仕様が決まってないシステム開発の相談は可能か
仕様が決まっていない段階でも、システム開発の相談はできます。この記事では、その理由と、仕様が曖昧なまま進めたときに起きやすい失敗、相談の前に整理しておくと話が進む項目、相談先を見るときのポイントを順に整理します。新規事業に取り組む私たちが、外注で遠回りしないための考え方として読んでいただければと思います。
仕様が決まっていなくても、開発の相談はできる
「仕様が決まっていないのに、開発会社に相談してよいのだろうか」と迷う声は少なくありません。仕様書がないと話を聞いてもらえないのではないか、準備不足だと思われるのではないか、といった心配です。
結論から言うと、相談してよい状態です。特に新規事業では、仕様が固まっていないのはむしろ自然なことです。顧客がどう反応するか、どの機能が本当に使われるかは、実際に形にして見せてみないと分からない部分が多いからです。仕様は、最初に完全に決めるものというより、検討を重ねながら見つけていくものだと捉えたほうが実態に合います。
そもそも「仕様」とは何か
仕様とは、作るシステムが「何をして、どう振る舞うか」を具体的に定めた内容のことです。一般的には、次のような項目が含まれます。
- 画面：どんな画面があり、何が表示され、どう操作するか
- 機能：登録、検索、承認、通知など、システムが行う処理
- データ：どんな情報をどの単位で持つか
- ルール：権限、承認の条件、例外時の扱いなどの業務上の決まり
- 連携：既存のシステムや外部サービスとのやり取り
- 非機能：想定する利用者数、表示の速さ、セキュリティなど、機能以外の要件
これらを最初からすべて決め切っている会社のほうが、新規事業ではまれです。決まっていない項目があること自体は、相談できない理由になりません。
「決まっていない」にもいくつかの状態がある
一口に「仕様が決まっていない」といっても、状態は一様ではありません。大きくは次の3つに分けられます。
- 事業の目的や課題はあるが、どんな機能が要るのかが浮かんでいない
- 機能の案はいくつかあるが、優先順位や範囲が決まっていない
- 社内の関係者の間で、作りたいものの理解が揃っていない
どの状態かによって、相談で話すべき内容は変わります。1なら課題や事業の仮説を一緒に整理するところから、2なら最初に作る範囲を絞るところから、3なら関係者が同じものを見て話せる材料を用意するところから始めるのが自然です。自分たちがどの状態にいるのかを大まかに言葉にできるだけでも、相談はかなり進めやすくなります。
相談の前に、決まっていなくてよいこと・あると進めやすいこと
仕様書がなくても相談はできますが、何も整理せずに臨むより、いくつかの材料があるほうが話は早く進みます。ここでは、決まっていなくてよいことと、あると進めやすいことを分けて整理します。
相談の時点で決まっていなくてよいこと
- 画面の細かい設計やデザイン
- 機能の網羅的な一覧
- 使う技術やプログラミング言語
- データベースの構造
- 細かな運用ルールや例外の扱い
これらは、相談を受けた開発側が質問しながら一緒に整理していく部分です。最初から決めておく必要はありません。
あると話が進みやすいこと
- 取り組む目的や、確かめたい事業の仮説（誰のどんな困りごとを解決したいのか）
- 想定している利用者（社内の誰が使うのか、顧客が使うのか）
- 今その課題を、どのような手段で解決しているか（手作業、既存サービス、他社の仕組みなど）
- 参考にしているサービスや、イメージに近い画面の例
- 判断のスケジュール（いつまでに何を決める必要があるか）
- 社内の関係者と、決裁の流れ
- 過去に外注で困った経験があれば、その内容
すべてを埋める必要はありません。「ここは分からない」と正直に伝えることも、立派な情報です。分からない箇所が分かっていれば、相談の場でそこから整理を始められます。
特に決裁の流れと判断のスケジュールは、見落とされがちですが重要です。何を、誰に、いつまでに示せば次に進めるのかが分かれば、開発側も「まず何を用意すべきか」を逆算して提案できます。
仕様が曖昧なまま進めると起きやすい失敗
ここまで「相談はできる」と書きましたが、相談することと、仕様が曖昧なまま発注・契約まで進めることは別の話です。外注で起きやすい失敗の多くは、曖昧なまま進めたことそのものより、「曖昧な部分を確かめる手段がないまま、決め切ってしまうこと」から生まれます。代表的なものを3つ挙げます。
言葉だけで要件を決めて、認識が食い違う
「管理画面を作る」「承認フローを入れる」といった言葉は、人によって思い浮かべる中身がかなり違います。文書や会話だけで合意したつもりでも、できあがったものを見て「思っていたものと違う」となる例は珍しくありません。認識の食い違いが起きる仕組みと対策は、システム開発の認識のズレを防ぐ、実物を見ながらのすり合わせで詳しく扱っています。
要件定義の抜け漏れ・食い違い
要件定義とは、作るシステムに必要な機能や条件を整理して文書にする工程です。ここでの抜け漏れは、後になってから発覚しやすいのが厄介な点です。実際に使ってみて初めて気づく「これではない」という違和感は、文書を読んでいるだけでは見つけにくいからです。進め方の考え方は要件定義とは？新規事業で抜け漏れとズレを防ぐ進め方にまとめています。
費用と仕様を先に固めてしまう
仕様がはっきりしないうちに、費用と作る範囲を先に確定させてしまうのも、失敗につながりやすい進め方です。新規事業は、検討を進める中で事業の仮説が変わることがあります。範囲を最初に固定していると、変更のたびに調整が必要になり、本当に確かめたかったことに手が届かなくなるおそれがあります。
ここで押さえておきたいのは、「仕様書がないこと」自体が問題なのではない、という点です。問題は、動くものを見て確かめる機会がないまま、言葉と文書だけで最後まで決め切ろうとすることにあります。仕様が決まっていない状態は、確かめながら決めていく進め方を選べば、むしろ柔軟に動ける状態だとも言えます。
仕様が固まっていないときの進め方
では、仕様が固まっていない段階では、どう進めるのがよいのでしょうか。ここでは、考え方を3つの手順に分けて整理します。
1. 目的と判断基準を先に言葉にする
機能の一覧より先に、「この取り組みで何を確かめたいのか」「何が確認できたら次に進むと判断するのか」を言葉にします。たとえば次のようなものです。
- 想定している利用者が、実際にこの仕組みを使ってくれるかを確かめたい
- 提供したい価値が、画面や操作の形で伝わるかを確かめたい
- 社内の決裁者に、事業の姿を具体的に見せたい
判断基準が決まっていれば、仕様が細かく決まっていなくても、必要な機能の優先順位をつけやすくなります。事業とシステムの関係を整理する考え方は、新規事業のシステム設計とビジネスモデルの作り方で取り上げています。
2. 動くプロトタイプで確かめる
プロトタイプとは、本番の完成品の前に作る、実際に動く試作品のことです。仕様が固まっていないときは、文書で議論を重ねるより、動くものを触りながら「ここはこう」と指摘し合うほうが、認識を揃えやすくなります。企画書だけでは伝わらない「何ができるのか」を、実物で示せるからです。
また、実物があると、経営陣と現場が同じものを見ながら話せます。新規事業では、目的は同じでも判断の材料と進む速度が違うために、話が噛み合わなくなることがあります。この点は新規事業で経営陣と現場がすれ違う原因は進め方のズレで、決裁の場面については新規事業の決裁を企画書だけで取るのが難しい理由で整理しています。
プロトタイプ開発の進め方と、どこまで作るかの判断については、MVP開発・プロトタイプ開発の進め方｜新規事業の判断法が参考になります。アイデアを動くシステムで確かめる手順は、新規事業のアイデア検証方法｜動くシステムで確かめる手順で扱っています。
3. 段階的に決めて、広げていく
最初から全機能の仕様を決め切ろうとせず、確かめたいことに必要な最小限の範囲から始め、反応を見ながら次に作るものを決めていきます。決めることを小さく区切れば、判断を誤ったときの影響も小さくて済みます。
AIを使った開発の広がりについて
近年は、AIを開発工程に取り入れる「AI駆動開発」が広がっています。試作を早く作れるようになる傾向があり、仕様が固まっていない段階でも、形にして確かめやすくなってきました。ただし、何を作るかを決めることや、できあがったものの品質を最終的に判断することは、引き続き人の役割です。AI駆動開発での役割分担と発注側の要点はAI駆動開発とは｜AIと人の役割分担と発注側の要点に、品質確認の考え方はAI開発でも品質には人の確認が必要な理由にまとめています。道具が進歩しても、「何を確かめたいのか」を言葉にする作業が大切なことは変わりません。
相談先を選ぶときに確認したいこと
仕様が決まっていない段階で相談するなら、相談先が「決まっていない状態」をどう受け止めてくれるかが重要になります。相談の場で確認しておきたい点を挙げます。
仕様書がない前提で話を聞いてくれるか
「仕様書をお持ちください」と求められる場合は、準備が整ってから改めて相談する形になります。仕様が固まっていない状態でも、目的や困りごとから聞いてくれるかどうかを確認します。
質問が、機能だけでなく事業や目的にも及ぶか
「どの機能を作りますか」だけを聞かれる場合、決まっていない部分は決まらないままになりがちです。誰のどんな課題を解決するのか、何を確かめたいのかまで一緒に考えてくれるかが、仕様が曖昧な段階では特に大切です。
契約の前に、実物や具体物で確認できる手段があるか
言葉や文書だけで決める進め方か、動くものを見て確かめられる進め方かを確認します。契約を判断する前に、何を見て判断できるのかが分かると安心です。
判断のタイミングが段階的になっているか
最初の段階で、どこまでを決め、どこからを後で決めるのかが明確かどうかを確認します。決まっていない部分を後で決められる余地が、進め方に組み込まれているかどうかがポイントです。
完成後の改善や追加の進め方が見えるか
新規事業のシステムは、作って終わりではなく、使われ方を見ながら育てていくものです。納品後に不具合修正や機能追加をどう進めるのかも、あらかじめ聞いておくと後で慌てずに済みます。
自社の規模や内容に合った相談ができるか
小規模な開発、独自の業務フロー、専門性の高い領域など、自分たちの内容に対応してもらえるかも確認しておきたい点です。開発会社ごとに得意な分野や規模は異なります。
外注全体の流れや失敗の防ぎ方はシステム開発の外注ガイド｜依頼の流れと失敗の防ぎ方に、受託開発の契約形態や選び方は受託開発とは？依頼の流れ・契約形態・新規事業の選び方にまとめています。あわせて参考にしてください。
まとめ
仕様が決まっていない段階でのシステム開発の相談について、要点を整理します。
- 仕様が決まっていない段階でも、相談はできる。特に新規事業では、仕様が固まっていないのは自然な状態
- 相談の前に、画面や機能の細部まで決めておく必要はない。目的、想定する利用者、判断のスケジュール、決裁の流れが分かると話が進めやすい
- 失敗の原因は、仕様書がないことよりも、確かめる手段がないまま言葉と文書だけで決め切ってしまうこと
- 仕様が固まらないうちは、目的と判断基準を言葉にし、動くプロトタイプで確かめながら段階的に決めていく進め方が向いている
- 相談先は、仕様書がない前提で話を聞いてくれるか、契約の前に実物で確認できるか、納品後の改善まで見えるかといった点で見る
仕様が決まっていないことは、相談をためらう理由ではなく、確かめながら進める余地が残っている状態です。まずは、何を確かめたいのかを言葉にするところから始めてみてはいかがでしょうか。
JustFitは、株式会社LEGAREAが運営する完全オーダーメイドの受託開発サービスです。「先に作って、後から決める」という考え方で、構想をもとに約1ヶ月で実際に動くプロトタイプを開発し、実物を見てから契約を判断できます。仕様が固まっていない段階や、稟議を通す前の段階でも相談できます。詳しくはJustFitのサービス紹介をご覧ください。