2024.10.01
自社の社内情報を未来の“ゴミ”にしないための備え 「情報量が多すぎる」時代がもたらす課題とは?
株式会社ナレッジワーク(全1記事)
リンクをコピー
記事をブックマーク
川中真耶氏(以下、川中):「規模が拡大しても耐えられる創業期のシステム・組織設計」というタイトルで発表させていただく(川中)真耶です。よろしくお願いします。
まず自己紹介なのですが、僕はずっと技術で飯を食ってきた人間です。大学で情報科学を学んで、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構造を取っています。
私たちはセキュリティがけっこう大事なのですが、最初からきちんと設計ができていたおかげで、ファイルを扱うような少し危ないところは外出しするということも、最初の設計からできています。それも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のところですが、実はナレッジワークを作る前に別の会社を作ろうとしていて、そこからいろいろ派生させようと思っていました。その会社は最後がアンダースコアだったので、「つながっていく」みたいなところを表していた感じです。
藤本:ありがとうございました。
司会者:はい、お願いします。
山本正喜氏(以下、山本):ありがとうございます。エキスパートによる完全分業体制をはじめからやるというところが、すごく珍しくておもしろいなと思っています。特に最初からPdMがいて、CEOがPOを兼務して、CTOがいて、デザイナーもいるというところで、そこは誰が旗を振っていくのか、誰がユーザーインサイトを取っていくのか。初期の頃は、探索をしなきゃいけないじゃないですか。
川中:そうですね、はい。
山本:その探索プロセスにはどんなふうに関わっていたのか、教えていただけますか?
川中:探索プロセスは、実はCEOがかなりやっていた部分があります。PdMは、もともと前の会社でPdMをしていた方を一緒に迎えることができて、PdMとしてお願いしたというかたちです。
社長、CEOが探索をしてくれて、かつ、そこから売ってきてくれて、ユーザーのことも全部聞いてきてくれて、「プロダクトシェアデイ」みたいなものが後期にできたのですが、初期の頃は、そこからエンジニアに1つ1つ教えてもらったというかたちになります。
山本:ありがとうございます。
司会者:残り1分です。
竹内真氏(以下、竹内):ちょっと感覚的な話をしてしまいますが、僕がいろいろな会社を見てきた感じ、ビジネスサイドの社長がPOをするとうまくいかないことが多いなと思っていまして。
川中:(笑)。
竹内:エンジニアの観点がないがゆえに、「こういうUIにしたい」「こういうUXにしたい」と実際の開発工数を理解できていないまま要求してしまうことがやはりあって、作るほうが疲弊するというのを見てきました。
そういうことがあったのか、それともなかったのか、あったとしたら、どんなふうに打開していったのか、教えてもらっていいですか?
川中:あったかなかったかで言うと、ほぼなかったです。というのは、デザイナーに委ねられていた(からです)。誰が決めるかを決める会社になっていて、デザインのところはきちんとデザイナーが考えて、最終的にはPOが承認するというかたちになっていたので、そこまで問題にはならなかったですね。
竹内:ありがとうございます。
司会者:ありがとうございました。時間になりました。
川中:はい、ありがとうございます。
司会者:ここまでは川中さんでした。ありがとうございました。
(会場拍手)
2024.10.29
5〜10万円の低単価案件の受注をやめたら労働生産性が劇的に向上 相見積もり案件には提案書を出さないことで見えた“意外な効果”
2024.10.24
パワポ資料の「手戻り」が多すぎる問題の解消法 資料作成のプロが語る、修正の無限ループから抜け出す4つのコツ
2024.10.28
スキル重視の採用を続けた結果、早期離職が増え社員が1人に… 下半期の退職者ゼロを達成した「関係の質」向上の取り組み
2024.10.22
気づかぬうちに評価を下げる「ダメな口癖」3選 デキる人はやっている、上司の指摘に対する上手な返し方
2024.10.24
リスクを取らない人が多い日本は、むしろ稼ぐチャンス? 日本のGDP4位転落の今、個人に必要なマインドとは
2024.10.23
「初任給40万円時代」が、比較的早いうちにやってくる? これから淘汰される会社・生き残る会社の分かれ目
2024.10.23
「どうしてもあなたから買いたい」と言われる営業になるには 『無敗営業』著者が教える、納得感を高める商談の進め方
2024.10.28
“力を抜くこと”がリーダーにとって重要な理由 「人間の達人」タモリさんから学んだ自然体の大切さ
2024.10.29
「テスラの何がすごいのか」がわからない学生たち 起業率2年連続日本一の大学で「Appleのフレームワーク」を教えるわけ
2024.10.30
職場にいる「困った部下」への対処法 上司・部下間で生まれる“常識のズレ”を解消するには
2024.10.29
5〜10万円の低単価案件の受注をやめたら労働生産性が劇的に向上 相見積もり案件には提案書を出さないことで見えた“意外な効果”
2024.10.24
パワポ資料の「手戻り」が多すぎる問題の解消法 資料作成のプロが語る、修正の無限ループから抜け出す4つのコツ
2024.10.28
スキル重視の採用を続けた結果、早期離職が増え社員が1人に… 下半期の退職者ゼロを達成した「関係の質」向上の取り組み
2024.10.22
気づかぬうちに評価を下げる「ダメな口癖」3選 デキる人はやっている、上司の指摘に対する上手な返し方
2024.10.24
リスクを取らない人が多い日本は、むしろ稼ぐチャンス? 日本のGDP4位転落の今、個人に必要なマインドとは
2024.10.23
「初任給40万円時代」が、比較的早いうちにやってくる? これから淘汰される会社・生き残る会社の分かれ目
2024.10.23
「どうしてもあなたから買いたい」と言われる営業になるには 『無敗営業』著者が教える、納得感を高める商談の進め方
2024.10.28
“力を抜くこと”がリーダーにとって重要な理由 「人間の達人」タモリさんから学んだ自然体の大切さ
2024.10.29
「テスラの何がすごいのか」がわからない学生たち 起業率2年連続日本一の大学で「Appleのフレームワーク」を教えるわけ
2024.10.30
職場にいる「困った部下」への対処法 上司・部下間で生まれる“常識のズレ”を解消するには