2020-05-06

分散アジャイルチームについて考える会。またはMuralの負荷試験について #distributed_agile_team #オンライン勉強会

Agile

COVID-19の影響でIT系の人達はテレワーク導入をすすめているけど、どうなんでしょうね。っていうかんじで勉強会を spring_akiさん、TAKAKING22くんの3人でやってみました。 4月21日と5月5日の2回やり、どちらもLTを数本と、OST(みんなでトピックをきめるディスカッション)。特に、5月5日は、13:30 - 19:00までのほぼ1日やってみるというものでした。これらの回の概要、そしてどんなツールをつかったのかを紹介します。またツール選定にあたっておこなった負荷試験のスクリプトも紹介します。

イベント概要
利用したツール
Muralは50名付箋のみ同時編集なら余裕、80名以上でもたつく
オンラインOSTはいいぞ！
最後に

2020-02-20

複業で個人事業主を1年やってみた。

2019年1月から「うさぎ組」という個人事業主をしています。会社員との複業でやっていて、半分ずつくらいという感じです。 1年でどんな仕事をしてきたのか、どんな感じなのかなどをまとめておきます。

概要

個人事業主で半分くらいを仕事できた。値下げなし。
つながらない仕事もたくさんあるのは会社員と一緒だった。
友達にたくさんたすけてもらった。

kyon-mm.com

開業
知ってもらう
仕事の内容
スポンサー
発表
Youtubeでトーク
売上など
育休
最後に

2020-01-14

カンファレンスを最高にするストーリーとスルーライン。もしくはアレグザンダー理論からみるカンファレンスの美しさ #RSGT2020

scrum design

RSGT2020をこじらせた人の考察エントリです。

プレゼンテーションにおいて大切なことはストーリーがあること。そして全体を通したテーマ（スルーライン）をつくることと言われています。*1 これで相手に自分を理解してもらいやすくなります。人は古代からストーリーに惹かれるし、長時間の話の末に、なにか心をゆさぶられるのは、話がつながっているからだとかんじています。でも、それを拡張してカンファレンスでできたら？たしかにカンファレンスにテーマを設定しているものはあるけど、全体をとおしてまさに「スルーライン」を感じられるストーリーがいきづくようなカンファレンスは？

今回のRegional Scrum Gathering Tokyo 2020は1日目のKeynoteからストーリーがはじまり、全体を通してスルーラインをかんじられるものでした。私は3日間ずっとわくわくしていて、こんなにどの時間帯でも学びを得たことはなかったです。大抵のイベントはおもしろい話はあれども、ずっとわくわくするということはできない。それはそれでいいのかもしれないですけど、でもこんな体験はなかなかできなかった。

このエントリーでは同イベントがなぜ私をこんなに夢中にさせたのかを考察します。

全体的な感想
以前から運営がいっていたこと
15の幾何学的特性による考察
最後に

全体的な感想

同イベントは2019までの良さのおおくをひきつぎつつも、私にとって最高のストーリーをかんじさせてくれました。すくなくとも、2018, 2019までのKeynoteというのは自分達の体験の話をすることがおおく、それらはとても心にひびき、示唆にとむものでした。ただ、わたしのようなアジャイルこじらせた人からすると、物足りないのも事実でした。具体的な体験もよいのですが、そこから得られるもっと法則やなにかについて聞きたし、イベント全体をとおして咀嚼していくような楽しみがなかったからです。私はなんらかの法則に興味があり、そういったものを語れる、咀嚼できる場をつねにもとめています。

今回のJames O Coplien による十牛図をつかったScrumへの向き合いを見つめ直すという話はまさに、様々な人にたいし「あなたはどこにいるのか、なにをみているのか、なにがみえていてい、なにがみえていないのか」などといったことをソフトウェア開発においてあてはめてみようというものでした。このKeynoteはパタンの具体例をはなすのではなくてパタンを雄弁に語るストーリーとして受け取ることができて、後に続くセッションの聞きかた、参加の仕方、思考にたいして一石を投じるものだったとおもいます。

1つの料理がよかったのではなく、フルコース料理のような感想をいだかせてくれたのがRSGT2020でした。

