bonotakeの日記

ソフトウェア工学系研究者 → AIエンジニア → スクラムマスター・アジャイルコーチ

『嫌われる勇気』がとても面白かった話

結構前に人に勧められていたのだけど、たまたま昨日手にとって読み始めたら止まらなくなり、結局一晩夜通しで読んでしまった。

びっくりしたのが、語られていることが僕がここ数年で獲得してきた価値観とあまりに似ていたと言うか、所々は普段自分が考えていることとまったく同じだった。 その上で、自分に欠けていた部分を補ってくれるようでもあって、自分の中でモヤモヤしていた部分を言語化してキレイに整理してくれた。 本の中では難解だとかなかなか理解できない概念だとか書かれていたけど、まぁ僕が現時点で完全理解してるわけでもないだろうけど、ただ、違和感というものは自分はほとんど感じなかった。

いま自分はアジャイルコーチという、人や組織と常に向かい合う仕事をしているのだけど、まさにそんな立場の人間にはとてもハマるのではないだろうか。 実際、その仕事の上で色々悩んでいたところもあったのだけど、読み終わった後そういった悩みはすっかり消えてしまっていた。

アドラー心理学、面白いかもしれん。

Org Topologies を少し使ってみた

この記事は元々LinkedInに英語で書いた記事を、せっかくだから日本語に翻訳してちょっと手直ししたものです。先に英語で書いて、その後日本語にざっくり訳してるので何か日本語が微妙ですが許して。


最近、Org Topologies というフレームワークに興味を持っています。アジャイル組織の成熟度、ケイパビリティを評価するツールで、それを2軸のマップ上にある、16種類のアーキタイプにシンプルに可視化・分類することができます。

www.orgtopologies.com

その Org Topologiesを、最近支援に入っているログラス社内に紹介してみました。同社では、1つのプロダクトを複数の機能領域に分け、それぞれの領域を独立したスクラムチームが担当しています。各スクラムチームは、単独のチームとしての能力は高いのですが、チーム間の連携はそれほどしていない状態です。

そんなログラス社内で有志を集め、30分の短いセッションでOrg Topologiesの簡単な紹介をしたところ、参加者は皆さん強い興味を持ったようで、さっそく翌日、開発組織の全社員を集めて、現在の各チームの状態をマップ上にプロットする1時間のワークショップが開催されました。

短いワークショップでの自己評価でしたが、ほとんどのチームは(ほぼ想定通り)A1〜A2 に自分たちをプロットしていました。A1〜A2というのは、チームが単一機能か、もしくは複数のスキルから構成されている状態(いわゆるクロスファンクショナル)で、チームのスコープがフィーチャー単位になっている、というものです。

そして、主にAレベル(フィーチャー単位)からBレベル(プロダクト内のビジネスユニット単位)へ上げることについて議論が起こりました。一方それを観察していて、いくつか発見したことがあります:

  • 視点が組織全体のスコープになっておらず、チーム視点からの発言になってるなーと思うことがちらほらありました。例えば、何人かは自分のチームがBレベルに上がりたいと述べていましたが、そのためには他のチームとの強い合意と協働が必要であることにあまり気づいていないようでした。良くも悪くも、現在の各チームが開発組織内でかなり独立しているんだろう、と思います。
  • ほとんどの人はBレベルチームに何かしら利点があるということには同意していましたが、実際にBレベルや "team of teams" がどのようなものになるかは想像できていなかったように思えました。
  • Aレベルにとどまることもアリな選択肢だと言う人もいました。実際、彼らはチーム単位ではかなり最適化されていて、個々のチームは十分に生産的な状態であると僕も思います。彼らの中からはBレベルに上がるのはコストがかかるという発言もちらほらありました。

そこで僕は、チーム間のコラボレーションについて、たとえばPBIを2,3個交換してどうなるか見てみる、といった"小さなトライアル "をしてはどうか、と提案してみました。議論はまだ継続中です。さてどうなることやら。

RSGT2024に参加しましたの記

RSGT2024 記念の品

RSGT2024に参加してきました。 3日間のイベントですが、前日にスピーカーズディナーという関係者のみのプレイベントにも登壇者として参加でき、結果として4日間まるまる呑みっぱなし堪能しました。

ということで、感想をつらつらと書いていこうと思います。思ったよりも少し長くなりました。

参加前に意識していたことと、それが結果どうなったか

今回参加するにあたって僕が意識していたこと、目的にしていたことが3つありました。

  1. 登壇する
  2. 焼肉レトロを作ったチームで焼肉を食う
  3. Zuziと話す

