50人で評価額2,100億円を越えたNotionに聞く、少数精鋭のプロダクト組織のつくりかた：連載「クリエイティブ組織の要諦」第3回
本記事は、組織イノベーションの知を耕す学びのメディア『CULTIBASE』との共同企画で、双方の媒体に掲載されています。
連載『クリエイティブ組織の要諦』では、デザイナーをはじめとしたクリエイティブ職の組織作りのヒントを得るため、注目企業にインタビューを重ねています。デザイン組織立ち上げを支援してきたMIMIGURI CO-CEO ミナベトモミを聞き手に、組織デザイン／組織開発の両面からヒントを探っていきます。
第3回に登場するのは、『Notion』を開発するNotion Labs（以下、Notion）です。2020年4月に企業評価額約2,100億円に達した際、従業員数は50〜60人だったという同社（2020年7月時点）。つい先日の2021年10月9日（日本時間）には、2億7500万ドル（約312億円）の新規資金調達を発表し、その評価額は約1兆1,200億円にまで上昇しました。
大型ユニコーンにしては異例のコンパクトな組織で、いかにして多大なる価値を生み出しているのでしょうか？今回は、これまで日本のメディアではほとんど明かされなかった、Notionのプロダクト開発と組織づくりについて、同社でProduct and Design Leadを務めるRyo Lu氏に独占取材。
ミナベは「ここまで美しい組織は見たことがない」と、インタビューで得た驚きを表現します。世界中のユーザーを魅了するプロダクトを生み出す、プロダクト設計とも美しき相似形を描く、類稀な組織設計論とは──。
プロダクトマネージャー偏重が陥る「タコツボ化」
ミナベ：近年スタートアップの組織コンサルティングをしていると、「Notionさんのように、少人数でレバレッジを効かせられる組織をつくりたい」と言われることは少なくありません。今日は是非とも、その組織デザインの秘訣をお聞きしたいと思っています。50名ほどの組織で膨大な数のユーザーを支えられる組織的な強みは、どのような点にあるのでしょうか？
Lu：私はいくつかのスタートアップを渡り歩いて来ましたが、Notionの組織はどの企業よりも柔軟なんです。一般的に、会社の規模が大きくなるにつれてセクショナリズムが生じ、「この部門の仕事はこれ」と壁ができがちですよね。そうした縦割り構造の存在は、その企業が開発したプロダクトの機能の構造を通して、エンドユーザーにも伝わる。一方、Notionでは部門の枠組みを越えた緊密な連携が多く見られます。
それから、透明性がかなり高い。基本的にはどの部門のどの情報にも、すべてのメンバーがアクセスできるようになっています。
ミナベ：部門の垣根を超えた柔軟さや透明性の高さという点は大事ですが、多くのスタートアップが重視しているポイントでもあると思います。そんな中で、Notionが際立っている点はどこにあるのでしょう？
Lu：そうですね、たとえば2020年まで、あえてプロダクトマネージャーを置いていなかったことは特徴的かもしれません。
ミナベ：えっ、そうなんですか。国内のプロダクト開発組織では、まず意思決定者となるプロダクトマネージャーを配属し、その傘下にデザイナーやエンジニアと共にチーム組成するのが一般的です。さらに近年では、プロダクトマネジメントやBizDevの手法知見も蓄積されてきている感覚もあります。しかし、Notionは違うと。
Lu：もちろん、プロダクトマネジメントの役割そのものは必要だと思っていますし、創業初期からプロダクトマネージャーを置くことを一概に批判するつもりはまったくありません。
しかし、開発プロセスの中でプロダクトマネジメントに重きを置きすぎてしまうと、しばしばタコツボ化の問題を抱えることになります。プロダクトマネージャーや、その配下のエンジニア、デザイナーたち自らが担当するプロダクトや機能にしか目を向けられないようになってしまう。
他方、『Notion』はそもそも単独で成立している機能がほとんどなく、すべてが相互に関わり合っているプロダクトです。だからこそ、柔軟に協業できる組織体制が必要で、自然と構築できたのでしょう。
また、全員が「ユーザーにとって有益なツールを提供する」という共通の目的をしっかり意識できていることも大きいと思っています。プロダクトマネジメントの力が強くなってしまうと、やはりどこかで自分の責任範囲における「成功」を意識してしまう。
しかし、あくまで私たちにとっての成功とは「ユーザーにとって有益なツールを提供する」こと。この目標達成に近付くためであれば、私のようなデザイナーがエンジニアリングをサポートすることもしばしば。エンジニアがプロダクトマネージャーのような役割を担うこともあります。
左・MIMIGURI ミナベトモミ／右・Notion Labs Ryo Lu氏
誰もが「ユーザー全体の利益」を追える組織設計
ミナベ：プロダクトマネージャーを置かない、柔軟で自律的な組織は、実際に運用しようとすると非常に難易度が高いと思います。「ユーザーにとって有益なツールを提供する」という共通目標を持つという点も、理念を重視するという意味だけでいえば、国内スタートアップにも見られる。
しかし、Notionは50人で2,100億円の評価額まで引き上げたことからも、その実践のレベルが段違いに高いのだと推察されます。プロダクトマネージャーを置かずとも急成長を実現できる要因とそのための取り組み、またプロダクトマネジメント機能をどのように担保しているのか、ものすごく興味が湧いてきました。
たとえば、プロダクトマネージャーがいない組織では、一人ひとりが適切な意思決定をスピーディーに下す重要性がかなり高いのではないでしょうか？
Lu：はい。だからこそ、常に全員がプロダクト全体を考えることを大切にしています。
エンタープライズを担当するセールス&カスタマーサクセス部門や、中小企業や個人ユーザーをサポートするCX部門、あるいはTwitter……Notionには、さまざまなチャネルを経由して、日々ユーザーからの要望が届けられます。
寄せられた数々の要望をまとめ、その中からどんな機能を実装したり、改善したりするのか意思決定していく。その際に、最重視するのが「ユーザー全体の利益になるかどうか」です。この判断軸を全員がしっかりと共有することによって、組織としてスピーディーに適切な判断を下すことが可能になります。
ミナベ：「ユーザー全体の利益」は、どのように判断しているのでしょう？
Lu：「その実装が、高い汎用性を持っているか」で判断します。他社のプロダクトとNotionとの最大の違いは、ユーザーが私たちの意図とは異なる形で、機能を利用できるようデザインしている点。機能やソリューションをデザインする際、私たちはユースケースを一般化して考えるようにしています。
一般的なプロダクトは、一つのユースケースに対して一つの機能を実装すると思います。つまり、それぞれの機能は、個別の目的・用途に特化した形で構築されている。対して私たちが提供する機能は、その用途を限定していません。
もちろん、ある程度の“想定”はありますが、ユーザーがその意図を越えて機能を活用できるようにも設計しています。スピーディーに効率よくソリューションを提供するため、すでに実装している機能を進化させる形を取ることも多いですね。
ミナベ：『Notion』はユーザーが自由度高くカスタマイズすることが前提だからこそ、「汎用性が高いか」というシンプルな判断軸がセットできていると。さらに、作り手の意図を強くしすぎず、意図せず使われることも許容している。その具体例があれば、教えていただけますか？
Lu：2021年6月に実装した、ページ内の一部を別ページにも同期させ表示する「Synced Block」（同期ブロック）は好例です。この機能は、異なるチームやプロジェクト間で情報を共有する用途を想定して設計しました。しかし、ナビゲーションバー（Webページ内の階層を移動しやすくするための機能）として利用するユーザーが多く見られましたね。
プロダクトと組織を通底する「ブロック」というコンセプト
ミナベ：なるほど。部門間の垣根がなく柔軟で透明性の高い組織構造を前提に、意図的にユーザーの声を大量に集めることで、メンバー全員が最も大きなインパクトに寄与する意思決定が行える状態を実現しているということですね。言い換えるなら、CXと開発がシームレスに連携することで、ユーザーと開発者が直接つながり、ユーザーコミュニティ起点の自律的なプロダクト成長が実現しているともいえる。だからこそ、スモールチームでもこれだけ急成長するプロダクトを開発できているのでしょう。
Lu：そうですね。実際、いまでも私を含め2人だけで、『Notion』のプロダクト全般のデザインを担当しています。
ミナベ：なんと……。
Lu：ただ、これを実現できている根本的な理由には、開発する対象を厳選するだけではなく、『Notion』自体の設計思想があるんです。それが、「ブロック」という概念です。
『Notion』には多くの機能があり、複雑な構造をしているように見えますよね。でも、一歩引いて見ると、とてもシンプルな構造をしている。段落、図、表、動画ファイル……こうしたいくつかのパーツ、私たちの言葉でいえば「ブロック」をユーザーが自由に組み合わせることで、自らのニーズに合った使い方が可能になる。つまり、『Notion』に用意されているのは、この「ブロック」だけなんです。
ゆえに、Notionにおけるプロダクトデザイナーがデザインしているのも、この「ブロック」の部分が主。プロダクト全体を統合的にデザインしようとすると、たしかに2人では難しいかもしれません。でも、一つひとつのブロックをデザインするだけなら、アイデアさえあれば少人数でも十分可能です。
赤矢印で指されているものがブロック。ブロックの真左には「::」のアイコンが表示される。このアイコンをクリックすると、オプションメニューが出てきて、ブロックごと複製したり、ブロックごと消したりできる。ドラッグ&ドロップでそのブロックごと移動させることも可能だ（参考）。
ミナベ：なるほど、先ほどの自由度の高いカスタマイズ性も、汎用性の高い機能選定というのも、「ブロック」という概念が前提にあったんですね。たしかに、僕の会社での『Notion』の使い方を振り返ってみても、いくつものブロックを組み合わせてそれぞれの用途に最適な形を構築しています。その自由度と高いカスタマイズ性こそが、使い続ける理由になっている。なぜ「ブロック」という概念を取り入れるに至ったのでしょうか？
Lu：実はこの考え方自体は新しいものではありません。1960年代から70年代にかけて活躍したコンピューターサイエンスの先駆者たちの考えがベースになっています。彼らはコンピューターというツールを使って、物理世界の法則に縛られずに情報をやり取りすることに関して、たくさんの興味深いアイデアを持っていました。
しかし、現在に至るまで彼らのアイデアの多くは実現されていない。今実際に私たちがコンピューター上で使っているツールの多くは、現実世界にあるものの置き換えに過ぎません。たとえば、『Word』は紙と鉛筆でつくったドキュメントの置き換えですし、『Excel』は計算表の置き換えですよね。
そういったツールを用いて作成されるデータは、「ファイル」という形式にとらわれていて、ファイルの外には情報が流れていかないような状態になっている。たしかに、紙と鉛筆で文章を書いたり、計算したりするよりも便利であることは間違いありません。しかし、データの流動性の低さという意味においては、現実世界となんら変わりはないと言ってもいいでしょう。
ミナベ：あえて分かりやすくたとえると、『Excel』でつくったデータを、フレキシブルに『Word』へ流し込むことはできない。一方『Notion』では、テキストファイルの途中でも、他で使っている表組みを柔軟に差し込める、といったイメージでしょうか。
Lu：そうです。『Notion』は「現実世界にあるツールの代替」として設計していません。私たちが実現したいと思っているのは、情報を一箇所にまとめ、個別のファイルという形式にとらわれずに扱えるようすること。そして、それらの情報にあらゆる人が容易にアクセスできるようにすることです。
それらを実現するためには、既存のファイルという形式ではない統一のフォーマットで情報を保存できるようにする必要がある。そして、その情報をいつでも変更できるような、柔軟性を持った形にしなければならない。
既存のファイル形式では、自由に情報を統合したり、移管したりすることができません。いかにしてそういった情報の取り扱い方が可能になるのかを考えた末、たどり着いたのが「ブロック」だったんです。
ミナベ：なるほど……冒頭で、「柔軟で流動的な組織」の話が出ましたよね。その組織構造も、ブロックで構成されているようにも捉えられるなと感じました。プロダクトにおけるブロック機能と同様に、汎用性が高く、自由度も高いのでプロダクトマネージャーなしに部門越境して開発している。ゆえに、タコツボ化もせず、機能要求から機能開発までスムーズに意思決定できている。
最近は日本でも、BizDevにおいて「少人数組織のプロダクトレッドグロース（製品による自律成長）が理想だ」という議論はあります。しかし、Notionはそのさらに一歩先を行っている。ブロック的な組織構造で、先ほども触れた、CXと開発がシームレスに連携したユーザーコミュニティ起点の自律成長が実現できている。いやー、すごいですね……！ 僕はいまかなり感動しています。
ブロックという概念をベースに、ユーザーの課題やニーズに応じて、無限に展開が可能な美しい組織設計。『Notion』というプロダクトの美しさは、組織の意思決定の流れや、組織自体の美しさに起因するものだったのですね。これはBizDev的な発想では生まれ得ず、プロダクトデザイン的な発想で組織を設計しているからこそ実現しているものだと思います。
「ブロック」機能によってユーザーが自由度と高いカスタマイズ性を享受できるのが、『Notion』というプロダクトの特徴。これを提供するNotionの組織構造も、PdMなしで、柔軟かつ流動的な組織体でコミュニティ全体に貢献する意思決定が行える仕組みになっている。いわば、プロダクトと組織が、同じ思想・構造で設計されているのだ。
創業6年目まで組織の細分化・構造化を行わなかった理由
ミナベ：ここまでプロダクトと綺麗な相似形を描いている組織設計は日本ではあまり見たことがありません。なぜそれが実現できたのかにとても興味があるのですが、どのように組織を構築してきたのでしょうか？
Lu：長きにわたって組織の規模を小さく保ってきたことが、大きいと思います。従業員数が増えだしたのは、創業から6年目の2019年ごろから。それまでは現在のような部門やチーム分けすら存在せず、エンジニア一人ひとりが機能開発を進め、それをデザイナーがサポートする形を取っていました。
ミナベ：2020年4月にはユーザー数が400万人を超えていたと聞いていますが、それにもかかわらず2019年なるまで組織構造すらなかった。これはとても重要なポイントのように感じますね。
というのも、スタートアップは、組織を拡大することを我慢できない。プロダクト自体が市場に適応するとすぐ、組織の再現性が生まれる前に大量採用を行なってしまうんです。その後、後追いで負債処理を行うような組織づくりの進め方が多く、それが当然と思われている。
しかし、Notionはそうではない。事業価値創出を何倍にもする“組織モデルの創造”をプロダクトと同時に行い、経営全体を一つのソフトウエアのように適応してから、スケールさせてきた。当初からブロック構造をもとに組織を構築しており、かつそれに従ってプロダクトも大きく成長してきたので、無理にメンバーを増やさずに済んだのでしょう。
Lu：それから、組織づくりにおいて大事にしているのは、有能なリーダーを採用すること。チームを成功に導けるリーダーを採用し、自走してもらうことが組織構築上の大きな鍵になると思っています。2020年にエンジニアリーダーを採用して、現在のエンジニア部門を構築してもらったことが好例ですね。
また、リーダーシップの面々がプロダクトを成長させるために、自らが管掌する組織をどう構築していくかをしっかり考え、採用にコミットしてきたことも大きいと思います。
ミナベ：人数を最小限に抑えながらプロダクトを成長させてきたということは、本当に必要な人だけを、言い換えれば純度の高い採用をして来られたのではないかと推察しています。採用において重視しているポイントも教えていただけますか？
Lu：最も重視しているのは、モノづくりに対する情熱です。それから、オープンマインドであること。周囲と協働する姿勢を持っているか、自分とは違う価値観や同僚からのフィードバックを素直に受け容れられるかどうか、といった点を見ています。
もちろん、組織のフェーズが変わっていくにしたがって、求める要素も変化するかもしれません。しかし、「モノづくりへの情熱」と「オープンマインドであること」の重要性はこれからも変わらないでしょう。
柔軟性と慎重なスケーリングを考えて、採用もブロックファースト
ミナベ：リーダー層は他のスタートアップで活躍した後にジョインした方が多いのでしょうか？
Lu：そうですね。リーダー層や経営陣はスタートアップ出身者が多いです。ただ、経験豊富なリーダーが多く在籍する他の組織とNotionには、大きな違いがあると思っています。
というのも、多くのスタートアップでは、創業者や経営陣が自らの出身企業を模倣する形でプロダクトや組織を構築しようとする。一方、私たちは創業者や経営陣のバックグラウンドや考え方、志向性からではなく、「ブロック」という概念から事業や組織づくりをスタートさせている。つまり、コンセプトファーストなんです。そこが、スタートアップ出身者を経営陣に迎えている他の企業との違いだと思います。
ミナベ：プロダクトや組織の設計のみならず、組織文化・採用にも「ブロック」というコンセプトが通底していたのですね。最後に、今後の組織的な展望をおうかがいできればと思います。
Lu：プロダクトマネージャーを配置せず、タコツボ化を避けてきたことが私たちの組織的な特徴の一つであるというお話をしました。ただ、それも組織の規模が小さかったからこそ。
より規模を拡大するにあたっては、各機能開発の進捗を管理し、部門間の調整役を担う役職は必要だと考えています。2020年にはじめてプロダクトマネージャーを採用したのですが、まさに今がそのベストタイミングだと感じています。
とはいえ、プロダクトマネジメント偏重にはしたくありません。しっかりとメンバー全員が等しく責任を持ち、全員が「ユーザーにとって有益なツールを提供する」という共通の目的にコミットできる組織をつくっていきたいですね。
ミナベ：プロダクト開発においては、まず事業を創造してから、後追いで組織・人創り...となりがちです。しかしながらNotionは、事業・組織・人を初期から駆動させながら、ソフトウエアのように検証していく経営デザインと、首尾一貫した美学によりインパクトを出されている。
今回、そうした新たな企業成長論を学べたと考えています。私にとっても今後の探求指針を得られました。本当にありがとうございました。
［文］鷲尾諒太郎［編］小池真幸