自社のシステム開発であっても、所有するスキルや納期、工数などの兼ね合いで外部の開発会社に依頼するケースは少なくありません。
しかし、システム開発の流れや必要な工程を知らずに委託すると、開発コストの増加や思わぬリスクに直面してしまう可能性もあります。
この記事では、システム開発の代表的な2つの工程や、流れについて解説しています。
「システム開発を円滑に進めたい」「外部企業への委託を考えている」のであればぜひ参考にしてください。
システム開発の工程とは
システム開発の工程とは、ITサービスを生み出すのに欠かせない作業を手順ごとに分類したものを意味します。
以下のような項目はすべて、システム開発の工程と呼ばれます。
- ITシステムの枠組み決め
- 概要の設定（サービスの目的）
- 内容の選定（デザイン含む）
- テスト運用
- リリース後の管理方法の確立
webサイトの仕様書や企画書の作成、プログラミング、試験運用といった作業は、すべてITサービスを生み出すための工程です。
また、開発の目的によって手法は異なり、工程の進め方が違ってくるのも大きな特徴です。
システム開発は、クライアントから依頼を受け、こうした開発の背景を踏まえたうえで、最適な工程の進め方を決めます。
つまり、システム開発における工程への深い知識と理解が欠かせません。
システム開発の代表的な工程の種類は2つ
システム開発における、代表的な工程は以下の2つです。
- ウォーターフォール開発
- アジャイル開発アジャイル開発
それぞれの違いを、一覧にしたのが以下の表です。
| 特徴の出る項目 | ウォーターフォール開発 | アジャイル開発 |
|---|---|---|
| 開発工程の進め方 | 段階的 | 可及的（突発的） |
| 開発コスト | 削減しやすい | 増加しやすい |
| 開発途中での仕様変更 | 困難 | 容易 |
| 開発品質 | 担保しやすい | 担保されづらい |
| リリースまでの期間 | 長期間 | 短期間 |
取り組み方が違う開発方法であるゆえに、ウォーターフォール開発とアジャイル開発とでは、開発にかかるコストやリリースに漕ぎつけるまでの期間に違いが生じます。
いずれの方法が正解かどうかは、一概にi
えません。
むしろ、プロジェクトに対して最適な開発工程を選ぶ必要があります。
ウォーターフォール開発とアジャイル開発、それぞれについて詳細な流れを解説します。
ウォーターフォール開発
ウォーターフォール開発とは、開発において古くから用いられる手法です。
英語で滝を意味するウォーターフォールの名を冠しているだけあって、ウォーターフォールでは開発工程をすべて段階的に区切りを付けながら進めていきます。
ウォーターフォール開発の、具体的な工程は以下のとおりです。
- 要求定義：開発するITサービスの企画書や仕様書をまとめる
- 外部設計：概要を決め、付帯もしくは関連するサービスについて整理する
- 内部設計：枠の決まったITサービスについて、細かな内容を詰めていく
- 開発：プログラミングを行い、ITサービスを構築していく
- テスト：完成したデモ版が、正常に作動するかをチェックする
- 運用：ITサービスリリース後の保守管理マニュアルの作成
つまり、ウォーターフォール開発が持つ特徴から、メリットとデメリットをまとめると以下のようになります。
| 特徴 | メリット | デメリット |
|---|---|---|
| 開発の進め方 | 計画的に進行できる | 前工程が終わらないと次の作業に入れない |
| 開発プロセス | 作業に入る前に明確化できる | 開発途中での変更はしづらい |
| 計画性がある | ITサービスの品質は高めやすい | 手戻り作業に対処する場合、大幅な遅れが生じる |
また、ウォーターフォール開発には、デメリットを解消した別の方法もあります。
H4：スパイラル開発（反復型開発）
スパイラル開発（反復型開発）とは、開発工程をループさせることで、ウォーターフォール開発における手戻り作業発生時の計画破綻によるリスクを減らせる手法です。
外部設計や内部設計といった、枠ごとに開発工程を進め、テスト運用までを先に行います。
ウォーターフォール開発を、工程ごとに別々に進めるイメージです。
メリットは、開発速度が上がり、急な仕様変更にも対応しやすい点にあります。
しかし、開発コストが増加しやすく、各工程の進捗度が見えづらいといったデメリットがあるため、管理を徹底する必要があります。
アジャイル開発
アジャイル開発とは、開発工程が完成するごとに機能をリリースしながらITサービスを完成させる開発手法です。
開発に取り掛かる前に計画を立てないのが大きな特徴です。
アジャイル開発の特徴と、生じやすいメリットとデメリットをまとめると以下のような表になります。
| 特徴 | メリット | デメリット |
|---|---|---|
| 開発は工程ごと | 他工程と別のため自由度の高いクリエイティブな開発ができる | 各工程の進捗管理が大変なため、責任者を置く必要がある |
| 反復で開発 | 手戻り作業にも迅速に対応できるため開発の速度が上がる | ITサービスの方向性がぶれやすいため、見直しも必要となる |
| 納品速度が速い | 納期を最優先に重視する顧客のニーズが叶えられる | 不具合も後から生じやすいため、アフターフォローが求められる |
ウォーターフォール開発が計画的かつ、順を追った工程で開発を進めるのに対し、アジャイル開発はそれぞれの工程で一斉に開発に取り掛かります。
さらに、アジャイル開発は、新機能のリリースという形で、完成した工程を随時実装させながらITサービスを完成させます。
スパイラル開発のように、リリース前に工程を合体させたりはしません。
カウボーイコーディング
アジャイル開発で注意したいのが、開発工程が好き勝手に開発に着手している状態のカウボーイコーディングという手法です。
アジャイル開発は、各開発工程がコミュニケーションを取りながら作業にあたりますが、カウボーイコーディングは連携を一切せずに作業を完了させてしまいます。
ITサービスの方向性が定まらない、開発工程がすべて完成したのちに露見する、甚大な欠落があらかじめ発見できないといったデメリットがあります。
アジャイル開発は、リーダーシップを発揮して管理する者がいないとカウボーイコーディングとなってしまうため、注意が必要です。
【表あり】システム開発の主な工程（流れ）
システム開発は、開発手法によって工程における名称が異なる場合があります。
しかし、ITサービスの構築に向けてそれぞれの開発工程が担う役割は同じです。
名称の違いに惑わされずに、開発目的に応じた工程を選びましょう。
システム開発の主な工程は、以下の7つです。
- ヒアリング・要件定義
- デザイン・外部設計
- プログラミング・内部設計
- テスト・ITテスト
- システムのリリース（β版）
- 公開・リリース（成果物の納品）
- 運用・保守
①ヒアリング・要件定義
クライアントからヒアリングした内容を基に、ITサービスの要件定義を決めます。
第一工程で、クライアントがITサービスに求める要望を具現化します。
ヒアリングを行うと、クライアントからは複数の要望や抽象的なイメージをたくさん聞くこととなるでしょう。
要件定義の大きな役割は、ヒアリング項目を整理して目的を整理することにあります。
実現したいことを明確にすれば、システム開発の目的も定まるでしょう。
また、同時進行できない要望については、優先順位をつけることで成果物に対するクライアントの満足度も担保できるでしょう。
ゴール設定を明確にできるため、開発期間、予算、バッファまで綿密な計画が立てられます。
②デザイン・外部設計
デザイン・外部設計は、フロントエンドのITサービスの“見た目”を定義付けます。
UI/UX（ユーザインターフェス・ユーザーエクスペリエンス）といわれる、webサイトであればサイトデザイン、ITサービスであれば顧客が実際に使うサービスをデザインします。
ヒアリングで定めた開発のゴールに対し、ターゲットユーザー層やITサービスの目的に応じた必要な機能や使い勝手を考慮したデザインを設計します。
③プログラミング・内部設計
プログラミングや内部設計は、外部設計を構築するバックエンドです。
UI/UXに沿って選定したデザインや画面遷移などの機能を実現するのに、必要な動作をプログラミングします。
プログラミング・内部設計工程は、システム開発において実際に手を動かして作業します。システム開発において、もっとも労力が費やされる工程といえるでしょう。
新機能のリリースなどで必要となる経費（ユーザー登録料、サーバー購入料など）の内訳もここで決めていきます。
④テスト・ITテスト
システム開発における、もっとも重要な工程とされているのがテスト・ITテストです。
丁寧にチェックを重ねるため、単体と統合、運用とそれぞれでチェックテストを行います。
単体とは、プログラミングによって形となったITサービスが、正常に作動するかを1つの開発工程のみでチェックします。
次に、統合・運用と規模を広げてもシステムが正常に作動するかをチェックします。
理論上は問題のないプログラミングでも、実際に稼働させてみることで初めてトラブルが生じるというパターンも少なくありません。
アクセスへの耐久性・処理速度・障害の有無・不具合の修正など、さまざまな可能性を考慮し、あらゆる検証パターンで地道なテストを繰り返していきます。
⑤システムのリリース（β版）
システム開発の工程には、リリース（β版）といって、完成したシステムをユーザーにお試しで使ってもらう工程もあります。
使い勝手や、開発されたシステムに対するユーザーからの意見・感想を集めます。
内部設計や要件定義によって定めたUIなどが的確か、ユーザーからフィードバックを集め、集まった意見は、改修や発見された不具合の修正に活かしていくのです。
プロジェクトの納期が差し迫っている場合やリリース後に改修を挟む予定がある場合など、省略されることもありますが、ITサービスの最適化に一役買う大事な工程です。
⑥公開・リリース（成果物の納品）
公開・リリースは、システム開発における納品を担う工程です。
要件定義に則したITサービスが作れているか、仕様が整理されているかを最終確認します。
また、システム開発は規模により多くの部署や人の手が介される場合も少なくありません。
関連する部署やチームに対し、開発システムの公開・リリースの周知を行うのも重要なタスクです。
⑦運用・保守
システム開発は、サービスリリース後の運用や保守についてもサポートします。
日々、ITサービスが正常に作動しているかを監視しながら、アップデートや実際に出た不具合の修正対応にあたり、レポートをまとめます。
運用・保守の仕事は、システム開発において切っても切れない関係性にある、大切なルーティンワークです。
業務の効率化や、新システムとの親和性を常に見守るためにも欠かせません。
システム開発の工程における比率
システム開発の工程における比率は、制作に割く時間が最も長いといわれています。
システム開発における工程を分割すると、基本設計・詳細設計・製作・結合テスト・総合テスト（ベンダ確認）の5つです。
比率を表で示すと、以下のようになります。
引用元：ソフトウェア開発 データ白書 20I8-20I9
制作については、作業比率が全体の35％以上を占めており、それだけ作業に長い時間を要しているということが分かります。
要件やフレームの構築も重要ですが、それ以上に、制作部隊が作業比率で大きなウェイトを占めているのがポイントです。
スケジュールを立てるのであれば、制作にきちんと時間を割けるようにすれば、質の高いITサービス開発につながるでしょう。
システム開発の工程で知っておきたい英語・略語
システム開発の工程で、知っておくと便利な英語・略語の代表的なものを紹介します。
| 略語 | 用語（英語） | 意味 |
|---|---|---|
| RD | 要件定義 （Requirement Definition） | システム開発により実装する機能を選定内容はユーザーのニーズによって決められる |
| BD | 基本設計（Basic Desig） | システムが有する機能を分割して設計機能ごとの互換性などをデザインする |
| FD | 機能設計（Function Design） | 開発システムの機能を明確にする |
| ID | 内部設計（Internai Design） | ユーザーが目にするデザイン設計（外部設計）の動作や機能の設計を司る |
| ED | 外部設計（External Design） | ITサービスにおいてユーザーが直接目にする、使う部分のデザイン設計 |
| DD | 詳細設計（Detail Design） | 出そろった設計項目に対して、プログラム実装前にそれぞれのシステムの設計を決める |
| PD/PS | プログラム設計（Program Design）（Program Structure Design） | 機能を実装する前に、各プログラムの動作をあらかじめ決めること |
| PG | プログラミング（Programin） | コンピュータ言語で、構築したい機能を開発していくこと |
| UT | 単体テスト（Unit Test） | 開発工程ごとにシステムの正常作動をチェックすること |
| IT | 結合テスト（Integration Test） | 単体テストをクリアした工程同士を合わせて正常作動をチェックすること |
| PT | 総合テスト（Product Test） | システムをすべて結合し、完成した状態で正常作動するかをチェックすること |
| OT | 運用テスト（Operations Test） | システム開発における最終チェックで、本番環境での正常作動をチェックする |
まとめ
システム開発の工程について、工程がどういったものを意味し、代表的な手法の解説から、作業比率、システム開発に関連する用語を解説しました。
システム開発では、付随する作業をすべて階層ごとに分けています。
開発手法も正解と呼ばれる方法は単一ではなく、開発目的やクライアントニーズにより、異なる手法を使い分けてシステムを生み出していきます。
つまり、システム開発ではどのようなプロジェクトでも、開発目的（ゴール）を見失わないようハンドリングしながら作業を進めなければなりません。
実装する機能の優先度も、開発工程や作業比率を参考にすれば、より完成度の高いITサービスの構築が可能となるでしょう。
