特集 Tech・Ed 2005パネルディスカッション・レポート .NET開発者のための「アーキテクトへの道」 デジタルアドバンテージ　一色 政彦 ＆ 正木 理絵子 2005/08/20

Page1 Page2

　マイクロソフト主催のアーキテクト／デベロッパー／ITプロ向けのカンファレンス「Tech・Ed 2005」が2005年8月2日から4日間開催された。その最終日、8月5日の最後のセッションでは、「アーキテクトへの道」と題されたパネル・ディスカッションが催され、「アーキテクトとはそもそもどんな人なのか？」「どうすれば自分もアーキテクトになれるのか？」「アーキテクトを社内で育てるにはどうすればよいか？」などについての熱い議論が交わされた。

　本稿では、そのパネル・ディスカッションのもようをお伝えする。ディスカッションのパネリストとして、さまざまな分野での企業向け情報システム開発に詳しい以下の方々が参加された。

• サン・マイクロシステムズ　伊藤 敬 氏
  （フィールドマーケティング統括本部 ストラテジックマーケティング統括部 統括部長）

• 日本フィッツ　荒井 玲子 氏
  （証券システム第二事業部 第五開発部 シニアマネージャ）

• アマゾン ジャパン　吉松 史彰 氏
  （Amazon Webサービス テクニカル エバンジェリスト）

• マイクロソフト　マイケル ダイクス 氏
  （デベロッパー＆プラットフォーム統括本部 エンタープライズプラットフォーム本部 プラットフォーム戦略部）

　そしてモデレータ（進行役）は、＠IT／Insider.NET、Windows Server Insider、System Insiderを運営するデジタルアドバンテージの小川 誉久が務めた。

　本稿では、どのパネリストの発言かが分かるように、文章の先頭に発言者の名前を記載し、モデレータの発言は太字で記載して無記名にする（以降、敬称略）。また本稿では、ITアーキテクトを単に「アーキテクト」と表記する。

■

◆アーキテクトとはそもそもどんな人なのか？　―――――

――　それではまず、「そもそもアーキテクトとは、一体何なのか？」をはっきりさせたいと思います。さっそく、質問になりますが、ここ数年で「アーキテクト」という言葉をよく聞くようになりましたが、なぜアーキテクトが注目されるようになってきているのでしょうか？

サン・マイクロシステムズ 伊藤 敬 氏

エンタープライズJava環境におけるアプリケーション・サーバのマーケティング業務などに長年従事。主に、UNIX／Javaベースのシステム・インテグレーションに詳しい。

伊藤：それは、「システム・インテグレーション（以降、SI）の収益構造が変わってきたから」でしょう。

　プログラミングの価格は、いつかは下がっていくものだと思います。確かにプログラミングは、システムに最新技術を導入するために必要不可欠な作業であり、さらにプログラマはそれを信頼性の高いものに仕上げていかなければなりません。また業種によって利用できる技術はさまざまに異なるので、取り扱うテクノロジが非常に幅広いということを考えると、プログラマはとても大変な仕事です。そのようなプログラミング作業に対して、これまでは相応の対価が支払われてきました。

　しかし、これから技術が進化していき、プログラミングの作業が自動化・簡略化するなどして、プログラミングが徐々に単純労働化していくに従って、その価格というのはあっという間に下がってしまうでしょう。そのようなことが現実に、SIの収益構造の中で起こり始めていると思います。最近はそれが顕著に現れるようになってきました。これは、WebやJavaなどのテクノロジが出てきておよそ10年がたち、テクノロジそのものが習熟してきたということもあるでしょう。つまり次世代のシステム開発では、単純な実装作業だけでは、ビジネスとして利益を生み出すことが難しくなってくるのです。

　このようなシステム開発の現状において「何に価値があるのか」を考えると、やはり「開発されるシステムの中に、お客さま（顧客。以降、エンド・ユーザー）の要望がどれだけ正確に反映されているか」、あるいは「要望以上の付加価値を持たせてシステム化できるか」というのが、システム開発の価値として挙げられます。要するに、エンド・ユーザーのニーズに沿った企業システムを開発する必要性が高まってきているということです。

　実際にこれに応えるには、「テクノロジを高度にかつ幅広く理解しながら、エンド・ユーザーに対して提案・営業もできる」というノウハウを持った人物が必要です。例えば、「新しいテクノロジも古いテクノロジも知っていて、それをどう変遷させていかなくてはならないか」、または「エンド・ユーザーの事情で古いテクノロジも使っていかなければならないが、ほかとの差別化を図るには新しいテクノロジにもトライしなくてはいけない」などの問題をうまく解決できる人、つまり「（システムの）制約」と「（エンド・ユーザーの）要望」のはざまを調整・改善していける人*1が、いままさに必要なのです。

