プロジェクトはなぜ失敗してしまうのか？

はじめに

こんにちは！
アットマーク・テクノロジー株式会社の酒井です

今回は、プロジェクトはなぜ失敗してしまうのか？成功に導くためにはどうすればよいかといった議題について、自分の過去の経験をふまえ考えて行こうと思います。

要件定義・設計の甘さが要因で失敗するITプロジェクトが多い

ITプロジェクトの成功割合

成功：52.8%
失敗：47.2%
"日経コンピュータ2018年調べ"

ITプロジェクトの約半数が失敗して、期待した成果を得られずに終了している
失敗要因の6割は上流工程にあるといわれる（要件定義、設計の不備）

※私自身も何度かプロジェクト渡り歩いてきましたが、要件定義段階での洗い出しや設計の不備でお客様の期待するサービスが不明確になっているであったり、設計書の品質が悪く、結果として納品物の品質も悪くなってしまったということがある。

このことから上流工程のタイミングで、よりよい品質を高めることによりのちにつながる構築フェーズや運用・保守フェーズにおける品質の向上、信頼性の向上や可用性の向上につながったりすると考えます。

上流工程が成功するポイント

ビジネス・エンジニアが相互理解するコミュニケーション

ビジネス層としては...

• どんな課題があるかを探す
• 解決する方針策を示す

といったような、種（設計）をまく

エンジニア層としては...
まかれた種（設計）に対して

• こんな課題もあるか提議する
• こんな機能はどうかと提案をする

といったようなエンジニア目線として設計に対してのアドバイス的なことを行う

それを踏まえ、ビジネス層がエンジニアへの理解を示し、エンジニア層がビジネスへの理解を示すことにより、お互いが目指す方向の不一致がなくなることによって、ビジネスの成功への道のりが開けることとなる。

上流工程 = 課題把握 + 相互理解

ステークホルダ

ビジネス側：

• 使う人：エンドユーザ
  • 開発されたシステムを実際に使用する人のこと
• 企画する人：プロジェクトマネージャ（PM）
  • エンドユーザから要望を吸い上げて企画を整理する
  • SEと協力して要件定義を作る

エンジニア側：

• 作り方を決める人：
  • PMと協力してシステム設計を作る
  • プログラマの開発をマネージする
  • インフラにおける工程でも同じである。用語は変わるだけ
• 構築する人：
  • 設計に沿ってシステムを実装する
  • 手順書に沿って構築する場合もあれば、設計から一貫して行うこともある

ITプロジェクトが失敗してしまう要因について

１．PMとSEのコミュニケーション不足

よくある典型的なパターンだと思います笑
エンドユーザと直接会話をできるPMが、SEとの調整を甘くみていることにより、ユーザーが求めている内容や本来するべきヒアリング事項などをすっとばして、SEに対し丸投げする行為。

こうなってしまっては、顧客評価が下がってしまうだけなので、大前提としてPMとSEのコミュニケーションは最重要事項！

２．PMの思い込み

これもよくあるパターンだと思います。
ユーザにしっかりとヒアリングせずに、今までの経験と勘で細かなワークフローを決めずに設計を進めてしまって、リリース後に問題となることが多い

３．エンジニアの思い込み

これもよくあるパターン
今までの案件からの知見や標準的な知識からの経験則の判断からで、ユーザやPMが思い描いているものと合っているかどうかを聞きそびれてしまう。

システム開発は技術的な問題よりも「企画の不備」で失敗する

目的やゴール設定が曖昧

目指す着地点がない

• 人によって問題意識がずれている
• 関係者がそれぞれ部分最適な要望を言い始める
• 要望が矛盾したり発散して収集が付かなくなる

システム開発だけが目的化している

はやり言葉だけでの目的で取り組んでしまい、潜在的な課題を洗い出せずゴールがないため、PMやエンジニアは混乱してしまう。

システムだけで問題が解決すると考えている

根本の問題が解決しない

• 古い社内制度を変えない
• 非効率な業務を改善しない

目的意識のズレ

ビジネス・エンジニアの目的意識のズレ

	ビジネス側	エンジニア
優先すること	課題解決が最優先	バグ回避が最優先
要件定義のスタンス	柔軟に変更したい	途中変更は避けたい
基本設計のスタンス	エンジニアまかせで大丈夫	言われてない事は設計に反映できない

失敗パターン

ビジネス側
・開発途中でも追加・修正できると考えている
・多少の考慮モレはエンジニアがカバーできると考えている

「とりあえず作ってもらって、後から修正しよう」と考えて、
きちんと要件定義を詰めていない失敗パターンが多い

エンジニア側
・要件定義に書いてない事は反映できない
・使う人を考えずに設計した成果物になってしまう

誰が・どんな風にシステム利用するのか見えず、要件定義のモレを見落としたり、エンジニアが作りやすい設計で開発する失敗パターンが多い

これらの問題を事前に解消することが上流工程の目的

目的意識の共有とコミュニケーションによる相互理解がプロジェクト全体においては最重要である

上流工程の必要性

上流工程の目的

ビジネス側・エンジニア側の共通認識をつくる
””誰の、どんな課題の、どうやって解決をするのか？””
全員がプロジェクトのゴール（目指す着地点はどこか）把握することがとても重要であると考える。

そのため、上流工程で作成される「要件定義書・基本設計書」この品質がプロジェクトの成功の向上につながると考える

要件定義のゴール

大前提！！
ビジネス側の「どんなシステムが欲しいのか？」がエンジニアに伝わる

• プロジェクトの目的、解決したい課題
• どんな機能が必要なのか？
• いつ、だれが、何のためにシステム利用するのか

注意事項

• 要件定義の段階からエンジニアに丸投げをしない
• 要望をすべて記載しない（要求の不一致などを避ける）

基本設計のゴール

エンジニア側の「どんなシステムを作るか？」がビジネス側に伝わること

インフラであれば

• どんな構成を作れればよさそうか
• 機能要求はどの機能をつかって満たせばよいか
• どのように要求と機能をマッチさせていくか

よい上流工程に必要なこと

要件定義から基本設計につながる2W1Hのストーリーが重要

• 要件定義の2W

  • Why：システム開発の目的は何か？（ビジネス側で作成）
    • 現状で困っていること（誰が、何に困っているのか）
    • 目指すゴール（いつまでに、何を目指すのか）
    • 現状とゴールのギャップ（=解決すべき課題）（解決するべき課題はなにか）
  • What：どうやって課題を解決していくのか？（ビジネス側からエンジニアに相談）
    • システム導入後の業務フロー
    • システムに必要な機能一覧
    • システムの使用感（非機能要件）

• 基本設計の1H

  • How：どんなシステムを作るか？（エンジニアからビジネス側に提案）
    • 画面設計（UI/UX設計）
    • 機能設計
    • データ設計

不明確な要件：エンジニア側で使うユーザーのことを考え問題定義

ビジネス側でその内容をうけエンドユーザーに確認

要件定義の進め方

１．ビジネス側で要望をまとめる
２．SEに対して、要望に対する要求を行う
３．SEは受け取った要望に対し検討を行う
４．SEは検討結果を提案としてビジネス側に返す
５．双方が合意形成したら要件として完成する

まとめ

プロジェクトの失敗は、上流工程での様々な要因が起点となり失敗してしまうことが分かりました。もちろん全てが上流工程が原因となってしまうことはありませんが、どちらにしても共通して言えるのがコミュニケーションをしっかりとるということです。