00:06
9月10日土曜日ですね。
地獄朝9時を回りました。
昨日の夜ですね、名作と言われている映画「ゴッドファーザーズ」の初代、第1作目を僕は昨日初めて見たんですけど、
まあまあ面白かったですね。面白かったんですけど、
あとメッセージ性も結構強かったんですけど、
あれがなぜそこまで当時の時代とか、あの時代に流行って、あんだけ名作だと言われて、
パート2が出たりするとか、3が出たりするとか、
あといろんなゴッドファーザー何たらみたいな作品に繋がったのかっていうのは、
僕の中では全然わかってなくてですね、
今それを自分なりに咀嚼したり調べたりしているところではあります。
はい、余談から入りました。
夢見のkeethさんの川原です。
では本日の朝活を始めていきたいかなと思います。
えーとですね、今日のタイトルですけど、
今日読む記事はタイトルにある、
The Final Technique in Collaborative User Researchっていう記事ですね。
こちらを読んでいこうと思います。
多分短いので時間が余ると思いますので、
もしいけるんであればもう1個の記事、
Testable Front End The Good, The Bad, and The Frackyっていう記事ですね。
こっちも読んでいこうかと思います。
またテストの話読むんかいってところですけど、
僕はテスト好きなので、ゆるりとお付き合いいただければ幸いです。
というところで、早速今日も入っていけたらなと思います。
はい。
えーと、いなきさんですね。
おはようございます。ご参加いただきありがとうございます。
この放送はただただネットで見つけた記事をだらだら読むっていう、
本当にそれだけの回です。
はい、じゃあ行きましょう。
最初、The Final Techniqueですね。
はい、まずサマリーです。
The Final Techniqueっていうのは、
ユーザーインタビューやユーザビリティテストで使用され、
いわゆる打倒性を損なわずに、
豊富なインサイトを得ることを保証します。
そんなようなスキルについてまとめられているのが、
そのThe Final Techniqueだというところですね。
はい。一応これがサマリーです。
で、じゃあ具体的に入っていきますけど、
The Final Techniqueっていうのは、
質的インタビューが研究手法として登場した時からある手法になります。
このテクニックっていうのは、
幅広いオープンエンドの質問した後に、
徐々により狭い範囲のオープンエンドの質問と、
クローズな質問を導入するものになっています。
オープンエンドの質問とクローズな質問というところに、
リンクが貼られていますので、
そこの記事のリンクをちょうどツイートしますので、
見てみられればと思います。
よく考えたら、
昨日読んだ記事をツイートしていない気がものすごくしているので、
後ほどやります。
で、戻りまして、
このように広い範囲から始めて、
より具体的にしていくという考え方は、
ユーザーインタビュー以外の他のタイプの調査でも有効になります。
このテクニックはセーリスによってとても役立ちます。
これは本当によくやりますよね。
ブレストとかでもよくやりますし、
アイディア出しをやってから具体的に何をやるかということですね。
ひたすらフロー式をどんどん広げておいて、
03:01
後ほどフロー式を閉じていくというような考えですね。
これは本当に僕も良いと思います。
黒から入ってミックルに落とし込んでいくということですね。
セーリスに役立ちますので、
例えばインタビューの質問であったりとか、
フォローアップの質問であったりとか、
ユーザビリティのタスクであったりとか、
当面調査における研究であったりとか、
いろんなところで使えますよね。
この記事ではユーザインタビュー及びモデレート、
ユーザビリティテストにおいて、
ファネルテクニックがどのように使用されるかというのを
説明していきますよというふうに言っています。
なるほどですね。
ではまた入っていきたいと思います。
まず一つ目ですね。
Why is it called the funnel technique?
そもそもなんでファネルテクニックと呼ばれているのでしょうか
というところですけれども。
つまりファネルですね。
ファネルというのは上部が広く、下部が狭いので、
開口部の狭い容器、ボトルであったりとか、
瓶などに物質、例えば油とか米などを注ぎやすくなっています。
同様にユーザリサーチにおけるファネルのテクニックというのは、
広いところから狭いところへ、言い換えれば
一般的なものから具体的なものへ、
中小度高いところから本当に具体的なところに
移行していくものです。
ユーザインタビューやユーザビリティテストのセッションは、
広範囲で探索的な質問やタスクから始めて、
具体的で狭い範囲の質問やタスクを導入する必要があるため、
ファネルは適切なメタファーと言えるでしょうと。
なるほど。
ファネルテクニックの目的というのは、
ユーザーの行動や認識にできるだけ影響を与えないようにすることです。
調査セッションの早い段階で特定の質問をしたり、
特定のタスクを与えたりするなど、
バイアスがかかり重要なデータが欠落する恐れがあります。
危険性がありますよというふうに言っていますね。
なるほど。
ファネルテクニックの目的というのは、
そういうバイアスとかデータ欠損みたいな危険性があるので、
そこを回避というか、するための対策的なテクニックだというところですね。
実際今このファネルテクニックの画像がガーンと今貼られていて、
ブロードというのがありますね。
上のいわゆる開口部ですね。
ところが、to generate newとか、
unanticipated insightsって書いてますね。
あと、specificですね。
下の方に行くと平行部、ちょっと狭くなってきますね。
口のところはspecific、特定のとか具体的なところですね。
to collect detailsって書いてますから、そういうことですね。
というところでした。
では続いていきましょう。
続いてのセクションが、
The Funnel Technique in User Interviewsというところですね。
ユーザーインタビューにおけるファネルテクニックというところですね。
ユーザーインタビューのインタビューガイドというのは、
通常参加者に関するストーリーや経験を協力してもらうための、
大体5個から8個ぐらいのオープンエンドの質問で構成されています。
06:04
これらに続くフォローアップの質問というのは、
オープンエンドまたはクローズドにすることができます。
インタビューは、前回映画のチケットを注文したときのことを教えてください。
いわゆる幅広いオープンエンドの質問から始める必要がありますよと言っています。
はい。
具体的なオープンエンドの質問というところですけど、
具体的じゃないですね。
こんな質問をしたらいいですよみたいなところですね。
参加者が話しやすいようにします。
続いて参加者がストーリーを共有し始めることができます。
新しいもしくは予期しない情報をたくさん生み出すことができます。
4つ目ですね。
リサーチャーが参加者にプライミングするのを下げることができますと言っています。
プライミングというところにも記事のリンクが貼られて、別のところの記事が載ってますね。
はい。
こんなような感じですね。
参加者が回答した後に、
インタビュアーというのは参加者の回答の中でリサーチャーが最も知りたいと、
もとはもっと知りたいと思う部分を掘り下げるために、
自由形式のフォローアップ質問、いわゆるプローブ質問と呼ばれたりもしますね。
っていうのをする必要があります。
これには次のような質問が含まれますと、
もう少し詳しく説明してもらえますか?とか、
それはどういう意味ですか?とか、
それについてどう感じますか?とか、
なぜそう思うんですか?とか、などなどですね。
インタビュアーは参加者が省略した追加情報や詳細を収集するために、
次のようなクローズド・クエスチョンを導入することもできますよと言ってます。
この映画を見たのはいつですか?とか、
一人で行きました?とか、
その映画は何分くらいですか?とか、
かなり詳細なとか、具体的なところに入っていくわけですね。
インタビューガイドに用意された主な質問ごとに、
インタビュアーは幅広いオープンエンドの質問からクローズドの質問へと移行していきます。
インタビューガイドの新しい質問ごとに、
パネル化のプロセスというのが繰り返されていきますよと言ってますね。
先ほどの画像の中にもう一つ、
さらに加えたものが載った画像が貼ってますけども、
いわゆるブロードのオープンエンディットクエスチョンから入っていって、
オープンエンディットのフォローアップクエスチョンに行って、
オープンエンディットのフォローアップクエスチョンさらに具体的なところに入っていって、
最後クローズドなフォローアップクエスチョンに行きますと。
そこからまたアンドリピートということで繰り返しですね。
他のところに行ったりとか、よりまたオープンな質問からまた具体的にどんどん入っていくという、
このサイクルを繰り返していくというようなところですね。
これをやって、質問1個1個に対して深みもしますし、
たくさんのことについても深みをしていくとか、
具体的なところの深掘りをしていくということですね。
このパネルテクニックを活用すると、
詳細を収集する前に新しいことを学ぶためのスペースを確保することができますと。
このインタビュー方法は、親密な関係を築き、
09:02
予備水なしでユーザーの本音を知るための最良な方法ですと言ってますね。
はい。
なるほどね。
予備水というところがなかなかミソですね。
何かをきっかけにどんどん情報を吐き出していくというのは結構ありますからね。
続いて、The Funnel Technique in Cooperative Usability Testsですね。
定性的ユーザビリティテストにおけるそのファネルテクニックというところです。
定性的ユーザビリティテストにおいて、
ファネルというのは以下のように使用することができますと。
1つ目は、ファネリングタスクですね。
タスクの作成及び順序付けというところですね。
もう1個は、参加者がタスクを完了した後のフォローアップの質問順序というところの考案。
この2つですね。
というのを考えることができますよと言っています。
タスクのまずファネル化を考えるんですね、そこから。
質的なユーザビリティテストのタスクの作成と順序付けには、
広範囲なものから具体的なものへと移行する同じプロセスを適用することができますと。
幅広い探索的なタスク、ユーザーがどのように行動するかを知ることができるようなタスクというのは、
ユーザーに何かを見つけるように、あるいは他の方法ではできないことをするように、
求める具体的で指示的なタスクの前に行う必要がありますと。
はいはいはい、まあそうだよね。
なるべく全部こっちが教えるというか、指示をするというか、やり方としてあるんですけど、
そのタスクを実行する人そのものにも気づきとか、
学びとかとかあるような指示を出すのがいいんじゃないかというふうに僕はこれを感じましたね。
幅広い探索的なタスクっていうのは、そうなりますよね。
全部を網羅することがなかなか難しいし、やってみなきゃわからないところもいっぱいあると思うので、
プロセス的にはまずでも結局幅広いところ、ちょっと抽象的、フワッとした感じから入るかもしれないですけど、
まあとはいえ、やっていく中でしっかりフォローアップをするような指示を出さないといけないということですよね、
ファネルテクニックですから。
ファネルテクニックのもう一つのメタファーっていうのは、迷路の中のネズミですみたいなことを言ってますね。
研究室の研究者が、マウスが大きな迷路の中でチーズを見つけることができるかどうかっていうのを確認することを想像してみてください。
まずマウスに迷路全体を与えて、チーズを見つけることができるかどうかを確認します。
しばらくしてマウスがチーズにたどり着かなかったら、不正確な経路を徐々に塞いでいって、
マウスがチーズを見つける可能性を高めていきますと。
ああ、そういうことをするんですね。
マウスインや迷図メタファーっていうところの画像が今貼られてますね。
本当に最初は迷路の中全体をバーンと出しておいて、そこにネズミを投入しますと。
で、ゴールにチーズがあるんですけど。
なかなかたどり着かなかったら、ちょっとずつ不確実性のある迷路の経路をどんどん塞いでいって、
12:04
最終的に1本でいけるような経路にたどり着かせる。
こんなようなテクニックをしますよねっていうふうに言ってますね。
なるほどね。
じゃあ続いていきましょう。ちょっと翻訳待ちです。
ファーネルテクニックを応用することは、迷路の中でネズミを誘導するようなものです。
ネズミがチーズへの道を自力で見つけられるかどうかをまず確認し、
必要に応じていくつかの経路を閉鎖していきます。
この例えの場合、マウスは参加者であり、チーズは私たちが研究したいデザインの側面です。
まず参加者が自力でたどり着けるかどうかを確認するのが良いのですが、
少し手を加える必要があるかもしれませんといって、
テーブルが出てきましたね。
テーブルは2次元ですが、縦軸としてタスクトゥギブザーパーティスパント、
あとラショネールですね。
ラショネールって言うんですかね。レーショネールですか。わからないですけど。
参加者に与えるべき課題です。
もう一個は理由ですね。
横軸にタスク123って感じになってますけど、
まずタスク1ですね。
タスク1はこのサイトを使ってあなたが作りたいと思うレシピがあるかどうかを見てみましょう。
その理由というところですけど、いわゆる幅広い探索的なタスクですね。
ユーザーがタスクの終点を定義し、自分なりの方法で完了することをまず許可します。
次はタスク2です。
サイトを使って夕食に作りたいと思うような簡単なレシピを探します。
続いての理由というところですけど、
ここは指示されたタスクになりますね。
ちょっと詳細な話になります。
このタスクは最終地点と成功基準が定義されています。
参加者にこの方法では探さないようなものを見つけてもらいます。
なるほど。
最終地点と成功基準が定義されています。今回は。
参加者にこの他の方法では探さないようなものを見つけてもらう。
一本道になるようなものを見つけてもらう。
最後はタスク3ですね。
検索を使用してチキンヌードルスープのレシピを見つける。
具体的にこのレシピだというのが決まるわけですね。
今度の理由としては完全に指示されたタスクですね。
最初の方のタスクは幅広い探索的なものですけど、
タスク2のところは指示されたタスクで、
タスク3はより詳細に指示されたタスクになります。
このタスクはユーザーに特定の機能を使用してあるタスクを行うように求めます。
私たちはユーザーに他の方法では探さないようなものを見つけ、
他の方法では使わないような機能を使うように求めていきます。
だから本当に手法であったりとか、
アプローチのところ、プロセスのところも一本に絞っていくような感じですね。
こうやっていくのがファネルテクニックですよねっていうような説明ですね。
でも確かに指示出し的なものも同じような感じかもしれないですね。
問題はそこまで各メンバーにそれぞれのタスクについての指示を出すとき、
15:00
ここまで時間を取れるのかっていうのも大事ですし、
ある程度フレーミングさえしてしまえば、
あとは自発的に皆さん動いてくれるっていうのがいいチームだと僕は思っているので、
人により蹴りだと思いますけど、やり方とかリーダーシップは人により蹴りですけど、
ここまでやったら確かにしっかりタスクを全然遂行してくれるとは思いますけど、
時間とコースの関係もあるのでどうなんだろうって言われますが、
ファネルテクニックの要素を取り入れた指示の出し方っていうのは確かにあるなと思ったので、
余ったその探索的、抽象度高いところから入って具体的なところに行くっていうのは別にありかもしれないですね。
あとはプランニングとかですかね、
スクラム開発やってるときのスプリントのプランニングするときとかも
こういうのから入ってもいいのかもしれないなと思いました。
ちょっとコンセプトとか手法が違ったりするんであれですけどね。
スクラムは現状課題を把握するフレームワークって言われたりするので、
そもそも具体的なところから入るのがスクラムだったりするから、
相性悪い気もしなくはないけど、
ただ僕がこの時点で読んだパネルテクニックって結構大きくなってる気もしているので、
ちょっと考えてみるのもいいかもしれないですね。
元々のフレームワークはこういうものですって確かに最初から前提から入るんですけど、
その前提に対して本当にそうかとか、新しい要素を取り入れることできないかっていう問いを、
根本的なところからの問いかけを投げるっていうのは僕は結構いい話だと思っているので、
ちょっと考えてみてもいいかなと思いました。
では続いていきますね。
もしタスク3ですね、具体的なところから始めて逆の順番で進めるとしましょう。
そうするとタスク1、タスク2でどのように行動するかを参加者に教え込むことになります。
タスク3から始めて逆の順序で進めると、
タスク1、タスク2で教えることになり、
参加者が指示されずに自分自身でどのように行動するかを学ぶことができなくなる可能性があります。
ここ重要ですよね。
結局指示待ちマンというか、上から言われたことしかやらないようなメンバーになりがちな可能性があるということですね。
具体的なところから入ると。
タスク3、2、1で行くということですね。
まず自分たちで考えたり探索をした上で具体的に行くというところに、
やはり学びであったりとか気づきがあるというところですよね。
タスクのパネル化、つまり広い探索的タスクから始めて、
指示されたタスクを導入することで行動に関する有効のデータを着実に取得することができるのが、
このパネルテクニックということですね。
確かにこの学習とか成長的な観点を踏まえるパネルテクニックが結構あるというか、
やっぱり俯瞰というか抽象的から具体的に行くというのは良い話だなと思いましたね。
まだ続いていきましょう。
もう22分か。
もう1個の記事。
テスタブルフロントエンドという記事。
ザ・グッド・ザ・バッド・アンド・ザ・フラッキーですけど。
これも読みたかったんですけど、ちょっと今日読めない可能性があるので、これ明日に回しますね。
パネルテクニックはステップタスクの背後にある考え方になります。
ステップタスクとは大まかなところから始めて、
必要に応じてより具体的な指示を与えるという多段階のタスクのことになります。
例えばあるeコマースサイトの比較機能を研究することに興味があるとしてみましょうと。
18:05
その時にまたさっきと同じようなテーブルですね。
抽象とかタイトから具体的に行くんですけど、
タスクですね。先ほどとちょっとナンバリングが続いてきますね。
次にタスク4です。
タスク4はまず買いたいと思うヘッドホンを選びカートに入れるというようなタスクですね。
まあちょっと抽象度高いですね。やることは分かりましたけど。
これは結構大まかなタスクです。
参加者にごく自然なタスクを与えて、
途中でたまたま私たちが興味を持っている機能を使うことをちょっと期待していますということですね。
続いてタスク4.1でちょっと深掘っていく感じですね。
あなたの友人はApple AirpodsまたはApple Airpods Proの購入を検討していますけど、
どちらを買えばいいかというところに迷っています。
このサイトを使って友人にどちらを勧めるかその理由を決めてください。
確かにちょっと具体的ですね。
このタスクに対しては、
参加者が自分で自然に比較機能を発見して使ってくれないという場合は、
このようなフォローアップの指示を出すこともあります。
そこまでそもそも比較機能とか検索機能でいけるのであれば、
そういう友人のサポートしなくても、友人は勝手にそのままやってくれますからね。
いけなかった時にそういうことをします。
目標は参加者をより具体的な状況に置くことで、
自然ではないかもしれないですけど、その機能を使うように一応促すことですよと言っています。
続いてタスク4.2なのでまたもうちょっと具体的なところですね。
ページを切り替えたりせずに、
その2つのヘッドホンを比較する方法を見つけることができますか?みたいな投げかけをすると。
ページ切り替えをしないのであれば最初から比較するページがあるはずだってところにたどり着くので、
そこに行ってたどり着けたら、
比較機能を見つけているということに他ならないのでそういうことですね。
これは先ほどの続きですけど、
それでも参加者が興味のある機能を使用しない場合があるんですか?
私たちはさらに直接的な方法を取るかもしれません。
この例では比較機能があることを強くほのめかし、それを使うよう参加者に求めています。
たどり着かないんじゃなくて使わないっていう人もいますよね、比較機能を。
比較の仕方はそれぞれありますけど、
比較機能を知らないっていう前提でいくとそういう促し方もありますよねってことですね。
でも確かにファネルテクニックを使っているというのはわかりました。
上記のステップタスクの例でタスク4.2まで到達した場合、
その機能には発見性または望ましさの問題があると結論付けられるかもしれません。
しかしこのレベルの具体性を提供することで、
これらの結論を出すと同時にこの機能自体に
インタラクションデザインの問題があるかどうかっていうのを確認するチャンスも得ることができますよって言ってます。
それも確かにそうですね。
続いていきましょう。
Funneling in follow-up questionsですね。
フォローアップ質問におけるファネル化ですね。
さっきの抽象的な質問に対するファネル化でしたけど、
続いてフォローアップの質問ですね。
21:01
訂正的なユーザビリティテストでは、
ファシリテーターっていうのはフォローアップの質問をするときに
ファネルのテクニックを使用します。
例えば参加者がタスクを終了した後に次のような質問をすることがありますと言ってますね。
またこれもテーブルになっているので、
1,2,3ってあるから具体的になっていくんでしょう。
1つ目ですね。
Question1は、
この活動をウェブサイト上で行うことについて何か感想はありますか?っていうところですね。
本当にふわっとした質問です。
この広範囲で自由な質問により、
参加者は完了したタスクに関連することを共有することができます。
続いてQuestion2ですね。
簡単なことは難しいことはありましたか?と。
これによって具体的な質問形式の、
具体的な自由形式の質問っていうのは使いやすさに重点を置いています。
ここではユーザーに対して使ってよかったこと、と思うこと、
もしくはあるいは苦労したと思うことを思い出してもらうように促しています。
結構逆なんだな。
最後の質問、Question3ですね。
使用しているフィルターについてどう思いましたか?ってところですね。
より具体的な質問となる自由回答になります。
ここではタスクで使用した特定のUI要素についてユーザーの注意を喚起しています。
でもアンケートとか質問を取るときに、
よくやるのって結構具体的なところからバーッと入っていて、
最後に何かありますか?本当に自由形式で思うところ、
何か追加で何か書けるもの出しておきたいものありますか?
みたいなアンケートが圧倒的に多い印象があるんですけど、
確かにファネルテクニックを使って逆説的に入っていくっていうのは
かなり面白いというか興味深いですね。
一番最初に超抽象度高く何でもいいから何か感じたことないですか?
みたいなことから入るっていうのはいいと思いますけど、
一方で回答者って自由形式の回答が面倒くさいって思う人が圧倒的に多いんですよね。
しかもそれを必須とかにしてしまうと余計にその瞬間から閉じてしまう可能性もあるので、
ちょっと危険な感はありますけど、
回答させるという意味では最初に抽象度高くフワッとやらせておいて、
そこから具体的なところ。
こちらが聞きたいところにちょっとちょっと流すのもいいですけど、
そこから何か派生したい、そういえばアルマットなみたいなところでいく可能性はないですね。
だからこそ最後の最後にフワッとさせる方がいいんじゃないかって気もしなくはないですけど。
最初から具体的なところにいくと考えとか見るところがフォーカスされすぎてしまってて、
他の発想に行かないっていう危険性も正直あったりはするので、
こちらが用意する質問の数を増やして、
いろんな観点での回答とか感想を聞いてみるというふうに促すのもありではありますが、
そうすると今度は質問の数が増えすぎてしまってて、
回答者がそれはそれでやっぱり面倒くさいと思っちゃう可能性もあるので、
結構バランスはありますね。
ただある程度フォーカスとか見るところを絞った上での自由回答形式から入るのは僕は結構いいのかなと、
今なんかなんとなく思いました。
24:01
余談をさせておきに戻ります。
先ほどの例では幅広い自由形式の質問から始めて、
より多くのフィードバックが欲しいUI要素に関連する特定の自由形式の質問へと範囲を狭めていますと。
質問3からクエスチョン3から始めて逆の方向に進むべきではありません。
言われてましたね。
べきではないんですね。
なぜなら参加者は促されることなく自発的に情報を提供するのが常に良いからですとこの人はおっしゃってますね。
私たちは参加者が私たちの特定の指示がなくても有機的にフィードバックを提供していることを期待しています。
なぜなら自由意志によるフィードバックっていうのは参加者の真の意見である可能性が高いからです。
これも確かにそうですね。
言われてみれば。
参加者に特定の要素に関するフィードバックを求めることは危険です。
参加者が単に研究者のために意見をでっち上げる可能性が常にあります。
まあ、何ですかね。
可能性はあります。
しかし、ユーザーインタビューとかからいくと、まさにインタビュアー側の方の意図を組んだ、そういうバイアスをかけて回答をする可能性もちょっとあったりするので、
本当にその意図が真の意見ですかっていうと疑問になったりするので、確かに最初から具体的に入ると危険性はすごく高いですね。
なるほど。
参加者に特定の要素に関するフィードバックを求める危険で、参加者が単に言いました。
例えば、質問1に対して参加者がフィルターがとても役に立ったと答えた場合、質問3に対して同様の回答をするよりも参加者が本当にそう考えていると確信することができます。
何も促すことなく、フィルターが役に立ちました、よかったというフィードバックがあれば、本当によかったということに言えますからね。
何も出てこなくて促していって、最終的にフィルター機能についてどうだったってなる場合は、実はそんなに良くなかったっていうことですよね。
なるほどです。
最後、ここまでサマリーで終了にしたいと思います。
最後、まとめですけど、パネルテクニックっていうのはユーザインタビューまたはユーザビリティテストで質問またはタスクを行うときに使用できます。
より具体的な質問またはタスクを導入する際に、幅広い自由形式の質問またはタスクから始めてください。
このアプローチっていうのは重要な情報を見逃さないようにし、参加者には早すぎる促しとか呼びかけをしないようにするのにも役立ちます。
インタビューやユーザビリティテストの司会とかファシリテーションですね。
詳しく知りたい場合は5日間の訂正調査コースとか1日間のユーザインタビューとユーザビリティテストのコースっていうのがあるのでそこを見てみてくださいと。
そういうワークショップ的なものをやってますよってことでした。
そのリンクも貼られてますので見てみていただければなと思います。
というわけで30分超えましたので、今日の朝活はこちらで以上にしたいと思います。
パネルテクニックっていうところでした。
インクオラティブユーザーリサーチなので、ユーザーリサーチの質を上げるためのパネルテクニックってところだったので、
27:02
実際プロジェクト進捗とかチームビルディングとかタスクの管理とかについて直接的に使えるっていうわけではないですけど、
要素的には確かにありだなと思いました。
特にブレストとかするときもまさにこれだなっていう感じはするので、
一つ参考になったなと思いますし、このテクニックを使える場面では使っていくっていうのは結構いいなと思いました。
というわけで、ちょっとあまりエンジニアには関わりがない、ユーザーインタビューなんてあんまりエンジニアはやらないですからね。
直接的なあれではないですけど、人生におけるスキルとして一つ持っていくのは全然いいなと思いますね。
ソフトスキルですね、まさにこれは。
というところでした。
参考になれば幸いです。
前日、何度かピックアップした通りですけど、
明日はこのテスタブルフロントエンドっていう記事の方を読んでいこうかなと思います。
こちらもちょっとそんなに長くはないので、もしかしたら途中でスパッと終わってしまう可能性が…
あー、ごめんなさい。嘘です。結構長かったな。
かなり長いですね、これ。
明日1日で終わらない可能性がありますね。
なので明日はまたテストの話かってなりますけど、
僕はテスト大好きなので、ごゆるりと参加いただければすごく幸いです。
じゃあ終了したいと思います。
今日は第1弾ですね、ご参加いただきありがとうございました。
また今日、明日と土日休みですね。
ゆっくりお休みいただいて、永久を失っていただければなと思います。
では、あさかずこれで終了したいと思います。
お疲れ様でした。
