オライリーの「技術リーダーシップのための14のヒント」を読んで、これは参考になった!と思った内容を話しています
■参考URL
技術リーダーシップのための14のヒント
https://www.oreilly.co.jp//books/9784814401178/
■プロフィール
つねぞう
ものづくりが好き。産業機械メーカーで設計をしている。猫を飼っている。
■文字起こしLISTEN
下記で文字起こしが読めます。
https://listen.style/p/designreviewfm
■番組へのお便りはお気軽にフォームよりお送り下さい!
https://forms.gle/yi27jVHA2kBi7Vpj6
Podcast アプリなどでレビューしてくれると大変励みになります!
Xアカウント: @tsunezo_works
■番組内で「OtoLogic」様の素材を使用しています
サマリー
エラスティックリーダーシップに関するエッセイ集をもとに、技術リーダーシップにおける14のヒントが紹介されています。具体的には、チームにおけるリードの重要性やメンバーの成長促進、コミュニケーションの質を向上させる方法について考察されています。このエピソードでは、技術リーダーシップに関する重要な14のヒントが紹介され、特にリーダーの役割やOSS開発におけるリーダーシップのあり方が強調されています。また、静かなリーダーシップや成長するリーダーの育成についても触れられています。さらに、このエピソードでは技術リーダーシップにおける「良い兄貴」にならない重要性が議論され、リーダーやマネージャーが真の問題に集中する必要が強調されています。加えて、組織の成果に繋がる効果的なマネジメントについても考察されています。
リーダーシップの基本
こんにちは、つねぞうです。
DESIGN REVIEW FM第92回目、始めていきましょう。
今日はですね、技術リーダーシップのための14のヒントという、
これはエッセイ集なのかな?
そういう資料をちょっと読んで、
なるほどなと思うことがありましたので、
ちょっとこちら紹介したいなと思います。
技術リーダーシップのための14のヒント、
これはですね、オライリーから出ている
Elastic Leadership Growing Self-Organizing Teamsの
日本語版の特典として収録された14のエッセイを
独立した書籍として再編集したものだそうです。
こちらが無料で公開されているというのを
Xで見ましてダウンロードしてみたというところですね。
オラリージャパンのホームページで
一応登録は必要なんですけど、メールアドレスとくらいかな。
登録は必要なんですけれども、無料でPDFがダウンロードできますので、
もしこのポッドキャストを聞いて興味を持った方は
ぜひダウンロードして読んでみてほしいなと思います。
内容としてはこのソフトウェア開発だったり、
そういうソフトウェア開発の技術でリーダーシップを取り組んでいる方に向けて
その技術リーダーシップに関するさまざまなヒントというものを
14の異なる視点からエッセイ形式で書かれているものとなります。
目的としてはこれらのエッセイが改めて多くの人々に触れて
さまざまな場所で新たなリーダーシップが生まれるきっかけになることを
願って届けられているということです。
もともとこのエッセイが収録されていた
エラスティックリーダーシップ777という書籍は
もう既に販売されていないそうで
エッセイが埋もれてしまうのがもったいないなということで
まとめられたそうですね。
では早速、14章ですね。
14章ありますので、それぞれ簡単に説明していきたいなと思います。
まず1章は関さんという方のリードについてですね。
まずここはリーダーシップとは何かというところから考えて
リーダーシップをするのはリーダーですよと
そのリーダーがするのはリード、リードすること。
そのリードとは何かということで
リードとはチームを変化させる言いにくいことを発言することであると言ってますね。
言いにくいこととは何かあの設計おかしいなとか
誰か決めてくれないかなとか
もうめんどくさいなとかそういうことですね。
リードとはチームを変化させる言いにくいこと
これらの言いにくいことを発言することであると。
そして特定の役職者だけではなくチーム全員が発揮できること
それがリードであるということですね。
この言いにくいこと、あなたが言いにくいことは
他のメンバーも気になっていることであるということです。
そしてチーム全体でリードすることによって
発言の頻度が増えたり
それによって見つかる問題の多様化
そしてあなたの指揮、あなたっていうのは我々ですね
この私たちの指揮が下がったとしても
大きな問題にならないと
そういうメリットが生まれるということです。
そしてあなたがリーダーという立場であれば
チームのメンバーの発言を即して
そしてその発言を大切に扱うことで
チーム全体のリード
言いにくいことを発言することですね
そういうリードをサポートする
そういう方が大事ですよということです。
チームの成長促進
そうなんですよね。
ちょっとこの自分が設計していて
その隣のユニットの設計を見た時に
なんかここ無駄なことしてるなとか
この部品変な形だなと思うことは
もちろんあるんですよね。
その時にそれを気兼ねなくというかね
ちゃんと指摘できるかどうかというのは
非常に重要なことだと思います。
2つ目、第2章は
永瀬さんという方が書いているんですけども
チームに成長してもらうためのリーダーシップ
ということでチームを成長させるのではなくて
チームに成長してもらうことが大事であると
リーダーシップというのは
特定のリーダーだけのものではなく
チームのメンバーがお互いに発揮し合うことができると
そしてチームに成長してもらうためには
まず自分自身が学んで成長する姿勢を見せることが大事であると
そして他人の成長にも興味を持つことが重要であると言ってますね。
そしてチームのメンバーへの権限の譲渡だったり
個々の人の個人の成長を可視化できるよう手助けすることが
チームの成長を促すリーダーシップとなりますよと言っています。
チームに成長してもらうためには
まず自分自身が学び成長する姿勢を見せるということで
ただチームメンバーにこの本読んだ方がいいよとか
あの展示会に行った方がいいよって
口で言うのは簡単ですけども
そういうふうに言うだけじゃダメだと
自分が率先してこの本を読んで
その本の内容を本で学んだ内容を共有してみたり
自ら展示会に行ってその展示会で見た面白かったものを
共有してみたり
もしくは何か視覚的なものを取ったよという姿勢を見せたり
そういうことが他のチームの他の人の成長にも
つながるよというと書いてます。
あとは個人の成長を可視化できるように手助けするというところで
そのプロジェクトをあるプロジェクトをやってる間に
みんなで日記を書くということを紹介してましたね
その日記っていうのはそのプロジェクトの間は公開しないと
なのでそのプロジェクトの間はある程度好き勝手
見られたら困るようなことも書けると
そのプロジェクトが終わった時にお互いに公開しましょうというところで
他のメンバーにプロジェクトをやってる間にどういうことを考えていたのかとか
そういうことが共有できる
そういうことをやってたそうですね
コミュニケーションの改善
次第3章。3章は海野さんが書かれた
コミュニケーションメンテナーになるという章で
こちらはですね自己組織化チームにおいて
チームのリーダーはチームのコミュニケーションメンテナーとして
そのコミュニケーション手段の設計だったり
運用改善を担いましょうということが書いています
基本的にはその情報を共有する場っていうのは
オープンにするべきであると書いていて
もしそれがそのクローズな場所で情報の交換だったり
コミュニケーションしてしまうと
誰がどの情報を把握しているかとか
情報は誰に伝えるのが適切かというのを
常に考える必要があると
そういうことを考えながらコミュニケーションを取るということは
不要な負担を強いているということを書いていますね
なのでその情報共有というのは基本的にはオープンの場
全員が見れる場所でやることで
それに加えてそのメンバーの特性だったり状況に合わせて
いろいろなコミュニケーション手段を適切に使いましょうと言っていますね
その対人が苦手な人だったり
チャットでチャットとかで済むような内容も
直接話さないと気が済まないという
いろんな人がいると思うので
そういうメンバーの特性に合わせて
適切なコミュニケーションをしましょうと
一見無駄に思えるような雑談の情報も
気軽に共有される場を作ることで
新たな価値が生まれることがあるということで
この一つとして日報を書くことを紹介していて
その日報には仕事に関係ないことも当然書いてもいいと
そういう気軽な場にすることで
さらっと仕事上の悩みとか
こういう問題が今持っているんですよということを
日報に書くとそれを見た誰かがコメントをして
問題が解決するとか
そういういいことが
新たな価値が生まれるといいことですね
そうなんですね
雑談上で
例えば同じチームじゃない人にも
違うチームの知り合いにも
雑談で今こういうことをやってますよとか
こういう問題が今起きているんだよね
という話をすることで
新しいヒントがもらえたり
うちではこんなことをやってるよとか
こんな部品見たよ
こんな製品見たよとかね
そういう情報がもらえることは当然ありますので
そういう一見無駄に思うような雑談というのも
重要であるというのは私も感じています
4章
困難に立ち向かうチームのリーダーへということで
江澤さんというのかな
ここで書かれていることは
リーダーは自身の考えやその理由
そういうふうに考えた理由をオープンに
特になぜそう考えるかというのを
オープンにすることが大事だと
それを繰り返し伝えることで
メンバーの自発的な行動を促す推進力となると
自分の考えというのは
本当に何もしないとほとんど伝わっていないと
考えるべきだということですね
彼はいつもそう言ってるよねと
周りの人に言われるぐらいに言わないと
それぐらい言われると
伝わったなというふうに考えるべきだと
そして
メンバーの話を聞くこと
聞く方法としては
101とよく聞きますよね
101ミーティング
1対1のミーティングをして
メンバーの話をちゃんと聞きましょうと
どうなんでしょうね
ソフトウェアの方では101とよく聞くんですけども
私たちのようなメーカー開発
製品開発の場で
あまり101をやってるっていうのは
ちゃんとやってるっていうのは聞いたことがなくて
日々の雑談はあるんですけども
本当101で話すってことは
本当期末半期に一度の評価の時ぐらいかな
うちはねと思っています
101を実施して
メンバーの話を聞きましょうとか
アンケートを取りましょうって書いてましたね
今のチームの状態
チームの状態がいい状態なのか
悪い状態なのか
それぞれメンバー自身が今
どういう精神状態にあるとか
そういうアンケートを取るっていうのも有効ですよと
そういうメンバーの状況を知ることによって
問題の本質を正しく理解することが非常に重要であると
そして今困難な状況に立ち向かっているチームというのを
ポジティブに導く
そのチームをポジティブの渦に巻き込むことが
リーダーに必要であると
そのリーダーが無理だと思ってしまったら
メンバーも簡単に無理だと思ってしまう
メンバーが難しいことに立ち向かっている時には
やろうと言ってあげることが
そのチームが一歩前に進むために必要なことであるということですね
その最初の一歩を踏み出す勇気を与えることが
リーダーの役割であるということです
確かにね
上のリーダーマネージャーが
これは難しいねやめようって言ってしまうと
もうそこはそこでおしまいになっちゃいますかね
いくら係員がやりたいですと言っても
そこは続けられないということで
一歩前に踏み出す勇気を与えるそれがリーダーシップであると
次第5章コンセプチュアルリーダーシップということで
ここはですね
広角機動隊の公安休暇の
荒巻課長のセリフをまず紹介してますね
我々の間にチームプレイなどという都合の良い言い訳は存在せん
あるとすればスタンドプレイから生じるチームワークだけだと
いうことでどうすればこの休暇のような
最強に自己組織化したチームが生まれるのでしょうかと
自己組織化というのは自主的にかつ適切に問題解決を行うチーム
それが自己組織化したチームということで
そういう自己組織化チームの実現には
チームが目指すべき強い共通目標や
ビジョンとしてのコンセプトが不可欠であると
リーダーというのはそのチームが進むべき道筋をコンセプトとして示して
その実現に向けて導く概念的
コンセプチュアルなリーダーシップを発揮するべきであると
このリーダーシップというのは特定のトップだけではなくて
多くの人々がそれぞれの役割や視点からコンセプトを策定し
技術リーダーの役割
周囲をリードすることで発揮されるであろうということで
例えばどんなコンセプトがあるかというと
一つ目の例として滑らかなシステムというコンセプトですね
この滑らかなシステムというのは
研究機関の例なんですけど
研究としてアカデミックなところもやりながら
それを実サービスに適用して事業成長
事業を成長させるまでを滑らかにつなげましょうという
コンセプトですね
2つ目のコンセプトとしているだけで成長できる環境
そういうチームに所属しているだけで成長できるような
そういう雰囲気づくりだったり
精度をつくるそういうコンセプトですね
そして3つ目のコンセプトとして速
生産性の向上というのは大事なんですけど
具体的に何をすれば生産性が向上するかというのは
人によってイメージするところがまちまちであると
ざっくり言うとアウトプットをインプットで割った値
それが生産性であると
その生産性を向上させるにはインプットをできるだけ少なくする
もしくはアウトプットをできるだけ大きくする
アウトプットをできるだけ大きくするという2つの方法があります
ただインプットをできるだけ小さくするというのは
消えていく方向になってしまうのでアウトプットをできるだけ大きくしましょうと
そこで思いついたのが即というコンセプトであるということですね
早いことが良いことだというコンセプトだそうです
そういうコンセプトを持つことで チームがそれぞれどういう働き方
をしたらいいかということが分かる でしょうということですね
OSS開発におけるリーダーシップ
次 6章 OSS開発のリーダーシップ ということで ここは松本博之さん
ですね Rubyを開発した松本博之さん のところで OSS開発プロジェクト
においては プロダクト ルビーとは何かという 自明ではない問いに継続的に
答え続けることが最大のリーダーシップ であると チームのモチベーション
を高めるようなビジョンを提示 することもリーダーの重要な役割
であると そしてメンバー間の相互 リスペクトを維持し リーダーとしての
責務 維持することがリーダーとしての 責務の一つであると 強力なリーダーシップ
っていうのはリスペクトを失い がちであるので 気をつけましょう
ということですね どうしてもリーダー マネージャーという責任者という
立場が強い人 そういう強力なリーダーシップ リーダーシップを持っている人
っていう発言っていうのは 他の メンバーを萎縮させるというか
従ってしまう方向になりがちなので そういうところもちょっと気をつけ
ましょうということですね 次 7章 刀は堂々と抜け 兼任リーダー
の心得ってことで 開発者とリーダー を兼任する場合 技術変化が激しい
時代では控えめにではなくて 刀は 堂々と抜くように開発に関わる
べきであると 廉価の砲刀をこっそり 抜くんではなくて 堂々と抜きましょう
というのは 私たちの身の回りの 状況 特にソフトウェアっていう
のは環境の移り変わりが凄まじい ので 廉価の砲刀というのはすぐ
錆びついてしまいますよと なので そこをもったいぶって抜かない
ので 堂々と抜いて鍛えましょう ということですね リーダーも
積極的にその開発に関わって技術 取得を続けることで その刀が錆
びつかずにチームメンバーとも 相互理解が深められますよと リーダー
がそのすべて情報 技術を知っている わけではないので 部下だったり
メンバーに鍛えてもらって技術を 身につけましょうと そのメンバー
から指摘を受けることもリーダー 自身のスキルアップにつながる
ので 共に働く経験から学びを得る ということが非常に重要である
よというふうに書いていますね 発祥 リーダーシップは誰のもの
か これは田辺さんという方ですね 静かなリーダーシップというふう
に書いていて リーダーシップっていう にはさまざまな形がありますよ
と 厚く語るタイプではなくても 静かなリーダーシップとして発揮
することが可能であるんじゃない かと 静かなリーダーシップとは
こうあるべきだと宣言して周り へ説明しながら地道に進み続ける
ことで結果的に周りを巻き込んで 変化を起こすことであると それが
静かなリーダーシップであるって ことですね リーダーシップっていう
のは未来を描いて明確な意思を 示すことであり 示された方向性
とそれを実現させるための具体的な 推進をセットで行うことが重要
であるというふうに書いております ね その厚く厚い思いで周りを振り
立たせて引っ張ることができなくても ちょっと不安だなという気持ち
の中に一歩踏み出してそこに価値 があると信じて歩み続けること
で周りもついてきてくれるんじゃない かというのが静かなリーダーシップ
の話ですね はい 9章9つ目は一緒に成長できる
リーダーを育てようということで 障子さんが書かれた章になります
リーダーシップっていうのは浮いて いないものではなくてプログラミング
のように学習し実践することで 身につけることができますよと
そのとき注意しなければいけない のが前任者だったり自分のリーダー
だった人と同じことをしすぎない ことが大事ですよと
ピーターの法則っていうのがあって 簡単に言えば能力主義の会社では
人は能力の極限まで出世し結果 みんな無能になってしまうという
法則ですね 優秀なメンバーAさんがいたとして
優秀なのだっていうことでチーム リーダーになりましたとチーム
リーダーとして力も発揮したので さらに上の役職の管理職になりました
しかし残念ながらAさんは管理職 では力を発揮できなかったという
ようなものですね 自分自身のリーダーシップを伸ばす
ためにはそしてチーム全体にリーダーシップ を発揮してもらうためにはリーダー
を育てるという活動が非常に有効 であるというふうに書いています
その管理職になるマネジメントの 部分だけを見てそういうリーダー
シップを取りたくないなと思っている 人は多いとただその中には技術
的なリーダーシップを取ることを 目指している人は多いんじゃない
かとなので厳密にはそのマネジメント とリーダーシップというのは切り分け
られないかもしれないけれども まずリーダーシップを意識して
覚えてもらうことが大事であります よということですね
メンバーにトップダウン志向理想 ゴールと現状を比較し何をやる
か考えるというトップダウン志向 や自分の仕事の影響範囲を意識
させることで個々のリーダーシップ を促すことができますよと書いて
ますね 10章採用プロセスについてもっと
考えようというので吉原さんかな 吉原さんというのかな今まで他の
リーダー育成と採用プロセス
人の章ではチームを成長させる 方法についてさまざま書かれて
いましたが実はチームのメンバー をどのようにして集めるかという
のも非常に重要でありますよと 良い人を採用することはプロダクト
だったりチームの成功に不可欠 であり採用活動は開発作業と同等
かそれ以上に重要なリーダーの 仕事であると書いてますね
採用後のミスマッチを減らすために 無理をして採用しない判断や候補者
がチームの文化に合うかを見極める ことが重要であると
採用プロセス自体もソフトウェア 開発と同じようにデータに基づき
継続的に改善していくべきである と書いていますね
ちょっと今私に当てはめて考えて みると開発のメンバーが直接その
採用プロセスに関わることはほとんど なくてたまに課長マネージャー級
の人が採用試験の面接官をやる ことはあるんですけども人事権
はないので上の人にこういう人が こういうメンバーが欲しいなという
希望を出すぐらいですかねそういう 希望を出すことも大事ということ
ですかね
11章あなたは少なくともあなた自身 のリーダーである居原さんの章
になりますリーダーというのは特別な 存在ではないということを書いて
人は誰でも少なくとも自分自身の リーダーであると自分の行動は自分
だけが決められる自分自身のリーダー シップとは自身のやりたいこと
だったりやるべきことを自分で決め そのために自ら一歩を踏み出し
行動することであると特別な採用 は必要なくて自分で考え自分で
行動を始めることだけが重要であり 組織にいるのであれば関係者全員
がウィンウィンとなる行動を目指す べきであるとこれは本当そうです
よね自分の行動を決めるのは自分 でありますので自分自身が自分の
リーダーであるとなるほどねただ その行動を決めるときに自分勝手
に行動するんではなくて自分が 所属している組織の関係者全員
がウィンウィンとなるそういう 行動を目指すべきであるとそこが
一番大事ですね12章うまくいったら どうなるのということで関さんの
章となりますこの関さんが所属 するところではチームではうまく
いったらどうなるのというふう に聞くよくそのチームでよく使う
フレーズとしてうまくいったら どうなるのっていうのがあるそうですね
これはこれから行う作業が成功 したときの具体的な様子だったり
その結果を確認する方法をイメージ するプラクティスであると練習
であると期待する結果だったり 確認方法を考えることで現実的
で的外れではないゴール設定が 可能になり始める前に問題点に
気づくことができますよとある 設計変更をしようとしたときに
組み立てとか製造現場から要求 があって設計変更をやろうとした
ときにそれがうまくいったらどう なるのと考えることでただ言われた
からやりましたのではなくてこれ を変更することで組み立て工数
が5分10分減りますよとかお客様 での障害が減りますよとかそういう
ことを考えましょうということ ですよねあと具体的な作業ステップ
だったり締め切りっていうもの をチームで共有することで協力
しやすくなり発生しそうな問題 やリスクをチーム全体で扱うことが
できますよということも書いて いますねうまくいったらどうなる
のこれちょっと使ってみたいですね 13章現場リーダーのための6つの
原則平鍋さんの方の章となります リーダーシップっていうのはチーム
を機能させ活性化させるための 技術だったりスキル特にファシリテーション
に大きく寄与する現場リーダー っていうのはチームの状態を見える
化し築や知識に名前付けを行い 良いことから始める始め良ければ
全て良しの原則を用いるべきである とチームの状態を見える化する
っていうところなんですけども あるエクセルシートをサーバー
に置いてそういうサーバー上の ファイルに進捗状況を書いてみんな
で見てねというふうに連絡した としてもどれだけの人が見るでしょう
かとそのコミュニケーションを 結ぶ情報路っていうのは短くな
ければいけませんと じゃあどうやって情報を共有
するべきかというと目に見える ように壁に貼り出しましょうと
書いてますね もう理想的なのは野球の表示板
野球場とかに行くと今点数だったり 今打中の人だったりそういう情報
が書かれた表示板があると思うん ですけどもあれが理想であると
全ての情報が一箇所に大きく書 かれて全員が見える状態になって
いるこれが最もよい見える化の 例と言えるでしょうとそして名前
付けチームがその改善を重ねて いく過程でノウハウだったり知識
ナレッジという気づき暗黙値という ものが蓄積されますよとそれは
もう暗黙値なのでそれぞれ個人 の中にあってそれを口に出すこと
で初めてチームとして共有されます と問題は共有されたものをチーム
としてどう扱うかあるいはチーム を超えてどう伝えるかというのが
大事であるとその気づきによって 得られた知識ナレッジをチーム
に定着させたりチームの外の人 に伝えるにはどうしたらいいか
そのためには名前を付けましょう ということですね名前が付いて
いれば伝えやすくなりますよと 何とか方式みたいなね名前を付け
良い兄貴の危険性
ましょうということなんですか ねチームに一定のリズムを作り
出すこと問題対私たちの構図で 問題に取り組むことそして小さな
改善を繰り返すことが重要である ということも書いていますねその
ためには机の配置も重要である というふうなことも書いています
14章大事な問題にフォーカスする 伊藤直哉さんチームが良くなれば
プロダクトや事業がうまくいく という考えは多くの場合で願望
に過ぎず真の問題を見極める必要 があると開発組織のリーダーや
マネージャーの重要な成果はチーム ビルディングではなく事業やプロダクト
の成果を見出すことであるとリーダー は真の問題にフォーカスしチーム
はそのバイアスから解放されて プロダクトや事業技術の難しい
問題に立ち向かうことを促す役割 を担うべきであるということで
この章の中の良い兄貴にはなって いけないというところは私もすごい
響きまして良い兄貴になってはいけない と簡単にその良い兄貴になって
しまうリーダーやマネージャー がいませんかということですね
その良い兄貴になってしまう人たち っていうのはチームの自己組織化
のために働きますとチームメンバー が自分たちの開発に集中できる
ように率先してそういう雑用的な ところを巻き取って面倒な書類
仕事を片付けてくれるとそして 101の面談を頻繁に行ってメンバー
の悩みに耳を傾けますとそして リスクを取るため背中を押します
とそういう彼らの良い兄貴のおかげ でチームの状況は良好であると
ただそのチームの状況が良好であれば うまくいくかというと必ずしも
そういうことはないよと良い兄貴 っていうのはチームを良い状況
にはできるんだけどプロダクト だったり技術のリードができない
じゃないんですかと戦略を描く ことができないで本当に技術的
に大事な意思決定のときに良い アドバイスができないとなぜなら
その日頃から良い兄貴ばかりを しているからですと事業や技術
をリードすることはせず人の面倒 ばかりを見ているから技術をリード
しなければいけない場面になっても それがわからなくなってしまっている
のですと良い兄貴っていうのは 本当に組織が困ったときつまり
事業が伸びないプロダクトが使 われない技術的に困難な課題で
つまずいてしまったこういう時に 役に立ちません勝ちたい時でも
サッカーフィールドに投入する ことができないリーダーそれが
良い兄貴ですと人は簡単に良い 兄貴になってしまいますチーム
の誰それが今の仕事に満足していない 彼が組織に不満を持っている彼女
が辞めたがっているなどなどこの 手の話題はチームやリーダーを
大いに不安にさせます強い意識を 持っていかれますそして問題放置
し続けたらメンバーから嫌われる かもしれない人間なら誰もが思って
当たり前の感情が頭を持たれて きますだから君細やかに人の問題
に対処する小さな問題に対処して ありがとうと感謝の言葉が帰って
きたことで安心する日々小さな問題 ばかりに対処しているからやがて
大きな問題はわからなくなって 対処できなくなる小さな仕事しか
できなくなるから小さな問題解決 に対応するこれは悪循環ですよ
とそうなんですよね本当そうだ と思いますよいいやりきっていう
のは悪魔の誘惑小さな問題っていう のは悪魔の誘惑でばかり対応している
と大きな問題に取り組めなくなって しまいますよとなんでその組織
が組織のリーダーだったりマネージャー の最も重要な成果っていうのは
そのチームビルディング良いチーム にするそのものではなくて当然
そこも大事なんだけどそこだけ ではなくて事業やプロダクトの
成果を出すこと期日までに製品の 設計を終えて予定どおりにリリース
することそれが一番大事なこと ですよとリーダーに求められる
のは真の問題を見極めてそれに フォーカスすることが大事ですよ
ということですねその良い兄貴 のようなチームへのきめ細やかな
配慮だったりサポートが不要という わけではなくてそれも当然大事
なんだけども本来リーダーがやる べき問題解決から逃れるための
言い訳になってはいけないよと いうことですねそこが一番大事
ですよということを話しています はいということで1章から第14章
成果を出すことの重要性
まで紹介してみました本当にいく つか実際実践してみたいなという
内容もありますしなるほどなということ がありますので皆さんもぜひ日々
の業務に活かしてみてもらえたら なと思います
はいアフタートークですあの2週間 ぐらい前かなXの方であるポスト
をしたんですけどもそれがものすごい バズりまして全然技術とか設計
に関係ない内容なんですけども ある電信柱に蜜蜂が集まっている
ような写真を投稿してこれなんだろう という投稿をしたんですねその後
その朝だったんですけど朝そういう 投稿をして帰り同じ電柱に来て
みるとある張り紙がありました とその張り紙にはこの絵はその
文法分ける8と書いて文法という ものですよと皆さん静かに見守り
ましょうねという張り紙がして あったんですね文法というのは
蜜蜂が女王蜂が新しい巣を求めて 引っ越しをするそういう仕組み
というかものなんですけども温か く見守りましょうねって張り紙
があってそういうこともあるんだ ねというとこでもう1回それをポスト
したんですねなんかすごい反響 がありましてびっくりしました
ね一番びっくりしたのが移住員 さんラジオの移住員さんがラジオ
の中でチラッとその話をしてくれ たんですよそういう張り紙をしている
のを見たよみたいな驚きました ねちょっと全然技術に関係ない
ポストだったんですけどもそういう ことがありましたということで
今日はここまでですpodcastの感想 質問は概要欄にあるgoogleフォーム
からお待ちしております各podcast アプリでのコメントからもお待ち
しておりますまたこの番組はいい なと思ったらぜひフォローと評価
をお願いします星5をつけていただける と嬉しいですではお疲れ様でした
36:48
コメント
スクロール