こんにちは！タイミーでバックエンドエンジニアとして働いている福井 ( bary822 ) です。 皆さんは「Claude Code の Skills を社内の Cursor ユーザーも使えるようにしたい」と思ったことはないでしょうか？ Claude Code には Claude Plugin という仕組みがあり、社内で共有したい Skills を簡単に配布できます。しかし、Cursor には Claude Plugin に相当する機能がなく、さらに Claude Code の Skills は独自の構文をサポートしているため、そのままでは動作しません。 この記事では、Claude Plugin 形式で配布している Skills を Cursor でも利用できるようにした取り組みについてご紹介します。 背景 タイミーでは、社内の開発ガイドラインに沿った開発を行いやすくすることを目的に、Claude Code の Skills を整備し、Claude Plugin 経由で配布しています。 tech.timee.co.jp Claude Code の Skills はエージェントに対してタスク実行時のコンテキストや手順を提供する機能です。この機能はもともと Claude Code 独自のものでしたが、現在では Agent Skills としてファイル名やディレクトリ構成、メタデータの種類などのオープンスタンダードが確立されつつあり、さまざまなAIプラットフォームで再利用できるようになっています。 Skills for organizations, partners, the ecosystem | Claude Overview - Agent Skills 課題: Claude Plugin で配布している Skills を Cursor で使えない Agent Skills の仕様自体は標準化が進んでいますが、配布の仕組みやサポートされる構文にはプラットフォーム間で差分があります。 配布の仕組みの差分 Claude Code には Plugin という仕組みがあり、Skills のインストール・アップデートを簡単に行えます。一方、Cursor には同等の配布機構がサポートされていません。 構文の差分 Claude Code の Skills には、Cursor でサポートされていない独自構文がいくつかあります。 !command 構文: SKILL.md 内で許可されたシェルコマンドを実行する構文。たとえば !gh api ... と書くことで GitHub API 経由でドキュメントを動的に取得できる。Cursor ではサポートされていない $ARGUMENTS 変数: スキル実行時にユーザーが渡す引数を受け取るための変数。こちらもCursor ではサポートされていない つまり、Claude Plugin で配布している Skills をそのまま Cursor に持ってきても、動的なコンテンツ取得ができず引数も渡せないため、まともに動作しない状態でした。 Cursor ユーザーにも同じ体験を提供するために、これらの構文を Cursor が理解できる形式に変換し、適切なディレクトリに配置する必要がありました。 解決策：変換スクリプトの作成 Claude Plugin 形式の Skills を Cursor 互換形式に変換するシェルスクリプト build-cursor-skills.sh を作成しました。 このスクリプトは以下の変換を行います。 動的コンテンツの埋め込み: !command 構文で動的に取得していたコンテンツを、ローカルのファイルから読み取ってテキストとして直接 SKILL.md に埋め込む 変数の変換: $ARGUMENTS を「ユーザーの指示に従って」という固定テキストに置換する 補助ファイルのコピー: Skills が参照する補助ファイル（ intro.md , workflow.md , troubleshooting.md など）もコピーする 変換後の Skills を構成する各種ファイルは、ユーザー領域( ~/.cursor/skills/ )に配置されるようにしました。Cursor はこのディレクトリを自動的に走査するため、配置するだけで Skills が利用可能になります。 # Skills を管理するリポジトリで実行するだけ ./scripts/build-cursor-skills.sh 変換処理の具体例 たとえばある Claude Code Skill の SKILL.md には、以下のように GitHub API 経由でドキュメントを動的に取得する構文が含まれています。 # API設計ガイドライン 以下のガイドラインに従って API を設計してください。 ! ` gh api /repos/org/repo/contents/docs/web_api_design.md ... ` 変換スクリプトはドキュメントを管理するリポジトリ上に配置します。こうすることで、この !gh の行をローカルにあるドキュメントの内容で置き換えることができます。 # API設計ガイドライン 以下のガイドラインに従って API を設計してください。 （ローカル参照した web _ api _ design.md の内容がここに展開される） これにより、GitHub API を呼び出さなくてもドキュメントの全文がスキルに含まれるようになり、Cursor でも問題なく動作します。 動的に取得する Claude Code 形式と比較すると、ドキュメントに変更があるたびにスクリプトの再実行が必要になります。この点に関しては Claude Plugin を使っていたとしても手動でアップデート( claude plugin update <plugin> )する必要があるため、大きな差はないだろうと判断して許容しました。 出力されるディレクトリ構造 スクリプトを実行するとユーザー領域に下記のようなディレクトリ構成でファイルが展開されます。 ~/.cursor/skills/ ├── skill-ref-design-api/ │ └── SKILL.md # ドキュメントが埋め込まれたスキル ├── skill-ref-design-table/ │ └── SKILL.md ├── skill-wf-design/ │ ├── SKILL.md │ ├── intro.md │ ├── workflow.md │ ├── troubleshooting.md │ └── samples/ │ └── default.md ... Dev Container 環境への対応 変換スクリプトをリリースした後、Cursor で Dev Container を使って開発しているメンバーから「スキルが認識されない」という報告がありました。 原因はシンプルで、Dev Container 内からはホスト側の ~/.cursor/skills/ が参照できないためです。 これを解決するためにいくつかの方法を検討しました。 方法 メリット デメリット devcontainer.json で ~/.cursor をマウント 設定一箇所で済む Cursor を使っていない人のホストにも ~/.cursor/ が作成されてしまう ワークスペース直下に配置 マウント不要（ワークスペースはデフォルトでマウント済み） gitignore の設定が必要 チーム内には Cursor を使っていないメンバーもいるため、 devcontainer.json にマウント設定を追加する方法は副作用が大きいと判断し、ワークスペース直下に配置する方法を選択しました。 具体的には、変換スクリプトに --target オプションを追加し、出力先ディレクトリを指定できるようにしました。 # Dev Container 環境向け：ワークスペース直下に配置 ./scripts/build-cursor-skills.sh --target /path/to/repo これにより、スキルファイルはワークスペース直下( <repo>/.cursor/skills/ )に配置されます。ワークスペースはデフォルトで Dev Container にマウントされているため、追加のマウント設定なしでスキルが認識されます。 ただし、ドキュメントが更新されてスクリプトを再実行すると、そのたびに更新された Skills を構成するファイルに差分が出てしまいます。そこで、利用する側のリポジトリでスクリプトによって配置されるディレクトリ以下を gitignore する対応も合わせて行いました。 今後の展望 現在はビルドスクリプトを手動で実行する必要がありますが、Cursor 側で Claude Plugin と同等の配布機構や !command 構文がサポートされれば、変換スクリプト自体が不要になる可能性もあります。その動向もウォッチしつつ、現時点で最もシンプルに課題を解決できる方法として、この変換スクリプトによるアプローチを採用しています。 また、元のドキュメントに更新が入った時に手元の Skills をアップデートすることを促す通知を送信するなど、ユーザーの利便性に配慮した仕組みづくりも進めていきます。 おわりに 今回は、Claude Plugin 形式で配布している Agent Skills を Cursor でも利用できるようにした取り組みをご紹介しました。 「Claude Code で便利に使っている Skills を他のツールでも使いたい、でもプラットフォームごとに構文や配布の仕組みが違って大変」というのは、多くのチームが直面しうる課題だと思います。私たちのアプローチはシンプルなシェルスクリプトによる変換という泥臭い方法ですが、低コストで確実に課題を解決できました。少なくとも今後 Agent Skills の配布の仕組みが Cursor に搭載されるまでの暫定対応としては十分に機能していると思っています。 この記事が、同じような課題に取り組む方の参考になれば幸いです。 最後までお読みいただき、ありがとうございました！

