次 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をつけていただける と嬉しいですではお疲れ様でした