システム開発プロジェクトの工程について(ウォータフォール基準)

こんにちは。フリーエンジニアの山口です。

前回の記事ではエンジニアとはこういうものだ、エンジニアになるためにはたくさんの勉強が必要、平均年収は。。。と長々と語りました。

今回の記事ではエンジニアがシステム開発する際に行う一連の作業の流れを理解することで開発プロジェクトの全貌についてイメージを掴んで頂けたらいいなと思い、システム開発プロジェクトの工程についてご紹介したいと思います。

主にシステム会社に入社したばかりの方、フリーランスのコーダーの方、これからエンジニアを目指そうと考えている方など、システム開発プロジェクトの参画経験が無い、あるいは一部の工程しか参画したことの無い方向けの記事になります。

システム開発プロジェクトにはどのような工程があって、各工程で何をするのか、受託開発におけるプロジェクトの工程を例としてご紹介します。

開発手法は日本で昔からよく利用されているウォーターフォール開発における工程になります。

ウォーターフォール開発とはまさに滝のように1本の流れに沿って開発を進める手法で、各工程が完了したら後戻りしないのが基本です。要件を細かくドキュメントに定義し、システム設計も同じようにドキュメントにまとめ、それから開発を行う手法になります。そのため、動くシステムを見ることができるのはプロジェクトの終盤になります。

ウォーターフォール開発のほかにアジャイル開発といって、大まかな要件を定義したあとに実際にプロトタイプシステムを開発し、プロタイプシステムに触れながら要件とのギャップを洗い出し、機能追加・修正・レビューを繰り返す手法もあります。

ウォーターフォール開発と違い、早い段階でシステムに触れることができるため、要件のギャップを小さくできることが特徴です。

アジャイル開発においてもウォーターフォール開発における要件定義から開発、テスト工程は存在しており、それらを短期間で繰り返しています。

そのため、まずはウォーターフォール開発の工程でどのようなことを行うのかを学ぶとほとんどのシステム開発プロジェクトで応用することができます。※ ただし、アジャイル開発ではプロトタイプの開発に注力するため、詳細なドキュメント作成は行わないことがほとんどです。

前置きが長くなりましたが、以下システム開発プロジェクトについてご紹介して参ります。

システム開発プロジェクトの流れについて

受託システム開発のプロジェクトは大まかに以下の流れに沿って始まります。

提案 → プロジェクトの準備 → キックオフ

要件定義 → 基本設計 → 詳細設計 → 開発 → テスト → マニュアル作成 → 受入・教育・リリース判定 → リリース

 運用保守

いったんシステムをリリースするところでプロジェクトは終了を迎えます。

あとは運用保守を別のプロジェクトチームあるいは別の会社が引き継ぐケースが多いです。

ざっと上記がプロジェクトの流れになります。

しかしながら、上記だけではいくつかの工程があることがわかっても、それぞれ何をやっているのかわからないですよね。

順番にプロジェクトの各工程について詳細をみていきたいと思います。

(1) 提案

営業部が顧客と商談し、提案の機会を得ます。あるいは既存の顧客よりRFP(提案依頼書)を受けて提案を行います。

提案依頼書にはどのような業務に関するシステムを構築したいのか、ざっくりとした機能リスト、システム構築に使うサーバー環境や開発言語、利用するユーザのPCスペックやOSの種類、ブラウザの種類などが書かれています。

指定された技術で提案するのか、技術選定も含めて提案するのかはRFPに書かれた内容によって異なります。

※ 自社サービス開発の場合は顧客への提案ではなく、社内提案になりますので企画からスタートになります。社内独自のルールはあると思いますが、システム開発における基本的な工程にさほど違いはないと思います。

(2) プロジェクトメンバーのアサイン

提案が通った場合、プロジェクトのマネージャーがアサインされ、プロジェクトマネージャーと部門長の采配でプロジェクトリーダーおよびメンバーのアサインを行います。アサインとは社員の中からプロジェクトメンバーの採用を行うことを指します。

小規模の企業においてはプロジェクトマネージャーが部門長を兼務しており、プロジェクトリーダーの選出とプロジェクトメンバーの選出を行います。

(3) プロジェクトの準備

プロジェクトマネージャーはプロジェクトの準備を行います。プロジェクトの各工程で行う作業を洗い出し、大まかなスケジュールをたて、プロジェクト計画書を作成します。

なお、この準備段階で起こりうるリスクを想定し、その対処方法をまとめておきます。また、WBS、議事録、QA管理、借用物管理、設計書のフォーマット、設計書の記述レベルをあわせるための規約づくりなどを行います。

