チーム開発の認識ズレを入口で潰す。OpenSpec に「AI が先に質問する」工程を足して比べてみた - Qiita
はじめに こんにちは鷹野です。 私は4月から仕様駆動開発（SDD）を取り入れるための新チームにジョインしました。 Claude Code もその時から触り始めた初心者です。そんな中、約2ヶ月の仕様駆動開発を経験して感じたのは、1人でやるのとチームでやるのは全然違うということです。 1人で開発していたときは、前提が自分の頭の中で揃っているので、特に不満なく思いついた仕様をそのまま AI に渡してどんどん書かせることができました。ところがチームになると、メンバーや AI で「何を作るか」の認識が少しずつズレています。そのせいで、あとから「ここが足りない」「ここが認識と違う」「そもそもここは考えられていなかった」という抜けや食い違いが次々と出てきて、そのたびに手戻りすることが増えました。 そこで試したのが、OpenSpec と grill-with-docs という2つのツールの組み合わせです。
OpenSpec で始める仕様駆動開発
はじめに Claude Code や Cursor を使って開発していると、「曖昧な仕様のまま実装が進んでしまう」問題に直面することが多いです。 AI は与えられた指示に忠実に従います。しかし、指示自体が曖昧だと意図しない実装になりがちです。また、生成されたコードの仕様がどこにも残らず、後から「このコードは何をするものだったのか」わからなくなることもあります。 この課題へのアプローチとして OpenSpec を試してみました。仕様を明確にしてから実装に進むワークフローを提供するフレームワークで、AI と協働しながら仕様駆動開発を実現できそうです。 OpenSpec とは OpenSpec は、AI コーディングエージェントとの協働を前提とした仕様駆動開発フレームワークです。 主な特徴 軽量で、シンプルなワークフロー。最小限のセットアップで始められる 既存プロジェクトにも対応。新規開発（0→
OpenSpec — A lightweight spec‑driven framework
Each OpenSpec change produces a spec delta that captures the change in requirements of the system. This makes it easy for developers to understand how they're modifying the system and what will need to change. It also allows reviewers to understand the change itself without having to dig through the code and quickly gain a high level understanding.
仕様駆動を取り入れて4ヶ月ほど経ったので思うことなど
はじめに こんにちは。Dress Code 株式会社で、プロダクトエンジニアをやっている津田です。 仕様駆動開発を始めて 4 ヶ月ほど経過したので、改めて振り返ってみるべく記事に残してみています。 今回の対象読者は次に列挙するような方々を想定しています。 とりあえず試して実感してみたい人 プロセスが重そうで踏み出しきれない人 現場での工夫・実践知を知りたい人 本記事がこれらの方の一助になれば幸いです。 正直、仕様駆動開発自体の合う合わないは組織の規模やプロダクトの性質、開発スタイルに強く依存すると考えています。 参考程度に弊社の情報を軽くお伝えすると、次のようになっております。 創業から1年経過し、拡大を目指しているフェーズ toB向け、バックオフィスの業務改善のSaaSを展開 開発スタイルはアジャイルに近い 開発者は執筆時点で12名、組織全体で40名弱の規模感 少なくとも我々はこのような
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
