「A Scrum Book: The Spirit of the Game」

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

day-25は「A Scrum Book: The Spirit of the Game」です。

どんな本

スクラムパターンランゲージとして捉えてみたらどう説明されるのか」といった試みをまとめた本です。
個人的に「読むハードルがなかなか高そうだぞ」という気持ちと、「スクラムの次の姿を感じさせてくれそうな本だな」という思いから、このAdvent Calendarの最終日にこの1冊を選びました。

各パターンについてはWeb上でも見ることが出来ます。

Scrum Patterns

組織パターンについて調べていて→「スクラムをパターンの観点から紐解いてみる」という試みを発見して(kawagutiさんのブログ)→ 「Scrum PLoP」なる活動を知り→本書にたどり着く、という流れで出会いました。

kawaguti.hateblo.jp

認定スクラムマスター研修で「スクラムと組織パターンは密接な関係がある」という旨のことを教わり、その組織パターンのJames O. CoplienもJeff Sutherlandと一緒に本書に名前が挙がっており、ますます「これは凄そうだ」とテンションが上がったわけです。

フレームワークとしてのスクラムは「変えることなく使え」が鉄則であり、それゆえに「どんな組織でも広く使える」であろうミニマルなルールを設けています。その一方で、コンテキスト依存が大きくなるものや、「いつでも守るべき」とはいえない要素に関してはスクラムガイドからは記述が落とされているようにも思います。
その点、「適用すべき順序こそあるものの、その時々の状況に応じて選択して必要そうなもの・効果の高そうなものを適用する」という「パターン・ランゲージ」としてのスクラムでは重厚感が増しています!

・・・ただし、今日時点ではまだ本書全体を通読はしていません。(単純にまだ読めていない。。)
ボリュームもそこそこあるので、まずは本書の冒頭でも薦められている通り「端から端まで読む感じではない」「The Scrum Core as Patternsを読んで、”パターンってどんな感じだろう?”を掴んでから、各パターンの太字部分を読んで全パターンをサラっと抑えてみる(Skim all the patterns by reading just those parts of the patterns that appear in boldface.)」という読み方をしました。
これによって、全体的な雰囲気は多分つかめたはずです。多分。

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

スクラムのコアなプラクティスがパターンとして組み込まれている

本書は2つのパターンランゲージからなっています。「Product Organization Pattern Language」と「Value Stream Pattern Language」です。
前者はチームや人的な側面・・役割や関係性、関わり方について(the roles, relationships, and gatherings of the peolple)。後者はものづくりの側面・・制作の流れプロダクトづくりについて(the organization of the workflow)描かれたものです。

例えば、「プロダクトオーナー」「開発者(開発チーム)」「自己組織化チーム」「スモールチーム」「クロスファンクショナルチーム」といったパターンは「Product Organization Pattern Language」に組み込まれています。一方で、「スプリント」「バックログ」「スプリントレビュー」「インクリメント(シュッ可能なインクリメント)」といったパターンは「Value Stream Pattern Language」のなかに組み込まれています。

(・・というか、スクラムガイドにでてくるこうした言葉が「パターン」として参照可能になっているのは何かゾクゾクするものがありませんか😏*1 )

それぞれが、いち「パターン(単語)」として定義されているので、「なぜスクラムがこのような形になっているのか。例えば、デイリースクラムは何の必要性があって・どんな(想定される)コンテキストに対応するために存在しているのか」といった説明を、リファレンスとして簡単に引く事ができます。

例としてデイリースクラムを見てみます。
ただの「プロセス(やり方)」としてデイリースクラムを捉えた場合、「毎日同じ時間に集まって、チーム全員で話して、問題を発見する場」という風に思われがちです。よく「日本語で言う朝会」といった説明がされるのは、そうした実態があるからでしょう。
しかし、「問題を解決するための解法」として考えるのがスクラムのパターンとしてデイリースクラムが現れます。それは、次のように説明されています。

