DX(デジタルトランスフォーメーション)推進コンサルティング 株式会社アイ・ティ・イノベーション

こんにちは、アイ・ティ・イノベーションの松井です。前回のメルマガから連載を開始した本ブログですが、多くの方々から反響をいただきました。ありがとうございます。さて、前回ブログはITアーキテクトという仕事に対する私の思いで締めましたが、そもそもITアーキテクトの役割とはどのようなものでしょうか。ITSS（ITスキル標準）など参考となる標準やガイドラインも世の中に広く公開されています。また、多くの企業でその役割定義に取り組まれている様子も見聞きします。私自身もITアーキテクトの役割についていろいろな方と意見交換する機会は増えています。そうしたなかで、日頃から思っていることがあります。ITアーキテクトの役割には「本質的に変わらない部分」と「環境変化に応じて変えていく部分」があるのだろう、と。今回は、ITアーキテクトの役割を考えたいと思います。

＊＊＊

本質的に変わらない部分とは、「ITアーキテクトなら当然こういう役割は果たすべきだよね」と誰もが思うような部分です。それは、ITアーキテクト自身が「時代や環境が変わっても自分はこうあり続けたい」と思う部分であるとも言えます。とは言え、なかなかITアーキテクト以外の人にはわかりづらいかもしれませんね。「ITアーキテクトって何をする人なの？」と質問されることがまだまだ多いのも、やはりそういうことのあらわれでしょう。もしこれが、「プロジェクトマネジャーって何をする人なの？」と問われたらどうでしょう。頭の中で「こういう役割の人」というだいたいのイメージが浮かぶと思います。例えば、プロジェクトマネジャーと開発エンジニアの役割が明確に異なると言われても、誰も違和感を抱きませんよね。これは、プロジェクトマネジャーが「専門職として確立された役割」と認知されているからです。ITアーキテクトもそうあるべきと私は考えます。

私の場合、その本質的な役割を「IT アーキテクト 育成ハンドブック」で学びました。これは、IPAのITスキル標準センターが人材のスキルアップに貢献する目的で作成したものです。ここでは、ITアーキテクトの役割を以下のように述べています。
・ビジネスの要求に的確に応える整合性のとれたアーキテクチャを構築すること
・要求者のビジネスの方向性に対する思いと実現性のあるITの観点をつなぎ、現実的な設計（ソリューション）に落とし込むこと

これを読んだときまさに我が意を得たりという思いでした。自分が目指しているのはこういうことができることなのだと、強く共感しました。ITアーキテクトにはシステム全体の構想力やシステム構築に必要となるITの目利き力・実践力が欠かせませんが、それらはユーザーの思いに対する理解と共感に立脚したものであるべきでしょう。

皆さんの組織でも、誰もが腹落ちするようなITアーキテクトの本質的な役割を言語化してみてはいかがでしょうか。特に、ITアーキテクト組織を主導するリーダーの方には是非とも自分の言葉で語っていただきたいと思います。組織として価値観が醸成され、ITアーキテクトがより生き生きと活躍できる、そんな場が増えていくに違いありません。

＊＊＊

環境変化に応じて変えていく部分はどうでしょう。これもプロジェクトマネジャーと比べて考えてみましょう。従来のプロジェクトマネジャーの役割は、QCDを達成するためにプロジェクトを管理することでした。これも確かに大切な役割に違いありませんが、最近はさらに新しい役割を果たすことが求められてきています。その背景にあるのが、プロジェクトに関わるステークホルダーの多様化やビジネス志向の高まりといった環境の変化です。例えば、PMIのタレントトライアングル™と言うスキルセットの考え方もそうした背景から来ています。

ITアーキテクトに関して言えば、IPAが公開しているiCD(iコンピテンシディクショナリ)のアプローチが参考になると思います。人材育成に取り組む企業がその人材のあるべき姿を描き、育成の仕組みを構築できることを目標としたもので、2015年に公開されました。iCDの特徴としては、従来のスキルありきの考え方ではなくタスク中心という点が挙げられます。従来のような「人材を定義し、その定義に沿って一人前に育ててから活用する」ではなく「必要なあるべきタスクを定義し、その実践のためのスキルとの組み合わせで役割を考える」というアプローチへの転換が求められています。長年、ITアーキテクトとして実践の場に身を置いてきた私から見ても、とても合理的な考え方だと思います。実際、iCDを使って人材育成に取り組んでいる企業は増えてきています。一方で、あるべきタスクを定義することの難しさがあります。企業の置かれた環境や組織体制、業務プロセスによって状況は異なり、それぞれの企業ごとに考えていくことが求められます。そのため、ITアーキテクト人材の育成を担当されている方々は本当に大変だと思います。

