自己紹介とMOSHという会社

改めて、AI時代における開発生産性と進化可能性を高める技術戦略というタイトルでお話しさせていただきます。MOSH株式会社でVPoTをしています。普段の業務では本日お話しする技術戦略と、それとセットで進めるエンジニア組織を見ていて、MOSHのビジョン実現に対してどこにレバレッジを効かせて、最短最速でそれを実現できるのか、逆にどこにリスクがあって阻害してしまうのかを考えています。趣味がOSSで、今日も少しお話ししますが、OrvalというOpenAPIからソースコードを自動生成するツールのメンテナーをしています。

MOSHのビジョンは、指名経済の実現です。サービスを個人間で買うとき、相手に対する信用がすごく大事になります。この人の危ないサービスだったらどうしよう、というのがあると思いますが、そこに対して安心して買うのは一定の難しさがありました。しかしSNSやYouTubeの普及によって個人の発信力が高まり、それに伴う安心感や信用が高まっているので、クリエイターエコノミー市場は経済圏が広がっています。

クリエイターにどういう方がいるのかを紹介すると、例えば語学学習・英語学習のクリエイターや、ヨガ・フィットネス、オンラインサロンなどがあり、個人の特性を生かしたクリエイターの職種は200種類以上も確認しています。中には個人や小規模の事業でやっているものの、数千万〜数億円という経済圏を作るクリエイターも現れています。そんなクリエイターに、MOSHはオールインワンプロダクトを提供しています。個人や小人数での事業運営は時間という資源が強い制約で、労働力というリソースは常に不足しています。それに対してオールインワンでカバーすることで、決済やコンテンツ管理、お客さんの管理のCRMなどをマルチプロダクト展開しています。

このマルチプロダクト展開は、これからお話しする技術戦略にも非常に大きな影響を与えているので、覚えておいてください。

問い：生産性向上で生まれた余剰を何に再投資するか

今日お話しすることですが、AIツールの使い方ではありません。AI時代に競争力を生み続ける技術戦略について、この数年間の試行錯誤から得た学びを共有する時間にしたいと思います。

まずこのセッションのテーマとして、生産性向上によって生まれた余剰を何に再投資しますか、という問いが提示されました。この問いを一緒に考えてみる時間にしたいとしつつ、最後には私自身の答えと、そこにたどり着くまでの経験や学びを伝えていくという構成となります。

本日のアジェンダは、まず生産性と価値についての認識合わせから始まります。次に、セッションタイトルにも含まれる「進化可能性」という重要なワードが何なのか、それを実現する技術戦略とは何かを紹介し、最後にそれがAI時代の開発の競争力にどうつながっているのかという結びの3部構成です。

生産性の定義とビルドトラップという罠

早速、生産性の定義から認識を合わせたいとして、書籍『技術革新と不平等の経済学』が引用しております。生産性の標準的な定義は「労働者1人当たりの平均生産量」だといいます。この生産性は、AIによって非常に飛躍した1年でした。高品質なプロトタイピングや開発フェーズの時間短縮、コストの低下によって、ソフトウェア開発のプロセスや組織の考え方、人数まで考え直させる1年だったと思います。

一方でこれによって、プロダクトマネジメントの課題もより顕著になっているといいます。代表的なものとして挙げられたのがビルドトラップです。書籍『プロダクトマネジメント』では、ビルドトラップは「実際に生み出された価値ではなく、機能の開発とリリースに集中してしまっている状況」と説明されています。プロジェクトはSQCDと作業のかたまりを進めていくものであり、プロダクトは成長に向けてアウトカムを実現し成功に至るまでプロジェクトを繰り返していく、という整理です。

その価値やアウトカムとは何かというと、同じ書籍で「顧客が価値を認めるのは、自分たちの問題が解決したり要望やニーズが満たされたときだけ」と断言されています。もう少し補足すると、価値とは交換システムの循環だと書かれています。プロダクトやサービスがあるだけでは価値自体はなく、それがお客さんに届いてお客さんが認めたときに対価としてお金やさまざまな価値をもらえる、この循環自体がアウトカムであり価値であるという説明です。提供者がサービスを持ち、お客さんがそれを受け取るというこの循環がすごく大事だと考えております。

