architect

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

ちなみに、私は現時点で世の中で一般的だろうと見ているアーキテクト像は、プログラマの親分です。かつ、顧客と要件の話も出来て、業務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（もちろん、それは重要なことだ。）より、アーキテクトの方が、プログラマの気持ちに近いということもあるだろうか。

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

さて、北海道でクラーク博士に「プロのアーキテクトになる」と誓って、東京に帰って来たのである。
ゴールデンウィークは、まだ4日ほどあるので、その間に、もう少しアーキテクトについて、これから数回の記事を使って、考えを深めておこうと思う。

まず、私の中でのアーキテクト概念の源泉について、思い出しておこう。

私が、「アーキテクト」という言葉にであったのは、そもそも何時のことだっただろうか。
今から、5年ほど前になるが、業界でも腕に覚えありのM社の研修を受けたことがある。オブジェクト指向を数日かけてじっくり教えるというもので、私は随分、薫陶を受けた。
その研修では、業界でも特に有名なH氏も講壇に立った。そこで、H氏は以下のようなことを語ったのである。（もう、5年前のことなので、意訳だ。）

• アーキテクチャが重要であり、SEとして顧客と会話をする時も、腹の中でどのようなアーキテクチャで作るかを常に考えておくこと。
• 今までは、PMとSEとPGがプロジェクトの登場人物だったが、これからは、そこに「アーキテクト」が加わる。
• フレームワークは、SIerにとって資産である。フレームワークを開発する際は、経営が十分にコミットしていなければならない。

この3点は、当時の私が、特に感じ入った内容として、研修後に自社のメンバーや上司に言って回ったことだ。
ここで、アーキテクトという言葉に出会ったのである。

研修では、オブジェクト指向の他に、RUPについても講義があった。
RUPでは、アーキテクチャセントリックと言われるように、特にアーキテクチャが重視される。
私は、自社でいくつかの研修講師をした経験があるが、この辺の話も十八番にしている。

余談だが、私が一緒に仕事をしたことのある、オブジェクト指向の大家はY氏だが、当時はH氏を知らなかったようである。
今では、Y氏とH氏はあるグループで啓蒙活動を一緒にやられている。業界は狭いものだ。