高橋システム開発の工程と流れを簡単に説明する【復習したい人へ】ツイートシェアはてブLINEPocketシステム開発と聞くと、プログラミングのイメージが強いと思う。システム開発でプログラミングをしているのは、ほんの一部の期間でしかない。プログラミングの前に、どのようなシステムを作るのかを要件を聞き出し、各機能の仕様を決定していく必要がある。プログラミングの後にも、様々なテストを行って不具合を修正することになる。この記事では、システムエンジニア歴1〜3年目の若手向けに、システム開発の工程と流れを簡単に説明する。できれば、下記のことを意識しながら読み進めて欲しい。・これまで自分が担当してきた工程はどこか・自分が最も得意な工程はどこか・自分が最も苦手な工程はどこか要件定義が得意であれば、コンサルタントとして年収アップが期待できるし、プログラミングが得意であれば転職先はいくらでもあるだろう。このように自分のキャリアパスを考える上でも、各工程の理解は役に立つはずだ。さいごにシステム開発の工程と流れまず最初に、システム開発の工程と流れをざっくりと説明しようと思う。各工程の呼び方は企業によって異なる場合があるが、やるべきことは同じだ。工程を分けて進めるのは、各工程でQCD(品質、コスト、スケジュール)を管理していくためである。顧客の要件を明確にし、開発見積りを算出する。画面や帳票などの各機能の仕様を決定していく。プログラミングができるレベルに詳細化する。コーディング・単体テストプログラムを作成し、単体での動作を確認する。結合テスト複数のプログラムを結合して実行させ、動作を確認する。総合テスト構築したシステム全体を通して、動作を確認する。運用テスト構築したシステムが要件を満たしているか、顧客が動作を確認する。構築したシステムを本番環境に移行し、動作を確認する。フォロー期間終了後、システム開発は終了となり、運用・保守へと引き継がれることとなる。要件定義〜本番移行・フォローまでの工程は、システム構築のプロジェクトが発足し、プロジェクトメンバーを中心にシステム開発を進めていくのが通常である。それでは、各工程について詳しく説明をしていこう。顧客へのヒアリングで要件を洗い出し、開発するシステムのスコープ(範囲)を決定する。スコープ決定後、システム開発に必要な費用を算出する。要件は、大きく1機能要件と2非機能要件に分けられる。機能要件は画面や帳票やバッチといった実装すべき機能のこと。システムの性能など、機能面以外の要件のこと。もとに、画面や帳票の各機能の仕様を決定していく。画面は、画面と画面の繋がり方(画面遷移)や、各画面のデザインや動作など。帳票は、帳票デザインや発行方法や発行タイミングなど。画面や帳票以外では、バッチ機能の仕様も決めていく。データのバックアップ、他部署や他社へのデータ伝送などはバッチ機能の代表的な例だろう。機能単位に書いているが、詳細設計では機能からプログラムに細分化し、処理の細かい仕様を決定していく。詳細設計書はチーム内部でのレビューのみで、顧客とのレビューは行わない。詳細設計書が効果を発揮するのは、プログラミングを他社や違う担当者に依頼する場合である。逆に言えば、プログラミングも同じ人が担当する場合は、詳細設計書を作るメリットは少なくなってしまう。担当者からすると、さっさとプログラミングをした方が効率が良いと感じ、実際にその通りである。このため、企業や組織によっては詳細設計書を作成しない場合もあるだろう。コーディング・単体テストコーディングは、詳細設計書をもとにプログラム言語を用いて画面や帳票などの機能を実装していく。コーディングのことをプログラミングと呼び場合もある。コーディングの後、詳細設計書やプログラムから、プログラム単体のテストケースを作成し、テストケースに沿ってプログラムの動作を確認する。結合テスト結合テストでは、単体テストが終わったプログラム同士をつなげて動かし、一連のプログラムの動作に問題がないことを確認する。結合テストは、1内部結合テストと、2外部結合テストに大きく分けられる。1内部結合テストシステム内のプログラムを結合させて実施するテスト。プログラム間の連携毎にテストケースを設定する。バッチ・バッチ→バッチ2外部結合テスト2つのシステムを結合させて実施するテスト。営業支援システムと人事情報システムとの間のデータ連携は、外部結合テストで検証する。システム間のインターフェース毎にテストケースを設定する。結合テスト結果をチーム内部でレビューして終了だ。(企業によっては、結合テスト結果報告書を作成して顧客とレビューする場合もある)総合テスト総合テストは、システム開発会社側の最終テストで、構築したシステムの総合的な動作検証を行う。具体的には、要件定義で作成した業務フローをもとにテストシナリオ(テストの流れ)を作成し、機能要件と非機能要件を満たしているかどうかを検証していく。機能要件と非機能要件の定義がキチンとできていないと、検証OKの判断ができないため、苦労することになるだろう。総合テスト結果を報告書としてまとめ、チーム内レビューの後に、顧客レビューを実施して終了となる。運用テスト運用テストでは、構築したシステムを顧客が検証する。顧客は、要件定義書や基本設計書をもとにテストシナリオを作成し、要件が満たされているか、業務運用上の問題がないかを検証していく。開発側の作業は、操作教育やテストデータ作成、問い合わせ回答といったテスト支援だけだが、顧客の代わりにテストシナリオの作成しなければならない場合もあるだろう。テスト終了後、顧客側にて運用テスト報告書を作成し、本番移行へとつながる。※運用テスト報告書は、本番移行前の「本番移行の可否判定」で使用する。顧客担当者の上位者が、本番移行をしても良いか判断するための資料となる。・フォロー計画書フォロー期間中のシステム監視方法や、確認項目などを記載する。フォロー期間が終了すると、プロジェクト完了報告書を作成して、プロジェクトが終了し、運用・保守へと引き継がれる。運用・保守フォローが完了したシステムは、運用・保守へと引き継がれる。システム改善や、システム不具合時の対応などの業務。さいごにシステム開発の工程と流れをざっくりと説明してきた。・システム開発工程は、要件定義〜本番移行・フォローまでの工程に分けられる。・各工程の呼び方は会社によって異なるものの、作業内容はほぼ同じ。この記事を見て「こんなの当たり前じゃないか」と思える人は、システム開発の初心者から卒業と言えるだろう。プログラマーやシステムエンジニアは、自分が担当するプログラムや機能だけに責任があるが、プロジェクトマネージャーになると、構築するシステム全体の責任を負うことになる。システムの品質を確保するためには、システム開発の各工程での品質の作り込みとチェックが欠かせない。各工程の作業内容が理解できていないとボロボロのシステムができあがってしまうのだ。この記事が、若手エンジニアの理解に役立つことを願っている。コメントをキャンセルメールアドレスが公開されることはありません。コメント名前メールアドレスサイト上に表示された文字を入力してください。書き方【サンプル有り】RECOMMENDこちらの記事も人気です。