iOSチームの開発フローにSDDを導入してみた

はじめに

iOSの開発のワークフローにSDD (Spec Driven Development) を取り入れたので、どのように導入したか、実際に入れてみてどうだったか、どんなメリット・デメリットがあったかをまとめてみました。

SDDを導入する以前はどのような開発フローだったか

仕様や設計を一つのファイルにまとめて、プルリクエストでレビューをし、レビューが通ったら、実装に入るというフローでした。課題として、特に決まったフォーマットがあったわけではなかったので、エンジニアによって、仕様や設計の書き方が異なっていました。

SDDをどのように導入したか

cc-sdd のコマンド設計とプロンプトを参考に、自チーム用にカスタマイズして導入しました。 変更点は次の3つです。

• cc-sddではsteeringでプロダクト概要や使用技術を記載したドキュメントを生成されますが、私たちのチームでは、Developer Guidelineのドキュメントをリポジトリ内に用意していたので、コマンド内でそのドキュメントを参照するように指示しました。
• cc-sddではspec-initコマンドで仕様書作成をスタートしますが、私たちのチームでは、フロントエンド共通(Web / Android / iOS)の仕様書を別途で作成しています。なので、仕様書作成のコマンドの引数で、仕様書を渡すことで、AIにどのような実装をしたいかを伝えて、リポジトリ内部でSDD専用の仕様書ドキュメントを生成するようにしました。
• 設計段階では、私たちのプロダクト特有のルールがDeveloper Guidelineに記載されているので、それを読み込ませて、設計ドキュメントを生成させるようにしています。

どんな時にSDDを利用したか

新規機能追加や機能改善タスクの施策でSDDを利用しました。OSアップデートやリファクタなどのiOSチーム特有の改善タスクでは利用していません。 効果を机上で判断しきれないため、小規模施策3件で実際に運用してみました。

SDDを導入してよかったこと

• 仕様書・設計書・tasksの3つに分けたことで、設計レビューで重点的に見るファイルを絞れるようになりました。私たちのチームでは設計書を中心にレビューし、仕様が気になれば仕様書を参照する形にしています。
• 設計書の各項目に「対応する仕様」を記載するルールにしたことで、完全にとは言えないものの設計漏れが減ったと感じています。

SDDを導入して残った課題

仕様ドキュメント作成 → 設計ドキュメント作成 → tasks作成 のフローだと、ウォーターフォール型の開発フローに近づきます。実装に入る前に仕様に修正が入ると、合わせて設計ドキュメントやtasksに修正も入れる必要がある手戻りが発生してしまいます。なので更新コマンドを作成して仕様書が更新されたら設計書やtasksも更新されるような仕組みを作る必要があると考えています。 また大規模な施策でSDDを利用するのは、難しいと感じています。理由は2点あります。

1つ目は、大規模施策の仕様書や設計書を1つにまとめてしまうと、人がレビューする際に読むのが大変なことです。

2つ目は、私たちのチームでは設計から実装までを同じエンジニアが担うことを大事にしており、SDDのドキュメントを一人が作成し、別のエンジニアが手分けして実装するフローが、チームの開発スタイルと合わないことです。

大規模施策で効率よくSDDを利用するには、共通で実装すべき箇所を先に片付けたうえで、残りを各エンジニアが独立したSDDワークフロー（仕様書 → 設計 → 実装）で進められるようスコープ分割するコマンドが必要だと考えています。

おわりに

iOSチームでSDDを小規模施策3件に導入してみた結果、設計レビューで見るべき箇所が絞れる・設計漏れが減るといった効果を感じられました。一方で、仕様変更時の手戻りや、大規模施策とチームの開発スタイルとの相性という課題も残っています。

今後は仕様書の更新が設計書・tasksに伝播する更新コマンドや、大規模施策をスコープ分割するコマンドを整備していきたいと考えています。SDDの導入を検討している方の参考になれば幸いです。