システム開発の工程と流れを簡単に説明する【復習したい人へ】




システム開発の工程と流れ

システム開発と聞くと、プログラミングのイメージが強いと思う。

しかしながら、システム開発でプログラミングをしているのは、ほんの一部の期間でしかない。

プログラミングの前に、どのようなシステムを作るのかを要件を聞き出し、各機能の仕様を決定していく必要がある。

また、プログラミングの後にも、様々なテストを行って不具合を修正することになる。

 

この記事では、システムエンジニア歴1〜3年目の若手向けに、システム開発の工程と流れを簡単に説明する。

できれば、下記のことを意識しながら読み進めて欲しい。

・これまで自分が担当してきた工程はどこか
・自分が最も得意な工程はどこか
・自分が最も苦手な工程はどこか

要件定義が得意であれば、コンサルタントとして年収アップが期待できるし、プログラミングが得意であれば転職先はいくらでもあるだろう。

このように自分のキャリアパスを考える上でも、各工程の理解は役に立つはずだ。

システム開発の工程と流れ

システム開発の工程と流れ

 

まず最初に、システム開発の工程と流れをざっくりと説明しようと思う。

各工程の呼び方は企業によって異なる場合があるが、やるべきことは同じだ。

工程を分けて進めるのは、各工程でQCD(品質、コスト、スケジュール)を管理していくためである。

要件定義
顧客の要件を明確にし、開発見積りを算出する。

基本設計
画面や帳票などの各機能の仕様を決定していく。
データベースやファイルもここで決定する。

詳細設計
機能毎に、プログラミングができるレベルに詳細化する。

コーディング・単体テスト
プログラムを作成し、単体での動作を確認する。

結合テスト
複数のプログラムを結合して実行させ、動作を確認する。

総合テスト
構築したシステム全体を通して、動作を確認する。

運用テスト
構築したシステムが要件を満たしているか、顧客が動作を確認する。

本番移行・フォロー
構築したシステムを本番環境に移行し、動作を確認する。

フォロー期間終了後、システム開発は終了となり、運用・保守へと引き継がれることとなる。

ちなみに。
要件定義〜本番移行・フォローまでの工程は、システム構築のプロジェクトが発足し、プロジェクトメンバーを中心にシステム開発を進めていくのが通常である。

それでは、各工程について詳しく説明をしていこう。
 

要件定義

システム開発の工程と流れ_要件定義

 

顧客へのヒアリングで要件を洗い出し、開発するシステムのスコープ(範囲)を決定する。
スコープ決定後、システム開発に必要な費用を算出する。
 
要件は、大きく①機能要件と②非機能要件に分けられる。

①機能要件
 機能要件は画面や帳票やバッチといった実装すべき機能のこと。

②非機能要件
 非機能要件は、システムの性能など、機能面以外の要件のこと。

もっと詳しく知りたい方は、下記の記事が参考にしてほしい。

機能要件と非機能要件の書き方〜サンプル付き

機能要件・非機能要件の書き方【サンプル有り】

2018年8月17日

基本設計

システム開発の工程と流れ_基本設計

 

要件定義書をもとに、画面や帳票の各機能の仕様を決定していく。

画面は、画面と画面の繋がり方(画面遷移)や、各画面のデザインや動作など。

帳票は、帳票デザインや発行方法や発行タイミングなど。

画面や帳票以外では、バッチ機能の仕様も決めていく。データのバックアップ、他部署や他社へのデータ伝送などはバッチ機能の代表的な例だろう。

できあがった基本設計書は、チーム内部でレビューを行った後、顧客とのレビューを行い基本設計書を凍結し、次の工程に進む。

詳細設計

システム開発の工程と流れ_詳細設計

 

基本設計書は機能単位に書いているが、詳細設計では機能からプログラムに細分化し、処理の細かい仕様を決定していく。

詳細設計書はチーム内部でのレビューのみで、顧客とのレビューは行わない。

 

詳細設計書が効果を発揮するのは、プログラミングを他社や違う担当者に依頼する場合である。

逆に言えば、プログラミングも同じ人が担当する場合は、詳細設計書を作るメリットは少なくなってしまう。

担当者からすると、さっさとプログラミングをした方が効率が良いと感じ、実際にその通りである。

このため、企業や組織によっては詳細設計書を作成しない場合もあるだろう。

