要件定義、基本設計、ときたらその後は詳細設計やコーディングに流れていくのですが、この「詳細設計」「コーディング」「単体試験」の作業量を見積もる際に見込んでおくべきものについて説明します。
目次
詳細設計
１．仕様理解
上流工程と製造工程を行う担当者が異なる場合、仕様に関する引き継ぎ作業を行う必要があります。仕様を引き継ぎ、製造工程担当者が仕様を理解し、後工程の成果物を作成できる状態にするプロセスが必要です。（同一人物が継続して行う部分については省略可能です。）
２．オリエンテーション
製造工程から参画したメンバーの為に、開発標準の説明や日報の提出方法、質問時の窓口等、今後の業務遂行に必要な情報を展開する場を設ける必要があります。
参画人数が少ない場合は、仕様理解のプロセスで同時にやってしまう方法もあります。
３．詳細設計書作成
担当者が実際に設計書を作成します。仕様に関する疑問点や、設計書の記載方等について、仕様理解とオリエンテーションにて説明ができていると、本工程がよりスムーズに進みます。
４．詳細設計書レビュー
出来上がった設計書をレビューします、レビュー時のガイドラインについては別記事にて説明します。
５．レビュー後修正
レビューした設計書が一発OKとなることは基本的にありません。レビュー後の結果を踏まえて設計書の修正を行います。
６．詳細設計書再レビュー
レビュー後修正を終えた詳細設計書を再レビューします。原則ここでOKになるはずですが、再修正を依頼するケースもあります。とはいうものの、再々レビューとか再々々レビューとかやってるとキリがないので、レビュー2回程度にしています。
７．単体テスト仕様書作成
単体テスト仕様書をコーディング後に作成する場合もありますが、詳細設計書レビュー後に作成することをお勧めします。なぜなら、単体テスト仕様書は詳細設計書に記載されている内容が網羅されていることを確認するためのテストであり、詳細設計書があれば作成することは可能だからです。
単体テスト仕様書も詳細設計書と同様にレビューは2回実施（レビュー、レビュー後修正、再レビュー）する想定です。
開発
８．コーディング
詳細設計書に基づきコードを書いていきます。単体テスト時にプログラムが全く動かないような不具合は本工程にて対応されている前提です。
９．単体テスト
単体テスト仕様書に基づき単体テストを実施します。テスト結果についてレビューを受けるために、エビデンス（入力内容、スクリーンショット、ログ等）を取得し保管します。単体テスト結果がNGである場合、プログラムを修正し再実施します。（NGの内容が上流工程にかかわるものである場合は早めに確認することが必要です。）
１０．単体テスト結果レビュー
単体テストの結果をレビューします。ここではエビデンスがテスト仕様書の通りになっている（なっていない）ことを確認するのみですので、1回でもいいと思います。
以上が詳細設計、開発工程にて必要にて実施するタスクです。プロジェクト規模や人数によっていくつか省略は可能です。
今日のまとめ
- 開発スケジュール作成の際に考慮するポイントだよ！
- 開発規模によっては省略してもいいかもね！
- バグの作りこみを防止するのが目的だよ！
