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

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

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

どんな本

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つの理由かと

「組織パターン」

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

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

どんな本

原題は「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:これとか、筆者がなんて言おうと正にアジャイル開発的な雰囲気だ

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