少人数チームを運営するときに気をつけておきたい３つのこと

ビジネスニーズがシステムリリースのスピードを重要視すると言われるようになって数年は経ちますが、それに伴い、プロジェクト自体も小粒化、短期間に加え低価格な案件が多くなりました。

まあ、もともと大規模プロジェクト自体が絶滅品種的なものでプロジェクトの数で言えば、小粒なプロジェクトが大多数なのですけど。

その大規模プロジェクトは、そこそこの大規模プロジェクトがあったときはプロジェクトマネージャもキーパーソンも確保できたものも、今では大規模プロジェクト自体が減ってきていて、そうした大規模プロジェクトではならの勘所を押さえているエンジニアやマネージャがおらず、今時の大規模プロジェクトは勘所を押さえずに進めるのでそれはそれは大変怖いです。

昔からあった少人数チーム

冒頭で述べたように少人数チームはその数自体は以前から多く、数を規模として捉えれば、△のように希少な大規模プロジェクト、大多数の小規模プロジェクトとなります。

つまり、少人数のメンバで構成するプロジェクトは以前からあったわけです。

ここ数年はスタートアップとかWebサービスなどのビジネスニーズであるスピード重視に経営や起業だからこそのコストから少人数のメンバで構成するチームにスポットが当たっているところです。

では、そうしたビジネスニーズに応じて編成される少人数チームで気をつける点はあるのでしょうか。

規模のバッファがない

プロジェクトチームの規模が大きくなればなるほど、様々なところでリソースのバッファが隠れているものです。コミュニケーションに時間が取られるとか、手続きが複雑になるなど、規模が大きければ大きくなるほど見えないスラックが潜在しています。

このスラックであるバッファは人的リソースにも当然あります。例えば、期待する成果に満たないエンジニアがいても、その他のエンジニアが期待に到達しない成果を穴埋めするだけの人的なバッファがあるのでプロジェクト全体としての期待する成果に応じた結果を帳尻合わせとして確保することができます。

ところが、少人数チームで、例えば、５人のチームのうち１人が期待に対する成果が得られていない場合、大規模プロジェクトのように残りのメンバで吸収することがとても負担になります。

新人を育てられない

大規模プロジェクトであれば歓迎はされないかもしれないけれど、先の期待に対する成果を周りが補填する形で新人エンジニアを育成する場としての機会となりました。

ところが少人数チームでは、それも先の期待する成果を得られないためにコストをフルで顧客のバジェットで賄うプロジェクトでは、新人エンジニアを育てることはコスト負担の問題から機会を作りにくくなるのです。

スキルミスマッチが命取り

バッファは何も人的リソースばかりに起きるものではありません。プロジェクトをチームとして成立させるための、プロジェクトの目的を達成するために必要なチームとしてのスキルセットを満たさなければプロジェクトは目的を達成することはできません。

少人数チームであればこそ、メンバに期待するスキルはマルチスキルになり、期待するスキルレベルも高くなります。

そうした背景があるにもかかわらず、スキルマッチしないメンバがいたらどうなるかを想像することは容易いことです。

そして、必要なスキルとレベルを持つエンジニアを必要なときに調達することは難しいという法則が働くのです。

チームが機能するとはどういうことか――「学習力」と「実行力」を高める実践アプローチ