システムを統合するために必要な事前知識――必須となる技術要素の整理と整合性について：戦う現場に贈る分散システム構築−情報部門編（2）（2/2 ページ）

[岩崎浩文，豆蔵 BS事業部]

契約の観点から発注側のプロセスを定義せよ

　さて、実際にプロジェクトを開始するまでに最低限決めておくべき事柄がある。設計を含めて作業を外部に委託する場合であっても、プロジェクトの主体はあくまで発注側である。となれば、それを包括する全体のプロセスと契約の関係を決めておく必要があるのだ。

　局所的な開発のプロセスとしては、ウォーターフォール型プロセスやイテレーティブ型プロセスなどが有名であるが、これはどちらかといえば主に作り手側の視点によるものだ。発注側から見た経営戦略まで含めた大きなプロセスの例としては、ISO/IEC 12207とその邦訳であるJIS X 0160:1996「ソフトウェアライフサイクルプロセス」、およびそれを拡張した独立行政法人情報処理推進機構による「共通フレーム2007」が存在する。

※参考資料
『共通フレーム2007??経営者、業務部門が参画するシステム開発および取引のために』 情報処理推進機構 ソフトウェア・エンジニアリング・センター=編/オーム社/2007年（amazon.co.jpへのリンク）

　それらを基に、ITスキル標準（ITSS V3）の投資局面、及び発注と契約の観点からV字モデルに再整理したものが下図である。

図 契約の観点から再整理した変形V字プロセス

　この図はV字の左右が「作業とその検証」という対応関係になっている。それぞれのプロセスの切れ目が契約の切れ目となり得る（しやすい）節目である。つまり、この切れ目でRFPを作成しなければならない可能性がある、ということになる。

　システム構築の契約は通常、設計段階では準委任契約、ソフトウェア開発の部分は請負型契約となることが多い。つまり、設計と開発では別契約となるため、全体の線表の上ではソフトウェア適格性確認テスト（つまり受け入れ作業など）の重要なイベントが発生することになる。そのタイミングで概算見積もりを出す方式である。

　受け入れ作業は一般に軽視されがちだが、誰が主体となっていつまでに受け入れを行うのかを決めておかない限り、この作業がボトルネックになってしまう恐れが高い。特に分散システムは、単体で完結して動作するシステムに比較して、チェック項目が圧倒的に多くなる。このとき、接続先となる既存システムを利用する部門が主体となってチェックしてくれるはずもない。あくまでもチェックは発注者である豆成くんの組織??情報システム部の仕事となるだろう。

　豆成くんの組織のように、発注側にそのような余裕や能力がない場合、この受け入れ作業までもを委託する必要がある。ここで必要な考え方は、誰がチェックできるのか、という観点である。図2のようなプロセスを用いた場合、実装時の受け入れをチェックできるのは、その反対側である要件定義を行ったグループである。

　筆者らが特に実際のプロジェクトで推奨している手法では、このV字モデルで要件定義の対となる受け入れ作業や検証作業を、最初から予算化し、可能ならばRFPに含めて事前に見込んでおく。期間や予算を最初から見込んでいない場合、後から追加や変更がどうしても必要になったときに無理が生じ、追加予算の確保・調整などが泥縄的になり、各方面がバタバタと奔走させられる可能性が高い。

なぜそうなったのか、根拠を確保せよ

　さて、ここからが本題だ。先の図2を俯瞰（ふかん）すると、システム構築の主領域において、作業は業務分析（業務要件定義）から要件定義を経て、実装（ソフトウェア開発）となっている。これは、すべての要件は業務から開発されるべきである、との要求開発の考えに基づいたものであるためだ。

　筆者は過去の記事（※）でもITアーキテクト視点での根拠の必要性を主張したが、それ以外の分野においても、ほぼすべての仕様は上位目的である業務要件から導き出されなければならないと考えている。

※参考記事
連載:28歳から挑戦するITアーキテクト（2） - アーキテクチャの採用理由を説明できるか？（＠IT情報マネジメント）

　上述したように、成果物の検証は発注者の活動だ。作業を委託する場合であっても発注者の視点でチェックすることになる。このとき、システムの要件が業務要件につながっていない設計になっていれば、その投資の客観性が確保できない事態になりかねない。つまり、決められた仕様はひょっとして担当者の趣味でやっているのではないか、との疑念を抱かれる恐れがあるということだ。

　特に冒頭の豆成くんの例でも、分散システムほど範囲の広い領域のシステム連携が必須となる作業であれば、その利害関係者も膨大な数に上る。その全員が必ずしも協力的であるとはいえず、不意に揚げ足を取られて転倒する事態も想定される。そうならないためにも、なぜそのような仕様となったのか、客観性を持った根拠を確保する必要があるといえよう。プロジェクト全体の客観性・公平性・必然性の確保のためにも必要な作業である。

　また、SOA型のシステム設計時に必ず問題として挙がる典型的な個所として、サービスの単位を一体どうやって抽出していくのか、というものがある。この問題に対する明快な解法として、“根拠”を生かして導き出す手法がある。これについては次回以降で取り上げていこう。

　さて、次回は具体的な分析・設計作業に突入した豆成くんが直面する、成果物のつながり、つまりトレーサビリティについて見てみることにしよう。

筆者プロフィール

岩崎 浩文（いわさき ひろふみ）

株式会社豆蔵 BS事業部。ITコンサルティング会社にて商用フレームワーク設計・構築およびITアーキテクトとして多数の企業システム設計・構築に携わる。その後、サーバ製品ベンダにてSOAコンサルタントを担当したのち、2005年より現職。現在、方法論「enThology」（エンソロジー）の策定とSOA型システム設計支援の主任担当として多くの現場へ支援を行っている。

株式会社豆蔵

「戦う現場に贈る分散システム構築」バックナンバー

• 既存システムという制約とアーキテクチャ――どうつなぎ、うまく再利用するか
• システムアーキテクチャとSOA製品選定――分散するシステムをつなぐ製品について
• 悩ましき分散システムのアーキテクチャ――要件に合致したシステムを設計するために
• これから始めるサービス指向型設計――単独システムとは違う世界へようこそ
• その分散システムは、正しく作られているか？――開発後の検証・受け入れを考えよう
• ここが核心！ 各サービスの抽出とサービス統合――SOAサービスの切り出し方とその統合方法
• 理想像と現実のフィット＆ギャップを知る――業務分析の成果をシステム統合に活かす
• システム統合になぜ業務分析が必要なのか？――作業の理由とITガバナンス
• システムを統合するために必要な事前知識――必須となる技術要素の整理と整合性について
• 緊急課題！ 点在する複数のシステムを統合連携せよ――問題山積！ 乱立する情報システムの解法とは？