振り返りが大事 - jun-ichi.blog.hatena

仕事をしていると、「やりたいなと思っていてもできていないこと」がたくさんある。仕事が一段楽したあとの「振り返り」もその中のひとつだ。

CreativeCommons Attribution-NonCommercial-NoDerivs License, Ootani

プロジェクトを進めるために、いろいろなことを考えて、実行していく。その中には、うまくいったものもあれば、うまくいかなかったものもある。けれども、プロジェクトの終わりには、なんだかんだで「結果オーライ」な感じになって、「なんかいろいろ苦労したけど、結果的にはうまくいってよかった、よかった」で終わっていることが多い気がする。

これでは、「経験」が「思い出」になるだけで終わってしまう。うまくいったことも、うまくいかなかったことも、分析して共有することで「思い出」ではなく「（組織の）ノウハウ」にすることができる。そのために、本当は、プロジェクトのメンバ間で次のようなことを共有できればよいと考えている：

今回のプロジェクトでチャレンジしたことは何だろうか？
- それはどのように評価できるだろうか
うまくいったと言えるのは何か？
- その原因はなんだろう
- それは別のプロジェクトにも活かせるだろうか
- もっとうまくやる方法はないだろうか
うまくいかなかったのは何か
- その原因はなんだろう
- どうすればうまくできるだろうか
楽しかった、嬉しかったのはどんな時か
- それはなぜだろう
- どうすればもっと楽しめるだろうか
辛かった、むかついたのはどんな時か
- それはなぜだろう
- どうすればそれを回避することができただろうか

もう少しシステムよりの観点だと、こんなところも共有したい。

これは「はまった」という障害は何だった？
実は作り直したいと思っているところない？
ここは「いけてる」、と思っているところある？
実はやばいと思っているところない？
このプロジェクトの本当の工数（深夜、休日を含める）ってどのくらい？見積もりとの乖離は？
このシステムの最終的な規模ってどのくらい？見積もりとの乖離は？

さまざまな観点で、何が良かったのか、または何が悪かったのかを客観的に分析して、次に活かしていくことが大切だと思う。たとえば、実態工数はファクトデータとして蓄積すると同時に、可能であればお客様に対してもフィードバックすべきものなのではないか。こういうフィードバックがちゃんと行われていないことが、システム業界の労務環境がよくならないことの一因だと考えているからなのだが、それはまた別の話。

プロジェクトがひと段落したら、ぜひこういう観点でディスカッションしたい。ただ、その頃には忘れてしまいそうだからメモしておこう。その中で、一般的だと思えるものはここでも紹介したい。（つづく、かも）