お役立ち情報
システム開発の工程を徹底解説！要件定義から運用まで失敗しない進め方と注意点

システム開発お役立ち情報

公開日:2026.01.23　更新日:2026.01.27

システム開発の工程を徹底解説！要件定義から運用まで失敗しない進め方と注意点

監修者

取締役斎藤裕一

1 システム開発の工程とは
2 システム開発の主な工程・流れ
3 システム開発工程のモデルの種類
4 システム開発の工程で注意すべきポイント
5 まとめ：システム開発を成功させるために発注者が意識すべきこと

システム開発は、「要件定義が重要」「途中でトラブルが起きやすい」と言われる一方で、
どの工程で、発注者が何を意識すべきかまで具体的に理解できているケースは多くありません。

実際には、システム開発の失敗の多くは、設計や開発そのものではなく、要件定義や設計段階での認識ズレ、関与不足によって引き起こされています。

本記事では、システム開発の全体工程（企画・構想〜要件定義、設計、開発、テスト、運用）を整理したうえで、各工程で発注者が注意すべきポイントや、よくある失敗とその対策をわかりやすく解説します。

「これからシステム開発を検討している方」
「過去にプロジェクトがうまくいかなかった経験がある方」
にとって、失敗を防ぐための実践的な指針となる内容です。

ITコンサルティングやシステム開発を一気通貫してご相談・ご依頼したい人はこちらのバナー

システム開発の工程とは

ここではシステム開発の工程とはについて解説していきます。

そもそもシステム開発における工程とは？

ここでいう「工程」とは、システム開発をおこなううえであらかじめ決まっている、必要なプロセスを指します。つまり、要件定義や外部設計、内部設計、プログラミングなどの、システム開発をおこなうために必須となる一つひとつのプロセスを指します。

工程に沿ってシステムを開発していく目的は、計画通りスムーズに開発を進行させることです。開発プロセスを工程に分割し、一連の流れに沿って進めることで、品質や進捗状況を管理しやすくなります。

実際の開発では、一つひとつの工程に期限や品質の基準などを設定しておき、決められた基準を守るように管理していきます。工程を理解し、それぞれの工程で管理をおこなうことにより、仕事の期限を守りつつシステムの質を確保できるのです。

システム開発における工程には厳密なルールはないため、分割の仕方などは企業ごとに異なります。

発注の際に工程への理解があると良い理由

先述のとおり、自社ではシステム開発をおこなわずに開発会社へ発注する場合であっても、工程への理解があるほうがいいです。なにもわからないままではシステム開発にどのように関わればいいのかわからず、開発工程を完全に委ねてしまうことになりかねません。

この状態では必要なチェックができなかったり、開発会社にうまく意図が伝わらないなどのコミュニケーションの問題が発生したりといったトラブルにつながります。うまく質問や確認ができなかった結果、完成に近づいた時点で大幅な修正が必要になってしまい、大幅に納期が遅れるなどの問題が出てきてしまいかねないのです。

このほかにも、「仕様変更」はシステム開発においてよく問題になっています。仕様変更とは、システム開発の工程がどんどん進んで言った段階で、伝えたいことに漏れがあるなどして途中で「やっぱりこれを変更したい」といわれることです。

システム開発では、はじめの工程で要件定義をおこない設定を進めていきます。後々の開発工程で仕様変更があると、計画どおりに進行できなくなって開発者を混乱させます。

その結果、見直しや変更が必要になったことによる納期の遅延や追加費用の発生などにつながっていく可能性があるのです。

発注の際に工程への理解がないと、途中で変更のリクエストをしても「ほんの一部分を変更させるだけなら問題ないだろう」と認識されてしまいます。

反対に、発注者側にも正しい工程への理解があれば、トラブルなくしっかりとシステム開発を行ってもらえるでしょう。

もし、仕様変更が必要になった場合には、リスクを把握したうえでそれでも仕様変更をすべきかどうか確認することをおすすめします。

システム開発における工程別の工数比率

工程の理解を深めるために、システム開発工数全体に対してそれぞれの工程がどれほどの工数比率であるのかをチェックしていきましょう。日本情報システム・ユーザー協会（JUAS）が発表した「ソフトウェアメトリックス調査２０２５」によると、２０１８～２０２０年に集めたデータでの実績工数比率は、以下のとおりです。

