チーム開発において、振り返りが重要なことは疑う余地がない。課題を見つけて改善し、次はうまくやれるようにする。KPTをはじめとした方法論も様々話題に上がっており、それを全くやっていないところなんてないんじゃないかと思う。
しかし、どれだけ振り返りを丁寧にやったところで、プロジェクトを成功させ続けることはできない。振り返りは問題が起きてから、あるいは起こった後に改善する手法であって、次をうまくやるのには効果的かもしれないが、起こってしまった問題の影響を取り返すことはできない。取り返しの付かない大きな問題が起きれば、次はうまくやれるかもしれないが、そのプロジェクトの失敗は確定する。
なんなら振り返りだけではプロジェクトは常に失敗すると思う。なぜならプロジェクトは常に変化するし、チームも変化する、環境も変わる。常に新しい問題が出てくるので、毎回その影響を受け続けることになる。振り返りをちゃんとやってるから大丈夫、というのは間違った自信だ。
ではプロジェクトを成功させるためにはどうするか。見通しをやるしかない。過去ではなくて未来、このあとどういうふうに自分たちが動き、そのなかでどんな問題が起きるのか。それを可能な限り想像して、問題を回避するためのアクションを取る。
インセプションデッキなんかはこの見通しのためのツールの側面があると思うが、振り返りに比べると、見通しは勘とか経験、あるいはドメイン知識とか属人性がないとできない傾向が強い。夜も眠れなくなるような問題とか、ステークホルダーを漏れなく洗い出すにはベテランが必要だ。
そういう誰もができるわけでもない振る舞いなので「見通しをやろうな」はあまり語られず、「振り返りはいいぞ」ばかりが目につくのかもしれない。そもそもぼくは見通しって今言っているけど、用語としても別に成立してないし。
ちなみに誤解の内容に書くと、インセプションデッキをやりましょう、それさえやれば大丈夫なんてことを書いているつもりはない。見通しは振り返りと同様に小さな単位から大きな単位まであり、プロジェクト全体の夜も眠れなくなるような問題の見通しもあれば、メンバー個人が今日の仕事をいい感じにやるための見通しもある。
とはいえ何も具体な手法のことを言わないのもアレなので、個人的に良いと思っている手法を提示すると、定期的（週1ぐらい）でプロジェクトのキーパーソンが集まって会話をとにかくする。その中で「このあとってこういうふうに動くよね」「なんか不安あるっけ」「つまづきそうなことある？」というようなことを話す。集まった上でこの会話になってないのだとしたら、おそらく目の前のことすら十分に話せていないぐらい会話の時間がそもそも足りていない。無言になって切り上げて解散が発生するまで会話の頻度を上げたほうがいい。集まり方は何でもよいが。十分な時間の余白を確保するという意味では1on1のほうが良いと思う。キーパーソンが複数人いるなら、1on1を複数やればいいだけ。
そういうわけなので、振り返りよりも見通しが重要なんじゃないかということを書いた。問題が起きてから対処するよりも、問題が起きる前に回避したほうが圧倒的に良いに決まっている。ただ、事前に回避すると、そのアクションをとったことが良かったのか目立たないし、起きなかった問題のためのアクションが無駄に思えたりしてしまう。炎上プロジェクトを残業でどうにかしたことが評価されて、炎上を回避して健康的にやりきったプロジェクトが評価されない事象に近いかもしれない。それそのものかもしれない。
