発注者ビューガイドラインとは何か
発注者ビューガイドラインというものをご存じでしょうか？ ソフトウェアテストに関する仕事をされている方には馴染みが無いかもしれません。
発注者ビューガイドライン（以下、ガイドラインと言います）とは、設計書の書き方のコツやレビューのコツをまとめたもので、「実践的アプローチに基づく要求仕様の発注者ビュー検討会※1」（以下、検討会と言います）が作成しました。
すべてのガイドラインがそろって公開されたのは、2008年3月18日です。ガイドラインは以下のホームページよりダウンロードできます。
このガイドラインは、私たち開発者の視点ではなく発注者の視点でさまざまなコツを集めています。「発注者視点」これが大事です。開発者だけがわかる設計書ではなく、システムをあまりご存じでないお客様にわかっていただけるにはどうすればよいのかという視点でまとめたのがこのガイドラインです。
発注者ビューガイドラインの目的・ねらい
発注者と開発者との間でコミュニケーションが上手くとれないことにより、さまざまなトラブルが発生します。開発者が作った設計書の内容が発注者に伝わらないことで、手戻りや仕様の抜けなどが発生してしまいます。そのような問題を防ぐために、設計書の書き方やレビューのやり方を改善したらよいのではないかと考えたのです。
これらを踏まえ、『発注者および開発者が「目標とする情報システム像」を共有する ※2』ために、設計書の書き方やレビューのやり方に関するガイドラインが作成されました。
発注者ビューガイドラインの対象範囲と構成
ガイドラインが対象にしているドキュメントは、外部設計のアウトプットの一部です。外部設計の成果物にはさまざまなものがありますが、次の3つの領域を対象にしています。
画面
画面および操作に関わる6種類の設計書を対象範囲としています。
- 画面一覧
- 画面レイアウト
- 画面遷移
- 画面遷移・レイアウト共通ルール
- 入出力項目
- アクション明細
システム振舞い
業務アプリケーションが提供する機能に関わる設計書と、利用者と業務アプリケーションの相互作用に関わる設計書、全部で4種類を対象範囲としています。
- システム化業務一覧
- システム化業務フロー
- システム化業務説明書
- システム振舞い共通ルール
データモデル
業務アプリケーションが利用するデータに関わる4種類の設計書を対象範囲にしています。
- ER図
- エンティティ一覧
- エンティティ定義書
- CRUD図
図1 発注者ビューガイドラインの対象
発注者ビューガイドラインを取り上げた理由
ガイドラインがターゲットにしている読者は、発注者と開発者です。対象者の中にテストエンジニアは入っていません。それなのになぜ取り上げたのでしょうか？
ガイドラインの内容は、書き方のコツやレビューのコツです。このコツは参加企業の実際の開発事例から集められました。発注者と開発者の間で、コミュニケーションが上手くいっているプロジェクトの事例を集め、どんな些細なことでも「役に立つ」と思われるものをまとめたのです。
ガイドラインが公開されて1ヵ月たちます。このガイドラインが開発者が読むと「あたりまえのことが書かれている」という感想をもたれる方が多いようです。それも当然です。このガイドラインは、研究室から生まれたアイデアを書いているのではなく、まさに現場で行われているそのものの事例を集めてきたのですから、自分たちが工夫しながらやっていることとそれほど乖離するわけがありません。ですから、このガイドラインは開発者にとっては「あたりまえ」のことが書かれています。
開発者にとって「あたりまえ」のことが、テストエンジニアにとって「あたりまえ」になっているでしょうか？
ガイドラインの目的は、発注者と開発者のギャップを埋めるために作られています。そのため、発注者と開発者という関係しかガイドラインの中にはでてきません。
では、テストエンジニアには関係の無いドキュメントなのでしょうか？ 私はテストエンジニアにも是非とも読んでいただきたいドキュメントだと思っています。
図2 発注者、開発者とテストエンジニアを取り持つ「ガイドライン」
図2をご覧になればわかると思いますが、発注者にとってわかりやすいドキュメントの作り方のコツは、見方を変えるとテストエンジニアにとっても役に立つということです。単なる開発者の視点であるならば、テストエンジニアに役立つことは少なかったかもしれません。しかし、発注者の視点で書かれているため、テストエンジニアが読んでも役に立つドキュメントになっているのです。
筆者がガイドラインを取り上げた理由はそこにあります。テストエンジニアが自分のスキルを上げるために、最近多く出版されているテスト関連の書籍を読み込むことも大切です。しかし、開発者向けに書かれたドキュメントを、テストエンジニアの視点で読み解き、自分のスキル向上に役立たせる、このような見方・考え方を多くのテストエンジニアに持ってもらいたいと思い、その一つの題材として最近公開された発注者ビューガイドラインを取り上げたのです。
テストエンジニアに役立つ発注者ビューガイドライン
テストエンジニアは、設計書や仕様書からテストを設計します。設計書や仕様書を読んでテストケースを作成しますが、その設計書は読みやすいものばかりとは言えません。よく理解できない設計書も中にはあるのです。
設計書が理解できない理由にはさまざまなものがあります。テストエンジニアのスキルが足りないというのもあるかもしれません。業務知識が絶対的に不足しているのかもしれません。しかし、そもそも読みにくいドキュメントになっているという可能性はないのでしょうか。理解を妨げる書き方になっている可能性は十分考えられます。ドキュメントを解釈できないテストエンジニアが悪いのではなく、ドキュメントの書き方が悪いというケースもあるはずです。
テストエンジニアの中には、設計書や仕様書を書いたことが無い人がいます。そのため、読みにくいドキュメントだと思っても、どのように対処すればよいのかわからなかったかもしれません。その人たちにこそ、このガイドラインを読んで欲しいのです。
ただし、このガイドラインは発注者と開発者に向けてかかれているため、テストエンジニアが初めて読むには取っつきにくいところもあります。そこで、次回と次々回の２回に分けて、テストエンジニアがどうやってガイドラインを読んでいけばよいのかを説明していきたいと思います。
- 【参考文献】
- URL：発注者ビューガイドライン（概説編）ver.1.0
