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) アジャイルとスクラムを大規模に実装する方法
- 作者: 榎本明仁,木村卓央,高江洲睦,荒瀬中人,水野正隆,守田憲司
- 出版社/メーカー: 丸善出版
- 発売日: 2019/01/30
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
TACO #3 アジャイルのコンセプトをゲームで紹介 with James Coplien に行ってきました
昨日はTACOのイベントへご参加ありがとうございました！
— Tokyo Agile Community (TACO) (@TokyoTaco) June 6, 2019
ゲームを通じてアジャイルへの理解を深めて頂く内容でしたがお楽しみいただけましたか？
アジャイル界の著名人Jimさんのお話も伺う良い機会でした。
次回は7/1の予定です！
皆様のご参加お待ちしております！@jcoplien #agile #アジャイル pic.twitter.com/eAWfL4Es02
はじめに
TACO(Tokyo Agile COmmunity)の3回目の勉強会に行ってきました。 パターンなどで著名なJames Coplien氏が来られるとのことで正直それ目当ての参加でしたが、TACOのコミュニティは暖かく、またゲストのCoplien氏のエネルギーに圧倒されっぱなしの場でした。この場を設けてくれたTACOの皆様には感謝しかありません。
当日の写真はここからみれます。
1. ボール回しゲーム
最初に行ったのはカラーボールを使ったボール回しゲームです。 ルールは下記のものでした。
- 20人程度が円を作る
- 決められた1人がボールを箱から取り出し皆に回す。
- ボールを回すときは隣に渡してはならない。また渡すときは投げなければならない。
- ボールは全員一度は触らなければならない。
- ボールに全員一度は触ったのち、最初に取り出した1人が箱に戻せば得点となる。
- 途中で落とした場合は減点となる。
1回やる→振り返り→2回目やる→振り返り… と合計4スプリント回したところ、上記の結果となりました。最初は皆がボール回す速度を早くしたり、互いの呼び名を覚えるようにしたりして改善案を出していましたが、Coplien氏が「ボールをケースに入れたまま回せば良いだろう。ダメとは言われていない。確認したのか? やってみてから判断を仰げばよい。」と言い、ケースに入れたまま回したのが高得点の3回目でした。「ゲームでも仕事でも何が許されていて、何がダメなのかをきちんと明確にしないといけない。」とCoplien氏が話していたが印象的でした。またみなの振り返りの様子を見て「皆振り返りで話してばかりで相手の話を聞いていない。」とも言っていました。
ケースに入れたままボール回しをしていても学べることが少ないため、4回目はケース回しを禁止し、円の中で立つ向きを変えたり、回すボールの数を増やしたりしたところ、落としたり詰まってスコアを落としてしまいました。ゲームが意図していた通りの結果となっています。
2. 進捗見える化ゲーム
1のゲームと同時進行で実施されていたため私は参加できませんでした。おそらくPMとしてプロジェクトに参加し、皆からヒアリングした情報を元に、カンバンを作って可視化するゲームだったと思われます。
3. 他人との位置を均等に保つゲーム
ここからはCoplien氏提案のゲームでした。
- 40人が大きな円を作る
- 各自が円の中から2人を「心の中で」選ぶ。
- 選んだ2人と自分が同じ距離に立つように(3人で2等辺三角形を成すように)立ち位置を移動する。
というルールのもと、1人をプロジェクトマネージャーとして立て、その人の指示のもと移動するようにしました。 プロダクトオーナー役のCoplien氏は「どれだけ時間があれば終わるんだ」とプロジェクトマネージャーに質問しましたが、明確な回答は返せませんでした。そこでCoplien氏はプロジェクトマネージャーを解雇(！)し、各自に自分の判断で動くように促しました。
各自が黙ったままぞろぞろと移動し…1分ちょっとで移動が完了しました。Coplien氏は「これが自律というものだ」と発言してゲーム終了。確かに身を以てトップダウン・マイクロマネジメントの問題が体験できるゲームでした。
4 名前順(アルファベット順)にボールに触るゲーム
最後に行ったゲームは20人ほどのグループで、名前順にカラーボールに触れていくというゲームです。
最初は名前を確認しながら回して数分かかり、次にあらかじめ名前順に並んでおくことで30秒程度になりました。 するとCoplien氏が「10秒でやってみろ」というので、小さな円を作り、片手回しをすることで10秒を達成。 さらに「1秒でやってみろ」というので、最初から皆がボールに触れている状態で始めるようにし達成しました。
Coplien氏のコメントは「極限までカイゼンしたあとはどうするか、自分たちの目的を踏まえた上で、ルールを変えていく必要があるんだ。そうして大きくなった会社を知っているだろう? トヨタ(織機→自動車)、ノキア(ゴム長靴→携帯電話)だ！」でした。
おわりに
TACOは英語話者が多く、普段のアジャイル勉強会とは違ったメンバーになるのもまたいいと感じました。 次回は7/1、内容は「Agile HR」だそうです。 次回参加は検討中ですが、また面白いテーマがあったら行ってみようと思います。
Re: 大規模にアジャイルをやるにはどうしたらいいですか？
TL;DR;
本当に必要かを見極める。やる場合は"ゆっくり"広める。
はじめに
上記記事は「答え 大規模にしない」でしたが、とはいえ大規模なアジャイル開発の事例も世の中にはあるわけで、自分の考えもアウトプットしておこうかなと思いました。
大規模アジャイルの定義
「大規模アジャイル」を語るとき、下記が混じっているように思っています。
- 会社・部門全体の大人数でアジャイルにやりたいが、作るものはドメイン・顧客・技術も異なる。
- 会社・部門全体の大人数で複数のプロダクトを手がけている。別々のプロダクトだが相互に関係性・依存がある。
- 会社・部門全体の大人数で1つのプロダクトをアジャイルに開発する。
「全社でアジャイルな組織を目指す」と言う人のほとんどは1パターンではないかと思います。これは小さいチームの集合体に過ぎないので個別にスクラムなり導入して別々に走らせれば良いと思います。
3パターンをアジャイルでやるには正面から向き合って乗り越えるしかないんじゃないかなと。
意外と見落としがちなのが2で、組織・部門内の人たちは独立だと思っているけれども、プロダクトの定義を大きく捉えると実は依存関係があるパターンです。例えばtoC向けWebサービスとしてPC・スマホがあり、iOS/Androidアプリがあり、裏ではtoB向けの管理画面があり、それぞれ別チームが開発しているような場合です。中の人がどう言おうと顧客としてみたら同一ブランドを冠した製品だと思いますよね?
依存関係が無くせるのは幻想
組織を区切り、チームを区切り、独立して動けるようにしてみても、チームをまたがる問題は絶えず発生します。よくあるのが「プロジェクトマネージャー」をアサインして「調整会議」を定期的に開催するパターンです。こうなると「上位組織の承認がなければ自分たちの活動内容を進めることができない」となって、全くアジャイルでは無くなってしまいます。
じゃあどうするの?
依存関係が生じるのは認めた上で、調整回数少なく・時間を短く、かつ特定の組織・チーム・人に偏らないよう、自分たちと組織とを「少しずつ」変えていくのが大規模アジャイルの適用だと考えています。「組織変革」なので、組織の形だけ整えて或る日突然始められるものではありません。
まずは自律して自走できるチームを1チームきちんと立ちあげる。そのチームメンバを少しずつ増やしながらアジャイルを実施する単位を組織の上位に移していく。これを数ヶ月から数年単位で地道に推し進める。本当に必要ならば着実に取り組みましょう。
LeSS Study LeSS本読書会 第4回
LeSS Study LeSS本読書会 第4回
第3回に引き続き、恵比寿 Redhatさんでの開催でした。 3回に渡って続いていた第2章が終わり、第3章もテンポよく終わりました。
Q: 「少しかじる」は「スパイク」と同じ?
A: 「少しかじる」は将来の計画や全体のアーキテクチャを詳細に詰めるには知識が不足しているので、試しに何か取り組んでみて、わかったことを踏まえて少しずつ肉付けしていこうというアプローチ。
「スパイク」は将来のスプリントで障害になりそうな項目に事前に取り組んで見通しをよくすること。(スクラムにおける技術的スパイクの進め方 | Ryuzee.com)
重複しているものもあるが、スパイクの方がより広い活動をカバーしている…ように思える。
Q: LeSSを導入する際に「教育とコーチングの提供」とあるけどどうするのがよい?
A: 大規模スクラムの本を読む。他のLeSS本もあるけど実践編の位置付けなので入門には辛そう。
実践者研修は3日で30万円とおすすめだけど少し高価に感じる。だがプロジェクトの失敗コストを考えたら10人送り込んで300万円くらい十分ペイするのではないか。みんな教育にかける投資を軽視しがちだよねー。
Q: ボランティア募ってLeSS導入を進めるんだね
A: LeSSを導入すると決めたプロダクトの担当からボランティアを募るのではなく、全体からボランティアを募ると本では書かれている。LeSSの導入はトップダウンだけでなくボトムアップの力も必要なので狭い範囲から探すよりも、全体から熱意のある人を探して集めた方が良い…ということかな。
Q: 著者は特定の団体・バックグラウンドを持つ人に恨みがあるのかな?
A: 「元PMIプロジェクトマネージャだというだけでLeSS導入者に任命するな」ということに対しての指摘。 著者が個人的に嫌な経験があったのかもしれないけど、著者が伝えたいのは「肩書きでなく、実際に手や頭を動かして組織文化を変えたことがある人を探せ」ということなのだと思います。
Q: ラーマンの法則って聞いたことがないんだけど
A: ラーマンの法則とは下記を指す。
- 組織は、中間および現場のマネージャーや、単一専門職といったポジションの権力構造を維持するために、暗黙に最適化されています。
- 1の結果として、組織を変えようとする試みは、今まで使っていた用語をただ、別の名前に変えるか、用語を大量につくって何か分からなくする事で現状を維持します。
- 1 の結果として、組織を変えようとする試みは、弱みを指摘される事を嫌がったり、マネージャー/スペシャリストの現状を維持しようとする人々により、「純粋主義者」「理論主義者」「革命主義者」「現実に合わせるためにカスタマイズが必要だ」と非難されます。
- 文化は構造に従います。
要するに「スクラムを導入したけどこれまでのプロジェクトマネージャーがスクラムマスターという呼び名に変わっただけで、中身はスクラムのプラクティスをつまみ食いしていて全然アジャイルな開発できてないよね」という、よく起きがちな状況を揶揄したものです。
この法則他で聞かないよねという話になりましたが、大規模スクラム本の著者「クレイグ・ラーマン」氏が この本で提唱した法則 だからだと思います。
Q: LeSSは導入時に雇用を保証するんだね
A: 導入が進むと組織がフラットになり、マネージャー層の役割が減ってくるから給料が減ったり、仕事がなくなるかもという不安は排除しなければならない。そうしておかないとLeSS導入の障害となり、あの手この手で妨害してくるかもしれない。
海外の企業だと個人が優秀かどうかに関係なく、部門ごと閉鎖しまとめて首を切る「ポジションクローズ」があるため、LeSSのこの考え方は結構珍しいのかもしれない。
Q: 並列組織がよくわからなかった
A: 既存の組織構造を少しずつ変えてLeSSを導入するのではなく、LeSS導入後の受け皿組織を先に作り、LeSS導入が済んだチーム・メンバを新しい組織に移動しながら導入を進める方法。
大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法
- 作者: 榎本明仁,木村卓央,高江洲睦,荒瀬中人,水野正隆,守田憲司
- 出版社/メーカー: 丸善出版
- 発売日: 2019/01/30
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
「Netflix日本参入秘話」を聞いてきました
1時間程度の講演に、1時間のQ&Aと大変濃い面白い時間を過ごせました。
講演者の竹中さんについて
半導体エンジニアとしてキャリアをスタートし、外資系コンサルティング会社のベイン・アンド・カンパニーに転職。ベインではサンフランシスコと東京にて勤務。その後、PEファンド投資先である小規模な日系機械メーカーの執行役員、ソニーの研究開発企画部門の部長、日本の不動産テックの先駆けとなったソニー不動産株式会社の創業・執行役員などを歴任。直近では2015年1月より動画配信の世界的大手であるNetflixの日本参入に際して日本での2人目の社員として参画し、2018年10月までファイナンス・ディレクターとして事業・コンテンツ戦略の立案やバックオフィスのマネジメントを担った。
Netflix日本法人2人目の社員でサービス立ち上げから、Japan CFOの職務である会計、それ以外に採用・バックオフィス・経営企画など何でも担当したそうです。
Netflixについて
NETFLIXの最強人事戦略 自由と責任の文化を築くとかぶる話も多かったです。
- 作者:パティ・マッコード
- 発売日: 2018/08/17
- メディア: 単行本（ソフトカバー）
主要事業と歴史
- 1997年にDVDメーリングビジネスの会社として創業
- 2007年からオンラインストリーミングのビジネスにピボット
- 2011年にオリジナル・コンテンツの制作を開始。
近年はオリジナルコンテンツ制作への投資を拡大しており、年間の予算は兆円単位(昨年が1.4兆円とか)。 連続ドラマのロスト・イン・スペースは1話10億円の制作費がかかっている。 フリーキャッシュフローは大幅なマイナスとなっているが、これは赤字体質の企業だということではなく、Amazonのように成長に大きく投資しているため。
グローバルでUI含めて単一のサービスを展開している。 売り上げのほぼ全ては定額課金の会費から。残りのわずかな収入はUSで残っているDVDレンタル事業とのこと。 定額課金の価格帯はグローバルでほぼ同じである。わずかな違いは為替変動程度。
事業戦略
Netflixの事業戦略はIR向け資料で公開されている。
一般的な企業での事業戦略資料は選択肢の幅を広く保つため意図的に「ふわっとした」表現を使っているが、Netflixでは明確に書いてあることが特徴である。
- PPVをやらない
- We don't offer pay-per-view or free ad-supported content.
- 広告をやらない
- We are about flat-fee unlimited viewing commercial-free.
- 映画とテレビシリーズを配信するエンターテイメントネットワークである
- We are not a generic "video" company that streams all types of video such as news, user-generated, sports, porn, music video, gaming, and reality. We are a movie and TV series entertainment network.
上記の戦略を決定した理由の背景は200〜300ほどあり、社内では公開されていて見ることができるらしい。
企業文化
SlideShareで公開されている「Culture Deck」の通り。
www.slideshare.net
他の企業でも規定されている、「こうありたい」という理想が書かれているが、Netflixがユニークなのはこれが実際に運用されていること。
下記のような質問を他企業の方からもらったそうだが、回答は他企業ではなかなかないものばかりとなっている。
- Q: KPIはなんですか → A: ありません。ユーザのためになることをしていたら売り上げが上がると考えています。
- Q: 人事考課はどうしていますか → A: 人事考課はありません。
- Q: ワークライフバランスはどうとっていますか → A: Netflixでは有給休暇の上限ありません
- 実際取り放題らしいが、日本のジョブオファーでは「最低20日」という記述になっていたらしい。
Freedom and responsibilities
Culture Deckの一つを取り上げて具体的な取り組みの紹介があった。 Netflixでは事業領域を絞り、優秀な社員を採用することに心血を注いでいるが、それは「タレント密度の向上を、事業の複雑性向上よりも早くやる。」という戦略に基づいている。
一般的に事業が成長すると複雑性が増してしまう。例えばメルカリはフリーマケット事業に加え、メルペイという金融事業が最近増えた。両者は異なる事業領域であり、異なる取り組みをする必要がある。さらに社員数が増えると優秀な社員の割合は低下する。 複雑性に立ち向かうのに、優秀な社員の割合があるしきいを下回ってしまうと組織に混乱とエラーが増加する。
そこで多くの企業では下記から選んで対処している。
- クリエイティブであるために小さい規模を保つ
- プロセスを作らずに頑張る
- しっかりとした業務プロセスを構築する
- この結果としてプロセスがどんどん肥大化し、優秀な社員が離れていってしまう。
Netflixは新たな選択肢として「4. より優秀な人材を集めてカオスを抑える」としている。 「Long-Term View」で事業領域が明確に規定されているのも、人材採用に注力しているのも全てはこのためである。
明確な事業方針を土台に、企業のカルチャーが規定されている。その上にシンプルな社内ルール・製品があり、優秀な社員がそれぞれの判断で動く。
これらを補強するものとしてデータを重視する分析、頻繁な社員合宿、ディベートカルチャーがある。
データ共有・分析と戦略的活用
グループと責務
Netflix内のメンバは概ね下記の3グループに別れている。
Science & Algorithm ⇄ FP & A ⇄ Content Acquisition
Content Acquisitionはコンテンツ確保に責務を持つ。よそと契約してきたり、コンテンツを独自に制作するのがここ。映画会社出身者が多い。定性的で、未来を予測して考え、個別のコンテンツタイトルごとに考える。
Science & Algorithmはコンピュータ・エンジニアリング・統計の専門家である。定量的で、過去のデータを元に解析し、個別コンテンツを束ねたカテゴリレベルで傾向や対策を分析する。
FP&Aは間に入る調整役。コンサル出身者が多いらしい。
分析手法
Netflixは原理的にサイト上でのすべてのユーザの行動を収集し分析することができる。 例えばユーザ情報、コンテンツ視聴データなどがある。 しかし、実際に使っている指標はすごくシンプルなものを追っている、Netflix流視聴率とか。
仮に分析できても経営と相関の高い指針・施策を導き出すことは難しい。 例えばKonMari ～人生がときめく片づけの魔法～はアメリカで社会現象にもなった大ヒット作だが、「この作品ヒットするかな?」とアメリカ人に聞かれて自信を持って答えられる日本人は少ないだろう。 なのでコンテンツ作りはArt半分、Science半分でやっている。
日本参入の舞台裏
- 採用について
- 初期の採用では苦労した。LinkedInで連絡しても会ってもらえなかった。
- 日本オフィスでも英語がほとんど。ペラペラでないと雇えない。
- 日本で社員を雇うにしても本国で面接をすることになる。日本で面接して本国に候補者を送っても不採用になることが多かった。本国での人気が高く、優秀な人を見る目が肥えた結果、日本からの応募者のレベルが相対的に低く見られているかもしれない。
- 人事考課と評価を切り離して運用している。
- 関連づけたたまま360度評価を導入すると「褒め合い」に着地してしまう。
- もっとパフォーマンスをあげるためのアドバイスを送る
Q&A
Q: コンサル・SONYの経験は役にたったか
A: 前職(SONY)の経験はほとんど捨てた、忖度とか。 ネットフリックスのやり方を身につけてからはコンサル時代の仕事の進め方が役立っている。
Q: 部下の育成
A: 自走できる人材を採用し、ネットフリックスのやり方を伝えてあとは放っておく。 Netflixではアメリカに優秀な人材が多く、ロールモデルを社内で見つけやすい。 ロールモデルと何が違うかを考えてもらうきっかけを作るだけのことが多い。
Q: 独自の文化が生まれたきっかけ
A: 2000年代前半のITバブル崩壊時に社員のレイオフを行った。すると会社のスピードが速くなった。 創業者のヘイスティング氏が会社にどんな変化が起きたのかを熟慮した結果、優秀な社員の密度を高めた結果だと結論づけた。 そこから今の経営スタイルが確立した。
Q: 評価のやり方
A: 評価は主観で行なっている。数値化せずともパフォーマンスの悪い社員は皆に認識されている。
360度フィードバックは「あなたがもっとパフォーマンスを上げるために」の観点で行う。 これは能力の高低とは関係なく行うことができる。 自身の経験だと働き方の根本に関わるフィードバックが役に立った。「担当する領域を絞ってほしい」「ハイレベルの判断ばかりでなく、タイトルレベルに入り込んで欲しい」など。
感想
コンテンツ系の人、コンサルの人、エンジニアと多様な人が多様な興味を持って集まった会だったようで、Q&Aはいつまでも終わらずどの質疑も大変面白かったです。
スクラムマスターを雇う時に聞いてみるとよい38個の質問
はじめに
楽しそうなので回答してみました。
自分の回答
アジャイルマニフェストでは「プロセスやツールよりも個人と対話を」といっている。プロセスを守らせるスクラムマスターは、それとは反対のことをしているのではないか？
型を守らせることで、「いつ」対話して「何を」得るのかをチーム・メンバに習得させるためと考える。 なので初めてスクラムに取り組むチームは最初からカスタマイズしようとせず、教科書通り全てのプラクティスを取り入れるべきだと考えている。標準とどうしても合わないものは後から見直しても十分間に合う。
自分の組織でアジャイルがうまくいっていることを示す兆候は何か？また自分の働きが成功している兆候は何か？
プロダクト開発・プロジェクトがステークホルダーの予想通り(予定通りではない)進捗していること。 スクラムマスターが扱う課題が技術・メンバなど内のものから、チーム・組織・プロダクトなど外に向かって変わってきていること。
追跡しないといけないメトリクスはあるか？もしそうだとしたら何の目的でどのメトリクスを追跡するか？
アジャイル開発・スクラム開発を取り入れて改善したかった事項をメトリクスにすれば良い。プロダクト・組織によって異なるので正解はない。 メトリクスはプロダクト・チームの状況を把握するきっかけとして使うべきで、値そのものを目標化しない方がよい。例えば生産性を上げるためベロシティを評価の指標としたらチームは見積もりの数字を大きくするだろうし、デプロイ回数に注目したら必要とされている顧客価値を提供できているかが後回しになるのではないかt。
あなたのチームのパフォーマンスは常にコミットメントを達成できておらずベロシティも安定していない。考えられる理由はなにか？そして問題をどのように指摘するか？
考えられる理由
- スケジュールが固定化しており、プロダクトオーナー・ステークホルダーがチームにバックログアイテムを与えすぎている。
- チームがスプリント期間中に全てのアイテムを完了できなくても良いと考えている。
- アイテムを完了させるための事前準備(アイテムのリファインメント、適切な分割)ができていない。
- 必要なスキルセットがチームに揃っていない。
対策
- スクラムマスターはデイリースタンドアップでアイテムが終わらない可能性を懸念として表明する。
- チームのふりかえりで議論の俎上にあげてもらう。
- 次のスプリントでは扱うアイテムを少なくし、完了させる状態が定常であることを認識させる。
- 準備・スキルの問題だと感じるときはリファインメントのやり方を見直す・技術習得の研修を計画するなどチームをサポートする対応を取る。
製品のディスカバリープロセスにスクラムチームは参加してよいか？その場合はどのようにするか？
もちろん参加してよい。 リファインメントに顧客・スクラムチームを招き、直接議論させる。
設計上プロダクトオーナーの役割はボトルネックになる。価値が最大になるよう、どのようにプロダクトオーナーをサポートするか？
バックログがメンテナンスされている状態を保てるようにサポートする。 上位にあるアイテムが適切に分割・見積もりされ、チームが着手できる状態になっているか、細かく詳細に入りすぎずプロダクトオーナーのマイクロマネジメントになっていないか、アイテムがステークホルダー・開発チームから上がっているフィードバックを考慮した上で妥当な優先順位で並んでいるかを確認する。
どのようにスクラムチームがしかるべきステークホルダーにアクセスできることを保証するか？
スプリントを進めるにあたりステークホルダーへのアクセスが必要であればプロダクトオーナー・スクラムマスターに事前の断りを入れることなく直接コンタクトをとって進めてほしい。プロダクトオーナー・スクラムマスター・何らかの組織で決まった定例会議をボトルネックとしたくない。ただし、両者の話し合いで決まったことがあるのであればプロダクトオーナー・スクラムマスター・打ち合わせに参加していない人に対していつでも見えるようにして欲しい。
どのように複数の異なる部門にまたがってアジャイルのマインドセットを広げるか？ITじゃないステークホルダーをコーチするのにどんな戦略をとるか？
まずはうまくいく1 チームを作る、広げるのはそれから。 ITじゃないメンバを巻き込む場合はカンバンの導入から入る、その次は定期的な振り返りかな。
上級管理職にどのようにスクラムを紹介するか
「今回のプロジェクトは自社にとって初めてのことが多いので、事前に詳細な計画を立てるのではなく、少しずつ検証しながら方針修正していきます。XX週間(1〜4)ごとに動くものを用意するので、ステークホルダーのあなたにはぜひアドバイスをいただきたいです。このご時世、メンバーの生産性も上げていかないとやっていけないので、こまめに振り返りを行い改善点を直していくようにします・・・」みたいな。
あなたはすでにステークホルダーにスクラムのトレーニングをしたとする。この考え方を適用しようとする初期フェーズのあと、スクラムの適用を続けることに同僚が激しく抵抗するような障害やハードルにぶつかったとする。このような状況においてどんな戦略を取るか？またどんな経験があるか？
- 抵抗する人と話し合いの機会を持つ
- まずは1〜2週間やってみて、それから再度話しましょう
それでも改善が見られなく、他のメンバは順応し、チームの阻害要因になっていたらチームから外すことを検討する。
プロダクトオーナーはステークホルダーの要求をプロダクトバックログ項目に落とし込んでその見積りをチームに求めることになる。その流れでよいか？
その流れで良い。バックログアイテムの分割に悩むようであればスクラムマスターと一緒にチームが取り組みやすい単位になるよう分割を行う。
チームに最新情報やマーケット状況を伝えるためにプロダクトオーナーにどんな情報を要求するか？
顧客・ステークホルダーの生の声を伝えて欲しい、できればそのまま。
誰がユーザーストーリーを書くとよいか？
プロダクトに関わる誰が書いても良い。チームメンバ・スクラムマスター・プロダクトオーナー・ステークホルダーなど。
よいユーザーストーリーとはどんなものか？どんな構造か？
「何をやるか」だけが書いてある。「どうやるか」についての記載がない。 さらにやることによって、「誰にとって」、「どんな価値があるか」、さらに「どうすれば価値を提供できているかを確認できるか」が書いてあると良い。
「Readyの定義」には何が含まれているべきか？
「何をやるか」について、チームが作業工数を見積もられる情報が揃っていること。
ユーザーストーリーを時間で見積もらないのはなぜか？
見積もりは正確にできない。担当するチーム・メンバーによっても必要な時間が変わる。 時間で見積もるとその時間内に完了させることが外に対してのコミットメントになりやすい。
プロダクトオーナーはあとになってから取り組むようないろんな種類のアイデアを追加してくる。結果的にいろんなタイミングで取り組む200個のチケットができたとする。それに対してどのように取り組むか？スクラムチームは200個のチケットに取り組めるか？
チケットが何個あろうがチームがスプリントに取り組めるのは上位の数個に限定される。 200個のチケットで重要なものが上位にきており、リファインメントがされていて、開発スピードとそこから予測できる開発計画に対してプロダクトオーナー・ステークホルダーと合意がとれていれば問題はない。
チームがもっとも価値のあるストーリーに取り組めるようにするためにどのようにスプリントプランニングにスクラムマスターとして貢献するか？
プロダクトオーナーが上位に並べたアイテムについて、背景を質問する。
ユーザーストーリーの価値をどんなメトリクスに基いて判断するか？どんなメトリクスは受け入れがたいものか？チームのコミットメントの権限を侵犯することなくどのようにもっとも価値のあるユーザーストーリーを選べるようにファシリテーションするか？
開発工数に対して提供できる価値が大きいものを選ぶ。 開発できそうな目処が付いているのであれば提供できる価値の大きさだけに基づいて並べることもある。 売り上げやユーザ数だけに着目すると技術負債の解消に着手しづらくなるため、チーム・プロダクトオーナー・ステークホルダーで数スプリント単位の大まかな方針を握っておきたい。
上位に持ってきたいアイテムがあれば、リファインメントの際などにプロダクトオーナーにコメントを伝える。最終的にどう並べるかはプロダクトオーナーに任せる。
どれくらいの時間をリファクタリングや重要なバグの修正や新しい技術やアイデアの調査につかうのが適切と考えるか？
ステークホルダー・プロダクトオーナー・メンバーと合意が取れていれば割合を気にすることなく費やして良いと考える。 とはいえ0にすると将来技術負債・スキル不足で苦しむことになるので毎スプリント10%ぐらいの時間は使うべきと考える。
チームの個人にストーリーやタスクを割り当てようとするプロダクトオーナーをどう扱うか？
スクラムマスターを通すように意見する。 バックログリファインメントなどプロダクトオーナーの責務に集中するよう何かプロダクト全体の課題になっていることの解決を依頼し、チーム内のやりくりは任せてもらうよう話をつける。
チームメンバーによるタスクのつまみ食いをどのように扱うか？
バックログアイテムの「上から」順に「1つずつ」担当するよう伝える。
ユーザーストーリーが最終的に確定していないがスプリントの2日目には確定する状況で、プロダクトオーナーはそれをスプリントバッグログに入れようとしている。どのように行動するか？
無理くり入れ込もうとしているならば、次のスプリントに回せないか話をする。もう少し時間が取れたらまた考えが変わるかもしれない。
どうしても今のスプリントに入れ込みたい場合、計画時に担当するアイテムを少なくして入れ込む余地を残しておく。ユーザーストーリーが確定し着手することになった場合も、担当する全アイテムがスプリントで完了するかをチームで判断し、終わらない場合はどれかを諦めてもらうようプロダクトオーナーと相談する。
スクラムチームのメンバーがスプリントプランニングに参加したがらないだけでなく、時間の無駄だと考えている。このような態度をどう扱うか？
なぜ時間の無駄だと考えるのかをチームメンバでスプリントの振り返りに話してもらう。 もし結論が「時間の無駄」だとなってしまった場合、その時のチームの課題を議題として放り込み、それでもスクラムのセレモニーが時間の無駄かを再度考えてもらう。
チームのサイズや経験度合いに関わらず全部のチームにスタンドアップを薦めるか？
勧める。 毎日、同じ時間に、短時間でチームの状況認識を揃えることに価値がある。
なにか困っていることの助けが必要なとき次のスタンドアップまで待つことを期待するか？
期待しない。困っているときはすぐにアラートを上げて欲しい。
スタンドアップをリードして単なるメンバーに対する報告セッションにしてしまうような人をどのように扱うか？
司会は持ち回りにする。
メンバーからの報告はチーム目線の内容で話してもらう。
- チームのために昨日何をしたのか。
- チームのために今日何をするのか。
- チームにとって障害になりそうな事項は何か。
スタンドアップが無駄だと思っていて遅刻して来たり協力的でなかったりもしくは出席すらしないような人をどのように扱うか？
- 叱る
- チームのメンバから外れてもらう。
スクラムチームのスタンドアップにステークホルダーは誰も参加していない。この状況をどのように変えるか？
デイリースクラムはチームのためのセレモニーなのでステークホルダーがいなくても特に問題はない。
分散チーム間のスタンドアップをどのように進めるか？
分散チームの定義が1つのチームが複数拠点に離れていることを指しているのであれば…
- 拠点をまたいだチーム構成にならないよう分割を検討する。
- 拠点をまたいだチーム編成が避けられないのであればZoomなどのツールを使い、メンバの顔が遠隔地にあっても見える状態を作って実施する。
スクラムチーム用の物理カンバンボードをいま書いてください
| Plan | Do | Check | Done |
|---|---|---|---|
| □□□□ | ■ | ■■ | ■ |
| □□□□□ | ■■ | ■ | |
| □□□ |
- Plan : 未着手
- Do : 実施中
- Check : レビュー待ち
- Done : 完了
各タスクは数時間で終わる粒度まで分割する。 タスクは先に着手するものを右側に置く。
だれがふりかえりに参加してよいか？チームだけか？プロダクトオーナーも参加してよいか？
誰が参加しても良い。プロダクトオーナーも参加して良い。 ただしマネージャーは参加するとメンバーが意見を萎縮してしまうかもしれないので、あとでスクラムマスターからふりかえりの概要報告を受けることで出たがったとしても納得してもらう。
チームが健全な状態かをふりかえりの中で確認するか？それとも不要か？もし必要だとするとどうやって確認するか？
問題がきちんと吐き出されているか、なんとなく問題が先送りや見て見ぬ振りされていないかを確認する。
過去に使ったふりかえりのフォーマットはどんなものか？
KPT！
どうやってマンネリを防いでいるか？
- 自分たちが取り組んできた改善をまとめ、チーム外に紹介する。そこでのフィードバックをチームで検討する。
- リスクは高いが、大きい学びを期待できる「スプリント中の実験」を何か定める。
チームはいつも妥当なアクションアイテムを選んではいるものの、実際に行動できていない。この悪しき習慣をどう扱うか？
改善項目であげる数を絞る。 毎日のデイリースクラムでリマインドする。 改善項目をバックログアイテムの一つとして取り扱う。
どうやってアクションアイテムのフォローアップを薦めるか？
毎日のデイリースクラムでリマインドする。 着手状況をチームに確認する。
他の方の回答
LeSS Study LeSS本読書会 第3回
LeSS Study LeSS本読書会 第3回
第2回に引き続き、恵比寿 Redhatさんでの開催でした。 第2章の残りが対象でしたが、今回も途中の議論が盛り上がり完走できませんでした。
Q: 設計ワークショップはいつやるのか?
A: 必要なときにやる、いつやってもよい。
設計ワークショップは第2章の実際のLeSS開発事例で紹介されていた取り組みで、複数チームが関係する開発・修正がスプリントで生じた場合、事前に設計スプリントや設計ストーリーをやることなく、スプリント計画前後で関係するメンバーが集まり短期間で設計を済ませるという取り組みです。本の例ではスプリントプランニング2の後になっていましたが、設計ワークショップによって依存ストーリーやタスクの見落としなど気がつくこともあるので前にやっても良いよという話をしました。
Q: LeSSをどうやり始めたら良いのか? 導入手順は明確に規定されているのか?
A: 特に規定されていない。やりながら学ぶ。
SAFeの開発経験がある方からの質問でした。SAFeは導入手順が細かく規定されており、その通りに従っていけば悩むことがないそうです。とはいえ手順が多くて導入コーチ無しには始められない気もするのですが…
LeSSでは導入規定は特に規定されていません。ただおすすめの導入タイミングはチームメンバが増えてしまったことで2チームに分割する必要が生じた時です。他のスケーリングフレームワークよりもオーバーヘッドになる役割やセレモニーが少なく、スクラムを自然とスケールさせられます。
いきなり大規模に始めるのではなく、まずはうまくスクラムが回せる1チームを作ってからスケールさせるのが定石と何人かの方がおっしゃっていました。
Q : LeSSはうまく行くのか?
A: うまく行くよ！
「LeSSが使えると思って勉強会をやっているのか、使えるかわからないから勉強会をやっているのかどっちか」という質問でした。 実際にLeSS経験があるのは私一人だったようですが、「うまく行くよと」お答えしました。
Q: プロダクトオーナーにいつ成果物を見せるのか? スプリントレビューまで待つ?
A: いつでも、できたらなるべく早く見せる。
スクラムでやりがちな間違いとして、チームが完了させたストーリー・アイテムをスプリントレビューまでプロダクトオーナーに見せないというものがあります。できたものは早く見せた方がフィードバックがもらえるのでどんどん見せましょう。
アンチパターンとしてスプリントレビューで初めて見せると、スプリントレビューが細かな進捗確認の場や、成果物の出来栄えチェックの場になりがちです。
Q: チームは「コードでコミュニケーションをとる」と短くかかれれているが、込められている意味が大きい。
質問ではなく感想ですが、LeSSでは全チームが全コンポーネントを触り、頻繁に統合することで互いの開発が関連することを早期に検知します。コードがコンフリクトしたり、テストが通らなくなったり、設計に食い違いが生じたりなど。問題が生じたら相手の席まで歩いていき、話し合いを行います。
頻繁に統合を行うにはブランチを切らず、マスターで開発をする癖をつける必要があります。ワントランク開発 - tuneの日記で紹介した内容ですが、多くの開発では「最高のプルリクエスト」を追い求めがちです。
Q: コンフリクトしないの?
A: 特に問題になることはない。
作業に支障をきたすほどコンフリクトするのであれば実装や設計がまずい。 テストを回し終えないと次のコミットができないルールがあるのならば、テスト時間が長いなど別の問題を抱えている可能性もある。
コンフリクトしないように事前の設計やタスク分割を頑張るのではなく、細かくマスターに修正を入れ込んでいくやり方を習得したり、テストの実行時間を短くしたりして、根本的な解決を目指す。
Q: オーバーオールレトロスペクティブとは?
A: プロダクト開発全体の課題を考える場である。
チームごとの振り返りの後に行われる、複数チーム横断でプロダクト開発全体の問題を議論する場である。
私が勘違いしていたのは
- チームの振り返りの共有会では無い。
- チームの問題のエスカレーションの場では無い。
の2点です。
大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法
- 作者: 榎本明仁,木村卓央,高江洲睦,荒瀬中人,水野正隆,守田憲司
- 出版社/メーカー: 丸善出版
- 発売日: 2019/01/30
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
