発注者はアジャイル開発をこうみているアジャイル実践者インタビュー(1)(2/2 ページ)

» 2005年11月05日 12時00分 公開
[畑田成広, 塩田英二, 水越明哉,アジャイルプロセス協議会 ケーススタディWG]
前のページへ 1|2       

実践したプラクティス

 実際に行ったアジャイル開発のプラクティスで何を実践したのかを質問した。ここでは一部インタビュー内容をまとめながら紹介する。

・ペアプログラミング

  90分や120分といった単位を決めて成果物を作成した。ペアで行ったのはプログラミングだけではなく、ドキュメントの作成や調査なども含んでいる。筆者の経験上、ペアプログラミングは、ペアを作ったり、交代したりするタイミングをいかに計るかが難しい。このチームで行っているように、90分や120分と最初から時間を決めて作業の区切りをつけ、作業報告を行い、ペアを交代するのは良いアイデアである。

・イテレーション開発

 1週間(より正確には5日間)を1単位として開発を進めている。開発は「「ストーリ」」という単位にまとめ、そのイテレーションでどの「ストーリ」を開発するかを決める。「ストーリ」はすでに紹介した「XPカード」に手書きで書く。仕様の詳細は、発注者である猪狩氏と週2回ほどレビューを行い、そこで調整する。実物で調整を行っているため、仕様についてのドキュメントはほとんどない。ドキュメントの少なさについて、発注側に聞いてみた。

―― 「発注者側としてはドキュメントの少なさはどうですか?」

猪狩 「週に2日くらいで内容を確認しているので開発中は問題ありません。開発中は、モデルを書いても、私がいない夜の間にもうモデルが変わっているということもあるから。モデルは手書きで伝わっていればそれでよいと思います。仕様は「ストーリ」からテスト仕様に書かれ、マニュアルに記述されます。アーキテクチャは、最初は手書きのモデルでしたが、固まってきてから保守用のドキュメントを起こせば良いでしょう」

 ドキュメントの少なさはアジャイル開発でいつも話題にされるものだ。しかし、このチームのように仕様担当者が身近に質問でき、実ソフトウェアで仕様を確認することができるならば、開発中のドキュメントは確かにそれほど必要ないように思われる。

 ただし、アジャイル開発だからドキュメントが少なくてよいというわけではない。この点はアジャイル開発でよく勘違いされることである。今回の開発チームは幸いなことに仕様の擦り合わせがしやすく、設計と実装を同時にできる環境であったため、少ないドキュメントが実現できている。しかし、状況が違えば、モデル図やレビューの記録などを詳細に残す必要がある。状況によって必要なドキュメントの取捨選択をし、無駄なドキュメントはできるだけ書かないというのがアジャイル開発の考え方である。

 イテレーションの長さは、最初は2週間で進めていたが、2週間だとイテレーションごとのフィードバックに時間がかかり過ぎるため1週間にした。イテレーションの長さなど「開発の進め方」にかかわることを、柔軟に変更している。アジャイル開発の進め方がチーム内に浸透していることが感じられる。

 XPの本には、イテレーションの標準は2週間と書いてあることが多い。しかし、筆者が知っているXPの開発現場では、慣れたチームは1週間を1単位としてイテレーションを行っていることが多い。慣れるに従ってフィードバックの回数を増やす傾向になるようだ。

・テストファースト(テスト駆動開発)

 発注側は、最初から「テストファースト」と「ペアプログラミング」を要求した。製品の品質を考えたとき、この2つのプラクティスは取り入れるべきだと考えたという。実際にテストファーストを行ったことで、どのような違いがあったのか。

桑折 「後から機能を追加したとき、前のところを壊しているか壊していないかが判断できるのは思った以上にいいと思いました。バージョン管理でマージしたときにも、前に動いていたところを確認してから進める(足場を固めながら進める)のはいいと思います」

和田 「テストがそろっていて、バグもほぼなく、高い品質を保つことができたと思います」

―― 「昔のやり方とアジャイルとで比べると、違いはありますか?」

角谷 「昔のやり方では、問題があったとき、「誰のせいなのか」「どこで処理するか」という話になることが多かったです。要求エラーか実装エラーかを判断できませんでした。いまは実装のエラーはほとんどなく、考慮しない使い方とか、そういう部分がエラーになっています」

―― 「するといまの方が問題は明らかな感じですね」

角谷 「そうですね。『あーそれは考慮してないわ』『それは伝えてないからね』というような(笑)」

