CAT GETTING OUT OF A BAG

What the tester is thinking.

自然とそうなる仕組みづくり(テスト実施者の名前を記録しないとどうなるか)

先日の航空機事故を受けて書籍『失敗の科学』を読んでいます。第1章 失敗のマネジメント(「ミスの報告」を処罰しない)に、次のようなことが書かれていました。

学習の原動力になるのは事故だけではない。「小さなミス」も同様だ。パイロットはニアミスを起こすと報告書を提出するが、10日以内に提出すれば処罰されない決まりになっている。また現在航空機の多くには、設定した高度などを逸脱すると自動的にエラーレポートを送信するデータシステムが装備されている。データからは、操縦士が特定されない仕組みだ。

この「操縦士が特定されない仕組み」は、忍者式テスト*1の「テスト履歴」を思い起こさせました。履歴として記録するのはテストした日付と結果(OK、NG)のみ。誰がテストしたかは記録しません。といっても、NGの場合はその詳細が報告されるので誰がテストしたかは自ずとわかります。OKの場合はわかりません。この記事の最後に忍者式テストの履歴(例)を載せましたのでご覧ください。*2

咳チームにJoinする前は、テストを実施した人の名前を記録するのは普通というか当たり前でしたので「あとから誰がテストしたのかトレースできないの?」とびっくりしました。「省力化なのかな? 咳チームのチケットシステム*3はログイン操作もないし、いちいち名前をタイプするのは面倒だからやめたのかも」くらいの浅い認識だったと思います。

テスト実施者の名前を記録しない

たったこれだけのことが、テスト実施にたいする心理的負担をなくす効果とテスト本来の目的に意識を向けさせる力がある、と知るのは、咳チームにJoinしてから数か月後です。

テスト実施にたいする心理的負担がなくなる

咳チームはひとり毎日1時間、忍者式テスト専用のアルゴリズムによって抽出したチケットに書かれているテストケース「本日のおすすめテスト」を元にテストします。前述したように、テストした人の名前を記録しないので、誰がどのチケットのテストを確認したのかはわかりません。今日、Aさんは6チケット分テストしたかもしれないし、Bさんは1チケット分しかテストできなかったとしても、誰もそれを知ることはできません。

わたしたちのラボ(仕事場)にはテスト用のPCがずらりと並んでいて、テストの時間割にあわせてプログラマーがつぎつぎと現れます。だから「テストしているな」はわかります。でも、数を数えるような進捗管理はいっさいしないのです*4

わたしは数を数えるような進捗管理される• • •側だったことがあるのでわかるのですが、テストが思うように進まないと焦るんですよ。心理的なプレッシャーはテストにも影響します。テストに集中したいのに残りの時間が気になってしまい、本来その人が持つパフォーマンスが出せない、なんてことも少なくないのではないでしょうか。なお、数を数える進捗管理が悪いという話ではありませんので、お間違えのないよう。

テスト実施者の名前を記録しない、から浮かびあがるメッセージは「進捗はいっさい管理しません。1時間でできるテストを自分の思うようにやってください」であり、これはまた「テストをサボる人はいない(みんながみんなを信頼している)」という暗黙の了解も含まれていると感じます。

テスト本来の目的に意識が向くようになる

テスト実施にたいする心理的負担がなくなると、テスト本来の目的に意識が向くようになります。テスト実施者の名前を記録しない仕組みはここにつながるのか!と理解したときは、感動して心が震えてしまいました。

テストの目的は所属する組織やチームごとに、また同じチームでもテストレベルやテストタイプによって異なります。忍者式テストの目的は以下です。

私たちのテストは、ストーリーに書かれているテーマを起点として「本当によいシステムになっているのか」について、本物のシステムを使って確かめる過程である。操作手順のような基本シーケンスだけでなく、チケットに書 かれた開発日記(要求の背景、開発の経緯など)を読み直し、実際に今日のシステムで操作して、問題がないか、さらには、本当によいものになっているのかを実験する。単に不具合を見つけたいだけでなく、使いづらさや誤解をまねく仕様や手触りの良し悪しなども含めた理想との違いを知りたいのである。その理想さえも市場や環境の変化に応じて変わっていく可能性がある。

ストーリーに書いてあるテストを実施して分かるのは“テストケースに書かれている前提や操作においてうまく動くか、動かないかである。変更による意図しない副作用を検出するためのリグレッションテストとしての効果はある。しかし、私たちが手に入れたい問題を発見するには、このテストケースだけでは足りない。そのために、書かれているテストケースを出発点として、さらに新しいテストケースを考えながらテストしなくてはならない。

 

「テストからはじめよ」〜忍者式テスト20年の実践から〜 一部抜粋

わたしたちは未知の問題(まだ見つかっていない問題)を見つけて直すためにテストします。だからチケットには書かれていない未知のテストケースを自分の頭で創造しながらテストすることが求められます。進捗を管理しないということは「数をこなすことが目的ではないですよ」という強烈なメッセージを与えます。1時間でたくさんのテストをこなすよりも1つの未知の問題を見つけるほうが喜ばれる。自分にしかわからないような違和感を面白がってもらえる。メンバーひとりひとりがこれを体感するので、自然とそうなる(目的にそった行動をしてしまう)のは当然といえば当然ですね。

忍者式テストの履歴(あるストーリーの例)

 

*1:忍者式テストについては一つ前の記事をお読みください

*2:テスト実施記録(テストレポート)のフォーマットや扱いは、所属する組織やチームの開発プロセス、テスト対象の特性、テストレベル、テストタイプ等で異なります

*3:@m_seki によって20世紀に開発された世界一長生きなチケットシステム

*4:日付ごとにテストしたチケット数やOK、NGの数を数えることは可能ですが、その手の集計もしません

忍者式テストの秘密公開!驚きの20年の実績が明かされる!

2023年(仏暦2566年)は、わたしにしてはあり得ないほど活動的な年になった。特に忍者式テストに関する外部への露出が増えて「急にどうした?」と感じられた方もいるかもしれない。なぜこんなことになったのかを記録しておく。

