決まらない要件や不安定なアーキテクチャ――。システム開発における「リスク」は年々増大し続けている。だが，リスクという課題に対して，従来のウォータフォール型開発では力不足だ。今，現場の開発者たちは反復型開発でリスクと上手に付き合う解を見つけた。先行ユーザーの成功と失敗から得られた最新情報を基に，実践上のポイントを明らかにする。
「1200万人分のバッチ処理をJavaで成し遂げなければならない」──。初めて挑む技術的難題に対して，電通国際情報サービス（ISID）の土屋尚友氏（産業ソリューション開発部 グループマネージャー）は，反復型開発プロセスのRUP＊1に活路を求めた。技術リスクを抑えることに適した開発プロセスと考えたからである。結果は，土屋氏の狙い通りに成功を収めた。
一方，ディーシーカードでカード会員向けのサイト構築を指揮する小林良彦氏（デジタル事業推進部 インターネット推進グループ 部長代理）は，ウォータフォール型開発で仕様変更による超過コストが50％にもなり，「どうにかしなければ」と感じていた。「このサイトは操作性や見た目が何より重要なため，開発途中の頻繁な仕様変更は避けられない。ならば，仕様変更を前提とした開発プロセスを採用すればいいと考え方を変えた」（小林氏）。現場のSEの賛同もあり，XP＊2やRUPで反復開発に挑戦した結果，仕様変更による超過コストを2分の1から3分の1に低減できることが分かった。
 図1●見通しの悪いプロジェクトが増える 最近は，「技術リスク」や 「要件リスク」が一層高まり，“見通し”の悪いシステム構築プロジェクトが増えている [画像のクリックで拡大表示] |
ISIDが直面した「技術リスク」やDCカードが悩んだ仕様変更の問題（「要件リスク」）は，決して対岸の火事ではなく，多くの開発者にとっても緊急に手を打つべき問題だ。長く開発現場の課題を見てきた，富士通 共通技術本部 プロジェクト統括部長の薮田和夫氏は，「技術と要件の2面で“見通し”の悪いプロジェクトが増えている」と指摘する（図1）。「見通しが良ければウォータフォール型が最適。昔はそれでよかった。だが今や，無数の組み合わせがあるプラットフォームの上で，試作しながら要件を固めていくようなシステムばかり。見通しの悪さはどんどん加速している」（薮田氏）。
リスク回避に反復開発が効く
こうしたリスクを開発の早い段階で回避できるメリットに着目して，今，RUPやアジャイル開発プロセス＊3といった「反復型開発プロセス」を選択するユーザーが増えつつある。反復型開発とは，「設計→実装→テスト→システムのリリース」という開発サイクルを1，2週間から1カ月程度の短期間で実施し，それを繰り返してシステム全体を開発していく手法である。
例えば，サントリー，全日本空輸，中古車買い取りチェーンのガリバーインターナショナル，統合業務パッケージ「SuperStream」を開発/販売するエス・エス・ジェイ（SSJ），約20の商品/サービス比較サイトを開発/運営するウェブクルーなどが，リスクを抱えたプロジェクトを反復開発で乗り切り，その効果を実感している。
今回，取材を通してこれらユーザーのノウハウに迫った。本記事では2つのリスクを反復開発で解決するノウハウと，効果的に反復開発を進めるノウハウを3回に分けて紹介する。
◆技術リスクを回避する
「検証作業の反復」が有効
最新の技術を使って既存システムをリプレースする案件が増えている今，性能不足や構築スキルなどの技術面で不安を抱くユーザーが増えている。そうしたユーザーはRUPを採用する傾向にあるようだ。RUPの基本コンセプトの中に，(1)様々なリスクを早期に解消する姿勢で取り組む「リスク駆動」，(2)非機能要件（信頼性や性能，再利用性，拡張性など）を考慮した上で，システムのアーキテクチャ＊4をしっかりと作る工程を明示した「アーキテクチャ中心」があり，これらが開発者を引きつけている。
しかし，「あるRUP開発チームでは，すべての開発者にRUPの教科書を持たせ，RUPツールも導入していたが，うまくRUPを進めることができなかった。“どう反復させていくのか”という最も大切なノウハウは，それぞれの開発現場で異なるからだ」（反復開発のコンサルティングを手がけるジークステクノロジー 北野弘治氏）。
“3×3×3”でリスクを回避
サントリーはRUPのコンセプトを十分に理解し，状況に即した反復計画を立てて技術リスク低減に成功した。
同社は2002年に，開発標準をUML/Java/フレームワークを使ったコンポーネント・ベースのオブジェクト指向開発に切り替えていた。しかし，大規模システムへの適用は，今年1月に本稼働した「共通債務システム」が初めてだった。総工数350人月，開発期間2年を費やしたシステムである。
 図2●プロジェクトの初期で技術リスクを潰す サントリーはJavaやフレームワーク，UMLを使う本格的なオブジェクト指向開発へ舵を切った。ここで生じる技術リスクをプロジェクトの早期に解消するため，RUPによる反復型開発を採用した。3期にわたった工程の第1期では3回の反復でインフラに近い部分から性能や技術を検証して，リスクを低減していった [画像のクリックで拡大表示] |
