スクラムガイド2020を読んで、自分たちのスクラムを振り返ってみた
アイミツ開発チームでエンジニアリングをしている deliku といいます。
スクラムガイド2020を読み直して、改めてスクラムとは何か、何を達成したいのか、自分たちが行っているスクラムを振り返ってみました。
スクラムとは
複雑な問題に対応する適応型のソリューションを通じて、⼈々、チーム、組織 が価値を⽣み出すための軽量級フレームワークである。
スクラムガイドとは
スクラムガイドは、スクラムの公式知識体系です。定義、理論、価値基準、チーム、イベント、作成物の章に分かれて説明しています。スクラムを実践する際は、このガイドを読むことを推奨します。
スクラムの3本柱
3本柱とは「透明性」「検査」「適応」の3つを示しています。
透明性
透明性とは今なにをしているか、どのような状況なのかが誰からも分かる状態を指します。良いことも悪いこともオープンであることが重要であり、心理的安全性の話にもつながってきます。大事なことは全員が情報を共有できる状態にあり、その情報をもとに検査していくことになります
検査
望ましくない変化や問題がないかを確認します。
適応
検査した結果から、調整 / 改善につなげていきます。
スクラムの価値基準
「確約」「集中」「公開」「尊敬」「勇気」の5つを指します。これらの言葉はスクラムガイドの下記説明に利用されています。
スクラムが成功するかどうかは、次の 5 つの価値基準を実践できるかどうかにかかっている。
スクラムチームは、ゴールを達成し、お互いにサポートすることを「確約」する。スクラムチーム は、ゴールに向けて可能な限り進捗できるように、スプリントの作業に「集中」する。スクラムチ ームとステークホルダーは、作業や課題を「公開」する。スクラムチームのメンバーは、お互いに能⼒のある独⽴した個⼈として「尊敬」し、⼀緒に働く⼈たちからも同じように「尊敬」される。スク ラムチームのメンバーは、正しいことをする勇気や困難な問題に取り組む「勇気」を持つ。
なぜ我々はスクラムを実践するのか
私たちは「プロダクト開発」をしています。プロダクト開発は「不確実性」が高く、私たちは最速で開発をしながら得た知見をチームで共有し、新たな「仮説」を経て、次の指針や優先順を決定して進んでいます。
これは、スクラムのフレームワークが提供する「複雑な問題に対応する適応型のソリューションを通じて、人々、チーム、組織が価値を生み出す」と一致します。それが一番大きな理由かなと考えています。
プロダクト開発の目的とは、プロダクトを利用してもらうことにある。プロダクトを提供し、そこで何らかの価値を見出していけるかが焦点になる。
プロダクト開発において最初の「作る」はあくまで「使ってみる」「試してもらう」ためであり、その開発量や準備は最小限に抑える。「作る」こと自体が主眼ではない。検証のために「作る」。検証結果でもって、方向性の確からしさを獲得していく。その上で「作る」ことになる（場合によって最初に作ったものは用を成さないと判断し、ゴミ箱に捨てることも十分ある）。
我々が実践しているスクラム
１スプリント１週間で行なっています。慣れないうちは１週間の経過が早くスクラムのイベントをこなす中で開発や設計を行う大変さがありましたが、慣れてくるとこのサイクルが板についてきました。
上述のイベントスケジュールに、スクラムイベントに本来ないMTGが設定されているので補足説明します。
企画会議
サイト開発の企画メンバーが、企画を持ち寄り "Why / What" の説明を行い、プロダクトオーナーから企画承認やフィードバックをもらう会議となります。最初のうちはエンジニアは任意参加でしたが、"Why / What" の説明を聞き、疑問があればその場で確認するほうが効率が良いことが分かったので、現在はエンジニアも参加しています。
設計会議
企画会議で承認された企画を、エンジニアと企画オーナー（企画を起票した人）で "How" の認識合わせや 企画の深掘りを行う会議となります。また、メインの担当エンジニアをつけ、細かい要件の調整は別途個別にやることとしています。企画内容によって話が間延びしたり議論が伸びてMTGの予定時間を超過することがあったためです。
ストーリーポイント見積もり
リファイメントの役割も担っています。ここでタスクにかかるストーリーポイントや仕様明確になっています。この作業を行うことでプランニングを効率的に実施します。
私が大切にしていること
過去の私のブログでも書いているので抜粋します。これは今も変わっていません。
スクラムを導入するにあたり意識していることとして、スクラムイベントを行うことは大事ですが、それらをこなすことがゴールになってはいけません。大事なことはチームの開発が最速で行われ、ユーザへの価値提供を行えていること と思います。スクラムは 手段 であり 目的 ではない のです。
参加者の声
・スクラムの3本柱 透明性・検査・適応
目的がすごくシンプルなので、始めやすそう
シンプルなだけに、無数のhowがあるので大変そう
・役割とイベントの概要だけ記されているので、実施者で変化がいくらでもつけられる
スピードや効率については記載がない。価値にしか触れていない。
・スクラムの⼀部だけを導⼊することも可能だが、それはス
クラムとは⾔えない。
なるほど。何かイベントが欠けてもスクラムとは呼ばない（呼べない）という理解
スクラムは「経験主義」でガイドにも経験という言葉が頻繁に出てくる
スプリントの積み重ねで経験値が上がっていくことでゴールの見通しや変化に対応していくのかと思う。
逆にいうと経験が積み上がってない状態では実質生産性やスピードは最大化できないということにもなると思う（スクラムで生産性やスピードは謳っていないが）。
チームに新規メンバーが参入したとき、そのチームメンバーでの経験は0なのでそれまでのやり方が通用しなくなるというのは心得ておいた方がよいと思った。
ちなみに私が受けた研修ではスクラムは基本メンバーの変動はしないと講師がいっていた（たぶん経験の積み重ねができなくなるからかなと合点がいった）
改善できそうな点としては、ポイント見積もりをスプリントプランニングに含めても良い気もします。ポイント見積もりでは設定したポイントをおさらいするくらいにすると時間が短縮できそう。
ただ、ポイント見積もりを全員でやることにより自分の着手するタスク以外も把握できるので、全体がどのように進んでいるか把握できるという面では良い。誰が何をしているのかを把握するのは透明性にもつながるが、その分若干のリソースを持っていかれる。
ハドルなどで会話した内容を文章に残しておくことでハドルに参加していない人も後で見て理解することができる。こういったことが透明性につながると思いました。これらはすでによく実行されているように感じます。
▶ 【PR】ユニラボ に興味がある方へ
今回の記事を読んでユニラボに興味を持っていただけた方は、まずはカジュアル面談でざっくりお話させていただければと思います！
この記事が気に入ったらサポートをしてみませんか？