テクノロジー部部長の工藤です。
今回は「システム開発を依頼したいけど、どのような流れで進めるんだろう？」「システム開発にアサインされたけど、全体の工程が知りたい」という方に、システム開発の全工程と進め方を解説します。
最低限の開発の工程を理解しておくと開発がスムーズに進み、リスクの回避ができます。システム開発を成功させるために、全体の流れを把握していきましょう。
システム開発を依頼できる企業は国内に多数あるため、どの企業に依頼すればいいか迷ってしまいますよね。最初のご相談相手として、業界歴10年以上のベテランPMがプロジェクトに伴走する弊社LIGはいかがでしょうか？
- ベテランPMが事業戦略など上流工程から支援
- ノーコードツール開発により保守運用しやすいシステムを提供
- 125名超の海外人材を活用した多彩な開発体制に対応
「こんなシステムは対応できる？」「まずは見積もりがほしい」などお気軽にご連絡ください。翌営業日以内に折り返しご連絡いたします。
関連記事：おすすめのシステム開発会社まとめ
目次
※編集部注:2021年6月に公開された記事を再編集しました。
システム開発の工程・進め方
システム開発は一般的な工程は以下の通りです。要件定義や基本設計などを上流工程、コーディングやテストなどを下流工程と分類します。
| 工程 | 概要 | 全工程に対する 工数比率 |
|---|---|---|
| 要件定義（要求定義） | 実装すべき機能や納期、 必要な人員（工数）などをまとめる |
15〜20% |
| 基本設計（外部設計） | システムのおおまかな構造やインターフェース、 データの保存場所や取得方法などを設計する |
10〜15% |
| 詳細設計（内部設計） | 外部設計で定義されたシステムの詳細な 実装方法（プログラミング方法）を計画する |
10〜15% |
| 開発（プログラミング） | 設計内容を実装する | 30%程度 |
| テスト | 作成したプログラムが正常に動くかをテストする | 20~25% |
| システム移行（リリース） | 旧システムから新システムに切り替える | 数% |
| 運用・保守 | システムの稼働が停止しないように監視や、 不具合が起きたときの改修などをおこなう |
-（継続的に実施） |
フェーズごとの作業内容や円滑に進めるための注意点について詳しくみていきましょう。
要件定義（要求定義）
要件定義とは、そのシステムを開発する目的に基づいて実装すべき機能や納期、必要な人員（工数）などをまとめた設計図のようなものです。
このフェーズでは、ユーザーのニーズを明確に把握し、システム開発の目的とスコープ（機能実現するものと機能実現しないものを区分けする作業）を定義します。
ここで定義する機能は、主に「機能要件」と「非機能要件」の2種類に分けるのが一般的です。
- 機能要件：発注者（クライアント）から求められるシステムの機能のこと
- 非機能要件：ユーザービリティ、性能、拡張性、セキュリティなどの機能以外の要件のこと
要件定義は、一般的に発注者側の責任で行うべきとされることが多いのですが、知見がない場合は要件定義が不十分になり、納期の遅れや費用の増大などのトラブルが生じることもあります。
そのため、発注する側に知見がない場合は、開発会社が要件定義の支援を業務として行ってくれるのかなども事前に確認をしておくとよいでしょう。
- 要件定義で得られる成果物
- 要件定義書、ユースケース図など
基本設計（外部設計）
基本設計では、要件定義の内容をもとに、システムの大まかな構造や画面などの見た目（UI、ユーザーインターフェース）、データの保存方法や取得方法などを設計します。
ここでは、要件定義の内容を差異なく反映させることが大切で、そのためには開発チームと綿密に連携する必要があります。
基本設計は発注者と開発会社が意見のすり合わせをできる最後の工程なので、打ち合わせではしっかりと内容を詰めていくことが重要です。
- 外部設計で得られる成果物
- 外部設計書、機能仕様書
詳細設計（内部設計）
詳細設計とは、基本設計で定義されたシステムの詳細な実装方法（プログラミング方法）を計画するフェーズです。主にシステム開発会社が担当します。
基本設計ではユーザー側からの視点が求められますが、内部設計においては各モジュールやコンポーネントの具体的な動作やデータ処理方法など、開発者側からの視点で設計をします。
- 内部設計で得られる成果物
- 画面遷移図、クラス図、シーケンス図、 状態遷移図、 アクティブ図、入出力設計書、バッチ処理設計書、データベース物理設計書など
開発（プログラミング）
詳細設計まで行えたら、コンピュータへの指示を記述していきます。この時、コンピューターは人間の言葉をそのまま理解できないため、コンピューターが理解できる「プログラミング言語」を用いて命令を出します。
プログラミング言語にはいくつかの種類がありますが、開発するシステムの種類によって使う言語が異なってきます。
- システム開発に使用される開発言語の一例
-
- PHP（ピーエイチピー）：WebシステムやWebサービスの開発によく使われる言語
- Ruby（ルビィ）：Webサービスのバックエンド開発、Webアプリの開発によく使われる言語
- C言語、C++（シー言語、シープラプラ）：ゲーム制作や汎用系システムの開発によく使われる言語
テスト
続いて、作成したプログラムが正常に動くかをテストする工程です。テストは次の4つの工程に分かれます。
| 単体テスト | プログラミングのモジュール（対象単位）ごとのテストを行います。最初の要件定義で求められている基準を満たしているかを確認していきます。 |
|---|---|
| 結合テスト | 複数のプログラムを組み合わせた状態で、それらがうまく機能するかを検証する工程。先程の各モジュールを結合して、データの受け渡しなどでプログラム同士が正常に連携するかをテストします。 |
| 総合テスト | すべてのプログラムが、要件定義の通りに動くのかを確認する工程。このときに、アクセスへの耐久性や処理速度などもテストします。 |
| 運用テスト | 運用テストでは、実際にシステムを運用する環境下において、システムに不具合がないかをテストします。ここでは、実際に業務に取り入れることができるかという点をテストしていきます。 |
もしテスト段階でバグが見つかれば、開発チームが修正し、再度テストを行います。
システム移行（リリース）
テスト工程が完了したら、いよいよシステム移行をおこないます。システム移行とは、実際に使えるように、旧システムから新システムに切り替える工程です。
リリースが完了したら発注者側が動作確認などをおこない、問題がなければ納品完了となります。
運用・保守
納品したシステムが使われ続ければ、メモリの容量が少なくなったり情報が古くなったりするため、エンジニアによる運用・保守が必要です。
問題なく使い続けられるように、常に監視を行い、必要に応じてアップデートをしなくてはいけません。なお、運用・保守の工程は自社でおこなってもよいですし、難しい場合は外部に依頼することも可能です。
ここまでが一般的なシステム開発の工程となりますが、実は開発手法に違い工程に差が出ることがあります。
ここまで紹介してきた工程は、ウォーターフォールモデルと呼ばれる開発手法ですが、近年ではより柔軟に開発ができるアジャイルモデルでの開発も増えてきています。
次項目では、アジャイル型の開発工程について見ていきましょう。
開発手法による工程・進め方の違い
開発に取り掛かる手順には、いくつかの種類がありますが、代表的な開発モデルとしては、ウォーターフォールやアジャイルというモデルがあります。
システム開発の工程は、開発手法により各工程をどのように進めていくかが変わってくるため、ここからはそれぞれの違いをみていきましょう。
ウォーターフォール開発の工程
ウォーターフォールモデルとは、ここまで紹介したような開発工程を、1つずつ順番に完了させていく開発モデルです。まず初めに要件を厳密に固めてから、それに沿って工程ごとに開発を完了させていきます。
ウォーターフォールモデルは、プロジェクトによって例外はあるものの計画的に工程が進むため、進捗状況の把握が容易であることや、品質が担保しやすいという特徴を持っています。
- ウォーターフォールモデルの理解に欠かせない「V字モデル」とは
-
開発工程とテスト工程の対応関係を表したものを、「V字モデル」といいます。単体テストでは、詳細設計での内容が正しく実装されているのかをテストし、結合テストでは基本設計の内容、総合テストでは要件定義の内容、といったように進めることで、検証作業を効率よく完了させることができます。
アジャイル開発の工程
アジャイルとは、日本語で「素早い」という意味を持ち、とにかくスピード感のある開発方法です。機能ごとに「企画→開発→テスト→リリース」のサイクルを回していくので、開発を進めながら随時変更や修正をおこなうことができます。
この開発方法は、要件定義が明確にできておらず、まずは作りはじめてみて随時修正をしたいときには最適な開発方法です。スタートアップや新規事業に向いている開発モデルといえるでしょう。
※弊社LIGもアジャイル開発に対応しています。実績を聞きたいなど、どんなことでもお問い合わせください。
関連記事：アジャイル開発ができるシステム開発会社
ウォーターフォール開発やアジャイル開発についてより詳しく知りたい方は、以下をご覧ください。
ウォーターフォール・アジャイル開発の違いをわかりやすく解説！
ともぞう
工程表の作り方・スケジュールの立て方
システム開発を進めていく時は、WBS（Work Breakdown Structure：作業分解構成図）を作成して、管理していくことが一般的です。
WBSでは作業項目を一覧にして洗い出し、タスクの種類や粒度によってツリー構造で引き下げていくことで、抜け漏れなく各工程を進められます。
同時にガントチャートなどを作成し、プロジェクト全体を見える化してスケジュール管理をしていきます。
ガントチャートのイメージ画像
工程表のもっとも重要な役割は、納期管理です。納期の遅延は、後工程や顧客関係にも影響がでて、最悪の場合、売上損失・会社の信頼損失に繋がります。
工程表を作成して開発を進めていくことで、そのようなリスクを最小限に抑えることができます。
システム開発会社への依頼前にしておく準備
システム開発を外注する場合、以下のことを知っておくと会社選びやその後の開発が円滑にすすみます。
契約形態の種類を知る
システム開発の契約形態には、主に「準委任契約」と「請負契約」の2種類があります。
| 準委任契約 | 特定の業務を遂行することを定めた契約のこと。一定期間、一定数のリソースを確保できる。 |
|---|---|
| 請負契約 | 請負人が仕事を完成させることを約束し、それに対して報酬を支払う契約。プロジェクトが完了したら、チームは解散する。 |
開発したいシステムが既に決まっている場合は請負契約でもいいですが、開発を進めていく上で改善していきたい場合は、準委任契約の方が良いでしょう。開発したいシステムに合わせて、契約形態を決めましょう。
以下では準委任契約の中でも、外部にエンジニアチームをつくる「ラボ型開発（ラボ契約）」の特徴について解説しています。新規サービスなど、アジャイル型で開発を進めたい場合はラボ型開発をご検討いただくと良いかと思います。あわせてご覧ください。
ラボ契約（ラボ型開発）とは？請負・準委任との違いをプロが解説
Noriaki Iwata
- 💡柔軟な開発体制を希望する方へ
- 準委任契約によるラボ型開発に対応している会社は多数あるため、「日本語でコミュニケーションしたい」「信頼できる会社が知りたい」という悩みがつきものです。もしはじめてのご相談相手探しでお困りでしたら、オフショア歴約10年で国内ディレクターが窓口となる弊社LIGにぜひお問い合わせください。
提案依頼書（RFP）の準備をする
システム開発を行う際に、システム化の方向性やシステム化の計画を立てます。これは、RFP（提案依頼書）とも呼ばれています。発注側がシステム開発をする際に、必要なシステム構成に関しての要件や保証条件などが記載されているものです。
RFPの準備がしっかりできている場合は、発注先候補に対してオリエンテーションを開催し、見積りや提案までを比較的容易に受けることができます。しかし、多くの場合はRFPがなかったり、RFPの内容が不十分なケースがあるでしょう。その場合は、発注候補の開発会社と打ち合わせを重ねて、作りたいものをしっかり理解してもらうことが成功への第一歩となります。
複数社に見積もりをとる
作りたいものの方向性が決まったら、発注先候補の開発会社に見積もりをとります。このとき、1社だけだと価格の適正値がわからないため、必ず複数社に見積もりをとるようにしましょう。
その際に、RFPや提案依頼事項に対する回答（提案書及びお見積もり書）を取り寄せます。依頼事項に対してしっかりと回答がもらえているか、作業スケジュールや費用の概要を評価したうえで、発注先を決定しましょう。
発注先を決定したら、システム化の範囲の概要、費用、各当事者の役割分担等を契約書にて決定します。
システム開発の工程で使う略称一覧
システム開発の現場では多くの略称が用いられます。代表的な略称を覚えて、コミュニケーションロスを防ぎましょう。
| 工程 | 略語 | 英語表記 |
|---|---|---|
| システム企画 | SP | System Planning |
| 要求分析 | SA | System Architectural design System Analysis System Analyze |
| 要件定義 | RD | Requirement Definition |
| 基本設計 | BD | Basic Design |
| UI基本設計 | UI | User Interface |
| 外部設計 | ED | External Design |
| 詳細設計 | DD | Detail Design |
| 内部設計 | ID | Internal Design |
| 構造設計 | SS | System Structure Design |
| 機能設計 | FD | Function Design |
| プログラム設計 | PD PS | Program Design Program Structure Design |
| プログラミング | PG | Programming |
| コーディング | CD | Coding |
| 単体テスト | UT | Unit Test |
| 結合テスト | IT | Integration Test |
| 総合テスト | PT | Product Test |
| システムテスト | ST | System Test |
| 運用テスト | OT | Operations Test |
さいごに
システム開発の工程においては、ドキュメントの作成・管理も欠かせません。
ドキュメントは、コミュニケーションギャップを埋め、コミュニケーションの質を高めるための最重要な手段となります。人によって解釈が変わることがないよう、完結に必要事項が記載されていることが望ましいです。そのため、仕様や要件の変更が即座に反映されている必要があります。
全体の工程を理解したら、次はドキュメントの重要性をしっかり理解し、開発を成功に導きましょう！
システム開発で大切なのは企業の課題を正しく認識し、解決する最適な方法を提案してくれる会社を選ぶことです。そのためには豊富な経験とスキルを持った人材が多い企業に依頼するのが安心といえます。弊社LIGでは、
- 業界歴10年以上、大手外資系企業で大小さまざまなプロジェクトを担当したコンサルタント
- 数々の世界的アワードを受賞してきた、UIUXにも強いデザイナーチーム
- BubbleやFlutterFlowなどノーコードツールでの開発にも対応
など、ベテランPMや経験豊富なメンバーが貴社のニーズに応じたご提案をいたします。
「とりあえず見積もりをお願いしたい」という場合も気軽にご連絡ください。
この記事も役に立つかも？システム開発の工程に関連する記事
【プロが解説】システム開発で陥りがちな失敗事例7選と対策方法 システム開発は外注？内製？メリット・デメリットを比較して解説 【プロ厳選】システム開発会社おすすめ18社｜最適な選び方を解説 【プロ厳選】アジャイル開発でおすすめのシステム開発会社11選
Akemi
Michitoshi Kudo
Michitoshi Kudo
Michitoshi Kudo
