はじめに
はじめまして、こんにちは。NＴＴドコモ 第二プロダクトデザイン部の原です。
アジャイルに挑戦中のコンシューマ向けアプリの開発部に所属し、PBI*1を作ったりといったプロダクトオーナー（以降POと記載）業務の一端を担っております。
せっかくスクラム開発をしているプロダクトに関わっているのだからと2022年の12月に認定スクラムマスター*2（以降認定スクラムマスターをCSM、スクラムマスターをSMと記載）を取得してからもうすぐ１年。。。CSM研修で何を学び、１年間の実務を経た今、自分達のスクラムをどう思っているのかを書き残しておこうと思います。
アジャイル開発に挑戦する皆さまへのヒントの１つにでもなれれば幸いです。
CSM研修の紹介
最初に私が参加したCSM研修を紹介します。
日本人で唯一の 認定スクラムトレーナーであるエバッキーこと江端一将さんの研修です。
社会人経験６か月、スクラム経験３か月の私がこの研修に挑むのは、ひのきの棒で魔王に戦いを挑むくらい無謀なことでしたが、何とか研修を乗り越えて銅の剣を使いこなすくらいには成長できた気がします。
けっこう厳しいトレーニングだとは思いますが興味のある方はぜひ挑戦を！！
参考：https://training.tech-kai.com/tech/user/courses
個人的大事な学びリスト
- スクラムは問題を表面化させるフレームワーク
- SMの責任はスクラム活動の全て・組織の成功である
- スクラムにおける全ての活動は分析できる状態になければならない
- スクラムは1000回伝えるゲーム
- DoneとAcceptance Criteria
- インクリメントは1口サイズのショートケーキを作り続けていくこと
- 計画力を高めることが何よりも重要
- SMが見ているだけで良いのが理想のスクラムチーム
- リリーススプリント*3を行うチームはスクラムをしていない
１．スクラムは問題を表面化させるフレームワーク
スクラムを行う目的は「リリース間隔を短くする」、「仕様変更に強くする」という部分ではなく、「現状を把握して分析をし続けられる環境を作ること」にあるということです。
スクラムのフレームワークはこの目的が達成されるように設計されているので、チームはスクラムに挑戦することで本当にたくさんの問題を可視化できます。こうして表面化された問題に１つずつ向き合って適応しようとする意思を見せるチームはいかなる変化にも適応できる強いチームになりますが、スクラムのフレームワークを行うことだけに注力してしまうチームはスクラムの恩恵を得られず失敗してしまいます。
２．SMの責任はスクラム活動の全て・組織の成功である
スクラムには3つの役割と責任があります。
一番伝えたいのはやはりSMの責任で、SMが担っているのはスクラムという活動そのものの成功だという部分です。スクラムの成功とはスクラムの三本柱が守られていて、自立した強いチームに成長していく環境が構築されていることになります。
SMはこの責任を果たすためであればスクラムチームの外に飛び出て組織全てをスクラムの成功に繋がるように改善させるように振舞って、組織を変えていく必要があります。
いつか私もスクラムの外の組織ごと変えられるSMになれる日が来たら、胸を張ってマスターですとアピールしていこうかなと思います。
注意：
SMの視点と責任からすればプロダクトの成功・失敗そのもの自体の責任を問われる必要はないため、プロダクトを成功に導くことに注力するのはSMの役割ではないです。
SMの役割はプロダクトになんらかの結果がでた状態を利用してスクラムチームをより良い変化をもたらすことにあります。
３．スクラムにおける全ての活動は分析できる状態になければならない
「検査」と「適応」を実行していくためにはスクラムの活動が必ず「分析」可能な状態である必要があります。分析可能な状態とはそれぞれの活動について分析の基準があったうえで分析の対象として認識していることです。分析の基準が設けられていない活動は「検査」も「適応」もすることができないためスクラムチームの行う活動ではなくなってしまうのです。
例）
- 活動前後で変化を促さないスクラムイベント
- 出荷可能な状態にないプロダクト
＝ コンディションが把握できず現状が把握できないため分析不可 - 一旦、とりあえずといった判断基準を持たない意思決定
など、、、
４．スクラムは1000回伝えるゲーム
普段の仕事や日常生活でそれ前も言ったじゃんみたいなことってありませんか？スクラムに限った話でもないですが1回伝えたら理解してもらえるなんて自分勝手な思い込みでしかありません。（はっ！！胸が苦しい。。。）
SMはスクラムの価値を伝えて、スクラムを成功に導いていく役割なのだから、自分が伝えなければいけないことは相手に伝わるまで100回でも1000回でも繰り返し伝える必要があります。その伝え方は言葉だけではなく、ワークショップや意図的に引き起こした失敗や成功の体験なども含めてあらゆる手段が候補になります。また伝える内容だけではなく「いつ伝えるか」が本当に重要なポイントになります。
私が高校野球をしていた頃の監督さんはチームが間違った方向に進んでいても黙っていて、大失敗した時に初めて起動修正をすることでチームの心に響かせるみたいなことをしていたので、あれが伝え方を工夫するということか！！と今更ながらの感銘を受けております（笑）。
５．DoneとAcceptance Criteria
Done：
サービス提供社が担保しなければいけないモノ・コトの総称、スクラムのすべての場面においてDoneは常に満たされた状態にならなければいけない
飲み物の例）
身体に問題を発生させないこと
Acceptance Criteria：
対象へ提供したいと考えているモノ・ことが実現できているか判断するための基準
飲み物の例）
味、量、値段
スクラムにおいてDoneは常に満たされた状態である必要があり、Acceptance CriteriaはDoneが当然満たされた上でのPBIごとの評価基準を超えているかの指標になります。つまり、「不具合のないプロダクト」というDoneがあるチームの作るプロダクトにはどんなタイミングであっても（試験をしていない状態でも）プロダクトに不具合がないことを証明し続けなければいけないのです。
証明しなければDoneを満たせない状態をUndoneと呼び、毎スプリント、Undoneを解消するPBIを着手することがスクラムの成功にとっては大切となります。
またDone⇒Acceptance Criteriaの順番で担保していくものなので、AcceptanceCriteriaを満たしてからDoneの証明をするというプロセスは間違っていることを認識することは非常に重要です。
うーん、難しい。。。
試験をしていない時でさえ不具合がないことを証明するってどうすりゃ良いんだよ(-_-;)
あ、だからTDD*6が激推しされているのか！！( ..)φメモメモ
６．インクリメントは1口サイズのショートケーキを作り続けていくこと
インクリメントは出荷可能な製品単位のプラスを積み上げていくことで、コンポーネントを積み上げていくことではありません。 ケーキに例えるとイチゴやクリーム、スポンジを個別に作ったものはインクリメントではないが、スプーンにのるような１口サイズのケーキはインクリメントになるイメージです。一口サイズのケーキであればケーキとして製品を分析することができてリリースするかどうかの基準にできますが、合体前のイチゴやクリームをみたところで完成したケーキがどんな味になるかが分析できないため製品をリリースする基準とならないってことですね。 確かにイチゴを１個渡されてこのケーキどう思うよって聞かれても、「いやイチゴじゃん！」ってなりますよね。
７．計画力を高めることが何よりも重要
誰もがやりがちだと思うのですが、計画通りに物事が進まなかった時の反省として着目するのはどうやったら計画通りに物事が進んだかという「適応力」の部分ですよね。そもそもの計画が間違っていたのではないかという方向での反省をする方はほぼいないんじゃないでしょうか。
ここで逆転の発想です。
計画通りに物事が進まなかった時には「計画力」を磨きましょう。「計画力」とはあらゆる可能性を見通し複数のサブプランを用意して準備しておくことになります。あらかじめ用意しておいたサブプランに流れて計画を変更するのは計画変更ではなくて、計画通りであると捉えることが大事です。
そもそも「逆算型」の計画は理想的な話をしているだけなので、目標を達成できないことの方が多いです。本来作っていくべきなのは目指すべきゴールの方向に向かって目の前の一歩を変更するといった「積み上げ型」の計画で、目指すべき方向に向かって一歩ずつ歩いていたら目標を達成しちゃっていたね、という状態を作れるのがスクラムの魅力の１つです。
８．SMが見ているだけで良いのが理想のスクラムチーム
成熟したスクラムチームのSMは見ているだけでもスクラムがうまく回ります。なのでSMの最初の目標としてはこの状態を作ることになります。この状態になった後はSMは暇になるのかと言われればそうではありません。今度はスクラムチームをスクラム外の脅威から守ったり、組織をより良く変えていくための行動に出るのです。
９. リリーススプリントを行うチームはスクラムをしていない
リリーススプリントを行うということは、不発爆弾を抱えているのと同じ状態なのでプロダクトは大きくなっていってもインクリメントを重ねているとは言えない状況です。プロダクトが大きくなるスピードは小さくても、内包するバグが発生する確率を下げるように各スプリントでUndoneの解消を行う方が確実にリリースに近づいていると言えると考えられます。
「ウサギと亀」、「急がば回れ」みたいなものです。
ここからがすごく重要なのですが、スプリントごとに行うべきUndoneの解消をおろそかにして最後のリリーススプリントの試験で不具合による延伸が起きた場合、その責任を負うのはDevではなくPOであることはスクラムチームの全員が認識する必要があります。
PBLの優先度を決めるのはPOの責任だからです。過激派SMだとこういったケースでPOから何とかしろと言われると、Dev T全員に休暇を取らせて何も対応できない状態を作ることで、SMとしてのメッセージを伝えたりするとかしないとか。。。
私が所属しているチームのスクラム
ここまで読んでくださっている皆さま、ほんとすみません。だらだらとした羅列に付き合って頂きありがとうございます。
スクラムがいろいろ難しいものだというのは分かったけどじゃあ結局どうなのよって思う方がほとんどだと思うので、最後に自分が所属しているチームで取り組んでいるスクラムについて紹介して終わります！！
良いとこ出てるんかもなぁって部分
① リリース期間
今年度から小さな開発内容のものを2週間1スプリントで開発するようになり、開発着手から最短で1か月後にリリースできるようになりました！！
スプリントが終わった後の試験で不具合を検出したりとまだまだな部分はありますが、1スプリントでインクリメントを出してリリースできるようになったという部分で大きな成果に繋がっています！！
さらに2週間スプリントのチームを2つ作り、それぞれが1週間ずれで開発を行うことによって1週間に1度のアプリリリースを実現しております。
② 開発順位の入れ替え
WF*7時代と比べて緊急の開発案件の差し込み対応ができたり、リリース直前にさらなる追加開発が出来たりと開発に柔軟性が生まれてきています。（WF時代を経験していないので半分想像ですが。。。）
③ 自ら触って検証する
私のチームではスプリントごとに提示される成果物を必ず自分の手で操作したり、社内配布したりして検証します。
成果物を触ることで、「本当に操作性は良くなっているのか」、「ユーザー操作に違和感はないか」、「どのような価値を提供できたのか」などを真っ先に検証するためです。
実際に成果物を触ってみると思っていた動きとは異なっていて、市場リリースの前に再改修を加えることもあります。
これこそ動く成果物で「検査」と「適応」を繰り返していくスクラムらしい成果の１つではないでしょうか！！
まだまだこっから！！って部分
① スクラムの目的の浸透とリスタート
自分自身そうなんですけど、正直なところスクラムの目的感とか価値を理解しないまま、世の中の流れがそうだからという理由でとりあえずでスクラムっぽい開発に挑戦しているように感じます。だからスクラムをすると言いながらリリーススプリントの実施やミニWFの繰り返しから脱却できない。。。
自分たちはなぜスクラム開発をする必要があるのか、スクラムが私たちにどういった価値をもたらしているのかといった部分を改めて整理して再スタートを切っても良いと感じているこの頃です。
② インクリメントの作り方
インクリメントを作るのが苦手です。ショートケーキを作りたいとなった時に、１口サイズのショートケーキの作り方が分からないからイチゴとスポンジを作ってはくっつけてを繰り返すしかない状況が散見されます。あと1スプリントで両手一杯のケーキを作ろうとして失敗することもよくあります。
いかに価値の高い一口サイズのケーキレシピを作れるかがPOの腕の見せ所かなと思うので、チーム一丸でそういった職人を目指そうと奮闘中です！！
③ DevとPOのコミニュケーション
Devからの提案が少なめで寂しいです。。。
PBLに目を向ければ開発を進めるためのPBIばかりで、Dev提案の開発効率や生産性をあげるためのPBIがほとんどない状態になってしまっています。
Devメンバからもっと提案してきてほしいという想いは確かにありますが、理由を考えるとはDev Tが改善PBIを検討する隙間もないほどに開発PBIでいっぱいにしていたり、深い議論を行わないままDev Tの提案PBIの優先度を下げているPO側の責任も少なくないです。
このあたり計画の数 %をDev発信のPBIを実施する仕組みを作ったり、普段のふるまいからDevの提案しやすい環境を作ったりとできることはたくさんあると思うので、少しずつでも変えていきたいです！！
まとめ
記事を書きながら何度も思いましたが、スクラムって本当に難しくて迷子になるフレームワークですね。そして、こんなフレームワークを浸透させてチームを成功に導けるSMという存在は本当にすごい！！って改めて感じます。
実は私の目標はSMになることなのですがそれはまた別の機会に書きたいなと思います。（そんな日来るのか笑）
今後も壁にぶち当たることは多いと思うのですが、社内のスクラムを少しでも良い方向に変えるために頑張っていきます！！
