天の月

ソフトウェア開発をしていく上での悩み, 考えたこと, 学びを書いてきます(たまに関係ない雑記も)

「スクラムマスターぶっちゃけトーク会 について聞いちゃうぞ」に参加してきた

distributed-agile-team.connpass.com

今週も分散アジャイルチームの会に参加してきたので、会の様子と感想を書いていこうと思います。

会の発端となったイベントのアーカイブ

www.youtube.com

会で印象的だったこと

以降では、上記Youtubeアーカイブを「ぶっちゃけ会」という名前で記載していきます。

ぶっちゃけ会のその後

ぶっちゃけ会としてしまうと、失言をさせようみたいなフォースが参加者で働きがちになってしまうので、「ぶっちゃけ」というのをタイトルにするのはやめようとなったそうですw

そのため、この会は最後のぶっちゃけがつくタイトルのイベントになってしまったようです。

受注前のスケジュール作り

受注前にスケジュールを作る際、まずは経験があってできるチームに見積してもらう(&スケジュールを作ってもらう)という話をぶっちゃけ会でされていたのですが、そこで話していた見積の実態についてぶっちゃけてくれました。

受注前に行う概算見積と実際の見積結果にどれくらいずれがあるのか、という部分をメインにお話してくれたのですが、新さんのチームでは大体1.5倍くらい(当初の見積もり±50%くらい)のずれに収まることが多いということでした。*1

受注前の見積では、エンジニアが見積しやすい単位でざっくりとPBLを洗い出したりTシャツ見積レベルで概算見積をして、後は着手してスプリントを実際に回す中でベロシティベースで見積をする戦略をとっているということですが、「開発前にもっとやるべきことがあったよね」という話になることがぶっちゃけ多いそうで、DAなどを参考にスプリント開始前に方向づけフェーズを設けるなどと言った工夫をされているということです。

スプリントゴール

ぶっちゃけ会ではスプリントゴールの設定が難しいという話が挙がっていましたが、この背景やより詳しい状況説明についてぶっちゃけてくれました。

発注側の顧客がPOになっていることが多いことや既存システムのリプレイスを担当する*2ことが多いという状況もあって、「ある程度固定化されたPBLを上から順にこなして欲しい」という話がPOからくる状況にぶっちゃけなりがちで、それ故にぶっちゃけ会で話していたような「GitのIssue(PBL) Aを終わらせる」といったゴールが生まれてしまうということでした。

スプリントの単位が一週間では短すぎる*3のではないか?という話がきょんさんからは出ていて、フラクタルスプリントはまさにスプリントの単位がビジネスが求めている単位と合っていない問題に対応した結果だということです。

PBLが全然変わらない状況はスクラムに向いていないという言説

既存システムのリプレイスなど、最初にある程度FIXされたPBLを上から順にやる状況に陥ったとして、それを理由にスクラムが向いていない状況だと話す人を見ることがあるけど、それはだいぶ曲解していないか?というお話をきょんさんがしてくれました。

スクラムをやっていないチームがいざスクラムをしようとなった際に、普段からスクラムで開発していないチームは全然うまくできないし、開発をしている以上様々な予期せぬ問題*4が出てくるので、スクラムのメリットは少なからず享受できるのではないか?そう考えると「最初にある程度FIXされたPBLを上から順にやる状況はスクラムに向いていない」という言説は曲解ではないか?というお話を聞いていきました。

スクラムをやめるタイミング

ぶっちゃけ会では、「スクラムが形骸化したらスクラムをやめるタイミング」という話を新さんはされていましたが、これは「スクラムをやめてもどうせ上手くいかないでしょ」という想いが根底にはあったということをぶっちゃけてくれました。

新さんとしては、形骸化しているタイミングは改善のチャンスだと捉えているということで、形骸化したときこそチームやプロダクトに向き合うようにしているということです。

お客さん選び

どういうお客さんと仕事したいか?というのを新さんはまだ言語化できていないという話を新さんがぶっちゃけてくれました。

全然変わる気もないし自分達に丸投げしてくるお客さんと、変わりたいんだけど自分達の力が足りずに変化が起きていないお客さんは一見すると同じに見えてしまうのが判断を難しくさせているということです。

スタートアップの変遷

