システム開発の工程とは？全体の流れとトラブル対策を解説

システム開発は、一般的に「企画 → 要件定義 → 設計 → 実装 → テスト → 運用・保守」の6つの工程で進みます。このうち企画から設計までを「上流工程」、実装からテストまでを「下流工程」と呼びます。工程の名前と順番を覚えること自体は難しくありません。ただ、実際のプロジェクトでは工程ごとに起こりやすいトラブルがあり、それを知らずに進めると後の工程で手戻りが発生します。

本記事では、各工程で何をして何が成果物になるのかを表で整理したうえで、工程ごとに起こりやすいトラブルと、その予防策を解説します。これからシステム開発を発注する担当者の方が、開発会社と同じ言葉で会話できる状態になることを目指して書いています。

◆この記事の要点

• 工程の全体像：企画→要件定義→設計→実装→テスト→運用・保守。設計までが上流工程、実装以降が下流工程
• トラブルの構造：遅延や予算超過の多くは上流工程で生まれ、下流工程で表面化する。後の工程になるほど修正の費用は大きくなる
• 予防策5選：変更時のルールを先に決める／文書ではなく画面で合意する／体制を見積もり時に確認する／外部連携の代替案を持つ／定例と進捗の見える化
• 発注者の関わり：要件定義のレビューと受け入れテストは発注者にしかできない。この2つに時間を確保する
• 当社の進め方：Figmaで画面を先に見せて合意し、AI駆動開発で実装の工数を圧縮したぶんを要件定義とテストに使う

» 【無料】システム開発の進め方を株式会社ペンタゴンに相談する

筆者はアプリ・Webシステム開発会社「株式会社ペンタゴン」の代表として、スタートアップから大手企業まで10年以上、企画段階から運用・保守までを一貫して担当してきました。工程の説明はひと通り知っているという方は、トラブル予防策5選から読み進めてください。

アプリ開発専門のプロ「株式会社 Pentagon（ペンタゴン）」とは？

Pentagon（ペンタゴン）は、アプリ開発を専門に行う会社です。私たちは単なる開発会社ではなく、お客様の事業の成長を共に創り上げるアプリ開発パートナーです。お客様の事業の成長に本気で向き合うため、当社のアプリ開発では、

• 「もっとこうすれば良くなる」という提案を次々と出します
• 「使いやすさ」と「成果があがること」のどちらも妥協しないアプリを作ります
• リリース後もデータを見ながら、改善・グロースまで一緒に考えます

詳しくはペンタゴンの特徴をご覧ください。無料相談はこちらから

システム開発工程の基礎知識

システム開発の工程とは

システム開発の工程とは、システムを完成させて運用に乗せるまでの作業を、目的と成果物の区切りで段階に分けたものです。一般的には企画、要件定義、設計、実装、テスト、運用・保守の6工程に分けます。各工程で「何をするのか」「何が成果物として残るのか」「どんなトラブルが起こりやすいのか」を一覧にまとめました。

工程の区切り方は開発会社によって多少異なり、企画を要件定義に含めて5工程とする場合や、テストを単体・結合・総合に分けて7〜8工程とする場合もあります。名称が違っても中身は同じなので、見積書や提案書では「どの作業がどの工程に含まれているか」を確認してください。

期間の目安は、当社の業務システム開発では要件定義に1〜2ヶ月、実装と検証に小規模で2〜4週間、中規模で1〜2ヶ月、大規模で3ヶ月以上です。設計は要件定義と一部並行して進めるため、全体では小規模なシステムで1.5〜3ヶ月、中規模で2〜4ヶ月、大規模で4〜5ヶ月以上が目安になります。要件定義の比率が大きく見えますが、ここを削ると後工程の手戻りで倍以上の期間がかかるため、当社では削らない方針です。

なお、スマートフォンアプリの開発も基本の工程は同じですが、ストア審査や端末ごとの動作確認、リリース後のOS更新への追従が加わります。アプリ開発の工程を知りたい方は、次の記事を参照してください。

担当者が知るべき『アプリ開発の流れ』７つの手順をプロが解説

システム開発の成果物とは？工程別の納品物一覧と発注者が確認すべきポイント

上流工程と下流工程の違い

企画・要件定義・設計（基本設計まで）を「上流工程」、詳細設計・実装・テストを「下流工程」と呼びます。上流工程は「何を作るか」を決める工程、下流工程は「決めたとおりに作る」工程です。発注者の関与が重いのは上流工程で、下流工程は開発会社の作業が中心になります。

