――昨年、＠IT Development Styleで現場の開発者にアンケートを行いました。そこで、現在の開発プロジェクトが抱える問題点を聞いたところ、「短納期開発への対応」とする回答が多く挙げられました。そのほか、「要求の変化や仕様変更への柔軟な対応」や「予算、見積り管理」を挙げる回答者も見られました。みなさんが携わっていらっしゃる開発プロジェクトにはどのような問題があるのでしょうか？

松岡優二氏

松岡　要件定義は大きな問題の1つです。私はそもそも要件というのはすぐには決まらないものだと思っています。当初予定した納期に間に合わないのは、要件定義がずれ込んで、設計、テストする時間がなくなるからですよね。私はプロジェクトの最初に要件をしっかりと定義するという作業を重視していたのですが、どうも根本的にそういう考えは間違っているのではないか、と思い始めました。要件というのは顧客にインタビューを繰り返す過程の中で成熟していくものかもしれません。とすると、既存の開発プロセスでは対応しきれないという結論に到達しました。

A　顧客側が要件をまとめて提出する作業に慣れていない、というケースも多々あるでしょうね。例えば、コストに対してどこまで要件が受け入れられるか、あるいはどこまで要件を出せばいいのか、という区切りをつけるのはとても難しい。（そういうお客さまのためにも）短い期間を区切り、少しずつ形にしていきながら、ある程度の形になった段階で最初のリリースをして、その後、さらに要件を吸収するという体制を作っておくのが重要ではないかと考えています。確かにそう考えたとき、既存の開発プロセスでは対応できないんです。

井上進氏

井上　（顧客の）要求の変化を管理するというのは確かに必要な課題ですが、（開発側の）多くは、では現実的にはどうすればいいか？ というところでつまずいてしまうことが多いと思いますよ。

余田　そうですね。重要なのはイテレーション*1を繰り返し、要件をきちんと吸収しながら、着実に仕上げていくというしっかりとした手順だと思います。そういうプロセスがないと、オブジェクト指向開発といっても効果は期待できない。つまり、オブジェクト指向開発に則した開発プロセスを社内に確立することがともかく重要でしょうね。NTTコムウェアでは、Rational Unified Process（RUP）を採用していますが、もちろんそのままで使えるわけではありません。カスタマイズをしながら少しずつ社内の標準作業として確立しようと努力している段階です。
*1 イテレーション：反復型開発における繰り返しの1単位のこと

――オブジェクト指向開発を適用するなら、作業手順もきっちりと確立する必要があるわけですね。顧客側から、オブジェクト指向開発でやってくれ、という要望はあるんですか？

余田憲彦氏

杉若　お客さまのビジネスの速度に合わせることを考えると、既存の開発プロセスでは対応できないのが現状なんですね。ハードウェアの問題だけをみても、かつてはメインフレームが主流で、一度開発をしてしまえば、急激に変更することはほとんどなかった。しかし、いまでは5年もすればハードウェアも陳腐化し、それによってシステムも時代の流れに合わなくなってしまう。ウォーターフォール型の開発プロセスだけではどうしても対応できないんです。そういう背景があると思います。

巻山　スケジュールを決めて、見積りが確定した段階では「これでいけるのではないか」と思うのですが、いつもずるずると後に延びてしまう。当初は、スケジュールや見積りが間違っていたのではないか、と思っていましたが、どうも問題は要件定義にあるようだと気付いたのです。スケジュールや見積りが予定通りにいかないのは、要求定義が甘いからだ、と。みなさんとは違う意見ですが私は、要件定義は最初に決めなければいけないと思います。そうしないと、スケジュールも見積りも確定できないからです。

A　さまざまなプロジェクトが並行して走る場合、そのすべてのプロジェクトを統括する地位にある上司は要件定義のドキュメントを必要とするんですね。で、その際、多様な開発プロセスがプロジェクトごとに採用されていると彼らは管理しきれないのです。だったら、開発プロセスは1つの方がいいのではないか？ そういう背景もあり、弊社でのRUP導入の経緯はトップダウンでした。

井上　製品を開発するにあたって、品質は繰り返し検証しなければいけないという企業のポリシーがあります。そういう意味で、反復型の開発プロセス導入に対しては、お客さまの理解がありましたね。日本ラショナルソフトウェアの教育コースを一緒に受けたり、意識は私たちと同じでした。製品のリリース時ではなく、検証のタイミングで見ることができるということに対しても好意的でした。

松岡　弊社は残念ながらみなさんとは違います。そもそも従来の開発プロセスうんぬんというよりも、開発プロセスという存在そのものをあまり意識していなかったですね。もちろん、基本設計、要件定義、詳細設計、コーディング、テストという大まかな作業の流れはありますが。そういう中で、私は社内に対して、とにかくプロセスというものが必要なんだと説いてまわりました。

