CAT GETTING OUT OF A BAG

What the tester is thinking.

昨日の正解は今日の正解ではないかもしれない

ソフトウェアテストの小ネタ - Qiita Advent Calendar 2024 - Qiita 17日目の記事です。

 製品開発、特にテスト(checkingではなくtesting)*1で難しいのは、自分の中での正解を持つ一方で「自分は間違っているかもしれない」と疑わなくてはならないところです。これは、だから自分は間違っていない=正しい、を証明するために証拠を集めたり、製品や開発やテストに必要な、ありとあらゆる知識や技術を身につけましょう、という話ではなく、たとえ証拠を集めたとしても、たくさんの知識や技術を身につけたとしても、本当にそれが正解かはわからないぞ!という態度で臨まないと、テストなんてできないよね、という話です。

 みなさんお気づきのように、本当にそれが正解かはわからないのに、実際にテストするときには、なんらかの期待値や正解が必要になる、という矛盾があります。わたしはこの矛盾を受け入れるために、全力で導いた「なんらかの正解」を「これは今日の正解だぞ」と考えるようにしています。そして明日になったら「昨日の正解は今日の正解ではないかもしれない」と考え、あらたな気持ちで製品に向き合い、今日もまた全力でテストするのです。今日の正解って、昨日の正解の仮説と検証も受け継いでいるんですよね。わたしくらいになるとcheckingでも疑いますよ。Enjoy testing!

あわせて読みたい

arborosa.org

*1:多くの先達が『テストの定義』を語られています。わたしがこよなく愛するテストの定義は G.J. Myers[1979] の『テストとは、エラーをみつけるつもりでプログラムを実行する過程である。』です。この記事の「テスト」は「製品開発のすべての工程、期間において、まだ誰も気づいていない未知の問題をみつける行為、活動」をイメージして書きました。

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

JaSSTソフトウェアテストシンポジウム-JaSST'24 Tohoku に参加しました*1。この記事では、そこで行われたワークショップ『クラシフィケーションツリー技法』を体験して思ったことをメモしておきます。技法自体の紹介やワークショップの詳しい内容については触れないので、参加した方にしかわからない部分が多々あると思います。

また、当日配布されたアンケート用紙に感想を書かずに提出してしまったので(へとへとで頭がまわりませんでした)実行委員のみなさんやこのシンポジウムがうまくいくように尽力された方へのフォードバックと感謝もお伝えできればと思います。

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

クラシフィケーションツリー技法は言葉としては聞いたことがあるくらいで知りませんでした。書籍『ソフトウェアテスト技法ドリル』であれだけ勉強したのにどういうことだ?と思ったら第1版には書かれてなかったのでよかったのですが(そういうことではない)第2版 にはクラシフィケーションツリー技法が追加されています。*2

優しさにあふれていたワークショップ

ワークショップに参加する側の気持ちって、これからどんなことやるんだろう(やらせられるんだろう)と多少なりとも不安があるものです。JaSST東北のワークショップは導入フェーズがものすごく丁寧。どんな技法なのか、どのように使うのかをわかりやすく紹介してくれます。それを聞いていればチュートリアルが解けてしまうスタイルは、誰一人として置いていかない優しさにあふれていて、大好きです。

お題選定が秀逸 x ムーブメント爆誕

演習はシンプルでわかりやすいお題なのに、考え方や解き方にバリエーションがつけられるようになっていて(実行委員のみなさんの思惑通り?)あんなに短い時間でもちゃんと悩めたのがよかったです。自分の頭で考えないと身につかないんだよね。

今年は注目すべきムーブメントがありました。手を動かしながら問題を解いていくと「知っている → わかる」が体感できるので、うれしくなってしまうんですよね。それが表出して誰ともなく自然と拍手がわきあがってました。とても心地よかったです。

JaSST東北のワークショップは頭が疲れることでも有名ですが、ハマる人にはハマり、わたしのようなリピーターも一定数いますので、このよろこびの表明とみんながみんなを褒めたたえるムーブメントは、来年から定番になるかもしれませんね。

時間に制約がある中でどう対処していけばよいのか

