#RSGT2021 で日本の文化の観点からスクラムについて考えた!

(2021-02-11 更新。動画が公開されたので貼りました!それと合わせて発表のために使ったアプリも紹介しておきました。)

Regional Scrum Gathering Tokyo 2021

でお話をさせていただきました。英語で。

confengine.com

youtu.be

スライドはこちら。

内容

スクラムを日本の文化の視点から見るとどう見えるんだろう?というお話。

きっかけ

去年、海外出身の人と仕事をしてて、お互いにお互いを理解しようとしてるんだけど、全然考え方が違ってて、すれ違って。

(あぁ、自分の意図を結構はっきり伝えたつもりだったけど、これだと伝わらないのか!)だったり。

「その言い方だと、周りの人は嫌な思いをするから良くないよ」ってことを伝えたら「え!?そんなつもりなかった、謝ります!」って言われたり。

逆に「どうしてこんなやり取りになるの?」って聞かれて(あれ?なんでだっけ?感覚では分かってるんだけど言葉にするとどうなんだろう・・・)ってなって、でもなんとか言葉にして説明したり。

「テックリードとして何をしないといけないかって定義もないのに、何をどうすることを期待されてるの?」って言われて、「ふむー。たしかにそうだよね」(でも日本の人ならできちゃうんだよなぁ。なんでだっけ?)って思ったり。

そういうことを毎日1on1で話しながら、徐々にお互いのことを理解していった。

のだけど、彼のことを理解する、というのはそれと同時に、僕自身のことを理解するということだったのだ。僕自身の根底にある、あたりまえ過ぎて気づいていなかった日本的な部分、それに気付かされた。そして、自分の根底にある文化は、彼の根底にある文化とは全然違う特徴があるんだなぁって。

そんなことを考えてたら、日本的な考え方からスクラムをもう一度見直してみたらどう見えるんだろう?ってことが気になった。それがきっかけ。

発表に使ったアプリ

mmhmm

www.mmhmm.app

スライドと自分を合成して共有できるアプリ。

ちょっとでも近くにいる感じがでたらいいなぁと思ったので試してみた。割と好きな感じなのでまたオンライン発表の機会があったら考えようかな。スライドの右上あけとく方がいいのかなぁとか考えなくてよかったのもよかった。

Grammarly

www.grammarly.com

英語のチェックアプリ。Mac に入れて使った。

a とか the とか分かんないから、とても助かった。有料プランにすると「もっとこういう言い回しの方が分かりやすいよ」ってのも教えてくれて、なるほどーってなってた。長い文章は2つに分けるとか、受動態じゃなくて能動態を使うとか。日本語だと主語を省略して受動態にすることが多いなぁって思いながら「この文章の主語ってなんだっけ?」って悩んだりしてたw

Concepts App

concepts.app

絵を描くアプリ。僕はほんの一部の機能を使ってるだけで、全然使いこなせてないけど。

個人的に Kafka のブログとかの絵の感じが好きで、Concepts 使ってるって書いてたので、なるほどーと思って iPad + Apple Pencil でお絵描きして楽しんだ。

So how DO you make those cool diagrams? July 2019 update

読んだ本など

こっから先は参考にした本などを書いておく。全部電子書籍で読んだけどリンクは紙にしとくー。

books.rakuten.co.jp

↑ジェフさんがスクラムをどう捉えてるんだろう?というのを知りたくて読んだ。人に問題があるわけじゃない、問題があるのはシステム(仕組み)の方だ、その人たちの力を最大限に引き出せるようなシステムを作りたかったんだ。みたいなことが書いてあって、なかまだー(失礼)って思った。

hbr.org

↑野中さんと竹内さんの新しい新製品開発についての論文。1986年のもの。これがスクラムの起源になっているので読んだ。この中の、HondaやCanonラグビーアプローチがスクラムの起源になってる。

books.rakuten.co.jp

↑これは2020年の12月に新しく出た方で、実際に読んだのはもう一個まえのバージョン。もう少し野中さん考えを知りたくて手にとった。電子書籍で読んだあとに、本屋で見かけて、なかなか読み終わらなかった理由が分かった。分厚いw

books.rakuten.co.jp

↑何年か前に買ってたやつを読み直した。野中さんのスクラムに対する意見を再度確認したいなと思って。4月に新しいバージョンを平鍋さんと及部さんで出版するみたいなので買おうと思ってる。

