テクノロジースタートアップの“ジレンマ”を解消するには？　「技術負債を作らずに爆速設計」を可能にした“エキスパートによる完全分業体制”

元Google Japanエンジニア、株式会社ナレッジワークCTOを務める川中真耶氏

川中真耶氏（以下、川中）：「規模が拡大しても耐えられる創業期のシステム・組織設計」というタイトルで発表させていただく（川中）真耶です。よろしくお願いします。

まず自己紹介なのですが、僕はずっと技術で飯を食ってきた人間です。大学で情報科学を学んで、IBMでリサーチャーをして、Google（Google Japan）でソフトウェアエンジニアをして、という経歴です。

2020年に、CEOの麻野（麻野耕司氏）とナレッジワークという会社を創業しました。そこからCTOをやっています。

ナレッジワークは、セールスイネーブルメントクラウド「ナレッジワーク」というものを作っています。こちらのプロダクトは、営業力の強化・営業生産性の向上を1つのツールで実現するようなものになっています。

スタートアップが持つ、ビジネスとプロダクトのジレンマ

さて、今日は、創業期にシステム・組織の2つをきちんと設計したことによって、今でも大きく拡大し続けられているという話をします。

テクノロジースタートアップにはジレンマがあると思っています。ビジネスを考えると、早くPMF（プロダクトマーケットフィット）したいんです。そのためにプロダクトを早くローンチしたい。でも、プロダクトのことを考えたら設計したいんですよ。技術負債は作りたくないじゃないですか。ゼロから作り直したくはない。なので、初期にこそ設計したいんです。

だから、この両方を満たすものを作るのが、初期のCTOとしての役割でした。

創業当初から「エキスパートによる完全分業体制」を採用

じゃあ、ここで何をやったかという話なのですが、私たちは「エキスパートによる完全分業体制」を取りました。普通のスタートアップだと、1人が何役も兼任すると思うんですよ。そうすると、ちょっと苦手な分野もあって、苦手な分野をやると、あとから入ってきた人によって全部作り替えられてしまうということが起こるかなと思います。

それを、創業当初からPdM（プロダクトマネージャー）、デザイナー、フロントエンドエンジニア、バックエンドエンジニア、すべてエキスパートを登用して、「専門分野だけガッチリやる」ということをしました。それにより、爆速で設計しつつ何年も耐える基本設計ができたかなと考えています。

完全分業体制の課題解決のためドキュメント文化と会議体を設計

ただ、これをすると1個問題があるんです。それは、コミュニケーションです。コミュニケーションをどうするかというと、私たちは「ドキュメント文化と会議体をきちんと設計する」ということをしました。

PdMは「minispec」というものを作っています。minispecとは（資料の）左下に書いてあるのですが、顧客課題とかユーザーストーリーとかの仕様をまとめたものです。これをPdMが中心になって作り、プロダクトデイリーという会議体で、プロダクトマネージャーとエンジニアが一緒になって何を作るか考える、ということをしています。

何を作るかが決まると、エンジニアは、それをどう作るか考えます。ここで「DesignDoc」というものを書いています。DesignDocは、API仕様やデータベースの仕様を、コードを書く前に議論をするというものです。

創業から2年半で、200件以上のminispec、100件以上のDesignDocができています。非常に多くできているかなと考えています。

創業期のシステムアーキテクチャは分業がしやすいSPA構造

分業をした結果、フロントとバックがシステムとしても分かれることになりました。フロントエンドとバックエンドが分業しやすいSPA構造を取っています。

私たちはセキュリティがけっこう大事なのですが、最初からきちんと設計ができていたおかげで、ファイルを扱うような少し危ないところは外出しするということも、最初の設計からできています。それも2週間程度でできたので、早かったかなと考えています。

結果として、初期の実装完了まで3ヶ月ほどでした。実装を完了するとすぐに営業することができ、1年間で10社以上の顧客を獲得することができました。

1人あたりプルリク（プルリクエスト）の数が毎日5つほどあり、最初はエンジニアが3人しかいなかったのですが、毎月4万行ほどのコードがリリースされているという点で、けっこう速いスピードで（開発）できたかなと考えています。ここまでが創業期の結果です。

組織拡大で生まれたコミュニケーションの課題もドキュメント文化と会議体で解決

次に、ちょっと拡大していくという時に、それまではプロダクトチームしかなかったのですが、ビジネスチームというものができてきました。

実はCEOがプロダクトチームの中に入っていて、プロダクトオーナーでもあったので、ここはコミュニケーションする必要がぜんぜんなく、ツーカーの仲みたいな感じだったんですね。ところが、徐々に会社が拡大するにしたがって、ビジネスチームとプロダクトチームが分かれてきます。そうすると、（スライドを示して）ここのコミュニケーションが必要になってくるわけです。

ここもまた、ドキュメント文化と会議体で解決します。私たちが作ったのはプロダクトシェアデイという会議体です。プロダクトチームからは「こういうものができましたよ」というリリースノートをビジネスチームに共有し、ビジネスチームからは、顧客の課題、感謝の声をプロダクトチームに共有する、そんな日を作りました。

エンジニアはセールスの観点でいうと、やはりドメイン知識がないのですが、これによりそこを補うことができたと考えています。実は先ほどの顧客10社は無償利用だったのですが、これにより有償転換率100%、顧客数も1年後に3倍になるという結果が得られました。

まとめ

まとめます。私たちはエキスパートによる完全分業体制を取りました。ドキュメント文化を構築し、コミュニケーションを定義しました。（その結果）専門性を保ちつつ、情報が巡る組織を作ることができ、職種・チームが増えても歩みを止めず、そのまま拡大することができたと考えています。