時間に制約がある中でワークをやるので「もうすこし考えたいぞ」の気持ちが残るのは仕方のないことですが、他のグループの成果物を見せてもらいながらお話(どういう気持ちでこうしたのか、何を優先したのか、悩んだところはどこかなど)を聞いていたら「もうすこし考えたいぞ」が、うまく消化していく感じがしました。

時間に制約があるのは仕事でも同じなので、やりたいこと、やるべきことに、どう対処していくのか、どう折り合いをつけていくのかーーのようなテーマについても、なんらかの示唆を与えたのではないでしょうか。そういうテストのお悩み、わりと多かったよね。

シンポジウム全体としてまとまっていて流石です

話がそれてしまいましたが、成果物を見学するターンで各グループで説明する人を残したのは大正解だと思います。基調講演の「説明できるテスト」とも動的につながり、シンポジウム全体としてもきれいにまとまっていて流石だなあと思いました。井芹久美子さんによる基調講演『説明できるテストをつくるためにできることを考える』は、なにもかもが素晴らしすぎて雑に感想を書きたくないので今日は書きませんが、もしかしたらわたししか気がついてないかも!と思うのは「この講演自体が基調講演の内容を体現していた」ことです。この講演内容を参加者が理解できれば、行動してもらえる。そのレベルまでみんなを引き上げてくれるような内容になっていたと思いませんか?

自分の開発やテストに対する考え方の癖がダダ漏れ事案

最後のワーク、仕様変更(機能追加)の演習は個人的にめちゃくちゃ面白かったです。普段の製品開発ではほぼほぼこれしかないので、自分の開発やテストに対する考え方の癖(仕様書とコードは一致していないかもしれないし、仕様書だって間違っているかもしれないし、この仕様だって本当に良いものになっているのか?)があふれ出てしまい、同じグループのまこっちゃんさんとsaeさんの思考にバイアスをかけてしまったかもしれない…と、今になって反省しております。

正解は一つではない

ワークショップ全体をとおして何度も聞いた「正解は一つではない」という言葉も印象的でした。製品開発って単純な正解探しのようなものではないのでね、チーム全員の脳みそを使い、意見や知恵を出しあって、そのときの最善で最適な解を探し続ける旅のようなものかもしれないな、と帰りの新幹線の中でしみじみと考えてました。

次回は西暦2025年(仏暦2568年)5月30日(金)開催!

今回も大満足のワークショップでした。次回も参加したいです。講演者の井芹久美子さん、実行委員のみなさん、このシンポジウムがうまくいくように尽力されたすべての方々、それから参加者のみなさん、ありがとうございました!

あわせて読みたい

miwa719.hatenablog.com

 

*1:今年のJaSST東北は現地参加のみの開催でした

*2:第2版も持っているのに読んでないことがバレてしまった

書籍『ソフトウェアテスト293の鉄則』の素晴らしいところ

書籍『ソフトウェアテスト293の鉄則』を愛読しているソフトウェア開発者、特にテスターはたくさんいると思います。「まえがき」が本当に素晴らしいよね。

標準化されたドキュメントに現場での知恵が収められているとは考えないほうがよい。

本書は、ソフトウェアテストについての総合的なガイドブックではないし、解答集でもない。

本書は、ベストプラクティスを集めたものではない。著者たちは "ベストプラクティス" というものを信頼しない。

どんな場合においても等しくソフトウェアテストソフトウェア工学パラダイムが受け入れられるなどとは到底信じられない。

これこれ、これですよ。著者たちの何事にも疑いの目を持つその姿勢がテストを体現してるしテスターらしいなと思う。疑うだけじゃないよ。それであなたはどう考えるのか、あなたの状況に適用して実践し、評価してほしい。あなたの開発の現場ではもっと良い方法、手法があるはずだ(自分自身で探し求めよ)という強い思いが「まえがき」から伝わってくる。

で、この流れでいくとテスターなら当然「鉄則を疑ってみる」になるはずなんですが、読みすすめていくと「そうそう、そうなんだよね」「わかるー」「沁みいります…」となるから油断ならない。

あなたの推し鉄則は何番ですか?

 

「ちょうどいい」の見つけかた

