SYSTEM DEVELOPMENT GUIDE

要望を伝えたのに、違うものができる。

システム開発の認識齟齬を減らすには、機能一覧を増やす前に、仕事の「通常」「例外」「確認待ち」を書き分けます。非IT担当者でも使える、発注前の7行メモを紹介します。

通常在庫あり → 出荷日を回答

例外在庫不足・特注品

確認待ち価格・納期・承認

「画面」より先に、仕事の分かれ道を揃える。

発注前に揃えるもの

機能ではなく、仕事の分かれ道を共有します

「受注管理が欲しい」「検索しやすくしたい」だけでは、作る側は足りない部分を推測することになります。最初から立派な仕様書を作る必要はありません。

発注前に最低限書くこと

どこから仕事が始まり、普通ならどう終わるか。普通に進まないときは何が起き、誰の確認を待つか。どこまで進めば完了か。

特に漏れやすいのは、毎回ではない処理です。値引き、在庫不足、特注、承認、返信待ちなどを「そのとき考える」のままにすると、完成後もExcelやメールで補う作業が残りやすくなります。

10分で使える

社内の詳しい人に、この順番で聞いてください。全部を決められなくても、「未決定」と書けば、開発前に確認すべき場所が見えます。

そのまま使える記入欄

対象業務：
始まり：
通常：
例外：
確認待ち：
完了：
今回は扱わない：

メモやメールへ貼り付けて使えます。

記入例

架空の業務例です。完成したシステムや顧客事例ではありません。

曖昧な言葉は、担当者ごとに意味が変わります。「注文当日17時まで」など、判断できる条件にします。

決まっていない項目は「未決定」と書き、決める人と期限を置きます。空欄のまま作り始めないためです。

請求や返品まで広げず、まず受注から出荷日回答までに区切ります。完成条件を確認しやすくなります。

7行を書いたあと

次は、各項目を画面・入力・出力・テスト条件へ落としていきます。外注する場合も、社内で作る場合も、この順番は変わりません。

7行に書こうとしても条件や例外がまとまらない場合は、システムを選ぶ前に、業務担当者ごとの認識を揃える工程が必要です。

業務の条件・例外・確認待ちを整理します

製品名や解決方法が決まっていなくても相談できます。現場で使っている帳票や言葉から、作る範囲を一緒に確認します。