ダイナミックリチーミングの実践：その確かな有用性と、意外な副産物について

はじめに

こんにちは。タイミーでエンジニアリングマネージャー（EM）をしているshuです。 (本記事はTimee Advent Calendar 2025 シリーズ3の19日目の記事になります。)

最近、社内のEMたちとHeidi Helfand氏の著書『ダイナミックリチーミング（Dynamic Reteaming）』の輪読会を行っています。この本は、従来の「チームは固定化されるべき」という常識を覆し、チーム編成を動的に変えることで組織の健全性と成長を促す手法について書かれた良書です。

読み進める中で、今年自分がアサイン責任者として対応した大規模プロジェクトの記憶が鮮明に蘇ってきました。

「あれ？あの時、必死で判断して実行したあの体制変更、まさにこの本に出てくる『アイソレーションパターン』そのものじゃないか？」と。

今回の記事では、今年発生した緊急プロジェクトでの実践を振り返りつつ、アイソレーションパターンの有効性と、そこで得られた「残された側のチームに起きた意外な副産物」についてシェアしたいと思います。

突発的な大規模プロジェクトと、急造チームの決断

今年、私が担当する領域で、大規模プロジェクトが突発的に立ち上がりました。

その性質は、EMにとっては胃が痛くなるようなものでした。

影響範囲が極めて広範囲に及ぶ
絶対に動かせないハードデッドラインがある
既存チームが片手間でこなせる量ではない

私はこのプロジェクトの立ち上げとチーム組成を担当することになりましたが、プロジェクトの性質に加え、タイミーのシステム特性や現在の開発チーム体制などを総合的に鑑みて、「既存の運用体制のままでは絶対に間に合わない」と判断しました。

そこで断行したのが、あるチームをベースにしつつ、プロジェクトに必要なドメイン知識やケイパビリティを持つメンバーを様々なチームから招集し、専任の「急造チーム」を組成するというリチーミングです。（個人的には、各チームの状況を鑑みながらメンバーを出してもらう、この調整業務が本当に非常に大変でした…）

後から本を読んで整理できたのですが、これは「アイソレーションパターン」と呼ばれる手法そのものでした。

アイソレーションとは、チームを意図的に切り出して分離・隔離し、既存のプロセスやルールから解放された違うやり方で仕事を進める自由を明示的に与えるパターンです。

主な目的:

イノベーション: 新しい大胆なアイデアの追求
緊急事態: 予期しない問題への集中対処
停滞の打破: プロセスが重くなった「硬直化の罠」からの脱出
アイソレーションパターン

このパターンについては、一般的な推奨事項は5つ紹介されています。その中で自分が重要だと考えているのが、以下の3点です。驚いたことに、今回の急造チームは無意識のうちにこれらのセオリーをなぞっており、それぞれがプロジェクトの成功に大きく寄与していました。

1. 専用スペースへの移動

本では物理的な部屋への移動が推奨されていますが、弊社はフルリモート体制のため、これは「専用チャンネルへの集約」として実践されました。

メンバーを既存チームから引き抜くと同時に、専用のSlackチャンネルを作成し、開発に関するすべてのやり取りや意思決定をそこで完結させるようにしました。オンライン上であっても、あたかも隔離された部屋にいるかのような没入環境を作り出すことで、コミュニケーションコストを最小限に抑えました。

2. プロセスの自由

「隔離」されたチームは、既存組織のルールに縛られず、最適なプロセスを選択できます。

タイミーの開発チームの多くは普段スクラム開発を採用していますが、今回のプロジェクトはハードデッドライン必達かつ手戻りが許されない状況でした。そこで、このチームに関しては普段のやり方に固執せず、PjM/PdMによる強力な進行管理のもと、ウォーターフォールに近い開発スタイルを採用しました。

このプロジェクト専用に最適化された独自のリズムで動くことで、迷いなくゴールへ突き進むことができました。

3. 邪魔をさせない

メンバーが目の前の課題に集中できるよう、外部からの干渉を遮断することも重要です。

これについては、プロダクト組織のエグゼクティブ(CXOやVPoXなど)から、このプロジェクトが全イニシアチブの中で最優先事項であると定義・宣言してもらい、全プロダクトメンバーにその認識を持ってもらうことで実現しました。

トップダウンによる強力なバックアップがあったおかげで、他の運用業務や開発などの差し込みが入ることがなく、メンバーは余計なノイズに惑わされることなく開発に集中することができました。

当時は「間に合わせるためにはこれしかない」という必死の判断でしたが、結果としてアイソレーションパターンは極めて有効に機能し、厳しいデッドラインを守り切ることができました。

そして、このリチーミングにはもう一つ、私にとって嬉しい誤算とも呼べるポジティブな副産物がありました。

本には書かれていない「既存チーム」の進化

それは、EMとして最も懸念していた人を引き抜かれた側の状態についてです。

今回のケースでは、複数のチームからドメイン知識を持つメンバーが招集されました。私が管掌するチームからも、フロントエンド領域を専門とするメンバーが1人、プロジェクトにアサインされました。

専門領域を持つメンバーが抜けることで、「残されたチームでの開発は立ち行かなくなるのではないか？」という懸念がありました。

しかし、あくまで私の管掌範囲内での観測にはなりますが、蓋を開けてみると、そこには本には書かれていない意外な化学反応が起きていました。

1. 空白がオーナーシップを醸成

人が減ったことで、物理的にリソースが不足します。すると不思議なことに、「誰かが拾ってくれるだろう」という無意識の前提がなくなりました。

「自分が拾わないと落ちる」

そんな健全な危機感が生まれたように感じます。これはまさに、タイミーが大切にしている新しいバリューの1つ「ジブンゴト」が、極限状態で体現されたと思います。誰かに言われてやるのではなく、構造的な空白が、彼らのオーナーシップを引き出しました。

2. 越境文化がより強まった

ここ1年半ほど、タイミーのSA(StreamAligned)チーム(※顧客価値に向き合う最小単位の開発チーム)では、領域を越境した開発が推奨されており、私自身もチームにそれを求めていました。特に今年は、AIコーディングツールの進化もあり、越境のハードル自体は下がっていました。

今回、フロントエンドの専門メンバーが抜けましたが、半分は意図的に、半分は状況的に、あえて即座にそのケイパビリティを持つバックフィルを用意しませんでした(もちろんうまくいかなかった時にサポートできるオプションは持ちつつ)。代わりに、メンバーにはこれを機に越境してほしいと伝えました。

その結果、移動したメンバーやFrontend Chapter(※職能ごとの横断コミュニティ)の力も借りながらではありますが、チームメンバー全体でフロントエンド領域のタスクを巻き取る動きが加速しました。リソースが足りないという状況が、結果としてチーム全体のフルスタック化を、実践レベルで前進させました。