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