なぜプロジェクトが炎上しているのか自分なりに考えてみた

みなさん、こんにちは👋

私は現在SESのエンジニアとしてお客様先に常駐し、とあるプロジェクトに参画しているのですが、そのプロジェクトが絶賛炎上中です。炎が本格的に燃え始めてかれこれ5ヶ月といったところでしょうか。さて、今回はその炎上の原因を自分のポジョンから自分なりに考えてみて、未来の自分への財産としたいと思います。

ちなみに、前提として自分はこの炎上案件に参画していることをネガティブに思っているなんてことは無く、今は個人の時間も体力もあるので1つの経験としてそれなりに楽しんでいます。特に納期前日の「絶対間に合わないけどやれるところまではやらないといけない」みたいな状況の中でフル稼働していると段々頭が冴えてくるあの感覚が好きです。まぁ、BPというポジションのお気楽さもあってこそだとは思いますが。

というわけで本題へ。

案件の概要

• 金融企業向け顧客管理Webアプリの新規開発
• 最終的な納期は今年の11月くらい。しかし、それまでに1ヶ月単位で納期がある。例えば、アプリ全体で100画面あり、今から開発に着手するとすると、10月までに50画面納品、11月までに残りの50画面を納品といった感じ
• ウォーターフォール開発

商流図

自分が属しているのは下請けのN社。

SESなのでプロジェクトの全体像といった情報まで知ることができないのが申し訳ないです。B社やC社がさらに下に仕事を投げている可能性もありますし、金融系の大規模プロジェクトなので商流は図より複雑なきがします。常駐ということでまとめてしまっていますが、厳密に言うと自分もN社から仕事を投げられているみたいなものなので。ただ、自分のいるN社は元請けから渡される設計書をもとに開発からテストまで完結させて納品しているので、自分のおかれているポジションとしては図のような感じでしょうか。

メンバー構成

• PM: 1名, PL: 1名, メンバー: 5〜14名くらいで、私のポジションはメンバー

• PMがプロジェクトを掛け持ちしているため、全体の3割の時間程度しか本プロジェクトに時間が割けない

• プロパーメンバーの中で本開発で使われる言語やFWについての知識があるのはPMのみ

なんか、プロジェクト管理を行うのはPMというイメージでしたが、このプロジェクトにおけるPMは「いるのかいないのか」みたいな感じで、PLが進捗管理などの諸々を行っています。

プロジェクト炎上の原因

外部的な問題から内部的な問題まで思い当たるものを書きたいと思います。ただ注意してほしいのは、これは愚痴とか不満とかそういった類のものではなく、純粋にプロジェクト炎上の原因を分析した結果を書いているだけということ。

それでは本題へ。

1.仕様書に不明点や矛盾点が多すぎる

例えば仕様書ごとにDBのカラム名やデータ型に矛盾があったり、「決定次第記載」という注釈が書かれた仕様書が普通に渡されてきます。現場では該当月になったら納品する分の仕様書がメンバーに渡されて開発を行うみたいな流れになっていたのですが、開発に着手する前に渡された仕様書の不明点や矛盾点の洗い出しから始めなければならず、この段階でもうPLが立てた予定から遅れることになります。

2.仕様書の不明点についての回答が遅すぎる

1で触れた仕様書についての不明点を元請けであるA社にQA表という形で不明点の質問をするのですが、これの返答に2、3週間くらいかかるので、我々の方針として不明点については「全ての仕様書から考えられる最も妥当な方法」で仮実装を行うことになっていました。ただ、仮実装なので引数と戻り値だけ整合性を持たせて中身が空の状態みたいな感じなので、結局のところ元請けの返答後に本実装を行う必要が出てきます。

あたり前のことかもしれませんが、QAの量的に仕様が固まっていないのも同然なので、実装側も「この実装で良いのか」みたいな感じでフワフワしながら開発を進めていくので、進捗は芳しくありません。

仮実装を行わないと実装可能箇所の作業が進まないので仕方のないことではありますが、はっきり言って仮実装部分に割く時間や返答受領後の本実装に伴う実装済み部分の改修も考えると時間を無駄にしている気がしています。

3.デグレ三昧

