※本記事は広告を含みます。
システム開発を学びたい!ビジネススキルを身につけたい

IT初心者必見|システム開発の全体の流れ・工程とは?図解あり

システム開発を学びたい!

システム開発の全体の流れを知りたい
システム開発の一般的なプロセスを知りたい

網羅的にシステム開発概要を理解したい

と言った疑問に答えます。

この記事を読むことで、システム開発の全体の流れ・プロセスを理解できます。自身のIT業界15年以上にわたって事業会社の社内SEとSier両方の経験からシステム開発の全体工程・流れを解説します。この事業会社の社内SEとSier両方の経験により、一般的な、「システム開発工程」よりも充実した内容をお届けできます。

本記事で解説するシステム開発工程とは?

一般的なシステム開発工程・プロセスの流れ
要件定義→基本設計→詳細設計→開発→各種テスト→移行・リリース→運用・保守

本書で解説するシステム開発工程・プロセスの全体の流れ
起案→プロジェクト立上げ→要件定義→基本設計→詳細設計→開発→各種テスト→移行・リリース→運用・保守

一般的に呼ばれる、システム開発(Sier等のシステム従事者目線)だけではなく、その前に発生する、事業会社目線のシステム開発工程も含み解説します。

補足:なぜ一般的なWEBや書籍等では要件定義前のシステム開発に関連する工程・プロセスの流れを解説しないのか?

理由:日本のIT人材の8割はSierに所属し、残り2割が事業会社に所属しているといわれています。したがって、WEB情報・システム開発系の書籍もこの8割をターゲットになっています。

しかし、Sierの顧客は事業会社であり、その事業会社で必要な起案・プロジェクト立上げを含むシステム開発工程を抑えることで本当の意味でシステム開発の全体を理解できたといえます

システム開発プロジェクトは、システム開発を開始する前から始まっています!!(特に、事業会社目線では)

✔記事の信ぴょう性

kato
kato

SIer SE→現、一部上場企業社内SE(IT歴15年以上)。基幹システム開発、及び、グローバル16拠点への導入やSCM・MDM等システム開発。社内SEの情報サイトIT Comp@ss運営者。「社内SE 1年目から貢献!情シス 企画・開発・運用 107のルール」著者。

本記事は、以下の社内SE基礎講座の「システム開発の全体の流れ・工程」の記事です。

IT初心者・社内SE向け|システム開発の【基礎講座関連記事一覧

✓ITスキルを伸ばしたい方にあわせておすすめ記事
独学派 社内SEの勉強におすすめ!システム開発が学べる本22冊【厳選】

システム開発工程(プロセス)の流れの全体像とは?

本記事では、以下のシステム開発工程(プロセス)に沿って各工程の解説をしていきます。本気で利用する図は、【社内SE 1年目から貢献!情シス 企画・開発・運用 107のルール 】の書籍から引用した為、章番号がありますが、本記事の構成とは関係ございません。混乱しないようご注意ください。

記事前半解説概要:システム開発工程(プロセス)の流れ

以下の内容に沿って、記事の前半ではシステム開発で登場する工程・プロセスの流れをまずは解説していきます。

システム開発工程(プロセス)の全体像と各プロセス概要説明
・起案
・プロジェクト立上げ
・要件定義
・基本設計
・詳細設計
・開発・コーディング
・システムテスト
・移行・リリース
・保守・運用
・契約&契約変更

記事後半解説概要:システム構築のアプローチの選択肢

記事後半では、一般的なシステム開発工程の一連の流れだけではなく、更にシステム開発工程の変動要素となる以下の選択肢も解説します。

システム開発プロジェクトを進める上で、どのように進めるかに大きく影響のある決めなければいけない選択肢は、上図です。

どれもシステム開発の進め方に影響があるので認識しておく必要があります。

システム構築の選択肢としては、
どのようなシステム構築を目指すのか?
・業務改善
・BPR
・デジタル化
・DX

なのか選択肢が存在します。

