tuneの日記

アジャイル開発、組織変革、ファシリテーションについて学んだことの記録

LeSS Study LeSS本読書会 第6回

LeSS Study LeSS本読書会 第6回

LeSS Study LeSS本読書会 第6回 - Less Study | Doorkeeper

今回は新宿、グロースエクスパートナーズ株式会社 イベントスペース「G's LounGe」での開催でした。

Q: LeSS Hugeでエリアを分ける背景の説明に「チームが集中力を失う」とあるが、エリアを分けないLeSSでも起きうる問題なのでは?

A: 起きうる問題だが、結局誰もがやらなくてはならず問題になりにくいのかも。または プロダクトが小さいうちはエリアも小さく、少しは耐えられるという想定があるのではないか。

Q: LeSS Hugeを導入している会社・組織はある?

A: 海外ではあるようですが、勉強会参加者の知る限り国内ではなさそうです。 日本でLeSSを導入していると公言している会社ですとYahooやGROOVE Xが挙がりましたが、LeSS Hugeに取り組んでいるという話は聞いたことがないとなりました。

Q: マイクロサービスとLeSSの相性はどうなのか?

A: マイクロサービスごとにチームを構成していなければ両者は矛盾していない。

マイクロサービスは設計・アーキテクチャの話、スクラム・LeSSはプロセスの話。 責務をシンプルにしたサービスにすることでサービスを増やしたり・作り直したり簡単にできるようになるのがマイクロサービスのメリット。 スクラム・LeSSは多能工化したチームによって、フロー効率改善が期待できるメリットがある。

Q: コンポーネントとフィーチャーの違いがわかりにくい。予約はどちらか。

ものによりそう。

  • ホテル予約システム→フィーチャーではないか
  • カレンダーの会議予約システム→コンポーネントっぽい

単独で利益があげられたり、顧客価値が訴求できるならば独立したプロダクトであり、フィーチャーになるのではないか。

Q: チームで多能工化を目指すが、現実には専門家思考の人もいる。チームに加える時に考慮している事項はあるか?

特に何もない。尖った能力を持つ人もうまく組み合わせてクロスファンクショナルなチームを構成する。 仕事の配分はチームでやりくりしてもらう。

とはいえ、圧倒的な専門性を持つ人がチームで能力を発揮できないケースもあるので、その場合はチームから外して別の仕事を与えることも考える。

Q: うちのチームは顧客と会いたがらないのですが…

A: 組織が顧客に会わせる目的を「仕様を明確化して文書を作成する人」としか扱っていないのではないか?

または顧客のことを理解する手助けを組織として提供していないのではないか?

Q: 典型的なLeSS Huge組織において、スクラムマスターはどこにいるのか?

A: フィーチャーチームにいる。

書籍の例では教育・コーチングチームがあるが、ここに所属している場合もあるかもしれない。 能力の高いスクラムマスターや、外部コーチがここに入るのかも。

書籍の「典型的なLeSS Huge組織」はガイドであって、「こういう組織にしなければならない」というものではないので、自分の組織・メンバ能力にあったやり方を見つけていけば良い。

Q: 自己管理チームとはなにか?

https://less.works/img/management/xtypes_of_teams.png.pagespeed.ic.3OY-9MF31j.png

A: 上図の左から2番目。

  • マネージャー主導チーム
  • 自己管理チーム←LeSSはここ、スクラムもここ
  • 自己設計チーム←外部に働きかけができて、組織変革ができるチームのこと。
  • 自己統治チーム←アジャイルスクラムの対象外、取締役会とか。

Q: システム思考とはなにか?

A: 因果関係を整理したシステムとして事象を捉え、俯瞰した視点で問題解決にあたる考え方。 ロジックツリーでも問題分析ができるが、個別の問題だけを解決しても実際には要因間に因果関係があるので本当に解決できるとは限らないという考えに立っている。

枝廣 淳子さん、小田 理一郎さんが翻訳・監修で入っている本がおすすめ。

学習する組織――システム思考で未来を創造する

学習する組織――システム思考で未来を創造する

「学習する組織」入門――自分・チーム・会社が変わる 持続的成長の技術と実践

「学習する組織」入門――自分・チーム・会社が変わる 持続的成長の技術と実践

世界はシステムで動く ―― いま起きていることの本質をつかむ考え方

世界はシステムで動く ―― いま起きていることの本質をつかむ考え方

