子育てとAIで作る塗り絵
ken
リスナーのみなさん、お久しぶりです。今日はゲストの方をお呼びして、収録しようと思っているんですけれども、
しばらくちょっと空いてしまいました。夏休みを取ったり、プライベートが忙しかったり、子育ての方が忙しかったり、みたいなことで、
ken
久々にゲストの方を呼んでお話しするのをすごい楽しみにしているんですけれども、
今日はMutsumiさんをお呼びしております。ようこそ。よろしくお願いします。
Mutsumi
よろしくお願いします。
ken
Mutsumiさんは初出演ということで、簡単に自己紹介みたいなのをしてもらおうかなと思いますが、よろしくお願いします。
Mutsumi
はい。名前はMutsumiです。ちょっと苗字の方がややこしくて、
結婚前が佐藤という苗字で、結婚後、加賀という苗字に変えていまして、
ところどころ佐藤だったり加賀だったりするので、名前だけでMutsumiと通しています。
現在は東京でソフトウェアエンジニアとして働いていて、プライベートな方でいうと二次の父親をしております。
2022年に男の子が生まれて、去年ですね、2025年に女の子が生まれて、その4歳と今年1歳になる子の父親をしているという感じですかね。
はい、簡単になりますが、そんなところです。よろしくお願いします。
ken
どうですか、子育てとの両立は。僕も一緒にポッドカスやってるカズのホットトピックなんだけど。
二次生まれて2人目、どうですか。
Mutsumi
いやー、二次生まれて、より難しさが増したなっていうのが正直なところですね。
一人目の時は、僕と妻も共働きで同じように働いているんですけれども、僕も妻もお互い仕事も頑張りたいし、子育ても頑張りたいしということで、
だいたい2人とも家事と育児を両方やるっていう関係で、ただ一方で仕事だったりキャリアも頑張りたいということで、
土日の片方はどちらかがワンオペをして、どちらかは自分のやりたいことをやるみたいな生活を送っていて、
なんとかそこで勉強することができていたんですけど、
二次になるとですね、この時間がやっぱり取れないなという。
ken
分かるわ。
Mutsumi
いや、そうですよね。
ken
片方がね、片方の子供を見て、もう片方がもう一人の子を見てってなるよね。
Mutsumi
いや、本当におっしゃる通りですね。
妻が息子の方をよく見てくれていて、僕が下の子の方をよく見ていて、それぞれで動いていて、土日はそれで過ごすっていうスタイルなので。
偶然だね、うちもなんかそんな感じに結局なって。
ken
僕もベビーの方を担当することが多くて、妻が上の子を担当することが。
なんでだろうね、たまたま、たまたまっちゃたまたまだけど。
なるほど、大阪も同じ感じがあるので。
ken
そうそうそう、特にこれといった理由は何も思いつかないんだけど、自然とそうなってて。
Mutsumi
あー、そうなんですね。
ken
うーん、そうだね。
Mutsumi
うちは結構あれですね、息子が結構ママがいいっていうタイプだったりもするのと、
妊娠期間中とかもやっぱりこう一緒に遊んであげられない期間があったりとかしたのもあって、
やっぱりこう二人の時間を作ってあげた方がいいよねっていうことで、よく妻と息子が出かけているという感じですね。
ken
確かに確かに、そうだね、4歳とかだと幼児帰りとは言わないかもしれないけどね、
ママをミスする時間が増えるよね、そうだね。
Mutsumi
そうですね、そうですね。
ken
その週末の時間の確保に戻るけど、
じゃあかといって一人にワンオペ二人をお願いするっていうのも結構ハードル高くない?
ken
うちとかと、何回かやるけど、ワンオペした方の親の負担がもう3倍増くらいになるので、
結局そのリカバリー2、3倍以上かかるっていう。
Mutsumi
めちゃめちゃわかりますね、めちゃめちゃわかります。
そうですね、ちょうどそれこそ妻がこの半年間ぐらいがっつり勉強したい、
プログラムみたいなのに入りたいっていうことで、ちょっと入っていて、
たまに月一ぐらいで土曜日とかですね、午後いないみたいなタイミングがあったりとかするんですけど、
そのタイミングワンオペになるとだいぶ来ますね。
だいぶ来ますね。
ありがたいことに妻の実家が同じく東京にありまして、
お母さんに来ていただけるっていうことがあるので、
それによってなんとかしのげる日はしのいでいて、しのげない日はだいぶ疲労をしてですね、
ken
僕がちょっと当たりが強くなってしまうみたいな反省として。
わかるわかるわかる。
Mutsumi
あるという。
ken
本当に。
Mutsumi
そういった感じですね。
ken
ソフトウェアエンジニアとしてはソフトウェアエンジニアリングで解決できることが本当に少ない領域だなと日々思ってます。
Mutsumi
間違いないですね。本当にそう思いますね。
一方でなんか最近ですね、発見として、
息子がすごく恐竜だったりとか昆虫が好きっていうのと、
塗り絵が最近すごくハマっていまして、
ken
塗り絵。
Mutsumi
でも塗り絵と言っても、やっぱり限られてくるというか、
だいたい本屋さんで売っている塗り絵か、100円ショップで売っている塗り絵になるので、
2、3冊買ったらだいぶこう、何ですかね、もう網羅しちゃうみたいな感じなんですよ。
それ以上の塗り絵ブックなんてそんなに存在しないっていう感じなんですけど、
昨今のAIの進化によってですね、
AIにちょっとマニアックな恐竜だったりとか、ちょっとマニアックな虫の名前を伝えて、
Mutsumi
それを塗り絵にしてもらうとですね、
本人もすごく喜ぶし、結構それで10円とかで印刷できたりとかするので、
それですごく親としては助かっている部分がありますね。
ken
え、何それめちゃくちゃ面白いアイデアですね。
マニアックな名前を例えると何ですか?
僕そんな恐竜とか昆虫詳しくないけど、こう。
Mutsumi
いや、本当にマニアックなんですよ。
なんか、すごく有名なのだとティラノサウルスとか、
ティラノサウルス知ってる。
トリケラトプスとかあると思うんですけども、
映画で出てくるよう、もう恐竜映画で出てくるようなカルノタウルスっていう恐竜だったりとか、
あとはアンペロサウルスっていう日記なんですけど。
ken
見たことある。角のある肉食。
そうですそうです。
Mutsumi
こういったものをですね、名前をわざわざ指定して作ってもらうっていう形ですね。
ken
めっちゃいいですね。
ちなみにそれは何?チャットGPT?それともジェミニーとかを?
Mutsumi
ジェミニーですかね。
チャットGPTを使うこともありますけど、ジェミニーですかね。
うちがそのGoogle Oneのファミリープランですかね。
ファミリーで、違うか、AIプランが多分家族がシェアできるプランなので、
どちらも活用しているという形ですね。
ken
画像を出してもらうみたいなのあんまりしたことがないけれども、
結構その精度というのはどうですか?足が抜けてたりとか目が微妙な感じになってたりみたいな感じはない?
Mutsumi
全然そんなことないですよ。
すごく何ですかね、クオリティが高い。恐竜存在しないので難しいんですけど。
ken
それっぽいもの。
それこそ塗り絵ブックに載ってても全然おかしくないなっていうものをですね、出してくれたりとか。
Mutsumi
AIがやっぱりやってくれるので、ちょっと難しかったりするんですよね。
4歳の子供がやるとなると。
Mutsumi
でもそれをもうちょっと背景のこういったものを削ぎ落としてほしいとか、
細かくじゃなくてちょっと大雑把にしてほしいとか、そういったことを伝えるとそれっぽく出してくれるので、
すごくやりやすいですし、子供本人がこれを塗りたいっていうものを用意できるので、すごくいいなというふうに感じていますね。
ken
そっか、確かに。子供の年齢に合わせてカスタマイズするっていうのはすごい良いアイデアですよね。
Mutsumi
そうですね。
ken
それでもまた僕もたまにするけど、数学の宿題とか、
なんか巷には数学の例えば掛け算をブラッシュアップするためのゲームがあるんだけど、
ken
それをしようとするとなんかアドが入ったりとか有料だったりとか、あとはなんかこうディスラクション、
余計なものが多い、ゲーミフィケーション過ぎるみたいな時に、
簡単なhtmlファイルでできるようなものを作ってあげると、それっぽくやってくれるみたいなのとか。
Mutsumi
いやーそれもすごい素敵ですね。
いいよね。確かに塗り絵はいいアイデアだね。
Mutsumi
そうですね。
新卒入社から長く働く理由
ken
いやーまあということで、今はちょっと仕事に戻るけれども、社会人歴7年目?
Mutsumi
そうだね。
1年目。
8年目になりますね。7年半が経過しようとしているタイミングです。
ken
おー、なんかちょっとエンジニア人生というのも聞いてみたいんですけど、
Mutsumi
はい。
ken
むつみさんあれだよね、エンジニアで新卒入社した会社に今ずっといるっていう。
Mutsumi
そうです。そうなんです。
ken
だから7年半同じ会社で働いてる。
Mutsumi
そうですね。2019年の4月に入社をして7年半同じ会社で働いているという状態ですね。
ken
結構珍しくないですか?IT界隈だとね。
めちゃくちゃ珍しいと思いますね。
Mutsumi
本当に会う方々に7年半ってすごいですねっていうのは結構言っていただきますね。
ken
入るとき想像しました?自分がここに8年近くいるっていうのは。
Mutsumi
あ、でもそれは正直想像できてたかもしれないですね。
なんでかっていうと、すごく特殊な会社だなっていう認識はしていて、
やっぱり先輩たちを見てもですね、全然僕よりも長く会社に生き生きと働き続けながら在籍している人が多くて、
僕も逆に転職はあまり考えないだろうなという前提で入っていたので、
長く働くだろうなという認識は持っていたけれども、
Mutsumi
振り返ってみると7年半経ったかっていう気持ちは出てきてますね。
ken
確かにね。
そこのキャリアの変遷みたいなのをプロジェクトというよりは
どういうロールでやってきたのか聞いてみたいんですけど、
入社の決め手ぐらいから聞いてもいいですか?
Mutsumi
入社の決め手はですね、学生時代。何年前なんですかね。
ken
なんかインターンとかして入ったんですか?
Mutsumi
いや、この会社ではインターンをしていなくて、
もう本当に先行だけを受けて入社をしたという形にはなるんですけれども、
そうですね、入社の決め手は先行の途中でですね、何人もの社員の方と会わせていただいて、
お酒を交えながらであったりとかで深いコミュニケーションをさせていただいたんですけれども、
会社が小さくて、その時は40人以内ぐらいの会社だったんですね。
その中で住人弱の方々とお話しさせていただく中で、
もう全員がすごく生き生きと働いていまして、
会社の未来についてすごく楽しそうに、
それこそ自分が当事者であるというか、会社を作っている人という認識を持って生き生きとされていたので、
そこが一番僕にとって入社の決め手になったところですね。
ken
いいですね。
いや、なんか、そのお酒を交えてこの新卒をリクルートする感じ懐かしいなと思って、
Mutsumi
僕もそうやって寿司とか焼肉をご馳走になりながら入社しましたけど。
ありますよね。
ken
なんか割とこう、あれかな、生き生きとしただから充実感とか、なんかそういうのが、なんだろうね、見えたっていうのが一つ決め手だった。
Mutsumi
そうですね。
もう一つ大事なのがあってですね、
インターンをしていた別の会社があって、
その会社はすごく日本の中でも急成長していた会社ではあるんですけれども、
急成長する中で、もともとは僕が所属していた部署の採用とかをすごく重んじていて、
そこにいる方々に生き生きと働いてほしいっていうふうに経営陣も思っていたし発言をしていた会社ではあったんですけれども、
急成長に伴ってちょっと採用の基準が緩まってるなというのを僕自身感じていましたし、
インターンを見ながら感じていましたし、
結果として、数年経って僕がもともと所属していた部署は機械だったりとか自動化によって解散するというか、
大幅に縮小みたいな形になってしまったので、すごく生き生き働いている人たちが多かったけれども、
ビジネスの事情で組織がそうなってしまうっていうのは、学生の見ながらちょっと嫌だなというのを僕は感じていて、
結局新卒として入社をした会社はやっぱり社員が一番大事だというふうに言っていて、
まずは社員がすごく幸せになることによって、社会であったりとか株主であったりとかそういった方々に価値を提供することができるし、
それこそがやっぱり株式会社であったりとか会社としてある姿だよねというふうに系人が言っていたのがすごく魅力的に感じて、
だからこそ社員の方々も生き生き働いているんだろうなというのを感じたので、
こう系人が言っていることといろんなメンバーが言っていることがすごく一致していたところが魅力的に感じたという部分ですかね。
なるほど、いや素晴らしいですね。僕は結構日本にいる頃、いわゆるジョブホッパーだったので、
ken
最初の1年前後ぐらいで2社変えて、3社目は結構長かったんだけど、
だからそのいろんな経営者を見てきたけれども、なんかそのすごい経営者のメッセージングがその社員を束ねているっていうのは、
会社としてすごい上手く回っているなあという聞いていた印象を持ちましたね。
いやそう感じますね。なのでその頃よりはすごく人数も増えているんですけれども、
Mutsumi
やっぱりその中でもみんな当事者意識を持って自分がこの会社を作っていくんだというふうに思えるような仕組みづくりをいろんなメンバーが考えていますし、
継続的にやっぱり飲みに行ったりとかランチに行ったりとかしてもそういうコミュニケーションが多いですし、
当事者意識を持っているなというのを今でも感じるというところですからね。
ken
当事者意識ってすごい僕の中で懐かしいワードで、僕の会社で最初に入った会社って当事者意識ってすごい、
すごいキーワードで、ATIって言葉があって、
ATI?
圧倒的当事者意識。
Mutsumi
すごいですね。
ken
そうそうそう、ATIを発揮しましょうみたいな。
それはむつびさんの言葉ですか?それとも会社でキーワードなんですか?
Mutsumi
当事者意識ですか?
当事者意識は会社のキーワードだと思いますね。
結構言われる言葉かな。
ken
なんでその話を広げてみたかったかというと、僕はもう外資5、6年ぐらいになっちゃうんで、
当事者意識の発揮の仕方ってやっぱり日本のAT企業とこっち全然違うなって思ったんですよ。
ken
5、6年経ったから、最近の日本の会社どんな感じかなって聞いてみたくて、
例えば当事者意識を発揮できてる状況、
当事者意識を発揮して活躍してる人って具体的にどういうことをしてます?プロジェクトとか。
っていうのも、
例えば僕の周りだと、
ken
じゃあ当事者意識を発揮する目についたGitHub意思を全部片付けるかっていうと、
そんなことやってたら、
例えば時間がなくなるとか、
あとは他の人のチームのレポジトリに変更を入れるのってすごい大変だったりするんですよね。
技術的にだけじゃなくて政治的にとか。
ken
だからプロジェクトを投げればいいっていうわけじゃないから、
当事者意識を発揮するっていうのも、
ken
目についたボールをすべて拾っていくっていう意味ではもちろんなかったりするんですよ。
むずみさんの会社でどういう人がロールモデルとして働いているのかなと気になったんですよ、ふと。
Mutsumi
そうですね。
僕自身は、
そういった何かしら気になったイシューがあるみたいなことであったりとか、
Mutsumi
別のチームのソースコードで気になった部分があるっていうところも、
当事者意識というふうに言えるかなと思っていて、
それは、
自分がこの組織であったりとか、
事業を良くしたいというふうに思っているからこそ生まれてくる問題だったりとか、
Mutsumi
気になった意識だと思うんですよね。
それが、
優先順位的に違うよねとか、
今そのタイミングじゃないよねとか、
そういった部分は、
どんどん磨いていくべきかなというふうに思ってはいるんですけれども、
前提としてセンサーとして、
それこそ与えられたタスクだけやるのではなくて、
より一層自分には何ができるんだろうとか、
Mutsumi
この組織をどうすればより魅力的な組織にできるんだろうというふうに思う
マインドの部分だったりとか、
センサーの部分だったりとか、
そういったところが当事者意識かなというふうに思っていまして、
具体的な例で言うと、
組織がまだまだ小さい状態ではあるので、
152か200人とかの間だったと思うんですけれども、
その中なので、
比較的別の事業の問題だったりとか、
人疑問に思ったこととかをポロッと聞けるんですよ。
別の事業部の人にランチの間で、
最近こういうのやってるっていうふうに聞いたんだけど、
これってどういうことなのとか、
もっとこういうやり方できないのとかって、
ある種侵害しているかもしれない。
その責任領域を侵害してはいるかもしれないけれども、
前提として誰かが挙げた意見っていうのは、
侵害したいとか攻撃したいっていうことではなくて、
よりこの事業を、会社をより良くしていきたいというふうな、
Mutsumi
全員の共通認識のもと言ってることだよね、
っていうことを表明したバリューがあったりとかするので、
そのバリューのもと、
Mutsumi
それぞれが意見を言うであったりとか、聞くであったりとかして、
より方向を持っていこうと全員が努力しているので、
そういった部分が小さいところにはなるかもしれないんですけれども、
当事者意識が働いている部分かなというふうに思っております。
ken
なるほどね。会社を良くしていくっていうのがすごい納得したんですけど、
どういうところに僕としては収束していったかっていうと、
日本の文化を離れたときは全然違うのかなと思ったけど、
一周回ってみると、ハイレベルではすごい似たことは期待されてるなと思ったんですよ。
ken
会社を良くするっていう表現をしたけど、
確かに僕の会社で言われているのは会社のビジネスモデルを理解して、
ken
会社として回っていくために必要なことっていうのは、
チームとのやり取りとか、自分のキャリアアップするためとかよりも大事なことだよね。
それを継続的に続けていくことができれば、
プロジェクトとしてアウトプットすることができるっていうのが良いことだよねって言われていて、
それを丸と当事者意識でまとめると、
ハイレベルで新卒と同じようなこと求められてるんだなっていう、
実は一緒だったのかなとかって思ったんですよ。
確かに。
最近それを収束してきたんだけど。
Mutsumi
最近なんですね。
ken
そうそうそうそう。
表面的な働き方はもちろん全然違うんだけど、
結局は会社の一員として、会社という組織がシステムが回っていくために、
どう貢献できるかなのかなっていうのを、
どういう言葉で表現するかの違いだなって思ったんで。
Mutsumi
そうですね。確かに。
そうなんですよ。
Mutsumi
面白いですね。
通じる部分があるんです。
ken
そうそうそうそう。
ハイレベルだよね。
いろんな働き方とかマインドセットとかあるけど、
Androidエンジニアとしての歩み
ken
最初はモバイルエンジニア、アンドロイドエンジニアだったんだっけ?
Mutsumi
そうです。
ken
何年ぐらいモバイルで働いたの?
Mutsumi
4年ぐらいですかね。4年弱かな。
働きました。
モバイルやったりその間はモバイル中心で、
Mutsumi
たまにウェブのフロントも触るという感じですね。
ken
アンドロイドエンジニアだったところに使ったフレームワーク、
キーワード、テクノロジーをちょっと散りばめながら、
どんなことしてきたかっていう技術的路線で聞いてもいいですか?
僕も前話したとき言ったかもしれないけど、
アンドロイドエンジニアからキャリアスタートしてるんですよ。
一応ちょっとだけだけど、アンドロイドスタジオ使ったし、
今もアンドロイドスタジオなの?っていうところから聞きたいんだけど。
Mutsumi
今もアンドロイドスタジオですね。
ken
そうなんだ。
僕がアンドロイドアプリをやり始めたのが、
2018年の4月頃ですね。
Mutsumi
なので、正社員として入社する1年前に内定社インターンを開始して、
そこからやり始めたという形でして、
Mutsumi
自分で何やりたいっていうふうに聞かれたんですよ。
エンジニアとして何をやっていきたいっていうふうに聞かれたときに、
将来的にはプロダクトが海外に出たときに、
貢献度が一番高いであろうアンドロイドアプリを書きたいですというふうに僕が言いまして、
Mutsumi
全然プログラミング経験は大してなかったんですけども、
そのタイミングでそのように宣言というかお願いをさせていただいて、
アンドロイドアプリエンジニアになりましたと。
当時は多分いろんな会社がJavaからKotlinへ移行してるタイミングだったんじゃないかなというふうに記憶してました。
なので、僕が入社をした会社も同様でして、
Mutsumi
Javaで書かれていたファイルがほとんどな状況でちょこちょこKotlinがあるっていう形でして、
僕は最初の1ヶ月半ぐらいはテキストブックでひたすらJavaとKotlinでアンドロイドアプリを作るというところを学びながらやっていたという形で、
最初は簡単な背景色をXMLで変えるみたいな部分から、
だんだんとこのプロジェクトの中でABテストとか試したいよねという話がありまして、
ABテストってどうやったらできるんだろうっていうところから、
Mutsumi
Firebaseのリモートコンフィグだったりとかそういったところを調べながら導入をさせていただいて、
少しずつ内定者インターンの期間に1年かけてなんとか機能は普通に作れるようになったかなっていう状態になりまして、
2年目になってからは、その事業部がちょっと大きなプロジェクトをやっておりまして、
海外にプロダクトを展開しようっていう大きなプロジェクトをやっていたんですね。
そこに僕がちょっととある事情で合流することになりまして、
合流もAndroidエンジニア他に1人先輩がいたんですけれども、
ちょっとその先輩が別の事業部に移動するので、
まるまるそのプロジェクトのAndroidアプリを僕が1人で書くみたいな形になりました。
そのプロジェクトは本当に大きくて、
数年運用したアプリをデザインからコードベースからフルスクラッチで作り直しますみたいな。
ken
なるほど、熱いですね。
Mutsumi
やってまして、基盤みたいなところ、ディレクトリ構成だったりとか、
どういうアプリケーションアーキテクチャでやっていくかみたいなところの基礎は先輩が作ってくれていたので、
Mutsumi
僕がやることは、だんだんと出来上がる仕様とデザインに合わせて、
ひたすらコトリンでそのアーキテクチャにのっとって、
プロダクトを作っていくっていうことをしていましたね。
Mutsumi
それが新卒1年目で、1年目はほぼほぼそれでずっと使っていたかなっていう形ですかね。
2年目の途中、7、8月とかにやっとそれを出すことができて、
なんとかそれが終わったっていう形ですかね。
ken
その時に採用したアーキテクチャとか覚えてますか?
なんかモバイルの世界ってアーキテクチャに色々名前がついていて、
綺麗なコードベースをするのを色々試行錯誤している印象があるんですけど。
Mutsumi
MVVMっていうものだったと記憶していますね。
モデル、ビュー、ビューモデル。
ken
ビューモデルか。
Mutsumi
当時ビューモデルがですね、
もともとは多分Rx系リアクティブプログラミングのRx Javaとか、
そういったものを利用して、
いかにビュー側に変更を伝えるかっていうのを、
サードパーティーのライブラリーで頑張っていたところを、
GoogleだったりAndroidのチームがライブデータというリアクティブなものを作ってくれて、
それにのっとってこのアーキテクチャで作っていきましょうみたいなものを、
Android自らがガイドライン的なものを公開してくれていたんですね。
なので基本的には僕もそれにのっとって作ろうとしていたという形ですね。
ken
そうなんだ。じゃあリアクティブの流れを若干覚えてるけど、
すごいリアクティブが流行ってた時期に僕はモバイルを離れた気がするけど、
その後の流れとしてはライブデータとか、
Googleが公式で出したアーキテクチャを採用していく企業も結構増えていったみたいな印象でいいんですか?
Mutsumi
そういった印象で合ってると思いますね。
ken
リアクティブ自体は完全に廃れたとかではないのかな?
今使ってる人は使ってるぐらい。
難しいですね。
Mutsumi
もともと多分リアクティブの入り始めとかで使われていたRX系は多分今はもうあまり使われていなくて、
概念としてはだいぶ残っているけれども、
使う道具としてはGoogleが出しているものを基本的にはみんな利用しているという認識をしていますが、
とは言ってもですね、正直僕もAndroidを離れて数年経っているので、
もしかしたらこの間に大きなパラダイムシフトがあった可能性はゼロじゃないと思いますね。
というのもさっきその4年くらいAndroidをやったという風に言ったんですけれども、
そのAndroidをそれこそ終えるタイミングぐらいでビュー側が大きく変わりまして、
もともとXMLとかで書いていた、構築していたと思うんですけれども、
そこからJetpack Composeというものになりまして、
リアクトだったりとか、
ken
似たような流れがあったよね。
そうですそうです。
ストーリーボードだっけ、違うかな。
Mutsumi
ストーリーボードで構築していたものを、
セーフトUIという宣言的UIに移り変わるタイミングで、
多分それよりも早くAndroid側はXMLからJetpack Composeに変わっていくぞみたいなタイミングでしたね。
ken
なるほどね。
Mutsumi
はい。
ken
懐かしい。
Jetpackを知らないかもしれない。
本当ですか?
ken
わかんない、その当時の最新を追ってた人は知ってたかもしれないけど、
少なくとも僕のチームに降りてこなかったな。
Mutsumi
それが多分2022年とかですかね。
ken
そっか、じゃあいないわ。
Mutsumi
それがJetpackがアルファとかベータとかで、
利用はもちろんできるけれども、
ちょっと複雑なUIになるとまだXMLでリサイクラービューとか、
いろんなものを利用して作ったほうがいいよねっていう状態でしたね。
多分もう全然デファクトになっていると思うんですけど。
ken
なるほどね。
ちなみにリアクトモバイル、リアクトネイティブだ。
Mutsumi
リアクトネイティブ。
ken
リアクトネイティブとかそういう道は通りました?
一つの言語でiOSもAndroidもコンパイルできる。
Mutsumi
それは通りましたね。
僕はFlutterを通りました。
Flutterで進めたアプリ開発
Mutsumi
Flutterはすごく好きでしたね。
ken
どんなところか。
Mutsumi
そうですね。
それこそ先ほど言っていたAndroidのプロジェクトで、
1年ちょっとかけて作っている中で、
すごく痛感したのが、僕と歴の長い先輩がiOS側をやっていたんですけれども、
Mutsumi
この2人でほとんど同じ画面をすごい長い時間かけて、
2人が同時に作ってるこれって何なんっていうのをすごく感じていて、
この時間もったいないなっていうふうにちょっと思ってしまっていたんですね。
今思えばちょっとOSに対するリスペクトが足りない気もするんですけれども、
純粋なアプリ開発者としてはそういったことを思っていて、
Mutsumi
何かしら解決できる手段がないのかというふうに思っていたところに、
React Nativeはもともとは知っていたんですけれども、
先輩に話したときにReact Nativeは辛いんだよねっていうことをぼやいていて、
あんまり積極的に受け入れるスタンスというか、
受け入れる感じには見えなかったので、
他にはいい方法がないのかなというふうに調べていたところで、
フラッターがちょっと熱くなってきたタイミング、
それが2020年7月頃ですかね。
そのタイミングでちょうど大きなプロジェクトが一段落したタイミングで、
別の事業部の方でAndroidアプリを作りたいんだという話が上がりまして、
Mutsumi
社内でほぼ唯一のAndroidエンジニアという立場だったので、
僕にどう作るのがいいかというのと、
Mutsumi
それこそiOSアプリはすでにあるんだけれども、
こっち側のリソースも含めて何とかしたいから、
Mutsumi
いい案はないかという話をもらいまして、
当時もフラッターをちょっと実験的に変えていったりとかしたので、
Mutsumi
こんな形のアプリであれば作れますよっていうのを
全然言える状態にはあったので、
Mutsumi
もともと同じ会社の中で知っている隣の事業部ぐらいの距離感だったので、
この事業部でやりたい要件なのであれば、
フラッターはすごい適してると思いますし、
これによってAndroidアプリを作ってリリースすることはもちろんのこと、
将来的にiOSアプリを統合して出すということも可能だと思いますというふうに、
隣の事業部のリードに提案させてもらって、
結果としてフラッターでちょっとやってみようというふうに、
引き手をしていただいてやったという形ですね。
ken
やってみてどうだった?
Mutsumi
結果としては本当にすごくよくて、
なんでかというと、
フラッターの開発チーム側がすごく簡単にきれいな画面を作れるコンポーネントを用意してくれているということと、
React Nativeと違って、
フラッターのレンダリングエンジンがNativeの、
ちょっと表現が正しいかどうかわからないんですけれども、
Nativeの上にある種描画されるという形になっていて、
Webのキャンバスとかと多分近いがいいので、
この上にフラッターのいろんなビューが描画されるので、
OS間でのズレみたいなところも全然ないので、
きれいにビューが描けるし、
それもOSの差異がないというのがすごく魅力的で、
かつUIの構築の仕方が宣言的UIなので、
Reactだったりとかに馴染みがある方が、
おすっと入りやすい形だったんですね。
なので、僕が一番最初に、
こういった感じで作るといいですよっていう、
テンプレート的なページをいくつか作って、
認証だったりとか通信部分とかも含めて作っておいて、
なので、これを真似てくださいっていうのを他のエンジニアの方々に、
Mutsumi
その方々はフロントの経験が多少ある人たちで、
モバイルの経験はあまりないっていう人たちだったんですけども、
そういった人たちにもすっと入ることができて、
4ヶ月ぐらいでアプリをリリースすることができたので、
Mutsumi
だいぶスピード感を持ってクオリティー高く出せましたね。
ken
なるほど。なんか面白いねフラッター。
ようなエンジンの話とかも面白い。
ローレベルAPIを使ってるからCPUの処理性能がよりいいみたいなことなんだろうか。
なんか深掘りがありそうな話。
Mutsumi
そうですね。そこはもうちょっと僕も調べてみたいかもしれないですね。
それこそ1,2年前ぐらいにレンダリングエンジンが変わったことによって、
よりフラッターのビューが綺麗になったとか、
動きが安くなったっていうのも聞いたので。
ken
そっか。モバイルを掃除って4年やったと。
たぶん途中でバックエンドに転身した話に振ろうと思うんだけど、
その前にせっかくモバイル話をしてるから1個最後に聞いてみたくて。
もちろんモバイルエンジニアを離れて数年経ったからあれだけど、
ken
少なくとも僕よりモバイルエンジニアを最近まで触ってたということで。
2026年でいろいろAIツールが来てるじゃないですか。
Mutsumi
はい。
ken
もし今年同じような技術選定をするとしたら、
AIコーディングによってやっぱりフラッターの方が使いやすいのか、
ken
それともネイティブのSwiftとAndroidのAPI、
Kotlin経由で触る方が書きやすいかで言うと、
そこら辺のトレンドとか意思決定の、
ken
自分だとどっち選びますかっていう。
多分当時はAIツールなかったですよね。
チャートGPDとかにフラッター。
Mutsumi
なかったですね。
これ最近記事出てましたよね。
わかんない。
Mutsumi
あれ本当ですか?
ken
どこから?
Mutsumi
ケンさんの会社から。
ken
嘘?
Mutsumi
あれ?
ken
どこ?パブリックのエンジニアリングブログ?
Mutsumi
そうです。リアクトネイティブからネイティブに。
ken
本当?僕全然わからない。
Mutsumi
ちょうどモバイル界隈でそれこそですね。
すごい話題になってまして。
ken
僕がそのネタを知ってて振ったみたいになっちゃったね。
違いますか?
ken
割と本当に普通に聞いて。
社内の流れも知ってるけどね。
社内の記事が多すぎてあんまりパブリックなのを置いてないんだよね。
Mutsumi
なるほど。
じゃあパブリックに出してるのよりもっともっとあるんですね。
ken
もちろんそれはそうだと思うんだけど、どこの企業もね。
やっぱりパブリック出せ以上のものが動いてるから。
ken
昔ちっちゃい会社にいた頃はRSSフィード。
RSSフィードもちろん古いかわかんないけど。
そんなことないと思う。
RSSフィードとかでキャッチアップするの多かったけど。
なんか今は社内にトレンドをうまくさまってくれる重鎮とかがいるから。
社内の人フォローしてるだけでもいっぱいいっぱい。
逆に言うといい感じの社内のフィルターが入ってるから。
Mutsumi
すごい。
ken
いいのか悪いのか知らないけど。
なんでちょっとあの。
今うちの会社のパブリックブログ読んでなんかめっちゃ記事出てるなって思いました。
まあいいや。ちょっと脱線しちゃったけど。
Mutsumi
そうですね。僕はどうですかね。
僕はでもやっぱりフラットアイラブだろうなというふうに思います。
いや、どういう事業部に関わるか、どういうビジネスに関わるかっていうことには依存すると思うんですけれども。
あくまでも僕が関わったことがあるビジネスの範囲内での判断にはなってしまうんですけれども。
そこまでOSネイティブなUIを構築する機械であったりとか。
OSネイティブが何かしらの機能を使いたいですっていうケースがあまりなかったなっていう経験がありまして。
それなのであれば、スビヒットとコトリン両方書いてもらって、書いてもらうだけでも出力トークン食うなっていうことを感じますし。
それこそ何か、これはどこまでコードレビューをするのかとか構築責任を持つのかっていう問題には発展してしまうんですけれども。
いずれにせよその責任が2箇所に分散されてしまうっていう問題が生じるなというふうに僕は感じるので。
大きくその2点からやっぱりFlutterを選ぶだろうなというふうには感じますね。
React Nativeを選ばない理由みたいなところで言うと。
そうですね、すごくでも大きなところがあるわけじゃないんですが。
Mutsumi
でも大きなところがあるわけじゃないんですが、やっぱり僕はさっきのFlutterの独自のレンダリングエンジンがあって、
それの上で描画されているっていうことが一番魅力的だなというふうに思っている部分ですかね。
OSに左右、さっきの話とも被る部分があるんですけれども、
やっぱりOSにあまり左右されないビジネスが基本的にほとんどだとした場合にあるならば、
ビュー自体もOSにそこまで依存させたくない。
結局React Nativeを選んでしまうとOSのUIコンポーネントを利用する形にはなるので、
OS側での最低のSDKバージョンであったりとか、サポートするバージョンであったりとか、
ターゲットのバージョンを上げたタイミングで何かしらの変更が加わるというものをできるだけ避けるのであれば、
一段階そこが抽象化されていて安全なFlutterを選んだほうがいいだろうというふうに思うケースが多いだろうなというところですかね。
ken
なるほどね。確かにすごいメイクセンスがあると思いました。
どっちの技術がいいという話よりは本当に会社のポジショニングとか会社の規模とか次第だよね。
Mutsumi
そうだと思いますね。それでやっぱりより一層、
iOSとか特にそうだと思うんですけれども、
ネイティブでいろんな機能を追加してくれてたりとかすると思うので便利な機能を、
そういったものをやっぱりより最先端に活用してユーザーに価値を届けたいっていうのがあるのならば、
やっぱりそれに早く追従できるようにネイティブで書くっていう方が魅力的だなというふうに感じますね。
ken
読まちがえない。
ありがとうございます。
プロダクトマネージャー挑戦の苦い経験
ken
ちょっとバックエンドの転身の話も聞きたいなと思うんですが、
モバイルは話しておりました?実はこういうプロジェクトをもう1回やってないみたいなのがあったら是非それを言ってもいいけど。
Mutsumi
いや、そうですね。技術的にはそんなにないかもしれないですね。
僕、実は、これは技術とは関係ないんですけれども、
それこそ4年目になったタイミングで半年間ぐらいプロダクトマネージャー見習い的なことにチャレンジした期間がありまして。
ken
その話を詳しく聞いてみたい。
それはそもそも自分で。
Mutsumi
これはですね、僕が自分で事業責任者の方にチャレンジさせてほしいですっていうふうに言ってやることになったものですね。
っていうのも、入社した時からそうだったんですけれども、
事業を作れる、プロダクトを作れる人になりたいっていうのがすごくありまして、
なので、もともとはエンジニアとして技術を深めたいというタイプというよりは、
どんどんプロダクトを作っていきたい。
逆に価値あると思われる機能を提供したいという気持ちが強くあって、
そこにエンジニアとして意見を出すことはもちろんしていたけれども、
Mutsumi
やっぱり自分がこれだと思う機能を提供したいということで、
そのタイミングでチャレンジをさせていただいたという形ですね。
それはやる前から起点を決めてやったの?
Mutsumi
そうですね。
ken
面白かったらずっとプロダクトマネージャーになるわぐらいの勢いでやったの?
Mutsumi
それでいうと後者ですね。
このままうまく…
ken
どうだったか、戻る決断をしたのかみたいなところを聞いてみたいぜひ。
Mutsumi
そうですね。
やってみて本当に辛かった半年間だったなというふうに思ってまして、
おもはや黒歴史と思いたいぐらい状態なんですけれども、
ユーザーに価値を提供したいというふうに思っていたし、
こういう機能があればいいんじゃないのかっていうのは
エンジニアとして何度も提案はしていたけれども、
いざプロダクトマネージャーになり、ユーザーのペインは何なのか、
このサービスを利用してくれている人は、
どんなものを潜在的に渇望しているのか求めているのかっていうことを
Mutsumi
ヒアリングはできるけれども、その後のソリューションが思いつかない。
思いついたとしても自信が持ちきれず、これでいこうという
すごくポジティブで前のめりな気持ちになれないっていうのに
苛まれたという形ですかね。
ken
だから、課題発見はできたが、その課題を解くための解決策が思い浮かばなかった。
もしくは、どれを取ったらいいか自信が持てなかったみたいな感じ。
Mutsumi
そうですね。おっしゃる通りですね。
ken
お腹が空いてるのはわかったけど、アイスクリームを食べたらいいか、チョコレートを食べたらいいか、
なんかもう決められないという感じ。
Mutsumi
あ、そうです。そうだと思います。
この人たちはこういう課題なんだと思うけど、
Mutsumi
で、何あげればいいんだろうみたいな。
いや、なんか人によって好きな食べ物は違いそうだしな、みたいな。
タイミング、コンテキストによって食べたいものって変わってくるよな、みたいな。
そういったものを持ってですね、全然自分で意思決定ができず、
何度やっても、いや、なんかソリューション抽象的だよねっていうフィードバックだったりとか、
なんかペインが、ユーザーの声からペインは確かに自分たちもそうだなと思うけれども、
ソリューションは確かにあんまりしっくりこないよねっていうフィードバックをチームメンバーからいただいていて、
だとしてもどう前に進めればいいのかよくわからないなっていうことに苦しんで、
でも自信が持ちきれないまま、何とかこの方向で勝負するしか今のうち手だとないなっていうものを提案して、
結果的にはチームとしてはそんな方向で進めることになって、
リリースまではいったものの、うまく当たらずだったっていうのも含めて苦い思い出の期間はありましたね。
ken
なるほどね。いや、なんかその話面白いな。なんか意思決定の話なのかな。
プロジェクトマネージャーのスキルみたいな話。僕はプロジェクトマネージャー、
をやったことは、がっつり言ってやったことはないので、ちょっとわからないけれども、
なんかその意思決定の難しさっていうところなのかな。
Mutsumi
そんな気はしますね。
ken
振り返ってみて。
Mutsumi
そうですね。振り返ってみて、そもそも引き出しが少ないっていうところもまずあると思います。
ken
ソリューションの引き出し?
Mutsumi
そうですね。ソリューションの引き出しの部分ですね。
よりやっぱりプロダクトを作っていきたいとか、価値を提供していきたいのであれば、
普段からいろんなアプリを触っているときに、ユーザーのどういうニーズに指すためにどういうソリューションを提供しているんだろうとか、
最近新しくこういう機能が出たけれども、これってなんで存在しているんだろうとか、
この後どう進化していくんだろうとか、そういった仮説を持つであったりとか、
疑問を持つことによって自分の引き出しを増やすということをしていなかったなというふうにまず一点思うと、
それができていたとしても、結局何を選ぶのがいいのかという意思決定はまた別の話でできなかったなというのと、
これは今も多分苦手だなというふうに思う領域ではありますね。
ken
うーん、なるほどね。面白いな。いや、SREも親和性があるんですよ、その意思決定の話は。
全然この状況は違うけど、例えばインシデントが起こって何か障害が起こって、
その軽減、ミティゲーション、軽減策を打たなきゃいけないときに軽減策がAとBとCあります。
Aにはこれぐらいのリスクがあって、これぐらいで復活するでしょう。
Bにはこういうリスクがあります。Cにはこういうリスクがあります。どれ選びますかってなって、
そう、バイスプレジデントはAがいいって言って、うちのチームの子さんはBがいいって言って、
なんかチームのディベロッパーはCがいいって言って、はい、じゃああなたどうしますかみたいな。
うーんみたいな。で、なんかもうどれも良さそうに見える。
でも誰かが意思決定しなきゃいけない。よしじゃあBで行こうって。
やるみたいなのがあるのに、なんかその似てるなと思って、その意思決定という側面だけに着色、注目すると。
いやー、そうですね。 プロデューサーが分かんないことってあるよねっていう。
いやーすごく感じた。 みんな燃えてるのは分かってんだけど。
誰かが早く意思決定しないといけない。
ken
そうですね。
で、プロダクトの世界で同じことが言えるか分からないけど、僕らの世界ではとりあえず早く意思決定をする。
その何もしないっていうのが一番もったいないから。
とりあえず早く意思決定をして何かミティゲーションすると、プランBがうまくいかなかったことが分かるので、
プランAかCに行けるよね。もちろんそのリスクも考慮する必要があるけどね。
Bを取ったら、なんかその取り返しのつかないことが起こる可能性もあるから。
確かに。
ken
プロダクトの世界だとどうなんだろう、A、Bテストしてとかなんか、
とりあえず早く市場に出してフィードバックもらって、どんどん機能出してとかっていう方向に。
Mutsumi
それはすごくあったんだろうなというふうには感じますね。
結構その、市場の空論じゃないですけど、だいぶ頭の中だけだったりとか、
自分たちのフィグマ上だけで話していたなというのは思っていまして、
もっと早くフィグマの中でも動くプロトタイプを活用するだったりとか、
自分がエンジニアなんだからもっとサクッと作って顧客に当ててみるとか、
そういったちっちゃい実験を繰り返していたら、
Mutsumi
より素早く何かしらの方向性に進むことはできたんだろうなというのは感じますね。
ken
なるほどね。実際はユーザーに当ててみて。
Mutsumi
そうですね。
ken
いや分かります。フィグマの世界では動くんだけど、当ててみて全然動かないっていう。
Mutsumi
いやおっしゃる通りですね。こういったものは本当に早く、
機場の空論じゃなくて早く当てるべきだったなっていう部分はそうですし、
自分に引き出しを持てるようにより日頃からセンサーを持とうというところもありますし、
本当に究極選択できないのであれば、もう意思決定はあるし、
まず最初はできる人だったりとか、誰かにお願いしてその背景から何かしらを盗むであったりとか、
その前後の結果から何かを得るであったりとか、そういったことをするべきだったなというのは、
うまくいかなかったからこそそこからそういったことを学んでいるという感じですかね。
ken
なるほど。なんかすごい神話性があります。
こういう時にうちのチームで、うちのチームじゃないかな、僕とかマネージャーで言うのが、
ken
言葉があって、英語なんだけどね、
in theory, there is no difference between theoryand practice.
in practice, there isっていう、
セオリーはセオリーとプラクティス、何違いがないけど、
in practice 実践はあるよねっていう、だからその、ちょっとジョークなんだけどさ、
フィグマとか僕らのアーキテクチャの議論がセオリーで、
実際にユーザーに当ててみるとか、実際にミティゲーションしてみるのがプラクティスにすると、
何、セオリー上はこれがいくはずだとか、
このソリューションが効くはずだとか、このミティゲーションがうまくいくはずだってやるけど、
やってみないとわかんないことがある。
さっさとプラクティスしてみるっていう。
いや、まさにですね。
ken
そうかそうか。で、それでやってみて、なんかうまくいかなくて、
よし、エンジニア戻るかってなったわけ。
Mutsumi
あ、そうですね。えっと、ちょうどそのタイミングで、
うまくいかず、半ば、少しだけ逃げる形で、
大石の育休に入りまして、で戻ったら、
ken
タイミングでリセットできた。
Mutsumi
そうですね。戻ったら別の人がそのプロジェクトを引き継いでガンガン進めてくれていて、
育休から戻って、可動時間が明らかに減る中、
Mutsumi
俺が今貢献できるのはエンジニアだという風に考えて、
エンジニアに戻ってガツガツ行動を書き始めたという形ですね。
バックエンドへの転身
ken
その時バックエンドに戻ったの?一旦アンドロイドで戻ったの?
Mutsumi
一旦アンドロイドで戻りました。
その後すぐ事業部の移動が行われまして、別の事業部に行き、
そこでバックエンドに転身したという形ですね。
ken
それは自分の希望もあり、転身したの?
それとも事業側からのリクエイメントとか優勢とか?
Mutsumi
両方ですね。アプリエンジニアを長年やっている中で、
やっぱりアプリだけじゃなくて、バックエンドも書けるようになって、
ある種なんでもできますじゃないですけれども、
事業部の状況に応じてやるべきことに取り組めるように、
自分のスキルセットを増やしたいという気持ちがもともとあって、
Mutsumi
移動した先の事業部で、正直求められたこととかは特になかったんですけれども、
組織の再編みたいなタイミングだったので、
求められたことがあったわけではなかったので、
逆に自分で探すタイミングで、ちょっと事情もあって、
Mutsumi
アプリチームを作ろうというふうに僕が決めて、
何人かモバイルエンジニアがいたので、
その人たちとデザイナーと僕とでアプリチームを作ることにしまして、
Mutsumi
このアプリチームを動かしていくときに、バックエンドのエンジニアがいないよね。
じゃあ僕がやりますっていうふうに言って、
バックエンドを、ある種ちょっと自分のスキルセットを広げたいっていう気持ちもありつつ、
事業部にとって必要だったので、
アプリチームを編成しながら自分もバックエンドをやるっていう形になりました。
ken
当事者意識ってやつですね。
Mutsumi
当事者意識っていうやつなんですかね。
ちょうど元々いたメンバーが既存のオンゴーイングなプロジェクトで忙しそうで、
実験がなかなかできていなかったっていうのと、
アプリ側の改修だったりとか機能改善がなかなか進んでいないっていう事情があったので、
じゃあ何人かちょうどアプリエンジニアが合流したし、
ビジネス的に実験したいこともあるし、
Mutsumi
アプリチームを作ったらそういった実験だったりとかアプリの機能開発もできるから、
これはちょうど良さそうだねっていう部分と、
もうその時点で会社で4年弱ぐらい働いていて、
アプリ側で技術的な意思決定だったりとか、
先ほどのフラッターのプロジェクトを牽引したっていう部分だったりとかで、
Mutsumi
信頼もある程度あったので、バックエンドやりますって言っても、
無積みだったら大丈夫だろうというふうに信頼していただいて、
バックエンドに転身できたという形ですね。
ken
バックエンドって技術的にはどんなのを使ってて、
どんなものを作ってたんですか?
バックエンドって言っても結構いろいろあるかなと思ってて。
Mutsumi
そうですね。移動した先が求人サイトを作っていたので、
長年運営されているサイトで、
バックエンドは主にRuby、Ruby on Railsで、
あるタイミングからRailsから別の言語、Goに、
だんだんビジネスロジックであったりとか、
APIを移行していこうっていうプロジェクトが進んでいまして、
Mutsumi
なのでメインで言うとRailsとGo両方ありますっていう状態でした。
その中でやっていたこととしては、
最初はそれこそ簡単なアプリに必要なAPIを作りますって言ったところで、
既存のテーブルを活用して何か情報を取ってくるAPIの作成であったりとか、
そこから派生して新しいデータを作ります。
テーブル設計からモデル設計、API設計までやりますって言ったところを、
スタートラインとしまして、
そこからだんだんといろんな機能開発を進めていったという形ですね。
例えば、求人サイトなので検索エンジン側を活用するものがあったので、
オープンサーチを活用してオープンサーチで純正にキーワードでの検索だったりとか、
条件でのフィルタリングによってそのまま結果を表示するんじゃなくて、
返ってきた結果からリランキングをかけて表示しましょうねみたいなことを入れるであったりとか、
Mutsumi
ちょうどバックエンドに転進し始めたタイミングが、
コパイロットとかGPTが登場したぐらいのタイミングだったと記憶しているんですよね。
2023年の初めなので。
なのでLLMを活用して何かしら機能として提供したいよねっていうのが事業部としてあったので、
それこそLLMを活用したものを機能として提供する、APIとして提供するとか、
LLMと通信するとかそういった部分も担当していたという形ですかね。
ken
なるほどね。
インフラ周りはどういう技術を使っているんですか、データベースとか。
Mutsumi
インフラは基本AWSに乗っていて、
MySQL互換のAWS Auroraを活用していて、
Mutsumi
アプリケーションとかはEKSですね。
EKS上で別カポットが上がっているみたいな形ですね。
ken
Auroraいいですよね。どうですか。
使いやすい。本当に完成している気がするプロダクトとして。
Mutsumi
そうですね。すごく使いやすい。
違和感がないというか、そんなに不便なことはないなというふうに僕自身は感じますね。
ken
バックエンドエンジニアのロールとして、
例えばEKSにアプリ乗せますというときのデプロイメントとかは触る?
それは別のチームがやる?
Mutsumi
デプロイメントは触りますね。
イメージ何使いますとか、ポットのCPUメモリーどれくらいにしますとか、
そういった領域も触りますね。
ken
EKSクラスター自体の管理は別の人がしてる?
Mutsumi
そうですね。そっちは別のインフラ担当の人がやってくれているという形ですね。
ken
データベースは誰が管理してるの?
例えばデータベースはテーブルじゃなくて、
データベース自体はアプリごとに作ってアプリチームで持って、
バージョンアップグレードとかも自分のチームで持っている?
バックエンドチームは持っている?
Mutsumi
バックエンドチームがバージョンアップは持っていないですね。
その事業部は数名のインフラ担当と、
あとはバックエンドももう何人かいるみたいな状況で、
そのバックエンドメンバーは基本的には機能開発がメイン。
インフラ環境のバージョンアップだったりとか、
Mutsumi
そういった部分はインフラメンバーが持ってくれているという形ですね。
なるほど。
ken
懐かしいな。そういう似たような構成の組織体制の会社で働いていたことがあるので。
そうですよね。
ken
じゃあテクニカルなことを聞いたけど、
次はフワッとしたところを聞いてみたいけど、
バックエンドに転身して数年やってみて、
ken
どうですか?キャリアの観点でもいい?
モチベーションの観点でもいいし、
作ってるものとかでもいいし、
今後もしばらくバックエンドやっていきたい感じですか?
それともファイルにまた戻ってみたいとか。
ビジネスロジックとシステム設計の面白さ
Mutsumi
僕はバックエンドに転身して、
すごくすごく楽しいなっていう気持ちですね。
ken
どんなところが?
Mutsumi
どんなところが。
確かにどんなところが楽しいんだろうな。
ken
モバイルではできる領域が広がったけど、
バックエンド始めてからまた新しくできることが
グワッと広がるのが楽しいみたいな感じなのかな。
そうかもしれないですね。
Mutsumi
サービスの根幹を扱ってるっていう感覚がすごくあって、
やっぱりこう…
ken
ビジネスロジックを書くっていうところかな。
Mutsumi
そうですね。
ビジネスロジックを書くといった部分であったりとか、
どうデータを保存しますかみたいな部分が、
Mutsumi
やっぱりより変化が激しい事業部だったりとかすると、
そのテーブル設計がミスると、
何かしら変更を加えたいときに、
あ、ここちょっとテーブル改めて再設計しないといけないじゃんみたいな
部分であったりとか、
じゃあそのデータ以降どうしようねっていったところが
生じてしまうと思うんですけれども、
その難易度、ある種事業の行く末とかも
プロダクトマネージャーであったりとか、
そういった人たちと想像を膨らませたりとか議論をしながら
設計をしてみて、実際運用してみて、
変化に耐えれる耐えれないっていうところを経験してみて、
うわ、この設計だと難しかったかっていったフィードバックを得て、
より理想な、ケースバイケースだったら思うんですけれども、
より理想的な形を追い求めている部分であったりとか、
同様に、
起動機処理をどういう風に行いますかみたいな部分を取っても、
僕は本当にエンジニアとしての知識がなかったので、
ニュースに起動機処理といえばスレッドで処理しますっていった部分か、
Mutsumi
もしくは急に入れてワーカーが処理しますっていうことぐらいしか
頭にいなかったんですけれども、
Mutsumi
それだとDBにはデータ保存されるけど、
ワーカーの急にデータを保存する前に処理失敗しちゃったら届けらんないよねみたいな話とかは、
確かにっていう風に思ったりとか、
その順番変えたらデータ作られてないのに送られちゃうよねっていったところとかも、
何ですかね、すごく確かにって思って、
やっぱり改めて正確に届けるにはだったりとか、
システムがいかに急なトラフィックが来たとしても耐えられるようになるか、
こういったサービスとして求められる水準、
ビジネス的な変化もそうですし、
ユーザーからの要求っていった部分にも耐えれるかっていったところを考えて設計して検証できる、
ある種理想的なものに仕上がっていく、この営みがすごく楽しいなという風に感じています。
ken
なんかすごい美しいまとめだなという、
エンジニアリングという営みがあって、僕は今後真似していこうかなって思ったんですけど、
ken
バックエンドの魅力ってそこだよね。
僕も広告事業でバックエンドやってたことがあるんだけど、
要するにビジネスモデルをビジネスロジックという形でコードに落とし込む、
ken
お金を稼いでいる企業のフローを再現可能なプログラムというものに落とし込むから、
そこがすごい面白いなとか、なんでこの会社はこのビジネスでお金を回して動かっているのかみたいな、
そこの抽象的なものを動くコードというものでブレイクダウンしていくというのがまず面白いし、
そこで変えたコードがお金に直結するわけだから、
例えばさっきオープンサーチを使ったランキングとか言ったけど、
ランキングのロジックを変えているわけじゃないですか。
そのランキングのロジックによってビジネスモデル次第だけど、
ユーザーへの見せ方も違うし、ユーザーへの価値を提供する仕方も違うね。
ランダムに検索結果を出すのか、ユーザーのコンテキストを理解して推薦、
レコメンドエンジンとして出すのか、それともジオロケーションを加味して出すのかによっても、
ビジネスの根幹が変わってくる。
それをコーディファイしていく、コードに落とし込んでいくというのがすごい楽しいし、
ken
僕が途中にSREに流れちゃったけど、そこにインフラ、マシンの上で動かすから、
やりたいことが全部できるわけじゃなくて、
制限、constraint、制約があるわけだよね。
例えば予算がこれぐらいしかないから、
潤沢にデータベースを大きくできません。
だからパフォーマンスの高いデータモデルにする必要があります。
じゃあそれはどうするのかって、頭をひねってパズルのように考えるっていうところの観点がすごい。
パフォーマンスエンジニアリング的な観点も面白いし、
ken
なのでバックエンドの醍醐味っていうのは、僕もバックエンドエンジニア離れちゃったけれども、
本当にこのビジネスモデルを向き合うすごい楽しいところだなっていうのがあるから、
どの会社によって働くかによっても全然学べることは違うけどね。
流通のバックエンドエンジニアとコマースのバックエンドエンジニアは全然違うけど、
面白さの醍醐味は一貫してるなと思いましたね。
Mutsumi
そうですね。本当にそう思いますね。
そのドメインをやっぱり理解して、だからこそコードとしては定義しておくべきだよねとか、
こういう作りにしておくべきだよねというふうに考えるようになったのは、
バックエンドやり始めてからだなというのを感じましたね。
ken
なるほどね。
いやー、結構深掘ってきましたけど、なんかキャリア面で話し足りないときはありますか?
ken
1時間超えちゃったけど、約束の。ごめんね。
Mutsumi
全然全然。そうですね。話し足りない。
AI時代にビジネス価値へつなげる
Mutsumi
最近でもより楽しいなというふうに感じている部分があってですね。
ken
どんなところが?
さっきのビジネスロジックをコードに落とし込むっていった部分ももちろんすごく楽しいんですけれども、
Mutsumi
AIによって機能開発の部分はすごくコードを書いてくれるようになりましたし、
事前の設計であったりとか、その仕様次第っていった部分もありますけれども、
AI待ちっていうタイミングがちょこちょこあるなというふうに思っていて、
このタイミングで今まであまりできていなかったCI側の改善であったりとか、
テストを増やしていきましょうという話とか、
オニタリングを整えていきましょうっていった部分を少しずつ僕がやってみているんですね。
これによって、やっぱりどっか、うちどっか使ってるんですけど、
そのイメージサイズが変わることによって、
Mutsumi
マシンのリソースがここまでいらなくなるよねっていったところとか、
プルがすごく早くなるから、ポットの立ち上がり早くなるよねっていった部分に貢献できて、
何かあったときの復旧早くなるよねっていったところとか、
こういったところもすごく魅力的ですし、
CIが早くなると、他の開発者がやっぱりイテーション早く回しやすくなるなっていった部分もすごく感じて、
いまして、本当に何か数十、例えば10分とか数十分かかるものが本当数分で終わるようになる、
1分で終わるようになるっていっただけで、
全然彼らがやりたいことを回せる速度が変わってくるなっていった部分とかはすごく魅力的ですし、
あまりモニタリングとかが整えられていない状態だったんですけれども、
少しずつデータドックを利用して、
いまどういったリクエストが来ていて、
Mutsumi
どこのアプリケーションにどういう服が、どのタイミングでかかっていて、
これは結局、求人サイトなので、SEO観点で来ているアクセスなのか、
実ユーザーにも影響があるアクセスなのか、
こういったところを切り分けながら、
これは確かに検索だったりとかSEO目的で来ているけれども、
Mutsumi
ちょっとユーザーにも影響が出てしまっているから、
こういうふうに変えたほうが良さそうだねっていった部分もですね、
もともとは純粋なプロダクトマネージャーと、
2人3客でプロダクトを作っていくだけっていったところから、
より開発者のみんなが安定して、
早くデリバリーできるような場を整えるであったりとか、
システムに何か起きていないかをみんなが見れる場を作るであったりとか、
そういった領域にも最近は手を出せるようになってきていて、
そっち側も、より多分サービスの中心に関わっているであったりとか、
サービスにおいて自分が関われる領域が増えているっていうことにすごく喜びを感じて、
楽しいなと思っている仕事内容ですね。
ken
そうだね、やったことが数値として可視化しやすいし、
さっきのCIのイメージによるプルの価値、プルが早くなったりとか、
CI時間が削減できるってところは何分削減できましたかみたいなのが見えやすいし、
メトリックスの話もビジネスロジックに似てると思うんですよね。
例えば、例定金がこれぐらい下がるとビジネス価値にこれぐらい影響がありましたとかっていうところのストーリーまで作れると、
やっぱりただメトリックスを増やすだけじゃなくて、
ken
このメトリックスを注視する必要がありますよね、チームとしてはみたいなところのボトムアップのアプローチもできるし、
それこそやっているメトリックスとビジネスを繋げるストーリーを作ることがバックエンドエンジニアとしてできるよね。
ken
そういう繋げ方はたくさんある中で、私自分の時間は二次の父親として限られている中で、
どこに注力して会社に価値を出していくかっていうのは、
本当に課題発見も課題提供もやっていかなきゃいけないという、
ken
すごい幅広く求められる面白いところだなと思うので、
自分がバックエンドエンジニアだった頃を思い出しながら、気づきながら聞いてましたけど。
ありがとうございます。
ken
いいよね。
Mutsumi
そうですね、すごくビジネスとの接続っていうのは今後の課題のびしろだなというふうに思っていますね。
やっぱり技術でできることが増えていくことが今は楽しさを覚えてはいるけれども、
やっぱりそれがビジネスにどう繋がるか。
Mutsumi
繋がってはいると思うけれどもうまく説明ができないであったりとか、
もしかしたらビジネス視点をより強化すると、
より見なければいけない指標があるかもしれないであったりとか、
見なければいけない、改善しなければいけないところが出てくるかもしれないので、
そういったところを繋ぐであったりとか、
よりビジネス的な優先度を判断するっていったところは、
個人としてはより強化できると、
今まですごく楽しくて広げてきた道具たちが、
より一層今後も活用できるかなというのを思いますね。
そうですね。そこのマインドセットの変化、
ken
やっぱり自分を振り返ってみて早くやっとくとよかったなってすごいあって、
新しい技術をキャッチアップするの楽しいんだけど、
結局それで終わっちゃうと、
ken
もちろんいつかトランジションしていくっていうのがあったからすごいいいなと思うんだけど、
なんか技術のキャッチアップが楽しいで終わっちゃうと、
他の人が作った技術のコンシューマーで終わっちゃうんだよね。
結局他の人が作った技術を追うだけの人生になっちゃうというか、
追うだけのキャリアになっちゃうけど、
やっぱり自分が向き合っているビジネスと価値を繋げてなんぼだし、
そこができれば、やっぱり技術は変わっていくじゃん。
リアクトのRXは終わってみたいなとかさ、
ストーリーボード終わってとかさ、XML終わってとかさ、
ken
で、LLMも来てみたいな。
でもLLMは技術として面白いけど、
それをビジネスと繋げられるプロダクトマネジメント的な側面もしっかりだけど、
ken
バックエンドエンジニアとして繋げられるっていうのはやっぱり、
それは貴重なスキルだと思うんだよ。
背筋が伸びますけど話してて。
Mutsumi
そうですね。ありがとうございます。
ken
なんかこう、レイテンシーが上がっただけで喜んでたらやっぱりダメで、
SLOというかね、サービスレベル、オブジェクティブとかさ、
ビジネスに影響するメトリコを覆う必要があるし。
そんなとこですかね。
ちょっと何回かまた読んで、
会社のプロジェクトの話とか、
なんかコミュニティの運営とかも頑張ってらっしゃるみたいなんで、
そこら辺の話も別途したいなと思うんですけど、
ken
今日はちょっとね、むつびさんのキャリア編ということで、
よう呼びしました。
そんなとこかな。
最後リスナーに向けて言い残したことはあれば。
言い残したことはないかもしれないですね。
むしろ、いつも逆にリスナーとしてすごく楽しんで聞いている、
Mutsumi
このPodcastに出ることができて、
すごく貴重な機会をいただけて嬉しいですっていうのと、
何かしら誰かしらの、
なかなかね、今AIが出てきてエンジニア難しいねって言われているとは思うんですけれども、
その参考になったら、
ちょっとでも参考になったら嬉しいなというふうに感じています。
そうですね。
貴重な経験だしありがとうございます。
Mutsumi
ありがとうございます。
ken
今日はうつみさんをお呼びしました。
ありがとうございました。
Mutsumi
ありがとうございました。
