カケハシ Advent Calendar 2024の24日目の記事になります。

今年は、開発組織のビジョンと技術戦略を策定しました。本記事では、カケハシの開発組織が歩んできた軌跡を振り返りながら、技術戦略を立案するに至った背景やプロセスを詳しく紹介します。
対象読者は特定の肩書に限定していません。CTOやVPoEといった役職に関わらず、開発組織の変革や成長に関心をお持ちのすべての方を対象としています。特に、現場で課題に直面し、それを解決することで組織全体を前進させたいと考えている方々にとって、本記事が参考になれば幸いです。

本記事では、以下のテーマに焦点を当てています：

カケハシの開発組織が歩んできた軌跡
ビジョンの策定と課題の診断
技術戦略の基本方針と具体的な行動計画の立案

今回は、技術戦略やビジョンの具体的な内容そのものではなく、これらを策定するプロセスや背景に焦点を当てています。カケハシの開発組織が歩んできた軌跡を通じて得られた知見が、開発組織の未来を模索する皆さまにとってのヒントになれば幸いです。

私は誰か？
カケハシの開発組織が歩んできた軌跡 (個人視点)
技術戦略の策定
- 戦略立案のフレーム
- 実践
まとめ
更新履歴
- 2024-12-27

私は誰か？

技術戦略室でアーキテクトを担当している@kimutyamです。
2021年5月に入社して以来、さまざまなチームを渡り歩いてきましたが、簡潔にまとめると以下のような経歴になります：

2021年5月～: プロダクトドメイン期
2021年12月～: プラットフォーム期
2024年6月～: 技術戦略室期

新規事業の立ち上げからスタートし、組織横断的な取り組みを経て、現在は技術戦略室のアーキテクトとして活動しています。技術戦略室は、CTO直下のチームとして、CTOと連携しながら開発組織全体の横断的な課題や問題に取り組むことを使命としています。

カケハシの開発組織が歩んできた軌跡 (個人視点)

私は創業期から関わっていないため、カケハシの開発組織が歩んできた軌跡を網羅的に紹介することは難しいですが、私が入社したシリーズBラウンドから、現在のシリーズCラウンドに至るまでの間、社員数は100名台から300名台へと大幅に増加しました。この期間中、組織拡大に伴う課題や技術的な課題に取り組む多くの機会がありました。
本記事では、私がアーキテクトとして関わった部分に焦点を当ててご紹介します。

2021年5月~: プロダクトドメイン期

カケハシでは、医療ドメインの最前線であるプロダクトドメインの開発を通じて価値を提供したいと考えるエンジニアが、今も昔も多く所属しています。組織としても自主性を重んじたチーム体制が敷かれ、最終的な価値を提供するプロダクトドメインに対して積極的な投資が行われてきました。
一方で、プロダクトラインナップや顧客層の多角化が進む中、横の連携を強化する必要性が高まっていました。私の関わっていた新規事業では、多くの横の連携が必要でしたが、横断的な優先順位やドメイン間をまたいで開発をリードするロールが存在せず、協調して動くことが難しいと感じていました。
2021年11月頃、私が関わっていた新規事業がピボットを迎えたことを契機に、自らの価値貢献の場を模索することになりました。引き続き新規事業に関するPoC（概念実証）やプロトタイピングを進める選択肢もありましたが、ビジネススキームが変化する可能性が高い状況であったため、選択肢を広げることを決意しました。
新規事業を成功させるには、顧客基盤となる既存プロダクトの成長が不可欠であること、そしてそれに関連するプラットフォームチームの開発を推進する人材が不足している現状を踏まえ、プラットフォームチームへの異動を提案しました。この提案は受け入れられ、異動が実現しました。

2021年12月~:プラットフォーム期

プラットフォームチームの最初の業務は、認可や所属といった問題領域に対して、各プロダクト向けに汎用的な基盤を構築することでした。分析を進める中で、認可そのものよりも、所属に関する認可データを提供する仕組みが重要であることが判明しました。(関連: マイクロサービスを考慮した認可の設計)
これに基づき、「組織アカウントサービス」という境界づけられたコンテキストを定義し、マイクロサービスとして開発しました。この「組織アカウントサービス」では、HTTP API方式でデータを供給する方法と、ETL処理を行ってデータを供給する方法の両方を実現しました。