勉強会時に参考にしたブログ


大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法

大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法

アジャイル・スクラムとHR・採用を組み合わせた用語の整理

アジャイルHR」とか「スクラム人事」とか、アジャイルソフトウェア開発から離れたアジャイルスクラムを冠する用語をよく聞くようになったので整理のためにまとめてみました。

アジャイルHR / アジャイル人事

ハーバードビジネスレビューでも特集が組まれたことのある用語。日本だけでなく世界でも使われている。


www.nikkei.com

従来の人事管理は任務遂行を重視しがちだが、アジャイルな人事管理は専門知識の育成、コラボレーションと迅速な意思決定に重点を置いている。マネジャーは、コーチングに優れているサーバントリーダーとして位置づけられる。 そのほか、(1)従業員に絶えず学びの場を提供する(2)従業員は絶え間なくフィードバックを受ける(3)成功指数は従業員の満足度と定着率、イノベーションを生み出しているかで決まる――などがアジャイルな人事管理の特徴だ。

「ソフトウェア開発で先行していた組織をアジャイルにする仕組みづくりを人事で取り入れていく動き」と考えて良さそう。

スクラム採用

herp.cloud

株式会社HERPが提唱する概念で日本だけの用語と思われる。 "scrum recruitment"でGoogle検索しても言及しているサイトは見当たらない。

この言葉は、チーム開発の手法としてインターネット系企業で広く取り入れられている、スクラム開発と同様に、共通のゴール(採用目標の達成)のために、全社員が一丸となって採用活動に取り組むことを意図して、弊社がネーミングしたものです。そしてスクラム開発の思想である、経験に基づくアプローチをベースに、現れた課題に柔軟に対応していくことを基本原則とする点も、同様にスクラム採用に欠かせないポイントだと考えています。

medium.com

ソフトウェア開発のスクラムを参考にしたようだが、「スクラムを使って人事・採用を改善する」ではない。

下記3つがスクラム採用のポイントらしい。

  1. 権限移譲
  2. 成果の可視化
  3. 採用担当のPM化

アジャイル開発・スクラムのプラクティスを使ったバックオフィス・採用の改善

アジャイルソフトウェア開発フレームワークスクラムそのもの、またはその中のプラクティスを活用してバックオフィス・採用の改善するアプローチ。ヴァル研究所とガイアックスの事例をよく聞くが、他の会社でも実は取り組んでいるのかもしれない。

www.slideshare.net

speakerdeck.com

qiita.com

speakerdeck.com

seleck.cc

Butterfly Effect #1 に行ってきました

www.youtube.com

Butterfly Effectとは?

「すごい人が話を聞きたい人の話はすごいはず」 という発想で、毎回違ったゲストを呼んでパネルディスカッションをするというイベント。

の1回目に行ってきました。ブログ枠での参加でしたので、楽しかった記録を書き留めておきます。 笑っていいとも!のテレフォンショッキングを模した構成になっており、初回ゲストは最近チーム転職で話題となった及部さんでした。

以下当日のレポートです。

聴衆のヒアリング

f:id:tune:20190709223929j:plain
入場直後のシーン、ライガーのマスクつき

今日はプロレスとのことでマスクをかぶった入場でした。

f:id:tune:20190709223936j:plain
Mentimatorを使った来場者の興味の可視化

はじめにSlidoを使った来場者のヒアリングがありました。

ざっくりまとめるとこんな属性の方々が集まったようです。

  • エンジニアが多い
  • 及部さんを知らない人は8人
  • 転職話を聞きたい人が多い

及部さんの自己紹介

  • 楽天に新卒入社→デンソー MaaS開発部に今月転職
  • アジャイル開発・チーム開発の文脈で登壇したり、モブプロの解説などを執筆したりしている。

なぜ今日はプロレスだと思ってきたかというと、攻めと受けがあるからだそうです。いい話を聞いて、いい質問をしてほしい。

  • 受け:聞く:インプット
  • 攻め:話す:アウトプット

パネルディスカッション

f:id:tune:20190709223945j:plain
パネルディスカッションのお題

Sli.doの方が多かった気がしますが、こんなものも用意されれていました。


Q: 転職の経緯は?

A: 仕事の切れ目が2019年4月にあった。 面白そうだなと思って社内外含めて提案を投げてみた。 結果チーム転職できた。


Q: 転職の理由は?