それぞれ、どんなことが起きてどうなったか、ふりかえって見ようと思います。

登壇した

speakerdeck.com confengine.com

2023年、僕にとって人生の転機とも言える出会いがあり、その話をプロポーザルに書いたら有り難いことに採択され、登壇しました。
学術研究の紹介ということで結構マニアックな内容でもあり、沢山の人に刺さるものではなかろうと思いつつ、でも結果的に多くの人から賞賛の言葉を頂いて、とても嬉しかったです。 あと、「ゾンビスクラムサバイバルガイド」の翻訳者お3人が全員来られて最前列に陣取られて、嬉しいという気持ちとプレッシャーとを両方同時に感じながら講演していました。最後は「ゾンビスクラム〜」の献本&サイン会になっていて、ちょっと面白かったです。

今回、資料の作成にとても悩みました。話したいことが色々あってどうしても考えがまとまらなかったのが大きかったです。
本当はもう少し論文の内容を重点的に話すつもりで、後半の僕の今の研究の話なんかはオマケだったのですが、別途、論文著者の Christiaan Verwijs にビデオメッセージを頼んだらがっつり僕の研究の話をしたものを送ってくれたので、じゃあ自分の話もするしかないか、と、当初の予定よりかなり多めにポジショントークをすることになりました。

あともう1つは、この研究を紹介することの「副作用」が気になってきたからでした。

講演の中で述べたことですが、ForsgrenのFour KeysやSPACEフレームワークといった開発生産性の研究って、今回紹介した研究と結構近いことをやっているんです。
で、Four Keysの研究でForsgrenはすごいことをやってのけたんです。だって、一見outputを測っているだけのDevOpsの指標のうち4つが、outcomeを通り越してimpactと強い相関を持つ(持たせることができる)、ということを実証してしまったので。
研究としてはノーベル賞クラスの大発見だと思っています。

ところが、日本では去年辺りから妙な形でバズり、結果として、それらの意味も理解せずに闇雲に導入してデタラメに使う人と、それを見て「Four Keysなんて…」と批判する人とで溢れかえる状況になってしまいました。元の研究の価値がすっかり毀損されてしまった現状を見るにつけ、本当に残念だと思っています。
だから、自分がこの研究をRSGTなんて大きな場で紹介することで、彼らの成果も同じ運命を辿ってしまったら嫌だな、と。

というあたりで、そのあたりをどうフォローするか、かなり悩みました。発表直前ギリギリまで調整してて、似たような話題を扱っていた1日目のryuzeeさんの『ベロシティ Deep Dive』の資料を見ながら更に調整を入れたりしていました。
でもまぁ結果的には、用意していたスライドをほとんど削りました。話が全然違う方向に発散してしまいそうだったので。
(この辺については語りたいことが沢山あるので、いずれどこかで話のネタにします)

似たような話で、この研究が「唯一絶対の真理」みたいに取られてしまうのは嫌だな、という気持ちもありました。タイトルにtheory(理論)とかついてるし、科学っていう錦の御旗を掲げてしまうと、本来以上に普遍的なもの、と思われてしまいそうで。
本来ならもっとたくさんの科学研究がなされて、その中で切磋琢磨され研磨されていって初めて大きなファクトに到達する、というもので、この研究だけで完結するものでもないのです。

講演の中では、「理論」はあくまで1つのモデルである、といった説明をしましたが、次の日にKiroさんと立ち話をしていたら、不意に「PLoP(パターンコミュニティのカンファレンス)に来ない?」と誘っていただいたりして、言われてみればこれってパターンだな、と思ったりもしました。僕が紹介した論文では社会科学的な手法を使ってますが、そうじゃなくてアレグザンダー流のパターンランゲージを使うとパターンになるのかも。手法やそれが生まれてきた文脈が違うだけで、目的や位置づけは結構近いように思います。

話が少し横道にそれましたが、ともかくも、それなりに好評をもらえて良かったです。終わった後にもいろんな方と議論させてもらえて、今後の研究の糧になりそうなネタもいっぱいもらえました。
論文の著者にもフィードバックして、今年これからは本格的に研究がんばっていきます。

あ、あと、講演その他で今後の研究で行うアンケートに協力頂ける方を、当日参加してからの思いつきで募集し始めたんですが、思ったより多くの方に応募いただけました。とても感謝しております。

焼肉レトロを作ったメンバーで焼肉を食った

