「2020年のエンジニア像 ～ エンジニアがこの先生きのこるには？ ～ powered by AWS」と題されたイベントに行ってきました。
どの方の話も「えー、そうなの！？」という驚きよりは「だよねえ。」「なるほど。」という感じで長谷川にとって共感フルな時間でした。
以下に長谷川が気になった、刺さったポイントを後からの振り返りのためにもまとめておこうと思います。
聞き違い、意図違いなどあれば長谷川までご連絡ください。
1部 各スタートアップによる、教育制度・評価事例紹介
1. 株式会社クラウドワークス 開発担当取締役 野村さん
- サービスローンチまでは開発に注力することが出来るので開発が進む。ローンチ後は運用などすることが増えて開発が進まなくなり「採用圧力」が強くなり採用したくなるがガマンが必要。
- 採用基準として重要視しているのは事業にコミットメントできるかどうか。
- その他の基準としては「持続的に成長している会社出身」「スタートアップ経験者」「自分のプロダクトを持っている」
- 自分よりすごい人を雇用しようと心がけている。そのために現CTOにCTO職を譲り渡してジョインしてもらった。
- スタートアップは採用が難しいので露出が大事。マスメディア、プレスリリース、イベント登壇、勉強会（社内/社外）
- オフィス内のコミュニケーションツール紹介。ChatWorkにGitHub, Redmine, SEMAPHOREからフィードを流す他、2ch, Twitterのキーワード検索結果も流している。
- 新機能リリースやリファクタリングなど節目でオフィス内に設置した銅鑼を鳴らす。
2. Sansan株式会社 開発部長 藤倉さん
- 「任せられるエンジニア」「背中を預けることが出来る人」「技術力より実務能力（コミットメント）」
- エンジニア採用では絶対に妥協しない。→ 時間がかかる。 → 加速させる仕組みが必要。
- 露出。メディアに出る。
- ダイレクトリクルーティング。責任者（藤倉さん）が交流の場に出ていく。
- 人事部、広報部の協力。勉強会立ち上げや登壇機会の獲得も人事部が行っている。
当日の登壇者の中で最年長ということだったけど長谷川と同い年。そうか自分はもう最年長の部類になっているのか、と思いました。
3. 株式会社nanapi CTO 和田さん
- エンジニアやリーダーからなるチームをまず作り、そこから事業が作られるスタイル。
- 学習も業務のうち。社内からコードを書けない人間を減らす。
- 学び続ける姿勢を重視。生き残るのは変化できる者だ、という理論より。（ダーウィン）
- 採用は運と縁。なので継続的に採用活動は行う。
- 採用基準はWebやテクノロジーへの姿勢。技術が好きか。
- 「必殺技」（これなら負けない！という尖った部分）があると良い。
- 採用活動はファーストコンタクトから始まっている、という理解。直接募集の応募者に対して和田さんからメールをしていた。（現在進行形？）
- 面談の際には初回面談から和田さんが参加している。
採用を「運と縁」と表現されていたのは本当にその通りですね。他の登壇者も基本的に同じことを仰っていますがそれを表現する言葉としては「運と縁」が一番スッキリ共感できました。
4. クックパッド株式会社 館野さん
- エンジニアの評価制度にフォーカスしたプレゼン。
- 評価軸は「部室（部署）の目標にどれだけ貢献したか」という縦軸と「エンジニアとしての技術力」という横軸。
- （クックパッドの）ユーザの問題発見・解決を主体的にできているか。 / 誰にも負けない分野で仕事をできているか。 / シンプルな設計をできているか。 / 社内外の開発者全体に貢献できているか。
- 評価は360度評価 → リーダー → 経営陣, 部室長と上げ、業績連動の賞与でフィードバックしている。
- 評価制度は「会社がどうありたいか」で決めており、定期的に増減（入れ替え）させている。
外から（特にエンジニア目線で）見ると技術の会社に見え、エンジニアからの人気も高くうらやましくも思っていましたが逆にそれが故の苦労もあるのでしょうね。
それでも「社内外の開発者に貢献できているか」というのは素敵ですね。
2部 パネルディスカッション、Q&A
モデレータ: アマゾン データ サービス ジャパン株式会社 松尾さん
#1 ベテランが若手エンジニアの成長速度に負けない強みを持ってこの先生きのこるには
- 技術は手段。知識と経験の行ったり来たり。若手は新技術を習得するという点を打つスピードは速いが、その点と点をつなぐという意味ではベテランの方が上手。（藤倉さん）
- 設計は経験がものを言う。機能・運用要件に対して必ずしも技術を使わなくても良いという総合的な判断はベテランの方が的確にできる。（野村さん）
- ベテランは技術のタテの積み上げでは若手に勝てない。それとは別領域のかけ算や仕事の総合力で勝負する。（和田さん）
- 過去に得られた知見からそれを活かしてものごとを「物事を前に進めていく」力はベテランならではのもの。（館野さん）
経験を積むことでデザインや物事の進み方・進め方はパターン化できることも多く、良い対応ができたり素早く対応できたりしますね。
ただ、「点々をつなぐ能力」「総合的な判断」「仕事の総合力」「物事を前に進めていく力」って早い人は20代後半で習得できるだろうと思うし、そうしたらさらに年上のエンジニアはどう戦おうか、というのはやはり気になるところです。
ビジネスパーソンが価値を上げるにはスケールアップ（自身の価値を上げる）かスケールアウト（他の複数の人の価値を上げる）しかなくて、加齢によって体力や学習速度という自身の価値を失ったエンジニアはスケールアウト方面に価値を求めるしか無いのか、そしてそうだとするとマネジメント的な領域に踏み込まざるを得ないのではないかなあ、と改めて思ってしまいました。
#2 テクノロジースタートアップ企業としてこの先生きのこるには？
- 変化をし続けることが組織全体で出来るか。（館野さん）
- 変化するという意識。それに対応出来る体制。（和田さん）
- （ここ数年でスマホが急速に普及したという話題を受けて）自分自身が変化に付いていけなくなったらまずい、と思った。（藤倉さん）
- ビジョンと風土以外は変え続けるものでは。（和田さん）
モデレータ松尾さん: 風土は意識して作っている？
- サービスのスローガンは毎週言っている。社外に発することで社内にも浸透させている。（野村さん）
- ミッションは全員言える様になっている。それに沿った行動が出来ているかを評価軸ともしている。（藤倉さん）
- 風土、教育、評価軸は一連のものでありそれがちぐはぐになっているとおかしなことになる。（和田さん）
赤ちゃんが雑誌のページを指でフリックしてページが動かないことを怪訝そうに見ている、なんて動画があったりしましたが、そういうスマホネイティブ世代が使うサービスを作れるか、使えるか。
#3 エンジニアに向けてひとこと
これ以降登壇者の発言に対応して頭を使い始めてしまい記録がおろそかに。
#3については省略します。どなたか～！
3部 質疑応答
ここも記録が出来ず強烈に覚えているところのみ…。
Q1. エンジニアは将来的にいなくなるか
参加者からの質問「新卒学生にヒアリングするとブラックなイメージなどが手伝ってエンジニアは避けられている様に思える。この先エンジニアはいなくなってしまうのではないか。」に対して、以下の様な意見がありました。
（無記名なところはどなたの発言か失念したところです。カッコいい発言もあるのにすみません。）
- 今でも鉄道（列車）を作る人がいる様にまったくゼロになることは無いだろう。
- 本当にプログラムを作るのが好きな人たちだけが残り、食べる手段としてイヤイヤやる様な人はいなくなるだろう。
- 「エンジニアはカッコイイ」という風潮になってきている。そう言う胃意味では増えるのでは。（和田さん）
- 昔は「エンジニアなのに服が好きなの？」とか「エンジニアなのに長髪なの？」とエンジニア=オタクと見られていたが今はエンジニアでもふつうにお洒落な人もいる。エンジニアを見る目は確実に変っている。（藤倉さん）
- エンジニアはクリエイタ寄りに見られる様になっているのではないか。
エンジニア（IT）を見る目が変ったタイミングは2つあったと思っています。
1つめは1995年～1997年ぐらいのインターネットブーム。「パソコンを使う」ことが一般的になり、特技:パソコンと書くことも出来るようになりました。
2つめは2004年～2005年頃のライブドア・楽天の躍進による一般からの注目。これはもっと強烈でITが憧れの対象にすらなり得るようになりました。（テレビドラマで出てくる「若いお金持ち社長」の会社がIT企業になりましたね。）
小学生の頃から紙にBASICのプログラムを書いていた様な「筋金入り」の自分から見るとエンジニアがカッコいい時代というのは本当に良い時代になったなあ、と思いますし、もっとそれが広がり、エンジニアが増えると良いと思っています。
ただ、本当にガリガリとプログラムを書くタイプのエンジニアは減っていくだろうとも思っています。本当にスゴい一部のエンジニアが、ふつうのエンジニアがプロダクトを作るための仕組みを作る、という時代になっていく、というのがその理由です。
登壇者のやりとりを聞いていて「エンジニア」をどの範囲と定義するかで増えも減りもするだろう、ということだと思いました。つまり、前述の「本当にスゴい一部のエンジニア」は減るが「ふつうのエンジニア」は増えるだろう、と。
そのとき「ふつうのエンジニア」が書くのが今のスタイルのプログラムなのか、もっと簡略化されたPowerPointみたいなツールで作るプログラムなのかはわかりませんが。
Q2. 採用にあたって言語にこだわりはあるか
- 全員、言語にこだわりは無いという立場。出来るエンジニアは何でも書ける。
- 募集要項にはRailsと書いているが、小さな所帯なので「Railsいいよね」ぐらいの価値観を共有するため。（野村さん）
モデレータ松尾さん: 応募者のソースは見ている？
- Railsのコードはレールに乗れているか、と言う意味で判断がしやすい。（野村さん）
- 必須にはしていない。だが非常に有効な判断基準。（藤倉さん）
- 必須にはしていないが今思うと採用に至った方はみんな見ている。（和田さん）
- ソースコード課題が必須。外に出していないが社内ではスーパープログラマ、という方はたくさんいるはずでそういう方の採用には課題が有効。（館野さん）
長谷川もよくソースコード審査や面接をしていますが皆同じことを考えているなあ、というのがこの質疑応答の感想でした。
デジタルサーカスでもソースコードの提出は求めています。提出できるソースコードが無い場合は履歴書・業務経歴書だけで判断して面談していますが、やはり判断がつかなく採用見送りとなることが多いです。
2部か3部で登壇者の方も仰っていましたが採用って「企業が個人を採用する」という1方向だけでなく、応募者の人生の一部を共にすることになるので判断ミスをして応募者の履歴書に短い経歴を付けてしまうことになるのをすごく恐れてのことです。
そう言う意味で館野さんの「課題を与えてプログラムの力を試す」というのは新鮮でした。
「出せるプログラムが無いので課題をください」というリクエストを仲介業者の方に頂くこともあったのですがそれに応えられる課題を作っておこう、と思いました。
イベントとしてはこの後懇親会があったのですがどうしてもサッカーの試合が見たくて後ろ髪引かれる思いで帰ってきました。
みんなが何を考えて何をしているのかを聞くのは面白いですね。
こんな機会を与えて下さった主催のスローガン株式会社さま、アマゾン データサービス ジャパン株式会社さまに大感謝。
そして登壇者のみなさま、パネリストの松尾さん、司会進行の伊藤さん、スタッフの皆様、そして参加者のみなさま、お疲れさまでした & ありがとうございました。
でもそれ以上に「自分よりすごいCTO」を招き入れるためにCTO職を譲り渡す、というのはなるほどなあ、と。CTO職を用意するというのは会社側の意思・覚悟の表れになりますね。
銅鑼も良いですね。長谷川は電子工作マンなので何かそういうの作りたいなあ、と思いました。電光掲示板みたいな。