少人数によるアジャイル開発の事例

少人数でのアジャイル開発の実践と工夫

　筆者ともう1名だけの体制で、しかも、作るべきものが確定していない中で、アジャイル開発以外の選択肢はなかったというのが正直なところです。このように少人数で、かつ、ゴールを探りながら進める開発に、詳細な工程表やガントチャートをあらかじめ作って、その計画通りに進めるということは不可能でしょう。期限とゴールの成果物イメージが決まっているだけで、それ以外は探りながら進めざるを得ません。

　これは、一般的な「要件定義」も同様のはずです。私たちがアジャイル開発をした点というのは、そのフェーズの成果物を、ドキュメントという形にせずに、実際に動くアプリケーションにしてしまった点に尽きます。

　開発者2名の間でもまだ、これから作ろうとしているものが明確にわかった状態ではなかったので、通常ならばイメージ図を描くなどをして認識合わせをしていき、最終的にはわかりやすいドキュメントに落とし込むかというところでしょうが、私たちの場合、さらに一歩進めて、ホワイトボードで少しずつ認識を合わせたらすぐにプログラミングを行い、実際の動きで確認しあいました。そのため、作っては直しての繰り返しを、2～3時間に1度くらいの非常に短い間隔でまわしていました。それは、アジャイル開発におけるイテレーションでの繰り返しを究極に短い単位にしたものでした。

　動くアプリケーションを確認しながら進めていき、求めるものと違っている場合は、その場で直していきます。2人ですので、特に会議室などで確認作業を行う訳ではなく、常に隣の席にいて、確認したいタイミングで声をかけて、そのまま一緒にプログラミングをしていく訳です。この作業は「ペアプログラミング」とXPなどでは呼ばれていますが、このプロジェクトでは当たり前の状態でした。

　このフェーズは、要件を探りながらアプリケーションにしていく段階であり、同時に、新しい技術を習得する段階でもありました。まだ2005年当時は、Ruby on Railsの日本語の書籍や情報も少なく、その中で試行錯誤をしながら学習していきました。この際にも、2人でコミュニケーションをとりながら動くアプリケーションを作っていたことが、効果を発揮しました。どうしても情報収集や頭だけで理解しようとしても、新しい技術はなかなか身に付くものではありませんが、実際に動くアプリケーションで試しながら作っていったことで、より早く身に付けることができたと思います。

　Ruby on Railsは、この段階のアジャイル開発をしていく上で、非常に効果を発揮しました。「巧遅より拙速」という言葉がありますが、実際の動きを作りながら試してみながら進めていく際には、コンパイルやビルドが不要だったり、サーバーの再起動をしないでも画面を少しずつ直しながら確認できるなどといった点が、欲しいものを探求しながら作り上げるフェーズには非常にマッチしました。

少人数でのアジャイル開発のまとめ

　ここでの開発は、2人での開発という本当にチームとしては最小単位の人数だったので、ツールというツールは、一切使いませんでした。メールさえも使っていませんでした。ホワイトボードなどのアナログなものは活用しましたが、それでもホワイトボードくらいで、それ以外は使わずにすませました。情報の共有はほとんどが口頭で行われていましたし、それがもっとも速い情報の伝達手段でもありました。このように、人数によってはツールを使わないという選択肢もあるということです。

　大事なのは「ビジョンとコンセプトの共有」という点です。具体的な作るもののイメージは口頭で合わせていきますが、どうしても伝えきれない部分も出てきます。その際に、ビジョンという点と、コンセプトという点の2つが事前に共有されていることで、迷う場面での判断がそろうようになります。

・ビジョン＝このソフトウエアを使うことで、使う人たちはどうなってほしいか
・コンセプト＝このソフトウエアを作る際に、どの部分に価値をおいて作るのか

　このようにビジョンとコンセプトをチームで共有することは少人数のプロジェクトに限らず、人と人のコミュニケーションで動くアプリケーションを早めに作っていくアジャイル開発において重要なポイントになってきます。

★アジャイルの価値観（その1）
　「包括的なドキュメント」よりも「動くソフトウエア」を重視する
　（そのために「ビジョンとコンセプトの共有」を実施すべし）

　次回は、SKIPを社内にリリースして、社内のユーザーからのフィードバックを得ながら開発を進めた段階で、より人数が多くなった体制でのアジャイル開発について紹介する予定です。