ワンキャリアの開発組織は「プロダクト開発を行う前に、その機能がどれだけのリターンを生むか」を算定するワークフローを運用しています。

ワンキャリアの「開発前にROIを算出するワークフロー」

プロダクトによるビジネス成長を狙っている私たちは、常に「何となく」ではなく「確実に事業にヒットする」プロダクト開発を行う必要があります。

上場企業でもあるため、リターンが生まれない投資を繰り返すことは、お客さまにとってももちろん、株主など、あらゆるステークホルダーにとって健全ではありません。

上場企業のプロダクト組織として、あらゆるステークホルダーに対してリターンの責任を果たす

そこで、前述したようなワークフローの運用を始めました。今回は、なぜこのような仕組みを運用しているのか、具体的な仕組みの概要をまとめてみます。

ワンキャリアではプロダクトからビジネス成長を起こせるように、開発組織の成熟を促してきました。

ワンキャリアプロダクト組織は、現在ではサービス群をまたいだ体験にまで責任を持てるように成熟

プロダクト開発組織には、プロダクトマネージャー、デザイナー、エンジニアが所属し「つくるだけでなく、ビジネスに効くような機能開発を行うこと」に責任を負っています。

事業群全体にまたがり「つくるだけでなく、ビジネスに効くような機能開発」に責任を持つ

立ち上げ当初から、私たちは「何かをつくる」という手段ではなくて、「何をつくるのか」という目的に責任を持つことにこだわってきました。

このスタンスは、たとえ開発組織が未熟であったとしても持つべき姿勢だと考えています。2019年の立ち上げ当初は、そもそものプロダクト開発の進め方からおぼつかない場面ももちろんありましたが、そのような組織であったとしても、目線は常に目的に向けているべきだと思います。

お客さまからすると、どんな開発のプロセスが取られているのかは関係がありません。なので、私たちは組織が未熟な段階でも、ビジネスに貢献できるような機能開発を行い続けてきました。

2019年から現在までに、開発組織はどんどん成熟していきました。当初はエンジニアのみだった組織にも、プロダクトデザイナーやプロダクトマネージャーなど企画推進に役割を持つメンバーが増えていきます。

このタイミングで「組織全員で、事業に効く機能開発」を行えるようにワークフローをアップデートさせることを考え始めます。

組織成熟によって、「何をつくるべきか」を組織全員で考えられるようになってきたタイミングで、ワークフローをアップデートさせる

ワンキャリアでは、このような課題を踏まえて「開発前にROIを算定する」ことをワークフローに組み込んでいます。

組織全員で「何をつくるべきか」を考えられるように、開発前にROIを算定するワークフローを取り入れた

仕組みの全体像としては、以下のようなイメージです。

ワンキャリアの「開発前にROIを算出するワークフロー」

より詳細にワークフローそれぞれで行っていることをまとめてみます。

まずは、戦略や要望をもとに、ロードマップを決めています。これはクオーター(以下、Q)単位で、ざっくりとつくりたいものの順序を決めているようなイメージです。

フェーズ1: 戦略の定義「Q単位のざっくりしたロードマップを用意する」

会社全体での大きな方針・戦略と、日々ボトムアップで吸い上げられている顧客要望をまとめながら、マーケティング部門長、営業部門長、取締役などと一緒に、つくりたいものの順序の想定をつけています。

ロードマップのイメージ

ここで重要なのは、このQ単位のロードマップは「変わりうるもの」と認識しておくことです。

課題や体験の検証を十分に重ねていない状態で、ロードマップを「必ずつくらなければいけないリスト」のように扱ってしまうと、つくった機能を外してしまうこともありますし、組織的にも「ただ言われたことをやる」組織になっていってしまいます。

戦略を固定化することで、不確実な状況に対応できなくなってしまうこともリスクとして考えられます。

このロードマップはあくまで、次のEpic単位の検証を行う上でのヒントであり、道標のようなもので、変えていくことも厭わないことが持つべきスタンスだと思います。

ロードマップは変わりうるもの、あくまで検証のヒントとして扱う

次にロードマップをもとに、プロダクトマネージャー、デザイナー、エンジニアで「Epic」と呼んでいる機能単位の仕様に変換します。

フェーズ2: Epicごとの検証「リターン予測や根拠付けまで行う」

他社でも仕様をまとめたドキュメント (ex. PRD) は存在していると思いますが、同様につくりたい機能の仕様についてはまとめつつ、

ワンキャリアがユニークなのは、Epicに「開発によるリターン予測」も明記していることだと思います。

  • どのような指標に機能する施策なのか

  • この機能をリリースした時に、どのくらいの数値向上が起こるのか

  • 数値向上の根拠

をまとめ、このリリースによってどのくらい成果が起こるのかを厳密にまとめています。

Epicに記載している「リターン予測・数値向上の根拠」のイメージ

ただ数式を書くだけで「数値向上の根拠」を出さなければただの机上の空論になってしまうので、プロダクトマネージャーやデザイナーは、この検証を開発意思決定の手前で行うようにしています。

例えば、営業メンバーと連携して、お客様に口頭で新機能の提案を行い、その時にお客様の購買意思が生まれたかどうかを計測して、数値で換算してみたりすることもあります。

