エンジニアがアーキテクチャ上のトレードオフを評価できるようになるためのシステム設計カタの構築方法

あるチームが地域のフェスティバル向けチケット予約サービスを設計した。想定される負荷を難なく処理し、設計レビューは全員の賛同を得て終了した。ところが、要件が変更された。主催者は、販売期間中にデータセンターが1つダウンしてもチケット販売が継続できるようにする必要があると約束したのだ。同じ設計に単一障害点が生じ、設計を担当したエンジニアたちは、何を変更し、何を諦め、その選択をどのように説明するかを決めなければならなくなった。

これは例示シナリオであり、実際に発生した事例ではありません。システム設計カタは、まさにこのような状況を再現するために構築されています。つまり、ある制約の下では問題なかった設計が、新たな制約に直面し、エンジニアは理由を添えて設計を擁護または修正しなければならない状況です。このガイドは、エンジニアリングイネーブルメントリーダーおよびエンジニアリングマネージャーを対象としています。システム設計カタとは何か、その構築方法、実行方法と評価方法、そしてトレーニングだけでは解決できない点について解説しています。すべてのケースと評価基準は、使用する前に上級エンジニアによる検証を受ける必要があります。

システム設計カタとは何ですか？

システム設計カタとは、短時間で時間制限を設けた設計演習のことです。少人数のチームが1段落のビジネス課題を受け取り、アーキテクチャをスケッチし、同僚に発表し、難しい質問に答えます。検索では、アーキテクチャカタまたはアーキテクチュラルカタとも呼ばれます。この形式はテッド・ニューワードがワークショップとして始めたもので、ルールやモデレーターの役割とともに、ニール・フォードのアーキテクチュラルカタのページに文書化されています。ニューワードの動機となった問いは、エンジニアがキャリアの中で6回未満しか設計する機会がないのに、組織はどのようにして優れたアーキテクトを育成すべきか、というものです。カタは、本番リスクなしに、彼らに追加​​の反復練習の機会を与えます。

クイック事実

1. パフォーマンス上の問題点を説明する

まずは課題から始めましょう。トピックから始めるのではなく、課題を明確にすることが重要です。課題は、変化する制約の下でアーキテクチャを擁護することです。実際の業務では、設計レビュー、インシデント対応、計画会議などで、要件が変化します。例えば、トラフィックの増加、可用性に関するより厳格な約束、新たなデータ所在地のルール、予算の削減などです。

多くのエンジニアは合理的なアーキテクチャ図を描くことができる。しかし、2つの目標が衝突した場合に何を犠牲にすべきか、そしてどのような証拠があれば考えを変えるのかを説明できる人は少ない。カタは、まさにその2つ目のスキルを磨くための訓練である。

エンジニアリングマネージャーに確認してもらうために、次のような1文のパフォーマンス記述を作成してください。「アーキテクチャと変更された制約が与えられた場合、エンジニアは何が壊れるかを特定し、変更を提案し、トレードオフを述べ、まだわからないことを述べる。」

2. 学習と状況のギャップを診断する

何かを構築する前に、その課題を、あなたのプログラムが現在実践し評価している内容と比較してください。

1. 練習では実際の課題が使われていますか？ 訓練でパターンを個別に教え、評価が多肢選択式のテストであるならば、誰も自分の選択を擁護する練習をしたことがないだろう。
2. 認知的な要求とは何ですか？ ブルームの改訂版分類法では、制約条件と選択肢を比較することは分析と評価の段階にあり、改訂版設計を提案することは創造の段階にあります。 学習活動をブルームの分類法に合わせる そのレベルに合ったアクティビティを選択する方法を示します。
3. スキル以外の何かが邪魔をしているのだろうか？ エンジニアが設計に十分な時間を確保できているか、アーキテクチャに関する意思決定の責任者がいるか、要件が文書化されているかを確認してください。チーム外の人物が決定を下した場合、どんなカタ（改善策）を実施してもチームの能力は変わりません。これらの原因を、解決できる担当者に伝えましょう。

3. 設計準備と実践

各段階に明確な役割を与えましょう。

準備。簡単な診断テストで前提条件を確認します。チームが使用する用語（可用性、一貫性、レイテンシ、コスト）、チームが知っておくべき構成要素、および独自の設計レビューテンプレートを確認します。この段階では、各自のペースで学習するのが適しており、復習テストでは前提条件の確認のみを行います。

