システム開発会社へ相談したものの、

「まだ発注するには情報が足りない」

「概算は出たが、本当にこの内容で進めてよいか判断できない」

「現行システムのことが分からず、正確な見積もりが出せない」

という状態になることがあります。

この場合、無理に本開発まで進める必要はありません。

相談後に必要なのは、発注するかどうかをすぐ決めることではなく、次に何を確認すれば判断できる状態になるのかを決めることです。

代表的な進め方は、次の3つです。

  1. 現行システムを調べる
  2. 要件を整理する
  3. 小さく試作して確かめる

まずは、自社がどの状態に近いか確認してみましょう。

今困っていること 先に行うこと
現在のシステムの中身が分からない 現行調査
何を作るか決まっていない 要件整理
作ってみないと判断できない 試作・PoC

この記事では、それぞれがどのような状況に向いているのかを分かりやすく解説します。

相談後にすぐ発注できないのは珍しくない

相談後の不明点に応じて現行調査・要件整理・試作を選ぶイメージ

初回相談では、現在分かっている情報をもとに、実現方法や概算費用を確認します。

しかし、実際には次のような未確認事項が残ることがあります。

  • 現行システムの仕様が分からない
  • どのデータを移すか決まっていない
  • 部門ごとに要望が違う
  • 本当に必要な機能が整理できていない
  • 外部サービスとの連携可否が分からない
  • 新しい操作方法を現場が受け入れられるか不安
  • 技術的に実現できるか確信が持てない

この状態で開発全体を契約すると、開発開始後に追加調査や仕様変更が必要になる可能性があります。

そのため、本開発の前に、

  • 現行調査
  • 要件整理
  • 試作・PoC

だけを先に行い、不明点を減らしてから判断する方法があります。

進め方1：現行システムを調べる

現在使っているシステムの中身が十分に分からない場合は、まず現行調査を行います。

現行調査が向いているケース

次のような場合です。

  • 古いシステムで仕様書が残っていない
  • 開発した会社と連絡が取れない
  • 担当者しか分からない処理が多い
  • どのシステムと連携しているか整理できていない
  • 改修と作り直しのどちらがよいか判断できない

調べる主な内容

  • 現在の画面・機能
  • データベースの構成
  • 外部システムとの連携
  • 使用している技術
  • 帳票やバッチ処理
  • 権限や承認ルール
  • 障害や改修の履歴
  • 使用している製品や技術のサポート期限

調査後は、「残せる部分」「改修が必要な部分」「置き換えた方がよい部分」を整理します。

現行調査を先に行うメリット

開発前に現状が見えるため、見積もりの前提をそろえやすくなります。

たとえば「データ移行は簡単そう」と考えていたものが、実際には複数のシステムへデータが分散していることもあります。

発注前にその事実が分かれば、移行に必要な作業や費用を見積もりへ反映しやすくなります。

進め方2：要件を整理する

課題や制約を整理して開発の対象範囲を決めるイメージ

現行システムのことはある程度分かっているものの、

「何を新しくしたいのか」

「どこまで作るのか」

が曖昧な場合は、要件整理を先に行います。

要件整理が向いているケース

  • 部門ごとに希望が違う
  • 作りたい機能が増え続けている
  • 必須機能と便利機能を分けられていない
  • 現在の業務自体を見直したい
  • 複数社から比較しやすい見積もりを取りたい

最初に整理したい内容

  • 解決したい業務課題
  • 対象にする部門
  • 利用する人
  • 必須機能
  • 後回しにできる機能
  • 既存システムとの連携
  • データ移行
  • セキュリティ
  • 希望する利用開始時期
  • 発注側で判断する担当者

重要なのは、すべてを細かい仕様まで決めることではありません。

今回の開発で何を解決し、どこまでを対象にするかを決めることです。

ここでいう「要件整理」は、本格的な要件定義の前に、何を解決したいのか、どこまでを開発対象にするのかを整理する段階を指します。

画面項目や細かな処理方法まで決める本格的な要件定義とは、少し役割が異なります。

進め方3：小さく試作して確かめる

要件を文章だけで決めにくい場合は、小さな試作を作って確認する方法があります。

一般に、画面や操作方法を確認するためのプロトタイプや、技術的に実現できるかを確かめるPoCなどがあります。

簡単に分けると、

  • 画面や操作を確かめたい → プロトタイプ
  • 技術的に実現できるか確かめたい → PoC

と考えると分かりやすくなります。

試作が向いているケース

  • 新しい業務で完成形を想像しにくい
  • 操作性が重要
  • 新しい技術を使う予定
  • 外部サービスとの連携可否を確かめたい
  • 本格開発前に現場の反応を見たい

試作で確認すること

