見出し画像

フラット組織において、正しい意思決定と事業推進のためにUbie Discoveryでやっていること

Ubie Discoveryで新規事業開発/プロダクト開発をしている中川です。

今回は、最近面接などでよく質問をもらうことが増えた、Ubie Discoveryというフラット組織においてどうやって正しい意思決定と事業推進を行なっているのか、について、中の人の目線で自分なりにまとめてみました。

Ubie Discoveryが採用するホラクラシー組織とは?

スクリーンショット 2022-02-20 23.56.56

上から下に責任範囲が小さく切り分けられて垂直に権限委譲されていく一般的なヒエラルキー(階層型)組織に対して、ホラクラシー組織では上下の概念が存在せず、Accountabilityによって並行に権限委譲されていきます。

Accountabilityとは、一般的な企業における部署が担う期待値に近いもので、部署にあたる概念を “サークル/ロール” と呼んで運用しています。

ヒエラルキー組織ではロジックチャートのように分解して表現される組織図が、ホラクラシー組織では細胞分裂のように円構造で表現されます。

個人的には、福岡伸一さんの「動的平衡」に近い営みがホラクラシーであり、サークル/ロールは作成・変更・破壊を繰り返しながら、組織全体の均衡を保っていきます。

この辺の記事にうまくまとまっていました。
https://www.dhbr.net/articles/-/7236

創造的破壊を繰り返す組織構造

前述のとおり、Ubie Discovery(以下UD)では部署っぽいもの(サークル/ロール)が容易に破壊されます。

それと同時に、より優先度の高いテーマに関してサークル/ロールが創造されたり、既存のサークル/ロールがアップデートされてその役割を担ったりします。

組織構造の破壊と創造は、UDに所属するすべてのメンバーが行います。いわゆる”上”の人が存在しないので、ひとりひとりが自分たちの頭で考えて最適な解を見つけ、歪みの修正と、こうあったらいいよね・やるねといったアクションが生み出され、動的に組織が変化していきます。

この話をすると、「そんなことするとカオスになりませんか?」という質問をよく受けます。

確かに、この破壊と創造のプロセスが無作為に拡散されていくとカオスになり、組織(系)の平衡はとても保てないと思います。しかしUDでは、優先度の高いテーマは何か・それはなぜか、のWHY/WHATが同期できており、それにより自律的に秩序を持った組織構造の破壊と創造が生まれています

これを可能にしているのは、徹底した採用とOKRです。

組織における意思決定の碇(いかり)となるOKR

中長期の事業ストーリーに紐付いたOKRが会社運営において重要なことは言わずもがなですが、このOKRは非常にハイコンテキストです。(入社直後は何のことを話しているのかまったくわからなくて焦りました。笑)

前述のとおり、UDにおけるOKRは事業を進める上での意思決定だけでなく、組織構造を最適化するための意思決定でも重要になってくるため、普通の企業よりもOKRが与える影響範囲も広いです。

また、全社OKRのような全社戦略に関わる部分を、一般的な会社では経営陣が主導で理解・戦略構築していくものですが、UDの場合は同様の粒度のことを全メンバーに期待します。

事業開発メンバーに限らず、エンジニア・デザイナー・コーポレートメンバーでも全員です。

ここが斬新かつ、複雑性を増す要素になっています。

つまり、全社OKRを骨の髄まで同期できているメンバーがどれだけ多く増やせるかが、正しい意思決定と、組織運営の鍵になります

ハイコンテキストなOKRの内容を、認識ギャップを極小化して伝えるための工夫

全社OKRを骨の髄まで同期できるメンバーをどれだけ多く増やせるか(拡大再生産ができるか)が、最近の社内でのもっぱらの関心ごとであり、ベスプラはまだ模索中であるものの、過去の失敗も踏まえて見つけたUDらしい工夫があります。

それは下記3点です。
・OKRには「AC」と「得たいリターン」を明記する
・ACにはWHATを書く。HOWは書かない
・得たいリターンはBS思考で書く

▶︎ OKRには「AC」と「得たいリターン」を明記する
ACというのはAcceptance Criteira(受入基準)のことで、スクラムのProduct Backlog Item(PBI)を作成するときの概念です。平たく言うと、どういう状態が達成できていたらそのOKRが達成できたといえるかが「AC」。そのOKRを達成することでどのようなアセットを積むことができるのかが「得たいリターン」です。

▶︎ ACにはWhatを書く。Howは書かない
前述したように、どういう状態が達成できていたらそのOKRが達成できたといえるかが「AC」です。そのため達成したい状態(WHAT)を定義する必要があるのですが、これをまやかしのWHATっぽいもの(HOW)で書いてしまうのが陥りやすい罠です。

すごく雑な例を挙げますが、「最高のユーザー体験が作れていること」は達成したい状態(WHAT)でしょうか?

WHATかどうか怪しいなと思ったら、まず「なぜそれが必要なんだっけ?」というWHYを自問します。最高のユーザー体験をなぜ作りたいかというと、詰まるところそれは "有料ユーザー数を増やしたい" というもう一つ上段の目的にたどり着いたりします。

スクリーンショット 2022-02-21 0.06.53

