天の月

ソフトウェア開発をしていく上での悩み, 考えたこと, 学びを書いてきます

#RSGT2022 プレゼン動画を同時試聴する会+OSTに参加してきた

beyond-hardware-agile.connpass.com

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

スクラムチームとアジャイル開発ガイドラインを見る

まずは佐野さんの発表から見ていきました。
大企業でアジャイルスクラムをやるというのが如何に大変かというのが分かりつつ、その中でも大企業ならではのコンテキストに何とか合わせようとしているのが見えたのが非常に印象的でした。

https://confengine.com/conferences/regional-scrum-gathering-tokyo-2022/proposal/16126

QAなんなん?~みんなが納得できるQAのスタイルを見つけよう~を見る

https://confengine.com/conferences/regional-scrum-gathering-tokyo-2022/proposal/15963/qaqa

続いて、SigSQAの皆さんのセッションを見ていきました。
QAスタイルファインダーはチーム内での会話を促進するツールとして有用だなあというのと、実際にチーム内でQAスタイルファインダーを運用してどのような会話をしたのかというのが分かって良かったです。

一方で、後のQ&Aセッションでも一部は出ていましたが、スタイルを定義して足りない時にどうするのかというお話や点数やそれぞれの価値観の定義をもう少し詳しく聴いてみたいな、という気持ちになりました。

F1 お茶の水グランプリ'22を見る

https://confengine.com/conferences/regional-scrum-gathering-tokyo-2022/proposal/16147/f1-22

最後にふさわしい(??)F1グランプリを見ていきました。
同時視聴していた参加者も登壇者と一緒にわいわいできて*1、めちゃくちゃ楽しめるセッションでした。
そして、おとっしーさんの状況がとても気になるセッションでした。。
みほらぶさんの実況の上手さを初めて見て、皆がみほらぶさんがすごいって言う所以はこれか...というのを実感しました。

全体を通した感想

本編後の本編含めて、一緒に同時視聴した参加者のメンバーから自分にはない視点で沢山の感想が聴けたので、楽しかったです。
RSGTはコンテンツが充実しているので、同時視聴をしながらの会話も盛り上がりますし、自分自身がやるプレゼンにも大きく繋がる部分や学びが多くがあって、最高でした。

*1:今回はきょんさんや森さんも一緒にフィードバック(?)をしてくれていました

「心理学の学術書・専門書 相互紹介イベント(ビブリオバトル) 2022年1月」に参加してきた

educational-psychology.connpass.com

他のイベントが被っていて会に申し込めていなかったのですが、こちらに飛び込みで参加したので(更に勝手に本を紹介してきたのでw)紹介されていた本をまとめていこうと思います。

紹介されていた本

最近学習科学の勉強をしているということもあって、学習科学の本を読みたく紹介させてもらいました。(教育心理学概論→学習科学ハンドブックの流れで今の所来ています)
3部構成になっているのですが、1部は教師のコンテキストから教えることについて、2部は学びの構造について、3部は自分自身について...という流れで構成されているため、教師ではない人は2部から読んでみてもいいかもしれないです。

こちらも自分から、自己調整学習に興味を持っているということで挙げさせてもらいました。
目標に向かって努力をするために行うダイナミックなプロセスとされている自己調整学習で日々のチームビルディングやソフトウェア開発にも応用できると思っているのですが、人に対して教える役割(教師...)のコンテキストで書かれていることが多いので、ソフトウェア開発の現場とのコンテキストの溝を読書会で埋めたいと思い、選びました。

白い森さんがおすすめしていたが絶版だったという本が最近復活したようです。
文化人類学の文脈では必読書とされているような本らしく、人間の認識についての概念を整理できる本だということです。
中々大変な本ということで、読書会向きの本だなあという印象がありました。

子育てをする中でおすすめされた本ということです。
非認知って何?結局非認知って認知じゃないんだろうか?と、紹介された小笠原さんは疑問があるようなのですが、読んだうえでこの疑問を晴らしたい*1そうで、紹介がなされていました。

学生の参加者から、「就活でバーンアウトする人たちが多いと聞いて読んでみたくなった(バーンアウトになった人達の支援をしたいと思った)」という話があり、紹介されていました。
燃えつきについて真剣に考えたことがなかったので、是非読んでみたいと思いました。

言語の持つ力を実感しつつあったさていさんが、言語心理学に入門してみたいという想いから挙げられていた本です。
Amazonレビュー等書籍のレビュー情報もないようで、読んで是非レビューを皆でしよう!と盛り上がっていました。

