技術担当者がいなくてもできる！ 自社Webシステムを「1枚の図」で見える化する方法
Webサイトのリニューアルや、周辺システムの追加・統合を検討する場面では、「現状の仕組みを説明しきれない」ことが理由で議論が進みにくくなるケースがあります。たとえば、どこまでがCMSで、どこからが外部システムなのか、入力した情報が最終的にどこで管理されているのかが整理されていないと、要件整理の段階で確認事項や関係者調整が増えやすくなります。
一方で、検討初期から完璧な設計書を用意する必要はありません。打ち合わせの前提を揃える目的で「現状を説明できる1枚の図」があれば、論点の切り分けや確認順序が明確になります。
本記事では、技術部門が専任でいない体制でも取り組みやすい形で、自社Webシステムを1枚の図にまとめる手順を3段階でご紹介します。
目次
まずは今ある「画面」を大枠で並べる
最初のステップは、ユーザーが実際に閲覧・操作する「画面」を洗い出すことです。ここで言う画面は、システム名称ではなく、利用者が触れる単位で整理します。
まずは次の粒度で十分です。
- コーポレートサイト（例：企業情報・サービス情報）
- 採用サイト
- 会員サイト（マイページ）
- キャンペーン用LP（ランディングページ）
- ECサイト
- 社内で利用する管理画面（CMSの更新画面、受注管理画面 など）
この段階では、システムの正式名称や技術要素を正確に言い当てることを目的にしません。たとえば次のように「誰が何をしている画面か」で表現して問題ありません。
- 名称は不明だが、広報がニュースを更新している画面
- 営業が資料ダウンロード数を確認している管理画面
併せて、画面の分類はこの時点で標準化しておくと後工程が進めやすくなります。たとえば「社外向け／社内向け」「公開側／運用側」といった切り口で分け、図の中で同じ言葉を繰り返し使う運用にすると、認識齟齬が起きにくくなります。
次に「登場人物（ユーザー）」を書き足す
2ステップ目では、その画面を利用している「登場人物」を追加します。ここでは「誰がどの画面を、何の目的で使うか」を固定していきます。
社外の登場人物の例は次のとおりです。
- 見込み顧客
- 既存顧客
- 代理店・パートナー
社内の登場人物の例は次のとおりです。
- 広報・マーケティング担当
- 営業・インサイドセールス
- コールセンター／サポート
- 情報システム部門
- 事業部の担当者
- 最上位管理者（システムの全権限を持つ管理者ロール）
画面を並べた図の周囲に登場人物を配置し、矢印やメモで関係を書き添えます。
- 見込み顧客 → コーポレートサイト／LP（情報収集、問い合わせ）
- 既存顧客 → 会員サイト（契約内容確認、各種申請）
- 広報 → CMS管理画面（ニュース更新）
- 営業 → MAツールの画面（見込み顧客の反応確認）、ダウンロード履歴の確認画面
※MAは「マーケティング活動を支援するツール」、CRMは「顧客情報を管理する仕組み」を指すことが一般的です。社内の呼称に合わせて置き換えてください。
ここまで整理すると、次のような判断がしやすくなります。
- どの登場人物にとって重要度が高い画面か
- アクセスや作業が集中する起点（問い合わせ、申込、ログイン後の導線など）はどこか
- 誰が運用作業を担っており、責任分界（担当範囲）は適切か
「データの流れ」を矢印で描いてみる
3ステップ目では、画面間で「どんな情報が、どこへ渡っていくか」を矢印で整理します。専門用語を前提にせず、入力された情報の最終的な管理先を特定する意識で進めます。
代表例は次のとおりです。
- お問い合わせフォーム → CRM（顧客情報の管理）
- 資料ダウンロードフォーム → MAツール（反応履歴・スコアの管理）
- ECサイト → 受注管理システム → 倉庫システム
- 会員登録フォーム → 会員DB（会員データベース）→ メール配信システム
このとき、「どうやって連携しているか（API連携、ファイル連携、バッチ処理など）」まで正確に書けなくても問題ありません。分からない部分は、分からないことが分かる状態にしておくことが重要です。
- ここから先の管理先が不明
- たぶんSFA（営業支援の仕組み）と連携している可能性がある
この可視化により、後工程で増えやすい作業を早めに把握できます。たとえば、連携が増えるほど監視項目が増え、障害時の切り分けに要する時間や関係者が増える傾向があります。あわせて、ログは量を増やすことよりも「どの操作が、どのデータに反映されたか」を追跡できる構造にできているかが、運用性に直結します。
図は「相談のたたき台」になれば十分
ここまでで、次の3点を1枚にまとめた図が完成します。
- 画面の一覧（どんな画面が存在するか）
- 登場人物と画面の関係（誰がどこを使うのか）
- データの流れ（情報がどこからどこへ流れるのか）
重要なのは、図が完全に正確であることではありません。むしろ次の情報が共有できる状態にすることが価値になります。
- 社内から見えている現状はこう整理できる
- つながりを把握できていない箇所はここである
- 手作業が残っており、運用工数が増えている箇所はここである
この状態になっていれば、抜け漏れの確認、二重管理の洗い出し、将来的な拡張時に論点が増えそうな箇所（例：SSO、API連携、バッチ処理の追加など）を整理しやすくなります。
完璧な設計図より、まずは1枚の概略図を用意する
自社のWebシステムを最初からすべて言語化しようとすると、確認範囲が広がり、着手のハードルが上がりやすくなります。まずは次の3段階で作る1枚の概略図から始めることをおすすめします。
- 画面（利用者が触れる単位）
- 登場人物（利用者と運用者）
- データの流れ（入力情報の管理先と連携）
そのうえで「何が整理できていて、何が未整理か」を明確にすると、検討の優先順位を付けやすくなります。
次のアクション例（検討初期の進め方）
- 現状の棚卸し（画面・登場人物・データの流れ）
- 非機能要件の整理（セキュリティ、性能、運用体制、監視、権限、バックアップ／復旧手順など）
- 方式選定の判断材料化（どこを標準化し、どこを個別最適にするか）
- 移行ステップ設計（出し分け → 申込 → 変更 → 決済のように、拡張順序と分岐を決める）
LYZONでは、検討初期の「棚卸し」や「前提整理」の段階からご相談いただけます。現状メモの粒度でも構いませんので、まずは1枚の図を起点に、論点と優先順位を一緒に整理します。
よくあるご質問（要件整理・要件定義）
Q1. 要件整理を始めるとき、最初に何を整理すれば全体像が見えますか
まずは、次の3点を一覧化してください。
- どの部門が運用主体か
- 誰に向けた情報か（見込み顧客、既存顧客、代理店など）
- どんな情報を扱うか（代表的なコンテンツ種別を2〜4個に絞る）
加えて「更新頻度（例：週次／月次）」「年間の増加件数」「承認の要否」を併記すると、運用体制や権限設計の論点を早期に固定しやすくなります。
Q2. 要件定義の打ち合わせで論点が混在しないために、最初に決めておくべきことは何ですか
「今の議論が公開側（ユーザーが見る側）か、運用側（管理画面・運用手順）か」を都度明確にし、前提を揃えることが重要です。ここが曖昧だと、後工程で「どの画面の話だったか」を再確認する作業が増えます。
また、機能一覧から入るのではなく、「登場人物×アクション×画面」で整理しておくと、利用者が不明確な機能を追加してしまうリスクを下げられます。
Q3. 権限や運用負荷が後工程で増えることを防ぐには、どんな聞き方が有効ですか
権限は、アクションをCRUD（作成・参照・更新・削除）に分解し、「誰が、どの操作を、どの範囲で必要とするか」で決めると抜け漏れが減ります。たとえば「参照のみの想定だったが、運用開始後に更新が必要になった」という論点は現場で頻出します。
あわせて、運用負荷は「量」と「頻度」で変わります。要件定義の段階で、次の項目を確認しておくと、運用工数や体制要件の見直しが必要になるリスクを下げられます。
- 年間で何件増えるか（増加件数）
- 誰が、どの頻度で更新するか（担当と頻度）
- 承認の有無と承認者（最上位管理者の関与範囲を含む）
- 障害時の切り分け担当と連絡フロー（責任分界）
株式会社LYZONの社内ニュースを始め、デザインの知識やお役立ち情報など様々な情報を発信しています。
