こんにちは。ヘンリーで VPoP (VP of Product) をしている agatan です。 2025年の10月から、これまでのエンジニアとしての役割に加え、VP of Product & 製品部門長という役割を担うことになりました。
これまではテックリードやアーキテクトなど、エンジニアとして、ヘンリーの複雑で巨大なドメイン（レセコン・電子カルテ）に技術面からアプローチしてきました。 VPoPという立場になり、プロダクトと事業をより俯瞰して見る中で、自分の中にあった「ある種の先入観」に気づくことができました。 今日はその言語化と、これからのヘンリーの開発組織が目指す「技術と事業の関係性」について書いてみようと思います。
この記事は
の1日目の記事です！
「技術戦略は事業戦略の従属変数である」と知らぬ間に思い込んでいた
先日のアーキテクチャカンファレンスでもお話ししましたが、私たちが向き合っているドメインは非常に複雑で、ソフトウェアの設計と組織の設計は、そのドメインの性質に応じて考える必要があります。
これまで私は、「技術戦略」つまり「ある事業やプロダクトをどのような作り方で作るか」を決める際、事業戦略を一種の「前提条件（Input）」として捉えていました。 「事業として何を達成したいか（What）」がまずありきで、それを実現するための最適解として「どう作るか（How）」を策定する。依存の矢印は主に「事業 → 技術」への単方向である、というメンタルモデルを、無意識にもってしまっていたのです。
ヘンリーにおいても、マイクロサービス化の意思決定、モジュラーモノリスへの移行、Kotlin や GraphQL といった技術選定など、様々な意思決定に関わってきました。 これらは当然、ドメインの性質や採用市場、既存のコードベースといった制約の中で、その時点での事業目標を達成するためにベストだと考えた選択でした。
しかし、VPoPとして事業計画や予実管理、営業戦略といったレイヤーに深く触れるにつれ、この「単方向の依存」という認識自体が、実は自分自身の可能性、ひいてはエンジニアリング組織の可能性を狭めていたのではないか、と感じるようになりました。
技術戦略は「事業の選択肢」を創出する
今の私は、 「技術戦略と事業戦略は双方向の依存関係にあるべきだ」 と考えています。
事業戦略が技術戦略に要件を与えるのは当然ですが、同時に、技術戦略（現在のアーキテクチャ、チームのケイパビリティ、技術的負債の状況など）が、事業戦略に「リアリティ」と「選択肢」を与えます。
例えば、「小規模チームで作り切ればリスクは低いが時間が掛かる」、「大規模に体制を拡充するとリスクは高まるがうまくいけば時間を短縮できる」。 これは単なる開発リソース配分の話ではなく、事業のキャッシュフローや、市場参入のタイミングそのものを決定づける経営判断です。
また、もっと攻めの視点で言えば、優れた技術戦略は事業に新しいオプションを提供します。 私たちが進めているモジュラーモノリス化やドメイン駆動設計の実践は、単にコードを綺麗にするためだけのものではありません。
- 「このアーキテクチャになっているからこそ、競合他社が半年かかるところを、我々は既存モジュールの組み合わせで1ヶ月で検証できる」
- 「ここが疎結合になっているから、特定の診療科向けに機能を切り出して、別プランとして売り出すことができる」
- 「こういう作りにしておくと、最悪失敗してもこの部分だけを切り離して捨てられるので、ここは攻めよう」
このように、技術的な武器があるからこそ描ける事業戦略が存在します。 エンジニアが技術戦略を磨き込むことは、経営に対して「このルートなら、もっと速く、高く登れる」という登山ルートを提案することと同義なのです。
「不確実性」を飼いならすための対話
もちろん、技術的な挑戦には不確実性がつきものです。「想定より時間がかかる」「パフォーマンスや信頼性に悪影響が出た」といった事象は往々にして起こります。
大前提として、シンプルに技術戦略が間違っていたことを認めて、より良い技術戦略にブラッシュアップしていくことが、まず初めに考えることであるべきです。 しかし、それに加えて重要なのは、その事実を即座に事業戦略へフィードバックし、事業戦略そのものを書き換える勇気を持つことです。
事業、ビジネスサイド、開発など、いろんな視点があり、それぞれお互いの変数が相互に影響し合っていることを認め合い、一緒に悩み、計画を動的にアジャストしていく。 ヘンリーのような難易度の高いドメインで勝つためには、この「双方向の対話」のループを高速に回すことが重要だと思うようになりました。
一人のエンジニアとして
正直なところ、技術戦略と事業戦略の関係性をこのように捉えることができるようになったのは、VPoPになってからでした。それまでは、もちろん事業に貢献することを意識してやってきたつもりではありましたが、どこかで事業戦略自体は所与のものであるという考えをもってしまっていたような気がします。
今振り返れば、テックリードやエンジニアだった頃の自分も、「もっと良い作り方」だけでなく「もっと良い事業の登り方」を考えることができたはずだと感じています。 「事業のことは経営が決めること」と、無意識に自分の領分を技術領域に限定してしまっていたのです。
だからこそ、私はVPoPとして、エンジニアのみんなが「技術の枠」に閉じこもらず、事業戦略という変数すらもハックできるような環境を作っていきたいと考えています。
「エンジニアも全員PLを見て、営業指標を気にしながらコードを書け」みたいなことをいいたいわけではありません。 そうではなく、自分たちが普段向き合っているコードや仕様、開発プロセスの中に、実は事業を動かすための『隠れた変数』があるということを意識できるだけで、もっともっと大きな価値を生み出せるはずだと思っているのです。
ヘンリーでの開発は、降りてきた仕様を単に実装するような開発ではありませんが、それでも事業の登り方のようなレベルの話については「固定された定数（制約）」だと捉えがちです。 しかし、現場のエンジニアだけが知っている事実があるはずです。 現場でコードを書いているエンジニアこそが、プロダクトの「手触り」を一番知っています。
- 「今のアーキテクチャなら、実はこんな機能も低コストで実現できる」
- 「これだけのものを作るには、一度基盤を整備してから一気に作ったほうが速い」
といったような現場からのインサイトが、経営会議の決定をひっくり返すべきだと思っています。
今回は私のバックグラウンドがエンジニアであるため、技術戦略を例にお話ししましたが、これはエンジニアに限った話ではありません。 デザイナー、プロダクトマネージャー（PdM）、ドメインエキスパートなど、あらゆる職能の専門性が、事業戦略にとってクリティカルなインプットを生み出しうると考えています。
私はエンジニアであり、技術以外の領域にはどうしても見落としが生まれます。「専門性を持った人たちが、それぞれの専門性をリスペクトしながら、共通のゴールに向かって越境し合いながら走る」というチームが理想的なチームだと思っています。 だからこそ、エンジニア以外のメンバーからは、それぞれの専門性に基づいた「事業へのインプット」を与えてもらいたいし、エンジニアについても私の見落としに気付かせてもらいたい。それができるような情報流通やコミュニケーション土台を作っていきたいと考えています。
おわりに
「事業戦略は技術戦略に影響を与えるが、技術戦略もまた事業戦略に影響を与えるべき」 すごくふつうのことを言っているかもしれませんが、これを高いレベルで実践するのはなかなかに難しいことだと思います。
ヘンリーの開発組織は、仕様書通りに機能を作る工場ではありません。技術的な洞察をもって、事業の未来を提案するシンクタンクであり、それを最速で形にする実行部隊です。 複雑怪奇な社会課題を技術でハックし、そのレバレッジで事業を非連続に成長させる。そんな「エンジニアリング」を、私たちと一緒に楽しみませんか。
ヘンリーはソフトウェアエンジニアを積極的に募集しています！興味を持っていただけた方は、ぜひお話させてください！
id:nabeop
