『UMLは手段』2008/05/18さっきまで読んでました。この頃は質のいい新書が見つからなくなってるので,あまり新書は読んでないんですけど,ちょいと時間があったので暇つぶしに読む。それにしても,たかだか200頁弱の内容で840円は高いなぁ......。600円くらいだろうと思って,値段を見ないままレジに持ってったらびびった。本書は二部構成になっていて,前半は「UMLは手段」,後半は「アーキテクトに未来を賭けた」と題されています。ついて書かれているわけじゃありません。業界と言われているところでは,手段が目的になっちゃうところが,しばしばあったりします。あたしゃこのサイトで,ダメだと思う設計者を「丸や四角を描く人」とかいった具合に表現することがあるんですけど,それは文字通り,「丸や四角を描くこと」がお仕事になっちゃっている人,とかいった意味を含めていたりします。「設計する手段」あるいは「設計を伝える手段」として,描いているわけじゃない。プロジェクトにも反映されないから,実質的に原価とし計上できない無駄な作業。さんは,読んでみると参考になるかも。一方で,後半の,「アーキテクトに未来を賭けた」では,「アーキテクト」の必要性と発掘/養成について書かれています。一時期前に流行ったコンサルブームは影を潜めるようになって,最近は「アーキテクト」ブームらしい。聞いた話ですけれど,一時期前のコンサルさんで,こんな話をしている人がいたそうです。コーディングなんかできなくたっていいんだよ!できるやつを使えりゃいいんだ。たしかに,コンサルさんの主たる業務は実装じゃないわけですけれど,実装フェイズでやっていることを何も知らなくていいなんてことはありません。夢見がちで言葉遊びが大好きなコンサルさんに限って,実行力/実装力に欠けるもんだから,そういったコンサルさんの仕事(夢物語)を請けちゃった実装部隊は,大変困るんだとか......。言うだけ番長ってやつか。「アーキテクト」というのが,そうした反省をふまえているのかは知らないですけれど,本書によると「アーキテクト」はもっと実行/実践寄りの仕事を任務にするそうです。具体的には,要件から「実装可能な」設計に落とし込んで,かつ実装部隊の取りまとめや調整を行う人みたい。いわゆる「アプリケーションエンジニア」に近いのかしらん。実際,保守性/拡張性の高いシステムを構築する場合,システムの全体を見渡すことができる人ってのは,必要不可欠です。その意味で言えば,これまでもアーキテクトなる人がいたわけですけれど,本書によると,そういう人の中には,技術的なバックグラウンドが頼りない人も少なくなかったんだとか。「アーキテクト」ってな言葉自体,最近の言葉ですから,言葉の意味も含めて興味のある方はご一読をば。いう人って,実際とても重宝する人だから,負荷が集中するんだろうなぁ......。