なぜプロジェクトが炎上しているのか自分なりに考えてみた
Published
リニューアル前の個人ブログで炎上案件に参画しているという記事を書きましたが、カジュアル面談なんかで「大変ですね」とか結構色々言われたり聞かれたりするので、今回はその炎上の原因を自分のポジョンから自分なりに考えてみて、未来の自分への財産としたいと思います。
ちなみに、前提として自分はこの炎上案件に参画していることをネガティブに思っているなんてことは無く、今は個人の時間も体力もあるので1つの経験として純粋に楽しんでいます。特に納期前日の「絶対間に合わないけどやれるところまではやらないといけない」みたいな状況の中でフル稼働していると段々頭が冴えてくるあの感覚が好きです。まぁ、BPというポジションのお気楽さもあってこそだとは思いますが。
というわけで本題へ。
案件の概要
- 金融企業向け顧客管理Webアプリの新規開発
- 最終的な納期が11月くらい。しかし、それまでに1ヶ月単位で納期がある。例えば、アプリ全体で100画面あるとしたら、10月までに50画面納品、11月までに残りの50画面を納品といった感じ
- ウォーターフォール開発
商流図
メンバー構成
- PM: 1名, PL: 1名, メンバー: 5〜14名くらい
- PMがプロジェクトを掛け持ちしているため、全体の3割の時間程度しか本プロジェクトに時間が割けない
- プロパーメンバーの中で本開発で使われる言語やFWについての知識があるのはPMのみ
プロジェクト炎上の原因
外部的な問題から内部的な問題まで思い当たるものを書きたいと思います。ただ注意してほしいのは、これは愚痴とか不満とかそういった類のものではなく、純粋にプロジェクト炎上の原因を分析した結果を書いているだけということ。それでは本題へ。
仕様書に不明点や矛盾点が多すぎる
例えば仕様書ごとにDBのカラム名やデータ型に矛盾があったり、「決定次第記載」という注釈が書かれた仕様書が普通に渡される。現場では該当月になったら納品する分の仕様書がメンバーに渡されて開発を行うみたいな流れになっていたが、まず渡された仕様書の不明点や矛盾点の洗い出しから始めなければならず、この段階でもうPLが立てた予定から遅れることになる。
仕様書の不明点についての回答が遅すぎる
前述の通り、仕様書についての不明点を元請けであるA社にQA表という形で不明点の質問をするのだが、これの返答に2、3週間くらいかかるので、不明点については「全ての仕様書から考えられる最も妥当な方法」で仮実装を行うことになっていた。ただ、仮実装なので引数と戻り値だけ整合性を持たせて中身が空の状態みたいな感じなので、結局のところ元請けの返答後に本実装を行う必要が出てくる。
仮実装を行わないと実装可能箇所の作業が進まないので仕方のないことではあるが、はっきり言って仮実装部分に割く時間も、返答受領後の本実装に伴う実装済み部分の改修も考えて時間を無駄にしている気がする。
デグレ三昧
仕様書のQA受領が納期の1、2週間前という絶妙なタイミングでくるので、モノによっては実装、モノによっては「納期間際で仕様を知らされたので次の開発期間で対応します」という体で未実装のまま納品することになる。
これの何が問題かというと、システムの整合性が取れていないので納品前の試験で不具合が多発するということ。我々のミッションとして、「20画面納品」となっていた場合、納品前の試験についてはそれぞれの画面についての単体試験はもちろん、20画面について遷移などが正しく行えるかなどの結合試験も行う必要があったので、結合試験の部分で不具合が多発した。不具合が多発すれば修正も多発する。修正しているはずなのにデグレ三昧。なぜなら我々は整合性のとれた仕様書を手にしていないから。
仕様が固まる前に試験仕様書を作成した
我々は仕様書を元に試験仕様書を作成していたのだが、散々書いたとおり仕様が固まっているとは言いにくい状況で試験仕様書の作成をおこなってしまったことも問題かなと思った。現実は開発と仕様書の変更が同時に行われているような状況だったので、仕様書の変更に試験仕様書がついてきておらず、試験時に仕様から消えた部分のテスト項目や項目漏れしている部分もあったりでテストという納期間際の段階で試験仕様書の修正を行うなど無駄なタスクが追加されたことも炎上の一因だと思う。
画面が完成していないのにテストを開始してしまった
「画面を開発中だけど、納期的に実装済みの機能についてはテストを始めないと間に合わない」というケースが当たり前にあったので、PLの指示で開発中の画面についてもテスト可能な部分からテストを行っていった。ただ、「デグレ三昧」と書いたように、いざ画面実装完了後に残りの試験項目を行うとNGが出て、それの修正の影響で
開発中にOKとなっていたテスト項目についても再試験を実施する必要が出てきてしまい、結局全部やり直しみたいなことが多発した。
自分は作業しながら「そりゃそうなるよな」と思っていたけれど、納期が迫っているというプレッシャーからPLがもう完全にパニック状態になっていた感じでしたね。
プロジェクトの技術スタックにマッチしているメンバーが少なかった
今回はC#とASP.NETをメインに使用していたが、これを自身の技術スタックにしているメンバーが2、3人いるかどうかみたいな感じだった。しかもそういった人は1ヶ月でチームを離れてしまったり、なんかもう人員確保については破滅していた。
当然、実装で詰まるところが増えて進捗も遅れがちになる。ただ、納期は待ってくれないし、増員も簡単に確保できないので、ひたすら残業や休出を行ってカバーするしかなくなり、チーム全体の活気が無くなっていく。ただでさえプロパーとPBというビジネス上の関係があって歪な状態のチームなのに。
ここらへんは予算とか色々なものが絡んでいそうなのでコントロールしにくい部分だと思うが、これが上手くいっていないと辛い運命になる可能性大だなと感じた。
増員メンバーのキャッチアップ用ドキュメントが整備されていない
前の方に書いたが、メンバーが1ヶ月で離脱したり色々とメンバーの入れ替わりが激しいプロジェクトなので、増員が補充されることもままあることなのだが、その増員メンバーのための環境構築用ドキュメントであったり、システムの概要把握用ドキュメントであったり、増員メンバーが作業を行う上で必要な情報を提供するためのモノが無いので実際の業務に入るまでに時間がかかっていた。
ただ、そんなドキュメントを用意する暇などプロジェクトが炎上してしまった後には無いので、プロジェクト発足時にしっかり用意すべきだと思った。
無駄な進捗報告会議がある
本プロジェクトでは毎朝9:30〜10:30の間に進捗報告を行ってから業務に入っていく形をとっていたが、「納期に間に合わない」という問題が現実味を帯びてくると、13:00〜13:30の間にも進捗報告会議が入ってくるようになる。昼休憩は12:00〜13:00なので、この進捗報告会議は実際のところ、朝の進捗報告会議が終了した10:30から昼休憩が始まる12:00の1時間半の作業に対しての進捗報告会議になっていた。
こうやって文字に起こすと笑えるほど意味の薄い会議ではあるが、「納期に間に合わない」という現実がPLを完全にパニック状態にさせてこういった無駄な作業を追加させてしまうのだと思います。
せっかくチャットツールがあるのだから、作業が完了すればチャットで報告、詰まる所があればチャットで状況共有で良いかなと思いました。
PLに意見できる人が誰もいない
「PLがパニック状態」ということを何回か書いたが、このパニック状態のPLに対して「それは違うんじゃないか」と言える人が誰もいなかったので、パニック状態から正気を取り戻させることができなかった、というのも問題点かなと感じました。
常駐先は受託開発のいかにも日本の伝統的な企業といった感じで、年功序列の感じも強く、プロパーメンバー間ですら自分たちにとっての先輩であるPLには何も言えないといった状態だった。プロパー間ですらそんな状態なので我々BPも何も言えずという状態だった。
まぁ、この問題、言い換えればメンバーはPLの圧を感じながら作業をする感じになるので、言いたいことが言いにくいみたいな雰囲気が漂ってしまう。
自分が印象に残っているのは、あるメンバーの「〇〇の実装で詰まっていて、実装方法を調査中です」という報告に対して、PLが「調査含めてどれくらいで実装できそうですか？」という返しをして、それに対して「今日中には終わると思います」みたいな会話があって、それを聞いていた自分は「実装方法の目処も立ってないのに、いつ終わるかなんて分からないでしょ」みたいなことを考えていました。
個人的には、ここでのPLの返しは「〇〇分くらい調べて実装方法が分からなければ報告をださい。社内で他のプロジェクトを行っているメンバーたちに聞いてみます」みたいなことが正解なのかなと。調べて分かればそれで良いですが、最悪のケースを想定して、そうなった場合はどう対処するみたいな方針を授けてあげるのがやるべきことかなと思いました。
まぁ、一番良いのは、「実装方法の目処も立っていないので、正直、いつまでに終わるとかは分かりません」と言っても大丈夫な雰囲気を作ることだとは思いますが。
あと、このプロジェクト固有の問題だと思いますが、PMが「いるんだかいないんだか」みたいな状態だったので、進捗管理やマネジメントの部分をほぼPL一人でこなさなければならない状態なのはかわいそうな部分だと思いました。
最後に
長々と書きましたが、結局の所
- 自分を見失わない
- 今やるべきことを冷静に考える
これが大事なのかなと思います。これができていれば、チームの雰囲気作りにしてもマネジメントにしても後は自分の能力次第だと思います。
通勤時間なんかに凄く考えるんですよね、「今のチーム状態はどうなのか、納期に間に合わせるには何が必要なのか、こうならないためには何が必要だったのか」などなど。
炎上プロジェクトに参画してなんだかんだ数ヶ月経ちますが、この状態で冷静に現状を分析できている自分の姿にはとりあえず一安心というところでしょうか。