Go to Qiita Advent Calendar 2024 Top
LoginSignup
18
21

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

ベリサーブAdvent Calendar 2019

Day 12
@ktanizakiin株式会社ベリサーブ

知らないようでやっぱり知らない仕様書のレビュー技法

Last updated at Posted at 2019-12-11

はじめに

皆さん、仕様書のレビューは実施していますか？テストで不具合を見つけて修正することも大事ですが、そもそも仕様書の段階で問題があるのであれば、レビューでその問題を検出して修正しておきたいですよね。
一口に「レビュー」といっても、様々なやり方が知られています。時と場合によって効果的なレビューの方法は変わるとは思いますが、まずは色々なレビューの方法を知っていることで、どんなやり方でレビューしたら良いか考えるきっかけになるはずです。ということで、この記事では、色々なレビュー技法（Reviewing techniques）について解説したいと思います。

この記事で扱う「レビュー」の範囲

仕様書（要求仕様書、要件定義書、機能仕様書など）のレビューを想定して記載します。コードレビューについては対象としていませんのでご注意ください。ただし、記載しているレビュー技法が、それ以外の文書やコードレビューでまったく使えない、ということではありませんので、適宜活用できると思います。
また、ウォークスルー・インスペクション・ピアレビューといったレビューの形式（ISO/IEC20246:2017の表現ではReview types）は本記事では記載していませんので、ご注意ください。

ISO/IEC20246:2017 Software and systems engineering ‐ Work product reviews　に記載されているレビュー技法

Ad hoc reviewing

決まった手順はなく、その場の思いつきで問題点を指摘する方法です。
「思いつき」と書くと適切でないようにも見えますが、実際は指摘する人はいろいろ考えた上で指摘している（はず）なので、鋭い指摘もたくさん出ます。とある調査では、個人レビューで問題点を指摘している組織の35%はAd hoc reviewingを使っているとのことです。皆さんの職場でもよく実施されているのではないでしょうか。
レビュー会のような場で実施すれば重複する指摘が出ることを防げますが、複数名が個別に実施すると重複する指摘が多く出てくる懸念はあります。
また、どこまで実施したら終了か、という判断が難しいです。「もう思いつかない」となるまで実施することが多いと思いますが、実際は、時間を置いてもう一度同じ仕様書を読んだら、新たな指摘を思いついたりすることもあります。（自分はけっこうそういうことありますが、皆さんはどうでしょう？）

Checklist-based reviewing

チェクリストを元に仕様の問題点を見つける方法です。
チェックリストは過去の経験などに基づいて作成されます。とある調査では、個人レビューで問題点を指摘している組織の50%はChecklist-based reviewingを使っているとのこと。上記のAd hoc reviewingとChecklist-based reviewingのどちらかを使っている組織が多いということになります。
チェックリストの範囲で指摘を探すため、その範囲で効率よく指摘を探すことができます。その一方、チェックリストの範囲を超える指摘を見つけるのが難しくなるという懸念があります。その他の利点として、チェックリストの項目ごとにレビューアを割り当てることで、指摘が重複するのを防ぐ効果があります。
効果的なレビューを行うためには、どんなチェックリストを用意するかが重要になります。指摘があまり見つからない場合、チェックリストを更新することを検討すべきですが、チェックリストが長らく更新されずに使い続けられるケースもあります。その場合、形式的にチェックリストを順に確認するだけでなく、不具合事例をもとにチェックリストの見直しを考えてみてはいかがでしょうか。

Scenario-based reviewing

何らかのシナリオに基づいて仕様書を読んで、問題点を指摘する方法です。
例えば、ユースケースが書かれていれば、ユースケースに沿って仕様を確認したり、見つけたい不具合のタイプを定めて、そのタイプの不具合を見つけるためのシナリオを作ってレビューする、といった形です。後者はDefect-based readingとも呼ばれます。「特定のタイプの不具合を見つけるためのシナリオ」はチェックリストのようでもありますが、チェックリストが抽象的・一般的な記載であるのに対し、Defect-based readingは特定の不具合に特化した具体的な記載になるため、その不具合を見つけやすくなります。
一方で、シナリオに含まれない不具合を見逃す可能性が高くなるという懸念があります。シナリオの作り方が重要で、ビジネス上のリスクや重要なユースケースに基づいてシナリオを作る必要があります。シナリオの詳しい作り方は『間違いだらけの設計レビュー』に詳しく解説されていますので、参考になります。

Perspective-based reading (PBR)

様々なステークホルダーの視点からレビューする方法です。
一般的には、開発者、テスター、ユーザの視点が使われますが、それ以外にもビジネスアナリスト、ビジネスオーナー、保守担当者、マーケティング担当者、オペレータ、プログラマなど、様々な視点を使うことができます。
例えば、テスターの視点だと、「この仕様書に基づいてテストできるか？期待する動作があいまいな部分や、不明な部分はないか？」といった問いから、仕様の問題点を指摘します。このような問いかけを、各視点ごとにチェックリストとして用意してレビューに使います。
テスターの視点でレビューする際の手順として、同値分割の考え方でレビューする手順が『How Perspective-Based Reading Can Improve Requirements Inspections』に解説されています。同値分割については、1日目のアドベントカレンダーで解説されていますので、そちらも参考にしてもらえればと思います。うるう年の判定プログラムであれば、「全角数字・半角数字のどちらでも同様に判定されるのか？」とか「アルファベットや記号を入力したときどうなるのか？」といった指摘が考えられますね。
具体的なチェックリストの例は上記の英語の資料のほか、『要求仕様書の特性に着目した個人レビュー手法の実験的評価』に記載されていますので、こちらも参考になります。
レビューアごとにどの視点でレビューするかを分担することで、指摘の重複を防ぐ効果が見込めるのは、Checklist-based reviewingやScenario-based reviewingと同じです。また、チェックリストを随時更新していく必要があるという点も同様です。

