105
48

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

よくわからずにClaudeのSkillを使い倒し始めたら、自分の仕事が丸裸になりつつある話

105
Posted at

はじめに

いえらぶGROUPの開発部で執行役員を務めています、和田です。わだけんです。

みなさん、Claude Code、使ってます?Claude Code・CodeXあたりを去年末までうろちょろしていたんですが、やはり界隈の勢いに押されて年始からはClaude Codeばかり触るようになりました。

といっても、昨年まで実はエージェント作ったりとかスキル作ったりとかあんまりしておらず、「やばいどっかでインプットして組み立てないとなぁ」と焦りつつ、日々の業務のほうが当然に優先順位が高いので、「出足遅れたな~」と考えていたのが実態です。

それが2週間前、ふと時間ができたのでようやく重い腰を上げ、スキルを本格的に使い始めました。

これまでも業務で触ってはいたんですが、どんどん便利になっていくので気づいたら2週間で974回も会話してて、Skill作って、MCP Server作って、Agentまで作ってたって状態にまで至っています。

その過程で予想外だったのが

自分がこれまでどういう作業をやっていたのかが、どんどん整理されていく、 ということ.

なんというか、仕事の解像度が上がるというか。「あ、俺ってこういう作業を繰り返してたんだ」みたいなことが、Claude任せで作業してるうちに見えてくる感覚があります、ちょっとビビっています。

ですが、一番伝えたいのは、別にClaudeの機能について詳しくなくてもこうなったということです。

「MCP?Agent?Skill?何が違うの?」みたいな状態から始めて、気づいたらそれぞれの役割分担が見えてきた。構えずに使い続けていたら、自然と整理が進んでいった感じです。

なのでそこらへんの敷居を下げることができたらいいなと思って、直近の自分の動きを記事にまとめています。

何が起きたか:2週間の記録

まず、実際に何が起きたかを時系列で整理してみます。

Phase 1:単発タスクの時期

これまでは、当たり前ですが普通にClaude Codeにお願いごとをしていた感じです。

  • 「この処理、どこで何やってるか調べて」
  • 「この設定ファイル、何が違うか比較して」
  • 「このバグ、原因わかる?」

1日あたり15〜40回くらいの会話量。いや~便利なツールだな~、たすかるな~、という認識でした。

Phase 2:スキル化の時期

当然ですが、同じようなお願いを何度もしている自分 がいることには気づいていました。

「コードレビュー、また頼んでるな」
「チケットの状況確認、これ毎回やってるな」
「レビューの観点、毎回説明してるな」

→ なんかスキル作るのが流行ってる臭い

そしてついに「スキル化してみようか」と思い至ります。

一番の動機としては、単に繰り返しがめんどくさいというのもあるんですが、一番は開発部のほかのメンバーにも共有したかったから。

自分がやってるチェックの観点とか、レビューで見てるポイントとか、それをスキルとして定義しておけば、他のメンバーも同じ品質で作業できるようになる。属人化を減らして、チーム全体の生産性を上げたかったんですよね。

Phase 3:スキルのブラッシュアップ時期

スキルを作って終わりかというと、そうでもなくて。

実際に使っていると「あ、この観点も入れたほうがいいな」「ここの説明が足りないな」ということが出てくる。

たとえばコードレビューのスキル。最初は基本的な設計原則(SRPとか)だけだったんですが、使っていくうちに:

  • 過去の障害事例(PostMortem)に基づくチェック観点を追加
  • 「車輪の再発明してないか」という既存コード活用の観点を追加
  • テスト容易性の観点を追加

みたいな感じで、どんどん書き足していきました。

ただ、ここでちょっとした違和感が出てきたんですよね。

「これ、ソースコードが肥大化するのと同じ感じじゃない?」

作業するたびにスキルに書き足していたら、なんかスキルの精度が鈍くなっていくだろうな、という肌感がありました。ソースコードが汚くなっていく感覚に似てる。

Phase 4:定期的なベストプラクティスチェック

そこで、定期的にこういうお願いをするようになりました。

「このスキル、ベストプラクティスに沿ってるかチェックして、修正・整理して」

正直、何がベストプラクティスなのか、自分ではよくわかってない(笑)。

でも「なんとなく、それぞれの機能にはベストプラクティスがあるんだろうな」ということはわかっていたので、Claudeに聞いてみた感じです。

それでも、「ベストプラクティスに沿って、こんな感じで直しました」という説明を読んだら「あ~なるほどね~」という納得は得られるので、そんな感じでちょっとずつ知識を深めていっています。

そして、転換点となるある時、こう言われました。

「これはスキルではなく、エージェント化したほうが良いですね」

おお、なるほど。

Phase 5:全体整理とMCP/Agent化

言われてみれば、Claude Codeの機能の種類はいろいろあったし、自分はその辺意識できてなかった(恥ずかしい)。
そこで、物は試しでそれまでに作った多数のスキルに対して、こういう指示を出してみました。

「MCP・エージェント・スキル、そのほか、どの役割で活用するのがベストプラクティスに最も近いか、全体的に整理して」

すると、案の定ですがちゃんと役割分担が整理された。

  • 外部APIを叩く処理 → MCP Server
  • 複数ステップの分析ワークフロー → Agent
  • プロンプト拡張・観点の定義 → Skill のまま

最終的な構成はこうなりました:

種別 役割
MCP Server 2個 外部API連携(GitLab、Backlog)
Agent 1個 MR分析・スキル評価
Skill 6個 レビュー観点、日報生成、要件定義支援など

2週間でこれだけ「自分の仕事の部品」が可視化・整理されたことになります。

