エンジニア採用をキャパシティプランニングしよう

お久しぶりです。id:unlearned です。

会社では上杉で通しています。

このブログを始めた頃は、30歳ぴったりくらいだった気がするのですが、もう40代も半ばです。 冬の寒さも身にしみるようになりました。

今年はCOVID-19のせいで散々でしたね。しかし、せっかくのクリスマスイブです。楽しんでいきましょう。

さて、この記事は、hey アドベントカレンダー2020 の24日目の記事です。

僕は今年の終わり頃から、hey の CTO室 というところでお世話になっていて、エンジニア採用やらなにやらをいろいろ考えたりする仕事をしています。

あ、もちろん考えてるだけではなくて、いろいろやっているんですが、考えるというのはすごく大切なことです。

ご存知かもしれませんが、 弊社(hey社)は今エンジニアを積極採用中でして、来年も良い人たちと一緒に働けたらなと思っています。

さて、今日はエンジニア採用のオペレーションについて考えたいなと思います。

エンジニア採用オペレーションの難しいところ

エンジニア採用の難易度は、市場にいるエンジニアが少ないとか、そういう話だけではなくて、日々のオペレーションもなかなか大変です。

エンジニアの採用ともなると、やはり技術的な側面もちゃんと面接しなければなりません。 そうするとですね、日々ガリガリとコードを書いてるエンジニアの力を借りないといけない。

コードを書くにはすごく集中力が必要で、面接なんてしちゃうと集中力が失われて、それ以降コードを書けなくなったりする。 さらに言うとですね、リリース日程がタイトな場合もあったりして、そういう時にあんまりプレッシャーをかけたくない。

にも関わらずですね、世の「採用頑張るぞ」は、無策なことが多い。 無策はよくない。

21世紀にもなって「食料は現地調達」みたいなところが、我々日本人にはあるんじゃないかなと感じます。 そういう反省はもうこの本で十分です。

人間中心主義でいこう

そもそもね100人くらいの会社で30人採用とか、そういうの大きいことを考えるのはとってもいいことだと思う。

世の中の求人が増えることは、基本的には良いことだと僕は思っている。

いろんな工夫ができる。

エージェントさんにいっぱい紹介してってお願いするのも良い。社内でリファラル採用を進めるのも良いし、自社メディアを立ち上げたりも採用を進めるにあたってはすごく良いことです。

でもじゃあさ、目線を変えるとね、

「社内でそれ受け止めるキャパシティあるの?」

って話です。

よく人間を「リソース」って言葉で表してしまう人がいるけど、僕はあんまりそういう言葉が好きじゃない。

人間はモノでもないし、仕事だけをする機械でもない。

感情があって、家庭があって、母であり、父であり、友であり。 はたまた、時々疲れてたり、荒んでたりもする。 もうね、働きすぎちゃうと、消耗しちゃうんですね。 だから、余裕をもたないといけない。

ちゃんと職場に適切なゆとりをもたらすのが、マネージャーの役割の一つだと僕は思っている訳です。

そうなってくるとですね、採用オペレーションのキャパシティを予測して、適切に人員の配置や、効率化などをしないといけない。

キャパシティプランニング

ここで、やっとエンジニアっぽい話になるんですが、キャパシティプランニングってみなさんご存知でしょうか?

SREチームの方々は当然ご存知だと思います。

Wikipediaのサービスデリバリの説明の中に「キャパシティ管理」として近しい内容が書いてありましたので、引用します。

サービスデリバリ - Wikipedia

開発するサービスが性能要件を満たす為に必要なリソースやスループットを見積もり、サービスレベルに見合った機能とコストを試算する事、さらに運用が開始されたサービスについて定期的な記録を採り、IT資源の枯渇や応答時間の監視などを行い、サービスレベル維持の為の定期的な拡張やメンテナンスをプランニングしていく為のプロセスとして位置づけられている。

以下、ちょっと古い本ですが(なんだもう10年以上前かよぉ、、、)

僕はインフラもやっていたので、こういう本でキャパシティプランニングを学びました。

