スクラム採用をチームに取り入れてみた話

この記事はfreee Developers Advent Calendar 2021の22日目です。

こんにちは。freee申告を開発するチームのマネージャーをしていますizumiです。

今日はその申告ヨットで取り組んでいる「スクラム採用」についてお話したいと思います。

スクラム採用とは？

「スクラム採用」でググるとたくさんの記事や広告が表示されます。その内容をみていくと、「採用チームだけでなく現場の社員達も一緒に主体的に採用を行うこと」で採用成果を創出していくための手法で、株式会社HERPさんが提唱されているようです。

その定義に当てはめるのであれば、freeeは創業したときから今までずっとスクラム採用をやってきました。

採用チームだけでなくエンジニアも自分達で候補者を探し、採用チームとエンジニアマネージャーでデータをみて振り返り、採用面接やカジュアル面談なども多くのエンジニアが皆で取り組んできました。

今回私たちのチームで取り組んだのはそうではなく、普段開発プロセスとして採用しているスクラム開発手法をしっかりと採用にも取り入れてチームで取り組んでみるというもので、実際に今年の7月から実施しています。私はこれをfreee版スクラム採用と呼んでいます。

freee版スクラム採用に取り組んだ背景

freeeに限らず成長企業であればどこでも同じだとは思いますが、多くの優秀なエンジニアを採用することは会社の成長スピードを加速させるためにも、自分達が目指すプロダクトビジョンを達成するためにも非常に重要です。

しかし、エンジニア採用市場の厳しさと毎年増え続ける採用計画により、会社の規模が大きくなるからといって採用の難易度は下がるわけではなく、むしろ採用ハードルを下げずにカルチャーマッチする人材を採用し続ける難易度は高くなっている感覚があります。

申告チームでもなかなか採用が進まずに苦しんでいました。（今も苦しんではいますが）採用エージェントの方への説明、社員への紹介依頼、そして採用媒体に載っている人で話をしてみたい人をピックアップしてスカウト送信するなど日々取り組んではいるものの、どうしても普段の業務が忙しいなかでやらないとはいけないとは思いつつも、面接・面談以外の採用活動は後回しになりがちで、チームとして主な活動となる採用候補者の検索とスカウトに関しても、採用計画から逆算した必要なスカウト数や面談数を確保できずにいる状態でした。

採用ももちろん大事ですが、エンジニアの本業はプロダクトを開発することです。採用を強制感なくチームで楽しみながら進めていきつつ、ただ採用に使う時間を増やすことでリカバリをする以外に良い方法はないものかと悩んでいました。

そんな中、エンジニアではないfreeeのあるチームで採用がうまく進んだのでその秘訣を聞くと、採用隊長が採用チームと毎週振り返りを実施してボトルネックの洗い出しや対策を行うこと、そして数字や情報の共有をしっかりやるというものでした。

振り返りと状況の見える化の旗振り役。これってなんだかスクラムマスターみたいだなと感じたところから、開発チームの採用活動に本格的にスクラム開発手法を取り入れてみてはどうだろうかと思ったのがこの取り組みを実施するに至った背景です。

スクラム採用での役割

今回実施しているスクラム採用プロセスでは、役割は明確には定義しませんでした。

例えばプロダクトオーナーに該当する採用オーナーのような役割を定義することも最初は考えましたが、実際には採用という明確なゴールがあるので細かな意思決定や調整は必要ないこと、そしてスクラム採用に参加するチームメンバー自身が面接官でもあり、それぞれが採用の決定権を持っていることなどもあり特に明確にしないことにしました。

採用スクラムマスターに関しては私がやっています。実際にはプロセスの設計やファシリテーション、やっていきの表明などは開発マネージャーでもある私が行い、スクラムイベントで参照するためのデータの整理やプランニングの準備は採用チームが行っています。

今後よりプロセスが慣れてきたタイミングで、役割を明確にして開発プロセスでのスクラムマスターの疑似体験をエンジニアメンバーが経験するなども面白いなとは考えています。

スクラム採用イベント