一番驚いたこと

事前知識なしで整理が進んだ

一番ビビったのは、Claudeの機能について詳しくなくても、ここまで整理が進んだということです。

繰り返しになりますが正直、最初は「MCP」「Agent」「Skill」の違いなんてわかってません。

なんとなく「いろいろな機能があって、それぞれにベストプラクティスがあるんだろうな」ということだけは感覚的にわかっていたという程度です。

その感覚だけを頼りに「ベストプラクティスに沿ってるかチェックして」とお願いし続けていたら、自然と整理が進んでいった。

最近、巷で「ツール」「エージェント」「スキル」の役割分担の違いについて書かれている記事をよく見かけるようになりましたが、この2週間の経験で、その違いがすごくよくわかった手応えがあります。

理論から入らなくても、実践から入って後で整理されていく、という流れが自分には合っていた気がします。

なんというか、OJT感 がすごい。

「自分の仕事」が見える

さらに新鮮だったのは、AIに任せようとすることで、自分がやっていることが明確になるという逆説的な効果です。

普段の仕事って、無意識にやってることがすごく多い。

「コードレビューする」って言っても、実際に何を見てるかは言語化されてない。
「チケット確認する」って言っても、どういう順番で何をチェックしてるかは暗黙知になってる。

それを「Claudeにやってもらおう」とすると、言語化せざるを得ない。

で、言語化すると、自分の仕事の構造が見えてくる

例:コードレビュースキル

例えば、コードレビュースキルを例に出してみます。

最初のバージョン

最初に作ったときは、基本的な設計原則だけでした:

  • 単一責任原則(SRP)
  • 安定依存の原則
  • 情報隠蔽

「まあレビューってこういうこと見るよね」くらいの粒度。

ブラッシュアップ後

実際に使っていくうちに、観点が増えていきました:

  1. 要件との整合性 - そもそも要件を満たしてるか
  2. 既存コードの活用 - 車輪の再発明してないか
  3. テスト容易性 - テストしやすい構造か
  4. 設計原則 - SRP、安定依存、情報隠蔽
  5. 障害予防 - 過去のPostMortemベースのチェック

「あ、俺ってこういうことを気にしてレビューしてたんだ」という自己理解。

チームへの展開

で、これをスキルとして定義したことで、他のメンバーも同じ観点でレビューできるようになった

「和田さんはいつも何を見てレビューしてるんですか?」という質問に対して、「このスキル見て」と言えるようになった。

属人化の解消、という意味でもスキル化は効果があったと思います。


学習曲線

振り返ってみると、こういう進化をたどっていました:

Phase 1: 単発タスク依頼
  ↓
Phase 2: 繰り返しパターンの認識 → スキル化
  ↓
Phase 3: 実践で気づいた観点を追記 → ブラッシュアップ
  ↓
Phase 4: 肥大化への違和感 → 定期的なベストプラクティスチェック
  ↓
Phase 5: Claudeからの提案 → MCP/Agent/Skill の役割分担
  ↓
「業務の全体像が見える」

ポイントは、各フェーズで「こうすべき」という正解を知っていたわけではないということです。

  • スキル化したのは「チームに共有したい」という動機から
  • ブラッシュアップしたのは「使っていて足りない観点に気づいた」から
  • 整理を始めたのは「なんか肥大化してる気がする」という違和感から
  • MCP/Agent化したのは「Claudeに聞いたらそう言われた」から

事前に設計したわけではなく、使いながら自然とこうなっていった感じです。

今の状態

2週間で974回の会話、6つのスキル、2つのMCPサーバー、1つのAgent。

数字だけ見ると「めっちゃ使ってるな」という感じですが、体感としては仕事が楽になったというより仕事が見えるようになったという感覚のほうが強いです。

まあ楽にもなってるんですけど。日報が自動生成されるのは普通に助かるとか。

この経験を経て思うようになったのは、

「構えずに、このくらいの姿勢で使い続けると、誰でも業務の整理と効率化ができるんじゃない?」

ということです。

必要なのは、たぶんこれだけ:

  1. とりあえずClaude通して作業してみる
  2. 繰り返しに気づいたらスキル化してみる
  3. 使いながら書き足していく
  4. たまに「ベストプラクティスに沿ってる?」と聞いてみる
  5. 提案されたら素直に従ってみる

最初はわからなくていい。使っていくうちに、Claudeが教えてくれる。事前知識より、継続的に使い続ける姿勢のほうが大事だと思います。

おわりに

2週間前にこんな感じの記事が書けるとは全然思ってませんでした。

「便利なツールだな」くらいの認識で使い始めて、気づいたら自分の仕事が丸裸になりつつある。
まあ丸裸になったからといって、急に仕事ができるようになるわけではないんですが(身も蓋もない)。

ただ、「自分が何をやってるかわかってる状態」と「わかってない状態」では、改善のしやすさが全然違う気がしています。

そして何より、**「よくわからないけど使い続けていたら整理された」**という体験も面白い。

構えなくていい。詳しくなくていい。とりあえず使ってみて、たまに「これでいいの?」と聞いてみる。それだけで、仕事の解像度は上がっていく。

というわけで、この記事を見て誰かのトライが増えたらうれしいな、という気持ちでの投稿です。

引き続きジタバタしていきます。

おわり。

CM

こんな感じで一緒にAIいじりながらいろんなチャレンジをしてくれる方を、いえらぶは常に募集中です。一緒にメリメリプロダクト開発してみませんか。

新卒採用サイト:

学生向けのインターンシップもやってます:

105
48
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
105
48

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?