この価値の循環サイクルでは、提供者側だけがサービスを強めると同時に問題も発生します。プロダクトの変更量が増加し、メンタルモデルの再構築がユーザーの負担になるということです。AIによって変化量はものすごく増加しますが、それを受け止めるエンドユーザーは人であり、ワーキングメモリという制約があります。ユーザーのワーキングメモリは変わらないのに届けるものは変わっていくというギャップが体験悪化につながる、これがリーンスタートアップでいう逆品質化だと説明されました。ビルドだけの最適化は不十分で、AIでビルド量が増えても計測が追いつかなければ、検証されていない機能の増加がそのままユーザー体験の逆品質化につながってしまいます。

この現象は、『リーンスタートアップ』の中でもシステム思考として言及されています。システムの一部を最適化するとシステム全体は必ず劣化する、複数の変数が連鎖するフィードバックループシステムとして捉えたとき、部分最適ではなく全体最適化が重要だという指摘です。

ここまでの課題を整理すると、まず大量生産が問題なのではありません。生産性を生産量と定義した場合、生産自体が増えることはむしろいいことだと考えています。一方で、複数の変数を同時に捉えられていないことが問題であり、ビルドトラップの本質は検証されていないことにあると整理されました。作る量と価値は別の話であり、複数の変数を同時にコントロールする必要がある、その検証のための仕組みが次のBMLループです。

BMLループ―AIが代替しない「計測」の重要性

BMLループは、『リーンスタートアップ』で解説されているBuild・Measure・Learnのサイクルです。製品を最適化するフィードバックループであり、重要なのはたくさんのものを効率的に作ることではなく、持続可能な事業の構築方法を短時間で学ぶためのフレームワークと記載されております。

AIはこのビルドをすごく代替して高速化してくれていますが、メジャー、つまり計測は代替しないというのがミソだと説明されております。この計測や学びがなぜ大事かというと、不確実性という土壌において進捗を的確に測る方法であるからだと捉えております。ビルド・メジャー・ラーンのメジャーがなければ的確な進捗がない、構築と計測がセットで、価値の維持は継続的な実験でしか成立しないということです。

これはそもそもソフトウェア開発そのものだと思います。書籍『Googleのソフトウェアエンジニアリング』にも、ソフトウェア製品の長期的なライフサイクルで必要となるのは、新しいアイデアの高速な探求、状況の変化やユーザーの問題への高速な応答、スケールした状態で速度を出すことの実現である、と書かれています。この価値を出し続けるために速度を出し続けるには、具体的にどうすればいいのか。その具体例を紹介していくのがアジェンダの2つ目です。

「進化可能性」を実現する7つの技術戦略―構造編

その答えが「進化可能性」だと思います。書籍『進化的アーキテクチャ』では、進化可能性を「システムが進化していく中で、他の特性を保護すること」と紹介しています。未来を固定化せず、全体的にアーキテクチャを進化させながら目の前の最適化もしていくという考え方です。変更容易性や対障害性など、アーキテクチャが守るべきものは目の前のことに場当たり的に対応すると犠牲になりがちですが、進化可能性はそこを保護するために進化を優先する考え方だと思います。

これをどう作るのかを話す前に、進化可能性とMOSHの歴史的背景についてお話します。MOSHのリアーキテクチャは実は3年前からスタートしています。当時のAIはCopilotのサジェストが出る程度で、まだ人がコードを書いていた時代です。とはいえ当時から分散や独立性は重視しており、人を中心とした開発体系設計でした。この歴史を踏まえて、特に重要だったものが具体的に7つ紹介します。

1つ目はマイクロサービス化です。メインのプロダクトのバックエンドがあり、その隣に新規事業のプロトタイプ的なプロダクト、旧システムがあります。旧システムは1つのマイクロサービスとして内部で参照され、通知やプラン管理、イベント集約といったマイクロサービスに依存しています。

プラン管理や通知をマイクロサービスとして優先しているのは、独立してデプロイできることと、要求される品質特性や構成が全然違うためです。

2つ目はアプリケーションの共通基盤です。これは冒頭のマルチプロダクト展開が影響していると思います。例えば顧客管理機能があったら契約プランを参照し、メッセージ配信機能を使うこともあります。それぞれの機能は共通して契約プランを参照し、売上管理の場合はさらに決済も参照する、というように複数の機能が複数の基盤を同時に使うことで、再利用可能な共通サービスプラットフォームを利用できます。

