このブログ記事は、先月末に NIJIBOX さん主催で開催されたイベント『UXリサーチの最適解 〜職域と機能から考えるベストプラクティス〜』でお話しさせていただいた内容の解説になります。

なぜこのテーマを選んだのか?

主催者と登壇者間で2回に渡るディスカッションをした結果、昨今の UX デザイン界隈におけるトレンドの一つでもある UX リサーチを取り上げることにしました。UX リサーチの定義や職域、必要性などが語られるイベントが非常に多く開催されていますが、もう一歩先に踏み込んだ、組織への装着について議論がなされる時間をより多く設けるべきである、という結論からこのようなテーマを設けることになりました。

当イベントの位置付けは、HOW TO よりも、UX Maturity Model(UX 成熟度モデル)における第3段階「Invested」− つまりUX デザイン的活動は投資に値するかどうかを見極めるためのディスコースを促す場です。

Planning Your UX Strategy

A strategy is a set of coordinated, orchestrated, planned actions, or tactics, which will take you along a journey to reach a desired future state, over an established period of time. Design objectives are conditions or outcomes that a project must meet, often of tactical nature.

UX リサーチをする上で大切な3つのこと

私が UX デザイナーとしてのキャリアを選択した当時、UX リサーチはもちろんのこと UX リサーチャーという職種すらありませんでした。ユーザーリサーチが近しいかもしれません。しかし、スマートフォンの普及などに伴い、ユーザー体験そのものが経営に直結することにようになったことで、より広義のユーザー体験の設計と改善に資本を投下する企業が増えてきたことが、UX リサーチとして生まれ変わった背景にあるかもしれません。

ところが、UX デザインが UX デザイナーだけで完結しないように、UX リサーチにも同じようなことが言えます。なので、タイトルの「属人化」「UX」を強調しました。このセッションで私が伝えたかったことは以下の3つです:

  1. UXリサーチの良し悪しは、リサーチの結果ではなく、ユーザーが求めているプロダクトが 提供できたかどうかで判断すべきである
  2. UXリサーチで検証するための仮説の種は、チームの誰もが持っている。 ユーザー体験のリサーチは組織全体が取り組むべき活動である
  3. リサーチが開発のボトルネックとなってしまってはNG。いまこの瞬間も使っている ユーザーがいることを認識し、成長速度を上げるために仮設検証を高速に回そう

自身のキャリアから見たリサーチの本質

以前、「UX デザイナーからプロダクトマネージャーへのキャリアパスの探究」というブログ記事で自身のキャリアについて触れましたが、私は UI デザイナーとしてキャリアをスタートさせました。その後、情報アーキテクチャへと視点を広げ、そこから少しづつ、ユーザーインタビューやユーザビリティテストといった、いわゆる「対ユーザーのリサーチ」を専門としていた時期がありました。ただ、ユーザーリサーチャーという専門家ではなく、UX デザイナーの延長として行っていました。その後、UX デザイン→サービスデザイン→プロダクトマネジメントとミクロからマクロな視点でプロダクト開発に携わっていくことになるのですが、プロダクト開発におけるリサーチが明らかにすべき点は3つあると思います:

ただし、これらの問いに対する納得度の高い結果が得られたとしても、いいリサーチとは言えません。期待した結果ではなく、最終的にはプロダクトが世に出たときにユーザーが求めれている価値が提供できたかどうかで判断すべきです。これは、例えユーザーリサーチであっても UX リサーチであっても、リスクを低減するための活動としてのリサーチの本質だと思います。

組織的活動としての UX リサーチ

UX リサーチャーを批判しているわけではありませんが、捉え方によってリサーチをする人が限定されてしまうと、投資する以前に関心ごとで終わってしまい、前述の UX Maturity Model の階段を登ることすらできず、組織全体への浸透が困難になってしまいます。

私は、UX リサーチは組織全体が取り組むべき活動だと思っています。なぜなら、リサーチに必要な仮説の種はチームの誰もが持っているからです。某就活サイトのリニューアルに携わっていたときに、身を以てそれを学びました。

マーケティング、営業、カスタマーサポート、エンジニア…サービスに関わっている人であれば、何かしらのインサイトを持っています。なぜならば、インサイトはファクトから生まれ、そのファクトは日々の分析やサービス運営などから見出されることが多いためです。しかも、それぞれが異なるファクトを保持していることが多いため、インサイトも多様です。

これが、仮説の種になります。あとはそれを検証可能な形式に整え、リサーチの計画を練って実行すればまた新たなファクトを集めることができます。これを誰もが必要なときに必要な情報にアクセスすることが可能になるよう一元化することができれば、それは常に進化していき、ユーザー体験の向上のために当事者意識も芽生えると同時に、リサーチを組織全体で取り組むべき活動として認識されるようになります。

共有フォルダでもいいですし、定例会議でもいいです。ファクトを集めることから始めてみてください。

アジリティの高い UX リサーチ

前職の Pivotal Labs でご一緒させていただいた多くのクライアントを含め、アジャイル開発を推進している企業は年々増加してきているように思います。特に昨今では HOW としてのアジャイル開発が触れられることが多い DX に関する記事を目にしない日がないくらいです。

アジャイル開発の導入によって得られるアウトカムの一つとして「ユーザーからのフィードバックまでのリードタイムが短くなる」があります。従来のプロダクト開発と比較してリリース頻度が格段に上がるため、仮説検証を高速に回せるようになりました。そのため、リサーチも従来とは違ったアプローチをとっていく必要性が出てきました。

UX リサーチの必要性が理解できていても、その実行における時間的コストが肥大化することでプロダクト開発のボトルネックとなってしまっては本末転倒です。世の中には非常に便利なアクセス解析ツールがどんどん増えてきています。故に今この瞬間も使っているユーザーの行動をその場で分析することも可能になりました。フィードバックループの速度が速くなればなるほど、プロダクトやサービスの成長速度も速くなります。

冒頭でもお伝えしましたが、リサーチの結果は、ユーザーが求めている価値が提供できたかどうかで判断すべきです。当初計画していた通りにできなかったから失敗というわけではありません。如何に低コストで、高いリターンを得ることができるのか、それだけを考えた方が組織内衝突もなくなります。

リサーチを始めるタイミング

最後に、セッションの終わりでも質問をいただいていましたが、リサーチをすべきタイミングについて自分なりの意見を述べて終わりにしたいと思います。言わずもがな、リサーチの目的は仮説検証を繰り返してプロダクトやサービスを成功へと導くことです。そのため、ポイントとなるのはフィードバックループを止めないようにすることです。

以下がそのリサーチをすべきタイミングを判断するためのサインです:

もし、UX リサーチャーが必要か否かを判断するための材料が必要というのであれば、上記を参考にしていただけるといいかもしれません。このサインを見逃すと、リサーチの意味を見失ってしまいます。

だからと言って UX リサーチャーに全てを委ねるのではなく、組織的活動としての UX リサーチをリードする専門家としてポジショニングした方が、それこそユーザー体験の底上げに最大限貢献できるのではないかと考えています。

4年お世話になった Pivotal Labs を卒業し、9月1日付で Ubie 株式会社に入社しました。

Ubie(ユビー)は

  1. 医療機関向けの働き方革命をサポートする「AI問診ユビー」
  2. 生活者向けの適切な医療へのアクセスをサポートする「AI受診相談ユビー」

の2つの事業を展開している、病気推測技術に強みを持っている会社です。僕はその中でも toC プロダクト「AI受診相談ユビー」のプロダクトオーナーを拝命することになりました。

Ubie株式会社 | Ubie, Inc.

Ubieは、テクノロジーの力で「世界中の人々を適切な医療に案内する」をミッションにしたヘルステックスタートアップです。AIを使った業務効率化や病気推測のサービスを提供しています。

ぼくの両親はとても活発で、やりたいと思ったことをなんでもやります。父はジムのトレーナーになるんだ、と言って筋トレばっかしていると思いきや、大学院の社会人用コースに通っていたりします。母は児童館で子供たちと遊び道具を作ったり、地元のコーラスサークルに入会して全国目指すんだ、とか言っています。羨ましいのです。そして、最期までその姿を見ていたいのです。

成し遂げたいことは、Ubie のようなサービスを通して生活者に寄り添い、長い人生の最期まで可能な限り健康維持をサポートし、やりたいことが不備なくできる自由を作り上げることです。それは、Ubie で実現できることだと思います。

なぜ転職を決意したか?

きっかけは二つありました。

一つは、「社会貢献要求」が強くなってきたことです。これまでのキャリアを振り返ってみると、個人であったりユーザー、それを取り巻くステークホルダーへの貢献を最優先に考え実行してきました。しかし、COVID-19 のクライシスに直面して以降、意識は社会へと移り、顕在化した多くの産業の「不」を自らの手で解決していきたいと思うようになったことが大きいです。

もう一つはテレビCMでも流れている、某人材会社の社長に自身のキャリアについてカジュアルに相談させていただいたときでした。

  • 昔はもっと貪欲な人だったでしょ?
  • これまで大きな意思決定に関わったことはあまりなかったでしょ?

目が覚めました。その業界に長く携わっている方なので当たり前なのですが、キャリアを辿っただけで薄れていった過去や自分に欠けているものを丁寧に紐解いてくださったような気がします。過去の人事の方から確かに「丸くなったね」と言われたことがあります。本当に感謝しています。これからは、より圧倒的にサービス作りに励んでいきます。

なぜ Ubie を選んだか?

何かを優先しようとすると何かに問題が出てくる、という葛藤が常にある医療業界において、政府の支援を得つつ、医師のみならず生活者が Win-Wn になるようなパラダイムを変える新機軸を作りあげようとしていることです。

更に付け加えると、それをやりきるための組織の土台作りに本気で取り組んでいること。この記事がとても参考になると思います。

スタートアップで、カルチャーが全く違う2つの組織を作った話|Ubie|note

