特集
Tech・Ed 2005パネルディスカッション・レポート

.NET開発者のための「アーキテクトへの道」

デジタルアドバンテージ 一色 政彦 & 正木 理絵子
2005/08/20

Page1 Page2

どうすれば自分もアーキテクトになれるのか? ―――――

―― 実際にそのようなアーキテクトになるためには、最低限、どのような素養や能力が求められるのでしょうか?

吉松:「アーキテクト」という言葉が最近はやっていて、実際に「アーキテクトになるには?」のようなタイトルの雑誌や本を見たことがあります。しかしそのような記事では、何か飛びぬけたITスキルを持ったスーパー・エンジニア(スーパーSE)という人がいて、そういう人がアーキテクトであるかのように読めてしまうのですが、実際にはそうではなく、先ほどの荒井さんとマイケルさんのお話と同じように、僕もアーキテクトとエンジニアというのは、まったく違う仕事だと思っています。そのため両者は、それぞれの仕事をこなすために必要な素養・素質というものも、やはり異なってきます。

 例えばソフトウェア開発でデザインパターンがはやった当時は、定石となるGoF(Gang Of Four)のデザインパターンを誰もが勉強しました(デザインパターンについては、「.NETで始めるデザインパターン」を参照されたい)。その次に取る行動は、人間の性質・素質などによって、2種類のパターンに分けられます。

 1つ目のパターンは、定石とはいえないもののいままさに盛り上がりつつあるデザインパターンに注目していく人。いまある知識をより広く、より多く集めたいと思うタイプです。もう1つのパターンは、「定石となるデザインパターンを最初に思いついた人は、一体どのようにしてこれを考えついたのか?」ということに関心を持ち、それを解明していこうとする人。デザインパターンの仕組みを思いついた思考プロセスを逆に探っていこうとするタイプです。

 前者のプロセスを踏む人は、既存のものを上手に組み合わせて完ぺきなシステム開発を行うためのセンスが鍛えられるし、後者のプロセスを踏む人は、思考プロセスそのものが身に付けられるので、自らシステム・アーキテクチャを作り出すためのセンスが磨かれるのではないかと思っています。どちらかというと、後者の方がアーキテクトっぽいのではないかと思います。

日本フィッツ
荒井 玲子 氏
現在は金融証券系のシステム開発などに従事。オブジェクト指向開発やモデリングに詳しいだけでなく、音大卒で培われた感性から、理系的ではない、ユニークな視点からアーキテクト観を語ってくれた。

荒井:「アーキテクトになるには、どうすればよいですか?」という問い掛けは、ちょっとずれているような気がします。「英語が話せるようになるには?」と同じように、何かのテクニックを習得すれば、それだけでアーキテクトになれる。そう思っているのだとしたら、それは違うのではないでしょうか。そこには、「アーキテクトになった後、どうしたいのか? 何がつくりたいのか?」がないのです。これからアーキテクトになりたいなら、アーキテクトになるためのテクニックを学ぶのではなく、アーキテクトとして、どういうものを創りたいかという持論がなくてはいけない。

マイケル・ダイクス:「アーキテクト」と呼ばれる人には、恐らく、3つの素養が必要だと考えています。

 1つは「クリエイティビティ」。これは発想の転換力のことです。もう1つは、「技術力」。最後の1つが「美的センス」です。美的センスというのは、例えば本当に素晴らしいアーキテクトによって設計されたシステム・アーキテクチャは、実際に見てみるととても美しいものなのですが、そのようなアーキテクチャを心から美しいと思える感覚を持ち合わせているかどうかということです。美的センスについてもっと言うと、建築家やITアーキテクトの間で幅広く読まれている『The Timeless Way of Building』(Christopher Alexander著)という本がありますが、この中で示されている「Quality without a Name」という概念がそれに当てはまるのではないかと思います。この概念は、「美」「質」「心地よさ」を含めたセンスを表現しており、「勘」や「性(しょう)」にとても近い概念です。従って、「美的センス」のみに限定せずに、もっと広く「センス」とした方がよいかもしれません。

