必要にかられていて、社内でも読書会がはじまった。読書会はまだやってるけど、先行して読み終わった。愛称は「ちいとぽ」らしい。
どういう本なのかは、訳者の方が用意してくれた以下の資料が良いのではないか。
自分が読み始めたモチベーションとしては、チームの分け方について知見を得たいというものだった。
本を読んでみた感想としては、元々の自分の考え方もそんなに外してないことが分かって安心感があった。もちろん考慮の幅・深さ・質は違うので、この本を読んで良かった。
どれくらい根拠のある内容なのかはよく分からなかったけど、個人的にはこれまで勉強してきたことと整合的だった気がするので全体的にはすんなりと受け入れられた。部分部分で表現が分かりづらかったり何が言いたいのかよく分からないところはあったとは思う。
近代的な組織論が端的にまとまっている印象だったので、世間の評判が良さそうだったのも納得でした。
個人的に気になった点
概観
- 最後のChapter 9に全体の内容がコンパクトにまとまっている
- ので、読み返したい時はここからはじめて、掘り下げたいChapterを追加で読むと良さそう
- なんなら、はじめて読むときもここから読みはじめても良いかも知れない
- しかし、文中序盤にあるおすすめの読み方みたいなところにはそんな読み方は紹介されていないので、良くないのかも
- 用語集も巻末にある
- 非エンジニアが読むには馴染みのない用語がたくさんでてくるので、そういう時は役に立ちそう
- ただし、そんなに網羅的ではない
- 「認知負荷」「逆コンウェイ戦略」が特に重要なキーワードだと思われる
- ただし現実には、逆コンウェイ戦略を採用したからといってかんたんにソフトウェアのアーキテクチャが変わるわけではない - 下林明正のブログにも書いた通り既存のソフトウェアの構造が組織の構造に作用することもある
- 文中でもその後Chapter 7で
新しいチーム構造が考案されて実装されたからといって、すぐに新しいアーキテクチャーが出現するとは限らない。まさにコンウェイの法則の背後にある力によって、既存のソフトウェアアーキテクチャーは、新しいチーム構造に対して最初は「反発」することになる。と書いてあった
チームについて
- チームの人数
- この本では5～9人とされている
- 上限のマジックナンバーは7～9人、高信頼組織では15人まであり得るらしいが非常に稀とのこと
- アマゾンの｢2枚のピザルール｣が会議の生産性を高める | Business Insider Japan
- ダンバー数 | UX TIMES
- ちなみにスクラムガイドによると10人以下
- 両手で数えられる人数が上限と考えて良さそう。当たり前だが、エンジニア以外の人員も含める
- この本では5～9人とされている
ストリームアラインドチームとは、価値のある単一の仕事のストリームに沿って働くチームのことだ。- (同僚も言ってたけど僕も)このネーミングは好き。フィーチャーチームとか職能横断チームと言うよりも実態がイメージしやすいし、ストリームを最適化しようという気持ちになれる
複数のチームに同一のシステムまたはサブシステムの変更を許すと、その変更と、変更がもたらす混乱について、誰もオーナーシップを発揮しなくなる可能性がある。コードはガーデニングのように扱うべきものだ。取り締まる対象ではない。- チームによるオーナーシップが縄張り争いにならないように注意する必要があるとのこと
- プラットフォームチームとコンプリケイテッドサブシステムチームの違い
- が何なのかは自分は「ストリームアラインドチームの認知負荷を減らすのがプラットフォームチーム」「ストリームアラインドチームの認知負荷を一部引き受けるのがコンプリケイテッドサブシステムチーム」と解釈した
知識体系の位置づけ
つまり、組織にとって「正しい」トポロジーはないが、「悪い」トポロジーは複数あるのだ。- アジャイル系の勉強をしていると「成果が出ていればアジャイル、出ていなければアジャイルじゃない」みたいなトートロジー的な雰囲気を感じることがあるんだけど、この考え方はもう少し有用な気がする
庭を造って維持するのに必要な要素のようなものと考えてみるとわかりやすいかもしれない。チームトポロジーアプローチは、どこに花や植物を植え、どのように剪定、育成するかの説明書のようなものだ。文化、エンジニアリング、財務といったものは、土、水、肥料のようなもので、植物が健康に育つのを助ける。不健全な文化、貧弱なエンジニアリングプラクティス、ネガティブな財務の影響などは、庭での成長を妨げる毒のようなものだ。環境が適切でなければ、いくらチームトポロジーが素晴らしい剪定や育成のやり方を示したとしても、ソフトウェアが育ち、生き残ることはない。- アジャイルであることがすべてではない。筋力や体力も必要。場合によっては筋力や体力だけでゴリ押しもできるだろう。ただ、様々な不確実性と立ち向かうには敏捷性があると強いし、ゲームのメタはどんどん不確実性が上がってきているのでますます敏捷性の重要さが高まってきている、ということ
その他
- DevOpsトポロジー
- コミュニティ・オブ・プラクティス（こみゅにてぃ・おぶ・ぷらくてぃす）：情報システム用語事典 - ITmedia エンタープライズ
- はてなの開発プロセスを改善する、すくすく開発会とプロジェクトテンプレート講義のご紹介 - Hatena Developer Blogなんかはまさにこれだよねと思った
- 文中ではイネイブリングチームとCoPは目的や力学が違うため共存できるとされている
- 4つのチームタイプと3つのインタラクションモードで整理できない構造に対してこの本がどういう温度感なのかはいまいち掴めていない
さらに個人的に考えたこと
人員を追加する前にやるべきこととは
- 人員の追加には慎重になるべき
- 人員の追加は認知負荷を高める
- コミュニケーションパスは指数関数的に増えるので、どこかで人員を追加することで得られるリソースよりもコミュニケーションコストの増加によって消費されるリソースの方が大きくなる
- つまり、スケールアップには上限がある
- したがって、ある程度の人数を超えたらチームを分割しなければ速いフローは維持できない
- つまり、スケールアウトする必要がある
- 分割は逆コンウェイ戦略にもとづいてソフトウェアの分割を伴い、工数を必要とする
- 分割が遅れれば遅れるほど「コンウェイの法則の背後にある力」によって分割に要する工数は大きくなってしまう
- つまり、人員の追加は分割の計画とセットで語られるべき
- 比較的副作用の小さいアプローチとして、1人あたりの生産性を高めるアプローチがある。が、実際には難しい場合も多いだろう
- バリューストリームマッピングなどからはじめて、エンジニアリングプラクティスに限らずチームのフローをコスパ良く改善できる点が無いか検討してみると良いだろう
- 効果的な改善をしたいなら、プロダクトオーナーと開発チームが組織パターンでいう「信頼で結ばれた共同体」であるべきだろう
- そうでなければ、「不要な機能を削除する」だとか「リファクタリングを日常的なものにする」といった一般的な改善すら難しい。結果としてエンジニアリングプラクティスに引きこもったりして、効果的な改善の手札はすぐに尽きる
- 信頼関係を築くにはお互いに「こいつならちゃんとやってくれる」と思わせることが必要
- 心理的安全性が担保されていないと、信頼関係のあるなしが余計に分かりにくくなる。心理的安全性が無いというのは信頼関係が無いことの裏付けでもあると思う。負の循環にいるので、抜け出しにくい
- つまり、スケジュールの遅延や障害発生が常態化しているようでは、信頼関係を築く手前にいると自覚するべき
- 失った信頼を取り戻すのは新たに信頼関係を築くよりも大変。実績を積み上げていくしかない
- 状態が悪いまま巨大なチームになってしまった場合は、半ば強制的にチームを分割して改善しやすい状況にするのも手だろう
- いわゆる分割統治
- ちいとぽ的にはストリームアラインドチーム間は期限付きのコラボレーションモードではじまり、将来的にはより疎な関係を志向するべきだろう
- その過程で適切な節理面を探索し続けることになるだろう。また、アーキテクチャの変更を伴う場合は工数も必要になるだろう
- こうした意思決定はボトムアップではできない。トップダウンの意思決定が必要(ただし、提案をすること自体は誰でもできる)
- ボトムアップが有効に機能するには、ボトムアップを前提とした組織デザインが必要
- つまり、巨大で状態が悪くリーダーがこうした意思決定ができないチームは詰んでる
- より上位決定者の介入を必要としている。それにも期待できない場合は……
代行するのではなく教育する
- チームが備えているべきスキルをアウトソースするようなアプローチは、ストリームアラインドチームのコンセプトに反している
- スキルが足りていない場合は、イネイブリングチームとのインタラクションを通じてチームがスキルを獲得するべき
- 期限付きのコラボレーションモードで知識移転して、その後はファシリテーションモードで支援し、最終的には関係が無くなる
- ただし、組織としてアジャイルを志向している、という前提が必要。そうでないなら、ストリームアラインドチームのコンセプトに反しているから何？という話になってしまう
- 世の中にはウォーターフォールの方が好きという人も普通にいるし、アジャイルとは素早くアウトプットし続けることだ！みたいな人もいる。方向性が揃ってないと議論が噛み合わない。ので、明示的に方向性を打ち出すことが必要
- これは、合わない人を切り捨てるという覚悟も必要ということ
- こうした意思決定も、ボトムアップではできない。トップダウンの意思決定と、さらに継続的な所信表明が必要(ただし、提案をすること自体は誰でもできる)
- こうした意思決定ができない組織は個人的には不確実性が高まり続けている時流から見て泥舟だと思う……
- 別に、アジャイルじゃなくても組織としてのもっともらしい方法論が確立されていれば何でも良いと思う。例えば、もの凄い天才のワンマン経営みたいなのもアリ。ただ結局スケーラビリティの面で問題を抱えることになってどこかで頭打ちになるので、ニッチ市場でしか通用しなさそう。そういうところも含めて、従業員を納得させてほしい。納得できないなら、不安=ストレス=認知負荷を抱えながら働くことになるので、いい影響は望めなさそう
- 世の中にはウォーターフォールの方が好きという人も普通にいるし、アジャイルとは素早くアウトプットし続けることだ！みたいな人もいる。方向性が揃ってないと議論が噛み合わない。ので、明示的に方向性を打ち出すことが必要
大規模スクラムの存在意義とは
チームのモデルやスケールデリバリーモデルはたくさんあるが、一見しただけでは個々の違いはわからない。さらに、チームのふるまいのパターンが示されておらず、他のチームとどのように効果的に接するべきかのガイドラインもないままだ。結果として、チーム間が密結合になったり、逆に孤立した自律チームを生んだりする。それは、実際にはスケールしない。
- 大規模スクラムとかあのへんのことを指していると思う
- 大規模スクラムが逆コンウェイ戦略と整合するイメージをあまり持てない。ので、基本的に悪手なのでは？という印象が強くなった
- ストリームアラインドチーム間のコラボレーションモードでの関わり方の実装例として大規模スクラムを参照すると良い？いまいちしっくりこない
- このあたりは大規模スクラムを実践してる人から聞いてみたいところ。ぜひ教えてください
個人APIも定義すると良さそう
- チームAPIを定義すると良いよという話から、自然と発想した
- まあ、ちいとぽ的にはチームファーストでいきましょうなので、個人の粒度で考えることはおすすめしないかも知れない
- ただ、実際にはチームに自分がどういう貢献できるんだっけ？とか、どう働くつもりなんだっけ？とか、そういったメンバー間の期待値調整が有効な場合が多いし、推奨もされてると思う
- ドラッカー風エクササイズとかはそのためのアクティビティですよね
- 最近、個人的にもどう働きたいんだっけ？というのが混乱してきていて、あまり有効に動けてないな、と思う
- まともなチームなら当然チームとしてそうした期待値調整を行っていると思うけど、まともじゃないチームも多い。また、個人としての希望とチームとしての希望のギャップに気づきやすくなっているほうがメリットも多いだろう
- いわゆる個人READMEみたいなやつもこれに当たるんだろうな、と思う
個人的には、特に4つのチームタイプと3つのインタラクションモードは今後色んなところで使われていくのではないか、と感じた。 そんなに分厚い本でもないし、おすすめです。
最近は釣りのためなら引っ越しもする。より良い釣り場を求めて移動を続ける者のこれまで、そしてこれから｜KINTOマガジンにも書いたように釣りで忙しくてあんまり読書の時間を取れてなくて、この本を読み終わるのにも時間がかかってしまった。具体的には、以前は月1冊ペースで本を読んでたけど、原付きを買ってからは月0.5冊ペースに落ちている。 まあ、過去にもこういう読書ペースが落ちる期間は何度もあったので別に飽きるまで遊んでれば良いと思ってるはいる。けど、若干焦る。こういうところも、自分はどう働くつもりなんだっけ？というところが整理できると解消できそう。
