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

[畑田成広, 塩田英二, 水越明哉，アジャイルプロセス協議会 ケーススタディWG]

うまく実践できなかったプラクティス

　実践したかったが、うまくできなかったプラクティスも聞いてみた。今回はうまくできなかったという結果だが、アジャイル開発においてはプラクティスにこだわらず、問題がありそうな場合はあえて実践しないことも重要なことである。

ペアプログラミング

　最初の段階では全員にペアプログラミングを導入していたが、ペアプログラミングの効果が発揮できない部分が見えてきたので一部を除いて解消してしまった。

中井　「例えば、Javaがやっと書けるレベルというコンビをペアにします。そうすると、タスクがあってやってみましょうとなったときに、実際に2人ともスキルが低いので話し合っても一緒に止まってしまいます。調べようとしても、2人ともスキルがあまりないので調べることもできず、2人そろって停滞して全然進まないという状態になってしまいます。

　そうなると困るので、例えばHTMLを作るとか、バリデーションを付けるとか、やさしくて簡単な仕事をそれぞれに与えます。2人でやるほどの作業ではないので、ペアにはしません」

　ペアプログラミングの教育的効果についても話題になった。

竹内　「最終的にスキルがすごく伸びたのは、ペアプロをちゃんとうまく活用できたメンバーですね。本当に、それはそう感じていますね、いまも。1人でいま任せられるのは、ペアプロをちゃんとうまくやってきた人だったと思います」

YAGNI

　YAGNI（You Aren't Gonna Need It：必要にならない）とは、できるだけシンプルな設計を進めるXPのキーワードである。

倉貫　「あと、プラクティスでできなかったのは、YAGNIですね。それはきっと要らないから、とシンプルに業務の方も考えればよかったのですけど。うちのチームのメンバーはもともとウォーターフォール出身ですし、最初から全部がっちり決めてしまおうという意識があって、おそらく余計なところの仕様についても、決めちゃったし、入れちゃったんだと思います。もうちょっとシンプルに最初は作っていって、そこから広げていくというスタイルをやっていった方が良かったかな、という気はしますね」

――　「YAGNIを実現するためには、どう考えていけばできそうですか？」

倉貫　「その機能については3カ月後にやる、と計画を最初から立てていれば、多分参画しているメンバーも安心して、ここまで決めるのが今回のところだろうっていう切り分けができますよね」

――　「なるほど。でも、なんかRUPっぽくなりませんか（笑）」

倉貫　「だんだん、そこに近づいているかもしれませんね（笑）」

　ペアプログラミングに関してはスキルの問題を把握して勇気を持って実践をやめ、YAGNIに関しては実践ができなかったが次に実現する案を持っている。ここでもプロセスの洗練の一端を見て取ることができると思う。

契約に関して

　現在一般的な要求を決めて金額・期間をコミットするという契約は、開発中にでも要求を変更していくアジャイル開発との相性があまり良くない。今回のプロジェクトの契約に関しても聞いてみた。

――　「今回の契約形態は？」

倉貫　「契約形態は、通常どおりです。見積もりをしていなかったかというと、していました。お客さんのRFPというのは当然あって、コンペもあって、うちの会社を選んでいただいたということですので、金額も決めてあったし、期間もコミットして契約しました」

――　「アジャイルは開発側のやり方であって、契約的にはアジャイルにしなくてもできるということですか？」

倉貫　「契約としてアジャイルにできればベストなのですけど、そのためにはベンダ側とお客さまのシステム部がアジャイルなら成り立つわけではなくて、お客さまのシステム部にお金を出しているスポンサー、つまりオーナー自身がそういうコミットをしないといけない。それは難しいので、いま日本でやるためには一括契約が現実解かなと思います」

　アジャイル開発の契約については、顧客企業の経営層のコミットを得ることが難しいので従来どおりの一括契約が現実的であるということである。今後、このインタビューにおいても契約の問題や、顧客企業の経営層の考えなども聞いていきたいと考えている。