50名規模の医療AIスタートアップUbie において、カルチャーや採用基準が全く異なる2つのチームを立ち上げ、数ヶ月運用してきました。スタートアップでは比較的珍しい取り組みで、採用応募者等からもよくご質問いただくので、背景やチームごとの違いをまとめてみました。 …

こちらの説明資料にもあるように、優れたサービスやプロダクトを開発するために必要な要素である Business – Technology – Creative に加えて、実際の医療現場にも立っている医師(Medical)も在籍しているため、高速でプロダクト開発を回せることも一つのユニークネスだと思ったからです。

Ubie といえば AI 問診ユビーがより知られていますが、もう一つの独自性でもある(僕のミッションでもあるのですが)生活者向けの AI 受診相談ユビーとのシームレスな連携も、これから実現したい世界にとって必要不可欠です。toC は2020年にローンチしたばかりで、これからグロースしていくビジネスです。伸び代しかないこのビジネスをドライブできるオポチュニティがあったことは、運命的な出会いだったと思います。海外事業も展開を開始しているのも、とても魅力的でした。

二つの大きな挑戦

まず一つは全く無知な業界のため、コミュニケションの基礎となる専門用語はもちろん、

  • 運不運の医療(医療不信)
  • 特定の診療科目や特定の地域での勤務医の不足
  • PHR の普及
  • デフレ経済を想定していない医療制度

などなど医療業界を取り巻く現状の圧倒的な理解です。そうしないとバッターボックスにさえ立てません。もちろん。

もう一つは PO としてのパフォーマンスの発揮です。Ubie にはプロダクトマネージャーは存在しません。Pivotal Labs で培ってきたプロダクトマネージャーとしての経験やノウハウは一旦箱の中に閉まい、この会社ではどのようなプロダクト・パーソンがベストフィットするのかを見定めたいと思います。セルフのためではなく、組織、ないしはプロダクトの成功のためなので、自身とのギャップを早期に発見することが先決です。

頑張ります。これからも、変わらずによろしくお願い致します。
ありがとう、Pivotal Labs。本当に恵まれた、いい会社でした。

最後に

