システム開発・発注

開発プロジェクト開始前チェックリスト

公開日 2026.09.16更新日 2026.09.16

システム開発を依頼する前に整理しておきたいこと

「こんなシステムを作りたいです」

システム開発のご相談は、多くの場合ここから始まります。

もちろん、最初の段階ですべてが決まっている必要はありません。

むしろ、

まだアイデアしかない
業務上の課題は分かっているが、どうシステム化すればよいか分からない
必要な機能を整理できていない

という状態からご相談いただくことも珍しくありません。

ただし、ここで一つ重要なことがあります。

「何も決まっていない状態から一緒に整理する仕事」と、「決められたシステムを開発する仕事」は、同じ“システム開発”でもまったく別の仕事です。

たとえば、

予算は500万円です。
この中で要件整理から設計、開発、テスト、リリースまで全部お願いします。

というご相談をいただいたとしても、作るものが決まっていなければ、その500万円が十分なのか、不足しているのかすら判断できません。

また、

エンジニアを1人、月○○万円くらいで入れてほしい。

という場合にも、そのエンジニアに何を担当してもらうのか、誰が指示をするのか、誰が全体設計をするのかが決まっていなければ、適切な人材を選ぶことができません。

そこで今回は、システム開発会社へ相談する前に確認していただきたい項目を、「開発プロジェクト開始前チェックリスト」としてまとめました。

まず確認したいこと

次の項目について、どこまで整理できているでしょうか。

1. 何を解決するシステムなのか説明できますか？

[ ] 現在困っていることを説明できる
[ ] システム化する目的を説明できる
[ ] システム導入後にどうなっていたいか説明できる
[ ] 「なぜこのシステムが必要なのか」を社内で共有できている

たとえば、

顧客管理システムを作りたい

だけでは、まだ開発要件にはなっていません。

「営業担当者ごとにExcelで管理している顧客情報を一本化したい」

「問い合わせから受注までの状況を管理したい」

「営業担当者が退職しても情報が失われないようにしたい」

など、システムを作る理由が必要です。

目的が曖昧なまま開発を始めると、開発途中で、

「やっぱりこれも必要だった」

「思っていたものと違う」

ということが起きやすくなります。

2. 誰が使うのか決まっていますか？

[ ] 利用者が決まっている
[ ] 利用人数がおおよそ分かっている
[ ] 社内利用なのか、顧客向けなのか決まっている
[ ] PC、スマートフォン、タブレットなど利用環境が分かっている
[ ] 管理者と一般利用者など、利用者の種類を整理している

同じ「予約システム」でも、

社員10人が利用する社内システム
1万人の一般ユーザーが利用するWebサービス
全国200店舗で利用する業務システム

では、必要となる設計が大きく異なります。

3. 必要な機能は整理されていますか？

[ ] 必要な機能を一覧化している
[ ] 必須機能と「あれば便利な機能」を分けている
[ ] 画面のおおよそのイメージがある
[ ] 入力する情報が整理されている
[ ] 出力したい情報が整理されている
[ ] 必要な帳票やCSVなどが整理されている
[ ] メールや通知などの要件が整理されている

ここで重要なのは、「欲しいものを全部挙げること」ではなく、優先順位をつけることです。

たとえば、

優先度	内容
Must	なければ業務が成立しない
Should	できれば必要
Could	予算に余裕があれば欲しい
Future	将来的に追加したい

といった形で整理しておくだけでも、開発会社との会話はかなり進めやすくなります。

4. 現在の業務フローは整理されていますか？

業務システムの場合、ここは特に重要です。

[ ] 現在誰が何をしているか分かっている
[ ] 業務の開始から終了まで説明できる
[ ] Excel、紙、メールなど現在利用しているものが整理されている
[ ] 誰が承認するのか決まっている
[ ] 例外的な業務パターンを把握している
[ ] システム導入後の業務フローを検討している

「現在の業務が整理されていないので、システムで整理したい」

というご相談もあります。

それ自体は問題ありません。

ただし、その場合に必要なのは、いきなりプログラムを書くことではありません。

まず業務整理や要件整理から始める必要があります。

これも立派なプロジェクトの一工程です。

5. 要件定義は終わっていますか？

ここが大きな分岐点です。

次のようなものが整理されているでしょうか。

[ ] システムの目的
[ ] 対象業務
[ ] 利用者
[ ] 機能一覧
[ ] 画面一覧
[ ] 権限
[ ] データ項目
[ ] 外部システムとの連携
[ ] セキュリティ要件
[ ] 性能要件
[ ] 利用環境
[ ] 運用方法
[ ] バックアップ
[ ] 障害発生時の対応
[ ] リリース条件

これらが決まっていない場合、

「要件定義済みの開発案件」ではありません。

その場合には、開発費を見積もる前に、

要件整理・要件定義の工程から始める

ことをおすすめします。

6. 「予算」より先に「範囲」を決めていますか？

システム開発では、

予算300万円なので、その中で作ってください。

というご相談もあります。

もちろん、予算に合わせて開発範囲を調整することは可能です。

しかし、

作るものが決まっていない状態で、価格だけを先に固定することはできません。

