Skip to main content

チーム向けPTOトラッカーを構築する

ツールの要件を記述すると、Devinがエンドツーエンドで構築・テスト・検証します。
AuthorCognition
Category機能開発
1

（任意）Ask Devin でコードベースのスコープを定義する

既にアプリに社内向けツールがある場合は、仕様を書き始める前に Ask Devin を使って既存のパターンを把握してください。特に、新しいツールを既存のアーキテクチャに合わせたい場合に有用です。回答を使って、仕様に具体的なファイル参照、コンポーネント名、パターンを書き込み、Devin が既存ツールと一貫性のあるものを構築できるようにします。また、Ask Devin から直接 Devin セッションを開始することもでき、そのセッションには Ask Devin が取得した内容がコンテキストとして引き継がれます。
2

詳細な仕様を作成する

Internal tools — PTO トラッカー、管理パネル、データスクリプト、CLI ユーティリティなど — は不可欠ですが、優先されることはほとんどありません。要件が明確で、利用者は自分たちのチームであり、「正しく動作すること」がピクセル単位で完璧なデザインよりも重要なため、Devin にとって理想的な対象です。ツールが何をするのか、どんなデータを保存するのか、どのサービスと連携するのかを具体的に記述してください。詳細を含めれば含めるほど、最初のバージョンがあなたのニーズに近づきます。Ask Devin を使って仕様をブラッシュアップすることもできます。ラフなドラフトを貼り付けて、コードベースに基づいた抜け漏れの指摘や改善提案を依頼してください。
3

認証情報を追加

Devin が必要とする APIキー やトークンは、Secrets 経由で渡します。この例では Slack の Webhook URL です。最も簡単な方法は、セッションを開始する前に、それらを組織シークレットとして保存しておくことです。
  1. Settings > Secrets に移動し、SLACK_WEBHOOK_URL を追加します
  2. Devin はシークレットに環境変数としてアクセスするため、それらがソースコードにハードコードされることはありません。
組織シークレットはセッションを開始する 前に 追加する必要があります。セッション開始時に注入されるためです。あるいは、チャットを使ってセッション中にシークレットを渡すこともできます。また、Devin は不足している環境変数がある場合、必要な認証情報を能動的に問い合わせます。
4

スラッシュコマンドでセッションを進行する

セッション開始後は、スラッシュコマンドを使って Devin のワークフローを調整できます。
  • /plan — コードを書く前に、詳細な実装計画を作成するよう Devin に依頼します。実装を始める前に計画を確認し、必要に応じて修正案を提案してください。
  • /test — すべてのテストを実行して作業内容を検証するよう Devin に指示します。各主要なマイルストーンの後に実行して、問題を早期に発見できるようにします。
  • /review — PR を作成する前に、バグ、エッジケース、スタイル上の問題について、自分で書いたコードをレビューするよう Devin に依頼します。
これらのコマンドはセッションのどのタイミングでも使用できます。セッション開始時に /plan、各機能の実装後に /test、最終的な PR の前に /review を実行してください。
5

Devin が構築し、正常に動作することを検証します

Devin は社内ツールも本番機能とまったく同じように扱います — コードを書き、テストを追加し、組み込みブラウザでアプリを開いて、UI がエンドツーエンドで正しく動作するか検証します。
  1. コードベースを調査 — DataTable と Calendar コンポーネントを見つけ、Prisma のスキーマを読み、既存の /internal/ ページレイアウトを確認します
  2. データベースマイグレーションを作成 — Prisma を使って pto_requests と pto_balances テーブルを追加します
  3. ページを構築 — /internal/pto 配下に、申請フォーム、マネージャー承認キュー、カレンダービュー、残高ダッシュボードを作成します
  4. Slack と連携 — 申請が送信されたとき、また承認または却下されたときに webhook 通知を送信します
  5. テストを書く — PTO 残高計算と日付重複検出のユニットテスト、申請エンドポイントの API テスト、承認ワークフローの統合テストを作成します
  6. ブラウザでアプリを開く — すべてのページに遷移し、テスト用の PTO 申請を送信し、マネージャービューから承認し、カレンダーが更新されることを確認し、ダッシュボードの数値をチェックし、日付の重複や残高超過などのエッジケースをテストします
  7. PR を作成 — マイグレーション、シードスクリプト、アプリケーションコード、テストに加え、そのツールの使い方を説明する README セクションまで、すべてをまとめて提供します
ブラウザでの検証によって、自動テストでは見逃される問題を発見できます — 崩れたフォームレイアウト、レンダリングはされるがクリックに反応しないカレンダー、成功後にフォームをクリアしない送信ボタンなどです。
6

ツールを拡張する

Once the base tool works, add features in follow-up sessions:
7

Devin Review で PR をレビューする

Devin が PR を作成したら、Devin Review を使って変更内容をレビューします。Devin Review はコードベース全体のコンテキストを把握しているため、差分全体にわたってバグやセキュリティ上の問題、スタイルの不整合を検出できます。