What Is System Development? The 6 Phases and the Real Cost of Waiting

システム開発が遅れる最大の原因は、技術の難しさではありません。「確認待ち」の時間です。仕様の質問に返事が来ない、レビューが止まる、承認が降りない——コードを書く時間より、誰かの返答を待つ時間のほうが長い。これが現場の実態です。

この記事は、初めて開発を発注する方や、社内でプロジェクトを任された非エンジニアの方に向けて、システム開発とは何かを6工程に沿って整理し、どこで時間が溶けるか、当社（株式会社六／Roku inc.）がAIエージェントでそれをどう圧縮するかまでをお伝えします。見積もりや納期の「内訳」が読めるようになります。

システム開発とは｜「作って終わり」ではない一連の工程

システム開発とは、業務やサービスの課題を解決するソフトウェアを、要件の整理から設計・実装・テスト・リリース・運用まで通して作り上げる活動を指します。プログラムを書く作業は、全工程のごく一部にすぎません。

そして「作って終わり」ではありません。むしろリリース後の運用・保守こそが本番で、ここで初めてシステムは価値を生み始めます。発注前にまず全体像を押さえてください。

自社のプロジェクトがどの工程にいるかを言語化できると、遅れや追加費用の理由が見えてきます。

システム開発の工程｜要件定義から保守までの6ステップ

システム開発の工程は、各工程の「目的」「発注側に求められること」をセットで把握するのがコツです。

要件定義

「何を作るか」を言葉と図で固める工程です。ここが曖昧だと後工程すべてが揺れます。IPA（情報処理推進機構）によれば要件定義は工数の約10%にすぎませんが（出典：ipa.go.jp）、この不備こそが失敗の根本原因です。複数の専門媒体も、開発失敗の主因は技術の難しさではなく「要件定義の曖昧さ=発注側と開発側のコミュニケーション齟齬」だと指摘します（出典：hnavi.co.jp）。要件定義は発注側が主導する工程です。

設計（基本設計・詳細設計）

要件を「どう実現するか」に落とし込みます。基本設計は画面・機能・データの外側の仕様、詳細設計はプログラム内部の作り方。工数比率はおおよそ20〜30%です（出典：wakka-inc.com）。発注側は基本設計のレビューと承認を担います。

実装・開発

設計に沿ってプログラムを書く工程で、工数比率は最大。製造・単体テストで全体の約30〜40%を占めます（出典：ipa.go.jp）。費用の内訳では、この工程が人月の中心です。費用相場や人月単価の読み方はAI駆動システム開発のサービス内容もあわせてご確認ください。

テスト

作ったものが要件どおり動くかを確認します。想像以上に重い工程です。IPA「ソフトウェア開発分析データ集2022」（5,546プロジェクト分析）では、結合テストと総合テストだけで実績工数の中央値32.0%（結合20.1%＋総合11.9%）を占めます（出典：ipa.go.jp）。テストは「おまけ」ではなく開発の3分の1を占める本体です。

リリース

本番環境へ公開します。データ移行や切り替え手順、トラブル時の戻し方まで計画し、発注側は公開可否の最終判断を担います。

運用・保守

公開後、システムを安定稼働させ改善を重ねる工程です。障害対応、セキュリティ更新、機能追加が含まれます。前述のとおり、ここが価値を生む本番です。

ウォーターフォール型とアジャイル型｜進め方の違いと向き不向き

進め方には2つの型があり、優劣ではなくプロジェクトの性質で選びます。

正直にお伝えすると、アジャイルや高速な反復が常に正解ではありません。アジャイルは少人数前提のため大規模開発に不向きで、要件がすでに固まっている場合や複数部署の承認フロー統制が必要な場合は、ウォーターフォールのほうが合理的です（出典：sackle.co.jp）。金融や行政など規制の強い領域では特にそうです。判断軸は、要件が固定か／関係部署の数／変更の起きやすさの3点です。

オープン系システムとは｜種類と開発手法の関係

システムは大きく3種類に分かれます。

• 汎用系：大型コンピューターに依存したクローズドな構成。銀行の勘定系など堅牢性重視。
• オープン系／Web系：標準的な機器やソフトを組み合わせる柔軟な構成。社内業務システムやインターネット向けサービスに多い。

オープン系システムとは、特定メーカーに縛られず標準技術を組み合わせて柔軟に構築するシステムを指します（出典：system-kanji.com）。多くの企業システムはオープン系かWeb系で、ここまでの6工程やウォーターフォール／アジャイルの考え方がそのまま当てはまります。種類が違っても、確認のやり取りで時間が溶ける構造は共通です。