これによって一貫した体験と技術的複雑性のカプセル化を実現しています。1つ変更を加えると複数の機能に影響を与えられる、多くのインパクトを出せるところがレバレッジだと考えています。

3つ目はフルスタックTypeScriptとモノレポです。これは先ほどのマイクロサービスと共通基盤を扱うのをサポートする仕組みで、フロントエンド・バックエンドと、それを参照する共通基盤をすべてTypeScriptで書いています。モノレポはマイクロサービスと親和性がすごく高いです。単一のワークスペースで管理することで、TSコンフィグやリンター・フォーマッター、AIコンテキストも含めたコード管理ポリシーを裁量できます。

OpenAPIも一元管理しているので自動生成のタイミングをリポジトリの中で担保でき、インターフェースの不整合を排除できます。AIエージェントがリポジトリを収集してプランを作る際も、一つのリポジトリなら網羅的な収集ができ、精度が上がります。

4つ目は機能単位でのソースコード分離です。これは高凝集・疎結合を実現するためのもので、重要な観点としてフィーチャースライスデザインとコロケーションという似た概念が紹介されました。フィーチャースライスデザインは機能単位でロジックを凝集化し、機能間は疎結合にするという考え方です。フロントエンドはURLのパスごとにディレクトリがあり、そのパスのディレクトリの中に関係するコンポーネントやテストがすべて収まっている構成になっています。

コロケーションも同様に、コードの知識を集約することで認知負荷の低減とメンテナンス性向上を実現します。AIがこの機能を修正する際に特定のディレクトリだけを決め打ちで参照できれば精度も上がりますし、決まっている機能はこのディレクトリという構成なので並行開発もしやすいです。

ここまで4つの共通する構造について紹介した上で、共通する設計指針をお話しました。1つ目は推論範囲を限定すること、AIエージェントがプランニングや探索をするときにその範囲を限定することで精度を上げていくというものです。

2つ目は変更の影響範囲を局所化すること、バックエンドならハンドラー単位、フロントエンドならルーティング単位で局所化することで、さらに高凝集・疎結合を進め、並列開発も可能にすることを意識しています。これは部分的に進化できる構造を作ることです。

7つの技術戦略―プラクティス編

ここから後半3つのプラクティスの紹介に移ります。5つ目は開発ごとに独立したプレビュー環境です。従来はステージング環境を共有し、各チームや開発単位でテスト環境を譲り合っていましたが、プレビュー環境の場合はプルリクエスト単位で専用の検証環境につながります。マージやクローズのタイミングで自動停止しますし、一定時間経過でも自動停止します。

単一のステージング環境の課題は並行開発や検証が間に合わないことだったので、これがすごく活躍しています。開発しながらその機能を社内で公開して、エンジニアではないメンバーにもフィードバックを素早く取り入れることもできています。

6つ目はスキーマ駆動開発です。各サービスのインターフェースをOpenAPIで定義し、それによってソースコードを自動生成しています。クライアント・サーバー間の不整合を解消するもので、単一のワークスペースで管理しているそれぞれのパッケージの中で、クライアントとサーバーのソースコード自動生成のタイミングが一致し、不整合は起きない。

クライアントが自動生成されるということは、そのクライアントが何を自動生成しているかを見れば、このパッケージが何に依存しているかも明示される、これはインテグレーションと依存関係管理の問題にまさに対応しているためです。

このスキーマ駆動開発をもう少し深掘りすると、すごくいいのが契約による設計が実現するということです。『マイクロサービスアーキテクチャ』でも、スキーマがない場合は破壊的変更を把握するためにテストでさらに多くの作業をしなければならない、と書かれています。この契約による設計の契約とは、スキーマがそのままサービス間の契約になるということです。E2Eテストを回避できることも大きく、シナリオの網羅が非常に難しく非現実的であること、安定した構築自体の難易度が高いです。仮に0.1%で不利益なテストでも、それが100個集合して同時に実行すると9.5%の確率で失敗してしまいます。さらにE2Eテストは結合したテストが必要になるため、マイクロサービスで話した独立デプロイの可能性が低下してしまうという問題もあります。