・要件定義：２０％未満

・設計から統合テスト（外部設計、内部設計、プログラミング、単体テスト、結合テスト、システムテスト）：６０％以上９０％未満

・運用テスト：２０％未満

こちらのデータに対して、望ましいと感じている工数比率として集めたデータは、以下のとおりでした。

・要件定義：４０％未満

・設計から統合テスト：３０％以上８０％未満

・運用テスト：２０％以上３０％未満

システム開発する際に、今よりも設計から統合テストの割合をおさえて、要件定義や運用テストの時間をとったほうがいいと感じる人が多いという結果です。しかし、実際には設計から統合テストの段階で工数が多くなっているのが実態なのです。

参照：ソフトウェアメトリックス調査２０２５

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

システム開発は、大きく「上流工程」と「下流工程」に分けられます。

上流工程は、企画・要件定義・基本設計など、システムの目的や要件、仕様の方向性を定める工程です。

一方、下流工程は、詳細設計・開発・テスト・リリースといった、決定した内容を実際に形にする工程を指します。

区分	主な工程	開発者の関与度
上流工程	企画・構想、要件定義、基本設計	高い（主体的な関与が必要）
下流工程	詳細設計、開発、テスト、運用	中〜低（確認・判断が中心）

特に上流工程は、プロジェクト全体の方向性を決める非常に重要な工程であり、その出来がプロジェクトの成否を左右すると言っても過言ではありません。発注者が業務課題や目的を十分に整理しないまま開発を進めると、後工程での仕様変更や認識のズレが発生しやすく、追加コストや納期遅延につながるリスクが高まります。

そのため、要件定義や基本設計の段階では、ベンダー任せにせず、発注者自身が意思決定に関与することが重要です。

一方、下流工程では、設計内容を正確に実装し、品質を確保することが主な役割となります。上流工程で合意形成ができていれば、下流工程はスムーズに進みます。

しかし、テストで想定外の不具合が発見されると、修正と再テストに追われ、納期遅延につながるリスクがあります。

システム開発で使用頻度の高い略語

要件定義では、クライアントと開発会社がそれぞれの話を理解して、しっかりとコミュニケーションをとることが重要です。依頼する側にとっては専門用語を理解しやすいように、受注する開発会社側にとってはクライアントに話を説明しやすいように、以下の使用頻度の高い略語の意味を確認しておきましょう。

また本記事では代表的な用語を取り上げていますが、より詳細な情報を知りたい方はIPA（独立行政法人情報処理推進機構）が公表するガイドライン等を一読すると学びが多いはずです。

参考：IPAの詳細はこちら

＜システム開発における代表的な開発略語＞

SP……企画
SA……要求分析・システム方式設計要求分析
RD-UI……要件定義（RDのみで要件定義を意図することもある）
UI……基本設計
BD……基本設計
SS……構造設計
FD……機能設計
DD……詳細設計
PD……詳細設計・プログラム設計
PS……詳細設計
M……製造
UT……単体テスト
CD……コーディング
PG……プログラミング
IT……結合テスト
ST……システムテスト
PT……総合テスト
OTO……運用テスト

システム開発の主な工程・流れ

システム開発の主な工程や流れは以下のとおりです。

企画・構想：開発前に行う
要件定義：打ち合わせと要件定義書の作成をおこなう
外部設計・基本設計：UIを設計する
内部設計・詳細設計：プログラムを設計する
プログラミング：実際にシステムを開発する
単体テスト：正しい動作か確認する
結合テスト：プログラム同士を連携させてテストする
システムテスト：全体の総合的なテストをおこなう
運用テスト：実環境に近い状況でテストをおこなう
システム移行・リリース：システムを公開し、必要であれば移行作業をおこなう
運用・保守：安定稼働させるために対応していく

それぞれの工程ごとに、ポイントを詳しくチェックしていきましょう。

企画・構想フェーズ（開発前に行うこと）

