はじめに
「マネージャーになったらコード書かなくなるよ」
そんな話を聞いてマネージャー職になって数年。確かにチームの開発ラインに入ることはなくなりました。
プルリクを出すこともなければ、コードレビューで細かい指摘をすることも減りました。
それでも、本当に「コードを書かなくなった」かというと、そうでもないんですよね。
むしろ「チームのリソースに入らない場所で、こっそり手を動かしている」というのが実態だったりします。
いわゆるプレイングマネージャーってやつです。
そんな私が最近ハマっているのが Claude Code 。
今回は「現場を離れたはずのマネージャーが、なぜ今さらCLIツールを触っているのか」という話をしたいと思います。
「現場を離れた」は本当か？
マネージャーの仕事って、チームのマネジメント、タスク・スケジュール管理、他チームとの調整...みたいなイメージがあると思います。
確かにそういう仕事が増えたのは事実なんですが、開発者以外のメンバーとのやり取りも多くなり、チームに頼むほどでもない雑務が発生するようになったんですよね。
例えばこんなやつです
- 「このスプレッドシートのデータ、ちょっと加工して別のフォーマットに変換したい」
- 「前に自分で書いたシェルスクリプト、微修正したいけど何書いてあるか読めない」
- 「簡単な社内ツールのプロトタイプ、サクッと作って見せたい」
これらの共通点、わかりますか？
「本格開発ではないが、スピードが命」 なんですよ。
チームのバックログに積むような話でもないし、ましてや外注するほどでもない。自分でサクッと片付けたい。でも、いざやろうとすると「あれ、この構文どう書くんだっけ...」となる。
技術力は確実に錆びついてるのに、マネージャーとしてはスピード感を求められる。この矛盾、プレイングマネージャーあるあるじゃないでしょうか。
なぜClaude Codeなのか？
そこで出会ったのが Claude Code です。
Claude CodeはAnthropicが提供するCLIベースのAIコーディングツールで、ターミナル上で対話しながら開発ができます。
「いやいや、ChatGPT とか Copilot とかあるじゃん」と思うかもしれません。確かにGUIベースのAIツールも便利です。でも、Claude Codeにはマネージャーに刺さるポイントがあるんですよね。
1. ファイル操作から Git 連携、実行までシームレス
GUIのAIツールだと、コードを生成してもらって、コピペして、ファイルに貼り付けて、実行して...という手順が必要です。
Claude Codeはターミナル上で完結するので、ファイルの作成・編集・実行・Git操作まで対話の中で進められます。
この「手数の少なさ」がスピード重視のマネージャーには刺さる。
※ ここまでCLIを推してきましたが、実を言うと最近はVS CodeのClaude拡張機能を使う頻度が増えています。
当初はCLIの「ターミナルだけで完結する没入感」に感動したのですが、最近の拡張機能の進化が凄まじく、扱いやすさも相まってエディタ内で完結するようになったからです。タイトル詐欺みたいになってしまいごめんなさい。。。
2. 思考をそのまま言葉にすれば動く
「このCSVを読み込んで、特定の条件でフィルタして、別のCSVに出力したい」
これくらいの雑な指示でも、Claude Codeは意図を汲み取ってコードを書いてくれます。
正確な構文を覚えていなくても、「何をしたいか」を伝えれば形になる。
これ、技術力が錆びついたマネージャーには本当にありがたいんですよね。
3. 記憶が曖昧なところを全部補完してくれる
「えーと、日付のフォーマットってどうやるんだっけ...」
「sedコマンドの正規表現、毎回ググってる気がする...」
こういう「なんとなく知ってるけど正確には覚えてない」部分を、Claude Codeが全部補完してくれます。昔取った杵柄がそのまま活きる感覚です。
2025年のAI開発トレンド：Vibe Codingと仕様駆動開発
ここで私の体験を語る前に、少し視野を広げて、2025年のAI開発トレンドについて触れておきます。
Vibe Codingとは？
2025年、OpenAI共同創設者の Andrej Karpathy氏が提唱した「Vibe Coding（バイブコーディング）」という概念が話題になりました。
これは「雰囲気」や「感覚」でAIに指示を出し、コードの細部には踏み込まずに開発を進めるスタイルです。
「チャットアプリを作って」と伝えるだけでAIがコードを生成し、「履歴機能を追加して」と言えば機能拡張される。まさに魔法のような体験です。
ただし、このアプローチには課題もあります。
- 仕様の曖昧さ：生成されたコードが本当に要件を満たしているか検証が難しい
- AI の実装がブラックボックス化：なぜその実装になったのか追跡できない
- 保守性の低下：構造的な設計なしにコードが増えていく
仕様駆動開発（Spec-Driven Development）の登場
この課題に対して注目されているのが 「仕様駆動開発（SDD）」 です。
AWSが2025年7月に発表したAI IDE「Kiro」や、GitHubがリリースした「Spec Kit」がこのアプローチを体現しています。コードを書く前に仕様を定義し、それを元に開発を進めていく考え方です。
仕様駆動開発の基本的な流れはこうです。
- 自然言語で要件を伝える
- AI が構造化された仕様書（requirements.md）を生成
- 人間がレビュー・承認
- AI が設計書（design.md）を生成
- タスクリスト（tasks.md）に分解
- 仕様書に基づいてAIが実装
つまり「バイブス → 仕様 → コード」という多段階プロセスを踏むことで、Vibe Codingの即興性と、従来の仕様書駆動開発の明確性を両立させようという考え方です。
両者の使い分け
| 観点 | Vibe Coding | 仕様駆動開発（SDD） |
|---|---|---|
| 向いている用途 | 単発スクリプト、プロトタイプ | チーム開発、中〜大規模プロジェクト |
| スピード | 速い | やや遅い |
| 品質・保守性 | 低い | 高い |
| 学習コスト | 低い | やや高い |
| ドキュメント | ほぼなし | 体系的に残る |
これを見ると、「マネージャーの単発タスクなら Vibe Coding でいいじゃん」と思うかもしれません。
でも、私の経験上、Vibe Coding だけだと「思ってたのと違う」が頻発するんですよね。
私のやり方：ゆるい仕様駆動開発
そこで私がたどり着いたのが、両者のいいとこ取りをした「ゆるい仕様駆動開発」です。
Step 1：ざっくり要件を投げる
最初のプロンプトは Vibe Coding的に雑でOKです。
「○○のデータを集計して、週次でSlackに投稿するスクリプトがほしい」
これくらいの粒度で投げます。
Step 2：Claude Code に要件ヒアリングしてもらう
ここがポイントなんですが、すぐに実装に入らせないんですよね。
「まず要件を整理したいので、ヒアリングしてください。」とClaude Codeに聞いてもらいます。
- データソースはどこですか？
- 集計の粒度は日次？週次？
- Slack のどのチャンネルに投稿しますか？
- エラー時の通知は必要ですか？
自分で要件定義書を書くよりも、対話形式で聞かれるほうが抜け漏れに気づきやすいんですよね。
これ、マネージャーとして要件を詰める会議をAIとやっている感覚に近いです。
Step 3：docs ディレクトリに仕様書を作成してもらう
ヒアリングが終わったら、docs/ディレクトリ配下に仕様書を作成してもらいます。
「今の内容をdocs/requirements.mdに仕様書としてまとめて」
docs/
├── requirements.md # 仕様書
└── tasks.md # タスクリスト（後で作成）
これで、ふわっとした会話がドキュメントとして残る。ここが重要です。
Step 4：仕様書をレビュー・修正（ここに一番時間をかける）
私が一番時間をかけているのは、このフェーズです。
作成された仕様書を読みながら、「ここはこうじゃなくて。。。」「この機能はなくていいや」「こっちの優先度を上げたい」みたいな修正を入れていきます。
コードを書く時間より、仕様を固める時間。これって、マネージャーとしての経験がそのまま活きる部分なんですよね。要件の優先順位付けとか、スコープの切り方とか。
技術力は錆びていても、「何を作るか」を決める力は鍛えられてきたはず。
Step 5：タスクに分解して進捗管理
仕様が固まったら、タスクリストを作成してもらいます。
「この仕様書からタスクを洗い出して、docs/tasks.mdに書いて」
あとはタスクを一つずつ消化してもらいながら、進捗を確認するだけ。「次は Task2をお願い」「Task3は後回しで」とコントロールしていきます。
実装フェーズはほぼ見ているだけです。プロジェクトマネジメントの感覚に近い。
本格的な仕様駆動開発との違い
世の中で紹介されている仕様駆動開発（KiroやSpec Kit）と比べると、私のやり方はかなりライトです。
| 観点 | 本格的な SDD（Kiro 等） | 私のやり方 |
|---|---|---|
| ツール設定 | 専用IDE・カスタムコマンド | 素のClaude Code |
| ドキュメント構成 | requirements.md / design.md / tasks.md の 3層構造 | requirements.md と tasks.md の2ファイル |
| 承認フロー | 各フェーズで明確な承認ポイント | 仕様書レビュー時にまとめて確認 |
| 対象規模 | チーム開発・中〜大規模プロジェクト | 単発スクリプト・小規模ツール |
| 所要時間 | 数時間〜数日 | 30分〜2時間 |
要するに、本格開発のエッセンスだけ拝借して、マネージャーの片手間仕事に適用している感じです。
Vibe Codingの気軽さは残しつつ、「仕様書で握る」ことで手戻りを減らす。この塩梅がマネージャーにはちょうどいい。
このやり方のメリット
- 会話が資産になる：ふわっとした要件が仕様書として残る
- 手戻りが減る：実装前に仕様を固めるので「思ってたのと違う」が起きにくい
- マネージャーのスキルが活きる：要件整理・スコープ管理は得意分野
- あとから見返せる：半年後に「これ何だっけ」となっても仕様書がある
使う上での心構え・注意点
とはいえ、万能ツールではないということも書いておきます。
本格開発は慎重に
これはあくまで私なりのやり方であり、本格的な仕様駆動開発をチームで経験しているわけではないため、実際の効率や品質については未検証です。
あくまで 「自分用」「一時的」「検証用」 という位置づけで使うのがおすすめです。
完璧を求めない
「7割で動けばOK」の精神が大事です。どうせ単発のスクリプトや検証用のコードなんだから、完璧なコードである必要はない。動いて目的が達成できれば勝ちです。
まとめ: リソース不足を嘆く前に
プレイングマネージャーって、リソース不足で苦しむことが多いですよね。チームに余裕がないから自分で動きたい、でも自分の技術力には限界がある、でもスピードは求められる。。。
Claude Codeは、そんな「錆びた技術力」をブーストしてくれる相棒だと思っています。
2025年現在、Vibe Codingと仕様駆動開発という2つのアプローチが話題になっていますが、マネージャーの単発タスクにはその中間くらいがちょうどいい。
- Vibe Coding の気軽さで始めて
- 仕様書で認識を握って
- 進捗管理しながら実装を委ねる
「現場を離れた」と言いつつ、実は現場との接点を違う形で持ち続けているマネージャーは多いはず。その接点を、もっと効率的に、もっとストレスなく保てるようになるツールとして、Claude Codeは結構おすすめです。
今回、Claude Codeの具体的な使い方については言及しませんでしたが、さらに効率化できるポイントがいくつかあります。たとえば、コーディング規約などプロジェクトの前提を記載したCLAUDE.mdを用意しておくことや、MCPと連携させること、サブエージェント機能の活用などです。まずは「ゆるい仕様駆動開発」から始めてみて、徐々にできることを増やしていくのがおすすめです。
興味があればぜひ触ってみてください。
最後まで読んでいただきありがとうございました。「わかる〜」「やってみようかな」と思えたら「いいね」してもらえると嬉しいです。