Empowerment Engineering

内発的動機づけをソフトウェア開発の力で支援する

タスクレベルの個人の振り返りフレームワークで成長の確認と成果の拡大を狙う

月次、週次、日次と日常的に個人振り返りをするようになってだいぶ経ちました。
月次の振り返りは 冒険記 と言うかたちで行っています。
週次の振り返りは個人プロジェクト単位の KPT で行っています。
日次の振り返りはその日にあった何かしらに影響を与えそうな意思決定、人への支援、何か大きめの挑戦を記録しています。

より細かいレベルでも振り返りたくなるのが振り返り中毒としての当然の流れになります。
タスクレベルの振り返りです。

前提

私は長期的な効率化や、新たな価値の創造に関る事が多いため
直近の成果物をいかに早く仕上げるかを優先していません。

例えば、振り返りによって直近の作業が週に1時間ずつ遅れるよりも
その時間によって、ある閃きを得た後は今後一生毎日30分得をできる仕組みを発見し、
さらにそれを個人ではなく可能な限り広く適用する、というようなことを想定しています。
「可能な限り広く」の範囲にはこのブログを読んでいる方も入っています。

この振り返りフレームワークは「てぃーびー」の目的に特化したものであり、
各自の必要とされる役割に合わせてカスタマイズすると良いと思います。

つまり、この記事で伝えたいのは

振り返りのフレームワークを各位用意しておくことで、
振り返り方法について思い出すためのオーバーヘッドをなくし、
振り返りの内容自体が曖昧でぶれていない状態で振り返りを実施する習慣を作る

というメタな考えであり、ここでまとめている私の振り返りフレームワークはその具体例のひとつです。

タスクレベルの振り返りとは?

あるひとかたまりのタスクに対する振り返りです。
あまりに小さいものは振り返りを挟むとオーバーヘッドが大きすぎるので、一定以上のものを想定しています。

てぃーびー式タスク振り返りフレームワーク

f:id:tbpg:20171211170120p:plain

  • 準備
    • 予想
      • タスクの着手前にこのタスクで得られる新しい知識・スキルを書き出す
    • 追加
      • もし、この時点で新たな知識・スキルを得られる要素がなければ期日の許す範囲で新しい知識・スキルを得られる要素を盛り込む
  • 実施
    • タスクを実施する
  • 振り返り
    • 宿題
      • 残った課題をタスク化する
    • 記録
      • 習得した新しい知識・スキルを書き出す
    • 概念化
      • 新たに習得した知識・スキルが概念化できるなら概念化する
    • 転用
      • 新しい知識・スキルが他のタスクの役に立つか想像する
      • 新しい知識・スキルが他の人の役に立つか想像する
    • 着想
      • 新しい知識・スキルが他の概念を組み合わせて着想を得る

ポイント

  • 人材が成長することは組織にとって大きな利益であるため、自己の成長をタスクに織り込むことを意識しています
  • 楽しく働くには成長できる仕事と成長の実感が必要だと考えていて、それを自分でつくりだしています
  • 新たに得た知識・スキルで他の人に役立つ機会や、新たな着想を得ることがあるためサイクルの最後に転用・組み合わせのフェーズを用意しています

ものごとを曖昧にしていると自分が仕事で成長しているかどうかわからないケースもあると思います。
しかし、こうやって具体的にしておくと本当に成長していないかどうかが分かります。
例えば、日々割り振られるタスクに成長できる要素が用意されていなくて、自分でも成長の機会を組み込むことが
難しい環境だとしたら、その場では成長できないということになります。

まとめ

アジャイル開発・リーン開発が小さなフィードバックループを大切にするように、
個人の成長も小さなフィードバックループが大切だと感じています。
特に、原因と結果の関係や新たに覚えたものごとの存在は、時間が立つと忘れやすいものです。
やったそばから振り返る。やったそばから記録する。
それが大事なのでは、ということを思います。

関連情報