システム構築、あえてシステム開発と言わない部分にも味噌があります。システムは何も自社で開発・もしくはSierに依頼し開発するだけが選択肢ではありません。
・エンハンス開発
・スクラッチ開発
・パッケージ導入
・クラウド利用

様々な選択肢が存在します。

更に、どうやってその決めたシステム構築の手段を進めるかも実際には選択肢があります。
・自社で開発を推進する
・Sierに基本設計以降の開発を依頼する
・Sierにシステム開発だけではなく、それとセットで発生する業務変革も支援を依頼する
・丸投げ、、、してしまう、、、または、丸投げになってしまう(涙)

等々あります。

更に、最後にその決めたスコープのシステム化をどのように開発し進めるかを決めます。
・ウォーターフォール開発
・アジャイル開発
・ハイブリッド開発

等様々です。

システム開発工程・プロセスの全体感を抑える為には、上記のシステム開発のプロセスだけではなく、様々な選択肢の違いも認識しておく必要があります。

システム開発の各工程(プロセス)の解説

起案

事業施策・戦略に基づきビジネス・業務の課題を特定しプロジェクトの立ち上げを狙います。ここで言うプロジェクト起案には、必ずしもシステム構築という課題解決の手段で対応するものだけとは限りません。例えば、更に配送業務を活性化する為に、庫内の大幅なレイアウト見直しや人員倍増プロジェクト等です。

しかし、いずれのシステム開発プロジェクトでもこの起案プロセスをすっ飛ばす事は出来ません。システム開発・構築はビジネス課題解決の為に実施されます。もし、そもそものビジネス課題の特定をスキップしたシステム開発プロジェクトは、システムを開発するということ自体が目的になってしまう、手段が目的になるプロジェクトです。

上図のプロジェクト構築の様々なアプローチからどうその課題を解決するのか?を検討していきます。様々なアプローチの違いに関しては記事後半で解説します。

ITのシステム開発プロジェクトの勘違いされる構図イメージは以下です。

社内SE 1年目から貢献!情シス 企画・開発・運用 107のルール

プロジェクト立上げ

次にプロジェクトの立上です。どのように特定したビジネス課題を解決するか、どれくらいの予算でどの効果を狙うかを検討していきます。事業会社の場合、このフェーズで社内の必要な予算・リソース等の承認を得てプロジェクトチームを編成していきます。

この工程で、どうビジネス課題を解決するかの手段の選定がまだの場合、ITソリューションのRFP(提案依頼)を実施し、複数選択肢からITソリューションを選定する作業を実施します。又、ITソリューションの選定だけではなく、どの部分に外部のSierを利用するのかといった検討も実施します。そのSierに対してもRFPを実施し選定を行いプロジェクト立上を狙います。

外部リソース活用のパターン例

社内SE 1年目から貢献!情シス 企画・開発・運用 107のルール

起案・立上フェーズで登場する詳細プロセスイメージ

社内SE 1年目から貢献!情シス 企画・開発・運用 107のルール

要求定義・要件定義

要求・要件定義自体の定義はシンプルです。この工程では、特定したビジネス課題に基づき、何を解決したいかを定義していきます。

社内SE 1年目から貢献!情シス 企画・開発・運用 107のルール

先ほどの立上でのRFPを実施するという箇所で、要求・要件定義を実施しなければRFPを推進できないのでは?と気づいた方は鋭いです。この要求・要件定義がIT初心者には少々わかりずらい工程です。

何が難しいかというと、要件定義は様々な工程で登場しうるからです。

例で解説します。

例1.RFPを実施する為に、ハイレベルなシステム化要件を検討しSierに提案を依頼する
例2.自社で要件定義を実施し、Sierに要件を提示し見積もりを行う
例3.Sierがプロジェクト参画し、システム化要件を検討し要件FIXを狙う

これら3つの要件定義は1プロジェクトで3回登場する場合も、しない場合もあります。

この違いは、要件の抽象度・具体度です。要件を概要レベルで決めなければ、Sierから提案をもらう事は出来ず、見積もり依頼する為にも概要の検討が必要です。一方、Sierがプロジェクト参画しシステムというモノづくりをする為にはかなり具体的なシステム化の要件まで落とし込まれている必要があります。