まさに「教科書」と呼べるような、1ページあたりの文字数がめちゃくちゃ多い専門書に近い本だそうです。
名前は聴いたことがあるような心理学関連の事象について、その事象の原点を知れるような本だということで、心理学の土台を固めるのにうってつけということです。

めちゃくちゃ自分好みな本の予感がしたので、1秒でぽちりました。

最後にのりっくさんから昨年読んだ中でベスト3に入るという本を紹介いただきました。
読むと、自分が人と違うんじゃないか?うつ病なんじゃないか?と思っている人の心が凄く楽になる本だそうで、のりっくさん劇推しだそうです。

結果

精神と自然を読むことになりました!

educational-psychology.connpass.com

会の感想

申し込みせずに乱入しましたが、ビブリオバトルで皆さんのプレゼンを聴けて、とても楽しかったです!

そして大分読み応えがありそうな本なので、今から読書会が楽しみです!

*1:強く反対できるようになりたいらしいです笑

JaSST nano vol.8に参加してきた

jasst-nano.connpass.com

今回もJaSST nanoに参加してきたので、会の様子と感想を書いていきます。

発表内容

テスコン(U-30クラス)審査委員ってどうなん?~いせりさん~

井芹さんから、テスコン(U-30)ことテスト設計コンテスト(30歳以下)をなぜ立ち上げたのか?これまでどのような歩みをしてきたのか?というのを伺っていきました。

最初は若い人ならではの破天荒なテスト設計手法の発見&教育・成長を目的にしてテスコンを開いていたものの、2020年からは、参加してくれた人たちへの教育や現場で価値を発揮できるテストエンジニアを育成することに注力したという話は印象的でした。
手厚いフィードバックや充実した教育資料がある理由も納得で、テスト設計コンテストに非常に興味が出て参加したくなるような内容でした。

また、審査員の方々がフィードバックを充実させるために、どのように審査員の方々がフィードバックスキル向上を図ったのか?という話や審査員同士でテスト設計コンテストのビジョンを育てていった話も、なかなか聴ける話ではないと思うので、非常に面白かったです。

メタモルフィックテスティングでMBT気分~snskさん~

AIをはじめとした期待動作を得にくい状態で有効なメタモルフィックテスティングをどのように活用することができるか、雉と猿と犬を判別する*1画像認識モデルを実例として、非常に丁寧に説明してくれました。

実際に画像認識モデルに対してメタモルフィックテスティングを行った過程を説明してもらえたことで、画像認識のメタモルフィックテスティングを行う場合にMBTとの相性がいい*2ことを実感できて、非常に面白い話を聴くことができました。

システムテスト自動化スクリプトのレビュー観点を挙げてみたの~ぱいんさん~

タイトルの通り、システムテストを自動化する際にどんな点に注意しないといけないのか、という話をぱいんさんの経験から語ってくれました。

どの観点も参考になったのですが、「システムテストを自動化する際は、人間が何気なく見れている観点を落とさないようにしよう」という話は特に面白かったです。
人間なら自然と見れているような観点であるボタンを押下した後のレスポンスタイムや、そもそもボタンがあるかどうかなども自動化のスクリプトには組み込んだ方が良いという話を聴くことができたのが、これまでそんなに意識してこなかった部分だったので楽しかったです。

その他にもテスト条件が現実的か、ソースコード重複がないか、再実行可能性があるか、実行時間は十分か、setDown, tearDown...多数の観点が挙げられており、これも学びになりました。

英語の学習法について~@hideshis_qaさん~

2日前に運営から発表のpushがあったという(笑)、hideshisさんから発表がありました。

hideshisさんがなんで英語を学習した方がいいと思うか?という話から、リーディング・ライティング・リスニング・スピーキングそれぞれでどのように勉強したのか、という話まで、丁寧に英語の学習法を教えてくれました。

興味のある記事を読む+英語で日記を書くという作業を通して、リーディングとライティングを組み合わせて伸ばすというのは、是非やってみようと思いました。
hideshisさんの優しい口調も合わさって、具体的なプラクティスだけではなく、非常に勇気をもらえる発表でした。

会全体を通した感想

今回は発表本数こそ少なかったですが、いつもに負けず劣らず充実した発表が多数あり、学びがあると共に楽しむことができました。
2022年もJaSST nanoが楽しみです!

*1:桃太郎をユーザーのペルソナとした?笑

