プロジェクトマネージャーならテスト仕様書のフォーマットこそ自分で作成しなければならない

システム開発に参加している人は、どんな立場の人であれ、「後工程のことを考えながら」その時々の成果物を設計すべきです。

成果物というのは、最終成果物(動くシステム)だけではなく、フェーズ途中で作成されるドキュメントもそうです。

そしてこのドキュメントは、会議体との関連性のうえで、「後工程に役立つか」ということを考え続ける必要があります。

ある会議が終わってから、ドキュメントに転記が必要となるドキュメントは有効ではありませんし、

フェーズが変わったり閲覧者が変わるたびに、体裁を変えなければいけないドキュメントも「有効なドキュメント」とは言えません。

そして、ディレクターや、プロジェクトマネージャーと呼ばれる「経験ある人」は、この「有効なドキュメント」を設計すること自体も、とても気を遣う重要な仕事と認識すべきです。

間違っても、社内標準のフォーマットをそのまま採用すべきではありません。

そんなドキュメントのなかで、特に誰もがやりたがらないものに「テスト仕様書」と「リリース仕様書」があります。

テスト仕様書はとても重要

このうちの「テスト仕様書」(UT除く)について言うならば、

このドキュメントは、特に神経をつかうというか、気を配った方がいいもので、

・どういうフォーマットであれば、直感的に見やすいか
・どういう情報を盛り込めば、迷うことなくテスト実施できるか
・どういうフォーマットであれば、エンジニアが見やすいか
・どういうフォーマットであれば、自分が見やすいか、、、

このような観点をクリアしていないと、テスト&その後の修正、さらにその後の集計作業は、本当に辛いものになることでしょう。

そして辛い作業なので、この仕様書作成や実施で手を抜いたりすると、それが後日のバグとして自分に返ってくるし、

手を抜いた仕様書なので、テスト消化状況などが正確に記録に残らない状態で目をつぶってしまうと、

本質的な振り返り評価ができず、結局、その組織のレベルはいつまで経っても上がらないままなのです。

おすすめの記事