ブルックスの法則

2021-05-25

以前携わらせて頂いた現場でブルックスの法則というものを教えていただきました。

短い Wiki なのでぜひ読んでいただきたいのですが、要するにプロジェクトがうまく進んでいないときに人を追加するのは逆効果だよ、という内容です。

自分はフロントエンドディベロッパーなので、Web サービスの開発に焦点を絞りますが。

Web サービスの開発プロジェクトがうまいこと進まないときって、以下のいずれかに、もしかくは複数にまたがって原因があります。

数字が小さければ小さいほど問題自体はは小さく、大きくなるにつれ問題の深刻度が増します。

会社で発生する問題の多くは内部の人為的なものから引き起こされています。

それが意識して起こされたものなのか、無意識のうちに起こされたものなのか、多くの場合それを問いてもしょうがありません。

個人的に思うのが、起きた問題に対して最適な解決法を見出すことが大事だよなと、そこができる現場は強い現場かなと。

たとえばプロジェクト内のフロントの開発の進捗が悪い場合、フロントエンドディベロッパーを追加して乗り越えよう！みたいな判断を下すプロジェクトマネージャーはかなり多いですが。

仮にスケジュールがきちんと切られていて、Web プロトタイプもスキーマもきちんと準備されているとしたら、もしかしたら開発を行っているフロントエンドリードエンジニアの技術力が追いついていない可能性は大いにあります。

もしそのような状況でフロントエンドディベロッパーを追加したとしても、元からいるフロントエンドリードエンジニアの下に就いたとしたら、実力を発揮しきれないこともままあるのではないでしょうか。

本来であれば、たとえばフロントエンドリードエンジニアをクビにして、もとからいるフロントエンドディベロッパーを昇格させるといった選択肢のほうが有効に働く可能性もあると思います。

たとえばフロントエンドリードエンジニアと 1on1 を行って、ヒアリングからさらなる問題の原因を追求するといったことも重要かと思われます。

それがたとえ周りには非情な判断だと思われたとしても、自分たちが行うべきなのはスケジュール通りにプロダクトをリリースすることであって、時としては絶対に必要な判断かなと。

事実、過去エンジニアを大量に雇っているにもかかわらず、まったく生産性が上がっていないプロジェクトに配属されたことがありました。

そこの現場は、各々のエンジニアの技術力はともかく、人が多すぎて物事の決断にやたら時間がかかっていたのが印象的でした。

またエンジニアが多すぎるせいでタスクを振るだけでも時間がかかっており、エンジニアの統制が間に合っておらず、そのせいできちんと管理しなければいけないことがずさんになっていたりと、なかなか散々な状態に。

そこの現場では PM から「開発がうまいこと回ってないからなんとかしてほしい」と言われて入ったのですが、『あなたの判断をまずなんとかするべきでは？』と感じざるを得ませんでした。

これは個人的な意見ですが、開発に携わる人数って少なければ少ないに越したことはないと思っています。

少ない人数で効率よく作業をこなす、それを実現するには各々がプロフェッショナルであることを求められます。

もちろんエンジニアの育成も求められますので、プロフェッショナルの下に人材を配置してエンジニアとしての育成も行う必要があります。

ただフロントエンドと Web デザインについてはこの育成の部分がまったく行われていないため、いつまで経っても平行線をたどっているような気がしてなりません。

単価 50 万円で中途半端なエンジニアを 2 人雇うのであれば、単価 70 万円で 1 人のプロフェッショナルを雇うほうが効率的なケースは多いと思います。

で、余った 30 万円で新人エンジニアを雇ってプロフェッショナルに育成してもらうのが、もっとも理想的なフローだよなーと。

まぁ、あくまで理想は理想でしかないですが…。

繰り返しになりますが、プロジェクトがうまく回っていないときにすべきこと＝人を追加することではありません。

そのときどきで最適な選択肢にたどり着くことが大事なわけで、最適な選択肢を見つけ出すには、時として今まで目をそむけていた事実と向き合う必要も出てくると思います。

仮に自分が足を引っ張っているようであれば、潔く身を引くことも重要でしょうし、自分がどういうポジションであれ、常に第三者的な視線で自分と周りを見続けることが大切なのかなと。

ということで、ブルックスの法則はとても鋭い法則だなぁと思った今日このごろです。

kk-web