【エンジニアブログ】プロダクト開発部のアップデートが進んでいます！
はじめまして、toridoriプロダクト開発部の髙瀬（たかせ）です。
まずは簡単な自己紹介を…
一昨年まではFlutter開発をしまくっていました。
去年まではかろうじて開発者の体裁を保てていましたが、今年に入っていよいよ開発業務がなくなりました（なくしました）。
今年からは組織マネジメントにコミットします！
▼ MVPシルバー賞を獲得したときの髙瀬をよかったらどうぞ
👀 この記事のトピックです
プロダクト開発部の組織マネジメントが始まりました。目下の仕事は「採用」「評価」「成果の見える化」です。
採用回りを1から見直し、直接応募を開始しました。良かったら見てみてね！
他にもいろいろ頑張ってますが先は長いです
はじめに
toridoriのプロダクト開発部は、エンジニアやプロダクトマネージャなどから構成される、toridoriのプロダクトをぐいぐいと成長させるための集団です。2023年4月現在は15名ほどいます。
去年までのプロダクト開発部には、次のような課題がありました。
😭もっと大きな組織になってたくさん開発したい。けどエンジニア採用がうまく行かない…
😭人が辞めていくんだが？
そんな目新しい課題ではないでしょうが、その辺に転がっている解決方法をそのまま適用できるものでもないと思います。
この記事は、上記の課題と向き合うべく「良い開発組織を作る」という大目標を掲げた髙瀬の決意表明みたいなものです。
取り組み始めて3ヶ月経ち、胸を張れる成果などまだありませんが、考えたこと、決めたこと、やってみたことなどをまとめてみたいと思います。
背景
2022年の12月ごろ、会社から「エンジニア採用にコミットしてくれないか」という旨の相談を受けました。
それまでも弊社はエンジニア採用を行っていたし、何名かの採用に成功もしていますが、全力を出せている、と言い切れるものではなく、かつ計画通りに進められていなかったという背景があった気がします。
髙瀬ならできるだろう、みたいな期待をしてもらえたようで、嬉しかったです。ただ、「エンジニア採用」という仕事を単体ですすめることに違和感があったのも確かでした。
「エンジニアが増えればプロダクト開発部がより大きな成果を出せるだろう」という会社の考えに対して、「ほんまか？」みたいな脳内ツッコミが生じていました。
平たい言い方をすれば、「増えた分だけ減っていく」とか、「人は増えたけど舵を取る人がいない」みたいな、そういう結末を回避する必要があるなぁと感じていました。
それとは別に、以前からメンバーのみなさんと1on1をしたり目標設計をサポートしていたので、ならいっそ、採用とか成長とか評価とか、EMとかVPoEのような職種に期待されるそれを目標にしよう、となり、今に至ります。
「良い組織」に向けて期待を洗い出した
とにもかくにもまずは期待を洗い出しました。
各所にヒアリングして、それとなく自分の意見も盛り込みつつ、やるべきことでマインドマップみたいな物を作りました。
組織というものに関してスキル・知識があったわけではないものの、ある種のロールプレイのような、他人の視点を妄想するのは得意だったんだと思います。例えば、次の視点から見た「素敵なプロダクト開発部」を想像し、達成すべき状態をひたすら書き出しました。
会社から見たプロダクト開発部
成果を上げて欲しい
価値の高い拡大を続けて欲しい
他部署と連携して、開発部特有の強みを活かして欲しい（論理的思考とか言語化とか）
エンジニア市場のインフレ（要出典）は理解している。効果的な予算の使い方を提示して欲しい
メンバーから見たプロダクト開発部
成長したい
自分の仕事が社会に影響を与えている実感が欲しい
お金が欲しい
快適なライフスタイルと両立させたい
転職検討者が見るプロダクト開発部
文化・雰囲気はどのようなものか
会社・事業の成長性は高いか
目下やりたいことはできるか
将来的にやりたいことはできるか
会社はエンジニアを大事にしているか
みたいな。
やるべきことを可視化した
期待を洗い出したら、それらの達成状態を推定し、「やるべきこと」に変換して、なるべく全体感があるように、図にしました。（ソース）
もっといい表現方法がありそうですが、当時、こうでもしないと自分で自分の仕事がわからなくなってやばい、みたいな事を考えていた気がします。通常のプロダクト開発と違いゴールを設計してくれる人もタスクに分解してくれる人もいないので、気を抜くと「何をやってるかよくわからん人」になりそうだなぁとか考えていました。
「採用」に関してやったこと
採用に関して、それまでのプロダクト開発部はいろいろと人事の方に頼り切りでした。
採用媒体を運用したり開拓してもらう
魅力的な募集要項を作成するためのヒアリングをしてもらう
選考希望者とのやりとりや連絡をしてもらう
スカウトしてもらう
カジュアル面談や選考こそ開発部で担当していたものの、そのフィードバックもおそまつ気味で、人事の方としてはPDCAを回しづらい状況でした。
また、募集要項には React とか Flutter みたいなエンジニア用語が頻出するんですが、全然詳しくないのに専門用語を使いこなさなきゃいけない、みたいなつらみもあっただろうと思っています。
そこで、なんかもう1から見直すことにしました。
■プロダクト開発部の見せ方をアップデートした
まずは、プロダクト開発部の見せ方を新しくしました。開発部の中の人だからこそ見える文化とか雰囲気とか、万人受けではなく「合う合わない」を知れることに重点を置きました。
メンバーのみなさんに「良いところ・悪いところ」をSlackで聞いてみたりもしました。下図はその様子です。
■直接応募の動線を新規作成した
開発部の見せ方をアップデートした後、notionを作成して、notionから応募できるようにしました。
それまでも、WantedlyやGreen等の採用媒体を利用していましたが、まずは直接応募の経路としての自社 notionを整備し、説明や募集要項のあり方を確立させてから、認知を拡大させるためのツールとして利用する、という方針で進めました。
完成した notion はこちらになります！
上記notionの最初の認知場所として、メンバーのみなさんに記事を書いてもらうべく、記事ライティング制度の導入も行いました。
導入して1ヶ月経った現在4つの記事が作成されていて、今のところはいい感じです。
■選考フローをアップデート中です
フローそのものは大きく変えていないのですが、各選考において何を見て何を見ないか、あるいは選考担当者に何を期待するか、等の明確化を進めています。
言い換えると、「プロダクト開発部はどんな人を求めるか」の定義を進めています。
今の所、共通事項として
素直な人物であること
会社のビジョン（個の時代の担い手になる）に共感してくれること
があり、その先は技術レベルに応じて分岐する形に進んでいます（詳しくは募集要項を御覧ください）。
「成長・評価」に関してやったこと
22年の開発部の課題感として、経営層にアイディアがあり、優秀なエンジニアもいるが、アイディアを「価値のある開発」に変換する人が不足していました。
理想的には、アイディアは次のような手順を経て開発に至るべきだと考えています。
アイディアを詰める（誰をどれくらい幸せにできて、市場へのインパクトはどれくらいで、初期的にはどこを目指すべきで、うんぬん）
企画書にする
他の企画書と並べて比較検討する
今一番価値の高い企画書の開発を始める
上記を省略していきなり開発を始めたときに起こる問題は、「エンジニアの負担でかすぎ問題」です。
本業である設計や実装に加え、アイディアを詰めること、それに価値を付けること、その上で可及的速やかにリリースして次に進むことなど、物事を成功させるために無限の頑張りが求められます。
基本的には開発部には頭の良い生き物が揃っているのでそれっぽく進めることはできるんですが、頑張れる量には限界があるし、なによりあまり成功に繋がりませんでした。「めちゃくちゃ頑張ったけど成功が小さい」から派生した「大きい成功が見えないから頑張れない」という雰囲気が薄ーく拡がっていた記憶があります。
評価や成長に話を戻すと、上記のような雰囲気は、「頑張ったのに評価されない」「評価されないから頑張りたくない」という悪循環を招く恐れがありました。あるいは、設計や実装に専念したい人からすると、「やりたいことができない」というストレスも予想されました。
これらの解消に向けて、次に取り組みました。
会社からプロダクト開発部への期待値を細分化する
細分化された期待値をまとめて公開し、「どこで誰がどれくらい頑張ってるか」を見える化する
期の目標を設計する時、メンバーに自分で選んで貰う（お願いすることもあります）
※ 補足すると、22年の後半に2名のプロダクトマネージャが参画してくれたことで、23年現在は状況がすこぶる改善されています。髙瀬が上記のような問題の言語化を行えるようになったのも、8割方彼らのおかげです。感謝。
※ もっと補足すると、Scrumの導入も結構な効果がありました。
■ロール制度の運用を始めた
実のところ、上記の課題感を「評価制度の不備」と捉え、22年12月より前から、仕事の期待値と実績のすり合わせに関していい方法を模索してました。
株式会社ゆめみ さん の等級制度をメンバーに見せてチェックつけてもらったり、Product Manager Triangle を2日間熟読してみたり、けれどもしっくりくる形には落とし込めず、まさに暗中模索って感じでした。
そんな中、こちらの記事でロール制度を知り、設計してみたところ、それなりの腹落ち感を得られました。
例えば次のようなものを作成しました。
弊社におけるロールとは、可視化された期待です。
職位との違いは、柔軟に担当者を変更できる点と、1人が複数のロールを担当することができる点です。
例えば次のようなロールがあります。
プロダクトマネージャロール
アプリ開発ロール
必要に応じて領域横断的に開発するマルチ開発ロール
技術選考を通じて技術水準低下を防ぐロール
などなど、各ロールには、よくある期待例も載せて、イメージを掴みやすくしています。
開発もプロダクトマネジメントも選考も、開発部に必要なすべての仕事をロールとして書き出し、担当者を決めて、開発部内で「誰がどのような期待のもと仕事しているか」の見える化を試みました。
半期に1回見直すことを前提に、「これをお願いできないか」と頼み込んでみたり、「あなたにはぜひこれをやってほしい」と提案してみたり。
直接的に評価制度を設計できたわけでは有りませんが、大きな一歩を踏み出せた気がしています。
運用を初めてまだ数ヶ月しか経っていないので、これからですね。
「開発部の成果」に関してやったこと
まだまだあります課題感。
会社から、よく「開発が遅い」と言われることがありました。
当時から「遅いってなんやねん」と思いながら聞いていたんですが、おそらくこれの原因は、開発部の成果が見える化されていなかったことにあります。
個々のメンバーの能力が低いとかさぼってるとかそういう話ではなくて、
f(人月)=成果という式があったとしたら、
f(10人月)=価値のわからない機能2つ みたいな、コストに見合った成果を実感できていない状況に違和感を覚えているのだと考えました。
弊社の評価制度において、個々のメンバー（あるいはチーム）の会社からの見え方は重要です。
ここでやるべきことは、人やチームの成果を全社に見える化することと、その成果の継続性を示すこと、でした。
■各チームのOKRを一緒に設計しています
OKR（Objectives and Key Results）とは、目標設計の仕組みです。それぞれ、
Objective には「パッと見で「いいね！」ってなる粒度の目標」を
Key Results には 「目標の達成を観測できる指標」を
を設定します。
四半期に一度、3ヶ月分のOKRを皆さんに作成してもらっています。別途、1〜2年スパンで、チームとして何を達成したいか、というチーム OKR も作成してもらっています。基本的にはチームの方に任せていますが、「会社の視座から見てどう映るか」という点から見て、提案や修正依頼などを行っています。
※ 本音を言うと、OKRを使いこなせていない感が拭えません。目標設計のフレームワークとしてこれより良いものが目に入っていないので使い続けていますが、未だに苦闘しています。
■全社会に乗り込んだ
弊社には、4半期が終わるたびに一度、各事業部のリーダーから全社員に向けて業績報告をする場があります（全社会）。
通常であれば、各事業部はその4半期の目標達成率と、次の4半期の目標を宣言します。
これまで、開発部は数値目標を建てるのが難しいという理由でこの場での報告を辞退していました。
22年の10月を皮切りに、全社会に乗り込みました。
数値目標なんて無いチームのほうが多く、場違い感が否めませんが、それを場違いじゃなくするのが髙瀬の仕事だ、まであると思っています。
開発部はどのように頑張っていて、何を達成しようとしていて、これはみなさんにどのような影響をもたらすもので…みたいな。
その他、もう少ししたら経営会議にも首を突っ込む予定です。
結局うまくいったの？
わからん！っていうのが本音です。
本格始動してまだ数ヶ月しか経っておらず、評価時期もまだ迎えていないので、「うまくいった！」を実感できるのはもうちょっと先じゃないかなぁと思います。
気をつけないと面倒なおっさんの暴走になるのでそこだけは注意が必要です。
少なくとも、会社はまだまだ変化の多いフェーズであり、ある時点でどれだけうまく言っていようとも満足しきっちゃいけないな、ってのは自分に言い聞かせながら仕事をしています。
最後になりますが、プロダクト開発部では、会社のミッション「『個の時代』の、担い手に。」に共感し、一緒にたのしく仕事できるエンジニアの方を常に！大募集しています。
この記事を読んで、toridoriの開発に少しでもご興味を持っていただけたら、ぜひエンジニア採用notionもご覧いただけるとうれしいです。（手前味噌ながら、プロダクト開発部みんなで考えた自信作です）
それでは！
この記事が気に入ったらサポートをしてみませんか？