DX(デジタルトランスフォーメーション)推進コンサルティング 株式会社アイ・ティ・イノベーション

menuclear
ホーム > ブログ > 弘中 伸典の記事一覧 > 『3分でわかる!システム企画一問一答』なぜ要件定義後に開発費が倍増するの?


『3分でわかる!システム企画一問一答』なぜ要件定義後に開発費が倍増するの?

Pocket

話が違うじゃないか!!提案時に1億だった見積がなんで2億になるんだ!?

要件定義工程が終わった後、システム開発会社から提示された見積金額が当初より倍増し、このように発注側が困惑して(または怒って)しまう、という話をしばしば耳にします。
ひどい場合は3倍、4倍になるようなケースもあり、ここまで増加してしまうと流石にプロジェクトを中止せざるを得ない状況になってしまいますよね。
読者の皆様にも、似たような苦い経験をされた方が少なくないのではないでしょうか。

なぜそのような現象が起きるのか?

弘中 伸典が担当するシステム企画一問一答シリーズ、今回は「システム開発におけるコスト増の要因」について考えてみます。

Qなぜ要件定義後に開発費が倍増するの?

これまでコンサルタントとして多くの問題プロジェクトの評価や立て直しを経験してきましたが、コストが膨れ上がるケースには大きく3つのパターンがあります。

まずは「コストが倍増することを想定していなかった」パターンです。

むむっ!?

すみません、いきなりちょっと何言っているのか分からないですよね。初めから倍増することを想定していてはダメじゃないかと。。。

ですが、要件定義のビフォア・アフターでシステムの開発規模が拡大することは不思議ではなく、むしろ自然なことと言えます。
一般的に、システム企画でとりまとめた要求をもとに開発会社から提案書・費用見積が示されますが、その前提となるのはあくまで「要求」であって、まだ「要件」ではありません。

「要求」とは、発注側が「ビジネスとして実現したい状態が定義されたもの」ですから、実際にシステムを設計・構築するにあたって必要な「すべての情報」が「具体的に」記述されている訳ではありませんし、技術的な実現性も十分には考慮されていません。
その後の要件定義工程で定義される「要件」は、要求にもとづいて「どのような業務・システムを実現するのか」を発注側・開発側双方で合意するものですから、網羅性や具体性、実現性が確保された状態で定義されることになります。

例えば、「顧客毎に担当営業者を設定できる」という要求事項があったとして、この情報だけではシステムを作ることができませんよね。要件定義では「顧客の部門によって担当営業が異なる場合は?」「担当営業が異動になった場合は?」など様々なケースに対応できるよう検討することになりますから、提案時には認識できなかった多くの情報が追加され、その結果システムの開発コストは高くなります。そして、これは要件定義前後で最大2倍に増加すると言われています(※)。

従って、要求のみにもとづいて見積もられた金額そのままで開発予算を確保してしまうと、確実にオーバーすることになります。もうちょっと言えば、開発会社によって「要件定義後に規模が拡大することを織り込み済みの見積金額」が提示される場合と、「要求のみにもとづいた見積金額」の場合があり、後者の金額そのままで開発できると考えるのはNGだということになります。

提案を受ける際には、要件定義後に規模が拡大する前提に立ち、あらかじめどの程度バッファを持ち、どのように要件の絞り込みや管理を行うのか検討する、開発会社の見積の前提・根拠をしっかり確認するなど、十分注意しておくことが必要なのです。

次に「システム構築方式を間違えている」パターン。

ゼロから独自に開発する方式(スクラッチ開発方式)、市販のパッケージソフトを導入する方式など様々なシステム構築方式がありますが、最も多い失敗は「自社のコア業務領域に無理にパッケージソフトを導入しようとした」プロジェクトです。
コア業務とは企業の競争力の源泉となっている業務のことで、当然他社と差異化された独自性の高い業務プロセスや仕組みを持っています。このような業務領域に対して「業務をパッケージに合わせるんだ!」と息巻いてプロジェクトを始めても、競争力低下に繋がるような業務の変更が許容できるはずもなく、結局ほとんどの機能をカスタマイズするハメになり大幅なコスト超過になることは目に見えています。

市販のソフトやサービスを利用する場合には、それが自社の業務領域の特性に合致しているのか、しっかり見極めておくことが不可欠です。

最後は「ビジネスとして実現したい状態が定義されていない」パターン。

これは、第1回目でご紹介した「システムに不要な機能ができてしまう」理由と同じです。つまり「システム化という手段が目的化している」、「ユーザーの課題をそのままシステムへの要求としている」といった原因によって目指すゴールが曖昧になっており、不要な要件、オーバースペックとなる要件を絞り込むことができず、開発規模が膨らんでしてしまうケースです。

つまり、システム企画でしっかり手順を踏んで目的や要求を定義できていない場合、自然に増える可能性のある2倍どころか3倍、4倍にコストが膨らむ可能性が出てきてしまう、ということになります。
逆に、しっかり目的を定義し、システム企画段階で要求の検討に十分な時間を掛け、要件定義の前にある程度網羅性や具体性を高めておくことができれば、要件定義後でも1.5倍あたりまでに規模拡大を抑えられることができるようになります。

今回の答え。

A正しく進めても最大2倍になってしまうものだから(ただし、構築方式を間違えず要求に網羅性・具体性を持たせられれば抑えることは可能)

一昔前は、開発会社が見積金額に相応のバッファを乗せておき、要件定義後の規模拡大を吸収するやり方が主流でしたが、バッファで吸収しきれないと開発会社は赤字になり、発注側もムダの多いシステムを作ってしまう事になりやすく、問題の多い方法でした。
現在は、要件定義後に再度見積もりを行って、規模拡大に伴う追加コストは委託側が負担する考え方が主流になりつつありますので、発注側はシステム企画段階からコスト増加の可能性を踏まえながら検討を進めておくことが重要と言えます。

それでは次回もお楽しみに!


| 目次
Pocket

採用情報
PM-waigaya
PM-WaiGaya
コンサルタントのトーク動画
PM Weekly Talk
PM Weekly Talk
コンサルタントが語る「PMBOK®12 の原理・原則」

Profileプロフィール

Avatar photo
弘中 伸典
1994年、徳山工業高等専門学校情報電子工学科を卒業。 SIベンダーに入社後、数々のシステム開発の現場で活躍。そこで得た多くの経験に感謝しつつも、IT業界における構造的問題に一石を投じるべく株式会社アイ・ティ・イノベーションに参画。問題の原因は、プロジェクトマネジメントの欠如にあると考え、日々のコンサルティング業務を通じてその必要性を訴え続ける。 専門領域は、プロジェクトマネジメントおよびシステム開発プロセスの標準化、PMOの設置と運営、IT投資マネジメントなど。 責任と誠意を持って問題解決に取り組む姿勢を大切にしている。 PMP(Project Management Professional)資格 保有

Recent Entries最近の記事