システム構成図は何から描く？古い図の接続を確かめ直す手順

何のために、どの業務の構成図を作る？

システム構成図は、業務を支える部品と、その間の関係を図で説明するものです。読む人が知りたいことによって、必要な細かさは変わります。業務担当へ「注文を見る仕事はどこを使うか」を説明する図と、IT担当が通信の設定を調べる図へ、同じ情報を詰め込む必要はありません。

どこまでを今回の図に入れるか、枠の分かれ方を見てください。

今回の範囲は支店の受注確認です。月次集計を別枠にしても、使っていないとは判断しません。

境界とは、今回の図に含める範囲の区切りです。会社全体を一つの箱にせず、対象の業務、入口、主要なアプリ、必要な保存先や外部依存を選びます。範囲外のサービスでも対象業務が依存するなら、境界の外に名前を置き、どの関係を確認するかを残します。描かないことと、使っていないことは別です。

構成・手順・設置場所を、一枚で混ぜない

「どの部品が何に依存するか」は構成の話です。「担当者がどの順に操作するか」は仕事の手順、「どの設備やサービスに置くか」は配置の話です。最初の図は目的に必要な関係に絞り、細かな操作や配置は別の資料へつなぎます。クラウドへ移す案の採用判断や、バックアップの復元試験を、この図だけで済ませません。

古い資料から、今の説明に使える根拠を探す

古い構成図は調査の出発点になりますが、作成された時点の意図と、今の実態が同じとは限りません。線を写す前に、図の版、対象の業務、参照している資料を確かめます。更新日が新しいという理由だけで、すべての関係が現状と照合済みとも判断できません。

資料のどの記載を、どの線へ移すのかを見てください。

破線は作図の手順で、接続を示す線ではありません。青い線は原票の関係だけを表し、現状の動作は未確認です。

• 構成図や運用資料：どの業務と環境を説明したものか、版と該当箇所、変更の記録を探します。
• 手順書や問い合わせ記録：実際に使う画面名や部品名、当時の担当を確かめます。過去の対応記録は、今の接続の証明とは分けます。
• 閲覧できる管理情報：既に許可された範囲の一覧や設定、監視の情報を、担当者と対応付けます。一覧にあるだけで、その業務が今も使っているとは決めません。
• 担当者の確認：業務側には使う場面、IT側や提供会社には接続の根拠を聞き、回答と資料のどこが対応するかを残します。

資料同士が違う場合は、どちらかを勘で採用せず、「図のこの線と、運用資料のこの記載が一致しない」と具体化します。対象環境、版、反映範囲、説明する時点が違わないかを確認します。確認できる範囲が足りなければ、必要な情報を持つ担当へ照会します。記事の作業として、ネットワークの一括探索や機器・接続設定の変更は行いません。

部品名が分かることと、接続が分かることを分ける

図を描く前に、使う人、入口、認証、アプリ、保存先を言葉で並べます。入口は、仕事を始める画面や窓口です。認証は利用者が誰かを確かめる仕組みで、この例の原票には「社内ID」と書かれています。アプリは仕事を処理するもの、保存先は扱うデータを置く先です。

箱に書ける名前が集まっても、線を足してよいかは別に確かめます。

この図は部品名の一覧です。近くに並べたことは、接続、同一サーバー、同じ設置場所を意味しません。

ただし、「業務ポータル」「社内ID」「受注アプリ」という名前が分かっただけでは、その間の接続や認証の経路まで確定していません。名前を箱へ書く作業と、箱の間へ線を引けるかを確かめる作業を分けます。実際のサービス名や役割が曖昧なときは、担当者へ確認する欄を残します。

部品一覧に担当や設置場所があっても、接続の方向、読み書きの種類、通信方式まで補いません。図の目的に必要であれば、どの項目が分かり、どれを追加で確かめるかを決めます。実アカウントの秘密値や個人のデータは、構成を説明する図へ書き込みません。

根拠がある関係と、先が未確認の業務を見比べる

受注確認には、アプリと保存先の関係を示す資料がある設定です。月次集計では、保存先・接続・設置場所が未確認です。どの資料で説明できる関係かを項目ごとに比べ、分からない線は推測せず、確認先への質問にします。

同じ会社でも、業務ごとに根拠が違います。二つの枠を別業務として比べてください。

