Nota開発部の組織と価値観
akix.iconakiroom.icon
秋山博紀 = akiroom = akix
VP of Engineering / 開発本部長
なぜ「Nota開発部の組織と価値観」?
今回のNota Tech Conf 2022 Springは、開発部全員登壇です
今まであまり「開発部」の存在について説明してこなかった
開発部の価値観(行動指針?)を紹介し、フィードバックを受け、「Nota開発部の教科書」を作りたい
Notaの価値観
Nota開発部とは何か
専門性に基づいて、プロダクトの開発・運用と会社の成長に貢献する部署
2021年8月から部門制を施行
それ以前に「部」という概念は無かった
akiroom.iconの名刺に開発本部長と書かれていたぐらい
2019年ぐらいまではエンジニア率の高いので厳密に分ける意味があまり無かった
割と責務が大きい
Gyazo・Scrapbox・Helpfeelの3プロダクトの開発と成長に責任を負う
特にGyazo・Scrapboxはいわゆる企画的なところも開発部が担う
職種
エンジニア
デザイナー
テクニカルサポート
主にGyazoやScrapboxの問い合わせに対応
実は1名で回している(対応がカリカリにチューニングされている)
コーポレートIT
技術的な解決を重視するために、開発部に入れた
今回のNota Tech Confでは、エンジニアとデザイナーが登壇しています
コーポレートITはエンジニアが兼務
テクニカルサポートの方は長期休暇中で登壇なし
他部署から日英対応で1名ずつ応援に来てもらってる
VPoE / 開発本部長とは何か?
組織によってCTOとVPoEの定義や役割は異なる
CTO・VPoE・VPoPの分立とCTO - Gunosy Tech Blog
CTOとVPoE(VP of Engineering)の違い | Coral Capital
VPoEとは何か? VPoE自身が解説するVPoEの役割と求められる能力、CTOと何が違う? |ビジネス+IT
Notaでは以下に責任を持つ
プロダクトの現在と未来
開発組織の構築と運営・採用
部門間調整
育成・評価・キャリア形成
インシデント対応
社内IT環境
akiroom.iconがNota VPoEとして心がけていること
① サーバントリーダーを目指す
大半の業務は優秀なメンバーが活躍することで回っている
メンバーが活躍できる環境を整えることで、良い感じに仕事が回る状況をつくる
② 革命を起こそうとしない・知ったことを何でも試そうとしない
ハンマーを持った時に釘っぽいものをなんでも打とうとしない
たしかになめらかに前進しているように感じる daiiz.icongocci.icon
グラデーションを許容するフロントエンド(ツール)生存戦略につながりそう。hata6502.icon
③ 出力ではなく成果を最大化する
「機能をできるだけ沢山作る」のような誤った指標を持たない
Nota開発部価値観3選
ドッグフーディング
プロダクトマネジメント的発想
自律的・自己組織的な働き方
ドッグフーディング
自分達で作ったものを自分達で使う
ドッグフーディングとは 意味/解説 - シマウマ用語集
ドッグフーディング(dogfooding)とは、社員が自社製品や自社サービスを日常的に社内業務で利用すること。
元々は、ドッグフード会社のセールスマンが犬用ビスケットを食べて質の高さをアピールした、というエピソードが由来とされている。
シマウマ用語集👀yuiseki.icon
Gyazo, Scrapbox, Helpfeelを使っていく
Gyazo
全社的にほぼ毎日何かしらで使っている
開発部の4職種(エンジニア、デザイナー、カスタマーサポート、コーポレートIT)は、ほぼ確実に毎日使っている
Scrapbox
/Nota(サンプルは/nota-private-sample)
営業情報、面接記録など、共有範囲を絞る目的で複数のプロジェクトを運用
Helpfeel
Welcome to Notaハンドブック
入社時のオンボーディングで利用する資料
アカウントセットアップの方法などが書かれている
自己組織化したマニュアルとして、書いてある内容が陳腐化した場合は、早速修正してもらう
めちゃよさそうminemuracoffee.iconyosider.icon
https://nota.gyazo.com/a950ab27b4d121b66d45374c57da5e0a
セキュリティハンドブック(セキュリティガイドライン)
社内規定の資料
ハウツーを盛り込むためにHelpfeel化
https://nota.gyazo.com/438fea62a8ca801d249b408ed21fabd3
https://nota.gyazo.com/ca13c5c70ecf6092e0ae7e954acd701e
これ今日も使いましたshokai.icon
どういう環境ではVPNを有効化しなければならないのか、それはなぜなのか、がリンク辿ったら理解・納得できて便利だった
よいところ
自分達で使っているのでバグにすぐ気づく
改善しようというモチベーションが高い
自信をもって勧められるプロダクトを作れる
なやみ
組織規模や文脈が異なるユーザーの気持ちが分かりづらい?
もしかしたら「憑依力」「想像力」のような力が必要なのかも?
/nishio/ドッグフーディングの罠にはまるのはまずそうtakker.icon
サービスダウンした時に、仕事がしづらい
Gyazoがダウンした時の様子を、うっかりGyazoって伝えようとする
草yosider.icontakker.icon
プロダクトマネジメント的発想
開発者だから出来る解決を探す
問題を俯瞰する
要望をそのままダイレクトに実装しない
できるだけ、複数の問題の解決を図る
"アイデアとは、複数の問題を一気に解決するもの"
定石を安易に採用しない
例えば、「〇〇といえば〇〇だよねー」を安易に決めず、定石のひとつ上を目指す
例:検索システム
Gyazo
ElasticSearchを利用
大規模なデータセットを検索している
画像だけで毎月2000万〜3000万件のレコードが増える
Scrapboxのページタイトル検索
ローカルで検索、辞書構築をWebWorkerで実装
検索はUI Threadで実行されているtakker.icon
てっきりweb workerで検索しているものだと思ってたので、調べたときは驚いた
ごくたまに固まることがあるかも
複数のアルゴリズムを組み合わせる
詳しくは/shokai/QuickSearchを参照
インクリメンタルサーチはクライアントサイドで完結させるというのはある種の定石かもしれないけど、常識というほどではないかもしれないshokai.icon
Helpfeelの検索
ローカルで検索、検索そのものをWebWorker上に実装
ExpandHelpをベースに、チューニング
詳しくは本当に役立つFAQ検索システムを目指してを参照
よいところ
ユーザーにとって予想だにしない一段階上のソリューションを提供できる
良いアイデアを思いつくと気持ちが良い
なやみ
ロードマップ・期日の説明が難しい
自律的・自己組織的な働き方
自律的
タスクを自分で選んでいく
PM/POが依頼することも多いが、全てのタスクと工程を指示することは稀
進め方を自分で考える
フルリモート制度・フルフレックス制度
自己組織的な働き方
改善サイクルそのものが回るよう意識する
e.g. Welcome to Notaハンドブック
KPTなどレビュープロセスを組み込む
よいところ
働き方を自分で設計できる
ダイバーシティあるyuiseki.icon
マネージャーの想像の外側の世界にも到達できる
なやみ
メンバーは大変だと思う
自分で意思決定したい人にはオススメの職場だが、やるべきことが全て明確であってほしい人には大変な職場だと思う
開発部その他の価値観
以下の考え方もある
プロトタイピング重視、実物重視
Demo or Die ☞ Deploy or Die
「実際に触ってみる」「まずは出せるところを出す」
実世界に出してみて高速に改善を回せるのいいですよね daiiz.icon
しなないでyosider.icon
データと直感をハイブリッドに使う
これいい表現だ daiiz.icon
出力では評価されず、成果で評価される
いっぱいdiffやPull Requestを作ったことだけで褒められることはない
むしろ差分が少なく最大の成果があることが褒められる
差分が大きく成果が少なく重要でも無いものは最悪
たしかにshokai.icon
リファクタリングの評価が難しそうtakano32.icon
リファクタリングは目的ではなく手段という世界観ですyuiseki.icon
ユーザーに価値を届けるためにリファクタリングが必要だったらやる
ユーザーの受け取る価値を損なわないためにリファクタリングが必要だったらやる
新機能の実装の前後にリファクタリングしてますshokai.icon
/icons/わかる.icon utgwkk.icon
なるほど、ありがとうございますtakano32.icon
リファクタリングした結果、(自身や他のエンジニアが)ユーザーに速く価値が届けられるようになったみたいな部分とかで評価されたりしたりはしそうpastak.icon
革命せずに改善する:漸進的なアップデート
成果をどんどん外に出す
革命を起こす:飛躍的な発明を目指す
馬車を高速化しても自動車や冷蔵庫は生まれない
つ グローバルに通用するプロダクトの条件は「引き算思考」ikai.icon
このあたり明確な合意形成をしていないものの、暗黙的にやっている
今年はこういったものを言語化して「Nota開発部の教科書」を作っていきたい
参考になりそうな書籍
リスト
プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける
アジャイルサムライ
ユニコーン企業のひみつ
ド定番ですが、Nota開発部のスタイルにかなり近いことが書いてある
本のままということは無いですが、雰囲気を掴むのに良いかも
まとめ
Nota開発部と価値観についてご紹介しました
価値観3選
ドッグフーディング
プロダクトマネジメント的発想
自律的・自己組織的な働き方
その他の価値観についても今後言語化していこうと思います
価値観が合いそう!という方はぜひご応募お待ちしております!