企画・構想フェーズは、システム開発に着手する前段階で、「なぜシステムを作るのか」「何を解決したいのか」を明確にする工程です。
このフェーズが曖昧なまま進むと、要件定義以降で方向性がぶれ、開発途中の手戻りや追加コストが発生しやすくなります。

発注者側で整理しておくべき主なポイントは以下の通りです。

背景・課題の整理：現在の業務で発生している問題点や非効率な部分を洗い出し、「システム化によって何を改善したいのか」を明確にします。
目的・ゴールの設定：業務効率化、コスト削減、売上向上など、システム導入によって達成したい目的を定義します。
対象業務・利用者の整理：どの業務を対象とし、誰がシステムを利用するのかを整理することで、後工程での要件ブレを防ぎます。
概算スケジュール・予算感の検討：実現したい時期や想定予算を大まかに決めておくことで、現実的な開発計画を立てやすくなります。
体制・役割：企画・構想フェーズを進めていく体制と、各メンバーの役割を決めます（意思決定者や窓口を明確にすることが重要です）

この段階では、仕様を細かく決める必要はありませんが、課題・目的・優先順位を関係者間で言語化・共有しておくことが重要です。
企画・構想フェーズを丁寧に行うことで、要件定義以降の工程がスムーズになり、結果として開発全体の成功確率を高めることができます。

要件定義：打ち合わせと要件定義書の作成

システム開発を外注する場合、企画・構想でどのようなシステムを開発するのか固まったら、次は開発会社との打ち合わせをし、要件定義をします。

ここでは、打ち合わせでの注意点と、要件定義で決めるべきことをご紹介します。

打ち合わせ

クライアントと契約書を取り交わした後、もしくは契約締結を前提として要件定義工程に入ります。本工程ではクライアントと開発会社間で打ち合わせを行い、双方のディスカッションの中で得られた情報を基に要件定義書と呼ばれるドキュメントを作成します。

要件定義が明確でない場合、開発を進める際に盛り込むべき内容が曖昧になってしまいます。また、「言った・言っていない」といった水掛け論も、プロジェクトでは非常に発生しやすくなります。開発会社側はクライアントの要望をしっかりと確認し、作り上げるシステムの概要を決めていく必要があります。

打ち合わせの際に現場の代表者や責任者が参加せず、現場では使われない、いわば無用の長物となるようなリクエストをするケースがあります。

このような状況はシステム開発の手間がかかるだけではなく、現場で使いづらいシステムを開発してしまう危険があります。打ち合わせの際に伝える要望はできるだけ現場目線の声をベースに進めていくべきでしょう。

要件定義書の作成

要件定義書とは、システム開発において、ユーザーが求める機能、性能、業務ルールなどを具体的にまとめた設計図となる書類です。

要件定義書は以下の4つをおさえる必要があります。※要件定義書の構成はプロジェクトによって異なりますが、一般的には以下の観点で整理されます。

機能名	特徴	具体例
機能要件	システムが実現すべき具体的な機能	・顧客の問い合わせを自動で分類し、担当部署に振り分ける・ユーザーがマイページでお気に入りの商品を登録できる
非機能要件	システムの応答時間やデータ処理能力などの性能	・ウェブページの表示速度は3秒以内・月間アクセス数が100万件を超えても安定して稼働
品質要件	システムの品質を確保するための基準（セキュリティや可用性など）	・システムの年間ダウンタイムは24時間以内とする・ユーザー認証は二段階認証を導入する
実行計画	システム開発に必要な工数やコスト、スケジュールを具体的に定める	・開発期間は6か月・各フェーズのマイルストーンを設定する

なお、要件定義工程についてより詳しい情報を知りたい方は以下のURLをご確認いただけたらと思います。

関連記事：システム開発の要件定義とは？欠かせない要素と進め方を解説

要求定義と要件定義の違い

要求定義とは、システム開発などで「顧客がシステムに何を求めているか（目的、課題、期待する成果）」を明確にし、開発側に伝えるためのもので「要求定義書」としてまとめられます。

要求定義と要件定義の違いを、具体例に沿って解説します。

要求定義：ユーザーインターフェースを重視し、初見でも使えるようにしてほしい
要件定義：左にメインメニューを置き、目的の画面まで2クリックで遷移する仕様とする

