ariyasacca

▼ [Software]『エラスティックリーダーシップ 自己組織化チームの育て方』

紙の本で帯に「まつもとゆきひろ」「平鍋健児」などの名前が並んでおり、日本語話者による共著の本なのかと勘違いしていたが、実際にはRoy Osheroveという人が書いた本の翻訳本で、日本語版にはおまけエッセイとして日本人ソフトウェア開発者による文章が寄せられているのであった。

本書の構成

• チームの状態によってリーダーシップを使い分けること
  • 「サバイバルモード」「学習モード」「自己組織化モード」の状態がある
• 寄稿者によるリーダーシップに関するエッセイと、Roy Osherove氏による分析
• 日本人執筆者のリーダシップに関するエッセイ（和訳版のオリジナル）

3つのモードについての文章まで読んでしまえば、あとは短いエッセイ集みたいなもので、空き時間に少しずつ読み進めることが容易になる。

合計で3～4時間くらいあれば完読できるのではないか。気に留まったところを記録しておく。

3章 バス因子に対処する

バス係数は、次のように定義できる。チームメンバーのうち何人がバスに轢かれたらプロジェクトあるいはチームが破綻するか。つまり、バス係数が1のときが最も危険だ。

ソフトウェアエンジニアやマネージャーにとってSPOF（単一障害点）は頭の痛い問題で、なかなか直視しづらい現実ではある。

ペアワークとかコードレビューとか、ちゃんとやった方がいいよねと改めて考えた。バス係数が低いと、おちおち有給休暇も使えんからなぁ。

4章 サバイバルモードに対処する

私がおすすめする手法の1つに、未来記憶というものがある。チームを集め、次の簡単な質問をしよう。「今から6か月後、プロジェクトが完全に失敗したところを想像してほしい。一体何が原因で失敗したと思う？」

これはなかなか良い問いかけだと思う。プロジェクトの立ち上げ期（いわゆるキックオフミーティング）などで使ってみたい。意地悪な性格の人が居たら雰囲気が一気に悪くなりそうではあるが。

20章 リーダーシップと成熟したチーム

「自己組織化」を神格化し過ぎるきらいのあるアジャイルコミュニティではリーダーシップの役割を小さくしようとする、リーダーシップがチームを安全地帯の外に導き、創発的な行動が促されるといった警告が書かれている。これはなかなか良いエッセイだなぁと思った。

Roy Osherove氏の分析でも、

何を分かっているか分かっていて、何が分かっていないかも分かっていたとしても、分かってないことすら分かっていないということがチームには常に存在する。

と問題提起されている。何となくスクラムマスターといった役割の人が意識しておくと良さそうだ。

24章 開発者が幸せな状態であれば、質の高い仕事が得られる

このエッセイはRoy Osherove氏の分析が本質だ。

私は、自分の見積もりには品質を向上させる時間を確実に含めるようにしている。たとえば、「それは合計でX日かかり、テストも含めるとX+3日かかります」とは言わない。私のXは、常にテスティング、TDD、コーチング、ペア作業の時間を含んでいる。それは仕事の一部なのだから、特に言及するようなことはしない。

見積もりを頼まれたらこうやって言い切りてぇ～～～。

38章 OSS開発のリーダーシップ

Matzことまつもとゆきひろ氏によるエッセイ。

OSS開発に人が集まってくると、やりたくなくてもリーダーとして決断を要求され、ゴールやビジョンの提示するよう考えを改めたという経験則が語られている。

広大なGitHubの片隅にいくつかOSSとしてコードを置いていると（もちろんRubyの何百万分の1という利用者であれ）徐々にコミュニティが形成されてきて、こういう役割が暗黙的に求められるよなァという気持ちでしみじみ読んだ。

46章 大事な問題にフォーカスする

プロダクトや事業のことを伸ばすには、プロダクトや事業を伸ばすことを考える必要がある。

んっ？　小泉進次郎構文かな？　と固まってしまった。

2017年に書かれた本だから、狙って小泉進次郎構文にしたのかどうか判別できない。

全体としては、いわゆる「いい兄貴問題」について、戒めとなることが書かれている。