キラキラした夢を持ったスタートアップが、徐々に平凡な企業になったりキャッシュを増やすための受託開発をしがちになってしまうという話をしていきました。

togetter.com

新さんの会社は勤続年数が長い優秀なエンジニアも多く、新さん自身も満足いくチャレンジができている一方で、「この会社に来て既に5年経っているけど、自分自身が歳を食ってチャレンジをやめていないか?」「自分自身が心から満足できるチャレンジをしているから今の環境を選んでいるのか?」というのを新さんは自問自答されているということです。

新さんの会社を転職していく方々も、スタートアップに転職するパターンが多いそうで、「もっとヒリヒリした環境で働きたい」というメッセージを言い残すという話もぶっちゃけてくださいました。

全体を通した感想

新さん節の熱い話が久しぶりに沢山聞けて、とっても楽しかったです。
常に自分自身に疑問を投げかけながら向き合い続ける新さんの姿は刺激的でしたし、チャレンジし続ける姿勢は素直に尊敬の念しかありませんでした。

また、生々しさがすごかったので記事での具体的な記載は省いちゃいましたが、後半にきょんさんが、具体的にこういう状況だったらどういう提案をどういう手順でするのか?というお話をしてくれたのもめちゃくちゃ勉強になりました。

*1:勿論、最初にした見積が当たることはない(=そもそもスコープが全然変わってくる)のは前提

*2:リニューアル前の機能は全て現状の踏襲を求められる

*3:ビジネス的に求めている機能の単位が1週間スプリントという単位と合っていない

*4:使用しているフレームワークのアップデートなど

(オンライン読書会) 精神と自然 生きた世界の認識論に参加してきた

educational-psychology.connpass.com

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

今回は、いよいよ最後の章(8章 それで?)と、本全体のふりかえりをしていきました。

オートポイエーシス

本書の中では、精神プロセスを論じる過程で「トートロジカルにしてエコロジカル」という単語が出てくるのですが、これはオートポイエーシスの考え方とも繋がっているのではないか?というお話が出ていました。(メカニズムがメカニズムを作ること、あるいは差異が差異を生むこと、という再帰構造が現れている点が一致している)

目的は全体を裁断した結果でしかない

部分を見た結果、何かしらの目的が生まれていることはあり得るけれども、あくまでもそれは全体から部分を裁断した結果生まれているものだよね、という話をしていきました。

人間の人生で言えば、生まれたという事実が起点となり、そこから再帰的に差異が生まれ続けた結果できたその時点での全体について後付けで目的を考えている、というのが一般的だよねというお話も出ていました。

たまに起こる破壊

システムがある程度頻繁にある程度こっぴどく破壊されることや人の死は、全体として見たときには好影響を及ぼすこともあるという話がされていました。
突然変異の話や、チームに起こる大きな変化という観点で共感できる話でしたし、このあたりはここ数年でよく言われている多様性が重要だという話と絡めて考えてみても面白いなあと感じました。

全体を通したふりかえり

順を追って緻密に理論や前提が積み重ねられてきた印象が強く、時間をかけて読んだからこそベイトソンの思考プロセスを追随することができたよね、という話をしていきました。(8ヶ月程度の期間をかけてやってきた読書会でしたが、これでもハイペースだったのではないか?という話も出ていました)

分類とプロセスの記述とを交互に行き来し、論理階型を積み上げていくという構造が、世の中の多くの事象を説明できる凄まじいものだったのではないかという話も挙がっていて、個人的には非常に共感しました。

全体を通した感想

せっかくなので、自分が本を読んで特に強く感じたことを感想として記載しておきます。

参加者の方からもありましたが、すぐに使える本では全くなかったけれど、今後数十年というスパンで考えると、めちゃくちゃ使える考え方が凝縮された本でした。
このタイミングで読むことができたのは本当によかったなあというのが素直な感想です。

部分にフォーカスしようとしがちで全体を見失いがち

部分と全体の話でベイトソンが警鐘を本書で鳴らしてくれたように、どうしても全体を見失いがちだったことに気がつきました。

自分自身を省みると、問題提起自体が誤ってしまっている*1ような状況って、結構あったなあと思いましたし、全体からフォーカスを外して部分に着目しすぎていたなあ...というのは本書を読む過程で強く感じました。

