システム開発の「工程」に詳しく、システム開発を専業として行っているIT企業は別として、一般的な企業の場合、システム開発自体をIT企業に外注することが多いでしょう。しかし、外注しているからシステム開発の知識は不要でよい、ということはありません。発注側にもある程度の知識があってこそ、ニーズに合ったシステムを構築できるのです。今回は、システム開発の工程に関する基礎的な知識を紹介します。
システム開発の工程にはどんなものがあるのか
システム開発には、多くの開発モデルで共通の工程があります。
システム開発の各工程
システム開発は、一般的に以下の工程をともないます。
- 要件定義
要件やシステムに求めることを明確にして、開発するシステムのスコープ（対象となる領域、範囲）を設定する工程です。発注側へヒアリングを行い、要件定義と開発の見積りを算出します。
要件には、機能要件と非機能要件があります。機能要件はシステムの主な目的を達成するために実装すべき機能で、非機能要件はシステムの性能のような、機能以外に求める要件です。 - 基本設計
データベースやファイルの仕様、画面のデザインや遷移、帳票のデザインやタイミングなど、機能の仕様を決定する工程です。バックアップやデータ連携など、システム全体の仕様も決定します。基本設計は発注側のレビューを受け了承を得なくてはなりません。 - 詳細設計
各機能を細分化し、細かい仕様を決定する工程で、これをもとにプログラミングを行います。設計とプログラミングを別のスタッフが担当する場合には特に重要です。 - プログラミング（コーディング）
詳細設定をもとに、プログラムを作成する工程です。ひとつの機能を細かい部品に分けてプログラムを作成します。 - 単体テスト
プログラミングが終了したら、不具合がないか、必要な機能が実装されているかを確認するためにテストする工程です。作成した部品ごとにテストを行って動作を確認し、不具合がなくなるまで修正します。 - 結合テスト
関連した部品を結合して、正確に動作するか、機能を実現できているかを確認する工程です。
結合テストには、内部結合テストと外部結合テストがあります。内部結合テストは、システム内部のプログラムを結合して行うテストです。外部結合テストは、ふたつ以上のシステムを結合・連携して行います。 - 総合テスト
すべての部品や機能を結合し、システム全体の動作を確認する工程です。全体での動作を確認し、要件を満たしているかを検証します。 - 運用テスト
顧客が操作して動作を確認する工程です。問題がなければ本番環境に移行します。 - 本番移行・フォロー
システムを本番環境で運用し、動作を確認する工程です。運用開始後は開発側から一定期間フォローされますが、フォロー期間が終了したら、運用・保守段階に移行します。 - 運用・保守
システムを運用・保守する工程です。システムが正常に稼働しているかの監視やユーザーサポートを行います。
それぞれの工程の呼び方は開発モデルや企業によって異なります。また、各工程をどのような手順で進めるかは、開発モデルによって異なります。
システム開発の工程それぞれの比率
開発工数全体に対する各工程の工数比率を知っておくと、システム開発の工程の理解に役立ちます。日本情報システム・ユーザー協会(JUAS)が公開している「ソフトウェアメトリックス2018年版」によると、各工程の工数比率の平均は次のとおりです。
- 要件定義：約20％
- 設計から統合テスト（基本設計、詳細設計、コーディング・単体テスト、結合テスト、総合テスト）：約60％
- ユーザーテスト（運用テスト）：約20％
実際にもっとも時間がかかるのは、テストとその修正です。ただし、あとから設計変更が生じて再度工程が増えることも多いので、一概にはいえません。
システム開発に関する略語
システム開発の現場では、英語ベースの略語がよく使われます。発注側でもこの略語を理解しておくと、エンジニアとの会話が楽になるでしょう。代表的な略語を以下に紹介します。
- SA（System Analysis） 要求分析
- RD（ Requirement Definition） 要件定義
- SP（System Planning） 企画
- BD（ Basic Design） 基本設計
- FD（Function Design） 機能設計
- SS（System Structure Design） 構造設計
- DD（Detail Design） 詳細設計
- M（Manufacture） 製造
- UT（Unit Test ） 単体テスト
- IT（Integration Test） 結合テスト
- ST（System Test） システムテスト
- PT（Product Test） 総合テスト
- OT（Operation Test） 運用テスト
システム開発には代表的なふたつのモデルがある
現在システム開発でよく使われている開発モデルには、ウォーターフォールモデルとアジャイルモデルのふたつがあります。
ウォーターフォールモデルとは
ウォーターフォールモデルとは、滝の水が流れ落ちるように工程を順番に進めていく開発モデルで、もっともよく使われています。
ウォーターフォールモデルの特徴
- 前の工程には戻らない
ウォーターフォールモデルでは、工程を順番どおりに進めていきます。いったん次の工程に移ったら、基本的に前の工程に戻ることはありません。 - 要件定義や設計に時間をかける
要件定義や設計はシステム全体の形を決めるものです。ここでシステムの仕様をしっかり決めることができれば、全体の開発時間が短くなります。 - 工程ごとに成果物を作成する
前の工程に戻る必要がないように一つひとつの工程を確実に進め、工程ごとに成果物を作成します。 - 大規模案件に向いている
開発が現在どの段階にあるかがひと目でわかります。そのため、部品が多く大規模な案件向きです。
ウォーターフォールモデルの流れ
要件定義から設計、開発など、システム開発の工程を順番に進めていきます。
ウォーターフォールモデルのメリット
- 開発スケジュールを管理しやすい
前の工程に戻ることがないため、進捗状況の把握がしやすくスケジュール管理が容易です。 - 経験者が多く開発しやすい
もっともよく使われる開発モデルのため、経験者が多く導入しやすいでしょう。 - 品質を管理しやすい
計画的に工程を進めて工程ごとに成果物を残すため、品質をきめ細かく管理できます。
ウォーターフォールモデルのデメリット
- あとから修正が発生した場合の対応が難しい
前の工程に戻ることはないので、あとから大きな修正や変更が発生した場合にはうまく対応できません。対応できても、開発日程が大きく遅れることがあります。 - 全体的に時間がかかる
設計に時間をかけ、工程ごとに成果物を作成するため、ほかの開発モデルよりも開発に時間がかかります。そのため、スピードが必要なプロジェクトには向いていません。
アジャイルモデルとは
アジャイルモデルとは、短期的に実装、リリース、テストを繰り返しながら修正して、最終的な成果物をつくっていく開発モデルです。アジャイルには「すばやい、俊敏な」という意味があります。
アジャイルモデルの特徴
アジャイルモデルでは、開発→テスト→修正を何度も繰り返します。そのため、発注側と開発側のこまめなコミュニケーションが必要です。
すばやく開発ができるため、短期間で進めたい案件に向いています。変化に対応しやすく、新規事業で全容があらかじめ決まっていない案件、修正や変更が多い案件にも適した開発モデルです。
アジャイルモデルの流れ
- 計画策定
前出の要件定義から基本設計にあたり、開発全体について大まかな要件と計画を策定する工程です。最初は細かい仕様は不要です。細かい仕様を決定しないことで、あとから変更や修正に対応しやすくしています。 - 工程の分割と優先順位付け
詳細設計にあたり、開発計画を機能ごとに「イテレーション」という単位に分割する工程です。プログラミングはイテレーションごとに行うので、優先順位を付けて開発順序を決定します。スコープや見積もりも機能ごとに作成します。 - 機能ごとの開発
プログラミングからテストにあたり、イテレーション単位で開発を行う工程です。機能ごとに要求定義、設計・開発、テスト・修正を繰り返します。 - 次の機能の開発
イテレーションごとに開発を行い、ひとつの機能をリリースしたら次の機能の開発に移ります。 - テストを追加した部分をリリース
前出の運用テストから本番移行にあたり、ある程度の機能が実装されたシステムをリリースする工程です。本番環境で運用されることで、さらに変更や修正が加わることもあります。 - 開発終了の判断
前出の運用・保守にあたります。アジャイルモデルでは、無限に開発と修正を繰り返すことができます。そのため、開発の終了は発注側もしくはプロジェクトリーダーなどの判断で決定します。
アジャイルモデルのメリット
- スピーディーな開発
要件定義や設計の時間が短いため、開発期間を大きく短縮できます。また、優先順位を付けることで重要な機能や必要な機能からリリースできるため、スピーディーな事業展開が可能です。 - 修正や追加に柔軟に対応できる
システムを開発しながら修正を繰り返すので、開発中でも柔軟に変更や修正を行えます。 - 開発中のコミュニケーションが多いのでユーザーのニーズに合いやすい
発注側と開発側が開発中もこまめにコミュニケーションをとりながら開発を行います。そのため、発注側の希望をくみとりやすく、よりニーズに合ったシステム開発が期待できます。
アジャイルモデルのデメリット
- 進捗状況がわかりにくくスケジュール管理がしにくい
最初に全体の計画を立てることがなく、短期的な実装とテストを繰り返します。そのため、システム全体を完成させるための計画を立てることは困難です。スケジュール管理もしにくく、品質を追求しすぎて開発時間がかかりすぎることもあります。そのため、きちんとした進捗管理が必要な大規模なプロジェクトには向いていません。 - 経験者や対応している開発会社が少ない
比較的新しい開発モデルなので、アジャイルモデルに精通した開発会社は多くありません。
発注側も開発チームの一員としてシステム開発の工程を理解しよう
よりニーズに合ったシステムを開発するためには、どの開発モデルで開発を行うのか、各工程で何を行うのかを発注側も理解していなくてはなりません。そのうえで開発側と細かくコミュニケーションをとることで、より品質の高いシステムの開発が可能になるのです。発注側も開発を行うプロジェクトチームの一員としてシステム開発に対する理解を深め、よりよいシステムの開発につなげることが大切です。
なお、サイバーウェーブの「VALUE KIT」は、Webサイトやシステムの管理を行う「ベース」、会社概要やプライバシーポリシーなど企業サイトにおいて必要な画面を作成する「フロント」など、機能ごとの部品を組み合わせて開発を進める製品です。課題や課題の解決方法を一緒に考えるところから始め、必要な機能を提案する形で進めるため、これからシステムへの理解を深めていきたいという段階でも利用しやすいでしょう。詳細は、こちらをご覧ください。
