昇進ドキュメントスタイルガイド
昇進のケースをまとめることは時間のかかるプロセスになり得ます。このガイドのヒントとスタイル原則は、証拠を明確に提示するドキュメントを準備し、レビューサイクルを減らすのに役立ちます。
定性的な表現よりも定量化を重視することは、読者と著者の双方にいくつかの利点があります。
- 時間をかけて徐々にドキュメントを組み立てやすくなり、どの時点でも完成度を理解しやすくなります。
- ドキュメントの内容により自信が持て、そして重要なことに、より客観的に読めます。
- 同じ役職への昇進ケースを互いに、また職務ファミリー基準と比較しやすくなり、トーンが一貫します。
- プレゼンテーションが最大限にインクルーシブになり、読者側に求められるコンテキストが減ります。
説得力のある昇進ケースを提示するための原則
- 形容詞と副詞の使用を最小限に抑える。
- 悪い例:
- “最も重要な Plan エンドポイントのパフォーマンスを大幅に改善した。”
- 良い例:
- “訪問数の多い 5 つの Plan エンドポイントについて、Time to First Byte (TTFB) を平均 180ms 削減した。”
- 理由: 形容詞と副詞は不正確で、読者がその人の実際のインパクトと正確な貢献を理解するのを困難にします。
- 悪い例:
- 定量化が適切で意味のあるものであることを確認する。
- 悪い例:
- “3 か月間でページビューを 200 万増加させた。”
- 良い例:
- “3 か月間で月間ページビューを 25% 増加させ、800 万から 1,000 万にした。”
- 理由:
- 「だから何？」テストに合格する記述になり、読者がさらに調査する必要がなくなります。
- 悪い例:
- 番号付きのリンクは例を列挙する場合にのみ使用し、その人がどのように何をしたかを説明するためには使わない。代わりに貢献を説明し、文中の一部をリンクする。
- 悪い例
- “重要なユーザー機能をアーキテクチャ段階から General Availability (GA) まで完遂した [1,2,3,4,5]。”
- 良い例
- “提案された解決策を検証し見積もりに役立てるための [proof of concept implementation] を備えた [architecture blueprint] を作成した。その結果、プロジェクトは 3 つの MR で予定どおり納品された [1,2,3]。”
- 理由: 読者が各リンクを個別に調査し、しばしば大きな Issue やディスカッションの中からその人の実際の貢献を自分で読み解く必要がなくなります。
- 悪い例
- 次のレベルでの能力とインパクトに焦点を当てる。
- ビジネス上の正当性は、昇進した場合にその人の役割がどのように変化するか、そしてそれがビジネスにとって何を意味するかを記述すべきである。
- 悪い例:
- “この昇進は、[name] が必要な際に役職の次のレベルで活動できる能力を認めるものです。”
- 良い例:
- “この昇進により、[name] はテクニカルアーキテクチャの継続的な責任を担い、まずはプロジェクトリードとして [project 1] を加速させ、[project 2] と [project 3] の完了を 3 か月前倒しして 2026 年度末までに完了させます。”
- 理由: 期待される役割の進化を明確に定義することで、昇進のビジネス上の必要性と、その投資が組織の目標にどのように貢献するかを示すことができます。
- 悪い例:
明確さとインパクトのための追加のヒント
- 不要なフィラーワードやフレーズを避けます。
- Arguably (おそらく)
- In order to (〜するために)
- It should be noted that (留意すべきは)
- Due to the fact that (〜という事実のため)
- 略語が初めて登場したときは展開して書きます (“Technical Account Manager (TAM)")。
- リンクが正しいリソースを指していること、想定する読者が利用可能であることを再確認します。
- 散文ではなく箇条書きを使います。
- 30 語を超える文章は避けます。
- テンプレートに従います。例を 2 つ求められた場合は、最良の 2 例を提示します。
最終更新 June 14, 2026: Merge pull request #403 from kyama0/claude/cool-turing-ls6eck (
bfd74782)