若手エンジニアへの権限移譲はどうすべき？　ベテランCTOたちの育成論

聴衆が本当に知りたいこと

戸村憲史氏（以下、戸村）：ありがとうございます。続いて、もうみなさんにしゃべってもらったのですが、アンケートを取らせてもらった中から、多かった質問を4つ選んでいる状態なのですが、時間の関係で（全部は）聞けないかもしれないので、4つの中でどれが一番聞きたいかアンケートを取らせてもらえればと思います。

まず一番上、「理系・情報系以外がエンジニアとして活躍するには？」を聞きたいという方。1人もいない……。

（一同笑）

戸村：次、「勉強時間の確保方法とどこまで技術を理解しようとしているか？」を聞きたい方。

（会場挙手）

渡部拓也氏（以下、渡部）：人気ですね。

戸村：次が「組織づくり。実力アップのために各社が取り組んでいること」を聞きたい方。

（会場挙手）

戸村：こちらのほうがちょっと多いですね。次、「各社で若手エンジニアが活躍してる様子。歩んでいけるキャリア」を聞きたい方。

（会場挙手）

渡部：なるほど。

戸村：なるほど。ではさっそく、「組織づくり。実力アップのために各社が取り組んでいること」を柴山さんから。

柴山直樹氏（以下、柴山）：とくに若手という目線だと、よくあるとは思うんですけど、とにかく（権限を）移譲するということはすごく考えています。

リーダーになれば若手は伸びる

柴山：肩書きはなるべくつけないようにしようと思ってるんですけど、1回若手をどんどんリーダーに上げてしまう。うちのチームは3名ぐらいずつでいっぱい作っていくという感じなので、ある程度パフォーマンスが出せるようになったらすぐに（チームの）リーダーに上がれる感じなんです。そうやって目線を上げていくということをすごくやっています。

そのなかでもけっこう難しめのタスクをそのチームにドーンと渡すと、そのリーダーは極端に技術力が上がるイメージが個人的にあります。そういうことにすごく取り組んでいて、うまくいっています。

戸村：けっこう渡す側も怖いとか。

柴山：そうです。

戸村：受け取る側も「全部任されると怖い」ということがあると思うんですけど、何か（対策を）やってたりします？

柴山：若干「壊れるの前提でやるしかないかな」というところはあって。当然、レビューやテストをかなり厚めにはやるんですけど、それでもやっぱり。

例えば、設計の段階で（ベテランのエンジニアと）ある程度質の差が出たりするんですけど、そのあとその人がステップできるということの兼ね合いで後者（若手）をけっこう取る場合があります。

その場合でも結局、「あとはおっさんのエンジニアがどうにかこうにか全部やるよ」というところもあると思うので、どうにかできればぜんぜん構わないと思います。それでもどうしようもなくなるケースも当然あるんですけど……。だから取捨選択って感じですかね。

アサインと技術選定はエンジニアにとって最高の成長機会

渡部：2つに分けたほうがいいかなと思っているのが、さっき会社づくりの話をしたと思うんですけど、管理者がエンジニアに一番与えられる成長機会は、やっぱり業務のアサインだと思っています。

というのは、別に技術って1人でも勉強できるじゃないですか。でも会社に来て、チームで仕事をするというところで、そこじゃなきゃできない仕事をそのエンジニアにアサインするということが一番で。

そのときのアサインも、採用の場とかで驚かれるんですけど、僕は技術選定にほぼ関わらないんです。大枠の技術の方向性は決めるんですけど、「このプロジェクトでやりたいですね」という可能性があって、クォーターの頭に合宿的なかたちで、事業の目標がこうだから、こういうプロダクトを作ろうと。

それを4～5個ぐらいのプロジェクトに分けて、1個のプロジェクトは3〜5人ぐらいに分かれていくわけですけど、「その中での技術選定はもう自分たちで決めて」と。ただ、「どうしてもダメだとなったら止めに行くよ」ということは言って、僕は拒否権だけ持っているという感じなんです。

そこで使う技術は、問題を解決しようとしているエンジニアが一番詳しいはずなので、そこで決めればいいじゃんと思っています。ただ、「チームでちゃんと合意はしてね」という話はしていて、「それめっちゃアンチパターンだよ」ということはチームで話をして決めるというかたちになっています。たぶんこういうかたちで技術力が上がってくるんじゃないかと思っています。

あとはどのぐらい技術的なチャレンジをするかという話も、事業の話とだいたいのプロダクトの戦略の話があれば、例えば「1ヶ月後までにこのぐらいできてないとまずいよね」とわかるので、あとは自分たちで、そのなかでどういうチャレンジをするか決めればいいというかたちです。なので、エンジニアには「品質と納期に責任を持ってくださいね」「どう進めるか、中身に関しては任せるよ」という感じでやっています。

