2024年12月19日

初めに

最近、システム開発の現場では「不確実性」という言葉が流行っています。しかし、多くの場合は「不確実性」が誤用されており、「不確実性」の本来の意味が失われつつあります。そこで、初めに「不確実性」の本質的な意味を考え、次に不確実性をどのように扱うべきかを考察します。

不確実性はリスクではない

経済学者であるフランク・ナイトによれば、不確実性とリスクは明確に区別される概念です。不確実性は確率的に予測できないものであり、リスクは確率的に予測できるものです。つまり、「リスク評価」という言葉は存在しても、「不確実性評価」という言葉は存在しません。システム開発における不確実性とリスクの例をそれぞれ示します。

不確実性の例
- まったく新しいアーキテクチャの採用による影響
  - 過去の採用事例がないため、何が起きうるのかを予測できない
  - 類似事例があったとしても、技術スタックやビジネスの文脈が異なる場合はその経験を確率的な予測に使えない
- 新規事業のシステムにおけるユーザーの行動
  - ユーザーがどのような行動を取るのか、どのような機能を求めるのかを予測するためのデータがない
- 未知の脆弱性による影響
  - 未知であるためどのような脆弱性が存在するのかが分からず、従ってそれがどのような影響を及ぼすのかを予測できない
リスクの例
- 特定の機能開発における工数の超過
  - 過去の類似機能の開発実績から、かかる工数を算出できる
- 負荷テストで見つかった性能劣化
  - テスト環境での測定結果から、本番環境での性能劣化の発生確率を算出できる
- テストにおけるバグ発見数の予測
  - コードの規模、複雑度、開発チームの経験などから、バグ発見数を予測できる手法が確立されている

不確実性は予測できないものであり、リスクは予測できるものです。しかし、プロダクト開発において不確実性を予測しようとする事例が数多く存在します。

例えば、IBMのメインフレーム事業ではSystem/360というシリーズが人気を博していました。その後にIBMは、需要の増加を理由にPC事業に参入しました。これまで企業向けに販売されていたメインフレームとは異なり、PCは消費者向けに販売される製品であり、市場動向を予測するのが難しいという特徴がありました。しかし、IBMはSystem/360で培った知識を基に、PCの市場動向を予測しようとしました。これが原因となり、IBMはCompaqなどの互換機メーカーとの価格競争に負けてしまいました。

このように、これまで予測可能であった「リスク」が「不確実性」に変わったことに気付けないことがあります。

プロジェクトマネジメントは予測ではない

ところで、近年では様々な指標が予測できるようになった影響で、プロジェクトマネジメントがあたかも「予測」する作業のように捉えられることがあります。「プロジェクトを管理するために予測が必要だ」という推論は一見正しそうですが、管理するためには本当に予測が必要なのでしょうか？過去の類似プロジェクトのデータがある場合は、それを用いてプロジェクトの流れを予測すべきですが、前例のない取り組みに対しては無理にデータを引用して予測するのではなく、今後起きうる問題に適応するための方法を考えて実践すべきです。

例えば、システムの小規模なアップデートに必要な工数は過去の開発実績から予測できますし、場合によっては発生しやすい問題を事前に特定することもできます。しかし、新しい技術を利用したサービスやプロダクトを開発する場合は、その工数、起きうる問題、そのものの価値を事前に予測することはできません。そのため、問題に適応しやすいマネジメント手法を活用することが重要です。例えば、小規模なPoC (Proof of Concept: 概念実証) から始め、早いうちからユーザーフィードバックを収集し、課題を見つけたときに迅速に方向転換できる体制を整えることで、問題への適応性を高めることができます。