システム基盤を設計・構築するためには,千差万別のユーザーの業務要件から,非機能要件の定義に必要な情報を漏れなく集めたり,設計結果をチェックする必要がある。実際にはどんなアプローチで挑むのか。Part4では新日鉄ソリューションズが策定したシステム基盤設計の実践手法を紹介する。

 構造化手法,オブジェクト開発方法論,データ中心アプローチなど,アプリケーションに焦点を当てた多くのシステム開発方法論が提案され,開発現場で適用されている。しかし,システム基盤の開発方法論はあまり議論されていないのが実情だ。

 アプリケーション開発とシステム基盤構築のどちらが欠けても,顧客満足度の高いソリューションは提供できない。筆者らはその観点から,システム基盤を効果的に設計・開発するための実践的な方法論について研究を重ねてきた。その中核を成すのが「基盤フレームワーク」である。

 Part1でも述べられている通り,システム基盤を的確に設計することは高品質な情報システムを実現する上で欠かせない。この設計思想の下,著者らは基盤フレームワークを開発した。以下ではこの基盤フレームワークの概要と,その中から,作業手順を定めたワークフローと,設計結果の妥当性を確かめる「チェックリスト」を取り上げて解説する。

 システム基盤を設計する上で考慮すべき内容は膨大であり,しかも各々が関連し合っている。ここで示す方法論も完成型ではなく,現在も整備・拡充を続けている。すべてを紹介しきれないが,どのようなアプローチでシステム基盤を設計するべきか,参考にしてもらいたい。

非機能要件の実現が目標

 まず,システム基盤の設計・構築を進める際の基本的な考え方を示そう。システム基盤の設計・構築は,以下の3つの視点から行うことができる。第一に,どんなハードウエアやソフトウエアを利用するかという「システム・コンポーネント」の視点,第二に,それらをどのように組み合わせるかという「アーキテクチャ・パターン」の視点,第三に,情報システムがどのような品質を確保すべきかという「非機能要件」の視点である(図1)。

図1●システム基盤を設計する際に必要な3つの視点
図1●システム基盤を設計する際に必要な3つの視点
バランスの取れたシステム基盤を実現するには,「アーキテクチャ」,「構成要素(システム・コンポーネント)」,「非機能要件」という3つの視点から分析・設計することが欠かせない

 以上の中で,システム基盤を設計・構築する際に最も重要なのは「非機能要件」の視点である。非機能要件とは,「機能要件(アプリケーションが実現すべき機能やサービス)」以外の,システムが確保すべき品質を指す。具体的には,「可用性(avail-ability)」,「性能(performance)」,「拡張性(extensibility/scalability)」,「セキュリティ(security)」,「運用管理性(manageability)」の5つだ(Part1の表1)。

 情報システムがどのようなコンポーネント(機器やソフト)を利用しているか,どのようなアーキテクチャ・パターンを採用しているかといったことは,実は顧客にとって本質的な問題ではない。システムの機能が,どのようなサービスレベルで提供されているかが最も重要なのだ。

 したがってシステム基盤を設計・構築する際は,非機能要件を十分に満たすことを最終目標とすべきである。つまりシステム基盤の設計・構築とは,5つの非機能要件を満たすことを目指してシステム・コンポーネントを選択し,それを最適なアーキテクチャで組み合わせることである。その際,コストも重要な検討項目となる。

 5つの非機能要件の内容について,簡単に紹介しておこう。

 「可用性」とはサービスの提供率とも言うべき尺度である。通常,「(システムが実際に稼働した時間)/(稼働を約束した時間)」で表現する。システムが稼働しない時間には2種類ある。1つはシステムの定期メンテナンスや移行など,あらかじめ稼働しないことを約束した「計画休止時間」。通常のシステムは,メンテナンスやバージョンアップなどの目的で,あらかじめ年に1~2回,数時間ずつ計画休止時間を設定している。もう1つは,予期せぬ障害や,その修復・復旧に要する「非計画休止時間」だ。

 「性能」とは,Webシステムなどの対話型のアプリケーションならば応答時間,バッチ処理ならば単位時間当たりの処理量など,エンドユーザーにとってシステムの使い勝手に大きく影響する指標である。より高速なプロセサやネットワークを使えば,性能を向上できる。しかし,当然ながら余分なコストが必要となる。

 効果的な性能設計を実施するには,システム全体のバランスを考慮しなければならない。「プロセサは十分に速いが,ネットワークは遅い」といったような,いわゆるボトルネック部分を排除する設計が重要だ。

 筆者らの経験では,システムの稼働後,顧客との間でトラブルになる問題の代表が,この性能問題である。回避するには,設計段階で顧客から性能要件をヒアリングし,目標値について合意を得ることが欠かせない。

将来を見越した拡張性を確保

 システム資源(リソース)をどのくらい追加・増強できるか,それによって性能をどのくらい向上できるかを表すのが「拡張性」である。拡張性には,物理面と性能面という2つの側面がある。前者はサーバーで言えば筐体内のスロット数やメモリー容量,入出力スロット数など。後者は,資源を増設することによって,どのくらい性能を向上できるかの割合を示している。

 言うまでもなく,どのサーバーにも増設可能数の上限値が存在する。サーバーの選定時には,当面必要となるリソースと,将来発生し得るシステムの拡張にどれだけ対応できるかを検討する必要がある。

 このほか,ウイルス対策や不正侵入検知といった「セキュリティ」,いかに効率的かつ低コストにシステムを運用できるかを指す「運用管理性」も,欠かせない非機能要件である。

 注意しなければならないのは,非機能要件を満たす設計をする場合は,個々のシステム・コンポーネントだけを見るのではなく,システム全体を見わたして検討する必要があることだ。システム・コンポーネントを部分的に増強しても,目的とする非機能要件を満足させられるとは限らない。例えば,システムの性能はプロセサだけで決まるわけではなく,ネットワークやミドルウエア,そしてアプリケーションそのものによっても大きく左右される。システム全体を見わたす視点を忘れてはならない。