Tweet
Tweet

Slide 1

Slide 1 text

成長期に歩みを止めないための 創業期の開発文化形成 株式会社ナレッジワーク CTO 川中真耶 (mayah) Developer eXperience Day 2024 講演資料

Slide 2

Slide 2 text

© Knowledge Work Inc. 講演者プロフィール 2 株式会社ナレッジワーク CTO 
 川中 真耶
 主な経歴
 2006 東京大学大学院情報理工学系研究科コンピュータ科学専攻
 修士課程修了
 2006 日本IBM 東京基礎研究所リサーチャー
 2011 Google Japan ソフトウェアエンジニア
 2020 株式会社ナレッジワーク共同創業
 
 王様達のヴァイキング(週刊ビックコミックスピリッツ)技術監修


Slide 3

Slide 3 text

© Knowledge Work Inc. Profile　会社概要 3 ナレッジワーク 会社概要 創業日 　2020年4月1日 代表者 　麻野 耕司 資本金 　61.3億円（資本準備金等含む） 事業内容 　ナレッジワークの開発・提供 主な株主 　グロービス・キャピタル・パートナーズ、DNX Ventures、WiL 　Salesforce Ventures、One Capital、ANRI、XTech、 　ユーザベース、フォースタートアップス、Sansan

Slide 4

Slide 4 text

© Knowledge Work Inc. 4 できる喜びが巡る日々を届ける Deliver the joy of enablement 「昨日できなかった仕事が今日できるようになった」 「今日うまく進められなかった仕事も明日はうまくできるかもしれない」 そんな想いで働ければ、仕事に希望が持てるはずです。 しかし、世の中の多くの人が「上司に恵まれない」「職場に恵まれない」 「会社の仕組みに恵まれない」などの理由で、 「努力しても成長できない」「努力しても成果が出ない」つまりは 「努力しても報われない」という環境で仕事をしています。 私たちは『イネーブルメント』を実現するプロダクトを提供することで 世の中の人たちが仕事にできるようになることを支援し、 働く喜びが巡る日々を届けます。

Slide 5

Slide 5 text

© Knowledge Work Inc. セールスイネーブルメントクラウド「ナレッジワーク」 
 5 みんなが売れる営業になる 
 セールスイネーブルメントクラウド 
 営業力強化・営業生産性向上 を１つのツールで実現 


Slide 6

Slide 6 text

© Knowledge Work Inc. ナレッジワーク 導入実績（一部の企業様のみご紹介しています） ナレッジワークは、多くの大手企業様に数千名規模でご利用いただいています 6

Slide 7

Slide 7 text

© Knowledge Work Inc. 3年で10個のプロダクトをリリースする マルチプロダクト展開という新たなステージを迎えます 7 2020.4 2020.10 2021.10 創業 プロダクト 無償版リリース プロダクト 有償化 2022.4 プロダクトリリース シリーズ Aファイナンス 2024.4 マルチプロダクト リリース（予定） シリーズ Bファイナンス 2023.11 会社沿革

Slide 8

Slide 8 text

本編

Slide 9

Slide 9 text

© Knowledge Work Inc. 9 開発文化？ 開発文化 テスト駆動開発 マイクロサービス 開発即リリース ドキュメント重視 データドリブン 設計重視 ビジネス主導 エンジニア主導 みなさまの会社の開発文化はどんなものですか？ アジャイル フラット ウォーターフォール モノリシックアーキテクチャ

Slide 10

Slide 10 text

© Knowledge Work Inc. 10 開発文化の善し悪し プロダクトと開発文化は紐付いており プロダクトに合う文化・合わない文化がある 開発文化 プロダクト

Slide 11

Slide 11 text

ナレッジワーク社の文化

Slide 12

Slide 12 text

© Knowledge Work Inc. 12 ナレッジワーク社のプロダクト Enterprise 向け B2B SaaS

Slide 13

Slide 13 text

© Knowledge Work Inc. 13 B2B をやったことがない人には意識しにくい差がある 開発に限らず営業を含めた全体の戦略が必要で その戦略にのっとって開発文化を形成していく必要がある Enterprise B2B SaaS における開発の特徴 Enterprise B2B SaaS to C 顧客の声 営業を通じて具体的に聞ける 製品を出す前に実際の対象顧 客にヒアリングできる 多いように見えても データを通じてしか 分からないかもしれない 機能リリース 顧客は使い方を全社に周知する ためのコストを払っており 高頻度の機能リリースが好まれ ないこともある A/B テストが嫌われやすい 高頻度にリリースしても良い A/B テストができる

