はじめに こんにちは、新規事業部フロントエンドブロックの 池田 です。普段は ZOZOマッチ のアプリ開発を担当しています。ZOZOマッチは、ファッションの好みからZOZO独自のAIが「好みの雰囲気」の相手を紹介するマッチングアプリです。開発にはFlutterを採用しています。 フロントエンドブロックは2024年に発足したチームです。発足間もないチームゆえに、開発を進める中でさまざまな課題に直面しました。本記事では、私たちが「課題をチーム全体で認識し、解決していける文化」を築くために取り組んできたことを紹介します。発足間もないチームでチームビルディングに悩んでいる方や、メンバー間の連携・知見共有に課題を感じている方、新規事業部の取り組みに興味のある方の参考になれば幸いです。 目次 はじめに 目次 背景・課題 取り組み KPTによる改善サイクル KPTから生まれた改善施策 進捗・困りごとの可視化 AIエージェントツール知見共有の仕組みづくり PRレビュー速度の改善 まとめ 背景・課題 フロントエンドブロックは3名と外部パートナーで構成されるチームです。新規事業部では、市場の変化に素早く対応しながらプロダクトを成長させていく必要があります。そのため、少人数でもスピード感を持って開発を進められる体制と、走りながら改善していける柔軟性が求められます。しかし、発足から日が浅いこともあり、チームとして改善サイクルを回す文化がまだ根付いていませんでした。開発プロセスや技術的な課題に直面しても、その解決が個人の力量に左右される状況があり、課題が個人の中に閉じてしまっていました。 具体的には以下のような問題がありました。 メンバーの困りごとが見えにくい ：各メンバーの抱える課題や悩みがチーム内で可視化されておらず、助け合いやサポートが難しい状態だった 改善を議論する場がない ：課題を感じても、改善案を提案・議論する場が整備されていなかったため、ナレッジがチームに蓄積されなかった こうした状況を打開するには、まずチーム全体で課題を共有し、改善を積み重ねていける仕組みづくりが必要でした。 取り組み ここからは、これらの課題に対してチームで取り組んできた改善施策を紹介します。まず改善サイクルを回すための仕組みとしてKPTを導入し、その中で見えてきた具体的な課題に対して個別の施策を実施してきました。 KPTによる改善サイクル チームとして改善を回していく文化を根付かせるため、KPT形式の振り返り会を実施しています。KPTでは、Keep（良かったこと）・Problem（課題）・Try（次に試すこと）の3つの観点で振り返ります。案件でやって良かった取り組みや大変だったことを洗い出し、次の案件へ活かせるようにしています。 振り返りの流れ 振り返りにはMiroを活用しています。具体的な流れは以下のとおりです。 付箋の記入 ：各メンバーがKeep・Problem・Tryの各エリアに付箋を貼る 投票 ：特に議論したい項目に投票し、優先度を付ける 議論 ：投票数の多い項目を中心に議論し、Problemに対しては具体的なTryを設定する 議論の際は、単に事象を共有するだけでなく、一歩踏み込んだ振り返りを意識しています。Keepについては「なぜうまくいったのか」を深掘りし、成功要因を言語化することで再現性を高めています。Problemについては「今後どうすればうまくいくか」をチームで話し合い、具体的な改善策を導き出すようにしています。次回の振り返りでは前回のTryの効果を検証し、継続するか改善するかを判断します。このサイクルを回すことで、個人の中で閉じていた課題がチーム全体で共有され、改善へつなげられるようになりました。 ツールと頻度の選定 振り返りツールにはいくつかの選択肢を試しました。当初は Findy Team+ のKPT振り返り機能や Parabol を使っていました。しかし、Miroに慣れているメンバーが多かったことと、付箋からJiraチケットへの変換が容易だったことから、最終的にMiroを採用しました。 頻度は隔週1時間程度で実施しています。 KPTを継続する中で、メンバー自らが課題を発見し改善策を提案するボトムアップの文化が根付いてきました。以降で紹介する施策も、その多くはKPTでメンバーから挙がった声がきっかけになっています。今後は付箋の数が減ってきたタイミングで、イベントタイムラインなどを取り入れることも検討していきたいと考えています。 KPTから生まれた改善施策 進捗・困りごとの可視化 KPTで「メンバーの困りごとが見えにくい」という課題が挙がりました。開発初期は特に実装するチケットが多く、誰がどのタスクを進めているのか、どこまで進んでいるのかが見えづらい状況でした。メンバーの進捗を日常的に把握するため、以下の取り組みを行っています。 朝のSlackスレッドでの共有 毎朝Slackのリマインダーが自動投稿されるので、出勤したらそのスレッドに今日やることを書くようにしています。テキストで残すことで、非同期でも状況を把握でき、困りごとがあればすぐにフォローできる体制が整いました。 スレッド内でのやり取りなので、気軽に質問を投げられるのもポイントです。業務に関する質問だけでなく、雑談や改善提案の話もそこから自然と生まれるようになりました。 夕会でのアクティブなスプリントの確認 フロントエンドブロックでは毎日夕会を実施し、今日やったタスクと困っていることを共有しています。 以前はメンバーがそれぞれやったことをConfluenceに書いて報告していました。しかし、この方法にはいくつかの課題がありました。 アサインされているチケットがどれくらいあるのか見えづらい レビュー待ちのチケットが溜まっているのか把握しにくい 書く人によってタスクの粒度が異なり、状況を正確に把握しづらい これらの課題を解決するため、Jiraのアクティブなスプリントを画面共有しながら進捗を確認する運用に変更しました。スクラムボードのアクティブなスプリントでは、現在進行中のタスクをステータス別（未着手・進行中・レビュー待ち・完了など）に並べカンバン形式で確認できます。 この変更により、各メンバーがアサインされているチケットやステータスが一目でわかるようになりました。ステータスが長く変わっていないチケットも把握できるため、困っていることがないか声をかけやすくなりました。また、報告のために文章を書く手間が減り、ボードを見ながら自然と議論が生まれるようにもなりました。 また、夕会では明日やることも共有しています。アサインされているチケットが前倒しで完了した人にはチケットが多い人から分配するといった、チーム内での負荷調整もこの時間で実施しています。 AIエージェントツール知見共有の仕組みづくり KPTでは「AI活用をチーム全体に広げたい」という声が挙がりました。ZOZOではClaude CodeやGitHub Copilotなど、さまざまな開発AIエージェントツールを利用できる環境が整っています 1 。新規事業部では、こうした新しい技術やツールを積極的に取り入れ、開発プロセスの改善にチャレンジできる文化があります。私たちのチームでは、執筆時点ではClaude Codeをメインに、実装からPR作成・レビュー・CI修正まで開発プロセス全体で活用しています。特定のツールに限定するルールは設けておらず、Codexなど他のツールで検証するメンバーもいますが、チーム全体としてはClaude Codeの利用が中心です。しかし、AIツールを使いこなしているメンバーとそうでないメンバーとの間に差があり、チーム全体で活用していくにはまだ改善の余地がある状態でした。 この状況を改善するため、チーム内で知見を蓄積・共有するための仕組みを整備しました。 AI関連の知見を集約するSlackチャンネル AI活用に関する知見を集約する専用のSlackチャンネルを開設しました。このチャンネルにはエンジニアだけでなく、PMやビジネスなどのメンバーも参加しており、日々の業務改善にAIを活用できないかざっくばらんに話し合っています。チャンネルでは以下のような情報を共有しています。 「こういう場面で使えた」という活用事例 ツールの設定方法やTips 勉強になった記事の共有 記事を共有する際には、チームとして取り組めそうな部分についても議論しています。チャンネルを開設したことで、メンバー全体のAI活用度が向上しました。また、AIに関する質問や相談が気軽にできるようになり、知見がチームへストックされるようになりました。 Claude Codeプラグインの共有リポジトリ Claude Codeにはプラグインとマーケットプレイスという機能があります。プラグインはClaude Codeの機能を拡張するための仕組みです。 公式ドキュメント では以下のように説明されています。 Plugins let you extend Claude Code with custom functionality that can be shared across projects and teams. プラグインには、再利用可能な命令セットである「スキル」、外部ツールと連携するための「MCPサーバー」、イベント駆動型の自動化を行う「フック」などのコンポーネントを含めることができます。マーケットプレイスは、これらのプラグインを配布・共有するためのカタログです。マーケットプレイスを追加すると、そこに登録されているプラグインを簡単にインストールできます。 私たちはこの機能を活用し、プロジェクト用の共有リポジトリを作成しました。このリポジトリは以下の目的で整備しています。 プロジェクト全体でAI活用できる環境を整備する チーム間でのAIの知見を共有できるようにする 車輪の再発明を防ぐ リポジトリには、各チームが必要なプラグインを追加していく運用にしています。現在はAtlassian MCP関連、Git関連、FlutterやWeb関連など、さまざまな用途のプラグインが集約されています。 リポジトリの構成は以下のようになっています。 plugins/ ├── atlassian-mcp/ ├── browser/ ├── flutter/ │ ├── .claude-plugin/ │ ├── skills/ │ └── .mcp.json ├── git/ │ └── .claude-plugin/ └── commands/ ├── branch/ ├── commit/ ├── issue/ └── pr/ └── help.md 各プラグイン（ flutter/ 、 git/ など）の中には、 .claude-plugin/ ディレクトリやスキル、MCPサーバーの設定ファイルが含まれています。 commands/ ディレクトリには、ブランチ作成やコミット、PR作成などの汎用的なカスタムコマンドを集約しています。 運用としては、新しいコマンドやプラグインを追加したい場合はPRを出してもらい、レビュー後にマージする流れです。また、新規プラグインをメンバーがキャッチアップできるよう、リポジトリの更新内容を先述のAI知見共有チャンネルへ自動投稿するGitHub ActionsのWorkflowも導入しています。 共有リポジトリを整備した1つ目のメリットは、Claude Codeのマーケットプレイス機能を活用することで、導入の手間を大幅に削減できる点です。プロジェクトの .claude/settings.json に extraKnownMarketplaces を設定すると、メンバーがプロジェクトを開いた際にプラグインがインストール候補として提示されます 2 。この設定ファイルはGitで管理されるため、チーム全体で共有でき、新しいメンバーも特別な手順なしで利用を開始できます。また、マーケットプレイスの自動アップデート機能を有効にすると、プラグインに更新があった際に自動で最新バージョンに更新されます 3 。そのため、チーム全体で常に最新のプラグインを利用できます。 { " enabledPlugins ": { " flutter@xxxx-marketplace ": true , " git@xxxx-marketplace ": true } , " extraKnownMarketplaces ": { " team-tools ": { " source ": { " source ": " github ", " repo ": " org/claude-plugins " } } , " project-specific ": { " source ": { " source ": " git ", " url ": " https://github.com/org/claude-plugins.git " } } } } 2つ目のメリットは、アプリ・バックエンド・Webの各チームで個別に管理していたスキルを一元管理できるようになり、知見の共有が促進された点です。同じようなプラグインを各チームで作成する重複作業がなくなり、他のチームが活用している便利なスキルをキャッチアップしやすくなりました。 PRレビュー速度の改善 KPTでは「PRレビューが遅い」という課題も繰り返し挙がっていました。レビュー依頼からマージまでのリードタイムが長く、各自の実装タスクが優先されることでレビューが後回しになりがちでした。この状況を改善するため、以下の取り組みを行いました。 Findy Team+によるレビュー状況の可視化 Findy Team+を利用し、PRのレビュー時間やサイクルタイムを可視化しています。KPT振り返り会では、Findy Team+のサイクルタイム分析やレビュー分析を定期的に確認しています。全体の指標を俯瞰しつつ、数値が悪化している項目を重点的にチェックすることで、開発プロセスのどこにボトルネックがあるのかをチームで共通認識として持てるようになりました。 実際にこの分析を通じて、KPTで挙がっていた「PRレビューが遅い」という課題がデータでも裏付けられました。感覚的な指摘が数値として可視化されたことで、具体的な改善アクションへつなげられるようになりました。 Google Engineering Practices Documentationの輪読会 レビュー待ち時間が長いという課題を受けて、 Google Engineering Practices Documentation の輪読会を実施しました。このドキュメントでは、コードレビューが遅れることによる弊害として以下の点が挙げられています。 チーム全体の開発速度が低下する ：新機能やバグ修正のリリースが遅延し、チーム全体のベロシティに影響を与える 開発者の不満が増加する ：レビューの滞りは開発者のモチベーション低下を招き、チームの雰囲気にも悪影響を及ぼす コード品質が悪化する ：レビューの遅れはPRの肥大化を招き、結果的にレビューの質も低下する悪循環に陥る 輪読会を通じて、これらの弊害をチームで共有しました。また、コードレビューはタスクの合間に行うものではなく、優先度の高い作業として扱うべきという認識を揃えることができました。さらに、輪読会はメンバー同士がコードレビューに対する考え方や心理的なハードルを知る機会にもなりました。「どこまで指摘すべきか迷う」「実装チケットを優先的に終わらせたい」といった悩みを共有することで、お互いの視点を理解し、レビューの進め方について建設的な議論ができました。 AI活用による効率化 レビュー時に「不具合の原因や実装背景が分かりづらい」「動作確認の手順が不明確」といった意見も挙がっていました。これらの課題についても、Claude Codeを活用して改善に取り組んでいます。具体的には、以下のようなカスタムスキルを整備しました。 スキル 用途 /pr-create 変更内容の要約に加え、不具合の原因や実装背景、動作確認の手順を含めたPRを作成する /pr-review コード規約やベストプラクティスに基づいたレビューコメントを生成する /pr-ci-fix CIの失敗原因を分析し、修正してコミットする /flutter-code-review ZOZOマッチアプリのコード規約をスキルとして登録し、実装やレビューの際に規約に沿った指摘ができるようにする これらのスキルにより、定型的な作業の時間を削減し、本質的なレビューへ集中できるようになりました。 さらに、Codexを活用したPRの自動レビューも導入しています。PRをオープンすると自動でCodexがコードレビューを実施するため、レビュアーはCodexの指摘を踏まえつつ、人間ならではの観点でレビューできるようになりました。 PRレビュー改善の成果 これらの取り組みの結果、Findy Team+の各分析で改善が確認できました。 サイクルタイム分析では、以下の改善が見られました。 PR作成数が約3倍に増加 ：AI活用の促進やレビュープロセスの改善により、PRを細かく分割して作成する文化が浸透しました オープンからマージまでの平均時間を約70％改善 ：レビュー待ち時間の可視化やCodexによる自動レビューの導入により、レビューのリードタイムが大幅に改善しました 一方で、グラフからはPR作成数が多い週ではマージまでの時間が増加する傾向も見て取れます。PRの量が増えるとレビュー負荷が高まり、結果としてリードタイムが延びてしまうという課題が残っています。今後は、レビュー体制の強化やさらなる自動化を通じて、PR数が増加してもマージまでの時間を維持・短縮できる仕組みづくりに取り組んでいきたいと考えています。 レビュー分析でも、Codexでの自動レビューとClaude Codeのスキル整備の前後で、各指標に改善が見られました。 指標 改善前 改善後 オープンからレビューまでの平均時間 10.3h 7.5h レビュー依頼からレビューまでの平均時間 10.1h 8.1h レビューからアプルーブまでの平均時間 17.1h 9.3h 特にレビューからアプルーブまでの平均時間は17.1hから9.3hへと約46％改善しました。Codexによる自動レビューでレビュアーの負担が軽減されたことに加え、輪読会を通じてレビューの優先度に対する意識が変わったことも、この改善に寄与していると考えています。 まとめ 本記事では、発足間もないチームが「課題をチーム全体で認識し、解決していける文化」を築くために取り組んできたことを紹介しました。KPTによる振り返りを起点に、進捗・困りごとの可視化、AIエージェントツールの知見共有、PRレビュー速度の改善といった施策を実施してきました。これらの取り組みを通じて、個人の中に閉じていた課題がチーム全体で共有され、継続的に改善を回せる体制を整えることができました。今後はDevinやFigma MakeといったAIツールも活用しながら、チーム内の改善にとどまらず、プロジェクト全体に対しても改善を働きかけていきたいと考えています。発足間もないチームでチームビルディングに悩んでいる方や、改善サイクルを回す仕組みづくりに課題を感じている方の参考になれば幸いです。 ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。 hrmos.co 2026年1月時点におけるZOZOで利用可能な代表的なAIツールは「 ZOZOにおけるAI活用の現在 ~開発組織全体での取り組みと試行錯誤~ 」をご参照ください ↩ Configure team marketplaces - Claude Code ↩ Configure auto updates - Claude Code ↩

