何をやりたいのかをすぐに見失ってしまう

最近、プログラミングのことよりも、頭の中のメモが多い理由は分かってる。たぶん6月末までこんな感じ。今日もそんな感じ。

宿題やりなよ

娘たちに「宿題やっときなよ」って言ってもあんまりやらない。気分が乗らないから。

でも、宿題をやる気にさせる方法なら分かってる。僕がリビングの机で勉強を始めるか、一緒に宿題をやろうとすればいいのだ。そうすると、娘たちも宿題をやろうという気分になってくれる。

なのに実際は「宿題やっときなよ」とだけ言ってツイッターを眺めてる。なので娘たちは宿題をやらなくて、僕はまた「やりなよー」って言うのを何回も繰り返してたりする。

どうしてだろう?

近道?

言ったらやってくれるのが一番はやい。だからそれで済ませたい、かな?だけど、よく考えるとそれは「僕にとって」一番はやいのであって。娘にとってはそうじゃない。

はて?僕がやりたかったことって何だっけ?って考えると、それは「娘が宿題を終わらせること」

あぁ、最初は「娘が宿題を終わらせること」を目的にして「やりなよ」って伝えるんだけど、そのすぐ後には「娘たちが自分の期待通りに動くこと」という目的に変わってしまってるっぽい。

遠回り?

自分の行動に対して、何か反応があって、結果が出てくる。絵にするとこんな感じか?

f:id:bufferings:20210508095631p:plain:w300

  • 「宿題やりなよ」を入れると「お絵描きする」が出てくる。
  • 「一緒に宿題やろう!」を入れると「宿題やる」が出てくる。

それが分かってるのに、僕は自分にとって最小の労力ですむ「宿題やりなよ」を選んで、娘たちの「反応」の部分が変わることで、「宿題やる」が出てくることを期待してる。ということか。

自分ではなく、娘たちが変わってよ、って思ってるってことか。

なるほど。

仕事でも見かける

これって、仕事でも見かけるなぁ。例は省くけど。

自分で変えられるのは自分の「行動」だけで、相手の「反応」は直接は変えられない。相手の「反応」は、自分の「行動」を通して変わる。

だから、望む「結果」を本当に手にいれたかったら、自分の「行動」を変えればいい。

宿題やりなよ

実際に僕が「宿題やりなよ」って言ってるときは「別にやらなくてもいいけど」くらいの気持ちだし、「いつか自分でやるようになるといいな」くらいの気持ちなんだろうな。

まぁ、たまには一緒に勉強しようかな。

後輩が自走できるようにサポートするぞー

この記事を読んで、自分が後輩をサポートするときはどうするっけなぁって考えてみた。例によってあんまり深く考えずに勢いで書く。誰にでもどこにでも当てはまるもんじゃないと思う。僕のいる環境の話ね。

note.com

信頼する

まずは、信頼する。頑張ろうとしてるとか、良いものを作ろうとしてるとか、自走したいと思ってるとか。そういうの。例えばもし「頑張ろうとしてないように見える」場合、「頑張ろうとしている」という部分を信じてるから、その気持ちが行動につながるまでの間のどこかに妨げとなる何かがあるはずって考えて、それを見つけて取り除いていく。

対話

自分の期待を共有する

「自走できるようになってね?」ってだけ言って待ってるのってめんどくさい。僕はめんどくさいことが嫌い。楽をしたい。てか、言うだけでできるならもうなってる。それよりも、今何ができているか、次の一歩は何か、目指したいのはこういうところだよ、ということを伝える方が手っ取り早いので好き。

いいなと思ったことをフィードバックする

いいなと思ったところは、みんなの前でいいね・ありがとうって伝える。そういうのが好きじゃない人の場合は、ダイレクトメッセージで伝えたりする。

それとは別に、本人が気づいていない良いところを1on1で細かく伝えたりもする。リモート会議でみんながシーンとしてるときに意見出してくれてその後に他の人にも聞いてくれたのありがとうとか、コードの名前に気をつけてくれてるのいいと思うとか、ドキュメントを分かりやすく書いてくれてありがとうとか。

自分の行動の中で何が良かったのか、って言ってもらわないと分からない場合は多いよね。だからそういうのは言葉にして伝える。自信と道標になるかなと思って。

良くなるといいなと思ったことをフィードバックする

