「ソフトウェアアーキテクトが知るべき97のこと」を読んだ
以前、「プログラマが知るべき97のこと」という書籍を読んだ。その内容は以下のウェブサイトでも全文読める。
今回は「ソフトウェアアーキテクトが知るべき97のこと」を、ウェブサイトで読んだ。
どうも書き写した際の誤字が多いのだが、注意して読めば分かるレベル。
個人的に参考になったところを引用する。他が参考にならなかったというワケではなく、これまでの自分の知識をベースに、僕にとって新しい発見があったかどうかで選んだ。
- No. 2 : "付随的な複雑さ"
- No. 4 : "長ったらしいWord文書などは書かないことです。Visioのようなツールで簡単な図を書いて、考えを伝えるのです。どうせ頻繁に書き換えることが最初から見えているのですから、図もシンプル・イズ・ベストです。" "長ったらしいWord文書よりも、まずはアイデアを浸透させることに力を入れてください。アーキテクチャーについての細かい決定事項を記録するなんてことは、後で考えればよいことです。"
- No. 6 : "「契約交渉よりも共同作業」というアジャイルの精神に従えば、アプローチは見つかります。具体的には、顧客のニーズを聞くことを目的とするワークショップやミーティングを聞くのです。そこでは「なぜ」という問いに答えやすくなるよう、顧客を誘導しましょう。"
- No. 7 : "アイデアは「売り込む」必要があり、そのためには効果的なコミュニケーションがなくてはならない" "複数の相手に自分の考えを説明するときには、いつでも立って話をしなさい"
- No. 9 : "それは交渉だということに気付け" "私たちは3台目、4台目のサーバーなどいらないことはわかっています。これは、スポンサーを次の話題に進ませるための交渉術です。すでにあなたが危険で崖から落ちそうなギリギリところを、かろうじて走っているのだということを示して、交渉のハードルを引き上げているのです。もしこれで本当にサーバーを手に入れることができたら、3台目は本番システムと同じ環境でテストするために使い、残りはビルド用にすればいいのです。"
- No. 12 : "「常識」というよりも「場の感覚」といったほうが正確だろう。つまり、特定の場で意味を持つ知恵ということである。"
- No. 18 : "汎用性よりも単純性" "後から考えると、単純な解の方が実は汎用性が高かったということは、十分あり得ることです。たとえそうではなくて、必要だとわかったものに書き換えることになっても、単純なものを書き換える方が、汎用的だとは言い難い「一般的な」ものを書き換えるよりも簡単なはずです。" "汎用性がまるまる役に立つことはありません。普通は特定の状況があり、役に立つのはその状況を解決してくれるものです。"
- No. 19 : "アーキテクトはビジネスと技術チームのインターフェイスです。" "アーキテクトは、飛行機の機長に似ています。いつも忙しく立ち働いているという感じには見えなくても、数十年の経験を活かして状況を絶えず監視し、異常に気付いたらすぐに行動を起こさなければなりません。プロジェクトマネージャー(副操縦士)は、日常的な管理を行う人です。ありふれた仕事や人員の管理のためにアーキテクトが忙殺されないように、アーキテクトを助けます。"
- No. 40 : "優れたシステム仕様は、応答時間そのものだけでなく、作業時間も規定します。作業時間とは、特定の仕事を終わらせるまでに必要な時間のことで、人がシステムの操作のために使っている時間を含みます"
- No. 43 : "何よりも大切なのは状況で、シンプルはそのために必要なものだということです。実際的な言葉で言えば、アーキテクチャー上の決定を下すときに、シンプルよりも優先すべきものは状況だけだということです。"
- No. 47 : "長ったらしい1次元的な「プロセス」に機能をまとめればプログラムしやすく、多くのデベロッパーにはより「論理的」に見えるかもしれませんが、ユーザーはそのようなものではなく、同時に多くの機能にアクセスできるユーザーインターフェイスを好みます。ユーザーは、プログラムのフロー制御をコールスタックに任せるのではなく、自ら介入しようとするのです。" "古き良き予測可能なコールスタック・アーキテクチャーには、もうさよならしましょう。必要に応じてコンテキストを回復しながら、いつでもどんな順序でもイベントに応答できるようにするのです。" "想像以上に恐ろしい世界でしょうか？しかし、現実の世界は、ずっと前から同じ問題に取り組んできているのです。遅れた手紙、破られた約束、行き違いになったメッセージ、間違った口座への支払いなど、例を挙げればきりがありません。"
- No. 52 : "理由を書き留めよ" "形式がどうであれ、ドキュメントは、「決定の内容は何か」、「なぜそのような決定をしたか」という基本的な問いに答えるものでなければなりません。副次的な問いですが、「他にどのようなソリューションを検討し、なぜ、選ばなかったか」、つまり「なぜ私の案ではいけないのか」についても、記述しなければならない場合がよくあります。ドキュメントは、検索可能にして、必要なときに簡単に見つかるようにすべきです。"
- No. 53 : "暗黙の仮定は、すべての立ち往生の母だ" "仮定する(assume)のは、u(you)とmeをばかにする(ass)ことだ"
- No. 56 : "ビジネスサイドの顧客たちが、提案されたシステムよりもメタファーを気に入ってしまうと、もっとも明るい解釈が共有されてしまって、現実の制約が見えなくなってしまう。" "開発チームが、実際のビジネス問題よりもメタファーの方が大切なように錯覚し出す。メタファーに振り回されておかしな判断をおかしいと思わないようになってくる"
- No. 62 : "頭の中で考えたメリットや要件を組み込んだソリューションを正しいと考えたくなることはよくあります。しかし、覚えておきましょう。将来必要になることを推測しても、50%の確率で間違い、49%の確率で大きく間違うのです。" "今日のところは、今日の問題を解決しましょう。"
- No. 66 : "解決策が1つしか思いつかないなら、何か問題がある"
- No. 69 : "今の近道、後で大損"
- No. 77 : "問題がかちっとしていると、解決されたときにはほとんど永遠に解決される"
- No. 80 : "クレバーなソフトウェアは、高くつきメンテナンスしにくく、もろいものです。クレバーになってはいけません。できる限り愚直になり、しかも適切な設計を作ることです。適切な設計にはクレバーという印象は生まれません。クレバーな部分がどうしても必要に思えるのなら、問題の立て方が間違っています。愚直に取り組めるようになるまで、問題を立て直しましょう。"
- No. 88 : "アーキテクトとデベロッパーは、すぐに問題解決モードに入るように教育されています。しかし、最良の解決は解決しないことだという場合があります。多くのソフトウェア問題は、一切解決しなくてよいのです。それらが問題のように見えるのは、ただ現象だけを見ているからです。"
- No. 92 : "新しい言語を学べ"
- No. 95 : "ソフトウェアのバグや実装し忘れた要件の多くは、暖昧で意味が漠然としている言葉に端を発しています。顧客、デベロッパー、アナリスト、ユーザーに、彼らが退屈して眠くなるくらい同じことを繰り返し質問しましょう。アリバイのほころびを探す検察官のように、質問のしかたを変えて、新しい事実、相違点、矛盾などを引っ張り出しましょう。繰り返しろ過するのです。"
- No. 100 : "ビジネス要求もシステム要求も津然一体で暖昧模糊とした要求を「要求」、整理しおえたシステム要求を「要件」と呼ぶなんて、おかしな話です。わざわざ分かりにくい言葉で区別せず、もっと分かりやすく何に対する要求なのか言い表せばいいではないですか。こうした不思議な用語を作ることこそ、要求に対する取り組みを分かりにくくしている典型的な例ですね。"
- No. 102 : "ソフトウェア開発の完全な自動化は目指すべきではありません。"
- No. 103 : "ウェブから集めてきた情報を吸収し続ける毎日。でも、何か不安が残ります。最新の技術情報には精通しているはずなのに、圧縮アーカイバ、検索エンジン、3Dグラフィックスエンジン……、そんなかつて憧れた魅力的なソフトウェアを、いつになっても作れる気がしない。作れるようになったのは、スクリプト言語とデータベースを使ったウェブアプリケーション。それなら1時間もあれば思ったものは作れるのだが。" "なぜか。ウェブに溢れる情報は、そのほとんどが、手段的で陳腐化しやすい知識だからです。「こうしたらこうなる」なんてノウハウ的な知識ばかりが増えても、背景にある理論の理解を必要とするソフトウェアを作ることはできません。圧縮、検索、3Dグラフィックス、それぞれの実現にはしっかりとした理論体系があります。" "また、ノウハウは次々と新しいものが見出されますから、すぐに陳腐化してしまいます。次から次へと新しいことを覚えて、それがどんどん陳腐化していく。さながらゼロサムゲームの様相です。" "日々の開発のために手段を学び、躍進のために本質的な技術を、バランス良く学びましょう。前者はウェブや書籍で、後者は教科書や論文で。何だって、どちらにも偏らない中庸こそがベストです。"
- No. 105 : "アーキテクトがデザインすべきなのはコミュニケーションです。システムはコミュニケーションを実現するための手段に過ぎません。" "書籍ユーザなんていない。いるのは、リーダーです。サーフボードユーザなんていない。いるのは、サーファーです。最終的なゴールは、「ユーザ」と呼ばれる存在のいない経験の総体をデザインすることだ。"
- No. 107 : "一般的にいって、「受動的」アーキテクトはなるべくお客様から大きな注文をいただこうと高機能かつ高品質を指向し、「能動的」アーキテクトはなるべく最小限の投資から収益を上げようとシンプルかつアジャイルな開発を指向します。"
アーキテクトって仕事が未だによく分かっていないが、少しはイメージが付いてきた感じ。