以前から運営がいっていたこと

運営の id:kawaguti さんや id:miholovesq さんがよくいっていましたが RSGTのセッション採択はどのように決まるのか - kawaguti’s diary によくまとまっています。セッション採択では次の流れできまっているようです。

Like機能による投票

Likeはあくまで一つの指標

Likeが少なくても落選にしない

一軍でカンファレンスの骨格を作る

テーマを集めてトラックを形成する

全体の流れをみながら、あいている枠に実行委員推薦のセッションを入れていく

参加者のペルソナを想定してウォークスルーをする

そして寝かす！

実は手間のかかる作業はここから

ここまででセッションスケジュールの作業は完了。最終チケット販売へ

現在プロポーザル募集中のカンファレンスもあります！

ここからわかるように、テーマそしてウォークスルーと流れを意識されてつくられていることがよくわかります。ここにKeynoteとして問いというものが今回はくみあわさったので、私にとって非常に響くものになったのではないかなぁとおもっています。

15の幾何学的特性による考察

ここからは同イベントをざっくりとですが、クリストファーアレグザンダーによる15の幾何学的特性で分析してみたいとおもいます。なおこれは正しさはまったくありません。独断と偏見です。

スケールの段階性
力強いセンター
境界
交互反復
正の空間
良い形
局所的に現れるシンメントリー
深い相互結合と両義性
対比
段階的変容 
粗っぽさ
共鳴
空
簡潔さと静謐さ
不可分であること

ストーリーとスルーラインの美しさ

James O Coplien の十牛図をつかったScrum PatternのKeynoteでは自分達が何を求めて、何を見つめて、何処へ行き、何をして生きるのかというような話だったとおもいます。初日の最初にして、歴史でもなく、プラクティスでもなく、自分と世界を認識することから始まりました。今回のRSGTではこれこそが「力強いセンター」としてのスルーラインになっています。「あなたは何で、世界をどう捉えているのか」

そこそこScrumの人気がでてきたからこそでてくる「このやり方であっているのか？」「Scrumにこだわっているわけではないけど」「Scrumってなんだ」「アジャイルな組織になることにどう立ち向かうんだ」というそれぞれの悩みを包含するように話すのは難しいと私はかんじてしまいます。ですが、Coplienは十牛図をつかって具体的なところは個々の事象やスクラムパタンの話をつかいながらうまくストーリーをつむいでいました。

翌日のSahotaのKeynoteはほとんど聞けなかったのですが、ほんのすこしだけきけたところや、スライド、参加者の話をきくと、やはり前日からつながっています。「あなたは何で、世界をどう捉えているのか」。アジャイル組織におけるマネージャーというのも、「自律性の高い組織にはマネージャーは不要」「ほんとうにそう？」という悩みをバランスよくなんて言葉をつかわずに、XY理論をつかって組織の部分毎の立ち位置を丁寧に具体的なストーリーとしてつむいでいました。

最終日の高橋さん(かっぱたん)のKeynoteは1人のエンジニアとしての生い立ちという強いストーリーがありながら、そこにはやはり「あなたは何で、世界をどう捉えているのか」という話でした。とくに「お前はなにを成すのか」「その道程を楽しむんだ」という印象がつよかったというのもあります。とても具体的でありながら、つたえたいのメッセージは自分がつながっていくとかそういったはなしでした。NOT ALONEという結びに感動した人もおおいのではないでしょうか。

CopeやSahotaはさすがで、自分の話をしていません。ストーリーをはなすときに自分の話はいくらでもおもしろくできますが、コミュニティや業界にたいする問いにおいて90分間のストーリーで人をひきつけるのはさすがです。

我田引水な感じですが、その後のkyon_mmの「チームの再定義 -進化論とアジャイル-」や TAKAKING22の「Team-Based Team - 会社を越えるチーム -」も「あなたは何で、世界をどう捉えているのか」というスルーラインをたもったまま、自分達がどのようにチーム、組織を見つめているのか、そして見つめられているのかという話をしました。kyon_mmもTAKAKING22もよくもわるくも自分のストーリーをはなしています。

