世界中のソフトウェアアーキテクトの知見や助言がまとめたられた書籍「ソフトウェアアーキテクトが知るべき97のこと」がウェブ上で無料公開中

By tec_estromberg

ソフトウェア開発のプロジェクト内で、ビジネスとプログラミング両方の知見が求められるのがソフトウェアアーキテクトで、彼らはプロジェクトを成功に導き、同時に利害関係者のニーズも満たすべく奔走する必要があります。そんなソフトウェアアーキテクトが知っておくべきことをまとめた書籍が「ソフトウェアアーキテクトが知るべき97のこと」で、世界中のソフトウェアアーキテクトが経験から得た知見や同業者へ送った助言がまとめられているのですが、これがウェブ上でも無料で見られるようになっています。

ソフトウェアアーキテクトが知るべき97のこと
http://ソフトウェアアーキテクトが知るべき97のこと.com/

掲載されているエッセイは全部で108個あり、その中でも海外のソフトウェアアーキテクトによる「知っておくべきこと」が97個、日本人アーキテクトによるものが11個あります。

外国人アーキテクトによる知っておくべき97のこと

1：システムの要件よりも履歴書の見栄えを優先させてはならない / ニティン・ボーワンカー
2：本質的な複雑さは単純に、 付随的な複雑さは取り除け / ニール・フォード
3：最大の問題は、たぶん技術的なことではない / マーク・ラム
4：まずコミュニケーション、そのための明快さとリーダーシップ / マーク・リチャーズ
5：パフォーマンスの決め手はアーキテクチャー / ランディ・スタッフォード
6：要求仕様の本当の意味を探れ / アイナー・ランドル
7：立ち上がろう！ / ウディ・ダーハン
8：すべてのものは、かならずエラーを起こす / マイケル・ナイガード
9：それは交渉だということに気付け / マイケル・ナイガード
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のこと

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

例えば「81：武器は慎重に選へ?、用意に手放すな」では、ソフトウェア開発の場に長年身を置くアーキテクトは、複数の武器(特定のコードに関する知識やノウハウなど)を持っていますが、新しいテクノロジーが登場したからといって、簡単に既に持っている武器を手放す必要はない、というアドバイスが挙げられています。新しいテクノロジーを真っ先に導入すればマイナス要素に足をひっぱられることもあるので、テクノロジーの「ビジネス」「コスト」「将来性」に着目し、トレンドに遅れないように気をつけながら新しいテクノロジーの導入について決めるべき、とのこと。

By Pedro Vezini

「コンソメの重要性」というソフトウェアアーキテクトとは無関係そうな項目では、完璧に澄んだ出来の良いコンソメをソフトウェアアーキテクトの仕事となぞらえ、システムひとつひとつの要件をつかむまで、思考を磨き、アイデアをろ過していく必要性を説いています。「これは何だ？どんな特性を持っているんだ？どんな関係があるんだ？」といった考えを突き詰めることで、アーキテクトはアーキテクチャー内の関係を正しいと証明できるものにするそうで、ソフトウェアのバグや実装し忘れた要件の多くは、暖昧で意味が漠然とした言葉に端を発しているそうです。

顧客・デベロッパー・アナリスト・ユーザーが退屈して眠くなるくらい同じことを繰り返し質問することは、出来の良いコンソメを作る際に液体が透明になるまで何度も何度もろ過を繰り返すことと同じであり、これがアーキテクチャーを洗練されたものに仕上げてくれるというわけです。

By Thomas Hawk

「技術上の借金は返済せよ」の項目では、ソフトウェア開発プロジェクトにおける、バグの修正や新機能の追加などのシステム変更を後回しにしないことの重要性が説かれています。一般的に、デベロッパーやテスターがシステム変更を行う際は、変更点を正しく設計・実装・テストするだけの時間を確保してからそれに取り組むことを望みます。もちろん判断にはトレードオフがあり、クイック・アンド・ダーティな手法が適している場合もありますが、そういった方法でその場しのぎな対応を行うと、プロジェクトは「技術的な借金」、つまりは後で必ずそれらに対応する必要性に迫られます。

お金の借金では、「利息」という見えないコストがあります。これに対して、技術の方の借金では利息が「システムが不安定になること」や、変更のために余分にかかる「メンテナンスコスト」に当たります。また技術の借金では、お金の借金を完済する際と同じように元金の返済、つまりはシステムの変更自体も行う必要があります。

技術的な借金について理解すると、「代償が高すぎてとてもそんなコストを払う余裕はない！」と思うかもしれませんが、デベロッパーはできる限り早く変更を施し、素早い変更を行う方が良いものです。その場合は修正が本番に適用された後に変更前の状態に戻り、そこから正しい方向に向かってデベロッパーに修正してもらい、次の定期リリースにはその修正を組み込むことが推奨されています。これは、「クレジットカードで何かを買って借金を作っても、月末に入金すれば利息を支払わなくて済むのと同じ」とのこと。

By 401(K) 2012

なお、「ソフトウェアアーキテクトが知るべき97のこと」をウェブ上で公開しているのはオライリージャパンではないのですが、内容自体はCreative Commons 3.0のもと自由に使用可能となっています。