初めてソフトウェア受託を行う企業の多くは、「システムを作ってもらう」こと自体を全工程と考えがちです。成否を分けるのは、前段で業務が明確化されたか、後段で受入が定義されたかです。XYN は済南で製造・小売・官公庁向けにサービスを提供し、受託開発を四段階に分けます。現状把握、方案合意、マイルストーン納品、リリース後の安定化です。
まず区別する：ツールが必要か、プロセスを固定化したいか
Excel を Web 表に置き換えるだけなら、期間は短くリスクも低く、成熟した販売在庫や OA で足りることが多いです。承認ルール、複数倉庫、複数ロール、財務／ERP 照合が入ると、汎用ソフトは「少し足りない」状態になります。その差分こそ競争力や歴史的負債であり、受託で補うしかありません。
立項時に三つの文を書くことを推奨します。誰が毎日使うか、解決しないと何を失うか、リリース後に成功とみなす条件は何か。この三つは機能一覧よりスコープを抑えます。「倉庫責任者の日次棚卸時間を半日から一時間へ」は「倉庫システムを作る」より受入しやすいです。
要件調査は議事録ではなく、図に落とす
調査段階で最も避けるべきは、要望だけを集めることです。有効な調査は業務を一つの経路に落とします。誰が起票し、どのノードを通り、どの伝票が生まれ、どの表にデータが載り、例外時にどう戻すか。XYN は通常、着手前に三つを出力します。
- ロールと権限：誰が閲覧・編集・エクスポートのみできるか。
- 主フローと例外フロー：通常伝票、返品、取消、補伝票それぞれの経路。
- 外部システム連携一覧：財務、決済、配送、WeCom／DingTalk—マスターデータと同期方向を先に明示。
この三つがあれば、プロトタイプは「見た目の良い画面」ではなく開発可能な仕様になります。プロトタイプ段階で項目名が争点のままなら、調査は未完了—人日で開発者を積まないでください。
開発はマイルストーンで、「完成してから見せる」ではない
受託プロジェクトの遅延はスコープ蔓延が典型です。デモでレポート追加、リリース前に承認追加。契約はマイルストーン単位に切ることを推奨します。例：マスターデータと権限 → コア伝票のクローズドループ → レポートと連携 → 試運転。各段にデモ可能な成果があり、理解のズレを早期に発見できます。
技術面では、将来モジュール追加の余地が必要です。統一ユーザーセンター、統一承認フロー、統一通知。画面は段階投入できますが、基盤を最初からバラバラに作ると、後から改修が混沌化します。
リリースは終点ではない：データ移行、研修、保証
旧データが移行できなければ、新システムは空回りです。移行前に合意：履歴伝票をいつまで残すか、コード規則を作り直すか、残高データの正とする側はどちらか。旧システムと短期並行運用し、照合が通ってから主フローを切り替えます。
研修はロール別に。全員にバックエンドを一度見せるのではありません。倉庫、財務、経営層は同じメニューを見ません。保証期間中は欠陥を致命・重大・一般に分類し、対応 SLA を明記—「一年無償保守」より実行可能です。
立項前の最短チェックリスト
- 成功基準を「使いやすい」ではなく業務指標で述べられるか。
- 連携先が合意済みか—開発途中で項目が出ないか。
- スコープを決められる内部責任者がいるか—誰でも要件追加できないか。
- 受入にバックアップ復旧、権限抽查、クリティカルパス負荷試験が含まれるか—デモだけではないか。
受託開発に秘訣はありません。核心は不確実な業務を、段階的に検証可能な仕様に変えることです。XYN はコードより先に合意を重視します。企業システムを検討中なら、現行フローと課題を送ってください—製品購入、MVP、フル受託のどれが適切か先に判断します。