ふりかえりを実践してみて

Redmineでチケット駆動開発を運用し始めてから、自然にふりかえりを取り入れることが多くなった。
ふりかえりでは、KPTという思考フレームワークを使うことが多い。

このKPTという手法で、開発チームと開発プロセスを大きく改善できた経験をしたので、振り返ってみる。
＃ラフなメモ書き。後でまとめる。

【元ネタ】
初めてのプロジェクトリーダー（6）
「ふりかえり」でプロジェクトを改善する

オブジェクト倶楽部の「プロジェクトファシリテーション 実践編 ふりかえりガイド」

【1】ふりかえりが無いチームは成長しない

成果物の品質が悪く、納期がズルズルと遅れる開発チームでは、同じ失敗を何度も繰り返す症状が多いだろう。
例えば、デグレ。
デグレが何度も起きると、その成果物そのものの信頼性が損なわれ、最終的には人間関係の信頼まで壊れてしまう。

そんな症状を見ると、駄目なチームはフィードバックプロセスが無い事実に気付く。
フィードバックが無いから、プロジェクト管理者は裸の王様。
現場の開発者の実情も気持ちも知らないから、リスクが突然表面化して、慌てて対策を立てても、手遅れだったり、的外れだったりする時も多い。

この症状はSW開発だけでなく、ビジネスでも同じだ。
現場のフィードバックの無い会社は、経営層が独裁者であり、経営層は裸の王様にすぎない。

特に、デスマーチプロジェクトでは、フィードバックプロセスが無く、目的の無い作業が延々と続けられる。
プロジェクトには必ず納期があり、プロジェクトを一つずつ経験していくうちに、ノウハウがたまって成長していくのに、ゴールの見えない作業は、単に疲労感をもたらすだけ。
開発者も管理者も成長しない。

現場から問題点のフィードバックがあれば、管理者も開発者もその問題を解決しようという行動が自然に出てくる。
「ザ・ファシリテーター2―理屈じゃ、誰も動かない!」では、人は問題に気付くと問題を解決しようと自然に動くものだ、という一節がある。

リスク管理に敏感な管理者ほど、リスクを嗅ぎ取るためのフィードバックを大切にするものだ。
すると、フィードバックする雰囲気作り、場作りが重要になってくる。
このフィードバックプロセスをマネジメントとしてフレームワーク化したものが「ふりかえり」だと考える。

【2】ふりかえりはフィードバックプロセス(つまり、評価＆改善プロセス)

アジャイル開発の一番の特徴は、インクリメンタルな開発だと思う。
２～４週間のサイクルで開発＆リリースを繰り返しながら、成果物を積み重ねていく。
チケット駆動開発も、バージョン単位で小規模リリースしていくから、インクリメンタルな開発を自然に行っている。
この時、バージョン単位でリリースした後に、ふりかえりを行うと効果的。

ふりかえりは、プロジェクトファシリテーションのプラクティスの一つとして提唱されているので、詳細はガイドを読むといい。
ふりかえりは一言で言うならば、PDCAサイクルの評価と改善プロセスに相当する。

僕のチームでは、Redmineロードマップに従ってバージョンをリリースした後、必ず、今回のリリースで何が良かったか、あるいは、何が悪かったのか、を自然にふりかえる雰囲気が生まれてきた。

全てのリリースがいつも成功するわけではない。
リリースした後に障害がすぐに判明する時もある。
リリースは成功しても、その過程で無理な作業を強いてしまう時もある。

チケット駆動開発では、リリース結果が終了チケットの履歴として残る。
バージョン履歴やコミットログ統計、チケット集計結果から、このチケットの修正方法が甘かった、とか、テストで混乱したのはテストケースの説明が不十分だったから、とか、工数見積もりを誤ったのはリファクタリングの作業を入れていなかったから無理が生じた、など、色んな意見が開発者から出てきた。
プロジェクトリーダーは、それらの意見を取り入れて、次のバージョンで改善した運用ルールを導入する。
その運用がうまくいったならば、一つの問題が解決したことになる。