*2:期待動作が0or1(識別できているor識別できていないしかない)のため

ドメイン駆動設計を導入するためにやったこと(の講演部分に)参加してきた

modeling-how-to-learn.connpass.com

こちらのイベントの座談会を除いた部分に参加してきたので、会の様子と感想を書いていきます。(ラスト30分で予定されていた座談会については、今回は他イベントと被っていたため残念ながら不参加です...)

イベント概要

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

ドメイン駆動設計を現場に導入するためにさまざまな体験談の発表です。

・なぜ導入に取り組んだか
・どうやろうとしたか
・うまくいったこと
・苦労した(している)こと
事業領域や開発を取り巻く環境が異なる三つの現場から、3名の体験談の発表と、座談会形式でそれぞれの考え方ややり方の意見交換をします。

イベントで話されていたこと

ドメイン駆動設計のプラクティスでカバーできること、できないこと ~松岡幸一郎さん~

発表内容

まず、DDDのポイントとしては、

  • ソフトウェアの機能性を高めること(役に立つものを作ること)
  • ソフトウェアの保守性を高めること(長期間開発しても機能開発にストレスを感じないような)

の2つがあるということで、一言で言うと、「ソフトウェアの機能性を高めることで役に立つものを作りつつ、頻繁な変更に耐えられる(機能開発が容易である)ような高い保守性を保つ」のがDDDということでした。
なお、機能性を高める・保守性を高めるというのは個別にやっても効果があるものなので、両立しないといけない(例えばモデリングをしないのはDDDじゃない...)は松岡さんの見解としては、DDDと言ってもいいんじゃないかと思っているということでした。(ただし、「ドメインモデル」で根本は繋がっているため、より大きな価値を発揮するということでした)

松岡さんはログラスに入社して、*1テストコードを増やしたり、ドメインモデル図を作成しながら開発したり、ペアプロやレビューを地道に導入したり...ということを繰り返した結果、チームにモデリングやテストをする文化が根付き、飛躍的にテストコードが増えたり、モデリングの重要性がチームに広まっていってユーザの業務を徹底的に理解する姿勢が身についたというお話でした。

後半では、具体的に新機能/既存機能に対してどのようにフィードバックをもらい、開発に活かしていったのか、というお話を聴くことができました。

文化を根付かせるために、当たり前に思えても中々継続させることが難しいこと(ユーザから早期にフィードバックを得る、テストコードを書く...)を丁寧に継続的に実践していたのが印象的でした。

参考資料

little-hands.hatenablog.com

little-hands.booth.pm

巨大レガシーシステムの戦略評価とリファクタリングにおけるDDDの活用事例~ミノ駆動さん~

続いて、リファクタリングを専門に仕事をするという、中々面白いポジションで仕事をされているミノ駆動さんから発表がありました。

ミノ駆動さんは事業領域という観点でドメインを明確化し、既存システムを分割しながらコアドメインを特定し、見つかったコアドメインリファクタリングに対して多くの投資をしていったということです。*2

また、現場への導入の際には、プロダクションコードを用いた勉強会を開いたということでした。
ミノ駆動さんも松岡さんも、現場でこれまで開発をしてきた人たちがこれまでよりもシステム開発が良くなっている実感を持ってもらえるように意識をしている様子が伺えたのが印象的でした。

変更を楽で安全にする良い設計を目指して~増田さん~

発表内容

ビジネスサイドからの期待値(ビジネスが変わった時にシステムへの反映がビジネスサイドが思うようなスピード感・コスト感で行えるようにしたい)に答えるために、超大規模なシステムのリファクタリングを行っている(現在進行形)というお話を聴いていきました。後に参考資料として貼りますが、とんでもない改善効果があったようです。*3

後半は、実際にこのような成果を出すためのスタイルが語られていきました。以下のような話が挙がっていました。

  • 設計書を読み込んで開発するのではなく、詳細設計をしながらプログラミングして、プロダクションコードを書きながら分析する
  • Whyの合意形成(悪い設計で失っているものや良い設計で得られるものを言語化・数値化)
  • Howの認識合わせ(ビジネスルール中心の構造、事実の記録付け、機能に濃淡をつけてカテゴライズ)
  • Whatの体験学習(ドメインオブジェクトを実際に書いて動かす、イミュータブルなテーブル設計、要点を絞り込んでノイズを除去する)
参考資料

