ストラテジーと実装の一致
「ストラテジーと実装の一致」という言葉は、10Xの矢本氏の言葉。詳細は、以下の記事に記載されている。
ストラテジーと実装の一致
スタートアップは何もない状態からサービスを構築するため、当初は「ストラテジー(戦略)」と「実装」の乖離がゼロの状態から始まる。しかし、開発が進むにつれて両者の間にどうしてもギャップが生じがち。そこで重要なのが、いかにストラテジーと実装の“一致”を保ち続けるかという点になる。これは単に戦略だけ、あるいはエンジニア側だけの努力で実現するのは難しく、プロダクトマネジメントによってリリースサイクルを短く保つことが重要。
私がスタートアップの一人目のエンジニアとして創業初期から強く実感したのは、「プロダクトの設計自体が実装との乖離を生むようではいけない」ということだった。
「フィーチャーの輪」とリリースサイクル
フィーチャーの依存関係が生む「輪」
プロダクトには、複数の機能が互いに依存する構造がある。依存関係が強い機能は、同時にリリースしないとユーザーが体験できない状況を生み出し、それが「最小の輪」としてまとまる。
たとえば「オンラインで同時にお絵描きができるサービス」を想定して
- お絵描き機能(コア機能)
- 登録機能(ユーザー登録・サインイン/アウト・退会)
- リワード機能(ログインや機能利用でポイント付与)
- ショップ機能(ポイントを使って色やスタンプを購入)
といった機能を実装したいとする。登録してポイントを稼ぎ、機能を買ってさらにお絵描きを楽しみ、お絵描きをするとポイントがもらえる、といったユーザーのアクションサイクルを想定している。
このとき、設計によっては「色を購入しないとお絵描きできない」「ポイントを稼がないと買い物ができない」といった制約が生じ、各機能をすべてそろえないとユーザーがサービスを体験できない設計になる可能性がある。そうなると、これら4つの機能は同時リリースが必須となり、大きな「輪」が生まれてしまう。
機能の挙動的な依存だけでなく、意味的な依存もある。例えば、ポイントを貯める機能はポイントを使う機能より先行してリリース可能だが、それはサービスとしては意味を持たない。
一見すると当たり前のように見えるが、たとえばPLG(Product Led Growth)の戦略を採用したい場合、紹介機能やリワード付与を実装する過程で登録機能まわりに必要な実装が増える可能性がある。その結果、ただ「登録機能を使ってPLGを実現したかった」だけなのに、フィーチャーの輪が肥大化し、リリースが遅れるケースは想像に難くない。
フィーチャーの輪の大きさをコントロールする
しかし、設計次第では依存関係を緩やかにし、機能を段階的にリリースすることも可能。たとえば、
- ログインなしでもお絵描きできる
- 初期から数色だけ使える(追加色やスタンプはログイン＆ポイント購入)
といった工夫により、コア機能(お絵描き)を先にリリースし、他機能は後から段階的に追加できるようになる。
このように、「最小の輪」を小さく設計できれば、スモールスタートで早いリリースが実現しやすくなる。
小さなリリースのメリット
1. ストラテジーとの乖離を減らす
小さくリリースを繰り返すことで、常に最新の戦略と実装が一致した状態を保ちやすくなる。大きな機能をまとめて作ってしまうと、開発途中で戦略が変わったときに大幅な修正が必要になる。
2. 機能改善がしやすい
少しずつユーザーに触れてもらいながら、機能ごとのフィードバックを早期に得られる。大きな輪を完成させるまでリリースできないと、序盤に作ったまだリリースされていない機能を作り直したり修正したりする事態が生じ、開発効率も悪化しやすい。これはエンジニアにとっても大きなストレスになる。
この辺りはリーンスタートアップと通ずる部分が大いにある。
実装サイドの視点
実装に時間がかかっても、プロダクトマネージャーはその間に暇を持て余すわけではなく、新たなストラテジーを考える。そして、その結果ストラテジーと実装の乖離がさらに進んだり、実装中の機能の変更が増えたりすることがある。
実装サイドから見ると、リリース速度を上げることが重要になる。
そのために取り組むべき施策をいくつか挙げる。
CI/CDの整備
- リリースが自動化されていることが前提。手順が複雑だとリリース頻度が下がる。
- ロールバックが容易にできるようにしておけば、リリースに伴うリスクを下げられる。
テストドリブン
- 常にテストを書く。リリースを急ぐためにテストを書かずに実装を進めるのが愚かなことは、多くのエンジニアが経験しているはず。
- テストは動作の正しさを保証するだけでなく、開発時の実行環境としても有用。
- 手動でAPIやブラウザを操作するより、テスト実行で状態を確かめられるのは大きなメリット。
アーキテクチャ設計
- 最大の目的は「変更に強いソフトウェア設計」を目指すこと。それがストラテジーと実装の乖離を防ぐ。
- 「ビジネス的にはこうしたいが、既存の作りがそれを受け入れない」という状況は誰も幸せにならない。
- 最初から先を見越してある程度のレイヤーを設計し、依存方向のルールを決めておくことで、実装が進むにつれコード量が増えても、根本の設計自体が複雑化することを防げる。後から小手先でコードを細分化するよりはるかに効果的。
- ビジネスロジックとインフラストラクチャを分離することで、ビジネスロジックの記述を容易にし、機能変更にも強くなる。テストやリファクタリングもしやすい。
スキーマドリブン
- フロントエンドとバックエンドなど、技術スタックをまたぐ場合にスキーマを共通化すると、同時並行で開発でき、型安全性も高まる。
コード生成
- スキーマドリブンの発想をさらに進め、コンパイル時にエラーを検知可能な仕組みを整える。
- 具体例：
- APIスキーマをもとにTypeScript型定義を自動生成し、レスポンスを型安全に扱う。
- DBスキーマをもとにクエリビルダを生成し、SQLの記述ミスを減らす。
- i18nの設定をもとに翻訳関連コードを生成し、翻訳漏れや呼び出しミスを防ぐ。
- メール配信SaaSのテンプレート情報をAPIで取得し、型を生成して安全にメールの作成・送信を行う。
- 一端をここに書いた → 「実行時にファイルを読み込むのをやめる 」
ユビキタス言語
- エンジニアとプロダクトマネージャーが同じ用語を使うことで、誤解やすれ違いを最小限に抑える。
- この共通認識をまず持ち、お互いが積極的に統一された単語を使うことで、コミュニケーションコストを下げられる。
コードコメント
- コードの意図は積極的にコメントに残す。コメントが多くて困ることはそれほどない。
- 可能であればプログラミング言語のドキュメンテーションコメントを積極的に使う。
- 複雑な過程がある場合は別途マーメイド記法などで図を書いてgitにコミットするなりGitHub Wikiにまとめるなりして、コードとは別の形で説明を残す。
まとめ
プロダクトマネジメントは、リリースサイクルを短く保つために機能の輪を可能な限り小さく設計することが重要。そして、エンジニアリングは、短いサイクルでの開発・リリースを実現するために、テストやCI/CD、アーキテクチャ設計など、多角的な取り組みを継続的に行う必要がある。
「フィーチャーの輪」の肥大化に気をつけながら小刻みにリリースを行うことと、開発環境や実装面でリリース頻度を上げられる体制を整えることを両立させたい。