「ドッグフーディング」「PdM的な発想」「自己組織的な働き方」　Nota開発部が大切にする3つの価値観

Nota開発部の組織と価値観

秋山博紀氏：ではさっそく「Nota開発部の組織と価値観」というタイトルで私、VP of Engineering 開発本部長をやっている秋山が発表いたします。

まずは、なぜ「Nota開発部の組織と価値観」というタイトルで発表しようと思ったのかというところからお話できればと思うのですが。今回のNota Tech Conf 2022 Springは、Notaという会社の開発部に所属している全員が登壇する機会になっています。

今まで対外的に開発部の組織的なところについて説明してこなかったという背景があるので、Notaという会社の中で開発部がどう存在していて、あとはどういった価値観をもっているのか。ある種、行動指針といってもいいと思うのですが、どういったもので仕事を進めているのかを紹介できればと思っています。

途中で詳しく触れられればと思うんですが、私の2022年のミッションというか仕事の1つとして、Nota開発部の教科書的なところを作っていきたいと思っています。そういったところも、今回の開発価値観やそういったものを共有した上で、ぜひフィードバックをもらえるとうれしいな、というところもあったりします。

Nota開発部とはそもそも何だ？

まずNota開発部はそもそも何だというところなんですが、専門性に基づいてプロダクトの開発・運用や、あとは会社の成長に貢献する部署だと思います。この言い回しをたぶん社内も含めて、おそらく外で初めて私が言ったので、メンバーからしたら寝耳に水だと思いますが。ただそんなに違和感がある表現でもないのかなと思っています。

「開発部」という表現が登場したのは、実は2021年の8月からなんですね。それまでNotaには部という概念がなくて、職種はもちろん分かれているんですが、厳密に部門線を引いていませんでした。開発部っぽいもので何があったかというと、私の名刺に「開発本部長」と自称していたくらいで、別に開発本部という組織はない状態が続いていて、それぐらい部という存在があまりなかったのかなと思います。

具体的には2019年ぐらいまでは、ほぼエンジニアしかいないような組織でした。厳密にはもちろん、バックオフィスの方やマーケティング、広報などいろいろな職種の方がいますが、パーセンテージでいくとエンジニアが非常に多い組織だったので、あまり部門として分ける意味がなかったというのが経緯であります。Helpfeelの事業をやっていく中で、どんどんいろいろな職種の人が増えていったので、こういった部門が増えたと認識しています。

開発部の責務

開発部の責務なんですが、もちろんいろいろな部署が大変だと思いますが、開発部もわりと責務が大きいかなと思っています。Gyazo、Scrapbox、Helpfeelという、けっこうターゲット層も違ったりするようなプロダクトが3つある中で、その開発とそれらの成長に責任を負う立場にあります。

特にGyazoやScrapboxなどは、通常だとあまりエンジニアが関与してこないような、いわゆる企画的なところやグロース的なところも含めて、開発部であったりエンジニアであったりが担うので、そういったところもけっこう大変だけれど、おもしろいところなのかなと思っています。

開発部にどういったメンバーが所属しているかということですが、職種に分けると4職種あります。エンジニアとデザイナーは、おそらく開発部でも他社さんでも違和感がないのかなと思いますが、Notaの開発部の特徴として、テクニカルサポートとコーポレートITも開発部に入っています。

テクニカルサポートは、主にGyazoとScrapboxの問い合わせに対応したりしています。Scrapboxに関しては、カスタマーサクセスにも手伝ってもらったりしていますが、Gyazoに関しては、実はほぼ1人で回しています。

昨日の発表などでユーザー数が何百万人いったようなところの話が出たかもしれませんが、そういった事業規模を1人でカスタマーサポート、テクニカルサポートを回しているのがけっこう珍しいかなと思います。このあたりは、対応がカリカリにチューニングされていて、1人で回せるような体制になっていることが背景にあります。

もう1個のコーポレートITについては、わりと管理部や総務部といったバックオフィス系の部署に所属していることが多いのかなと思いあすが、Notaの場合はその技術的な解決を含めて、エンジニアと協力して社内IT環境を作っていこうということで、開発部に入ってもらっています。

今回のNota Tech Confについては、エンジニアとデザイナーが登壇しています。コーポレートITはまだ専任の人が入っていないので、エンジニアが兼務しています。テクニカルサポートは、わりとハッピーな理由で長期休暇中なので登壇はなしです。現状仕事の仕方として、他部署から日本語・英語を1名ずつで応援に来てもらっていますが、今回は発表なしというかたちです。

