エンジニア100名に対してPM1名。Notionの急成長を支える開発組織とカルチャー

目次
・Notionの組織構成
・Notionの製品決定プロセス
・Notionのプロダクトデザインの考え方
・Notionのプロダクトとビジネスニーズのバランス
・Notionで働くエンジニアの役割
・Notionのエンジニア採用
・Notion流PLGにおいて大事なこと

※2021年12月9～10日に開催された【PRODUCT LEADERS SALON 2021】より、Notionにてエンジニアリングの責任者を務めるMichael Manapatさんのセッションをお届け。書き起こし形式で編集したものをお届けします。

>>>［関連記事］PRODUCT LEADERS SALONに関する記事一覧はこちら

【スピーカー】Michael Manapat　NotionHead of Engineering（画像 右）
Notionにてエンジニアリングの責任者として、同社のエンジニアリングおよびデータサイエンス部門を統括。Notion入社以前は、Stripe社で6年間にわたり応用機械学習の取り組みを指揮し、数々の新製品やビジネスラインを立ち上げ。それ以前は、Googleのソフトウェアエンジニア、ハーバード大学の研究員を務めていた。

【モデレーター】Ken Wakamatsu 株式会社metroly CEO / CPO（画像 左）
⽶国カリフォルニア州オレンジカウンティ⽣まれ、カリフォルニア⼤学バークレー校出⾝。⼤学卒業後、エンジニアとしてMacromediaに⼊社。その後、Kodak、Adobe、Ciscoを経てSalesforceに⼊社。2016年、Salesforce Japanに出向し、プロダクトマネジャーの責任者として、プロダクトマネジメントチームを⽴ち上げる。 2020年、AI交通費精算サービスを提供する株式会社metrolyに参画。20年以上SaaSを中⼼としたプロダクト開発で培った知⾒を⽣かし、経営とプロダクトの責任者としてタイムマネージメントのアプリケーション、「Time Insights」の開発に向き合っている。

Notionの組織構成

まず最初に自己紹介をお願いします。（聞き手：Ken Wakamatsu氏　日本CPO協会 代表理事）

みなさん、こんにちは。Notionでエンジニアリング責任者を務めているマイケルです。

Notionとはオールインワンのワークスペースで、メモの作成、ドキュメントの作成、ナレッジ管理、Wikiによる整理、エンジニアリングやデザイナー向けのプロジェクトの実行などが可能です。さまざまな組み合わせやカスタマイズができるので、職場で必要なツールを自在に作成できます。

私自身は、2020年の初め、コロナが始まる直前にNotionに入社し、2年弱が経ちました。特異なスタートでしたが、とても楽しくチームも大きく成長しました。本日はここに来られてうれしいです。

プロダクトデザインやエンジニアリングという観点から、Notionの組織構造について教えていただけますか。

最初にエンジニアリング組織についてご紹介します。現在、約100人のエンジニアがおり、5つのグループで編成されています。

1つ目は、インフラとデータインフラストラクチャを構築するグループです。ここには、テクノロジー企業のインフラ型組織に必要なものが全て揃っています。信頼性、ストレージ、アラート、モニタリング、データパイプラインなどです。

2つ目は、APIやプラットフォームの開発グループ。2021年5月には開発者向けAPIのベータ版を発表しました。完全版の発表は2022年初旬の予定で、皆が一丸となって取り組んでいます。また、インドで「Automate.io」を買収したため、APIとプラットフォームの部門はハイデラバードにあります。

3つ目は、「コアプロダクト」と呼ばれるグループ。ここで取り扱う範囲は、Notionにあるほぼすべての機能です。エディター、サイドバー、モバイルアプリ、ナビゲーション、検索等はコアプロダクトの担当です。

4つ目は、グロースに焦点を当てたグループ。アクティベーション、アクイジション、エクスパンション、リテンションなどファネル各段階で適切に働きかけNotionの活用を促します。

5つ目は、データサイエンスのグループです。 GTM 戦略や製品化のための分析やデータサイエンスに取り組んでいます。

