リリカルさんのHAYST法のまとめ

リリカル @mhlyc

どうせ夜中だしHAYST法に関する個人的私見をひたすらに書いていこうと思う。

リリカル @mhlyc

まずHAYST法っていうのはカッチリしてるように見えるじゃないですか？たしかにある意味カッチリしてますけど実は全部がカッチリしてるわけじゃないです。ある程度の"みなし"を使って大体必要なエリアを網羅してるっぽく見せてるんだと思うんですよね。

リリカル @mhlyc

ていうか網羅的にテストをーとか簡単にいうけど、そんなの100%網羅なんて不可能なわけ。お金が無限にあって全人類がテストしてくれるなら別だけど、無理じゃんそんなの。 だからテストの手法って大体何かのモデルを使って合意とか納得感をつくって「これでいいよね？」っていうわけ。と思ってます僕は

リリカル @mhlyc

まあなんだけどやっぱりHAYST法は僕は好きなんですね。なぜかというと理由はいくつかあるけど、ラルフチャートとかコンテキスト分析とか、手法の一部分だけ抜き出してもレビューやテストに対して十分な効果を発揮するところが好きです。

リリカル @mhlyc

ラルフチャートはノイズとアクティブノイズがとにかく良い仕事をする。 モデルって不思議で、空白があると「埋めないといけない」みたいな意識が働くんですよ。それで、最初空欄だったアクティブノイズやノイズの欄に色々な要素が上がったりする。

リリカル @mhlyc

入力のバリエーションや内部の書き込み読み取りの処理も、モデル使って考えてみると不足に気づいたりする。まあこのへんはラルフチャートの利点と言うよりはモデリングの利点ですけどね

リリカル @mhlyc

あとコンテキスト分析。これはすごい。これは＠mkoszk さんに聞いた話が元ネタなんだけど、これって要件とか仕様のレビューにめっちゃ使える。マジで。 「この機能をこのときにこのユーザーがここで使ったらどうなる？」って、コンテキスト分析をしてみるとわかるんですが案外抜けてることがある。

リリカル @mhlyc

あとはなんといっても目的機能。これは5年前くらいの秋山さんの資料見たときからすごいと思っていて、例えばワードで下線を引く機能は「下線を引くこと」が目的じゃないんだよね。目的は「文字を目立たせること」です。

リリカル @mhlyc

これを目的機能を考えないで検証するとどうなるか？「下線を引けたからオッケー」ってなるんですよ。下線がめっちゃ細い線で引かれて全然目立たなくても「下線を引けたからオッケー」。こういう検証してる人がいたら 「お前は本当にその製品をテストして、品質を保証するつもりがあるのか？」って思う

リリカル @mhlyc

なので目的機能はとても大事。 で、これに関連して、目的機能をユーザーストーリーとして捉えるという話につながるんだけど ユーザーストーリーって検証可能なものを作って、かつビジネスゴールに直結するものを作るわけなんです。 これが何を意味するかというと、

リリカル @mhlyc

ユーザーストーリーを網羅していくことで製品全体を保証していく、つまりアジャイルに近い考え方で品質の保証ができるんですよね。ユーザーストーリーマッピングの話が出てきたのはこの辺の話から繋がっているのかなと思っています。 私はアジャイル詳しくないので違ったらごめんなさい。

リリカル @mhlyc

という感じで素晴らしい手法のHAYST法なんだけど、ポイントがいくつかある。 僕の考えるポイントは ・未来スライダー ・whom ・コンテキスト分析〜ユーザーストーリーの展開 です。

リリカル @mhlyc

未来スライダーはとても汎用的に使える良い考え方。 使い方って言われるとたいていは使い始めとか、使いなれた頃のことは出てくるんだけど、買い替えどきって出てこない。プリンターでいえば使い始めて1,2年の話は出てきても、5年後どう使われるか？って意識的に考えようとしないと考えないんですよ。

リリカル @mhlyc

なので「ライフサイクル全てを通してユーザーを満足させる」というのはとてもカッコいいし魅力的な考え方だと思うのです。 3W出すときから検証内容を考えるところまで意識できると良いなぁと思います。

リリカル @mhlyc

次はwhom HAYST法的には「顧客の要求？そんなものは知らん」ってスタンスなんです。 6w2hのマインドマップ、whyの直下に何もかけないのなんでだと思います？「何も書かせたくないから」ですよ（1年前くらいの秋山さん談）

リリカル @mhlyc

whyって結局、「誰かが機能を増やせと言ったから」みたいな要求になるわけなんですけど それを全部満たしていけば本当に良い製品が作れるのか？無理じゃね？というところから生まれたのがwhomです。

リリカル @mhlyc

まずひとつ。お客さんは自分の要求を自分でわかっていない。 もうひとつ。要求はその場しのぎのことも多く長期的な目線から考えられていることが少ない。

リリカル @mhlyc

そこでwhom。ユーザーであるwhoの要求に応えるよりも、第三者であるwhomの利益を考えたほうがより本質的な、根本的な目的に近づけるのでは？という考えです。 秋山さんはこの件について目的工学が云々と言われていましたが、忘れました。

リリカル @mhlyc

例えば車なら、運転手（who）の要求に応えて握りやすいハンドルにするより、同乗者（whom）が満足するように揺れの小さい車に設計する、とか。まあこれは例えなので微妙かもですけど whomに目を向けた方が長期的なものが出やすいんじゃないかってのは私も思ってはいます

リリカル @mhlyc

だからこのwhomとユーザーストーリーの理由（得られる利益を書くところ）と紐づけられると、製品の価値提供を直接検証できるユーザーストーリーになってとても良いわけ。もちろん常に納得いくものが作れるようになるのは難しくて そこは苦労するところだと思います。

リリカル @mhlyc

最後にコンテキスト分析からのユーザーストーリーへの展開。 ここはコンテキスト分析でいかに良い感じの抽象度で出せるかがポイントで、基本的には「どんな環境で使われるか？」というのを考えて、その中から普通の要素一つと極端の要素二つを取り出すという進め方をとります。

リリカル @mhlyc

やりたいことはユーザーストーリーの検証なんです。なぜならそれが製品の価値と直結しているから（というか、そういう風に作るから）。 で、ユーザーストーリーもなるべくキワッキワのものを作って検証したいわけ。テストしたい要素が複数含まれたってそこは良いです。キワッキワな方がむしろ良い。

リリカル @mhlyc

そこで、「3Wでシチュエーション系は出してはいけない問題」にぶち当たる。これわかりやすいのは、「通学路」みたいにwhoやwhereの要素を含んでるものを出してしまった場合。

リリカル @mhlyc

まずwhereが通学路って時点で、whoが学生に限定されますよね？（限定されないにしても、発想が引っ張られることが多い） それでwhenが「勉強中」とかになると、もうそれ通学中に音源聴いて勉強してる学生のストーリーほぼ確定ですよね。（mp3プレイヤーの例なら）これだと広がりがない。

リリカル @mhlyc

なので、通学路だったら「歩道」とかにする。そうすると学生に限られないし、勉強中…はそのままでもいいかな。 そうすると「資格取得に向けて勉強中の主婦」みたいなストーリーにもできる。