Slide 14

Slide 14 text

© Knowledge Work Inc. ナレッジワーク社の場合 ● 創業当初から資金調達できており、会社を（かなり）大きくすることが求められる ● 明日の食い扶持を心配するのではなく、思ったように大きくできないこと、持続的に大きくできないことを心配する必要があ る 14 文化を作る上での前提条件

Slide 15

Slide 15 text

© Knowledge Work Inc. 15 ナレッジワーク社が目指した文化 イネーブルメント文化 専門分化 高再現性 情報流通

Slide 16

Slide 16 text

イネーブルメント文化 1. 専門分化

Slide 17

Slide 17 text

© Knowledge Work Inc. 17 専門分化 高い基準の 定義 意思決定者と 意思決定場所 の定義 専門家による高い基準の整備と、その構築体制を支援します

Slide 18

Slide 18 text

© Knowledge Work Inc. 18 専門家による高い基準の獲得に注力する ● 専門家による初期基盤の整備 ○ 初期の構造は、組織が大きくなるにつれてそのまま引き延ばされることが多い ■ 最初期にきちんと設計しておくことで組織が拡大しても耐えられる設計を作ることができる（少なくともやり直 しを数年先送りできる）と信じて推進 ○ 創業初期からフロントエンド開発とバックエンド開発に別れてそれぞれの開発領域の整備 ● 決める人と決める場所を決める ○ 最終意思決定者を明確にする ■ 最後に責任を持つ人を明確にする ○ 決める場所（会議体）を決めておき、議題をだれもがあげられるようにする ■ 意思決定者も間違えるため ■ 意思決定者が独善的にならないため ■ 誰もが意見を言えるようにするため ■ 意思決定者だけを懐柔して議案が通すことを防ぐため ○ Frontend / Backend ギルド　意思決定会 ■ 細かな開発ガイドラインを決定していく場所（スタンダードなモジュール構造は何か、など） 専門分化

Slide 19

Slide 19 text

© Knowledge Work Inc. 私たちは才能を掛け合わせることで価値が生まれると考えます。 そのために、ひとりひとりの才能に着目し、 コラボレーションが生み出される組織を作ります。 19 Policy Management Actions　マネジメント行動定義 コミュニケーション 組織編成 人材育成 人材採用 Collective genius 「集合天才を生み出す」 制度設計 優劣関係 総合対応 課題指摘 均質優秀 画一成長 補完関係 長所活用 期待賞賛 異能才能 多様進化 ＜ ＜ ＜ ＜ ＜ 19 社内文化資料

Slide 20

Slide 20 text

© Knowledge Work Inc. 専門家による基盤の整備 20 専門家による初期基盤の整備 ● frontend, backend で初期から分化して開発 ● API 定義で frontend/backend 間で齟齬がでないように最初から schema (protobuf) 駆動開発を行う ○ schema だけは双方でレビューする これは実際に人数が増えてこないと効果は分からなかったがエンジニアが 10 人を超えてきた頃から効果を実感 ● frontend メンバーの言葉 ○ frontend を専門でやっている人が初期にいない場合 backend エンジニアが frontend も最初に書くことになるが、 大体全部書き直すことになるので良かった ● backend メンバーの言葉 ○ schema がきちんとしていて backend のことだけ考えれば良いのでやりやすい 振り返り ● フルスタックを良しとする文化もありえるが、frontend, backend をどちらも高い基準でできる人は少ないため、この方式を 選択した ● 初期に frontend メンバーを揃えられなければ別の戦略をとった可能性がある (schema 駆動にならなかった可能性もあ る)

Slide 21

Slide 21 text

© Knowledge Work Inc. 21 開発に関する細かな標準を決める場所 ● 週1回、30分で開催 ● 議案を当日 12:00 までに書く必要がある ○ なければ開催されないし、12:00 に一分でも遅れると (CTO 起案でも) 容赦なく来週に回される ● 最終意思決定者は CTO とギルドマスター ● 非参加者は白紙委任状を出しているとみなされる ● 毎回平均 2~3 個の議題 この方式は結構おすすめできる ● 参加者で pros/cons を出し合って議論できる ● 知らない場所で勝手に技術的スタンダードが決まることを防 ぐ 「決める人と決める場所を決める」というやり方は、全社の意思決定 方針として統一されている 意思決定会 実際にあった議題の例 ● UUID v4 じゃなくて UUID v7 を標準にしま せんか ○ すでに v4 の場所を v7 にしてもメ リットがないが新規の場所であれば メリットがあるか？ ○ シーケンシャルに id が並ぶことに よる pros/cons の議論、特に将来 的に newsql に移行することに支障 はないか？ ○ → 現時点では否決 ● モジュールのレイヤー構造が歴史的理由 で過度に多い部分があるので減らした構 成を標準にしませんか ○ → 可決 ● DB からのデータは可能な限り int32/int64 で受けませんか ○ → 可決

