再現性を生む完璧な指示の出し方

さて、今回はですね、ソフトウェアのバグをどうやって見つけるかという、そういうテーマの資料を深掘りしていきます。 でも、これを聞いて、「あ、自分は開発者じゃないから関係ないや」ってもし思ったなら、ちょっと待ってください。 実はこれ、何か新しいプロセスを作ったり、チームに作業を依頼したりする時に、もう誰にでも役立つ、完璧な指示の出し方についての話なんです。 ええ、そうですね。今回あなたが共有してくれた資料、ええと、先輩のアキさんと後輩のカイくんでしたっけ？ その対話形式でテスト仕様書の書き方を解説してるっていう。 はい、そうです。この資料の革新は、まさにあなたが今言った通りで、専門技術の話に留まらない、すごく普遍的な知恵なんですよね。 誰がやっても同じ結果を出せること。これを専門的には「再現性」と呼びますけど、この考え方こそが、あらゆる仕事の品質を高める鍵になります。 再現性ですか。あ、なるほど。確かに誰がやっても同じクオリティの結果が出るっていうのは、もう、あの開発だけの話じゃないですもんね。 例えば、新人に業務を引き継ぐときのマニュアル作成とか、あとはコールセンターの応対スクリプトとか。まさに、あらゆる場面で求められる考え方ですよね。 その通りです。で、この資料が面白いのは、その再現性をどうやって確保するのかを、「秘伝のレシピ」っていう、すごく分かりやすい比喩を使って解き明かしていくところなんです。 秘伝のレシピ。いい言葉ですよね。ええ。 曖昧な「ささっとやっておいて」みたいな指示がいかに危険か、そしてどうすれば誰でも同じ味を再現できるレシピが書けるのか、その具体的な方法論がこう、見えてくるんですよ。 いいですね。では早速、その秘伝のレシピの作り方を紐解いていきましょうか。資料の中で、後輩のカイくんが 「とりあえずログインしてみて、変な動きがないか確認するじゃダメなんですか？」って、こう素朴な疑問を投げかけるところから話が始まります。 ええ。気持ちはまあ分かりますけどね。うん、多くの現場で、特に時間がないときなんかは、そういう曖昧な指示は飛び交いがちですからね。 でも、先輩のアキは「それでは人によってチェックの厳しさがバラバラになる」ってまあ一蹴するわけです。はい。ここが最初の、すごく重要なポイントですね。 これを料理に例えるなら、あの「お肉をいい感じに焼いてください」ってだけ書かれたレシピみたいなものですよね。あ、なるほど。わかりやすい。 僕が焼いたらミディアムレアだけど、他の人が焼いたらウェルダンになっちゃうかもしれない。 以前、後輩に「これ、いい感じに資料まとめといて」って頼んだら、僕が欲しかったデータがほとんど入ってない、なんかデザインだけが綺麗なスライドが出てきた、苦い記憶が蘇りますよ。 まさにそれです。その「いい感じ」が人によって全く違う。そうなんですよ。 ここで排除すべきなのは、もう完全に主観なんです。チェックする人のその日の体調とか気分、あるいはその業務に対するスキルレベルに結果が左右されては、 品質を保証するなんてことは、まあできないわけです。うーん。 で、この主観の排除っていうのは、指示を受ける側だけじゃなくて、実は指示を出す側にも言えることなんですよね。と言いますと？ 指示書を書く側が、「これくらい言わなくてもわかるだろう」ってこう思い込んじゃってるケースが非常に多い。ああ、耳が痛いな。 その書き手の主観こそが、曖昧さの一番の原因だったりするんです。だから、誰がいつ何度やっても同じ手順で同じ結果に辿り着ける、精密なレシピが必要不可欠になる。 これはもう品質保証の根幹をなす考え方ですね。 なるほど。じゃあ、その誰もが同じ味を再現できる「秘伝のレシピ」には、具体的に何を書けばいいんでしょうか。 資料では、重要な要素が3つあるとされてましたよね。操作手順、入力データ、そして。最も大事なのが「期待値」ですね。 そうです、期待値。ええ、その3つです。多くの人が手順書を書くとき、最初の2つ、操作手順と入力データまでは書くんですよ。はい。 料理で言えば、作り方と材料ですからね。はい。でも、本当に差がつくのは、3つ目の期待値をどれだけ具体的に書けるかなんです。 期待値。これ僕も最初聞いた時、何のことか正直ピンとこなかったんですよね。期待する値って言われても、みたいな感じで。 資料では「こう動くはずだ」という、その正解のこと、と説明されてましたね。そうです。 単に作業を指示するだけじゃなくて、その作業の結果、どういう状態になっていれば成功なのか。その正解の姿を明確に定義する。 これがレシピの味を決める、いわば最後の隠し味なんです。隠し味。 ええ。例えば、資料の例がすごく秀逸でしたよね。パスワードの入力テストの例ですね。 パスワード欄にわざと何も入れずにログインボタンを押す、というのが手順。はい。これに対して、期待値をただ「エラーが出る」と書くだけでは不十分だと。 ええ、もし「エラーが出る」としか書いてなかったら、どんなエラーが出ても、テストした人はオッケーって報告する可能性がありますよね。 例えばシステムがクラッシュして、画面が真っ白になって、なんか意味不明な英語のエラーコードが表示されたとするじゃないですか。はい。 これも一応エラーが出たことにはなりますからね。うわあ、それは怖いですね。バグなのにテストをパスしてしまう可能性があるわけだ。 そこで大事なのが、期待値を具体的に書くこと。資料では「パスワードを入力してください」という赤いエラーメッセージが表示される、と、もう正解をセットで書いておくと。 これなら間違えることはない。まさに。後輩のカイくんも、なるほどって気づいてましたけど、これを書いておかないと、 出たエラーが私たちが意図した正しいエラー表示なのか、それとも未知のバグなのか、テスト担当者には判断のしようがないんです。 ふむふむ。つまり、何が合格なのかっていうゴールテープの位置を走り出す前に全員で共有しておくってことです。 これがなければ、担当者は自分の感覚で合否を判断することになって、品質はあっという間にブレてしまいます。なるほどなあ。 そして、レシピ通りにちゃんと料理しましたよ、と証明するために、もう一つ大事な要素がありました。それがエビデンス、つまり証拠ですね。ええ。 「この画面のスクリーンショットを撮ってください」というように、証拠の残し方までレシピに書いておくと。 これは後から第三者が本当にテストしたのかとか、その結果どうだったのかを客観的に追跡できるようにするためですね。 品質保証の世界では、この追跡可能性、カタカナで言うと「トレーサビリティ」が非常に重視されます。トレーサビリティですか。はい。 例えば、製品がリリースされた後に重大な問題が見つかったとしますよね。ええ。その時に、いつ、誰が、どのような手順でテストして、その結果どうだったのかを正確に遡って確認できなければ、 原因究明も効果的な再発防止策を立てることもできない。「ちゃんとテストしたはずなんだけどなあ」みたいな、記憶だけの議論になってしまう。ああ。 それでは組織として成長がないんです。だから証拠が大事なんですね。資料にあった実務的なコツも面白かったです。 「エビデンスのファイル名には日付とテストナンバーを入れよう」とか。こういう細かな配慮が後々のトラブルを防ぎ、管理コストを下げるわけですね。 ええ、素晴らしい指摘です。それって、つまり指示の解像度を上げるってことなんですよ。指示の解像度。 はい。単に「スクリーンショットを撮って」と指示するんじゃなくて、20260106ログイン03.pngみたいな名前で、共有フォルダーのエビデンスって場所にいれてください、とまで指示する。 作業そのものだけじゃなくて、その成果物をどう扱うかまで含めてレシピに落とし込む。これがプロの仕事です。指示の解像度を上げるか。うーん、耳が痛いな。 でも、そうやって解像度を上げていくと、今度はまた別の問題が出てきますよね。後輩のカイくんも、まさにそこを突いてくるんです。 「でもテスト項目って無限に作れちゃいますよね」と。いい質問ですよね、それ。まさにその通りで、 パスワード入力一つとっても、文字数、使える文字の種類、記号の組み合わせ、空欄、全角・半角。 いや、考え出したらキリがないですよ。そうなんです。すべての可能性を網羅するなんて、時間的にもコスト的にもまあ不可能です。 そこで出てくるのが「テストデザイナー」という考え方なんですね。ええ。闇雲にバグを探すんじゃなくて、戦略的にレシピを作る。 資料には「V字モデル」とか「境界値分析」とか、ちょっと専門用語が出てきますけど、まあ難しい言葉は一旦置いておきましょう。はい。 要点は、どこを重点的に守るべきかを設計する力のことです。どこにバグが潜んでいそうか、どこが壊れるとビジネスへの影響が大きいか。 そういったリスクを分析して、限られたリソースをどこに集中投下させるか。その戦略を立てる専門家ですね。 なるほど。それってなんだかお城の防御を考えるのにちょっと似ていますね。まさにその例えは的確です。 お城の全ての壁を同じ厚さにはしませんよね。しないですね。敵が攻めてきやすいであろう大手門の守りは硬くして、石垣も高くして、兵士も多く配置する。 でも、裏手にある崖の上にあって誰も使わないような小さな窓まで、同じレベルの防御はしないはずです。確かに。予算も兵士の数も有限ですからね。 それと同じで、ユーザーの個人情報とか決済に関わる機能は、何重にもテストを重ねて徹底的に守りを固める。 一方で、滅多に使われない設定画面の隅にある表示が1ピクセルずれても誰も困らないような部分に、同じ熱量を注ぐのは非効率です。 そのメリハリ。つまり、守るべき場所とある程度は許す、容認する場所を見極めるのが、テストデザイナーの腕の見せ所なんです。ふーん。 彼らは単なる作業者ではなくて、品質という観点からの設計者。いわば品質の建築家なんですよ。いやあ、面白い。 さて、ここまで秘伝のレシピの作り方を見てきましたが、この考え方、あなたがどう活かせるか、ですよね。 ソフトウェア開発をしていなくても、例えば新しい業務フローをチームに導入するときを想像してみてください。日常業務への応用ですね。 ここからが、この資料の知恵を本当に自分のものにするためのステップです。「この手順でやってみて」って口頭で伝えたり、簡単なメモを渡すだけじゃなくて、 資料にあったエクセルのサンプルのように、No、項目、手順、入力値、期待値、結果、エビデンス、みたいな、そういうフォーマットで手順書を作ってみる。おお。 特に期待値、つまり「この状態になっていればOKです」っていうゴールを明確に定義するだけで、チームの認識のズレは劇的に減るはずです。 まさしく。例えばあなたがマーケティング部のマネージャーで、部下に競合の動向調査を依頼する場面を考えてみましょうか。はい。 「A社の最近の動向を調べておいて」っていう曖昧な指示では、出てくるレポートの質は担当者によってもうバラバラになります。ああ、目に浮かびます。 A社のWebサイトのトップページだけ見て、「特に新しい動きはありませんでした」で終わる人もいれば。いるでしょうね。 過去3ヶ月のプレスリリースとか業界レポートまで読み込んで深い考察をしてくれる人もいる。そこでレシピの出番です。 手順として、「競合A社の直近3ヶ月のプレスリリースと主要な業界ニュースサイト3つをチェックする」。 入力データは、「各社のWebサイトのURLとニュースサイトのURL」。そして期待値は。 「A社の新製品情報、価格変更、他社との提携に関する情報をエクセルの一覧表にまとめること。特に価格変更があった場合は、その背景についてあなたの推測を100字以上で記載すること」。 おお！ここまで具体的に書けば、誰がやっても一定レベル以上のアウトプットが期待できるわけです。なるほど。「期待値を100字以上で記載」までが期待値なんですね、すごい。 これならアウトプットの質が担保されますね。なんなら家族に買い物をお願いするときにも使えそうです。 「期待値：特売の卵を1パックと、脂肪分が3.6%以上の牛乳を1リットル」みたいに。素晴らしい応用例です。まさにその通り。ありがとうございます。 何かをチェックする、誰かに作業を依頼する、その際に「期待値は何か、作業した証拠をどう残すか」を意識するだけで、 手戻りとか、「言った言わない」の不毛な確認といった。不毛なコミュニケーションコストも、単純なミスも減らすことができる。 これは部署や役職に関わらず、誰でも明日から使える非常に強力なツールだと思います。というわけで、今回は「バグを見逃さないための秘伝のレシピの作り方」について、 あなたが共有してくれた資料を深掘りしてきました。重要なのは誰がやっても同じ結果になる「再現性」。ええ。 そのために操作手順、入力データ、そして何より期待値という正解を明確に定義することが不可欠でした。 そして全ての可能性を試すんじゃなくて、テストデザイナーのように「お城のどこを守るべきか」戦略を立てること。さらに作業の証拠を残すことで、プロセスの透明性と追跡可能性を確保すること。 この一連の考え方はソフトウェア開発に留まらず、あなたの仕事の品質そのものを高めるヒントになったんじゃないでしょうか。 最後に最後に少し視点を変えて考えてみましょうか。今回の資料はどうやって間違いとか期待通りでない動きを見つけるかという話でしたよね。 いわばマイナスをゼロに近づけるための技術です。ええ。ここで一つ思考をジャンプさせるための問いが浮かび上がるんですけど。私たちは「期待外れの失敗」を見つけるための 非常に洗練されたプロセスを設計しようとしていますよね。では、その逆。「期待以上の成功」を体系的に見つけるためのプロセスは設計しているでしょうか。 期待以上の成功ですか。偶然の産物、ハッピーアクシデントみたいな。ええ、そうです。例えばユーザーが開発者の意図しない、でも非常に便利な使い方を偶然発見したとき。ああ。 あるいは、ある機能が想定していなかった全く別の顧客層にものすごく刺さったとき。そういったポジティブな想定外の出来事を、私たちは単なるラッキーで終わらせていないでしょうか。 確かに。そういう話を聞いても「へー面白いね」で流してしまっているかもしれないです。 エラーを探すためのレシピがあるのなら、予想外の価値を発見するためのレシピも書けるんじゃないでしょうか。 ユーザーからの問い合わせログの中から、特定のキーワードを含む感謝の声を定期的に抽出する手順。はい。 製品の利用データの中から、開発者の想定とは異なる使われ方をしているパターンを検出する仕組み。あなたあなたの身の回りでも、そんな「幸せのバグ」を見つけるためのレシピを考えてみるのはいかがでしょうか。