計画書には以下のような内容を記載します。

・プロジェクトの背景と目的

・プロジェクト範囲

・プロジェクト制約事項

・プロジェクト全体作業の流れ

・プロジェクトにおける成果物一覧

・プロジェクト標準(ドキュメントフォーマット、表記ルールなど)

・プロジェクトの進め方

・プロジェクトスケジュール(全体と直近作業の中日程)

・プロジェクトに必要な資源(開発PC、各種ツール、ソフトウェアライセンスなど)

・プロジェクト体制

・プロジェクト予算

・プロジェクトで想定されるリスクと対処法

・品質目標

・プロジェクトチーム目標

計画書を作成した後は、プロジェクトメンバーの招集と情報共有を行います。

※ 基本的にプロジェクト計画書はプロジェクトメンバーと一緒に作るものではなく、プロジェクトマネージャーが事前に準備するものになります。

プロジェクトマネージャーはプロジェクトのメンバーと顔合わせを行います。同じ会社の社員同士でも一緒に仕事をするのは初めてということもありますので、自己紹介を含めプロジェクトの内容を確認します。

ここでプロジェクトメンバーに大まかな全体スケジュールとドキュメント作成時の注意事項などを共有しておくことが非常に大切で、この工程がただの自己紹介で終わってしまったりすると、ドキュメント作成時に表記揺れの修正や異なるフォーマットで作られたドキュメントの修正作業など、無駄な作業が発生してしまう可能性が高くなります。

(4) プロジェクトのキックオフミーティング

プロジェクトメンバー内での情報共有とは別にお客様とキックオフミーティングと呼ばれる打合せを行います。

お客様側にも当然ながらプロジェクトメンバーが構成されており、お客様側のプロジェクト責任者、プロジェクトメンバーとの顔合わせを行います。

当該ミーティングの目的は双方の認識合わせが主目的になります。

プロジェクトの背景や目的、各メンバーの役割の確認、今後の打合せ方法や予定の確認、プロジェクト内で利用する共通ルール(※)の確認等を行います。

※ 借用物の管理方法、メール送信時におけるルール(件名や添付資料のパスワードルール)、QA管理の方法、連絡先窓口など

以下、当該ミーティング向け資料のサンプル抜粋になります。

上記のような資料を用意してお客様とプロジェクトについて確認します。

会社員エンジニアの方々は上記のような資料を作成する機会がそれなりに多いと思いますが、フリーランスのエンジニアになりますと、自身で直接受託開発を行っていない限り、あまり作成する機会はないかもしれません。

しかしながら、システム構築の目的や背景、プロジェクトが目指すゴール、そしてシステム化対象範囲にスケジュール、コミュニケーション手段(会議体)などはランサーズのようなサイトで仕事を請負う際にも必要なことで、参考になるかと思います。

PowerPointの資料では無くても、最低限箇条書きのテキスト資料で上記の目次内容を確認できるような資料を用意しておくと、どのようなプロジェクトにも役立つと思います。

(5) 要件定義

要件定義フェーズでは、お客様の現行業務の流れを確認し、これから開発するシステムを使ってどのような業務の流れにしたいのか、どのような課題解決を行っていきたいのかを整理する工程になります。

提案の際に大まかな要望は頂いた上で提案を行うのですが、それだけでは具体的なシステム設計に落とすことができません。

また、当該フェーズはお客様が主体のフェーズになります。

当該フェーズではお客様の要件を資料にまとめる作業をサポートするのがシステム開発側の役割になります。

お客様が主体であることはキックオフミーティングで役割分担を説明する際にしっかり伝えましょう。

あまり理解されていないお客様が多いのですが、お客様の業務の流れ、重要なポイントはお客様にしかわからないところですので、改善点を見出すにしてもお客様が主体にならないと、我々エンジニアがサポートできることは非常に限られてしまいます。

業務の中でお客様が課題と感じていない課題を発見するのもこのフェーズになります。

技術的なこと、プロジェクトの予算を視野に入れ、システムが壮大なものにならないように要件を整理します。

当該フェーズにおける成果物は「要件定義書」になります。

要件定義書には新しいシステムでの業務の流れや登場人物について記載します。何の業務で誰がどのような権限を行使して対象の処理を実施するのか、それらをまとめます。

記載項目としては以下の通りです。

・システム名の定義

・システム化の目的

・システム化の範囲

・新業務に登場する人物と組織

・新業務フロー

・ビジネスルール

・業務用語辞書

・システム環境構成

・処理機能一覧

・画面一覧

・画面遷移図

・画面レイアウト

・帳票一覧

・帳票レイアウト