もうひとつは、ネガティブフィードバック。「あの行動は、話を聞いていないように見えたよ」とか「今回のタスク、ちょっと手戻りが多かったね。次同じようなのが来たらどうしようか?」みたいなの。「あなたは話を聞いていませんよね?」みたいな主観的な決めつけじゃなくて「どう見えたか」とか、「手戻りが多かったよね」っていう事実とかを中心にする。

信頼が前提にあるから「もっと話をちゃんと聞くように!」じゃなくて「どうしたらそう見えない行動を取れるか」とか「どういう仕組みにしたら手戻りを減らせるか」みたいな話ができる。

フィードバックはあったかいうちにする

どちらもできるだけはやく伝えたい。特に、ネガティブフィードバックは評価時期に伝えるのだと遅すぎる。そこまでの間に良くなってて評価も上がるのが一番いい。だって、後輩をサポートするときって「後輩の評価があがること」が僕のゴールだから「評価時期だから言うけどここ良くないよ」みたいなの意味ない。

迷ってることはそのまま伝える

サポートしてるときは結構悩むことがある。先輩だからある程度しっかりしてるほうがいいのはそうだけど、完璧じゃなきゃいけない、みたいなのはちょっと邪魔。

例えば「話を聞いてるよって伝えるにはどうしたらいいんだろう?分からん。これ質問で引き出そうとしてるとかじゃなくて、本当にどうしたらいいかよく分かってないんだよね」みたいに相談したりする。「じゃあ、こういう風にやってみるのはどうでしょうか?」って教えてもらえたりして「おーいいね。それやってみよう!」ってなったりする。

話を聞く

自分の意見を伝えたら、次は相手の気持ちを知りたい。これ、順番が逆だとあんまり話したい気持ちにならないかなと思うので、先に自分の気持ちを伝えるようにしてる。

相手の考えが自分と違ったとしても「相手がそう考えている」ということは否定することじゃないので「そう思ってるんだね。教えてくれてありがとう」って言う。「そっかー」ってよく言う。その次に使う接続詞は順接にする。「そう思ったんですね。でも・・・」じゃなくて「そう思ったんですね、じゃあ・・・」にする。

イメージとしては、横に並んで一緒に目的地を見てる感じ。「今こっちに向かってるよね、じゃあ、あのゴールに向かうには次にどうしたらいいと思う?一緒に考えよう」みたいなの。

だいたいここまでが、お互いの考えを共有するためにやってること。実際は、これを「行動」の中でやってる。

行動

やって見せる

最初は、やって見せる。何が正解かも分からない状態で「自分で考えてやって(でも、僕の期待には応えてね)」みたいなの、さっきも言ったけどめんどくさい。「最初は僕がやるから、次は自分でもできるようになるつもりで見ててね」

タスクに対して「こういう場合は、こんな風に考えるよ」って考えを伝えて「だからこんな風にコードを書いて、でドキュメントにはこういうことを書くよ、その理由は・・・」みたいに。

「この仕様だと何種類かに読み取れるよね?そういうときは『Aさんの時間をいただくのもったいないから、たぶんこれだろうしこれで実装しよう』じゃなくて『Aさんーこれ教えてくれー』って教えてもらう方が結局良いものができるんだよ」みたいに。

んで「ふむ。時間をいただくのが申し訳ない?それわかる。じゃ、申し訳なくならないような仕組みをチームで考えてみようかー」とかも。

一緒にやる

次は、一緒にやる。ペアプロのナビゲーターみたいな感じ。「そうそう、そこは仕様書確認してみようか」「おーその名前付けいいね!」「そこは、こういう風にやったほうが良いと思うー」「ちょっと興味があるだけなんだけど、そこどう考えてそれにしたの?・・・なるほど」「お、悩む?そういう場合はAとBがあるよ。試してみる?」とか。

やったのを見る

その次は、やったのを見せてもらう。ここでまた気づくことが出てくるので、そしたらその部分はまたやって見せたり、一緒にやったりして、徐々に一人でできるようになっていく。

任せる

そういうことを繰り返して、どんどんできることを増やしていきつつ、もう安心だなと思う部分は完全に任せていく。とはいっても、チームのレビューとかがあるから、まぁその後輩とチームに任せるって感じではあるか。

心持ち

失敗の機会を与える

失敗しながらが一番成長できると思うので、小さくいっぱい失敗してもらえるような仕組みにする。プルリクエストのレビューよりもペアプロで拾う。週次の30分の共有よりも日次の5分の共有で伝えるとか。

