システムアーキテクチャとSOA製品選定――分散するシステムをつなぐ製品について：戦う現場に贈る分散システム構築−開発現場編（9）（2/2 ページ）

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

システム非機能要件定義と製品選定

　今回、豆成くんが直面した局面はシステム全体の非機能要件機能定義に当たる。RFPなどで定義・提示された非機能（機能要件以外の部分）をよりどころにして、システムをどう構成していくかを決める作業である。いわゆるITシステムとしての技術的な作業がようやく発生してくる個所である。

　非機能要件については図に示したとおり、JISでは機能性・信頼性・使用性・効率性・保守性・移植性の6要件が挙げられている。具体的な項目については規格や手法によりさまざまであるが、おおむねこのような点が考察範囲として想定されていると考えてよいだろう。

図1　非機能要件項目（JIS X 0129-1〈ISO/IEC 9126-1:2001〉 外部及び内部品質のための品質モデルより）

　蔵田が例示したアプリケーションサーバ（APサーバ）の選択についても、システム非機能要件と照らし合わせて選定する必要がある（当然だが、担当者の個人的な好みや思い込みで決めてよいものではない）。蔵田が豆成くんに指摘した問題は、非機能要件中の「使用性」や「移植性」などにかかわる内容と考えられる。

　このフェイズで必要となるのは、どのようなアプリケーション構成で、どのような製品を使ってシステムを成り立たせるのか、局所的ではなく大きな視点でのアーキテクチャ構成を考え、それらを実現するために製品を選定するという姿勢だ。ベンダが提供する純粋なアプリケーションサーバやESB製品の多くは、世の中で一般的に要求される特定機能を提供するものであり、そのまま自社に使えるとは限らない。ERPやCRMなどの業務機能そのものを盛り込んだ製品は機能要件とシステム機能のフィットギャップを考えればいいが、カスタムアプリケーションを下支えする基盤系の製品は、厳密に使い方を決めたうえで採用検討を行うのが本筋である。

　いま豆成くんが挑戦中のシステムは、システム間連携が入る分散システムである。単体のシステム内でつじつまを合わせるのは当然として、別個のシステム同士を問題なく連携させることが必須事項として要求されている。例えばシステム間で採用されている製品が異なる、同じ場合でもバージョンが異なるなどの問題はごく一般的に起き得るものだ。同一メーカー製品間であればメーカー側のサポートが期待できるが、異なるメーカー間の接続ともなると難易度が急上昇することもざらである。ここをどう乗り切るかが鍵となってくる。

　なお、企業の大規模業務システムは歴史的に大手製品ベンダが主導してきた経緯があるうえ、乗り換えが容易でない、大きな金額が動くなどの理由により、政治的で恣意的な意思決定が行われやすい面がある。すなわち、1人のITアーキテクトができることは意外に少ないのが事実なのだ。「これを使うことはもう決まっています」と上意下達風に「伝達」されることもしばしばだ。だが、ITアーキテクトの職責としては、RFPなどで決められた非機能要件に採用予定の製品が合致しているか否かについては、客観的な事実としてその内容を吟味し、利害関係者に提示・説得する必要があることはいうまでもないだろう。技術者としての知見とこだわりを発揮すべき場面である。

どうやって製品を選定するのか

　もし、実現すべきソフトウェアの構成を何も考えない状態で製品の選定に当たった場合、製品の提供する美辞麗句に踊らされて目が曇り、もともと何が必要だったのかが分からないほど、迷走してしまうこともあり得る。ここでは、できる限りの客観性を持ちつつ、現実の開発や運用においての利点・欠点を導き出すためには、やはりもともとどういう形で作ることを想定していたのか、そこで何が足りないのか、何を補うために製品を採用するのか、という観点が必要となってくる。

　そのためには何よりもやはり、ソフトウェアのアーキテクチャ、例えばレイヤ構成はどうするのか、セキュリティはどう担保するのか、トランザクション制御はどこで行うのかといった所をまず決めるべきだ。そうでなければ、製品ごとの適合性判断は難しい。しかも製品ベンダがもともと想定していない使い方――パッケージアプリケーションではなく、企業が自社の都合で組み立てたスクラッチ開発システムを流用する形の分散システムであれば、まずはつないで正常に動くか否かという点から検証することが必要となってくるだろう。

図3　アーキテクチャと製品選定　システムの役割分担をアーキテクチャとして定めることで、選ぶべき製品の要件が見えてくる

　原則として、多額の費用と莫大な人員を投入して難度の高い分散システム開発を推進する以上、システムのプロトタイプを作ってそれを実際の製品に載せてみるといった検証作業の手間を惜しむべきではない。ここを勘・経験・度胸で押し切るのは、よほど類似の実績に恵まれたスーパー・アーキテクト以外、決してお勧めはできない。コスト・期間の制約が厳しい現実のプロジェクトを目の当たりにした場合、多分に理想的な話に聞こえてしまう点は残念だが、まずは在るべき姿、理想形を知ることである。ITアーキテクトとしてプロトタイプ構築と検証が不可欠だと肌で感じた場合、それを利害関係者に説得することも重要な仕事の1つであろう。

　今回の豆成くんも例外ではない。机上であれこれ悩んだり、製品動向を調査したりすることも大切だが、分散システム構築では製品選定から入るよりも、より本質的な意味を持つソフトウェアのアーキテクチャ設計と、その検証作業という側面から攻めるのがよいだろう。そのためには、まずアーキテクチャを決め、そこで何が足りないのか、何を補うために製品を導入する必要があるのか。そして候補となる製品に不足部分があるとき、それを補う方法があるのか、といったような筋道の付いた検討を行うことが重要である。

　次回は、そのソフトウェアアーキテクチャ部分について見ていこう。ITアーキテクト・豆成くんの腕が試される。

筆者プロフィール

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

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

株式会社豆蔵

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

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