実際に増田さんが現在進行形でリファクタリング&開発を進めているプロジェクトのレポートだそうです。(NRI×ドメイン駆動設計)

https://www.nri.com/-/media/Corporate/jp/Files/PDF/knowledge/publication/chitekishisan/2020/09/cs20200910.pdf?la=ja-JP&hash=8AAB2186F81D949959B358FC0D724DC972343665

全体を通した感想

現場の開発とDDDをどのように接合させるか、という試みの話が聴けたので良かったです。
松岡さんミノ駆動さんの話からは、現場で既存で取り組まれているやり方を壊し過ぎないようにして現場の理解を集めながら、DDDの要素の一部分(?)を取り入れようとする話が聴けて、増田さんの話からは、「変更を楽で安全にする」という観点とDDDがどのように関わるのかという話が聴けて、三者三様の実際の開発例が聴けて面白かったです。
この接合部分の話は、個人的にはもっともっと聞きたい感覚もありましたが、今回は30分という時間の都合もあったと思うので、また次を楽しみにしようと思います。

*1:松岡さんは、元々DDDの講師としてログラスに行っていたようで、まさにミイラ取りがミイラになったというお話をされていました

*2:この作業の過程では、有識者が全然いない&人手が全く足りないという事態に直面したそうで、相当な苦労があったそうです。。。

*3:ソースコードが183千行→97千行になる、同じ修正規模だった時に修正が必要なモジュールが追加3修正65→追加1修正2になるなど...

チームビルディング勉強会 「ちいとぽ」感想会!に参加してきた

team-building-study-group.connpass.com

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

会の概要

タイトル通り、ちいとぽことチームトポロジーを読んだ皆さんで感想戦をしていこうというイベントです。

会で話されていたこと

OST形式で、30分×2で2つのテーマについて感想戦をしていきました。

認知負荷とは?

認知負荷という単語が本では多種多様な場面で用いられており、これってどういう意味で使われているんだろう?という話をしていきました。意見としては以下のようなものが挙がっていました。

  • プロジェクト型の認知負荷/プロダクト型認知負荷というのがありそう。
  • 制限しない方が良い認知負荷があるのでは?普段全く仕事をしないチームから知識を仕入れることで、何か新しいやり方が生まれるなど
  • 学習内容に伴う負荷/学習に関係ない余計な負荷/学習に役立つ適切な負荷の3つに分けて、それぞれの認知負荷をどう効果的に調整するかを考えると良さそう。学習内容に伴う負荷は、コンプリケイテッド・サブシステムチームが調整し、学習に関係ない余計な負荷はスクラムで言うスクラムマスターやプラットフォームチームが調整し、学習に役立つ適切な負荷はイネイブリングチームが調整する、というような形。
  • 認知負荷という概念が作られたコンテキストが教育分野なので、これを組織に適用するのは難しそう。認知負荷という概念が現れた元々の論文を読んでも、認知負荷という概念を活用している場面が大分違うので、「認知負荷が高そうだから下げよう!」位のレベルで行動すると痛い目を見そう。
  • 認知負荷が高いかを測るやり方が難しい(外から質問を投げてみてどれ位的確に答えが返ってくるか?で測るというのは、認知負荷以外の要素があまりにも影響しそうだった。)

チームAPIの活用

書籍内で紹介されていたチームAPIを上手く活用する方法は?という話を議論していきました。以下のような意見が挙がっていました。

  • 過去に他のチームとやり取りした際、「定義されたフォーマットでチケットを挙げてください」と言われて、冷たいな...と感じたことがあったが、あれはまさにチームAPIを適切に定義できていた例だったのかもしれない。
  • チーム間のドラッカー風エクササイズという感覚を持った。チームごとに何かしらの想いがあり、その思いにしたがってコミュニケーションを取ろうよ、コミュニケーションプロトコルを定義しようよという話。
  • 結局はストリームアラインドチームが肝になっているので、ストリームアラインドチームを軸に考えると、適切なAPIが切れそう
  • レポートライン別/話したいロール別にチームAPIを定義することで、余計な介入を減らすことができるのではないかと思った。

チェックアウト

