システム開発を依頼する前の準備と流れ｜新規事業編

この記事では、システム開発を依頼する前に何を準備し、依頼後はどんな順番で進むのかを、新規事業の場面を想定して整理します。相談前にまとめておきたい6つのこと、依頼から運用までの一般的な流れ、つまずきやすい点と避け方が分かります。仕様書が完成していなくても相談はできますが、「何を確かめたいのか」が言葉になっているほど、話は早く進みます。

依頼の前に押さえたい前提

システム開発の依頼というと、「詳細な仕様書を用意してから連絡するもの」と考えがちです。しかし新規事業では、仕様が固まっていない段階こそ相談が必要になる場面が多くあります。事業の仮説そのものが、作りながら変わっていくことが珍しくないためです。

一方で、開発会社に任せきりにできないこともあります。それは「事業として何を実現したいのか」を決めることです。設計や実装は専門家と一緒に進められますが、事業の目的や判断の基準は、依頼する私たちの側が持っておく必要があります。

そのため、依頼前の準備のゴールは仕様書を完成させることではありません。相談相手と同じ前提で考えられるように、材料をそろえておくことです。仕様が固まっていない段階での相談は、仕様が決まってないシステム開発の相談は可能かでも詳しく整理しています。

相談の前に整理したい6つのこと

準備といっても、長い資料は要りません。次の6点を、箇条書きのメモ程度でまとめておくと、最初の相談が具体的になります。

1. 事業の目的と、確かめたい仮説

「なぜこの事業に取り組むのか」「誰のどんな困りごとを解決するのか」「何が確認できれば次に進めるのか」を言葉にします。たとえば「この仕組みで、利用者が継続して使ってくれるかを確かめたい」といった形です。

確かめたい仮説が決まっていると、最初に作る範囲を絞りやすくなります。何でも盛り込むと、範囲が広がり、判断も遅れがちです。

2. 利用者と利用場面

システムを使うのは誰で、どんな場面で、どんな端末から使うのかを書き出します。利用者が社外のお客様か、社内の担当者かによって、画面のつくりや必要な機能は大きく変わります。

詳細な画面設計は不要です。「忙しい現場の担当者が、移動中にスマートフォンで確認する」といった一文があるだけでも、相談相手は、使う人の様子を具体的に想像できます。

3. システムが事業の中で担う役割

システムが事業の本体になるのか、事業の一部を支える位置づけなのかを整理します。利用者に提供するサービスそのものがシステムである場合は、システムの設計がそのままビジネスモデルの設計になります。この考え方については、関連する新規事業のシステム設計とビジネスモデルの作り方の記事で解説しています。

役割が曖昧なまま相談すると、「どこまで作るか」が決まらず、進みにくくなります。

4. 決める人と、判断に必要な材料

誰が最終的に決裁するのか、その人は何があれば判断できるのかを確認します。新規事業では、企画書だけでは可能性が伝わりにくく、決裁が止まることがあります。理由は新規事業の決裁を企画書だけで取るのが難しい理由にまとめました。

稟議の前に動くものを見せたいのか、それとも稟議が通ってから動かすのか。この違いによって、開発会社に求める進め方も変わります。

5. 時期と社内の関係者

いつまでに何を判断したいのか、社内で関わる人は誰かを整理します。「次の経営会議までに実物を見せたい」「半期の計画に間に合わせたい」といった具体的な時期の目安があると、そこから逆算して進め方を考えられます。

関係者が多い場合は、意見の調整役を誰が担うのかも、事前に決めておくと安心です。

6. 過去の経験と、気になっている不安

過去にシステム開発を外注して、うまくいかなかった経験や困った点があれば、その具体的な内容も共有します。「完成したものが想定と違った」「途中で費用や仕様の話が噛み合わなくなった」など、具体的であるほど、同じ失敗を避ける工夫を一緒に考えられます。

不安を先に伝えることは、弱みではありません。依頼の進め方を決める大切な材料です。

準備メモの例

6点を1枚にまとめるなら、次の形で十分です。

