【EM Conf 2025】技術課題を整理し、経営と紐づける。「バリューベース戦略」を用いた思考法と実践｜atama plus VPoE 前田和樹

2月27日に開催された、EM（エンジニアリングマネージャー）関連の3コミュニティが共同運営する大型カンファレンス「Engineering Manager Conference Japan 2025」。

本レポートでは、atama plus株式会社でVPoEを務める前田和樹氏のセッション「エンジニアリング価値を黒字化する、バリューベース戦略を用いた技術戦略策定の道のり」をご紹介します。

技術戦略と経営戦略の方向性を一致させ、必要な投資を得るために「バリューベース戦略」のフレームワークが役立つという前田さん。

バリューベース戦略を応用して、技術課題を整理して経営戦略を立て、経営戦略とのむすびつきを示していく方法を、約40分のセッションで紹介。内容を一部再編成してレポートします。

• keyboard_arrow_down 「価値」の構造を捉えなおす。バリューベース戦略とは何か？
• keyboard_arrow_down 「バリューベース戦略」のフレームワークを、技術戦略に応用する
• keyboard_arrow_down STEP１：大量の技術課題を構造化する
• keyboard_arrow_down STEP２：構造化した技術課題を、経営の言葉に翻訳する
• keyboard_arrow_down STEP３：「今やるべき施策」を決める
• keyboard_arrow_down 実践例：バリューベース戦略 × 「技術戦略を立て、施策を打つ」
• keyboard_arrow_down 実践例：バリューベース戦略 ×「次の技術戦略を立てる」
• keyboard_arrow_down まとめ：バリューベース戦略を活用し、投資を勝ち取る

atama plusでVPoEを務める前田です。今日は「技術戦略と経営戦略のアラインメントをとるために、バリューベース戦略というフレームワークを使う」という話をしていきます。

私は、技術戦略を構造的に捉え、経営戦略と接続するために、「バリューベース戦略」という枠組みを使っています。

今日はその具体的な方法として、
・バリューベース戦略とは何か
・バリューベース戦略は技術戦略にどう調和するのか
・技術戦略を経営戦略にアライメントするために、バリューベース戦略をどう用いるか
といった話をしていきます。

まずバリューベース戦略という考え方について。

バリューベース戦略とは、ハーバードビジネススクールで近年提唱されている、戦略フレームワークの1つです。この『「価値」こそがすべて！』という本でわかりやすく解説されています。

この考え方の一番コアになるのは「価値」です。やろうとしている施策、解こうとしている課題が、顧客、従業員、サプライヤーの誰にどんな価値を生むのか？という問いがベースになっています。

バリューベース戦略には、2つの概念が出てきます。

1つ目がWTP（Willing to Pay）です。ユーザーが「このサービスに払ってもいい」と思う金額の上限を指します。

もう1つがWTS（Willing to Sell）。組織が提供してもいい最低ライン、とありますが、わかりやすく言うと「この収入帯を下回ったら、従業員が会社から出て行く」とか「サプライヤーがこれだけの売り上げが担保できないんだったら、この会社と取引をやめる」といったこと。

ただ、WTPとかWTSは、実際の価格とかコストを指しているわけではありません。

そして、WTPとWTSの差分を「バリュー（価値）」と定義する。これが、バリューベース戦略の基本的な考え方です。この考え方は、技術的な課題と親和性が高いんじゃないかと思っています。

具体的に想像しづらいと思うので、具体例を出しますね。バリューベース戦略は、経営戦略の分野で、競争優位性とかサプライチェーンマネジメントなどによく応用されています。

例えば、電子書籍リーダーのKindle。これはWilling to Payを向上した場合の例です。電子書籍リーダーの黎明期には、Sonyなどが先行して、小型化したり機能を追加したりした新しいデバイスをどんどん発売していました。後発としてAmazonがKindleを発売します。その際「Kindleに3G回線を無料でつける」という戦略をとったんです。本を買い、ダウンロードし、読むまでが1個の端末で済むので、他社の電子書籍リーダーとは全然違う体験が提供できる。そうして、ユーザーから「これだったらこの金額払ってもいい」というMAXの価値、つまりWilling to Payを劇的に高めたんです。

Willing to Sell を下げる例では、アパレルブランドであるGAPの、パートタイマーの勤務時間へのアプローチ。GAPは店舗型ビジネスで、パートタイマーの従業員満足度に課題がありました。パートタイマーの勤務する曜日や時間が安定しないことで、家庭とのバランスがとりづらかったのです。その際、報酬を上げるのではなく、シフトを固定化するための取り組みを行いました。これにより、人件費を全く変えずに従業員満足度を高め、Willing to Sellを下げたんです。

