今回はスクラムについて語ります！
今回お話するスクラムは、アジャイル開発 のときによく使われるチーム管理の方法で、知っておくときっとどこかで役に立ちます。
でも全てを理解するのは、結構大変なので、まずはうちの記事で簡単に理解してみるのはいかがでしょう？
ただ、自分の経験とミックスしてるので、私のオリジナル要素も少し交じってます、すいませんｗ
ちなみに、今回のお話は単体でも読めるように書いていますが、こちらをまず読んでいただくと、より楽しめます！
ざっくりスクラムとは？
ざっくり言うと「スクラムを組んでみんな一丸となって成功しよう！」というフォーメーションです。
要は、アジャイル開発をするとき、チームをどのように編成して動けばいいのか？・・こんなときの攻略法だと思って下さい。
前回の記事 でこんな事を書かせていただいたのですが、アジャイルは以下のような特徴があります。
アジャイル型の特徴は、仕様変更をガンガン行う前提で進めるという事。
なので最初の段階では仕様をざっくり決めて、あとは臨機応変に仕様を決めながら開発します
簡単に言うと、やりながら仕様を決めていくので、すごく重要になってくるのが・・
チームのコミュニケーションなんです！
そして、以下が徹底されてないと、思い通りにチームが動かなくて失敗しやすいのがアジャイルの特徴。
- 毎日コミュニケーションがとれる体制
- 最低限の方針はぶれないようにする
- 誰が何をしてるかを全員把握している
- チーム全体が自律的に動く
要はこの辺を徹底して、開発プロジェクトを進めるために「スクラム」という攻略法を使う訳です。
ではお待ちかね。ここからはスクラムのやり方を簡単に紹介します。
３つの役割を定義する
スクラムは、大きく３つの役割を持った人を決めて進めます。
- プロダクトオーナー
- スクラムマスター
- 開発チーム
まず、それぞれの役割を説明していきます！
プロダクトオーナー
顧客・社内にヒアリングをしながら、どんなプロダクトにするか方針を決める人で、チーム全体の状況も常に把握して管理します。
例えばこういう方針。
- 価値
- ターゲット
- どんな機能が必要か？
- 機能開発の優先順位
- 費用対効果（ROI）
- などなど
ちなみに、こういう方針や計画を、プロダクトオーナーが解りやすく視覚化するのが基本で、この視覚化された情報を・・
プロダクト・バックログといいます！
売れる＆使いやすい製品になるか・ならないかはプロダクトオーナーの判断にかかってます。
顧客のニーズや状況に合わせて、どの機能から開発していくかの優先順位の判断もします。
尖った商品が売れる場合もあるし、汎用的な商品が売れる場合もあるので、どんな商品が売れるかって判断は、結構難しいんですよ・・。
そのため、以下のような、幅広いスキルが求められます。
- 幅広いビジネスや開発の知識・ノウハウ
- 決断力・実行力・折衝力
- 顧客の意見に忖度しない目線・判断力
ちなみに、方針を決めてその情報を、プロダクト・バックログとして開発チームに渡しますが、作り方に干渉・指示をしないのが基本です。
スクラムマスター
スクラムマスターは、チーム1人1人が、プロダクトオーナーが決めた「プロダクト・バックログ」の方針から外れていないかを管理する役割です。
管理だけではなく、開発チームの状況や意見をプロダクトオーナーに伝える支援も行います。
時には、現場の技術的な意見を吸い上げ、プロダクトオーナーに、方針変更の提案をしたり、理不尽なトップダウンなど外部の圧力からチームを守る。
このように、プロダクトオーナーと、開発チームを支援して調整する役割が・・
スクラムマスター！
特徴的なのは、マネジメントはするが、コントロールはしないので、通常のリーダーとは役割が異なります。
あくまで、チームの支援をする人で、目指すゴールは、開発チームを支援し自律的に動けるように導く事。
※このように指示ではなく、支援をしてチームをゴールに導く役割を「サーバントリーダー」といいます。
余談なんですけど、「プロダクトオーナー 兼 スクラムマスター」は「あり」か「なし」かみたいな、賛否両論の議論がよくあるんですが・・、
私は「反対派」です。この役割は絶対に別々であるべきだと思います！
理由として、私の経験を振り返ると「現場の調整」と「方針の決め」を同じ人がやってしまうと、プロダクトオーナーの目線が優先される方針に、なりやすかったんです。
兼任した結果、ただのトップダウンのチームになってました。これでは、臨機応変が売りのアジャイルのメリットがなくなってしまいます。
現場とオーナー、両方の目線を持つ中間の役割は、人とプロダクトを繋ぐためにとても重要だと思います！
開発チーム
開発に関わってる人すべてを「開発チーム」と呼びます。特に役割やリーダーは決めません。
方針にそって、開発チームが話し合いながら、自分たちで決め、強みを生かし自律的に作る事が基本になります。
なので、開発チームのメンバーは、設計を含め横断的に幅広く対応できるスキルが必要となります。
残念ながら、言われた事しか出来ない人、型にはめて物事を進めたい人ばかりのチームでは、スクラムが成り立ちません。
私自身、実際にSESや派遣のよせ集めで「さぁアジャイル開発をやるぞ！」みたいな感じでスタートしたが、成り立たなくて失敗した事例をよく見ました。
スクラムのメリットとしては、何よりも自分達の判断で進められる事。これが、うまくいくとモチベーションが上がり、生産性もめっちゃ上がります。
自分の責任と判断で作り上げたものが世に出る事。これを開発チームのモチベーション・自信・チームワークにつなげるのがスクラムの狙いなんです。
この３つの役割を図にすると
こんな感じですね。
社外にもステークスホルダー（利害関係者）がいる場合、ヒアリングや交渉をするのはプロダクトオーナーです。
代表的な進め方
次は、代表的な進め方を3つ紹介します。
スクラムはチームリーダーを定義せず、開発チームがプロダクトバックログにそったものを、それぞれ自律的に考え作っていきます。
自由度はかなり高くなる分、チームで毎日お互いの状況を把握して、話し合える事が鍵となります。これを実現するために以下の方法がよく使われます。
- スプリントバックログ
- デイリースクラム
- ボード管理
スプリントバックログ
スプリントバックログとはチームとしてのタスクリストです。
期間は、直近の1週間～3週間くらい (※これをスプリント期間といいます）で終わるものだけを、まずはタスクとして定義します。
「〇〇さんが終わります」ではダメ「チームとして終わります」の判断をするのがスプリントバックログの基本です。
デイリースクラム
デイリースクラムは、毎日全員で作業進捗を確認する事で、朝会で確認しあうのがよくあるやり方です。
- 昨日どこまで終わったか
- 今日は何やる？
- 障害になって困っている事
ここでは共有だけにして、細かい議論はせず、最低限、上記の情報共有を15分以内で終わらせるのがポイント！
何かあれば、別な時間にミーティングを設定しましょう。とにかく朝会で長々と議論するクセをつけちゃダメ！
ボード管理
ボード管理とは、タスクをホワイトボードに貼って、以下の情報を視覚的に確認できる状態にしておく事。
※ SaaSで提供されてる管理ツールで、管理する場合もあります。
- ToDo（やる事）
- InProgress（対応中）
- Done（完了）
※ちなみに、こんな風にやります。後ろのホワイトボードみえます？フリー素材があるほど有名なやり方だったりします。
最後に
まとめますと、以下を理解する事と、透明性をどれだけチーム内で高められるかが、スクラムの肝だと私は思います！
- プロダクトバックログ
- プロダクトオーナー
- スクラムマスター
- 開発チーム
- スプリントバックログ
- デイリースクラム
- ボード管理
そして、上記の内容をもとにして、チームに合うやり方に、少しずつアレンジしていくのが一番良いと感じます。
せっかく、自由度の高いやり方なのに、フレームワークでガチガチにしたら意味がないですからね。
そうそう、話は変わりますけど、実は今回のテーマ「スクラム」は、ご要望をいただいた事がキッカケで書かせていただく事にしたんです。
ご要望ありがとうございました！
少し長くなってしまったので、果たしてうまく説明できたかな？・・なんて、実はちょっと心配してますｗ
よっしーTECHに載せて欲しいテーマは、引き続き募集してますのでよろしくお願い致します！
うちの記事を読んだ後、スクラム・アジャイルに興味を持った方は、この本を読むと面白いかも！
現在、noteで「よっしーTECH」の下書き版公開中です！ こちらもよろしくお願いします！
はじめてから１か月目ですが、現在、PV数は1930、フォロワー数 95！
