セキュアベース･リーダーシップを読んだ

読書記録

作者:ジョージ・コーリーザー,スーザン・ゴールズワージー,ダンカン・クーム
プレジデント社

読みながらメモとかはとっていなかったのだけど、これは記録に残しておきたいなーと思ったのでざっくりと読書記録を。
GWに対話や関係構築に関する本を読んでいたり(問いかける技術、アサーション入門、フォーカシング)、直近でもシャイン博士が語るキャリア・カウンセリングの進め方: <キャリア・アンカー>の正しい使用法を読んだりなどで、「コーチングとかマネジメントとかリーダーシップについては、色々と知らなきゃいけないことがあるぞ・・無限にあるぞ・・・そしてそれを自分が知らないことによって周りの人が失敗する確率が上がったり、本来望めたレベルが下がったりするのは嫌だな・・・」「知れば知るほど武器になるな、面白いな」っていう気分が高まっていたので。
とりわけ、キャリア・アンカーの話を見ていて「周りの人の実力・才能をもっと豊かに引き出すには？」を深めたいなーという意欲を濃くしてくれたので、積んであった本書を手にとった次第。

どういう本

「セキュア」という言葉が含まれていることから、心理的安全性とかそういう方面の話と関連があるのだろうなーと思いながら読んでみたけど、そうっちゃそう。
読了後に、この本を知った＆買ったきっかけは何だったっけ・・・っていうのを思い出そうとしたんだけど文脈が掘り出せずに残念。購入タイミング的に、LeanとDevOpsの科学を読んでいた時期っぽかったので、その関連かな？

原題が「Care to Dare: Unleashing Astonishing Potential Through Secure Base Leadership」で、「思いやりで勇気を与える」「セキュアベースリーダーシップで驚愕的な才能を開花させる」みたいなニュアンスなのかなー

言うまでもなく、この「セキュアベース」が本書の中核的な概念であり、それがどのような効果をもたらすか？どのように実装・実行するか？を伝える本。

セキュアベースリーダーシップについては、まえがきの言葉を借りれば以下のように定義されている。

守れられているという感覚と安心感を与え、思いやりを示すと同時に、ものごとに挑み、冒険し、リスクをとり、挑戦を求める意欲とエネルギーの源となる人物、場所、あるいは目標や目的
『まえがき (P9)』

個人的なイメージでは、「私はここにいて良いんだ！という肯定感をもたらし、内発的な意欲をもって挑戦を促す」ような施しをもたらす「いつでも帰ってこれると信じられる基地、ホーム」的な存在なのかな〜という捉え方。
その存在は、からなずしも「接点をもった誰か」である必要はなくて、精神的支柱となるような「目標」であったり「過去の経験、エピソード」などでも良いよーと。ふとっちょのオバサンの為に靴を磨く、というのも近いだろうか。遠いか。

1冊を通じて、他人(フォロワー)にとっての「セキュアベース」たるようなリーダーになることを目指す。それは「具体的な何かの行動や思考」よりも総合的な、「人としてのあり方(P13)」として語られる。
そのために必要な「資質」を9つの要素に分解し、しかもそれを「明確で、現実的で、習得可能なもの(P61)」と断言している。
それぞれ、どうして必要なのか？具体的にどんな行動・心理に顕れてくるのか、表せるのか？自分自身がそう振る舞えているかを、どう点検すればいいのか？どのように獲得・強化すればいいのか？
─といった話が展開されていくのだ。

論理的な話であり、自己啓発的な側面も多分に含みながら、具体性・実践的なレベルによく落とし込まれているな〜と読んでいて嬉しかった。

トータルの所感

いわゆる「尊敬・敬意」「謙虚さ」「安全であること」「優しくすること」は、語るまでもなく重要である事には異論はないが、やはりビジネスの局面においては「厳しさ」も必要なのでは？と感じる面もある。
要するに目標達成に向けた力学だ。それが無くて、どうも片手落ちな、ただ他人を恐れて日和ったような平和主義じゃないか・・・と感じてしまうような本もしばしば見かける。
その点、この本は「健全なプレッシャーのかけ方」についても視野に入れているように感じられて、その点がとてもよかった。
個人的にはチームが機能するとはどういうことか ― 「学習力」と「実行力」を高める実践アプローチを初めて読んだときに、「あくまで目標達成に向けたチームの強化(学習促進)のために、手段として心理的安全性を確保しに行く」というスタンスに目から鱗！！が落ちたのだが、この本もまた「ただ優しいお兄さん的な”安心できる基地”になろう」というだけの話の展開はしておらず、好きな感じだ。

全体的な構成の工夫として、実際にあった(セキュアベースリーダーシップを発揮していると言える)顕著なエピソードを頻繁に織り込まれていて、それも読者の興味を維持し続けるのに貢献していると思う。ワクワク感があった。*1

少しだけ話の展開が冗長に感じられる部分もあるかも知れないが、そういう「何度も1つの物事を少し言い換えて述べる」的な配慮を頼って、少し気楽に読んだりスピードを上げても大丈夫そうだな〜って安心感を個人的には感じた所。

お気に入り箇所

9つの特性

主題であり、本書の論(の具体的な部分)の骨子になる要素。
これらの要素・行動を安定的に実践することで、フォロワーのセキュアベースになろう！というもの。

冷静でいる
人として受け入れる
可能性を見通す
傾聴し、質問する
力強いメッセージを発信する
プラス面にフォーカスする
リスクを取るよう促す
内発的動機で動かす
いつでも話せることを示す

それぞれが「思いやり」と「挑戦(の誘発、促進)」を高いレベルで獲得し提供するために欠かせない、と。

特性1つずつに対して、「(調査で収集した)セキュアベース・リーダーが、それを表し実践していると言える顕著な発言」「あなたのセキュアベース・リーダーシップ行動を評価しよう(点数が低かった部分が重点的に伸ばすべき項目になる)」「特性を伸ばすためのヒント」といった節を設けて肉付けしている。

例えば、特性5「力強いメッセージを発信する」についていえば、

リーダーの発信
- 「彼はこんなメモを書いて渡して売れました。『君は間違いなく正しいことをやっているよ』。メモ用紙に書いてもらったこのひと言が、わたしにとってはとても大きかったのです。本当に大きかった。今でもその紙を持っています」
- 「彼女は私に『いつでもチャンスはある』と言いました。身動きが取れず、誰も助けてくれないと思い始めていた苦しいときだったのですが、彼女の言葉から自由を感じ、力を得ました」
- 「わたしが上司との間に問題を抱え、会社を辞めることを決心したとき、人事部門の同僚が、『辞めるときには常に堂々と、落ち着いて』と言いました。彼の言葉がずっと心に残り、この変化の時期を温かい気持ちとプロ意識を忘れずに、乗り切ることができました」
あなたのセキュアベース・リーダーシップ行動を評価しよう
- 力強く覚えやすいメッセージを発信している
- はっきりと簡潔に話している
- 非言語のメッセージやジェスチャーを使って、覚えやすいメッセージをさらに強調している
伸ばすためのヒント
1. 言葉だけでなく、非言語のメッセージにも気を遣う
2. その一瞬を逃さない
3. 力強いメッセージをはっきりと、簡潔に、ゆっくりと伝える
4. 力強いメッセージを書く
5. 力強く短いメッセージをノートに書きためておく