荒井:わたしが先ほどいった「アーキテクトとして、どういうものが創りたいか?」というのは、マイケルさんのクリエイティビティに類似するものがあると思います。また、複数あるアーキテクトの素養の中でも、美しいものをちゃんと美しいと感じられる感覚、つまり美的センスが一番重要だと、わたしは考えています。

 ここでいう美しいものとは、簡単ないい方をすれば、「シンプル」だということです。つまり美的センスとは、シンプルなものを求めることができて、シンプルにものが作れるということです。

 このような美しさは、例えば最近の携帯電話などに、顕著に表れています。一方では、機能がどんどん追加されていって、きらびやかになっていく携帯電話。こちらはエンジニア的な発想です。もう一方では、通話の機能だけに絞った携帯電話が出てきています。こちらは、アーキテクト的な発想です。一度買った後でどちらの携帯電話の方が長く使われるのかというと、やはり通話のみの携帯電話だと思います。なぜなら、機能がたくさんある携帯電話はすぐに飽きられてしまって、すぐに買い替えられてしまいます。つまり、良いものは使われ続けるということです。で、どちらが美しいと思うかと問われたときに、通話だけの方が美しいと感じることができる人は美的センスを持っていると、わたしは思います。

―― なるほど。アーキテクトになるための話ですが、ここまではちょっと抽象的な話になりましたので、もっと具体的な話をしていきましょう。アーキテクトにとって必要なエンジニアリングの知識やプログラマ・スキルには、具体的にどのようなものがあるのでしょうか?

伊藤:例えば、OSの知識やプログラミング言語、ネットワーキング、ビジネス・プロセス・モデリングの知識、開発プロセスの知識など、基本的なテクノロジの知識は必要不可欠ですね。特に、アーキテクト自身がかかわっているシステムの根幹となるテクノロジについては、十分な知識を持っておく必要があると思います。

マイケル・ダイクス:アーキテクトとしてアーキテクチャを設計する対象によって、身に付けなくてはならない技術は変わってくるため、一概にはいえないと思います。例えば、ソフトウェア・アーキテクトだったら、当然、プログラミングやOSに関する知識が必要ですし、さらにそのソフトウェアが分散システムならば、分散されるコンポーネントやサービス間の通信手段などを選択できるだけの知識が必要になってきます。またはソフトウェアじゃなくて、データベース・アーキテクトならば、データの在り方を考えなければならないので、データやデータベースに関する深い知識が必要となるでしょう。

荒井:ほかのアーキテクチャ設計の経験はともかく、最低限、プログラミングの経験は必要だと、わたしは思います。特にソフトウェアを作るという経験は、最低1年でもいいから必要だと思います。

 ソフトウェアを実現しているのはソース・コードです。オブジェクト指向技術を使って設計したとしても、現在のオブジェクト指向プログラミング言語では、すんなりコードに落ちません。すべてのオブジェクト指向技術がプログラミング言語仕様に落ちていないからです。その差分を解消するために、設計モデルをゆがませるか、無理をしたコードを書くわけですが、その差分がどのくらいの影響範囲を持つのか、ということは実装経験抜きには知ることができません。言語仕様を調べて学んでいくのも悪くはないのですが、プログラミング言語には手を動かしてみないことにはわからない部分もあります。このような理由から、アーキテクトにはソフトウェアの開発経験が必要だと考えています。

 アーキテクトは少なくとも言語仕様までは習得しておく必要があり、エンジニアはさらにその先の細かな技術までを知っておく必要があると思います。そこで、よく誤解されてしまうのが、「エンジニアが下にいて、アーキテクトはその上です」という階級差があるという説です。しかしこれはうそです。エンジニアとアーキテクトには職の違いがあり、並列で横にいると思ってください。だから必ずしもシステム・エンジニアとしての下積みの経験があって、初めてアーキテクトになれるというキャリア・ステップが存在するわけではありません。例えば、ビジネスのアーキテクトからITアーキテクトになるキャリア・パスもあり得るということです。

アーキテクトを社内で育てるにはどうすればよいか? ―――――

デジタルアドバンテージ
小川 誉久 氏
Windows Server Insider編集長。Insider.NET、System Insiderの3つのフォーラムを@ITで運営している。

―― 自分がアーキテクトになるために必要な素養やテクノロジの知識については分かりました。

 それでは今度は、社内で自分の部下をアーキテクトに育てたいという場合には、どうすればよいのでしょうか?

 そもそも部下が有能なアーキテクトになれるどうかを見分けるための方法というのは、あるのでしょうか?

荒井:10個ほどの質問リストを使って、素養のある人を探しています。その質問の中には、例えばこんなものがあります。

「粘土が好きか? それとも積み木が好きか?」

 この質問は、その人のクリエイティビティの方向性を確かめる質問です。

 例えば、粘土をこねくりまわしながら独創的なものを創り上げるのが好きだという人は、やはり何か新しいものを無から創作することに向いているのだと思います。また形状の決まった積み木をうまく組み合わせるのが好きだという人は、もともと形が決まっている世界の中でそれを実際に作って実現してみせることに向いているのだと思います。要するに、粘土はアーキテクト向きで、積み木はエンジニア向きです。

 実は、この質問は結構奥深いところがありまして、裏があるんです。積み木が好きという人は、実はプロフェッショナルな素養を持ち合わせていると見ることができます。例えばこれがビジネス上の話になると、積み木が好きな人は、さまざまな制約の中でもきちんとクリエイティブさを発揮することができますが、粘土が好きな人はこのようなことは苦手なのです。