もしこの記事を読まれて共に働きたい、Ubie で働くことに興味がある方はいずれかの手段でご連絡いただけると嬉しいです!

  1. 自分含むお知り合いの Ubie メンバーに声がけする
  2. Ubie Day (オンライン説明会)に参加する(お申し込みフォーム
  3. 直接応募する
  4. Ubie LINE アカウントにて、最新情報をチェックする(登録URL

採用職種一覧

プロダクトマネージャーとしての学び

Pivotal Labs で働いて4年が経とうとしています。本題に入る前に、Pivotal Labs という会社を知らない人が大半だと思うので、弊社のこちらのブログ記事に詳しく書かれていますので、ご参考ください!

Pivotal Labs はクライアントから依頼を受けて、ソフトウェアを開発しています。しかし、受託開発を行っているわけではありません。私達のゴールは、案件終了時にはクライアントが自分たちのみで持続的に良いプロダクト開発のプロセスを継続することができ、かつ新しいメンバーにその手法を教えることができる状態になっていることです。

Pivotal Labs のプロダクトマネージャーとしての経験は非常に貴重で、今後の自分のプロダクト開発との向き合い方を改めてくれたような気がします。この学びをプロダクト開発に携わる、主にプロダクトマネージャーのみなさんにご紹介したいと思い、この記事を書いています。この会社に入った当初は働き方含めてすべてが新しくて、軽いパニックになっていたのですが、その中でもとびっきりの学びをひとつだけ。それは「何を作るかよりも、何を作るべきではないのか、という視点に比重を置いてプロダクトを開発すること」です。

計画は信頼できなくなる

VUCA ー Volatility(変動性・不安定さ)、Uncertainty(不確実性・不確定さ)、Complexity(複雑性)、Ambiguity(曖昧性・不明確さ)時代の到来とよく言われています。様々な業界、業種、組織、文化をお持ちのクライアントとお仕事をさせていただいていると、本当にその通りかもしれないと実感することが多々あります。同僚とも話していて感じたのは、これまでの経営哲学は結果を予測可能にするために計画とコントロールを重視してきたが、変化の早さが最大の脅威となったとき、計画や予測は信頼しにくくなる、ということです。それはとても身近な問題として、表面化してきているように思えます。現に、PDCA について指摘されているこちらの記事はとても腹落ちしました。

PDCAが前提としているのは、あくまで “想定外のことが起きない” 世界。つまり、「常に安定しており、かつ心理や感情など人間的要素が関わらない環境」の中で継続的に改善を繰り返して品質を高めていくというシーンで使うのであれば、確かに有効なのです。しかし、“いつも想定外のことが起きる” “昨日と今日で状況が変わる” といった「先がまったく読めない」環境では、そもそも最初の「P(計画)」の立てようがありません。そこでPDCAにこだわりすぎると、かえって物事が前に進まなくなる原因にもなり得るのです。

そのため、新規事業であれ、新しい機能開発であれ、プロジェクトの上流で市場調査やユーザー調査の結果をもとにした要件定義に膨大なコスト(時間や予算)をかける傾向にあります。なぜなら、失敗するリスクを避けるためです。

ところが、時間の経過と共に変化の早さに対応することが困難となるため、後工程にしわ寄せが生じてしまい、プロダクト開発そのものがコントロール不能となってしまうという別のリスクが姿を現します。そのため、「この先の全体像が見えなくて不安」「どんなモノがいつできるかわからない」と言った心配が絶えなくなります。

プロダクト開発は賭けである

プロダクト開発は賭けのようなものです。それは避けられません。なぜなら、世に出さないとわからないことが多いからです。できることは、賭けを小さくして失敗するリスクを可能な限り低くすることです。

多少編集しましたが、ぼくが尊敬する上司の言葉です。ここで記載の失敗するリスクとは、ものを作るまでの時間に対して間違ってしまうものを作ってしまい、結果としてユーザーに使ってもらえないリスクのことを指します。小さな賭けで、小さな成功を積み重ねることが、現代のプロダクトにおける生存戦略なのかもしれません。

Pivotal Labs は、Lean XP という開発手法を用いて上記の実現をサポートしている会社です。そのような働き方を4年も続けていると、自分の中でプロダクト開発に対する価値観が変わっていることがわかりました。これまでは、誰に何をどのようにプロダクトやサービスを届けるべきなのかを強く自問しながらプロダクトデザインやプロダクト開発に携わってきました。

ところが、Pivotal Labs のミッションである『Transforming How the World Builds Software(世界中のソフトウェア開発そのものを変革する)』を体現するためのアプローチや手法を学んでいく中で、徐々に自分のとってのプロダクトマネジメント論が確立されていきました。

 

ぼくが考えるプロダクトマネジメントとは、仮設検証という小さな賭けを繰り返しすることで「つくるべきではないもの」は何かという学びを最大化し、失敗による被害を最小限に留めてプロダクトを成功させること。そして、実現に向けてチームの強みを活かしながら、ユーザーに価値を提供し続けることができるような組織文化を浸透させること。

 

プロダクトマネージャーの Job Description(職務内容)は様々で十人十色ですが、ぼくが大切にしているプロダクトマネジメントはこの通りです。今の会社には、本当に感謝しています。

何を作るべきではないのかを考える

話を戻しますが、Lean XP の実践的なアプローチやマインドセットはこれまでのブログ記事などでもご紹介していきましたが、本質にあるのは「何を作るかよりも、何を作るべきではないのかに比重を置いてプロダクトを開発すること」です。世の中的にみても、同じ思考に傾いてきている気がしなくもないです。

当時話題になった、Microsoft Work 2000 の UI

当時話題になった、Microsoft Word 2000 の UI

よくあるプロジェクトのケースだと、要件をできるだけ盛り込み、完成形と呼ばれるアウトプットが始めに描かれることが多く、あとはその実現に向けて「どう作るか」という思考のみが働き、約束という名の計画が練り上げられていくことが多いようです。

ここでの落とし穴は2つあります。

  1. 一度決めたアウトプットに対して疑いを持たなくなること(持つことができないこと)
  2. 計画通りに行かないとコントロール不能になり炎上すること

Lean XP ではこの落とし穴にはまらないように、開発をしながら先行してユーザー調査を繰り返し、想定されるアウトプットに対しての評価を元につくるべきではないもの(機能含む)を特定し、排除すること&新たなる課題やソリューションの種を拾いながら検証済みのモノを開発します。結果として、より良いモノが生まれやすくもなります。

下記のアーミーナイフの図がとてもわかりやすいです。右が必要だと考えている最終形のアウトプット、左は実際にユーザーが求めている理想的なモノの対比です。

Copyright (c) Anton Nikolov 2017

つまり、先に作る予定のモノは、必要であることがわかっている物のみに絞られていきます。これを次々と繰り返すことで、何を作るべきか、必要なもののみを積み上げた理想形に近づけることができます。

どう作るかにプロダクトの運命を委ねない

完成形は存在しないと思っています。それは、サービス提供者側が勝手に考えたアウトプットにしか過ぎません。重要なのは、ユーザーが頭に描いているアウトプットなのではないでしょうか。

生活様式が変わったり新しいサービスが次々と登場する世の中において、変化が早いのは当然だと思っています。そして、計画や予測は信頼しにくくなるのは当たり前だと思っています。だからこそ、賭けに出る姿勢(アプローチ)が必要なのです。

Lean XP は奥が深く、現代に求められている開発手法だとは思いますが、他の開発手法と比べて最も優れているとは思っていません。そう言ってしまってはもともこうもありませんが、プロダクトの運命を「どう作るか」に委ねるのではなく、「何を作らないで、何を作るべきか」に全ては掛かっているのです。

最後に…Pivotal Labs Tokyo ではプロダクトマネージャーを募集しています(2020年8月時点)もしご興味があれば以下のリンクよりご応募いただくか、このサイトのコンタクトフォーム経由でぼくの方までご相談ください!お待ちしてます。

Product Manager: Pivotal Labs (VMware Tanzu) in Tokyo, Japan | main

プロダクトマネージャー Product Manager (Pivotal Labs) VMware Pivotal Labsについて1989年に設立されたPivotal Labsは、数々の大手企業に対してアジャイル型ソフトウェア開発のコンサルテーションを提供してきました。2019年にはVMwareの一部となり、今後はそのビジネスをさらに拡大、加速させていきます。 求める人材 …

プロダクトやサービス開発における様々なズレを解消するためのフレームワークの一つとして「キャンバス」があります。この記事を読まれている方であれば一度は耳にしたことがあるかもしれませんが、Business Model Canvas(ビジネスモデル・キャンバス)Lean Canvas(リーン・キャンバス)などが有名です。キャンバスは、複雑な情報を一枚絵に構造化してわかりやすくしてくれているので、意思決定を加速させてくれる非常に便利なツールです。

他にはどんな便利なキャンバスがあるんだろう?と興味本位で2〜3年かけて情報収集をしてみたところ、約200種くらいありました。時代の変化と共にインスピレーションを受けながら増えていったことを想像すると、多分もっとあるでしょう。それらは自身の Pinterest でコレクションとして今も集めています。キャンバス集めは、もはや趣味です。

その中にはあまり知られていないけれども、あらゆる課題を解決してくれるキャンバスが沢山埋もれています。ただ、あまりにも数が多いので、今回はその中でも自分の中でヒットだった5つのキャンバスをご紹介したいと思います。

  1. Social Media Strategy Canvas(ソーシャルメディア戦略・キャンバス)
  2. The Brand Canvas(ブランド・キャンバス)
  3. Team Canvas(チーム・キャンバス)
  4. Project Canvas(プロジェクト・キャンバス)
  5. Workshop Preparation Canvas(ワークショップの企画のためのキャンバス)

それでは一つ一つ見ていきましょう。

1. Social Media Strategy Canvas

ソーシャルメディアは今となってはビジネスにとってクリティカルな、かつゲームチェンジャーともなり得るマーケティングチャネルです。なぜなら、ソーシャルという文字通り、自社とクライアントやユーザーを繋ぐ大事な接点となっているからです。プロダクトマーケティングの観点からも、PSF(Product-Solution Fit)を探る上で重要な役割を果たします。

Social Media Strategy

Copyright © 2015 Marketing Solved

  • どのソーシャルメディアから始めればいいかわからない
  • どれが相性がいいのかわからない
  • 何を投稿すればいいかわからない
  • 以前かじったことがあるけれど、うまくいかなくて辞めた

このキャンバスは、上記のような身近な課題をシンプルに解決してくれます。プライベートではソーシャル・ネットワーク・サービスを使い倒しているけれども、事業戦略の位置付けでいざ初めてみるとなると、どうしたらいいかわからないときがあります。僕自身も以前 Facebook マーケティングをやったことがありますが、四苦八苦してしまい、今これがあったら便利だったんだろうな、と思いました。

このキャンバの考案者によると、3ヶ月もすれば効果が見え始めるとのこと。Twitter のフォロワーが何千人増えたとか、ソーシャルメディア経由の収益をデイリーで挙げることができた、とかとか。

キャンバスにまとめられている項目一覧:

  • ユーザー情報(デモグラに加えて、好むブランドや興味など)
  • 月間目標(何を達成したいか、何をPRしたいか)
  • 目標を達成するための月次・週次・日次タスク
  • 投稿する内容やコンテンツ
  • 投稿するタイミング(過去のデータを元に最適化)
  • 投稿する頻度
  • 投稿先のプラットフォーム

テンプレートのダウンロード:

How To Create a Fail Proof Social Media Strategy That’s Simple and Gets Results – Marketing Solved

If you’ve decided it’s time to get serious about social media, I’m here to tell you – YES, it is time! Social media has been a real game changer for businesses and for one reason, it’s SOCIAL. It really is the connection between you and your future clients.

2. The Brand Canvas

ブランド戦略という言葉を耳にすることがありますが、ブランドの範囲がかなり広いため、どのようなアクションが求められ、実行されるべきなのかイメージが湧かないときがあります。

ブランドと聞くとロゴ、つまりは CI を真っ先に想起しますが、モノよりもコトの時代となった今、Apple Watch に代表されるようにシンボルだけではなく、人の生活をより豊かにするためのストーリーであったり、人々の生活に根付いたコミュニケーションが求められます。

Lean Branding Canvas

Copyright © IGNITION Framework

このキャンバスは、それらを構成する要素を細かく分解して一つのブランドを作り上げることができると思います。ガイドラインに等しい項目もあるため、デザイナーやマーケティングの部署と協業しながら埋めていくといいかも?

キャンバスにまとめられている項目一覧:

  • ストーリー
    • プロダクトが置かれているポジション(インセプションデッキのような扱い)
    • 顧客への約束ごとを一言で
    • ブランドを擬人化した時のパーソナリティ
    • ペルソナ
    • ストーリーボード(ソリューションがユーザーの目標をどのように助けるか)
  • シンボル
    • タイポグラフィ
    • カラーパレット
    • ロゴ
    • 使用する画像
  • 戦略
    • 認知度向上のための施策(チャネルやコンテンツなど)
    • 収益につなげるための施策
    • マイルストーン(メッセージを発信するタイミングなど)
    • 継続的なコミュニケーション手段(シェアの促進など)

テンプレートのダウンロード:

The Brand Canvas – How To Create and Communicate A Compelling Brand – Ignition Framework

Why does Apple’s brand mean so much to so many people? How is it that they seem to sell their products almost effortlessly while other manufacturers are constantly clamoring for our attention and we give them no heed? When it comes to innovation, invention is only half of the equation.

3. Team Canvas

チームワークはプロダクトの成功を左右します。

全社のミッションやプロダクトの戦略を共有することはチームのコミュニケーションを円滑に進めるために、最低限必要であることは誰もが認識していることだと思いますが、実は普段会話しない内容がチームワークを良くする上で大事だったりするのではないでしょうか。これは僕の経験なのですが、個人には強みや弱みがあり、やりたいこととやりたくないことがあり、それを理解せずに進めてしまうと本当のチームとして機能(ワーク)しないことがあります。僕自身もやりたくないことがあるので、それは周囲に明示するようにしています。

Team Canvas

Copyright © 2015 The Team Canvas

そこで目に止まったのが「Team Canvas」です。これはワークショップ形式で、約1時間ほどかけてチーム全体でまとめると効果的だそうです。結構踏み込んだ会話が求められるので、アイスブレイクも兼ねて進めるといいかもしれません。

キャンバスにまとめられている項目一覧:

  • チームメンバーと役割
  • チーム共通のゴールと個人としてのゴール
  • 目標を達成するために活かせる強みやソフトスキル
  • チームと個人の弱みと直面しうる課題
  • チームとしての行動規範
  • 個々のニーズやチームへの期待
  • チームが大切にすべき価値
  • 目的(なぜしているのか、何をしようとしているのか)

テンプレートのダウンロード:

Learn about Team Canvas – Team Canvas

Years of observing, leading and consulting small teams made us realize that it’s not the lack of knowledge that makes effective teamwork so hard. It’s the hard questions themselves that are not being asked at the right time.

4. Project Canvas

「Project Canvas」は、プロジェクト全体におけるコミュニケーションをシンプルに、そして明確にするためのキャンバスです。プロジェクトのキックオフや、プロジェクト途中のチェックイン、そして振り返りの際に利用することを想定されています。インセプション・デッキと重複する要素はあるものの、正式文書ではなくビジュアル化することで、相互理解を促すことができるのでいいなと思いました。

Project Canvas

Copyright © 2016 Project Canvas Creators

これも自身の経験ですが、過去のプロジェクトではこのキャンバスと似たような項目をワークショップを通じて外部化したものをプリントして、壁に貼り付けたりしました。データとして格納するよりも、目に見えるところにあるとプロジェクト中に迷子になりづらいので、おすすめです。また、希かもしれまぜんが、複数のプロジェクトにアサインされている状態の場合、より効果が発揮されるかもしれません。

キャンバスにまとめられている項目一覧:

  • プロジェクトの目的
  • プロジェクトのスコープ
  • 成功指標(プロジェクトの成功を定めるための指標)
  • 主要なマイルストーン
  • 主なタスク(やるべきこと、方針など)
  • アウトカム(最終的に成し遂げられるもの、成果)
  • チームメンバー
  • ステークホルダー
  • ユーザー
  • リソース(予算など)
  • 制約事項(外的要因による弊害など)
  • リスク

テンプレートのダウンロード:

Project Canvas – Visual project communication and overview

Project Canvas is made by project facilitators and project management professionals, who seek to simplify the challenge of project communication – before, in and after project execution: project kickstart: pitching and project initiation. project overview: project briefing and status. project management: task assignment and project progress.


5. Workshop Preparation Canvas

過去にワークショップを企画並びに実施した経験はありますか?

その時その時の関係者を巻き込みながら、プロジェクトを効率的に進める上で様々なワークショップを開くことがあります。ワークショップの落とし穴は、ただ楽しいで終わってしまわないことです。楽しいのはいいことなのですが、目標が達成できたかどうかがワークショップの成功を判断する上で重要となります。このキャンバスでは、ワークショップを成功させる上で必要な「6つのP」をまとめてくれています。

Workshop Preparation Canvas

Copyright © 2018 Toby Sinclair

ロジスティックな部分など、基本中の基本についての明記を促していますが、疎かにしてしまうことがたまにあるので埋めておいて損はなさそうです。

キャンバスにまとめられている項目一覧:

  • Purpose(目的、なぜやるのか?)
  • Practicalities(いつ、どこでやるのか?どのようなセットアップでやるか?)
  • Participants(参加者はだれか?各人のニーズは何か?)
  • Products(事前に準備すべきものは何か?題材は何か?)
  • Process(アジェンダは何か?)
  • Principles(どのように意思決定が行われるか?ワークショップの価値は?)

テンプレートのダウンロード:

Workshop Preparation Canvas

“Give me six hours to chop down a tree and I will spend the first four sharpening the axe.” ― Abraham Lincoln I have run many workshops and by far the most important part to a successful workshop is the preparation. From my experience a one day workshop requires at least three days preparation and maybe…

番外編:ユニークなキャンバス2選

以上、キャンバス・コレクターの僕がオススメする5つのキャンバスでした。本当はもっと紹介したいのですが、たださえ長い記事なのに、更に長くなってしまうので最後に2つだけ、番外編としてとてもユニークなキャンバスをご紹介します。もはやプロダクトやサービス開発に関係がないかもしれませんが、悪しからず。

Negotiation Canvas(ネゴシエーション・キャンバス)

誰かとネゴシエーション(交渉)するときに、自身の考え方を整理するのをサポートしてくれるキャンバスです。みんながハッピーになり得るアイディアを複数考え、上手くいかなった時の対処法まで考えるというバックアップ付き。

Check out Negotiation Canvas, a free workshop template!

One-page tool for success in any negotiation.

Life Canvas(ライフ・キャンバス)

その名の通り、人生について考えることができるキャンバスです。自身のビジョンやスキルが世界のニーズとマッチしているかどうかを測るために活用することができますが、今話題の Ikigai についても触れられているので個人ワークでやってみる価値はありそうです。

The Life Canvas

The Life Canvas is a framework that provides a simple, visual method of defining, understanding, and utilizing your unique capabilities and desires to build the future of your dreams.

まとめ

こうやって一つ一つのキャンバスに目を通してみると、キャンバスというフレームワークはとても奥が深いです。

今回のように、高度な思考技術によって整理された構造をリバースモデリングすることで、意図が汲み取りやすくなり自分自身の頭の整理にも役立ちます。また、いざ埋めようとしても、埋められない項目があったりします。つまりそれは、情報が欠落しているということです。欠落しているということは、失敗する可能性があるということです。キャンバスのいいところは、一枚絵にすることで、欠落した情報を見逃すことができないところだと思います。

一つでもいいので、試しにやってみませんか?

もし、微妙だな〜と感じられた方がいれば、実用性が比較的高い以下のキャンバスから始めてもいいかもしれません。実際にやってみましたが、難易度は高めです。

はじめに:Xデザイン学校とは?

Xデザイン学校とは、UX、UCD、デザイン思考、サービスデザインなどを軸としたデザインの学びと研究を推進する社会人向けのデザイン学校です。今年で4年目に突入しています。詳しくは「Xデザイン学校2020年コースカタログ(pdf)」を見ていただきたいのですが、Xデザイン学校ではスキルや目的に応じて計6つのコースに分けられています。

  1. ベーシックコース:UXデザインの基礎を学ぶ(申込受付終了)
  2. マスターコース:実践的なUXデザインを身につける(申込受付終了)
  3. アドバンスコース:プロフェショナルスキルや研究スキルを探求する(申込受付終了)
  4. ビギナーコース:初めてUXデザインを学ぶ
  5. リーダーコース:UXデザインのリーダーを目指す
  6. パーソナルコース:個人や3人程度のグループで学ぶ

その中でも (5) のリーダーコースは昨年新設されたばかりの、出来立てホヤホヤのコースです。私は昨年度に続き、本年度のリーダーコースの講師を僭越ながら務めさせていただくことになりました。お声がけいただいた山崎先生に感謝です。

リーダーコースの募集は既に開始しており、7月25日が締め切りとなっています。本年度は COVIDー19 の影響で、全てオンラインでの実施になります。

Xデザイン学校2020年リーダーコース(オンライン)募集

Description ■リーダーコースの紹介UX/サービスデザイン、デザイン思考の活用、リーダーシップ、チームワーク、ファシリテーション、ワークショップ、デザインマネジメント、組織のデザイン、ビジョンデザイン、アート思考、などを学びます。月に2回、平日の夜に講義・ワークショップで、講師と受講者の対話を通じて学びを深めて行きます。講座修了後は、X …

この記事では、Xデザイン学校、特にリーダーコースを受講しようか悩んでいるけど、もう少しイメージを掴みたいと思っている方向けに、非常にざっくりではありますが、私のセッションの様子を掻い摘んでご紹介しますので、ぜひ検討材料としてお使いください!

なぜ、リーダーコースが必要なのか?

発端は、私とコンセントの大崎さん、そしてXデザイン学校の共同代表・山崎先生と座談会をしていたときでした。経済産業省がこの春に公開した「高度デザイン人材育成ガイドライン」にて、ビジネス現場での高度デザイン人材のイメージでも示されているように、

  • デジタルトランスフォメーションへの対応の必要性
  • ビジネス価値の優先度の変化
  • VUCA時代における社会の変化

これらのデザインを取り巻く状況の変化から、リーダーシップが今後のデザイン人材に必要であることが語られるようになってきました。

経済産業省:高度デザイン人材育成ガイドライン 概要版

自分もまだまだ未熟なのですが、みんなで学び合う実験の場として、やってみよう!となったのがリーダーコースが誕生したきっかけです。

一部セッションのご紹介

コンセントの大崎さん、富士フィルム(Open Innovation Hub館長)の小島さん、Xデザイン学校の山崎先生と試行錯誤した結果、2019年度のリーダーコースでは、私は以下のプログラムを提供させていただくことになりました。

  1. チームビルディングとフィードバック
  2. リーダーシップとファシリテーション
  3. チームワークと意思決定のプロセス

非常に好評だったため、本年度も基本は昨年のを踏襲する予定です。一部いいフィードバックをいただけたので、本年度はもうひとつのコンテンツを追加予定です!

冒頭でも言いましたが、受講しようか悩んでいるけど、もう少しイメージを掴みたいと思っている方!非常にざっくりではありますが、私のセッションの様子を掻い摘んでご紹介しますので、ぜひ検討材料としてお使いください。基本は同じチームで活動を共にしていきます。

チームビルディングとフィードバック

自社に持ち帰ってすぐに適応できる、チーム力を上げるためのアクティビティを実施しました。主にチーム内のコミュニケーションを促進させることが目的です。基本、全てのセッションは同じチームで作業をしていきます。

実施したアクティビティ例:プロジェクトのチームヘルスチェック

医者が患者を診断するかのように、変化に対応できる強いチームをつくるため、チームの「今」の健康状態を測り、調子が悪いところの原因と解決策を話し合います。

リーダーシップとファシリテーション

このセッションでは、チームを導くデザイナーとして求められる、ファシリテーションの重要性とそのテクニックをご紹介しました。

ファシリテーションと一概に言っても、具体的に何をどうするのでしょう?ある程度の型がないと、例えば「ファシリテーションをお願いしてもいい?」と言われても手こずってしまいます。

私が考えるファシリテーションの基本形は以下だと思っています。

  1. アイディアを発散する
  2. 情報を整理する
  3. 優先順位を設定する
  4. 意思決定をする

これに沿って、チームを導くことが大事なんだと思います。

チームワークと意思決定のプロセス

最終回では、チームで効率的に意思決定を繰り返しながらプロジェクトを成功させるためのアプローチをご紹介しました。事前課題として、新しいサービスまたはコンセプトを考えていただき、それに対してプロダクトやサービスを成功させるために、最もリスクのある思い込みを特定していきます。

その後、ある手法(お楽しみ)を使って優先度付けを行い、検証をするための実験を計画してもらいました。いつ、どこで、どんな実験をして、何を得たいのか。これは、プロジェクトチームでプロダクトやサービスを成功させるために必要なアプローチだと思います。

最後に

私が考える、優れたリーダーが大事にしていることは以下かな、と考えています。

  1. チームの心理的安全性を担保し、自身の考えを自由に発疹し、共有できるチームにする
  2. 公正性を大事にし、誰が主張するものであれ、最高のアイディアを求め続ける
  3. すべてを一度にできないという前提のもの、優先度を徹底して一つ一つクリアにする

これに従って、コンテンツを組みました。なかなか盛り沢山で準備が大変でしたが、セッション後に毎回のように懇親会があるのですが、その場ですぐ感想を聞けたり、以前やってワークショップをやってみました!と言ったフィードバックをいただけるのは本当に嬉しく、自分自身にもプラスになっています。

大崎さんや小島さんのセッションも拝聴させていただきましたが、どれもクオリティが高く、完成度がとても高いです。ここまでUXデザインやサービスデザインを、多角的にビジネスの側面から捉える学びの機会はあまりないと思います。

ぜひ、新しい学びを体験してみませんか?

Xデザイン学校2020年リーダーコース(オンライン)募集

Description ■リーダーコースの紹介UX/サービスデザイン、デザイン思考の活用、リーダーシップ、チームワーク、ファシリテーション、ワークショップ、デザインマネジメント、組織のデザイン、ビジョンデザイン、アート思考、などを学びます。月に2回、平日の夜に講義・ワークショップで、講師と受講者の対話を通じて学びを深めて行きます。講座修了後は、X …

はじめに

仮説検証学習サイクルを可視化するためのツールを「Experiment Board」と呼んでいます。2年ほど試行錯誤を重ねましたが、今は納得して運用することができているので、世のプロダクト開発をよりよくするためにも、参考になるかわかりませんが公開したいと思います。

なぜ、この Experiment Board が必要だと思ったのかと言うと、過去にこんな悩みがあったことがきっかけでした:

  • ユーザーリサーチの際に、過去の質問や検証内容と重複してしまうことがあって、時間の無駄だと思った
  • どこまでが未検証で、どこまでが検証済みだったかわからず、迷走することがあった
  • 価値ある学びやインサイトが多くあった場合に、まとめて管理したり記録する方法がわからなかった
  • 仮説検証学習のために実験を繰り返す習慣を身につけたかった

これらのモヤモヤを解消してくれたのが、Experiment Board でした。根底にあるのは、リーンスタートアップの「Build-Measure-Learn」のフィードバックループです。

Learn:思い込みや仮説、Build:実験、Measure:検証可能な指標

この図の通り、実験(Experiment)を通しての仮説検証の結果から得られる学びを切り取り、形式化することが鍵となります。

なぜ、実験なのか?

上記で「実験」という言葉を使いました。科学のように、仮説を検証するために積み重ねる実験は、正にプロダクト開発においても同じだなと思います。なので、仮説検証学習サイクル=実験と呼んでいます。

なぜ実験が必要かというと、プロダクトを開発する上で最も高いリスク、それはユーザーに使われないものを作ってしまうリスクを可能な限りなくすためです。リスクを低減するためには、早期に「いま」検討中ないしは開発中のプロダクトを試すことが重要であり、同時にその行程を管理し、修正していくことです。

あと、「リリースをする」という表現よりも「実験をする」と言い換えたほうが目的が明確で、意思決定のスピードや検証サイクルも早くなる気がします。心理的構えもなくなるので、安定します。

なにを、検証するのか?

左が課題の優先順位付を行う「2×2」、右が Experiment Board です

実験をはじめる前に、答えるべき問いを設定します。この問いに対する解を得るために、実験をします。問いは多きく分けて2つのカテゴリに分類することができます。

  1. ユーザー&課題
  2. プロダクト&ソリューション

(1)については、

  • 実際にユーザーは存在するか?
  • 解決「すべき」課題か?

などが代表例です。これらの問いに対する解を見出すことができれば(2)に進みます。

  • ソリューションは課題を解決するか?
  • 使いやすいか?

などが代表例です。これらの問いを検証可能な仮説に落とし込んで実験することで、以降はより詳細な仮説検証学習サイクルに進むことができます。仮説の設定方法については過去のエントリーが参考になると思います。

仮説駆動型UXデザインのススメ | mariosakata.com

先月末に NIJIBOX 主催のイベント …

どのような、流れで行うか?

プロダクト開発手法に左右すると思いますが、私が慣れ親しんでいるアジャイル開発では、イテレーションごとに以下の流れで実験を行っています。

イテレーションごとの流れ:

  1. 問いの設定
    ユーザー&課題について?プロダクト&ソリューションについて?
  2. アサンプションを洗い出す
    最もリスクが高い思い込みは何か?
  3. 仮説化する
    検証可能な仮説にする
  4. 実験方法を考える
    何を検証するためにやるのか?どのようにやるのか?
    例)ペーパープロトタイプ、ABテスト、ランディングページ、インタビューなど
  5. 実験する、試してみる
    どれくらいの期間やるのか?何人に対してやるのか?
  6. 結果を測る
    仮説は検証できたか、間違っていたか?
  7. 振り返って学びをシンセサイズ(統合)する
    何を学んだか?
  8. 繰り返す

実験は繰り返すものです。次に何を検証しようと悩んだ時には、以前ご紹介した「2×2」というフレームワークを取り入れてみるといいかもしれません。

2軸で考えるプロダクトデザインの シンプルな意思決定方法

9月上旬に、 UX MILK 主催の「 UX MILK Fest 2019」という大きなイベントに登壇させていただく機会がありました。「2軸で考えるプロダクトデザインのシンプルな意思決定方法」と題した当日のセッションでは 「2x2」という手法をご紹介しました。セッションでお伝えしたかったのは、この手法を取り入れることで、様々な角度から軸となる考え方を UX …

Experiment Board の例

先ずは準備です。実験を進めるための必要項目を記載していきます:

  • フェーズ(実験の回数やプロダクトのライフサイクルなど)
  • ペルソナ
  • 期待する成果(アウトカム)
  • 検証したい仮説
  • 実験方法
  • 成果指標(Key Result)
  • 学び

Google が主催したイベントに登壇した際にも紹介した、Experiment Board の事例です。ちなみにこれは、実際に Zappos が実践した実験そのものです。多少編集しています。

  • フェーズ:Beta
  • ペルソナ:レイシーさん
  • 期待する成果:ユーザーはいつでもどこでも靴を買うことが出来る
  • 検証したい仮説:ユーザーはオンラインで靴を買いたいだろう
  • 実験方法:オズの魔法使い
  • 成果指標(Key Result):50%のユーザーは一足以上の靴を買う
  • 学び:女性はドレスにあう靴をオンラインで購入する傾向にある

仮説があっていたかどうか、また指標が達成できたかどうかをステッカーを使って管理してたりします。赤はアラートなので、やり直す必要があるのか、そもそも辞めるか、といった決断をする材料となります。

Experiment Board の導入によって、いつ、誰に対して、何のために、そしてどのような実験をするのか?そして、その結果はどうだったか?この一連の問いをこの順番で可視化することで、論理的に物事を考えることができ、情報の整理が容易になりました。

仮説検証学習サイクルも回り続けます。

上記が一応テンプレートのような役割を果たしていますが、ホワイトボードに縦に貼り付け、その横に実験ごとの結果を記録していくだけでも済みます。実験の回数が多くなってきたら、エクセルでもいいので、デジタルに移行することをオススメします!

まとめ:やってみてよかったこと

インサイトや学びの抽出がしやすくなった

可視化のメリットはやはり大きいです。特に、今回ご紹介したようにホワイトボードなどを用いることができれば、何が検証できて、何が間違っていたのか、どのような学びがあったのかを項目ごとにすぐに確認することができるので、取りこぼしが減ったように思います。

次のアクションに繋げやすくなった

学びはチームを前進させてくれます。普段であれば、見ていないところや諦めているところをすくい上げて、新しい価値を見出すこともできます。他にも、ターゲットユーザーのアップデートであったり、課題の優先度の変更といった本質的な議論が展開されるようになります。それは、中長期的に見るととても有益な情報だったりします。

過去の実験がまとまっていることで自信がつく

プロダクト開発では、生産性に直結するアウトプットに注目することが多いです。でも、Experiment Board のようにこれまで実験した回数であったり学びの数が可視化されていると、それだけ良いプロダクトに向けて突き進んでいることがわかり、一人一人の自信につながり、チームの士気も上がります。このような質的なイニシアティブが得られることも、メリットの一つです。

早い段階でいくつかの仮説や思い込みが間違っていたことがわかる

最もリスクが高い思い込みを優先して検証可能な仮説に思い込み、実験によって検証することで、それがあっていたか間違っていたかを測ることが Experiment Board の目的です。一つ一つ潰すことで、安心感が得られるのも、いいところです。

全ては、実験です。このフレームワークの導入も、実験です。導入コストは圧倒的に低いので、ぜひやってみてください!

なぜ、ホロクラシーは注目されるのか?

突然ですが、Holacracy(ホラクラシー)という言葉を耳にしたことはありますでしょうか?

日本ではまだ参考文献が少ないためご存知の方は少ないかもしれませんが、サービスデザインないしは組織デザインのための学習の一環として調査し、記事にまとめてみました。

Wikipedia によると、ホラクラシーとは従来のようにトップダウンのヒエラルキーによって意思決定がなされるのではなく、組織全体に権限を分散させ意思決定させることで、自走する組織を保つための社会技術または組織のガバナンス・マネジメント方法と定義されています。

Holacracy is a method of decentralized management and organizational governance, in which authority and decision-making are distributed throughout a holarchy of self-organizing teams rather than being vested in a management hierarchy. Holacracy has been adopted by for-profit and non-profit organizations in several countries.

Hierarchy vs Holacracy

企業、NPO 問わず今ではアメリカを始めフランスやドイツ、オーストラリア、イギリスで導入実績があるとのことですが、有名なところでは Airbnb、Zappos、Medium が導入例として紹介されることが多く、日本でも一部記事によって紹介されています。

「このホラクラシー、元はと言えばソフトウェア会社で開発のために考えられた、昔ながらの上から下に命令を下す形態を、「自律したサークル」のようなものに置き換えた形です。理論的には、このシステムを導入することにより、社員は会社の経営に関してより発言権を持つようになります。根本的には、ホラクラシーは、「人」中心ではなく、「やらなければならない仕事」を中心に、会社を組織するのが目的です。その結果、社員には肩書きが必要なくなったのです。社員は、明確な目的を持っていくつかの職務を担当します。1つのチームや部署で働くのではなく、大抵は複数のチームの一員として、それぞれの場所で特定の役割を果たします。」「このホラクラシー、元はと言えばソフトウェア会社で開発のために考えられた、昔ながらの上から下に命令を下す形態を、「自律したサークル」のようなものに置き換えた形です。理論的には、このシステムを導入することにより、社員は会社の経営に関してより発言権を持つようになります。根本的には、ホラクラシーは、「人」中心ではなく、「やらなければならない仕事」を中心に、会社を組織するのが目的です。その結果、社員には肩書きが必要なくなったのです。社員は、明確な目的を持っていくつかの職務を担当します。1つのチームや部署で働くのではなく、大抵は複数のチームの一員として、それぞれの場所で特定の役割を果たします。」- 「すべての階級を廃止」米Zappos社が導入した組織管理システム「ホラクラシー」は成功するか?

ホラクラシーの浸透によって、組織が本来どのように構造化されるべきか、どのように意思決定がなされるべきか、どのようなガバナンスレベルが行き届くべきかを改めて見直し、変化を受け入れる組織へシフトするきっかけが生まれるのではないでしょうか?

いまでは Google や Microsoft のような巨大企業で働く従業員も、企業が益々組織的になっていくことに嫌気が差し、スタートアップに転職するケースが増えていると聞きますね。多くの大企業もホラクラシーに注目している理由の一つかもしれませんね。

従来の組織構造 (c) HolacracyOne, LLC

ホラクラシーの歴史

2007年に Ternary Software とうソフトウェア会社の創設者である Brian Robertson 氏がまとめた公文書(Robertson, Brian (June 2007). “Evolving Organization”. Integral Leadership Review 7)によって浸透したと言われており、元々の語源は1967年に Arthur Koestler 氏の著書「The Ghost in the Machine」で提唱されたホラーキー(holarchy)から来ており、ギリシャ語の holos(Whole / 全体)が由来となっている。ホラーキーは独立独行でありながらも全体の一部であるという認識のもと、全体を司る一部でありながらも独立した一部である、という双方の機能を保持していることを意味します。

The Ghost in the Machine

The Ghost in the Machine is a 1967 book about philosophical psychology by Arthur Koestler. The title is a phrase (see ghost in the machine) coined by the Oxford philosopher Gilbert Ryle to describe the Cartesian dualist account of the mind-body relationship.

ホラクラシーはイテレーティブ(反復)な組織運営や適応プロセス、自律組織などのキーワードで説明することができますが、その根底にはアジャイル開発やリーン生産方式の思想が根付いていることがわかります。開発手法だけではなく、組織にも柔軟性が求められている現代には特にフィットするのではないでしょうか?

ホラクラシーの主要原則

前述した Robertson氏がまとめた公文書は、今では彼が所属する HolacracyOne の公文書として発表されておりますが、ここでホラクラシーの原則をいくつかご紹介したいと思います。

Holacracy Constitution – Holacracy

Version 4.1 This “Constitution” defines rules and processes for the governance and operations of an organization. The “Ratifiers” are adopting these rules as the formal authority structure for the “Organization” specified upon the Constitution’s adoption, which may be an entire entity or a part of one that the Ratifiers have authority to govern and run.

活発化する役割

ホラクラシーにおける組織構造の幹となるのが、役割です。ホラクラシーには役割と、その役割を更に活発化させるための「エナジャイザー」の存在が不可欠であり、自身の言葉でキャパシティやポテンシャル、機能すべき役割や期待できる結果を表現できるように促さなければなりません。まるで上下がない、団体スポーツにおけるポジションのようです。役割は、肩書きや職種のことではありません。ひとりが複数の役割を担うことも可能になるということですね。

下記の円型組織に表示されている小さいひとつひとつの円は、人を指しています。詳細を確認すると、役割と決定権限がある内容の一覧等が組織内で明確になっていることが分かります。再度言及しますが、記載されているのは役割であり、肩書きや職種ではありません。そのため、複数の役割を保持している人が複数名か存在するものの、役割上の重複が見られないことが特徴です。

(c) HolacracyOne, LLC

円型の構造

ホラクラシーとカテゴライズされる組織構造は、バラエティに富んだ役割が円型のように構成される自律組織です。ひとりひとりが創造し、実行に移し、評価するためのプロセスを常に保てるようにしなければなりません。円型の組織では自身で組織運営に向けた会議を実施し、役割を新たに設け、メンバーを選発するなどの取り組みを自己責任のもと遂行します。円型の組織ではひとりひとりの役割のリンクが重要です。

ガバナンスの強化

上記の通りで、円型組織は複数存在する場合もあります。それぞれに生まれる円型組織では独自で定義すべき組織運営のためのガバナンスを周囲の役割や方針に従って定めていく必要があります。ホラクラシーではすべての円型組織を統合した意思決定の方法論を用いることで、多種多様なインプットをそれぞれの円型組織から自動でかつ効率的に入手できるようになります。

オペレーションのプロセス

ホラクラシーにおける組織運営では、様々なオペレーション上のニーズに応えるべくそれぞれの円型組織のメンバーが自身の役割を果たすために効率的に、かつ協働的に運用されるべきです。そのため、会議においても意思決定権がひとりひとりに分散されているため、会議が効率的に開催されることが特徴として挙げられます。

ホラクラシーは未発達?

但し、ホラクラシーはいいことばかりではないようです。

昨年に独自のマネージメントやリーダシップ論を提唱している Steve Denning氏を発端とした反論も生まれてきています。そのひとつに、アジャイル開発やリーン生産方式をモチーフにしているホラクラシーモデルには顧客視点が不足していると指摘しています。

Making Sense Of Zappos And Holacracy

“Zappos Says Goodbye To Bosses,” was the recent headline in the Washington Post. “Zappos is going holacratic: no job titles, no managers, no hierarchy,” wrote Aimee Groth in Quartz. “Gurus Gone Wild” wrote my fellow Forbes contributor, George Anders. And also Paul Hebert: “A new word crept into HR’s vernacular last week: holacracy.

すでにホラクラシーを導入している有名企業のひとつに Zappos 社などがありますが、Zappos 社は創設時よりすでに顧客中心の組織であったが故に成功していると考え、顧客中心の発想が根付いていない組織には専属部隊の欠如により不向きなのではないか、と加えています。

あくまでもひとつの反論ですが、ホラクラシーの商標登録をしている HolocracyOne ではそれぞれの指摘に対する意思をブログで表明しています。また、既に導入している企業と連携することにより、未だ歴史が浅いホロクラシーの更なる進展を目指しているようです。

Holacracy Blog – Holacracy

Holacracy® is hard. Learning Holacracy is like learning a new language. You may pronounce some of the words you learn pretty well the first time, but you need to hear the words spoken correctly, see them used in context, and practice using them yourself, many times over, in order to learn the language well enough to truly leverage it.

従来のマネジメント体系であるヒエラルキーとは異なり、ホラクラシーは市場変化が激しいIT特有のマネジメント体系かもしれませんが、引き続きウォッチしていきたいと思います。

この記事では「ローマ式投票法(Roman Vote)」という意思決定を支援するためのアクティビティの一つをご紹介します。ローマ式投票法の導入によって、チームは様々なメリットを得ることができます。チームのコンセンサスが得やすく、サポートしあえる関係を構築できたり、チームの心理的安全性を担保できる、など。みなさんは、普段からどのように周囲のコンセンサスを得ていますか?

意思決定の場でよく起こること

複数人で何か意思決定をするときに、困った経験は誰にでもあると思います。それが例え仕事だとしても、プライベートだとしても。さぁ、意思決定をしようとするときに静かになる。そこで口にする「みなさん、これでいいですか?」それに対して、コクリと頷く人もいれば、異論がなければそれは賛成という都合のいいように解釈して、その場を締めちゃうなんてことはありますが、それは周囲のコンセンサスが得ているとはとても言えませんよね。

どうすればもっと効率よく合意することができるのか?よくある模範回答は以下の2つではないでしょうか。

  1. 多数決によって決める
  2. 相談や話し合いの場を設けて偉い人が決める

これでもし、周囲のコンセンサスを得ることができたのなら、それは嬉しいですよね。二人とかだったら争いはないのでしょうけど、それがプロジェクトチームのように複数人が関与していた場合、多くの意思決定の場が懸念点の洗い出しやアイディアの出し合いで終わってしまい、次に持ち越されることもしばしばあるのではないでしょうか?私はよくありました。「また別途お時間を調整して相談させてください」は一時、私の中での流行語大賞になっていました。

「賛成」や「反対」の文脈で許容してしまうと、結果に対するサポートであったり、より良い提案が生まれにくくなってしまいます。決定事項に対して納得して熱量が半端ない人もいれば、しらけている少数派の人だっているでしょう。このような意思決定方法論が続くと、中長期的に見るとプロダクトや組織に関する課題は徐々に表面化してくる恐れがあります。

そのため、最適なアプローチはどれほどのコンセンサスが周囲から得られているのかを見える化することにあり、最終的な意思決定の前に不明点や反対意見をも受け入れることです。ここでご紹介する手法は「ローマ式投票法(Roman Vote)」です。

ローマ式投票法とは?

古代ローマでは、剣闘士であるグラディアトルが戦った闘技会のコロッセウムにて、その場を埋め尽くしていた民衆の意見を「Thumbs-up」または「Thumbs-down」で判断し、意思決定をしていたと言われています。20年ほど前に公開された映画「Gladiator(グラディエーター)」で、当時のローマ皇帝が敗北した剣闘士の始末を決定する際に、これを用いているシーンがあります。

  • Thumbs-up(親指を立てる):賛成します、または受け入れます
  • Thumbs-side-ways(親指を横にする):マジョリティの意見に乗ります
  • Thumbs-down(親指を下向きにする):受け入れません、意見があります

もし全員が Thumbs-down だった場合、その案は却下ですよね。もし、複数の意見が対立した場合、Thumbs-down の意見をまずは聞いて同意した内容について振り返りを行います。そうすることで、Thumbs-up がマジョリティでも Thumbs-down が複数見られる場合は、その意見を参考にする機会が与えられます。但し、大半が Thumbs-side-ways だった場合は注意が必要です。あまり参考にならないことが多いです。どちらでもないが多いと、論点の再整理や条件の見直しを推奨します。

ローマ式投票法の流れ

ローマ式投票法は実はプライベートな場でも用いることができます。ここでは、高校時代の同級生5人と一白二日の旅行を計画するときのシチュエーションを想定したときの、ローマ式投票式の流れをご紹介したいと思います。

  1. ファシリテーターを決める
  2. 決めたい内容の共通認識を合わせる
  3. 前提条件を整理する
  4. 会話のための時間を設ける
  5. 意思決定に必要な情報を整理する(候補など)
  6. ローマ式投票法で決める

ファシリテーターは旅行をしよう!と提案した人です。わかりやすくFさんとしましょう。Fさんは、来週末の旅行先を決めるために、4人をカフェに誘いました。Fさんは先ず、集まってもらったメンバーに趣旨を伝え、移動手段や一人当たりの予算を提案します。それを聞いてメンバーは旅行先の候補を挙げていきます。行動範囲、混雑状況、当日の天気などから絞られていきましたが、会話が行ったり来たりで収集がつきません。幾つか優勢な案が出たところでFさんは会話を切り、ローマン式投票法を実施することにしました。

Fさん「では、旅行先を軽井沢にするかどうかで、みんなの意向を聞きたいと思います。では、せーのって言ったら親指を立てるか、横にするか、下げるかで教えてください。いいですね?では、せーの!」

(親指を立てた人:二人、親指を横にした人:二人、親指を下向きにした人:一人)

Fさん「割れましたね〜。まずは親指を下向きにした人の意見を聞いてみましょう。それを踏まえて、横にした人の考えも聞いてみたいと思います。では…」

ビジネスの現場はこんなに軽くないですが、一通りの流れとローマン式投票法の意味についてご参考になると嬉しいです。

ローマ式投票法をプロダクト開発に取り入れる

これはプロダクト開発を進める上で、日々の小さな意思決定をする場でも役立ちます。デザインコンセプトを決める場であったり、バックログの優先順位をチームで合意するときであったり。決定が明確なシチュエーションにおいては毎回実施しなくてもいいと思いますが、ポイントは周囲の、みんなからのコンセンサスが十分に得られているかどうかです。

コンセンサスが得られているということは、周囲からのサポートが得られるということです。例え、それが反対していた案であったとしても自分の意見をも受け入れた上での結果であれば主体性が生まれます。最近よく心理的安全性という言葉を聞きますが、それに近いと思います。

いずれ、ローマ式投票法が要らなくなる状態に持っていくことが、チームとして目指すべき姿なのかもしれませんね。

導入にあたってのアドバイス

もし、ローマ式投票法に興味があるのであれば、最後に二つのアドバイスがあります。

  1. なるべく早い段階で取り入れることを推奨します。なぜなら、既に特定の人物によって意思決定の場が支配されている場合は、あまり効力がありません。時間が過ぎれば過ぎるほど、チームのコンセンサスが得にくくなります。振り返りになりますが、そうなると、チームはどうなるでしょう?
  2. どの場でも取り入れようとしないこと。時間などの期限を設けて、それまでに明確な意思決定ができなかった場合にローマ式投票法を用いると、客観的に見ることができるのでオススメです。ローマン式投票法だけでしか決めれないチームは、逆に疑った方がいいかもしれません。

個人的に学んだのは、ローマ式投票法は全てを解決してくれる訳ではないということです。最も重要なのは、自分自身が下した意見から一歩引いて、見る姿勢を持つことです。頑固はよくないです。チームで前に進むためには、頑固者はいない方がいいです。

この空気に任せる曖昧な意思決定に終幕を!

背景

4年ほど前に、オライリーより出版された『デザインの伝え方』という書籍の監訳を担当させていただいたことがあります。

デザインの伝え方

AmazonでTom Greever, 坂田 一倫, 武舎 広幸, 武舎 るみのデザインの伝え方。アマゾンならポイント還元本が多数。Tom Greever, 坂田 一倫, 武舎 広幸, 武舎 るみ作品ほか、お急ぎ便対象商品は当日お届けも可能。またデザインの伝え方もアマゾン配送商品なら通常配送無料。

組織におけるコミュニケーション術という副題で、デザインを他者に伝える際に注意すべきギャップや、必要な心構え、そして効率的に合意形成を進めていくためのテクニックが書かれています。

なぜ、今ここで『デザインの伝え方』を取り上げるのか。私はかれこれフルリモート化により、2ヶ月弱、在宅で仕事をしています。そのため、チームはもちろん、ステークホルダーや他部署の関係者との会話は全てオンラインで完結しています。いや、完結するように工夫せざるを得ない、といった表現が正しいのかもしれません。

昨日(5月7日)にこんなツィートをしました。

フルリモートに完全移行すると、それまでのコミュニケーションに様々な変化が訪れます。例えば、相手が見えなくなる。オフィスにいる場合は、チームやステークホルダー、関係部署の人間は姿を探そうと思えば見えるのは当然のことです。しかし、オンラインでは誰が、何をしているのかが見えづらくなり不安を掻き立てます。そうなると、プロダクト開発の進め方にも影響が出てきます。その内の一つが、目に見える成果物を具体的に示さなければならなくなったことだと考えています。Before コロナは自分の成果を見える範囲で証明することができましたが、それが見えづらくなった今、自分から積極的に共有しなければならない状況にシフトしているように思います。

そのために、デザイナーはデザインをすること以上に、周囲にデザインを理解してもらうためのコミュニケーションに力を入れなければならないと考えています。

半分宣伝っぽくなってしまいますが、そこで参考になるのが『デザインの伝え方』です。

デザイン領域の特徴

専門家でもない人が専門家の仕事に意見する権限を持つーこれは現代の組織において、デザイン以外の分野ではほぼあり得ない現象です。

本書に書かれている一文です。ハッとさせられました。確かにそうかもしれません。デザイナーが手がけるインターフェースはいつの間にか組織全体の対ユーザーのインターフェースとなり、自然の成り行きとして非デザイナーとの接触機会は増えてきています。先日書いた「デザイン思考の如くー陥りやすい3つの誤解」という記事でも、創造活動としてのデザインに非デザイナーを迎え入れることができた背景について述べました。

結果として、デザインは他の分野に比べると、はるかに意見の対立しやすい分野になりました。

視覚的に目にするものであるが故に、デザインが主観的なものであると捉えられることが多く、我々の直感がデザイン上の問題をどう解決してくれているかを明確に説明できないでいます。そのため、ステークホルダーがデザイナーに注意を喚起する問題や懸念の大多数は、誤解や伝達の不備に起因しており、コミュニケーションが成立していないにも関わらず、成立したと思い込むことによって発生します。

これからのデザイナーに求められるスキルは、ステークホルダーや関係者の期待をうまく調整する能力なのです。

デザインを伝えるポイント

ステークホルダーや関係者の期待をうまく調整する能力は、素晴らしいデザインを生み出す能力よりも重要になってきます。大変ではありますが、プロダクトをデザイナーとしての視点だけではなく、ユーザーに共感するように、ステークホルダーの視点から見てみると、より良いデザイン(プロダクト)を生み出す可能性が広がってくることがわかります。

本書では、ユーザーに対する場合と同じ原理原則を紹介しており、組織におけるステークホルダーとのコミュニケーションにも適用する方法について述べています。デザインを理解してもらうためのコミュニケーションは、デザインそのものよりも重要であり、冒頭で述べた通り with コロナの今は尚更です。

ステークホルダーないしは関係者にデザインを伝える際のポイントは3つあります:

  1. このデザインはどのような問題を解決できるのか?
  2. このデザインはユーザーにどのような影響を与えるのか?
  3. このデザインが代替案よりも優れている理由は何か?

お気づきでしょうか。実はこれ、ユーザーにも同じことをデザインを通して伝えているはずなのです。

  • このデザイン(プロダクト)はあなたのこの問題を解決することができます
  • このような価値を提供することができます
  • 他のデザイン(プロダクト)よりも、こっちの方が優れている理由はこちらです

前述の通り、組織におけるステークホルダーや関係者とのコミュニケーションは、ユーザーに対する場合と同じ原理原則を当てはめていることがわかります。

悩んだら、相手の裏側を引き出す質問を準備しておくのも有効です。以下が本書で挙げられた例です。

  • どんな問題を解決しようとしているのか?
  • この方法で行なった場合、どのような利点があるのか?
  • これは、このプロジェクトの目標にどんな影響を与えるのか?

これらの質問は、ステークホルダーとのコミュニケーションにおいて実はマストだったりします。と言うのも、オンラインだとどうしても存在が薄れて声が小さくなってしまう人が出てきてしまい、気軽さも欠けてしまってフォローアップが困難だったりするからです。その場合は、ややくどいぐらいに明確にしておくとコンセンサスは取りやすいかもしれません。

偉大なデザイナーは、偉大なコミュニケーター

偉大なデザイナーは、偉大なコミュニケーターという章があります。デザイナーは、ユーザーとの接点を担う人です。そのため、多くの関係者と会話しなければいけないのは必然であり、それは理解しなければなりません。そのため、平等に意見を言ったり質問をすることに、躊躇してはならないと思います。私の経験からしても、上で紹介されているような質問を聞く権利は新卒だろうと、新しく入ってきた中途だろうと、誰でも聞く権利はあります。逆に耳を貸してもらえない組織は、おかしいと思います。

最後に、本書では、デザインの伝えるときの心構えとして、IDEAL というコンセプトを紹介しています。

  • Identify the problem:問題を特定すること
  • Describe your solution:解決策を説明すること
  • Empathize with the user:ユーザーの気持ちになること
  • Appeal to the business:組織にアピールすること
  • Lock in agreement:合意を確実に取り付けること

合意が得られれば単なる IDEA(アイディア)を持っている段階から、本当に理想的な(IDEAL)なプロダクトやサービスが生み出せる段階へ進むことができるのではないでしょうか。

非デザイナーの方へ

本書の最後の方に、デザイナーと仕事をよくする非デザイナーの方向けの言葉があります。デザイナーと仕事をするときに、ぜひ心掛けて欲しいと思います。そうすれば、今まで以上に共創できるはずです!

  • 焦点を当てるべきは「デザインの好き嫌い」ではなく「デザインの有効性」
  • 解決策の提案はせずに、理解のための質問をする(それもいくらでも)
  • 「自分もユーザー」という考え方は捨てる
  • デザイナーの説明をちゃんと聴く
  • デザイナーにも決定権を委ねる
  • 言葉使いを丁寧にし、フラットな関係を保つ
  • 裏付けとなるデータの有無を尋ねる
  • デザイナーが成果を上げるのに必要なものを漏れなく提供する

最後まで読んでいていただき、ありがとうございました。

はじめに

イノベーションに関するイベントのタイムテーブルに目を通すと、約9割くらいの確率でデザイン思考という言葉を目にするようになりました。現在半額セール中の amazon のカテゴリ別(ビジネススキル)1位も、デザイン思考関連の書籍です。(2020年5月4日時点)

なぜ、このようにデザイン思考が注目されるようになったのでしょうか。歴史を振り返ってみると、IDEO と言う企業の存在は欠かせません。IDEO は、世の中への影響や貢献度の高い企業の内の一つとして知られています。

先ず、約20年前(もうそんなに経ったのか…)に発売された書籍『発送する会社!ー世界最高のデザイン・ファームIDEOに学ぶイノベーションの技法』でその名を社会に広げ、『デザイン思考が世界を変える―イノベーションを導く新しい考え方』でデザイン思考がイノベーションを起こす起爆剤になり得るという風潮を作ったことが背景にあります。

今、改めて IDEO のサイトを見ているのですが、デザイン思考の専門サイトが開設されており、デザイン思考を学ぶための教育コンテンツが盛り沢山で驚いています。

Resources

Design thinking simultaneously considers what is desirable from a human point of view, what is technologically feasible, and what is economically viable. It also allows people who aren’t trained as designers to use creative tools to address a vast range of challenges.

私も実は、この中で紹介されている IDEO U というビジネスマン向けのオンラインコースを受講したことがあります。IDEO の中の人がメンターとしてサポートしてくれるので、心強かったです。オススメ。

さて、デザイン思考というと、下記のような図を一度は見たことがあると思います。これは、IDEO の創設者であるデビッド・ケリー氏が創設した Standford 大学の d.school が提唱する5つのステップであり、デザイン思考を説明する際に最も参照されている図と言っても過言ではありません。

このように、デザインのプロセスが公式化されたことで、結果として非デザイナーをプロセスに迎え入れることができるようになりました。この功績は、非常に大きいと思います。デザイン思考は、普遍的なプロセスとしてイノベーションを実現するための鍵となる問題発見&問題解決に適用できると今日まで考えられてきました。

ただし、実際のところ蓋を開けてみると、デザイン思考で説明される言葉と、実際にデザイナーが用いる言葉を並べてみると、そこにギャップがあることが伺えます。

例)予算、社内政治、マイルストーン、工数、組織文化など

