頭数だけ揃えても開発キャパは思うようにスケールしない

頭数だけ揃えたって、開発キャパシティは思うようにスケールしないよ。どうしてって？だって、ソフトウェア開発は、チームプレーだから。

ミッドフィルダーばかり11人いても、サッカーの試合で勝つのは難しいよね。それぞれのポジションが揃って、巧みに連携してこそ勝利を導くわけでしょう？

ソフトウェア開発もチームプレーなんだよ。それぞれが受け持つポジションがあって、互いに連携するわけ。

スポーツチームとの違いは、控え選手がいないことかな。それってリスクだよね。そうそう、急な欠員に対して、すぐに補填できない。サッカーで言えば、11人揃わずにゲームに臨むようなものだよ。

こういう事態に備えて、2つのことが重要になるんだ。チーム内でポジションを冗長化することと、稼働率を抑えることね。

冗長化って言うと、ちょっとやらされ感があるかな。それぞれが自分のポジションだけに固執していると、チームは助け合えないでしょう？自ら進んでフォローするマインドとスキルを育てないとね。

それには、メンバーがタスクで手一杯な状態にしちゃだめだ。欠員が出た時に、フォローにまわれなくなるし、まわろうとしなくなる。稼働率が高すぎると、ただの個の集まりに陥って、チームという視点を失うんだ。

チームビルディングって大切だよ、ほんと。スポーツチームも、必ずチームで集まって練習するでしょう？チームとしての練度と一体感を高めることが、それだけ重要ってこと。

だから、チームを不可分な単位として考えるんだ。個の集まりじゃなく、チームがひとつの個なわけ。

チームが個なんだから、メンバーが増え過ぎると逆に効率が悪化する。7±2人程度が好ましいって、聞いたことない？ソフトウェア開発は、スモールチームでフォーメーションを組んで戦うゲームなんだ。

じゃあどうやってキャパシティをスケールさせるのかって？もちろん、新しいチームを育てる。チームという単位でスケールさせていくんだよ。

でもね、複数チーム制を機能させるってのは、思うほど簡単じゃない。ソフトウェアシステムを複数チームでどう分割、担当して開発するか。その境界付けに悩むことになる。

だだっ広いサッカーグラウンドを区切らず使うことをイメージしてみなよ。そんな場所で同時に複数のゲームが行われたら、大混乱になるのは目に見えてるよね。いくつかのフィールドに区切って、それぞれ独立してゲームすべきなのは明らかでしょう？

ソフトウェアシステムに境界を設定するのも同じ理由さ。コンポーネントと呼ばれるフィールドに区切らないと、まともにプレーできない。

ただね、フィールドと違って、コンポーネントってのは互いに繋がってる。これをどう繋げるのか、慎重に設計しなきゃいけない。下手すると、チーム間にタスクの従属関係が形成されやすくなってしまうから。

タスクの従属関係が、並行開発の阻害要因だって知っているでしょう？プロジェクトマネジメント経験者なら、常識だよね。スケジュールをのばす原因になりかねない。

タスクの従属関係は、チームを互いに束縛する鎖のようなものなんだ。がんじがらめの状態じゃ、それぞれのチームは独立した個として活動できない。

だから、優秀なアーキテクトの存在が欠かせない。ソフトウェアシステムの設計の良し悪しが、チームプレーに影響するわけだから。

ソフトウェアシステムとソフトウェア開発組織っていうのはさ、対になって漸進的な進化とトランスフォーメーションを繰り返すんだ。これこそが、スケーラブルなソフトウェア開発ってことさ。