デザインリサーチの教科書
- Amazon
- kurこと木浦幹雄さんの本
- CIID(Copenhagen Institute of Interaction Design)で学んできて、自分自身も色々なものを作り出してる
- 「ちゃんとデザインできる人がデザインをちゃんと学んで書いたデザインの本」
サイボウズ社内の勉強会で説明するための読書メモ
デザインが見た目だけのものじゃない話
- Buchanan's Orders of Designで4つの段階に分けられている
- デザインという言葉で見た目や工業製品のデザインをイメージしがちだが、インタラクションやエコシステムのデザインまで広がりがある
- CIIDはCopenhagen Institute of Interaction Design
- Buchanan's Orders of Designで4つの段階に分けられている
人間中心設計は言葉の意味が変化した
- 関連: 「誰のためのデザイン」
- 前提として作りやすさがユーザにとっての使いやすさより優先されていた時代があって、それに対して「もっと使う人間にフォーカスして設計すべき」となったのが初期の人間中心設計
- Useful（役に立つか）、Usable（使いやすいか）、Desirable（好ましいか）
- ユーザの内面に関する指標
- 「使う人間にフォーカスして設計」の具体的な実現方法は？
- 「使う人間にとっての使いやすさは何か？」を使う人抜きで議論して設計してもな…
- というわけで「デザインプロセスにユーザを迎え入れる」という参加型デザインという手法が生まれた
- 関連: 参加型デザインの話は「どんな機能が欲しいか」でも出てきた
- kintoneをこの視点で眺めてみると:
- 業務用アプリの開発に関して「使う人がデザインプロセスに参加できるようにする」仕組み
- 「既に作られたもの」を購入するのではなく、ユーザ自身が開発プロセスに参加する
- 仕様を決めて「作る人」に外注するのでもなく
デザインリサーチ
- この本ではリサーチの結果をもとにデザインするものとしている
- 世の中的に明確な定義がある言葉ではない
- ニーズがあり、解決されてなく、現実的コストで解決できる課題を見つけだす必要がある
- これを「機会」と呼ぶ
- 機会の発見 デザイナが関わるフェーズ3つの1 p.40
- Opportunity Scout
- Storytelling
- Execution
- これはCIIDによる定義
- 「どのような価値を提供するか」が機会(の半分)、「それをどうやって提供するか」がソリューション
- ソリューション、解決方法をいきなり考える前に、まず機会を言語化する
- 手戻りを小さくする効果がある
- これは「あいまいで大きなプロセス」を小さなプロセスに分けることで、うまくいかないときのネクストアクションを決めやすくなる効果があると思う
- ソリューション、解決方法をいきなり考える前に、まず機会を言語化する
- 機会の発見のためには、選択肢を増やしてから減らすのが良い
- 人間は色々なバイアスのせいで「取りうる選択肢」の一部しか認識できてないからまず選択肢を広げる必要がある
- ここで議論した: デザインシンキングは深さ優先探索？
- 人間は色々なバイアスのせいで「取りうる選択肢」の一部しか認識できてないからまず選択肢を広げる必要がある
- この本ではリサーチの結果をもとにデザインするものとしている
機会言語化のメリット: デザインのプロセスの透明化
- 「なぜ作るのか」「人々が本当にこれを求めているのか」に対して自信を持てる
- →プロジェクトに対するコミットメントが高まる
- 他人がプロジェクトの目的に共感しやすくなる
- ブラックボックスだと物が完成するまで関わりづらくなる
- メンバーが自律的に動きやすい環境づくり
- 「なぜ作るのか」「人々が本当にこれを求めているのか」に対して自信を持てる
デザインリサーチは上流工程ではない
- 独立した工程として開発の前にあるのではない
- 例えばリーンスタートアップ的なプロダクトの開発
- これはプロセス自体が仮説検証の繰り返し
- プロダクト開発そのものがデザインリサーチと言える
マーケティングリサーチとデザインリサーチの違い
- 混同されやすいが目的が異なる
- 速い馬が欲しい
- 人は何が欲しいのかわからない
- →新しいものを作る上で直接何が欲しいか聞いてもあまり有益な調査にならない
- まず個人にフォーカス
- 人を安易に抽象化しない 人には個人差がある
- 個人に注目して得られた知見が、その個人特有なのか、多くの人に当てはまるのかは、得られた後で確認することができる
- 「典型的なユーザ」に絞る必要はない、エクストリームユーザに注目することで得られる知見もある
- このエクストリームユーザを新たな顧客にすることは主目的ではない
- 黒い皿の話
- アビリーンのパラドックスみたい
- ファーストフードとオーガニックフード
- 自分が実際にどうであるか、ではなく、社会的にどうであるべきかの憶測で演じてしまう
- 他人の前では模範的であろうとする
- なるべく普段通りの状況で観察したい
- 理解する対象をユーザ個人に制限しない
- これはかつてユーザのことを切り離して製品のことだけ見て設計していたのと同じ轍
- ユーザは環境と独立して存在しているのではない
- 周囲の環境や人と相互作用する
- そのユーザが製品を使うことによって、周囲の人や環境にどのような影響を与えるか？与えるべきか？与えないべきか？
- kintoneなどのグループウェアの場合は特に、組織に対して導入されるって特徴がある
- ユーザ個人の使いやすさだけではなく、それが組織の中で使われた時に周囲の人にどのような相互作用を起こすか
- 例えばグループウェアを使う個人にとっては自分の書いたものを多くの人に読んで欲しい時にeveryoneメンションをしたい、しかしそれは周囲の全員に対して通知を発生させる
- 混同されやすいが目的が異なる
企業における新規事業開発
- 「新規」って言ってるけど基本的にゼロベースではない
- 企業が既に持っているリソースを活用することによる相乗効果
- 既存顧客に対する露出・認知・理解、開発生産の設備・人員、調達販売チャネル、知財、etc.
- サイボウズの場合だとゼロベースの企業に比べて「既にグループウェアを活用している顧客」が抱える問題を理解しやすいし、それを解決するソリューションができた場合にそれを顧客に認知させやすい、販売チャネルも作りやすい、というあたり
プロダクトはモノだけではない
- 購入者が製品を認知してから死ぬまでがプロダクト
- 「墓石のように死んだ後も残された人に価値を発生させるケースがある」なるほど
- 「購入者が製品を認知してから、ユーザが死ぬまで」か？
- そもそも購入者が法人の場合、購入の意思決定をした人が退社することもあり得る
- まあ、売買のタイミングで終わりじゃないよ、ということ
- 「墓石のように死んだ後も残された人に価値を発生させるケースがある」なるほど
- 組織改善、業務改善自体がプロダクトになりうる
- モノに合わせて組織や業務の側を改善することもプロダクトになりうる
- これはサイボウズ的にはしっくりくる考え方だと思う。
- かねてから言われてる「グループウェアを売るのがゴールではなく、顧客企業がチームワークあふれる状態になりそれが維持されることが大事」という考え方とマッチする
- 購入者が製品を認知してから死ぬまでがプロダクト
ここまでで2章、全体の3割ほど。3章以降で具体的な手法の解説がある。
ここまで読んでの考察
- 普段の自分の行動を振り返ってみると「できるかできないからグレーなもの」に進む傾向がある
- 「できるかどうかわからないもの」が「できる」とわかることが、できる範囲の拡大だから
- 無意識に「できることを増やすこと」に高い価値を感じて行動している
- 技術的難易度の軸で難しい側に進むことになる
- 一方でイノベーションの機会を探索することを考えた時、これは「探索範囲を無意識に狭めている」ことになる
- 5つ矢印を書いたうちの右に進む2本しか見てない
- 僕でも右に進む矢印2本のうちだったら顧客価値の高い方を選ぶけど、それだとあまり適切な機会探索ではない
3章
- デザインリサーチの手順
- デザインプロセス
- ダブルダイヤモンド 2019版の矢印追加の話
- d.schoolとCIID
- プロジェクト設計
- チームビルディング
- タックマンモデルのバリエーションDAUモデル
- Stormは独立のフェーズではない
- 「好む働き方」「このプロジェクトで得たいもの」などを最初に開示
- プロジェクトに対する認識を揃える
- 議論のテクニック: Four-Player Framework
- 関連: 6つの帽子
- タックマンモデルのバリエーションDAUモデル
- リサーチ設計
- 調査
- インタビュー
- それが最適と言える理由は？
- どんな人に話を聞くのか客観的に定義できると良い
- 最適な人数は意見が分かれる
- 1人増やすことで得られる情報は徐々に減るので、どこかでコストに見合わなくなる
- 「インタビューをすること」は手段であって目的ではないので、予定途中でもやめるのが理想
- クライアントワークの時はなかなかそうもいかない
- 誰がそれを決めるのか事前に決めておかないとダラダラ続けてしまう
- すごく具体的な情報が充実してる、ここだけで60ページある
- インタビュー
- 分析
- テーマ作成
- インサイトの抽出
- 良いインサイトとは
- 読んで理解できる
- 文脈を知らない人をチームに巻き込むことが可能なように
- イノベーションにつながる
- 次の行動に移せる
- 面白い結果であっても行動につながらないなら無益
- 新しい知見であること
- 読んで理解できる
- 良いインサイトとは
- 機会発見
- How might we
- 「我々はどうすれば〜ができるだろうか」
- 対象ユーザ
- 制約
- 達成すべきゴール
- 10の実例
- 長所を伸ばす/短所を取り除く
- 形容詞に注目してそれを変化させる
- 逆に考える(ネガティブなものをポジティブにするなど)
- そもそも論
- あることが前提のものをそもそもなくす、など
- 他に使用可能なリソースがないか？
- 立場を変える
- 迷惑を被ってる側の視点だけで考えがちだが、あえて問題を発生させている人の立場に立ってみる、など
- 問題を分割する
- コレはもうちょっと色々な案がありそうな気がするなー
- ネガティブな言葉を使わない
- 広すぎず狭すぎずな質問にする
- ステークホルダーとの認識のすり合わせをする
- 「我々はどうすれば〜ができるだろうか」
- How might we
- デザインプロセス
ここまでの考察
テーマ作成の部分までは僕の普段やってるKJ法のライト版と置き換えても問題なさそう。
KJ法はグループ編成した後がぼんやりしているが、こちらの手法では「インサイト抽出」「機会発見」と続く。
- それぞれの段階でのアウトプットに「どういうものが良いか」が明示されているので迷子にならずに進みやすそう。
- KJ法のグループを文章化するとき、特に「イノベーションにつながるか」は考えてない
- 考えても面白いかも
- これはKJ法がそもそも学問上の仮説を作るために生まれたからで、何かをデザインするための手法とは「仮説を作る」ところが同じでも、仮説の目的が違うことによる
アイディエーション
- プレスト「すべて紙に書く」「紙に書かれないアイデアは無価値」
- いいね、まったく同感
- アイデア選択
- まず評価軸を定める
- アイデアを見てから評価軸を作ってはいけない、特定のアイデアを選ぶためのバイアスが掛かる
- プレスト参加者に評価軸をあらかじめ伝えてはいけない、出てくるアイデアにバイアスが掛かる
- 意見が分かれた時にどうやって調停するのか？
- kur: まず、プロジェクトのゴール/目標を確認するですかね。ゴール設定が曖昧だったり、人によって解釈が違ったり、制約条件が違ったりがあると思うので、前提条件をすり合わせます。前提をすり合わせずに、どのアイディアが良いか？で話しあっても、なかなかまとまらないと思うので
- なるほどなるほど、目的の解釈や暗黙の制約の理解などに食い違いがあるかも知れないから、そこをまず解決するわけですね。そこを解決するとどのアイデアが良いかに対する意見の食い違いが消えてなくなることが多い、と。
- 対立解消図の考え方に近い
- kur: とはいえ、利害関係者同士、「良い状態」が必ずしも一致するとは限らないので実際には難しいところだったりするんですけど。お客様のことを考えるとA案のほうがいいけど、組織に設定されたOKRを考えるとB案が良いとか。
- コンセプト作成
- コンセプトとは？
- 明確な定義がない
- 知見をステークホルダーに伝える
- アイデアをもっと具体的にして検証可能にする
- コンセプトとは？
- ストーリーテリング
- 仮説検証としてのプロトタイピング
- フィディリティの低いプロトタイプ
- ペーパープロトタイプとか
- フィディリティの低いプロトタイプ
- プレスト「すべて紙に書く」「紙に書かれないアイデアは無価値」
4章 デザインリサーチの運用
- 継続的なプロダクト開発におけるデザインリサーチ
- 組織構造
- 独立チームの場合コストセンターとみなされる
- リサーチの機会を見落としがち
- プロダクトマネジメント