求められるエンジニア像
戸倉 御社で求められるエンジニア像を教えてください。もちろん、エンジニアに期待していることは年々ITの進化とともに変わっていくと思いますが、それをどういうふうに伝えていこうとしているのか、そのあたりも。
長瀬 ベーシックに変わらない話でいうと、10年くらい見てきて技術者の資質として1つ思うのは、とにかく知的好奇心や探究心がある技術者がやはり長い目で見ても伸び続けるということ。そこは技術者を見る際にものすごく大事にしています。もう1つは、サイバーエージェントには性格がいい子が多いと言いましたが、人格面を正しく見ていくということ。この2つがポイントになります。
それこそ、技術的な発展、これからの未来という軸で考えたときに、今は小学生がスマホのアプリを作る時代じゃないですか。もう5年くらい経つと、プログラミング歴10年みたいな子が普通に新卒で入ってくる。つまり、普通に技術ができるだけでは価値がない時代が来るかもしれません。そういう意味でいうと技術者のバリューが、サービスや経営、ビジネス視点を持った技術者という軸と、もう1つは技術者のために技術を作れるとか、ブロックチェーンとか、これまでにまったくなかった価値を新しく技術で生み出せる、そのどちらかに寄ってしまうと思っています。それ以外はインプリメーションするだけの技術者という感じになると思うので、2つのバリュー、いずれかを出せるような技術者を発掘し、評価、支援をしていきたい。そういう意味で、OSSの活動をもっと会社の中で評価していこうとか、いろいろな社会に合わせた形への対応というのが会社としては大事になると思っています。プログラミングができたら即採用していた時代から考えると、本当に変わりましたね。
戸倉 昭和、平成、令和生まれのエンジニアが混ざっていく中で、今後、女性、男性だけではない、世代的なダイバーシティといったところをどうインクルードしていくのか。逆に、「いろいろな人たちが混ざっているからこそやれること」をどう見つけていくのか、が課題になっていくと思います。サイバーエージェントの中では、そういった活動や考え方は生まれていますか？
長瀬 明確に1つ決めていることは、年功序列がないということ。たとえば、サイバーエージェントでは新卒1年目をテックリードに抜擢することも普通にあり、その下に10歳近く年上のエンジニアが付くという状況もあったりします。プロジェクトの中、エンジニアの中、全社の中でのコミュニケーションにおいても年齢は意識しない。もちろん、エンジニアの評価に関しても、です。若い人でいい人材がいたら抜擢してチャンスを与えるし、それを妬む年上の技術者もいません。もともとビジネス職がそうです。文化として普通に行われてきた会社なので、技術者の中でも当たり前になっていたりはします。社内のグレードも年齢なんて見ていないですし。逆に、いわゆるベテランと呼ばれる技術者は何より業界の中での経験を持っている。その経験が会社の中ではものすごく生きるので。
もともとビジネス職が中心で、新卒文化で会社が作られている中で、エンジニア職も新卒が軸になって会社を引っ張っていくという形になっています。そこに中途、ベテランも普通に入って、切磋琢磨しあっている。何よりお互い尊敬しあっているというのが一番いいかなと思います。
戸倉 社内でいろいろな経験をして、インスパイアされている方が外に行って、やりたいことをやっていく。その際、最低限注意してほしいことなどのルールはありますか？ たとえばセッションスライドへのロゴの入れ方や、キャラクターの扱いなど。
長瀬 少し反省している部分でもありますが、技術的なもの、個人の活動、いろいろなものに対し、統制を取ることよりも任せる部分が多くありました。よくも悪くも性善説に則って、いろいろなものをゆるく決めようというのが、うちの社風の大前提にあるので。そろそろ最低限決めたほうがよいというものを、みんなと相談しながら決めているところです。すでにやっている人にヒアリングをして、それを吸い上げてベストプラクティスという形で広めていくというのがよいのかなと思います。
「Developer Experts」[2]のような制度で社外でも活躍してくださいと推奨するのはけっこう象徴的で、このようなモデルケースを会社が打ち出すことで、それを真似て若手の技術者の活動につながります。これらを通じて、何かいい形でみんなが理解を深めてもらえるといいなと思っています。
実際、「（サイバーエージェント社員の）OSSを見ました」という学生さんも増えてきています。フリースタイルで自由にやらせていた甲斐があったような気がします。iOSやAndoroidの大きなカンファレンスの日は、その部門のエンジニアが丸ごといないのも普通になりましたね。
戸倉 そこまで自由に参加できるんですね。
長瀬 むしろ参加しろと言っています。チケット代も会社で費用をサポートしますし。地味ですが、エンジニアに寄り添っていろいろ聞くと求めていることを教えてくれるので、極力、会社として、正しく今の時代にあったものをやっていければいいのかなとは思っています。
戸倉 今回の書籍の中で「DevRelの3C」というフレームワークでDevRelの活動を定義し、取り上げています。Code（技術的なリソースになるもの）、Contents、Communityで3C。自社のエンジニアの社外での活動に対して、特にどこに力を入れてほしいと思いますか？
長瀬 技術はサービス開発、世の中のために使って貢献することで意味を成すというのが大前提としてあるので、基本的にはそこを軸に置いてほしい。その上で、技術を共有する活動や、何かを広めていく活動をするなどの時間の使い方は個人に委ねています。何がエンジニアとしての成長につながるのかは、その個人の状況や目標設定の中ですり合わせていくという形ですね。
[2] サイバーエージェントの技術支援制度の1つ。特定の領域における突出した知識やスキルを持ち、第一人者として実績を上げているエンジニアに新たな活躍の場を提供し、その分野の発展のための貢献およびサイバーエージェントグループへの還元を目的とするもの。この制度自体もエンジニアからの提案によって生まれた。
左：長瀬慶重氏、右：職業「戸倉彩」氏
『DevRel エンジニアフレンドリーになるための3C』
著：職業「戸倉彩」、中津川篤司、小島英揮
編：大内孝子
価格：本体2,200円＋税
マーケティング・営業・採用担当者必携！
あなたの会社・製品を、エンジニアに好きになってもらうための極意
DevRel（Developer Relations：開発者向け共創マーケティング）とは、「自社製品・サービスと、外部開発者・ユーザーとのつながりを作り上げる活動」です。 具体的には、エヴァンジェリスト、アドボケイトと呼ばれる人を中心にコミュニティを形作り、コミュニケーションを取りながら、自社製品を良くしていく(そして宣伝する)活動が一般的です。
本書は、DevRelのスペシャリスト3名による、
- マーケティング／営業／採用担当者が
- DevRelの概要・必要性を知り
- 「今すぐ」自社で始められるノウハウや必要なもの／ことを知る
ための書籍です！
