参加してきました。2回連続2回めです。
ここでは備忘録がてら、思ったことを要約しつつつらつらと順不同に並べていきます。
ちなみに、3月にあった前回のときの記事はこちら。
- 全体の感想
- 秋のハジケ祭り
- discoveryとdeliveryを一緒にやるスクラム
- 相対見積り
- スクラム版ウミガメのスープ
- アジル・コンペティション
- DDDの話と型の話とDaniel Jackson
- 『誰も教えてくれなかったアジャイル開発』
- 最後に
全体の感想
濃かった。濃い人たちとひたすら濃い話をした。
3月にあった初参加のときは、全てが目新しく、ひたすら楽しいという感覚だったが、今回は2回めでもあり、すでに顔なじみとなった方々も増え、慣れたのもあるんだろうけど、それゆえ余計に色んな人と遠慮なしに色んな話ができた。
あと、直前までやってたCSP-SM研修でひたすら議論しまくってた（この話もそのうちブログに書きたい）のとか、最近は自覚的には7割くらい研究者で、1人でいるときずっと思索してることが多いので、そういうのも影響したのかもしれない。
秋のハジケ祭り
参加者で共有しているSlack Workspaceでの自己紹介で、きょんさんが意気込みとして「秋のハジケ祭り」と書いていたことが初日開始前の一番の話題だったが、3日間通してみると、一番ハジケリストだったのは川口さんだった。
discoveryとdeliveryを一緒にやるスクラム
自分がOSTのテーマに入れたやつ1個め。
discoveryとdelivery、それぞれ別にスクラムをやるのはできると思うが、一緒にやってしまうとだいたいわやくちゃになるチームが多い気がしたので、どうしたら上手くやれるのか、皆さんの意見を聞いてみた。
セッションでは主にryuzeeさんと川口さんの意見をもらえたし、最終日の昼食でたまたま対面に座っていた森雄哉さんにも話を聞くことができた。
ryuzeeさんが議論の末最終的に出した案が、Marty Cagan & Jeff Patton の Dual Track Scrum （Agile ではなく）とほぼ同じ形になったのは興味深かった。
森さんはGoogleの20%ルールを引用して、discovery : delivery = 20:80 で、稼働時間を分割して、1日のうち特定の1時間だけとか、特定の曜日だけdiscoveryをやる、という案を出してくれた。割合が50:50 だと「おそらく負ける」という発言が印象的だった。
あと、たまたま2日目の夕方に「アジャイルが使える／使えない場面」みたいのを話してるセッションで、「ディスカバリー：not スクラム」みたいなのがあったので、いやスクラムできるでしょ、みたいな話から、単に問題の複雑さが違うだけで扱うことはできるという話をクネビンフレームワークを使って話した。
川口さんはセッションで「discoveryとdeliveryをいちいち分けていない」と発言されていたが、実際のところ問題はdiscoveryとdeliveryの違いではなく、問題の複雑さの違いなのだろう。スプリントゴールがまともに立てられてベロシティが安定するようなのは問題があまり複雑でないときで、問題があまりに複雑になるとそのへんのよくあるプラクティスは、そのままでは役に立たなくなる。だからそういうときは何かしら工夫しないといけない。でもそれはスクラムというフレームワークの枠内で十分可能だろうと思う。
相対見積り
見積もりで思い出したが、最近Kiroさんが「最近のCSM研修ではTシャツサイズすらも教えなくなった」とのことで、今教えている見積りのやり方を教えてもらった。恐ろしくシンプルで、非常に面白かった。
即効性が高そうだったので、自分も試してみたい。
スクラム版ウミガメのスープ
OSTに出したテーマ2つめ。1日目の夕方にやった。
水平指向パズルとも呼ばれる「ウミガメのスープ」のスクラム版を作ろう、というテーマでセッションを企画してみたが、僕が用意してきた例題があまりに良問で（？） ほとんどその問題を解くだけで皆力尽き、そのセッションは最終的に、参考に持ってきた同種のボードゲームをただ遊ぶ会になってしまった。
合間に他の人にも出してみたが、ぱっと正解に近づく人もいたものの、全体的にかなり歯ごたえがあったようだ。
こちらに問題を書き出しておく。あまりに難しそうだったので2日目以降は問題を易しめに改変したが、こちらは一番最初の難しいままのやつ。
スクラムマスターのAさんは、まだスクラム未経験のチームにスクラムを導入し、苦労はしたもののなんとか軌道に乗せることができた。
皆よく成長したな、とほっと胸をなでおろしていたある日、マネージャーからショッキングな一言を言われてしまった。
で、2日目の午前中にaki.mさんと立ち話になり、セッションでやるより、色んなセッションで聞ける誰かの体験談を問題形式にアレンジしていく方が早いのかも、という話になった。
その流れで新しい問題が1問増えた。
あと、流れで1日めの夕食にきょんさんが出してくれた「ノンフィクション版ウミガメのスープ」も悩んだ挙句正解できたのは結構嬉しかった。
アジル・コンペティション
1日目が終わって部屋に戻ったとき、前に森さんに教えてもらって買った「アジル・コンペティション」本をたまたま持ってきていたのに気づいた。
前回の記事で触れた、2001年のアジャイル宣言で「Agile」という単語が採用されたきっかけとなった Agile Competitors and Virtual Organizations: Strategies for Enriching the Customer の翻訳である。
というので、深夜にSlackに書いて、翌朝からダイニングテーブルのところにずっと置いといた。結果として、参加者のそれなりの人が中古本をAmazonでポチったようだ。
DDDの話と型の話とDaniel Jackson
2日目の夜、aki.mさんがKiroさんにDDDとドメインモデリングを教えてもらっており、同席させてもらった。
自分はDDDを何度勉強しようとしても「やたら小難しくてようわからん」となっていたタイプだったのだが、お陰さまでかなりわかった気になれた（ダニング＝クルーガー効果）。
というかKiroさんが説明に使った図がかなり汎用的で、おそらくDDDに限らず、仮説検証（あるいは仮説演繹）一般に当てはまるモデルなのでは、という気がする。
以下は、その図を僕の頭の中で解釈した可換図式風の何か。
元の問題 に対し、ある側面からモデル化し（
）、仮想空間上で解決方法
を考え、実装してみて（
）、現実の空間で本当に元の問題が解決したのかを観察しチェックする（
）。解決していなければ、それを踏まえてもう1回やる。
追記：この記事公開後にKiroさんからコメントがあって、図の元ネタの1つは結城浩さんの『プログラマーの数学』に出てくる「ファンタジーの法則」とのこと。
それでめっちゃ腹落ちした。これ、数学的にはと
が随伴（共役）になってるって話だ。
てことは、と
がちゃんと随伴になるようにサポートする仕組みがDDDだったりするのかな。何の根拠もない妄想に近い話ですが。
でたまたま、そのとき覗いていたkappaさんが、なんかの拍子に「スタートアップのホントの立ち上げのところではTypeScriptの型がしんどい。動的な言語のほうが良い」ということを漏らしたので、まぁ一応立場的に反論、というのは大げさだけど、型を使いたがる人はこう考えるんですよ、という話を、まさに上の図を使いながらkappaさんにしてみた。
そうするとkappaさんの気持ちも議論の中で見えてきて、たぶんこういうことでは、というのが見えてきた。
- 型でやりたいのは上図でいう
を作る試行錯誤のところ
- その方が、後々変なバグに煩わされることがない
- スタートアップが動的な言語でやりたいのは、全体のイテレーションをとにかく早く回すところ
- 潜在的なバグが残るのはある程度良しとしている
結論としては、やっぱり図が万能すぎるというところで落ち着いた。
それはそれとして、自分はKiroさんがDDDの人だったとは不勉強ながら知らなかったのだけど、大まかな説明をした後具体的なドメインモデリングの実例をいくつかぱぱっとKiroさんがし始めて、最後に、いろんなドメインモデルを抽象化し始めて、なんというか、昔翻訳した『抽象によるソフトウェア設計』のことを猛烈に思い出していた。
「実際に使うためだけならここまで抽象化する必要はないんだけど、これくらいの抽象度にしておくとシンプルでバグが入りにくい」というKiroさんの話もほぼそのままだった。
なので、ずっとドメインモデリングの話を聞きつつ、7〜8割くらいDaniel Jacksonのことを思い出してて、最近彼がやろうとしていることも結局これなのか、と勝手に納得していたりした。
『誰も教えてくれなかったアジャイル開発』
2日目の夜にAckyさんからこの本の存在を教えてもらい、その場の勢いでKindleで買ってみた。それで翌朝、持ってきていたiPadで読みながら感想を言い合ったりしていた。
（買ってほしいとは思わないのでリンクは貼らない）
まぁ、確かに酷い本だとは思う。ただなんというか、アジャイル導入の際の課題感みたいなのは理解できるし、ちゃんとやろうとした跡も伺い知れるし、ばっさり切って捨てたいとか、そんな気にもならないでいる。
昔は正しいと思ってやったけど、今から振り返ると黒歴史にしてしまいたい……みたいなことって、アジャイルの界隈にいる人は誰しも1つくらい経験しているのではなかろうか。割とそれと似たような話かな、という気がする。
本を出版するまでいっちゃったのはすごいし、どうしてそうなった、というのは知っておきたいという気もするんだけど。
最後に
他にも色んな人と話したし、もっと細かいレベルで覚えていることはいっぱいあるんだけど、僕の能力では全て文書化しきれないのでここまでにしておきます。
こういう場を与えてくださった皆さま、色々話に付き合ってくださった参加者の皆さま、どうもありがとうございました。