たとえば、

  • 実際に操作しやすいか
  • 業務の流れに合っているか
  • 必要なデータを取得できるか
  • 外部サービスと接続できるか
  • 想定した速度で動くか

などです。

ただし、試作は完成版ではありません。

試作したものをそのまま本番利用できるとは限らないため、何を確認するための試作なのかを事前に決めることが重要です。

現行調査・要件整理・試作の違い

現行調査・要件整理・試作の目的と確認する内容を比較するイメージ

3つは似ていますが、目的が異なります。

進め方 主な目的 向いている状態 終わった後に分かること
現行調査 今のシステムを理解する 現行仕様が分からない 残す・直す・置き換える範囲
要件整理 作る範囲を決める 要望がまとまっていない 必須機能、対象範囲、見積もり条件
試作・PoC 実際に確かめる 文章だけでは判断できない 操作性、実現性、現場の反応

どれが一番よいというものではありません。

判断するときは、

「今、何が分からないから発注できないのか」

を考えます。

迷ったら「今、一番大きな不確定要素は何か」を確認する

次の質問を使うと整理しやすくなります。

今のシステムが分からない

→ 現行調査

現在の仕様やデータ、連携先が分からないままでは、正確な開発範囲を決めにくいためです。

何を作るか決まっていない

→ 要件整理

要望を集めるだけでなく、優先順位と対象範囲を決めます。

作ってみないと判断できない

→ 試作・PoC

画面、操作方法、技術的な実現性などを小さく確認します。

この3つは、どれか1つだけを選ぶ必要はありません。

たとえば、

現行調査 → 要件整理 → 必要な部分だけ試作 → 本開発

という順番で進めることもあります。

本開発の前に「調査・整理・試作」だけを依頼する方法もある

相談したからといって、すぐに本開発全体を契約する必要はありません。

たとえば、

  • 現行調査だけを依頼する
  • 要件整理だけを依頼する
  • 試作・PoCだけを依頼する

という進め方もあります。

この方法のメリットは、本開発の前に不確定要素を減らせることです。

たとえば、現行調査を行った結果、

「一部改修で十分だった」

「想定以上にデータ移行が複雑だった」

「作り直した方がよいことが分かった」

という判断につながることもあります。

一方で、調査や試作を別で行えば、その分の期間や費用は必要です。

そのため、すべての案件で工程を分ければよいわけではありません。

すでに要件が明確で、現行仕様も十分に分かっている場合は、そのまま本開発へ進むケースもあります。

調査や試作を依頼するときに確認したいこと

本開発前の依頼でも、単に「調査してください」と依頼するのではなく、終了時に何が分かるのかを確認しておくことが重要です。

現行調査なら

  • 調査対象
  • 調査できなかった範囲
  • システム構成
  • 現在の課題
  • 今後の選択肢

要件整理なら

  • 対象業務
  • 必須要件
  • 対象外
  • 未確定事項
  • 見積もりの前提

試作・PoCなら

  • 確認する内容
  • 作る範囲
  • 本番では使わない部分
  • 成功・失敗の判断基準

「何を作業するか」だけでなく、

終了時に、次の判断ができる状態になっているか

を確認することが重要です。

相談後にすぐ発注しない方がよいケース

次のような状態なら、もう一段階確認してから本開発へ進む方がよい場合があります。

  • 現行システムの仕様がほとんど分からない
  • 開発会社ごとに見積もりの前提が大きく違う
  • 部門間で必要な機能について合意できていない
  • データ移行の対象が決まっていない
  • 技術的な実現性に不明点がある
  • 現場が新しい業務をイメージできていない

一方で、必要な情報がそろっているなら、無理に調査工程を増やす必要はありません。

大切なのは、確認のための作業を増やすことではなく、不明点を残したまま大きな発注をしないことです。

まとめ

システム開発会社へ相談した後、すぐに発注できない場合は、

  1. 現行システムを調べる
  2. 要件を整理する
  3. 小さく試作して確かめる

という選択肢があります。

判断基準はシンプルです。

  • 今のシステムが分からない → 現行調査
  • 作るものが決まっていない → 要件整理
  • 作ってみないと判断できない → 試作・PoC

相談したからといって、そのまま本開発を発注する必要はありません。

次に何を確認すれば判断できるのかを整理し、不確定要素を減らしてから本開発へ進むことが重要です。

システム開発を初めて発注する場合の全体的な流れはこちらです。

システム開発の発注は何から始める？初めてでも迷わない11ステップと準備するもの

要件定義について詳しく知りたい場合はこちらです。

要件定義を頑張るほど、プロジェクトが遅れる理由

システム開発をご検討の方は、ニチコマへご相談ください。

お問い合わせ

参考にした外部情報