「ITプロジェクトを失敗させない！｜失敗の原因を分析し、対策を考える。」というタイトルの通り、
ITプロジェクトを失敗させない（成功に導く）為に、過去の経験等から失敗の原因と対策をまとめます。
ITプロジェクトの7割は失敗しているとよく耳にしますが、
その原因は何なのでしょうか？
なぜそのITプロジェクトが失敗してしまうのか、
なぜ失敗と判定されてしまうのか、
原因を見極めないといつまで経っても
ITプロジェクトは失敗し続けてしまいます。
目次
まずはITプロジェクトがおかれる環境
○IT業界は基本的にブラックである
・人が足りていない
・終電まで働くことも
・タスクが多い
・複数プロジェクトが同時に進行する
○ITプロジェクトの要件なんていつでも簡単に変えられるんでしょ？
・見積り時点から要件が増える・変わる
・Webにおいては何でも自由自在だと思っている
○経験・勘によるITプロジェクトマネジメント
・過去の経験によると、スケジュールはこれくらい
・勘だけど、まだ間に合うと思う
○IT業界は変化のスピードが圧倒的に早い
・来月でこのバージョンのサポート切れるって
・また新技術出てきたよ
ここ20年程でインターネットが急速に普及し大衆化し、
誰でも簡単にWebサイト・ホームページが作れる時代になり、
ITがより身近なものになってきたからこそ、
ITサービスやWebサイトを作るITプロジェクトって簡単でしょ？
失敗なんてしないでしょ？
やりたいこと自由自在にできるんでしょ？
といったイメージが浸透しているように感じます。
事実として、ITはより日常と密接なものになり、
IOTと呼ばれるモノのインターネット化が進み、
あれもこれもインターネットに接続し、
どこからでも情報を取得でき、逆に送ることも可能になってきています。
初期の頃は、ホームページやポータルサイト、ゲームといった、
ITそのものを利用することがビジネスになっていましたが、
現代においては、ビジネスとITを掛け合わせて、どのように活用するかが求められる時代になっています。
ITプロジェクトの失敗とは
○納期に間に合わない
○できあがったモノが全く違う
○バグが残っておりサービス障害発生
○無事リリースできたが、全く反響がない
○運用開始してみると考慮漏ればかり
ITプロジェクト失敗の原因
○納期に間に合わない
・スケジュールを実際よりも短く見積もってしまった
・度重なる仕様追加、要件変更によって
・嘘の進捗報告がされており、リリース直前に遅れが発覚
・開発者がいなくなった
・リスクの想定ができておらず、対処に遅れた
○できあがったモノが全く違う
・要求事項から要件定義、要件定義から設計への落とし込みを全く確認していなかった
・プロジェクトの目的、目標がプロジェクトチームに共有されていなかった
・構築実行フェーズにおいて成果物を元にした進捗確認をしていなかった
○バグが残っておりサービス障害発生
・設計レビューを実施せず、設計ミスに気がつかなかった
・ソースレビューがされておらず、バグに気がつかなかった
・テスト設計レビューをせず、ケース漏れに気がつかなかった
・正常系のみのテストを実施し、異常系のテストが漏れていた
・テストによってバグが大量に出たが、納期を遅らせることができず、潰しきれなかった
○無事リリースできたが、全く反響がない
・目的が明確じゃなかった
・要件定義時点で目的がずれてしまっていた
・設計時点で構築しやすい仕様に変更してしまった
○運用開始してみると考慮漏ればかり
・業務設計、運用設計がされていなかった
・業務を理解しないまま、システムを作ることを目的としてしまった
ITプロジェクトを失敗させない為の対策
○納期に間に合わない
・スケジュールを実際よりも短く見積もってしまった
→WBSを作成し、タスクの洗い出し漏れをなくす
始めの計画段階から、ゴールまでの全てのタスクを詳細に分解し、洗い出せることが理想だが、現実的でない為、段階的詳細化を行う。
→スケジューリングする際に適度にバッファを設ける
ビジネスにおいてスピードを求められるのは当然だが、失敗のリスクを少しでも減らす為に、適度なバッファは必要である。
外注する際は、キツキツに組んだ後に、各工程の移行時や各マイルストーンにバッファを設けると良い。
・度重なる仕様追加、要件変更によって
→変更管理を実施し、なし崩し状態をやめ、トレードオフをしっかりやる
変更管理を行うことで仕様追加、要件変更がオフィシャルなものとなり、担当者ベースでの合意で自らの首を絞めることを回避させることができる
また、この仕様追加、仕様変更を行う場合、あれをやめなければできないといったトレードオフもしやすくなる
・嘘の進捗報告がされており、リリース直前に遅れが発覚
→信頼関係と見える化
まずは嘘がなく正直な話ができる信頼関係を築く必要がある
その上で、ガントチャートなどを用いて日々の進捗報告の見える化を行う
・開発者がいなくなった
→モチベーション向上のマネジメントを
辛くてもモチベーションが維持できている内は責任感を持って最後まで取り組むものである為、褒賞が難しくても、差し入れや飲みに行くなど、モチベーション向上のマネジメントが必要である
それでも、本人の意思はコントロールしようがない為、最悪の場合を想定して、バックアップ体制を構築できると良い
・リスクの想定ができておらず、対処に遅れた
→事前にリスクの洗い出しを行い対策を立てる
計画フェーズで過去のプロジェクトからの教訓や想像力を総動員し、事前にリスクを洗い出し、それらに対して、対策を立てておくと良いでしょう
○できあがったモノが全く違う
・要求事項から要件定義、要件定義から設計への落とし込みを全く確認していなかった
→要求事項のトレーサビリティを行う
定義した要件が実現されれば要求事項は満たされるのか？設計した内容が実現されれば要件は満たされるのか？と、設計時点とテスト時点でトレーサビリティを行う
・プロジェクトの目的、目標がプロジェクトチームに共有されていなかった
→プロジェクト憲章を作成し、プロジェクトメンバーを集めたキックオフを開催する
・構築実行フェーズにおいて成果物を元にした進捗確認をしていなかった
→ガントチャート上の進捗報告のみではなく、定期的に対面で成果物ベースの進捗確認会を実施する
○バグが残っておりサービス障害発生
・設計レビューを実施せず、設計ミスに気がつかなかった
→設計レビューを実施する
完璧な人は存在せず、他者の目を入れることは大切なことである
・ソースレビューがされておらず、バグに気がつかなかった
→ソースレビューを実施する
完璧な人は存在せず、他者の目を入れることは大切なことである
・テスト設計レビューをせず、ケース漏れに気がつかなかった
→テスト設計レビューを実施する
完璧な人は存在せず、他者の目を入れることは大切なことである
・正常系のみのテストを実施し、異常系のテストが漏れていた
→必ず異常系のテストを実施する
正常系のテストのみでテストを完了する概念を無くす
想定外の操作や処理は必ず起こるものである
・テストによってバグが大量に出たが、納期を遅らせることができず、潰しきれなかった
→納期を遅らせるか、リリース対象の機能を絞る
バグが大量に出ており潰しきれない場合、その事実を正直に伝え、納期を遅らせることが最善である。レアケースでしか発生しないが重大なバグがあるにも関わらず、担当者判断で大丈夫だろ、とリリース判断してしまうとそれが命取りになる。
どうしても納期を遅らせられない場合、リリース対象の機能を絞る調整をすべきである。全ての機能がリリース時点で必要なケースは稀である。
○無事リリースできたが、全く反響がない
・目的が明確じゃなかった
→プロジェクト開始時に必ず目的を明確にする
何の為にするプロジェクトなのか？なぜプロジェクトを実施するのかを明確にすべきである。サイトリニューアルも目的が集客改善なのか、ユーザビリティ改善なのか、デザイン改善なのか、新技術導入なのかで、実施すべき内容が全く違う。
・要件定義時点で目的がずれてしまっていた
→目的のトレーサビリティを行う
定義した要求・要件が実現されれば目的は果たされるのか？と要件定義、設計、テスト時にトレーサビリティを実施する。
・設計時点で構築しやすい仕様に変更してしまった
→目的の共有と変更管理の徹底
目的を共有することで、いくら構築しやすい仕様だとしても、目的が達成されないものであれば採用できないと判断ができるようになる。また、変更管理を徹底することで、勝手な仕様変更をしにくい環境を作る。
○運用開始してみると考慮漏ればかり
・業務設計、運用設計がされていなかった
→業務設計、運用設計を実施し、運用担当者にレビューしてもらう
対象の業務や運用に沿わないものであれば、いくら品質が高く、ハイパフォーマンスな、最新技術モリモリだとしても、使えないサービス・システムである。
業務フローや運用フローを用いて設計し、運用担当者に必ずレビューしてもらうようにすべき。
・業務を理解しないまま、システムを作ることを目的としてしまった
→プロジェクトの目的をぶらさない
目的を明確にし、プロジェクトメンバー全員で共有し、目的のトレーサビリティを行う
最後に
冒頭にも記載した通り、
誰でも簡単にWebサイト・ホームページが作れる時代になり、
ITがより身近なものになってきたからこそ、
ITサービスやWebサイトを作るのって簡単でしょ？
ITプロジェクト失敗しないでしょ？
やりたいこと自由自在にできるんでしょ？
といったイメージが浸透しております。
しかし、一方で、ビジネスと密接に関わるIT活用が求められており、
ITサービスやWebサイトが果たす役割も変わり、
ITプロジェクトは複雑さが増してきていると思われます。
7割は失敗すると言われるITプロジェクトを成功に導くため、
少しでも参考になれば幸いです。
・・・と、偉そうに書いてますが、
僕もITプロジェクト実務者の一人なので、
失敗させないように取り組んでいこうと思います。
合わせて読んでいただきたい「リスクマネジメント」に関する記事です。
