2006年7月,IPA(情報処理推進機構)のITスキル標準センターは,ITアーキテクトの活動プロセスやスキル体系を報告書にまとめて公開した。内容は,約2年間にわたって活動してきたプロフェッショナル・コミュニティ(ITアーキテクト)注1がまとめた成果物であり,大きく「ITアーキテクトの活動プロセス」と,ITスキル標準(ITSS)v2に盛り込まれた「ITアーキテクトの専門分野とスキル体系」に分かれる。ここからは,これらを基に説明する。

 実は,ITアーキテクトが開発プロジェクトに参加しない例はよくある。つまり,ITアーキテクトが存在しなくても,システムは出来上がる。では,IT アーキテクトの存在意義は何か。今回の報告書ではまずその点を明らかにした。具体的には「要求者と設計者の橋渡し役」と位置づけている(図1)。

図1●ITアーキテクトの仕事の流れ(活動プロセス)
図1●ITアーキテクトの仕事の流れ(活動プロセス)
ITアーキテクトは,要求者からの要求に基づいてシステム要件とアーキテクチャを策定し,それを設計者に伝達する。作業は大きく,要件定義で実施する「要求モデリング」と基本設計で実施する「アーキテクチャ設計」がある
[画像のクリックで拡大表示]

 ITアーキテクトの定義は次の通りである。「ITアーキテクトとは,ITアーキテクチャ注2を作成し,その成果物と効果に責任を持つ専門職である。ビジネス領域での経営戦略や実現するビジネスプロセスの検討結果を入力にしてITアーキテクチャを設計し,成果物としてITアーキテクチャの設計書を出力する」──。

 補足すると,ITアーキテクトが情報を受け取るのは「要求者」からであり,ITアーキテクトが情報を渡す先は「設計者」である。要求者とは,利用者や経営企画担当者,情報システム担当者,コンサルタントなど様々だ。設計者とは,一般にSEのことを指す。

要求者の思いを妥当な要件に

 要求者と設計者の橋渡し役となるITアーキテクトが取り組む活動プロセスは,大きく二つのフェーズがあり,その中に八つのステップがある(表1)。二つのフェーズとは,要件定義で実施する「要求モデリング」と,基本設計で実施する「アーキテクチャ設計」だ。

表1●活動プロセスで実施する八つのステップ
表1●活動プロセスで実施する八つのステップ
[画像のクリックで拡大表示]

 要求モデリングでは,(1)ビジネスシステム概要の確認,(2)要求獲得と分析,(3)アーキテクチャ要件の再構成──という三つのステップを踏む。ITアーキテクトが最初にやるべき活動は,要求者の指示を受けて,要求の枠組みを確認すること(1)。要求の枠組みは,情報システムだけにとどまらない。手作業やコンピュータ以外の機械も含む(すべてを含めてビジネスシステムと呼ぶ)。次に,ビジネスシステムに関与する様々な要求者にヒアリングし,詳細な要求を引き出して分類および整理する(2)。要求を整理したら,システムに実装すべき要件(機能要件および非機能要件)を整理する(3)。ここまでが,要求モデリングの活動プロセスである。

 「要求者は一般に,要件ではなく“こういうシステムを作りたい”という思いを要求として伝える」。こう話すのは,ITアーキテクトとして主に要求モデリングを手がける日立製作所の石井裕二氏(ITソリューション部主任技師)だ。「ITアーキテクトがその思いを正しい要件へと再整理しなければ,矛盾が生じて手戻りを招いたり,保守性や効率性が損なわれたりする」(石井氏)と指摘する。

 今回の報告書では「要求定義」と「要件定義」を明確に区別している点も注目すべきだろう。要求定義は,ビジネスや現行システムの課題を明らかにし,あるべき姿を示した“思い”を列挙するものと位置づける。実施に当たっては,ビジネス環境をはじめ,競合企業や取引先,基盤製品や関連技術などの動向に基づいて定義する。主な作成者は,先に挙げた「要求者」だ。

 一方の要件定義は,要求定義の内容をシステム全体(または企業全体)の因果関係をとらえながら再定義したもの,と定義する。技術的な観点から要求の妥当性や現実性を評価し,システムに実装すべき「要件」を整理する。この要件定義を実施するのが,「ITアーキテクト」というわけだ。

構造と効果に責任を持つ

 システムに実装すべき要件を定義したら,次に行うのがアーキテクチャ設計である。アーキテクチャ設計では,(4)コンポーネント構造の設計,(5)要求の充足評価,(6)標準化と再利用,(7)要求の合意形成,(8)技術移管と指導──という五つのステップを踏む。

 手順としては,まず要求モデリングで明らかにした要件(機能要件と非機能要件)に基づいて,プログラムやデータ,ユーザー・インタフェース,およびハードウエアやミドルウエア,フレームワークなどのプラットフォームの構造と実装方式(アーキテクチャ)を決定する((4))。数多くのアーキテクチャ設計を手がけてきた野村総合研究所の武田則幸氏(システム技術二部上級テクニカルエンジニア)は「ここで定義するのはアーキテクチャとしての概念的なモデル。詳細なモデルはITスペシャリストやSEが担当する」と語る。ITアーキテクトとして重要な役割は「早期にプロトタイプなどを作って,製品や技術を徹底的に検証すること」(武田氏)だ。

 次に,(5)要求の充足評価と,(6)標準化と再利用を実施する。要求の充足評価では,構築すべきシステムが要求を満たすか否かを判断できる評価項目と測定法を検討する。ITアーキテクトは,構築したシステムの効果にも責任を持つ必要があるからだ。一方の標準化と再利用では,他のプロジェクトの設計成果やシステム資産を導入して開発を効率化するための計画を立案。ステップ(5)と(6)の結果は,必要に応じて(4)のアーキテクチャに反映する。

 アーキテクチャを設計したら,満たすべき品質などに関して,要求者に説明して合意形成する(7)。その上で,設計者に対して自身が設計したアーキテクチャの考え方や注意点などを伝える(8)。その後,個別の設計の中で出てきた全体に影響を及ぼす要素はアーキテクチャに反映する。