【工程定義】要件定義設計テスト一連の工程を一挙解説

IT業界に入っていくつかの部署、プロジェクトを経験したが、現場によってプロジェクトにおける工程定義が結構曖昧な印象がある。会社内では標準の工程定義があるところも多い気がするが、顧客との付き合いが長いような客先分室だと、顧客側の工程定義の言葉が定着していて、社内向けの報告と顧客への報告とで認識がぶれることがある。そして往々にしてズレていく。そもそも社内標準があってもそれが我らがipaさんの定義と若干ズレていたりすると、社内の人同士でも認識がずれる。そしてベテランになる程、改めて確認しづらく認識が合うことは一生ないと言っても過言ではない。

そして、最悪の場合、実施すべき工程が抜け落ちることで、品質が悪化したり、デスマーチに巻き込まれたりと、誰も良い思いをしない。

今回はプロジェクトマネージャが一番最初にやるべき、そして最も重要と言っても過言ではない工程定義について私なりの解釈で解説・整理したいと思うので、何かの参考になればうれしいです。

工程定義の意義

プロジェクトマネージャ（PM）がプロジェクト計画の立案・作成をするうえで一番重要と言っても過言ではないのがプロジェクトの工程定義だといえる。

このプロジェクトを成功するためにどんな作業が必要になるのか大きな枠組みで考えていくこと。

そして、この工程定義が一番難しく、PMの腕の見せ所が”プロジェクトの特性を踏まえた検討をすること”である。そう、いわゆるテーラリングってやつ。

システム開発に限らず、プロジェクトとはそもそもが独自性のあるものであり、類似性はあっても同一のものは決して存在しない。

プロジェクトごとに求められることも異なり、制約・条件（期間、コスト、品質）も異なり、関係してくる利害関係者も異なり、プロジェクトを遂行するメンバも同じではない。

だから、プロジェクトの特性を踏まえて計画をする必要がある。

たまに、プロジェクトの特性を無視して、去年のあのプロジェクトと同じだからという暴論で工程定義を適当に考えるなんちゃってPMがいるが、決してマネしてはいけない。反面教師にすべきである。

工程定義の具体例

前述した通りプロジェクトによって実施すべき工程は異なる。

したがって、これという正解はないし、前のプロジェクトでは単体テスト仕様書の作成を単体テスト工程の中で実施したけど、この現場では内部設計工程の中で実施するとか、製造工程で実施するとか、同じ作業でもどの工程にその作業を配置するかが変わってくることもある。

とはいえ、私なりの経験と様々な書籍、ネットでの様々な意見をもとにできる限り細分化しつつ定義してみた。

まず、絶対的真理として抑えておくべきことは、システム開発は大きく、作るものを決め、実際に作っていく「検討・開発フェーズ」（いわゆる、開発）と作ると決めたものと実際に作ったものが正しかったかどうかを確認する「検証フェーズ」（いわゆる、テスト）に分かれる。

そして、一番大事なのが検討・開発したものをどの段階で検証するかを決めていくにある。

よく低品質でトラブルになるプロジェクトは、検討・開発したものを検証するフェーズが実施されていないまま工程が進み、問題が検知されることなく、火を噴くことになる。

わかりやすい例でいえば、要件定義にて非機能要件の１つに”操作性を考慮して画面操作してから原則２秒以内に反応があること”と定義しているなら、パフォーマンステストをしなければいけないし、機能定義として”受注処理後の返品処理は決済バッチが完了するまで”と決めたのであれば、”決済バッチが完了済の場合は返品処理ができないこと”を単体テストや機能テストなりで検証しなければいけない。

なお、「検討・開発フェーズ」と「検証フェーズ」の紐づけを記したが、これも答えはない。むしろこれもプロジェクトごとに定義すべきである。

以降は、順に各工程について解説していく。

工程説明

要求分析

RFPに記載されているやりたいことを確認。そもそも何がしたいのかを確認し、やりたいこと一覧を整理する。

５W1Hをもとに何が課題でどのように解決するかを検討し案を出す。この時の解決策はシステムに限らず、業務の変更などの代替案も含める。