また、これに関連して、「なんでこの機能を作るんだっけ?」「我々はなんでここにいるんだっけ?」と言った投げかけの危うさも実感しました。*2

効果的な学習や発達のためには差異や関係性を見つけることが役に立つかもしれない

ベイトソンが本書で定義してくれていた、「差異を作り出す差異」の概念や再帰的なプロセスの積み上げを見て、主観的な差異を見つけて、その差異をもとに新たな差異を見つけて、その新たな差異がまた新たな差異を見つけて...というプロセスを踏むことが学習や熟達の過程になるという考え方を知りました。

この考え方が現時点で何かすぐに役立てられそうかというとそういう訳ではないのですが、学習の過程や熟達の過程の捉え方を新たに持てたことで、人材育成や教育だったり自身が新しいことを勉強する際にプロセスにより自覚的になることができたり、制御できる変数をこれまでよりも一つ増やせたのかな?と思いました。(半分願望も入っています笑)

ベイトソンの思考プロセス

前提を積み上げていくベイトソンの思考プロセスが、非常に参考になりました。

論理階型を飛び越してしまうことで誤った結論を出してしまうというのは、本書で幾度となく忠告されていましたが、自分自身がめちゃくちゃやりがちだったので、耳が痛かったです。

巷で言われている(?)抽象化/具体化とかロジカルシンキングみたいな話とは全然違う視点で論理のつながりを捉えられたのも、すごく面白かったです。

*1:「(再帰的に無限につながっているものに対して)その最終点はなんなの?」「何がポイントになるの?」といったような質問をするなどが一例

*2:全体からのフォーカスを弱めるという点以外にも、差異を主観的ではなく客観的なものとして定義しようとしまっているように見えるという面でも危険かも、とも思いました

大人のソフトウェアテスト雑談会 #121【花火】に参加してきた

ost-zatu.connpass.com

今週もテストの街葛飾に行ってきたので、会の様子と感想を書いていこうと思います。

ちむちむどんどん

ちむちむどんどんが、演劇として見るとなぜ辛いと感じるのか?という話をRyoさんを中心に聞いていきました。

何かしらの苦難があって、その苦難がきっかけで行動変容が起きて。。というストーリーが一般的なのに、周りからいくら刺激が与えられても主要人物に行動変容が起きず、ご都合主義的な話に見えてしまうのがなかなか見ていて辛いんだ、ということです。

RTA

note.com

www.youtube.com

RTAで、これまでにない入力方法やブレイクスルーが起きる瞬間に立ち会えるのはとても面白いという話をしていていきました。

RTAに限りませんが、何かしらの常識がぶち壊れる瞬間を観れるのは本当に楽しいです。

ゲーミフィケーションとインプロ

舞台装置*1がないインプロでは、強制的に相手とコミュニケーションを取る必要がなく、よりビジネスのコンテキストに近い*2はずなのになかなか広まっていかないのはなんでなんだろうか?という話を聞いていました。

※なお、Ryoさんは内海さんから最近インプロの知識を詰め込まれすぎており、その上での感想な模様ですw

ちいとぽ

Team Topologiesがなかなか自分には合わないという方のお話を聞いていきました。

書いてある内容はわかるんだけど、全然共感が出来ず、人間味があまりにも薄いのが気になっているということでした。

確かに良くも悪くもコンサルタントが書いたんだなあーという感想を自分も持ったので、結構共感できるお話でした。

ここから派生して、昔は10年に一度くらいしか翻訳本が出なかったスクラムやプロダクト系の本がばんばん出ているのはいい部分は勿論あるけど、誤解された知識があっという間に広まってしまったりするリスクもあるよね。。というお話もしていきました。

1983

とにかく明るいラジオが盛り上がっている1983年世代ですが、実は世間だと1983生まれはカオスな人たちが揃っているというお話を聞いていきました。(具体的な人物名の言及は避けておきます笑)

森さんをはじめ、arround 1983なのに呼ばれていない人たちがなぜ呼ばれないのかの推測や、呼ばれないことに対する悲しみを語っているのは面白かったですw

全体を通した感想

Tommyさんから大人の教育をあまり受けることができなかったのは唯一残念なところでしたが*3、今日はいつも以上に葛飾でしか話されないようなぶっ飛んだネタが多かったので楽しかったです。

