ITプロジェクトに正解はない。しかし間違いはある――失敗へ向かう「下りのエスカレーター」は、最初の判断から始まる
ITプロジェクトの失敗について語られるとき、よく挙がるのがこんな声です。
- 「人手が足りなかった」
- 「スケジュールが厳しすぎた」
- 「ベンダの技術力が不足していた」
もちろん、それらが原因になることもあります。
しかし20年以上にわたり様々なITプロジェクトを見てきた立場からすると、もっと根本的な問題があると感じています。
それは、進む方向そのものを間違えてしまうことです。
プロジェクトが炎上している現場に行くと、関係者は決して怠けていません。むしろ逆です。
- 休日返上で働いている
- 夜遅くまで会議をしている
- 追加予算を確保し、人員も増やしている
それでも状況は改善しない。なぜでしょうか。
彼らが乗っているのは、上りのエスカレーターではないからです。失敗へ向かう、下りのエスカレーターなのです。
本人たちは全力で走っています。しかし進む方向そのものが間違っているため、努力するほど失敗へ近づいてしまいます。
私はこれまで、そんなプロジェクトを何度も見てきました。そしてその原因をたどると、ほぼ例外なく「判断」の問題に行き着くのです。
ITプロジェクトは「判断」の連続である
多くの人は、ITプロジェクトを「技術の話」だと思っています。しかし実際は違います。
ITプロジェクトとは、判断の連続です。たとえば、こんな判断が次々と求められます。
- パッケージを導入するのか、自社開発するのか
- パッケージなら、何を選ぶのか
- どのベンダをパートナーとして選ぶのか
- クラウドを採用するのか。どの技術基盤を選ぶのか
- どこまで標準化し、どこまで独自仕様を認めるのか
- 何を優先し、何を諦めるのか
- セキュリティにどこまで投資するか。どの程度の稼働率を求めるか
これらはすべて「判断」です。しかも、その一つひとつが数年後のシステムの姿や事業競争力を左右します。
ITプロジェクトとは、システムを作る活動ではなく、判断を積み重ねる活動なのです。
正解はない。しかし、間違いはある
重要なのは、ITプロジェクトに「唯一の正解」は存在しないということです。
同じ業種・同じ規模であっても、同じシステムを導入すれば成功するわけではありません。
- パッケージ導入が正解になる会社もある
- 自社開発が正解になる会社もある
- クラウドが向いている会社もあれば、そうでない会社もある
答えは企業の状況によって変わります。だから私は、「これが正解です」と断言することはほとんどありません。
しかし一方で、間違いは確かに存在します。それも、かなりの確率で失敗につながる間違いが。
たとえば、こんな判断です。
- 予算を決めずにプロジェクトを始める
- 責任者を曖昧にしたまま進める
- 現場の要望をすべて取り込もうとする
- ベンダに判断を丸投げする
- 技術選定を流行だけで決める
こうした判断は、その瞬間には合理的に見えることがあります。
しかし経験上、その先に待っている結果（炎上）はある程度予測できます。
技術選定は、時に勝敗そのものを決める
ITプロジェクトでは、「どの技術を選ぶか」「どの製品・アーキテクチャを採用するか」といった判断が行われます。
その際、性能・コスト・開発スピードといった指標で比較しがちです。もちろん、それらは重要です。
しかし本当に重要なのは、その選択が3年後・5年後にどのような結果をもたらすか、という長期的な視点です。
開戦当初は「正しい判断」に見えた
第二次世界大戦中の航空機開発は、この問題を考える上で示唆に富む事例です。
日本軍機は軽量化を徹底し、機動力と航続距離を重視しました。一方で米軍機は、多少重くなっても頑丈さ・整備性・生産性を優先しました。
開戦当初だけを見れば、日本軍の判断は成功に見えます。零戦は高い機動力を誇り、多くの空戦で優位に立ちました。
しかし長期戦で求められたものは違っていた
戦争が長期化すると、状況は一変します。
- 被弾しても帰還できる
- 整備しやすい
- 大量生産しやすい
- 搭乗員を育成しやすい
こうした特性を持つ米軍機の設計思想が、次第に決定的な優位性となって現れてきたのです。
問題は性能ではなく「設計思想」だった
ここで言いたいのは、日本軍の判断が「間違いだった」ということではありません。当時の制約条件や戦略を考えれば、合理的な側面もあったでしょう。
しかし結果として、短期戦に強い設計思想と長期戦に強い設計思想では、戦争全体を通じて大きな差が生まれたという事実があります。
零戦は空戦では強かった。しかし「長期戦」という下りのエスカレーターに、最初から乗ってしまっていたのです。
ITでも同じことが起きます。導入時には高評価だった技術や製品が、5年後には組織を苦しめるケースは珍しくありません。
だからこそ「今勝てるか」だけでなく、「将来も戦い続けられるか」という視点が不可欠なのです。
ITシステムでも、同じことが起きる
短期的には合理的に見える判断が、数年後に大きなツケとなって返ってくることがあります。
- 導入時の評価だけで技術を選ぶ
- 開発費の安さだけでベンダを選ぶ
- 目先の使いやすさだけで製品を選ぶ
数年後、気づいたときには——
- 改修が困難になっている
- 保守費用が高騰している
- 技術者が確保できなくなっている
- 特定ベンダへの依存から抜け出せなくなっている
そうした事態に陥っているのです。
技術選定は、経営判断である
技術選定とは、単なる開発手法の話ではありません。企業がどのような未来を選ぶか、という経営判断です。
その判断は、時として勝敗を決するほどの影響力を持ちます。
だからこそ私たちは、技術そのものよりも、「なぜその技術を選ぶのか」という判断の質を重視しています。
ITプロジェクトに正解はありません。しかし、
- 将来の選択肢を狭める判断
- 運用・保守が立ち行かなくなる判断
- 特定ベンダに過度に依存する判断
こうした「避けるべき選択」は確かに存在します。成功する道筋は複数あります。しかし、失敗に向かう道筋もまた、はっきりと存在するのです。
プロジェクトには、無数の分岐点がある
技術選定は分かりやすい例の一つですが、本質はそこだけではありません。プロジェクトには無数の分岐点があります。
- 予算の決め方
- ベンダの選び方
- 責任者の置き方
- 優先順位の付け方
技術選定は、その中の一つに過ぎません。重要なのは、どの分岐点においても「明らかに危険な選択」を避け続けることです。
下りのエスカレーターに乗ってしまうのは、たった一つの大きな失敗ではなく、小さな判断の積み重ねであることが少なくないのです。
「その判断をする前に、相談してほしかった」
私たちは第三者の立場でプロジェクトを見る機会が多くあります。その中で何度も感じることがあります。「なぜその道を選んでしまったのだろう」と。
当事者は真剣です。経営者も現場もベンダも、それぞれ最善を尽くそうとしています。
しかし第三者から見ると、
- 「そのパッケージは御社に合わないのではないか」
- 「そのベンダ選定は危険ではないか」
- 「その技術選定は数年後に大きな苦労を生むのではないか」
と感じる場面があります。そして残念ながら、その懸念が現実になることも少なくありません。
数年後——
- 改修ができなくなった
- 保守費用が高騰した
- 開発会社との関係が悪化した
- 業務がシステムに合わせられず、定着しなかった
そうした結果を目の当たりにするたびに、口惜しい気持ちになります。
なぜなら、適切なアドバイザーが隣にいれば、避けられた可能性が高いからです。
未来を予測することはできません。しかし経験を積んだ人間には、成功する道筋までは分からなくても、危険な道筋は見えることがあります。
だからこそ、第三者の存在には価値があるのです。
ベンダは「作る」ことができる。しかし「判断」は代行できない
誤解していただきたくないのは、第三者が判断を代行するわけではない、ということです。
経営者に代わって決断することはできません。また、それをしてはいけません。
何を優先するのか。どこに投資するのか。どのリスクを受け入れるのか。
それは、経営の責任だからです。
第三者の役割は、
- 判断材料を整理すること
- 選択肢を可視化すること
- リスクを明らかにすること
そして、経営者が自信を持って判断できる状態をつくること。それが、私たちの仕事です。
「判断しない」こともまた、判断である
プロジェクトでは、間違った判断だけでなく、判断しないことも大きな問題になります。
- 関係者の意見がまとまらない
- 誰も責任を取りたくない
- 反対意見が出るのが怖い
その結果、決めるべきことが決まらないまま進んでいきます。しかし問題は自然には消えません。
先送りされた課題は、後工程で何倍ものコストになって返ってきます。
判断しないことは、安全策ではありません。「判断しない」という判断をしているだけなのです。
まとめ――下りのエスカレーターに乗らないために
ITプロジェクトの成功は、優秀な技術者がいるかどうかで決まるわけではありません。
成功を分けるのは、その時々で必要な判断を、適切に下せるかどうかです。
正解はありません。しかし間違いはあります。
そしてその間違いは、後から取り返そうとすると莫大なコストを伴います。
だからこそ、
- 判断を丸投げしない
- 判断を先送りしない
- 判断できないなら、判断できる状態をつくる
それが、下りのエスカレーターに乗らないための最も確実な方法だと、私は考えています。
もし今、貴社のプロジェクトで「決めるべきことが先送りされている」「ベンダの提案が自社に本当に合っているのか不安だ」と感じているならば、ぜひ一度、利害関係のない第三者の視点を取り入れてみてください。
最初のボタンを掛け違える前に立ち止まること。
それこそが、経営者にしかできない最大の「正しい判断」なのです。
設計の前に、体制を整える。そのための一冊。
ホワイトペーパー「次期システム開発体制を立ち上げる前に知っておくべき７つのトレンド」 PDF形式
内製か外注か、ベンダ選定から予算の考え方まで、経営層が押さえておくべきIT体制づくりの要点を７つのトレンドで整理しています。
【読後に得られる視点】
- 内製と外注の使い分けの判断軸が持てるようになります。
- IT投資の予算を「見積」ではなく戦略として決める考え方が分かります。
- ベンダ任せにしない、主導権を握る開発体制の設計方法が分かります。
この記事を書いた人について
-
オーシャン・アンド・パートナーズ株式会社 代表取締役
協同組合シー・ソフトウェア（全省庁統一資格Aランク）代表理事
富士通、日本オラクル、フューチャーアーキテクト、独立系ベンチャーを経てオーシャン・アンド・パートナーズ株式会社を設立。2010年中小企業基盤整備機構「創業・ベンチャーフォーラム」にてチャレンジ事例100に選出。
