組織作りに「プロダクト開発のエッセンス」を取り入れ、不確実性に向き合い続ける / 竹田祥【Developer eXperience Day 2024】イベントレポートVol.3

日本CTO協会が主催を務め、2024年7月16日・17日に開催された大型カンファレンス「Developer eXperience Day 2024」。「Developer eXperience（=開発者体験）」をテーマとし、その知見・経験の共有とそれに関わる方々のコミュニケーションのために計30以上のセッションが行われました。

本記事では、「組織作りに「プロダクト開発のエッセンス」を取り入れ、不確実性に向き合い続ける」の様子をお届けいたします。

1. 登壇者紹介

1.1. 竹田祥

2. フリーのVPoEとして組織作りに取り組む

3. Engineer Successチームの組成

4. 組織開発にプロダクト開発のエッセンスを取り入れる

5. Engineer Succeesダッシュボードの作成

6. 3年分の開発組織のポートフォリオの作成

6.1. フリーでの活用事例

6.2. データをもとに改善を繰り返す

7. 良いプロダクトを作れる組織は、良い組織を作れるはず

8. Developer eXperience Day 2024 イベントレポート一覧

登壇者紹介

竹田祥

フリー株式会社執行役員 VPoE

高校時代からプログラミングを始め、個人事業主としてサイト制作業務に従事。大阪のシステム開発会社にて技術力を向上。その後、BtoB企業へ転職、同社にて新プロダクト開発のための部署を立ち上げ、開発部長に就任。2018年、フリー株式会社に入社後、同社の関西支社のエンジニア組織立ち上げを担当。現在は同社でVPoE、プロジェクト＆グローバル開発本部長を兼任、開発に関わる幅広い役割に従事。

フリーのVPoEとして組織作りに取り組む

はじめまして。フリー株式会社執行役員 VPoEの竹田と申します。今回は、フリーのVPoEを2、3年やってきた中で見えてきた「組織作り」についてお話しさせていただきます。

まず簡単に自己紹介をさせてください。キャリアとしては、エンジニアを20年ぐらいやっています。フリーに入るまでは、コードを書く部分にフォーカスしていました。フリー入社後は、プロダクトマネージャー・エンジニアリングマネージャーにキャリアチェンジをし、そこからVPoEになりました。趣味は、ウサギを触りまくることです。自宅で4羽飼っています。この子たちがめちゃくちゃかわいいんですよ。これはあくまでも個人的な感想ではあるのですが、ウサギを飼っていると家でのDX（Developer Experience）がかなり上がるので、おすすめです。

自己紹介はこれくらいにさせていただいて、本題に入って行きたいと思います。今回お話することは、DXを実行するうえでの土台となる「組織づくりの進め方」や「データの扱い方」についてです。私含め、CTOやVPoE、EMなどリーダーポジションは、様々な悩みがあると思います。抽象度が高い部分もありますが、自信を持ってロジカルに組織づくりを進めていける参考になれば幸いです。

Engineer Successチームの組成

弊社は「スモールビジネスを、世界の主役に。」というミッションを掲げ、会計ソフトを中心にスモールビジネス事業者向けのバックオフィスサービスを作っています。今日の話の前段のイメージを持っていただくために、開発組織のアウトラインをご紹介します。開発組織は、500名ほど在籍しており、毎年新しいプロダクトをリリースしている状況です。中でも、2021年あたりから年100人という急激なペースで人が増えています。地方拠点やグローバル、未経験採用も始めており、多様性の広がりも加速しています。

私がVPoEになったのは、ちょうど急激に人が増え始めた2021年のタイミングです。様々なカオスや多様な変化が起きているため、取り組むべきテーマは山積みで、何から手を付けたらよいのかわからない状況でした。これは組織作りを担われている方にとっては、よくある話だと思います。弊社の場合「まずは形から入ってみよう」ということで、開発組織作りの専任チームを作ってみました。これが今回の話の内容の土台になっているもので、現在も継続している取り組みです。

その際、「カスタマーサクセス」という職種を参考にしました。簡単に解説すると、自社プロダクトを使ってくださっているユーザーを成功体験（サクセス）に導くポジションです。このエンジニア組織版を作ろうという話になり、「Engineer Successチーム」を組成しました。ミッションはシンプルで、「開発メンバーの “成功体験” に繋がることだけを考えて、実行し続ける」というものです。「サクセス」というのはプロダクトや会社のフェーズによって変わるものではありますが、フリーの場合は「ユーザーにとって価値のあるプロダクトを変換を楽しみながら最速で生み出し続けること」と定義しました。

