時期尚早な人員増加

ソフトウェアの良い点の一つは、人々がそれを必要とし、しかもすぐに必要とすることです。組織がチームにソフトウェアの生産速度を上げるように要求するのはよくあることで、時には組織は、そのコミットメントを真に示す方法で支援しようとします。それは、チームに人を増やすためにお金を使うことです。

さて、ソフトウェアチームに人を追加することの真のメリットについては、多くの議論がなされてきました。私にとって明らかなのは、線形的なメリットは得られないということです。チームを倍増しても、コミュニケーションと調整のコストが発生し、増加を鈍らせるため、生産性は倍増しません。私の全く非科学的な経験則では、生産性の向上は、人数の増加の平方根に比例する可能性が高いということです。つまり、チームを倍増すると、生産性は約50％向上します。しかし、実際には、これは個々の要因によって大きく異なります。私知っている中には、かなりの規模のチームであっても、単独で生産性を倍増させる可能性のある人がいますし、チームの生産性を低下させるような人にも遭遇したことがあります。

しかし、ここで私が強調したいのは、立ち上げの問題です。うまく機能している小規模なチームがありますが、より多くのソフトウェアを必要としており、それを得るためにお金を使う準備ができています。進捗率を倍増させるために、4倍、6倍のお金を支払っても構わないと思っています。重要でありながら、あまり理解されていない要素は、チームに安全に人を追加できる速度です。

一度ならず、人を急速に増やしすぎたプロジェクトに遭遇しました。これは、コードベース自体の凝集性の崩壊として現れます。重複が蔓延し、私の友人の何人かは、単一のアプリケーション内に3つのオブジェクトリレーショナルマッピングフレームワークを持っていたプロジェクトについて知っています。この崩壊は、新しい人がコードベースの現在の動作方法を理解していないため、競合するフレームワークを追加するなど、それと矛盾する何かを行うために発生します。新しい人が多すぎると、チームリーダーシップはすべてを追跡できなくなり、コードベースに問題が発生します。これらの問題は、誰も一貫した方法を見つけられないため、互いに強化し合い、壊れた窓症候群が発生し、正のフィードバックループが発生します。（そして、正のフィードバックループは通常、悪いことです。）

これに加えて、急速な人員増加は、人間のコミュニケーションメカニズムの崩壊につながります。人々がお互いに協力することに慣れるには時間がかかり、急速な人員増加は、大規模なチームが成功に必要な関係を築くことを妨げる可能性があります。

では、どれだけの速度で安全に人員を増やすことができるのでしょうか？ここで具体的なアドバイスをするのは難しいです。なぜなら、経験豊富なプロジェクトマネージャーに尋ねると、常に多くの変数を考慮する必要があると正しく指摘されるからです。私が最も信頼しているPMの情報源の一人であるJoe Zenevitchに話を聞いたところ、彼は一度にチームを2倍以上にしたくないと示しました。2倍にすることさえリスクの高い決断であり、既存のチームがすでに12人以上いる場合、またはかなりの数のジュニアがいる場合は、リスクが高まります。

大幅な規模の増加を行う場合は、新しい人がチームに定着するまで、さらに人を追加しないでください。これには数週間かかります。開発者はコードベースとドメインを知る必要があり、BAはドメインエキスパートに精通している必要があり、誰もがお互いを知る必要があります。Thoughtworksでは、私たちは、明るい、意欲の高い、学習の速い人材を採用しているため、人々がすぐに立ち上がることができると期待しています。しかし、それでも1〜2週間かかります。ほとんどのチームでは、もう少し長く待つ必要があります。

チームに人を追加しても、能力はすぐに上がりません。新しいプロジェクトで生産性を上げるには時間がかかります。さらに悪いことに、既存のスタッフは彼らがスピードに乗るのを助けるために時間を費やす必要があるため、あなたのベロシティは最初は低下する可能性があります。Joe ZのThoughtworksチームの観察では、新しい人と既存の人への影響が相殺されるため、最初の数週間は正味の影響はありません。[1]ほとんどのThoughtWorkerは、ペアプログラミングは、人々をより迅速にオンボーディングするための大きなイネーブラーであると指摘しています。Pat Kuaも、新しい人をチームに効果的に参加させる方法について良いアドバイスを提供しています。

もう一つ注意すべきことは、プロジェクトの初期段階で人員を増やしすぎないことです。大規模プロジェクト（50人以上）を行う人々から聞いた最も確固たるアドバイスの1つは、プロジェクトは小規模に、おそらく12人ほどの開発者から始めるべきだということです。彼らは、システムの主要な設計要素と相互作用を、システムの初期の部分を構築することによって理解する必要があります。その設計が落ち着いてから初めて、チームの規模をフルサイズに増やすことを検討する必要があります。その落ち着きの一環として、コピーすべきではないと思われる設計要素を削除する時間を設けてください。人々は自然にそこにすでに存在するものをコピーするので、そこに存在するものがすべてさらなる開発のための良いプラットフォームになるようにする必要があります。これは、コードの清潔さに過度に注意を払うべき時です。

最後に、人員増加を検討する際には、それが価値があるかどうかを慎重に検討してください。生産性を低下させることなく、チームを大幅に削減できるという感覚がない大規模なチームに遭遇することはめったにありません。かつて私が言ったように「アジャイルのスケーリングは、あなたがやりたいことの最後のことです」。

参考文献

私の同僚であるFrancisco Trindadeは、数週間で一度に数人の開発者を育成するために使用した良い経験について話しています。