まだまだ知らない世界があることがよくわかったので、精進していきたいと思います。

*1:演者が演技をしなくても伝えるようにすること

*2:ビジネスでは嫌いな相手ともコミュニケーションを取る必要がある

*3:Tommyさんはマイクネタをはじめ今日も沢山盛り上げてくれました

More Effective Agile チラ見会 -書評を書くぞ-に参加してきた

engineering-floor.connpass.com

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

毎回参加しているもののscrapBoxに記録を残しているチラ見会ということでブログを書いてこなかったのですが、今回は特別会&結構レアなイベントなのでブログに書いていきます。

会の概要

これまで読書会をしてきた内容を踏まえて、書評を書いてみようという会です。書評を載せる媒体は特に指定がなく、各々が投稿しやすい場所に投稿していきます。

会の様子

書評メモを書く

まずは30分弱時間をとって、書評のメモを個人個人で書いていきました。

本の内容をふりかえりながら書くことができて、これまでの総復習ができた気がしたのが、非常に楽しかったです。
また、本の内容を全体的にふりかかえって、どのような部分が自分は好きだったのか(逆にどのような部分は個人的に気になったのか)を言語化できたのもよかったです。

書評をみんなの前で読み上げる

参加者全員に向けて、上でそれぞれが書いた書評メモを読み上げていきました。

他の方の感想を聞くのは楽しかったですし、色々な視点での感想があったり、これまでの会で読んできた内容を思い出させてくれるような感想があって、学びが深い時間でした。

好きな媒体に感想を投稿する

各々が投稿したい媒体に感想を投稿していきました。

自身はAmazonに投稿したのですが、レビューが掲載されるまでには数日かかるということで、投稿されるのを気長に待ちたいと思います。

人生で初めての投稿だったのに加え、まだレビューが1件しか書かれていなかったこともあって、思ったよりドキドキしました笑

次のチラ見会で読む本を決める

次の読書会で読む候補の本を決めていきました。以下の本が挙がっていました。

  • Googleソフトウェアエンジニアリング
  • 実践ソフトウェアエンジニアリング
  • セキュアバイデザイン
  • エンジニアリングマネージャーのしごと
  • リーダーの作法
  • オブジェクトデザイン
  • Making Software
  • データ指向アプリケーションデザイン 

まだ最終決定ではありませんが、1〜2週間後にGoogleソフトウェアエンジニアリングを読むことになりそうです!

全体を通した感想

(ブログ記事としては書いていないものの)チラ見会は週に4回ペースでここ1年くらい参加していて、初めて一通り読み終えた本が出てきたのは感慨深かったです。

次回の読書会も楽しみです!

SMARTCAMP Tech Talk#2 開発効率を上げるためのエンジニアとデザイナーの共創に参加してきた

smartcamp.connpass.com

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

会の概要

以下、connpassのイベントページから引用です。

SMARTCAMP Tech Talkは、スマートキャンプ株式会社が主催するオンライン勉強会です。

本イベントでは、これまでスマートキャンプが取り組んできた開発効率を上げるためのエンジニアとデザイナーの共創をテーマにしたイベントです。

スマートキャンプではエンジニアとデザイナーは一緒に企画や開発を行います。 その中で認識をあわせ開発効率をあげる取り組みをご紹介できればと思っております。

下記のような課題がある方は是非お申し込みください!  エンジニアとデザイナー間でのコミュニケーションに課題がある方 エンジニアとデザイナーでやる企画・開発で課題がある方 (その他、デザイナーとのコミュニケーションや開発効率に興味あれば是非参加してください)

会で印象的だったこと

同期的コミュニケーションと非同期的コミュニケーションの使い分け

Zoom繋ぎっぱなしといった同期的コミュニケーションと、Slack上のやりとりやPRなどの非同期的コミュニケーションをどのように使い分けしているか?というお話を聞いていきました。

同期的コミュニケーションでは議論がしやすくなる上に感情がお互いに理解しやすくなるという利点がある一方で、メンバー全員が同じ時間を取る必要があるためコストが高い*1点はデメリットとなるため、これらのデメリットとメリットを天秤にかけて、どちらのコミュニケーションをとるかの判断材料にしているということです。

同期的コミュニケーションの取り方〜Gatherの活用〜