組織開発にプロダクト開発のエッセンスを取り入れる

チームには良いメンバーが集まり、良いコンセプトも作れたのですが、「とはいえ、テーマが多いので具体的にどうやって進めたら良いんだ？」という状態に陥りました。ここでやっと本題に入ります。VPoEとして3年ほどやってきて、「組織開発は、プロダクト開発と同じなんじゃないか？」ということに気づいたんです。そこで、組織開発にプロダクト開発のエッセンスを取り入れることにしました。

プロダクト開発では、「①ユーザー理解 → ②要件定義 → ③設計・実行 → ④評価」のサイクルを回していくのが一般的かと思います。実はこれ、ほとんど組織づくりと同じなんです。プロダクト開発でいう「ユーザー」は、組織作りのケースだと「開発組織のメンバー」となります。そのため、「①メンバーや組織を深く理解し → ②組織に必要なことを見極め → ③実際に試してみて → ④結果を見ながら改善していく」というサイクルになります。この仮説検証のサイクルをいかに早く回せるかということにチャレンジしました。

実際にこの取り組みは非常に効果がありました。1つは、「不確実性の高い活動に対して “思考の拠り所” を作ることができる」ということ。プロダクト開発は普段からやっているので対処しやすいのですが、組織作りになった途端に迷いがたくさんでてきます。しかしこの迷いをプロダクト開発に置き換えて考えると、対処法のイメージができて自信を持って進められるようになります。2つ目は、「普段慣れ親しんでいる概念なので認知負荷が低く、話が早い」という効果です。組織作りではメンバーを巻き込む必要があります。そんな時にプロダクト開発という共通の認識を前提に話を進められると、理解してもらいやすいです。結論を申し上げると、数年やってみた結果めちゃくちゃおすすめなので、ぜひやってみてください。

Engineer Succeesダッシュボードの作成

ここからは各フェーズごとの詳細やポイントについてお話します。まず先述の「①メンバーや組織を深く理解し」「②組織に必要なことを見極め」についてです。ここでは、組織作りにおける意思決定に根拠を示し、仮説を作る事が重要です。構造としてはとてもシンプルで、現状の組織状態を把握し、目指したい組織状態を可視化します。そのギャップを埋めるために、必要な組織施策を打っていくという構図です。しかし、組織状態を把握しようと思っても200〜300人もいると情報の取得方法に困りますし、将来の組織状態も日々変化する事業計画やプロダクト計画に応じて変わってきます。そのため、これらを定義することはすごく難易度が高く、これまでは本気で取り組めていませんでした。

弊社ではここに本気で取り組み、私がVPoEになって3年ほどで2つのアウトプットを出したのでご紹介させていただきます。事例1が「Engineer Succeesダッシュボードの作成」で、事例2が「3年分の開発組織のポートフォリオの作成」です。

まず、「Engineer Succeesダッシュボード」について解説します。いわゆるタレントマネジメント領域になってきます。そこに、開発組織ならではの要素を加えたことがポイントです。弊社で実際に取り扱っているデータは主に3つです。「基本情報や評価などの定量データ」「対話やサーベイ等による定性データ」「開発チーム共通の役割定義を元にしたcan/will/expect」があります。これらのデータを掛け合わせて、あらゆる角度から分析をかけていくイメージです。

一旦私を例にとって見ていきます。まず、「基本情報や評価などの定量データ」です。ここは基本的なものなのでわかりやすいと思います。中でも重要なのが、「所属の変遷」です。開発組織における所属の変更は、やることが大きく変わります。ここをしっかり把握しておくと、各メンバーの強みを把握できるようになります。

次に、「対話やサーベイ等による定性データ」です。対話の部分では、毎年100人ほど新規メンバーが入ってくるのですが、その全員と2on1を実施しています。あとは、Slackなどを日常的に観察したり、社内をうろうろして情報を集めています。サーベイについては、負荷なく回答できるものを用意して各メンバーのコンディションの計測を行っています。興味深いのが、辞めた人のデータを分析すると、9割以上の確率で何かしらのアラートが出るんです。そのため、日々のコンディションチェックはすごく重要です。