なお、タイトルは「AIタイトルアシスト」(はてなブログの生成AIによる新機能)に作ってもらった。リンク先の論文やスライドを見てもらえれば忍者式テストの秘密がわかるし、驚きの20年の実績(テスト結果)も載ってるから嘘じゃない。自分では思いつかないよ。すごいねぇ。

忍者式テストについて書き物を残したい

なぜこんなことになったのかのアンサーは「忍者式テストについて書き物を残したい」これに尽きる。忍者式テストは @m_seki が率いるチーム(咳チーム)が続けているXP(エクストリームな反復開発)に有効なプラクティスである。わたしは忍者式テストの実践者であり、素晴らしい取り組みだと実感する観測者である。20年を超える実績があり、多くのソフトウェア開発者に知ってもらいたい活動だ。

忍者式テストの初出は2004年のJaSST(ソフトウェアテストシンポジウム)で、その後も技術系カンファレンスで何度か発表している。が、いつもほとんど反応がない。なんでこんなにウケないのかずっと気になっていた*1。きっとわたしが忍者式テストをはじめて聞いたときに感じた「わけのわからなさ」に多くの民がやられているのだろうと思った。わけのわからなさは狂気にも似ている。身の安全を保つために近寄らないほうがいい。だから生物学的に見なかったことにするのではないか。その一方で一風変わったネーミングから「忍者式テストってなんだろう?」と興味を持つ人がいてもよさそうだ。

ここで問題がある。 @m_seki の発表スライドは非常に難解なのだ。発表を聞いた人ならぎりぎりわかるかもしれないが、あとからなんだっけ?とスライドを見直してもたぶんわからない。こんな感じだから発表を聞いてない人にはほぼほぼ理解できない。初出のスライドを見てもらうとわからなさがわかると思う。だから「いつか忍者式テストを言語化したい。ソフトウェア開発者が読んでまあまあ理解できるものを書きたい」と思っていた。

ここで問題がある。毎日の製品開発(つまり忍者式テスト)が刺激的で面白くて非常にうまくできていて、あっという間に一日が終わってしまう。わたしたちの製品を世の中にリリースし続けることの価値もわかっているから、その時間を削ってまでも書く?と思ってしまうのだ。定時まで仕事するとくたくたになるので、残業して執筆することも考えてなかった。

2022年の終わり頃、来年書かないともう書けないかもと思った。@m_seki に話したら「じゃあ、どこで発表するか決めよう」となり、ソフトウェアシンポジウム(SS2023)での発表を目指して準備した。ちょうどこの頃、社内表彰(高度技術者表彰)をもらったことも執筆の後押しになった。伝えたいメッセージと具体的なネタを書き出した。模造紙1枚の巨大なマインドマップになった。社外発表になるので上層部の人たちに時間をとってもらい4回にわけて咳チームと忍者式テストとそのマインドを話した。

ソフトウェアシンポジウム(SS2023)

1999 年に出版された eXtreme Programming[1](以下 XP)に端を発したアジャイル開発は世界中で広く普及し, アジャイル開発の基礎となる反復開発,テスト駆動開発[2]も広く知られることとなった. 私たちのチームはX線CT装置をXPで開発している. 本稿では,私たちの20年の実践から,反復開発の利点と反復開発に有効なプラクティス「忍者式テスト」を説明する. 

マインドマップの中から内容を厳選して忍者式テスト入門編として発表した。これはこれで書き切った感はあるが、模造紙に書いたことの半分も書いていない。特にストーリーの分割について丁寧に書けなかったことが心残りだった。忍者式テストをうまくやるためにはシステムを変更する最小単位(ストーリー)の切り方と順番が重要である。ここは具体的な例を使って説明しないと伝わらないと思っていたので、ソフトウェア品質シンポジウム(SQiP2023)での発表を目指して準備することにした。

ソフトウェア品質シンポジウム(SQiP2023)

反復開発やテスト駆動開発を基礎としたアジャイル開発は世界中で広く普及している。その一方で、アジャイル開発の個々のプラクティスはうまくできているのに、製品開発がうまくいかないといったケースも見受けられる。うまくいかないチームの様子を聞いてみると、基礎となる反復開発の実践に問題があるように感じた。

私たちのチームは製造業でミッションクリティカルな領域のソフトウェアをエクストリームプログラミングで開発している。私たちの20年以上にわたるアジャイル開発の豊富な経験から、反復開発をうまくやる方法を伝えたい。本発表では、反復開発に適したプラクティス「忍者式テスト」を説明し、ストーリーを計画するテクニックや製品を磨く様子やチーム内のロールなど、忍者式テストを中心とした私たちのさまざまな活動について説明する。

スクラムフェス三河

SQiP2023の1週間後、スクラムフェス三河の栃木トラックKeynoteでSQiP2023の再演とパネルディスカッションをさせてもらった。書き物だけでなく動画も残すことができて嬉しかった*2

忍者式テストのブレないコンセプトに感嘆している

2004年に発表された初出のスライドは2023年もそのまま使えることをこの記録のオチとしたい。日々の調整や改善は耐えず行われているが、コンセプトはなにひとつ変わっていない。アジャイルソフトウェア開発宣言が公開された2001年の数年後には、もうこのやり方に辿り着いていたのか…とあらためて驚いている。忍者式テストはXPをより深く考えれば自然と導かれるプラクティスである、と @m_seki は言うが、ふつうは思いつかないプラクティスである。

*1:一部の熱狂的なファンやマニアは除く。当の本人は発表中のツイート数の少なさを自慢するくらいなので気にしてないようだ

*2:@kawaguti さんのspeakerdeckに当日使用したスライドを置かせてもらった。ありがとうございました!

狩野モデルの予習メモ

来月開催されるソフトウェア品質シンポジウム2023の基調講演『Kano Modelから品質について学ぶ!』が楽しみです。開催日まであと少しあるので「狩野モデル」を予習することにしました。この記事は自分用のメモです。予習の仕方は、1. 手持ちの技術書の索引から”狩野モデル”を探して読む。2. 気になることをメモする。不定期にゆるく更新します。