ご清聴ありがとうございました。

監査ログとトランザクションの整合性をどうやって取ったか

司会者：ありがとうございました。それでは質疑応答です。審査員のみなさん、お願いします。

藤本真樹氏（以下、藤本）：じゃあ、私から。けっこういろいろとおうかがいしたいのですが、まず1つ目は、創業期のエンジニアのハイアリングがメッチャ大事だよねということで、「こうやって集めてきたぜ」とか、なにかあったら。

あと、そのチームの中で川中さんが、「あの中の1人が自分だぜ」、あるいはそれ以外のところで「こんなふうにパフォーマンスをしたぜ」みたいなことをもう少し教えていただけるとうれしいです。これが2点目。

あと3つ目が、すごくミクロな話で、ちょっとちゃんと見られていなかったのでアレなんですが、システムをデザインしたところ、「GoとTypeScriptでSPAでやったぜ」みたいなところで、監査ログがあったじゃないですか。

川中：はいはい。

藤本：監査ログを出すと、そことプロダクトのデータベースとの整合性を取るのがメチャメチャ面倒だなと僕は思って生きているので。トランザクションを張れないじゃないですか、別のほうに投げると。なので、こっちがコケたら監査ログだけ残ってどうしようとか、いろいろ（あるのですが）、もしそこで工夫したことがあれば教えてください。

あと、どうでもいいことかもしれませんが、ナレッジワークの英語のロゴ（「_KNOWLEDGE WORK」）のアンダースコアがメッチャ気になっていて、あの由来。これは時間がもったいないので、後ででも教えてください。以上です。

川中：質問が全部覚えられているかどうか定かではないので、ミスっていたら教えてください。

初期は、基本的にはリファラルです。CEOがけっこう集めてくれた部分もあるんですが、CEOがプロダクトマネージャーを集めて、プロダクトマネージャーがいろいろな人に声をかけて、僕がたまたま出会って、そこから声をかけて、エンジニアの方と面接をして、「君たち、本当に実力あるの？」と僕が聞いて、一緒に集めたというかたちになります。だから、最初はもうほぼリファラルです。20名ぐらいのうち、18名ぐらいまではリファラルみたいな感じです。

僕はバックエンドの専門家として、チームとして働いていました。なので、バックエンドは僕がやっていた感じです。

あとは何でしたっけ？　監査ログと。

藤本：そうですね、監査ログとトランザクションの整合性をどうやって取りましょうねという。

川中：何をやったかというと、そこはすべてイベントベースで駆動するようにしています。トランザクションを張った時に、イベントをPub/Subみたいなところに投げて、その監査ログを書くだけの人を作っています。

Pub/Subは書くのに失敗すると、また後で投げることができるので、まぁ、失われないであろうと（考えて）、そういうアーキテクチャを取っています。

「_KNOWLEDGE WORK」のKのところですが、実はナレッジワークを作る前に別の会社を作ろうとしていて、そこからいろいろ派生させようと思っていました。その会社は最後がアンダースコアだったので、「つながっていく」みたいなところを表していた感じです。

藤本：ありがとうございました。

ユーザーインサイトの探索プロセスはCEOが担当

司会者：はい、お願いします。

山本正喜氏（以下、山本）：ありがとうございます。エキスパートによる完全分業体制をはじめからやるというところが、すごく珍しくておもしろいなと思っています。特に最初からPdMがいて、CEOがPOを兼務して、CTOがいて、デザイナーもいるというところで、そこは誰が旗を振っていくのか、誰がユーザーインサイトを取っていくのか。初期の頃は、探索をしなきゃいけないじゃないですか。

川中：そうですね、はい。

山本：その探索プロセスにはどんなふうに関わっていたのか、教えていただけますか？

川中：探索プロセスは、実はCEOがかなりやっていた部分があります。PdMは、もともと前の会社でPdMをしていた方を一緒に迎えることができて、PdMとしてお願いしたというかたちです。

社長、CEOが探索をしてくれて、かつ、そこから売ってきてくれて、ユーザーのことも全部聞いてきてくれて、「プロダクトシェアデイ」みたいなものが後期にできたのですが、初期の頃は、そこからエンジニアに1つ1つ教えてもらったというかたちになります。

山本：ありがとうございます。

司会者：残り1分です。

社長がビジネスサイドのPOでも問題はなかった

竹内真氏（以下、竹内）：ちょっと感覚的な話をしてしまいますが、僕がいろいろな会社を見てきた感じ、ビジネスサイドの社長がPOをするとうまくいかないことが多いなと思っていまして。

川中：（笑）。

竹内：エンジニアの観点がないがゆえに、「こういうUIにしたい」「こういうUXにしたい」と実際の開発工数を理解できていないまま要求してしまうことがやはりあって、作るほうが疲弊するというのを見てきました。

そういうことがあったのか、それともなかったのか、あったとしたら、どんなふうに打開していったのか、教えてもらっていいですか？

川中：あったかなかったかで言うと、ほぼなかったです。というのは、デザイナーに委ねられていた（からです）。誰が決めるかを決める会社になっていて、デザインのところはきちんとデザイナーが考えて、最終的にはPOが承認するというかたちになっていたので、そこまで問題にはならなかったですね。

竹内：ありがとうございます。

司会者：ありがとうございました。時間になりました。

川中：はい、ありがとうございます。

司会者：ここまでは川中さんでした。ありがとうございました。

（会場拍手）