2人チームは、かつての10人チームに匹敵する

出典: The two-person team is the new ten-person team

私はかつて、120人規模のエンジニア組織を率いていました。いまは2つの会社で同時にエンジニアリングを統括しています。1社はエンジニアが19人いて、2〜3人単位のプロダクトチームとプラットフォームチームに分かれています。もう1社は、エンジニア部門そのものが2人だけです。

どちらの会社でも、仕事の単位は小さなチームです。いずれ大きくなるまでの仮の姿ではありません。この形そのもので仕事をしています。

2〜3人のチームは10人チームを縮めたものではありませんし、10人チームも100人組織を縮めたものではありません。それぞれ構造がまったく違います。チームの規模を一本の線の上に並べて、小さいほうを大きくなるまでのつなぎとみなす。2026年のいま、チーム規模をめぐる議論でいちばんよく見かけるのがこの誤りです。

ここでは、小さなチームを「小さなチーム」として正面から評価してみたいと思います。寄せ集めでも、一時的なものでも、言い訳が必要なものでもありません。仕事の性質に合っていれば、それが正しい形なのです。

小さなチームが本当に得意なこと

真っ先に挙がるのはコミュニケーションでしょう。2人ならシステム全体を頭に入れておけますし、会議を開かなくても数分で物事が決まります。知識は、わざわざ手順を整えなくても、一緒に働くうちに自然と共有されます。どれも事実で、大事なことです。ただ、小さなチームがうまくいく本当の理由はそこではありません。

本当の理由は「主体性」です。

ある程度の規模の組織では、経営層が自律性を口にしても、現場のチームが実際にそれを持っていることはまれです。意思決定は上で静かに済まされ、形だけ相談したうえで下りてくる。あるいは、制度上は権限を与えられていても、「最後は誰かが承認するのだろう」という空気があって、チームがそれを行使しない。どちらにしても、チームは本当の意味で判断を下していません。

2人のチームでは、そういう働き方ができません。判断を回す先がないからです。自分たちで決めなければ、何も進まない。それが当たり前になると、上に許可を求めること自体をしなくなります。チームは「決まったことを実装する場所」から、「答えを生み出す場所」に変わります。

私たちの2人チームでは、ここを一切妥協していません。システムの作り方も、何を優先して何を後回しにするかも、どこまでで「十分」とするかも、2人のエンジニアが決めます。私の判断もCEOの判断も待っていません。多くの組織がつまずくのはまさにこの点で、チームを機能させているのもこの点です。

120人の組織にいた頃は、主体性は常に取り組み続けても解決しきれない課題でした。スクワッドにはオーナーがいて、オーナーには担当範囲があり、範囲には境界があり、境界にはエスカレーションの経路がある。それ自体は間違っていません。あの規模では必要な仕組みです。ただ、その代償として、主体性は自然に発揮されるものではなく「管理される資源」になります。そしてエンジニアリングの力のかなりの部分が、境界の内側で働くことではなく、境界の調整に費やされてしまうのです。

小さなチームにできないこと

2人のチームは、すぐに価値を生まない作業について、毎週のように割り切った判断をしています。分かりやすい例が、個人データの開示請求への対応です。本当はプロセス全体を自動化したいのですが、件数がそれに見合いません。だから当面は手作業で対応し、件数が増えて必要になるまでそのままにします。もっと大きなチームなら、誰に頼まれたわけでもなく、人員に見合うからという理由で、コンプライアンス関連の取り組みの一環としてとっくに自動化していたでしょう。

これが小さなチームの取引条件です。手をつけられない仕事はキューに積まれたままになります。ただ、そのキューは正直です。「来期には着手します」と取り繕う人はいません。

一方で、小さなチームを運営するなかで確信を強めたこともあります。エンジニアの時間が浪費されているなら、早い段階で徹底的に自動化すべきだということです。2人のチームにとって、エンジニアの時間は何より貴重な資源です。それに見合う価値を生まずに時間を削るものは、すぐに取り除かなければなりません。大切なのは「何を作るか」の判断ではなく、「何を作らないか」の判断です。

もう一つの弱点は、工夫で乗り越えるのがもっと難しいものです。2人のチームは、単一障害点が2つあるのと同じです。1人が辞めれば、チームの半分と、システムの一部についての実務知識の大半を失います。一般的な意味での後継者育成は成り立ちません。控えの人材も、見習いも、順番を待つ次の担当者もいないからです。