仕様書のQA受領が納期の1、2週間前という絶妙なタイミングでくるので、モノによっては実装、モノによっては「納期間際で仕様を知らされたので次の開発期間で対応します」という体で未実装のまま納品することになっています。

これの何が問題かというと、システムの整合性が取れていないので納品前の試験で不具合が多発するということ。我々のミッションとして、「20画面納品」となっていた場合、納品前の試験についてはそれぞれの画面についての単体試験はもちろん、20画面について遷移などが正しく行えるかなどの結合試験も行う必要があったので、結合試験の部分で不具合が多発しました。不具合が多発すれば修正も多発します。修正しているはずなのにデグレ三昧。なぜなら我々は整合性のとれた仕様書を手にしていないので。

4.仕様が固まる前に試験仕様書を作成してしまった

我々は仕様書を元に試験仕様書を作成していましたが、これまで書いたとおり、仕様が固まっているとは言いにくい状況にもかかわらず、試験仕様書の作成を行ってしまったことも問題かなと思いました。現実は仕様書の変更と開発が同時に行われているような状況だったので、仕様書の変更に試験仕様書がついてきておらず、試験時に仕様から消えた部分のテスト項目や項目漏れしている部分もあったりでテストという納期間際の段階で試験仕様書の修正を行うなど無駄なタスクが追加されたことも炎上の一因だと思いました。

「なぜ仕様が固まってから試験仕様書を作成しないのか」という疑問があるかもしれませんが、よくある受託開発では品質保証の意味として試験項目やそのエビデンスも納品する必要があり、開発の流れ的には「試験仕様書作成→開発→テスト」というのが妥当かなと思うのですが、我々の開発チームは基本的に人員不足という問題を抱えており、「試験仕様書作成の担当者は試験仕様書作成完了後に開発に加わる」ことになっているので、とにかく早めに試験仕様書を作成して開発に加わる必要がありました。そこに「仕様が固まっていない」という問題が重なってしまい、試験仕様書作成者自身も一旦開発に回ってしまうと、QAの回答を元に試験仕様書の修正する作業まで手が回らなくなってしまい、納期間際のテスト工程で慌てることになってしまいました。

5.画面が完成していないのにテストを開始してしまった

進捗の遅れから「画面を開発中だけど、納期的に実装済みの機能についてはテストを始めないと間に合わない」というケースが当たり前にあったので、PLの指示で開発中の画面についてもテスト可能な部分からテストを行っていました。ただ、「デグレ三昧」と書いたように、画面実装完了後に残りの試験項目を行うとNGが出て、その修正の影響で開発中にOKとなっていたテスト項目についても再試験を実施する必要が出てきてしまい、結局全部やり直しみたいなことが多発しました。

自分は作業しながら「そりゃそうなるよな」と思っていましたが、納期が迫っているというプレッシャーからか、PLがパニック状態だったのかなと思いました。

6.プロジェクトの技術スタックにマッチしているメンバーが少なかった

開発チームのメンバーで今回のプロジェクトで使用されている技術を自身の技術スタックにしているメンバーが2、3人いるかどうかみたいな感じでした。加えてプロパーメンバーの中で技術スタックにマッチしているのがあの「いるのかいないのか」状態のPMだけだったので、技術スタックにマッチした人はBPの中に数人といっても良い状態で、そういった人に限って1ヶ月で別の案件に行ってしまったり、とにかく開発メンバーの出入りが激しく、なんかもう人員確保については破滅していました。

当然、実装で詰まるところが増えて進捗も遅れがちになります。ただ、納期は待ってくれませんし、増員も簡単に確保できないので、ひたすら残業や休出を行ってカバーするしかなくなり、チーム全体の活気が無くなっていきました。

ここらへんは予算とか色々なものが絡んでいそうなので大変な部分だと思いますが、これが上手くいっていないと辛い運命になる可能性は高くなりますし、開発メンバーにダイレクトにしわ寄せがくるので、どうにかしてほしい部分です。元請けから投げられる仕様書の質が低いといった自分たちでコントロールできない部分とは違い、自分たちでコントロールできる部分なのでちゃんと準備するべき部分だと思います。

開発が長いスパンで、技術スタックがミスマッチなメンバーが使用技術についてキャッチアップできる環境が整備されているなら別ですがね。