この記事は、 NTT docomo Business Advent Calendar 2025 14日目の記事です。 こんにちは、社内データ分析コミュニティ「データサイエンスちゃんねる」の是松です。 普段はジェネレーティブAIタスクフォースに所属しており、特定の業務に特化したAIエージェントの開発などを行っています。 データサイエンスちゃんねるでは、社内向けの輪読会やKaggle LT会など、社内のデータサイエンスに興味があるメンバーの交流を目的とした活動を行っています。 本記事では、データサイエンスちゃんねるの目玉活動になりつつある「データ分析開発合宿」について、運営目線での話をしたいと思います。 社内イベントの企画・運営に興味がある方の参考になれば幸いです。 データ分析開発合宿とは？ 運営のお仕事 ステークホルダーへの説明 サービスログを提供するサービス主管との調整 イベント会場の確保 参加募集 分析環境の準備 イベント対応 事後対応 第３回での変更点 分析サービスの一本化 宿泊から通いへ 振り返りと今後の展望 運営のコツ 今後の展望と課題 データ分析開発合宿とは？ データ分析開発合宿とは、所属に関係なくデータ分析が好きな社員が集まって短期集中でデータ分析に取り組むというイベントです。 普段は交流する機会の少ないメンバーが集まり、社内のサービスログの分析を通して交流を深めます。 毎年秋ごろに開催しており、第1回と第2回は30名程度、先月実施した第3回は10名の参加者が集まりました。 過去の記事はこちら( 第1回前編 、 第1回後編 ) データ分析開発合宿の目的は主に2点です。 社内にあるさまざまなサービスログを、合宿参加者の新たな視点で分析し、活用例を示し、サービス改善を図る データ分析スキルを持つ人材の横のつながり強化と、チャレンジできる実践の場を作る イベントは3つのステップに分かれています。 Step1: キックオフ 参加者顔合わせ、サービス・課題概要説明、分析テーマ・チーム決め（3時間程度） Step2: 課題ヒアリング 業務の合間に、サービスログデータの確認や課題の深掘りを行い、疑問点などをヒアリングする（1時間 x 数回） Step3: 分析 三日間にわたる短期集中での分析、課題解決のための施策提案にチーム単位で取り組む。 最終日に各チームごとの成果を発表する。 単にデータ分析をするのではなく、課題ヒアリングを経て仮説を立て検証し、最終的にサービス主管へ提案する必要があります。 参加者からは「貴重な実データを分析する機会だ」と評価を受けております。課題ヒアリング、仮説検証、提案準備など、実践的なスキルも養うことができます。 運営のお仕事 本イベント開催にあたり、運営としてのタスクを簡単に紹介します。 データサイエンスちゃんねるのメンバーを中心にさまざまな部署に所属する9名が運営に携わり、分担して準備を進めました。 ステークホルダーへの説明 本イベントの予算を出していただいているコミュニケーション＆ネットワークサービス部や、分析プラットフォームの管理をしているデジタル改革推進部など、 関係各所に対してイベントの目的や期待される成果・セキュリティ対策等を説明します。 特にセキュリティに関しては多くの方が気にされるところであり、分析環境や分析データの個人情報の取り扱いなど、丁寧にコミュニケーションをとりながら問題がないように準備を進めていきます。 サービスログを提供するサービス主管との調整 各運営メンバーのコネクションを活用して、分析合宿に協力してくれそうなチームとコンタクトをとり、協力を打診します。 分析データの共有と、課題ヒアリングのための情報提供が主な依頼事項です。 分析データは適切に匿名化し、特定をできないように加工も行います。 イベント会場の確保 イベント会場の準備をします。 第1回と第2回ではホテルのホール会場を利用していましたが、今年は宿泊を伴わない形式に変更し、イベント会場を利用しました。 参加募集 募集要項を作成し、社内に周知します。 過去の合宿参加者や、運営メンバーの伝手を辿って個別の声かけも実施します。 分析環境の準備 NTTドコモビジネスには、 DLX と呼ばれる全社員が使える分析基盤があり、本イベントもその環境を活用しています。 分析データの整備、アクセス管理を行います。 イベント対応 キックオフ、課題ヒアリング、本番の分析の各ステップに運営として立ち合います。 事後対応 分析データはイベント終了後に削除等の対応を適切に行います。 参加者アンケートの実施、ステークホルダーへの報告、各種周知活動（本記事もその一環です）等を行います。 第３回での変更点 イベントを重ねる中で、今年は方針をいくつか変更しました。 分析サービスの一本化 第1回は3サービス、第2回は5サービスを題材とし、チームごとに取り組むサービスを選ぶ形式をとっていました。 社内サービスの改善という目的を考えると、選択肢が増えるのは良いことではあるのですが、運営を続ける中で下記のような課題感が出てきました。 分析の質：サービスが複数あることで、1つのサービスあたりの分析チーム数が減り、多角的な視点での深掘りがしにくくなる サービス選択の偏り: せっかく協力してもらったのに、どのチームにも選ばれないサービスが出てしまうリスクがある 運営コスト: 複数サービスのログ提供調整を並行して行うため、運営メンバーの負荷が高い ここで述べた以外の要因もあり、第3回では「1つのサービスを全員で多角的に深掘りする」という方針に切り替えました。 1つのサービスに対して複数の分析テーマを用意し、チームごとに1つのテーマを選んで取り組んでもらうことで、短期間でも効果的な分析ができるようにすることが狙いです。 今回はサービスログ提供のための事前調整が想定以上に難航した背景もあり、サービスを1つに絞ったことで、結果的には運営リソースをパンクさせずに開催できました。 とはいえ、基本的には取り組むテーマの選択肢が多いことはイベントの魅力に繋がりますので、次回は今回の課題への対策を議論した上で、最適な方針を決めていきたいと思います。 宿泊から通いへ 第1回、第2回はホテルでの合宿形式で開催していましたが、昨今の宿泊費高騰の影響を受け、予算内で適切な宿泊施設を見つけることが困難となりました。 そのため、第2回のキックオフで使用した会場 docomo R&D OPEN LAB ODAIBA を利用し、宿泊を伴わない「通い」形式での開催に変更しました。 「寝食を共にして横のつながりを強化する」という合宿本来の醍醐味が薄れる懸念はありましたが、会場変更には以下のようなメリットもありました。 配信品質の向上: ネット環境や設備が整っているため、成果報告会のライブ配信品質が向上し、オンライン視聴者が大幅に増えた コストと手間の削減: 会場費が無料であり、宿泊手配にかかる事務作業も不要になった また、運営側としては「宿泊なしの通い形式にすることで、業務の合間や家庭の事情に合わせて参加しやすくなり、参加者が増えるのでは」と期待していました。 しかし、蓋を開けてみると前述の通り参加者は前回より減少してしまいました。また参加者アンケートからも宿泊形式を望む声が少なくなかったので、 次回の方針については、改めて議論をしていきたいと思います。 振り返りと今後の展望 手探りで3年間進めてきた本活動ですが、3年間の活動を通じて、重要なポイントが見えてきました。 運営のコツ ステークホルダーにメリットのある設計：データ分析イベントで障壁となりがちな「分析データの確保」ですが、本施策では「サービス主管の困りごとを解決する」という出口を明確にしました。主管部署には「課題解決のヒント」を、参加者には「実践的な成長機会と交流の場」を提供することで、双方から積極的な協力を得られたと思います。 組織へのアピール力を高めるコンセプト設定：単なる交流会に留めず、「人材育成」と「サービス価値向上」という経営層にも伝わりやすい目的を企画段階で固めたことで、各組織からの理解と支援を得やすい企画になりました。 今後の展望と課題 第3回では「参加者の減少」という新たな課題に直面しましたが、一方で「少人数だからこそ、チームを越えた密な議論やフィードバックが生まれた」という、規模を追うだけでは得られない価値も発見できました。 今後は、この「密な体験」という良さを活かしつつ、知名度向上や開催時期の最適化を行い、より多くのメンバーが参加しやすい形を模索していきます。また、提案した施策のその後の効果検証など、さらに踏み込んだ取り組みにも挑戦したいと考えています。 来年以降も、この「データサイエンスちゃんねる」が社内のデータ活用を加速させる場であり続けられるよう、改善を止めることなく進化させていきます！