企画・構想といった大枠でのBeforとAfterの整理。したがって、AsIsとToBeを整理することもここに含まれてくる。ただ、イメージ的にはよりプロジェクトの方向性を決める大方針的な感じがしっくりくる。

主な作成物：要求事項一覧、システム鳥観図、（新業務フロー）、（新業務一覧）

業務要件定義

どのような業務にしたいのか。業務のAsIs、ToBeの整理。

パッケージシステムの導入であれば、このフェーズをFit＆Gapと定義することもある。FitとGapを定義して、Gap一覧を作成することもここに入ってくる。

業務フローを描くことで、業務のどこでどのようなシステム・機能が関わってくるかを明確にする。

主な作成物：新業務フロー、新業務機能一覧、業務定義書

システム要件定義

業務要件定義で決めた業務を実現するうえでの機能を決める。

もう少しシステム要件定義を細分化すると以下のような分類になる。

移行要件や運用要件については、システム要件定義の段階では実施せず、工程後半に開発プロジェクトとは別立てで実施するようなプロジェクトもある。

◆機能要件

主な作成物：画面レイアウト定義、システム機能定義、機能一覧

◆情報要件

主な作成物：データ一覧、情報子定義、データ区分、概念ER図

◆非機能要件

主な作成物：インフラ定義書、ユーザビリティ、ユーザインタフェース

ユーザインタフェースの例：一覧表示方法、メッセージ表示方法、文書ルール（英字は半角？全角？）、入力補完（カンマスラッシュの自動入力、コードから名称取得など）、データチェック（タイミング、方法）、タブ順などなど

◆移行要件

主な作成物：データ移行要件定義書、システム移行要件定義書

◆運用要件

主な作成物：システム稼働後の保守体制、保守チームへの引継ぎ方法

※運用チームを同時に立ち上げるような新システムの場合は、運用設計が別途後続で必要になる。

また、忘れがちだが、後続工程の見積を作成するための見積作業もこの工程の立派なタスクである。

システム設計

データフロー、論理DB設計、共通設計、データフロー設計（データの流れの定義）

また、DB設計完了後にDB実装（テーブル作成・更新・インデックス生成など）もこの工程で実施する。

DB実装については外部設計にて各画面担当者が個別に実施するような場合もあるが、規模が大きいプロジェクトであったり、機能数が多い、参画者が多いプロジェクトの場合、責任範囲を決めづらくなるのでこの工程でまとめて実施するのがおすすめである。

例：データフロー設計

マルチカンパニー対応で一方の会社（A社）が発注登録を行うと、もう一方の会社（B社）の受注を作成するような仕組みを実現する場合に、A社の発注番号がB社の受注テーブルの得意先発注伝票番号に設定されるといったような各データがどのように流れ、繋がっていくかを定義する。

例：共通設計

メニュー構成や色味、ロゴの設計もこのタスクに相当する。その他に、各画面や機能から共通的に呼び出される機能の開発もこのタスクに当たる。例えば、受注登録時と在庫引当時でそれぞれで納期計算が行われる場合、この納期計算処理を共通処理化し、納期計算に関する処理設計をすることになる。また、そもそもどの部分を共通化するかについてもこのシステム設計の中で実施していくことになる。

主な作成物：DB設計書、データフロー図、IF項目定義

業務要件定義➡システム要件定義➡システム設計についてはできれば、純粋なウォーターフォールではなく、同時並行で進めつつ、何度かサイクルを回すのが理想。

どうしても、IF項目定義を詰めるときや、画面レイアウトを定義する中で、DB項目を追加する必要が出てきたり、それによってデータフローを修正する必要が出てきたり、業務要件定義を一部修正する必要が出てきたりすることは避けられてないからだ。

ただし、永遠にサイクルを回す訳にもいかないので、そこは要件定義のマネジメントとしてしっかりコントロールする必要があるので要注意。

外部設計

画面、機能ごとの設計、ユーザ部門が見て判断できる内容で記載することを意識する。

基本設計と呼んでいる現場もかなり多い。

システムの言葉ではなく、業務の言葉で記載することが重要である。