A: 前の会社が嫌で転職したわけではない。人事のヒアリングにもそう答えた。 面白そうなオファーをもらった & 10年でちょうど良い区切りだと思った。


Q: どのくらいオファーきた

A: 数は覚えていないがカンバンで管理していた。TODO / DOING / DONE / PRAY(お祈りorz) チーム転職をGithubで書いていたので、Issueを作ってオファーしてくる会社もあった。


Q: 決め手は?

A: 一番読めなくて、公表したときに面白そうな所を選んだ。裏ではチームで相談している。 及部さんが愛知県出身なのでデンソーのことは以前から知っていた。


Q: チームで企業という考えは?

A: チーム内で熱い想い・プロダクトオーナーシップを持っている人がいたらやったかも。今回は誰かと組んでやりたかった。


やめるときに全社にメールを送ったら面識のない人から「楽しそうにやっているなと思っていました」と返信があった。 何でも楽しもうとしている。

楽しい・楽しくないの2択だと批評家のようになってしまう。 「楽しむ」だと自分でなんとかする余地が生まれ、なんでも楽しめるようになるのでは。


Q: やばい上司の対処法がある?

A: 上司に遠慮はしていない。1on1で上司の相談に乗る。

初めての上司と会うときは理想の上司・部下の関係を考えて、入り方に気をつける。 自分が上司の下に入ろうとすると、上司も上からなんとかしようとしないか。 対等にコミュニケーションを取ったほうが良い関係が築ける。


Q: 今日はなぜ獣神サンダー・ライガーなのか?

A: 今年はライガー推し、来年引退するから。


f:id:tune:20190709223950j:plain
チームメンバによる及部さん評価

Q: チームメンバーに及部さんを評価してほしい。

A: チームに被害が出ないようにマネージャーとしてうまくやってくれていた。一緒に仕事しやすい環境を作ってくれる。


Q: 目標としている人は?

A: たくさんいる。尖ったスキルを持つ人をそれぞれ評価して学びたいと思っている。 あとはプロレスラーの棚橋弘至。何かを長く支えている人は自分にない部分だと感じて尊敬している。


Q: いいPOの定義は?

A: あるプロダクトのことが大好きな人と仕事をしたときは背中を預けるような働き方ができてよかった。


Q: マネージャーとしてのファイアウォール

A: リファクタリングに近い。上司とのコミュニケーションパスを疎結合にする。


Q: 上司からのマウンティングはなかったのか?

A: された経験あり。やられたらやり返すw 2〜3年目に「やめてもいいや」と思うようになり、そこから色々やり始めることができた。ダメなら転職しようと。 何かの発表で社長いじりをしたことがあったが、意外と何もなかった。壁を作っているのは自分なのではないか。


Q: 男性の育児休暇

A: 育児は仕事の比じゃないほど不確実性がある。割り込みが多い。育児は3時間スプリントでスプリント期間が毎回変わる。


Q: 及部さんの1日/休日の過ごし方

A: 家事が多い。平日できないので。あと筋トレ。


Q: アジャイルリーダーサミットで敢て否定したアジャイルラクティス

A: モブプロを初めて作業分担が当たり前だと思っていた先入観が壊れた。今の当たり前ももっと良いやり方があるかもしれない。 チーム固定化 → 気軽にいいチームが作れたらもっと良いよね。 普段からいいと思っているものを挙げ、斜に構えて批評するやり方は取り入れてみてもいいかもしれない。

型を学ぶとそれが良いと思ってしまうことがよくある。 もっと改善する、もっと上を目指すということを忘れてしまう。


Q: 一番楽しかったこと、これから楽しみなこと。

A: MaaS、自動運転の世界をなんとかしてやりたい。


次回のゲスト

f:id:tune:20190709223955j:plain
名古屋からの中継で参加されたkyon_mmさん

ライバルでもあり、友達でもある。@kyon_mmさんだそうです。

感想

今年の頭ぐらいから勉強会の立ち上げを色々と悩まれて準備されていたのだなと感じる会でした。 次回はこれから調整とのことですが、ここから始まった輪が予想外の広がりを持っていくと良いですね。

「スクラム現場ガイド」を読みました

スクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本-

スクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本-

私がスクラム開発を始めて3年弱。この本は「1年目にスクラムアジャイルで『どんなことが起きるか』についての本」との位置付けですが、会社でこれからスクラムを学んでいこうとする仲間にオススメする前に自分でも読んでみました。

