記事の内容
会社は、どれかのパターンを選択しなければいけない
3つの採用パターン
- エンジニアを社員として採用する
- 他社に全てをアウトソーシングする
- エンジニアを社員として採用して、一部をアウトソーシングしたりSESを雇う
IT系のアウトソーシングには自由度とコストのトレードオフ。
変更が多いシステムなのか、少ないシステムなのか？
また、アウトソーシングをしても各種の決断の最終責任は自社に残り、常に一定の管理・監督・判断をしなくてはならない。
正社員のITエンジニア採用のシンプルな原則
以下の内容は、「正社員のITエンジニア」を採用したい人に向けたものです。
ITエンジニアが重視するのは成長機会
ITエンジニアにとって、自分のスキルは最重要の資本である。
これを大きくしていくことは、人生の戦略上、もっとも基本的な目標。
エンジニア目線の「成長」と事業の「成長」は異なる
経営者；事業が成長して儲かって欲しい。
エンジニア；自分の技術的なスキルが成長して欲しい。
この２つのギャップを埋めるためには、高給だったりストック・オプションが有効だと思ってる。
経営者の「事業が成長したら、あとで従業員に還元する」という言葉は、ただの空手形で全く信用できない。
ITエンジニアに関連するスキルにも２つある。
4つの成長機会
- 技術的にも、事業スキルも成長できる。
→ 理想 - 技術的に成長できるが、事業スキルは成長しない。
→ エンジニア的にはOK？ - 技術的には成長できず、事業スキルは成長する。
→ 経営者とエンジニアの間で、齟齬が起こりやすいところ。
できるエンジニアほど、この環境には長くいない - 技術的には成長できず、事業スキルも成長しない
→ 絶対にいたくない
技術的な成長機会の詳細な説明
| 項目名 | 成長できる | 成長できない |
|---|---|---|
| 触るシステムの 種類 |
時期により、いろいろなシステムを触ることができる | ずっと1つのシステムを触る |
| テーマの 変化 |
いろいろな課題に取り組み、新たに問題解決する日々 | 日々のタスクに新しいことが少なく、決まった手順でオペレーションをしている |
| 扱う技術の 種類 |
複数種類の技術を扱える | 特定の技術のみ |
| 扱う技術の 新しさ |
新しい技術に触れる機会がある。 バージョンアップにも積極的 |
古い技術のみ。 コスト節約や安定稼働のためにバージョンを固定している |
| 扱う技術の 汎用性 |
世界的なスタンダードや、その候補となっているオープンな技術が多く、転職しても活用できそう | 自社の独自フレームワークなどを使っており、覚えたことの大半が転職したら無価値になる |
| 仕事の範囲・ 大きさ |
大きな目標に向かって、アーキテクチャの選定・設計などの上流・初期段階の活動に参加できる | 仕事が場当たり的で細切れで、まとまった作戦に基づいて取り組む機会が少ない |
| 仕事の 難易度 |
難しすぎず、簡単すぎない。 または、難しくはあるが相談相手がいて何とか進めることができる |
簡単すぎる。 または、本人にとって難しすぎる上に相談相手もおらず、物事を進められそうもなく思える |
| 仲間 | いろいろな技術者と仕事ができ、刺激を受ける。優秀な技術者と一緒に仕事ができる | 一緒に働く技術者仲間が少なく、固定的で、刺激を受けることが少ない |
| 社外活動 | OSS開発や勉強会といった社外的な活動に理解があり、支援がある | 社外での活動がしづらい |
| インターネット | インターネットを自由に利用でき、SNSなどを使って知人と情報交換を手軽に行える。 ブログなども自由 |
職場から自由にインターネットを検索したり書き込んだりといったことができない。 個人的な活動も良い顔をされない |
| 技術的な 業務の割合 |
ITエンジニアリングに費やす業務時間が多い | 管理・事務・営業・サポートなどITエンジニアリング以外の業務の割合が高い |
触るシステムの種類
様々なシステムをローテーションさせるようにするとか？
もしくは、エンジニアのポジションを変えてみるとか？
サーバーサイド、フロントサイド、Android、iOS、サーバー管理者など、一つのシステムでも多くの職種がある。
本人の希望にそって、ローテーションさせるのも面白いかも？
テーマの変化
ルーチンワークを正社員にやらせてたら飽きてしまう。
それでも、どうしてもやらないといけない作業もある。
できるだけ自動化した上で、その上でSESを雇ったりアウトソーシングに出すのがよさそう。
そして、正社員には、より生産性が高い別の仕事を渡す。
高いお金で雇う外注を、消耗品として扱うべき。
別にぞんざいに扱えという意味ではないけど、お金や雇用期間とのトレードオフという意味。
扱う技術の種類
Web系ならphpだけでなく、Railsとかにも触れると嬉しい。
勿論、Javaとか他の言語もあるにこしたことはない。
最近なら、AndroidにKotlinを導入するとか。
エンジニアのレベルにもよるので、常にエンジニアとコミュニケーションを取りながら、その時々に最適解を選んでいきたい。
扱う技術の新しさ
Dockerだったり、AWSだったり。
他にも新しいものは次から次へと出てくるけど、エンジニアが使ってみたいというなら、新しい技術を是非とも取り入れて欲しい。
そのシステムの重要性にもよる。
あと、Rails4からRails5にupdateしたいと言った時にも、先々のことを考えて許可してあげたり。
経営側からすると、その辺りのメリットが見えづらいので話しあいが必要ですね。
扱う技術の汎用性
独自フレームワークほど、汎用性の低いものはない。
あと、有料のフレームワークとかね。
楽々フレームワークとかいうのを思い出した。
一つの会社でしか使うことはなかった。
できるだけオープンな技術を使いましょう。
仕事の範囲・大きさ
上流から入れると嬉しいよね。
Platform、フレームワーク、言語の選定から始まり、要件定義やDB設計を行う。
初期段階から入って、実装して納品まで関われるのが最高。
逆に駄目なパターンは、ただの引き継ぎだったり、運用・保守とか。
仕事の難易度
これはエンジニアのレベル次第なので、しっかりとコミュニケーションを取りましょう。
仲間
１人でやる作業はつまらない。
チームでやる仕事の方が、お互いに成長を感じられる。
社外活動
できる人にとっては、OSS活動とかブログとかの活動は許されてる方がいい。
インターネット
社内でサイトの閲覧を禁止している場合もあるけど、よほど、みんなが遊んでいる場合を除いては本人達の自主性に任せましょう。
技術的な業務の割合
できるだけ、エンジニアリングに関われるようにしてあげるべき。
それができないなら、エンジニアリング以外の仕事を別の人に委譲してあげるとか？
「技術的な成長機会」を提供できる会社に変わるための戦略
3つの戦略
- エンジニアとコミュニケーションを取って、意見を聞いてみる。
- CTO的なポジションになれる、いいエンジニアを雇う。
- 付加価値をつける。
フレックス制、リモートワーク、海外勤務、高い給料など
こうやって並べて見ると、エンジニアからすると当たり前のことだけど、できていない会社が多い気がします。
あと書いていて思ったのが、「コミュニケーションをする」という項目が非常に多い。
何をするにしても、コミュニケーションありき。
そのため、コミュニケーションした上でエンジニアの声を積極的に拾っていけば、結果として「エンジニアの採用」は上手くいく気がします。
まとめ
この記事では、主に正社員の採用方法に関する考え方ついて説明しました。
Good luck with your engineer life!
