00:02
エンジニアリングマネージャーの問題集。
株式会社株式スタイルの後藤秀典です。
この番組では、エンジニアリングチームで起きている問題について、
技術、組織、ビジネスといった複数の観点で深掘りし、問題の正体へアプローチしていきます。
今回のテーマは、豊かなドメイン知識をどのように手に入れるのか問題です。
前半で、かなり複雑な、お客様ごとの違いが大きいようなドメイン業界でプロダクトを作られていると、そこで格闘されているという話を伺いました。
では一体、このとても難しいドメインの知識をエンジニアたちがどのように獲得していっているのか、
それをどのようにマネージャーとして促進しているのかといったところが非常に気になるところですので、
そういったお話が聞けるといいなと思っています。
本日のゲストをご紹介します。株式会社オプティマインドエンジニアリングマネージャーの古市佐藤さんです。
古市さん、軽く自己紹介をお願いします。
オプティマインドエンジニアリングマネージャーをしております古市と申します。よろしくお願いします。
オプティマインドには1人目のエンジニアリングマネージャーとして、
今は組織含めより会社が良くなる方向になるように注力しているというところになります。よろしくお願いします。
今回もお願いします。前回はオプティマインドさんの事業のところについていろいろお話しいただいたので、
今回はどちらかというとエンジニアリング組織といったところでお話を伺えたらいいなと思っております。
最初に今のAzizがどんな感じなのかというのを教えていただきたくて、
オプティマインドさんの中のエンジニアの数だとか、それがどんなチームに分かれていたりというところから教えていただけますか。
はい、現状我々の会社、社員数が47名となっております。
この中にエンジニアが27名在籍しております。
開発組織はプロダクト開発部と呼ばれている一つの大きな塊にはなっているんですが、
この中に現状5つのチームがあります。
1つは会社の計画を作るというチーム、計画作成チームと呼ばれているんですけども、
実際にサラズという画面を提供する部分を作っているチーム。
もう1つが計画実行チームと呼ばれていて、作った計画を実際にそれを動かすと。
ドライバーさんが実際にその計画の通りに走った実績を取ったりするようなチームが1つあります。
あと最適化チームと呼ばれていて、計画を作るときの問題を解くというのを専門にアルゴリズムを作っているチーム。
03:05
もう1つが経路探索チームと呼ばれていて、最適な答えが出ましたと。
次に最適な答えにさらにどの道を取ると最も良いかという、
経路探索をメインにアルゴリズムを組んでいるチーム。
最後にデータを管理するデータ基盤チームというのがあって、
地図のデータを整備したりとか、GPSのデータを整備したりとか、データ周りの基盤を作るチームがあります。
これらの5チームで1つのサービスを作っているという体制になっています。
なるほど。ありがとうございます。
5チームで27名エンジニアがいらっしゃるんですね。
で、古市さんが1人目のエンジニアリングマネージャーで今も1人なんですか?
そうです。まだ1人ですね。
なるほど。じゃあその5チームの全員を古市さんがマネジメントしているような感じなんですか?
ではなくて、自分が見ているのは計画を作る計画作成チームと、それを実行する計画実行チームの2チームを見ております。
なるほど。じゃあより画面があるような、画面を作っていくというか、
そっち系のユーザーに近いようなことをされているようなチームを古市さんがマネジメントしていて、
裏側のよりアルゴリズムヘビーなところというところは別の方が見ているような感じなんですかね?
そうですね。各チームにテックリードが在籍していて、実行チーム以外の4チームにそれぞれ専門の技術を持ったテックリードが存在しているので、
私が見ていないその他のチームはテックリードが同じチームのマネジメントをやっています。
なるほど。といったときに、改めて古市さんのエンジニアリングマネージャーとしてのミッションというか役割というかって、今はどんな感じなんですか?
まず1つ目は、この実行チーム最近立ち上がったばかりなので、このチームをしっかり機能させるというのが1つあるのと、
計画を作る側、実際にこのサービスの画面を提供している側は、たくさんの要望をかなりいただいているので、
これを対応していくためにチーム自体をもっとグロスさせていったり、より価値が発揮できるチームにしていく必要があるので、
まず注力すべきはその2つになっています。
なるほど。ありがとうございます。2つのチームは結構フェーズが違うということなんですね。
そうですね。違いますね。
ちょっとそこも伺いたいんですが、1つ目実行チーム、そちらはまだ立ち上がったばかりということなんですが、
そこでチームをうまく軌道に乗せていくために、具体的にどんなことをされようとしているんでしょうか?
もともと計画作成チームの中にこの実行文脈を一部含んでいたんですけれども、
06:03
複数の業務ドメインを1つのチームで見ていくのはかなり認知不可を含めて難しいものがあるといった話から、
実行チームを分離する形で今新しいチームを立ち上げています。
純粋に分離して2チームになったわけではなくて、別のメンバーも加わっての実行チームなんですけれども、
もともとチームを立ち上げるために人を集めてきたわけではなくて、
いるメンバーをあるドメインに分離して立ち上げたチームなので、
立ち上げ時点の苦労というか、全然知らない人たちを集めてよし今からゼロスタートだというわけではないので、
そこまでの立ち上げに関する苦労というか、これからゼロスタートしていくみたいな文脈はないですね。
なるほど。ある程度知っている人たちで、新しいチームでというところで、
コンテキストとか目標とかプロセスとかわからないですけど、
そういうところを整えるというような感じなんですかね。
そうですね。
ありがとうございます。
もう一つの分離された側というか、もともとあった計画作成チームの方。
こちらはすごくやることがたくさんあるということでしたけれども、
ここに対してはどんなアプローチで問題を解決されるとしているんですか。
そうですね。認知不可は多少これでチーム分離することで下がってはいるものの、
人数も分離した分減っているので、まずはここにメンバーを足していくことと、
そこにドメイン知識をつけていってもらわなくちゃいけないというのが非常に難しいというか、
そう簡単には覚えていけないというところがちょっとあるので、
もともと機能していたチームなので、それほど手を入れなくても自律的に動いてはいるんですけれども、
今今スケールさせていかなくちゃいけないというところが結構大きなポイントにはなってきているので、
そこに向けて下準備をしていくというか、
今いるところにメンバーを足しても同じように機能させていくみたいなところが一つポイントになっていますね。
なるほどなるほど。
じゃあまあとにかく捌ける数を増やすというか、
エンジニアを増やしてよりキャパシティを上げていくというようなところということだと思いまして、
さらにその裏側というか、増やすといっても簡単に増やせないというか、
その人たちにもドメイン知識を結構ちゃんとつけてもらって、
でワークするようになるというようなストーリーということだと思いまして、
そのドメイン知識っていうところも前半の時に結構いろいろ伺った中で、
単純にこう一つドメイン取っても難しそうですし、
なんかお客さんごとの違いみたいなところでさらに複雑性も上がってそうだなというふうに思うんですが、
09:05
なんかこのドメインっていうものをもう少し理解、僕自身が理解したくって、
具体的にどんな要素でドメインが構成されているとかって、
お話しできそうな範囲で教えていただくことってできますか?
そうですね、表向きのサービスのドメインとして計画が作るところがどうしても一番手前に来ているので、
この計画をお客様がどう作っているのかっていうのをまず理解をする必要があります。
それがお客さんごとたくさんあるので、
ここをいかに滑らかに吸収して実装に落としていくかっていうところが結構難しさがあるところに一つなっています。
やっぱり業務を覚える、お客様の業務がわからないと計画を作ることはみんな理解しているし、
どうやると計画が作られるのかも理解はしていても、
どう使うかっていうところが割と薄くなりがちというか理解しにくいところではあるので、
そこをいかに埋めていくかっていうところが一つポイントですね。
なるほど、なるほど。
そうですね、計画も僕自身想像がつかないんですけれども、
どうやって計画するのか、さらに計画されたものをどう使うのかっていうところですよね。
計画って一言で言ったときに、計画の中に何が出てくるんですか?
拠点、車とかどんな感じなんですかね?
そうですね、まず運ぶ人のドライバーが一つ要素としてありますと。
次に車ですと。
ただ物を運ぶときに車と人は一セットなので、
仕組みとしてはユーザーのマスターというか、
人が何人いて車が何台あってというのは別々の情報なんですけれども、
最適化からすると運ぶもの、それをキャリアと呼んでいるんですけれども、
車と人はセット、一つのものという概念で取り扱っています。
これ以外に運ぶ荷物。
荷物はどんな量を取り扱うかというのはお客様と違うので、
それが1個なのか、1キロなのか、あるいは1ダースとかいろんな単位で扱われるので、
荷物の量が分かる概念が一つあります。
それ以外にスポットと呼んでいるんですけど、
配送先の情報、物理的に移動経路でどこという情報だったり、
そこの場所の名前だったり、
あとはその場所に入れる時間、作業時間というか、
実際にこの場所でどれぐらいの作業時間を見込むのかとか、
そこで休憩するのかしないのかとか、
そういうパラメータも配送先にはあります。
それ以外に走る道路で行けば、
有料道路を使うのか使わないのかみたいな概念も必要だったりしますし、
12:06
あと宅配ですと、ある場所で荷物を受け取って、
ある場所で配達を下ろすということが考えられるんですけど、
それを1人の人が必ずやらなくちゃいけなくて、
Aさんが拾ってBさんがそれを届けるわけにはいかないので、
集荷と配送をセットで考える概念が必要です。
この場所では集荷しかしないし、この場所では配送しかしないという、
場所単位で見れば積むか下ろすかどっちかしかないんですけれど、
配送全体を見ると積んで下ろすということが発生するので、
その概念が割と複雑というか、
計画を作る上で同じ人にそれが割り当てられるようにしなければいけないみたいな、
そういう考え方もあります。
そのあたりが割と中心の概念というか、
ややこしさを持っていたり複雑さがあるところですね。
なるほどな。
計画を作るというときには、今出てきた概念を使って、
最終的にはエンジンの方が最適な順番だとかルートだとかを作っていくことになるんですけれども、
そのエンジンに渡すインプットを作るということですよね、計画っていうのは。
そうですね、そうなりますね。
だからどうなんでしょう。
さっきのお話だと、どこかでお昼ご飯を食べるとか休憩するとか、
そういったお話もあったんだけれども、
その辺はエンジンに渡す前にある程度入れられる情報っていうことなんですかね。
そうですね。
休憩も時間帯だけ指定ができるので、
あとはエンジン側でこの休憩時間を経路中のどこで取ると最適かっていうのはエンジン側が考えてくれるので、
この人は何時間休憩しなきゃいけないかっていう情報を渡しますね。
なるほどな。
そうですね、すごい細やかなところまでエンジン側が計算するってことですね。
そうですね、はい。
でもそのエンジンに渡すインプットも結構いろんな情報があって、
組み合わせ方とかもこういう組み合わせの計画っていうのはそもそもできないとか、
いろんなルールを満たしながらインプットを作らなきゃいけないということで、
そこはそこで、そのドメイン知識というところも深いものが必要ってことなんですよね。
そうですね、はい。
Greenにかけない転職裏話ラジオ、略してグリテンラジオは、
転職アプリGreenの運営メンバーが個人的一押し企業について語ったり、
現場で感じる転職や中途採用のリアルについて話す音声番組です。
毎週月曜朝6時更新です。
15:02
通勤や休憩時間のお供にぜひお聞きください。
詳細はカタカナで、グリテンラジオと検索してチェックしてください。
And now, a short commercial break.
って言ったときに、先ほどの話に戻ると、新しく入ってきた方に
結構深くそこをまずキャッチアップしていただくっていうことが必要そうだと思うんですけれど、
勉強会やったりとか、どんな感じでそのキャッチアップを促進していたりするんでしょうか。
基本的にはドキュメンテーションは割とそのあたりしっかりしているので、
まずは読んでもらうというか、どういう知識なり概念があるのかっていうのを
まず頭に入れてもらうみたいなところがあります。
それ専用に勉強会を用意することはしてないんですけれども、
新しいメンバーが入り次第、各チームで必要な考え方なり
概念っていうのを教えていくようなイメージにはなっています。
ここで一通り、初めて聞くような言葉だったり、
それが何を表すかみたいなことをざっくり理解してもらうっていうのがまず一つ。
それと連動したソースコード、
エンジニアであればソースコードも見てもらうほうが早い場合も多いと思うんですけれども、
得た知識と実際にそれがどうコードで表現されているかみたいなところを
まず頭の中で組み合わせてもらうみたいなところが最初のターンになります。
大抵の場合はそれでどういう作り、どう考えて何をしているのかっていうのは
概ね理解はできてくるところなんですけれども、
実際にどう使われているかとか、
お客様がわりと遠いというか、2Bのサービスであるがゆえというところはあるんですけれども、
実際に使っているところを見ることもなければ、
自分が普段の生活で配送計画を作ることもないので、
なかなかイメージしづらい部分というのはどうしてもあって、
我々のフロントエンドを作るチームであるがゆえに、
その辺りを保管する別の活動を今進めているところです。
そこは幸いなことに、我々の要望に色々応えてくれるお客様もいるので、
実際に現場に行くという機会を、
月何回かわりと高い頻度で訪問させていただくという場を今設けています。
実際に配車係が困っていることを聞いたり、
我々のサービスを使っている配車計画を作る時間帯に訪問させてもらって、
実際に作っているところを見て、何に困っているとか、
どんな使い方をしているのかというのをヒアリングしています。
合わせてドライバーさんにも話を聞いて、
実際どういう困り事があったり、業務でどんな使われ方をしているのかみたいなのは、
エンジニアも参加できますし、ビジネス側もデザイナーも、
18:01
人数の許す限り訪問させてもらって、
実際にそれを肌で感じて、実際耳で聞いてくるというようなことを1つやっています。
これ毎回人数が限られているので、
来た人と言うと、はいはいはいって手がかかるので、
じゃあ今回はこのメンバーで行きますみたいな形で今やっています。
これが1つ目の活動。
もう1つは実際に自分たちでトラックを借りて、運転できる範囲のトラックを借りて、
自分たちで計画を作って、
自分たちで指示されたルートを実際に走るということをやっていて、
本当にこの指示されたルートが走りやすいのかとか、
システムを実際に自分で触ってみてどう感じるかみたいなことを確認するのも、
これも定期的に実施して、
そういうところから実際の現場のドメイン知識を得たり、
利用状況を把握したりということをやっています。
なるほど。かなり今のお話は面白くてですね。
1つ目の現場を訪問するというのは、
これは多くの会社でもやられていることだと思うんですが、
特に2Bでおっしゃった通り、
普段使うようなシステムではないというところのものを、
いかに現場感を持って理解できるのかって、
すごい難しいところだと思うので、
行って見たり話したりするしかないという感じだと思います。
それは結構、今エンジニアの皆さんとかも、
みんな行きたい行きたいというふうになる感じってことなんですかね。
そうですね。非常に人気が、機会が少ないっていうのもあって、
できるだけ順番に行ってもらってはいるところなんですけども、
結構すぐ埋まってしまうというか、
はい、行きます行きますというところがあったり、
実際に運送会社に出向で行きたいぞとか、
本当にやっぱりなりきらないと理解できないんじゃないかという声も出るぐらいのところですね。
なるほど。エンジニアの皆さんもそこに課題感だったりだとか、
やっぱりいいものを作りたいみたいなところで、
そこを知りに行く必要があるんだというふうに、
皆さんこう思ってらっしゃるっていう感じなんですね。
そうですね。意識は割と高いというか、
この使っているところがイメージしにくいからこそ、
みんながそういう意識を持っているっていうのはありますね。
なんかそれってすごく放っておいて、
そういった状況になるってことはないと思うので、
ベースとなる考え方というかカルチャーというか、
そういうところで皆さんがそういう考え方になるような方向づけができてるんだろうなというふうにも思いました。
そうですね。わりと知りたい欲というか、
そういうことを知っているべきだというのはもちろんあるはあるんですけれども、
顧客への価値提供ということに強いこだわりというか、
よりお客様に使ってもらうためにはどうすればいいかみたいなことは、
自然と考えられる組織というか文化が、
私が入る前からできていたので、
21:01
結構自然と、私が何かしたというわけではなく、
もともとそういう意識が高い組織だったというところがありますね。
でも最初から多分会社にそういうものが経営者だったりが、
そういった考えだったりを持っていらっしゃって、
それが自然に広がっているとか、
そういうことなんだろうなというふうにも思いましたので、
すごくいいカルチャーだなというふうに思いました。
社長の松下が現場100遍という言葉を掲げていて、
現場にこそ答えがあるというか、
そこに行くことに意味や価値があるよということを、
ずっと言い続けているというところがあって、
それが結構浸透しているのは大きいですね。
なるほどな、そこは一番の肝でしょうね。
やっぱり社長がそういった言葉でもって何度も多分おっしゃっているんでしょうし、
多分実践もされているということだと思うので、
それは確実にカルチャーになっていくものですよね。
そうですね。
ありがとうございます。
2つ目の方もめちゃくちゃ面白いなと思いまして、
トラックを借りて実際に回ってみるっていうのは、
これ実際にやってみてどうなんですか?
おかしいなみたいな感じだったりするのか、
いい感じに回れたとか、
そもそもトラックを運転することができたりするんですかね、
大きめのトラックとか。
運転できるサイズなのでそんなに大きいものではないんですけれども、
1個あるのはやっぱりドライバー視点で運転してみないと分からなかったりするので、
ナビで指した停車位置が本当に止めやすいのかとか、
この道幅だとやっぱり走りにくいよねとか、
案内された道路に対して感じるものはあるので、
その点はすぐシステムにフィードバックしたりすることが多いですね。
じゃあどちらかというと、できた計画のそれ自体の使いやすさというか、
いうところを自分たちでも試しているっていうようなニュアンスなんですかね。
そうですね。計画を作るのはパソコンでやるので、
それは普段から自分たちで使うことはできるんですけど、
出来上がったものがどうだったかという、
この結果が大事なところが本当に時間通りに走れるのかとか、
その辺はやってみないと分からないところを身をもって体験しているところですね。
なるほどな。
それって多分ビジネスだったり会社によっては、
最初から自分たちがそういうユーザーであるところから
プロダクト作りを始めたりされるところもあって、
そういうところは自社の中でそういったPDCAを回しやすかったりもするんでしょうけれども、
全ての会社がそれができるわけじゃないので、
そういったときに自分たちでもユーザー側と同じことをやってみるって、
結構王道のパターンとはいえ、
全ての会社ができていることでもないとは思うので、
そこまでやってらっしゃるのって、
先ほどの現場100編でしたっけ?
24:01
っていうふうにおっしゃられていたことの、
表れの一つなのかなというふうにも思いまして、
徹底してるなというか、
そこまで会社として予算もつけてやってらっしゃるということだと思うので、
すごくいい活動だと思いますし、
エンジニアも参加されているということだと思うので、
現場を知るというか、自分たちのプロダクトを知るという意味でも、
めちゃくちゃ効果のある取り組みなんだろうなというふうにも思いました。
じゃあそういったことをしていくことで、
エンジニアのオンボーディングというか、
ドメイン知識を身につけていくというところは、
ある程度道具としては揃っているという感じなんですか?
それともまだまだそれ以外にもやらないと、
チームで100パーワークするみたいにならないのかというとどうなんでしょうか?
そうですね、どうやったらもっと短時間でそれができるのかというのは、
チャレンジしていかなくちゃいけないというか、
いまだに答えは見つかっていなくて、
どうしてもある程度時間が必要というか、
すぐに吸収できない部分はあったりするんですけど、
足らないっていうことは今のところないんじゃないかなと思っていて、
あとはどう時間を短縮するかみたいなところはまだこれから考えてくるところですね。
なるほど、そうですよね。
確かに今話したような内容だと、
お客様のところを訪問するチャンスがそんなにたくさんあるわけでもなさそうだし、
行きたいって言ってすぐにやれるものでもないと思うので、
時間はかかるっていうことなんですね。
それは当然でしょうね。
でも、いろいろなやり方で短縮していくこともできるんでしょうし、
何かビデオを撮っておいてみるとかもあるかもしれませんしね。
でも、より多くの人がそういった体験をして学んでこられたっていうことだったら、
チームメンバーからの学びも結構リアルな声としてインプットを得られるような気もするので、
それがどんどん増えていけば、より学びが加速度的に早くなっていくのかなというふうにも思っていました。
そうですね。
実際にゲームオンラインの写真を撮らせてもらったり、
動画でも大丈夫っていうお客さんもいたりするので、
そういう貴重な情報は社内にナレッジとして貯めて、
後でみんなで見たりということができるようになっているので、
その辺は結構助けられているというか、
言った人しかわからないみたいなことにはまだなっていないので、そこは嬉しいところですね。
ドメインに関しては非常に面白い取り組みを聞かせていただいてありがとうございました。
そんな感じでスケールさせていくための布石を打ったりもされているということだと思うんですが、
実際それ以外にいざ2倍になってもいいぞみたいな感じなのか、
とはいえ何か別の課題とかがあるのかというとどうなんでしょう。
27:03
そうですね。ある程度のサイズであれば、
人数増えてもおそらく大丈夫であろうとは思いつつも、
今チームの面倒を見ているのがテックリード兼チームリーダーが見ているので、
チーム増やしますとかチームが10人になりましたってなるとリーダーを用意する、
テックリードを増やすっていうのはそう簡単にできることではないと思っているので、
そういったときにチームをまとめられる役割もセットで人数が増えないと、
単純に人を足してもおそらくすぐスケール次第というかボトルネックが表に出てきてしまうなという課題はありますね。
そうですよね。リーダーっていう人がいてチームがあるっていうような構造を取られているっていうことだと思うので、
リーダーも増えなければスケールしないっていうことですよね。
リーダーの方、テックリードってなればよりテックに強いっていう部分があると思うので、
相当な時間をかけないとそういう方々が育ってこないというか、
現れてこないっていうことだと思うんですが、それとは切り離したチームのリーダーっていったときには、
そういうリーダーってあり得るのか、まとめ役としてのリーダーっていう形だけっていうのは存在できそうなんですか。
一応今1チームだけ公式というかチームリーダーとして役割を持った人がいて、
そこが今うまく機能しているようなので、おそらく方向性としてはありだなというふうには思っています。
各チームにリーダーシップを発揮できるメンバーっていうのはいるので、
そういうメンバーを起点に増やしていける可能性は十分今あると思っているところですね。
ちなみに改めてテックリードっていう要素を切り離したチームリーダーの方っていうのは、
どんな役割を持った方になっていくんですか。
そうですね。まずチーム運営というか、スクラムしているならスクラムイベントをしたり、
各メンバーの日々の運営をある程度任せられるっていう役割が1つあります。
テックリードと大きな違いってそれほど出てこないなとは実は思っていて、
技術的に何かを決めなくちゃいけないとか、難しいことを相談しなきゃいけないときにはテックリードが出てくるんですけども、
チームリーダーだから何か違いがあるかというと、それほど大きく差はないかなというふうには思っています。
レビューもしますし、基本的なチーム内での決め事を決めていく力も必要ですし、
チームリーダーだからこの役割ですっていう切り分けを実はあまりしたくない。
各チームに、本来はあなたはチームリーダーだからこういう役割をしなさいみたいに仕向けるよりは、
30:03
チームが自発的にリーダーシップを発揮して誰かがその役割になれるっていう状態がいいのではないかというふうには考えていて、
あまりこの役割はこの人だからこの人にっていう集中するようなやり方はあまりテックリードとかチームリーダーだからっていうのを
抜いてもやっぱりスケールしにくいんじゃないかなというふうには考えているので、
結局分けても同じでしたにはならないように今考えないといけないんだろうなと思っているところですね。
なるほど、今最後の方のお話ってもしかすると古市さんご自身の美学というか、こういう動きをみんながした方がいいんじゃないかっていうような考えが
現れているところなのかもしれないなと思ったりもしたんですけども、そうではないですか。
そうですね、個人的に自分が考えるチームのいい状態っていうイメージはあるんですけど、
それが答えではもちろんないし、今の組織にそれが合うかどうかっていうのもまだまだこれから見ていかなくちゃいけないところがありつつも、
自分としてはおそらくこれが理想の形だろうみたいなイメージは今できてはいるので、
そこに近づけるのがいいのか、それをもとにもっといい方向を目指すのがいいのかみたいなのはまだ試行錯誤するところですね。
そうですよね、必ずしも自分の理想みたいなのが正解ってわけでは当然ないとは思いつつも、
でも僕自身もやっぱり自分が考える良いチームのあり方とか、エンジニアの動き方っていうのはやっぱりベースとして持ちながら、
それと会社のカルチャーだったり、会社の戦略みたいなところと沿わせながらミックスしてあり方を考えるってことをやったりするし、
そういうのがマネージャーとしての良いやり方だよなとも思っているので、
古市さんがご自身の哲学というところを背後に持ちながらどう適応していくのかっていうのを探ってらっしゃるようなお話が聞けたので、
そこはいいなというふうに思いました。
ありがとうございます。自分のチームだとか、私のチームだからみたいな意見というか、そうじゃないよなと。
エンジニアマネージャーってチームを下から支えるような、チームのためのEMであるべきっていうふうには思っているので、
いかに自立してもらうかとか、それが機能させるにはどうするべきかみたいなことは常々考えつつも、
自分がこうあるべきだみたいなのを推し進めるのも違うと思っているので、
そこはうまくなじませていくところがやっぱりマネージャーの腕の見せどころというか、必要とされるところだろうなとは思っていますね。
33:03
確かにもう完全に同意しかないですね。
僕自身も若気の痛いとかで、こうあるべきみたいなことでマネジメントをしたこともあるんですけど、
大抵そういうのってうまくいかないので、いかにチームメンバーだったりチームそのものだったりっていうのを
よく観察して見つめて、そこに必要なものをうまくマネージャーとしてサポートするような形で導入していくとか、
そういう感じではなく、導いていくっていうか、助けてあげるっていう。
そんなような形でやっていくのがやっぱりいいですよね。
そう思います。
ありがとうございます。最後に古石さんのマネジメント感みたいなところも聞けて、すごい良い回になったと思っております。
この2回を通していろいろオプティマインドさんの事業だったり、
あとは組織のことだったり、マネジメントのことをいろいろ聞かせていただいてありがとうございました。
ありがとうございました。
古石さん、今回もありがとうございました。
ドメインに関するお話っていうところで、かなり面白い話を伺えたなと思ってまして、
現場に行くお話っていうのは当然他の会社さんでもやられていることだし、
オプティマインドさんでもやってらっしゃるということで、ここもすごく面白かったのと、
あとトラックに自分たちで乗って走ってみるっていうのは言われてみたら当たり前かもしれないんですけれど、
なかなかそこまで会社としてやれているかというとそうではないと思いますので、
そういったことが社長ご自身の考え方だったり、それが組織の中に根付いているといったところも含めて、
すごく面白い取り組み、面白いカルチャーが醸成されているんだなというふうに強く感じました。
またそれ以外でも古市さんご自身のマネージャーとしてのチームの相方というか、
こういうふうにみんなが動いてほしいみたいなところのお考えも聞けて、すごくいいお話を伺えたなと思っております。
古市さんとプロダクトを通してお客様ごとの現場とどう向き合うのか問題についてお話しした前回のエピソードもぜひお聞きください。
さてこの番組では感想や質問リクエストなどお待ちしております。
番組詳細欄にあるリンクよりお気軽にご投稿ください。
TwitterではハッシュタグEM問題集をつけてツイートしてください。
EMはアルファベット、問題集は漢字でお願いします。
そしてAppleポッドキャストやSpotifyのポッドキャストではレビューもできますので、こちらにも感想を書いてもらえると嬉しいです。
お相手は株式会社株区スタイル、COO兼CTOの後藤秀典でした。
