【SI業界】システム開発の流れ～マスタスケジュールとメンバー数の推移、各工程作業～【就活生向け】
【本記事は、SI業界志望の就活生等の初心者向けの内容です】
前回の記事でシステム開発の概要や体制図、メンバーの役割を説明しました。今回はシステム開発のマスタスケジュールとプロジェクトメンバーの人数の推移、そして各工程の作業内容について説明していきます。
ありきたりな工程作業の説明は省き、できるだけシステム開発のイメージが湧くように現場のプロジェクトをイメージして説明します。
マスタスケジュールとプロジェクトメンバー数の推移
システム開発では、まずはじめに「要件定義」と呼ばれる工程から始まります。
ここではお客様からどんなシステムを作りたいのかをヒアリングし、要件定義書としてまとめます。
（具体的な作業内容は本記事の下部にまとめます）
要件定義書が完成すると次は見積りに入ります。「見積り」ではお客様からの要望をどのぐらいの期間・人数でこなせるか見積り、お客様と金額の交渉を行います。
交渉の結果、以下のようなマスタスケジュールとプロジェクトメンバー数でプロジェクトを進めることが決定します。 ここでやっとシステム開発のプロジェクトの全貌が見えてきます。
システム開発の各工程作業内容
上記のマスタスケジュールをご覧いただくと分かる通り、システム開発のプロジェクトではメンバー数が大きく変動します。
これは各工程で必要とされる作業内容と作業量が異なるからです。
それでは実際に各工程の作業内容を見て行きましょう。
プロジェクトメンバー数の推移と合わせて見てもらえるとイメージが湧きやすいかと思います。
ちなみに本記事では一般的な工程の定義ではなく、具体的な作業イメージでまとめます。
※一般的な工程作業については「システム開発 工程」等でググってみてください。
| 工程名 | 主な作業内容 | 説明 |
|---|---|---|
| 要件定義 | ・お客様との打合せ ・要件定義書作成 ・見積り作成 |
要件定義書と見積りを作成することがゴールになります。 お客様に聞きたいこと（要件定義書の記載内容）を整理して、何度も繰り返し打合せを行います。 |
| 基本設計（BD） | ・基本設計書作成 ・内部レビュー ・お客様レビュー |
要件定義書をインプットに、お客様に見える画面や帳票等の詳細を定義します。 機能単位に担当者を決めて基本設計書を作成し、チーム内部でレビューを行います。 レビューは指摘を取り込んで何度も実施することが多いです。 内部でのレビューが終わったらお客様にもレビューしてもらいます。 |
| 詳細設計（DD） | ・詳細設計書作成 ・内部レビュー |
基本設計書の内容をどのようにPGMで実現するか検討し、PGM単位で詳細設計書としてPGが作成します。 それを基本設計を担当したSEがレビューします。お客様は出てきません。 なお記載のレベル感はプロジェクトによって全然違います。 |
| 製造・単体テスト （M/UT） |
・プログラム作成 ・単体テストケース作成 ・単体テスト実施 ・単体テストケース/結果レビュー |
詳細設計書をもとにPGがプログラムを作成します。 完成したらテストケース（パターン）を作成し、PGM単位で詳細設計書通りに動くことを検証します。 SEはテスト結果のレビューや各種ルール作り、テストで発見したバグ対応等を行います。 |
| 結合テスト（IT） | ・結合テストケース作成 ・結合テスト実施 ・結合テストケース/結果レビュー |
単体テストでPGM単位で検証を行いましたが、その範囲を機能単位での検証に拡大します。 結合テストでは基本設計書通りに動くことを検証します。 基本設計レベルの検証のためテストケースをSEが作成し、テスト実施をPGがやることが多いと思います。 |
| 総合テスト（ST） | ・総合テストシナリオ作成 ・総合テストケース作成 ・総合テスト実施 ・総合テストケース/結果レビュー |
総合テストでは要件定義の内容通りにシステム全体が動くのかを検証します。 具体的には要件定義で作成した業務フローをもとに、まずテストシナリオ（テストの流れ）を作成します。 それをさらに詳細な確認ポイントを記載したテストケースに落とし込みます。 開発側のテストとしてはこれで終わりになるので、ここでバグを出し切る必要があります。 |
| 受入テスト（RT） | ・お客様のテストのヘルプ ・お客様問合せ対応 |
受入テストは基本的にお客様でのテストなので、開発側が主体的に実施する作業はありません。 テストを実施するための準備を手伝ったり、問合せ対応を行ったりします。 ただお客様がシステムに詳しくない場合など、ケース作成から開発側でやることもあります… |
各工程作業の成果物サンプルまとめ
上記の説明だけで分かれば天才です。実際のサンプルを見ないとよくわからないと思うので、各工程で作成する成果物について、具体的なイメージが載っているサイトを紹介します。
＜要件定義書＞
Kaleido Modeling » rcp-srs-01:要件定義書
※記事中央の「でき上がりサンプル」を見るとサンプル（PDF）が見れます。
＜基本設計書＞
［画面設計］画面の構造は物理的・論理的に示す
※記事右上の「連載目次へ >>」を見るとさらにたくさん見れます
＜詳細設計書＞
詳細設計書はプロジェクトによって全然違いますが、いくつか見たことあるようなサンプルがあったので紹介します。
＜単体テストケース＞
[ThinkIT] 第6回：単体テスト仕様書＆報告書 (3/3)
＜結合テストケース＞
以下サンプルで「シナリオ」や「ケース」という言葉が使われていますが、プロジェクトによって使い方が違います。そのためあまり言葉を気にせず、どんなことを実施しているかという観点で見ていただいたほうが良いと思います。
[ThinkIT] 第7回：結合テストと総合テスト (1/3)
＜総合テストシナリオ／ケース＞
あまり良いサンプルが見つかりませんでした。良いサンプルがあれば紹介頂けると幸いです。
総合テストは業務の流れをベースに動作を確認するのが目的なので、業務のパターンがシナリオになります。さらに業務のパターン毎に何を確認するか（画面や帳票、データなど）を記載したものがケースとなります。
まとめ
今回はプロジェクトのマスタスケジュールやプロジェクトメンバーの人数の推移、そして各工程の作業内容についてまとめました。なんとなくプロジェクトの全体像と流れがわかってもらえると嬉しいです。
はじめは分からないことだらけだと思いますが、一つ一つ順を追って理解していけば全体像がつかめてくると思いますので、根気よく確認していってください。
今後は各工程の詳細やその他のトピックについて、もう少し掘り下げた内容をまとめていきたいと思いますので、よろしければご覧頂ければと思います。