僕の2番めの目的は、「チーム焼肉」のメンバーとリアルで会って、焼肉を食うことでした。
チーム焼肉というのは、1日目にSatoshi Haradaさんが講演した「焼肉レトロスペクティブ」を考案した、あるA-CSM研修の中で結成されたチームです。

confengine.com

研修はオンラインだったのですが、いつかリアルに集まって焼肉を食べよう、と約束していたのでした。

そしたらメンバーの1人であるHaradaさんが、研修の中で生み出された「焼肉レトロスペクティブ」をネタにプロポーザルを出し、採択されてしまうという驚きの展開に。
しかも当日は、研修の講師だったZuzi Sochovaも来る、というので、「RSGTに来れるメンバーだけでもそこで再会して、焼肉を食いに行く」というのが僕の中でも目標になっていました。

1日目、無事にHaradaさんの講演を見届けた後、チームメンバーのうち何とか集まった4名+飛び入り2名の合計6名で、会場近くの焼肉屋に焼肉を食べに行きました。
残念なことにHaradaさんは講演で力尽きたようでそのまま帰宅されてしまったのですが、再会するのに一番大変かも、といっていた島根のメンバーも参加されて、本当に貴重な時間になりました。

焼肉のようす

Zuziと会って話した

上にも書きましたが、今回のRSGTにはZuziも来るとことに気づいて以来、Zuziにリアルで会って話すぞ、というのが僕の中のミッションとなりました。
というのも、僕がスクラムの道に真の意味で入ったのは、彼女の『SCRUMMASTER THE BOOK』を読んだのがきっかけだったからです。

僕は最初にスクラムマスターをやったチームで壁にぶち当たり、苦悩している最中に勧められて彼女の本を読んで、スクラムとは何か、スクラムマスターはどうあるべきか、ということを初めて理解できた、と思っています。

……という話を、1日目の会場で彼女を見かけて声をかけ、直接話しました。

このとき、「理解できた」の意味の英語として got to know とか understood じゃなく "found" という単語が口をついて出て、うわ変な英語になっちゃったと思いつつそのまま喋っちゃったのですが、今思い返してみると、僕自身の感覚の表現としては正しかったのかも。
いずれにせよ、Zuziがそれを聞いてとても喜んでくれて、それで僕もすごく嬉しかったのでした。

時間が前後しますが、その前にまず「あなたのクラスの『チーム焼肉』が研修中に作ったレトロスペクティブについて今日メンバーの一人が登壇する」と説明し、登壇者のHaradaさんのところに連れて行って引き合わせ、Haradaさんの緊張をぶちあげるなどしました。

サインをしてもらおうと思っていたのにその日は本を持ってこれなかったので、2日目に持ってきて彼女を探し、サインしてもらいました。(このへんはただのミーハーなファンと化している。)

3日目、トラブルがあって1時間くらい遅れて会場入りした僕は、OSTのサークルを見て回るうちに、やはりOST中のあるテーブルを覗き込んでいるZuziとすれ違いました。
そしたらそこで目があって、向こうから声をかけてくれて、そのまま2人で5分くらい立ち話で雑談をしていました。いやいや、何でこんな気楽にZuziと話せるんだ? すごいぞこの会場。すごいぞRSGT。

後から振り返ると、あんなに話せる時間があったならもっと彼女にスクラムやリーダーシップの話をしたかったなぁと思ったりもしたんですが、向こうからすれば、気楽な雑談混じりのほうが嬉しかったかもしれません。

全体の感想:カンファレンスからギャザリングへ

僕は前年が最初のRSGT参加で今年が2回めだったんですが、明らかに僕の中で位置づけが変わりました。

去年の僕は本当に一人ぼっちで、講演を一通り聞いた後は誰とも交わらず、すぐに家に直帰していました。
今年の僕は、会場には見知った「仲間」が本当に多数いて、そんな仲間たちと廊下での立ち話や終わった後の飲みの場でディープな話をするのが、各講演を聴講するよりもメインになっていた気がします。 まさに、去年は「カンファレンス」に参加した感覚でしたが、今年は文字通り「ギャザリング」になりました。

本当に楽しませてもらいましたし、この貴重な場を提供してくださってる方々に感謝しつつ、来年もぜひ参加したいです。できればまた登壇者として、今度は研究の成果を発表しに。

勉強会を開いてスクラムのCSP-SM資格を取得した話

これはスクラムマスター Advent Calendar 2023の12日目の記事です。

僕は11月にCSP-SM という資格を取りました。 CSP-SM というのは Certified Scrum Professional-ScrumMaster® の略で、Scrum Alliance が発行するスクラムマスターの資格の中では最上位のものになります。