失敗、というか、自分の期待と違う場所に向かった場合は「何がそうさせてるのか」を知る良い機会。怒られるかもしれない、という気持ちだったり、知らないということが恥ずかしくて聞けないとか、目的を勘違いしてたとか。それが分かれば、次はそうならないような仕掛けを一緒に考える。

ちなみに、失敗は、自己申告しなくても勝手に見つかるような仕組みにしておく。自分から「これ失敗かもしれません・・・」って言いづらいから。

最短距離を求めない

質問の仕方とか、確認の方法とか、目的地にたどり着くのに最短の道を選んでなくていい。「自分だったらこの道をいくから君もここを通るべきだ」みたいなの。それよりも自分で考えてやってみることに価値がある。「その道行くの?いいね。行ってみよう!」「わー!目的地についてよかった!」でいいかなと。その後で「こういう道もあったよ」くらい。

最後は拾っとく

任せるし、失敗から学んだらいい、とはいえ、プロジェクトとかを失敗させてしまうとめんどくさいことになる。なので、その辺りは拾っておく。今のスキルではこぼれ落ちてしまう部分がどうしてもあるからね。

もし、その拾ったものを伝えて理解できるんだったら伝えるし、まだ伝えてもわかんないかなと思うのは別に伝えない。そのときがきたら伝えればいいかなと思って。

目的を共有する

これ最初に書けばよかった。「何をするか」っていうタスクじゃなくて「何を達成したいか」っていう目的を共有する。「そのためにチームのみんなでベストを尽くしてほしいんだよね。どうする?」みたいなの。

タスクよりもプロジェクト、プロジェクトよりもサービス、サービスのためにチーム、その視点を全部見せておく。と言っても、プロジェクトぐらいまでしか見えてない人もいるかもだけど別にいい。いつか、どっかで言ってたことが役に立てばいいかなくらいで。

どこまでやるの?

こんな話をしてたら「そんなことしてる時間ない」みたいに言われるときあるけど「僕は、それをやらない方がめんどくさいってだけだよ」という気持ち。

こんなとこかな。こういう風にしてたら、勝手に自走してくれる。

僕の中でのスクラムの定義は広い

スクラムで開発をしているか?」

 と聞かれると「うーん」ってなる。それは、あなたの中のスクラムの定義による。

そして、スクラムの定義に厳しい人だけでなく、多くの人にとって、僕のやっている開発はスクラムではないだろう。

Doneの定義が明確ではなくてもスプリントを始めるし、スプリントバックログアイテムは全部は完了しないのが普通だし、スプリント中の差し込みも当然あるものとして開発をしている。

プロダクトマネージャー(POに近い役割)は2人いるし、プロジェクトマネージャー(SMに近い役割)も2人いるし、エンジニアのリーダーとしての開発マネージャーもいる。

 

全然スクラムじゃないよね。

 

でも、僕の中では、もうこれでスクラムと呼んでいいことになっている。

僕の中のスクラムの定義

 じゃあ、僕の中のスクラムの定義ってなんだろう?

 

それは、何をやっているかではなくて、どう反応していけるか。

Commitment, Courage, Focus, Openness, Respect、そこに謙虚と信頼。これを持ったチームで、透明性を持って検査と適応をしていれば良い。

そんなチームで、プロダクトだけじゃなくて、プロダクト化されていないところまで含めた「サービス」全体を見て。

自分たちの今持っているをスキルを、期待ではなく、過去の実績をもとに把握して、ベストな道を選ぶ。

そういうチーム。今何ができるか、じゃなくて、今できることを持って、どこに踏み出そうとしているか。

チームもプロダクト

現状維持をしたいとは思っていない。やりたいことはたくさんある。もっとチカラをつけて、もっと良いサービスづくりをしたい。

そう考えると、サービスに対するスクラムチームであると同時に、チームそれ自身も自分たちのプロダクトだなと思う。そちらも育てていく。

スクラムマスターはチームというプロダクトのプロダクトオーナーだなぁって感じがする。そして、自分が何もすることがなくなるようになんてならない。

フレームワークとしてのスクラム

とはいえ、フレームワークとしてのスクラムを否定しているわけではない。

分かりやすいガイド、入口、1つの形として存在してくれているおかげで踏み出すことができるし、自分が違うやり方をしているなぁって認識できる。

アジャイルな開発をしているか?」

と聞かれたら「そうだね」とは言えそう。

ということで、僕の中のスクラムの定義は広い。

今日もぼーっと思うことをメモしておいた。

 

 

 

 

