チームはミッションのためだけではない。生き方そのものである。 #RSGT2020
Regional Scrum Gathering Tokyo 2020というカンファレンスのセッションは公募制で、私も発表してみたかったのでプロポーザルをだしました。 聞いてみたいかたはぜひ下のサイトでVoteしてもらえるとうれしいです。このプロポーザルにおいてどんな話をするつもりなのかをすこし紹介します。
1. セッション概要の引用
1つのチームが複数のプロジェクトに分裂したとき、そのチームはどうひきつがれるのでしょうか。おなじものにはならないし、それなりの成熟をするには時間がかかる。だから、チームはできるだけ解散してはならない。果たして本当にそうでしょうか?
私達のチームメンバーは複数のプロジェクトにわかれ、PBLもPOもまったく異なるようになりました。それでも1つのチームとして存在する方法を模索しました。その過程で、複数チーム、複数プロジェクトにおける15minスプリントを基盤とするフラクタルスプリント、組織横断な知識交換、プロジェクトに依存しないチームとしての存在意義を見出してきました。私達のチームは解散したようにみえましたが、実際には解散していなかったのです。フラクタルスプリントによってフラクタルチームは成されました。
異なるミッションをもっていても、組織としては軍隊アリやバッファローのような超個体をめざす1つのチームとして機能をするようにまでなりました。プロジェクトのためだけにチームがあるのではありません。わたしたちがいるからチームなのであるという視点をつきつめていき、それは個人や組織の成長にもつながっていく姿をお話します。
2. チームとはなんのためにあるのか
わたしが今まで読んできた書籍であるとか、発表であるとか、会話のなかでは、チームというのはミッションのためにつくられるものであり、そのため同じ目的をいかに共有するのか?という話に焦点があてられていました。 ほかにもチームとグループはちがうとか。ビジネスの世界ではそうだという話がおおくあるとおもっています。
では、プロジェクトがことなれば、ミッションが細分化されていれば、それはチームとはよべない。そういうことになります。そうしてチーム横断での仕事の仕方や組織作りになやむ。そうした日々をおくる。ありふれた風景におもえます。
我々基盤チームも事実上の解散になり、そうなるのかとおもっていました。 でも、我々は基盤チームで仕事をしていくことに誇りをもっており、そしてなによりこのメンバーと仕事をし、失敗も成功もかみしめ、成長をしていくその過程が楽しいとおもってこの5年間をすごしてきました。
ミッションがことなっていても、チームとして存続する方法を模索する。そんな挑戦をはじめました。
3. フラクタルスプリントのスケールアウト
我々がしっている古典的なチーム横断は2つです。横断組織をつくる。そして期間の長いタイミングもしくはアドホックなタイミングで情報の同期をつくる。 これをやっていてはおおきなチームとしては成立しない。基盤チームはこれをかえるために、プロジェクトがことなってもフラクタルスプリントをすることにしました。
なので、プロジェクトがことなるチーム同士で、15minスプリント、1Hourスプリント、1Dayスプリント、1Weekスプリントを実施しています。つまりフラクタルスプリントを複数チームにスケールアウトさせました。
これによりミーティングの時間はのびたりのびなかったりしていますが、我々の経験上、目安時間からずれてしまうの修練上の誤差のようなものであり、メンバーは「いまは修練の時だ」という認識でただひたすらにこのスケールアウトされたフラクタルスプリントをいかに上手につかいこなすのかということをかんがえています。
4. 発表ではなすこと
おおくの組織でチーム同士をつうじた組織の成長、多層な学習、という課題があるとおもいます。事実わたしの仕事ではほとんどがこういった話題です。
まだ小さな事例ではありますが、複数プロジェクトにおいても同期されたスプリントを実行するとえられる効果。そしてこの手法の転用方法や展開についてをはなせるとおもいます。
また、この考え方の根本ともちかい進化心理学からみたアジャイル開発についても話をすることになります。 チームとはミッションのためだけにあるものとかんがえることが、可能性をせばめているときづいた話です。 言い換えれば、なぜ人間はチームを作りたがるのかということについて学術的な側面と、経験的な側面について話します。
アジャイル開発とスクラム~顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント
- 作者: 平鍋健児,野中郁次郎
- 出版社/メーカー: 翔泳社
- 発売日: 2013/01/18
- メディア: 単行本(ソフトカバー)
- 購入: 1人 クリック: 12回
- この商品を含むブログ (21件) を見る
- 作者: ロビン・ハンソン,ケヴィン・シムラー,大槻敦子
- 出版社/メーカー: 原書房
- 発売日: 2019/02/27
- メディア: 単行本
- この商品を含むブログを見る
Re: モッククラス、下から見るか?横から見るか?
先日Twitterでリプライがきたのでみてみたら素晴らしいブログ( モッククラス、下から見るか?横から見るか? )がありました。
プログラムにおける自動単体テストでモックをつかうべきかどうか悩んでいるというもの。
私なりにこれに回答しようとおもいます。みんなもなにかおもうところがあれば、SNSではなくブログにしてほしい。(Webからそのままアクセスできるという点において)
- 1. 基本方針
- 2. 仕様化テスト、レガシーコード改善、リファクタリングでつかう
- 3. トランザクションのcloseなどの後処理を確実に検知する。Rxや一部の書き方によってtry-with-resourcesがつかえなくても。
1. 基本方針
- 可能なかぎりモックライブラリはつかわず、コンストラクタDI(Dependency Injection)で解決できるならそうする
- 往々にして厳密な単体テスト(1ファイルにとじたテスト)はしておらずコンポーネントテスト(複数ファイルにまたがったテスト)がおおい
2. 仕様化テスト、レガシーコード改善、リファクタリングでつかう
自動化されたテストがなく、これからリファクタリングをしたいというときには、既存のプロダクトコードを変更せずに自動テストを実装すべきです。そのときには時刻やDBやAPIなどに依存したコードをテストしなければいけないでしょう。
テスタビリティの低い設計ではこれらを「テストから設定」することがむずかしかったり、高速な単体テストとすることがむずかしかったりします。そのときには、モックライブラリをつかって時刻やDBやAPIなどをテストダブル(スタブやモック)におきかえます。
モックライブラリは実質的にリフレクションなどをつかっているものがおおく、プロダクトコードを変更せずにプログラマーが自由なコードで一部の処理を代替させることができます。これによって自動テストを実行できるようにしてから、徐々にリファクタリングをすすめていく。という場面ではモックライブラリが適切でしょう。
3. トランザクションのcloseなどの後処理を確実に検知する。Rxや一部の書き方によってtry-with-resourcesがつかえなくても。
たとえばトランザクションやコネクションのコミットやクローズ処理が確実にされているかを検知したい場合につかえます。 単体テストのメリットとして、IO処理が失敗した場合を簡単に模倣できるという点があります。それ自体はコンストラクタDIな設計における簡易なテスト用のスタブクラスでもできます。
ですが、たとえばDB操作が失敗したときに必ずコネクションがcloseされていることのテストはなかなか検知できません。モックライブラリであればできます。 もちろん静的コード解析でも対応できる部分はありますので、一概にモックライブラリでやるべきとはいいませんが、なかなかに便利なときがあります。
Javaだとtry-with-resourcesとかでかいておけばいいじゃんというのもありますが、rx系というかpromise系というかのライブラリをつかっていたり、いくつかの設計においてはtry-with-resourcesをうまくつかえないことがあります。そのときには、モックライブラリで検知させるというのは妥当だとかんがえています。
実践テスト駆動開発 (Object Oriented SELECTION)
- 作者: Steve Freeman,Nat Pryce,和智右桂,高木正弘
- 出版社/メーカー: 翔泳社
- 発売日: 2012/09/14
- メディア: 大型本
- 購入: 4人 クリック: 262回
- この商品を含むブログ (31件) を見る
- 作者: Kent Beck,和田卓人
- 出版社/メーカー: オーム社
- 発売日: 2017/10/14
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (1件) を見る
- 作者: Joshua Bloch,柴田芳樹
- 出版社/メーカー: 丸善出版
- 発売日: 2018/10/30
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (2件) を見る
スクラムフェス大阪で基調公演。もしくはJASRACへの支払い #scrumosaka #agileradio
2/22 - 2/23 に開催されたスクラムフェス大阪にてKeynoteを担当させていただきました。 @TAKAKING22 くんと一緒に壇上に上がる日がこうやってくるとはおもってもみませんでした。 テックカンファレンスで世界初「オープニングムービー + 入場曲 + ジャズピアノ生演奏 + メイキング映像 + アンコール + キーノートタイトル参加者で議論」という構成でおとどけしました。(要出典)
本エントリでは、なぜこうできたのかの一部、また、日本で楽曲を使用するときに課題になる JASRACへの対応方法をのこしておきます。
なぜこの構成にできたのか
この辺の大枠は先日出演させていただいた #agileradio にて軽くはなさせてもらいました。
Scrum Fest Osaka 2019 トーク その1 | アジャイルラジオ
簡単にまとめると次の流れでした
- 大切にしたいことは 2018/12に @TAKAKING22 と きょんで決定
- アイディアを RSGT2019 の OSTの1セッションで議論
- OSTにて「アンパンマン」「生演奏」「脇役としてのキーノート」というアイディアがかたまる
- 2日後の1/14 に企画提案、プランニング
- 以後怒涛のプレゼンテーション、編曲、練習、動画編集、構成をねりなおすの制作1ヶ月をすごす
いやー、本当にたのしかったです。 アーティスト活動のさわりをやったのかなっておもうんですが、たしかにこれはたのしい。 バンド活動していたり、絵をかいたりする人達の気持ちがすこしだけわかりました。すごいな。
これは結果であって、なぜこうできたのかという話ですね。僕の中ではだいたい次の要素が強かったなと。
- @TAKAKING22 と きょんが大枠で信頼しあえる仲であった
- @TAKAKING22 がプロレスやアイドルという「エンターテイメント」を好きでありよく見ている
- ジャズピアニストがきょんが所属する基盤チームにいた
- きょんの夢がエンジニアで東京ドーム公演であった
- きょんが昔、ニコニコ動画でアンパンマンのジャズアレンジを聞いたことがあり感動していた
- @TAKAKING22 や きょんを信頼してくれる仲間がいた
どの要素も重要だったのかなーとおもいました。どれかが欠けてもこの構成にはならなかったのではないだろうか。 そしてこの企画をうけいれてくれた 運営および参加者に感謝しています。
楽曲の使用。JASRAC
生演奏するということで、JASRACとのつきあいが必要になりました。 先日料金をおさめたので、そこまでの流れは次のとおりです。
- 会場がJASRACと契約しているかを調べる
- 会場の定員数、チケット代、利用する楽曲のJASRAC登録されているか検索、利用するときの長さを確定する
- オンラインで見積もりをしてみる
- 開催5日前までに申請書を書いて会場最寄りのJASRAC支社に郵送する
- 後日電話で詳細の確認がくる
- 請求書が送付される
- 振り込みをして完了
大学とかで開催する場合でも、きっと音楽教室みたいなところはJASRACと包括契約している場合があるかとおもいます。一般的にはライブハウスとかです。 今回の会場はどうも契約していないのではないかということだったので、2にすすみました。 基本は会場の定員数で料金がきまります。利用するときの長さはメロディをどれくらい演奏するかです。今回のわたしたちの構成はメロディ部分はすくなかったので料金をおさえられました。 楽曲はこちらから検索できます。
見積もりはこちらでできます。
これでだいたいの料金がわかるとおもいます。 ちなみに私は「ファッションショー」みたいなもので見積もりをしました。
ここからは郵送してうんぬんです。公式に手続きの流れがあるのでリンクを。
スクラムフェス大阪は会場が大阪だったので大阪支社に郵送しました。 そうすると後日、イベントの概要とかいろんなことを電話で5minくらい確認してくれます。そりゃIT系のカンファレンスで生演奏してとかわけわからんですよね。。。
で、後日請求書がとどくので振込みをします。 こんな封筒です。
まとめ
最&高なプレゼンテーションのありかたを模索していきたい。大切な1歩をふみださせてくれたみなさまありがとうございました。 どのような形になるかはわからないけれど、ご依頼うけつけております。一緒につくりだせたらとおもいます。
Special Thanks
それ1ピクセルずれてない? ってわかるのか試してみた
Regional Scrum Gathering Tokyo 2019 というカンファレンスで @ryuzee さんとはなしているときに、
Webサイトみていると、これなんか1ピクセルくらいズレているってすぐわかるよねー。きになる。
と言っていました。わたしもたまにWebサイトつくることにかかわるけれども、(要求されている品質の都合上)なんとなくでやっていることもままあって、厳密に綺麗にしようみたくするのはあんまり経験がないなーと。
で、自分でつくるかどうかはおいといて、まず「それ1ピクセルずれてない?」って自分で判断できるのかためしてみようとおもいました。
Do you think you’ve got a designer’s eye?
次のWebサイトで簡単なテストをできました。
https://www.supremo.co.uk/designers-eye/
クリックすると次のような画面がでてきて、「このドットは中心ですか?」にYesなら左、Noなら右をクリックしていくかんじです。 10問連続で正解すればクリア。
結果、私は2回目くらいでクリアしました。 1回目では三角形の中心がうまくわからず失敗しました。
これだけでWebサイト全般ってわけじゃないけど、Webサイトつくる初心者の人に中心ってわかるー? みたいなノリで研修のアイスブレイクとかにやるのはいいかもなーっておもいました。
ある改善、プラクティスやTryをいつやめるのか。もしくは5000枚のKPTの理由。 #scrumosaka #rsgt2019
先日、 Scrum Fest Osaka 2019というカンファレンスでとある方からこんな質問をうけました。
きょんさんのチームでは、何度かやればうまくいきそうなTryとかプラクティスがあるときに、いつまで挑戦するとか、いつになったらやめるとかそういった基準とかはありますか?
これ聞かれたときに昔の自分だったら「やれなくなるまでは挑戦しつづける」って答えていたとおもうんですよね。でも、今は違うなーと。 僕が答えたのは「やりたい意思がある限り続ける。やりたくないものをやるのは楽しくない。」で、もっと端的にいうと
というものです。ある種の適者生存というか。プラクティスが正しいから残るのではないというかんじですかね。 ただ、それだと怠惰でルールのないチームは一向に成長しないので、成長するための仕掛けは必要だとはおもいます。 でもそのときに、ただ問題を解決するためにプラクティスをいれることでは定着しないんだろうなーというのが自分の感覚です。 毎日のように徹底された食生活管理と運動を納得してもできないこともあるし。
まだうまくまとめられないんですが、感覚的には「問題を解決する方向と、自分が楽しめる方向が同じ方向をむいている」ってことかなーっておもいます。 で、過去の自分もそうでしたが、「人を問題に寄せる」のはビジネスなんだから当然のようにできるっておもってしまって、いろんなところでヘイトがたまる。。。 いまの基盤チームはそれは時間がかかるのが普通なので、15min毎にとても小さな量のいい事にもわるい事にも触れ続けることで、人を問題に寄せる、問題と一体となるくらいに考えられるような場にしていくことをやるようになりました。それが大量の付箋となっている KPT as ARTなやつです。 Scrum Fest Osaka にておおまかには bleisさんとdico_lequeさんが話してくれました。
Scrum Fest Osaka 2019 - 感謝のKPT 5000枚 -基盤チームのレトロスペクティブ- | ConfEngine - Conference Platform
KPT as ART になった理由。ふりかえりへのむきあいかた。
わたしからはこれの経緯とか語られなかった部分を。
これも最初からうまくいったかというと、チーム内でいろんな意見もありましたが、わたしはこれがうまくいくと信じていたし、いろんな議論をへて今の形になりました。チーム内であったのは「情報がたくさんあって整理できない」というものでした。これはいわゆるKPTとは情報を整理し、問題や改善案を具象化する行為だと考えていれば当然だとおもいます。でも、私がおもうにそれは長期間存在するチームには無理だということです。おおくの人はかしこいというか、かしこくないので、具象化できる課題はすぐに尽きます。いいかえると、適切な具象化をあまりできません。
人間はあまり賢くないので整理するため具象化するためのKPTというのはすぐに限界をむかえます。これがKPTがうまくいかない根本だと私は考えています。
1週間に1度できないKPTにむかいあうよりも、具象化するための材料となる量を増やしていき、文字通りその情報にかこまれることで、なんとなく自分達の状況が心にうかびあがってくる。そういったスタイルが長期間存続させるチームには最適だと。
ので、ふりかえりででるような情報は整理しながら増やしていくのではなく、好きなときに整理する、どちらかというと、整理できる状況になったら自然とされる、というのがいいのだろうと。エンジニアというのもあって、とかく情報を整理したがる性質からの脱却に時間がかかったメンバーもいましたが、それもふくめてゆっくりと慣れていきました。
これに似たこととして、チームの外から「この付箋を見返すことなんてできないから意味ないでしょ」とかいわれます。これも結局は上と一緒で、KPTとは整理してチームの道標となるべきものであるという考えからだとおもいます。私達はそういうことをこのKPTでやりたいわけじゃないので、別にそういった必要はないという回答になります。
では、基盤チームは自分達が向かうべき場所についてはどのように話しあい、どのようにそれがのこり、どのようにいまかかえている問題がのこるのか。 基本的には会話でなされていて、それがテキストとしてはKPTにのこります。でもその付箋を見返すことはないですね。 チーム内で濃密に会話したときの体験のほうが付箋に貼られるよりずっと記憶にのこり、そして信頼関係を築くためにはずっと大切だと、そう実感しているからです。 そしてまた、私が基盤チームの考えをプレゼンテーションにしていき、みんなの意思がまた1つかたまる。そういったサイクルをこの4年間続けてきた。といったかたちです。
ちょっと長くなってきたので、基盤チームの話はこのへんで。 続きとか、他の話気になるー!って人は、飲みにさそったり、お仕事のご依頼おまちしております。(あ kyon-mm.com
#RSGT2019 の歩き方
はじめてRSGT2019に参加する人、もっとたのしみたい人などたくさんいるとおもいます。ということで、RSGT2016 - 2018まで参加してきた身としての歩き方を紹介します。
本エントリは 「Regional Scrum Gathering Tokyo Advent Calendar 2018」(非公式)26日目の記事です。(は?) adventar.org
- まず会場近くに宿泊しよう
- 基調講演はきいて損がない
- ランチでは隣の人に声をかける or さっさと食べてホワイエ(ホール外)でドリンクをのみながら声をかける
- ランチ後の講演はどれか2,3つ聞いて、それ以外はホワイエ(ホール外)でスピーカーをつかまえる or 休憩する
- 初日のネットワーキングパーティではここまで話した人をつかまえよう or 気になる人に声をかけよう
- 2日目もほぼ同様でOK
- 3日目のOSTは聞きたいトピックにまず参加
- まとめ
まず会場近くに宿泊しよう
会場は大崎ブライトコアホールです。平日開催で朝から & 毎日(任意で)飲み会がある ことから会場近くに宿泊することをオススメします。徒歩20min圏内くらいを考えると、大崎や五反田でしょうか。五反田はそこそこホテルがあります。
朝の通勤ラッシュにもまれて体力をうばわれると、RSGTでは体力が保ちません。万全でのぞんでいきましょう。
基調講演はきいて損がない
どんな基調講演でもいいところ、わるいところそれぞれあります。それでも基調講演は価値が高いのです。とにかく聞きましょう。あきたら退室して、スポンサーブースの人に声をかけましょう。
- なにかしらインパクトがある話をする(なんらかの新規性がある、規模が大きい、トレンドをまとめている、レジェンド的存在)
- RSGT参加者のうち、おおくの人が聞いているので参加者同士での会話のキッカケにつかえる
ランチでは隣の人に声をかける or さっさと食べてホワイエ(ホール外)でドリンクをのみながら声をかける
おそらく今回もランチはお弁当がでて、(任意で)ホールで食べることになります。この場で声をかけてみましょう。話しかけるの苦手な人は次をまず言えば大丈夫です。
- 何度か参加したことあるんですか? 私はn回目なんですけど。
- さっきの基調講演ききました? 私はxxxのトピックいいなっておもいました。どんなところ気になりました?
- 今日はこのあとどの講演聞くか決めているんですか?
- Scrumやっていますか?
これでだいたい5minはもちます。話好きな人だったら30minくらいもつんじゃないですかね。
ランチ後の講演はどれか2,3つ聞いて、それ以外はホワイエ(ホール外)でスピーカーをつかまえる or 休憩する
1日ずっとすわって聞いているとそれだけで疲れます。できるだけダラっとする時間をとりましょう。 ホワイエにでたら、(まだ講演していないスピーカーも含めて)なんにんかのスピーカーがだいたいいます。気になるスピーカーがいたら、積極的に声をかけましょう。
- 次にどのセッション聞くか決めているんですか?
- (決まっていないといわれたら) 今回の講演をしようとおもったキッカケってなになんですか?
- (決まっているといわれたら) その講演のどのへんが気になるんですか?
スピーカーは話したがりの人がおおいので、声さえかければ、勝手に話してくれます。楽ですね。
初日のネットワーキングパーティではここまで話した人をつかまえよう or 気になる人に声をかけよう
例年どおりであれば、ホワイエで立食パーティになります。とりあえずドリンクとか軽食とかに並ぶことになるとおもいます。 並んでいるときは隣の人に声をかけてみましょう。また、ここまでで声をかけた人をみつけてみるといいとおもいます。 だいたい聞くことは次で大丈夫です。
- 今日はどの講演がたのしかったですか?
- 私はxxxの講演がたのしかったです。yyyなところとか。
- 明日はどの講演を聞く予定なんですか?
- RSGTにはなぜ参加したんですか?
2日目もほぼ同様でOK
基本的な流れは一緒なので↑のとおりで大丈夫です。ちがうのは、ネットワーキングパーティがないことくらいでしょうか。 ちょっと食事してから帰りたいなーっていうときには、「今日おわったら一緒にどこかいきませんか?」といってみましょう。そんなんハードルたかい!とおもわれるときには、スピーカーにいってみましょう。そう、かれらは話したがりです。(万が一、断われてもそんなに落ち込まないでね!)
3日目のOSTは聞きたいトピックにまず参加
3日目はOpen Space Technologyといって、最初の30min程度で、参加者が議論したいことを自由にタイムテーブルにいれていき、時間になったら自分達で議論がはじまるスタイルです。もし話したいトピックがあればその場で出しましょう!なければとりあえず雰囲気をみながら参加で大丈夫です。
OSTでの議論は正解や不正解などはなく、その場にいる全員が参加すべきメンバーがあつまっているというリスペクトをまもってすすめるものです。初心者だったとして、自分がいてもいいのかとか、発言が貧困なのではないかとか、悩む必要はありません。
まとめ
RSGT2019の歩き方を紹介しました。ここまで書いといてあれですけど、どのカンファレンスでもこれでいい気がしている。
この記事を書くキッカケをくれた id:ayumi_h ありがとう
とても良記事ばかりで、25日までではなく年末まであったらいいのにな、という気分です。
- 作者: 西村直人,永瀬美穂,吉羽龍太郎
- 出版社/メーカー: 翔泳社
- 発売日: 2013/02/13
- メディア: 単行本(ソフトカバー)
- 購入: 5人 クリック: 13回
- この商品を含むブログ (33件) を見る
- 作者: ジェフ・サザーランド,石垣賀子
- 出版社/メーカー: 早川書房
- 発売日: 2015/06/24
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (3件) を見る
スクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本-
- 作者: Mitch Lacey,安井力,近藤寛喜,原田騎郎
- 出版社/メーカー: マイナビ出版
- 発売日: 2016/02/27
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (2件) を見る
エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド (Object Oriented Selection)
- 作者: Kenneth Rubin,岡澤裕二,角征典,高木正弘,和智右桂
- 出版社/メーカー: 翔泳社
- 発売日: 2014/07/08
- メディア: 大型本
- この商品を含むブログ (7件) を見る
- 作者: Rachel Davies,Liz Sedley,永瀬美穂,角征典
- 出版社/メーカー: オーム社
- 発売日: 2017/01/21
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (1件) を見る