要件定義力の再構築（1）：「苦悩からの脱却」を目指す「一丁目一番地」

（本記事はBizauthが提供する「BA BLOG」から転載、編集しています）

　「プロジェクトで失敗する」「ベンダーにいいようにやられる」――。こういったことを繰り返し、IT部門は苦境に追い込まれていく。その背景には、IT部門にとっての「一丁目一番地」ができていないという現実がある。それはつまり、「開発」と「運用」であることは言うまでもない。

　筆者がコンサルタントとして働き始めた二十数年前、所属する外資系コンサルティングファームは開発の方法論、すなわちメソッドを持っていた。「このメソッドがあるから我々は失敗しない。On Time、On Budgetでプロジェクトを成功させる」。それが当時のメッセージであり、結構斬新に世の中に響いていた。「失敗しない」というのは、ITを担う者にとって、最初に達成されなければならないことなのだ。20年以上前から、それは決まっている。

　もっとも、現実には、On Time、On Budgetでプロジェクトが成功することはまれで、多くの失敗をしていた。しかしながら、プロジェクトを成功させるためにさまざまな手だてを尽くし、手法としてまとめ上げる点は画期的だった。

　後に、多くのベンダーやユーザー企業が開発標準化や運用標準化という名のもとに追随し、各社の開発手法と運用手法が整備されていく。現代においては、ITIL（Information Technology Infrastructure Library）やPMBOK（Project Management Body of Knowledge）など、業界横断やグローバルでの標準化も進んできている。IT部門にとっての一丁目一番地には、世界中も一生懸命なのだ。

　ただ、こうした手法に心酔し切れるかというと、そういうわけではない。やみくもに信じることはできない。なぜなら、さまざまな手法が暗黙に前提としていることが、自社のものと異なっていたり、ベンダーとの契約タイミングなどが慣習的・制度的に世の中の標準手法と微妙に異なっていたりすることもあり、単純に信じるには危険が伴う。

　また、こちらの方が致命的なのだが、何とっても要員の厚みが想定と全く異なっている。できているに越したことがないのだが、経営者がそこまで人材を投入して厚い体制を作ることを容認していない。学べるものが数多いのであるが、自分たちなりの手法を編み出していかなければならないのだ。

プロジェクトの失敗は要件定義ができていないことに起因

　誰もが納得することだろう。開発の三大失敗理由は、「要件定義が終わらない」「パフォーマンスが出ない」「移行ができない」である。かつて、筆者が外資系コンサルティングファームに属している際に、失敗プロジェクトの総括というものを数多く手掛けているが、失敗の理由はほぼこの3つの事象に収れんする。

　もっとも、パフォーマンスが出ないというのは、ハードウェアの構成やサイジングを誤っていることや、ソフトウェアの構成や相性が悪くて起こることが多いため、これはこれで要件定義時にきちんと検討できなかったと考えることができる。

　また移行ができないというのも、要件定義の段階において移行方針や移行計画が適当に作られてしまうことで着手のタイミングがむやみに遅れてしまったり、実際の移行プログラムの作成やデータの投入に本来は多大な工数がかかるにも関わらず過小に見積もったりすることで起きるとも言える。これも要件定義ができていないことに起因すると言えないこともない。

　すなわち、プロジェクトの失敗は、ほぼ要件定義ができていないことに起因するのだ。逆の言い方をすると、要件定義が成功すれば、ほぼ全ての案件がうまくいくともいえる。また、運用をきちんとする、すなわち障害を発生させることなく、効率的にシステムを動かすにも要件定義が寄与する。システム障害の70％程度は、新規や追加開発のリリース後1カ月以内に起きる。すなわち、開発がきちんと行えれば、運用段階での障害も劇的に減らすことができるのだ。

　こうしたこともあり、筆者は要件定義の作成能力こそ、情報システム部門にとっての「核心的能力」だと思っている。

　情報システムのライフサイクル的に見て、最も重要なフェーズが要件定義だ。システムのライフサイクルで見たときに、ほとんどの企業は要件定義を終了するとベンダーへ委託する。多くの場合、請負で委託することが多いだろう。そして、開発を受注したベンダーがそのまま保守・運用を担っていくだろう。

　ライフサイクルで見たときの大きな転換点が要件定義であり、その機能性、安定性、経済性を決定付ける。システムの成功と失敗の分水嶺がここにあるということだ。

　情報システム部門の使命から考えても、要件定義がその使命の達成のために極めて重要な業務であることは明白である。情報システム部門の役割は、ITの投資対効果（IT-ROI）を継続的・長期的に最大化していくことにある。そのために、良質なシステムを安価で装備し、安定的かつ効率的に運用していくことが求められる。

　「良質なシステム」とは、経営、ユーザー、顧客にとって効果をもたらす機能を装備することであり、障害のない安定的な運行を可能とするシステムである。安価・効率的であるとは、委託契約段階で決定する価格内に、開発作業や運用作業を押さえることで達成される。こうした、質の決定、価格の決定は要件定義を通じて行われるもので、この業務こそが情報システム部門のパフォーマンスを決定付けることに異論はないだろう。

　これ以外の能力が重要ではないかというと、決してそんなことはないのであるが、要件定義能力の「核心度」から比べると、「周辺度」が高い能力が多くなってくる。最近では、IT-ROIの管理の重要性が高まり、ITコストの詳細把握が求められ、効果管理の重要性は高まっている。要件定義でベンダー委託をする際の見積もりの明細度、具体性、比較容易性を確保しておかなければ、コストの把握自体が難しくなる。

　また、ベンダー管理の重要性も、ベンダーとの利益相反が大きくなっている現代では、重要度は高まっている。ベンダーに何をどういう条件で委託をするか、能力の見極めをどう行うかは要件定義時のRFP（提案依頼書）からベンダー選定のプロセスで実現できるものが多い。ユーザーへの業務改善・改革提案は、革新を望む経営やユーザーが増えてきていることにより、一層の重要性を増している。要件定義を経て実際にどれくらいのコスト、実現性で可能となるのか、業務改革自体の成否がそこで決まるため、やはり核心的な影響をもたらす業務であることに変わりはない。

　情報システム部門にとって、高い要件定義力は不可欠である。そして、苦境に陥ったIT部門は、間違いなくこの点に問題を抱えている。その力を回復することが、情報システム部門を苦難から脱するための核心であり、「一丁目一番地」の最重要課題となるのだ。