「見積書の作成に時間がかかっている」「複数の部署でExcel管理していて情報がずれる」。こうした課題を感じたとき、受託開発の相談を検討する担当者は多いはずです。しかし、業務の流れを整理しないまま相談すると、要件定義の段階で話が行き来し、開発会社側も何を作るべきか判断しづらくなります。結果として、見積もりの精度が下がったり、開発後に「思っていたものと違う」という手戻りが発生したりします。
受託開発の相談前に業務フローを整理しておくことは、開発期間の短縮や手戻りの削減につながります。この記事では、相談前にどこまで整理しておくべきか、判断基準とともに解説します。
業務の流れを「工程」で分解する
まず取り組みたいのは、対象業務を工程ごとに分解することです。たとえば「受注管理」という業務であれば、「問い合わせ受付」「見積作成」「承認」「受注登録」「発注」といった工程に分けられます。想定例として、この分解を怠ると「受注管理システムを作ってほしい」という漠然とした依頼になり、開発会社は工程ごとの担当者や判断基準を一からヒアリングする必要が出てきます。
工程を分解する際は、次の質問を自分たちに投げかけると整理しやすくなります。
この業務は、誰が、何を見て、何を判断し、次に何をしているか？
この問いに沿って業務を書き出すと、担当者ごとの作業範囲や、判断が入るポイントが見えてきます。判断が入るポイントは、システム化する際にルール化が必要な箇所であり、要件定義で重点的に詰めるべき部分です。
「例外処理」を洗い出す
業務フローには、通常の流れとは別に例外的な対応が存在します。たとえば「特定の取引先だけ承認フローが異なる」「月末だけ処理順序が変わる」といったケースです。この例外処理を洗い出さずに開発を進めると、稼働直前や運用後に「この場合はどうするのか」という指摘が相次ぎ、追加開発や手戻りの原因になります。
例外処理を洗い出す際は、以下のような確認が有効です。
この業務で、月に一度でも「いつもと違う対応」をしたことはあるか？
頻度が低くても、業務上重要な例外であれば、開発会社に事前に伝えておくべき情報です。逆に、発生頻度が極めて低く、人が手動で対応しても支障がない例外であれば、システム化の対象から外すという判断も選択肢になります。
開発が必要な場合と、既存サービス・運用改善で足りる場合
業務フローを整理していく中で、そもそも受託開発が必要かどうかを見極めることも重要です。すべての業務課題が開発で解決すべきものとは限りません。
受託開発を検討したほうがよい条件は、次のようなケースです。
- 業務フローが自社独自であり、既存のパッケージやSaaSでは工程の一部しかカバーできない
- 複数の社内システムやExcelファイルをまたいだ情報連携が必要で、手作業の転記が発生している
- 業務量や利用人数が多く、ルールを変えるより仕組みを変えるほうが影響範囲が広い
一方で、既存サービスの導入や運用改善で足りるケースもあります。
- 市販のSaaSやクラウドサービスが、対象業務の工程をほぼそのままカバーできる
- 業務量が少なく、テンプレートやチェックリストの整備、担当者間のルール統一で解決できる
- 例外処理の発生頻度が低く、都度人が対応しても業務全体への影響が小さい
この見極めを相談前に行っておくと、開発会社との打ち合わせでも「開発すべき部分」と「運用でカバーする部分」の切り分けがスムーズになります。開発会社に相談する段階で、すべてを開発で解決しようとする必要はありません。
業務フローの整理を資料にしておく
整理した業務フローは、簡単な図や箇条書きでよいので資料化しておくことをおすすめします。工程、担当者、使用しているツール、例外処理を一枚にまとめておくだけで、開発会社との初回打ち合わせの質が変わります。専門的なフローチャートのツールを使う必要はなく、手書きのメモやExcelの表でも構いません。
資料化の際に意識したいのは、「現状の流れ」と「理想の流れ」を分けて書くことです。現状の流れは今困っている部分を洗い出すために、理想の流れは開発によって実現したい姿を伝えるために使います。この二つを混同すると、開発会社が「現状の課題を解決したいのか、新しい仕組みを作りたいのか」を判断しにくくなります。
相談前に確認しておきたいチェックリスト
- 対象業務の工程を、担当者ごとに書き出したか
- 各工程で「誰が何を判断しているか」を明確にしたか
- 月に一度以下の頻度でも発生する例外対応を洗い出したか
- 現状の業務フローと、開発後に実現したい理想のフローを分けて整理したか
- 既存のSaaSやパッケージで代替できる工程がないか確認したか
- 業務量や利用人数など、開発の必要性を判断する材料を数字で把握したか
- 整理した内容を一枚の資料やメモにまとめたか
業務フローの整理は、開発会社に依頼する前の準備であると同時に、自社の業務課題を客観的に見直す機会にもなります。整理を進める中で「実は開発しなくても解決できる」と気づくケースもあります。まずは現状の業務を書き出すところから始めてみてください。