以上がエンジニアリングの体制で、各グループの規模は様々です。構築すべきものが多いためエンジニアリングはかなりの規模となっています。

現在プロダクトマネージャーが1名おり、グロースグループと密に連携しています。プロダクト全般をエンジニアやデザイナーが担当しているボトムアップ型のプロダクト組織です。

まもなくさらに数名の PM が加わります。プロダクトマネジメントのプロセス全体で、例えばユーザーリサーチや発表後に解決すべきユーザーストーリーやユースケースについての厳密な検討が必要で、当社はその点を重視しているため PM を増やすことにしました。

最後にデザインですが、現在Notionのコアプロダクトに携わるデザイナーは2名です。常に多くのエンジニアリングチームと連携し、シンプルなテーブルやリンクのプレビューなど、エンジニアと直接作業を行っています。プロダクトマネジメントやデザインの観点から今までもこれからも非常にスリムな体制を維持していきます。

Notionの製品決定プロセス

Notionではどのように製品決定がなされますか？

約2年前、私がNotionに入社した当時と、現在の製品決定のプロセスは大きく異なります。

2年前は、エンジニア、デザイナー、共同創業者が直接コミュニケーションを取り、少人数で意思決定していました。エンジニアがプロジェクトを終えたタイミングで、創業者のアイバンとサイモンに会い、フィードバックやアイデアをもらいます。それらをもとに、デザイナーが詳細を作り上げる。常に数週間先を見て、次に取り組むべき項目やプロダクトの詳細を決定していました。

現在は組織の規模も大きくなるので、以前のような進め方はしていません。まず、四半期、半年、一年で行うことについては、数ヶ月ごとに共同創業者の アイバン とサイモン、COO のアクシャイ、CRO のオリビアと私で話し合い、長期的な戦略プランを立てています。

たとえば、2022年末のNotionのあるべき姿として、広範なプロダクト一式を発表すべきか、プロジェクト管理等の特定事項に注力すべきかなど。新たな可能性を加えたりもしながら、達成したいことやその理由、おおよその戦略フレームについて半期ごとに確認しています。

プロダクトの詳細については、エンジニアリングチームが直接話し合います。たとえば、2021年の初めに目標として掲げていたことは、Notionの中核となるドキュメントやWiki のユースケースの範囲拡大、ユビキタスの採用など。それらについて、エンジニアリングチームがディスカッションし、アイデアを出し合います。

「目標達成には、検索に取り組む必要がある。現在は関連性の検索順位があまり良くない」

「検索スピードが遅い。エディターにラグが多く操作も直感的でないためエディターのパフォーマンス改善が必要だ」

このように戦略目標やフレームに基づく具体的なプロジェクトやプロダクトの機能は、エンジニアリングチームがボトムアップで決定し、創業者二人と私で計画を確認してフィードバックを行います。「なぜ y ではなく x にフォーカスするのか」といった形で議論や調整を少ししますが、基本的には各チームに任せたいと考えています。

また、プロジェクトの実行についても、エンジニアとデザイナーがチームを組んで推進していきます。UXパターンのアイデアも彼らが決めますし、製品仕様が決まっている場合には、モックアップ実行計画ができた時点で資料を作成してもらい、それを経営陣が各自で確認します。質問がある場合には創業者と私が加わりオープンに話し合うことにしていますが、ほとんどの場合Docにスタンプを押すだけ。チームの能力を信じているからです。

Notionのプロダクトデザインの考え方

プロダクトの試験運用は、毎日行なっています。ユーザーリサーチやユーザーフィードバックなど、常に様々な形で多くのユーザーと対話しています。

ですが、社内にはNotionの熱心なユーザーが230人もいるので、プロダクトのうまくいっている点とそうでない点について私たちは常に把握できるのです。Notionはある意味私たちのために構築されています。自分の直感がプロダクトの方向性に影響を与えることは、勝手ながらとても楽しいことです。

その他にも、弊社にはプロダクトの決定に必要なデータを得るたくさんのチャネルがあります。ここでのデータとは量的にも質的にも広義のもので、いくつかのチャネルを使用しています。