自己プロジェクト評価

　自分たちのプロジェクトをどのように評価しているか、10段階で評価してもらった。

――　「このプロジェクトの10段階評価は？ あまり顔色をうかがわずに（笑）」

中井　「6点くらい。まず、システムにおけるメインフローやキモになる部分を後半に作成してしまった。また、うまく自分たちなりの開発の決まり事を自分たちで決めて守ろうというスタイルがうまくできなかった」

吉尾　「6点くらい。根幹みたいな部分ではなく、枝葉の部分から作ってしまったので、イテレーションごとの修正コストが増大してしまった。例えば、正常系から先に決めて、異常形については段階的にやりましょう、という形でうまく進めていければもう少し負荷も下がったはず」

竹内　「7.5点くらい。確かに問題はあったのですけれども、初めてのメンバーで、初めてプロジェクトをやって、結構若手中心でしたので、それにしては結構うまくいったと思っています。個人的には、初めてアジャイルの実際のプロジェクトをやりましたけれども、そんなに懸け離れた考え方ではないな、と思いましたね」

倉貫　「プロジェクトリーダーという立場から見た場合、5点かな。マネジメントから見て、若手の成長してくれた部分とか、経験できたことは非常に良かった。ただ、逆に、若手中心のメンバーにしてしまったのは、やっぱりマネジメント上の問題だった。ラインの上司として見たとき8点。スペックホルダを使ってみるとか、Springを使ってみるとか、チャレンジをしたということについては非常に効果があったし、成果が上げられている」

メッセージ

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

中井　「勇気です。経験者もやったことのない人に対しても勇気です。委縮すると良い結果が出ないので、勇気を持って前に出て行くことですね」

竹内　「勝算です。勝算を持って対応しないといけないかなと思っています。よく分からないけど取りあえずアジャイル、要件が決まっていないからアジャイル、とやっても絶対うまくいかない。今回のプロジェクトでは自分たちで独自のプロセスを立て、ちゃんとプロセスを考えていけるだろうという勝算を得た。また、パイロットとしてプロジェクト内でアーキテクチャを事前に組んでみたことも勝算の1つだ」

吉尾　「できるところから少しずつ。アジャイルとかXPとかの記事を見てて感じるのが、二元論的なことを語っているのが多い。アジャイルなのか、そうでないのかといった。だが、パラダイムの変換とはいっても、ある程度の連続性といったものを持たせたいなと思う。XPでやろう、枠組みはこうだというように最初はそんなに意識しなくて、プロジェクトに紛れ込ませるような形でやって、十分それが潤滑油になっていくのではないか。とっかかりとして一番良さそうなのはテストファーストだと思う」

倉貫　「チャレンジする機会があれば、ぜひチャレンジしてほしい。ただし、自転車を乗れるようになるには、何度か転ばないと乗れるようにならない。サイクルの回し方やペダルの踏み方をどれだけ勉強しても、自転車に乗れるようにはならないと思います。これから実践される方は、転ぶというか、自転車に乗ってみることをやらないと、うまくは乗れないと思います。ただ、いきなり社運をかけた大きなプロジェクトでアジャイルだとかではなく、自分たちの担保できるプロジェクトからやっていかないといけない」

アジャイル開発は洗練の繰り返し

　アジャイル開発という言葉はここ数年で広まり、書籍などで学んで実践する方も多いだろう。しかし、規定されたプラクティスをただ実践するだけではアジャイル開発ではうまくいかない。初めはXPなどのプロセスをまねするところから始めても、自らのプロジェクトになじまないプラクティスは改善し、必要であれば新しいプラクティスを開発する。このようなプロセスの洗練のサイクルこそがアジャイル開発を成功させるためには必要であると強く感じた。

「アジャイル実践者インタビュー」バックナンバー

• オフショアでアジャイル開発の実際
• アジャイル開発におけるプロセスの洗練
• 発注者はアジャイル開発をこうみている