- シニアエンジニア・PM・デザイナーほど、自分が責任を持つ中核指標のグラフを少なくとも1つ持つべきであり、これは仕事で成果を出すための最も速い方法の1つである
- シニアレベルで扱うべき重要な問題の大半はグラフで表現可能であり、ページ数・性能・コスト・売上・離脱率のように長期的な変化を示す指標を自ら責任を持って追うことが求められる
- グラフは「15%減らした」のような文章よりも、規模・傾向・変動性・時点を一度に示し、インパクトを説明しつつ検証可能な信頼を得るための最も強力なコミュニケーション手段である
- 目標設定と確認にグラフを組み合わせるループは、成果の追跡とフィードバックを極端に単純化し、高業績と失職を分けるほどの差につながりうる
- 良いグラフとは、他の人が頻繁に参照する少数の重要なものであるべきであり、品質・サポート・売上・リテンションなどにおいて1つのグラフを最後まで責任持って動かすことがシニアの中核的な役割である
重要な問題を扱う
- シニア段階では、「大きくて重要な問題」を引き受けることが必須であり、こうした問題の多くは時間に沿った変化を示すグラフで表現できる
- 例: ページ数の削減、性能改善、コスト削減、売上増加、離脱率低下
- 四半期単位以上の期間で、自分の仕事の結果が目に見える曲線として現れるべきである
- すべての仕事がグラフに直接結びつく必要はないが、グラフを1つも担当していないなら、シニアとして十分に役割を果たせていない
インパクトを明確に伝える
- シニアがよく抱える問題は、自分の成果が理解されないという不満であり、これはたいていコミュニケーションの失敗と見るべきである
- 「ページを15%減らした」のような文章だけを送ると、出発点・期間・傾向・偶然かどうかなど、多くの追加質問がすぐに生まれる
- グラフはこうした問いに対して、規模（スケール）、過去の履歴、変動性、変化の時点を一目で示す
- さらにデータソースへのリンクも添えられるため、相手がグラフの真実性を自分で検証しやすい
- インパクトを曖昧なテキストだけで表現すると、「今やっていることが正しいのか、投資に見合う効果が十分か」についての鋭いフィードバックを受けにくい
- 逆にグラフで表現すれば、功績を認められると同時に、方向性や優先順位について明確なフィードバックを得られる
- グラフは、業務の価値と時間に対する効果を明確に示す手段である
すべての要素を1つにつなぐ
- 前回の記事 On Achieving Goals で述べたように、物事を成し遂げるプロセスは**「目標設定 → 確認」という単純なループ**に要約できる
- 良い目標を立て、明確な責任者を置き、定期的なチェックインを通じて状態と必要な調整事項を確認する単純な構造が、目標達成の本質である
- 目標が失敗する原因の大半は、価値のない目標・優先順位の誤り・責任者不在といった悪い目標設定と、チェックイン不足・誤ったチェックイン運用など基本プロセスの崩壊に由来する
- 正確な目標と継続的な確認は、組織が本当の変化を生み出すための基礎インフラであり、これがなければどんな目標も継続的には達成できない
- 今回の記事は、ここにグラフを組み込めという追加ルールを加える
- つまり、目標を設定し、その目標を表す単一のグラフを定期的に確認するループを回すべきだということだ
- この組み合わせは、高業績者と失職状態を分けるほど強力な道具になりうる
まとめ
- グラフは、シニアが進捗を追跡し、結果を示し、フィードバックを得るための中核単位である
- 1つのグラフを引き受けて前に進めることが、オーナーシップ（ownership）の実質的な単位である
- 今、自分が責任を持つグラフがないなら、すぐに1つ見つけて自分のものにすべきである
Appendix: グラフ所有の Tip & Trick
- 他の人が頻繁に引用するグラフを持てるようになれば、正しく進んでいる証拠である
- 人はたいてい怠惰なので、役に立って正確なグラフがあれば、それを作り直さずそのまま持ってきて使う傾向がある
- こうしたグラフは自然に自分のキャリアにとってもプラスに働く
- グラフは最初から完璧である必要はなく、フィードバックを通じて段階的に改善していく過程そのものが真のオーナーシップである
- 避けるべきアンチパターンは、**「あまりに多くのグラフを所有すること」**である
- 自分の物語に都合のよい瞬間にだけ使うため、大量のグラフを集めて「所有している」と主張する人もいるが、
- 良い状態とは、ごく少数の、本当に重要なグラフだけを深く責任持って見ることである
- 「You have too many metrics」 でも述べたように、指標やグラフは少なく、そして致命的なほど有用であるべきだ
- エンジニアがグラフを探すときは、品質課題がよい出発点になる
- ページ数、インシデント、バグ、性能はいずれもグラフ化しやすく、誰かが責任を持つのを待っている領域である
- PM・デザイナーの観点では、**サポートチケット、売上、競合勝率、リテンションに影響する付随製品のアタッチ率（attach rate）**などがよい候補である
- 必ずしも自分ひとりの力だけで指標を動かせる必要はなく、
- 重要な指標を継続的に監視し、粘り強く人を動かして方向をそろえるだけでも、キャリアを大きく前進させられる
8件のコメント
私の体重グラフは右肩上がりです
私の年俸の上昇グラフは、5年間ずっと0%です。
一般化するのは簡単ではないでしょうが、ひとまず経営陣を説得するには最も良いツールであることは確かですね。
それなら、そのグラフはおそらく汚染される可能性が高いでしょう。
グッドハートの法則: "測定基準が目標になった瞬間、その測定基準はもはや良い測定基準ではなくなる"
グッドハートの法則を論破する引用として
ピーター・ドラッカーの言葉として知られる「測定できなければ管理できない（If you Can't measure it, you Can't manage it）」を思い浮かべました。
さらに調べてみると、Drucker Instituteでもドラッカーはそのような発言をしたことはないとしています。
むしろ逆の言葉を見つけました。
測定できなければ管理できないと考えるのは間違っている。――それは高くつく神話だ。（It is wrong to suppose that if you can't measure it, you cant manage it-a costly myth） - エドワーズ・デミング（Edwards Deming）
それでもなお、有意義な測定基準はあると思います。特に、相反する2つの指標の両方に責任を持つ誰かがいるほうが、より効果的だと思います。SREの観点で障害件数を減らせたと喜んでも、その分だけ石橋を叩いて渡るように慎重になってデプロイが遅れ、機能開発が鈍ることもあり得ますし、Devの観点で機能開発をたくさんできたと喜んでも、その分だけ障害発生件数も増えるかもしれないからです。
p99 latency、応答成功率、リクエストあたりのコスト、MTTR、障害発生件数のような指標も、悪用しにくい良い指標だと思います。（もちろん悪用される可能性はあるでしょうが、追跡して管理することのほうが、失うものより得るもののほうが多そうです……）
普段から、パーセンテージで成果をアピールするのは無意味だと思っていましたが、この記事がその考えを完成させてくれる気がします。
売上を5パーセント向上させることに貢献、ではなく、どの期間にどれだけ伸ばし、それが自分の貢献前と比べてどれだけ急になったのかを語るべきだと思います
成果や目標を数字で表現する能力が重要だと思っていましたが、この記事ではグラフでまで表現しなければならないと言っていますね。相手にとって理解や信頼の面で納得できる部分だと感じました