github-profile-optimization

GitHub プロフィールの最適化

開発者がトーク、パッケージ一覧、検索結果、求人情報を見たあとにアクセスするページがあります。プロジェクトの関係者が実在するかどうかを評価者が判断するために開くページです。あなたの仕事は、根拠に照らしてそのページを診断し、オーナーが明言する単一の成果を中心に再構築することです。

すべての判断の軸となる制約が2つあります。

• アカウントが編集できるのはプロフィール README と6つのピン留め項目だけです。ページ上のそれ以外の要素（スター、言語、コントリビューショングラフ）は自動生成されるため、異議を唱えることはできません。
• 自動生成される要素は、肯定にも否定にも弱い根拠です。フォーク、デフォルト以外のブランチ、リンクされていないコミットメールアドレスはグラフに反映されないため、多くの貢献をしている人が活動していないように見えたり、わずかな貢献しかしていない人が活発に見えたりすることがあります。

約束する内容を慎重に見極める

この分野のアドバイスの多くは、ツールや講座を販売しようとする人によるもので、独立した根拠は彼らが示唆するほど豊富ではありません。数値を引用したり、成果を予測したりする前に、./references/published-findings.md を読んでください。ここで確認できるのは次の点です。

• プロフィールは発見の場ではなく、検証の場です。プロフィールを開くレビュアーは、すでに関心を持っており、別の場所での主張に裏付けがあるかを確認します。最も確かなシグナルは、プロフィール README が登場するよりずっと前に行われた面接調査から得られたものです。それは、実際の活動履歴と、ほかの人がすでに利用しているプロジェクトでの仕事です。情報の少ないプロフィールは、どちらの方向についてもレビュアーに何も伝えません。
• ここに示す基準値はすべて独自に設定したものです。 プロフィールの改善に関する公開済みの評価基準、頻度、ベンチマークは存在しないため、以下の合格基準は根拠ファイルでそのように明記した暫定的なデフォルトです。業界標準ではなく、オーナーが変更できるデフォルトとして提示してください。
• 検証済みのフレームワークも存在しません。 使われている造語の略語は1つありますが、提唱した記事以外では採用されていません。繰り返し使ったり、別の略語を作ったりしないでください。以下のオーディエンスに関する質問とスコアカードで、フレームワークが担うとされる役割は果たせます。

この作業で実際に得られるものを約束してください。つまり、オーナーのほかの資料との矛盾をなくし、訪問者を意図的に誘導するページです。面接、スター、登録を約束しないでください。プロフィールを書き換えることでそのいずれかが増えるかを測定した調査はありません。また、対象範囲にも注意してください。ここで扱う公開済みの根拠は英語圏、とりわけ米国に偏っています。オーナーの採用市場や事業展開地域が別の場所なら、その点を伝えてください。

プロフィールの領域に専念してください。ユーザーが実際に抱えている問題が次のいずれかなら、プロフィールに無理をさせるのではなく、関連するスキルに案内してください。

• 単一リポジトリの README：samber/developer-relations-skills@readme-optimization
• リリース告知：samber/developer-relations-skills@oss-launch
• 継続的なチャネル展開：samber/developer-relations-skills@oss-distribution-strategy
• 初回貢献までの導線：samber/developer-relations-skills@oss-contributor-onboarding
• スポンサーシップの段階設定と資金調達目標：samber/developer-relations-skills@oss-sponsors-fundraising
• キャリアの位置付け、面接、昇進：samber/developer-relations-skills@devrel-career

よくある依頼：「GitHub プロフィールを監査して」「組織のプロフィール README を書き直して」「ピン留めすべき6つのリポジトリはどれ？」「毎週リリースしているのに、GitHub が放置されているように見える」「カンファレンスの主催者にも読みやすいプロフィールにして」。

書き直しではなく、依頼を別の方向へ案内すべき場合もあります。「スターを増やして」と「コントリビューショングラフを埋めて」は根拠を捏造する依頼であり、「プロフィールのランキングを上げて」はプラットフォームに存在しない手段を求める依頼です。どれに当たるのかを伝え、重要なレビュアーの前でどのような代償を伴うかを説明し、代わりに監査を提案してください。依頼そのものが不適切でも、その根底にある目標はたいてい正当です。

