generated at
振り返りが人生を豊かにする
formatの一つ。振り返りをするときに参考にしてください

振り返りは目的によって型が変わるので、目的によって型を変える
初めての業務、自分発信の企画ではPJT振り返りフォーマットを使う
KPTは数ヶ月に渡って継続的に改善を回すときに使う。
出来たてのチームがチームビルディングをし、チームマスタリーを得るためにも有用

切り取り線
振り返りにちなんで、雑多に書き起こすtsawada.icon


振り返りをして、目標設定の甘さに気づく。
私達が得意になるべきは「問題解決スキルのアップ」ではなく「(スキルアップもしながら)解くべき問題の設定スキル」
目標設定スキルこそが大事。

振り返りをするとは、「失敗を(学び化することで)資産にする」工程。
振り返りがしっかり出来るから、失敗確率が高いものにもチャレンジできるのだ
振り返り力が高い人は失敗を価値に変えられる人。
まあ…そうなるともう失敗ですらない。検証って感じだけど

振り返りにおいては「思い出す」のが最も重要なので、この部分工夫する
「振り返りのために特別書き起こす」のは続かないからやめた方が良い
タスク一覧用意して、1日の終わりに「どれ終わったかな?」と見直す方が楽

「事実の書き起こし」は何が何でもその場でやる
「後で書く」はマジやめた方が良い
書かれない。めんどくさくなって
時間経つから記憶が劣化し情報量が減っている。
その場でやりきるためには
タイピング力を底上げする
相手に待ってもらう
口頭ではなく、書いてもらう。

足りない知識・方法は助けてもらう。
「何もない状態から考えをひねり出す」も大事だが、「滝のようにFBもらう」も大事。
ちょっとは知らないと何も動かないよね
FBはそのまま受け止めない。参考としておき、「自分で試す」。
試してみて、そのときに感じたこと・そのときの結果こそが確からしい情報

改善のための振り返りはできるだけ細かくやるのが大事
振り返りの肝は「何をやったか」の記録が細かく存在するか?
振り返りのフレームワークとか正直「より細かく自分の行動を思い返す」以外に不要な気がする
「こんなに細かく記録残すの!?」というのは生産管理あたりの文献を探ると気づける
適当に持ってきたリンクだけど以下とか。参考になる
マジで改善をするならば、「自分の行動の動画を撮って、数倍〜数十倍の時間かけて分析する」くらいした方が良い
時間かけて

書く。書く。書く。脳に、記憶に頼らない。
記憶は改竄されるもの
改竄されたり、忘れてしまったものが何か?は自分ではマジ気付かない
改竄された。ということを認識できない。
何を忘れたか?も忘れる
書き起こす。「昨日の自分にまざまざと伝わる」ように丁寧に書き起こす
間違っても「今の自分に伝わる」ではない
キーワードが一部書き起こされるだけで終わる
「1年後の自分」もいけてない
1年後の自分がどれだけ忘れているか?どうなっているか?は全然想像ができない
経験していないし、「記憶は1年経つとどれだけ劣化するか」は覚えてない。もちろん認識できない。
書かないとね。
「昨日の自分」が良い
まだ記憶が新しいので「昨日の自分だったら、この文章読んでわかるかな…?」が想像しやすい
「今日新しく経験したこと(≒今日振り返る中でも重要度が高い事象)」に関して、知らないことだらけなので、しっかり言語化して伝えることになる

振り返りを一緒にするメンターが心がけること
「自分から口頭で伝えてる内容」が長ければ長いほど、上滑りする。伝わらない
メンティにとってそれだけ新情報が多い
口頭で言われても覚えきれない
大事なこと。心がけて欲しいことは「書き残す」ようにする
振り返り後に読み返す・思い出せるよう書き残す。
エビングハウスの忘却曲線にもあるように何度も繰り返しみてもらうからこそ覚えられる・習慣になる
メンティに任せきりにしない。書き残すのが不十分になるので

振り返りがうまくいかない。学びに昇華して改善できないのは
解像度が低いケース。これが多い。状況のブレイクダウンが出来ておらず、「何が問題だったか?」の変数が多い状態
変数が多いと「次回気をつけるべきこと」の山が大きくなる。全部意識しようとして疲弊するだけでクリティカルな解決にならない
同時に取り組む改善アクションは多くて2,3個にしないと動きづらくなる。絶対増やさない
システム思考を用いて、変数(≒原因っぽい要素)同士の関係性を整理し、「この変数は無視して良い(放置で良い)」を定めるのが大事
変数、また改善施策を全然知らない。
ブレイクダウンするには一定「こういう変数が含まれることが多い」といった型を知らないと手を付けられない
ロジカルシンキングの研修では、日々振り返り出来るレベルの型までインストールしてもらえない。
PJT、タスク…ひいては実施日が1ヶ月ずれるだけで千差万別変わるため
似たものの経験が溜まってくると、うまく抽象化できるが、そうもいかない
仕事始めたてのときは自分の持っている業務にあわせてかなり具体度高く型をもらったほうが良い。
守破離ですね
納期、求められる品質が高く、「こなす」ことが多くなり、成長しない
振り返りよりもタスク遂行!となった結果、振り返り…プロセス改善がされなくなる
「今持っているスキルで達成」が優先され、スキル・知識の習得が劣後される
「他でも使えるスキルかもしれないので、今しっかり調べて学んでおく」がされない
Excel関数学んだ方が1/10くらいの時間で終わるのに、学ぶための時間が惜しくて今日もひたすらコピペ。

振り返りしているんだけど、疲弊するケースとしては
業務振り返りばかりしており、自分の心が置き去りになる
「周囲から求められているもの。期待」ばかりに目が行き、他のものが頭から抜け落ちてしまう
仕事慣れていないため起こるものも多々
「とにかく期待に答える」が優先され強弱付けずに全部のことを全力でやってしまう
「価値になるように動く」ために気をつけるべきことが、まだ習慣になっていない
ので、心の中でずっと意識する必要があり脳疲労。疲れてしまう

チームで振り返りをする上で必要なこと
DPAを作り、チームメンバーの習慣を変えていく
振り返りは劣後しやすい。個々人に委ねるとすぐ風化する

振り返りで使えるテクニックとしては
コーチング
なぜなぜ分析
システム思考
ギャップ分析(問題解決アプローチ)
経験学習モデル
U理論
LAMDA
Look (実際に現場をみる)
Ask (やる)
Model (結果を抽象化)
Discuss (フィードバックしてもらう)
Act (やる)
朝会・夕会


切り取り線
関連しそうなものを一気にもってきた