【イベントレポート】Findy主催「開発生産性Conference2024 」に登壇しました

2024.8.1

6月28日、ファインディ株式会社主催のイベント「開発生産性Conference 2024」が開催されました。

本パネルディスカッションでは、エムスリー株式会社取締役CTO/VPoP山崎氏と、ラクスル株式会社上級執行役員CTO SVP of Technology竹内が「エンジニアは事業KPIにどのように向き合うか？」や、両社のROI最大化の秘訣や実践例についても深く掘り下げました。明日から活かせる実践知となれば幸いです。

※本記事はRAKSUL TechBlogからの転載です。

ROI（Return on Investment）の「R（リターン）」と「I（投資）」どちらが大切か？

ーーまずは、エムスリーとRAKSULの現状について教えてください。

山崎：
エムスリーは、「インターネットを活用し、健康で楽しく長生きする人を１人でも増やし、不必要な医療コストを１円でも減らすこと」を目指す医療IT企業です。2000年に創業し、現在東京証券取引所プライム市場に上場しています。

事業は医療ニュースサイトや医師向け転職サイト、電子カルテシステムの開発など多岐にわたります。2024年4月にはエムスリーテクノロジーズを設立し、グループ内でのエンジニアサポートやCTO派遣のようなサービスを展開しています。エムスリーはギークカルチャーが根付き、生成AIを活用した小規模チームでの意思決定と成果を重視し、生産性の高い組織を目指しています。

竹内：
RAKSULは、テレビCMの影響で印刷業のイメージが強いかもしれませんが、印刷事業を中核に、内製での立ち上げとM&Aを通じてさまざまな領域で事業・サービスを展開しています。2009年に設立され、東証プライムに上場し、今年で15周年を迎えます。

エンジニアリングカルチャーはエンジニアだけでなく、事業責任者や担当者にも広がり、問題解決に向けた高い「解像度」を重視しています。このカルチャーにより、複雑な業界ドメインに挑戦し、効率的で革新的な解決策を提供しています。特に非効率な部分を見つけ出し、ディスラプションを通じて成長を遂げています。

ーープロダクト開発におけるROIについて質問させてください。両社では、「R（リターン）」と「I（投資）」どちらの優先度が高いですか？

山崎：
エムスリーでは、ROIを考える上でR（リターン）の最大化に重点を置いています。プロダクトの開発効率を評価する際、最終的な売上の規模が非常に重要ですしリターンが大きければ、その他の要素も補うことが可能です。このため、私たちは常に高いリターンを目指すことに注力しています。

医療業界は非常に多くの、優先順位が明確でない課題を抱えておりますが、エムスリーはその中で、多くの人が”お金を払ってでも”早期の解決が望まれる課題にフォーカスしています。したがって、投資のリターンが十分に大きいかを最初に確認するようにしています。

また、利益を最優先する当社の方針において、ROIは売上高からコストを差し引いた利益として計算されます。コストが固定されている場合、売上が増加すればそれに比例して利益も増大します。

竹内：
R（リターン）に関して、山崎さんと共通の見解がある中で、エンジニア組織の人手不足について触れたいと思います。
私自身、この業界で20年以上の経験がありますが「人手が余っている」という状況に遭遇したことはありません。限られたエンジニアリソースや経営資源の適切な配分が極めて重要です。

つまり、I（投資）をどれだけ小さく抑えるかが鍵となります。投資を抑えることで、より多くのプロジェクトに取り組む機会を増やすことができます。たとえば、10人のチームで1つのプロダクトを立ち上げる場合と比較して、5人で立ち上げた場合、同じ人員で2つのプロダクトを立ち上げることが可能ですよね。

山崎さんがお話されたリターンの重視と同様に、投資を最小限に抑えることで、プロジェクトの数を増やし、成功の機会を広げることができます。打率が100%ではない以上、打席に立つ機会を増やすことが、結果的に大きなレバレッジを生み出すと考えています。

山崎：
なるほど。仰る通りですね。エムスリーでは、現在110人のエンジニアが20チームに分かれており、約50のプロダクトを抱えています。このため、すでに人手が限られており、さらに増員する余地がありませんので……竹内さんのお話に非常に共感しました。

