Iasa日本支部では、これまで14回にわたり情報提供の一環としてコラムを配信してきました。今回からは、多くの皆様からの「米国本部のコンテンツを翻訳紹介してほしい」という声に応えるため、本部コンテンツを取り上げていきたいと思います。
Iasa米国本部はIasa Globalとしてホームページを開設しており、そこで多様なコンテンツを公開しています(註1)。コンテンツとして公開されているものは、カンファレンスの講演スライド、有識者へのインタビュー動画、技術記事やエッセイ等と多種多様です。
初回となる今回は、IasaのThought Leader（思索的リーダー）でもあるニック・ロザンスキー氏のインタビュー記事(註2)を取り上げます。彼は世界的に著名なアーキテクトであるとともに、日本語訳として出版されている「ソフトウェアシステムアーキテクチャ構築の原理」の著者でもあるので、ご存じの方は多いでしょう。
本稿はインタビュー内容を翻訳したものです。世界的な思索的リーダーが考えていることを少しでもお伝えできればと思います。
（インタビュー始まり）
■ あなたとあなたの仕事について教えてください
私の名前はニック・ロザンスキーです。この20年ほどアーキテクトとして働いています。
その長いバックロググラウンドには、1980年代半ばに開発者としてITの仕事を始めたことがあります。私は開発者として、（もちろん）設計者または要件アナリストとして、少しばかりプロジェクト管理の仕事をしてきましたし、アーキテクトとして約20年間働いてきました。
私がアーキテクトになることを決心したのはIT部門で出世し続けたかったからですが、多くの同僚みたいにマネジメント職志向ではいたくありませんでした。私の技術のバックグラウンドには、コンピューター科学の修士号とMSC（Master of Science）があります。
私はさまざまなテスト技術に取り組んできましたが、小さなシステムだけでなく大きなシステムや、企業規模のシステムで仕事をしてきました。ですので、専門家というよりゼネラリストです。数多くのことを少しずつ知っているといった感じです。まぁ、より多くのことを知っている領域が1つか2つありますが、いわゆる専門家ではありませんね。
■ 最初にアーキテクチャについて考え始めたのはいつですか？
1990年代後半、Sybaseプロフェッショナルサービスで働くことができたのは幸運でした。当時、SybaseとOracleでDBMS市場全体の約50%を占めていました。Sybaseには大規模なプロフェッショナルサービス組織があり、その中にアーキテクチャプログラムがありました。このプログラムには、アーキテクトのトレーニングや、アーキテクチャ関連の作業に使用できるさまざまな資料が含まれていました。
私はどういったキャリアに進むべきか考えていた頃、自身の仕事においてはテクノロジー的な要素に重きを置き続けたいと思っていたので、同僚のほとんどがプロジェクト管理に従事していましたがそれをしたくありませんでした。そこで、Sybaseを使用しているアーキテクチャプログラムのことを聞いたときそれに飛びつきました。そして私はSybaseの認定アーキテクトになりました。
Sybaseで取り組んだ仕事の多くには、アーキテクチャ的な側面がありました。今にして思えばアーキテクトと必ずしも言えるものではなかったかもしれませんが、システムの主要なコンポーネントがどのように連携しているか、そしてもちろんSybase技術を使ってクライアントの問題を解決するにはどうすればよいか、といった大きな概念を理解しました。
■ ベンダーに所属するアーキテクトの倫理的側面をどうお考えですか？
それは非常に興味深い質問です。それに対する唯一の答えは、あなたが信じている製品のベンダーで働いているということだと思います。Sybase製品は非常に強力な製品セットでデータベースが非常に強力であり、他の関連するテクノロジーも強力だったため、Sybaseをソリューションとして顧客に推奨することについて何の懸念もありませんでした。もし、あなたが信じていないことを推奨するようにプレッシャーをかけられているなら、それを跳ね返さなければなりませんが、実際にはそれはとても難しいことですね。そのベンダーがあなたの日々の賃金を支払っているのですから、それに従う必要があります。
そう、それは興味深い質問です。もし自分が推薦している製品を信じていないのだとしたら、別の誰かのために働かなければならないのだろうと思います。
■ 専門家としてのアーキテクトとはどの様な人とお考えでしょうか？
それは私はいつもこの質問を恐れています。しっくりくる答えを出すのはとても難しいです。外科医とは何か、エンジニアとは何かと尋ねられたらその質問に答えることができるでしょう。アーキテクトとしてそれをするのはとても難しいです。
システムのアーキテクチャは何か、という問いに対しての形式的な答えはあります。「システムを構成する要素とそれらの間の相互作用と情報の流れ」です。ほとんどの場で使われている形式的な定義ですが、人々が共感できるようなものではありませんね。
アーキテクトとは何か？アーキテクトとは、白紙の状態からシステムのアーキテクチャの定義をする人です。これも人の心に響く定義ではありませんね。外科医でしたら「病気を治し、死を免れるための手術を誰かの心臓に対して行います」と言えるわけですが、アーキテクトではそのようにはいきません。私がよくやるのは、“私がしていること”や“なぜ私がしていることが役立つのか”を説明し、最終的にアーキテクトとは何かを人々が理解してくれることを願うことです。
■ では、何をしていて、なぜそれが役立つとお考えですか？
アーキテクトは何をするのか？アーキテクトはごく初期の段階で関わっています。ここでは、ソリューション・アーキテクチャに焦点を当てます。必要ならば、エンタープライズ・アーキテクチャについても説明します。
アーキテクトはプロジェクトのごく初期の段階に関与しており、また関与すべきです。初期段階では問題を抱えている上級の利害関係者がいます。解決する必要があるビジネス上の問題があります。彼らはそのソリューションがどのように見えるかについての考えを持っているかもしれません。アーキテクトが守らねばならない制約があるかもしれません。
私たちはMicrosoft WindowsやSAPを使用しています。それが何であれ、あなたができることを制限します。また、ソリューションがどのようなものになるかについてアイデアを持っているかもしれません。しかし、これらのアイデアは検証されておらずステークホルダーが利用できる状況にありません。アーキテクトが行うことはそこに到達することです。
利害関係者を特定します。ソリューションに対する彼らの関心ごとを特定します。利害関係者と協力し、プロセスへの参加を確実にするために何が必要か理解してもらいます。彼らの要求を確実に把握していることを確認し、ソリューションに向けて動き始めます。大きなホワイトボードを使って、ホワイトボードに枠や線を描き、最終的にはそれをソリューション・アーキテクチャにするのです。
しかしこれは問題の半分に過ぎません。すべての利害関係者に説明する必要があるからです。彼らがそれを理解し受け入れたことを確認してください。もちろん、それは反復的なプロセスです。なぜならあなたが知らなかったことを発見したり、あるいは利害関係者の1人がその方法で受け入れてはならないといったことを発言することもあるからです。もう一度戻って周りを見回し、最終的にはシステムのアーキテクチャが合意され、開発者や他の人に引き渡すことができるレベルまで文書化されるでしょう。これは、延々と続くアーキテクトの道です。
■ アーキテクチャが継続的な開発作業としたならば、それにどのように対応しますか？
あなたの質問の意図に全く同意します。実際には、他の誰かが何かを始める前に、ある程度のアーキテクチャの基礎を作る必要があります。
ですから、少なくとも概要レベルのソリューション・アーキテクチャの骨組みのようなものを設計する必要があります。その中に主要な要素を含めます。そうしないと意味をなさないものをコーディングしてしまうからです。開発者はそれを使って作業を開始することができます。アーキテクトは、アジャイルかウォーターフォールかを問わずそのプロセスに関与し続けます。提案されたアーキテクチャのようなものを提供すると、開発者はコード、モジュールや構造などの観点からどのようなものになるかを考え始め、そのプロセスの一環としていくつかのものを構築したり、ステークホルダーとの継続的な関わり合いを始めたりします。
実際のところ、あなたはさまざまな方面の人たちと仕事をしているので、開発プロセスに関与し続けることはとても難しいことです。でも、あなたがそれに関与し続け、アジャイルなプロセスで対処し、リファクタリングや再設計などを行うといったことができるので、私はアーキテクトがプロジェクト全体を通して関与すべきであることに全面的に同意します。
■ アーキテクチャの実践において、開発への関与がより増えると思いますか？
それはビルドの設計に移ったあと、あなたがアーキテクトとして何をしているかによります。私は、最近はそれほどでもないかもしれませんが、昔は設計やアーキテクチャにも関わっていました。そうでない場合、私はアーキテクチャを設計開発チームに任せます。
あなたは関与し続けなければなりません。それは個人的な関係がとても重要になるところです。ですので、私はアーキテクトとして多くの時間を会議や人との1対1のセッションに費やしました。ある領域で仕事をする時に私が望むことの一つは、主要な利害関係者全員と定期的なミーティングを設定することです。相手が誰であるかに応じ、週に1回、2週間に1回などです。彼らと一緒に座り、彼らが直面している問題にどう取り組んでいるかを話します。それはしばしば、あなたの注意を惹かねければならないようなアーキテクチャ上の問題点を、彼らとあなたが共有する瞬間となります。人と面と向かって接触し続けるのでなければ手遅れになるまで何かを発見することはできず、彼らが何かを作ってからそれが間違いであることを発見するだけとなります。
私にとっての課題は、今は開発者ではないということです。以前はかなり優秀だったのですが。最近では実際のところ深く技術に傾倒していません。JavaやC#のコードを書くよう頼まれることはありません。そこにおいて私に何ができるかという点、その状況における技術的な価値ということに関しては少し課題があります。これはすべてのアーキテクトが直面する課題だと思います。
■ エンタープライズ・アーキテクトとソリューション・アーキテクトの関係を説明していただけますか？
最も単純なレベルで言えば、エンタープライズ・アーキテクトとソリューション・アーキテクトの関係は、扱っている対象の範囲に過ぎません。つまり、ソリューション・アーキテクトとしては一貫性のあるソリューションを形成するシステム、あるいは2つか3つのシステムを扱うことになります。エンタープライズ・アーキテクトとしてはビジネス部門や組織の一部、あるいは組織全体を扱いますが、その場合アーキテクチャのコンポーネントは通常システムそのものであり、データ・ストアやその他の性質を持つシステムです。
あなたの質問に対して饒舌な答えをするならば、実際には両者はかなり違います。エンタープライズ・アーキテクトは明らかに、担当するステークホルダーのレベルがシニアとなる傾向があります。したがって、シニアIT管理者であるCIO、ビジネス・ステークホルダーはCEO、ユーザーはスポンサーのシニア・マネジメントである可能性があります。したがって、より抽象的なレベルで作業する傾向があり、受け答えする質問はより広範でかつ技術に特化されない傾向となります。ですから、エンタープライズ・アーキテクトとしては、ある特定の技術的な質問に対して答えを求められることは稀です。
もう一つの違いは相手の優先順位が違うことです。エンタープライズレベルでいえば、それは企業の戦略とビジョンに関することです。クライアントや顧客、ビジネスユーザーへのデリバリーに関することことです。予算や支出などの大きな問題に関することです。
私が思うに、エンタープライズ・アーキテクトの世界の方がソリューション・アーキテクトの世界よりもずっと大きな問題があると思います。より戦略的になる傾向にあります。つまり、エンタープライズ・アーキテクチャは、戦略的に優れた方向に組織を導くということです。一方、ソリューション・アーキテクトはより焦点を絞っています。システムを提供する必要があり、それを来年までにする必要があります。
■ これから将来に目を向けたとき、アーキテクトはどこに向かうと思いますか？
いままで目立つこともなくあまり理解されてこなかったアーキテクトというものが、この10年ほどの間で変わってきているのを見て、私は非常に勇気づけられています。私が5年間携わってきたすべてのプログラムやプロジェクトにはアーキテクトがいて、最近も多くの採用活動をしてきました。ですが、すべてのプロジェクトがこれに取り組むには変化が必要であり、まだまだ長い道のりがあると思います。
この広い業界では、アーキテクトが何をするかについてほとんど意見が一致していないと思います。2人のアーキテクトにどんな仕事をしているのか聞いても、いく通りもの答えが返ってきます。私が見てきたような組織はそれを実現しようと懸命に努力しているので、アーキテクトが役割としてもっと確立され、アーキテクトが何をしているのかについてもっと明確で一貫性があるようにしたいと思います。そうしなければならないと私は確信しています。アーキテクトに対して本当に何を求めているのか分からないため、アーキテクトを募集するのはとても難しいのです。「私こそがアーキテクトだ」と言う人もいれば、「もっと広い範囲のことをしている」と言う人もいて非常に多様です。プロジェクトマネージャやC#の開発者やテスターを雇うのも難しいですが、合理的なコンセンサスがありますよね。それは変わらなければならないと思いますしきっと変わると思います。アーキテクチャは組織におけるキャリアパスとなり、人々がそこでキャリアを積むことに対して不安を感じなくなると確信しています。昔でしたら、人々の多くはこの役割を引き受けたくないと思ったでしょう。なぜなら、それがどこに向かうのかわからなかったからです。それは変化しており、今後も変化していくと思います。
テクノロジーが急速に変化しているのは明らかであり、インターネットやIOT、クラウドはその類のものです。この数年に気づいたことですが、古き時代にはソリューション・アーキテクトは全てのこと、サーバやネットワークやデータベースについて考えなければなりませんでしたが、現在ではそこにインフラストラクチャがあると仮定したうえで、専らアプリケーションとデータアーキテクチャに焦点を当てています。これは今後も続くと思いますし、その基準(bar)はさらに上がっていくでしょう。
次の10年で明らかに状況が変化すると思います。
（インタビュー終わり）
いかがでしょうか。インタビューから伝わってくるのは、自ら推奨するソリューションやテクノロジーに対する彼自身の深い愛着、そしてアーキテクチャによって顧客の課題を解決するアーキテクトとしての信念と自負です。アーキテクトとして歩む道のりは、決して平坦なものではありません。プロジェクト初期のカオスな状況において、多くのステークホルダーと対話し、アーキテクチャデザインで秩序をもたらし、組織を前進させることにアーキテクトは関与し続けていくことが求められます。であるからこそ、深い愛着や強い信念と自負が不可欠なのだろうと考えます。また、全てのアーキテクトが直面する課題として、自らの役割や提供価値を変革していくことを常に意識していかないとならないでしょう。インタビューで語られるように、次の10年も変化の時代であり続けるでしょうし、その変化を牽引するのはアーキテクト自身なのですから。
今回はIasa米国本部コンテンツから、ニック・ロザンスキー氏のインタビュー記事をご紹介しました。本記事についてのご意見・ご感想をお聞かせください。
註）
1.“Videos,Articles,Content”,Iasa Global,
2.“Software systems Architecture with Nick Rozanski”,Iasa Global,