目次
- システムの要件よりも履歴書の見栄えを優先させてはならない
- 本質的な複雑さは単純に、 付随的な複雑さは取り除け
- 最大の問題は、たぶん技術的なことではない
- まずコミュニケーション、そのための明快さとリーダーシップ
- パフォーマンスの決め手はアーキテクチャー
- 要求仕様の本当の意味を探れ
- 立ち上がろう!
- すべてのものは、かならずエラーを起こす
- それは交渉だということに気付け
- 定量化を求めよ
- 500行の仕様書より1行のコード
- フリーサイズのソリューションを求めるな
- パフォーマンスの検討に早過ぎるということはない
- アーキテクチャーとはバランスをとること
- 犯罪的なコミットエンドランを防ぐには
- 選択肢を1つに絞らないための現実的な方法
- ビジネスサイドに主導権を渡せ
- 一般性より単純性、再利用よりもまず最初に使えること
- アーキテクトは手を汚さなければならない
- 継続的にインテグレーションを実行せよ
- 日程による失敗を避けるために
- アーキテクチャーではトレードオフは避けられない
- 要塞としてのデータベース
- 不確定性が潜むという感覚を磨け
- 鏡に映る問題は見かけよりも大きい
- 再利用は、アーキテクチャーだけではなく人と教育の問題と心得よ
- アーキテクチャーにI(自我)なし
- 地上300mからの目
- 選ぶ前に試せ
- ビジネスドメインを理解せよ
- プログラミングは製造ではなく設計だ
- デベロッパーに自己裁量を与えよ
- 時間がすべてを変える
- 「ソフトウェア・アーキテクト」のAは小文字だけ。それで満足せよ。
- 大きなスコープは敵
- 役者ではなく執事になれ
- ソフトウェア・アーキテクチャーが論理的な意味を持つことを考えよ
- 摩天楼はスケーラブルではない
- 未来はヘテロジニアスとともにある
- パフォーマンスがまず大事
- ダイアグラムの空白に注意せよ
- デザインパターンに習熟せよ
- 状況がなによりも大切
- ドワーフ、エルフ、ウィザード、キングの4種類の人々
- 建物のアーキテクト(建築家)から学ぼう
- 繰り返しと戦え
- 現実の世界にようこそ
- 支配せず、観察せよ
- アーキテクトは2つの顔を持つ
- アーキテクトは境界とインターフェイスに注意を注げ
- デベロッパーに力を
- 理由を書き留めよ
- 暗黙の仮定、特に自分自身ものを疑え
- あなたの知識と経験を共有しよう
- パターンの病理学
- たとえ話の使いすぎに注意
- アプリケーションの保守に力を入れよ
- 3つから2つだけを選ぶ覚悟を決めよ
- 趣味や個人的な意見ではなく、原理原則に従え
- 動くスケルトンから始めよう
- データがすべて
- 単純なものは単純に
- アーキテクトは何よりもまずデベロッパーであれ
- ROI変数を意識せよ
- 目の前にあるのはレガシーシステムだという前提で設計せよ
- 解決策が1つしかない場合には、セカンドオピニオンを求めよ
- 変化の影響を把握せよ
- ハードウェアの理解も必要
- 今の近道、後で大損
- 「完璧」は、「十分よい」の敵
- 「よいアイデア」を避けよ
- 優れたコンテンツは優れたシステムを作る
- 怒れるアーキテクトとしてビジネスと対立するな
- 主要な指標の耐久性をためしてどこで壊れるかを確かめよ
- 設計するならコーディングできなければならない
- 他の名前でバラを呼べば、キャベツにしかならない
- しっかりとした問題には高品質のソリューションが与えられる
- 勤勉さが必要
- 自分の判断に責任を持て
- クレバーになるな
- 武器は慎重に選べ、用意に手放すな
- 本当の顧客は目の前の顧客ではない
- 設計した通りにはならない
- フレームワークは相性で選べ
- 強力なビジネスケースを作れ
- コードだけではなくデータをコントロールせよ
- 技術上の借金は返済せよ
- 問題を解こうとするな
- システムは用具的に作れ
- 問題解決に情熱を注げるデベロッパーを探して手放すな
- ソフトウェアは実際には存在しない
- 新しい言語を学べ
- 未来永劫安泰なソリューションはない
- ユーザーの拒否感情の問題
- コンソメの重要性
- エンドユーザーの立場からはインターフェイスこそがシステム
- 優れたソフトウェアは構築されるのではなく、成長する
- アーキテクチャは縦と横の基本構造を持つ
- ビジネス・アーキテクトを目指せ
- 問題にフォーカスせよ
- 問題にとらわれるな
- 煩雑なことを非属人化し、創造性を高める
- 手段的な技術と陳腐化しない本質的な技術
- 開発スタイルをデザインする
- システムではなく、コミュニケーションをデザインせよ
- 移り気な利用者を捉える
- 受動的アーキテクトと能動的アーキテクト
- 説明責任を果たす
感想
システムの要件よりも履歴書の見栄えを優先させてはならない
最新テクノロジーを知っていることも重要だが、顧客をないがしろにしてはいけない。
プロジェクトでは、新しいテクノロジーより正しいテクノロジーを使うことを心がける。
本質的な複雑さは単純に、 付随的な複雑さは取り除け
本質的な複雑さとは、問題自体の難しさ。
付随的な複雑さとは、問題の難易度を下げるための処理から出て来る問題のこと。
開発者は複雑な問題を解くために集まってくるが、付随的複雑さを量産してしまうこともある。
開発者が本質的な複雑さと向き合えるよう、環境を整えてやるのがアーキテクトの仕事。
最大の問題は、たぶん技術的なことではない
プロジェクトの失敗をテクノロジー的なせいにしがちだが、実際は人間関係が原因なことが多い。
プロジェクトは、人間が構築しているものなので、成功・失敗の鍵は人間になる。
一番重要なのは、意思疎通・話し合うテクノロジー。
知識だけでなく、相手を尊重して会話がしやすい雰囲気を作る。
まずコミュニケーション、そのための明快さとリーダーシップ
アーキテクトは、プロジェクトの目的・目標を伝える必要がある。
そのためには、明快さとリーダーシップが必要になる。
明快さは、長文よりも簡潔な文。
図もシンプルにして、細かい決定よりもアイディアの共有をする。
リーダーシップは、意思決定と理由をセットで伝えることを心がける。
そうすれば、開発者と協力して開発できる。
ミドルウェアの変更だけでは、パフォーマンスは上がらない。
チューニングも同じ。
パフォーマンスを上げたければ、ロジックの整備を行うことが大事。
アーキテクチャがシステムに与える影響はデカい。
要求仕様の本当の意味を探れ
要求したものが問題解決になってないことがある。
ユーザに「なぜ」という質問をしやすいように誘導し、真の問題を探る。
人は、暗黙の前提がある状態で話をしてしまいがちなので、回答内容には注意する。
立ち上がろう!
アーキテクトの仕事は、人に説明することが多い。
説明は、立ってしたほうが効果的。
たってすれば、ボディランゲージしやすいし、声も届きやすい。
だから、立ち上がることから始めよう。
すべてのものは、かならずエラーを起こす
自動化した場合、ヒューマンエラーは減らせるが、手数を省いたエラーは増える。
人よりも汎用的なエラー対処システムはない。
システムは、自動化の塊のようなもの。
だから、エラーがないとは言えない。
エラーが起きない前提は辞めて、受け入れて対処を考えるほうが効率的。
それは交渉だということに気付け
本当に必要か聞かれても、「なんとかなる」ような回答をしてはいけない。
その後の条件は、大抵聞いてない。
この話を聞いて、「２位じゃなダメなんですか？」って言ってた奴を思い出した。
たぶん、このときも「ダメじゃないです」の後に、いろいろ言ってたけど、聞き入れてないんだろうな。
これは、説明ではなく、投資やめる前提の交渉だったんだろう。
それを理解して交渉できなかったから、交渉に負けたのだろう。
というか、やり方卑怯すぎんだろう。。。
定量化を求めよ
アーキテクトの役割は、曖昧なことをシステム化すること。
指標化することを心がける。
指標化できないものは、やるべきではない。
なぜなら、指標化できないものは、あまり重要ではないことが多い。
500行の仕様書より1行のコード
設計は、重要ではあるが、注力しすぎると成果できずに終わる。
目標を達成するための手段であって、成果ではない。
フリーサイズのソリューションを求めるな
パターンは、いつ使うかの見極めが重要。
問題解決には、見極めが必要。
パフォーマンスの検討に早過ぎるということはない
非機能要件は、後回しにしがちだが、早い段階で基準をつくって監視したほうがいい。
あとになってリスク低減、チューニングコストも抑えられる。
技術問題のクリアだけでは不十分。
技術要件とビジネス要件のバランスを取る必要がある。
犯罪的なコミットエンドランを防ぐには
コミットエンドランとは、コンパイルしてコミットしたもので、自動テストなしのこと。
コミットエンドランは、プロジェクトにとっては犯罪的な行為で、手戻り工数が大きくなる可能性が高い。
リスクが高いにも関わらず、起こるのは、ビルド・テストに時間がかかりすぎるから。
人に制限を科すより、そうしない環境整備を・やろうと思う理由を無くす必要がある。
選択肢を1つに絞らないための現実的な方法
技術領域は、選択肢を絞ることが可能。
しかし、ビジネス領域は、複数の技術領域にまたがり複雑。
システムを分割可にしておき、ビジネス要件の変更に対応できるようにしておいたほうが、将来的に楽できる。
ビジネスは曖昧なもので移ろいやすいから、対応能力が高いほうがビジネス的には嬉しい。
ビジネスサイドに主導権を渡せ
アーキテクトは、ビジネスとテクノロジーの仲介が役割。
企業の目的と経営の現実化について、技術的な決定を下す必要がある。
ビジネスサイドに主導権を握らせるためには、、開発状況をフィードバックさせる必要がある。
ビジネスサイドが方向性を示さない場合、開発者がビジネス判断しなければいけなくなり、本来の目的から外れる可能性が高い。
アーキテクトは、ビジネス目標・指標をビジネスサイドに決めさせるように動く。
開発者が下す小さな判断が、ビジネス目標を変えないように注意する必要がある。
一般性より単純性、再利用よりもまず最初に使えること
汎用性の追求は、選択肢が多いゆえに誤用の問題がついて回る。
汎用化は、問題の本質を解決するためのもの。
問題を理解しているからこそ、単純でなければいけない。
汎用化することが目的になると、現実が見えなくなり、複雑度が増すだけなので、問題がなんなのかは常に考えて頭に入れておく。
汎用性は、無条件ではない。
ある特定の状況で柔軟に対応できるようにするのが汎用性であることを、十分に理解しておく。
アーキテクトは手を汚さなければならない
アーキテクトは、チームをリードしなければならない。
そのためには、メンバーができることはすべてできる必要がある。
つまり、テクノロジーについては、誰よりも詳しい必要がある。
優れたアーキテクトの条件
- 問題点の発見
- 犯人探しより問題の掲示
- 優れた解決・回避策の掲示
- 専門分野に関してエキスパート
- 自らを模範とする
継続的にインテグレーションを実行せよ
ＣＩは、インテグで問題を起こさないためのリスク管理術。
リスク管理だけではなく、開発状況の把握・調整など開発者間の共通認識のための素材としても使える。
開発の安定化、統制を取るためにもＣＩは必須。
日程による失敗を避けるために
プロジェクトの失敗の大半は、計画なしの日程変更。
日程変更がある場合、作業量について考え、交渉する能力が必要になる。
説得させる能力が日程調整に必要だということを意識しておく。
アーキテクチャーではトレードオフは避けられない
すべての要件を満足させると、システムはバランスが悪いものが出来上がり、結果的に何もできなくなる。
やるなら、適材適所で専門職を上手く使うことが必須。
要塞としてのデータベース
データは、永遠に残る。
データにバグが有ると、致命的になりやすい。
データモデルを安全に作るには、なるべくアプリ層と分断して独立性を保ち、整合性を保つことが重要。
不確定性が潜むという感覚を磨け
選択肢が複数あるのは、システムに不確実性があるから。
意識説に容易なアーキテクトを採用すると、今後の設計に重大なインパクトを残す。
選択肢が単一や選択肢に大差がない場合は、判断条件が足りてない可能性が高い。
判断を先延ばしにしたほうが無難。
その場合は、次の判断タイミングが送れないように注意が必要。
鏡に映る問題は見かけよりも大きい
よく起きがちな問題
- 小さな問題がいつの間にか重大問題になっている（依存関係とか）
- 楽観的に物事を考える
- メンバーの関心事がプロジェクト目標になってない
- 他人を受け入れない・容認できない
乗り越えるための工夫
- リスク管理のためのバグトラフィック
- 多様性に価値観を置く
- 「いやなにおい」を嗅ぎ分ける（ポケモンの技かな？）
- 単純なテスト方法の模索
- 盲点（認識しにくいもの）を無くす
再利用は、アーキテクチャーだけではなく人と教育の問題と心得よ
再利用の条件
再利用できるものがあることを知っている
あると思わないと、利用されない。
利用できるものを見つけたら、それを保持して使えるチャンスを待つ。
使い方を知っている
使い方を覚えるのは、能力と訓練に左右される。
正しく使えば、効果を最大限に得られる。
その努力をしなければいけない。
自作するよりも再利用したほうがいいと思う
問題を自分で解けないことを恥だと思ってはいけない。
コストを賭けるべき場所なのか、よく考えて再利用する／しないの判断を下す。
- 過去の成功から傲慢になる
- 設計に自己投影（自分の作品への批判を避けるために相手を攻撃する）
対策
- 要件を正義にする
- チーム重視して作品の私物化を辞める
- 仕事にチェックを入れる
- 自分自身を振り返り、他人への敬意を払っているか反省する
地上300mからの目
ソフトウェアの品質は、内外で別れる。
ソフトウェアの価値を測るには、いろんな視点が必要になる。
プロジェクトにあった測定内容を複数用意して、変化の方向を把握し、柔軟に対処することを心がける。
選ぶ前に試せ
システム開発とは、判断の連続。
何かを決めるには、判断材料が出揃うまで安易に決めてはいけない。
何かを決める前に、その判断が正しいのかを試してから下す。
労力はかかるが、最適解でなかった場合のリスク回避・絶望回避には必要。
ビジネスドメインを理解せよ
ビジネス知識がないと、問題の理解や対策が取れない。
アーキテクトとして成功するには、広い技術知識とビジネスドメインに対する深い知識が必須になる。
プログラミングは製造ではなく設計だ
プログラミングは、建築プロセスではなく、学習・発見のプロセスに近い。
規定してから構築は、変更ができず、開発の邪魔をする。
ソフトウェア開発を最大限活用するには、予測できないものにたして、柔軟に対応できること。
それを阻害するのは、リスクを減らせていない。
デベロッパーに自己裁量を与えよ
アーキテクトがすべてを命令していては、本来やるべき仕事ができなくなる。
開発者の監視に注力するのではなく、各開発者が疑問に思ったことを質問しに来る環境を作ることが大事。
時間がすべてを変える
時間が教えてくれるもの
- 適切な課題が選択できたか？
- シンプルに作れたか
- 古いものに満足せよ
「ソフトウェア・アーキテクト」のAは小文字だけ。それで満足せよ。
小文字である意味が理解できない。。。
文化的な何かがひそんでいるのだろうか？
翻訳する人には、そこら辺の違いを意識した上で、翻訳して欲しいな。。。
大きなスコープは敵
スコープの拡大は、失敗しやすくなる。
なぜなら、見積もりがハズレた場合の影響がデカくなり、チーム開発のやり取りが急増する。
回避するためには、本来のニューズを把握し、優先順位をつけて早くシンプルに対応しておく必要がある。
役者ではなく執事になれ
アーキテクトは、顧客のために行動しなければならない。
エゴで言動を変えてはいけない。
特に、バズワードに踊らされているようでは、アーキテクトとは呼べない。
ソフトウェア・アーキテクチャーが論理的な意味を持つことを考えよ
ソフトウェアの影響は大きい。
ユーザに制約を課す時は、慎重に考える。
決して自分が楽をするために、ユーザに制約を課してはいけない。
摩天楼はスケーラブルではない
ビッグバン的なデプロイは、失敗しやすい。
成功するためには、小さな単位でデプロイする必要がある。
小さくデプロイすることで、失敗の要因を突き止めやすくなる。
また、小さくデプロイするためには、システム分割が明確にできている必要があり、インタフェースの定義が明確化されている必要がある。
そのため、小さくデプロイすることで疎結合なシステムを作りやすくなる。
未来はヘテロジニアスとともにある
ヘテロジニアスとは、別々の領域で別のテクノロジーを使っていること。
今のアーキテクチャは、限界が見えてきたので、対象領域に最適化されているテクノロジーを選択して、生き残りの算段を考えておく必要がある。
パフォーマンスがまず大事
パフォーマンスはシステムに取って重要。
遅すぎては、使い物にならない。
ダイアグラムの空白に注意せよ
ダイアグラムの間には、矢印だけではなくいろんな要素が介在している。
ハード的な要素を省略しているだけで、実際にはあるので、知らなければいけないことが隠されている。
そういうものがあることを認知しておけば、より安全にことを進められる。
デザインパターンに習熟せよ
デザインパターンは、ソフトウェア開発の基本。
アンチパターンは、罠を回避するために必要。
パターンを学んで、実行・適用することがアーキテクトに課せられた課題。
状況がなによりも大切
自分がどのような状況にあるのか、よく把握する。
把握できないと判断ミスにつながり、あとでツケを払うことになる。
ドワーフ、エルフ、ウィザード、キングの4種類の人々
ドワーフ → ハードワーカー
エルフ → 才能特化
ウィザード → 効率高い
キング → 人を協力させて成果を出させる
アーキテクトは、キングのように振る舞う必要がある。
建物のアーキテクト(建築家)から学ぼう
- アーキテクトの役割は調停
- エラーは隠さず、破壊を恐れない
- 完璧なものなどない。不完全を容認する
繰り返しと戦え
コピペは問題に注力してないので、不要なコードがないとは言えない。
重複は、作業の遅延を招く。
何もしなければ重複は取り除かれないので、見つけたらトラフィックする習慣が必要。
現実の世界にようこそ
連続した世界で、あらゆる事象が並列実行される。
だからといって、逃避してはならない。
現実にたいして人間は古くから対応できている。
システムも対応できるハズ。
支配せず、観察せよ
すべてを支配するアーキテクチャは、密結合になりやすい。
完全なコントロールがなくすことが、今後のアーキテクチャの課題になる。
アーキテクトは2つの顔を持つ
プロジェクトは、相反する要件を含むことがある。
両立するように調整するのがアーキテクトのお仕事。
そして、その変化に対応できるように全力を尽くすのが、持つべきマインド。
アーキテクトは境界とインターフェイスに注意を注げ
大きな問題に対応するには、問題を分割する必要がある。
分割統治をして、複雑な問題に取り組む。
分割統治するためには、問題領域の境界を明確化し、名前付けをする。
各問題の関係を洗い出し、それぞれどのように関係しているのか分かるコンテキストマップを作る。
そうすれば、システムを見通せて、問題解決の方法を考えたり、現状を説明する資料として使える。
デベロッパーに力を
ソフトウェア開発は、チームでするもの。
なので、アーキテクトは開発者の力が発揮できるように尽力する必要がある。
そのためにすべきことは、以下。
- 開発者に力をつけさせる
- 採用活動に参加してチームを強くする
- ロードマップの作成
- 過度な制約の廃止
- 本質的でない仕事から開発者を守る
理由を書き留めよ
ドキュメントの価値は、人によって違うが、アーキテクト選定の議事録は、開発者に与える影響が大きい。
作ることで得られるメリットは以下の通り
- 原則について会話する材料になる
- 反論が正しいか判断する基準になる
- 引き継ぎ
- 基礎の確立
- 設定の見直し
暗黙の仮定、特に自分自身ものを疑え
経験的証拠のない仮定・思い込みは、後戻りできなくなる前に正しいか確認する。
技術は日進月歩で進化しているので、思い込みによる指向の固定化は危険。
あなたの知識と経験を共有しよう
知恵を引き出すには、他人に説明して倫理の穴を見つけてもらうのが一番楽。
失敗から学ぶためにも、共有して議論をする必要がある。
基礎にする前に、それが誤りではないことを確認した方がいい。
パターンの病理学
自分が博識であることを自慢するために、問題領域にパターンを適用するのは危険。
不必要にパターンをもちいるのは、作り過ぎや複雑化に繋がる。
誤用を誘発するので、誘惑に負けず、冷静な判断を下す。
不必要なパターンが適用される例として、自動コード生成されたソースを見ると、心底そう思う。
特に誤用が多いのが、Facadeパターンだと思うね。
まとめる必要性を感じないのに、単純アクセスでもFacade噛ませてあったりして、ムダなコードが増えてる事が多い。
コーディングは、まだ人の領域で、何も考えてないコピペマスターは、淘汰されることを切に願う。
たとえ話の使いすぎに注意
メタファーや比喩は、複雑で曖昧なものを理解するために必要。
プロジェクト創成期には、薬にはなるが、成熟してくると、都合のいい解釈をしたり、ビジネス問題より優先してしまうことがあるので、毒に変わることがある。
メタファーに振り回されすぎない注意が必要。
アプリケーションの保守に力を入れよ
保守に思いつき対応はＮＧ。
システムのライブサイクルの大半は保守なので、注意してないとすぐにモンスター化する。
本番稼働を成功させるためには、早い段階から保守の観点を取り入れ、開発を勧める。
開発者と保守者では、スキルセットが違うので、視点が足りてないことがあることを理解して開発をすすめる。
3つから2つだけを選ぶ覚悟を決めよ
全てを実現するのは、複雑化され、難解バグを生むだけ。
本当に必要なのか、十分に考慮する。
これは、原理原則を適用する場合も同じ。
メリット・デメリットを考え、必要なものだけを選んで欲張ってはいけない。
トレードオフを受け入れる考えを持つことが重要。
趣味や個人的な意見ではなく、原理原則に従え
原理原則に従うと、説明が楽になる。
共通認識として使えるので、会話がスムーズに進む。
見解や趣味でことをすすめると、政治的議論の引き金になる。
動くスケルトンから始めよう
動くスケルトンとは、最小限の実装で動作するもの。
最初に作ることで、フィードバックサイクルが短くなり、修正や要件だしが楽になる。
動く状態を保ちながら、機能拡張したほうが、最後に一気に作り上げる開発よりも成功しやすい。
データがすべて
プログラムは、データを操るためのツール。
リリース後のシステムのバグの大半は、データに起因している。
正しいタイミングで、正しいデータが送られていれば、システムは正常に動く。
システムのコア部分は、データを理解することがから始まる。
単純なものは単純に
単純な問題は、博識であることの証明に複雑に解いてはならない。
その場合、コストが高くなる
将来の予測は、大抵ハズレるもので、設計はなるべくシンプルにして、誰でも対応できるようにしておく。
アーキテクトは何よりもまずデベロッパーであれ
アーキテクトは、デベロッパーとして専門分野を極めた人がなれるもの。
ROI変数を意識せよ
ROIとは、使ったリソースにたいする利益の割合。
ソフトウェア開発は、投資のようなもの。
ROIを意識して、効率的な判断をしないと、あまり価値はない。
アーキテクチャ上の判断は、ROIを意識することから始めよう。
目の前にあるのはレガシーシステムだという前提で設計せよ
システムは、遅かれ早かれレガシーになる。
だから、メンテナンス性には注意する必要がある。
メンテナンスに必要なものは、以下の通り
解決策が1つしかない場合には、セカンドオピニオンを求めよ
解決策が一つしかないということは、トレードオフの余地がない。
アーキテクトとして経験が不足していると思わなければいけない。
その場合、なるべく多くの人の意見を聞いて、どするか考えたほうがいい。
変化の影響を把握せよ
変化は、モジュールだけとは限らない。
スケーラビリティや、チームの人員、他システムのＩＦ変更など。。。
変化はコントロールできないので、変化に影響を受ける箇所を局所化しておき、対応が簡単にできるようにする。
そうすることで、リスク計測しやすくなる。
アーキテクトとして、常に変化影響が最小になるように準備をしておく。
ハードウェアの理解も必要
ハードがソフトに与える影響は大きい。
なるべく早い段階から、ハードの専門家と連携できるようにして、ハードの制約を知っておく。
ビジネスニーズに答えるためにも、ソフトウェアだけでなく、ハードウェアも意識しておく。
今の近道、後で大損
初期開発は、近道をなるべく避けて、まずい設計を潰す。
基礎づくりをしていることを忘れてはいけない。
基礎づくりが疎かになっていると、後で大きな代償を支払うことになる。
「完璧」は、「十分よい」の敵
完璧を求めすぎると、メンテナンス難やチームの混乱を招く。
要件達成ができる最低ラインで終えるようにして、余った時間を他に回したほうが、正しく時間を使える。
「よいアイデア」を避けよ
よいアイディアをプロジェクト途中で入れるのは、かなり危険。
よいアイディアと思っても、適用するにはコストがかかることを常に意識する。
よいアイディアで善意からくるものでも、それが必ずしも正しいとは限らない。
悪意のない悪は、やっかいで非常に質が悪い。
受け入れる前に、それをやる必要があるのか、よく考える。
優れたコンテンツは優れたシステムを作る
コンテンツは、システムに価値を与える。
コンテンツが優れていなけければ、システム開発が成功したとはいえない。
システム開発の段階で、なるべくコンテンツへのフィードバックをすることを、忘れてはいけない。
怒れるアーキテクトとしてビジネスと対立するな
ビジネスは、デベロッパーの存在理由。
ビジネスでの意見対立でキレるのは、得策ではない。
意見の不一致を認め、どうやって解決するのか考える。
どうしても許せない場合は、転職するしかない。
自分のエゴを通して、機会損失することは、避けるべき。
主要な指標の耐久性をためしてどこで壊れるかを確かめよ
耐久性を知ることで、問題箇所をしることができる。
性能について、後手の対応ではなく、先手の対応ができるため、メリットは大きい。
設計するならコーディングできなければならない
使ったことがないものを使うのは、リスクが大きい。
覚えるに時間が掛かるが、プロダクトの落とし穴に気づくのが早くなったり、不要なリスク混入を避けられる。
アーキテクトは、デベロッパーでもある。
使えないテクノロジーがある場合は、学習して身につけましょう。
他の名前でバラを呼べば、キャベツにしかならない
名前がコロコロ変わるのは、設計に問題がある。
名前が変わるタイミングで、何が目的だったのか、よく考え直す習慣をつける。
そうすれば、次回の設計はよりよくできるはず。
しっかりとした問題には高品質のソリューションが与えられる
アーキテクトに必要なことは、問題の線引。
問題を正しく分割できることが、耐久性を高め、設計しやすいシステムに繋がる。
勤勉さが必要
勤勉さに欠けるアーキテクトは、原則からハズレることが多く、システムを瓦解させがち。
勤勉でいることは、アーキテクトに必要な要素。
勤勉であるためには、ルールを作り、常に守ることが必要。
これは、どの業界でも当てはまる。
自分の判断に責任を持て
ソフトウェアの失敗は、アーキテクトの判断ミスや詰めの甘さ。
責任を持って開発に挑まないと、失敗は避けられない。
判断を下すためには、下記の条件に気をつける
- 判断理由が完全に説明できる
- 決定したものは、検証していること
- 決定したものが守られていることを確認する手段があること
- より詳しい人がいたら、その人に判断を委譲できるようにしておく
クレバーになるな
ここでのクレバーは、小手先の騙し技を使う人のこと。
クレバーなことばかりしていると、あとで大きな代償を支払うことになる。
アーキテクトは、単純なものを作ることに注力する。
クレバーな設計は、ほころびが出やすいので避ける。
武器は慎重に選べ、用意に手放すな
使い慣れた武器は、使い慣れているので効率的に開発ができる。
捨てる場合は、デメリットが発生することを忘れてはいけない。
新技術を使う場合のメリット・デメリットは以下の通り
- 学習コストがかかる
- だいたいは古い技術で代用できる
- 新規テクノロジーが成功するとは限らない
将来性を考え、新技術の取捨選択をしましょう。
本当の顧客は目の前の顧客ではない
本当の顧客は、もっと奥にいる。
真の顧客の成功が、自分の成功に繋がる。
目の前の顧客の成功は、自分の成功には繋がらない。
設計した通りにはならない
考え抜いた設計が、現実に通用するとは限らない。
小さな変更が積み重なり、設計がズレることはよくあること。
そこに仕様変更・バグが重なれば、最初に設計したものは、影も形もなくなることがある。
設計したものが絶対と思わず、変わることを受け入れなければならない。
フレームワークの担当領域が被ると、複雑になりやすい。
使うなら、担当ドメインを明確に分割して任せる。
その他のフレームワークと連携するなら、特に注意しなければならない。
強力なビジネスケースを作れ
人は、認識したものが現実で価値を持つ。
デベロッパーが価値を出すには、ビジネスで成功・使える必要がある。
コードだけではなくデータをコントロールせよ
システムは、ソースだけで構成されていない。
スキーマやデータもバージョン管理する。
トラブルを想定した場合、管理できているほうが万全に対応できる。
技術上の借金は返済せよ
技術的負債は、利子がある。
なるべく早く返さないと、利子で肥大化して、借金地獄に突入する。
問題を解こうとするな
問題をいきなり解いてはいけない。
その問題が正しく定義されているところから確認する必要がある。
あと、解く必要がある問題なのかも十分に考える。
システムは用具的に作れ
仕事には、道具が必要不可欠。
道具はシンプルである方が、簡単で効果的に使える。
システムは、ユーザにとっては道具。
なるべく使いやすくシンプルに作る。
問題解決に情熱を注げるデベロッパーを探して手放すな
強力なチームは、アーキテクト一人では作れない。
優れたデベロッパーが複数必要になるが、見つけるのは至難の業。
見つけたら大切に扱い、意欲を削がないようにして維持する。
ソフトウェアは実際には存在しない
ソフトウェアは、物理的なものではない。
使えたり、変更したりできるけど、現実世界には直接影響を与えない。
使われないと存在しないと同義であることを忘れてはいけない。
新しい言語を学べ
ビジネスの人は、プログラミング用語は知らない。
だから、デベロッパーはビジネス用語を覚えて、直面している問題について会話できるようになると、重宝される。
未来永劫安泰なソリューションはない
未来は、誰にも分からない。
そのため、未来永劫バグを起こさないシステムを作るのは、不可能。
未来にばかり目を向けず、今の問題を直視する。
今の選択を誤れば、未来も誤った結果になることを理解しておく。
ユーザーの拒否感情の問題
ユーザの拒否反応は、プロジェクト失敗に繋がる。
回避するためには、人柱が必要。
ユーザや利害関係者の代表と対話して、両者が納得できる折衷案を出すことは重要。
ソフトウェアのバグや要件漏れは、曖昧さや不明瞭な言葉に起因している。
解決するには、質問を繰り返し、コンセプトを洗練する必要がある。
タイトルにあるコンソメは、濾過して美味いコンソメを作ることは、ソフトウェア開発と似ているよと言いたかった。
エンドユーザーの立場からはインターフェイスこそがシステム
エンドユーザーは内部の構造なんて意識しない。ＵＩこそがすべて。
システムを成功させるには、内部構造を知っている人とＵＩの専門家が手を組む必要がある。
優れたソフトウェアは構築されるのではなく、成長する
ソフトウェアの失敗は、いきなり大規模で作ったり、想定外の規模に膨れ上がることが多い。
初期は、明確なコンセプトを持った状態から小さく始めて、徐々に大きくしたほうが、成功しやすい。
日本人アーキテクトによる知っておくべき１１のこと
現実の問題は、非線形でいろいろなものが影響し合う。
何に価値を置くか決めることで、モデル化され２次元構造になる。
問題を解く場合、まず何に価値を置くのか決めることから始める。
ビジネス・アーキテクトを目指せ
ソフトウェアの考え方は、ビジネスに繋がることが多い。
また、テクノロジーをビジネスに反映させるのは、アーキテクトの仕事。
ビジネスパーソンとして価値観を養い、目的をもって仕事することは、必ず将来のためになる。
問題にフォーカスせよ
正しく問題を定義してないと、見当違いなシステムが出来上がり、誰にも使われない。
真の問題を見抜く必要がある。
問題を発見して解決する能力が必要。
問題にとらわれるな
問題は、人によって見方が違う。
解決策は、制約とコストが伴うので、まずは何を問題にしているのか理解することから始める。
煩雑なことを非属人化し、創造性を高める
自動化は、煩雑な問題を解決するためのもの。
ソフトウェア開発全体への適用は無理。
なぜなら、自動化前提だと制約がついてまわるため、新たな問題の解決に制約がかかる。
ソフトウェア開発は、煩雑作業と知的創造を含む。
手段的な技術と陳腐化しない本質的な技術
最新テクノロジーに精通していてもできないものがあるのは、手段的知識を得ているだけで、技術体系や理論を理解してないから。
ノウハウを溜め込むのはいいが、陳腐化しやすく新しい考えで上書きされることもある。
ネットにある情報は、大半がノウハウ。
理論や原則は、ネットでは集めにくい。
ノウハウ：ユーザに価値を提供する手段として必要
理論：問題解決に必要
ノウハウだけ、理論だけでは、変化する世の中に対応できない。
両方バランス良く学び、変化に備える。
開発スタイルをデザインする
開発手法は、テクノロジーと同じくらい重要。
要件対応、バグの混入率、チームの雰囲気などに影響を与える。
メンバーの特性に合わせて、どう進めていくかも考える。
システムではなく、コミュニケーションをデザインせよ
新規システムの開発は、組織の風土を理解し、モデル化すること。
モデル化できれば、システム化すべき箇所が見つかるハズ。
システムはのユーザを作るのではなく、やりたいことを実現するためのシステムを作っていることを、忘れてはいけない。
移り気な利用者を捉える
要求分析は、曖昧さや不確実性が残る。
なぜなら、利用者全員の話を聞くことはできないため。
曖昧さを無くすためには、利用者を想定し、目的・振る舞いの仮定・検証を繰り返してシステムを最適化していくしかない。
受動的アーキテクトと能動的アーキテクト
受動的アーキテクトは、ユーザからの要求にあったものを高機能・高品質で作りたがる。
売上増加など、自分の都合のために、不要な機能提案をすることもある。
能動的アーキテクトは、最小の投資で最大の成果が得られることを目指す。
権限が大きいので、検証してない新テクノロジーを試したり、失敗を秘密にしようとすることもある。
どちらもメリット・デメリットがあるが、理想像は似通る。
違ってくるのは、環境要因。
環境が個人に影響を与えることを自覚して、バランスをとって成長しましょう。
説明責任を果たす
要件をクリアしてシンプルに作るのが、アーキテクトの役割。
それを実現するためには、開発者にたいして説明責任を果たす必要がある。
説明は、ドキュメントを多くすればいいわけではない。
必要最小限のドキュメントを作り、サンプルなどを用意して、初期導入の敷居を下げる。
感想
いろんな人の意見を見て言えるのは、問題の定義がアーキテクトの本質な気がする。
問題の切り方がシステムを左右するといろんな人が言っているから、たぶん真実なんでしょうね。
あと、慢心しちゃダメなんだろうなって読んでて思った。
役割・役職が変わっても、自己研磨を怠るやつは、失敗するんだろうな～って感じた。