books.rakuten.co.jp

↑SECIモデルについて、もう少し知りたくて手にとった。SECIモデルの周りの章しか読んでないけど、時間があるときに他の部分も読んでみようと思う。経営学の本だから僕にはとても難しくて、でも全然知らない分野だから面白かった。これも分厚い。

books.rakuten.co.jp

↑The New New Product Development Game とは別の系譜として、トヨタ生産方式がある。ので、読んだ。なるほどなぁ。

books.rakuten.co.jp

スクラムのプロダクトオーナーやスクラムマスターの元になっているトヨタのチーフエンジニアについて知りたくて読んだ。スーパーマンだなぁ。

books.rakuten.co.jp

↑日本の組織のいまいちなところを知りたくて読んだ。前半が戦争の話で、知識が全然ないので難しかったけど、後半はそれを組織論の観点で分析してて、そっかー!って言いながら読んだ。

books.rakuten.co.jp

↑失敗の本質で「空気の支配」って出てきて、そもそも「場の空気」の「場」って何だろう?ってのが知りたくて読んだ。組織の構造の話や、欧米型の組織の特徴についても書かれてて、言われてみたら確かにそうだなぁと思った。

books.rakuten.co.jp

↑戦時中にアメリカが日本を分析したもの。アメリカから日本がどんな風に見えたんだろう?というのを知りたくてパラパラと目を通した。「恥の文化」かぁ。ちょっと違う気もするなぁと思いながら。また今度ゆっくり全部読もうと思う。

books.rakuten.co.jp

↑「場の空気」ってなんだっけ?ってのが分からなくなったので読んだ。「場の空気」と日本語について書かれていて、確かにそうだなぁと思った。

books.rakuten.co.jp

↑「空気」ってなんだー!!って分からなくなったのでパラパラと目を通した。宗教の話とか出てきてちょっと難しいけど、なるほどなぁと思った。

からの

次は、これを読みたいなー!野中さんのキーノート、よく理解できてない部分もあるけど、なんか最高だった。

books.rakuten.co.jp

RSGT2021 楽しかった

オンラインとオンサイトのハイブリッド開催にしてくれてたおかげで、この状況でも大阪からオンライン参加することができたので、ありがとうございます。

てやまぐさん、おのさん、サインを代わりに書いてくれてありがとうございましたー!

来年は、会場でみんなに会えたらいいな。弁当食べたい。

f:id:bufferings:20210108183145j:plain

ソフトウェア開発するときの兼任についてふわっと

この記事読んで、いいなぁと思ったのだった。前を向いてるところとか。その中で何を優先するべきかを整理してるところとか。

zenn.dev

んで、兼任について今までふわっと思ってたのをふわっと書くだけ書いてみようと思ったのだった。

開発者として仕事をしてるとき

こんな感じ。黒い丸の部分が、僕の担当。

f:id:bufferings:20201220113451p:plain:w400

プロダクトマネージャーとプロジェクトマネージャーは、分けて考える方がいいと思ってるので、分けてかいた。スキルや考える向きが違うから。

兼任して!って言われたとき

特に何も認識合わせをせずに始めてしまうと、こういう「全部のロールで100%」を期待されてしまってたりする。上司からだったり、チームメイトからだったり、自分自身からだったり。

f:id:bufferings:20201220113921p:plain:w400

実際は最初はPdMとPjMの領域の期待値は低いだろうけど、でも「将来的には100%できることを期待してるよ!」みたいなところあると思う。

こういうのだと、疲れてしまう。

実際のところ

できるのって、こういう感じかなぁという印象。

f:id:bufferings:20201220114302p:plain:w400

3つのロールを足しても100%にはならない。プロジェクトの数が増えるとコンテキストスイッチによる損失があって、3つのロールを兼任する場合3つのプロジェクトだと考えてみると40%は損失されるから。(「ワインバーグのシステム思考法 ソフトウェア文化を創る」より)。

でもコードに触れたいなぁ

とか思って、こういう風に動いてしまっちゃうよね。「今日は何にもやってないのにもう定時だ!今からコードレビューしなきゃ!」みたいなの。実際は何にもやってないなんてことはなくて、PdMとして動いてたりするのにね。赤い部分は自分の許容量を超えてる。

f:id:bufferings:20201220120648p:plain:w400

