nDiki : スクラムマスター
2016年12月20日 (火)
第9回 エッセンシャル スクラムを読む会
社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会9回目。今日は第9章 プロダクトオーナー。
自分がプロダクトオーナーをしていることもあり発表担当をしました。
受け入れ条件の定義と検証
受け入れ条件が満たされていることを確認することがプロダクトオーナーの主な責任の1つにあげられています。これはスプリントレビューで行うのかなと勘違いしていたのですが、プロダクトオーナーによる受け入れ条件の検証はスプリントレビューまで待たずにスプリント実施のときに行うとあり、ここは学びになりました。スプリントレビューでデモが許されているのは完成した機能だけとのことです。
ただ CSM によるとプロダクトオーナーが忙しくスプリントレビューのタイミングになっているところも多いらしいです。
誰がプロダクトオーナーになるべきか
ネットサービス開発は商用開発にあたるので「顧客の声を代弁する社員(プロダクトマネージャーなど)がなる」に相当しますね。
その他の役割と組み合わせ
プロダクトオーナーとスクラムマスターを兼任するのはよくないという点については、それぞれ違う行動指針で動くものだからと CSM がいっていました。確かに。
プロダクトオーナーとして余裕があれば複数チームを担当するのもありと本書には書かれています。私はいま3チームをみているのですが、スクラムのアクティビティにかかる時間的に3チームが限界ですね。2チームまでが適切な感触です。
プロダクトオーナーチーム
チーフプロダクトオーナーという役割が出てきますが、チーフプロダクトオーナーは直接開発チームを見ないようなのでそれってもはやプロダクトオーナーじゃないんじゃないかと思ったのですがどうなんでしょうか。
プロダクトオーナー? プロダクトマネージャー?
勉強会ではプロダクトオーナーとプロダクトマネージャーの違いについてディスカッション。個人的にはスクラムだとスクラムマスターという存在がいるので、プロダクトオーナーの方が少し楽なんじゃないかと思っています(スクラムではない体制におけるプロダクトマネージャーに比べて)。
勉強会参加者にプロダクトオーナーになりたい人はと聞いたところ、やりたい人・やりたくない人双方いました。 CSM は(決して軽視しているわけではないけれども)「プロダクト」よりも「プロセス」の方が面白いからプロダクトオーナーになりたいとは思わないとのことでした。なるほど。
2017年1月10日 (火)
第10回 エッセンシャル スクラムを読む会
社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会10回目。今日は第10章 スクラムマスター。
「私は 問題を解決するためにいるわけではない。あなた方が問題を解決できるようにここにいるのだ」
チームに作業を依頼したり、仕事のやり方を指示したりすることもできない。スクラムマスターには仕事を完成させる責任はない。
スクラムマスターはコーチのように振る舞いプロセスのリーダーとして支援する役割の人です。
スクラムマスターの存在はスクラムのかなり大きな特徴といえる要素だと思っています。スクラム以外の開発プロセスで同様にコーチ的な役割の人は定義されているのでしょうか。そんな特筆すべきスクラムマスターですが、期待よりかはちょっとあっさりな説明だった感じはします。
誰がスクラムマスターになる?
スクラムマスターの経験豊かな人がいる場合は別として、多くの場合は今いる人の中の誰かになってもらうことになるのでしょう。その場合は
- ビジネスドメインの専門家の必要はないが技術的知識を理解していること
- コーチとして質問力がある・辛抱強いこと
が良い条件のようです。
人が少ない場合はどうでしょうか。その場合は複数のチームのスクラムマスターを兼任する形が良く、そうでなければ(有能な人であれば)開発チームメンバがスクラムマスタを兼任するのが良いとのことでした。前の章でも書かれている通りスクラムマスターとプロダクトオーナーの兼任はやめた方が良いとmもあらためて述べられていました。
スクラムマスターはとても1章で全てを語れるものではない奥が深いものなのでしょうね。もし担当することになったら沢山学ぶべきことがありそうです。
2017年3月28日 (火)
第21回 エッセンシャル スクラムを読む会
社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会の21回目。第21章 スプリントレビュー。スプリントの中でいちばんうまく出来ていないスプリントレビューの話です。
スプリントレビュー
スプリントレビューは作業結果(出荷判断可能なプロダクトインクリメント)の検査と適応をするアクティビティです。
不都合な真実も含めて、現在のプロダクトの状況を透明に見せてくれる。
という、ちょっと最初は勇気が必要なアクティビティです。
この章によるとスプリントレビューはスクラムチームがスクラムチーム外の人に説明しフィードバックを得るための機会なのです。しかしながらついチーム内の確認の場になりがちで、チーム外の人からきちんとフィードバックを得られていないと反省しています。
スケジュールの調整
スクラムチーム外の参加者が最も多く、スクラムのアクティビティの中では最もスケジュールの調整が難しいと述べられています。たしかに。ステークホルダーのスケジュールに合わせてスプリントレビューのスケジュールを決め、それに合わせて他のアクティビティを合わせるのが現実的とのことでした。
スプリントレビューに参加してくれないようなら、それは開発する価値のないプロダクトということである。したがって、プロダクト開発を注視すべきだろう。
きちんと参加者が集まらない場合は同時並行の作業が多すぎないかも見直すべきなのかもしれません。
スプリントレビューのアウトプット
リファインメント(グルーミング)したプロダクトバックログと更新したリリースプランがスプリントレビューのアウトプットだと書かれています。
ほとんどのチームはスプリントレビューでグルーミングをしている。関係者全員が開発の現状と今後を理解して、新しいPBIを作成したり、既存のPBIの優先順位を変えたり、不要なものを削除したりする。
これも全然意識できていないところ。今はコメントをもらって終わりになっています。きちんと対話をしプロダクトの適応をするところまで実現できていないなと。
デモ
デモが難しいからといって、それはデモをしない理由にはならない。
プロダクトオーナー側でも「まぁいいか」と思ってしまうの良くないですね。反省。
2017年4月14日 (金)
第23回 エッセンシャル スクラムを読む会 (最終回)
社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会の23回目。第23章 未来へ。ついに最後の章です。
スクラムは継続的な改善の一形態なのだからこれが最終形態というものは無いし、どのチームをとっても同じというものは無い。プラクティスはあってもベストプラクティスはチームによって違う。準備ができていないからスクラムを始められないというのはそもそも原則に反するので、まずやって学ぼう。現状を変えるよりもスクラムを無視したりスクラムを変更したりすることの方が簡単だけれど、組織を変革するために協力しあいながら確固たる信念をもって立ち向かおう。
そんなメッセージを本章から受け取りました。
第1章の「スクラムは役に立つか?」で出た通り全ての領域でスクラムが適しているわけではないので、盲目的に導入すれば良いというものではなく、領域が変わった場合はスクラムを続けるか続けないかの判断が必要になるのでしょう。もし取り組む領域が「複雑な領域」であるならばスクラムフレームワークはとても強力だということは間違いありません。
「エッセンシャル スクラム」と「エッセンシャル スクラムを読む会」そしてなによりこの半年のスクラム開発経験でスクラムについて多くを学ぶことができました。「エッセンシャル スクラム」は「スクラムガイド」を読んだだけでは得られない広範囲な知識やノウハウが詰まった良い一冊でした。
エッセンシャル スクラムを読む会のふりかえり
エッセンシャル スクラムを読む会を終えたあとは、オフィスのコラボスペースでビールを飲みながらお疲れさま会。参加の皆さんお疲れさまでした。この回を始めてくれたはらかち氏に感謝。休まず毎回参加してディスカッションしたことでいろいろな学びを得ることができました。嬉しい限りなので珍しく私もビールで乾杯しました。いっしょに全回参加した2人のうちの1人である RabbitFake 氏も特にお疲れさまでした。
ふりかえって出てきた話題としては
- 取り組む領域がクネビンフレームワーク(第1章)のどの領域なのかを見てスクラムを採用するかどうか考えたい。
- チームメンバでエッセンシャル スクラムを読むことで「PBI」などの同じ理解で使える言葉が増えた。チームの共通言語作りに貢献できた。
- 原則大事(第3章・第14章など)。
- WIP を下げる重要性をあらためて学んだ。
- 準備完了の定義・受け入れ条件が重要。
などが上がりました。
また実際に読む会と並行してスクラムを行ってきた中で
- プロダクトバックログリファインメントで1スプリントにおさまるように適切にプロダクトバックログアイテムを分割するの大変だよね。
- スクラムマスターと開発チームメンバ(エンジニア)との兼任が難しかった。
- スクラムマスターであると同時に組織図上のリーダーという立場でいると、自発的行動を促すのとある程度指示的に動かすのとの兼ね合いが悩ましかった。
- 困った状態であることにメンバが気がつくのを3カ月待った上で物理かんばんを導入してみた(すごい)。
などの話が出ました。
スクラム実践についての「検査と適応」をタイムリーに勉強会をしながら進められて学びの多い半年間でした。
全23回
- 2016年10月25日 第1回 第1章 イントロダクション
- 2016年11月01日 第2回 第2章 スクラムフレームワーク
- 2016年11月08日 第3回 第3章 アジャイルの原則
- 2016年11月15日 第4回 第4章 スプリント
- 2016年11月22日 第5回 第5章 要件とユーザーストーリー
- 2016年11月29日 第6回 第6章 プロダクトバックログ
- 2016年12月06日 第7回 第7章 見積もりとベロシティ
- 2016年12月13日 第8回 第8章 技術的負債
- 2016年12月20日 第9回 第9章 プロダクトオーナー
- 2017年01月10日 第10回 第10章 スクラムマスター
- 2017年01月17日 第11回 第11章 開発チーム
- 2017年01月24日 第12回 第12章 スクラムチームの構成
- 2017年01月31日 第13回 第13章 マネージャー
- 2017年02月07日 第14回 第14章 スクラムのプランニングの原則
- 2017年02月14日 第15回 第15章 さまざまなプランニング
- 2017年02月21日 第16回 第16章 ポートフォリオプランニング
- 2017年02月28日 第17回 第17章 エンビジョニング (プロダクトプランニング)
- 2017年03月07日 第18回 第18章 リリースプランニング (長期計画)
- 2017年03月14日 第19回 第19章 スプリントプランニング
- 2017年03月21日 第20回 第20章 スプリントの実施
- 2017年03月28日 第21回 第21章 スプリントレビュー
- 2017年04月04日 第22回 第22章 スプリントレトロスペクティブ
- 2017年04月14日 第23回 第23章 未来へ
2017年8月2日 (水)
何もコミットしないスプリントで各自好きなことをする
インクリメントの完成に高いコミット意識をもって毎スプリント取り組んできている CS 開発チームがいくつか大きなリリースを終えたので、スクラムマスターと相談して今日からの1週間スプリントは「プロダクトバックログアイテムについては何もコミットしない」で各自好きなことをして良いことにしました。
リファクタリング・技術的負債の返済・開発環境の整備や、調査・学習・ドキュメントの整理など、いつものスプリント中にはなかなかできないことを各自でしてよい1週間です。
普段から持続可能なペースを意識してスプリントプランニングしていますが、それでも頑張り続ければストレスも溜まってくるでしょう。適切なタイミングでブレイクを挟むことで、バーンアウトを防ぎ長期的にデリバリーし続けられるチームでいられればと思っています。
ちなみにこの取り組みは去年別のチームが unwinding period と呼んでやっていたのを真似てみたものです。
今回スプリントがどういう感じだったのかは、いつも通りスプリントレトロスペクティブでふりかえってみます。
[ スクラム ]
2017年10月5日 (木)
見学者がチームに来ることに慎重になった理由
プロセスについて意見が欲しいということでスクラムマスターが別のチームから見学者に来てもらおうとしていたのですが、今回はちょっと気になって反対しました。
一つはまだチームがプロセスを大きく変更したいと思っていないから。チームが大きな課題感を感じていない状態で、変更を前提とした意見をもらっても受け入れられないように思えました。
それからふりかえりの場も見学ということだったのですが、チーム外の人を安直に呼ぶと心理的安全ではない場になって正常なふりかえりにならなくなる恐れが強いも今回は感じました。
まずはチームとして受け入れられるようにしてからのタイミングがいいんじゃないかと今日は思った次第です。
[ 心理的安全性 ]
2018年4月17日 (火)
ふりかえりは「書いてから発表する」
その場で時間をとり全員が発言する内容を手元に書いてから順番にしれっと発表するミーティングスタイルにすることで、出席者全員がミーティングにコミットするようになり、また大きな声の人が勝つことなく全員が他人の意見に左右されずに考えを話せるようになります。これを最初に学んだのは「すごい会議」でした。
「事前に各自ふりかえったことをボード(だったりシート)に書いておいて、ミーティングではそれを話し合う」というふりかえりスタイルは参加しない人が出てくるので良くないと、スクラムマスターが話してくれたこともありました。
次回のふりかえりの時間までに気がついたことを忘れないように書き出しておくというのはもちろん良いことですが、ミーティングの進行の際にも「書いてから発表する」流れを入れておくことが大切だなと思っています。
2019年2月14日 (木)
Developers Summit 2019 1日目 #devsumi
2015年・2016年・2017年以来、2年ぶり4回目の Developers Summit 参加。一昨年には無かった Wi-Fi のスポンサー提供があってとても快適になった。素晴らしー。
朝1番のセッションの冒頭で今回の事前登録が4000人超という話があった。大盛況。会場の混み具合からするともうキャパオーバーも近いのではと思えてくる。各セッション会場でのバーコードチェックがステージ近くで、まだセッションが終わる前に次のセッションの人が誘導されて入ってきたりして、待機列の問題からだろうけれど、ちょっと発表者に失礼なんじゃないかなーとは思ってみてた。
以下セッションタイトルは2月13日時点の公式サイトより。
10:00〜10:45 【14-D-1】 Scrum@Scale入門
株式会社アトラクタ 原田騎郎(@haradakiro)氏
メモ
- スケール
- 全く同じチームを複製してくことはできない。違いのあるチームを増やしていく。まずうまく行っているスクラムチームを2つ育ててから、スケールさせる(そうでないと悪いものがスケールする)。
- Scrum @ Scale フレームワーク
- PO
- 「調査してから…」ではなく「今間違えろ」(辛いけど……)
思ったこと
やはり適切な人数の自己組織化されたチームで構成される体制を作っていきたいな。エッセンシャル スクラムだとプロダクトバックログは唯一なものと書かれていたと思うんだけれど*1、現実的なところ抽象度の違う階層化されたバックログとチーム毎にそれぞれあるバックログという感じでいいんだな多分(エッセンシャル スクラムでも階層化バックログ自体は紹介されている)。
*1 どんなプロダクトバックログをいくつ用意すべきかを考えるにあたっては、基本原則がある。プロダクトごとに、プロダクトバックログをひとつ用意するというルールだ。-- エッセンシャル スクラム 6.7
11:05〜11:50 【14-A-2】 GitHub Actionsはどのような未来を描くのか : コンテナ技術が開くワークフローのOSS化
GitHub 池田尚史(@ikeike443)氏
GitHub Actions で Docker イメージを作成して、デプロイまで実行できるようになるという話。デプロイ以外にも GitHub 内での様々な処理も。
12:10〜12:40 【14-A-3】 GCPに恋してHashiCorpを愛して起業したエンジニアのお話
株式会社grasys 長谷川祐介氏
サンドイッチ。HashiCorp 製品と Google Cloud の紹介。それから企業の話についての自分語りを伺えた。
13:05〜13:50 【14-D-4】 大学におけるイマドキのエンジニア教育
ワイクル株式会社 角征典(@kdmsnr)氏 株式会社アトラクタ 永瀬美穂(@miholovesq)氏
前半永瀬氏による enPiT 事例紹介。
後半角征典氏のエンジニアリングデザインプロジェクト(EDP)を通じた知見紹介。参加者の多様性とモチベーションのばらつきを意識した取り組みが素晴らしい。
こちらでもやはり最適なチームについて(人数・多様性)が取り上げられていた。メンバの多様性によるデメリット(ここではモノづくり工程ではデザイナーができることが少ない)もきちんと示されていて、その上でそうしているという話で説得力があった。
ただ「やってみているという話」ではなく、裏打ちされた方法論を押さえた上での取り組みで学びのある話だった。
東工大生イジりが嫌味がないのも素敵。
14:10〜14:55 【14-D-5】 新技術導入を成功させる組織のつくりかた 〜spanner、GKE導入の実体験から得たこと〜
株式会社コロプラ 廣本洋一氏
- コロプラでのマネージメント事例。2年前に事業部制から機能別組織に。
- コピーベースで新しいアプリケーションを作ることによる課題があった。
- ノーメンテナンス時間というポリシーを前提とした技術選択。
- オーバーエンジニアリングとの戦い。
機能別組織だからこそ、事業部とは別のロードマップで優先度判断ができる部分があるのだなと感じた。
15:15〜16:00 【14-A-6】 レガシーとのいい感じの付き合い方 〜15年続くウェブサービスのシステム改善パターン〜
株式会社VOYAGE GROUP 福田剛広氏 小林徹也氏 駒崎大輔氏
ECナビについて2年弱かけて AWS 移行した話。
サービスの長期運用で技術が古くなり、エンジニアから見た魅力がなくなり新規採用で苦戦したり、在籍エンジニアのモチベーションがダウンしたりというのはあるある話だ。
別だったインフラとアプリの管轄を分けないようにする・オンプレから AWS に移行する・いったんそのままの構成で移すなどは、そうだよねというかそうするよねというかそうしているよねとかそういう感じ。現実的・保守的な判断かなと。
16:20〜17:05 【14-A-7】 ZOZOTOWNのDWHをRedshiftからBigQueryにお引越しした話
株式会社ZOZOテクノロジーズ 塩崎健弘氏
BigQuery 移行事例についての、味わいのある発表。
今日はシャッター音少なめだなと思っていたのだけれど、このセッションは賑やか。聴講者の層が違うのかな。
17:25〜18:45 【14-A-8】 「ITエンジニアに読んでほしい！技術書・ビジネス書大賞 2019」プレゼン大会
高柳謙氏 株式会社丸善ジュンク堂書店 平木啓太氏 株式会社スマートニュース 瀬尾傑氏 株式会社アトラクタ 永瀬美穂(@miholovesq)氏
技術書・ビジネス書のそれぞれトップ3人の著者(や関係者)によるプレゼンテーションと投票・発表のセッション。
About
Naney (なにい) です。株式会社MIXIで SNS 事業の部長をしています。
※本サイトの内容は個人的見解であり所属組織とは関係ありません。