Role-based reviewing

様々なステークホルダーの視点からレビューする方法です。
・・・あれ？これだけだとPerspective-based readingと同じ説明ですね。
実際、似ている手法のようですが、日常の自分の立場とは異なる立場でレビューする、という点が強調されます。たとえば、開発者がテスターの立場からレビューしたり、ビジネスオーナーが開発者の立場からレビューしたり。普段と異なる役割を意識するということで、ロールプレイング的な意味合いが強いので、Role-based reviewingと呼ばれるのだと思われます。

SQuBOK Review2017に記載されているレビュー技法

Checklist based reading、Perspective Based Review、Defect Based Reading

これらは上で解説したので割愛します。SQuBOK Review2017では、これらは大きなくくりでシナリオ・ベースド・リーディングとしてまとめられています。指摘を見つけるためのシナリオや問いかけが集まったチェックリストをベースにしてレビューする、という点で共通しています。

Usage Based Reading

ユースケースに沿って仕様書を読んで、問題点を指摘する方法です。
SQuBOK Review2017によると、UBRはノベル・リーディング技法と呼ばれることがあり、シナリオ・ベースド・リーディングとは異なる技法とのことです。ユースケースに優先順位を付けて、優先順位の高いものから、順にユースケースを追うことで、仕様書に問題がないかを確認する方法です。

国際会議などで提案されているレビュー技法

Trap Based Review（ISSRE 2018 Workshops）

不具合の作りこみに繋がる罠（Trap）をベースに仕様書の問題点を指摘する方法です。以下の論文に詳細が記載されています。（有料です）

Method of Requirements Review considering Adverse Conditions（SCIS&ISIS2018）

要求仕様の内容をレビューアが整理し、想定外の悪条件（Adverse Conditions）を考慮して、仕様の問題点を指摘する方法です。以下の論文に詳細が記載されています。（これも有料です）

SQiP Libraryで発表されているレビュー技法

仮説駆動型レビューや作成者の認知バイアスに着目したレビュー手法、コンセプトベースドレビューなど、様々なレビューの方法が提案されています。SQiP LibraryのWebサイトから資料をダウンロードできますので、詳細はそちらを確認してください。レビューの技法を検索すると48件あります（こちらは無料です！）

さいごに

いくつくらい知っているものがありましたか？ここに挙げたものがすべてではありませんが、ある程度、有名なものは挙がっているかなと思います。もっとこういう方法もあるよ、ということがあればぜひ教えてください。
レビュー技法の効果は実際に使ってみないと見えにくいと思いますので、色々な方法を試して、ご自分のチームに合ったやり方を見つけられると良いと思います。

おまけ

特定のレビュー技法ではありませんが、個人的に仕様書をレビューする際に考えていることを3つお伝えして、この記事を締めくくろうと思います。（ホントはこれを書きたかっただけかもしれません）

  1. 仕様を理解する
  • 現状の仕様だと何が起きるかを整理し、色々なパターンや組み合わせを一生懸命考える。
    • こうなって、こうなって、こうなったとき、この仕様だとこういうことになるけど、それって問題ない？
  1. 仕様を整理して思考を広げる
  • まだ考えられていないこと、議論されていないことが何かあるか考える
    • なんとなくでも良いから、全体像を描く努力をすると、全体の中で抜けていることに気付いたりする
      • 実際、ホワイトボードなどに絵を描きながら整理していると思いつくこともある（こことここの繋がりはどうなっているんだっけ？とか）
    • 整理していると、「あれ、そもそもこれってなんでこの仕様にする必要があったんだっけ？」と思ったりもする
  1. 「そもそも」に立ち返る
  • 「そもそもこういう仕様にした理由や意図は何か？」「そもそもの目的は何か？」「そもそもこの機能って必要なのか？」など、自分自身に問いかける
    • USDMの「理由」とか、HAYST法の「目的機能」を考えることに近いかもしれません。
      • 最近あったこととして、表形式のUIを使っている画面のデザインについて議論があった際に、「そもそもなんで表形式なの？」という問いかけから、表を使わないほうが良さそうというアイデアに繋がったり。
      • 半月ごとにデータをアップロードする仕様があった際に「そもそもなんで半月ごとなの？」という問いかけから、半月にこだわる必要がないことに気付いたり。

レビューの際にどんな考え方で指摘を見つけているかについては、「違和感のつかまえかた」という発表がとても参考になりましたので、下の参考URLに乗せておきます。

参考URL

参考URLをまとめておきます。無料で見られる日本語の資料もありますので、見てもらえればと思います。

18
21
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
18
21

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?