「このシステムを作ってほしい」と社内で話が出たとき、担当者が最初に悩むのは、どこまで情報を揃えてから開発会社に相談すればよいかという点です。たとえば、受注管理をExcelで行っている部署から「入力ミスが多いのでシステム化したい」という相談が来たとします。この時点で開発会社に連絡しても、具体的な見積もりや提案はまず返ってきません。開発会社が知りたいのは、今誰が、どの画面やファイルを使い、どんな順番で作業しているかという業務の流れだからです。
相談前にこの流れを整理しておくと、要件定義にかかる時間が短くなり、後からの仕様変更も減らせます。逆に、整理が不十分なまま進めると、開発後半で「実はこの作業も必要だった」という手戻りが起きやすくなります。
業務の流れを洗い出す範囲を決める
最初に迷うのが、どこからどこまでを整理すべきかという範囲です。システム化したい作業の前後にある手作業も含めて書き出す必要があります。たとえば受注入力を自動化したい場合でも、その前段階の「注文メールを確認する作業」や、後段階の「在庫担当への連絡」まで含めて流れを把握しておくと、開発会社は接続すべき業務の境界を判断しやすくなります。
この作業の前工程と後工程で、誰が何を確認していますか。
この質問を自分たちに投げかけることで、担当者の頭の中にしかない手順が見えてきます。口頭での引き継ぎや、担当者の経験に頼った判断が含まれている場合は、それも書き出しておくと、開発会社が仕様に落とし込む際の材料になります。
開発が必要な条件と、既存サービスや運用改善で足りる条件
業務の流れを整理すると、実は開発をしなくても解決できる場合があることに気づくこともあります。判断の目安は次の通りです。
既存のクラウドサービスや市販ソフトで足りる条件は、業務の手順が他社と大きく変わらない場合です。請求書発行や勤怠管理など、多くの企業で共通する業務であれば、すでにあるサービスの設定変更や運用ルールの見直しで対応できることがあります。まずは既存サービスでカバーできないかを確認してから、開発を検討する順番が無駄を減らします。
一方、受託開発を検討すべき条件は、自社独自の判断基準や承認フローが業務に組み込まれている場合です。たとえば、取引先ごとに異なる割引率や納期の計算ルールがあり、それを担当者の経験で都度判断しているような業務は、既存サービスでは吸収しきれないことが多く、個別の開発が検討対象になります。
情報を揃える単位は「画面」ではなく「作業」
整理をするとき、つい「どんな画面が欲しいか」から考えてしまいがちですが、これは開発会社との会話を遠回りにします。先に整理すべきは、画面ではなく作業の単位です。たとえば「入力する」「確認する」「承認する」「連絡する」という作業ごとに、誰が担当し、どのくらいの頻度で発生し、どんな情報を参照しているかを書き出します。
この整理ができていると、開発会社は「この作業は自動化できる」「この確認は人が残すべき」といった判断をしやすくなります。逆に画面イメージだけを持ち込むと、見た目の話が先行し、業務の課題がどこにあるのか後から確認し直すことになり、要件定義の期間が延びる原因になります。
例外処理や頻度の低い作業も記録しておく
通常の流れだけでなく、月に数回しか発生しない例外的な作業も記録しておくことが大切です。想定例として、通常は自動で処理できる注文でも、特定の取引先だけ手動確認が必要になるケースなどがあります。このような例外は、開発の初期段階で伝えておかないと、後になって追加の仕様変更として扱われ、スケジュールや費用に影響することがあります。
すべての例外を事前に洗い出すのは難しいため、よくある例外と、まれにしか起きない例外を分けて伝えておくと、開発会社側も優先順位をつけて設計しやすくなります。
相談前に確認しておきたいチェックリスト
- 対象業務の作業を、担当者・頻度・使用する資料ごとに書き出したか
- 前工程と後工程まで含めて流れを確認したか
- 既存のクラウドサービスや運用改善で足りないか、一度検討したか
- 担当者の経験や口頭での判断に頼っている部分を言語化したか
- 月に数回程度しか発生しない例外的な作業も記録したか
- 業務の課題を「画面が欲しい」ではなく「作業の困りごと」として言葉にしたか
- 関係部署の担当者にも流れの認識を確認したか
業務の流れを整理する作業は、開発会社に依頼する前の準備であると同時に、自社の業務を見直す機会にもなります。整理の途中で、開発以外の方法で解決できる部分が見つかることも珍しくありません。まずは今の業務をどこまで言葉にできるか、手を動かして確認してみてください。