7.増員メンバーのキャッチアップ用ドキュメントが整備されていない

前の方に書きましたが、メンバーが1ヶ月で離脱したり色々とメンバーの入れ替わりが激しいプロジェクトなので、メンバーが補充されることもままあることでした。しかし、増員メンバーのための環境構築用ドキュメントであったり、システムの概要把握用ドキュメントであったり、増員メンバーが作業を行う上で必要な情報を提供するためのモノが無いので実際の業務に入るまでに時間がかかっていましたし、増員メンバーに対する情報キャッチアップのために他の開発メンバーが自分の作業を止める必要がありました。

人がいないので人を増やそうとすると作業効率が落ちる…なんかもう負のスパイラルです。これが、納期まで数ヶ月あるという段階なら、一旦作業効率が落ちるが、その後グンと上がるみたいなこともあると思いますが、納期から次の納期までが1ヶ月という今回のプロジェクトでは、その効果をあまり感じることはできませんでした。

ただ、そんなドキュメントを用意する暇などプロジェクトが炎上してしまった後には無いので、プロジェクト発足時にしっかり用意すべきだと思いました。BPとか外部の人間にも頼って開発を行うなら尚更だと思います。

8.無駄な進捗報告会議がある

本プロジェクトでは毎朝9:30〜10:30の間に進捗報告を行ってから業務に入っていく形をとっていましたが、「納期に間に合わない」という問題が現実味を帯びてくると、13:00〜13:30の間にも進捗報告会議が入ってくるようになりました。昼休憩は12:00〜13:00なので、この進捗報告会議は実際のところ、朝の進捗報告会議が終了した10:30から昼休憩が始まる12:00の1時間半、昼休憩返上で作業したとしても2時間半の作業に対しての進捗報告会議になっていました。

こうやって文字に起こすと笑えるほど意味の薄い会議ではありますが、「納期に間に合わない」という現実から、PLが「どうすれば間に合うのか、なんとか間に合わないか」という感じでパニック状態になり、こういった無駄な作業を追加させてしまうのだと思います。

せっかくチャットツールがあるので、作業が完了すればチャットで報告、詰まる所があればチャットで状況共有で良いかなと思いました。「納期に間に合わない中での妥協策を探す」ことも必要かと思いますが、数時間の作業に対してわざわざ全メンバーの作業をストップさせてまで進捗会議を行う必要はないと思いました。

あと、「納期に間に合わない」という問題が現実味を帯びてくるころにはメンバーの進捗を事細かに把握したところで、納期に間に合わせるためにできることは何もないかなと思います。火種が見えた瞬間に策を講じないと手遅れだなと思いました。本当の火事と一緒で燃え始めたら火はとんでもないスピードで回っていくので、「こうなったらこう」みたいな引き出しを多く持つことが必要だと感じました。

9.PLに意見できる人が誰もいない

前の文に「PLがパニック状態」ということを書きましたが、このパニック状態のPLに対して「それは違うんじゃないか」と言える人が誰もいなかったので、パニック状態から正気を取り戻させることができなかった、というのも問題点かなと感じました。

常駐先は受託開発のいかにも日本の伝統的な企業といった感じで、年功序列の感じも強く、プロパーメンバー間ですら彼らにとっての先輩であるPLには何も言えないといった状態でした。プロパー間ですらそんな状態なので我々BPも何も言えずという状態でした。

まぁ、この問題、言い換えればメンバーはPLの圧を感じながら作業をする感じになるので、言いたいことが言いにくいみたいな雰囲気が完全に完成されていました。

自分が印象に残っているのは、あるメンバーの「〇〇の実装で詰まっていて、実装方法を調査中です」という報告に対して、PLが「調査含めてどれくらいで実装できそうですか？」という返しをして、それに対して「今日中には終わると思います」みたいな会話があって、それを聞いていた自分は「実装方法の目処も立ってないのに、いつ終わるかなんて分からないでしょ」みたいなことを考えていました。

個人的には、ここでのPLの返しは「〇〇分くらい調べて実装方法が分からなければ報告をださい。社内で他のプロジェクトを行っているメンバーたちに聞いてみます」みたいなことが正解なのかなと。調べて分かればそれで良いですが、最悪のケースを想定して、そうなった場合はどう対処するみたいな方針を授けてあげるのがやるべきことかなと思いました。