ーー竹内さんは山崎さんのリターンに対する考え方についてどう思いますか？

竹内：
結局、私たちは営利企業なので、利益を出すことが最終目的です。開発の効率も、それが最終的に収益につながらなければ意味がない。営利企業としては、利益がなければ従業員に適切な報酬を支払うこともできません。

ですから、リターンが高いプロジェクトを優先する必要があります。難しいのは「どれくらいのプロジェクトを選択するか？」です。リターン上位5つだけを取るのか、それとも上位10まで広げるのか。また、長期的な視点と短期的な視点の両方が必要です。そんな中、RAKSULでは8月から新たな会計年度が始まりましたが、人手不足の中でリターンの高いプロジェクトから資源を割り当てています。

新規事業と既存事業で「R」と「I」の優先度は変わるのか

ーー新しい事業を立ち上げる際のマネジメントや開発担当の視点から、ROIについてどのようなアプローチを取るか教えてください。また、新規事業と既存事業で異なる視点がある場合、その違いについても詳しく教えていただけますか？

竹内：
新規事業と既存事業では目線が異なります。特にソフトウェアそのものが価値であるSaaS事業には、開発投資を惜しむべきではないと考えています。一方、トランザクションベースの事業やカスタマイズECプラットフォームでは、古くなればなるほど技術的負債が蓄積しやすいため生産性はどうなのか、という疑問が湧きますよね。そこには徹底的な計測と可視化が必要になってきます。
実際、今年2月にRAKSULに私が参画した際、古いコードベースの改善が必要だと感じました。

山崎：
R（リターン）の優先度が高い点に加え、I（投資）も重要な議題ですよね。私は、新規事業の立ち上げ時の、理想的なチーム構成は、プロダクトマネージャー1人、プロダクトデザイナー1人、QA（Quality Assurance）1人、エンジニア4人の“マジックナンバー７”が最適だと考えています。調整するとしても7±2。
SI業界などで過去には大規模チームでプロジェクトが進行していましたが、現代のモダンなプロダクト開発の現場では、基本的にはこの小規模チームで抑えます。このようにI（投資）を固定して、これらのチームがどれだけ大きなリターンを総和として生み出せるかが鍵となります。

これはあくまでプロジェクトの立ち上げフェーズ。成長フェーズでは戦略が異なります。MVPが完成し、PMF（プロダクトマーケットフィット）を達成した後のスケールフェーズでは、営業スタッフの投入や売上の増加により、さらなる開発が必要になります。

この時に、アクセルを全開にする際、I（投資）をどれだけ投入するかは、開発組織のリーダーやCTO、CEOによって決定されます。PMF達成まではマジックナンバー7が適切ですが、その後の成長段階での資源管理が肝心になります。

竹内：
PMFは非常に重要で、その地点に到達するまでの過程は困難が伴います。初期の想定から外れたり、市場で受け入れられないことも。それによって何度も戦略を変更する必要があると思います。

そんなグロースフェーズにおいては、I（投資）とR（リターン）をどうコントロールしていくかを議論したいです。私は、極論、短期は殺してでも技術的な負債をできるだけ少なくし、中長期的にスループットの最大化を目指すべきだと考えています。エムスリーでは、この点をどのようにコントロールしていますか？

山崎：
これは非常に難しい問題ですよね。グロースフェーズにはエンジニアのリソースを多く割り当てたい、というのが現場からの意見も含め、理想ではあります。ですが、他の事業との並行が必要なため、すべてにリソースを割り当てるわけにはいきません。PMFを達成した後も次の事業が待っており、会社として全力を尽くす環境が整っていればそうするのですが、次の事業が全体的に利益を生む可能性もあります。そのような判断は本当に難しいなと感じています。

スモールチームでグロースフェーズを乗り切る方法

竹内：
私自身、プロダクト開発には特別な才能があるわけではないので、事業計画に基づくリターンを信じ、タイムトゥマーケット（製品化するまでの時間）を適切に管理することが重要だと考えています。

山崎：
実際のところ、投資のタイミングが非常に難しいですね。特に、PMFを達成する前に過剰なI（投資）をしてしまうという課題があります。多くの企業が、PMFを達成する前にMVPの開発と同時に人員を増やし始めます。これは、PMF達成に多くの人員が必要だという誤解から生じることが多いですが、実際にはPMFが達成できなかった場合、投入したコストが無駄になり、結果的にR（リターン）が小さく、費用が膨大＝I（投資）が大きいという状況に陥ります。これが、生産性が悪い状態です。

