アーキテクチャはトレードオフの技術である
ほかに 28 言語で読めます
English · Español · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
モジュール4／7：Data Architectコース第1章「データアーキテクトのように考える」。各モジュールは単独でも読めます。 前へ：可逆性テスト · 次へ：今日のために作る。明日に備える。失敗に備える。
このモジュールが答える問い： いくつもの解決策がうまくいきそうなとき、アーキテクトはどう選び、その選択をどう説明するのか？
アーキテクチャが単に正解を見つけることなら、ずっと簡単でしょう。プラットフォームを学び、パターンを学び、制限を学び、正しいものを選べば終わりです。
現実のアーキテクチャはそうはいきません。難しい判断はたいてい、明らかによい解決策と明らかに悪い解決策の間ではありません。うまくいき得る複数の解決策の間にあり、それぞれに長所と短所があり、それぞれがアーキテクチャを少しずつ違う方向へ動かします。そこでこそ、アーキテクトはテーブルの席を得るのです。
問題を解く方法はたくさんある
Section titled “問題を解く方法はたくさんある ”アーキテクトを教えるとき、この例を形を変えて何度も使ってきました。
Salesforceでは、一つの問題を解く方法がたくさんあることがあります。たとえば10通り、と数字を出すこともありますが、それはたとえであって数ではありません。選択肢の多くは最初から問題を抱えています。プラットフォームの制約にぶつかったり、重要な要件を満たせなかったり、受け入れられないセキュリティや性能の問題を生んだりします。それらはすぐに外せます。ほかのいくつかは今日はうまくいきますが、データが増えると問題が出ます。技術的には動いても、すでにわかっている成長には耐えられません。
残るのは、将来のニーズまで支えられる少数の選択肢です。ここからが面白いところです。どれもうまくいき、スケールし、要件を満たすかもしれません。では、どれが正しいのか？ すべてかもしれません。アーキテクトの仕事は、その違いを理解することです。
選択リストのような単純なものでさえ、今日はうまくいっても、データが増えると問題が出ることがあります。選択リストはユーザーにとって使いやすいものです。でも、値がどこから来るのか、いくつまで増え得るのかを問うてみてください。選択リストが最もうまく機能するのは、値がおよそ20個未満のときです。米国の州のように50まで増やすこともたまにありますし、国のように100を超えることはまれで、そうなると扱いにくくなります。ですから、選択リストごとに上限を把握しておきましょう。そして、選択リストの値を変えるのはメタデータの変更であって、データの変更ではありません。
代わりに参照関係を使えば、ユーザーインターフェースは少し複雑になります。しかしリストは上限なく増え続けられ、新しい値が連携から届くこともできます。これは使いやすさとのトレードオフです。それがバランスです。
最適とは完璧という意味ではない
Section titled “最適とは完璧という意味ではない ”私は最適という言葉を慎重に使います。最適なアーキテクチャとは、個々の判断がすべて完璧なアーキテクチャではありません。そんなアーキテクチャはおそらく存在しません。全体としての解決策のバランスがとれているアーキテクチャです。
解決策Aは最高の性能が出るが、高価で保守が難しいとします。解決策Bはコストが低く運用も簡単だが、性能を少し犠牲にします。解決策Cは将来に向けて柔軟だが、今日の複雑さが増します。どれが最適でしょうか？ この事実だけでは答えられません。ビジネス、要件、優先順位を知り、どの制約が本物でどれが好みにすぎないのかを知る必要があります。アーキテクチャは文脈に依存します。だから、あるお客様に正しかったパターンが、次のお客様にはまったく間違っていることもあるのです。
そしてデータアーキテクトとしてのあなたの仕事は、こうした判断のバランスをとることです。何十もの判断を、自分で、あるいはチームとともに下すことになります。それがどの判断なのかを知り、コスト、時間、機能への影響が大きく、主要な意思決定者に上げるべき判断がいつなのかを知りましょう。
最適でない判断が、最適なアーキテクチャの一部になり得る
Section titled “最適でない判断が、最適なアーキテクチャの一部になり得る ”これはこの章で最も大切な考え方の一つです。私はときに、解決策全体をよりよくするために、アーキテクチャのある部分で最適でない判断を承知の上で下します。
重複をなくすと連携が不必要に複雑になるので、少量のデータを重複させるかもしれません。理論的によりきれいなモデルではレポートや日々の利用がずっと難しくなるので、よりシンプルなデータモデルを選ぶかもしれません。代わりの方法では組織がまだ運用できないインフラが増えるので、少しの性能コストを受け入れるかもしれません。
どれか一つだけを切り出して見れば、最適ではないと言うでしょう。その通りです。しかしアーキテクチャは、個々の部品をそれぞれ最適化することではありません。システムを最適化することです。局所的に最適でない判断も、そのトレードオフを理解している限り、全体として最適なアーキテクチャの一部になり得ます。危険なのは、トレードオフをしていると気づかずにトレードオフをすることです。
何を手放しているのかを知る
Section titled “何を手放しているのかを知る ”誰かに「これが最善の解決策です」と言われると、私は次に**「何において最善なのか？」**と尋ねます。最も速い？ 最も安い？ 最もシンプル？ 最もスケーラブル、最も安全、最も柔軟？ 最も運用しやすい、最も早く届けられる、専門スキルに最も頼らない？ ほとんどの場合、答えが「最善」ではない別の軸があります。それがトレードオフです。何を得るのかを知りたいし、何を手放すのかも知りたいのです。
大量の企業データについて、2つの選択肢を考えてみましょう。一つはデータをSalesforceにコピーする方法で、Salesforceネイティブの機能が使いやすくなりますが、データの移動、保存、同期、もう一つのコピーのセキュリティ、そして遅延への対処に責任を持つことになります。もう一つはデータをその場に置いたまま、必要なときにアクセスする方法です。重複の一部はなくなりますが、可用性、クエリの性能、ネットワークへの依存、リモートシステムの能力がより重要になります。どちらの説明も、どちらを選ぶべきかは教えてくれません。教えてくれるのは、どんな問いを立てるべきかです。
要件はすべて同じ重さではない
Section titled “要件はすべて同じ重さではない ”トレードオフを考えると、すべての要件が同じ重さを持つわけではないことにも気づかされます。
誰かが「データはすぐに使える必要があります」と言います。わかりました。「すぐに」とはどういう意味でしょう？ 1秒、10秒、1分？ そして、なぜでしょう？ 数秒が重要な不正検知かもしれません。あるいは単に夜間のロードを待つのが嫌なだけかもしれません。それはまったく違う要件であり、どちらなのかわかるまで、アーキテクトは問い続けます。
私が好きなのは、問いに耐える要件です。どれくらいの量か、何件か、どれくらい速くか、どれくらいの頻度か、誰のためか、そしてそうしなければ何が起きるか？ 「速い」はアーキテクチャの要件ではありません。「顧客情報の更新の95パーセントが、30秒以内にサービスエージェントから見えること」なら、ずっと要件に近いものです。これでトレードオフを評価できます。
制約が答えを変える
Section titled “制約が答えを変える ”アーキテクチャを制約するのは、テクノロジーではないこともあります。お金、人、時間、ライセンス、組織の成熟度が制約になります。
技術的には優れていても、会社にない運用チームを必要とするアーキテクチャは、よいアーキテクチャではありません。問題をエレガントに解決しても、お客様が買わないライセンスを必要とする機能も、解決策ではありません。そして完璧な3年がかりの変革も、8週間後に立ち上げなければならない会社の役には立ちません。
どれも、期限のためによいアーキテクチャを捨てるという意味ではありません。何を、なぜ妥協しているのか、どんな結果を受け入れているのか、そして理想的には今日の妥協から明日のアーキテクチャへどう進むのかを理解するという意味です。
アーキテクトには「最適」の姿が必要
Section titled “アーキテクトには「最適」の姿が必要 ”ここに興味深い緊張関係があります。完璧な答えが一つあるとは限らないと言いながら、私は同時に、最適な解決策がどんな姿をしているかを頭の中に持っていてほしいとも思っています。この二つは矛盾しません。基準点が必要なのです。
データモデルを見るとき、不必要な制約なしに要件に合わせて最適化できるなら何を作るかを知っておきたいのです。そして現実の制約がその設計から私たちを遠ざけるとき（モデルの一部をフラットにする、データの一部を重複させる、連携を先送りにする、一時的な手作業のプロセスを受け入れる）、私は行き当たりばったりに妥協しているのではありません。最適からどの方向に、なぜ離れているのかをわかっています。それがアーキテクチャの技術であり、その勘は練習で身につきます。
描いてみる
Section titled “描いてみる ”トレードオフを理解する最良の方法の一つは、描いてみることです。アーキテクチャ図はスライドの飾りではありません。考えるための道具です。2つの方法から選ぶなら、両方を描きましょう。データはどこにあり、どこへ移動するのか？ 誰が所有しているのか？ 境界はどこにあり、セキュリティはどこで適用されるのか？ 何かが失敗したら何が起きるか、ボリュームが増えたら何が変わるか？
図は曖昧さを表に引き出し、全員が指させる同じ絵を与えてくれます。
それがどれほど大切かを学んだのは、ある電力・ガス会社のプロジェクトでした。レビューのたびに、同じ概念をまた説明し、会話を元の設計へ引き戻している自分に気づきました。そこで会議の進め方を変えました。毎回のレビューを、画面にデータモデルを映して始めたのです。すべての項目が載った詳細なものではありません。要約したモデルです。取引先には取引先責任者がいて、このレコードには子があり、作業はここにぶら下がる、といったものです。出席者はほとんどが経営層で、かかったのは2、3分でした。
会議のたびに同じメンバーだったので、その図が私たちの共通言語になりました。みんながその図の名前を使い始めました。同じ質問はだんだん出なくなり、会議はずっと楽になりました。私はこれを会議の足場を固めると呼んでいます。毎回見せるシンプルな図は、作るのにかかった手間よりずっと大きな価値がありました。
目的は芸術的な完成度ではありません。エンジニア向けの詳細な図のこともあれば、経営層向けの5つの箱と6本の矢印のこともあります。目的は明確さです。
トレードオフを説明する
Section titled “トレードオフを説明する ”よいアーキテクトは順を追って示します。検討した選択肢はこれです。それぞれで得られるものはこれです。それぞれのコストはこれです。私が推奨する選択肢はこれで、理由はこうです。
推奨がトレードオフの後に来ることに注意してください。アーキテクチャを「前にやったことがあるから、信じてほしい」にしたくはありません。経験はとても大切です。パターンを早く見抜き、問題に早く気づく助けになります。しかし経験は、考える筋道をよくするためのものであって、置き換えるものではありません。私たちの仕事は、アーキテクチャを理解することだけではありません。組織がその判断を理解できるよう助けることです。最終的な判断を下す人がアーキテクトでない場合は、なおさらです。
正しく考える。速く考える。
Section titled “正しく考える。速く考える。 ”すべての選択肢を分析するのに、いつも3週間あるわけではありません。3分しかないこともあります。会議中に要件が変わったり、知らなかった制約を誰かが口にしたり、経営層が「来年これがヨーロッパで必要になったら？」と尋ねたりします。
私は**Think Correct. Think Fast.（正しく考える。速く考える。）**という言葉を使ってきました。速さは、考えることを省いて得られるものではありません。その瞬間が来る前に十分考えておくことで得られます。パターンを学び、プラットフォームを知り、失敗を見て、どの問いを立てるべきか、どの判断が元に戻しにくいかを知っている。だからこのコースでは、ずっとシナリオに取り組みます。分析した判断が多いほど、次の判断の形を早く見抜けるようになります。
フォーム入力が必要なお客様がいました。ただしフォームはたくさんあり、質問は時とともに変わる可能性がありました。私はすぐに、アンケートのデータモデルが必要だと気づきました。このコースの後半で改めて扱うパターンです。パターンと解決策を見抜けたので、目の前の要件だけでなく、これから来る要件にも対応できる、より完全なデータモデルを持ち込むことができました。
アーキテクチャとはバランスである
Section titled “アーキテクチャとはバランスである ”データアーキテクチャをさらに深く進むと、私が単純なルールを示すのを控える選択に出会うでしょう。正規化するか、フラットにするか？ データをコピーするか、フェデレーションするか？ 同期か非同期か？ 標準オブジェクトかカスタムか？ アーカイブするか、オンラインに置いておくか？
原則も、パターンも、制限もあり、明らかに間違った答えもあります。しかし多くの場合、アーキテクトの仕事は、このシステム、このビジネス、この時点にとっての正しいバランスを見つけることです。
最適の姿を知る。制約を理解する。実行可能な選択肢を見極める。トレードオフを見えるようにする。そして判断を下す。
それは優柔不断ではありません。それがアーキテクチャです。
ここでアーキテクトが決めること
Section titled “ここでアーキテクトが決めること ”- どの選択肢が実行可能で、どれが今すでに間違っているか、あるいは1年後にだめになるか。
- 実行可能なそれぞれの選択肢が何を得て何を手放すか。問いに耐える要件に照らして測る。
- どの制約が本物で、どれが好みにすぎないか。
- トレードオフを示した上でどの選択肢を推奨するか、そしてそれをどう説明するか。