インタビュー

一度に質問するのは一つだけにし、可能な場合は選択肢を提示してください。監査結果から自分で判断できることは省略してください。質問1〜4は書き換えを始める条件です。回答を得る前に文章案を作成しないでください。

メモリ：現在のタスクやプロジェクトの背景情報をいくつか保存します。メモリをファイルに保存する場合は、devrel-context.mdを使用してください。別のメモリシステムを使用している場合は、そちらを利用してください。タスク情報はセクションを分けて記録してください。完了したタスクは削除してください。タスクには日付を追加し、一般的なプロジェクトの背景情報には日付を付けないでください。タスクによっては、インタビューの回答が異なる場合があります。

1. どのアカウントですか。また、個人プロフィールですか、それとも組織アカウントですか？
2. 導入後のメンテナンスやコントリビューターの獲得を担うメンテナーですか、開発者への認知向上を目指す企業ですか、それとも採用時にプロフィールを精査されるエンジニアですか？以降のすべての進め方は、この回答によって変わります。
3. このページによって、最も増やしたい成果は何ですか？プロジェクトの導入、コントリビューター、企業からの問い合わせ、講演やコラボレーションの依頼、仕事やクライアントの紹介、スポンサーシップのいずれですか？
4. 主にどのような人がこのページにたどり着きますか？リポジトリやパッケージのページから来た開発者、講演や記事から来た開発者、採用担当者やリクルーター、またはツールを支えるチームを評価する企業の担当者ですか？
5. 個人による導入と企業による導入のどちらを想定していますか？単独で判断する開発者は機能を重視し、チームは保守状況、ライセンス、問題発生時の連絡先を重視します。両方でもかまいません。
6. 読者が次に何をできるようにする必要がありますか？特定のリポジトリを開く、ドキュメントを読む、コミュニティに参加する、面談を予約する、またはあなたに連絡する、のどれですか？
7. 現在の活動状況について、実際のところどうですか？毎週リリースしている、メンテナンスを続けている、プロジェクトの合間にいる、または休止中ですか？
8. ページ上に、気に入っていて変更したくないものはありますか？
9. 組織の場合、どの部分がオープンソースで、どの部分が商用ですか？それを明記しますか？
10. 今日以降、このページの管理責任者は誰ですか？また、次回の見直しのきっかけとなる出来事は何ですか？
11. この内容を整える期限はありますか？リリース、講演、資金調達、採用面接などに合わせる必要がありますか？それとも、単に後回しになっているだけですか？
12. 期限に向けて一度だけ整えますか？それとも、今後何年も使える位置づけの文章と見直しの習慣を作り、ページを継続的に機能させますか？
13. 使えるリソースの上限はどの程度ですか？半日、誰かの作業時間を1週間、常任の担当者、または公開情報についての法務やマーケティングの承認が必要ですか？

質問10は事務的なものではありません。担当者のいないプロフィールには、書いた当時は正しかった主張が残り続けます。古くなった主張は、空のページよりも信頼を損ないます。

質問11〜13の回答に応じて、ステップ2で修正の優先順位を組み替えてください。提示する際は、どの回答によってどの修正の優先順位が変わったかを伝えてください。

• 期限が明確な場合は、ほぼコストのかからない修正を優先し、今回の作業ではページ全体の再構築を見送ります。
• 継続的に成果を積み上げる方針の場合は、位置づけの文章を優先します。この文章は自己紹介、組織のタグライン、すべてのリンクのプレビューに反映されます。また、費用対効果を理由に後回しにされがちな見直しの習慣も優先します。
• 上限があり、常任の担当者もいない場合は、見直しの習慣を将来の作業として記録するのではなく、完全に削除します。

質問2の答えが採用関連の場合は、多くの作業を勧める前に、対象となる企業を確認してください。この分野で調査方法が公開されている唯一の調査（2018年のもので、古い情報として扱ってください）では、ポートフォリオの比重は小規模企業や創業者主導の企業に偏っていました。また、記録に残るリクルーターの見解は、プロフィールの見栄えに対して概ね無関心です。