最後が、「開発チーム共通の役割定義を元にしたcan / will / expect」です。ここからがエンジニアっぽい話になります。「can」は本人とマネージャーが認識するすでにできるロールとラダー（段階）、「will」は今後目指したいロールとラダー、「expect」はチームや会社が期待する今後担って欲しいロールとラダーです。これらを定期的にインプットしてアップデートする作業を行っています。

補足ですが、2021年以降急激に人が増えたこともあり、開発に求められる仕事や役割が多様化・複雑化していきました。そんな中で、「何でもできる人」が評価される傾向にあったんです。組織としてこれは良くないと思い、ロールの定義とラダーの明文化を実施。社内の共通言語として機能させるために、採用や評価、チーム編成時などあらゆる場面で参考にしてもらえるよう周知していきました。

弊社では、代表的なエンジニアのロールとして、「PdL（Product Lead）」「EM（Engineering Manager）」「TL（Technical Lead）」「IC（Indivisual Contributer）」の4つを定義しています。ラダーに関しては、「Associate」〜「Principle」で設定しており、各々の責務も明文化されています。

例えば、新規プロダクトチームを作る時にもこのロールとラダーの定義は有効です。従来であれば、「グレードがこれくらいの人を集めておけばいいや」という感じでした。しかし今では、ロールとラダーを組み合わせたチーム構成の枠を作り、その枠に当てはまるメンバーをアサインするといったかたちで、よりロジカルにチームを組成するようにしています。

こういった定義づけをしておくと、can / will /expectがかなり具体的に書けるようになります。例えば、「現在はMiddle PdL、Junior EMを担当でき（can）、今後はSenior PdLを目指していきたい（will）。マネージャーとしてもSenior PdLとして活躍して欲しいと思っている（expect）。」といった感じです。

このように、各メンバーに対して「定量」「定性」「can / will / expect」のデータを紐づけているので、全社横断的にデータを分析していくと様々な傾向が見えてきます。例えば、ロールとして全社的にPdLの比率が高いと仮定します。しかし、PdL内でのラダーの比率を見るとその多くがjuniorレベルでした。このような状況だと、プロダクトの成長が遅れてしまう可能性が高いので、juniorからMiddleにメンバーのレベルを上げていくための戦略立案の必要性が浮き彫りになります。同時に、コンディションやワクワク感などのデータも紐づいているので、これらのデータの掛け合わせによってデータを分析し、打ち手を考えていくイメージです。他には、新卒メンバーの成長状況や今後のキャリアイメージにも役立ったりします。

これらの取り組みをやるとなると、実際はとても大変です。ユーザー理解調査・分析のポイントは３つあります。1つ目は、「1次情報に触れ、メンバーの状況を正確に把握すること」。基本的にメンバーのデータは様々な場所に散らばっているので、地道に集めていかなければなりません。また、弊社もそうだったのですが、定性データが社内で管理されていないことも多いです。定性データの取得には膨大な労力が必要になりますが、ここの質をどれだけ上げられるかが今後の組織作りの意思決定の質に大きく影響を及ぼします。そのため、一定の土台を作るまでは手抜きをせずに取り組むことが大切です。2つ目は、「定量と定性、両方のデータを用いて分析すること」。相手は人なので、人物像を正確に把握するためにも定量、定性の両方のデータが必要です。3つ目は、「継続的にいつでもデータを参照できる状態にしておくこと」。当たり前ですが、willなどは時間とともに変わっていくものです。それに伴って全社データ自体も変化していきます。その前提を踏まえたうえで、最新のデータを把握し、いつでも見れるようにしておくことが重要です。

採用、予算、事業企画など組織的な意思決定をする場面でこれらのデータを参考にすることで、より質の高い決断ができるようになります。そのためにも、このようなデータ活用を組織として習慣にしていくことが重要です。

3年分の開発組織のポートフォリオの作成

ここまで「今の組織状態の可視化」について解説してきましたが、次に「目指したい組織状態の可視化」についてお話します。具体的には、「3年分の開発組織のポートフォリオを作成する」といったものです。先ほどのダッシュボードと組み合わせることで、より強力な打ち手に繋がります。

大枠として、事業やプロダクトの計画から逆算した数字を詳細に設定し、それを元に「開発組織としてどのような状態にしたいのか」という意思を提示します。弊社の場合だと、組織全体の人数、ロール・ラダーの分布・人数、新卒・中途の分布・人数などを年単位で可視化しています。もちろん事業計画はいくらでも変わるので、定期的にアップデートをし続けなければなりません。

