品質基準はどう定めるべき？解釈の不一致を防ぐために、上流工程でできること

仕様に対する認識の違いがテスト後に発覚し、修正対応に追われる現場は少なくありません。

こうした問題を防ぐために重要なのが、「開発の初期段階で品質基準を明確に定めること」です。要件定義〜詳細設計の段階で、メンバー間の認識の相違が生まれないようにドキュメントを整備すれば、手戻りのコストを回避しながら開発を効率的に進めることができ、最終的な品質の安定にもつなげられます。

本記事では、曖昧な品質基準がもたらす問題や人によって解釈が分かれやすいポイント、品質基準を明確に書き表すための方法などを解説します。

第三者検証の重要性｜資料ダウンロード

曖昧な品質基準がもたらす問題

品質基準の曖昧さが上流工程で見過ごされると、テスト工程やリリース後に深刻な問題として表面化します。

まずは、品質基準の曖昧さによって生じる問題を整理します。

解釈の不一致で現場が混乱する

仕様書の記述が曖昧だと、メンバー間での認識が食い違い、実装以降の工程で混乱が生じます。

例えば、プログラマーごとに異なる解釈で実装を進めた結果「本来同じ位置にあるべきボタンが、画面Aでは左上、画面Bでは右下に表示される」といった事態がテストで発覚し、仕様の再検討やコードの修正に追われる現場は少なくありません。

プロジェクトコストが増大する

上記のような修正対応にかかるコストは、問題の表面化が遅くなればなるほど膨らんでいきます。

ある調査では、要件定義の段階でのバグ対応コストを1としたとき、テスト工程で発覚した場合のコストはその20倍、納入時点での発覚の場合は200倍にまでのぼるというデータもあり、上流工程での問題の見落としによる影響の大きさを物語っています。

品質が低下し、ユーザーの不満につながる

基準が曖昧なまま放置されリリースされることで、ユーザビリティを大きく損なってしまう事例は後を絶ちません。

一つひとつの機能やモジュールの挙動が重要なのはもちろん、同じくらい注意すべきが、プロダクト全体としての整合性です。

例えば会計ソフトなどのように繰り返し作業の多いソフトウェアの場合、ボタンの位置が画面間で統一されていないだけでも使用感や業務効率が大きく低下し、ユーザーの不満や離脱をもたらします。

仕様が曖昧になりやすい項目の例

上記のようなトラブルを防ぐためには、上流工程からドキュメント上で品質基準を明確に定めておくことが重要です。

ここでは、仕様が曖昧になりやすい項目の典型例を解説していきます。

丸め処理ルール

丸め処理が問題になる要素として、身近なプロダクトでは次のような例があります。

• ECサイトのポイント
  （100円につき1ポイント付与するルールで、購入金額が1,980円になった場合、19.8ポイントを付与するのか、100円以下を切り捨てて19ポイントを付与するのか）

• 勤怠管理アプリの打刻時刻
  （15分単位で集計するルールで、18:23に退勤打刻が押された場合、18:15からはみ出た8分間をどう処理するか）

金額や時間（秒・分）などの誤差は、1回あたりは微小でも、何千・何万件と処理が重なることで大きな差異になる場合があるため注意が必要です。また、分野によっては法律上の規制がある場合もある（税法関係など）ので、発注者ともすり合わせながら適切な基準を設定することが欠かせません。

UIデザイン

色合いやボタンの形・サイズ、レイアウトなどのUI面は、特に解釈が曖昧になりがちな項目です。

実際の開発で問題になることの多い項目として、次のような例があります。

• 段階的に画面遷移するフォーム入力機能で、画面Aでは左から「OK」「キャンセル」、画面Bでは「キャンセル」「OK」の順で書かれている
  
• 同じ「保存」ボタンが、プロフィール編集画面では緑色のボタン、設定画面では青色のテキストリンクなど、デザインが統一されていない
  
• ボタンがクリック可能かどうかの視覚的な手がかり（影、ホバー効果など）が統一されていない

同じ機能であるにもかかわらず表現が異なると、ユーザーが操作に戸惑います。小さなストレスがプロダクトに対する満足度を無意識に下げるので、表現の統一には注意が必要です。

エラー判定ルール

不正な入力時や例外的な環境下での挙動も、仕様が曖昧になることが多い領域です。

設計段階で見落とされやすい項目として、次のような例があります。

• バリデーションエラーで再入力を求める場合、正しく入力された内容を残すのか削除するのか
  
• エラーの原因をユーザーにどこまで説明するのか
  
• 複数のデータの処理中にタイムアウトが発生した場合、処理済みのデータはそのまま確定（コミット）するのか、すべて取り消して実行前の状態に戻す（ロールバック）のか

通信トラブルやセッション切れ、大量データの処理など、さまざまな状況を想定して仕様を明確化しておくことが重要です。

上流工程で品質基準を明確化するための作業手順