・システムメール一覧

・システムメール送信先定義

・外部システム関連図

・外部システムインターフェース一覧

・外部システムインターフェース定義

・エンティティ一覧

・エンティティ定義

・システムコード一覧

・品質要件

・セキュリティ要件

・運用・障害対策要件

・業務要件一覧

・業務運用要件

・データ移行要件

以下は縦に業務のフローを記載した例になります。

登場人物や組織を縦軸にとって、横方向にフローを記述することもあります。業務フローの記述フォーマットは会社やプロジェクト毎に異なることが多いのですが、一度フォーマットを作っておくと流用することができ、作業も楽になります。

また、このようなフロー図を記載することが多く、罫線を多用することからドキュメントはExcelファイルを使うことが多いです。最近ではGoogleスプレッドシートに記載するプロジェクトもあります。

要件定義フェーズの段階でエンティティやある程度画面のイメージを定義できると、基本設計フェーズではそれらをベースに練り上げていくだけになりますので、要件定義フェーズは非常に重要なフェーズになります。

アジャイル開発においてはドキュメントに細かく定義はしないものの、業務要件をしっかり押さえ、開発を行っていきます。

「要件定義書」をベースに次フェーズ以降の設計書を作成していきます。

(6) 基本設計

基本設計フェーズでは、要件定義フェーズで作成した要件定義書をもとに実際にシステムの設計を行うフェーズになります。

当該フェーズの成果物は「基本設計書」になります。主役は我々エンジニアです。

基本設計書の役割は我々エンジニアがシステム開発する際にも利用しますが、どちらかというとお客様とシステム仕様を確認することを主目的としたドキュメントになります。

各種画面のレイアウト、必要な項目、画面で発生するイベント(データの保存や入力補助ツールの呼び出しなど)、データの保存先などを定義します。

お客様は業務に必要な画面が足りているか、入力項目や表示項目、表示名称に問題ないかチェックします。

基本設計書に仕様をまとめて認識合わせを行うことで、後々仕様漏れなのかシステムのバグなのかの判定に役立てることができます。

アジャイル開発ではこれらの認識合わせをプロトタイプシステムを使ったデモンストレーションで行います。

要件定義書に記載した画面一覧や画面レイアウト、帳票一覧、帳票レイアウト、エンティティ定義などをベースに練り上げていきます。

※ エンティティ定義とは例えば会社組織、社員、社員の所属、商品、商品の発注情報、請求情報等々、システムで利用する「情報やモノ」を定義したもので、DBにおけるテーブル設計に利用します。

例えば画面レイアウトや画面項目定義は以下のような形で定義します。

(7) 詳細設計

詳細設計フェーズでは基本設計フェーズで作成した基本設計書をもとにコーディングできるレベルの処理手順を設計するフェーズになります。もちろん主役は我々エンジニアです。

当該フェーズの成果物は「詳細設計書」になります。

DBのテーブルに至ってはDDLといってSQLのCREATE TABLE文を用意したり、画面から入力されたデータに対し、どのタイミングで入力チェックを行うか、どのように加工してどのテーブルへ保存するか、など詳細を記載します。

基本設計書に対し、実装方法を肉付けしたようなドキュメントになりますので、お客様はあまり意識して参照することの無いドキュメントになります。

詳細設計書を書くことでプロジェクトマネージャーはソースレビューとは別に実装方針の時点で誤りを発見したり、品質管理をすることができます。

また、詳細設計書をベースに単体テストを実施することで将来バグが見つかった時に初期開発の瑕疵なのか、運用保守作業を起因としたバグなのか切り分けに利用されます。

(8) 開発(製造)

いよいよ開発フェーズです。当該フェーズの成果物は言わずもがなですね。はい、ソースコードです。プログラミングを行って実際にシステムを構築するフェーズです。

製造という表現をされることもあるのですが、一般的な製造業とソフトウェアの開発は微妙に違うので私個人の感覚では製造といわれると若干の違和感なり抵抗感なりを感じてしまいます。

それはさておき、開発フェーズはプロジェクトマネージャーによっては単体テストフェーズまでを含めて開発フェーズと呼ぶことがあります。

私もそちらのほうが多い印象です。実際にすべてコーディングし終えてから単体テストフェーズへ進むよりも、画面を作成してテスト、データ取得ロジックを作ってテストなど、プログラミングとテストを繰り返すことが多いからです。

ただ、スケジュールをたてる場合には開発とテストを明確にわけています。

(9) 単体テスト

開発フェーズでプログラミングを行った後は作った機能のテストを行います。

当該フェーズでは「単体テスト仕様書」にテストケースを作成します。