一緒にランチをして、技術や採用をみんなで考えよう

渡部：とはいえ、組織全体の中でそれをうまく回していく仕組みも必要だなと思っていて、「パワーランチ」と呼んでいるんですけど、月に2回、各プロジェクトである程度モノができあがってきたらデモを見せながら、「こういうところをがんばって作った」とか「こういうところを気にした」とか「技術的にこういうところをがんばった」というところを、みんなで飯を食いながら話を聞くということをやっています。

「お昼ごはんは会社で出しますよ」という感じで、毎週「ごちクル」でお弁当探して、「もう同じ弁当しかねえな。どうしようかな……」みたいな感じなんですけど（笑）。

あとは、もう少し中期的な話をする場もほしいということで、ウチの会社の中に「エンジニア明日の会」という名前の会があって、それを2週間に1回やっています。トピックはとくに決めないで、未来の話だけをする時間が2週間に1回1時間あってもいい、ということで始めました。そこでは技術の話もするし、「この負債どうしよう？」という話もします。

あとは採用の話で、合否の判定で迷ったときは、「どういうところをいいと思ったんだっけ？」というのは、エンジニア全員でちゃんといいと思った点やよくないと思った点を言おうとか、「僕らはどういう人がほしいんだっけ？」「どういうチームになりたいんだっけ？」という話も、基本的に全員で話をするという会をやっています。

そういうことの組み合わせで、技術力だったり、その人が本当に働きたい環境を作っていくことができるようにやっています。そんな感じです。

技術的負債は不可避、最初から潰しやすく設計しろ

戸村：1個お聞きしたいんですけど、技術選定をしたときにあまりにも尖った要素が出てきて、誰もメンテナンスできないとか、逆にそのフレームワークが今後メンテナンスされないというときってないですか？

渡部：そうですね。ただ基本的にみんな良識あるエンジニアだから、そこはそんなに外したことはしないと思ってるんですけど。でもチャレンジも必要で、僕が常に言っているのは「潰しやすいサイズで設計してくれ」という話をしています。

負債なんて絶対起きる。書いた翌日から負債になっているので、ソフトウェアなんて腐ったらもう悪いところがいっぱいあるわけです。それはリリース直後からどんどん起きるので、負債に取り組むことはもちろんやらなきゃいけないんですけど、なるべく潰しやすいサイズで1個の論理的なシステムを構成すると、もう「そこのインプット・アウトプットさえ守れば作り直せばいいよね」というふうにしたほうがいいんじゃないかなと思っています。小さすぎると大変なので、なるべくそのへんのバランスは取ったうえででやっています。

柴山：プロジェクトのだいたいの単位は決まってるんですか？

渡部：長くてもクオーターです。

柴山：なるほど。

渡部：でもクオーターの中で、各プロジェクトでフェーズを区切ってリリースしていくとか、まずは社内の人間が使えるようにしてフィードバックを集めて、それこそGoogleのフォームで要望リストを作ってアラートしたりとか。そこでブラッシュアップして出す感じが多いです。

ランチは大事、その場にいない人も参加できる仕組みづくり

柴山：パワーランチはどのくらいの頻度でやってるんですか？

渡部：2週間に1回です。うちの会社リモートワークの人もけっこういるので。

柴山：（リモートの人の）ランチはどうするの？

渡部：その人は自分で買ってくれという。

柴山：なるほど（笑）。

渡部：さすがに宅配できないので、オフィスにいる人の分はやるよということです。毎回Googleのフォームを作って、「欲しい人はここで申し込んで」ということで前日の昼間までに締め切って、僕のほうで発注するという感じでやっています。

あとはその会（パワーランチ）も「Zoom」というリモート会議システムを使って録画しておいて、なるべき参加してほしいんですけど、あとから見たい人が見れるようにしていたり、あとから入社した人が見れるようにやっています。

エンジニアリングを通じて、適材適所なキャリアを形成しよう

戸村：ありがとうございます。続いて、「各社で若手エンジニアが活躍している様子。歩んでいけるキャリア」についてお話しいただければと思います。

柴山：エンジニアが25人ぐらいで、20代が6割ぐらいです。平均年齢は30ちょいぐらいです。

司会者：（若手エンジニアが）活躍してますね。

柴山：そうです。うちはちょっと活躍してもらわなきゃ困るという現状があって（笑）。

様子は、さっきも言ったんですけど、やっぱり仕事への目線が変わって、（会社への）影響度が上がってきた子はぽこぽこ出てくるというイメージです。