• 目的と仮説：どんな利用者の、どんな課題を解決し、何が確認できれば次に進むのか
• 利用者と場面：誰が、いつ、どこで、何を使って利用するのか
• システムの役割：事業本体か、支える一部か
• 決裁の流れ：誰が、どのタイミングで、何を見て判断するのか
• 時期と関係者：いつまでに判断したいのか、社内で関わるのは誰か
• 過去の経験と不安：以前うまくいかなかった点、今回気になっている点

空欄があっても構いません。「ここが決まっていない」と分かることが、相談の出発点です。

システム開発依頼の一般的な流れ

次に、依頼から運用までの一般的な流れを見ていきます。開発会社によって細部は異なりますが、おおむね次の段階を踏みます。

1. 相談とヒアリング

最初は、困っていることや実現したいことを伝える段階です。ここで準備メモが役立ちます。開発会社の側も、事業の背景や制約を聞き取りながら、進め方の方向性を探ります。

この段階で、相手が事業目的に関心を持ち、質問してくれるかは、開発会社を見極める材料になります。選ぶ視点はシステム開発会社の選び方で整理しています。

2. 要件の整理

何を作るのかを、機能や条件として具体的にしていく段階です。「要件定義」とも呼ばれ、後の工程の土台です。抜け漏れや食い違いがあると、後半で手戻りが生じやすくなります。

ポイントは要件定義とは？新規事業で抜け漏れとズレを防ぐ進め方で解説しています。

3. 見積もりと契約

要件がある程度まとまった段階で、開発会社から見積もりと契約の提案があります。契約の形は、大きく2つの種類に分けられます。

• 請負契約：開発会社が、発注側と決めた成果物を完成させることを約束する契約
• 準委任契約：決めた作業を行う約束の契約

どちらが向くかは、要件がどれだけ固まっているかによって変わります。契約形態の違いや、選ぶときの考え方は受託開発とは？依頼の流れ・契約形態・新規事業の選び方で詳しく扱っています。

新規事業では、仕様が途中で変わる前提で、変更の対応を契約前に確認するのが大切です。

4. 設計・開発

画面や仕組みを設計し、プログラムを作る段階です。途中経過を見せてもらえるのか、確認の機会がどのくらいあるのかは、事前に聞きたい点です。完成まで見えない進め方だと、最後に「想定と違う」と気づくリスクが高まります。

5. テストと受け入れ確認

作られたものが、決めた条件どおりに動くかを確認する段階です。開発会社が行うテストに加えて、依頼側が実際の利用場面を想定して触ってみる確認も欠かせません。

誰が、どの基準で「問題なし」と判断するのかを、決めておくと、受け入れで迷いません。

6. 公開と運用

公開後は、不具合の修正や、利用状況に応じた機能の追加が必要になります。新規事業では、公開してから分かることが多いため、納品後の対応範囲も依頼前に確認しておきたいです。

流れ全体と失敗の防ぎ方は、システム開発の外注ガイドにもまとめています。

依頼でつまずきやすい点と避け方

準備と流れを押さえても、依頼の場面では特有のつまずきが起きます。従来の進め方で起きやすい事故と、その防ぎ方を整理します。

言葉だけで要件を決めて、認識がずれる

文章や口頭だけで要件を決めると、同じ言葉でも頭に描いている姿が人によって違うことがあります。「管理画面」「検索機能」といった言葉は、とくに解釈の幅が広い表現です。

防ぐには、画面のイメージや動くものを見ながら「ここはこう」と指摘できる場をつくることです。実物を見ると、言葉では出てこなかった違和感に気づけます。詳しくはシステム開発の認識のズレを防ぐ、実物を見ながらのすり合わせで扱っています。

要件の抜け漏れや食い違いに、後から気づく

要件を机上で固めても、実際に使ってみて初めて分かる「これじゃない」は避けられません。問題は、それに気づく時期が遅いことです。開発が終盤に差しかかってからの修正は、手間も時間も、やり直しの負担も大きくなります。

早い段階で触れるものを用意し、違和感を早く見つけて直す進め方が、手戻りを抑えます。

費用と仕様を先に固めて、後から困る

新規事業では、仮説が固まりきっていない状態で、費用と仕様を先に決めてしまうことがあります。その後に市場の反応や社内の判断が変わると、決めた内容が合わなくなりかねません。