このように、発注者の要求を具体的な要件に変換する作業が要件定義です。

基本設計（外部設計）と詳細設計（内部設計）

ここでは基本設計と詳細設計について解説します。

基本設計（外部設計）

要件定義が完了した後、外部設計や基本設計、インターフェース設計などと呼ばれる工程に移ります。外部設計では、要件定義で決めた内容をもとに、ハードウェアの設計やシステムの操作画面のレイアウトなど、搭載すべきものやシステムの特徴をより具体的に決定していきます。

ここでユーザーインターフェース（UI）を設計するため、ユーザー側の視点に立って使い勝手のいいシステムになるよう検討することが重要です。見栄えの良さだけではなく、効率よく動き、操作性が高く、アクセスしやすいシステムになるように設計を進めます。

この工程では、基本設計書やシステム構成図、インターフェース設計書、外部設計書、方式設計書、テーブル定義書、ファイル定義書が成果物です。また、外部設計の工程では、開発期間や費用についてクライアント側と話し合います。

詳細設計（内部設計）

内部設計や詳細設計と呼ばれるのが、システムの中身である機能や動作の設計をおこなう工程です。開発言語やAPIとの連携、サーバー・データベース、プログラミングのルールの策定など、主に技術的な要素を設計していきます。この工程で作成するのは、単体テスト仕様書や詳細設計書などです。

外部設計や内部設計というとおり、外部設計では人の目に見える部分を設計し、内部設計は人の目に触れないものを動かすために必要な部分を設計します。内部設計をおこなうことで、外部設計で設計した内容をシステムに正しく反映できるようになるのです。

設計工程における成果物一覧

設計工程では、要件定義で合意した内容をもとに、システムの仕様を具体化するための成果物を作成します。

これらの成果物は、開発会社だけでなく、発注者にとっても「認識が合っているか」「要件が正しく反映されているか」を確認する重要な判断材料となります。

・基本設計における成果物

成果物名	特徴
業務フロー図	どのような業務で利用するのか、業務の流れとシステムの関係性を記したもの
システム構成図	システム全体の構成を図で表したもの
画面一覧	システムの必要画面を一覧としてまとめたもの
実行計画	システム開発に必要な工数やコスト、スケジュールを具体的に定める
インターフェース図	要件定義やシステム構成図でまとめた資料をもとにどの情報をどのシステムに連携するかを決定したもの
帳票一覧	帳票を出力するにあたって必要な項目、レイアウトを示したもの ※帳票がないシステムでは不要
コード一覧	システム内で扱うデータ（区分や属性など）を識別するために割り当てる「符号（コード）」のルールや具体的な値を整理・定義したもの
CRUD図	データベースのテーブルに対して、各機能がどの操作（作成・参照・更新・削除）を行うかを整理したもの
バッチ一覧	通常業務とは別に、定期的・自動的に実行される処理の一覧
データベース設計書	業務プロセスなどをもとに保存するデータを一覧化したテーブル定義書やデータベースの関係性をまとめた設計図
非機能要件一覧	可用性、性能/拡張性、運用/保守性、セキュリティなどをまとめた要件一覧

なお、上記成果物の一覧は以下のURLでも解説しています。

関連記事：基本設計における成果物とは？開発工程の流れや注意点を含めて解説

・詳細設計における成果物

成果物名	特徴
状態遷移図	システムの状態が遷移する様子を図に書いて図形や矢印などで表現したもの
シーケンス図	アクティブ図よりもシステムの内部処理に着目して、より詳細に表記したもの
画面遷移図	WEBアプリケーションやその他業務システムの開発において、どのように画面遷移が行われるかを表した図 ※基本設計段階で作成することもある
クラス図	プログラミングをする際の元データとなる、システムを構成するクラス関係を表すもの
アクティブ図	ユーザー操作とシステム処理の流れがわかるもの
モジュール構造図	構成するモジュールがどのように分割されて、各モジュールがどのような処理を行うのかを示した図
入出力設計書	各機能でどのような情報がインプットとして用いられ、どのような情報がアウトプットとして出てくるかを表したもの
バッチ処理設計書	定期的な処理や大量データの一括処理を行うプログラムの仕様を詳細に定義したもの
テスト設計書	単体テストや結合テストでベースとなるテストの指針や骨格を定めたもの
データベース物理設計書	論理設計で決めたデータ構造をデータベース管理システムに合わせて、具現化したもの
外部インターフェース設計図	社内外の他システムと連携するときの仕様を定義したもの
IPO（処理機能記述書）	システムの機能・ビジネスロジックの処理内容を入力（Input）、処理（Process）、出力（Output）の３形式で表現した図式

