読書メモ

・「UMLは手段」
（荒井 玲子 ：著、技評SE新書　\840） : 2009.06.06

内容と感想：
　「まえがき」でUMLを適用した失敗プロジェクトの増加について触れている。 本書はそうした現状に問題意識をもって書かれた。
　第一部ではその失敗の原因を探り、それを解決する方法を紹介し、 プロジェクト成功のための実践的なUMLの適用法を説明している。 第二部では「アーキテクト」という新たな職種と求められるスキル、その育成について説明している。
　タイトルが言うとおり、UMLは手段であって、表記方法だけを知っていてもモデリングは出来ない。 そこには分析・設計のモデリング知識が必要とされる。 しかし第一部・第３章にもあるように全ての技術者がフルスペックのUML知識を持つ必要はない。 本書では技術者に必要とされるUMLスキルを３種類（資産構築技術者、第一線技術者、構築技術者）に分けて説明している。 つまり社内での役割によって身に付けておくべきスキルが異なるのである。
　また同・第４章では開発企業の強み（コアコンピタンス）に応じてUMLの適用方法が異なることを、 ４つのタイプに分けて述べている。 これらからは、企業に人材育成方法の最適化を迫ることに気づかされる。 自分の会社や組織の強みを把握して、UMLのスキル獲得を効率よく行なう必要がある。 これはUMLに限ったことではない。
　同じ章には「企業資産としての技術者ポートフォリオ」という表現が出てくるが、 自社の立ち位置を見つめ直し、武器となる技術者育成をどうしていくべきかヒントを与えてくれる。

○印象的な言葉
・成功プロジェクト：費用、要件実現率、納期が計画通りだったプロジェクト（定量的側面）。 定性的な側面は「人材育成」。メンバーが疲弊し、後悔するようでは失敗。 参加したことを誇りに思える、スキルを向上できた、成長できた。満足感、達成感。また同じメンバーでやりたい。
・トレーニングやツールへの過剰な期待。企業ニーズとトレーニングのミスマッチ
・メンテナンスされなモデル
・UMLは実際に記述して練習するのが効率的。失敗が許される場で練習すること。 プログラミングとは別の技術が要求される。マスターするには大変な時間と労力が必要。正攻法が一番の近道、安上がり。
・技術移転をしてくれるメンター
・資産構築技術者：抽象度の高いモデルの構築。プロジェクト非依存のフレームワークの開発。社内コンサル。企業資産。
・第一線技術者：プロジェクト依存モデル。プロジェクト非依存のフレームワークをプロジェクトに応じたカスタマイズ。この技術者が不足。
・構築技術者：第一線技術者の用意したモデルを利用し、実際のシステムを構築。少ない労力で大量の生産を確実に行なうことが期待される
・４タイプのコアコンピタンス：専門重視型、ソフトウエア開発型、IT資産構築型、保守運用型
・優れたモデル：保守性、拡張容易性が確保。シンプル、小さい。美しい構造。わかりやすい。長持ち
・モデラーの要件：抽象化思考、美的センス（美しいと感じる感性、美しいものを作ろうとすること）
・プロダクトライン：システムをシリーズ化して、コアの構成を資産化
・UML活用にはモデリング技術、開発プロセス、開発方法論など多くの土台となる技術が必要。パラダイムシフトを要求される。
・アーキテクト：ソフトウエアアーキテクチャの構築。リーダーシップは取るが、プロジェクトマネージャではない。 育成には初期コストもかかり、時間もかかる。かかるのは最初だけ。自己成長のサイクルに乗れば手助けは不要。
・コア技術は長期的に有効である技術を選択
・先見性：問題領域が今後どう変化するか予測。本質や構造をよく知る
・形は機能に従う（ルイス・サリバン）。装飾は不要
・訓練：短期的に実践に必要なスキルを向上させる
・教育：長期的に有効な考え方に重点。実践に即役立つとは限らない

○ネタ
・V字モデル：谷の下流よりも上流工程ほど広がりがあるのは、そこにかける工数（時間）をたっぷり取れということ。 　設計の抽象度の高さ（設計書の記述粒度）をも意味する。

-目次-
第1部 UMLは手段
　なぜUMLで失敗するのか
　負け組パターンを分析する
　勝ち組はここが違う
　コアコンピタンス経営によるUML戦略
第2部 アーキテクトに未来を賭けた
　システムトラブルはなぜ繰り返されるのか
　アーキテクトに向いている人、向いていない人
　間違いだらけのアーキテクト選び
　アーキテクトを育成する