プラットフォームのマイクロサービスを開発する中で、以下のような基盤やルールの不足を認識することになりました：

マイクロサービス間連携
ETL処理を含めたデータ連携方法
マイクロサービスのデプロイ戦略
分散トレーシングなどシステム横断的な監視
サービスの可用性レベル
サービスの分割統治の基準
技術選定基準

これらの課題はプラットフォームに限定されたものではなく、プロダクトドメインを含む全社的な課題でした。横断的な課題に取り組むチームやワーキンググループが以前から存在していないわけではありませんでしたが、対応が追いついていませんでした。
プラットフォームチームには、プロダクト共通の認証サービスなどを提供するチームのほか、SREチームやDREチームも所属していました。

SREチーム：インフラアーキテクチャの整備や情報セキュリティのガバナンス・ガイドラインを推進。
DREチーム：データ基盤の運用や、データメッシュを推進するデータガバナンス・ガイドラインの整備。

また、プラットフォームチーム外では、有志によるワーキンググループ内で技術的な取り組みの共有や相談を行っていました。しかし、プロダクトドメインのVolatility(変動性)に追随できるほど、十分な人員が投下できておらず、課題の数は右肩上がりに増える一方でした。
「組織アカウントサービス」の開発がある程度落ち着いたタイミングで、私はプラットフォーム全体のアーキテクトとして課題解決に取り組むことにしました。具体的には以下の活動を行いました：

DevOps/DataOpsの支援
新たなプラットフォームサービスの立ち上げ
アーキテクチャレビュー体制の整備

しかし、開発組織としてどの技術に投資すべきか、またどのアーキテクチャポリシーを担保すべきかといった大きな問題領域は、未だ明確化されていませんでした。足元の重要課題への対処に追われている状況が続いていました。

主な課題

各方面からアーキテクチャや技術的課題が上がっていたが、全社的に取り組むための意思決定スキームが存在しなかった。
技術選定基準や開発プロセスの指針があったものの、事業成長に合わせたアップデートが後手に回っていた。
アーキテクチャレビューでの差し戻しが多く、オーバーヘッドが発生していた。
イネーブリングを実現するための組織的な投資が行えない状況が続いていた。

2024年6月~: 技術戦略室期

2024年3月、新CTOとして@yunon_physが就任し、開発組織に変化がありました。

改めて課題を共有し、CTO室の設立を提案していました。その提案だけがトリガーになったわけではないと思いますが、程なくして、全社的な課題に取り組む役割を担うようCTOからオファーを受け、技術戦略室の設立とともに主務として任命されました。この意思決定は迅速に行われ、すぐに具体的な活動を始められました。「CTO室」ではなく「技術戦略室」としたのは、ミッションをより明確に定義するためとのことです。
技術戦略室は私が主務として専任し、各ドメインのテックリードやEM（エンジニアリングマネージャー）数名が兼務する体制でスタートしました。ミッションや推進方法はチームの発足後に徐々に明確化しました。当初は「チームを横断する複合的課題に焦点を当て、アーキテクチャの方向性と行動指針を示すこと」をミッションと考えていました。
初期の活動として、アーキテクチャレビューで明らかになった課題を整理し、マイクロサービス間の連携を促進するためのイネーブリング活動に注力しました。その後、技術戦略の立案に改めて取り組みました。

技術戦略の策定

技術戦略を策定するきっかけとなったのは、FY25の予算計画でした。しかし、これは単に予算計画のために策定したわけではありません。戦略的なリソース投資を行うために、中長期的な（中期を1年、長期を3年と設定)視点を定め、アドホックな課題解決に頼らないスキームを構築することが目的でした。技術選定やアーキテクチャ、設計において拠り所がない場合、ミクロでは優れた方法でも、マクロで見ると技術的負債に発展したり、気付いたときには機会を逃し後戻りができなくなるリスクがあります。こうした背景から、中長期の視点で技術戦略を立てることが重要だと考えました。
カケハシにとって技術は、医療ドメインの課題を解決するための手段であり、プロダクトやソリューションを実現するために、いかに価値を提供できるかが鍵となります。このため、プロダクト戦略が先行し、それに基づいて技術戦略が続くべきだと考えていました。
カケハシ社内では、プロダクト戦略の言語化は進んでいませんでしたが、プロダクトの方向性はロードマップとして示されており、コーポレートビジョンや事業戦略も全社的に浸透していました。そのため、プロダクト戦略が明確になる以前でも技術戦略を立てることは可能だと判断しました。開発サイドから先行して技術戦略を検討し、Head of Productと対話を進める手段を選択しました。技術戦略の策定はCTOと共に進めましたが、プラットフォーム整備期に横断的課題へ取り組んだ実績を考慮いただき、立案過程では多くの権限を委譲していただけました。