「Design Thinking is Bullshit」という衝撃的なトークをぜひ見てください。デザイン思考に対する彼女の批判はこれからのデザイン思考を語る上では欠かせないはずです。

ここで言うギャップは、私は「デザイン思考の実践で陥りやすい誤解」と理解しています。この記事では、デザイン思考の如く取り組む際の誤解を紹介するとともに、回避策についても述べたいと思います。

デザイン思考で陥りやすい3つの誤解

誤解その壱:ユーザーの声を反映すれば、うまくいく

単純過ぎますが、ここで注意すべきは、誰の声(WHO)か、何を(WHAT)拾うか、そしてどのように(HOW)ユーザーの声を拾うのか、と言う問いに対する答えを持ち合わせているかどうかです。

一言にユーザーの声と言っても、ユーザーは大勢いるが?どうすればユーザーの声を拾えるのだろうか?そして、どのような形式を採用すれば的確なニーズを抽出できるのだろうか?この答え無くして、ユーザーの意見を反映すれば失敗はしないという保証はできないはずです。なぜなら、ユーザーリサーチで大切なのは、優先度付けだからです。それでは、それぞれの問いを詳しく見ていきます。

誰の声を拾うか(WHO):ユーザー像を明確にする際には、ターゲットとなるセグメントの中でも、特に集中したい人物像のペルソナを設定する必要があります。そうすることで、従来のセグメンテーションとは異なり、より深く、そしてより実感が湧くようになります。