受注確認の一本の線には資料があります。月次集計の先を推測で補わず、両例とも最終確認日は未確認として残します。

次の図は、同じ架空会社の別々の業務です。「支店の受注確認」には、受注アプリから注文DBへの関係を示す資料と担当メモがある設定です。「月次集計を見る」では、集計画面の先にあるデータ元・接続・設置場所をまだ説明できません。両方とも最終確認日は未確認で、現在の実構成を照合し終えた例ではありません。

架空原票の全項目を読む

図で省略した欄も、次の二つの記入例へそのまま残しています。「未確認」は原票の空欄を表し、ゼロ・不要・未接続・不存在・障害や成功に置き換えません。「本社設備」という記載も、台数や同一サーバーへの同居、細かな通信経路までは示しません。

矢印へ、方向の意味と根拠を付ける

線を引くと、読む人は「この二つには関係がある」と受け取ります。古い線を残した理由が分からなければ、その前提で調査や変更を進めてしまうかもしれません。図には、何を表す方向なのか、どの資料と担当確認に対応するのかを付けます。

完成した説明図の一本の線を、下の根拠へ結び付けて読んでください。

これは資料とメモに記された関係の説明用下書きです。読み書きの種類、通信方式、現在の動作を実証した線ではありません。

1. 始点と終点を名前でそろえる。受注アプリと注文DBのように、どの部品同士の関係かを記します。部署名、画面名、サーバー名を同じ種類の箱として混ぜず、必要なら役割も添えます。
2. 矢印の意味を決める。処理を依頼する向き、データを送る向きなど、目的に合う意味を明記します。意味が違う矢印を同じ線で表さず、凡例で読み方を示します。往復するように見えるからと、根拠なしに双方向の線を足しません。
3. 根拠を関係へひも付ける。資料名、版、該当箇所、担当確認のメモを記録します。図を読む人が、なぜその線があるかをたどれるようにします。
4. 根拠が示していないことも残す。この架空原票の「受注アプリ→注文DB」は、資料とメモ上の関係です。読み書きの種類、通信方式、現在の動作結果までは記載されていません。必要な説明なら、追加で質問します。

細かな通信を確かめる必要が出たら、この図から対象を特定して、設定や接続を確認する別の作業へ渡します。構成図を描いたこと自体で、接続や権限、性能が正常に動いたことにはなりません。

分からない接続は、照会先と具体的な質問へ変える

月次集計の例で保存先が空欄なら、箱を推測で足さず、「集計画面のデータ元は何か」を質問にします。クラウド集計候補という名称も、現在利用しているサービスの証明ではありません。担当者の回答と資料がそろうまで、利用有無は未確認のままにします。

疑問符の先に新しい保存先を描くのではなく、質問メモへ残す部分を見てください。

集計画面の先の構成は描いていません。業務担当と提供会社へ、現在の対象と根拠資料を尋ねます。

質問には、対象業務、図の該当箇所、手元の資料の版、分からない点を添えます。「今の構成を全部教えてください」より、「この集計画面とデータ元の関係を、現資料のどこで確かめられますか」のほうが、確認する範囲を合わせやすくなります。

回答が「分からない」なら、確認できる担当や資料の所在、次に調べる範囲を残します。担当者が不明な場合は、システムの管理を取りまとめる人へ窓口を相談します。返事がないことを、未使用や不存在の結論にしません。ほかに裏付けがそろった部分は図に残し、照会中の部分と読み分けられる状態にします。

未確認の注記だけで図を埋めず、「何を知りたいか」「誰へ聞くか」「どの資料や確認で判断するか」まで書きます。現時点では判断を保留する部分と、説明できる部分が分かることが、次の作業につながります。

図の版・確認日・担当と、確認できた範囲を残す

構成図を後から読む人には、図を保存した日だけでなく、どこまで現状と照合したかが必要です。図の更新日と、関係を実際に確かめた日を区別します。見た目を整えて保存しただけで、確認日を新しくしません。

図の下書きと、その横に付く記録をセットで読んでください。

第2版は根拠資料の版です。図の版名は説明用の記入例であり、最終確認日を補うものではありません。

図の目的と対象範囲

読む人、対象業務、開始・終了、今回含める部品と範囲外を記します。