Have a short event every day to replan the Sprint, to optimize the chances first of meeting the Sprint Goal and second of completing all Sprint Backlog Items. (via http://scrumbook.org/value-stream/sprint/daily-scrum.html)

「スプリントゴールの達成のために、その次にスプリントバックログアイテムの完了のために、毎日スプリントを再計画する短いイベントを行う」と言われると、少しドキッとする人もいるのではないでしょうか。
何故「定点的に毎日集まって話すことに『日々のスクラム』なんて名前がついていたのか」という謎も、少し解けてくるはずです。

「デイリースクラムは、コプリエンの組織パターンにあるスタンドアップ・ミーティング(デイリーミーティング)を発展させたもの」とされているのも興味深いところです。

「ランゲージ」として各パターンの有機的なつながりを知ることが出来る

パターン・ランゲージということで、各パターンのつながりが重要視されます。「単語」と「文法、文」の関係と言われるような、そういった組み合わせについても「パターン・ランゲージとしてのスクラム」では提示されるのです。(ソフトウェア開発者にとって1番馴染み深いGoFデザインパターンにおいては、こうした「つながり」は重視されていませんが。)

これも非常に面白く興味深いな、と思った点でした。

f:id:o0h:20220211105501j:plain
Product Organization Pattern Languageの体系・つながり
f:id:o0h:20220211105552j:plain
Value Stream Pattern Languageの体系・つながり

いずれのランゲージも「The Mist」が起点となっており、これを「はじめに」のようなものだと考えると、Product Organization Patternの方のランゲージでは本書の副題でもあるThe Spirit Of The Gameが/Value Stream Patternの方のランゲージではVision(Product Vision)がスタートとなっていることが見て取れます。
これとはまた少し違った視点で、「パターンが現れる(?)順序」も記述されています*2
下記リンクからそれぞれ参照することが出来ます。

https://scrumbook.org.datasenter.no/sequences/product-organization-sequence.html / https://scrumbook.org.datasenter.no/sequences/value-stream-sequence.html

Composing Your Own Pattern Language

これだけ多様な「問題の特定」「解法の形式化」を通じた「パターンの定義」を提供しながら、本書は第4章にて「自分たちの言語を作るんだ!」と提唱します。
そもそも、この本やその他の多くのパターンランゲージ(組織パターンとかGoFのパターンとか)が、ワークショップを通じて参加者の経験を抽出し編纂されたものです。そう考えると、「決定的で恒久的なもの」でも「定理として存在するもの」でもなく、」でもなく、「その時々で多くの人に通じる内容が共有されている」とでも言うべき、流動的なものにも感じます。
そのため、「各パターンのうち適切なものをチームは自ら選択し採用することが出来るし、自分自身の経験から本書にないパターンを発見することも出来る」とされています。

まさにアジャイルの「計画に従うことよりも変化への対応を」のとおりですよね。
オレゴン大学の実験」でも、アレグザンダーはコミュニティやプロジェクトが自らのパターン・ランゲージを作る可能性や効果について言及しています。
そして、本書でもアレグザンダーの思想を以下のように引用しています。

Christopher Alexander humbly called his original pattern collection "A Pattern Language" rather than "The Pattern Language." His intent was that people pick and choose patterns from his book, add some of their own, and create their own language that communicated the vision of what to build.

『A Scrum Book: The Spirit of the Game P452』

この章がとても魅力的で重要に感じたのは、『形を変えずに使うべきだ」と説明されるスクラムフレームワークに対して「自分たちの道を歩む」ことが如何にに有用で現実的であるか、を伝えているからです!*3
『よく出来た形」に変更を加えるのは恐ろしいことです。が、「いつかはやるべきだ」と。何が良いパターンで、何が良くないパターンなのか・・・
本書では次のような記述がありました。

In short, be guided by what may be the two most important patterns in this book: the first one, and one of the last ones─ ¶1 The Spirit of the Game and ¶93 Greatest Value_, respectively.

『A Scrum Book: The Spirit of the Game P455』

この2つを最大限に尊重して、正しい方向へ進めているかどうかを自ら占い続けていく・・という感じでしょうか。

関連して、「パターンとして」のスクラムを考えて見る時に、 UltimateAgileStories 10th Anniversaryに収録されている@kiroharadaさん*4の発言に非常に興味深いものがあったんだよなーと思い出しました。

文脈が分かるように、その前後を抜粋してみます。

さかがわ)アジャイルを始めたときに、すごい衝撃を受けて、いきいきと働けるとか楽しいとか。そういうことが、アジャイルが広まった理由なのかな?っていうのが、私がアジャイルを知ったときに感じました。私は入社してからスクラムという形でしか仕事をしたことがないんですけど、メンバーとか変わっているけど、同じスクラムをやっていても、仕事がすごいしんどくて追われる感じのときもあるし、楽しいと思う時もあって同じスクラムやって いても、判らないことが多いなって思って。同じアジャイルをやっていても、楽しく働ける、輝いている状態と、そうじゃない状態と大きな違いがあるんじゃないかって。なんか大事なことがあるのかな?って思いました。
や)それは、パターンを適用しても、いきいきしてないっていう話ですよね。
きょん)まさしくそういう話ですよ。
(中略)
きょん)あー、なるぼど。そういう意味ではうちのチームはまさしくそこをやっている感じです。自分たちのチームのパターンランゲージを毎日インクリメントしていっているんで。その場合は自分たちのパターンランゲージを書いて、実際うまくいった秘訣はこうだったっていうのが書かれて、次の日以降それを実際使ってみて、なんか違ったかもしれないっていって、また変わっていってみたいな感じで自分たちのパターンランゲージを作っているんで、それは前よりもいきいきしている感じがありますね。
原田)スナップショットだからね。出てきたランゲージって、その時の。それはスクラムパターンランゲージが、「The」じゃなくて「A」であること。たまたまその一個のカタマリに過ぎなくて、もっとたくさんの良いスクラムパターンランゲージがあっていいはずっていうところに立っているからそうなっていて、じゃあパターンランゲージをそのままコピーしても同じようにならない、っていうプロセスの方を気をつけておく方がいい形になるだろうなって思うんですけど、やっぱり回答集として扱いたくなるんですよね。計算ドリル解くみたいに。そうするといきいきしないよね。

