荒井玲子『UMLは手段』
新しいことについていけてない上司さん向けの本……？ というのが印象。
文章はとても平易で、エピソードを織りまぜて親しみやすい構成になっているけれど、UMLについてほぼ予備知識をもたない僕からすると、用語の遣われ方にややわかりづらさを感じた。素人はさきに「図解UML」みたいな本を流し読みしておくとスムーズかもしれない。なんの役に立つのが謎ですが、自分用の用語リストを下に載せておきます。
名言：「すご。デザインパターン、ヤバすぎ。マジで」(p.29)
第一部「UMLは手段」より。
第二部「アーキテクトに未来を賭けた」より。
こちらは「UMLは手段」とはべつものと思ってきもちを切り替えたほうがいい。ただし、ちょっとした関わりも感じられる。それは「適正」について。
- 「アーキテクトがオーラを持っているというのは本当です」(p.129)
- 吹いたｗ しかし「技術的自信」による「落ち着き」というのは納得。
- p.144
- 否定要素をリスト化すんなｗｗｗ 「A、B、C……ではない」という日本語ならではの悪文法をなぜあえて再現するｗｗｗ 分類の仕方にもたまに違和感を感じるし、どうにもこのひとの表現は僕にしっくりこない。
- 「形は機能に従う」（ルイス・サリバン）(p.150)
- シンプルなものが強い、というのはソフトにもハードにも通じる普遍的方針。これは高校生のころの研修旅行で、バルサで橋作りをしたときに実感レベルで理解した。
- 「日々与えられている仕事をきっちりやっていると、自分がやりたい仕事は自分にくるものです。やりたい仕事がぜんぜんこない場合は、「自分にはまだその仕事をやれるだけのスキルがないのだ」と考え、スキル向上に励んでください」(p.188)
- ああー、その通り、たぶん！ いまとさきをみる！
- 「多くの人はアーキテクトの素養の「一部」をすでに持っているのです。（中略）現在の自分に足りないスキルを身につけてしまえば、誰でもアーキテクトになれるのです」(p.123)
- 啓発的な言い回しではある。しかし「適正」という発想と矛盾してしまいそうな気配も感じる。第一部における技術者の分類も想起させられる。適正は確かにある、しかし、技術の向上によってある程度は埋め合わせが効く、という折衷的な解釈が無難だろうか……。
- 素養と技術をどこで区別したらいいのだろう？ むしろ「性格」や「価値観」といった「技術によって変えることは可能だが、本人に変える意思がないもの」を「素養」とよんでしまうと、割り切りがいい。ただ、それだと、向上心のあるひとには「性格」や「価値観」がない、という奇妙な事態を引き起こしてしまう（笑） まあ、このへんは言葉遊びなんすけどね。
- とりあえず、いまの僕が思っているのは、行動様式に関する大部分は技術による、つまり変更可能だ、というスタンスなので、とりあえずは「適正」なんていうことを考えずに気ままに勉強していこうと思う。いや、わがままな「性格」や「価値観」を自覚している、という矛盾もあるのですが（笑）
- 「技術」よりも「訓練」と言うほうが適当か。
第一部の用語リスト。
「これがわかってたらこの本をスムーズに読めていただろうなあ」という用語をピックアップしてあります。ただしろくに調べ直したりはしてないので、いまだにわからない用語のリストアップでもあります。ひとりかふたりくらいのひとには参考になるだろうから、いちおう載せてみます（そのうちひとりは僕です、というツチケン節）。
説明はおれオプティミゼーションなので注意。
- UML
- 表記の方法であって、設計の方法ではない。ましてや、オブジェクト指向の設計方法そのもの、などではない。なるほど、これは僕も思い違いしていた。
- Notation / Semantics
- 要素と関係？（たぶん違う）
- メンター
- p.187 のイラストを見れば一発。ゆるやかな指導者、といったところか。
- クラス図・シーケンス図
- このへん、なんの説明もなく用いられて戸惑った。本書が「UML」自体の入門書ではないゆえんか。
- デザインパターン
- 利便性と硬直性。初心者が扱うとケガをする。硬直性が「変更」を前提にしたデメリットであることに注目！ つくったものをいかに保守するかということは、UMLの本質に関わる（だろう）視点なので。
- 目的
- 用語じゃないけど（笑） タイトルである「UMLは手段」という言い回しに注目してもらいたい。これは裏返せば「目的はUML以外」ということ、もっといえば「目的を考えろ！」というメッセージが込められている（はず！）。だからこそ、この本に「UML」自体に関する内容を期待するのはお門違いといったところ。なるほど、自分で納得した。
- 開発工程
- 開発に関する全部。
- コアコンピタンス
- 開発に関する全部、のなかで、どこを強調するか。「強み」という訳語もあるけど、むしろ「強み」にしたい部分、つまり強調部分（「強み」の選択）、として考えたほうが理解しやすいと思う。はじめから強いわけないだろ？ ちょっと言い過ぎた。
- 資産構築技術者・第一線技術者・構築技術者
- このへんの分類の仕方、および言葉選びに馴染めない。ただ、それぞれの立場は段階的なものではなく、適正（スキルとセンス）によって配分されるべき、という考え方には納得できる。
- フレームワーク
- なんとなくわかる。
- ユースケースモデル
- なんだそりゃ？
- コンポーネント
- わかる。たぶん。
- 記述粒度
- 粒度？ 物理学用語か何かですか？
- 専門重視型・ソフトウェア開発型・IT資産構築型・保守運営型
- ふーん。
- 「〜についてフルスペック」
- 著者特有の言い回しだなあ。意味はわかる。
- メタモデル
- ビジネス概念を表したモデルですって。
- 抽象化思考・美的センス
- モデラー（←ださいｗ）に求められるもの。開発の業界でこういった言葉が強調されるあたり、新しいパラダイムの波が確実に迫っていることを思わせる。よく知らんが。
