“要件を決められない”という要件リスクに対して，反復開発では「短いサイクルでリリースする“動くシステム”を呼び水に，ユーザー要件を引き出すことができる」（みずほ情報総研 開発第二本部 第五部 務台（むたい）博海氏）。動くシステムが開発の末期でないとリリースできないウォータフォール型との決定的な違いだ。

　このメリットを生かし，みずほ情報総研はある企業の基幹システム刷新プロジェクトにおいて，毎週水曜日の午後いっぱいをユーザーとの定例会議，その翌週の金曜日をリリース日と決め，1週間という非常に短いサイクルでシステムを次々とリリースできた。

　一般に反復開発では，従来型の開発方式よりユーザーの高い参画度が求められる。このケースでは，ユーザー自身に「小さく生んで大きく育てることや手戻りを許容する開発手法を望む姿勢があった」（同部 担当課長 浦田智之氏）ことが成功の下地になっている。

ユーザーの“代理人”を立てる


図4●顧客の“代理”を立て，プロジェクトに常駐
TISの倉貫氏はXP開発を進めるに当たり，常時プロジェクトに参加してもらえない顧客に代理人（ユーザーのシステムを長年開発している開発者）を立て，プロジェクトに常駐してもらった。同氏はこのプラクティスを「顧客プロキシ」と名づけた
[画像のクリックで拡大表示]

　しかし，「要件リスクを回避するため反復開発をやりたいが，ユーザーがなかなか時間を割いてくれない」という現場の悩みは多いだろう。この問題に1つの答えを出したのがTISの倉貫義人氏（基盤技術センター コンサルタント 主査）だ。以前のXPプロジェクトで「顧客プロキシ」と名づけた手法を編み出した。XPにはユーザーがプロジェクトに常駐する「オンサイト顧客」というプラクティスがあり，ユーザー参画の必要性が非常に高い。しかし，ユーザーにオンサイトで参画してもらう同意が得られなかったため，顧客プロキシを考案した（図4上）。

　顧客プロキシとは，ユーザーの業務とシステムを長年担当するSEをユーザーの代わりに見立てて，プロジェクトに参画してもらうこと。顧客プロキシがユーザーとの要件定義や橋渡し，受け入れテストも担当するため，ユーザーが常駐しなくとも，ある程度正確な方向でプロジェクトが進む。だが，最初は顧客プロキシが1人だったため，負荷が集中して大変だった。

　そこで今回，別ユーザーのXPプロジェクトで，顧客プロキシを3人に増やし，負荷の分散を図った（図4下）。開発体制も，顧客プロキシを中心にユーザーと要件を詰める「業務チーム」と，そこで決まった要件を実装/テストする「開発チーム」に分けた＊9。業務チームが1回の反復を終えると，そこでユーザーと要件定義を進めていた顧客プロキシが1人ずつ順番に開発チームに移り，開発チームのSEと一緒にXP開発を進める。その間に，業務チームは並行して要件定義の続きを進めることができる。「顧客プロキシが開発チームに入っている間，ユーザーと取り決めた仕様を共有しにくい」（倉貫氏）という改善の余地はあるものの，創意工夫でユーザーの要件を引き出すことができた＊10。

全員参加で真摯なやり取りを

　「早いビジネスの流れに追いつくため，経営層やユーザーを巻き込み，1カ月ごとに実装できる範囲を“関係者全員で考えて開発”してきた」と語るのは，ガリバーインターナショナル 情報システム部 椛田（かばた）泰行氏だ。

　椛田氏が担当する大/中規模開発で実践しているのは，「Scrum」というアジャイル開発プロセスの1つ。Scrumは「30日を反復（スプリント）の単位とする」「毎朝15分ミーティングする」「スプリント終了後は4時間レビューする」といった行動基準を重視し，一度決めた行動基準を皆で厳守することがルールになっている。関係者全員がスクラムを組んで，システム開発を進めていくためだ。結束が強くなり，結果として要件リスクが小さくなる。

　さらにガリバーは，情報システム部の体制にも工夫している。同社の4つの事業部に対して，設計やマネジメントに長けた上級SEを1人ずつ専任で張り付け，ユーザーからの要求を厳しくチェックしているのだ。この上級SEは「システムはツールに過ぎない」と言ってはばからず，ユーザーからのシステム化要求にあいまいさがあれば，ユーザーに費用対効果などを説明させるという。数字で表せない場合には「どのようなビジネスの効果を生むか」と論理的な説明を求める。スクラムの上に成り立つこのようなやり取りが，要件リスクを確実に減らす。