初リーダーでのアジャイル開発

（5）プロジェクトとしての試み

最後のリリース（3rdリリース）は、2010年7月。いよいよ社外向けのリリースです。ソース・コードに関しては、2010年6月中旬にフィックスする必要がありました。

最終リリース成功の要因

ここでは、最後のリリースに向けて筆者たちが行った取り組み内容を、4つ述べます。（1）Redmineの運用方法を一新、（2）早い段階で結合テストを実施、（3）担当者間の密な連携、（4）リポジトリの一本化、です。

（1）まず、2ndリリースの前後で、Redmineの運用方法を一新しました。これまでは、Redmineを、タスクやバグの一覧として用いていました。実装優先度などは、定例会議のタイミングで確認していました。このやり方を変えました。

具体的には、各チケットについて、明確にどの期限までに必要かを入力してもらい、また、タスクの重要度も入力してもらうようにしました。開発チームは、これに基づいて、重要度の高いチケットから順に着手することにしました。

こうすることで、機能をどんどん実装していくことが可能になりました。

（2）次に、前回の反省（要望と異なるものを作ったという失敗）から、今回は、とにかく早い段階で、結合したテスト環境に乗せ、動作を確認してもらうことにしました。

これによって、プロダクトの動作に関する認識違い、などのフィードバックを、素早く得ることができるようになりました。

（3）さらに、担当者間で、密に連携を取るようにしました。テスト環境での動作上で問題があれば、週1回の会議を待たず、Redmineでのコメントやメールを通して、相手の開発担当者とこちらの担当者間同士で、直接やりとりをし、対応するようにしました。

最も効果的だと思ったのは、メールなどでは伝わりにくい、仕様などに関するささいな疑問点があった際に、積極的にユーザーに直接、質問に行くようにしたことです。これにより「仕様があいまいなために開発が進まない」という問題が解消されるようになりました^*1。

• [*1] 筆者注: 本来であれば、オンサイト顧客（意思決定ができるユーザー）と同じ場所で働くのがベストです。

（4）最後に、バージョン管理システムの連携による、リポジトリの一本化です。

先に開発に着手した開発チームのプロダクトは、「Git」を用いてソースを管理していました。一方、ユーザー側のプロダクトは、「Subversion」を用いてソースを管理していました。これら2つのプロダクトは、それぞれ異なるバージョン管理システムにより、別々に管理されていました。

当初は、開発チームのソース・コードを圧縮して固め、これをユーザーに渡すというかたちでデプロイしていました。これを改め、Gitの関連ツールである「git-svn」を用いて、Subversionのリポジトリに対し、開発チームの変更を日次で反映するようにしたのです。

こうすることで、機能の実装や問題の改修を、早期にテスト環境に反映できるようになりました。

上記の4つの工夫により、プロダクトの開発サイクルを早く回せる環境に改善したことで、筆者たちは無事に最終版をリリースすることができたのです。これらは、アジャイルな開発では最初からするべき、という内容です。しかし、筆者たちは、紆余曲折しましたが、最終段階になって実践できるようになったのでした。

プロジェクトをふりかえってみて

さて、今回のプロジェクト事例においても、いくつかの「情報共有」や「改善」に触れました。気付いていただけたでしょうか。例えば、以下のような取り組みを紹介しました。

• 「要望を次から次へと会議でお願いされ、それを受け入れる」という問題に対し、Redmineにあらかじめ要望を入れておいてもらうことで、チームで返答を考える
• 最初のリリース直後に、ソース・コードがチームで共有されていないという問題や、新しく入ったメンバーとのソース・コードの共有にあたり、ユーザーと調整して時間をもらい、テスト・コードをペア・プログラミングで書く
• 人数が増え、チーム全員で設計を共有しにくい、という状態に対して、ホワイト・ボードの前で全員で設計する
• ユーザーが想定した仕様と異なる実装をして失敗したことに対して、結合した環境を早い段階で用意してもらい、動作を確認してもらう
• クリティカルな問題や、仕様上確認したいことがあれば、週1回の定例を待たず、Redmineやメール、そして直接の対話を通じて対応していく

もちろん、ほかにも、より良い解決策があったかもしれません。しかし、筆者たちのプロジェクトでは、こうした答えを自分たちで探し、実施していったのです。ここで重要なのは「自分たち」とは何か、ということです。

今回のプロジェクトがうまくいった要因には、ユーザーとの連携がうまくいったということがあります。例えば、Redmineの導入や運用方法の「改善」、リポジトリの同期などは、開発チームが率先してやったわけではありません、これらは、ユーザー側からの提案でした。

このようにして、プロジェクトは「反復」して開発を行い、徐々に開発チームとユーザーが一体になっていきました。これにより、プロジェクトは成功したのだと思います。

（6）まとめ

今回は、クラウド・サービス開発の事例を用いて、筆者がリーダーとして携わったプロジェクトが、どのようにアジャイルを実践していったのかを伝えました。今回の事例を通し、開発者とユーザーが1つになってアジャイルを実践していくことが成功への鍵だと実感しました。

「反復」とは、繰り返すということです。今回の事例を通し、開発、そしてリリースを繰り返していくことが、プロジェクトにとって非常に大切だと伝わったのではないでしょうか。前回までの3回の連載で筆者が伝えた内容もまた、「反復」して第4回の今回で伝えられたのではないかと思います。

第1回では、アジャイルの基礎的な内容とその背景を紹介しました。第2回から今回までは、事例をベースに紹介しました。ここで1つ質問です。チームやプロジェクトなどの組織がアジャイルな開発をする目的は何でしょうか。

本連載からも分かると思いますが、アジャイルな開発は、すぐに高い効果を出す「銀の弾丸」ではありません。本当に成功へと至るためには、チームもユーザーも一丸となり、本気で取り組んでいく必要があります。

「アジャイルな開発をする目的」を共有し、それを見直し、実践するうえで、本連載の内容を参考にしていただければと思います。開発者とユーザーが、ともにアジャイルを実践し、本当に価値あるモノを手にすることができる状態を目指しましょう。