running-work-transitions

Bitwarden では、チーム間でロジック、パターン、ツール、またはプロセスの所有権を移行するために、Work Transition Playbook を使用します。最も一般的なきっかけは、取り組みがフェーズ 4 から 5 に移行するときです。シェパードがスコーピングとコミットメントを終え、チームが実装を担当する段階に入ります。ただし、このプレイブックは汎用的です。Platform がフレームワークをプロダクトチームに引き継いだり、SRE がランブックを引き継いだり、別のプロダクトチームが自分たちの担当ではなくなったインテグレーションを移管したりする場合にも使えます。どの方向への移行にも同じプレイブックが適用されます。

このスキルでは、移行の両側を扱います。ファネルの仕組みをより広く扱う Skill(navigating-the-initiative-funnel) を補完するものです。

「移行」が実際に意味すること

プレイブックから次の一文を読み、両チームがそれに沿って行動するようにしてください。移行の成功とは、ドキュメントが共有されたときや会議が開かれたときではなく、引き継いだ作業を受け入れ側のチームが自信を持って独立して進められるようになったときです。

以下の 6 つのフェーズに含まれるすべての要素は、その結果を実現するためのものです。セッション、ドキュメント、状況確認は手段であり、目標ではありません。

どちら側ですか？

• 受け入れ側。 別のチームから作業を引き継ぎます。通常、受け入れ側のチームは、指名された主要な窓口担当者（プレイブックでは「通常はテックリードまたはシニアエンジニア」と明記されています）が代表します。引き継ぐ内容を評価し、チームが受け入れる準備を整え、サポート期間を効率的に進めることが役割です。
• 引き継ぎ元。 別のチームに作業を引き継ぎます。これは、他のチームによる採用を想定したフレームワークやパターンをチームが構築した場合、より小規模な取り組みを別のチームによる実装までシェパードした場合、または運用上の責任が移る場合に該当します。受け入れ側のチームが自立して作業できるように資料を準備し、引き継ぎ後は主導するのではなく支援することが役割です。

フェーズは両側で同じですが、責任は異なります。同じ取り組みの別の時点で、参加者が両側を担う場合（単一チームに隣接する取り組みをシェパードする際によくあります）は、両方のセクションを読んでください。

受け入れ側から見た 6 つのフェーズ

フェーズ 1 — 準備

移行セッションの日程を決める前に、移行元チームが資料を準備します。移行先チームは、移行を受け入れる前に資料を評価します。

確認事項：

• ドキュメントが十分であること。 移行先チームの有能なエンジニアが、ドキュメントを受け取って自力で作業できる状態であるべきです。ドキュメントが不十分であれば、異議を申し立ててください。チームが継続して対応できない移行を受け入れてはいけません。
• Jira が分かりやすいこと。 エピックには内容が伝わる概要が記載されています。ストーリーは、移行先チームがさらに詳細化できる粒度で用意されています。あらかじめ作成されたスプリント計画をそのまま渡されるほど具体的ではなく、スコープを再調査する必要があるほど曖昧でもありません。
• 関係者と連絡先が特定されていること。 移行先チームは、サポート期間中に必要となる背景情報を持つ移行元側の担当者を把握しています。また、進捗を気にかける関連する関係者（リーダーシップ、PM、他のチーム）も把握しています。
• 移行先側に指名された主担当の連絡先（POC）がいること（通常はテックリード、ときにはシニアエンジニアです）。EM も状況を把握し、支持しています。
• 引き継ぎ後の作業量を正直に評価していること。 「新しいものを採用する」ことだけを計画している移行では、実際のコストを過小評価しています。次の 3 つの軸を明示的に評価してください。
  • 実装と統合。 移行した成果物を移行先チームの領域で実用化するには、どのような作業が必要ですか？パターンの適応、統合の接続、テストの作成、ワークフローの更新などです。
  • 既存のプロセスとコードの段階的な廃止。 新しい成果物が既存のものに取って代わる場合、その既存のものを廃止する作業も独立したスコープです。通常、移行先チームは、従来のアプローチが実際にどのように機能しているかを最も深く理解しています。その知識を活用してください。
  • 継続的な保守とバグ修正。 サポート期間の終了後は、誰が何を担当しますか？ほとんどの移行では、移行先チームが採用したすべてのものを担当します。共有フレームワークやライブラリの場合、移行元チームが一部の保守を引き続き担当することもあります。所有権の境界がどこにあるか、明確に確認してください。