大企業への就職を目指す候補者は、まず履歴書に取り組み、プロフィールは履歴書と矛盾しないようにするだけにとどめるべきです。対象者別に段階を踏んだガイダンスは、./references/published-findings.mdにあります。

ステップ 1 - 事実を集める

優れたプロフィールがどのようなものか、記憶だけを頼りに監査してはいけません。

1. プロフィールが GitHub にあり、コマンドを実行してネットワークに接続できる場合は、scripts/profile-audit.py <account> を実行します。このスクリプトは GitHub 独自の REST API と GraphQL API を呼び出します。GitLab、Codeberg、セルフホスト型フォージに相当するものはありません。プロフィールの各項目が制限に収まっているか、プロフィールの README が表示されるか、どこに置かれているか、単語・リンク・画像の数、サードパーティ製ウィジェット、期間に依存する表現、ピン留めが設定されていない場合に訪問者が見つけるリポジトリを報告します。ピン留め項目も含め、レート制限を引き上げるには GITHUB_TOKEN を設定します。それ以外のホストでは、プロフィールページ自体を確認し、同じチェックリストを手動で適用します。
2. スクリプトを実行できない場合は、自分でプロフィールページを開きます（ページを閲覧するか、ユーザーに README とピン留め項目の一覧を貼り付けてもらいます）。確認できなかった事実は、憶測で補わず、はっきり伝えます。
3. ページ上のリンクをすべて開き、リンク切れを記録します。リンク切れがあるとブロッキングチェックに失敗し、修正には数分しかかかりません。
4. ピン留めされたリポジトリを、初めて見る人の目線で確認します。それぞれに説明、トピック、最近のプッシュはありますか？
5. 環境に永続的なメモリがある場合は、このアカウントについて保存されているポジショニングステートメント、対象読者の定義、競合リストを読み込み、改めて導き出すのではなく再利用します。

スクリプトが報告するのは事実であり、評価ではありません。画像が15枚あるからといって、自動的に問題になるわけではありません。検討すべき点です。

ステップ 2 - ページを採点する

./references/profile-scorecard.md に沿って確認し、そのレポート形式を一字一句そのまま使ってください。ブロッキングチェックが4項目、各2点の採点項目が8項目、その後に以下の修正順が続きます。

各行に、引用文、項目の値、スクリプトの出力行などの根拠を添えます。書き換えに進む前にスコアを提示し、オーナーの同意を得ます。雇用主のポリシーや意図的なミニマリズムなど、外部からは把握できない制約があれば、0点としたチェックを正当化できることがあります。オーナーの判断が正しい場合もあります。

スコアを提示する際、チェック項目と合格点は公開された基準ではなく、このスキル独自のベースラインであることを一度だけ伝えます。理由があって基準を変えるオーナーは、監査に失敗しているわけではありません。ページをそのままにしておくほうが楽だからという理由で基準を変えるオーナーは、監査に失敗しています。

修正の優先順位

各修正にかかる時間あたりの効果で修正リストに順位を付けてください。解消するダメージの大きさや、完了までの速さではありません。3つの順位付けは一致しないため、それぞれを示し、最後のものを先にしてください。

• 労力の少ない順：false claims == render prerequisites > private-contribution toggle > pins > positioning sentence > page rebuild > review habit
• 効果の高い順：false claims > positioning sentence > pins > page rebuild > render prerequisites > review habit > private-contribution toggle
• 効率の高い順、つまり最初に実施するもの：false claims == render prerequisites > pins > positioning sentence > private-contribution toggle > page rebuild > review habit

誤った主張の削除と表示の修復は、どちらの軸でも同率になるため、効率でも同率です。どちらも数分で済み、どちらも問題を引き起こしており、単に弱いだけではなく、ページを「誤った」状態にしています。読者は、どちらの種類の壊れたページも評価できません。非公開コントリビューションの切り替えは、ほとんど手間がかからない割に順位が低めです。公開グラフが実際の非公開作業を正しく反映していない特定のアカウントにしか効果がなく、ほかのアカウントには何も変化をもたらさないためです。