　このようなポジションにばっちりと当てはまるのが、「アーキテクト」ではないでしょうか。

*1 パネル・ディスカッション冒頭の自己紹介では、「アーキテクトの1番大事な仕事をひと言でいうと何？」という質問がパネリスト全員に問い掛けられた。そこで吉松氏が返答した内容を受けての発言。ちなみにほかのパネリストの返答内容は、伊藤氏が「SIの現場なら、システム全体の把握」、荒井氏が「コンセプトを作ること」、マイケル・ダイクス氏が「長期的な視点に立ち、システムのあるべき姿をエレガントに実現させること」だった。

荒井：わたしは、アーキテクトが注目されるようになったのは、「分散システムの開発が広まり、失敗プロジェクトが増大したから」だと考えています。

　分散システムの開発が増えるに従って、メインフレームの開発では考えなくてもよい範囲を考えなくてはならなくなりました。例えばシステムで利用されるミドルウェアの組み合わせです。

　分散システムは、単に、機能を積み上げていけばできるという代物ではありません。そのようなメインフレーム的発想で開発をするとアプリケーション機能以前の問題が多数発生し、システムは動きません。

　しかし実際には、アーキテクチャを設計できる人材がシステム・インテグレータ（以降、SIer）の中で不足しており、またその必要性をSIer自身が認識できていなかったため、分散システムの開発が失敗するケースが増えてしまったのです。

　そのようないくつもの失敗の経験から、アーキテクトの必要性がようやく認識され始めたのだろうと思います。

アマゾン ジャパン 吉松 史彰 氏

Amazon Webサービスのテクニカル・エバンジェリスト。主にXMLやWebサービスなどのテクノロジに詳しく、.NET、Webサービスに関する高度な技術解説記事を多数執筆している。

吉松：先ほどの荒井さんのお話を伺って、「ああ、そうか！」と気付いたのですが……。

　わたしはこれまでWindows環境でプログラミングやそれに関するトレーナーをやってきましたが、そのような「プログラマ」である僕にとって「アーキテクチャ」とは、マイクロソフトが教えてくれるものでした。例えば、マイクロソフトが.NET以前に提唱していた「Windows DNA（Windows Distributed interNet Application）」や「クライアント／サーバ・システム」などがそれです。

　これまでのプログラマの感覚では、例えば「クライアント／サーバ・システム」といわれれば、「Visual BasicとSQL Serverでシステムを構築しよう」と大ざっぱに考えて、それを実践していけばよいつもりだった、実際にそうやってシステム開発を行ってきたのですが、いまの荒井さんのお話にあったように、現実的には、それだけではやっぱりうまくいかないですね。

　「『クライアント／サーバ』とだけいわれても、実際のシステムは構築できない」ということに、やっとみんなが気付き始めて、「それじゃ、そのシステムの具体的なアーキテクチャはどうするの？」っていうことをきちんと考える人、つまりアーキテクトが必要だと、認識され始めてきたのだろうと思います。つまりここにきて初めて、より良いものを作るには、大ざっぱなだけでなく、もっと細かな視点、つまりきちんと現状に合わせて考慮された「アーキテクチャ」が必要であると気付いてきたのではないでしょうか。

マイケル・ダイクス：わたしはアーキテクトにとって大事な仕事は、「新しいことを築き上げること、切り開くこと」だと考えています。そういう意味では、いまになって、いきなり「アーキテクト」が出現したわけではなくて、昔からアーキテクトの仕事は存在していたと思います。ただしそのような仕事をする人を、昔は「アーキテクト」とは呼んでいなかったということでしょう。

　それではいまなぜ、アーキテクトが注目されてきているのかというと、「新しいこと」に対するニーズが非常に大きくなってきているからではないでしょうか。

　例えば、多くの企業では、メインフレームからのダウンサイジングによるシステムの置き換えや、企業合併などによるシステム統合、ユビキタス社会への備えなどの問題に悩んでいます。しかし、このような状況を解決するための既存のベスト・プラクティスというのは、完全には定まっていないことが多いと思います。そもそもこのように多様な問題に対して固定的な解決法を用意することは難しいでしょう。よって、このような問題に柔軟に対応する新しい解決策を提案できる人が必要となります。そのような自然な流れでアーキテクトが必要になってきているのだと思います。

