PMFは1->10でも（大体）必要
私は今いわゆる1→10フェーズのプロダクトのマネジメントをしている。よく言われる0→1と1→10で求められる能力やスキルの違いとして以下が挙げられることが多いと思う。
これについて、自分の実感としては大分異なる点が大きいため、それをまとめる。
PMFとは
PMFをするということは、これまで解決できていなかった課題を従来の方法とは異なる形で解決するプロダクトを創出することだと理解している。PMFの失敗パターンとしては、そんな課題は存在しなかった、課題はあるがお金を払ったり労力をかけたりするほどの価値ではなかった、技術的にできないことだった、技術的に可能だがお金と時間がかかりすぎる、などが挙げられる。
1回のPMFで成長できる余地には限界がある
冒頭にあるような0->1と1->10の違いに関する記事にはこの点が抜けていると思う。それこそiPhoneだって初期はWebベースだったのが急にAppStoreなんて開設して一気にネイティブへ舵を切ったり、スキュモーフィズムを捨ててフラットデザインへ移行したり、なかなかにドラスティックな変更を繰り返した結果、今の地位がある。
これはもはや第二、第三のPMFを実施した（そして成功した）と見做すべきレベルの仕事だと思う。そして別にこれはiPhoneに限らず、ある程度成功しているプロダクトであれば皆こうした経験を経ている。
PMFは0->1移行も繰り返さなければならないし、それが無ければいずれ競合に追いつかれてしまうのではなかろうか。
とはいえ0->1のPMFは失敗すると会社自体が死ぬが、1->10のPMFについてはある程度の失敗なら持ちこたえられるという側面はあると思う。その代わり、今の組織だったりプロダクトについて場合によってはドラスティックな変更を推し進めなければならないという、ある種の身軽さが失われている。
可能性ではなく確率へ注意を払え。或いはもっとマシな方法を考えよう（About Face）
ユーザーの集中を邪魔しない
文書やソースコードを書いているとき、気がつくと時間を忘れて没頭したりそのプロセスを楽しんでいることがある。こうした状態のことを流れ（flow）と呼ぶらしい。確かに「フロー状態」とググってみると概ねそのようなことが書かれたコンテンツがヒットする。
こうしたユーザーのフロー状態を維持する方法の一つとして「モードレスでフィードバックする」というものがある。
こういったウィンドウやダイアログボックスを差し込む方法はモーダルである。ユーザーは自分のタスクを続ける前にまずこのモードに対処しなければならない。当然ユーザーのフロー状態を止めてしまう要因に繋がる。
確率と可能性
しかしこうしたモーダルやダイアログボックスは頻繁に見かける。はてなブログでも下書きを削除しようとするとこのようなポップアップが出てくる。
削除のように不可逆的な操作についてはミスをした時のダメージが大きい。こうした注意喚起の意味も込めて何も考えずに確認モーダルを挟むことが多いし、それによって顰蹙を買うことも少ない。むしろ一部のユーザーにはこうしたダイアログが無いことが不安だと文句を言うくらいだ。
しかし今からまさに下書きを削除しようとしているユーザーがここで「キャンセル」を押す可能性はどの程度あるのだろうか。あるとすれば、チェックミスで別の記事を消してしまうということが考えられなくもないが、このダイアログでは「1記事を削除します」と記事の数しか明示してくれていないため、そのミスも防ぐことはできない。
これは完全に私見だが、現場猫的なダブルチェックによるトラブル回避をバカにするソフトウェアエンジニアでも、意外とこういったダイアログを何も考えずに差し込んでくることが多い。
話を戻すと、可能性がゼロではないからといってダイアログを差し込むのは止めようということだ。一体その操作が行われる確率はどの程度なのか、ということを考えなければならない。多くのユーザーにとってはただ手間でしか無い操作を、一部のユーザーのために強いることは全く合理的でない。
ミスをした一部のユーザーを救いたいのであれば、彼らだけにピンポイントで有効なソリューションを考えるべきである。
具体例
例えばGmailでは送信したメールを、その直後であればキャンセルすることができる。
【Gmail】送信したメールを取り消す方法（PC、Android対応）- 送信取消機能 ≫ 使い方・方法まとめサイト - usedoor
この方法は多くのユースケースに於いて、ダイアログを差し込むことより遥かに効果的ではないだろうか。別にやり直す必要の無いユーザーは完全に無視することができるし、うっかりミスを犯した場合でもワンクリックで元に戻すことが出来る。
そしてはてなブログの下書き削除についても、結局ゴミ箱機能がついており30日以内であれば復元することができる仕様になっている。せっかくこの機能があるのだからわざわざ確認ダイアログなど挟まずに、Gmailと同じように「ゴミ箱から復元」リンクでも用意すれば良いのだ。
とはいえ、流石に天下のはてな社がこんなことに気づかぬはずがない。下書きを削除するという操作自体めったに行われないから放置しているのであろう、と思っている。
ユーザーを愚かに見せるな（About Face）
Kyashというアプリを使っていたらこのようなエラーが出てきた。
これは典型的なダメUIだと感じる。About Faceを参照しながら、なぜこういうUIを作ってしまうのか、どうするべきなのかを論じる。
このUIの何がユーザーを（というか私を）苛立たせるのか
私は一応もともとソフトウェアエンジニアとして働いていたので、こういうUIを作ってしまう気持ちは痛いほど分かる。
チャージできませんでした。 Kyashにご登録のカード会社へお問い合わせください。
適切なエラーメッセージとしてまず必要なことである、何が起きたのかというファクトを正しく明示せよという原則に則って「チャージできませんでした」と簡潔な文が最初に来ている。確かにnginxのアクセスログで「8月8日の23時頃にエラーアクセスがありました」とか書かれていてもデバッグができない。
そして次のメッセージ、「Kyashにご登録のカード会社へお問い合わせください。」。これはおそらく実装的にはクレカ会社とのAPI連携で、クレカ会社側が何かエラーを返してきたということなのだろう。つまりKyash側は少なくとも仕様どおりの動きをしている。であればまず疑うべきはクレカ会社側の問題なのだから、そっちを調べろという指示である。まっことごもっともなメッセージである。
しかしこのメッセージはユーザーをバカにしているようにしか（少なくとも私には）見えない。インプリメンテーションが露出しており、メンタルモデルに全く則していないからであろう。平たくいえば、この画面を見る時のユーザーのことを全く何も考えていないのだ。「お前のクレカ設定が間違ってるんだから何とかしてこい。うちは知ったこっちゃない」と言わんばかりに見える（被害妄想？）。
ユーザーのゴールは何か
こういう時は慌ててメッセージの文言を変えるのではなく、ユーザーのゴールを考え直すところから始めることがAbout Face的にも推奨される。慌ててパッチワークをしてもろくなことにはならない。
このエラーメッセージは、私が土曜の夜中に知り合いへ送金しようとした時に発生した。
この時のユーザーのゴールとはなんだろうか。
About Faceではゴールとタスクは全く別物であって、世にはびこるユーザーインターフェイスはタスク指向でしかないものが多すぎると言っている。例えばKyashにおけるタスクとはこんな具合だ。
- 現金と同等の汎用性を持ったポイントを任意の相手に渡す
- 対面せずにオンラインで渡す
- 24時間好きな時に渡す
一方、（少なくとも私にとっての）Kyashのゴールはこんな具合だ。
- 送金を忘れないように、思い立ったその場ですぐに実行できる
- 銀行口座は印鑑証明とかの写真を撮るとかコピーを郵送するとか馬鹿げた行為なしで送金できる
- アプリを勧めずとも周囲の人が既に使ってくれている
手段がタスクであって、目的がゴールであるといったところか。どんなアプリであってもゴール指向でないデザインがされていれば、いずれは使われなくなっていくと本書は断言している。
この場合のゴールとは何か
とはいえ問題はクレカ会社側のAPIがいつもと違う動きをしていることだ。Kyash側としては（バグ改修などを除けば）手出しができない状況なのだろう。
しかし私からすれば、明日は日曜だしそもそも窓口も分からないしどうせ聞いたところでたらい回しにされて「Kyashとかいうアプリがダメなんですよ」とカード会社のヘルプデスクから冷たくあしらわれる言われる未来すら想定される。全くやる気がでない。しかしこの支払を忘れて相手から信用を失うのが怖すぎる。
つまり私の今のゴールはこうなる。
- 相手を待たせたくない。送金を忘れたり、送金が遅れることで「こいつだらしないな」と思われたくない
- なんとか電話せずに自分で解決したい（ヘルプデスクに電話する体験はたいてい最悪）
- 会社が休みの間になんとか解決したい。平日になると忙しくて忘れるのが怖い
ここまでゴールの解像度が上がると、少しはマシな打ち手が見えてくる。
1を解決しにいく場合、Kyashアプリ側が相手方へ「クレジットカード会社側のトラブルで送金が遅れてしまっているようです。◯◯さんと我々は最善を尽くしてこのトラブルを解決しようとしています。」とでもメッセージを送ってくれる機能を実装することが考えられる。要は「こいつだらしないな」と思われなければよいのだ。
2, 3を解決しにいく場合は、こうしたトラブル時のよくある解決手法のうち、クレカ会社へ電話せずにできそうなことが書かれたFAQページへのリンクでも貼れば良い。別に100％解決を保証しなくても良いので、可能性があれば教えて欲しい。（e.g 一旦他社のクレカを紐付ける）
どれも2週間もあればリリースできるような機能である。技術的にはできないはずがない。
なぜこうなってしまうのか。どうすれば避けられるのか
おそらくこのUIを考えたのはエンジニアだろう。もしかしたらディレクターやPdMが「もうちょっとユーザーフレンドリーにできないの？」とか聞いたかもしれないが、エンジニアが「いやクレカ会社側のトラブルなんだから知りませんよ」と冷たくあしらったのかもしれない。なんにせよこれはインプリメンテーションモデルに則ったメッセージだ。事実として、インプリメンテーション的には、このエラーは100%クレカ会社側のAPIの責任である（とKyashエンジニアは思っている）。
つまりインプリメンテーションに最も近いエンジニアがこのUIを考えたと考えるのが自然だろう。特にこうしたエラーの理解は多少技術がわからないと判断が難しいところがある。技術が分からないPdMやディレクターがメッセージ内容を丸投げするとこうなるのだ。
PdMとしてできることは、以下ではないだろうか。
- 技術を理解し、顧客のメンタルモデルを理解した上で、すべてのUIを自分で設計する
- 上記ができない、どうしてもエンジニアへ任せるしかない場合は
- この画面を見た時のユーザーのゴールを定義し、エンジニアにそれを伝達する
- ユーザーのゴールさえ特定されていればそこに最適化してくれる優秀なエンジニアを予め採用しておく
なんにせよ、このUIを作り出した責任はPdM又はディレクターにある。PdMやディレクターは設計者でもありつつ、こうしたバッドUIを防ぐ優れたQAでもいなければならない。大変つらい仕事だ。だがやりがいはある。。。。。と思う。
私自身も、気をつけねばらならない。
で、結局どうやって解決したの？
よく見たらSMSでクレカ会社から新着メッセージが届いており、開いたところどうも不正利用防止システムが働いたようだった。この利用は私本人ですよ的なボタンを押したらすぐに解決。「よくあるケース」的な感じでKyashアプリ内にこれが出ていたらどんなにNPSが上がったことだろうか。。。。残念である。
ビジュアルインターフェイス - 視覚のプロセスとパターン
これを読んでいる。
視覚のプロセス
ここでは人間の視覚は無意識下である種のパターンマッチングを行っており、これのおかげで脳は見るものの優先順位をシステムを確立できているという話がされている。
個人的にはこれは別に視覚に限った話ではなく、人間の行為すべてに言える話だと考える。
人間が行為するということのなかには、行為の主題となっているものの遂行とその主題的行為の遂行と同時に生まれる「副産物（side effect）」（Ｄ・デネット）とが含まれている。
たとえば、コーヒーを飲もうと思って、カップをソーサーから取ること、カップを口に当てて飲むこと、それらはコーヒーを飲むことの一連の主題的行為に含まれることである。
しかしコーヒーを飲むという行為は主題的連関以上のものを含んでいる。
たとえばコーヒーを飲む際に生じる音（コーヒーを飲む音）も、“コーヒーを飲む”という行為の中に含まれている。
それはコーヒーを飲むという主題的行為の「副産物」に属しているといってよい。
誰も音を出すためにコーヒーを飲んでいるわけではないからである。
たしかに。
たとえばコーヒーを飲んでいるとき、突然電灯が消えたとしよう（松原仁、「人工知能における『頭の内と外』」 in 『哲学』 1990/10）。
飲んでいる人は驚くに違いない。
なぜ驚くのだろうか。
おそらくコーヒーを飲むことと電灯が消えることとの間には、「変化」にかかわる因果連関がないからである。
普通われわれは、何をすれば何が起きるかという「変化」の関連を視野に収めながら ― 間違っている場合もあるにせよ ― 行動している。
行動とはいつでも予期行動なのである。
これは当然、ビジュアルインターフェイスデザインでも無視していいことではない。 本書ではパターンシステムでどのパターンを認知し、意識的なシステムがそのパターンの詳細を認知するとしている。ビジュアルインターフェイスもこのパターンに則ることが重要である。
視覚的なパターン
iOSの設定画面では各カラムの左側にアイコンが入っている。これは単にオシャレかどうかということではなく、それぞれの行が異質なものであるということをパターンとして認識させていることが伺える。
またこうしたパターンは学習される。ユーザーはアイコン（記号）から自分なりに意味を解釈し、それを学習してくれる。ただしこうした学習を期待する場合は、該当するオブジェクトと記号を常に紐付けて表示しなければならない。逆に言えば、それさえ守れば覚えてくれる。本書ではこれを視覚的フーガ（visual fugue）と呼んでいる。
About Faceを読む（導入編）
アランクーパーの名著About face初版の日本語訳。国会図書館以外ではもう見つけることすらままならないこの書籍を上司が貸してくれた。
そして時代は流れ、About faceは既に第四版が出ている。日本語訳や第三版までで止まっている上に中古で27,000円超えという状況だが、英語版ならKindleで3,500円出せば買える。英語ができないと質のいい情報にはアクセスできないという状況を端的に物語っているようで辛い気持ちになる。最近エラーログ以外で英文を読んだ記憶なぞない。
しかしそうも言っていられないし、何よりもあのアランクーパー先生の書籍なのだ。PdMとしては読まないわけにはいかない。ということでやっていく。一体何ヶ月かかるのだろうか。。。
About face
まず"About face"という聞いたことのない熟語の意味を調べた。Google日本語訳によれば「顔について」らしい。が、どう考えても書籍のタイトルとして「顔について」はおかしい。よくよく調べてみると（ぐぐってみると）こんなページがヒットした。
Definition of about-face 1: a 180° turn to the right from the position of attention 2: a reversal of direction 3: a reversal of attitude, behavior, or point of view
日本語だと「回れ右」「転向」といった語が近いニュアンスのようだ。さて何からの転向なのだろうか。 開発者やデザイナーではなくユーザー目線で考えようというありきたりな話かな。何はともあれ読み進める。
目標志向のデザイン
まずすべてのユーザーインターフェイスはユーザーの目標(Goal)を達成できるものでなければならない。もっと言えばユーザーの目標をそのままインターフェイスデザインに落とし込まないといけない。
さて目標とは何か。結論は「時と場合によるので一意には言えません」というありがちなものだ。ただし目標とは何"ではない"か、それはどのように特定するべきかという話はされている。 ただ読んだ内容を転記していても著作権的に問題があるし何よりも新規性が無い。そこで私自身が悩んでいる問題を解決してくれるアプリケーションのデザインを策定する中で、About faceに書かれていることを実践することにした。
日報をつけるのがめんどくさい
うちの会社では半期に1回のペースでいわゆる360度評価を受ける。その際に自己申告で「この半期はこんなことをやりましたよ」というのを上司や同僚が見やすい形で残しておくことは評価上有利に働く可能性が高く、また自身でふと「あぁ俺こんなことやってたなぁ」と振り返ることでエモくなれるため、日報をつけることはそれなりに意義がある。
私が日報をつけるパターンは主に
- 朝イチに昨日やったこととその感想、今日やることを書く
- 就業前にその日やったこととその感想、明日やることを書く
の2つであった。しかしなんだか最近仕事が忙しく、朝イチや就業前にも普通に会議が入っていたりして日報をつけるのが億劫になってしまった。これは良くない。
そこでコアコンセプトとして以下を持つアプリケーションを作ることにする。
参考：
- 誰が：スケジュールが埋まりがちなサラリーマンが
- 何を：自分の実績や底に対する感想をまとめた日報を
- いつ：毎日
- どう：手軽かつ簡単に書ける
さてこれは完遂できるのだろうか。我ながら不安ではあるが、楽しみもある。
EngバックグラウンドPdMを誰がなぜ必要としているのか
私は今とあるIT企業で（少なくとも肩書は）PdMとして働いている。
有名なマーティ・ケイガンの『Inspired』を読むと辛くなるくらい必要な力量は付いていないが、それでも何とか1年はクビにならず働いている。
1年働く中でふと、「よくよく考えたら、EngバックグラウンドのPdMって本当に需要あるの？」という疑問を（今更）抱き、色々話を聞いていたらなんとなくその答えが見えてきたので、ここに記す。
そもそも私がなぜPdMを目指したか
もともと私がPdMという職種を目指したのは、ITとビジネスの双方を考えてサービスを立ち上げたり伸ばしたりすることが、ITコンサル会社でSWEとしてもITコンサルとしても働いていた当時の自分のキャリア的に最も相性が良かろうという軽い気持ちが発端であった。
また当時通っていた大学院でもサービス開発の真似事を実践し、「あぁサービスがゴミだとどんなに美しいコード書いても意味ないな。でもビジネスだけしかわからないとコードがゴミになるんだよな。」と思ったことも、ITとビジネス両方を考える職種であるPdMへ興味をもったきっかけにつながった。
EngバックグラウンドのPdMってどこで需要あるの？
上記のような背景で転職をしたため、当時の私にはPdMが今後メジャーな職種になるのかどうか、いまいち確信が持てなかった。いわゆる見切り発車である。
大体PdMといっても、会社によっては実質PjMを募集しているし、あの有名な及川さんも「PdMは事業の成功のために必要なことは何でもやりましょう」とか「本当に解く価値のある課題（できれば複数）を特定し、最適な方法で解く方法を考えよう」とか、別にそれPdMでなくても必要だよねレベルのことしか言っていない。
いま“企業がどうしても欲しい”PdM像を【土屋尚史・杉浦正明・丸山貴宏・及川卓也】が徹底討論！【PMC2019レポート】 - エンジニアtype | 転職type
職種的に「なんでもやりましょう」が求められる上に、会社によってイメージも違うPdMという職種へニーズが高まっていると言われても、意地悪な言い方をすれば都合のいいスーパーマンを求めてるだけなんじゃないのと思ってしまい、悶々としていた。
オペレーション最適化の先を目指している会社
上記のようなことをぼんやりと考えながらいろいろな会社の人と話をしていたら、気がつくことがあった。
そもそも私が見聞きする（つまり私のバイアスが入っている）範囲で成功している会社というのは必ずITを活用している。今話題のワークマンもCaddiもラクスルもそうだ。ある意味では、もう9年も前になる、ホロヴィッツが言っていた"Why software is eating the world"の延長線上で未だに物事は進んでいるということになる。
そして、そんな会社が成長するステップもどうやら以下の1と2に分けられるらしい。
- 自社事業のオペレーションをIT化することで、圧倒的なコスト削減やPDCA高速化につなげる
- ITを活用するからこそ提供できる新しいユーザー体験、それによってインパクトが出せる領域の発見とソリューションの創出
例えばワークマンは1を達成したことになる。一方ビズリーチは自社事業である転職エージェントの中で発見した「客観的な判断に基づく“採用→評価→育成→配置”ができていない会社が多い」という課題に対してHRMOSというサービスをローンチしている。
分かってきたのは、EngバックグラウンドのPdMを求めているのはこの2について実践している、または実践しようとしている会社であるということだ。
自社事業のオペレーションを最適化するだけでは日本一には（多分）なれない
先程から何かと引き合いに出すワークマンは現在年間の売上が900億程度、一方ユニクロは8800億程度である。ワークマンが日本一を目指すかどうかはさておき、このままの戦略ではユニクロを抜かすには彼らが落ちてくるのを待つほか無いということは想像がつく。どんなにオペレーションがうまくてPDCAが速くても服屋は服屋である（それが悪いわけではない）。世界一を目指すのであれば服屋ではない何か、へ転身するしかない。
つまり自社事業の再定義が必要となるわけだ。マイクロソフトがWindowsとOfficeで儲けるためのリソースを捨ててでもAzureに舵を切ったように。ビズリーチはコアビジネスの転職エージェントサービス用のリソースをあえて、（傍から見る分には）儲かるかどうか分からない人材活用プラットフォームに投入している。これでもまだ無難な投資だとは思うが。
おそらくオペレーション最適化をゴールにするのであれば、やる気のあるソフトウェアエンジニアへ”ユーザー業務”を体験でもさせて、彼らが思う改善方法というのを地道に積み重ねれば良い。それが難しいという話もあるが、それはそういうことをやってくれるソフトウェアエンジニアなりプロジェクトマネージャーが雇えないという話であって、PdMはあんまり関係ない。
ただし事業創出となるとそうもいかない。なにせ今は存在すらしないサービスなのだから体験も何もない。必然的に仮説検証を重ね着実に前進できる（または潔く撤退できる）人材が必要となる。そして今はMVPだのリーン開発だの、最小限の機能を兼ねそなえた実際のサービスをリリースしないと仮説検証って無理じゃねという話が多い。（個人的には、それアプリ作らなくてもユーザーインタビューなりペーパープロトで良くない？っていうか行動観察しました？という事例が圧倒的に多いが）
こういうことを考えられる人材は、確かにEngバックグラウンドのPdMが適切かもしれない。Engバックグラウンドがないと見積もりができない、無駄に実装コストが高い設計にしてしまう、そもそもありものを組み合わせれば良いものをわざわざスクラッチ開発してしまう、といった事故につながるリスクが高いのだろう。
ただでさえうまくいくかどうか分からない新規事業立ち上げにおいて、そういう"防げる事故"は防ぎたいだろう。余談だが私が転職して徹底的に叩き込まれたことは「作らないという選択肢を第一に置くこと」であった。
ということで、誰がどういう理由でEngバックグラウンドのPdMを求めているのか、がある程度腹落ちできた。そんなん知ってたわという人が大半なのだろうが。
ユーザビリティとは & ユーザインタビューの設計、振り返りについて
以下の書籍を読んだ。
ユーザビリティエンジニアリング(第2版)―ユーザエクスペリエンスのための調査、設計、評価手法―
- 作者:樽本 徹也
- 発売日: 2014/02/26
- メディア: 単行本（ソフトカバー）
購入自体は数ヶ月前に行っていたが、電車内の移動時間等の隙間時間でちょぼちょぼ読んでいても内容が頭に入らないため、 年末に腰を据えて一気に読むことを決意した。 導入部分とユーザインタビューの章が今の業務で悩んでいることと近く、学びも多かったので、ここを私的に要約した。
ユーザビリティ
- ユーザーの満足を得るために保証しなければならない『利用品質』
- 「使いやすさ」ではない。ユーザビリティが損なわれた製品は「使いにくい」で済むどころか、そもそも使えない
- そもそもユーザビリティ自体、特定のコンテキストにおいて、特定のユーザがある目的を達成するために製品を用いた時の効果、効率、満足度の度合いを指す
- つまりコンテキストやユーザが設計されてない時点で論外（実際の現場だと結構見るような気もする）
- 以下を全て満たして初めて『ユーザブル』
- 効果...ユーザが目標を達成するための機能があること
- 効率...なるべく最短経路で目標を達成できること
- 満足度...目的を達成する上でユーザが不愉快な思いをしていないこと
ダメなユーザビリティの製品が出る理由
上記の条件が満たせていないから。
- ユーザ像が無い、もしくは開発陣に最適化された像でしかない
- コンテクストがない、（以下同文
ユーザエクスペリエンス
ユーザビリティが満点でも、製品の評価も満点とは限らない。 コモディティ化を避けたかったら体験までコミットしましょう。
UCDのアプローチ紹介
ユーザエクスペリエンスの設計は表層だけでなく、その下の構造や戦略の土台から考えてないと詰む。（The Elements of User Experience） いきなりアイデア考えたりユーザーの不満を実装するのではなく
- ユーザーの利用状況はなにか、課題（潜在的なものも含めて）はなにか？
- 今から作ろうとしているものは、この課題を効率よくかつ満足度を担保した状態で解決できるか？
を最低限の実装（プロトタイプ）で評価し、OKになるまで実装してはいけない。 この評価はたいてい複数回行われる。見かけの納期は伸びるが、ダメな機能をリリースしてから直すより遥かにマシ。
ユーザインタビュー
よく言われる「ユーザへの弟子入り」が重要。質問は事前に一個用意しておくくらいで十分。 まず教えを請い、わからない部分を根掘り葉掘りし、最後に自分の理解を確認する。終わったら別のことを聞く。
注意点は以下の通り
- ユーザは話を要約しがち
- ユーザの話は時系列に沿ってなかったり抜け落ちがあったりする
- ユーザは例外を無視しがち
アンチパターンの一つとして、「なぜ◯◯しないのですか？」が挙げられる。（結構やりがちだった気がする） これを始めると弟子入りというより議論になってしまう。「◯◯はやってない」→「どれくらい◯◯はやってませんか？最後にやったのはいつですか？」など、あくまでも教えを請う流れを意識する。 なぜ、を考えるのは聞く側が考えるべきこと。
インタビューの設計
- 聞きたいことを整理し、インタビューのテーマ（何を何故知りたいのか）にフォーカス
- 質問をオープン形式に
- 質問の順番を自然な会話風に、プロフィールや普段の仕事の話から、徐々にテーマに移していく
- インタビューガイドを作る（書籍p48参照）
インタビューガイドはかなり役に立ちそう。次回から取り入れる。 「あなた”流”の使い方はありますか？」「◯◯を使っていて、戸惑ったり慌てたり、失敗談はありますか？」「◯◯の機能で、めったに使わない機能はありますか？」 は使えそう。
インタビューの結果を分析する
KJ法が有用。まずはテープ起こしから発言録を作り、これをカード化、グループ化、アウトライン化、最文章化、検証。 p68を参照。
まとめ
- ユーザブルとは「どんなユーザ」が「どんなコンテキスト」で目的を達成する上においていくつかの評価項目が基準値を満たすこと
- 仮にユーザブルでもビジネス的には微妙かもしれない。エクスペリエンスまで考えよう
- ユーザインタビューはUCDにおける調査での一手法。注意点やアンチパターンを踏まないように
- ユーザビリティは即興性が大きいが、とはいえ事前の設計や事後の分析も重要
次はインタビューの事前設計と評価について、深堀りしたい。
