このページでは、一般的なシステム開発の流れを会社に入りたての新入社員の方でも理解しやすいように簡単に説明しています。
（目次）
やること一覧
システムを開発する上でのやることを大まかに記載しました。まずは、大きな視点でやることをイメージしてみましょう。こう見てみると、そんなに難しくありませんよ。
次章で、もう少し詳しく解説していきます。
| 大分類 | 実施内容 | やること | |
| 開発 準備 |
システム化計画 | どんなシステムを作るか考える | |
| 社内説明・決裁 | 上司を説得し、開発費用を確保する | ||
| ベンダー選定 | 開発する会社（ベンダー）を決める | ||
| 開発 | 要件 定義 |
ユーザー要件定義 | 発注会社側がやりたいことを決める |
| システム要件定義 | やりたいことをもとにシステム機能を決める | ||
| 概算費用・工数見積り | 大まかな費用・開発工数を算出する | ||
| 設計 | 基本設計（外部設計） | システムの画面やデータの流れ等を考える | |
| 詳細設計（内部設計） | システム開発のやり方を考える | ||
| 運用設計 | システム運営のやり方を考える | ||
| 詳細費用・工数見積り | 最終的に必要な費用・開発工数を算出する | ||
| 開発 | インフラ環境構築 | システムを動かすサーバや各種機器を用意する | |
| プログラミング | システムをプログラミングする | ||
| テスト | 単体テスト | プログラム単位で動作を確認する | |
| 結合テスト | 機能ごとで動作を確認する | ||
| 運用テスト | 運営を考慮してシステム全体の動きを確認する | ||
| 本番 切替 |
切替判断 | テスト結果や操作性などを考慮して、 開発したシステムを使うかどうか決める |
|
| 利用者説明 | 利用者へ操作方法や利用開始日を説明する | ||
| システム切替 | 開発したシステムを使い始める | ||
| 通常 利用 |
日常運用 | 運用設計の内容や問い合わせ対応を行う | |
| 利用結果報告 | 利用開始後の稼働状況を報告する | ||
開発準備
まずは、システム開発を行う前の下準備を始めます。
システム化計画
どんなシステムを作るのか、システム化の全体計画を行います。
システム化の目的や背景、システム概要、開発期間など、全体的にどんなことをやろうとしているのかを考えましょう。
主にA3資料の書き方で記載している内容を考えます。
【テンプレート付き】トヨタ系企業で古くから使われているＡ３資料の書き方を説明します！
社内説明・決裁
「システム化計画」で考えた内容を関係者（社長等決裁権者）に説明し、決裁をとります。
ここでの目的は、こんなシステムを作るんだ！ということを決裁権者に認知・納得してもらうことと、開発予算を確保することです。
ここで、決裁権者にちゃんと説明して、納得してもらっておくと、今後の定期報告やトラブル報告などがスムーズにいきます。
面倒でもちゃんと納得してもらったうえで進めましょう。
ベンダー選定
システム開発を行う会社（ベンダー）を選定します。
もし、付き合いの深い開発会社があるのであれば、その会社に開発を依頼します。
特にないようだったら、複数の会社にRFP（提案依頼書）を出して、開発提案してもらうケースもあります。（RFPに書く内容はシステム化計画で考えた「どんなシステムを作るのか？」です。）
ベンダーの選定基準は「誠実さ」を重視した方がよいです。
この段階で出てくる費用はあてになりませんので、費用は参考程度にしかなりません。開発時の対応やシステムリリース後のサポートなど長い目で見ると「誠実さ」が最も重要です。
開発
次に実際の開発工程に移ります。
要件定義）ユーザー要件定義
ユーザー要件定義では、発注側企業（ユーザー：利用者側）企業のやりたいことを決めます。システム化計画の内容を具体化していく感じです。
システム開発全体に関係してくるので、開発ベンダーに任せっきりにするのではなく、発注者側が何をやりたいのかを考えましょう。
なお、画面やプログラム構成の検討などは、この後のシステム要件定義や各種設計で開発ベンダー主体で行います。ユーザー要件定義は、イメージ図や言葉でやりたいことが定義できていれば、ＯＫです。
要件定義）システム要件定義
システム要件定義では、ユーザー要件定義の内容を受けて、開発ベンダーが具体的なシステム構成を決めていきます。
やりたいことをシステム化するには、機能をどのように分割して、画面にはどんな内容を表示して、機器はどんなものがいるのか・・・などを定義していきます。
発注者側の立場で考えると、なかなか理解しにくいものもあったりすると思いますが、開発ベンダーの言ってることがわからない場合は、堂々と「わからない！」と言って、説明を求めましょう。
うやむやのまま進んでいくと、そこが落とし穴になってトラブルが発生したりすることも多いです。
あと、開発ベンダーの担当者がちゃんと説明してくれなかったり、不誠実な対応をされる場合は、担当者を変えてもらうか、場合によっては、開発ベンダーの変更も検討しましょう。この段階であれば、傷口が浅くて済みます。
要件定義）概算費用・工数見積もり
システム要件定義まで終わったら、概算費用が算出できます。
開発ベンダーからシステム化機能、概算工数（〇〇時間）、概算費用（〇〇円）の見積もりが出てきますので、機能が合ってるか、概算費用は、当初のシステム化計画で賄えるかを確認しましょう。
賄えない場合は、基本的には、必要ない機能を削る形になります。開発ベンダーと相談しながら、必要不可欠な部分を残しつつ、機能を絞って、費用削減していきましょう。
設計）基本設計（外部設計）
設計）詳細設計（内部設計）
設計）運用設計
設計の段階まで来ると、開発ベンダーが主体の工程になります。
開発ベンダーから、システムの画面イメージやデータの入手元などについて、確認がありますので、確認しましょう。（画面配置はこれでいいか？とか社員データはどこから入手するのか？とか聞かれます。）
特に、運用設計に関しては、システムリリース後の運営に関わりますので、定期的にやらなければいけない作業など内容をしっかり確認しましょう。
設計）詳細費用・工数見積もり
システム設計を通して、ほぼシステムの内容は決まりますので、詳細費用・工数の見積もりがあります。
要件定義の段階から、特に変更が無ければ、概算費用とほぼ同じだと思いますが、要件の追加（やりたいことの追加）やシステム化の考慮漏れなどがあれば、増えている場合もあります。
概算見積りと同様に内容確認し、必要に応じて、費用削減をしてください。
開発）インフラ環境構築
開発）プログラミング
開発工程も開発ベンダーが主体の工程です。
システムを動かすためのサーバや各種機器（ネットワーク機器など）等インフラ環境を整備し、プラグラムを作っていきます。
もし、クラウド環境を利用する場合は、物理的な環境構築がない場合もあります。
クラウドサービスとは？ＩａａＳ、ＰａａＳ、ＳａａＳの違いや選定方法を解説
テスト）単体テスト
単体テストは、開発ベンダー主体の工程です。
不具合の数がどれくらいあったか、とか、想定通りのテスト内容がどれくらいだったか等で、テスト内容を評価したりしますが、基本、テスト結果報告の内容確認のみでOKです。
テスト）結合テスト
結合テストは、発注者側も積極的に参加し、内容確認しましょう。
システムリリース後の修正や利用者からのクレームにならないよう、気になる点はここで納得いくまで確認しましょう。発注者側でしかわからない部分もありますので、気になる部分は指摘してあげたほうが開発者も助かります。
・当初「システム化計画」でやりたいと思っていたことが、実現できているのか？
・設計通りの画面／機能なのか？
・利用者にとって、使いやすい操作性になっているのか？
テスト）運用テスト
運用テストは、システムリリース後の通常利用を想定したテストです。
結合テスト同様に、システム全体を通して、おかしな部分がないか、辻褄があっているのか、気になる部分は納得いくまで確認しましょう。
本番切替
開発・テストが終わって、いよいよ、システムをリリースする工程です。
切替判断
切替判断は、テスト結果の内容を見て、システムをリリースするかどうかを決める工程です。
テスト結果が特に問題なければよいのですが、問題がある場合、妥協した状態でもシステムリリースするのか、リリースを延期して、再度開発を行うのかを判断します。
利用者説明
システムリリースが決まった後、利用者に対して、説明を行う工程です。
システムの目的や操作手順、リリース開始日などを案内します。案内方法は、さまざまで説明会を開催する場合もありますし、ポータルサイトへの掲載で済ます場合もあります。
システム切替
新システムへの切替を行う工程です。
切替日当日にトラブル発生することは、多々あります。
トラブル発生に備え、切替手順書の準備、開発ベンダー責任者の連絡先、関係システム担当者の連絡先、社内トラブル発生時の連絡先、利用者への案内方法など、事前に準備できることは準備しておきましょう。
通常利用
システムリリース後の通常利用時の工程です。
日常運用
運用設計の内容やシステムの問い合わせ対応を行います。
定期報告会や今後のシステム改善のために問い合わせ対応履歴をとっておくとよいです。
利用結果報告
システムリリース後に、決裁権者や社内責任者に対して、利用結果報告を行います。
利用者からの問い合わせ内容、システム利用状況、トラブル内容、システム化計画で当初考えていた効果が得られたか（得られそうか）など、開発したシステムに応じて、結果報告を行います。
発注者目線でみたシステム開発の流れは、以上です。