『UltimateAgileStories 10th Aniversary P21-23』

「ルールブックとしてのスクラム」を尊重する。それは十分に煮詰められたものでもあるはずなので。
他方で、それを「回答集」にしない・・・The Spirit of the Gameを大事にしながら、「スクラムはそれだけじゃないはずだ」という気持ちで「自分たちの言語」を紡いでいくという。そうした取り組み方が、非常に重要になっていく気がします。
(もちろん、そうすると「スクラムであるかどうか」を超越して呼び方は軽微な問題になるのかもしれません。その段に至っては自分たちらしく自然体での身体の運用が出来るのかと思います)

まとめ

core patternsも含めて各パターンが「コンテキスト」「ソリューション」「フォース」に砕いて記述されていることで、より深く「スクラムが何を目指しているものなのか」を理解できるような気がしました。
その上で、「軽量なフレームワークとしてのスクラム」だったり「スクラムガイド、ルール」を超えた学びが非常に多いです。それも、「スクラムがやろうとしていること」に密接に紐づく拡張です。

そういった意味で、「スクラムの基礎に立ち返るものであり、その先を見据えた超越を志すもの」のような感覚を持ちました。
ある意味、通常のスクラムは「よく設計された軽量で最低限のフレームワーク」だとするなら、それを包含する形で「スクラムパターンランゲージ」があるようにも見なす事が出来るはずです。
そうした「広いスクラム」を手にとって考えられる点で、重量級ではあるけど非常に面白いし今後も手元に置いておきたい1冊だなと思いました!

*1:Scrum Core Patternとして、集約して言及されています https://scrumbook.org/book-outline/the-scrum-core-as-patterns.html

*2:ちょっと自分がsequenceの意味を汲み取りきれているか自身がないのでした・・・。 A sequence is more structural than temporal, and it may take a small bit of mental training to think of it in other than the terms we normally use for development processes. とされています。

*3:いわゆる”ScrumBut"についてどう考えればいいのか?については、また別の問題としてあるかも知れませんが。

*4:kiroさんのパターンについての活動は https://www.slideshare.net/kiroh/ss-57444498 など

「パターン、Wiki、XP ~時を超えた創造の原則」

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

day-24は「パターン、Wiki、XP ~時を超えた創造の原則」です。

どんな本

非常に名著でした。
タイトルだけだと「その3つに何の関連性があるのか」というのも分からなそうで、とてもとっつきにくそうな印象を覚えるかも知れません。
自分は「周りの人(の一部)がみんな読んでいる/読むべき本として名を挙げているから」というフワフワした理由で購入しました。

具体的な技術やプラクティスの本ではなく、歴史を紐解いて「どのように今のソフトウェア開発に影響を与えるものが、今のような形になってきたのか」という物語のような読後感を得ました。

タイトル通り、「(GoFデザインパターンの源流となる)アレグザンダーのパターン・ランゲージ、それ以前の思想」「オブジェクト指向とソフトウェア開発におけるパターンの発見と普及」「パターンとWiki」といったトピックに触れていきます。
「一見、何の関連性があるのか分からない」もの同士が「実は密接に絡んで影響しあっている」というのがよく理解できました。

こうした背景を知ることで、それぞれのコンセプトやその他の派生物について知る際にも「どのように見て取り、接するか」も変わっていくかと思います。

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

「パターン・ランゲージって何」を知るにはまずこの本からでいいのでは

実は、この本は1度は読もうと手に取るも、「自分にとってどんな事をもたらすのかがイメージできないな」と思って途中で止めてしまっていました。
それを改めたて読もうと思ったのは、「組織パターン」を読もうとして難しい、先に「パターンとはなにか」を押さえたいかもな・・・と考えてのことでした。

オリジナルのパタン・ランゲージが目指していること、その前にアレグザンダー自身がどのように「失敗」「探索」を積み重ねてきたか?を理解することで、より立体的に「パターン・ランゲージの価値」を感じられるようになりました。

これまでは「ただのベストプラクティス集」くらいに捉えていたものが、なぜ「ランゲージ」と呼ばれているのか?「コンテキスト/フォースがなぜ重視されているのか」については、本書を読んで把握できました。
そして「ソフトウェア開発に取り込まれた時に、どのような変容が生じているのか」についても認識できたし、また「パターンをとりまとめてランゲージを紡ぐことの威力」についても本書を通じて感じることが出来ます。

自分にとっては間違いなく「イキイキとした」は特別な意味を持つ言葉になったし、また「参加の原理」「漸進的成長の原理」といったアレグザンダーの提唱した考え方が、いかに「アジャイル的」であるか・・と非常に感銘を受けました。
(実際、本書をきっかけにオレゴン大学の実験 (SD選書)も読んでみて、とても面白く感じました)