また、外部設計では２つの側面を区別しながら定義していくとより明確になる。

〇システム（画面・機能）に対する入出力を定義

例：月（2020/12）を入力したら、その月の総売上を表示する

〇システム（画面・機能）の処理順序を定義

例：入力した月(2020/12)をもとにその月の売上履歴を集計し、売上額の合計を画面に表示する

主な作成物：外部設計書

外部設計までが「検討・開発」フェーズにて顧客の意見が入ってくる部分であり、これ以降のフェーズは決まった内容についてシステムに落とし込む工程に入っていくことを意識すること。

なお、外部設計にて顧客レビューを受ける際、顧客側のITリテラシーや負荷、参画度合いを鑑みて、処理順序までのレビューは受けず、入出力定義までのレビューとすることもある。（実際、処理順序を説明されても理解できない顧客、レビューしている時間が取れない顧客が多いイメージ）

内部設計

処理設計。コーディング、システムに落とし込むためのもの。

詳細設計と呼ぶ現場もかなり多い。

〇システム（画面・機能）が行う処理をシステム的な表現に換える

例：”売上履歴テーブルの売上日が20201201<=　AND <=20201231の範囲で集計する”など

内部設計をもとに単体テスト仕様書を作成する。ここで作成することで処理パターンの抜け漏れを防ぐことができる。実装・コーディング工程で作成することもあれば、単体テスト工程で作成することもあるので、はっきりしない部分ではあるが、個人的にはなるべく早い段階で作成するのが望ましいという立場である。

主な作成物：内部設計書、（単体テスト仕様書）

プログラム仕様書

あまり作成することはない。実装内容を文字に起こしたようなもの。フローチャートは内部設計書に記載することはあるが、わざわざ工程として設けることはまずない。

変数宣言、変数初期化なども記載する。プログラマー初心者が自身の実装の下地として作成する効果は一定あるだろう。

作成物：アルゴリズム仕様書、フローチャート

実装・コーディング

いわゆる、プログラミング。内部設計、プログラム仕様書をもとに作成する。

クライアント層、ビジネスロジック層、DB層で分かれている場合は、xxx.jsp、yyy.java、zzz.javaといった具合にプログラムファイルごとに作成。

主な作成物：プログラム

コードレビュー

いよいよここからが「検証」フェーズに入る。

まず、前提として「検証」フェーズの各工程はその工程で何を検証するのかという観点を明確にして臨むようにすることが重要である。

また、レビュー工程について記載はしてこなかったが、コードレビューについては実施するプロジェクトもあれば実施しないプロジェクトもあるため、言及しておく。逆に言えば、これ以外の工程についてはレビューが必ずあるといってよい。

実際のプログラムを一定の基準をもとに有識者が目検でレビュー。闇雲に実施するのは工数の無駄遣いになる。きちんとルールを設けておくべきである。

主な観点は、エラーハンドリング、NULLチェックの有無、変数宣言/初期化の有無など。

また、重要な機能や経験の浅いメンバが作成したプログラムに絞ってレビューしたり、逆にこれらの機能について品質を上げるために主な観点以外の視点でも有識者がしっかりチェックしたりなども有効的。

主な作成物：レビュー表

単体テスト(UT)

内部設計（プログラム仕様書）に沿って作成したテスト仕様書をもとにテスト。よく言うホワイトボックステスト。前述した通り、ここで単体テスト仕様書を作成することもあるが非推奨。

テストデータの作成はこの工程で行うことになる。よく炎上しているプロジェクトだと、テストデータの作成に時間がかかってテスト消化が進まないという声が頻繁に聞こえてくる。これはテスト工数の見積が甘いことや、テスト実施者が仕様をわかっておらず、設計者にテストデータの作成方法を聞きながらでなければ実施できないことなどの原因が考えられるが、先んじて対処が必要。

プログラムファイルが複数存在し、それぞれで動作検証ができる場合はそれぞれで実施することも可だが、現実的には１つの機能（画面）にしたうえでテストする。

主な作成物：単体テスト仕様書及びその結果

機能テスト

