はじめに：「仕様書が来るのを待つ」開発の限界
「企画から仕様書が来るまで待っててね」
この一言で1週間が経過し、届いた仕様書を見ると「技術的に不可能」または「予算に見合わない」という事態、経験ありませんか？
SaaS開発において、エンジニアが「受け身」でいると、最適な解決策は生まれません。
企画側は技術的制約を知らないままアイデアを立案し、エンジニアは実装時に初めて「これは無理です」と伝える。結果、手戻りが発生し、リリースが遅延し、ビジネスチャンスを逃します。
本記事では、要件定義の段階からエンジニアが参画し、技術的な視点からビジネス価値を最大化する 「逆提案」の手法 と、Figma・Notionを活用した 「認識のすり合わせ」ドキュメント の作成方法を紹介します。
課題：「ふわっとした仕様」と実装時の衝突
導入前の典型的なフローは以下の通りでした。
このサイクルを象徴するのが、ある時の「カート機能のリニューアル」プロジェクトです。
企画書には 「カートに入れた商品を、他のユーザーとリアルタイムで共有できるようにしたい」 とさらっと記載されていました。
しかし、技術的にはWebSocketによる双方向通信が必要であり、既存のサーバーレス構成では月間コストが約50万円増加する見込みでした。
実装段階でこの問題を指摘した結果、企画側は「なぜもっと早く言わないのか」と不満を持ち、エンジニア側は「仕様書に書いていなかった」と言い訳に終始。関係性に亀裂が生じ、プロジェクトは3週間遅延しました。
解決策：「技術的伴走型」要件定義の3ステップ
「仕様を待つ」から「一緒に作る」へ、開発プロセスを根本から変更しました。
1. 企画立案時の「技術的伴走」（Upfront Engineering）
企画会議の最初からエンジニア（私）が同席し、技術的制約と可能性をリアルタイムで伝える体制を確立しました。
重要なのは「それは無理です」と否定することではなく、「こうすれば実現できます（松竹梅）」という代替案の提示です。
実際の事例：「リアルタイム在庫表示」機能
企画側の当初案:
「在庫数が変わるたびに、全ユーザーの画面を即座に更新したい」
私の逆提案:
| プラン | 技術構成 | 実装コスト | 運用コスト | UXへの影響 |
|---|---|---|---|---|
| ❌ 松 (当初案) | WebSocket (Pusher等) | 2週間 | +8万円/月 | 即時反映 |
| ✅ 竹 (推奨案) | 30秒ポーリング + SWR | 3日 | 0円/月 | 最大30秒遅延 |
| 🔺 梅 | リロード時のみ更新 | 1日 | 0円/月 | 手動更新 |
ビジネスインパクトの比較:
「0.5秒の遅延」と「最大30秒の遅延」がコンバージョン率に与える影響は、過去データから0.3%未満であると試算しました。一方でコストは年間96万円の削減になります。
この数字を提示した結果、企画側も「竹案（低コスト案）で十分」と即断。実装後、CPA（顧客獲得単価）を下げつつ、必要十分なUXを提供できました。
2. Figmaを使った「動く仕様書」作成
企画書と実装の齟齬を防ぐため、静的なドキュメントではなく「状態遷移」がわかるFigmaプロトタイプを必須化しました。
- 従来の仕様書: 「エラー時は適切に表示する」
- Figmaプロトタイプ:
- 在庫不足エラー: カートアイコンにバッジを表示、スクロールで該当商品まで自動移動
- 決済エラー: モーダル表示、3秒後に自動で入力フォームにフォーカス
さらに、エンジニアがFigmaのコメント機能で 「技術的フィードバック」 を直接入れます。
💬 エンジニアコメント:
「このアニメーションはCSSだけで実現可能なので工数は軽微です（2時間）」
「このデータは現在APIに存在しないため、バックエンド改修が必要です（+3日かかります）」
これにより、デザイン確定後の仕様変更が85%削減されました。
3. Notionによる「技術要件とビジネス要件のマトリクス」
「なぜこの機能が必要か」を開発中も見失わないため、二軸の要件マトリクスをNotionで管理しました。
| 機能要件 | ビジネス目的 | 技術的制約 | 優先度 | 代替案 |
|---|---|---|---|---|
| リアルタイム在庫 | 売り切れ防止 | WebSocket高コスト | P1 | 30秒ポーリング |
| 一括発注機能 | 作業効率化 | 最大100件制限 | P0 | ページネーション |
| 画像アップロード | 視認性向上 | ストレージコスト | P2 | 外部CDN利用 |
この表をスプリント計画時に全員で確認し、「技術的コストに対するビジネス価値」が見合わない場合は、早期にスコープアウト（機能削減）の判断を下せるようにしました。
成果：手戻り削減とリリース速度の向上
上記のプロセス変更を6ヶ月間運用した結果、以下の定量的な改善が見られました。
| 指標 | 改善前 (Before) | 改善後 (After) | 変化率 |
|---|---|---|---|
| 仕様変更による手戻り工数 | 週12時間 | 週2時間 | ⬇️ 83% |
| 企画→リリースまでのリードタイム | 平均4週間 | 平均2.1週間 | ⬇️ 48% |
| リリース後の仕様不備バグ | 3.2件/月 | 0.4件/月 | ⬇️ 88% |
| エンジニアからの要件提示率 | 5% | 35% | ⬆️ 7倍 |
特に効果的だったのは、「技術的伴走」による企画側の信頼獲得です。
当初は「エンジニアが企画に口出しするな」と警戒されていたものの、具体的なコスト削減案や迅速な代替案を3回連続で提示した結果、 「この機能、まずは@YushiYamamotoさんに相談してから決めよう」 という文化が形成されました。
具体的なドキュメントテンプレート
実際に使用している「技術要件ヒアリングシート」を共有します。ご自由にお使いください。
# 機能要件ヒアリングシート（Notionテンプレート）
## 1. ビジネス背景（必須）
- **解決したい課題:** [ユーザーが〇〇できずに離脱している]
- **成功指標（KPI）:** [カゴ落ち率を5%改善]
- **リリースデッドライン:** [202X/XX/XX]
## 2. 技術的制約チェック
- [ ] 既存DBスキーマの変更が必要？
- [ ] 外部API連携が必要？
- [ ] リアルタイム性が必要？（許容遅延: ___秒）
- [ ] モバイルアプリ対応が必要？
## 3. 代替案検討欄（エンジニア記入）
- **代替案A (High):** [WebSocket実装]（工数: 2週間, コスト: 高）
- **代替案B (Low):** [ポーリング実装]（工数: 3日, コスト: 低）
- **推奨案:** [B] （理由: KPIへの影響が軽微で、コストメリットが大きいため）
## 4. リスク評価
- **技術的リスク:** [アクセス集中時のDB負荷]
- **回避策:** [リードレプリカの参照]
まとめ：「エンジニア」という枠を超える価値創出
技術力だけでは解決できない、ビジネスと技術の断絶。この問題に対して、私が実践したのは以下の3つです。
- Upfront Engineering: 企画段階から技術的視点を投入し、代替案を提示する
- Visual Communication: Figma等の視覚的ツールで認識を同期する
- Transparent Documentation: Notionで技術的制約とビジネス価値を可視化する
これにより、エンジニアは「仕様を待つ受け身」から「価値を創る主体」へと変わり、技術的実現可能性とビジネスインパクトの最適解を追求できるようになりました。
「エンジニアとしての役割を超えて動く」とは、コードを書く範囲を超えて、プロダクトの価値を定義する段階から関与するということです。