はじめに

新卒1年目が終わり、現場で半年間のスクラム開発を経験しました。

研修中、毎日書く「日報」や「週報」に、「今日は何を書こう…」「昨日と同じような内容だな…」と頭を抱えたことはないでしょうか。

私自身、「これって業務報告じゃなくて、ただの感想文になってないか？」と、自分の書いている内容にモヤモヤしていました。

そんな私の日報の書き方を根本から変えてくれたのが、現場で毎日行っていた 『レトロスペクティブ（振り返り）』 の習慣でした。

今回は、スクラム開発中に行った「振り返りフレームワーク」を使って、日報を「未来の自分を助ける武器」　に変える方法を紹介します。

スクラムの3本柱

スクラムには、プロセスを支える 「3本柱」 という概念があります。

  • 【透明性】 プロセスや作業が見える状態であること
  • 【検査】 と 【適応】 「透明性」という土台の上で、現状をチェック（検査）し、ゴールに向けてやり方を調整（適応）し続けること。

日報でもこれらを意識するだけで、書くべきことが明確になります。

なぜ「フレームワーク」を使って書くのか

「日報に何を書くか」を考えるとき、単純に文章を書き連ねるよりも、あえてフレームワーク（型）に当てはめて書くことをおすすめします。

その方が読み手（先輩）にとっても状況がクリアに伝わり、圧倒的に読みやすくなるからです。

  • 読み手のメリット： どこに何が書いてあるか一目でわかるため、即座にフィードバックができる。
  • 書き手のメリット： 「この項目に沿って埋めればいい」というガイドラインになるため、書くことに迷わなくなる。

実際の振り返り

私のチームでは、この振り返りを「毎日」行っています。


※機密保持のため一部加工しています。

実際の現場では、このようにホワイトボードを囲んで、付箋を貼りながら「次はどう良くするか」を議論しています。

おすすめの振り返り手法4選

「何を書こうか」と迷わないために、フレームワーク（型）を使いましょう。目的に合わせて使い分けるのがコツです。

業務やスキルの改善に向いている手法

  1. YWT (やったこと、分かったこと、次にすること)
    • やったこと： 何をしたか
    • わかったこと： 経験から得た気づき。
    • 次にすること： 学びを次へ繋げるアクション。
    • ポイント： 「わかった」を深掘りすることで、自分の理解の解像度を上げることができます。
  2. KPT (Keep / Problem / Try)
    • Keep： 良かったので継続すること。
    • Problem： 困ったこと、課題。
    • Try： 明日試す解決策。
    • ポイント： Problem（現状の検査）を書き出すだけでなく、必ず明日のアクションであるTry（適応）とセットで考えるのが鉄則です。

自分のコンディションや状況把握に向いている手法

  1. FDL（Fun / Done / Learn）
    • Fun： 楽しかったこと。
    • Done： 終わったこと。
    • Learn： 学んだこと。
    • ポイント： 「楽しかった（Fun）」を意識的に探すことで、自分がエンジニアとしてどこに喜びを感じるのかが可視化されます。
  2. MAD / SAD / GLAD（喜・怒・哀）
    • MAD： イライラしたこと。
    • SAD： 悲しかった、不安だったこと。
    • GLAD： 嬉しかったこと。
    • ポイント： 「エラーが解消できなくて不安（SAD）」といった感情を日報に透明に出すことで、先輩社員からの早期のサポートを引き出し、適応を早めることができます。

全てのタスクに「自分なりの見積もり時間」を出す

見積もり時間という定量的な視点を入れると、振り返りは一気に書きやすくなります。

タスクの見積もり時間と実績にズレがあった場合、そこには必ずズレの理由が存在します。

見積もりと実績に「ズレ」が生じると、申し訳ない気持ちになるかもしれません。しかし、ソフトウェア開発には「不確実性のコーン」という概念があります。

大切なのは、ズレたことを悔やむことではなく、この「ズレ」をきっかけに、なぜ起きたのかを分析すること。これこそがスクラムでいう「検査」の本質です。

【YWTを使った記述例】

やったこと：Pythonで関数を定義し、条件分岐によって戻り値を変える処理を書いた。[予測 0.5h / 実績 1.5h]

分かったこと：見積もりを大幅に超えた原因は、単純な「インデントミス」による意図しない挙動の調査だった。
            Pythonにおいてインデントは単なる見た目ではなく「構文そのもの」であるという認識が甘く、デバッグに時間をかけすぎてしまった。

次にすること：拡張機能を導入して自動修正、またはエラー波線が出るように設定する。

最後に

他にも今回紹介しきれなかった振り返りフレームワークはたくさんあります。
しかし、どの手法を使っても、目的は「透明性を高め、検査し、より良く適応する」ことの1点に集約されます。

「何を書けばいいかわからない」日報を卒業し、フレームワークを使って自分をアップデートし続けましょう。その積み重ねが、半年後のあなたを必ず助けてくれます！