技術的リスクをどのように特定し、軽減しますか？

Question

Accepted Answer

**技術的リスク**は、配信を脱線させたり本番環境で障害が発生したりする可能性のあるもの、すなわち未知数、脆弱な依存関係、スケーリング上限、単一障害点です。TLの仕事は、**リスクを早期に明らかにし、意図的に縮小すること**です。なぜなら、その上に構築する前にリスクに対処するのが最も安いからです。

## リスクを管理する方法

```text
1. IDENTIFY — what could go wrong? (unknowns, deps, scale, security, people)
2. ASSESS — likelihood x impact. Focus on the high-high quadrant.
3. ATTACK the biggest unknowns FIRST — spike, prototype, load-test
4. MITIGATE — reduce likelihood or blast radius (redundancy, flags, fallbacks)
5. MONITOR — track known risks; have a plan if they materialize
```

## 遅くではなく早く脱リスク化する

最も危険なリスクは*未知数*です。推定できないものです。スパイクやプロトタイプを使ってまず最初にそれらに取り組み、プロジェクトがまだ変更が安い段階で真実を学びましょう。簡単で既知の部分を最初に構築するのは生産的に見えますが、最後に地雷を残すことになります。

## 具体的な例

プロジェクトが、スケールで使用したことのないサードパーティAPI に依存しています。それが機能すると仮定してシステム全体を設計しないでください。1週目にそれに対してプロトタイプを作成してください。負荷に対応できない場合、それはすべてをその周りに構築した後ではなく、今わかります。

## 落とし穴

快適で既知の作業を最初に行い、怖い未知の部分を最後に残すこと。これはあなたが間違っている場合のコストを最大化し、まったく逆です。

## なぜ重要なのか

遅くまで無視されたリスクは危機になり、高額で、スケジュールを破壊し、士気をくじきます。

リスクを早期に追跡するTLは、小さな既知コストを今交換して、後で大きな未知コストを回避します。

この先見の明は、シニアリーダーを給料に見合う価値のあるものにする大部分です。