小規模なシステム開発を依頼できる？断られにくい相談のしかた
小規模なシステム開発も、依頼すること自体はできます。ただ、相談の伝え方によっては、話が進みにくくなる場合があります。この記事では、小規模な開発が断られやすい背景と、断られにくい相談のしかたを整理します。
新規事業では、最初から大きなシステムを作るより、小さく作って確かめたい場面が多くあります。そのため、小規模な依頼は特別なものではありません。相談前に何を整理しておくとよいかを、順に見ていきます。
小規模なシステム開発は依頼できるのか
結論から言うと、小規模なシステム開発を依頼することはできます。実際に、新規事業の最初の一歩として、必要な機能だけに絞って作りたいという相談は少なくありません。
ただし、どの開発会社でも同じように受けられるわけではありません。規模が小さいほど向く会社と向かない会社の差が出やすく、この点は知っておいたほうがよいところです。
「小規模」に決まった定義はない
「小規模」という言葉は、人によって指すものが違います。
- 画面が数枚で、機能が1つか2つに絞られたもの
- 事業の仮説を確かめるための、試験的なシステム
- 既存のサービスに、1つだけ機能を足すもの
- 利用者が限られた、社内向けのもの
依頼する側が「小さい」と感じていても、開発会社から見ると、認証・データの持ち方・管理画面など、決めることが多いこともあります。逆に、依頼側が「大きな話」と思っていても、整理すれば小さく始められることもあります。
相談では「小規模です」とだけ伝えるより、何をどこまで作りたいのかを具体的に伝えるほうが、話が早く進みます。
規模より「判断の材料」が見えるかどうか
断られるかどうかは、規模の大小そのものより、判断に必要な材料が見えるかどうかで決まることが多いと、私たちは考えています。目的、範囲、決める人、時期。これらが見えれば、小さな案件でも受けられるかどうかを判断しやすくなります。
小規模な依頼が断られやすくなる4つの背景
断られる理由を開発会社の側から見ておくと、相談のしかたを整える手がかりになります。ここでは一般的に起こりやすい事情を挙げます。個々の会社の方針は異なるため、あくまで目安です。
1. 目的が見えず、何をもって完成とするか決められない
「システムが欲しい」という相談だけでは、何を作れば役に立つのかが分かりません。完成の基準が曖昧なまま始めると、途中で「思っていたものと違う」となりやすくなります。この認識違いは、小さな開発でも起こります。
実物を見ながらすり合わせて防ぐ考え方については、システム開発の認識のズレを防ぐ、実物を見ながらのすり合わせで詳しく書いています。
2. 決める人が見えず、話が前に進まない
相談の窓口の人と、最終的に決める人が別だと、確認のたびに社内で持ち帰りが発生します。小規模な案件ほど、確認の往復が増えると進行が重くなります。誰がどこまで決められるのかが分かっていると、開発会社も進め方を組み立てやすくなります。発注側の役割は発注側のプロダクトオーナーとは｜役割と判断のしかたで整理しています。
3. 「最初は小さく」のはずが、後から範囲が広がりそう
最初は小さいと聞いていたのに、打ち合わせのたびに要望が増えていく。この展開を、開発会社は警戒します。範囲が変わること自体は自然なことです。ただ、変わったときにどう扱うかが決まっていないと、双方が困ります。この点は、システム開発の仕様変更への対応｜追加要望の扱い方でも触れています。
4. 作ったあとの運用が想定されていない
小さなシステムでも、公開したあとに不具合の修正、改善、利用者からの問い合わせ対応は発生します。作って終わりと考えていると、「誰が面倒を見るのか」が決まらないまま納品を迎え、双方に負担が残ります。納品後の考え方はシステムは納品後の改善で育てる｜新規事業の考え方が参考になります。
断られにくい相談のしかた：伝えておきたい5つのこと
ここからが本題です。相談の際に次の5点を整理して伝えると、小規模な依頼でも話が進みやすくなります。完璧に固まっている必要はありません。「ここまでは決まっていて、ここは未定」と分けて伝えることが大切です。
1. 何のために作るのか、何を確かめたいのか
機能の一覧より先に、目的を伝えます。たとえば次のような形です。
- 新しいサービスに、顧客が本当に申し込むかを確かめたい
- 稟議に出す前に、動く形で関係者に見せたい
- 事業の一部をシステム化して、運用できるか試したい
目的がはっきりすると、開発会社は「本当に必要な機能」と「後回しにできる機能」を分けて提案できます。機能の絞り方はMVP開発の機能の絞り方｜最初に作るものと後回しの基準にまとめています。
2. 最初に動かしたい範囲
小規模な開発の相談では、「全部」ではなく「最初に動かす範囲」を言葉にしておくことが重要です。
- 誰が使うか（利用者の種類）
- その人が最初にする操作は何か
- 最低限、見せたい画面や流れは何か
管理画面のように、範囲を広げようと思えばいくらでも広げられる部分については、新規事業の管理画面開発｜最初に作る範囲の見極め方を参考にしてください。最初は最小限にとどめる判断がしやすくなります。
3. 決める人と、確認にかかる時間
誰が最終判断をするのか、確認に何日くらいかかりそうかを伝えておきます。これは相手への配慮でもあります。確認が早いほうが進行も早くなるため、開発会社にとって受けやすい案件になります。
社内で稟議が必要な場合は、そのことも先に伝えておくほうが安全です。稟議の前の段階で相談できる開発会社もあります。稟議とプロトタイプの関係は稟議を通すシステム開発｜プロトタイプの使い方で書いています。
4. 決まっていないことは、決まっていないと伝える
仕様がすべて固まっている必要はありません。むしろ、固まっていないことを隠したまま話を進めるほうが、後で問題になりやすくなります。次のように分けて伝えるだけでも、相手は状況を把握できます。
- 決まっていること：目的、想定する利用者、使いたい場面
- 迷っていること：機能の優先順位、画面の細部、データの持ち方
- まだ考えていないこと：運用体制、拡張の方向
仕様が未確定の段階での相談については、仕様が決まってないシステム開発の相談は可能かで詳しく扱っています。
5. 今回の位置づけ：検証用か、そのまま使うものか
作るものが「事業を確かめるための試作」なのか、「そのまま顧客に使ってもらう本番」なのかで、必要な品質や進め方は変わります。この違いを先に伝えておくと、認識のズレを防げます。
試作と本番の関係は、MVPから本開発は作り直し？引き継げる部分と見直す点で整理しています。プロトタイプやMVPなどの用語が曖昧な場合は、プロトタイプとモックアップ・MVPの違い｜新規事業の使い分けを見ておくと、相談時の言葉を揃えやすくなります。
相談メモの例
5つを、A4の1枚程度にまとめておくと便利です。長い資料は必要ありません。
- 目的：（例）新しい予約サービスの需要を確かめたい
- 最初に動かしたい範囲：（例）利用者が予約を入れるまでの流れ
- 決める人：（例）事業部長。確認は1週間以内に可能
- 未定のこと：（例）決済の方法、管理画面の機能
- 位置づけ：（例）まず関係者と数十人の利用者に見せる試作
この程度でも、開発会社は「受けられるか」「どこから確認すべきか」を判断できます。
小規模でも先に確認しておきたいこと
規模が小さくても、確認しておいたほうがよい点は大きな開発と変わりません。相談の段階から次の点を意識しておくと、後からの行き違いを減らせます。
見積もりの前提と範囲
見積もりは、数字そのものよりも、何を前提に、どこまでを含んでいるのかが大切です。前提が違えば、同じ「小規模」でも内容は大きく異なります。見積もりの読み方はシステム開発の見積もりの違い｜金額より先に見る前提と範囲にまとめています。
秘密保持と、成果物の権利
新規事業のアイデアを伝えるときは、秘密保持の取り決めが気になります。また、作ったプログラムの権利が誰に帰属するのかも、契約前に確認したい点です。
小規模な案件ほど、契約書を簡単に済ませてしまいがちです。しかし、規模が小さくても事業の中核になるシステムであれば、こうした確認は欠かせません。
納品時の確認方法
何をもって「できあがり」とするのかも、小さな開発でこそ決めておきたい点です。納品時にどの項目を確認するのかは、システム開発の検収とは｜納品時の確認項目と進め方が参考になります。
開発会社の選び方
小規模な相談を受けてもらえるかどうかは、開発会社の得意分野によっても変わります。新規事業向けの開発に慣れた会社か、小さな案件でも対応する姿勢があるかは、相談の際の受け答えからも見えてきます。選ぶ視点はシステム開発会社の選び方｜新規事業で失敗しない7つの視点で整理しています。外注全体の流れはシステム開発の外注ガイド｜依頼の流れと失敗の防ぎ方も合わせてご覧ください。
小さく始めるために、動くものを先に見るという進め方
小規模な開発では、「作る前にすべてを決める」進め方が合わないことがあります。決めるための材料が足りないのに、仕様書だけで判断しなければならなくなるからです。
そこで有効なのが、先に動くプロトタイプを作り、実物を見ながら判断する進め方です。文章や図だけでは伝わりにくい「何ができるのか」が、触ることで分かります。「ここはこう」「これは要らない」といった指摘もしやすくなり、要件の抜け漏れや食い違いを早い段階で見つけられます。
この進め方は、小規模な新規事業と相性がよいと考えています。理由は3つあります。
- 事業の仮説を、本格的な開発の前に確かめられる
- 関係者が同じ実物を見て話せるため、決裁者と現場の認識を揃えやすい
- 続けるかやめるかの判断材料が、早い時期に手に入る
プロトタイプを使った判断の流れは、新規事業の開発は小さく作って確かめる投資判断の進め方や、新規事業のアイデア検証方法｜動くシステムで確かめる手順で詳しく解説しています。やめる判断も含めて考えたい場合は、新規事業の撤退判断｜プロトタイプで「やめる」と決める基準が参考になります。
社内にエンジニアがいない場合
小規模な依頼を考える会社には、社内にエンジニアがいないところも多くあります。その場合でも、相談自体は可能です。ただ、発注側で決めるべきことは残ります。何を作るか、何を確かめたいかを決める役割は、外部には任せきれません。進め方は新規事業でエンジニアいない会社の進め方｜システム開発や内製と外注どちらがいい？新規事業システムの判断軸で整理しています。
過去に外注で失敗した経験がある場合
以前の外注で思うような結果にならず、小さな依頼でも慎重になる会社もあります。その場合は、何が起きたのかを相談時に率直に伝えると、同じことを避けやすくなります。見直す点はシステム開発の外注で失敗後のやり直し｜再依頼の見直し点にまとめています。
相談前によくある疑問
予算が限られていても相談してよいか
相談自体はできます。予算に上限がある場合は、その旨を最初に伝えたほうが、範囲を絞った提案を受けやすくなります。上限があることは、断られる理由ではなく、範囲を決める条件として扱われるのが一般的です。
一部の機能だけを頼んでもよいか
一部だけの依頼も、相談の対象になります。ただし、既存のシステムとの関係や、将来つなげたい機能があるかどうかは伝えておくと、後の手戻りを減らせます。既存の仕組みと分けて作る考え方は、新規事業は既存システムと切り離して作る理由と進め方で説明しています。
相談前に、どこまで準備すればよいか
資料の完成度は高くなくても構いません。相談前の整理の仕方は、システム開発を依頼する前の準備と流れ｜新規事業編にまとめています。前述の5つのメモがあれば、まずは話を始められます。
まとめ
小規模なシステム開発も、依頼することはできます。断られやすくなる原因は、規模の小ささではなく、判断に必要な材料が見えないことにあります。
- 小規模の定義は人によって違うため、作りたい範囲を具体的に伝える
- 目的、最初に動かす範囲、決める人、未定のこと、今回の位置づけの5点を整理する
- 決まっていないことは、決まっていないと正直に伝える
- 見積もりの前提、秘密保持、権利、納品時の確認方法は、小さな案件でも先に確認する
- 動くプロトタイプを先に見て判断すると、小さく確かめながら進められる
JustFitは、構想をもとに約1ヶ月で動くプロトタイプを先に開発し、実物を見てから契約を判断できる受託開発サービスです。仕様が固まっていない段階や、稟議の前の段階でも相談でき、小規模な開発や独自のフローにも対応しています。詳しくはJustFitのサービス紹介をご覧ください。