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