要件定義のカギは「業務を分解する」こと

要件定義で悩む発注者の多くは、「何を決めればいいかわからない」という状態にあります。その突破口になるのが「業務の分解」です。難しい言葉は使わず、業務を整理するための実践的な考え方を紹介します。

なぜ「業務を分解する」のか

「在庫管理システムが欲しい」という一言は、要件定義の出発点にはなりますが、それだけでは開発を進めることができません。

「在庫管理」という言葉の中には、入荷・出荷・棚卸・発注アラートなど、さまざまな業務が含まれています。それぞれの業務で誰が何をするのか、どんな情報を使うのか、どんなルールがあるのかを分解して明らかにすることで、初めてシステムに必要な機能が見えてきます。

業務を分解せずに「なんとなく」で要件定義を進めると、後から「この業務が抜けていた」「この流れは考えていなかった」が続出します。

分解の3つの軸

業務を整理するときは、以下の3つの軸で考えると整理しやすくなります。

1. 流れ（業務フロー）

業務が最初から最後までどのような順番で進むかを整理します。

「受注したらどうなる？」「承認が必要なのはどのタイミング？」「例外が起きたときはどこに連絡が行く？」といった問いを立てながら、業務の流れを図や箇条書きで書き出してみます。

ここで重要なのは「現状の流れ」と「理想の流れ」を分けて考えることです。現状の非効率をそのままシステム化しても改善になりません。一方で理想だけを追いすぎると現場が使えないシステムになります。「現状はこうだが、システム導入後はこう変えたい」という形で整理できると理想的です。

2. データ（扱う情報）

業務の中でどんな情報を使っているかを整理します。

「顧客の情報」「商品の情報」「受注の記録」——こうした情報のかたまりを特定し、それぞれに何が含まれているか（顧客なら：名前・住所・担当者・取引履歴など）を書き出します。

また、「この情報とこの情報はどうつながっているか」を意識することも重要です。「受注は顧客に紐づく」「受注明細は商品に紐づく」といった関係性を整理することで、データベースの設計方針が自然に見えてきます。ここは技術者がやることと思われがちですが、業務の実態を知っているのは発注者自身なので、「どの情報とどの情報がセットで動くか」は発注者側で整理できます。

3. 役割と権限

誰がどの業務をやり、誰がどのデータにアクセスできるかを整理します。

「この画面は誰が見ていい？」「この操作は承認者だけができる？」「部門をまたいだ場合はどうなる？」といった問いを立てることで、権限設計の基礎ができます。

ここを曖昧にしたまま開発を進めると、リリース後に「この人が見てはいけないものが見えている」「承認をスキップできてしまう」といった問題が出てきます。

実際にどう整理するか

専門的なツールを使う必要はありません。最初はExcelや紙でも十分です。

業務フローの整理：箱と矢印で「誰が何をしてどこへ渡す」を書いていきます。例外のパターンも書き出せると理想的です。

データの整理：「このシステムで管理するもの」の一覧を作り、それぞれに含まれる情報項目を書き出します。

役割と権限の整理：「役職・部署」と「できる操作」を表にまとめます。

この3つが揃うと、ベンダーとの打ち合わせで話が格段にスムーズになります。ベンダーはこの情報を基に機能一覧を作り、コストやスケジュールを見積もることができます。

「業務の分解」で見えてくること

業務を分解する過程で、次のことが浮かび上がってくることがあります。

属人化していたルール：ある担当者しか知らない処理方法が存在することに気づきます。ベテランが退職したときのリスクも見えてきます。

紙と口頭で動いていた部分：フローを書き出すと、意外なほど多くの情報が紙や口頭でやり取りされていることがわかります。ここがシステム化の対象候補です。

必要なかった手順：フローを整理すると、「この確認ステップは実は不要だった」という発見もあります。IT化のタイミングで業務を改善するチャンスでもあります。

まとめ

要件定義で「何を決めればいいかわからない」と感じたときは、「業務フロー」「データ」「役割と権限」の3つの軸で業務を分解することから始めてみてください。

難しい技術用語は必要ありません。「業務を知っている人が、業務の言葉で整理する」ことが、良い要件定義の出発点です。