この契約による設計によって担保されることで、自動生成はすごく効果を発揮します。自動生成は決定論的であり、AI時代だからこそこの決定論による生成が重宝しており、決定論的に解決できるものはそうしたいという考えのもと積極的に活用しています。MOSHでは機能にすると2,397、これはAPIクライアントやサーバー、MCPツールもこれで生成しているといいます。ファイル数でいうと14,118ファイル、ソースコードの行数でいうと588,297行が、この資料を作った時点で自動生成されており、今もどんどん増えています。

最後、7つ目はガードレールと規約です。基本的なリンターやフォーマッター、タイプチェッカーはもともと入れていたものの、それだけでは足りないため、独自のカスタムルールを運用しています。一例として紹介されたのがデザインシステムです。デザインシステムの構築とプロダクトの機能開発は、リアーキテクチャのタイミングで同時進行しているため、整備が間に合っていないコンポーネントがいくつもあり、後追いで修正しています。

共通コンポーネントは67、細分化するとファンクション単位で221あり、これに後追いで追従していくのが大変なポイントです。逸脱を検出するカスタムのBiomeルールも作っており、一例として紹介されたテキストコンポーネントの整備プルリクエストでは、ファイルが361件、増減はプラス1,419・マイナス1,250という大きな変更でした。

もう一つがDBスキーマです。「prisma-strong-migrations」というツールをOSSとして自作しました。PrismaとPostgreSQLに特化したマイグレーションの安全性チェックで、Prismaが発行するSQLにリスクや規約の違反があった場合にエラー処理をしてくれます。人に加えてAIエージェントが自律的に修正することを前提に作られています。

エラーメッセージのサンプルでは、何が問題かがバツで示され、どういうアプローチで対処すべきかも出力される仕組みで、AIがこれを読み取って次のアクションに自律的に進めるようになっています。39のルールを定義しています。

もう一つがOpenAPIです。これにもカスタムリンターを入れており、ツールはRedocly CLIを使っています。MOSHでは標準ルールに加えてカスタムルール10個、プラグインも7個追加しています。

OpenAPIをどれだけ管理しているかというと、パス数が359、スキーマオブジェクトの数が201、ファイル数561、全部のYAMLを合計すると40,916あるといいます。これを導入したとき、違反数は初手で3,650あり、非常に渋いという経験をしました。

進化可能性がもたらした効果とAI時代の競争戦略

ここまで7つ紹介した上で、アジェンダ2の問いである「進化可能性はどう作るか」に戻りたいと思います。進化可能性はプラットフォームの積み重ねによって作られる、ということです。3年前からのリアーキテクチャは当時AIへの最適化を目的にしていなかったものの、結果としてAIエージェントの目的に相性が良かったと思います。重要な効果として、コンテキストを小さくすること、契約を明確にすること、決定論的な部分を増やすこと、並列化と自己修正を目指すことの5点です。

プラットフォームに加えて、AIの進化に合わせて投資を増やした部分がAIエージェントハーネスの強化です。リンターやスキルを増やす、コンテキスト管理をする、規約違反がマージされたプルリクエストを拾ってリカバリを投げるといったことも試しました。ここまで独立性を高めているのは、AIによるスロップや破壊も影響範囲を制限してコントロールすることで、可逆性を高めることを一定許容する選択をしているためです。

フロントエンドは機能単位で分かれており、バックエンドはさらに細かく、マイクロサービスで分離された中でも機能単位でフィーチャースライスしているのでかなり局所的になっています。一方で、影響範囲を制限できないインターフェース部分は人が重点的にレビューしています。MOSHはSPAでアプリケーションを作っているため、フロント・バックエンド・DBという3層があり、このつなぎ目は層をまたぐため非可逆性が高く、重点的にレビューしているいます。

フロントエンドとバックエンドの間はOpenAPIスキーマ、バックエンドとDBの間はDBスキーマがその境界にあたります。人のレビューをサポートするツールも欲しいということで、Redocly CLIのカスタムプラグインや自作のOSSサポートツールを作っており、決定論で対処できるものはリンターにどんどん任せる、というのを強化してきました。

こうした進化可能性への投資が競争力につながったのかが大事なポイントでした。デプロイ数は43倍になりました。これは3年間の変化で、それぞれの期間で9倍、2.4倍、2倍になりました。エンジニアの人数も同時期に3.5倍になっており、3年前に10人だったのが今は35人程度になっているといいます。人数増加に比べものにならないほどデプロイ数が増加しました。