近年はAWSなどができて、サーバーの調達なんて考えなくて良くなりましたが、 昔は1ヶ月前には発注しておかないといけないとか、そういう事態がよくありまして、インフラエンジニアにとっては、死活問題になる知識でした。

コンピュータ資源のキャパシティプランニングのアイディアは、組織体制のキャパシティプランニングにも活かせそうです。

さて何にせよですね、自組織の体制が、採用プロセスを回せる状態にあるか、事前に予測しておきたい。

採用の全体感をつかむ

採用にはいくつかのフェーズがあります。 ざっとこんな感じかなと思います。

f:id:unlearned:20201223194230p:plain
採用フェーズ

この各フェーズでの数値を取っておくわけです。 来年からどうするかを考えている、リクルーティング担当者は今年の数値をちゃんと把握しておくといいですね。

あくまでも、選考という過程だけに範囲を絞ると、 エントリー数から入社までくらいで考える感じになるかと思います。

(今回は議論から外していますが、オンボーディングはすごく大事です。一番時間もかかりますので、ここはここでちゃんと考えておきましょう)

ゴールから逆算する

さて、選考の各フェーズごとに数値を取っておくと、通過率を出せます。

f:id:unlearned:20201223200353p:plain
各フェーズの通過率

ゴールから逆算することで、シミュレーションができるようになります。

簡単に言うと、選考の各フェーズの通過率の逆数を、採用数から掛けていきます。

下の図は、採用数をN人とした場合のシミュレーションになります。

f:id:unlearned:20201223201035p:plain
逆算

こうすると、最終的に、

  • エントリーがどれくらい必要か
  • 何回面接をする必要があるか
  • 必要な時間数はどれくらいか(面接にどれくらい時間がかかるかわかれば)

など実際の目標値や、負担を定量的に予測できるわけです。

やってみよう

さて、Microsoft ExcelGoogleスプレッドシートなどを取り出してやってみましょう。

来年の採用計画のキャパシティプランニングをして、効率化や面接官の補充など、プロセス改善に役立てましょう!!

しかし...

でもすごくだるいじゃないですか? エンジニアはExcel嫌いですよね。多分。

(僕はちゃんとGoogleスプレッドシートでやりました)

そこで

strife

だるいので、コマンドラインツールを作りました。

STatistical Recruiting Information For Engineers

GOPATHは適切に設定してあると仮定します。

$ go get github.com/unlearned/strife/cmd/strife

としてインストールします。

次に、以下のような感じでjsonファイルを作ります。ファイル名は任意ですが、ここでは、 recruiting_result_2020.json とでもしましょう

{
    "phases": [
    {
        "name": "entry",
        "number": 480
    },
    {
        "name": "document screening",
        "number": 160,
        "average_number_of_hours_spent": 0.2
    },
    {
        "name": "1st interview",
        "number": 80,
        "average_number_of_hours_spent": 1.5
    },
    {
        "name": "2nd interview",
        "number": 40,
        "average_number_of_hours_spent": 1.5
    },
    {
        "name": "3rd interview",
        "number": 20,
        "average_number_of_hours_spent": 1.5
    },
    {
        "name": "offer meeting",
        "number": 15,
        "average_number_of_hours_spent": 1.5
    },
    {
        "name": "join",
        "number": 10
    }
    ]
}
  • name は各フェーズの名前を入れます。
  • number は各フェーズのプロセスを行った回数、もしくは採用された人の数などです。
  • average_number_of_hours_spent はそのフェーズのプロセス1回あたりに何時間かかったかです。

あとは来年採用したい人数を決めましょう。ここでは仮に 30 とします。 そして、次のようにコマンドを叩きます!

$ strife 30 ./recruiting_result_2020.json                                                                                                                                                                                                                                        
## Past Performance ##
|         phase        |      entry      |document screening|   1st interview  |   2nd interview  |   3rd interview  |   offer meeting  |       join      |
|         number       |        480       |        160       |        80        |        40        |        20        |        15        |        10        |
|average hours required|         0        |        0.2       |        1.5       |        1.5       |        1.5       |        1.5       |         0        |