これは一例なのですが、「あなたは何で、世界をどう捉えているのか」という生きるうえでの重要な問いといってもいいものを3日間かけて咀嚼できていくというすばらしい体験がそこにはありました。

このスルーラインが「力強いセンター」としていきづいており、もちろん他のテーマもありましたが、それらの数はすくないものにみえます。独断と偏見では14セッションがこのスルーラインにひっかかっていて、他は4セッションが2テーマ、1セッションがいくつかのテーマにみえます。この段階的に力強さがかわるのは「力強いセンター」とともに「スケールの段階性」が現われているなぁとおもいました。典型的な美しさにみえます。

また、スルーラインが3日間にわたって咀嚼できるというのは、「あなたは何で、世界をどう捉えているのか」という問いを媒介にして「事例」と「体験」の「交互反復」が起きていました。「力強いセンター」が別の側面で「交互反復」をもっているというのはよくみられるくみあわせです。

セッション時間と数の美しさ

Keynoteが90分、45分セッション、20分セッション、100分ワークショップという構成でした。「段階的変容」と「局所的に現れるシンメントリー」とみるのがいいんでしょうかね。よさそうです。

ただ各セッションの時間のスケールにあわせたセッション数でいうと「スケールの段階性」という美しさはありません。「大きいものほど数が少なく、小さいものほど数がおおい。そこにもおなじようなスケールがある」とはなっていないことがわかります。時間配分に美しさをかんじるようなカンファレンスはまだ見たことがないのですが、実現されたときにどうなるんでしょうね。

Day1
- 90分 x 1
- 45分 x 6
- 20分 x 4
- 100分 x 2
Day2
- 90分 x 1
- 45分 x 8
- 20分 x 8
- 100分 x 0
Day3
- 90分 x 1
- 30分 x 36

廊下という自由

廊下で会話が創発される感じはまさに「粗っぽさ」からおきているように見えます。目的も方法も時間も規定されていない。そのためのスタンディングテーブル、あたたかいコーヒー、水などです。これにより、人によってSlackをもてたり、あたらしくつながったり、自分のセッションへのフィードバックをもらったり、仲間と考察をしたりと様々な時間をすごせるようになっています。またあたらしいストーリーがうまれる場でもあります。これは同イベントの感想ブログでも多く言及されており、粗っぽい場をつくることにより個々人の満足度がおおきく向上しています。いきいきとするんですね。

各セッションの部屋の広さ

朝のKeynoteでは400名、午後から各セッションでは200名、200名、60名、というのを2回くりかえしてからの、会場全体という最も全体をつかった場づくり。 1日目、2日目では、時間経過とともに「段階的スケール」をかんじさせる場でありながら、最終日には全体性をかんじさせる場をつくるというのが最大とおもっていた部分がぜんぶつながって本当の全体をみせるという形につながっています。

この時間経過とともに場の部分と全体をいききする感じがいきいきとするんでしょうね。

考察が不足しているもの

考察してみたけど特性がわからなかったものはいくつかあります。これは私のスキル不足から達成、未達成にかかわらずその狙いと美しさの関係がわかっていません。

Coach's Clinic
Open Space Technology
Open Proposal
Advent Calendar
Sponsor Booth
Networking Party
Speaker's Dinner
各種食事

考察に力つきたともいいます。

最後に

もし可能ならこのようないきいきとした場というのをまたつくってみたいとおもいました。運営からしたら意図とちがうとか、いろいろアレな解釈されてもこまるとかあるかもとおもいましたが、このカンファレンスの1ファンとして投稿させていただくにいたりました。こわかったので、運営にも念のため確認をさせていただいたのですが、快諾いただけました。ありがとうございます！また来年もたのしめたらいいなとおもいます。

パターン、Wiki、XP ~時を超えた創造の原則 (WEB+DB PRESS plusシリーズ)

作者:江渡浩一郎
出版社/メーカー: 技術評論社
発売日: 2009/07/10
メディア: 単行本（ソフトカバー）

ザ・ネイチャー・オブ・オーダー　建築の美学と世界の本質　生命の現象

作者:クリストファーアレグザンダー
出版社/メーカー: 鹿島出版会
発売日: 2013/09/11
メディア: 大型本

