役職はどうでもいい、“その時代のエンジニア”であり続けたい　「生涯現役」を志す、ディップ社CTOのエンジニア観

エンジニアは常に学び、変化し続けなければならない

豊濱吉庸氏（以下、豊濱）：次ですね。これはエンジニア観と言ったほうがいいのかもしれませんが、技術力はけっこう必要かなと思っています。僕が今まで言っている「エンジニア」はWeb ITのエンジニアなんですが、やはり常に学び、変化し続けることが必須かなと思っています。そうしないと、たぶん時代から遅れてしまいます。

先ほど質問にもありましたが、1999年に新卒として入った僕と2023年に新卒で入ってきた人の仕事はぜんぜん違うわけです。先ほどオンプレでデータセンターにもサーバーがあるというお話をしました。これは言っていいのかわからないんですが、アプリケーションエンジニアが、そのサーバーを会社から手で担いでタクシーに載せてデータセンターに運んでガッチャンとやっていたんですね。

今の人はそんなことを実際にやらなくてもいいじゃないですか。その時間をもっと良いコンテンツの開発に使ったり、アプリケーションまわりのスキル向上にあててもぜんぜん良いと思っているので、これをやらなきゃいけないということもないと思うんですよね。

なので、24年後の2047年は、たぶん（今と）ぜんぜん違うことをみんなやっているんだろうなと思っています。何をやっているかはわかりませんが、変化や進化するのが当たり前というスタンスでいろいろな勉強をする一方、そういった変化にも対応できるようになるのかなと思っています。

「自分がいなくなる」が1つのマイルストーン　“その時代のエンジニア”であり続けたい

次ですね。これは仕事観です。「自分がいなくなる」というのが1つのマイルストーンかなと思っています。やはり「○○さんがいないと回らない」というのは組織としてすごい弱いと思っています。僕もマネージャーになった時にすごく思っていたことなんですが、「自分がやるほうが楽」と思ったら、それは組織のためになりません。

思い切って部下や後輩に任せて主役になってもらうほうが、チーム力は一瞬下がるかもしれませんが大きな目（視点）で見た時にたぶん上がるかと思います。なので、そういったアプローチで仕事をしています。

3番目ですね。これも社内ではずっと言っているんですが、2025年ぐらいにCTOを誰かに渡そうかなと思っています。期限を切ると逆算で登り方が見えるんですよね。「CTOって何をするんだっけ？」とか「組織をどうしたらいいんだ？」とか「採用はどういったものをやっていったらいいんだっけ？」みたいなものが見えてくると思っているので、マイルストーンとして自分がいなくなるというのはきっと良い手なのかなと思います。

というわけで、これが最後のページですね。これからのキャリアです。これはもう新卒の時からずっと変わっていませんが、僕は一生エンジニアとして生きていきたいと思っています。1つ前の話ともつながるんですけれども、やはりエンジニアと呼ばれ続ける役割・立ち位置でこの先25年後、30年後もやっていきたいなと思っています。

CTOとか執行役員とかは正直どうでもよくて、“その時代のエンジニア”というものであり続けたい。それだけの純粋な思いがあります。あとは、なにかを作り続けていたい。僕はものづくりが単純に大好きなので、そういった環境でエンジニアと呼ばれ続けて人生を生きていきたいなとすごく思っています。ということでスライドはこれで以上です。

CTOになって「業界に貢献したい」とより思うようになった

篭橋裕紀氏（以下、篭橋）：ありがとうございます。僕から質問してもいいですか？

豊濱：はい。

篭橋：先ほど、CTOになった時に、今の業界の視点になるというところをさっきおっしゃっていましたが、自分もイチエンジニアというところで、それを経験することによって大きく見え方が変わったと思っているところはどのへんですか？

豊濱：イチエンジニアとして直接つながる部分はもしかしたら少ないのかなと思うんですが、CTOになって外部への発信や登壇が増えた中で、見られ方を研究して、より社会、事業、業界に対して貢献したいという気持ちが強くなったので、イチ会社とかイチ部署という考え方じゃないアプローチってできないのかな？　とはけっこう思うようになりました。

それが技術なのかエンジニアなのかと言われるとちょっと難しいんですけれども。だいぶ広がったのかなと思います。

篭橋：なるほど。ありがとうございます。

今やりたいことはコーディング

篭橋：フクシマさんから質問が1つ来ています。「今やりたいことはありますか？」ですが、いかがですか？

