新しい開発者ツールの導入は、ロールアウトのお知らせだけでは実現しません。チーム内の誰かがそのツールを上手に使い始め、それについてオープンに話し、他の人が簡単に従えるようにすることで初めて実現します。このキットは、そうした取り組みをサポートするために設計されており、それを第二の仕事に変えることはありません。すでに行っている可能性の高いことに形を与え、同僚に直接渡せる資料を提供します。
チャンピオンとして行う仕事は、不釣り合いな効果を持ちます。共有する例は、その後に続くエンジニアの学習曲線を短縮し、公開で答える質問はすべて、1人の経験をチーム全体が構築できるものに変えます。あなたはヘルプデスクではなく、チームの乗数として機能しており、このガイドはその条件下で役割を持続可能に保つために構成されています。
このガイドの使い方
チャンピオンの役割は、相互に強化される3つの行動で構成されています。発見したことを共有すること、人々が質問する人になること、そしてアクティブなユーザーの輪を広げることです。以下のセクションでは、それぞれについて順番に説明し、その後に30日間のプレイブック、一般的な懸念への対応ガイダンス、および誰にでも渡せるクイックリファレンスシートが続きます。
チームに合ったものを使用し、合わないものは脇に置いてください。ここにあるものは、完了することが期待されるチェックリストではなく、多くのエンジニアリング組織全体で機能してきたパターンのセットです。
フェーズ1：チャンピオンの役割
チャンピオンが行うこと
行動 | 実践ではどのように見えるか | なぜそれが重要なのか |
発見したことを共有する | 自分の仕事からのプロンプト、スクリーンショット、小さな成功を、チームがすでに読んでいる場所（エンジニアリングチャネル、スタンドアップスレッド、プルリクエストの説明など）に投稿します。 | 独自のコードベースから引き出された例は、外部ドキュメンテーションよりも説得力があります。同僚は、ツールが自分たちと共有する問題にどのように適用されるかを正確に見ることができるからです。 |
人々が質問する人になる | 同僚が何かを達成した方法を尋ねてきたら、使用した実際のプロンプトで応答して、自分のタスクに直接適用できるようにします。 | 具体的で実行可能な例は、好奇心と最初の成功した使用の間のギャップを取り除きます。これは、ほとんどの導入努力が停滞する場所です。 |
輪を広げる | 専用チャネルや週次スレッドなど、軽量で定期的な習慣を少数確立して、注意がよそにあるときでも勢いが続くようにします。 | 1人に依存する導入は脆弱です。共有された習慣によって行われる導入は、独自に複合し続けます。 |
これのほとんどは、すでに行っている仕事の中に自然に適合します。違いは、発見がどこに投稿されるか、そして答えがどのように伝わるかについて、少量の追加の意図です。
なぜこれが重要なのか
ツールは、信頼できる誰かがそれが努力する価値があることを示すときに、組織内に広がります。ドキュメンテーションは何が可能かを説明できますが、同じコードベース、同じワークフロー、同じ制約から引き出された同僚の例は、人々を好奇心から最初の試みに移します。独自の経験を見えるようにすることで、導入が停滞する最も一般的な理由を取り除きます。それは、どこから始めるかを知らないことです。
これがあなたにかかる費用
自分自身とリーダーとの期待を設定する価値があります。以下のアクティビティは、通常の労働週内に適合することを目的としており、役割は追加のサポート責任ではなく、既存の仕事の乗数のままである必要があります。
アクティビティ | 週あたりの時間 | ガイダンス |
成功とプロンプトの投稿 | 約15分 | スクリーンショットと1～2文で、その場で捉えてください。正式な記述に変えることは避けてください。 |
共有チャネルで質問に答える | 約20分 | 一度公開で答えてから、質問が繰り返されるときにその答えにリンク戻します。 |
週次のショーアンドテルスレッドをホストする | 約5分 | 開始プロンプトを投稿します。チームがコンテンツを提供します。 |
オプションのペアリングまたはウォークスルー | 0～30分 | これを本当に行き詰まっている同僚のために予約し、時間をスケジュールする前にクイックスタートリンクを提供してください。 |
フェーズ2：発見したことを共有する
独自の経験は、同僚が遭遇する最も説得力のある資料です。それはコードベース、ワークフロー、そしてあなたがすべて共有する問題に固有だからです。ドキュメンテーションは何が可能かを人々に伝えます。投稿は、実際に環境で機能しているものを示します。
共有する価値があるもの
最も有用な投稿は、同僚が明日再利用できる技術を説明しており、すでに完了している結果ではなく、説明しています。技術はチーム全体に広がるにつれて複合します。ステータス更新はそうではありません。
共有する価値がある（他の人が再利用できる技術） | あまり有用ではない（ステータス更新） |
「@-mentioningディレクトリが機能することを学びました。 | 「Claudeで支払いサービスを移行しました。」 |
「プランモード（Shift+Tab）は、編集が行われる前に正確にどのファイルが触れられるかを表示します。これが、共有コードで使用するのが快適な理由です。」 | 「このスプリントでClaudeのおかげで大幅に時間を節約できました。」 |
「長いタスクが完了したときにデスクトップ通知を受け取るようにStopフックを設定しました。設定はスレッドに記載されています。」 | 「今週は8つのチケットをクローズしました。」 |
「 | 「Claudeは本当に優れています。試してみるべきです。」 |
共有先
チームがすでに読んでいる場所に投稿してください。目標は新しい場所を作成するのではなく、通常の業務の流れの中に例を配置することです。
場所 | 最適な用途 | 推奨フォーマット |
| 発見、プロンプト、「今日学んだこと」の瞬間 | スクリーンショットと1～2文の背景説明 |
プルリクエストの説明 | レビュアーがすでに読んでいる実際のコードでアプローチを実演する | 「Claudeと一緒にこのリファクタリングを行いました。アプローチについて説明できます。」のような1行の説明 |
スタンドアップまたは週次の書面による更新 | リーダーおよびスキップレベルマネージャーとの使用を標準化する | 1つの具体的な成果を説明する1文 |
チームウィキまたは内部ドキュメント | 永続的なパターン、カスタムスキル、 | チャネルトピックからリンクされた短いページで、検出可能な状態を保つ |
機能するフォーマット
スクリーンショットと1行の背景説明、または簡潔なビフォーアフター説明が、一般的に適切な詳細度です。各投稿は短く保ち、スクロール中の人でも要点を理解できるようにしてください。長い記事は後で読むために保存され、忘れられることが多いのに対し、スクリーンショット付きの短い投稿はコピーされて試されることが多いです。
投稿例
以下は、逐語的にコピーするテンプレートではなく、トーンと長さの例です。
ディレクトリに@メンションできることを今日学びました。@src/components/を指定して、どのコンポーネントがテストを欠いているかを尋ねたところ、忘れていた2つが見つかりました。
長いタスクが完了したときにデスクトップ通知を受け取るようにStopフックを設定しました。リファクタリングを開始して立ち去り、完了したときに通知を受け取りました。設定はスレッドに記載されています。
プランモードは、重要なコードでこれを使用することに安心できる理由です。Shift+Tabを押して「plan」が表示されるまで進むと、変更前に正確にどのファイルに触れるつもりかが表示されます。
フェーズ3：人々が質問する人になる
いくつかの例を共有すると、質問が続きます。これはチャンピオンの役割が最大のレバレッジを持つ場所です。なぜなら、1人への良い回答は、同じチャネルを見ている他の数人のブロックを解除することが多いからです。
説明ではなくプロンプトで答える
同僚が何かをどのように達成したかを尋ねるとき、最も有用な応答は実際に使用したプロンプトです。彼らは、あなたが書くことができるどんな説明よりも、そのプロンプトを自分の問題に対して実行することからより多くを学び、すぐに行動できるものを与えます。
同僚： どのようにしてそのレース条件を見つけましたか？
チャンピオン： 「@tests/scheduler.test.tsのテストは不安定です。理由を調べてください」と尋ねたところ、スケジューラー内の2つの結合されていないプロミスをトレースしました。同じ表現をあなたのテストで試してください。
ドキュメントではなく機能を指す
「プランモードを試してください。Shift+Tabを押して表示されるまで進んでください」という応答は、ドキュメントへのリンクよりも現在の瞬間に有用です。その人が後で詳細が必要な場合、彼らは自分で見つけるでしょう。今、彼らは彼らのブロックを解除する1つのことが必要です。
聞かれる可能性が高い質問
以下の表は、チャンピオンが最も頻繁に尋ねられる質問、推奨される応答、およびその人がより詳細に準備ができているときに提供するリソースをカバーしています。
聞かれる可能性が高い質問 | 推奨される応答 | フォローアップリソース |
「最初に何を試すべきですか？」 | 実際だが限定的なタスク（理想的には、難しいのではなく退屈だから延期している不具合または雑務）を推奨してください。 | |
「コードを信頼するにはどうすればよいですか？」 | プランモードを紹介します。Shift+Tabを押すとそれに切り替わり、Claudeは変更する予定を正確に提案し、ユーザーが承認するまで何も変更されません。 | |
「セットアップの価値はありますか？」 | インストールには約2分かかり、ターミナルで実行され、IDEエクステンションは不要です。 | |
「不正な結果が生成されました。」 | エラーメッセージまたは失敗したテストをClaudeに返すよう促してください。元のリクエストを言い換えるよりも、エラーメッセージやテスト結果を貼り付ける方がはるかに効果的です。 | |
「私たちのコードベースの規約を理解していません。」 |
| |
「これは単なるオートコンプリートですか？」 | Claudeが不慣れなファイルを説明したり、サービス全体のバグを追跡したり、マイグレーション計画を作成したりする簡単なデモンストレーションを提供してください。これらは単一行を完成させるのではなく、リポジトリ全体で推論が必要なタスクです。 | 2分間のライブデモンストレーション |
「セキュリティとデータ処理についてはどうですか？」 | この質問は管理者に相談してください。組織のデプロイメントとデータ処理ポリシーは既に設定されており、チャンピオンはこの回答を即興で行うべきではありません。 |
フェーズ4：サークルを拡大する
目的はプログラムを構築することでも、ロールアウトを所有することでもありません。あなたが積極的に推進を停止した後も勢いが続くようにする、少数の軽量な習慣を確立することです。チャネル内の質問があなた以外の人によって答えられている場合、このロールは役割を果たしています。
機能する傾向があるパターン
パターン | 実行方法 | 必要な労力 |
専用チャネル |
| セットアップに約5分、その後は環境的 |
週間ショーアンドテルスレッド | 毎週金曜日に「今週Claudeはあなたを何で手伝いましたか？」と投稿してください。準備、スライド、またはミーティングは必要ありません。スクリーンショットと短い説明で十分です。 | 週に約2分 |
カスタムスキルを共有する | 最も有用な | スキルあたり約5分 |
最初のタスクでペアリングする | 開始する人に対して、単一の15分間のペアリングセッションを提供してください。自分のコードで1つの成功した結果は、どんなプレゼンテーションよりも説得力があります。 | 1人あたり約15分 |
次のチャンピオンを特定する | あなたに最も多くの質問をする同僚は、通常このロールを引き受ける準備ができています。彼らにこのキットを転送し、チャネルの責任を分割してください。 | 無視できる程度 |
30日間のプレイブック
ゆるい計画が役に立つ場合、以下のシーケンスはほとんどのチームで機能する傾向があるものを反映しています。コンテキストに合わせて自由に調整してください。
週 | 推奨アクティビティ | それが機能しているというシグナル |
第1週 | チャネルを作成し、クイックスタートをピンで留め、プロンプトを含む2～3個の独自の例を投稿してください。 | 数人の同僚が反応または返信し、チャネルで少なくとも1つの質問が尋ねられます。 |
第2週 | 週間ショーアンドテルスレッドを開始し、すべての質問に公開で答え、1つのカスタムスキルまたは | あなた以外の誰かが自分の例を投稿します。 |
第3週 | 2～3回の短いペアリングセッションを提供し、最も一般的な質問と回答をピンで留めたFAQメッセージに統合してください。 | 繰り返しの使用が見られます。同じ同僚が何度も戻ってくるのではなく、1回試して停止します。 |
第4週 | 2番目のチャンピオンを特定し、機能しているものと機能していないものについて、リーダーまたは管理者と簡潔なサマリーを共有してください。 | チャネル内の質問は、あなた以外の人によって回答されています。 |
誰かがより深く掘り下げたいとき
あなたはオンボーディングプログラムではなく、温かみのある導入役です。同僚が「これを試すべきか」から「これを効果的に使うにはどうすればいいか」へと進んだら、公式のクイックスタートと一般的なワークフローページに誘導してください。これらのページには、本当に役立つが自分で発見するのが難しい機能をカバーする短いセクションが含まれています。
フェーズ5：一般的な懸念への対応
健全な懐疑心は予想されるべきものです。エンジニアは新しいツールについて慎重であるべきです。最も効果的な対応は、一般的なケースを議論することはめったにありません。代わりに、懸念を認め、簡潔な再構成を提供し、その人自身のコード上で1つの具体的なデモンストレーションを提案してください。ほとんどの懸念は、1回の成功した経験で解決されます。
懸念 | 推奨される対応 | 提供する証拠 |
「それなしの方が速いです。」 | それはその人が日常的に書くコードについては可能性が高いです。避ける傾向のある作業（レガシーファイル、不慣れなサービス、またはテストスキャフォルディング）で試してみることをお勧めします。そこではレバレッジが最も高いです。 | 退屈なタスクを両方の方法で計時して比較してください。 |
「AIが本番コードに触れることを信頼していません。」 | 変更は読まれずに適用されるべきではないことに同意してください。プランモードと通常のdiffレビューを組み合わせることで、エンジニアが検査していないものは何も適用されません。これはプルリクエストと同じ基準です。 | 実際のファイルでプランモードをデモンストレーションしてください。 |
「これはジュニアエンジニアを弱くするでしょう。」 | 適切に使用すれば、それは効果的な説明者です。ジュニアエンジニアに、何かを変更するよう求める前に、ファイルとそのコールサイトを説明するようClaudeに求めることをお勧めします。 | 「@ファイルを説明し、どこから呼び出されているか」を一緒に実行してください。 |
「一度試してみたら、それが幻覚を見ました。」 | これは通常、モデルの問題ではなくコンテキストの問題です。関連ファイルを@メンションし、 | 適切な@コンテキストで元のプロンプトを再実行してください。 |
「別のツールを学ぶ時間がありません。」 | Claude Codeはプラットフォームではなくターミナルコマンドです。最初のセッション内で価値を返さない場合、それを脇に置くことは合理的です。 | 2分のインストールに続いて1つの実際のバグ。 |
付録：クイックリファレンスシート
以下の技術は、誰かを最初の試行から日常的な使用に移す最も確実な方法です。このテーブルはチャネルにピン留めするか、単独で共有することを目的としています。
技術 | 適用方法 |
適切なコンテキストを提供する |
|
編集前にプランを確認する | Shift+Tabを押してプランモードに入ります。Claudeは実行前に承認のための意図された変更を説明します。 |
リポジトリを教える |
|
ワークフローを再利用する |
|
長いタスク中に情報を得る | ストップフックを設定して、長時間実行されるタスクが完了したときにデスクトップ通知を受け取ります。 |
不正な結果から回復する | リクエストを言い換えるのではなく、失敗したテストまたはスタックトレースをClaudeに貼り付け直し、その特定の失敗に対処するよう求めてください。 |
編集を正確に保つ | diffを求めるか、「Xのみを変更する」と指定してください。Claudeはスコープが述べられているときにスコープを尊重します。 |
付録：リソースディレクトリ
リソース | リンク |
クイックスタート | |
一般的なワークフロー | |
スキル | |
Anthropic Academy | |
Claude Code の完全なドキュメント |
このロールを引き受けていただきありがとうございます。人々は信頼できる誰かがそれが努力する価値があることを示したときに新しいツールを採用します。それがあなたが行っている貢献です。Claude Code は頻繁に更新されます。このマテリアルを社内で配布する前に、code.claude.com/docs でバージョン固有の詳細を確認してください。