mcpField
A
arc42-section-06

arc42-section-06

github.com/msiccdev開発4539 回インストール16 週間前に更新
リポジトリ

arc42-section-06 について

arc42-section-06は、アーキテクトによるarc42のランタイムビュー作成を支援するスキルです。事前にシステムの文脈とシナリオを確認し、正常系・エラー系・品質目標を含む文書を作成します。

主な機能

  1. 013~5件のランタイムシナリオに集中
  2. 02構成とシナリオの文脈を先に確認
  3. 03正常系・エラー系・品質目標を網羅
  4. 04詳細度を3段階から選択
  5. 05チェックリストで確認・反復

活用シーン

  1. 01重要なランタイム相互作用の記録
  2. 02重要な処理の失敗時の復旧説明
  3. 03品質目標を支える動作の提示

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/msiccdev/arc42-toolkit --skill arc42-section-06

インストール後、Claude Code で/arc42-section-06を入力して読み込まれたか確認します。

詳細

arc42 第6章:ランタイムビュー

arc42 のエキスパートアーキテクトとして、第6章:ランタイムビューのドキュメント作成を支援します。

この章では、システムの動的な振る舞い、つまり重要なシナリオを実現するために、実行時にビルディングブロックがどのように連携するかを説明します。第5章の静的な構造を補完するものです。

選定ルール: シナリオは3~5件のみです。網羅性ではなく、アーキテクチャ上興味深いものを選んでください。どのシナリオにも、ここに記載する理由が必要です。

必須のシナリオ構成: 正常系のシナリオを少なくとも1件、エラーまたは復旧のシナリオを少なくとも1件、第1.2章の品質目標を直接示すシナリオを少なくとも1件、必ず含めてください。


ステップ1 — まず以下の質問をする

まだドキュメントを作成しないでください。 以下の質問をすべてして、回答を待ってください。

コンテキストの確認 — まず質問してください:

  • 第5章はありますか? ある場合は、コンポーネント名を取得してください。シナリオで参照できるのは、そこに存在するビルディングブロックのみです。
  • 第3章はありますか? ある場合は、外部アクター名とシステム名を取得してください。シナリオで参照できるのは、そこに記載された外部参加者のみです。
  • 第1.2章はありますか? ある場合は、品質目標を取得してください。少なくとも1件のシナリオを品質目標に関連付ける必要があります。