単体テストの「単体」とは一つひとつの機能を指しています。従って、単体テストとは一つひとつの機能が正しく動作するかを試すことを目的としており、それぞれの機能間の連携が正しく動作するかについては基本的にテストしません。

例えばデータ保存処理が正しく動作することをテストしたり、データ取得処理が正しく動作することをテストします。

データを取得処理で取得したデータをデータ保存処理に渡してデータ保存できることまでは確認しません。

機能間の連携が正しく動作するかについては次フェーズの内部結合テストで行います。

ただし、画面入力のテストについては画面とデータ保存等を行うサーバーサイドのプログラムの両方をそろえてテストすることが多く、単体テストであっても内部結合テストと同じようにテストすることがあります。

また、昨今のシステム開発においては、プログラムによるテストの自動化が進んでおり、例えばJava言語における開発においてはJUnitといったテストツールを使い、テストプログラムからテスト対象の機能を呼び出し、正しい結果を得られることを確認します。

テスト駆動型開発という手法で開発する場合には先にテストプログラムを作り、テストが通るようにメイン処理を作成していくので、開発フェーズと単体テストフェーズが同時進行になります。

テストの結果はスクリーンショットで取得して、エビデンス(証跡)として残し、テストで発見されたバグについては修正を行い、再度テストを行います。

テスト回数と発見されたバグの数は集計し、品質管理の指標として利用します。もちろんお客様にもどれだけのテストケース、どれだけのテスト数を行っていくつのバグを消化したのか共有します。

バグが無いことに越したことはないのですが、バグが全く無い場合はテストケース自体の品質が悪い、テストケースに漏れがあることを疑います。

基本的に一定規模のシステムにおいては一定数のバグが含まれているのが通常で、バグが見つかることは悪いことではありません。

このフェーズでバグをしっかり見つけておかないと、後の工程でどつぼにハマります。

(10) 内部結合テスト

内部結合テストフェーズは開発した機能間のデータ連携をテストするフェーズになります。

内部結合テストにおける成果物は「内部結合テスト仕様書」になります。

結合テスト仕様書には一覧画面に登録データが表示できること、登録データを検索表示することができること、登録データの詳細表示画面へ遷移できることなど、各画面から必要な処理を呼び出して期待通りの結果となることをテストするためのテストケースを記載します。

単体テストと同じくエビデンス(証跡)をスクリーンショットで取得します。ただし、操作前後の動きがわかるように取得する必要があるため、操作途中の動きからすべてスクリーンショットで取得します。

基本は1アクション1スクリーンショットになりますが、エビデンス取得作業の負荷軽減のため操作を録画する手法もあります。

また、開始時のデータベースの状態、データを保存したときの状態もエビデンスとして残します。そのため、画面上の表示結果だけではなく、DBのテーブルの状態もエビデンスとして取得する必要がありますので、この証跡集めは思っている以上に大変な作業になります。

(11) 外部結合テスト

外部結合テストフェーズは外部のシステムとの連携テストになります。

例えば、メインのシステムとは別のサーバーにからシステムメールを送信したい場合は外部システムにメール送信リクエストを行います。

メインシステムだけではなく、外部システムへのリクエストが正しく動作するかをテストする必要があり、このようなテストを外部結合テストと呼んでいます。

メール送信の他、会社の基幹システムから社員や組織のマスタデータを連携してもらうといった場合も、データ受信が正しくできることを確認します。

その他、GoogleDriveAPIを利用してファイル保存を行う場合、クラウドサインAPIを利用してクラウドサイン上で契約書の確認を行う場合など、外部システムを利用した機能はすべて外部結合テストフェーズで確認を行います。

外部結合テストフェーズにおける成果物は「外部結合テスト仕様書」になります。

内部結合仕様書と同じくテストケースを記載し、エビデンス(証跡)を取得します。

(12) システムテスト

システムテストフェーズは実際にお客様の業務にあわせたシナリオでテストするフェーズになります。

例えば、業務システムではバッチ処理といって日次、月次で特定の処理プログラムが自動的に実行されていたり、時には数分置きに動いている場合があります。

これらの定期処理を動かしながら、システムの本番利用を開始したかのようにテストするのがシステムテストになります。

実際の業務を行うようにテストを行うのが目的ですので、たくさんのケースを1日で消化するようなフェーズではなく、日数をかけてテストします。

これにより、バッチ処理が特定時間のみ正しく動作しない、業務上発生するレアケースに対応していないといったことに気付くことがあります。

システムテストフェーズにおける成果物は「システムテスト仕様書」になります。

