Open38

週次の振り返りの効用ってなんだろうか

kmishimakmishima

KPT

「自分自身の改善を促す」仕組みとして週報を機能させる。
デイリーノートに日々の気づきや時間帯ごとに何をしていたかは書き残せているので、
Problem→Try→Keepを仕組み化して、何が具体的に変化したかを書き残せるようにしたい。

https://zenn.dev/watty/articles/34b7720c2b5637

今までの僕の週報を見て思いました。。。
「これって、振り返りのフレームワークであるKPT法じゃない!?」

kmishimakmishima

長期視点

経験と絡めて長期視点の予測を推定できるようになることが大事
自分にとって効果が高く、やりたかった事、やれていて羨ましい人を参考にしながら、KPTの題材をリストアップする。

「今の決断/アクションが、将来数ヶ月〜数年後にどういう影響を生むのか」を想像する力です
未来をシミュレーションし、「めんどくさいけどやったほうがいいこと」を続けるためにも、「長めに過去遡って振り返りをする」のがおすすめです。

自分で体験して、検証して、「ほんとじゃん」と気付くことがとても重要

https://scrapbox.io/inteltank/月報テンプレート

kmishimakmishima

自分に都合のいい未来のイメージをそのまま現実だと信じてしまったり、期待通りにうまくいく計画を立てただけであんしんしてしまったりすることがよくあります。 「やったほうがよいこと」を思い浮かべただけで、やった気になってしまいます

週次計画や月次計画、5か年計画といった中長期的な計画を作ると、理想と現実の区別がつかなくなって破綻します。メンテナンスの負荷も上がり、計画を修正するだけでも大仕事になります。

https://scrapbox.io/kmishima/中長期計画だいたいうまくいってない

kmishimakmishima

その「週」になにをやったか

https://maguro.dev/weekly-report-2020-09-27/

週報にOSS活動を記録する

自分のために書いてあげる。
その結果、自分と似た境遇の人が、その内容を見て参考にしてくれるかもしてない。
(利他主義みたいな話?gitlab documentationに似たこと書いてた)

kmishimakmishima

メタ認知

まー、会社でネットサーフィンしすぎることは、仕事の生産性を下げて、ひいては人事の評価も下げる行為なのでなるべくは避けたいと思っている。でも、なんかうまく仕事に集中できる時期と出来ない時期があるんだよね。 今は仕事が出来ない方の時期に当たる。
タスクシュートとかも使って仕事の作業時間を定量化して測ってみようとしてるけど、僕は一日5時間も働ければ良く働いている方である。一日8時間勤務なので、残りの3時間はぶらぶらとサボってることになるようだ。

https://www.ituki-yu2.net/entry/Issues_with_my_use_of_Task_Chute

自分がどういうときにどういう傾向で行動するかを理解する。
メタ認知的な視点を取り入れる。

kmishimakmishima

タスクシュート

佐々木さん、記録って何の役に立つんですか?」のほうがタスクシュートの具体的な考え方を知るためには使えると思う。

読んでみたい。

kmishimakmishima

目標設定

意識しなくても勝手に身体が振り返りノートにアクセスするまで馴染ませたい

目標を達成するためのシステムを自分の中に構築しましょう
繰り返しは脳神経系の最適化に必要な作業です
適切な目標を立てて達成するシステム、つまり勝ちパターンを脳に刻み込みましょう
第22章 簡単な目標から達成しよう

kmishimakmishima

成果のないプロセス

「振り返り」をするのが目的ではなく、目標を達成することが大事。

成果の無いプロセスは、振り返りが停滞する
とりあえずアクションを作って実行しとけばいいってもんじゃない
アウトカムの無いアクションはマイナスを発生することもある

成果の無いプロセスは、振り返りが停滞する

kmishimakmishima