AI活用でマージPRが4倍になった開発ユニットも発生しており、開発ユニットとはエンジニア3〜5人の開発単位を指しております。マルチプロダクト展開についても、直近1年で13の新機能、11の既存機能のリニューアル、6つの共通基盤開発を行い、自社のAIエージェントやMCP開発にも積極的に投資できています。

数字だけでなく見た目でも分かりやすい例として、AIの精度向上です。決済リンク一覧という機能について、片方はデザイナーがデザインしたもの、もう片方はエンジニアがAIエージェントにプロンプトを渡して自動生成してもらったプロトタイピングです。全く同じではないものの、押さえておきたい情報設計のレベルは結構押さえられていて、大きな違いはないです。これだけのクオリティのプロトタイピングが一発ででき、プレビュー環境などで積極的に社内公開できることが大きな恩恵でした。

このように進化可能性はプロダクト開発の効率化だけでなく、開発速度や組織のスケール、エンジニア人数、新しい技術の導入など様々な領域を進化可能にしており、AIによってさらに強力な競争戦略になっておりました。

では生産性向上と競争戦略についてどう整理しているのか、もう一歩踏み込むと生産性はAIとプラットフォームの両輪だと捉えています。仮にAIがレベル10になってもプラットフォームがレベル1なら掛け算で10にしかなりませんが、自分たちでコントロールできるプラットフォームもその分10倍になれば100倍になる。AIによる生産性向上は当たり前になり差別化にはなりにくいため、重要なのは余剰の使い道だと考えています。

同時に、生産性の分岐構造も起きていいます。生産性が高い組織は余剰もできやすく、それを生かして資産化していくとさらに生産性が上がり、変化にも適応していける、それが最終的にユーザーの価値につながります。生産性が低い組織はそもそも余剰を作るのが難しく、資産化できないため適応力も優位性も減り、ユーザーの価値も届きにくくなる、という分岐構造があります。

この分岐はAIによって一般化したと考えております。これまでは高い生産性を持つ組織だけが、生産性向上後の余剰を何に再投資するかという難しい問いに直面していましたが、AIによって多くの組織が生産性向上を経験したことで、この問いも民主化されていると学びました。

ここでようやく最初の冒頭の問いに戻ります。生産性向上によって生まれた余剰を何に再投資しますか。私の答えは、AI活用の生産性向上で生まれた余剰を、消費ではなく未来の生産性と進化可能性を生む仕組みに再投資する、です。複利構造を持つ技術資産を構築できるかが、AI時代の開発競争力を決めると考えています。

残された課題とまとめ

ただ、残された課題もあるとして、まとめの前に3点紹介します。1つ目は、冒頭で話した計測・検証に対するAI活用がまだできていないことです。量だけでなく価値も含めた生産性向上が次のトライです。2つ目は、人のクリエイティビティと標準化のバランスです。生産性はこのセッションの定義だと一人当たりの平均生産量であり、組織や集団を前提にしているため個人のばらつきをどうフォローしていくかという課題があります。

またハーネスをガチガチに組んだ結果、トッププレイヤーの工夫の余地が減って足かせになってしまうこともあり得ると思います。人のクリエイティビティを残しつつ最低ラインを上げていくバランス感覚がかなり難しいと感じています。低い基準に合わせるとガードレールが膨大になり、CIの速度やコストに跳ね返ってくるため、これも全体最適が必要だと思います。3つ目は、ドメイン知識の上流でのカプセル化です。ドメイン駆動設計の用語でドメイン知識やビジネスルールのカプセル化はAIが見過ごしがちなので、課題だと考えています。

最後のまとめとして、AIは生産量を底上げしたこと、価値には複数の変数が複雑に関わること、計測と適応の実験には進化可能性が必要であること、進化可能性はプラットフォームの積み上げでありAIとも高い親和性を持つこと、そしてAIによる生産性の底上げは、高い生産性を持つ組織が直面していた問いに対して、福利構造を持つ技術資産を構築できるかがAI時代の開発においての競争力を決めると考えております。

アーカイブ動画・発表資料

イベント本編は、アーカイブ動画を公開しています。また、当日の発表資料も掲載しています。あわせてご覧ください。

▼動画はこちら

※動画の視聴にはFindyへのログインが必要です。