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

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

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

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

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

クイック事実

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

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

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

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

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

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

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

3. 設計準備と実践

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

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

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

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

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

リアルタイム入力か、非同期レビューか？ ライブでのファシリテーションは、選択肢が曖昧な場合に最も効果を発揮し、エンジニアは先輩社員から、なぜその方針を維持するのかという説明を受けることで学ぶことができます。書面による説明と注釈付きの例を比較するだけであれば、非同期レビューで十分です。

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

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

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

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

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

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

より強力な試み。 「二重販売禁止ルールを厳守します。分割販売中は、メインサイトのみがチケットを販売し、もう一方のサイトでは待機ページを表示します。同じ座席を二度販売することを避けるため、短時間であれば空席数が少なくなることを容認します。分割販売はまれで短時間であると想定しており、主催者には待機ページが許容範囲内であることを確認したいと考えます。両方のサイトで販売する必要がある場合は、事前に各サイトに個別の座席ブロックを割り当てますが、その代償として一部の座席が売れ残る可能性があります。」この回答では、紛争の名称、立場、コスト、不明な点が明示されていることに注目してください。

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

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

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

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

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

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

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

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

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

残る可能性のある制約

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

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

よくある質問

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

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

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

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

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

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

どこから始めれば

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

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