『WFプロジェクトでもできる改善』意識してふりかえりをしよう

こんにちは。ITサービス事業部の岡島一樹です。

ウォーターフォールプロジェクト改善の第3弾です。

前回の記事も参照頂ければ幸いです。

・『WFプロジェクトでもできる改善』夕会よりも朝会をやってみよう

・『WFプロジェクトでもできる改善』朝会を改善しよう

今回のテーマは「意識してふりかえりをしよう」です。

ところでみなさん、プロジェクトのふりかえりってやってますか？

アジャイルのプロジェクトでは当然のようにやっていることでしょう。

スクラムであればプロセスの中にレトロスペクティブが組み込まれているので、あまり意識しなくてもプロセスをふりかえる機会は増えます。

ではウォーターフォールのプロジェクトではいかがでしょうか？

私の経験談ですが、意識してやらないとふりかえることがないままプロジェクトが終わってしまうとうことが多いように思います。

ウォーターフォールでのふりかえり

ではそもそもウォーターフォールにふりかえりは必要なのでしょうか？

仮に万能で神がかったリーダーが一人いてプロジェクトのプロセスが完璧にできあがっていて、メンバーはおんぶに抱っこで良い、そんなチームであればふりかえりを取り入れてまで

プロセスを改善する必要はないかもしれません。

ですがほとんどのリーダーは万能ではなく普通の人ですよね。

メンバーの意見は聞きたいですし、改善できることはしていきたい、そう思っているリーダーが多いのではないでしょうか？少なくても私自身はそう思っています。

ふりかえりはアジャイルだけのものではない

ふりかえりを実施することで自分たちのチームのプロセスを見直す機会を設けることができます。これはアジャイルとかウォーターフォールとか関係ないですよね。

つまり、ふりかえりってアジャイルの専売特許ではないんですよね。

そしてウォーターフォールこそ意識してやらないとふりかえる機会すらないのです。

ふりかえりを実施するタイミング

問題はいつやるかですが、スクラムであればスプリント単位のキリの良いタイミングで実施できます。同じようにウォーターフォールでもキリが良いタイミングでふりかえりするとどうなるか、シミュレーションしてみましょう。

パターン①：プロジェクトの最後にふりかえりする

これは問題外ですね。

ふりかえりで上がったきたTryを実施しないままプロジェクトが終わってしまいました。

私も昔経験したことがありますが、プロジェクトが終わればメンバーは散り散りになってしまい、チームで決めたアクションを実践できません。

個人レベルのアクションは次のプロジェクトで生かせるのかもしれませんが、チームとしての改善がないまま終わってしまうのは非常に勿体ないです。

パターン②：工程ごとにふりかえりする

こちらも微妙です。

仮に開発工程のプロセスを改善したい場合、開発工程の最後にふりかえりしても意味ないですね。ふりかえりで出たアクションを実施できるのは結合テスト以降ということになってしまい、開発工程のプロセスを改善することができません。

そして工程の期間が長いと思い出すことが大変になり、ふりかえりの時間も長くなってしまいがちです。

パターン③：キリの良いタイミングに囚われない

これなら改善が継続しそうですね。

ウォーターフォールの場合、キリが良いとか悪いとかでふりかえりのタイミングを決めるべきではなさそうです。そして工程としてキリが悪くても、1週間とか2週間とか短いスパンでやるべきです。そして朝会と同じようにどんなスパンでやるのかチームで決めて、時間帯も固定化することをおすすめします。固定化することでチームにリズムが生まれてきますし、ふりかえりの時間にメンバーが別の予定を入れないよううにすることもできます。

ふりかえりの手法

ところでふりかえりの手法には様々なものがあります。

チームに合わせてどのやり方でも良いと思いますが、私はKPTをおすすめします。

初心者でも分かりやすいですし、実践しやすいです。

要はカイゼンのサイクルを回せるかが重要です。

チームでやると決めたTryは確実に消化していくようにしましょう。

そのための工夫は次回でお話します。

最後に一言

最後になりますが、ウォーターフォールと言えども今までのやり方を盲目的に信じて突き進む必要はない、ということです。

やってみてうまくいかなければ軌道修正していけば良いですし、結果的にチーム全体がカイゼンしていった方がみんながハッピーになれると思いませんか？

今回は以上になります。

みなさんも参考にしてみてください。