多すぎた「隠し味」-シェフ秘伝のレシピから見えてくるものとは？ / Too many “hidden flavors”

弥生株式会社　もくテク
弥生QAエンジニアと品質を考える会 ～カレーづくしの考察集～（2023/04/20）
https://mokuteku.connpass.com/event/275711/

1. 多 す ぎ た 「 隠 し 味 」 ー シ ェ フ 秘 伝 の レ シ ピ か ら 見 え て く る も の と は ？ 弥 生 株 式 会 社 福 田 柾 也
2. 本日の内容 • 元々テスト計画からテスト実施までを一人で行っていた私が、一部の作業 を別の方にお任せするようになってから生じた色々な課題に関するお話し です テスト計画 テスト作成 テスト実施 私（店長役として登場） 新人さん テスト作成 テスト実施 テスト設計 ？
3. こちらは、地元でこだわりの洋食屋を経営してきた店長と新人のお話です。 店長はこれまで調理や接客を一通りこなしてきましたが、コロナ禍や物価 高の事情により、経営に専念する必要が出てきました。 そこで、アルバイトの新人にまずは看板メニューのカレー作りを任せるこ とにしました。 店長はこの道15年で、味に対するこだわりが強く、完璧を求める性格です。
4. レシピにはカレー作りの工程が書かれているのですが、細かな手順は省か れており、実際は長年の勘と経験によるアレンジが随所に加えられていま す。 先週から入ったばかりの新人はレシピやマニュアルもとにカレーを作って みましたが、店長が納得する味のカレーを作れず、困惑しています。 新人「店長、レシピ通り玉ねぎは細切りでいいんですよね？」 店長「おう、具材としてはな。隠し味に入れる分はみじん切りだぞ。あと は、はちみつ、コーヒー、しょうゆ、りんごかな。その日の調達状況にも よるけど。」 新人「・・・・。」
5. 店長に一つ一つ作り方を再確認していると、レシピには書かれていない隠 し味や下ごしらえが大量にあることが分かりました。 新人はレシピと実際の調理内容とのギャップに戸惑っているようです。 果たして、店長は新人にカレー作りを任せることができるのでしょうか？
6. 私の経験談に基づく実話 • 極限まで効率的に作られたテストシナリオ 店長 店長 • 手順に重複や無駄がある • 確認観点に漏れがある 新人さん
7. 事象から見えてきたこと • 依頼された側は何が「効率的な手順」であるか分からないが、依頼する側 はこの点を見失いがち • 依頼された側に過去の経験がない場合、必要な工程が漏れる場合がある が、依頼する側は「当然確認してくれる」と期待しがち
8. 事象から見えてきたこと • 依頼された側は何が「効率的な手順」であるか分からないが、依頼する側 はこの点を見失いがち • 依頼された側に過去の経験がない場合、必要な工程が漏れる場合がある が、依頼する側は「当然確認してくれる」と期待しがち 「経験則に基づく隠れたこだわり（＝隠し味）」が伝わっていない ※ここでの「隠し味」とは、「レシピに明文化されていない調理過程」を指します。
9. 「経験則に基づく隠れたこだわり」とは？ ①複数の経路、導線から実行できる場合は最短ルートで実行する 画面D 画面B 画面A 画面C 画面F 最短ルート 画面E 画面遷移図
10. 「経験則に基づく隠れたこだわり」とは？ ②過去の障害や仕様変更から、重点的にテストを行うべき個所を知っている 2023 2016 2017 2018 2019 2021 2022 2020 大幅な仕様変更 大幅な仕様変更 大幅な仕様変更
11. やってみたこと ①依頼者側と作成者側の情報量の格差を埋めるようにした パターン網羅表 画面遷移図 画面A 画面B 画面C 画面F 画面E 画面D 画面G 画面I 画面H 議事録 ------------ ------------ ------------ 仕様決めメモ ------------ ------------ ------------ 過去資料 ------------ ------------ ------------ 新人さん へぇ、こんな風になってたんだなぁ
12. やってみたこと ②過去の障害や確認観点の経緯、背景となる補足情報をテスト設計書に書 き込んだ テスト設計書 ------------ ------------ ------------ 過去の障害情報（チケットなど） 観点 観点の背景、経緯 参考になる設計書や資料のリンク 新人さん なるほど、そんなことが あったのかぁ
13. やってみた結果 ①依頼者側と作成者側の情報量の格差を埋めるようにした Good Bad 一番早くできるパターン で作ってねー 店長 新人さん あぁ、 パターンAの ケースか 新人さん 確認するものが 多いなぁ テスト設計書 外部設計書 画面遷移図 過去資料 ---------------- ---------------- ---------------- ------------ 前提を揃えることができた 作業着手までの資料確認の時間が増えた
14. やってみた結果 ②過去の障害や確認観点の経緯、背景となる補足情報をテスト設計書に書 き込んだ Good Bad おお、助かる！（この調子で 他のレシピも任せたいなぁ） 店長 新人さん 書くことが多い なぁ・・・ テスト設計書 ---------------------- ---------------------- ---------------------- ---------------------- ---------------------- ---------------------- 店長、手順が間 違ってるんで直 しときますね 店長 新人さんがテスト設計の不備やミスを 指摘、修正できるようになった 依頼側の準備作業が増えた 背景 経緯 過去障害
15. 現在取り組んでいること • 資料の読み方を作業依頼時に説明する – 情報は多ければ良いというわけではない – 見るべき要点、見なくてよい個所を伝える • テックリード、エンジニアと協力し、要件定義書や設計書に処理の背景や意 図を記載してもらうよう働きかけている – 要件定義書や、設計書をはじめて見た人にも、その仕様の経緯や背景が理解できる ようにするため
16. 新人が増えたときどうする？（今後の話） 導入作業としては、下記を想定 • ①全体の概要を画面遷移図で説明 – ざっくりの全体像を知る • ②基本動作網羅テストの実施 – ここで細かな画面単位の機能を触ってみる • これ以降は個別の案件ごとに設計書を個別に確認する時間を設ける – 設計の背景や経緯が書かれているので、テストの意図もここで理解できる
17. まとめ • これまで一人で行っていた作業を別の人に依頼したら、想像していたもの と異なるものが出来上がった • 原因を分析してみると、作業を依頼する側に 「経験則に基づく隠れたこだ わり」があり、それが依頼される側に伝わっていないことが分かった • 上記を解決するため、以下の取り組みを行った – 依頼者側と作成者側の情報量の格差を埋める – 過去の障害、経験から得られた情報をテスト設計書に書き込む • さらなる取り組みとして、情報はただ渡すだけではなく、読み方まで伝え る。上流工程の成果物にも経緯や背景を記載する、を実践中
18. 店長と新人さんのその後