Slide 22

Slide 22 text

イネーブルメント文化 2. 情報流通

Slide 23

Slide 23 text

© Knowledge Work Inc. 23 情報流通 Biz ↔ Dev* の 情報流通の 仕組み Dev 内での 情報流通の 仕組み 専門分化を進めたときに絶対に問題になるコミュニケーション不全に対処します *Biz は営業組織を指し Dev は開発組織を指す

Slide 24

Slide 24 text

© Knowledge Work Inc. 24 お互いが何をやっているか分からないことを防ぎ 情報流通を行うことで相互の不信感を取り除きお互いが補完できる状況を作ります Biz ↔ Dev の情報流通の難しさ 理想的な状況 
 陥りがちな状況 
 組織がアンバランスで主導権が一方にある Biz が Dev に要望ばかり押しつける Dev が Biz に必要な機能を作らない Biz と Dev がバランスして 相互に補完し合っている状態 Biz Dev ＜ Dev Biz ＞ Biz Dev =

Slide 25

Slide 25 text

© Knowledge Work Inc. 25 情報流通を行うことで相互の不信感を取り除きお互いが補完できる状況を作ります Dev から見た Biz へのありがちな不満 理想的な状況 
 陥りがちな状況 
 プロダクトが賞賛されても Dev にまで届かな いのに要望だけは事細かに伝えてくる 賞賛も要望もきちんと Dev に フィードバックされる Dev Biz 賞賛 要望 Dev Biz 賞賛 要望

Slide 26

Slide 26 text

© Knowledge Work Inc. 前提：プロダクト開発の流れ 26 マーケットや顧客情報を Devに伝え、 開発された機能をマーケットや顧客に届け切ります PdM IS MRK DS CS Security Design Frontend Backend QA PMM PO ②開発要望 Bizの情報を中心として、 マーケットや顧客視点の 要望を Devに届け切る ①開発展開 Devが開発した機能を マーケットや顧客に 届け切る Biz と Dev をつなぐため 全社のプロダクトシェアデイを設計

Slide 27

Slide 27 text

© Knowledge Work Inc. プロダクトシェアデイ 27 プロダクトや顧客の現状を Biz, Dev ともに知る場所 ● 毎週１時間 ● 全社組織が大きくなって Biz と Dev でのコミュニケーションが難しくなってきてから始めた

Slide 28

Slide 28 text

© Knowledge Work Inc. プロダクトシェアデイの全体像 28 ②開発要望（ PMM） 時間：20分 ①開発展開（ PdM） 時間：32分（全体8分＋各領域8分） バリューマップ 1 【今回】要望詳細 2 【今回】要望サマリー 3 プロダクトシェアデイは 「①開発展開」「②開発要望」を基軸に進めていきます 【過去】要望サマリー 4 戦略 1 計画：【製品課題】プロダクトマップ 2 計画：【開発方針】ロードマップ 3 計画：【開発計画】開発スケジュール 4 リリース紹介 &デモ実施 5

Slide 29

Slide 29 text

© Knowledge Work Inc. おまけ：　全社内情報流通 29 創業時から行っている全社施策が２つある Quarterly Session ● 毎 Q、１日４時間を３日使って 、全社、部門、個人のプラ ニングを行う ● 各グループの Q の戦略を決めるために、事前に少なく とも２時間以上話し合う ● Build your company の精神の元、各メンバーのやりた いことと部門のやりたいことが擦り合うようにする Monthly Session ● 月末、２時間を使って、全社、部門、個人の一ヶ月の振 り返りを行う 戦略目標の納得感の醸成 戦略目標の納得感は 会社に対するエンゲージメントと 非常に相関が高い 会社の方針を理解・納得できるよ うにみんなが方針を議論できる時 間を設けている

Slide 30

Slide 30 text