こんな感じで、実際の価格設定やコストではないところの価値をスライドする、という考え方がバリューベース戦略です。

これらの例は、1つの施策がWTP、WTSのどれかに効いているという話です。しかし面白いことに「1つの施策で、WTP、WTSどちらにも効く」という場合もあるんです。これを「二重の優位性」といいます。

例えば、アパレルブランドTommy Hilfiger のブランドラインである「Tommy Hilfiger Adaptive」。これはハンディキャップを持っている方向けのブランドラインで、単価は高いものの、ボタンやチャックなどデザインが、着やすく動きやすいように工夫されているのです。

この施策をやることによって、まずWilling to Payとしては、ハンディキャップを持っている方々にとって、今までなかなか手に取れなかったおしゃれな服、という選択肢として価値を上げることができています。また、社会貢献性の高い活動に取り組むことで従業員の満足度を高めるので、Willing to Sellが下がる。

つまり1つの施策で、価値のマックスと下限を両方スライドするといった優位性を効かせることもできるわけです。

課題と施策の各要素は、システムとしてつながっています。その要素をシステム思考的に捉え「この施策がどこに効くのか」という有機的なつながりを理解できていると、こうした戦略の転換もできるのです。

この考え方を技術戦略に転用できるんじゃないか？と考え、バリューベース戦略での価値にフォーカスして、技術戦略を構造化してみました。

エンジニアリングによって成し遂げたいことは、究極的には「価値を高めること＝アウトカムの追求」だと思います。

バリューベース戦略のフレームワークを使うとしたら、エンジニアリングにおけるWilling to Payを「事業貢献につながる価値」と、Willing to Sellを「開発組織の維持にかかるコスト」と捉え、これらの差分が「エンジニアリングのアウトカム」となります。

技術戦略とは、抽象的に捉えると、事業貢献につながる価値を高めて、開発や組織にかかるコストを下げ、間のマージンを高く取る、すなわちアウトカムを追求するためにある、といえます。

アーキテクチャなど個別の課題をミクロにだけ見るだけでなく、全体で価値をどう最大化するか、そのためにWilling to PayとWilling to Sellをどう調整するか、という考え方をしてみたんです。

この「価値を上げてコストを下げる」っていうのは、「売上（Willing to Pay）ー 原価（Willing to Sell）＝利益（Value）」と捉えると、損益計算書（P/L）をベースにした考え方だなとも思います。

これが正しいバランスだったらちゃんと利益が出ている、と言えます。

では、今回の登壇タイトルにもあるような「エンジニアリングの黒字化」とは何を指すのか？

例えば上記の表のように、かかっているコストの方が高すぎて、出している価値が相対的に少ないという構造だったら、「エンジニアリングが赤字」といえると思っています。これを黒字化させるのが、技術戦略を立案、実行する際に重要です。

では、具体的に見えているミクロの課題を、バリューベース戦略に沿ってどのように整理していくか？

技術戦略の中にある要素をざっくりと、WTPとWTSに分けてみました。

Willing to Payを上げるためには、プロダクトを進化させる、品質を上げる、価値を提供するスピードを高めるといった要素が挙げられます。一方、Willing to Sellを下げるには、開発や運用にかかっているコストを下げるとか、組織開発のコストを下げる、という要素があります。

そして、個別の課題をマッピングするために、さらに2～3段階ぐらい分解していくとこんな感じ。ちょっと見づらいですが、馴染みのある技術課題に近いところまで、解像度が上がってきました。

これらの中には、一意にマッピングできるか悩ましい課題もいくつかあります。そこで「二重の優位性」に立ち返って整理しなおします。

例えばアーキテクチャーに関わる課題を改善できたら、もちろんWilling to Payとして価値提供速度が上がることも、Willing to Sellとして開発の負担を下げることもありえますよね。これが「二重の優位性」にあたります。

「二重の優位性」があるいくつかの技術課題は、複数の箇所にマッピングすることにして、洗い出した技術課題とその関係性をすべてマッピングしました。するとこんな感じ。

これは弊社のEMが1時間くらいでパッとやってくれました。マッピングしながら「1つ解くだけで、複数の要素に高い効果が出る施策」を明らかにしていくと、「二重の優位性」を持つ施策を特定することができます。

こうして今ある課題をバリューベース戦略に沿って構造化して技術戦略と同定できたら、経営戦略と照らし合わせていきます。

