「組織パターン」を読む
youchan
youchanこの本に求めること
- 業務を行う上で適切なチーム編成について考えられるようになる
- どの粒度でチームを作るのか
- 複数のチームを兼務しなければいけない状況はどう対処すべきなのか？
- チームとして適切なコミュニケーション形態がなんなのかを知る
youchanどんな本？
本書には2つの見方があり、いずれも妥当だ。本書は組織を改善するためのガイドであり、ソフトウェア開発の4番目の社会的スタイルにおける、ソフトウェア開発構造の「お手本」の記録でもある。ほとんどの読者は、組織的な改善のためのガイドとして本書を扱うだろう。
具体的にそれらお手本はどのようにして記述されていたのかが第二章「パターンの登場」のところに書いてある。多くの企業への調査をえて書かれているので、エクストリームプログラミングと比較するとかなり科学的なアプローチで本書は書かれたと言える。
※エクストリームプログラミングは過去に読んだことがありますが、記憶の中だと著者の経験から編み出されたプラクティスの集合知である認識です、違っていたらごめんなさい。
youchan本書に頻出の用語として「パターン」「パターン言語」「フォース」あたりがある。
実は「パターン」に関して明確に書かれた定義がない。
パターンについての短い、それゆえ必然的に不完全な定義を示そう。
繰り返し発生する構造的な形で、あるコンテキストにおける問題を解決するもの。なんらかの全体の全体性あるいはシステムに寄与し、美的あるいは文化的な価値を反映する。
パターン自体が何なのか、という記述はありつつも単純かつ明確な説明は本書には存在しなかった。
パターン言語に関する説明に入るとある程度形を帯びてくる。
パターンはパターン言語から生じる。ここでいう言語という言葉は比喩として使っている。英語は一つの言語だ。そして言語としての英語を構成するのは、いくつもの単語と、その単語を意味あるやり方で組み合わせるための規則である。
パターンが意味のある順序で組み合わされたものがパターン言語となる。
「フォース」に関する説明はなかったので少し調べた。
ソフトウェアエンジニアが設計や実装の正当性を示すときに使っている判断基準の類いを、 フォースという概念は一般化します。 例えば、コンピュータサイエンスにおけるアルゴリズムの古典的な研究において、 解決すべき主要なフォースは「効率」（時間的な複雑さ）です。 しかしながら、パターンというものは、 これまで生み出してきたあらゆる作品の開発においてあなたが遭遇したような、 さらに広範囲で、さらに計測が困難で、互いに矛盾した目的と制約を取り扱います。 例を以下に示します。
「計測可能な問題」と捉えるとよさそうだ。
youchan基本的にパターンの詳細が書かれた部分に関しては読む順序が決まっていない。また全部読む必要もない。という旨が書かれている。以降は自身が気になったトピックをつまみ食いしていく形にする。
youchan4.1.1 信頼で結ばれた共同体
チーム内の人間が互いに信頼し合うことが欠かせない。そうでなければ、何かをやりとげることは難しい
思えば過去に、双方が疑心暗鬼になって開発効率がほぼゼロとなったことがあった。一方は相手の能力を疑い、一方は相手の心情を疑っていた。
信頼していることを明示的に表現する必要があると書いていたが、具体的には何が必要なのだろう？本書では時間管理に利用されていたストップウォッチを破壊する儀式について書かれていた。
アクションとして示せるなら下記あたりだろうか...?
- 「信頼しているので...」を枕詞として頻繁に用いる
- 素直に褒める（この辺りの実装読みやすいね、この考え良いですね、など）
youchan4.2.3 段階的に人を増やす
雇用プログラムのフェーズ分けをしよう。業務にとって中心となる基本的な適正に見合った人を雇うことから始め、プロジェクトが成長する必要に応じて新しい人を入れよう。
最近自分が業務委託の方の受け入れを担当しているが、新しくチームに入ったメンバーは（本人の適正などによるが総じて）自走できる状態になるまで多くの時間を要する。新卒で半年、中途でも2〜3ヶ月は見積もっても良いと考えている。
なので一気に数人増やすのは得策ではないと考えている。
youchan4.2.6 顧客たちを巻き込め
顧客と開発組織の主要なロールとの間で交わされるコミュニケーションを促進し、それによって顧客満足度を高め、維持することは、開発組織にとって重要だ。
顧客というロールを開発者やアーキテクトというロールと密接に結びつけよう。品質管理やマーケティングなどのロールと結びつけるだけではだめだ。要するに、開発者もアーキテクトも、自由にそして頻繁に顧客と話をすべきなのだ。可能であれば、開発者やアーキテクトが顧客のところにいくのではなく、顧客をこちら側の環境に巻き込もう。
マネージャー・コーダー間は関係が歪むことが多い。という点で顧客と直接開発者が接点を持つという話。あとはマーケティングはブランドやプロダクト名など、設計者がほとんど気にしない要因に目を向ける傾向があることにより、開発者がマーケティングの人間と話すことで要件を理解することは難しい。という主張もあった。
youchan4.1.26 手を止めて始めた作業を中断するな
重大な問題に対して、開発者がすでに「何かの手を止めて」作業しているのであれば、その作業が終わるか、その問題自体がどうしようもなくもつれてしまうまで、その作業を中断してはならない
これによって、コンテキストスイッチのコストを極小化させることができる。
確かに小粒であれボールを拾いすぎてしまうと、とてつもなく認知負荷が上がって生産性が下がる。自身もそういう経験があった。
youchan4.1.25 作業を中断して問題を取り除く
包括的にスケジューリングされた計画を立てるのは、不可能と言わないまでも難しい。それでも、ある種の計画がなければ、仕事であふれかえってしまう。つまり、実際には進捗していないのに次から次へとタスクをこなすという状態に陥ってしまうのだ。
重要なリソースが手に入らないせいでプロセスが止まりそうになっているのであれば、そのリソースを提供できるロールの作業をいったん中断し、プロセスが止まってしまわないようにしよう。
組織全体の生産性を最適化するものに労力をかける方が有用だという話。自身がなるべくコードレビューを行うのはこういった理由からである。
youchan4.2.12 目的の統一
多くのプロジェクトは立ち上げ期に数々の障害に突き当たる。人々が協力して仕事をしようと苦労するからだ。
プロジェクトのリーダーはチームメンバー全員に共通のビジョンと目標を教え込まなければならない。
時間が経つにつれて、目的の統一はチーム内の対話や顧客との対話、あるいは他のステークホルダーとの対話の中に登場するようになる。きっかけを作るのはチームリーダーだが、チームのダイナミクスがそれを引き継ぎ、物事を進めていかなければならない。
この結果、チームは明らかに、様々な目的に向けて作業するのではなく、協力して作業するようになる。しかし、もっと細かいながらも強力な効果がある。
この節はプロジェクトの立ち上げに関わる話と理解しているが、自身の状況に当てはめることもできそうだ。
僕自身はロールの兼務が、最近の生産性の落ち込みの原因かと思っていた。しかし目的が統一されていないことも原因の一つなのかもしれない。開発作業にレバレッジがあまり効いていない。
今所属しているチームは寄せ集めの状態に近く、共通の目的を持ちづらい。したがってチームの細分化が必要なのかもしれないと思い始めた。
youchan4.1.13 ワークキュー
スケジュールは、単純に優先順位付けされた作業の一覧として作成しておこう。暗黙的な要件（4.1.16）の一覧を手がかりとして、実装するであろう順番を並べよう。そのときに緊急度や優先度が高い項目を上に持ってくるのだ。
以前の僕はこのパターンで動いていたが、上司から「いつまでやれば良いか決められていないのであれば、やらなくてもよいのでは？」という理屈で一蹴された。直近で採用しているのは具体的な期日ではなく「3月中には終わる見込みです」といった曖昧なスケジューリング。この記事でいう「見積もり」にあたる行為をよくやるようにしている。
youchan4.1.21 一つのタスクに一つのチーム
もしプロジェクトのメンバーが、危機が起きるたびにその対応に時間をとっていたら、危機管理にあまりに時間を使いすぎて、実際の作業が終わらなくなってしまうだろう。
サブチームを作って、突発的事態に対応してもらおう。そうすればメインチームが作業を続けられる。
チームを分けるというアプローチもある。アクティビティを並べ替えて、各チームに第一優先のタスクと、それに付随してやるべきアクティビティが紐づくようにしよう。
自分がやるべきなのはこの辺りなのかもしれない。今ある種それに近い形態を取れているのだが、定例で挙がる話題や任されるPull RequestのReviewが、自身のメインにある仕事と距離がありすぎて関心が持てない。
経緯としては下記のような流れ↓
- 組織がデカくなってきたのでチーム制にしよう
- チームメンバー個々人で持っている仕事が干渉しなさすぎるので定例がただの作業報告になったり、利用者から降ってくるタスクを受ける人間が決まった人になってきた
- （定例を減らしたり、業務を縦割りにしてスイッチングコストを削減）
- チームの人数が増えたり関わるプロダクトが多い影響なのか、シナジーが生まれないチームになっている
そろそろチームを分けるような動きがあると、個人的には旗を挙げるような動きがやりやすい。
youchan6.1 組織改革のための起爆剤
自分の欠点と勇敢に立ち向かい、組織の変化を抱擁する準備ができていないなら、相互の信頼と尊敬を築いて、内省と対話のための基礎を作らなければならない。信頼と尊敬がなければ、深くコミュニケーションしてプロセスに関する議論（こうした議論では、プロセス内の所定の段階に責任のあるロールや人が槍玉に挙がることが多い）を越えて、組織に関する議論や最終的には原則に関する議論に至ることはできない。
「4.1.1 信頼で結ばれた共同体」と似たような記述。
youchan6.1.1 解決に先立つ不調和
多くの組織は自分たちのことがわかっていないので、抱えている問題を認識できない。ただし、組織に属する人の中には、組織の欠点に気づいている人もいる。そういう人たちは、問題がなんであるのか正確にはわかっていないかもしれないが、何かが間違っていることは知っているのだ。しかし、組織内の主要な人の多くが組織の抱える問題について認識するまでは、物事が変わることはないだろう。
自分たちもそうだった。ここ最近周囲の人が関心を持つまでは問題があるという認識がなかった。
youchan6.1.5 チームビルディング
チームビルディングには、予期せぬよい副作用がある。チームビルディングによって、チームが変化する必要性が指摘されるのだ。隠れた傷が表面に浮かび上がり、必要な治療を受けられるようになる。
チームビルディングを通してグループ全体における各々の働きぶりがわかることで、創発されるやりとりのパターンが見出せるとか。信頼を築いたり、チームをより強固にするための対話が促されるという話だった。
組織パターンにおいて具体的なチームビルディングはいわゆる「ワークショップ」みたいなもので、それぞれに割り振られた仮のロールを演じながら課題を遂行するというものだった。
現代におけるチームビルディングの手法は調べれば色々ありそうだ。
ふりかえりはチーム構築のための強力なツールで、その恩恵には明示的なものと暗黙的なものがどちらもある。重要なのは、ふりかえりによって組織のメンバー同士の信頼関係の基礎が構築されるということだ。
ふりかえりも有効なのか。なるほど。
youchan6.3.2 組織はパターンではなくインスピレーションだ
パターンは多くの多様な経験をもとに合成されており、あなたの置かれている状況は我々が観察したものとは間違いなく異なるはずだ。それゆえ、パターンはインスピレーションをもたらすのに使われることを意図している。
なるほど、How to本ではない。
youchan7.1 人類学にあるパターン
本書では、体系的パターンがそれぞれ、パターン言語、すなわちより大きな全体の一部になっている。この全体と個々のパターン同士の混交こそが文化なのだ（個々のパターンの緩やかな集合体が文化であるわけではない）
この表現をみると既に組織はオリジナルのパターン群を所持していて、それらを適用しているということになる。
youchan一旦ここまでにしておく。
6章で書かれていたように、インスピレーションをもたらすためにこの本は存在している。
なので組織・チームのような単位で課題を感じた時に都度読んでいくのが良いのだろうと思った。
自分が今持っている課題感としては「チームの粒度での成果が出しづらい」というのがあり、これは言い換えるとチーム単位での目標を持てていないというのがある。優先度が整理できずに複数の目標が点在しており、それらが平行に走っている影響で、チームメンバーが目的を認識しづらい状態になっているのだと考えている。
そこで一旦チーム分割というのを考えている。これが有効であると考えた背景には「新卒採用の人数が増えてきたので、所属するチームの人員が一気に増える可能性が高い」というのがある。チームが大きいと統制が取りづらく、やる仕事も分散してしまう、という文脈でチームを分割する動機は既にある。
今のチームが持っている大きな仕事単位でチームを分割すると、チームで目標が立てやすくなる。よって自身が持っている課題感は薄れるのかもしれないと考えている。