top of page
執筆者の写真松井 淳

ITアーキテクトの新たな役割

 ITABoKは、ITアーキテクトが備えるべきスキル要件を網羅した知識体系として、様々な専門領域を対象としております。よって、独力で学習されている方が、全ての内容を理解することにはハードルがあると思われます。また、ITABoKに書かれているトピックを他人はどう理解し、実践しているのかを知ることは非常に有意義と考えます。

 こうした点を踏まえ、Iasa日本支部理事が持ち回りで、ITABoKの各章を解説していきます。また、単なる情報発信に終わるのではなく、それをきっかけに皆様からコメント・意見をいただき、活発な議論に広げられればと思います。気軽にフィードバックください。

 1回目は、ITABoKの冒頭から<1.ITABoK>を取り上げます。<1.ITABoK>では、「1.1なぜITABoKか?」「1.2アーキテクチャとは?」「1.3アーキテクチャの価値」という章立てで、ITABoKの目的や位置づけ、アーキテクチャやアーキテクトに対するIasaの定義が述べられています。これらと絡めて、アーキテクトの役割定義というテーマにも触れてみたいと考えています。

 

■ ITABoKの目的


 ITABoKに書かれている内容は、大きく分類すると次の3つがあります。

  • ITアーキテクトとしての専門職の定義

  • ITアーキテクトの活用とエンゲージメント

  • キャリア・パス

 この中でも特に、「専門職の定義」(スキルとケイパビリティの記述)に相当のボリュームが割かれています。これは、Iasaが「共通の知識体系と言語を創出し、ITアーキテクトの専門職を正式なものとする(註1)」ことをゴールとしており、ITABoKをプロセスや方法論の標準ではなく人々のフレームワークと位置づけていることによります(註2)。よって、ITABoKはITアーキテクトの育成に焦点をあてて書かれています。


 また、ITABoKの表現自体は記述的で、特定の価値観や思想を押し付けていません。これは、十分なスキルをもつITアーキテクトの裁量を優先しているからです(註3)。そのため、ITABoKをどう活用すべきか戸惑われる方がいるかもしれません。一方で、効果的に活用されている方もいるでしょう。ここに、実践を共有することの重要性があります。


 ITABoKの存在意義は、「より良い実践の検討のための共通言語を提供する」という点にあると私は思います。ITABoKを共通言語とし、議論と実践を重ねて共有することで、ITアーキテクチャに対する私たちの知見やスキルを、一層高めていくことができるでしょう。

 では、ITアーキテクトの役割とはどのようなものなのでしょうか。

 

■ IasaのITアーキテクチャ/ITアーキテクトの定義


 Iasaは、ITアーキテクチャを「テクノロジー戦略の適用を通じて得られるビジネス、組織、クライアントによる利益の獲得の実践」「価値のあるテクノロジー戦略のデザインとその実現のアート(技能)、もしくはサイエンス(註4)」と定義しています。Wikipediaによるとアーキテクチャには「建築学、建築術、構造」といった意味がありますが、このうち建築術のニュアンスに近いと思われます。構造(モノ)としてよりも、専門職による術(コト)として定義している点がIasaらしいと感じます。


 ITアーキテクトの定義を見てみましょう。Iasaは、ITアーキテクトの役割を「ビジネスのテクノロジー戦略家(註5)」と定義しています。多くの方にとってこれは抽象的な表現かもしれません。ですので、ITアーキテクトの役割についてもう少し考察してみましょう。

 

■ これからのITアーキテクトの役割


 ITアーキテクトに何を期待するかは組織によって様々でしょう。皆さんの組織・プロジェクトではステークホルダー間で、ITアーキテクトの役割が共有されているでしょうか。例えば、私があるITプロジェクトにソリューション・アーキテクトとして参画した際の、ITアーキテクトの役割は以下の通りでした。

  1. お客様が抱える課題を理解して、あるべきITシステムの全体像を構想する

  2. お客様が求める品質要求を満たす、適切なIT技術/製品を選定する

  3. 開発全体を統制し、プロジェクトマネジャーを技術面で支援する

 ここにあげた役割はIPAのシステム・アーキテクトに近いものです。多くの組織・プロジェクトでもこれと似た役割かもしれません。ITアーキテクトがこうした役割を果たし続けていくことの重要性は、今後も変わらないと思います。同時に、私は次の3つの理由から、求められる役割の広がりを感じています。


・アーキテクチャデザイン対象の変容


 ITの世界では、もともとアーキテクチャという言葉は、IBMがSystem/360の設計思想を表現するために使ったのが始まりだそうです。それがITシステムの設計思想にも使われ、今やビジネスの視点でもこの言葉が使われるようになりました。変化の時代といわれる昨今、アーキテクチャデザインに関する多くの課題は、ビジネス視点に関わるものとなってきています。ITアーキテクトは、アーキテクチャデザインによって課題を解決する専門職です。よって、IT視点にとどまらずビジネス視点でアーキテクチャ対象を捉え、デザインできることの重要性が増してきています。


・アジャイルへの対応


 私は自身の経験上からも、組織やITの変革を成功させるにはアーキテクチャ活動へ十分なリソースと時間をかけることが重要と考えています。大規模で複雑な場合は、特にこのことが顕著です。その一方で、テクノロジー視点、ビジネス視点のいづれにおいても、アジャイルであることが求められてきています。こうしたアジャイルへの対応においてアーキテクチャ活動が、オーバーヘッドとみなされることがあるのも事実です。ITアーキテクトの役割を果たしながらも、組織のアジリティをどう高めていくか。大きなチャレンジですが、テクノロジーの目利きとしての専門知識と、ステークホルダーへの影響力を兼ね備えたITアーキテクトに期待される役割と考えます。


・アーキテクチャスキルを備えるべき人材の広がり


 ITABoKに書かれているスキルは、ITアーキテクト専門職だけが備えておれば十分でしょうか?私はそう思いません。アーキテクチャはあらゆるステークホルダーの協調によって作り上げていくものです。よって、アーキテクチャに関わる全ての人が、ITABoKに書かれているスキルを理解することが望ましいと考えます。特に、Iasaの5つの柱が重要です。そのためには、ITアーキテクトは専門職として自らのスキルを高めることはもちろん、組織の基本スキルとして啓蒙していく「伝道師(エバンジェリスト)」の役割を担っていくことが求められます。

 

 ITアーキテクトに求められる新たな役割に思いを馳せた時、私自身は「ビジネスのテクノロジー戦略家」というIasaの定義に共感できるように感じます。皆さんはいかがですか。


 よろしければ、Iasaの定義に対するご意見・ご感想や、皆さんの組織でのITアーキテクトの役割定義についてお聞かせください。一緒に議論していきましょう。

 

註)

  1. ITABoK Version2 日本語訳版、「1.2 アーキテクチャとは?」P.18

  2. ITABoK Version2 日本語訳版、「1.1 なぜITABoKか?」P.11

  3. ITABoK Version2 日本語訳版、「1.1 なぜITABoKか?」P.11

  4. ITABoK Version2 日本語訳版、「1.2 アーキテクチャとは?」P.10

  5. ITABoK Version2 日本語訳版、「1.2 アーキテクチャとは?」P.18









 





 


 





以上


 

引用などがある場合は、下記に入れてください。





閲覧数:11回0件のコメント

Comments


Commenting has been turned off.
bottom of page