OSS
勉強会・LT
PHPerKaigi 2022に登壇しました
その他
@hanhan1978さんにお呼ばれして、2回目のポッドキャスト出演で喋ってきました！
とても楽しかったです✨(普通に喋っているだけなので、これで良いのだろうか？っていうのは毎回思うw
悲しいのはこの2日前に使っていたマイクが壊れていてEarPodsで喋らざるを得なかったこと・・・
PHPUnitの実行結果(失敗したテスト)をProblem MatcherでPRのdiffに示す
PHPerKaigi 2022でLTしてきます。
で、Problem Matchersの話に触れるのですが、5分では触れられ無さそうな内容を予め残しておきます。
Problem Matchers？
↓みたいな感じで、PR時のdiff上に「ここが間違っているよ！」を示す仕組み(の1つ)。
ざっくりいうと、
- 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には、ファイル名を入れる」という指定になっている。
これを使わせるためのstepを用意した
PHPUnitの失敗したテストがある。
この出力内容を、patternに従ってPR(のFile Changes)に抜き出してくれるようになるのだ
じゃーん！
という感じで、「regexpに合致したところから」「パターンにあるグループと、属性(要素)に変換して」「File ChangesのGUI上に表示している」ってな様子が分かる。
PHPUnitのProblem Matcherで、お手軽に使えるやつ
shivammathur/setup-phpもしくはdecnorton/phpunit-problem-matcherを使うのが良い。
php-setupを使っていない(独自のimageをbuildしている、など)の場合は後者一択。
利用方法は、それぞれのREADMEやソースコードを参照。
これら2つも、実際に定義ファイルを用意して利用していることになる。ので、「お手本例」を簡単に見ることが出来る。オープンソースありがと〜〜
ハマった所
現状、setup-phpの方はいくつかのアサーションに対応していない(ように見える)。要するに、「指定されたregexpで対応できていないものが有る」。
↓これはうまくいく。
↓これらはうまくいかない。
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出そうかなぁと言う気持ち
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 |
やろうと思ったきっかけは、各カレンダーの冒頭に書いてありますが、
「あんまり仕事で開発してねぇ・・・」という状況を自覚した上で「だからって技術や開発に関わる成長が無いなんて事になるのは嫌だ、少しでも防ぐために自分なりにやってきたことはあるだろう、であればアウトプットくらい出来て然るべきだな・・・試すか！！」みたいなモチベです。
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」「スクラム現場ガイド」「アジャイルな見積りと計画づくり」「エクストリームプログラミング」「アート・オブ・アジャイル デベロップメント」など、間違いなく鉄板と呼んで差し支え無さそうな本も通読できた
とかとか。
あとは、当初から目標としていた「まぁスクラムとかアジャイルとか勉強してるんですよ〜っていう感じを、(読書記録の物量を以て)形に落とし込めんじゃない？」というのもゴールにたどり着けたのでは！
書いたもの
せっかくなので！全員集合です！！！！！
- 1st day
- 2nd day
- 3rd day
- 4th day
- 5th day
- 6th day
- 7th day
- 8th day
- 9th day
- 10th day
- 11th day
- 12th day
- 13th day
- 14th day
- 15th day
- 16th day
- 17th day
- 18th day
- 19th day
- 20th day
- 21st day
- 22nd day
- 23rd day
- 24th day
- 25th day
*1:記事を書いた日は40日程度
「XPエクストリーム・プログラミング導入編 ― XP実践の手引き 」
この記事は 「ひとりでアジャイルo0h② Advent Calendar 2021」のday-20です。 adventar.org
day-20は「XPエクストリーム・プログラミング導入編 ― XP実践の手引き」です。
どんな本
「XPシリーズ」の1冊で、エクストリーム・プログラミング入門 の次のステップの位置づけになると思います。
名前の通り、「XPとはなにか」についての入門書的な説明の後の、「それぞれをどうやって使っていくか」といった部分に重きをおいた話になっています。
「こういうイベントを開いて○○を実施しましょう」とか「誰が関係するか」とか、「こんなメトリクスを使うと・・」とかといった話が出てきます。
XP入門が「価値原則」も丁寧に取り扱っていたのに対して、こちらは「プラクティス」よりとも言えると思います。
個人的には、「まずは具体的な話や個別的なプラクティスから理解を広げていってみたい」という人には、XP入門より先にこちらの本から手を出してみる〜というのも良いのではと思います。
お気に入りポイントかいつまみ
「XPって具体的にどんな事するの」が分かりやすい
目次をみると、まるでパターン・ランゲージのカタログのように「具体的な、解法を説明してくれそう」な予感のするタイトルのついた章が並んでいることが分かると思います。
(実際には、パターン・ランゲージのように各章で共通した形式が用いられているわけではありませんが)
目次は紀伊国屋のサイトで確認できます。
また、第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部構成になっています。
本書で挙げられているパターンの様子については、オブラブのサイトでコンパクトにまとめられているので雰囲気を掴めるかも知れません。
リンクしておきます。
お気に入りポイントかいつまみ
抽象的で難解だが「なるほど」も(かなり)多い
本書はボリュームもそこそこありつつ、「組織」とか「コミュニケーション」「計画」といった抽象的なテーマを扱っています。
その上、「パターンで記述する」というのは、馴染みの薄い人にとっては取っ付きさもあるのではないでしょうか。
そのために、読みながら「自分はちゃんと理解できているのだろうか・・・」とモヤモヤとする場面も少なくなかったです。
まして、自分に経験の少ないところには想像力も働きにくく、例えば「受託開発」「何十人も開発者がいる組織」「厳密にウォーターフォール方式でを用いた開発」「アナリストやテスターと言った役割と責務の分担」などなど、自分は身を持って経験をしたことがありません。そのため、それがすべてのパターンを読解する時に関係するものではないのですが、扱っている前提がピンとこない・・・というハードルがあります。
ただし、目指しているものは共感できていると感じます。
「ちゃんと働きやすい組織を作って、プロジェクトがいい感じに進むようにしようぜ！」という。そのために「厄介な課題」を特定して「こういう時どうしよう」を記述したパターン集であり、「それをクリアしたら次に・・・」とか「そこまでいったらコレもできるはず」といった、パターン同士の連なりが描かれている本です。
ということで、自分としては「変にハードルを上げすぎないで気楽に読む、それだけでも十分に学ぶものが多い！」と肩の力を抜きながら読んでいました。
(往々にして、歴史の淘汰を超えて生き残っている本は、「然るべき時に自分が読んだら嘘みたいに分かりやすい」という性質を持つものが多いので。)
とりわけ、スクラムや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冊です。 目の前で発生しているコンテキストとそこに起因する課題の見抜き方、そこにどう対処するか・・・という引き出しが増えます。すなわち、識別できる・検知出来る問題のレパートリーが増え、それに対応するための解法も増えるということになります。
先述の通り、いきなりすべてを理解する・・・というのは困難かと思いますが、「気楽にパラパラとページをめくってみる」「何か困ったときやうまく行かない時にまた手にとって、ピンときそうなところだけ読み直してみる」くらいのカジュアルさが大事に思いました。
「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上でも見ることが出来ます。
組織パターンについて調べていて→「スクラムをパターンの観点から紐解いてみる」という試みを発見して(kawagutiさんのブログ)→ 「Scrum PLoP」なる活動を知り→本書にたどり着く、という流れで出会いました。
認定スクラムマスター研修で「スクラムと組織パターンは密接な関係がある」という旨のことを教わり、その組織パターンの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のデザインパターンにおいては、こうした「つながり」は重視されていませんが。)
これも非常に面白く興味深いな、と思った点でした。
いずれのランゲージも「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には入りそうです。
続きとしては、「時を超えた建設の道」「パターン・ランゲージ:創造的な未来をつくるための言語 (リアリティ・プラス)」といった本に学びを広げてみたいなーと思っています。積んでいます。