大半のエピソードは自分でも体験したり、よその事例で聞いたことがあるものでしたが、それでも心に残るものがありました。ある程度スクラム開発を経験した人なら誰でも学びがある、オススメの本です。

以下私の印象に残ったエピソードのご紹介です。

2章 仲間とともに旅立つには

アジャイル開発を知り、新プロジェクトでスクラムを取り入れようとした主人公が上司のバックアップは得たものの、仲間探しに苦労する話でした。上司は主人公の支援は約束したものの、チームメンバは主人公が自ら集めることと伝えます。読んでいて「なんでメンバーをアサインしてあげないのかな」と思いましたが、「新しい取り組み・変化に前向きな人を集めないとうまく行かないからだろうな」と、当初は思っていました。

主人公は休暇中にアジャイル開発に関する書籍を読み漁って知識を得たことになっていますが、誘ったメンバには即座の参加を要求していました。これに対して上司が主人公がアジャイル開発を受け入れるように変わっただけの時間が他のメンバにも必要だと諭します。実際のプロジェクトではスムーズな立ち上がりを目指すあまり、「やりながら良さを勉強してよ」というアプローチを取りがちですが、きちんと理解するだけの猶予と用意を与えることは大事だよなと感じました。

21章 文化の衝突

すでにスクラム開発が軌道に乗っているチームに、リソース増強のためチーム文化に合わないメンバーがアサインされるとう話でした。チームは新メンバーを頑張って受け入れようと対話を重ねたものの、新メンバーはスクラムのやり方をどうしても受け入れず、最終的にスクラムマスタはメンバーをチームから隔離し仕事を与えず、元のメンバだけでプロジェクトを進める決断をします。

プロジェクト終了後に上司から呼び出しを受けた主人公は追加リソースを活用してプロジェクトを進めなかったことについて叱責されますが、プロジェクトの完遂をリスクに晒してまで仕事を作ってやるべきだったのかと逆に反論します。スクラムに後ろ向きなメンバがいつまでもチームに残るのは、現実でも割とよく直面する悩みだと思います。

29章 巨大なバックログの見積もりと優先順位付け

スクラム開発をこれから始めようとするプロジェクトが巨大なバックログの作成まではこぎつけたものの、優先順位づけも見積もりもどこから手をつけて良いか分からず途方にくれるという話でした。これに対して経験豊富なコーチが以下の手法を提案します。

  1. 広く壁を使える場所を確保する
  2. チームにバックログの項目を5つずつ渡し、開発規模の順に左(開発規模が小さい、作るのが簡単)から右(開発規模が大きい、作るのが大変)へ並べてもらう。最終的に全ての項目を並べてもらう。
  3. チームに見積もり規模が変わる間を決めてもらう。ストーリーポイントが1と2の間、2と3の間、3と5の間、5と8の間、8と13の間に線を引く。
  4. ステークホルダーを全員呼び、線で区切った枠内で優先順に上下で並べてもらう。枠外を超えた移動は無しとする。
  5. 開発規模が小さく、優先順位が高いものをバックログの上位に置く。開発規模が大きく、優先順位が高いものは早めにバックログリファインメントに回して分割を試みる。

見積もりの数値はいつも問題になりやすいと感じていましたが、このやり方ならスクラムを始める時でも相対比較ができ、かつ数字を意識する必要がないのですぐにでも取り入れようと思いました。* The Big Wall: Prioritizing and Estimating Large Backlogs - Mitch Lacey & Associates - Scrum and Agile Trainingという手法だそうです。

IVE connect #4 Value Stream Mapping体験ワークショップ に行ってきました

ive-connect4.peatix.com

はじめに

組織全体のアウトプットを効率化していくことに課題感を感じており、DevOpsDays Tokyo 2019で気になっていたValue Stream Mappingのワークショップが開催されることを知ったので行ってきました。あらかじめ用意された架空のプロジェクトを対象にしたワークなので消化不良感はあるものの、それでもやってみての気づきや、理解を得ることができ、有意義な勉強会でした。

Vallue Stream Mappingとは? / 進め方

speakerdeck.com

「プロダクト開発の始めから終わりまでのフローを図式化し、部門をまたがった全体で効率化を考えることで、組織のフロー効率改善に繋げるモデリング手法」と理解しました。

