メインコンテンツへスキップ
このページは、既に Claude Code を使用しており、チームの採用を支援したいと考えている個別のエンジニア向けです。何を共有するか、受ける質問にどう答えるか、30 日間の実行計画、および一般的な懸念への対応について説明しています。 開発者ツールの採用は、ロールアウト発表によってはめったに起こりません。チームの誰かがそのツールをうまく使い始め、それについてオープンに話し、他の人が従いやすくすることで起こります。チャンピオンとして行う仕事はチームに不釣り合いな効果をもたらします。共有する例が多いほど、その後のエンジニアの学習曲線が短くなり、公開で答える質問が多いほど、1 人の経験がチーム全体が構築できるものになります。あなたはヘルプデスクではなく、チームの乗数として機能しており、このガイドはその条件下で役割を持続可能に保つために構成されています。

​
チャンピオンの役割

この役割は、互いに強化し合う 3 つの行動で構成されています。
行動実践ではどのように見えるかなぜ重要か
発見を共有する自分の仕事からのプロンプト、スクリーンショット、小さな成功をチームが既に読んでいる場所（エンジニアリングチャネル、スタンドアップスレッド、プルリクエストの説明など）に投稿します。自分のコードベースから引き出した例は、外部ドキュメントよりも説得力があります。同僚は、ツールが自分たちが共有する問題にどのように適用されるかを正確に見ることができるからです。
質問される人になる同僚が何かを達成した方法を尋ねるとき、実際に使用したプロンプトで応答して、自分のタスクに直接適用できるようにします。具体的で実行可能な例は、好奇心と最初の成功した使用の間のギャップを埋めます。これは、ほとんどの採用努力が停滞する場所です。
サークルを拡大する専用チャネルや週次スレッドなど、軽量で定期的な習慣を少数確立して、注意がよそにあるときでも勢いが続くようにします。1 人に依存する採用は脆弱です。共有された習慣によって行われる採用は、独自に複合し続けます。
これのほとんどは、既に行っている仕事の中に自然に適合します。違いは、発見がどこに投稿されるか、および答えがどのように伝わるかについて、少量の追加の意図です。

​
これにかかるコスト

自分自身とリーダーとの期待を設定します。以下のアクティビティは、通常の労働週の中に適合することを目的としており、役割は追加のサポート責任ではなく、既存の仕事の乗数のままである必要があります。
アクティビティ週あたりの時間ガイダンス
成功とプロンプトの投稿約 15 分スクリーンショットと 1 ～ 2 文で、その場で捉えます。正式な記事に変えることは避けてください。
共有チャネルで質問に答える約 20 分公開で 1 回答えて、質問が繰り返されるときはその答えにリンクバックします。
週次のショーアンドテルスレッドをホストする約 5 分開始プロンプトを投稿します。チームがコンテンツを提供します。
オプションのペアリングまたはウォークスルー0 ～ 30 分これを本当に行き詰まっている同僚のために予約し、時間をスケジュールする前に Quickstart リンクを提供します。

​
発見を共有する

自分の経験は、同僚が遭遇する最も説得力のある資料です。なぜなら、それはコードベース、ワークフロー、および共有する問題に固有だからです。ドキュメントは何が可能かを人々に伝えます。投稿は、実際に環境で機能しているものを示します。

​
共有する価値があるもの

最も有用な投稿は、既に完了している結果ではなく、同僚が明日再利用できる技術について説明しています。技術はチーム全体に広がるにつれて複合します。ステータス更新はそうではありません。 再利用可能な技術の例：
  • 「ディレクトリを @-mention することが機能することを学びました。@src/components/ を指して、どれがテストを欠いているかを尋ねたところ、見落としていた 2 つが浮かび上がりました。」
  • 「Plan mode（Shift+Tab）は、編集が行われる前に正確にどのファイルが変更されるかを示します。これが、共有コードで使用するのに快適な理由です。」
  • 「Stop hook を設定して、長いタスクが完了したときにデスクトップ通知を受け取るようにしました。設定はスレッドにあります。」
  • 「/init を実行すると、リポジトリから CLAUDE.md が生成されるため、アシスタントは規約について再度質問するのを停止します。」