品質基準についての認識を統一するためには、「どこで解釈が分かれやすいか」を整理したうえで、ドキュメント（仕様書や設計書）の作成・慎重なレビューを行う必要があります。

ここでは、上流工程で品質基準を明確化するための作業手順を解説します。

1. 品質基準が曖昧になりやすい箇所を特定する

ドキュメント作成の準備段階として、まずは品質基準が曖昧になりやすい項目を整理します。

具体的には、上述の典型例のほか、過去のプロジェクトで発生した不具合などを振り返り、後工程で問題になりやすい箇所を抜け漏れなく洗い出していきます。

2. 条件や期待結果を、解釈の余地のない表現で書く

曖昧になりやすい箇所を特定できたら、仕様書・設計書に品質基準を落とし込んでいきます。

このとき、「適切に処理される」「正しい値が返ってくる」といった抽象的な表現を避け、解釈が一意に定まる言葉で書くことが重要です。

数値の範囲など、数式で表現できる部分は極力数式で表すことで、誤解なく実装・テストを進めやすくなります。

3. レビューで合意形成・改善につなげる

品質基準を定義した後は、開発チームやQAエンジニア、（受託開発の場合）クライアントなど各ステークホルダーによるレビューを実施します。

「曖昧な表現は残っていないか」「実現可能な仕様か」「元の要件とのずれはないか」などの観点から確認し、不安要素は実装開始前に解消しておきます。すぐに確定できない事項については、いつまでに誰がどうするかを決めてプロジェクト内で共有し、定期的に進捗確認や相談の時間を取ります。

4. 情報共有のルールを整える

品質基準を定めた後は、全員が最新の品質基準を確認しやすいように、情報共有のルールを整えることも重要です。

次のような点に留意することで、ドキュメントの形骸化を防ぎ、プロジェクト期間全体にわたって共通認識を維持しやすくなります。

• 品質基準を定めたドキュメントは、全員がアクセスしやすい場所に置く
• どれが最新版なのか、一目でわかるようにする
• 内容を更新するたびに関係者全員に周知する

読みやすいドキュメントを作成するためのポイント

品質基準を明確化しても、ドキュメントが読まれない、または正確に読解されなければ、チーム内で解釈違いが生じてしまいます。

最後に、可読性の高いドキュメントを作成するためのポイントを解説します。

シンプルな文章で書く

書き手・読み手の間での解釈違いを回避するために、なるべくシンプルな文章を書くことが重要です。

例として、次のような点をチーム内でルール化するとよいでしょう。

• 受動態を避ける（主語の抜けを防ぐ）
• 1文を40文字以内に収める（長い文は意味のねじれにつながる）
• 表現は統一する（同じ機能や要件などは同じ用語で書く）

メンバー間の専門分野や業務知識、社歴の違いなども考慮し、なるべく一般的な表現で書くことも重要です。また、プロジェクト内の用語集を作成して、アクセスしやすい場所に格納するのもよいでしょう。

図や表を活用する

図や表などによる視覚化も、ドキュメントの可読性を高める有効な手段の一つです。

図表を挿入する場合は、読み手によって解釈が異ならないように、次のような要素について凡例や注釈で意味を明示します。

• 図の線の種類（実線・点線）の意味
• 色の意味（システムフロー図での色分けなど）
• アイコンや図形の意味
• 略語や記号の定義

フォーマットを整備する

社内共通のフォーマットを作成・活用することで、品質基準の考慮漏れを防ぎやすくなります。

フォーマットを使う際の注意点は、項目を略さずすべて埋めることです。記入不要な項目にも、「N/A」「該当なし」「－」などを記入し、記入漏れではないことを明示するようにしましょう。

フォーマットは一度作成して終わりにせず、チーム内のナレッジの蓄積に応じて随時更新することが重要です。新たに不具合が発生した場合はフォーマットに項目を追加したり、逆に使わない項目は削除したりして、自社に最適なフォーマットを整備していきます。

品質基準の明確化で、開発効率と完成度を両立させる

品質基準を明確に定めることで、仕様やテスト結果に対する認識のズレを防ぎ、開発効率の向上と品質の安定化を両立できます。曖昧さを排除した仕様書の作成には一定の経験・スキルが必要で、慣れるまでは時間もかかりますが、早期からの認識統一がプロジェクト成功の土台となります。

品質基準の定め方やドキュメントの作成・運用方法に不安がある場合は、外部のテスト支援会社との協業も有効な手段の一つです。専門的な知見に基づくレビューを受けることで、長期的に見た品質保証体制の強化につながります。

AGESTのドキュメントインスペクションサービスでは、25,000件以上のテスト支援実績により蓄積されたノウハウをもとに、仕様書をはじめとするドキュメント作成・レビューをお手伝いします。

自社の品質保証体制に課題をお持ちの方は、ぜひ一度ご相談ください。

ドキュメントインスペクション サービス詳細ページ

TFACT (AIテストツール)

関連コンテンツ