仕様と費用を決める前に、実物で確認できる機会の有無は、依頼先選びの大事な視点です。

経営陣と現場で、判断の材料が違う

目的は同じでも、経営陣は判断材料を求め、現場は早く動きたいという状況は珍しくありません。ズレは目的ではなく、進め方にあることが多いです。背景は新規事業で経営陣と現場がすれ違う原因は進め方のズレで整理しています。

依頼の前に、決裁者が何を見れば判断できるのかを現場と共有しておくと、開発が始まってからのすれ違いを減らせます。

動くものを先に確認する進め方

ここまでの注意点には、共通する考え方があります。言葉や書類だけで決めきらず、動くものを見ながら確かめるという進め方です。

企画書だけでは伝わりにくいこと

企画書は考えを整理する役には立ちますが、「実際に何ができるのか」「触ったときにどう感じるのか」までは伝えにくいものです。動くプロトタイプ（試作品）があれば、決裁者も現場も同じ画面を見ながら話せます。プロトタイプとMVP、モックアップの違いはプロトタイプとMVP・モックの違いを整理で解説しています。

稟議の場面でも、実物があれば説明の説得力が変わります。使い方は稟議を通すシステム開発｜プロトタイプの使い方で紹介しています。

事業性を、予算をかける前に確かめる

新規事業では、大きな予算をかける前に「この事業はうまくいきそうか」を確かめたい場面が多くあります。動くシステムで利用者の反応を見れば、机上の議論より確かな材料が得られます。具体的な手順は新規事業のアイデア検証方法にまとめています。

AIの活用で、試作の進め方も変わりつつある

近年は、AIを活用した開発が広がり、試作の進め方も変わってきています。AIが設計や実装の一部を担い、人が「何を作るか」と品質の判断を担うという役割分担が、考え方の基本になりつつあります。仕組みや発注側の要点はAI駆動開発とは｜AIと人の役割分担と発注側の要点で解説しています。あわせてご覧ください。

ただし、AIが作ったものを人が確認することは欠かせません。理由はAI開発でも品質には人の確認が必要な理由で詳しく述べています。

最初の相談で聞いておきたいこと

依頼先と最初に話すときは、こちらから伝えるだけでなく、相手に不明点や不安を質問することも大切です。次の観点を押さえておくと、依頼後のギャップを減らせます。

• 仕様が固まっていない段階でも相談できるか、その場合どう進めるのか
• 実物や途中経過を、依頼する側が、いつ、どんな形で確認できるのか
• 契約や費用の判断は、いつ頃行うのか
• 要件が変わったとき、どう対応するのか
• 完成後の不具合対応や機能追加は、どこまで任せられるのか
• 作ったシステムの権利は誰のものになるのか、データの扱いはどうなるのか

回答の内容だけでなく、質問に対して具体的に答えてくれるか、こちらの事業への理解を示してくれるかも見ておきたい点です。

まとめ

システム開発を依頼する前の準備と流れを整理しました。要点は次のとおりです。

• 依頼前の準備は、仕様書の完成ではなく、相談相手と同じ前提で考えるための材料を、依頼する側がそろえること
• 事業の目的と仮説、利用者と場面、システムの役割、決裁の流れ、時期と関係者、過去の経験と不安の6点をメモにしておく
• 依頼は、相談から始まり、要件の整理、見積もりと契約、開発、テストと受け入れ、公開と運用の順に進むのが一般的な流れ
• つまずきの多くは、言葉だけで決めることと、実物を見るのが遅いことから生まれる
• 動くものを先に確認できる進め方なら、認識のズレや手戻りを早い段階で減らせる

新規事業のシステム開発は、最初から正解が決まっているわけではありません。だからこそ、準備を整えたうえで、確かめながら進められる依頼先と進め方を選ぶことが大切です。

JustFit（株式会社LEGAREAが運営する完全オーダーメイドの受託開発サービス）は、「先に作って、後から決める」という考え方で、構想をもとに約1ヶ月で動くプロトタイプを先に開発し、実物を見てから契約を判断できる進め方をとっています。仕様が固まっていない段階や、稟議を通す前の段階でも相談できますので、詳しくはJustFitのサービス紹介をご覧ください。