たとえば住宅建築で、

土地も間取りも広さも設備も決まっていません。
ただし2,000万円以内で家を完成させてください。

と言われても、正確な見積もりが難しいのと同じです。

システム開発も、

要求 → 要件 → 設計 → 工数 → 金額

という順番で具体化していきます。

したがって予算が決まっている場合には、

予算500万円の中で、どこまで実現するかを一緒に決める

という進め方になります。

これは、

500万円で考えているものを全部作る

という意味ではありません。

7. プロジェクトの責任者は決まっていますか？

[ ] 発注側の責任者が決まっている
[ ] 意思決定者が決まっている
[ ] 開発会社からの質問に回答する担当者がいる
[ ] 社内の要望を取りまとめる人がいる
[ ] 仕様変更を承認する人が決まっている

システム開発は、開発会社だけでは進められません。

たとえば開発中には、

この場合はどういう動きにしますか？

AとBのどちらを優先しますか？

このデータは誰が変更できますか？

といった判断が何度も発生します。

このとき、

社内で確認します。

という状態のまま何週間も回答が止まれば、当然プロジェクトも止まります。

発注者側にもプロジェクトを推進する役割が必要です。

8. 誰が仕様を決めるのか決まっていますか？

ここは非常に重要です。

開発会社には、

決められた仕様を実現する役割

と、

何を作るべきか一緒に考える役割

があります。

この2つは同じではありません。

たとえば、

この画面には何を表示したら使いやすいですか？

この業務をどうシステム化すればよいですか？

そもそもどんなシステムにするべきですか？

というところから依頼する場合、

単純な「開発作業」だけではなく、

業務分析
要件整理
UX設計
システム企画
プロジェクトマネジメント

などの役割も必要になります。

当然、それらにも工数が発生します。

9. スケジュールの根拠はありますか？

[ ] 希望リリース日が決まっている
[ ] なぜその日なのか説明できる
[ ] 発注者側の確認期間も考慮している
[ ] テスト期間を確保している
[ ] データ移行期間を考慮している
[ ] 社内教育やマニュアル作成期間を考慮している

特に注意したいのが、

3か月後に使いたいので、3か月でお願いします。

というケースです。

希望日はもちろん重要ですが、

希望納期と、開発に必要な期間は別のものです。

機能量から必要工数を算出し、そのうえで開発体制を検討する必要があります。

10. 既存システムとの連携はありますか？

[ ] 連携対象のシステムが分かっている
[ ] APIの有無を確認している
[ ] API仕様書を入手している
[ ] 外部サービスの利用料金を確認している
[ ] 外部ベンダーとの調整担当者が決まっている
[ ] CSV連携なのかAPI連携なのか決まっている

「○○システムと連携してください」

という一言でも、実際には大きな調査が必要になることがあります。

外部システム側にAPIが存在しない場合には、そもそも希望する方法では連携できない可能性もあります。

11. データ移行について考えていますか？

[ ] 現在利用しているデータがある
[ ] 移行対象データを決めている
[ ] データ形式を確認している
[ ] データの品質を確認している
[ ] 誰がデータを整理するか決めている

新しいシステムそのものより、

古いシステムからのデータ移行の方が大変だった

というケースも珍しくありません。

「今あるExcelを全部入れてください」

という場合にも、

Excelの形式が統一されているのか、重複データがないのかなどを確認する必要があります。

12. リリース後の運用を考えていますか？

システムは完成したら終わりではありません。

[ ] 誰がユーザーを登録するのか
[ ] 誰が問い合わせに対応するのか
[ ] 誰がマスターデータを管理するのか
[ ] 障害時の連絡先を決めている
[ ] 保守契約の必要性を検討している
[ ] サーバー費用などのランニングコストを理解している
[ ] OS・ライブラリなどのアップデートを想定している
[ ] 将来的な機能追加を想定している

開発費だけではなく、

システムを維持するための費用

も考える必要があります。

では、どのような契約・進め方が適しているのでしょうか？

すべてのチェック項目が「YES」である必要はありません。

重要なのは、

現在どこまで決まっているのかによって、依頼すべき内容が変わる

ということです。

大きく分けると、次のようになります。

ケース1：まだ「作りたいもの」が明確になっていない

状態

課題はある
アイデアはある
必要な機能はまだ分からない
業務フローも整理できていない

ケース2：作りたいものはあるが、仕様が決まっていない

状態

システムの目的は決まっている
利用者も決まっている
おおよその機能も分かる
詳細仕様は決まっていない

ケース3：要件定義まで完了している

状態

機能要件が決まっている
画面が決まっている
システム構成がある程度決まっている
完成条件を説明できる

ケース4：プロジェクトは存在しており、一部の開発リソースが不足している

状態

プロジェクト全体の責任者がいる
PMまたはPLがいる
システム全体の設計がある
タスクを切り出すことができる
エンジニアへ指示できる

「エンジニアを1人ください」の前に確認したいこと

SESや準委任型の開発についても、よくある誤解があります。

たとえば、

できるだけ単価の安い若手エンジニアを1人お願いします。

という依頼です。

もちろん条件に合うエンジニアをご提案できる場合もあります。