戦略立案のフレーム

戦略とは、耳障りの良いビジョンや野心的な熱意を並べるものではなく、現状の重大な課題を分析し、それに対してどのように行動するかを示すものです。ビジョン（理想像）に向かう過程で取り上げたい問題領域は多くありますが、その中でも特に重要な課題を選び、リソースを集中して取り組むことが重要です。現状から理想に近づけるための道筋、それが戦略です。

図1. 戦略とは

この観点から見ると、戦略の策定方法は目標設定に似ています。

OKRだけで十分だという意見もあるかもしれません。しかし、短期目標だけでは中長期的な視点を欠き、手続き的な開発プロセスに陥りがちです。技術戦略は中長期的な視点を持ちつつ、短期目標と一貫性を保つ必要があります。
戦略の立て方は、『良い戦略、悪い戦略』を参考にしました。『The Engineering Executive's Primer』の中でも『良い戦略、悪い戦略』を基にした戦略の立て方が紹介されています。

１.　診断──状況を診断し、取り組むべき課題をみきわめる。良い診断は死活的に重要な問題点を選り分け、複雑に絡み合った状況を明快に解きほぐす。
２.　基本方針──診断で見つかった課題にどう取り組むか、大きな方向性と総合的な方針を示す。
３.　行動──ここで行動と呼ぶのは、基本方針を実行するために設計された一貫性のある一連の行動のことである。すべての行動をコーディネートして方針を実行する。

（出典：リチャード・P・ルメルト『良い戦略、悪い戦略』日本経済新聞出版、p.109）

『良い戦略、悪い戦略』ではこの3つの要素を戦略のカーネルと呼び、戦略の基本的構造と定義されています。この考え方を基に、以下の図のようなフレームに整理しました。

図2. 戦略立案のフレーム

診断の軸となるビジョンを明確にすること
基本方針における「人・モノ」は、アーキテクチャとして構造化し、行動を規定すること
基本方針における「コト」は、そのまま具体的な行動に落とし込むこと
市況環境や資金調達状況などの不確実性を考慮し、変化に対応するため、診断を1年周期で行い、戦略のカーネルを適宜見直すプロセスを回すこと

実践

ビジョンの策定

診断を分析する前段階で、問題を捉えるために開発ビジョンを明確にすることにしました。ここで言う「問題」とは、現状とビジョンの間にあるギャップを指し、「課題」とはその問題を解決するための具体的な行動を指します。

図3. 問題と課題

この図3は、図1の「戦略とは」と類似しています。戦略とは、ビジョンに向かう過程で取り上げるべき課題が無数に存在する中で、特に重要な問題を選び、それに集中して取り組むことです。開発現場の行動に結びつけるには、抽象度の高いコーポレートビジョンを開発組織の具体的な方向性へと落とし込む必要があると考えました。
ビジョンの策定といっても、0から1を生み出す創造的な行為ではありません。コーポレートビジョンを実現するために、開発組織としてどのような未来を目指すのかを示すものです。コーポレートビジョンを基に演繹し、開発組織の強みやエッセンスを掛け合わせてビジョンを策定しました。
ただし、これは100%論理的なプロセスだけで策定したわけではありません。ビジョンには想いや背景が伴わなければ、納得感を得ることは難しいからです。幸い、私はコーポレートビジョンに強く共感して入社しており、自分の経験や価値観ともリンクするビジョンを立案しました。立案後、CTOをはじめ、技術戦略室のメンバーやHead of Productからも共感を得て、最終的に確定しました。

診断

問題を適切に捉えるためには、解くべき問い、つまり主論点を明確にする必要があります。当初、診断の際に課題を羅列し、そこから帰納的に問題を導こうとしていましたが、うまくいきませんでした。CTOからのフィードバックで、問題を平易な言葉で定義し、誰にでも明確に理解できる状態にするよう指摘を受けました。経営層やHead of Product、技術戦略室のメンバーとの対話を重ねる必要があったため、このフィードバックは非常に的確でした。そこで、まずCTOに各ステークホルダーの関心事を整理してもらい、それらの関心事からビジョンと関連性の高い主論点を抽出しました。次に、主論点を中心に構成要素を分解し、課題を体系的に整理するためのロジカルツリーを構築しました。

