00:00
株式会社株区スタイルの後藤秀典です。この番組では、エンジニアリングチームで起きている問題について、技術・組織・ビジネスといった複数の観点で深掘りし、問題の正体へアプローチしていきます。
今回のテーマは、エンジニアがプロダクトにどれだけオーナーシップを持つのか問題です。
エンジニアはプロダクトと近い距離で仕事をしているところもあれば、例えばプロダクトマネージャーがいたり、いろいろと受発中的な関係だったりするところもあると思います。
最近、自社でサービスを持っているところであれば、エンジニアがよりプロダクトと近い位置、強いオーナーシップを持って開発している方が良いプラクティスとされていたりしますよね。
ここがどんな設計になっているのかというのを聞いてみたいなと今日は思っています。
ゲストには松井テクノロジーズエンジニアリングマネージャーの花田悟さんにお越しいただきます。
松井テクノロジーズさんでは、民泊業界の中で、より運営のところをITの力で効率化していこうというようなことをされているんですけれども、
ここでいくつかプロダクトを開発されたりしているので、それをどんなふうにうまくマネージしているのかとか、
どんな考え方でオーナーシップを設計しているのかというところを聞いていきたいなと思っています。
エンジニアリングマネージャーの問題集。
では本日のゲストをご紹介します。松井テクノロジーズエンジニアリングマネージャーの花田悟さんです。
自己紹介をお願いできるでしょうか。
はい。松井テクノロジーズ株式会社でエンジニアリングマネージャーをやっております。花田悟と申します。
はい。今日はよろしくお願いします。
よろしくお願いします。
はい。ではですね、松井テクノロジーズさん、私の歌舞伎スタイルとちょっと近い事業領域でやられている。
そうですね。
うちの会社は旅行代理店という感じなんですけれども、松井テクノロジーズさんはどっちかというと民泊の方の、
施設の管理のシステムとか、その辺やられてるってことだと思うんですが、
ちょっとまずこの事業のところだったり、会社の理念とか、
なんかその辺りを、僕以外の視聴者の方って、僕よりもあまりなじみがない方もいらっしゃると思うので、
その辺りからまず説明していただけないでしょうかね。
そうですね。まず松井テクノロジーズ株式会社の理念っていうところで言いますと、
一つ最も大事にしているのは、意味ある新産業を作り続けるっていうところでして、
言ってしまえば、ソフトウェアのみの会社ではなくて、ソフトウェアが生み出す差分を最大化していくっていうところをベースにしていて、
現在は民泊住宅取得事業と、そして短期賃貸事業っていうところをターゲットに開発だったりサービス展開をしています。
03:04
一般には知り合いや主さんが空いてる一室を貸し出すことが多いのが民泊なんですけど、
一方、祭りが運営しているのは一室を丸々貸し出すために借り上げているっていうものなので、
ホテルほどフォーマルではなく、また知り合いの部屋ほどカジュアルではないっていう感じのお部屋を貸し出す民泊をやっております。
ありがとうございます。またちょっとこの事業特性っていうか、ああいうところだったり、
その事業の中で今どんなシステムを、プロダクトを作ってらっしゃるのかとか、後々聞いていきたいなと思っております。
この祭りテクノロジーズさんで、羽田さんがエンジニアマネージャーとして仕事をされてるんですけれど、
これは入社してからどんな仕事に関わってきたのかとか、
聞いてる話だと最初はRailsで作ってたものを少しずつTechStack変えてきたとかだったりすると思うので、
その触りみたいなところだけでも今簡単に教えていただけますか。
そうですね。私が入社したのが5年以上前のタイミングで、その時はRuby on Railsだけで開発していたんですね。
今でも運用しているM2MシステムというものをRailsだけで動かしていたんですけど、
現在のCTOが入る前後のタイミングで、バックエンドはGoがメインで、
フロントエンドはReactプラスTypeScriptでという感じになって、後途中でラストが入ったりという感じになってきました。
技術面についてはこういう感じで、もう一つサービス展開というところに関して言いますと、
最初はRailsアプリケーションでモノリティックに開発していたのですが、
一貫性よりも可用性のほうが大事だということが分かったところと、
開発体験としてサービスを分割して展開していたほうがいいよねという話になったので、
現在表に出ているところとしては5つのプロダクトになっていて、
実際のところ7つとか8つとかあったりする感じですね。
なるほど。ありがとうございます。早速いろいろ深掘りしたいキーワードがいろいろ出てきたりしているんですけれども、
まずは一旦ここで区切らせていただいて、
今日はいろいろお話を聞きたい中でも、まずはこの事業というものがどんな事業なのかというのを
僕がもう少し理解したいところがあるので、その辺りのお話を伺っていきたいなと思っています。
事業との関わりでプロダクトというところで5つあるとおっしゃっていたと思うんですが、
その5つのプロダクトというのがそれぞれ事業の中でどんな位置づけになっているものなのかとか、
そこをもう少し教えていただけますか。
そうですね。ゲスト体験的なところからまずお話させていただきますと、
通常ゲストさんというのはお部屋をOTAサイト、エアビーさんとかで調べて、
予約を確定させた後でいろいろと事前にチェックインするための方法だったりとか、
06:05
またこの設備はあるかとかいう確認だったりというメッセージのやり取りをするというところ、
そこら辺をやり取りしているというところだったり、
あとは実際に数百、今500ほどのお部屋を抱えている状況で、
そういったのを全てをスプレッドシートとかで管理しているのというのはすごく大変。
かつ、送信漏れとかもあるというところをサポートするところで、
M2M Systemsというサービスがあります。
またお部屋に入る際の鍵の受け渡しだったり、本人確認、
またその後の宿泊者台帳の作成というところに関してはM2Mチェックインというところがカバーしております。
そしてチェックアウト後のところに関して言いますと、
実際に清掃したり、また備品を管理したり、また清掃のクオリティチェックだったりというところはM2Mクリーニングでカバーをしておりまして、
あとはもう一つ先ほどシステム図のお話をしましたけれど、
それは住宅宿泊事業のほうをカバーしてまして、
もう一つ自社でマンスリープラットフォームのスミカというのを持ってまして、
ここはOTAサイトとか検索機能とかも兼ねて、また契約だったり決済、カスタマーサポートもサポートしているというのがスミカになっております。
またシステム図とかチェックイン、またクリーニング、またスミカというところ、
いろいろあるので、これらを連結させる、そして実際の物件を管理するところだったり収支管理だったりというところを管理しているのがM2Mコアというサービスがあります。
これで計5つになります。
なるほど、ありがとうございます。
結構あれですね、ゲストさんから見てもチェックインの前のところから滞在中というのかな、その辺りのものと、それからチェックアウトした後というところで、
それぞれのフェーズにおいて必要な運営している側のお仕事みたいなところを効率化するシステムで、いくつかプロダクトがあって、
プラスニンパクじゃないマンスリーみたいなところもカバーするようなものも出されているということなんですね。
結構広めにいろんなフェーズの機能をカバーしていっているという感じに見えるんですけれども、
こういったプロダクト群をどれくらいのサイズの開発組織で作られているんですか。
そうですね、現在の開発部のメンバーの数と言いますと9人になっています。
多少2年前とかはもうちょっと10人とかそれくらいいたんですけど、それほど増減はせずという感じですね。
なるほど、ここめちゃくちゃ興味深いので、今日ぜひ深掘っていきたいんですよね。
9人という人数で5個のプロダクトを作っているというのは、ものすごい効率よくプロダクトを作っているとも言えると思うので、ここは興味深いところですね。
ちょっとそこの話に行く前に、濱田さんがこの9人の開発組織というのを、どんな感じでマネジメントされているのかというのも一旦聞いておきたくて、
09:06
9人全員を濱田さんがマネジメントしている感じなんですか。
いえ、そうではなくて、実際のところマネジメントってそこまでがっつり詳細にいろいろやっているというわけではなくて、ワンワンをしているという限りで言いますと、5人を見ているという感じですね。
ただ、CDOと各州でワンワンをやっているケースもあるので、5人と言っているけど、実際2人ほど各州でやっていたり、もしくは別のレポートラインの1人プロダクトオーナーの下についている人間もいるので、
またそのプロダクトオーナーと各州でやってもらったりという感じですね。
なるほど、なるほど。じゃあ5人プラスアルファぐらいのところですね。
そうすると、濱田さんが手を動かすようなこともしながらマネジメントもされているぐらいのニュアンスなのか、フルでピープルマネジメントなのかというとどんな感じなんですか。
そうですね。私自身がM2Mシステムズのプロダクトオーナーではあるので、かなりコードを書く時間をある程度確保しないといけないという状況にはなっていて、
なのでコーディングをそこまでフルではやれないんですけど、ピープルマネジメントだったり組織を良くするためにどうしようかということをいろいろやったりという。
比率としては今4対6でマネジメントよりの方がちょっと増えてきたかなって感じですね。
なるほどなるほど。いろいろ興味深いワードが出てくるので、めちゃくちゃ質問していきたいことだらけなんですけれども。
一旦もうちょっとこの組織の運営みたいなところを聞くんですが、9人という開発組織で5つのプロダクトを持っていて、
その今プロダクトオーナーという言葉が出てきたんですが、プロダクトというものに対して誰がどんなものを作るというふうに決めていったりしてるんですかね。
そうですね。どういうふうに決めていくかというと、通常ですと、プロダクトごとにプロダクト会というのを設けてまして、
ここで開発側のプロダクトオーナー、実際に行動を書いてというところの人と、もう一人事業側の責任者と一緒に1対1だったり、他にも何人か付いたりということはあるんですけど、
これを毎週だったり各週やってまして、ここでこれをやりたいとか、どうやっていきたいとかいうところを明らかにしたりとか、
もしくはこういう感じにやっていきましょうという仕様の策定だったり、また終わった後、リリースしたらこれリリースしました、使ってください。
そしてフィードバックを得るというところをやっているので、実際のところ誰が開発をすることを決めるかというと、
プロダクトごとにビジネスサイドか開発サイドかというところは多少比率は違いますけれど、お互い人同士なのでどうしてもパワーバランスというのはあると思うんですけど、
どちらもが何を開発するかを決めていくという感じですね。
12:03
ありがとうございます。でもあれですよね、いわゆるプロダクトマネージャーみたいな人が作るものを決めているわけではないですよね、組織としては。
そうですね。プロダクトマネージャーというのを弊社のポジションとしては現在はいませんね。
そうするとエンジニアが本当に作るものを、作るフィーチャーを決めていくという、いわゆるプロダクトオーナーとして振る舞っているというところで、
あれですね、単にものを作るだけじゃなくて、結構そのプロダクトがどうあるべきかというところも考えて、
ビジネス的なセンスも持って仕事をしていくということだと思うので、結構やりがいはありそうな仕事かなというふうに思いました。
ちなみにあれですか、このマツリテクノロジーズさんのプロダクト群って運営系のところの改善みたいな、
効率化みたいなプロダクトが結構揃っていると思うんですが、これは実際どういう方に使っていただくものになるんでしたっけ?
そうですね。メインとなるのは社内の社員の方々がメインで使われているというところで、
メインユーザーは社内の方ですね。もちろん少し社外の方々も使われるんですけど、メインのユーザーは社内の方ですね。
じゃあさっきおっしゃってたビジネス側の人と開発側のプロダクトオーナーが話すという話の中の、
ビジネス側っていうのはもうその社内のユーザー部門っていうことなんですか?
そうですね。社内の実際に使っているユーザーの方がメインっていうことにはなっています。
ただ事業が移り変わっていくとどうしてもちょっと実際に触っているところから離れるってことは多少はありますけれど、
ただプロダクトことは事業部側で一番分かっている人が事業部側の責任者として参加していただくって感じですね。
社内というか同じ会社の中に実際使っているユーザーがいるっていうのは、僕自身も前職ぐらいで経験した組織の形で、
それはそれで結構面白いというか、フィードバックがめちゃくちゃ早くもらえたりだとか、
開発部のやってることがダイレクトにその人たちの仕事の効率に影響するだったりとかがあって、
すごくやりがいがそういう面でもあったなっていうのを今思い出しました。
実際サービス開発のやりがいっていうところの一つっていうのは、人が喜んでくれるところっていうところ。
オペレーションコストを下げたりとか、ユースケースのカバー率を高めたりっていうところっていうのは、
実際目に見えたフィードバックが得られるので、すぐ1週間とかそれくらいで得られるフィードバックなので、
モチベトンとしてはすごく強いですね。
ですよね。
IT・インターネット業界に強い転職アプリグリーンは、今話題のテック企業、プロダクト開発、DX案件など、
15:06
グリーンだけの良質な求人を数多く揃えています。
正式応募前に企業の中の人とカジュアル面談ができるので、仕事内容やメンバーのことをしっかり理解した後に先行に進めます。
カジュアルに始める転職活動にグリーンをご活用ください。
ちなみに、少しその事業のところに話を戻したいんですけれど、
民泊系の事業をやっていく中で、僕のあまりそこに詳しい人間ではないんですが、
なんとなくの印象として、やっぱり一つ一つの宿泊施設の固定資産というのかな、
ホテルとかと比べたらそこまで大きくない中で、それを運営していくという時に、
部屋の数がそんなにたくさんあるわけでもないと思うから、
一泊あたりのコストというのをできるだけ下げていきたいビジネス、
どれでもそうかもしれないんですけど、よりそういう要因が、ファクターが大きいのかなと思っていて、
そうするとやっぱり人件費とか、そういうものをいかに削るのかというのが、
事業の利益というか、存続性というか、そういうところにも影響しそうだなと思っているので、
まつりテクノロジーズさんというのは、すごくシンプルにというか、
素人目線でいうと、そういうところに対してITの力でアプローチされてるんだろうなというふうにも見えているんですけれども、
その見方というのは合ってるんでしょうかね。
そうですね。一つはやはり、利益を上げていくというところになると、どうしてもオペレーションコストというのが高くなってしまうので、
ホテルさんと比べるってなってしまうと、例えばフロントに人をずっと常駐させるってなるとすごくお金がかかるってなると、
そこをチェックインシステムで無人化したりとか、というところなので、実際のところは人件費を抑えるというところは確かにあります。
またそれとは別で、やはりここでいうところのゲスト、宿泊者というところの体験を高めるというところだったりとか、
なるべく快適に過ごしてもらうためにどうしていくかというところで、コストを下げるというところと、
付加価値を付け加えていくところというのは両軸でやっておりますね。
確かにそうですね。その後者の方も当然無視してはならない部分だと思うので、コスト下げてお客さんの体験が悪くなってしまう意味はないですからね。
ITみたいな力でよりゲストへの付加価値というのも提供しつつ、オペレーションコストみたいなのも下げるという、
すごい理にかなっているなと思いますし、かつあれですね、オペレーションコストというのが社内のオペレーションコストみたいな部分が結構あると思うので、
自社としてもビジネスを継続する上でのコストがどんどん下がっていくというか、
低いままを抑え込めるというのはすごくウィンウィンな状態でビジネスをされているようにも思いました。
18:05
そうですね。社内のユーザーというところだと、どうしても単調な作業以外のもっと楽しいやりがいのあることをやってもらいたいというのはあるので、
実際それだけ時間を増やせると、その人の使う時間を減らせられるし、もっといいこと、もっとビジネス的にインパクトのあることができるようになるというところは狙いの一つではありますね。
そうですよね。それはどんな職種に対してもそういう方向に持っていきたいですよね。
そういったビジネスをされている中で、先ほどの気になるワードの開発者がプロダクトオーナーをやっているというところなんですけれど、
具体的にプロダクトオーナーの仕事って何をやるのか、もしくは何をやらないのかを決めるということが結構大事だと思うんですが、
こういうことを決める時に、まつりテクノロジーズさんの中で決める順番というか評価軸というか、そういうものってあったりするんですか?
プロダクトごとにやっぱり、スミカだったら2Cというところだったり、Coreだったらかなり業務回線というところ、
システムズだったらやっぱりAirBとのやり取りというところで、ちゃんとレートリミットだったりとかエラーバッジェットを下げたりというところがあったりするので、
各プロダクトごとに何を重視するかというところは多少は違います。
ただ、一貫して共通していると思われるところというのは、やはり使う人に対してどれだけ価値を提供できるか、もしくはインパクトを与えられるかというところを重視してますね。
またあとは先ほどもちょっと触れたところではあるんですけど、実際に社内のユーザーが使ってはいるので、
そのところでその人たちの困っているところを助けるところというところを優先して取り組みがちというところはありますね。
なるほどな。そうすると、どれくらいユーザーに価値を届けられるのか、価値提供できるのかっていったときに、
当然プロダクトオーナーとしては何が価値になるのかっていうのをきちんと理解してないといけないわけですよね。
それって言語化されてたりだとか、そういうのをきちんと理解する、分析するだとか、メトリクスを持っているだとかなんかあるような気もするんですけど、
その辺ってどういうふうにやられてるんですか?
そうですね。言語化されているプロダクトって試みをやりつつではある状況なんですけど、
全プロダクトに対してやっているというわけではないです。
ただ、開発部の一つの目標として小さく挑戦すばやく失敗だったり、もしくはあるべき姿を探すっていうところがあって、
ここら辺からどんどん仮説を立てて検証して仮説を立て直すってことをよくやってるっていう。
なので、評価軸としてどうしても言語化はしてないけれど、そのプロダクトオーナーがかなり何を求めてるかっていうところを考えて、また立て直してっていうことをやってるっていうところありますね。
21:07
なるほど。じゃあもうそれを考えるっていうか、見出すことからプロダクトオーナーに権限が依存されてるというか、任されている状態ってことなんですかね?
そうですね。実際にプロダクト界を回していただくってなると、そういったことをよくお願いしております。
なるほど。じゃあ相当裁量があるというか、責任が大きいというか、そういう状態で開発者がプロダクトオーナーをやっているってことなんですね。
そうですね。ちょっと言い方は悪いですけど、かなり放任主義的なところもありますね。
でもその分、自分の考えたことをきちんと責任を持って実行していけるっていうことだと思うので、当然いろんなチャレンジができるでしょうね、その中では。
エンジニアっていう枠に留まらないような経験っていうこともできるんじゃないのかなっていうふうに思いました。
そういったプロダクトオーナーっていうロールっていうんですかね、いうものがあることはわかりました。
5つプロダクトがあって、9人のエンジニア。それでやっているっていう時に、1つのプロダクトはじゃあ1人だったり2人でアサインメントが決まっていて回していくのか、
それとも1人がいくつかのプロダクトを見て回していくのかっていうと、どんな形なんですか、そこは。
そうですね。複数プロダクトのプロダクトオーナーっていうのは、今はCTOしかいないですね。
基本はやはり1人が1つのプロダクトを見るっていうことにはなってます。
わかりました。プロダクトオーナーは当然入った敵っていうか、これだけをしっかり見てねっていうことだと思います。
プロダクトオーナーじゃない、エンジニアっていうところではどうなんですか。
そうですね。弊社、フロントエンドエキスパートが1名と、あとデザイナーが1名で7人残りいて、ほとんどの人が何らかのプロダクトに関与しているっていうところなので、
かなり先人的に携わっているっていうところがあるので、他のエンジニアについてもかなり自分からどんどん改善していこうっていうところの特徴はやはりありますね。
例えばCoreの中でも、M2M Core、実物件の情報を管理するっていうところでも、CTOがプロダクトオーナーをやりつつっていうところではあるんですけど、他にも2名のエンジニアがいるんですけど、
Goのリポジトリでパッケージを分けてて、その中の3つに分割したところで、ちゃんとそれぞれCTOだったり、もう2人のエンジニアがそれぞれプロダクトオーナーとして活動しているってところがありますね。
なので、通常のエンジニアっていうのは限りなく少ないですね。
24:07
基本何かにオーナーシップというか責任をしっかり持っていて、その部分に関してはすごい材料を持って動いているっていう状態。
逆に何か責任が曖昧って、悪い言い方で言うと曖昧というか、共有されているような状態っていうのがほとんどないような感じなんですかね。
そうですね。プロダクト単位で言うと、やはりプロダクト界を主催している人間っていうのがオーナーシップ握って全部やるっていう感じのところはありますね。
わかりました。かなりオーナーシップに振り切ってるというか、それで効率よくプロダクトを作っていっているってことだと思うんですが、
例えば僕の経験で想像するのは、どれか一つのプロダクトをある一時期ものすごい注力しなければいけない、みたいな状況が出てきたときに、
そうするとオーナーシップっていうのは一旦脇に置いて、一つのプロダクトをみんなで作ろうみたいな。
そういう時期もあるんじゃないかなって思ったりするんですけど、それはどうなんですかね。
過去に多少あったような気はしますけど、現在のところでそういった類似のことがあったらどうするかとなると、
一つはそのプロダクトに限定されない機能っていうのがあるはずなんですね。
要はこの機能が欲しいっていう話でやっても、それって一般の機能ですよねってなったら、
それを別のプロダクトに携わっている人間にちょっと手が空いてるんだったらぜひこれをお願いしたいですっていう感じで、
機能をドメインに依存しない形で切り出してお願いするっていうことはありましたし、
そういう感じでやっていただこうかなっていうところは考えてますね。
なるほど、そうするとやっぱりオーナーシップっていうのを大事にしてるというか、
一時的にでも他のところにアサインされるみたいな状況を作らないように、
作るものを一般的な部分とそうじゃない部分ときちんと分けていって、
一般的なものはプロダクトにくっつく形じゃない状態で作っていくとか、
そういう方針というか哲学というか、そういうものをきちんと持たれてるような感じですね。
コンテキストスイッチ、実際すごく大変じゃないですか。
あれこれって分けるのって。
分かります。
ある程度インフラもやって、バックエンドもやって、フロントもやってっていう一つの機能について、
一連の流れをやるっていうところだと結構ストレスとかコンテキストスイッチがあまり発生しないので、
開発者体験としてもこういったのはいいかなっていうのは考えてます。
この辺結構深いなと思っていまして、
事業とは少しコンテキストの違う開発者が働きやすいだったり、
27:04
より力を発揮できる状況っていうので、そこはそこでもうちょっと聞いていきたいんですが、
ここはおそらく次回より深掘って聞いていきたいところだと思っていますので、またお聞かせください。
その辺かなり特徴を持たれてると思うんですけれども、
ちょっと事業っていうところに戻ると、
オーナーシップをかなり強く持つように設計していて、
オーナーシップが共有されないようにやっている。
それを効率よく保っている状態だと思います。
この話をするとおそらく多くの人が結構知識が属人化される部分があるんじゃないのかっていう懸念を持つと思うんですよね。
これに対する対策っていうか、それも共通コンポーネントみたいな部分で
知識が共有されるようにしているとかそんなのかなとか想像するんですけれども、
何か具体的にやられていることってあるんですか。
何かドキュメントとか文章とか設計資料とかっていうのを残す習慣がないっていうのと、
もう一つは残してメンテするコスト高いよねってなっちゃうっていうところがあって、
そういったところから知識の共有っていうところにコストを割くっていうところは避けてるってところがあります。
むしろコードを分かりやすくだったり、コードコメントで誰でもコードを書けるようにしていこうっていうところはある。
ドメイン知識についてはもうどうしようもないので、もう膨大なので、
実際に例えばARBの契約とかリスティングからの予約の作成だったりというところだったり、
もしくは住宅宿泊事業と短期賃貸契約の違いとかって、
法律の専門家じゃないので若干こういう流れっていうところはみんな分かるけれど、細かいところは分からないっていう。
なので100%はドメイン知識について何かドキュメントに残そうっていうことはやってないです。
むしろ自分でオーナーシップ持ってどんどん調べていってっていうところ。
それでドメイン知識をどんどん作っていこうっていうところあります。
ただ基本的なジャーゴン的なところ、用語解説的なところはノーションで少し溜めてたりっていうところはありますね。
結構この辺は特徴が現れてるなと思うんですけれども、
ドキュメントをできるだけ書かないというか、コードがある意味知識のシングルソースオブトゥルースであって、
エンジニアであるならばそれを読んで知識を獲得するのが一番効率がいいというか、
そこに振り切った設計をしてるっていうんですかね。
30:00
そんな感じのように受け取りました。
実際前はRailsアプリケーションをモノリティックに開発するってなってたら結構大変だったんですけど、
実際ドメインごとにもうプロダクトを分けてるので、そのプロダクトの行動を読むと大体何をしたいかが分かるっていうところがあって、
なので一番最初サービス分割をする前はとても大変だったような記憶があるんですけど、
分割した後だとかなり楽にドメインだったり機能だったりっていうのが分かるようになったような気がしますね。
なるほどな。そういう意味でもモノリスを分解して小さなプロダクトというか、より明確な線を引くっていうのは意味があるんでしょうね。
単に作り方っていう話じゃなくて、知識の在り方っていうか、そういうところまで考えた時にどっちがいいんだっけっていう話になると奥深いですね、これは。
でもすごく興味深い方針だなと思いますし、エンジニアのよりこっちの方がいいだろうっていうところを結構深く考えられて、直感でっていうところもあると思うんですけれども、
そこに寄せた設計なんだろうなっていうので、これは一つすごくいい教訓になったかなと思います。
はい、じゃあ今日はマツリテクノロジーズさんの組織の事業寄りの話ということでいろいろお話を聞かせていただいて、いろいろどんなやり方をしているのかというところも伺えて、
そうですね、学びがいろいろありましたんで、また次回よりマネジメント寄りの話を聞かせていただきたいと思います。
花田さんありがとうございました。次回はより花田さんがされているマネジメントについて伺っていきたいなと思っております。
今回のマツリテクノロジーズさんの事業とオーナーシップについていろいろお伺いして、かなりエンジニアのプロダクトオーナーシップっていうところに振り切った設計というか、
状態で運営されているということを伺いました。これはこれでエンジニアがエンジニアリングっていうところだけではなくて、事業っていうところにも深い理解を持って、
裁量も持って取り組んでいくというところで、ものすごくチャレンジングだと思いますし、エンジニアからすると技術を伸ばすだけじゃなくて、
事業を伸ばすためにあらゆることを学んだりしてチャレンジしていかなくちゃいけないという環境だと思うんですよね。これはすごく面白いと思います。
やりがいがある環境なんだなというふうに思いました。とても振り切った設計で、ワークしたらすごいなと思いますし、今ワークしていると思うので、すごく学びのあるオーナーシップの設計だなと思いました。
さて、この番組では感想や質問、リクエストなどをお待ちしております。番組詳細欄にあるリンクよりお気軽にご投稿ください。
33:04
TwitterではハッシュタグEM問題集をつけてツイートしてください。EMはアルファベット、問題集は漢字でお願いします。
そしてApple PodcastやSpotifyのPodcastではレビューもできますので、こちらにも感想を書いてもらえると嬉しいです。
お相手は株式会社株区スタイルCOO兼CTOの後藤秀典でした。