制限を意図的に設ける

  • 2024年刺激を受けた考え方
    • 私は四半期の目標の振り返りの度に、「やりたいことはたくさんあったはずなのに、やれなかったなあ」と感じることが多くありました。
    • ただ、振り返ってみるとやりたいことだけど、「やらなきゃ」と言う感覚で取り組んでいたことも多かったように思います。
    • 特に、この記事の中で紹介されていた、「19時以降はやりたいことしかやってはいけない」というルールは、 個人的にはとても良さそうだと感じました。
kmishimakmishima

予測精度を上げる

  • 行動目標をどのように扱っていますか?
    • 大切なのは、「今、確実にできること」を着実に実行し、その中で少しずつ成長を重ねることです。それが誠実な振る舞いであり、最終的には成果に結びつく道だと考えます。逆に、「次は頑張ります!」と曖昧な約束を繰り返すことは、(少し強い言葉ですが)不誠実だと感じるのです。
  • うまくいったことに執着しない
    • 成功した方法を土台にして、「もっとうまくできるやり方はないだろうか?」と探求したり、「こうしてみたらどうだろう?」と新しい試みをすることが大切です。
    • 仮に新しいアプローチがうまくいかなくても、元の成功した方法に戻ることができるので、大きくパフォーマンスを崩すことはありません。このような柔軟性が、チームの強みとなります。
kmishimakmishima

出来ないことが出来るようになるまで、のフィードバックループ

なぜ出来ないか?を考えるのが振り返りです
その目標設定はほんとに必要ですか?自分で解決したいことですか?実は他の人に任せてしまってもいいかもしれません
何か強烈にやりたいことがある人は、そこに至る過程を徹底的にかみ砕きましょう
第22章 簡単な目標から達成しよう

kmishimakmishima

ネタ作り

技術情報の種作りにつながる

また業務中に疑問に思った点や気付いた点などをログとして残すこともおすすめです。
業務後の振り返り時に見返すことで、技術記事のネタが見つかることが自分の場合は割とあります。
イメージとしては、「自分にだけわかるくらいのメモ」として記事を書いていくことをおすすめします。

https://zenn.dev/counterworks/articles/articles-output

kmishimakmishima

ジョハリの窓

ビジネスシーンでは、設定した目標に近づけているか、次にとるべきアクションは何か、仕事を最適化していくために振り返りは重要とされています。それは自分の振る舞いに関しても当てはまると思います。
スクラムのレトロスペクティヴでよく使われるKPTなどを参考にして、自分の良かったところ、良くなかったところを振り返り言語化します。ジョハリの窓で言う「盲点の窓」や「未知の窓」に位置していることに少しでも気付けるようにします。つまりは自己理解です。

  • 【開放の窓】自分も、相手もよく知っている領域
  • 【秘密の窓】自分は知っているが、相手には隠している領域
  • 【盲点の窓】相手は知っているが、自分は気付いていない領域
  • 【未知の窓】自分も、相手も知らない領域

https://keiei-shinri.or.jp/word/ジョハリの窓/ より引用

https://qiita.com/YOS0602/items/916ce3a05336d94e1644

kmishimakmishima

フィードバック

そして大事なのは、気付きを得てどうするかです。
自分の良いところは継続していきます。悪いところを見つけたら、どうして良くないのか、自分はそれを改善したいのか、改善したいならどうやってアクションするかを考えていきます。
大人になると、誰も当たり前のことを注意してくれなくなります。

https://zenn.dev/hizacra/scraps/05ca933589e692

kmishimakmishima

一人スクラム

Backlog使って一人スクラム回すのよいかも。

火曜から日曜までの朝はデイリースクラムを行う。 昨日までの進捗を振り返り、必要に応じて今日以降の作業を再計画する。
日曜の夜はスプリントレビューとスプリントレトロスペクティブを行う。 スプリントで実際に作業をやり通してみると、想定していた成果が得られない場合がある。 スプリントレビューではそのギャップを埋めるためのアイテムを新たに作成したり、逆に不要なアイテムを削除したりする