――　それでは、吉松さんにお伺いしたいのですが、Windowsベースのシステム開発でアーキテクトと呼ばれる方々が、現実に活躍しているケースというのはあるのでしょうか？

吉松：（観客席に向かって……）酒井さん、あるんでしょうか？（※日立システムアンドサービスの酒井 達明氏は、本フォーラムでもレポートした「SOAの設計手法」のセッション・スピーカーでもある）

酒井：すみません。ご指名を受けてしまいましたけれども。

　多くの現場では、いまのところ、アーキテクチャはまだあまり重視されていないと感じています。というのも、昔のメインフレームの時代には、典型的なベスト・プラクティスとなるアーキテクチャが定まっていたので、取りあえず機能だけを積み上げていけばアプリケーションはできてしまっていました。実はそのようなアプリケーションの作り方は、いまでも変わっていません。

　しかしそのために、稼働直前にさまざまな問題が起こってしまう。例えば、パフォーマンスが悪かったり、システム内のコンポーネントがうまくつながらなかったりします。そこで、結局は小手先の対応でアプリケーションを動かすことになる。

　そういう経験から最近になってようやく、「上流で考えること」の重要性が問われるようになりました。Windowsベースのシステム開発におけるアーキテクトの重要性は、もちろんシステム開発の業種や規模にもよるでしょうが、ようやく認識され始めてきているところです。

――　分かりました。ありがとうございました。どうやらアーキテクトは、「これからのシステム開発において重要な役所である」と認識され始めた段階のようですね。現在のシステム開発では、エンジニア（いわゆる、システム・エンジニア：SE）という職種がありますが、それではエンジニアとアーキテクトはどこが違うのでしょうか？

荒井：エンジニアは、平たくいうと、確実に動作するシステムを作る人のことです。システム開発のためのテクノロジについて詳しいだけでなく、最新の技術についてもよく知っており、その技術を用いたシステムを設計・実装して、実際に動くところまで作り上げることができます。

　一方、アーキテクトの仕事は、システム全体のコンセプトを設計した「青写真」を作ることなのです。

マイクロソフト マイケル ダイクス 氏

プラットフォーム戦略エバンジェリスト。4年前から日本で活動しているが、それまで米国で数多くのシステム開発などを経験。米国のシステム開発事情に精通している。

マイケル・ダイクス：エンジニアは、既存のテクノロジやコンポーネントなど（以降、部品）を組み合わせたシステムを設計したり、実装したりすることができます。これはエンジニアが既存の部品の組み合わせ方・パターンを熟知しているということです。こういう部品を組み合わせてシステムを構築した場合には、確実にこれくらいの可用性やスケーラビリティ、パフォーマンスを確保できるということをすべて理解しています。ここはエンジニアの非常に優れたところです。

　しかしエンジニアは、アーキテクトと違って、それ以上の新しいところ、未知の領域にはなかなか進みません。エンジニアは、アーキテクトのように、壮大なビジョン（＝青写真）を掲げたり、まったく新しい部品の組み合わせを考え出したりはしないと思います。

　わたしの父は土木技師で空港や道路、橋などを建設していたのですが、長年の持論や勘などから建設する対象や目的に合ったパターンを使い、時としてそれらを応用していました。従って父は、「橋が落ちないためには、こういう部品はこういう場所に使えばよい」ということなどをよく分かっており、問題分析・問題解決するための能力が確かに備わっていたことになります。しかしこれは何千年も培われてきた知識を完ぺきに適用しただけに過ぎず、新しい種類の組み合わせで、自ら斬新なデザインを持つ橋を造ったわけではないのです。つまり、父はエンジニアであり、アーキテクトではなかったのです。

　どちらが優れているということではなく、エンジニアはエンジニアでシステム開発に欠かすことのできない重要な仕事である一方、アーキテクトは、いままでなかったような新しいシステムを作ったり、斬新なアーキテクチャのシステムを構築したりするなど、エンジニアの問題解決能力とはまた違った能力が要求されます。

　一般的には、エンジニアとアーキテクトには、このような違いがあると思います。

――　なるほど。それでは話題を変えて、どうすればアーキテクトになれるかについて議論していきましょう。（次のページへ続く）

INDEX
	［特集］Tech・Ed 2005パネルディスカッション・レポート
	.NET開発者のための「アーキテクトへの道」
	1．アーキテクトとはどんな人なのか？
	2．どうすればアーキテクトになれるのか？

　

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）