【#1】PLとしてAIネイティブ開発をゼロから立ち上げた話【プロジェクト方針・体制編】
この連載について
PLとして新規システム開発を立ち上げた。テーマは「AIをフル活用して開発する」こと。
ただ、「AIを使う」と言っても何を目指すのかが曖昧だと結局は補助的にしか使えない。なので最初からゴールを決めた。
設計書・コード・テスト、全部AIに生成させる。人間はレビューと判断に集中する。
この連載では、プロジェクト立ち上げから各工程のリアルを順番に書いていく。第1話の今回は「方針決め・体制設計・環境選定」の話だ。
なぜ今これをやるのか
正直に言うと、これまでの開発スタイルに限界を感じていた。
設計書はWordとExcelで、バージョン管理はファイル名で（設計書_v3_最終_修正版2.xlsx みたいなやつ）。コードレビューはPRを見て手でコメント。テストケースは表でべたっと管理。
このやり方で何年もやってきたけど、チームが変わるたびに属人化するし、AIに渡しても「このExcelを読み込んで…」みたいな手間が発生して、結局AIの恩恵が薄くなる。
AIが読みやすい状態を先に作れば、AIはもっとよく働く。 その仮説を、実プロジェクトで検証したかった。
KPIはシンプルに「生産性を5〜10%向上」。別に劇的な数字を狙っていない。まず確実に再現できる改善を積み重ねることが先だと思っている。
体制設計：2チーム制にした
体制は以下のように組んだ。
PL（自分）
├── AI推進補佐メンバー × 1名
│ → Agent・Skillの設計・量産・改善
└── 開発メンバー × 4名
→ AgentをつかってタスクをこなしてPRを出す
+ フィードバック（Agentへの使用感・改善要望）
ポイントは「Agentを作る人」と「Agentを使う人」をはっきり分けたこと。
最初は開発メンバーにAgentも作らせようとした。でもそれをやると、「Agentを育てながら開発する」という2つの責務が混ざって、両方が中途半端になる。
Agentは品質と精度が命なので、自分とAI推進補佐メンバーが専任で作り込む。開発メンバーはAgentを信頼して使い、疑問や改善点をフィードバックするだけでいい。このサイクルを回すことで、Agentが現場に合った形に育っていく想定だ。
ツール選定：GitHub Copilot一本で行く
今回はGitHub Copilot（エンタープライズ）のEnterpriseプランでマルチモデルが利用可能な設定を使う。モデルはClaude / GPT / Geminiを一通り使える環境だ。
実は、ツール選定の時間はほとんどかからなかった。理由はシンプルで、会社として使えるAIツールがGitHub Copilotだけだったからだ。Claude CodeもCursorも、個人開発では触っていて魅力は十分わかっている。でも社内のセキュリティ審査を通っていないツールを業務で使うわけにはいかない。
最初は「縛りがあってもったいないな」と思っていた。が、使い込んでいくうちに考えが変わった。
1つのツールしか使えない＝「何がうまくいって何がダメだったかを純粋に評価できる」。複数ツールを混在させると「これはCursorのおかげ？Copilotのおかげ？」が分からなくなって、ノウハウが蓄積しにくい。制約が逆にプラスになった形だ。
また、GitHub CopilotはVS Code内でAgentモード・Skillファイル・プロンプトファイルが全部連携できる。リポジトリの.githubフォルダに指示を集約すれば、IDEを離れずにAIをフル活用できる。この一体感は他のツールにはなかなかない強みだと感じている。
設計書のフォーマットを全部Markdownにした
ここが今回の取り組みの中で一番「やってよかった」と思っているポイントだ。
設計書は一切Word/Excel/PowerPointを使わない。全部Markdownで書く。
理由は2つある。
1. AIが直接読み書きできる
MarkdownはGitHub CopilotのAgent/Skillが直接読み込める。Excelだと「この表を読んで」みたいなコンテキスト渡しが必要になるが、Markdownならリポジトリに置いてあるファイルをそのまま参照させられる。
2. Git管理できる
差分が見える。誰がどの行を変えたかが追える。設計書とコードを同じリポジトリで管理できる。ExcelはGitで管理すると「Binary file」とだけ出て、差分が全く見えない。
最初は「設計書がMarkdownで大丈夫なの？」という不安をメンバーから聞いた。見た目の問題だと思う。Excelの方が「ちゃんとしてる感」がある。でも1週間使ってみると、見た目より「探しやすさ」「更新しやすさ」「AIに渡しやすさ」の方が圧倒的に重要だと全員が実感してきた。
.githubフォルダをプロジェクトの司令塔にする
GitHub CopilotのAgent/Skillを管理するために、.githubフォルダをかなり作り込んだ。
.github/
├── copilot-instructions.md # 全体への指示・ルール
├── instructions/ # 工程別・役割別の指示
├── prompts/ # 各タスク用のプロンプトファイル
└── skills/ # 専門知識を持たせたSkillファイル
他社の取り組みも参考にしつつ、うちは立ち上げ直後なのでまずは十数個から始めた。工程が進むごとに増やしていく予定だ。
立ち上げてみて思ったこと
最初は、基本設計書の作成からAgentで進めるつもりだった。要件定義は別部隊が担当するため、私たちは基本設計から着手する計画だった。
ただ、実際に要件を読み込むと曖昧な部分が多く、この状態で素直に基本設計を作ると穴だらけになるリスクが高かった。しかも、要件の不明瞭さをあぶり出す作業は、プラットフォーム固有ルールやチームの慣習といったバイアスが強く、Agentだけで安定して処理するのが難しい。
この判断から、基本設計書の初版は人が作る方針に切り替えた。Agentには、抜け漏れチェック、観点追加、表現統一などの支援に回ってもらう形にしている。
もう1つ、大きく方針転換したのが体制だ。もともとは開発メンバーにもAgentを作ってもらう想定だったが、AI熟練者に開発計画を壁打ちした際に「Agentを作ったことがないメンバーには難しい」と指摘を受けた。実際、メンバーの中には「Agentって何？」という状態の人もいた。
キックオフ前のスキル確認で薄々感じていた違和感もあり、この体制のままでは立ち上がりが遅れると判断。そこで、Agent作成は専任チームが担当し、開発メンバーは使う側に集中する体制に変更した。
この変更で、立ち上げ直後の混乱はかなり減った。作る側と使う側の責務が明確になり、改善サイクルも回しやすくなっている。
次は進行管理編。計画・進捗・課題管理をAI前提でどう回しているかを、実運用ベースで書く予定だ。
この連載のロードマップ
| パート | 位置づけ | テーマ |
|---|---|---|
| キックオフ編 | 公開済み（本記事） | プロジェクト方針・体制・環境設定 |
| 進行管理編 | 次回予定 | 計画・進捗・課題管理をAI前提でどう回すか |
| 基本設計編 | 複数記事で展開予定 | 要件の曖昧さをどう設計に落とすか / 人とAgentの分担 / レビュー観点の作り方 |
| 詳細設計編 | 複数記事で展開予定 | I/O定義中心で設計を具体化する進め方 |
| 開発編 | 複数記事で展開予定 | プロンプト資産化と実装フローの運用 |
| 単体テスト編 | 複数記事で展開予定 | テスト観点とケース生成の実践 |
| 振り返り編 | 最終フェーズ | KPI達成度と次フェーズへの改善点 |
Discussion