システム開発プロジェクト失敗事例の理由と成功させる秘訣

こんにちは！

ITエンジニア・webディレクター・webデザイナーなどのIT人材の自立・キャリアを支援するITプロパートナーズのCTOの柳澤（やなぎさわ）です。

弊社は、独立精神旺盛な優秀なエンジニアの方々の独立・起業サポートや、フリーランス支援を行っている会社です。

現在、転職市場に現れない優秀なエンジニアを獲得する方法を無料プレゼント中です。

こちらのジョブウィズでは、企業の新規事業開発担当者の方や、システム開発責任者の方、事業責任者の方達に向けて、事業開発のコツや、自社プロダクトやWebサービスを立ち上げる際にポイントや注意点について、弊社ノウハウを包み隠さずにお伝えしています。

さて、今回はシステム開発についてです。

システム開発で失敗した、という話を耳にした経験のある方は多いでしょう。

日本のIT業界では、多少の自虐と開き直りの意味も含めて「成功するシステム開発は全体で3割。7割は失敗する」という言葉が聞かれます。

北海道にある国立の医学大学や日本を代表するメガバンク(青いところ)など、「しっかりとした組織」が発注主になってもシステム開発に失敗することもあるのです。

そこで今回は、システム開発失敗の悲劇を少しでも減らすために、その理由について見ていきたいと思います。

システム開発の現場のリアル

「案件を炎上させたくない。トラブルなくプロジェクト成功させたい」とシステム開発に関わる全ての方がそう願ってシステム開発に携わると思います。

しかし、残念なことに多くのシステム開発プロジェクトは炎上します。

ITエンジニアの中でも、システムのパーツであるプログラムを作成・コーディングするプログラマーの方々は少し異なる想いを持ってプロジェクトに参画してくることが多いです。

彼らはその役割上、プロジェクトの最初からいるのではなく途中段階から参画してきますが、彼らが考えているのは「このプロジェクトは炎上案件かどうか」。

つまり、彼らの感覚で言えば炎上案件があるのは当たり前で、目下の関心は自分の案件は炎上していないか、楽しい楽しいデスマーチが待ち受けていないかと言う現状があります。

それがシステム開発の現実です。

システム開発のデスマーチって？

ところで、デスマーチ略してデスマはIT業界の闇として有名ですが言葉が独り歩きしている印象もあるので、一応、整理しておきましょう。

デスマーチは睡眠を削るなどのワークライフバランスを崩して仕事をする、という話とは異なります。

マーチとは行進という意味ですが、ここでは案件を前進させる、ということを意味しています。

冒頭でも少し触れた青い銀行の炎上案件などが典型例ですが、業務とクリティカルに関わるシステムの更改などは、多少のトラブルも目を瞑ってプロジェクトを前進させることが多いです。

一刻も早く案件を終了させ、システムを稼働させたいですからね。

しかし、トラブルをトラブルとして放置しては前進させられませんので、その分トラブル対処のため、あるいは解決に要した日数分の遅れを取り戻すために要員を追加、つまり追加投資をするのが通常です。

しかし、この追加投資が厄介で、追加投資した分より失敗させられない、という気持ちが関係者の間で強まります。

ところが要員が増えるということはそれだけプロジェクトの管理が複雑になっていくということでもあり、返ってトラブルが発生するリスクも高まることを意味します。

実際、追加要員の認識ズレを起因とする手戻りは非常によくあることです。

そして、その手戻りで遅れた分を追加要員投入で取り戻そうとすると……と、いったエンドレスゲームに入ってしまったプロジェクトのことをデスマーチと呼びます。

コストだけ雪だるま式に膨らみ、なにかしらプロジェクトは前進しているらしいが、いつまで経っても目に見える成果が上がってこない。

そもそも、いまどの辺りを進んでいるのか、ゴールに近いのかそれともまだまだスタート付近なのかも、誰も確証を持っている訳ではないが重要なシステムの開発プロジェクトで予算も大量に投入したので、今更止めようとは誰も言えない、というのがデスマーチの姿です。

だいたいのデスマーチは、これ以上はコスト的に耐えられないというタイミングで幕引きを図られるのですが、決して終了ではなく、凍結あるいは延期という形になることが多いです。

大量の資金と時間をかけたプロジェクトをなかったことにはできない、という無念さがにじみ出てくるようです。

資金力があり、是が非でもやり遂げなくてはいけない、という状況にあるところだと、第二次開発という形でリスタートの体裁を取りつつ、中身は一新ということもあります。

そして、雪だるま式に膨らんだコストの扱いを巡って、システム発注側とシステム開発側で裁判になることも多いです。