で、自分はこのCSP-SMを取るために勉強会を開いて、色んな人に手伝ってもらいました。

bonoake-csp-sm.connpass.com

(あんまり告知せず細々とやってたつもりなのに、こないだ某スクラムコミュニティの集まりに行ったらみんなこの勉強会のことを知ってて結構恥ずかしかった)

こんなやり方でスクラムマスターの資格を取った人も珍しいと思うので、なぜこんなことをしたのか、何をやったかの体験記を書いていこうと思います。

目次:

勉強会を開くまで

CSP-SM研修を始める

自分がCSP-SMを取ろうかなとぼんやり考えたのは、確か今年の初めごろだったと思います。(理由はとりあえず割愛)
その頃って、国内でのCSP-SM研修はodd-eさんで前年に1回開催されたくらいで、第2回が開催されるかどうかも僕にはわからない状況でした。

それでネットを色々検索して、どうやったら日本でもCSP-SM研修が受けられるか探ってみたところ、このnoteがすごく印象に残りました。

note.com

自分のペースでやれるなら英語での研修もアリか、くらいに思っておりました。

で、実はこの頃まだA-CSMも取っていなかったのですが、A-CSMはアギレルゴさんでやってるZuzi Sochovaの研修を受けると決めていたので(彼女の本『SCRUMMASTER THE BOOK』のファンだったもので……)9月開催の予定が出たタイミングで早々と予約してしまい、それを待つ数ヶ月の間にCSP-SMをどこで受けるか探す、という感じの日々が始まりました。

上のnoteで紹介されていた講師の方はもう同様の、毎回1on1でメンタリングしてくれるスタイルでのCSP-SM研修を開催してなくて、Scrum Allianceのコース検索でも同じようなものは見つかりませんでした。

ただ、コースの種別選択に "Self-Paced" というのがあることに気づきました。
自己学習型、いわゆるe-ラーニングスタイルで、教材がテキストや動画で提供されて、基本的にはそれで自分で勉強していくスタイルのものでした。

それで本当に勉強になるのかあまりにも不安だったので、めちゃめちゃ悩んだ挙句、その検索で出てくるCSP-SM研修や講師の名前をひたすらぐぐって、評判を確認してみることにしました。

番役に立ったのはRedditで、数少ないながらも受講者の書き込みがちらほらありました。
ボロクソに叩かれてるコースもある一方で、比較的評判が良かったのが3back.comの研修でした。テキストが良くて、資格を取った後もよく参照してる、みたいなコメントが印象に残りました。

と言ってもRedditの匿名性の高い書き込みなんで、どこまで信用して良いかもわからず、最後まで悩んでいたのですが、結局ここに決めました。安かったし。
ということで、お金を振り込んでコースを開始したのはスクラムフェス三河の1日目が終わった日のホテルでした。ちなみにA-CSMを取得したのはその前日です。

勉強仲間を探すことに

で、早速教材にアクセスできるようになったんですが、いきなり大きな壁に直面することになりました。

Self-Paced な研修って、単に教材を提供するだけでなく、実際にちゃんと勉強したか確認するために色々な課題を出して、そのエビデンスを提出するものが結構あるようです。 教わったことを自分のチームで実際に適用してみて、その記録をログにして提出させるものとか。
で、僕が始めた 3back.com のものは 周囲の誰かと一緒に勉強し、一緒にディスカッションやグループワークをして、その結果をレポートにまとめて提出する というものだったのです。

ホームページにあるガイダンスにもやんわりと書いてあったのですが、その時点では理解できず、コースを初めて一番最初の詳しいインストラクションを読んで初めて気づきました。
完全に独学でできると思いこんでいたので、ホテルでインストラクションを読みながら呆然としたのを覚えています。

そういう周りに仲間のいないぼっち受講者のために勉強仲間探し用のフォーラムも併設されているのですが、1週間に1人くらいしか書き込みがなく、しかも自分の場合は時差があって(参加者の大半は米国在住ぽかった)そこで仲間を探すのは早々に断念しました。

勉強会を開くことに

とりあえず、近しいスクラム実践者の人たちに個人的に声をかけはしたものの、自分の研修に常に同じ人に参加してもらうのは無理がある、とも思いました。 僕の資格取得のための勉強に全部ボランティアで付き合うほどモチベーションが高い人ってそうそういないだろうと*1
また、受講期限は3ヶ月以内と決まっていて、逆算するとかなりハイペースでコースを消化していく必要があったので、勉強仲間の都合で先に進めなくなる、みたいな事態は避けたかった、というのもあります。

