はじめに
InfoQ に掲載された記事がとても面白かったので備忘も兼ねて感想を書こうと思う。
以下に記事に記載された著者の主張と感想を記載する。
一人の人間がすべての決定を下したり、影響を与えたりしてはならない。代わりに、適切なチームメンバーに意思決定に参加してもらう。
とはいえ関係者全員が納得するアーキテクチャも存在しないので、各種トレードオフを考慮しながらどういい塩梅に落とし込むかにリーダーの手腕が問われそう。
まずいのは、開発対象のサービスのドメイン知識やコンテキストのない人（エンジニアとしては優秀）たちで構成されたアーキテクチャ委員会みたいな所で意思決定されてしまうことだと思う。
ドメインエキスパートの参加は必須だが、様々な開発のコンテキストを知っている現場のエンジニアも必ず意思決定に関与させるべきだと思う。
再利用の目標が誤った決定を左右するようなことがあってはならない。その代わり、再利用は理にかなった場合のみ行うこと。
行き過ぎた再利用・共通化が技術的負債になるはあるあるだと思う。
この記事では特にアーキテクチャレベルでの再利用はアンチパターンだと主張している。 同意（完全にやめるのも非現実的だとは思う）。
共通化されたサービスが複数のチームで利用されるようになると、技術的な意思決定がチームを跨いでなされるようになり、開発のボトルネックになるため。
アーキテクチャー上の課題に取り組んだ経験のある人材を解雇してはならない。その代わり、彼らを雇用し、必要であれば再教育する。
属人性よくない言われがちだけど、ある程度の属人性を許容することによってそのシステムのコンテキストを熟知した人たちを組織に根付かせること開発コストの削減につながるとは思う。
もちろん暗黙知が非常に多く、新規参画者にとってキャッチアップが困難な状況を作っていいわけでもないので、トレードオフはあると思うが ソフトウェア開発スキルはコモディティであるという信念 に毒されて開発エンジニアを取り替え可能な部品捉えるべきではない（ロックインとのトレードオフ。）。
より早く納品するために品質を妥協してはならない。その代わり、技術的負債（Technical Debt）は、アーキテクチャを実行可能な状態に保つレベルで管理すること。
あとでリファクタリングするよりも最初に高品質なコードを書いた方が断然コスパが良い。
酷いコードのリファクタリングはコストがバカにならず結果としてROIが低くなりがちなので、すでにある技術的負債の返済は「アーキテクチャを実行可能な状態に保つレベル」程度に済ますべき。
「負債＝絶対悪」とするのではなく、うまく付き合っている選択をすべき。
アーキテクチャを完璧にするために納品（とフィードバック）を遅らせてはいけない。その代わりに、今ある最高の情報を使ってアーキテクチャを設計し、フィードバックを使ってそれを改善する。
１つ上の項目と矛盾するようだがアーキテクチャに完璧はない。「フィードバックを使って改善」できる状況を作ることを初期アーキテクチャの目標にすべき。
過剰設計は初期開発において陥りがちの罠なので気をつけたい。妥協しないというのは完璧を目指すことではなく、既存環境の制約から来るトレードオフの中で最適値を目指すことである。
誰かが成功させたアーキテクチャを真似してはいけない。その代わりに、独自のQARを使ってアーキテクチャを設計しよう。
書籍や他社事例で言及された「ベストプラクティス」や「アーキテクチャパターン」が必ずしも自組織にとってふさわしいとは限らない。
組織によって発生する制約やトレードオフは異なる。そのため、アーキテクチャ選定はあくまでも自組織の「コンテキスト」を十分に考慮に入れ、教科書上のベストプラクティスだけを盲信して判断しないようにしたい。
ベンダーやコンサルタントに意思決定を委託してはならない。その代わり、自分たちのアーキテクチャを自分たちでコントロールでできるようにしておくこと。
コンテキストを熟知してない人たちに意思決定してはいけないよねって話。ここまで読んだなら詳細は言うまでもないので省略。
社内のソフトウェア・アーキテクチャ・レビューだけに頼らず、できるだけ早く製品をリリースし、実世界からのフィードバックを得ること。
初期設計の段階で最良のアーキテクチャ選定ができるとは限らない。実世界からのフィードバックによってソフトフェアアーキテクチャをブラッシュアップするという視点を持とう。