kmishimakmishima

スプリントレトロスペクティブ

まず、レトロスペクティブについてスクラムガイドでは以下のように書かれています。

  • スプリントレトロスペクティブは、スクラムチームの検査と次のスプリントの改善計画を作成する機会である。
  • スプリントレトロスペクティブには、以下の目的がある。
    • 人・関係・プロセス・ツールの観点から今回のスプリントを検査する。
    • うまくいった項目や今後の改善が必要な項目を特定・整理する。
    • スクラムチームの作業の改善実施計画を作成する。

スクラムガイドに書かれているように、レトロスペクティブとはスプリントを検査して改善計画を立てるためのスクラムイベントです。また、単にプロダクトを考えるのではなく、人・関係・プロセス・ツールの観点で検査するという点がポイントです。

位置付け
多くのスクラム有識者はレトロスペクティブが最も大事なスクラムイベントだと言い、最低限レトロスペクティブさえできていればスクラムは成り立つと言う方もいます。
さて、それはなぜでしょうか?
私はアジャイル・スクラムを実践する上で、「改善サイクルを回す」ことが必要不可欠だからだと考えております。
レトロスペクティブはチームに改善サイクルを根付かせるためのイベントであって、改善サイクルを効果的に回し続けられるかどうかがスクラムチームの成熟度を決める大きな要因になる。
そのため、レトロスペクティブの効果を最大化することで、チームの成熟度を高めることができるのだと考えております。

大枠の流れ
大枠の流れはこちらになります!

  1. タイムラインに前スプリントのTry出来事を洗い出す
  2. 前スプリントのTryから効果、出来事からProblemを考える
  3. 効果からKeepを決める
  4. ProblemからTryを決める
  5. 決めたTryを翌スプリントのタイムラインに置く
    実際のアイテムはこのようなタイムラインで管理してます!

https://zenn.dev/levtech/articles/b6346b9b9f9629

kmishimakmishima
  • トップダウン思考のデメリット
    • 人参をぶら下げられた馬のように、夢や目標の達成に向けて、無理をしてしまう。
    • 完璧を追い求めようとすると、時間ばかり過ぎてしまう。
    • 試行錯誤の上作ったプランだとしても脆弱で予想外の出来事に弱く、そのメンテナンスに大きな負荷がかかってしまう。
kmishimakmishima

この「事前準備」が抜けてしまうと、『自己管理』ではなく、『自己機械』 化してしまい、「それで自分って何がしたかったんだっけ・・・?」となってしまう可能性が高いです。だからこそ、必要なのです。
https://qiita.com/YUM_3/items/e0d734690d6aa37c5125

kmishimakmishima

理想と現実

自分の能力に対して過度なノルマを設定しなくなった
自分は何かを頑張ったら実際以上によくやったと考えがちなタイプだ。 完了したアイテムの見積もりの累積として作業量を定量化してみると、自分が目標とした作業量と現実とのギャップが愕然とするほど大きいことが示される
一人スクラムを始めたての頃は過大な量のアイテムをスプリントに詰め込みがちだったが、次第に現実と向き合い、着実な計画を立てるようになった。 そのような計画を立てて実行にコミットできた方が、振り返った際に有益なインサイトも得られやすい。

kmishimakmishima

リーン

大事な視点。
無駄があるからこそ、日常がかがやく場合もあるので、無駄を省くことに固執してはいけない

本当に価値があると思える作業に集中しやすくなった
自分の現実的な行動量が分かると、ある将来の時点までに自分が完了可能なタスクの量は想定より少ないことが分かる。 するとゴールとは直接関係のない作業に費やす時間がより勿体ないと感じるようになる。
分かりやすい例としては読書が挙げられる。 以前は有用そうだと感じた本をついつい買って積ん読していた。一人スクラムを始めてから、作業を定量化することで読書に当てられる時間は非常に限られていることが分かった 。 その本を読むことがゴール達成にどのように寄与するのか具体的に言語化できない場合、その本は買わないようになった。

