技術アーキテクチャのプレゼンでは、三つのことを順に示します。システムが全体のどこに位置するか、重要なリクエストがどう処理されるか、そして、提案する方式をほかの選択肢より優先する理由です。最後に、必要な意思決定を示します。構成要素の図だけでは、動作や設計上のトレードオフまでは伝わりません。
ここでは、架空の小売業者の注文サービスを例にします。チームは、注文受付と出荷処理の間にキューを導入することを検討しています。資料の目的は、開発担当と運用担当がこの変更を試験導入するか判断できるようにすることです。実際の本番システムの設計を示したものではありません。
図と比較がまとまったら、Presentiでアーキテクチャの構成案を編集可能なスライドにすると、説明の順序を整えやすくなります。AIにシステムを考案させるのではなく、設計の根拠も入力してください。根拠のある内容なら、初稿の構成にも意味を持たせられます。
何を承認してほしいのかを先に決める
スライドを作る前に、求める決定を一文にします。「決済の承認は現在の処理経路に残し、受付済み注文の出荷処理を非同期化する試験導入を承認する」。併せて、対象外も示します。決済事業者との接続、データベースの置き換え、購入手続き全体の再設計は、今回の議論には含めません。
この一文が、資料に入れる情報を決める基準になります。運用責任者には、出荷処理の遅延がどう見えるのかを伝える必要があります。開発責任者には、再試行と重複をどう扱うかが必要です。どちらにも、社内の全サービスを一通り紹介する必要はありません。想定するユーザーの操作がまだ合意されていない場合は、製品要件のプレゼンで整理してから、このレビューでアーキテクチャの選択を求めます。
対象システムと周囲の関係から説明する
顧客、購入手続き用アプリ、注文サービス、決済事業者、出荷サービスを含む全体図を用意します。関係を矢印だけで表さず、その役割を書いてください。「API」よりも「決済を承認する」のほうが意味を伝えられます。今回扱う注文サービスを明示し、外部システムはその境界の外側に置きます。
C4のシステムコンテキスト図のガイドでは、細部に入る前に、システム、利用者、接続先を俯瞰する図を示すことを勧めています。このように図の役割を分けるために、C4のすべての図を採用する必要はありません。
一件の注文を受付から出荷処理まで追う
キューによって何が変わるのかは、番号付きの処理の流れで説明します。次の表は、架空の小売業者を想定した例です。表と図の番号をそろえれば、発表者は該当する箱を探さずに、各処理を指し示せます。
| 順番 | 処理 | 伝えるポイント |
|---|---|---|
| 1 | 購入手続き用アプリが注文サービスに注文リクエストを送る | 一連の処理を追跡できる注文IDを持たせる |
| 2 | 注文サービスが決済の承認を確認する | 決済が拒否された注文では、出荷処理ジョブを作らない |
| 3 | 注文サービスが受付済み注文と未送信イベントを記録する | 注文の記録後、イベントの発行前に障害が起きる場合を設計で扱う |
| 4 | 発行処理が未送信イベントをキューに送る | 送信を再試行する場合があるため、イベントに変わらない識別子が必要 |
| 5 | 出荷サービスがイベントを受け取り、処理状態を記録する | 同じイベントを再受信しても、二重出荷を起こさない |
| 6 | 運用担当がジョブの状態や失敗通知を確認する | キューの導入は、リクエスト経路だけでなく監視と復旧の作業も変える |
C4の動的図は、特定のユースケースで実行時に起きるやり取りを順序付きで示せます。必要な部分に絞って使ってください。この例で重要なのは、すべての正常な呼び出しではなく、障害と再試行の経路です。
この例に「必ず一度だけ処理される」「注文を失わない」と書いてはいけません。その主張には、この資料には含まれていない実装の詳細とテストが必要です。代わりに、未送信イベントの復旧方法、失敗したジョブの保持期間、再実行の責任者といった設計上の問いを示します。
同じ観点で選択肢を比較する
メリットの文章とデメリットの文章を並べるだけでは、比較しづらくなります。同じ評価軸を使い、それぞれの方式で必要になる対応を示してください。
| 評価軸 | 出荷サービスを直接呼び出す方式 | キューを使う出荷処理 |
|---|---|---|
| 顧客への応答 | 注文受付が出荷サービス呼び出しの動作に依存する | 注文受付と、その後の処理を分離できる |
| 障害からの復旧 | 呼び出し経路内で再試行を扱う | ジョブ状態、再実行、重複への対応が必要 |
| 運用作業 | この処理の構成要素が少ない | キューの状態、失敗ジョブ、処理の遅延を管理する担当が必要 |
| 移行 | 新たなメッセージ経路は不要 | 試験導入と元に戻す手順が必要 |
この表は設計時の検討事項であり、測定した性能ではありません。実際の遅延やエラーのデータを加えるのは、環境、期間、対象サンプル、出典を示せる場合だけです。データがなければ、改善を断定するのではなく、範囲を限定した試験導入を提案します。
六枚のスライドに議論をまとめる
- 決定事項と範囲：提案する試験導入と対象外の項目。
- 全体像：注文サービスと直接つながるシステム。
- 現在の課題：提案のきっかけとなった、実際に観測された障害、遅延、運用上の制約。
- 提案する処理の流れ：六つのやり取りと障害が起こり得る箇所。
- 選択肢：両方式を同じ四つの評価軸で比較。
- 試験導入の判断：責任者、元に戻す手順、テスト、続行・中止を判断する日。
この例の最後のスライドでは、試験導入の判断日までに、プラットフォームチームがイベント発行の失敗、イベントの重複配信、出荷サービスの停止をテストするよう求められます。各テストには、期待する結果と、その結果を判断する担当者が必要です。資料だけで設計の結論が出るかのように扱わず、会議で具体的な次の行動を決められます。これらのテストを終えたら、リリース可否を判断するためのプレゼン資料で、結果を対象のリリース候補、未解決の阻害要因、実施可否を決める権限者に結び付けます。
自分たちの処理の流れ、比較表、試験導入の条件を使って、Presentiで六枚のスライドの初稿を作ることから始めてください。設定、ログ、テスト結果の詳細は付録やリンク先の設計記録に置けば、主な説明を圧迫せず、レビュー担当者が確認できます。