続けて質問してください:

  1. シナリオの選定 — ドキュメント化するうえで最も重要なランタイムシナリオを3~5件挙げてください。以下の基準を参考に選んでください。

    • システムの主要なユースケースにおける正常系
    • 重大なエラー、タイムアウト、または復旧の経路
    • 主要な品質目標(例:#efficient のためのキャッシュ、#reliable のためのフェイルオーバー)が実行時にどのように実現されるかを示すシナリオ
    • 直感的に分かりにくい、または誤解されやすいインタラクション
    • アーキテクチャ上重要な場合は、起動またはシャットダウンのシーケンス
  2. 各シナリオについて、以下を質問してください:

    • 何がトリガーになりますか?(ユーザー操作、外部イベント、スケジュールされたジョブ、システムイベント)
    • 第5章のどのビルディングブロックが関与しますか?
    • 第3章のどの外部アクターまたはシステムが参加しますか?
    • どのような順序で処理が進みますか?各参加者は何を送信、または返しますか?
    • 各ステップで何が問題となる可能性があり、どのように処理されますか?
    • 該当する場合、このシナリオは第1.2章のどの品質目標を示しますか?
  3. 詳細度 — LEAN、ESSENTIAL、THOROUGH のいずれにしますか?

    • LEAN: 番号付きの手順のみ — 図はありません
    • ESSENTIAL: 番号付きの手順 + C4 PlantUML シーケンス図
    • THOROUGH: 代替フローやエラーフローを含む C4 PlantUML 図全体

ステップ2 — ドキュメントを生成する

すべての回答が揃ったら、シナリオごとに小見出しを設けて第6章を作成してください。図は個別の .puml ファイルとして docs/diagrams/ に保存します。セクションの Markdown では図を参照してください。ソースをインラインで記載しないでください。

ランタイムシナリオの図ファイル(ESSENTIAL/THOROUGH の場合、シナリオごとに1つ)— docs/diagrams/runtime-[scenario-name].puml に保存してください。このソースをセクションの Markdown に含めないでください。そこに記載するのは画像参照のみです。

@startuml runtime-[scenario-name]
!include https://raw.githubusercontent.com/plantuml-stdlib/C4-PlantUML/master/C4_Dynamic.puml

title Runtime: [Scenario Name]

Person_Ext(actor, "Actor", "Description")
Container(compA, "Component A", "[Technology]", "Responsibility")
Container(compB, "Component B", "[Technology]", "Responsibility")
System_Ext(extSystem, "External System", "Description")

Rel(actor, compA, "1. sends request", "[protocol/format]")
Rel(compA, compB, "2. queries", "[protocol/format]")
Rel_Back(compA, compB, "3. returns result", "[protocol/format]")
Rel_Back(actor, compA, "4. responds", "[protocol/format]")

@enduml
# 6. Runtime View

## Overview

[1 paragraph: Which scenarios are documented, why were they chosen, and what does the set collectively illustrate about the system's dynamic behavior?]

---

## 6.1 [Scenario Name — e.g. "User Places Order"]

**Purpose:** [Why document this scenario? What does it illustrate architecturally?]

**Trigger:** [What starts this scenario?]

**Participants:** [Components from Section 5 and external actors from Section 3]

**Quality goal illustrated:** [Which goal from Section 1.2, or "none" if this is a structural scenario]

### Sequence



Steps:
1. [Actor / Component] sends [request / event / message] to [Component]
2. [Component] validates [what] and calls [Component]
3. [Component] fetches [data] from [Component]
4. [Component] returns [result] to [Component]
5. [Component] responds to [Actor]



![Runtime: [Scenario Name]](diagrams/runtime-[scenario-name].puml)

### Error Handling



| Step | Failure | System Response |
|------|---------|----------------|
| [N] | [What can go wrong] | [How the system responds — retry, fallback, error surfaced to user] |

---

## 6.2 [Scenario Name — e.g. "Payment Timeout and Retry"]

[Repeat structure for each scenario]

ステップ 3 — レビューと反復

ドラフトを提示したら、次のチェックリストを確認してください。不合格の項目があれば、問題点と対応方法をユーザーに伝えてください。黙って指摘するだけにしないでください。

シナリオ一式:

  • シナリオが 3〜5 件ある — 少なすぎず(不十分)、多すぎない(網羅しすぎ)
  • ハッピーパスのシナリオが少なくとも 1 件ある → ない場合は、主なユースケースをユーザーに尋ねてください
  • エラーまたは復旧のシナリオが少なくとも 1 件ある → ない場合は、最も重要なステップが失敗した場合に何が起きるかを尋ねてください
  • セクション 1.2 の品質目標につながるシナリオが少なくとも 1 件ある → ない場合は、実行時に最もよく実証できる目標を尋ねてください

各シナリオ:

  • 参照されているすべてのコンポーネントがセクション 5 に存在する → ない場合は、セクション 5 に追加するか、名前を修正してください
  • 参照されているすべての外部アクターまたはシステムがセクション 3 に存在する → ない場合は、セクション 3 に追加するか、名前を修正してください
  • トリガーが明示されている — トリガーがなければシナリオを開始できません
  • クリティカルパス上のシナリオについて、エラー処理が記載されている

図(ESSENTIAL/THOROUGH):

  • 図のファイルが命名規則 docs/diagrams/runtime-[scenario-name].puml に従っている
  • 図が Markdown 内で参照されており、インラインで記述されていない
  • 図に含まれるすべての参加者が、セクション 3 および 5 のコンポーネント名とアクター名に一致している

続けて、次のように尋ねてください。「何を調整または詳しく説明しましょうか?」 ユーザーが満足するまで反復してください。


docs.arc42.org/section-6 に基づいています

コメント