有志によるスクラム本がでました！
N1! 制度でスクラムエバンジェリストを担当している西野です。
9/11にオフライン開催された技術書典13にて、ニフティ有志で執筆したスクラム本の頒布を行いました！
スクラムマスターの話を中心に、いろいろなチームのスクラムとの戦いの記録が読めます。 以下からDLできるので、まだ読んでいない方はまずDLしてからこの記事を読んでください！
発刊記念イベントしてみた！
喜ばしいことに想像以上のDL数があったので、この本を出すにあたってのバックグラウンドトークイベントを 「ニフティのスクラム」執筆者が語る！ 〜スクラムぶっちゃけ話〜 と題して行いました。
↓アーカイブ動画はこちらから↓
「ニフティのスクラム」執筆者が語る！ 〜スクラムぶっちゃけ話〜 – youtube
「ニフティのスクラム」執筆者が語る！ 〜スクラムぶっちゃけ話〜のサマリー
登壇者
スピーカー：西野 香織（N1！スクラムエバンジェリスト・マイニフティチーム スクラムマスター）
スピーカー：畑谷 啓志（オプションサービスチーム スクラムマスター）
スピーカー：小浦 由佳（社内プラットフォームチーム スクラムマスター）
ファシリテーター：高田 渉（入会システムチーム スクラムマスター）
登壇者LT
ニフティのスクラム」をなぜ出したかと概要紹介
2つのスクラムチームを合体させるとどうなるか?
「ニフティのスクラム」p41 同タイトルの概要紹介
超属人化組織の情シスでスクラム
「ニフティのスクラム」p32 同タイトル記事の概要紹介
スクラム一問一答 〜NIFTY Tech Talk編〜
「ニフティのスクラム」でもスクラム一問一答というコーナーがあるのですが、今回、3人のスクラムマスター同士で本には載せられなかったスクラムに関する疑問について答えてみました。
過去に行った社内スクラムマスターの情報共有会や、お互いに聞いてみたかった内容を質問として取り上げています。
システムを熟知している人の負担が大きくなりがちだけどどうしてる？
システムを熟知している人ばかりに仕事の負担が大きくならないよう、属人化解消をどう進めているか
小浦
- チームメンバーができる程度の粒度までタスクを分解する
- 誰でもとれるようなSBIには頭に★をつけて見やすくしている
- 業務共有やマニュアル化を徹底する
- もともと、それぞれのメンバーが専任的にプロダクトを担当していたので、自分の担当ではなかったプロダクトのタスクを取るよう工夫している
- 違う業務をどのくらいの割合担当したかの検査
畑谷
- モブプロを実施して属人化を解消している
- タイトルにあるぶっちゃけ話的にいうと、もともと属人化が進んでいた
- なんでもモブプロにするわけではなく、コアの部分だけを対象としてモブプロ
- モブプロだとコードを書く効率自体は上がるわけではないが、レビュー時間が短縮されるため、トータルでかかる工数はそこまで変わらない
西野
- システムを熟知している人の理解度を100％だとして、全員が30％くらいまで理解できていれば、理解度100％の人が1人しかいないことは問題ではない
- タスクを分解したときに、このタスクについてサポートする人をタスクに明記しておく
- 畑谷さんのチームと同じくモブプロも導入している
- システムを熟知している人が最初ナビゲーターをやるシーンが多いとおもうが、みんなが慣れてきたら、その人はナビゲーターもドライバーもなるべくせずに見守るようにする
- 熟知している人がどこまで離れても大丈夫かを少しずつ測る
- 急ぎの仕事があると「システムを熟知している人にやってもらおう」となりがちなので、属人化解消期間にはそういう仕事をなるべく入れないような調整も必要
よかったレトロスペクティブある？
ファシリテーターである高田から挙げた質問。KPTをよく使うが、ほかの良かったレトロスペクティブを知りたい。
畑谷
- アジャイルレトロスペクティブズに載っている内容が素晴らしいため、ここから実践している
- 特にタイムラインという振り返りを、データ収集のフェーズでよくやっている
- スプリントの中でやってきたことを付箋に貼って見える化する
- 特に（スプリントをまたぐような）大きな開発で、開発着手からリリースまでを振り返るときに、このイベントでテンションが上がった・下がったということを共有できる
- そこから得たデータで、KPTを考えるといった次のアクションにつなげることができる
西野
- レトロスペクティブは毎回変えるようにしている
- レトロスペクティブについてのqiita記事を書いたのでよかったら読んでほしい
- 障害がおきたときはフィッシュボーンをよく使う
- 起きた障害を魚の頭として、そこから魚の骨のように、その障害を起こした要因としてこんなものがあったかも…というのを書いていく
- レトロスペクティブに限ったことではないが、デイリースクラム以外のあらゆるスクラムイベントでファイブフィンガーをおすすめしている
- 5本指で自分の満足度を表現すする。とても満足なら5（手をパーにする）、まったく満足していないなら0（手をグーにする）
- 畑谷さんが挙げていたタイムラインだが、タイムラインを書く時にどんなイベントが起きたかを抽出するのが記憶ベースだと大変。どうやっているか
- 確かに大変。初めてやったときは、事前にタイムラインを書かせてほしいというような要望が出たりした（畑谷）
- タイムラインを自分もよくつかっているが、思い出すのが大変なのはすごくわかる（小浦）
小浦
- 象、死んだ魚、嘔吐
- 象：見ないふりをしている問題
- 死んだ魚：早くごめんなさいをしたほうがいい悩みの種
- 嘔吐：ぶっちゃけ話
- チームの中で表出してない課題や、メンバーの率直な気持ちが聞ける
今のプロダクトオーナーにどうやって権限を持たせることができたか？
プロダクトオーナーに権限がないと、プロダクトの方向性を見失ってしまうこともあるが、スクラムマスターとしてどのようにプロダクトオーナーの権限を持たせたか
西野
- とても難しい問題
- PO本人も、どんな権限があるかわかってない事が多い
- まずはそのチームで決められることを把握する
- もしPOが決定を渋ることがあれば、それを誰に確認しなきゃいけないかを聞くことで、権限をもっていないことがわかる
- 権限がない状態がなぜ起きているかを知る
- 周囲から（そのスクラムチームが）不安に思われていることが要因となって、権限が無くなってしまっていることが多いので、その不安を潰すようなアプローチをかける
- 例えばリリースを何度も遅延させてしまっていて、なにかするたびに上席にレビューを求められている状態だとしたら、リリースを間に合わせるようにして信頼を取り戻すとか
- 組織全体がスクラムを理解した状態であれば、POに権限を持たせることは難しくないはず
- 組織に対するスクラム支援もスクラムマスターの責務のひとつ。POに権限があるとこういうメリットがあると説明し、共感してもらうことはスクラムマスターの頑張りどころ
- （組織から）スクラムチームが信頼される・信頼できる状態にあることは大事
畑谷
- これという答えは出せない
- 実際POを立てるときにとったアプローチとして、権限をPOに持ってこられるよう上のほうで話し合ってもらった
- 開発の上長経由で、POの上長にアプローチしてもらう
- 上のほうで話し合ってもらうときに、スクラムをする（POに権限を持たせる）メリットの説明をするには、結果が出ていないと難しい
- スクラムをやっている当人はメリットを実感しやすいが、ステークホルダーだとなかなか実感は難しい面もあるかも（西野）
- 最初から（ステークホルダーを含めた）全員が完全に納得してスクラムを始めるのは難しいかも（西野）
小浦
- まだまだ道の途中という感じがある
- 自分のチームの場合はPOがマネージャーなので、権限がある状態
- あるべき状態としては、POとマネージャーは違う人の方がいいと思う。いずれはそうしたい
- PBI管理を、POから開発者に移管して運用している
- ルール上はPOしかPBIを動かせないが、スクラムチームで合意がとれているなら、POの権限を開発者に委譲してもいいと思う（西野）
- POが「開発者はここまでやっていい」と権限を下ろせていたり、POが多忙であったりするならば、（合意をとったうえで）開発者が動かしてもいいという話も聞いたことがある（西野）
- POに権限をもたせて、さらにスクラムチームで細かい権限を分担していくかたちもありだと思う（西野）
- PBIを動かすことそのものはあまり問題がないが、プロダクトの行く末を決めるような力がまだ弱いので、そこへの注力や周囲への説明をがんばりたい（小浦）
スクラムやっててよかったエピソード・一番しんどかったエピソード
畑谷
- よかった：リリースの期間の短縮
- スクラムやる前は「2-3ヵ月かかります」とざっくり見積もっていたことが、1ヶ月でできるようになった
- 集中して取り組むと無駄なくリリースできることが実感できた
- しんどかった：優先度決め
- ひとつのチームで、対象ユーザーは同じだがいろいろなプロダクトを扱っている
- どちらの優先度がより高いかを、プロダクト同士で比較・判断することが難しい
- （プロダクトが違う中で優先度を決められる）真のPOは誰だという悩みもある
西野
- よかった：チームメンバーのモチベーション向上
- スクラム導入後のフィードバックとしてもらった意見
- リリース回数が増えたことで、特にエンジニアのモチベーションが向上した
- 今までは自分しかできなかった仕事がほかの人もできるようになったことで、障害対応のときに絶対に自分がいないといけないという不安が拭え、心理的安全性が確保された
- しんどかった：スクラムマスターがひとりしかいない
- 今は社内でスクラムマスター共有会というイベントがあるので相談先があるが、自分がスクラムを始めた頃はスクラムマスターが各チームに点在している状態だった
- スクラムマスターの振る舞いについて悩んでも相談できる先がなかなか無い
- スクラムマスターが凹んでいるとチームにも悪影響が出てしまうため、スクラムマスターである自身のモチベーションコントロールが難しい
小浦
- よかった：属人化解消
- スプリントごとに誰がどんなチケットを消化したかを検査している。特に（属人化解消の）成果が出たスプリントは、全員で喜び合っている
- 日々の会話のなかで、メンバーから「いつもと違うタスクができて嬉しい」「スクラムやってよかった」というコメントがでてくるとニンマリしてしまう
- しんどかった：スクラムマスターの役割はどこまでなのかわからない
- ひとりで気張って、いつの間にかお母さんみたいになってしまって、勝手にしんどくなってしまっている
- チームのリーダーも兼任しているので、スクラムマスターでもあり、リーダーでもあり、お母さんでもあり……という状況に陥って、凹んでしまう
- women developers summitでその話を西野さんがするそうなので、楽しみ
- 参考リンク）登壇内容こちら：スクラムマスターが「チームのお母さん」にならないための方法 #devsumi
まとめ
同じ会社のスクラムマスター同士とはいえ、チームが置かれている環境や目指すゴールも異なるスピーカー3名でしたが、スクラムについての悩みや課題・喜びは話し合ってみて非常に共感できるものが多かったです。
似たような課題でも解決のアプローチが違うことも知れたので、お互いのスクラムチームの良いところを吸収して、自分のチームの課題解決に還元していきたいと思います。
現場にどのように権限を持たせていくかはもっと掘りがいがあるテーマだと思ったので、また機会あれば
スクラムマスター対談はまたやってみたいと思っているので、スクラムに関する質問などあれば、ぜひTwitterでこの記事を引用して質問をお寄せいただければと思います。（関係者一同、ウォッチしております！）