ペルソナで思い出したのですが、atama+ という企業ではペルソナの擬人化を徹底するあまりに、3D 化してしまったのだとか。ここまでする必要はないと思いますが、一度オフィスに遊びに行かせていただいたときに、大変興味深い光景を見ました。打ち合わせ中の社員が、ユーザーを名前で呼びながら、会話をしていたのです。ここまで浸透していると、効果は絶大です。

AI先生『atama+』開発におけるユーザー像「ペルソナ」を公開

atama plusは、「教育に、人に、社会に、次の可能性を。」というMissionのもと、生徒が「基礎学力を最短で身につける」ことを目指してAI先生『atama+』を全国の塾・予備校に提供しています。 プロダクト開発において、Valuesとして掲げている「Wow students …

何を拾うか(WHAT):リサーチの中身のことです。ここからは、イメージがしやすいインタビューに話を絞っていきたいと思います。この記事を読んでいるみなさんは、普段のインタビューではどのようなことを聞いていますか?また、インタビューに至るまでどのような過程を得ていますか?

インタビューは、学びを得る場です。そのようにインタビューを位置付けることで、チームで次のインタビューに向けて話し合う場で、学びを最大化するための質問内容が自然と絞られていきます。発散し過ぎてしまうと、あれもこれも聞きたい内容が多すぎで、インタビュー時間が超過してしまったりします。また、急ぎすぎて試合終了後の選手インタビューのようなテンポの Q&A になってしまいがちです。ユーザーインタビューは、時間が限られている。そうならないようにするためには、優先度をつけることです。優先度付けは、インタビュー設計の時から始まっています。