## Prediction ##
|         phase        |      entry      |document screening|   1st interview  |   2nd interview  |   3rd interview  |   offer meeting  |       join      |
|         number       |       1440       |        480       |        240       |        120       |        60        |        45        |        30        |
|average hours required|         0        |        0.2       |        1.5       |        1.5       |        1.5       |        1.5       |         0        |
| total hours required |         0        |        96        |        360       |        180       |        90        |       67.5       |         0        |

terminalで等幅のフォントを使っていれば、綺麗に出力されるかと思います。

これは僕が適当に作った情報ですが、上記より、この架空の会社の過去採用実績から鑑みるに、30人採用するためには、1440人のエントリーが必要ですねというのが見て取れます。 また書類選考だけで96時間、一次面接は240回、360時間かかることがわかります。

と、このように実績からの予測が作れるというわけです。

この予測をもとに、面接できる人を増やしたり、ホットスポットを見つけ効率化を行います。

まとめ

まとめます

  • エンジニア採用のオペレーションはエンジニアに負荷をかける
  • 負荷のかけ過ぎは良くない。人間は道具じゃない
  • 予測し、体制を組み、効率化を行うことをしよう
  • 予測のために
    • 構造を把握し、全体感をつかもう
    • 情報を得よう
    • 情報を利用して逆算しよう
  • スプレッドシートなどでやろう

以下余談

  • STRIFEってのは僕の好きなバンドの名前です
  • 今回Go言語初めて書きました。諸々拙い部分多いかと思いますので、教えていただけると助かります
  • README を書く前に力尽きました。なるはやで書きます
  • recruiting ってuの後にiが入るんですね。コード内に埋め込んでしまいました。なるはやで直します

最後に繰り返します。弊社(hey社)はエンジニアもエンジニア以外も積極採用中ですー。

以上です!良いお年をー

デザイン組織のつくりかた

デザイン組織のつくりかた デザイン思考を駆動させるインハウスチームの構築&運用ガイド

デザイン組織のつくりかた デザイン思考を駆動させるインハウスチームの構築&運用ガイド

  • 作者: ピーター・メルホルツ,クリスティン・スキナー,長谷川敦士,安藤貴子
  • 出版社/メーカー: ビー・エヌ・エヌ新社
  • 発売日: 2017/12/22
  • メディア: 単行本(ソフトカバー)
  • この商品を含むブログ (2件) を見る

2018年は結構大変な年で、僕の勤めていた会社の組織改編があった。

僕は光栄というか、成り行きという感じで、簡単にいえば、「開発組織の長」的な立場になったんだけど、その開発組織には、「プロデューサ」「デザイナー」「エンジニア」の3職種のチームが混在しているって感じ。

今まではエンジニアチームのことさえ知ってればよかった。というか逆に人生経験として、エンジニアやエンジニア組織のマネジメントしかやったことない人が、どうやって、組織をまとめればいいのさって話。

この本を語弊を恐れず、大雑把に言えば

  • 組織構造
  • コミュニケーション

をどのように抑えるかっていう基本が前提として、そこにデザイナーの仕事っていうのを理解して配置するって内容の本です。

ただし、デザインの重要性は理解しておく必要があるので、基本的にIDEOあたりの一連の本はよく読んでないと、コンテキストが不在になるので、やばい。

後で書く

ハーバード・ビジネス・レビュー公式ガイド 社内政治マニュアル

ハーバード・ビジネス・レビュー公式ガイド 社内政治マニュアル

ハーバード・ビジネス・レビュー公式ガイド 社内政治マニュアル

風通しのよい職場とはいいもんだ。

仕事はしやすいほうがいいし、社内政治があんまり巧妙なのはいやなもんだ。 僕はいい大人なんで、転職活動なんかもかつてはしたことがあるし、その上で言うんだが、

「ウチには政治とかないから」

とか言う会社には多分行かないほうがいい。社内政治がないなんてことはありえない。それは僕がそう言う環境に行ったことがないから、知らないだけだとか言う人もいるかもしれないが、そうじゃない。

