スクラッチ開発を選ぶ―でも範囲はどこまで？

「どうせ作るなら」が始まった

カスタム開発が決まったと社内に伝えた翌日、営業部長から声がかかった。

「田中さん、ちょっといい？見積書システム、発注受付機能も一緒に作れない？」

発注受付。つまり、顧客が見積書を確認してOKを出したら、そのままシステム上で発注を受け付け、受注データとして登録する機能だ。

翌日は経理部からも連絡が来た。

「請求書の発行も一緒にできるようにしてもらえたら、うちも助かるんですけど」

発注受付も請求書も、一緒に作った方が効率よくない？どうせシステム作るんだし。

気持ちはすごくわかる！でも、一度に作るものが増えるほどリスクも比例して増えるんだよね。

まず1つのことをちゃんと完成させる、これがシステム開発の鉄則だよ。

関係者を集めて、「今回作るものの範囲」を決める会議を設けた。

最初は全員が「できれば全部欲しい」という顔をしていたが、開発会社に初期打診したところ、機能追加のたびに費用と期間の試算が跳ね上がることが数字で見えてきた。

10ヶ月後まで現場がExcelで頑張るのか、という話になったとき、空気が変わった。

「じゃあまず見積書だけでいきましょうか」

営業部長も経理部も、あっさり引いてくれたわね。費用と期間を数字で見せたのがよかったのかしら？

そう、数字で示すのが一番効くんだよ。「リスクがある」「複雑になる」だけでは伝わりにくいけど、「10ヶ月かかる」「400万円追加になる」は誰でも理解できるよね。

意思決定者に判断してもらうときは、「感情的な理由」より「具体的なコストと期間」を示してみて。これはシステム開発だけじゃなく、社内調整全般で使えるテクニックだよ。

発注受付と請求書発行は「フェーズ2」として、今回のシステムが安定稼働してから改めて検討することになった。

フェーズ2って、ちゃんと作ってもらえるの？「後で」って言ったままになりそうで……

正直、そのリスクはゼロじゃないね。でも、フェーズ分けをうまくやるコツがあるよ。

今回は「フェーズ2として先送り」を議事録に明記して、関係者全員にメールで確認を取ったんだ。これで「言った・言わない」が防げるよ。

スコープが決まったら、「何を作るか」を文書にまとめ始めた。この作業が要件定義の第一歩だ。

今回の開発スコープ（フェーズ1）

フェーズ2として先送り

このリストをまとめたら、すぐ開発会社に連絡していいの？

まだちょっと早いよ！このリストは「大項目」でしかないんだよね。開発会社に相談するためには「要件定義」として、もう少し細かく詰める必要があるんだ。

たとえば「見積書の作成」一つとっても……

……など、決めることがたくさんあるから。次回は「要件定義」の進め方を見ていこう！