不明な点があれば、今のうちに明らかにしてください。準備段階は、ギャップを最も低コストで埋められるタイミングです。

フェーズ 2 — 移行セッション

少なくとも 2 回のセッションを、1〜2 週間の間隔を空けて実施します。移行先チームは準備して参加し、2 回目にはより具体的な質問を持ち寄ります。

• セッション 1（背景とアプローチ）。 セッション前にドキュメントを確認します。理想的には、数営業日前までに確認してください。セッションでは、解決しようとしている問題、そのアプローチを選んだ理由、PoC またはフレームワークの説明、より大きな取り組みの中でこの作業がどのように位置づけられるかを理解します。自由に質疑応答を行います。このセッションでは、主に話を聞きます。
• セッション 2（実践と計画）。 この時点までに、移行先チームはコードやツールに触れているはずです。実際の実装を読んで初めて出てくる質問を持ち寄ります。チームがこの作業をどのように統合、拡張、またはスケジュールするかを話し合います。ドキュメントの不足を明らかにします。サポート期間の内容について合意します。

複雑な移行や重要度の高い移行では、追加のセッションが必要になる場合があります。セッション 2 の終了時に、両チームで追加のセッションが必要かどうかを判断します。

フェーズ 3 — サポート期間

セッション終了後、移管元チームは引き続き対応可能な状態を保ちますが、主導する立場からサポートする立場へと移ります。標準的な期間は、複雑さに応じて 4～8 週間です。

移管元チームに相談すること：

• ドキュメントで触れられていない、アプローチに関する質問、意図、エッジケース。
• 初期 PR の認識合わせのレビュー — 修正が容易なうちに、意図したパターンとのずれを見つけてもらいます。
• 本番環境の実情から当初のアプローチの調整が必要と思われる場合の、選択肢の評価。

移管元チームに依頼しないこと：

• 移管先チームの作業に対する門番役。移管元チームはアドバイザーであり、承認者ではありません。
• 移管先チームに代わって作業すること。移行は作業の引き継ぎであり、一時的な貸し出しではありません。

プレイブックで重要な前提として示されているのは、移行が完了したからといって、移管先チームがすぐに作業を開始するとは限らないということです。移管された作業は、製品ロードマップのコミットメント、ほかの取り組み、バグ、技術的負債など、チームがすでに抱えている優先事項と競合します。引き継ぎから実際の作業開始までに遅れが生じるのは、通常のことであり、想定されています。

**通常ではないこと：**移管先チームが優先しないため、移管元チームがひそかに作業を再開することです。これはリーダーシップの話し合いで解決すべきことであり、両チームとエンジニアリング部門のリーダーシップが協議する必要があります。回避策で対処する問題ではありません。エグゼクティブによるリソース配分は、ファネルのスコープ設定とコミットメントのフェーズで行われます。そのコミットメントが優先順位付けされた作業につながっていない場合は、移管元チームに不足分を埋めさせるのではなく、エスカレーションしてください。

フェーズ 4 — 状況確認（移行から約 30 日後）

15～30 分の会話、または非同期のスレッドで行います。これは、引き継いだ作業が「実際にはまったく着手されなかった」という事態を防ぐ、重要なチェックポイントです。

確認する質問：

• 移管先チームは、移管された資料を使って作業を始めていますか？まだの場合、何が妨げになっていますか？
• 未回答の質問や、ドキュメントが不十分だと分かった箇所はありますか？
• チームはアプローチに納得していますか？それとも、アプローチとの不一致を示すような回避策を講じていますか？
• サポート期間の調整が必要ですか？延長または短縮しますか？

チームがまったく作業を始めていない場合は、懲罰的にではなく、エスカレーションしてください。原因がキャパシティなのか、優先順位の競合なのか、それとも移行に実際の不足があったのかを把握します。対処しないままにしておくと、この段階で取り組みが頓挫します。

フェーズ 5 — 振り返り（移行から約 90 日後）

両チームが参加する、45～60 分の正式なミーティングを行います。目標は、活用状況を評価し、移行プロセスについてフィードバックを得て、今後の移行に役立つ学びを記録することです。

議題：

• **活用状況の評価。**作業は意図したとおりに使われていますか？移管先チームは拡張しましたか？逸脱や未活用の領域はありますか？
• **移行プロセスへのフィードバック。**うまくいったことは何ですか？ドキュメント、セッション、サポート期間に不足していたものは何ですか？どうすればもっとスムーズになりましたか？
• **今後の移行に役立つ学び。**プレイブック自体のどこを変更すべきですか？
• **残っている不足。**未解決の問題、追加で必要なドキュメント、さらなるサポート。

