――反復型開発プロセスを導入することでどのような効果があったのでしょうか？

松岡　残念ながら数字で示すことはできないのですが、最終リリース時に大きな変更はほとんどなくなりました。つまり、お客さまがあきらめてもらえないような変更要請というのはほとんどなくなったということです。そういう意味では非常に効果がありました。

　以前は、最終リリース時に、重要な要件の漏れを確認したということがありました。お客さまは「聞いてくれなかったから言わなかった」とおっしゃるケースもあるんです。とはいえ「最初の要件定義書には記載されていないので、できません」とは言えないですし。

反復型プロセス導入に必要な取り組み（3つまでの複数回答 n=486） 出展：「＠IT Development Style読者調査」2002年11月

巻山　機能レベルまで落とし込んだユースケースをお客さまと一緒に作成していく過程で、要件の漏れがなくなっていきます。またこちらのスタッフもお客さまのビジネスの流れを把握できるようになります。私自身、仕様を決める段階で漏れがないように徹底的に決めますね。

　ただ、いくら反復型開発でも修正できる範囲は限られるものです。例えば、1週間単位のイテレーション期間で実装からテストをする場合、時間はあくまで1週間しかないわけですし、絶対的な作業量も決まっています。必ず柔軟に対応できるというような都合のいいものではないと思うので、できる限り要件定義の段階で決めます。

オブザーバ　堂山真一氏

井上　見積りのリスクをいかになくすかが課題でしたね。リスクをできるだけ検知して削減するためにRUPの導入を決めたといってもいいかもしれません。プロトタイプを作成し、検証し、ミスを修正し、実際の開発へ進んでいくという作業プロセスを採用した結果、必要以上のリスクを回避できたと思っています。

余田　まったく新しいアーキテクチャを構築するプロジェクトに参加したことがあります。アーキテクチャを固めるときにユースケースを利用し、反復を繰り返しました。その際、「このアーキテクチャはいける」という確信を得ることができたのです。もし、あのプロジェクトがウォーターフォールだったら、すべてが終わった時点で動かない、というケースも考えらます。アーキテクチャを最初の段階で確立できる、というのは大きな利点ですね。

松岡　私はかつてEJBで開発をし、実用に耐えるパフォーマンスが得られなくてお客さまに叱られ、それで直して、ということを繰り返して、結局は自前のアーキテクチャを採用したという経緯があるのですが、これも反復型でなければ、最後になってやはり駄目だった、ということが分かるという事態になっていました。

堂山　リスク管理という意味では人がとても重要だと私は考えています。反復型の場合、スタッフがどこまで理解しているのか、小さなスコープの段階で分かる場合が多いのですが、ウォーターフォールだと最後になって、やっぱりわかっていなかった、ということが判明したりします。

――Development Styleのアンケートによると、反復型プロセス導入に必要な要素は何かという質問で多く挙げられたのは、チーム全員が学習する機会を設ける、という意見でした。みなさんはどのようにチームのスキルの底上げを行っていますか。あるいは今後どのような学習方法が考えられるのでしょうか。

松岡　チーム全員を対象とするなら、私は少なくともユースケースとオブジェクト指向の2つだけは学ばせます。ユースケースを基に設計とコーディングを進めることを徹底させるのですが、これは経験しながら学ぶしかありません。本を読んだり、講習会を開いても、やはり実際のプロジェクトでユースケースを書きながら学ばないことには使えるものにはなりません。ただ、社内にはメンター（指導者）となれる人材は多くありません。複数のプロジェクトをかけもちしながら、というのが現状です。

オブザーバ　渡辺隆氏

A　若い人はすんなり吸収していくと思います。ではある程度の開発経験を積んだ人をどう教育するのか？ 結局、実践で知ってもらうしかないので、うまくいきそうなプロジェクトに参加してもらい、実践経験を積んでもらうのがいちばんいいのではないでしょうか。そこにはメンター的な人間もいると思いますし。

