スタートアップの創業期は、プロダクト開発だけでなく企業文化を形成する上でも非常に重要な時期となります。
本記事では、「Developer eXperience Day 2024（DXD）」（主催：日本CTO協会）にて「成長期に歩みを止めないための創業期の開発文化形成」をテーマにおこなわれたセッションの内容をお届けします。
このセッションでは、株式会社ナレッジワーク CTOの川中 真耶さんが、同社における開発文化形成の体験談をご紹介してくださいました。
川中 真耶さん
東京大学大学院情報理工学系研究科コンピュータ科学専攻修士課程修了。日本IBM東京基礎研究所研究員やGoogleソフトウェアエンジニアなどを経て株式会社ナレッジワークを共同創業。CTO of the year 2022 ファイナリスト。「王様達のヴァイキング」（週刊ビッグコミックスピリッツ）技術監修。
目次
文化をつくる上での前提条件
プロダクトと開発文化は紐づいています。文化は、一元的にこれがよい・悪いというものではありません。プロダクトと文化は密接に関連しているため、そのプロダクトをつくりやすく売りやすくするための開発文化を、それぞれの会社でつくる必要があります。これからお話しするのはあくまでナレッジワークの事例ですので、それぞれ自社のプロダクトに合うかどうかを考えていただきたいです。
ナレッジワークでは、エンタープライズ向けのBtoB SaaSを開発しています。エンタープライズとは、3,000人くらいの従業員がいる会社です。だからナレッジワークでは、エンタープライズ向けの開発文化を形成しています。
ナレッジワーク社が目指したイネーブルメント文化
ナレッジワークが目指した文化を、「イネーブルメント文化」と名付けました。イネーブルメント文化には専門分化・情報流通・高再現性という3つのテーマがあります。
簡単に言うと、専門分化はまず仕組みや再現性を無視して、とにかくできる人がレベルの高いことをする。そうすることで、最高レベルの基準が上がります。その次の情報流通で、「レベルが高い人はこのようなやり方をしています」と伝えていく。次に高再現性で、できない人も同じ水準でできるようにするにはどうすればよいかを型化していく。こういったことを最初の3年間で考えてきました。
専門分化＝みんなが専門性を発揮
専門分化は、「みんなが高い専門性を発揮できる文化」です。高い基準をきちんと定義して、その基準を決める人も決めています。
ナレッジワークでは、プロによるプロの基準がそこらじゅうにあるのがよい文化だと考えています。創業初期から、可能な限り専門家が専門領域で仕事をできるようにしてきました。バックエンドに強い人は、片手間でフロントエンドの仕事をしたりせず、きちんとバックエンドの仕事をする。最初につくったものは組織が大きくなっていくにつれて拡大していきます。フロントエンド専門の人が後から入ってきて、「なんだこれ」となるのを防ぐためです。
もう一つ全社的な文化として、「決める人と決める場所を決める」を徹底しています。スタートアップは社長がすべて決める専制政治になりがちですが、メンバーとしてそのような環境で仕事をしたいかというと微妙ですよね。我々は民主主義をよしとしています。民主主義というと多数決や全会一致と思われがちですが、それはそれでスタートアップのよいところであるスピードが失われてしまいます。
だから我々は、決める人と場所を決めています。たとえば、「これについてはこの会議で決めます」と事前に通達します。最終意思決定責任者を決めて、その人に最終的な権限を持たせていますが、誰か1人に最終的な権限だけがある状態だと、その人だけを裏で懐柔すればよいとなってしまうため、この会議で決めるということを伝えています。
決める会議の中でみんなに意見を言ってもらって、みんながある程度納得したら、初めて最終意思決定責任者が決める。たとえばA案とB案があって80点と20点ならすぐ決まりますが、51点と49点みたいなときはなかなか決まりませんよね。そういうときは最終意思決定責任者が決めて、早く進めるのが正義だと考えていいます。
スタンダードを決めるための意思決定会
意思決定会の話です。開発に関する細かいスタンダードを決める場所として、意思決定会を週一で実施しています。
ナレッジワークでは、フロントエンドギルド、バックエンドギルド、QAギルドといった形で、職種が同じ人たちを集めた組織をギルドとして組成しています。昔は組織図上、フロントエンドグループ、バックエンドグループといった感じでしたが、最近はマルチプロダクトになってきたので、プロダクト単位でグループを組みました。その上で、バックエンド同士やフロントエンド同士でも話がしたいということでギルドを組成しています。我々はプロダクト単位でグループがわかれていても、ソースコードを共有しています。どこかのグループのバックエンドがこうすると言ったら、ほかのグループもなるべく同じようにしてほしい、スタンダードを決めてほしいとなる。だからスタンダードを決める意思決定会を実施しています。
事例としては、UUID v4をずっと使っていたけどv7を使いたいという話があって、勝手にどこかのグループが使い出すこともできるのですが、議題に挙げました。そこでデメリットなどの話をして、いったん否決となっています。
このように、標準は誰かが勝手に決めるのではなくて必ず意思決定会に上がります。だから新入社員でもインターンでも、誰でも提案できます。私の一存で決めることもありません。みんなで議論して決めるので、みんながよいと思うものが決まっていく仕組みです。
Biz↔︎Dev間における情報流通
専門分化を進めると、各々で専門分野を深掘りしていくことになりますが、それを横につなげる情報流通が重要です。情報流通で大事なのは、Biz（営業組織）↔︎Dev（開発組織）における情報流通の仕組みと、Dev内の情報流通の仕組みです。
情報流通のなにが難しいのか。Bizが強いかDevが強いか、どこの会社でもだいたいどちらかが強いんです。理想としてはBizとDevのバランスがとれている状況が好ましいと考えており、なるべく対等な関係を目指しています。
Bizは顧客の矢面に立っているので、「このプロダクトいいね」も「こうしてほしい」も言われます。ただDevに降りてくるのは「こうしてほしい」だけで、「これがよかった」という話はあまり来ません。そうすると、エンジニアもモチベーションがわかなくなります。それで「Bizの言うことはあまり聞きたくないな」となって、Bizも「Devが聞いてくれない」と思うので、徐々に仲が悪くなっていってしまう。
これを解決するためにナレッジワークでは、BizからもDevからもプロダクトに対する要望を言い合ったり情報を提供しあったりする場として、プロダクトシェアデイをつくりました。分化が進むにつれて、お互いがなにをしているのかわからないという状況を防ぐためです。
具体的にはDevがPdM、BizがPMMを立ててそれぞれに話してもらいます。PdMはプロダクトをどのように売っていこうという戦略や、プロダクトの機能、顧客の業種やこの業種にはこの機能がどれだけ刺さるかなどが書かれたプロダクトマップをもとに説明します。また、ロードマップや開発スケジュールも提供します。
逆にBizからDevへ展開するのは、バリューマップや要望詳細などです。バリューマップとは市場がどのようなものを求めていて、我々がなにを提供しているのかを書いたものです。市場がこういう製品や機能を求めていて、我々がどこまでつくれていて、どこからはつくれていないから、このような機能をつくってほしいとDevに要求します。
Dev内の情報流通とドキュメント
我々はドキュメントをきちんと書く文化を創業当初からつくっています。ミニスペックやデザインドック、デザインドック、ポストモーテムなどをすべて書いてきました。
ミニスペックには解決すべき課題やユーザーボイスがあって、その上で「これをつくればこのユーザーの課題は解決できるのではないか」という話がまとめられています。開発ミーティングが週に1、2回あるので、持ち込んで話し合いに使うのです。
ミニスペックをもとに書くのがデザインドックです。「こんなものをつくりましょう」となった上で、RDBのテーブル構造やビッグクエリにはこうして保存しましょう、APIはこうしましょうといったことをすべてドキュメント化しています。これをみんなでレビューしてから開発を進めます。これを書かないと、プルリクで設計のやりとりが始まってしまうので、それを防ぐためにも必要です。
次にテストデザインドックです。これもミニスペックからつくっているもので、「ミニスペック上こういう仕様があるので、テスト計画はこうあるべき」というドキュメントを残します。
最後にポストモーテムです。リリースしたときにインシデントがあれば、必ずポストモーテムをつくります。このようなことが起きて、原因はこれで、いつ発生していつ検知して、いつ終わらせたかが書かれています。またネクストアクションとして、この事故が二度と起きないようにするにはどうすべきかも書いています。このネクストアクションは3か月以内に終わらせるのが目標です。
ドキュメントの徹底は善か？
ナレッジワークではドキュメントを徹底して書いてきました。これが善かというと、もちろんプロダクトによるでしょう。
ナレッジワークは書くほうに振りましたが、結果としてドキュメントのおかげで助かっていることは多いです。新入社員が「ここってどうなっているんですか」と疑問に思ったときも、過去のドキュメントを調べればわかります。ただ、コストは高いです。ドキュメントを書かなければ、もっと開発を進められただろうなとも思います。あとはレビューの負荷が偏っていて、私やリーダーに偏りがちなところもあります。
ただデザインドックは新入社員やインターンにも書いてもらうので、設計の練習には非常にいいですよ。最初は大量の訂正が飛んできたりしますが、半年くらいするとみんなある程度書けるようになって、設計もできるようになります。だから教育としても効果的だと思います。
高再現性を実現するための型化
我々が再現性で重要だと思っているのは、型化です。プロダクトマネージメントの型化と、どのように成長していくかも、スキルマップとガイドラインをつくって型化する。プロダクトマネージメントの型化は、最初はなにもないので、とにかく頑張ることから始まります。その後、うまくいったものを型化する形です。
プロダクトは4つのフェーズでできていきます。最初はカスタマープロブレムフィット。顧客に対して課題があるかをヒアリングします。その次にプロブレムソリューションフィット。課題を解いて、このような機能があったら買ってくれますかという提案書をお客さんに持っていく。そこで10社中3社が買ってくれるとなったら、次のソリューションプロダクトフィットに進んで開発が始まります。3〜6か月くらいでプロダクトが1個できたら、それを顧客に無料で使ってもらいます。その後、顧客にショーン・エリス式のテストで「このプロジェクトがなくなったらどう感じますか」と聞いて、「大変残念」が40%を超えたらプロダクトマーケットフィットであると定義しています。
スキルマップとガイドラインの策定
エンジニアと開発の型化について。まずはスキルマップをつくりました。項目としては、プロダクト理解や技術戦略、設計・実装・運用などが重要だと考えています。たとえば若手がVPやシニアやミドルになるにはこれくらいのことをしてほしい、今のあなたはプロダクト理解はミドル、技術戦略はミドル、設計はシニアなどと提示して、シニアに上がったらこのようなことができてほしいといったコミュニケーションに使っています。
あとはガイドラインやハンドブックです。たとえばスプリントコップというのは当番のアラートです。この当番はなにをするのか、スプリントコップを見ればわかるようになっています。バックエンドエンジニア向けのスキル面接アセッサーガイドラインには、スキル面接のコーディングインタビューはこういう観点で評価して、こういうやり方で進めてくださいといったことがすべて書かれています。
取材後記
本セッションでは、ナレッジワークにおける開発文化形成の歩みを事例とともにご紹介いただきました。
川中さんはこのセッション内で、たびたび「これはあくまでナレッジワークの事例であり、なにがよい文化かは企業によって違います」と話していました。
たしかに一言でスタートアップといっても、プロダクトや事業内容、置かれているフェーズや組織の規模などによって、最適な文化形成は異なるはずです。
ナレッジワークの事例をヒントにしながらも、常に自社にとっての本当によい文化とはなんなのかを考えていきたいと思います。
（取材／文：谷口智香）