誰が悪かったのか、なにが原因でここまでコストが膨れ上がったか、裁判の中から明らかになることが多いため、案件に関わらなかったシステム発注を検討している方やITエンジニアからすると、非常に学ぶことが多いです。

しかし、当事者たちからすると、デスマーチからの法廷闘争と、これほど辛い体験もなかなかないでしょう。

ちなみですが、プロジェクト渡りに慣れたフリーランスの方だと、求人募集状況を見て、炎上案件と思われる案件を避けたり、逆にデスマーチ化した案件は人が集まらないのでその分払いが良くなるため、むしろ積極的に炎上案件に飛び込んだりする方もいます。

ITエンジニアにとって案件の炎上は日常的風景とまではいかなくても、取り立てて騒ぐような特別なことでもないのです。

全体的によく見られるシステム開発の失敗理由

では、システム開発の失敗の現場について分かってきたところで、失敗の理由を見ていきたいと思います。

①見積もりが曖昧

まず、よく聞かれるのは「見積もりが甘かった」という意見です。

工数やスケジュールについて、予想以上にかかってしまい、まったく予定通りにプロジェクトが進まずご破算になった、あるいはスケジュールを予定通りにするために増員した結果、デスマーチ化してしまった、というのはよく見る失敗の原因です。

②発注者と開発側のコミュニケーション不足

スケジュールが狂う原因の一つとして、システム発注側と開発側の意思疎通のミスというのが挙げられます。

発注側と開発側で思い描いていた像が異なっていため、手戻りが多発する、そもそもチェックポイントとなるべきタイミングで必要な会話が行われておらず、プロジェクト終盤でそもそも論が出てきて終了間際から一転、根本から見直し、という例も中にはあります。

③求められている技術力が高い

そして、システム開発側の体制に対して求められている技術力、処理速度が高すぎるということもあります。

今AIが話題だからと言って、どこの開発会社でも簡単に仮想サーバーのAI監視ができるわけではありません。

AIが得意な会社であれば可能でしょうけれど、大規模DB構築が得意な会社がAIも得意とは限りません。

このアンマッチが不幸な結末を招くことも多いのです。

さてここからは、多かったシステム開発失敗の要因とその事例について見ていきましょう。

【発注側の視点！】システム開発失敗の要因と事例

上では、全体から見たシステム開発失敗について見てきましたが、今度は一歩踏み込み、システム発注者側の視点でなぜシステム開発に失敗してしまうのか見ていきます。

①システム開発側が何を言っているのかわからない

発注側から見てシステム開発の失敗の原因だと思うものとして一番多いのは、システム開発側がなにを言っているかわからない、提示されたドキュメントの意味がわからないまま進んでしまう、というものです。

②開発側に期待している仕様が伝わっていない

また、似たようなところで、業務について説明してシステムになにを求めているのかも伝えたつもりなのに、開発側が十分に理解していない、あるいはミスリードや思い込みで、勝手な仕様を策定して構築を始めてしまった、というものです。

発注側にも分かるような段階になってから、思っていたのと異なったシステムか作られようとしていることに気が付いてしまった、となると相当な手戻りが発生します。

再度、認識合せするときも、相当気まずい中で行わなければならず、一度で理解できなかったことを二度目で理解してもらえる保証もなく、前回よりはマシとはいえどもイメージと異なったままということもしばしばです。

また、デスマーチ化していなくても規模の大きい案件ですと、複数のIT企業が参画します。

すると管理が複雑、更に縦割りになってしまい発注側の意志が上手く伝播しないし、空中分解しないように組織維持ばかりに注力していて、システム開発が遅々として進んでおらず、工数ばっかり食っているように見えることも多いです。

③結果、コスパの悪いシステムになってしまう

逆に、システムについて理解が足りないところを開発側に補って欲しかったのに、積極的な提案や十分なフォローをしてくれず、せっかく新しいシステムにしたのにも関わらず、従前のシステムからの進化を感じ取れず失敗だと思っている、という意見もあります。

システム開発の初期段階である要件定義の策定など、システムの方針決めについてプロであるITエンジニアの知見を活かせてくれなかった、という不満です。

動くシステムになっただけ良かったけれど、コストパフォーマンスが悪く、総評としては失敗ということになります。

【開発側の視点】システム開発失敗の要因と事例

今度は立場をひっくり返して、システム開発する側の視点に立って、システム開発の失敗を見ていきましょう。

①発注側の担当者の対応

一番、開発側が恐れているのは担当者の意識です。

よくあるのが、経営層はシステム化に乗り気で前のめりで提案を聞いてくれたが、実際の担当者がそこまで乗り気ではなく、ひどい場合だと、「素人には分からないので、専門家に任せたい」という建前で丸投げに近い態度をとってくる、あるいは開発側との間に一線を引きたがる場合があります。