なお、上記成果物の一覧は以下のURLでも解説しています。

関連記事：詳細設計の成果物は何が重視される？進め方や注意点を紹介

発注者は、すべての成果物を技術的な視点で理解する必要はありませんが、「要件定義で決めた内容が反映されているか」「業務上の使い勝手に問題がないか」といった観点で確認することが重要です。

設計工程での認識ズレを早期に発見できれば、開発フェーズ以降の手戻りや追加コストを大きく抑えることができます。

プログラミング：実際にシステムを開発

プログラミングの工程では、実際にシステムを開発していきます。これは、コーディングや開発とも呼ばれる工程です。システム開発においては、これまでの「要件定義」や「基本設計」、「詳細設計」の工程を「上流工程」と呼び、プログラミング以降の工程を「下流工程」と呼びます。

内部設計の際にプログラミングの型をある程度開発しますが、この工程では実際に作り上げていくフェーズです。この工程ではプログラミング言語を用いますが、使用する言語の種類によって特徴が異なってきます。プログラミングの際はシステムごとに必要となるプログラミング言語が異なるため、さまざまな言語を使い分けながら進めていくことがあります。

単体テスト：正しい動作の確認

単体テストは、プログラムが正しく動作するかをチェックする工程です。詳細設計の際に作成しておいた単体テスト仕様書をもとに、動作確認をおこないます。

テストにはいくつか種類があり、はじめにおこなうテストは、個々のプログラムが要件定義で定めた内容どおりに動くかどうかのチェックです。もしも正常に反応しなかった場合には、どのように反応したのかを確認し、問題があった部分を修正します。

結合テスト：プログラム同士の連携のテスト

結合テストは、プログラム同士を連携させて、正常に反応するかどうかをテストする工程です。単体ではうまくいっても、複数のプログラムが組み合わさると干渉によって正常に作動しないケースがあります。

たとえばデータの受け渡しをしてみるなどで、プログラム同士で連携がとれ、基本設計書で定めた機能が再現できているかどうかを検証するのです。

システムテスト：全体の総合的なテスト

システムテストでは、全体の総合的なテストをおこないます。この工程でのテストとは、すべてのプログラムを合わせた状態で正常に作動するのかどうかをチェックしているものです。

システムテストでおこなうのは、動作確認だけではありません。アクセスへの耐久性や処理速度など、実際にユーザーが利用する際に問題がないかを確認していきます。

受入テスト（UAT）・運用テスト

運用テストの工程で実施するのは、実際にシステムを利用する環境に近いものを用意し、そのなかで正常に反応してくれるかどうかという、実用性を重視したテストです。システム移行やリリース前の最終テストとなるため、ありとあらゆる状況を検証していきます。

テストできる環境を早めに整備しておけるように、外部設計が終わったあたりの段階から準備を進めていくといいでしょう。

システム移行・リリース：新システムを公開

先述の各テストで徹底的に検証し、現場での運用に問題がない状態だと判断できれば、システム移行やリリースをおこないます。市場にリリース（公開）するときは、システムのすべての機能が一度に公開されるわけではなく、クライアント側のビジネス戦略に応じて順次リリースされていくという流れです。

開発したものが社内システムなどで、もしも既存のシステムを使っている場合には、旧システムから新システムへの移行作業をおこないます。この場合にも、一気に切り替えていく一斉移行の方法と、少しずつ切り替えていく順次移行の方法から選択可能です。

運用・保守：安定稼働させるための対応

システムを実際に使い始めたら、安定稼働させるために運用・保守の工程として対応していきます。その後もしもバグがあれば正常に動くようにする、アップデートを実施したりなどの対応をとっていくのです。これによって、システムを使い続けられるようにしていけます。