自身の見識を広げる「教養」として

この本にあるような内容を知ったところで、明日からの仕事に役に立つ!という性質のものではないと思います。
しかし、個人的にはいち開発者として何かが「開けた」ような印象も持ちました。 少なくともデザインパターンを始めとした所々の「パターン」について、XPの生い立ちについて触れることができたことは、学び方・学ぶべき領域の選び方や感じ方について少なからずインパクトを与えました。
(実際、この本を読んで「パターンとは」を知ったことで、捉えにくいと感じていた「組織パターン」も読破できたように感じています)

「読める本が増える」というのは、1つの教養の効用なのではないかと個人的には思うところです。

まとめ

「この本は、いつ読むべきか?」と考えると凄く難しいと思いますが。
ただ、自分の周りの多くの人に読んでみて欲しい1冊なのは間違いないです。2021年に読んだ中でTOP5には入りそうです。

続きとしては、「時を超えた建設の道」「パターン・ランゲージ:創造的な未来をつくるための言語 (リアリティ・プラス)」といった本に学びを広げてみたいなーと思っています。積んでいます。

「エッセンシャル スクラム」

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

day-24は「エッセンシャル スクラム」です。

どんな本

スクラム全般について扱っている本の中では「決定版」といって差し支えないんじゃないでしょうか、といえる本。

入門的な位置づけて全体を扱った本(SCRUM BOOT CAMP THE BOOKなど)、 特定の領域にフォーカスを絞った本(アジャイルな見積りと計画づくりアジャイルレトロスペクティブズなど)、「困ったこと・ハマりどころ」だったり視座を上げた話題にフォーカスした本(みんなでアジャイルSCRUMMASTER THE BOOKスクラム現場ガイドなど)は色々とあり、またどれも読むべき本たちだと思います。

しかし、意外と「スクラム全体について、しっかりと踏み込んで扱った本」は珍しいと感じました。

基礎的なレベルから扱われおり、それでいて中級レベルに踏み込んだような人(例えば認定スクラムマスター研修を受講しました、くらいの)にとっても一読に値する本になっていると思います。
(スクラムについて知ろうとした人が1番最初に読む、というのには少し重いかも知れません。読めると重いけど「ページ数が少なくて全体感を掴める」という本は他にもあるはずなので、そっちを掴んでからのほうが良さそう)
また、1つ1つのトピックについて丁寧に扱われていることから、リファレンスにも使えそうです(まえがきの「本書の使い方」にも書いてあるとおりです)。

大凡、頭と経験で叩き込んだ後はスクラムガイドを読み直して大事な要素を思い出す・確認する事が多いかとも思いますが、他の人と認識を揃えたりインプットを提供するには、やはり「ルールブック」だけでは足りません。その点、「なにを・どんな形で説明すれば良いのか?」については本書が活躍してくれるかと思います。

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

本質的で補足的なスクラムのガイドブック

スクラムは「軽量なフレームワーク」です。
そのために、(スクラムガイドを使って)実際に現場で取り入れようとするには、「スクラム外」の補助的なプラクティスが必要になってきます。
本書は、そのどちらもしっかり扱っています。

第3章までに「スクラムフレームワーク」や「アジャイルの原則」がしっかり目に描かれます。
(ここまでだけでも、「なぜアジャイルか」を理解する上で重要な論点が多数説明されているので良い感じです。たくさん線を引きました。)

そして4章〜23章までが、個別的なトピックを扱いながら「スクラムの○○」を扱っていきます。
スプリント、ロール、バックログなどの「スクラム内」の話から、ユーザーストーリーやマネージャー、プロダクト/リリース/ポートフォリオプランニングなどの「スクラム外」の話も含めてです。

そうした「スクラムをやろうとしたら現実的に立ち現れる壁」に先手を打ってフォローしてくれる様子が、この本を決定版たりうるところまで「信頼できる本」に高めていると感じるのです。

個人的には、第8章「技術的負債」についての考察や「いつ・どうやって対処すべきか」が論じられている点はグッと来ました。
「ヘロヘロScrum」に語られているように、なぜか「内部品質を置いておいてどうにかする」という症状が時折あらわれる・・と言われます。

bliki-ja.github.io

なぜ技術的負債が悪影響を与えるのか、それがどのような形で現れてくるのか。どのように、スクラムの中で管理していくか?について説明されています。

そうした「避けて通れない問題」「深く考えなければならない問題」を、1冊で総合的に取り扱ってくれているのが本書のお気に入りポイントの1つです。

どうやって歩んでいくか

「基礎的な内容を(も)扱った本」でありながら「守破離の守より先へ歩ませるための本」であるとも感じます。
そのために「スクラムは何であるか」「何が起きるか」を理解していることが不可欠です。
その役割を言って担おうとしている、という意気込みが感じられました。

とりわけ、最終章「未来へ」は強いメッセージが散りばめられています。

個人的にハイライトした一節です。