―― ちなみにアメリカでは、どのようにしてアーキテクトを育成しているのでしょうか?

マイケル・ダイクス:簡単に説明すると、1つ目は、アーキテクトとして育てたい部下に、責任ある仕事を任せるということです。要するに、OJT(On the Job Training)です。部下をアーキテクトへ導くというよりも、部下の背中を押してあげるということです。もちろん、部下が転びそうになったときには、ちゃんと支えてあげることが大事です。

 それからもう1つは、ベスト・プラクティスの共有です。ユーザー企業の場合には難しいかもしれませんが、SIerの場合ならば成功事例となったアーキテクチャの設計を共有して、「何が良かったのか」「何が教訓になったのか」などの知識を社内で共有することです。共有された知識を見ることで、これからアーキテクトになるような若い人たちが成長できるようになると思います。また成功事例となったアーキテクチャの設計は、ベスト・プラクティスとして特別に取り上げるだけではなく、みんながベスト・プラクティスに対する議論に積極的に参加して、「わたしだったら、こうする」などの意見を、自由に発言できる雰囲気を作り出すことです。

 3つ目はピア・レビューです。つまり、作成したアーキテクチャの設計を同僚同士でレビュー(評価・確認)するということです。若手アーキテクトが作り出したものをみんなでレビューして、「わたしだったら、こうする」などの意見を出し合いながら、アーキテクトとして成長させていくことが大事だと思います。

伊藤:アメリカはトライして駄目だったらまた次という文化で成り立っている社会なので、若い人でも「ソフトウェアで世の中を変えていこう」「ソフトウェア開発にパラダイム・シフトを起こそう」としてアーキテクトになる人が多いのですが、日本ではちゃんとした階層型の社会が成り立っているから、地道にアーキテクトを育てていくという構図になりがちです。

 これは、文化的なものだからどちらが良いとは一概にいえないでしょうが、わたしはもう少しアメリカ型を見習ってもいいかなと思っています。「世の中を変えていこう」という気概を持った若い人に、どんとアーキテクトの仕事を任せてみて、それでもし駄目だったらまた出直しという、少し余裕を持った会社経営で、アーキテクトを育てられたなら、日本でも優秀なアーキテクトが多数輩出される可能性が広がるでしょう。

 日本でも、実際にそのようなチャレンジを行う会社は増えてきていますし、若い人も起業したりしていますね。だけど、まだあまりうまくはいってないです。日本でもこういうことが、もっとうまくいく社会になってほしいと願っています。

アーキテクトを目指す皆さんへ贈るメッセージ ―――――

―― 分かりました。それでは最後に、これからアーキテクトを目指す皆さんへ向けたメッセージを、一言ずつお願いしたいと思います。

マイケル・ダイクス:先ほど、部下である若いアーキテクトの背中を押してあげるという話を上司にあたるみなさまにしましたが、一方、若い方はとにかくリスクを背負ってアーキテクトの経験を積む責任があると思います。もちろん、結果がまったく予測できないようなまったく新しいことをするというのは、本当に怖いことです。それでも、リスクを背負って挑戦することが、アーキテクトの最初の一歩となるでしょう。

吉松:なりたいなら、なるためのことをやりましょう。アーキテクトになるには、受け身の姿勢ではきっとなれないでしょう。アーキテクトは教科書に書いてあることを学べばなれるような職業ではないのです。加えて、アーキテクトという職業は(プログラマに比べて)そんなに人数が必要とされていないとも思います。つまり競争率が非常に高い職業だと思っています。ですから、頑張ってください。

荒井:アーキテクトは、未来を作る人、つまりコンセプトを作る人です。アーキテクトを目指す人に、次の3つのことをお伝えしておきます。1つ目は、アーキテクトになること自体を目的としてはいけません。2つ目は、創りたいものを自分の中に持ってください。そして最後に、それが使われる具体的イメージを持ってください。創りたいものは、いまの技術で実現できないことで構いません。技術はあとからついてきます。パロアルト研究所におけるパーソナル・コンピュータの開発も、ユビキタス・コンピューティングもそうです。そこでは、まずコンセプト・デザインがあります。現在、技術は追いつき、当時のコンセプトが実現されました。そうやって、いつかは実現されていきます。