要するに、I（投資）を行うタイミングが早すぎることです。ただし、これを遅らせすぎるという問題もあります。投資の増減をどのタイミングで行うかが鍵となります。このジレンマを解決するためには、無闇に投資を増やさないことが重要です。そのために私たちは、先ほどお伝えしたマジックナンバー7から9の範囲でチームを管理し、グロースフェーズを乗り切る方法を確立しています。

竹内：
実際、最初から最後までスモールチームで進んでいくことは可能なのでしょうか？

山崎：
PMFの質が高ければ、可能です。例えば、エムスリーデジカルは、クラウド電子カルテによって、オンプレミスとクラウドを含む電子カルテ業界で日本一の地位を確立しました。この成果を達成するまで、最大で8人のエンジニアという小規模なチームで取り組んできました。

I（投資）の導入に関しても、過剰に早期にリソースを増やすことは避けるべきであり、そのタイミングは非常に繊細な問題です。場合によっては、新しいプロジェクトについても考慮する必要があります。

そう考えて、エムスリーではスモールチームでのアプローチを採用しています。全体で110人のエンジニアが20チームに分かれ、平均して5～6人のチームでプロジェクトを運営しているような状況です。正直、足したいですが（笑）。

竹内：
率直な疑問として、もしフィーチャー（機能追加）リクエストが大量に来た場合、どのように対応しますか？

山崎：
PMFの質を高く保つことができれば、後続のステップもスムーズに進みます。PMFも段階的に進行しますよね。最初のアクセルを踏み始める頃のプロダクトがよくできており、ユーザーの心を掴んでいると、その後のプロダクト開発は比較的楽に進むことが多いです。特に医療業界では、小さいイノベーションでも大きな影響を与えるため、初期段階での成功が重要です。

エンジニアは事業KPIにどのように向き合うか？

ーーいよいよ本題に移ります。エンジニアが事業KPIにどう向き合うかについて、RAKSULさんの考えをお聞かせください。

竹内：
まず、私たちの「解像度」を大切にする文化について説明しますね。たとえば、印刷EC「ラクスル」では、印刷業界の複雑なビジネスプロセスを解像度高く理解することを重視しています。単純なECプラットフォームと異なり、私たちは非カスタマイズ状態からカスタマイズを行い、ラベル印刷から配送に至るまでの一連のプロセスを管理しています。

このプロセスを深く理解することで、ペインポイントを特定し、どのような改善がR（リターン）を生むか、構造変革や非連続的成長をどう引き出すかを見極めます。

この理解を基に、エンジニアの目標設定にOKR（目標と主要結果）を導入し、その遂行の度合いをエンジニアの評価に反映しています。これにより、エンジニアがビジネスの成長において、事業部メンバーと同等の責任を持つようになります。

このアプローチがRAKSULの強みであり、私たちの業務が面白い理由の一つです。しかし、この方法を過度に推進すると、近視眼的になってしまい、プロジェクトを急ぎ足で進めるという弊害も生じることがあります。このバランスを保つために、OKRを設定し、それを評価プロセスにも組み込むようにしています。

山崎：
我々も竹内さんのお話と似た取り組みをしていますが、エンジニアが事業KPIにどう向き合うかという点では、より積極的に関与しています。エムスリーでは、エンジニアの生産性や社内での評価は、その事業への貢献度に直結しています。エンジニアがいることで事業が成り立っており、その重要性を全員が認識する必要があります。エンジニアの主な目標は、明確に事業の達成です。

しかし、エンジニアが事業成果だけに直結すると、エンジニアリングに集中できず、開発に向き合えなくなるのではないかという声も、エンジニアからはあがっていたりします。エムスリーでは、エンジニアの評価と役割設定において2つの工夫を行っています。

一つ目は、個人個人のエンジニアの評価の工夫です。エンジニアの評価の約20%を直接的な事業成果で行っています。例えば、電子カルテチームでは、年間の電子カルテの販売数を評価指標にしています。残りの80%は、その事業目標を達成するための、新機能の開発、リリース作業、技術負債の返済、セキュリティの強化などが含まれるエンジニアリング活動などに基づいて行います。