豊濱：今やりたいことですか？　1ヶ月ぐらい僕にコーディングをさせてほしいなと思っていますね（笑）。絶対に許されないからとりあえず言ってみるんですけど。Golangとかで書きたいですね。言語でいうと、GolangとかRustとかをやってみたいです。

質問者4：ありがとうございます。「コードを少しだけでも書いている」とおっしゃっていたので、どうやって（開発に）入っていっているんだろうなと。「これ書くよ」と言われても、「いやいや！　CTOに書いていただくのは恐れ多い」みたいな感じになってしまったりするのかなというのが、ちょっと気になりました。

豊濱：なるほど。実際にそれは言われています。なので、いわゆる人材サービスのプロダクトにはさすがにイチエンジニアとしては入っていません。

ここを改善したり、ここを自動化したらすぐ終わるのにみたいな業務ってやはりまだまだ弊社にたくさんあります。そういったところで細かいお手伝いをしたり、このレイヤーだからこそ知りえる情報を何らかの加工をしないといけない時に、そういうレイヤーにいくと僕だけになったりするので、それをちょっとやったり……そういう感じで「ぎりぎりコードを書いている」という表現をしました。

質問者4：ありがとうございます。

新人の成長のためには、バランスを考えて必要な分だけサポートをする

篭橋：じゃあ次はスギウラさんから質問がございます。

豊濱：「新人の成長のために行う（ために意識していることがあれば教えてください）」。そうですね。思い切って任せるというお話とほぼイコールかなと思うんですが、例えば自分がなにかの役職に就いていた時に、僕が兼務で部長をやるのではなく、誰かしらにチャレンジで部長になってもらう。そういうレイヤーを経験したことがない方であれば、前面には出すけれども僕が後ろからサポートするみたいな。

なので、安心して部長職に立ってもらえるようにするのはすごく意識してやっていましたね。

質問者5：なるほど。やはり任せるにしてもサポートはしっかり行うということですね。

豊濱：はい、そうですね。僕は先ほどもお話したとおりで完全放置でマネージャーになったことがあるので、そのつらさは身に染みて感じています。やはりそういうサポートは最初は必要だなと。もちろんサポートし過ぎるとそれはそれで良くないというんですかね。自分で考えることができなくなってしまうので、ある程度ではありますが、最初はサポートが必要なのかなと思っています。

質問者5：ありがとうございます。マネージャーの立場にいても自分で動きたくなっちゃうというのがやはり多々あると思うんですが、そういう場合にどうやって人に任せていくかというのをお聞きしたいなと思っていたので、「思い切って任せる」というのはけっこうやってみたいと思いました。

豊濱：はい。ありがとうございます。

迷っても思い切って決断することが多い

篭橋：次はタカハシさんから。

豊濱：「悩んだ時はどうやって解消していますか？」。これは難しいですね。一応今の僕にも上司はいるので、相談はできます。でも正直回答は自分で作らないといけないし、決めるのも自分でやらないといけない立場なので。相談というよりは「こうしようと思っているんですけど、どうですか？」みたいな感じですかね。

あとは同じ執行役員とか事業部長の人とかもいるので、一緒に「こうやっていったらどうかね」みたいな話をして、方向性を決めたりしている感じですかね。

質問者6：ありがとうございます。決断をしないといけない時って、自分が決めることが多くなるのかなと思っていて、その時に「本当にこれでいいのかな？」と迷った際にどうやって解決されているのかが気になりました。

豊濱：心配になることは多々あるんですが、「自分が決めないと進まないな」というのもあって、思い切って決めることのほうが多いかもしれないです。

質問者6：ありがとうございます。

言えないような失敗も数々経験　大事なのはミスを繰り返さないこと

篭橋：これはワダさんですね。

豊濱：「躓いた経験ないし失敗した経験」。本当にメチャクチャいっぱいあるんですよ。この場で言えないような失敗もたくさんしています。エンジニア時代だと自分のコードがすごくイケていなくてコンテンツをほぼ全部飛ばしてしまったり、1日見られなくしてしまったり、そういった経験は多々あります。そういうことから学んだところも多かったんですが、その時はすごくへこみましたね。本当に20年前とかですね。その時のへこみ具合を今でも覚えていますからね。

マネージャーになってからはどうだろうな。やはりメンバーが幸せに働いていなくて残念ながら退職した時かな。もちろんマッチしなかったという理由もあると思うんですがそういう時は「自分になにかできなかったのかな？」とか「ちょっとどうにかできたんだろうな」という思いに駆られるので、躓いた経験は今もありますし、昔もありました。ワダさん、こんな感じの回答で大丈夫ですか？