スクラムを採用するときには、事前に物事を完璧にしなければならないと心配してはならない。そんなことはできないのだ!さらに、事前に完璧にしようとすると、当てずっぽうをしなければならなくなる。その場合、スクラムを適用して何が起きたかを見ることでしか得られない重要な学びが得られなくなるのだ。経験上、たいていのチームの最初の2回程度のスプリントは、うまくいかない。それでよいのだ。私がスクラムチームに対して望むのは、次のスプリントでは、前のスプリントよりもよくなってほしいということだけだ。だから、始めるのを遅らせてはならない。今の時点で、スクラムをどう使うのかわかっていると思っていても、次のスプリントをやりきった後になって、どれだけのことがわかるかを想像してほしい。

Kenneth S. Rubin. エッセンシャル スクラム (Japanese Edition) (Kindle の位置No.9171-9177). Kindle 版.

スクラム自体が「学習し続けていくこと」を大前提としてフレームワークだと思っています。
裏を返せば、「やってみて(検査)得られる学びに重きを置く」ともいえるし、「やらないとわからない」「最初から完成しているものなどない」ともいえるはずです。

「次のスプリントをやりきった後になって、どれだけのことがわかるかを想像してほしい。」とは、正に希望であり非常に心を掻き立てられるメッセージだな、と感じました。

まとめ

非常に力強く、頼もしい本だと思います。
(ボリュームもそれなりにある・・!)

スクラムガイド自体は適宜アップデートされていっていますが、本質的な部分は変わっていないはずです。
その本質にしっかりとアプローチしているので、本書も多少の読み替えは求められど古びることは無さそうに思います。

スクラムを学び始めた人には必ず推したいなと確信できる1冊でした。

「ジョイ・インク 役職も部署もない全員主役のマネジメント」

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

day-23は「ジョイ・インク 役職も部署もない全員主役のマネジメント」です。

どんな本

元気の出る良い本ですね!!
とてもざっくり言えば「XPを取り入れて、本当に大事なもの”喜び”に基づいた組織づくりをする」という感じでしょうか。

個人的には、XPやアジャイルが本当に目指しているのはこういう事なんだろうなぁ・・と思います。
ビジネス的にも、という面はもちろんあると思いますが。それ以上に、「開発者が本来的なやりがい・働き方を取り戻す」「イキイキとしたソフトウェア開発」として、みたいな。 完璧な計画を立てて、そこから寸分も違わぬように1人1人が行動をするように求められる・・という従来的な科学的管理手法や「機械のパーツのような」ソフトウェア開発よりも、1人1人が持てる力や創造性を発揮しながらお互いに助け合ってダイナミックに目的に向かっていく、というような「アジャイル」です。

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

単なる「働きやすさ」に留まらず「価値のある仕事」をすることを喜ぶ

もちろん「退屈な働き方なんてやめて、苦しさよりも楽しさを持って開発しようぜ!!」的な話でもあるのですが。
それ以上に、印象的だなぁと思ったのは「自分たちの楽しさ」だけでなく「社会、顧客にとって喜んでもらえるもの」をとても大事にしている点でした。

誰でもすぐ当たり前だと気づくように、喜びに満ちたチームのほうがよい成果を出す。それに僕たちの喜びは内部だけに閉じない。僕たちのねらいはここでの仕事が世界に出て行き、広く普及し、期待どおりの人びとが喜んで使ってくれるところにある。喜びに満ちた会社が大事に考えるのは、自分たちがいかに世界を変えるかだ。外部にそうした喜びをもたらし続けられるのは、内部にも喜びがあってこそだ。

リチャード・シェリダン. ジョイ・インク 役職も部署もない全員主役のマネジメント (Japanese Edition) (Kindle の位置No.333-337). Kindle 版.

という文章や、

メンローでの喜びの根幹にあるものは、僕たちが作ったソフトウェアを人が使ってくれ、うれしい体験だと感じてくれることだ。

リチャード・シェリダン. ジョイ・インク 役職も部署もない全員主役のマネジメント (Japanese Edition) (Kindle の位置No.1868-1869). Kindle 版.

などは、素直に「良いな、憧れるな」と思えるものです。

ともすれば「開発者にとっての楽しい働き方」という側面だけを強調すれば、自己本位的で排他的なやり方になってしまうかも知れません。
「本当に良いもの」は「お互いにとって良いもの」とでもいうような、美麗辞句ではない本質的な「意味のあるもの」としても”喜び”を感じました。

アジャイルの話だけどアジャイルの話ではない

いわゆる「アジャイルの本」だったり「アジャイル開発を取り入れて組織を改革するには」みたいな話とは違って、最も本書を際立たせている特徴だとも思うのですが、「アジャイルとは何か」「それを目指してどう動くか」ということが話の軸になってはいません。

