キーポイント
- アーキテクチャを構築していない人は、アーキテクチャに関する決定を下すべきではない。アーキテクチャを形成する重要な技術的トレードオフを行うには、アーキテクチャがどのように構築されるかについての知識が不可欠である。
- 品質属性要件(QAR)はアーキテクチャ設計の原動力となる。これらの要件を無視したり、不十分な定義にしたりすることは、失敗のもとである。
- アーキテクチャの決定をベンダーに委ねてはならない。ベンダーはあなたのコンテキストもQARも知らないし、あなたのためにトレードオフを決めることもできない。
- どんなに成功しているように見えても、他の組織からアーキテクチャをコピーしてはならない。彼らもまた、あなたのコンテキストやQARを知らない。
- アーキテクチャを評価する唯一の方法は、構築してテストすることだ。設計を完璧にするためにこれを遅らせることは、失敗への道だ。
成功するソフトウェアアーキテクチャを開発するのはシンプルだが、簡単ではない。QARを理解し、QARを最大限に満たすトレードオフを理解し、実行するには、洞察力と経験が必要であり、その多くはアーキテクチャ自体の実験を繰り返すことで集めなければならない。プロセス自体は単純だが、考慮すべきトレードオフはしばしば難しく、簡単な答えはめったにない。
落とし穴になりそうな場所を知ることで、特定の道を進むと行きたいところに行けないことを伝えることができ、チームの助けになることが多い。この記事では、トレードオフと結果に関する決断をより良くするために、私たちが経験した成果のない道をいくつか説明する。
一人の人間がすべての決定を下したり、影響を与えたりしてはならない。代わりに、適切なチームメンバーに意思決定に参加してもらう。
アーキテクチャは力のバランスであり、多くの場合、完全に満足のいくものには決してならない、一連の最適ではないトレードオフの結果である。優れたパフォーマンス、優れたスケーラビリティ、優れたセキュリティ、優れた保守性、そして優れたユーザビリティ?幸運を祈る!
一人ですべての決定を下すと、アーキテクチャはその人の経験、偏見、好みを反映される。それがその状況にとってちょうどいい場合もあるが、ある分野ではよくても、別の分野では悪いということもよくある。
異なる経験を持つ者同士の健全なギブアンドテイクは、開発チームが行うべき競合するトレードオフをむき出しにする議論につながる。一個人、たいていはチーム内でもっとも年長者(別名「HiPPO:Highest Paid Person's Opinion」シンドロームと呼ばれる)が下した決定や影響を受けた決定が、チームメンバー全員から賛同を得ることはほとんどない。彼らは、自分たちの仕事の安全を懸念してその決定に反対する発言はしないかもしれないが、その決定の結果何か問題が起きれば、すぐに批判し、チームをサポートしなくなり、さらには去っていくだろう。
これは、多数派が支配すべきだという意味ではない。委員会によって設計されたアーキテクチャは、肥大化し、焦点が定まらない傾向がある。私たちの経験では、理想的なバランスとは、多様な経験と視点を持つ数人の仲間が、より良い情報に基づいた決定を下すために、主張に異議を唱えることである。
再利用の目標が誤った決定を左右するようなことがあってはならない。その代わり、再利用は理にかなった場合のみ行うこと。
コード、コンポーネント、設計、あるいはコンフィギュレーションの再利用は、最初は良いアイディアのように聞こえる。経営陣は、再利用によってコストが削減され、納期が短縮され、品質が向上すると信じて、このコンセプトを推進したがる。チームは、MVPをより早く提供するために既存のアプリケーションの大部分を再利用することを決定するかもしれないし、かなり成功した製品を提供するために作成された既存のアーキテクチャを再利用することさえあるかもしれない。
再利用の範囲が関数である場合、サービスやクラス/タイプの使用はかなり簡単で、かなり成功する。なぜなら、関数の範囲は狭く、その副作用は限られているため、非常に異なるコンテキストで使用ができるからだ。残念ながら、少なくともアーキテクチャレベルでは、再利用によって期待されるメリットが実現されることはほとんどない。なぜなら、アーキテクチャは、異なるコンテキストに適応しにくい、広範囲で基本的な前提を置いているからである。
新しいアーキテクチャのQARが、既存のアーキテクチャが満たすように設計されたQARと一致しない限り、既存のアーキテクチャの再利用が成功することはめったにない。過去の実績は将来の成功を保証するものではない!MVPを迅速に実装するために既存のアプリケーションの一部を再利用することは、その設計にレガシー技術を含めることによって、関連するMVAを制約する可能性がある。再利用するために既存のコンポーネントを拡張すると、設計が複雑になり、メンテナンスが難しくなり、その結果コストが高くなる可能性がある。
再利用の機会を評価するときは、そうすることでアーキテクチャが複雑にならないか自問すること。もしそうなるのであれば、自分のニーズにぴったり合うように自分で書いた方がよいかもしれない。
アーキテクチャー上の課題に取り組んだ経験のある人材を解雇してはならない。その代わり、彼らを雇用し、必要であれば再教育する。
経営陣はコスト削減に執着し、時には管理職に特定の割合でコスト削減を奨励するボーナスが動機となることもある。ソフトウェア開発スキルはコモディティであるという信念に後押しされ、低コストのベンダーが何年も何十年も経験を積んだチームメンバーと同じスキルを提供できるという契約に誘惑されるかもしれない。
時にこれは真実である。かつての同僚が言っていたように、10年の経験があるのと、1年の経験を10回繰り返すのとでは大きな違いがある。別の言い方をすれば、ソフトウェア開発における本当のスキルは、コーディングでも、構文の知識でも、特定のフレームワーク群に精通していることでもなく、課題解決である。
アーキテクチャの役割は課題解決であり、さらに、特定の種類の課題を解決した経験から基づいたトレードオフが可能というスキルが加わる。アーキテクチャの課題を解決した経験のない開発者は、学べるが、その前に多くの間違いを起こすだろう。経験の有無にかかわらず、必要なのは賢い人材だけだと思い込むよりも、そのような学習サイクルをすでに経験した人材を雇用したり、維持したりする方が、安上がりな場合もある。
ビジネス上の意思決定でアーキテクチャを決めてはいけない。その代わりに、明確に定義されたQARを満たすための意思決定を行う。
ビジネス上の意思決定は多くの場合短期的なものであり、四半期や年次の計画サイクルがビジネス上の意思決定を支配する傾向がある。今期の業績を犠牲にして将来を考える経営者は、長期的な夢が実現するほど長くその地位にとどまらないことが多い。
ソフトウェア・アーキテクチャは、それとは異なるものでなければならない。すぐに結果が出ることは重要だが、組織がシステム構築のために行う投資は、収益に達するまでに数年を要することが多く、多くのシステムの寿命は数十年に及ぶ。ビジネスは即効性を求める一方で、特定の問題を解決するために数年ごとに新しいシステムを構築する余裕もない。
それにもかかわらず、ビジネスパーソンは時々、アーキテクチャの決定に自分自身を介入させようとする。2つの例を挙げれば、「ブロックチェーンは最新のものである」とか、もっと最近では「生成AIはすべてを変えようとしており、今それに飛び込まない企業は取り残される」というような記事を読んで勇気づけられることが多い。テクノロジーは、現状を打破するような形で競争の場を均等にするが、識者が予測するような形では決してない。
新技術は興味深い能力を提供するが、常にトレードオフや意図しない副作用を伴う。新技術は基本的、あるいは奇跡的に、QARを満たすことを重要でなくしたり、些細なことにしたりしない。多くの場合、新技術がQARを満たす能力はまったく未知数である。そこで、アーキテクチャの課題に対処した経験が重要になる。適切な質問をする場所と方法を知り、その質問に対する答えを得るための実験を考案する方法を知ることが重要になる。
より早く納品するために品質を妥協してはならない。その代わり、技術的負債(Technical Debt)は、アーキテクチャを実行可能な状態に保つレベルで管理すること。
MVP(Minimum Viable Product)とそれに関連するMVA(Minimum Viable Architecture)の間には常に対立関係がある。MVPの目的は、ソリューションが顧客やユーザーが経験する結果を改善するかどうかをテストすることである。MVAの目的は、MVPが経済的・技術的に長期にわたってサポートできることを保証することである。MVPに価値がなければ、MVAの作業は無駄になるが、MVAが実行可能でなければ、MVPも重要ではない。
MVPを重視しすぎる組織は、製品のコンセプトは気に入っていても、その製品の性能の低さに幻滅してしまうような、不幸な顧客を抱えることになりかねない。これでは、MVPをコピーするだけで、時間をかけてより効果的に実装できる競合他社に門戸を開いてしまうことになる。いわゆる先行者利益(ソリューションで最初に市場に出ることのメリット)が過大評価されるのには理由がある。顧客は粗悪な製品を提供する企業を罰する。
アジャイルソフトウェア開発アプローチやリファクタリングのようなプラクティスの台頭により、一部の組織は、問題は後でいつでも修正/リファクタリングできるのだから、スピードがすべてだと考えるように誘惑されている。現実には、修正作業の効果には限界がある。「後で修正」やリファクタリングが本当に意味することであるリメディアルワークは、別の、より効果的な方法でコードを書き直す前に、コードが何をするのかを把握するためにチームが費やさなければならない時間があるため、コストがかかる。リファクタリングと呼んだり、アジャイルソフトウェア開発アプローチを用いたりしても、作業の複雑さを根本的に減らすことはできない。
アーキテクチャを完璧にするために納品(とフィードバック)を遅らせてはいけない。その代わりに、今ある最高の情報を使ってアーキテクチャを設計し、フィードバックを使ってそれを改善する。
前のセクションを読むと、ソフトウェア開発チームは欠陥のあるアーキテクチャを決して出荷しないように注意と時間をかけるべきだと考える読者がいるかもしれない。それも良い戦略ではない。アーキテクチャに完璧はない。アーキテクチャは、不完全なトレードオフの集合によって形作られる。そして時には、本当に異常なことが起こるまで、そうでないこともある。アーキテクチャーを完璧なものにし、一度きりで常に確定できると信じるのは危険な考え方であり、チームが予期せぬニーズに対応できるよう進化できる、弾力的で適応性のあるアーキテクチャーを開発するのを妨げる。
ビッグ・アーキテクチャ・アップフロント症候群は、しばしばシステムにとって致命的である。完全に致命的でない場合でも、真の学習を開始するシステムのリリースを不必要に遅らせる。このシステムを設計する前に、すべてのアーキテクチャ要件を釘付けにすることは不可能だ。これは、初期アーキテクチャを作成することに反対する議論ではない。すべてのものには出発点がある。しかし、その時点で持っている最高の情報をもとに初期アーキテクチャを作り、フィードバックを使って改善することは、新しい情報を得ることを期待して初期リリースを延期し続けるよりも良いことだ。
また、どんなにレビューミーティングを重ねても、少なくともアーキテクチャのサブセットを実際に構築し、さまざまな条件下でテストを行い、目的に対する適合性を評価することには代えられないことも注目に値する。レビューミーティングは、たとえ経験豊富なアーキテクトが行ったとしても、参加者が過去に経験したことのある問題を明らかにすることができるだけであり、新しい技術や技法を採用したときに容易に表面化するような突発的な問題を明らかにすることはできない。
機能要件がアーキテクチャの原動力になってはならない。その代わりに、現実的なQARによってアーキテクチャが推進されるようにする。
要件が重要であることは誰もが認めるところであり、その結果、ほとんどの開発チームは機能要件に対するソリューションの開発に大半の時間を費やしている。ビジネス利害関係者は、品質属性要件を明確にするのに苦労する一方で、自分たちが何を望んでいるのかについては、通常、非常に明確であるため、機能要件に取り組むのは比較的簡単である。
残念なことに、優れたアーキテクチャ設計は、明確に定義された品質属性要件によって推進される。機能要件のみを使用してソフトウェアアーキテクチャを設計すると、拡張性が低く、負荷がかかった状態でうまく動作せず、長期間にわたって弾力性のないソフトウェア製品を作成することになる。開発チームが機能要件だけに焦点を当てると、そのソリューションのアーキテクチャは、ユーザーの実際のニーズを満たすには不十分なものになる可能性が高い。
誰かが成功させたアーキテクチャを真似してはいけない。その代わりに、独自のQARを使ってアーキテクチャを設計しよう。
人気のある記事やカンファレンスの講演では、ある有名企業やあるベンダーが、特定のQARを満たすために特定のアプローチをどのように使ったかが述べられている。これらの講演や記事は、重要な学習源となる貴重な洞察を共有しているが、限界がある。いわゆる「ベストプラクティス」や「アーキテクチャパターン」についても同じことが言える。他の誰かが特定のアプローチを使って成功したことを知ることは有益だが、それはある点までだ。
すべてのアーキテクチャは、異なる力のバランスであり、そのコンテキストでは理にかなっているが、他のコンテキストにはうまく変換できないことが多い、最適ではないトレードオフの集合である。自分自身のソリューションに関係する力とトレードオフの可能性を理解することは不可欠である。なぜなら、カンファレンスに参加している有名企業とは異なる結論に至る可能性があるからだ。同じ結論に至る可能性もあるが...
他人の選択を理解するには、その背景とQARを理解しなければならない。彼らの最終的な選択を知るだけでは、あまり意味がない。彼らの文脈を理解せずに、彼らの選択だけをもとに自分の決断を下すことは、彼らの成功を実現するどころか、失敗の道を歩むことになりかねない。
ベンダーやコンサルタントに意思決定を委託してはならない。その代わり、自分たちのアーキテクチャを自分たちでコントロールでできるようにしておくこと。
他人のアーキテクチャをコピーすることのバリエーションとして、同じような問題の経験があると主張するベンダーやコンサルタントにアーキテクチャの決定をアウトソースする(または放棄する)ことがある。彼らのソリューションは、他の文脈ではうまくいくかもしれないが、それでもあなたは、彼らの提供するものやアイデアを自分で評価しなければならない。彼らの提供するものがあなたの状況に完璧であることが証明されるかもしれないが、そうでない場合、解決すべきはあなたの問題であって、彼らの問題ではない。最初からこのことを理解しておけば、より良い決断を下すために、より良い質問ができる。
コンサルタントは、あなたの組織に必要な専門知識と異なる視点をもたらしてくれるが、全知全能ではなく、彼らにも盲点がある。コンサルタントは、あなたの決断に助言はできるが、あなたのために決断はできない。
QAR、セキュリティの脆弱性、メンテナンスの問題、ライセンスの問題を理解せずにオープンソースのフレームワークを使うことは、事実上、意思決定をアウトソースするもう一つの方法である。オープンソースのコンポーネントは、最新のアプリケーションには欠かせない。しかし、あなたのQARをサポートしている可能性もあれば、していない可能性もある。オープンソースのコンポーネントを採用する前に、その作成者がどのような決定を下したのか、そしてその決定があなたにとって正しいのかどうかを理解する必要がある。
アーキテクチャを一般化しすぎてはいけない。むしろ、あなたのQARのために、そしてあなたのQARだけのために設計することだ。
ソフトウェア・アーキテクチャは普遍的なものではなく、コンテキストと、多くの場合アプリケーションに依存するトレードオフを反映している。ソフトウェア・アーキテクチャは、QARを満たしている限り良いものである。
組織内のさまざまな種類のアプリケーションに共通のアーキテクチャを提供するために、さらに大きなQARのセットを解決する、さらに一般的なソリューションが存在する。しかし、より一般的な問題を解決するためのボーナスポイントもなければ、そのような一般的なアーキテクチャが必要である、あるいは使われるであろうという証明もない。多くの業界標準の2回目の改訂はこの罠にはまり、考えうるあらゆるニーズに応えようとし、その過程で有用性を超えて肥大化してしまう。
アーキテクチャを一度に構築してはならない。その代わりに、リスクと無駄を減らすために、少しずつ構築し、テストする。
ソフトウエア・アーキテクチャはソフトウエアである。その目標が達成されているかどうかを知る唯一の方法は、そもそも目標を持ち、少なくともその一部を構築し、目標に向かって前進しているかどうかを確認することである。
ソフトウェアアーキテクチャの目標は、QARを満たすことである。少なくとも、QARのほとんどを満足させるような合理的な選択をすることである。なぜなら、そのすべてを完璧に満たすことは不可能だからだ。アーキテクトのスキルは、トレードオフのバランスをとることである。
「大上段に構えたアーキテクチャ」アプローチが失敗するとき、チームがトレードオフを行うために必要な情報の一部は、アーキテクチャの一部を構築しテストすることでしか得られないからである。開発チームのメンバーがどんなに賢く、技術的に経験豊富であっても、アーキテクチャはおそらく彼らが見たこともないようなものを扱わなければならない。その結果、彼らは実験する必要がある。
このことは、アーキテクチャのピアレビューが重要でないということを意味しない。特に、(開発チーム外の)ピアは、開発チームの労力を大幅に削減できるような経験を持っているかもしれない。あるいは、少なくとも探索に実りそうな方向性を指し示してくれるかもしれない。納期に間に合わせるためには時間がないから」という理由でアーキテクチャー・ピアレビューをスキップすることは、通常、近視眼的であり、後で手戻りを増やすことにつながる。
2023.12.20 編集部注:初出後に以下のセクションを追加しました。
社内のソフトウェア・アーキテクチャ・レビューだけに頼らず、できるだけ早く製品をリリースし、実世界からのフィードバックを得ること。
この記事の最初のリリースで私たちはミスを犯した。タイトルでは12個の落とし穴があると約束されていたにもかかわらず、私たちは11個しか落とし穴を用意していなかったのだ。著者や編集者による数え切れないほどのレビューがその誤りを見逃していたが、注意深い読者がそれを発見した。コーディングの際の典型的な「1つ違い」の配列インデックスの問題のように、この誤りを見つけるのは非常に難しかった。より詳細なレビューがあれば発見できたかもしれないが、このような問題に最も近いところにいる人たちは、他のことに集中している。オリジナルの作者や開発者が見つけられないものを見つけるには、新鮮な視点を持つ人が必要なのだ。
記事よりもはるかに複雑なソフトウェアアーキテクチャの文脈では、このような視点を得る唯一の方法は、製品の実用版を実世界に送り出すことである。システムが稼動し、完了の定義を満たした後、アーキテクチャを改善する唯一の方法は、システムを開発した人々やその共同作業者のコミュニティが持つバイアスから解放され、実世界の精査を受けることである。
結論
以上のように、何がソフトウェアアーキテクチャの成功につながるかを明確に言うのは難しいが、何がそうでないかを言うのは簡単である。ソフトウェアアーキテクチャの定義を他人に求めたり、他人のアーキテクチャを模倣したりすることは、良いソフトウェアアーキテクチャを作ることを失敗させる2つの大きな方法である。QARを考慮しないこともそうだし、魔法のようなベンダーの技術やプロセスに期待することもそうだ。
ソフトウェア・アーキテクチャにダメージを与える機能不全は、ほとんど無限にある。しかし、ここに挙げたリストは、どこでうまくいかなくなる可能性があるのか、また、それに対してどうすればいいのかのヒントを与えてくれる。あなたは間違いなく、他にも遭遇するだろう。昔誰かが言っていたのを思い出す。"良い判断は経験から生まれるが、そのほとんどは悪い判断から生まれる。"