こんにちは、タイミーでバックエンドのテックリードをしている新谷（ @euglena1215 ）です。 今回は、社内向けに公開したバックエンド開発Handbookと、それをClaude CodeやCursorといったAIエージェント向けスキルとして届けることで、気づいたらHandbookを参照している状態を目指した取り組みについて紹介します。 バックエンド開発Handbookとは何か バックエンド開発Handbookは、タイミーのバックエンド開発における設計・実装・運用のガイドラインをまとめたドキュメント集です。GitHub Pages でホスティングし、開発者が見やすい形で公開しています。 タイミーでは GitHub Enterprise Cloud を利用しているため、GitHub Pages のアクセス制御機能でリポジトリの読み取り権限を持つメンバーのみに公開範囲を制限できます。 バックエンド開発トップページ なぜ書き始めたのか 事業の成長・変化に伴い、バックエンド開発に関わるエンジニアが増えてきました。AIツールの進化も相まって、バックエンド以外を専門とするエンジニアが越境してコードを書く機会も増えています。 こうした変化の中で、これまでチーム内で暗黙的に共有されてきたノウハウや設計思想を形式知として残し、誰でもアクセスできる状態にしておく必要がありました。 たとえば戦略的プログラミングの重要性、概念モデリングの進め方、テーブル設計の注意点など、日々の開発で繰り返し必要になる判断基準を体系化しています。 カバー範囲 Handbookは開発プロセスの全体を一気通貫でカバーしています。 フェーズ トピック はじめに 戦略的プログラミングの心構え、秘匿情報の取り扱い、タイミーを取り巻く法律 設計 概念モデリング、ギャップ分析、テーブル設計、Web API設計、クラス設計、非同期処理設計、バッチ処理設計 実装・レビュー 実装ガイドライン、コードレビュー、自動テスト設計、コードの整頓 運用・保守 ログ設計、監視、障害対応 リリース デプロイ・リリース 設計に重点を置いているのは、バックエンド開発に慣れていない人がAIエージェントを使ったとしても、カバーしにくい領域だからです。実装やレビューのプラクティスはある程度一般化されていますが、「タイミーのバックエンドとしてどう設計するか」はチーム固有の知見が多く、形式知にする価値が高いと考えました。 たとえばタイミーでは、Sidekiq ジョブ実行中にデプロイが行われると、Sidekiq プロセスに SIGTERM が送信されます。その25秒後にたとえ実行途中であってもジョブをキューに戻す、という実装上の制約があります。開発者はこれを考慮してジョブの処理をべき等にしたり、25秒を超えないように処理対象を分割してジョブに切り出すなどの対策を行う必要があります。このような暗黙的かつ独自の制約は特に Handbook として残すべきだろうと考えていました。 Handbookをどう届けるか Handbookを書いて公開するだけでも価値はありますが、ドキュメントは自分から読みに行く必要があり、ひと手間かかります。存在を知っていても、忙しい開発中には思い出せないこともあると思います。 いま、社内の多くのエンジニアがAIエージェントを日常的に使って開発しています。Claude CodeやCursorなどのツールが開発フローに組み込まれているのであれば、 AIエージェント経由でガイドラインを届ける という選択肢があります。 開発者が意識しなくても、AIエージェントがガイドラインを参照しながら設計や実装を支援してくれる。そうすれば、「気づいたらガイドラインに沿った開発をしていた」という状態を作れます。 この考えから、Handbook公開と同時にAIエージェント向けスキルとしても提供することにしました。現在、Claude Code Plugin と Cursor Agent Skills の2つの形式で配布しています。 ここからは、AIエージェント向けスキルの技術的な仕組みと、人間側の学びを促す工夫の2つの観点で説明します。 スキルの技術設計 リポジトリ構成 1つの工夫として、Handbookのマークダウンドキュメントとスキル定義を同じリポジトリに同居させています。 handbook/ ├── backend/ # Handbookドキュメント（マークダウン） │ ├── design/ │ │ ├── web_api_design.md │ │ ├── table_design.md │ │ └── ... │ ├── implementation/ │ └── operation/ ├── .claude-plugin/ # AIエージェント向けスキル定義 │ └── timee-backend-handbook/ │ ├── plugin.json │ └── skills/ │ ├── ref-design-api/ │ ├── wf-code-reading/ │ └── ... └── scripts/ └── build-cursor-skills.sh # Cursor向け変換スクリプト ガイドラインの原文とスキル定義が同じリポジトリにあるため、ドキュメントの更新とスキルの更新を同じPRで行えます。ドキュメントとスキルが乖離するリスクを構造的に減らせます。 Reference SkillsとWorkflow Skills Handbookの内容を、AIエージェントのスラッシュコマンドで呼び出せるSkillsとして提供しています。今回、スキルの役割に応じて Reference Skills と Workflow Skills という2種類の分類を独自に定義しました。これはClaude CodeやCursorの公式な分類ではなく、Handbookスキル群の設計方針として導入した概念です。 Workflow Skill（高レベル） ├── Reference Skill A を呼び出し ├── Reference Skill B を呼び出し └── Reference Skill N を呼び出し（必要に応じて） Reference Skills Reference SkillsはHandbookの各ページと1対1で対応します。 /handbook-ref-design-api # Web API設計 /handbook-ref-design-table # テーブル設計 /handbook-ref-design-class # クラス設計 /handbook-ref-impl-code-review # コードレビュー ... たとえばAPI設計のReference Skillsは以下のように定義されています。 --- name: handbook-ref-design-api description: Web API設計のガイドラインを参照してエンドポイント設計をレビュー・提案 context: fork agent: general-purpose allowed-tools: Bash(gh *) --- ## Web API設計ガイドライン !`gh api /repos/my-org/handbook/contents/backend/design/web_api_design.md -H "Accept: application/vnd.github.raw"` ## タスク 上記のガイドラインに従って、$ARGUMENTS のWeb API設計をレビュー・提案してください。 ポイントは context: fork です。サブエージェントとして独立したセッションで実行されるため、メインセッションのコンテキストウィンドウを消費しません。情報量の多いHandbookの取得をサブエージェントに委譲し、要約のみを返すことで効率的に運用できます。 また、 gh api -H "Accept: application/vnd.github.raw" でマークダウンの原文をそのまま取得できます。Handbookが更新されれば自動的に最新の内容が反映されます。 Workflow Skills Workflow Skillsは、状況に応じて複数のReference Skillsを組み合わせるユースケース特化型のスキルです。 context: current でメインセッション上で実行されます。 現在はWorkflow Skillsを4つ提供しています。 スキル フェーズ 内容 /handbook-wf-code-reading 理解 既存機能を体系的に理解する /handbook-wf-modeling モデリング 概念モデリングを実施する /handbook-wf-plan 計画 開発中: 詳細設計を行いつつ、複数個の実装計画に落とし込む /handbook-wf-implement 実装 開発中: 与えられた入力を元に実装する たとえばモデリングフェーズのWorkflow Skillsを実行すると、以下のような流れで進みます。 イントロダクション : 概念モデリングの重要性とギャップ分析の考え方を説明 ガイドライン取得 : 必要なReference Skills（概念モデリング、ギャップ分析など）を自動で選択・呼び出し 意図の深掘りと目標の合意 : 何をモデリングしたいのか、スコープを確認 すり合わせの質問 : ドメインの境界やビジネスルールについて質問を提示 メインセッションでモデリング実行 : 回答を踏まえて一緒にモデリングを進める 開発者はスラッシュコマンドを1つ実行するだけで、必要なガイドラインの参照からモデリング作業までを一気通貫で進められます。ガイドラインの存在を知らなくても、Workflow Skillsが自動的に適用してくれます。 階層構造のメリット Reference SkillsとWorkflow Skillsの2層構造には、以下のメリットがあります。 再利用性: 同じReference Skills（たとえばギャップ分析）が理解・モデリング・設計の各Workflowから呼ばれる 動的選択: Workflow Skillsがユーザーの入力や状況に応じて、必要なReference Skillsだけを選択的に呼び出す コンテキスト効率: ガイドラインの取得処理はサブエージェントに委譲され、メインセッションには要約のみが返る また、Workflow Skillsは自作も可能です。既存のWorkflow Skillsを参考にしながら、チームの開発フローに合わせたワークフローを追加していけます。こうしたスキルが充実すれば、どのタスクに取り組むときでもHandbookの知見にガイドされる状態が作れます。新しくチームに加わった開発者でも、スキルを通じてすぐにチーム固有の設計方針をキャッチアップできるはずです。 人間の理解を置き去りにしない設計 スキルの技術設計だけでは不十分です。ここが一番気をつけたポイントです。 AWSが提唱しているAI-DLC（AI Driven Development Life Cycle） は、AIの出力を妥当にジャッジできる人間の存在を前提としています。人間側の理解が伴わなければ成り立ちません。 しかし現実には、AIの出力を「なんか良さそうだから」とそのまま使ってしまい、人間側の理解が追いつかないケースも起きがちです。AIの進化によって実装の詳細を人間が把握しなくてよくなる部分はあるでしょう。ですが、背景にある考え方を理解していなければ、AIと適切にコミュニケーションを取ることはできません。 だからこそ、このスキル群では人間に考え方やインサイトをインプットする工夫を随所に入れています。いわば、いつでも質問できるメンターをAIで実現する試みです。 工夫点１：イントロダクションで「なぜ」を伝える 各Workflow Skillsの冒頭にイントロダクションを設けています。ここではいきなり作業に入るのではなく、「なぜこのフェーズが重要なのか」「このフェーズで何を学ぶのか」を説明します。 たとえば理解フェーズのイントロでは、コード理解には概念・構造・実装の3段階があり、概念レベルから順に深めるアプローチが有効であることを説明しています。 ## 推奨アプローチ 概念レベルから順に理解を深めることを推奨します： 1. 概念レベル: まず全体像を掴む（どんな世界なのか） 2. 構造レベル: データとクラスの設計を理解（どう表現されているか） 3. 実装レベル: 具体的なロジックを理解（どう動くのか） 工夫点２：ガイドラインURLの提示 全てのスキルで、参照したガイドラインのホスティングしているURLを、ユーザーに必ず提示するようにしています。 重要: 参照したガイドライン（https://{my-org}.github.io/handbook/backend/design/web _ api _ design.html） をユーザーに必ず提示してください。 AIの要約だけで完結させず、元のドキュメントに戻れる導線を用意しています。全体像を掴んだ上で、気になった箇所は原文で深掘りできます。Handbookそのものの認知と活用が進む効果も期待しています。 工夫点３：抽象から具体へ段階的に Workflow Skillsのフロー全体が、抽象度を段階的に下げていく設計になっています。 ワークフローの4フェーズ（理解→モデリング→計画→実装）がそうですし、各フェーズ内でも同様です。理解フェーズでは概念→構造→実装と段階的に深め、計画フェーズでは概念モデルの出来事やモノをAPIエンドポイントやテーブルへ変換していきます。 一気に情報を出すのではなく、フェーズごとにすり合わせの質問を挟むことで、開発者自身が考える余白を作っています。 以下は、思考実験として「タイミーで企業合併を表現するなら？」というお題で、モデリングのWorkflow Skillsを試したときの様子です。 「将来の新設合併対応を見据えて、今回のモデルはどの程度汎用的にすべきですか？」「合併には時間的なフェーズがありますか？」という質問が飛んできました。そもそも合併に吸収・新設のパターンがあることを私は知りませんでした。Handbookの設計ガイドラインを熟知したエキスパートと、ドメイン知識を持ったエキスパートが悪魔合体するとこんな体験になるのか、と末恐ろしくなった瞬間です。 工夫点４：各ステップに学習ポイントを明示 Workflow Skills内の各ステップには「なぜそうするのか」「ここで何を学ぶか」を明示しています。 📚 学習ポイント: - 出来事（申請する、承認する）→ APIエンドポイント - モノ（勤務実績、勤務時間）→ リソースとリクエスト/レスポンス - ビジネスルール → バリデーションとエラーハンドリング 💡 ガイドラインのポイント: - 出来事は動詞で考え、APIでは名詞（リソース）として表現 - 選択された名前（例：「勤務実績」）をリソース名に反映 作業の手順だけでなく、その背景にある考え方を一緒に伝えることで、AIが出す結果の「なぜ」を開発者自身が理解できる状態を目指しています。 使ってみての感想 自分自身の所感 実際に使ってみて、これまでとは一線を画す体験だと感じています。 従来のAIエージェントの出力は、一気にたくさんの情報を出してくることが多く、情報量に圧倒されて消化しきれないことがありました。ですが、このワークフローでは抽象度を段階的に下げながら教えてくれるので理解がしやすいです。普段の会話で賢いなと感じる人は、抽象的なところから徐々に具体へ落としていくのが上手ですが、このワークフローにも同じ感覚があります。 AIエージェントは便利な開発アシストツールだと思いつつも、開発のギアが上がる感覚はこれまでありませんでした。ですが、このワークフローは明確にゲームチェンジャーだと感じています。 VPoEの反応 VPoEに実際に動かしながら紹介したところ、その場でEMチャンネルに @here 付きで共有してくれました。特に、AIエージェントが段階的にガイドラインを適用しながら開発者と対話する体験に手応えを感じてもらえたようです。 語彙力が下がっているVPoE 他開発チームメンバーの反応 現在、社内への全体発信を終えて各チームへのハンズオンを順次進めているところですが、すでに手応えを感じ始めています。 既に普段の開発で使ってくれているエンジニアからはこんなコメントをもらっています。ありがたい限りです。 handbookはここ1,2年で一番自分に刺さったプロダクトです おわりに この記事では、バックエンド開発Handbookと、それをAIエージェント向けスキルとして届ける取り組みについて紹介しました。 ドキュメントを書くだけでなく、AIエージェントを介して開発フローへ自然に組み込むことで、ガイドラインを届ける新しいアプローチを模索しています。AIへ任せきりにせず人間側の理解を促すことが、知の高速道路を敷くうえで最も大事なポイントだと考えています。 今回の取り組みを通じて、AI時代の開発組織に必要な要素が見えてきた気がしています。短期目線での開発の高速化だけでは不十分で、「全タスクがオンボーディングタスクになっていること」「メンターを基本的にAIが担い、いくらでも質問できて自走できる環境が整っていること」。この2つが揃えば、誰でもどのチームに移っても素早く立ち上がれるようになります。つまり、必要な場所に必要な人材を配置できる人員の流動性の高さに直結します。Handbookとスキルの取り組みは、その第一歩です。 今回作成した Agent Skills はカジュアル面談でもデモできるので、興味ある方はお気軽にお声がけください！実際に触ってみたい方は、ぜひタイミーに入社してください！ product-recruit.timee.co.jp

