ソフトウェアエンジニア@横浜の徒然日記

SDGs,人と組織,ソフトウェア開発について知ったことを徒然なるままに発信

MENU

アーキテクトって何よ?〜ソフトウェアアーキテクトが知るべき97のこと〜

①アーキテクチャとビジネス
②アーキテクトとデベロッパー
③アーキテクチャ選定にまつわる話
④アーキテクトのスキル 
等々が縦横無人に語られている本。 
軽く読み流そうと思うと
意外と咀嚼するのに時間がかかるので注意。 

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

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

  • 作者: 鈴木雄介,Richard Monson-Haefel,長尾高弘
  • 出版社/メーカー: オライリージャパン
  • 発売日: 2009/10/05
  • メディア: 単行本(ソフトカバー)
  • 購入: 17人 クリック: 362回
  • この商品を含むブログ (82件) を見る
 


■目次
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.あなたの知識と経験を共有しよう
55.パターンの病理学
56.たとえ話の使いすぎに注意
57.アプリケーションの保守に力を入れよ
58.3つから2つだけを選ぶ覚悟を決めよ
59.趣味や個人的な意見ではなく、原理原則に従え
60.動くスケルトンから始めよ
61.データが全て
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.説明責任を果たす

■なぜこの本を読んだのか?
ソフトウェアアーキテクトの仕事をしたい
と考えていた時期にそもそもアーキテクト
って何するのよ?という疑問があった。
そんな時にアーキテクト達への
インタビュー集である本書を読んだ。

■いつこの本を読んだのか?
2009年(アーキテクト時代)

■この本を読んで変わったこと
印象に残ったのは以下の話だった。

①アーキテクチャとビジネス
アーキテクチャビジネスに依存する。
故にビジネスサイドに主導権を持たせる形で
アーキテクチャを構築する必要がある。
そうしなければそのアーキテクチャは
無くなることになるだろう。

17.ビジネスサイドに主導権を渡せ
30.ビジネスドメインを理解せよ
72.優れたコンテンツは優れたシステムを作る
85.強力なビジネスケースを作れ
92.新しい言語を学べ
日本-02.ビジネス・アーキテクトを目指せ

②アーキテクトとデベロッパー
アーキテクトは技術を俯瞰的に統括する役割。
故に各技術へ精通していることが不可欠。
精通することでデベロッパーと良好な関係が築ける。
一方でデベロッパーが設計・実装しやすい
環境づくりを行うことも必要。

11.500行の仕様書より1行のコード
41.ダイアグラムの空白に注意せよ
51.デベロッパーに力を
63.アーキテクトは何よりもまずデベロッパーであれ
68.ハードウェアの理解も必要
75.設計するならコーディングできなければならない
90.問題解決に情熱を注げるデベロッパーを探して手放すな

③アーキテクチャ選定にまつわる話
アーキテクチャを選定する際は
「なぜそのアーキテクチャにしたのか」
を個々のアーキテクチャに対して
説明できなければいけない。
その際に大事なのは
「なにが問題なのか」と言う
問題設定だ。

22.アーキテクチャーではトレードオフは避けられない
43.状況が何よりも大切
52.理由を書き留めよ
53.暗黙の仮定、特に自分自身のものを疑え
64.ROI変数を意識せよ
77.しっかりとした問題には高品質のソリューションが与えられる
79.自分の判断に責任を持て
84.フレームワークは相性で選べ

④アーキテクトのスキル 
アーキテクトは何よりも本質的な
技術を追求する必要がある。

時に最新技術に飛びつきたくなることが
あるかもしれないが,取り組む前に
その価値を慎重に見極めなければならない。

時にトリッキーな手法を利用することが
あるかもしれないが,それを常としてはならない。

59.趣味や個人的な意見ではなく、原理原則に従え
80.クレバーになるな
81.武器は慎重に選べ、安易に手放すな。
日本-06.手段的な技術と陳腐化しない本質的な技術