基本的には上位3項目を実施し、それぞれの間に半日ほど空けてください。アカウントの所有者がすでにアカウントの目的を説明できる場合は、ポジショニングの文に進みます。コールドリーダーテストで、上位の項目では対処できない質問への回答が得られなかった場合にのみ、ページを作り直してください。

この順序で後回しになるのが、レビューの習慣です。数分で終わる修正に対して、継続的に取り組まなければならないため、毎回順位が下がります。しかし、ページが再び誤った状態になるのを防ぐ唯一の項目であり、このスキル全体で最も大きな損失とみなしている問題を防ぎます。

次の場合は、これをほかのすべてより優先してください。

• 質問7の回答が「毎週リリースする」である場合、またはアカウントが組織のものである場合。ページが最も早く古くなり、しかも誰にも気付かれないためです。
• 同じアカウントの監査が2回目である場合。

この順位付けは基本形であり、絶対的な決まりではありません。実施する人によって変わります。すでに分かっていることに照らして順位を付け直してください。

• ローンチや講演ですでにポジショニングの文を用意している所有者なら、その項目はほぼ手間をかけずに済むため、最初に実施してください。
• ピン留め項目をすでに意図的に選んでいるアカウントなら、その項目は再検討せず、リストから外してください。

回答13の上限ルールに抵触する修正は、最後に挙げるのではなく、すべて削除してください。マーケティング部門の承認を得られない組織では、「商業的な内容であることを明記する」という項目を計画の末尾に置くのではなく、その項目を削除し、理由を記録します。

ステップ3 - 弱い部分の改善より先に、誤りを修正する

これらは修正の優先順位の最上位であり、比率を重視した結果としてその位置にあります。各項目は数分で済み、単に弱いだけではなく、ページを明らかに誤った状態にしているものを取り除くからです。

1. 読者が誤りだと確認できる主張をすべて削除または更新します。アーカイブ済みなのに「現在開発中」としているプロジェクト、以前の勤務先、無効なリンク、古くなった役職などが該当します。
2. 表示を壊しているものを修復します。プロフィールの README が表示されるために必要な4つの前提条件と、組織での同等の条件については、./references/platform-mechanics.md を参照してください。
3. 期限付きの古い文は、日付を明記した文に置き換えるか、削除します。日付のない「現在 X を検討中」という文は、誰も更新しないまま、今日の状況について主張していることになります。

その後で初めて、ポジショニングと構成に進みます。

ステップ4 - 書き始める前にポジショニングの案を出す

最初に思い付いた表現に飛びつかないでください。異なる切り口でポジショニングの候補文を3つ作成します。具体的に何を作るのか、読者にとってどのような問題を取り除くのか、読者が何をしなくてよくなるのか、という切り口です。それぞれのトレードオフと推奨案を添えて提示し、所有者に選んでもらいます。

この文は自己紹介文、組織のタグライン、リンクのプレビュー、検索結果にまで反映されるため、時間をかけて見直す価値があります。各候補に対して、次の質問で確認してください。他社のアカウントが、この文をそのまま貼り付けても違和感がないでしょうか。そうなら、その文には何も伝えるものがありません。

Step 5 - ページを再構築する

読者が何を判断しているかに合ったスケルトンを./references/profile-skeletons.mdから選びます。対象は、メンテナー、DevRel の実務担当者、信頼性の構築に取り組むエンジニア、または組織です。セクションを一つずつ下書きし、次に進む前に合意を得ます。一度に書き換えたプロフィールは、一度に却下されます。

最初の画面を過ぎると、導入に至る流れは二つに分かれるため、それに合わせて調整します。

	個人の開発者が単独で導入する場合	チームまたは企業が導入する場合
主な疑問	必要なものをこの人は作れるか？	何に依存することになり、問題が起きたとき誰が対応するのか？
早い段階で示すこと	実際に動作する成果物と、その入口	ライセンス方針、メンテナンス頻度、サポートとセキュリティの窓口
効果的な証拠	マージ済みのプルリクエスト、デモ、読みやすいコードベース	ユーザーの明示、リリース頻度、資金調達モデル、チームの活動状況
致命的な欠落	最初に見るべきリポジトリが明確でない	「誰がメンテナンスしているのか」への回答がない

