ソフトウェアアーキテクトが知るべき97のこと

目次
監修者まえがき
はじめに

01　システムの要件よりも履歴書の見栄えを優先させてはならない
    ニティン・ボーワンカー
02　本質的な複雑さは単純に、付随的な複雑さは取り除け
    ニール・フォード
03　最大の問題は、たぶん技術的なことではない
    マーク・ラム
04　まずコミュニケーション、そのための明快さととリーダーシップ
    マーク・リチャーズ
05　パフォーマンスの決め手はアーキテクチャー
    ランディ・スタッフォード
06　要求仕様の本当の意味を探れ
    アイナー・ランドル
07　立ち上がろう！
    ウディ・ダーハン
08　すべてのものは、かならずエラーを起こす
    マイケル・ナイガード
09　それは交渉だということに気付け
    マイケル・ナイガード
10　定量化を求めよ
    キース・ブレイスウェイト
11　500行の仕様書より1行のコード
    アリソン・ランダル
12　フリーサイズのソリューションを求めるな
    ランディ・スタッフォード
13　パフォーマンスの検討に早過ぎるということはない
    レベッカ・パーソンズ
14　アーキテクチャーとはバランスを取ること
    ランディ・スタッフォード
15　犯罪的なコミットエンドランを防ぐには
    ニクラス・ニルソン
16　選択肢を1つに絞らないための現実的な方法
    キース・ブレイスウェイト
17　ビジネスサイドに主導権を渡せ
    デーブ・ミュアヘッド
18　一般性より単純性、再利用よりもまず最初に使えること
    ケブリン・ヘニー
19　アーキテクトは手を汚さなければならない
    ジョン・デービーズ
20　継続的にインテグレーションを実行せよ
    デビッド・バートレット
21　日程による失敗を避けるために
    ノーマン・カーノベール
22　アーキテクチャーではトレードオフは避けられない
    マーク・リチャーズ
23　要塞としてのデータベース
    ダン・チャック
24　不確定性が潜むという感覚を磨け
    ケブリン・ヘニー
25　鏡に映る問題は見かけよりも大きい
    デーブ・クイック
26　再利用は、アーキテクチャーだけではなく人と教育の問題と心得よ
    ジェレミー・メイヤー
27　アーキテクチャーにI（自我）なし
    デーブ・クイック
28　地上300mからの目
    エリック・ドーネンバーグ
29　選ぶ前に試せ
    　エリック・ドーネンバーグ
30　ビジネスドメインを理解せよ
    　マーク・リチャーズ
31　プログラミングは製造ではなく設計だ
    アイナー・ランドル
32　デベロッパーに自己裁量を与えよ
    フィリップ・ネルソン
33　時間がすべてを変える
    フィリップ・ネルソン
34　「ソフトウェア・アーキテクト」のAは小文字だけ。それで満足せよ
    バリー・ホーキンス
35　大きなスコープは敵
    デーブ・クイック
36　役者ではなく執事になれ
    バリー・ホーキンス
37　ソフトウェア・アーキテクチャーが倫理的な意味を持つことを考えよ
    マイケル・ナイガード
38　摩天楼はスケーラブルではない
    マイケル・ナイガード
39　未来はヘテロジニアスとともにある
    エドワード・ガーソン
40　パフォーマンスがまず大事
    クレイグ・ラッセル
41　ダイアグラムの空白に注意せよ
    マイケル・ナイガード
42　デザインパターンに習熟せよ
    マーク・リチャーズ
43　状況が何よりも大切
    エドワード・ガーソン
44　ドワーフ、エルフ、ウィザード、キングの4種類の人々
    エバン・コフスキー
45　建物のアーキテクト（建築家）から学ぼう
    キース・ブレイスウェイト
46　繰り返しと戦え
    ニクラス・ニルソン
47　現実の世界にようこそ
    グレガー・ホープ
48　支配せず、観察せよ
    グレガー・ホープ
49　アーキテクトは2つの顔を持つ
    デビッド・バートレット
50　アーキテクトは境界とインターフェイスに注意を注げ
    アイナー・ランドル
51　デベロッパーに力を
    ティモシー・ハイ
52　理由を書き留めよ
    ティモシー・ハイ
53　暗黙の仮定、特に自分自身のものを疑え
    ティモシー・ハイ
