業務システムの相談で、いきなり欲しい画面の話から始めると、見積もりがぶれやすくなります。先に必要なのは、誰が、いつ、何を見て判断し、次の人へ何を渡しているかを表した業務フロー図です。
静岡の中小企業や店舗では、電話、紙の伝票、表計算、口頭確認がうまくつながり、長年仕事が回っていることがあります。ところが、そのつなぎ役が特定の人だけだと、開発会社には見えません。私が初回の打ち合わせで一番時間をかけるのも、画面より、その見えない受け渡しの確認です。
清水の倉庫と駿河区の事務所、離れた動きを一本にする
業務フロー図は、きれいな資料でなくて構いません。紙に担当者ごとの列を引き、作業を左から右へ並べるだけでも、十分に会話の土台になります。たとえば清水区の倉庫で在庫を確認し、駿河区の事務所が受注を確定する会社なら、電話を受けた時点から出荷後の請求確認までを一本につなぎます。
一つの作業箱に書く内容
- 担当 営業、事務、店長、配送担当など、実際に手を動かす人
- きっかけ 電話受注、来店、締め時刻、承認依頼など、作業が始まる条件
- 使う情報 注文書、顧客台帳、在庫表、写真、過去の履歴
- 判断 在庫不足、値引き承認、重複登録など、流れが分かれる条件
- 次へ渡すもの 確定した数量、承認結果、帳票、連絡済みの記録
担当者名ではなく役割名で書くのがコツです。人が替わっても使える図になるうえ、「その人が休むと止まる工程」も見つけやすくなります。
通常の流れより、返品・訂正・急ぎ注文を書く
開発後に追加費用が出やすいのは、日常の主な流れではなく例外処理です。飲食店なら品切れ後の注文変更、製造業なら不良品の差し戻し、卸売業なら締め後の数量訂正。普段は口頭で吸収している作業ほど、図の脇へ書き出します。
- 普段どおり進んだ場合を一本描く
- 作業が戻る場面と、責任者の承認が要る場面に印を付ける
- 月末、繁忙日、担当者不在の日にだけ起きる処理を聞き取る
- 二重入力している箇所と、手書きで補っている項目を囲む
ここまで描けると、「入力画面が必要」という話が、「受注内容を一度入力すれば、在庫引当と出荷指示に同じ情報を使いたい」という要望に変わります。開発側も、必要な処理と対象外の作業を判断しやすくなります。
要件定義書には画面名より先に目的と範囲を書く
要件定義書は、専門家だけの文書ではありません。発注側と開発側が、何を作れば検収できるかを同じ言葉で確認する記録です。最初に「転記を減らす」「承認待ちを見えるようにする」など、改善したい状態を書きます。単に効率化と書くより、現場の判断に使えます。
相談前にそろえたい項目
- 対象にする業務と、今回は対象にしない業務
- 利用者の役割、利用場所、端末、同時に使う人数の目安
- 入力項目、検索条件、必要な帳票、保存したい履歴
- 閲覧、登録、承認、削除を誰に認めるかという権限
- 既存データの形式、件数の目安、移行後に照合する方法
- 他のシステムとの連携方法と、連携できないときの手順
- 応答の速さ、バックアップ、障害時の連絡、利用できる時間帯
- 納品後の修正窓口、操作説明、保守に含む範囲
顧客名や実データを最初から丸ごと渡す必要はありません。初期相談では、個人を特定できない見本や項目名だけでも整理できます。実データが必要になる時期と受け渡し方法は、秘密保持や権限と一緒に決めます。
見積もりを比べるなら、優先順位と検収条件をそろえる
同じ依頼文でも、会社ごとに「含む範囲」の解釈は違います。安いか高いかを見る前に、初期設定、データ移行、操作説明、公開後の修正、毎月の保守がそれぞれ見積もりに含まれるかをそろえてください。
機能は初回に必須、運用を見て追加、今回は対象外に分けると、予算判断がしやすくなります。検収条件も具体的にします。「検索できる」だけでなく、「担当者が顧客名と受付日で検索し、対象の履歴を開ける」と書く形です。
打ち合わせ前の整理時間は、一般的に小規模な業務なら担当者数名で一回あたり三十分から一時間程度を何度か確保するのが目安です。一度で決め切ろうとせず、現場で図を見直す時間を挟むほうが、後から出る認識違いを減らせます。
図が手書きの段階でも、相談は始められます
NIR株式会社では、静岡の現場で今使っている紙や表計算を見ながら、業務フローと要件の整理からお手伝いしています。まだ発注を決めていない段階でも、どこまで準備すれば見積もりを比べられるかを確認できます。必要な範囲が見えないときは、システム導入・開発を無料で相談するから、困っている作業を一つだけお聞かせください。現場の言葉を図に直すところから始めます。