この区分を知っておくべき理由は、トラブルの大半が上流工程で生まれ、下流工程で表面化するからです。要件の抜け漏れは実装中に「この場合はどうなりますか」という質問として現れ、設計の曖昧さはテストで「思っていた動きと違う」という形で現れます。後の工程になるほど修正の範囲が広がり、費用も大きくなります。発注者が時間をかけるべき場所は上流工程です。

工程の略語一覧

開発会社の提案書やスケジュール表では、工程が略語で書かれることがあります。よく使われるものをまとめました。

V字モデルとは：各工程と対応するテストの関係

V字モデルとは、要件定義から実装までの工程を左側に、それぞれの工程で決めたことを確認するテストを右側に並べ、V字型に対応させた図のことです。要件定義で決めたことは受け入れテストで、基本設計で決めたことは総合テストで、詳細設計で決めたことは結合テストで、実装したものは単体テストで確認します。

発注者にとってこの対応関係が重要なのは、要件定義の抜け漏れは、対応する受け入れテスト、つまり最後の工程まで見つからないことを示しているからです。上流工程で決めたことが正しいかどうかは、下流工程の最後でしか検証されません。だからこそ、上流工程で画面のプロトタイプを使って「動く前に」確認する価値があります。

弊社「株式会社ペンタゴン」では、アプリに特化して制作をしております。　 アプリ開発をお考えの場合は、以下のバナーをクリックして弊社までご相談ください。経験豊富なアプリエンジニアがご相談を承ります。

システム開発における各工程の解説と重要ポイント

各工程を「家を建てる」ことになぞらえると、全体のイメージがつかみやすくなります。

システム開発というと「実装」に目が向きがちですが、家づくりで図面なしに工事を始める人はいません。企画と要件定義で何を建てるかが決まり、設計で図面ができて、実装はそれを形にする工程です。以下、工程ごとに「何をする工程か」と「進めるうえでのポイント」をまとめます。

工程① 企画｜「何のために作るか」と効果の物差しを決める

何を行う工程か：解決したい課題、対象となる業務、期待する効果、予算と期間の枠を決め、社内の合意を取る工程です。開発会社に相談する前の社内作業が中心になります。

進めるにあたってのポイント

1. 目的を「状態」で書く：「在庫管理システムを作る」ではなく「拠点間で在庫数が合わず毎週行っている確認の電話をなくす」のように、完成後に誰がどう動けているかを書きます。この状態がそのまま効果を測る物差しになります
2. 利害関係者を洗い出す：決裁者、実際に使う現場、情報システム部門、連携先の担当部署。ここで漏れた人の一声が、後工程での大幅な要件変更になります
3. 要望は集めるが、この段階で絞らない：優先順位は要件定義で効果と費用を見ながら決めます。企画段階では「困っていること」を広く集めるほうが、後の抜け漏れが減ります

当社では企画段階からデザイナーが参画し、必要に応じて現場や想定ユーザーへのアンケート調査を行います。企画した本人も気づいていないニーズがこの調査で見つかることが多く、要件定義の精度が上がります。社内で企画がまとまらない場合は、企画からサポートできる開発会社に早めに相談するのも一つの方法です。

【テンプレ無料】プロが教える「アプリ開発企画書」の９つのポイント

工程② 要件定義｜作る範囲と優先順位を言語化し、見積もりを確定する

何を行う工程か：業務フローを整理してシステム化する範囲を決め、機能要件（何ができるか）と非機能要件（性能・セキュリティ・可用性など）、優先順位を要件定義書にまとめる工程です。本開発の見積もりがここで確定します。

進めるにあたってのポイント

1. いまの業務の実態から出発する：現場の担当者に同席してもらい、使っているExcelや帳票を実物で見せてもらいます。「こうあるべき」から考えると、現場で使われない機能ができます
2. 「当たり前」を文章にする：発注側にとって自明な業務ルールほど要件定義書から抜けます。曖昧な要件のまま進めると後工程の手戻りの原因になるので、画面単位で「この場合はどうなるか」を確認します
3. 優先順位をつける：すべての要件が同じ重さではありません。「ないと業務が回らない（Must）」「あると効率が上がる（Should）」「次の段階でよい（Could）」に分け、最初に作る範囲を決めます。判断の軸は「業務への効果の大きさ」と「実装の手間」の2つで、効果が大きく手間が小さいものから着手します。この優先順位があると、予算や期間が足りなくなったときに何を削るかで迷いません
4. 見積もりの前提を確認する：金額だけでなく、どの機能が含まれ、何が含まれていないか、変更が出た場合はどう扱うかを書面で確認します

