「攻めのIT経営」におけるシステム発注の重要性

　企業をとりまくビジネス環境が目まぐるしく変化するなか、戦略的なIT投資によって企業価値の向上や競争優位性の強化を図る「攻めのIT経営」が重要視されています。モデルとなった海外企業は、ITを内製化しており、経営トップの直接コントロールのもと、俊敏かつ柔軟にITを構築することで新たな顧客価値を創造しています。

　しかし、日本企業の多くは、IT構築をITベンダーに外部委託しているため、ITを内製化している海外企業のように俊敏かつ柔軟なIT構築が困難です。一部の企業では、ITの内製化に向けた取り組みが始まっていますが、高度なIT人材の育成・確保、IT組織改革と権限委譲、ITに精通した経営メンバーの参画など、さまざまなハードルがあり、一朝一夕には実現できないのが現状です。

　こうしたIT構築を外部に頼らざるを得ない企業にとって、「システム発注力」こそが、IT投資の成果に直結した重要な能力と言えるでしょう。

　筆者は、企業システムの企画段階から発注後のプロジェクト支援（PMO：Project Management Office）のほか、提案依頼書（RFP：Request For Proposal）に対する提案実施から受注後のプロジェクト推進に携わっています。本連載では、システム発注を支援する側・提案する側から知り得た経験をもとに、システム発注力を高めるために発注者が留意すべき事柄や、システム発注に失敗しないための取り組みについて紹介します。

システム発注の成功率はわずか3割

　最近では、RFPを用いたシステム調達は珍しくなくなりましたが、国内のシステム調達にRFPが使われるようになったのは2000年代に入ってからです。

　それ以前は、ITベンダーに発注内容を伝えて、見積と作業計画、要員の経歴書を提示してもらい、契約交渉を行っていました。RFPが普及した背景には、企業の設備投資に占めるIT予算の急激な増加により、IT予算を統制する意図があったと考えられます。

　RFPが定着した今日において、発注担当者がRFPに最も期待していることは、提案内容に優れた費用対効果の高いITベンダーにシステム発注を行うことでしょう。IT投資の費用対効果を高めることができれば、IT予算を統制するという経営側の意図とも合致します。

　それでは、RFPによってシステム発注の成功率は向上したのでしょうか？　たとえば、システム開発プロジェクトの成功率は3割というのがIT業界の定説です。一般的にシステム開発プロジェクトの成否は、計画当初のQCD（品質・コスト・納期）の達成で判断します。しかし、RFPを用いたシステム発注が定着した近年において、この数字が大きく改善された調査結果は発表されていません。

　したがって、7割ものシステム開発プロジェクトに問題を生じさせる原因は、発注プロセスと異なる別の部分にあると考えたほうが自然です。

　システム開発プロジェクトの成功率が改善しない原因とは何か？　筆者は、昨今の「攻めのIT」のように高度化したITミッションを実現する方法論として、現在も多くのシステム開発で採用されているウォーターフォール型開発モデルにミスマッチが生じていることが関係していると考えています。

ソフトウェア開発プロセスに内在する「不確実性」の正体

　ご存じのようにソフトウェア開発には「不確実性」が伴います。不確実性とは、事象が確実でないことを表した概念です。ソフトウェア開発プロセスの不確実性の研究として、ソフトウェアコスト見積手法の COCOMO を提唱した数学博士ベームの1983年論文「ソフトウェアエンジニアリング経済学」の工程と比較したソフトウェアコストの推定精度があります。


　上図は工程ごとのソフトウェアコストの見積精度に対する「ばらつき」を示したものです。ソフトウェア開発は、初期段階の見積精度が低く、工程が進むごとに見積の差異が小さくなることを表しています。このグラフの形状から「不確実性のコーン」と呼ばれており、ソフトウェア開発の初期段階で正確なコスト予測が難しいことを表しています。

　調査が行われた当時の開発モデルは、ウォーターフォール型が主流です。ウォーターフォール型開発モデルは、ソフトウェア開発の全体プロセスを工程に分割し、要件定義に始まる上流工程から下流工程に向けて、段階的に詳細化を進められます。大規模プロジェクトの事例も多く、ITベンダーの標準的な開発モデルとして管理手法や作業手順が研究され、経験者が確保しやすいなどのメリットがあります。

　ウォーターフォール型の原則として、上流工程の決定事項をもとに下流工程の詳細化が行われます。そのため、上流工程の些細な誤りや見落としが、下流工程の作業量やソフトウェアの品質に影響します。

　しかし、上図グラフの通り、ソフトウェア開発の上流工程には、大きな不確実性があるため、上流工程の完全性を追求することは困難である、という矛盾をはらんでいます。

　不確実性の度合いは、IT導入の目的や種類によっても違いがあります。たとえば、会計業務のように、IT導入による差別化が難しく、パッケージ製品が豊富で、市場調達も容易なIT導入の場合は、導入事例の活用やパッケージ製品の設計思想に合わせて業務プロセス・ルールを見直すことで、不確実性を抑えることができます。

