はじめに
こんにちは、開発1部で食事管理アプリ「ヘルシカ」の開発をしている新谷です。
社内でAIツールを使って開発を進める中で、個々のタスクは確実に速くなっているものの、開発フロー全体としてはまだ思ったほど生産性が上がっていないと感じています。この記事では、その原因を分析し、「エンジニアが仕様書を主導して書く」という開発フローの改善に取り組んだ話を紹介します。
現状の開発フローと課題
これまでの開発フロー
ヘルシカチームでは、以下のような流れでプロダクト開発を行っています。
施策立案 → 認識合わせ → デザイン作成 → 設計 → 実装 → コードレビュー → QA → リリース
認識合わせのために、PdMがPRD（Product Requirements Document）を作成しています。PRDの構成は大まかに以下のような形です。
## 背景・目的・仮説 なぜこの施策をやるのか（Why） ## 分析・検証 確認したい指標（定量面） ## 要件・仕様 ユーザーは〇〇にアップロードした画像を保存できる（What）
このPRDには、WhyとWhatが書かれています。これをもとにチーム全員で認識を合わせ、担当のエンジニアがシステム設計（How）を作成して実装に入ります。
タスク規模によるボトルネックの違い
AIツールの導入によって、小さなタスクでは設計・実装がボトルネックになりにくくなりました。むしろ認識合わせやコードレビューの方が相対的にボトルネックになってきています。
しかし、中規模〜大規模なタスクでは、依然として設計・実装がボトルネックです。具体的には以下の2つの課題があります。
- 設計の課題
- PRDの仕様からシステム設計に落とすのに時間がかかる
- 仕様の考慮漏れや認識齟齬が設計段階で発覚し、手戻りが発生する
- 実装の課題
- AIが生成したコードの確認・修正に時間がかかる
課題の深掘り
実装の課題について掘り下げると、AIが期待通りのコードを出せない原因の多くは、設計書（= AIへのプロンプト）の不備に行き着きます。
もちろん、AIが力を発揮するための環境整備（リンターや自動テストの整備、ルールファイルの充実、既存コードの品質改善など）も大切です。しかし、これらを整えたとしても、不備のある設計書を渡せば不備のある実装が出てきます。
つまり、設計フェーズで短時間かつ考慮漏れのない設計を作れるかが、AI時代の開発生産性を左右するポイントだと考えました。
では、設計の課題をもう少し細かく見てみます。
- 設計に時間がかかる：技術的知識やドメイン知識に基づく設計力・スピードに依存する
- 手戻りが発生する：PRDの仕様に考慮漏れがあり、設計や実装の段階で初めて問題が発覚する
この2つの課題を解決するために、「エンジニアがPRDの仕様（What）を主導して作成する」というアプローチを考えました。
エンジニアが仕様を主導する
なぜエンジニアが仕様を書くのか
エンジニアは実際のコードベースを理解しています。そのため、仕様を考える段階で「この機能を実現するには、既存の〇〇の処理にも影響がある」「この条件分岐は仕様として明確にしておく必要がある」といった技術的な観点を織り込めます。
これにより、仕様段階での考慮漏れが減り、後続のシステム設計で大きな手戻りが発生しにくくなります。結果として、設計にかかる時間も短縮されます。
また、エンジニアが仕様を引き受けることで、PdMはマーケティングや数値分析など、本来注力すべき領域により多くの時間を使えるようになるのではないかと考えています。
AI時代ならではのメリット
さらに、AI時代ならではのメリットもあります。エンジニアが仕様書を作ることで、「どういう仕様書を書けば、後段のシステム設計書を楽に作れるか」「どういう粒度で書けば、AIで設計書の生成を自動化できるか」といったPDCAを回しやすくなります。
仕様書のフォーマット自体を改善していくことで、仕様書→システム設計書→実装の一連の流れを最適化できる可能性があります。
AI-DLCとの共通点
この考え方は、AWSが提唱しているAI-DLC（AI-Driven Development Life Cycle）のINCEPTION PHASE（AIと要件を深掘りして決めていくフェーズ）に通じるものがあります。AI-DLCでは、最初のフェーズでPdM・デザイナー・エンジニアが一緒に要件を詰めていくことを推奨しており、今回の取り組みと方向性が近いと感じています。弊社でも別チームがAI-DLCを試した事例があるので、興味のある方はこちらの記事もご覧ください。
難しい点
一方で、エンジニアが仕様作成を主導するには、PdMと同じくらいの解像度でビジネスや数値を理解する必要があります。これは簡単ではありません。
しかし、AIによって職種間のオーバーラップが進む中、エンジニアにもビジネス理解が強く求められるようになっていくと考えています。仕様を主導することは、エンジニアのスキルセットを広げる機会にもなるのではないかと思っています。
新しい開発フロー
最終的に、以下のフローに変更しました。
- PdMがPRDのWhy（背景・目的・仮説）を作成
- PdM・デザイナー・エンジニアで認識合わせ → エンジニアが主導してWhat（仕様）を詰める
- エンジニアが仕様書を作成
- 仕様書のレビュー
- エンジニアがシステム設計書（How）を作成
- 実装
これまでシステム設計書はドキュメントとして残すことを必須としていませんでしたが、仕様書→システム設計書の変換をAIで自動化するPDCAを回すために、今回から残すことを必須としました。
実際の成果物の例
具体例として、「プレミアム機能無料開放」施策での成果物の一部を紹介します。
まず、PdMが作成したPRDの一部です。施策の背景・目的・仮説が記載されています。
## 概要 新規ユーザーに対し、プレミアム機能を一定期間無料開放することで、 アプリの価値を早期に体験してもらう。 ## 仮説 新規ユーザーはプレミアム機能がロックされているため、 アプリの価値を体験できず、継続利用につながっていない。
次に、エンジニアが作成した仕様書の一部です。PdMとの認識合わせを経て、具体的な仕様に落とし込んでいます。
## 無料開放期間 - 期間: 初回ホーム到達からx日間 ## 機能要件 ### プレミアム機能の無料開放 - 無料開放期間中、全ユーザーがプレミアム機能を利用できるようにする ### バナー表示（ホーム画面） - 対象: 非プレミアムユーザーのみ - 無料開放期間中: 無料開放中であることを示すバナーを表示 - 無料開放期間終了後: 終了のアナウンスに切り替え
そして、この仕様書をもとに作成したシステム設計書の一部です。
## 設計方針 ### 意味の分離 フリーミアム導入により、「課金しているか」と「プレミアム機能を使えるか」の 意味が同じではなくなるので、コード内でこれらを分離する。 | プロパティ | 意味 | 用途 | | isPremium | 実際に課金しているか | ログ送信パラメータ | | freemiumLastDateTime | フリーミアム期間終了日時 | バナー表示 | | hasFullAccess | プレミアム機能を使えるか | UI表示・遷移制御 |
試してみての所感
この取り組みはまだ実験段階で、試し始めて2週間ほどです。
よかった点
- エンジニアがWhatの段階から積極的に介入できる構造になった
- 仕様書→システム設計書→実装の流れで、エンジニア同士の議論が増えた
- システム設計書に着手する段階で、大きな手戻りは発生していない
課題
- タスクの並列度が上がり、頭の切り替えコストが高い
- これまでは「実装」と「認識合わせMTG・コードレビュー」の並行だったが、そこに「次のタスクの仕様書作成」が加わる
- 実装中のタスクと仕様を書くタスクはまったく別の内容なので、コンテキストスイッチが頻繁に発生する
- 仕様書にどこまで書くべきかの基準がまだ定まっていない
- どの粒度で書けば後段のシステム設計書や実装がAIで精度よく出てくるのか、引き続き検証が必要
- 正直なところ、現時点では開発速度が上がったという実感はまだない
- ただし、仕様書・設計書をドキュメントとして残す運用にしたことで、「何を書けばAIの出力精度が上がるか」を振り返れる状態にはなった。この改善サイクルを回していくことに意味があると考えている
まとめ
AIツールによって個々のタスクの開発速度は向上していますが、中規模以上のタスクでは設計・実装がボトルネックになっています。この課題に対して、エンジニアがPRDの仕様（What）を主導して書くというアプローチを導入しました。
まだ試し始めたばかりで、タスク並列度の増加や仕様書の粒度の最適化など、新たな課題も見えてきています。
今後は仕様書のフォーマットを改善しながら、仕様書→システム設計書のAI自動生成についてもPDCAを回していきたいと思います。
