皆さんは、自分の行動に対して発生した結果の検証（振り返り）などは行っているだろうか。簡単にいうと、反省会をしているだろうか。
筆者は優秀ではないので、何かミスをしたり問題が発生した時は、何故それが起きてしまったかを検証し、再発をしない為にどうすべきかを行ってきた。（完璧じゃないし、甘めであるという逃げ道は作っておくｗ）
また、反省するふりをした思考停止状態の人達も目の当たりにしてきた。
ここでは、その辺りの体験談を交えて、意味のある振り返り、反省会のやり方のアドバイスが出来ればと思う。
〇本当に改善する気ある？
そもそも、反省会を行う目的とは何だろうか。
行いを振り返り、そこから教訓を得て、次に生かす。
なるほど、聞こえはいいが全く具体性が無い文章だ。
反省会を行う理由は、それまでの経緯で発生した良くない点、問題点、改善すべき点を洗い出し、具体的にそれらを解決する為の手段を確定する為に行う。
更に、それはきちんと取り組める内容になっていなければならない。
つまり、改善する為の行動が導きだせないといけない。この具体的な行動を示せなかった反省会には何の意味もない。
よく筆者が見かけるのは、以下のような反省だ
・次回から気を付ける
・意識できるように心掛ける
見る度に思う。
具体的にどうやって？と
悪かった点を認識できるところまではいい。世の中には、それが問題点なんだと気づかせる所から始めないといけない人間も居るからだ。
問題は、それを再発しない為の具体的にどのような行動を取ればいいかを考えて実践しようとしていない所だ。
それが無ければ、結局同じ事の繰り返しである。
これが個人の振り返り報告などならまだいいが、反省を目的とした会議でもこのような結論に至っているプロジェクトを良く見かける。
この状態に何の疑問も感じていない人間を、思考停止状態と呼んでいる。
〇どんな時に反省会した方がいいの？
反省会というと、大人数で行うようなイメージがあるが、別にこれは一人で行ったって構わない。
ただ、お互いに意見交換することに意義があるなら、それは反省会の場を設けて大人数で反省内容の検証をしてもいいと思っている。
振り返りをした方がいい物は、常に自分の行った行動に対して行うのがいいが、慣れないうちは大変だと思うので、ここは押さえといた方がいいという物だけピックアップする。
・プロジェクトの節目（特に、リリース終わった時等）
これはかなり大事だ。反省会の全てに言える事だが、振り返るべき物は「失敗した物」だけではなく「成功した物」に関してもきちんと考察する事だ。
思考の順序としては
・なぜ「成功or失敗」したのか
・成功の場合は、それを継続して行う為にはどうすればいいのか
・失敗した場合は、その失敗が引き起こされた根本の原因は何で、どのような行動をすれば再発が防げるか
といった具合だ。
特に、自分が提案した内容に関して他者からのフィードバックを貰ういい機会なので、批判的な内容だったとしても意見を貰えるなら貰った方がいい。必ず次回の糧になるはずだ。
・月末に、自分の作業履歴の振り返り
これは必須ではないが、自分の作業能力に関心があるのならやっておいて損はない。
皆さんは、自分の作業履歴をどの程度細かく把握しているだろうか。
筆者は、1時間単位で行った事をメモして、1日の終わりにそれを表にしてまとめている。1時間単位で行ったことは、更に詳細にどのような作業をしたのかをメモしている。
また、当初予定していた実装と、追加仕様対応と、不具合修正と、残業の項目は分けている。
表の形式は何でもいいが、筆者はWBSの形式を取っている（WBSの話は、また別の機会に）
これを一か月続けると、自分が何にどの程度時間を費やしたかがわかる。
この表を見て、自分の月の作業を振り返るのだ。
例えば、ある機能で当初割り振られた日数は5人日だったとして、それに費やした時間が7人日だったとすると、一見定められた日数で終わっていないように見えるが、実は仕様追加分の作業が3人日分の作業だったので、実際は4人日で終わっているなどがわかる。
つまり、次回からは見積もりをする際に、この追加仕様分の作業を先に行うのなら、その分の見積もりを予め確保するという対策（改善）ができるようになる。
・何か問題が発生した時
これは良く起こる事なので、意識せずに取り組んでいるかもしれないが、一応、例として記載しておく。
例えば、デザイナーさんが全角文字列を含めたファイル名をアップしてしまい、それが原因でアプリがクラッシュしてしまった、なんていう話はよく耳にするのではないだろうか。
確かに、デザイナーさんの不注意ではあるが、問題の根本はそこではない。そんな人の裁量で注意してもらうなんて考え自体がもう間違っている。
この場合は、ビルドをする前にリソースの文字列チェックツールなどを自動で実行してエラーを検知できるようにするなど、人の手ではない手段で解決を図るべきだ。人はミスをする生き物なので、そのような機械的なチェックは機械に任せるように思考を切り替えよう。
つまり、この問題が発生したのは、この問題の発生を予期できなかったエンジニア側の怠慢であるし、それが当然発生すると予見して指示が出せなかったディレクターの責任である。改善策としては、チェッカーツールを作って再発防止に努めるというのがベターだろう。
〇あとがき
途中から、若干反省会とは逸れた内容になってしまったが、結局ここでも言いたい事は、思考停止状態になるなという事だ。
そうすれば、こんな記事読まなくても、具体的な改善策が出ない反省会に出たとしても、必ず疑問を持てるようになる。
常に、「なぜそうなのか」「何の意味があるのか」「本当に改善できないのか」「本当の問題はなんなのか」という思考を持つようにしていってもらいたい。