まぁ、一番良いのは、「実装方法の目処も立っていないので、正直、いつまでに終わるとかは分かりません」と言っても大丈夫な雰囲気を作ることだとは思います。ただ、PLに引き出しがないと、その「いつまでに終わるか分からない」という回答に対して策を授ける事ができないので、進捗会議でお互い沈黙になるという地獄の時間を経験することになります。ちなみに、自分は経験しました。

あと、このプロジェクト固有の問題だと思いますが、PMが「いるんだかいないんだか」みたいな状態だったので、進捗管理やマネジメントの部分をほぼPL一人でこなさなければならない状態なのはかわいそうな部分だと思いました。要所要所でPMに相談していたとは思いますが、プロジェクトの規模的に一人ではどうしようもない状態なので…

最後に

長々と書きましたが、個人的には

• 自分を見失わない
• 今やるべきことを冷静に考える
• WBSを作成する力より問題が起きた時、起きそうな時の対応力が重要

まずは目の前の納期に焦って自分を見失わないこと。プロジェクトの長が焦ったりイライラしたりすればチーム全体に雰囲気が伝染します。チームの雰囲気を乱すリーダーは最悪です。私が以前参画していたプロジェクトでは進捗会議でメンバーを詰めたりする人がいましたが、この雰囲気はチーム全体に伝染して、チームの士気が下がるのでNG行為の筆頭だと思っています。自分を見失わなかったところで元々の性格がアレなら終了ですが、普段は優しいのに追い詰められると周りにキツく当たってしまいがちな人はまあまあいると思うので、どんな状況でも自分を見失わないことが重要だと思います。

次に、今やるべきことを冷静に考えること。「無駄を増やさず、無駄を取り除く」ことをするために、常に冷静に物事を取捨選択する力が重要だと思います。

最後に、問題が起きた時、起きそうな時の対応力を身につけること。経験を積めば引き出しも増えそうですが、ネットに書き記されている炎上案件体験記やマネジメントについての本など、情報源はたくさんあるので学ぼうと思えばそれなりの知識は身につくと思います。

上記3つが揃えば後は自分の力を発揮するだけだと思います。俯瞰で見る力やチームの雰囲気作りなどなど。マネジメントをするということは十人十色の人間を扱うということですし、それぞれの人に対応した接し方、タスクの振り方など、「これをすれば良い」みたいな銀の弾は無いと思うので。まぁ、ここからマネジメント職の面白い部分が始まるのかなと思います。

------- ｷﾘﾄﾘｾﾝ -------

通勤時間なんかに凄く考えるんですよね、「今のチーム状態はどうなのか、納期に間に合わせるには何が必要なのか、こうならないためには何が必要だったのか」などなど。

炎上プロジェクトに参画してなんだかんだ数ヶ月経ちました。稀なる強者からすれば「まだまだ」と言われるかもしれませんが、最近は毎日23時近くまで残業＆6勤1休という形が続いているので、そろそろ人並みの生活をしたいなと思い始めてきました。

「デスマーチを生き延びたからこそ今がある」なんてテーマで炎上してイベントが中止になった例がありますが、現在進行形で炎を浴びている身としては少し聞いてみたかったと思うこともあります。ただ、個人的にデスマから学べることは、他のエンジニアの通常業務と比較して少ないと思いますし、プライベートや自己研鑽の時間が無くなることを考えるとかなりマイナスなので、このような場面に遭遇したら出来るだけ早く逃げるのが一番だと思います。終わりの見えないプロジェクトに人生を捧げるなんて時間の無駄です。

自分がこんな記事を書いているのも、「このクソみたいな炎上案件からなにか1つでもプラスの経験を作らなければ」という思いから、二度と自分や自分の周りのエンジニアに同じ思いをさせないように教訓として残しておこうと考えてのことなので。プロジェクトが炎上しやすい日本のIT業界の体質なんて変わらないと思いますし、そこで地雷踏まないようにするための防衛術的なものですねこれは。

嗚呼、果たして自分はこの状況から生き延びることができるのでしょうか？