「アーキテクト」という役職は、プログラマに近い場所から、ビジネスマンに歩み寄る綱渡しを行う職業です。ただ技術を極めれば良いと言うわけではなく、ビジネスだけを知っているのでもない。両方のいいところをあわせもった職業と言えます。
本書は、アーキテクトという役職を、時には美しく、時にはシビアに紹介しています。単なるプログラマで終わりたくはない。それでも、プロジェクトマネージャーになるよりは、技術を極めたい人に、読んで欲しい一冊です。
アーキテクトの役職を、仮想プロジェクトを通して説明しているため、実際の業務における仕事が分かりやすく解説されています。一つの例だとして受け取ればいいと思いますが、かなり面白そうな職業だと言うことが分かると思います。
アーキテクトは、チームプレイであるソフトウエア開発の中心で、ITスキルとヒューマンスキルを両輪に、プロジェクトを成功に導きます。そんなアーキテクトの役割を感じてもらえる一冊だと思います。プロジェクトマネージャーに関する書籍と言うのはあれど、アーキテクトに焦点を合わせた書籍と言うのはまだまだ少ないです。そんな中で「アーキテクトとはなんなのか」を身近に感じれる一冊になっています。
特徴
本書は、「アーキテクト」と呼ばれる職業について説明した書籍になっています。プログラマやSEからステップアップする先に、プロジェクトマネージャー以外の職業があるということを認識できる、一味違った面白さをもつ本になっています。
アーキテクトの役割を、本書の中では仮想プロジェクトを用いて説明されています。その中で、プロジェクトに必要なドキュメント、メンバーに対する配慮、設計の方針、テストの仕方、アジャイル開発についてなど、実際のプロジェクトで使っている知識を整理するのにも役立ちます。また、アーキテクチャとは何か、アーキテクチャの重要性など、ソフトウェア開発における大切なことも、一緒に学べてしまう構成になっています。
アーキテクトというと、システムの分析・設計に特化した役割だと思うかもしれませんが、本書で説明されている「アーキテクト」はそれだけではありません。技術は道具であり、お客様を幸せにするシステム、ビジネスに利益をもたらすシステムにするにはどうすればよいのかを考える職業だと言えます。
システム開発という仕事を楽しくするのは、アーキテクトの腕次第です。ただのプログラマで終わりたくないが、技術を極めたい人に、本書をおすすめします。非常に分かりやすい口調で書かれているので、とても読みやすいです。読み物として楽しんでください。
覚書き
アーキテクトとは何か
技術は道具です。自己満足のためだけに使う技術は、それがいくら高度なものでも、所詮はオモチャに過ぎません。「技術力を人のために活かす」ことを考えたとき、個別の「技術」とそこにかかわる「人」、そして「活かす」ということ、それはビジネスセンスであったり目的意識というような曖昧なものかもしれませんが、それらは等しく重要です。技術を人に結びつける橋渡しとなるのが、それらを高いレベルで兼ね備えたアーキテクトなのです。
品質のよいシステムにするために
設計・実装において、プログラマが同じ判断基準に基づいて開発することが、品質のよいシステムを作る重要なポイントです。そのためには、詳細なアーキテクチャ設計書を用意することが大切です。
アーキテクチャ設計書は、プログラマが行う設計の指針を与えるようなものを盛り込むべきです。また、前提知識となるものがある場合は、分かる形で明記しておくことが大切です。
品質のよいシステムを作るためには、アーキテクチャ設計書だけでは不十分です。設計書を見ても理解できない場合や、確実にアーキテクチャを守って開発してくれるとは限らないからです。
アーキテクチャを確実に守らせるためのルールとなるものが「フレームワーク」です。どのようなフレームワークを用意するかどうかが、アーキテクトの腕の見せ所でもあります。
トラブルプロジェクトレスキュー
破綻からの脱却には、破綻した現実にとらわれずに、まず理想形を描いてみる。
トラブルが発生すると、目の前はその問題を解決することだけしか見えなくなってしまいます。一息ついて、全体を見渡せる余裕を持ち、理想形を思い浮かべてみます。理想形が現実に実現可能かどうかを検証して、可能であれば、何とかその形に持っていけるようにすることも、アーキテクトの仕事の一つである。
トラブルにみまわれないためにアーキテクトとしてできることは、アーキテクチャで何を解決するのか、何から解決するのかを意識して、より効果的なアーキテクチャの設計と適用を行うことです。そのためには、システムで解決すべき問題点の優先順位を明確にしておくことが大切になってきます。
ウォード・カニンガムのインタビュー（パターンについて）
私が本当に言いたいのは、全てのプログラマがアーキテクトでなくてはだめだと思う、ということなんだ。アーキテクチャは極めて大事なので、誰もがいつでも気にかけていなければならないし、アーキテクチャを良くする責任を自分も負っていると考えなくちゃいけない。そうした責任を特定の個人に集中させるのは大間違いだ。もうひとつ、アーキテクチャの練習、という点がある。本当に重要なことが起きるのは前もって予測できないことが多い。だから、開発中そうしたことが起きたときに、自分が直面しているのはアーキテクチャに関わる問題なんだと認識できること、そして、アーキテクチャに関わる問題に対処する心積もりをしておくということが、パターンムーブメントの核心にあると私は強く思っているんだ。
「すべてのプログラマーよ、アーキテクトたれ。」ということですね。
参考
- 職業としてのアーキテクト。実際の開発現場ではこんな人がアーキテクトです。
- アーキテクトに必要なスキルの一つUML、よくまとまっています。