アジャイル開発におけるプロセスの洗練アジャイル実践者インタビュー(2)(2/3 ページ)

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

吉尾 「例えば、イテレーション1で私が仕様確認をしていました。イテレーション2で開発チームに戻ってやっています。イテレーション3でまた業務チームに戻って仕様確認しました。そうすると結構様相が変わっていたりとかするのですね。別の人がイテレーション2で仕様を詰めた人と私のところで仕様上の矛盾が発生していたりだとか。その辺の情報がうまく伝達されていなくて。お客さんとしては会社は1つなので、伝わっているだろうという形でそういう前提で話をするのですよね。その辺りの情報の齟齬というのがときどき発生したということがありました」

竹内 「まずかったのは、全員毎回総入れ替えしたところですね。計画ではちょっとずつ、3名体制だったので1名抜いて、入れ替えるという形でやるつもりだったのですけど、それが諸事情でできなかったのですね。そこはやっぱり死守する必要があったのかなあと思っています。あと、私以外にも1人、ずっと業務チームにいるような人、仕様について責任を持つ人がいてもよかったのかなあと思います」

 既存の顧客プロキシというプラクティスを実践してみて、問題があれば新しいスペックホルダというプラクティスを開発・実践する。さらにそのプラクティスについても問題点を見つけたら改善するというサイクルが見られる。

テスト駆動開発

 テスト駆動開発とは、まずテストコードを書きそのテストコードが通るように実装するという開発手法であり、XPのプラクティスである。機能追加を行ったときにいままでの実装部分を壊しているかどうかテストコードにより発見できるなどといった利点がある。テスト駆動開発はプロジェクトの初めから実践していた。

中井 「テスト駆動開発を主体でいきました。また、コミットするときテストを含めてビルドマシーンで流して通っていたら実際に入れるようにし、1日1回はデイリービルドをして必ずテストを通して動きを確認したりもしていました」

―― 「テスト駆動開発は初めから順調に動きましたか?」

中井 「最初のうちはいろいろと問題がありました。テスト駆動開発をやったことがない人は最初やはり結構苦しむみたいです。経験がある人でも、「テスト書くと遅くなっちゃうから書かなくても良いですか?」といってきたり。まず何でテストが必要かを説明するところから入っていきました。ビルドマシーンを用意してもテストが通らない状態でコミットされてしまったり(笑)、その都度説明していました」

―― 後半は流れていましたか?

中井 「後半は、イテレーション2が終わったくらいでだいぶ浸透しまして、基本的にテストは必ず通るという状態になっていました。テストを書くっていうのが苦手、という人はまだやっぱりいました」

 テスト駆動開発における問題点についても聞いてみた。

ALT 図3 テスト駆動開発の問題点

―― 「テスト駆動開発でやると後半テストが増えてきて仕様変更するとテストも大量に変更しなくてはならない、そういうことはありますか?」

中井 「そうですね、1機能1機能に関してはそんなに影響は出ないのですが、それをくっつけたときですね。流れみたいなテスト、ワークフローとかシナリオとか、そこら辺が影響してくるっていうのがあります。やはりその辺をいかにうまく影響がないようにするには、という課題があります。また、テストの量が非常に増えてビルドをするのに時間がかかってしまうという問題もあります。今回、かなりの数のテストができまして、大きいのから小さいのまで入れると、1000個近くいったのかな。これも今後の課題ですね」

倉貫 「テストコードをリファクタリングって、いままであまりフォーカスは当てられていなかったですけれど、やはりやらないと駄目かなと感じましたね」

一緒に概念モデリング

 顧客との仕様確認の方法にもアジャイルな方法を工夫して実践した。