WHYを自問し、会社として得たいリターンを明瞭化すると、WHATが正しい粒度で定まります。
つまり、先ほどの例で言うと「最高のユーザー体験を作る」は全社で達成したい状態の必要条件であって、十分条件ではないということがわかります。「最高のユーザー体験を作ることで、有料ユーザー数●●人が達成できている」がより精緻なWHATかなと個人的には考えています。

スクリーンショット 2022-02-21 0.16.04

▶︎ 得たいリターンはBS思考で書く
これは事業フェーズにもよりますが、基本的には近視眼的なPL思考(ex. 売上●円)ではなく、中長期目線のBS思考(今期どのようなアセットを積みたいか)でリターンを書いていきます。

OKRは地図 : 目的地を書く。行き方は書かない

東京からロサンゼルスに行きたい、となった時。旅のメンバーにはじめに伝えることは
- 目的地をロスにしたこと(WHAT)
- なぜ、ロスに行きたいのか(WHY)
この2点だけ。

どうやってロスに行くのか(HOW)は、チームメンバー全員で考える。飛行機で行ってもいいし、船で行ってもいいし、もしくは別の全然違う行き方があるかもしれない。

OKRも同様で
- この四半期で得たいリターンは何か(WHAT)
- この四半期でどんなアセットを積めたら事業成功のオセロの角が取れるか(WHAT)
- なぜ今それをやるのか(WHY)

この3点を徹底的に明瞭化します。

WHY/WHATが全社で同期できると、このOKRの達成は最適なAccountabilityを持ったサークル/ロールに完全に委譲され、どんな攻め方(HOW)で達成するかの戦略もサークル/ロールメンバーに一任されます。都度都度進め方を”上”に確認する必要がないため、意思決定と事業推進のスピードは圧倒的に早いのが特徴です。

UDメンバーに期待されていることは、世の中一般的なCxOに近いなと個人的には感じていて、それは意思決定できる権限委譲の範囲が非常に広いことと、常にスピード感を持って最適な意思決定を求められる(いい意味での)プレッシャーがかかった環境だからです。

スクラムの考え方を新規事業開発(Biz Dev)にも活用し、解くべき課題を明確に

UDにおける意思決定プロセスのなかでもう一つ特徴的なのは、プロダクト開発以外のチームでもスクラム運用が導入されていることです。

スクラムとは
https://qiita.com/halhorn/items/5cf7d28034ad9132d311

スクラム運用の経験がなかった私は入社当時かなり面喰らったのと、プロダクト開発の仕組みが果たして事業開発においても機能するのか懐疑的でした。

しかし実際に経験してみることで、不確実性の高い新規事業開発こそスクラム運用が効果的である、ということが腹落ちしました。今ではスクラムのない運用が考えられない体になってしまいました。笑

解くべき課題を明確にしてくれるPBI

PBIとは、いわば “解決したいテーマと、どのような状態になったらそれが解決できるか” を明文化したチケットで、1週間以内に解決できるサイズにちぎって書かれます。

新規事業は不確実性が高いので、早く出して早く検証することが重要です。環境変化で取り組むべきテーマが日次で大幅に変わることは日常茶飯事なので、ROIを最大化するためにも、1週間以内にアウトプットが出せるサイズでちぎることをUDでは重要視してます(※厳密には事業フェーズにより変わりますが細かくなるので割愛)

PBIのフォーマットは
- 背景(WHY / なぜそのテーマに取り組むか)
- AC(WHAT / 達成したい状態)
- 得られるリターン(WHAT / このチケットで得たいもの)
- 検証ポイント(WHAT / このチケットで検証したいこと)

だいたい上記のような感じが多いです。
OKRのところでも書いたとおり、PBIでもWHY/WHATにフォーカスすることを大切にしていて、HOWをできるだけ書かないことにこだわっています。

達成したい状態(WHAT)を同期しただけで、自分の想像を超えるアウトプットが開発チームから生み出された成功体験をしてから、1人の頭の中にある陳腐なHOWにチームが縛られるのではなく、チームで最適なHOWを生み出せることの素晴らしさに気付いてしまったからです。

また、PBIを書くことで解くべき課題が先鋭化されることにも気付きました。
- 自分の中の論理矛盾
- 思考がHowに偏っていないか
- それは本当に解くべき課題か?
- それは本当に今取り組むべき?

安宅和人さんの「イシューからはじめよ」にもあるとおり、なによりも重要なのは “どの課題を解くべきなのか” というイシューの質を上げること。PBIを書き、WHY/WHATに向き合うことで、自然とイシューの質が上げられ、チームが取り組むべき課題・テーマの優先順位付け・意思決定の精度が圧倒的に上がりました。

このプロセスを習慣にし始めてから、自分が今までいかに雰囲気で事業開発をしていたかに気付き、恥ずかしくなったくらいです。


まとめ : UDというフラット組織における意思決定の三種の神器は、ホラクラシー・OKR・スクラム

この記事を読んでもなんのことかよくわからないかもしれませんが、習うより慣れよです。

意欲的な組織運営をしているな。面白そうだな。ダイナミックな環境で働いてみたいな。などなど、UDで働くことに興味を持ってくれた方は、ぜひカジュアル面談からはじめてみませんか?

一緒に月まで行ける仲間を募集中です!

▼ Ubie Discoveyメンバーとのカジュアル面談のお申し込みはこちら
https://recruit.ubie.life/

この記事が気に入ったらサポートをしてみませんか?