📕アジャイルな見積りと計画づくり 〜価値あるソフトウェアを育てる概念と技法〜

11章「望ましさ」による優先順位づけ、より

あるフィーチャ(a, b, c)を狩野モデルとカール・ウィーガーによる相対的重み付け手法で評価した例が載っている。狩野モデルでの評価は、a:線形(あればあるほど良い)、b:当たり前、c:魅力的となる。下に記載した開発の優先順位に従うと、a:2位、b:1位、c:3位となる。一方、相対的重み付け手法で評価すると、a:3位、b:2位、c:1位となる。

✍️それぞれ評価方法がちがうし、どちらが正解というものでもないが、優先順位が変わってしまうのが面白い

狩野モデル
  • 当たり前のフィーチャ:プロダクトが成功するために不可欠である。が、どれだけ幅広く用意しても、品質に磨きをかけても顧客満足度にはほとんど影響を与えない。ある程度満たされると満足度は上がらず、並より高くはできない。
  • 線形のフィーチャ:「あればあるほど良い」もので、線形/一元的という呼び名は、フィーチャの量に対して顧客満足度が線形に高まることに由来する。フィーチャがうまく動けば動くほど(多ければ多いほど)顧客はより満足する。プロダクト価格も線形に増減する傾向がある。
  • 魅力的なフィーチャ:大きな満足やわくわくする気持ちをもたらす。プロダクトの価格を割り増すことができる。部分的にでも実装すれば顧客満足度が大幅に上がる。が、それがないからといって顧客満足度が悪くなることもない。顧客やユーザーは実際に自分が体験してみるまでそれが必要だと気づかないため「隠れたニーズ」と呼ばれることがある。
  • 開発の優先順位*1。1. 当たり前:リリースまでに当たり前のフィーチャを揃える。2. 線形:できるだけ多く完成させる。3. 魅力的:時間の許す範囲で対応する(リリース計画には含めておく)。
  • アンケートした結果、E(魅力的)、L(線形)、M(必須)、I(無関心)、R(逆効果)、Q(懐疑的回答)別に集計する。高得点が2つになるのはユーザーによって期待の抱き方に差があることを示している。この場合は他の要素でユーザーを分類しながら分析する。たとえば、ロール別、企業の規模、業種別など。
  • フィーチャには時間の経過とともに評価が変わる性質(狩野モデルの図の中を上から下へとさがっていく性質)があることに注意。(例:ホテルのWi-Fi

✍️人類に早すぎる発明は時間の経過とともに無関心から魅力的に評価が変わるかもしれない。ストリーミングの時代にアナログレコードの生産枚数がV字回復したり、ちょっと不便さも感じるけど水筒(マイボトル)が見直されたりするので、落ちたら終わりでもなさそう

相対的重み付け手法
  • 投入コストに対してより大きな価値を生むフィーチャを探す手法
  • フィーチャを実装することで得られる利点、実装しないことで被る悪影響、開発するためのコストの3つをもとに、フィーチャの優先度をあらわす数値を算出する。

✍️普段の開発では狩野モデルも相対的重み付け手法も使ってないけど、何かを作ろうとしたとき(作ってる最中も)こんな会話をしてる

  • これがあると何が嬉しいの?
  • これがないと具体的にどう困るの?
  • 本当にAが欲しいの? BとCが入らないけどそれでもAが欲しい? 
  • 欲しいのは本当にこれなのかな。違かったりしてー
  • これが欲しいんじゃなくて(リリース済みの)◯◯が気に入らないってことなんじゃないの?

上記は特定の誰か(これが欲しいと持ってきた人)にたいする質問の場合もあるけど、自分としての回答を考えてることが多いかもしれない。たとえば「これがあると嬉しいとしたらなんだろう?」をいくつも考えてるな。無意識でやってたけど、たぶんなにか理由があるのだと思う。なんだろう?

📕魅力的品質と当り前品質(論文)

www.jstage.jst.go.jp

狩野モデルは「動機付け衛生理論」からの類推によって着想を得ている。動機付け衛生理論、知らないので調べる

動機付け衛生理論(二要因理論)

アメリカの臨床心理学者、フレデリック・ハーズバーグが提唱した職務満足および職務不満足を引き起こす要因に関する理論。人間の仕事における満足度は、ある特定の要因が満たされると満足度が上がり、不足すると満足度が下がるということではなくて、「満足」に関わる要因(動機付け要因)と「不満足」に関わる要因(衛生要因)は別のものであるとする考え方。
元々は、1959年にハーズバーグとピッツバーグ心理学研究所が行った調査における分析結果から導き出された。約200人のエンジニアと経理担当事務員に対して、「仕事上どんなことによって幸福と感じ、また満足に感じたか」「どんなことによって不幸や不満を感じたか」という質問を行ったところ、人の欲求には二つの種類があり、それぞれ人間の行動に異なった作用を及ぼすことがわかった。たとえば人間が仕事に不満を感じる時は、その人の関心は自分たちの作業環境に向いているのに対して、人間が仕事に満足を感じる時は、その人の関心は仕事そのものに向いている。ハーズバーグは前者を衛生要因、後者を動機付け要因と名づけた。前者が人間の環境に関するものであり、仕事の不満を予防する働きを持つ要因であるのに対して、後者はより高い業績へと人々を動機づける要因として作用している。

ハーズバーグの二要因理論 – リーダーシップインサイト より一部抜粋

表1 評価の二元表、より

  • 魅力的評価:あれば満足、なくても{仕方ない、何とも感じない、当然}
  • 一元的評価:あれば満足、ないと不満
  • 当り前評価:あれば{当然、何とも感じない、しかたない}、ないと不満
  • 無関心評価:あってもなくても満足も不満も感じない
  • 逆評価:あるのに不満、ないのに満足を感じる

✍️狩野モデルのあの図しか知らなかったので、二元表に「何とも感じない」と「しかたない」が入っていてちょっと感動してしまった

表2 集計結果と各品質要素の傾向、より

✍️品質要素の(12)置き場所、というのはどういう感じのアンケートなんだろう?

3.3 集計結果の検討、より

  • 評価の傾向が「魅力的」の場合、「無関心評価」「逆評価(ないほうがよい)」した回答者が他の品質要素に比べて多いという傾向がみられる。このタイプの品質要素は使用者の価値観の多様化が反映されやすい。

✍️逆評価:iOSアプリのTwitterタイムラインをスクロールすると画面下部のメニューが自動で隠れてしまうようになった。多くの人は魅力的と感じるのだろうか。慣れたら使いやすくなるのかと思っていたけど3週間たっても慣れない(気に入らない)から、このUI仕様はわたしにとっては逆評価。無料で使ってるけど逆評価。メニューが隠れるタイミングで画面上部の切り替えタブ{おすすめ、フォロー中}も隠れる。これにより画面みちみちにツイートが表示されるから、タイムラインを読むことだけに集中したい人には嬉しいのかな。それともできるだけ多くのプロモーションを表示したいのか?とか変なことを考えてしまう。無料で使ってるのに…

Twitterタイムラインのメニュー

✍️自身のプロダクトでも(わたしにとっては)逆評価のものがある

✍️もうひとつの逆評価「ないのに満足」は、普段あまり意識したことがなかったけど、実装して試してみたら使いづらくてやめた(なくした)ケースもあるので、小さな変更レベルで遭遇してそう

  • 回答者の属性によっても品質要素に対する評価の傾向が把握できる(図3)テレビの映り具合(年齢別)で年齢が低いときは、一元的評価が2割、当り前評価が8割だが、年齢が高くなると一元的評価が4割、当り前評価が5割、それ以外が1割となる。

✍️この結果は当事者(高齢者!)としてとてもよくわかる。きれいに映れば映るほど見やすいので嬉しい。一元的評価と当り前評価はこんがらがってしまうときがあるので、そんなときはこの例を思い出そう

 

あとで書く

 

*1:本書では順位は書いてない。文章から読み取った順位。

JaSST東北名物ワークショップを体験して思ったこと #jassttohoku

JaSSTソフトウェアテストシンポジウム-JaSST'23 Tohoku にオンサイト参加しました。今回のテーマは『アジャイル開発』です。この記事では、そこで行われたワークショップを体験して思ったことをメモしておきます。ワークショップの詳しい内容については触れないので、参加した方にしかわからない部分もあると思います。

ワークショップの内容(JaSSTのページから転載)

「そもそも、アジャイルってなに?」 そんな方々に、顧客に価値のあるソフトウェアを早く、継続的に提供するアジャイル開発の要件選定を、ユーザーストーリーマッピングという形で体験できるワークショップです。
オンサイトの方はカードを使ったグループワーク、オンラインの方はdiscordの音声チャンネルとmiroを使ったグループワークを予定しています。zoomによるワークのご視聴も可能です。

ワークショップを体験して思ったこと

ワークショップ(以下、ワーク)がはじまったのが16時40分でした。この時点で、川口恭伸さんによる基調講演やアジャイル開発の事例をいくつも聴講し、普段の開発業務では得られない刺激を受け、頭がすごく疲れていました。JaSST東北のワークは頭を使うことがわかっていたので「ここから2時間も無理…」と思っていたのですが、JaSST東北名物のワークと言われるだけあって無理じゃなかった。今回も面白かったです!*1

2回体験できたのがよかった

ユーザーストーリーマッピングは言葉を聞いたことがあるくらいの認識で、今回が初体験でした。だから2回やれたのは大変よかったです。1回目(お題:朝起きてから家をでるまで)で、基本的なやり方をつかめたので、2回目(本番)は開発の内容に集中できました。

このワークが教えてくれたもの

アジャイル開発(乗換案内システム)の要件選定というお題でユーザーストーリーマッピングを体験しました。1チーム4名です。

このワークをとおして起きたさまざまな出来事は、瞬間的に自分の記憶の中に取り込まれますが、短期記憶に入ったものは消えてしまいます。翌日にはさらにいくつか抜け落ち、1週間もたつと鮮明さも失われ、記憶から引き出すことがむずかしくなっていきます。抜け落ちたものが何かを自分で把握することもできないでしょう。でも、チームのみんなで付箋に書いて、貼って、並べて、移動した結果(そのときに撮った写真)を見ると、それが索引となり、自分の記憶を呼び起こすことができます。加えて、写真には記録されていない、チームの雰囲気、メンバーひとりひとりの表情、実際に話したことが音声とともに、ありありと思い出すことができます。それがまた脳を刺激して、忘れていた何かを引き出し、自身の記憶を更新できる。そんなことが身をもって体験できるワークだったと思います。

ユーザーストーリーマッピングは「見た目の派手さ」と「なんかやった感」が印象的ですが*2、このワークで作った付箋(写真)を毎日見直して再考し、記憶を構築し続ける参加者はいないと思うので「見える化しても見ないと意味がない」という事実と「見るということはどういうことだ?」が問われているとも思いました。

他のチームの付箋(成果物)を見学する時間があったのもよかったですね。同じ要件であってもチームの数だけやり方があり、その成果物だけを見ても、それに至った理由や試行錯誤の様子*3 は、同じ部屋にいても、部外者にはまったくわからないのだな、ということを、あらためて実感しました。

今回、同僚のm_sekiと一緒に参加しました。ワークも同じチームです。今後このワークについて話すときには、2台の記憶装置(m_sekiの記憶装置とわたしの記憶装置)を使って、お互いの記憶を交換することができます。すでに記憶が曖昧になっているところもありますし、自分では理解できなかったこと(たとえば、ユーザーストーリーマッピングと計画ゲームの違いなど)について、これから話し合ってみるつもりです。おそらく新しいノードの話(ワークでは話さなかったこと)も出てくるでしょう。チームのメンバーの人数分、記憶装置がある。チームで開発する、チームで補完し合うってこういうことだよね、と思いました。

*1:120分で最大の価値を体感してもらうために、お題の選定や設計も相当工夫されたのでしょうね。しかもハイブリッド対応!さすがだなぁと感心しました。実行委員のみなさま、ありがとうございました。

*2:個人的な感想です

*3:そこが一番面白いところ!

経験ベースのテスト技法:エラー推測(どうすれば、深い経験と高度な知識が身につくか)

ソフトウェアテスト講義ノオト: ASTERセミナー標準テキストを読み解く の 4.5 経験ベースのテスト技法 (1) エラー推測(P.191)に、このように書かれています。

 推測は、「テスト担当者の経験、欠陥や故障のデータ、ソフトウェアが不合格となる理由に関する一般的な知識」にもとづいて行います。逆にいえば、経験と知識が貧弱であれば良い推測はできません。エラー推測によるテストで良い結果を出すためには、深い経験と高度な知識が必要ということです。これは、他の「経験ベースのテスト技法」でも同様です。
 どうすれば、深い経験と高度な知識が身につくかというと、一件一件のバグを大切にするしかないと筆者は思います。具体的には、テストしてバグを見つけて直ってきたら、その原因について自分が納得するまで理解するの繰り返しです。

”どうすれば、深い経験と高度な知識が身につくか”の具体的な方法が「その原因について自分が納得するまで理解する」というのは、自分の感覚とも合っていて、普段やっていることと一致します。

中でも、わたしが注目しているのは、自分以外の人が見つけたバグで、かつ、自分では見つけられなかった(だろう)と思うバグです。このバグから「自分に足りないもの」が具体的にわかります。システム間のインターフェースやソフトウェアの設計や実装だけでなく、製品に関する知識(たとえば、ある特定分野の臨床医学)、どこにも明記されていない現場での実際の使われ方の理解、テストのうまいやり方や狙いどころ(たとえば、特殊なテスト画像をどこでどう使うか)、さらに、そのバグを見つけた人の製品開発にたいする姿勢(たとえば、医学文献を探して読んで自分なりの裏付けをとっている)などなど。さまざまなことに気付かされ、そこから学び、真似してみたいことが見つかります。

ここまでの文章を読んで「たしかにそうだな。自分もやってみようかな」と思った方がいるかもしれませんね。これを実際にやると、毎日「自分のわかってなさ」に向き合うことになります。人によっては辛い作業です。

わたしは、自分で見つけたバグについては、早いうちから「その原因について自分が納得するまで理解する」ことができていました。が、自分以外のテスターやプログラマーが見つけたバグについては、そこまで熱心に研究することができませんでした。いくつか理由はありますが、自分のわかってなさにいちいち向き合うのが苦痛でしたので、それが(すくなからず)自身の行動に影響していたと思います。

現在は「自分がなにもかもわかるなんてあり得ない」「わたしのくせに」と思っています。思っていますというか、実際そうなんです。当時の自分はなんて思い上がっていたのでしょうか。本当に恥ずかしいです。わたしたちは、誰でも簡単にわかるような製品なんて作ってないですし、だからこそ、多くの人たちが知恵を出し合って開発しているのです。よく考えてみればわかることでした。

追記(2023-05-06)

ソフトウェアテスト講義ノオト: ASTERセミナー標準テキストを読み解く の元はnoteの連載で、ソフトウェアテスト技術振興協会の「ASTERセミナー標準テキスト」を著者の秋山浩一さんが講義するとこんなことを話す、という内容を書籍化したものです。

本記事で話題にした経験ベースのテスト技法は、こちらから読むことができます。

note.com

書籍を購入しなくてもnoteで読めるのですが、ノオトの作成コンセプト に書いてあるように「ウェブサイト(note)を読むよりも、本で読んだほうがわかりやすく、学習しやすい」です。

noteにはいくつか罠があります。たとえば、埋め込まれているツイートをクリックしてしまうと、そちらの議論も面白くて、しばらくnoteに戻れなくなったりします。それはそれで良いのですが、タイムパフォーマンス(タイパ)を気にして学習したい場合は、書籍をおすすめします。

無意識なテストを完全に理解した

はじめに

2020年12月に 無意識なテスト - CAT GETTING OUT OF A BAG を投稿しました。無意識なテストというのは ”意識して触っているわけではないのにバグを出せてしまうテスト” のことです。わたしがそう呼んでいるだけで一般的なテスト用語ではありません。この記事を3行で説明すると、こんな感じです。

  1. 意識して触っているわけではないのにバグが出せます
  2. 無意識なテストはこんな特徴があります
  3. なぜこんなことができるのかはよくわからないけど、無意識(意識下)に強い影響を与えてそうな2つの習慣を紹介します

先日、認知科学*1の面からプログラミングを理解する本 プログラマー脳 ~優れたプログラマーになるための認知科学に基づくアプローチ を読みました。「なんとなくそうだろうな」と感じていたことが、わかりやすい例とともに科学的に解説されていて、ある種の爽快感がありました。

本記事は、認知科学の面から「無意識なテスト」を理解しようとしたものです。とくに10章『複雑な問題をより上手に解決するために』が役立ちました。

まずは 元の記事 を読んでいただいて、ここに戻ってくるのが、おすすめの読み方です。

本題に入る前に

本題に入る前に、脳内で生じる認知プロセスを簡単に説明します。(括弧内はコンピュータに例えたときのイメージです)

  • 短期記憶:読み聞きしたばかりの情報を一時的に保持する(RAM)
  • 長期記憶:長期間覚えておきたい情報を保持する(HDD)
  • ワーキングメモリ:短期記憶や長期記憶を使って情報を処理する場所(CPU)

それぞれの認知プロセスは互いに協調しあっています。たとえば、あるストーリーをテストしてバグを見つけるときはこんな感じです。

  • ユーザーストーリーやテストケースを目で見て読むことで脳に取り込まれます
  • 読んだ内容は短期記憶に読み込まれています
  • その間に、長期記憶から数日前に朝会で議論になっていたことや、過去に起きた問題などを思い出します
  • どのようなバグが起きそうかを考えるために、短期記憶の情報と長期記憶の情報(経験に基づく個人的な記憶や事実)が、ワーキングメモリに渡されます
  • ワーキングメモリが活性化し、新しいテストのアイデアが形成されます

何かを考えるときにはワーキングメモリに負荷がかかります。ここが大事なポイントです。

プログラマー脳 ~優れたプログラマーになるための認知科学に基づくアプローチ(図1.2 P.11)

無意識なテストを理解する

10章『複雑な問題をより上手に解決するために』に、プログラミングと問題解決のスキルを向上させるための2つの手法が書かれています。

  1. 自動化してより大きな問題や難しい問題に時間を割けるようにする
  2. 長期記憶を強化して、より簡単に問題を解決できるようにする

手法1の自動化ですが、自動化と聞いて、TDD、テスト自動化、最近話題のChatGPTでのコード自動生成を想像してしまいました。そうではなくて、ここでの自動化とは「自分の脳が小さな作業を考えずにできるようになること」です。人間は考えるときにワーキングメモリを使いますが、考えずにできるようになれば(=自動化できれば)その分のワーキングメモリが空き、時間的にも余裕が生まれ、より大きな問題や難しい問題を解くことにリソースを割り当てられるよね、というロジックです。

手法2は、問題を解くときは長期記憶の情報を使っています。だから問題をうまく解けるようになるには長期記憶を強くすればよい、というロジックです。

長期記憶を強くするってどういう感じだろう? と疑問が残りますが、読みすすめます。

長期記憶には手続き記憶と宣言的記憶が保存できる

長期記憶には異なるタイプの記憶(手続き記憶、宣言的記憶)が保存できます。

プログラマー脳 ~優れたプログラマーになるための認知科学に基づくアプローチ(図10.2 P.195)

 

手続き記憶(以下、潜在記憶)の例として、タッチタイピング、間違えたときのCtrl+Z、バグがありそうな行に自動的にブレークポイントを置くなどがあります。潜在記憶を十分に訓練しておくと、その記憶を呼び起こすことに、脳はほとんどエネルギーを必要としなくなります。たしかにこれらの操作はほとんど何も考えずにできますね。

手法1は、特定のスキル(本書ではプログラミング)をタッチタイピングと同様、何も考えずにできるようにしてしまおうというものです。無意識なテストっぽい!

無意識なテストはテストスキルの自動化:潜在記憶

いわゆる直感と呼ばれるものは、実際には、以前に解いたことのある問題と似たような問題を解いたときに起こるもので、なぜそれをすべきかはよくわからないまま、何をすればよいのかだけがわかるのです。(P.195)

無意識なテストの特徴として「気がついたらやっていた」「頭で考えるというより身体が勝手に動いている」を挙げています。引用した文章(P.195)を読んだときに(ああ、これだ)と思いました。無意識なテストは「テストスキルの自動化:潜在記憶」でした。

本書を読むまで、無意識なテストとスキルの自動化は結びついてませんでした。テストの自動化ってそっちかい!といった感じです。無意識なテストをしながら、別のことを考えたり、テーマの異なる問題に気づいたり、悪巧みのアイデアが降りてきたりするのも、無意識なテストで脳みそ(ワーキングメモリ)に余裕が生まれたからだ、と説明がつきます。

潜在記憶は繰り返し実践することで作られる

特定のスキルを何度も練習して、何も考えずにできるようになったら、そのスキルは自動化された(潜在記憶になった)と考えることができます。潜在記憶は考えることではなく繰り返し実践することで作られます。プログラミングに関するスキルを自動化したいならプログラミングを、テストに関するスキルを自動化したいならテストしなよってことですね。

1回反復するごとに、あなたはほんの少しずつ強くなっていくのです。(P.203)

本書ではプログラミングに関する潜在記憶を強化する具体的な方法が載っています。

元の記事では、テストスキルを自動化するための(と書いてもいいですよね)2つの習慣を紹介しました。毎日繰り返すことも入っているので、テストに関する潜在記憶を強化する方法としては、案外いい線をいっているのではないかと思います。わたしは無意識なテストを完全に理解しました。

長期記憶の強化

無意識なテストを完全に理解したので、これで終わりにしようかと思ったのですが、本書の10.4『コードとその説明から学ぶ』に、手法2の説明が書いてあったので、もうすこし続けます。

手法2は「長期記憶を強化して、より簡単に問題を解決できるようにする」というものでした。他の人がどのように問題を解決したかを知ることで、同じ問題や似たような問題に出会ったときにより簡単に解けるようになる、と書いてあります。本書はプログラマー向けなので、既存のコードについて学び、そのコードがどのように設計されたかについて、説明を受けるとよいとも書かれています。

ちょっと当たり前すぎて拍子抜けしました。これが「長期記憶の強化」につながるというのがいまいちピンときません。学んだことが長期記憶に保存されるのは普通のことのように思えるし、そのことと強化の関係がよくわからない。

でもね、ワーキングメモリの認知的負荷を使った説明を読んで「なるほど!」と思いました。

ワーキングメモリがいっぱいになるといろいろまずい

何かを考えるときにはワーキングメモリに負荷がかかります。ワーキングメモリがいっぱいになると、適切な思考ができなくなります。扱う問題が難しかったり、一度に多くの問題を相手にすると脳がパニックを起こします。これは自分でも何度も経験があります。

ワーキングメモリがいっぱいになると、脳はさらにもうひとつできないことが出てきてしまいます。それは情報を長期記憶に戻して保持すること。問題を解くことに負荷がかかりすぎると、記憶に残せなくなってしまうのです。大変な思いをして問題を解いたはいいが、その問題や解決策を記憶として残せないので、後から思い出せません。言われてみれば、心当たりがありますが、これは盲点でした。

プログラマー脳 ~優れたプログラマーになるための認知科学に基づくアプローチ(図10.6 P.205)

 

本書では、生徒たちを二つのグループにわけて、問題の解き方を詳しく説明したもの(範例)を渡したグループと渡してないグループで同じ問題を解かせる実験結果(範例を渡したグループのほうが問題を解く力がつく)が載っています。

これを読み、知っていることは出し惜しみしないで教えたほうがいいんだな、という思いを強くしました。同時に、前に若者と一緒にテストしたときに、わたしが出し惜しみせずに大量の情報を爆速で話しながら、開発中の製品を手荒く触っていたせいで、若者の長期記憶にはたぶん何も残らなかったであろう、ということにも気づいてしまいました。教えればいいってもんじゃない。

ワーキングメモリをいっぱいにしない工夫

他の人がどのように問題を解決したかを知ることは、同じ問題や似たような問題を解く際に、ワーキングメモリの認知的負荷をおさえる効果があり、知ったことや学んだことを、しっかりと長期記憶に保存(強化)できると理解しました。必要なことにリソース(ワーキングメモリ)を割り当てるテクニックとも言えます。

普段、脳のワーキングメモリの認知的負荷なんて意識してなかった(知識もなかった)ので、この考え方は非常に面白かったです。製品開発は簡単ではなく、複雑で難しいことのほうが多いです。だから本当に考えたいことに自分の脳を使いたい。ワーキングメモリを空けるために、どんな工夫ができるだろうと考えています。*2

おわりに

無意識なテスト認知科学の面から理解してみました。無意識なテストはテストスキルの自動化:潜在記憶ということがわかりました。無意識なテストは複雑な問題をより上手に解決するためのテクニックです。

無意識なテストを完全に理解した!

*1:認知科学(cognitive science):「情報処理」の観点から、記憶や思考などの人間の脳と心の動きを解き明かし、「認識・知能」の理解を目指す研究分野。

*2:本書の4章『複雑なコードの読み方』に、ワーキングメモリの認知的負荷を軽減するテクニックが載っています。

読書会のつくりかた #50QuickideasTests

5年前に入手して雰囲気で読んでいた Fifty Quick Ideas To Improve Your Tests (English Edition) の待望の日本語版『ソフトウェアテストをカイゼンする50のアイデア』が出版されました。

この日本語版を使って2022年11月からオンライン読書会を行っています。本記事ではこの読書会のつくりかた=設計について記載します。

読書会のつくりかた

はじめに考えること「読書会で何を得たいか」

オンライン読書会を主催するのは今回がはじめてですが、社内では何回か主催したことがあり、読書会の設計はそこでの経験をベースにしています。いつもはじめに考えるのは「読書会で何を得たいか」です。今回は自分が言い出しっぺなので考えるまでもないのですが、社内だと同僚や後輩から受ける相談から「◯◯の本を使って、読書会をしてみようか」となる場合もあります。読書会の初回には必ず「何を得たいか」をみんなで話します。*1

たとえば、話題の新刊をみんなで読もうぜ!となったときも「何を得たいか」を言葉にしておくと、読むことが目的にならず、得たいものを得ようとする読み方、時間の過ごし方になるのでおすすめです。何を得たいかを全員で一致させる必要はないですが、あの人の「こんなことを得たい」を知ってしまうと、それにつながるような何かを教えてあげたくなりますよね。*2

どういう読書会にしたいかを共有する

読書会の初回(0回目)に主催者3名で、どういう読書会にしたいかを話しました。こうしたい、こうなったらいいな!だけでなく、やりたくないことや、こうなったら困る、嫌だ、も話します。このイメージが共有できると、読書会の最中にそこから外れたり、迷走したりしても、誰かが気づいて本線に戻りやすくなります。事前に防ぐという強制力はあまり期待してません。諦めているわけではないけど、そうなってしまうときはそうなってしまうので、なるべくコストをかけないで戻れるようにしておくのがいいと思ってます。

読書会ではなく読書会を聴く会というスタイル

今回はおしゃべりがメインなので主催者3名で読書会をやることにしました。延長なしの1時間で音読もして全員にパスを回すには5名が限界かなと話していたのですが、毎回2名を募集するのはいろいろ面倒なのでやめました。読書会を公開するか非公開にするかは、わりと早いうちから公開する方向で話していました。ただ、自分たちは本の中身に集中したいから、それ以外のことに気を配る余裕はないよね。でも参加してくれた人たちを感じたいし、すこしは交流もしたいな、というわがままな願いを叶えてくれたのが「読書会を聴く会」というスタイルでした。インタラクティブさがほどよく低くて、今のところとてもよいです。

リスナーに読書会のイメージをどう伝えたか

オンライン読書会といえばそうなのですが「オンライン読書会」の言葉から想像するものは人によって異なります。この読書会のイメージに賛同してもらえる人に聴きにきてもらいたい。そのイメージをどう伝えればいいのだろうと悩みました。試しに一度だけ聴いてもらえればわかるのですが、そのためにわざわざ時間を調整してもらい、その結果「自分には合わないな」となったら申し訳ないし、がっかりされるのも嫌だったのです。

そこで、connpassで参加者(リスナー)を募集するときに「読書会をやろうと思ったきっかけ」を載せることにしました。ここに読書会のイメージも書きました。

読書会をやろうと思ったきっかけ(connpassに載せているものを転載)

日曜日の昼下がり、日々の開発風景を思い浮かべながら、手に入れたばかりの『ソフトウェアテストカイゼンする50のアイデア』を読んでいました。翌日の朝、#テストラジオ でパーソナリティのなそさん(@hiroyuki3gou)と、よしたけさん(@yoshitake_1201)がたまたま(偶然!)本書の感想を話していて「ああ、こういうのいいな!」と思いました。同じ本を読んだ開発者が何を思い、何を考えたのかを知ることは、自分が経験したことのない開発や、自分には無い考え方や捉え方や読み方に出会えるチャンスだからです。

数名で読書会が開催できればそれでよいので非公開でもよかったのですが、わたしと同じように「自分以外の開発者が何を思い、何を考えたのかを知りたい」と思う人にとっては多少なりとも価値があると思い、公開することにしました。チャット欄を用意しますので、自分はこう読んだよとか、思ったことや考えたこと、実際にやっていることなど、ぜひ書き込んでください。わたしが喜びます。聴き専(耳だけの参加)でもまったく問題ありません。

おしゃべりがメインなので、早く読み終えたい方や書いてあることを正しく理解したい方や正解を知りたい方には向きません。うすうす感づいてる方もいるかもしれませんが、何かを解決してすっきりするような感じにもならなそうです。楽しみ方や面白がり方は参加者のみなさんに委ねたいと思います。

2022年の新語として「タイパ(タイムパフォーマンスの略語)」が話題になりましたね。これを読めば、タイパ重視の人がうっかり参加してしまうことはないと思います。

読書会のすすめかた

本番の読書会のはじめからおわりまでイメージしながらひとつひとつ決めました。全体をとおして意識したのは「無理をしない」です。ずっと同じペースで物事を楽しむための原則です。

無理をしない

読書会の形式として『読書会という幸福 (岩波新書)』では、①おすすめの本を紹介し合う読書会、②朗読を採り入れた読書会、③輪読形式の読書会、④同じ本を読んできて話し合う読書会、の4つが紹介されています。①③④は予習が必要な読書会です。

今回の読書会は(無理をしないので)予習は無しにしました。宿題(読書会で話した内容をブログに書くなど)もありません。だから読書会の本番の1時間に集中できます。*3 

隔週開催にしたのもそうです。毎週やるとなると「ちょっとしんどいな…」と思うときもありそうですよね。1週間ってあっという間だから。読書対象をChapter 1(13アイデア)に絞ったのもそうです。本書はタイトルのとおり50のアイデア*4が掲載されてます。隔週開催となると1回1アイデアを読んでも2年はかかります。うわー、2年かー、2年やるのはちょっと自信ないな、となって、まずはChapter 1(13アイデア)だけやってみることにしました。まだはじまってないのに、どうやっておわりにするかをみんなで考えていました(笑)。

すすめかたの要点もconnpassに載せました。

すすめかた(connpassに載せているものを転載)
  • 書籍『ソフトウェアテストカイゼンする50のアイデア』は各自用意する
  • 本書、本文は画面共有しない(映さない)
  • 読書対象:まえがき、本書について、Chapter 1(13アイデア
  • 開催は木曜日 20:00-21:00(隔週)
  • 祝日はやらない
  • Discordのボイスチャンネル、テキストチャンネルを使用する
  • ボイスチャンネルはマイクミュートで参加してもらう
  • 数段落を音読→おしゃべり を繰り返す
  • 気になる書き込みは読んで紹介したい
  • まとめない(おしゃべりしたことがすべて)
  • 読み急がない(1回1アイデア読了を目指さない)
  • 読み進めることを目的にしない
  • 録画、録音はしない
  • ツイートやブログはOK
  • ハッシュタグ #50QuickideasTests

読書会中にBGMを流しているのも「無理をしない」に関係してます。本を読みながら自分の頭で考える読書会なので、全員で「うーん」と考えていると沈黙の時間を配信してしまいます。このときに無理をして話そうとしなくてもいいように、余計なプレッシャーを自分たちが感じなくて済むように、お手製のBGM*5を流しています。

また、connpassの参加募集のタイトルに連番(第n回)をいれるかいれないか、のような細かいことも話し合いました。連番をいれると何がお得か?タイトルで何を知りたいのか?連番でなくむしろ日付をいれたほうがいいのか?みたいな話を真面目にやりました。連番をいれると新しいリスナーの参入をさまたげるのではないか?とかね。最終的には連番にはあまり意味はなく、毎回カウントアップするのは手間だし、きっといつか間違えるよね、となって連番なしになりました。

アンチハラスメントポリシー

CC-BY-4.0で公開されている「TokyoGirls.rb アンチハラスメントポリシー」を元にこの読書会のアンチハラスメントポリシーを作成してconnpassに載せています。何もないところから作るのは大変なので助かりました。ありがとうございます。

設計を見直してより良くしていく

読書会を数回行った状態でこの記事を書いているのですが、イメージしていた読書会ができていると感じます。参加者のみなさんがそうなるように行動してくれているからだと思います。ありがとうございます。

読書会を開催するにあたり、ここに書いてないことも含めて設計してきましたが、あることをしたおかげで、設計の見直しが無理なくできるようになりました。それは connpassに「読書会をやろうと思ったきっかけ」と「すすめかた」を載せたことです。もともとは参加するかしないかを判断してもらうために載せたのですが、新しい参加募集をconnpassで作って内容を確認するときに、自然にそれが目に入るので隔週で読み直しています。設計を見直すためにわざわざアクセスしに行くのではなく、やることに組み込まれているから、とても楽だし気分がいいです。

さっそく見直しました

前回(2023年1月26日)の読書会で「ここだけの話」をしました。感想ブログをUpしてくださった方がいい感じに書いてくれて何も問題はないのですが「ここだけの話」の判断を聞き手に押し付けているなと感じました。"ここだけの話ですけどー" という前置きを聞き逃す可能性だってあります。読書会で話したことをツイートしたりブログに書くことはOKにしているので、今後は外に出せない話はしないようにします。書きたいなと思ったときに安心して書いてもらえるように。

このようにちょくちょく見直しながら、全員が気持ちのよい時間を過ごせるよう、より良くしていきたいと思います。

*1:訓練されているブログ読者は「うまくいったらどうなるの」を想起しましたね。正解です。

*2:今回わたしはこれを発動しています。

*3:今回の読書会は②に近いのかなと思いきや、本文の説明を読むとぜんぜん違います。世の中にはいろんな読書会があるのだなぁ。

*4:日本語版には訳者の山口鉄平さんによる特別寄稿の4アイデアも収録されています。

*5:あとで書く