猪狩 「伝えたものは大体テストされます。こちらが思い込みで伝わっているというのがあったりするけれど、思い込みで伝わらないところはウォーターフォールでも伝わらないだろうし。それに自分が想定していないならそれを設計するのはできません。要求ミスはいままでとあまり変わらないかなと。イテレーションごとに議論して問題や新しい使い方を見つけ出すことができています。最初に書いて出しちゃうとレビューしたってそんなには見つけられません」

 この話の中で、大規模開発との比較が話題になった。

桑折 「以前参加したプロジェクトでは、がちがちのウォーターフォールで開発をしていたのですが、そのプロジェクトで開発したプログラムはとても品質が良く、バグはほとんどありませんでした。どういうバグのつぶし方をしていたかというと、ひたすらコードを紙に出して、赤ペンで追い、チェックするの繰り返しだったわけです。値については、デバッグでその場所で止めて(値を)確認をする。その紙を製品管理担当者に出す。すると、製品管理担当者からは「ここは駄目じゃないか?」ということが返ってくる。かなりアナログなことをやっていました。そして、一度OKになったコードは絶対に手を入れてはいけなくて、変えて使いたいときにはラップしなければいけませんでした。開発要員は全部で100人くらい。人をつぎ込めばできる、という感じで1年間進めて、最終的には品質良く仕上がりました。

 いまはそういうことを4人でやっていて、こっちもバグがなく品質が良いです。昔のプロジェクトで人数を掛けてやっていたのは1日1回の受け入れテストでした。いまのプロジェクトと比べると、コスト差はとても大きい。でも、どちらでもできるんだなという面白いところにも気付けるところがありました。品質はどちらでも保てるけれど、こっちの方がかっこいいよね(笑)とか、コストは削れるよね、とかそういうことが実感できています」

―― 「いまのやり方を50人でできると思いますか?」

桑折 「いまのやり方をどうすれば50人に広げられるか、ということを考えています。いきなり50人でやるというのは難しいですが、いくつかのチームに分け、各チームでやる形を採用すれば、もしかしたらできるかもしれない、と思っています」

―― 「具体的にどうすればやっていけそうですか?」

桑折 「最終的には徹底的に自動化していくことが必要だと、このプロジェクトに入って思いました。例えば、みんなにユニットテストを書いてもらうのはいいのだけれど、そのテストをほったらかしではなく、必ず1日に1回はすべてを実行するなど。このテストをすべて自動でできるようにしていけば、もしかしたら可能ではないかと思います。50人のテストを毎日やるというのは、何か手段を講じなければ実現はほぼ不可能です。できるだけ自動化し、毎日テストができるようにすれば、もしかしたらいけるんじゃないかと思います」

・自動化

 テストファーストの項で出てきたが、自動化というのはこのプロジェクトの1つのキーワードである。

角谷 「いろんなところを自動化しました。コンパイル、デプロイ、自動テスト。受け入れは手でやるしかないですが。最初は全部手でやっていたんだけど、少しずつツールやスクリプトで自動化していきました。ビルドプロセスにも歴史があり、私はそこに思い入れがあります。自動化する方法は何でもよいと思います。バッチファイルでもいいし、Javaクラスで作ったりもしています。後は、バージョン管理。ここに異常なこだわりがあります。リリースしたバージョンと作っているバージョンのリリース、マージ。リリースは1カ月に1回。マージもペアでやります。いまはすべてペアでやっているので、皆テストもできるし、マージもできる。これはプロジェクトにとっての大きな財産です」

―― 「自動化はコストが掛かると思うが、どこで作りますか?」

角谷 「ちょっとずつやるしかありません。大掛かりにはできない。やっている間にもそういう議題が出たことがあります」

猪狩 「お客さまを説得するのと同じで、それをやることで生産性が上がるといえるか、その情報をくれれば判断できます」

角谷 「信じてもらうチームにならないと駄目ですね」

 XPは「重複したコード」を嫌う。「重複のないコード」を目指す。コードに限ったことではなく、何度も繰り返すような重複した作業についてもいえる。このチームでは「重複した作業」を徐々に自動化していくことによって、無駄を解消していった。多くの場合、プロジェクトが進むにつれて、無駄な部分が増えていくように感じられると思うが、プロジェクトが進むにつれて無駄が減っているとは素晴らしい。

自己プロジェクト評価

 自分たちのプロジェクトをどのように評価しているか、10段階で評価してもらった。プロジェクトの良いところと悪いところを定量的な評価を含めて語ってもらった。

―― 「このプロジェクトの10段階評価は? あまり周りは気にせずに(笑)」

