昨日の正解は今日の正解ではないかもしれない
ソフトウェアテストの小ネタ - Qiita Advent Calendar 2024 - Qiita 17日目の記事です。
製品開発、特にテスト（checkingではなくtesting）*1で難しいのは、自分の中での正解を持つ一方で「自分は間違っているかもしれない」と疑わなくてはならないところです。これは、だから自分は間違っていない＝正しい、を証明するために証拠を集めたり、製品や開発やテストに必要な、ありとあらゆる知識や技術を身につけましょう、という話ではなく、たとえ証拠を集めたとしても、たくさんの知識や技術を身につけたとしても、本当にそれが正解かはわからないぞ！という態度で臨まないと、テストなんてできないよね、という話です。
みなさんお気づきのように、本当にそれが正解かはわからないのに、実際にテストするときには、なんらかの期待値や正解が必要になる、という矛盾があります*2。わたしはこの矛盾を受け入れるために、全力で導いた「なんらかの正解」を「これは今日の正解だぞ」と考えるようにしています。そして明日になったら「昨日の正解は今日の正解ではないかもしれない」と考え、あらたな気持ちで製品に向き合い、今日もまた全力でテストするのです。今日の正解って、昨日の正解の仮説と検証も受け継いでいるんですよね。わたしくらいになるとcheckingでも疑いますよ。Enjoy testing！
あわせて読みたい
JaSST東北名物ワークショップを体験して思ったこと #jassttohoku
JaSSTソフトウェアテストシンポジウム-JaSST'24 Tohoku に参加しました*1。この記事では、そこで行われたワークショップ『クラシフィケーションツリー技法』を体験して思ったことをメモしておきます。技法自体の紹介やワークショップの詳しい内容については触れないので、参加した方にしかわからない部分が多々あると思います。
また、当日配布されたアンケート用紙に感想を書かずに提出してしまったので（へとへとで頭がまわりませんでした）実行委員のみなさんやこのシンポジウムがうまくいくように尽力された方へのフォードバックと感謝もお伝えできればと思います。
ワークショップを体験して思ったこと
クラシフィケーションツリー技法は言葉としては聞いたことがあるくらいで知りませんでした。書籍『ソフトウェアテスト技法ドリル』であれだけ勉強したのにどういうことだ？と思ったら第1版には書かれてなかったのでよかったのですが（そういうことではない）第2版 にはクラシフィケーションツリー技法が追加されています。*2
優しさにあふれていたワークショップ
ワークショップに参加する側の気持ちって、これからどんなことやるんだろう（やらせられるんだろう）と多少なりとも不安があるものです。JaSST東北のワークショップは導入フェーズがものすごく丁寧。どんな技法なのか、どのように使うのかをわかりやすく紹介してくれます。それを聞いていればチュートリアルが解けてしまうスタイルは、誰一人として置いていかない優しさにあふれていて、大好きです。
お題選定が秀逸 x ムーブメント爆誕
演習はシンプルでわかりやすいお題なのに、考え方や解き方にバリエーションがつけられるようになっていて（実行委員のみなさんの思惑通り？）あんなに短い時間でもちゃんと悩めたのがよかったです。自分の頭で考えないと身につかないんだよね。
今年は注目すべきムーブメントがありました。手を動かしながら問題を解いていくと「知っている → わかる」が体感できるので、うれしくなってしまうんですよね。それが表出して誰ともなく自然と拍手がわきあがってました。とても心地よかったです。
JaSST東北のワークショップは頭が疲れることでも有名ですが、ハマる人にはハマり、わたしのようなリピーターも一定数いますので、このよろこびの表明とみんながみんなを褒めたたえるムーブメントは、来年から定番になるかもしれませんね。
時間に制約がある中でどう対処していけばよいのか
時間に制約がある中でワークをやるので「もうすこし考えたいぞ」の気持ちが残るのは仕方のないことですが、他のグループの成果物を見せてもらいながらお話（どういう気持ちでこうしたのか、何を優先したのか、悩んだところはどこかなど）を聞いていたら「もうすこし考えたいぞ」が、うまく消化していく感じがしました。
時間に制約があるのは仕事でも同じなので、やりたいこと、やるべきことに、どう対処していくのか、どう折り合いをつけていくのかーーのようなテーマについても、なんらかの示唆を与えたのではないでしょうか。そういうテストのお悩み、わりと多かったよね。
シンポジウム全体としてまとまっていて流石です
話がそれてしまいましたが、成果物を見学するターンで各グループで説明する人を残したのは大正解だと思います。基調講演の「説明できるテスト」とも動的につながり、シンポジウム全体としてもきれいにまとまっていて流石だなあと思いました。井芹久美子さんによる基調講演『説明できるテストをつくるためにできることを考える』は、なにもかもが素晴らしすぎて雑に感想を書きたくないので今日は書きませんが、もしかしたらわたししか気がついてないかも！と思うのは「この講演自体が基調講演の内容を体現していた」ことです。この講演内容を参加者が理解できれば、行動してもらえる。そのレベルまでみんなを引き上げてくれるような内容になっていたと思いませんか？
自分の開発やテストに対する考え方の癖がダダ漏れ事案
最後のワーク、仕様変更（機能追加）の演習は個人的にめちゃくちゃ面白かったです。普段の製品開発ではほぼほぼこれしかないので、自分の開発やテストに対する考え方の癖（仕様書とコードは一致していないかもしれないし、仕様書だって間違っているかもしれないし、この仕様だって本当に良いものになっているのか？）があふれ出てしまい、同じグループのまこっちゃんさんとsaeさんの思考にバイアスをかけてしまったかもしれない…と、今になって反省しております。
正解は一つではない
ワークショップ全体をとおして何度も聞いた「正解は一つではない」という言葉も印象的でした。製品開発って単純な正解探しのようなものではないのでね、チーム全員の脳みそを使い、意見や知恵を出しあって、そのときの最善で最適な解を探し続ける旅のようなものかもしれないな、と帰りの新幹線の中でしみじみと考えてました。
次回は西暦2025年（仏暦2568年）5月30日(金)開催！
今回も大満足のワークショップでした。次回も参加したいです。講演者の井芹久美子さん、実行委員のみなさん、このシンポジウムがうまくいくように尽力されたすべての方々、それから参加者のみなさん、ありがとうございました！
あわせて読みたい
書籍『ソフトウェアテスト293の鉄則』の素晴らしいところ
書籍『ソフトウェアテスト293の鉄則』を愛読しているソフトウェア開発者、特にテスターはたくさんいると思います。「まえがき」が本当に素晴らしいよね。
標準化されたドキュメントに現場での知恵が収められているとは考えないほうがよい。
本書は、ソフトウェアテストについての総合的なガイドブックではないし、解答集でもない。
これこれ、これですよ。著者たちの何事にも疑いの目を持つその姿勢がテストを体現してるしテスターらしいなと思う。疑うだけじゃないよ。それであなたはどう考えるのか、あなたの状況に適用して実践し、評価してほしい。あなたの開発の現場ではもっと良い方法、手法があるはずだ（自分自身で探し求めよ）という強い思いが「まえがき」から伝わってくる。
で、この流れでいくとテスターなら当然「鉄則を疑ってみる」になるはずなんですが、読みすすめていくと「そうそう、そうなんだよね」「わかるー」「沁みいります…」となるから油断ならない。
あなたの推し鉄則は何番ですか？
「ちょうどいい」の見つけかた
お客さまへの製品リリースが頻繁には行えない状況でのMVP（Minimum Viable Product）は、どうしても機能を盛ってしまうことになりがちと感じています。そんななか、チームにJoinして2、3年の若者二人による、ある機能開発で何を作るか？の検討会がありました。「それを落としてきたかー」「そこをそう変えてきたかー」と思うような提案をしてきて、わたしたち（開発者）よりもお客さまに近い立ち位置の人も混ざっていたので、内心ハラハラしましたが、話し合いの結果「まずはそれでやってみよう」となり、へーー、ここまで削っていいのかーーーと、たいへん勉強になりました。
製品としての「ちょうどいい」を見つけたいとき「少なすぎるくらいの内容で提案する」というのは言葉としては知っていますが（冒頭にも書きましたが、製品リリースやアップデートが頻繁には行えない状況で）本当にそんな提案をするのは難しいです。
少なすぎるくらいの内容で検討をはじめ、話し合いの中で「これは絶対落とせない」となれば真のMVPなので追加すればよい。それはそうだと思います。一方でスレスレMVPかそうでないかくらいの微妙なライン上にいる仕様を「削っていいんじゃない？」とは言いづらい。あったら便利だし、お客さまにも喜んでもらえるのでは・・・なんて思ってしまう。あった方が良いものと、絶対にないと成立しないものを選択する過程と分かっていても、その取捨選択は難しいです。少なくともわたしには。
今回うまくいった要因を考えてみました。
- 落とした仕様も議題にあげて、削った理由（自分たちなりの考え）を話した
- 当初想定していたものから大幅に変更した仕様も同様
- 検討会の前にエース級たちに相談して相当勉強して考え尽くしている（言葉の端々からわかる）
- 二人が想定してない使い方を指摘されたときも、それがないと本当に製品として成り立たないのかどうかの視点を最後まで持ち続けた*1
- 似たような既存機能でその仕様は搭載していないが、それはどう説明しますか？と良い問いかけができた（他の機能もよく知っていないとその場ですぐにこんな返しはできません）
- 作りはじめてからやっぱりここはどうしてもだめだね（お客さまが困る）となったら、そのときはもちろん検討して対応します、と始めに宣言した
言葉にすると普通なんだけど、当たり前のことが当たり前にできてすごいなと思います。
そうそう、検討会自体の進め方のアドバイスをプロの無職にもらっていて、それを素直にきいてやったのもうまくいった要因かもしれません。
- 議事録を先に書く（普通は検討会のあとに議事録を書きますが、先に議事録を書いてしまうアイデアです。検討会は議事録を見ながらやります。こんなへんてこりんなやり方、よく思いつくよな…）*2
- 時間切れになったらこの仕様でいきます！で始める（より重要なことから話そうとみんなが意識する。どうでもいい話は自然に抑制される。集中すべきことに集中できる）
検討会のあと、事務所に戻って若干興奮気味に具体的にどこが良かったか、素晴らしいと思ったか、二人からわたしが学んだことをそれぞれに伝えました。
わたしたちの製品はいったんリリースしてしまうと、あとから仕様を変更したり削除するのは簡単にはできません。入れてしまった仕様はこの先何十年も気にし続けながら開発／テストしなくてはならないのです。未来のコストも考えたら本当に素晴らしい提案だったと思います。
わたしが熱心に褒めるので気持ち悪くなってしまったのか「でもこれに集中してできるのも他の人たちの助けがあってのことで、チームでやってることなので…」と恥ずかしそうに言うので「そういう風に思えるところも素晴らしいよ」って伝えました。
自然とそうなる仕組みづくり（テスト実施者の名前を記録しないとどうなるか）
先日の航空機事故を受けて書籍『失敗の科学』を読んでいます。第１章 失敗のマネジメント（「ミスの報告」を処罰しない）に、次のようなことが書かれていました。
学習の原動力になるのは事故だけではない。「小さなミス」も同様だ。パイロットはニアミスを起こすと報告書を提出するが、10日以内に提出すれば処罰されない決まりになっている。また現在航空機の多くには、設定した高度などを逸脱すると自動的にエラーレポートを送信するデータシステムが装備されている。データからは、操縦士が特定されない仕組みだ。
この「操縦士が特定されない仕組み」は、忍者式テスト*1の「テスト履歴」を思い起こさせました。履歴として記録するのはテストした日付と結果（OK、NG）のみ。誰がテストしたかは記録しません。といっても、NGの場合はその詳細が報告されるので誰がテストしたかは自ずとわかります。OKの場合はわかりません。この記事の最後に忍者式テストの履歴（例）を載せましたのでご覧ください。*2
咳チームにJoinする前は、テストを実施した人の名前を記録するのは普通というか当たり前でしたので「あとから誰がテストしたのかトレースできないの？」とびっくりしました。「省力化なのかな？ 咳チームのチケットシステム*3はログイン操作もないし、いちいち名前をタイプするのは面倒だからやめたのかも」くらいの浅い認識だったと思います。
テスト実施者の名前を記録しない
たったこれだけのことが、テスト実施にたいする心理的負担をなくす効果とテスト本来の目的に意識を向けさせる力がある、と知るのは、咳チームにJoinしてから数か月後です。
テスト実施にたいする心理的負担がなくなる
咳チームはひとり毎日１時間、忍者式テスト専用のアルゴリズムによって抽出したチケットに書かれているテストケース「本日のおすすめテスト」を元にテストします。前述したように、テストした人の名前を記録しないので、誰がどのチケットのテストを確認したのかはわかりません。今日、Aさんは６チケット分テストしたかもしれないし、Bさんは１チケット分しかテストできなかったとしても、誰もそれを知ることはできません。
わたしたちのラボ（仕事場）にはテスト用のPCがずらりと並んでいて、テストの時間割にあわせてプログラマーがつぎつぎと現れます。だから「テストしているな」はわかります。でも、数を数えるような進捗管理はいっさいしないのです*4。
わたしは数を数えるような進捗管理をされる側だったことがあるのでわかるのですが、テストが思うように進まないと焦るんですよ。心理的なプレッシャーはテストにも影響します。テストに集中したいのに残りの時間が気になってしまい、本来その人が持つパフォーマンスが出せない、なんてことも少なくないのではないでしょうか。なお、数を数える進捗管理が悪いという話ではありませんので、お間違えのないよう。
テスト実施者の名前を記録しない、から浮かびあがるメッセージは「進捗はいっさい管理しません。１時間でできるテストを自分の思うようにやってください」であり、これはまた「テストをサボる人はいない（みんながみんなを信頼している）」という暗黙の了解も含まれていると感じます。
テスト本来の目的に意識が向くようになる
テスト実施にたいする心理的負担がなくなると、テスト本来の目的に意識が向くようになります。テスト実施者の名前を記録しない仕組みはここにつながるのか！と理解したときは、感動して心が震えてしまいました。
テストの目的は所属する組織やチームごとに、また同じチームでもテストレベルやテストタイプによって異なります。忍者式テストの目的は以下です。
私たちのテストは、ストーリーに書かれているテーマを起点として「本当によいシステムになっているのか」について、本物のシステムを使って確かめる過程である。操作手順のような基本シーケンスだけでなく、チケットに書 かれた開発日記（要求の背景、開発の経緯など）を読み直し、実際に今日のシステムで操作して、問題がないか、さらには、本当によいものになっているのかを実験する。単に不具合を見つけたいだけでなく、使いづらさや誤解をまねく仕様や手触りの良し悪しなども含めた理想との違いを知りたいのである。その理想さえも市場や環境の変化に応じて変わっていく可能性がある。
ストーリーに書いてあるテストを実施して分かるのは“テストケースに書かれている前提や操作において”うまく動くか、動かないかである。変更による意図しない副作用を検出するためのリグレッションテストとしての効果はある。しかし、私たちが手に入れたい問題を発見するには、このテストケースだけでは足りない。そのために、書かれているテストケースを出発点として、さらに新しいテストケースを考えながらテストしなくてはならない。
わたしたちは未知の問題（まだ見つかっていない問題）を見つけて直すためにテストします。だからチケットには書かれていない未知のテストケースを自分の頭で創造しながらテストすることが求められます。進捗を管理しないということは「数をこなすことが目的ではないですよ」という強烈なメッセージを与えます。１時間でたくさんのテストをこなすよりも１つの未知の問題を見つけるほうが喜ばれる。自分にしかわからないような違和感を面白がってもらえる。メンバーひとりひとりがこれを体感するので、自然とそうなる（目的にそった行動をしてしまう）のは当然といえば当然ですね。
忍者式テストの秘密公開！驚きの20年の実績が明かされる！
2023年（仏暦2566年）は、わたしにしてはあり得ないほど活動的な年になった。特に忍者式テストに関する外部への露出が増えて「急にどうした？」と感じられた方もいるかもしれない。なぜこんなことになったのかを記録しておく。
なお、タイトルは「AIタイトルアシスト」（はてなブログの生成AIによる新機能）に作ってもらった。リンク先の論文やスライドを見てもらえれば忍者式テストの秘密がわかるし、驚きの20年の実績（テスト結果）も載ってるから嘘じゃない。自分では思いつかないよ。すごいねぇ。
忍者式テストについて書き物を残したい
なぜこんなことになったのかのアンサーは「忍者式テストについて書き物を残したい」これに尽きる。忍者式テストは @m_seki が率いるチーム（咳チーム）が続けているXP（エクストリームな反復開発）に有効なプラクティスである。わたしは忍者式テストの実践者であり、素晴らしい取り組みだと実感する観測者である。20年を超える実績があり、多くのソフトウェア開発者に知ってもらいたい活動だ。
忍者式テストの初出は2004年のJaSST（ソフトウェアテストシンポジウム）で、その後も技術系カンファレンスで何度か発表している。が、いつもほとんど反応がない。なんでこんなにウケないのかずっと気になっていた*1。きっとわたしが忍者式テストをはじめて聞いたときに感じた「わけのわからなさ」に多くの民がやられているのだろうと思った。わけのわからなさは狂気にも似ている。身の安全を保つために近寄らないほうがいい。だから生物学的に見なかったことにするのではないか。その一方で一風変わったネーミングから「忍者式テストってなんだろう？」と興味を持つ人がいてもよさそうだ。
ここで問題がある。 @m_seki の発表スライドは非常に難解なのだ。発表を聞いた人ならぎりぎりわかるかもしれないが、あとからなんだっけ？とスライドを見直してもたぶんわからない。こんな感じだから発表を聞いてない人にはほぼほぼ理解できない。初出のスライドを見てもらうとわからなさがわかると思う。だから「いつか忍者式テストを言語化したい。ソフトウェア開発者が読んでまあまあ理解できるものを書きたい」と思っていた。
ここで問題がある。毎日の製品開発（つまり忍者式テスト）が刺激的で面白くて非常にうまくできていて、あっという間に一日が終わってしまう。わたしたちの製品を世の中にリリースし続けることの価値もわかっているから、その時間を削ってまでも書く？と思ってしまうのだ。定時まで仕事するとくたくたになるので、残業して執筆することも考えてなかった。
2022年の終わり頃、来年書かないともう書けないかもと思った。@m_seki に話したら「じゃあ、どこで発表するか決めよう」となり、ソフトウェアシンポジウム（SS2023）での発表を目指して準備した。ちょうどこの頃、社内表彰（高度技術者表彰）をもらったことも執筆の後押しになった。伝えたいメッセージと具体的なネタを書き出した。模造紙１枚の巨大なマインドマップになった。社外発表になるので上層部の人たちに時間をとってもらい４回にわけて咳チームと忍者式テストとそのマインドを話した。
ソフトウェアシンポジウム（SS2023）
1999 年に出版された eXtreme Programming[1](以下 XP)に端を発したアジャイル開発は世界中で広く普及し， アジャイル開発の基礎となる反復開発，テスト駆動開発[2]も広く知られることとなった. 私たちのチームはX線CT装置をXPで開発している. 本稿では，私たちの20年の実践から，反復開発の利点と反復開発に有効なプラクティス「忍者式テスト」を説明する.
- 「テストからはじめよ」〜忍者式テスト20年の実践から〜（論文）
- 「テストからはじめよ」〜忍者式テスト20年の実践から〜（発表スライド）
- 「テストからはじめよ」〜忍者式テスト20年の実践から〜（文字起こし）
マインドマップの中から内容を厳選して忍者式テスト入門編として発表した。これはこれで書き切った感はあるが、模造紙に書いたことの半分も書いていない。特にストーリーの分割について丁寧に書けなかったことが心残りだった。忍者式テストをうまくやるためにはシステムを変更する最小単位（ストーリー）の切り方と順番が重要である。ここは具体的な例を使って説明しないと伝わらないと思っていたので、ソフトウェア品質シンポジウム（SQiP2023）での発表を目指して準備することにした。
ソフトウェア品質シンポジウム（SQiP2023）
反復開発やテスト駆動開発を基礎としたアジャイル開発は世界中で広く普及している。その一方で、アジャイル開発の個々のプラクティスはうまくできているのに、製品開発がうまくいかないといったケースも見受けられる。うまくいかないチームの様子を聞いてみると、基礎となる反復開発の実践に問題があるように感じた。私たちのチームは製造業でミッションクリティカルな領域のソフトウェアをエクストリームプログラミングで開発している。私たちの20年以上にわたるアジャイル開発の豊富な経験から、反復開発をうまくやる方法を伝えたい。本発表では、反復開発に適したプラクティス「忍者式テスト」を説明し、ストーリーを計画するテクニックや製品を磨く様子やチーム内のロールなど、忍者式テストを中心とした私たちのさまざまな活動について説明する。
スクラムフェス三河
SQiP2023の1週間後、スクラムフェス三河の栃木トラックKeynoteでSQiP2023の再演とパネルディスカッションをさせてもらった。書き物だけでなく動画も残すことができて嬉しかった*2。
忍者式テストのブレないコンセプトに感嘆している
2004年に発表された初出のスライドは2023年もそのまま使えることをこの記録のオチとしたい。日々の調整や改善は耐えず行われているが、コンセプトはなにひとつ変わっていない。アジャイルソフトウェア開発宣言が公開された2001年の数年後には、もうこのやり方に辿り着いていたのか…とあらためて驚いている。忍者式テストはXPをより深く考えれば自然と導かれるプラクティスである、と @m_seki は言うが、ふつうは思いつかないプラクティスである。
*1:一部の熱狂的なファンやマニアは除く。当の本人は発表中のツイート数の少なさを自慢するくらいなので気にしてないようだ
*2:@kawaguti さんのspeakerdeckに当日使用したスライドを置かせてもらった。ありがとうございました！