メンバーが困ったときに素早くフォローしたい場合(新人がチームに入りたてな部分)などは、同期的コミュニケーションを活用しているということで、ツールとしてはGatherを使用しているというお話がありました。

Gatherを使っているのは、話しかける側/話しかけられる側が一眼で分かるようにするためだということで、「溜まり場」や「集中スペース」を指定することができたり、誰と誰が話をしているのか?というのが非常に便利だったということです。
また、スペースを複数作ったことで、自然とコミュニケーションを取る際の人数が少なくなり*2、コミュニケーションの「密度」が上がったということです。(Zoom繋ぎっぱなしのときはどうしても全員が話せるような話題でコミュニケーションをとりがちだった)

一方で、サードパーティの機能が使えないためタイマーやbotの導入ができない点や、音声品質がDiscordなどと比較すると悪い点は、改善の余地があるということでした。

部屋の名前の付け方

「雑談部屋」や「1on1部屋」といったように明らかに何をするのか分かりやすい部屋に加えて、「会長室」などといった何をするのかがわからず偶発的な出会いや会話が生まれるような部屋を作ることで、メンバーのコミュニケーション方法が多彩になり、コミュニケーションコストが大きく改善*3されたということです。

相互理解しておくと協力関係を深めることがよりできた要素

POとDevのコミュニケーション改善をするために、コミュニケーションにおいてどのような要素が改善されると協力関係が改善されたかを説明してくれました。

色々な要素はあるものの、特に、

  • お互いの性格
  • 技術的興味
  • 仕事に対する価値観

の3要素は対話をすることで、コミュニケーションが改善傾向にあったということでした。

会全体を通した感想

コミュニケーションを改善させるために実際に行った施策の中から、特に効果が高かったものを小さい粒度で紹介してもらえた点が特によかったです。

Gatherの部屋作りの部分や実際のコミュニケーション例を紹介してくれたのも、面白かったです。

*1:相手の予定を調整する必要が出てくる

*2:目的に応じて部屋が分かれるので、雑談をする組とペアプロする組と...といった風に人が分かれる

*3:アンケート結果ベース

Markin' Quality 第10.5回:No RYO!!・1に参加してきた

markin-quality.connpass.com

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

会の概要

第10.5回目は、深夜ラジオのノリの「That's Done!!」回のアニバーサリー・スペシャル「No RYO!!」回です。ゲストはお迎えせず、運営メンバー3人で語ります。

夏らしく納涼祭を脳内でイメージしながら、これまでの歩みをふりかえってみたり、そこで学んだことや心に移りゆくよしなしごとをそこはかとなく喋ったり、主にMarkに投げられるまさかりを全部受け止めて血塗れになったりします。

いつも以上にDiscord・Twitter・おハガキで質問も受け付けます。要はフリーテーマです。なにげない日常が実は大事なんだよなぁ、とかみんなで思いを馳せましょう。せっかくだから浴衣でも着るか。  

会の様子

CSM研修

yoyaさんがCSM研修に9月から行かれるということで、その話を聞いていきました。(すでに体調を整えていらっしゃるそうです)

元々コロプラが運営していた宿泊所ということですが、現在は形を変えて復活しているそうです。

www.attractor.co.jp

一度行ったらもう帰って来れなさそうという感想も出ていました笑

prtimes.jp

その後納涼続きでMarkさんの夏の予定の話を聞いていたのですが、MarkさんはAgile testing daysに参加されるということで、今からそのお土産話を聞くのが楽しみです!

Agile testing daysで気になるセッション

holistic testingのワークショップQuality Coaching Masterclassテスト自動化に関する基本体系のお話など、Markさんから多数のセッションについて見どころを聞いていきました。

自身は参加できないのが残念ですが、日本で聞く話とは趣向が違う話も多く興味深かったですし、コーチングやインプロと品質が混じるセッションがあったりして、どのセッションもとても面白そうでした。

Markさんの車

www.mazda.co.jp

Markさんがつい最近購入したという車の話を聞いていきました。

Markさんはあるときから車を買ってみたいと思うようになり、そのために引っ越しもしたというお話をされていて、なんともめでたい話を聞いていきました。

Bug Bash

厳密にいうとBug Bushではない*1ものの、チームの連帯感を高めるために4週間連続で Bug Bushをされたというおおひらさんの話を聞いていきました。