「ユニコーン企業は書籍に書かれているようなアジャイルなんてやってない」

4/26 に発売されます!

ユニコーン企業のひみつ」をいただいて読みました。読みやすくて面白かったー。4/26 に発売されます!チームをリードしている人や組織づくりをしている人にはもちろんおすすめだし、メンバーの一員としてチームの中で仕事をしている人も「なるほどそんな風に仕事をしてるのかー!」って感じることができて面白いと思うー。あと、アジャイルな開発とかスクラムをやってる人ももう一度自分の大切にしているものを見直すことができるんじゃないかなぁ。ぜひどうぞ。

www.oreilly.co.jp

ユニコーン企業はスクラムをやっていない

この本の「ユニコーン企業」とか「テック企業」って「大きくなってもスタートアップみたいな働き方をしている企業」のことで、GoogleAmazonFacebookSpotify のような企業を指してる。そういった企業が何を大切にしているか、どんな風に開発を進めるのかを著者が働いていた Spotify の事例を中心にして教えてくれる。当時の Spotify はまだ分かるけど Google とかはユニコーンって感じでもないけどねw(著者の独自の定義らしい)

そして、ユニコーン企業ではスクラムをやってない、スクラムマスターもいない。って話は、とても興味深い。こういう「自分はどうしてスクラムをやってるんだっけ?」みたいなことを再考させられる機会って好き。一歩深く自分の考えを確認できるから。

エンタープライズ企業はスクラムをやっている

ユニコーン企業との対比で、時流に合わなくなった姿として「エンタープライズ企業」が出てくるんだけど、そのエンタープライズ企業でやってるのは、ウォーターフォールなのかなぁ?って思いきやそうではなくて、アジャイル・具体的にはスクラム、というのがまたこれ面白い。2015年頃の話だと思うから、5年前くらいか。「アジャイルはもう『ふつう』なのですから」そっかー。

ただ、このエンタープライズ企業は本の中で「いやいや、そんなことはやらんやろ」って思うようなことをやる企業なので「それと比べてユニコーン企業はすごいんだ!」って言われてもところどころ「ちょ、ちょっと考えさせてくれ」ってなってしまったw

あ、そうだ、なんとなく先に訳者あとがきを読んだんだけど、先に読むのおすすめ。Spotify モデルは使われていない、みたいなちょっと前に話題になった話にも触れてるから。

読みやすい

著者は「アジャイルサムライ」や「初めての自動テスト」のジョナサン。

著者の他の本を読んだことある人は分かると思うけど、そんないつもの感じで、かわいいイラストとか、喋りかけるみたいな文章で、とても読みやすい。ページ数も190ページでサクッと読める。ジョナサンは、なんか、すごく楽しんでる感じが伝わってくるので、読んでてこっちも楽しくなってくるね。

さらに日本語訳もとても自然で違和感がない。普通は、翻訳された本を読んでたら、ちょこちょこ日本語に違和感があって、原文を見に行って「あぁそういうことか」ってなることがあるんだけど、この本は原文が全然気にならない。(興味本位で原文を見に行って「うぇー、この英語をそういう風に翻訳するのかー!確かにそれだと自然だけど・・・すごいなぁ」みたいにはなってたw)

プロジェクトで仕事を進めない

僕は特に「プロジェクトで仕事を進めない」ってとこに、色々と考えさせられたなぁ。指示されて動くんじゃなくて、自分たちで考えて動けるような自己管理チームにしていくにはどうしたらいいのかなぁって、ぼんやり考えてるところでもあったので、色んなヒントがあったし、確かにそうよなぁって考えさせられることがたくさんあった。RSGT 2019 でクリスが「見積もりをやってない」ってのを聞いたときと似たような感覚。

具体的なプラクティス

Spotify の組織づくりや、それがどんな風に機能していたかを結構具体的に教えてくれてるので、特に組織づくりを考えてる人は面白いかも。ただ、Spotify の具体的な事例なので、そのまま自分のところでやってみるというよりは、その要素を咀嚼して実験してみる、という感じになるかな。そういうことを考えるのも読んでて面白かったな。

ジョナサンが驚くの?

読んでてもうひとつ興味深かったのは、あのアジャイルサムライのジョナサンが「びっくりした!」みたいに書いてるところ。「こんな風に言う人なんてこれまで見たことない」(うろ覚え)みたいに言ってるところがあったんだけど「へー。アジャイルサムライ書いたような凄い人も、こんなことで驚くのか!」ってちょっと身近に感じてしまったのだった。

