悩ましき分散システムのアーキテクチャ――要件に合致したシステムを設計するために：戦う現場に贈る分散システム構築−開発現場編（8）（2/2 ページ）

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

システム機能要件定義で行う作業

　今回は「システム要件定義」のフェイズである。RFPなどで定義・提示された要件を基にして、システムでその機能を具体的にどう実現すべきなのかを決める作業がメインとなる。RFPを作成する要件定義フェイズが“粗いレベルで要望をまとめる作業”とすれば、それをより具体化・詳細化していく作業と考えればよいだろう。

　ここで蔵田が語ったのは、このRFPにまとめられた要件を基にしてどのような手順で設計書を書いていくのか、という視点からのものだ。詳細レベルの要件は一般に膨大であるため、1人の人間が作業できる量を超えていることも多い。事前に作業の手順を決め、集団で機械的に作業できるように取りはからうことが想定されている。豆成くんのいう“集団の力技”というのは、それを前提にした問いだったわけだ。

　なお、このシステム機能要件定義で作成する成果物は、一般にシステムの取り扱うべき情報の構造（概念モデルやE-Rモデルなど）、その情報の処理（業務フローやユースケースなど）、そして利用者が操作すべき画面（画面遷移図や画面設計書など）とその構成などが主だったものである。

　典型的な企業システムは、情報をどう効率的に書き込み、どう効率的に読み出すかという処理を中心に考えることができる。この点は開発言語や動作プラットフォームが変化した現在においてもあまり変化はない。この点を鑑みれば、蔵田の説明した過去の手法にならう作業案は、さして不思議だともいい切れない。むしろ過去に実績があり、社内文化として（一部とはいえ）根付いているならば、その選択には一定の合理性があるといえる。今回の考察領域であるシステム機能要件については、単体システムも分散システムもさほどの違いがない、といっても過言ではないだろう。

単体システム開発と分散システム開発の溝

　問題のポイントは、そのシステム機能要件をどのような方式（アーキテクチャ）で実現するのか、という部分にある。

　例えば「商品を更新する」という実現すべき処理があった場合、単体システムの新規開発であれば、そこで取り扱うべき情報構造と、そのための操作する画面の設計があれば、あとは決めた方式にのっとって物理設計まで一気に落とし込むことが可能である。組織で決まったやり方がある場合や、やり方が最初から指定されている場合であれば、さほど悩まずに実装作業まで進めるはずである。

図1　単体システム・新規開発の場合

　ところが既存システムの流用が前提となる分散システムの場合、このような「一気通貫モデル」を導き出すことは容易ではない。なぜなら、既存システムにはすでに同じ機能が存在している可能性があるうえ、複数の既存システムで同じ情報を取り扱っている可能性があるからだ。

図2　分散システム・既存流用の場合

　このため、分散システムの場合、既存システムとの接続の都合なども考慮したうえで独自の方式（社内標準）を考慮する必要が発生する。主に接続のパターンやプロトコルの選定、トランザクション制御やセキュリティなどが中心課題となるだろう。こうした環境下での標準手法がすでに組織内で定義されていたり、最初から指定されたりしていれば問題ない。だが、そういった幸運な（腕の立つ技術者にとっては不幸な？）場合を除き、まず方式を定義して、その上に各機能を実現していく形を取らざるを得ないだろう。

　豆成くんが頭を悩ましているのは、まさにこの領域の話である。各既存システムの方式を理解したうえで、どう設計していくのか。各システムのデータは整合性を確保できるのか。非機能要件で定義された条件を満足させて正常に動作するのか――。大変重大な個所でもあり、1つ間違えるとシステム全体が機能不全に陥る恐れもある。

　次回からはこのシステム方式設計部分について、複数回にわたって豆成くんの悩みを見ていくことにしよう。

筆者プロフィール

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

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

株式会社豆蔵

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

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