現状の業務とシステムを棚卸しする９大フォーマット

0.はじめに

多くの人が開発プロジェクトを始めるにあたり、「現時点の業務やシステムをまず調査すべし」を理解しています。

ただし、調査の目的を理解せずに「とりあえず調べています」というプロジェクトが多く、調査にばかり時間を使ってしまっているケースが多いです。

この記事では、漏れなくスムーズに業務とシステムを棚卸しするための代表的なフォーマットを紹介します。

1.現状調査の2つの方針

まず、開発プロジェクトで現状を調査する目的や調査方針には2種類あることを理解しておきましょう。

• 課題発見型
• 棚卸し型

1.1.課題発見型

1つめは、変えるべきことをはっきりさせるために行う調査です。

現状を調べることで、業務やシステムがどんな構造になっていて、何がガンなのかを明らかにする（それを課題と呼ぶ）。

プロジェクトとしてやっつけたい課題が特定できたら、それに対する解決策のアイディアを磨いていくと、それがプロジェクトの骨格となる（施策と呼ぶ）。

課題発見型は、以下の手順で進める。

• ざっくり調査し、大きな課題がありそうな部分を特定する
• 課題があるところを深掘り調査する
• 調査でわかったことを様々な角度から分析し、課題構造を明らかにする
• 分析結果を課題一覧や施策一覧にまとめる

あくまで課題を探し、的確な解決策を見つけることが目的なので、問題がない業務やシステムを詳細に調査するのは時間のムダ。なので、メリハリを付けた調査を心がける必要があります。

1.2.棚卸し型

もう1つの調査は、システム構築の検討材料を集めるためのものです。

例えばシステム機能の候補をもれなく洗い出すには、現状調査が必須となります。

今の業務を知らないと、システム構築の最中に「え？そんな業務もやっていたのですか？」となってしまいます。

同様に現行システムを知らないと「え？経理システムにこんなデータも渡さないといけないんですか？」となってしまいます。

いずれのケースでも作り直しや、想定していなかった機能を開発することになり、スケジュールや予算を圧迫します。

なので課題発見型とは違い、棚卸し型では網羅性がポイントとなります。どうせ後から調査が必要なのであれば、プロジェクト初期に洗いざらい調べておくべきです。

今回はこの棚卸し型の解説となります。

2.現状の業務とシステムを棚卸しする９大フォーマット

業務とシステムが現在どうなっているかを棚卸しするための代表的なフォーマットを紹介します。

業務とシステムを棚卸しする９大フォーマット（サマリ）

2.1.業務フロー

業務フローとは、現行の業務手順を初めから終わりまで一通り記述するフォーマットです。業務の全体像を「誰が・何を・どの順番で行っているのか」を矢印と図で表現するため、現場担当者から経営層まで直感的に理解できるのが大きな特徴です。

特徴

• 視覚的に理解できる
  流れを図示するため、会話だけでは見落としがちなタスクの重複や無駄なやり取りを簡単に発見できます。
• 担当者ごとの役割を明確化できる
  部署や役職ごとにレーンを分けて記述する形式は「スイムレーンチャート」と呼ばれます。これを使うと「どの部署がどの工程を担当しているのか」が一目で分かります。

利用する場面

• 業務の現状把握や課題発見をしたいとき
• 将来業務フロー（To-Be）を設計する前段階
• システム導入の要件定義資料としてベンダーに説明するとき
• システムテストのシナリオや、新システム説明会の資料作成

効果

現状の業務フローを作成しておけば、将来業務フローを描くときの比較対象となり、改善点を明確に示すことができます。結果として、後続の要件定義やシステム設計がスムーズになり、手戻りのリスクを減らせます。

参考例

2.2.アクティビティ一覧

アクティビティ一覧とは、業務に関する情報を網羅的に洗い出すためのフォーマットです。業務フローと同じく業務の流れに沿って記述しますが、分岐が少ない業務ではこちらの方が短時間で作成でき、多くの情報を記載できるという特徴があります。

特徴

• アクティビティ（業務タスク）の分解
  業務をレベル1〜3に細分化して階層化します。
• 付加情報の整理
  各アクティビティに対して「作業者」「利用システム」「作業ボリューム」などを付け加えます。
• 網羅性の高さ
  業務に関する情報をすべて一覧に集約できるため、システム構築の検討に必要な材料を一箇所で把握できます。

