» 【137号】ビジネスアーキテクト

株式会社データ総研 データ総研のオンサイト教育
製品案内 DMBOK ITコンサルティングサービス ITコンサルティング事例 紹介セミナー 教育コース 技術情報 DRIブログ 会社概要
技術情報
【137号】ビジネスアーキテクト

■アーキテクトのニーズ
EA(Enterprise Architecture)が引き金になったのでしょうか、このところ、
ITアーキテクト、データアーキテクトなど、アーキテクトを標榜する名刺を見
かけることが多くなりました。

元来は、建築の設計者を指したのでしょうが、建築に限らず、設計者一般
に用いられるようになったようです。デザイナーも設計者なのでしょうが、全
体骨格の構造に関する設計をアーキテクトが担当し、内装相当の詳細設計
をデザイナーが担当するかに見えます。
情報システムはコンピュータの登場によって生まれたという解釈が多いように
見えますが、私は「情報システムは江戸時代からあった。顧客、商品、受注、
納品、売掛、回収など、今とさほど変わらずあった。ただ和紙と筆とそろばん
などツールが違うだけだった」と考えます。したがって、当初のシステム化−
正確には機械化−は、アーキテクチャはそのままに、ツールをコンピュータ系
に置き換えるものだったと思います。
受注、生産、経理などの個別アプリケーションは、こうして機械化されスピー
ドアップされていったわけですが、それが却ってアプリケーション横断のスコー
プに歪をもたらしたかに見えます。従来の人間系を前提にしたアーキテクチャ
を、DBやネットワークを前提としたアーキテクチャに変革しなければならな
くなったのでしょう。
デザイナーは、ある与えられたスコープの中で設計することになりますが、アー
キテクトは制約の少ない空間の中に自分でいくつものスコープを設定し、その
相互関係を最適化することになります。最適化といっても、数値化は難しいの
で担当者の総合的判断になります。従来のアプリケーションシステムのスコー
プは、納期とスポンサーの守備範囲とお金によって、決められたケースが多かっ
たように見えます。そのスポンサーの守備範囲は、その力量や人間関係によっ
ても決まります。したがってスコープには過大、過小、重複、欠落などがあり
ます。また最近のようにM&Aが行われますと、類似のレガシーシステムがい
くつも生き残る可能性があります。個別アプリケーション担当者がいくらがん
ばっても、ここに手をつけなければいつまでも問題が残ります。保守コストが
予算の90%を占めるとか、アジャイルに環境変化に対応できないなど、アー
キテクチャは最適から程遠くなっていますので、アーキテクチャ設計を担当す
べきアーキテクトが求められると言うことになるのでしょう。
アプリケーションが旧式のプラットフォームと密着しているため、使いにくく
コストが割高、そこで「仮想化などの最新技術を用いて、ハード・ソフトを整
理してコストダウンやスピードアップを図る」といった、ITアーキテクトの
テーマもあるわけですが、ここでは以下ビジネスアーキテクトに絞って話を進
めたいと思います。
このビジネスアーキテクトの主要成果物は何でしょうか。どのような資質・技
量を持ち、どのように調達すればよいのでしょうか。
■ビジネスアーキテクトの主要成果物
主要成果物は、都市計画のための地図や建築物のための平面図相当の、企業全
体のビジネスの鳥瞰図であると考えます。組織図やシステム関連図では不十分
で、やはり個人差の出ないデータモデル図を中心とするものと考えます。これ
は「企業の実体はデータによって記述される。企業活動はこのデータの変化で
ある」と考えるからです。全社を対象にする場合、個別アプリケーションに関
するいわばローレベルの図と、全社のアプリケーション間コミュニケーション
に重点を置いたハイレベルの図を、分けるのが有効と考えます。ローレベルは
担当SEに任せられる部分が多いので、ビジネスアーキテクトとしてはハイレ
ベルに多くかかわることになります。
この成果物を作るときの一番難しい問題は、個別アプリケーションのスコープ
(業務ドメインと呼ぶこともある)をどう設定すべきかです。私は、これは製
品と市場と機能(営業、生産、経理、人事など)の3つから決まるといってい
ますが、目下ガイドはなく、ビジネスアーキテクトの判断に依存するところ大、
のテーマです。小さすぎると全体の数が増えハイレベルの負荷が増えます。ま
た大きすぎるとローレベルの関係者が多くなり、コミュニケーション効率が悪
くなり、メンテが難しくなります。その証拠に最近ERPベンダーはSOAを
導入してスコープを小さくし、アジャイルな変化に対応しようとしています。
■ビジネスアーキテクトの資質・技量と調達
ビジネスアーキテクトの責務は、ビジネスニーズの変化に迅速に対応して、ビ
ジネスとITのギャップを縮め、継続的な全体最適を実現することです。この
ため企業のビジョン・ミッション・経営目標を踏まえ、市場の動向を察知して、
ビジネスアーキテクチャをメンテし続けなければなりません。このためには、
システムを構成する部品を、独立性の高いもの−サービスをベースに部品化を
行うSOAはこの意味では健全−とし、かつ変化しやすいものと、変化しにく
いものとに分別し、変化しやすいものは随時取り替えるアプローチを採らなけ
ればなりません。このためビジネスアーキテクトは、SIer−将来的にはS
aaSer−と情報要求に関する折衝ができる必要はありますが、ITよりも
ビジネスよりの知識を持ち、多くの関係者に理解を得るためのコミュニケーシ
ョン能力を持たなければなりません。企業組織の設計にかかわる業務であり、
将来IT抜きの経営はありえませんから、将来の経営者は、このようなビジネ
スアーキテクトをキャリアパスとして生まれるのではないかと思われます。
このような人材を「作ってなんぼ」のSIerに求めるのは、見当違いと思わ
れます。経営の中枢にかかわりますから、やはり自社の中に求めなければなり
ません。「リストラで人材が払底した」といっても丸投げは不可です。「それ
ならこれから育てる」という覚悟が必要だと考えます。ITに強い必要はあり
ませんから、広くユーザ部門からも候補者を見つけることができます。自社の
ビジネス全般をまだ十分知らなくても良いのですが、これに強い興味があるこ
とが必要でしょう。
本や座学では時間がかかりますので、やはり経験のあるコンサルタントの支援
を受けながら、適切な「全社ビジネスアーキテクチャ」に関するプロジェクト
を遂行するのが、ベストかと思われます。この場合おそらくPMとして参加す
ることになると思われますが、ビジネスアーキテクトは、恒常的機能ですから、
次からはPM育成係りの役割を果たしつつも、ビジネスアーキテクチャの整備
に専念していく必要があると思われます。
ビジネスアーキテクトのかかわる最も重要なドキュメントは、「全社アプリケー
ション横断のハイレベルのデータモデル図」と述べましたが、これを作るため
の素材、アプリケーション間でやり取りされるハイレベルメッセージ(トラン
ザクション)を図示する業務フロー図−弊社のIPFチャート相当−が、デー
タモデル図の動的な側面を補うという意味で重要です。動的ですから、静的な
データモデル図よりは変化しやすいのですが、ハイレベルは変化が少ないので、
有効と思われます。また、レガシーやパッケージを活用するとき、SOAの対
象になるサービスは主としてここに登場するという意味でも重要です。
以上社内に限定した考察を行いましたが、社外すなわちB2Bにおいても、最
適の役割分担の課題があり、社内での経験を踏まえたビジネスアーキテクトの
活躍舞台が広がっています。またSIerやSaaSerにおいては、実装や
保守局面でこれらビジネスアーキテクトを支援する役割が拡大していくものと
思われます。データ総研としては、このようなビジネスアーキテクトの育成や、
その支援体制を、今後の非常に重要な課題として取り組んでいきたいと考えて
います。