昨年の後半はふりかえり記事を書くことが多かったですが、何となくで書いているところもあったので、どうやって振り返っているか観察してみました
この記事は、「開発ふりかえり記事」をどう書いているか、書く時のテンプレなどはあるか、についてまとめたものです。
はじめに
記事を書く前に感じていたこと
YWT（やった、わかった、次にやること）は使っているとして、要約は意識してるかな…
記事を書いて分かったこと
ふりかえってみて感じたのは、けっこういろんなことしてる、ということでした
文脈として「どう考えるクセがあって、どう対処したor感じたか」に帰結する事が多く、また前述の他に、フィードバックを意識して作業していることに気づきました
この記事を参考にしたわけではないのですが、だいだいこの記事にあることをやっているような気がしました（経験学習モデル、ダブルループ学習、YWP、KPT）
目標の振り返りの【具体的な書き方】【例文】 - カオナビ人事用語集
ふりかえり自体を避けたくなる心理に対し「どんな心づもりで書いているのか」も、まとめてみることにしました
心構え
先に、抵抗を消すために意識していること
意識的に楽観する
ふりかえりを書くときに、「こんなことはもうみんな知っているのでは」「こんなのは初歩的な過ち」「前も同じことを書いたな」など、世間体を気にする気持ち、恥ずかしさ、迷い等が、貴重なアウトプットを複雑で分かりにくいものにしてしまう可能性があります
そんなときは、以下のようなことばを心の中で唱えたりしています
●もう他の人が書いたのでは→自分も出していい
●こんな初歩的な内容→自分のような初歩に助かる
●以前に書いてしまったからもうこのネタは使えない→使っていい（なんなら同じ記事を10回投稿していい）
批判―ネガティブに対処する
意識的な楽観のバックグラウンドとして、人は新しい情報を好む（報酬回路）けれども、慣れたものに手を出す（恒常性バイアス）という、一見相反する情動を持っていることを前提にしています
注目される方が大変なのに、炎上したらどうしようとか、間違ってたらどうしようとか、さらに不安が増すときもあります
その時は、さらにネガティブな読者像をイメージし、層に分けてみています（関心ある人か、対処できる相手か）
忘れる＞前向きに受け取る＞固執する（批判など）＞アンチ（逆鱗＞逆恨み）＞関心が無い
人は読んだそばから書いてあったことを忘れます
忘れてなくても、記事や筆者に間違いがあった場合、それが後から訂正されれば、改善は前向きに受け取るし、前向きに受け取らなくても、固執するのはその筆者に関心があるから
関心がなければ自分もその方を相手する必要が無いし、もし関心の持たれ方がアンチ方向なら、（自分の書いた記事が）なぜその記事がその方をアンチにしてしまったかに関心があります
もしアンチ理由が重要であれば、その批判や指示に従うかは別にして、私が意図せず業界の不文律や暗黙の期待値に踏み込んだ可能性を疑います
もしアンチ理由がどうでもいいことであれば、お互いのために関係を切るだけだし、その批判は、おそらく自分以外にも不特定多数に向けられていると思います（自分だけと思うから辛くなる）
そう思えば、振り返りを書くのも、まぁそこまで悪くはないかなと思えるのでは、と思います
書く手順（フィードバックループ）
目次→要約→キーフレーズの順に内容を固めていきます
キーフレーズを抽出後、キーフレーズに基づきもう一回要約し直します
目次と書き出し、目次と要約、目次とキーフレーズ、のように、常に目次をフィードバック対象として文を構成していきます
目次を書く
最初の切り口は、YWT（やった、わかった、次にこうする）を使うことが多いです
ただ、最終的な構成は、ふりかえり毎に変わります
過去の振り返り記事の目次
改めて見返してみても、あまり共通点が見えません…
それでも、「どう考えるクセがあって、どう対処したor感じたか」という文脈は伝わる目次になっていそうです
要約とキーフレーズの抽出を重ねることで、目次が毎回変わるのかもしれません
目次の行数
目次の大見出しが4を超えると複雑さが増し、中見出しも5を超えると複雑、全見出し数が10-15を超えると読む気が失せるので、この辺りは意識しています
書き出す
最初は以下の切り口で書き出すことが多いです
●やったこと
●思ったこと
●躓いたこと
●またやりたいこと
●もうやりたくないこと
特に、もうやりたくないことについては、「手戻りが発生したポイント」「迷い」や「ファイル探しで時間を取られたポイント」を見つけ、さらに２種類に分けます
●それでもまたやらなきゃならない場合（代替案が無い）
可能な範囲でマニュアル化
他の方の良い記事があればリンクを貼り、補足
●代わりの方法がある場合
before→afterの形式にして、こう思っていたけどこうだった、次はこうしてみよう
書き出した内容のうち、これだけは言いたいという内容を中心にグループ分けします
要約する
書いた内容を要約する方法はいろいろあり、興味がある分野なので、さまざまなアプローチを試しています
最近特に気に入っているのが、拾い読み（スキミング）を意識した要約です
TEDなどで使われる英語のスピーチは、拾い読みしやすいように、段落の最初の文は段落の要約文で、またスピーチの最初と最後に全体のまとめを2-3文で説明します
●全体要約、命題、詳細、まとめ
●各段落の最初の１文だけ読んで全体を推測できる
英語スピーチの最初の段落の最後の文には、命題（このスピーチであなたはどんな問題を解決するか、問題は何か）を書きます
この方法で要約してみることで、全体の要約、段落の要約を目次と比較できて、目次の文脈が通っているか検証ができます
（あくまで要約のためなので、このルールに厳密に従っているわけではありません）
キーフレーズを抽出する
何度か要約し推敲したあとに、さらに文脈にねじれが出ていないか、キーフレーズを抽出します
ここはもう、あまり深く考えずに読み、飛び込んできた言葉に強調を入れます
重要なことば（名詞、動詞）やキーフレーズ（教訓）に、太線、下線を引きますが、
強調が多すぎないようにします
この段階で、段落がキーフレーズの提示か、キーフレーズの説明か、それ以外かを判断し、キーフレーズに関係ない内容は削除します
通常、5行以上の文は苦痛で読めないと言われているので、一つの見出しは3段落、一段落は長くても5行以内になるようキーフレーズ抽出段階でさらに要約します
キーフレーズの抽出後、もう一度目次を見直します
これを繰り返すことで、さらに目次にフィードバックをかけます
最後に
ふりかえりにニーズがあるのは製品をリリースした直後だけで、ふりかえったところでその後検索エンジンで上位になることも無いかもしれませんが、自分の思考のクセを見つけるにはいいアウトプットになります
また、しっかり要約してまとめたら、それなりに得るものがあります
それでも読まれなかったら、それもまたチャンスと考えます
●読まれなかった→もう一回同じ内容で書ける
●読まれた→分かりやすい書き方ができた
どちらの結果も前向きに捉えられるよう、反響の測り方を考えておくのも大事だと思っています
この内容に限らず、いつ書いた内容であっても、いいねしていただけたら、何か得るものがあったのかなと受け取ります
（以上）