竹内 「業務チームの話であればお客さんとの仕様確認の仕方を、ちょっと工夫しましたね。あんまり紙ばかり持っていってもしょうがないので、基本的には設計書はほとんど作らなかった。動くものがあればイメージできるだろうということでHTMLのイメージを作成しました。後はユースケースシナリオを書いて、そのシナリオ、画面のスナップショット、HTMLをお客さんと見ながら実際に確認しました。あと、概念モデルを作成して清書して持っていくと「何だこれは」という話になるので、ホワイトボードで一緒に概念モデルを書きました。これはかなり効果的で、お客さんも途中から自分で書き出していましたから」

倉貫 「われわれがきれいにきっちり書いて、もうバッチリだというモデルを持っていくと、向こうは、量が多いしいきなりこんな難しいもの見せられても分からないと思います。われわれの思考プロセスを、ホワイトボードでじかに見せていくとお客さんもそれについていけます。いままでのモデリングには時間という概念がないので、作り方、作っている最中を見せるというのは、知識の共有という面でこれから非常に重要だなと思いました」

 概念モデリングを顧客と一緒に行うというプラクティスは、顧客の合意を得るためや要求を正確に聞き出すため、また開発者が独り善がりなモデリングを行わないためにも、非常に有効な手段となり得る可能性を秘めている。アジャイル開発にとどまらず、今後注目すべきモデリング手法といえるだろう。

その場で議事録/初めに議事録

 顧客との打ち合わせの議事録は、その場で画面に出してその場で合意する(「その場で議事録」)という形を取った。また、バリエーションとして「初めに議事録」というプラクティスも一部実践していた。

竹内 「会議が始まる前に議事録書いちゃうんです。なんかやばそうな会議だってあるじゃないですか、まとまらなそうなものって。そのときに「こう落としたい、こういうふうに議事録に落ちたら良いなあ」っていうのを書いてしまいます。それをお客さんに出すか出さないかは場合によるのですけれども、それで結構、うまくいったという場合があります。ただ、事前準備がかなり要るのでここぞというときに使っていました」

会議室を占有

 このプロジェクトでは会議室を1つ占有して自由に使っていた。これはチームのモチベーションを高めるのに一役買ったようである。

倉貫 「人数が増えてきたときに机が当然足りないということで、会議室が1フロアに4部屋あるのですけど、その会議室の1つを占有させていただいてわれわれのプロジェクトだけが使えるようにして、そこにメンバーを入れて自由にさせていました。そこだと、壁とかにいろいろ張っても、会社から文句いわれないんで(笑)。帰るときは鍵だけ閉めて帰ってね、って話で。

 やらせてみると、彼ら(吉尾)のチームだったら、進捗(しんちょく)率を壁に張り出したりとか、スケジュール表みたいなものを壁一面に張り出して、この日に、これをする……みたいな、ね。焼き肉を食べに行く、なんてプライベートなことも書いてあったりして(笑)」

吉尾 「そういう仕事をしていなくても、「焼き肉!」とかって入れておくとそれを励みにして頑張るという、副次的な効果も得られるので、それは良いですね」

竹内 「そんなに楽じゃなかったですけど、なぜかメンバーはモチベーション高かったですね。そういうのがあったのかもしれない(笑)」

吉尾 「焼き肉は、割と良かったと思いますよ。モチベーションを高められたし」

倉貫 「まぁ、若いメンバーが多かったのですけど、割と仲も良かったですね。プロジェクトが終わっているのに、ゴールデンウイークに一緒に遊びに行った、なんて話を聞いたり。そんなに仲良かったの? って後でこう、私が驚いたりして(笑)」

―― 「前回のインタビュー(第1回連載分のインタビューのこと)では、プライベートでは遊びに行かないといっていたのですが、なかなかやっぱり違うんですね」

 これらの実践プラクティスは、プロジェクトのメンバーが実際に試してみて効果を認めたもの、あるいは日々の作業を改善していった結果に名前を付けたものである。アジャイル開発では定められたプラクティスを守れば良いというわけではなく、開発者自身が問題を見つけて改善することが求められている。このプロジェクトのようにプロセスを洗練していくことがアジャイル開発には必要である。

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