見出し画像

たまには「うちのチーム」の話でも。

はちと申します。
いつも見ていただいてるかた、ありがとうございます。
初めての方、僕はこんな人です。


おかげさまでいろんなところでお話をする機会をいただくのですが、最初の頃は自分のお話をしていましたが、プラクティスの話やマインドセットの話をさせていただくことが増えました。

なので、 最近お会いした方は「普段どんなチームでどんなことしてるんだろ?」と思われることもあるのかなとも思っています。

というわけで、今回は1年ぶりくらいに私のチームのお話をしようと思います。

どんな会社?どんなチーム?

私は映画、テレビ、CMなどのいわゆるエンターテイメント的なメディア業界に身を置いています。

会社としてはポストプロダクションと言われる撮影から皆さんの手元にコンテンツが届くまでのほぼ全ての仕事を担っており、日本のみならずアジアでは1、2番の大きさかなという感じです。

多くは絵や音の編集を行っている現場の人間で、約1%がいわゆるソフトウェアエンジニアというイメージです。

私はそんな15名のエンジニアチームに所属しており、主にプロダクトオーナーをやりつつ、セールスエンジニア、AWSの設計実装などを行なっています。

15人で40超のプロダクト

そんな私たちのチームは主に映像業界向けのBtoBサービスを開発しており、顧客は社内の時もあれば、テレビ局や映画会社、配信プラットフォームなど多岐に渡ります。

そんな業界特化のプロダクトということもあり、表には出せないものが多かったりもします。一応外に出せるものとしてこんなのがあります。


プロダクト自体は請負や受託開発というわけではなく、顧客の課題やニーズに日々触れているので、そこから自らで企画、マーケティング、それをファーストユーザーになりうるお客様と一緒に試行錯誤しながら作り、SaaSで提供することが多いです。

試行錯誤しながらつくっていくこともあり一部のプロダクトで採用していたスクラムでの開発を全てのプロダクトに適応する動きを取っており、そのためのアジャイルコーチのような動きをしています。

プロダクト×チーム

実はこの8月に日頃からコミュニティーやイベントでお世話になっている川口恭伸さんに合宿に来ていただき、新入社員も含めたコンテキストと基礎レベルの整理とプロダクト×チームのあり方を見直しました。

スクリーンショット 2019-10-05 13.13.36

それまでは新しい開発プロジェクトが始まると必要な人員を考え、プロダクトごとにチームを組成していました。

そのため、40超ある大小さまざまなプロダクトとチームがメッシュ状に絡み合っており、それぞれが5〜10のプロダクトを兼務している状況でした。

スクリーンショット 2019-10-05 13.21.42

感じた方も多いと思いますが、これではスクラムでの開発がうまくいきませんでした。

「今週はこのプロダクトに何時間かけられる」という議論から入り、インシデントが発生するとほかのプロダクトやメンバーへの影響も大きくチームでのコミュニケーションも取りづらいものでした。

 ベロシティーの考え方うや相対見積もりが時間の概念に引っ張られてしまうのです。

このような状況を打破するために合宿を経てこれをチームに対してプロダクトを紐づけるというものに変えました。

スクリーンショット 2019-10-05 13.26.41

これにより、

・プロダクトに個人の集合ではなく、チームで向き合える
・チームが固定のため、練度が上がっていく
・時間の概念を考えず、ベロシティーと向き合える
・WIPを適正に保て、それぞれのissueに集中できる

といったメリットが生まれました。

チームで向き合ったリアルな課題たち

「チームの練度が上がる」と言いましたが、「ほんとかよ?」「どうやってわかるの?」という声もあると思います。

私の実感としてはふりかえりで課題を見つけ、試行錯誤しながらどんどん良くなるということが本当にできているといったところからチームの練度が上がったと自信を持って言えるようになりました。

ここからは具体的な課題とどう解決してきたかの一部をご紹介します。

1. 聞いていいのかわからない

私がプロダクトオーナーを務めるチームは合宿を経て、7人のチームで複数のプロダクトにあたっています。

メンバーはTLを除くと2年目、1年目、営業からのジョブチェンジ、現場からのジョブチェンジといったメンバー構成です。

そのため、チームでのプロダクト開発自体の経験が浅いメンバーが多いです。
とはいえ、前年度の開発プロジェクトが全社表彰を受けたということもあり、少しずつ自信が出てきているという状況です。

まずここで起きたのが、「なかなかDoneにならない」という問題です。

これをふりかえりで議論していく中で出てきたのが人によって実装スピードが違いすぎるという問題でした。前述の通り、比較的若いチームなので誰がどのissueを取るかでそのissueの速度が変わっています。

「当たり前だ」と言ったらその通りなのですが、思考停止せずに「どう良くするか」を考えようという話をしていきました。

そもそも何故だろう。そんな会話の中で見えてきたのが、

「TLさんも忙しいのに、こんなレベルで自分が時間をもらえなんて…」
「調べればできそうと思ってたらできなくてズルズルと…」
「これも勉強だから頑張っていたらズルズルと…」

という遠慮や責任感によるものでした。
これは責めるべきことでは決してなく、むしろ褒めてあげることです。

そのため、ただルールを一つ作ることで習慣化を促すことから始めました。

30分悩んだらまずはslackの困りごとチャンネルに共有しよう

これは永続的にルールとして拘束するものではなく、習慣付けするためのトレーニングとしてみんなで決めました。

それと同時にチームにワーキングアグリーメントができました。そして、それを毎スプリント見直すという約束もできました。

この30分ルールは功を奏し、今ではすぐに立ち上がり、相談を始める空気が定着し、30分ルールも目的を達成し、ワーキングアグリーメントから外れました。

