mmkkkkzz As-is / To-be Diagram
業務改善の内容を「きれいな絵」ではなく、根拠・課題・変更・効果を追跡できる業務モデルとして作る。最終成果物は、編集可能な process-model.json と、オフラインで閲覧・編集・SVG/PNG出力・PDF印刷できる自己完結型 asis-tobe.html を基本とする。
対応モード
依頼内容から次のいずれかを選ぶ。
- create: 断片的な資料やヒアリングから新規作成する。
- reconstruct: 既存画像・PowerPoint・PDF等の図を読み解き、意味構造を再構築する。単なるピクセル模写はしない。
- update: 既存
process-model.jsonまたはHTMLを更新する。既存IDを可能な限り維持する。 - review: 既存図の意味・網羅性・可読性・根拠・保守性を監査する。明示されない限り再作図しない。
最初に行うこと
- 与えられた資料をすべて読み、情報源を列挙する。
references/interview-playbook.mdの観点で、既知・不明・矛盾を整理する。- 次を判定する。
- 図の目的と想定読者
- 対象範囲、開始条件、終了条件
- As-isとTo-beのどちらがどの程度判明しているか
- 事実、要望、推測、未確定事項の区別
- 出力の粒度と用途（経営説明、顧客合意、要件定義、実装設計など）
- 既存資料から回答可能なことを質問しない。
ヒアリング方針
不足情報が成果物の正確性を大きく左右する場合だけ質問する。質問は原則として1回のまとまった質問群にし、最大8問までとする。質問攻めにしない。
必ず確認すべきブロッカー
次のいずれかが不明で、資料から安全に推定できない場合は確認する。
- 図で意思決定したいこと、想定読者
- 対象業務の開始・終了・対象外
- 主な担当者または組織
- To-beで絶対に守る制約（法令、統制、既存システム、期限、予算など）
- 現行と将来を区別するための最低限の業務ステップ
質問せず仮置きできるもの
次は、ユーザーが早い初稿を求めている場合、明示的に「仮置き」「要確認」として進めてよい。
- 正確な件数、工数、エラー率、金額
- 未確定のシステム製品名
- 詳細な例外分岐
- To-beの実装方式の細部
質問文の作り方
- 目的別にまとめ、選択肢を添える。
- 「なぜ必要か」を短く示す。
- 既知情報を前提として明記し、回答負担を減らす。
- 回答がなくても進められる項目には「未回答の場合の仮定」を付ける。
- 画像が低解像度で文字を確実に読めない場合は、原本または高解像度版の有無を1回だけ確認し、読めない文字を捏造しない。
詳細は references/interview-playbook.md を参照する。
モデリング原則
assets/model.schema.json と references/modeling-guidelines.md に従い、まず process-model.json を作る。HTMLを直接手書きして意味構造を埋め込まない。
必須原則:
- 各処理ノードは、原則として1つの担当レーンと1つの工程ステージに属する。
- ノード名は「動詞＋目的語」を基本とし、曖昧な名詞だけのラベルを避ける。
- 人、組織、システム、データ、帳票、判断、統制、例外を区別する。
- 手作業、自動、半自動を明示する。色だけに依存せず、ラベルまたは記号も付ける。
- 課題は該当ノードまたはエッジに紐付ける。
- To-beの変更は、少なくとも1つの課題または戦略目的に紐付ける。
- KPIは、変更による成果または運用品質を測れるように紐付ける。
- 情報源を
sourceIdsで追跡する。根拠のない事実を断定しない。 - 仮定は
meta.assumptions、未解決事項はopenQuestionsに分離する。 - As-isとTo-beで同じ概念は同じ用語を使い、比較可能性を保つ。
図の設計
references/visual-design-system.md に従う。
- 原則はAs-isを上、To-beを下に配置する。比較重視なら左右配置も可。
- 可能な限りAs-isとTo-beでレーン順・工程順を揃える。
- 1画面に詰め込みすぎない。目安として、各状態6レーン、8工程、35ノードを超える場合は、概要図と詳細図に分ける。
- エッジ交差を最小化する。長距離の戻り、例外、データ連携は線種を分ける。
- 「変更点帯」「課題一覧」「変更台帳」「KPI」「仮定・未解決事項」「根拠」をHTML内に持たせる。
- 機密情報や個人情報は必要最小限にし、分類を
meta.confidentialityに記録する。 - 外部CDN、外部フォント、外部トラッキングを使わない。
生成手順
1. 出力ディレクトリ
ユーザーが指定しなければ、作業ディレクトリ配下に次を作る。
asis-tobe-output/
process-model.json
asis-tobe.html
decision-log.md
open-questions.md
同名がある場合は上書きせず、日付時刻または連番を付ける。ただし update モードでは指定された成果物を更新し、更新前のバックアップを残す。
2. モデル作成
assets/sample-model.jsonを構造例として参照する。- 入力資料、ヒアリング回答、仮定をモデルへ反映する。
- IDは短く安定した形式にする。例:
A-03,T-05,P-02,C-04,K-01。 - updateモードでは、意味が同じ要素のIDを変更しない。
- バージョンはセマンティックバージョニングを使う。内容変更は原則patch、構造変更はminor、互換性のないスキーマ変更はmajorとする。
3. 検証
スキルディレクトリを SKILL_DIR として解決し、次を実行する。
python3 <SKILL_DIR>/scripts/validate.py \
--input asis-tobe-output/process-model.json \
--strict
エラーは必ず修正する。警告は、修正するか、妥当な理由を decision-log.md に残す。
4. HTML生成
python3 <SKILL_DIR>/scripts/render.py \
--input asis-tobe-output/process-model.json \
--output asis-tobe-output/asis-tobe.html
生成HTMLは自己完結型であり、ブラウザ内で以下を行える。
- ノード詳細の確認
- ズーム、フィット
- JSON編集と再描画
- JSON保存
- SVG/PNG出力
- 印刷/PDF保存
- 変更台帳、KPI、課題、仮定、未解決事項、根拠の閲覧
5. 目視確認
ブラウザを利用できる場合はHTMLを開き、少なくとも次を確認する。
- ラベル切れ、重なり、線の不自然な交差がない
- As-isとTo-beの比較軸が揃っている
- 重要な課題・変更・KPIが見つけやすい
- 100%表示と縮小表示の双方で読める
- 印刷時に操作UIが消え、図が欠落しない
6. 補助文書
decision-log.md には、スコープ、主要な設計判断、採用した仮定、図を分割した理由、未採用案を記録する。
open-questions.md には、次の順で記録する。
- 意思決定を止める質問
- 要件定義までに必要な質問
- 実装前に必要な質問
- 精度向上用だが非ブロッカーの質問
品質ゲート
最終化前に references/quality-gates.md を使って自己レビューする。特に次を満たすこと。
- 開始・終了・対象外が明示されている
- 主要な処理に担当がある
- 孤立ノード、参照切れ、重複IDがない
- 課題 → 変更 → KPI の追跡ができる
- As-isの問題を解決しないTo-be要素が、戦略目的なしに追加されていない
- To-beの例外処理、失敗時対応、運用責任が無視されていない
- 事実と仮定が混在していない
- 色覚差や白黒印刷でも識別できる
- 元データJSONだけで再生成できる
更新モードの追加ルール
- 既存JSONを正本として読み、HTMLから逆推定しない。JSONがない場合のみHTML埋め込みモデルを抽出する。
- 変更前にバックアップを作る。
- ID、レーン、ステージの並びを必要なく変えない。
meta.version、meta.updatedAt、meta.changeLogを更新する。- 削除した要素は、理由を変更履歴に残す。
- HTMLを再生成し、手編集されたHTML差分を正本にしない。
レビューモードの追加ルール
指摘は次の優先順位で整理する。
- Critical: 誤解を招く、根拠がない、統制・法令・責任の欠落、As-is/To-be混同
- High: 重要な例外・システム境界・変更根拠・KPIの欠落
- Medium: 可読性、用語不統一、線交差、過密、曖昧なラベル
- Low: 配色、余白、補助情報、表記揺れ
各指摘には、対象ID、問題、影響、具体的な修正案を付ける。
最終応答
ユーザーには、次だけを簡潔に返す。
- 作成または更新した成果物へのリンク
- 図の対象範囲と主要な改善点の要約
- 残っているブロッカー質問
- 仮定が多い場合は、その旨と影響
内部の長い検証ログをそのまま貼らない。