トップ > スクラム開発 > スクラム開発を体系的に学んだのでアウトプットする

スクラム開発を体系的に学んだのでアウトプットする

スクラム開発
記事タイトルとURLをコピーする

はじめに

先日、スクラムについて体系的にインプットさせていただく研修の機会をいただきました。

自分は案件を通して我流でやっていたので、非常に勉強になり、学んだことをアウトプットしたく今回ブログを書くことにしました。

対象読者

  • スクラム開発の雰囲気を知りたい方
  • 自身のスクラム開発と他の人のスクラム開発の違いを知りたい方
  • スクラム開発をしていないが、スクラムの考え方を取り入れて柔軟な開発をしたい方

スクラムの起源

  • 要求・環境・技術の進歩など不確実な要素が多い中でプロジェクトを進める必要があり、一方向的にプロジェクトを進める ウォーターフォール開発 が困難になってきた
  • 上記の課題を克服するため、1980年代の日本企業の働き方を分析した結果、短いサイクルで検査と適応を繰り返す スクラム開発 が生まれた ※1
  • スクラム以外にも独自の軽量かつ柔軟な開発アプローチで成功した人たちが集まり、その成功の本質を分析した結果、 アジャイルソフトウェア開発宣言 が生まれた

※1 論文: 「The New New Product Development Game」より。

この論文では、日本企業とNASAなどのアメリカ企業における新製品開発プロセスの比較分析が行われた

■ 感想

スクラムの起源が日本企業にあったのは意外でした。高度経済成長期の日本の優秀さを実感しました。(勝手にラグビーが起源だと思ってました)

スクラムとアジャイルはついつい混同しがちなのですが、アジャイルとは開発フレームワークというよりも「アジャイルソフトウェア開発宣言」に記されたマインドセットのことを指すことも初めて知りました。

特に、成功の本質は手法ではなくマインドセットにある というのはスクラムを実践する上でも重要なことだなと感じます。

  • アジャイル: 「アジャイルソフトウェア開発宣言」に記された開発を成功させるための共通となるマインドセット
  • スクラム: アジャイルに則ったソフトウェア開発フレームワーク

そして、アジャイルが先にあったのかと思っていましたが、スクラムや似たような開発アプローチを抽象化してアジャイルが生まれたのも驚きでした。

スクラムの3本柱

  • スクラムの重要な考え方として、以下3本の柱がある
  • 透明性: チーム全員に対して情報が公開されていること。判断の基準が明確であること
  • 検査: 透明性が確保された状態で、ゴールの達成状況や成果物を継続的に検証できること
  • 適応: 検査の結果、期待された基準を満たしていない場合、迅速に変更を加えて状況に適応すること

■ 感想

「検査」と「適応」は、スクラム中にイベントとして発生するタイミングがあるので自然と意識出来ていたと感じました。

一方「透明性」は、日ごろの個人の意識に依存する部分が大きく、自分自身出来てない場面も多々あるなと思いました。

弊社の社風でも透明性はよく重視されるのですが、「失敗を非難しない、相談しやすい雰囲気、情報公開に対してポジティブに評価してもらえる」などのチーム風土があることが重要だと感じます。

研修では、この3本柱を体感すべく、3スプリントで紙飛行機をたくさん作るワークショップを行いました。 ref

大人が真剣に紙飛行機を作る光景は少し面白いですが、理解が深まるのでスクラム導入したての場合にはおすすめです笑

例えば、ワークショップでは途中に別チームと紙飛行機の作り方ノウハウを共有する時間がありました。この時間により、他チームのノウハウを取り入れて紙飛行機の生産が格段にアップしました。

ここから情報の公開、すなわち透明性の重要性が体感できました。

スクラムの要素

スプリントイベント

  • スプリント(Sprint)とは作業期間のこと。通常 1~4週間の期間で設定され、この単位で検査→適応を繰り返す
  • スプリント中は、「プランニング, デイリースクラム, レビュー, レトロスペクティブ」の4つの基本イベントがある(※1)
  • また、他の重要なイベントとして「バックログリファインメント, リリース」が存在する(※1)

※1. 各イベントの詳細

イベント やること 頻度
プランニング スプリントゴールとやること(=PBI(後述))を決める 毎スプリントで最低1回
デイリースクラム 日々の進捗を確認し、障害があればアラートをあげる 毎日
レビュー スプリントゴールに到達したか検査する 毎スプリントで最低1回
レトロスペクティブ このスプリントの振り返り(KPT)を行う 毎スプリントで最低1回
バックログリファインメント 将来のスプリントを計画する 必要に応じて
リリース プロダクトリリースを行う 必要に応じて

■ 感想

基本的な4つスプリントイベントとリリースイベントは普段の業務でも実施しているため馴染みがありました。

一方、バックログリファインメントは研修を通して初めて明確になりました。(研修を通して一番の学びでした)

プラン二ングとの違いが分かりづらいですが、「将来の計画をするか否か」がポイントです。

  • プランニング: 次回のスプリントの計画をすることが目的
  • バックログリファインメント: 将来(2~3Sprint先)のスプリントを計画することが目的