各工程で本当に時間が溶けるのは「確認待ち」

開発が遅れる主要因の一つは、技術の難しさではなく「確認待ち」のコミュニケーションコストです。ただし正確に言う必要があります。

工数（作業時間そのもの）で見ると、最大は確認待ちではありません。IPAの実データでは製造32%＋結合20%＋総合13%で、下流工程が約65%を占めます（出典：ipa.go.jp）。「上流のやり取りが工数の大半」という主張は工数データと食い違います。

問題が表れるのは「工期（カレンダー上の時間）」と「手戻り」です。工期では上流の比重が相対的に重く、作業が止まって返答を待つ時間が前半に偏ります。そして上流の欠陥を後工程で直すほど、修正コストは数倍から数十倍へと膨らみます（出典：qbook.jp）。倍率は媒体により幅がありますが、後ろにいくほど高くつく傾向は一致しています。

さらに多くの開発は外部委託で進みます。IPAの分析では外注の工数比率が50〜90%を占めるプロジェクトが多数で（出典：ipa.go.jp）、発注側と開発側が分かれている以上、確認の往復は構造的に発生します。

公平を期すと、遅延の原因は確認待ちだけではありません。技術検証の甘さ、権限移譲のない組織体制、契約上の問題など複数要因が複合します（出典：vnext）。実際、ITプロジェクトの成功率は約52.8%、工期どおりに終わったのは39.1%、品質に満足できたのは28.9%という調査もあります（出典：xtech.nikkei.com）。確認待ちは「唯一の原因」ではなく「圧縮できる主要因の一つ」です。当社が手を入れられるのは、このコミュニケーション部分です。

AIエージェント直結で工程を圧縮する

当社のアプローチは「1つの脳、300人のAIプログラマ」です。1人のエンジニアがAIエージェント群を直接動かし、確認サイクルそのものを短くします。

従来は、要件の質問→担当者へ連絡→返答待ち→反映、という往復が工程ごとに何度も発生し、止まった時間が工期を押し上げます。当社は、判断する人とAIエージェント群を直結させ、この往復の待ち時間を圧縮します。固めた要件をその場でモックアップに反映し、認識のズレをコードで確かめながら進めます。

正直にお伝えします。AIで圧縮できるのはコミュニケーションと実装のサイクルであり、技術検証や契約調整まで魔法のように解決するわけではありません。要件が固定済みの大規模・規制系プロジェクトでは、前述のとおりウォーターフォールが合理的な場面もあります。当社は「AIが何でも速くする」とは言いません。確認待ちという特定のボトルネックを、検証可能なかたちで縮める——それが立ち位置です。仕組みや進め方はAI駆動システム開発のサービス内容で説明しています。

その正直さを形にしたのが、初回相談から動くモックアップを無料で構築する取り組みです。資料や口頭ではなく、動く画面を見ながら認識をすり合わせる——これが確認待ちを最初から減らす一番の近道です。

よくある質問

システム開発の期間はどれくらいかかりますか？

規模に強く依存します。小さな業務ツールなら数週間、複数部署にまたがる基幹システムなら年単位になることも。期間を縮める最大のレバーは、要件をどれだけ早く固め、確認待ちをどれだけ減らせるかです。当社は初回から動くモックアップで要件確認を前倒しします。

要件定義は発注側が用意すべきですか？

完璧な仕様書は不要です。ただし「何を解決したいか」「誰がどう使うか」は発注側にしか分からない情報です。要件定義は発注側が主導し、開発側が整理を手伝う共同作業と考えてください。ここの曖昧さが失敗の根本原因になります（出典：hnavi.co.jp）。

ウォーターフォールとアジャイルはどちらを選ぶべきですか？

要件が固定で多部署の承認統制が必要ならウォーターフォール、仕様が変わりやすく小〜中規模ならアジャイルが向きます（出典：sackle.co.jp）。優劣ではなくプロジェクトの性質で選びます。

AIで開発すると品質は下がりませんか？

下げないために、当社はテスト工程を省きません。IPAデータでもテストは工数の約32%を占める品質の要です（出典：ipa.go.jp）。AIが速めるのは確認と実装のサイクルであり、品質確認の手順は残します。

発注全体の判断軸はシステム開発会社の選び方と費用相場、工程ごとの費用感はシステム開発費用の相場、AIで工程を圧縮する仕組みはAIエージェント開発で詳しく解説しています。

自社のプロジェクトが今どの工程で、どこに時間が溶けているか——それが見えたら、まずは動くモックアップで確かめてください。AI駆動システム開発のサービス内容をご確認のうえ、お問い合わせからご相談ください。