次の秋よりシステムアーキテクト試験とITストラテジスト試験が始まります。ご受験の予定はありますでしょうか。アプリケーションエンジニアとシステムアナリストに合格した経験から「自分が受けるならこうする」というところを述べてみます。

現行との対応で言えばシステムアーキテクトはアプリケーションエンジニアであり、ITストラテジストはシステムアナリストです。日本語も加えて表にしてみましょう。

システムアーキテクトとアプリケーションエンジニアの違い

まずは新試験制度のシステムアーキテクトとそれに対応する旧試験のアプリケーションエンジニアを比較してみます。旧試験では「アプリケーション」の開発を担当する「技術者」であったところが「システム」の「設計者」となりました。アプリケーションよりもシステムのほうが広い概念ですから、守備範囲が広がったことが見て取れます。また、技術者というと何でも屋さんな言葉ですがそれが「設計者」となり、守備範囲が狭まりました。

情報処理推進機構のサイトにある対象者像は以下の通りです。

＜アプリケーションエンジニア＞
情報システム開発プロジェクトにおいて、プロジェクト計画に基づいて、業務要件分析からシステム設計、プログラム開発、テストまでの一連のプロセスを担当する者

＜システムアーキテクト＞
高度IT人材として確立した専門分野をもち、ITストラテジストによる提案を受けて、情報システム又は組込みシステムの開発に必要となる要件を定義し、それを実現するためのアーキテクチャを設計し、情報システムについては開発を主導する者

アプリケーションエンジニアは誰かが作った計画に沿い、一連のプロセスを担当することが仕事でした。それがITストラテジストからの支持を受けて（おそらく場合によっては交渉を行い）システムのアーキテクチャを設計した上で、開発を主導するという仕事になります。これまではレベルの高いSEという雰囲気でしたが、設計の専門家としての役割が強調されています。

試験としての違いはシステムの方式設計や組み込み分野の問題が増えるようです。今年あたりはSaaSや仮想化を取り込んだ形の方式設計が出やすいのではないでしょうか。

ITストラテジストとシステムアナリストの違い

そして新試験制度のITストラテジストと旧試験のシステムアナリストを比較してみます。旧試験では「システム」の「分析」を専門とする人でしたが、「IT」の「戦略家」となりました。「システム」と「IT」の言葉の違いはあまり感じられませんが、「アナリスト」が「戦略家」になったところは大きな変化であると思います。アナリストというと金融アナリストや証券アナリストなど主に分析をする人という印象を受けます。それが戦略家、すなわち自ら将来を切り拓いていくような印象に変わりました。

＜システムアナリスト＞
経営戦略に基づく情報戦略の立案、システム化全体計画及び個別システム化計画の策定を行うとともに、計画立案者の立場から情報システム開発プロジェクトを支援し、その結果を評価する者

＜ITストラテジスト＞
高度IT人材として確立した専門分野をもち、企業の経営戦略に基づいて、ビジネスモデルや企業活動における特定のプロセスについて情報技術を活用して改革・高度化・最適化するための基本戦略を策定・提案・推進する者。また、組込みシステムの企画及び開発を統括し、新たな価値を実現するための基本戦略を策定・提案・推進する者

システムアナリストもITストラテジストも 経営戦略と密接な関連があることは同じです。私が感じた違いとしては、システムアナリストが

経営戦略
↓
情報戦略
↓
システム化全体計画
↓
個別システム化計画
↓
システム開発プロジェクト
↓
結果評価

のようにウォーターフォール的なのに対して、ITストラテジストでは経営戦略を実現するにあたり必要となる様々プロセスを、ITを活用してパワーアップさせることが使命である点です。その様々な業務プロセスがITに何を求めてくるかを考え、基本となる戦略を立てることがITストラテジストの役割であると言えます。経営者に対して「この経営戦略でいくならばIT施策としてこういうことがやれます。これで達成できそうですか？」という助言をしていくことが中心となり、戦略の推進はともかく各プロジェクトの推進まで干渉していくという性格は薄められました。

試験としての違いは、こちらもシステムアーキテクト試験と同様に組み込み系システムが加わっていることと、経営サイドの知識がより多く問われるようです。今年あたりはiPhoneによるCRMやSFAの強化などが出やすいのではないでしょうか。

システムアーキテクトとITストラテジストの違い

では最後にシステムアーキテクトとITストラテジストの違いを見てみます。 ITストラテジストは経営戦略と密接に関係するシステム戦略を考案します。

例えば最近のキーワードにSOAやBPMがありました。サービス志向のシステム設計により事業の統合や切り離しの際にシステムが重荷とならぬよう、サービスインターフェースのオープン化、標準化を進めていくというものです。

事業戦略が、円高とアメリカ経済の冷え込みを逆手に取って自社の製品ラインナップ上のウィークポイントを買収によって克服していくというところにあるならば、それを支えるIT戦略としては社内システムのサービス化を進めることで買収にかかる時間的なオーバーヘッドを短縮できることが望ましいです。

となるとITストラテジストとしてはそれが実現できるのかどうか、また費用や期間はどうなのかをざっくりレベルで確認しておかなくてはなりません。そこでシステムアーキテクトとの相談です。例えば人事給与系のシステムはパッケージなのですぐにでも対応でき、経理系のシステムは10年以上前にHOSTでスクラッチ開発したものなので難しい、というようなことがわかってきます。

ここでITストラテジストにより経理系のシステムはオープン化しましょう、というようなIT戦略が立ってきます。そしてシステムアーキテクトに「やれる？」という相談が持ちかけられます。システムアーキテクトはそれを実現するための要件を定義して方式を決め、開発を担当します。ミドルウェアを介してHOSTをそのままにするとか、スクラッチでオープン化するとか、似たようなパッケージを使うとか、H/Wベンダーによるレガシーシステム移行ソリューションを使う、などの方法を検討します。

また、この例では単なるオープン化ではなく買収戦略を支えるためのSOA対応ということになるので、スケーラビリティについても考慮しておく必要が出てくるでしょう。となると仮想化技術あたりを持ってきてシステムの規模が大きく変動してもいいようにしておく、というようなことまで考えていく必要がでてきます。IT戦略の中で仮想化をSOA推進のための重要な武器と位置づけるならば、それをシステムアーキテクトが噛み砕きます。例えば経理システムで先行して仮想化技術を導入し、その評価を行った上で全社的に展開するかどうか決める、というようなやり方となるでしょう。

システムアナリストとアプリケーションエンジニアの時代からなかなか両者の違いがわかりづらいですが、具体的に書くと上のような形になると思います。ITは魔法ではありませんので、ハードの限界にせよ、情報理論の限界にせよ、実現できない機能というものがたくさんあります。

もちろんスペシャルなITストラテジストが10年くらい先までの業界動向と技術進歩を予測して真っ白な紙に無駄のない戦略をさらさらと書くことができたら上のような調整は不要でしょう。しかしそんなわけがありません。過去の資産もありますし、新しい資産でも技術動向の読み違えでゴミと化すこともあります。そういった困ったところを処理していくのが現実の仕事の大半でしょうし、これまでの午後試験の問題もほとんどは「困ったところを直す」でした。

よってITストラテジストとシステムアーキテクトは、今あるシステムを間においてどうやったらよくなるかについてそれぞれの立場からの意見を言い合う関係になります。

すなわち、事業戦略に基づいてIT戦略を策定する際に「システムがこうなれば事業戦略が遂行できるだろう」という理想論から入るのがITストラテジストであり、「今のシステムをこうすれば事業戦略が遂行できますよ」という現実論から入るのがシステムアーキテクトだと思っておけば大きな間違いはないでしょう。