エラスティックリーダーシップ
2022年11月27日
オライリーから出てるソフトスキル本の一つ、エラスティックリーダーシップの読書メモ。読んだのだいぶ昔なので、つまみ食いしながらまとめ直したけど、物理本で買ったので、大変だった。11章以降はエッセイ集なのでまとめない。
ちなみに5whysは本の著者がまとめたリーダシップに関するBlogがまとまっている。こちらも参考にできると思う。
まだ何者でもない
専門家はいない。わたしたちしかいないんだ。
いまだにあんまりしっくりきてないけど、自分が専門家であると過信し始めると、誰にも相談できなくなってしまう危険性があるということや、どんな問題も自分達で解決していかないといけないんだよってことを言っていると理解した。
昔会社にいた優秀な先輩が「まだ何者でもありません」って言っていて、かっこいいなぁと思ったのを思い出した。
うだうだ言ってないで手を動かそう
成功をもたらす秘訣の9割はマウンドに立つことだ。
なにを成すにもまずはやり始めないとだめだよねっていう当たり前のことだけど、それが一番難しいから秘訣として書いてるだよなぁきっと。
頭の中でいろいろな理想像はあって、それに向かって日々どういう生活をすればいいのかもなんとなくイメージはあるけど、その通りにやれないのは何にどれくらい時間がかかるのかがイメージできてないのが大きいのかなぁ。
自分でロジックを考えてプログラムを作るだけであれば、だいたいどのくらいの時間がかかるのかがわかるので、着手しやすい。
けど、勉強だったり、調べ物だったり、誰かを巻き込むようなことになると、未知の部分、知ることができない領域が多くてコントロールできず、マウンドに立つ気にならない。
ダラダラ過ごしてしまうのは、費やした時間分の見返りを特に求めていないからなんだろうか。まぁなんだかんだ言って、それがダラダラ過ごす結局自制心が足りてないだけなんだろうけど。
柔軟なリーダーシップが必要だ
チームが私たちリーダーに求めるものは刻々と変化していく…中略、特定のリーダーシップスタイルを押し付けるのではなく、継続的にリーダーシップスタイルを変化させるアプローチを採用する
正直とても難しい。たしかに人によって自分の言葉が刺さる人と刺さらない人がいたり、求めているものが違ったりするから、最適なリードの仕方は一つではないだろうと言うことは想像できる。が私は柔軟にコントロールできるほどできた人間ではない。
ちなみにこの本のなかでは「指揮統制」「コーチ」「ファシリテーター」の3つのスタイルが紹介されている。
いつどういうスタイルが効果的なのかはチームやプロジェクトの「フェーズ」に依る。
フェーズとモード
チームやプロジェクトにはフェーズとモードがある。
- サバイバル：学習する時間が十分にない状態
- 学習：十分なゆとり時間があり、その時間を使って学習や検証をを行っている
- 自己組織化：チームがリーダーの助けなしに自分達の問題を解決していける
いくら自分が学習モードであったとしても、プロジェクトがサバイバルフェーズであると、自ずとサバイバルモードになってしまう。フェーズとモードは切り離して考えられない。 プロジェクトが並行していると、一つのプロジェクトが学習フェーズであったとしても、もう一つのプロジェクトがサバイバルモードだとスイッチングが必要になる。
基本はサバイバルモードに引っ張られる気がするので、いかにしてサバイバルなモードを抜け出していくのかがポイントになる気がする。
サバイバルモード
なぜ抜け出さないのか？
- サバイバルモードにはある種の達成感がある
- 考えずにとにかく手を動かすことを求められるから楽
- これを抜ければ楽になれると思うと立ち止まるのが難しい
サバイバルモードを抜け出すには？
まずは学習フェーズに移行することを優先する。そのためにゆとり時間を作る必要がある。もちろんただゆとり時間を増やしただけでは帰る時間がその分遅くなるだけなので、何かを犠牲にする必要がある。
- 現在のタスクやリスクを洗い出す
- この日以降はゆとり時間を取る、という基準とするためのデッドラインを決める
サバイバルモードで必要になりうる指揮統制リーダーシップ
サバイバルモードでは、いろんな人の意見をあれこれ聞いている余裕はそこまでないので、リーダーがある程度決め事をして指示する進め方が最も効果的なことがある。
もちろんなんでもうまくいくわけではなく、決定に従わなかったり、士気を下げるような発言をしたりする人が現れたりすることもあるだろう。
たぶんサバイバルモードでは役割分担を明確にしておいたほうがいい。とくに、誰が何を決めるのかははっきりさせておくといい。
割窓を許容するな
一部のコードをレビューしなくても良いと言い出したらそれは割窓だ
これは〇〇だからレビューしなくてもいいや、と言い始めると、いろいろな言い訳がではじめて、レビューされないコードがどんどん増える。
サバイバルフェーズでは例外なくコードレビューを実施することが重要らしい。たしかにサバイバルモードはとにかく前に進むことを重要視する傾向があって、必須ではないコードレビューは明らかに優先度が下げられる。
ただ、なんでサバイバルフェーズから学習フェーズへの移行期間にやることの話でレビューが出てきたのかはよくわかってない。
たとえ短い期間であっても手本をしめそう。メンバーやリーダーシップの品質を妥協してはいけない。
ほかの章でどんなに短い期間であっても手本を示したり、今週は先週よりもよい状態、来週は今週よりも良い状態になっていることをこころがけるというようなことが書いてあった気がする。無意識に意識していたとおもう。
クリアリングミーティングと呼ぶ理由は、うまくいっていないこと、仕事についてしまいこんでいる悪い感情、共有すべき情報など、チームが知っていること全てを明らかにするからだ。
ミーティングを惰性でやっていることが多いけど、クリアにする事柄がないならやらなくてもよさそうだなと思った。もう少し目的を明確にしないと。
学習することを学ぶ
学習曲線は基本的には右肩あがりに推移するが、何か新しいことを学び始めたタイミングで必ず谷ができる。新しいことを学び始めるときは知っていることを忘れ、これまでの経験や安定したやり方から離れる必要があるからだ。
しかしその谷のあとは飛躍的な成長が待っている。谷というのは準備期間だ。その谷を受け入れて、飛び込めるかどうかが成長するかどうかの境目になる。
6つの影響力
何かをやろうとした時にどこに課題があるのか、なにをすべきかを見極めるためのツール。
- 個人のレベル：個人個人にタスクをやるためのスキルがあるか
- 個人のモチベーション：個人個人にタスクをやるためのモチベーションや理解があるか
- 社会のレベル：必要な支援、情報が提供できるか
- 社会のモチベーション：組織にタスクをやるためのモチベーションや理解があるか
- 環境のレベル：タスクをやるための環境が整っているか
- 環境のモチベーション：報酬につながっているか