プロジェクトが炎上し始める兆候には色々あると思うのですが、今回あらためて気づいた点があるので書いておこうと思います。
プログラマーとしてプロジェクトに関わっていると、ある日PM（＝プロジェクトマネージャー≠プロダクトマネージャー）が「現在着手しているタスクの進捗状況を箇条書きにして報告してください。何％進んでいて、いつまでに完了するかを数字で教えて下さい」と言ってくることがあります。
プログラマーとしては若干「めんど」と思いながらも、コードを書く手を止めてチャット欄に報告事項をまとめ始めるわけですが、これはよく考えたらおかしなことで、PMというのはプロジェクト全体のタスク状況をそもそも把握しているはずです。でなければプログラマーに次の作業の依頼をしたり、プロダクトオーナーに報告したりということができないし、状況を把握した上でプログラマーに対し「このタスクはどうなっていますか？ 大丈夫ですか？」と突っつくのが仕事なわけです。
さらに、プログラマー自身に進捗をまとめさせることの問題は、プログラマーが上げてくる報告が主観に過ぎないという点にもあります。「もう90%できているので、明日にはプルリクができます」と良いながら２日、３日、一週間と過ぎていくのはあるあるです。プログラマー自身に悪気はなく、本当に予想もできなかったハマりどころのせいであと10%がなかなか完成しないということもあります。PMは、そういう状況を外から客観的に見て「これはもうしばらくかかりそうだな」という判断を早めにしなければなりません。
なんでPMは「状況をまとめろ」と言ってくるのでしょうか。端的に言えば、楽をしたいからです。状況を把握するのはそれなりに骨が折れる仕事です。集中力が要ります。その作業をプログラマー自身にオフロードすることで自分の負荷を下げたいわけです。
単純にPMが怠け者だったり性格が悪い人間である場合もあるでしょう。しかし、怠け者でない勤勉なPMがそういうことを良い出した場合は、PMの処理能力を超える負荷がかかってきているということの徴（しるし）だと思われます。
PMの処理能力が限界を超えるとどうなるでしょうか。まず、PMがプロジェクトの状況を把握できなくなります。PMの預かり知らぬところで機能が実装され、マージされ、デプロイされます。リリースされた機能にバグがあった場合、そのバグの原因となった機能がいつ誰によって作られ、誰に修正依頼をすれば良いのかわからなくなります。その都度関係者に訪ね歩き、どうテストしたら良いのかもよくわからずに雰囲気で修正をリリースします。テストの観点が不十分なのでデグレが混入し、また同じことを繰り返します。
また、関係者からPMへの依頼がどんどんとキューに積まれていきます。依頼したことが開発チームに認識されるまで一ヶ月かかるようになります。キューだったはずなのにスタックみたいに依頼事項がLIFOで処理され出します。当然最初に依頼した人は不機嫌になり、チーム内に不信感が生まれます。悪い雰囲気は蔓延し、一人また一人とチームを去っていきます。足りなくなった人手を補充するために高値掴みも厭わず新しい人を入れるのですが、根本的な問題が解決していないので新しいメンバーは自分のことを「火消しで投入されたのだな」と認識します。なんとか消火活動は成功しますが、火が消えた段階で「火消し屋」もチームを去ります。そうこうしているうちに順調に資金が底をつき、めでたくゲームオーバーとなります。
PMとはプロジェクトの消化器官のようなものだなあと思います。ビジネスサイドがユーザーからの要求を「食べ」て、PMが「消化」して、プログラマーが「吸収」して現実のプロダクト＝「身体」が成長します。消化器官が疲弊すると、食べ物を受け付けず、栄養を吸収できず、プロダクトは停滞します。それどころか、ユーザーの要望を食べ続けなければプロダクトがユーザーのニーズを満たせなくなり、どんどん身体はやせ細っていき、プロダクトは死を迎えます。
伝統的な受託システムインテグレーション企業では、プログラマー1人に対しPM5人というような、プログラマーの人数に比して異常なほどPMを補充することでこの問題を乗り切ろうとします。これは明らかにバランスが悪いため費用対効果が低く、ビジネスサイドから入ってくる要望を過剰に解釈することで誰も使わない機能がリリースされてしまいます。人間の身体に例えれば脂肪が付きすぎた状態と言えそうです。
スタートアップではビジネスに共感するメンバーのみを集めることで「全員PM」のような状態を作り出そうとします。全員が自発的にプロジェクトの状況を把握することで単一障害点を無くそうと言うわけです。しかしこれは夢物語であり、現実問題としてそのような外観は誰かの犠牲の上に成り立っています。それで楽ができるのは役員だけで、実際にはPM業を中心的に担わされている人物が必ずいます。「リーン」と言えば聞こえは良いですが、弱りきった胃腸では満足に機能をリリースできません。下痢を繰り返している痩せ型人間と同じです。
プロダクトが本当に欲しかった筋肉質な身体を作るにはどうすれば良いのでしょうか。人間と同様に「胃腸を健康に保つ」ことが大事だと思われます。PMの負荷を下げ、必要ならアシスタントを付けたいところです。
PMの負荷が高まるのは関係者が増えすぎてコミュニケーションのオーバーヘッドが発生しているからだと推測できるので、チームのメンバーを減らすというのもある程度有効だと思います。少ないメンバーで生産性を維持するためには、優秀なメンバー（プログラマー）で布陣を固める必要があります。
プログラマーも人間の身体に例えるなら、この場合は腸内細菌ということになろうかと思います。少数精鋭のプログラマーを雇用することは、腸内フローラを整えることと似ています。この場合の「悪玉菌」は「ダメなコードを書くプログラマー」と言えそうです。
結論としては、ダメなコードを書くプログラマーをチームから減らすというのが解決策になるんじゃないかなと思います。単にチームから追放するのではなく、ダメなコードを書くプログラマーに成長する機会を与えるチームであるのが理想ですが、そうも言っていられない懐事情もあると思われますので実際にはダメなコードを書くプログラマーにクビを宣告することになるんじゃないかなと思います。悲しい話ではありますが。