　お客さまに対しては、反復開発の必要性を説きました。反復開発を採用すると、従来とはドキュメントの提出タイミングが異なります。形式も違ってきます。ドキュメントは従来の機能概要書ではなく、ユースケースで書かれているわけですから。まずはそこが最大の難関ですね。

　結果的にはトップダウンではなく、チームのボトムアップから徐々に、という感じでした。ただ、あるプロジェクトチームが独立して反復開発を導入しても意味はないわけで、全社的な取り組みは絶対に必要だと痛感しています。

巻山展輝氏

巻山　弊社には変化を拒む層がかなりいまして。まずは、そのような層に対し、かつての成功体験を崩してまでも反復開発を導入しなければならない理由を説明しまければなりませんでした。

　いちばん効果があったのは、（反復開発プロセスを）実行した後で、結果を示したことです。工数の削減、コストの削減といったデータを示して説明すると納得してくれる上司もいました。つまり、一人一人の開発者が割く工数を見積り、実際の作業と照らし合わせながら検証していきました。実際にはスケジュールに遅れが出たのですが、全体としてみればほぼ見積り通りという結果になりました。

　また品質に関しても、反復開発のためお客さまに見せる機会が多く、逐次改良することができました。特にユーザーインターフェイスについて、変更要求が多かったのですが、今までよりも柔軟に対応できたのです。

松岡　たまたまやりやすくていいプロジェクトに当たったのではないか？ という批判、反論が出ることがありますよね。プロセスがよかったのではなく……、プロジェクトがよかったのだろう、と。そういうときに私がよく言うのは「私は9時に会社に来て、6時に帰ることができます。それは私が暇なのではなく、私がこういうやり方（反復型の開発）をしているからです」と。

巻山　長い時間仕事をすることが、よく働くという評価の仕方、考えはいまだに根強いものがあります。ただ、成功事例を2つ、3つと積み重ねていくと、まわりでも採用しようという動きが出てきますよ。

　ちなみに、私はユースケースドリブンで開発を進めていまして、要件定義からすべてユースケースで表記しています。当然、お客さまには、「今回のプロジェクトは、こういうプロセスを採用して、こういう図（ユースケース）を使用しますよ」という説明はします。その際、専門用語を使った説明はしませんね。お客さまは、最初は戸惑っていても、使っていくうちに自然と慣れていきますね。ユースケースはシナリオ形式なので、読みやすく、修正もお客さまの前で行えるのが評価されるようになります。

松岡　ユースケースシナリオは、コーディングしている最中でも役に立ちますよね。少なくともアプリケーション・ドメインを理解している方であれば、ユースケースを理解することは問題になりません。ユースケースは反復プロセス導入の核になると思いますよ。まずはユースケースから始めるのが最もよいのではないかと思います。

　ただ、ユースケースというのは基本的にはオブジェクト指向とは関係なく存在しているものです。要件定義の作業としては、ユースケースの中からクラスやオブジェクトを見つけていくわけですが、私は概念レベルのクラス、仕様レベルのクラス、実装のレベルのクラスというように、3レベルの要件定義を固めていきます。仕様レベルの記述はかなり複雑で難しいのですが、概念レベルの記述なら（ユースケースをほとんど知らない）お客さまでも十分理解できるわけです。つまり、概念レベルと仕様レベルのクラスを合わせて、お客さまにレビューしてもらうということで初期の要件定義を行っていきます。

　ユースケースだけ作っていくと、だんだんユースケースが細分化されていき、わけがわからなくなってしまうんですね。それを防ぐためには並行して、概念レベルのクラス図を書いておくのが必要だと思います。

――企業の中には往々にして、実際にプロジェクトを運用する部署と併走するプロジェクトを管理する管理部門がありますね。管理部門ではある一定のやり方が決まっている場合が多く、現場との意識の乖離があるといいます。そういう意味で、ボトムアップでの導入とトップダウンでの導入を比較すると、やはりトップダウンの方が圧倒的に効率的なんでしょうね。

杉若直樹氏

杉若　NTTコムウェアでは管理部門よりさらに上からRUP導入の声が降りてきました。その号令に合わせて、管理部門もRUP導入に対応しました。非常に幸運な例だったと思います。

A　私がいる部署では、オンライン系（画面系）と夜間バッチ系の2つの開発プロジェクトが同時並行で走っていまして、この2つのプロジェクトの開発手順をどう合わせていくのかが大きな課題になっています。同じデータベースを使っていますから、上司としては2つのプロジェクトとも同じやり方をしてほしいと考えているでしょう。ただ、オンライン系のスタッフはオブジェクト指向でやればいいと主張し、バッチ処理のスタッフはそうはいかないと言う。どっちを優先するかというと、今のところウォーターフォール型開発の方がうまく進んでいるんです。プロジェクトが立ち上がって間もないですから、ウォーターフォールでうまく行っているように見えますが、ずっと同じことをしているわけにもいかない。これをいかに今後、RUPを適用して効率的に作業を進めていくか、という説得が必要なんですね。プロジェクトには協力会社のスタッフも含まれていますから、彼らを巻き込んでこっそりと反復型の開発でやってみる、という試行錯誤の繰り返しです。それでぼちぼち結果が出てくればいいかな、と思っています。