ここからは、あるべきタスクを定義する際に参考になるのではないかと思う考え方をご紹介します。図2をご覧ください。

この図は、私が理事を務めるIasa日本支部が主催するセミナー資料からの抜粋です。ここに描かれているのは、ITアーキテクトが取り組まなければならない２重のギャップです。組織が抱える問題点の多くは構造的なものであり、その解決のためにはこの２つのギャップを解消する必要があります。見方を変えると、この図はまさにITアーキテクトが活動すべき領域を表現していると言えるでしょう。あなたの組織にはどのようなギャップがありますか？そうしたギャップを解消すべく適材適所でITアーキテクトが配置され活躍できていますか？

この図の中身に少し踏み込んでみます。まず左右の軸を見てみましょう。
この軸にあるのは、ビジネス戦略とIT戦略のギャップです。EA(エンタープライズ・アーキテクチャ)で言うところの４つのアーキテクチャ領域「ビジネスー情報―アプリケーション―テクノロジー」が不一致を起こしている状態です。具体的には、デジタル技術が経営に活かされていなかったり、ITシステムがビジネスの足枷となっていたりする状況であると言えます。この軸では、ビジネスとテクノロジーの専門職が協調すべきであり、「わたし作る人」「わたし使う人」という溝を埋めることが求められます。全社横断的なワンチームで取り組む必要があります。ITアーキテクトはこの溝を埋めるキーパーソンの役割を担います。例えば、これからDX経営に取り組もうとしている組織ならば、アーキテクチャ領域「ビジネスー情報」を貫くタスクを中心にITアーキテクトを配置することを優先するかもしれません。ITシステムが足枷になっているなら「情報―アプリケーション」を対象に、疎結合アーキテクチャへの移行を意識した配置も考えられるでしょう。
また、こうした取り組みでは全社的なアーキテクチャ管理組織も必要になってくるでしょう。それについては弊社シニアコンサルタントの中山のブログ記事「アーキテクチャ・マネジメント・オフィス（ＡＭＯ）」が参考になりますので、あわせてお読みください。

もう一つの上下の軸は、開発ライフサイクル（例えば、企画構想―要件定義―設計―開発―移行）の間でのギャップです。企画したビジネス成果が、システムの導入によって本当に手に入れられているでしょうか。意図したアーキテクチャは実現できていますか。逆のケースとしては、そもそもアーキテクチャデザイン不在ということを放置していませんか。こうした状況の理由としては、ITアーキテクトが適切なタイミングで開発ライフサイクルに関与できていないことがあるのかもしれません。
ITアーキテクトの活動領域に目を向け、欠けたピースを埋めるべくあるべき役割を定義していきましょう。

＊＊＊

最後に、育成について少しだけお話しします。以下の9項目は、これからの若手がITアーキテクトとして育っていくためにはどういうことが必要かを挙げてみたものです。私がこれを書いたのは10年ほど前ですが、今も変わらないと考えています。ここで伝えたいことは、ITアーキテクトを育てるということは、個人と組織と企業が一体となって取り組まないといけないということです。個人の自助努力に任せるだけではうまくいきません。

＜ITアーキテクトを育てていくために＞
アーキテクト個人がすべきこと
(1)継続的に学び続けること、そして学んだことを業務に活かしていくこと
(2)得意分野はもちろん、それ以外にも幅広くアンテナを張り巡らせること
(3)好奇心を持ち続けること
(4)情報発信を行うこと

組織（チーム、コミュニティ）がすべきこと
(5) 情報交流やコミュニティの場を広げていくこと
(6) 議論がしやすい雰囲気を醸成していくこと

企業がすべきこと
(7) アーキテクトが活躍できる場を作っていくこと
(8) アーキテクトの経験・知見をビジネスに活かしていくこと
(9) アーキテクトを育成するためのカリキュラム・キャリアパスを確立すること

＊＊＊

次回は、アーキテクチャデザインをテーマに書いてみたいと思います。お楽しみに！