あと、Developerの部分は、DeveloperとDevelopment Managerにも分かれるので、コンテキストスイッチはもう少し時間を持っていってしまうと思う。

んで、何が言いたいかというと

これができているだけで、とてもすごいことなんだよというのを、自分だけじゃなくて周りも認識している状態、というのがいいよなと思う。

f:id:bufferings:20201220114302p:plain:w400

それを認識したうえで赤い部分をがんばってみたりするのはいいかなと。ただその場合も「やらなきゃいけないことができていないので無理をしてでもがんばらなきゃ!」ってなるのではなくて「やるべきことはやったうえで、さらにうわのせでやってるのやで!」って認識がいいなと。

そんな風にふわっと書いてみました。

気まぐれ上司

金曜日の夜は、娘の習い事のお迎えに行って、二人で自転車で帰ってくる。いつも決まった道を通って帰ってる。

 

でも、昨日は少し違った。お迎えに行った帰り道、娘がいつもの道を行こうとするので、とめた。「今日は、そっちじゃなくてこっちの道で帰るよ」

 

「あ、そうなんだ」というので「うん」って言って二人でそっちの道を帰る。しばらくぼーっとしたあとに「なんでだと思う?」と聞いてみる「なぞなぞ?」「ううん」

 

娘は少し考えてみて「んー、なんで?気分?」「ううん、今日は習い事短くて帰ってくるの早かったでしょう?」「うん」「だからだよ」

 

「あーあっちの道は今の時間はまだ人がたくさんいるからか」「そうそう、あっちの方が近いんだけどね」「そっか、なるほどね」

 

といいつつ、もう別のことを考えてそうだったので、今日にはもう忘れてるだろうな。

 

しばらくぼーっとしてるときに考えたのは、これって上司が気まぐれに見えてしまうのと似てるかもなぁということ。

 

「帰り道はこっちの道を行く」というルールだと捉えていると、今日は気まぐれで違う道を選んだように見えたかもしれないな。と。

 

僕の中では当然のことだったので、言葉にして伝えてなかったけど「道が混んでいなくて自転車でも安全に帰れるときは近い方の道で帰りたい」という自分の考えを伝えておくと良さそうだなと思ったので話をしておいた。

 

逆に、自分が誰かの指示に従うときは、その理由を理解しておきたいよな、とも思いながらコーラを買ってあげて帰った。

 

毎朝15分以上のデイリースクラムをしてる

15分以上のデイリースクラム

今一緒に仕事をしているチームでは、毎朝みんなで集まって話をしてる。みんな家から仕事してるからZoomで。

デイリースクラムみたいなものではあるのだけど、15分以内におさめる、ということはあまり考えていない。

だいたい15分は超えていて、長いときは30分ぐらいかかる。でも、それでいいと思っている。それだけ話すことがあるというだけ。

どうして?

理由は、開発チームだけじゃなくて、プロデューサーも含めて全員で「現状を確認する」「同じ方を向く」「不安を共有する」ということをやっているから。実際のところ、開発チームだけの話だと5分もかからない。

プロデューサーはチームの外側で起こった色んなことをフィルタリングして開発チームに必要な情報を届けてくれる。とても助かる。お互いに情報を共有して、現状の認識合わせをする。そのうえで、今日何をやるべきかを再確認している。

そんな感じなので、毎朝プランニングをしている気持ち。

どうして?その2

どうしてこういうことが必要かというと、僕らは、特定の開発プロジェクトだけを担当しているわけじゃなくて、サービスの運用も担当しているから。

なので、問い合わせや調査の依頼、突発の対応が入ったりする。そうなると昨日までとは状況が変わるから「チームとして今日どのように動くべきか」というのをみんなでプランニングする必要がある。

「これは今の作業を止めてでもやったほうがサービスにとって良いんですよね?」

という話や

「今の作業の方がサービスにとっての優先度が高いから、その対応は次のスプリントに入れましょうか?」

という話がとびかう。

サービス運用も?

という風に僕らは開発だけじゃなくてサービスの運用も見てる。このことは、上記のように開発チームに不安定さをもたらすのだけど、僕自身はそれはそれで良いかなと思ってる。開発をしているときに運用視点の話がでてくるから。

「この設計だと問題があったときに気づくのが遅れるから、すぐに気付けるようにしたいな」とか「このログだとシステムに何が起こったのかは分かるけど、じゃあそれでユーザーがどう困るかが分からないから、そっちが分かるようにしたいな」とかそういうの。サービスの運用を実際に体験して、実感してないとなかなか伝わらない。