IT初心者の方は、システム開発のプロジェクトで何度も出現する要件定義に混乱しないように注意が必要です。

関連記事:システム要件定義の進め方・必要成果物とは?

基本設計

基本設計と詳細設計の違いは、設計詳細粒度の違いです。IT初心者向けにもっと分かり易く言うと、要件を元に社内SEや業務部門にレビューしてもらう粒度のシステムデザインを記述したのが基本設計書です。一方、詳細設計は、基本設計書を元に、プログラマーさんたちが実際にコーディングできる程度まで詳細化されたものです。

基本設計では、システムの機能要件や非機能要件に基づいて、アーキテクチャやデータベース設計、インタフェースの設計などが定義されます。典型的な成果物には、システムの概念図、アーキテクチャ図、データフロー図、ユーザーインタフェースのスケッチなどが含まれます。基本設計の目的は、システム全体の設計方針や構造を明確にし、開発プロセスの方向性を確立することです。

詳細設計

詳細設計は、基本設計で定義された概念を具体的な実装に落とし込んでいきます。基本設計で定義された要件や設計方針をもとに、具体的なモジュールやコンポーネントの設計が行われます。スクラッチ開発の場合は、コーディングの設計になり、パッケージ導入の場合は、モジュール等の設定等になります。

詳細設計では、プログラミング言語やプログラミングパラダイム、データ構造、アルゴリズムなどの技術的な詳細が定義されます。典型的な成果物には、クラス図、シーケンス図、データベーススキーマ、API仕様書などが含まれます。詳細設計の目的は、プログラマーや開発チームが具体的な実装を行うための指針を提供し、システムの実装を効率的かつ一貫したものにすることです。

テスト

システム開発におけるテストは様々な種類のテストが存在します。各テストを通して必要な観点を確認し、品質をあげリリースを目指します。

社内SE 1年目から貢献!情シス 企画・開発・運用 107のルール

・単体テスト(UT:Unit Test)=モジュール単位のテスト
・内部結合テスト=開発したシステム内でのテスト
・外部結合テスト(CT:Combined Test)=複数システムの連携も考慮したテスト
・システムテスト(ST:System Test)=システム全体テスト
・受入テスト(UAT: User Acceptance Test)=業務ユーザーによる受入テスト

一言でシステムテストと言っても、システムテストの中に以下要素を考慮し広義でシステムテストと呼ぶプロジェクト・企業文化もあれば、以下のそれぞれのテストを切り出しXXXテストと命名しテストを実施するプロジェクトも存在します。呼び名や位置づけはプロジェクトや企業文化で変わったとしても、どのような観点で何の品質を確認し担保したいのかは同じです。

社内SE 1年目から貢献!情シス 企画・開発・運用 107のルール

あわせておすすめ記事

移行・リリース

システム開発プロジェクトにおける移行は、(大抵の場合)システムアプリケーションだけではなく、業務、データ、運用保守のこの4つの移行やリリースが存在します。システムだけリリースしても、業務運用が移行できていない、データがぐちゃぐちゃでは新しいシステムで業務プロセスを開始する事が出来ません。

社内SE 1年目から貢献!情シス 企画・開発・運用 107のルール

保守・運用

プロジェクトとしてシステム開発を実施しますが、システムリリースが完了し、ある程度システムが安定稼働した段階で、保守運用チームに引継ぎを実施します。企業によっては、システム開発した方の数名がそのまま保守運用チームに流れたり、又は、保守運用チームはシステム開発するメンバーとは全くことなるメンバーで引継ぎを実施し保守運用を実施する場合もあります。

この保守運用も、プロジェクトとしては何もITのシステム運用の話だけではなく、業務運用の話もあります。以下の用語と図で運用の全体感を理解が必要です。

社内SE 1年目から貢献!情シス 企画・開発・運用 107のルール

契約プロセス

システム開発を推進する際には、企業の進め方にもよりますが、Sierと契約し進める場合もあります。上記で書いたように、8割のIT人材がSier所属を鑑みると大抵のシステム導入は何かしら外部リソースを活用し推進します。