また、toC向けの機能であれば、すでにリリースされている機能を改善してみて、一定期間テストしてみることで数値予測をすることもあります。

Epic単位でリターンの算出を行い、必ず数式だけでなく根拠まで検証していく

この想定している成果算出のための方法は、機能によって異なります。

例えば、toC向けの機能であれば、マーケティング部門のメンバーと一緒に、逆に、toB向けの機能であれば、営業部門のメンバーと一緒に、リターン算出方法をディスカッションし、検証も一緒に進めていきます。

このように、プロダクトマネージャーとデザイナーがEpicに「開発によるリターン予測」をまとめたら、開発に進めるかどうかエンジニアチームで意思決定をします。

フェーズ3: ROIベースで開発承認「エンジニア主導で開発に進めるのかを意思決定」

エンジニアは、何もしなければ「どうつくるのか?」に目が向きやすく、投資対効果を意識しづらいものです。

あえて、エンジニアという一番お金を使う役割の人が、「何をなぜつくり、どういう成果を出すのか」を意思決定することで、適切にチームとして投資に対しての意識が育っていくと考えています。

Epicごとのリターン予測を参考に、エンジニアで開発有無を意思決定

ちなみにこの承認の議論の場には、プロダクトマネジメントやデザイン側も管掌する私や、管理部門の部門長も参加します。(場合によっては取締役も参加)

機能単体というよりも、もう少し先を見据えて、「ワンキャリアにとってあるべき体験か」という目線で議論をしています。

さらに、財務諸表的な部分も合わせてチェックをしています。

  • BS(資産)に載るような開発になっているか?

  • CF(キャッシュフロー)的にも問題がないか?

  • 事業戦略上、必要な投資になっているか?

  • 開発によって、原価が下がるか?

といった、投資によって財務諸表的にもリターンが大きくなることが明快になった上で、機能開発に踏み切るようにしています。

エンジニア組織内で承認を行ったら、その後は会社内のワークフローに載せて、機能単位で開発実施していく稟議をかけます。

承認後の流れのイメージ。会社のワークフローに乗せて稟議承認を行い、その後も予実を週次で管理

開発組織内部だけで意思決定をするのではなく、会社として投資有無の合意を取る仕組みにしておくことで、透明性のある活動となります。

また、一つひとつの活動を金銭という共通言語に換算することができるので、「今正しく投資ができているのか」ということにも意識を向けやすくなるメリットがあります。例えば、開発組織では毎週「機能単位の開発予実」を営業組織のように報告するのですが、そこでも実際に予実が合っているのかを考えやすくなっています。

プロダクト組織は、常に投資対効果の高い活動だけを行えるわけではありません。例えば差し込みのエラー対応など、「やらなければいけないが、投資対効果は低い活動」がどうしても生まれてしまいます。そのような場合にも、こうして活動を金銭に変換して考えられるようにしておくことで、長期的には無駄のない場所に投資し続けようという引力を生むことができます。

このようなワークフローの運用を通して、多くの機能をリリースすることができました。

これまでにワンキャリアのプロダクト開発組織でリリースしてきた機能の一部

さらにその中には実際に、リリースされた施策によって大きく事業数値が向上している事例も生まれています。ROIを意識した開発によって、確実にビジネス成果につながる機能を出せるようになってきました。

会員登録機能のリニューアルでは、KPIが大きく向上し、ビジネスインパクトを生むことができた

最近では、ROIだけでなく、ROE (自己資本利益率) という株主目線でのリターンをも意識できるようになってきました。

会社全体が適切に資源を投下して、成長に繋げられているのかを測定することで、安定した経営を実現することができます。

世の中には数多く人材サービスを運営する企業が存在していますが、ワンキャリアは「プロダクトで伸びる会社」だと捉えています。

HR業界は、まだまだプロダクトによって変えていける範囲が大きく、ビジネスに加えてプロダクトを適切に扱えるようになることで、より多くの課題が解決され、同時に企業成長も生まれていくはずです。

一方で、プロダクトへの投資は「出してみないとビジネスに効くかどうか分からない」不確実な投資であると考えられることもあるでしょう。このような状態だと大きくプロダクトに投資していくことはできないはずです。

今回の仕組みによって、「出す前からどのくらいビジネス成長に貢献するか」をできるだけ具体的に予測できるようにしたことで、ワンキャリアではこれからさらにプロダクトの投資が生まれていくことでしょう。

プロダクト開発組織として考えるべき分岐。ワンキャリアでは右側のような「投資を行えるプロダクト組織」へと成熟し始めている

このような仕組みは、組織成熟とともに運営が可能になってきたものです。一朝一夕ではなく、少しずつ「プロダクトから企業成長を生んでいく」ということを目掛けて内製開発組織を育ててきました。

この組織変遷についてまとめた事例もぜひ合わせてご覧いただけると嬉しいです。

https://cocoda.design/shunsukeiwamoto/p/p8bafec1a05fe

今後もビジネスにヒットさせるプロダクト開発を狙って行えるように、ワンキャリアの開発組織を成熟させていきます。プロダクトマネジメント、デザイン、エンジニアリングと全体にまだ成長の余白があります。ぜひ一緒にプロダクトからHR業界に挑んでいきましょう。

このデザイン組織をもっと知る