チェックアウトとして、参加者でふりかえりをしていきました。以下のような感想が挙がっていました。

  • もやもやするポイントが多い本だと再認識できた
  • もやもやの共有ができてよかった
  • まずは良いストリームアラインドチームを作ることが大切なんだと思った
  • どの立場の実践書かが分からなかった。
  • チームAPIを実践したい
  • 認知不可の高まりを検知する方法をもう少し考えたい
  • 4つのチームタイプのネーミングが複雑でもやる
  • いつでもどこでも「まずは会話しましょう!」ではないんだな、と知れた
  • 「プラットフォームチームの価値は、プロダクトチームに提供しているサービスの価値で測られる」という言葉が好き
  • チームAPIの話で、コミュニケーションは密なもの/密ではないもの両方が必要ということが分かった
  • 組織設計する上の人(事業部長とか)にも読んでもらいたい。。

会全体を通した感想

皆さんのもやもやが多めだった部分が挙げられ、それぞれについて共有できたのが良かったのかな、と感じました。(参加者からも、自分の想いと似たような想いを聴けて安心したという感想が多く挙がっていました)

個人的には、認知負荷の部分はまだまだ自分の理解が浅く、現場のコンテキストに合わせるためには、もう少し原著となっている論文を読み込んだり、学習科学の観点から深堀をしたいなーと思いました。

merpay QA Talk 〜メルペイQAのリアル vol. 3〜に参加してきた

mercari.connpass.com

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

イベント概要

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

今回のイベントは、フルリモート環境において選考を受け入社をしたメンバーを中心に

コロナ禍での転職で抱えていた不安や選考中に感じていたこと
入社後のオンボーディングやキャッチアップについて
フルリモート環境において日々どんな取り組みをしているのか
どんな働き方をしているのか
YOUR CHOICEな働き方ってどう?
など「全員品質」を目指すメルペイのQAエンジニアたちのリアルな声をお届けします。
以下のような方にオススメの回です。

コロナ禍での転職活動について知りたい方
メルペイの実際の状況(体制や働き方)を知りたい方
他社のQAエンジニアが何をやっているか興味がある方
2021年9月15日のイベント merpay QA Tech Talk ~メルペイQAのリアル vol. 1~ に参加した方
2021年11月24日のイベント merpay QA Tech Talk ~メルペイQAのリアル vol. 2~ に参加した方
「全員品質」ってなに?と思った方
一つでも当てはまる方は、ぜひご参加ください!

また、本イベントは「メルペイQAのリアル」の後に会社や求人について紹介する時間を予定しています。
パネルディスカッションでメルペイQAについて興味を持って頂いた方は是非そのままご視聴ください。

イベントで印象的だったこと

オンラインでコミュニケーション機会を増やすための仕掛け

コミュニケーションの機会を増やすために、マネージャーやQAの他メンバーと定期的に1on1の場を設けたという話をされていました。また、Slackでも質問をしやすい雰囲気作りがされているため、分からないことがあった時や困った時に質問がしやすいということです。

他にも、雑談会の場を作ってそこではプライベートのことを話したり、日報を用いて今何をやっているかというのが全員に見えるようにしていたり、相手のことを知り、コミュニケーションのきっかけを作りやすくしているということでした。

プライベートの話をする場と、仕事の話をする場を明確に分けてそれぞれ意図的に場を用意しているのは面白いなあと思いましたし、「コミュニケーションの機会が多く、相談しにくいとかコミュニケーションコストが多くかかるといった問題が起きない」という話を聴いて、意図的にコミュニケーションの機会を増やす重要性を実感しました。

メンバーの声を吸い上げる

仕事で困っていることがあればすぐにマネージャーやメンターに相談して声を反映させてもらえるという話や、他プロダクトの話をもっと知りたいという話から他チームとのシャッフルランチが開かれたりと、メンバーの声がすぐに吸い上げられるというお話がありました。

評価の仕組み

評価の際には評価の根拠となるようなエビデンスをまとめて提出し、そのエビデンスを基に評価がされているため、納得感が強いということでした。
また、1on1をはじめとしたコミュニケーションの機会が多いことから、評価の際にはよく見てもらっている印象が強く、評価に対して満足感を感じることが多いというお話でした。

評価する側の意見としては、「コミュニケーションパスも多いため、例えばAさんの評価をする際に、Aさんの声からだけを基に評価するのではなく、Bさん, Cさん...他の人から聞いたAさんの働きぶりも評価対象となり、多角的な評価がしやすい仕組みになっている」という話が挙がっていました。

評価というとどこも課題を持っている印象がありますが、(少なくとも今回イベントに登壇されていた方々に関しては)コミュニケーションの機会が多いことが評価の満足感に寄与しているようで、面白いなあと思いながら聴いていました。

全体を通した感想