なので思案の末、connpassを立てて勉強会を開き、参加者を公募することにしました。

やってみた結果

そんな感じで、色々なギャンブル要素を乗り越えていった結果ですがめちゃめちゃ面白かったし、めちゃめちゃ勉強になりました。

そもそもまず、よくある数日間拘束の同期セッションでの研修に比べて、結果的にですがめちゃハードでした。やってみるまで逆だと思ってました。
週2回2時間の勉強会を開催して、その準備のために1時間予習して、終わった後も提出するレポート作成や次回告知のために30分〜1時間作業して……てのをやってて、まぁまぁしんどかったです。
最初は平日21時〜23時でやってたんですが、何回かやるうちに明らかにオーバーワーク気味になってきたので、週末の午前中開催に変更しました。

あとテキストですが、Redditの噂は本当で、すごく興味深いものでした。講師はDan Rawsthorneという方で、数学の博士号を持っているというだけあって、印象としてはかなり理論的で、特に大きな企業内でスクラムを展開する場合を想定した、かなり現実的な思考のフレームワークを提供するものでした。Zuziの本や研修では自分がどこか修行僧になったような気分になるのですが、それとは全く毛色が違うな、という印象でした。
日本のスクラムコミュニティではあまり聴かないような内容も多く、直前のA-CSM研修ともガラッと変わった内容で、とても新鮮で、刺激になりました。

で、何より参加者とのディスカッションが本当にためになりました。僕なんかよりずっと経歴の長い先輩方もちょこちょこ参加してくれて、あと教材がかなりディスカッション向きだったのもあり、毎回かなり議論が白熱しました。僕が課題を提出し終えてからも延々1,2時間議論していたこともありました。(いや、本当にありがたかったです。)

そういう意味では、やっている間いろんなことを考えさせられたし、結果、かなり自分の身になったと感じています。間違いなく受講料の元は取れたし、やった甲斐は間違いなくありました。

ライブセッション

ちなみに、全部e-ラーニングでの自己学習というわけではなく、コース修了までに4回、Zoomを使ったライブセッションに参加する義務がありました。(他のどの Self-Paced 研修にも4回のオンラインセッションは必ず入っている感じで、おそらくCSP-SM研修の要件として必須になっているんだと思います。)

自分は、色々な国の人たちが集まる国際カンファレンスに参加して、講演を聞いたりディスカッションをしたり、はできるくらいの英語力です。いわゆるESL*2として、同じESL、つまり母国語が別にある人と英語で話すならそこまで苦にはならない、くらい。
そんな自分ですが、3back.com のオンラインセッションは結構きつかったです。体感8割以上は米国からの参加者で、講師のDanもめちゃめちゃアメリカ人の、しかも早口でひたすらしゃべり倒す人で、彼の話やネイティブ同士のディスカッションを全部聞き取るのは結構ハードでした。
とはいえ、内容はすごく面白いものが多くて、あまりにもったいないので2回めからは文字起こしのアプリを持ち込んで、気になったところはそれで取ったログを終わった後で読み返す、みたいなことをしてました。

あと、10分くらい参加者同士2〜3名でフリーディスカッションをする時間があったんですが、それはまぁ、それなりに何とかなりました。(相手が合わせてくれたとも言える。)
米国の、結構な大企業の中でスクラムマスターやってる、みたいな人が多くて、僕は日本人、というのもありますが、フリーランスアジャイルコーチという身分が結構珍しがられた感じでした。

おわりに

ということで、まとめると、やってみて本当に良かったです。
めちゃくちゃ勉強したし、めちゃめちゃ面白かったし、めちゃくちゃ勉強になりました。
かなり自分の血肉になったと感じています。

そんなわけで、僕と同じような自己学習型の研修を同じ人に勧めたいという気持ちもありつつ、やっぱり英語力が壁かなぁと思いました。
e-ラーニングの教材は、今どきは翻訳サイトもあったりして割とどうとでもなる気がしますが、やっぱライブセッションをこなすには、英語はできたほうが良いです。どの程度あったほうがいいか、まではわからないですが、やっぱり講師の話やディスカッションを直接聞き、あわよくば参加できる機会はとても貴重で、英語ができないともったいない、と思います。
3back.com は米国人8割な感じだったのですが、他のところだと(あくまで売り文句をそのまま受け売りすると)世界中から参加者が集まるようなのもあるようで、そちらはそちらで狙い目かもしれません。

