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

（3）ゆっくり歩き始めたプロジェクト

プロジェクトは、2009年10月に始まりました。初回のリリースは2010年の1月で、社内の利用者向けでした。

プロジェクトの始まり

ユーザー（ビジネス・オーナー、TISの事業部）との初めての打ち合わせでは、「クラウド・サービスを展開しようとしている。それをWebブラウザで操作するための、魅力的なインタフェースを持った画面が欲しい」という説明を受けました。説明の際に、画面名称の一覧と、各画面で何ができるのかを一言のメッセージで記述した、シンプルなドキュメントをもらいました。

筆者たちのチームは、この説明とドキュメントから、「やりたいことはいろいろとあるが、具体的な内容は決まっていない」という印象を受けました。

そこで、筆者たちは、画面の一覧に、優先順位を付けてもらいました。そして、以下の2点を約束してもらいました。

• 最も優先度の高い画面から順に実装して行くこと
• 週に1回、会議を実施し、その画面で何をしたいのかを話しつつ、デモをしながら動きを確認していくこと

こうして、プロジェクトが始まりました。ところが、なんとか1月18日に初期リリースを実施したものの、筆者たちのチームは疲弊した状態になってしまいました。

ゆるふわなコミットメント

読者の皆さんは、ユーザーが「どうしても、これも実装してほしい」という要望を出してきたら、どうしますか。アジャイルな開発では、こうした要望を、いつでも、またいくつでも、追加できるのでしょうか。筆者としては、これは「半分は正解で、半分は違う」と思います。

新しい要件が追加されたときに、その優先度を上げて、先に提供することは可能です。しかし、その分、期限内に実装されない機能が生じます。

しかし、当時、筆者は会議の場で、ユーザーから「どうしても」というお願いがあれば、「まぁ、これ位は大丈夫だろう」と思い、開発チームに相談せずに、どんどん受け入れてしまいました。結果、ただでさえ見積もりに対して結果を出せずに焦りを感じていたチームを、さらに圧迫していく結果となったのです。

このような"ゆるふわ"なコミットメントであったため、初回リリースのテスト直前は、チームはアジャイルの原則を崩した状態となりました。具体的には、メンバー全員が残業し、テスト・コードも書かず、ペア・プログラミングも実施しない、メンバー全員がバラバラの開発、といった状態でした。

これにより、次のリリース向けの開発が始まったころには、「ここのソース・コードが分からない」といった状態が発生したのです。ソースを作成した本人でさえ、どういう意図があったのかを覚えていない個所があり、継続した開発がすぐには実施できない状態になっていたのです。

（4）開発チームの試み

初回リリース後の、次のリリース（2ndリリース）は、2010年3月末でした。社内限定で、サービス内容を向上させる機能が目玉でした。

アジャイルな開発を実践するチームに向かって

初回リリース日の当日から、筆者たちのチームには2人の新メンバーが増えました。1人は、PM（プロジェクト・マネージャ）やリーダーとしての経験が豊かな人です。もう1人は、新しい技術にも積極的に取り組もうとする新人さんでした。

上述したように、初回リリース直前のプログラムは、テスト・コードも無く、ペア・プログラミングも実施していませんでした。このため、すぐには機能拡張に取りかかれない状態でした。

そこで、筆者たちはユーザーと調整し、初回リリース後の、このタイミングで、ペア・プログラミングに着手し、それまで書かれていなかったテスト・コードを書き始めました。こうすることで、リズムを作りつつ、少しずつ新しい要望の実装に着手していったのです。

面白いのは、チームの1人が、アジャイル以外での経験が豊富だったことです。実際にアジャイル開発に参加するうえで、いろいろ驚いた点があったと思います。

例えば、筆者の会社には、標準的な設計書などのフォーマットがあります。ところが、これらのフォーマットを利用したカッチリとしたドキュメントは、筆者たちのチームにはありませんでした。

また、仕事の仕方も、従来の開発とは異なります。リーダーである筆者が「今日はこの作業をやってください」と指示するのではなく、朝会でメンバー全員が「今日はこれをしよう」と言って、その日の作業内容を決めていくのです。

こうしたアジャイルな開発の特性から、アジャイルの経験が少ないメンバーには、さまざまな"疑問"や"不安"が沸いたことでしょう。こういった"疑問"や"不安"の声を聞くたびに、私たちはチーム内でよく話し合いました。

もちろん、すべての疑問や不安に対して、完ぺきな「正解」を出せたわけではなかったと思います。しかし、チーム全体で考え、自分たちの答えを見つけて、それに向かっていったのです。こうして、仕事の仕方に対して、さまざまな意見が出るようになりました。意見が活発に出されるようになったことで、チームでの活動は「改善」されていったのです。

設計に関しても、基本的にペア・プログラミングで行い、ペアを変更して、なるべく多くのことに触れるようにしていました。人数も増えて、なかなか共有できない個所も多くなってきたので、新しい機能の着手前には、全員でホワイト・ボードを前にして設計するようになりました。

2ndリリースに向けて

前述した通り、ユーザーは、筆者たちの開発チームとの調整だけではなく、バックエンド側の開発についても調整する立場にありました。こうして、2ndリリースのころには、さまざまなタスクが混在する状態となっていました。そこで、ITS（課題管理システム）である「Redmine」を利用することにしました。

Redmineの導入は、開発チームにとってもメリットがありました。具体的には、Redmineによって、機能修正や要望の内容を、週次の定例会の前に知ることができました。

事前に機能修正や要望を知ることで、チームで受け入れられるかどうかの見積もりを行い、無理に要望を詰め込まないように調整することができます。また、開発チームからの疑問点をあらかじめ用意して会議に臨むことができるので、以前よりも素早くプロダクトの方向性を決められるようになります。

こうして、初回リリース時の問題を解消しつつ、順調にプロジェクトは回っていきました。そして、2回目の結合テストを迎えました。しかし、残念ながら筆者たちはリリースをすることができませんでした。筆者たちは、ユーザーに対して価値のあるソフトウエアを届ける、という、基本かつ大切なことを失敗してしまったのです。

リリースできなかった理由は、一部の仕様が、ユーザーが想定していたものと大きく違っていた、という致命的な問題でした。定例でのデモでは、バックエンド側のシステムとして、開発チームが用意したモック・アプリを用いていました。ところが、モックは実際の動きと異なるため、簡単な動作確認しかできていなかったのです。

ここまで読むと、失敗した開発事例なのではないか、と思われるかもしれません。しかし、筆者たちは目指していったのです。アジャイルな開発を実践するチームを。そして、結論から言うと、無事にリリースできたのです。

次ページでは、これらの失敗を踏まえたうえで、筆者たちがどのようにプロジェクトを成功に導いていったのかを紹介します。