ただ、できてることも結構あるなぁ

Spotify すごいなぁとは思う一方で、自分のいる組織でできていることも結構あって、その辺りを考えながら読むのも面白かったな。Spotify はそういう方法を選んだんだなぁって思うけど、自分のいるところでは、スクラムマスターがいてもいいし、スクラムやっててもいいし(あぁアレンジしてるからスクラムとは呼べないものかもだけど)、プロジェクトがあってもそれを会社の文化に合わせて有効に活用できてたら、それでいいと思ってる。

あなたはどうする?

全体として「僕らはこうやった。あなたはどうするの?」って問いかけられてる感じ。この本で得られた情報をそのままコピペするんじゃなくて、それをヒントに、自分たちのいる場所をどんな風に良くしていけるだろう?ってことを考えてかなきゃね。って思って楽しくなった。ありがとうジョナサン。

面白かったー

ということで、読んで良かったです。ぜひ手にとってみてください。翻訳お疲れさまでした。ありがとうございました!

僕の頭の中にいる人たち

ちょっと前に、みわさんとせきさんとお話をした。とても心地のいい空間を用意してくれて、幸せな時間を過ごすことができた。ありがとうございました。

その中で「僕の頭の中にはお二人がいるんですよ」という話をしたのだけど、今日は僕の頭の中にいる人たちを何人か紹介しようと思う。

 

せきさん

僕が何かに悩んでると「うまくいったらどうなるの?」って聞いてくれる。「あぁ、正しさみたいなものに、とらわれてるかも」って言うと「よし」って言ってくれる。常に、自分の行動を疑わせてくれる。

 

みわさん

僕が気のせいかな…って通り過ぎようとしたら「うん。そうなの。違和感があった」って言って「どうして彼はいつもと違う言い回しを選んだんだろう?何かここに隠れてる気がする」って言うので、いっしょに気をつけて見てみたりする。

 

そんな風にお二人が僕の頭の中にいてくれるおかげで、自分だけだと気づけない視点に気づけたり、通り過ぎそうなところを踏みとどまれたりする。

 

そして、お二人の他にも愉快な仲間たちがいて結構騒がしい。

 

中村洋さんは、僕が一歩踏み出せずにいると「やったらええですやん」「なんでやらへんの?」って言ってくるし

 

だいくしーさんは、僕が強行突破しようとしてるときに横でもっと柔らかい伝え方でみんなの理解を得ようとしてるから、ですよね…ってなるし

 

いろふさんは、「その行をそんな風に書いた意図が知りたいです」「その設計で本当に大丈夫ですか?」「そっか。名前はそれでいいのか…」「IDEは道具だから、手足のように使えるようになるといいですよね」って言うし

 

およべさんは、僕が悩みそうなときに「それ面白いじゃん!」って言うし

 

とてもにぎやかでよい。

 

ちょっと良くしたいだけなのに

なんだか難しい。なんでなんだろうなー?って、恒例の(?)ぼーっと考えたシリーズ。

こういうのが頭の中に入りこんできて難しくしてるかなぁ

  • 失敗したくないって気持ち
  • 怒られたくないって気持ち
  • しっかりしなきゃって気持ち
  • 恥ずかしくて言えないって気持ち
  • 計画、見積もり、期待
  • もう引き返せないって気持ち
  • 自分と同じ価値観の強要
  • 結果よりも過程を重視
  • 過去の自分の言動に縛られる
  • 過去の成功体験に囚われる
  • 正しさや理想の押しつけ
  • ルールに囚われる
  • チームより個人の手柄
  • プロダクトよりプロジェクト
  • 人よりプロダクト
  • 目の前のことでいっぱいいっぱい
  • とかとか

こういうのが頭の中にほわほわーって入ってきてるときは「良くしたい」ってとこに目を向けるのが難しいよなーって思う。

客観的に考えられるようになりたいなー。

 

 

アジャイルな開発とチームづくり

社内でLTしたネタ。去年からサポートしているチーム作りのお話。

1週間スプリント

最初は短いサイクルで試行錯誤したいから1週間スプリントでやることにした。

f:id:bufferings:20210324215639p:plain:w500

スプリントの終了と開始

金曜日にスプリントレビューとレトロスペクティブとプランニング。

f:id:bufferings:20210324215740p:plain:w500

プランニングは2部制にして

  • 第1部では次のスプリントでやりたいことの認識合わせを全員で
  • 第2部では細かいタスクの話をエンジニア中心で