「どういうのが価値のある仕事で、プロダクト開発を通じて社会にも従業員にも良い体験をもたらすか」という課題に本気で取り組んだ結果、XPとであって・・・といった話になっています。
「XPを知って、探し求めていたものを見つけた」という話でもあると思いますが、だからといって「XPを目指して組織を作った」という方向性にはなっていないように感じます。寧ろ、自ら到達した「喜び」という価値観が最も太くて中心的な軸になっています。

(なんて事を言いつつも、ペアプロを初めとしたXPを取り入れてみて見事に手応えを感じたり、それが仲間たちにも認められて受け入れられていく様子は少し鳥肌が立つくらい興奮しましたが。)

「ビジョンが鍵」という言葉は強く響いてくるものがありますね。

「ど真ん中に『アジャイル』を置いていないが、ソーシャルチェンジについて描き出した本」だと思いました。

まとめ

ワクワク感のある、楽しい気持ちになる本だな〜と思います。
これをみて、「さて自分はどうやって働きたいかな」とも考えたくなるかも知れません。

インターネット上でアクセスできる文献にも、本書の雰囲気をよく感じられるものがいくつもあります。
これらの記事・資料を読んでみると、より楽しめそうです。

codezine.jp

note.com

「大規模スクラム Large-Scale Scrum(LeSS) 」

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

day-23は「大規模スクラム Large-Scale Scrum(LeSS) 」です。

どんな本

LeSSわかんねーなぁ〜と思い、ちょっと概要だけでも知りたいなーと思って買った本です。
対象読者としては、「 プロダクト開発に関わる全ての人」で「唯一の前提知識は基本的なスクラムの知識」であるしています。
本書は、役割や計画・イベントについて「1チームスクラム(いわゆるスクラム)」「LeSS(複数チームへの展開)」「LeSS Huge(組織レベルへの展開)」といった段階的な説明を各章にて展開しています。
なので、対象読者のスクラムに関する理解を「基礎知識」と限定しているように、スクラムの復習もしながらLeSSへの展開を説明する〜というような流れになります。

どのようにLeSSを導入するのか、どんな狙いをもって利用するのか、どんなチームを構成すべきか、バックログやスプリントの運用について扱われています。

個人的には、「もう少しLeSSの基礎的な内容・体系を頭に入れてから読んだ方が良かったかも」とも感じました。
例えば、本家サイトの学習リソースや

less.works

@ryuzeeさんの概要スライド slide.meguro.ryuzee.com

などが参照できます。

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

LeSSの本だけどLeSSを考えていない組織でもヒントになりそう

まず読了後に浮かんだ感想がこれでした。
「そもそも単一チームのスクラムも稼働できてないぞ・・・」という中で「将来的に選択肢に入ってきたら良いな」「ひとまず、知識としては抑えておきたい」と思い、この本を手に取ったのですが。

LeSSをLeSSらしく活用するためには、やはり「しっかりと基本を抑えて実践する、型を活かす」というのが基本になるのだとは思います。
一方で、スクラムが開発と価値へのフォーカスを求めた結果のフレームワークであるように、LeSSも複数チームで単独プロダクトに取り組むためのフレームワークです。
「どうやってその形に至ったのか」という背景や価値を知ることで、「どういう課題を想定して、どういう対処を選択したのか」を感じることが可能になります。

本書は、まず1チームスクラムでの実践についての解説をしながら、簡単に「LeSS ver.」の概要を示し、その上で「何に気をつけるべきか、どう考えるのか」を紹介します。
こうした「難しいところ、うまくいくためのコツ、考え方」を厚めに扱っている点が面白かったです。
「新しいフレームワークではなく(規模を発展させて使う)スクラムなのだ」としているからこそ、(スクラムを履修した人向けに)どう応用するのか?に焦点を当てている、とも言えるのかも知れません。

その結果として、先述の通り、「必ずしもLeSSを採用しなくても、複数チームやいくつかのセクションに分かれた上での意思決定やコミュニケーションをデザインするには?」というヒントにもなり得るものだと感じました。
Y理論的な組織設計、システムシンキングをベースとした意思決定、「プロジェクトやプログラムよりもプロダクト」といったエッセンスは、汎用的な「複数チームで一緒にゴールを目指すには」といった組織設計にも役立つのではないでしょうか。それらをプラクティスに落としたのが「LeSSのルール」だとしたら、正にスクラムやLeSSの採否に関わらず真似できるもの・学ぶべきものが多くあるな、と感じました。

文化と構造

組織(の全体や部分)の動き方について語っている本なので、構造の話は大きなウェイトを占めます。
その一方で、「何を目指すのか」「何を求められるのか」といった文化的な部分が「構造」を作る上での目的であるとも言えるはずです。

本書は、その両者をどちらも重視しながら扱っているような印象があります。構造やチームのデザインをする際にはその「意図」を、意図を説明する際には「中〜大規模で求めるべき意志の浸透やコミュニケーションの在り方」を欠かさず説明してくれています。

まとめ

LeSS面白そうだな、うまく取り入れたらいきいきとしたプロダクト開発ができそうだな〜という魅力を感じました。
実際に体験としてどこかで触れてみたいなぁ。

