はじめに

仮説検証学習サイクルを可視化するためのツールを「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特有のマネジメント体系かもしれませんが、引き続きウォッチしていきたいと思います。