やってる。

ストーリーポイントと理想時間を併用してみてる

これはだいぶあとの方の話。

最初の頃はチケットのサイズを見積もるのにストーリーポイントだけを使ってたんだけど、半年くらいした頃にストーリーポイントに加えて理想時間の見積もりも併用することにした。

最初の頃に理想時間を導入しちゃうと、頭では分かってても「時間」に引っ張られてしまうので、ポイントだけで始めることにした。で、半年くらいしたころには新しいやり方にも慣れて、もう数字に追いかけられないチームになってたので、もう少し自分たちのことを知って改善に役立てるために導入してみようかってことで始めた。

ストーリーポイントは、ちょっと先の話をするため。プランニングよりも前につけておいて、リファインメントで「次のスプリントではここらへんまでかなぁ」「んー、それならこっちが上のほうがいいなぁ」みたいな話をするときに使う。

理想時間は、エンジニアたちが自分たちのことを知るため。スプリントプランニングの第2部でつけて、毎日残り時間を更新して、バーンダウンチャートをこの理想時間でかいてる。

Daily Scrum

朝みんなで Zoom にあつまってデイリースクラム

f:id:bufferings:20210324215813p:plain:w500

まずは運用周りの状況を確認。自社サービスの開発だけじゃなくて運用も担当してるので、問い合わせやアラート、トラブルの対応や緊急依頼などもハンドリングしてて、毎日変化する状況を把握する。

その確認が終わったら、エンジニアからタスクの状況を共有して、今日やることの再計画をする。もし運用で急ぎのタスクが入ってたら、どのタスクを止めるかを話し合う。

それから、PDM(Product Manager)やPJM(Project Manager)から、今自分たちがどんなことをやってるかの共有がある。これは少し先に運用タスクとして入ってきたり、次のスプリントの計画に入ってきたりする。

以前に↓のような記事を書いたけど、最近はみんな慣れてきて短ければ10分、色々あるときでも30分くらいで終わってるな。

bufferings.hatenablog.com

Team

そういえば、チームはこんな感じ。自社サービスの開発と運用の両方を見ている。

f:id:bufferings:20210324220321p:plain:w500

エンジニア

エンジニアが6人いて、DVM(Development Manager)がリードしてる。エンジニアの動きについては後で説明する。

PDM

PDM(Product Manager)が2人いて、Chief PDMがリードしてる。PDM と Chief PDM は常に認識を共有している。決断は、混乱がないように Chief PDM がしている。

PDM はビジネスチームやデザインチームととても近い距離にいて、社内外含めてステークホルダーと話をしたりしながら、プロダクトの将来を描いている。

サービス運用も含めてハンドリングをしているため、とても大変なんだけど、いつもエンジニアのことを気遣ってくれててかっこいい。

PJM

PJM(Project Manager)は全体を見てる。スクラムマスター的な動き。

組織のマネージャーが PJM とバディを組んでるので、チームにとって良さそうなことがあれば、組織のやり方も含めて変えていけるようになってる。

この2人が、チームの中で間に落ちそうなものを拾い上げてくれるので、エンジニアもPDMもそこをあまり気にせずに自分のやることに集中できる。

PDM が忙しすぎるときはサービス運用タスクを拾ったり、エンジニアがいっぱいいっぱいのときは簡単な問い合わせなら PJM が手を動かしてくれたりする。2人とも、もともとスキルの高いエンジニアなので、あんまり手を出しすぎないように気を遣ってくれながらなのもかっこいい。

開発スタイル

モブ & ペア

エンジニア6人は、タスクや状況に合わせて色んな組み合わせで開発を進める。例えば

  • 2人 x 3
  • 3人 x 2
  • 4人, 2人
  • 6人全員

チームのルールで、タスクを担当する最小単位を2人にしている。シンプルなタスクなら2人で、ちょっと難しいものは3人で、全員が深く理解しておいた方が良いものは6人で担当する。

この組み合わせはマネージャーやリーダーが決めるのではなくエンジニア6人で話し合って決めている。「このタスクは3人でやるほうが良さそう」とか「これはちょっとそちらの2人の意見もほしいので4人でやろう」とか。1日の途中でも1つのペアが「相談したいー!」って声をあげて、みんなが集まってきて、そこでペアを組み替えたりもする。

