実際の業務プロセスからソフトウェアへ：何から始める？
「受注管理システムが必要」「社内業務をデジタル化したい」といった要望だけでは、システムの動作や実装範囲を具体化するための情報が十分とは限りません。現在の業務、関係者、情報の流れを整理することで、要件をさらに確認するための材料が増えます。
実際の業務プロセスを、利用者の流れ、データ、具体的なルールへ落とし込むことで、ソフトウェアが何をすべきか、どこまでを優先するか、開発前に何を確認すべきかが明確になります。
1. 実際の業務プロセスから始める
「管理システムが必要」という言葉から始めるのではなく、日々の業務で実際に起きている場面から考えます。誰が、いつ、何をしているのか。どの情報が必要で、どの部分で時間がかかったり、管理しにくくなったりしているのかを整理します。
例えば受注処理であれば、営業担当者が注文を受け、在庫を確認し、顧客へ回答し、倉庫へ依頼を送り、配送状況を確認するという流れで表現できます。
こうして具体的な行動の流れを示すことで、抽象的な要望ではなく、実際の業務として捉えられるようになります。そこから、「どこが手作業なのか」「何を表示する必要があるのか」「各段階で誰が操作するのか」といった次の質問も明確になります。
2. 業務フローと利用者の役割を明確にする
ソフトウェアの有用性は、実際のニーズや業務フローをどの程度支援できるかにも左右されます。そのため、機能一覧を作る前に、業務フローと各ステップに関わる役割を整理します。
受注処理の例では、営業、倉庫、経理、管理者が同じシステムを使うとしても、必要な情報は異なります。営業は在庫と注文状況を確認し、倉庫は準備すべき注文を把握し、管理者は全体の進捗や例外を確認します。
役割を明確に分けることで、すべての人に同じ情報を詰め込んだ画面を作ることを避けられます。各利用者が、自分の業務に直接必要な情報と操作だけを扱える設計につなげやすくなります。
3. 業務プロセスを機能へ変える
業務フローを整理すると、それぞれのステップから必要な機能を検討するための材料が得られます。業務上のアイデアを、設計・実装に必要な要件へ具体化する際の一つの基礎になります。
例えば「注文を確定する前に在庫を確認する」というステップからは、商品ごとの利用可能数を表示する、取引後に在庫を更新する、在庫不足時に警告するといった機能が考えられます。
「注文を倉庫へ渡す」というステップからは、ステータス変更、担当者の割り当て、更新日時の記録、関係部署への通知といった機能につながる場合があります。
重要なのは、それぞれの機能が具体的な業務ステップや利用者のニーズと結びついていることです。「誰が、いつ使うのか」を説明できない機能は、初回範囲には不要かもしれません。
4. データと業務ルールを明確にする
機能はシステムの目に見える部分にすぎません。正しく動作させるためには、どのデータを保存するのか、そしてどのルールに基づいて処理するのかも明確にする必要があります。
例えば注文には、顧客情報、商品、数量、担当者、支払状況、配送状況などが必要になるかもしれません。それぞれについて、誰が閲覧できるか、誰が編集できるか、いつ更新されるかを決めます。
さらに、業務ルールも整理します。在庫が不足していても注文を確定できるのか。誰が注文をキャンセルできるのか。どのタイミングで通知するのか。どのケースで管理者の承認が必要なのか。
こうした内容はシステムのロジックを大きく左右します。事前に合意されていないと、開発側が推測で判断したり、開発中に何度も修正したりする原因になります。
5. 初回リリースの範囲を決める
業務プロセスを詳しく整理すると、システムに入れたい要望が多く見つかることがあります。しかし、すべてを初回リリースに含める必要はありません。
現実的なのは、主要な業務を成立させるために必須の機能と、後から追加できる機能を分けることです。受注管理システムであれば、注文登録、在庫確認、ステータス更新、進捗確認は初期機能になり得ます。一方、高度なレポートや細かなカスタマイズは後のフェーズでも構いません。
初回範囲が明確になるほど、期間、コスト、テストの見積もりもしやすくなります。また、より早い段階で実際に利用し、新しい業務プロセスが本当に合っているかを確認できます。
6. 開発前に何を準備すべきか？
技術チームへの相談や開発開始前に必要な仕様の粒度は、プロジェクトの種類、進め方、制約によって異なります。設計や開発へ進む際は、対象スコープに大きく影響する情報を適切な粒度まで明確にし、重要な仮定を確認できる状態にする必要があります。
一般的に確認が必要になる項目には、利用者、主要な業務プロセス、重要なデータ、守るべき業務ルール、対象スコープで解決したい内容などがあります。
これらが共有できれば、開発チームはより具体的な要件分析、画面設計、データ構造の検討、スコープの見積もりへ進みやすくなります。
Fenixでは、初期段階で業務の背景を、技術チームが扱える形へ整理することを重視しています。顧客側ですべての詳細を用意していただくのではなく、開発前に必要な情報を一緒に明確にしていきます。
7. まとめ
業務プロセスをソフトウェアへ変えるときは、アイデアからすぐに機能一覧へ進むのではなく、まず利用シーン、利用者、業務フロー、データ、業務ルールを整理する必要があります。
これらを整理することで、必要な機能や初回リリースの範囲を検討するための基礎ができます。また、各機能を利用者や業務上の目的と結び付けて確認しやすくなります。
