IT業界にいると「当たり前の知識」として扱われるシステムを作るための進め方や工程の話。
会議やお客様との会話でも普通に出てくる単語。
でも、そのことについて教えてもらえる機会ってあまりないと思いませんか？
開発言語やOSなどテクニカルな内容については社内外問わず色々と勉強する機会はありますが、
開発の進め方とか開発工程のことは先輩SEから教わるか、先輩SEのやり方を真似て自分なりに
理解することがほとんどではないでしょうか。
そこで、普段学ぶ機会が少ない開発の進め方や手順について書きたいと思います。
１．開発プロセスとは
「開発プロセス」とは、システム（製品やサービス）を作成するための体系的な手順を指します。
概要から詳細へ順に落とし込んでいくための手順を「プロセス（工程）」と呼んでいます。
体系的な手順を具体的にあらわすと以下のようになります。
① 計画する：目標の策定、開発スケジュール・予算を計画
② 要件を定義：システム化の範囲を決定する
③ 設計する：システムの仕様を設計
④ 開発：設計を形にする
⑤ テスト：想定通りに動作する事を確認する
⑥ リリース・納品：ユーザーへ納品
⑦ 保守：安定稼働のため
上記①～⑦の各プロセスを順に進めていきシステムを作成していきます。
次の章から開発プロセス毎に説明していきます。
２．開発プロセスのステップ
ここからは本題となる開発プロセスについて見ていきたいと思います。
各プロセスの表現・名称や分類の仕方は参照する媒体によっていろいろありますが
今回の記事で説明する開発プロセスは以下に分類します。
| No | プロセス（工程） | 主な作業 |
| 1 | 要件定義 | ・業務課題の整理と解決案の決定 ・システム化の範囲を明確にする。 ・関連システムとのインターフェース 一覧を明確にする ・非機能要件の整理 |
| 2 | 基本設計 詳細設計 |
・ネットワーク構成を決定 |
| 3 | 開発 | ・設計に沿って実装 |
| 4 | 単体テスト 結合テスト システムテスト 受け入れテスト |
・単体テストの実施 ・結合テストの実施 ・システムテストの実施 ・受け入れテストの実施 |
| 5 | 納品（リリース） | ・システムリリース ・各種成果物をユーザーへ提出 |
| 6 | 保守 | ・ハードウェア異常監視 ・システムエラー監視 ・バグ対応 ・仕様変更 ・仕様追加 |
各開発プロセスの実施は基本的に必ず必要になってきます。
ただし、開発を行う時に採用する開発手法（開発モデル）により実施方法や粒度は変わってきます。
開発手法（開発モデル）と開発プロセスの関係は3章で説明します。
２-１．要件定義
ユーザーの業務課題を洗い出しあるべき姿を明確にしてシステム化する範囲を決定するプロセスとなります。
ユーザーが抱える業務課題としてよくあるのは
・現状、手作業が多く時間がかかっているので効率化したい
・Excelで作った資料が散在し煩雑なので集約したい
・今、動いているシステムが古くなってきたので新しくしたい
・業務改革に合わせてシステムを刷新したい
・外出先から社内システムの情報をみたい
などなど。
上記のような課題や要望に対してやみくもにシステム化を進めると費用も期間も際限なく大きくなってしまいます。
そこで本当に「今」必要な物にスポットをあてシステム化するべき範囲と開発する期間・費用を決定していきます。
整理・決定していく内容は大きく３点あります。
１つめは業務要件の決定
現状の課題と実現したい業務フローとの差異を明確にしてシステム化する業務をまとめていきます。
２つめは機能要件の決定
ハードウェア・ソフトウェア両面からシステムを構成する要素を洗い出しまとめていきます。
３つ目は非機能要件の決定
性能や保守性・セキュリティといったユーザーが意識しにくい領域についてまとめていきます。
要件定義では多くの事を決定する必要があるため作成する成果物も大量になります。
代表的なものを以下に表現しています。
各成果物の作成は、基本的にユーザーと分担して行いますが、ユーザーに情報システム部門がないこともあるのでベンダー主導で行う事もあります。
主な成果物
| 成果物名 | 記載プロセス（工程） | 主な内容 |
| 業務要件 | キックオフ資料 | ・システム化の背景・目的や範囲を明確にする ・ユーザー、ベンダー各組織の体制図を明確にする |
| 業務プロセス関連図 | ・業務全体の流れを明確にする ・各業務の手順と担当者を明確にする ・各業務の情報の流れを明確にする |
|
| 現行業務フロー(As-Is) | ・業務毎に現状の業務フローを明確にする | |
| 新業務フロー(To-Be) | ・業務毎にあるべき業務フローを明確にする | |
| 業務一覧 | ・業務を一覧にしてシステム化対象・対象外を明確にする | |
| 要求一覧 | ・業務毎にシステム化したい要求を一覧にする | |
| 業務機能一覧 | ・利用者・役割毎にシステム化要件を一覧にする | |
| 要件変更管理一覧 | ・各記載内容の変更履歴を管理する | |
| 機能要件 | システム方式 | ・クラウド、オンプレ等環境方式を明確にする ・Web、C/Sなど実装方式を明確にする |
| ハードウェア構成図 ネットワーク構成図 |
・サーバの配置、関連を整理 ・ネットワーク設定、機器を整理 ・ファイアウォール・セキュリティ設定の整理 |
|
| ソフトウェア構成図 | ・OSやミドルウェアの基本的な設定を整理 ・拠点、サーバ毎に表現 |
|
| システム構成図 機能一覧 |
・実装する機能の一覧 ・各機能の関連を整理 ・他システムとの関連を整理 |
|
| 画面一覧 画面遷移図 画面レイアウト(概要) |
・作成する画面に関する仕様を明確にする | |
| 帳票一覧 帳票レイアウト（概要） |
・作成する帳票に関する仕様を明確にする |
※上記が必須という事ではなく一例として記載しています。
２-２．基本設計(外部設計)
基本設計は、主にユーザーが目にする部分（画面イメージや操作、帳票など）に関する仕様を決定していきます。
画面遷移や画面レイアウト、帳票レイアウト・出力方法、保持するデータ、外部とのインターフェースといったユーザーが業務で目にしやすい部分が対象となります。
要件定義で決めきれなかった画面構成・テーブル情報などもこのプロセスで決定し要件に対して漏れが無いように設計していきます。
ユーザーと仕様について検討できるプロセスは基本的に、このプロセスまでとなるため要件が全て満たせているかをしっかり確認していく必要があります。
また、ユーザーが目にする部分ではありませんがシステムを稼働させる環境（機器）の構成について設計を進めていく必要があります。
ユーザーの情報システム部門など担当を決めて設計を進めていきます。
主な成果物
| 成果物名 | 記載プロセス（工程） | 概要 |
| 基本設計書 | ハードウェア構成図 ネットワーク構成図 |
・ネットワーク配置やIPアドレスなど詳細情報を決定 |
| ソフトウェア構成図 | ・OSユーザーの権限設定 ・DBの設定情報など各ソフトウェアの詳細を決定 |
|
| 業務フロー データフロー |
・業務フローに画面等のシステム要素を明記 ・データの流れを明記 |
|
| システム構成図 | ・システムを構成する機能配置を明記 ・他システムとのインターフェースを明記 |
|
| 機能一覧 | ・開発する機能を明確にする | |
| 画面設計書 | ・画面に関する仕様を明確にするレイアウト、項目定義など | |
| 帳票設計書 | ・帳票に関する仕様を明確にするレイアウト、項目定義など | |
| データ設計書(概要) | ・テーブルの項目定義や主キーなどを明確にする表現する | |
| バッチ設計書 | ・データ集計、年度切り替えなどバッチ処理の仕様を明確にする |
※上記が必須という事ではなく一例として記載しています。
プロジェクトによっては、基本設計を外部設計と表現する事もあります。
多くのシステム開発では、ユーザーが見て理解できる基本設計までがユーザーのレビューと承認の対象となります。
２-３．詳細設計(内部設計)
詳細設計は、基本設計の内容をシステムに実装していくために必要となる詳細な部分について仕様を決定していきます。
例えば、システムを利用する人により画面の色を変えるという仕様がある場合
基本設計では、
・利用者の部署により色を変える。
・A部署の利用者は画面の色を青、B部署の人は緑にする
とユーザーが理解できる表現で記載します。
詳細設計では利用者の部署を判断する基準まで明確にして記載します。
・利用者の部署を〇〇テーブルの△項目で判断
・△項目が「１」の時がA部署、「２」の時がB部署とする
・△項目が「１」の時、画面の色を青に設定する
・△項目が「２」の時、画面の色を緑に設定する
という感じでよりシステムに近い表現で仕様を決定していきます。
状況や開発手法によりますが、基本設計と詳細設計を細かく分けずに設計として完結させる事もあります。
主な成果物
| 成果物名 | 記載プロセス（工程） | 概要 |
| 詳細設計書 | プログラム一覧 | ・作成するプログラム単位に一覧にする |
| 画面遷移図 | ・各画面の関連・遷移を明確にする | |
| 画面設計書(詳細) | ・画面の詳細仕様を明確にする ボタン操作、データ取得・更新条件など |
|
| 帳票設計書(詳細) | ・帳票の詳細仕様を明確にする 改ページ条件や出力保存方法など |
|
| CRUD図 | ・各機能とテーブルのアクセス方法を明確にする Create/Read/Update/Deleteを表現する |
|
| テーブル設計書(詳細) | ・未決定分含め最終的なテーブル定義を明確にする | |
| データベース物理設計書 | ・バックアップ含めデータベースの容量を明確にする | |
| バッチ設計書(詳細) | ・データ集計、年度切り替え等詳細仕様を明確にする。 | |
| クラス図 モジュール関連図 |
・クラスやモジュールの関係を明確にする ※オブジェクト指向言語で開発する場合は作成する事もある |
※上記が必須という事ではなく一例として記載しています。
プロジェクトによっては、詳細設計を内部設計と表現する事もあります。
２-４．開発
開発は、「製造」「実装」と呼ばれる事もありますが、これまで決めてきた仕様を実際に動く形にしていくプロセスとなります。
このプロセスは、これまでのプロセスと違いどのようなプロジェクトにおいてもやる事は同じです。
開発環境を構築し、データベースを定義し各機能を具現化していきます。
主な成果物
| 成果物名 | 記載プロセス（工程） | 概要 |
| 開発資産 | DDL文 | ・データベース、テーブル作成を行うためのSQL文 |
| プログラムソース HTML、CSS Java、Excelなど 各種定義体 |
・作成したプログラムソース 開発方法によって作成される成果物はさまざま |
２-５．単体テスト
作成した機能が正しく動作する事を検証・確認するためのプロセスです。
単体テストは機能単位、画面単位に仕様通りとなっているかを検証するためのテストです。
テストを行う時は、
・画面や帳票の出力内容が正しいか
・ボタン操作時など内部の動作が正しいか
といった個々の機能が仕様通りの動作をしているかを確認していきます。
単体テストは１つの独立したプロセスですが、開発時に行う動作確認をより体系化して行うため基本的には開発から単体テストまでを１つのサイクルとして管理される事があります。
※１つのサイクル：単体テストを１つのプロセスとして明記せず「実装」「開発」の一部と考える
２-６．結合テスト
機能と機能が正しく連携し動作する事を検証・確認するためのプロセスです。
たとえば、Ａ画面で登録したデータがＢ画面で正しく表示されているか、といった感じです。
Ａ画面、Ｂ画面それぞれは単体テストで仕様通りである事は確認しているはずですが、各画面の
操作を一連の流れとして実行した時にそれぞれが仕様通りになっているかを確認します。
プロジェクトや開発規模によっては、内部結合、外部結合と２つに分けて実施する事があります。
内部結合は、システムの内部または機能の内部といった閉じた世界で行うテストを指します。
システム内に10画面あり画面間の結合テスト、システム内にある複数のサブシステム間の結合テストなど。
外部結合は、複数のシステム間または複数の機能間で行うテストを指します。
２つのシステムの結合テスト、２つの機能の結合テストなど。
２-７．システムテスト
システムを構成する全機能を対象にテストを行います。
実際の業務を想定しながらテストデータを作成し本番に近い操作を行いシステム全体で整合性や性能面も考慮しテストを行います。
また不具合を検知できる最後のプロセスであり非常に重要となります。
単体テスト、結合テストは機能毎の動作に対して検証を行いました。
システムテストでは、対象業務で想定される場面ごとに検証を行います。
月末・月初の集計業務、年度をまたぐ業務、日々行われる業務、上長や役割毎に行う業務など利用シーンをイメージしてテストを行いシステム（業務）全体として正常に動作しているか確認します。
２-８．受け入れテスト
システムテストまでは原則としてエンジニアがテストを行いますが、受け入れテストはユーザーが実際にシステムを使って検証を行います。
システムテストと同様にさまざまな業務をシナリオとして切り取りテストを行います。
受け入れテストで概ね問題なければ納品という事になります。
ただし、品質が非常に悪い（単体テストで検知できるようなエラーが残っている）場合や決定してきた仕様と大きく乖離しているといったシステムとして使用に耐えない状態が発覚すると、ベンダーの瑕疵責任として費用が払われないという問題につながる事も。最悪の場合、損害賠償を請求されるという事にも発展します。
上に挙げたような低品質にしない事は大前提ですが、要件定義から受け入れテストに至るまでに、いかに真摯な対応と態度で友好的な関係を構築できているかといった側面も重要になってきます。
各テストの主な成果物
| 成果物名 | 記載プロセス（工程） | 概要 |
| テスト仕様書 | 単体テスト仕様書 テストエビデンス |
単体テストのテストケースを記載した設計書 テストを実施した時に想定通りに動作した証跡 |
| 結合テスト仕様書 テストエビデンス |
結合テストのテストケースを記載した設計書 テストを実施した時に想定通りに動作した証跡 |
|
| システムテスト仕様書 テストエビデンス |
システムテストのテストケースを記載した設計書 テストを実施した時に想定通りに動作した証跡 |
２-９．納品
上記でふれてきたプロセスを経て、ユーザーへシステムを引き渡すプロセスです。
要件定義、設計、開発、テストの各プロセスで作成した成果物をとりまとめユーザーへ提供します。
納品対象となる成果物や提供の仕方は、プロジェクトを始める前にあらかじめユーザーと合意しておきます。
納品方法は一般的に大きく２つあります。
Excelなど作成した電子データとするか、印刷しまとめた紙のどちらかになります。
電子データで納品する場合は、まずデータの中身を整理する必要があります。
ファイルを開いた時に編集中の状態になっていない事を心がけます。
例えばExcelで納品する場合、以下のような点に気をつけます。
・フォント・文字サイズが全ページ統一されている事
・印刷時に見やすい状態で改ページ設定されている事
・カーソルは各シートの先頭に移動している事
・Excelを開いた時に表紙シート（一番最初のシート）が表示されている事
これらが契約時に取り決めされている事もありますが、とりきめがなくても作成した製品として
提供する事になるので形を整えて納品するというマナーに近いかもしれません。
そしてユーザー指定のフォルダへ格納する または CDに焼き付けるなどして納品となります。
紙で納品する場合は、設計書系資料は全て印刷して納品します。
全資料で通しのページ番号をつける、冊子とするなどして印刷物を整えます。
印刷する場合も、紙として体裁を整える必要があります。
・フォント・文字サイズが全ページ統一されている事
・章の途中や文章の途中で改ページされないようにする事
・全体の表紙、資料単位の表紙をつける
・機能単位、設計書単位それぞれにページ番号を設定、または納品物全体を通し番号としてページ番号を設定する
印刷して納品するには準備に時間がかかる・保管場所が必要など、開発ベンダー・ユーザーともに不便さがついて回るため、最近は少なくなってきています。
それでも官公庁へ納品する場合は、印刷して納品する事が多い印象です。
開発した資産についてはそのまま電子データとして納品する事が多いと思いますが、まれに印刷して納品という場合もあります。これらは全てユーザーとの契約次第となります。
納品プロセスとして必要な成果物は特に決まったものはないですが、納品書や検収書といった開発ベンダー・ユーザー双方納品した証跡を残すための書類を作成し完了となります。
２-１０．保守
保守は納品されたシステムを継続して稼働させていくためのプロセスとなります。
システムの開発には必ず必要なプロセスですが、システムが稼働してから必要になるため要件定義～受け入れテスト・本番リリースとは別で検討される事がほとんどです。
例えば、Ａユーザーの〇〇システムの開発を行う場合。
ベンダーＹが要件定義～受け入れテスト・本番リリースまでを担当、
ベンダーＺが保守を担当 となっているとします。
ベンダーＹは保守性よりもユーザーが望むものに近いシステム目指します。
それを安定稼働させるための取り組みは最終的にベンダーＺが考える事になります。
保守の主な作業内容は
・システムの各種状態を監視し異常終了しないよう事前に対応する。
→ディスク容量の監視、メモリ・CPUの使用率監視
→必要に応じて月次などで状況報告を行う
→各対応時の手順書作成
・不具合が発生した時に、原因の追究と恒久・暫定対応含めシステムの復旧を行う。
→不具合原因の追究
→システム不具合の場合は、改修を行う
→想定外のデータや操作が原因の場合、手順書や使い方を周知
→ネットワークやディスクに関係する場合は、対応案を作成し運用方法を確立する
→インシデント管理を行い、ナレッジの蓄積を行う
・仕様変更や機能追加の要望が出た時に対応する。
→仕様変更時は納品された設計書などを更新しシステム改修を実施
→機能追加時は新たに設計書から作成しシステムに機能追加を実施
→仕様変更、機能追加どちらにしても保守の時間で対応可能か判断を行い
難しい場合は別途開発プロジェクトを立ち上げが必要である旨をユーザーへ伝える。
テストを行って納品されたシステムであっても不具合が全く発生しないという事はまれです。
レアケースのデータが登録される、担当者が変わって想定外の操作をされるなど不具合となる原因はゼロにはできません。
また、ネットワークが不安定、ディスク容量が足りない、などといったシステムが動作している環境面が不具合の原因になる事もあります。
こういった不具合が発生した時に、原因を調査しシステムが正常に動作する状態に戻す対応を保守担当が行います。
保守にも特に決められた成果物はありませんが、保守を行う中で発生するさまざまな事象をナレッジとして蓄積し対応の迅速化・属人化解消の取り組みを行う事が一般的です。
主な成果物
| 成果物名 | 記載プロセス（工程） | 概要 |
| 保守 | インシデント管理表 課題一覧 変更管理表 |
・安定稼働させるためのナレッジを管理します |
３．代表的な開発手法と開発プロセスの関係
この章では、実際に開発を行う時に仕様される開発手法のなかで各プロセスがどのように実施されていくのかを簡単に解説します。
３-１．ウォーターフォールモデルと開発プロセス
まずはシステム開発を行う時の最もメジャーな「ウォーターフォールモデル」です。
ウォーターフォールを日本語で表現すると「水が落ちる」という意味です。
上（要件定義）から下（受け入れテスト）に段階的に落ちていくことからウォーターフォールと呼ばれています。
下図のように段階（各プロセス）ごとに完了させてから次工程へ進んでいくため前の工程に後戻りはできません。
工程ごとにしっかりとレビュー（成果物の確認）を実施し、精度を高めていくのが特徴ですが、その分サービスリリースまでに時間がかかりがちというデメリットがあります。
要件定義が正確にできていないと想定した仕様にならないため品質の低下につながります。
要件定義や設計といった上流工程は非常に重要になります。
また、ウォーターフォールに限りませんが各プロセスの関係は、以下のようになります。
下図の関係をＶ字モデルと表現し１つの開発手法として扱う場合もあります。
３-２．アジャイルモデルと開発プロセス
次にアジャイルモデルです。アジャイルモデルは主流になってきている開発手法で「サービスリリースまでの期間を短縮できる点」が最大のメリットです。
ウォーターフォールモデルの「時間がかかりやすい」というデメリットに対応するための開発手法となります。
アジャイルとは日本語で表現すると「素早い」「機敏な」といった意味になり、 機能毎に設計・開発・テストを、繰り返し精度を高めて順次リリースしていきます。
下図のようにリリースしたい機能毎に「設計⇒実装⇒テスト⇒改善」を繰り返し実施します。
３-３．スパイラルモデルと開発プロセス
スパイラルモデルはアジャイルモデルと似ていますが、ウォーターフォールモデルとアジャイルモデルを組み合わせた開発手法となります。
ウォーターフォールモデルは各開発プロセスを段階的に進めていきますが、スパイラルモデルはシステムをサブ機能に分割し機能毎に要件定義・設計・実装・テストを繰り返し実施します。
下図は機能の違いを背景色で表現しています。機能毎に設計からテストを繰り返し必要があれば都度、仕様を変更しながら開発を進めていきます。
３-４．その他モデルと開発プロセス
開発手法は、上記にあげた３つ以外にもいくつか存在します。
その中で、よく名前が出るものをピックアップしてみました。
ただし、上記にあげたプロセスの流れと基本的には同じです。
開発する際に重視するポイントが変わってくるというだけですが、参考としてピックアップしました。
1) プロトタイプ手法
その名の通りまず動くもの（プロトタイプ）を作成しユーザーレビューを受けながら進める手法です。
この場合、各プロセスの流れはアジャイルモデルやスパイラルモデルと同様になります。
まず、プロトタイプの設計⇒実装⇒テスト⇒レビュー⇒改善を繰り返しすすめていきます。
2) スクラム
スクラムモデルはアジャイルの一種で、少人数で課題解決にむけて行う手法です。
ラグビーのスクラムから来た名称で、チーム一体となって進めていくコミュニケーションを重視した手法です。
プロジェクト期間中に短い期間を設定しいくつかの機能を開発していきます。
3) DevOps
DevOpsは、「Development（開発）」と「Operations（運用）」２つの役割を合わせた造語です。
従来、開発チーム・運用チームと別々に存在するチームが密接に連携をとり迅速かつ柔軟に開発を行う手法です。組織やチーム体制に重点を置いた手法です。
開発チームはシステムをよりよいものにすること（新しい変化）を追求し、運用チームは実際に稼働しているシステムを継続して安定稼働させる（安定）事が目的です。
本来であれば相反する目的を持つチームを組織として融合させ開発と運用のサイクルを作り上げる考え方となります。
４． 開発プロセスのおまけ
ここまで開発プロセスの解説をしてきましたが、システム開発の現場はプロジェクト毎に千差万別で常に同じやり方で進んでいけるわけではありません。
だからというわけではありませんが「システムを作る」時の考え方と開発プロセスと開発手法のとらえ方について軽くふれておきます。
４-１．各開発プロセスで考えること
実際に開発プロセスを使ってシステムを作る時に考える事はなんでしょう。
主に「要件定義」の段階でさまざまな事を考え決定していく事になりますが、決定していく内容を、ビジネスマナーや新人研修などでよく出てくる５Ｗ１Ｈに当てはめると整理しやすくなります。
「When いつ」 ：納期はいつにするのか
「Where どこで」 ：事務所（PC）だけなのか、出先（モバイル）でも必要か
「Who 誰が」 ：どの部署の人が使うのか
「What 何を」 ：システム化したい情報・業務は何か
「Why なぜ」 ：システム化する目的は
「How どのように」 ：Webアプリか、どう実現するか
５Ｗ１Ｈを使ってユーザー視点から「何をしたいのか」「いつ使うのか」「どこで使うのか」
「誰が使うのか」「どのように使うのか」といった事を考えていきます。
またベンダー側の視点から「いつまでに作るのか」「何を作るのか」といった内容も考えていきます。
上で上げた内容を
「要件定義」で概要を決定し
「設計」で抜け漏れがないように詳細化し
「開発」「テスト」で正しく動作するよう形にしていきます。
「納品」してユーザーへ使える状態にし
「保守」で安定稼働を目指していきます。
プロジェクトにより進め方はさまざまですが、決めていく内容の大原則は変わらないので参考にしていただければと思います。
４-２．開発プロセスと開発手法の違い
開発プロセスと開発手法に触れてきましたが密接に関係する言葉になるためそれぞれの違いについて説明します。
インターネットで「開発プロセス」と検索すると「開発手法」と混在して結果が表示され、開発手法＝開発プロセスのように説明される事が多いと思います。
システムを作るうえで開発プロセスと開発手法は切り離せないものなので、同義として扱われる事も多いですが、今回の記事では「開発プロセス≠開発手法」とし切り離して解説をしてきました。
それぞれの言葉は以下のように定義しています。
開発プロセス：システムを作るための手順を「工程」に分類し定義したもの。
「要件定義」「設計」「テスト」「保守」など
開発手法：開発プロセスを効率よく運用するための方法。開発モデルとも呼びます。
「ウォーターフォール」「アジャイル」「スパイラル」など
言葉の定義が曖昧になりがちですが、しっかり明確にしておきましょう。
採用する開発手法（開発モデル）を決定し開発プロセスにそって開発を進めていくのが一般的です。
５．さいごに
ここまで読んでいただきありがとうございます。
開発プロセスについて解説をしてきましたが、ここで記載した内容はあくまで一例となります。
プロジェクトやPMの方針・考え方やユーザーの意向など様々な事を総合して開発プロセスや成果物を決定してシステムを作成していきます。
長くなりましたが、実際に携わるプロジェクトを進めていく時の参考になればと思います。
