ソフトウェアレビューにおける仕様レビュー文化の定着と品質の向上

こんにちは。高橋信です。

今回はソフトウェアレビューにおける「仕様レビュー文化の定着と品質の向上」としてQAによる仕様レビュー導入について紹介します。 どのような現場の課題を解決できるのかや、何をベースにするか、ソフトウェアレビューのプロセス、導入後フォローなども解説しましたので、QAによる仕様レビューでお困りの方が解決の一助になればと思います。

自己紹介（ソフトウェアレビューとのかかわり）

初めに自己紹介から。 2014~2016の2年間SQiP研究会ソフトウェアレビュー分科会で、仕様レビューに関する現場の課題を研究し論文を発表しました。 論文はこちら

• 2014年：重大欠陥を早期是正するレビュー手法　3分割レビューの提案（以下3分割）
• 2015年：欠陥パターンと検出テクニックを用いたレビュー手法の提案と そのトレーニング教材の有効性評価の報告（以下トレーニング）

3分割では、「各設計工程での手戻り削減」と「開発計画遵守」を目的として、各設計工程の期間を大枠・詳細・総合の3つのフェーズに分割し、各フェーズ終了時点の3回で、予め用意したレビュー観点表を用いて仕様レビューを行うという手法を提案しました。
トレーニングでは、初級・中級レビューアも活用できるように、欠陥パターンに一般的に知られている欠陥検出テクニックを紐づけた手法を提案しました。さらに実践で活用できるようにするために、反復練習型トレーニング教材「チョコ・トレ」も作成しました。（ただ一部未完成）
どちらも「手戻り削減」「レビューアの育成」と現場のよくある課題に対して、解決に役立つ手法の一つです。興味がある方は一読下さい。

ソフトウェアレビューでよくある現場の状況

• レビュープロセスは未定義
• レビュー対象のテストベースは人により様々
  • ストーリーボード、仕様資料、画面設計等
• レビュータイミングはテスト設計時
  • レビュー指摘ではなく質問形式
• 指摘内容は個人のスキルに依存
  • ドメイン知識の有無、該当機能のテスト経験有無　等
• 上流工程でレビュー経験の少ないメンバがいる

仕様レビューが属人化しており、出来るメンバは豊富な知見で効果的な仕様レビューが出来ている半面、大多数のメンバは「レビュー観点が確立していない」「上流で仕様レビューした経験が少ない」そんな現場、皆さんも経験あるのではないでしょうか。
QAメンバも安定して価値のある仕様レビューを提供するためには、 体系立てたレビュープロセスと観点を導入していくと効果的です。

なぜQAメンバで仕様レビューが必要なのか

仕様レビューの目的

修正コストの削減

「コストモデル」を使った 開発品質・生産性向上の取組み 1 ～バグ対応コストの見える化と最適化～より

仕様レビューを実施する一番の目的ですね。不具合は早期に検出するほど修正コストが低くなります。 設計工程で検出出来なかった不具合をテスト工程で検出すると修正コストは 4 倍（５→２０）となります。

• 想定される修正作業
  • 不具合条件の切り分け、不具合票起票
  • 不具合個所の調査
  • 修正方法の検討、再設計
  • 影響範囲の確認
  • 修正とデプロイ
  • 修正確認、影響確認　等々

テスタビリティの確保

テスタビリティ(Testability、テスト容易性)は「どれだけ容易にテストできるか」 「どれだけテストを実現できるか」の度合いを示す品質特性です。

具体的にはテストをするために必要な情報がレビュー対象に記載されていることが必要です。

• 期待値が記載されていない
• 仕様に抜けや矛盾がある、
  • ～場合のについての記載がない、資料間で整合性がとれていない
• 機能追加時に修正影響範囲が想定できない
• テスト環境の制約で実施したいテストが出来ない　等々

上記情報が記載されていない場合、テストの網羅性、実現性に問題が発生する可能性が高くなります。 また機能追加時の修正対象がテストしやすいか、テストが効率的に実施できるかも重要です。

• リファクタリングが発生する場合、どの程度の機能に影響が想定されるか
• 共通部品を利用する場合、該当箇所以外のテストは削減可能か
• 新規画面作成時は自動化テストケースが作りやすい画面設計となっているか　等々

QAメンバの視点

プロダクトマネージャー、開発、QAなど役割の異なる立場（視点）での仕様レビューは大事

プロジェクト参加者は立場により優先度の高い（または得意とする）レビュー視点が異なります

• プロダクトマネージャー：プロダクトの価値や利用者などに基づく視点
• 開発：設計の矛盾や実装効率、保守容易性などの視点
• QA：テストの網羅性、実現性、容易性（テストしやすい）、効率性等の視点
  • 設計段階で上記視点で仕様レビューをしておくことで、修正コストの削減、仕様の早期把握や、テスト設計の手戻り防止が期待できます

ソフトウェアレビュー入門（3） “読み方”を知って、レビューをもっと効果的により図を引用

上記の様にQAならでは、QAだからこその視点を活用することで、設計工程でより多くの不具合を検出することが可能となります。 QAメンバも率先して仕様レビューに参画し、修正コストの削減とテスタビリティを確保していきましょう。

ソフトウェアレビューを効率よく進めるために

レビューオリエンテーションキットの導入

困ったときは先人の知恵を拝借しましょう。

SQiP研究会では過去に様々な仕様レビューの現場課題が研究がされています。 その中からこちら、
レビューオリエンテーションキットを用いた、育成によるレビュー文化の形成から知恵を拝借しました。

初心者が持つレビューへの抵抗感を減らし、 実践的かつ効果的なレビューの技術を学べる 「レビューオリエンテーションキット」を開発した。