システム開発工程のモデルの種類

システム開発工程のモデルには複数の種類がありますが、今回は以下のモデルをチェックしていきましょう。

ウォーターフォール開発
アジャイル開発
V字モデル
XP（ペアプログラミング）
スパイラル開発
MVP開発・プロトタイピング開発
DevOps（呼び方：デブ・オプス）
ハイブリッド開発

ウォーターフォール開発とアジャイル開発は、開発工程の基本となる２モデルです。V字モデルは、開発工程とテスト工程をリンクさせ、ウォーターフォール開発を進化させたモデルだといわれています。それぞれのシステム開発工程モデルの種類について、特徴を解説します。

ウォーターフォール開発

ウォーターフォールとは、上流から下流へ水が流れていくことを指す表現です。つまり、上流工程から下流工程に向かって、一定の流れで進めていく開発方法を表しています。決められた順に工程を進めていく方法で、1つの工程が完了しないうちには次の工程に入ることはありません。

進捗状況の把握が容易で、高い品質のシステムが作りやすいのがメリットです。ただし、素早いシステム開発は苦手で、仕様変更へ対応する難易度が高いというデメリットもあります。

アジャイル開発

アジャイル開発は後戻りすること（仕様変更）を前提としてプロジェクトを進行する開発方法です。ウォーターフォールとは違ってはじめに全体を綿密に設計せず、１つの工程をしっかりと完成させる前に進めていくため、各工程をスピーディに進行させられます。

また、工程の後戻りができるため、途中での仕様変更に対応しやすい開発方法です。ただし、工程の進捗状況の管理が難しいこと、対応できる開発会社が少ないという点がデメリットです。

アジャイル開発の指針となる手法のひとつに、スクラム開発と呼ばれるものがあります。スクラム開発はチームで開発する手法で、メンバーそれぞれが違った役割を果たしつつ、しっかりとコミュニケーションを取って開発していく方法です。スクラム開発は、今後も更新が必要なシステムなどを開発する案件に適しているといわれています。

V字モデル

V字モデルでは、プログラミングの工程までウォーターフォールと同じく上流から下流へ流れるように進められます。プログラミングが終わってテストの段階になってからは、テスト工程と開発工程とでそれぞれの工程をリンクさせて、効率的に検証作業を実施する方法です。

単体テストでは内部設計のチェック、結合テストでは外部設計のチェック、システムテストで要件定義の内容の実装をチェックします。このように、折り返して一つひとつ上流にのぼりながら工程を確認していくため、V字モデルといわれています。

テストする内容を明確にできるため作業進捗がわかりやすく、テスト工程で手戻りのリスクを軽減できるという点がメリットです。

スパイラル開発

スパイラル開発は機能ごとに開発工程を繰り返す開発方法で、アジャイル開発と似ています。アジャイル開発との違いは、機能のリリース時期や重視するポイントです。

アジャイル開発は機能ごとに開発を完成させてその都度リリースするため、サービスを稼働させながら開発を進めていきます。スパイラル開発でも機能ごとに工程をおこなうものの、機能は動作確認のためのプロトタイプとして開発していきます。

その後クライアントレビューを確認して改善しつつ、全ての機能の実装が完了してからリリースすることが大きな違いです。

アジャイル開発はスパイラル開発と比べて計画的に進められるという点がメリットです。一方、スパイラル開発はより品質を重視して開発できるというメリットがあります。

ただし、スパイラル開発は開発にコストがかかるため、アジャイル開発のほうが普及している傾向があります。

MVP開発・プロトタイプ開発

プロトタイピング開発手法とは、早い段階で簡易版であるプロトタイプ（試作品）を開発し、クライアントからのフィードバックを確認してから完成させていく開発手法です。

はじめの打ち合わせの段階でいろいろと確認を取っていても、クライアントがイメージできていなかったり、使ってみてから考えたかったりするケースはよくあります。こんな場合には簡易版を使って確認してみると実際の完成イメージがつかみやすくなるでしょう。

