じゆうちょう Advent Calendar 2019 18日目の記事です。
概要
データエンジニアリングという業務を扱うにあたって、どのように人事評価を実施するか。 本稿では実践可能なレベルで「評価基準」の例を提示します。
もくじ
背景
データエンジニアリング業務に伴う「人事」（採用・アサイン・育成・評価）について質問を受けることが増えました。
噂の「まかないランチ」をご馳走になりました！ pic.twitter.com/mMO0zWiFoU
— ゆずたそ (@yuzutas0) 2019年1月10日
データ基盤の重要性が認知され始めてきたのだと思っています。 組織として力を入れようとすると、評価設計の話は付いて回ります。 仕事の成果を正しく評価できなければマネジメントが崩壊するからです。
人事トピックが出てきたということで、2019年は本格的な「データ基盤」元年と言えるでしょう。知らんけど。 少なくとも、いち担当者の技術的な取り組みを超えて、組織的な仕組みを模索・共有するフェーズには入っているはずです。1
注意点
- 以下2点を前提とします（Appendixで補足します）。
- 目標管理制度と人事評価を兼ねる形式であること。
- 被評価者がコントロールできない事象に対してはフォローを入れること。
- あくまでも1つの例です。ご自身の置かれた状況を踏まえて、可能な範囲で参考にしていただけると幸いです。
- 本稿は筆者個人の見解であり、所属組織を代表するものではありません。不適切・考慮不足だと感じさせてしまう点があれば、それは筆者個人の責任によるものですので、どうぞ筆者個人宛てにご指摘のコメントをいただけますと幸いです。
本題: 人事評価の設定例
こんな感じです！
1. マイルストーン（計画）
開発計画の策定・遂行を軸とした設定です。 ロードマップを引いて、マイルストーンを置いて、その進捗を目標とします。
- 3月までに、KPIの定義についてA部署・B部署マネージャーと合意形成すること
- 6月までに、KPIの週次モニタリングが運用開始できていること
- 9月までに、KPIモニタリングについて、A部署・B部署のメンバーに事後ヒアリングを行い、課題管理ができていること
- 12月までに、課題管理表をもとに翌年の開発計画書を作成して、C部署のマネージャーと合意形成すること
ガチガチの大規模組織であれば上記のような目標設定になるでしょう。 それなりに成熟した事業・組織において、散在したデータを集めたり、データ活用アイデアを実現するには、何かと時間が掛かるものです。
小さなサービス・フットワークの軽いチームであれば「来週までにKPIダッシュボードを作ってね！」といった話になるでしょう。 その規模感に合わせた目標設定の粒度やスケジューリングになるはずです。
2. QCDS（構築）
基盤システムの構築・改修については、開発計画におけるQCDS目標を紐づけることができます。
- Q:品質（後述するサービスレベルにもとづいて目標設定する）
- C:コスト（目標とする予算内で実現できたか）
- D:デリバリー（目標とする期間で実現できたか）
- S:スコープ（目標とする機能要件を実現できたか）
特筆すべき事項はないかと思います。 データ基盤と言えどもITシステムなので、ITシステム構築における一般的なプロジェクト評価方法を適用できます。
3. サービスレベル（運用）
データ基盤の保守・運用については、サービスレベルにもとづいて目標を設定・管理することができます。
あまりにもシステム障害が多発＋事態が改善されない→担当者がマイナス査定になる。 改善アクションによって高いサービスレベルを実現した→担当者がプラス査定になる。 こういった形で評価できます。 本質的にはSREと同じで、サービスとしての信頼性を担保することが求められるからです。
「サービスレベルとは何か」「データ基盤のサービスレベルをどう定義するか」については以下の記事を参照ください。 単純にレスポンスタイムや障害件数をグロス集計するのではなく、サービス品質として「便益・ユースケース」駆動で目標設計すべきです。
4. 利益目標（企画）
以下のような価値観を持つ組織では、具体的な金額目標を設定することができます。
「データ分析を実行してビジネスで成果を出す」ことができる人を「データエンジニア」と呼ぶ
スケーラブルデータサイエンス データエンジニアのための実践Google Cloud Platform
- 作者:Valliappa Lakshmanan
- 出版社/メーカー: 翔泳社
- 発売日: 2019/06/05
- メディア: 単行本（ソフトカバー）
データ基盤・データ分析といった役割はコストセンターとして扱われがちです。 しかし、営利企業がデータを活用するのは、何らかの形で企業価値向上・利益創出に寄与する（と期待している）からです。 価値を生み出していない（ように見える）「データ活用」には、いずれ経営観点で指摘が入るでしょう。2
「データ基盤を用いたデータ分析・機械学習」がビジネス利益創出に寄与できる場面は多々あります。 ABテストによる機能・UIの最適化、コンテンツのレコメンド、セールス業務改善、リテンション（CRM・CCCM）、マーケティング（例:アロケーション最適化）など。 ビジネスモデルによりますが、こうした利益創出ドライバーを支援するときは、数値目標を持ちやすいと言えます。
ただ、いわゆる「開発・運用専任のエンジニア」にこの目標を持たせることはできません。 そのロールがコントロールすべきでない数字だからです。
あくまでも「データ基盤のプロダクトマネージャー」と呼べるようなロールに利益目標を持たせる。 これはアリだと思っています。 プロダクトマネージャーがROIにコミットすることで、強靭なデータ組織へと急進化を遂げることができます（さもなくばチーム解散）。
まとめ
注意点に記載しましたが
目標管理制度と人事評価を兼ねる形式であること
という前提から、必然的に「案件の目標設定」と近似する形となりました。 この基準をベースにして、ジュニアエンジニアであれば「スキル習得目標」といった他の要素も加味し、最終的な評価基準が出来上がるはずです。
「データ基盤も他の業務と同じだ」ということが最も伝えたかったメッセージです。 経験豊富なマネージャーであれば「新しい情報」は1つもなかったはずです。 「データ基盤だからこそ」という特別な要素はありません。
マネジメントのプロフェッショナルが適切なマネジメントを執行することが重要だと思っています。
Appendix
以下おまけコンテンツです。
前提1: 本稿のスコープ ＝ 査定でボーナスが上下するような状況
順を追って説明します。 まず、人事評価の役割は以下の3点だと解釈しています。
- 結果をもとに上司・部下の認識を擦り合わせて、次の案件アサインの参考とする
- 評価フィードバックを通して部下育成の機会とする
- 仕事と金銭的なインセンティブを紐づける（正のフィードバックだけでなく負のフィードバックもありうる）
このうち(1)アサインと(2)部下育成については、日々の1on1のほうが重要だと個人的には考えています。 「四半期に1回」「半年に1回」「1年に1回」といった考課面談だけだと、チャンスが少なすぎるように思うからです。
もし(1)と(2)で悩んでいるのであれば、おそらくデータ基盤特有のトピックではありません。 単純にマネジメントスキルの問題で、週に1回の1on1を組むとか、1日に3分でいいから話を聞くとか、そういう施策のほうが有効だと思います。 なので、本稿では対象外とします。
(3)金銭については以下2点に分けられます。
- 3-1.「管理職になる」といった給与テーブル自体の移動
- 3-2. インセンティブ・ボーナスといった単発の増額・減額
評価結果と金銭が連動しない評価制度であれば、検討のリソースを割くメリットは少ないので、本稿の対象外とさせてください。
(3-1)ですが、給与テーブル制度を前提とします。 Netflixのような尖った制度を採用する組織では、大元の思想が異なるため本稿の対象外です。
例えば、通常社員(A)と管理職(B)で2つの給与テーブルがあるとします。 Aなら年収400万円、Bなら年収700万円といったベース金額が設定されるはずです（あくまで例です）。 さらに、エンジニアなら専門職として毎月プラスいくら、営業ならコミッションがボーナスに乗る、といった形で加味されます。
給与テーブルについては、各社ごとに既に何らかの仕組みやポリシーがあるはずです。 カッツモデルを引き合いに出して専門性よりも人間性を見て昇進させるとか、経営陣の目に止まる華やかな成果を出した人が出世しやすいとか。 データ基盤単体の話ではなく、横断的な話となるので、(3-1)は本稿では扱いません。
ということで、本稿は「定期的な人事評価によってボーナスが上下する」という(3-2)の限定的なスコープに影響を与える査定を「人事評価」と呼称します。 このスコープにおける「人事評価」は「案件の目標設定」と結びつきやすいと考えています。 「担当案件で圧倒的な成果が出たからボーナスが増える」という状況が最も自然に思えるからです（主観です）。
なお、プレゼンテーションや社外貢献を評価に含めるエンジニア組織もありますが、私自身はこの制度を経験したことがありません。 どういう力学が働くのかイメージできないので、今回は対象外とさせてください。
前提2: 被評価者がコントロールできない事象に対してはフォローする
本人がコントロールしえない事象に対しては情状酌量すべきだと思っています。 できれば目標設定の時点でなるべく考慮・工夫するのが理想ですが。
例えば
- 前任者の仕込んだバグ・不具合がもとで、システム障害が多発した
- 障害対応に工数を割いて、機能追加（基盤強化）が計画通りにできなかった
- 結果だけを見たら「目標は未達成」となる
よくある話です。
ここでマイナス査定にしてしまうのは、よろしくないかなと思います。 まず、労働者本人のモチベーションとしては最悪ですよね。
さらに、組織としてモラルハザードを助長しうると思っています。 「額面通りに目標さえ達成できれば評価される組織」になります。 今回の例だと「隠せるなら障害を隠しておいて、機能追加したほうが評価される組織」ということです。 要するに「臭いものに蓋をして逃げ切ったやつが得をする環境」です。 どこかで無理が出てくると思います。
なのでマネージャーはフォローを入れることになります。 「目標は未達成だが、こういう事情があったからだ。むしろ障害対応でこういう貢献をしてくれた。だからこの人物はこう評価したい。」 と、さらなる上位レイヤーに対して説明するのです。 経営者の立場だと「いいから目標を達成しろや」「どうするんやこれ」と言いたくなるので、健全な大人の喧嘩が勃発して、ネクストアクションを模索するわけです。 ミドル層が上手く吸収できると、組織は円滑に回ります。
あらゆる例外状況を踏まえた完璧な評価基準が存在するわけではありません。 どこかで必ず運用面でのカバーが入ります。 システムではなく上司（人間）が人事評価をする意味がそこにあります。 これは「データ基盤」や「人事評価」に限らず、「組織制度の運用」において一般的に言えることです。
今回のように「こういう評価基準です」と具体例を示すと、「じゃあこういうときはどうするんですか」と例外ケースの質問をされることがあるので、いちおう明記しておきます。
応用編1: 「データ基盤」という固有トピックにおける技術や案件の評価について
「データ基盤について詳しくないから、正しく評価できない（評価されない）」という話を聞きます。 ただ、エンジニアだろうがデザイナーだろうがマーケターだろうがカスタマーサポートだろうが、今の時代どこも同じだと思います。 「データ基盤だから」ではなく「専門家をいかに評価するか」「専門外の相手にいかに評価させるか」というポータブルスキルの話だと私は解釈しています。
現場で手を動かしているのはスペシャリストです。 経営者が経営の専門家であるのと同様に、マネージャーがマネジメントの専門家であるのと同様に、スペシャリストにはスペシャリストの担当領域があります。 「評価する側」よりも「評価される側」のほうが特定分野について詳しいはずです。
マネージャーには「自分よりも知識のあるスペシャリストを適切に評価できるように話を聞くスキル」が求められます。 スペシャリストには「自分よりも知識のないマネージャーが適切に評価できるように話を伝えるスキル」が求められます。 データ基盤に限った話ではありません。
もしデータ基盤をキッカケとして課題が可視化されたのであれば、むしろマネジメントスキルを向上させるチャンスとして、ポジティブに捉えられると最高ですね！ これから時代が変わって次々と新しいスキルの持ち主が出てきても、そのスペシャリストたちと信頼関係を築ける強いマネージャーになれるのですから！ すごーい！
一方で、スペシャリストがスペシャリストを評価することを前提とした仕組みもあります。 シニアエンジニアがジュニアエンジニアを評価するようなケースです。 「この座組みは続けたい」「だけど評価できるデータ基盤エンジニアが存在しない」のであれば、打ち手は「外から引っ張ってくる」（採用・技術顧問）か「評価できるように勉強する」（CTO・VPoE・SREチーム・エンジニアリングマネージャー陣）のどちらかだと思います。 専門性が細分化されていく時代において、スペシャリストがスペシャリストを評価する座組みが本当に適切なのか、私個人としては懐疑的な立場ですが。
応用編2: 「データの民主化」の目標設定をどうするか
データ組織が成長して大規模になると、役割分担が進み「データの民主化」専任チームが立ち上がることがあります。 素直に考えると「データ基盤を参照している部署」（広さ）x「データ基盤を参照している度合い」（深さ）でモニタリングすることになります。
ただ、これはAsIsの可視化としては便利ですが、案件目標や人事評価（ToBe設定）にそのまま使うべきではないと思います。
そもそも何のためにデータを民主化するのか。何のためにデータを活用するのか。 もし「利益貢献」がゴールなら「利益インパクトのある部署への導入」といった施策が優先採用されるでしょう。3 この施策と整合的な評価基準を考えると、以下のような形になります。
「データの民主化」という言葉が持つイメージとは違うかもしれません。 しかしコミットする目標としてはこれが妥当です。
「皆がデータを使いやすい状態を実現する」とは、要するに「デザイン」です。 「皆にデータを使ってもらう」とは、要するに「マーケティング」です。 華やかなだけでなく、地道に仮説を立て、ターゲットを絞って、改善していくわけです。 デザインやマーケティングの業務を担当するのと同じです。 デザインやマーケティングの業務を担当するのと同じ枠組みで人事評価すれば良いはずです。
「データの民主化だからこそ」という特別な要素はありません。 既存の要素を参考にして、抽象化・具体化できる思考力があれば、必然的に答えは出てくるはずです。
おわりに
長々と書きましたが、人が人を評価して、そこにお金が絡むわけなので、どこまで書いても書き足らないなぁと思っています。 仮に自分が評価される立場だったら、そのくらい考えてくれる人に評価してもらわないと納得できないんじゃないかな、という気持ちもあります。
データ基盤やデータ活用、あるいはエンジニア組織の立ち上げ・運営について、壁打ち相手を探している！という方がいましたら、 お気軽に@yuzutas0までお声掛けください。DMは全開放しています。
-
組織的な仕組みは過去の資料でも言及しているので、興味のある方はぜひ色々と漁っていただけると嬉しいです！↩
-
データ組織という名目で、事実上のディレクション組織という場合もあります。短期的な数字目標を持たない立場だからこそ、いわば社内コンサル的な立ち位置で関係者の合意形成に寄与するロールです。ディレクション組織と名乗ってしまうと、既存のディレクション組織とハレーションが起こるため、「数字目標を持たないデータ組織」（だけどディレクション価値を提供している）という建てつけになります。これはこれで企業にとって不可欠な存在と言えるでしょう。こうした組織のあり方を否定する意図はありません。↩
-
データ分析屋にこの話をすると「単価＊量」で分解できるだろと言われたことがあるのですが、むしろ定量的に考えると「パレートの法則」が働くと仮定できるので、重点部署を攻めるほうが望ましいと個人的には思っています。↩