僕が言ってることにぜんぜん納得してくれない人とかは、すごく成長してもらってるんじゃないかなと思います。自分の考えでかなり進めていけるようになってるというのは、1つ成長してもらってるところかなと思います。若干受け身になりがちな子もいるので、そことの違いはあるかなというところですね。

キャリアとしては、ウチは肩書きはあまり用意していないので、僕らにとって「若い子にどういうキャリアを歩んでもらうのか」ということは、正直これからのチャレンジという感じです。

ただ僕自身も、プレイヤーをやりながら幅広く見るエンジニアというのを推奨はしてるので、いろんな部分で自分のユニークさでエッジを立てながらも、常にプロダクトに触ってるというかたちで進んでいってもらいたいなと思います。

でもやっぱり、人によっては適材適所というところがあるので、そこからよりビジネスサイドに入っていったり、サポート寄りのところ、グロース寄りのところに入ってもらって活躍してもらうのもかなりありかなと思います。

そういう場合でも、エンジニアリング持っていると、ほかのところに入ったらさらに活きるというところもあるので、その人の特性を見ながら積んでいってもらえばという感じです。

大手からの移籍組や20代のマネージャーが活躍している

戸村： 20代若手の共通点はありますか？　どんな人がいて、過去にどういうことをしていたみたいな。

柴山：僕の性質もあると思いますけど、ウチは大学でやっていた人とか、それこそ情報系だったり。あとは大手で飽々して来ているみたいなタイプの人が多いので、とにかくモチベーションに溢れてるタイプが多いです。

戸村：活躍してるのは、その大手の人たちと（大学でやっていた人）どっちですか？

柴山：今パッと思いついた数人は、どちらかというと大手からのタイプです。たぶん自分個人で裁量を発揮する場所が欲しかったけど、与えられずに抑圧されてたタイプだと思うので、それがバッと花開いて、みたいなのはすごくいいかなと思います。

渡部：うちの会社は今、全部60人弱ぐらいですかね。エンジニアが15～20人の間ぐらいで、20代はつい先日まで20代だったやつも含めて5人ぐらいです。

活躍している様子でいうと、今までうちの会社もあんまりタイトルとかなかったんです。というのは、僕に全社のレポートラインが一時期ひどいとき7割入って、「ちょっと無理だ。もう見れない」みたいになって。ちゃんとマネージャーを作って、組織・チームの単位でちゃんとみんなで成長しやすいようにやっていこうという感じでやってます。そこのエンジニアのマネージャーは20代の子がやっています。最近30になって「もう中堅です」と言ってたんですけど。

その子はもともと「マネージャーとか興味ないっす」みたいに言ってたんですけど、最近はすごくチームをビルドアップするのを見て、「頼もしいな」と。

エンジニアに歳は関係ない？　20代から50代まで活躍する現場

渡部：それ以外の子でも、ウチの場合は年齢にけっこう幅があって、たぶん一番歳とってるエンジニアで50オーバーです。40代は1人、2人いて、30中盤ぐらいにボリュームゾーンがあって、20代がいるみたいな感じなんですけど、あまり意識せずにみんなフラットに働いているので、「こいついくつだっけ？」みたいな。あまり（年齢を）気にしていない感じです。

エンジニアとしてみんな超中核メンバーでやってるし、中核じゃない人はいないということはあるんですけど、実際に「技術をこうしていこうぜ」という話も（みんな）同じような感じでやっているので、とくに若手枠という感じよりかは、みんな横一線でやっています。

キャリアとしては、さっきの合宿の話もあったんですけど、合宿で決めるのはだいたい大枠の「このプロジェクトってこういうことを達成してほしいよね」というゴール設計だけするので、「実際どのように作っていこうか」ということは、エンジニアもPMもデザイナーも一緒に考えて走るという感じです。

なので、「こういったものを作って」という仕様書はないんです。ある意味、自分でそこの仕様を作ってやっていくみたいなところで、本当に本質的なことにこだわった開発ができるんじゃないかなと。

なので、「コード書いてるだけが楽しいです」という人はウチの会社にはあまりいなくて、「実際にプラットフォームを作って、自分たちがどういった価値をエンドユーザーに届けられるかを一緒に考えたい」という人が集まってきているので、そういったところは楽しいところなんじゃないかなと思っています。

戸村：エンジニアで50代の人ってあまりいないような気がするんですけど。

渡部：あまりいないです。僕もびっくりしました。

戸村：そうですよね。その人は今までどういうキャリアで、（今は）何をしているんですか？

リクルート草創期から活躍する肉体派50代エンジニア

渡部：今は普通にエンジニアとして第一線でやっていて、最近ウチが作っている分析系のプロダクトの基盤作っていたり、何でもやっています。

