システム化の相談で何を伝える？部署ごとの要望を最初の対象業務にまとめる

営業・倉庫・経理の要望を、同じ仕事の流れへ戻す

営業は「変更をすぐ通知したい」、倉庫は「今日の出荷予定を一覧で見たい」、経理は「注文内容の転記を減らしたい」。会議で機能の希望を集めても、どこから着手するか決まらないことがあります。まず、直近で止まった仕事を一つ選びます。

ここでは、受注後に納品予定が変わる場面を架空の例として考えます。営業の注文表と倉庫の出荷表に違う日付が残り、経理はどちらが確定か問い合わせています。相談の入口は、三つの機能を一度に作ることより、「変更の確定と受け渡し」を誰が行うかです。

• 整理した後に、最初の実装範囲を決める進め方 →

「連携できていない」という見立てを、確認できた事実と分ける

たとえば注文番号O-031の納品予定が23日から26日へ変わったとします。営業の表は26日、倉庫の表は23日。この二つの記録を確認できたなら、日付の不一致は事実です。ただし、原因が転記忘れなのか、承認待ちなのか、連携の遅れなのかは、まだ分かりません。日付・番号は説明用の架空例です。

事実は「どの記録を、いつ、誰が確認したか」と一緒に伝えます。原因の見立てには「仮説」、調べていないことには「未確認」と添えてください。不明な件数を0件としたり、未確認を処理済みと扱ったりしません。

• 記録の確認日と、確認した役割を付けたか
• 例外的な変更か、繰り返す仕事かを区別したか
• 調べていない原因・件数を、確定値にしていないか

最初は「予定変更の確定と受け渡し」に絞って話す

この例で最初に相談する範囲は、注文番号に変更前後の日付を結び付け、確認担当が確定し、倉庫が受け取ったか追えることです。注文の登録、在庫計算、請求の自動作成まで含めるかは別に判断します。

対象を狭めても、前後の業務を見なくてよいわけではありません。変更が請求へ影響する条件や、既に出荷した注文の扱いは確認します。経営・調達側には、どの待ちや照会を先に解消したいか、他の仕事を後回しにする理由を説明できる形にします。

• 対象が整理できたら、各社へ同じ見積条件を伝える →

既存の運用・設定・連携・開発を、同じ条件で比べる

同じ注文番号が使えるなら、まず共有場所や変更担当をそろえる運用を検討できます。今のソフトに変更履歴や通知の設定があれば、その機能で足りるかを確認します。部署間で別のソフトを使う場合は、CSVやAPIで渡せる項目・更新の間隔・失敗時の確認方法を調べます。

履歴や権限、例外処理が既存機能では足りない場合に、追加開発を比較します。APIがあることだけで安全に連携できるとは限りません。契約上の利用条件、仕様、同じ注文を識別する方法、訂正・再送の扱いも判断材料です。

• 運用でそろえる：担当と確定場所を決める。別の表を更新する手間が残るか確認する。
• 既存設定を使う：履歴・承認・通知の機能を確認。契約プランや権限で利用できる範囲を調べる。
• 連携する：同じ注文番号で変更を渡す。失敗・重複・訂正を担当者が追えるか確認する。
• 追加開発する：不足する記録・確認画面を作る。運用・変更・保守を誰が担うか先に合意する。

• 既存システムを残す・段階移行する・全面刷新する条件を見る →

社内で決めることと、開発会社へ任せる調査を分ける

業務責任者は、何を確定と呼ぶか、例外時に誰が判断するか、最初の対象と優先順位を決めます。現場担当は実際の記録と、困った場面を説明します。情報システム担当は既存ソフト・権限・契約・接続条件を確認します。すべての担当が初回に同席できなければ、未確認事項ごとに回答する役割と期限を置きます。

開発会社には、現行の流れの整理、設定・連携の可否調査、改善案の比較、合意した範囲の設計・実装を相談できます。調査や整理をどこまで依頼するか、成果物と費用を先に合意してください。相談しただけで全調査が無償になるとは限りません。