お客さまへの製品リリースが頻繁には行えない状況でのMVP(Minimum Viable Product)は、どうしても機能を盛ってしまうことになりがちと感じています。そんななか、チームにJoinして2、3年の若者二人による、ある機能開発で何を作るか?の検討会がありました。「それを落としてきたかー」「そこをそう変えてきたかー」と思うような提案をしてきて、わたしたち(開発者)よりもお客さまに近い立ち位置の人も混ざっていたので、内心ハラハラしましたが、話し合いの結果「まずはそれでやってみよう」となり、へーー、ここまで削っていいのかーーーと、たいへん勉強になりました。

製品としての「ちょうどいい」を見つけたいとき「少なすぎるくらいの内容で提案する」というのは言葉としては知っていますが(冒頭にも書きましたが、製品リリースやアップデートが頻繁には行えない状況で)本当にそんな提案をするのは難しいです。

少なすぎるくらいの内容で検討をはじめ、話し合いの中で「これは絶対落とせない」となれば真のMVPなので追加すればよい。それはそうだと思います。一方でスレスレMVPかそうでないかくらいの微妙なライン上にいる仕様を「削っていいんじゃない?」とは言いづらい。あったら便利だし、お客さまにも喜んでもらえるのでは・・・なんて思ってしまう。あった方が良いものと、絶対にないと成立しないものを選択する過程と分かっていても、その取捨選択は難しいです。少なくともわたしには。

今回うまくいった要因を考えてみました。

  • 落とした仕様も議題にあげて、削った理由(自分たちなりの考え)を話した
  • 当初想定していたものから大幅に変更した仕様も同様
  • 検討会の前にエース級たちに相談して相当勉強して考え尽くしている(言葉の端々からわかる)
  • 二人が想定してない使い方を指摘されたときも、それがないと本当に製品として成り立たないのかどうかの視点を最後まで持ち続けた*1
  • 似たような既存機能でその仕様は搭載していないが、それはどう説明しますか?と良い問いかけができた(他の機能もよく知っていないとその場ですぐにこんな返しはできません)
  • 作りはじめてからやっぱりここはどうしてもだめだね(お客さまが困る)となったら、そのときはもちろん検討して対応します、と始めに宣言した

言葉にすると普通なんだけど、当たり前のことが当たり前にできてすごいなと思います。

そうそう、検討会自体の進め方のアドバイスプロの無職にもらっていて、それを素直にきいてやったのもうまくいった要因かもしれません。

  • 議事録を先に書く(普通は検討会のあとに議事録を書きますが、先に議事録を書いてしまうアイデアです。検討会は議事録を見ながらやります。こんなへんてこりんなやり方、よく思いつくよな…)*2
  • 時間切れになったらこの仕様でいきます!で始める(より重要なことから話そうとみんなが意識する。どうでもいい話は自然に抑制される。集中すべきことに集中できる)

検討会のあと、事務所に戻って若干興奮気味に具体的にどこが良かったか、素晴らしいと思ったか、二人からわたしが学んだことをそれぞれに伝えました。

わたしたちの製品はいったんリリースしてしまうと、あとから仕様を変更したり削除するのは簡単にはできません。入れてしまった仕様はこの先何十年も気にし続けながら開発/テストしなくてはならないのです。未来のコストも考えたら本当に素晴らしい提案だったと思います。

わたしが熱心に褒めるので気持ち悪くなってしまったのか「でもこれに集中してできるのも他の人たちの助けがあってのことで、チームでやってることなので」と恥ずかしそうに言うので「そういう風に思えるところも素晴らしいよ」って伝えました。

*1:晒してみて初めてわかること、自分に足りないことが学べる。指摘のあとすぐに「正直そういう使い方は想像できてなかったです。なるほどって思いました」と言えたのもよかった。普段から練習してないとなかなか言えないんじゃないかな。

*2:先に議事録を書いてしまうアイデアは元ネタがあるそうです。そのうちプロの無職がXかブログで言及してくれるかも?

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

先日の航空機事故を受けて書籍『失敗の科学』を読んでいます。第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:本書では順位は書いてない。文章から読み取った順位。