炎上プロジェクトが生まれる理由を考えてみた

いい加減炎上プロジェクト*1に嫌気がさしてきました。

私が関わってきたシステム開発プロジェクトは、だいたい炎上していることが多いのです。「お前の会社が悪い」というご指摘はご尤もです。

炎上プロジェクトに入ると精神的に止んでる人がいるわ、会社に来なくなっちゃう人が出るわで色々と大変です。こんな不幸をこれ以上世に生み出さないためにどうして炎上プロジェクトが生まれてしまうのか考察していきたいと思います。その上で未然に防ぐ方法を考えていきたいです。

（いや、、、割とマジで考えていきたい。炎上プロジェクトってすごい悲惨です。不幸しか生み出さない。。。）

*1） システム開発プロジェクトにおける炎上とは、遅延が続き仕事が回らなくなっている状態。あらゆる工程が並行して走り、開発現場は大混乱している。

　　　　

では、早速炎上プロジェクトが生まれる理由を考えていきましょう。

1.スケジュールに実現性がない

そもそもプロジェクトの計画に問題があるパターンです。システムのリリース日が決まっておりそこから逆算して、要件定義・設計・開発のスケジュールが引かれているが、それぞれの工程のスケジュールの長さには根拠がないことが多い。ひどいところは、要件定義・設計・開発を同じ長さでやることになっているプロジェクトなんてあります。

「ソフトウェア開発データ白書の活用*2」によると要件定義に対し、基本設計・詳細設計はそれぞれ2倍、開発は4倍の工数がかかるとあります。

*2）<https://www.ipa.go.jp/files/000004088.pdf>

  適当なスケジュールを引くくらいなら参考にしてほしいです！

2.コミュニケーション不足

システムの設計や開発を行う上で必要な情報をヒアリングせずに勝手作って、作ったものが要求したものと全然違ってました、というパターン。これは話にならない。こんなことするならシステム作るの辞めちまえというぐらいひどい。分からないことは、聞きにいきましょう。

しかし、気を付けていても防げない場合もあります。それは、タスクの影響度がわからず、関係するチームへのコミュニケーションができなかった場合です。開発しているプログラム設計が変わったので、プログラムの修正し、一旦はよしと思われたが、後々データ移行に影響がでて失敗したなんてことはよくあります。。。

これは開発者のスキル不足とも言えるかもしれません。。。

3.成果物がない、もしくは成果物の品質が低い

そもそも要件定義で何を作るのか決めていなかったために起こる悲劇です。

要件定義書に決まってるのですが、いざ中身を空けてみると当たり前のことしか書いていない。設計のインプットになるレベルに達していない場合があります。

（システムのシの字も分からないコンサルタントが要件定義をすると大体こんな出来になっている）

そうなると設計者が尻ぬぐいをすることになり、途端にスケジュールが破たんします。個人的には、要件定義は設計に少しぐらい踏み込んでいるぐらいがいいと思います。

4.開発品質が悪い

ここで言う開発とは、プログラムを書くところから単体テストまでを意味しています。開発では、プログラム中のロジックを全てクリアするようにテストするべきと思いますが、単体テストで見つけるべきバグが、後続の結合テストや総合テストで見つかるなんてことがよくあります。。。

結合テストや総合テストを実施している人からすれば単体テストは当然行われており、バグも潰しこまれていることを前提にテスト計画を立てていますから、単体テストレベルのバグが見つかると、大幅な手戻りになります。

真面目に単体テストをしましょう。そしてレビューしましょう！

図解 これ以上やさしく書けない プロジェクトマネジメントのトリセツ (Panda Publishing)

今日はここまでにしたいと思います。

また、明日から炎上プロジェクトに戻ることになります。

鬱な気分です。

3連休とれただけでもマシかもしれませんが。。。