00:00
株式会社株区スタイルの後藤秀典です。この番組では、エンジニアリングチームで起きている問題について、技術、組織、ビジネスといった複数の観点で深掘りし、問題の正体へアプローチしていきます。
今回のテーマは、小さなエンジニア組織で開発者体験の追求が必要か問題です。 開発者の体験って当然良い方が良いに決まってるんですけれども、それをやるにもコストがかかりますよね。
小さなエンジニア組織で、どれくらい開発者体験の向上、もしくはさらに追求していくようなことをやるべきなのか、というのは結構エンジニアリングマネージャーとして悩む問題なんじゃないかなと思っております。
今回はゲストに、前回に続いてmatsuri technologies エンジニアリングマネージャーの花田さとるさんにお越しいただきます。
前回のお話でもあったんですが、5つのプロダクトを9人という小さな開発チームで開発しているというところで、その中で強いオーナーシップを持っていらっしゃるので、オーナーシップを持っていれば開発者としても一定のチャレンジができて成長もできるということだと思うんですが、
それだけで開発者は嬉しいんだろうか、というところについて色々今日は聞いていきたいなと思っています。
エンジニアリングマネージャーの問題集。では本日のゲストをご紹介します。matsuri technologies エンジニアリングマネージャーの花田さとるさんです。花田さん一言自己紹介お願いします。
はい。matsuri technologies 株式会社でエンジニアリングマネージャーをやっております。花田さとると申します。
はい。前回はmatsuri technologies さんの事業とか、事業に関連するエンジニアリングのやり方というか、そういうところのお話を結構伺ったので、今回はよりそういったやり方の中で花田さんがどんな風に開発者をマネージメントしているのかというところを聞いてみたいなと思っております。
で、matsuri technologies さんって今9名ですかね、というところで開発をされているということなんですが、さすがにやっぱり事業のスケールというか、そういうところも検討されていらっしゃると思いますし、これは当然のこととしてなんですけれども、その中でやっぱり採用とかそういうことも普通にやっていらっしゃると思います。
で、このmatsuri technologies さんでというか、花田さんがどんな風に採用に関わっているのかというところを簡単に教えていただけますか。
はい。採用自体、前からやってた採用というのは基本的にはリファラル採用ということだったんですけど、1年ほど前からリファラルに限定しない媒体を使った採用というのを始めました。
当初はグリーンさんだったりファインティーさんだったりという形で、今はこの2つがメインでやってます。
主にどのようにやっているかってなると、やはり1つはいいねの送付だったりスカウトの送付というところがメインで、ここら辺は基本的にいろいろと条件に合う方をピックアップしていただいて、
03:17
スカウトを本当にチームに合うかとか、求めているスキルかとか、もしくは文化がマッチしそうかというところを見て、私がこの人にスカウトを送りましょうというところを決定していって、実際に後はマッチしてご返信いただけたらカジュアル面談だったりとか、そして技術面談だったりというところに進んでいくって感じですね。
なるほど、今はそういった採用媒体を使っているってことだと思います。リファラルの時は面接とか当然やると思いますけれども、そこまでリソースかけなくてもできてたのかなっていう気がするんですが、一方で採用媒体使ってスカウトを送っていくとかになってくると一定リソースが必要かなと思うんですよね。
先ほどのお話ですと、羽田さんが実際にご自分で送られたりっていうところだと思うんですが、これ人事の人もある程度やって、羽田さんがやるっていうのか、それともどれくらいの割合でここをやられてるんですかね。
そうですね。ピックアップっていうところに関しては人事というよりは外部の方、カラットさんっていう会社さんがかなりサポートしてくださって、その方々と一緒に協力して求人票の改善だったりとか、実際にどういう文面でスカウトを送るかっていうところをやってますね。
私が実際にやるところっていうのは判断だったりっていうところだったり、もしくは方向性っていうところをメインにやってますね。
なるほど。それってまつりテクノロジーズさんでは一般的な、他の職種でも同じようなやり方をされてるんですか。
他の職種の場合はまたちょっと把握はしてないんですけど、カラットさんに協力していただいてはいないっていう状況だと把握しております。
なるほど。そのやり方っていうのは羽田さんがこういうふうにやろうみたいに提案してやってるような感じなんですかね。
一番最初、カラットさんは確か投資元の方からご紹介していただいて、実際にこういう感じで。
私も人事の人間も開発者をどうやって採用するかっていうところについて全く知らなくて、実際に友達付に採用するということしか知らなかったので、
そこら辺の知識がある方だったり、実際にどういう感じでやっていけばいいかっていう経験、体験だったりシステムだったり組織を作られてる方にお願いしようということはそのタイミングで決まりましたね。
そうですね。結構もうエンジニアの採用ってすごく一般的に難しくなってきていますし、
なんだかの知見がある方っていう人にお手伝っていただいて、一定体系的なやり方をしていった方が効率よくいい方を取っていける体制っていうのが作れますよね。
06:04
そういうことをやっていかないとどの会社も厳しいのかなという感触は持っております。
じゃあそういう中で、でも花田さんが一定人事に任せるとかではなくて、エンジニア採用に関してはご自分で判断みたいなところも入って、
割と早いフェーズからその判断みたいなところも入ってやってらっしゃると思うんですよね。
それって花田さん自身が面接のプロセスの中で、ここは自分で入った方がいいとか、そういう考えのもとにやってらっしゃるんですかね。
それともカラットさんでしたっけ、カラーのアドバイスのもとにそういうふうにやってるとか。
まず一番最初に私が採用活動を頑張るっていうことが決まった、やっていくぞってなったタイミングで、
採用活動って何するのって分からなかったものですので、実際に自分がカジュアルメンダーを受けてみようだったり、採用試験を受けてみようっていうことをまずやりました。
そこで分かったのは、単純にエンジニアじゃないと話が盛り上がらないし、何やってるかよく分からないから、
最初からある程度エンジニアだったり、EMまたCTOっていうポジションの人が最初からアプローチした方がいいですよねっていうことが分かって、
そこから私がどんどんやっていきますっていう感じになりましたね。
なるほどね、そこめちゃくちゃ分かりますね。
エンジニアを採用するときに、うちの会社なんかでもカジュアル面談をエンジニアじゃない部署の人が甘えてっていう部分もあるんですけれども、やってもらったりしてるんですけれども、
会社としてのやってることだったり、表面的なエンジニアリングのこういう制度がありますよとか、そういうのは説明できるんですけれども、
やっぱり実際に現場で戦ってる問題の難しさのニュアンスだったり、面白さだったりだとか、そういうところを熱量を持って伝えるみたいなところって、
これはやっぱりやってる人間じゃないとできないところはありますよね。
そうですよね。実際、それで関してちょっと良くない話ではあるんですけど、私、フロントあんまり最近触ってなくて、
フロントをやりたいっていう方について、いい感じに足並みを揃えるのが大変っていうか、
弊社はこういう感じでこうやっててっていうところ、話はできるんですけど、ちょっとああっていう足踏みをしてしまうっていうタイミングがちょくちょくあって悩ましいところであれば。
確かにそれはわかりますね。さすがに、いくらエンジニアといえども、職種っていうのが結構多様化してきているので、
全ての職種に対してモチベートできるようなカジュアルメンダーができるかというとまたそれは違うんですよね。
例えば、バックエンド、フロントエンドっていうのもあるし、もっとデータよりのデータ分析だったり、
09:01
データサイエンティストみたいな方をどうモチベートしていくのかっていうと、そこの面白さみたいなのは一定のやっぱり知識があったりがないと伝えられないでしょうし、
SREみたいな方もあれば、いろいろありますからね。ここはキリがないんでしょうけど、
でも人事の人がやるよりはエンジニアのバックグラウンドがあるエンジニアリングマネージャーがやった方が、
より近い位置の話ができるっていうのは絶対的にはあるでしょうね。
はい、そうですね。あとフロントだけにしか興味がないっていう方はもうあんまり少ないですから、
何かしら他の関連する領域についてすごい興味があったりとか勉強してたりっていうことがあるので、そこからもやっぱりつながっていくことはあるので。
これ会社さんにもよると思うんですけれども、私の歌舞伎スタイルの方だと採用するときも一旦フロントエンドみたいな縛りで募集はするんですが、
実際にやっていただくのってその技術だけにとどまらないような働き方を期待しているところがあるので、
そういう働き方自体が面白いですよねみたいな話をしたりだとか、よりスキルを使ってどんな事業の問題を解決していくのかとか、
そういうお話をしたりするので、そういうつながりの部分さえうまく話せれば、そこまで技術のところの最新状況をキャッチしていなくても、
一定うまく面白い話はできるんじゃないのかなっていう気がしてますけどね。
そうですね。実際その人事の方だったら何を言ってるか分からないってなるかもしれないんですけど、EMだったらこの人すごくフロントに興味あるから、
技術面談とかもしくは第二のカジュアル面談の時にフロント寄りの方をぜひ同席させようっていう考えもなりますし、
そういったところで失敗率は下げられるかなって思いますね。
そういった採用のところ、花田さんがエンジニアとしてやらなくちゃダメだっていうか、
エンジニアを採用するならそれが分かってる人がやらなくちゃダメだっていう風にインサイトを持って、
自分がやるっていう風に決めたっていうところは結構面白いなと思っておりまして、
実際これ採用にどれくらい時間使ってらっしゃるんですか。
そうですね。ざっくり計算してカジュアル面談とかも入れると、大体週10時間くらいですかね。
多いと10時間くらいですね。
そうですよね。それぐらいになってきますよね。1日2時間とか平均すると使って。
ですよね。結構時間使いますよね、ここは。
そうですね。実際採用のあれこれを考えると同時に開発部内の外へのアピールっていうか、
外へのアクションっていうときにどうしてもうちに絵の振り返りっていうのがあるので、
得られるものもあるっていうところからやってますね。
あと採用やるってなったときに、
12:04
割とゼロからのスタートみたいなところでやられてきたってことなんですが、
どんな基準でエンジニアを評価していくのかとかいうところもゼロから作っていったんですかね。
いや、もともと評価制度、開発部の評価制度がちゃんとあったので、
それに照らし合わせてこの人だったら今求めてる層はこの部分だからこれくらいのところができる人でないとっていう感じで。
評価技術があったのですごくだいぶゼロからとは言えないですね。
なるほどなるほど。
ちょっとそっちの話を聞いてみたいので、採用の話から評価の話に移りたいと思うんですけれども、
その評価の基準っていうんですか。
それは具体的にどんなものだったんですか。
大きな指針として3つありまして、
1つは大きな仕事に立ち向かえる人、具体的目標を設定して前に進めるタイプ、タスクの管理とかいうところも含めてます。
大きな指針の2つ目っていうところは技術に対して深い理解をしている人、
専門性があったり、もしくは得意な技術領域や普段の開発で徹底的な調査とか言及名ができるような人。
3つ目の指針としては、ちょっとエキスパート寄りの方向けの指針なんですけど、
継続的に勉強し、それをエヴァンジェレル人っていう呼吸をするように勉強してほしいし、呼吸をするようにハーピーウォッチ研の活用してほしいっていう、この3軸がありますね。
なるほど。この3軸を面接の中でも見に行くようにしていったってことなんですかね。
そうですね。実際にカジュアル面談の資料の中にもこういう指針ですっていうところ言って、
で、実際にあなただったらどういう方向に進みたいですかっていうお話を聞きますね。
なるほどな。なんかその、割と何ですかね、僕だと全職がメルカリでこう3つのバリューみたいなのがあって、あれはあれですごくわかりやすいなと思ったんですけれども、
今のそのマツリテクノロジーズさんのその開発部の指針っていうのかな、評価基準3つ伺った時に、
まあそれはそれで割と広い範囲をカバーしていて、なんかこう技術だけにとらわれない、その行動の仕方っていうか問題を解決するような部分もきちんとカバーしているような軸になっていて、
なんかすごくバランスのいい評価軸っていうのが3つ、いい感じであったんだなっていうふうに思って、なんかこうなんでしょう、その軸っていうのはなんかこういろいろ試行錯誤してなんかできてきたものなのかとかなんかあるんですかね。
そうですね、いやこれその評価軸っていうところは発生経緯としてはそもそもがCTOがジョインしたタイミングで評価をしなくちゃならないってなって、
評価軸がその当時エンジニアの評価軸っていうのがあんまり定まってなくて、それでCTOが仮に立てて実際に開発部のメンバーにどうだろうかっていう相談をして、
15:11
いいんじゃないですかってなってそのままっていう。で、実際見直しつつも定着しているって感じですね。
なるほどな。じゃあ最初にCTOが作られたっていうものが割といろんなバランスを加味してこの軸っていうのがなんかこう提案されたっていうことなんでしょうかね。
はい。
でもやっぱりそういう軸がうまくバランスよく存在しているっていうのってすごい大事かなと思いますね。
それによっていろんなこういう方向が今成長として足りてないよねとかね、そういう会話もできますもんね。
そうですね。
IT・インターネット業界に強い転職アプリGreenは、今話題のテック企業、プロダクト開発、DX案件などGreenだけの良質な求人を数多く揃えています。
正式応募前に企業の中の人とカジュアル面談ができるので、仕事内容やメンバーのことをしっかり理解した後に先行に進めます。
カジュアルに始める転職活動にGreenをご活用ください。
そういう評価基準があったりするっていうことだったり、そもそも評価っぽいこと、評価っぽいというか評価をしているっていうことだと思うんですが、
9人っていうサイズの組織で、そういった評価の基準があったりするっていうのって、全ての会社がそういう状況ではないと思うんですよ。
どっちかっていうと、まだ小さいから評価とかそんなになくてもいいんじゃないとか、そういうのがあったりすると思う中で、
割ときちんとしようというか、過剰なきちんとではなくて、必要最小限のルールというか、
そういうところを整備していこうっていうものが、つぎテクノロジーズさんの少なくとも開発部っていう中の暗黙的な美学というかポリシーというか、
そういうところに通ずるものがあるのかなっていうのも個人的に思ったりしたので、その辺り感覚でもいいんですが、
花野さんの思ってらっしゃることってありますか。
やっぱり何事も透明性がある程度ないと怖いよねっていうのってあるじゃないですか。
特にエンジニアの場合だったらすぐにアクセスできるっていうところが要求されているので、そこは透明性っていうところ、
特に評価っていう、なんだかんだ給与とかにもつながるようなものについては透明に担保しておきましょうっていうところはありますね。
事業の成長と組織の成長は両輪であって、両方があってかつ両方が見えていないと個々人のキャリアプランへの影響も考えられます。
18:02
祭りっていうのはコロナの影響下においても事業の成長は続けることができて、かつ数字も残したんですけど、
一方で組織面での成長っていうのは数字では見えづらいとなったので、
自分の影響範囲の開発部においては明確に組織としての成長を確保していこうという思いがありました。
なるほどな。どの会社でも勢いよく事業や組織がスケールしたときって、
歪みが出るのって必然みたいなもんだと思うので、それをどれくらいのスピード感で、
どれくらいの硬さや柔らかさで整えていくのかっていうのは会社次第だと思うんですよね。
そういう中で開発部のところのルールまではいかないですね。評価基準みたいなのを整えられたのって。
その透明性も当然あると思うんですけども、やっぱりきちんとしてた方が仕事しやすいというか、
そういうマインドっていうんですかね、ところの現れなんでしょうかね。
その透明性みたいなところもあるんですよね。エンジニア一般的にそういう環境の方が好きっていうのがあると思うんですけども、
花田さん的にはそれってエンジニアにとってっていうことなのか、花田さんの中でのこうあった方がいいっていう、
もう少し上位の概念っていうか思考性っていうかいうところだったりもするんですか。
そうですね。やはり一つは、ベースとなるのはエンジニアが働きやすい、安心して働けるっていうところが一番あって、
もう一つはやはり我々資本主義社会に生きているので、資本主義のところでうまく資本家といい関係を作って、
かつ労働者はただ酷使されるだけじゃなくて、いい感じに会社をハックしていこうっていうところがあって、
なのでそういった関係を作れるようにしていかないと、会社に入るってなんかこう労使契約を結ぶだけじゃなくて、
会社でいいチャンスを得る、いい機会を得る、いい環境を得るっていうところをやって欲しいのでっていうのもありますね。
なるほどね。そういう時に一定の基準っていうものがあって、その基準をどううまく使いながら会社のためにもなるし、
自分のためにもなるっていうのがやれればいいっていうことですよね。
それが基準がないと、じゃあどこまでがOKでどこまでがダメなのかっていうのが、それこそ俗人的な判断になっちゃいがちですからね。
確かにね。そういう意味で透明性とも言えるし、労使契約ではあるけれども会社と個人との間が対等になるようにというか、そういった価値観だったりもするんですかね。
21:01
そうですね。ちょっと私にはそういった価値観があって、特に私の見てきたエンジニアっていう方々ってそういった特徴の方が多かったような記憶があるので、そこも大事にしていこうってなりましたね。
確かにね。当然これって会社だったり組織っていうところのカルチャーの要素もあると思うので、どういった組織にしたいのかっていうので変わってくると思うんですが、
いろいろどの組織にも良さはある中で、個人がある程度その人の意思というか、そういうものをきちんと持って、会社は会社というシステムですよとかね。
そういう見方をしながら、きちんと求められている期待を出しながら、個人としての生き方というか個性というか、そういうものもきちんと一定のラインで持っていて、そこも自分の判断で利益を得ていくっていうかね。
そういうことがやれる方がいいっていう考え方は当然あると思うので、それはいいなって思いました。そういった評価軸みたいなものがありつつ、実際、エンジニアたちを成長させていくっていうところも必要だったりするのかなと思うんですよね。
そういう時に、プロダクトオーナーとかやってるので、すごいやりがいはあると思うんですけれども、それだけでエンジニアたちって、まつりテクノロジーさんの中でどんどん成長していけるような感じなんですか?
そうですね。成長させるっていうか、成長してくださいとお願いするっていうところがあるかなっていうところですね。前回のお話でオーナーシップを与えるっていうことを言ったと思うんですけど、かなり本人主義的なところもあって、自由と裁量を与えて、後は機会を提供して、それでどんどんいろいろやって、どんどん成長してくれって、成長してくださいっていう感じですね。
じゃあ、自由が結構あるっていうことなんで、それぞれの人はオーナーシップを持ちつつも、いわゆる20%ルール的な感じで、自分の成長に必要なことを勝手にっていうか、いい感じにやってるような感じなんですかね。
そうですね。一つはあれですね、毎日1時間は自分の勉強、業務に多少関連するような勉強をしていいですよっていうルールを提供してて、それでそこで得た知見とか知識とかっていうのは別に社内に絶対活用しなくちゃいけないというわけではないけど、時々それを発表してくれると嬉しいなっていうくらいで与えてたりっていうところはありますね。
なるほどなるほど。そういうインプットは定常的にやってないとなかなか積み上がっていかないんで、必要ですよね。それを1時間くらいって目安をつけてるのも結構いいなと思いました。
24:11
でもそれってなんていうのかな、一方でエンジニアの知識っていうものって単にインプットするだけじゃなくて、その得たものを何らかの形で実際の問題に対して使うっていうことがあることで、当然それが事業に貢献するっていう意味もあるんですが、その人にとっての知識として定着するっていうか、ものになっていくっていう側面があると思うんですよね。
そういうところは上手く導いたりとかなんかあるんですか?
主に2つあって、毎日午後3時から相談会っていうのをやってまして、これ1時間時間取ってまして、ここで要は技術的な悩みだったり発表だったりをする時間を絶対用意しておくっていうところはあります。
もう1つが結構弊社のところで、いろいろとドッグフーディング的な開発しててパブリックにしてるものもあったり、もしくはプライベートで開発してるものもあったりして、そこで活用してもらうってこともありますね。
なんかあれですね。じゃあ使う場面っていうところも意図的にというか、ある程度作ろうとしてるってことなんで、単にインプットだけしてくださいっていうのではないってことですもんね。まあそうですよね。まあその方が全然健全ですよね。
なるほどな。さっき2つ目のところでドッグフーディング的なことをされてるっていう。ドッグフーディングなのか、社内ライブラリーとかツールみたいなものとかなんですかね。そこって具体的にこういうものとかってあったりするんですか。
そうですね。1つはデザインシステムというかUIライブラリーというかっていうものがあって、これがかなりエキスパートが1人で、ほとんど1人でUIライブラリーデザインシステムを作って、それを各プロダクトがフロントエンド側で使っているっていうものがあったり。
あとは他には、Goのタイム型ってすごい日付関連でトラップが多いので、それをラップするための自社の日付ライブラリを開発したりとか、あとはオープンAPIの使い勝手がちょっと良くないので、自社で代替を作って、エンドポインツGoっていうやつがあって、それでいろいろと自分らで使いやすいエンドポインツの追加だったり管理だったりをできるようにしてるっていうことがありますね。
なるほどな。ちょっと一個一個いろいろ聞きたいとは思いつつ、ちょっと時間がないので一個一個掘れないんですが、ざっくりとした印象として、5つプロダクトを持っている9人の開発組織に対して、結構いろいろプロダクトそのものじゃないツールというか、そういうものの開発をやられてるんだなっていうふうに思いまして。
27:05
そこって何でしょう、意図的にそういうふうに、当然エンジニアの成長っていう側面もあると思うんですが、それにしては結構たくさんやられてるなっていうふうにも感じたんですよね。ここって何か考えだったり思いっていうか、そういうものがあるんですか。
そうですね。1つはないなら作ろうっていうところはありつつ、もう1つ、私個人的なエンジニアリングマネージャーとしての思いなんですけど、他の会社と同じような感じにはしたくないっていうのがあって、他の何かどこかの大きな企業だったりとかに依存してではなくて、自分たちの力で問題を解決していきたいよねっていうところがあります。
これがやれないと結局他の似たような会社と同じになっちゃうから、それは避けたいよねっていうところがありますね。
なるほどね。だから何かあれですね、事業オンリーじゃなくて、やっぱりエンジニアとしてこうあるべきみたいな美学みたいなものがあって、ないから作るというか、既存のものを探せば近しいものはあるんだけど、自分たちの問題解決にはベストフィットしてないっていうこともよくあると思うので、
そういう時に自分で作れる状態の方がいいよねっていうのが何か価値観としてあるんですよね。
はい、それは言われるとあるんじゃないかなっていう、当然としてあるので、あんまり価値観として名分化しているものではないんですけどありますね。
そうですね、何かそこって結構何でしょう、いろいろな企業を見てきた中で、花田さんのお話を伺うと、何か確かに当たり前かもしれないんですけれども、それを当たり前かのようにできているところって、そこまで多数ではないと思うんですよ。
やっぱり特に小さい組織であれば、やっぱり事業に100%振り切るとかだと思うので、出来合いのライブラリを使って何とかそれでできる範囲でやろうとかってなると思うんですよね。僕もそういう意思決定をしちゃいそうだと思うんですよ。
ただそうではなくて、やっぱりエンジニアがきちんと自分たちのベストは何かっていうのを考えて、そういうベストのソリューションを生み出せる状態っていうのを作る余白っていうのかな、何かそういうものをきちんとデザインされてるっていうのが、すごく組織として面白いと思いますし、
エンジニアリングマネージャーとして、すごいエンジニアのことを考えてというか、エンジニアがどういう状態がいいのかっていうのを、すごく花田さんの中で強い信念みたいなものを持たれて、そういったデザインをされてるんだなっていうふうに僕は勝手にかもしれないですけど解釈しました。
デザインしたというよりか、結構自然発生的なところはやはりあるかなと思いますね。あと、ベストを探すっていうところはどうしても求めてしまうんですけど、それをいい感じに開発者体験っていう、コストを下げるとかいうところにちゃんと落とし込めているっていうところも一つはこういった自社のライブラリーだったり、自分らのためのツールの開発っていうところには落とし込めてるかなっていう感じですね。
30:17
そうですね。花田さんだけがデザインしたとかではなくて、みんながどういうふうにやれてるといいのかっていうのを一緒に作りながらそういう状態になってきたっていうことなんでしょうね。
なるほどな。
結構理想的だなっていうふうに思いました。
ありがとうございます。
ちょっと1個だけ聞きたいのは、今すごい良いバランスで開発者の体験もよく、開発部っていうのが存在してると思うんですけれども、これを組織の人数がもうちょっと増えてきて、花田さん以外の人もマネージメントしていくみたいな状態になった時に、
そういうマネージメントの仕方っていうのが花田さんにすごく俗人化したものなのか、祭りテクノロジーズとしてそういうマネージメントっていう文化がおそらく他の人でもできるだろうみたいな感じなのかなんでしょう。
そういうところは花田さん的にそういうDNAみたいなのがきちんと受け継がれていくような感触を持っているかだったり、それはちゃんと教えていくだったりするのかとかありますかね。
そうですね。教育する人の教育っていうのは、今現在進行形なので、この文化がどこまで継続するかとか、このスタイルのマネージメントがどこまで共有できるかっていうのはちょっと怪しいところではあるんですね。
ただ、今いろいろな人と一緒に仕事したり採用したりっていうところではある一定、この雰囲気、この文化、このスタイルいいよねっていうところの教育、理解、共感は得られていると思うので、何とかなるんじゃないかなっていう期待をしてますね。
なるほどね。確かにね、花田さん一人で設計したっていうものじゃなくて、いろいろな人の意見でそういうふうになってきたっていうところだから、だからあれですよね、設計っていうよりはもうそういうフード、カルチャーみたいになっている部分もあると思うから、そういう意味では自然と受け継がれていくっていうことかもしれませんね。
なるほどな。中でもすごくいい状態が作れてるんだなと思って、めちゃくちゃ学びになりました。ありがとうございます。
今日は花田さんからまつりテクノロジーズさんの、より開発組織のマネジメントという観点でお話を伺いました。本当にいろんなことをされていて、特に開発者寄りの観点でのいろいろ考えてらっしゃること、やってらっしゃること、作れていることっていうのは聞いている方にとってもすごく学びのあることになったんじゃないのかなと思います。
花田さん、2回にわたりありがとうございました。まだまだお話足りないので、またお待ちしております。今回2回目では花田さんがどんなふうにマネジメントされているのかっていうのをお伺いして、すごく私の印象に残ったのは、開発者としてこういう体験のほうがいいよねっていうことに関して、すごく花田さんが信念を持って活動してらっしゃるところかなと思っていて、
33:21
採用に関しても花田さんがご自身で動いてらっしゃるっていうのも、そういった開発者が採用みたいなところに時間を使わずに開発に専念できた方がいいだろうっていう考え方のもとにされてらっしゃると思いますし、あとは開発者の普段の仕事においても問題を解決するときにベストなソリューションを選べるべき、選ぶときにないんだったら自分たちで作れるべきっていったところも、
そういった状態のほうがいいっていうことに対して、きちんと組織をそういう状態に持っていけるようにエンジニアリングマネージャーとして作ってらっしゃるところがあったので、これはなかなか小さいエンジニアリングチームでできることではないなというふうに僕は思いまして、とても印象に残りました。
ハナダさんとエンジニアがプロダクトにどれだけオーナーシップを持つのか問題についてお話しした前回のエピソードもぜひお聞きください。さて、この番組では感想や質問、リクエストなどをお待ちしております。番組詳細欄にあるリンクよりお気軽にご投稿ください。
TwitterではハッシュタグEM問題集をつけてツイートしてください。EMはアルファベット、問題集は漢字でお願いします。そしてApple PodcastやSpotifyのPodcastではレビューもできますので、こちらにも感想を書いてもらえると嬉しいです。お相手は株式会社株区スタイルCOO兼CTOの後藤秀典でした。