当社では要件定義に1〜2ヶ月をかけ、見積書には前提とスコープを明記しています。要件定義の工程だけを先に契約することも可能で、BtoBマーケットプレイスの案件では約2ヶ月の要件定義を納品したうえで本開発に移行しました（開発実績：出品から支払管理まで一気通貫のBtoBマーケットプレイスアプリ開発）。

システム開発の要件定義とは？進め方から成功のコツまで徹底解説

要件定義は誰がやる？発注側が準備するものと見積もりが出る条件

工程③ 設計｜画面とデータで「動く前に」合意する

何を行う工程か：要件を実現するための仕組みを決める工程です。利用者から見える部分（画面、帳票、操作の流れ、外部システムとの連携）を決める基本設計と、プログラムの内部構造やデータベースの構造を決める詳細設計に分かれます。

進めるにあたってのポイント

1. 文書ではなく、動くもので合意する：設計書の文章だけで合意すると、完成後に「思っていたものと違う」が起こります。画面のプロトタイプを実際に触ってもらい、操作の流れごと確認します
2. 曖昧な仕様を下流工程に持ち越さない：「あとで決める」とした項目は、実装中に開発者の判断で埋められます。例外的なケースの扱いまで設計段階で決めておきます
3. 使いやすさは設計で決まる：入力の手数や画面の遷移は、実装が終わってからでは直しにくい部分です。実際に使う人の視点でレビューします

当社では要件定義の段階からデザイナーが入り、Figmaで画面と導線を先に固める「デザインファースト」で進めています。掲載申請から管理者の審査・承認までのフローを持つシステムのように、関係者ごとに見える画面と操作が変わるものほど、文書より画面で流れを確認する効果が大きくなります（開発実績：審査承認フローまで対応するM&Aマッチング管理Webアプリ開発）。

工程④ 実装｜設計どおりに作り、レビューで品質を守る

何を行う工程か：設計書に基づいてプログラムを書き、データベースや外部連携を構築する工程です。開発会社の作業が中心ですが、発注者側にも確認事項への回答や進捗の把握という役割があります。

進めるにあたってのポイント

1. レビュー体制を確認する：書いたコードを別の担当者が確認するコードレビューは、バグの早期発見と品質の均一化に効きます。見積もり時に「誰がレビューするのか」を聞いておきます
2. 確認事項の返答ルートと期限を決める：実装中に出る「この場合はどうしますか」への回答が遅れると、そのぶん開発が止まるか、開発者の独断で進みます。窓口と返答期限を決めておきます
3. 進捗を週次で見える化してもらう：「順調です」という報告ではなく、完了した画面と残っている画面の一覧で確認します

当社の実装はFigmaの設計をもとにしたAI駆動開発（Claude Code）が中心で、コーディングの工数を大きく圧縮しています。AIが書いたコードは人とAIの両方でレビューし、圧縮できた工数は要件定義とテストに振り向けています。工程の比重がどう変わるかは、トレンドの章「AI駆動開発で工程の比重が変わる」で図にしています。

工程⑤ テスト｜要件を満たしているかを第三者の目で確認する

何を行う工程か：作ったシステムが要件どおりに動くかを確認する工程です。プログラムの部品ごとに確認する単体テスト、部品をつなげて確認する結合テスト、システム全体を本番に近い環境で確認する総合テスト、発注者が実際の業務の流れで確認する受け入れテストの順に進みます。

進めるにあたってのポイント

1. テスト計画を実装前に作る：何を、どの順番で、どの環境で確認するかを先に決めます。設計書に対応する形で確認項目を作ると、抜け漏れが減ります
2. 開発者以外がテストする：作った本人は自分の思い込みどおりに操作してしまうため、見落としが起きます。開発に関わっていないメンバーによるテストを工程に入れます
3. 受け入れテストは業務シナリオで行う：画面を一つずつ確認するのではなく、「受注から請求まで」のように実際の業務を通しで流します。発注者にしかできないテストなので、期間を最初から確保します