こういうやり方にたどり着くまでの流れはこんな感じ:最初の頃にペアワークを導入して、しばらくして慣れてきた頃に6人全員のモブワークを実施。しばらくすると、ふりかえりで「全員じゃなくてもいいときがある」という意見が出てペアに戻してみて、次のふりかえりで「認識を揃えるという意味では、ペアよりも結局モブワークの方が良い場合がある」って意見が出て、それ以降も2人や3人などの組み合わせにトライしつつ、今は「最もチームとして良い組み合わせを、常に考える」というところに落ち着いて、動的に組み替えるこのような形になった。

Zoom Breakout Room

ペアワークなどには Zoom のブレイクアウトルームを使っている。メンバーが自分で移動できる設定にしているので、他のペアに確認したいことがあるときなどは「ちょっとRoom 3に行ってくるね」って聞きに行ったりしてる。便利。

ちなみに、基本的にみんなカメラはオフにしてる。1 on 1 とかだとオンにしてるけど、ペアワークのときとかはオフならオフで問題ない。僕は饅頭食べながらペアワークを横で見てたりする。楽でいい。

Daily Pair Rotation

最近新しくトライしてるのは、日次でペアを交代する仕組み。

タスクの区切りで交代、ってなると中々交代するタイミングが合わないのと、そのタスクの細かい部分については担当したペアしか分からなくなるので、ローテーションしてみようって話になった。

アンカー(残る方の人)を決めてペアの組み合わせを考えるんだけど、考えるの大変だねってなったので、Parrit を紹介しておいた。気に入ってくれてるみたい。

https://parrit.io/

Evening Huddle

朝のデイリースクラムとは別で、帰りの会もしてる。最初の頃は全員で集まって Daily Scrum と同じことをやってたんだけど、夕方と朝に同じことしなくてよさそうってのと、どっちかっていうと、エンジニアはエンジニア同士で、プロデューサーはプロデューサー同士で、もうちょっと深い話がしたいねって話がでて、別々にやることにした。

目的は、それぞれのロールの中で深い共有をして認識を揃えること。不安があれば共有すること。

f:id:bufferings:20210324215852p:plain:w500

朝の会では再計画に必要十分な情報をさくっと全員で共有するので、エンジニアリングやプロデュースの深い部分までは踏み込まない。一方、この帰りの会では、例えばエンジニアだと技術的な細かい不安や疑問、気になっていること、知っておいたほうがいいことなどを踏み込んで話す。プロデューサーも、プロデューサー内で認識を揃えるために、お互いの状況や意見を交換している。

そうそう。最初の頃は、朝のデイリースクラムでエンジニア全員が一人ずつ話をしていたんだけど、そうすると粒度が細かくなって全体が見えにくくなってしまうから、帰りの会で話をしたことをエンジニアの代表一人が次の日の朝に共有する、ということにした。代表は毎日交代する。

他のペアのタスクにも目を向けることができるようになった、とか、チームとしての全体観を考えるようになった、とかで良い感じ。

Me Time

ふりかえりの中で「ペアやモブで仕事をしていると、一人の時間がないので、一人時間を作ろう」ってなって、帰りの会の後の30分〜1時間ぐらいを me-time にした。その日にやったことの中で気になったことを調べたり、E-Learning をやったり、他にも色々やることがあるので大切な時間。

f:id:bufferings:20210324215937p:plain:w500

DVM

ここで DVM(Development Manager)の話をしておこうかな。

DVM はエンジニアのリーダーとして、技術的な意思決定をする。採用する技術や、エンジニアリングの方向性、技術的負債の返済計画をエンジニアに相談しながら決めたりする。

それから、PDM や PJM からの技術的な相談の窓口になっている。直接エンジニアたちに相談をすると、そのつど手がとまっちゃうので、まずは DVM が受け取ってそこで答えられるものには答えて、エンジニアに聞いたほうが良いものは、タイミングを見て DVM からエンジニアに相談をする。

そして、DVM はエンジニアのペアプロの部屋をうろうろする役割をしている。チーム内ではこの役割のことを「リベロ」と呼んでいる。これは、ふりかえりのときに「ちょっとペアで悩むことがあったときに、他のペアに聞きたいなーって思うときがあるんだけど、邪魔するのも悪いなぁって気持ちにもなる」という話があって「じゃ、DVM にうろうろしてもらって『これ聞きたいー』みたいなの相談できるようにしてみよう」ってなって始めた。実際にうろうろしてたら、色んな相談ができるようになったみたいで良い。

Pull Request Review