© Knowledge Work Inc. 私たちは会社は皆で作る作品であると考えます。 そのために、誰もが組織運営を自らの責任と捉えて、 積極的に行動をすることができる組織を作ります。 30 Policy Management Actions　マネジメント行動定義 コミュニケーション 組織編成 人材育成 人材採用 制度設計 Build your company 「会社は皆で作る作品である」 沈黙評論 責任集中 自己成長 人事採用 専制君主 質問提案 役割分担 相互支援 全員採用 民主主義 ＜ ＜ ＜ ＜ ＜ 社内文化資料

Slide 31

Slide 31 text

© Knowledge Work Inc. 31 Dev 内の情報流通 要件定義・デザイン 計画 QA リリース 実装 minispec 機能設計文書 DesignDoc 内部設計文書 TestDesignDoc テスト計画 Postmortem 障害事後分析文書 創業当初から各開発プロセスでドキュメントを作っています

Slide 32

Slide 32 text

© Knowledge Work Inc. 32 minispec: 要件定義 → 実装・QAへのドキュメント 解決すべき課題 ユーザーボイス ユーザーストーリー 代替案など 社内フィードバック 詳細仕様 実装時の仕様書となる minispecは、必 ず解決したい課題（Why）を明確にした 上でお客さまの声・社内の声も踏まえ What/Howを決定しています 以下の項目があります

Slide 33

Slide 33 text

© Knowledge Work Inc. 33 Design Doc: 実装内部でのドキュメント Objectives（概要） Background（背景） System Overview（設計概要） Detailed Design（詳細設計） Caveats（設計の注意事項） Scalability（スケーラビリティ） …等 minispec をもとに、実装のポイントとなる部分を DesignDoc に落とし、システムアーキテクチャやテーブル 設計を実装前に議論しています。バックエンド側で設計が 難しいものは、可能な限り DesignDoc を書くようにしてい ます。 以下のような項目があります。

Slide 34

Slide 34 text

© Knowledge Work Inc. 34 Test Design Doc: テストのためのドキュメント テストベース（対象定義） テスト対象の分析 テスト設計仕様 テストケースとテスト実施結果 minispec をもとに、テストのポイントとなる部分を TestDesignDoc に落とし、テスト設計について議論してい ます。 以下のような項目があります。

Slide 35

Slide 35 text

© Knowledge Work Inc. 35 Postmortem インパクト 原因 タイムライン 詳細 振り返り Next Action 障害が起こった場合は事後分析を行っています 以下のような項目があります。 特に NextAction を全てこなしているかを指標の一つとし て追っており、３ヶ月以内に全てのアクションを終わらせな ければなりません。

Slide 36

Slide 36 text

© Knowledge Work Inc. ドキュメントはどれだけ書くべきか？　は悩ましい ● ナレッジワークでは書く方に振った ● 結果として新規入社者の理解に助けになっているし、実装で分からないことがあってもドキュメントのおかげで助かってい ることもある ● 一度書くと非同期で物事を進められるようになる ● 一方で書くコストはそれなりに高い ● DesignDoc は設計を tech lead だけでなくだれでもやるようにしているため、大きな設計をするときはかならず書いても らっている ○ 誰もが最初は本当にろくに書けず、レビューで全面真っ赤に書き直される ■ 考慮漏れ、曖昧、問題に対して取った設計が難しすぎる ■ 日本語になってない、ロジックが通ってない ○ 徐々にできるようになっていき、半年ぐらいたたき込まれるとレビューコメントが数点ぐらいになる ○ ナレッジワーク社では設計を重視しているため教育の場にもなっている ● 作っては壊しを繰り返しているのならばメリットよりコストの方が高い可能性がある ● レビューするにはかなりの技術力が必要で、一部の人に負荷が偏りがち 36 ドキュメントの徹底は善か？

Slide 37

Slide 37 text

イネーブルメント文化 3. 高再現性

Slide 38

Slide 38 text

© Knowledge Work Inc. 38 高再現性 プロダクト マネジメントの 型化 スキルマップと ガイドラインの 策定 高いレベルの基準を社内を巡るようにしていきます

Slide 39

Slide 39 text

© Knowledge Work Inc. 最初は試行錯誤、これは避けられない うまくいったら成功のポイントを言語化して型化し、次の同じプロダクト開発に生かす 39 プロダウトマネジメントの型化

Slide 40

Slide 40 text

