炎上案件を振り返る～何故プロジェクトは炎上するのか～

てるお

炎上案件とは？


・スケジュールが大幅に遅延している
・短納期の割に作業ボリュームが大きい
・メンバーのリソースが足りていない
・有識者がいない
・プロマネやマネージャーの管理能力、調整力がない
など、問題があるプロジェクトのことを指します。
僕は先月までの2ヶ月間、炎上案件を担当していたのですが、この案件が炎上してしまった理由について述べていこうと思います。

1.人材の入れ替わりが激しい


まず一つ目はこれです。炎上案件はとにかく人がコロコロ入れ替わります。
そのせいもあり
・仕様書はあるけど作った人がいない
・環境構築の方法を誰も知らない
・テストデータの作成方法を誰もわからない
・試験を実施しようにも試験環境が誰も出来上がっていない
・まずそもそも仕様書の記載内容が正しいかどうかすら怪しい
といった状況が多発します。
前任者の作った仕様書を僕がレビューしたこともありました笑
自分が一切手を触れていない仕様書のレビューをしろと言われてもハッキリ言って無理です！
また、長く在籍している人がいないせいもあり、以下、2. の理由に繋がります。

2.各作業者のシステムに対する理解が浅い


これが二つ目です。各作業者が皆システムや作業内容についてよくわかっていない状態で作業しています。
何しろ配属初日、まだシステムについて一切何もわかっていない状態で「さぁテストやれ」と言われたのです。
･･･いやいやちょっと待て、何を言っているんだあなたは？
何もわからないのにテストやれなんて無理ですよと言うと、「それじゃあテスト経験者にやり方を聞いてみましょう」
唐突に経験者のAさんという方を捕まえ、通話開始。このときなんと夜の19時です。(定時は9時～18時)
･･･定時後にいきなり呼び出すか普通！？
そんなことを思いながら通話を聞いていたのですが、やはりこれは対面で時間を作ってやらないといけないということで、翌週対面で説明をしていただきました。(配属初日は金曜日です)
その際はもう一人テスト経験者に来ていただき、このお二方から試験の実施方法を教わるのですが、何かどうも教え方もフワフワしています。
おそらくこれ、このお二方もこんな感じで教わったんだと思います。
その後はよくわからないまま試験を進めよくわからないまま試験項目を消化していきます。

そんな中、またしても「おや？」と思わせる事態が起きます。
試験仕様書と設計書の内容が紐付いていないのではないかという話が出てきました。
その際、試験仕様書を作成したのがAさんだというので、聞いてみることに。
僕が設計書を見せると、衝撃の一言が。
え？なんですかこれ？
･･･ん？何言ってるんだ彼は？
Aさんによると、前任者からの引き継ぎがあったそう。
前任者の作成していた仕様書内でもう処理フローの記載ができあがっていたので、それを見て仕様書を作成したのだとか。
なので設計書自体初めて見たし、設計書の内容について聞かれてもわからないそう。
･･･そんなことある？？引き継ぎって普通もっと丁寧にやるもんでしょ？？
もしかして前任者もよくわからずに作ったのか？
そんなことを思いながら解析を行ったのですが、どうやら仕様書の内容は合っていたようです。

ここまでの説明でおわかりいただけたかと思いますが、この案件は業務に関してのキャッチアップが雑です。
みんながみんな目の前の作業をよくわからないままひたすら横に流している状態でした。
システムについてよくわかっていない人がよくわかっていないままレクチャーしてよくわかっていないまま作業を進めています。
また、人材の入れ替わりが激しいのもあり、過去にその作業を経験してよく理解している人が離脱してしまっているなんてこともありました。
長く在籍している人もいるにはいるのですが、システムの規模が大きすぎるのもあり、そのすべてを理解しているわけではないようです。
このシステムの規模が大きすぎるというのが、以下、3. の理由に繋がります。

3.リポジトリがゴチャゴチャ


各種資料の保管場所をリポジトリというのですが、資料の数が膨大なのもあり、どこに何が保管されているのかがわからないのです。
2. で述べた設計書も、当時のPMから渡されてようやくその存在に気づけたので･･･

試験実施するにあたり、仕様書や設計書などの各種資料内容から試験内容を考えなければいけないのですが、まずその各種資料を探すところから始まります。
下手すりゃ資料の調査だけで2日終わることもありました。
更にタチが悪いのが、資料に書かれている内容が正しいとは限らないんですよね。
2. でも述べたように、みんなよくわからないまま資料を作成しているので、資料に書かれている内容が間違えているなんてこともあり得ます。
その内容が正しいかどうかの精査も必要でした。

4.スケジュールがザル


これは全ての炎上案件に当てはまると思います。スケジュール管理が不適切なのです。
この案件、そもそも2月終了予定だったものがズルズルと先延ばしになった結果3月4月と続いてしまったという経緯があります。
また、試験方法もテストデータも何もわかっていない試験項目を4日で終わらせろという無茶振りをされたこともあります。
結局これは後にリスケになったのですが･･･
その他にも休日出勤している人もザラにいましたし試験内容が難解だったせいで期限を2週間オーバーしてようやくクリアした項目もありました。

5.人手が足りない


これも全ての炎上案件に当てはまりますね。
大規模システムなのでとにかく人手が必要なのですが、ご覧の通り現場の体制がフワフワしているので次々離脱者が出てしまいます。
離脱者が出るたび増員するのですが、雑なキャッチアップで理解が不十分なまま作業を行いそのせいでまた十分な成果を得られずまた離脱者が出る。
そして前任者がやり残した内容をよくわからないまま後任者が引き継ぐ。よくわからないまま引き継いだのでまた期限がズルズル後ろにずれていく。
炎上案件はこの負の無限ループ状態に陥っています。

6.PCのスペックが低い


これは余談的な内容になりますが、PCのスペックがゴミです、カスです。
ローカルディスクの空き容量はなんと237GBしかありません。
PC受け取ってから2週間でもう容量切れになりました。
ローカルディスク上から不要なデータを消去するのにも無駄な時間がかかりましたし、そのせいで作業の進捗が遅れることもありました。
また、キーボードも従来のPCとは異なっており、使いにくいことこの上なかったです。
更に言うと、配属初日にまだ3月入場者用のPCが届いておらず、前任者の使用していたPCをお借りしていたのですが(そもそもこの状況がもう前代未聞･･･)
前任者のPCのCPUはIntel i5です。型落ちです。勿論空き容量はすでに赤くなっていました。
こんなのハッキリ言ってエンジニアに貸与していいPCではありません。
こんなPCを使っていては当然生産性も下がります。
エンジニアに貸与するPCという一番大事なところをケチるからプロジェクトが順調に進まない、これも炎上理由の一つでしょう。

まとめ


今回は僕の経験から炎上案件が何故燃えるのか、その理由について記載していきました。
炎上要因は大きく分けて以下6つです。

  1. 人材の入れ替わりが激しい

  2. 各作業者のシステムに対する理解が浅い

  3. リポジトリがゴチャゴチャ

  4. スケジュールがザル

  5. 人手が足りない

  6. PCのスペックが低い

過去に炎上案件にアサインされたことのある方は身に覚えがあるのではないでしょうか？
これらの要素は独立して発生するのではなく、全ての要素が繋がりあって発生しています。
人材の入れ替わりが激しいから各作業者のシステムに対する理解が浅いし、各作業者のシステムに対する理解が浅くて人手が足りないから期限がズルズル後ろ倒しになるのです。

以上、ご清覧ありがとうございました。

この記事が気に入ったらサポートをしてみませんか？