どのように拾うか(HOW):ユーザーの声を抽出するための方法は様々です。そのため、どれが一番ベストな選択なのか、悩んでいる人も多いはず。そこで推奨したいのは、2軸を用いた整理です。以前、2軸を使ったプロダクトデザインにおける意思決定の方法「2×2」について紹介しましたが、今回も同様な取り組みが可能です。私が過去に取り入れた軸に以下があります:

  • コスト
  • 時間
  • 母数

この軸で整理することができれば、どの手法が今の状況におけるベストな選択肢なのか自信を持って判断することができます。ユーザーの声を可能な限り、なるべく取りこぼさないようにしたいから、と言う理由で安易に母数が多い手法を選択しても、プロダクトのためにならないこともあるため、注意が必要です。

誤解その弐: アイディアは多数決で決めたほうが、失敗するリスクは下がる

デザイン思考といえば、ポストイットが壁一面に貼られていて、その前に大勢の人が集まっているシーンを思い浮かべる人が多いと思います。

これは、参加しているメンバーのアイディアを発散し、収束させる過程の内のひとつですが、ここので注意すべきは、「お任せ民主主義状態」にならないことです。自身の書籍『サル化する世界』で内田樹氏はこう述べています。

民主主義は多数決ではなく、多様な意見に対する合意形成の上で成り立つもの。できるだけ多様な立場の人を合意形成の当事者に組み込む必要がある。