ワークショップで行った作成手順は資料の通りですが。

  1. 開発プロセスの工程を横に並べる
  2. 工程の最初と最後にスタート・ゴールをつける
  3. 各工程のLT(リードタイム。着手から終わるまでの待ちも含む時間を書く)、PT(プロセスタイム。工程の作業に必要な実作業時間を書く)を記入する。
  4. 工程をグルーピングし、グループ・全体のLT/PTを計算する
  5. ボトルネックになっていそうな箇所に印をつける。
  6. ボトルネックの解消案を出す。それによってLT/PTがどう変化するかを記入する。

私のグループが研修で描いた例はこんな感じです。

f:id:tune:20190620195627j:plain
描いてみたVSM

CREATIONLINEさんの研修サービス

ぜひ会社でやってみたいと相談したところ、クリエーションライン株式会社で研修サービスがあることを教えてもらいました。早速連絡を取り、開催に向けて動き始めています。

www.creationline.com

LeSS Study LeSS本読書会 第5回

LeSS Study LeSS本読書会 第4回

第4回に引き続き、恵比寿 Redhatさんでの開催でした。 第4章「顧客価値による組織化」を読みましたが、話が脱線して盛り上がる回で途中で終了しました。

Q : 「フレームワークを先に作りたがるエンジニア」は何故ダメとされているのか?

A: 毎スプリント顧客価値を提供するように開発するのがスクラムのやり方だとして、初期のスプリントは開発の足回りに時間を取られることが少なくありません。スプリント0で準備することもありますが、それを指した記述に感じました。私が感じている課題は、はじめにシステムの上から下まで、一通り触って作ってみることで、課題を早く出すことに価値があるのだと考えました。フレームワークミルフィーユのように用意していると、どこかのレイヤーに課題があるときに気がつくのが遅れてしまいます。

Q : チームの大半は顧客中心のフィーチャーチーム とはどういうこと?

A: 「チームメンバーの大半はフィーチャーチームのためのメンバ」という意味ではなく、「複数あるチームの大半はフィーチャーチームで構成され、そうでないチームが少しある」という意味だととりました。リリースまでに必要な作業だがフィーチャーチームができないもろもろ(テスト、リリース判定、マニュアル作成、などなど)をとり扱う「Undoneチーム」を書籍のあとで触れているのでこのことではないかと思います。

Q : 「同一ロケーションのチーム」は時代遅れでは? リモートで効率的に働くやりかたもあるはず。

この日一番盛り上がった脱線話でした。

A1: F2F派の意見です。顔を合わせて仕事をする以上に効率の良いやり方はないのではないか? リモートワークを許容するにしても、まずは顔を合わせて自分たちが出せる最高パフォーマンスを確認し、リモートを取り入れても効率が落ちないようにするべき。そもそもチームの全員が通勤時間0秒だとしたら、それでもリモートで働くことを選ぶのか?

A2: リモート派の意見です。同一環境(全員リモート)を同一ロケーションと呼べば問題ないのでは。チームの一部がリモートだと情報格差やタバコ部屋の議論のような問題が起きてしまうが、全員リモートで環境を揃える努力をするならば、チャットなどのやり取りで議論過程が残る利点もリモートにはある。

Q : チームを長生きさせられている組織はある?

A: ずっとは難しいというのが参加者の感想でした。チームがプロダクトに紐づき、そのプロダクトが長生きするとチームも長生きする傾向があるようです。

Q : フィーチャーチームの欠点「乱雑なコード/設計につながる」

A: MVP(Minimum Viable Product)だからスピードを重視して乱雑なコードを書いたり、設計に手を抜いたり、テストを省略したりというのはやりがち。

避ける方法として下記が挙がりました。

  • 重要な機能(システムの背骨)から作ることで、全体で重要なことを最初によく考える。
  • Doneの定義をきちんと用意する。
  • MVPであっても使い捨てでなくMVPなりのアーキテクチャを考える。

Q : フィーチャーチームの改善目標は誰が決める?

A: チームが決める。ボトムアップだけでは組織課題に対処できないのでトップ・マネジメントを巻き込むイメージ。


大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法

大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法

TACO #3 アジャイルのコンセプトをゲームで紹介 with James Coplien に行ってきました

taco.connpass.com

はじめに

TACO(Tokyo Agile COmmunity)の3回目の勉強会に行ってきました。 パターンなどで著名なJames Coplien氏が来られるとのことで正直それ目当ての参加でしたが、TACOのコミュニティは暖かく、またゲストのCoplien氏のエネルギーに圧倒されっぱなしの場でした。この場を設けてくれたTACOの皆様には感謝しかありません。

