システムを統合するために必要な事前知識
――必須となる技術要素の整理と整合性について2008/11/7
契約の観点から発注側のプロセスを定義せよ
- - PR -
さて、実際にプロジェクトを開始するまでに最低限決めておくべき事柄がある。設計を含めて作業を外部に委託する場合であっても、プロジェクトの主体はあくまで発注側である。となれば、それを包括する全体のプロセスと契約の関係を決めておく必要があるのだ。
局所的な開発のプロセスとしては、ウォーターフォール型プロセスやイテレーティブ型プロセスなどが有名であるが、これはどちらかといえば主に作り手側の視点によるものだ。発注側から見た経営戦略まで含めた大きなプロセスの例としては、ISO/IEC 12207とその邦訳であるJIS X 0160:1996「ソフトウェアライフサイクルプロセス」、およびそれを拡張した独立行政法人情報処理推進機構による「共通フレーム2007」が存在する。
※参考資料
それらを基に、ITスキル標準（ITSS V3）の投資局面、及び発注と契約の観点からV字モデルに再整理したものが下図である。
 |
| 図 契約の観点から再整理した変形V字プロセス |
この図はV字の左右が「作業とその検証」という対応関係になっている。それぞれのプロセスの切れ目が契約の切れ目となり得る（しやすい）節目である。つまり、この切れ目でRFPを作成しなければならない可能性がある、ということになる。
システム構築の契約は通常、設計段階では準委任契約、ソフトウェア開発の部分は請負型契約となることが多い。つまり、設計と開発では別契約となるため、全体の線表の上ではソフトウェア適格性確認テスト（つまり受け入れ作業など）の重要なイベントが発生することになる。そのタイミングで概算見積もりを出す方式である。
受け入れ作業は一般に軽視されがちだが、誰が主体となっていつまでに受け入れを行うのかを決めておかない限り、この作業がボトルネックになってしまう恐れが高い。特に分散システムは、単体で完結して動作するシステムに比較して、チェック項目が圧倒的に多くなる。このとき、接続先となる既存システムを利用する部門が主体となってチェックしてくれるはずもない。あくまでもチェックは発注者である豆成くんの組織――情報システム部の仕事となるだろう。
豆成くんの組織のように、発注側にそのような余裕や能力がない場合、この受け入れ作業までもを委託する必要がある。ここで必要な考え方は、誰がチェックできるのか、という観点である。図2のようなプロセスを用いた場合、実装時の受け入れをチェックできるのは、その反対側である要件定義を行ったグループである。
筆者らが特に実際のプロジェクトで推奨している手法では、このV字モデルで要件定義の対となる受け入れ作業や検証作業を、最初から予算化し、可能ならばRFPに含めて事前に見込んでおく。期間や予算を最初から見込んでいない場合、後から追加や変更がどうしても必要になったときに無理が生じ、追加予算の確保・調整などが泥縄的になり、各方面がバタバタと奔走させられる可能性が高い。
なぜそうなったのか、根拠を確保せよ
さて、ここからが本題だ。先の図2を俯瞰（ふかん）すると、システム構築の主領域において、作業は業務分析（業務要件定義）から要件定義を経て、実装（ソフトウェア開発）となっている。これは、すべての要件は業務から開発されるべきである、との要求開発の考えに基づいたものであるためだ。
筆者は過去の記事（※）でもITアーキテクト視点での根拠の必要性を主張したが、それ以外の分野においても、ほぼすべての仕様は上位目的である業務要件から導き出されなければならないと考えている。
※参考記事
- 連載:28歳から挑戦するITアーキテクト（2） - アーキテクチャの採用理由を説明できるか？（＠IT情報マネジメント）
上述したように、成果物の検証は発注者の活動だ。作業を委託する場合であっても発注者の視点でチェックすることになる。このとき、システムの要件が業務要件につながっていない設計になっていれば、その投資の客観性が確保できない事態になりかねない。つまり、決められた仕様はひょっとして担当者の趣味でやっているのではないか、との疑念を抱かれる恐れがあるということだ。
特に冒頭の豆成くんの例でも、分散システムほど範囲の広い領域のシステム連携が必須となる作業であれば、その利害関係者も膨大な数に上る。その全員が必ずしも協力的であるとはいえず、不意に揚げ足を取られて転倒する事態も想定される。そうならないためにも、なぜそのような仕様となったのか、客観性を持った根拠を確保する必要があるといえよう。プロジェクト全体の客観性・公平性・必然性の確保のためにも必要な作業である。
また、SOA型のシステム設計時に必ず問題として挙がる典型的な個所として、サービスの単位を一体どうやって抽出していくのか、というものがある。この問題に対する明快な解法として、“根拠”を生かして導き出す手法がある。これについては次回以降で取り上げていこう。
さて、次回は具体的な分析・設計作業に突入した豆成くんが直面する、成果物のつながり、つまりトレーサビリティについて見てみることにしよう。
株式会社豆蔵 BS事業部。ITコンサルティング会社にて商用フレームワーク設計・構築およびITアーキテクトとして多数の企業システム設計・構築に携わる。その後、サーバ製品ベンダにてSOAコンサルタントを担当したのち、2005年より現職。現在、方法論「enThology」（エンソロジー）の策定とSOA型システム設計支援の主任担当として多くの現場へ支援を行っている。
株式会社豆蔵
SI会社からあるユーザー企業に転職した豆成くんは、入社早々点在する複数のシステムを統合する大役に任じられた。先輩格の蔵田に相談すると「情報システム部門にもSI会社にもこの手の複雑な設計をこなす能力を持つ人材はいない。そして個々のシステムの面倒を見ているSI会社は既得権益を守るため、システム間調整を嫌がる」と指摘された。
こうした状況は、実際のユーザー企業によく見られる。複数システムを統合・連携させるには、技術論の前に政治的な話に巻き込まれることが多いのだ。分散システム構築プロジェクトにおいては、構築対象のシステムを事前に設計し、RFP（提案依頼書）を出してそれに対するプロポーザル（提案書）と見積もりを複数社に提案してもらい、中身と価格を見ながら発注する方法が好ましい。
またプロジェクトを実際に開始するまでに、全体のプロセスと契約の関係を決めておく必要がある。特に受け入れ作業や検証作業の主体（発注側）を明確にし、予算化しておきたい。この発注側からの視点でチェックしたとき、仕様の客観的根拠が必要だ。SOA型システム設計の典型的な課題である「サービス単位の抽出」にも、この根拠が生かせる。
| Page1 豆成くん、苦悩する 設計するのはどこの誰？ |
|
 |
Page2 契約の観点から発注側のプロセスを定義せよ なぜそうなったのか、根拠を確保せよ |
キャリアアップ
スポンサーからのお知らせ
転職／派遣情報を探す
「ITmedia マーケティング」新着記事
イーロン・マスク氏がユーザーに問いかけた「Vine復活」は良いアイデアか？
イーロン・マスク氏は自身のXアカウントで、ショート動画サービス「Vine」を復活させるべ...
ドコモとサイバーエージェントの共同出資会社がCookie非依存のターゲティング広告配信手法を開発
Prism Partnerは、NTTドコモが提供するファーストパーティデータの活用により、ドコモオ...
「インクルーシブマーケティング」実践のポイントは？ ネオマーケティングが支援サービスを提供
ネオマーケティングは、インクルーシブマーケティングの実践に向けたサービスを開始した...