このサイクルを意識化したプロセスが、KPTによるふりかえりだ。
フィードバックプロセスがあるからこそ、PDCAサイクルはらせん構造となり、チームは成長していく。

【3】KPTは誰もが意見しやすいような雰囲気を作る

KPTのからくりは非常に簡単。
Keep(良かったから次も続けたいこと)、Problem(問題だから次は止めたいこと)、Try(次に挑戦したいこと)の3つをチーム全員で書き出してまとめること。

僕がKPTで一番注意するのは、チーム一人一人が必ず1回は発言すること。
ワインバーグの本「スーパーエンジニアへの道―技術リーダーシップの人間学」には、技術上の問題を解決する意見を言った人は、そのチームの発言回数が最も少ない女性だったという例をあげて、少数意見を取り入れるリーダーシップの重要性を指摘している。

僕は、メンバーにPostItに書いてもらっている。
ホワイトボードへ書くようにしたら、うまくゆかなかった経験があったから。

普通の日本人は自己主張しない。
特に女性はそうだ。
大きな声を立てる人の意見だけが残り、数少ない少数意見が出にくい。
PostItなら、一旦静かになるが、どのメンバーも必ず一つは意見を出してくれる。

但し、他のファシリテーターから、ホワイトボードで書くやり方ができないのは、プロジェクトリーダーにファシリテーションのスキルが無いからだろう、という指摘を受けた。
他にも良い方法があるかもしれない。

【4】KPTに出てくる改善パターン

KPTをやって一番面白かったのは、リーダーがあげたKeepが、メンバーからProblemという指摘を受けたこと。
例えば、僕のチームでは、仕様確認をExcelで残す運用を僕がKeepにあげたら、開発者から、Excelでは欲しい情報を全文検索しにくい、というProblemがあがった。
これはリーダーの認識が裸の王様だった、という事実そのもの。
メンバーからProblemの理由をきちんと聞けば、それなりの理由があることが分かり、そこから問題点を改善しようとする雰囲気になる。

問題意識の強いチームは、Keepをすっ飛ばして、Problemを話したがる。
あるいは、Problemの中に、この問題はこのような解決策があるから試したい、というTryの意見が混じる時もある。
ProblemからTryの話が膨らむ時は、結構楽しい。
僕のチームでは、ProblemとTryの議論が白熱する場面が多くて、次のバージョンではこんな対策や運用を試してみようか、という結論に達する時がある。

そして、そのTryを一つずつ次のバージョンで取り入れていくうちに、開発プロセスは自然に改善されて、生産性が高くなってゆく。

Tryの項目が成功したならば、その項目はKeepに移る。
今後も続けるべき運用ルールになるだろう。
そして、その運用ルールでは解決できない新たな問題が又出てくるだろう。

KPTを続けると、Problem→Try→Keepという自然なループ構造が発生する。

しかし、KPTで全てがうまくいくとは限らない。
5回以上KPTを続けてみると、Problemに問題がずっと溜まり続ける時がある。
あるいは、問題解決策がTryに提示されているのに、放置状態になっている時がある。
つまり、TODOがたまるとTryが多くなる。

そんな時はProblemやTryの棚卸しが必要。
Tryに上がった解決策を実際に試して成功したか、その評価を聞く。
あるいは、Problemにあがった問題がどのように変化してTryへ移り、Keepへ昇華されたのか、辿ってみる。

すぐに解決できない問題も時には存在する。
そういう問題は、隠さないけれども認識はしておくべきだろう。

KPTによるふりかえりを僕が使った動機の一つは、RedmineやTestLinkの運用について開発者の率直な意見が聞きたかったからだ。
RedmineやTestLinkを導入して、プロジェクト管理も開発プロセスも劇的に変化したけれども、その運用が根付いた理由は、開発者の積極的な関与もあったから。

ツールとその運用は、セットで考えるべきだと思う。
その時に、KPTのよるふりかえりは大きな威力を発揮すると思う。