利用する場面

• 業務改革プロジェクト：非効率な業務を議論する場合は業務フローを使うことが多い
• システム構築プロジェクト：網羅的で緻密な情報が必要な場合にはアクティビティ一覧が有効

例えば、新システム導入を検討するときに「どの作業がどのシステムを利用し、どのくらいの件数が発生するのか」を一覧化することで、必要な機能や処理能力を漏れなく洗い出すことができます。

効果

• システム要件の漏れを防ぐ：各アクティビティに紐づくシステム利用や処理件数を整理できるため、後から「想定外の機能が必要だった」という事態を防げます。
• 見積もり精度の向上：作業ボリュームや頻度を把握できるので、システム負荷やコストの試算が現実的になります。
• 一元化による共有のしやすさ：担当者・利用システム・業務量などを一表にまとめられるため、関係者間での認識合わせが容易になります。

参考例

2.3.ファンクションマトリックス

ファンクションマトリックス（FM）とは、システムの機能をマトリクス形式で整理したフォーマットです。現行システムの機能をひと目で把握でき、さらに将来作りたいシステムの機能整理にも利用されます。

特徴

• 一覧性の高さ
  システム全体の機能を表形式で整理することで、「この領域がごっそり抜けている」「複数のシステムを無理やり組み合わせている」といった課題を一望できます。
• 現行版と将来版の比較
  現行FMと将来FMを並べることで、追加すべき機能や改善対象がどこかを視覚的に比較できます。
• チェックリストとして活用
  システム要件の漏れを確認する際に、「すべての領域に必要な機能が網羅されているか」を確認できます。

利用する場面

• 現行システムの棚卸し：既存の機能を整理し、どの領域に問題があるかを議論するために利用
• 将来システムの設計：新たに追加する機能や改善する領域を示すために利用
• 要件定義の精度向上：必要な機能の有無を一覧で確認し、漏れを防ぐ

効果

• 全体像を把握しやすい：システム全体を鳥瞰できるため、関係者間の認識を揃えやすくなります。
• 問題発見の効率化：領域ごとの機能の偏りや不足を発見でき、議論がスムーズになります。
• 業務担当者とのコミュニケーションに有効：プログラム一覧のように細かすぎず、現場でも理解しやすいレベルで議論可能になります。

注意点

現行FMを作るときに、エンジニア提供の「プログラム一覧」をそのまま流用しないことが重要です。プログラム一覧は詳細すぎて業務担当者には伝わりにくいため、業務フローやアクティビティ一覧から機能を拾い出すほうが、議論に使えるFMを作成できます。プログラム一覧は補足的に、抜け漏れのチェックに活用するのが良い方法です。

参考例

2.4.システム一覧

システム一覧とは、プロジェクトに関係するシステムを網羅的に洗い出すためのフォーマットです。システム刷新の際に「どの範囲を今回の対象とするか」を判別したり、データ移行の際に「どれだけデータが分散しているか」を把握するための基礎資料となります。

特徴

• 1システム1行で整理
  各システムごとに「開発言語」「導入パッケージ」「利用者」「管理者」「保守契約期限」などの基本情報をまとめます。
• 公式システムだけでなくEUCも対象
  IT部門が開発した公式システムだけでなく、現場担当者がExcelやAccessで構築したEUC（End User Computing）も必ず含めるのがポイントです。
• FMとの違い
  ファンクションマトリックス（FM）が「機能」の一覧であるのに対し、システム一覧は「システム本体」を整理する技術的な一覧です。

利用する場面

• システム刷新の範囲決定：今回のプロジェクト対象とするシステムを明確化する
• データ移行計画の策定：どのシステムにどのデータが存在するかを把握する
• システム統廃合の検討：重複システムや利用目的が曖昧なものを特定する

効果

• システムの全体像を俯瞰できる：公式・非公式を含めてすべてのシステムを一覧化することで、漏れなく全貌を把握できます。
• 重複・偏りを発見できる：同じ業務範囲を複数システムでカバーしている、あるいは逆に全くサポートされていない領域が見つかります。
• メンテナンスやリスク管理に活用できる：保守期限切れシステムや管理者不明のシステムを早期に洗い出せます。

参考例

2.5.インターフェース一覧

