井上 研一 昨日から今日にかけて、テンションの上がらない状態が続いていた。
今月、転職して某コンサルティング会社のSI部門に入った。今までどおり、SIの仕事をする以上、自分の立場はエンジニアである。しかし、自分はどういうエンジニアになろうとしているのか、それが見えなくなってテンションが上がらなくなってしまったのだ。
この悩みは、自分にとって非常に長い期間の悩みで、振り返れば4年前、2006年のこのブログに、そういうエントリーがある。まぁ、その2006年にエンジニアなんてやめようと思って、前々職の会社を退職したのだが。
その2006年に、私はアーキテクトになるという宣言をした。どうにも、プログラマがシステムエンジニアになってマネージャになって運良く行けば部長になったりするようなキャリアパスが腑に落ちなくて、それ以外の道としてアーキテクトという名前を挙げた。
しかし、アーキテクトとは何なのか。普通に「アーキテクト」というと建築家のことで、私はITの世界にいるからアーキテクトといってもITアーキテクトである。ITアーキテクトを言い換えて、ITの建築家だとするならば、それは一体なんぞや。
以前、西村佳哲さんの「自分の仕事をつくる」という本を、このブログで取り上げた時に、象設計集団に関する記述を引用したことがある。ここで、もう一度、引用する。
いま僕のチームで進めている高齢者施設の設計作業を参考に話してみましょうか。今年の一月から始めて来年の九月に実施設計をまとめ上げる。全体で二十ヵ月ほどのプロジェクトです。
いまはエスキームを詰めている段階ですが、ここにいたるまでに、高齢者関連の勉強を相当積み重ねてきました。クライアントと一緒に本の回し読みも続けています。ちょうどお風呂の部分について設計を詰めているのですが、どうしても気になることがあって、近いうちに広島の施設を訪ねてみるつもりです。
プロジェクトがはじまって最初の三ヵ月ほどは、手はあまり動かさず、勉強に集中しました。そしてまずは五十一カ所の施設を実際に見に行くことを決め、北欧から国内まで、興味を持ったところはだいたい見学し、実際に体験もしてきました。入力装置を体験してみたり、寮母さんの仕事をやってみたり。入居者と同じ部屋で寝泊まりして同じ食事を食べ、同じ生活をしてみたりします。
そうしているうちに、だんだん何をするべきなのか、何が問題なのか、自分たちに何ができるのかが細かいところまでみえてくる。この勉強の段階が非常におもしろい！いろんな分野に数多くの先駆者がいて、それぞれの現場で素晴らしい実践を行っています。そういう方々に出会っていくのは興奮する経験だし、以後友人として仲良くしている人もいます。
ジャンルを越えたこれらの経験を、最終的に建築にまとめあげていくのです。スタディの段階は、時間的にも経済的にも負担がかかる部分ではあるけれど、大切にしています。それに何といってもおもしろい部分だから、これを捨ててしまったら長続きしないと思いますね。
これが建築家の仕事だと思う。単に建物を設計する人ではない。クライアントに求められて仕事が始まるのではあるが、世の中に何が必要なのかを考えて、その結論として建物を設計する。そういう仕事ではないだろうか。
SIの世界では、よく「業務」と「技術」という言い方をする。SEは業務と技術の両方を見て仕事をしている。これは建築家に似た仕事のやり方だと思う。しかし、SIerのキャリアパスはSEで居続けることを許してはくれない。SEは通過点であり、そこから何かにならねばならないという。
ひとつは旧来からの直線的キャリアパスのゴールであるマネージャだ。マネージャはプロジェクトを複数抱えて、その管理をしている。経営層、顧客、プロジェクトメンバの間に入って、すべてを調整している。大変な仕事だし、立派な仕事だと思うが、それは業務でも技術でもない。
最近は、SEの次のキャリアとしてコンサルタントとアーキテクトが挙げられている。（私も4年前にアーキテクトを目指すといったくらいだから、最近と言っても4年前にはあった概念だ）
「ITアーキテクト×コンサルタント」というそのものずばりの本がある。同書では、その仕事内容について、以下のような説明がされている。
ITアーキテクトは以下の3つの側面を役割として持っています。
- 技術動向に精通して技術の本質を見極め、優れた価値判断をする技術アドバイザー
- 技術を適材適所に配置して全体最適のアーキテクチャを描くデザイナー
- ユーザや開発者などのステークホルダーを調整して成功に導くコーディネータ
一方、コンサルタントについては、こうだ。
- 顧客の問題を正しく捉え、問題解決手法を活用して解決に導く問題解決人
- 顧客以上の業界・業務知識を保有し、戦略や業務プロセスを改革する業務エキスパート
- 顧客企業内のさまざまなステークホルダーを説得して実行の軌道に乗せるコーディネータ
これはつまり、SEが業務と技術の両方をやっているところ、業務を特化してレベルを上げるとコンサルタントになり、技術を特化してレベルを上げるとアーキテクトになると言っているように見える。「ITアーキテクトは技術にこだわるエンジニアに次のキャリアとして人気がある」といった記述もある。
これを読むと、私は辟易とする。結局、業務と技術の両方をやることは出来ないのかと。そうして、どちらかを選ばなければならないと思って、私のSEとしてのアイデンティティは崩壊するのである。私はどちらかと言えば業務の人間だと思っているが、といって技術に興味がないわけではない（むしろ、技術の人と見られている期間が長かった）。ただ、技術だけを突き詰めるのは嫌だとは思っているが。そういう自分は、どうすれば良いのかと。
SEの仕事は、顧客の業務も、それをどうやって実装するかも、つまり、業務と技術の両方に触れるので、比較的気に入っている。ただ、扱う領域が小さいのは不満である。だからキャリアアップを考えるのだが、キャリアアップするには業務と技術のどちらかを捨てなければならない（もしくは両方捨ててマネージャになる）ということなのか。
ここで先ほどの象設計集団の話に戻ると、彼らの仕事はコンサルタントのそれだろうか？（技術に特化した）アーキテクトのそれだろうか？私には、どちらでもない。むしろ、その両方のように見える。
今日、「ソフトウェアアーキテクトが知るべき97のこと」という本を買ってきた。まだ、すべてを読み終えていないが、冒頭の監修者まえがきに、監修の鈴木雄介さん（アークランプの人だね）が、このようなことを書いている。
ソフトウェア・アーキテクトは実に中途半端な立ち位置にいます。ビジネスサイドの人間よりは技術に詳しく、プログラマ達よりはビジネスサイドの都合が分かっています。
これは非常に短いながら、アーキテクトの立ち位置を見事に言い表していると思う。そして、我が意を得たりと思うアーキテクト像だ。業務か技術の択一ではなく、どっちも、の人がアーキテクトだ。4年前に私がなりたいと言ったアーキテクトは、そういう人である。（その宣言を会社でして、与えられた仕事がDBMSのクラスタリングと運用設計だった。それはやっぱり、何か違うと思う。）
実は情報処理技術者試験の最上位であるLevel4の試験で、私の思うような職種の設定がなされている。
- プロジェクトマネージャ
- ITストラテジスト
- システムアーキテクト
- ITスペシャリスト（データベース、ネットワーク、情報セキュリティ、エンベデッドシステム）
業務の人がコンサルタントを目指すならITストラテジストであろう。技術の人が技術を極めればITスペシャリストである。そして、システムアーキテクトはそのどちらでもない部分にポジショニングしている。そして、すべてLevel4で同位であり、システムアーキテクトが、ITストラテジストやITスペシャリストへの中間点では決してない（無論、プロジェクトマネージャへの中間点でもない）ことが重要だ。
ここまで考えて、ようやく私のテンションは上がってきた。業務か技術かの選択ではなく、その中間に立つエンジニアであり、それを高めていくキャリアを作っていけば良いということなのだ。