費用を左右するのは、触るソフトと部署の数、記録のばらつき、連携の仕様、訂正や権限の複雑さ、過去データの移行、業務を止められる時間です。費用や納期の確約より、どの条件が確認済みで、どの調査が残るかをそろえます。

• 課題の相談から設計・開発・導入までの進め方 →

移行中の仕事と、完成を確かめる場面も短く添える

新しい記録を試している間、旧表と新しい仕組みのどちらで予定を確定するかを決めます。並行して動かす期間には、同じ注文番号で差を照合する人、差を直す場所、切替を戻す条件が必要です。業務上の原本を二つにしないよう、確定場所を明示します。

完成は画面が開くことだけでは判断できません。通常の予定変更に加え、同じ注文の再訂正、承認待ち、出荷済みの変更、連携失敗、担当交代を使って、受付から確認・訂正・受け渡しまで業務で使えるかを確かめます。承認待ちのものが確定扱いにならないことも確認します。

導入後に項目や承認ルールが変わったら、誰が影響を調べ、どの記録を更新し、誰へ連絡するか。保守の対象、変更依頼の手順、双方の役割を合意に含めます。

• 旧表から切り替える日と、確定場所を決めたか
• 訂正・未確認・連携失敗を、通常処理と分けて確かめられるか
• 完成を確認する担当と、判定に使う業務例があるか
• 変更・障害時の連絡先と、保守の対象が共有されているか

初回相談では、最初の仕事・調査範囲・次に決めることをそろえる

要望が全部まとまるまで待つ必要はありません。「どの仕事で止まったか」「どこまで確認したか」「何が未確認か」を、業務の言葉で伝えてください。機密情報をそのまま送る必要はなく、取引先名を伏せた説明や架空の注文例でも、最初の論点は共有できます。

SHINJIDAIは課題の相談を受け、解決策の提案から設計・開発・導入まで伴走しています。この例なら、納品予定が変わったときの記録と役割を確認し、既存設定を使う案・連携する案・不足部分を作る案を比較します。合意した範囲を実装し、変更の確定・受け渡し・訂正が業務で回るか確かめます。

相談で次に決めたいのは、最初に扱う業務、残す仕組み、必要な調査と双方の作業、完成の確認方法です。詳細な仕様・費用・納期が未確定なら、その前提を残して次の調査へ進みます。

業務の課題整理から、設計・開発・導入まで

部署の要望を、最初に相談する仕事へ
SHINJIDAIにご相談ください。

• ?機能の希望がばらばらで、何から始めるか決まらない
• ?今のソフトを残す範囲と、未確認事項を整理したい
• ?調査を任せる範囲と、完成を確かめる条件を決めたい

課題の整理から伴走

直近で止まった仕事と記録、関係する担当を確認します。残す仕組みと未確認事項を分け、既存設定・連携・追加開発の比較案を提案。対象と双方の作業を合意して実装し、変更の確認・受け渡し・訂正が業務で回るか確かめます。

最初の対象業務を相談する→

初回は、困っている業務と現在の状況の概要で構いません。調査・設計・開発の範囲と費用は、着手前に合意します。

ID・パスワードや顧客データは、フォームに記載しないでください。

相談から実装までの進め方を見る →

• 業務整理から移行・保守まで、発注の判断材料をまとめて見る →
• SHINJIDAIの会社情報を確認する →

出典

IPA『ユーザのための要件定義ガイド 第2版』の紹介・目次では、業務部門の主体的な関与、ビジネス要求の把握・分析、運用・移行・総合テストの要求を扱っています。本記事の相談前の整理例・図・比較条件はSHINJIDAI独自作成で、同資料の図表の転載ではありません。資料紹介・目次を2026年10月14日に確認しました。

• IPA：ユーザのための要件定義ガイド 第2版（2019年9月12日公開） →
• IPA：第2版の書籍概要・目次（第7章の運用・移行・総合テストを含む） →