システム開発はなぜ予想よりも長くかかり高くなるのか？

システム開発プロジェクトは、ビル建設とはまるで違うことを、以前以下のエントリに記載しました。

私が知るかぎり、控え目に見ても8割のプロジェクトはスケジュールが遅延し予算も超過します。それでも動けば良いほうで、結局は使えないということになって、時間も費用も無駄になり、関係者を失望させる度合いも驚くほどです。
このような状況は、システム開発の「ある特異性」が理解されず、システムの構築をビル建築事業のように扱う傾向のために起きています 。

その「特異性」とは、システム開発プロジェクトはあらゆる形でまずい方向に進みやすい、ということです。

何も変哲もない小さな案件さえです。例えば友人のフラダンス愛好家の会のための簡単なウェブサイトを作るようなことでさえ、長い非難の応酬と友情を危機にさらす可能性があるのです。友人のためにいくら厚意を払ったとしても、感謝されることすらなく、ただお互い疲弊してしまうということです。つまりシステム開発プロジェクトというのは他の種類のプロジェクトと比べ迷走する傾向が強いのです。

今回はその「特異性」について考察してみます。

システムの要件を前もって定義するのは予想以上に難しい

プロジェクトがまずい状況なったとき、その裏側では起こっていることは殆どこういうことです。

システム会社は顧客が実際に依頼したことを元に仕事を始めます。しかし途中で、顧客が何が欲しいか、について考えを変えてしまうのです。顧客が考えを変えるときに、それがプロジェクトの進行にどのような影響を及ぼすかは、システム会社が頭をかきむしるような状態であっても、それほど深刻に捉えることはありません。

システム会社が頭をかきむしるのは、技術的な骨組を決めてしまったあとで、その変更に対応するためには、骨組からやり直さないといけない、あるいは大がかりな修正が必要ということですが、このような舞台裏の事情を顧客が納得するよううまく説明するのは、とても難しいことです。よってほとんどのケースでは、顧客は舞台裏の苦労を知る機会がなく、考えを変えた自覚も得ないまま、最初の仕様は静かに忘れ去られます。

何故こんなことが起こるかというと、実は何を作る必要があるのか、実際のところ顧客自身も良く分かっていないのです。これがシステム開発の「特異」なところなのです。

「欲しいものなら充分もう分かっている。」これは顧客の口から最初に出てくる一般的なものです。実際に顧客は自分で何が欲しいのか明確な考えを持っているように感じています。しかし心底思っていたとしても、それは実際のプロジェクトの変更可能性にはあまり影響しないものです。

それではシステム開発以外の他所の世界では、どうでしょうか。建築にせよ建設にせよ、自分たちが欲しいものを頼むときに、自分たちが何を作って欲しいのか分からない、ということはありえないでしょう。しかしシステム開発の世界では、どうやら事情が違うようなのです。

いえ、正確にいえば、顧客は自分たちが欲しいものは知っています。だからシステムを発注するのです。しかし自分たちが欲しいシステムを定義し、そのシステムがどう振る舞うかを十分に想像することは、また別の話しです。この「想像」というのが実は難しいのです。

私たちの脳は実際に動く様子を見ずにプロセスをイメージすることに向いていない

建築分野やその他工学的分野は、「モノ」を作ることに関して存在していますが、システム開発では「プロセス」を作ります。システムを作るということは、人間のプロセスを可能にする仕組みを作ることです。「想像」するのが難しいのは「モノ」が動くメカニズムをイメージすることではありません。難しいのは人間のプロセスがどう動くかを明確かつ詳細にイメージすることです。

別の言い方をすればシステムを考える時、私たちは通常システムを考えているのではなく、組織や顧客のための仕事のプロセスと、それを可能にする仕組みを考えているということです。対象が「ヒト」か、「モノ」か、「人間のプロセス」か、というこの違いが、「特異性」を生んでいます。このプロセスをイメージするというのは本当に難しいものです。私たちの脳はプロセスの可視化には向いていないからです。

既存の業務をシステム化する場合であっても「仕事は全く変わらなくて、情報を紙でなくデータベースに記録するだけ。だからプロセスも同じ」というのは正しくありません。人間による行動というレベルで見れば、紙に書くのと、システムに入力するのとでは、全く異なったプロセスです。そういうところに見過ごされがちで、頭をかきむしるような問題がたくさん隠れているのです。

私たちの頭はプロセスをイメージすることが困難なため、プロジェクト開始の時点で想像したシステム要件は実際に必要とされるものと大きく異なっている可能性をふんだんに含んでいます。そして計画段階での間違いや見落としは間違った技術の選択につながり、その間違いを正す為の変更は、時間もコストも高いものにします。

本当の意味で判断すべきポイントは、プロジェクトがある程度進んだ段階で訪れる

次にプロジェクト立ち上げ時に顧客の稟議で語られる「予算は〇〇億円を見込んでいます」について考えてみましょう。この〇〇億円という予算はシステム会社からの概算提示や社内での試算など、何らかの根拠に基づいて役員会に諮られます。

しかし、この段階で出てくる予算は「おそらくこれくらいかかるはずだろうと、計画の時点では想定できる」というレベルの数字であることは少なくありません。計算の根拠となるシステムの「あるべき姿」を定めるのは、前述のように予想以上に難しいからです。

とは言っても、あたりをつけないとプロジェクトとして妥当かどうか判断できません。しかしこの数字は必ず途中で変わるものなのです。〇〇億円で見込んだプロジェクトは、検討を進めれば進めるほど、問題点とその解決策が具体化していきます。その結果、当初〇〇億円でできるかなと思って検討してきたプロジェクトには、いくつかの変更事項と選択枝があることが見えてきます。

つまりプロジェクトがある程度進んだ段階で、本当の意味で判断すべきポイントが訪れるのです。そんなときに、建築や製造などシステム開発以外の他所の世界で言われるマネジメントにこだわっていては（例えば品質、コスト、納期という指標をもってプロジェクトの成功が図られると固執してしまうと）それが破綻してしまったときのセカンドプランも無いという悲惨な状態になってしまいます。

つまりシステム開発プロジェクトでは臨機応変なマネジメントが求められるのです。具体的にはビジネスへの影響度に応じて必要な品質をその都度決める、ビジネスで価値が高い機能の開発コストは投資を補って、さらにスケジュールの遅延を許容する、ビジネスの優先順位に応じて開発対象を柔軟に入れ替える、といった臨機応変さです。

臨機応変とは、日本のお家芸と言われた「ものづくり」の完成度の高さ、これを支えたマネジメント手法から少し視点を離してみる、ということでもあります。

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

谷尾 薫

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

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

最新記事一覧

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