社内の不満を仕様に変える手順

ドッグフーディングを続けると、社内から声が集まります。「使いにくい」「なんか遅い」「ここが分かりにくい」。これらは貴重な情報ですが、そのままの形では開発に渡せません。感想と解決策が混ざっており、何を直せばよいのかが定まらないからです。

本記事では、集まった声を要求仕様に翻訳し、直す順番を決めるまでの手順を整理します。記録を集める仕組みそのものについてはドッグフーディングの始め方で扱っています。

手順1: 事実・解釈・要望に分解する

集まった記録を、まず三つに分解します。

多くの記録には「使いにくい」という解釈だけが書かれています。この場合は、書いた人に「何をしようとして、何が起きて、どう回避したか」を聞き直します。三つ揃えば事実になります。

要望は、そのまま仕様にしません。要望は利用者が思いついた解決策であって、解決すべき問題そのものではないからです。「元の位置に戻してほしい」という要望の裏には「編集した行を見失う」という問題があり、解決策は並び順の維持かもしれませんし、編集した行の強調表示かもしれません。問題を特定してから解決策を選びます。

手順2: 起きた回数を数える

次に、同じ事実が何回記録されたかを数えます。記録の言い回しは人によって違うため、同じ問題を指すものをまとめる作業が必要です。

数えるときの注意点があります。回数は「記録された数」ではなく「起きた数」です。同じ問題に何度も遭遇しながら、面倒で一度しか記録しなかった人がいます。まとめる際に「これは週に何回くらい起きますか」と一言確認するだけで、実態に近づきます。

対象業務の全体件数に対する割合も押さえます。月に3回の発生でも、対象業務が月5件なら深刻な問題です。

手順3: 深刻度を業務への影響で判定する

深刻度は、感じ方ではなく業務への影響で判定します。三段階程度で十分です。

• 高：業務が止まる、誤ったデータが記録される、外部に誤りが出る
• 中：回避策はあるが、余計な手間や時間がかかる
• 低：気になるが業務は進む

判定を「どのくらい嫌か」で行うと、声の大きさに引きずられます。「止まったか」「間違ったか」「余計な手間が何分かかったか」という問いに置き換えると、判定がぶれません。

余計な手間は時間で書き留めておきます。一件あたり2分、週に20件なら週40分。この数字が、直す価値を判断する材料になります。

手順4: 頻度と深刻度で並べる

頻度と深刻度が揃えば、直す順番はほぼ自動的に決まります。

この表の価値は、直すものを決めることより、直さないものを決められることにあります。「頻度低・深刻度高」を回避手順の明文化に割り当てている点が要です。めったに起きないが起きると業務が止まる問題は、実装で解決するより、起きたときの対処を全員が知っている状態の方が費用対効果が高い場合があります。

手順5: 社内固有の要望を仕分ける

並べ替えたあと、外部の利用者にも当てはまるかを確認します。ここを省くと、社内の業務手順に合わせた機能が積み上がり、プロダクトが社内専用に寄っていきます。

仕分けの問いは次の三つです。

• この業務手順は、対象利用者の組織にも存在するか
• この要望は、社内用語や社内の既存データ形式を前提としていないか
• 対象利用者が同じ状況になったとき、同じ不便を感じるか

当てはまらないものは、仕様から外し、社内向けの運用の工夫（手順書、設定、社内だけの補助ツール）として扱います。この判断を怠ったときに起きる問題は社内でだけ通用するプロダクトの罠で扱っています。

判断がつかないものは保留にし、外部の協力者に確認するまで着手しません。社内の声だけで判断すると偏ることについてはドッグフーディングの限界と誤判断を参照してください。

手順6: 満たすべき条件の形で書く

最後に、開発に渡す形に書き換えます。書くのは解決策ではなく、満たすべき条件です。

書き換えの例を挙げます。

• 元の記録：「一覧が使いにくい」
• 事実：「編集して保存すると一覧の先頭に戻り、編集した行を探し直している。1日20件の処理で毎回発生」
• 満たすべき条件：「編集後に一覧へ戻ったとき、編集した行を探し直さずに次の行へ進めること」

条件の形で書くと、実装方法の選択肢が開発側に残ります。並び順の維持でも、編集した行への自動スクロールでも、一覧に戻らず次の行を開く形でも、条件を満たせば構いません。要望をそのまま仕様にすると、より良い解決策が検討されなくなります。

あわせて、確認方法も書きます。「編集後の操作で、探し直す動作が発生しないこと」のように、直ったかどうかを判定できる文にします。速度や件数に関わるものは非機能要件として、数値の目安を添えます。

手順7: 直した後に記録が減ったかを見る

修正をリリースしたら、同じ内容の記録が減ったかを確認します。減っていなければ、問題の特定が間違っていたか、解決策が効いていません。

記録が減ったかどうかを見る習慣があると、仕様化の精度が上がっていきます。逆に、直して終わりにすると、直したつもりの課題が形を変えて記録され続け、原因の見立てが改善されません。

感想を事実に戻す作業が仕様化の中身

社内の不満を仕様に変える作業の中身は、感想を事実に戻し、回数と影響を数え、外部の利用者にも当てはまるかを仕分け、満たすべき条件の文にすることです。頻度と深刻度の二軸で並べれば、直す順番も直さない判断も、議論せずに決まります。

この流れが回り始めると、社内検証は「不満が溜まる場」ではなく「仕様が生まれる場」になります。効果の測り方はドッグフーディングの効果を測るで整理しています。

UXデザインやWebシステム開発における要求整理についてご相談がありましたら、お問い合わせからお気軽にご連絡ください。