当社では開発者以外のメンバーによる第三者視点のテストを標準の工程に組み込んでいます。AI駆動開発で実装が速くなったぶん、テストと品質改善にかける時間はむしろ増やしています。

システム開発の総合テストとは？種類・手順・観点を徹底解説

工程⑥ 運用・保守｜使われ続ける状態を保ち、効果を測って改善する

何を行う工程か：リリース後にシステムを安定して動かし続ける工程です。稼働の監視、障害対応、セキュリティ更新、OSやブラウザの更新への追従、業務の変化に合わせた改修が含まれます。

進めるにあたってのポイント

1. 保守の範囲と費用を契約時に決める：障害対応の受付時間、復旧までの目安、軽微な改修が保守に含まれるかどうかを、納品前に書面で確認します
2. 障害時の連絡体制を作る：誰が、どこに、どう連絡するかを決め、連絡先を現場に共有しておきます
3. 効果を測って改善する：企画で決めた物差し（削減した時間、処理件数、ミスの件数など）を実際に測り、使われていない機能や新たな要望を次の改修に反映します

当社はリリースして終わりではなく、利用状況のデータを見ながら改善まで伴走する体制をとっています。システムは作った時点ではなく、使われて効果が出た時点で成功と考えているためです。

アプリの運用保守費はいくら？相場・月額の目安と内訳をプロが解説

株式会社ペンタゴンでは、要求をカタチにするのは当たり前。さらに「もっとこうすれば良くなる」という鋭いデザインや機能の提案を次々に出します。新しいサービスを検討中なら、一度ご相談ください！

システム開発で使われる代表的な開発モデル

工程の中身は同じでも、「どの順番で、どの単位で工程を回すか」は開発モデルによって変わります。代表的なモデルの進め方と、向いているケース、発注者が注意する点を表にまとめました。

どのモデルでも、要件変更の扱いが前提から変わる点は押さえておいてください。ウォーターフォールは「開発中に大きな変更は起きない」ことを前提に進めるため、変更が出れば計画の見直しが必要になります。アジャイルは「変更は起きるもの」として進めますが、そのぶん発注側にも反復ごとの判断が求められます。

当社では業務システムの開発はウォーターフォールを基本にしつつ、設計の段階にFigmaのプロトタイプ確認を挟む進め方をとっています。文書ベースのウォーターフォールの弱点である「動くものを見るのが最後になる」を補うためです。要件が動くことが前提の新規サービスでは、トレンドの章で触れるMVP（最小限の機能を持つ製品）から段階的に広げる進め方を提案しています。

システム開発の⼿法を徹底解説！選び⽅のポイントとおすすめの開発モデル

ウォーターフォール開発とは？特徴やメリット・デメリットを徹底解説【システム開発】

弊社「株式会社ペンタゴン」では、アプリに特化して制作をしております。　 アプリ開発をお考えの場合は、以下のバナーをクリックして弊社までご相談ください。経験豊富なアプリエンジニアがご相談を承ります。

システム開発の工程におけるトラブル予防策5選

システム開発の遅延や予算超過は、原因をたどると「予想外」ではなく、工程の初めに手を打てたものが少なくありません。当社が支援してきた案件で繰り返し見てきた5つの原因と、それぞれをトラブルに発展させないための予防策をまとめます。

システム開発におけるリスク管理の重要性と対策方法を解説【2026年最新版】

① 要件の大幅な変更

起こること：実装の途中で、上長や経営者の一声、投資家の意向、競合の動きなどによって要件が大きく変わります。追加や変更の内容そのものより、「設計まで終わった部分を作り直す」ことがスケジュールと予算に効いてきます。

予防策

• 決裁者を要件定義のレビューに同席させる：後から「聞いていない」と言う人を、決める場に最初から入れておきます
• 変更時のルールを契約時に決める：変更要望が出たら、開発会社が費用と期間への影響を見積もり、発注側が承認してから着手する。この手順を最初に合意しておきます
• 最初から全部作らない：使ってみないと分からない部分は第2段階に回し、まず業務が回る範囲でリリースします

当社では仕様変更のご要望があるたびに、費用と期間への影響をその場で提示し、進めるかどうかを判断していただいています。変更を止めるためではなく、変更の代償を見えるようにして判断の質を上げるためです。

② 要件定義・設計の甘さが開発工程で現れる

