システム開発のプロジェクトが炎上する理由

システム開発のプロジェクトの成功率は3割と言われており、業界内でのプロジェクト炎上の話題は度々耳にします。私自身もプロジェクト炎上の現場には何度か携わってきました。昨日ツイッター上でこんな投稿をしました。

システム開発のプロジェクトが炎上する理由にはどんなものがあると思いますか？リプ欄でご意見いただければ幸いです。

— 米村歩@日本一残業の少ないIT企業社長 (@yonemura2006) April 12, 2018

皆様から実にたくさんのリプライをいただきました。ご協力いただけた皆様ありがとうございました。

多くの皆さまがプロジェクト炎上経験者の強者のようでして、一言ではまとめきれないほどたくさんの炎上理由が集まりましたので、その内容をこのブログにまとめてみることにしました。

情報が多かったので私なりに少し整理しまして、下記の４つにカテゴリー分類してみることにしました。

会社間での力関係の問題
プロジェクトメンバーの問題
プロジェクトマネージャーの問題
顧客の問題

システム開発のプロジェクトが炎上する理由は、一つの原因によって引き起こされると言うよりは、色々な要因が積み重なった時に炎上となるのかもしれません。多くのプロジェクト炎上経験者の情報を整理・分類することによって、見えてくる共通点や根本的問題もあると思います。

結構有益な情報が集まったと思いますので、今後のシステム開発プロジェクトで炎上を回避するための参考としていただければと思います。

会社間での力関係の問題

４つにカテゴリー分類した中では最も厄介な問題かもしれません。中には解決困難な問題もあり、解決しようとする場合は各社の経営陣クラスの人間が出ていって対応する必要がありそうな問題です。

各社間で政治的な争い事をしている

顧客の課題を解決するためではなく、各社が自分達に有利になるように政治的な争い事を延々と続けている場合があります。複数社が吸収合併されて統合された場合や、子会社・関係会社が自社の利益を確保するために奔走してプロジェクト進行を邪魔してくることがあります。会社間ではなく、部署間での対立の場合もあります。

各社間の利害が絡んだせいで仕様が決まらない

関係各社が自分達の利益ばかり主張してそれぞれ自分勝手な要求ばかり繰り返すので、仕様がいつまで経ってもまとまらない場合があります。全体を見て最適な解決方法ではなく、それぞれが自分達のことだけを考えて争うので利害が対立して仕様が決まりません。

要件定義も未確定なのに納期だけは最初に決まっている

プロジェクト全体の納期だけは最初の時点で決定されているけど、何をやるのか要件定義がいつまで経っても決まらない場合があります。要件定義がどんなに遅延しようとも納期の変更は絶対に認めないようなことが発生すると、後々プロジェクト炎上の要因となります。

上流工程の遅延を下流工程にしわ寄せする

顧客側の要件定義のスケジュールが遅延したのに、プロジェクト全体の納期は変更されずに後工程のフェーズのスケジュールがその分短縮される場合があります。上流工程を遅延させた顧客の責任であるにも関わらず、有無を言わさず後工程を担当する会社にそのしわ寄せを押し付けてくる場合があります。

プロジェクトメンバーの問題

プロジェクトメンバーに問題があることによってシステム開発のプロジェクトが炎上することは確かにあるようですが、プロジェクト炎上の要因としては実はそれほど大きな主因ではありません。プロジェクトメンバーに問題があっても、マネジメントがしっかりしていれば炎上は通常回避できます。

プロジェクトメンバーの技術力が不足している

プロジェクトを遂行するための能力がメンバーに不足している場合があります。SESだと平気で経歴詐称して新人レベルの人間を送り込んでくることが日常茶飯事なので、プロジェクトを遂行するだけの能力を有していないメンバーがプロジェクトに在籍していることはよくあります。

正しい進捗情報を報告しようとしない

エンジニアに限った話ではありませんが、進捗の遅れを隠蔽して嘘の進捗報告をする人は必ず存在します。途中まで順調な進捗報告を受けていたはずなのに、ある時突然全く進捗が進まなくなり、確認してみると問題だらけで全然進捗していないというケースがあります。

問題点があっても隠蔽してしまう