こんにちは！プロダクトエンジニアのkazzhiraです。 私たちのチームでは、2025年の夏ごろから「AI活用による開発生産性の向上」に取り組んできました。しかし、当初の取り組みは抽象的なガードレールの提示や個々人の実践にとどまり、チームとして大きな成果には結びつきませんでした。 その後、SDD（仕様駆動開発）というアプローチに出会い、オープンソースの cc-sdd フレームワークをベースに試行錯誤を重ねてきました。 本記事では、AI開発標準の策定に失敗した経験から何を学び、どのように仕様駆動開発に辿り着いたのか、そして、実践を通じて得た成果と学びをご紹介します。 チームのAI導入でうまくいかなかった話 AI活用の個人最適化 当初、チームでは Cursor、Claude Code、Devin、GitHub Copilot、Gemini などの AI ツールを個々人の判断で利用できる状態でした。 しかし、AI活用の状況は個々人に閉じており、チームとしてのナレッジ共有や標準化は進んでいませんでした。 AI開発標準策定の失敗 そこで「AI開発標準」の策定を試みました。情報を収集したうえで、Planモードで実装計画を立て、途中でレビューを挟む開発スタイルを言語化しました。しかし、結果的にこの取り組みは失敗に終わりました。 資料の説明が抽象的で、チームが具体的に動きようがなかった 開発手法の共通項を抜き出しただけのガードレールに過ぎなかった 実際の開発プロセスに落とし込めず、絵に描いた餅になった 参考： 当時の考えを振り返った記事 なぜSDDをやろうと思ったのか 理想の開発体験の議論 チームで理想の開発体験・開発生産性の課題を話し合った結果、以下の課題が明確になりました。 リファインメント（仕様を決める会議）で議論が発散して収束に時間がかかる AIは顧客課題、ユーザーストーリーを知らず、要件の精度が高くない AIの出力が微妙で、整理されたコンテキストが足りない SDDとの出会い これらの課題を解決する方法として、 SDD（仕様駆動開発） に辿り着きました。 SDDの本質は、 仕様書を「単なるドキュメント」ではなく、AI と人間の両方が参照する SSoT（Single Source of Truth）として機能させる ことです。 定性面 AIがユーザーストーリー、背景、受け入れ条件から精度の良い仕様書を生成する →「AIは顧客課題、ユーザーストーリーを知らず、要件の精度が高くない」の解決 構造化された要件定義書・設計書・開発ルールで一貫したコンテキストを提供する →「AIの出力が微妙で、整理されたコンテキストが足りない」の解決 定量面 価値提供速度の向上 これらの効果を期待し、投機的に取り組んでみることを決めました。 ちなみに、「リファインメントで議論が発散して収束に時間がかかる」は当時Notion AIでの解決も試しました。しかし本題から外れるため、本記事では割愛します。 SDDの実践と工夫 cc-sddフレームワークの採用 SDD を実践するにあたり、私たちはオープンソースの cc-sdd （Spec-Driven Development フレームワーク）を採用しました。 深い理由はなく、筆者が各所で目にして実験的に入れていた背景があります。 チーム固有の課題 cc-sdd の基本的なアプローチを導入した上で、私たちのチームは以下の課題に直面しました。 複数のリポジトリを AI が横断的に操作できない チーム固有のタスク分割・実行ルールがなく、AI の出力がチームの開発フローに合わない Rails 固有の設計パターンが AI に伝わらない プロダクトのドメイン知識が AI に渡っていない 私たち独自のソリューション これらの課題に対し、私たちは以下の解決策を構築しました。 1. マルチリポジトリ横断ワークスペース Cursorによる開発を前提に、code-workspaceを生成して複数リポジトリを統合的に扱う仕組みを実装しました。 【my-team.code-workspace】 { " folders ": [ { " name ": " my-team ", " path ": " . " } , { " name ": " backend ", " path ": " ~/workspace/backend-repository " } , { " name ": " frontend ", " path ": " ~/workspace/frontend-repository " } , ... ] } これにより以下のメリットが得られました。 AI エージェント（Cursor / Claude Code 等）がリポジトリを横断して操作可能 仕様書リポジトリ（my-team）とコードベースを統合管理 私たちの最初の実装では、my-team・backend・frontendをセットで管理しました。 今はもう少し増えています。 2. タスク生成・実行ルールの整備 チーム固有のタスク生成・実行ルールを定義しました。 ルール種別 内容 タスク分割ポリシー "デプロイ可能な最小粒度" にタスク分割 Commit・Push・PRのルール 例示することで、意図した生成に誘導する。例えば "commitには変更理由とリファレンスを必ず含める"、"PRテンプレートに従う" など。 タスク実行順序の定義 Swaggerを定義してからfrontendとbackendの作業に移行する。 3. カスタムステアリングドキュメント Rails 固有の設計パターンやプロダクトのドメイン知識をステアリングドキュメントとして整備しました。 Controller Patterns（ before_action の濫用禁止、個別でエラーハンドリング不要など） プロダクト固有の名称、用語、ユースケース リポジトリ構造のサマリ 採用している技術の詳細 例として「プロダクト固有の名称、用語、ユースケース」を定義した例を示します。 # Product Overview タイミーアプリのAPIサーバー、クライアント向けWebアプリケーションのAPIサーバー、 ワーカー向けモバイルアプリケーション、社内管理ツールを提供するプラットフォーム。 ## Core Capabilities 1. **ワーカー・クライアント管理**: ワーカーとクライアント企業のアカウント管理、認証、プロフィール管理 2. **求人・マッチング**: 求人作成、公開、ワーカーとのマッチング機能 3. **勤怠・給与管理**: 出勤管理、給与計算、支払い処理 4. **コミュニケーション**: チャット機能、レビュー・フィードバック機能 5. **管理機能**: 社内管理ツール、各種レポート・分析機能 ## Target Use Cases - **クライアント企業**: 求人作成・管理、ワーカー管理、勤怠確認、給与支払い - **ワーカー**: 求人検索・応募、勤怠管理、給与確認 - **社内管理者**: システム管理、データ分析、各種レポート生成 ## Value Proposition - ワーカーとクライアント企業を効率的にマッチングするプラットフォーム - 勤怠管理から給与計算まで一貫した業務フローを提供 4. カスタムコマンド cc-sddのコマンド体系以外で、チームで必要な成果物を保管するためのコマンドを用意しました。内容は長いため省略します。 QAチェックリストの自動生成「spec-qa-checklist」 Playwright MCPによるQA自動実行「playwright-mcp-qa」 最終的なファイルツリーを示します。 my-team/ ├── my-team.code-workspace # マルチリポジトリ統合ワークスペース定義（独自作成） ├── repos.yml # 対象リポジトリ一覧（独自作成） ├── repos.template.yml # ↑のテンプレート（独自作成） ├── docs/ # プロジェクト横断ドキュメント │ ├── scripts/ │ ├── setup.sh # 初期セットアップ（独自作成） │ ├── setup-workspace.sh # ワークスペース構成生成（独自作成） │ └── sync-*.sh # リポジトリ・設定の同期（独自作成） │ ├── .cursor/ │ └── commands/ # カスタムコマンド（独自作成） │ ├── spec-qa-checklist.md # QAチェックリスト生成 │ └── kiro/ # Kiro Spec-Driven コマンド群 │ └── .kiro/ ├── steering/ # アーキテクチャ制約 │ ├── product.md # プロダクト原則 │ ├── tech.md # 技術標準 │ └── structure.md # コード構造パターン ├── settings/ │ ├── rules/ # 設計・実行ルール（独自） │ │ ├── tasks-generation.md # タスク生成（プレフィクス規約・分割順序）（独自作成） │ │ └── task-execution-policy.md # 実行ポリシー（環境・Git・コミット規約）（独自作成） │ └── templates/ │ ├── specs/ # 仕様テンプレート │ └── steering/ # ステアリングテンプレート └── specs/{feature}/ # 機能単位で生成 ├── requirements.md # 要件 ├── design.md # 設計 ├── tasks.md # タスク └── e2e-qa-checklist.md # QA（独自作成） 評価 ポジティブな評価 cc-sddの短期間の導入で最も価値を感じたのは、実装速度の向上ではなく、 開発プロセスの質の向上 でした。 暗黙知の形式知化 — これまで個人の頭の中にあった仕様判断が、requirements / design / task の3つの成果物を通して言語化・共有された 手戻りの減少 — 仕様書によってコンテキストが整理されたことで、AIの出力品質が安定し、実装後の手戻りが体感として減った 合意形成の質の向上 — 仕様を厳格に言語化するプロセスが、チーム内の認識齟齬を早期に解消した モブワークとの親和性 — 構造化された仕様書が共通言語として機能し、スプリント初期の設計作業を効率的に進めることができた ネガティブな評価 一方で、チームで改善すべき課題も挙がっています。 モノにもよるが、仕様書を作る工程で同期的に1日〜1.5日の時間を使う 仕様書を精査する工程の疲労感 実装スピードとデプロイ頻度は、以前と同等か、微増している感覚 シンプルに練度不足 リファインメントが引き続きボトルネック。実装が効率化しても、要求の供給が追いつかなければ全体のスループットは上がらない 中間生成物のレビューがリファインメントに次ぐボトルネック。AIが高速に生成するアウトプットに対し、人間のレビューが追いつかない etc. データで見る事実：cc-sdd導入でデプロイ頻度は向上しなかった 前提として、開発者が3名のスクラムチームです。 【デプロイ頻度の移動平均推移】 デプロイ頻度の移動平均推移 開発生産性を測るFour Keysの1つの指標であるデプロイ頻度に着目しました。 cc-sdd導入前後でデプロイ頻度が向上していないことを観測 AIを本格導入してきた過去6ヶ月で見るとデプロイ頻度は増加傾向 先ほどのネガティブな評価の「実装スピードとデプロイ頻度は、以前と同等か、微増している感覚」とも一致しています。 ここで、他の視点も入れてみます。 【デプロイ頻度と変更リードタイムの移動平均推移】 デプロイ頻度と変更リードタイムの移動平均推移 【平均レビュープルリク数とレビューからアプルーブまでの平均時間の移動平均推移】 平均レビュープルリク数とレビューからアプルーブまでの平均時間の移動平均推移 【マージ済みプルリク数のアクティビティの推移】 マージ済みプルリク数のアクティビティの推移 これらの結果から、cc-sddによる開発について3つの事実が分かりました。 変更リードタイムは以前の開発繁忙期の時と同程度の推移 ※sddに関連するドキュメント更新のアクティビティは計測対象外です レビュー時間は以前よりも下がっている 瞬間風速的にはPR作成数が過去半年で最多を記録した cc-sddによって、設計からレビューの効率化には成功しているが、デプロイまでの流れを阻害しているボトルネックが別に存在すると読み取れます。 これまでの経緯を含めて考察すると、それはリファインメントによる要件の供給速度だということがわかります。 今後の取り組み ここまでの取り組みでは事実としてデプロイ頻度が上がりませんでした。 ネガティブな評価であがった課題を “のびしろ” と捉え、インパクトの大きい課題をコツコツ解消していく予定です。 直近では、AI-DLCのアプローチとスクラム開発と組み合わせ、リファインメントを改善する方針で以下の取り組みを進めています。 AIを要求・デザインフェーズにも適用し、仕様策定のボトルネックを解消する 仮説の壁打ち プロトタイプ作成を回す AIがアクセス可能なSSoTの範囲拡充（ビジネスコンテキスト、ユーザーリサーチ等） 価値提供のフィードバックループを短縮し、次の要求定義に繋げる まとめ cc-sddの導入で仕様の認識齟齬が早期に解消され、意図した仕様どおりの実装に到達しやすくなりました。 しかし世間で語られるようなAIによる劇的な生産性向上には至っていません。 仕様策定フェーズのボトルネックやレビュー負荷など、AIを適用できる余地は多く残されています。 私たちのチームでは、思考をAI Drivenに変化させ、要求定義から価値提供までの全体フローを、改めてAI前提で組み直す必要があることが見えてきました。 この記事を書いている時点でも新たな取り組みで急速に進化していることを実感しています。 私自身も置いていかれないように、チームに貢献できるように成果を出し続けようと思います。 引き続きこの領域に挑戦していきます。 タイミーには、こうした挑戦と学び、そして発信を歓迎する文化があります。 ともに挑戦し成長していきたい方、興味があればぜひ1度お話ししましょう！ プロダクト採用サイトTOP カジュアル面談申込はこちら