ITアーキテクチャ設計の反復と吟味：ITアーキテクチャ構築の勘所（6）

前回「製品／技術の適用と実現性の検証」までに、一通りのITアーキテクチャ設計ステップを紹介したが、それぞれのステップは独立して1回ずつ行えばよいというわけではない。前のステップの設計内容を受け継いで後続の設計を行い、設計結果を吟味して、必要に応じて前のステップの設計を見直すといった反復が、良いアーキテクチャ設計には欠かせない。

[河野紀昭（日本IBM ICP-エクゼクティブＩ/Ｔアーキテクト），＠IT]

　ITアーキテクチャ設計は「要件の洗い出し」「機能的アーキテクチャ設計」「配置設計」「製品／技術の適用」といった流れで行われるが、この流れは1回実施したら終わりというわけではない。製品や技術は、本来、ビジネス要求から一連の設計ステップを経て選択されるものであるが、採用技術によっては、適切な配置設計が変わるケースもある。このような場合には、前のステップに戻って、アーキテクチャ設計を見直すことが必要である。

　また、いったん、ITアーキテクチャが完成しても、さまざまな観点でアーキテクチャ設計全体を見直して吟味する過程は欠かせない。ここで重要なのは、前のステップがどのように後続ステップにつながっているかを明らかにするトレーサビリティの考え方だ。トレーサビリティのある設計では、どのビジネス要件がどのアーキテクチャ要件につながり、そこから、どのように考えてアーキテクチャ設計したか、文書化して関連性を明確にしておく。

図1 トレーサビリティのある設計

　トレーサビリティのある設計ができていると、ITアーキテクチャの妥当性を吟味できるし、ビジネス・ニーズが変化した際や、利用可能なテクノロジが変化した場合に、ITアーキテクチャを変更すべきかどうかの判断を客観的に行うことができる。

勘所：ITアーキテクチャ設計を反復せよ。このためにトレーサビリティを重視せよ

　ITアーキテクチャを吟味するうえで重要なポイントはなんだろうか。

　まず、そもそもITアーキテクトの仕事は、ビジネスの要求にIT技術を用いて応えるための設計をすることであるので、ITアーキテクチャがビジネス・ニーズにマッチしていることが一番重要であろう。

勘所：ビジネス・ニーズにマッチしたITアーキテクチャにせよ

　さまざまなビジネス・ニーズやシステム要件は、ITアーキテクチャ設計上、相反することがある。例えば、次のような要件はあちらが立てばこちらが立たずということになりやすい。

• 高速大容量で高い信頼性←→安い構築コスト
• 誰でも自由に簡単に使える←→高いセキュリティ
• 開発が容易←→保守が容易

　ITアーキテクトとしては、相反するシステム要件を考慮して、ビジネス上の優先度と照らし合わせたうえ、できるだけバランスの取れた実現法を取るとよい。1つの要件を100％満たすために、ほかの要件の実現度が0％になるよりは、それぞれの要件を80％ずつ満たす妥協案が良いことが多いだろう。

勘所：バランスの取れたITアーキテクチャにせよ

　設計者が腕に覚えがある場合、システム全体のアーキテクチャを全面的に新しい思想に基づいた斬新なものにしたいと考えることもあるだろう。先進的な設計が悪いわけではないが、すべての要素を斬新な設計とすると、技術リスクや実装コストが増えてしまう。

　筆者は、ビジネス要求から見て、本当に必要なところに新しい設計を実施する一方で、ビジネス要求上は「普通で良い」ところには、できるだけ、一般的で実証された設計を適用するようにしている。先進的なシステムの場合でも、実証済みの設計と新しい思想の採用割合は8対2程度だろうか。つまり、8割の実証済みの設計のうえに、2割の先進性を構築するわけである。

勘所：ITアーキテクチャ設計にも8:2の法則がある

　 このようにして、設計者が良いと信じるITアーキテクチャが1つできたら、そこで満足して良いのだろうか。ベストと信じる設計をしても、費用とか運用性の面で何らかの短所が残る場合があるだろう。そこで重要なのが代替案の検討である。

　代替策の検討としては、トポロジーや採用技術を変えて再度アーキテクチャ設計を行い、欠点を解消できないか検討するとよい。

　アーキテクチャ案が複数できたところで、ビジネス・ニーズに対応した複数の評価項目を設けて比較検討する。このようにすれば、アーキテクチャ案を客観的に評価できるので、仮に最初の案に落ち着いたとしても、アーキテクチャ採用理由を明確化することができる。

勘所：代替案を比較検討せよ

　最後にITアーキテクチャ設計上、ITアーキテクトが忘れてはならないことを1つ挙げよといわれたら、筆者は「気配り」を挙げたい ITアーキテクチャが実装されシステムが利用されるときの次のような状況を想定してみよう（カッコ内は担当者の気持ち）。

• 利用者が初めてシステムを使ったとき（まだ使い慣れていない）
• 利用者がシステムを使って急いで仕事をしたいとき（まどろっこしい操作は嫌だ）
• システム障害が起こってシステム担当者がリカバリを行うとき（パニックになっているかもしれない）
• 開発者がアプリケーション機能の拡張を行うとき（既存機能を壊したくない）
• 利用者が増え、ハードウェアを増強するとき（ハードを増強した分だけ性能が上がってほしい）

　このようなときに、システムを利用する人、運営する人ができるだけ困らないように、あらかじめITアーキテクチャ上、配慮をしておくことが大切である。このため、ITアーキテクトは、システムがどのように使われるのか、常に想定してアーキテクチャを設計する気配りを忘れないようにしたい。

勘所：利用局面を想定し、気配りを忘れずに

　以上、本連載では、アーキテクチャ設計を行う時の基本的な勘所を紹介してきた。いずれの「勘所」も経験から得たいわゆる生きた知識である。質の高いアーキテクチャを構築する助けとなれば幸いである。

「ITアーキテクチャ構築の勘所」バックナンバー

• ITアーキテクチャ設計の反復と吟味
• 製品／技術の適用と実現性の検証
• 配置設計の手順と注意点
• 第2回 アーキテクチャ要件の洗い出し
• 第1回 アーキテクチャ設計の手順