のように紹介されている。これが、9個とも全てにおいて繰り返される。

各特性についての「あなたのセキュアベース・リーダーシップ行動を評価しよう」に従って、セルフアセスメントをしてみたら、以下のような結果になった。
主に職場において部下・同僚・上司とのコミュニケーションを想起しながら点数を付けてみたもの。
(各設問、1＝まったくできていない〜5＝常にできているで答えるのを3問ずつ)

特性	評点
1. 冷静でいる	6/15 (3未満が2つ)
2. 人として受け入れる	14/15 (3未満が0)
3. 可能性を見通す	13/15 (3未満が0)
4. 傾聴し、質問する	15/15 (3未満が0)
5. 力強いメッセージを発信する	9/15 (3未満が1)
6. プラス面にフォーカスする	14/15 (3未満が0)
7. リスクを取るよう促す	11/15 (3未満が0)
8. 内発的動機で動かす	12/15 (3未満が0)
9. いつでも話せることを示す	8/15 (3未満が2)

意外と高いかもな？？？？(今はそこそこ機嫌が良いからですね、多分)

元々の素質として「人のことを観察してポイントをつかもうとしている」「ちゃんと他人を褒める」という面は持っている*2のに加えて、コーチングを勉強しながら「目の前の相手を信じる」「内側に持っている可能性を引き出せるようにする」というのも重要性を理解しトレーニングしているので、他者に対する尊重は概ね評点が高いのかも。
(傾聴と発問は、座学や読書だけでなく機会を作って実践訓練を積んでいるので。伸びていないと困る・・)

他方で、自身を律することや、他人に対して「課す」ような方面は依然として弱そう。
この辺りは、他人に対する弱気とか、「相手の望みに対する確証が持てない」的な、コントロールできないものへの不安が強く出ているのかな〜という感じがする。自己肯定感が低い(自分の持っているもの・見ているものへの疑いが強い)性質からくるものな気がする。
「力強いメッセージを〜」についても、「簡潔に伝える」が弱いと感じている(＝話がダラダラしがち)ので、これもまた「伝わっているかな？と不安がつきまとっているから」という意味で根が似ていそう。

こうした面が、どのようにリーダーシップや(組織内で果たすべき)他人への影響の与え方に影響しているか？が分かるし、その重要性も解説されている！！というのが本書。

・・・にしても特性1😇
コレに対しての「ヒント」として、(自身の感情や気分に自覚的になって、それを収束させる術を用意すること〜という意味で)「マインドフルネスの練習をする」というのが挙げられている。
いや〜、そうですよねガッハッハ！という気持ちになったけど、課題感はあってちゃんと ~~積んでいる~~ 勉強しようとしているんですよ！！！というのが下の図。
方向性はちゃんと合っているんだなーとも言えるので少し自信になった。

4つのリーダーシップのアプローチ

本書全般を通じてリーダーシップは「フォローとリード」もしくは「CareとDare」のような軸の掛け算で描かれているが、その「思いやること」と「挑ませること」を用いた四象限で「リーダーシップのアプローチ」を説明している。
これがまた面白かった。チームを動かすときに、リーダーがどのように行動したり判断したりするか・・・？

「思いやりも強く、挑ませる面も強い」となったときに「勝利を目指す」ようなリーダーシップとなる。
逆に、「思いやりも挑ませる面も弱い」場合には「回避を目指す」と。
要するに、チームとしてのリスクのとり方や、「自分でやるか・誰かにやらせるか」という意味でのリスクの置き方が変わってくる。

これもまた、そのようなアプローチを端的に表現するような言葉(セリフ)─「この表現にピンときたら、あなたのアプローチはコレですよ！」といったものが例示されていて、イメージが湧きやすかった。

例)

勝利を目指すアプローチ(思いやり:強、挑ませる:強)
- 成功するには人間関係が重要だ
- 必要なときには、フォロワーが私を助けてくれる
- 意思決定をするのは楽しい
- 他者とともに仕事をすれば、最高の結果が出せる
支配を目指すアプローチ(思いやり:弱、挑ませる:強)
- 最終的には、重要なのは結果だけ
- 部下はわたしの信頼を勝ち得なければならない
- 一人でいたほうがいい
- 部下はお金のためだけに働いている
負けないことを目指すアプローチ(思いやり:強、挑ませる:弱)
- 自分で決定を下したくない
- どうなるか様子を見よう
- 他の人からも同意を得る必要がある
- 批判や反対は回避する
回避を目指す(思いやり:弱、挑ませる:弱い)
- 熱心にやる意味はない。これはただの仕事だ
- リスクはとらない
- 感謝されていない
- 部下は勝手にやるだろう

こうしたアプローチについて紹介した上で、重要なのは(個人的に心に留まったのは)

このモデルから得られる最も重要な学びは、「プレッシャーを受けたときにどの方向性に動くか」である。
『第6章「勝利を目指す」マインドセット (P228)』

という部分。
ただ8行程度でサラッと書かれている内容ではあるが、リーダーシップというのは、固定的で唯一性のあるものではなく、あくまで変動的であり脆いものなのだなーとハッとさせられた。
人は「良い面よりも悪い面のほうが目に付き、印象に残る」ようにできていると思う。
なので、プレッシャーがかかったとき = 弱さに飲まれた時に、どのように力を発揮できるか・・・・？は重要な課題であると感じた。

愛着スタイル

セキュアベース・リーダーになるためには「他者とどう関わるか」が重要になる。
その要素として「自分自身が、自分に対してどのような関係モデルを持っているか」「自分自身が、他人に対してどのような関係モデルを持っているか」の2軸からなる4象限のパターンとして「愛着スタイル」を表せるという。自己に対する肯定感の＋or−、他人に対するそれの＋or−の組み合わせだ。

自分を肯定し、他人も肯定する: 安定型 - 勝利を目指す
- 近づきやすい
- 自尊感情が大きい
自分を肯定し、他人を否定する: 回避・拒絶型 - 支配を目指す
- 一匹オオカミ
自分を否定し、他人を肯定する: 不安型 - 負けないことを目指す
- 不安
- 過度の依存
自分を否定し、他人も否定する: 孤立型 - 回避を目指す
- 引きこもる
- 気落ちする

これも「基本的なスタイル」があり、様々な要因によって「別のスタイル」が誰しも現れるものだという。 (それぞれの象限が、先のリーダーシップアプローチにもリンクしてくる)

これも本書の中で特に気に入った部分のひとつで、各愛着スタイルごとに、「調子の良い日」「調子の悪い日」におけるそれぞれの行動特徴を説明している。こうした説明に自身の行動を照らし合わせて、「自分はどの愛着スタイルが基本なのだろう？」とアセスメントをすることができるのだ。
(そして、ここでも「安定型」を目指すための処方箋が紹介されている)

