1. LayerX NOW!
  2. #79 mosaからyoshikiへ:バク..

2024年1本目のLayerXNow!は、バクラク事業部のCTO交代のお知らせ回です。前CTOのmosaさんと新CTOのyoshikiさん、さらにファシリテーターとしてVPoEのmakogaさんの3人に登場頂き、CTO交代の背景、今後の開発体制、品質保証プロセスの確立、意思決定の改善など今後yoshikiさんが目指す開発像について話しました。

▼ 話のハイライト

・それぞれの自己紹介とCTO交代の経緯

・新CTO就任の経緯と抱負

・小規模チームによる顧客起点の開発について

・品質保証プロセスの確立(最近の大きな変化)

▼ カジュアル面談のリンクはこちら

https://jobs.layerx.co.jp/opendoor


▼LayerX Now!とは・・・ LayerXの日常を伝えるPodcast。社員が 交代でホストを務め、LayerXで働く様子を赤裸々にお伝えします。

▼ メディア情報

LayerX採用情報:https://jobs.layerx.co.jp/ LayerX エンジニアブログ:https://tech.layerx.co.jp/ LayerX 公式note:https://note.layerx.co.jp/ CEO福島のnote:https://note.com/fukkyy


00:00
はい、みなさんこんにちは。こんばんは、LayerXのkogaです。LayerX NOW!を始めていきたいと思います。
LayerX NOW!は、組織・文化・プロダクトのセキュララな話を伝えていく番組です。 本日は、バクラク事業部のプロダクト組織からお届けいたします。
今回のテーマは、バクラク事業部のCTOが交代するということで、全CTOのmosaさんと新CTOのyoshikiさんからCTOを交代することの意義、これからの開発体制について色々と話を聞いていきたいと思います。
今日の出演者はですね、私含めて3人ということですね。じゃあまずはですね、それぞれ自己紹介からお願いいたします。じゃあmosaさんお願いします。
はい、こんにちは。mosaです。LayerX NOW!は3回目くらいの出演かな。僕の今のポジション名で言うと、今だと微妙だな。前のポジション名で言うと、バクラク事業部付けのCTOだった。
かつ今はCPUという形になります。全社のCTOがyoshikiさんで、事業部付けのCTOが交代されたみたいな感じになります。yoshikiさんは残りの2つの事業を見ていて、バクラクとしては事業部CTOがいるみたいな形になります。
僕の経歴としては、最初新創生DNAで入って、サーバーエンジニアとして入って、次、GNOSYにフッキーに誘われて移って、そこでサーバーエンジニアとPDMみたいな形をやっていて、転機事業をいくつか立ち上げるみたいな動きをしていて、
で、LayerXを立ち上げて、そこで技術的なところだとか、プロダクト的なところだとかをずっと見ていますっていう形です。本日はよろしくお願いします。
よろしくお願いいたします。それではyoshikiさんも自己紹介をお願いいたします。
中川yoshikiと申します。新しくCTOに就任するってことになって、入社自体は2020年の6月ぐらいから業務委託みたいなものを開始していて、その頃はブロックチェーンの事業をやりつつ、DX事業部っていうのを後に作るんですけど、
そういうDXの事業を社内からやっていきたいみたいなところが、最初の入社してからのプロジェクトだったりしました。この頃から企業のサイルコスタデータをつなげることとか、企業間取引のシェアライフムーブにするにはみたいなDXの事業を話していました。
今小川さんからちょっと硬いっていうのが来たので、柔らかい話します。スマートレアXインボイスっていう爆楽の前身になるプロダクトを開発し始めて、そこから最初は請求書の受け取りみたいな事業のドメインをみんなで開発しながら学んでいったという形になります。
昨年からエネブリングチームっていう横串でプロダクトを出していろいろ物を作るエンジニアの組織のチームに入って、そこにいながらも2人アラインドチームで一緒にプロダクトを作るとか機能を開発するみたいなことを続けてきました。
今年からCTOのところになって、もう少し自分のできるところを広げていきたいなというのが今日一緒に話しできればかなというふうに思います。
03:10
ありがとうございます。お二人からいろいろ今日はお話聞いていきたいと思います。
今日ファシリテーターを務めるのは私小川になります。私は2023年4月に入社しまして、7月から爆楽事業部のVPOE、VP of Engineeringをやっております。
その前までは、ボヤージョとかカルタっていう会社で11年半くらいCTOをやってきて、いろんなCTOいると思うんですけど、特に私は組織面がすごい好きでやってきたっていうのもあって、
0xでバックラップのVPOEという形で組織面をやっていこうかなというふうには思っております。
私は直続のエンジニアリングオフィスっていうチームを持って、そこのチームのミッションは人とチームの観点からエンジニアリング組織のパフォーマンスを最大化するっていう
掲げておりまして、重要テーマを3つとして仲間を増やす、仲間の熱量を上げ、組織の熱伝導率を高める、仲間の爆速成長をサポートするということをやっていきたいというふうに思っております。
今日はこの3人でやっていきたいと思います。
はい、じゃあまずはですね、どうしようかな。何から話しましょうかね、MOSAさん。
じゃあまずはMOSAさんからCTOをなぜ交代することにしたのか。結構こだわり持ってMOSAさんCTOをやってたわけじゃないですか。
なぜ交代することにしたのかっていうのをちょっと聞かせてもらっていいですか?
もう早速本題ですね。はい、じゃあ話します。
僕はこれまでCTO兼CPUというポジションでプロダクト組織、開発組織全体を見ていましたと。
それは結構ある種いいこともたくさんあったなと思っていて、プロダクトっていう文脈で全部見れるっていうところで、
ビズサイド、プロダクト届けるサイドとプロダクト作るサイドっていうふうにすごい分かりやすく組織を作れたっていうのもあるし、
あと結構意思決定として何をどういう順番で開発するのみたいなところで、
どうしても工数管みたいなところとかエンジニアリソースみたいなところと切り離せないので、
プロダクトを作るっていう意味だとそこの意思決定が一緒くたにできたっていうのは内外としてもやりやすかったんじゃないかなと思ってます。
ただ結構組織だとかプロダクト数が拡大していく中で、プロダクト数ももう6個だとかになっていて、
開発組織ももう50名だとかそういうレベルになっていく中で、開発組織って言ってもデザイナーさんだとかQAさんだとか、
いろいろ合わせてですけど、そうなった中でじゃあ簡単に言うとお前技術に責任持ってんのってなると、
うーん難しくなってきたなっていうところはあって、
僕の動きって結構新規プロダクトどんどん立ち上げていく、
コードを実際書いてユーザーヒアリングして設計してコードを書いて立ち上げるみたいな動きがメインになってるんですけど、
結構その中で昔は新しい技術的仕組みを取り入れてやるみたいなところもできてたんですけど、
06:06
最近は自分がやってるかっていうと結構先ほど吉木さんが話してたエネベリングチームに、
なんかお任せみたいなところも増えてきていて、
なんか自分で技術っていう文脈でみんなを引き入れてるのかだとか、
新しい遺伝子を取り入れられてるのかみたいなのとか、
自分としてもプロダクトっていうところに向き合う時間が増えていて、
技術っていう単体に純粋に向き合うことも減っちゃったなっていうのがあって、
そうなった中でなんかみんなに技術って面で背中をもっと見せられる人の方が、
なんかいいんじゃねえかっていうのは結構元々思ってたんですね。
で、その中で吉木さんだとかに、
ちょっと何ヶ月か前にドスカネシ行ってよっていうのを相談して考えますみたいなところの中で、
今回本人からやりたいですって言っていただいたので、
よっしゃーって思ったみたいなところです。
ありがとうございます。
そうですね、なぜ吉木さんだったかっていうのはちょっとまた後ほど話します。
はい、ありがとうございます。
そうですね、私もすごい入ってきて思ったのは、
やっぱりスピードを出すときに意思決定のスピードってすごい大事だと思うんですよね。
そこをすごいMOSAさんがしっかり意思決定のスピードを出してやっていたっていうところは、
印象的だったなというふうに思いますね。
吉木さんはどうですか?なんかMOSAさんがCTO、CPUを兼務してて、
なんか良かったところとか気になってたところとかありましたか?
やっぱりどういう順までどのように作るかみたいなスピーディーに意思決定できる人が
一人の頭に、意思決定者の中にまとまってたっていうのは
めちゃくちゃ良かったんじゃないかなって振り返って思いますかね。
で、我々みたいなコンパウンドみたいな複数のマルチプロダクトを作って
それをつなげるみたいなところをスピーディーに行えたっていうのは、
やっぱCTOとCPUが兼務してた、そのイメージがすごく出てたのかなっていうのは
振り返って思うかなと思います。
そうですよね、ほんとそこはそう思いますね。
でもその後はあれですよね、CTOとしてのMOSAさんと
あとはストリームアラインドチームを支えるプロダクト横断系をやるところの
VPであるSuguruさんもいたと思うんですけど、そことの積み分けっていうところも
あったかと思うんですが、その辺はいかがですか?
これは僕が話したほうがいいですか?
はい、そうですね。今回CTOをお題するにあたって
なんでSuguruさんじゃなくてYOSHIKIさんかっていうところが出てきて
そこは僕は結構いい話になるというか
やっぱ彼にやってほしかったっていうのがすごいあって
Suguruさんもちろんめちゃくちゃいいエンジニアですし
尊敬するところも多いですと。
RAREXの中での動き方としては結構エネーブリングっていうところに重心を置いていて
ストリームアラインド、実際にフィーチャーをプロダクトとして開発して
価値を最大化するみたいなところで言うと
そういう動き方よりは本当に技術にフォーカスっていうところがメインになってて
09:00
YOSHIKIさんは両方やってるんですよね。
全部やれる人で、全部そういう動きをしてる。
もともとストリームアラインドとしてめっちゃプロダクト立ち上げる中で
技術的なところをどんどん良くしていって
今はエネーブリングとある種、エネーブリング主軸でプロダクト作るみたいな動きをしていて
両方の文脈が分かっていて、両方のことを理解して動き続けられてるっていうのが本当に大きいです。
彼って実は、当時レイアックスインボイスっていう名前のプロダクトあったんですけど
そこの行動、実は一行目、一番最初にコミットしたのってYOSHIKIさんで
そのフレームを作った人なんですね。サーバーサイドも、確かフロントエンドもかな。
そういうことができる人がCTOになれるっていうのはなんだろうな
ある種最初からやってくれてる人がCTOになるっていうのは
僕はすごい嬉しいことだと思うし
これからも彼については、技術って面でやっぱ行動を書いてほしいなっていう強い思いもあります。
そんな形です。
そうですよね。すごいバクラク、これだけプロダクトが増えて大きくなったときの
一行目をYOSHIKIさんが書いてたっていう話はすごいいい話だなっていうのも思いますね。
覚えてますか?YOSHIKIさん、その一行目の行動。
一行目、そうですね。とりあえず、当時いた342のエンジニアで
こういう形の開発でもう進めちゃおうかみたいな話をしたぐらいの記憶しかない。
2週にざっと書いて、もうこれでみたいな。
そこから開発した後は結構プログラマーにプルリクを止めるなっていうのを結構
みんなで掛けたかなっていう気がしていますね。
やっぱり初期なので、もう何回壊してもいいと思っていたので
プルリク止めずにどんどんマージしていこうっていうのは
初期からFPとか思ってたかなっていうのは思ってますね。
あれ最高でしたね。あれで多分スピード3倍くらいになった気がする。
めちゃくちゃ良かった、あのカルチャー作ったのは。
でもそのカルチャー本当に築いてくれたYOSHIKIさんだからこそですね
本当に社内でMOSAさんから次のCTOはYOSHIKIさんですって時も
社内がめちゃめちゃこう盛り上がりましたもんね。
やっぱね、YOSHIKIの兄貴はね、前々から社内でね
MVP制度とかあったんですけど、確かだいぶ初期からMVPを獲得するくらい
みんなが評価している人だったかなと思います。
ありがとうございます。じゃあそうですね、MOSAさんからは
そのような形でYOSHIKIさんに是非という話があったんですが
それを受けてYOSHIKIさんはどういう思いで
じゃあやるぞっていう形になったんでしょうか?
もうですね、最初話をMOSAさんからもらってから
自分が返信するまでって結構長い時間がかかってしまっていて
それは何でかっていうと、やっぱり責任の重さみたいなのが非常に大きいと思いますし
あとはすごいエンジニアがいっぱいいる中で
MOSAさんは含めSUGURUさんがいますとか
あとメンバーの中に技術的に強いメンバーがいる中で
自分が果たす役割って何ができるんだろうみたいなのは
12:03
とっても考えたし、いろんなロールモデルみたいなものがあるのかな
っていうのをちょっと探してしまったんですけど
結局自分がやりたいとか自分にフィットするものっていうのは
なかなか思い浮かばなかったから
なかなか返信できなかったっていう部分があったんですけど
自分の中で1個答えられたのは
先ほどコードを書いてほしいみたいな部分があったんですけど
やっぱり今までMOSAさんが
例えば取締役ですとかCTOですとかCPOですとか
言いながらずっとコードを書いてたっていうのは
めちゃくちゃ大きかったかなと思って
これは他の求職者の方と話したときとかも
どんな組織あるんですかみたいなすごい新鮮に受け取られて
自分もこういう組織で働きたいなって客観的に見て思ったので
自分がもしそういう職に就くのであれば
ロールとか関係なくちゃんとコードを書いて機能を作って
あの組織に貢献したいなっていうのが思ってたので
やりたいですっていうところをそこを含めて返信したのが
自分としての意思決定の部分だったかなというふうに思いますね
この返信をしてからは本当に1ヶ月かかんないぐらいで
トントン話が進んでいて
会社のスピード感みたいなのは
今のフェーズになってもすごい驚くなみたいなのは
めちゃくちゃありまして
多分裏で動いてくださったら小川さんとか
SuguruさんやMOSAさんはいると思うんですけど
そのスピード感は自分が就任するときも
こんだけ早かったから
これは今後も維持したい部分かなっていうのは
とても思いましたね
やっぱり吉木さんにという話を聞いたときに
やっぱり吉木さんの良さが生きるためにはどうしたらいいんだ
っていうのをすごくやっぱりMOSAさんSuguruさんと話しましたね
やっぱりMOSAさんもすごい強い思いがありましたもんね
そうですね
その時もあれですね
当時からCTを交代したいなって話を
Suguruさんだとか
小川さんとか話したときに
やっぱり吉木さんだねっていう話は
みんなマジで
ゆっくり吉木さんから言ってたら
それそれみたいな感じで
みんな当然同意してたというか
そういうのもあって
彼の動きとしてやっぱり
ずっと現場にコミットして
偉そうに振る舞うとかじゃなくて
現場に僕は全てのエッセンスが詰まってるし
課題感みたいなところがたくさん転がっていると思うので
そこをずっとやっていってほしいなと思っています
そうですね
一般的なCTOの役割というのではなく
やっぱり幕楽なりのフォーメーションだったりとか
吉木さんなりのCTOっていうのをすごい考えて
今回いい方向に進めたっていうのは
僕もすごい嬉しいなと思ってますね
吉木さんじゃあ
もう少し意気込み的なものがあれば
意気込み
話してもいいですか
15:00
そうですね
やっぱりミッションとして持ったのは
幕楽の事業部全体で
開発から顧客に最後デリバリーして
またそこから開通のプロセス回すみたいな
オペレーションのマネージメントみたいな部分を
別途テクノロジーできる部分があれば
そこを取り組みたいなっていうのが
一つ大きなところであって
結局CTOだからっていうよりかは
ソフトウェア開発のエキスパートとして
ここってもっとこういうことができると
全体のフロー効率上げれるとか
そういう視点で取り組みたいな
っていうのは思っています
あとはテクノロジーがすごい
もう完全な魔法だったことはないと思うんで
完璧じゃないにしても
トレードオフからベターなものを
ちゃんと選択していくっていう部分
別途テクノロジーしたいなっていうのが
一つあります
もう一つは開発チーム横断での
テクノロジーのマネージメントみたいなのがあります
ここに関しては
Suguruさんとかエネビリングチームとか
プラットフォームチームのメンバーがいるので
そこのメンバーとも話しつつ
ただやっぱりストリームアラインドチームからの要望に
どれだけ応えられるかっていうのを
横串でアラインしていけたらかなというふうに思っています
その2点が今の自分のミッションかなというふうに思っています
逆にやることやらないことみたいな話を
死に前にいろいろ話せたのは
すごい良かったなと思っていて
やっぱりプロダクトの最後の意思開発の
決定の部分はMOSAさんが今後もやっていくよというところと
あとはやっぱり組織的な部分とか
EMGだったりCOGAさんだったりとかっていうのが
サポートしてくれるという部分があったので
ここら辺はすごく話せて
自分として2が下りたというか
もっとこういうことをやろうみたいなところに
みんなのフォーカスが揃ってたのは
すごい良かったなというのは思いますね
ありがとうございます
MOSAさんどうですか今の意気込みを聞いて
最高ですね
本当に最初
ヨスキーさんかなってなった時も
扇動があるし多すぎることっていうのは
みんなリスクとして捉えていて
誰に何聞いてって言うとあれだけど
最終的に誰がケツ持ってるのみたいなところが
ふわっとすると
大体組織って変な方向に向いていくので
ここで誰が何責任持っていて
ここでそれぞれがやることやらないこと何
っていうところをバシッと決めたっていうのは
良かったかなと思ってますし
それが実際にどうなっていくか問われるのは
今後だと思うんですけれども
まず骨格ができたっていうところは
大きかったのかなと思います
本当その通りですね
ただ今回のフォーメーション
僕的には世の中に参考にできるところがないんで
本当に自分たちで考えていかなきゃいけない
フォーメーションだなっていうのは思うので
それはすごいやりがいのあるチャレンジもありながら
すごい頑張っていかなきゃいけないところだなとも
思ってはいますね
じゃあ次はですね
意気込みを聞いたところで
実際今爆落のプロダクト組織や開発体制みたいなものが
どういう状態になっていて
18:00
ここ1年ぐらいでどういうふうな取り組みをやって
これから未来どうしていきたいのかみたいな
そういう話もちょっとできればなと思うんですが
じゃあどうしましょうかね
吉木さんにお願いしてもいいですか
はい
基本的に今プロダクトがいくつあるんだろう
4つ5つあるんですけど
ストリームアライドチームに
必要なプロダクトの情報をちゃんと集約して
必要なドメインみたいなのを
チームでもって開発を進めていて
1チームが4人とかで開発している
モバイルで分けているチームとかも
あったりはするんですけど
かなりスモールなチームが止まられているな
っていうのがあって
あとは特色としてあるのは
チームが作成からリリース
その後どういうふうに使われているかみたいな部分の
一連のオーナーシップを持っているみたいなのが
いいなというふうに思っていて
これは開発のすごい初期の段階から
保たれている部分でいいなと思っている点です
2、3年前エンジニアしかいなかったチームであっても
顧客の方に実際にヒアリングエンジニアが
行って開発してたりとかっていうのが
まだ保たれているなっていうのがあって
MOSAさんも未だにヒアリングみたいなのを
結構な本質をこなしてやってたりするので
これはすごく小さなチームに閉じて
ちゃんとドメインを集約して
要望を聞いて開発できているなっていうのが
今かなというふうに思います
そうですね
コンパクトなチーム 小さなチームっていうところは
本当に特徴の一つですし
これがやっぱり爆速開発につながっていると思います
やっぱりオーナーシップを持って
顧客の方にまで価値を踏み出すっていうところまで
あるからこそのやっぱりアウトカムの爆速
っていうのが生まれているかなと思いますね
僕はちょっとMOSAさんに
例えばこれぐらいの組織規模どう?って言ったときに
小川さん 多すぎますって言われたことがある
それじゃ普通の会社になっちゃうじゃないですか
みたいに言われました
懐かしいですね
MOSAさんの中で今計画の中でも
だいたいフィットした感じで出せるようになったかな
と思いますが
計画見て小川さん これ違います
そういうのも試行錯誤しながらですね
爆落なりの小さなチームで大きな仕事をするのには
どうしたらいいのかみたいなところを
もっと僕も考えていきたいなというふうに思いますね
じゃあもう少し
しつきさんの方から今年取り組んできたこととかも
教えてもらっていいですか
そうですね
今2023年とかで変わったなっていうところ
やっぱ品質保証のプロセスみたいなのが
ある程度確立できてきたみたいなのが
2023年で最も大きかったなっていう部分かなと思っていて
どんなテストとかバグを減らそうっていう以上に
適切に使われているとかっていうのを
PDMだったりエンジンだったりQAだったり
開発に携わる人がみんな語ってるっていうのが
すごくいいなと思っていて
QAチームの人もそういう観点でプロダクトを育てて
21:02
品質保証のエキスパートでもあるんですけど
ドメインの理解みたいなのをちゃんと
チーム一丸となってできてるみたいなのは
2023年で一番変わったなっていうし
とてもいいなっていうふうに思っている点だったりします
あとはスモールなチームな分
エンジニアはバックエンドもフロントエンドも
一機能に関して担当するみたいなケース
非常に多いんですけど
そういう時にこの機能のオーナーシップを持って
こういうふうに使ってもらえるように作りましたとか
そういうものをちゃんと持っててるっていうのは
とてもいいなと思っていて
事業部全体でレビュー会で
プリント伝を最後に1週間に1回とかやってるんですけど
技術でよって結局何が達成されたかとか
どういう機能を提供できるようになったみたいなのを
エンジニアがちゃんといきいきと
共有できてるっていうのは
めちゃくちゃいいなって思ってて
これもまだまだ今後も続けていきたいところかな
というふうに思っています
ありがとうございます
品質のあたりはそうですね
やっぱりいいメンバーが入ったっていうところも
すごく大きいと思いますし
それだけではなくやっぱり
多くのお客様に使われるようになったっていうところですかね
そこから来る品質性の意識っていうのも
すごく変わったのかなと思うんですけど
まささんそのあたりいかがですか
品質はフェーズ変わったかありますね
プロダクトによってフェーズは違うんですけれども
そうですね
もうおととしの1月からリリースして
3年近く経つプロダクトになってるのと
あとお客層も広がっている
最初はもうIT系だとか都内みたいなところだったのが
今だとかなり景色が変わってるっていうところもあって
IT
そういうお客層が変わっても求められる
品質とかが多く変わるわけじゃないんですけど
やっぱ機能の性質とかが変わってくるだとか
パフォーマンスの要件だとか
そうですね
規模 データの規模が変われば全然
APIの内部の処理とか変わってくるので
そういった性質が変わったっていうところは
特に大きいのかなと思っています
そうですね 各チームのOKR
チームOKRの中にも品質っていう言葉が
今年は結構増えたかなっていうのはすごく思いましたね
ありがとうございます
そうですね 先ほどちょっと話が出たんですけど
これ収録が2023年の年末に撮っていて
今年っていう言葉が
23年なのか20年なのかちょっと分かりづらいというのが
あったかと思ったんですが
すみません 意識した
3年前ですね すみません
おととしの1月だけど3年前のリリースです すみません
これはちょっとこういう収録あるあるかなと思いますが
ということですね
そうする3年ちょっと経った中で
今6プロダクトが出ていて
これからも新しいプロダクトをどんどん出していく予定が
ありですね
ただその一つ一つのプロダクトをリリースするだけじゃなく
24:00
プロダクト間の連携もですね
より密になめらかにやっていくっていうことをですね
今試行して進めていますが
この辺りの新しいプロダクトを生み出すとか連携とか
この辺りについては何かお話できるとかありますか
吉木さんいかがでしょうか
そうですね 何かこう
これも2023年の話になるんですけど
ある程度パターンとか型みたいなのは
何かやってる人のメンバーの間では
何か少しずつできてきたのかな
みたいなのは思っていて
一番テクニカルに大きい部分でいくと
やっぱりグローバルに爆落のグローバルで利用できるスペース
みたいなのがちゃんと確保されて
これによって実装上の制約みたいなのを
少し減らすことができたっていうのが
なんか2023年大きかったなというふうに思っていて
あとはただそうは言っても
使用としてどう提供するかっていうのは
毎回ケースバイケースで
すごい正解あるわけない正解がないものに対して
常に逆に当てながら決めているっていうのが
今なのかなと思っていて
そこはなかなか簡単に技術で解決できる部分ではないし
正解もないので
引き続き取り組むべきところかなっていうところかなと思っていて
もう一つあるのはやっぱり
機能を開発していったその先で
運用していくっていう部分の課題で
どこにコンテキストというか境界線を引いて
開発チームを組んでいくかみたいなのは
まだまだ手探りなところがあって
これも結局正解がなくって
マイクロサービスでいう構造的な破壊みたいなのは
現地ある程度コードベースの上でできるんですけど
意味的な破壊みたいな
暗黙的な挙動が変わりましたとか
仕様が少し変わったんですよね
データの意味が変わりました
性質が変わったみたいな
やっぱりどうやって連携していくかっていうのは
まだまだ課題かなというふうに思っている部分ですか
そうですね
最近本当にスペックの書き方だったりとか
連携のレビューの仕方だったりとか
そういったところも少しずつ工夫をしていく中で
まだまだ正解があるというか
多分正解はないんでしょうけど
ここは本当に面白いところ
難しくもあり面白いところだなと思います
エンジニアリングの本当に面白いところだなというふうに
僕も見てて感じてますね
ということでだいぶ時間も過ぎてきましたね
じゃあ次のトピックぐらいで最後になるのかな
じゃあゆきさん今後ですね
新しくCTOになってからの
これからの可能性みたいなものとか
こうしていきたいみたいなところも
もう少し教えてもらってもいいですか
今爆落は開発始めて3年と少し経っているんですけど
サーフ組織としてもまだまだ変わっていく途中で
やれる領域みたいなのが
どんどん社内の中でも広がっているし
社外を見てプロダクトを作っていく
っていうイメージでも広がっていくので
ここはやれる領域みたいなのが
めちゃくちゃ広くあるかなというふうに思っているのと
爆落のすごい事業部としてのいい特徴は
やっぱり顧客からのフィードバック
本当にもらえているみたいな部分
多分それがストックされていて
27:02
さらにそれをどういうふうに
自分たちの進化につなげるかみたいなのも
やっぱり実際の声を聞きながら
解決できていっている組織かなと思うので
ここはエンジニアとして入って
いろんな生の声を聞いて
自分の未熟力でどういうふうに変えていけるか
っていうのはめちゃくちゃ
ワクワクする環境かなというふうに思いますね
そうですよね
12月 11月ってすごいアドベントカレンダーを
たくさん発信していると思うんですが
今年入社したエンジニアの何人かも
やっぱり顧客の近いところで開発できる
っていうのを求めて入ってきて
実際本当にめちゃめちゃ近いところで開発できましたとか
実際に広島まで出張して
お客様のところの業務を見てきましたとか
そういう話があって
そこがすごくSaaSの面白いところだな
っていうのはみんな言ってますよね
ここはぜひ継続していきたいと思いますし
これから本当に人が増えていく中で
オンボーディングの過程で
こういう顧客の声っていうところと
実際に物を作る人間が触れ合う機会っていうのを
どう増やしていくかっていうのは
一緒に考えていきたいなと僕も思ってます
やっぱり直接的なフィードバック
すごくありがたいですね
ありがとうございます
他にはいかがですか
可能性こうしていきたいというところ
そうですね
去年自分の中で反省があるとしたら
エンジニアの意思決定みたいな部分で
開発チームにとっても
自分にとっても課題かなというふうに思っていて
やっぱりどういう風なアーキテクチャを取っていくかとか
あとはこういう変更をやりたいみたいなところを
ちゃんと意思決定できる機会がたくさんあって
そこは成長の余地でもあって
やっぱりここを決めきっていかないといけないのかな
というのが自分の課題として残っているかなというふうに思って
多分ここは意思決定者とかステークホルダーいると思うんですけど
やっぱりそこに対話をせずに決めるっていうことはできないと思うので
やっぱりここをある程度コスト払ってても
ちゃんと対話して決めていくみたいなところを
実行していきたいなというふうに思っていて
あとは決めたらレイアクスらしく
連絡と実行とかっていうのを分けずに
ちゃんと最後までやり切るみたいなところを
2024年取り組みたいかなというふうに思っています
そうですね ここは今年は特にフロントエンドの
ライブラリというか大きなバージョンアップのときに
どうするかみたいなところで
なかなかチームでも決めづらかったり
どうしてそうしていくのかっていう話もありましたよね
そうですね やっぱ難しいですね
何がって感じだけど
なんかコンパウンドっていう文脈でも
すごい難しいなっていうのは
吉木さんもお話ししていただいた通りで
意思決定みたいなところ
フロントエンドだと最近ギルドみたいなところも作って
意思決定の軸みたいなのどうしていくかみたいな
これまでだとワーキンググループみたいな言い方で
ちょっと合議で決めきるみたいなところまで
30:04
なかなかいきづらかったみたいなところが
意思を持ってここで決めるんだみたいなところが
出てきたのかなと思っています
そうですね そういうふうに
プロダクト横断したチーム横断した意思決定だったりとか
本当に戦略1年で終わらないような
長い時間をかけた意思決定みたいなところを
本当にやっぱり現場の人たちが
意思を持って決めていけるっていうところを
どうやって作っていくのかっていうのは
文化だったり体制だったり
すごく重要なところかなと思います
やっぱり吉木さんがCTOになって
CTOが決めるじゃなくて
現場から意思を持って進めていくっていうところを
やっていきたいというのは吉木さんからめちゃめちゃ感じるので
それをどうやって実現するかっていうのは
本当にこれから楽しみだなというふうに思ってますね
そうですね
あとは
マルチプロダクトのSaaSだけではなく
コンパウンドっていうところも特徴的かもしれませんが
少しもう話も出てきてますが
もう少しコンパウンドならではの大変さとか
面白さみたいなところって何かありますかね
自分が一番投資に入って考えたのは
機関システムとかERPパッケージとか
あとは単独で動くSaaSとか
あとは社内DXみたいないろんな変遷を経て
今のコンパウンド化みたいなところがあるのかなという
個人的に思っていて
やっぱりバラバラになったものの揺り戻しみたいなのは
一定あるのかなと思っていますと
爆落の初期の爆落というか
React Symbolsも作る前のDX事業部で最初考えたことって
バラバラになった社内データのサイロ化を
どうやってつなげるみたいなことを
案としてらっしゃったりもしてたんですけど
その頃から一定の課題感としてあって
爆落としてはやっぱりビジネスドメインどんどん広げていって
交通化した我々のデータを持って業務つなぐみたいなことが
できる立ち位置にあるので
そこは普通としてどこに境界線を持たせて作って
どういうチームで作って
そのつながりを作ってちゃんと価値につなげる
みたいなところができるのは
Reactの魅力なのかなというふうに思っていて
普通のSaaSともちょっと違う点で
魅力かなと思っています
あとはエンジニアリングはやっぱり
アーキテクチャみたいなものを考えながら作っていくので
一方的に機能を掛け合わせて価値を作るという部分は
ぜひ試行錯誤しながら
Reactできるといいなというふうに思っています
ありがとうございます
本当そうですよね
共通化したデータを用いて業務をちゃんと滑らかにつないでいくって
これ本当にお客様がすごく求めているものなんですよね
そうですね本当に
もささんもあれですよね
ヒアリングとか行くとそういう声よく聞きますよね
そうですね
コンパウンドってすいません
当たり前より使ってきた言葉なんですけど
要はマルチプロダクトと単純に複数のプロダクトを並べる
それぞれ並べるじゃなくて
33:01
連携性こそがプロダクトだくらいの思想を持っている
業務フローってやっぱりサイロ化すると
本当にやりづらいというか
現場の課題ってやっぱりデータと業務がサイロ化している
例えば印刷して経理に持っていく
せっかく倫理とかは電子化されているのに
それを印刷して経理に
なんか領収書とほち止めしたり
ノリ付けして持っていくみたいなのが平気で
現場だと起きているので
そうじゃないよねと
臨機でやった内容がそのまま経理の画面に入っていく
みたいなのが理想的な体験だと思っているので
この連携性こそがプロダクトだという覚悟でやってますね
ただやっぱり作るのって本当に難しくて
3つくらい課題があるなと思っていて
1個目は仕様を作る課題
めちゃくちゃ連携性って一口に言っても
ここの変更がこっちに伝播してみたいなところ
体験設計するのってすごい難しいなっていう
1点目の課題と
2点目がアーキテクチャの課題
吉木さんが話したように
どういう境界線を作るのかみたいなとか
どこにどうデータを持つと
一番循環参照しないだとか
アーキテクチャがスキーするのかみたいな
正直どうやっても循環参照するじゃん
っていう思う時もあるんだけど
そこをうまくグローバルなスペースに移すみたいな
要はリソースカットのマイクロサービスにするだとか
そういった動きで何度か避けていくみたいな話とか
3点目は組織の難しさ
横断チームどうやってやるねみたいな
プロダクトの掛け合わせもどんどん増えていくので
それごとに横断チーム作ってると
キリがないみたいなところがあるので
そこの組織設計
公明の法則的にもどうしていくかみたいな
ところの3つの課題が難しいし
面白くてみんなが入社してほしいな
入社すると楽しめるところかなと思っております
ありがとうございます
宣伝もありがとうございます
ということでまだまだ聞きたいことはたくさんあるんですが
そろそろちょっといいお時間になってきたかな
というふうに思っております
最後に宣伝をさせていただきたいなと思うんですけれども
2月の15日と16日に
Developers Summit 2024
通称Dev Summitが開催されるんですが
そこで新CTOの吉木さんが登壇しますので
ぜひこれを聞いている皆さん
現地で参加もしくはオンラインでの視聴を
していただけると嬉しいなというふうに思います
今日も最後になりますが
こんな人と働きたいっていうのも
ぜひ吉木さんともささんから
一言ずついただければと思いますが
そうですね
やっぱり今のフェーズ
まだまだ変わっていく部分ではあるし
外から見たLinuxがどう見えているか分からないですけど
やっぱり社内の課題みたいなのもたくさんあるので
そこを一緒に解いていけるエンジニアの人を
募集していますし
あとはやっぱりやれる領域
フロントエンドからバックエンドまで
いろんなものに自分たちで入っていける
36:01
あとは業務をこういうふうに
効率化できるみたいなところも
領域としてあるので
そういうことに興味のあるエンジニアの人は
ぜひ一緒に開発したいなというふうに思いますね
ありがとうございます
ではもとさんもお願いします
そうですね
これから爆落ってプロダクト
どんどん進化していくので
機能数
プロダクト数もそうですし
機能数 連携数もどんどん増えていく
お客様の相談とかも変わっていくし
性質が変わっていく中で
そういう変化を楽しめる人っていうのは
いいのかなと思っています
なんか自分に向かってるっていうよりは
その事業そのものに向かって
変化していく事業を乗り越えるぞ
楽しんで
さらに上を目というか
さらにそこを伸ばしていきたい
その中で自分も成長していきたい
っていう方が
とってもいいかなと思っています
はい ありがとうございます
そのように私たちは
全方位で採用積極募集中でございますので
これを聞いて気になった方は
ぜひカジュアル面談等に
応募いただけると
嬉しいなというふうには思います
はい ということですね
今回はですね ここで終了とさせていただきます
じゃあ よしきさん もうささん ありがとうございました
ありがとうございました
ありがとうございました
37:18

コメント

スクロール