*1:TED TALKSでよく話題になっています

TED TALKS スーパープレゼンを学ぶTED公式ガイド

2020-01-06

#RSGT2020「チームの再定義 -進化論とアジャイル」セッションを3倍楽しむ

1/8から開催されるRegional Scrum Gathering Tokyo(RSGT) 2020。年に1度の日本最大級のScrumのカンファレンスです。このイベント内の1/9 13:00 から「チームの再定義 -進化論とアジャイル-」というセッションを3倍楽しむ情報をまとめておつたえします！

Regional Scrum Gathering Tokyo 2020 - チームの再定義 -進化論とアジャイル- | ConfEngine - Conference Platform

前作まで

この作品はRSGT2016から続く一連の最新作になります。

2016 : Scrum, Test , Metrics
2017 : スクラムありがとう, そしてさようなら -Scrum 破-
2018 : スクラムが難しいのは幻想 -情熱の再定義-
2019 : 超Scrum入門
2020 : チームの再定義 -進化論とアジャイル-

2016「Scrum, Test , Metrics」

基盤チームというチームがScrumに取り組みはじめたところから話はスタートしました。常にテストをし、6min単位での予定、実績工数のメトリクスをとり、自分達の感覚によるメトリクスの重要性の話をしました。

Scrum,Test,Metrics #sgt2016 from kyon mm

www.slideshare.net

2017「スクラムありがとう, そしてさようなら -Scrum 破-」

Scrumのスプリントレビューは全員がおなじものをデモしたり、POやSMというロールはDailyにクジできめたり、スプリント期間を1日スプリントにしたりとスクラムのルールや慣習を変えていく話をしました。ここから超個体（複数の生命体が１つの生命体かのようにふるまう集団）をめざしはじめました。

2018「スクラムが難しいのは幻想 -情熱の再定義-」

スプリント期間を1時間スプリントにしたり、タイマーによる時間管理をしたり、スクラムイベントをできるだけプロトコル化したり、DailyでValueStreamMappingをしたりとできるだけ仕組み化していく話をしました。ここから超個体や自然の仕組み、攻殻機動隊を次の目標にすえはじめています。

2019「超Scrum入門」

スプリント期間を15分スプリントにしたり、複数のスプリント期間をあつかってフラクタル構造にしたり、Krebs Cycle for Creativityをとりいれたり、ARTとしてのKPTで壁をKPTだらけにしたりとより人間や生物や化学の根源的なところに着目していく話をしました。ここからScrumの3本柱といったものとは別のものを見るようになってきました。

2020 本作「チームの再定義 -進化論とアジャイル-」

生物や化学の根源にあるフラクタル構造という安定した性質を土台にすえながら、スプリント期間以外にもフラクタル構造にしていくことや、超個体の性質である頻繁な正のフィードループとゆるい負のフィードバックループを仕組み化することなどを目標にして2019年を過ごしたチームの話です。

1つのチームが複数のプロジェクトに分裂したとき、そのチームはどうひきつがれるのでしょうか。おなじものにはならないし、それなりの成熟をするには時間がかかる。だから、チームはできるだけ解散してはならない。果たして本当にそうでしょうか?

私達のチームメンバーは複数のプロジェクトにわかれ、PBLもPOもまったく異なるようになりました。それでも1つのチームとして存在する方法を模索しました。その過程で、複数チーム、複数プロジェクトにおける15minスプリントを基盤とするフラクタルスプリント、組織横断な知識交換、プロジェクトに依存しないチームとしての存在意義を見出してきました。私達のチームは解散したようにみえましたが、実際には解散していなかったのです。フラクタルスプリントによってフラクタルチームは成されました。

異なるミッションをもっていても、組織としては軍隊アリやバッファローのような超個体をめざす1つのチームとして機能をするようにまでなりました。プロジェクトのためだけにチームがあるのではありません。わたしたちがいるからチームなのであるという視点をつきつめていき、それは個人や組織の成長にもつながっていく姿をお話します。

そしてこれらを支える理論として進化心理学、ダーウィンの進化論などの学術的な視座からアジャイル開発を話します。なぜ人間はチームをつくるのか。

進化論