起こること：実装の途中で「この条件のときはどう動けばよいか」という確認が頻発し、そのたびに作業が止まります。設計どおりに作ると実現できない、あるいは性能が出ないことが実装中に判明することもあります。初期の工程で検討されなかった問題が、工程が進むにつれて表面化するのが特徴です。

予防策

• 画面単位で例外ケースを確認する：正常な流れだけでなく、「入力が空のとき」「権限がないとき」「連携先が応答しないとき」をレビューの項目に入れます
• プロトタイプで操作の流れを通す：設計書を読むだけでは気づかない矛盾が、画面を触ると見つかります
• 技術的に不確かな部分は先に試す：外部連携や性能に不安があるなら、実装の前に小さく検証します

当社では要件定義の段階で、業務フローや仕様をAIに読ませて未確定の要件を洗い出す工程を入れています。人が読むと「書いてあるつもり」になる抜け漏れを、機械的に指摘させるためです。

③ リソース制約

起こること：発注側の予算が年度の途中で削られる、発注側の担当者が異動する、開発会社側の主要メンバーが抜けるといった形で、人・予算・時間のどれかが足りなくなります。担当者が代わると、それまでの経緯が失われ、同じ議論をやり直すことになります。

予防策

• 体制と担当者を見積もり時に確認する：誰が設計し、誰が実装し、誰がテストするのか。途中で担当が代わる場合の引き継ぎ方法も聞いておきます
• 決定の経緯を記録に残す：議事録と決定事項の一覧を1か所にまとめておけば、担当者が代わっても経緯をたどれます
• 予備の期間と予算を持つ：全体の1〜2割程度を予備として確保し、使わなければ次の改修に回します

④ 外部要因

起こること：法改正や業界の規制変更、OSやブラウザの更新、連携している外部サービスの仕様変更や提供終了、自然災害など、プロジェクトの外側で起きる変化です。特に外部サービスとの連携は、相手の都合で仕様が変わるため、自分たちでは制御できません。

予防策

• 連携先の変更告知を追う窓口を決める：外部サービスの仕様変更は事前に告知されることがほとんどです。誰がそれを見るかを決めておきます
• 代替手段を設計段階で検討する：連携先が止まったときにシステム全体が止まらないよう、手入力での代替や切り離せる構造を設計に含めます
• 保守契約に外部要因への対応を含める：法改正や外部サービスの変更に伴う改修を、保守の範囲に入れるか別見積もりにするかを決めておきます

⑤ コミュニケーションの問題

起こること：「伝えたつもり」と「聞いていない」のすれ違い、議事録がなく決定事項が曖昧になる、発注側の窓口が複数あって指示が食い違う、といった形で現れます。開発チーム内でも利害関係者との間でも起こり、どの工程でも遅延の原因になります。

予防策

• 定例会議と議事録を習慣にする：週1回の定例で進捗と課題を確認し、決定事項と宿題を議事録に残します
• 窓口を一本化する：発注側・開発側それぞれに責任者を一人置き、確認事項はその人を経由させます
• 進捗を画面と数字で共有する：「順調です」ではなく、完了した画面と残りの画面、課題の一覧で共有します

当社では週1回の定例を基本とし、関係部署が多い案件では決定が必要な時期に週2〜3回に増やして関係者に同席してもらっています。認識のズレは早く見つけるほど安く直せるためです。

システム開発が遅れる7つの原因と効果的な対策方法を解説

システム開発の成功要因と発注者が押さえたいポイント

ここまでの予防策を、プロジェクト全体の進め方として整理すると次の5つになります。いずれも開発会社に任せきりにせず、発注者が「やってほしい」と求めてよいことです。

プロジェクト憲章の定義

プロジェクト憲章とは、目的、スコープ、目標、関係者、スケジュール、リスク、変更の扱いを1〜2枚にまとめた文書です。システム開発は多くの人が関わる作業で、全員が同じ目的と全体像を共有していることが前提になります。憲章があれば、途中で判断に迷ったときに「この目的に照らしてどうか」で決められます。

関係者の期待値を揃える効果もあります。経営者は費用対効果を、現場は使いやすさを、情報システム部門は保守性を見ています。憲章を通じて目標とスコープを共有しておくと、「そんなはずではなかった」という後からの認識のズレを減らせます。

要件定義・設計段階で不確定要素を可能な限り潰す

