• まえがき

■第一部　UMLは手段

第1章　なぜUMLで失敗するのか

• 一　代表的な現場の声
  • 普及が進むUML／何がいいのかわからない
• 二　UMLとの接触
  • これからはUML／広がる夢
• 三　UMLの研修
  • 社内研修／プロジェクトメンバーの反応
• 四　UMLの適用
  • 設計／実装／テスト
• 五　プロジェクトの結果
  • 何が嬉しいのか／深いため息
• 六　失敗の原因は何か

第2章　負け組パターンを分析する

• 一 「UMLとの接触」での失敗原因
  • (1)受動的理由による導入／(2)トレーニングやツールへの過剰な期待
• 二 「UMLの研修」での失敗原因
  • (3)レベル設定の欠如／(4)技術の違いに対する認識不足
• 三 「UMLの適用」での失敗原因
  • (5)UMLと設計方法論を混同／(6)メンターの不在／(7)UMLと開発プロセスの分離
• 四　これをやったら負け組になる
  • 目的なき導入／UMLと設計方法論を混同／UMLと開発プロセスの分離／目標なきトレーニング

第3章　勝ち組はここが違う

• 一　勝ち組に共通する成功パターン
  • 目的と手段／成功のポイント
• 二　目的の明確化
  • UML適用の動機（期待する効果）／開発工程のどこに適用したいのか
• 三　企業ニーズに合わせたUML適用と技術者育成
  • 資産構築技術者／第一線技術者／構築技術者／企業ニーズと現状のミスマッチ
• 四　企業ニーズに合わせた表記のフィルタリング
  • 記述粒度はフィルタリングできる／ポイントはコアコンピタンスとテスト

第4章　コアコンピタンス経営によるUML戦略

• 一　システム開発における開発プロセス
• 二　コアコンピタンス別UML適用法
  • 専門重視型／ソフトウェア開発型／IT資産構築型／保守運用型
• 三　残る課題
  • モデラーの発掘／三つのタイプの技術者への誤解
• 四　企業ニーズに合わせてUMLを適用するには
  • 目的の明確化／コアコンピタンスの認識／適材適所の技術者配置と育成／UMLの適用プランを立てる

■第二部　アーキテクトに未来を賭けた

第1章　システムトラブルはなぜ繰り返されるのか

• 一　不足する業務系アーキテクト
• 二　こんなトラブルが起きていませんか？
  • よくあるシステムトラブル／トラブルの原因
• 三　なぜこのようなトラブルが起きるのか
  • メインフレームは「守られた開発」／分散システムは「自由度の高い開発」／アーキテクト不在がトラブルの原因

第2章　アーキテクトに向いている人，向いていない人

• 一　アーキテクトの素養
  • チェックリスト／アーキテクトに必要なスキル
• 二　ピープルスキル
  • 協調関係を築く／リーダーシップとマネジメント／話し上手より聞き上手／仕事をふるのが得意／オーラを持つ／チャレンジャブルである
• 三　テクニカルスキル
  • 技術力／適用力／スキルアップ時間の確保
• 四　コミュニケーションスキル
  • 聞くこと，伝えること／コミュニケーション手段
• 五　変化予測力
  • 技術と社会／良品を見分ける力
• 六　美的センス
  • シンプルこそ美しい／形は機能に従う

第3章　間違いだらけのアーキテクト選び

• 一　適任者がいない
• 二　間違った選抜基準
  • 開発経験が長いだけの技術者／ルーティンワークをしている技術者／分散系システムのプログラマー・設計者／最新技術だけが好きな技術者
• 三　アーキテクト候補のいる場所
  • 大規模化の弊害／「そんなものがあるなら見せてみろ」／正しいアーキテクト候補とは／ミドルの開発経験者／保守開発の経験者

第4章　アーキテクトを育成する

• 一　訓練が必要
  • 基本的な誤り／「教育」と「訓練」
• 二　基礎訓練
  • ステップ1：アセスメントとポジショニング／ステップ2：道具を使えるようになる／
  • ステップ3：見習い／ステップ4：定期的なフィードバック
• 三　自己成長のサイクルに乗ったアーキテクト

• あとがき