――裏で進めていて、結果を出すという意見は多いですね。

井上　ただ、反復型開発に適するプロジェクトと適さないプロジェクトもあるので、すべてを反復型でやるというのは違う気がします。

巻山　バッチ処理のシステムには私も参加したことがあります。お客さまは「いついつまでにバッチ20個追加しておいて」みたいなことをおっしゃるわけで、こちらとしても次から次へと作業を進めていけなければいけない。しっかりとした仕様書なんて作る時間はないですし、途中から参加したスタッフには何が何やら分からない状況になってしまうんですね。しかし、開発における問題点などは逐次把握しなければならないので、途中から仕様をすべてユースケースで書き直してしまいました。そこまでしないと現状を把握できないんです。

現在の開発プロセスの課題（3つまでの複数回答 n=486） 出展：「＠IT Development Style読者調査」2002年11月

余田　反復型開発の導入の条件としてプロジェクトの規模は重要だと思います。自分1人あるいは2〜3人のスタッフがRUP経験者でも、プロジェクト規模があまりに大きいとすべてのスタッフにノウハウを行き渡らせるのはほとんど不可能です。私はしかたなく、当時プロジェクト専用に教育テキストを書いたりしましたが、こういうやり方は、まだまだ規模が小さいからできたことでしょう。

堂山　NTTコムウェアではRUP適用パイロットプロジェクトとして、規模の違うプロジェクトで検証してきました。50人、70人のプロジェクトになると、さすがに導入普及は大変ですね。

余田　最初は規模の小さいプロジェクトで経験し、次に少し大きいプロジェクトに移る、という具合にできれば、RUP技術者をスムースに増やすことができるかもしれません。開発プロジェクトには共通の“痛み”があると思います。端的なのは残業による“泊まり込み”でしょう。とにかく仕事が終わらない。バグ改修に何日もかかってしまう。こういう痛みに対して、なんとか改善していこうと働きかけることによって、チームがRUPの導入に積極的になっていきました。

――反復型プロセスを社内に浸透させるのは本当に一苦労ですね。普及のためにこういう工夫をしている、という方はいらっしゃいますか？

松岡　私は「こういう流れで作業を進めてくれ」と言うだけですね。お客さまにも「こんな感じで進めていきます」と打ち合わせでお話をするだけです。コンセプトまで説明するのはサブプロジェクトのリーダークラス以上ですね。それ以外のスタッフにはあえて説明しません。プロセスの重要性を理解するには、経験が必要だと思うんです。要求は簡単には固まらない、というのは経験者の方は理解できますが、若い方はよく分からないのではないでしょうか？ ハードウェアの開発では仕様書なしで設計を作業を行うことはまずないのですが、ソフトウェアの開発ではそういうことがよくあるのです。事実、作りながら仕様書を作っていくことも頻繁にあるわけです。そういうことは経験してこないとピンと来ないと思います。だから、スタッフにはあえて説明する必要はないと思っています。

――巻山さんは先ほど見積もりの精度を上げることで、反復型開発導入の端緒を開いたとおっしゃっていましたが、具体的にはどのようなデータでまわりを説得していったんですか。

巻山　私は最初にスコープを決め、それから全体像を決め、「これだけのシステムをいついつまでにいくらで作ります」と言ってしまいます。その際、全部ユースケースで仕様を書いてしまう。その段階ではチームなんてありません。スタッフはユースケースのシナリオに当てはめていくんです。それでチームができる。

　イテレーションで開発するなら、イテレーションを想定したスケジュールを書いていくんです。その結果できあがるユースケースシナリオには、開発スタッフの行動スケジュールが全部入っているんです。後は、スタッフごとに作業をすべて割り振るだけです。イテレーションの期間はスタッフと相談し、納得してもらったうえで設定します。

　つまり、結果的にはインクリメンタルな開発プロセスを実践していることになりますね。そういう意味で言うと、私も松岡さんと同様、スタッフに深い説明をしたことはありません。開発期間中は、（スタッフの）毎日の進捗状況をメールで受け取ります。毎朝、今日行う作業を聞き、仕事が終わったときに、1日分の進捗状況を報告してもらうことで、マネージメントをしていきます。開発規模は（実装フェーズで）およそ30人くらいですね。だから、最初の要件定義さえうまくいっていれば、後は流れ作業的に行えるのです。

Development Style Initialsponsorコーナー