図の版と作成・更新担当

どの図が現在説明に使う版かを区別し、変更内容をたどれるようにします。古い版も、参照関係が分かる場所へ残します。

根拠資料と確認メモ

資料名・版・該当箇所、質問と回答の記録を、図の関係へひも付けます。閲覧する範囲と共有先は、社内で扱える情報に合わせます。

現状との照合日・確認者・確認範囲

実際に確かめたときに、その日と担当、確認した内容を記します。未実施なら空欄や未確認として残します。

未確認と次の確認

不明な関係、質問、照会先、次の作業を記します。全体を一括で確認済みにせず、関係ごとに区別します。

架空原票の両例は、最終確認日が未確認です。受注アプリと注文DBの関係に資料と担当メモがある設定でも、現在の状況といつ照合したかは補えません。図の説明へこの限界を付け、IT管理担当が改めて確かめる項目にします。

実パスワードや鍵などの秘密値を図へ書く必要はありません。システムの関係を説明する情報と、接続に使う機密情報の保管先を分けます。外部へ見せる場合も、説明に必要な範囲を関係担当とそろえます。

業務担当とIT担当で、図が説明する内容を確かめる

図を一人で仕上げる前に、その業務を知る人と、技術の関係を説明できる人に読み合わせてもらいます。全員の返事を一律に集めるという意味ではありません。知りたい関係ごとに、答えられる担当を選びます。

二人が別々の図を直すのではなく、同じ箱と線について質問する場面です。

業務側は呼び名と仕事、IT側は関係の根拠を確かめます。この読み合わせで動作試験まで合格したとは扱いません。

業務の見方：何の仕事を、どこまで表した図か

支店の受注担当には、受注確認という仕事と部品の呼び名が対応するか、入口や画面名に取り違えがないかを確かめます。原票にない操作や別業務を、図の流れへ混ぜていないかも見ます。画面の名前を知っていることと、その裏側の接続を知っていることは分けて聞きます。

ITの見方：箱と線を、どの根拠で説明できるか

IT管理担当や提供会社には、関係の始点・終点・向き、資料の版と対象環境、現状と照合した範囲を確かめます。根拠が一部にしかないなら、その一部だけを図へ反映します。運用資料が示す構想、現在の設定、動作確認の結果を、同じ確認として扱いません。

読み合わせを終える目印は、目的と範囲、根拠のある関係、未確認の質問先が、読む人に伝わることです。対象業務の動作や復旧まで試したと示すには、それぞれの確認が必要です。図のレビューの完了と、システム全体の正常性を分けて記録します。

回答や構成の変更があったら、図と元資料を一緒に直す

照会の回答が届いたら、まずどの業務・環境・関係についての回答かを確認します。根拠を見て、対象範囲に合う内容だけを図へ反映します。回答の文章を受け取っただけで、利用や接続の成功を認定しません。

破線は、回答が届いた後に行う更新の順番です。実際に更新済みの構成を示しません。

対象環境や資料が合わなければ、該当する説明を保留します。記録を受け取っただけで、未確認を確認済みへ変えません。

1. 未確認としていた質問と回答を対応付け、追加の資料や確認メモを残します。
2. 新しく裏付けがそろった関係へ、方向の意味と根拠を付けます。必要な確認が残る部分は、注記と次の作業を保ちます。
3. 根拠が変わった線や、現状と違うことが分かった説明を見直します。古い説明をそのまま現在の図へ残しません。
4. 図の版、変更内容、更新担当を残します。現状と照合した日と範囲は、実際に確かめた内容に合わせます。
5. この図を参照する手順書や関連図が分かっているなら、変更が関係する担当へ伝え、参照先の食い違いも確認します。

アプリの入替え、データの保存先の変更、認証や接続の変更、管理担当の交代などは、図を見直すきっかけになります。変更の記録と図を対応付けられる場所へ置き、誰が次に確かめるかを決めます。更新頻度や期限は、自社の変更と運用に合わせて相談します。

構成図から「移す対象は何か」「戻せるか」という別の疑問へ進むこともあります。移行するデータの照合は件数・金額・関連データを確かめるガイドへ、復元を試す計画はバックアップの復元テスト計画へ分けて進めます。接続の説明があることは、移行や復元の合格を示しません。