そして今では、相談だけではなく、自主的に時間を決めてペアプロ、モブプロが自然発生しています。

2. 締切までに終わるかわからない

相談しやすい空気がチームにでき、実装速度も上がってきました。そして、毎スプリントでもベロシティーが上がり始めます。

しかし、ある程度スプリントが進み、ステークホルダーからのフィードバックも増えてくるとプロダクトバックログアイテムがそのスプリントのDoneの数以上に追加されることも出てきました。

私としてはプロダクトのタイミングとステークホルダーのモチベーションの向上によるものなのでウェルカムでした。
そして、その中で優先順位さえつけていけばチームのこころをざわつかせることはありません。

しかし、2年目の彼からある日こんな声が上がりました。

「最近やることが増えてきて全部終わるか不安です…締め切りに対して今のペースで本当に大丈夫ですかね?」

私の中では見えていたものの彼の中では不安を抱かせていました。ただ、彼のこの責任感と勇気を出して言いだしてくれたことがとても嬉しく、ぜひチームにその思いを伝えてほしいと話しました。

そして、次のふりかえりの中で当然議題として挙がりました。

そこで始めたのが、

MVPを決めて、そこまでを見積もってみよう!

というものです。

 MVPとはMinimam Viable Productの略で単体で動く最小単位のプロダクト。いわば、最低限必要な機能という意味です。

私たちはSprint Planningの中では直近+2~3Sprint分が常に見積もられている状態を作っていましたが、それだけではMVPがどのくらいで終わるのかも見えません。

 この出来事から2Sprintで実装とのバランスを考えながらMVPまでを見積もってみました。

 結果として、このままいくとどのくらいで終わるかというざっくりな見積もりができて、期日までに頑張れば終わるね。という安心も生まれ、心のざわつきは治りました。

 とはいえ、今後も後から見つかるMVPに必要な機能も出てくるはず。それを見越してValueを上げていくことに関して同じ方向を向き直った良い出来事でした。

3. プルリクがたまり続ける

 次に起こったのが、「実装スピードに確認スピードが追いつかない」という問題です。つい、実装が完了してもプルリク確認が終わらず、レビューまでに見せられない。そして、次Sprintへ持ち越しになることが増えました。

 なぜこれが起こるのか。

それは実装速度が上がったことが要因の一つです。いいことですよね?チームの成長に伴うありがたい悩みです。

 一方で、忘れられていたのが優先順位。

Sprint Backlogには優先順位順に並んでいるものの、実装が終わるとプルリク確認が自分以外のレビュアーが行うもの。その間に次のIssueに着手していると、プルリク確認で直しが発生しても後回しになってしまっていました。

また、「自分以外全員がレビュアー」というルールでおこなっていたこともあり、私自身がボトルネックになってもいました。

画像4

ここで改めてワーキングアグリーメントに加えられたのは3つ

・ プルリクはTL + 2人が確認

 プルリクエストはあくまでコードとしての正しさを確認。つまり、仕様としての正しさは実装前に個別ならびにPlanning時にPOと確認しておくこと。コードの正しさはTLと第3者の目があれば担保できるというものとしました。

・テストデータ用Seedの作成に関するプルリクは1人確認したらOK

 テストデータの投入に関しては間違えても大きな問題がないと判断し、レビュアーを減らすことで確認コストを下げました。

・プルリク確認タスクも実装と一緒に優先順位をつける

 どうしても実装の途中で手を止められるのは避けたいもの。であれば、初めから優先順位をつけるべきだ。ということで、そのプルリクの確認自体が全体から見てどのくらいの優先順位かを判断できるようにすることにしました。

これにより、暗黙的に「プルリクが溜まることがよくない」としていたものが「優先順位は低いのであれば、確認よりも他の実装を」という意識がより一層身につきました。

5. TLがプルリク確認に追われる

 上記ワーキングアグリーメントからTLの時間がほとんどプルリクの確認時間になってしまいました。本当は実装の核を担う人間でありながら、実装に時間が避けない。品質の担保としては必要なことでありながら、これではボトルネックがPOからTLに移っただけということにみんなで気づきました。

 そこでうまれたのが

プルリクを倒す会

というアイデアでした。

具体的には優先度の高いプルリクエストが溜まったら、Daily Scrumの中で時間を決めて関係者全員でモブプロで確認、修正を行う。というものです。

 これによってプルリクエスト自体の行って返ってというやりとりを減らし、実装の時間を捻出しました。

 ただ、これだけではまだまだ効果が薄く、現在考えているのは陶山さんの下記資料にあるようなモブプロの実現です。

まだこれはチャレンジできていないですが、次Sprint以降で試していこうと思っています。

チームの練度は上がる

 ここまで具体例としてあげてきた通り、チームの練度は上がります。そしてチームは進化し続けることができます。

 「ふりかえりの形骸化」はよく聞く話です。そのためには、いろんな手法がありますし、それも大切です。

 ただ、それだけではなくチームに起こっているリアルをに向き合うことに真摯に向き合うことでチームは進化します。

 今回久々にまとめてみて自分のチームもまんざらではないなと改めて思いました。

 もし、この記事が皆さんに気に入ってもらえたら、どこかでチームと一緒にイベントでお話しさせていただこうかなと思いました。

主にPjM、PO、セールスエンジニア、AWS ソリューションアーキテクトなどを務める。「映像業界の働き方を変える」をモットーにエンジニア組織を超えたスクラムの導入、実践に奔走。DevLOVEなど各種コミュニティーにおいてチームビルディングやワークショップのファシリテーションを行う