そんな感じ

なので、デイリースクラムというかデイリープランニングみたいなものをやっていて、それには15分以上かかってる。

プロデューサーには、こういう質問をしてるかな:

  • 今日、開発チームに伝えておきたいことはありますか?
  • 困っていることや、開発チームに相談したいことはありますか?

ところで

僕が初めてスクラムを勉強したときは、デイリースクラムの3つの質問はこんな感じだったと思う:

  • 昨日何をやったか?
  • 今日何をやるか?
  • 困っていることは?

だけど、2013年のスクラムガイドの改定で、こんな風に変わった:

  • 開発チームがスプリントゴールを達成するために、私が昨日やったことは何か?
  • 開発チームがスプリントゴールを達成するために、私が今日やることは何か?
  • 私や開発チームがスプリントゴールを達成する上で、障害となる物を目撃したか?

こっちの方がチーム感があって好きな感じ。さらに、3つの質問自体が「必須ではなく、一つの例」になったけど、それも良いなと思う。

参考: スクラムで削除された5つのトピック | Ryuzee.com

頑張ってる人の力になりたい

なぁと思う。そして、そう思える人が周りにたくさんいるのは、良い。

最近涼しくなってきて、今日は久しぶりにぼけーっとゴロゴロしてるので適当に書いてみる。

 

どちらの力にもなりたい

頑張っているのになんかあんまりうまくいかなくて悩んでる、のは、期待と現実にギャップがあるからだということが多い。

これくらいできなきゃいけないけどできてない…。みたいなの。

って話をすると、現場のメンバーを想像するかもだけど、マネージャーもそう。

どっちも頑張ってるし、より良くしたいと思ってるし、どっちも悩んでる。ので僕はどちらの力にもなりたい。

この辺は「自分の娘たちがその立場だったら自分はどう思うか」を考えると優しい気持ちになれる。

 

今のままでいい

「期待通りにいかないのは頑張りが足りないからだ」と思ってる人が多い。でも、そんなことはない。

今のままで良くて、明日それよりもうちょっと上手にできるようになったら、明日が今日よりも良くなる。ただそれだけ。

 

ギャップが見えない

難しいだろうなと思うのは、期待と現実をどう埋めていけばいいか、そのギャップが見えていない場合が多いということ。

ギャップが見えていないと、なんかうまくいかないんだけど、どうすればいいのかが分からないなぁって、不安の中を手探りで進むしかない。

 

ギャップを見せる

だから、僕が手っ取り早く手伝えるのは、そのギャップを見えるようにする、ということなのかなと思ってる。

期待と現実をつなぐための動きを、できる範囲で僕がやって見せる。その一部はエンジニアの動きだし、一部はスクラムマスター的な動き、他の部分では、マネージャーの組織づくりの動き。

こういう動きが組織としてできると、自分たちの期待に近づけるよ、みたいなの。

もちろん全部ができるわけではなくて、その触りを見せるくらいしかできないけど、そんなやり方があるんだ!ってのを1つだけでも見せられると役に立つかなと。

 

そういう感じ。

 

頑張る?

そういえば、頑張る、というのは、無理をする、というのとは違う。残業はしない。休憩もしっかりとる。生活を1番に考える。がいい。

その上で仕事に向き合って、限られた時間の中で自分のスキルを伸ばしながら、サービスに対して昨日よりも今日は少しだけ多く貢献できるように考えて行動をする。

 

そういうのを頑張ってる、と言いたい。

 

娘たち

には、まだできないことがたくさんあるけど、できないことを悲しむより、できてることを喜びつつ、明日も無理せず頑張って、できることが増えたらまたパーティーしようね。なのがいいなぁ。というのが根底にある。

 

適当に思い浮かんだことを書いてみた。そろそろお昼ごはんでもつくろっかなー。

 

日本的な視点でScrumを再考してみたい #RSGT2021

と思って RSGT2021 にプロポーザルを出しました。ちょっとでも面白そう、と感じてもらえた方はぜひ投票をお願いします!9月末でしめきりなので早めにポチッとタイトル下のハートマークを押していただけると嬉しいです。

confengine.com

この10年弱くらいスクラムやってて、良いところたくさんあって好きなんだけども、なんかちょっと気になるところもあって、なんだろうなぁ?って思ってて。