このブログを読んでる君が、会社の上司か同僚かわからんが、そういう人の愚痴をこぼすとするでしょう、それが「社内政治」だ。 人間が共同で働いて行く中で、政治がないなんて状態はない。

時間でも、お金でも、モノでもいいけど、何らかのリソースは配分しなければならない。 論理に基づいていようが、それを誰かが判断する。 それは政治でしょ。必要悪ってやつかもしれない。

つまり、社内政治とは、どのように取り扱うかが全てだと思う。 先にでた、転職活動の例でいうと、つまり、政治というものに鈍感すぎるんだ。

この本はそう言った社内政治をどのようにハンドルしていくかという、 一種の攻略本だ。

基本原則としては、「正直に自分の気持ちをポジティブに話す」ということに尽きる

続きは後で書きます、、、

1 on 1をベースとした組織構造の提案

こんにちは!id:unlearned です。

今年は寒いですね。 暖冬説はなんだったのかと思っているのですが、四季があるのは好きです。

さて、この記事は、Engineering Manager vol.2 Advent Calendar 2018 の20日目の記事です。

1 on 1っていいよね。

ドラッカー曰く、

マネージャーを見分ける基準は命令するする権限ではない。貢献する責任である。
権限ではなく、責任がマネージャーを見分ける基準である。

さて、僕は1 on 1好きです。 1 on 1をやることで、信頼感を醸成できますし、みんなとキャリアについて相談できます。 また、ボトムアップのアイディアも吸い上げできますし、本当に良い。

すべての仕事は人間がやっています。 僕は、1 on 1が仕事に人間性を取り戻し、職場が活気づくなんともROI(Return On Investment:投資利益率)が良い施策だと考えています。

僕の職場でも、「1 on 1はチームに週一で1人30分程度でお願いします」という形にしています。

「1 on 1いいよね」だけじゃ収まらない問題

1 on 1はチームに変化がある時に効果を実感できると思います。 特にチームの人数が爆増してたりとかすると、チームビルディングの一環としてもとても良い。

一方で、1 on 1対象者が増えてくると、時間的な負担が出て来ます。 1 on 1のメンバーが10人ほどに増えると、1週間に5時間ほど、時間の確保が必要なります。これは週全体の労働時間の1/8に当たります。

1 on 1はROIが良いと思う反面、「人は1 on 1だけに生きるにあらず」です。

また、10人ものメンバーの話を聞くのは、実際にはかなりのエネルギーを消耗します。少なくとも僕は頭がパンパンになりますし、早く帰って眠りたい気分にはなります。

その上、10人もの人間を、人間は理解したり、そのために何かアクションが取ることができるでしょうか? 時に、「俺は何人の人間をマネジメントしてるぜ」と、担当する人間の数が多い自慢をするする方がいますが、現実には、1人あたりのメンバーのために費やす時間を薄く分配しているだけです。

機械的に問題解決もなく1 on 1することが、貢献と言えるでしょうか?

こいつは大変だ!

解決策

組織を考える時に、1 on 1対象メンバーが5人程度になるように、うまく配置/分割していくのが良いと思います。

なんで5人かというと、1日に1人と1 on 1をやるような感じです。

1日に1人と1 on 1ができるなら、1 on 1に全力で望めます。 加えて、一週間に1 on 1に使う基本的な時間も、2.5時間に抑えられます。 空いた時間で、ガンガン問題解決作業を行いましょう。

とはいえ問題

とはいえ、1 on 1を構造的に組織的に行うには、思いの外、問題がつきまといます。

まず第一に、今後1 on 1を他の人に任せることを、ちゃんとメンバーに伝えなければいけません。 また、そのことについて、納得してもらう必要があります。場合によっては、ひきつづき1 on 1を行い続ける誠実さも必要です。

二番目に、今後誰に1 on 1を任せていくのかは非常に重要な問題になります。しかしすでに、適切な1 on 1をされているのであれば、比較的スムーズに1 on 1を行うメンバーが見つけられるかもしれません。そういったメンバーがいた場合、しばらく、2 on 1形式を行うことで、スムーズに1 on 1に移行していくことができるでしょう。