もともと僕が話を聞いたときは、草創期のリクルートからやっていて、まだリクルートさんが紙媒体主力の商売をしていたころです。もうみなさんに言ってもわからないかもしれないですね（笑）。

今はリクルートさんってWeb（サービスを）いっぱい持っているじゃないですか。あの前は全部紙だったんです。雑誌みたいなやつとか。それこそ『ゼクシィ』とか。ああいう記事を作るときに、どのコンテンツをどこに置くかといって、印刷のために配置をする社内システムがあったらしくて、それを作ったのがとっかかりらしいんです。そこからエンジニアになっていったみたいで、今も普通にエンジニアをしています。

その人はマラソンが好きで、3時間15分とかで走ります。3時間を切ると、日本の50代で100位以内に入るらしいんです。そこを目指してがんばっています、という人です。

戸村：パワフルな。

柴山：すごいですね。

渡部：マジで筋肉とかすごい。話が脱線するんですけど、今ウチの会社でなんちゃって部活動が流行っていて、ヨガ部があって、僕もそこに入ってるんですけど、週に1回朝来てマットを敷いてやるんですけど、この人（50代のエンジニア）も入っていて、「マジなんだこの太もも!?」みたいな（笑）。そんな50代のかっこいいおじさんです。

技術への深い理解を諦めるな

戸村：ありがとうございます。続いて、「勉強時間の確保方法とどこまで技術を理解しようとしているか」。柴山さんから。

柴山：どこまで技術を理解しようとしているか……ちゃんと（事前に）聞いておけばよかったんですけど、どういうことですか？

司会者：これはたぶん「（技術を）全部理解するのって無理でしょう」という話になります。深さの問題です。

柴山：ああ、なるほど。僕個人のですか？

司会者：そうですね。

柴山：僕自身はなるべく業務を減らして、勉強時間を増やすという、とにかくほかの人に押し付けてでも自分の勉強時間を増やすという感じでやっています（笑）。

（会場笑）

柴山：（技術の理解を）どこまでというかたちでいうと、僕はもうとにかくいけるところまで深くやったほうがいいんじゃないかなと。僕個人はそういうタイプなので、そういうやり方をしています。

ただ、人それぞれだなという感じはします。もう本当に業務で勉強しまくったほうがいい人とか、浅く広くやったほうがいいタイプとか、けっこういっぱいいると。僕たちはそんな感じです。

戸村：勉強方法は、どんな勉強をされるんですか？　本を読んだりとか？

柴山：本を読むか、Webを漁るかです。あんまりコードを読むというだけの勉強はあまりやらないですけど、そういう感じです。

読書もコーディングもやれ。自分の成長をマネジメントしろ

渡部：僕はけっこう業務の領域で「なにかいい解法ないかな？」と探すときに本を読みます。よく若い子には、「自分の成長ぐらい自分でマネジメントしろよ」と言っていて、業務でやっているプロジェクトってもっと不確定要素が多いじゃないですか。自分のことって自分が全部コントロールできるから、自分がマネジメントできないとプロジェクトのマネジメントはできないよね、ということです。

例えば、「この技術を年末までに身につけたい」と思ったら、読むべき本が決まるじゃないですか。まずそこから計画を立てなさいと言ってるんですけど、例えば今からだと、年末までに45日ぐらいですかね。読みたい本の総ページ数を割るんですよ。要するに、1日何ページ読まないと終わらねえなと。それを絶対読むと決めて読みますと。なので「飲み会があるからこの日は無理かもな」と思ったら、ちょっとその分多く読んでおくとか。

どんどんズルズル遅れていくと……そういうプロジェクトいっぱいあるじゃないですか。ズルズルと遅れて。でも、自分の成長はズルズル遅れさせたくないじゃないですか。なので、読むページ数を決めて「1日何ページまで読む」みたいな感じで、技術の勉強時間は確保しています。

僕はけっこう通勤が長い時期が多かったので、その通勤時間にひたすら本を読むということをやっていました。

技術の習得でも、やっぱりコードを書かないとわからないので、僕は年に1本ぐらいサービスを1人で作っています。アプリ、iOS、Android、サーバ、インフラ、Vagrantに何かちょっとAIチックなのを1本作って。

そうすると、「Hello World」をいくら書いてもぜんぜん習得した気にならないんですけど、ユーザーに見せようと思って作ると、「さすがにこのままじゃいけねぇな」ということがあるので、本当にこの技術のおいしいところをちゃんと学びきらないと作れないので、そういうことをやってぐるぐる回しています。

あと20代のときは「コードを書いて覚えよう」ということで、毎日1時間とか1時間半ぐらいふだんよりも早く起きて、コードを書いてから会社に行ってました。そんな感じです。