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