従って、例えば以下の図の様に、(1つのモデルですが)要求定義中に契約プロセスを推進し、Sierを要件定義から活用したりします。

合わせておすすめ記事

契約変更管理プロセス

取り決められた契約もプロジェクトの状況により変更が必要です。その場合には、然るべき契約変更を実施するプロセスが必要です。

システム開発の様々な選択肢を抑える

記事の後半では、以下の内容を更に詳しく解説していきます。


システム開発プロジェクトを進める上で、どのように進めるかに大きく影響のある決めなければいけない選択肢は、上図です。どれもシステム開発の進め方に影響があるので認識しておく必要があります。

システム構築の選択肢としては、
どのようなシステム構築を目指すのか?
・業務改善
・BPR
・デジタル化
・DX

なのか選択肢が存在します。

システム構築、あえてシステム開発と言わない部分にも味噌があります。システムは何も自社で開発・もしくはSierに依頼し開発するだけが選択肢ではありません。
・エンハンス開発
・スクラッチ開発
・パッケージ導入
・クラウド利用

様々な選択肢が存在します。

更に、どうやってその決めたシステム構築の手段を進めるかも実際には選択肢があります。
・自社で開発を推進する
・Sierに基本設計以降の開発を依頼する
・Sierにシステム開発だけではなく、それとセットで発生する業務変革も支援を依頼する
・丸投げ、、、してしまう、、、または、丸投げになってしまう(涙)

等々あります。

更に、最後にその決めたスコープのシステム化をどのように開発し進めるかを決めます。
・ウォーターフォール開発
・アジャイル開発
・ハイブリッド開発

等様々です。

システム開発の進め方に対する選択肢の違いによる影響まとめ

事業戦略の選択肢
どのようにプロジェクト自体を進めるか、そもそものシステム開発の推進の仕方に影響

IT戦略
選択する開発やシステム構築の選択肢によりそもそも若干工程が異なる

プロジェクト方針
システム開発の工程のどの部分を誰が担当するのかが異なる

システム構築方針
選択肢によりプロセスが異なる

これをふまえ、更に具体的に様々な選択肢の概要を解説します。

業務改善・改革の手法

プロジェクトでどのように業務改善や改革を狙っていくかの以下の選択肢の違いから解説します。システム開発の工程自体は、どの手法を選択してもほぼ同じです。しかし、どのように要件定義を進めるのか?や、どんなアプローチで業務改善を狙うのかの進め方に大きく影響を及ぼします。

システム構築の選択肢としては、どのようなシステム構築を目指すのか?があります。
・業務改善
・BPR
・デジタル化
・DX

社内SE 1年目から貢献!情シス 企画・開発・運用 107のルール

導入方法ごとの特徴

エンハンス開発とは、スクラッチ開発でも、パッケージ導入でもどちらの場合でもいえる既存改修の意味です。したがって、システム開発の工程自体への影響は、新規導入でもエンハンス開発でも変わりません。

システム開発工程へ変化が生じるのが、スクラッチ開発を実施するのか?それとも、パッケージやSaasなどのサービス利用をするのかです。

スクラッチ開発の場合
起案→プロジェクト立上げ→要件定義→基本設計→詳細設計→開発(コーディング)→各種テスト→移行・リリース→運用・保守

パッケージ等導入の場合
起案→プロジェクト立上げ→要件定義→基本設計→詳細設計→設定作業→各種テスト→移行・リリース→運用・保守

既製品は、既にユーザーに販売する為に、システムが出来上がった状態です。その為、開発をするというよりも、そのソリューションに対して設定をするイメージです。要件定義の進め方等も変化しますが、工程としては同じく存在する為、本記事では詳細割愛します。

補足までにそれぞれの導入方法の特徴をご紹介します。

社内SE 1年目から貢献!情シス 企画・開発・運用 107のルール

Sierをどう活用しプロジェクト推進するか検討する

Sier等の外部リソースの活用は、これまでで解説したシステム開発工程への変化ありません。但し、誰がどの工程を担当するのか?といった役割分担に影響を及ぼします。プロジェクト規模・企業のシステム開発文化・プロジェクト予算等々の要員でどう外部リソースを活用するかは変化します。