まず、サポート窓口や Twitterなどあらゆるユーザータッチポイントを通じて、「これが欲しい」「これは使えない」「これは作って欲しい」と言った意見を記録し、階層的な分類でタグ付けします。例をあげましょう 。「閲覧のアクセス権やデータベースのフィルター設定の権限が欲しい」という意見はユーザータッチポイントの追跡データベースに「データベース」「アクセス権」「フィルター」とマークされ、私たちはその点について検討することになります。

過去一週間、一か月、四半期に、intercomなどの会話でデータベースへのアクセス権を取り上げた人が何人いたか。全ての会話から実際に人々が語った内容を確認することができます。これがプロダクトデザインの際に採用する情報のひとつです。

もうひとつ大きな情報源になっているのは、既存や見込みの企業など大規模ユーザーからのフィードバックです。数ヶ月に一度、カスタマーサクセスチームとセールスチームからユーザーからの要望や提案をまとめてもらい、優先順位のついた要望リストをもらっています。

Notionの特徴としてアンバサダーの存在があると思うのですが、彼らからのフィードバックも、チャネルやプロセスを通じて直接得られるのでしょうか？

おっしゃる通りです。アンバサダーはプロダクトのリリースサイクルの一部として非常に重要な存在です。彼らとはSlack で直接やり取りしていて、リリースする前のベータ版をアンバサダーに使ってもらい、フィードバックを得ています。「このフローは直感的でない」、「バグがある」、「これが足りない」、「この機能がいい」など、こうしたコメントを集めてプロダクトの正式発表前に何度か修正を加えています。

Notionのプロダクトとビジネスニーズのバランス

エンジニアリングやプロダクトのニーズと、ビジネスサイドである CRO の意見とのバランスはどのように取っているのでしょうか？

現在の最大の課題のひとつです。2021年7月に行なった全社的な計画ではマーケティングや経営陣から、エンジニアリングに向けてやりたいことを提示しました。その中にはプロダクトへの要望もあればビジネスのためのエンジニアリングサポート go to market への側面もあります。セールスチームを介した大規模ユーザーの要望は監査ログや管理コンソールなど様々です。それがプロダクトへの要望です。

しかしマーケティングキャンペーンや価格設定パッケージング、請求の方法を変更するためのエンジニアリングサポートも必要です。これらはすべて計画の段階で見直され、成長を元に人員を配置できるかどうか検討します。必要なものを把握するために全体のロードマップを見据えて検討するのです。かなり大変ですが、さらに厳密に行うことを目指しています。

Notionで働くエンジニアの役割

エンジニアリングチームとプロダクトマーケティングとの連携はどうですか？

いくつかの方法で密接に連携しています。まずNotionで働くエンジニアの仕事は、コードを書くだけではありません。プロダクトマネージャーが不在の場合 、エンジニアに機能についての全責任があります。 API 公開に合わせて、 書くブログ記事の内容やドキュメントの表示方法、大企業利用に備えてすべきこと等、各プロダクトや機能の発表時にはエンジニア自身がマーケティングにかなりの時間を割きます。

現在プロダクトマーケティングのチームやPMMは非常に充実しています。エンタープライズ、 グロース、 コアプロダクト、それぞれのグループにPMMがいて、様々な形で関わっています。

たとえば、 エンタープライズのPMM は、大規模ユーザ向けの監査ログ機能を開発中のグロースチームに参加します。多くはエンジニアやデザイナーが直接引っ張ってきますが、 PMMはプロダクト開発プロセスの初期段階でユーザーの声を届けてくれる存在です。

ベータ版や社内版を検討する際にも、 PMMはプロダクトを精査し、しっかり把握しています。「小規模チーム向きだが、この点が大企業ユーザーには使いづらいだろう」など、エンジニアリングにアドバイスします。つまり従来 PM が行なっていた仕事の多くを、現在は PMM が行なっているのです。PMMは、開発プロセスでは大切な存在になっています。

Notionのエンジニア採用

プロダクトマネージャーの数が多くないということは、エンジニアやプロダクトマーケターがその役割を担うということですよね。Notionで働くエンジニアに求められる能力について教えてください。