自分に当てはめて考えてみると、自信に満ち溢れている時は安定型で居られることが歳を取るに連れて増えてきたようにも思う。
その一方で、2〜4のどれも出てくるんでないかい？？？という気もした。明らかに「引きこもる」「気落ちする」という反応はあるので。
ただ、そこまで行くことは減ったorリカバリは効くようになってきたとも思うし、少なくとも「他人にそのままぶつける」ほどの問題は抑え込めるようになってきたんじゃないかなー・・・
2,3でいえば、昔だったら拒絶型が強そう、今だとやや不安型に行き着くのかな？という気も。

まとめ

他にも、とても重要な概念が出てくる。「絆」や「信頼構築スタイル」、「喪失」「離別」や「悲しみのプロセス」だったり、「6つのリーダーシップのスタイル」など。

セキュアベース・リーダーは、そのコンセプトだけをなぞると、かなり崇高で聖人君子なビジョナリーでエナジャイザーで・・・・といった現実離れしたコンセプトになりそう。
しかし、本書では「セキュアベース・リーダーになるためには、リーダー自身にもセキュアベースが絶対に必要」とか「リーダーシップや関係性のスタイルは、プレッシャーやストレスによって(一時的に)変動するもの」といった現実的な面を見落とさない。

この「絶対壊れない完璧性」よりも「弱った時に素早く認知して、どう回復するか」と向き合った話に、とても希望を感じた。

自分自身がぼんやりと感じていた課題(「思いやり」はまだがんばれても、「挑ませる」が上手くない気がする)についても、その症状と課題、そして処方箋を得ることができたはずだ。

改めて、「リーダーシップってなんだっけ？」って考えてみたくなるきっかけとなった1冊だった。
自分自身、ここのところ(というかCAL-1を受けてからかなー)は「サーヴァント性よりも自己変革性を伴って行動するリーダーシップを獲得したいな」と感じていたところだったので、この「けしかける」ような側面・・・「フォロワーがしっかりと高いレベルの挑戦を続けられるか」に重きをおいた話は非常に面白く感じた。

強いて言えば、「自分自身がどのようにビジョンを掲げ、それに邁進していくか/周りを巻き込むか」に関しては扱いが薄かった気がする(あくまで「フォロワーを内発的な動機によって行動させる」が目的)ので、その辺りはまた別の本や理論で補っていきたいところ

*1:なんとなく、「ビジネススクールの教科書」みたいな本には、こういう事例を織り交ぜているものが多い気がするなぁ。事例研究やフィールドワークが多いからか

*2:というか、元同僚だったり研修を受けた際のフィードバックなどで他人にそのように言われる機会がしばしばあり、それで知った

2022-05-15

GWを振り返る

読書記録

読みたい本がたくさんあるんだ〜〜！って気持ちのままに迎えた連休ということで、本を読みました。

↓1年前 daisuki.nichiyoubi.land

雑感

4/29-5/8までで10冊読んだので、ペースにしてちょうど1日1冊くらいかなー。
前から読んでいてこの期間に読み終わったものもあるし、逆にこの期間に読み始めて今も読書中のものもありつつ。
あと、「1冊は読み終えられるように軽そうな本を挟む」みたいな事もしてた。この辺り、去年のGWに結構たくさん読んだな〜っていうのが1つの目安にしてたなぁ。

ソフトウェア設計、コーチング、PjM、DevOps、PdM、ファシリテーション、「他人に勧められるかな？」目線でレベル的に自分にとっては易し目な本・・・と、自分の興味のあるものを我儘に手にとった感じ🤗

あと洋書が段々と自分の読書リスト(実際に読んだ本)に含まれてくるようになったのは嬉しいな。
これもアドベントカレンダー2021に訓練みたなものができた点だと思う。

アナリシスパターンを読み切るぞ！！！って思ってたけど、結局まだまだ途中だなぁ。

読んだ本の記録↓

読了順に

Domain-Driven Design in PHP

Domain-Driven Design in PHP (English Edition)

作者:Buenosvinos, Carlos,Soronellas, Christian,Akbary, Keyvan
Packt Publishing

Amazon

猫も杓子もDDDじゃないですか、っていうことで「PHP利用者にはグッと来やすい」みたいな書評をどこかで見かけたような見かけなかったような気がして積んでた本。
GW初日(その前日の夜だけど)に読み始めて、この期間では1番最初に読み終えて。

いや〜〜〜コードがPHPだとすごい分かりやすいな！？脳みそが楽だ！！！みたいな気持ちになった。
直近でアジャイルソフトウェア開発の奥義第2版オブジェクト指向開発の神髄と匠の技を読んだ際に「コードが視覚を通じて脳みそに届いて理解に至るまで」の摩擦係数がすんごい高ぇ〜・・・みたいな経験をしたばかりなので、この「ざっと全体俯瞰してもポイントや言いたいであろう事が目に飛び込んでくる」くらいの読みやすさはとっても気楽で嬉しかった。

それもあって、かつ難易度としてもそんなに高くなくわかりやすかった気がする。
コードが具体的、ある程度の「DDDとは」的な所の端折りを許したことで「つまり何」がテンポよく出てくる、みたいな感覚。
どうしても「養殖物」なコードではあると思うのだけど、「集約」とか「ドメインイベント」とか「ドメインサービスとアプリケーションサービス」とかの戦術的DDDを扱う上で出てくる掴みにくいような概念も、自分にとってはスッと頭に入って来やすい感じがしたなぁ。
それは「PHPだから」もあるだろうし、「説明も簡潔だから」ってものあるだろうし、それこそ「何度も似たような本を薄く広く読んできたから解像度が上がる」って効果も感じつつ。

動作可能なサンプルコードもGitHubに上がっているということで、本書にて触れられていないコードとか全体のつながりは補える。
勉強がてら、CakePHPで書き換えてみたいなーって思ったり。

なるほど感が多かった1冊。DDDの「入り口の次」くらいに良いんじゃないかなー
最近、社内でもDDDだったり設計に興味ありそうな人がチラホラ目に入ったり、あと「PHPのコードリーディングを練習してみたい・良い題材がほしい」って人も居たりするので、勉強会してみても面白そうだ。

PMBOK対応童話でわかるプロジェクトマネジメント

作者:飯田剛弘
秀和システム

Amazon

yokohamanortham.63 で言及されていた本。

anchor.fm

まず「なんで童話で語ろうとしたんだwww」っていうお茶目さを感じつつ、全体的にそういった軽快さで記述されているので、読み心地としては軽いしとっつきやすいんじゃないかな〜！という印象。
これ1冊で「プロジェクトマネジメントができるぞ！！」というものではないけど、例えば「自分が参加しているPJでマネージャーがどういう事を考えていそうか、何に気を遣っていそうか」が薄っすらと感じ取れるようになったり、自PJの「なんとなく上手く行ってないかも？やりづらいかも？」を観察するためのメガネにはなってくれるかも。

問いかける技術 ― 確かな人間関係と優れた組織をつくる

Amazon

組織開発系の本、ということでいいのかなー。
「問いのデザイン」とか「問いかけの作法」とか(どちらも同じ著者だけど)が「どうやって引き出すか」というよりも、こちらは「どうやって向き合うか、聞き手の態度として何が大事か」のような、より内省的な話を扱っているような印象。
(同著者の「企業文化」「人を助けるとはどういうことか」も積んでる、面白そうだから読みたいんだよなー)

