なんらかのプロダクトを開発している企業にとって、エンジニアの組織作りは永遠の課題です。そこでふだんからエンジニアチームが取り組んでいる、プロダクト開発の概念を組織作りにも取り入れてみるのはいかがでしょうか。
本記事では、「Developer eXperience Day 2024」（主催：日本CTO協会）にて「組織作りに『プロダクト開発のエッセンス』を取り入れ、不確実性に向き合い続ける」をテーマにおこなわれたセッションの内容をお届けします。このセッションでは、フリー株式会社の竹田 祥さんが実際にフリーで実施している組織作り関連の施策やプラクティスについてお話ししてくださいました。
竹田 祥さん
2018年入社。2022年からVPoEとして各プロダクトやエンジニア組織作りの責任者を担当。エンジニアが自然体で楽しみながら最高のプロダクトを開発できる環境を作っていきたい。うさぎを4羽飼っています。
目次
組織作りにプロダクト開発の概念を取り入れることの効果
プロダクト開発では、ユーザー理解をして、なにを作るか決めて、実際に作って試して、評価するといったサイクルを回します。組織作りも同じです。このサイクルを組織作りに当てはめて、いかに高速で回せるかにチャレンジしました。
組織作りにプロダクト開発の概念を取り入れたことで、よい効果が2つありました。
1つ目は、思考のよりどころができることです。組織作りで迷いが出たときに「プロダクト開発ならどうするかな」と立ち返って、自信を持って進められるようになります。
2つ目は、メンバーが慣れ親しんでいる概念なので、認知負荷が低くて話が早いということです。
開発組織なので、ユーザーであるメンバーはふだんからプロダクト開発をしています。だからプロセスにおける認知負荷は非常に低いです。たとえば「組織作りの中でプロトタイピングをしたい」と言えば、すぐに通じるのです。メンバーを巻き込むときも、話が早く進みます。
また組織作りやHRの話は、エンジニアには遠い存在だと思われがちですが、プロダクト開発の概念を適用すればその壁も壊せます。
ユーザー理解・調査・分析と要件定義
フェーズごとのポイントと具体的な施策例をご紹介します。
開発と同じですが、まずはユーザーを理解して、なにを作るかを決めましょう。組織作りでも、意思決定や施策をどんどん実施していきますが、そのときに根拠を示して仮説を作る必要があります。
現在の組織状態があって、その先の1年後、2年後、3年後で目指したい組織状態がある。そこまでのギャップを埋めていくのが、組織作りの施策です。ここに本気で向き合うために、2つのアウトプットを作成しました。
エンジニアサクセスダッシュボードの作成
まずはエンジニアサクセスダッシュボードという、データが一元的に見られるものを作りました。いわゆるタレントマネージメントのような領域ですが、そこに本気で向き合いました。
ダッシュボードには、開発組織ならではの要素を盛り込むのが大事になります。
1つ目は基本情報や評価のような、定量的なデータです。
2つ目は、対話やサーベイ等による定性データです。ここで行間を埋めていかないと、定量データだけではわからないことも多くあります。
最後に役割定義です。エンジニアのロールを定義して、それに対するみんなの状況や目指しているもの、期待値などを可視化しています。
基本情報や評価などの定量データ
いったん私をイメージして考えてみましょう。
基本的な情報は在籍年数や報酬と、所属の歴史などになります。
今までどのような所属を歩んできたのかは非常に重要です。開発組織における所属の変遷は、やってきたことやプロジェクト経験の積み重ねです。これを把握すると、「この人はこれができるだろう」「これが得意なんだな」といったことがわかります。
評価情報は、クォーター後の評価やグレードがどのように上がっているかをそのまま集計しています。
対話やサーベイ等による定性データ
次に、いわゆる定性データです。
センシティブな情報も多いので、本人と話してメモを残したい人は残す、残したくない人は話をして終わりという扱いです。
ここには本気で取り組んでいて、毎年100人くらいのメンバーが入社するので、その全員と2on1を実施しています。2on1のメンバーは、意図的に構成しています。私は必ず出るようにしていますが、組織作りの責任者なので「なにかインサイトを与えたら、組織が変わるのでは」という期待を持ってほしいという意図があります。
また、エンジニアリングのバックグラウンドがないメンバーがいると、気兼ねなくいろいろなことを話してくれることもあります。
あとは私自身が日常的にSlackを観察したり、会社をうろうろして状況を見たりするのも大事だなと思って実施しています。
サーベイも、できる限り負荷なく情報を集めたいと思って取り組んでいます。
まずはコンディションです。毎週キャラクターのbotに「先週の体調はどうでしたか」といったことを聞かれます。毎回答えなくてもよいのですが、調子が悪いときは答えるような流れです。
ネガティブな話ですが退職した人のデータをさかのぼると、9割以上の確率でなにかしらこういった部分でアラートが出ています。だからこういったものを見ておくのは意外と大事です。
あとはよくある項目ですが、仕事に対するわくわく感があるか、組織に対して納得感があるかなども集めています。
開発組織共通の役割定義をもとにしたcan/will/expect
開発組織の中で、共通言語として役割定義をしています。それに対してcan/will/expectがあります。
canは、本人とマネージャーが今、できると思っている役割（ロール）と段階（ラダー）です。
willは今後やりたいロールとラダーです。
expectは、本人ではなく会社やマネージャーが期待していることを定期的にアップデートしています。
代表的なロールを4つ定義しています。
エンジニアリングマネージャーは一般的な概念ですが、プロダクトリードはいわゆるプロダクトカンパニーっぽいものです。プロダクトの価値を追求するエンジニアのロールを明確に設けています。
たとえば新規プロダクトの開発チームを組成するときに、かつては「グレードがこれくらいの人が集まっていたらいいや」という感じでした。今はそうではなくて、ラダーと役割をきちんと組み合わせて、チーム構成の枠を作ります。その中に、本人のwillも含めて合致する人をアサインしようと、ロジカルに進めています。
こうすると、can/will/expectが具体的に書けるのです。
たとえば私が、ミドルPdLとジュニアEMができると思っているとしましょう。ただ、今後のキャリアややりたいことを考えると、今後はシニアPdLとしての道を極めたい。マネージャーやチームにとってもそれがありがたいとなれば、双方の希望が合致してマッチングができます。
エンジニアサクセスダッシュボードがあるとできること
ここまでお話しした定量・定性とロール・ラダーを、全員に対して紐づけています。これを横断的に分析すると、いろいろなことが見えてきます。
ダミーのデータですが、組織全体で今のcanはどのようなロールの人が多いのかを分析したところ、PdL的な人が多いという結果になりました。さらに、その中のロールのレベル感はどれくらいかという分析をします。PdLが多くても、ほとんどの人がジュニアレベルではプロジェクト進行ができません。
そうなると、なんとかしてレベルをミドル以上に上げる施策が必要となります。
またコンディションやわくわく感といった話も紐づいているので、メンバーは多いけど、実際はみんな辞めそうなどといったこともわかります。
エンジニアサクセスダッシュボードのポイント
ポイントは3つあります。
1つ目は、近道はないので一次情報から触れて把握していくことです。
簡単にお話ししてきましたが、データはいろいろなところに散らばっているので、集めるだけでも大変です。とくに定性データは一次情報から触れていくしかないため、時間もかかります。
ただ、ここで解像度をいかに上げるかが、今後の組織作りの意思決定に関わってくるのです。だから、手抜きをしない覚悟で臨む必要があります。
2つ目は定量と定性、両方のデータをミックスして使うことです。相手は人なので、定量データだけでは見えない部分も多いです。定性データとあわせて補完していきましょう。
3つ目は、データを継続的にいつでも参照できるようにすることです。データは常に変化していくという前提を置きましょう。その上で、最新のものがいつでも見られるようにしておくことが大事です。
組織的な意思決定をする場面は、採用、予算、事業計画、プロダクト作りなどいろいろあります。その際に、できる限りデータをきちんと見ることを組織の習慣にしていくのが重要です。
開発組織のポートフォリオの作成
次に、目指したい組織状態をどうやって可視化していくかのお話です。目指したい像として、3年分の開発組織ポートフォリオを作りました。
年度ごとのグレードに対する人数や割合、具体的なロールを使ったものや新卒と中途の割合、在籍年数どれくらいの人がこれくらいいるというのを、仮説を立てて書いています。
SaaSなどの会社では、ARRという年次の売上に対して、「何%を開発組織に当てる」という形で予算決めをしていることが多いかと思います。ただそれだけだとおもしろくなくて、それに加えて組織としてどのような状態にしたいのか。自社の強みはこのあたりにあるから、予算よりもオーバーするけど、多い人数を確保しておこうとか、そういう意思を込めることが大事です。
具体的には組織全体の人数などを、詳細に内訳までシミュレーションしています。ロール・ラダーもそうですし、日本・グローバルはどうするのか、新卒・中途はどうするのかを年単位で決めています。
もちろんこれも変わっていきます。事業計画自体が市場の状況などによって変わり、それによって投資割合も変わるのです。大変ですが、定期的にアップデートしています。
開発組織のポートフォリオのポイント
ポイントは2つあります。
1つ目は、逆算で作れる部分も多いのですがそれだけではおもしろくないので、「こうなりたい」という理想像を広げて盛り込むのが大事です。
2つ目は、経営メンバーと認識を合わせ続けることです。ポートフォリオは開発組織に対する投資イメージそのものとなるので、金額的な話にも直結します。そのため、社長やCTO、CPOを含めて認識を合わせていくのが大事です。
ここがずれると、組織に対するお互いの期待値がずれてしまうので、うまくいかないことが増えます。だからギャップを埋め続けるのが非常に重要です。
実際の使い方の事例
ここまでできたら現状も細かく分析できますし、将来的にどのような状態を目指したいかの仮説も立てられるようになります。あとはギャップをどう埋めていくかを考えるだけです。先が見えていると優先度もつけやすく、組織としてどこから手を打つべきかもわかります。
たとえばFY27の組織と3年後を見据えたときに、「ミドルEMやシニアPdLがこれくらい足りない」というのがリアルな数字として見えてきます。このときに、組織作りをする者としてなにをするか。
まずはwillに「3年後ミドルEMになりたい」と書いている人たちが、どれくらいいるのかを把握します。その人たちに対してなにをすべきか、どのような成長支援をすべきかを施策に盛り込んでいくのです。
また採用においては、ジョブディスクリプションにそのまま使えます。ロール定義をアレンジして、募集要項にしています。
設計・実行のポイント
ここまでお話ししてきた2つが土台にあれば進めやすくなるので、設計・実行と評価についてはポイントだけお話しします。
まず設計実装はデータを使って、組織としてなにをすべきかが見えている状態で実行します。
データや仮説は当たり前に使いましょう。組織のテーマはなぜか無限にわいてきます。だからデータを使って、選択と集中をしましょう。
また、スモールスタートするのが非常に大事です。
組織の話は、「全員に適用してみよう」といきなり大きくなりがちです。ただプロダクトと同じで、実際に試してみないと結果がどうなるかはわかりません。だから恐れずに小さく試してみる。アジャイルに進めていくのが大事だと思います。
評価のポイント
最後の評価です。
同じくデータを見ましょう。土台ができていると、組織作りに対してなにかをしたときに影響が出ます。細かいところだとわくわく感が変化する、willの傾向が変わるなどといったことがあります。だから施策を試したときに、「どこに反映されるだろう」と意識しながら進めるのが大事です。
また組織的な取り組みは、思ったよりも成果が出ない場合があります。設計して「これはいけるだろう」と思ってやってみたけど、数字にはまったく反映されないこともあります。
これはそういうものだと思って、スモールに試して結果が出なかったらアップデートする、もしくは違う施策に切り替える。プロダクト開発と同じで、そうやってどんどん進めていくのが重要です。
最後に
プロダクト開発と組織作りは似ています。だからプロダクト開発の概念を適用することで、よりよい組織作りにつなげられます。みなさんも普段からプロダクトを作っていると思いますが、それができているなら、組織作りも同じように考えていけばよい組織ができるはずです。
「組織作りは大変で難しい」と感じている方も多いと思いますが、恐れずにこういった概念を適用して、自信を持って楽しみながら取り組めばよい組織ができるかと思います。
取材後記
竹田さんご自身がVPoEとして試行錯誤された取り組みやフリーでの事例などを踏まえた、エンジニアの組織作りに関する知見が満載のセッションでした。
聞けば聞くほど、プロダクト開発と組織作りには共通点が多く、その概念はあらゆるフェーズで応用がきくのだなと感じました。
データの収集などは大変かと思いますが、エンジニアの組織作りで苦労されている方は、一度プロダクト開発のエッセンスを取り入れてみるのも一つの手だと思います。
（取材／文：谷口智香）
