「ふりかえり」とは(後編) - ふりかえりの本当の効果

前回はふりかえりの具体的な進め方に着目しましたが、後編では事例を交えながらその効果を考えてみたいと思います。

あるプロジェクトでの事例紹介

自分が参加していたそのプロジェクトは比較的メンバーが多く、およそ30名程度いたと思います。メンバーが多いのでチームを3つほどのサブチームに分け、自分はそのサブチームのリーダーでした。そこではイテレーション開発を採用しており、1回のイテレーションが2カ月程度で全部で3回のイテレーションを計画していました。このイテレーション計画は、[第3回イテレーション開発のノウハウ]でお話したように、あまり効果的なイテレーション計画ではありませんでした。しかし、当時はそれでもなんとかなるだろうということでプロジェクトは進んでいました。

1回目のイテレーション

開発当初から遅延気味ではあったのですが、単体テストまではなんとか予定通りに終了。そして結合テストに入ったのですが、なかなかサービスが期待通りに連携できず四苦八苦していました。この結合テストで初めてクライアントとサーバを接続していましたし、サーバ側もDBとの接続が初めてでした。プロトタイプなどである程度接続確認はしていたのですが、なかなか思い通りにいかず、テストは遅延し当初の予定を達成できませんでした。

最初のふりかえり

1回目のイテレーション終了後に、すべてのチームのメンバーが参加するふりかえりを実施しました。さまざまな問題や意見が交換されるなか、ある若手メンバーから

「単体テスト後すぐに結合テストを実施する計画に問題がある。単体テストと結合テストの間に疎通テスト期間を設ければよいのでは？」

と提案が出されました。実はこのメンバーは、批判的な意見や反抗的な態度を取ることが多く、若干問題があるように思えた方でした。開発経験も少なく、特別なスキルもありませんでした。ただそのような方から建設的な意見が出されたことに少々驚きを感じていました。

内心は、この提案自体はあまり効果がないだろう、とその時点では感じていました。問題点は、単体テストが簡易なテストコードのみで終了していた点で、そちらをなんとかするほうが効果的、というのが自分の考えでした。しかし、プロジェクトに批判的だったメンバーが出してくれた、貴重な意見と感じたので、議論の方向性を見守っていました。結局そのふりかえりでは、「疎通テスト期間を設けましょう」となりそのメンバーが該当局面の担当リーダーとして抜擢されていました。

2回目のイテレーション

やはり開発は遅延気味でした。新たに定義した疎通テストでは、そのテスト自体は計画通りに終了しました。しかし、結合テストでは今度はフレームワークのアーキテクチャ問題が発生し、やはり当初の予定をクリアすることはできませんでした。ただ疎通テストを任された方は、依然批判的な意見は言うものの、その解決策なども考えてくるようになり、うまく行かないながらも能動的に動くようになっていました。イテレーションとしては成果が出なかったのですが、メンバーの自立性という意味では大きな成果が見えました。

3回目のイテレーション

当初の計画によるとイテレーションは3回でしたが、あまりにリスクが高すぎるため、3回目のイテレーションは2回に分割し実施することにしました。3回目からは開発要員を増員する予定もあったので増員も行いました。遅延プロジェクトに増員するとかえって生産性が悪くなることも多いのですが、物理的な作業量を考えると絶対に必要という状況でした。危機的状況ではあったのですが、前述のメンバーに代表されるように、メンバー全員が問題意識を持ち、能動的に考え動くようになったと思います。実際に疎通テストを担当してくれたメンバーはこの頃にはほぼサブリーダーと同等という雰囲気がでており、チームの中心メンバーとして精力的に動いてくれていました。

実際には3回目のイテレーションもかなり厳しい状況であり、いくつかは実装漏れもおきましたが、4回目のイテレーションでやっと予定通りの品質を確認でき、最終的には問題なく納品をすることができました。

打ち上げにて

プロジェクトの打ち上げの2次会でのことでした。メンバーは10人ぐらい残っていたと思います。

「いや、ホント厳しかったよね」
「あの問題が出たときにはどうなることかと思ったよ」
「でもやったよね」
「ああ、やった」
「オレたちはやったぞー」
「オオー!!!!!」

こんな感じでメンバー全員で抱き合って叫んでいました。スポーツの大会で優勝したときのような感じでした。ここまで盛り上がることは自分でもほとんど経験はないのですが、大変厳しい状況をチームが一丸となって乗り越えたからこそ喜びが大きかったのだと思います。

ふりかえりの効果

こんなチームができたのも、メンバーの意見を尊重する雰囲気があったからではないだろうかと感じています。そして、最も具体的な例が疎通テストを提案してくれたメンバーの変貌ぶりです。実際、疎通テストが効果的だったか、というと今でも効果は少なかったと感じています。しかし大事なのは、メンバー各自が自ら考え能動的に行動できるチームになっていたかどうか、ということです。ふりかえりを実施し、自分の意見が取り入れられたことにより大きくモチベーションなどが上がったのだと思います。「このチームでは意見を言えば採用される」「自分が考えたアイディアを実践させてくれる」「成功させるためには、自分も自ら考え行動しなくては」という雰囲気が生まれていたように思います。

アジャイル開発では優秀な人材が必要とよく言いますが、問題意識が高く自律的で能動的なチームであれば、メンバーのスキルは多少低くても大抵の難局はクリアできます。これは自分の経験からも確実に言えます。そのようなチームを生み出す状態がアジャイルであり、そして「ふりかえり」が最も効果的に自律的なチームを作り出す方法の1つだということです。もちろんプロジェクトを成功させるためには、ある程度のトップダウン指示なども必要でしょう。しかし、ウォーターフォールに代表されるような進め方でルールに縛られ、工夫をすることを禁止され、指示通りに作業するだけ、というチームで本当に成果を上げることができるでしょうか。それよりは多少の効率の悪さなどには目をつぶってでも、チームやメンバーが自律的にプロジェクトに臨んでくれる方が確実に成功に近付けるはずです。

ふりかえりは、システム開発以外でも有効に活用できるはずです。まだ実施したことがない、という人やチームは「ふりかえり」とは(前編)も参考に、ぜひ実施してみてはいかがでしょうか。

次回は、「オフショア開発の進め方」についてお伝えします。

執筆者紹介

川上文夫

パッケージベンダーのグループマネージャーとして複数プロジェクトのPM、PLを兼務。要件定義からプログラミング、テスト、運用を担当している。数多くのプロジェクトのリーダーとして20年のキャリアがあり、オフショア開発の経験も豊富。独自プラクティスに軽量議事録、朝会Wiki、設計実装並列手法などがある。アジャイル系コミュニティにも所属し、記事の執筆やワークショップ登壇など精力的に活動を続けている。