ただ、個人的には、この本を読んで「よし明日からLeSSやるぞ!!」と言えるまでの解像度を得るところまでは行かなかったかも知れません。。
(もう少し、「自分が近い内にLeSSやっていくぞ〜〜!」という気概を持って読み込んだら全く違う感想になるかも)

それでも、「スクラムについては少しは勉強したんや・・・」って状態から読んで見る分には、とても興味深く面白かったです。
LeSSか否かを問わず、「複数チームで合意をとって一緒にモノを作っていく」という自体は自分にとっても発生しそうな今日です。なので、フレームワーク自体というよりも少しメタな情報を読み取りながらページを捲っていました。
それが、「プロダクト開発の組織設計を考える人にとっては広くヒントになるんじゃないかな」と感じられた一因でもあるかも知れません。し、そういう向き合い方でも得るものが多かった一冊だったなぁ〜という感想に繋がっています。

「アジャイルコーチング」

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

day-22は「アジャイルコーチング」です。

どんな本

アジャイルコーチとしてチームに関わる」という題目です。どういう振る舞いを求められるのでしょう?といった話が書かれています。

もちろん役割としてアジャイルコーチを・・というのが、本書の最も合致しそうなシチュエーションだと思いますが、もっと広くの人に役立つ本です。
(アジャイルソフトウェア開発をやり始めた)チームのリーダー、マネージャー、スクラムマスターなど。個人的には役割としての「アジャイルコーチ」という存在を認識していなかった時に、「スクラムマスターのやるべき仕事」を理解したくて手にしました。
そして、実際にスクラムマスターの「コーチとして」「チェンジ・エージェントとして」の能力を開発していこうと考えた時には、手助けになてくれそうな本だなと感じました。

「どういう風に・どういう場面でコーチが求められるか」というのは、ひいては「自己管理型のチームを育むにはどう支援すべきか」という話にも通じます。そういう意味で、コーチやリーダーだけではなくてメンバーと一緒に本書を読んでみるのも、チームのレベルを上げる手助けになる気がします。
日本語版の推薦の言葉から、@kiroharadaさんの言葉を借りれば「コーチに限らず、チームでシステム開発をする難しさを知っている人には、ぜひ手にとって欲しい本」とのことです。

「コーチとは」から始まり、アジャイル開発の難しい局面(プラクティスXXを導入したが上手く行っていない、など)についての観察や介入の仕方、そして(チームだけでなく自身も含めた)持続的な成長をしていくための指南へと続きます。

いわゆるコーチングだけでなく、ファシリテーションティーチング的な「やるべきこと」についても扱われた本です。
扱う範疇もチーム作り、技術的プラクティス、カイゼンへと渡ります。

ボリュームの割には中身がギュッと詰まった、それでいて「実行に移すにはこれらはあまりにも状況によりすぎる、自己成長と徹底的な観察(と引き出し)が必要そうだ、それに対してこの本は重要な/頻出する問題についてベースとなるようなヒントを与えてくれているな」と感じた本でした。

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

「直接手を動かさないでチームを支援する」ってどんなイメージ

サーヴァントリーダーシップやコーチなど、「自らがど真ん中に立って課題を解決するわけではない」という立ち回りがあると思います。
実際のところ、それは「出来るはずの人が出来ることをやっていない」というヤキモキした気持ちになったりもすると思うのです。特に、プレーヤーからマネージャーだったりスクラムコーチに転身した場合など。

それに対して、この本には「間接的に助ける」「そっと支援する」といった感じの関わり方を、考え方と具体的な行動指針をあわせて説明しています。

個人的には、第3章にある「質問してはいけない時」、第5章「デイリースタンドアップ」での「自分から先に言わないようにしましょう。」「問題そのものをあげてこないということもあります。コーチとしては、探究心を持ち続けてください。そして、改善の機会がないかと目を光らせてください。」といった箇所など、特に印象に残っています。

チームの成功を一緒に目指す存在ではありつつ、あくまで主役はチームであること、そしてコーチはその支援者である・・・なんて事を感じます。
(忍耐強く付き合っていく、というのがメチャクチャ大変そうではある!)

苦難

チームに対して自ら積極的に関わり影響を与えるのではないにせよ、全くもって放置して消極的・受動的に関われという話ではないはずです。
チームが失敗してしまっては(良い学習にもならない、という意味での失敗)、元も子もありません。

そうすると「チームの停滞」「間違った方向への進行」「自らの”エゴ”を抑え込めるか」などなど、色々な困難が発生します。

本書の多くの章で、「苦難」という節が設けられています。
その名の通り、コーチとしての読者がこれから遭遇するであろう苦難(とその処方箋)を紹介する節です。 こうしたインプットをくれることが、本書の「コーチを目指す人・取り組んでいる人に寄り添った本」としての特徴を際立たせているようにも感じます。