質問者7：ありがとうございます。キャリアの表を見た時にけっこう輝かしいというか、順当な感じがしたので、成功している人には裏に失敗もいっぱいあるんだなと思いました。もしよろしければ、その失敗や挫折の経験からどう立ち直られたのかも教えていただきたいです。

豊濱：振り返るのはすごく大事なのかなとは思います。同じようなことを繰り返しちゃいけないと思っているので、振り返っても自分の中で答えが見つからない時は、頼れる同僚とか、上司がいれば相談して解消していました。けっこう月並みの回答なんですが、そんな感じで進んできた感はありますね。

質問者7：じゃあ上司に相談するという感じなんですかね。ありがとうございます。

豊濱：ただ、これはぜんぜん関係ないんですが、僕は上司に好かれないタイプなので（笑）。「その場で考えろ」とけっこう言われた記憶はありますね。

質問者7：ありがとうございます。その話を聞いて、今のチームでうまく上司に相談ができているので今のままでいいのかなと（思いました）。参考になります。ありがとうございます。

豊濱：ありがとうございます。

学んだこと・経験したことは時代が変わっても活かせる

篭橋：タナカさんから「1990年に学んだ知識が30年経ったらまったく役に立たないというのはエンジニアではよくありますが、私はそれを考えると悲しくなります」というコメントが（来ています）。

豊濱：タナカさんのおっしゃっていることはすごくわかります。自分が積み重ねてきた経験が、いつか役に立たなくなるというのはエンジニアあるあるというか、たぶんこの業界の常識なんだろうなと思います。ガラケーからスマートフォンに変わる時とか、業界にとって大きな変化が起こった時にそういう人がたくさん出たんだろうなと思うんです。

だけど、学んだことが全部活かせなくなることはないのかなと考えていて、アルゴリズムとかアーキテクチャの考え方とか仕事の進め方とかって、言語やデバイスが変わったところで一緒かなと思っています。だからまったくゼロから作り直しという感じではなく、今までの経験を活かせるところもあるんだけれども、捨てなきゃいけない部分もあるのかなと思っている。僕はそう捉えています。

質問者3：ありがとうございます。フロントはすごく変化が速いので、昔のことが今だとぜんぜん役に立たない、みたいなことが多いと思うのですが、それを前向きに考える時にされていることはなにかありますか？

豊濱：先ほど「生まれてから」みたいな表をお見せしましたが、僕は中学生ぐらいからプログラミングをやっていて、いわゆる開発する機種や言語は常に変わっているのが当たり前だと、たぶん自分の中に刷り込まれているんですよね。なので、その時々で得なきゃいけない知識というのは変わっていくものだという前提に立っている感じがしているんですよ。

あまりそこに違和感がないというのが正直なところだったりもします。ちょっと参考にならないかもしれませんが、そういうものだと考えている感じです。

質問者3：ありがとうございます。本質を理解して、アルゴリズムとかそういうところで活かせるように僕も考え方をちょっと変えていきたいと思います。ありがとうございます。

豊濱：ありがとうございます。

永遠の課題・ビジネス側と開発側の壁にどう立ち向かっているか

篭橋：僕からも質問させてください。これは言える範囲でいいんですが、営業職が強い会社の中で、CTOの立ち位置でどううまく立ち振る舞っているのか。開発チームがうまくスケールするために心がけてやっていることがあれば教えていただきたいです。

豊濱：そうですね。先ほど従業員が二千何百人いると言いましたが、システム統括部の人数は100人程度で大勢ではないので、そういった悩みはもちろんあります。ただ、僕の立場から見る限り、だからといって（開発チームが）ネガティブとか立場が弱いという感じはあまりない気がしています。

同じレイヤーの営業の本部長の人や役員の人としゃべっても、お互い「何をしているのかを知りたい」という話をすごくするんですね。なので、もっと関わってお互いの仕事を知って、やれることを見つけていくという機会は、たぶん伸びしろとしてたくさんあるんだろうなと思っています。

ただ、弊社の場合はこのクラスでないとそれがなかなか話せないということが多くて、現場のメンバーの課長クラスが常にそうやってコミュニケーションを取っているかというとそうではありません。なので、例えば営業に同行して「プロダクトはどうですか？」とか「こういう機能があるんですけどどうですかね？」と聞くような取り組みはすごく増やしていきたいなと思っています。

篭橋：なるほど。ビジネス側と開発側みたいになると、けっこう溝ができがちというか、営業は「速く出せよ」だし、開発側はどうのこうのみたいな。あるあるではあると思っていて、僕らもけっこう悩んだ時があるんですが、どううまくやっていけばいいとか、なにかありますか？

