# Asis Tobe Diagram > 業務改善・BPR・システム導入のAs-is / To-beを、資料・議事録・画像・箇条書きから構造化し、必要なヒアリングをまとめて行った上で、保守可能なJSONと自己完結型HTML図として生成・更新・レビューする。現行業務、将来業務、業務フロー、システム連携、手作業、RPA、課題、KPI、変更点を可視化したい依頼で使用する。一般的な単発フローチャートや、見た目だけの画像生成には使用しない。 - Skill: `mmkkkkzz/asis-tobe-diagram` (Agent Skill, multi-file: 28 files) - Install (CLI): `npx skillmds@latest add mmkkkkzz/asis-tobe-diagram` - Raw SKILL.md: https://api.skillmd.com/api/skills/mmkkkkzz/asis-tobe-diagram/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Web & Frontend - Author: mmkkkkzz (https://skillmd.com/u/mmkkkkzz) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/mmkkkkzz/asis-tobe-diagram --- # 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**: 既存図の意味・網羅性・可読性・根拠・保守性を監査する。明示されない限り再作図しない。 ## 最初に行うこと 1. 与えられた資料をすべて読み、情報源を列挙する。 2. `references/interview-playbook.md` の観点で、既知・不明・矛盾を整理する。 3. 次を判定する。 - 図の目的と想定読者 - 対象範囲、開始条件、終了条件 - As-isとTo-beのどちらがどの程度判明しているか - 事実、要望、推測、未確定事項の区別 - 出力の粒度と用途（経営説明、顧客合意、要件定義、実装設計など） 4. 既存資料から回答可能なことを質問しない。 ## ヒアリング方針 不足情報が成果物の正確性を大きく左右する場合だけ質問する。質問は原則として**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つの担当レーンと1つの工程ステージに属する。 2. ノード名は「動詞＋目的語」を基本とし、曖昧な名詞だけのラベルを避ける。 3. 人、組織、システム、データ、帳票、判断、統制、例外を区別する。 4. 手作業、自動、半自動を明示する。色だけに依存せず、ラベルまたは記号も付ける。 5. 課題は該当ノードまたはエッジに紐付ける。 6. To-beの変更は、少なくとも1つの課題または戦略目的に紐付ける。 7. KPIは、変更による成果または運用品質を測れるように紐付ける。 8. 情報源を `sourceIds` で追跡する。根拠のない事実を断定しない。 9. 仮定は `meta.assumptions`、未解決事項は `openQuestions` に分離する。 10. 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. 出力ディレクトリ ユーザーが指定しなければ、作業ディレクトリ配下に次を作る。 ```text 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` として解決し、次を実行する。 ```bash python3 /scripts/validate.py \ --input asis-tobe-output/process-model.json \ --strict ``` エラーは必ず修正する。警告は、修正するか、妥当な理由を `decision-log.md` に残す。 ### 4. HTML生成 ```bash python3 /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` には、次の順で記録する。 1. 意思決定を止める質問 2. 要件定義までに必要な質問 3. 実装前に必要な質問 4. 精度向上用だが非ブロッカーの質問 ## 品質ゲート 最終化前に `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差分を正本にしない。 ## レビューモードの追加ルール 指摘は次の優先順位で整理する。 1. **Critical**: 誤解を招く、根拠がない、統制・法令・責任の欠落、As-is/To-be混同 2. **High**: 重要な例外・システム境界・変更根拠・KPIの欠落 3. **Medium**: 可読性、用語不統一、線交差、過密、曖昧なラベル 4. **Low**: 配色、余白、補助情報、表記揺れ 各指摘には、対象ID、問題、影響、具体的な修正案を付ける。 ## 最終応答 ユーザーには、次だけを簡潔に返す。 - 作成または更新した成果物へのリンク - 図の対象範囲と主要な改善点の要約 - 残っているブロッカー質問 - 仮定が多い場合は、その旨と影響 内部の長い検証ログをそのまま貼らない。