以下のプロセスを意識しました：

主論点の特定：問題を解決するための問いを平易な言葉で定義し、全員が理解できる共通言語を作る。
分解と整理：主論点を軸に、関連する要素をMECEに分解し、網羅性と重複のない構造を確立する。
ロジカルツリーの構築：課題を論点に紐づけて階層化し、解決の優先順位やリソース配分を明確にする。

図4. イシューツリー

このアプローチにより、問題の構造が整理され、解決すべき課題が具体化しました。最終的に、ステークホルダー全員が問題意識を共有しやすくなり、対話を進めやすくなりました。

基本方針の策定

基本方針は、課題を解決するための大きな方向性と総合的な指針を示すものです。診断で抽出した課題を解決するため、基本方針を策定しました。注力すべきテーマと、それに関連する重要課題を3カ年の戦略的ロードマップに落とし込みました。このプロセスは、診断で抽出した課題を要約し、テーマを抽出する作業が中心であったため、比較的スムーズに進みました。しかし、基本方針を経営層や開発現場に共有した際、納得感が十分に得られませんでした。方向性そのものには異論はありませんでしたが、「もう少し前段階で開発現場の課題に向き合うべきではないか」という指摘がありました。当初は、ビジョンを基に現状とのギャップを分析し、解決策を進めるアプローチを考えていました。しかし、現状の課題に取り組む姿勢を同時に持たなければ、ビジョン達成に向けた組織全体のムーブメントを生み出すのは難しいことに気付きました。現場からのフィードバックを受ける中で、課題を整理したロジカルツリーの一部において蓋然性が十分に高くない部分があることに気付き、修正を加えました。幸い、問題の修正は大きな手戻りを必要としない範囲でした。

行動の定義

基本方針を実行するために、具体的な行動を考えることが最終目標です。基本方針は3年間のスパンで決めましたが、具体的な行動については、先のことが不確実で計画が古くなるのを防ぐため、1年間を目安に検討しました。まず、基本方針を基に、開発組織で扱う領域（ドメイン）の範囲を決め、その中で特に重要な解決すべきポイントを明らかにしました。そして、それを進めるための組織体制を設計しました。これは、今のシステムや組織の形に引っ張られないようにするためです。この設計を内部では「ヒト・モノ」のアーキテクチャと呼んでいます。これは、ドメイン駆動設計（DDD）のコンテキストマップに似ていますが、関係性を示すものではなく、事業の中で重要な要素を整理することに重きを置いています。この作業は、既存の組織やミッションに影響を与えるため、関係者と何度も話し合いを重ねる必要がありました。次に、システムや組織の形を大きく変えずに取り組める、チーム内での活動やプロセスの改善といった「コト」も検討しました。

まとめ

本記事では、技術戦略の立案プロセスを通じて、課題の診断から基本方針の策定、具体的な行動計画の定義に至るまでの考え方や実践内容を紹介しました。戦略は、現状とビジョンのギャップを明確にし、それを埋めるための優先課題にリソースを集中させることで、短期的な成果と中長期的な成長を両立させる道筋を示すものです。その過程では、診断を通じて課題を整理し、問題を平易な言葉で定義すること、そして関係者と対話を重ねて納得感を得ることが重要でした。また、基本方針を具現化するために、「ヒト・モノ」のアーキテクチャを設計し、プロセスや組織体制を最適化することにも注力しました。これにより、既存の構造に囚われることなく、新たな価値を創出する基盤を築きました。
戦略立案は単なる計画作りではなく、経営層から現場まで、全員が同じ目標に向かって進むための共通言語を作ることでもあります。そのため、トップダウンだけでなく、現場の視点を取り入れることが不可欠でした。
最後に、技術戦略は静的なものではなく、変化する環境に応じて進化し続けるべきものです。定期的な診断と見直しを通じて、戦略が現場の実態とビジョンの双方に適応できるよう更新し続けることが求められます。
本記事が、技術戦略を考える際のヒントや参考になれば幸いです。