あと、僕は勉強会で「僕の資格取得にボランティアでつきあってくれる人」を募集してやりましたが、たぶん理想は、一緒にCSP-SMを取る仲間を集めて、その人たちと一緒に申し込んで、一緒に勉強していく方法なんだろうなと思います。(ちなみに 3back.com は5名以上のグループでの参加申込だと受講料のディスカウントがあるっぽいです。)

というわけで、本当に貴重な体験をすることができました。
最後に、僕の勉強会に付き合って、僕といっしょに勉強してくださった皆様、本当に本当にありがとうございました。

*1:実は結果的には、最初の回から最終回まで皆勤だった人もいました。その方と2人だけの回もあって、本当にありがたかったです。

*2:English as a Second Language、2つめの言語として英語を話す人のこと。

アジャイルコーチとスクラムマスターの集い(2023年11月)に参加してきました

www.attractor.co.jp

参加してきました。2回連続2回めです。
ここでは備忘録がてら、思ったことを要約しつつつらつらと順不同に並べていきます。

ちなみに、3月にあった前回のときの記事はこちら

全体の感想

濃かった。濃い人たちとひたすら濃い話をした。

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に限らず、仮説検証(あるいは仮説演繹)一般に当てはまるモデルなのでは、という気がする。
以下は、その図を僕の頭の中で解釈した可換図式風の何か。

元の問題 X に対し、ある側面からモデル化し( model(X))、仮想空間上で解決方法fを考え、実装してみて(impl)、現実の空間で本当に元の問題が解決したのかを観察しチェックする(solved?)。解決していなければ、それを踏まえてもう1回やる。


追記:この記事公開後にKiroさんからコメントがあって、図の元ネタの1つは結城浩さんの『プログラマーの数学』に出てくる「ファンタジーの法則」とのこと。
それでめっちゃ腹落ちした。これ、数学的にはmodelimplが随伴(共役)になってるって話だ。

mm.hyuki.net

てことは、modelimplがちゃんと随伴になるようにサポートする仕組みがDDDだったりするのかな。何の根拠もない妄想に近い話ですが。


でたまたま、そのとき覗いていたkappaさんが、なんかの拍子に「スタートアップのホントの立ち上げのところではTypeScriptの型がしんどい。動的な言語のほうが良い」ということを漏らしたので、まぁ一応立場的に反論、というのは大げさだけど、型を使いたがる人はこう考えるんですよ、という話を、まさに上の図を使いながらkappaさんにしてみた。
そうするとkappaさんの気持ちも議論の中で見えてきて、たぶんこういうことでは、というのが見えてきた。

  • 型でやりたいのは上図でいうf を作る試行錯誤のところ
    • その方が、後々変なバグに煩わされることがない
  • スタートアップが動的な言語でやりたいのは、全体のイテレーションをとにかく早く回すところ
    • 潜在的なバグが残るのはある程度良しとしている

結論としては、やっぱり図が万能すぎるというところで落ち着いた。

それはそれとして、自分はKiroさんがDDDの人だったとは不勉強ながら知らなかったのだけど、大まかな説明をした後具体的なドメインモデリングの実例をいくつかぱぱっとKiroさんがし始めて、最後に、いろんなドメインモデルを抽象化し始めて、なんというか、昔翻訳した『抽象によるソフトウェア設計』のことを猛烈に思い出していた。
「実際に使うためだけならここまで抽象化する必要はないんだけど、これくらいの抽象度にしておくとシンプルでバグが入りにくい」というKiroさんの話もほぼそのままだった。

なので、ずっとドメインモデリングの話を聞きつつ、7〜8割くらいDaniel Jacksonのことを思い出してて、最近彼がやろうとしていることも結局これなのか、と勝手に納得していたりした。

『誰も教えてくれなかったアジャイル開発』

2日目の夜にAckyさんからこの本の存在を教えてもらい、その場の勢いでKindleで買ってみた。それで翌朝、持ってきていたiPadで読みながら感想を言い合ったりしていた。
(買ってほしいとは思わないのでリンクは貼らない)

まぁ、確かに酷い本だとは思う。ただなんというか、アジャイル導入の際の課題感みたいなのは理解できるし、ちゃんとやろうとした跡も伺い知れるし、ばっさり切って捨てたいとか、そんな気にもならないでいる。
昔は正しいと思ってやったけど、今から振り返ると黒歴史にしてしまいたい……みたいなことって、アジャイルの界隈にいる人は誰しも1つくらい経験しているのではなかろうか。割とそれと似たような話かな、という気がする。
本を出版するまでいっちゃったのはすごいし、どうしてそうなった、というのは知っておきたいという気もするんだけど。