大切なのは、公正性です。それはつまり、全てのアイディアにチャンスを与えることです。誰が発言したか、誰のアイディアかで判断を任せるのではなく、アイディアが優れているかどうかで判断するための発想です。公正なプロセスとは、お互いの意見を尊重し、一人が主張するものであれば、多数が主張するものであれ、最高のアイディアを求め続けること。もう一度言いますが、この人が言ったから、とか少数の意見だから、と言う不公平な扱いをしないことです。それでは、「自分の意見が受け入れられる、または受け入れてもらえる」と言う心理的安全性の環境を作り出すことができません。

アドバイスの一つは、その場で改善案を出さないようにすることです。最初に、理解のための質問をします。アイディアの一つ一つに目を通し、全員の理解が揃っている前提を作ってください。決して価値観を押し付けない、いいところも指摘してください。その後、上でも紹介したような2軸の意思決定方法を用いることができれば理想的です。

誤解その参:プロトタイプで問題がなければ、使ってもらえる

プロトタイピングツールはここ数年で劇的な進化を遂げました。過去の記事「最低なユーザーリサーチ:リモートのリスクを減らすためのアプローチ」でも述べた通り、リモート環境下でも円滑にプロトタイプを使ってインタビューすることができる時代にいます。昔は紙芝居程度ではあったのに比べて、あたかも本番稼働しているかのようなインタラクションや画面遷移を実現できたりします。本当に凄い。