桑折 「7です。いままでのプロジェクトよりよくできています。疑問がある点は、スキルの低いメンバーで同じことができるかどうか。今回のメンバーのスキルは総じて高い。自分でこういうプロジェクトを興して成功すれば、10になるでしょう」

家永 「8か9。自分の資産になっているから。ほかのところでできるか、と考えると課題があると思います。要求エラーについては、もっと良いものができると感じています」

角谷 「8点かな。チームでソフトウェアを作るのはいい。ただ、スキルにギャップがあるときにどうするか、それが課題。あと、ドキュメンテーションの部分は不満足です。加えて、このチームは全体のプロジェクトの一部なので、自分たちのチームだけではなく、プロジェクト全体をうまく作れればいいと思います。メンバー間のテンションギャップもあるかな。それを考慮すると7かも(笑)」

和田 「8。プロジェクト全部をきっちり成功させないといけないと思います。プロジェクト全体を上手に進めていくやり方をもっと考えたいですね。皆ができるようになるまで待っていたいが、そうすると間に合わないかもしれません。その辺りのかじ取りで悩んだことがありました。このチームは自己最適化がもっとできるはず。プロジェクト全体の最適化もできるでしょう」

 この質問は発注者である猪狩氏にも行ってみた。

猪狩 「7。課題はドキュメントとアカウンタビリティ(説明責任)。コードの品質は高いですが、それを(社内に)どう見せていくかがいまはまだ不十分だと思いました」

―― 「その辺りはアジャイル開発でいつも問題となるところですが?」

猪狩 「ウォーターフォールと同じ形である必要はありません。社内を説得できればいいと思います(ウォーターフォールのまねではなく)。どういう情報をそろえれば説得できるかを考えています。アジャイル開発なりのものが作れるとよいといつも思っているのですが……」

メッセージ

 本インタビューは、アジャイル開発の導入の手掛かりになることを目的として行った。そこで、最後にインタビューした皆さんからアジャイル開発に興味がある人たちに向けてメッセージをもらった。

和田 「楽しいからやってみれば、と思います。とにかくやってみて、自分で考えること」

家永 「社内のプロジェクトでいきなり導入することはできないかもしれないけれど、既存の開発プロジェクトで、困ったときに、アジャイル的な開発スタイルの必要性を聞いてみたり、現状の問題を共有したり、そういうところから始めるのがいいのでは。やるぞ、と肩ひじ張るよりも、身近なところからやるのがいいと思います」

桑折 「アジャイル開発手法を採用しているプロジェクトに参加してみないと実感できないと思います。もし、(アジャイル開発を)やりたいのなら、会社の中でその旨をアピールし、プロジェクトに参加できるようにしておくことでしょうね」

角谷 「(アジャイル開発のプラクティスは)ちょっとずつやった方がいいです。まず、自分がちょっとずつ実践する。そして、だんだんアジャイルになっていった方がいいなあ、というふうにチームの雰囲気を誘導する。実践してみて、その後、実際に実践している人の話を聞くようにしてほしい。自分でやらないで話を聞いてもいいフィードバックを得るのは難しいです。「単体テストってどうですか?」って聞かれても、答えようがない。自分でやってみて「こういうテストが書けないんですけど、どうすればいいですか?」と質問すべきです。

 もう1つ、アジャイルをアジャイルしなきゃいけない。アジャイルはこうだよね、というのを探しながらアジャイルをしなければいけません」

猪狩 「まずは、ペアプログラミングを体験してほしい、と思います。ペアプログラミングを嫌う人もいます。自分の技術がばればれになっちゃうから。でも、プロジェクトを成功させるには、その辺がオープンになった方がいいです。新しい知識も入ってくる。コードレビューだけでは、もし致命的なバグが見つかっても、アーキテクチャやロジックを変えることは不可能です。しかし、ペアプログラミングなら書いている最中にバグが判明するので、それができます。ウォーターフォールでペアプログラミングを実践しても問題はありません」

アジャイル開発のメリットは発注者にもある

 往々にして、アジャイル開発のメリットは、開発者側の視点で語られることが多い。しかし、発注者側の話を聞くと、(発注者側にも)大きなメリットがあることが分かる。発注者と開発者がうまく協力できれば、とてもスムーズに開発作業を進められるのだと感じた。発注者側にアジャイル開発のメリットを浸透させることができれば、いまよりもアジャイル開発を実践しやすい環境を作ることができる。今後、アジャイル開発を実践していくには、開発側の視点だけではなく、発注側の目線でもアジャイル開発の有効性を訴えていくことが重要なのだと感じた。

前のページへ 1|2       

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