井上 研一 [itemlink post_id=”1760″]
読み終えたので、レビューしておく。
本書では、「アーキテクトは何をする人か？」ということが、現時点で、広く共有出来そうな内容が、平易に説明されている。
と、いうのは、現時点ではやはりアーキテクトというものの役割が、明確には定義されていないのではないかと思っていて、その上で最大公約数的かつ現実的に定義された内容だと思うからだ。
役割が明確に定義されないという意味では、SEだって同じようなものだ。
今後はPGのネクストキャリアとして、どちらかと言えば業務寄りならSE、同じく技術寄りならアーキテクトと言われるのではないかと思ったりする。
そうなれば、今よりはSEにせよ、アーキテクトにせよ、役割が明確になる。
（個人的には、それで良いと思っているわけではないが…。）
本書は、多くの部分が、新規システムの開発プロジェクトにおけるアーキテクトの役割を、ストーリー仕立てで説明することに充てられている。
そこでは、重要な考え方になるものが、格言的にピックアップされているので、後で振り返ったときにも読みやすいだろう。
ページ数は少ないが、開発プロジェクト以外でのアーキテクトの役割についても説明が行われているのは、個人的な思いとも共感する。
例えば、新技術の発掘→ビジネス上の活用シーンの探求→プリセールスに同行といったシチュエーションは、「技術の進歩を価値に変える」という（私の）価値観において、「進歩」に重心を置いた発想だ。
全体的に良書だと思うが、唯一、欠けていると思うのは、アーキテクトがSEの1つの役割ではなく、専門の職種となった時に、その上司は誰か？アーキテクトの管理者は存在しないのか？ということが、触れられていないことだ。
ストーリー仕立ての記述では、「マネジャー」と呼ばれる人物が登場するが、どうやら配下にはアーキテクトだけでなくSEもPMも存在しているようで、システム開発部の部長や課長といった存在に見える。
SIerの中でアーキテクトが職種として存在するようになれば、当然に組織立って動くことになるだろう。そうなれば、管理者が必要となるのは必然だ。
また、SIerの社員としてのアーキテクトは、SIerの経営判断としての技術の方向性に、影響を受けるのは間違いないし、そもそも、その先導役となる立場ではないだろうか？
そうすると、CTOをトップとする技術系の組織ツリーが構築されることになると思うのだが、どうだろうか。
タイトルの「“プログラマ”の本懐」には、若干の違和感を感じたりするが、それは私だけかもしれない？