4週間連続でBug Bushをしたという事実もすごいのですが、フィードバックをもらうための工夫を細かくされていたり、チームで連帯感を持つための工夫とかがされており、めちゃくちゃすごかったです。

また、まずはふりかえりをして、そこでスプリントレビューの準備会をしようという話になって、その後スクラムマスターが資料を作ったり準備をし始めて、チームが盛り上がって。。という風にどのようにこういった工夫が生まれるのか?という過程を聞くことができたのも面白かったです。

会全体を通した感想

今日は0.5単位の会ということもあってか(?)、なんとなく前半は葛飾らしさを感じる回でしたが、yoyaさんが上手に切り替えしてくれて、品質関連の話もたくさん聞けてよかったです。(葛飾のような感じでもそれはそれで楽しいのですが笑)

*1:体験型のスプリントレビューに近いようなイメージ

スクフェス大阪 #scrumosaka のプレゼンを同時視聴したり、アジャイル系の相談したりに参加してきた

distributed-agile-team.connpass.com

今週も分散アジャイルチームの会に参加してきたので、会の様子と感想を書いていこうと思います。

誤解まみれのチューリング。コンピュータの父ってホント?【チューリング1】と、チューリングはコンピュータの父ではない。コンピュータ科学の父だ【チューリング2】の同時視聴をする

www.youtube.com

www.youtube.com

こちらを見ていきました。

ゆる言語学ラジオをやっているお二人が始めたラジオということでしたが、めちゃくちゃしっかりしたバックグランドの知識を基にゆるゆると話をしてくれて、タイトルの通りゆるくチューリングの話を聞くことができました。

専門的な用語のそばには全然コンピュータ科学と関係ないゆるいエピソードを盛り込んだり、自分自身をネタにして誰も傷つかない笑いを自然に取ったり、お二人が仲良く話している姿をたくさん見れたりと、色々楽しむ工夫がされていて楽しかったです。

アジャイルラジオ〜CEDEC2022でスクラム道関西メンバーたくさん出るよ!の巻〜の同時視聴をする

podcasts.google.com

久しぶりにアジャイルラジオの同時視聴をしていきました。

ゲーム業界の一端が聞けて楽しかったですし、ふりかえりやスプリントレビューに対する皆さんの想いが聞けたのも、すごくよかったです。

自身が人生で一番最初に聞いたPodcastアジャイルラジオだったので、アジャイルラジオを聴くときはなぜかいつも感慨深い感じになっているのですが笑、今回も楽しかったです。

CEDECでの登壇、応援しています!

プロダクトオーナー大変説の同時視聴をする

podcasts.google.com

おそらく分散アジャイルチームでは初?のfuroshiki.fmを同時視聴していきました。

ドメインエキスパートという単語は割と使いがちなのですが、改めて考えると、どういう人がドメインエキスパートで、プロダクトにどのような価値をもたらしているのか?というのは色々な意見があって面白いなあと思って聞いていました。

森さんが、「この仕事10年やっています。でも部署の売上は停滞してます。」という状態の人は知識を持っているかもしれないけど、その人のドメイン知識には価値があるの?という話を途中でしてくれたのですが、これが個人的にはめちゃくちゃわかるし、刺さるなあと感じました。(同時視聴のありがたみを実感しました)

ep.25 役割に応じたふるまいのちがいを同時視聴していく

podcasts.google.com

続いて、同じくfuroshiki.fmの最新エピソードを聞いていきました。

アジャイルコーチとスクラムマスターの話やマネジメントの話、上司がいない組織の話など、盛りだくさんでしたでどれも面白かったです。
特に、ばやしさんやひろみつさんがアジャイルコーチ的な振る舞いをして自分自身に違和感を感じて、一度現場を挟んだりとアジャイルコーチから離れたというお話をしてくれていたのは、特に面白かったです。

長編エピソード(60分)でしたが、時間を追うごとに話が徐々に盛り上がっていく感覚があり、非常に面白かったです。

全体を通した感想

今日は久々にPodcastを同時視聴していたのですが、参加者の方々からボロボロと新しい視点が出てきて、やはり分散アジャイルチームの会は面白いなあと思いながら聞いていました。

なぜか外から(チャットだけ)参加している人たちがいて、最後は交わってくるという構図も面白かったですw