言ってしまえば、コーチに求められる最低限の資質は「自分で考えて最適な選択肢を講じることができる」ことだとも思っています。
なので、必ずしも「マニュアル的に、こうした苦難が現れてくると信じ込む・紹介されている対処を試みる」ことが正解ではないのだと思います。寧ろ、形を変えたり強弱を持って現場に出現してくる事が多いのではないでしょうか。
そういう意味では、別に「正解」や「How to」を与えてくれるものではないはず。

それでも、どうやってチームを観察していくか?どういった部分を(特に)気をつけていれば全体をつかめるか?といったポイントとして非常に有用だと思うのです。

また、「どんな素晴らしい(と自分が思える)ことであっても、人と人がいるところには必ず苦難がつきまとうものだな」とも、改めて感じました。

まとめ

各章・各節をパラパラと捲って見て見るだけでも、思い出しがてら気付かされたり学べることの多い1冊だなと感じます。
時折、手にとってみたいです。

個人的には、より「チェンジ・エージェント」的な側面を強化するのにはFearless Changeと併せて読むことで「踏み出し方」「促し方」「辛抱のやり方」も学ぶと良さそうという気がしました。相性の良い本同士ではないでしょうか。

「チームを育てていきたい」と考えている人には、今の役割や立場に関係なく得るものがある本だと思います

「いちばんやさしいアジャイル開発の教本 人気講師が教えるDXを支える開発手法」

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

day-2は「いちばんやさしいアジャイル開発の教本 人気講師が教えるDXを支える開発手法」です。

どんな本

アジャイル開発ってどういうものなんだろうね?」というのを扱った本です。
「教本」というシリーズ名の通り、レベル感としては初学者向け・実践よりも知識や効果について重心を置いている、それに挿絵が多く見出しもキレイなので紙面の印象としてメリハリのある感じも受けました。読みやすい・見やすいと思います。

個人的には、「アジャイルって全く触れたことがなくて」とか「スクラムやカンバンを始めてみようと思うんだけど」という人たちに渡しやすい本ってないかな?と思って探している中で、手にとった本です。

経営層・マネージャー層に向けて「アジャイルとは」を説明する本は読んだことがあったのですが*1、「開発者だけに向けたわけでなく、PdMやビジネスサイドだけに向けた訳でもなく、本当に概要や思想の感覚を知るためにアジャイルを概説した本」という意味で少し珍しく感じました。(自分がこれまでに読んでいないだけで、そういった書籍はたくさんあるとも思っていますが)

アジャイルについて、登場の背景・考え方の特徴や強み、弱み・(スクラムを例にした)活動の雰囲気を知ることができそうです。

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

概要的であり「なぜ」「なにを」に終止している点

「入門書」にはいくつか方向性があると思うのですが、その中の1つは「真似してやってみれるようにする」ためのプラクティカルな本だと思います。
で、この本はその真逆、とても「概要を広くそれなりに浅く」のレベル感を保っているように感じました。
そのため、開発職が読んでもいいし、非開発職(プロダクト制作/製作に関わっていない人、プロダクト部門でない人も含め)が読んでもOK!なバランスになっています。

「はじめに」で述べられているコンセプト、

アジャイル「開発」という名が示すように、技術者をターゲットとしているのはもちろんですが、経営者やマーケッター、セールスパーソンなど非技術者でもアジャイル開発を理解し実践できるように心がけました。

市谷聡啓,新井剛,小田中育生. いちばんやさしいアジャイル開発の教本 人気講師が教えるDXを支える開発手法 (「いちばんやさしい教本」シリーズ) (Japanese Edition) (Kindle の位置No.39-41). Kindle 版.

が実現されているように感じます。

程よく「どうやって」にも触れている

執筆陣には、「カイゼン・ジャーニー」のコンビの名前もあります。
あちらあとても「現場的」な本でした。まさに「このとおりにやってみよう、真似してみよう」というプラクティカルなところが先にあり、そこに対して理論や背景を解説するような。
もちろん、その「やり方」「理論」の両軸ともしっかりと質が高かったから良い本足り得るわけです。

そんな面々が関わっている本なので、本書も「どういうことなのか」の説明が分かりやすいです。
先に書いたとおり、全体を通じて「概要」レベルの話を展開している訳ですが、そこから「実際にはどんな感じなの」を感じさせる程度に少しだけプラクティスの話も入っています。(例えば「プランニングポーカー」とか「ペアプログラミング」「KPT」なんて単語も出てきます)
これがあることで、「だたの理論」で終わらずに、「実際に現実の開発プロジェクトで使われているんだろうな」というイメージをするための橋渡しになっているように感じます。

まとめ

自分としてはサラサラと読む感じでしたが、初学者が2,3冊目に読むような本としては薦められそうだなと思いました。
例えば「カイゼン・ジャーニーを読んでみたが、より理論的な所を知りたい」と感じた人にとってこの本が答えになるかも知れません。

「あのチームはアジャイルなんとかっていうのをやっているらしいぞ」「なるほど、それは一体何なんだ?」って感じになったら読んでみて欲しい本。