開発パートナーである日本総合研究所のアーキテクト＊5，三嶋正弘氏（産業ソリューション事業本部（大阪） 開発第四グループ シニア・アプリケーション・エンジニア）は，最もリスクを潰せる反復方法をRUPの方向付けフェーズで練った。
導き出したのは，開発を3期に分け，各期の中でも反復を繰り返す2段階の反復プロセスだった（図2上）。第1期では技術リスクが高く要件リスクが低い機能を構築，第2期では要件的に困難な機能，第3期では枝葉の機能を開発することにした。第1期は，主に技術検証を繰り返しながらシステムの基盤を構築し，技術リスクの低減を図った。この基盤の品質が，その後のプロジェクトの成否を左右する。
三嶋氏は，さらに基盤を3つに切り分けた上で，3回の反復開発で徐々に技術リスクを低減していく方針を採った。具体的には，(1)Javaコンポーネントの基盤整備，(2)フレームワーク「cFramework」を使ったオンライン処理基盤の確立，(3)COBOLからJavaに実行環境を移したバッチ処理基盤の性能検証──について，図2下のように小刻みに反復開発した。
その結果，バッチ処理の一部でJavaの採用をあきらめ，従来のCOBOLをやむなく残す部分も出た。Javaでは必要とする性能が出なかったからだ。「Javaに統一したかったが，早期に問題を発見/回避できたことは反復開発ならではの成果」と三嶋氏は語る。
プロジェクトの成功を振り返り，サントリー 情報システム事業部 システム開発部 課長の川（かわ）晃憲氏も，「アーキテクトが技術リスクをしっかり認識し，最適な反復プロセスを計画してくれたことに尽きる」と評価する。
実システムを作りながら検証する
全日空のマイレージ管理システムをCからJavaへリライトするプロジェクトでも，技術リスク，特に性能不足の回避が最大の焦点だった。
旧システムから開発/保守を担当してきたISIDの土屋氏は，再利用性の観点からJavaを提案したが，「これほど巨大なJavaのバッチ処理は初めて」だった。しかも，Java開発チームは今回新たに組織したため，メンバーの技術的なスキル・レベルが分からない。開発当初で，性能と構築スキルの2点でリスクを背負っていた。
土屋氏はリスク駆動とアーキテクチャ中心を心がけて，8カ月で6回の反復開発を計画。何より先に性能面の技術リスクを低減するために，第1反復ではバッチ基盤を構築することにした。2カ月間，Javaでバッチ処理をリライトしながら，Cベースの旧バッチ処理との性能比較を続けた末に，満足のいく成果を得られた。
従来型の開発でも，プロトタイプ開発により同様のリスク低減を図れると思われがちだが，それと反復型は決定的に異なる。プロトタイプは一部の機能を取り出して検証するに過ぎず，ユーザー要件やシステム要件を100％満たしたものでもない。反復型は「実システムを作りながらリスク低減を図れること」が大きな強みである。
開発者の構築スキルに起因するリスクについては，第1，第2反復の実績を見ながら，機動的にチーム編成を変更して対応した。
第1反復の結果，メンバーのJava技術の底上げには時間がかかると見た土田氏は，「基盤クラスを設計できる技術者か，コンポーネントを使うだけの技術者か」などを見極め，その後の反復で構築スキルが平準化するようにチームを組み直した。
さらに，「いつの時代もDBがボトルネックとなる」と考えた土田氏は，パフォーマンス監視チームを別に設け，反復ごとに開発者のSQL文の記述にチェックの目を光らせた。こうして12チームが5反復で構築した新システム（第1期開発）は性能を満たして本稼働できた。
実際に動くシステムを短い間隔でリリースできる反復型開発だからこそ，性能検証も構築スキルの見極めも可能になる。
3回の反復でバグが7分の1に
テスト工程が後半に集中するウォータフォール開発では，バグが多発した場合，そのリカバリが泥縄になる。こうした「品質不良」という技術リスクを低減させる点でも，反復開発のメリットは大きい。たとえ一度の反復で失敗しても，次の反復を始める前に「振り返り＊6」のチャンスがあり，挽回しやすいからだ。
 図3●反復で習熟度は上がる クロノスが受託したある反復型開発では，第1反復で一時は頓挫が危ぶまれたほどの状態に陥り，バグ発生率が高かった。しかし，開発者の習熟度アップにより，第2反復以降はバグ発生率が半減していった [画像のクリックで拡大表示] |
ITベンダーのクロノスが受託したある反復開発では，3回の反復を経てバグの発生を実に7分の1に低減できた（図3）。重要で複雑な機能の設計/開発が割り当てられていた第1反復では，開発メンバーの習熟度も低くバグが多発。コンポーネント開発をベースにしていたが，プロジェクトでコンポーネントの作成予定などを一元化していなかったため，重複による修正や破棄も発生した。「プロジェクト・マネージャが第1反復の終わりに“失敗プロジェクトだ！”と叫ぶほど状況は悪く，一時は開発が頓挫するかとも思った」（クロノス 第一開発部リーダー 山野寛氏）という。
下がったモチベーションを盛り返したのは，反復後の振り返りだった。ここでメンバー全員が意見を出し合い，次の反復での改善策を考えた。Excelの仕様書からJUnit用テスト・ケースを自動生成するツールを作ったり，コンポーネント情報の交換，リファクタリング＊7の導入などを決めたりした。「毎朝のスタンドアップ・ミーティングでも，課題の確認とスケジュール確認を実施して乗り切った」（山野氏）。こうした策が奏功し，第3反復ではテスト・ケース数が第1反復の2.5倍に増えていたにもかかわらず，バグの発生率は約7分の1という成長を遂げた＊8。