QAという文脈ではなく、チームで働いている人たちであれば誰しもが参考になるんじゃないかと思う話でした。

コミュニケーションの機会が多い、コミュニケーションパスが多い、の2点が有効に作用している実例を聴くことができたので、それが大きな収穫でした。

#RSGT2022 プレゼンを同時視聴したり、アジャイル系の相談したりに参加してきた

distributed-agile-team.connpass.com

RSGTが終わって最初の木曜日が来て、今日も分散アジャイルチームに行ってきたので会の様子と感想を書いていきます。

「ブルシットプロダクトからチームを守れ! 「顧客が本当に必要だったもの」をいかに追求しつづけるか」の同時視聴

https://confengine.com/conferences/regional-scrum-gathering-tokyo-2022/proposal/16109

こちらをまずは見ていきました。途中少し抜ける場面もあったのですが、分散アジャイルチームの同時視聴会ならではの盛り上がりがあって、今日も最高の時間が過ごせる予感がするスタートでした。

今日はRSGT直後ということもあったのか、普段よりも多くの方々がいらして、kiroさんや及部さんなど、多くの方が突っ込みを入れたり理解を補足してくれたので、森さんのセッション×1.5倍というコラボレーションでも聞きやすかったです。
また、森さん自身も、発表で言えなかったことや専門用語を使った補足を交えてくれて、なんとも豪華な時間でした。

(スクラムアジャイルを)よく学びよく試行錯誤する~継続して学び現場に持ち帰るために~の同時視聴

https://confengine.com/conferences/regional-scrum-gathering-tokyo-2022/proposal/16154

まさかの自分のセッション...ということでなぜかめちゃくちゃ緊張しましたが、皆さんからたくさん感想が聴けてありがたかったです。

色々感想をいただけて嬉しかったのですが、一歩一歩過程を辿ったり苦悩することで普通の人から今の自分に至ったことが分かった、というお話をいただけたのがすごく嬉しかったです。*1
また、「勇気が出るセッションだった」「聴いていてワクワクしました」と言ってもらえたのもとっても嬉しかったです。

RSGTでの登壇は本当に緊張しましたし、思い出すと未だに変な汗をかいてしまうのですが笑、こうしてフィードバックを貰えるのは本当にありがたいですし、すごく嬉しかったです。

LeSS もスクラム。プロダクトオーナーがスクラムマスターとともに取り組んだ LeSS チームの合体から融合までの同時視聴

https://confengine.com/conferences/regional-scrum-gathering-tokyo-2022/proposal/16136/less-less

続いて、nakoさんのセッションを見ていきました。
コミュニケーションをSMやマネージャーなどと綿密に取る、優先順位を明確化しながらバックログを作っていく、ルール化されたWAを直していく...は言葉にすると簡単ではあるものの、実践したり継続するのは中々難しいことを積み上げていく姿が印象的でした。

タイトルの「Lessもスクラム」にもある通り、「Lessだから特別な何かをしたり突拍子もないようなプラクティスを導入する」というのではないんだなーというのが、これまで聞いてきた大規模アジャイルのどの発表よりも出ている素敵な発表でした。

nakoさんは現地でもお話したのですが、何でも話したくなるような素晴らしいマネージャー感がにじみ出ていたのが印象的でした。

The Battle in Scrumの同時視聴

https://confengine.com/conferences/regional-scrum-gathering-tokyo-2022/proposal/16137/the-battle-in-scrum

最後はkiroさんの発表を同時視聴していきました。
kiroさんっぷりが全開で、プレゼンが本当に上手だなあという感想をまずは持ちました。
アレグザンダーヲタク全開の話でしたが、kiroさんご本人から、プレゼンの補足や実はこんな話もしようと思っていたという話が聴けたり、アレグザンダーヲタクのきょんさんからの補足があり、いきいきとする同時視聴会でした。

最後はkiroさんから、記録には残せないスクラムに関するオフレコ話もありw、やはりお金払っても来たいような会だなあと思いました笑

全体を通した感想

新年一発目にふさわしい、最高の分散アジャイルチームでした。
また、本当にたくさんの知識を教えてもらって育ててもらった(と個人的に勝手に感じている)分散アジャイルチームの会で、自分のセッションを見てもらって感想をいただけたのは、感慨深い時間でした。

*1:良くも悪くも導入でかなりインパクトを与える構成にしたので、この構成にした結果、ただすごいこと自慢をした人、みたいに捉えられないかがすごく不安だったので