不確実性のコーンでシステム開発のリスクと対応方法を考える
ITコンサルのyw（ゆー）です。
システム開発に関するレポートや書籍で”不確実性のコーン”と呼ばれるサムネイルの図がよく出てきます。私の経験上もこの考え方はとても重要だと思いますし、昨今の事情を鑑みるとより重要度が増してきています。
最初にこの考え方が登場したのは1981年と言われていますが、変化の激しいといわれるIT業界においても最近のレポートや書籍でも多く登場しており、システム開発における普遍的な事実を表していると捉えることができます。
不確実性のコーンが登場するレポート・書籍
・超上流から攻める IT 化の原理原則 17ヶ条（2010）
・情報システムに係る政府調達について（2010）
・共通フレーム2013（2013）
・IT サービス政府調達に関する調査 報告書（2017）
・アジャイルザムライ（2011） etc...
そこで、今回はこの”不確実性のコーン”とは何なのか。実際のシステム開発においてどの様にこの知識を活用するのかについて解説したいと思います。
システム開発におけるリスク分析、全体計画などに役立つ基礎知識ですので、関係する方は読んでみていただけたら。
不確実性のコーンとは
登場するレポート・書籍毎で表現は異なりますが、概ね以下のような図で表されます。
これは、システム開発の初期段階の方がスコープ（コスト、期間、開発機能）のばらつきが大きく、開発が進むにつれて、ばらつきが小さくなることを表しています。
いわゆるウォーターフォール開発の場合のように見えますが、アジャイル開発においても小さい開発単位（イテレーション）ごとにIT企画～テストのプロセスを経ます。
不確実性のコーンが示すこと
スコープのばらつきが大きいということは、計画に対して実績が乖離しやすい、つまり、リスク（=顕在化前の課題）があるということです。
つまり、システム開発の初期段階ではスコープの変動リスクが大きく、完成に向かうにつれて変動リスクが小さくなるということです。
実際のプロジェクトでは、特にプロジェクト初期においてはスコープの変動リスクが有ること考慮して、リスクマネジメントが必要であることを示しているわけです。
不確実性のコーンに関連する具体的な問題例
イメージしやすいよう、実際のシステム開発で起こりうる問題について例を上げたいと思います。これらは私が実際に何度も経験している事例です。
例.1 要件定義でのコスト増加
IT企画を元に要件を整理し始めたら、想定した以上に複雑なシステム機能が必要なことが判明し、コストが倍以上かかることが判明した。
例.2 設計での工期長期化
設計を始めたら、利用しているパッケージには想定していた機能がないことが判明し、スクラッチ開発（１からの開発）が必要であることが判明。工期が長期化した。
例.3 テストでの要件不足による手戻り
発注者側でのテスト（UAT）を実施したところ、法務上必要な機能の不足が判明、追加開発が必要になった。
例.4 開発中の外部環境変化で要件が追加
開発開始した段階で、競合企業が類似サービスをリリース。ビジネス優位を確立するために、新たなマーケティング機能の追加開発が必要になった。
もう一歩、近年のシステム開発の特徴
不確実性のコーンが提唱されたのは冒頭で述べたとおり1980年代ですが、考え方が古くなってきているかと思いきや、むしろこの考え方は重要度が増してきていると思います。
というのも、近年特に以下のような状況が発生してきており、システム開発における不確実性（=リスク）が増してきているからです。
外部（市場）要因
ビジネス環境の変化が早くなってきています。これはDXの文脈で語られることも多いですが、ITを用いたビジネスの変化が激しく、半年、１年と開発していたらその間にビジネス環境は大きく変わってしまいます。
それにより、システムに求められる機能というのも時間経過とともに変化するリスクが大きくなってきています。
内部（開発）要因
システム開発の環境も日進月歩で変化していっています。そのため、ベンダーにとっても利用実績の少ない新しい技術を用いる場面も多いです。そのため、設計・開発段階で要件を実現困難・想定以上の工数が発生する場面も多くなってきています。
加えて、システム自体もITの高度化に伴い複雑化しています。スクラッチ開発は減り、何かしらの外部サービス/パッケージ/ライブラリを活用しながら開発するのが一般的になってきていますので、開発段階になって、利用する外部サービスなどの制約で想定以上の開発量となることも起こりやすくなってきています。
さらにもう一歩、重要度が増す案件の特徴
不確実性のコーン自体はどんなシステム開発にも当てはまりますが、案件の特徴によってスコープ変動リスクの大きさには違いがありますので、どのような案件で特にリスクが高くなるのか見ていきます。
不確実性のコーンの重要性がます案件の特徴
・開発期間が長期
・新規ビジネス向けシステム
・新しい技術を用いた開発／開発者の熟練度が低い
一つづつ解説します。
開発期間が長いとばらつきは大きくなります。それは外部環境の変化により要求が変動するリスクが有るからです。
新規ビジネス向けシステムの場合はばらつきは大きくなります。これも外部環境の変化速度が大きいため要求が変わる可能性があります。逆に確立した業務をシステム化するような案件ではリスクは高くありません。
利用する技術が新しい場合は開発段階で手戻りが発生する可能性があるためこれもリスクが高くなります。また、その技術に対して開発者の熟練度が高い場合は問題になりづらいですが、低い場合はよりリスクが高くなります。逆にレガシー技術で開発する場合にはあまりリスクは高くありません。
この知見をどう活用するのか
ここまでで、不確実性のコーンが表すシステム開発のリスクを見てきました。では、この知見をを生かして、実際のシステム開発へ適応するのか解説します。
不確実性のコーンが示すのはプロジェクトにおけるリスクです。なので、このリスクを回避/低減/転嫁する方法を紹介します。
以下に上げる案は実際の実行には様々なノウハウが必要となるため、ここでは紹介程度にとどめておきます。
案1. アジャイル開発を取り入れる
日本では未だウォーターフォールによるシステム開発が一般的です。ウォーターフォール開発ではプロジェクトの最初に要件、計画を決定し、リリースまでその通りに進めます。
一方、アジャイル開発は開発中であっても要件や計画の変更を受け入れます。そのため、アジャイル開発ではプロジェクト途中でリスクが顕在化しても影響を低減する事ができます。
案2. 分割調達する
各フェーズごとにベンダーと契約する分割調達の方式も有効です。よくあるのは、基本設計までと詳細設計以降で分割するのが一般的と思います。
億単位の大規模案件の場合には有効ですが、小規模案件の場合には逆にコスト高や開発機関の長期化の要因にもなるので注意が必要です。
また、同じベンダーに分割調達しても金額交渉の機会を増やすだけになる可能性があるためこの点も注意が必要です。
案3. スコープを柔軟に変更可能なスキームを構築する
プロジェクトが計画通りに進まない場合に何が問題になるかと言うと、リリースが遅れることや予算超過するなどの実害以外にも、経営層の理解が得られないなどの社内的問題が発生するケースも多いです。
例えば、市場環境が変わったので予算追加して新しい機能を増やしたほうが良いケースという場合に、経営層からは計画立案当初になぜ予見できなかったのか、予算を取らなかったのかと追求され、プロジェクトが滞るケースです。
こういったリスクがある場合（経営層が計画の変更を許容しない体質の場合）には、予めそれらを許容できるスキームを構築しておくというのも一つの案としてあります。
実際にやることは単純で、予めバッファを持った予算や計画で決裁を取っておくなどになります。問題が顕在化してから説明すると、いくら説明しても否認されてしまうので、計画段階（予算取り段階）で説明するのが鍵です。
理想的には、継続的に不確実性のコーンについて経営層へ理解を求めるようにしておくのが良いです。要は、システム開発とはリスクを含むものであって、当初計画から最大4倍程度は乖離してしまう可能性があるということを理解させておくということです。
案4. 請負契約とする（オススメはしない）
DXで問題として取り上げられている対応方法であり、弊害のほうが大きくなることが多いためオススメはできませんが、請負契約とすることも一つの案です。
要は、請負契約とすることで、スコープ変動リスクはベンダーへ責任を転嫁できるため、ユーザ企業としては（契約上は）リスクオフになります。
但し、以下の状況となることは理解しておく必要があります。
請負契約による発生しうる状況
・リスク分は結局は開発費用に含まれる
・ユーザ企業側に責任は残る
1点目について、ベンダーもシステム開発にはリスクが含まれることをよく知っています。そのため、請負契約でのシステム開発においてはかなりのバッファを設けて、見積もり、計画を提示するのが一般的です。
そのため、結局のところ、リスクオフしたつもりが、そのままユーザ企業にコストとして跳ね返ってきていることが多いです。
2点目について、全てリスクオフしたつもりになっていても、大抵の場合はユーザ企業にも責任は残るた完全なリスクオフにはならないです。
大抵の場合においては、要件定義とUAT（受け入れテスト）はユーザ企業責任です。つまり、要件定義に誤りがあった場合にはユーザ企業側が責任を追う必要が出てきます。
仮に、要件定義やUATをベンダー責任として請負契約した場合（そもそもこれはシステム開発におけるアンチパターン）は、ビジネスとシステムの整合を取れなくなる可能性が高く、システム開発自体は成功しても、それを活用する段階で問題が発生することが多いです。当然この部分はユーザ企業責任になります。
まとめ
不確実性のコーンについて説明しました。それは、システム開発におけるスコープ変動リスクについて示しており、その対応方法についても解説しました。
昨今はその重要性が増しており、また、案件特性によってもその重要度は変わるため、案件に応じて以下のような対応案も検討すべきということを解説しました。
・案1. アジャイル開発を取り入れる
・案2. 分割調達する
・案3. スコープを柔軟に変更可能なスキームを構築する
・案4. 請負契約とする
今回も最後まで読んでいただきありがとうございました！
この記事が気に入ったらサポートをしてみませんか？