システム開発や業務アプリの発注を考えたとき、「まず仕様をきちんと決めてから、業者に頼もう」と考える経営者や担当者の方は多いと思います。発注先に対して失礼のないように、また見積もりを正確に取るためにも、一見すると正しい順番に思えます。
しかし実際には、「仕様が完全に決まってから発注する」というやり方が、かえって開発の失敗を招くケースが少なくありません。この記事では、その理由と、発注前にどこまで整理しておけばよいのかを、ITに詳しくない方にもわかる言葉で説明します。
「完璧な仕様」は最初から存在しない
業務システムの仕様は、実際に画面を触ったり、現場で運用してみたりして初めて見えてくるものです。たとえば「在庫を管理したい」という要望ひとつを取っても、「入庫と出庫だけ記録できればよいのか」「取引先ごとの単価も必要か」「月末に棚卸し表と照合したいのか」といった細部は、頭の中だけで網羅するのは困難です。
それにもかかわらず、発注前に「すべての機能、すべての画面、すべての例外処理」を文書にしようとすると、準備に何か月もかかってしまいます。その間に業務のやり方が変わったり、担当者が異動したりして、せっかく書いた仕様が古くなってしまうこともあります。
失敗につながる3つのパターン
仕様を完全に決めてから発注する進め方では、次のような問題が起きやすくなります。
1. 仕様書は立派でも、現場の困りごとが抜けている
机上で作った仕様書には、「なぜそれが必要なのか」という背景が書かれていないことがよくあります。結果として、機能は揃っているのに使いにくい、現場の担当者が結局Excelに戻ってしまう、といった事態が起こります。
2. 途中の変更が「追加費用」と「納期遅れ」を生む
開発が始まってから「やはりこの項目も必要だった」と気づくことは、ほぼ避けられません。すべてを先に決めた前提で契約していると、変更のたびに見積もりの取り直しや契約の見直しが必要になり、お互いに負担が増えます。
3. 発注側と受注側の認識がずれたまま進んでしまう
仕様書の文言は、読む人によって解釈が変わります。「承認機能」と書いてあっても、社長の承認が必要なのか、課長までで十分なのか、スマホからの承認が必要なのか。こうした違いを早い段階で確認しないまま開発が進むと、完成したものを見て初めて「想定と違う」となります。
発注前に決めておくべきことは「全部」ではない
では、何も決めずに発注すればよいのかというと、そうではありません。大切なのは、仕様の細部までを決めることではなく、次の点を言葉にしておくことです。
- 何のために作るのか：たとえば「月末の請求作業にかかる時間を半分にしたい」など、目的を一文で書けること
- 誰が使うのか：事務担当、現場スタッフ、経営者など、使う人を具体的に挙げること
- 今どうしているのか：Excelや紙、口頭でのやり取りなど、現状の流れを簡単に書き出すこと
- 優先順位：「これがないと困る」ものと「あると便利」なものを分けておくこと
- 予算と時期の目安：正確でなくても、上限や希望時期の感覚を伝えること
これらは専門知識がなくても整理できる内容です。仕様書というより、「相談するための材料」と考えるとよいでしょう。
「仕様を決める」より「一緒に固めていく」
理想的なのは、発注前に最低限の方向性を決めておき、開発の初期段階で小さく作って確かめながら仕様を固めていく進め方です。たとえば、最初は主要な機能だけを持つ簡単な版を作り、実際に数名で使ってもらいます。そこで出た意見を反映しながら、次の機能を追加していきます。
この方法であれば、途中で仕様が変わることは前提になるため、変更を歓迎しながらも費用と納期のコントロールがしやすくなります。発注先にとっても、現場の声が早い段階で届くため、手戻りが減ります。
ただし、「変わってもよい」という前提を契約や見積もりの段階で合意しておくことが大切です。何が変更に当たるのか、どの範囲までを初期版に含めるのかを、事前に話し合っておくと安心です。
発注先の選び方にも影響する
仕様を一緒に固めていく進め方に向いているかどうかは、発注先の姿勢にも左右されます。見積もりを出す段階で、業務の背景をよく聞いてくれるか、「わからないこと」を素直に質問してくれるか、完成形のイメージを図や実際の画面で見せてくれるか。こうした点は、仕様書の出来以上に重要な判断材料になります。
逆に、仕様書通りに作ることだけを強調し、現場の困りごとに関心を示さない相手の場合は、後で「言われた通りに作ったのに使えない」という結果になりやすいでしょう。
まとめ
「仕様が決まってから発注する」という考え方は、一見すると慎重で正しく見えます。しかし、業務システムは作りながら見えてくるものが多く、完璧な仕様を先に用意しようとすると、かえって時間と費用を失いがちです。
発注前に決めるべきは、目的・使う人・現状・優先順位・予算の目安といった、相談の材料になることです。そのうえで、開発を一緒に進めながら仕様を固めていく姿勢を持つことが、失敗を減らす近道になります。
過去の開発事例では、現場の日報を専用アプリに置き換えた現場向け日報・ナレッジ共有PWAの開発や、請求や見積もりの作業を自動化した金属買取業向け 見積書自動作成アプリの開発などがあります。どのように要望を整理し、段階的に形にしていったかの参考になるかもしれません。
「何から考えればよいかわからない」「発注の前に整理を手伝ってほしい」というお悩みがあれば、LINEでお気軽にご相談ください。
