システム開発の費用はなぜブレまくるのかを徹底検証

システム開発における見積もりは、以下のコラムでも触れたとおり信頼性が低く、計画どおりに進まないものです。

ありとあらゆる形でブレまくるシステム開発の費用。その根本理由について本コラムで徹底検証してみます。

パターン1　システム開発という試みが、業者への見積依頼から始まる

仕事の出発点が見積依頼である場合。
公共機関の入札や、民間企業における相見積もりがこれに該当します。

ちなみに国および地方公共団体の契約は原則として入札によらなければいけません。
また民間企業による相見積りは、少しでも有利な条件で取引したい心理も働き、商習慣として強く根付いています。
さらに昨今ではWeb上で発注者とシステム開発会社を結び付ける市場が拡がっており、この状況に拍車をかけています。

しかし製造や建築の分野、あるいは消耗材を始め普及商品を発注すること等と比べると、システム開発の分野での発注は随分勝手が異なります。何にせよシステム開発という営みにおいては、この入札や相見積もりという段取りは相性が非常に良くないのです。

以前コラムで述べたとおり、システム開発は、人間が行うプロセスを扱う仕事です。
そのプロセスを実際に見ることなく、さらにはその対象となる組織や働いている人たちの状況を仔細に聞くことなくイメ―ジすることは難しいからです。現実的には不可能と言い切っても良いでしょう。

その状況で、システム開発会社が提案や見積りをすると云っても、有効な手法は限られています。
推測で提案するか、過去に行った仕事で一番近いケースを参照して類推するか、システム開発会社自身が持っている製品を提案する、のせいぜい3択になります。

にもかかわらず、見積依頼をすれば応えてくれる業者がいると期待する発注者と、それに応えることを是とする業者。この両者における「美しき誤解」によって悲劇が生まれます。

出発点から波乱要素を含んだ案件において、初回提案や見積りが暫定であったとしても、いざ契約が交わされると「暫定」という申し送りは静かに忘れ去られることが殆どです。こうして時限爆弾を抱えた状態でプロジェクトが始まります。検討が進めば進むほど、推測や過去の経験に基づいた提案には無理があったことが見えてきて、当初それが妥当であると信じられてきた見積もりはブレ始めて、やがて深刻な状況をもたらすのです。

パターン2　要件定義に割り当てる時間が少なすぎる

「要件定義」とは、そのソフトウェアやシステムに必要な機能や性能を明らかにしてゆく作業のこと。実際の具体的な開発作業を始める前に行う作業のひとつ。また顧客が望んでいる機能や仕様などについて、その概略をまとめた文章・文書を指すこともある。（wikipediaより）

これまでに当社はシステム開発案件の仕切り直しのご相談を数件受けたことがあります。
ご相談内容は、多額の追加費用を求められて頓挫している、要件が固まらず作業が止まってしまっているなど、様々です。

そのような相談を受ける中である共通項に気が付きました。
当時の担当であったシステム開発会社が着手時に出した見積書を見ると、要件定義に割り当てる費用が極端に少ないのです。詳細をここに書くのは控えますが、大雑把に全体を「100」とすれば、要件定義にはせいぜい「5」程度の費用しか割り当てられてません。

見積書には申し分け程度の要件定義費が計上されているだけで、あたかも開発作業の「おまけ」として扱われているような印象です。
確かにクライアントにとっては、システムが備えるべき機能要件のそれぞれの費用は気になるものの、要件定義といった目に見えないものには価値を見出しづらいものでしょう。

システムを作るという試みは、クライアントにとってはそう何度も経験しないほどの大事業です。
クライアントがあれもこれもと要望を出したくなる気持ちはよくわかります。

ただそれらを優先付けしたり、仕分けたり、抽象化したり、単純化したり、と様々手法で整理していかないと「本当はどうすべきなのか」は見えてこないのです。クライアントの口から様々に語られる与件に対し、輪郭を与えていくというプロセスがシステム開発の最初のヤマ場と言えるでしょう。

大雑把に、要件定義、設計、開発、テストといった作業工程を経てシステムは完成します。
設計以降の工程はシステムを作ることについて存在していますが、要件定義では、システムを作ること以前の検討について存在しています。