豊濱：これは回答になっていないんですが、たぶん永遠の課題なんだと思うんですよね。

篭橋：なるほど。

豊濱：ぜんぜん違う職種でお互いにやっていることを理解しようとしても、わからない部分があって、溝と言ったらあれかもしれませんが、お互いに知り尽くすのはなかなか難しいんだろうなと（思います）。思い返してみると、ディップだけではなく、それこそヤフーとか過去にいた会社でもビジネスで営業側とものづくり側みたいなものがあって、やはりそういった溝というか理解できない範囲もあって、ワーワーしちゃったりすることもあった。

なので、それをなるべく減らすことしか今はできないのかなと思っています。先ほど言ったような取り組みで、少しでもお互いのことを知ったり、一緒にクライアントさんの気持ちを知りに行ったり、ある程度のシナジーを生み出せるのかなと思っています。

篭橋：なるほど。そうですね。同行はけっこういいですよね。「面接コボット」には僕らも何回か一緒に同行させてもらっています。

豊濱：ありがとうございます。僕もそうですね。ぐるなびという会社にいた時に、いわゆる飲食店の業務支援として予約台帳や顧客台帳を作っていて、飲食店のオペレーションにどれだけ刺さるかが課題でした。同行して、僕らもメチャクチャ大きな「確定する」ボタンを作っても、まったくクライアントさんの目に入らなかったりでメチャクチャへこんだり。

でもそういうのって、実際に行ってみないとわからないところもあると思っているので、そういった取り組みができると、ものづくりにもすごく反映できるのかなと思っています。

篭橋：ありがとうございます。

現場の状況はそこまで把握しない派　あくまで後ろからサポートをする

篭橋：ここでヨシノさんから「自分が任せた仕事がどう進んでいるか気になって頻繁に聞いてしまう傾向があります。現場の状況はどこまで把握していますか？」と質問が来ています。

豊濱：これを言うとディップの人たちが「おいおい」ってなるかもしれませんが、僕はそこまで把握しない派ですね。今みんな画面の向こうで「おいおい」って顔をしているんですよね。でもなんて言うんですかね。常に聞いているよりも、なんか困った時やトラブった時とかにパッと出ていって、そこで解決できるスキルを僕は持っていると思っています。

なので困った時に「きちんと助けるよ」とか「後ろにいるよ」とか、そこをわかってもらえるとうれしいなと思います。回答としては、（現場の状況を）頻繁には聞いていないです。正直知らないことも多いです。

質問者1：ありがとうございます。自分は、事前に察して問題が発生しそうなところを先に潰していくことをどうしてもしてしまいます。逆に言えば「信頼されていないんじゃないか」と思われても仕方ない気もしていて悪いなとは思っているんですけど。けっこう聞きに行ってしまうので、そこは気になっていました。

豊濱：課題を解決する速度でいうと、ヨシノさんのアプローチもありなのかなと思うので、一概にそれが良い・悪いではないのかなと（思います）。僕も放置し過ぎて、「お前もうちょっと見ろよ」と、たぶんみんな思っていると思うので。バランスなのかなとは思います。

質問者1：組織規模もあるかもしれないですね。自分のN2iと、ディップさんだとメンバーの人数も違いますし、やっている事業も違うので……ありがとうございます。

豊濱：ありがとうございます。

技術動向のキャッチアップの仕方は？

篭橋：豊濱さんは、CTOとか今の仕事をしながらインプットをどのぐらいしようと、心がけているんですか？

豊濱：先ほどもお話ししたとおり、そんなに本を読まない派なので。まわりから得る情報や、会社の中で仕事を通じて得られる情報がけっこうすべてなのかなと思っています。なので意識して情報を集めようというのは、あまりこれまでもしていなかったです。

ただ最新の技術動向はキャッチアップしなきゃいけないなと思っているので、そこはメンバーに聞いたり、ある程度のニュースを読んだりする中で、「こういったセキュリティのissueが世の中では発生しているんだな」とキャッチアップしています。

篭橋：なるほど。ありがとうございます。2025年にCTOを誰かに譲るみたいなことは、もう全社的にも言っているんですか？

豊濱：はい。言っていますし、たぶんどこかの記事で外にも公開していると思います。

篭橋：なるほど。それで成長を誰かがして働いてくれたらうれしいということですね。みなさんどうでしょう？　ではこのあたりで終了とさせていただきます。本日は豊濱さんありがとうございました。

豊濱：こちらこそありがとうございました。