以下を参考に、外部リソース活用の一般的なパターンを理解しておきましょう。

社内SE 1年目から貢献!情シス 企画・開発・運用 107のルール

開発手法を検討する

開発手法の選択肢は、システム開発の工程・プロセスや進め方に影響を及ぼします。ここまで解説した、システム開発の工程は、以下のウォータフォール開発の手法でした。このモデルが様々なプロジェクトでかなり多く見かける開発手法です。

IT初心者の方は、まずウォーターフォールの開発手法のシステム開発工程から学び、アジャイルやハイブリッドに知識を広げていけば問題ありません。

以下のシステム開発手法の詳細の前に、どんなシステム開発でよくどのシステム開発手法が選択されやすいか理解しておくと便利です。

よく見かけるシステム開発手法の選択肢

WEB系のシステム開発
→アジャイル開発

特に、対ユーザーに対して情報提供するような仕組みでは、タイムリーな更新で価値提供が可能。

業務系のシステム開発
→ウォーターフォール開発やハイブリッド開発

業務で利用するシステムの場合、早くシステム開発が出来たとしても、既存業務の変更やトレーニングが必要になり、アジャイルで開発したとしてもプロジェクトとしては、バッチでリリースとなる場合が多い。

ウォーターフォール開発

ウォーターフォール開発は工程を1つずつ進めます。前工程が完了したら後工程を進めます。工程管理が容易で品質管理にも優れ、計画を立てやすいのが特徴です。要件を固め、SIerから見積もりを取得して開発に着手します。

社内SE 1年目から貢献!情シス 企画・開発・運用 107のルール

アジャイル

アジャイル開発は、開発単位を細切れにし、スピーディなリリースを目指す手法です。ウォーターフォールに比べると少ない成果物で、開発、テスト、リリースを繰り返して進めます。

社内SE 1年目から貢献!情シス 企画・開発・運用 107のルール

ハイブリッド

プロジェクト全体をアジャイルで進めるのではなく、一部分のみウォーターフォールを取り入れる手法です。1つのモデルは、要件定義や基本設計をウォーターフォールで計画的に推進し、SIer が請け負うシステム構築をアジャイルで進めます。

社内SE 1年目から貢献!情シス 企画・開発・運用 107のルール

IT初心者必見|システム開発の全体の流れ・工程とは?図解ありまとめ

システム開発における一連の工程の流れと、様々な工程に影響を与える選択肢も解説しました。本記事で解説した概要は以下です。

システム開発工程(プロセス)の全体像と各プロセス概要説明
・起案
・プロジェクト立上げ
・要件定義
・基本設計
・詳細設計
・開発・コーディング
・システムテスト
・移行・リリース
・保守・運用
・契約&契約変更

システム開発プロジェクトを進める上で、どのように進めるかに大きく影響のある決めなければいけない選択肢は、上図です。

どれもシステム開発の進め方に影響があるので認識しておく必要があります。

システム構築の選択肢としては、
どのようなシステム構築を目指すのか?
・業務改善
・BPR
・デジタル化
・DX

なのか選択肢が存在します。

システム構築、あえてシステム開発と言わない部分にも味噌があります。システムは何も自社で開発・もしくはSierに依頼し開発するだけが選択肢ではありません。
・エンハンス開発
・スクラッチ開発
・パッケージ導入
・クラウド利用

様々な選択肢が存在します。

更に、どうやってその決めたシステム構築の手段を進めるかも実際には選択肢があります。
・自社で開発を推進する
・Sierに基本設計以降の開発を依頼する
・Sierにシステム開発だけではなく、それとセットで発生する業務変革も支援を依頼する
・丸投げ、、、してしまう、、、または、丸投げになってしまう(涙)

等々あります。

更に、最後にその決めたスコープのシステム化をどのように開発し進めるかを決めます。
・ウォーターフォール開発
・アジャイル開発
・ハイブリッド開発

等様々です。

タイトルとURLをコピーしました