調査結果を記録します。振り返りでプロセスの改善点が見つかった場合は、プレイブックに反映してください。Bitwarden の移行は、チームが学んだことを追加することで、より良くなります。

フェーズ 6 — 完了

次の条件を満たしたとき、移行は完了です。

• 移管先チームが、移管された作業を独立して進めている。
• サポート期間が終了している（または相互の合意により、明示的に早期終了している）。
• 振り返りが実施され、調査結果が記録されている。
• 未完了のアクション項目に担当者と期限が設定されている。

完了時には、移行が完了したことを正式に確認します。両チームに明確な合図が必要です。移管先チームは自律しており、明示的に再度協力を求められない限り、移管元チームは責任を負いません。

移管元チーム側から見た 6 つのフェーズ

フェーズ 1 — 準備

引き継ぎ元のチームは、引き継ぎ先のチームが頼りにする資料を準備します。目指すべきなのは「誰かが知っていることが、どこかにすべて書かれている」状態ではなく、「引き継ぎ先の優秀なエンジニアが資料を受け取り、自力で作業できる」状態です。

用意するもの：

• アプローチ、パターン、重要な決定事項を説明する技術ドキュメント。 既存の ADR、アーキテクチャ計画、PoC のプルリクエストを重複して作成するのではなく、参照してください。ただし、参照先が最新で、アクセス可能であることを確認してください。
• 引き継ぐ内容と、引き継ぎ先のチームに期待される最終状態を明確に説明したもの。 資料の山から範囲をリバースエンジニアリングさせないでください。
• 既知の制限事項、エッジケース、意図的に選択したトレードオフ。 これらは後から再構築するのが最も難しいため、書き留める価値が特に高い情報です。注意深く読んだ人が驚くようなことは、すべてここに記載してください。
• Jira の整理。 引き継ぎ先チームの担当領域について、範囲と期待される成果がわかる説明的な概要を付けたエピックを作成します。ストーリーは、引き継ぎ先のチームが詳細化できる粒度にします。あらかじめ書き上げたスプリント計画にも、曖昧な仮置きにもなってはいけません。エピックの説明から、PoC のプルリクエスト、ADR、関連ドキュメントにリンクしてください。
• ステークホルダーマップ。 引き継ぎ元の側では、アプローチの策定に関わった人（シェパード、Architecture Council のレビュアー、分野の専門家）と、それぞれが持つ背景知識を記載します。進捗に関心を持つステークホルダー（エンジニアリングリーダーシップ、依存関係のある PM、隣接チーム）も記載します。移行が行われることを関係者に知らせ、パルスチェックと振り返りを通じて状況を共有してください。

続いて、引き継ぎ後の作業量を、引き継ぎ先のチームと率直に見積もります。チームに代わって見積もるのではありません。プレイブックでは、PoC の経験を踏まえて引き継ぎ元が見積もりやすい 3 つの軸を挙げていますが、引き継ぎ先のチームは、自チームのシステムの実情に照らして検証する必要があります。

• 引き継ぎ先のチームの領域における実装と統合。
• 新しい作業に置き換えられる古いプロセスとコードの段階的な廃止。隠れたコストが潜んでいることがよくあります。
• サポート期間終了後の継続的なメンテナンスの責任。原則として、引き継ぎ先のチームが採用したものはすべて、引き継ぎ先のチームが所有します。共有フレームワークについては、引き継ぎ元のチームが一部のメンテナンスを継続する場合があります。責任の境界がどこにあるのか、明確に確認してください。

移行セッションの前に、準備段階でこれらのコストを明らかにしておけば、両チームが現実的な期待を持って引き継ぎに臨めます。また、引き継ぎ先のチームの EM がキャパシティを計画し、移行が想定より大規模だとスプリントの途中で気づく事態を防ぐことにも役立ちます。

フェーズ 2 — 移行セッション

セッションは引き継ぎ元のチームが実施します。最低 2 回行い、間隔は 1～2 週間空けます。