スクラムの起源には The New New Product Development Game という論文があって、これは1980年ごろの日本の製造業の新しい新製品開発を取り上げたものなのだけど、この論文に影響を受けて1990年ごろにスクラムが考案されて、それが逆に最近日本に入ってきて、色んなところで導入されてる。

この10年で、スクラムによって自分の周りの色んな考え方が変わってきて、日本的なあまり良くない部分も減ってきて良いなぁと思う。そうなってくると今度は、日本的な良い部分をもう一度見つめ直してみたい気持ちになった。

僕は、英語化をした企業で仕事をしているのだけど、そこでは日本の文化を土台にして、海外の文化の人たちもたくさん一緒に仕事をしていて、お互いの違いを尊重しながら仕事をしている。そんな風に他の文化に触れると、逆に自分の土台になっている文化について気付かされることが多い。

The New New... を元に考案されたスクラムだけど、日本の文化という土台の上では、もう少し別の見方もできるのではないか、もしかしたらそういう日本の文化の中で育ってきた自分だから気づくことができる視点があるのではないか、という気持ち。

ハイコンテキスト、場、絆、暗黙知、リーダーシップ、開発リーダー、プロダクトオーナー、スクラムマスター、マネージャー、その辺りをキーワードにしてもう一度自分の中の言葉で考えてみたい。

英語で発表しようと思います。当日は通訳があるかもしれないから、その場合は日本語でも聞くことができると思います。ぜひ投票をお願いします!

実験によってチームのやり方として定着してきたものを6個

この2ヶ月ぐらいサポートしてるチームで、実験を重ねる中でチームのやり方として定着してきたものがあるので、温かいうちに書いとく。6個ある。

背景

どういう背景かを簡単に:

  • エンジニア4人とリーダー1人、プロデューサーが2人のチーム。全員家からリモートでつないでる。
  • サポートに入る前はチームは計画重視の指示型開発で全員別々の作業をアサインされて取り組んでいた
  • そこに「自己組織化チームにしたいけどそういう経験者もいないしプロジェクトも忙しい中なのでサポートしてほしい」と声をかけてもらって参加
  • 2週間くらい観察して色々周りを整えたあとにチームに入って、スクラムを導入して1週間スプリントを6回終えたところ
  • 自分はリーダーの代わりに入らせてもらうことにした。まずはチームのやり方を色々変えてしまって、チームが落ち着いてきたら徐々にリーダーと一緒にそのリーダーならではの道を探して、最終的にはそのリーダーに渡す予定。

スクラムをどんな風に導入したかは今日は触れない。そして、いつものことだけど、ちゃんとスクラムやってるわけじゃない。

定着してきたチームのやり方

ということで、チームのやり方として、実験して定着してきたものたちを紹介する。

(1) Mobbing by default / 基本はモブ

全員が集まることを基本とする。特に以下の場合はペア作業中だとしても全員を集める。

  • 大きな設計判断、または難しい設計判断をする場合
  • ペアの二人共が悩んでしまった場合
  • 他のペアの意見も聞いてみたい場合

基本をモブにする背景

  • 基本がペアだと、全員で集まるハードルがあがってしまうため、基本はモブとする
  • 基本がモブで、そこからペアに分かれるのは簡単

これを実現させるためにまず最初に「チームとしてタスクを受け取る」ということに取り組んだ。個人やペアでタスクを受け取るという認識だと、助け合うときに足枷になってしまうから。自分の今担当しているタスクの手を止めても、別のペアのタスクの相談にのることがチームとして優先することだ、という認識を持てる場にすることが大切。

(2) Pair as Atomic Unit / 最小単位はペア

作業担当の最小単位はペアとする。一人ではタスクを担当しないこと。

  • 設計・実装・テスト、それぞれに対してクオリティがあがる
  • イージーミスが減る
  • 別の視点の意見が入る
  • コードレビューの負担が下がる
  • 一人だと焦ってとばしてしまいたくなることも、二人だと止めてもらえる
  • 名前づけを真剣に考えやすくなる
  • ときには途中で見切りをつけてまず動くところまで持っていくという判断をしやすくなる
  • 一人だと悩んでハマってしまう場合があるが、ペアに相談できるし、ペアでも悩む場合に他のペアに相談するという判断がすばやくできる
  • ペアのもう一人がお休みの場合は、別のペアに合流して3人で作業することを第一に考える