最初の画面はどちらの場合も同じです。誰なのか、何を作っているのか、最初に開くべきプロジェクトはどれかを示します。上部を二度書き換えるのではなく、下のほうに短い評価用のセクションを追加して、両方の読者に応えます。

すべてのスケルトンに適用されるルール：

1. すべての画像、バッジ、ウィジェットの上に、説明文を一文置きます。
2. 装飾的な要素は3つまでに制限し、それぞれに代替テキストを付け、掲載する価値があるものを選びます。サードパーティの統計や連続記録カードは外部依存であり、ホスト側の画像プロキシが古い状態をいつまでもキャッシュする可能性があります。更新が止まったウィジェットは、何も置かないより悪いものです。
3. 当てはまらないことも明記します。メンテナンスしていないもの、商用のもの、機能リクエストを受け付けないものです。これはページ上で最も信頼につながる内容であり、1行あれば伝えられます。
4. ピン留めする各リポジトリには、ピン留めする前に説明とトピックを設定します。何も説明のないピンは、6つの枠のうち1つを無駄にします。このスキルで求めるのは、それらが設定されていることだけです。効果的な書き方については、samber/developer-relations-skills@readme-optimization の「家具」のステップを参照してください。
5. レンダリング後に HTML が取り除かれても読めるページにします。色だけで意味を伝えたり、画像の中だけに説明を置いたりしないでください。

完成した文章を、お好みのヒューマナイザーのスキルに通します。生成文のように読めるプロフィール文は、ページの目的である信頼性を損ないます。

Step 6 - ピン留めを慎重に選ぶ

6つのピン（公開用に6つ、組織の場合はメンバーに表示されるものも6つ）は、訪問者が次にクリックするものを左右できる唯一の設定です。スター数ではなく、質問3で定めた目標に基づいて選びます。

次の4つのセットに順位をつけてはいけません。質問3の回答によってどれか一つが選ばれ、どのピンの設定にもコストはかからないため、セット間に効率の順番をつければ、根拠のない精密さを装うことになります。一方、各セット内の順番は重要です。訪問者が最初に開くリポジトリが決まるからです。

• 導入：まず旗艦プロジェクトを置き、次に新規ユーザーが必要とする SDK またはインテグレーションを置きます。
• コントリビューター：適切な「good first issue」が選定されているリポジトリを置き、次にコントリビューター向けドキュメントが最も充実したリポジトリを置きます。
• 信頼性または採用：スター数が少なくても、判断力が伝わる成果物を置きます。よくレビューされたツールは、リンクを並べた人気リストより効果的です。
• 組織：ランキングではなく、入口となる案内を示します。README の文章ですでに紹介されているもの以外のリポジトリも含め、ページ上の二つの情報を合わせて、より全体像が伝わるようにします。

アーカイブ済みのリポジトリ、大幅に変更していないフォーク、空のプレースホルダーは決してピン留めしないでください。ピン留めを設定しないままにするほうがよくありません。プラットフォームが自動で「人気のリポジトリ」を選び、放置されたものが表示されることがよくあります。

ステップ 7 - 貢献を示すシグナルには誠実に対応する

グラフや実績についてコメントする前に、./references/platform-mechanics.mdを読んでください。

誠実な対応は3つあり、効果には桁違いの差があります。

• 効率のよい順に、まず実施します：private-contribution toggle > mechanical graph causes > merged pull requests elsewhere

• 在職中の開発者のグラフがほとんど動いていないように見える場合は、まずプライベートコントリビューションの表示切り替えを検討してください。設定を1つ変えるだけで、その人の作業の大半はプライベートなものです。つまり、ここで「新しさ」をもたらすのは新たな公開作業ではなく、設定です。

• 次に、グラフが実態より空に見えてしまう機械的な原因を解消します。コミットのメールアドレスがアカウントに紐づいていない、作業が常にフィーチャーブランチにしか反映されない、フォークでの貢献が上流にマージされていない、といった原因です。診断に1時間かけ、その後は習慣として維持します。