• セッション 1（背景とアプローチ）。 引き継ぎ先のチームが自分たちで確認できるよう、少なくとも数営業日前までに資料を共有します。セッションでは、解決する課題とこのアプローチを選んだ理由（何をするかと同じくらい、なぜそうするかが重要です）を説明し、PoC またはフレームワークを確認し、作業がより広範な取り組みや戦略にどう位置づけられるかを説明します。制約とトレードオフを明示し、自由に質問できる時間を設けてください。
• セッション 2（実践と計画）。 この時点までに、引き継ぎ先のチームはコードに目を通しています。より踏み込んだ質問が出ることを想定してください。自分たちで確認する中で見つかった不足点に対応し、作業の統合方法やスケジュールについて話し合います。補足が必要なドキュメントの不足箇所を特定し、サポート期間の構成に合意します。

セッション 2 の終了時に、追加のセッションが必要かどうかを両チームで判断します。複雑な作業や重要度の高い作業では、追加セッションが必要になることがよくあります。

フェーズ 3 — サポート期間

引き継ぎ元のチームは主導する立場からサポートする立場へ移行します。一般的な期間は、複雑さに応じて 4〜8 週間です。基本的な考え方は、いつでも対応できる状態にあるが、担当として割り当てられてはいないということです。

サポート期間中に引き継ぎ元のチームが行うこと：

• 質問に非同期で対応できるようにします。たとえば、アプローチ、意図、エッジケースに関する質問には、Slack や PR のコメントで答えます。
• 引き継ぎ先のチームが作成した初期の PR を 1〜2 件レビューし、意図したパターンに沿っているか確認します。**ゲートキーパーとしてではありません。**修正が容易なうちに、意図とのずれを見つけます。
• 本番環境で、当初のアプローチでは想定していなかった問題が明らかになった場合、選択肢の評価を支援します。引き継ぎ先のチームが意図を推測せざるを得ない状態にしてはいけません。
• サポート期間の延長や短縮が必要な場合は、率直に伝えます。より多くの時間が必要でも、それは失敗ではありません。

引き継ぎ元のチームが行わないこと：

• 引き継ぎ先のチームが作業を優先しなかったからといって、ひそかに作業を再開すること。このプレイブックでは、引き継ぎから実作業の開始までに遅れが生じるのは通常のことだと明記されています。大幅な遅れが生じた場合に適切なのは、引き継ぎ元のチーム、引き継ぎ先のチーム、エンジニアリングリーダーシップの間で優先順位をすり合わせる話し合いを行うことであり、元の所有権を再び作り出すような、ひそかな作業の再開ではありません。ファネルの「スコープ設定とコミットメント」フェーズでは、経営陣のコミットメントが確立されています。そのコミットメントが優先度の高い作業につながっていないのであれば、それはリーダーシップの議論であり、誰かが無理をして解決する機会ではありません。
• マージをゲートキープすること。詳細なコードレビューは、ほかのあらゆるコードと同じように、引き継ぎ先のチームが担当する領域です。
• スコープを追加すること。この移行は、スコープが定められた作業の引き継ぎであり、範囲を広げるための招待ではありません。

引き継ぎのタイミングに関する実務上の注意点：引き継ぎ先のチームがしばらく作業に着手しないと引き継ぎ元のチームが把握している場合、正式なセッションは相手の準備が整う時期まで延期する方がよいこともあります。コンテキストは時間とともに薄れるためです。ただし一般的な指針としては、作業を引き継ぐ準備ができた時点（コンテキストが最も新鮮な時点）でセッションを行い、引き継ぎ先のチームが実作業を始めた時点からサポート期間が始まると考えます。大きな空白期間が生じた場合は、引き継ぎ先のチームが作業を始めるタイミングで簡単な再オリエンテーションを行えば、引き継ぎ元のチームが継続的に関与しなくてもコンテキストを取り戻せます。

フェーズ 4 — 状況確認（移行から約 30 日後）

引き継ぎ元のチームも参加します。引き継ぎ先と同じ質問を確認します。作業は始まっているか、ドキュメントは十分か、サポート期間の長さは適切か、アプローチとの不一致を示唆するような方法でチームが作業を回避していないかを確認します。

状況確認の結果、作業がまったく着手されていないことが分かった場合、引き継ぎ先のチームと共同でエスカレーションするのはこのタイミングです。懲罰的な対応ではなく、能力上の問題、優先順位の競合、あるいは移行自体の不備があるかどうかを把握するために行います。対処しないままでいると、イニシアチブの作業はここで立ち消えになります。

フェーズ 5 — 振り返り（移行から約 90 日後）

引き継ぎ元のチームも参加します。両チームで 45〜60 分を確保します。目標は、定着状況を評価し、移行そのものについてのフィードバックを集め、今後の移行に役立つ教訓を記録することです。

