アーキテクトという仕事

Itoi,LLC 社長
 糸井名生(いとい・なおまる)氏

私事がいろいろあり、二ヶ月も空けてしまいました。申し訳ない。

5年くらい前から、「アーキテクト」という肩書を良く耳にするようになりました。ビル・ゲイツがしばらく「Chief Software Architect」だったので、それで知名度が上がったのかもしれません。

ソフトウェアエンジニアの出世コースとして、

Software Engineer -> Engineering Manager -> Vice President of Engineering

は昔からあり、今もこれに乗る人はたくさんいます。しかし問題は、マネージャーになったあとは、最前線で技術に携わる機会が減ることです。偉くなって下につく人が増えれば増えるほど、技術から遠ざかります。5年も10年もかけて、エンジニアとして技術を磨いたのに、技術を生かせないのはもったいない。また、優秀なエンジニアで、人の管理に時間を使うのは嫌で、技術に集中したい、という人もいます。

そこで、別の出世コースが開拓されたんだと思います。

Software Engineer -> Architect -> Chief Technology Officer

私は、アーキテクトという仕事は、エンジニアの延長線上にあり、経験を積んだエンジニアがなる、というくらいにしか思っていませんでしたが、それ以外の面が色々あるということがだんだん分かってきました。

プロダクト・マネージメントとエンジニアリングをつなぐ

プロダクト・マネージメントが何を作るかを決めて、エンジニアリングがそれを作るわけですが、往々にして対立が生じます。例えば、一ヶ月の開発期間があるとして、前者は、もう一つ機能を増やして欲しい。後者は、そうすると大変なので、増やしたくない。どちらの見方ももっとなので、両者のバランスを取らないといけません。

プロダクト・マネージメントは、技術的なことは分からないので、何が大変なのか分からないし、エンジニアは、技術に集中するので、その機能がどのようにお客さんの役に立つか、ピンと来ません。

アーキテクトには、両方の考え方を理解して、適切な妥協点を見付けることが要求されます。

製品全体を見る

エンジニアやエンジニアリング部門が、自分の作っているものだけに集中して、回りの部署のしていることを把握していないと、一つ一つの部品は動くけれども、全部品をまとめて製品にしたときに、部品同士が上手く動かない、という問題が生じます。

技術に優れたエンジニアでも、人並外れた集中力を持っているのが仇になり、自分の部品はものすごく良く知っているけれど、他の部品には興味が無いので何も知らない、という罠に陥いることがあります。

アーキテクトは、自分の部署の外の動きにも目を配り、自分の部品が、外の部品と協調できるように、気を付けないといけません。

正しいアーキテクチャを目指す

エンジニアの仕事で重要なことと言えば何といっても、時間内にソフトウェアを作る、ということです。結果として、ソフトウェアのデザインを選ぶときに、良いデザインではないけど、時間がないし、まあ動くから、簡単なやり方でいいや、という選択をしばしばします。

この妥協は絶対に必要ですが、やり過ぎると、内部構造がめちゃめちゃになってしまい、次回コードを修正するときに、大変な苦労を強いられるます。

アーキテクトは、一番簡単な実装に比べると、若干労力がかかっても、正しいアーキテクチャで作ろう、という方向性を持たなくてはいけません。正しいアーキテクチャ、というのも難しく、教科書に書いてあることが良いとは限りません。エンジニアリング部門、会社と、お客さんにとって、向こう何年かたっても上手く動くアーキテクチャは何か、ということを常に考えることが重要です。

 (糸井名生氏のブログ「柳通り便り(http://blog.goo.ne.jp/naomaru1)」より転載)

糸井名生(いとい・なおまる)氏

1973 年生まれ。名古屋大学工学部情報工学科卒。1996年に渡米し、ミシガン大学コンピューターサイエンスの修士・博士課程へと進学。電子認証などのセキュリ ティプログラムに関連する研究でPh.Dを取得。2001年、サンマイクロシステムズへの入社を機にシリコンバレーへ。アクティブカード社などを経て、 2007年4月Itoi,LLCを起業。
現在は、NextLabs, Inc.というスタートアップでエンジニアとしても活躍中。


記事についてのお問い合わせは、info@svjen.org まで。