「決め方」の渡し方 / How to hand over the "decision-making process"

【Startup in Agile #7 】ボトルネックは人の意思決定？「決め方」の変遷教えて
https://startup-in-agile.connpass.com/event/386112/

Transcript

1. 「決め方」の渡し方 株式会社ビットキー パウリ
2. 「決め方を渡せる人」が、次の挑戦を手にする。 「決め方を渡す仕組み」が、組織を成長させる。 2
3. パウリ @pauli_agile EM支援、DevHR、技術広報 WEB・iOSエンジニア → マネージャー → 　　SM/EM育成。 現在はビットキーで組織開発・技術広報・ 採用を横断担当。
4. 元記事はこちら 前編 中編 後編
5. 3人の時は全部自分で決められた。 50人になったら 回らなくなった。 そんな経験、ありませんか？
6. パターン A「全部渡す」 「あとはよしなにやってくれ」 判断基準なしに意思決定を迫られる 失敗 → 前任者が再登板 「自分じゃなきゃダメだ」が強化 パターン B「何も渡さない」 「まだ早い」「自分の方が速い」 前任者が永遠にボトルネック 新メンバーは成長機会を失い続ける 組織がスケールできない
7. なぜこうなるのか？ ̶ BBoMの構造 特定の「できる人」に業務が集中する 3段階の負のスパイラル 1. 知識の偏在  立ち上げ期を⽀えた人に知識が集中 → 属人化     ↓ 2. 業務の集中  「この人に聞けば分かる」→ バス係数1     ↓ 3. 時間の枯渇  採用しても引継ぐ時間がない → 負のスパイラル完成 これは「人」の問題ではなく 「構造」 の問題
8. Aさん → Bさんへ、Xチームのマネジメントを委譲 引継ぎなし で丸投げ → Bさん混乱 → チーム崩壊 → Aさんが再登板 Aさん（引継ぎしなかった側） Bさん（挑戦した側） 「やっぱり Aさんじゃなきゃ！」 と評価UP 「まだ能力不足」 と評価DOWN 問題はBさんの能力ではなく、「渡し方」の設計が欠けていた こと 実際に起きたケース
9. 「引継ぎしない方が得をする」構造にも注意 ケース 構造 引継ぎすると地位が危うくなる 限られた役職 × 評価制度 → 知識を渡す＝ 立場が不安定に。「現状維持」が最も安全 引継ぎしない方が評価される 引継ぎ不足で後任が失敗 → 前任が再登板して評価UP。歪んだインセンティブ これは「その人が悪い」のではない 組織の構造として、そういった振る舞いが合理的になってしまっている 情報の非対称性 が温存される環境では自然に起きる現象 個人を糾弾するのではなく、構造を変える 視点が必要
10. 渡せなければ、組織はスケールしない 0→1を作ったあなたの力は、 1→10では「渡す力」に変わる スタートアップの成長過程で必ず起きる変化 3人→50人：全員が同じ部屋にいない → 暗黙知が通じなくなる 50人→100人：自分が全部見られない → 判断基準を渡す必要が生まれる 100人→：自分がいなくても回る仕組みが必要 → 渡せなければ事業が止まる 採用しても、渡せなければ人は活きない。 常に引き継げる状態を維持する = 組織が次のフェーズに進める
11. では、どう渡せばいいのか？
12. 3つのシグナルでメモを残す 「⼊社前の自分だったら何を知りたかったか？」の視点で記録する。 シグナル 例 記録すること 規則やフローがあった時 　デプロイ手順、承認フロー 業務の流れ 他者に聞いた時 「Nさんしか知らない仕様」 自分で判断した時 技術選定、優先順位変更 期待と裁量の範囲 完璧なドキュメントではなく、思考の断片を「種」として残す 誰が何を知っているか
13. まず相手の内面を可視化する Will / Can / Should Will 本人のキャリア観・興味関心 Can 自身のスキルの棚卸し Should 組織から期待されていること 本人のShouldと組織のMustのズレに 課題が潜む 本当にその人に渡すべき？
14. 次に業務を分類する Risk-Effort マトリクス 業務を 「リスク」 と 「エフォート」 の2軸で分類する。 Risk（縦軸） 判断ミス時の事業へのインパクト Effort（横軸） 時間的・技術的・心理的負荷 どれくらい渡すべき？
15. 3ゾーン別 関わり方のグラデーション 一気に全部渡すのではなく、ゾーンに応じてグラデーションで渡す
16. 引継ぎの媒介に「システム」を置く 人対人の引継ぎは、どうしても伝わらない・⾓が立つことがある。 人→人 人→システム→人 暗黙知が伝わらない 判断基準がコードやプロンプトに残る 属人的なレビュー 一定品質のアウトプットを自動生成 感情的な摩擦が生じうる 引継ぎの「システム化」は、AI時代の新しい選択肢 システムの出力を起点に対話できる
17. 実例 tech-pr-generator 技術広報の起案〜整形を属人的に回していた → システム化で品質の均一化と工数削減 を実現（予定）
18. 引継ぎとは 互いを「探索し続ける」プロセス
19. 後任者への探索 ワークショップや対話を通じて、相手の Will / Can / Should を理解する 把握している側面だけでなく、まだ見えていない可能性 も探る 一度「理解した」と決めつけず、絶えず「今」のその人を把握し続ける 相手を知ることが、その人にしかできない活躍 につながる
20. 自分自身への探索 なぜ自分はそう判断するのか？ その思考プロセスは言語化されているか？ 「伝える力」が足りないなら、本・論文・他者から学びを得る 引継ぎは、前任者自身が専門性の言語化を鍛錬する機会 でもある あなたの引継ぎが後任者の挑戦になり、その挑戦がまた次の引継ぎになる。 この営みが定常化すれば、個々人が挑戦し続ける強い組織 が生まれる。
21. 明日から始められること
22. 明日から始める 3つのアクション 1. 今日した判断を 1つ、言語化してみる なぜその判断をしたか？ 雰囲気言葉を使わずに説明できるか試す。 2. 渡したい相手の Will / Can / Should を聞いてみる 相手の内面を知ることが、引継ぎの第一歩。 3. 任せたい業務を Risk-Effort で分類してみる いきなり全部渡さない。人によってゾーンが違う ことを忘れずに。
23. 「決め方を渡せる人」が、次の挑戦を手にする。 「決め方を渡す仕組み」が、組織を成長させる。
24. 後付け
25. ゾーンがわかったら どう「伝える」か
26. 雰囲気言葉が生まれる理由 なぜ使うのか 何が起きるか 「わからない」と言うのが怖い 後任者に「言語化の下請け」を押し付ける 抽象的に語る方が高尚に見える錯覚 頼られる存在でありたい心理 判断基準が共有されず属人化が維持される 自分都合で抽象的な表現を使うことは、 他者に「言語化の下請け」を強要している のと同じ 対処法：正直に伝える （「まだ言語化できていません」）→ 時間を確保する （「明日までに整理します」）→ 学んで共有する 「バランスの正体」を延々と手探りさせる
27. 雰囲気言葉の言い換え NG 雰囲気言葉 変換プロセス OK 具体的な伝え方 「バランスだね」 「今週はスピード優先、 来週からは安定性優先に切替」 「視座が低い」 具体的な考慮漏れを指摘 「経営会議を想定すると、 コスト面の根拠が弱い」 「難しいね」 変数を分解する 「機能的には可能だが、 法務リスクで自分たちでは決められない」 When（どの時点で）と Why（何が優先されるから）を伝えれば、 後任者は迷いなく自走できる 対立軸と変数で切る