つまり要件定義という作業は、決しておまけのような存在ではなく、むしろ比重をかけてしっかり行うものなのです。
これをおざなりにしてしまうと、見積もった作業内容と費用がブレて、システム開発は迷走しまくります。

パターン3　システム開発の「ある特異性」を理解せず、ビル建築事業のように扱う

システム開発が備え持っていて、他の産業分野における製造や構築業務が持ちえない「ある特徴」について以前、こちらのコラムでも述べました。簡単に比較するうえで、ここではビル建設とシステム開発とを比べてみることにします。

どちらも発注者の要求に沿ったものを設計して組み立てていく点、すなわち「モノ」を作る点では同じですが、決定的に違う点があります。

それはシステム開発の場合は、人間の仕事のプロセスを補助することに対して存在していることです。人間の仕事のプロセスは、AならばX、BならばYというルールに沿った手続きや条件分岐があります。
さらに人間の仕事には、まるで身体動作のように簡単に説明できない知識が存在しています。
それをコンピューターに対して定義できるように言葉に還元する作業も存在します。

この手続きを備えたシステムと、人間が応答のやり取りを重ねるということから、システムは単なる「箱」や「空間」あるいは「制作物」という存在を超えて、人間と疑似的な会話を行って仕事を助けていくもの、と捉えることができます。
このような特徴はあらゆる産業においてシステム開発という営みのみが備え持つもので、他の産業分野、たとえば印刷産業であっても、機械製造産業、エネルギー産業でも見られないものです。

このようなシステム開発が持つ「特異性」ゆえに、私たち人間が普段慣れ親しんでいる仕事の仕方を当てはめようとすると、そのプロジェクトはたちまちうまくいかなくなります。

人間が営む仕事のプロセスというのは、実際に目にしないとうまくイメージできません。私たち人間の脳は実際に動く様子を見ずにプロセスをイメージすることに向いていないからです。さらに仕事のプロセスの8割は習慣的かつ無意識的に実行されるため、これを言語として表現するには相当の努力が要されます。

このことからシステム開発の「特異性」を発注者とシステム開発会社の両者が理解してコミュニケーションしない限り、要件定義にいくら時間をかけても、取りこぼしや見逃しを防ぐことができません。こうして地雷を抱えてプロジェクトの終盤戦を迎え、検討に漏れがあったことに気付きます。これがブレる原因なのです。

最後に

システム開発の費用を見積もるという作業は、設計者が持つ知識とノウハウを結集させることでもあり、案件とのあくなき闘いでもあります。また人間の顔や個性が一人一人違うように、クライアントの課題も一つとして同じものはありません。どの案件も唯一無二の正解などなく、組織の数だけ課題があるといって良いでしょう。よって設計者は日々目の前の案件と格闘するのです。

それでも日々どこかで案件が炎上しています。業界全体でも、これまでにたくさん失敗を繰り返しましたが、その一方では失敗を克服する新たな手法が生まれて続けていることも事実です。その歴戦の苦労の末に、現在では様々なテクニカルな見積り手法が存在しています。しかしテクニカルなアプローチはそれが有効になり得る環境が整わない限り機能しません。

システム作りをクライアントとシステム開発会社との共同作業と捉え、共通の意識を以て臨むことが重要であることは言うまでもありません。システム開発会社も案件の課題解決に対して最後まで伴走する意気込みが必要であり、その意気込みを空廻りさせないためには、クライアントの意識改革まで踏み込む姿勢が求められるといえるでしょう。

この記事を書いた人について

谷尾 薫

オーシャン・アンド・パートナーズ株式会社　代表取締役
協同組合シー・ソフトウェア（全省庁統一資格Aランク）代表理事

富士通、日本オラクル、フューチャーアーキテクト、独立系ベンチャーを経てオーシャン・アンド・パートナーズ株式会社を設立。2010年中小企業基盤整備機構「創業・ベンチャーフォーラム」にてチャレンジ事例100に選出。

最新記事一覧

• 経営者向け2024.11.18基幹システム再構築とは何か？:価値を生み出す仕組みの再設計
• システム開発2024.11.13見積依存のリスク：発注者が知っておくべき価格依存の弊害
• RFP2024.11.12システム再構築における発注力の重要性とその鍛え方
• RFP2024.11.11IT導入の成功に不可欠なシステム部門の役割拡大と組織づくり