小さなチーム

ここ数年、数人の小さなチームのプロジェクトが多くやるようになりました。 協力会社の方も含めるとそれでも20名近い規模になっているのですが、それでもまだ小さいほうですね。

小さいことのメリット

意識したわけでなくプロジェクト規模からの必然で小さなチームになったのですが、やってみるとソフトウェアの品質面からも小さなチームの方が良いのかなと思いました。

当たり前ですが、チーム内を見渡すことができるのでメンバー自体のスキルを踏まえて、個々のメンバーの状態やその進捗を常に踏まえて物事を進めることができるようになります。私は職種がプロジェクトマネージャーというわけではないので専門の方はもっと行けるのかもしれませんが、こういうことができるのは経験的には20人が限界です。

これを超えると、進捗のための会議などの時間が長くなり、チーム内の意見やポリティカルな衝突に時間を割くことが多くなります。これが数百人規模だと、こういうチーム内の情報整理、調整に専任のチームが必要になります。

小さなチームだとメンバーをそもそも厳選できますし、コミュニケーションは特に意識しなくても濃くなります。メンバー間のコミュニケーションの志向も把握しているので、衝突しないよう柔軟にその場で役割を割り振って行くことができます。

人が集まるとどんな集団でも、優秀な２割、普通な６割、バカな２割になるという説があります。小さなチームであれば、意識してバカを排除でき優秀な５割を実現することも可能です。

結果、プロジェクトで生産する成果物の品質も向上します。うまくチーミングできれば、今まで大人数で年単位でかけていたプロジェクトを数人で数ヶ月なんてこともできそうな気がしています。全てを自前で作るのでなく、クラウドサービスが充実により適切なサービス選択によりさらにこの傾向は強まっていると思います。

小さなことのデメリット

チーミングに失敗し不幸にしてバカの混入率が高いと、リカバリーがかなり厳しいです。自分がオーナーシップを持っているプロジェクトであれば、面談などである程度こういったリスクは排除できます。

一番のデメリットは、会社の売上という観点からのメリットがないことです。
長期的には高い生産性、高い品質のチームというのは会社の競争力を高めるのだと思いますが、短期的には相対的に売上も小さくなります。従って、そういうチーミング自体をすることが難しくなります。

企業は、ある程度の規模の開発を少人数でやることのリスクより、そこそこの人数を投入してリスクを減らすということをやりたがります。 現場としてはそれはリスクを上乗せしてるだけなのですが、「リスクを減らすために人を投入します」という論理は意外に多くの人が納得してしまうのです。リスクが減っているかどうかは知りませんが、クライアントは人を投入したと納得し、ベンダーは売上が上がったと納得する。リスクが顕在化したら、さらに人を投入する。

よく見る光景ですしこのアプローチは「デスマーチ」と言われているはずですが、なぜかりん議ではチームメンバーの厳選より大量投入の方が受けがいいようです。

我々は通常ソフトウェアを設計する際、機能を適切にモジュール化して小さく簡潔していきます。ソフトウェアを設計する際の基本的なアプローチです。チームも同じことなのかと改めて思いました。チームもモジュールのように厳選し簡潔にして品質を高めることが必要です。これができれば、チームを組み合わせた、複合チームで大きくして行くことはありかもしれません。

大人数でピラミッドを作って行くことがダメなのかと。