エンジニア採用活動にスクラムを導入した話
こんにちは、プログリットでインフラエンジニアをしております inady です。
はじめに
こちらの記事では、プロダクト開発部（エンジニア部門）における採用活動の改善について紹介したいと思います。
採用活動における課題
今までの状況
プロダクトが増えエンジニア組織の拡大が必要になる中で、前期エンジニア採用人数の目標を掲げエンジニアチームとしても動いていました。ただ、実績としてはなかなか厳しい結果となりました。
この状況を改善するため、外部のコンサルティングを活用する案を提案したのですが、CTOのShimaさんから「まず自分たちでやれることを、改めてやってみませんか？」というフィードバックをもらいました。
私はこのフィードバックを受け、まずは課題の洗い出しから着手しました。
明らかになった課題
採用活動は、採用チームのメンバー1人とエンジニアチームのメンバー3人の計4人で行っていました。
今までの活動を振り返って分析した結果、次のような課題が明らかになりました。
チーム間のコミュニケーション問題
採用チームとエンジニアチームは異なる組織に所属しているため、作業がある意味で「投げ渡し」のような状況になっていました。
具体的には、採用チームから「スカウトをX件送ってください」という依頼を受けて対応する形になっており、エンジニアチームにとって採用活動が「自分ごと」として捉えにくい状況でした。
その結果、改善活動がなかなか進まないという問題が発生していました。本来は1週間に何件スカウトを送りたいという目標があるにもかかわらず、業務の忙しさや差し込みの依頼により後回しになってしまうことが多かったです。
もちろん、エンジニアチームも「採用が非常に大事で、最優先事項である」ということは頭では理解しているものの、どうしても自分の開発業務を優先してしまい、採用活動が後回しになりがちでした。
また、定例会議も数値共有に閉じてしまい、具体的な改善活動はほぼ手付かずの状況でした。
スクラムフレームワークの導入
これらの課題を解決するため、今期からエンジニア採用活動にスクラムの枠組みを導入することにしました。
プログリットには FIVE GRIT というバリューがありますが、その中の「Own Issues (課題に対して当事者意識を持ち、解決に導きます)」の考えかたをエンジニア採用に取り込むには、スクラムが最適だと考えたからです。
スクラムチームの定義
まず最初に取り組んだのは、スクラムチームの明確な定義です。
エンジニアチームと採用チームという別々のチームではなく、「ワンチーム」なのだ、という意識づけから始めました。
具体的には、Notionにエンジニア採用スクラムボードを作成し、全員で課題を解決していくという体制を整えました。
また、スクラムのキックオフミーティングでインセプションデッキ(我々がなぜここにいるのか)を話し合うことで、認識のすり合わせを実施しました。
スクラムの3つの柱の実践
次に、スクラムの3つの柱である「透明性」「検査」「適応」を適用しました。
透明性の確保
各メンバーがやっている作業が見えるようにするため、すべての作業をチケット化しました。
エンジニアチームが今までほぼ把握できていなかった採用チーム側の作業も含めて同じタスクボードに配置し、とにかく作業を見えるようにすることを大事にしました。
検査と適応のサイクル
3週間に1回のスプリントを回し、スプリントごとに振り返りを実施しました。
振り返りで上がった課題点を見つけて、次のスプリントでは「必ずその課題から着手する」というサイクルを通じて、採用活動自体のプロセスも徐々に改善していきました。
例えば、「目標スカウト数を送りきれなかった時の原因分析フレームワークを確立する」とか「面接前の事前準備をNotion AIで自動化する」などといった改善活動をおこなってきました。
スクラムで達成した課題の改善
ベロシティの見える化
振り返りの中で効果が高かった改善活動の一つが、ベロシティの見える化です。
ベロシティとは、スプリント内でチームが達成できたタスク量の指標で、これまでのスプリントで消化したポイント数をもとに、今後のスプリントで達成可能な目標を設定するのに役立ちます。
最初の1〜2スプリント目は、スクラムをやっている新鮮味があり、積まれたポイントを消化しようというマインドが維持できていました。
しかし、エンジニア全員が兼務で採用活動を行っているため、徐々に業務の忙しさに負けてやらなくなってしまうという課題が発生しました。
この課題を解決するため、Slackに毎日、理想のポイント消化数と実際のポイント消化数を自動で投稿する仕組みを作りました。
これにより、全員が「今どれくらいビハインドしているのか」もしくは「進んでいるのか」を可視化できるようになりました。
また、ただ自動で送っているだけだと、これもやはり新鮮味がなくなって「ただ通知が来るだけ」となってしまうので、時折スクラムマスターの私がコメントを入れるようにしています。
その結果、忙しい中でも時間を確保してスカウトを送ろう、というようにマインドが変化してきました。
タスク管理方法の変更
もう一つの大きな変更は、タスクのアサイン方法です。
以前は「Aさんはスカウトを今週x件送る、Bさんはx件送る」というふうに、個別にタスクをアサインしていました。
しかし、スクラム導入後は、「タスクは誰が着手してもよい」という前提を全員で共有し、進捗を見ながらチームで助け合い、自分で自分のタスクをアサインする方式に変更しました。
この変更により、例えば障害対応や体調不良等でメンバーの1人が対応できない場合、他のメンバーが代わりにスカウトを送るといった柔軟な対応が可能になりました。
最近では、採用チーム側のタスクに関しても、エンジニアチームが「やれるところありますか？」と確認しながら進めるなど、ワンチームでスクラムらしい動きが出てきています。
プロダクトオーナー（P.O.）の明確化
もう一つ重要な改善点として、P.O. を明確に定義したことがあげられます。
以前は、採用チームとエンジニアチームがそれぞれの領域ごとに決定権を持っていたため、「どちらの判断が正しいのか」「どちらの決定事項が最終判断なのか」が分からないという課題がありました。
これを解決するため、採用チームのYoshitakaさんに P.O. を明確にお任せし、意思決定ラインを統一することにしました。
例えば、「面接前にコーディング課題を提出してもらうプロセスを設けるかの議論」なども、以前であればエンジニアチーム側で最終意思決定をしていたのですが、これらも採用チームのYoshitakaさんに最終決定いただくようにし、意思決定の統一と最終判断の一本化ができるようになりました。
スクラムマスターの私としては、
「Yoshitakaさん、この件どうしますか？」
とか、
「Yoshitakaさん、3ポイントほどタスクを減らしたいのですが、どれにしますか？」
などと積極的に最終判断を仰ぐように意識しています。
なお、「P.O. が判断できるような材料を揃えるのはスクラムメンバーの役割である」という点は付け加えておきたいと思います。
導入後の効果
現在導入から約4ヶ月経過しましたが、前期に比べてかなり良い進捗で進んでいます。
それに加えて大きな効果としては、採用チームとエンジニアチームが本当の意味でワンチームとして動けるようになったことです。
タスクの「依頼」ではなく、「チーム全体の目標達成に向け全員で協力し合う意識」をスクラムというフレームワークを活用することで自然にできるようになりました。
スクラムとは、一般に「プロダクト開発」において使う印象があるかたも多いかもしれません。しかし、採用活動の領域でもスクラムの原則を適用することで大きな改善が得られることを実感しました。
We are hiring!
というワケで…
プログリットでは、プロダクト開発のメンバーを募集しています！
「世界で自由に活躍できる人を増やす」というミッションに共感してくださる方、組織の中でお互いに切磋琢磨しながら成長していきたいという方は、ぜひカジュアル面談でお話しましょう！
