概要

メンバーに対して色々と期待はするわけですが、期待値を一方的だったり曖昧なままにして「何となく」でやっていくのを止めようって話を書き残そうと思います（弊社向けなので、適宜都合の良いように読み替えてください）。

前提

1. ドラッカー風エクササイズ等で「チーム->自身（チームが自身に期待していること）」「他メンバー->自身（他メンバーが自身に期待していること）」「自身->自身（自分自身に期待していること）」の期待値がクリアになっていること。

2. 上記に加えて、個々の期待値がチーム内で共有されていること。

3. チームの目的や目標と言ったOKRやインセプションデッキ、チーム憲章のようなものがチームに対して開示されていること。

期待値振り返りの目的

1. 自他の期待値に対する事実を認識する。

2. どの程度達成できているか主観的事実の認識と客観的認識のフィードバックを同時に行う。

3. チームの目標及び他メンバーの期待値に自分がどのようにコミットできるか明確にする。

3. メンバー間のフォロワーシップを明確にし可視化する。

期待値振り返りのメリット

1. OKR, CFRとの親和性が高く、既存の仕組みを考えると弊社には導入しやすい。

2. チームや個々の成長が中心になるので期待した「成長」を求めるマネジメントにはフィットしやすい。

期待値振り返りのデメリット

1. 期待値が明確になっていないとそもそも行えない。

2. ガッチガチのトップダウンなチームでは規律が乱れる（想定していない動きが発生する）可能性が高まる。

3. 同じチーム、同じプロジェクト等、業務上の距離が近いメンバーではないと振り返るだけで未来に繋がりにくい（ケースとしては少ないのでデメリットではないかも）。

4. プロダクト・プロジェクトが振り返りの中心にならないので、プロダクト・プロジェクトに対するフィードバックは少なくなる（プロジェクトの振り返りはレトロスペクティブ等の別場で必ず行うこと）。

期待値振り返りの方法

事前準備

自身の期待値を他のメンバーに説明できるレベルで明確にしておく。具体的にどのようなことを期待されているのか、それに対して自身は何ができて何ができないのか、少なくとも左記の内容は説明できるようにしておく。
期待値に関しては「自身単独でできること（オーナーシップ）」と「他メンバーと協力しなければならないこと（メンバーシップ）」に切り分けておく。オーナーシップは「○○本を読む」や「○○研修を受ける」等、自身だけでクリアできるもの、メンバーシップは「○○に関して知見を深める」や「実際にコードレビューを行う」等の自身だけではクリアできないものになる。

上記で整理した内容に対して「誰からの期待か」「今現在できること」「期待値をクリアするためにやったこと」「自分ではできないこと」を明確にし、「今現在できること」「期待値をクリアするためにやったこと」を整理しておく。その他制約があれば記載する（無ければ無しでOK）。

例：

期待値：  
　○○本を読んで得た気付きや知見をアウトプットする

誰からの期待か：  
　○○さん  

分類：  
　オーナーシップ  

今現在できること：  
　本を読みすすめる  
　適宜感じたことや思ったことを下書きに残す

期待値をクリアするためにやったこと：  
　2章/6章読んだ  
　2章までのナレッジの下書き  

自分ではできないこと：
　ナレッジレビュー（コメント欄でのフィードバックでもOK）  

その他制約：  
　特になし

期待値：  
　○○の実装に関して知見を深める

誰からの期待か：  
　チーム  

分類：  
　メンバーシップ  

今現在できること：  
　○○を用いた実装（実装はできるがよく理解しないまま使ってる感がある）

期待値をクリアするためにやったこと：  
　公式リファレンスを見ながら動かしてみた  
　簡単なCLIアプリを作成した  

自分ではできないこと：
　コードレビュー  

その他制約：  
　家に開発環境が無く、自己学習の時間が取れない
　実務で利用することが無く、実務ベースで知見を得られない

振り返り（タイミング）

タイミングは1回/2週ぐらいが良さそう。スクラム開発であれば1回/1Sprintが活動サイクルと一致するのでいいかもしれません。チームができたばかりの頃（タックマンモデルで言えば形成期）は相互理解も進んでおらず期待値がブレる可能性が高いのでサイクルは短い方が良いかも。期待値を出し合うことが形成期から混乱期に移行するトリガーになる可能性もあります。

振り返り（時間）

4人で1時間30分ぐらい

振り返り（方法）

1. チームの目的・目標の確認

最終的には成長を通してここにコミットするので確認する。
毎回毎回確認しなくても良くない？って思われそうですが、何度も何度も伝えて伝えてチームの目的や目標、このチームをどうしたいか・このチームにどうあって欲しいかをメンバーが「何度も何度も聞き飽きた！もう勘弁してくれ！！」となるまで伝えましょう。チームにおいて最も重要な内の1つはチームのメンバーが共通認識を持つことです。

2. 「チーム->自身」の振り返り（5分程度）

チームから自身に期待されていることを「自身がチームに対してどのようにコミットできたか」を主軸に振り返ります。左記の例で言えば「○○本をまだ途中だけど読んで、○○に関して意識して行動できた。具体的には○○をする時に事前に○○しておくようにしてみました。○○は今まで○○でしたが、意識して行動することで○○が○○になったと思います。」とかですかね。具体的に何をしてどんな意識や行動の変化があったか、それがどのようにチームにコミットしたか話せると良いですね。
もちろん仕事が忙しくてなかなか動けない時もあって気まずくなりそうですが、その時は自分が忙しくて期待値に対して時間を取れていないというアラートかもしれません。悪いことではありません。チームに対して素直に伝えてチームのみんなと一緒に解決していきましょう。

3. 「他メンバー->自身」の振り返り（5分程度）

先程と同じ感じで「自身が他メンバーから期待されたことに対してどのようにコミットできたか」を振り返ります。少人数であればあまり出てこない問題かもしれませんが人数がある程度増えてくると「あれ？自分ってこの人に期待によくコミットしてるけどあの人の期待にあまりコミットしてない気がする...」とか出てくると思います。関係性が良かったり相互理解が進んでいる人に対してはアプローチしやすく、そうでもない人にはアプローチしにくいのは当たり前ですが、これは心理的安全性を部分的に低く感じてしまっているサインかもしれませんね。
「他メンバー」と書きましたが、他メンバーは特定の誰かかもしれませんし、複数人のメンバーかもしれません。特定の誰かであればコミット先は決まっていますが、他メンバーが複数人の場合は自身が誰かアプローチしやすい人に限定してコミットをしていないかも振り返ってみると良いかも知れません。

4. 「自身->自身」の振り返り（5分程度）

自分自身への期待の振り返りですね。自分はこういうことをしたかったんだなぁとか、こういう成長をしたかったんだなぁとか、前はこう思ってたけど今はこう思うとか、期待値の思い出しや期待値の修正に使ってもらって構いません。
最初は自分がどこを向いてどこに歩いていこうとしているのか、それさえ振り返ることができたら良いと思っています。

内省にも繋がるのかもしれませんので、必ずしも期待値振り返りで行う必要はありません。場を1on1としてもいいですね。

5. フィードバック＆期待値修正（10分程度）

2〜4で行った振り返りについて他メンバーからフィードバックを受けたり、クリア済みの期待値を削除したり、修正・追加したりする時間です。フィードバックする時は感情や好き嫌いは一旦置いて、事実をもとにフィードバックしましょう。チームや自身にコミットしてくれたメンバーには感謝の意を示しましょう。

おわり

適当にスコーピングやテーラリングしたり、今やってる取り組みを加速させるにはどうしたら良いかなぁと考えている時のメモなので、考えが甘いところはあると思います。