うさぎ組

ソフトウェア開発、チームによる製品開発、アジャイル、ソフトウェアテスト

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

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

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

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

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

目次

全体的な感想

同イベントは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の幾何学的特性で分析してみたいとおもいます。なおこれは正しさはまったくありません。独断と偏見です。

  1. スケールの段階性
  2. 力強いセンター
  3. 境界
  4. 交互反復
  5. 正の空間
  6. 良い形
  7. 局所的に現れるシンメントリー
  8. 深い相互結合と両義性
  9. 対比
  10. 段階的変容

  11. 粗っぽさ
  12. 共鳴
  13. 簡潔さと静謐さ
  14. 不可分であること

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

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シリーズ)

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

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

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

#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単位での予定、実績工数のメトリクスをとり、自分達の感覚によるメトリクスの重要性の話をしました。

www.slideshare.net

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

Scrumのスプリントレビューは全員がおなじものをデモしたり、POやSMというロールはDailyにクジできめたり、スプリント期間を1日スプリントにしたりとスクラムのルールや慣習を変えていく話をしました。ここから超個体(複数の生命体が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年ほどで進化心理学という学問が注目をあびています。それ以外にも文化人類学などもまた盛り上がってきています。 アジャイルやチーム開発というものを進化で獲得した形質と照らしあわせて話します。人間の欲や振舞いというのが進化で獲得した形質だとしたら?

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

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

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

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

攻殻機動隊

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

www.netflix.com

www.production-ig.co.jp

最後に

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

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 アノテーション

@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);
    }
  }
}

リポジトリ

GitHub - kyonmm/junit5-timeout

参考書籍

テスト駆動開発

テスト駆動開発

Java本格入門 ?モダンスタイルによる基礎からオブジェクト指向・実用ライブラリまで

Java本格入門 ?モダンスタイルによる基礎からオブジェクト指向・実用ライブラリまで

[改訂新版]マインドマップから始めるソフトウェアテスト

[改訂新版]マインドマップから始めるソフトウェアテスト

既存のシステム設計手法ではつらいので、数理的システム設計という手法をつくった #agileto2019

現代のソフトウェアシステムにおけるシステムアーキテクチャ設計手法や、それらをとりまく各種手法は素晴しい。だけど、わたしはまだまだもっと理想にちかづきたい。 そんな思いから課題をみつめて、自分なりに設計手法をつくってみました。 いまはこれを数理的システム設計とよんでいます。まだαバージョンくらいです。

いままでも、これについては筑波で2度勉強会をしており、今回はAgile Tour Osaka 2019で講演してきました。

アジャイル システム設計 Meetup - connpass

システム設計ハンズオン勉強会 -リジェクトすえなみチャンス暑気払い- - connpass

Agile Tour Osaka 2019 × miniPLoP 2019年11月9日(大阪府) - こくちーずプロ

で、今回はたぶんはじめてスライドを公開しました。 スライドにある通りですが、基本的には僕の経験のみの話で、業界にたいする評価とかではありません。

speakerdeck.com

  1. アイディア、仮説、要求 と アーキテクチャ へのギャップがおおきく、それによってビジネスの可能性を小さくしてしまっていたり、技術進歩への追従がしにくくなっていたりする。
  2. 主観的に機能や仕様の配置をしてしまうことによって、システムの無駄がおおくなる。
  3. 機能に依存した設計をすると、変更によわくなる

おおまかにはこのへんの課題意識があって、これをかいけつするために、より要求などによりそいながらも、アーキテクチャとしてつくるものを想像しやすく、数理的な手法があればいいのではないだろうかという気持ちがうまれました。

そこで参考にしたのが、クリストファーアレグザンダーの The Nature of Order 15の幾何学的特性です。 建築をはじめとして、美しい設計というのは15の幾何学的特性をもっていると発見したというのが彼の主張です。

ということで、これによってシステムを設計してみようということで手法としてつくりあげたのが、この数理的システム設計です。

スライドにもあるようにたくさんの課題がありますが、ITをつかったシステムが巨大で複雑化していくなかで、よりアイディア、仮説、要求などと具象的な技術をつなぐ設計手法として大成できていけたらいいなとおもっています。