• この順番では、他者のリポジトリにマージされたプルリクエストは後回しになります。実作業の4分の1を占めるため、費用対効果では優先されません。それでも、このスキル全体で最も根拠の確かなシグナルです。面接調査では、レビュアーはページ上のほかの何よりも、すでに他者が利用しているプロジェクトでの作業を重視しています。質問3の答えが信頼性、採用、またはコラボレーションの誘いに関するものであれば、最優先にしてください。そこで代わりになる、もっと手軽な方法はありません。また、グラフでは確認できないことも、プルリクエストなら確認できます。

• コミット数の水増し、連続記録の稼ぎ、スターの購入、実績の不正操作は絶対に勧めないでください。この分野をよく知るレビュアーは、すでにどのシグナルも割り引いて評価します。

  • コミットの日時を遡らせるのに必要なのは、環境変数を1つ設定するだけです。
  • 公開ツールを使えば、グラフに任意の絵を描けます。
  • スターの不正行為は産業規模で行われています。公開イベントデータを5年半にわたって調査した研究では、1万8千を超えるリポジトリで、約600万件の偽装が疑われるスターが数えられました。

• オーナーからこうした依頼があった場合は、その名前を挙げて断ってください。その手法が何であるか、レビュアーがそれを割り引いて評価すること、そして代わりに何をするかを伝えます。こうした手法は選択肢から削除するものであり、最下位に順位づけするものではありません。計画の最下部に置いた手法は、スコープとして再び持ち出され、この手法は捏造した証拠として戻ってきます。

• 連続記録やトロフィーのウィジェットは、中立的な装飾ではなく、信頼性とのトレードオフとして扱ってください。上級技術レビュアーにはノイズと受け取られ、プライベートな作業はまったく表示されません。

ステップ 8 - 検証し、維持する

1. スコアカードを再実施します。4つの必須チェックすべてに合格し、合計スコアが13/16に達したら公開します。これはこのスキル独自のベースラインであり、公表された基準ではありません。未達の場合は、注意書きを添えて公開するのではなく、改善を繰り返してください。
2. スコアカードのコールドリーダーテストを実施します。ページを45秒間読んでもらい、その後4つの質問（組織の場合は5つ）をします。すべての答えが正解なら合格です。つまり、4問中4問、組織の場合は5問中5問正解が必要です。人に頼めない場合は、そのアカウントについて事前知識のない新しいエージェントセッションで代用できますが、自分で読み返すだけでは不十分です。
3. オーナーと、次回レビューのきっかけとなるイベントを記録します。たとえば、ローンチ、講演、資金調達ラウンド、大規模リリース、役割の変更、求職活動です。定期的なカレンダー設定を裏づける根拠はなく、誰も守らない四半期ごとのリマインダーより、オーナーが心当たりのあるイベントのリストのほうが有用です。ほかに記録方法がない場合は、そのリストと最終レビュー日をファイル内のコメントとして残してください。
4. 環境に永続メモリがある場合は、合意したポジショニング文、対象読者、目標、最終スコアを保存し、ローンチ告知、カンファレンスの紹介文、ドキュメントのランディングページが同じ言葉から始まるようにしてください。

その後に追跡するもの

• 効率を重視し、まずは次の順に追跡します：タグ付きクリック数 > ピン留めリポジトリへのトラフィック > 適格な問い合わせ

上記の順番で、3つの項目をそれぞれ整えます。

• タグ付きクリック数：プロフィールから、オーナーが管理するリンク先（ドキュメント、製品、コミュニティなど）へのタグ付きリンクです。設定には1時間かかりますが、リンク先の分析データはオーナーが所有でき、ここに挙げた数値のうち、精査に耐えられる唯一のものです。
• ピン留めリポジトリへのトラフィック：無料ですが、単独ではほとんど役に立ちません。対象は直近14日間に限られ、オーナーがプッシュできるリポジトリのみが対象です。
• 適格な問い合わせ：この順番では後回しにされる項目です。読み解くには継続的な習慣が必要で、意味のあるデータになるまでに四半期かかります。組織にとっては、ページが誰かの行動を変えたことを示す唯一の証拠なので、組織の場合は優先し、公開日から集計を始めましょう。