この本は「謙虚に問いかける」という事を重視していて、「謙虚さとはなにか」「なぜ大事なのか」といった話を展開している。
ただ単純に「相手に大して丁寧な態度で接する」みたいな話だけではなくて、もっと受容を重んじるような、「自分の意見を出したり主張したり誘導することなく、本当に相手の中にある/出そうとしているモノを引き出す」といったような話。相手に興味を持つ、先入観を排除する、「聞く」のに集中する・・・

面白くて新鮮だったのは、「思考プロセスに影響を与えるようなの問い」がアンチパターンとされている点。
例えば「内面に何を持っているのか」とか「根底にどういった思考や価値観があり、そういう思考に至っているのか」といったような、会話(=発言など、表面にできていているもの＝コンテンツ)を生み出している原因だったり過程だったりといったレイヤーに意識を向けるような問いのこと。
「よく聴く、相手を立てる」みたいな実践であるはずのコーチングにおいて、こうしたものこそが「相手への興味の向け方」とされているような感じがあり、明確に違うなーと。

もちろん「どっちが良い、悪い」という話ではなくて「適切に使い分けるべき」という話になるのだけども。
いわく、このような問いかけは「本人は思おもよらなかったことを考えさせる」ような方向づけになってしまい、相手の考えようとしていた事柄の道筋に大きな影響を与えてしまう。言ってしまうと「思考プロセスを乗っ取る」「会話の主導権を握る」ような状態に陥ってしまうのではないか、と。

問いや会話の実践を通じて、信頼関係を築いていく事を指向した1冊。
今回はちょっと駆け足気味に読んでしまったけど、分量もそんなに多くないので、またどこかで再読したいなー

アサーション入門

アサーション入門――自分も相手も大切にする自己表現法 (講談社現代新書)

作者:平木典子
講談社

Amazon

アサーションとかアサーティブコミュニケーションっていうのを初めて知ったのはどこだったっけか・・・というのがパッと出てこないのだけど、どこかでしっかり修めてみたいなと思っている分野の1つ。

こうした考え方を知ることは、単純に「他者と上手くコミュニケーションをとる」みたいな事にも効果を発揮すると思うのだけど、もっと抽象的な部分での「自分が自分を大切にできているか」「何にこんなにも傷つけられているんだろうか」を取り出す力が育まれるのかな〜という気がする。

その点で言えば、第3章「考え方をアサーティブにする」で触れられているものが大事そうな感じも。

フォーカシング

作者:ユージン T.ジェンドリン
福村出版

Amazon

コーチング、カウンセリング文脈の本を引き続き読んで見る。
フォーカシングはとてもおもしろいし強力だなぁ・・・と思うのだけど、自分の場合、マインドフルネスやU理論みたいな「実際に自分が感じてみないと、どういう感覚なのかを掴むのが難しいもの」という引き出しにフェルトセンスは入っているような。
自分の場合、コーチングを習う過程で少しは体験していたので、最後まで「面白いなー」って気持ちを維持しながら読めた気がする。

フォーカシング、「自分の内面や感覚に意識を向けて、何が起きていてどんな事を感じているのか・・？を知ったり理解したりする」みたいな話で。これが出来ると、例えば「なんでそんなにイライラしてしまうのかが分かった！！」とか「私が本当に望んでいたのはこういう事だったのかも！」みたいな感じで、気持ちや感覚がほぐれたりと。

特に印象的だったのが、

うなくフォーカシングができているときにはどんな感じが出てきてもうれしく感じるものです。「死んでしまえ！」という内面の感じが聞こえてくるかもしれません。これをおだやかに、理解を示しながら吟味することになるでしょう。たぶん「おや、面白いな。宣告されてる感じだ。道理で行き詰まってるという感じがしてたんだ─もしそこにこんな感じがずっとあったのだとしたら。(後略)」 (P51)

のあたり。
こういう、「めちゃくちゃ憤っているのは自分自身」であるはずなのに、その感情の変化や激しい反応自体も切り離して客体化していくことで、そこから踏み込んで「何がそうなれるのか」についても理知的に分析できるーっていう作用の仕方にはすごいパワーを感じる。

これもまた、「こういう考え方もあるんだな」っていうのを知っているだけでも救われる面はあるのでは？といった1冊。

コミュニティ・オブ・プラクティス

コミュニティ・オブ・プラクティス―ナレッジ社会の新たな知識形態の実践 (Harvard Business School Press)

Amazon

実践コミュニティの話。
会社で考えようとしていたことに関連して、連休の狭間に「ちょっと明日のミーティングに持ち込もうとしているネタについて、うまい説明ができると良いなー」ってことで優先度を上げて読了。

「お互いに知見を共有し合う、同じ領域に興味や課題感を持つ人同士で集まって研究や学習をすすめる」って意味でのコミュニティと、「実際に起きた出来事や行動から得た知識や考察を重んじる、得た知見は現場で活かす」って意味での(理論知でない)実践を、ということで「実践共同体」とか「実践コミュニティ」「プラクティスコミュニティ」とか「PoC(s)」とか言われているものについての本*1。

「ユニコーン企業のひみつ」で紹介されているSpotifyモデルでいうところの「ギルド」とかもコレの1つなんじゃないかな？って思っているのだけど、どうなんだろう。
あとLeSSでも触れられていたり。調整と統合 - Large Scale Scrum (LeSS)

「こういう取り組みがあるんだな」というのを知るためには十分な1冊だなーと感じる反面で、そもそもの性質として「上手くいくやり方を紹介する教科書的な本」っていうのは難しい話題なのかもな、とも感じた。
事例研究を集めて統合した内容にはなっているけど、かといって「どこにでも当てはまる公式」なんてのは無いよなー人や状況に応じて観察して最適化していくしかないよなー・・みたいな。

他方で、「企業活動としてやらなければいけないこと」みたいなのは抑えている気がして、例えば「業績や評価とどう結びつけるか」「組織内でどう位置づけるか」などなど。逆に、(例えばアジャイル系な本とか組織開発系な本であるような)「個人としての喜びをどう描くか、どうエンパワメントしていくか」みたいな側面はあまり触れられていないような印象も受けた気がする。最近割とそういった本ばかりを読んでいたからなのだろうけども。

こういったトピックについて興味がある人は目を通してみても良いかもしれない、ただ「やってみるしかない」「上手くいくかどうかは、まずリーダーシップを」(あと上役の理解と支援！)的なところなので、端から端までしっかり読んで頭に入れる〜〜っていう必要性は薄いのかも。
どうやっていくか？という面では、むしろ、Fearless Changeとか学習する組織とかに必要なことが散りばめられているかも。

The DevOps 逆転だ！究極の継続的デリバリー

The DevOps　逆転だ！究極の継続的デリバリー

Amazon

システム運用アンチパターンのまえがき(だっけな)で触れられていたので買った本。
ビジネスフィクションで描かれた「最悪な状態からどうやってDevOps的なコンセプトの実践・実装で大きな成功を勝ち取っていくか」を紹介する本であり、「DevOpsとは〜」とか「○○のプラクティスを紹介します！」といったものではなく。前情報なく読んでみると面食らうかもw