最後に

他にも色んな人と話したし、もっと細かいレベルで覚えていることはいっぱいあるんだけど、僕の能力では全て文書化しきれないのでここまでにしておきます。
こういう場を与えてくださった皆さま、色々話に付き合ってくださった参加者の皆さま、どうもありがとうございました。

「アジャイルソフトウェア開発という概念」の源流は日本なのか 〜『日本企業はなぜ「強み」を捨てるのか 』を読んで〜

夜中におもむろに書評を書き出す第2段。

この本自体はとても面白いし首肯できる部分も多いが、1箇所だけイチャモンをつけたい。

そもそもアジャイルソフトウェア開発という概念自体、マニフェスト(注:アジャイルソフトウェア開発宣言のこと)の発表よりも3年早く、1998年に日本の研究者から提案されている。
南山大学の青山幹雄教授による一連の研究である。 (同書より引用)

ここで紹介されている「1998年」の「提案」とは、おそらくICSE1998で青山先生が発表した論文 "Agile Software Process and Its Experience" のことだろうと思う。Agile Software Process(ASP)という、実際に富士通の社内で実践されたソフトウェア開発方法論を論文としてまとめたものだ。
で、たまたま私はこの論文をつい最近目を通したのだが、最初に断言すると、これは2023年現在アジャイルと呼ばれているものとは異なる手法である。
ASPが「アジャイルソフトウェア開発という概念」を世界でいち早く提唱した、と書くと否定しきれない部分もある。 ただ、ASPが源流となって今主流になっているアジャイル開発の手法が生まれたのか、ASPが今のアジャイルの先を行っていたのか、と言われると、それは当たらない、と言えるだろう。
ということで、紛らわしい表現は正しておきたい、と思ったのがこの記事の趣旨である。

以降はそのことについて、もう少し詳細に書いていきたい*1

前提:アジャイル以前

まず前提として、アジャイルが生まれる以前のソフトウェア開発モデルの歴史に軽く触れる。

元々、1970年のRoyceの論文が起源となってウォーターフォール型の開発モデルが起こり、世界的に普及した。
しかし、最初に全てを計画し、開発期間ずっとその計画のとおりに開発する、というスタイルには問題も多く、特に1990年前後からその見直しを図るような動きが出始めた。そのうち有名なのが1986年のBoehmによるスパイラル開発、その後の1990年代のBoochに代表される反復型開発である。

これらの流れの後に現代のアジャイルも青山先生のASPも存在する。実際、青山先生の論文ではBoehmやBoochを参照している。

現在アジャイルと呼ばれるもの vs ASP

Boochらの反復型開発の時点で既に、短いイテレーションを回しながら作りたいソフトウェアを部分的に少しずつ作って拡張していく、という思想は出来上がっていた。
ではアジャイルとは何なのか、といえば、誤解を恐れずに言えば、反復型開発を前提として顧客からのフィードバックを受けて自らが学習し、開発を軌道修正していくのが一番の特徴であり、それが方法論の中に組み込まれている。

そして、青山先生のASPにはこの特徴はない。論文では、ASPを実践してみて得られた恩恵の1つに "Higher quality by earlier feedback from the customers"(顧客から早い段階でフィードバックを得ることでの品質の高さ)を挙げている(7.1節)だけで、それを意図的にプロセスに組み込むといったことはしていない。

ASPアジャイルではないのか

では、ASPは全く「アジャイル」ではないのか、というと、必ずしもそうは言い切れない。 論文の中では

Agility means quick adaptations to changes in requirements and surrounding environments.
アジャイルとは要求や周囲の環境の変化に素早く適応することである)

と書かれていて(2節)、これは今のアジャイル開発が志向するものと同じだ。

つまり、ASPはアプローチが異なるだけで、「アジャイル」を志向しているという意味では現在のアジャイルと同じである。

アジャイル」という概念の起源はどこなのか

では、この「アジャイル」という考え方はどこから来たのか。青山先生の論文では現在のアジャイルと呼ばれる方法論は一切参照していない(たとえばスクラムの論文は1995年に出ているが、青山論文では参照されていないし、実際参考にもしていない)し、逆に現在アジャイルと呼ばれる数々の方法論もASPを参照した形跡は見えない。

つまり、両者の「アジャイル」の概念には、実は共通する先祖がいるのである。

青山先生の論文では、アジャイルの概念について以下の "Agile Competitors and Virtual Organizations: Strategies for Enriching the Customer" という本を参照していた。自分は読んでいないが、半導体生産にまつわる経営手法の本らしい。