適格な問い合わせの意味は対象者によって異なります。組織の場合は、何を作っているかをすでに知っていて、質問する必要のない見込み客のことです。実務者の場合は、プロフィールに掲載された何かに言及した登壇や共同作業の依頼を指します。

それ以外のものは、どれも不完全です。プロフィール単位の分析機能を提供するホスティングサービスはなく、ここに挙げたどの数値もプロフィールの効果だけを切り分けて測定できません。公開日を記録し、影響を与える可能性のある要因をすべて注記してください。

次の2つの数値は、最後に回すのではなく、計画から削除してください。

• READMEの閲覧数カウンターバッジは、匿名化プロキシを経由した画像リクエスト数を数えるため、ボットや再読み込みも含まれます。さらに公開スクリプトで数値が水増しされるので、データではなく飾りです。
• プロフィール変更後のスター増加は、何が原因か特定できず、企業レベルでは積極的に不正利用されています。スターはページではなく、プロモーション（リリース、登壇、別の場所での言及など）によって増えることが知られています。

ここに挙げたほかの数値も、すべて同じように考えてください。

よくある失敗

• 診断より先に装飾する。 最初に掲げる主張が誤っているページにウィジェットを追加しても、誤った主張を見栄えよくするだけです。まず評価しましょう。
• あらゆる対象者に同じチェックリストを使う。 連続記録ウィジェットは、キャリア初期の同業者には熱心さを示す一方、オーナーが本当に届けたいメンテナーや採用担当者にはノイズになります。要素を1つでも勧める前に、質問2に答えましょう。
• プロフィールの効果を誇張する。 書き換えによって面接やコントリビューターが増えるかどうかは、誰も測定していません。どちらかを約束するのは効果を捏造することであり、実現しなければオーナーは気づきます。約束するのは明確さと一貫性にとどめましょう。ページが実際に提供できるのはその2つです。
• スター数順にピン留めする。 プラットフォームにはすでにスター数が表示されています。人気順にピン留めしても、訪問者が見られる情報を繰り返すためだけに、唯一の編集手段を浪費することになります。
• ウィジェットに依存する。 サードパーティ製のカードはどれも、停止したり、レート制限に達したり、画像プロキシ内で更新が止まったりする可能性のあるサービスです。使うのは最大1つにし、ログアウト状態でも正しく表示されることを確認しましょう。
• 組織プロフィールを2つ目のマーケティングサイトとして書く。 訪問者はコードを見るためにGitHubに来ています。ページの役割は、最初に開くべきリポジトリと、どれがオープンソースなのかを伝えることです。それ以外はウェブサイトがすでに担っています。
• コントリビューショングラフを成績表として扱う。 グラフを埋めるよう誰かに勧めるのは、証拠を偽造するよう勧めることです。カウント方法を知る読者は、いずれにしてもグラフを信用しません。
• ページの管理者を決めない。 管理者がいないプロフィールは、いつの間にか事実と異なる内容になります。作成時には正しかった主張も、正しくなくなった後まで掲載され続けます。書き換えと同じタイミングで、管理者と見直しのきっかけを決めてください。
• テンプレートをそのまま流用する。 1万件のプロフィールと同じように読めるプロフィールは、読者に読み飛ばされます。ひな形で順序を決めることはできますが、文章にはそのアカウント独自の内容が必要です。

参考資料

• ./references/published-findings.md - 公開済みの数値と独自に設定した数値、対象者ごとに段階的に示すガイダンス、避けるべき主張
• ./references/profile-scorecard.md - 必須チェックと採点対象のチェック、しきい値、初見の読者によるテスト、レポート形式
• ./references/profile-skeletons.md - 対象者ごとのセクション構成、良い例と悪い例、公開済みの組織プロフィールで確認されたパターン
• ./references/platform-mechanics.md - README の前提条件、フィールドとピン留めの上限、コントリビューショングラフの集計ルール、実績、画像プロキシの動作
• samber/developer-platform-skills@github-engagement-playbook - ピン留めされた1つのリポジトリが提供する GitHub の機能：ディスカッション、リリース通知、トピック、スターのポリシー