プログラマの本懐 山本啓二（日経BP社）

1.アーキテクトの仕事
(1)メインの仕事は「雛型を作る」
(2)用語やドキュメントのみならず、抽象的な「方針」（アーキテクチャ）を実装として提供
(3)仕組み（フレームワーク）の導入作業まで支援
(4)最終目的はアーキテクトをシステムに浸透させ、トラブルを解消

2.アーキテクトが行う要件定義
(1)例えば、以下のような上流工程の成果物を整える
・機能の目的がわからない（業務がわからない）→用語集作成、説明
・A画面とB画面で微妙にフローが異なり流用ができない→画面の標準化、統一化
(2)要件分析では重要な登場人物（オブジェクト）の洗い出し、決定を行う(概念モデリング設計）
・要件分析の打合せではオブザーバの位置付け
　実現可能性やリスク、コスト上の制約条件など実装上の問題について技術的アドバイス
(3)仕様設計では登場人物（アクター）の何を行うか（ユースケース）を記述し、画面として設計していく（概要設計）
　
3.アーキテクチャを設計する
(1)要件からアーキテクチャが生まれる（まず要件ありき）
・解決すべき課題である「要件」の解決策として「アーキテクチャ」を決定する
(2)要件定義の段階でどのくらい技術的課題を整理しておくか
・現状は個人の経験が大きい
・いわゆる「不吉な匂い」をどこまで嗅ぎ付けられるかによる
(3)設計書にどこまで記述するか
・全ての利用者が理解できるように暗黙値を全て記入する事は不可能
・冒頭に要求される前提知識と参考文献を列挙
・ユースケース図から更にシステム上「どのように」やりとりされるのかまで記述
・技術要素（例.SessionBean）は「なぜ」「なんのために」使うのか必ず説明
・「ログ」「例外」などつまづきやすい箇所は念入りに
・Web/EJBの層間やサブシステム間インタフェース例外の扱い方は事前に整理
・コーディング規約はバランスよく
　①読み人にとって「読みにくいコード」の排除
　②書く人にとって「書きにくいコード」の排除
　③具体的にはインタフェース設計（スコープ）、APIドキュメント（コメント）、命名ルールが必要
・パフォーマンス設計は全体の20％に起因する場合が多い（80:20ルール）ため、
　早い段階でパフォーマンス重視の設計は行わない

4.フレームワークを用意する
(1)全ての品質特性（信頼性、保守性など）は満たせないため、優先順位を決める
(2)品質特性を満たすアーキテクチャは客先への提案・質問で固めていくこと
　（非機能要件は、客先から要求されない場合が多いため）
(3)メリット（定型的処理を部品で対応するため、その分のコーディングが不要など）
　を動機付けとし、アーキテクチャに沿ったフレームワークを導入