ある意味では「理念」「価値観」「哲学」といったものをまざまざと描き出して伝えてくれる1冊でありつつ、全てが物語の中で展開しているので、「ここから何を(具体的なプラクティスや進め方として)学ぶか」については、読者自身がしっかりと要約したり抽象化する必要がありそうかな？っていう印象。

中身としては(対立者がめちゃくちゃ最悪でストレスが溜まる、っていうのを除けばw)スルスルっと読めるし「あるある」的な内容もふんだんに盛り込まれているし、読み物として楽しめる内容でもあったし〜で面白かった

現場で役立つシステム設計の原則〜変更を楽で安全にするオブジェクト指向の実践技法

作者:増田亨
技術評論社

Amazon

良いコード／悪いコードで学ぶ設計入門―保守しやすい　成長し続けるコードの書き方をGW前(配信開始日)に読んだことをきっかけに、未読だったな〜と思って手にとった本。
今の所の自分だと、何かめちゃくちゃ目新しいことを学ぶぞ・・・！という期待よりも、「何か会社とかで若手に勧めやすい本があるといいな」「他人に説明する時に分かりやすい文章とかを吸収したいな」という期待が強めだった。

読んでみて、評判に違わず「色々な人にオススメして良さそうだな、早い段階で出会ってほしいな」という印象に。
これ1冊で「設計が出来るようになる、引っ張っていける！！」っていうものではないにせよ、大事な心構えが埋め込まれていると思うし、「ガンバに持って帰って実践する」のに能う本だなーと。
「業務ルールにしっかり目を向けておけ！」みたいな点が強調されていたり、「データベースとアプリケーションコードがどういう関係になるべきか (変な癒着を避けないといけない)」という罠っぽいところも抑えてあったりと、抑えているポイントが気持ちよかった。

A Philosophy of Software Design

作者:Ousterhout, John
Yaknyam Press

Amazon

どっかで読まないとな〜〜って思って読めていなかった1冊、これが読めてよかったな。。
必ずしも全面同意ではないものの(モジュール(というかクラスか)についてのスタンスなど)、考えは明快で力強いな！！と思うものがとても多く。
あと英文も読みやすかった印象！

Deep Moduleって単語はこの発表で初めて聞いたものだったのだけど、やっぱりオリジナルを読むと「なるほどな！！」感がまた1つ変わってくると言うか。
あと、個人的には、コメントについての考え方がとてもおもしろかった。
General puserposeとSpecial purposeも共通性可変性分析に通ずるものを感じたし、レイヤー分けとか”Pull Complexity Downwards"とかに繋がっていったりと。
複雑性とは何か？という定義(解釈)についても、シンプルによく言い切っているな〜って感心して納得したり。

仕事でコードレビューをする際に机の片隅に置いておきたいし、そういう仕事をする人には1回読んでみてほしいなぁとも感じる。
名著と名高いだけあるなー

本の最後に「Summary of Design Principles」「Summary of Red Flags」が載っているのも助かるし、著者の想いとか願いとか苛立ちみたいなものを感じる

プロダクト・レッド・オーガニゼーション　顧客と組織と成長をつなぐプロダクト主導型の構築

Amazon

ば〜〜っと駆け足気味に読み流した感じ。より思想的な部分、哲学的な部分を期待していたけど、どちらかというと「数字をどう設定するか(何をインジケーターとして扱うか)」だったり「運用をどうするか」みたいな具体の話の方が、この本においては面白かった印象。
そういう意味では、少し物足りなかったり期待が満たされなかったのかも。
組織文化やコアとなる精神といったもので、「根本的に今とは考え方を変えないと強くなれないぞ！！！」と思わされるようなガツンとくる衝撃は無かったかもなー的な。個人的には、プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届けるの方が好きそう。

「製品開発、サービス提供」の分野については、いくつかのコンテキストで同様に語られることがある気がする。セールス、マーケ、プロダクト(開発)、顧客リレーション・・・例えばカスタマーサクセス系の本を読むとセールスだったり顧客リレーションが多かったり。その意味でいうと、この本はマーケティング畑の本かな？って何となく感じた。

翻訳者ご本人のスライドが https://speakerdeck.com/ykmc09/product-led-organization にあるので、先にコチラに目を通してから本書を手にとって見ると、より面白そう！

*1:長澤さんの記事 https://www.servantworks.co.jp/posts/scrum-master-community-of-practice/ や、ここでも言及されている「Scrum実践者が知るべき97のこと」でも紹介されてる

2022-05-01

やったこと・書いたもの{2022,04}

やったこと・書いたもの

OSS

勉強会・LT

PHPerKaigi 2022に登壇しました

その他