プロジェクト進行に問題発生はつきものであり、問題が発生した場合にはリーダーに適切に報告する必要がありますが、これを隠蔽しようとする人がいます。怒られたくない、面倒くさいことの対応をしたくないという心理からなのか、問題を見つけても見て見ぬふりをしてしまって、後々に問題が膨れ上がってもっと大変な目にあいます。

プロジェクトメンバーが突然いなくなる

客先常駐の現場だとプロジェクトメンバーが突然いなくなることはよくあることです。単純に契約の区切れでいなくなることもありますが、プロジェクトメンバーが途中で嫌になって逃亡してしまうこともあります。陰湿なリーダーが気に入らないメンバーをいじめて追い出すこともあります。

プロジェクトメンバーの入れ替えが頻発している

順調にプロジェクトが炎上してくると、途中で離脱するプロジェクトメンバーが多数発生します。そのために常に入れ替えで新しいメンバーが投入されてくるようになります。この時に投入されるメンバーが技術不足だと燃えているプロジェクトに油を注ぐ結果となります。

プロジェクトマネージャーの問題

プロジェクトが炎上する要因としては、個別のプロジェクトメンバーの問題よりも、マネジメントに失敗しているケースがほとんどだと思われます。多少プロジェクトメンバーに問題があったとしても、リーダーが適切にマネジメントしていれば炎上するようなことにはなりません。

顧客の無茶な要求を引き受けてしまう

顧客から無茶な要求をされたら断らなければなりません。顧客の無茶な要求を引き受けるということは、そのしわ寄せを自分達で引き受けるということです。その結果として自社の従業員に残業を強いる結果になったり、自社の利益が圧迫される結果になったりします。

見積もり範囲外の作業を受けてしまう

顧客から何か依頼をされる時には、適切な料金と適切なスケジュールが必要です。それなのに見積もり範囲外の要求をされた時に断りきれずに受けてしまい、プロジェクトメンバーにそのしわ寄せがいってしまいます。見積もり範囲外の作業を受けるなら、お金と時間の話を顧客としなければなりません。

そもそもの見積もりが誤っている

見積もりに想定外の誤差が発生することは当然ありますが、そもそもの見積もりが誤っている場合があります。経験豊富なマネージャーであればそのようなミスはありませんが、経験の浅い人が見積もりをした時に、前提条件を誤って最初から全然見積もり金額もスケジュールも足りなくなってしまっている場合があります。

スケジュールにバッファが全くない

そんなに正確に見積もろうとしても、想定外の事態というものは必ず発生するものです。そういった想定外の事態まである程度は織り込んだ上で見積もりを行うのが適切なマネジメントです。それをやらずにバッファゼロで見積もりをするということは、一つでも想定外の事態が起きた時点で破綻するということであり、プロジェクト炎上の第一歩となってしまいます。

適切な納期が設定されていない

顧客から強く言われて断りきれずに無理な納期設定をしてしまう場合があります。または無理な納期設定をしないとその仕事を受注できないという場合に、無理を承知で無茶な納期設定をする場合があります。わざとプロジェクトを炎上させているに等しい行為です。

チームメンバーに適切な情報共有がされていない

顧客と打ち合わせして決定した内容をチームメンバーにも適切に共有しなければ、プロジェクト進行がうまくいかないことは当たり前のことですが、これができないリーダーは実際にいます。特に仕様に関する変更事項は即時正確に共有してもらう必要がありますが、それを怠ったために仕様漏れや仕様バグとなって後々炎上することがあります。

仕様未確定のまま製造に先行着手している

要件定義や設計フェーズのスケジュールが遅延してきた時にそれをリカバリーする手段として、仕様未確定だけど先行して製造着手させる手法をとるプロジェクトマネージャーがいます。その場しのぎの対応でしかなく、仕様未確定のため戻り作業も多くなってしまい、後々さらにスケジュールが逼迫することになります。

スケジュール遅延が残業でカバーされている

スケジュールが遅延してきた時にリカバリー方法として、残業でカバーさせようとするプロジェクトマネージャーがいます。しかし残業でカバーという手法はマネジメントではなくサルでもできる愚策です。そのようなリーダーはマネジメント能力がない証拠ですので、慢性的な長時間労働状態となってプロジェクトが炎上しやすい状況となります。

