ELASTIC LEADERSHIPという本を読んでいます。
いろんな方から「いい本だ」と聞いたので、超速読や速読ではなく熟読しようと思い、自宅のデスクでメモを取りながら読み進めています。
4章 サバイバルモードに対処する
今日のチームのほとんどがこのサバイバルモードにあると著者は考える。
私はサバイバルモードを「学習するのに十分な時間がない」状態と定義している
4.1 サバイバルモードかどうか
チームを数日間ユニットテスト研修に行かせることができるか。そのくらいは出来るとして、それを現場に適用する時間がとれるような状況になっているか。
こうしたゆとり時間を充分作れないチームは、すぐサバイバルモードになってしまう。
4.1.1 サバイバルな安全地帯
- サバイバルモードにとどまるのはとても簡単。
- 忙しい自分、に酔ってずっと続けたりする
- 火消しが心地よくなってしまったり、中毒的。
4.2 サバイバルモードから抜け出す
ゆとり時間をつくるのが大切。
ゆとり時間を作ったら、サバイバルモードではなく学習モードになれる。
4.2.1 必要なゆとり時間はどのくらいか
『ゆとりの法則：誰も書かなかったプロジェクト管理の誤解』によると、学習時間の生産性は通常の生産性の1/10程度。
テスト駆動開発に不慣れな開発者に、テスト駆動開発を学びつつ開発させようとすると、いつもの10倍の時間を見込まないといけない。
→ソフトウェア開発プロジェクトでコレが出来るようなところってあるんだろう・・・。業務請負だと相当ハードルが高そう。自社開発をしていてある程度体力がある会社でないと難しそう。
4.3 ゆとり時間を作り出すー必須のアクション
じゃあどうやってゆとり時間を作り出して、サバイバルモードにあるチームを学習モードへの引き上げるのか。
4.3.1 現在のコミットメントを確認する
今持ってるコミットメントを取り消さないといけない。
タスクボードを使って、タスクの可視化を行う。
→カンバン方式？なんにせよ、可視化は本当に大事。大事。
4.3.2 現在のリスクを確認する
著者オススメの手法が未来記憶というもの。
「今から６ヶ月後、プロジェクトが完全に失敗したところを想像してほしい。一体何が原因で失敗したと思う？」
と問いかけること。
あがった原因をリスト化する。
4.3.3 デッドラインを引く
→締め切りのないタスクは行われない、は当たり前だけどよくある。そして自分もやってしまう・・・反省。
タスクボードとリスクのリストで、今チームが持っているコミットメントが可視化できた。
「ゆとり時間」を仕事の中に組み込み開始するタイミングをデッドラインとして、そのデッドラインまでに火を消す。
デッドライン＝ゆとり時間を持った仕事を開始するタイミング が来たら、リーダーはチームのゆとり時間確保に全力を尽くす。
4.3.4 どうやってコミットメントを取り消すか
- タスクボードをステークホルダーに示す
- ゆとり時間を確保してチームが学ぶと、どんな良いことがあるのかを説明
- 今後の見通しを説明
- この取り組みによる利益を説明
4.4 なぜゆとりか？
ゆとり時間がないと、学習が出来ない。サバイバルモードを抜け出せない。
4.5 指揮統制リーダーシップ
自己組織化に向かうためには準備が必要。課題をメンバーだけで解決するスキルが不足していると難しい。
メンバーは、チームリーダーが問題を全部解決してくれると思っていることもある。しかし、これだと生き残れない。
4.5.1 悪い決定を正す
例えば、チームがソースコード管理ツールを使用しないことにしよう！と決定した場合。使用を促す。
悠長に議論するのではなく、正す。
まずはサバイバルモードを抜け出すのが先で、後の学習フェーズで時間を確保。
4.5.2 チームの強みを発揮する
ここは一旦得意な人に任せよう
4.5.3 障害を取り除く
チームに悪影響を与えるようなメンバーに対応。
一時的に部屋を分けるなり、別プロジェクトや別のチームに行かせるなど。
関連した話では、有名な「落ち込ませるようなもの禁止」ルールはいつだって通用する。そのルールの下では、あなたはチーム内の子どもじみた行動を禁止する。たとえば「それ絶対うまくいかないって思ってたんだよね」というようなフレーズは本書では「落ち込ませるようなもの」に数える。
→なるほど確かに。ソフトウェアテストや品質保証の面から考えると、たまにダメ出ししかしなかったり開発を言い負かすことにご執心の方がいる。誰かを落ち込ませても、チームにメリットが無い場合はすべきではない。
4.6 移行期間に行う必要のあること
4.6.1 チームとより多くの時間を過ごす
リーダーの時間の50%は、チームで過ごす。（＝別の部屋に居るのではなく）
そのために、不要そうな会議をスキップするなど。
まずは時間投資が必要で、それはあなたでなければならない。あなたこそがチームを率いているのだ。
→客先常駐のお仕事をしてるリーダーにとっては、時間に見合った個人の成果も出しつつメンバーの時間を確保するということで難しそう・・・
そもそも客先常駐してたら、明示的に学ぶ時間は取れなさそう。厳しい。
4.6.2 チームの主導権を握る
サバイバルモードのうちは、対ステークホルダーの唯一の窓口になる。
メンバーに直接依頼が飛んできて「はいやります」と言って学ぶ時間がなくなるのを防ぐ。
4.6.3 イエスと言うことでノート言う方法を学ぶ
依頼が来たら「よろしい、ならばタスクボードを見てみましょう」の流れ。
アジャイルのプラクティスと同じで、追加があったら優先順位を並び替える。
4.6.4 デイリースタンドアップを始める。
→これもアジャイルサムライで読んだような内容。
- 昨日何をしたか
- 今日何をするか
- 困っていることはないか
割れ窓を見逃さない。
→次項
4.6.5 割れ窓理論を理解する
4.6.6 本気のコードレビューを始める。
コードレビューなしにチェックインできない、というルールを設ける。
リモートでコードレビューするとあまり効果がないので、隣に座ってやるほうがよい。
4.7 チームが大きい場合は？
「ピザ２枚で足りる人数」を超える場合、小さなチームに分割して、小チームにリーダーが居るような状態を作る。
ref: 「2枚のピザ理論」で少人数チーム制を導入するIT企業 | 富裕層向け資産防衛メディア | 幻冬舎ゴールドオンライン
4.8 広域チーム（分散しているチーム）の一部である場合は？
定期的にメンバーが集まって隣り合って作業できるようにがんばる。他はリモートでなんとかする。
4.9 次にやること
本章の内容によって、サバイバルモードの中で学習するための時間を作り出せたはず。次はその後の、メンバーを自立させるところ。