it

本当は楽しいIT業界――“重鎮”を超えて － ＠IT
飯尾氏は「学生や若手エンジニアはとにかく自分でスキルを磨いてほしい。そのことで、楽しい人生を送れるチャンスはほかの業界よりもある」と話す。「まずは自分が取り替え可能な人間かどうかを考えるのが非常に重要。取り替え可能なうちは幸せになれない。取り替え不可能な人間になってほしい」と技術者に期待する。

こういう記事が出るのはとても良いことだと思う。

構造上の問題を抱えた古いSI業界をさておいて、外の世界に飛び出していく。それが、今のところIT業界を楽しいと思ういちばんの近道だと思う。
しかし、それが出来るのはスキルを磨いた「本当の技術者」に限られるのではないか。

IT業界というのは基本的に技術者がすべての業界（のはず）。技術にもいろいろあって、故に技術者にもいろいろあるが、何にせよ「IT」というものに惚れて、そのスキルを高めていく技術者に対して福音がもたらされるようになるのは、結構なことだ。

ただ、SIerという種類の会社の中で（良くも悪くも）「仕事が出来る」人は、必ずしもそういう典型的な「IT」技術者ばかりではない。 例えば、顧客との調整ごとが上手いとか、いろいろ話を聞きだしてくるとか、手際よく設計書をまとめるとか、メンバーを率いる統率力があるとか、後輩を教えるのが上手いとか、上司を説得するのが上手いとか、果ては下請を叩くのが上手いとか云々。そんなことは、SIerで働いたことのある人なら、みんな知っていることだろう。

ただ、そういう、純粋な「IT」という技術とはちょっと違ったところの能力を持ってSIerで働いている人にとって、SIerやSI業界たるものの外に出て行くというのは難しいのではないか。

今のところ外に出て脚光を浴びている人というのは、「アイディアを持っていて、それを何らかのソフトウェアとして形に出来る人」だ。要はデキるプログラマな人たちなのではないか。

SIerには「プログラムなんてしばらく書いてないよ」という人がいっぱいいる。書きたいけど組織の都合上、書かせてくれないという人もいるだろうし、書きたくないなぁと思っている人もいるだろう。
でも、彼らもIT業界で働く技術者には違いない。プログラムしない彼らは、実は技術者ではないのだろうか？（私は、そういう人は「エンジニアっていうかSE？」みたいな。そういう風に思っている。いや、SE＝ソフトウェア・エンジニアなのだが、なんかエンジニアっぽくないSEというか。おそらく、ソフトウェア・エンジニアではない「SE」という職種があるのではないか。ちなみに、自分を含む。）

そういう人にとっても、IT業界が本当に楽しいと思えるのはいつになるのだろう？（そういう人が幅を利かせているからダメとか、そういう話？）

（前の記事のつづき）
ここまで、何気なく「アーキテクト」という言葉を使ってきましたが、「アーキテクト」という職種に期待される役割は、現時点では曖昧模糊としています。
世の中で言われているアーキテクトというのも、結構、幅があるようですし、私がここまでに述べてきたアーキテクト像も、必ずしも一般的なものとは言えないでしょう。

ちなみに、私は現時点で世の中で一般的だろうと見ているアーキテクト像は、プログラマの親分です。かつ、顧客と要件の話も出来て、業務SEと協力しつつも、それとは違う立場・視点で要件をまとめるというのがミソで、「（技術的）提案能力のある工場長」みたいな感じだと思っています。
しかし、技術的な提案能力と、工場長の職務は両立できるのでしょうか？これも、単に2つの職種を、人がいないから1人でやっているように見えてなりません。そもそも、SEという職種が、ありとあらゆる職種を1人でやっているようなものですが、そこからアーキテクトが分離されるだけマシといった程度のように見えます。これが、現時点でのSIerの限界と言えば、それまでですが…。

いずれにせよ、アーキテクトという言葉に踊らされてはなりません。（言葉で踊るのは、この業界の慣例だけれども…。）