三つ目として、組織が階層的になる可能性があります。 5人に絞るということは、5人のエンジニアリングマネージャーをさらに上位のエンジニアリングマネージャーがその5人と1on1を行うという形式になってしまいます。個人的に、これは非常に痛い。 対策としては、エンジニアリングマネージャーというのはあくまでも役割なのであって、偉さの階層ではないという認識を開発文化として浸透させる必要があるかと思います。

まとめ

  • 1 on 1ができる限界の人数をベースに組織を考えてみたよ
  • 1人のエンジニアリングマネージャーが1 on 1を行う人数って限界があるよね
  • 分割しましょう
  • 1 on 1の担当を引き継ぐ時には、ちゃんとみんなの納得感を得よう
  • 1 on 1を適切に行うことで、1 on 1を引き継ぐことが容易になります
  • 組織が階層化しないように気をつけよう

以上です。 わかりづらいので、あとで図を加えるかもしれません。

楽しく行こう!

文明はなぜ崩壊するのか

文明はなぜ崩壊するのか

文明はなぜ崩壊するのか

帯によると、トランプ大統領がレコメンドしている本らしいですね。 とはいいましても、本自体が2012年の本なので、まだトランプさんは大統領ではないですが。

さてこの本は文明というものに対してフォーカスしていますが、 実際にはこのアイディアは、ITシステム的なものであったり、会社だったりと、 システム一般に応用の聞くアイディアと考えられます。

文明が発展すると、システムが複雑になって、容易に問題を解決できないどころか、 問題を理解できないほどにまでなる。 その理解できない認識の壁を「認知域」と著者は呼んでいます。

それでも我々は問題を解決しようと奮闘するのですが、 それを阻むのが、社会的認知の壁、著者が「スーパーミーム」と言っているものです。 スーパーミームは綺麗にいえば

人々に受け入れられている、

  • 情報
  • 思考
  • 感情
  • 行動

に当たります。 もう少し、生々しい表現にするなら、

  • 常識
  • 伝統
  • 理論
  • 偏見

ということになります。 スーパーミームはバックグラウンドに伴う複雑さを隠蔽します。 「なぜ〇〇なのか」といった構造を理解せずに、丸覚えできてしまうので便利というわけです。

さて、著者は以下のようなスーパーミームがあるといいます。

  1. 反対という名の思考停止(不合理な反対)
  2. 個人への責任転嫁(非難の個人化)
  3. 関係のこじつけ(偽りの相互関係)
  4. サイロ思考
  5. 行きすぎた経済偏重

恐ろしいほど、現代日本を表しているようですね。

対処方法としては、短期計画がうまく言っている間に、長期計画を立てないといけない。 プログラミンで言うところのリファクタリングちゃんとしていかないといけない感ですね。

短期的な緩和療法では効き目がないので、

  • 並行漸進主義

的に、同時にガンガン緩和策をうつことで、まずは時間を稼ぎつつ、根本的な問題を解決するために

  • ひらめく

必要があると言うこと、というのが著者の主張です。

そのために、脳トレだとか、リラックスする時間が必要ですよと言う、 意外と最後は牧歌的になってしまったが、日本人には大切なように思います。

また、

  • 知識を獲得する
  • 知識を使って活動をする(ひらめきをうむ)

とひらめきが起こるための知識の統合を2フェーズに切っていて、 まーそうだよね、と思うのところもありました。

読んでいてとても楽しい本でした。 ついでに思い出を書いておくと、そこかしこで持ち歩いて読んでいて、 どっかに置き忘れてしまいなくしてしまったので、書い直してまで読んだ本です。

13歳からの反社会学 (角川文庫)

この本を読みました。 パオロ・マッツァリーノって人、かなり昔からwebページ持ってて、 統計から世の嘘を切ってた人なんだけど、語り口が好きでよく読んでました。

今回、初めて著作を購入したんだけど、あの頃のままのマッツァリーノでしたね。 全世代の13歳にオススメです

HARD THINGS

HARD THINGS

HARD THINGS

結構前に読んだ。 ベン・ホロウィッツのガンバリの結晶みたいな本。

「言うは易く行うは難し」ってやつですね。