その分散システムは、正しく作られているか?――開発後の検証・受け入れを考えよう戦う現場に贈る分散システム構築−情報部門編(6)(1/2 ページ)

豆成くんの分散システムに関する作業もいよいよ大詰め。そんな豆成くんのところにやってきた先輩社員・蔵田が告げたセリフは驚愕(きょうがく)の内容だった。

» 2009年05月25日 12時00分 公開
[岩崎浩文,豆蔵 BS事業部]

 SI会社からあるユーザー企業に転職した豆成くんは、入社早々点在する複数のシステムを統合する大役を押しつけられてしまった。要件定義から方式設計まではおおむね完了し、開発のためのRFPをまとめる段階まで進んだのだが、まだまだ先は長い。

 独立した単体システムのみの開発経験で、業務知識もシステム統合技術も持たない豆成くんは、無事プロジェクトを成功させることができるのだろうか?

豆成くん、開発を甘く見る

 前回の蔵田先輩の助言により、業務分析からシステム設計への鍵をつかんだ豆成くん。データ構造を中心に考えるという、伝統的ともいえる“ベタ”な対応ではあったが、非常に分かりやすい方針であったため、年長者や関係各位の反応もよく、設計作業は意外にもはかどった。

 スケジュール上の遅れはあるにせよ、設計作業の目途がある程度の立ったところで、蔵田は豆成くんに今後の話をしてみた。

 「豆成、今後についての話だ。この成果物を基に開発フェイズに入るわけだよな」

 「はい。開発委託先にこれらを発注するために、RFPをまとめる予定です。それを先方に渡して提案書をもらったら、発注――請負契約ってやつですよね」

 「うむ、それなんだがな……。部長の方から“発注はくれぐれも慎重にやれ”とお達しが来たんだ。前回の開発で、発注した内容と出来上がってきたソフトウェア成果物に齟齬(そご)があってな。要するにちゃんと作ってなかったわけなんだが、訴えるのなんのって大揉めだったんだよ。しかも、今回は丸投げじゃなくて、ひょっとすると複数の業者へ分割発注することになるかもしれん。開発規模がデカいからな」

 豆成くんは、前職で発注側に散々いじめられた経験を思い出しながら、悩ましげに応えた。「難しいですね。ボクも以前は“できてる、できてない”で、いつも揉めてました。それをどうやったら回避できるのか、正直良案が思い浮かびません……そんなもんじゃないんですか、開発作業って?」

 「いや、それじゃぁ困るんだよ」――蔵田は少し苛立たしげに反応した。

 「納品を受けて検証作業をやって、瑕疵(かし)を見つけて修正依頼を出して――なんてことを繰り返してたら、どんだけコストが掛かるか。下手をすればうちの責任ということで、追加請求される場合だってある。しかも相手は複数だ。時は金なり。今回のプロジェクトの大目標を忘れた訳じゃないよな」

 「大目標って、コスト削減ですよね……」

 豆成くんはうつむき気味に答えた。

発注と納品との溝

 ここで豆成くんが突き付けられた課題は、システム開発のみならず、世に一般の「オーダーメイド」型の商売に付きものの普遍的なものである。発注側は「プロに頼んでるんだから、子細はよろしくやってくれるだろう」と自分に都合の良い方に解釈し、受注側は「指示がないからこんな感じで済ませてしまおう」と、やはり自分側に都合の良い方で決着させてしまう。

 しかも今回の場合、オーダーメイド対象がユーザーインターフェイス以外は目に見えない、業務アプリケーションである。その仕組みが裏でどうやって実現されているのか、将来どのように利用する予定があるのか、など発注時に多くの情報を付与しない限り、発注側が受注側に正確な意図を伝えたことにならない。

ALT 図1 あいまいな発注は、自分の首を絞める

 加えて、今回は既存システムも含んだ分散型のシステム構成が前提となっている。発注先のベンダについても、一社に丸投げという形態は(既存システムとそのお守りをしているベンダが存在している以上)なかなか採りづらい。

 つまり大規模分散型のシステム開発においては、発注のための要件定義が最も難易度の高い個所となることが想像できよう。これまでの連載で豆成くんが苦労してきたのは、まさに納品・検品段階でのトラブルを防止するためでもあったのだ。

       1|2 次のページへ

Copyright © ITmedia, Inc. All Rights Reserved.