インターフェース（I/F）一覧とは、再構築対象システムと他システムをつなぐインターフェースを整理したフォーマットです。現代の業務システムは単独で稼働することは少なく、複数のパッケージやスクラッチ開発システムが相互にデータをやり取りして構成されています。そのため、システム再構築時には現行I/Fの全容を把握し、抜け漏れなく検討することが欠かせません。

特徴

• I/Fの基本情報を整理

  • From（連携元）とTo（連携先）
  • 連携されるデータの内容
  • 受け渡しの技術方式（API、バッチ、ファイル転送など）
  • データ受け渡しタイミング（リアルタイム／日次／月次）

• システム横断の可視化
  I/Fを一覧化することで、どのシステム間に依存関係があるかがひと目で分かります。

利用する場面

• システム再構築の設計時：対象システムと外部システムの接続を見直す際に必須
• データ移行計画：どのI/Fを通じてデータが流れているかを把握し、移行後のシナリオに反映
• 業務効率改善の議論：「二重入力が多い」「リアルタイム連携されない」などの課題を洗い出すために活用

効果

• 抜け漏れ防止：現行I/Fを一覧化しておくことで、新システム移行時の連携忘れを防止できます。
• 改善点の可視化：リアルタイム連携や重複入力の改善ポイントを具体的に検討できます。
• 依存関係の理解：システム間の結びつきを俯瞰でき、リスク評価やテスト計画に役立ちます。

参考例

2.6.システム構成図

システム構成図とは、現在のシステム全体像を俯瞰的に表現した図です。厳密に決まったフォーマットはありませんが、一般的にはパワーポイントなどで機能やシステム間の関係性を図示します。表形式では見えづらい全体像をひと目で把握できる点が特徴です。

特徴

利用する場面

• 現状把握：現行システムの構成範囲やデータの流れを関係者全員で共有するとき
• 課題検討：どこで業務上の問題が発生しているかを議論する際の土台として
• 将来構想の比較：現行と将来の構成を並べて、どこを改善・追加するかを説明するとき
• 段階的移行の整理：大規模プロジェクトでは「2025/4時点」「2026/10時点」といった形で複数枚作成し、時系列でシステムの変化を示す

効果

• 全体像の共有：関係者が一目でシステムの全体像を理解できる
• 議論の促進：「今回のプロジェクトの範囲はどこか」「将来どこを変えるのか」を具体的に話し合える
• 計画の整理：段階的に変化していくプロジェクトを図示することで、複雑な計画も直感的に理解できる

参考例

2.7.システムの主要データ

システムの主要データ一覧とは、現行システムが管理しているデータを整理したフォーマットです。大きく以下の2種類に分けて記載します。

• マスタデータ：商品や社員など、日々大きく変化しない基礎情報
• トランザクションデータ：発注や経理仕訳など、日々の業務で発生する取引記録

特徴

• 業務担当者が理解できる粒度で整理
  現行データベースの項目一覧をそのまま出すと、数千のカラム名（暗号のような項目）が並び、議論には使えません。
  → 業務で使う「商品」「顧客」「社員」「発注」「売上」といった単位で表現することが重要です。
• データの性質を明確化
  データをマスタ／トランザクションに分けておくことで、管理対象の性格や更新頻度を把握できます。

利用する場面

• 要件定義の基礎資料：新システムに必要なデータ構造を検討する際の土台
• データ移行計画の立案：どのデータをどこからどこへ移行するかを決める際に利用
• データ品質改善の議論：マスタの重複やトランザクションの入力不備など、現状課題を特定する

効果

• 業務目線での整理が可能：専門用語やデータベース項目名にとらわれず、現場と共通認識を持てる
• 漏れを防止：業務に必要なマスタやトランザクションを一覧化しておくことで、システム再構築時の取りこぼしを防げる
• データ移行の精度向上：対象データを明確にしておくことで、移行範囲やデータクレンジングの計画を立てやすくなる

参考例

2.8.コード体系

コード体系とは、現行システムで利用されている主要なコードを整理したフォーマットです。コードはシステムやデータの根幹を成すものですが、全体を網羅的にまとめた資料は意外に存在しません。そのため、あらかじめ調査するコードの種類や採番ルールを決めて整理していくことが重要です。

特徴

• 業務ごとの識別子を整理

  • 人事系：社員コード、資格コード
  • 営業系：受注コード、取引先コード
  • その他：商品コード、会計コード など