​
どこで共有するか

チームが既に読んでいる場所に投稿します。目標は、目的地を作成するのではなく、通常の仕事の経路に例を配置することです。
場所最適な用途推奨形式
#claude-code または一般的なエンジニアリングチャネル発見、プロンプト、「今日学んだこと」の瞬間1 ～ 2 文のコンテキストを伴うスクリーンショット
プルリクエストの説明レビュアーが既に読んでいる実際のコードでアプローチを実証する「Claude と私はこのリファクタリングを行いました。アプローチについて説明するのに喜んでいます。」のような 1 行
スタンドアップまたは週次の書面による更新リーダーおよびスキップレベルマネージャーとの使用を正常化する1 つの具体的な結果を説明する 1 文
チームウィキまたは内部ドキュメント耐久性のあるパターン、カスタムスキル、および CLAUDE.md の例短いページ。チャネルトピックからリンクされているため、発見可能なままです

​
機能する形式

スクリーンショットに 1 行のコンテキストを伴う、または簡潔なビフォーアフター説明は、一般的に適切な詳細レベルです。各投稿を短く保ち、スクロール中の誰かでもポイントを吸収できるようにします。長い記事は後で保存されて忘れられる傾向がありますが、スクリーンショット付きの短い投稿はコピーされて試されます。 以下の例の投稿は、トーンと長さを示しています。逐語的にコピーするのではなく、適応させてください。 
ディレクトリを @-mention することが機能することを今日学びました。
@src/components/ を指して、どのコンポーネントがテストを欠いているかを尋ねたところ、
忘れていた 2 つが浮かび上がりました。

Stop hook を設定して、長いタスクが完了したときにデスクトップ通知を受け取るようにしました。
リファクタリングを開始し、立ち去り、完了したときに通知されました。
設定はスレッドにあります。

Plan mode は、重要なコードでこれを使用するのに快適な理由です。
Shift+Tab を「plan」が表示されるまで押します。
何かを変更する前に、正確にどのファイルに触れるつもりかを示します。

​
質問される人になる

いくつかの例を共有すると、質問が続きます。これはチャンピオンの役割が最大のレバレッジを持つ場所です。なぜなら、1 人への良い答えは、同じチャネルを見ている他の数人のブロックを解除することが多いからです。

​
説明ではなくプロンプトで答える

同僚が何かを達成した方法を尋ねるとき、最も有用な応答は、実際に使用したプロンプトです。説明を書くことができるよりも、自分の問題に対してそのプロンプトを実行することで、より多くを学び、すぐに行動できるものを与えます。 
同僚：それがレース条件を見つけるようにどのようにしましたか？

チャンピオン：「@tests/scheduler.test.ts のテストは不安定です。理由を把握してください」と尋ねました。
スケジューラーの 2 つの結合されていないプロミスをトレースしました。
テストで同じ表現を試してください。

​
ドキュメントではなく機能を指す

「Plan mode を試してください。Shift+Tab を押して、それが表示されるまで」のような応答は、その瞬間のドキュメントへのリンクよりも有用です。後で詳細が必要な場合、その人は自分で見つけます。今、彼らはブロックを解除する 1 つのことが必要です。

​
聞く可能性のある質問

