最近、自グループのJob Descriptionとロードマップを作成する機会があって、結構いい経験だったのでメモしておきます。
前提: 私自身について
- 私自身はただのエンジニアで、管理職やテックリードではないです
- これまで採用にがっつり関わったことはないです
- 前職だと機械学習系の面接でたまーに出るくらい
- ましてやJob Descriptionの作成とかは関わったことはない
- 現職だとカジュアル面談に出るくらい
- 前職だと機械学習系の面接でたまーに出るくらい
- グループのロードマップがあるチームで働いた経験はありますが、その作成にがっつりと関わったことはないです
Job Descriptionとロードマップの作成に関わる経緯
- 現職のデータ基盤では、様々な領域のデータがBigQueryに集まっています
- エンジニアに限らず、幅広い職種の人がBigQueryでクエリを実行していて、それを支えるデータ基盤グループへの期待も大きくなっています
- その一方で、「〇〇という分析をするためにどのデータを使えばいいかわからない」「同じ集計をしたはずなのに結果が異なる」といったようにデータを簡単・安心・安全に使ってもらうための課題が増えています
- こうした課題を解決するため、データマネジメントの組織の立ち上げ、ロードマップの策定を行なったり、データマネジメントに特化したJob Descriptionを作るタイミングがありました
- 少人数のチームのため、エンジニアである私もこれらの作成に関わりました
宣伝ですが、今月末にこの辺のことを話すTech Talkのイベントを開催するので、興味がある方は是非ご参加ください。
作成に関わった結果
Job Descriptionを作成するにあたって、(当然ですが)自グループは何のためにあるのか、どういった課題を解決するためのグループなのかを言葉で定義する必要があります。実際に定義しようとしてみると、案外メンバー間で認識(例: やるべきと思っている優先度)が違っていたり、うまく言語化できないことがありました。
ほぼ同時期にデータ基盤のロードマップの作成を始めました。ロードマップをゼロから作るのは大変なので、業界内では有名なDMBOKをベースに考え始めました。この本は600ページ以上あり、データマネジメントを考える上でカバレッジは申し分ないものの、これから自社に合わせたロードマップを作成するには正直かなりのギャップがありました。そこでDMBOKの項目はベースにしつつ、各項目に対して自社のAS-ISとTO-BEをそれぞれグループのメンバーで議論することにしました。10以上ある項目をフラットに考えると見通しがよくなかったため、自社の現状に合わせて項目間の依存関係を洗い出したり、データ基盤のユーザーに対してヒアリングを行ない、需要側も考慮した上で優先順位を組み変えを検討する、ということをやっています。
ロードマップを作成していく中で、次第に現在の課題が言語化できてきたり、それに対する解決案が見えてきつつあります。このプロセスを経た結果、よかったところは色々あって
- 上位レイヤーから天下り的に降ってくる課題ではなく、本当に解くべきと思える & 自分事化して考えられる課題になっている
- メンバー内でしっかり議論をぶつけているため、納得感がかなり高い
- ロードマップが「やることリスト」ではなく、ストーリーとして語ることができる
- Job Descriptionもこれらの議論の結果を経て作ることができた
- 解決方法もかなり工夫のしがいがあるし、必要だったら問題定義から見直せるため、挑戦しがいがある
- バリューは解き方よりも問題設定で8割くらい決まってしまうというのはよくある話
- 課題をどう捉え、どう解決するかは腕の見せ所ではあるし、エンジニアとしては楽しさを感じるところでもある
- カジュアル面談で自分の仕事の面白さをどう捉えているか、より熱量を持って話せるようになった
などがありました。時間をかけて作る価値があるな、と個人的には思います。
所感
Job Descriptionやロードマップは作るべきタイミングがあると思うし、それほど頻繁に作るものではないとは思いますが、エンジニアであっても作る機会があったら前のめりで参加してみるとよいと思います。