さて、話が長くなってきました。
考え始めて2ヶ月が経って、その間には北海道でアーキテクト宣言したりしたわけですが、現状認識としては、こういったところです。
言ったは良いが、その「アーキテクトとは何ぞや」とというところを、はっきりさせなければ、何の意味もありません。出てくる結論は「デキるSEの代名詞」では、ダメなのです。

宣言して早々、悲観的になっています…。
というのも、SIerという会社組織に所属していれば、その分だけ役割の明確化は難しいものになるような気がしているのです。
本来なら、組織は色々な人がいるから組織なのであって、逆に言えば、組織には色々な人が存在できるのだと思うのですが…。なかなか、上手く行かないものです。ん～。

思うに、コミュニティにこそ色々な人がプロフェッショナルとして存在可能なのかもしれません。それこそ、今が、組織の時代ではなく、コミュニティの時代だということなのでしょうか…。

昨日の夜に箱根湯本の旅館で読み、今日の朝昼に℃-uteのイベントの合間で読み、何とか読み終えたのは、これでした。

北海道でアーキテクトになろう！とクラーク博士に誓い、最近は「役割としてのアーキテクトではなく、職種としてのアーキテクトが必要」と語っているので、この本はまさにベストマッチ。
箱根に行く直前に町田の三省堂書店で見つけたときには、これも運命だなぁ…と感動したわけですが…。

なぜ、「ですが…」と逆接で言っているかというと、この本を読んでアーキテクトの役割が、なおさら分からなくなったからなのです。

この本の主旨は、ソフトウェア業界ではエンジニアとサイエンティストしか存在せず、サイエンティストがやる仕事以外はすべてエンジニアが幅を利かせている。それはあまりに不明確だし、顧客としても明確な役割が見えていないのは不便。それが、ソフトウェア開発の失敗の大きな原因…という話だと思います。
そこまでは分かる。すごく、明確に理解できる。
実際、SEはあまりに広大な業務領域を持っていて、それこそ顧客へのヒアリングから、業務設計、システムとしての設計、プログラマの管理、場合によってはインフラの設計…と、プロマネがやるであろうプロジェクト体制の維持管理以外の仕事は、すべてやっているに等しい。
まぁ、はっきり言って、1人の人間がそんな広大な領域を一手に請け負うのは無理だと…。

だから、きちんと役割分担して、そこにアーキテクトが登場するというのは理解できるのです。
しかし、アーキテクトに割り当てられた役割が、最近言われているものとは、かなり違うような気がします。
ちょうど、ソフトウェア開発と建築のアナロジーを強調しているために、アーキテクト＝建築士として扱われていて、故にアーキテクトは顧客の立場に立って、ビルダー（プログラマ）らとの仲介をする役割を演じることになっています。
エンジニア（SE）は、システムの堅牢性などを保証するために存在していて、建築とのアナロジーでは、最近流行の構造計算とか、そういうことをやる人となっています。

つまり、この本でいうアーキテクトは、広大な技術知識を持ちつつも、顧客に対するヒアリングは誰よりもやる人。
最近、言われているアーキテクトは、どちらかというと技術サイドに立って、ビルダー（プログラマ）の兄貴分的な活躍も期待されるような役割ですから、真逆とまでは言わないまでも、かなりズレているのです。（「最近、言われているアーキテクト」というのも微妙な表現ですが、ここでは「プログラマの本懐」に書いているようなアーキテクトを指しています。）

全文を読む

読み終えたので、レビューしておく。

本書では、「アーキテクトは何をする人か？」ということが、現時点で、広く共有出来そうな内容が、平易に説明されている。

と、いうのは、現時点ではやはりアーキテクトというものの役割が、明確には定義されていないのではないかと思っていて、その上で最大公約数的かつ現実的に定義された内容だと思うからだ。

役割が明確に定義されないという意味では、SEだって同じようなものだ。
今後はPGのネクストキャリアとして、どちらかと言えば業務寄りならSE、同じく技術寄りならアーキテクトと言われるのではないかと思ったりする。
そうなれば、今よりはSEにせよ、アーキテクトにせよ、役割が明確になる。
（個人的には、それで良いと思っているわけではないが…。）