こちらは概要にレビューの技術を学べるとある通り、仕様レビューに必要なものが一通り揃っています。

• 第2章レビューの基礎
• 第4章プロジェクトへ導入する際のヒント
• 第5章レビュー文化の熟成

この中から現場の体制、文化を考慮して必要なもの（プロセス）を現場に導入します。

QAによる仕様レビュープロセス

• QAによる仕様レビュー目的の共有
  • 目的もなく納得感もない作業は長続きしませんし、定着もしません。そのためメンバになぜQAによる仕様レビューが必要なのか、仕様レビューで提供できる価値は何かを明確にして共有します
• レビュー対象
  • レビュー対象はプロジェクトの上流工程で作成されるドキュメント全般とします
    • ユーザーストーリー
    • 設計書、仕様書
    • アジャイル開発なのでPOや開発者と仕様決めで話した会話も対象です
• レビュー観点表
  • 安定した仕様レビューを実施するために、観点（整合性、状態、機能影響など）と項目（ドキュメント間の整合性、ユーザの登録状況など）を整理し、現場での具体例を記載します
  • 工夫可能な点は以下です
    • 項目毎に汎用的、ドメイン依存を記載する
    • ドメイン依存は現場の有識者でリストを作成する
    • 運用していく中で適宜追加変更削除していく
• レビュータイミング
  • いつやるかは重要です
    • 案件の大小や難度により作成するレビュー対象が異なるため上流工程全般（要件分析、設計）とします
  • QA工程はテスト分析フェーズで再度実施します
• レビュー指摘の取扱い方法
  • レビュー記録票を導入。スプレッドシートで一覧を作成し指摘内容、回答、修正日などの項目を作成
  • ここは現場次第。管理するドキュメントが増えない様に既存の資料を活用してもよいですね

導入のポイント

• レビュー対象すべてを仕様レビューしない！時間は有限なので、より効果のあるレビュー対象に注力する
  • どのレビュー対象に効果があるかは、仕様レビューを積み重ねていかないと分からないですけどね
• ステークホルダに事前説明をしておく
  • 元々現場でシフトレフトの意識があれば、導入に対してメンバからの反対は少ないと思います。シフトレフトの意識がなければまずは意識を変化するところから始めましょう
  • プロセス導入だけでなくQA側での作業を理解してもらうために開発チームへ説明も必要です。 特に作業が発生するレビュー指摘票のフローは認識齟齬が発生しないように口頭で説明し納得して頂く事が重要です

QAによる仕様レビュー導入後・・・

導入して終わりにはなりません。導入したプロセスは定着したか、困っている人はいないか、実務の中で寄り添いながら観測が必要です。観測項目の一例を紹介します。

• 仕様レビュー対象に抜けはないか
  • すべてをレビュー対象にする必要はないがレビューすべき対象が抜けていないか
• 仕様レビューの実施時期は妥当か
• 確実に仕様レビューが実施されているか
  • プロセスに組み込んでも抜けるときは抜けます
  • 導入初期は1案件づつ確認が必要です
• 狙った指摘が検出出来ているか（QAならではの視点も含む）
  • 仕様が不明確である
  • レビュー観点表に沿ったドメイン指摘　等
• 仕様レビュー経験が少ないメンバも仕様レビューのやり方やレビュー観点表の使い方に困っていないか
• レビュー観点表の更新（観点の追加、変更、削除）はされているか

また以下の項目から導入後の効果測定が可能です。

• 目的のQAメンバも安定して価値のある仕様レビューを提供はできたのか
  • QAによる仕様レビューの効果はどの程度あったのか（指摘の重大度、修正工数等）
• プロセス定着はできたのか
• 開発側との関係性は
• QAメンバの意識はかわったか

導入後フォロー（仕様レビュー練習教材の作成）

レビュープロセスを導入しても都合のよい案件が無いと中々実施経験が積めない問題があります。

その対策として経験が少ないメンバ向けに過去の仕様レビューで検出した不具合や、仕様レビューで検出しておくべきだった市場障害をレビュー対象（設計書）に人為的に埋め込んだ練習教材の作成をお勧めします。

• 練習教材のお勧めポイント
  • 検出済みの不具合、設計書と既にあるものを利用して作成するので作成工数が少なくて（１時間程度）済む
  • 知っておいて欲しいドメイン知識に依存する不具合を意図的に埋め込むことで、ドメイン知識の学習も並行して実施可能
  • レビュー観点表を作成している場合、埋め込む不具合とレビュー観点を紐付けしておくとレビュー観点の理解にも繋がる

最後に

最後にレビューオリエンテーションキットから私の好きなノウハウと標語を紹介します。

• ノウハウ

長い文章は要注意： 仕様書の文章中に読点（「、」）が 何度も出てきている長い文章を記述してい場合は、 欠陥が含まれていることが少なくない。

これあるあるだと思います。日本語の構造的に読点が多数出てくると主語が曖昧になったり、修飾語がどこにかかるのかがわかりづらくなります。 また自信がない部分の説明は文章が長くなりがちですね。

• 標語

他人の欠陥は見つけられても、自分の欠陥は見つけられない

不思議ですね。なぜか自分で作成した成果物の欠陥は見落してしまいがちです。認知バイアスと呼ばれこれまでの経験や先入観、思い込みから思考が無意識に誘導されてる現象です。 対策として作成した成果物を翌日に見る等、自己レビュー力を鍛えたいですね。 他にも多数のノウハウ、心構え、標語が記載されていますので是非参考にして下さい。

再掲：

レビューオリエンテーションキットを用いた、育成によるレビュー文化の形成