コーチングプラクティス： プロジェクトチームの振り返りの進め方
取り組んでいることをほぼ何でも入力すると、IX Coach が現実に最も合うプラクティスを見つけます。「プロジェクトチームの振り返りの進め方」については、現在のプラクティスライブラリからの最適な一致をご覧ください。
役立つかもしれないプラクティス
- 解散期:意図を持ってチームを終える
チームがどう終わるかは、各メンバーが次のチームをどう始めるかを形作る。
タックマンのチーム発達段階モデル - 定期的なチームの排除レビューを行う
もはやどんな現在の目標にも役立っていないことをチームがやっていないか定期的に見直す。
チームのためのアイゼンハワー・マトリクス - 始める前にプレモーテム（事前検死）を行う
プロジェクトが始まる前に問いかける——失敗したと仮定して、何がまずかったのか？
後知恵バイアス：なぜすべてが振り返ると当たり前に見えるのか - 非難のない短いアフターアクション・レビューを行う
重要なアウトカム — 成功でも失敗でも — の後、チームとして一緒に四つの質問をする。
チームにおける心理的安全性 - プレモーテムとレッドチームのプレッシャーを組み合わせる
プレモーテムを実行し、それからレッドチームにグループが見逃した失敗モードを見つけるよう依頼する。
レッドチーミング：失敗する前に計画をストレステストする - リスクレジスターだけでなく計画そのものを変更することを要求する
計画を変えないレッドチーム演習は何も達成していない。
レッドチーミング：失敗する前に計画をストレステストする - 金曜のリフレクションを実行する
毎週金曜日、何を成し遂げたか、何を学んだか、何を違うふうにするかを振り返る。
『アジャイル・リザルツ(AGS)』を実践する - コミットする前にプレモーテムを行う
プロジェクトがすでに失敗したと想像し、なぜかを逆算する。
計画の誤謬——なぜあなたの見積もりはいつも外れるのか - 単一の週次優先順位設定ミーティングを行う
アドホックな優先順位の要求を、チーム全体が一緒に再仕分けする一回の週次ミーティングに置き換える。
チームのためのアイゼンハワー・マトリクス - プロジェクト開始前に、フィードフォワードを使ってチームの目標をすり合わせる
プロジェクトの開始時に、批評すべきパフォーマンスがまだない段階で、どうすれば成功できるかについてのフィードフォワードを募る。
フィードフォワード:実際に行動を変える未来志向のフィードバック
関連する悩み
- チームの振り返り
それは彼らのミーティングだ——彼らが大切なことを持ってきて、あなたはそれに合わせる。
部下にアジェンダを持たせる
- レッドチーム視点での計画立案
レッドチーミングとは、誰か——あるいは構造化された思考プロセス——に、あなたの計画を積極的に壊そうとさせ、その前提を特定させ、敵対的な反応を見つけさせ、楽観主義とグループシンクが抑え込んでいる失敗モードを浮かび上がらせる実践です。それは軍事・情報機関の文脈に起源を持ち、現在では企業戦略、セキュリティ、製品開発において使われています。その有効性のエビデンスは主に組織的・実践者的なものであり、統制された試験からのものではありません。
レッドチーミング：失敗する前に計画をストレステストする
- 後知恵バイアスを防ぐプリモータム分析
プロジェクトが始まる前に問いかける——失敗したと仮定して、何がまずかったのか？
始める前にプレモーテム（事前検死）を行う
- チームの心理的安全性を高めたいとき、仕事を学びとして枠づける方法
困難なプロジェクトを始める前に、それを明示的に、間違いが情報を生む実験として名指しする。
不確実な仕事を学習としてフレーミングする
- 明日やる（チームと）
マーク・フォースターのドゥー・イット・トゥモロー(DIT)システムは、1日の始めに今日のタスクリストを締め切り、新しい依頼は明日に回すことで作業量をコントロールする――際限なく反応し続けるのではなく、約束したことを終わらせるためだ。これは試験されたプロトコルというよりは実践者システムだが、その中核的な仕組み――クローズドリスト、まとめた同日処理、ルーティン業務の分離――は、裏付けの強い認知負荷と注意に関する研究と整合している。
ドゥー・イット・トゥモローを実践的に理解する
- 頼まれる前にプロジェクトの進捗を報告する
キックオフで作成され、二度と更新されないRACIは、最初の変化が起きた瞬間に時代遅れになっている。
スコープやチームが変わったときにRACIを見直す
自分の言葉で状況を説明する でプラクティスライブラリ全体を検索できます。