この際のポイントは、2つあります。1つ目が、「リアルな状況を織り込みつつも、縮こまらずに理想像をイメージすること」。現実的すぎると面白くないので、保守的になりすぎずに理想のイメージを広げることが重要です。2つ目が、「経営メンバーとイメージの認識をあわせ続けること」。将来的なヘッドカウントなどにも関わってくる話なので、これは開発組織に対する投資イメージそのものです。ここがずれたまま進んでしまうと、事業やプロダクトに対する期待値のギャップが生まれてしまいます。そのため、このギャップをいかに埋めながら走れるかが肝になってきます。

「今の組織状況の把握（Engineer Successダッシュボード）」と「目指したい組織状態の可視化（3年分の開発組織のポートフォリオ）」ができれば、意思決定はかなりしやすくなるはずです。現状もかなり細かく分析できますし、この先どうなりたいかも仮説が立てやすくなります。あとは、このギャップをどのように埋めていくかを考えれば良いんです。実際に先のことが見えていると、優先度も立てやすくなります。

フリーでの活用事例

フリーでのこれらのツールの活用例をご紹介します。1つ目は、3年後のFY27までの事業、プロダクトのスケールを見据えた時に、「Middle EMやSenior PdLが何人足りない」と具体的な数値で見えています。この時の打ち手として、willのデータを通して将来的にMiddle EMやSenior PdLになりたいメンバーの数を把握し、そのメンバーに対してどのようなサポートができるかを考えます。他には、採用活動にも使いやすいです。ロール定義を転用すればJDも作りやすいです。また補足ではありますが、willやcanを踏まえると異動調整はとてもスムーズに進みます。

2つ目の例として、グレードの移行率の把握があります。グレードの推移やそこに対するロールの掛け合わせを見ているので、「このグレードになると、次のグレードに上がりにくくなる」というデータが見えてくるんです。この場合会社としては、「その層に対して効果的なチャレンジアサインができているのか」を考えるきっかけになります。

2つ例をご紹介しましたが、ツールを用いることでこういった組織的な課題をデータを元に出せるようになるというメリットがあります。

データをもとに改善を繰り返す

ここまで、組織作りのサイクルの「①メンバーや組織を深く理解し」「②組織に必要なことを見極め」についてお話しました。正直これだけできていれば、この後の「③設計・実行」「④評価」はかなり進めやすくなるので、ポイントを絞ってお伝えします。

まずは、「③設計・実行」についてです。先程のデータを用いて組織として何をすべきなのかを設計し、実行していきます。このフェーズのポイントの1つ目は、「データを用いて仮説を持って進めること」。面白いことに組織テーマは無限に湧いてきます。そのため、選択と集中をしながら進めることがすごく大事だと考えています。2つ目は、「スモールスタートをすること」。不思議なことに組織や制度の話になると、話がいきなり大きくなりがちです。実際にはやってみないとわからないこともたくさんあるので、まずは恐れずに小さく試してみることが重要です。

最後に、組織作りのサイクル「④評価」についてお話しします。ここはすごくシンプルです。ポイントは同様に2つありまして、1つ目が「感覚だけでなく、必ずデータを用いて判断すること」。「Engineer Successダッシュボード」や「3年分の開発組織のポートフォリオ」といった土台ができていると、組織作りの施策を打った時に、必ず何らかの影響がこの2つにデータとなって現れます。そのため、何か施策を打つときは、これらのデータのどの項目に影響がありそうかを意識しながら進めることが大切です。2つ目は、「現実に向き合い、どんどんブラッシュアップすること」。組織的な取り組みは、思ったよりも成果が出ないことが多いです。緻密に設計して実行したにも関わらず、数字に全く影響がないこも結構あります。これはそういうものだと割り切って、結果が出なければ施策のアップデートや別施策を実行して改善していくことが重要です。

良いプロダクトを作れる組織は、良い組織を作れるはず

本日の話のまとめになるのですが、「プロダクト開発と組織作りは非常に似ている」といまだに感じています。そのため、プロダクト開発の概念を組織作り、特にはエンジニア組織に当てはめることで、より良い意思決定に繋げることが可能です。両者が似ているとすると、「良いプロダクトを作れる組織は、良い組織を作れるはず」だと考えています。これは逆もしかりです。組織作りに苦労されている方も多くいらっしゃると思いますが、まずは恐れずにこういったプロダクト開発の概念を取り入れながら、取り組んでいただけると良い組織が作れるんじゃないかと思っています。私からのお話は以上です。ありがとうございました。