しかし、その前に確認したいことがあります。

その人に何を担当してもらうのでしょうか？
タスクは誰が作るのでしょうか？
仕様は誰が決めるのでしょうか？
技術的なレビューは誰が行うのでしょうか？
困ったときに誰へ質問すればよいのでしょうか？
プロジェクト全体の品質は誰が管理するのでしょうか？

これらを発注者側で担えない場合、

必要なのは単純な「開発要員1名」ではない可能性があります。

場合によっては、

PM
PL
テックリード
アーキテクト
上流SE

などの役割が必要です。

経験の浅いエンジニアをアサインするほど、

周囲に適切な管理・設計・レビュー体制が必要になる

という点にも注意が必要です。

「安いエンジニアを入れれば、開発費も安くなる」とは限らない

エンジニアの単価だけを見ると、

月100万円のエンジニアより、月60万円のエンジニアの方が安く見えます。

しかし、

誰かが仕様を考える
タスクを細分化する
実装内容をレビューする
技術的な質問に回答する
問題発生時にフォローする

必要があります。

これらを自社で担えるのであれば、若手エンジニアを活用することもできます。

一方、

詳しいことは分からないので全部任せたい。
でもエンジニアはできるだけ安い人にしてほしい。

という条件は、両立しない場合があります。

「管理を自社で行う代わりに開発リソースだけ調達する」のか、「プロジェクトそのものを任せる」のか。

ここを最初に決めることが重要です。

開発会社へ「全部お任せ」することもできます

ここまで読むと、

「発注者側でそこまで決めないと依頼できないの？」

と思われるかもしれません。

もちろん、そんなことはありません。

株式会社アットマーク・ソリューションでは、

まだ何も決まっていない段階からご相談いただくことも可能です。

ただしその場合、

「開発だけを依頼する」

のではなく、

一緒に整理する工程からプロジェクトを開始する

ことになります。

たとえば、

相談
 ↓
現状整理
 ↓
課題整理
 ↓
業務整理
 ↓
要求整理
 ↓
要件定義
 ↓
概算見積
 ↓
設計
 ↓
開発
 ↓
テスト
 ↓
リリース
 ↓
運用・改善

という進め方です。

つまり、

決まっていなくても問題ありません。

ただし、

決めるための工程を省略することはできません。

開発前チェックリスト

最後に、簡易版のチェックリストを掲載します。

プロジェクト

[ ] システムを作る目的が決まっている
[ ] 解決したい課題が決まっている
[ ] プロジェクト責任者が決まっている
[ ] 意思決定者が決まっている
[ ] 希望リリース時期が決まっている
[ ] 予算の目安がある

業務

[ ] 現在の業務フローを説明できる
[ ] システム化する範囲が決まっている
[ ] システム化しない範囲が決まっている
[ ] 例外的な業務を把握している

システム

[ ] 利用者が決まっている
[ ] 利用人数が分かっている
[ ] 必要な機能が整理されている
[ ] 機能に優先順位を付けている
[ ] 必要な画面が整理されている
[ ] 必要なデータが整理されている
[ ] 権限が整理されている
[ ] 外部システム連携を把握している

開発

[ ] 要件定義が完了している
[ ] 仕様を決める担当者がいる
[ ] 開発会社からの質問へ回答できる
[ ] 仕様変更時の意思決定方法が決まっている
[ ] 発注者側でテストに参加できる

運用

[ ] データ移行について検討している
[ ] 運用担当者が決まっている
[ ] 問い合わせ対応方法を決めている
[ ] 保守・メンテナンスについて検討している
[ ] ランニングコストを想定している

チェックが付かなかった項目があっても問題ありません

このチェックリストは、

「全部チェックできなければ相談できない」

という意味ではありません。

むしろ、

チェックできなかった項目こそ、最初に整理すべき内容です。

たとえば、

要件がまだ整理されていない

→ 要件整理・要件定義からご支援します。

業務そのものが整理されていない

→ 業務整理から一緒に行います。

要件は決まっているが開発リソースが不足している

→ 開発チームへのエンジニア参画を検討します。

要件も体制も決まっている

→ 請負開発として見積もりを検討します。

重要なのは、

「現在どこまで決まっているのか」をお互いに認識したうえでプロジェクトを始めることです。

システム開発は「コードを書くところ」から始まるわけではありません

開発プロジェクトで最も避けたいのは、

発注者は「当然そこまでやってくれると思っていた」

一方で、

開発会社は「そこは依頼範囲に含まれていないと思っていた」

という状態です。

こうした認識のズレは、プロジェクトが進んでから発覚するほど大きな問題になります。

だからこそ、アットマーク・ソリューションでは、開発を始める前の整理を大切にしています。

まだ構想段階でも構いません。

要件が決まっていなければ、要件を決めるところから。

業務が整理されていなければ、業務を整理するところから。

開発体制が足りなければ、必要な役割を整理するところから。

「とりあえず作り始める」のではなく、「何を、誰が、どこまで担当するのか」を明確にしてからプロジェクトを進める。

それが、発注者と開発会社の双方にとって、結果的に最も無駄の少ないシステム開発につながると私たちは考えています。