はじめに
開発現場で製品のテストをする際には、テスト仕様書や設計書の入力となる「仕様」が記載された仕様書や設計書を参照すると思いますが、皆さんは最新(または製品同等の)「仕様」がどこにあるか意識していますか？通常は社内のサーバーやファイル管理ソフトに保管されていると思いますが、何がどこまで書かれていて、それが実際の製品と見比べてみて妥当なのか？という視点で観た時に、果たして自信を持って「ここにあります！」と言えるでしょうか？
では、仕様書・設計書の記載内容が十分でない場合、どこにその情報があるのか？
ということですが、筆者はいくつかの情報源にあたって必要な情報を収集しています。
情報源の見つけ方
著者は普段、以下のようなことを気にして情報源の在りかを探しています。- 周りの有識者
長年同じ製品に携わっている周りの方から情報が聞けると、かなり楽に仕様を収集することできます。同じ職場でなくても、以前対応されていた方であれば、かなりの情報量をお持ちなのかと思います。 - 開発担当者
仕様書を書いて実装している開発者であれば、それなりに情報を持っている場合がありますが、対象製品の開発において経験の浅い人だと、他機能との関連性や仕様の在りかについては、抜け漏れが発生する可能性があります。とはいえ、自分では分からないと思う事がある場合には、事実確認含めてしつこく聞き続け、聞いた内容から仕様を整理して、仕様を煮詰めていくことも必要になります。 - 仕様書、設計書
仕様書・設計書に全ての仕様が書かれていることが理想ですが、実際にそこまで仕様を適切に記載することは、経験者(の方があまり書かないことも)であっても難しいのかと思います。仕様書には書いていないが、設計者の頭の中にはあるということはありますが、その仕様を外部から理解することはできません。また、メールやチャット、手元のメモ等で仕様のやり取りをすると、その内容自体が埋もれたりして仕様書に記載すらされないということもあります。
仕様書に書かれないことであっても、日頃からチケットや掲示板など人目に付くところに記載していくようにすれば、まだ仕様を拾得する助けにはなります。 - テスト仕様書、テスト設計書
テスト設計・実施中に確認したことなど、仕様書や設計書に書かれていないことをテストケースや備考欄に記載していることがあります。
テスト仕様書・設計書から開発側の仕様書・設計書に反映されるのかは、開発現場の状況(開発が忙しくてプロジェクト終了後に反映する等)によるところが大きいのですが、こちらの資料も参照すると、仕様の抜け漏れが軽減できる可能性があります。 - プロジェクト管理ツール(Redmine等)
上記と類似しますが、ツールを利用して開発を進めている場合には、チケットのようなものに仕様を記載している場合もあります。例えば、開発工程では仕様書・設計書に記載しますが、テスト工程で確認した仕様などは、テスト結果書に記載すると情報が埋もれてしまうことがあるため、あえてこちらに記載していることもあります。 - 製品(機能)
開発中の製品であっても、現物(プロトタイプ版)を触って仕様を理解することはとても重要です。仕様書と製品の一致/不一致する事象や操作などは簡単に確認できると思いますが、それ以外にも気になるところがあれば触ってみて、各仕様の理解度を深めていくことが必要です。仕様書に全ての仕様が書かれていることはほぼないので、仕様の抜け漏れや誤りに気付くこともあります。 - 類似する他機能の仕様書
既存機能や他機能と仕様を比較することで、実装の不確かさ(整合性の不一致)からシステム上本来あるべき仕様に気付くこともあります。
まとめ
製品に詳しくない人や経験の浅い人は、「仕様」がどこにあるのか、現状どうなっているのか、どこを探したら良いのか、改めて見直ししてみたり、周りの方々に確認しておくことをお勧めします。また仕様は、製品と共に更新し続ける必要があるため、常に最新の状態になっているか確認しておいてください。 「出来る時に出来ることを出来るだけやっておく(確認する)」という意識はとても大事です。 皆さんの開発現場でも、今一度見直しをされてはいかがでしょうか？
もし品質改善でお困りの方がいましたら、是非お話を聞かせてください。 以上