スクラムフェス大阪 2021でシステム思考の話をしてきました #scrumosaka
はじめに
今年もスクラムフェス大阪でプロポーザルを採択いただき、話してきました。
社内で向き合う課題が段々と複雑に・難しくなってきているため「システム思考」を布教することが増えてきています。 ただ「これ読んでおいてー」ですむような、最初のとっかかりに適した資料がなかなかなく、「ないなら自分で作るか！」と追い込むためのプロポーザルでした。 他の方の登壇を聞いていてもシステム思考に言及することが最近増えてきたのでニーズはそれなりにあるのではないかと思っています。
登壇準備をしている時は20分枠だといろいろ盛り込むのが難しいなと感じていましたが、使い始めるにあたって必要最小限のことを盛り込むようにまとめられたかと思います。
過去のシステム思考に関連しそうな記事
参考資料
#JBUG 広島 #8 でRettyでの改善取り組みを話してきました
2021年6月13日に行われたJBUG 広島 #8でRettyでの改善取り組みを話してきました。以前 LeSS Studyで紹介した内容 をベースにした再演です。
4月に刊行されたユニコーン企業のひみつと絡めて話して欲しいという話があり、アジャイル/スクラム/LeSSではなく、何を課題と考えて、どう変えていったかを中心とした話としました。
反応など
ちょっと待って、チーム名かわいすぎじゃないですか…？ #JBUG pic.twitter.com/4BhCBroLg4
— おんだまめこ (@OnYun) 2021年6月13日
プロダクト全体思考。ユーザー価値を中心にして考えないと、ですね。取り組むことを、１つにまとめて、ときどきで一番重要なことを意思決定する。そうですよね。#JBUG
— 藤野英利（Hidetoshi FUJINO） (@projectm721) 2021年6月13日
誰がどこに責任を持つか明確にすること。オーバーラップし協力するように促すこと#JBUG pic.twitter.com/dmkkYcwpkd
— おんだまめこ (@OnYun) 2021年6月13日
属人化を減らして、優先順位の高いものからみんなで片付ける。覚えておきたい考え方だなー。
— Tantan / 書籍「豊富な作例で学ぶ Adobe XD」共著 (@shamojiko) 2021年6月13日
#JBUG
アウトカムベースな組織、めちゃくちゃ理想的だ
— ちゃんゆー (@chanyou0311) 2021年6月13日
つい何をしたかに目が行きがちだと反省#JBUG
近道はない。でもやるしか無いんだ。
— たにしょー / コミュマネ @nulab (@shoki_taniyama) 2021年6月13日
→かしこまりました。#JBUG #JBUG広島 pic.twitter.com/GTz0oo45fV
Retty さん、「なぜ」を共有できる組織で、あとバックログをPdMが一人でなく組織で話し合って決められるところがすごいなと思いました。分かっていてもユーザー中心で話をして決めるのが組織ではなかなかできない。でもやるしかないですね。 #JBUG
— 藤野英利（Hidetoshi FUJINO） (@projectm721) 2021年6月13日
カジュアル面談で話すとよさそうなこと
はじめに
先日heyさんの採用イベントで公開カジュアル面談をさせていただきました。
「できるだけ本当のカジュアル面談に近づくようにやりたい」というhey 勝亦さんの希望もあり、事前に打ち合わせは特にせず、「こいつらヤラセっぽいな」と思われないように深く切り込むような質問もときおり混ぜ込みました。もちろん事前にheyさんの公開資料を読み込んで考えてきたものです。
せっかくなので「自分がカジュアル面談を受けるならこういうことを聞くだろうな」と考えたこと、逆に普段実施する側で「これは必ず説明するように心がけていること」をまとめてみました。 Googleで「カジュアル面談 質問」と検索すると例がいくつも出てきますが、大抵は公開されている会社情報を調べるとわかることばかりなので、直接聞かないとわからないことを聞いた方が良いですよね。
自分ならこんなことを聞いてみたい
事業構造、何でお金を稼いでいるか。
創業時の事業や広く認知されているサービスと、実際にお金を稼いでいる事業・サービスが異なる会社がよくあるなと思っています。 会社における売り上げ比率から社内のパワーバランスや、今後力を入れていく開発領域も推測できると思います。
何で収益を上げられているのかわからないけど積極的に採用を行なっている場合、調達した資金を燃やしながら人員を拡大している可能性があります。 広告事業ができる前のGoogleも採っていた戦略ではありますが、Googleになれなかった会社の方が圧倒的多数ですので、目処・戦略はついているのか、いつまで挑戦できる余力が残っているのか、リスクとリターンを確認しておくと良いと思います。
募集の背景
「〇〇で有名なあの人と一緒に働けるチャンスかもしれない」と思わせる募集要項がはっきりした求人をたまに見かけることがありますが、憧れのその人が退職するために代わりの人材を募集していることがあります。「これからXX人材を集めて業界内を引っ張っていくんだ！」とピュアに想像せずに、きちんと確認した方が良いと思います。
募集の背景をはっきり答えられない場合は採用の頭数を追っている可能性が高いと思います。あなたの経歴やスキルはそこまで重要ではなく、他の誰かでも代替はきくでしょう。
競合との差異
競合が全くない会社・事業領域はまずないと思います。 競合を意識し過ぎているのもユーザーを見ておらずよくない兆候ですが、意識しなすぎなのも自分たちのやりたいことをやっているだけでまずいサインかもしれません。
業界の2番手企業が1番を追い抜かすことはほぼなく、逆転にはなんらかの競争軸の変化が必要なので、何を差別化ポイントと考えているのか説明してもらうと良いと思います。営業力や気合いが答えとして出てくる場合は多分逆転は望めないでしょう。
今の会社の課題
「人が足りない」みたいな話しか出ないと、見えにくい・隠れてしまっている本当の問題に向き合えてないのではないかと思います。 ここをはっきりと答えてもらえると、自分が入ることでどう貢献できるか、過去の経験がどう生かせるかといった話で盛り上がれるはずです。
事業成長の先に何が起きるか
今伸びている事業があってもいつか成長の終わりを迎えます。その時に会社はどう動くのでしょうか? 国外を目指す、新規事業を立ち上げる、M&Aを実施するなど考えられますが、会社の打ち手は自分の考え方とあっていますでしょうか?
その会社で働くことで何が得られるか
せっかくなので他の会社では得られない貴重な経験があると良いですよね。 すぐに答えるのが難しい質問かと思いますが、すぐに答えてくれるようだと普段から自社の強み・差別化を意識している証拠かと思います。
説明するように心がけていること
会社でできること、できないこと
事業構造や経緯に起因する正解があるわけではない事項は、最初に確認しておいた方が双方時間を無駄にしなくて良いと思います。
- 会社が一番重視していること。ユーザー、売り上げ、事業成長など。
- 開発スタイル。個人で行うのか、チームで行うのか。
- 開発領域。フロントエンドからインフラまで広く触れるのか、職能・特定の機能に限定されるのか
- 新規技術の採用。取り入れやすいか、しにくいか
- 新規事業の立ち上げ。携われる機会は多いか、少ないか。
働き方、会社の制度
自社が裁量労働制なのでフレックスとの差異を必ず説明しています。 また裁量労働だと勤務時間の懸念を持たれるため開発のサイクル、1日の流れを紹介しています。
コロナ禍になってからはリモート勤務の割合、緊急事態宣言中の勤務、コロナが落ち着いた後はどうなりそうかを話すことが増えました。
面談相手の質問に時間が許す限り全て答える
「会社にいい印象を持ってもらう、願わくば選考に進んでもらう、すぐに選考に進まなくても転職の機会にまたコンタクトを取って欲しい！」が面談する側の気持ちなので、どんな些細なことでも相手が知りたいことは答えるようにしています。
おわりに
上記の話、カジュアル面談を面接の1歩目として考えている会社だとウケは悪そうですが、「カジュアル面談」だしこれくらいは答えてくれる会社が多いといいなと思っています。
スクラムマスターを育てるコツ
はじめに
「スクラムマスターをどう選んだら良いか、どう育てたら良いか」という悩みを多くの方が持っているようなので自分の経験をまとめておきます。
自分はアジャイル・スクラムを学び始めて丸5年が経ちました。 CSM(認定スクラムマスター)資格は持っていません。 初めてスクラムマスターに挑戦するメンバーをサポートした経験が複数回(累計10人以上)があります。
私にとってのスクラムマスターのゴールは「スクラムを始める前よりもよい働き方がチームでできている」ことです。 スクラムのルールをきっちり守ることではありません。
スクラムマスターの選び方
皆から立候補を募り、やる気がある人を信じるのが良いかと思います。 チームのエースや次のリーダー・マネージャー候補を選ぶ事例を聞いたことがありますが、そうなると役割ではなく役職感が出てくるのであまりお勧めしません。
「チームに献身的になれる人(細々としたタスクを普段から自主的にとってくれる)」「メンバーから慕われていて、助けたい・盛り立てたいと思わせる人」が強いて言えば向いているような気がします。 職位・グレード・スキルが高い人が務める必要はありません。どちらかというとそういうメンバーがスクラムマスターになると、メンバーが指示を仰ぐようになったり、自分が隠れてタスクをたくさんこなしてアウトプットを確保しようとするのでスクラムがうまく回らないことの方が多い気がします。
最初にお願いすること
スクラムマスターをお願いする人が決まったら下記の事項を伝えています。
- スクラムマスターはスクラムというフレームワークの中の役割であって、役職ではない。
- プロジェクトリーダーやチームのリーダーではないし、そういう振る舞いを求めてもいない。
- まずはスクラムで定義されたプロセスをきちんと守ることを心がけてほしい。
また、スクラムマスターを任された人のマネージャーには下記のお願いをします。
- まずは「チームの雰囲気がよくなればヨシ」ぐらいに思っておいてほしい
- 「スクラムを一人で回せる(カンファレンス登壇者でもお互いに相談し合っている)」とか「ベロシティをX % 向上させる(見積もりを水増しされるだけ)」ような目標を設定しない
まずは基本に忠実に従い、スクラムのイベントをつつがなく回せることに注力してもらいます。
チームメンバーも含めて初めてスクラムを導入する場合、最初の1回は全てのスプリントイベントに同席し、やり方がおかしいところがあれば適宜直します。 2回目以降はふりかえりだけ毎回呼んでもらうようお願いし、2週間〜1ヶ月ぐらいは同席します。 出席しても基本何も言いませんが、強いて言えば振り返りの改善案として出てくる策が「お気持ち(XXX に気をつける)」だったときだけ具体的な行動に直させます。
最初からスクラムマスター専任でお願いすると何をして良いのか混乱することが多いので、開発メンバーと兼任でお願いすることがほとんどです。
スクラム自体が初めてであればSCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発を読んでもらいます。 スクラム自体は経験があるけどスクラムマスターが初めての場合はアジャイルな見積りと計画づくり ～価値あるソフトウェアを育てる概念と技法～を読んでもらっています。
うまくスクラムが回っていない兆候
2〜4週間(または2〜3スプリント)もたつと、大抵開発のリズムができ、何らかの成果が見え始めるようになります。 振り返りがうまく回っているとチームで改善しようという雰囲気が出てくるのでスクラムを始める前よりも「チーム雰囲気が良くなったのでヨシ」という目標が達成できます。
スクラムに従っているんだけど今ひとつしっくりきていないというときは、下記の兆候が出ていることが多いです。
1. スプリント内に全てのやることが終わらず、それがスプリントの最終日になってわかる
スプリント内で終わらないことはさておき、問題は「終わらないことがスプリントの最終日にわかる」ことです。 このケースはデイリースクラム(朝会)が機能しておらず、互いのやったこと・やることを発して終わっていることが多いです。 開発タスクの残り時間合計の推移や、全体でボトルネックになっていることをデイリースクラムで確認するようになると終わらないことが早期にわかり、プロダクトオーナーやステークホルダーとスプリントのスコープ調整を前もって実施することができます。
スプリント中にバーンダウンチャートを作ることを提案すると解決することが多いです。
2. スプリント内に全てのやることが終わらず、仕掛かりを多く持ち越す
スプリントプランニングが不十分(実装・テスト のような雑なタスクにばらされている)で、バックログの各アイテムに1人を割り当て終わっていることが多いです。 「複数人で取り組んだら少しでも早く終わらせることができないか」という話をチームがしていないことがほとんどに感じています。
一度チームに指摘すると、モブプロを始めたり、手が空いたメンバーが他メンバーの助けに入るなりするようになって解決することが多いです。
3. チームがスクラムマスターの指示を待ってしまう
「手が空いたんですが次に何をしたら良いんですか」とスクラムマスターに質問し、スクラムマスターが指示してしまうケースです。 スプリントプランニングとデイリースクラムの実施が不十分で、どういう順序でタスクを片付けていくのかメンバーが理解できておらず、自分で判断できないことが起因になっているように思っています。
「〇〇さんはどう思いますか?」と相手にボールを投げ返すと自分で考えるようになったり、その結果スプリントプランニングをもっとやろうといったり根本解決につながることが多いです。
スクラムの基本が身についてからの伸ばし方
上記のやりとりを3ヶ月もするとスプリントイベントは一通り回せて、チームの雰囲気も良くなった状態になります。 「自分が手を動かさず、サポートに回った方がチームとしての成果が出るんですよねー」とコメントが出てくるようになります。 またスクラムマスターにチームの状況を聞いてみると「言葉にできないモヤモヤ」や「もっと上手くできるはず」といった感想を聞くことも出てきます。
ここからは個別に壁打ちの機会を設けて伸ばしています。 あとは「最近実験している?」と聞いて、何かしらチームを良くするチャレンジに取り組んでいるかを聞くことが多いです。
相談される悩みの多くは経験・引き出しが少ないケースが多いため、外部の勉強会を教えたり、上級者向けの本をお勧めすることが多いです。 色んな経験を知れて良いなと思った本はスクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本-でした。またアジャイルとかスクラムとか書いてないけど、結局基本を深く理解できるのはトヨタ生産方式をお勧めしています。 他にもいい本はたくさんありますが、本を読むだけで成長することはあまりなく、自分の持ち場・現場の課題に向き合う時間を増やした方が結果的に早く・強く成長するなと感じてます。
スクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本-
- 作者:Mitch Lacey
- 発売日: 2016/02/27
- メディア: 単行本（ソフトカバー）
おわりに
私の場合はこんな感じです。他にも色んな方のノウハウ知りたいです。
"プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける"の感想
プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける
- 作者:Melissa Perri
- 発売日: 2020/10/26
- メディア: 単行本（ソフトカバー）
社内で実施した読書会 & 議論で大分満足してしまい、記録を残し忘れていました。 今更ですが自分の感想メモです。
1章 : 価値交換システム
競合でその機能が成果を出していることを確認しているか?
競合がある機能をつけると「是非うちでも」という話が出てきがちで、2番手以降のプロダクトだと「星取表で負けてるから売れないんだ」という話に流れがちですが、「競合のその機能はユーザーに響いているんですか?」という返しはしたことなかったかも。でも「わからないけど星取表で全体的に負けているからダメなんだ」とか返されてぐぬぬとなりそう。こういうやりとり仕事でしていると、まずいいプロダクト作れていないので気をつけていきたい。
企業は従業員を顧客やユーザーと近づける必要がある。それによって学習できる。
これですね。
こう言ってるときは、立ち止まった方がいいかもよ pic.twitter.com/RDsh1oFc8Q
— Ryutaro YOSHIBA (@ryuzee) 2021年3月24日
2章 : 価値交換システムの制約
リリースしたものがうまくいったかはどうわかりますか?
正常に動作した時の挙動や、受け入れ条件の話はよく出るけど、ユーザーの行動・振る舞いをプロダクトによって良い方向に変えたいことがゴールなので、どうやって知ることができるかはもっと気にしていきたい。
アウトカムってもうちょっといい用語ないかな?
この本を読んだ人同士だと「それってアウトプットじゃ無い? アウトカムは何だろう」と話せるけど、読んだことがない人に「アウトカムは何ですか?」と聞くとアウトプットが返ってきそう。もっといい日本語ある気がするんだけど思いつかない。読書会だと「Burning Needsどうだろう?」と思ったのですが、アウトカムよりさらに狭い界隈にしか刺さらなそう。
3章：プロジェクト / プロダクト / サービス
望ましいアウトカムを得られるまで組織を最適化する
アウトカムを目標に据えて、イテレーションでプロダクトを磨いていく。その過程で開発プロセスや開発組織も磨いていかないといけない。
プロジェクトではなくプロダクト
これは自分もことあるごとにいうようになったけど、プロジェクトやめていきたい。
4章：プロダクト主導組織
「ビジョナリー気取り問題」ってありません? エセジョブズ問題
自分の作りたいようにプロダクトを引っ張ることを目的としているPdM志望の人ってよくみませんかという話。 書籍では「ビジョナリー」と紹介されていたけど、TwitterやSNSで見る感じ大抵の人はたまたまくじに当たった一発屋でジョブズでは無い感じ。 エセジョブズの人は夢を壮大に語るけど、何となくユーザーを向いてない気がするんですよね。
5章：私たちが知っていること、知らないこと
「未知の未知」が最近ようやくしっくりくるようになった
既知と未知の組み合わせの4象限の話。PdMは自身が手を動かすことによって未知を既知に変えていかなければならない。
わずかな知識を会得して何も知らないから知っている状態になったとき。
— おつな 🌱 (@by0027) 2020年1月10日
私は無知を解消したかもしれないけど、不知の事実があることも自覚しないといけない。#図解 pic.twitter.com/cI8kFH8SD5
6章：悪いプロダクトマネージャーの典型
PdMはミニCEOではない
会社(プロダクト)のビジョンを変えたり、人事をどうこうする権限がないので、CEOではないのだという話でした。 確かにその通り。
これはここ1年ぐらいで痛感しています。 「小さく始めるんだ」といいながら、うまい検証のやり方を実験できてない感じ。
会社でPdM(プロダクトマネージャー)研修できそう。 ストーリーの書き方、ミーティングのやり方、要望の集め方、テストのやり方
PdMの育成プロセスがないよねという話から。 「いいPdMの排出企業」もこれといった会社が無い気がします。
自社でも育成に取り組んでいますが、「みてやって覚えろ」だけじゃなくて、定期的に勉強会・研修を整備しても良いのかもしれない。 複数社で協力してやると運営も楽になって良さそう。
7章：優れたプロダクトマネージャー
PdMはPO(プロダクトオーナー)を内包する
これもそうですねという話。 スクラムを使っていると、プロダクトオーナーが全てプロダクトの責任があるように思ってしまうが、責務を書き出してみるとPdMの方が多い。
10章：戦略とは何か？
優れた戦略とは詳細な計画のことではありません。 戦略は意思決定を助けるフレームワークである。
何をやるかのリストより、何をやらないかを決める根拠にできるものがよい戦略・フレームワークだなと思うようになりました。 中期計画も機能のリストじゃなく、重要なアウトカムのリストで作っておけば軸がぶれなくて良さそう。
11章：戦略のギャップ
上位の意図をどう実現するかは任せるべき。 なぜ必要なのかは上から下に伝える。どう実現するかは下から上に報告してもらう。
普段から心がけていることではありますが、判断に使うであろう情報はできる限りオープンにしておき、判断を委ねるのがスピードが出て良いですね。
12章：良い戦略フレームワークを作る
チームに制約を設けた方が動きやすくなるが、ミッションで狭めるのが良いかというと悩ましい
今の開発チームは会社のほぼ全領域に携われるようにしているけど、チームや組織ごとにある程度の制約を設けた方が自分たちで目標立てやすくなって良いのかなともやもや。 制約を入れた方が良いことには同意しつつ、どう入れるかはプロダクトの範囲ではない気がしています。
失敗に成功したい
気持ちとは裏腹に成功した失敗の実例が思い出せず。小さな実験しかやってないのだろうなと。 失敗しないと許容文化も生まれない気がするのでもっと実験していかないと。
13章：企業レベルでのビジョンと戦略的意図
ミッションは企業の存在理由を説明する。 ビジョンは目的に基づいてどこに向かっていくかを説明する
ビジョンとミッション、以前はしっくりこなかったのですが、ビジョンがしっかりしてる現職で働いていてこれは良いものだなと思うようになりました。 ビジョンの存在が強すぎてミッションが弱くなっているのでこれを時間作ってブラッシュアップしていくといいんだろうな。
15章 プロダクトのカタ
価値提案の中心でないものに対して、凝ったものを作らない
これ。 SaaSが増えてきたからか、自身の考え方が変わったのか、お金で解決できるものはお金で解決した方が良いなと考えるように変わりました。
16章 方向性の理解と成功指標の設定
AARRRはユーザー満足度について語っていない
これ。 定量指標を意識することは大事だけど、何を見ていて、何を見れてないのかは常々意識しないといけない。
17章 問題の探索
問題を根本的に理解しなければ、適切なソリューションを意図して作ることはできない
同じアウトカムに対してイテレーションで取り組んでいると、問題の理解度がだんだん深まってきて適切なソリューションにたどり着ける気がする。 プロダクトの弱いところを全体的に手直ししようとして表層的な問題に取り組み続けるよりも、自社の未来につながる問題に継続的に取り組んでいかないといけない。
「ユニコーン企業のひみつ」を読んで考えたこと
ユニコーン企業のひみつ ―Spotifyで学んだソフトウェアづくりと働き方
- 作者:Jonathan Rasmusson
- 発売日: 2021/04/26
- メディア: 単行本（ソフトカバー）
「ユニコーン企業のひみつ」を読みました。 きちんとした書評は会社のTech Blogで公開予定のため、ここでは個人的に感じたこと・考えたことを書き留めておきます。
どこから手をつけるのが良いのか
書籍だと変わった後の姿の紹介しかないため、自分の会社で同じように変えていこうとなるとどこから取り組むべきかに悩みそうです。 自分がやるなら「自律する開発チームを作る→自律する開発チームを増やす→目標を徐々に揃える」かと思いました。 自社の開発プロセス改善もそう言えばこの順でした。 Spotifyモデル(2013年)・Spotifyリズム(2016年)の公開時期を踏まえると、Spotifyもこの順のように思えます。
自律したチームはどこまでやるべきか
書籍では決められた手順通り開発するチームを「野菜切り」と比喩していますが、真に自律したチームはいったいどこまで出来るのでしょう?
自己組織化チームとは何か？で紹介されている「自己管理型チーム(タスクの実行、進捗管理)」かなと思っているのですが、書籍を読んでいると「自己設計型チーム(チームのデザイン、チームが運営される組織面の変更)」かそれ以上を求めているのかなと感じました。でも書籍の中ではプロダクトオーナー(PO)・テックリード(TL)・アジャイルコーチ(AC)から構成されるPOTLACなるチームが言及されているので、組織面の変更権限はこっちにあるような気がするんですよね。 だとするとチームの自律の範疇はフランチャイズオーナーの店舗運営ぐらいなのかなーとか思ったり。
「自律してね」チームに伝えると、多くのケースで何でもかんでもやろうとして動きが悪くなるので、書籍に出てくる下記の期待値表現は短くて今後使っていこうと思いました。
自律せよ、だが局所最適に陥るな。
イテレーションはプロダクトを試行錯誤して磨いていくこと
書籍の序盤に出てくる表現。iPhoneを思わせる挿絵があるけど、「Appleだって最初からiPhone12を発売できたわけではないでしょ」という説明は良さそう。 同じ対象を何度も何度も改善しながら作り直すことが大事なんですよというメッセージは伝えていきたい。 ただブラッシュアップとか違う用語がいいかなと思いました。 イテレーションは開発サイクルそのものを指して使われるケースが多い気がして、新たな意味を持たせるには広まりすぎたと思います。
課金コードは何番?
うけた
でもこれがうける人は過去にこの体験に触れた経験があるということで・・・
インハウスのアジャイルコーチがマネジメントチームの一翼を担う
プロダクトオーナー(PO)・テックリード(TL)・アジャイルコーチ(AC)から構成されるPOTLACというマネジメントチームが紹介されていますが、国内の企業でインハウスのアジャイルコーチがいて、その人にマネジメントチームに入ってもらう事例は聞いたことがありません。アジャイルコーチは外部からスポットで招聘していたり、アジャイルコーチが社内にいてもマネジメントチームの一員ではないと思うんですよね。うちはこれできているよという会社があったら話を聞いてみたいです。
日本のアジャイル実践者は外部コーチが多い気がするので「Spotifyではインハウスでアジャイルコーチを雇い、マネジメントチームに参加させている。日本もこうやっていくべき！」みたいな啓蒙活動するといいんじゃないかな。(適当)
Spotifyは合意形成の文化である。
ヤンテの掟に言及されているのが良かったです。Spotifyの開発文化はこれに根ざして形作られた「合意形成を重視する文化」だと考えるとしっくりきます。
- 自分がひとかどの人物であると思ってはいけない
- 自分が我々と同等であると思ってはいけない
- 自分が我々より賢明と思ってはいけない
- 自分が我々より優れているという想像を起こしてはいけない
- 自分が我々より多くを知っていると思ってはいけない
- 自分が我々を超える者であると思ってはいけない
- 自分が何事かをなすに値すると思ってはいけない
- 我々を笑ってはいけない
- 誰かが自分のことを顧みてくれると思ってはいけない
- 我々に何かを教えることができると思ってはいけない
ロードマネージャーの負担が大変そう
スクラムを発展させたLeSSだとスプリントのタイミングで全チームの方向性・リズムが強制的に揃うけど、Spotifyモデルだとカンパニーベットの遂行に責任を持つロードマネージャーの負担が凄そう。
というか彼/彼女らは本書で批判している"プロジェクト"マネージャーなのではないか?
Spotifyへの憧れ
そういえば2年前に転職活動をしていたときに、Spotifyを受けてみようかと考えていたくらいには憧れていたことを思い出しました。 当時は東京の募集がなく(今もオープンのポジション無いようです)、フルリモートもなかったことで調べただけで終わってしまいましたが。
Spotifyへの憧れはSpotifyモデルを公開した、Henrik Kniberg氏由来で、彼を自分のキャリアのロールモデルとしておいています。 今はMojang(マインクラフトの開発元)にいるそうですが、きっといろんな実験をしているんだろうな。
2021年3〜4月に社内で共有したアジャイル開発関連の記事
社内でアジャイル開発を議論するSlackチャンネル #tech_agile に見かけた良記事のまとめです。この記事は第4弾です。
- 2020年9〜10月に社内で共有したアジャイル開発関連の記事 - tuneの日記
- 2020年11〜12月に社内で共有したアジャイル開発関連の記事 - tuneの日記
- 2021年1〜2月に社内で共有したアジャイル開発関連の記事 - tuneの日記
ノウハウ・知見
スクラムで回す開発の実際の話
ここが好き
より良いものを作るために、プロダクトマネージャーと開発者が話をした方がいいなら、手を止めるのを気にしない。
ただ、全員が話をすると時間を持っていかれすぎちゃうから、代表で1人が話をするくらいがいいかな。その人が「他のメンバーの意見も聞いたほうがいいな」と思ったら、みんなに聞く。くらい。これは開発者を代表するくらいのスキルが必要なので、テックリードというロールの人がやる。
サービスの運用による突発対応は、あるものとして考える。突発対応が入ったらデイリースクラムでチームとしての動きを話し合う。「今日は突発対応を優先させるから、別のチケットの作業を止める」みたいなの。もし日中に緊急のものが入って次の日のデイリースクラムまで待てないって場合は、テックリードが開発者を集めてチームとしての動きを話し合う。
専門チームは他にも色んなチームとやり取りをしているから、そのようなチームとのやりとりはスプリントをまたいでやることになる。それも全然気にしない。 組織の活動も後輩の育成も楽しい。
大切にしてるのは、そういうのも全部ひっくるめたうえで開発できるものが、自分たちの健全なスピードなんだなって受け止めること。
リソース効率とフロー効率
細く長く開発続けるのやめたいねーという社内の話から
www.slideshare.net
Whole teamという考え方
勇気をもって質問する。分かるけどまだまだできてない時あります
角を立てない質問の仕方
「ちょっと自分の理解が追いつかなくなってしまったんですけど〜」とか「混乱してきたので自分の頭を整理したいんですけど」って枕詞につけるという話でしたー
— aki.m (@Aki_Moon_) 2021年3月11日
自分はメンバーの感情が過剰に気になってしまうので、誰も傷つけない言い回しで凄い役立っています
Working Agreementでは下限も話し合うと良いのでは無いか?
チームのWorkingAgreementの話。「こういう風にしようね」てのはよく話す合うやろうけど「これはないな」みたいな下限的なものも話し合うと良いと思う。理想はいくらでも話し合えるし、やっていく中で変わっていくことが多い。それに比較すると下限はそこまで変わらない印象がある
— yoh nakamura (@yohhatu) 2021年3月11日
夕方にやる短いミーティング→「帰りの会」
弊社でも帰りの会いくつかできました。
チームラーニング
どういう生活リズムか、強み・弱み、コミュニケーションは話すのが良いかテキストが良いか、MTGに対してのスタンスなど具体的な質問をチームで共有することで働きやすい環境づくりを目指すチームラーニングというプラクティス
ホワイトボード(Miro)の使い方工夫
テンプレートを作ると「いきいき」しないよねという学び
スクラムマスターのキャリアを考える上で、ぜひ立ち止まってやってほしいエクササイズ
他社事例
atama plusのLeSS事例
自分の感想
- 議論を重視する文化があったからか、議論時間が無駄に増えてしまったのかも。
- Rettyではリファインメントの人数を減らし、信頼してもらう方向に倒している
- atama+のリファインメントは10〜20名で、そのうち8人ぐらいが議論する感じらしい
- LeSSを導入する問題背景が全社で揃ってなさそう
- Rettyの場合は「ミッション間の根回し」にパフォーマンスが左右されることが1番の課題だった
- 「開発効率が上がる」ぐらいの意識なので、LeSS導入過程でパフォーマンスが落ちる(新しい領域をチームが学習している)ことに耐えられなかったように見える。
楽天 椎葉さんのチーム作り事例
うちと似ているなーと思うところもあるし、うちより洗練されてるなーと思うところもある。さすがな感じ
GMOのレゴスクラム
勉強会・カンファレンス
モンハンスクラム
マイクラとか繰り返し作業ゲーとスクラムの学習は相性が良いのかも
入社1年目の新人がふりかえりを習慣化して学んだこと
その他
スクラム用語を使わないスクラムの説明
スクラムってカタカナ語が多くて人に説明しにくいって言われたので、スクラム用語使わないで説明する資料作ってみた pic.twitter.com/KiFxXjMNgs
— Ryutaro YOSHIBA (@ryuzee) 2021年3月4日
スクラムとアジャイルのおすすめ本
個人的には「アジャイルな見積もりと計画作り」と「エクストリームプログラミング」で良いんじゃないかと思っています
危ない兆候
こう言ってるときは、立ち止まった方がいいかもよ pic.twitter.com/RDsh1oFc8Q
— Ryutaro YOSHIBA (@ryuzee) 2021年3月24日
SmartHR製のプランニングポーカー
リモートでバックログリファインメントをやる際に、物理プランニングポーカーを使うと顔出しする動機付けになるかもなーと思ったり。
ボブおじさんのインタビュー翻訳
CleanAgileが書かれた背景を掴むのに短くまとまっていて良き。
“The New New Product Development Game”とAgile with ScrumとLean
ユニコーン企業のひみつ/訳者あとがき
「ユニコーン企業はなぜスクラムをやってないのか」に対してと思われる原田騎郎さんのツイート
よりよいプロダクト・プロセス・チームを見出すために安定的に不安定な状態を作り出すための枠組みというのがスクラムの立ち位置なので、結果としてスクラムじゃなくなっていくのは自然なこと。それらを見出す過程の中でスクラムが役に立っているといいなぁ、くらいですね。
— HARADA Kiro (@haradakiro) 2021年4月30日