上流工程で決め切った分だけ、下流工程のトラブルは減ります。細かな機能まで要件を言語化し、システム全体の整合性を確認し、「当たり前にこうだよね」と思われる事柄についても入念に確認します。自明に思える要件ほど、関係者ごとに理解が違うことがあるからです。

一方で、使ってみないと分からないことまで机上で決め切ろうとすると、要件定義が終わりません。「いま決められること」と「使ってから決めること」を分け、後者は第2段階の範囲として明示しておくのが現実的です。

進捗を見える化するプロジェクトマネジメント

進捗は「報告」ではなく「一覧」で確認します。ガントチャートでタスクの依存関係と期限を可視化し、タスクごとに担当者と状態を管理し、重要度と緊急度で優先順位をつけます。遅れは早く見つかるほど打ち手が多く、1週間の遅れなら調整できても、1ヶ月の遅れは納期に直結します。

発注者側は、進捗の一覧を見せてもらえるかどうかを開発会社選びの基準にしてよいと考えています。当社では進捗の可視化と認識のズレの早期解消を、プロジェクト運営の基本にしています。

システム開発のスケジュールを理解して円滑に開発を進めよう

第三者によるテスト

テストは開発者本人以外が行うことで、はじめて品質の担保になります。理由は2つあります。一つは、作った本人は自分の仮定どおりに操作してしまうため、意図しない動きを見落としやすいこと。もう一つは、開発に関わっていない人がテストすると、システムを深く知らない利用者の視点で使いにくさやエラーを早期に見つけられることです。

開発会社に「誰がテストするのか」を確認してください。開発者が自分でテストして終わり、という体制であれば、受け入れテストの比重を発注側で重くする必要があります。

バグの早期発見・早期解消

バグは見つかる工程が遅いほど、修正にかかる費用が大きくなります。設計段階で見つかった矛盾は文書を直せば済みますが、実装後に見つかれば複数の画面に影響し、運用開始後に見つかれば業務を止めて対応することになります。利用者がバグを見つける状態が続くと、システムそのものが使われなくなります。

そのために、各工程の終わりにレビューの機会を設け、次の工程に問題を持ち越さないことが基本です。工程をまたいで見つかった問題は、どの工程の作業が原因だったかを振り返り、次のプロジェクトのチェック項目に加えます。

システム開発工程のトレンド

システム開発には大きな予算と時間がかかります。そのため近年は、最初から全体を作り切るのではなく、小さく作って検証しながら進める方法が主流になっています。工程の順番が変わるわけではなく、「一度に回す範囲」を小さくする考え方です。

新プロダクトはPoCから始める

PoC（Proof of Concept：概念実証）は、アイデアや技術が本当に実現できるかを、本開発の前に小さく確かめる取り組みです。新しい技術を使う、連携先の実現性に不安がある、そもそも狙った効果が出るか分からない、といった場合に、システムの一部だけを作って検証します。

PoCで確かめるのは、技術的に実現できるか、狙った効果が見込めるか、関係者がその方向で合意できるか、の3点です。PoCの結果をもとに本開発の計画を立てるため、ここでの検証が甘いと、本開発の要件定義からやり直すことになります。

PoCとは？アプリ開発ではPoCが重要！リスクを下げて検証

MVP（Minimum Viable Product）から小さく始める

MVPは、利用者に価値を届けられる最小限の機能だけを持ったバージョンで、実際に使ってもらうことを前提にしています。検証用のPoCと違い、MVPは本番で使われるシステムです。最も重要な機能に絞って早くリリースし、利用者の反応を見ながら次に作る機能を決めます。

当社では新規サービスの開発で、まずMVPの範囲を一緒に決め、そこから段階的に広げていく進め方を提案しています。最初に全部を作らないことは、トラブル予防策5選の「① 要件の大幅な変更」への最も有効な予防策でもあります。

アプリのMVP開発とは顧客ニーズを満たす最小限のプロダクト

AI駆動開発で工程の比重が変わる

生成AIによるコーディングが実用になったことで、工程そのものは変わらないまま、工程ごとの比重が変わり始めています。従来は実装が全体の工数の中心でしたが、AI駆動開発では実装の工数が圧縮され、そのぶんを要件定義と設計、テストに回せるようになりました。