業務中の悩みとして、毎回のプランニングで将来のスプリントも考えていたので考える時間が足りず品質が落ちることが多々ありました。苦し紛れに「全体的な要件の整理と機能開発」を同じスプリント内で実施し、後者がゴール未達になる...なんてことが何度もありました。

研修後にバックログリファインメントを導入したところ、「全体の要件の整理、先に2~3スプリント先のやることを明確にすること」で、上記問題を解決できました。

プラン二ングでやっていたタスクをオフロードできたことで、考える時間が足りず品質が落ちること場面がなくなりました。また、そもそもプランニングにかかる時間を1~2H程度短縮できるようにりました。

プロダクトバックログアイテム(PBI)

  • プロダクトゴールを達成するために、何を成し遂げるか?何を顧客に届けるべきか?を記述したもの。
  • 1PBIは、そのスプリント内で完了できる単位で切る
  • よいPBIでは、誰でも判断ができるかつ、情報がそこに集約されている

PBIでケーキを作ろう

  • PBIを切るときは、要件定義→設計→開発→テスト...と横軸に切るのではなく、出来上がる機能(≒ユーザ体験)で縦軸できることが大切。
  • PBIはケーキに例えるとわかりやすい。(要件定義, 設計..はケーキを構成する1スポンジ層でしかない)
  • 顧客はレビューで美味しいケーキを食べたい！

■ NGなPBIチケット

タイトル: 紙飛行機を設計する
完了条件: 設計が完了する

✖: PBIの切り方が断片的で、タイトルを見てもこのPBIが完了することで何が成し遂げられるかが伝わりづらい (=ケーキが作れていない) ✖: 顧客に届けるべきものが完了条件に書かれてない。完了条件が曖昧。

■ よいPBIチケット

タイトル: 3m飛ぶ紙飛行機が1台できる
完了条件: 作成した紙飛行機が3m飛ぶデモを見せる
補足: 紙飛行機の要件は....

〇: タイトルを見ただけで、このPBIが完了することで何が成し遂げられるかが明確 (=ケーキが作れている) 〇: 完了条件で顧客に届けるものと検査基準が明確になっている
〇: 紙飛行機の要件が書かれ、このチケットに情報が集約されている

■ 感想

研修後もPBIを切ることはまだまだ苦戦気味です。特にプロダクトを顧客に届けられる価値単位で分割するのにパワーをかなり使います。

繰り返してるうちに、最近は以下のような流れでPBIの切り方をすると上手く行くことが多いです(システムテストとリリースは顧客に届ける価値になっているのか怪しいですが)

  • ①機能Aが完成する(要件定義→設計→実装→Integテストまでこの中で実施する)
  • ②機能Bが完成する
  • ③システムテストが完了する
  • ④リリースが完了する

一方、「プロダクト全体として要件定義や設計する」時間も重要です。これらはプランニングやバックログリファインメントの活動でカバーしています。

ただし、上記の時間だけでカバーしきれないときもあるので、その場合はケーキを作ることにこだわりすぎず、全体の要件定義や設計でPBIを切っています。

スクラムチーム

  • スクラムチームは、責任に応じて、①開発者 ②プロダクトオーナー(PO) ③スクラムマスター(SM) の3つの役割に分かれる。
  • POとSMはチーム内で1人ずつアサインされる。
  • 開発者のみ複数人アサインされる。開発者同士は上下の関係はなく、みな平等にプロダクトに対して責任を持っている
名称 責任 やること
開発者 スプリントのゴールに責任を持つ スプリントの計画, PBIの消化
PO プロダクトの価値を最大化することに責任を持つ リリースの計画, 効果的なプロダクトバックログ運営
SM スクラムの働き方に対して責任を持つ チームにスクラムを浸透させる、チーム内のプロセス改善を実行する、別チームとの依存関係の調整など進捗を妨げる障害を明確化・解消する

■ 感想

スクラムマスターやること多くて大変だなと思いました笑

別チームとの調整に対する責任をスクラムマスターが持つのは意外でした。開発者がPBIを消化する中で調整すると思っていたためです。（このあたり踏み込んで質問すればよかった...)

講師の方が「責任範囲が明確化でも自分の責任範囲しかやらないのは✖。自分の責任にコミットしつつ助け合うことが大事」と話していたのが印象的でした。

業務でも、私は開発者ロールとして参加しているのですが、「リリース計画を考えたり、他チームとして調整したり...」など責任の枠を超えることが多いです。

おわりに

他にも触れたようと思ったのですが、長くなりすぎるので一旦ここまでで区切りとさせていただきます。

スクラムを体系的に学ぶことで、以前よりも視野が広がり柔軟に活動できるようになったと感じました。

スクラム開発を直近でやる予定がなくても普段のプロジェクトに生かせる考え方もあるので、まだ勉強したことない人は一度インプットする価値あると思います。

菅谷 歩 (記事一覧)