Naoさんのリーダーシップ経験
ken
リスナーのみなさん、こんにちは。London Tech TalkのKen Wagatsumaです。
じゃあ、今日もかつさん、よろしくお願いします。
Kazunari Okuda
はい、よろしくお願いします。
ken
そして、今日はNaoさんもゲストにお呼びしています。
Naoさん、お久しぶりです。
Nao
お久しぶりです。お願いします。
Kazunari Okuda
よろしくお願いします。
ken
はい、よろしくお願いします。
ということで、Naoさんは、London Tech Talk、実は2回目の出演となっていて、
前回はエピソード89のブッククラブの第6章の振り返りを、僕と一緒にさせていただいたんですけど、
今日は、Naoさんの持ち込み企画ということで、
リーダーシップマネジメントスキルとは、みたいなね、割とすごい面白そうな、盛り上がりそうなトピックについて話していきたいなと思っているんですけれども、
最初に、Naoさんに簡単な自己紹介と、今回この企画を提案してくれた理由について、ぜひ聞きたいなと思っています。
お願いしてもいいですか。
Nao
はい、お願いします。
Naoと言います。
ソフトウェアエンジニアになってからは、4年半ぐらいなんですけれども、
今、イギリスの再生可能エネルギー、リニューアブルエナジーという、オクトパスエナジーという電力会社で働いています。
フロントエンドなんですけれども、今月4月の頭ぐらいから、自分のロールが変わってチームリーダーということでやらせてもらうようになって、
その前々からリーダーシップの形っていうのが、オクトパスエナジーは私が初めて働く外資系企業っていうか、日本の会社じゃない会社って感じなんで、
結構そのリーダーシップって全員に求められてたり、自分がリーダーとかマネージャーになる前から結構そこは薄々気づいてたっていうか、
違うなぁというのは気になったんですけれども、自分もそういうロールになったっていうところもあって、すごい興味もあるし、
あとは海外で実際に働かれているお二人と、どういった感じのことを、本とかはいろいろあるんですけど、裸でその感じている感じとかを聞いてみたいなとか、
そういうところで、すごいこのロンドンテックトークで、すごい海外で働かれているエンジニアの方が多い環境で、そういう話を話せるっていうのはすごい面白そうかなと思って、
Kazunari Okuda
面白そう。 提案してみました。 ありがとうございます。これ、ガズさんめちゃくちゃ面白そうっすね。 そうなんですよ。このトピック聞いた時、
トピックのタイトルがリーダーシップとマネージメントの違いというので、確かにそれって考えたことなかったなぁと正直思ってて、すごい良いトピックだなぁと思いましたね。
ken
これも那央さんとね、いつ取りましょうかみたいな話をしてて、まかえし環境でリーダーをするっていうのは多分初めてだっておっしゃってたんですけど、
なんか半年ぐらい慣れてから取りますか?みたいな話が出たんだけど、まず一旦この成り立てのタイミングで、こうフレッシュな感じで話して、
でまた半年後取ったら面白いよねみたいなのもあったので、今日はちょっとザックバラにね、みんな思っているということを聞いていきたいなと思います。
最初にちょっとあのね、今言ってくれた中で気になるトピックがあったんですけど、オクトパスエナジーさんはICだろうがリーダーシップはどこでも求められているっていうことを言っていて、そこちょっと深掘りしてみたいんですけど、なんか言語化できたり、なんか具体例とか紹介できたりしますか?
あーそうですね。そうですね。なんかミッションにそういう言語化されているとか、もしくは明確にICだけどリーダーシップ発揮してね、みたいなカンバセッションが今までマネージャーとあったのかとか。
Nao
要求とかリクエストはされないんですけれども、評価されるっていう気がします。そのリーダーシップっていう言葉にはなってないんですけど、エンジニアがエバリエーションされるときにエンジニアリングメトリックスっていうそのいろんなスキルがわーってあって、
その中にリーダーシップみたいなやつがあるわけではないんですけれども、そのジュニア、ミッド、セニアとかってなっていくにあたって、同じ項目でもこれはその自分一人のパフォーマンスだけじゃなくて、
リーダーシップを発揮して、要するに他人に影響を与えるというよりかは、チームとして上がるというか、
他人を引き上げるなのか、底上げするなのか、それは多分その人のスタイルによると思うんですけど、個人で一人で素晴らしいパフォーマンスを出す以上のことが、レベルが上がるにつれて求められてくるってなると必然的にリーダーシップがいるかなっていうような、
その形は様々なんですけれども、そういう引き入るとか、何かをリードするテクニカルなのか、その雰囲気的なところなのかとか、それはもう本当にいろんな発揮する場面があるんですけれども、
全体的に求められている感じはしますね。具体的に一人で引きなさいみたいな、そういうのではないんですけれども、
いるだろうな、必要となるだろうなっていう感じですね。
ken
なるほど、これカズさんの職場とかと比較してどうですか。
僕のチームは、SREはジュニアがほぼいなくて、なんかシニア以上なので、あんまりメンターシップとかもあるけれども、
割と似たような感じというか、プロジェクト任されたらリーダーシップ発揮してね、みたいな前提としてある感じなので、
本当にチームのメンバー構成とかカルチャーによっても違いそうなんですけど、カズさんのところはどうですかね、比較して。
Kazunari Okuda
そうですね、やっぱりNagoさんがおっしゃった通り、そのロールが上がっていくにつれて、
個人の力が、ジュニアとかはまずそれをつけて、ミッドエンジニアとかになると、チームの中で自分だけじゃなくて、
そのジュニアの面倒を見れるとか、シニアになるとチームのプロジェクトを引っ張っていけるで、シニア2っていうのがあるんですけど、
それになるとチーム全体を引っ張っていけるみたいなのとかもありますし、その中でリーダーシップが必要かっていうと、
私の会社でもリーダーシップとは言われてないんですけど、リーダーシップを持っている人が持ってそうなスキル、こういうのを体得して持っていると次のレベルに上がれるよ、みたいなのは定義されてますね、
なんかそんな気がします。確かにこれがリーダーシップを持っているっていう人が持っているようなスキル。
Naoさんの新しいロールの課題
ken
それ例えばパッと出ます?なんか、ジュニアをメンタリングできるメンタリングスキルとか、あとはプロジェクトを実現できるデリバリー力とか、うちで言われたりするかな。
Kazunari Okuda
そうですね、結局プロジェクトを最初から、例えばシニアとかだと技術面では完全に誰の助けもなくてインプリメンテーションができて、その技術面での提案ができるとか、
っていうところには何でしょう、シニア2、一応私プロモーション狙ってて、結構シニア2がどういうのを求められるかっていうので見てみると、新しいプロジェクトのディスカバリ、
どういうところから、既存見えてる問題よりも自分から問題を見つけてそれを提案して、それを最後の実装持っていって、実装からQAまで持っていって、それをデリバリーしていくみたいな一貫したものを求められる。
その中で、結局チームを引っ張っていかないといけないんですよね。
そうですね。
プロジェクトがあって、我々はワークストリームって言ってるんでしょう。一つのプロジェクトがあったとしたら、その中で一人じゃなくて、バックエンドフロントエンドのエンジニアがいて、
あとデザイナーとプロジェクトマネージャーがいて、どうコミュニケーションして、どうやってチームを引っ張ってプロジェクトを終わらせるかっていうことがシニアエンジニア2を求められてて、みたいな感じですね。
それがリーダーシップに、リーダーシップは求められてないんですけど、リーダーシップを発揮せざるを得ないような気がしますね。
ken
なるほどね。発揮しないと終わらないというか、いわゆる多分テックリードとかスタッフエンジニア的な動きかなと聞いてて思いましたけど、
そういえばNaoさんの今のタイトルというのは正確にはどういうタイトルになるんですか?
Nao
タイトルは私はまだ、今ちょうど会社のエンジニアリングメトリックスとかがちゃんとできて、シニアエンジニアになった人しか本当はリーダーができないんですけど、私はシニアになる前にリーダーになったんですよ。
ken
飛び急、飛び急してる。
Nao
なんですけど、それが要するに要は会社のスキームとマッチしてないんで、一旦競技中ですみたいな感じで言われてて。
ken
何それかっこいいアウトライヤー。
Nao
いや、というより多分誰もやりたい人がいなかっただけだと思います。周りにはシニアのICの方はたくさんいて、
うちの会社はもうミッドかシニア、ジュニアも少しいるんですけれども、すごいシニアをハイアリングするみたいな、基本的にそういうことが多くて、
なので、ICのシニアの人はめっちゃたくさんいるんですけど、特にバックエンド。
私はフロントエンドなんですけど、フロントエンドの方がもう少しバランスよくいろんなタイトルの人たちがいるかなっていう感じなんですけれども、
会社自体がほぼほぼバックエンドの人の会社なので、そういった会社のエンジニアリングそのロールのメトリックスがほぼバックエンドに沿ってできているところもあって、
フロントエンドはもう少し違うので、そこがちょっとマッチしてないってあると思うんですけど、オフィシャルには今競技中ですみたいな感じで言われてて、あんまりよくわかんない感じで、シューグラリンの感じになっています。
ken
なるほどね。それを聞きたかったのは、今カズさんがお話してくれた動き方っていうのは割とリーダーシップが求められるけど、
マネジメントスキルっていうと、リーダーシップとマネジメントスキルを分けなきゃいけないみたいな問題提起もしてくれて、まさにそうだと思うんですけど、
いわゆるピーポーマネジメントのマネジメントだと思ってるんですね。カズさんが言ってくれたのはリーダーシップかつプロジェクトのマネジメントっていうところは求められるけど、
解かなきゃいけない課題をディスカバー発見して、それで最後まで実装してプロダクションアウトするっていう意味で言うと、
ピーポーマネジメントってのは必ずしも求められないんじゃないかなと思いながら聞きました。
なおさんの新しいロールでは、なおさんが考えているリーダーシップとマネジメントを分けたときのピーポーマネジメントスキルは求められていく
Nao
ジョブタイトルなのかなと思って聞いてたんですけど。両方求められてしまいます。フロントエンドの場合はなんですけど、うちの会社は人数が少ないので、
要は一つのチームに対して、テクリードとEMを置くほどの人数がいないっていうのがあって、
なのでフロントエンドの人は必然的に兼任って感じになってます。ただバックエンドはもっと細かく分かれてて、
プロダクトのテクリードとかそういう風にもなってたりする、プロジェクトがプロダクトになってるって考えるのかもしれないんですけど、
もっと細かくちゃんと分かれてて、どれくらいの比重が、ピーポーマネジメントを完全に削除するっていうのは多分無理なんですけれども、
その比重みたいなのも結構示されてたりとかするんで、そのあたりは、私もバックエンドじゃないからそこまで一生懸命それはチェックしてないんですけど、
そのあたりのスキームはバックエンドの方はちゃんとあるなって感じで、フロントエンドはもうちょっとふわっとっていうか、人数も多くないし、
兼任でやらなきゃいけないとか、そういう感じですかね。
ken
なるほどね。これを聞いて僕の正直な感想はめちゃくちゃ大変そうというか、リーダーシップスキルとマネジメントスキルを分けつつも、
どっちも同じ人に求められているっていうのが結構チャレンジングだなと思っていて、かずさんの現場とかどうですか。僕の現場もさっき言ったそのシニアエンジニア的なその動き方は、
別にピーポーマネジメントにいるディベロップマネジャーとかエンジニアリングマネジャーがいて、例えば、
課題を発見しました、プロジェクト化しました、メンバーを2,3人集めてやりますなときに、例えばそのメンバーの一人がバーンナウトしてしまったとか、
なんかちょっと評価にくすぶってるとか、やめちゃって新しい人入れなきゃいけないっていう部分はエンジニアリングマネジャーがカバーしてくれるので、
どっちかというとちゃんとプロジェクト、プロダクトをデリバリーする、あとその技術を担保するってとこに集中できる環境ではあるんですよね。
なんでそこはスキルは明確に分かれてるし、それが求められるジョブロールも分かれてるんですよ。
かずさんのところもそんな感じですか。
Kazunari Okuda
そうですね。私もなおさんの話を聞いてて大変そうだなというか、まだそのフロントエンドの方がちょっとバックエンドの方が細分化されてて、
フロントエンドの方がそうじゃないとおっしゃってたので、そういう感じになってるのかなと思ったんですけど、
けんさんのところと同じで、私の会社ではエンジニアリングマネジャーっていうのはそのピーポーマネジャー、
1on1とかしたりとかキャリアをそのリポートの人たちを育てていくっていうか、どうキャリアを育てていくとか、
パフォーマンスですよね。それぞれのリポートのエンジニアのパフォーマンスを見たりとか評価するとかっていうのが、
いわゆるエンジニアリングマネジャーというロールでして、
それとは完全に別で、その人たちはもう完全にピーポーマネジャーとして分かれてるんですよ。
サーバントリーダーシップ
Kazunari Okuda
それとは別にICで、テックリードとかシニアエンジニアとかスタッフエンジニアっていうのは、
そこの人の評価とかっていうのもしないし、たぶん1on1もしないですね。評価とかもたぶんしてこないと思いますね。
完全に分かれてると。
Nao
うちも今フロントエンド増えていってる、今ちょうどハイアリングとかもしてる感じなんで、
もうちょっと人数が増えたらその辺とかも再分化されたりするのかなとか、
バックエンドにもそういう形式が整ってるのがあるんで、あるんかなっていう、ちょっと過渡期って感じは感じますね。
ken
結構ハイアリングとかもいっぱいあって、それも忙しいなっていう感じがあるんで。
だからもうまさに上からしたら、なおに前例作ってもらおうみたいな感じなんじゃないですか。
Nao
いや、そこまではないと思うんですけど、
そうですね、特に私のチームは2Cがマーケットなんで、もともと結構カオスな感じのチームなんですよ。
2Bだと市販機とかで、一つの大きなコントラクトがあって、
もうそれでカスタマー何百万人とかってガサッと数字で考えられてしまうような世界っていうか、
もうこの契約が成立すれば、金額なり人数なり見込みがもうかなり確約に近い形で予想が立つっていうビジネスなんですけど、
2Bだったら、私のチームって2Cなんで、
かけたエフォートに対するどれだけのバックがあるかっていうのが、本当にやってみないとわからないので、
できるだけ小さくいろいろ試して、その中で一番勝率が高いものを残していってっていう、
ずっとトライアンドエラーで永久にその答えはわからないっていう、本当にリアルマーケットがマーケットなんで、
そういうこともあって、結構その人のリソースの確保とか、そういうのも難しかったり、
あとは3ヶ月先に何が期待されてるかとかもちょっとわかんないっていうか、
マーケティングチームとかセールスチームとかと結構一緒になって、
そのミックスで一チーム、チームとしては全然別れてはいるんですけれども、
やっていくこととしては結構そういういろんなステークホルダーとかなり一丸になってやっていくみたいな感じのチームなんで、
人のマネージメント、それからテクニカルな担保っていうか、
あとはプロジェクトのどう進めるかっていうか、リソースの配分とかですかね、
そういう結構きれいに分けられないみたいな特性もチームの特徴としてあるのかなと、
結構ごちゃっとしてるというか、総合的な感じっていうか、そういう感じですね。
ken
本当に不確実な状態というか、曖昧な状態から成果を出していけっていうところですよね。
Nao
そうですそうです。だからそれに耐えられないといけないというか、きっちりきっちりみたいなのが普通だというふうに思っていると、
多分ストレスしかないって感じだと思うんで、
できる常に来たものをピンポンするっていうか、来たものをすぐに打ち返せるとか、
変化にすぐ対応できるコードベースにしておくとか、
そこは絶対だなと思ってるんですけれども、何が来るかわからないっていうのもあったりして、
そういう対応力みたいなのは結構求められてる気がしますね。
ken
なるほどね。これ事前のメモにすごい上手い言い方をしてるなと思ったのが、
実現するゴールがない状態でサクセスを生み出す。
やらなきゃいけないことは誰かが作ったゴールを達成することじゃなくて、
マーケットでのサクセス、ユーザーに対する成果のサクセスを提供するっていうところなんだっていうところが、
本当に会社のカルチャーを表してるし、でもそれがビジネスするっていうことですよね。
誰かが作ったペーパーワークのゴールをするとか、
ユーザーにあんまり影響のない機能、デッドライン守って価値提供するこれどれぐらいが意味があるのかっていうところを、
現場のエンジニアとかリーダーシップ求めて、ちゃんと考えていかなきゃいけないっていうのが、
現場に浸透してるような良いカルチャーがあるんじゃないかなって、
本当に話しながら聞いてて思いました。
Nao
そうですね、確かに。
ちょうどそれこそ前回、今福岡なんですけれども、
数日前に福岡に戻ってきて、その前に東京にいたんですけど、
ちょうどその時グローバルCEOサミットみたいなのが東京であって、
CEOの人とかCTOの人は私も会ったことがあったんですけど、
もっと他のヘッドオブオペレーションとか、
外国のトップの人たちとかもみんな日本に来てて、
ちょっと喋る機会とかがあって、そういう人たちと話す機会があったんですけど、
なんか結構すごいピュアな感じの人たちが多くて、
それはすごい楽しかったし、やっぱいいなって思いましたね。
なんかすごい純粋に楽しそうみたいな感じっていうか、
目がキラキラしてる感じっていうか、楽しそうな感じだったんですよね。
ken
いいですね。
Nao
なんか風格があるとか、そういう感じっていうより、
なんかすごい喋りやすくて、誰よりもピュアに疑問を持ってたりとかして、
なんか私、前はプロダクトのチームにいたので、
前はここにいましたみたいな感じで言ったら、
あれってさ、もっとこういう風にできないの?みたいな感じ。
やっぱり興味を持ってないと出てこない質問みたいなこととか話が出てきて、
結構そういう本当にいろんな国のさらにトップみたいな人だから、
結構本当に実務レベルとかで言うと全然離れてるところだと思うんですけど、
そういうところの人たちとかが、
そういう本当に実際のそれを実装してるエンジニアと対等に、
もっとこうできないの?っていうその実装レベルの話が、
ken
なんか普通に楽しくできて、すごいいいなって思いました。
すごいな。
Nao
楽しかったです。
ken
そのピュアさかっこいいですね。
Nao
いいなって思いましたね。ピュアやなと思って。
ken
なんかシンプルに楽しくやっていくっていうか、
なんかそういう人見てたら周りもついていきたくなっちゃいますよね。
Nao
そうなんですよね。
それもすごいいいリーダーシップの例だなっていうふうに思いましたね。
別にその人が何かを提示して、
これを実現しよう、いくぞみたいなことを言ったわけではないんですけれども、
ナチュラルになんか人がインスパイアされていくっていうか、
ついていきたいなとか一緒にやりたいなって思えるみたいな、
人としての魅力みたいなのがすごい。
これも一つリーダーとして大切な要素だなと思って見てましたね。
ken
なるほどね。
なんかそのリーダーシップの観点で、
カズさんもそのトラディショナルリーダーシップとかサーバントリーダーシップみたいな、
リーダーシップの型もいろいろあると思うんですね。
このその周りがついていきたくなる、
そのロールモデルみたいな動き方をする、
ロールモデルになれるっていうところも、
うちの現場では割とリーダーシップの一つに挙げられてたりはするんですよね。
Raising the bar というか、
例えばその一つ仕事をするにしても、
ただ合格点を目指すだけじゃなくて、
バーを上げて70点で合格なのところを、
80点、90点のアウトプットを出すことを定常的にやるような人が、
いわゆるロールモデルになり、
そういう人がやっぱり評価もされるし、
プログレーションも、
昇進もしていくみたいなところでも、
明確にそういうメッセージが打ち出されていたりするんですよね。
だからその周りを引っ張っていける、
その引っ張っていき方は人によるんだけど、
本当にこう、
ピュアに好奇心を持ってドライブしていくような人とか、
どんどんどんどん自分でバーを上げていって、
アウトプットを高めていけるような人が、
ロールモデルとしているっていうのは、
うちの現場としてあったりします。
なんかそのカズさんの思うリーダーシップの形とか、
聞いてみたいなと思うんですけど、
ありますかね。
Kazunari Okuda
そうですね。
私はサーバントリーダーシップっていうのを、
ちょっと言及したんですけど、
きっかけはですね、
LinkedInで人のポスト見てたら、
サーバントリーダーシップみたいに書いてるマネージャーとか、
結構そのポジションの人が書いてるんですよね。
サーバントリーダーシップってなんだろうな、
っていうのを気になって調べた感じだと、
トラディショナルのリーダーシップだと、
どっちかっていうと、
人をプッシュするというか、
典型的なリーダーシップというか、
あえて人をプッシュしていって、
何かを達成するみたいな感じなんですけど、
サーバントリーダーシップっていうのは、
もうちょっと支援するというか、
サーバントっていうぐらいなんで、
そこまで何て言うんでしょう、
下木のように使うわけではないですけど、
間接的に、
例えば支援していって、
先ほどおっしゃったように、
Nagoさんがおっしゃったように、
好奇心があって、
マネージメントの人たちが好奇心があって、
これはどうなのとかっていう、
現場のことを知ってて、
この機能はどうなの、
例えばどうなのとかっていう話をされると、
間接的にモチベーションが上がるじゃないですか、
その人たちにインスパイアされるというか、
直接こうなるよって言われてるわけじゃなくて、
ああなりたいなと自然に思うような感じ、
っていうのが、
Nagoさんの話聞いてて、
きっとそれがサーバントリーダーシップの
質問とリレーションシップ
Kazunari Okuda
一つの形なんだろうなと思いましたね。
ken
なるほどね。
確かにじゃあ、
ここ3人ともとりあえずリーダーシップとか、
ロールモデルの形みたいなのは見えてきた中で、
これ2人ちょっと聞いてみたいんですけど、
じゃあ周りに良いインパクトを出すっていうところを、
一つ達成したいってなったときに、
具体的にどういう風にインパクトを
染み出していくかっていうところを聞いてみたいんですよね。
例えばNagoさんの場合はグローバルCEOみたいな
ミートアップがあって、
実際にお話をして、
そこで影響を受けたりとか、
あとは僕の場合だったら、
例えば実際にいい動き方をしてることが評価という形されて、
こういう動き方がいいんだなっていうのが周りに浸透していく
みたいなのがあったりするんですけど、
でもそのいい動きっていうのは、
周りにビジビリティがないと分からないと思うんですよね。
いい動きをしてるっていう、
動き方自体もそうだし、
それが良いか悪いかみたいな評価基準も
周りに伝わらないといけない。
だからいろんな現場で、
例えばいい動き方をしたら、
盛り上げるようなスラックで盛り上げてみたりとか、
あとはいいフォローアップをしたりとか、
コンテンツを発信できる人は、
フォローとかにして社内で展開すると、
リアルタイムに話せないタイムゾーンを超えた人とか、
その時休んでる人にも
インパクトをビデオを見てもらうみたいな形で広げたりとか、
あと社内にドキュメントを書いたりとか、
いろんな形はあると思うんですけど、
その良さとかインパクト周りに実際に染み出していくところに
何が必要なのか、
どういったティップスがあるのかっていうのは
何かお考えあったりしますか。
思いついた方からでもいいんですけど。
Nao
そうですね、私は、
わかんないですけど、
数週間レベルの、
あれ、あれ、
いいですね、いきましょう、それの。
思うのとしてはですけども、
3つぐらいあるかな、
出せるかなと思って、
忘れそうやから先に言うんですけど、
1個が質問をすること。
2つ目が、
自分のチームの
以外の、他のチームといいリレーションシップを
作っておくこと。
自分のチームの人たちは、
自分のリポジトリとか、
自分のウェブサイトなり、
プロダクトにフォーカスしてるんで、
他のパブリックリレーションじゃないですけど、
そういうところと、
あとは、
直接的と間接的、
どちらも必要だと思うんですけれども、
リコグニション、
リコグニションは、
今のパブリックリレーションに近いかもしれないんで、
褒めるっていうこと。
しっかり、
感謝なり、
いいなと思ったりとか、
小さいのも大きいのも、
間接的にも直接的にも、
ちゃんとそれを褒めるっていうこと。
その3つぐらいかなって、
思ってて、
1個ずつ話していったら、
めっちゃ長くなりそうなんで、
とりあえず、
リコグニション
Nao
3つで、
って感じですね。
質問をするっていう1個目が、
結構ふわっとしてるんで、
ちょっとだけ説明すると、
私は、
質問をするタイプの人なんですね。
それは、
エンジニアになる前からそうなんですけれども、
その理由は何でかっていうと、
自分が分かってないと
できないからって感じなんですよ。
ほぼ自分のため的な感じなんですけど、
理解してないとできないから、
理解するまで聞くっていうのがあって、
もちろんそれで、
人の時間を取ってしまうこともあるんで、
ちょっと、
良くないかなとかって思いながらも、
でも聞かないと本当にできないからと思って、
その葛藤は自分の中にありつつも、
すごい聞きまくるみたいな感じだったんですけど、
もしかして、
それが自分のリーダーシップって
思われてることの1つになってるかもしれないって
思う機会が、
去年ぐらいから結構増えてきていて、
それは、
えっと、
暗中模索
みたいなシーンの時に、
誰も
質問してない場合って、
私はみんな分かってるから質問してないと思ってたんですよ。
周りシニアの人が多いので、
だから、
私だけが
分かってないとかチーム移動したりとかしたら、
私このチームに来てまだ
1ヶ月とかやから、
あれも分からんしこれも分からんしみたいな感じで、
自分だけが分かってないと思って、
だから早く追いつきたいと思って、
すごい質問するみたいな感じだったんですね。
とか、そういえば
誰々さんがいついつまでこれ出したいって言ってたけど、
え、誰も動いてないけど、
え、大丈夫なの?みたいな感じとかで、
とにかく気になることすべて質問しまくってたんですけど、
それは
物事をプロシードしてるっていうことに
結果的にはなる。
とか、
チームの中でクリアじゃなくて、
みんなが分かってない人も多分いたし、
はっきりしてなかったところを
明確にしていくみたいな、
そういう
私としては分からないことを
質問してるだけ、
アウトプットの具体的な方法としては
Tipsっていうか、
質問をするっていう形なんですけれども、
それが導く結果っていうのは、
はっきりしてないものを
クリアにするっていうことだと思うんで、
それは物事が前に進むっていうことだったりとか、
ほっとかれてたものが
オンステージに上がるとか、
オンホールだったものが
オントラックになるとか、
そういうことに
変化がついていく
っていう結果になるんだろうな
と思って、
質問をするっていう。
これめっちゃ分かるなぁ。
どうですかパスタ?
ken
うなずきながら聞いてましたか?
めっちゃ分かる。
それは本当に
Kazunari Okuda
話が長くなったかもしれないですけど、
いいよ、長くしましょうよ。
ken
質問するっていうのは、
Kazunari Okuda
リーダーシップとは
置いておいても、
日本とそれ以外の国で、
そもそも質問をすることとは
全然違うんですよね。
日本とそれ以外の国で、
質問のカルチャーの違い
Kazunari Okuda
そもそも質問をすることって
あんまり日本で
他の人の時間を
取るみたいな、
あんまりネガティブな感じが
あるような気がするんですけど、
本当に
こっちの人たち、
僕は日本を出て
今のアメリカの会社とかで
働いてるんですけど、
みんなめっちゃ聞くんですよね。
本当に細かいこと。
特に
リモートワークになってから、
質問をすることで
クリアになっていくっていうか、
直接のコミュニケーションがない。
リモートワークしてるんで、
直接のコミュニケーションないじゃないですか。
何かをクリアにすること、
コミュニケーションって
すごい大事なんですよね。
それが
チャットとかに残っていく、
どこかの文章に残っておくっていうことは
すごい大事で、
その中で質問を
どんどんクリアにしていく
っていうコミュニケーション
っていうのは
めっちゃ大事ですね。
本当に。
うなずきが止まらなかったですね。
Nao
大事ですよね。
すごい私覚えてるのが、
一番最初、新卒で
エンジニアとかじゃなくて、
普通に就職した会社で、
質問しまくってたら
一回自分で考えてから質問しよっか
みたいなこととかをすごい言われてたんですよ。
ググれかすとかあるじゃないですか。
もうググれはもしかしたら
チャットGPTしろかもしれないですけど、
今の最近だから。
それはみんな
知ってる上で、
でもやっぱり
カルチャー的に
調べたけど
でも聞きにくいみたいな感じのカルチャーって
あんまり良くないですよね。
あんまり何も進まないっていうか、
土壌として
クリエイティビティも生まれないし、
やっぱりそうやって
すごい言われてたんだよ、私。
自分で考えてから質問。
多分すごいアホな質問ばっかりしてたんやと思うんですけど、
まあ、でも
だとしても
やっぱ欧米的なカルチャーって
good questionって言って、すぐ
めっちゃえ?みたいな質問とかに
答えて、そして
僕はこう思うよとか、
私はこういう風に思って
これを進めてますとか、みんな
そうやって答えてくれるんで、
やっぱり質問をするっていうことは
すごい
分かってない人っていうことじゃなくて、
物事を進めていこうとか
積極的な姿勢として
すごい求められてる
なと思いますね。
ken
はい。
ここは
ミーティングに求められる
目的の違いっていうのも
あると思うんですよ。
カズさんが日本ではこうだったみたいに
言ってたけど、例えば
なぜ例えば日本式とか
日本だけじゃないと思うんですけど、
アライメントを取るようなミーティングの場と
議論を
進める場のミーティングって全然
違うスタイルだと思っているんですね。
その分からなかったことを
スポットライトを当てて議論したり
とかっていうところには、確かに
質問をするっていうスキルってすごいめちゃくちゃ
重要だし、それを言える勇気が
ある人とか、そこにちゃんと立ち向かって
いける人っていうのがすごい重宝されるんですよね。
日本では
寝回しって言葉があるじゃないですか。
寝回しっていうのは
スタッフエンジニアの本とかにも
日本式スタイルの
ポリティクスみたいな感じで紹介されたり
するんですけど、寝回しっていうのは。
それは
アライメントを取るミーティングの場では効いてくるんですよね。
だからそこでは
ステークホルダーを集め、みんな
これもう考えたよね、考え抜いたよね。
このドキュメント事前に読んだよね。
じゃあこれでいくよ、オッケー、太鼓板押してよみたいな
アライメントを取るっていう場で
例えば、なんだろうね、じゃあ
前者だけにカフカを使っていくよ、
アライメントを取るよってミーティングに来た時に
カフカって何ですかって質問は
さすがにないと思うんですよ。
それは、アライメントを取るミーティングの前に
すでに質問するというステップがあり
そこでみんな質問したという前提で
知識が揃った状態で
みんな反抗しに来るだけみたいな
褒めることの効果
ken
ミーティングのスタイルの時もあるんですよね。
で、それを踏まえた上で
たぶん、アライメントを取るだけの
ミーティングって
自分の現場とかそんななくて
本当にその議論で直さんが言ったように
みんな分かんないところを持ち合わせて
みんなで議論するっていう場の
ミーティングが多いから
やっぱりその質問するスキルとか
スポットライト当てるスキルってすごい情報されるんだなと
本当に聞いてと思ったんですよね。
だからこれは
質問するって結構怖いじゃないですか。
みんな分かってんのに
自分だけ分かんないのかなって
質問してみたら実はみんな分かってなかったっていうところが
普通にあるので
Nao
そうなんですよね
あれ良かった、あのクエスチョン良かったよ
とか後から言われて
え、分かってなかったんかい、みたいな
ken
そうそうそうそう
そうね
Kazunari Okuda
で、あと
リーダーシップの中でも
質問
力って大事だなと思ってて
私は自分のマネージャー
に対して
101の中で
たくさん質問してくれって言うんですよね
っていうのも
私はこう考えてこれをしています
っていうのを言った時とかに
じゃあそれはなんでとか
こういう状況はどうなのとかっていう
なんて言うんでしょう
うーんと
まあその101の中でやっぱり
第3者
自分のマネージャーの
と、なんて言うんでしょう
意見を
いろいろな
私だけでしか考えられてなかったことを
なんかどんどん膨らましていく
みたいな場には
してるつもりなんですよ
その中でやっぱり
マネージャーがこうこうこうでした
私が例えばこうこうこうで
これをやろうと思ってますって言って
そうだね、はい頑張ってみたいな
そこで何も議論が
生まれないと
なんか101としての価値は
私にはあんまりないと思ってるし
マネージャーも
存在する意味はないな
と思ってるんですよ
だからそこでなんかもっと
どんどん質問して
当たり前
だとしても
なぜそれが当たり前なのか
それは僕にとっては当たり前だけど
他の人にとっても当たり前じゃないかもしれない
じゃないですか
だからなんかその
リーダーシップのスキルとして
質問力
例えばピーポンマネージャーの人にも
なんか必要なもの
かなと私は思いましたね
ken
その通りですよね
なんか日本語だと
何か話し始めるときの
枕言葉として
皆さんご存知かもしれないですけど
みたいなあるけど
あれ僕なるべく言わないようにします
多分みんな知らないだろうなって
同じこと知ってても見方絶対違うと思うので
Kazunari Okuda
そうですね
Nao
なんかそのコンテキストが
全員揃ってる前提っていうのは
すごい日本ならではって感じ
ですよね
ken
2つ目がリレーション作りと
3つ目が褒めるってとこでしたね
これすごいその褒めるのとこ深掘ってきたんですけど
Kazunari Okuda
褒めるもまた言いたいと思いました
ちょっと話したいなと思ったんですけど
ken
これまず
確認しておきたいのが
会話の中で褒める
っていうことであって
評価するってわけではないですよね
例えばその評価すると
また
別の軸で捉えてますよね
Nao
別の軸ですね
ken
あえて
飴を与えられるわけじゃなくて
雰囲気作りとしての褒める
っていうだけですよね
Nao
エンカレンジメントというか
そうですねエンカレンジメントと
パブリックリレーションでも繋がるんですけど
やっぱり
一人一人が
スタープレイヤーであるっていうことを
本人たちも自覚してほしい
ということと
やっぱり一人で仕事は完結しないので
やっぱりそうやって他の
パブリックでみんなに見えるところで
しっかり褒めるっていうことで
他のチームからのリコグニションが得られて
それはなんていうのかな
タイトルとは違いますけど
この人ってこういうプロジェクトをやったことがある人なんだとか
こういうことをやってるんだとか
おそらくそれは全員が見てるわけではないと思いますし
本当にあんまり意味のないことかもしれないですけれども
でも少なくともスラッグとかだったら
絶対メンションもつけるし
それで
エンカレンジメントが一番大きいかもしれないですけど
外からもやっぱり
その人たちの存在っていうのを
リーダーシップの磨き方
Nao
知ってほしいっていうのもあって
それはやってますね
だからチームの中の一人で
誰がやってるんだかわからないんじゃなくて
すごいこういったことに
この人たちっていうのはすごく貢献していて
それは会社のためとか
クライアントのためとか
もしくはステークホルダーのためとか
っていうのを結構明確にできるだけ
言うようにしてたりとか
あとは普通にただ個人的に
自分がすごい助かったとか
いいことしてるなとか思ったら
さってDMで送ったりとか
そのやり方は本当に
いろんな
一箇所のチャンネルとかに
とどまらないようにしてて
直接的間接的
インサイドチーム
アウトサイドチームって
それは結構バランスよく
そして多いほうがいいかなっていうふうには
思って
やってます
ken
そうですね
これちょっと聞いてみたいんですけど
僕マネジメントの経験ちょっとだけあったときの
経験談なんですけど
人前で褒められることが
苦手な人もいると思うんですよね
Nao
居心地が悪いというか
ken
そうそうそうそう
そういうのを確認しないと
そういう人に対して
人前で褒め殺しちゃうと
いつもちょっと不快だったとか
恥ずかしいみたいな
そう褒めるって簡単だけど
結構難しい
3つのプレイヤーがいるじゃないですか
褒める自分と褒められる人と
それを見てる第3者みたいな
だから他のチームメンバーっていうのがあるので
その3者がみんな
心地よい褒め方っていうのは
本当に難しいな
褒めるがただ多すぎても
1回の褒めるとかエンカレッジメントの
効果がどんどん薄くなって
ってしまうので
例えばいつも
みんながいるチームチャンネルで褒める
ってことを始めたときはすごいなんか
嬉しいんだけど1年も続けると
みんなが褒めてるなみたいになっちゃうから
例えばやり方を変えてみたりとか
そういう
褒め方自体も
進化が必要というか
Nao
そうですね
思っていますね
確かに
あと褒めるっていうと日本語のせいかもしれないんですけど
なんかちょっと上から目線というか
私があなたを評価してますみたいな感じになっちゃうのが
すごい嫌で
それはしない
事実
自分としてチームを助けてくれました
とか
自分の感謝を伝えるみたいな
そういうやり方の方が私は好きで
できるだけ
リーダーとして
あなたを褒めるみたいな
あんまりそういう方向の矢印は
好きじゃないしあんまりしてない
こういうことをしてくれてありがとう
みたいな感じで
ノミネートするみたいなことじゃないから
本当に素直に助かったことを
ピックアップして
それを上げるみたいな
感じですね
ken
確かに確かに
それで過去に一緒に働いたことあるマネージャーで
すごいなと思ったのは
その人をマネージャーから
僕と一緒に働いた
いい動きをした人に
彼から褒めるんじゃなくて
僕にちゃんとフィードバックしてね
っていう風にナッチしてきたんですよね
僕と
その人間で
感謝とか褒め合いが
できるように常にリーダーから
上から目線だけじゃないところを
なんだろう
促したっていう動き方を
してきた
マネージャーがいてそれはすごいなと思った
Nao
いいですね確かに
なんか一方通行な感じになりがち
ですもんね
いいですね
ken
褒めるいいですね
Kazunari Okuda
そうですね
ナオさんがおっしゃったように
日本語の褒めるってなんか
上から目線というか
感じはありますけどこっちの
褒めるっていう
正しい日本語なのかどうか
アクノロジーするというか
こういうことしてくれてありがとう
感謝するのかな
でも
私個人としてもやっぱり
マネージャーとかが
ここがすごい助かったよとか
例えばQAドックのこういうところにデザイン書いてて
QAするのにデザインを
見るときにすごい助かったよ
とかって
言われると
モチベ上がりますよね
それはなんかその
それってやっぱりサーバントリーダーシップじゃないですけど
なんか私個人としても
なんか
引っ張られてるわけじゃないんだけど
なんかこう間接的に
モチベが
そういうことを
感謝されると
嬉しくて
モチベ上がりますよね
そういう場って
私の会社では
エンジニアリングの
全体会議があってそこで
プロプスって言って一番最初に
誰かに対して
感謝を伝えるっていう場があって
かつ
私のチームはですけど
振り返り
レトロスペクティブが2週間に1回あるんですけど
その場でもプロプスっていう
感謝を伝える
誰でもいいから
チームメンバーとかこういうことにありがとう
っていう場もあって
あとは
おっしゃったよりダイレクトメッセージとかでも
感謝を伝える場もあるし
みたいな感じで
複数
アクノリティするというか感謝を伝える場
っていうのが結構あったりして
そうですね
それを
出す場があるとみんな
感謝を伝えやすいし
土壌ができますよね
じゃあ感謝されたからもう一回
私からも感謝しようみたいな
ところとか
そういう場って
大事だな
ちゃんと設けられてること
みんなが当たり前のようにやる
っていう場を
作るっていうのがまた一つ
大事なのかなと思いましたね
ネガティブなフィードバックの与え方
ken
そうですよね
日本の小学校の時の表彰状を
配るみたいなイベントとか
何か聞いて思い出したけど
今思うとそういう意図でやってたのかなと
Nao
そうかもしれないですね
あと思うのはやっぱりビジネスなんで
どうしても数字とか
大きい人数のプロジェクトとか
そういったところは当然目立つんですけれども
でもそれに
その人が注力できるっていうのは
やっぱり他の
もっとちっちゃいプロジェクトとか
ビジネスアズ友情みたいな
バグをフィックスするとか
ちょっとしたプロジェクトにはならないけど
ちょっとした要望を
すぐに直すとか
そういったのを
やってる人がいるからっていうことも
あったりとかするんで
感謝を伝えるとかっていうのは
もちろんエンカレッジとかそういうのもあるんですけれども
あなたがやってる仕事っていうのは
すごく重要な仕事であるっていうことを
本人の方に分かっていただく
っていうのもすごいやっぱり
大きいところで発表されたり
そういう風になる仕事も
当然あって
それは大変だけど楽しかったりもすると思うんですけど
そうじゃないけど
すごい大事なことっていうのは
本当に全てが
言ってみればちっちゃいこととか
全ての仕事は本当は本来
そういうものなので
そういった
自然にやっぱり強弱がついてしまうところを
できるだけ
そうじゃないと
やってたりとか
あとはサポートやってくれたり
もしくはレビューしてくれて
スムーズに実際プロジェクトが
続くようなサポートをしてくれたりとか
っていう方を
できるだけ
サポートっていうか
すごい重要な働きをしてくれてるっていうのが
スポットライトしたいなとは思いますね
ken
いやーさすがですね
3週間と思えないですね
なんかこう
結構リーダーシップっていうところに
絞ってすごい議論が盛り上がってきて
時間もいい感じになってきたので
もう今日はこのまま
第1弾リーダーシップということで
第2弾マネジメントとの違いを
やっていこうかなと思うんですが
あと2つぐらいちょっと話したいトピックがあって
どのようにリーダーシップを磨いていくのか
っていうのを最後に締めたいのと
もう1つ前に
これちょっと小さい問いとして
今までは褒める
パレーチする
ポジティブフィードバックっていうところを
話してきましたけど
どのようにリーダーシップを磨いていくかに
逆にネガティブなフィードバックを
与えるっていうところに関して
何か思いとか経験とか
考えがお二人あったりするかな
っていうのを聞いてみたいと思います
っていうのも
いい動きをした人を
この具体的な動きがすごい良かったね
っていうことで周りも
そのロールモデルを認識するっていうのは
なんだろう チームの生産性に寄与しなかったり
あんまりこう
その
あんまり良くない動きってあったりする
例えばミーティングにすごい遅れて連絡なし
とか
あとはデッドラインを引き伸ばして
引き伸ばして引き伸ばして
習慣になってしまっている人とか
そういった人に対してネガティブなフィードバックを
与えざるを得ないシチュエーションっていうのは結構あると思うんですよね
それを与えるっていうのも
僕はリーダーシップスキルの1つじゃないかな
と思っていて
必ずしもマネージャーだけが言うものではなくて
例えば同僚に
気持ちよくネガティブなフィードバックを
あげられる関係になれば
それはチームの底上げにもなるかなと思っているんですけど
ネガティブなフィードバックを与える
という点に関しては
そうですね
じゃあまずnaoさんから
もし何かあれば聞いてみたいなと思います
Nao
そうですね まず
ポジティブネガティブどっちも
フィードバックはして
するんですけど
フィードバックとして
相手が何を望んでいるかっていうのを
できる限り正確に把握しておくのが
大事かなと思いますね
どういう
コントリビュートの仕方
相手の望むことを把握しコミュニケーション
Nao
どういう働き方を望んでいるか
それを把握した上で
私もできるだけその人にコミットできる
その人が望んでいるような
できればそういうプロジェクトを回すとか
あとはワーキングライフバランスとか
あとは会社ができるサポートとか
そういったことを提供した上で
その
本当に困っていることがあれば
単純に事実を確認しますね
例えばさっきおっしゃってたみたいな
ミーティングにあんまりちゃんと時間通りに
来れないとかっていうのがあった時に
他の人を聞けて
オンタイムに始めたいんだけれども
私がそれに対して何か
できることありますかっていう風に聞いて
そしたらもう時間通りに
来てくれるようになりましたね
その後からとか
おー素晴らしい
それがどれくらいのプレッシャーに
伝わったのかちょっと分からないんですけれども
やっぱりその
私が指示したことを
やってくれるっていう関係は望んでなくて
自分で考えてほしいんで
そのために私が
実際その私としては
望んでる環境じゃないっていうか
オンタイムに始められないっていうのは
その私のっていうより
他の人の時間も送ってるし
嫌だったんで
それを改善したいっていうのが
私の意図だったんですけれども
質問として
私にそれに対して何かできることがあるのか
っていうのを聞いて
その人が何を望んでるのか
その人がそれを実現できるためには
どういうことをこちらができるのか
例えば向こうが
30分時間ずらしてほしいとか言ってきたら
それはチームにも確認を取った上で
するつもりでしたし
そういう感じ
相手が望んでることを
把握して
やりたいことはあるんで
その上で会話で
どうしたらうまくできるかなっていうのを
コミュニケーションしていくっていうこと
と
でも本当に正直に話す
っていうことかもしれないです
例えばリーダーシップの時じゃなくても
私ICの時とかで
コードレビューやチェンジリクエストの適切なやり方
Nao
コードレビューとかで結構
チェンジリクエストをどのレベルでするか
コメントだけにするのか
チェンジリクエストにするのか
とか
これって今マージしても問題なくて
言われたコメントに関しては
フォローアップでやるからっていう
そこの自由度みたいなのとかを
すごい激しく
私としてはちょっときつすぎるんちゃうかみたいな感じで
思ったことがあって
めっちゃ会話が長くなっちゃった
ブルリックとかがあって
その時私が最終的に感じたのは
私信用されてないのかなっていう
ken
ことだったんですよ
Nao
私はそれを聞きました
本当に
私にとって
働く人に
一緒に働く人に信用してもらう
っていうことはすごく大事なことなので
今のやりとりだと
そうじゃないのかなって感じるんだけれども
どうしたら
あなたに信用してもらえるんですか
みたいな感じで
私にとって結構重要な問題なんです
みたいな感じで聞いて
もしかしたらだいぶきつい
こいつめっちゃガー強いなって
思われたかもしれないけど
そしたら
向こうが
そういうふうに思ったんだみたいな
僕はそういうつもりじゃなかったんで
ごめんねみたいな感じになって
なおがそうやってやるっていうことは
じゃあ僕ちゃんとそれは信用して
必ず
私も必ずやるからって言って
ほんまにすぐやったんですけど
相手からリクエストされてたことはもちろん
ちゃんと答えましたし
プールリクは相手も
折れてくれたじゃないですけど
分かったって言ってくれたって感じ
でも正直に自分の気持ちで
喋るみたいな
ぶつかる感じっていうか
ken
そういう感じ
そのストーリーめっちゃ好きですね
そういうのを通して
信頼関係って養われていくじゃないですか
Nao
他のメンバー
ちょっとバチってそこではするんですけど
結局別に
それですごいギスギスしたかっていうと
そんなこともなくて
別にその後も
普通に前年仕事はやりやすく
できたので
ずっともやもやして
お互いにもやもやしながら
なんとなくバチバチ関係が悪いより
それだったら普通に言った方がいいやん
っていう
パーソナリティーかもしれないんですけど
ken
私はそういうスタイルですね
もやもやしちゃうとどんどんお互い不満も
溜まっていってしまいますから早いうちにね
Nao
そうなんですよ
やっぱりどうしても言わなくても
やっぱり出ちゃうんですよ態度とか
実際ディスカッションとかになった時に
なんか
本当は思ってることあるのに
そのもやってした関係性だったりしたら
もういいわみたいな感じで
ちゃんと建設的なディスカッション
最後まで突き詰められなかったりとかして
全然良くないんで
それは
その場その場で毎回解消していきたい
ken
ですね
これは全ての関係性に減ると思います
Kazunari Okuda
そうですね
マジで夫婦関係に今
私も考えてましたよ
Nao
本当ですね
ken
不満の目は早めに
積もうと言う
Nao
積もうと言ってますね
ken
積んどこうって
本当にいい話
かずさん何か言い残したことありますか
ネガティブフィードバック
最後のトピックに行く前に
Kazunari Okuda
ネガティブフィードバックは
やっぱり難しいですね
いろんなワークショップを経て
その
どうやって
コンストラクティブフィードバックを与えるかみたいな
なんかいろんな
本とか
会社でも
セッションがあるんですよ
フィードバックはギフトだみたいな感じで
ありますよね
そのどうやって
コンストラクティブなフィードバックを
与えるかみたいなのも
何度も経験はしてきてるんですけど
リーダーシップを磨く方法
Kazunari Okuda
まあ
そうですね
躊躇しますよね私としては
正直言って
でもなんか
実際でも
正直に
言い方きつくない
言い方であれば
私はマネージャーとかにこうしたらもっと
いいよいいと思うよとかっていう
そのフィードバックを
いただいたときは
素直に受け止めることができる
っていうか
じゃあ
そういうふうに見られてたんだからこうしよう
みたいな感じで
取れますよね
で
なおさんが言った方法って
めっちゃいいなと思ってて
私に何ができるっていう
聞き方
協力的ですよね
ken
そうですね
Kazunari Okuda
それってすごいいい方法だなって
私は思いましたね
そこで
なんでって結構強い言葉で
日本語でもそうなんですけど
なぜって聞かれると
なんでこうだとかって
言い方って結構きつくないじゃないですか
でもそこで
それ解決するためには
私に何ができるって
言い方なんだと
実はさみたいな
例えばタイムゾーン的に
ここに
子どもを保育園に送る時間があるから
ちょっとギリギリなんだよね
だからちょっとずらしたいんだけどさ
でも言いづらくてさ
みたいなとかっていうきっかけになるよな
と思って
すごいやり方だなって思いました
ken
確かに
学びですね
本当に
こういったなんだろうね
ユースケースってもう
いくらでも思いつくので
自分がネガティブフィードバックを
上げるの失敗したシチュエーションみたいな
ちょっと磨いていきたいなと思います
お二人あと5分くらい
Nao
時間大丈夫ですか?
ken
今日は
いろんなリーダーシップの形とかについて
語ってきたので
最後に
リーダーシップはなんとなくこんなものかな
っていうのを
見えてきたリスナーの方もいらっしゃると思うし
僕もそうなんですけど
最後にリーダーシップを
磨いていく獲得する
強くしていくためには
どういったことを気をつけて
行動したらいいのかとか
どういったメンタリティとか
思いを持って仕事に
当たっていけばいいのかっていうところに関して
一人一人思いを述べて
クロージングしようかなと思うんですよね
自分たちが思うリーダーシップだけ
ポンって投げるとき
次このエピソードを聞き終わった後
じゃあどうしようかなっていう
ところになってしまうので
リーダーシップを磨いていくっていうのは
またこれも深いトピックだとは思うんですよね
やっぱりこう実際に
リーダーシップに書かれた本
っていうのがたくさんあるし
それを読んだ瞬間にリーダーシップ身につくもので
もちろんないので
やっぱりその
色々現場で試していかなきゃいけないとは
思います
だから僕が一つ考えてるのは
そのリーダーシップをまずは言語化する
リーダーシップの一貫性と責任感
ken
例えばそのエンカレッジメントする
でもいいしフィードバック与える
みたいな言語化した上で
それを実際に
現場で一つ一つ試していく
みたいな地道な方法
しかないのかなっていうのはあると思います
でもこれのリーダーシップって結構
割と幅広い
トピックのキーワードなので
それをブレイクダウンして
リーダーシップの中でも自分はこれが
まず今磨いていきたいっていうのを落とし込む
っていうのは一つありかなと思うんですけど
そうですね じゃあカズさん
ナオさんのほうで
何か思いとか意見とかあったりしますか
Kazunari Okuda
じゃあ私から
ken
そうですね
Kazunari Okuda
責任感持つっていうのは
そうですね
責任感持つっていう日本語も
難しいんですけど英語とかだと
オーナーシップとかって言って
結局
リーダーシップ
個人的に思うリーダーシップを
持つ人っていうのは
ちゃんと最後まで
自分で引っ張るというか
ちゃんと持って
自分で最後までやり遂げていく
結果それに
みんながついていく
っていうところがあるのかな
と思ってて じゃあどうやって
責任感持つのかっていうのは
難しいところなんですけど
そのノウハウは分かんないんですけど
結局リーダーシップを
持つ
ためにはどうするかっていうと
オーナーシップを
持つ
責任を
持つ
そんなのが近いんですかね
そう
リーダーシップを
磨いていくための
一つ
その中でいろんなものが
リーダーシップに必要なものが
得ていかれるのじゃないかな
ken
ってちょっと
なるほど
だからリーダーって結構いろんな
決断をしていくと思うんですけど
そこで起きてしまった失敗とか
ネガティブな影響に対しても
自分が
起こしてしまったことだから
リカバリーに入ったりとか
多分姿勢につながっていく
ってことですよね
Kazunari Okuda
そうですね
確かに
ken
なおさんどうですか
Nao
そうですね私が
磨いていく
これを結構
注力したいな
って思うのは
なんていうんですかね
その
チームメンバーが
私のことを
ゲスしなくていいような状態
要は一定であるっていうか
なんかあれ
なおこの間こうやって言ってたけど
なんか今日違うこと
言ってる気がするとかってなると混乱するし
私が
そういう経験をしたことがあって
それ結構自分にすごい響いたんですよ
なんか
で
そうするとすごい
いろんなゲスが自分の中に発生して
しまって
ものすごい混乱だったんですよね
自分の中でだから
一貫性がない状態
そうですね当然いろんなことが起きますし
チームの
人たちは知ってなくて
私はその他の人と
話してて知ってることとかっていうのも
当然リーダーっていう
ポジションまあマネジメントもそうだと思うん
ですけどそういうロールの人たち
ってあると思うんですけど
いつも一定で
ありたいっていう風には
努力していきたいなっていうのは
思ってて
強さとかスタイルとか
っていうのは別に私まだないんでそういうのは
これからそういうのは別に
自分のスタイルでいいと思うんですけれども
自分が一定じゃなかったら
そこに変な
フィルターがかかってしまって
素直に
簡単に喋ってくれなかったり
とか私が
今日は機嫌が悪そうだから
こういう言い方にしとこうとか
それがすごい私が望んでないことなんで
いつでも
一定でいるっていうか
何が起こってても
そういう状態を
でいられるように
っていうか
それを提供できるように
そこを結構磨きたいなっていう風に
思ってて
思ってますね
ken
たしかに
朝礼募会っていうね
四字熟語もありますけど
朝やったことと夜やったことが変わると
Nao
ついてくるのも大変ですからね
でもそれはそれでいいと思うんですよ
朝礼募会はいいと思ってて
なんですけど
説明できればいいと思うんですよ
ken
説明責任
Nao
そうですね
要はプライオリティは
バンバン変えていいと思うんですけど
でも今はこれっていうのは
はっきりしとくみたいな
今1,2,3,4,5ってなったけど
リーダーシップとマネジメントの違いについて
Nao
ごめんこういうことあったから5一番にするわ
みたいな
少なくともメイクセンスする状態
でもそこのスピードはめっちゃ早くてもいいと思ってて
てかむしろそっちの方がいいかなと思ってて
そのフレキシブルに
やってくれてることに対しては
やっぱりすごい感謝ですし
すごく評価できるところ
だったりみんなの
すごい重要なことっていうのも
言いたいなと思うんですけど
朝礼募会はどっちかというと
歓迎
ken
一貫性を保ちづらい状況に
自分を置かないように
気をつけてるのが
何か意見を言うときに
コン詰めて考えた意見は
来やすく言わないってことは気をつけてますね
えーどういうことですか
とりあえず意見を求められたから
3秒で思いついたようなことを
ポッと言っちゃうと
でもそれって後からもっと自分の中で考えると
いやこれ違ったな
常に自分が自信を持って
言えるオピニオンを言えば
その時の最適解であるので
後から
変えるときも説明席に
変えられると思うんですけど
ただ場を和ませる
場を進めるために
中途半端な意見は
言ってしまうと
それってすぐ自分でも変えたくなっちゃうので
そうですね
何か意見を求められても
自分にスキルがなかったり
言う権利がないなってときは
明確に僕はそのオピニオンを
持てる立場にはないから
後にしてくれもしくは彼に聞いてくれ
ってことを明言したりすると
そういう一貫性を
保ちづらいシチュエーションに
自分を置かないようには
Nao
回避はできるかなと
ですね
なるほどです 勉強になりました
ken
いや
Kazunari Okuda
それは面白いですね
例えばそこで
さっきの話も出てきたんですけど
出てきたのかな 出てきてないような気がする
そこで黙ってると
分かんないじゃないですか どう考えているのか
って他の人たちは
でもそこで私は
まあそういう意見を言える
立場ではないですよっていうことによって
なんて言うんでしょう
まあ周りの人が
Nao
ポジションを明確に示すっていうか
Kazunari Okuda
そうですね だから他の人が
ああこういう風に考えてるんだっていうのが
分かりやすいんで
ken
それっていいですね
でその上でこれとこれがあると
意見言えるっていうのも多分添えられると
最高だなと思ってて
この時点で僕はこの情報が足りないから
Nao
あのチームの彼と話した後でなら言えるよとか
ken
はいはいはいはいいいっすよね
あと
でもねちょっとこう
Nao
いや深いな
ken
そうですね
あっという間に1時間
本当ですね
これはもうちょっとね
なおさんの現場での
こう葛藤と
調整に引き続き
第2弾第3弾ととってきたトピックだなと
Nao
本当に思います
今こんなこと言ってますけどね
どうなってるんだろうか数ヶ月後
完全自信喪失
自信喪失みたいな
もう何も言えることない
ken
もう私から何もしゃべることはあります
やっぱりリーダー経験する人って
そういう段階も得ると思うんですよ
リーダー経験とバランスの取り方
ken
ほとんどの人が
なんかこう
いや上手くいかなかったな自分のスタイルが
みたいな
Nao
そういう時に乗り越えられるっていうのも
何が必要なのかみたいな
そうですねやっぱりICとすごい違うのは
プロジェクトが終わったとか
明確な成功みたいなのが全然なくて
何も
みんなも調子良さそうで
自分もオッケーで
みんながハッピーそうだったらって
すごいふんわりした状態で
なんかそのサクセスがすごい見えにくいんで
自分で結構バランス取るっていうのも
結構あれかなと思います
終わったみたいなのもないから
ken
あーわかる
そこはねすごいわかる
SRDとかもそう原点法なんで
基本
障害起きたらダメだから
うまくいってる状態が
Nao
普通みたいな
そうですよね
Kazunari Okuda
私も
それが一つの理由で
あんまり
people managerやりたくないなと思う
理由なんですよね
行動の方が単純なんですよ
人って難しいですよね
正直
難しいと思います私的にはですね
人を扱うっていうのは
だからコードのスキルだなと
私は思いますし
そこまで
自分ができるのかなっていう自信と
あと
そこまでやりたいのかなと
正直思うところは
ken
ありますよね
そういうキャリアと
関連付けた時の悩みってのもありますよね
じゃあちょっと今回は
まだまだ話し足りないとはいえ
一旦第一弾ということで
リーダーシップについて話して
なおさんとかずさんと話してきました
ではリスナーのみなさんぜひ
第二弾第三弾と出していきたいので
今後も楽しみにしてください
今回話したトピックで
ここも少し詳しく聞いてみたいとか
なおさんのこういうチャレンジ聞いてみたい
みたいのがあればぜひお便りお待ちしております
今日はなおさん
かずさんありがとうございました
Kazunari Okuda
ありがとうございました