© Knowledge Work Inc. プロダクトマネジメントプロセス 40 顧客価値の高いプロダクトを開発するためのプロセスが定義されています フェーズ 対象 課題 課題 価値 価値 機能 機能 市場 ス テ ッ プ PMM ①課題把握 ②課題判断 ③価値定義 ④要件定義 ⑥顧客展開 ⑤開発実装 ⑦成果創出 ⑧利用把握 Customer Problem Fit Problem Solution Fit Solution Product Fit Product Market Fit PdM

Slide 41

Slide 41 text

© Knowledge Work Inc. 41 開発者の成功モデルも言語化し、スキルマップとして定義 良いと考えられているやり方、標準とされるやり方はガイドラインやハンドブックを書いて型化 ● こまったらハンドブックを見ながら作業できる ● ハンドブックがあることはイネーブルメントの一環であると捉えている スキルマップとガイドラインの策定

Slide 42

Slide 42 text

© Knowledge Work Inc. スキルマップ プロダクト理解 技術戦略 設計 実装 運用 VP ・中長期(1〜3年)の会社の戦 略を理解し、技術的な側面か ら議論が行える ・複数の事業を横断したプロダ クトの機能や価値を理解でき、 技術的な観点から議論ができ る ・中長期(1〜3年)の技術戦略を策定 できる ・自社の技術の理想を策定し、逆算し て、プロダクトに導入できる ・複数の事業を横断した設計ができ る ・複数の事業を横断して活用できるラ イブラリや仕組みを実装できる ・中長期（1〜3年）を見据えて、よりイン シデントが発生しにくい仕組みを考案 し、組織に導入・定着できる ・複数の事業を横断した一貫性のある 運用の仕組みを提案・導入できる シニア ・自部署が開発しているプロダ クトの機能や価値を理解でき、 他部署と適切に議論しプロジェ クトの推進ができる ・短期(四半期〜１年)の技術戦略を策 定できる ・担当領域の技術的な潮流を読み、自 部署の開発に導入できる ・Design Docを機能要件・非機能 要件（スケーラビリティ・セキュリティ ・UX）両面の観点からレビューでき る ・多人数で開発することをふまえて仕 組みを工夫した実装ができる ・非機能要件（スケーラビリティ・セ キュリティ・UX）を考慮して実装できる ・上記をふまえたコードレビューができ る ・十分な実装スピードがある ・インシデントが再発しない仕組みを発 案・実装できる ・他部署と協力してインシデントを解決 に導くことができる ミドル ・独力でminispecを理解で き、技術的な観点から議論が できる ・自部署が開発しているプロダ クトの機能や価値を理解でき る ・自部署の技術戦略を自身の開発に 落とし込むことができる ・担当領域の技術的な潮流を読み、自 身の開発に導入できる ・工夫やアイデアが必要な新規の Design Docを独力で完成できる ・複数のアイデアを持ち、その時点 の状況に対して妥当なものを選択で きる ・Design Docに明記されないことも 汲み取って実装ができる ・自分なりの工夫やアイデアを実装に 反映できる ・上記をふまえたコードレビューができ る ・アラートを調査し、原因を特定できる ・インシデントの原因を適切に自部署お よび他部署に報告できる ジュニア ・周囲の支援を受けて、 minispecを理解できる ・プロダクトの機能や価値につ いて、担当範囲において理解 できる ・自身の担当範囲における技術調査 が行なえ、必要があれば周囲に支援 を求めることができる ・周囲の支援を受けて、既存の Design Docを理解できる ・周囲の支援を受けて、新規の Design Docを完成できる ・周囲の支援を受けて、既存や自分が 作成したDesign Docに従って実装で きる ・自分の実装した機能のテスト（単体 テスト・統合テスト・E2Eテスト）が書け る ・担当期間中にアラートを監視し、イン シデントの予兆に気づくことができる ・インシデントの予兆を捉えた場合に周 囲に相談・報告できる 社内資料一部改変

Slide 43

Slide 43 text

© Knowledge Work Inc. 標準を定めハンドブックやガイドラインとして多数整備 作成を毎 Q の目標に入れて整備をしてきた 43 ガイドラインやハンドブック

Slide 44

Slide 44 text

これから創業期を駆け抜ける人たちへ

Slide 45

Slide 45 text

© Knowledge Work Inc. 成長期に歩みを進めるには プロダクトに合わせて ぶれない開発文化を作ろう 45

Slide 46

Slide 46 text

No content