杉若　切羽詰った状況ではメンター的スタッフを中心に開発しながら学んでもらうしかないわけですが、本来はプロジェクト開始前に基礎体力をつけておくべきです。講師を派遣してもらって講習を受ける方法もありますが、スタッフ全員が例えば5日間講習に専念するというのは現実困難で、その補完策としてWBT（Web Based Training）を活用しています。3カ月間いつでも受講できるので、プロジェクト開始直前や、プロジェクトの途中からでも役立ちます。

堂山　弊社では年度内に数百人単位のWBT受講を目指しています。これだけの人数となると集合研修スタイルでは対応できません。

　実際にRUP適用プロジェクトを経験したスタッフが、「WBTを受けて目から鱗（うろこ）が落ちた」と言っていました。ある意味、教育もイテレーションなのかな、と思いました。

巻山　自分で意欲を出すというのはとても重要だと思いますね。優秀な人は放っておいても勉強しますから。だから優秀な人ほど残業をさせてはいけないんですよ。時間外に勉強を怠らない人材は、将来的に会社にメリットをもたらします。それを残業で縛るのはまったく逆効果ですよ。

余田　動機付けとして、新しいことを吸収し、それをプロジェクトに適用して成功したことのある人は、モチベーションが持続するでしょうね。勉強方法はいろいろあると思いますが、基礎レベルを上げる方法の1つとしてWBTは有効でした。

――それでは、最後にこれから反復型開発プロセスの導入を検討している読者の方々にアドバイスをお願いします。

松岡　導入についてはやはりトップダウンが圧倒的に望ましいですね。そうでない場合、対外的、対内的にもさまざまな障害に遭いますので。また、実際さまざまな障害に合われている方には、反復型開発プロセスが現実に則していないとは思って欲しくないですね。ゆくゆくは、全社的に行きわたると思って欲しい。地道に頑張って欲しい。

井上　現在進行しているプロジェクトに何が足りないかを明確にし、ターゲットを絞って、問題を終息させることができるプロセスを選ぶべきです。ちなみに私はリスクドリブンにひかれて、RUPを選択しました。

A　アプリケーション開発の最中には、必ずトラブルに遭遇すると思います。そのときに、1人で考えていても行き詰まるだけなので、共通の悩みを持つ人を見つけて相談し、共に解決策を見つける努力をした方がいいと思います。

余田　開発プロセスはいま、一種の流行語になっていますが、流行に流されて導入するならばやめたほうがいいと思います。改善しようという問題意識を常に持ち、さまざまなことを勉強し、RUPならRUPのエッセンスを見極めて実践してみる。その繰り返しが重要だと考えています。

杉若　まずRUPに過度の期待を持つのは失敗の原因だと思います。RUPを魔法か何かと勘違いして、適用すればすべての問題が自動的に解決する、と思っている人がいます。それで失敗するとRUPが悪いというパターンです。RUPはあくまでツールとして使いこなして欲しい。プロジェクトとして目標を設定し、必要な部分をカスタマイズしながらステップ・バイ・ステップで適用していけば、きっとうまくいきます。

巻山　さまざまなプロジェクトを経験することが重要だと考えています。そこで必ず、反省が生まれます。その反省を、次のプロジェクトに活かすことで、だんだんよくなっていくのではないででしょうか。

――本日みなさんのお話をお伺いして、改めてソフトウェア開発におけるプロセス革新の必要性を認識しました。現在は“RUPなどの反復型プロセスを導入したいが、周囲の説得も難しく、自分1人ではどうすることもできない”と悩んでいるエンジニアが多いようですが、さまざまな創意工夫で道を切り開いているみなさんの姿は、きっとそうした人たちの励みになることと思います。われわれも今回の座談会でお伺いできた貴重なご意見をもとに、開発プロセス革新を一歩でも進めるための情報やソリューション提供に努力させていただきます。長時間にわたり本当にありがとうございました。

Development Style Initialsponsorコーナー