株式会社ビットキーで組織開発・技術広報・採用を横断担当するパウリ氏による登壇資料。「3人の時は全部自分で決められたのに、50人になったら回らなくなった」という経験を起点に、意思決定の引き継ぎ（引継ぎ）の設計について、失敗パターン・構造的原因・具体的なフレームワークまでを体系的に解説しています。
立ち上げ期を支えた「できる人」に知識と業務が集中し、採用しても引継ぐ時間がないため、さらに業務が集中する悪循環。パウリ氏はこれは「人」の問題ではなく「構造」の問題だと強調します。
「入社前の自分だったら何を知りたかったか？」の視点で、完璧なドキュメントではなく思考の断片を「種」として残す。
本人のShouldと組織のMustのズレに課題が潜む。「本当にその人に渡すべきか？」の判断材料になる。
業務を「リスク（判断ミス時の事業インパクト）」×「エフォート（時間的・技術的・心理的負荷）」の2軸で分類し、3ゾーン別にグラデーションで渡す。一気に全部渡すのが一番危険。
| 人→人 | 人→システム→人 | |
|---|---|---|
| 暗黙知 | 伝わらない | 判断基準がコードやプロンプトに残る |
| レビュー | 属人的 | 一定品質のアウトプットを自動生成 |
| 摩擦 | 感情的な摩擦が生じうる | システムの出力を起点に対話できる |
実例として技術広報の起案〜整形をシステム化（tech-pr-generator）した事例を紹介。引継ぎのシステム化はAI時代の新しい選択肢。
「バランスだね」「視座が低い」「難しいね」といった雰囲気言葉は、後任者に「言語化の下請け」を強要しているのと同じ。対処法は正直に伝える（「まだ言語化できていません」）→ 時間を確保する → 学んで共有する。
| NG（雰囲気言葉） | 変換プロセス | OK（具体的な伝え方） |
|---|---|---|
| 「バランスだね」 | 対立軸と変数で切る | 「今週はスピード優先、来週からは安定性優先に切替」 |
| 「視座が低い」 | 具体的な考慮漏れを指摘 | 「経営会議を想定すると、コスト面の根拠が弱い」 |
| 「難しいね」 | 変数を分解する | 「機能的には可能だが、法務リスクで自分たちでは決められない」 |
When（どの時点で）と Why（何が優先されるから）を伝えれば、後任者は迷いなく自走できる。
引継ぎとは「互いを探索し続ける」プロセス。引継ぎは前任者自身が専門性を言語化して鍛錬する機会でもあり、あなたの引継ぎが後任者の挑戦になり、その挑戦がまた次の引継ぎになる。この営みが定常化すれば、個々人が挑戦し続ける強い組織が生まれる——「決め方を渡せる人」が、次の挑戦を手にする。「決め方を渡す仕組み」が、組織を成長させる。