• コード体系・採番ルールを明示
  各コードがどのように採番されているか（連番／部門ごと／属性込みなど）を明らかにすることで、システム上の一貫性を確認できます。

• 情報の複雑さを反映
  1つのコードに複数の意味が込められていたり、部門ごとに異なるコード体系が存在する場合、データ連携や業務処理に余計な負荷がかかることがあります。

利用する場面

• システム再構築の要件定義：必要なコードや採番ルールを整理し、将来システムに反映させるために活用
• データ移行計画：既存コードと新コードのマッピングを検討するときに必須
• 業務効率改善：複雑・不統一なコード体系が原因で発生している余分な処理を洗い出す

効果

• コードと業務の対応を確認できる：主要な業務情報がコードで識別され、システム機能として正しく扱われているかをチェックできます。
• 不統一による非効率の把握：コード体系の不統一や複雑化が、データ連携や検索精度の低下につながっている箇所を発見できます。
• 将来のデータ設計に役立つ：一覧を整理することで「理想的なコード体系はどうあるべきか」を検討する材料になります。

参考例

2.9.課題一覧

課題一覧とは、現状の棚卸しを進める中で発見した課題を一元的に集約するフォーマットです。将来の施策検討やあるべき姿を描く際の基盤となる資料です。

特徴

• 課題をまずは整理せずに収集
  非効率な業務やシステム機能の不足などを、発見した段階でとにかく一覧に記録します。
• 出どころを明確に記録
  「どの部署の誰から聞いた課題か」を残しておくことで、後から再確認や追加調査が可能になります。
• 多様な視点から課題を追加
  ヒアリング結果だけでなく、プロジェクトメンバーが業務分析の中で見つけた構造的な課題も加えていきます。

利用する場面

• 施策検討：将来像を検討する際に、どの課題を優先して解決すべきかを決める基礎資料になる
• 課題間の関係性整理：因果関係を分析し、根本的な課題を特定する
• 関係者共有：「どの業務領域にどんな課題があるのか」を全体で確認するために利用

効果

• 課題の網羅性を確保：調査時に出た小さな指摘も含めて一覧化することで、後から見落としがなくなります。
• 施策の検討を効率化：課題エリアにマークを付けておくと、改善施策を検討する際にグルーピングが容易になります。
• 他フォーマットとの連携が可能：主要課題を「ファンクショナリティ・マトリクス」や「システム構成図」にマッピングすることで、問題箇所を可視化し、関係者間で共通認識を作りやすくなります。

参考例

3. 棚卸し結果を元に、システムを分析する

ここまでで作成した棚卸し資料は、単なる整理で終わりではありません。
次のステップは、それらを材料に「分析」することです。

つまり、

• 「結局のところ、何がシステムのガンなのか？」
• 「次のシステムを作るときに、二度と繰り返してはいけないことは何か？」
  を明確にする作業です。

3.1.よくある分析結果の例

実際に多くのシステムで指摘される典型的な課題を挙げます。

• 機能連携不足
  同じ情報を複数のシステムに二重・三重に入力している。
• 場当たり的な機能追加
  必要な機能をその場しのぎで継ぎ足した結果、プログラムが複雑化。
• 設計資料の欠如
  改修時にプログラム解析から始める必要があり、些細な修正でも時間とコストが膨らむ。
• コード体系の不統一
  販売システムと経理システムで取引先コードが別々のため、データを統合できない。
• セキュリティの脆弱性
  古い仕組みのまま運用しており、データ漏洩のリスクを抱えている。
• 老朽化したテクノロジー
  メーカーサポート切れや性能不足により、業務量の増加に耐えられない。

3.2.なぜ分析が大事なのか

現行システムは、最初から悪かったとは限りません。

• 初期はスマートでも、改修を重ねるうちに複雑怪奇になったケースもあります。
• 前回のシステム構築で生まれた問題を、そのまま何年も引きずっているケースもあります。

いずれにせよ、「現行システムのガン」を特定することが、次のシステムで同じ失敗を繰り返さないための第一歩です。

これは医療で病巣を残さず手術するのと同じで、問題の所在を正しく見極めることが大切です。

4.おわりに

現状調査は、後続の要件定義や設計を支える土台です。

課題発見型ではメリハリ、棚卸し型では網羅性が鍵となります。

フォーマットを活用し、効率よく情報を整理することで、プロジェクトの手戻りを防ぎ、次のステップを安心して進められるでしょう。

おわりっ！