kmishimakmishima

一つだけ補足しておくと、「一人スクラム」は銀の弾丸ではない。

  • そもそもゴールがなければ一人スクラムを実践する価値がない
  • スクラムイベントを実行しなければ一人スクラムは成立しない
  • スプリントゴールの達成に全力を尽くすことにコミットできなければ一人スクラムは機能しない。
    ゆめみの片岡さんが Atomic Scrum というフレームワークを提唱している。 スライド中の言葉を借りると、「漸次的共進化」を目指していけるのが一人スクラムの最大のメリットかもしれない。
kmishimakmishima

GTD

  • タスク管理システム:労力対提供価値の観点から優先順位付けされたタスクリスト
    • タスクは「提供価値」(特大・大・中・小として 4,3,2,1 点)で評価される
    • 「生産性」「提供価値」「時間効率」などの指標でパフォーマンスを可視化
  • 目標管理システム:週次目標(MITopic)と月次目標(MITarget)の設定と追跡
    • 目的やゴールが明確に記述され、達成に向けた具体的なアクションと紐付けられる
  • 「Inbox」:GTD(Getting Things Done)の概念を取り入れ、頭の中の気になることを外部化する
kmishimakmishima

漸次的共進化

  • 成長したその先はなにか? についての自己定義を行う
    • PO/Dev/SM の 帽子をかぶり分ける
  • OODA(経験主義)から PDCA(トップダウン)に切り替える
  • 振り返りの内容から、目標や計画の達成状況を確認する
    • 月次レビューの内容にもつながっていく
kmishimakmishima

ポイント見積もり

  • 割込みが来ない時間帯を意識する
  • 30 分を1ポイントとして作業を見積もる
kmishimakmishima

改善のサイクルを設ける

ふりかえりはふりかえりなのでふりかえる
Actionはとりあえずやってみる。代わりに効果検証を忘れずに。

これまでのレトロは単なるKPT方式でやっており、

  • 突発的にTryが生まれる
  • Tryが履行されない、忘れられる
  • KeepがDoneのような位置付けになって時間が経つと忘れられる

ということが時々発生していました。

ですが、上記で紹介したプロセスへ変更したことでそのような事態を防ぎ、継続的に改善できるようになってきた実感があります(あくまで定性的な評価です)

kmishimakmishima

記憶

  • 1 年以上前の日記や振り返りログを見返して、「XX を学んだ!」と書いてあることの多くを今でも覚えているか? - kidooom's Scrapbox
    • 過去の日記や振り返りログを読み返すと、「XX の本を読んで学んだ!」とテンション高く書いてあるのに今となっては忘れてしまっていることの多さに気づいた

https://scrapbox.io/kidaaam-92022284/1年以上前の日記や振り返りログを見返して、「XXを学んだ!」と書いてあることの多くを今でも覚えているか?

kmishimakmishima

Digital Commonplace Book

  • 伝統的な「コモンプレース・ブック」のデジタル実装で、興味ある引用や観察を収集整理する
    • 古典的な知識管理手法の現代版であり、シンプルさと柔軟性が特徴
    • 単なる収集に留まらず、定期的な振り返りと再構成が重要である
    • 読書ノート、引用集の発展形として捉えることができる
kmishimakmishima

SECOND BRAIN

  • 週次・月次振り返りについての記述があった
    • できるだけ短い時間で終わらせる
    • 一週間、1か月を点数化するためには習慣トラッカーが必要
kmishimakmishima

デービッドゴルブの経験学習モデル

まずアウトプットして、出てくる疑問点を具体化する

  • 体系的な疑問ではなくて、ボトムアップ的な具体型の疑問だな
  • デービッドゴルブの経験学習モデル
    • 経験・振り返り・概念化・試行