最低なユーザーリサーチ:リモートのリスクを減らすためのアプローチ | mariosakata.com

本記事は、ユーザーリサーチを批判することを目的に書いた記事ではないことをご理解ください。私自身の経験をもとに、ユーザーリサーチの可能性を広げるためのアプローチをご紹介し、リモートでユーザーリサーチを行っている、またはこれから行う人にとってお役に立てればと思っている。 …

だた、ここで注意すべきはアイディアを忠実に再現することができるが故の甘えです。プロトタイプの目的は、上で述べた「何を」が明確にならなければ、ただ単に確認のためのチェックになってしまいます。ユーザーのニーズを無視してしまいがちです。この機能はあったら使いたいと思うか?使いやすいか?このような誘導的な質問をする場を何度も目撃したことがあります。こちら側が求めている答えをユーザーから引き出す、なんとも都合がいいインタビューなのでしょう。

その場で問題がなく、期待通りの回答がユーザーが得られたなら、リリースしても問題はさほどないだろうという甘い考えは、捨てた方がいいと思います。将来のことはユーザーにだってわかりません。現時点で例え「欲しい」と言及していたとしても、実際のところはその場にいないとわからないもの。成功の確率はもしかしたら上がるかもしれないが、決して保証するものではありません。

最後にもう一つ

もう一つ誤解を招きやすいのが、デザイン思考は順を追って進めていく段階的なアプローチで、リリースしたらプロセスは終了、と考えてしまいがちなところです。しかし、ソフトウェアはずっと生き続けます。ユーザーも、使い続けます。では、作り手は手を休めていいのでしょうか?

リリースした後も、その壱で挙げたように何を学びたいか、何を検証したいのかを再度整理することで、その先につなげることができます。仮説も、よりシャープになっていきます。向かうべきプロダクトの方向性も明確になっていきます。チームの自信につながっていきます。イノベーションにグッと近づいていきます。直ぐに答えを求めてしまいがちな我々ですが、一度のサイクルでうまく行ったのなら、こんなに苦労はしないでしょう。

そういえば、この記事では「デザイン思考」と言う言葉を20回以上も使いました。くどい記事になってしまいました。最後まで読んでいただき、感謝です。