当日の写真はここからみれます。

1. ボール回しゲーム

最初に行ったのはカラーボールを使ったボール回しゲームです。 ルールは下記のものでした。

  1. 20人程度が円を作る
  2. 決められた1人がボールを箱から取り出し皆に回す。
  3. ボールを回すときは隣に渡してはならない。また渡すときは投げなければならない。
  4. ボールは全員一度は触らなければならない。
  5. ボールに全員一度は触ったのち、最初に取り出した1人が箱に戻せば得点となる。
  6. 途中で落とした場合は減点となる。

f:id:tune:20190605203136j:plain
ボール回しゲームの得点

1回やる→振り返り→2回目やる→振り返り… と合計4スプリント回したところ、上記の結果となりました。最初は皆がボール回す速度を早くしたり、互いの呼び名を覚えるようにしたりして改善案を出していましたが、Coplien氏が「ボールをケースに入れたまま回せば良いだろう。ダメとは言われていない。確認したのか? やってみてから判断を仰げばよい。」と言い、ケースに入れたまま回したのが高得点の3回目でした。「ゲームでも仕事でも何が許されていて、何がダメなのかをきちんと明確にしないといけない。」とCoplien氏が話していたが印象的でした。またみなの振り返りの様子を見て「皆振り返りで話してばかりで相手の話を聞いていない。」とも言っていました。

ケースに入れたままボール回しをしていても学べることが少ないため、4回目はケース回しを禁止し、円の中で立つ向きを変えたり、回すボールの数を増やしたりしたところ、落としたり詰まってスコアを落としてしまいました。ゲームが意図していた通りの結果となっています。

2. 進捗見える化ゲーム

f:id:tune:20190605203545j:plain

f:id:tune:20190605203600j:plain

1のゲームと同時進行で実施されていたため私は参加できませんでした。おそらくPMとしてプロジェクトに参加し、皆からヒアリングした情報を元に、カンバンを作って可視化するゲームだったと思われます。

3. 他人との位置を均等に保つゲーム

ここからはCoplien氏提案のゲームでした。

  1. 40人が大きな円を作る
  2. 各自が円の中から2人を「心の中で」選ぶ。
  3. 選んだ2人と自分が同じ距離に立つように(3人で2等辺三角形を成すように)立ち位置を移動する。

というルールのもと、1人をプロジェクトマネージャーとして立て、その人の指示のもと移動するようにしました。 プロダクトオーナー役のCoplien氏は「どれだけ時間があれば終わるんだ」とプロジェクトマネージャーに質問しましたが、明確な回答は返せませんでした。そこでCoplien氏はプロジェクトマネージャーを解雇(!)し、各自に自分の判断で動くように促しました。

各自が黙ったままぞろぞろと移動し…1分ちょっとで移動が完了しました。Coplien氏は「これが自律というものだ」と発言してゲーム終了。確かに身を以てトップダウン・マイクロマネジメントの問題が体験できるゲームでした。

4 名前順(アルファベット順)にボールに触るゲーム

https://pbs.twimg.com/media/D8YHHxqU0AEme2w.jpg

最後に行ったゲームは20人ほどのグループで、名前順にカラーボールに触れていくというゲームです。

最初は名前を確認しながら回して数分かかり、次にあらかじめ名前順に並んでおくことで30秒程度になりました。 するとCoplien氏が「10秒でやってみろ」というので、小さな円を作り、片手回しをすることで10秒を達成。 さらに「1秒でやってみろ」というので、最初から皆がボールに触れている状態で始めるようにし達成しました。

Coplien氏のコメントは「極限までカイゼンしたあとはどうするか、自分たちの目的を踏まえた上で、ルールを変えていく必要があるんだ。そうして大きくなった会社を知っているだろう? トヨタ(織機→自動車)、ノキア(ゴム長靴→携帯電話)だ!」でした。

おわりに

https://pbs.twimg.com/media/D8YHHxyU8AApL-V.jpg

TACOは英語話者が多く、普段のアジャイル勉強会とは違ったメンバーになるのもまたいいと感じました。 次回は7/1、内容は「Agile HR」だそうです。 次回参加は検討中ですが、また面白いテーマがあったら行ってみようと思います。