ダーウィンの進化論のことですが、この10年ほどで進化心理学という学問が注目をあびています。それ以外にも文化人類学などもまた盛り上がってきています。アジャイルやチーム開発というものを進化で獲得した形質と照らしあわせて話します。人間の欲や振舞いというのが進化で獲得した形質だとしたら？

参考文献は次になります。

人が自分をだます理由:自己欺瞞の進化心理学

作者:ロビン・ハンソン,ケヴィン・シムラー
出版社/メーカー: 原書房
発売日: 2019/02/27
メディア: 単行本

進化心理学から考えるホモサピエンス一万年変化しない価値観 (フェニックスシリーズ)

作者:アラン・S・ミラー
出版社/メーカー: パンローリング株式会社
発売日: 2019/01/25
メディア: 単行本（ソフトカバー）

サピエンス全史　上下合本版　文明の構造と人類の幸福

作者:ユヴァル・ノア・ハラリ
出版社/メーカー: 河出書房新社
発売日: 2016/09/16
メディア: Kindle版

攻殻機動隊

攻殻機動隊というのはSF刑事作品というジャンルですが、作者の先見性や洞察力が感じられる作品として人気をえています。このなかで攻殻機動隊 STAND ALONE COMPLEXというシリーズ名でアニメ作品があり、「チームプレーなどという言い訳はない。あるのは、スタンドプレーの結果生じるチームワークだけだ。」というセリフが有名です。 2018の「スクラムが難しいのは幻想 -情熱の再定義-」ではこのセリフを引用しています。チームにおいてこの攻殻機動隊全体を通じたメッセージというのは非常に参考になる点がおおく、本作「チームの再定義 -進化論とアジャイル-」でもいくつかリンクする部分がでてきます。

www.netflix.com

www.production-ig.co.jp

最後に

前作までの流れ、進化論、攻殻機動隊の3つをおさえておけば「チームの再定義 -進化論とアジャイル-」をもっと楽しめます。お茶の水ソラシティ 1/9 13:00 テラス会場でおまちしております。

2019-12-09

kyon_mmのプロポーザル没ネタ集 #RSGT2020

このエントリは Regional Scrum Gathering Tokyo Advent Calendar 2019 - Adventar のエントリです。

昨日はharadakiroさんの Regional Scrum Gathering Everywhere - haradakiro's blog でした。キーノートとOSTを担当されたとのことでしたが、アジア圏でのScrumコミュニティでも私達とおなじような悩みをかかえているんですね。来年はいってみようかな。

さて、わたしはRSGT2020のプロポーザルが運よくとおりまして、チームの再定義という話をします。 => https://confengine.com/regional-scrum-gathering-tokyo-2020/proposal/12223/-

で、そもそもプロポーザルに登録しなかったけど、こういったネタもあるにはあるんだよなーっていう一覧を紹介します。たぶんRSGTにはむかないだろうなーってものもあるし、あとは自分が話したいのはやはり今とおっているものなのでどれもだしませんでした。もし、これらの内容に興味があるかたは、社内でもオープンイベントでも呼んでください。話にいきます。 => https://kyon-mm.com / twitter @kyon_mm / FB Kyon MM

没ネタ一覧

アジャイルにおけるシステムアーキテクチャ設計
レトロスペクティブツアーという複数チームのプラクティス
Scrum is dead. Long live the alliance.
大規模システム開発は予算のとり方にあわせた手法でしか幸せになれない
チーム開発を10年勉強してわかった3つのこと
アジャイルコーチと開発チームの2足の草鞋
私達がPullRequestよりもLimboを選ぶ3つの理由

タイトルだけだとあれなので、かるい説明をしていきます。

アジャイルにおけるシステムアーキテクチャ設計

これは最近発表している数理的システムアーキテクチャの話をよりアジャイル開発の現場でどう意味があるものなのか、どんな場面で役にたつのかという話になります。数理的システムアーキテクチャ設計(αバージョン)のスライドはこちらです。ソフトウェアシステム設計におけるアレグザンダー理論の活用数理的システム設計手法の提案 #agileto2019 - Speaker Deck

レトロスペクティブツアーという複数チームのプラクティス

