Gunosy エンジニア行動指針をつくりました

かとうです。今年は110kg担いでフルスクワットできるようになりました。

こちらの記事はGunosy Advent Calendar 2022の1日目の記事です。 昨年最後の記事はkoidの面倒なドキュメント生成はCIにやらせようでした。 今年もよろしくお願いいたします。

さて、本記事ではGunosyのエンジニアの行動指針（コンピテンシーマトリクス）を策定いたしましたので、どういった流れで作成したかというお話をしたいと思います。もともとパブリックに公開する想定で作っていましたが、まだ運用開始したばかりなのと、どこに掲載するか準備が整っておらず間に合いませんでした、ごめんなさい。とりあえず本日はプロセスや込めた思いなどを書いていきたいと思います。

背景

現在Gunosyでは全社共通の等級（グレード）制度＋専門職等級の手当（エンジニア専用）という形で報酬（給与）が決まるという形になっています。

もともとはグレード制度のみで、エンジニアのもつ専門性はビジネススキルと総合的に判断という形になっていました。エンジニア採用における市場環境などの背景もあり、もう少し柔軟に、独立してエンジニアとしての専門性を評価できるようにしたいというねらいのもと、専門職手当の制度を2年前に設定をしました。

設定した一方、その手当の金額を決める基準が「イメージ」としてかなり曖昧な状態でスタートしてわかりづらいものでした。そのため、手当の基準として設定するためのエンジニアの行動指針を策定し、制度を運用していくこととしました。

どのようなものを作ったか

テクノロジー/ソリューション/チームワークという3つの大項目に4〜6個のテーマがあり、それぞれ5段階で求めるふるまいが記載されています。

当初、「ネットワーク」「Go」「AWS」「Android/iOS」・・・などかなり具体的な個別の技術要素についてそれぞれ5段階のレベルをつけていくというものを作成しました。実際に運用に耐えうるものか事前にヒアリングなどしてみたのですが、具体的にそのスキルを示すことが難しかったり、各技術のレベルを普段の業務と関係なく引き上げていくのが目的なのかと問われると違うなということで、今の形に見直すことにしました。

具体的にいえば、テクノロジー項目にある「オペレーション（運用・保守）」というテーマであれば、

• Base（Lv0）
  • 業務効率化において自動化の必要性を理解している
  • チーム内や担当領域の既存のプロセスやプラクティスを理解している
• Lv4
  • チームを問わず、リスク意識を高める啓蒙をしている
  • チームを問わず効率化できる仕組みを考えている

というように、レベルが上がることに具体的な実行や影響を与える範囲が広くなることを求めるような内容になっています。 また、特定の役割に限定した内容にならないよう注意し、表現も全体的に「〇〇できる」ではなく、あくまで「ふるまい」としてとらえてもらいたいため「〇〇している」となるよう意識して作成しました。

進め方

「具体的な技術要素」から「ふるまい」へ変更するのも、言うは易く行うは難しで、ゼロベースからマトリクスを完成させるまでに約半年かかりました。序盤はマトリクスという形式も決定していなかったため、半日ブロックしてこうあるべきといった話し合いからスタートし、あとはSlackチャネルでの話し合い＋1〜2週間に一度2〜3時間ほど予定をブロックしながら作業をする、といったことを繰り返しました。 何もない状態から作り上げるのはかなり難しく、調査をしている中で見つけたCircleCI Engineering Competency Matrixはかなり参考にしました。

何もない状態からマトリクスの形になるまでの手順は下記のような流れとなりました。

1. miroのふせんを使って「社内で活躍するエンジニア像」を思いつく限り書き出す
2. ふせんのグルーピング
3. グループに名前をつける
4. グループ間で近しいものをまとめ、小→中→大とグルーピングしていく
5. グループに名前をつける
6. 小グループ（テーマ）ごとに、各ふせんの内容の具体性や影響範囲などを見てレベル分けをしていく
7. レベル感の調整を行う
8. テーマごとに「ふるまい」の表現となるようにテキストを編集する

実際には1-2と6-8あたりは何度か繰り返したり、まとまってきたあとレベル感が想定しているものか社内アンケートなども行いました。

miroの様子

理想をいえば全てのエンジニアから意見を集約しながら作りたいものですが、とりまとめることは不可能と判断し、CTOを中心にリードエンジニアの役割を担っているメンバーを中心に数名で作り上げました。 いったんマトリクスの内容はver1.0.0として社内のgithubリポジトリに記載してあり、今後の変更はPull Requestベースで改変する、透明性を保ちつつ進める想定です。

また、実際マトリクスだけを作ってもこれをどう利用するかの説明ももちろん必要です。査定に関連する項目でもあるため人事への事前確認、続いて評価者として携わるマネージャ陣へ運用方法を展開し、必要な修正をしたのちエンジニア全体に展開するという手順で進めました。

作ってみて

作成をし始めてから社内公開、運用開始まで1年近くかかっています。もう少しはやく完了する予定ではありましたが、焦ってリリースして取りやめるとなったら最悪のシナリオだったので、そうはしたくないという思いがありました。最終的にGunosyのエンジニアってこんな感じ、という価値観が反映されたものができたと感じています。

自分自身も含め、評価や査定に苦手意識をもつ方は多いと思いますし、自信を持ってできていると言える方はなかなかいないのではないかと思います。不要だと考える気持ちもわかりますが、今回の作業で「活躍するエンジニアのイメージ」のブレストをしたり、レベルの調整を行う中で、数名とはいえばらつきがあり、やはりなんらかの基準や方針をもっておかないと組織の価値観はずれていってしまうのではないかとあらためて考えるようになりました。

制度もシステムも、作ったあと放置をするとそのうち負債化してしまいます。策定にご協力いただいたみなさまに感謝しつつ、今後もアップデートを重ねていきたい*1と思います。

さて、Gunosy Advent Calendar 2022の1日目は少ししっとり目の記事でスタートしました。明日はnagayamaさんのKotlin Coroutinesの話になる予定です。お楽しみに！

*1:まずはパブリックリリースからかなと思います