質問推奨される応答フォローアップリソース
「最初に何を試すべきですか？」実際だが限定的なタスク、理想的には退屈だが難しくないため、その人が延期している bug または chore を推奨します。Common workflows
「コードを信頼するにはどうすればよいですか？」Plan mode を紹介します。Shift+Tab を押すと、それに切り替わり、Claude は変更する予定を正確に提案し、ユーザーが承認するまで何も変更されません。Permissions
「セットアップの価値はありますか？」インストールには約 2 分かかり、ターミナルで実行され、IDE 拡張機能は不要です。/init を 1 回実行するだけで、作業を開始するのに十分です。Quickstart
「不正な結果が生成されました。」失敗を Claude に戻すことを奨励します。エラーメッセージまたは失敗したテストを貼り付けることは、元のリクエストを言い換えるよりもはるかに効果的です。Common workflows
「コードベースの規約を理解していません。」/init を実行して CLAUDE.md ファイルを生成し、チームの規約、テストコマンド、および変更しないディレクトリを追加することを提案します。Memory
「これは単なるオートコンプリートですか？」Claude が不慣れなファイルを説明し、サービス全体でバグをトレースし、または移行計画を作成する簡潔なデモンストレーションを提供します。これらのタスクには、1 行を完成させるのではなく、リポジトリ全体の推論が必要です。2 分間のライブデモンストレーション
「セキュリティとデータ処理についてはどうですか？」この質問を管理者に参照してください。組織のデプロイメントとデータ処理ポリシーは既に設定されており、チャンピオンはこの答えを即興で行うべきではありません。Security · Data usage

​
サークルを拡大する

目標は、プログラムを構築することや、ロールアウトを所有することではありません。アクティブに駆動を停止した後でも、勢いが続くことを可能にする、軽量な習慣を少数確立することです。チャネルの質問があなた以外の人によって答えられているとき、役割はその仕事をしました。

​
機能する傾向があるパターン

パターン実行方法必要な労力
専用チャネル#claude-code チャネルを作成し（または既存のチャネルで定期的なスレッド）、Quickstart リンクと 1 つの強い例をピンで留め、公開で質問に答えて、各答えがすべての視聴者に利益をもたらすようにします。セットアップに約 5 分、その後は環境
週次のショーアンドテルスレッド毎週金曜日に「Claude は今週何を手伝いましたか？」と投稿します。準備、スライド、またはミーティングは不要です。スクリーンショットと短い説明で十分です。週あたり約 2 分
カスタムスキルを共有する最も有用な .claude/skills/<name>/SKILL.md ファイルを投稿します。例えば、コミット前にテストと lint を実行する /ship スキルと、1 行の説明。スキルはプレーン Markdown であるため、同僚はすぐに採用できます。スキルあたり約 5 分
自分の使用からセットアップガイドを生成する実際の時間を費やしたプロジェクトで /team-onboarding を実行します。Claude は最近のセッション、コマンド、MCP サーバーをスキャンし、新しいチームメイトが最初のメッセージとして貼り付けてセットアップを再生できるガイドを生成します。チャネルにピンで留めます。約 2 分
最初のタスクでペアリング開始している誰かに 1 つの 15 分間のペアリングセッションを提供します。自分のコードでの 1 つの成功した結果は、どのプレゼンテーションよりも説得力があります。1 人あたり約 15 分
次のチャンピオンを特定するあなたに最も多くの質問をする同僚は、通常、この役割を引き受ける準備ができています。このページを転送し、チャネルの責任を分割します。無視できる

​
30 日間の実行計画

緩い計画が役立つ場合、以下のシーケンスはほとんどのチーム全体で機能する傾向があるものを反映しています。コンテキストに合わせて自由に調整してください。
1

週 1：チャネルをシード化する

チャネルを作成し、Quickstart をピンで留め、プロンプトを含む 2 ～ 3 つの自分の例を投稿します。機能していることを示す信号： 数人の同僚が反応またはリプライし、少なくとも 1 つの質問がチャネルで尋ねられます。
2

週 2：リズムを開始する

週次のショーアンドテルスレッドを開始し、すべての質問に公開で答え、1 つのカスタムスキルまたは CLAUDE.md スニペットを共有します。機能していることを示す信号： あなた以外の誰かが自分の例を投稿します。
3

週 3：ペアリングと統合

2 ～ 3 つの短いペアリングセッションを提供し、最も一般的な質問と答えをピンで留めた FAQ メッセージに統合します。機能していることを示す信号： 繰り返し使用が見られ、同じ同僚が 1 回試して停止するのではなく、戻ってきます。
4

週 4：引き渡す