これに付随してさまざまな設計手法について勉強するようにもなったのもこの数年の成果かもしれません。

で、またこれのはなしをかるくさせてもらう機会をいただきました。

すえなみチャンス忘年会2019 本編 - connpass

数理的システム設計以外についてもシステム設計、アプリケーション設計についてはいくばくか詳しいつもりなので、登壇、研修、実務でのアーキテクト業などのご依頼もおまちしております。 kyon-mm.com

参考書籍

生命の現象

生命の現象

形の合成に関するノート/都市はツリーではない (SD選書)

形の合成に関するノート/都市はツリーではない (SD選書)

Clean Architecture 達人に学ぶソフトウェアの構造と設計 (アスキードワンゴ)

Clean Architecture 達人に学ぶソフトウェアの構造と設計 (アスキードワンゴ)

ソフトウェアシステムアーキテクチャ構築の原理 第2版

ソフトウェアシステムアーキテクチャ構築の原理 第2版

マイクロサービスアーキテクチャ

マイクロサービスアーキテクチャ

エンタープライズアプリケーションアーキテクチャパターン

エンタープライズアプリケーションアーキテクチャパターン

進化的アーキテクチャ ―絶え間ない変化を支える

進化的アーキテクチャ ―絶え間ない変化を支える

情報アーキテクチャ 第4版 ―見つけやすく理解しやすい情報設計

情報アーキテクチャ 第4版 ―見つけやすく理解しやすい情報設計

エンジニアのためのデザイン思考入門

エンジニアのためのデザイン思考入門

レゴスクラム研修を筑波技術大学の先生達に提供した話 #lego4scrum

個人事業主うさぎ組 kyon-mm.comでは、スクラムアジャイルの研修も仕事にしています。 今回はenPiT ビジネスシステムデザイン分野でずっと一緒にお仕事をしている、筑波技術大学 渡辺准教授の職場でスクラムを知ってもらうという目的で研修をしてきました。渡辺さんが声をかけてくださった先生方を対象にという感じです。 その様子を紹介します。

座学

私からアジャイルマニフェストスクラムガイド、アジャイルの各手法の関連などを整理して、概観を説明しました。 その後、参加者同士で座学の内容を振り返ってもらって質問を出してもらい、回答したり議論をしたり。 ここで想定以上の量の(しかも良質な)質問が出てきて、議論が盛り上がりました。 ほとんどの参加者がアジャイル開発の経験がないにも関わらず、なかなか鋭い質問があり、「本当にやったことないのかな。。。?」と思ってしまうほどでした。

レゴで街づくり

講師である私(プロダクトオーナー役)からレゴで作って欲しい街の情報を伝えて、あとは各チームで街を作ってもらいます。まずはどんな街にするのかを自分たちで考えて、見積もって、作ってみて、レビューして、やり方を振り返りして、とスクラムのスプリントを実践します。 今回の研修では3スプリント実施しました。

ペルソナについて議論したり、スプリント計画をしているときは各チームいろんな議論の仕方がありました。 f:id:kyon_mm:20190919151803j:plain

f:id:kyon_mm:20190919152122j:plain

f:id:kyon_mm:20190919152102j:plain

ユーザーストーリーマッピングを使いながら、バックログを作って優先順位をつけていき、受け入れ条件を考えていくのも実践してみます。 f:id:kyon_mm:20190919161941j:plain

チームごとに出来上がる街は最初は小さかったり、体験の設計が不足していたりしますが、どんどん良くなっていきます。お互いに「そういうのが得意なの?」なんて驚きもあったりして楽しそうでした。

f:id:kyon_mm:20190919164122j:plain

スプリント毎にプロダクト、自分たちの進め方をふりかえって、自分たちのうまくいっているところや、なんとかしたいなーっていうところを話し合い、自分たちでどうしていくのかを考えていきます。

f:id:kyon_mm:20190919165103j:plain

f:id:kyon_mm:20190919165042j:plain

3スプリントが終わったら1日のふりかえりをして終了です。研修が楽しかった話や、得た学び、今後自分たちはこれをどうやって活かしていくのかなど議論は尽きませんでした。 生徒たちのことを熱心に考えている先生方、尊いわ。。。

