想定読者
・炎上プロジェクトを回避したいPM
・避けられない炎上のダメージを如何に小さくするかを知りたい方
・炎上する原因を事前に察知し、きな臭いプロジェクトを避けるようにしたい方
状況
概要
・受託開発案件
・開発期間は1ヶ月半
・要員は自分を含めて4.5人
（2人は入社2ヶ月目の未経験者、0.5人は時間外のヘルプ要員）
・開発工数は想定範囲内（6.7人月）でスタート
・私の立場はPL、PG、新人教育の3つ
・工程は、実装、単体テスト、結合テスト
想定外の状況
開発要員のスキル不足
経験2年（Javaの経験はないが、C#の経験者）の要員だったので、多分大丈夫だと思っていた。
しかし、実際にコーディングさせてみると「あともうちょっとでできます」と言うのだが、1週間たっても終わらない。
最終的にコードをチェックしたら、2割程度しかできていなかったというオチ。
結果的にその人にはテスト周りと新人教育の補佐をしてもらうことになりました。
その分、実装担当者の負担が激増したのは言うまでもない。
想定以上のコーディング量
予定STEP数：8700
実績STEP数：15000
約1.7倍！
理由は、予定STEP数は受託元が算出したもので、過去の実績ベースと思われる。
私の担当したある画面では、1200STEPの予定に対して、3200STEPを実装した。
重複コードがあったんじゃないですか？
と思われる方に弁明したい。
私は可能な限りリファクタリングし、重複コードはなくすようにしていた。
重複したらすぐにメソッドにわけ、小さな処理であっても長くなるなら共通メソッドを作ることを惜しまなかった。
技術不足の壁
これは「開発要員のスキル不足」にも共通するが、私自身のことを主として言いたい。
・実務でのJavaは初めて
・TypeScriptも初めて
・受託元の独自FWを使用したこと（Springベースだが、Springも初めて）
実際、TypeScriptの非同期処理にてこずっていた。
それ以外では技術的にそんなに問題にならなかったが、
慣れるころ（1か月後）には案件も終息するだろうという予測通り、
開発スピードが加速し始めるころには単体テストのバグ修正をしていた。
設計書誤りによる仕様見直し
設計書によっては特に誤りや理解が難しいものもなかったが、
中には明らかに間違っていたものや、仕様理解に苦しむものがあった。
最初は受託元に問い合わせ、仕様を明確にし、
誤りであった場合は修正していた。
しかしこれがマジで半端ないくらい時間を無駄にした！
1.5日で実装完了する予定の画面が、
仕様の明確化（1日）と再設計（1.5日）によって3日に延びたのだ。
さすがにマジでムリゲーだと感じたため、仕様変更による修正をストップした。
これによって、その後は少しは過重労働が減ったのだ。
新人教育の弊害
何もわからない人間に仕事をさせるとき、「すべてを教えなければならない」
もう一度言う、「すべてを教えなければならない」
・単体テスト仕様書はどのように作るか？
・テストケースはどういうケースが必要か？
・どうコーディングするのか？
etc
分からなければ質問が飛んでくるし、自分で調べさせても解決に時間がかかる。
1か月半という短い期間では「成長を待つ」ということができなかったため、
私は作業スピードに対する成果に対してとてもフラストレーションが溜まっていた。
これは避けようがなかったため、下策ではあるが、
私が残業することで追加の作業時間を作り出すという方法をとっていた。
打破した要因
工期の延期と残業
STEP数の大幅な増大、設計書不備による修正が相まって、
1週間ほど納期を伸ばしてもらうことになった。
また、受注してから半月ほどできな臭い匂いがプンプンしてきたので
体がもつ限り残業して仕事をこなすようにし始めていた。
きな臭い匂いは、「開発要員のスキル不足」「新人教育の弊害」によって
予定通りにいかなくなっていることからすぐにわかりました。
仕様確認と変更点を備忘録に残す
当初、仕様確認や変更点のやりとりはメールだけで行っていました。
しかし、画面単位でいくつもでてくるため、画面単位に仕様確認書を作成し、
それをやりとりする方法に変えました。
その仕様確認書には「優先度」をつけてたことと、
回答内容が画面単位で一覧化できるようになったことで確認の手間が少なくなりました。
仕様変更に対応しない
仕様変更や設計不備だった場合、途中からは対応しないことにしました。
とはいえど、対応しなければそもそも機能しないという場合は対応しました。
結果、仕様変更で進まないという状況はなくなっていきました。
残った仕様変更内容は一覧化し、別途対応予定を組みなおして対応することにしたため、
最後は余裕を持って対応できました。
ツールの作成
単体テスト用のCSVファイルを生成するツールを作成
200パターン以上のCSVファイルを手で作っていたら、1日はかかると予測していた。
1ファイル2分×200=400分（約6.7時間）
それに、データの修正やパターンが増えたときに作り直すことに
時間をかけるのはナンセンスだったためツールを自作（約2時間）。
これでサクッと仕上げました。
納品するソースコードをまとめるツールを作成
単体テスト後、仕様変更対応後でソースコードを毎回まとめていたので、
ツールで自動化させました。
使ったのは結合テスト後だけですが、
毎回1時間近くかかっていた作業が5秒で終わりました（笑
このツール作成にかけた時間は、約1時間半です。
トータルではマイナスでしたが、ツールで効率化することの重要性を学べた良い機会でした。
納品ドキュメント（Excel）をA1セルに合わせて、拡大率100％にするツールの作成
180個ほどのファイル数があったので、手作業でするのは面倒だったため、
当然のことながらツールで対応することにしました。
最初はたくましゅくじょさんのサイトにあったツールで対応しました。
これは自フォルダのみだったため、サブフォルダ全てに対応したものを自作しました。
（所要時間1時間半くらい？）
やはり面倒なことはツールにやらせるのが一番です！
意識改革
納期まで半分を過ぎたころ、今のままでは納期に間に合わないことは目に見えていました。
「どうしたら納期に間に合うのか？」を考えた結果、私のしたことは
「会社に泊まり込む」
でした。
これによって、残業時間は少し増えるだろうがそれで工数は足りるのか？
というと足りませんでした。
しかしここで私が変えたかったことは、
「終わらないなぁ（泣）」というメンタルを「絶対に終わらせる！」に変えること
だったのです。
しかし私のこの行動を会社の人々は馬鹿にしました。
『自宅から徒歩で通えるのに、わざわざ会社に泊まる必要があるのか？』と。
※会社は徒歩10分のところにあります。
意識改革のためだと言っても、理解されませんでした。
まぁ、いいですけど。
私としては、とにかくやれることを全てやりきるしかないと思っていました。
結果として、自分のメンタルを強化できて良かったと思っています。
教訓
炎上プロジェクトにしないために、または炎上プロジェクトを回避するための教訓です。
・新人教育を兼ねている案件は、自分が良く知る技術の採用を前提とすること。
・要員のスキルは事前にマッチさせておくこと。
ミスマッチが発覚した場合は速やかに外し、新たな要員を補充すること。
・作業そのものに集中できるよう、作業時間短縮になるツールの導入には積極的であること。
・仕様変更を安易に受け入れないこと。
・見積もり根拠が不明確で、工数感が測れない案件は避けること
コメント