スケジュール遅延を単体テスト簡略化で対応する

製造工程のスケジュールが遅延した時に、そのリカバリー方法として単体テストを簡略化して時間省略しようとする人がいます。単体テストフェーズで少々バグが残存したとしても後工程の結合試験フェーズでバグを抽出しようという安易で愚かな考え方です。ひどい場合には単体テストフェーズが省略されたりします。

プロジェクトメンバーの進捗状況を把握していない

マネジメントの第一歩は正しい情報の把握から始まりますが、プロジェクトマネージャーがそもそもメンバーの進捗状況を把握していない場合があります。最初のうちは進捗をきちんと把握していても、良い感じにプロジェクトが炎上してくるとメンバーの状況を把握する余裕すらなくなり、さらに良い感じにプロジェクトを燃やしていくこととなります。

問題点があっても放置されてしまう

プロジェクト炎上の末期的症状と言えるかもしれません。本来はプロジェクトの問題点や課題を適切に対処していくことも、プロジェクトをスムーズに進行していくために必要な仕事のはずですが、炎上するとそんな余裕は一切なくなり、問題が発生しても見て見ぬふりをするようになってきます。見ないようにしても問題が消えるわけではないので、後で必ずより大きな利息が付いて問題は大きくなり、燃えているプロジェクトに油を注ぐ結果となります。

顧客の問題

システム開発のプロジェクトが炎上する理由は開発会社側の問題ばかりではありません。発注する側の顧客側に問題があってプロジェクトが炎上することも多々あります。

過剰なドキュメントが要求される

顧客説明用の資料として、必要以上に過剰なドキュメントが要求される場合があります。顧客側担当者が自分の上司に説明するために、発注先に過剰な資料を作らせようとすることもあります。こうした顧客の行為はプロジェクト進行の妨げになります。

顧客側で必要なシステムが明確になっていない

システム開発をする前に、そもそもどんなシステムを作りたいのか、作る必要があるのかが明確になっていない場合があります。そのような状況だと要件定義や設計が中々フィックスせずに後工程にしわ寄せされてプロジェクト炎上の要因となります。

途中で何度も仕様がころころ変わる

仕様検討のフェーズで仕様がころころ変わるのは当たり前のことではありますが、仕様検討がフィックスした後にもころころ仕様を変えようとする顧客がいます。顧客のこのような行為はプロジェクトメンバーに過剰な負担をかけますのでプロジェクト炎上の要因となります。

リプレイス案件で要件定義が「現行踏襲」となっている

既存システムをリニューアルする案件の時に、顧客側が仕様の定義で「現行踏襲」を多用することがあります。これは単に仕様を明確にする仕事を顧客側の怠慢で怠っているだけです。本来であれば現行の仕様を確認してドキュメントに明記するべきです。ドキュメントに現行踏襲の記載のあるプロジェクトは後で必ず問題になります。

顧客が仕様決定を先延ばしにする

仕様決定は最終的に顧客側で行ってもらう必要があるのに、いつまで経っても顧客が仕様決定をしようとせずに先延ばしにすることがあります。色々検討するのが面倒だったり時間が取れなかったりというのが理由ですが、単なる顧客側の怠慢です。顧客の怠慢によって後工程を担当しているプロジェクトメンバーに負担をかけることになります。

納期変更を一切認めようとしない

システム開発のプロジェクトには想定外の事態が発生することはつきものです。その想定外の内容によっては納期調整が必要となる場合もありますが、それを顧客が一切認めようとせずに結局無茶なスケジュールで進行してプロジェクトが炎上することがあります。また顧客都合によってプロジェクト進行が遅れる場合もありますが、その場合でも最終的な納期は一切認めようとしない顧客もいます。

過剰なまでに何度も打ち合わせを要求してくる

コミュニケーションは十分に行う必要はありますが、顧客側が単に上司への説明のためだけに、過剰なまでに何度も打ち合わせを要求してくることがありますが、顧客のこのような行為はプロジェクトの円滑な進行の妨げとなります。プロジェクトが炎上している時こそ全力で事態の解決に望むべきですが、そういう時に限って何度も何度も説明のための打ち合わせを要求してきてプロジェクト進行の妨害をしてくることがあります。