　不確実性が小さければ、ウォーターフォール型は最も効率に優れた開発モデルかもしれません。しかし、「攻めのIT」のように、競争優位性の確保がIT導入の目的となると話は変わります。

　たとえば、先端ITを他社に先んじてビジネスに活用することを目指すような場合、導入事例が乏しいため、実現性や導入効果の確証は得られません。その結果、必然的に不確実性は大きくなります。

　ウォーターフォール型開発モデルが抱える不確実性については、ソフトウェア技術者も静観していたわけではありません。小規模な開発とテストを反復しながらシステム開発を行うアジャイル型の開発モデルなど、新しい開発手法を提唱しています。

　しかし、ちょっと古いデータですが、国内では9割を越えるシステム開発プロジェクトが、ウォーターフォール型で行われているのです（注1）。

上流工程の品質を確保できない「V字モデル」

　ウォーターフォール型のシステム開発を計画通りに進めるセオリーは、各工程の品質を確保し、後続工程の手戻りを最小限に抑えることにあります。特に上流工程は、後続工程に与える影響が大きくなるため、品質確保が重要な工程と言えます。

　ウォーターフォール型には、V字モデルと呼ばれる品質管理の考え方があります。開発プロセスをV字に配置し、相対する工程間で品質を担保することで、システム全体の品質を確保する方法論です。

　V字モデルは古くからある方法論ですが、最近では、要件定義とシステム要件定義を分割し、最上流工程にシステム企画（システム化計画）を加えたV字モデルをよく目にします。

　また、システム企画と要件定義は「超上流工程」と呼ばれています。超上流工程の作業手法や決定すべき事項を明確化することで、上流工程の品質向上を意図しており、昨今のITミッションの高度化と関係性が伺えます。

　シンメトリー構造の美しいV字モデルは、見る人に納得感を与えます。筆者自身、ウォーターフォール型の品質管理は、V字モデルであると信じてきました。

　しかし、超上流工程の品質向上に取り組むなかで、V字モデルの問題点も実感しています。たとえば、一般的なV字モデルの考え方では、システム企画に対しては運用後の効果検証、要件定義に対しては運用・受入テストを位置づけています。つまり、超上流工程の品質を確認して是正できる機会は、システム開発の終了後になるのです。

　しかし、高度なITミッションの実現と現行システムの刷新を合わせたプロジェクト全体工期が2年におよぶ、大規模システム開発プロジェクトは珍しくありません。

　このようなタイプのプロジェクトは、発注担当者と議論を行うと人によってプロジェクトの達成目的の優先順位に違いがあるケースが多く、上流工程の品質確保の難しさを痛感しています。

　このように、難易度の高い大規模プロジェクトでも、上流工程の成否が確認できるのは、V字モデルでは2年後ということになるわけです。

「攻めのIT」を体現するグローバル企業が取り組んでいること

　V字モデルにも、要件定義に対応した運用・受入テストが検証プロセスとして存在しています。しかし、この時点でIT導入目的を損なうような不具合が発覚したとしても、システム自体はシステムテストを終えた完成に近い状態です。マスタースケジュールでは、カットオーバーまで残されている期間は残りわずかでしょう。軽微な改修であれば対処できるかもしれませんが、大幅な改修が必要になれば、改修後にテストをやり直さなければならず、納期遵守が難しくなります。

　この2年間、発注企業には、開発費用というIT投資を行っていますが、仮に上流工程の検討不足によって意図した効果が得られなくても、投資コストは戻ってきません。

　保守工程の改修で、当初のITミッションは達成できるかもしれませんが、追加コストによって費用対効果は低減します。さらにリリース延期によって、効果的な市場投入のタイミングを逃せば、機会損失という形でも投資効果は減少します。

　ただし、最小限の機能実装でシステム運用を開始する、スモールスタートであれば、保守工程で見直しを加えながら品質向上を図るという進め方は、非常に理にかなっています。

　つまり、システム運用を含めた長期的なライフサイクル全体で捉えれば、V字モデルは上流工程の品質管理に有効です。しかし、システム開発プロジェクトの期間中においては、V字モデルは上流工程の品質管理の手段を提供していないと言えます。

　では、このような問題について、「攻めのIT」を体現しているグローバル企業は、どのように取り組んでいるのでしょうか？　そのひとつと言えるのが、BA（BOK）ではないでしょうか。

　BA（ビジネスアナリシス、またはビジネスアナリスト）とは、ビジネスニーズを定義し、ステークホルダーに価値を提供する解決策を立案することにより、企業の変革を引き起こすことを目指す活動（または専門家）であり、BABOKはBAの知識体系をまとめたものです。

　国内でも2010年頃にBA（BOK）活用が話題になったことがありますが、残念ながら国内ではBAの活動は定着してないのが実情です。米国ではBAの導入支援を専門に行う企業があり、ユーザー企業のBAに対する積極的な活用姿勢をうかがい知ることができます。

　しかし、国内では同様な事業を行っている企業は極めて少なく、発注企業のBAに対する認知度や導入ニーズの低さを物語っています。

【次ページ】「攻めのIT」をともに実現するITベンダーに求めるべき2つ資質