こんにちは、プロダクト開発基盤チームでEngineering Managerをしている Yoshioka (@tsuyogoro) です。
2025年、LegalOn Technologiesはマルチプロダクト戦略を掲げ、複数の新規事業プロダクトを同時にスタートしました。本記事では、その開発を支える基盤チームの立ち上げから運営まで、「プラットフォームもプロダクトだ」という考え方をどう実践してきたかをご紹介します。完璧な正解ではなく、試行錯誤の記録として、同じような課題に向き合う方々の参考になれば幸いです。
この記事は以下のような方に向けて書いています
- プラットフォーム/開発基盤チームのリードやメンバー
- エンジニアリングマネージャー、テックリード
- これから基盤チームを立ち上げる方
特に、複数のプロダクトやチームを横断して、開発基盤の設計や運営に関わる方に参考になる内容です。
この記事から得られること
私たちが2025年に実践してきた開発基盤チームの運営について、以下の視点でご紹介します。
- 「プラットフォームもプロダクトだ」という信念：なぜそう考えて、どう実践したのか
- ロードマップの作り方：全社戦略とどう接続して、優先度をどう判断したか
- コラボレーションモードという選択：早すぎる抽象化を避けて、具体から価値を作る方法
- 「静かな平和」という成果指標：派手な改善ではなく、問題が起きなかったこと自体が価値になる
LegalOn Technologiesの開発体制にかなり深く踏み込んだ記事になっています。スマートなプロダクトを開発している自負はありますが、開発現場は泥臭く、地に足をつけて進めています。そんな一面も伝われば幸いです。
はじめに
2025年、LegalOn TechnologiesはARR100億を突破し、次の手としてマルチプロダクト戦略を掲げ、リーガル領域で培った技術と知見を活かした複数の新規事業プロダクトの開発を同時にスタートさせました。
そんな中、新規事業プロダクトをスムーズに立ち上げて、サステナブルに運用できる開発体制を実現するために立ち上がったのが、プロダクト開発基盤（通称：P開）です。
立ち上げ当初、新規事業プロダクトの開発はまだ軌道に乗るか乗らないかのタイミング。そこでまず、チームのミッションとフォーカスすべき箇所を言語化することから始めました。ただ、その過程で大きな課題が見えてきました。
具体性のジレンマ
P開として、全事業プロダクトへの貢献を期待される大きな役割がありました。ただ、その「貢献」の中身に具体性が欠けていると、チーム間の期待値が揃いません。
「とりあえずあのチームに任せればいいや」という"何でも屋"になるリスク。「何をやっているか分からない、何もやってないのでは？」という"何でも無い屋"になるリスク。この両方が存在していました。
特に前者を受け入れて、来た案件を一つずつ「作っては出し」を繰り返すと、どうなるか。まとまりのない全体像、一貫性のない判断基準、属人化した知識——こうした未来が容易に想像できました。
こうした状況の中で、私たちはある明確な信念を掲げることにしました。
「プラットフォームもプロダクトだ」という信念
私たちは「LegalOn Technologiesの事業プロダクト開発を支えるプロダクト」を開発するチームになることにしました。顧客はエンドユーザーではなく、社内の開発者たちです。
なお、本記事では「プロダクト」という言葉が2つの意味で登場します。混乱を避けるため、ここで用語を定義しておきます。
| 事業プロダクト | 基盤プロダクト | |
|---|---|---|
| 主な顧客 | エンドユーザー | 社内の開発チーム |
| 提供価値 | 業務の効率化・リスク管理など | 開発スピードの向上・運用の安定化 |
| 成功指標 | チャーン率・MRR・ユーザー満足度など | デプロイ頻度・リードタイム・開発体験(DX) |
以降、「事業プロダクト」「基盤プロダクト」を区別して説明していきます。また、プロダクト一般の話に触れる際には “プロダクト” と表現します。
開発の "門番" にはならない
P開立ち上げ時、「これを必ず使ってください」「このプロセスに従ってください」といった、開発プロセスを横断的に決める立ち位置だと捉える声もありました。しかし、そうした存在は開発のボトルネックになる恐れがあります。特に「全ての事業プロダクト」を対象とするP開では尚更です。
私たちが目指したのは、各チームの裁量を守りながら、本当に必要な共通基盤を提供することでした。
"プロダクト"の要素がチームの存在を明確にする
基盤プロダクトも "プロダクト" であることから、明確になる・明確にしなくてはならないポイントが出てきます。これにきちんと向き合うことで、チームの存在が明確になります。
1) 顧客が明確である
基盤プロダクトの顧客は、開発チーム（事業プロダクトの開発者たち）です。「基盤チームに相談」ではなく、「基盤プロダクトに要件やfeature requestを出す」というように、プロダクトとしての窓口と責任を持つようにしました。
2) 提供価値が明確である
提供したい価値は「開発から運用までの速度と安心」。開発の立ち上がりをスムーズにして、かつ、「それを使っておけば間違いない」という安心感を開発組織全体にもたらすことです。
3) ロードマップ（開発プラン）と意思決定の軸が明確である
一般的な "プロダクト" 同様、独自のロードマップ・開発プランを持ちます。要件を受け付ける窓口も存在します。"プロダクト" としての方向性も持つので、「やる or やらない」もロジカルに、意志を持って運用されます。
プロダクト名をつけ、コンセプトを明確にした
私たちは2つの柱を定義しました。P開立ち上げ前から存在していた "Akupara" という基盤プロダクトと、Akuparaの守備範囲外をカバーする "Avalon" という新しい基盤プロダクトです。両プロダクトのコンセプトを以下のように明確にしました。
Avalon：汎用サブドメインのソリューション群。認証・認可、請求・決済、監査ログ、通知、データ基盤連携など、事業プロダクト横断で必要となる機能を容易に組み込めるものの集合です。
Akupara：事業プロダクト開発のゴールデンパスを提供するソリューション・インフラ群。アプリケーションのテンプレート、CI/CDパイプライン、オブザーバビリティツールキット、セキュアな初期設定などを提供します。最短で「動く・計測できる・安全な」初期状態へ到達できることを目指します。詳しくは 今年、チームメンバーがPlatform Engineering Kaigiへ登壇した際のブログ をご覧ください。
これらのプロダクト名とコンセプトを普段のチームワークで当たり前のように使うことで、メンバーの目線合わせに大きな力を発揮しました。チーム外とのコミュニケーションでも同様です。現在（2025年12月時点）、製品開発チームでこれらのプロダクトを知らない人は一人もいません。
長期的な予測よりも、「プランの実行」にフォーカスした
"プロダクト" には「何を、いつ、誰に届けるか」を示すロードマップ（長期的プラン）が不可欠です。しかし、状況は複数の新規事業プロダクトが並行して立ち上がる激動の最中。チームも立ち上がったばかりで、1〜2年先を見通すのは至難の業でした。
そこで私たちは、長期的な予測にこだわるのをやめました。代わりに、中期的なプランを立てて、短期的に確実に実行し続ける体制づくりを優先することにしたのです。
具体策として採用したのが、「全社戦略」を羅針盤とした柔軟なプラン運用。実行計画はすべて、半期（6ヶ月）ごとのチーム目標に集約します。
基盤プロダクトの顧客は「開発チーム」ですが、その背後には常に「全社戦略」があります。そこで構築したのが、以下の枠組みです。
チーム目標設計の枠組み
経営発信の戦略文書を読み込む
LegalOn Technologiesでは、経営が策定した全社戦略がドキュメントとして社内共有されています。これを徹底的に読み込み、基盤プロダクトとして貢献できるポイントを半期のAchievementとして抽出します。
事業プロダクト側の大方針をキャッチアップ
各事業プロダクトの定例資料や議論から、開発の方向性や課題を把握。これもAchievementに落とし込みます。
Achievement → Key Outcome → Epic
Achievementから具体的なKey Outcomeを設計し、そこから直接Epic（メンバーにアサインするプロジェクトの単位）を作成。これらをタスク管理システム（Notion）上で全てリンクさせる独自の仕組みを導入しました。
効果：「今の仕事が戦略のどこに効くか」を言える状態
この枠組みがもたらしたのは、「今日やっている仕事が全社戦略のどこに効くか」を明示的に言える状態です。
- メンバーの納得感とモチベーション向上
- 優先度判断の明確化（「これは今期のチーム目標に効くか？」で判断）
- ステークホルダーへの説明力向上（「なぜそれをやるのか」を戦略から説明）
といった効果に繋がりました。
以上の取り組みを通して、ミッションの解像度を上げることができ、いくつかのテーマに焦点を定めて開発を進めることができるようになりました。次のセクションでは、認証基盤開発のエピソードを取り上げます。
取り組んだ基盤開発の具体例：認証基盤（Avalonの一部）
アプローチの選択
ロードマップから選択したのは、認証基盤の開発。開発中の新規事業プロダクト全てに必要な基盤です。
初期段階では「事業プロダクト間で同じアカウントを使って、複数サービスへログインできる」案も検討しました。しかし、新規事業プロダクトの開発が道半ばの中、影響範囲の大きい部分をサービス化すると、SPOF化のリスクが高まる懸念がありました。
そこで採用したのが、「ワンコード、事業プロダクト別環境」。同じコードから事業プロダクトごとにDocker imageを作成してデプロイするアプローチです。SPOF化リスクを避けつつ、配布と更新の摩擦を減らして、並列立ち上げに追随できる構成を目指しました。
直面した壁：抽象化の罠
複数事業プロダクトの立ち上げと並行して作る中で、「基盤プロダクトをつくる」という目線が、事業プロダクト側とP開双方に入ってしまいました。すると議論が抽象的になり、具体的な要求が見えにくくなってしまったのです。これこそ、早すぎる抽象化の典型的な罠でした。
方針転換：コラボレーションモードへ
そこで、アプローチを大転換。事業プロダクト側は抽象化を気にせず「作りたいものを作る」にフォーカスしてもらうことにしたのです。
P開のメンバーを1人ずつ各事業プロダクトチームに配置。事業プロダクト側と「何を作るか、どう作るか」の議論に時間を使いつつ、実際のコーディングはP開側でP開メンバーと協力して進める体制を構築しました。
この「コラボレーションモード」が効果を発揮。片足を事業プロダクト側に入れている各メンバーから、認証基盤への要件が集まってきます。P開では各種事業プロダクトからの要件を一つのコードベースへ実装していきます。何でもかんでも入れるわけではなく、基盤として適切な機能・要件かをシビアに見て判断。しかし、事業プロダクトA向けに実装したものは、事業プロダクトBにも反映可能です。
効果：「静かな平和」の実現
事業プロダクト側は自分たちのドメインに集中できるようになり、P開側は具体的な要求から基盤を作れるようになりました。各事業プロダクトによる認証の再発明を防ぎ、一貫性を担保できたのです。
成果は「Avalonがあるから劇的に良くなった」というよりも、「無いことによる問題を意識せずに済んだ」こと——組織内に静かな平和が保たれたこと自体が価値でした。2025年12月現在、開発中の事業プロダクトには認証基盤がすでに組み込まれており、リリースに向けて終盤に差し掛かっています。
2025年の成果（2025年12月時点）
では、この1年で何が生まれたのか。
事業プロダクト開発への貢献
各事業プロダクトに認証基盤が組み込まれて、開発終盤に差し掛かっている状態です。
AvalonとAkuparaの両方で複数の価値を生み出して、届けることができています。主な成果を挙げると、以下のようなものです。
- 認証基盤
- Protobufスキーマの全社共通管理基盤
- 既存事業プロダクト内の汎用ライブラリ・ツールの基盤プロダクトへの移植
- Akuparaのエンハンスメント
- データ基盤連携の汎用ライブラリ
チーム目標管理の効果
半年分の期待値を明確にした上で、チームを走らせることができています。期中に大きくブレることなく走れる状態を実現できたことは、大きな成果です。
開発というものはどうしても時間がかかります。一定の難易度があるもの、価値のあるものになれば尚更です。期中のブレを抑えられたのは、チーム目標管理の枠組みがしっかり機能した証だと考えています。
副次的効果
次の期の目標を早いタイミングで考えられる状態も生まれています。2026年2月下旬から次の半期のチーム目標を立て始められる見込みで、余裕を持った計画サイクルが回り始めています。
まとめと今後の展開
この1年間、プロダクト開発基盤を「開発チームに提供する基盤プロダクト」として捉え、AvalonとAkuparaの二本柱で運営してきました。「開発から運用までの速度×安心」を提供価値とし、チーム目標管理で期中のブレを抑えながら、認証基盤をはじめとする汎用ライブラリやツールを開発しました。
2026年以降も、この枠組みを維持しながら次のステップに進みます。事業プロダクト戦略に紐づく認証基盤の展開、進行中の事業プロダクト開発から見えてきた新たなニーズへの対応、そして余裕を持った計画立案を継続します。
基盤プロダクトは一度作って終わりではありません。事業プロダクトと共に成長し続けることが真の価値を生み出します。これからも「顧客＝開発チーム」の速度を上げるため、走り続けて参ります！
仲間募集と宣伝
最後に、オフィスからの景色をご紹介します。この景色を眺めながら、一緒に基盤プロダクトの開発に挑戦してみませんか？プロダクト開発基盤チームでは、以下のポジションを募集しています。少しでもご興味のある方は以下からご応募ください！
TECH-111- Software Engineer, Backend - Product Foundation - 株式会社LegalOn Technologies
TECH-203- Platform Engineer - Product Foundation - 株式会社LegalOn Technologies
そして1/22（木）に、渋谷駅新南口改札から徒歩30秒の渋谷サクラステージのオフィスにて「リファラルミートアップ」を開催します。当社のエンジニアがどのような仕事をしているのか、ざっくばらんに聞けるイベントです。我々としても初の試みですが、この記事を読んで「ちょっと気になるかも？」と感じた方は、ぜひお声がけください！
【1/22イベント開催！✨】LegalOn Technologies リファラル採用について | Notion
謝辞
年末のお忙しい中、ブログレビューにご協力いただいたプロダクト開発基盤チームのみなさん、CTOオフィスメンバー、HRメンバーに感謝申し上げます。ブログレビューだけでなく、日々のコラボレーションの積み重ねが、チームをここまで形にしてきました。2026年も、より大きな成功を生み出せるよう一緒に頑張っていきましょう！
