はじめに
こんにちは。Dress Code 株式会社で、プロダクトエンジニアをやっている津田です。
仕様駆動開発を始めて 4 ヶ月ほど経過したので、改めて振り返ってみるべく記事に残してみています。
今回の対象読者は次に列挙するような方々を想定しています。
- とりあえず試して実感してみたい人
- プロセスが重そうで踏み出しきれない人
- 現場での工夫・実践知を知りたい人
本記事がこれらの方の一助になれば幸いです。
正直、仕様駆動開発自体の合う合わないは組織の規模やプロダクトの性質、開発スタイルに強く依存すると考えています。
参考程度に弊社の情報を軽くお伝えすると、次のようになっております。
- 創業から1年経過し、拡大を目指しているフェーズ
- toB向け、バックオフィスの業務改善のSaaSを展開
- 開発スタイルはアジャイルに近い
- 開発者は執筆時点で12名、組織全体で40名弱の規模感
少なくとも我々はこのような状態で始めてそれなりに使えているな、というステータスです。
事業の成長とともに仕様駆動開発の位置付けがどう変わっていくのかも楽しみですね。
なお、仕様駆動開発がなんであるか、についてはすでに語られ尽くしているので本記事では割愛します。
結論
個人的に始めた仕様駆動開発でしたが、大小合わせて 43 件の仕様変更が行われたようです。
コミット履歴を見るに、開発者 12 人中 9 人が仕様駆動開発を用いたコミットをしているようです。
特に組織・チームで使っていく方針を明確に打ち出したわけでもなく自然と使い始めているため、何らか試す動機があると判断できそうです。
また、個人的な感想を述べると、次のようにまとめられそうでした。
- 生の仕様駆動開発のツールだけだと物足りなさは出るのでカスタマイズは必要
- 開発全体のプロセスが楽になった実感はないが、以下のような恩恵は受けられている
- コーディングにおいて非決定的なAIの出力への依存度は相対的に下げられた
- 特に共通基盤の開発において、仕様・想定が残っている事実は心強い
- 実装着手あるいは動くものを見るまでのリードタイムは伸びるので、成果が出ていない時期に焦りがある
以下、時系列とともにやったことや振り返りを記述します。
導入期
まず、ツールは OpenSpec を採用しました。
そもそもの仕様駆動開発におけるフェーズは 3 つある、とされています。
記事によると、以下のフェーズで定義されています。
- Spec-first: 仕様を作成し、それを元にAIの支援を受けた開発フローを進める
- Spec-anchored: タスク完了後も仕様を保持し、機能改善・保守に活用
- Spec-as-source: 仕様書＝ソースで、原則人間がソースを触らない
toB向けのSaaSを作るとなると、設定で顧客の要求を満たすことが多く、仕様を保持し続けることに価値があると判断をしております。
つまり、 Spec-anchored が望ましい、と判断をしています。
また、Brownfield で段階的な採用が可能なツールが当時調査した範囲だとあまり見つけられず、OpenSpecの採用を決めました。
以下の画像は当時のADRのインフォグラフィックです
Brownfield の良いところは自分の担当領域でのみ利用を開始できる点にあります。
しれっと openspec init を実行し、commandsやskillsを用意し、既存のソースコードをベースに仕様書を書かせてあげれば使い始められます。
実際に私も基盤実装における仕様がコードに埋もれていくことに危機感を覚え、仕様駆動開発を一人で始めました。
ここから合う・合わないを個人的に見ていくことがファーストステップとして大事になりそうです。
試運転期
OpenSpec はさまざまなツールを提供してくれていますが、現時点の実装だと少しだけ複雑度が高くなっています。
導入を決めた当初は v1 が出ていない時期だったので、 /openspec-proposal -> /openspec-apply -> /openspec-archive のフローだけを気にすれば開発は完結していました。
v1 になってからは複雑なワークフローにも耐えられるように細分化され、
スキルも提供されているので文脈に応じて適切に使うツールを判断してくれるようにはなっています。
基本的な流れは、以下のようにステップごとに人間の判断が介在する余地が設けられました。
- proposalの作成 -> レビュー
- specsの作成 -> レビュー
- designの作成 -> レビュー
- tasksの作成 -> レビュー
これによって今まで以上にウォーターフォールみが増しましたが、明らかに実装時の精度が上がった感覚があります。
spec を書くときはモデルの性能に強く依存するので、ある程度のたたきを人間が書いて、Opusなどの推論に強いモデルと壁打ちをしながら仕様を詰めていくのが良いと思われます。
その取り組みにおいても後述するようなツールの準備・支援を並行で動かしておくと効果的に運用できます。
拡張期
設計をOpenSpecのワークフローに当てはめて実装を始めるといくつか痒い所に手が届かないケースが発生します。
例えば・・・
- OpenSpecが出してくる仕様は人間の認知負荷が高い構造で作られる
- GIVEN / WHEN / THEN で構造的に記載されているとは言え、AIが出力した文章では目が滑る
- 第三者がレビューする場面でざっくり意図を把握したいときに長ったらしい文章を読むのはなかなか時間が惜しい。
- AI が仕様の文章を生成するので、会話を重ねるとドキュメント間に矛盾が生じるケースがある
我々はこれらの課題に対してカスタムコマンドを定義することで対応をしました。一例となりますが、、、
-
/openspec-pr-summary: PRレビューしてくれる人のための要約を生成する -
/openspec-info-graphic: 指定した changes からインフォグラフィックを作成するプロンプトを生成する -
/openspec-review: 文書間の整合性チェック・非機能要件の観点にフォーカスを当ててセルフレビュー
これらのカスタムコマンドは直接的に上述した課題をクリアするだけでなく、
我々の Any Decision Record として雑多に決定事項を溜め込む文化とも相性が良かったです。
※Any Decision Record については次のSpeaker Deckをご参照ください
仕様駆動で検討した内容も決定の一種なので、ADR として同じストックに乗せたくなります。
カスタムコマンドによる要約・インフォグラフィックは、人間が読みやすい形に加工するための土台を作る一助となり、認知コストの抑制にも効いています。
人間のための翻訳のプロセスを省くと、リポジトリには仕様があるのにレビューや引き継ぎでは参照されず、事実上使われない状態になりやすい、と捉えています。
今後に向けて
toB向けのプロダクトを作るときに避けられないのが、顧客独自の運用をプロダクト内に取り込んだり、当時の法対応など、意図が陳腐化しがちな意思決定です。
仕様駆動開発を軸に据えられると、当時の意図・背景を仕様とADRの両軸でドキュメントに残せるようになることを期待しています。
特に OpenSpec は changes を時系列で溜め込むことができるし、断面の仕様も別途有していることから、
リリースノートと紐づけて当時どう動作したのか、どういう意図で修正を入れたのかをより明確にすることができると考えています。
全てのPRに仕様を紐づけるのはコストが重くて流石にやりたいとは思いませんが、意図が重要になる変更や領域は積極的に仕様駆動で開発できたら良いかな、と感じています。
また、徐々に作成した仕様を活用する場面も増やせており、今では一部の機能開発において PdM /QA が OpenSpec の仕様をレビューしたり、それを元にテストケースを作る活動が始まっています。
これらの活動を加速して、シフトレフトしていけると生産性を高めつつ、運用負荷も抑えられるようになるのではないかと期待しています。
最後に
色々取り組みを時系列で書いてみましたがここまで使ってみての感想・意見を改めて書いてみます。
総じて言えることは、開発のスタイルによって仕様駆動開発の評価はかなり変わるだろうな、という点です。
個人の感想・妄想にすぎませんが、以下のように組織規模や開発スタイルによる向き不向きがありそうです。
ウォーターフォールで仕様をガチガチに固めるところはそもそもあまり恩恵は受けられないと思っています。転記するだけコストが無駄ですからね。
走りながら考える組織においては有用なケースが多いであろうと推測できます。だいたいにおいて価値が先導してて「何を」「どう作るか」が未確定なケースが多いので。
少人数しか触らない小規模なプロダクトにおいては無用の長物になる可能性が高いです。属人化させて成長速度を加速させる必要性が高いことと、「話せば分かる」ことが多いので。
我々は実装したい「価値」はあるが、具体的に「何を」「どう作るか」は未確定で、走りながら考えることが非常に多いためそれなりにハマっていると思えます。
特に開発フェーズの「何を」「なぜ作るのか」の要件整理については、言語化の必要性が非常に高いので今まで以上に解像度が高まっていると認識しています。
プロセスは重くなりましたが、価値を満たすための路面状況が整うような感覚があります。
AI エージェントと中心に据える開発手法、今までだと舗装されていない道を歩くような感覚で、走っていてつまずくことが多かったですが、それがだいぶ減った印象です。
まだまだ使い始めて間もないですが、今後も活用してみようかなぁと考えています！
Discussion