これは「効率上げるために一人で作業してみる」という実験をしたときに「やっぱりつらい」「結局時間がかかる」ってなって「最小単位はペア」にすることになった。

(3) Separate Work in a Pair / ペア内別作業

ペアワークだからといって常に一緒に作業をしないといけないわけではない。

  • 必要に応じてペアで別々に作業をしても問題ない

ただし、あくまでも担当の最小単位はペア

  • 一日の終わりには、そのペアのどちらに話を聞いても状況が分かるように認識を同期しておくこと
  • そのため、ペアで頻繁に認識合わせをしておく

実際にうまくいった方法

  • 時間を区切って「1時間後に共有しましょう」というようにしたらうまく同期できた。

(4) Frequent Breaks / 頻繁な休憩

モブやペアは想像以上に疲れるので、頻繁に休憩を取ることを忘れないようにする。

  • 特にペアは気を抜くことができないので疲れる。

長くても1時間に1回は休憩を取ること。

  • 例:45分作業したら15分休憩
  • 例:25分作業したら10分休憩

休憩といってもずっと休んでるわけじゃないよ

  • 気になってたことを調べたり
  • メールの確認みたいな開発以外の作業をしたり
  • チャットに返事をしたり、チケットを見てたりするから

(5) Engineer Evening Huddle / エンジニア夕会

毎日夕方にエンジニアだけで集まって共有や相談をする場を設ける

  • 「話すことがあれば開催」ではなく一旦集まって「話すことがなければ解散」というスタイル。開催のハードルをあげないため。どうでもいい話もできるようにするため。
  • 朝会のようにエンジニア以外が参加している場だと気を遣ってしまうような細かいコードの話やどうでもいいような話題が中心
  • もちろんエンジニア以外の参加も歓迎する

具体的によくやるのはこんな感じ↓

プルリクエストの事前説明

  • プルリクエストで「書き終わったコード」だけを見てレビューするよりも過程も共有したい
  • なので、そのプルリクエストで何を考えてどんな風に修正をしたのか
  • 主にどの辺りを見てほしいか、どの辺りが心配か、気にしなくても大丈夫な部分はどこか
  • 動作確認やテストについての共有

など。これでプルリクエストのレビューの負担がだいぶ下がった。

設計判断の共有

  • コードを書いてる途中でも、書く前でも、早い段階で設計判断を共有しておくと色んな意見がその時点でもらえるので、より良いコードがかける

悩み・不安の共有

  • 何か悩んでたり不安に思っていたり困っていたりすることがあれば共有する
  • エンジニアの不安はあたってることが多い

って感じなんだけど、これは、それまでモブでやっていたのをペアでも作業し始めて、情報が分断され始めたとチームが感じたときに、TRYとして始まったもの。

一日中モブをやってる場合は常に情報が同期されているのでこの会をスキップすることができる。実際に何度かスキップしている。

(6) Morning Huddle over 15 mins / 15分以上の朝会

朝会は15分以上かかることが多いけど気にしない。

実際のところエンジニアのタスクの状況共有は10分もかからないのだけど、その前に、プロデューサーからエンジニアへの同期というのをやってる。

プロデューサーからはこういう共有がある:

  • 他部署との調整
  • サービス運用に関わる共有や調査依頼
  • ステークホルダーからの情報の共有
  • 他の案件の準備のためのエンジニアの協力依頼
  • などなど

チームの外側の状況は日々めまぐるしく変わっているのだけど、それをフィルタリングして大切なものだけを伝えてくれる。そのおかげでチームが開発に集中できるようになってきている。

そして、チームは「現在の状況の中でチームとして今日最優先にするべきことは何だろう?」って考えて取り組むことができる。

そんな感じ

自分が大切にしてるのは「気持ちの自然な流れ」。別々作業を基本にしてると「モブやってもいいですよ!」ってしててもなかなかそちらに流れない。モブの方が気持ちの位置エネルギーが高い感じ。

だから「モブを基本にします!でも別々に作業してもいいですよ!」ってしとくとエネルギーが低い方には自然と流れることができるので両方をうまく使い分けることができる。そういう仕組みづくりが好き。

全員が前向きに取り組んでくれてるし意見を出してくれるのでとても助かる。定着したものもチームの成長や周りの状況に応じて変化するので、定期的に見直していきたい。