買い手と売り手の双方を経験した横澤佑輔さんに聞くエンジニア目線のPMIとは？いいエンジニアとは？｜横澤佑輔さん対談インタビュー
株式会社ソースメイカー代表取締役横澤佑輔さんとコデアル愛宕の対談インタビュー。
＜横澤佑輔プロフィール＞
1983年生まれ、2006年日本電子専門学校卒業
新卒入社でDNPグループのSI部門に配属、以後はゲオグループのネット事業部門にてエンジニアリードを努め、
2014年よりイタンジ株式会社の創業期にエンジニアとして入社、後に取締役CTOに就任し
2015年8月株式会社アセンシャスから不動産仲介サービスであるnomadをイタンジ株式会社が事業買収した際にCTOとして技術面のデューデリジェンスなど様々な業務に携わる。
2018年株式会社GA technologiesがイタンジ株式会社の株式を取得し完全子会社化する際には売り手側としてもM&Aを経験。
2018年10月より株式会社ソースメイカー代表取締役を務め事業計画から開発、保守運用やKPIトラッキングまでを提供するDXコンサルティングを提供している。
＜愛宕翔太プロフィール＞
Twitter: @shotaatago
#働くをもっと自由にのビジョンの下 、即戦力エンジニア採用ができる「コデアル」 を開発・運営。#エンジニア採用を語る会 #エンジニアキャリアチャンネル も運営中
長崎県長崎市出身。青雲高等学校にて、高校3年時に囲碁部主将を務め全国高校囲碁選手権大会全国大会出場。2007年、東京大学文科二類に進学。
大学2年時は、東京大学・東京大学三四郎会との共同プロジェクト「知の創造的摩擦プロジェクト」に関わる東大公認学生団体「東大ドリームネット」において語る会のマネージャーを務める。
知の創造的摩擦プロジェクトとの関わりから、志高く、起業家として生きることに憧れ、起業家として生きることを決意する。大学3年時からは、旧東京大学産学連携のスタートアップ「リッテル」（現在は株式会社ライフルにM&A）にて仕事を始め、大学4年次はそのまま社員になる。働きながら、新宅純二郎教授のゼミ生として、MOT (技術経営) を学ぶ。2011年、東京大学経済学部経済学科卒業。
買収先の東証一部上場の株式会社ライフルリッテル研究所に参画。参画2年目で、株式会社ライフル新規事業部門にて、新卒採用仲介Webサービス『メンターズnet』を企画・実装(現在はサービス提供終了)。その後卒業し、2012年8月9日、コデアル株式会社創業。
2016年、エンジニアインターン、エンジニア就活を事業譲渡( http://bit.ly/2lQaVBa )による軍資金を全額投下し、即戦力エンジニア採用ができる「CODEAL（ http://codeal.work )」のサービス立ち上げ現在に至る。
今回の対談の動画はこちら
CTOとして、買い手と売り手の双方からM&Aを経験された横澤さんに、今回はそれぞれの立場におけるエンジニア目線のPMIを中心にお話いただきました。また、後半はエンジニア採用のお話、いいエンジニアとは何かについてもお話いただきました。
M&Aを行う買い手側のエンジニアとしてどのようなことを考えていった？
愛宕）買収する側に立った時は、具体的にどんなことをまず一緒にしていったんですか？一緒になるかどうかの判断からまず入ってるんですかね？
横澤）もちろんそうなりますね。ただ、かなり意思決定まで早かったですね。当時を振り返ってみると具体的なドキュメンテーション（作成）などの話を除くと、最初のコンタクトから（意思決定まで）多分１ヶ月切ってると思います。
当時はオンライン賃貸仲介みたいなサービスが割と珍しく、イタンジとnomad、あと1つは某上場企業がやってたサービスの3すくみのような状態になっていて、シェア１位がnomadシェア２位がイタンジという状況でした。
なので一緒にやった方がいいだろうという話が上がり、コンタクトしてから話が決まるまでは１ヶ月切っていたと思います。
愛宕）では、一緒になろうと決まってから、一緒になる前に何か確認していった点って具体的にどういうものがありますか？特にシステムの面などで
横澤）そうですね、いわゆる財務的なDD(デューデリジェンス）みたいなものは、当時のCFOがやってましたし、システム的なDDもやっぱりやっていました。向こうのシステムのソースコードの中身も全部見せていただいて、サービスのKPIとかも全部拾い上げて行きました。
あとは、一緒にやるに当たって、不動産で言うと会員データや物件データなどをマージしないと意味がなくなってしまうので、DB(データベース）の仕様やソースコードの仕様を見て、本当にできるのかというところからまず始めるという感じでしたね。
愛宕）なるほど、面白いですね。ちなみに技術観点のDDとなったときに、何を聞けばいいのかって結構難しいと思うんですが、どうやって問いをひねり出していったんですか？
横澤）それはすごいいい質問で、そのサービスが事業として成功するときに何をキーファクターサクセスとするか、というところにそれがあると思っています。不動産はやっぱり、データという側面が相当強かったので、僕は最初から「DBを全部見せてください」というところから進めていきました。
アプリケーションなどはそれでいうと、結構後回しみたいなところでしたね。データの仕様をどちらかのDBに寄せる必要があったのですが、結局はイタンジ側のDBに寄せました。例えば物件の賃料の変遷みたいな重要なデータがうまくマージできる構造にそもそもなってるのかどうか？のような細かい部分を見ます。
極端な例で言うと、賃料って整数型とかでデータを持つべきなのに、あれ？文字列型になってるみたいなことがないように
愛宕）なるほど
横澤）逆に、アプリのuxなどが重要なサービスであって、データ自体はそこまで（重要でない）という話であれば、イタンジのDBを向こう側に寄せに行くみたいな意思決定も全然あったと思っています。
そこはサービスの特性とそのサービスが（顧客から）技術やデータ、uxなど何を求められてるかというところで総合的に判断するのではないか、という感じですね
愛宕）うーん、なるほど。今の話でも、サービスのどこがビジネスの競争優位性になってるのかという部分も踏まえて、何を見るかということですね。今回の話ですと、データが重要ということになってましたが、サーバーサイドのAPIがどのように作られているかであったり、そういうところも見たんですか？
横澤）その辺はチラッと見ましたね。まずはDBのスキーマ定義みたいなところをかなりメインで見たので、ダンプデータとかをもらったりしました。こっちは結合シミュレーションとかをSQLレベルで何回かやって、よしオッケーみたいな。
あとは、このデータは何でこうなって、こうやって加工されて保存されているのか？みたいなビジネスロジックですね。それはサーバーサイドのプログラムを見ないとわからないので、そこは結構見ました。
逆にフロントはほぼ見てないです。買収実行までだと、そういった技術DDのフェイズっていうのは、エンジニアならではの大変さみたいなものがあったと思いますね。
逆にM&Aで売り手側になったときには、どのようなことがあったのか、買い手側のときとの違いは？
愛宕）では次は、GA technologiesにイタンジが買収されて一緒になる、という立場になったときは、逆側ということになるわけですけど、違いを感じたこととかってありました？
横澤）全然違いますよ正直。当然今度はDDをやられる、うける立場になるわけですよね。なので、その前に自分でDDをやってた経験もあったので、結構細かいテックスタックであったりとか、データベースがどうなってるであるかとかは、かなり話が進んだ段階でしっかり準備をしていたんですよ。
愛宕）なるほど
横澤）と思ったら、GA technologiesとのディールも思っていたよりは意思決定が早くて、いろいろ準備したけど、結果的にあまり出す機会もなく決まってしまい、張り切りすぎちゃったなみたいな感じになりました（笑）
まあ、そこも観点が違って、GA technologiesとイタンジの業態ってのは当時では完全に別で、不動産テックっていう大枠では一応一緒だけども、GA technologiesは売買の方に特化していてイタンジの方は賃貸に特化していた。
不動産テックっていう大きな（括りで事業の）ポートフォリオを見たときに穴を埋めるっていう作業なので、あんまり前回のような競合サービスを統合して強化する努力というよりは、ポートフォリオ上どこを埋めなきゃいけないか、それによって全体としてシナジーを持って不動産テック総合企業になる、という戦略の中での考えです。
そういう意味で言うと、イタンジはイタンジでサービスとしてある程度完成はしているという状態だったので、そういった意味で観点が違ったのかなと。今振り返るとそうなのかなと思ったりはしますね。ただ実際に買い手のGA technologiesが（内部的に）どう考えていたのかは知らないので憶測ではありますが。
愛宕）面白いですね。例えば、人材業界とかで見たときに、人材紹介と人材派遣、またはそのどちらでもなく基本的にプラットホームとか媒体で直接マッチングっていうのは、同じ業界なんですけど多分全然見てる数字が違っていますよね、IR見ても一目瞭然ですけど。
その中で、同じキーサクセスファクターを見てるっていう粒度だと、答える側も問いかける側も結構深くなると思うんですよね。
横澤）そうですね、ディープになります。
愛宕）そうですよね。そういうのが前半で横澤さんがしていた話だと思うんですけど、例えばGA technologiesとの話だと、キーサクセスファクターになる部分がちょっと違うところもあったのかなぁと。
横澤）そうですね。本当に引いた目で俯瞰してみると、最初のM&Aっていうのは同じ（不動産の）バリューチェーンにいるところ同士でやったので、めちゃくちゃディープになったんです。
しかし、GA technologiesとの時って、（不動産の）バリューチェーンで見るとやっぱりずれてるところの領域で一緒になるという話なので、当然話が変わるんですよね。データの持ち方とかビジネスの考え方自体が
ビジネス関係だけではない？重要なカルチャーの違いについて
愛宕）他も何か一緒になる側に立ったときに、一緒にする側の時とさらに違いを感じたみたいなことっていうのはあるんですか？今までも結構お話いただいてますけど
横澤）そうですね、ビジネス関係以外で言うと、やっぱりカルチャーですね。完全に違いがあるのは
愛宕）ぜひ、それも聞かせていただきたいです。
横澤）カルチャーのフィットの難しさというのは、ものすごくあると思っていて、逆にどうやったら成功するんでしょうね？と個人的には思ってるぐらい難しいのがカルチャーのフィットですかね。
システムとか事業はうまいことやれば何とかなると思うんですよ。ただし、カルチャーって完全に頭で理解しきれるもの、割り切れるものでもないと思う、人間の心が影響するので。そこの統合はすごい難しかったなって思いますね。
例えば、イタンジっていう会社は結構エンジニアサイドがリードするケースが多くて、すごい良い言葉で言うとプロダクト文化というのが結構あったんですね当時は。逆に、買収する先のnomadっていうサービスは、エンジニアのいる数もすごい少なかったですし、それよりもビジネスオペレーションとかに強みがすごいあった。
逆に言うと、イタンジとかはその辺が弱かった。だから、お互いが補完関係になってるから最高！という話なんですけども、当然カルチャーもそれに合わせて全然違うわけなんですよ。
愛宕）確かに。ビジネスの方が強いということは、自分から売るであったり、話を持ちかけることができるような人材が活躍していて、プロダクトの方が強いという会社ではまた違う発想をするのかなと思います。
横澤）そうですね。だからPMIをうまくやるために、例えば実行の何ヶ月か前から私とかは向こうの会社にいってずっと作業してたり、その逆もやったりとかしてましたね。そんな感じで結構色々やってて、最初はいい感じだったんですけど…詳細に言えないんですけど、その後結構痛い目にあいましたね。
愛宕）なるほど。今のは、nomadの時の話をしてくださったと思うんですけど、GA technologiesと一緒になるって時もやっぱりカルチャーという話はあったんでしょうか？
横澤）やっぱり、お互いかなりセンシティブにそこを考えていたってのはありますね。僕は買収のタイミングで会社を抜けてしまったので（買収後のPMIについて）詳しくはわからないのですが、イタンジのプロダクトカルチャーっていい面もあれば、そうじゃなくて補完関係になる部分もあるってのはnomadの時と同じであったので。
GA technologies側のカルチャーってのも、僕は中身見たわけじゃないので、具体的にはわからないんですが、多分またイタンジとは異質のものがあるってのは間違いなかった。そこがうまくマージされていくのかってところは、お互いやっぱりかなり心配、というかセンシティブに考えていたなっていうのはありますね。
愛宕）なるほど
横澤）ただ、まあ結果として、GA technologiesの業績や決算を見てると良い感じですし、IRの中で発表されるイタンジの業績もしっかり伸びてるっぽいので、うまくいったのではないかなと個人的には思ってますけれども。
愛宕）今までのお話の中で、相手方の会社に行ったりとかもしていたって話が出てたと思うんですけど、自分たちのカルチャーって全然わからないなと思っています。ただ、相手のカルチャーはわかるんですよね。
横澤）そうですね、わかりますね。
愛宕）そうですよね、別の会社のミーティングに少し出さしていただいたりしていて思うのですが、その会社の人たちの雰囲気というのは、その会社の内部に自分がいない時には、すごく客観的にわかる気がしています。
横澤）いやー、そうですよね。例えば、イタンジの場合だとクライアントに不動産会社さんが多かったんで、そういう会社さんの朝礼とかに参加させていただいたりとかもあったんですけど、もう全然真逆ですよカルチャーは。
愛宕）採用のシーンをさせていただく中で、色んな会社さんでミーティングとかを見させていただく機会があるんですけど、「あっ、全然違うなぁ」みたいなことを思うんです。
会議体の進行一つとってもそうですし、昨日あった楽しかったことや学んだことを３０秒程度話してからミーティングの具体的なアジェンダに入るような手法があったり無かったりとか、会社によって違いますね。
横澤）いわゆるアイスブレイク的なやつですよね。そのアイスブレイクも本当に会社によってカラー出ると思うんですよね。
愛宕）そうですね。何の話が出るかとか、どんな感じでみんな話してるのかとかやっぱり違いますよね。
横澤）ミーティングの入り口とかでわかるってのはそういうところかもしれないですね。こんなにカルチャー違うのかみたいな。
愛宕）今回は、会社が一緒になるっていう前提でここまで話してきましたけど、働く会社を選ぶっていう時も結構それって大きいと思うんですよね。
会社が一緒になった時の話も出つつ、今一緒に働くって話も出たので、ちょっとエンジニア採用の話の方にも突入していけたらなという風に思っています。
横澤さんの思ういいエンジニアとは？ビジネスマンも同じ？
愛宕）横澤さん、なんか変な質問するんですけど、いいエンジニアって何だと思いますか？
横澤）変っていうか、すごい難しいやつですね（笑）
愛宕）いろいろな答えがあると思うんですけど、横澤さんなりのいいエンジニアって何ですか？
横澤）本当に厳密に個人的見解ですっていう前置きを置いた上でいうと、やっぱりエンジニアリングって手段なので、howの一つでしかない。やはりwhyとかwhat、つまり事業上の課題であるとか、それがひょっとしたら社会企業であれば社会課題になったりもしますが、それを解決するのが良いエンジニア。
その手法は何でもいいと思うんですけど、そういうエンジニアでありたいっていうのが常々思ってるところですね。
だから、ちゃんとその事業課題であったり社会課題というか、そのサービスやプロダクトの先にいるお客さんが求めるニーズですとか、ペインとかそういったものにちゃんと向き合って行動できてれば、いいんじゃないかなと思います。でもこれきっと、ビズでも同じですよね？
愛宕）そうですね、ビズ側っていったらいいんですか？いいビジネスマンって何ですかってことですかね？
横澤）はい
愛宕）そうですね、課題解決できる人ってのが一番短いワードなのかなという風に思っています。個人的見解って僕もつけ加えた上で、やはり相手の困りごとを支援、解決ができることっていうのが大事だと思います。
横澤）同僚とかも見方によっては顧客のような考え方のような会社もあると思うので、そういった周りの課題を解決するといった意識は常に持ち続けること。そして、まあそこにエンジニアならば技術的な強み、スペシャリティを持ってるっていうだけの違いだと思うので。なんか普通のこと言ってますね（笑）
愛宕）いえいえ、でもなんかビジネス的なところで言うと、僕も全然わかってないですけど、あくまで課題解決の手段として色んなテクニックがあるのかなぁっていう風に思ってるので。
例えば、手段としてBANTとかのいろいろな営業のフレームワークがありますけど、それはコーディングやプログラミングと同じであくまで手段で、あまりその手段とかテクニックに入り込みすぎると、それがテクニックとしてやってるっていうのが相手にすごく伝わってしまう気がしてるんです。
モテ本みたいなものがあったときに、モテ本に書いてあったことをそのままやってる感じというか。それって多分一番bot化しやすい、プログラム化しやすい、手続き化しやすい行為になってしまうっていう要素があると思っています。
それを手続き化する能力というのもすごく大事な能力だと思うんですけど、ビジネスマンって言ったときに、それができないことを何か手段として提供していったり、提案できないと、人間がやる価値がなくなるっていうことに行き当たることが結構あるなと思います。
横澤）それでいうと、最近よくいうのは、ROIが高いアウトプットを出すっていうところとかは、プログラミングにおいても自分自身も心がけるし、社員とかにも言ったりはしますね。
愛宕）具体的なROI、投資に対する費用対効果、が高いっていうことを考えた例みたいなのって何かありますか？
横澤）例えば、すごくわかりやすいあるあるの例で言うと、お客さんが〇〇っていうシステム作りたいです、って来る場合です。
「それってどなたのどういう課題を解決するやつなんでしたっけ？」とか「現状は何使ってるんですか？」とか聞いて、「なるほどExcelですね」みたいな流れになって、そのExcelを置き換えるためにSaaSみたいなのを作りたいとかまあよくある話だと思うんです。
「でもこれってSaaSをつくるっていうよりは例えば最近の〜っていうノーコードツールを作ってやっちゃうと、あれ、2日でできますね」みたいな。
愛宕）あー、わかりやすいですね。
横澤）それこそがやっぱりROIが一番高い、お客さんから見たときにですね。
エンジニア採用における、いいエンジニアの定義とは？
愛宕）いいエンジニアってどんなエンジニアですか？という問いから今まで話して来ましたが、エンジニア採用という意味で言うと、やっぱりいいエンジニアを採用しましょう、という話になりますよね。
ただちょっとここで意地悪な質問をしたいんですけど、みんなが今出てきたような要素を持ってるいいエンジニアでチームを作った方がいいのか、それとも比率とか割合の問題もあるんでしょうか？その部分についても聞いてみたいです。
横澤）比率とか割合の問題はあると思いますよ正直。サービスを立ち上げる段階の時って、良くも悪くも技術面での難しい課題って少ないと思うんですよね。
例えばClubhouse（音声SNSアプリケーション）とかわかりやすいんですけど、あれアクティブユーザーが１００人とか１０００人ぐらいの規模の時って、そこそこのエンジニアだったら誰でも作れると思うんですよ。
でもデイリーアクティブユーザーが１億人とかになった時って、多分誰でも作れるって話じゃなくなると思うんです。それもやっぱり、サービスとか事業の伸びによってそこのフェイズが変わって、必要とされる技術のレベル感とかが変わるって言うのは当然あると思うので。
僕は、最初工場とか持ってる会社に新卒で行ったんですけど、工場の規模がでっかくなればそれをオペレーションする人間の能力とか当然変わるので、求められるものが変わっちゃう、っていうのは同じだと思いますね。
だから、事業に合わせて設計するっていうのが結構採用のキモだと思います。そこの言語化が精緻になっているのが採用のキモなんじゃないですかエンジニアによっては。いいエンジニアって、まあ多分わざと愛宕さんおっしゃってると思うんですけど（笑）、めちゃくちゃフワッとしてるじゃないですか。
愛宕）そうですね（笑）、すごい抽象度高い問いですよね。どんな状況においてとかって前提を全くつけずに今質問してますね。
横澤）そうですね。その返答として僕が今言ったことって、どんな状況においてもそもそもビジネスマンとしていいよねという話なので、お互い抽象度めちゃくちゃ高いんです。
しかし、例えば、いいエンジニア欲しいんだって言ってる企業からお話聞いたときに、その事業規模であったりとか今事業においてどういうフェイズにいるのかっていうところから入っていって、そうであればこういう採用戦略ですよねみたいな話は必ずしますね。
逆にいいエンジニアって言われて、そこをめちゃくちゃブレイクダウンしていく感じです。事業フェイズは一体何なのかみたいな。
愛宕）実はお客様800社に聞くときも、横澤さんと全く同じようなことを僕もやってるんですよ。
要は、「とにかく即戦力のエンジニアが欲しい！」とか言われたときに、横澤さんの例だと１００人使えるクラブハウスでいいのか、デイリーアクティブユーザー1万人いってるような状態で作る必要があるのかとか、ビジネスの課題はシステムの部分によってより伸びそうなのかとか、単純にビジネスオペレーションの人員配置のところでうまく行ってないのかというのを聞きます。
そもそも、コードとか開発の領域じゃないかもしれない、っていう話もありえますよね。なので、結局分解していって、今の状況を聞いて話をさせていただいてるっていうのがあるから、横澤さんの話とか刺さりまくってる感じですね。
横澤）そうなんですよね。採用困ってるというご相談って、独立してからずっといただいてるんですけど、やっぱり困ってる内容の解像度を高くするっていうのは難しい作業です。
特にエンジニアではない人が、解像度を高くするってのは難しいと思うんですよ。そういうので、何回も同じような「事業フェイズはこうですよね、じゃあ採用方針はこうですね」っていう話を結構何周かしたので、あのnoteを書いてるみたいな感じです。
愛宕）なるほど。めちゃくちゃ面白いんで、皆さん横澤さんのnote(https://note.com/yoko_net)是非みてくださいね。
転職だけが答えじゃない、環境を変えるとはどういうことか？
愛宕）ちょっと横澤さんに教えて欲しいんですけど、例えば連絡しても返信がこないかもしれないと思ったとするじゃないですか？
だから連絡しないようにしようって思ってしまうと、ビジネスサイドの人だったら、もう次の行動が起きないから、次の行動に対する結果がついてこない。その結果、次に進まないって思うんですよ。
だから、実際にやることの大事さと何か数字で振り返っていくっていう両輪が必要だと思っています。しかし、やるってことを思うためにはできないかもしれないと不安に思ってもしょうがないという部分があると思います。
やってから考えればいいことを、こうなるかもって悪い方向に先に考えちゃうと、足が止まって伸びが遅くなるのかなと思うことがあって。
そういう観点からエンジニアってみたときに、フェイズによって求められることも変わってくるわけじゃないですか？そういうときにこういう心持ちで挑んだ方がいいとか、こういう考え方が大事、みたいなものって何かあったりするんでしょうか？エンジニアをやっていく上で
横澤）幸い自分の所属してる会社が、すごい勢いで伸び続けていれば、勝手に課題の質とか量とかって変化するから、それに食らいついてれば自ずと成長すると思うんですよ。
でも、全部の会社がもちろんそうじゃないと思うので、残念ながら下振れちゃう会社もあるでしょうし。あとは、そもそも大きくて安定していて横這いでっていうパターンもあるでしょう。
そういうとこにいてエンジニアやってると、ずっと似たようなことやってるなって感じる瞬間あると思うんですよね。そういう時はやっぱり、自分から動いて環境とかを変えた方がいいんじゃないかなと思いますね。
これは転職しろっていうわけではなくて、社内でも環境って変えられると思います。そういうことは個人的にもすごい大事にしてました。現役のエンジニアのキャリアの相談みたいなものを受けたりするんですけど、そういうところがモヤっとしてて、どうしよう？みたいなのがあります。
そういうのはもう、とりあえず一回頑張って環境変えた方がいいんじゃないかな、とは言っちゃいますね。転職しろって言ってるわけではなくて。
愛宕）その転職しろって言ってるわけじゃない、っていうのはすごい共感します。
横澤）自分のロールを要は決めちゃってるというか、例えば、一年とか同じ会社にいて、同じようなロールでやってると、何となく慣れちゃうんですよね。人間ってやっぱり慣れのバイアスみたいなのめちゃくちゃ強いじゃないですか。
明日から全く別の自分になろうって言ったときに、実は簡単になれるんですけど決め切れないだけで、そうは思ってもやっぱり別の自分になる事は難しいことなので、勇気を持ってというか努力してやるしかない。はい次、はい次みたいな感じで。
その結果、そこで失敗しても別にいいと思います。まあ、ただエンジニアは失敗すると、その失敗の内容次第では割と洒落にならないというのはありますけど。
愛宕）横澤さんの話にすごく共感したのが、CODEALという会社も人の仕事を変えるという機会の提供をやってる会社ではあるんですけども、転職って意味だけじゃなくという言葉がすごく刺さっていて、今社内で持ってるロールがあったときに、仕事というのは自ら機会は作り出し放題なところがあると思ってるんです。
自分で線を引くというところだけじゃなくて、今ここが課題でお客様に価値提供できてないという課題があったときに、だったら自分の得意技を使うと、この課題は解決できるんじゃないかというのを提案して、実際にやってみる。
これは社内であってもできる可能性はあると思います。まあ、それをやり切った上で、転職とかもあると思うんですけど。
大きい会社にいた方がいいのかとか、小さい会社にいた方がいいのかとか、どこにいた方がいいのかっていう相談を僕も仕事柄すごい受けるんですけど、どこにいたとしてもまず自分を変えるという意識が前提としてあった方が得なんじゃないかと思ってたりするので、横澤さんの言葉が刺さりました。
横澤）おっしゃる通りです。変えるなら自分からだと思うので、それですよね。それでもうまくいかないんだったら、環境をガラッと変えるっていうのは次の選択肢としてあると思いますし。
横澤さんが経験を伝える理由とは？業界というものを考えたときに
愛宕）最後に全体を通して、何かエンジニアの方に横澤さんから一言まとめていただきたいです。
横澤）難しいな、めちゃくちゃ大きめな質問きましたよ（笑）
愛宕）じゃあちょっと翻訳すると、noteにもエンジニア採用についてすごく発信されてるじゃないですか横澤さんって。今日も、会社が一緒になるときにエンジニアリングの面で、どんな面で困って、どう対応してきたか教えてくださってますよね。
それって別に横澤さんからしたら教えなくてもいいし、やらなくてもいいと思うんですけど、なんでやってるんですか？それを聞いて終わりたいです。
横澤）そうですね、なんでやってるんですかね。僕はIT業界でずっと働いてるんですけども、いろいろありますけどこの業界がなんだかんだ好きだし、多分死ぬまでエンジニアっていう職業に関わり続けるんだろうなって最近は思ってます。
そういうのに対して、色んな貢献の仕方があると思うのですけど、業界全体に対して。例えば、わかりやすくOSSにコミットするみたいなのもいいと思います。色んなものによって支えられてるのでエンジニアの業務は。
ああいうソフトウェア的なスキルに限らず、マネジメントとかそういったところとかもまだまだ還元が必要とされている業界だとは思っているのが理由です。共有文化みたいなものがあるんですかね、エンジニアって。
自分が１０何年仕事してきて、得たものというのは少なからずあると思うので、そういうのも惜しげもなくシェアしていこうっていうのは結構本気で思っているところですね。
僕、若い頃に出会った先輩プログラマーですごい尊敬する方がいるんですけれども、その方にあるとき「いや、大丈夫だよ死なないから」って言われたんですよね。結構やらかして、めちゃくちゃへこんでたんですけど、そのときにその言葉を言われて、まあ確かに、と思いました。
逆に死ぬような要素がある時はちゃんとやろうねっていう話をされて。だから、そういう意味で言うと、エンジニアリングでダイレクトに人の生死に関わるみたいなものも当然あるんですけど、多くの人はあんまりそういうところに関わらずに、今ある生活であったり、社会をよくするみたいなところにコミットする仕事になってると思います。
だから、そんなに考えすぎず良いものをたくさん出していきましょう、みたいなのがエンジニアの使命なのかなという気はしてます。単純にみんながよくなれば、勝手に社会もよくなるしというところですね。
愛宕）今日話していただいただけでも、すごい貴重な体験をされてきていて、その体験を自分だけのものにせずシェアをして、横澤さん自分ではおっしゃらないですけど、少しでも業界全体とか他に同じ悩みを抱えてるエンジニアの方やエンジニアに限らないIT業界の方に役立てば、っていうことでやってるのかなって。勝手な僕の見立てですけど
横澤）そうですね、多分そうです（笑）
愛宕）今後も是非発信を続けていただきたいです。今日は本当に横澤さんありがとうございました。楽しかったです。
サポート頂いたお金は、Youtube/記事の発信など、日米を横断した情報発信のために使わせていただきます。