コーディング・単体テスト

システム開発の工程と流れ_コーディング・単体テスト

 

コーディングは、詳細設計書をもとにプログラム言語を用いて画面や帳票などの機能を実装していく。

なお、コーディングのことをプログラミングと呼び場合もある。

コーディングの後、詳細設計書やプログラムから、プログラム単体のテストケースを作成し、テストケースに沿ってプログラムの動作を確認する。

結合テスト

システム開発の工程と流れ_結合テスト

 

結合テストでは、単体テストが終わったプログラム同士をつなげて動かし、一連のプログラムの動作に問題がないことを確認する。

結合テストは、①内部結合テストと、②外部結合テストに大きく分けられる。

①内部結合テスト

システム内のプログラムを結合させて実施するテスト。

プログラム間の連携毎にテストケースを設定する。

例)
 ・画面→画面
 ・画面→バッチ
 ・バッチ→バッチ

②外部結合テスト

2つのシステムを結合させて実施するテスト。

例えば、営業支援システムと人事情報システムとの間のデータ連携は、外部結合テストで検証する。

システム間のインターフェース毎にテストケースを設定する。

例)
 Aシステム → Bシステムへのデータ連携

 Aシステム ← Cシステムへのデータ連携

結合テスト結果をチーム内部でレビューして終了だ。

(企業によっては、結合テスト結果報告書を作成して顧客とレビューする場合もある)

総合テスト

システム開発の工程と流れ_総合テスト

 

総合テストは、システム開発会社側の最終テストで、構築したシステムの総合的な動作検証を行う。

具体的には、要件定義で作成した業務フローをもとにテストシナリオ(テストの流れ)を作成し、機能要件と非機能要件を満たしているかどうかを検証していく。

 

機能要件と非機能要件の定義がキチンとできていないと、検証OKの判断ができないため、苦労することになるだろう。

総合テスト結果を報告書としてまとめ、チーム内レビューの後に、顧客レビューを実施して終了となる。

運用テスト

システム開発の工程と流れ_運用テスト

運用テストでは、構築したシステムを顧客が検証する。

顧客は、要件定義書や基本設計書をもとにテストシナリオを作成し、要件が満たされているか、業務運用上の問題がないかを検証していく。

開発側の作業は、操作教育やテストデータ作成、問い合わせ回答といったテスト支援だけだが、顧客の代わりにテストシナリオの作成しなければならない場合もあるだろう。

テスト終了後、顧客側にて運用テスト報告書を作成し、本番移行へとつながる。

 

※運用テスト報告書は、本番移行前の「本番移行の可否判定」で使用する。

顧客担当者の上位者が、本番移行をしても良いか判断するための資料となる。

本番移行・フォロー

システム開発の工程と流れ_本番移行・フォロー

 

本番移行に向けて、本番移行計画書とフォロー計画書を作成する。

・本番移行計画書
移行方法やスケジュール、移行体制、障害発生時の対応方法などを記載

・フォロー計画書
フォロー期間中のシステム監視方法や、確認項目などを記載する。

 

フォロー期間が終了すると、プロジェクト完了報告書を作成して、プロジェクトが終了し、運用・保守へと引き継がれる。

運用・保守
フォローが完了したシステムは、運用・保守へと引き継がれる。

・運用
システム稼働が停止しないよう監視をしたり、ユーザーからの問い合わせに回答するようなルーチン業務。

・保守
小規模なシステム改善や、システム不具合時の対応などの業務。

さいごに

システム開発の工程と流れをざっくりと説明してきた。

・システム開発工程は、要件定義〜本番移行・フォローまでの工程に分けられる。

・各工程の呼び方は会社によって異なるものの、作業内容はほぼ同じ。

この記事を見て「こんなの当たり前じゃないか」と思える人は、システム開発の初心者から卒業と言えるだろう。

 

プログラマーやシステムエンジニアは、自分が担当するプログラムや機能だけに責任があるが、プロジェクトマネージャーになると、構築するシステム全体の責任を負うことになる。

システムの品質を確保するためには、システム開発の各工程での品質の作り込みとチェックが欠かせない。

つまり、各工程の作業内容が理解できていないとボロボロのシステムができあがってしまうのだ。

この記事が、若手エンジニアの理解に役立つことを願っている。
 






コメントを残す

メールアドレスが公開されることはありません。

CAPTCHA