複数チームの全員参加で、他チームのレトロスペクティブを見てまわるというプラクティスです。これによる学びはかなりおおきいんですよね。ということで、ここ数年いくつかの現場で導入、実践しているので、結果付きで話せたらいいなと。

Scrum is dead. Long live the alliance.

タイトルはあおりなんですが、まぁ大規模アジャイルの手法はどれもだめで、その理由とかです。いくらかはRSGT2020ではなす、「チームの再定義」にも含まれる内容になります。

大規模システム開発は予算のとり方にあわせた手法でしか幸せになれない

これはタイトルのままです。予算への承認のとりかたがウォーターフォールだとアジャイルには開発がすすめられないとかです。

チーム開発を10年勉強してわかった3つのこと

これはまぁわたしの経験の話ですね。(それ以外もだろ！！！)

アジャイルコーチと開発チームの2足の草鞋

この1年は複業でアジャイルコーチと開発チームをやってきたので、その経験をただはなすかんじ。 https://kyon-mm.com で企業や学生へのアジャイルコーチ、 https://otr-jp.com でシステム開発という感じでした。

私達がPullRequestよりもLimboを選ぶ3つの理由

先日、masterブランチ一本でいいじゃんってかいたらいろいろ反響があったので、そのへんをまとめたやつです。 Limbo というのはこちらです => https://medium.com/@kentbeck_7670/limbo-on-the-cheap-e4cfae840330

JUnit5でテストに時間がかかりすぎたら失敗にする Timeout アノテーション

JUnit

@Timeout で実行時間がかかりすぎていたらFailにする
リポジトリ
参考書籍

@Timeout で実行時間がかかりすぎていたらFailにする

自動テストの実行時間がかかりすぎているときには、Failにしたいということがたまにおきます。IOに依存しているテストではよくありますし、複雑なロジックをくんでいて無限ループになってしまったり、組み合わせ爆発がおきてしまったり。そういうのが予見されるときには個別に@Timeoutというアノテーションをテスト対象の範囲に最大実行時間を指定しておくことで実現します。

package junit5.timeout;

import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.Timeout;

import java.time.Duration;
import java.util.concurrent.TimeUnit;

import static org.junit.jupiter.api.Assertions.assertTimeoutPreemptively;

class TimeoutDemo {

  @BeforeEach
  @Timeout(5)
  void setUp() {
    // この中の処理で5秒以上実行してしまったらここでFailする
  }

  @Test
  @Timeout(value = 100, unit = TimeUnit.MILLISECONDS)
    // unit指定なし => 秒。
    // unit指定 => nano秒から日まで指定できる
  void _100ミリ秒以上かかるとテストが失敗する() {
  }

  @Test
  void 非同期実行におけるタイムアウトはassertTimeoutPreemptivelyを使うと便利() {
    assertTimeoutPreemptively(
        Duration.ofSeconds(1),
        // なにか非同期で実行するもの。Executableをわたす。
        () -> {
        });
  }

}

@Timeoutはクラスにつけたら、@Testや@BeforeEachなどのそれぞれにつけたのと一緒の動きになります。もちろん、@Nested がついたクラスがインナークラスにいても動作します。

package junit5.timeout;

import org.junit.jupiter.api.*;

import static java.lang.Thread.sleep;

// ClassにもTimeoutをつけられる
@Timeout(2)
public class TimeoutClassDemo {

  @BeforeEach
  void setup() throws InterruptedException {
    sleep(1_000);
  }

  @Test
  void some_spec_1() throws InterruptedException {
    sleep(1_000);
  }

  @Test
  void some_spec_2() throws InterruptedException {
    // Timeoutよりおおきいので失敗する
    sleep(2_100);
  }

  // Nestedの中でもClassにつけたTimeoutは有効
  @Nested
  class SomeContext {
    @BeforeEach
    void setup() throws InterruptedException {
      sleep(500);
    }

    @Test
    void some_spec_3() throws InterruptedException {
      sleep(1_000);
    }

    @Test
    void some_spec_4() throws InterruptedException {
      // Timeoutよりおおきいので失敗する
      sleep(2_100);
    }
  }
}