2 番目のチャンピオンを特定し、機能しているものと機能していないものについて、リーダーまたは管理者と簡潔な要約を共有します。機能していることを示す信号： チャネルの質問があなた以外の人によって答えられています。

​
誰かがより深く掘り下げたいとき

あなたはオンボーディングプログラムではなく、温かい紹介です。同僚が「これを試すべきか」から「これで効果的になるにはどうすればよいか」に進むとき、Quickstart および Common workflows ページを指してください。これらには、本当に有用だが、自分で発見するのが難しい機能をカバーする短いセクションが含まれています。

​
一般的な懸念に対応する

健全なスケプティシズムは予想されます。エンジニアは、コードに触れるツールについて慎重である必要があります。最も効果的な応答は、一般的なケースを議論することはめったにありません。代わりに、懸念を認め、簡潔な言い換えを提供し、その人のコードで 1 つの具体的なデモンストレーションを提案します。ほとんどの懸念は、1 つの成功した経験によって解決されます。
懸念推奨される応答提供する証拠
「それなしの方が速いです。」これは、その人が日常的に書くコードに対して真実である可能性があります。レガシーファイル、不慣れなサービス、またはテストスキャフォルディングなど、レバレッジが最も高い仕事で試すことを提案します。退屈なタスクを両方の方法で 1 回計時し、比較します。
「AI が本番コードに触れることを信頼していません。」変更が読まれずに着地しないことに同意します。Plan mode と通常の diff レビューを組み合わせることは、エンジニアが検査していない何かが適用されないことを意味し、プルリクエストと同じ標準です。実際のファイルで plan mode をデモンストレーションします。
「ジュニアエンジニアを弱くします。」うまく使用すれば、効果的な説明者です。ジュニアエンジニアに、何かを変更するよう求める前に、ファイルとその呼び出しサイトを説明するよう Claude に求めることを奨励します。「@file を説明し、どこから呼び出されるかを説明してください」を一緒に実行します。
「一度試したら、ハルシネーションしました。」これは通常、モデルの問題ではなく、コンテキストの問題です。関連ファイルを @-mention し、/init を実行し、実際のエラー出力を提供することで、通常、それが解決されます。適切な @ コンテキストで元のプロンプトを再実行します。
「別のツールを学ぶ時間がありません。」Claude Code はプラットフォームではなく、ターミナルコマンドです。最初のセッション内で値を返さない場合、それを脇に置くことは合理的です。2 分間のインストールに続いて 1 つの実際のバグ。

​
クイックリファレンスシート

以下の技術は、最初の試行から日常的な使用に誰かを移動させるのに最も確実に機能するものです。チャネルにこのテーブルをピンで留めるか、独自に共有してください。
技術適用方法
適切なコンテキストを提供する@file または @directory/ 参照を使用するか、エラーまたはログ出力を直接貼り付けます。関連するコンテキストを提供することは、精巧なプロンプトよりも効果的です。
編集前に計画を確認するShift+Tab を押して plan mode に入ります。Claude は実行前に意図した変更を説明し、承認を待ちます。
リポジトリに教える/init を実行して CLAUDE.md ファイルを生成し、規約、テストコマンド、および変更しないディレクトリを追加します。Memory を参照してください。
ワークフローを再利用する.claude/skills/<name>/ に SKILL.md ファイルを保存して、チーム全体が使用できる /name スキルを作成します。Skills を参照してください。
長いタスク中に情報を得るStop hook を設定して、長時間実行されるタスクが完了したときにデスクトップ通知を受け取ります。Hooks を参照してください。
不正な結果から回復するリクエストを言い換えるのではなく、失敗したテストまたはスタックトレースを Claude に貼り付けて、その特定の失敗に対処するよう求めます。
編集を外科的に保つdiff を求めるか、「X のみを変更する」と指定します。Claude はスコープが述べられるとスコープを尊重します。
Claude Code は頻繁に更新されます。このマテリアルを社内で配布する前に、ドキュメントホームページ に対してバージョン固有の詳細を確認してください。