社長の浜野がエンジニアの貴田さんにいろいろと聞いてみた。
自分は仕事としての課題を解決するためにエンジニアをやっている。
ーいきなりですが、現在の貴田さんのチームでの役割をおしえてください。
実は今はチームとして動いてるわけじゃないんですよ。一応、即応チームに所属しているんですけど、それとは別に、SREの仕事もしていますし、2022年の10月からは、CTOと一緒にベトナムの開発拠点の立ち上げにも大きく関わっています。そういう意味ではバックエンドエンジニアもやってますし、SREもやってますし…ベトナムに関しては、なんでしょう、半分PMみたいな動き方もしてます。
ー役割が多い…役割分担って、どんな感じで決まるんですか。
うちの場合、会社の中での役割って完璧に明文化されているわけではなくて、この人はこの分野に強いから、この仕事を任せようみたいな、そういう感じで、自然と適材適所で決まっていってる気がしますね。ただ私の場合、バックエンドエンジニア、SRE、ベトナムの立ち上げの役割は単純に「やってください」みたいな指示から始まってる気がしますね…笑。
ーいろんな仕事をやらないといけないのって大変ですよね。人によっては、一つの仕事に集中して取り組みたい場合もあると思うんですが。
そうですね。なんというか、全てをこなせているうちは問題ないんですけど、私はどちらかと言うと専任で取り組む方が好きですね…笑。最近はベトナムの方が忙しいので、例えば、SREのルーティーンはあまり積極的にやらなかったりとか、バックエンドの開発も重いタスクは持たないようにしたりとか、もちろん何かあればすぐに対応はするんですが、その時々でメインで取り組んでいる業務は決まっている感じですね。
ーたしかに。いろんな仕事を任されたところで、働く時間は限られているので、優先順位を付けて取り組むことになりますよね。今はすごく忙しいと思うのですが、個人の技術力を高めるために取り組まれていることがあれば教えて下さい。
そうですね。業務とは異なる領域の技術を勉強したり、新しい言語を学んだりとか、そういうことをしたいとは思いつつ、今はそういうことに集中して取り組んではいないですね。やっぱり、自分は仕事としての課題を解決するためにエンジニアをやっているという意識があるので、まずは仕事に関連する技術に興味がいっちゃう感じですね。ただ、仕事中にBGMとして技術系のPodcastを聴いたりして、自分が知らない技術についてキャッチアップするということは意識的にやってはいます。リモートワークをしていると、子供が騒がしかったりするので、集中するためにもPodcastを聴きながら仕事することはありますね。
出社して仕事した方が、一日の区切りは良い。
ーみんマはここ3年間でフルリモートのメンバーが多くなりました。リモートワークはどうですか?
前職でも少しだけリモートワークしていたのですが、現在のみんマのようにフルリモートで働くというのは初めてですね。なんか正直、もう出社に戻りたいみたいな気持ちは、結構あったりします。笑
ーえっ!?来たら良いじゃないですか!なんでオフィス来ないんですか?笑
いやぁ、ちょっと…あの…なんでしょう…コミュ障なので…はい…笑。
ーなるほど…笑。面白いのが、リモートワークをしていて「やっぱりオフィスって良いですよね」みたいに言う人多いんですが、結局来ないんです…オフィス通勤圏内に住んでいるのに…。どうしてなんでしょう?笑
やっぱりリモートはリモートで楽じゃないですか。通勤しなくて良かったり。さすがに出社した方が良いだろうとは思いつつも、まぁ…甘えですかね。笑
ー自宅の方がオフィスより作業環境が良いとか、そういう理由もあるんですか?
私の場合は自宅の作業環境をこだわったりとか、そういうのは特になくて、自宅が作業効率の良い環境かというと別にそんなことはないですね。悪くはないですが、あくまで平均的な感じですね。
ー今期から部署ごとに月1回「出社デイ」が設けられました。もちろん参加は任意ですが、こういうイベントで背中を押された方が出社しやすいんでしょうか。
そうですね。出社デイなんかは、さすがにオフィスに行くと思うので、それを機会に徐々に出社を増やしていこうと思ってます。ただ、私の場合、業務上、人とのやりとりってそんなに多く発生しない気はしてるんですよ。昔はオフィスに来ると業務で関わりのあるエンジニアと直接話せたので、あれはやっぱり仕事しやすかったなっていうのはありますね。今はベトナムに関する仕事が多いというのもあって、そういうのが出社しない理由になってるかもしれません。
ーなるほど。オフィスに来る「目的」が大切ということですね。
ただ、個人的にオフィスに出社して仕事した方が、一日の区切りは良い感じがしますね。仕事が終わった後、みんなで飲みに行ったりとか。自分はそういうのが好きな方なので。家から渋谷までは30分ぐらいなので、全然行けるし、行きたいなとは思ってるんですけど。
大切なのは「成功させる力」。
ー話しは変わりますが、学生の頃からプログラミングを勉強されていたんですか?
専門的に勉強をしていたわけではなくて、なんというか、大学の研究でシュミレーションとか計測をするときに簡単なプログラムを書く程度でした。大学ではハードウェア系の研究をしていたので、漠然とエンジニアにはなりたいなと思っていたんですが、ソフトウェアなのかハードウェアなのかというのは最初は決めていなかったんです。ただ、一般的にハードウェアに比べてソフトウェアの方がフィードバックループが早いので、そういった理由でソフトウェアエンジニアの道に進むことになりました。元々の性格として、ものづくりが好きというか、何か条件を変えて動きを見るみたいな、そういうことが好きなんですよね。実際に何を作るかは置いておいて、漠然とエンジニアになりたいなと思っていたんだと思います。
ー大学を卒業した後は、何をされたんですか。
大学卒業後は新卒でソフトウェアの開発会社に入って約5年間働きました。20名弱の小さな会社で、エンジニアの数も少なかったんですが、気付いたら、自分がCTOの次くらいのポジションになってしまって。これ以上は成長できない環境なのかなと感じたのと、使っている技術がニッチだったので、もう少し一般的なWeb開発をやりたいなと思うようになったんですね。それでまず会社に辞意を伝えたんですが、そしたら「気分転換に違うことやらない?」って言ってくれて、子会社で半年間ほど技術コンサルみたいなことをやらせて頂いて、その後にみんマに転職してきた感じですね。
ー貴田さんが仕事をする上で大切にしていることってありますか。
ありますね。なんか結構、自分で全てを把握しておきたいというか。自分で納得した上で仕事を進めたいっていうところはありますね。あと、これはある技術ブログで読んだ話しなのですが「成功させる力」が大事だと思っています。
ー「成功させる力」ですか?
はい。例えば、何かを開発するとき、どんな仕様にするかとか、解決したい課題に対してどのような技術を採用するかとか、どのような開発手法を用いるかとか、そういった選択全てを正解にするために、自分で納得した上で取り組みたいっていうことですね。
ーそれって、今この会社で実現できてますか?
仕事なので「チャンスをもらっている」という表現は適切ではないかもしれませんが、自分のこれまでの開発を振り返ってみると、けっこう自由にやらせてもらっていた気がしますね。みんマでは納期というか「この日に絶対リリースしろ!」みたいなプロジェクトにアサインされることが少ないので、これが自分には合っているなと。これはCTOの狙いなのか、たまたまなのかは分かりませんが、わりとじっくりと時間をもらって自分の納得のいく設計を決めた上で、多少遅れるのはしょうがないというか、そういう開発スタイルを許容してもらっているので、自分にとっては納得できるかたちでリリースできていると思います。これが例えば、急ぎの開発だったりすると、悩んでいる時間がないので、突貫工事になってしまって自分的にはイケてないなぁ…という思いのままリリースすることになるので。笑
ユーザーのフィードバックをもとに改善していく過程は楽しい。
ー結果として納得のいく仕事ができているということですね。貴田さんから見たCTOってどんな人ですか?
一言で言うと「表に出ないタイプ」ですね。裏では結構面倒くさいことをやっていると思うんですが、ほとんど表には出てこない。ただ、何か問題が起きたときとか、悩んでいる課題があったときには誰よりも素早く動いて、適切な解決策を出してくれるっていう印象です。最近でもそういう経験が何回かあって。ベトナムでもそうですし、日本側の開発でも、CTOが提案してくれた技術がドンピシャでハマって、開発がうまく回っているっていうことがありますね。
ー逆に、CTOにもっとこうしてほしい、っていうのはありますか。
うーん、ありますね…笑。これは他社との比較になってしまうかもしれないんですが、いわゆる大手IT企業って、エンジニアリングマネージャーみたいな層が充実しているなと思っていて。5〜10名程度のチーム単位でマネージャーみたいな人がいて、エンジニアの面倒を見たり、メンター的なことをしたり。そういった組織設計みたいなことは、今後の拡大に向けて、CTO主導でもっとできるんじゃないかなとは思ったりしますね。今のみんマみたいに個々のエンジニアに裁量が与えられていると言えば聞こえはいいですが、逆に言うと、一人で迷っちゃったり、進むべき道が示されないっていうことにもなっちゃう可能性もあると思うので。
ーなるほど。CTOも同じことを言っていました。思いは同じということですね。みんマに入社してから、特に印象に残っているプロジェクトってありますか?
やっぱり最初のプロジェクトが一番印象に残ってますね。新しいカテゴリーの開発だったんですけど、チーム的に余裕がある感じで、初期のリリースからその後の改善までやれて楽しかったなと。自分でバックエンドもフロントエンドもアプリも開発したりして、バリバリやれてたなっていう印象ですね。やっぱりユーザーのフィードバックをもとに改善していく過程は楽しいですね。今の仕事はバックエンドに偏っていてわりと決まったことをやるっていう感じなんですが、たまに過去に自分がリリースした機能のKPIなんかを見て個人的に楽しんだりはしてますね。笑
近いうちに限界が来る。
ーくらしのマーケット全体を見たときに、何か課題はありますか?
プロダクト全体を外から見ると実はもう完成されているんじゃないかっていう気もしていて。エンジニアやデザイナーがプロダクトを作って、その後、システムだけでは実現できない部分についてはコンサルタントやCSがフォローする、そしてマーケティングでさらに利用者を増やす。この拡大の仕組みが完成されているんですよね。もちろん、細かな不具合や機能など改善していきたい部分はいっぱいあると思うんですけど。プロダクト全体として見たときに、致命的な問題があるとか、何かこの部分だけを変えれば一気に伸びるみたいなところは、少なくとも僕は思いつかないですね。逆に中から見た場合、改善点っていうのは無数にあって。自分が今やっていることにも関係するんですが、エンジニアリングの観点で言うと、結構コードが古くなってきていて、それによって保守性が下がったり、変なバグを生んだり、開発しにくい状況があるんです。
ー新規の開発もしつつ、既存のリファクタリングも同時にしないといけない。リソースが二倍必要ですね。
まさにそうなんです。だからこそエンジニアの採用が大事になってくると思うんです。今って、過去に在籍していた人も含めて、強いエンジニアが作った強い基盤の上にいろいろと乗っけてなんとかやっている感じで、きれいなコードではないけど、ちゃんと動くものを提供できている部分もあったりするので。そういったものは近いうちに限界がくると思っています。
マジで彼らの生産性は高いんですよ。
ーなるほど。強いエンジニアというお話がありましたが、貴田さんの考える優秀なエンジニアとは?
まさに今話したことで言うと、0→1の開発ができるエンジニアってやっぱり強いと思っていて。単機能の開発っていう点で言うと、わりと似たような実装がすでにネット上に転がってるんですよ。なのでそれらを調べる力さえあれば、わりと頭を使わずに開発できてしまうんですよね、実際。なので、くらしのマーケットの開発で言うと、甘えじゃないんですけど、実際そういう感じになっちゃってる部分もあって。真に優秀なエンジニアっていうのは、そういう意味で古いコードとかを全然無視できるというか、前例がなくてもフルスクラッチで開発できる力を持っている人だと思います。
ーたしかに、0→1で開発できるエンジニアは天才というイメージがあります。チームで活躍するエンジニアという点ではどうでしょうか。
そうですね。まさに今、私が頑張ろうとしてることなんですが「タスクを正しく定義するスキル」かなと思っていて。これが結構大変なんですよ。ベトナムの開発チームで言うと、彼らすごい開発が早くて、すぐにタスクが足りなくなってしまうんです…笑。漠然としたゴールや課題の中から本当に必要な開発を要件定義して、それらを適切な粒度で切り分け、タスク化してメンバーに振り分けていく。もしこの作業が得意なエンジニアがたくさんいれば、ある意味で、どんなレベルのエンジニアでもスピーディーに開発できる体制が構築できるわけで、今後どんなにエンジニアが増えても、開発効率を落とさずに組織を拡大できるんじゃないかと思っていますね。
ーベトナムの立ち上げはどうですか?うまくいきそうですか?
それはもう、私次第です…笑。マジで彼らの生産性は高いんですよ。それをちゃんと利益につなげるというか、成果につなげるには、まず業務設計がちゃんとしていないといけない。なので、自分の動き方がすごい重要だと思っています。
技術力の評価はどこまでいっても難しい。
ー話しは変わりますが、エンジニアの相互評価制度についてはどう考えていますか。
わりと長いこと相互評価でやってきたんですけど、何というか、人に対する評価ってそんなに変わらないなと思っていて、わりと先入観で「この人はちゃんとしてるから」とか、けっこうイメージで評価しちゃう部分ってあると思うので、そういう意味では適切じゃない気はしています。ただ評価指標を見るとエンジニアに求められていることが明確になっているので、それはすごく良いと思っています。
ーなるほど。評価軸は正しいが、評価の測定方法に改善の余地があると。
そうですね。評価っていうところで言うと、やっぱりどうしても主観が入るので、特に業務で関わりの少ない人に対するもので言うと、100%正しい評価っていうのは難しいかもしれませんね。うちの場合、評価サイクルも早いので、短期間で他人の評価をし続けるというのは、けっこう大変ですね。なので、例えば「何個のタスクをこなしたか」「見積もり通りにタスクを完了できたか」「何件のレビューに参加したか」みたいなものは定量化して客観的に評価してもいいんじゃないかと思いますね。逆に「技術力」っていうのは、どこまでいっても評価が難しいですね。例えば、何かを開発するときに5つの選択肢があったとして、その中で正しい選択をすれば技術力が高いのかと言うと、実際にはそれ以外の選択肢もあったりすると思うので。
エンジニアが数百人規模になっても高い生産性を発揮できる組織。
ー貴田さん個人として、何か目標はありますか?
最近は本当に忙しいので余裕がないというか、正直あまり考えられていないんですけど、もう少し落ち着いたらエンジニアのチーム感を高めるための何かを頑張りたいなっていう気はしてますね。今って、すごい自由な反面、個々のエンジニアの関係性が希薄だなって思っていて、個人的にはもっと関係性を高めた方がいいと思っています。
ー貴田さんの考える理想のチームの状態を10段階で表すと、今はどれくらいですか?
…2とかです。
ー低いっ!逆にその「2」には何が含まれていますか?
やっぱり開発チームとしては機能してるじゃないですか。と言ったらあれかもしれませんが、PMも少人数でよく開発を回してるなって思いますね。PMが全体のタスクのボリュームを考えて、エンジニアをアサインして、エンジニアがちゃんと開発をして、ふつうにそのサイクルが回っているので、最低限しっかりと開発できているという点で「2」ですね。
ー最低限しっかりと開発ができている状態が「2」というのは、視座の高い貴田さんらしい評価ですね。逆に足りない「8」は?
いわゆる日本の代表的なテック企業を「10」と置いたときに足りない部分が「8」なんですけど、個々のエンジニアがそういった企業に匹敵するレベルになっているかとか、あるいはエンジニアが数百人規模になっても高い生産性を発揮できる組織になっているかとか、そういうところですね。この「8」を埋める作業ってけっこう大変だと思うんですよね。2を3にして、3を4にして、っていう感じで。
ー具体的にどうしたらいいのでしょうか。リモートワークも関係性を希薄にしている要因の一つなのでしょうか。
まさにそうだと思いますね。私が今話しているようなことも、普段は私の頭の中にあるだけで。でも、私が考えているようなことって、たぶん他の人も何かしら考えていると思うんですよね。チームとしてこういう課題があるよねとか、こうしたら解決できるよねっていう共有ができれば、具体的な取り組みっていうのができるようになるんじゃないかと思ってます。これに関しては、ボトムアップでできること、マネジメントからトップダウンでできること、両方あるんじゃないかなと。
ーそうですね。トップダウンで言うと、ここ数年は世の中の状況もあり、有事の戦略として「フルリモートでも回る組織」を実現してきましたが、今年はよりチームワークにフォーカスしていきたいと考えています。
はい、良いと思います。笑
ーありがとうございます…笑。貴田さん個人としての状態は10段階で言うと、いかがでしょう。あくまで個人として。
個人も「2」くらいじゃないでしょうか…うん…全然できてないですね…。自分としては今任されている仕事が自分として伸ばしていきたい部分だったので、まずは今を頑張ろうっていう気持ちでやってます。これがうまくいけば、今度はその経験を外部にも発信したいと思っていて。それができて「4」くらいですかね。
ー任されている業務がうまくいって、それを外部に発信しても「4」って…ストイックですね…。それじゃあ「10」はどんな状態なんですか?
うーん、自分でも分からないですね…笑。でも、そこを目指すのであれば仕事以外でも頑張らないといけないと思いますね。エンジニア業界における、インフルエンサーというか、その人の知名度だけで会社に優秀なエンジニアが集まってくるような、そういうレベル感だと思います。それって並大抵の努力じゃ無理だと思うので、日々のアウトプットもそうですし、何年もかけて技術力を高めていく必要がありますね。自分個人で言うと、技術力一本でそれを実現するのは大変というか、技術だけではなく、マネジメントもできるっていうのを自分の売りにしたいと思っています。そういう意味で、今やっている、技術選定や設計、タスク管理は自分にとっての活路ですね。
ーわかりました。直近で何か大きなプロジェクトはありますか?
カテゴリーのマイクロサービス化って呼んでいるんですけど、大きなリファクタリングですね。今って全ての機能が一つのアプリケーションとしてまとまってインスタンスにデプロイされている状態なんですけど、これをもう少し細かい単位で分けてスケーラビリティを上げたり、可用性や保守性を高めたりするのが狙いですね。
ーさらなる拡大に向けた基盤づくりですね。本日はありがとうございました。