レビュー用ディスプレー「トルネード・ディスプレー」

　第1回のまとめ（http://thinkit.jp/article/906/3/）で示した通り、アジャイル開発では、ドキュメントをしっかりそろえるよりも、動くソフトウエアを重視しています。品質はどこで作り込むかと言うと、ソースコードの段階で確認していくしかなく、そのためにはソースコードレビューは欠かせません。

　アジャイル開発では、よく「ペアプログラミング」という呼び方で、開発者が2人1組のペアになって1つのパソコン上で一緒に開発をすることがあります（図3-1）。1人がプログラミングをしていき、もう1人は設計の相談に乗りながら、生み出されるコードの品質を逐一チェックしていくのです。

　この狙いと効果は、ソースコードのレビューが本当に品質向上に役立つのであれば、プログラミングをするそばからコードレビューをしていくことで、究極に品質を向上させようというものでした。これは「良いことは極端にやろう」という、アジャイル開発の1つであるeXtreme Programming（XP）の思想によるものです。

　ペアプログラミングを実施していくことで、「どうやって作るか」という部分に関する品質を向上させることができます。しかし、ここでのコードレビューは、あくまで開発者同士のピアレビューになってしまうため、「何を作るか」という部分については、ペアプログラミングだけでは効果が薄いです。

　「何を作るか」という部分を確認するために、顧客やマネジャーによる「動くソフトウエア」に対するレビューをする必要があります。ただし、オープンソース開発の場合、エンドユーザーやダウンロードしてくれるユーザーが直接レビューするということはできないので、スペックリードという役割で筆者が参加して、「何を作るか」という観点でのレビューを行っています。

　コミュニティーからの要望を受け、その本質的な課題を検討した上で、SKIPのコンセプトにそって実現することと、リソース配分を見た上で、取捨選択と優先順位を判断するのがスペックリードの仕事になります。

　ペアプログラミングであれば、ディスプレー1枚で済む話ですが、スペックリードを含めたレビューの場合、3名以上になることも多く、ディスプレー1枚では共有しづらくなります。アジャイル開発の場合、ここでのレビューはドキュメントではないので、印刷して配るということもできません。レビュー対象は「動くソフトウエア」なので、実際の動きを確認する必要があります。プロジェクタを使うことも多いのですが、準備の手間もかかる上、どうしてもオペレーションは1名になってしまいます。

　そこで、筆者のチームでは「トルネード・ディスプレー」という製品を活用していました。トルネード・ディスプレーは、大型モニターにスタンドを付けて、打ち合わせ時に机の代わりに設置することのできるペーパーレス会議システムです（図3-2）。非常に効率的に「動くソフトウエア」のレビューができるようになっています。また、通常の会議においても紙の資料をなくすことができ、しかも、その場で編集してしまえることは、アジャイルに進めるプロジェクトにとって多いに助けになっていました。

ツールを活用したアジャイルの事例　まとめ

　うまく行っていないプロジェクトなどでツールを導入するとなると、過度な期待をしてしまい、ツールさえ入れればうまくいくと考えてしまうことがあると思います。しかし、ほとんどの場合そういったことはありません。ツールはあくまで人が使う道具なのです。それを忘れずに、自分たちで意識をした上で導入することで、仕事の効率はアップできます。大事なことは、自分たちの仕事の仕方を見直すことです。もし問題があると感じているならば、ツールを導入する前に、自分たちの開発スタイルを見直し、改善方法を検討した上で、その助けになるツールは何か、という観点から考えることが重要になります。

★アジャイルの価値観（その3）
「プロセスやツール」より「人と人との相互作用」を重視する。
（ツールはその限界や向き不向きを知り、うまく使うと効果絶大）

　オープンソースであるSKIPを活用したビジネスとして、筆者たちはSaaS事業を営んでいます。最終回となる次回は、オープンソースとSaaSのビジネスモデルについて、そして、クラウドコンピューティングとアジャイル開発について、紹介したいと思います。