自分のパフォーマンスを価値に繋げるために、データと正しく付き合う
――ここまではマインドセットでしたが、もう少し具体的なことを。事業やプロダクトの成功を導くために、どのように指標を立てていくかなどのポイントはありますか。
手塚：SRE領域に絞ると、ユーザー体験や一連の処理（クリティカルユーザージャーニー）に基づいたSLOを作成し、そのユーザーに対してシステムの信頼性がどの程度達成できているかのKPIを作ります。それをもとに運用と開発の優先順位をつけていきます。これはエラーバジェットを通じた手法になります。
ただしこれを教科書通りにやれば大丈夫とも言い切れません。世の中に大きな影響を与えるシステム障害を見れば分かると思いますが、自分たちで設定したSLOとしては大丈夫だったとしても、社会やお客様が心情的に許してくれない場合もあります。そういう意味ではSLOの設定の誤りとも言えますが、社会やユーザーが本当に求めていることは何か、常にステークホルダーを見ながら継続的に組み替えていく必要はあると思います。
また、そのプロダクトが何を実現したいかにもよります。例えばぼくらのセキュリティ商材だと、いかに多くのユーザーに多様なユースケースで使用してもらえるかにKPIを置いている状態で、そのなかで磨いています。
アジャイル開発では、スプリントのバックログから開発量のKPIを取るのですが、運用していて粒度の設定で難しさを感じています。一方でユーザーからのフィードバックがどういう成果になるかにKPIを置くと、いいかもしれません。
よく思うのは、指標は状況次第であり、スタートアップも大企業でも共通して言えるのは「ないなかでどう戦うか」。どこも足りないものがあるなか、いろいろ工夫したり、採用の入口を用意したり。試行錯誤しながらKPIを増やしていくことになるかもしれません。
松本：頷きながら聞いていました。スタートアップで資金調達の根拠を考える時にいろいろと指標やストーリーが必要になります。KPIや何らかの指標に落とし込まないまでも、エンジニアが事業やプロダクトに貢献するための具体策を考えてみることですね。
例えばぼくが所属するところではビジネスコンテストを実施していまして、優勝したら会社から援助が出ます。個人が社内で資金調達に挑むような感じです。自分がやってみたいビジネスについて、コンセプトや必要な資金を15分くらいの資料にまとめるのはかなり大変ですが、こういうことにチャレンジする機会があれば挑戦してみるといい勉強になると思います。社会や事業に貢献したいと思うと、すごくいい資料ができあがったりします。
ですので「やりたい」と意欲があるなら、一歩を踏み出すしかありません。ビジネスコンテストに参加したり、スタートアップやプロダクト立ち上げに参画したり、プロダクトマネジャーが近くにいるなら関わりを増やしてみたりするのもいいかと思います。自分のやる気と行動力を試すことにもなります。
そこを超えたら実際にKGIやゴールからどんどん分解して、具体的なKPIなどの指標に落とし込んでいけます。技術力があるなら、技術ベースで設定していけば自分の取り組みがどのゴールに影響するかも見えてきます。実際の取り組みとしては多少の劇薬感はありますが、まずは行動に移してみることですね。
――これまで出てきたものをエンジニアやエンジニア組織はどのように活用していくといいでしょうか。
手塚：指標はあくまでデータでしかありません。データとなる結果が生まれる背景には構造（組織構造や仕組み）があり、そこに何らかの力（実際の活動）を与えることで結果に繋がります。単なる数値を追っていたとしても的確にその構造と力の与え方を分析しないと道を踏み外しかねないなと思っています。
スプリントの数字がよくなかったら、体制を増やすなどの安易な対応に走りがちですが、開発効率を落とすようなメカニズムがあるはずなので、そこに目を向けていくべきです。チケットの切り方が大きすぎたからそう見えただけだったのか、何らかのトラブルが起きていたのかとか。
――パフォーマンスに関するデータの蓄積、分析、可視化でいいプラクティスはありますか？
手塚：パフォーマンスを発揮しているかどうかは抽象的な捉え方をする傾向があると思います。あるお客様はGitで何回コミットしたか、記事を書いたか、トークしたかのデータをとっています。ただし結果を判断するためではなく、推移の傾向を捉えるために使っています。「パフォーマンスが落ちてる？」と思った時に、データを見ながらその要因を分析するといった具合です。
松本：他でも聞いたことがあります。個人のパフォーマンスをデータから見ると、反感を買います。ケアに使うことが大事です。数字からパフォーマンスが落ちていると見えたとしても、現場をよく見るとそれを誘発する要因があります。数字は障害を取り除くためのケアや振り返りのための参考にするのがいいです。
――それでは最後に読者へメッセージをお願いします。
松本：今回はエンジニアの愛や内発的なものが出ましたが、興味を持とうとしているエンジニアの後押しやサポートをするのが自分の仕事であり、それこそがマネジメントだと思い始めているところです。だからぼくからエンジニアに事業やプロダクトに貢献するために「こうしてほしい」はあまりなくて、エンジニアを支援できるように先進的な大企業の評価を参考にしています。事業統括や経営の人たちはいろいろ試してもらいたいです。
手塚：いろいろと偉そうに話しましたが、できてないところがたくさんあって悩ましいところです。事業やプロダクトをリードする側の伝え方がエンジニアのパフォーマンスや愛に影響してきますので。まずは自分から！
