00:00
ITトリオのお時間です。
はい、本日は私の現職の大先輩、元上司であるケイさんをゲストにお迎えして、
エンジニアリングマネジメントの相談会というテーマでお話ししていきます。よろしくお願いします。
お願いします。
はい、なべちゃんがずっとエンジニアリングマネジメントに悩みを抱えているということで。
そうですね、本当。
ずっと裏では話していたんですけど、そこで相談相手として私の元上司、元上司で大先輩のケイさんがきっと相談に乗ってくれるであろうということで、
ゲストに呼ばさせていただきました。
はい。
はい、ということでそんなケイさんの自己紹介からまずよろしくお願いします。
はい、チーズの先輩、上司、ケイです。
ITベンチャーでエンジニアリングマネジャーを今はやっています。
マネジメントをやり始めてからは大体3年くらいですかね。
3年なんですね、結構長い。
一部本当のエンジニアリングマネジャーというよりかはリーダーみたいな感じでやってた時期もありますけど、でも軸足をマネジメントに移し始めてからはそれくらいかね。
エンジニアとしては元々レールズエンジニアとしてキャリアが始まって、バックエンド、インフラ、フロント全体的にやって、それから今の会社の開発拠点を立ち上げるっていうミッションをきっかけに本格的にエンジニアリングマネジャーになっていったっていう。
レールズエンジニアのイメージは全然ないんですけど、最初はレールズだったんですね。
レールズでしたね。大学生の時とかは何ならアプリ作ったことなくて、Pythonでデータ分析とかそういうことしかやったことなかったところから、社会人になったタイミングでアプリの開発にがっつり入るようになって、レールズ書いてましたいっぱい。
私も知らない姿でしたね。
そうなんだ。
そこまで昔のことはあまり知らなかったので、そんなケイさんなんですけど、マネジメント歴3年ということで、なめちゃんにとっては大先輩だよね。
大先輩です、本当。僕がもう半年しかまだ経ってなくてっていう感じなんで、もう本当に何年も上の先輩ですね、本当に。
なんか照れるな。
なんでちょっといろいろ教えてもらえたらなと思ってます。
私も聞きたい。
早速なんですけど、今日2つお題というか聞いたこと持ってきてまして、1つ目がマネジメントの時間配分っていうところで、よくエンジニアリングマネージャーっていうのは4要素でテクニカル、テクノロジーですねと、
03:03
ピープル、プロダクト、プロジェクトっていう形で、4要素のマネジメントがあるような話がよくされると思うんですけど、その中でどれを優先して時間を使うのかみたいなところ。
これケイさんは大前提あると思うんですけど、この優先順位どうやって決めてるのかなっていうのをちょっと聞いてみたいなと思ってます。
これが1つ目で。
1つ目がピープルのマネジメントっていうところで、人の成長を見込んでいろいろマネジメントを考えていくとは思うんですけど、それを僕らの会社の場合は半年間で計画を立てるんですけど、
どういうプロダクトを作るかとか、どういうふうに人が成長するのを見込んで考慮するのかみたいなところも含めて半年間の戦略を練るんですけど、
それをどういうふうに見込んでるか、人の成長をどれくらい見込んでプロダクトに落とし込んでるかみたいなところをちょっと聞いてみたくて。
っていうのも、僕自身本当はこれぐらいの短いスパンでこういうプロダクトを作ってほしいみたいなことがあるんですけど、
ただそのスパンだとちょっと今のメンバーのスキル感だとちょっと間に合わないかな、足りないかなみたいなことが結構あったりしてて、
そこをピープルマネジメントで成長促進させて穴を埋めていくみたいなところが僕らがやることかなとは思いつつも、
その差分をどこまで半年間の企画の中にあらかじめ入れ込んでおくのかみたいなところを、
ちょっと僕の中で折り上げがまだつけられてなくて、その話をちょっとしてみたいなっていう感じですね。
なるほど、なるほど。メンバーの私には結構難しい話でしたね。
マネージャーにならないと意識しない。
そこの視点まで上がらないとね。
はい、まずは一つ目の時間配分に関してですね。
長嶋さん、じゃなくてケイさん。
マネジメントね、まずマネジメントって言ったときに、
とりあえずピープルとプロジェクトとプロダクトとテクノロジーとその4つ指すっていう前提で話したときに、
僕の場合はやっぱり自分の監督してる組織のフェーズによってかなりこの配分って変わってきたなっていうふうに思ってます。
当たり前ですけど、やっぱり最初の立ち上げ時、僕マネージャーになったタイミングってメンバー0人のところから始まったんですよね。
すごい。
まずは仲間集めから。
そうそうそう。
プロダクトないプロジェクトを見て、だけど組織は作るっていうのは決まっていて。
新しいな。すごい新しいですね。
だったから、いろいろ同時並行で走らせてはいたけども、やっぱりピープルのマネジメントに最初は多分8割方ぐらいのリソースを割いていて、
06:08
もちろん最初に作るものとか取り組むプロジェクトっていうのをゴールみたいなものを決めた上で、
それに適した人を取るってできれば美しいとは思うんですけど、
なかなか現実層はうまくいかないというか、
誰が入ってきてくれるかによって任せてもらえるプロジェクトとかっていうのは結構左右されるし、
どういうプロジェクトやるとうまくいくかっていうの差が出るので、
まずは可能な限りいい人を取るために全身全霊尽くすみたいなフェーズが、
1年ぐらいかな、続いてましたね。
結構長い時間。
でした。
ここから僕が運が良かったこともあるんですけど、
時メンバーがやっぱりその後の自分の時間配分をめっちゃ左右するなと思っていて、
最初の2人3人ぐらいでめちゃくちゃいい人を取れていたら、
どっか先、いろんなマネジメント領域でいろんなこと忘れてよくなるんですよね。
一番忘れてよくなるのがプロジェクトのところとかテクノロジーのところ。
だから今はもういいメンバーがそれなりの数も集まったし、
僕の後をついでリーダーをやってくれてる人とかもいるので、
プロジェクトとテクノロジーのところもそうだし、
プロダクトのところもいいPDMがいるので結構もう要素は使ってなくて、
ピープルもある程度組織が細かったので、
採用というよりかは機体位置調整とか目標設定とか、
今いるメンバーに最大限高いアウトプットを出してもらうための仕事だけに集中しているという状態で、
時間配分どんなものって言われたときの答えになってるかわかんないですけど、
ピープルが最初めちゃくちゃ高かった上でどんどんどんどん下がっていってるっていうのが今。
なるほど、最初ピープルにすごい時間かかってたときって特にどんなこと注意してました?
どんなこと考えてました?
最初はピープルマネジメント、採用自体も本気で自分でゼロから組織全部作るっていうのは初めてだったんで、
一人目誰を取った方がいいみたいなそんな自信を持ってやっていたわけでは全然なくて、
すごい手探りだったんですよね。
ただ、すごい経験のある人だけで固めた方がきっと成功確率は上がるとは思ったんですけど、
僕はあえてそれを選ばなかったんですよね。
この人はすごい伸びるポテンシャルがあるだろうなって思う人もそれなりに比率としては多めに入れつつ、
09:06
とはいえきっとこの人はいざって時に背中を預けられるっていうようなナンバー2みたいな人はちゃんと確保しつつみたいな
ちょっとは気をつけてやってて、当時はそれがうまくいくかって全然確証もてずにやってたんですけど、
今になってみて思うのは正しかったなって。
おーすごいですね。一発目で良かった。
本当に良かった。
ポテンシャルを感じた人っていうのはスキル的に伸びるポテンシャルを感じてたっていうだけじゃなくて、
マインドセットが良い人を取るっていうのは気をつけてました。
素直で当事者意識がすごく高そうな人。
そういうタイプの人は結果的に今振り返ってみたときにものすごい伸びていて、
採用時点ではこっちの人の方が経験とかスキルとかあっただろうなっていう人に普通に追いついてきてることとかもあって、
なので、真っ当に考えるとハイスキルで経験ある人で固めた方がいいと思うんだけど、
その一定、冒険してみるというか、ポテンシャルに信じてみるみたいなことをやるのもすごく大事だったなって。
素直で当事者意識がある人って、面接って30分とか1時間しかない短い時間の中でどうやって見極めてますか?
いい質問ですね。
いい質問来ましたね。
めっちゃ難しいんですよ。
難しいですよね。
僕も面接で話題するんですけど、いつもちょっと難しいなと思いながら。
なんかでも、僕、面接とか面談とかするとき、見極めようみたいな意識ではあんまやってなくて、
助けてほしいんですよと、僕のことを。
っていうので、本当にこの人は自分のこととか、僕の持っているプロジェクト、プロダクトのことを何とかするために必死に考えてくれるだろうかみたいな、
そういう見方だけしてますね。
結果的にマッチする人っていうのは、アプローチの仕方の良さとかももちろんありますけど、やっぱ真摯に向き合ってくれるし、
ただ経験に基づいて物を言うとかってだけじゃなくて、ちゃんと僕のチームの状況だとか、プロジェクトの状況だとか、
いろいろ踏まえた上で、その状況に合わせてしっかり考えてくれたりっていうのがあるので、
12:05
そういう人はやっぱり素直さ、誠実さみたいなのがあった上で、ちゃんと考え抜いてくれる当事者意識があることが多いのかなって気はしますね。
なるほどなるほど。そこで1個聞いてみたいんですけど、当事者意識って後からでも身につくと思います?それとも全然的な感じですか?
はいはいはい。でも全然後から身につくと思います。
思うし、なんか当事者意識の身につけ方っていろいろあるとは思うんですけど、
今自分の身の回りで、この人めちゃくちゃ当事者意識上がったなって思う人は、
ちょっとこれ言い方がすごい難しいんですけど、
こういう話難しいですよね。
当事者意識ないというか、あちこちボールが落っこちているプロジェクトとか組織とか、
そういうのはやっぱあると思うんですけど、そういうところのことも見せてあげるというか、
ちょっとやっぱ上手くいってないっていうのはどういう状況なのかっていうのを味合わせた上で、
でもこれ何とかしたいじゃん、どうしたらいいと思うっていうのを一緒に考え続けるんですよね。
っていうのをずっとやってたら、結果的にものすごい当事者意識高くなった人とかは周りにいますね。
なるほど、なるほど。
自分もそれすごい大事だと思っていて、マネージャーの人たちって一見すると、メンバーからすると、
色が高いものだと思っちゃうと思っていて、僕は。
色が高い人が振る舞いによって、これは見て見ぬふりしてもいいものだとか、
あるいは当事者意識持ってやらないとダメだとか、一緒にやってくれる感、
最悪困った時尻拭いてくれるかみたいな話とかも、
そういうマネージャーによって安心感とか、どこまでやっていいんだみたいなのって結構違うかなと思って、
余計なことやるとダメかもって思っちゃうパターンとかもあるわけじゃないですか。
そこら辺のマネージャーがどう振る舞いをするかっていうので、結構メンバーの振る舞いって僕すごい変わるなと思ってて、
なので僕も当事者意識は鍛えられると思っているんで、
そういう自分からちょっとメンバーに寄り添う形で一緒に成長していきたいなっていう思いがすごくあるっていうのはありますね。
このね、私もともとKさんが上司だったよっていうのをさっき話したと思うんですけど、
本当にKさんは信じて任せてくれる人だなって思ってて、
15:05
私以前の放送で、自分はフロントエンド、デザイナー出身でフロントエンドしかやってなかったけど、
バックエンドにもチャレンジしましたみたいな話をしたと思うんですけど、
それをやってみればって言ってくれたのはKさんなんですよね。
私がやりたい、やりたいって言ってたのもあるけど。
最初はめちゃくちゃ苦戦してても、まず任せてくれて、
分かんないところは真摯に向き合ってくれてっていうのがあって、
そういうことを繰り返してもらえたからこそ、多少たりとも私も当事者意識を持てたというか、
そういうところはあるかなと思ってて、
Kさんの話も今のなべちゃんの話もすごい、メンバーとして踏み落ちたところがありましたね。
実体験等にね。
やっぱりなるべく難しい課題だとか、ちょっと辛い状況だとか、
そういうところにちゃんと真正面から向き合わせた上で、
なるべく並走してあげる、それに尽きるのかなって思います。
なるほど、並走していって、そうすると一人一人のスキルも高まってきて、リーダーシップも高まってきてってなると、
ピープルから徐々に手が離れてきてっていうところで、今ってどこら辺がメインなんですかね、マネジメントの割合で言うと。
今はプロジェクトマネジメントです、一周回って。
その意図というのは、プロジェクトマネジメントが指す範囲って人によって結構変わるなと思っていて、
いわゆるスケジュールマネジメントみたいな狭い部分だけ指して言う場合もあれば、
もうちょっと広いコストだとか、他の要素もいろいろ考えた上で全部をコントロールするのがプロジェクトマネジメントだっていう人もいると思うんですけど、
僕最近プロジェクトマネジメントのことを不可能マネジメントだなっていうふうに。
ちょっとわかる気がします、それ。
なんか伝わるかな、要するに簡単なプロジェクトなんて一つもなくて、
大抵どっかに不可能でしょって言いたくなることってあるんですよね。
けどそれを何とかするためにあらゆる手を尽くすのがプロジェクトマネジメントであって、
ただチケット管理したりだとかカントチャートをきれいに整備するとか、そういうことがプロジェクトマネジメントではないなって、
最近すごく身に染みて感じています。
なので、不可能マネジメントをするのが今の自分の仕事だって思うと、
自ずとそのピープルの要素もテックの要素もプロダクトの要素も全部総動員して戦う必要があるんで。
18:03
そうですね。
なので一周回ってプロジェクトマネジメントの比率がすごくたまる。
その中にいろんな要素が全部含まれてるみたいな感じかもしれないですね。
軸があるみたいな。
それはすごくわかりますね。
プロジェクトがどれぐらいの流度を指すのかわからないですけど、
自分の経験でいうと、やっぱりこういうことやってみたいなイメージだけあるみたいなパターンが結構あって、
そのイメージに対してやっぱりそもそも具現化しないといけないし、
具現化したとしても、そもそもその具現化するためのスキルが足りないとか、人が足りないとか、コストもかかるとか、
そういうのがいろいろある中で、しかも仕様を決めるためにいろんな関係者がいて、
誰に仕様を最終的にフィックスしてもらえばいいんだみたいな話とかもあったりして、
そこら辺を一つ一つ決めていって、
一個一個地道に手探りで本当に一個一個決めていって、
最終的にある程度いろんなものを決めていくと形になって見えてきて、
プロジェクトうまくいけそうみたいな感じでやっと進められるみたいなことが結構あって、
本当に最終不可能なところから、どれだけ可能性を上げていくかみたいなところって、
すごい今まで自分の経験の中でもあって、不可能マネジメントという言葉は確かになっていうのはすごく思いました。
伝わってよかった。
これケイさんが作った造語なんですか?
これは勝手に言ってます、僕は。
この界隈で言われてるのかな、みたいな。
全然聞いたことない。
そういうわけではない。
聞いたことないかな。
それはすごく思いますね。
ITトリオ。
あとあれですね、プロジェクトマネジメントにリソース入ってるんですけど、
プロジェクトマネジメントうまくやる上で、さっきの、
People、Project、Product、Technologyの要素でいうところの、
テクノロジーがやっぱなんだかんだ言ってめっちゃ大事なんだなっていうのも、
最近すごい痛感していて、
いわゆるEMって呼ばれる人たちって、
なんていうのかな、
なんとなくスペシャリスト度を諦めたみたいなふうに思われることが多いような気がしていて。
そういう話もありますね。
そうじゃない人ももちろんいると思うんですけど、
やっぱりジェネラリストを目指しているからEMに行ったんだっていうことが結構多く感じていて、
なんですけど、
これまで自分が出会ってきたガチで優秀なEMみたいな人たちって、
スペシャリスト並み、何ならそれ以上ぐらいの技術をわかっている人が多くて、
21:04
技術がわかっているから、当然プロジェクトの中の不確実性のコントロールだとか、
不可能マネジメントみたいなところも、
すごい高い精度でうまくやれてるし、
技術がわかっているから、
プロダクト作る上でもうまいこと、最新の技術とか面白い技術とかっていうのを取り込みながらやってるから、
採用もうまくいくし、
採用がうまくいってるからいいチームできて、
いろんなサイクルがよく回ってみたいなところで、
いろいろとできてるなと。
なので、
僕は今EMですけど、
テクノロジーのところは絶対に最後まで諦めないぞっていう気持ちは続けてますね。
なるほど、
それは僕もすごい痛感したんですよ、最近になって。
すごい痛感した時事があって。
やっぱり僕半年前にマネジメントになったんですけど、
その時にプロダクトもリセットされて、
テクノロジーの部分の、
今まで長くやってたからこそ分かってた、
ソースコードの細かいところの仕様とかまで分かってた部分がリセットされちゃったんで、
技術的にはもちろん同じRails使ってるんで、
理解はできるんですけど、
ただそこら辺の細かい部分のテクノロジーまではちょっと分かってなくて、
今プロジェクトの中で、
塞がすごい積み上がってるみたいな話とかもあったりした時に、
じゃあその塞をどうやって解消しようかみたいな話の時に、
僕はそこの塞までの奥深いところまでのレイヤーの知識が、
今までそこを開発してきたわけでもないから、そんなになくて、
それをマネジメントするってなった時に、
塞解消の結果を立てないといけないんですけど、
でもどうやってここを立てるのかみたいな。
やっぱりそこのテクノロジーの部分って自分の中ですごい痛感したというか、
ここをちゃんと理解しないとマネジメントできないぞこれと思って、
それを本当にヒアリングしたりとか、
自分でいろいろソースコードを打ったりとか、
やっぱりそうやってやった方が絶対に計画も立ちやすいし、
詰まってるところとかもフォローしやすかったりとか、
どういうふうに調子したらいいかって見えてくるから、
すごいテクノロジーは大事だなって痛感したっていうのは最近ありました。
そうですよね。
けいさんと一緒に働いてて思うのは、
どんだけテクノロジー部分をメンバーに任せてくれても、
いろんなところでちゃんと情報キャッチアップしてて、
いざ大事なところは声かけてくれるんですよ。
ここもいいんじゃないかとか、ここ考えた方がいいんじゃないかって、
シュッと急に現れて、シュッと大事なこと言って、
シュッと帰ってくるみたいな。
かっこいい。
あれ、それってテクノロジーを極めたからこそ、
このプロジェクトに対する知見があって、
24:02
未来を見据えてるからこそできるところだなと思ってて。
いつも、あ、すごいって。
すごいですね、それは。
すごい、こうなんですねって。
よくなってる。
やっぱりEMとしてステップアップすればするほど、
どんどんどんどん不可能を可能にせっていうミッションが
飛んでくるんですけど、
不可能を可能にするためのすごい重要な要素が
テクノロジーなら間違いなくて、
不可能マネジメント力の厳選はやっぱりテクノロジーだよなっていうのは。
そうですね、本当にそれ思いますね。
ちょっと次の話行ってもいいですか。
もちろん。
ありがとうございます。ちょっと話変わっちゃうんですけど、
2個目のPプラマネジメントのところで、
ちょっと続き聞いてみたくて、さっきテクノロジーとか
いろいろ大事な話とかされてくれたと思うんですけど、
そのテクノロジーのスキルって
いっちょいステキではなかなか身につきづらいかなと思っていて、
で、そのメンバー、
僕らの会社の場合は半年間で計画を立てるんですけど、
その半年間で、今って自分は
メンバーのスキルが成長するかどうかっていうのは
一定は見込むんですけど、そんなに大きく見込んでない計画として
結構作ることが多いんですけど、
そこってそもそも、けいさんは
どこまで人の成長を入れて計画立てていますか?
はいはいはい。これはなんかね、
マネージャーのギャンブラー精神というか、
そういうのが多いと思われるとこかなって思っていて、
で、僕の考え方は、
この人はこのぐらいの期間で
ここまで伸びるだろうから
このプロジェクトにアサインするとかではなく、
この伸びるだろうじゃなくて、
もう伸ばすんだっていう前提で、
伸ばそうと思ったらこのプロジェクトに突っ込まないとダメだっていう
アサインの仕方をしています。
それメンバーからするとめちゃくちゃ嬉しいと思いますね。
心当たりがいろいろあるな。
なるほど。
すごいギャンブルだとは思うし、
大前提、マネージャーがちゃんとフォローできるだけ
全技術領域に精通している必要性とかもあるので、
スキル高くないとできないと思うんですけど、
もうそれでうまくいったら、
やっぱり一番みんな幸せになれると思っていて、
今まで本人は到底できないと思っていたプロジェクトとかを
自分主体でやってみて、
すごいスキルも伸びて、プロジェクトも成功して、
次もっと難しいプロジェクトに任せてもらえてみたいな、
27:02
一番幸せ。
それやろうと思うと、伸びるだろうなみたいな予想だと、
やっぱり難しいなって思うんですよね。
それで実際結構うまくいかなかったなってことは結構ありましたね。
だし伸ばすって決めてアサインしてしまうと、
マネージャー自身も絶対にミスってるわけにいかんというか、
フォローしきらないとそのプロジェクトがやばくなったりもするので、
真面目に絆創するようになるというか、
マネージャー自身のお尻を叩くためにも、
伸ばすためのアサインっていうのは大事なのかなって思います。
ちょっと一個意地悪な質問してもいいですか。
その前に、マネージャーの力量に作用されるかなと思ってて、
マネージャーの能力がチームの成長限界にならないかみたいなところってないのかなと疑問に思ったんですけど、
ごめんなさい意地悪な質問です。
いや、あると思います。
もちろんマネージャーがボトルネックにならないようにできると、
いいのかもしれないんですけど、
でもやっぱり組織ってトップの人以上の器にはならないというか、
っていうのが僕のただの経験論ですけど、
そういうふうに思っていて、
なのでやっぱりマネージャーは最強であるっていうのを諦めずに目指すべきなのかなって。
すごいいい話聞けてると思います。
それ聞けたら僕はすごい嬉しいなと思いましたね。
結構そのマネージャーって、
メンバーを信頼して任せるといえば聞こえがいいですけど、
自分の能力じゃなくてメンバーの能力でとにかくなんとかするマネージャーも結構僕はいるかなと思っていて、
もちろん別にそういうマネージャーを否定するわけではないんですけど、
テクノロジーとかちょっと半ば諦めてるみたいなケースって結構あったんですよ。
そうなった時にやっぱりこう、当時メンバーの時にやっぱりそのテクノロジーも相談したいなとか、
そういうのはすごいあって、やっぱり相談できないからちょっと俺流でやるしかないなみたいな、
ちょっと色々こう調べてやってみるって感じだったんですけど、
でもなんかやっぱりそういうのも相談できる方がすごいもっと上手くいっただろうなとか思う機会とかもあったりして、
常にマネージャーが最強であるっていう姿勢を見せてくれるのって、
メンバーからしたらなんて心強いんだろうってすごい思うなって。
うん、うん。
もちろんね、マネージャーに多くを求めすぎだみたいな意見もきっとあるだろうなと思うんですけど、
30:04
まあでもその分ね、高い期待かけられて、といい友情ももらって頑張ってるわけだから、
まあ最強を目指すべきなんじゃないって僕は思います。
いいですね、それ。
なるほど、なるほど。
確かにな。
すごい、けいさんの発言に重みを感じましたし、
なんか私にとってはけいさんって本当に相談したくなるような最強な存在だったから、
だったかなっていうと過去形みたいなんですけど今でもそうで、
そういう信念からあるんだなっていうのが聞けてニヤニヤしちゃいましたね、私も。
そうなんですよ、あんまりそういうのメンバーには言ってないかもしれないですね。
勝手にそういうマインドで僕はやってましたね。
かっこいい。
すごいな、ちょっとそのマインドは僕も継承していこうと思います。
そんなマインド最強なけいさんなんですけど、
なんか私にとって、いわゆるメンバー層の私にとってとても話しやすい存在なんですよね。
なんか結構私の経験上、マネージャーってやっぱ上の人だから、
牙って喋りに行かなきゃとか、準備して喋りに行かなきゃみたいな感覚に陥ることが多くあったんですけど、
なんでこんなにけいさんって相談しやすいんだろうっていうところで、
なんかメンバーとのコミュニケーションで気をつけてることとかってあったりしますか?
はいはいはい、まずなんかめちゃめちゃ褒められててちょっと照れてるんですけど、
そう、気をつけてることか。
でもなんかそんなに普段から気をつけて喋ってるわけじゃないですけど、
一個思うのは、マネージャーだからこういう振る舞いしなきゃいけないみたいなのって、
マネジメントをやり始めた頃とかって意識すると思うんですよ。
例えばプロダクトマネージャーだったらそのプロダクトのこと誰よりも分かってて、
全ての決定ができないといけないとか、
EMだったら、なんだろう、そのピープルマネジメントのところすごい上手じゃないといけないだとか、
コミュ力高くないといけないとか、いろいろこうじゃなきゃいけないみたいな思い込みみたいな、どうしても。
そういうのをなるべく考えないようにしていて、
マネージャーだからとか、誰かの上司だからこう接しなきゃいけないではなくて、
シンプルに向き合ってるプロダクトとかプロジェクトをうまく回すためにどうしたらいいのかだけ考えてたら、
結果的にメンバーとの接し方がそういうふうになったっていう感じだなって。
33:01
確かに確かに。
正直ね、高圧的というか、上司・部下みたいな接し方したところで、そんなにプロジェクトの成功に響いてくるだろうかって思うんですよね。
あんまり意味ないんじゃないかっていうか、だったら気軽に話してもらえる関係性の方が良くないって僕は思っちゃって。
確かに確かに。
そういうところを感じますね。
一緒に良いプロダクトを作っていくための仲間みたいな感覚で話せるのはすごいなって思ってます。
確かに僕はそれがちょっと極端なところがあるかもしれないんですけど、
よくメンバーからは、けいさんのことは冗長だとは思ってますけど、上司だと思ったことは一度もないです、みたいなことを。
だからこそこうやって収録に召喚できるし。
確かに。
良いのか、自分はそれでって思う時もあったけど、でも良いかって思ってますね。
私は好きです。
ありがとうございます。
そんな感じですかね、収録時間的には。
はい、Tトリオ。
ということで、本日はけいさんを招いて、マネジメントに関していろいろ相談させていただきました。
ということで、この番組を気に入っていただいた方は、Spotify、Apple Podcast、YouTubeなどで番組のフォローをお待ちしております。
レビューもぜひお願いいたします。
お便りも募集しています。放送の概要欄にあるリンクからどしどし送ってください。
Xで感想を呟く場合は、ハッシュタグITトリオでお願いします。
それではまた連絡お願いします。
お願いします。
お疲れ様です。