54　あなたの知識と経験を共有しよう
    ポール・W・ホーマー
55　パターンの病理学
    チャド・ラヴィーニュ
56　たとえ話の使いすぎに注意
    デビッド・イング
57　アプリケーションの保守に力を入れよ
    ムセディシ・カスパー
58　3つから2つだけを選ぶ覚悟を決めよ
    ビル・デオーラ
59　趣味や個人的な意見ではなく、原理原則に従え
    マイケル・ハーマー
60　動くスケルトンから始めよ
    クリント・シャンク
61　データがすべて
    ポール・W・ホーマー
62　単純なものは単純に
    チャド・ラヴィーニュ
63　アーキテクトは何よりもまずデベロッパーであれ
    マイク・ブラウン
64　ROI変数を意識せよ
    ジョージ・マラミディス
65　目の前にあるのはレガシーシステムだという前提で設計せよ
    デーブ・アンダーソン
66　解決策が1つしかない場合には、セカンドオピニオンを求めよ
    ティモシー・ハイ
67　変化の影響を把握せよ
    ダグ・クロフォード
68ハードウェアの理解も必要
    カメル・ウィックラマナヤケ
69　今の近道、後で大損
    スコット・マクフィー
70　「完璧」は、「十分よい」の敵
    グレッグ・ナイバーグ
71　「よいアイデア」を避けよ
    グレッグ・ナイバーグ
72　優れたコンテンツは優れたシステムを作る
    ズービン・ワディア
73　怒れるアーキテクトとしてビジネスと対立するな
    チャド・ラヴィーニュ
74　主要な指標の耐久性を試してどこで壊れるかを確かめよ
    ステファン・ジョーンズ
75　設計するならコーディングできなければならない
    マイク・ブラウン
76　他の名前でバラを呼べば、キャベツにしかならない
    サム・ガーディナー
77　しっかりとした問題には高品質のソリューションが与えられる
    サム・ガーディナー
78　勤勉さが必要
    ブライアン・ハート
79　自分の判断に責任を持て
    イ・ジュウ
80　クレバーになるな
    イーベン・ヒューイット
81　武器は慎重に選べ、安易に手放すな
    チャド・ラヴィーニュ
82　本当の顧客は目の前の顧客ではない
    イーベン・ヒューイット
83　設計した通りにはならない
    ピーター・ジラードモス
84　フレームワークは相性で選べ
    エリック・ホーソーン
85　強力なビジネスケースを作れ
    イ・ジュウ
86　コードだけではなくデータをコントロールせよ
    チャド・ラヴィーニュ
87　技術上の借金は返済せよ
    バークハート・ハフネーゲル
88　問題を解こうとするな
    イーベン・ヒューイット
89　システムは用具的に作れ
    キース・ブレイスウェイト
90　問題解決に情熱を注げるデベロッパーを探して手放すな
    チャド・ラヴィーニュ
91　ソフトウェアは実際には存在しない
    チャド・ラヴィーニュ
92　新しい言語を学べ
    バークハート・ハフネーゲル
93　未来永劫安泰なソリューションはない
    リチャード・モンソンヘーフェル
94　ユーザーの拒否感情の問題
    ノーマン・カーノベール
95　コンソメの重要性
    イーベン・ヒューイット
96　エンドユーザーの立場からはインターフェイスこそがシステム
    ヴィナヤク・ヘッジ
97　優れたソフトウェアは構築されるのではなく、成長する
    ビル・デオーラ

日本人アーキテクトによる知っておくべき11のこと

01　アーキテクチャは縦と横の基本構造を持つ
    萩原正義
02　ビジネス・アーキテクトを目指せ
    萩本順三
03　問題にフォーカスせよ
    榊原彰
04　問題にとらわれるな
    榊原彰
05　煩雑なことを非属人化し、創造性を高める
    萩原正義
06　手段的な技術と陳腐化しない本質的な技術
    伊藤直也
07　開発スタイルをデザインする
    小野和俊
08　システムではなく、コミュニケーションをデザインせよ
    鈴木雄介
09　移り気な利用者を捉える
    牧野友紀
10　受動的アーキテクトと能動的アーキテクト
    江島健太郎
11　説明責任を果たす
    萩本順三

索引