エンジニアがNotionで活躍するには、技術力の高さだけでは不十分です。私達が求める人材とは、優れた技術力に加えてプロダクトデザインの洞察力や判断力を備え自分の手で終始プロセスを実行できる人です。

現在Notionの社員数は230名ほどですが、部門を超えた連携が多く、エンジニアにも他部門との関わりが求められます。しかし、それは全てのエンジニアが望むものではありません。Notionでエンジニアに求められる能力は、技術力が高く、部門間の協力に対する意欲と能力があり、プロダクトのセンスがある人。その採用は門戸をかなり狭めることになりますし、難しくもなりますが、こうした人材を採用できれば驚くべき仕事を素早くこなしてくれるでしょう。

昨晩嬉しいことがふたつありました。ユーザーにとって重要な機能をこの一週間でふたつ発表したのです。一つはシンプルテーブル、もう一つは余白にコメントする機能です。どちらも主に一人のエンジニアが担当したもので、二人ともこの夏に入社した社員です。つまりNotionでは、入社4ヶ月でプロダクトの機能追加を世に送り出すこともできるのです。今回は一人での担当でしたが、すべてのチームが協力します。こうした人材の採用は難しいですが、もしできればプロジェクトに大きな影響を与えてくれるでしょう。

エンジニア向けの面接には当然専門的な質問や、コーディングのテストがありソフトウェア設計の面接もあります。しかし面接の過程の多くは、協調性やコミュニケーション力、責任感等に重点を置くものです。 問題解決能力を見るために、JavaScript で問題の解決方法を書く速さにも注目しています。

内面的要素を見極める面接はなかなか難しいですが、私たちは面接官とのやりとりを非常に注意深く見ています。質問にはっきり答えているか。また、過去の仕事について、プロジェクトに関わったあらゆる人への理解、プロダクトマネージャーと自分の仕事内容についての語り方などから見極めています。

Notion流PLGにおいて大事なこと

最後に、 プロダクトレッドグロースに移行中の企業にアドバイスをお願いします。

ポイントはいくつかあります。一つは戦術的かもしれませんが、早い段階でデータエンジニアリングやデータサイエンスに投資することです。Notionは初期の段階から成し遂げたいことの明確なビジョンがあり、それを成し遂げました。少しアップルに似ているかもしれません。そして幸運なことに早い段階で PMF ができたことで成長を遂げましたが、初期段階ではかなり直感に頼っていたため、データ主導の思考や分析の基盤が整っていませんでした。

そこでグロースチームを立ち上げ、注力してきましたが当初時間をかけたのは正しいデータの収集でした。プロダクトで人々が行なっていることは何か。オンボーディングファネルで人々が去りがちな箇所はどこか。使いにくい点やある点でのコンバージョンが低いあるいは高い理由は何か。データを見るまで、私たちは何もわかっていませんでした。そこで今年は現状把握のためにデータエンジニアリング、データインフラストラクチャ、データサイエンスに関する投資をしました。

二つ目は、プロダクトの改良こそ、成長のための重要な手段になります。間違いがちなのは、 成長を企業の一部や、単一チームだけに関することだけで捉えることです。

例をあげましょう。Notionで通知や共有、コメント等に取り組んでいるチームが複数あるとします。各分野にはプロダクトにとっての本質的な価値があります。例えばユーザーが同僚とともにドキュメントを編集することも、全て成長のためのメカニズムです。ワークスペースに参加していない人をメールでメンションした際に招待状が届く。コメントでメンションしてより良い経験ができるようにして、登録を促すメールが届くようにすればユーザーの拡大につながります。

現在のグロースチームがグロース全般を担当していますが、グロースとエンタープライズの2分野があります。エンジニアリングが作り上げるもの全てにグロースの視点とエンタープライズの視点があるという DNA の浸透を目指しています。ソリューションの完成には解決を目指すコアプロダクトのユースケースやユーザーストーリーに加えてこの二つの要素が必須です。

（終わり）

編集 ＝ 野村愛