IT業界において開発の難しさに注目が注がれるのは主に、行いたい開発に対しどの程度の予算を確保すべきかを見積もる時と、開発を振り返ってそのコストが妥当であったかを検証する時だ。大規模開発ではこのような検証ニーズがあることが多く、いずれの場合も、開発の難しさは生産性(規模÷工数など)の逆数などで表現され、実際にそのシステムを開発する側や開発プロジェクトをマネジメントする側だけではなく、開発発注者や開発予算の承認・確保・検証の役割を担う第三者が納得できるように説明することが重要となる。
しかし、見積りコストや実績コストの妥当性について、皆が合意できる妥協点にたどり着くことは容易ではない。例えば大規模な開発の見積りコストの妥当性について検証を行う場合、コスト見積りの決定的手法や相場感がないIT業界では、その開発の難易度をどう捉えるかを関係者が皆納得できるよう説明し、妥当な価格で合意を得る必要がある。ただし、このような理想形で物事が進むことはむしろ少なく、ベンダ側は有識者による大まかな尺度での難易度評価を行い、かたやユーザ（発注部門）側はその妥当性を検証する術を持たないというケースが多い。こうなると、予算部門から承認が得られない、または無理な値引後契約をする安請負でプロジェクトの失敗を招き、更なるコスト増やプロジェクト中断という最悪のケースに陥ることもありうる。
今回は、コストの見積りや妥当性検証の重要な要素となる開発の難しさについてどのような要素を特に注意して合意すべきなのか、活用事例が増えつつある可視化手法等を交え、課題について考えてみたい。
システム自体の複雑さ
開発の難しさについて関係者間で認識のずれが起きやすい要素として、まず開発対象のシステム構造自体の複雑さが挙げられる。そのシステム構造の複雑さを可視化する方法は、大きく2つある。
1つはシステム構造可視化ツールを用いて、対象システム全体または改修保守範囲の複雑さを視覚的に表現し、場合によっては複雑度メトリクス等を算出する方法である。具体的には、影響分析ツール(Reverse Planet等)により機能単位での階層図示化や特定業務のフローの図示を行い、その図から複雑さを把握する。影響分析ツールが本来目的とする利用方法ではないが、プログラム構造解析機能を間接的に利用して、影響範囲の大きさという観点からシステムの複雑さを視覚的に把握することが出来る。他に開発者以外にもわかりやすい視覚化を行っている例としては、富士通APMモダナイゼーションサービスがある。対象の業務アプリケーションを一つの街になぞらえ地図のイメージで俯瞰する技術が提案されている。
システムの難しさを可視化するもう一つの方法は、ユーザ数やサブシステムの数、規模（ライン数、画面数、帳票数、データ量など）を業界データ（ソフトウェアデータ白書など）の値と比較する方法である。この方法は比較参照値とするシステムの詳細情報が分からないため、おおまかな比較にのみ適用される。例えば、該当する業界の値と比べて圧倒的に大きいシステムの等の場合には、業界一般とくらべてどれほど突出しているかを把握し共有することで、大小様々なプロジェクト経験をもつ関係者の難しさの基準のズレを改める第一手となる。その他には、同程度の規模や同じ発注者の案件の工程別の工数比率から要件定義やテスト工程にどれほどかけるべき案件なのかを共有することも有用な一手となる（小規模案件、簡易な案件ほど製作工程の工数比率が大きい）。
プロジェクト条件の難しさ
開発の難しさ、コストの妥当性を検証するには、システム自体の複雑さだけに着目するのでは不足がある。開発を行うシステムに対し、どのような条件下のプロジェクトを遂行する（した）ことになるのか、その条件はどれほど難しいのかについても関係者間で認識のずれが起きやすい。そしてこのプロジェクトの難しさの合意こそが、開発の難しさの合意において最も難しい要素となる。
有効な活用事例としてあげられるのが、類推法をベースとした見積りツールを活用する方法や、自らの開発実績をプロジェクトの諸条件とともにデータとして蓄積し活用する方法である。SEER for Softwareなどは2万件超のデータを有し、規定のプロジェクト特性を表すパラメータと規模の情報を入力することでプロジェクトの難易度を加味した工数を算出することができる。日本の開発案件に適用するには日米の違いも加味する必要があるが、実際の開発をもとにした推計結果であるため、限定的な条件から大まかな見積りしか行えない開発初期段階では概算見積りコストの妥当性を裏付ける根拠として重宝される。
自らの開発実績をデータとして蓄積する方法では、開発ベンダが個別に自社の開発データ白書を作成し、自社の特徴的なプロジェクト条件をCoBRA法などによって表現しコスト予実差異の根拠を逐次記録しつつ見積り精度を高める試みが事例が増えつつある。
商習慣上の課題
システムやプロジェクトの難しさが正しく合意しにくい状況には、IT業界の商習慣にも原因がある。特に、そもそも十分な情報が揃わないタイミングで合意しようとしていること、また柔軟な責任範囲の設計がしにくい契約形態のためなかなか合意に至らないことが要素として大きい。
前者はすなわち、要件が確定しない段階でのコスト見積りである。この時点での見積り精度は数分の一から数倍のずれがあってもおかしくない。しかし、現実には予算枠の確保という条件を満たすため、行わざるを得ないという場合が多い。このような不確定要素の多い見積りに対してはリスクを発注側・受注側どちらも理解し、契約を多段階に分け、要件定義終了後などのタイミングで改めて再見積りを行う方式を採用することが望ましい。
後者は、準委任契約と請負契約というプロジェクト推進の責任の持ち方が極端な契約方式ばかりが選択されている状況のことである。準委任契約では受注側のコスト管理責任が生じず、請負契約では発注者のコスト超過責任が生じない。不確定な仕様が混在する状況下でこのどちらかの契約を選択しなければならないとなると、一方の責任が事実上放棄された形での合意となりかねない。欧米の契約形態には、両者の中間のCPIF(コストプラスインセンティブフィー)など、受注側が予定コストを下回った場合のインセンティブ報酬を設定する一方、発注者は詳細なコスト見積り内容とコスト実績を踏まえた上で、発生コストをすべて支払うという契約方式も存在している。日本においてもこのような契約形態の活用が議論されるべき時期ではないだろうか。
以上のように、開発の難しさを関係者で合意することは活用出来うるツールが現れつつあっても、未だ課題は多く残っている。自社のデータ蓄積等によりこの状況を打破しようとしている企業は多いが、個別の努力では解決には多大な時間がかかる。プロジェクト条件を含む開発データを業界レベルで蓄積することや柔軟な商習慣の指針等の議論の進展が望まれる。