00:00
今日はですね、プロダクトの検証の話を聞いてみたいんですけど、 検証といっても、出来上がったプロダクトの品質の検証と、
あとプロダクトを作る前の事前の需要などの検証の大きく分けて、2つに分かれるのかなと思ってるんですけど、 これって理解として合ってますかね?
はい、そうですね。よく前者のことを正当性検証と言って、後者は妥当性検証とよく言うことがありますね。
じゃあ今回は正当性検証と妥当性検証について話を聞いていきたいんですけど、 正当性検証ってどういうものですか?
正当性検証は大雑把に言うと、使用と実装の間の検証です。
使用と実装の間の検証。
つまり、私たちは、ちょっと順をよって話すと、 私たちは何かのソフトウェアを使って現実の問題を解決したいわけですよね。
例えば、誰かとお話をしたいという人たちを繋いであげるのがSNSだし、 こういうふうに何か解決したいものっていうのがあって、
これが一般的には要求とか呼ばれている領域のもの、問題領域とか、 そこから出したものの要求とかって言ったりするんですけど、
っていうものがあって、これは時点ではまだ使用になってないんですよね。
だけど、SNSみたいなものにもいろんな種類があるじゃないですか。
例えばXもあるし、あるいはミクシーもあるし、 あるいはアメ風呂みたいなのもあるし、いろんなSNSがありますよね。
どういうふうな階を選んでこの問題を解決するのかっていう、 その階、つまりどういうふうに私たちはこの問題を解くのかっていうのが仕様にあたるものです。
解きたい課題をどうやって手段として解決するのかっていうことですよね。
どう振る舞うシステムを開発して解決するのか、それが仕様にあたるもので、 この仕様と実際振る舞う実装があるわけですよね。
この間が正当性検証と呼ばれているもので、 要するにプロダクトの品質と呼ばれているものが大体ここに帰着することです。
仕様を定義されていて、それが実装に落とし込んでいて、 100%仕様通り実装できていれば正当性検証は100%できているということなんですね。
これを考えてみると、じゃあ我々テストとかやるじゃないですか。
よく単体テストとかやったり、結合テストとかやったりとか、 あるいはエンドツインテストとかしたりしますよね。
あるいはテスターさんにテストをお願いする。 これは全部正当性検証なんですよ。
でもそれだけだとどういう落とし穴があるかってことを考えてみると、 妥当性検証の必要性がよくあります。
なるほど、そこで必要になってきたんですよ。
例えば問題を解く、SNSを作るっていうのは回のうちの一つですけど、
寂しいっていう人がいて、お話したいなっていう人に対して、 例えばポテトチップスを揚げるシステムを作りましたっていう仕様を考えてくると、
何も問題解決していないじゃないか。 多分システムはできるんですよ。正当性検証も通るんですよ。
ポテトチップス揚げるシステムはできる。
だけど、その仕様はできてるし、それを実装もできてるから、 正当性検証は100%オールオッケー。
ポテトチップスできるものを確かに作れましたってなる。
それはそうですよね。
だけどそれは私たちの解きたかった問題じゃなかったんですよね。
お腹空いてる人向けのソリューションだけですよ、それは。
03:01
違いますよねっていうような。
なんか今の話聞いたらあれなんですけど、 正当性検証は仕様と実装の間の検証、
そこがマッチしてるかどうかの検証ですけど、 妥当性検証の方は需要というか解きたい課題と
仕様をマッチしているかどうかの検証みたいな。
一つはそうです。
仕様がまず、この仕様正しい仕様なのかってことを決めてくれるのが 妥当性検証になっていて、
確かにこの仕様は問題を解決する、 その程度がなかなか大きいとかっていうのが
良い仕様の条件なので、こういうふうな評価をできるようにするのが 妥当性検証です。
ただ妥当性検証は実は仕様と要求の間だけであるものじゃなくて、
実は実装と要求の間にも起こるんですね。
なるほど、じゃあレイヤーをまたぐんですね。
レイヤーをまたぐんです。
なぜかというと、よく機能要求と呼ばれている要求があると思います。
例えば性能要件とか、そういうものがあるんです。
何秒以内にレスポンス返してほしいんだけど、
例えばこのAPIは100msでレスポンスを返してほしいとします。
仕様で100msより遅かった時はNGでとしますっていう仕様を決めることはできるんですけど、
大抵それにはあまり意味がなくて、
101msじゃダメなんですかって言ったら多分大丈夫ですね。
っていう話とかがあるので、こういうのって白黒つかないんですよ。
白黒つかないのとかってよく妥当性検証の中に入っていて、
大雑把にさっき言った問題をどれくらいよく解けてるかも白黒つかないですよね。
そうですね、100%カバーできるものでもなさそうだなっていう気がしますし。
なんとなくこれは良さげ、あれよりは良さげとかっていうのが言える。
こういうのは結構妥当性検証がほとんどで、
実装がなぜそうなのかっていうと、さっき言った性能だったりだとか、
そういうものとかっていうのが要求との相手じゃないとわからないかな、ですね。
いわゆるUXって呼ばれてるところなんですかね。
UXの使用性とかが言われてるとほとんど機能要求です。
なるほど、そこの検証とかが該当するのは妥当性検証と呼ばれてる。
そういうことですね、機能要求と実装の間で妥当性検証をしているということですね。
やはりあれですかね、QAする時にも、これは正当性検証のチェックリスト、
妥当性検証のチェックリストみたいな形で、
リスト分けしておいた方がちょっとわかりやすくはなりそうなんですかね。
そうです、もちろんその通りで、リスト分けしてさらに実は細分化することができて、
例えば正当性検証っていうのは振る舞いの検証がメインになるんですけど、
振る舞いって大雑把に分けると2つあって、1つはいつか良いことが起こるっていうタイプ。
例えば踏切があるじゃないですか、踏切。
踏切が電車が通った後にウィーンって踏切のゲートが開いてくれないと困るわけですよ。
困りますね、渡れないので困りますね。
そう、いつか良いことが起こるっていうタイプのもの、これは活性って呼ばれるタイプのものなんですけど、
いつか良いことが起こるっていうものと、いつでも悪いことが起きない。
06:00
例えば電車が通ってる間にゲートが開いてるってことが起きてはいけない。
っていう風に安全性、この2つで正当性を記述することができて、
なので正当性もさらに細分化すると、安全性と活性って2つがあってチェックリストが分かれるということになりますね。
今の話聞くとフールプルーフとかそういうところも若干入ってたりするのかなと思ったんですけど、
ちょっと考え方としては違うところなんですかね。
フールプルーフ、なるほど。
絶対に間違わないような形になってるだったりとか。
それはどちらかというと引きの要求、ユーザビリティの方ですね。
なるほど、そっちになるんですね。
間違う人、どんなにシステムを上手く作ったとしても間違う人ってやっぱりいて、
そういう人たちってやっぱり白黒つかないんですよ。
この仕様だと100%合格とは言えないって感じになる。
やっぱり結構引きの要求に入ってくるんですよね、こういうのって。
なるほど、そっちは妥当性検証の方の対象になっていくんで。
なるほど、そういったところで区別しつつ検証していく方が良さそうなんだけども、
実際具体的に正当性検証をするとか妥当性検証をしたいってなった時に、
どうやっていくのかっていうのがあまり見えない。
正当性検証の方はなんとなくテストとかQAとかをしっかりやる。
仕様に沿ってちゃんとやっていくっていうのがなんとなく見えるんですけど、
とにかく妥当性検証の方がよく分かりづらいなっていうのがあるんですかね。
妥当性検証は結構難しいっていうか、みんな無理矢理やってるところはあると思っていて、
例えば問題はどれくらいうまく解けましたかって言われて、
え?ってなっちゃうんじゃないですか。
例えば大雑把に言うと5段階とかで分けて、これはよく解けてないとか、
そんな感じでしちゃう、無理矢理始めるみたいなのが妥当性検証でありますね。
なるほど、そのUXの調査みたいなインタビューみたいな形で、
このシステムはすごい使い勝手が良かったですみたいなアンケートを取った結果が妥当性検証として使われる。
もちろんそういうふうなユーザーインタビューもそうですし、
何ならペーパープロトンのタイミングでも本当はそれができるんですよ。
なのでそういうことを妥当性検証、結構早めの妥当性検証としてやっておくと、
仕様自体がまず良くなるっていうのがあって、
その後に仕様が良くなれば実装ももちろん良くなるんで、
っていうふうな形で目指していく形になりますね。
他にもいっぱいあって、
例えば設定された問題が確かに本当に問題なのかっていうことを疑いにかかるとかっていうのもありますね。
例えば寂しい人が繋がりたいっていう人がいる、本当にいるの?っていうとこですね。
疑っていくってことですね、その課題に対して。
そうじゃないと、結局作っても誰も使われなかったってことが起きちゃうわけですよ。
それはもちろん事業者にとっては何も嬉しくないし、
OSSとか開発してる人にとっても何も嬉しくないですよね。
だからちゃんと確かにそこに解決すべき問題があるのかっていうことも、
妥当性検証もすごく重要な側面で、
09:01
ただこれはなかなか定量評価しづらいっていうのがあって。
ですよね。
若干エンジニアリングの領域、若干とは言わずも、
かなり外れてるなと思っているような領域なんですね、妥当性検証に関しては。
リサーチ寄りですね、本当に。
マーケティングリサーチとかそういうところとかにも関わってくるものです。
市場調査しつつ、ユーザーインタビューもしつつ、総合力で検証していくみたいな。
でも実は製品で一番大事なのって妥当性なんですよ。
これはすごく忘れられてる観点で。
だって妥当性がなければ売れないじゃないですか。
問題は確かに解けないしってなっちゃうんで、
一番実は大事なのが妥当性なんですね。
だからといって妥当性検証だけをしようっていう風にすると何が起こるかっていうと、
みんながみんなそれぞれ違うことを考えて、
違う派手な製品ができるっていうのがよくある。
そうなんですか。
なぜかっていうと仕様がはっきりしなくなっちゃうからなんですね。
正当性検証を下ろすとかにすると、
自分たちはこういうのを作るんだっていうイメージ、ビジョンが共有されなくなっちゃう。
正当性検証の方をしないと。
私たちはSNSを作るぞってなったら何人かに分業して作るわけじゃないですか。
その時に共通のイメージを持っておく必要があるんですね。
しようっていう形で共通のイメージを固定して、
それをみんなで作るんだっていう風にしていくわけなので、
みんなで分業するときにその仕様って結局必要になってるんですよ。
最終的な仕様ですよね。
最初に作る仕様。
だから正当性検証を下ろすとかにすると空虚な仕様ができて、
みんなが好き勝手にそれを解釈して、
最終的に組み合わせたらキメラみたいな感じのすごいことができちゃった。
っていうことが起きちゃう。
だから正当性検証もちょっぴり大事なんだけど、
でも本当に一番大事なのは、
いくらキメラとやろうと妥当性があるものっていうのは、
それだけで素晴らしい製品なんですよ。
っていうのがあって、
実は妥当性の方が大事っていう流れが今来ていると思っています。
なるほど。
この妥当性検証、正当性検証の方は割り返しエンジニアリングチックなので、
パチッとやれればいいのかなとは。
エンジニアリングの延長・専長でできるのかなという感じなんですけど、
妥当性検証を実際に国明さんがやるとしたら、
もしくは今やっているとしたらどういったことを。
実は妥当性検証をめちゃくちゃ重視する流派があるんですよ。
流派がある。
流派がある。
これはアジャイルって呼ばれている流派が、
妥当性検証をめちゃくちゃ大事にしている。
めちゃくちゃ聞いたことあるんですね。
めちゃくちゃ聞いたことあると思うんですよ。
アジャイルの人たちってよく、
プロダクトオーナーの人たちに、
レビューしてもらいますよね、製品を。
アジャイルで、
スクラムで開発していって、
スクラムの頻度ですかね、
例えば2週間に1回とか1週間に1回に
プロダクトオーナーの人に
収入できた成果物をレビューしてもらって。
レビューしてもらって。
プロダクトオーナーは顧客の代弁者みたいな立場として振る舞うことですよ。
12:01
そこで妥当性を確保しようとするわけです。
2週間に1回妥当性の検査が入るようにしている。
強制的に。
そうですね、確かに。
アジャイルのもう一つ重要な点っていうのは、
何をしたら私たちは問題を解決できるのかってことって、
どうせ分からないだろうっていう立場に立脚してるんですよ。
なるほど、100%理解なんてできないでしょっていうような
根底からアジャイルに回していく、
小さいサイクルで回していく。
小さいサイクルで、
学習しながら探索する場所を決めるってことをやっていく。
よくアジャイルだと、
自動車をいきなり作ろうとはしなくて、
キックボードから始めて、
その次に自転車になってとかっていうのが
よく流れが踏むじゃないですか。
これは妥当性を追っていってるんですよ。
妥当性が、だんだん妥当性がいい方向にいくように
を狙って、
そういうイテレティブな開発をしているわけですね。
ちょっとずつちょっとずつ進んでいくってことですよね。
方向性をちょっとずつ変えながらも。
そしてアジャイルは、
ドキュメントをそこまで大事にしたいっていうのもありますよね。
それよりかは、顧客との対話とかを大事にするっていう思想があるわけです。
それはまさに妥当性を優先するよって言ってるんですよ。
正当性、つまり仕様とかをみんなで作って、
それを確かに計画通りに作っていくっていうことより、
妥当性を大事にしていくんだよっていうメッセージが
あそこに込められていると思っています。
なるほど。
かっちり決めすぎないよというようなイメージ。
どうせわかんないでどうすればいいぞ。
あれなんですかね、
ウォーターフォールとの対比でもあるっていう形ですかね。
そうですね。
アジャイルに関しては、
仕様をがっちり決めて全部一連の開発テストまで
全てこなすというウォーターフォール。
仕様をがっちり決めた後の開発、
全てやるみたいなのに比較して、
アジャイルの場合は本当に小さく回していく。
仕様をあまり決めすぎないっていうようなところを
重要視しているっていうところがある。
そうですね。
仕様を決めるスタイルを取ることはできるんですけど、
どちらかというと仕様はかなり柔軟に変わっていくものになりますね。
変わる前提ということですね。
変わる前提です。
妥当性が命なんで、
仕様なんて妥当性のためにいくらでも変えてやるよっていう
主義なんですね。
なるほど。
アジャイルっていう話が出てきて、
確かになと思ったのが、
正当性検証と妥当性検証、
もちろんどっちも重要じゃないですか。
さっきスクラムの中にPOに2週間に1回とかの単位で
妥当性検証してもらうみたいないう文脈でいると、
スクラムってスクラムマスターがいるじゃないですか。
また別で。
そっちは正当性検証のことを担っているのかなっていう感じなんですかね。
スクラムマスターの。
私がいろんな現場を見てきた限り、
正当性検証の担い手はほとんど普通のソフトウェアエンジニアの人たち。
なるほど。
プレイヤーの方たち。
これはなんでかっていうと、
よくエクストリームプログラミングって今は当たり前になってきていて、
15:02
自分たちが単体テストを書いて、
それが定期的にCIっていう仕組みによって検証されてっていうことがあると思うんですけど、
ここと結構関連があって、
普通に私たちがよく書く単体テストってのは全部正当性検証なんですよ。
その仕様をテストで書いて、
こんな感じに動くべきだ、振る舞うべきだってことを表明して、
それがちゃんと振る舞っているかってことをテストするわけですよね。
まさにその仕様のテストで正当性のテストなわけですけど、
これはじゃあ誰がやってるんですかって言ったら、
エンジニア自身がやってますよね。
確かにそうですね。
だから担い手はソフトウェアエンジニアなんです。
なるほど。
じゃあスクラムマスターは正当性検証と妥当性検証をいい感じに回す人ですね。
そうですね。
どちらかというと私のイメージだと、
スクラムマスターってチームのベロシティを上げていくって言ったらいいのかな。
先ほど言ったとおり、アジャイルってチームの学習をすごく大事にするわけですよ。
分からないこともいっぱいあるから、
学習していって積み上げていって、それを乗り越えてやろうっていうことなわけですよね。
その学習とかを促してあげる存在だと思っています。
学習したことって、学習しただけじゃ意味がなくて、
学習したことを反映して何らかやり方を変えたりとか、
いろんなことを促していかなきゃいけないんですよね。
これをメンバーに任せると、
メンバーは普段の開発作業とかに暴殺されちゃうんで、
誰かがちょっと待て待て待て、一旦こっちに目を向けて、
今こんなことは今週ありましたねと。
これって私たちはこういうことを学んだんじゃないですか。
だから次こう変えていこうねとかっていうふうに、
一旦みんなを少し立ち止まらせる役割が必要だと思っていて、
私はスクラムマスターがその役割になっていると思っています。
なるほど、交通整理じゃないですけど、
やはりそのサイクル、アジャイルという高速なサイクルで学習していくという目的に対して、
最適にチームが動けるようにすればスクラムマスター、マネージャーみたいなイメージですね。
よく言うのはスクラムマスターが何か問題を提起しすぎちゃいけないんですよ。
そうすると問題の発見能力を失わせちゃうんですね、チームから。
チームのメンバーが?
そう、チームのメンバーが。
なるほど、そこがちょっと難しいところ。
そう、よくグッと耐えて言わないとかっていうことがよくスクラムマスターでよくあるあるだと思ってるんですけど、
言っちゃダメなんですよね。
なるほど。
そこら辺で妥当性検証と正当性検証をいい感じに回して学習していきつつ、
妥当性検証の精度をどんどん上げていくということですね。
ただ、妥当性検証の精度を上げていく責任はどちらかというとプロダクトオーナーにあると思ってます。
顧客の代弁者じゃなきゃいけないですからね。
なるほど。
ちなみにその妥当性検証の担い手というか、一番のオーナーシップを持っているのはPOと。
POだと思いますね。
ところなんですけど、POがやってることってどういうことなんですかね?
POは顧客理解にすごく努めなきゃいけない人で、
18:00
実際に製品を使ってみたり、使ってる人たちのところに行って、
こんな風に使われてるんだっていう風に理解したりとかして、
何をこれからプロダクトをどういう方向に進ませていくかっていうビジョンを描ける人じゃないといけないんですね。
そのためには本当にとにかくよく顧客を理解して、製品を理解して、
それがどう使われてるかをよく理解してっていう人じゃないといけないんですよね。
なのでプロダクトオーナーは本当に妥当性検証をする採点マシンであると同時に、
より良い採点をするために顧客理解に努めるっていう傍観者であるってことですね。
自分自身の知識もアップデートしないといけないし、
採点するためにそもそも製品の理解もできていないといけないし、
あとは一部分技術の理解ももしかしたらできていないといけないし、
っていうすごい難しい。
難しいですね。
いないというか。
ただここもノーターをつけることができて、技術まで知ってるってなるとプロダクトオーナーになれる人がすごく減っちゃうんで、
技術は知らなくていいと。
エンジニアがこういう風に実装できるっていうプランは提案できると。
解決したい問題を出すところまでがプロダクトオーナーだって割り切ってあげると、
ちょっとだけハードルを下げることができますね。
ちょっとやりやすくなるそうですよね。
ちゃんと役割分担しているところで。
なんかここら辺で最近今の話で言うと、
アジャイルでチームメンバーが複数いて、エンジニアの方も複数いて、
それでPOが1人いて、アジャイルで開発度の高速に回していくみたいな話だったんですけど、
今後というか今AIがいるわけじゃないですか。
ここら辺の検証ってどう変わってたりします?
検証はだいぶ変わってきてると思っていて、
今AIが正当性検証の担い手にかなりなっていると思ってます。
そこがAIによって変わっていくってことですね。
一応どおり作ってねって言ったら、はいって作ってテストまで用意してくれるじゃないですか。
正当性検証の担い手になっているわけですよね。
じゃあ妥当性検証は誰がやるのかって言ったら、今人間がやってるわけですよ。
ただすごく賢いモデル、フェイブルとか賢いモデルは、
妥当性検証できちゃうんですよね。
ユーザビリティ悪いとこ見つけてって言うと、うっすって。
ここダメっすって言ってくれるみたいなのがあって。
実は私もユーザビリティレビューとかをフェイブルにさせてみたら結構いいこと指摘されたりしてたんで、
そういうのできてきてるんですよね。
ただ最終的にどういう問題を解決するかっていう問題設定はまだAIにはできてない。
そこは人間が担う。
妥当性検証の一番大きなループはまだ人間が担っていると思っていて、
だいぶAIがそこに近づいてきてるっていうのが私の認識ですね。
作業としてはAIがやってくれるけど、
結果的にその大冗談の部分、意思決定だったりとか、
どれを選択してやっていくのか、どういう方向性に進んでいくのかは、
もちろん人間がハンドリングしていくようなところですよね。
さっき国明さんが言ってたフェイブルとかに妥当性検証、
ちょっとユーザビリティのチェックしてもらって、
21:00
結構いいこと言ってくれるなみたいな言うのも、
結構いいこと言ってくれるなっていう判定が国明さんだったらできてた。
できてる話だと思うんですけど、
これ多分全員が全員できるとは思えないんですよ。
いいこと言ってるなぁが、
なんかこういうこと言ってるね、なんか良さそうだね、
ぐらいに思うっていうパターンも全然あると思ってて、
人によってはね。
そもそも妥当性検証ということをちゃんとやろうという目的で、
望んでAIにここの部分だけお願いして、
いいことちゃんと言ってくれたっていう判定ができる人だったらいいんだけども、
なんか結構まだまだやっぱ難しいんじゃないかなと若干思っちゃったんですけど。
実は私が思うに、
妥当性の方が正当性より簡単なんですよ。
そうなんですね。
使いにくいとかっていうのは人間が直感的に分かるじゃないですか。
なるほど。感覚で分かる。
感覚で分かる。感覚で分かるわけですよ。
例えばよくゲームとか脳汁出るみたいな言い方しますけど、
脳汁出るをAIに理解させるのは相当大変だと思うんですけど、
人間は一発で分かるわけですよ。
これ脳汁だ、これダメだ、脳汁出ねえわとか言えるわけで、
妥当性検証の方がどっちかっていうと人間にはフレンドリーだと思ってます。
仕様の方が難しいですね、むしろ。
確かに。
なるほど。じゃあ人間がやるべきところはやっぱそのUXだったりとか、
これで例えば自分がユーザーだったら自分もだし、
他の顧客がいるんだったらその人たち、
市場の人たちが喜びそうだなっていうところは、
人間が担っていくって感じなんですかね。
そうだと思いますね。結局自分たち、
人間の問題って人間が変わる問題しかないんですよ、大体。
そりゃそうですよね。
人間が変わる問題しかないんで。だから人間の心地良さとか、
人間の感性っていうのがすごく妥当性にとってはいつまでも重要なんですよね。
そのセンサーとして人間はいつまでもまだ必要なんだと思ってます。
人間が使うんだったらってことですよね。
AIが使うんだったらまた別だけど。
それの一個の歯車としてAIはかなり食い込んできてるよねってところですね。
妥当性検証もしてくれるし、一部してくれるしっていうところなんですね。
ここら辺の妥当性検証とか、正当性検証はありそうなんですけど、
妥当性検証で数理モデルを使っていい感じに証明できるみたいなそういうのがあったりするんですか。
一応できなくはないんですけど、あんまり良くないかなともちょっと思ってるけど、
一応ちょっと私の最近のアイディアを話してみると、
大体そのユーザービジティとかっていうのは、画面すごく狭い。画面って狭いですよね。
画面の中にどういう入線順序で、どういう動線、シーケンスっていうのを重視するかっていうことの
攻め切り合いによって画面のレイアウトとかが決まるんだと思ってます。
情報密度が限られるから、のせたい情報を入れているだけだよねっていう。
だけどそこに絶対収集選択肢がなきゃいけないわけですよ。
24:00
例えば設定画面って割とどうでもいいから、みんな設定画面をハンバーガー外国の中とかに隠したわけですよね。
だけど例えばSNSとかだったらタイムラインの画面はめちゃくちゃ重要だし、
ダイレクトメッセージの画面はやっぱり大事だしっていうのがあって、
これはタブとかに一等値に置かれるわけですよ。
これってやっぱり何をやったかっていうと、いろいろシーケンス振る舞いが許されている中で、
このシーケンスには価値がある。このシーケンスはちょっと価値が低い。
けど必要としている人は一部いるみたいな。
そういうふうな形で優先順位付けがされているんですよね。
それがレイアウトに落ちてきているっていうのがある。
なのでこのシーケンスごとに重要度を決めてあげた上で、
そのシーケンスが最もみんなをハッピーとさせるような計画を探索させることができると思っているんですよ。
つまりこのシーケンスは何でできる?
条件としてはより多くのユーザーが使うシーケンスは、
そうじゃないシーケンスよりもタップ数が少ないとかっていうふうな条件をつけることができる。
それでデザインを探索させるんです。
いろいろデザインをさせてユーザビティレビューをさせてみます。
お客さんはこういうことをこの画面を見たらすると思うけど、
このシーケンスよりもこっちのほうがタップ数多いじゃん、ダメじゃんみたいなことを認識させるってことをやると、
これ結構妥当性検証としてはっきりとした基準になるので、
AIが回しやすい、ループエンジニアリングしやすいような基準になると思っています。
例えばこういうことをやってあげたりするっていうのが一つ私は最近思っているアイディアですね。
ユーザビリティテストとしてどれだけ早くそこの機能にたどり着けるかっていうところを検証するということですね。
速さを数値上で測るみたいなステップ数で測るみたいな。
実際そのソフトウェアっていうのは何らかのシーケンスをこなした後に価値が生まれるってパターンがほとんどで、
例えばECサイトとかで言うとカートに入れるまでは全然価値が生まれてないんだけど、
カートに入れた後に商品の決済が走って、商品が届くっていうこのシーケンスに価値があるわけですね。
商品が実際に移動してっていう。
これが一番価値の高いシナリオなんで、これのタップ数はとにかく押さえなきゃいけないんですよ。
住所変更とかよりもこっちの方が圧倒的に高頻度でやれるんで、
タップ数はこっちの方が少なくあるべきだよね、みたいなのが具体例になりますね。
なるほど。
その検証をちょっと証明できる形でできないかっていうところを。
証明までいかないと思っていて、探索ですね。
いっぱいいろんなデザインってかっていうのがあって、同点のデザインとかもあると思って、
どっちがいいかっていうのはどっちに先にたどり着いたかでしかないと思ってるんですけど、
そういうふうなデザインとかを探索させてあげるってことができると思っていて、
そうしてあげるとループエンジニアリングは多分できる。
めちゃくちゃ面白そうですね。
単純に採点ができるんですね。
このデザインの、このホーム画面のデザインだったら80点とか。
これは実装しなくてもできるんですよ。
むしろ実装しちゃうとめんどくさいことになるんで、
フィグマ上とかでモックアップできるじゃないですか。
画面の繊維図が描けていればできますね。
27:01
なので机上演習できるんですよこれ。
確かに。
っていうのとかを作ってあげるとすごく私はうまくいくだろうなって思いますね。
実装してしまうとめんどくさいっていうのは結構実感値としてあって、
実際に画面の繊維をシミュレーターとかで実際にやってみないといけないんですよね、実装してしまうと。
そういうユーザーストーリーのフィグマみたいな画面一覧がないと。
だからこそフィグマみたいな形で画面一覧が一気にある状態の方がやりやすいっていうのは確かにその通りですね。
タップ数のどこをタップしたらどこに行くのかっていうのがちゃんと定義できていれば。
実装しちゃうと通信が失敗したりすると簡単にコケちゃうんですよね。
だけどフィグマ上は別に通信失敗しないような繊維組んでおきますでいいじゃないですか。
確かに。
それが圧倒的に楽なんですよ。
やりやすい。
やりやすい。
実際にそれ今やってたりするんですか?
今はそうです。会社でフィグマのベストプラクティスを探っていてこれができるような体制っていうのをちょっと作ろうとしてますね。
めちゃくちゃいいですね。面白そう。できたら。
そうですね。
それで先にデザイン上で点数比較してどれにしようかっていう議論ができるっていうことですね。
デザイン上いい感じのものを。
もちろんあれですよね。この機能にはこのぐらいの価値があるみたいな重みづけは人間がするって形ですよね。
そうです。最初はそうなると思いますね。ただ実際にユーザーのデータが手に入り始めるとまた話が変わってくると思っていて。
確かに。
Googleアナリティクスとかでお客様が80%はこの動線を通るとかっていうのはわかるじゃないですか。
そのデータの方が人間の仮説よりも価値がありますね。
確かに。一番最初は人間のそれこそPOの独断と偏見によってこれの方が絶対いいはずだみたいなので決めつつも後からリリースした後は数字を追いつつっていう。
そうですね。もちろん数字に丸められちゃうのには背景がいっぱいあって。
例えばこのページにみんなが劣れず入れてると思ったら実はみんなごとアップしてるだけだったみたいなのがあるんですよね。
ありそう。
そういうのは数字には丸められちゃって見えなくなっちゃうから、ある程度訂正的な面もやっぱり必要ではあります。
いろいろやり方はありつつもっていうところですね。
データとしてはどんどん集めて、妥当なところを妥当なデータとして集めていくとどんどん精度は上がっていくんじゃないかっていう。
めちゃくちゃいいなと思いましたね。
やり方としてはもしかしたらABテストもできるかもしれない。
ただUIがガラッと変わると難しいかもしれないんですけど。
ABテストとかでデータの検証とかももしかしたらできるかもしれないぐらい。
そうですね。ABテストはめちゃくちゃいい手段だと思っていて。
なんならAIにABテストさせるのも結構いいんじゃないかなと思ってて。
探索自体は。
実際に私たちがやるときってデザインがABCがあります。
どれが一番いいですかみたいな。そういう比較になるんですよ。
そりゃそうですね。
なのでABCでそれぞれループエンジニアリングさせて
30:04
ここら辺はこういうふうにここで詰まりましたとかって取ってあげると比較ができる。
そうするとこれが1みたいなのが分かる。
これは鉄則なんですけど。
AIとかの言ってることを鵜呑みにしちゃいけないっていうのはユーザーインタビューの鉄則で。
実際にタスクを与えたときにかかった時間とか5タップの数とかっていうのをしようがすごく大事なんですよね。
だからそういうのとかを見てあげて今間にミスったな。
ここのアイコンがミスってたからだなとかここの部分の位置が良くなかったんだな。
指に隠れちゃって見えなくなったんだなとかそういうのが分かると一番いいんですね。
全ての情報を鵜呑みにせずにちゃんと検証していくっていうところの姿勢の方が重要ですよね。
全て受け入れないでちゃんと自分で考えて検証しましょうっていうような当たり前の話かなっていうところですね。
結構いい話できたかなと思ってて。
正当性の検証も重要だしそれよりも妥当性の検証が重要なんだけど
人間がどんどん今後になっていく妥当性のところでどんだけこのプロダクトがいいものかとか
どういう価値を持つべきものなのかっていうところをジャッジにどんどんやっていきつつ
その妥当性の検証もちょっとずつAIで良くなっていくんじゃないかっていうようなところですかね。
ありがとうございます。
最後にこの検証周りで何か言っておきたいところとかあったりします?
そうですね正当性検証も妥当性検証もAIに正当性検証ヨロとか妥当性検証ヨロって言うと大抵うまくいかないんですよ。
ノイズばっかりになるか全て見逃すかみたいな感じになっちゃうんで
大事なのはその正当性も妥当性もその構造を抽出することだと思っていて
さっき言った通りそのクリック5タップがどれだけあるかっていうのは一種の構造になってて
シーケンスがある中でその寄り道しちゃうのは原点だよっていう構造にフォーカスさせるわけですよ。
そういうふうにどこかの検証の意味のレイヤーの構造に着目させてあげると
結構AIってバッチリ指摘してくれるんですよ。
だから私は正当性検証妥当性検証今すごくフォーカスさせるためのツールをいっぱい作っていて
それが結構成果を上げてきているのでぜひ正当性検証も妥当性検証も意味構造を抽出して
フォーカスさせてあげるってことをAIにやってあげるとうまく連携できると思いますよ。
いいですね。ちょっとそのツールいっぱい作っているツールの話もどこかで聞きたいなと。
そうですね。
じゃあ今回はここまでにしたいなと思います。
もっと詳しく教えてください。
ラジオ略してくわらじではスーパーエンジニアであるくみわけさんに
一般エンジニアであるへんてこが技術的な質問をしていく番組になっています。
今後もですねいろんなこと聞いていきたいなと思ってますので
お聞きのプラットフォームで高評価やフォローやチャンネル登録の方よろしくお願いします。
またこんなことをくみわけさんに聞いて欲しいというものがありましたら
コメントいただけると取り上げますのでよろしくお願いします。
Xなどでハッシュタグくわらじでつぶやいてください。
33:02
感想もぜひお待ちしております。
それではここまでありがとうございました。
ありがとうございました。