丸投げされて良いモノをお願いします、と言われても、なにを良いと思っているのか価値観が分からないままでは良いモノを作ることは不可能です。

仕方なく、とりあえず案を作っては見るもののダメ出しを受けることになり、開発側の士気がダウンすると同時に、発注側に対して悪印象を抱くこともしばしばです。

更に計画段階で余計な時間を使ってしまい、後々の実装段階など本当に時間がかかるステップの時間が足りなくなる、ということも多いです。

②橋渡し役がいない

また、発注側担当者は、開発側がなにを求めているのか理解していない、と感じることも少なくありません。

発注側担当者に求めているのは、極論すると一つだけです。

それはずばり、システムに対する発注側ユーザー、つまり本当にシステムを使う人と開発側の橋渡し役です。

ユーザーのニーズを明確にして伝えてくれることを期待しているのに、社内の関係部署を上手く巻き込めていないため、正しい要望が見えず仕様を定められない。

発注側担当者の求めに応じた仕様で構築を進めたら、ユーザー部署から見直しが入って手戻りになった、というのはよくあることです。

③非現実的な要望

他にも、発注側がシステム開発について知識不足なため非現実的な要望を提示してくる、という不満も多いです。

開発規模に対して小さすぎる予算枠、短すぎるスケジュール、そして構築の途中で唐突に発生する機能の追加要求など、わがまま放題な顧客は少なくありません。

その顧客に振り回されてあらぬ方向にシステム開発が転がり出す、ということも多いです。

④打ち合わせの機会が少ない

そして、システム開発について、担当者が他の業務と兼務しているなどの理由で打ち合わせする機会が少ない、最低限の予算しか用意していないのに、更に値切る気が満々といった風な、「システム投資はコストでしかない」という考えが強くシステム開発に対して十分な支援を行ってくれない発注側が多いという不満も多いです。

確かにシステム開発そのものが直接的な利益を生むことはほとんどないですが、良い成果を出すためにはそれ相応の環境が必要なのに用意されていない、と感じることが多いと言う声もあります。

お互いに共通しているシステム開発失敗要因

お互いに共通するシステム開発失敗の要因はなんといっても双方の認識不足です。

システム開発側は受注側の業務について理解不足や思い込みでシステム開発を進めてしまう。

受注側もシステム開発に関する知識不足のため、必要なタイミングで必要な情報を提供できないということが多いです。

それらが積み重なると、開発速度の遅延、成果物、もっと言えば構築されたシステムの受け取り拒否などの問題へと発展します。

本来であれば、コミュニケーションの場を設けることで、認識不足を摘み取るべきですが、開発側がなにを言っているかわからないといった受注側の不満、あるいは担当者多忙などの理由で会ってくれないという開発側の嘆きから分かるように、打ち合わせの機会が十分にない、あっても認識合せが十分に出来ていない、ということが多いです。

では、どのようにシステム開発を成功させれば良いのでしょうか。

システム開発を成功させるためには

システム開発を成功させるために必要なことは、まずはシステム受注側・開発側双方で十分にコミュニケーションができる場を持つことが第一です。

定例会を開く、チャックポイントを明確にするなど、プロジェクト当初から認識ズレを防ぐ施策を行う事が重要です。そ

の上で大切なのは、発注側の場合はメンバーの顔触れをどうするかです。

システムについて分かっていないよりも分かっている人の方が良いですが、それよりも重要なのは、システムでなにを実現したいのか、どうしたいのかビジョンが明確に描け、そして強いリーダーシップを発揮して、迷ったときに決断できる人を中心に置いた方が良いでしょう。

また関係者が増えすぎると船頭多くして船山に上るになるので、システム化対象業務について詳しい方などキーパーソン数名で固めた少数精鋭で進めるべきです。

そして、お客様だと無理難題を開発側に押し付けるだけでなく、歩み寄るのも大切です。

一方で開発側は、なにをして欲しいのか、なにができて、なにができないのか明確かつ、ITエンジニアではない方にも丁寧に説明することが重要です。

発注側担当者の動きが悪いのであれば、動き方が変わる様に誘導するのもITエンジニアの仕事のうちです。

まとめ

今回はシステム開発の失敗についてみてきました。

成功の秘訣ももちろん大切です。

しかし、100の成功も1の失敗で全てが崩れることがあるため、失敗の方を理解する方がより重要です。

みなさんもシステム開発で悲劇を見ないで済むように、ご注意ください。

この記事が皆様のお役に立てば幸いです。