第6章 スケールするリーダー
6.1 いつでも決定せよ
6.1.1 飛行機の比喩
曖昧(ambiguous)
「曖昧」に対応する英単語にはfuzzy, vague, obscure, ambiguous があって、明示されているのは読者への信頼を感じる
ambiguous は「意味が複数ある」曖昧さ。問題の捉え方が複数ある、という意図か
6.1.2 目隠しを特定せよ
そのような人々は、非常に長い間その問題に浸かっていたた めに「目隠し」を装着している。
自分が「目隠し」を装着していることに気づいて、それを外す方法、もしくは外せないけど目隠しをずらすことくらいはできる方法ってないものかなーと思う
チームが安定していればしているほどメンバーが変わらないので「目隠し」を装着しがち、というジレンマ
OSTやってるイベントに参加すると毎回「目隠し」に気付く
「幽霊の出る墓場」問題に通じる
6.1.3 鍵となるトレードオフを特定せよ
6.1.4 決定し、それから反復せよ
ケーススタディの例は、既存のトレードオフ関係を疑って、新たな制御可能な変数を見つけ出すといういい例だなあ
そうでもないのに勝手にトレードオフだと信じられていた例→「質とスピード」
6.2 いつでも立ち去れ
6.2.1 あなたのミッション:「自動運転」チームを構築せよ
6.2.2 問題空間の分割
開発がほぼ全自動で回るように移譲して行った結果、それ以外の仕事がマネージャーに集中して結局SPOFになった
かといって、開発外タスクを開発チームにたくさん移譲するのもなんか違う気がする
手順書整えといて普段はマネージャーがやって、手がまわらないときだけお願いするくらいのバランスが良さそう
手順書が整えられるなら自動化も視野に
「問題への解」を担当しているチーム、あるあるだな。。
6.3 いつでもスケールせよ
6.3.1 成功の周期
「不安になるくらいわくわくする」
いい言葉だ。インポスター症候群になりそうな時とかに使っていきたい
6.3.2 「重要」対「緊急」
知らなかった。値段も安いしとりあえずポチった。
6.3.3 ボールを落とすことを学べ
近藤の哲学は、家から出たがらくたの散らかりを全部効果的に片付けることについてのものだが、抽象的な散らかりに対しても効果を発揮する
話題になっていた記述だ
捨てられない80%の仕事を、「自分がやらないといけない仕事」あるいは「自分がやりたい仕事」と勘違いすることは個人的には多いなあと感じた。
割合で書いてくれているのはイメージがしやすい。「自分の仕事を20%にした結果、組織やチームが全く回らなくなるか?」というのは一つの目安として使えるのかもなあ。
6.3.4 自分のエネルギーを保護する
脳は自然に90分周期で動作している
論文あるのかー知らなかった。
6.4 結論
6.5 要約
みんなからのコメント
Googleにしかできないとしたら、それはなぜか?
あんまりGoogleにしかできなそうな部分はなかった。
あんまりしっくり来ない回答だけど、強いていうなら、心理的安全性をはじめとしたチームの土台ができていることなのかなあ。(自身が感じている不安を言えなかったりすると実現するのは厳しそう)
自分も強いてあげるなら、「管理職・上位職の人にはこういうことをやってもらうよ・こういう考え方で仕事に臨んでね」というのをきちんと伝えているからなのかなと思った(本当に伝えているかはわからないけど)
マネージャーという肩書きだけ与えられて、期待する振る舞いや役割のすり合わせや教育ができてない会社は結構ありそうだなと思い
現場でどこまでできているか?
いつでも決定せよ、の部分はできている気がした
いつでも立ち去れはなかなか。。できている人もいるが、自分の職場だとそこらかしこに単一障害点は発生していたイメージ(仕事の連絡を遮断するとかは絶対にできなかった)
いつでもスケールせよ、は半分くらい。メンタルヘルス的に厳しければ遠慮なく休むとかはやっていたけど、それでも仕事の連絡を断つことはできていなかった。
自分が管理職ではないのでわからないけど、権限移譲はあんまり行われてない印象(上位職の人が自らタスクをこなしているイメージ プレイングマネージャー的な)
管理職だから事務処理や打ち合わせが多いものっていう諦めもあるような気がする
出社しているとちょっとした相談をしたくても空いているところに話しかけることが出来なくてoutlookで30分単位の打ち合わせを設定されて、打ち合わせ祭りになっている人もいる気が。みんなどうしてるんだろう。(oViceとかバーチャルオフィス的な仕組みが有効かと思ったけど全然使ってない)
この本があるのになぜ実践する企業はすくないのか?
技術的卓越性のほうが評価しやすい(指標を作りやすい、短期的に評価しやすい、他と比較しやすい)っていうのがありそう。MBO的な感じというか。あとは事業における重複感を少なくできるからとか。ここにある「課題ベースでリーダー(チーム?)をわける」というのをやっていくと、チームに重複がでてきて収益率としては悪化しやすくなるっていうのがあり、判断が非常に難しいっていうのがあると思う。
っていうのを明確に言語化して考えている人たちがいるかは知らないけど、あるんじゃないかなーっていう。
なんとなくだけど、こういう形で管理職に求められる役割や姿勢を言語化できている会社が少ないのではと思う(習うより慣れろ的な)
Googleの再現性を大事にするエンジニア的な企業文化がこの言語化を生み出しているような気もしており、それだとしたらエンジニア的な企業文化を持つ会社の少なさが、実践できているGoogleの特異さを強調しているのかなと思った
管理職の立場ではないので想像するしかないが、Googleにしか出来ない理由はあまりなくて、それが管理職(マネージャー)の仕事という思い込みと、真面目な体質(少なくとも自社の管理職はみんな)なのかなと思いました。
手を抜く/サボる部分とか、ときめく/ときめかないを考えている人はいるにはいるけど少ない
それの乗り越え方はなにか?
マネージャーの横の繋がりをもつ 非公式な集まりみたいな 以前管理職になりたての人がベテラン管理職の人に「えっ、あれってそんなんでいいんですか」とか「そんなことまで業務委託でお願いしてるんですか」みたいな話をしていたことがあってそういった盲目的にやらねばならぬと思わされているケースがあるんじゃないか
ビジネスモデルとかビジネスのステージ別にどの程度はこういったリーダー的な振る舞いのために収益を犠牲にしていいのか?という目安があるといいかも?リーダージャーニーみたいな。
「エンジニアのためのマネジメントキャリアパス」?
ビジネス的なコンテキストが書かれていない
どのようなナレッジ領域があるのかを紹介する本
ステップを小さくするとしたらどうできそうか?
1on1でどこまでできているかの気づきを促したり、研修的なプログラムでケーススタディのようなものをやってみるとか?
OST