例えば経営戦略として新規顧客を大幅に増やしたいんだったら、技術戦略としてはユーザーフローの改善をしてWTPを向上できたらいいのかな、とか。また、アップセルを重視してるんだったら、そのための分析基盤を整えて顧客行動を可視化するのが、中長期的なWTP向上につながるかなとか。あるいはコストを抑えて利益率を上げたいなら、今かかっているインフラなどのコストを最適化してWTSを下げるとか。

この考え方は、経営戦略ありきで、その実現のために開発側が出せる価値を先に定義して、そこからどんどん課題に下ろしていく、という川下りのような考え方ですね。

この構図で全ての課題に説明がつくかというと、そういうわけじゃない。なぜなら、エンジニアでないと見えない技術課題は、この構図だとなかなか出てこないんですね。

では、エンジニアにしか見えていない課題を経営戦略にどう昇華していくのか。このとき経営と対話する上でも、バリューベース戦略のフレームワークは有効だと思っています。

例えばアーキテクチャの複雑性が開発のボトルネックになっている時。

以前の僕なら「アーキテクチャー刷新して開発しやすい状態にしたい」という言い方をしたと思いますが、これを少し翻訳するだけでだいぶ心証が変わります。バリューベース戦略に則って整理すると、アーキテクチャ刷新により、Willing to Sellを下げる、つまり「開発にかかるコストが下がる」、さらにWilling to Payを上げる、つまり「（今経営戦略の中にある）事業の多面展開の速度を上げることができる」、と伝えられますね。

こうして、今ある課題を改善することが、バリューベース戦略でのWTP、WTSにどう影響するのかを整理して伝えることで、課題に取り組むための投資を勝ち取りやすくなります。

これは、エンジニアにしか見えない課題の改善が何に効くのかを、川上りのように、経営への価値提供に結びつけていくというような考え方ですね。

しかし、「これで双方向でアラインでき、解くべき課題が見えた」というわけではありません。

「解くべき課題」は無限にあります。その中で「今解くべき課題はどれなのか」を考えていかなくてはなりません。これにも、バリューベース戦略のフレームワークが役立ちます。

「今解くべき課題」を定めるとは、言い換えれば「今は解かない課題」を定めることでもあります。たくさんの技術課題をマッピングした上で、今のサービスや経営の背景と照らし合わせた上で、どれを劣後させないといけないかを特定して意思決定をする。これもエンジニアリングマネジメントだと思っています。

例えば、経営戦略として、ユースケース的に高いパフォーマンスを求められない時だったら、パフォーマンスの改善は劣後させるとか、資金調達した直後でキャッシュに余裕があり、市場を取りに行きたいとなら、コストにかかる課題を劣後させるとか。

これをバリューベース戦略に基づいてマッピングすると、こうなります。

目の前に見えている課題の抽象度を高くして、WTP、WTS、二重の優位性を整理する。そのうえで、川下りのように「経営課題を解決する課題」なのか、川上りのように「現場の技術課題から経営課題に昇華させた課題」なのか、また「今は解かない、と劣後させた課題」なのか、を分けていく。そして、リソースや他の開発施策とのバランスで、「今解くべき課題」を絞り込み、意思決定する。

このように、バリューベース戦略のフレームワークで技術課題を整理していくと、経営とコミュニケーションを取りやすくなっていくし、経営戦略と技術戦略の方向性を合わせていくことができます。

ここまで、バリューベース戦略のフレームワークを応用して、技術戦略を整理し、経営戦略とアラインしていく方法をお話しました。

ここからは、実際に組織でどう実践していったのかをお話します。

そもそもバリューベース戦略という考え方を、どう関係者に浸透させるかが重要だと考えていました。弊社でも知っている人が少なかったため、まずは技術戦略に深くかかわる経営メンバーやEMとの対話の中で、「バリューベース戦略」という言葉や考え方を使うようにしました。課題をマッピングしたり、開発組織が出すべきアウトカムを構造化する際に、「バリューベース戦略に沿って、このように整理しています」とシェアしていったんです。

開発組織全体に対しては、組織が実現したいことをメンバーにメッセージングする際に、バリューベース戦略の概念の部分に絞って伝えました。

右下に、全社会議で使った資料を貼っています。エンジニア全員に、ここまで話してきた内容を詳細かつ構造的に理解してもらおうとしても、エンジニアにとっては情報過多になってしまう。そのためこのタイミングでは、損益計算書（P/L）のような形でまとめています。

それからは実際に、バリューベース戦略に基づき、経営戦略の方向性を掴みながら技術戦略を練っていきました。

これは去年の下半期の話なのですが、当時は経営戦略としても、開発組織づくりへの課題感が強くありました。そのためWTSの中でも組織開発コストを下げていくことに注力する、と意思決定しました。