伊藤:確かにアーキテクトの競争倍率は高いと思います。それならばどうするか。いままで10年間、外資系企業で働いてきた経験から、どうやって生き残るかを考えてみると、自分の強みはどこにあるかを考え直すことです。いままでのIT業界の歴史で体系立てていえることは、強いものと強いものが合わさって強者連合みたいなものを作ることで、生き残っているということです。わたしは、強いものが単独で生き残るのではなくて、強いものが協力し合って生き残っていくものだと信じています。アーキテクトも、当然ながら企業の中にいます。従ってアーキテクトは、その企業が生き残っていくためのファクタ(要因)となる必要があると思います。そのファクタとしては、自分の何が強みになるのかをよく考えていただきたいです。以上がこれからアーキテクトになられる方へのメッセージです。

―― 今回のパネル・ディスカッションを通して、わたしなりに、ほんの少しですが、アーキテクトというものがどのようなものか分かった気がします。本日はどうもありがとうございました。

 これが、「アーキテクトへの道」パネル・ディスカッションで交わされた会話の一部始終である。これまで、アーキテクトの定義はあいまいで、霧に包まれた謎の人物像のように思えていた読者も多いと思うが、本稿でその霧がほんの少し晴れてきたのではないだろうか。

 取りあえずここで、筆者なりにパネル・ディスカッションの内容を簡単にまとめてみると、次のようなことがいえると思う。

●アーキテクトとはどんな人か?

  • システム全体に対する(将来の変化予測を含めた)コンセプトを持っている人
  • そのコンセプトを基に、柔軟で斬新なアーキテクチャを設計できる人
  • ビジネス的な側面では、システム制約の中でエンド・ユーザーの要望を実現する、柔軟で斬新な解決策を考えられる人

●アーキテクトに必要な能力や素養とは?

  • 未来に対する壮大なビジョンやコンセプト(=何を創りたいか)を持っていること
  • システムのあるべき姿(=美しさ)を感じ取ることができるセンス
  • 無から柔軟かつ斬新に発想できるクリエイティビティ
  • (当然ながら)開発者として必要最低限の技術力

 ITとは、結局のところ、「ものづくり」というビジネスの「裏方」なのだと思うが、そうであるならば、われわれシステム開発者は、その裏方として「ビジネスをしっかりと支えられる頑丈でかつ柔軟な柱」となるシステムを作っていかなければならないはずだ。ITテクノロジが幅広い分野へと成長し続ける現在、ITシステムの構築はもはや一様ではうまくいかなくなってきている。多様化するシステム構築を成功させるためには、現実に即したシステムのアーキテクチャを考えられる人材、つまりITアーキテクトがどうしても必要なのだ。

 確かに今回のディスカッションでも、アーキテクト像やそれに対する思いは、パネリストそれぞれに微妙に違う部分もあったが、その根本にある「よりよい情報システムを構築するために必要な人材」という点は共通であったと思う。ITはもはやあらゆるビジネスにとって不可欠の存在であり、その成否がビジネスの成否を大きく左右する。そして優れた情報システムを開発するためには、ビジネスの要求、エンド・ユーザーの要求を、一貫したコンセプトとして情報システムに貫く必要がある。これには、ビジネスとITテクノロジを高度につなぐ人材が必要だ。それがITアーキテクトだといえるだろう。

 最後に本稿の執筆に当たって、パネリストの方々やパネル・ディスカッションのまとめ役をされた大森 彩子氏(マイクロソフトのアーキテクト・エバンジェリスト)をはじめ多くの関係者の方々にご協力していただいた。ここで感謝の意を表したい。End of Article

 

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


Insider.NET フォーラム 新着記事
  • 第2回 簡潔なコーディングのために (2017/7/26)
     ラムダ式で記述できるメンバの増加、throw式、out変数、タプルなど、C# 7には以前よりもコードを簡潔に記述できるような機能が導入されている
  • 第1回 Visual Studio Codeデバッグの基礎知識 (2017/7/21)
     Node.jsプログラムをデバッグしながら、Visual Studio Codeに統合されているデバッグ機能の基本の「キ」をマスターしよう
  • 第1回 明瞭なコーディングのために (2017/7/19)
     C# 7で追加された新機能の中から、「数値リテラル構文の改善」と「ローカル関数」を紹介する。これらは分かりやすいコードを記述するのに使える
  • Presentation Translator (2017/7/18)
     Presentation TranslatorはPowerPoint用のアドイン。プレゼンテーション時の字幕の付加や、多言語での質疑応答、スライドの翻訳を行える
@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)

注目のテーマ

Insider.NET 記事ランキング

本日 月間