引き継ぎ元のチームから得られる最も価値のある成果は、ドキュメント、セッション、サポートでカバーできなかった点を率直に認めることです。プロセスの改善点はプレイブック自体に反映します。Bitwarden での移行は、チームが学びを追加することで改善されます。

フェーズ 6 — 完了

引き継ぎ元のチームは移行の完了を確認し、関与を終えます。この意思表示は重要です。引き継ぎ先のチームは自律しており、明示的に再度関与を求められない限り、引き継ぎ元のチームの関与は終了しています。完了後も「念のため」のレビュアーとして関与し続けないでください。それは、手放すことを拒むのと同じ、控えめな形の表れです。

プレイブックの調整

6つのフェーズは、一般的なプロセスを示しています。作業内容に応じて規模を調整してください。これは双方に当てはまります。

• 小規模な移行（単一のパターン、限定された範囲）：期間を短縮します。状況確認は Slack のスレッドで行い、振り返りは定例のチームレトロに組み込めます。
• 大規模な移行（複数チーム、高い複雑性）：2回を超えるセッション、より長いサポート期間、より正式な振り返りが必要になると想定してください。
• 緊急の移行（退職、組織再編）：必要であれば準備を短縮しますが、サポート期間やフォローアップのチェックポイントは省略しないでください。価値の大半はそこにあります。

規模にかかわらず、省略してはならないことが1つあります。それは30日後の状況確認です。それ以外はすべて規模を調整できますが、これだけは、問題が表面化しないまま失敗するのを防ぐ仕組みです。

よくある間違い

引き継ぎを受ける側：

• 内容の乏しいドキュメントのまま移行を受け入れること。 実装時に、その代償を引き継ぎ先のチームが払うことになります。準備段階で異議を唱えてください。
• セッションを目標として扱うこと。 セッションは手段です。セッションを何回実施したかにかかわらず、90日後に引き継ぎ先のチームが独立して運用できていなければ、移行は失敗です。
• キャパシティに関する疑問を未解決のままにすること。 「時間ができたら取り組みます」では、移行は頓挫します。割り当てられたキャパシティがない場合は、移行の前にリーダーシップと話し合うべきであり、後ではありません。
• 引き継いだアプローチをひそかに回避して作業すること。 方針のずれは、実運用でインシデントが発生してからではなく、状況確認の段階で見つけるほうが低コストです。表面化させてください。
• 元のチームに作業を再開させること。 引き継ぎ先のチームが優先順位を付けられない場合は、リーダーシップにエスカレーションしてください。元の所有体制を再現するような支援は受け入れないでください。

引き継ぐ側：

• ドキュメントの準備が整う前にセッションを実施すること。 内容の乏しいドキュメントを補うために開くセッションは、フォローアップ項目の一覧を作るだけに終わります。まず資料を準備し、その後でセッションを予定してください。
• 引き継ぎ先のチームがエスカレーションすべきキャパシティ不足を補うこと。 引き継ぎ先のチームが作業を優先していない場合、適切な対応は、黙って作業を続けることではなく、取り組みへのコミットメントについてリーダーシップと話し合うことです。そうしないと、所有権の移転が損なわれます。
• 段階的廃止コストの評価を省略すること。 多くの場合、引き継ぎ先のチームのほうが、以前のものが実際にどう機能しているかを元のチームよりよく理解しています。廃止計画を明示的に立ててください。
• サポート期間を、所有権を引き続き持つ期間として扱うこと。 このフェーズで元のチームはアドバイザーです。レビューの目的は認識合わせであり、承認ではありません。マージの権限は元のチームにはありません。
• 完了後も関与し続けること。 「もうしばらく様子を見ましょう」は、手放すことを拒む婉曲的な表現です。引き継ぎ先のチームがいつ自律できるのかを、明確に把握できるようにしてください。
• 振り返りを省略すること。 プレイブックを改善する唯一の仕組みです。うまくいかなかったことがあれば、次の移行に役立てるため、ここで表面化させてください。

参考資料

• Work Transition Playbook — 正式な資料です。完全なフェーズごとの詳細、概要表、調整の指針は、get_confluence_page で取得してください。
• 関連資料：移行のきっかけとなることが多いイニシアチブの背景については Skill(navigating-the-initiative-funnel)、引き継ぎ対象を評価する際（どちらの方向でも）に適用するアーキテクチャ上の判断については Skill(architecting-solutions) を参照してください。