当社ではFigmaで画面を固めたうえで、Claude Codeを使ったAI駆動開発で実装を進めています。実装が速くなった効果は納期の短縮だけではなく、上流工程に時間をかけられること、途中の仕様変更に対応しやすくなったこと、テストと品質改善の時間を増やせることに現れています。この記事で繰り返し述べてきた「上流工程に時間をかける」が、コストを増やさずにできるようになったのが一番の変化です。

AI駆動開発のWebシステム開発費用・期間｜要件定義が全て

システム開発の工程についてよくある質問

要件定義と基本設計の違いは何ですか？

要件定義は「何を作るか」を決める工程、基本設計は「それをどう実現するか」を利用者から見える形で決める工程です。要件定義では「受注データを入力し、月末に請求書を出せること」のように、業務として必要なことを決めます。基本設計では、そのための画面の構成、入力項目、帳票のレイアウト、他システムとの連携方法を決めます。要件定義が終わると見積もりが確定し、基本設計が終わると画面の見た目が確定する、と考えると区別しやすいです。

基本設計と詳細設計の違いは何ですか？

基本設計は利用者から見える部分（外側）を決め、詳細設計はプログラムの内部構造（内側）を決めます。そのため基本設計は外部設計、詳細設計は内部設計とも呼ばれます。発注者がレビューするのは基本設計までで、詳細設計は開発会社の内部で実装者に向けて作る文書です。発注者が詳細設計書の中身を理解する必要はありませんが、「詳細設計書が納品物に含まれるか」は保守を別の会社に引き継ぐ可能性があるなら確認しておいてください。

ウォーターフォールとアジャイルでは工程が違いますか？

工程の種類は同じで、回し方が違います。ウォーターフォールは要件定義から運用まで全体を一度ずつ順番に進めます。アジャイルは1〜4週間の反復ごとに、機能のかたまり単位で設計・実装・テストを繰り返します。発注者から見た違いは、ウォーターフォールでは上流工程に判断が集中し、アジャイルでは反復ごとに判断が求められる点です。どちらが優れているかではなく、要件がどれだけ固まっているか、途中で変える必要がどれだけあるかで選びます。

発注者はどの工程まで関わる必要がありますか？

すべての工程に関わりますが、発注者にしかできないのは「要件定義のレビュー」と「受け入れテスト」の2つです。企画は発注者が主体、要件定義と基本設計は業務の実態を伝えて内容を確認する役割、実装と単体〜総合テストは確認事項への回答と進捗の把握、受け入れテストは実際の業務の流れで動作を確認する主体、運用・保守は効果の測定と改善要望の整理が役割になります。要件定義書の作成や画面設計は開発会社の作業なので、社内に情報システムの担当者がいなくても進められます。

各工程にはどれくらいの期間がかかりますか？

当社の業務システム開発では、要件定義に1〜2ヶ月、実装と検証に小規模で2〜4週間、中規模で1〜2ヶ月、大規模で3ヶ月以上が目安です。全体では小規模なシステムで1.5〜3ヶ月、中規模で2〜4ヶ月、大規模で4〜5ヶ月以上になります。期間を左右するのは画面数と帳票数、外部システムとの連携の数、関係部署の数で、関係部署が多いほど要件定義の合意形成に時間がかかります。

業務システム開発の費用相場と内訳｜元が取れる条件と試算法

まとめ

システム開発は、企画→要件定義→設計→実装→テスト→運用・保守の工程で進みます。工程の名前を知ることよりも大切なのは、トラブルの多くが上流工程で生まれて下流工程で表面化するという構造を理解し、上流工程に発注者自身が時間をかけることです。

• 要件変更のルールを契約時に決め、決裁者を要件定義のレビューに入れる
• 設計は文書ではなく、画面のプロトタイプで合意する
• 体制・レビュー・テストを誰がやるのかを見積もり時に確認する
• 外部連携の代替手段と、保守の範囲を設計と契約に含める
• 週1回の定例と進捗の一覧で、認識のズレを早く見つける

当社は企画段階からデザイナーが参画し、Figmaで画面を先に合意し、AI駆動開発で実装を圧縮したぶんを要件定義とテストに使う進め方で、スタートアップから大手企業までのシステム開発を支援してきました。「社内でシステム開発の話はあるが、何から決めればよいか分からない」という段階からご相談いただけます。

» 【無料】システム開発の進め方を株式会社ペンタゴンに相談する

ペンタゴンの4つの特徴（一貫対応・ユーザー視点設計・KPI逆算・組織的品質管理）