まとめ

レゴ®︎によるスクラムの研修をソフトウェア開発などを教えている筑波技術大学の先生方とやってみてわかったのは、何かを模索しながら誰かに何かを提供する、学びについて普段から考えているという人にとってはスクラムの考え方はマッチしやすいのかもしれないと改めて気づかされました。 普段はソフトウェア開発企業の方々にレゴスクラム研修を提供することが多いのですが、もっと違う業界の方にも提供できると良さそうだなぁと。 もしご興味ある方いらっしゃれば https://kyon-mm.comhttps://twitter.com/kyon_mm からご連絡いただければ!

あと、筑波はいいぞ!

チームはミッションのためだけではない。生き方そのものである。 #RSGT2020

Regional Scrum Gathering Tokyo 2020というカンファレンスのセッションは公募制で、私も発表してみたかったのでプロポーザルをだしました。 聞いてみたいかたはぜひ下のサイトでVoteしてもらえるとうれしいです。このプロポーザルにおいてどんな話をするつもりなのかをすこし紹介します。

confengine.com

www.youtube.com

1. セッション概要の引用

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

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

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

2. チームとはなんのためにあるのか

わたしが今まで読んできた書籍であるとか、発表であるとか、会話のなかでは、チームというのはミッションのためにつくられるものであり、そのため同じ目的をいかに共有するのか?という話に焦点があてられていました。 ほかにもチームとグループはちがうとか。ビジネスの世界ではそうだという話がおおくあるとおもっています。

では、プロジェクトがことなれば、ミッションが細分化されていれば、それはチームとはよべない。そういうことになります。そうしてチーム横断での仕事の仕方や組織作りになやむ。そうした日々をおくる。ありふれた風景におもえます。

我々基盤チームも事実上の解散になり、そうなるのかとおもっていました。 でも、我々は基盤チームで仕事をしていくことに誇りをもっており、そしてなによりこのメンバーと仕事をし、失敗も成功もかみしめ、成長をしていくその過程が楽しいとおもってこの5年間をすごしてきました。

ミッションがことなっていても、チームとして存続する方法を模索する。そんな挑戦をはじめました。

3. フラクタルスプリントのスケールアウト

我々がしっている古典的なチーム横断は2つです。横断組織をつくる。そして期間の長いタイミングもしくはアドホックなタイミングで情報の同期をつくる。 これをやっていてはおおきなチームとしては成立しない。基盤チームはこれをかえるために、プロジェクトがことなってもフラクタルスプリントをすることにしました。

なので、プロジェクトがことなるチーム同士で、15minスプリント、1Hourスプリント、1Dayスプリント、1Weekスプリントを実施しています。つまりフラクタルスプリントを複数チームにスケールアウトさせました。

f:id:kyon_mm:20190910223147j:plain
フラクタルスプリント

f:id:kyon_mm:20190910223248j:plain
フラクタルスプリントを複数チームで同期させながらおこなう

これによりミーティングの時間はのびたりのびなかったりしていますが、我々の経験上、目安時間からずれてしまうの修練上の誤差のようなものであり、メンバーは「いまは修練の時だ」という認識でただひたすらにこのスケールアウトされたフラクタルスプリントをいかに上手につかいこなすのかということをかんがえています。

4. 発表ではなすこと

おおくの組織でチーム同士をつうじた組織の成長、多層な学習、という課題があるとおもいます。事実わたしの仕事ではほとんどがこういった話題です。

まだ小さな事例ではありますが、複数プロジェクトにおいても同期されたスプリントを実行するとえられる効果。そしてこの手法の転用方法や展開についてをはなせるとおもいます。

また、この考え方の根本ともちかい進化心理学からみたアジャイル開発についても話をすることになります。 チームとはミッションのためだけにあるものとかんがえることが、可能性をせばめているときづいた話です。 言い換えれば、なぜ人間はチームを作りたがるのかということについて学術的な側面と、経験的な側面について話します。

アジャイル開発とスクラム~顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント

アジャイル開発とスクラム~顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント

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

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