内部結合テストや外部結合テストに近いテストケースになります。

(13) 操作マニュアル作成

外部結合テストフェーズの終わり頃からシステムの操作マニュアルを作成します。そのため各フェーズと異なり、並行して作業するフェーズになります。

当該フェーズでの成果物は「操作マニュアル」です。マニュアルには二種類あり、操作マニュアルと業務マニュアルがあります。

エンジニアが作成するのは「操作」マニュアルです。システムの基本的な操作方法をマニュアルにまとめます。これをもとに業務マニュアルの作成やユーザ教育をお客様が行います。

操作マニュアルは画面の共通部、例えばメインメニュー等の説明から始まり、各画面におけるリンクやボタンからどのような画面に遷移するのか、どのようなアクションが起きるのか、システム機能の操作方法を記述します。

操作マニュアルでは○○業務を行うため〇〇メニューをクリックして、XX画面を開き、△△ボタンをクリックして・・・というような業務を行うための説明は記述しません。

以下は非常に簡易的な操作マニュアルのサンプルになります。画面内の説明ポイントに番号を振り、番号に対応した説明を一覧表で記述します。

(14) 受入テスト、業務マニュアル作成、ユーザ教育、リリース判定

受入テスト、業務マニュアル作成、ユーザ教育、リリース判定はお客様が主体となって行う作業になります。

受入テスト、業務マニュアルの作成はシステムテストフェーズの完了後に行います。プロジェクト期間の短縮のためにシステムテストフェーズと受入テストを並行して行うケースもあります。

受入テストとは開発したシステムがお客様の業務要件を満たしているかどうか確認するテストになります。

受入テストでは実際にお客様がシステムに触れるため、想定していた機能とのギャップにより変更要望が生じる可能性があります。

当該フェーズにおけるエンジニアの役割としては受入テストのサポートとそれらの変更要望対応になります。

お客様は受入テストと並行して業務マニュアルの作成を行います。また、業務マニュアルを利用して実際にシステムを利用するユーザに新業務の流れをレクチャーします。

(15) データ移行とリリース準備

本番利用開始に向けて各種マスタデータの準備、今までの業務で蓄積してきたデータを新システムに移行するフェーズになります。

お客様の受入テストと並行して作業することが多く、移行データの一部を受入テストおよびユーザ教育用データとして利用することがあります。

受入テストおよびユーザ教育終了後、一度データをすべて消去して、再度移行データを取り込み、本番利用の準備をします。

データ移行のためのツールはエンジニアが用意します。移行対象データはお客様側で用意します。

CSVファイルやExcelファイルなど、何かしらフォーマットを定めて移行ツールを用意します。

まとめ

ざっとシステム開発プロジェクトの工程を紹介いたしましたがいかがでしょうか。

個々のドキュメントの詳細まで説明を行うと1冊2冊の本が書けるぐらいのボリュームになってしまいますので、本当にざっくりと全体を紹介させて頂きました。

システム開発プロジェクト全体を通してみると、プログラミングを行うフェーズは全体の一部で、それ以外の作業が多いことがわかるかと思います。

なお、アジャイル開発ではイテレーションといって開発とレビューを繰り返しながらブラッシュアップしていきますので、ウォーターフォールに比べプログラミングを行う時間が多いと思います。

開発手法によって多少の違いはありつつも、ウォーターフォール開発の各フェーズは基本的なシステム開発の工程になりますので、これらのフェーズを理解しておくとその他の開発手法でプロジェクトを進める場合も応用することができます。

フリーランスの駆け出しエンジニアの方はWeb制作案件等を行っていることが多いと思いますが、Web制作案件のような要件が明確でミニマムなプロジェクトではいきなり開発とテストを行ってリリースということもあります。

そのため、開発案件であればすべてが上述の工程を行うわけではなく、規模に応じて省略されるフェーズがあります。

また、ドキュメントのボリュームも変わってきます。中規模案件はおおよそ半年～1年程度のプロジェクト期間になりますが、要件定義書は700~800ページ、基本設計書は1000ページを超えたりします。

小さなプロジェクトでは手厚いドキュメントを作成しても費用が大きくなり過ぎてしまうため、ドキュメントは最小限にして開発を進めることが多いです。

もう一度ウォーターフォール開発におけるプロジェクト全体の流れを確認すると以下の通りです。

提案 → プロジェクトの準備 → キックオフ

要件定義 → 基本設計 → 詳細設計 → 開発 → テスト → マニュアル作成 → 受入・教育・リリース判定 → リリース

 運用保守

以上になります。

説明不足な点も多々あるかと思いますが、参考になれば幸いです。