練習。カタ自体を実行してみましょう。ニール・フォードのサイトで説明されている形式では、チームが結成された後、演習は3つのフェーズで実行されます。チームが何を作るかを話し合うディスカッションフェーズ、各チームがプレゼンテーションを行い質問に答えるピアレビューフェーズ、そして仲間が親指を立てて「完璧」、親指を立てて「まあまあ」、または親指を立てて「ひどく失敗」する投票フェーズです。いくつかのルールはそのまま採用する価値があります。チームは馴染みのないテクノロジーについて仮定を立てることはできますが、それを明示しなければなりません。また、オールスターチームを雇えると想定してはいけません。

制約条件の変更を追加してください。標準的なカタでは、固定された問題が提示されます。このガイドでスキルを訓練するには、途中で2枚目のカードを追加してください。これは、チームが対応しなければならない変更された制約条件です。これは私たちの設計上の選択であり、元のルールには含まれていませんので、試用してください。

フィードバック。フィードバックは総合点ではなく、決定事項に関連付けてください。「2つの地域に移動しましたが、切り替え中に発注された注文がどうなるかについては説明がありませんでした」というフィードバックは、「5点満点中3点」というフィードバックよりも役立ちます。

リアルタイムでの入力と非同期でのレビュー、どちらが効果的でしょうか？選択肢が曖昧な場合、特にエンジニアが先輩社員からその方針を維持する理由の説明を聞くことで、リアルタイムでのファシリテーションが最も効果を発揮します。一方、文書による説明と注釈付きの例を比較する程度であれば、非同期でのレビューで十分です。

4. 現実的な例題に取り組む

例示です。使用前に、上級エンジニアが事例と解答基準を検証する必要があります。

事例：ある地方フェスティバルでは、週末に2万枚のチケットが販売され、そのほとんどが最初の10分間で売れる。最初の要件は、このピーク時の需要に対応できる予約サービスを構築すること。設計：ウェブ層1つ、データベース1つ、決済時に決済プロバイダーを呼び出す構成。

変更された制約。途中で主催者は、データセンターが1つオフラインになった場合でも販売を継続しなければならず、チケットを2回販売してはならないと付け加えた。

最初の試み。「2つ目のデータセンターを追加してデータベースを複製する」。チームは馴染みのあるコンポーネントに頼ったが、2つのサイトが相互に通信できない場合に二重販売禁止ルールがどうなるかについては言及していない。

フィードバックと再挑戦。ファシリテーターはチームに対し、対立する2つの目標を挙げ、ネットワークが分裂した場合にどちらを守るかを説明するよう求めます。再挑戦では、どちらかを選択し、顧客がどのような経験をするかを説明するよう求められます。

より強力な提案。「二重販売禁止ルールを守ります。分割販売中は、メインサイトのみがチケットを販売し、もう一方のサイトでは待機ページを表示します。同じ座席を二度販売することを避けるため、短時間、空席が少なくなることを容認します。分割販売はまれで短時間であると想定しており、主催者に待機ページが許容できるかどうかを確認したいと考えています。両方のサイトで販売する必要がある場合は、売れ残りの座席が多少出ることを承知の上で、各サイトに事前に個別の座席ブロックを割り当てます。」この回答では、対立点を明確にし、どちらかの立場を取り、コストを明示し、不明な点を指摘している点に注目してください。

それぞれの回答が妥当であるか、あるいは不完全であるかを説明してください。評価は、審査員の好みのアーキテクチャではなく、承認された基準に基づいて行ってください。最初の回答ではコンポーネント名が挙げられていますが、トレードオフについては触れられていません。より優れた回答では、具体的な内容が示され、前提条件が明記され、価格とともに代替案が提示されています。

5．能力を評価し、移転計画を策定する

能力の証拠は、エンジニアがこれまで経験したことのない新しいケースにおけるパフォーマンスです。評価項目は、トレードオフの推論と新しい制約への対応です。シンプルな評価基準では、各基準につき0～2の尺度を使用します。

