社外常駐で学んだアジャイル開発

（5）「改善」のための起爆剤となる「ふりかえり」

「ふりかえり」とは、それまでのプロジェクトの状況や実施したことについて見直し、次に何をするべきかを考えるための手法です。

アジャイルにおけるふりかえりの特徴は、イテレーションの終了時やイベントごとに実施する点です。こうして、1回のプロジェクトの間に、何度も実施します。

「何度も実施する」ことが重要です。短い期間で小さな「改善」を実施し、その「フィードバック」を得る、というセットを繰り返すことができるからです。進行中のプロジェクトを、継続的に、より良い方向へと導くことができます。

筆者たちは、開発チーム内では、週に1回のペースで「ふりかえり」を実施しました。また、前述した業務確認テストの終了時などのタイミングでは、ユーザー部門を混じえての「ふりかえり」を実施していました（本来は、日ごろからユーザーを巻き込むことがベストです）。

こうした「ふりかえり」を通して、"開発するうえで問題となったこと"や、"チーム活動をより良くしたもの"を、チーム自身で見つめ直し、メンバー間で共有しました。そして、"問題を解決するためにどうすればいいのか"や、"より良くするためにどうすべきか"という内容を、個人ではなくチーム全体で検討しました。これらにより、それまでのやり方を変化させていきました。

これらの結果として、開発が効率的になったり、プロダクトがより良くなったり、といった内容につながったと思います。

以下では、「ふりかえり」をするうえでのポイントについて解説します。

うれしいことや良かったことを含め、どんどん共有する

問題や課題などは"するする"出るけれども、良かった点がなかなか出ない、ということがあります。また、良かった点を出しづらい雰囲気となることがあります。

実際、筆者も、自分の失敗や問題に焦点をあてがちです。もちろん、それらも非常に大切なことですが、今回これこれにチャレンジしてみて良かった、この作業はとても楽しかった、といった内容も、問題を出すのと同じくらい大切です。チームで共有するべき内容だと思います。

ただし、メンバーが出した内容を深く追及することは大切な一方で、せっかく出した内容を批判することは良くありません。これによって、メンバーが発言しにくい雰囲気になるからです。

また、個人を特定した問題定義も良くありません。問題は人が持っているのではなくチームにあることを強く意識し、チームで対策に取り組んでいく必要があるからです。 今回の事例を通して、「ふりかえり」は、反省会やダメ出しをする場ではないということを感じました。とにかく楽しくワイワイと、うれしいことや良かったことを出しあうことが大切で、それは、プロジェクトの活性化のためにも非常に大切なことだと感じました。

改善案は、現実的に実施可能なアクションを書く

「チーム内で情報共有ができていない」といった問題があった場合、「情報共有をする」という改善案を出したとしても、実際何をすれば良いのか分からない、という状況になります。何も改善されないまま、次に向かうことになりがちです。

間違った方法であっても、また次にそれを見直せば良い、と思います。具体的に実践できる内容をどんどん挙げて、実際に実践していくことが大切だと思います。

もしそれでも問題が挙げづらいのなら、問題をもっといろいろな角度から深く掘っていく必要があるかもしれません。「改善」を続けていき、ある程度長く続いているプロジェクトでは、実際、問題は深い所にあり、具体的な改善策を出すのが難しい時もあります。

筆者たちは、プロジェクトの中盤からは、プロジェクトが抱えている問題を皆で列挙し、その中でも、最も改善したい問題だけに焦点を当て、さまざまな方向から原因は何かを掘り下げていく「ふりかえり」を実施しました。こうして根本原因を見つけたところで、具体的に実践するアクションを挙げて、プロジェクトの改善に取り組んでいったのです。

開発チームに限った話だけを題材としない

開発チームのメンバーだけで「ふりかえり」を行う場合、どうしても開発チームや自分自身に関する話だけになりがちです。

でも、本当に焦点を当てるべきなのは、開発チームに閉じた問題ではないはずです。

エンドユーザーの状況（課している宿題があふれてたまっていないか、など）や、エンドユーザーとの関係性（意思疎通がとれているか、など）も、常に考えるべきです。エンドユーザーが抱えている問題があってプロジェクトがうまくいかない場合は、それらに対して開発チームができることを考えることが大切です。

アジャイルな開発は、エンドユーザーと開発チームが一緒に力を出し合って開発していくことが大切であり、それによって良いプロダクトができると考えています。開発側とか、顧客側とか、そういう風に壁を作ることは、プロジェクトにとっては良くないことです。チーム内の改善と同様に、こうした障壁を変えていく必要があります。

偉そうなことを書いてますが、筆者もいまだに「ふりかえり」の奥深さや難しさを感じます。今回挙げた3点のポイントは、特に筆者自身がよく経験する問題であり、また、今回のプロジェクトでの「ふりかえり」をふりかえってみて気付いたことです。

もし「ふりかえり」をすでに導入しているのに、うまく改善活動が行われていない、という場合は、「ふりかえり」自体のやり方を見直してみるのも良いかもしれません。また、プロジェクトに関係のない外部の人にファシリテートしてもらうのも、客観的な視点から全体を見てもらえるのでよいでしょう。

さまざまな工夫を取り入れて、プロジェクトをより良くしていくことが、アジャイルでうまく開発するコツだと私は思います。

（6）まとめ

今回は、業務システム開発の事例を用いて、アジャイルの効果を解説しました。アジャイルが、いかにして「改善」を実施し、チームの成長、プロダクトの成長、プロジェクトの成長をうながすのか、ということを理解できたのではないでしょうか。

さて、今回説明した「改善」には、実は「勇気」が必要です。なぜなら、時には、これまで当然のようにあったものを捨てなければならないし、時には、これまで体験したこともない新しいことへのチャレンジが必要になるからです。

ただし、これからアジャイルを実践しよう、と考えているのであれば、心配には及びません。なぜなら、アジャイルな開発にチャレンジしようとしている時点で「勇気」を持っている、と筆者は思うからです。

最初から完ぺきな状態で始めなくても、今回紹介したように、プロジェクト全体で少しずつ「改善」を繰り返していき、成長していくことが、もっとも大切なことだと思います。