そうそう。もともとこのチーム「コードレビューに時間がかかる」「リーダーが忙しすぎてボトルネックになってしまう」という課題の相談があったのだけど、ペアワークの導入と帰りの会の深い共有と DVM as リベロで、Pull Request を出す前にエンジニア内で認識は揃ってて、実装の方向性の話も終わってて、出したときには「落ち着いて全体を再確認する」くらいになっているので、どちらの問題も解決した。

Backlog Refinement

次のスプリントでやるバックログアイテムの話って、プランニングのときに話をするだけだと全然時間が足りないね、ってなって、バックログリファインメントをやることにした。

週に一度まとまった時間を取るより、毎日少しずつ話しをしてみようか、ということで、デイリースクラムの後にやってる。

f:id:bufferings:20210324220009p:plain:w500

最初は全員でやってたんだけど、これもまたふりかえりで「DVMがエンジニアの代表で話をしてみよう」ってなったので、今は Chief PDM・DVM・PJM の3者でやってる。

全員でやってたときは細かい話がしづらかったんだけど、人数を絞ってからは結構密度の濃い話をすることができるようになって、良い。

次のスプリントのバックログアイテムを相談したり、もう少し長いスパンの話をしたり、お互いに相談したいことを持ち寄ったりしてる。

PDM「ビジネスチームからのこういう相談があって・・・」DVM「あぁ、そういうことなら差し込みになりますけどやりましょうか。その代わりこの最後のチケットはできなくなるけどいい?」PDM「はい、それでお願いします。ありがとう」

とか

DVM「ちょっと技術的に難しい問題があって、次のスプリントにはみ出しそうだから調整できると助かります」PDM「じゃあ、次に予定してたこれを、もう少し後にずらせるように調整してきますね」

とか

エンジニアリファインメント

これも最近始めたトライ。リファインメントに DVM が代表で参加するようになったので、そこで話し合った内容の共有をエンジニアにするのと、あとは、プロダクトバックログアイテムに見積もりとしてストーリーポイントをつける作業をエンジニアで集まってするのと。

火曜と木曜の Me Time をエンジニアリファインメントに充てるようにしてみてる。

2週間スプリントと Non Project Day

半年ぐらいたって、新しい開発スタイルにも慣れてきて実験も落ち着いてきたので、今年から2週間スプリントに変更した。それと同時に、Non Project Day を1週目の金曜日に導入した。

f:id:bufferings:20210324220127p:plain:w500

サービスのことを考えると、チームのスキルアップに時間をさくことには価値がある。という話になって、プロジェクトのことを忘れて「サービスのためになる」と思うことにそれぞれが取り組む日にした。

  • 気になっている部分のコードを読む
  • ドキュメントを整備する
  • 自動化について考える
  • 今後採用するかもしれない技術に触れてみる
  • などなど

単純に楽しいし、プロジェクトの中で取り組むことが難しい部分にふれることができて、とても良い。

Business Status Sharing

Non Project Day の日は、Backlog Refinement はお休みにして、その時間で Business Status Sharing をすることにした。

f:id:bufferings:20210324220211p:plain:w500

PDM が今のサービスのビジネス状況を共有してくれて、今後の方向性や、ユーザーの声、ビジネスチームの声などをエンジニアに届けてくれる。

また、リリースしたものに対するユーザーの反応や KPI の状況なども教えてくれる。とてもおもしろい。

Sprint Review は再確認だけ

あ、そうだ。書くの忘れてた。

スプリントのアイテムは、完了したらそのつど PDM にレビューしてもらうので、スプリントレビューのときにレビューしてもらうことは特にない。スプリントレビューでは「今回のスプリントではこれらのチケットがクローズできたね」って認識合わせをして終わり。

スプリントプランニングの第1部も、すでにバックログリファインメントで十分に話し終わっているので、「この順番で上から理想時間見積もりをして、できるところまで取っていくね」という話で終わり。

なので、スプリントレビューとプランニング第1部合わせて30分くらいで最近は終わっている。健全な感じで良い。

仕組みを改善する仕組み

ということで、これが今の開発チームの全体像。

f:id:bufferings:20210324220249p:plain:w500

自分が気をつけたのは「一人にしない仕組みを作ること」。エンジニアもそうだけど、特に PJM や PDM や DVM やマネージャーは一人になってしまいがちなので、そうならないような仕組みづくりをしてきた。お互いがお互いを頼れる場を仕組みにしておいた。

そして、今はもう「仕組みを改善する仕組み」がチームの中にできていて、自分たちで回し始めているのでとても良い。