VPoEとはそもそも何だ？

あとは昨日のどなたかの発表の最中に「VPoEはそもそも何なんだ？」みたいな質問をいただきまして、けっこう重要な問いだなと思っていて、そのあたりも触れられればと思います。開発部を統括している立場ではありますが、CTOとVPoEの関係はけっこう組織によって違うのかなと思っていて。

いくつか記事をピックアップしましたが、当時のGunosyだったわいまつさん(@y_matsuwitter）が書いたこの分立とCTOみたいな記事や、あとはCoral Capitalさんが出している記事、あとはその他のネット記事を見ていただくと、全員共通のことを言っているところもありますが、微妙に違うこともいっていたりして、なかなかその会社によって違うところもあるかなと思っています。

Notaの場合は、（スライドを示して）このあたりに責任を負う立場なのかなと思っていて、1点目はプロダクトが今どういう状況でちゃんとそれが回っているかや、あとは将来どう回していくかみたいなわりと最終責任に近いポジションで見ていく立場なのかなと思っています。

それを合わせて開発組織自体、そもそも組織形態をどうやって構築していくかや、あるいはみんなにうまく活躍してもらうための運用であったり、あとはそもそもメンバーを増やしていくみたいなところも必要なので、そういった採用活動にも責任を負っています。

あとは営業部やマーケティング部など、そういった別の部署があるので、部門間調整をしたり、あとはエンジニアの水準、デザイナーの水準、メンバーの水準をどんどん高めようというところで、育成や人事制度の評価を設計したり。メンバーのキャリア形成みたいなところにも、ある程度コミットメントしているのかなと思います。

他にもインシデントが発生した時に、ある程度責任を持って対応をしている立場であったり、あとはコーポレートITが管掌部門として入っている関係で社内IT環境を作っていたり、そういったところも責任を負っています。

VPoEとして心掛けていること2つ

私がNotaのVPoEを拝命してたぶん5年ぐらいですかね。ちょっと計算しておけばよかったんですが（笑）。たぶん5年ぐらいだと思うんですが、心がけていることがあります。これは当初からあまり変えていなくて、あとは社内に向けても初めて説明するところでもありますが、1点目が「サーバントリーダーを目指す」というところです。

会社によって、このサーバント型がいいのかボス型がいいのかなど、いろいろな組織形態があると思いますが、Notaのメンバーの場合は、基本的に優秀なメンバーが多いので、大半の業務はメンバーが活躍できる状態でさえあれば、基本的にはうまく回るような組織なんですね。

活躍できる環境というのが、プロダクトの状況であったり社内の状況だったり、あるいは社会情勢で変わってくるところがあるので、そういうのを事前に察知して、例えば良い感じに先回りして体制を変えたり、環境を整えて良い感じに仕事が回る状況を作ったりするようなところをかなり意識しています。

2点目が、権限だったり知識を学んだりもらったりすると、自分に合わせて革命を起こしたくなっちゃったり、あるいは知ったことをとりあえず試してみたくなっちゃう気持ちがあるんですね。ただそれは、絶対にやらないということを決めていて、よくハンマーを持つと全部釘に見えるみたいな話があると思いますが、なんかそういうものを持った時に今の体制でうまく回っているところを「やってみたいので変えてみる」みたいなところは絶対にやらないようにしようというところは意識しています。

なのでチームメンバーからすると、あまり変化が大きくないなという体制が続いているように見えるんですが、微妙に実はチューニングしているところもあったりするので、変わっていないような感じで実は意外とあります。例えば5年前とかと比べると、ガラッと変わっているところがあるんですね。なので、劇的に変えようとはしないみたいなところは意識しています。

あとは出力じゃなくて、成果を最大化するところを意識していて、例えば「開発部の成果は何ですか？」というのをステークホルダーに説明しなければいけない立場なんですが、そうするとわかりやすくトラッキングできる、数値化できるものとしてプルリクの数がたくさん立ち上がりました、これだけコードを書きました、機能をリリースしたのが1,000個あります･･･などなど、そういう数値目標を言いたくなりがちなんですが、それは実は誤りで。

例えば機能をたくさん作ることではなくて、具体的にエンドユーザーであったりお客さんにどれくらいの価値が生み出されているかが大事なので、そういった間違った指標を持たないというところはかなり意識しています。こういった3点を意識して、VPoEとして仕事をさせてもらっています。

開発部が大事にしている価値観3選

今日の発表は、開発部としてはそんな感じの部署なんですが、価値観3選ですね。おそらくもう社内合意も出来上がっているであろう、かつそんなにもう異議がないんじゃないかというところをピックアップしてみました。ドッグフーディングの話とプロダクトマネジメント的な発想を持つというところと、自律的・自己組織的な働き方をするというところです。

おそらくNotaのことを、大変ありがたいことに熱烈にウォッチしてくれている方がいると、またこの話かみたいなところはあると思いますが、何度も説明するぐらいかなり重要なところだと思っているので、あらためて紹介できればと思います。

まずはドッグフーディングですね。これはもう“一丁目一番地”に出てくるような超重要な価値観だと思っています。自分たちで作ったものを自分たちで使うというところ。ドッグフーディングを知らない方向けに説明すると、もともとの由来としては、ドッグフードを作っている会社のセールスパーソンが実際に犬用ビスケットを食べて、品質が高いですよとアピールをして、確かに作っている製造元の人が食べているんだったら良い品質なんだろうみたいなところが由来だとか。他にもいろいろ由来はあるみたいなんですけど、そういったところからドッグフーディングというキーワードになっています。

弊社の場合はGyazoとScrapbox、Helpfeelというプロダクトを作っているので、実際にそれを毎日使っています。Gyazoの場合は、全社的にほぼ毎日何かしらに使っていると思います。とりわけ開発部の4職種については、ほぼ確実に毎日使っているんじゃないかなと思います。Scrapboxについても、「/Nota」というNotaのプロジェクトがあって、これを開くとプライベートプロジェクトなので開けないはずです。Notaじゃない人が開けたらちょっとまずいので、こっそり連絡をいただければと思います。

代わりに「/nota-private-sample」というページがあって、これを開くと、こんな感じでNotaの中でどうやって議論をしているかを参考情報としてコピーしているプロジェクトがあります。ここのプロジェクトは176ページだけしか入っていませんが、今はだいたい3万か4万いかないぐらいのページがこのプロジェクトには入っていたかなと思います。

その他にも、営業情報や面談記録など共有範囲を絞る目的に複数のプロジェクトを運用していたりしています。GyazoとScrapboxがB2Cのプロダクトなので、わりと実際に使ってみると、こんな感じでNotaも使っているのかというのが想像しやすいかと思います。

Helpfeelのドッグフーディング2つ

HelpfeelがB2BのSaaSになっていて、実際に触ることはできますが設定画面などは触れないので、どういう感じでドッグフーディングをしているのかがちょっと想像しづらい部分もあると思うので、このあたりを紹介できればと思います。

わかりやすくは2個です。必ず入社時に全員触るように実は設計しています。1点目が「Welcome to Notaハンドブック」というものを整備していて、入社時のオンボーディング、特にGoogle Workspaceのアカウントをセットアップする方法であったり、あるいはSlackやGitHubなどそういったところをセットアップする方法が書かれているマニュアルがあります。

ミソはこのマニュアル自体が自己組織化されるようになっていて、読み進めていって、もし書いている内容が陳腐化していた場合は、そのマニュアルの修正自体を最初のミッションとすることが決まっています。実際に最初のページのスクリーンショットをここに貼りましたが、「ようこそ！」というメッセージのあとに、もういきなり「最初の仕事は、アカウントを発行してください」というのと、あとは「必要であればハンドブックを更新して次にジョインする方の手助けをしてください」。

それで「古い情報があったら今のスクリーンショットを撮影して自分で更新してください」ということになっています。このとおりに作業をすると、ScrapboxとHelpfeelとの関係も含めて理解できるはずなので、そういった点でドッグフーディングをしていたりします。

実際にこういうアカウントのセットアップまわりは、コーポレートITの担当者がスクリーンショットを撮ろうと思うと、イチから同じような状況を再現したりしなきゃいけなくてかなり大変なので、そういう意味ではこういった自己組織化したマニュアルもけっこう手としては良いなと思っています。

もう1点がセキュリティハンドブックというものを作っていて、具体的にはセキュリティガイドラインですね。社内のルールを掲載しているプロジェクトです。これが社内規定の資料ではあるんですが、例えば「パスワードはこうしてください」というルールがあったとして、じゃあ具体的にどう運用するんだというハウツーも、ルールとセットで必要だと思います。

そういったハウツーを盛り込むためにHelpfeel化をしていて、これは実物を見てもらったほうが早いかなと思います。今URLが出ちゃっていてパスワードがかかっているので入れないはずですが、入れちゃった人はまたこっそり連絡もらえればと思います。こういう感じでHelpfeel化されていて、アクセスするといろいろな説明が出ます。

ここに例えば「vpn」と入れると「VPNは何を使えばよいですか？」と出てきて、こういったかたちでハウツーが出てきて、ルールが出たあとにハウツーが出ます。具体的にどうやってセットアップするのかみたいなものをWindows、Macなど全部書いてあります。

基本的にこの使い方で、コーポレートITに問い合わせが来ることはほぼないです。なのでこういったところで何度も同じことを聞かれないで済むところで、Helpfeelがどう活用されるかをドッグフーディングできていいのかなと思いました。

shokaiさんが今日も使ってくれたということで、ありがとうございます。こんな感じでけっこうドッグフーディングしていると、このあたりは説明を深くしたほうがいいなとか、こういう構造を作るといいななどがわかるので、そこは良いポイントだと思いますね。

今はちょっと良いところを先に言っちゃいましたが、そもそも自分たちで作ったものを自分たちで食べると、バグがあればすぐに気づきますし、あとは改善しようというモチベーションもすごく高いです。自分たちが使って自信を持っているので、そのように勧められるプロダクトを作れるかなと思います。

悩みというかこれは私が最近思っていることなんですが、けっこう組織規模や文脈が異なるユーザーの気持ちがわかりづらいのかなというところがあって、もしかしたらそういう人たちがどういう生活をしているかという想像力、あるいはその人になりきって使ってみるみたいな憑依力など、そういうところが必要なのかなと思う時があります。

あと下の話は冗談半分なんですが、あまりにも組み込みすぎていてサービスダウンすると仕事しにくいことがあります。そんなしょっちゅう落ちているわけじゃないんですが、例えばGyazoが落ちると「Gyazoがこんな感じで落ちています」というかたちでGyazoろうとしちゃうんですね。

スクリーンショットを撮ろうとしたら今落ちていたわ、みたいなことがあったりして、こういう感じでどれぐらい重要なサービスかが実感できるので、そういうところもおもしろい点だと思いますね。このあたりはドッグフーディングのすごい大事なポイントだと思っています。

プロダクトマネジメント的な発想の重視

次に、プロダクトマネジメント的な発想をすごく重視しています。これはいわゆるプロダクトマネージャーというポジションが世の中にはあると思うんですけれども、そういった考え方をエンジニアだったりデザイナーだったりメンバー間でも持ってもらうということを意識しています。

これはどういうことかというと、開発者として解決できる問題を、開発者として見て、開発者だからこそできる課題解決を探していくというところを重視しています。大事なのが問題を俯瞰して、来た要望をそのままダイレクトに実装しないということですね。理想としては、できるだけ複数の問題を解決できるといいかなと思っています。

下に貼ったのは任天堂の宮本茂さんが言った「アイデアとは、複数の問題を一気に解決するもの」という言葉ですが、こういったかたちでお客さんから見たスコープ、エンドユーザーから見たスコープだけの要望をそのまま鵜呑みにせずに、この要望の裏にある問題意識だったり困りごとは何なのかというところを見て、そこからもう1回俯瞰して問題を解決することをかなり重視しています。

あとはプロダクトマネジメントと近いかどうかわかりませんが、私の好きなNotaの価値観に「定石を安易に採用しない」というところがあるんですね。これは例えば「〇〇を実装するなら〇〇とかだよね」みたいな、エンジニアだったらこうだよねというのがあると思いますが、それを安易に採用せずに定石の1つ上を目指すということをやっています。

Notaでわかりやすい事例は何なのかと思ったんですが、検索システムがすごいわかりやすいなと思って。検索エンジンを作る時は、例えばElasticsearchを使ったりSaaSだとAlgoliaを使うなどさまざまあると思いますが、Gyazoの場合はElasticsearchを使っています。これはすごく正しいと思っていて、Gyazoは画像だけでも毎月2,000万から3,000万件ぐらいレコードが増えていくんですね。

こういった大規模なデータセットを検索するには、当然そういったオープンソースを使ったほうがいいだろうということで、Elasticsearchを使っています。これ自体の意思決定もすごく良いと思いますが、下のScrapboxとHelpfeelはけっこうおもしろいなと思っていて、ページタイトル検索やHelpfeelの検索は、パッと見はElasticsearchで作っちゃってもいいようなものだと思うんですよね。

でもそこは、安易にそういう選択肢を取らずに、Scrapboxの場合だとローカルで検索をして辞書構築の部分をWebWorkerに逃がすみたいなことをやっているんですね。かつ複数のアルゴリズムを組み合わせていて、昨日のshokaiさんの発表の例だと連番になっている数字をまとめてみたところもありますが、そういったところの検索もすごく頭が良くなっているんですね。

shokaiさんのScrapboxに実装まわりの紹介があるんですけど、こういった選択を取るというのが、けっこうおもしろいなと思っています。あとは「ある種の定石」もあるみたいですね。

Helpfeelは、実はFAQの検索を全部ローカルでやっています。Scrapboxが検索のインデックスの構築を辞書構築をWebWorkerでやっていたのに対して、Helpfeelは検索そのものをWebWorker上に実装しています。もともとCTOの増井さんが考えたExpandHelpという論文があって、それをベースにゴリゴリにチューニングをかけているという背景があります。

このあたりは、実は2021年Helpfeelプロダクトオーナーのdaiiz君が発表してくれているので、このあたりを見てもらえるとけっこうおもしろいかなと思います。

こういったプロダクトマネジメント的な発想を持つところの良いポイントとしては、ユーザーにとって予想だにしない一段階上のソリューションを提供できる可能性があるというところですね。

あとは私も、プレイングマネージャーとしてコードを書いたりしているのでわかるんですが、単に良いアイデアを思いつくと気分がいいんですね。なのでそういうところが働いて楽しいポイントにもつながると思うので、その顧客の要望を鵜呑みにして高速に実装するのではなく、高速に実装すること自体も私はもちろん悪いことだとは思っていないんですが、ちゃんと俯瞰して考えるというところをやっていければと思っています。

悩みのポイントとしては、言われたことをそのままやると、工数の計算をしてそのとおりにやればいいので期日の管理とかすごいしやすいんですが、ある程度俯瞰してバッファを持たせていくと、そのロードマップ的な説明や期日の説明が難しいというところが悩みとしてあります。これはけっこう私が対外的に説明する機会が多いので、それで悩んでいるポイントでもありますが、そのあたりは知見がある方にぜひいろいろと教えていただけるとうれしいなと思っています。

自律的・自己組織的な働き方

最後ですね。自律的・自己組織的な働き方みたいなところを重視しています。自律的というのは何かというと、基本的にタスクは自分で選んでいく・考えていく。問題は自分で発見していくところがかなり重視されている会社です。PMとかPOといった立場のメンバーが依頼することも多いんですが、基本的にはすべてのタスクに対して「これだけやってください」とか「この工程でやってください」というのを手取り足取りということはもう一切ないです。

進め方自体もわりとガバッとタスクを渡して自分で考えてもらって、もちろんサポートはするんですけれども考えてもらうことが多いかなと思います。あとはそういった働き方をサポートするために、フルリモート制度・フルフレックス制度というところをやっているので、そのあたりも含めて、けっこう自律的に働いてもらう必要があるかなと思います。

あとは自己組織的な働き方ですね。自己組織化みたいな言い回しって、おそらくスクラム宣言か何かで出てきたのかな、アジャイル宣言かスクラム宣言かどっちかだと思うんですが、そもそもルールとして改善サイクルが回っていくようなものを考えていこうというところです。

例としては、先ほどご紹介したようなWelcome to Notaハンドブックみたいなものがわかりやすくて、あれもルール上必ず改善されてどんどん良くなってくるはずというルールで設定されているので、そういったものをプロダクトしかり働き方しかりに組み込んでいくということを意識しています。あとはKPTとかレビュープロセスとかそういったところを組み込むというところもやっています。

こういった自律的・自己組織的な働き方みたいなところの良いところは、働き方を自分で設計できるということがけっこう大きいかなと思います。すごく昔の話だと、9時に出勤して17時に退勤する定型的な生活をするのがけっこう良い時代としてあったと思うのですが。

今はそういう時代でもないかなと思いますし、わりと時代がというよりはいろいろなシチュエーションに置かれているメンバーがいる中で、一番活躍できる働き方は人によって違うと思うので、そういったところを担保できるのは良いところだと思っています。

あとはマネージャーが想像する外側の世界に到達できるのは、すごくいいなと思っています。マネージャーが全部「こういうもので、こういうプロダクトを作ってください」というのを規定すると、おそらくよくある例は、プロダクトマネージャーがUIも含めて全部設計して、それに基づいて実装していくパターンが多いと思いますが、それをやると結局マネージャーの想像の世界観からも出られないんですね。

Notaのメンバーのすごいなと思うところは、「これお願いします」と振った時に、軽々と自分だったり他のメンバーだったりが想像した範囲を超えてくるような発明をしてくれるところがあるので、そういうところはすごくいいなと思っています。

悩みというかポイントとしては、とはいえ自分でルールを作って考えてやっていくぞというのは、メンバーにとってはけっこう大変かなと思っていて、自分で意思決定をしたい人にはかなりおすすめの職場なんですが、やはり人によってはやるべきことはすべて明確であってほしいという話はあると思うので、そういう人にとってはけっこう大変な職場かなと思っています。

その他の価値観

開発部においての3選をとりあえずピックアップしましたが、実はその他にも価値観的なものがあるなと思っています。サラッとだけ紹介すると、例えばプロトタイピングや実物を重視していくというところ。Demo or DieというMIT メディアラボのニコラス・ネグロポンテさんが言っていた「デモするか死ぬか」みたいな言葉や、伊藤穣一さんがそのあとに言っていたDeploy or Die、「出すか死ぬか」みたいな。

実際に死ぬことを要求されることは会社なので当然ないんですが、ぜひデモしたり実際に本番環境に出してみて実際に触ってみられるものを作ってみたりなど、まずは出せるところを作ってみましょうというところを重視しています。daiiz君のコメントのとおりですね。実世界に出してみて高速にフィードバックをもらえたりするので、そういうところは良いポイントかなと思います。

あとはデータを出してもらうところはもちろんやるんですが、データをそもそも取れないみたいな領域もあるので、データと直感をハイブリッドに使っていったり。あとは出力では評価をしないで成果で評価するというところ。いっぱいDiffとかプルリクを作ったことだけで褒められることはまずないです。

差分が少なくて最大の成果があることは褒められます。差分が大きく成果が少なく重要でもないものをすごく一生懸命作っているのは基本的には最悪とみなされますね。下のコメントで「リファクタリングの評価は難しそう」というコメントがありますが、リファクタリング自体もなぜ必要であるか、重要であるかなど、そういったところが重視されます。

なのでこれが世の中的に正しい、これはやりたいのでリファクタリングをやります、Diffが3万行です、とかはあまり褒められない文化ですね。

あとは最後の2つですね。完全に矛盾していることを言うんですけれども、革命せずに改善するというのがポイントですね。漸進的なアップデートをかなり重視していて、1年かかってすごい機能を1個ボンッと出すよりは、その機能を分割していって、1週間だったり3日だったりで「ここだけ少し良くなった」というのをどんどん出してもらうことを重視しています。

一方で革命を起こす何かを作るということも重視していて、飛躍的な発明をぜひしてほしいという気持ちがあります。増井さんのWeb記事か何かだったと思うんですが、馬車の例がすごくわかりやすくて、馬車を一生懸命高速化しても自動車とか冷蔵庫は生まれないんですね。

馬車が担っている機能のrequirementsとして、例えば高速に人間を移動させたいであったり、このリンゴを新鮮なまま食べてほしいだったり、いろいろそういう欲求があると思いますが、それを馬車をメチャクチャ速くすることで解決しようと思っても根本的な解決にならないという考え方があって、そういったところをやっていけるのは、強いメンバーかなと思っています。

このあたりは合意形成はしていないんですが、暗黙的にやっていることかなと思うので、今年はこういったものを言語化してNota開発部の教科書を作っていきたいと思っています。

このあたりの話題は『プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける』『アジャイルサムライ』『ユニコーン企業のひみつ』のようなド定番の本に書いてあるんですけど、本のままということはないんだけれども雰囲気をつかむにはよいと思うので、もしご興味を持っていただけたらぜひ読んでいただければと思います。

最終的には教科書を作っていきたい

本日のまとめに入ります。Nota開発部の組織とそれらの価値観について紹介しました。ディティールとしては価値観3選として、ドッグフーディング、プロダクトマネジメント的発想を持つこと、自律的・自己組織的な働き方をしていくことについて紹介しました。その他の価値観についても、実はこれは初出ししたというものも多かったりするので、今後言語化していって、最終的には教科書を作っていきたいと思っています。

このあたりを見ていただいて価値観が合いそう、ちょっと一緒にこれだったら仕事をしてみたいなと思っていただけた方は、かなりNotaに向いていると思うので、ぜひご応募いただければと思います。以上で発表を終わります。ありがとうございました。