スモール・リーダーシップ
2019年4月7日
ついに役職がついてしまったので、それっぽい本を読み始めた。
スモール・リーダーシップ チームを育てながらゴールに導く「協調型」リーダー
改めて考えると当然のことだったりするけど、実際一緒に働くといろいろな要因で忘れてしまったりしそうなので、覚書として残しておこう。
一緒に考え、一緒に決め、一緒にコミットするチームを作ること。
これまで自分の上についた二人のリーダーは、「基本放任するタイプ」と「基本自分で決めるが、必要に応じて意見を求めるタイプ」の2つのタイプだったと思う。
前者はどちらかといえばチーム全員が横に並んで前に進むタイプのチームだったので、割とやりたいことをガンガン言えたし、自分の進みたい道を整備してくれたので、それはそれでよかった。 けど、それぞれのメンバーが進む方向がバラバラだったのもあり、人によっては放任されると結構ツライかなとも思う。実際自分もそう感じた時期がある。
後者は背中を見て学べタイプで、意見を聞いてはくれるもののだいたい否定された気がする。また、必要な時しか呼ばれないので、なぜそれが必要なのかとか、 リーダーがなぜそういう考えに至ったのかが今思うとわからなかったなと思う。
異なるタイプのリーダーの下についたことは今自分が人の上に立つ上で非常にいい経験になった。
チームが目指すべきは、常に新しい知識を吸収しつつ、その知識がチームに展開され続けるという、二つのバランスが取れた姿なのです。
これができたら苦労しないんだろうけど笑
たしかに、チーム内で担当を割り振ると、その人がいなくなった時に自分や他の人が学び直さなければいけないのは本当に無駄だと思う。 リーダーとしての業務をしながら知識を得るためには、メンバーから知識を展開してもらう仕組みが必要だ。
自分の側に準備ができていないと、その作業を通じて、何かを具体的に伝えることができないと感じるかもしれません。（中略）自分から伝えられない何かを、相手に引き出してもらうこともできるかもしれません。 そのためには一緒に働くことに対して何を期待しているのかを相手に伝える必要があります。
自分はメンバーがやりたいことしかやらせたくないという思いが強くて、やりたくないことは自分で引き取る傾向が強いと思っている。（自分もやりたいことしかやりたくない）
だけど、やりたくないことでもやったほうがいいことはたくさんあるので、そういう場合はなんでやったほうがいいのかということを伝えることを忘れないようにしたい。
支配型リーダーの弱点として、基本そういうチームのメンバーは指示待ち人間が増えてしまうので、
リーダーのやることが溜まってしまって、作業が終わっているのにリーダーの指示を受けられないメンバーが出てきてしまう。
ことと、
リーダーの指示が間違っていたら
どうしようもなくなってしまうことがあげられる。自分はそうなるつもりはないけれど支配型リーダーになるのであれば、サブリーダーとか相談役が必要が必要だと思う。
チームとしてミッションを成功させるためには、決まりごとを守ること、また、守られていない場合にそれを指摘し合うこと
は当たり前だと思うけど、なかなかできない。リーダーだから許されるみたいなことにはならないように気をつけたい。 でも、例えば遅刻しまくるリーダーに対して何も言わないのはリーダーだからではなく「別に遅刻したところで問題ない」と思っていたからであって、 そういうルールなら、いっそ撤廃してしまえばいいと思う。（ただし、会社的には問題あるんだろうから面倒なところだ）
スキルは通常、「知ってはいる」ことを時間をかけて繰り返し行うことで「できる」ようになるものです。
なるほど。どれだけ仕様書を読んで暗記していようとも、それはスキルではなくただの知識になってしまう。 ただ個人的には「自転車にめっちゃ詳しいけど自転車に乗れない人」は話し相手としてはけっこう好きかも。メンバーにはいて欲しくないけど。
チームの仕事において重要なのは、「誰がやるか」ではなく、「どの役割の人がやるか」という考え方です。作業を人に紐づけてしまうと、その人の能力によって作業範囲が決まることになってしまいます。
これは結構盲点だったなぁ。あの人ならここまでできるかやってもらおう、あの人はこれは詳しくないからやらなくていいとしてしまうと、当然後者は一生成長できない。 役割と、その役割がやることを明確に決めて、あとはその役割に誰を当てるかを決めるのがよさそう。
やらないことを定義して初めて、やることの範囲が明らかになるのです。
これはつねに実践するように覚書。
解釈とは、新しいものごとに出会ったときに、それを自分の世界観に位置付ける作業です。
だからこそ、人と人が同じ解釈をすることは非常に難しい。「分かった」と相手が言っても、その「解釈」が自分のそれと同じかどうかはわからない。 分かったところで終わらせないで、どのように分かったのかまでを確認するようにしないといけない。これはしつこいとうざいので程度に気をつけたい。
自分がAという意見を出したときに、あるメンバーが「AではなくBにすべき」という意見を出してきた場合に質問すべき事項は四つあります。
・「Bについてもう少し詳しく教えてください」
・「Aについてどう見えているか教えてください」
・「Bのほうがよい理由を教えてください」
・「Aではダメな理由を教えてください」
意見が対立した時は根本から食い違っていないかどうかをまず確認することが大事。その上で意見の相違がある場合は、
「誰の言っていることが正しいか」ではなく、「事実としてどうか」に焦点を合わせた議論を行うようにしましょう。
以下の名言は少々大げさだが、覚えておこう。
「私はあなたの意見には反対だ。だがあなたがそれを主張する権利は命をかけて守る」（ヴォルテール）
「相手の気持ちに同意することなく、それを理解し受け入れられるのは発達した心の証だ」（サーチ・インサイド・ユアセルフ）
「早く行きたければ一人でいけ、遠くへ行きたければみんなでいけ」
最後にリーダーとしてはもちろんチームを成長させることもミッションの一つだが、何をもって成長とするのかという点として
CMMI（Capability Maturity Model Integration）
というスキームが紹介されていた。簡単にまとめると、CMMIとはプロセスの出来を指標として定義したもので、
- LV1「初期」: プロセスなんてないよ！個人の力量で無理やり解決してるよ！って状態。スケジュールや成果物の品質は予測できない。カオス。
- LV2「反復できる」: 似たようなプロジェクトに関しては「以前のやり方でやれば大丈夫！」レベル。人によって解釈が違う可能性がある。
- LV3「定義された」: 「組織のプロセス」として文書化、標準化されている状態。あれ見てやって。
- LV4「管理された」: 成果物とプロセスの両方に対して定量的品質目標が定められている。成果物の品質がだいたい予測できる。
- LV5「最適化する」: 定量的なフィードバックによって継続的にプロセス改善が行われている
という感じ。もともとはソフトウェア開発のためのものらしいが、小さなチームにも応用がききそう。今はLV3の状態だと思うので、次は品質目標をきめて計測を行うところからかな。