二つ目は、事業ごとにいるチームリーダーの責任を設定することです。これらのリーダーは事業の成果に直接責任を持つCTOのような役割を果たし、我々中間層の介入を最小限に抑えることで、事業と密接に連携しています。このアプローチにより、社内には複数のCTOが存在しているような形になり、エラスティックな組織が自己組織化を促進していると思います。

竹内：
私たちのエンジニアリングカルチャーと非常に似た価値観ですね。事業が広範囲にわたると、その深い理解や「解像度」は現場のエンジニアでなければ把握できないことが多く、マネージャーにはその詳細を理解することが難しいです。

RAKSULでは、各事業部に独自のCTOを設置しています。例えば、印刷事業や広告事業など、それぞれの事業に特化したCTOがおり、このアプローチによって役割が明確にされています。事業部ごとのCTO配置は、各事業のKPIを管理し、それを目標にOKRやその他の事業KPIを組み込むことで、事業の成功が直接的に反映されるよう努めています。

ーー目標やOKRの中で事業KPIを持つようにされていますが、現場のエンジニアが「とはいえ、直接的に事業KPIに貢献するのが難しい」と感じる瞬間があった場合、どのようにコミュニケーションをとりますか？

山崎：
各事業部にCTOを設置し責任を持たせることで、エンジニアの中でも事業に関する会話が生まれるため、うまくコミュニケーションがとれているとは思います。現在のエンジニア組織において、マルチプロダクトの概念が普及する中で、各チームにCTOを配置する流れが強まっていると思います。

以前はこの役割をテックリードやエンジニアリングマネージャーと呼んでいましたが、CTOという肩書タイトルを与えることで、よりトータルな成果に対する責任を持たせることが可能になると思っています。これが組織全体の生産性向上に寄与する重要な要素になっています。さらに、チーム内でもコミュニケーションが起こることにより、エンジニアの意識が高まり、リターンの意識も促がされます。

エンジニアの事業視点を深めるための工夫

ーーより具体的に、エンジニアが事業視点を深めるための工夫を教えてください。

竹内：
「事業視点を深めるには、責任を持たせることが非常に重要」という点、私も同意します。さらに、事業の構造を正確に理解し、何がその事業を持続可能なものにするのかを明確に彼らに把握してもらうことも必要です。私たちは、開発責任者がこれらの点をしっかりと理解しているかどうかを確認するため、事業責任者とのコミュニケーションの質を常にチェックしています。

山崎：
私はプロダクトマネージャーの役割を非常に重要だと考えています。この理由は、ビジネスサイドとエンジニアリングサイドの間の潜在的な対立を解消するためです。単にビジネスサイドの指示に従って行動するだけでは、事業は成功しません。ビジネスサイドの意見が常に正しいとは限らないからです。

そのため、プロダクトマネージャーには重要な中間者として機能してもらいます。彼らはビジネスサイドの要求をエンジニアリングの観点から解釈し直し、より実行可能で効果的な解決策を提案することで、生産性を向上させます。エンジニアに直接ビジネスの目標を押し付けるのではなく、プロダクトマネージャーが橋渡しとして機能することが、プロジェクトの成功にとって非常に重要です。

ROIのI（投資）を小さくするには数値にこだわる

ーーROIのI（投資）を小さくするために工夫していることはありますか？

竹内：
ROIの「I（投資）」を効率的に管理するためには、非常にシンプルなのですが「計測すること」です。例えば、エンジニアがオペレーションに40%の時間を費やしているとします。これを20%削減することができれば、その分の時間を新機能の開発に再分配できますね、と、効率化の努力を数字で示すことが、投資の最適化には極めて重要です。

山崎：
私は「採用基準を高めること」が非常に重要だと考えています。採用基準を上げることによって、エンジニアの全体的な能力が向上し、それに伴い、チームに新たなメンバーを加える際にもより慎重になります。エムスリーでは、設立から24年間でエンジニアの数が110人に留まっているのも、この厳しい採用基準が理由です。そもそもI（投資）がないのなら、I（投資）をうまく使うしかなくなるので。