そのため、仕様が明確に決められていない場合や、クライアントが発注に慣れていないケース、操作性が重要なものの開発には、プロトタイピング開発手法がおすすめです。

プロトタイピング開発手法では早期にプロトタイプを試して完成イメージを確認するため、どのようなシステムを開発するのかという認識のズレが回避できます。また、技術的に実装が難しい機能などの問題点が早い段階で確認でき、不具合を回避しやすくなる点もメリットです。

ただし、完成品だけではなくプロトタイプも作るため、コストがかかることや開発者の負担が大きくなりやすいというデメリットもあります。

DevOps

DevOpsとは、Development（開発チーム）とOperations（運用チーム）が連携しあう開発手法で、それぞれの単語を組み合わせて作られた言葉です。連携してシステム開発することによって、余分な工数を削減して素早く柔軟にかつ高い品質で対応できる仕組みを作れます。

情報共有の促進や、それぞれのチームが尊重しあえる組織文化を構築すること、テスト効率化のためのツール活用などが、DevOpsの重要なポイントです。

DevOpsは開発手法としてだけではなく、概念として使われることもある言葉です。最近はアジャイル開発が多くなったこともあって、開発チームは改善と修正を繰り返しています。しかし、運用チームはシステムを安定稼働させるために何度も変更したくないという思いがあり、重視するものが違う分反発しあってしまうことがあるものです。

先述したとおり、お互い協力しあったほうがいいシステムが開発できます。そのため、DevOpsが注目されるようになったのです。

ハイブリッド開発

ハイブリッド開発とは、ウォーターフォール開発とアジャイル開発など、複数の開発手法を組み合わせたものです。

例えば、開発の進め方として、ハードウェア開発や外部連携はウォーターフォールで進め、ユーザーインターフェースなどソフトウェアの部分はアジャイルで進めるケースです。

これによって、ウォーターフォール開発の長所である「計画性」とアジャイル開発の長所である「柔軟性」を両立させることが可能です。

一方で、二つの異なる手法を並行して管理することから、管理コストの増大、手法間でのギャップが生じやすいことがあげられます。

システム開発の工程で注意すべきポイント

ここではシステム開発の工程を進めるうえで、よくある失敗事例と対策をご紹介していきます。

要件定義でよくある失敗と対策

要件定義は、システム開発全体の成否を左右する重要な工程ですが、発注者側の関与不足や認識のズレにより、さまざまな失敗が起こりやすい工程でもあります。ここでは、要件定義でよくある失敗と、その対策について解説します。

目的やゴールが曖昧なまま要件定義を進めてしまう

「何を解決したいのか」「導入後にどうなっていれば成功なのか」が整理されていないと、要件が場当たり的になり、後工程での仕様追加や変更が頻発します。

【対策】：企画・構想フェーズで整理した課題や目的を要件定義書に明文化し、関係者間で合意を取ることが重要です。

現場の意見が十分に反映されていない

意思決定者や管理職の意見だけで要件を決めると、実際の業務と合わず、使われないシステムになるリスクがあります。

【対策】：現場担当者へのヒアリングを行い、業務フローや実際の運用を踏まえた要件整理を行います。

要望と要件が混在してしまう

「できたら嬉しいこと」と「必ず必要な機能」が整理されていないと、コストやスケジュールが膨らみやすくなります。

【対策】：要求事項に優先順位を付け、必須要件と追加要件を明確に分けて整理します。

開発会社に任せきりにしてしまう

要件定義をすべて開発会社任せにすると、認識のズレに気づかないまま設計・開発が進む可能性があります。

【対策】：要件定義書の内容を発注者自身が確認し、業務視点で違和感がないかを必ずチェックすることが重要です。

要件定義の段階でこれらの失敗を防ぐことができれば、設計・開発工程以降の手戻りを減らし、プロジェクトをスムーズに進めることができます。

設計・開発工程で起こりやすい問題

設計・開発工程では、要件定義で整理した内容をもとに、具体的な仕様・実装へと落とし込んでいきます。このフェーズでは、以下のような問題が起こりやすくなります。

設計内容と要件定義の乖離