はじめに こんにちは。タイミーでエンジニアリングマネージャー（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(※職能ごとの横断コミュニティ)の力も借りながらではありますが、チームメンバー全体でフロントエンド領域のタスクを巻き取る動きが加速しました。リソースが足りないという状況が、結果としてチーム全体のフルスタック化を、実践レベルで前進させました。 3. MTGの発言量が爆増した 人数が多いMTGだと、どうしても一人ひとりの発言時間は少なくなってしまいがちです。 今回、リチーミングによりチーム人数が減ったことで、全員がより当事者としてスプリントゴールを目指す状況となりました。その結果、ほぼすべてのMTGでマイクをミュートにすることがなくなるほど、一人ひとりの発言量と議論の密度が劇的に向上しました。 まとめ：変化こそが、組織を強くする 今回の経験を通じて、アイソレーションパターンは単なる緊急時の対症療法ではないと痛感しました。 それは、重要なプロジェクトを成功させるための強力な武器であると同時に、既存チームに健全な揺らぎを与え、メンバーの新たな可能性を強制的に（しかしポジティブに）開花させるきっかけでもありました。 人が動くことで、組織全体の成果の総和は減るどころか、むしろ増える。 誰かが抜けた穴は、決してネガティブな空白ではなく、他の誰かが一歩前に踏み出すための「成長の余白」だったのだと思います。 本で理論を学び、現場で実践し、予想以上の成果を得る。EMとして、非常に学びの深い1年となりました。 組織の変化を恐れず、来年もダイナミックに挑戦していきたいと思います。 本質的な課題解決とメンバーの成長を両立させるダイナミックな組織運営に興味がある方、変化を楽しみながら成長したいと思っている方、ご興味があればぜひお話ししましょう！ プロダクト採用サイトTOP カジュアル面談申込はこちら