リスクを和らげる方法はあります。記録を残すこと。新しく来たエンジニアが数か月ではなく数週間で戦力になれるよう、システムを小さく保つこと。AIツールを使って、予備知識のない人でもコードベースを読み解けるようにすること。すぐに読み直して理解し直せるシステムは、作った本人への依存度が下がります。

それでもリスクがなくなるわけではありません。リスクが現実になったときの衝撃を和らげるだけです。小さなチームが与えてくれるものと引き換えに、より大きなブレを受け入れる。その覚悟を、正直に持っておく必要があります。

AIが実際に変えるもの

AIと小さなチームについての議論の多くは、処理量の話に向かいがちです。AIでエンジニアの作業が速くなるから、小さなチームでも大きなチーム並みの仕事ができる、という論法です。私はこの捉え方が役に立つとは思いません。論点の立て方がずれていて、実際に起きていることを過小評価しています。

2人のチームでは、調整コストはもともとほぼゼロです。会議を減らしたりレビューを短くしたりして処理量を上げる余地はありません。そもそもそれが制約になっていなかったからです。AIが変えるのは「守備範囲」です。これまで無視するか外注するしかなかった領域にまで、チームの手が届くようになります。

具体例はデータパイプラインです。私たちにはデータエンジニアがいませんし、本格的なデータウェアハウスの設計もしていません。それでも、BigQueryへの自動化されたパイプラインを構築・運用し、変換処理はdbtで行っています。ビジネスに必要な水準は十分に満たしています。これまで見たなかで最も洗練されたものではありませんが、確かに存在し、動いていて、2人のエンジニアが責任を持っています。2年前なら、この作業は外注されるか、後回しにされるか、スプレッドシートで不十分に済まされていたはずです。それがいまは、チームの手の届く範囲にあります。

これが典型的なパターンです。AIのおかげで、小さなチームはこれまで手放すしかなかった領域を守れるようになります。運用、インフラ、社内ツール、ドキュメント。従来は専門家か大きなチームがいなければ吸収できなかった、細々とした仕事の数々です。2人が10人になるわけではありません。ですが、2人のチームが責任を持てる範囲は、確実に大きく広がります。

なぜ「つなぎ」ではないのか

2人チームは大きなチームになる前の初期段階で、問題はいつ採用するかだ。そう考えるのが自然かもしれません。でも私はそうは考えていません。このチームは、いずれ現れる「本当の答え」までの仮置きではなく、それ自体が仕事に対する答えなのです。

これがあらゆる仕事、あらゆる事業に当てはまるとは思いません。10人、20人、100人のエンジニアが本当に必要なプロダクトもあります。問題の範囲がそれ以上削れず、作業を順番に片付けていくことができないからです。私はそういうチームも率いてきました。焦点を絞りきれなかった失敗ではなく、その仕事にとって正しい形です。

一方で、2人チームが正しい形であり、ずっとそうであり続ける仕事や事業も確かに存在します。核となる部分がはっきりしていて、ユーザー像が明確で、並行して進めることより継続性のほうが価値を生むロードマップを持つプロダクト。スループットの遅さによる損失より、組織の断片化による損失のほうが大きい事業。こうした領域では、私は小さなチームを「我慢して受け入れる」のではなく、自ら積極的に選びます。

私の結論

私はもう、2人チームから人を増やすタイミングを待っていません。このチームこそが、仕事が求めている形だからです。人を増やしてもプロダクトは良くなりません。むしろ、ほかのチームが作るほかのプロダクトと似たものになり、一貫性が大勢の頭に分散して薄まってしまうでしょう。

2つの会社を同時に率いてみて、120人を率いていた頃には見えなかったことがはっきりしました。チームの規模は、本気度や野心の大きさを示すものではありません。設計上の選択です。2人のチーム、3人のプロダクトチーム、100人のエンジニア組織は、それぞれ異なる仕事に向いた、異なる楽器のようなものです。大切なのは、その仕事にどの楽器が必要かを見極め、選んだらそこに踏みとどまる覚悟を持つこと。いま私が率いる2つの会社では、その楽器は小さなチームです。そしてそれは序章ではなく、答えそのものなのです。

---