で、どうやらこの本がアジャイル開発宣言にも影響したらしい。Harbard Business Reviewの記事 "The Secret History of Agile Innovation"によると、

Although they disagreed on much, the group eventually settled on a new name for the movement: agile. The word was suggested by one attendee who had been reading the book Agile Competitors and Virtual Organizations: Strategies for Enriching the Customer.
(多くの点で意見が分かれたが、最終的にグループは、このムーブメントの新しい名称を「アジャイル」に決定した。この言葉は、"Agile Competitors and Virtual Organizations: Strategies for Enriching the Customer" という本を読んでいた参加者の一人が提案した。)

と書かれている。この記事の著者にはこの会議の参加者でスクラムの提唱者の1人でもあるJeff Sutherland もいるので、信憑性は十分あるだろう。

ということで、おそらく当時の様々な世界的潮流のなかで、青山先生も、現在アジャイルと言われる数々の方法論の提唱者も、同じ「アジャイル」という概念に着目したのだろう。
そして、その「アジャイル」の概念をソフトウェア開発方法論の名前に使用した、という点では、青山先生がアジャイル宣言より3年ほど早かった。しかし、だからといって青山先生のASPが今のアジャイルの源流になっているわけでもないし、今のアジャイルの特徴をASPが先取りしていたわけでもない。ASPが他より「早い」と言えるのは、「アジャイル」という概念とその名称を使用したことだけだ。

ASPのアプローチ

ここからは少し余談になるが、ではASPはどういった特徴を持つ方法論なのか。
それは、複数の少人数チームからなる分散開発をベースにした反復型開発であり、特に初期は並列開発によるリードタイムの短縮を企図していたようだ。マルチコアのプロセッサでプログラムの実行速度を上げる、といったのとベースの発想はほとんど同じだ。
つまりASPでは、ソフトウェア開発を分散並列型にすることで「アジャイル」を達成しようとしていたようだ。

実はこの話、ちょっと面白いなと思うところがある。

最近、Joe JusticeがTeslaやSpaceXで展開しているxM(eXtreme Manufacturing)というのが、既存のアジャイル(特にスクラム)をベースに、徹底的な分散並列開発を志向してリードタイムを極限まで縮めるような開発方法論なのだ。

youtu.be

youtu.be

ついでにいうと、xMのキモは徹底したモジュール化なのだが、青山先生はASPの論文を発表した後、まさにソフトウェアを独立性の高い「コンポーネント」の集合体として捉え、それらコンポーネントの組み立てだけでソフトウェアを開発する「コンポーネントウェア」の研究に邁進されている。

そう考えると、青山先生は非常に感度が高く、先進的な研究をされていたんだな、ということが伺える。「アジャイルの起源」と「勘違い」されそうになるのも、仕方ないのかも知れない。

*1:ちなみに、私は学生時代から青山先生には様々な面でお世話になった。そのへんは先生が逝去されたときに書いたが、いずれにせよ、そういう人間がこの記事を書いている、ということは付記しておく。

『質的研究を科学する 』を読んだという話

夜中の変な時間に目が覚めてしまったので、以前読んだ本の感想をおもむろに書き出そうとしてみる。2ヶ月くらい前に読んだやつだけど。

自分は今初めて質的研究というのをやろうとしていて、何かと言うとインタビューや自身の観察から得たログみたいなものを分析して何かしらの科学的な知見を得ようとする手法のこと。社会科学の世界でよく使われる。
ただ、自分は今まで自然科学な世界で研究することがほとんどで、こうした定性的データを自分の主観に基づいて分析したところで何かしら一般性のある客観的な知見が得られるのか、それは本当に科学なのか……という思いが最初は強かった。

そんな折にこの本に出会って、かなり腹落ちした。
この世に唯一絶対の真実があるかどうかはわからないが、自身の心のうちに起きる「現象」を十分説明できる「記述」を見つけることが科学である、という(構造構成主義的?)立場は自分の、特に数学で養われた感覚とすごくマッチしていた。
おかげでこの本を読了した後はそういった客観性の意識に悩まされることがなくなった。

こういった科学哲学的な本を好む人が自分の近傍にどれだけいるかわからないけど、自分の中ではとてもためになった、ということで紹介しておく。

注:bonotakeは、amazon.co.jpを宣伝しリンクすることによってサイトが紹介料を獲得できる手段を提供することを目的に設定されたアフィリエイト宣伝プログラムである、 Amazonアソシエイト・プログラムの参加者です。