１つの画面、機能としてのテスト。単体テストと一緒に行われることが多く、あまり区別されることも少ない印象。ただ、単体テストがクラスファイルごとのテストであったり、クライアントのみのテスト、ビジネスロジックのみのテストに留まっている場合は、機能テストを実施することで、１つの機能、画面として成立させることが必要。

主な作成物：機能テスト仕様書及びその結果

内部結合テスト(ita)

超平たくいえば、画面遷移のテストであり、機能同士がつながるかどうかのテスト。

外部設計書もしくは内部設計書に記載されている画面遷移通りに遷移できるかどうかのテスト。

前工程までで完成したすべての画面、機能を繋げていく作業である。

テスト工程でスタブやドライバを作成してテストしていた場合はこの工程を省いたり、そもそもいきなりシナリオテストに進んだりすることもある。

ただ、シナリオテストの不具合件数が異常に跳ね上がるリスクの軽減やシナリオテストで検出すべき不具合を適切に抽出するためにはこの工程はあった方が良いだろう。この工程をしっかりと設けているプロジェクトで品質面のトラブルを抱えているものは少ない印象がある。

プロジェクトによっては単体テストが早く終わったメンバが複数の画面、機能を繋げてみてモンキーテスト的に叩いてシナリオテストの前にバグだしすることもある。ただ、やっぱり工程として定義するのが理想。

主な作成物：内部結合テスト仕様書及びその結果、画面遷移テスト仕様書及びその結果

外部結合テスト(itb)

サブシステム間の機能を繋げてみる。内部結合テストよりも広い視点でつながるかどうかを検証する。

複数システムが存在しないような場合は実施しないこともある。

また、自社管轄ではないシステム（＝対向システム、IF連携先システム）との連携テストは後続工程で実施するイメージ。この工程はあくまで内部結合テストの範囲を広げたイメージ。

私もあまり経験がない。

主な作成物：外部結合テスト仕様書及びその結果、サブシステム間連携仕様書及びその結果

ここまででアプリケーションとしては動くものをしっかりと完成させる。したがって、画面遷移でエラーが起きる、予期せぬエラーが起きるなどがないようにバグ出しを行い、アプリとしての完成度を高めることが重要

シナリオテスト(LT)

業務シナリオに沿ったテストを実施する。ブラックボックステストに当たる。

要件定義で作成した業務フロー通りに業務が流れるかどうかを確認する。システム目線ではなく、業務目線でテストをすることがポイント。

この工程では、業務要件定義の内容がしっかりと反映されているかをしっかりと確認していく。

もっとこうしたらよいのでは・・・？という点があり、顧客に逆提案を行い改善を図っていくことはべき論でいえばなし。その場合は、本来は「検証」フェーズであるため仕様変更などは別工数をもらって別途対応していくことが筋。所謂、変更管理扱いになる。ただ、ここはシステム屋としてもっと良いものをという思いで悩む部分でもあり、せめぎあいのため、顧客との信頼関係に寄ったりもする。

主な作成物：シナリオテスト仕様書及びその結果

単に”動く”アプリケーションから業務で”使える”アプリケーションにブラシュアップしていく。

システムテスト

ハードウェアや通信も含めてシステム全体で問題ないかを確認する。

複数システムがある場合は、システム間の連携設定（バッチやそれに関連するディレクトリ、HUFLT設定など）も組んだうえでシステム間連携テストもこの工程で実施することが多い。

また、非機能要件関連のパフォーマンス、ユーザビリティ、セキュリティ、負荷に関するテストもここで検証する。

特に非機能要件はインフラが関わってくる部分も多く、新システム導入の場合でインフラ環境も設定した場合には、アプリとインフラの統合テストを実施する。例えば、APサーバやDBサーバがデュアル構成の場合は、サーバの片方を停止した状態でも問題なくアプリ側のデータ登録や処理が可能かどうかや、アプリ側で入力したデータのバックアップが正常に取得され、定めた時点に正常に復元できるかどうかを確認する。

既存システムに対するエンハンス開発の場合は、リグレッションテスト（他の機能への影響確認）もこのフェーズで行うこともあるが、シナリオテストの中で実施することも多い。