スクラムイベントとして採用したのは、スプリントプランニング、スプリントレトロスペクティブ、スタンドアップミーティングの３つです。

採用デイリースクラム(朝会)

採用デイリースクラムは簡易的なものです。コロナでリモートワークが中心というのもありますが、slackでやること・やったこと・気づきや困ったことなどを共有しています。

プロダクト開発のための、本当のデイリースクラムミーティングも毎朝行っていますので、採用のデイリースクラムは簡易的なものにしています。もしこれがコロナではなく全員出社していたとしてもslackでのやりとり程度にしていると思います。

また、開発チームの主要な活動である、採用媒体から話をしてみたい人を検索してピックアップした件数を毎朝Slack botが投稿するようにして状況の可視化をしています。仕組みはすごく簡単で、スカウト候補者をGoogle Spreadsheetで管理しているためGoogle App Scriptを使って毎朝10~11時の間にslackに投稿するようなスクリプトを用意しています。

botがメンバーごとのスカウト数を投稿しているSlackのスクリーンショット

採用スプリントレトロスペクティブ(振り返り)

毎週金曜日にプランニングと合わせて、開発チームと採用チームが参加して実施しています。まずは最初にデータを眺めていきます。スプリント内でのスカウト送信状況、返信状況、スカウト媒体ごとの数字、候補者のパイプライン状況、面接官ごとの面接数、辞退発生状況などなど。そして、前スプリントで発生したTry(改善事項)の取り組み状況なども確認していきます。

少しでも楽しみながら採用活動をやれるようにと、スカウト返信王決定戦も実施しています。スカウト候補者から返信がきた場合に、その候補者を最初に見つけた人にポイントが入る制度です。 3ヶ月ごとに区切ってスカウト返信王には私から豪華景品を贈呈するということにしています。ただし、もうすぐこのスクラム採用を初めて最初の3ヶ月が経つのですが、今のところ私がスカウト返信王になるのが確実なので、豪華景品の贈呈はなくなりそうです(笑)

その後は振り返りを行います。デイリースタンドアップで出た気づきや困りごともここで拾いながら振り返ってTryを出していきます。

例えば毎回ではないですが、スカウト送信するか迷った候補者の目線合わせやペルソナ作り、返信率が高いメンバーがどういうスカウトを行っているのかを分析したり、モブプロならぬモブスカウトみたいなことをやることもあります。

十分にはまだまだできていませんが、これまでマネージャーと採用チームだけでやることが多かった候補者のペルソナ作りや募集要件決めなどを短い時間ながら全員でもやることで共通認識を高めていく効果があると期待しています。

採用スプリントプランニング(計画)

レトロスペクティブの後にそのままプランニングを行います。媒体によっては採用チームの方でリストを用意する必要や、期間限定の媒体もあったりするので次のスプリントで誰がどういった媒体でスカウト候補者を検索するかなどを決めていきます。優先順位を確認して、アバウトなアサインを決めて終了します。

やってみてどうだったか

まだ開始してから3ヶ月というタイミングではありますが、成果には繋がっています。スカウトがあきらかに増加し、採用候補者やカジュアル面談の件数も増えています。とはいえ、最終目的である採用決定者の数はまだまだ満足できるような状況ではありません。

エンジニアは当然高い技術スキルとプロダクト開発において優れた能力とマインドを持った人たちですですが、freeeでは一緒に働く優秀なエンジニアを自分達で採用するんだというカルチャーができてはいます。

それでもやはり、一歩間違えば採用候補者探しや面接などをめんどくさいと思ってやりたくないとなってしまい、採用活動がエンジニアのモチベーション低下を招いてしまう危険性のあるものだとも考えています。

チームメンバーには、日々のプロダクト開発に加えてこうしたスカウトや面接などの採用活動で多くの苦労をしてもらっていますし、もしかしたら全然できてないよと怒られてしまうかもしれませんが、このスクラム採用を通じて少しでも楽しみながら、チーム全員で一緒に働きたいと思える優秀なエンジニアを採用するぞというモチベーションで採用に関わってもらいたいなと思っています。