評価基準：0は欠落またはサポートなし、1は関連する省略を含む部分的、2は合意された基準に照らして完全かつ正当化されている。明示された安全性やデータ保護要件を無視するなど、重大なエラーは個別に定義し、総合スコアで隠蔽できないようにします。この評価基準は提案であり、検証済みの準備基準ではありません。エンジニアリングマネージャーと調整し、試験的に運用してください。有用なフィードバックを伴うインタラクティブな実践を設計するためのガイドでは、意思決定につながるフィードバックの書き方について説明しています。

計画の移行は意図的に行います。カタの後、各エンジニアに実際の設計上の決定事項を1つレビューに持ち込んでもらい、同じ質問を適用します。過去のインシデントに対する非難のないレビューも、実際の業務への良い橋渡しとなります。非難のないインシデントレビューの実施方法については、ガイドを参照してください。

インタラクティブな配信が役立つ場面

インタラクティブな形式は、グループを見る前に全員がコミットする必要がある場合に役立ちます。ライブ カタ セッションでは、ファシリテーターが変更された制約を示し、各チーム メンバーにトレードオフとその理由を入力するように求め、議論が始まる前にスプレッドを公開できます。元の形式の最後にあるピア 投票は、同じように簡単に実行できます。同じケースを準備のため、またはセッションに参加できなかったエンジニアのために、自己ペースで実行することもできます。AhaSlides は、インタラクティブな学習と、ライブ配信と自己ペース配信の切り替えをサポートしています。これはプレゼンテーションおよび学習ツールであり、アーキテクチャを描画または実行する場所ではないため、図はホワイトボードまたは設計ツールに残してください。使用する予定の特定の作成、フィードバック、またはレポート機能については、独自のワークフローと照らし合わせて確認してください。形式の選択に関するガイダンスについては、適応型、インタラクティブ、ライブ学習を使用するタイミングに関する記事を参照してください。

何が変わったかを測定する

変化する制約の下でもエンジニアがアーキテクチャを擁護できることを示す指標を事前に決定する。未知のケースにおけるトレードオフの推論を、プログラム開始前に取得したベースラインと比較する。対象者、分母、およびタイミングを明確に定義する。結果が改善した場合は、トレーニングの効果を判断する前に、同じ期間に他に何が変わったのか（新しい設計レビューテンプレート、人員配置の変更、注目を集めたインシデントなど）を検討する。

残る可能性のある制約

• デザインにおける権威。 チームが決定を下さなければ、練習しても効果は限定的だ。
• 時間。 型を作るのに数時間かかるが、実際のデザインには数週間かかり、型では提供できないデータが必要となる。
• 事件報道。 ある事例ではいくつかのトレードオフが考慮されている。点数はエンジニアの判断力全般を表すものではない。
• 複雑。 複雑性が増すことが必ずしも優れたアーキテクチャであるとは限らないので、コンポーネントの数が多いことを評価すべきではない。
• 転送。 ワークショップで良い成績を収めることと、緊張感のある復習で良い成績を収めることは同じではないので、型（カタ）の後、実際の場面でパフォーマンスを確認するようにしましょう。

これらの点を早めにスポンサーに伝え、個別の対策を計画しましょう。カタは、エンジニアが説明し、擁護できる能力を高めるものですが、権威や時間を生み出すものではありません。

よくある質問

システム設計カタとは何ですか？

短時間で時間制限を設けた設計演習で、少人数のチームがビジネス上の課題に対するアーキテクチャをスケッチし、同僚に発表し、難易度の高い質問に答える。アーキテクチャ・カタとも呼ばれる。

チームは何人くらいが適切ですか？

本来の形式では、3～5人の小グループを使用し、通常は1つの部屋で4～10グループのうちの1つとして行います。全員が発言できる程度の小グループを使用してください。

システム設計カタの評価はどのように行いますか？

新しい事例を提示し、合意された基準に基づいて、トレードオフの推論と変更された制約に対する対応を評価してください。ピア投票は有用なフィードバックとなりますが、それ自体が評価点となるわけではありません。

どこから始めれば

組織内で繰り返し発生する設計上の決定事項を1つ選び、それに関する1段落の事例を記述してください。変更された制約条件を追加し、エンジニアリングマネージャーに事例と回答基準を検証してもらい、重大なエラーのリストを含む3つの評価基準からなるルーブリックを作成してください。展開する前に、1つのチームで試験的に運用してください。

カタを自分のチームで実際に実行し、その後自分のペースで再利用する方法を確認するには、AhaSlidesをご覧ください。