@hanhan1978さんにお呼ばれして、2回目のポッドキャスト出演で喋ってきました！
とても楽しかったです✨(普通に喋っているだけなので、これで良いのだろうか？っていうのは毎回思うw

anchor.fm

悲しいのはこの2日前に使っていたマイクが壊れていてEarPodsで喋らざるを得なかったこと・・・

2022-04-09

PHPUnitの実行結果(失敗したテスト)をProblem MatcherでPRのdiffに示す

PHP CI

PHPerKaigi 2022でLTしてきます。

fortee.jp

で、Problem Matchersの話に触れるのですが、5分では触れられ無さそうな内容を予め残しておきます。

Problem Matchers？

↓みたいな感じで、PR時のdiff上に「ここが間違っているよ！」を示す仕組み(の1つ)。 f:id:o0h:20220409013844p:plain

ざっくりいうと、

GitHub Actionsのアウトプット内容(actionsの実行結果画面って、標準出力的なやつありますよね)からPRのGUIに転記する〜という感じの仕組み
「標準出力をパースするための定義(regexpのパターンや、その反映先のタクソノミーとの関連付け)」を予めどこかに用意しておいて
GItHub Actionsのstep上で、特殊な記法(=コマンド)を使って↑の設定ファイルを有効化させる
- ::add-matcher::{{ 定義ファイルのパス }} という内容をechoする

という流れ。

例えば .github/pm-phpunit.json に定義ファイルを置いた場合、↓みたいなworkflowを作ると動く。
run: echo "::add-matcher::.github/pm-phpunit.json" がミソ

name: phpunit
on: pull_request

jobs:
  phpunit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Setup PHP
        uses: shivammathur/setup-php@v2
        with:
          php-version: latest
          tools: composer, phpunit
      - name: Setup problem matchers for PHPUnit
        run: echo "::add-matcher::.github/pm-phpunit.json"
      - name: Composer install
        run: composer install
      - name: Run PHPUnit
        run: phpunit

詳しい話は↓ github.com github.com

実際の例

例として、こんな感じの定義ファイルを用意してみる。
状況をわかりやすくするために、「patternを1個だけ設定する」ようにしている。その影響で、(実用的では無さそうな気はしつつ)「messageには、ファイル名を入れる」という指定になっている。

f:id:o0h:20220409015529p:plain

これを使わせるためのstepを用意した f:id:o0h:20220409015829p:plain

PHPUnitの失敗したテストがある。
この出力内容を、patternに従ってPR(のFile Changes)に抜き出してくれるようになるのだ f:id:o0h:20220409015420p:plain

じゃーん！

f:id:o0h:20220409015505p:plain

という感じで、「regexpに合致したところから」「パターンにあるグループと、属性(要素)に変換して」「File ChangesのGUI上に表示している」ってな様子が分かる。

PHPUnitのProblem Matcherで、お手軽に使えるやつ

shivammathur/setup-phpもしくはdecnorton/phpunit-problem-matcherを使うのが良い。
php-setupを使っていない(独自のimageをbuildしている、など)の場合は後者一択。
利用方法は、それぞれのREADMEやソースコードを参照。

これら2つも、実際に定義ファイルを用意して利用していることになる。ので、「お手本例」を簡単に見ることが出来る。オープンソースありがと〜〜

github.com github.com

ハマった所

現状、setup-phpの方はいくつかのアサーションに対応していない(ように見える)。要するに、「指定されたregexpで対応できていないものが有る」。

↓これはうまくいく。 f:id:o0h:20220409020628p:plain

↓これらはうまくいかない。 f:id:o0h:20220409020654p:plain f:id:o0h:20220409020709p:plain

setup-phpの方の定義ファイルを見てみると、↓のようにpatternが指定されている。

      "pattern": [
        {
          "regexp": "^\\d+\\)\\s.*$"
        },
        {
          "regexp": "^(.*Failed\\sasserting\\sthat.*)$",
          "message": 1
        },
        {
          "regexp": "^\\s*$"
        },
        {
          "regexp": "^(.*):(\\d+)$",
          "file": 1,
          "line": 2
        }
      ]

紐解くと、

「数字＋閉じ括弧」から始まる行があって
そのすぐ次の行に「Failed+スペース+asserting+スペース+that」を含む行があって
空白文字のみからなる行があり
「文字列＋コロン＋整数文字」の行がある

という感じ。

なので、

エラーメッセージがある(失敗例の1枚目には「なんか変だよ！」の出力がある)
expect/actualのdiffがある(失敗例の2枚目には不一致文字列の内容の出力がある)

といったケースでは、Problem Matcherがうまく拾ってくれ無さそう。

phpunit-problem-matcherの方ではこれらのケースにも対応できている(ようにみえる)ので、現状ではこちらを利用するのが良いかも知れない。

落ち着いたらPR出そうかなぁと言う気持ち

2022-02-11

2021年もAdvent Calendarに参加しました

やったこと・書いたもの

メリークリスマス！！！

タイトルの通りで、2021年も年の瀬にAdvent Calendarに参加しました。
(一部の界隈で言う)Advent Calendarとは、12月に入ってからクリスマスまでの日々をカウントダウンしながら、1日ずつブログを書くぞ！！という催事です。

今回は複数のAdvent Calendarに参加して、胸を張ってクリスマス当日を迎えるつもりでした！💪
が、結果として、やっと今日・・・2022年の2月11日・・・に自分の担当分を投稿し終わりました。。。大遅刻ですね気が遠くなる悲しいな病んでしまう。

何はともあれ、完走したぞ、計72日*1を経て全ての作業を終えた！！グランド・フィナーレ！！やった〜〜！！という訳です。

完走の感想

結果とか出だしとか

とりあえず、書いたのはこんな感じ。

月	書いた本数
12月(advent期間)	55
12月(advent期間外)	2
1月	7
2月	11

adventar.org

やろうと思ったきっかけは、各カレンダーの冒頭に書いてありますが、
「あんまり仕事で開発してねぇ・・・」という状況を自覚した上で「だからって技術や開発に関わる成長が無いなんて事になるのは嫌だ、少しでも防ぐために自分なりにやってきたことはあるだろう、であればアウトプットくらい出来て然るべきだな・・・試すか！！」みたいなモチベです。

1人Advent、2018年にやった時は完全に生活リズム崩れたし辛かった印象が強いので、やりたい気はするけど・・どうしたものか・・・と思っていた所に、知人の「今年は1人Adventやる〜」的な声がTL上を流れていきまして。

はぁ、世の中には頑張っている人がいるぞ、じゃあ自分もどうにかなりてぇもんだ・・・と思ったので決心しました。

で、「複数個やる代わりにネタ出しのハードルをめっちゃ下げる」として、「今年既にやったこと」の放出でいけるモノを〜と考えたのです。
最初は「CfP応募したネタをふりかえってみる」＋「ここ1年くらいで興味を持って学んできた、アジャイル/スクラム系の本の感想みたいなやつ」で2本併走のつもりでした。
が、「どの本にしようかな〜」と思っていたら、25本は軽く超えていることに気づきます(既読/積ん読)。し、選ぶとしたらどういう観点よ???ってモヤモヤ感というか割り切れない気持ちが湧き、「あれ・・？もしかして・・？」と積ん読も完全に解禁して数えてみたところ、「ちょっと範囲を緩くしたら50冊近くあるね・・・・」「んじゃ2つに分けるか」となったのでした。

その結果、75エントリー(全部俺)が組み上がったわけです！！

やってみて

11月のうちに本を読み終わってる、少なくとも7,8割は12月に入る前に読み終わってないと厳しいぞ・・・・・と思ってたんですけどね！！
全然そんな状況になってなくて、12月に入る前から「Adventキツい」っていうのが確定しているような状況で。

実際の読了状況はブクログにある通り。 booklog.jp

てなことで、「読みながら書きながら」をやるハメになったのでした。
しかも、その内の何冊かは「重い本」「厚い本」だったり、それに加えて洋書もあると。

特に1月入ってからは、ある意味で「締切」もなくなったので一気に進捗が悪くなってしもうた。

とは言え、なんだかんだでやりきった。お疲れさまでした。「1枚はちゃんとスケジュール通りに終わらせていたし」とか「ゆーて期限内に”普通の2倍以上”は書いてるんだよな」とかいった事実もあり、敗北感はあるものの挫折感はないかもな〜っていうのが今の気持ちでしょうか。それ以上に、ずっと続けていた＆平日も休日も頭の片隅にず〜っと渦巻いていたものがコレで解消したと思うと、やった〜〜〜！って気持ちが大きいのでした。

特に、この試みを通じて「良かったなー」と思うのは、

プロポーザルとしては削ったことや、「自分の中の課題や気持ちでしか無いから、応募内容に含めるものではないんだよな」といった部分を、そこそこ言語化できた。それを公に残すことも出来た。
難しいぞって(自分の中では)位置づけにあって、実際に過去に数度は読み始めるも頓挫していた組織パターンを読み切った
洋書 * 3をしっかり読み切った(A Scrum Bookは、端から端まで読み切ったわけじゃないけど)。今まで「洋書を1冊読み切ったことってあったかな？」という感じなので、実績を作れたの嬉しい。これでハードル下がった。
自分の中で、長い間「いつか読むぞ〜」って思っていたり(Advent関係なく)大きなマイルストーン的な位置づけになっていた本、「LeanとDevOpsの科学」「組織パターン」「A Scrum Book」をしっかり読むことが出来た
特にXP/Lean周りは、(スクラムに比べて)知識の補給・補強があまり行われていない分野だったので、いくつかの積ん読を集中的に消化できた
「エッセンシャルスクラム」「This is Lean」「スクラム現場ガイド」「アジャイルな見積りと計画づくり」「エクストリームプログラミング」「アート・オブ・アジャイルデベロップメント」など、間違いなく鉄板と呼んで差し支え無さそうな本も通読できた

とかとか。
あとは、当初から目標としていた「まぁスクラムとかアジャイルとか勉強してるんですよ〜っていう感じを、(読書記録の物量を以て)形に落とし込めんじゃない？」というのもゴールにたどり着けたのでは！

書いたもの

せっかくなので！全員集合です！！！！！

*1:記事を書いた日は40日程度

2022-02-11

「XPエクストリーム・プログラミング導入編 ― XP実践の手引き」

1人Advent2021-2 読書記録

この記事は「ひとりでアジャイルo0h② Advent Calendar 2021」のday-20です。 adventar.org

day-20は「XPエクストリーム・プログラミング導入編 ― XP実践の手引き」です。

XPエクストリーム・プログラミング導入編 ― XP実践の手引き (The XP Series)

Amazon

どんな本

「XPシリーズ」の1冊で、エクストリーム・プログラミング入門の次のステップの位置づけになると思います。
名前の通り、「XPとはなにか」についての入門書的な説明の後の、「それぞれをどうやって使っていくか」といった部分に重きをおいた話になっています。「こういうイベントを開いて○○を実施しましょう」とか「誰が関係するか」とか、「こんなメトリクスを使うと・・」とかといった話が出てきます。
XP入門が「価値原則」も丁寧に取り扱っていたのに対して、こちらは「プラクティス」よりとも言えると思います。

個人的には、「まずは具体的な話や個別的なプラクティスから理解を広げていってみたい」という人には、XP入門より先にこちらの本から手を出してみる〜というのも良いのではと思います。

お気に入りポイントかいつまみ

「XPって具体的にどんな事するの」が分かりやすい

目次をみると、まるでパターン・ランゲージのカタログのように「具体的な、解法を説明してくれそう」な予感のするタイトルのついた章が並んでいることが分かると思います。
(実際には、パターン・ランゲージのように各章で共通した形式が用いられているわけではありませんが)

目次は紀伊国屋のサイトで確認できます。

www.kinokuniya.co.jp

また、第1章・第2章は全体に関わるものなのでまず目を通した後は、その後の各章は独立して読むことが出来るので、気になったトピックからページを捲ってみる〜という使い方もできると思います。
そのくらい、具体性にフォーカスした内容であると同時に魅力的なパワーのあるプラクティスが取り扱われている、ということです。

「エクストリーム」に想いを馳せる

少なくないプラクティスが、昨今の開発の現場では「当たり前」になっていると思います。
とりわけ「11章プログラミング」にある、コードの共同所有・リファクタリング・シンプルな設計・継続的インテグレーション・コーディング標準・・などは、XPを意識しなくてもやっている！というチームも多いはずです。
名前が「エクストリーム」とイカつい手法ではありますが、その一方で「誰でも知っているしやっている」ものでもある、というのはとても興味深いことです。

裏を返せば、現在の現場にいる我々や私自身にとって「そこまでやる？」とか「歪なやり方だなぁ」と思えているものが、10年も経たない内に当たり前になっている可能性だってあるぞ、という事なのだと考えています。

「なにをエクストリームに推し進めたかったの」「どういう価値感(常識感)からの脱却があったのか」を考察することは、これからの時代を読み解く上で意味を持つのではないでしょうか。
そういう視点から「ちょっと昔に書かれた、熱狂的なXP教本」のようなXP入門、本書XP導入編を読んでみると、また違った大きな発見があるように感じます。

特に好きな章

14章「テストファースト―意図を伝えよう」は、本書の中では長い部類の章なのですが*1、テストファースト/TDDをすると何がどうやって楽になるの・・？が追体験できるような気がします
16章「行うべきか、行わざるべきか」は、アジャイル的な振る舞いを端的に言い表しているなぁと思います
27章「それはChetのミスだ」は、個々人の勇気を重んじつつも「チームとして動いているのであり、責任は(誰か1人ではなく)チームにある」というのを良く理解できる話でした
20章「イテレーションを運転する」は、タイムボックスを定めて開発をしていると絶対に直面する「思ったより進んでないぞ」や「順調と言えるのだろうか？」についての対処の話です

まとめ

全体的に読みやすい・分かりやすいような文章で、躍動感を持った文体は読者にワクワク感を与えてくれるなぁなんて感じながら読み進めていました。
まだまだ「XPのすべて」という話では無いように感じますが(そもそもそんなものがあるのか？)、取っ掛かりとしては十分、そして実行してみるのにも十分！と言える1冊だと思います。

押し付けのように「XPだ、XPをやるぞ！」とやっていくのは難しいのかも知れません。
しかし、本書のように「そういうお困りごとだったら、ちょっとこれを試してみようよ！」と個別的なプラクティスを少しずつ導入していこう〜を助けてくれるものがあると、とても心強いのではないでしょうか。
そして最終的には、端から端までエクストリームになれると良さそうですね！

*1:コードがあるから、というのも1つの理由かと

2022-02-11

「組織パターン」

1人Advent2021-2 読書記録

この記事は「ひとりでアジャイルo0h② Advent Calendar 2021」のday-25です。 adventar.org

day-25は「組織パターン」です。
25！！！やっと！長かったです・・・

組織パターン

作者:James O. Coplien,Neil B. Harriosn
翔泳社

Amazon

どんな本

原題は「Organizational Patterns of Agile Software Development」です。冒頭の記述を見ると、「組織としての学びや、病と癒やし、成長の為のパターン」というところになるでしょうか。
こうした「成長」や「癒やし」というのがアジャイルの性質と深く関わるということで、Agileの名を関して・・・という面もありつつ”「アジャイル」という単語をタイトルに選んだのは、本が売れるようにとの思いからだった。"と述べていますw
一方で、実際に「アジャイルソフトウェア開発にも影響を与えた」とも述べており、ジェフ・サザーランドやケン・シュェイバーといったスクラムの人たち、また「ペアで開発する」のパターンはXPのプラクティスに取り込まれたり、といった事柄が紹介されています。
(そういった影響の度合いを見て、「ひとりでアジャイル」のAdvent Calendarに含めたのです。)

組織パターンが生まれるにあたっての背景を説明したり本書の全貌を解説する「歴史と導入」、パターンランゲージ(カタログ)、より広い視野で組織構造そのものに備わる原則についての「基礎と歴史」、最後に「ケーススタディ」という4部構成になっています。

本書で挙げられているパターンの様子については、オブラブのサイトでコンパクトにまとめられているので雰囲気を掴めるかも知れません。
リンクしておきます。

objectclub.jp

お気に入りポイントかいつまみ

抽象的で難解だが「なるほど」も(かなり)多い

本書はボリュームもそこそこありつつ、「組織」とか「コミュニケーション」「計画」といった抽象的なテーマを扱っています。
その上、「パターンで記述する」というのは、馴染みの薄い人にとっては取っ付きさもあるのではないでしょうか。
そのために、読みながら「自分はちゃんと理解できているのだろうか・・・」とモヤモヤとする場面も少なくなかったです。
まして、自分に経験の少ないところには想像力も働きにくく、例えば「受託開発」「何十人も開発者がいる組織」「厳密にウォーターフォール方式でを用いた開発」「アナリストやテスターと言った役割と責務の分担」などなど、自分は身を持って経験をしたことがありません。そのため、それがすべてのパターンを読解する時に関係するものではないのですが、扱っている前提がピンとこない・・・というハードルがあります。

ただし、目指しているものは共感できていると感じます。
「ちゃんと働きやすい組織を作って、プロジェクトがいい感じに進むようにしようぜ！」という。そのために「厄介な課題」を特定して「こういう時どうしよう」を記述したパターン集であり、「それをクリアしたら次に・・・」とか「そこまでいったらコレもできるはず」といった、パターン同士の連なりが描かれている本です。

ということで、自分としては「変にハードルを上げすぎないで気楽に読む、それだけでも十分に学ぶものが多い！」と肩の力を抜きながら読んでいました。
(往々にして、歴史の淘汰を超えて生き残っている本は、「然るべき時に自分が読んだら嘘みたいに分かりやすい」という性質を持つものが多いので。)

とりわけ、スクラムやXPに触れたことのある人は、その「元ネタ*1

例えば

「¶ 4.1.3 ぐずぐずするな」と「¶4.1.7 プロトタイプを構築せよ」は、「出荷可能なインクリメント」の精神性に見て取れたり、
「¶4.1.13 ワークキュー(を優先度付けされた作業の一覧を作り、それをスケジュールとして扱う)」はバックログの管理を思い浮かべたり、
「¶4.2.7 顧客の代理」は、そのままXPの「オンサイト顧客」→ スクラムの「プロダクトオーナー」に通ずるものを感じますし、
「¶4.2.8 シナリオが問題を定義する」はユーザーストーリーを
「¶ 4.2.12 目的の統一」は、インセプションデッキの「我々はなぜここにいるのか」を想起します。
- 「¶ 4.2.19 全体論的多様性」は、クロスファンクショナルチームという概念に繋がっていきますし、
「¶ 5.1.2 ロールは少なく」は、まんまスクラムチームの「プロダクトオーナーと開発者しかいない」に繋がっていくと思ったり、
「¶ 5.2.7 スタンドアップ・ミーティング」は概念も名称もそのまま採用されることが多いプラクティスになっています

といったように、既に定式化されていてよく見知ったパターンやプラクティスとの関連性が浮かぶものが豊富に存在しています。

それ以外にも、

¶4.1.2 スケジュールを小分けにする
¶4.1.9 細かいリスケをしない
¶4.2.16 多様な集団
¶4.2.24 トラックナンバーはほどほどに
¶ 5.2.8 ドメインの粒度に合わせて人員を配置せよ

など、パターン名から「言わんとしていることが何となく分かる」のと課題への共感もしやすそうなものもあり散見されます。

こうした、実感の湧きやすいパターンが多く含まれており、ただ壮大な「組織パターン」というハードルにビビりながら読むよりも、1つ1つ見ていったら結構馴染みやすい印象になるのではないか〜という気がしました。

自身の環境における問題にどう適用するか？

パターンランゲージ(カタログ)の強みの1つは、「自分が何となく感じていたモヤモヤについても、コンテキスト・課題を言語化して、その対処法と注意事項も示してくれる」という点です。
この本においても、読みながら「あ、最近気になっているああいうの、もしかしたらこの観点で捉えてこういう風にしたら改善できるのかも」と感じているものが多々ありました。あるいは、自然と出来ていることに対して、しっかりと名前がついてパターン＝形式として認識できるようになったり、など。

個人的には、

¶4.1.14 非公式の労働計画
¶4.1.17 開発者がプロセスをコントロールする
¶4.1.18 作業が内側に流れる
¶4.1.22 誰か一人を犠牲にする
¶4.1.28 手を止めて始めた作業を中断するな
¶4.2.9 防火壁
¶5.1.4 中央の生産者
¶5.1.12 循環領域を作る
¶5.2.15 インターフェイスの背後のバリエーション*2
¶5.2.17 緩やかなインターフェイス

辺りについて、特に気に入ったり意識したいなと感じたりしました。
わかっているものや、分かってはいるけど意識しないと中々そうならないものや、全く出来ていないな・・・と感じるようなものが含まれます。ただ、組織パターンに導かれて「組織を今より強くする」という気持ちを持つと、非常にヒントになることが多いです。

まとめ

Team Topologiesでも「いかに組織構造を扱って問題を解決するか」「コミュニケーションパスをどう設計するか」という話題が論じられていましたが、組織パターンも非常に広い観点から「組織」を描いています。

少なくとも言えるのは、「引き出しを増やす」ことができる1冊です。目の前で発生しているコンテキストとそこに起因する課題の見抜き方、そこにどう対処するか・・・という引き出しが増えます。すなわち、識別できる・検知出来る問題のレパートリーが増え、それに対応するための解法も増えるということになります。

先述の通り、いきなりすべてを理解する・・・というのは困難かと思いますが、「気楽にパラパラとページをめくってみる」「何か困ったときやうまく行かない時にまた手にとって、ピンときそうなところだけ読み直してみる」くらいのカジュアルさが大事に思いました。

*1:必ずしも時系列的な意味合いでの「元」ではなく。各パターン/プラクティスの扱っている概念としての上下や前後的な

*2:これとか、筆者がなんて言おうと正にアジャイル開発的な雰囲気だ

どういう本

トータルの所感

お気に入り箇所

9つの特性

4つのリーダーシップのアプローチ

愛着スタイル

まとめ

最近の本の読み方

雑感

読んだ本の記録↓

Domain-Driven Design in PHP

PMBOK対応 童話でわかるプロジェクトマネジメント

yokohamanortham.63 で言及されていた本。

問いかける技術 ― 確かな人間関係と優れた組織をつくる

アサーション入門

フォーカシング

コミュニティ・オブ・プラクティス

The DevOps 逆転だ！究極の継続的デリバリー

現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法

A Philosophy of Software Design

プロダクト・レッド・オーガニゼーション 顧客と組織と成長をつなぐプロダクト主導型の構築

勉強会・LT

その他

Problem Matchers？

実際の例

PHPUnitのProblem Matcherで、お手軽に使えるやつ

ハマった所

完走の感想

結果とか出だしとか

やってみて

書いたもの

どんな本

お気に入りポイントかいつまみ

「XPって具体的にどんな事するの」が分かりやすい

「エクストリーム」に想いを馳せる

特に好きな章

まとめ

どんな本

お気に入りポイントかいつまみ

抽象的で難解だが「なるほど」も(かなり)多い

自身の環境における問題にどう適用するか？

まとめ

PMBOK対応童話でわかるプロジェクトマネジメント

現場で役立つシステム設計の原則〜変更を楽で安全にするオブジェクト指向の実践技法

プロダクト・レッド・オーガニゼーション　顧客と組織と成長をつなぐプロダクト主導型の構築