本書は、多くの部分が、新規システムの開発プロジェクトにおけるアーキテクトの役割を、ストーリー仕立てで説明することに充てられている。
そこでは、重要な考え方になるものが、格言的にピックアップされているので、後で振り返ったときにも読みやすいだろう。

ページ数は少ないが、開発プロジェクト以外でのアーキテクトの役割についても説明が行われているのは、個人的な思いとも共感する。
例えば、新技術の発掘→ビジネス上の活用シーンの探求→プリセールスに同行といったシチュエーションは、「技術の進歩を価値に変える」という（私の）価値観において、「進歩」に重心を置いた発想だ。

全体的に良書だと思うが、唯一、欠けていると思うのは、アーキテクトがSEの1つの役割ではなく、専門の職種となった時に、その上司は誰か？アーキテクトの管理者は存在しないのか？ということが、触れられていないことだ。
ストーリー仕立ての記述では、「マネジャー」と呼ばれる人物が登場するが、どうやら配下にはアーキテクトだけでなくSEもPMも存在しているようで、システム開発部の部長や課長といった存在に見える。

SIerの中でアーキテクトが職種として存在するようになれば、当然に組織立って動くことになるだろう。そうなれば、管理者が必要となるのは必然だ。
また、SIerの社員としてのアーキテクトは、SIerの経営判断としての技術の方向性に、影響を受けるのは間違いないし、そもそも、その先導役となる立場ではないだろうか？
そうすると、CTOをトップとする技術系の組織ツリーが構築されることになると思うのだが、どうだろうか。

タイトルの「“プログラマ”の本懐」には、若干の違和感を感じたりするが、それは私だけかもしれない？

アーキテクトについて、さらに考えを深めていこう。
今回は、私の実体験から、アーキテクトの仕事を探り出すことにする。
次回以降で、世の中一般に言われているアーキテクトとは、何かを探り、私が実体験として知っていることとの違いがあるのかどうか、明らかにしたい。
そうすれば、少なくとも私は、どういうアーキテクトになるべきかが分かるだろうから。

私が研修講師として十八番にしている、RUPのアーキテクチャセントリックは、当然、実際のプロジェクトでも取り入れている。
フレームワークを使ってみたり、プロジェクト初期から腕の良いメンバーを技術専門要員（つまりアーキテクト）として、参入させたりしているのだ。
プロジェクトでの効果は顕著なものだと認識している。
逆に、失敗したり、火を吹いているプロジェクトを観察すると、いろいろな理由があると思うが、アーキテクトがいなかったり、投入タイミングが遅すぎることが、その1つであるのは、間違いないと思っている。

では、プロジェクトの中で、アーキテクトは、どんな仕事をしたのだろうか。

• 業務SEとの非機能要件のすり合わせ。
• 非機能要件を実現するフレームワークの開発や、アーキテクチャ説明書の執筆。
• 使用するミドルウェアの調査。
• 単体テスト方法の指示。
• 開発環境の整備。（Eclipseの設定指示、CVSの導入、Antスクリプトの作成など）
• 採用するフレームワーク、アーキテクチャに沿った、サンプルアプリケーションの開発。（実際の開発の雛形となる。）
• プロジェクト進行上で出てくる技術的な問題の解決。
• PMとのプロジェクトの進め方に関するすり合わせ。（特にテストツールの使用等をWBSに関連づける場合。）

ざっと、こうしたことが思いつく。
プロジェクトの初期から中盤にかけて、かなり大量の作業があることが分かる。

私は、実際のプロジェクトにアーキテクトとして参入した経験もあるが、大抵はアーキテクトに作業をお願いする側のリーダーや、業務SEであった。
考えてみると、実際のもの作りをするプログラマとの間で、関係が深くなるのは、業務SEよりアーキテクトであったケースが多いように感じる。
これは、特にプログラマが投入された最初期において、プログラマの具体的な作業を指示するのがアーキテクトだからということが、理由として考えられる。
他にも、アーキテクトの技術力が高く、プログラマの尊敬を集められることもあるかもしれない。
顧客に顔が向いている業務SE（もちろん、それは重要なことだ。）より、アーキテクトの方が、プログラマの気持ちに近いということもあるだろうか。

いずれにせよ、私が知っているアーキテクトとは、このようなものである。