また、組織開発コストを下げながら、WTPの中でも「価値提供速度」を向上できる施策として、プロダクト開発における、エンジニアと関係部署との連携強化も行うことにしました。Willing to Sellを減らすことに主眼を置きながら、副次的にWilling to Payを高められるわけです。

この戦略を開発組織に説明するときは、先ほどの損益計算書の構造からブレイクダウンしながら、技術戦略の方向性や具体的に取り組むべきテーマを伝えました。

ではこの戦略をもとに、去年の下半期は何に取り組んでいたのか。

当時、経営起点でWilling to Sellを下げるために最もレバレッジが効く施策として、採用活動に注力しました。長年眠っていたテックブログの定期更新や、イベント登壇などは、自分やメンバー自身の学びの深化にも、会社のプレゼンにもなります。

ただ、これだけでは売り上げが上がらないので、技術起点でWilling to Payを上げながら、開発組織の課題を解決するための施策も、並行して進めていました。

当時の開発組織の課題は「生成AIを活用して新しい顧客体験を届けるための機能開発に取り組めていないこと」でした。

その解決策として、生成AIを用いた機能を有志でつくったのです。実際にユーザーからもめちゃくちゃ好評で、サブプロダクトとして展開することになりました。

この施策によって「新しい技術を使って探索することは、プロダクトの価値向上につながる」と示すことで、エンジニアリングの課題の解決が、プロダクトの価値向上につながると証明できました。詳細は先々週のDevelopers Summit 2025で話したので、よかったら見てもらえたらなと思います。

そして今ちょうど、バリューベース戦略に基づいて、次の技術戦略を立てています。

去年の実践から、「バリューベース戦略に基づいて技術戦略を立てて実行すると、アウトカムを生み出せる」ということは、エンジニアにも一定浸透していました。

今回改めて技術戦略を立てるうえで、組織には今どんな技術課題が眠っているのかを吸収することにしました。その際まずは、今いる30名ほどのエンジニア全員を集めて、メンバーに見えている技術課題を発散的に書き出してもらったのです。画面左側に掲載しています。

このようにメンバーから出てきた課題を、また全員で、画面右側のように構造化していきます。これは先ほど見せた、バリューベース戦略に則って技術課題を整理した際の樹形図と同じ構造になっています。その際メンバーに、バリューベース戦略のフレームワークを伝え、自分が挙げた課題をマッピングしてもらうのです。こうして課題の多い箇所を可視化しながら、その課題を解決するためのストーリーのつくりかたも話し合いました。

それ以降は私とEMの間で、「今やるべきこと」が何なのかを選んでいきました。経営戦略から川下り的に技術戦略がアラインしている課題はどれなのか、技術課題として顕在化していて川上りの考え方が必要なのはどれなのか、システム思考的に因果関係があり、二重の優位性が取れそうなものはどれなのか。こうして課題を分類し、バリューベース戦略というストーリーの中で「今やるべきこと」を決めていっています。

今の段階では、アーキテクチャーの刷新が、WTSである開発のコストを下げることにも、WTPとしてプロダクトを進化させることにも効くのではないか、というストーリーをつくろうとしています。

アーキテクチャには圧倒的に飛び抜けて課題が溜まっているうえに、二重の優位性が効く。ここに経営リソースを投下しましょう、という話もしやすいはずだと考え、今は説明の準備をしているところです。

では、今日の話をまとめます。

今日紹介した「バリューベース戦略」とは、ユーザーが払ってもいい最大金額（WTP）と、従業員やサプライヤーが組織に残ってもいい最低ライン（WTS）があって、その間のマージンを最大化することで価値を提供する、という考え方。WTPやWTSは、実際の価格とかコストを指すわけではありません。

これを技術戦略に転用します。技術戦略とは究極的に、「エンジニアリングのアウトカムを追求していくこと」。バリューベース戦略のWTP、WTSと同じような構造で、「事業貢献につながる価値」と「開発組織にかかるコスト」の2つに大別すると、エンジニアリングのアウトカムは、これらの差分を最大化することで大きくしていける、といえます。

開発組織にある課題を捉えていくためには、まずは図のようにWTP、WTSをそれぞれ分解します。そして、今あるマッピングしていきます。

技術戦略を経営戦略にアラインさせるためには、経営課題から川下り的に技術課題に落とし込んでいく方法と、技術課題から川上り的に経営課題に昇華していく方法があります。それと同時に、優先順位を劣後させる課題も決まっていきます。

この構図をつくれれば、エンジニアリングマネージャーとして解決したい技術課題を、経営戦略とアラインさせ、投資の意思決定をしやすくすることができるのではないかと考えています。

以上です。ありがとうございました。

執筆・編集：光松瞳