まず多いのが、設計内容と要件定義の乖離です。要件定義書に記載されていた背景や目的が十分に共有されていない場合、設計が「作りやすさ」や「技術的都合」を優先した内容になり、発注者の意図とずれてしまうことがあります。

【対策】：設計レビューの場で「要件との対応関係」を明示し、なぜこの設計になっているのかを確認することが重要です。

設計の不備・不足

次に、設計の粒度不足・過不足もよくある問題です。設計が粗すぎると、開発者ごとに解釈が分かれ、品質のばらつきや手戻りが発生します。一方で、過度に細かい設計は、変更への対応力を下げ、開発スピードを落とす要因になります。

【対策】：プロジェクトの規模や体制に応じて、「どこまで設計で固めるか」を事前に合意しておくことがポイントです。

仕様変更ルールが曖昧

仕様変更への対応ルールが曖昧なまま進むこともリスクです。設計・開発フェーズでは、業務理解が進むことで追加要望や変更が出やすくなります。これを場当たり的に受け入れると、スケジュール遅延やコスト超過につながります。

【対策】：変更管理のルール（影響範囲の確認、承認フロー、費用・納期への反映）を明確にしておくことが重要です。

テスト・運用フェーズでの注意点

テスト・運用フェーズは、「作ったシステムが本当に使えるか」を検証し、実運用へとつなげる重要な工程です。このフェーズでも、発注者側で意識すべき注意点があります。

テストの観点の不足

まず注意したいのが、テスト観点の不足です。開発側のテストは、仕様通りに動くかという観点が中心になりがちで、実際の業務フローや例外ケースが十分に考慮されていないことがあります。

【対策】：発注者側としては、実業務を想定したシナリオテストや、現場担当者による受入テストを実施することが重要です。

運用を見据えていない

運用を見据えた確認不足もよくある課題です。操作性や画面遷移、エラーメッセージなどは、開発中には見過ごされやすいものの、運用開始後の負担に直結します。

【対策】：「誰が・どの頻度で・どのように使うのか」という視点で、運用時の使いやすさを確認することが求められます。

運用・保守体制が不明確

さらに、運用・保守体制の不明確さもリスクとなります。障害発生時の連絡先や対応範囲、改修時の進め方が曖昧なまま運用を開始すると、トラブル時に混乱が生じます。

【対策】：運用開始前に、保守契約の範囲、対応時間、役割分担を整理しておくことが重要です。

まとめ：システム開発を成功させるために発注者が意識すべきこと

システム開発を外注する際は、開発会社の技術力だけでなく、発注者側の関わり方がプロジェクトの成否を大きく左右します。

特に、企画・構想から要件定義、設計・開発、テスト・運用に至るまで、各工程での判断や確認を怠ると、後工程での手戻りやコスト増加につながりやすくなります。

重要なのは、「何を作るか」だけでなく、「なぜ作るのか」「誰のために使うのか」を一貫して共有し続けることです。

企画・構想フェーズでは、課題や目的を言語化し、関係者間で認識を揃えること。
要件定義では、要望と要件を整理し、優先順位を明確にすること。
設計・開発工程では、要件とのズレがないかを確認し、変更ルールを明確にすること。

そして、テスト・運用フェーズでは、実業務を想定した検証と、運用・保守体制の整理が欠かせません。

これらを意識して進めることで、「作ったが使われないシステム」ではなく、現場で本当に活用され、事業や業務に貢献するシステムを実現しやすくなります。

システム開発は一度きりの作業ではなく、導入後も改善を続けていく取り組みです。発注者自身が各工程のポイントを理解し、開発会社と適切にコミュニケーションを取ることが、開発成功への近道と言えるでしょう。

監修者

斎藤裕一
取締役

＜略歴＞
大阪大学工学部、大阪大学大学院情報科学研究科修了。
国内最大手IT企業の株式会社NTTデータで大手金融機関向けに債権書類電子化システム、金融規制・法規制対応システムの要件定義・インフラ設計・開発・構築・複数金融サービスのAPI連携等を手がける。その後、株式会社GeNEEの取締役に就任。

＜資格＞
基本情報技術者試験、応用情報技術者試験、Oracle Master Platinum等多数

この記事をいいねと思ったら！