以前学んだアジャイル開発とスクラム開発について少し整理する機会があったのでまとめておこうと思います。

アジャイル開発

アジャイル開発のマインドセット

アジャイル開発には共通のマインドセットがあり、そこには『４つの価値』とその価値に由来する『12 の原則』がある。

４つの価値

プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。

上記の原則に対して、IPA のアジャイルソフトウェア開発宣言の読みとき方では次のように解釈している。

価値	解釈
個人と対話	対面コミュニケーション：個人同士の対話を通じて相互理を解深めることで、よりよいチームが作られる
動くソフトウェア	実働検証：動くソフトウェアを使って繰り返し素早く仮説検証をし、その結果から学ぶことがより良い結果を生み出す
顧客との協調	顧客との Win-Win 関係：お互いの立場を超えて協働することにより、よりよい成果と仕事のやり方を作ることができる
変化への対応	変化を味方に：顧客のニーズやビジネス市場の変化は事前計画を狂わす脅威ではなく、よりよい成果を生み出す機会と捉える

上記の通り、アジャイル開発宣言では、開発プロセスとしての価値を提案している。

12の原則

アジャイル開発では、その宣言の背後にある『12の原則』を定めている。原文の解釈について、IPAのアジャイルソフトウェア開発宣言の読みとき方でまとめられている内容と合わせて下記にまとめる。

顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します

解釈	説明
顧客の満足を求め続ける	ビジネス側の人と開発者にとって最も重要な活動は、価値のあるソフトウェアを素早く継続的に提供し、顧客に（QCDの達成ではなく）ビジネスゴールの達成の観点で満足してもらうこと

要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます

解釈	説明
要求の本質を見抜き、変更を前向きに	改善につながる要求は、新しい価値を見つけた証拠。勇気を持って変更を受け入れることで、変化に強くなり、企業の競争力を高めることに貢献する

動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします

解釈	説明
成果物を2−3週間で、リリースし続ける	ビジネス側の人が積極的にビジネスの舵取りができるよう、ビジネス側の人と開発者は2−3週間の短い期間で、成果物を定期的にリリースする

ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません

解釈	説明
全員で共通の目標に向かおう	ビジネス側の人と開発者が共通目標に向かって一緒に働くことで、一連のリリースおよびフィードバックのサイクルが円滑になる

意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します

解釈	説明
人の意欲は信頼から	プロジェクトを成功させるため、開発者には意欲のある前向きな人々を集めて、彼らが働いやすい環境を整えることが必要

情熱を伝えるもっとも効率的で効果的な方法はフェイストゥフェイスで話をすることです

解釈	説明
コミュニケーションは直接対話で	お互いの本音をフェイストゥフェイスで汲み取り、直接対話すること大切

動くソフトウェアこそが進捗の最も重要な尺度です

解釈	説明
進捗も品質も現物で	進捗状況を最も正確に測るには、動くソフトウェアを確認するのが一番。進捗状況は、求められている価値をどれだけ実現できているかであり、計画通り進んでいるかということではない。

アジャイル・プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません

解釈	説明
一定のペースでプロジェクトにリズムを	無理のない一定の開発ペースを保つことで、ビジネスを成功に導く。過負荷なパフォーマンスを求める状態では、創意工夫や改善という意欲が起きない。開発者の生産性を最大化するために、チームの心身がベストな状態を保てるように無理のない一定のペースが重要。

技術的卓越性と優れた設計に対する普段の注意が機敏さを高めます

解釈	説明
よい技術、よい設計、よい品質の追求	新しいビジネスを支えるソフトウェアは、状況に応じて素早く変更できることが求められる。そのためには優れた技術・設計が必要であり、品質については高い保守性が必要。よって、技術者は技術力を磨き、プロダクトへの適用技術、設計に対して常に注意を払わないといけない。

シンプルさ（ムダなく作れる量を最大限にすること）が本質です

解釈	説明
ムダ＝価値を生まない、を探してヤメる	ビジネス側の人と開発者は、顧客が求める価値が何かを考え、その価値に直結しない作業や機能をムダと定義し、ムダを減らすために最大限努力する必要がある。よくあるのは『作りすぎのムダ』で、本当に必要な要求なのかをビジネス側に確認する。これまでの常識や慣習にとらわれずに、新鮮な目で現状を見るのが大事。

解釈

説明

ムダ＝価値を生まない、を探してヤメる

ビジネス側の人と開発者は、顧客が求める価値が何かを考え、その価値に直結しない作業や機能をムダと定義し、ムダを減らすために最大限努力する必要がある。よくあるのは『作りすぎのムダ』で、本当に必要な要求なのかをビジネス側に確認する。これまでの常識や慣習にとらわれずに、新鮮な目で現状を見るのが大事。

最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます

解釈	説明
よいものはよいチームから	最良のアーキテクチャ・要求・設計は、最良のチーム（自律型チーム）から生み出される。自立型チームは、メンバー一人ひとりが自らの行動・作業に責任を持ち、お互いの連携により、チームの成果を最大限に発揮することができるチームのこと。そのために規律・ルールをチームで決め、メンバー各自が率先して行動することが求められる。

解釈

説明

よいものはよいチームから

最良のアーキテクチャ・要求・設計は、最良のチーム（自律型チーム）から生み出される。自立型チームは、メンバー一人ひとりが自らの行動・作業に責任を持ち、お互いの連携により、チームの成果を最大限に発揮することができるチームのこと。そのために規律・ルールをチームで決め、メンバー各自が率先して行動することが求められる。

チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します

解釈	説明
自分たちのやり方を毎週、調整する	チームが成長し続けるためには、定期的にふりかえり、自分たちのやり方を調整し続けることが大事。失敗を許容し、すぐに改善できるようにチームで話しあい課題に立ち向かう。

アジャイル開発の進め方

アジャイル開発は、アジャイル開発宣言、および原則に従い、次のような進め方をする

関係者は目的達成のためにお互いに協力し合いながら進める
一度にまとめてではなく少しずつ作り、早い段階から実際に動作するものを届け続けて評価を繰り返す
利用者の反応や関係者からのフィードバックを継続的に得ながら、作っているもの自体や計画を調整する。

また、アジャイル開発手法には、次の種類のものがある：

共通するのは『事前に全て正確に予測し、計画することはできない』ということを前提にしている点。

アジャイル開発では、どのくらいの期間・人数で仕事をするかを決めて、その範囲の中で大事な要求から順にプロダクトを作っていく。よって、重要なものから先に作り、そうでないものを後回しにして成果を最大化することを目指す開発といえる。

なぜアジャイル開発なのか

ウォーターフォールとアジャイルでも、要件定義や設計は行い、プロセスの共通部分は多い。

違いとしては、ウォーターフォールは、各工程が滝が流れるように進み、各工程の成果物を完成品とみなし、あと工程での手戻りが発生しないように進める。

一方、ジャイルでは反復的に開発が進み、スプリントごとに動くソフトウェアが作られ、次のスプリのではそのソフトウェアから得られた気づきを基に要件レベルから見直される。

ユーザが本当に欲しいものは『潜在的なニーズ』であることが多いため、実際に製品を使ってみるまでは、本音が得られることが少ない。そうした状況において、ウォーターフォールでは全部できてからでないと製品を使えず、最後になって『なんか、これじゃない、、、😱』ということになってしまう。

アジャイルでは、小さいサイクルで動くものを少しずつ作っていき、都度ユーザにフィードバックしてもらい開発を進めるため、最終的にユーザの求めた機能が提供できる。

また、いくつかの要件を形にした後で、新しい要件に気づいたり、実装を進める中でより良い設計を思いついたりした場合にも、アジャイルではフィードバックで取り入れることが可能。

所感

アジャイル開発において、個人的に最も重要だと思うのは自己組織化の部分と思っています。自己組織的に動けていないと、それは、アジャイル開発ではなく、やり方だけ真似ている開発なのじゃないかなと思っています。自身が取り組む際には、しっかり自己組織的に動けているかを確認していきたいなと思います。

スクラム開発

スクラムとは

スクラムはアジャイル開発の手法の一つで、スクラムガイドには次のように記述されている：

複雑な問題に対応する適応型のソリューションを通じて、人々、チーム、組織が価値を生み出すための軽量級フレームワークである。
スクラムは『経験主義』と『リーン思考』に基づいている。経験主義では、知識は経験から生まれ、意思決定は観察に基づく。リーン思考では、ムダを省き、本質に集中する。

上記を実現するために、スクラムには『３本柱』と『５つの価値基準』が定められている。

３本柱

透明性

スクラムにおける重要な意思決定は、以降説明する３つの作成物を認知する状態に基づく。透明性が低いと、価値を低下させ、リスクを高める意思決定につながる。透明性があることで検査が可能になる。
検査

スクラムの作成物と合意された進捗状況は、適切に検査し、潜在的に望ましくない変化や問題を検知する必要がある。検査を支援するために、スクラムには以降で説明する５つのイベントでリズムを作っている。検査があることで適応が可能になる。
適応

プロセスで何かしら逸脱や、成果が受け入れらない時は、プロセスや構成要素を調整し適応する必要がある。関係者に十分な権限が与えられていない時、自己管理されていないチームでは適応が難しい。スクラムチームは、検査によって新しいことを学んだ瞬間に適応することが期待される。

価値基準

スクラムが成功するかどうかは、以下の５つの価値基準を実践できるかによる：

価値基準	説明
確約(Commitment)	ゴールに達成し、お互いにサポートすることを確約する
集中(Focus)	ゴールに向けて可能な限り進捗できるように、スプリントに集中する
公開(Openness)	スクラムチームとステークホルダーは、作業や課題を公開する
尊敬(Respect)	メンバーはお会いがいに能力ある独立した個人として尊敬し、一緒に働く人たちからも同じように尊敬される
勇気(Courage)	正しいことをする勇気や困難な問題に取り組む勇気を持つ

スクラム開発のルールセット

スクラム開発では、『３本柱』、『価値基準』を具現化するためのルールセット（５つのイベント、３つのロール、３つの作成物）を用いて実践する。

5 つのイベント（会議等）

イベント名	説明
スプリント	・固定期間に区切って開発する際の単位。最長でも１ヶ月・スプリントは他のイベントの入れ物・スクラムではスプリントを繰り返すことでリズム良く開発を進める
スプリントプランニング	・スプリントを進める計画のためスプリントの冒頭で行う・スプリントで何(what)をどう(how)作るかを計画する
デイリースクラム	・スプリントゴール達成のための毎日の状況確認・昨日やったこと、今日やること、障害となることなどを話す
スプリントレビュー	・スプリントでの成果物をデモする・フィードバックを受けて、プロダクトバックログを見直す・今後の予定や見通しの共有
スプリントレトロスペクティブ	・直近スプリントでのカイゼン活動・バグが生まれるプロセスを直す・提案されたカイゼンの１つは次回のスプリントに必ず反映する

３つのロール（人の役割）

ロール名	説明
プロダクトオーナー	プロダクトバックログ管理の責任者
開発チーム	・プロダクトバックログを開発する人・機能横断的なチームである必要がある (開発チームでプロダクトを作るための作業全てができる。)
スクラムマスター	・スクラム開発のプロセスが円滑に回るように仕切る人・マネージャーや管理者ではなく、スクラム開発を誘導するトレーナー的な役割をする

３つの作成物

作成物名	説明
プロダクトバックログ	・機能や要求、要望、修正などプロダクトに必要なものを抽出し、実現したい順に並べたもの・常にメンテナンスして最新に保つ・上位項目については見積もりを済ませる
スプリントバッグログ	・選択したプロダクトバックログ項目と実行計画・プロダクトバックログを具体的な作業に分割する・後から増えることもある・１タスクは 1 日以内で終わるサイズ
インクリメント	・スプリント単位で評価可能なもの（動作して検査可能なソフトウェア）・累計のプロダクトバックログ項目を合わせたもの・プロダクトバックログアイテムが完成の定義を満たした時に誕生する・よって、完成の定義が決まっていないと評価できない

全体の流れ

上記の『５・３・３』の流れのイメージをまとめる。

上のイメージのように、スクラム開発は『PDCA』を回すためのフレームワークと捉えると分かりやすい。『P：スプリントプランニング』、『D：実装＋デイリースクラム』、『C：スプリントレビュー』、『A：スプリントレトロスペクティブ』みたいな対応になると思う。

雰囲気はつかめた、で、どうする？

スクラムの進め方はなんとなくわかったので、それぞれのイベントで役立つノウハウをまとめておきます。

プロダクトバックログの決定

プロダクトバックログでは次のことを決める必要がある。

どういうことを実現するのか（ゴール）
絶対に達成したいことは何か（ミッション）

ゴールとミッションを明確にする

上記を決める活動の 1 つに、インセプションデッキと呼ばれる手法がある。インセプションデッキでは、明らかにすべき点を 10 個の質問でまとめられていて、それについてスクラムチームで話し合い、スライドにまとめていく。

プロダクトバックログのサンプル

詳細なフォーマットはない。機能を列挙したものや、ユーザストーリで書いたものなどがある。

機能列挙型

機能	目的	詳細
日報入力	最新情報から戦略を考える	日単位で訪問先、担当者、案件情報を入力する
ログイン	機密のため利用者を制限	社員番号とパスワードで認証
・・・

ユーザストーリ型

ストーリー	デモ手順	見積もり
毎日訪問先の状況を記録したい。最新情報から戦略を練りたいため	XXX 社の記録ページを表示して、訪問日時、商談状況、報告内容を入力して記録ボタンを押す。確認画面が・・・
利用者を制限したい。機密情報を社員のみに開示するため	未ログイン状態でアクセスするとログイン画面を表示。〇〇の社員番号とパスワードを・・・
・・・

作業の見積もり

プロダクトバックログの内容をまずは大雑把に下記くらいに分類する。

簡単に終わりそう
少し大変そう
結構大変そう

上記の振り分けをしたら、1 つのプロダクトバックログの項目に対して、作業量の基準値を設定する。その基準に対して、他の項目たちが相対的にどんな感じかをそれぞれ見積もっていく。この時のやり方には、見積もりポーカーと呼ばれるものもある。

また、プロダクトバックログは、細かくしすぎない。見積もりは結局のところ推測でしかないので、プロダクトバックログを細かくして、見積もりを詳細にしたところでズレが起こる。その際、せっかく詳細に見積もりにかけた時間が無駄になるため

全体の見積もり（必要なスプリント数の見積もり）

上記で決定したプロダクトバックログと見積もりをもとに、全体でどの程度の時間が掛かるかが見通せるようになる。

理由は、それまでのスプリントで消化した見積もり数の値から、１スプリントで消化できる見積もり数（ベロシティ）を予測でき、残プロダクトバックログの見積もり数合計➗ベロシティで、残りどの程度かかるかがわかるようになるため。

スクラムを初めてやる場合には、何回か数をこなし、スプリントの平均ベロシティを出すと良い。

スプリントプランニングの実行

スプリントプランニングでは次のことを行う。

このスプリントで何をするかを共有する
完成の定義を決める
必要な作業（タスク）を洗い出す
スプリント内で終わるかを判断する

デイリースクラムで進捗確認

デイリースクラムでは次のことを共有する。

スプリントゴール達成のために昨日やったこと
スプリントゴール達成のために今日やること
スプリントゴール達成の妨げになる障害や問題点

デイリースクラムの中では、問題を見つけることだけにとどめ、実際の対処はデイリー後に議論する。

また、スプリントゴールに対して、スプリントバーンチャートを書いてみると、進捗把握できるため、有効らしい。

スプリントレビューでフィードバックを得る

スプリントレビューでは、スプリント開始時に決めたプロダクトバックログのうち、完成したものを開発チームおよびステークホルダーに見せて、今後のフィードバックを得る。

実際に動くものを触ることで期待したものになっているかの確認を行え、要求通りであっても『実は使いにくかった』というような改善のヒントを得ることができる。

スプリントレトロスペクティブでスプリント自体を見直す

スプリントレトロスペクティブは『ふりかえり』。スプリントを通してうまくいかなかったことや改善点等をチームで話し合って、次のスプリントをよりうまく回せるようにする。

ふりかえりの手法としては、『KPT』や『Fun Done Learn』などいろんなやり方がある。心理的安全性のあるチームを作るためにコミュケーション向上を狙ったものや、スプリント中のやりにくい作業などを思い起こして、どうすればいいかなどを考える。

PDCA との違い

スクラム開発の各プロセスは PDCA に近いと言えるが、スクラムでは『スプリントレビューでプロダクト自体の改善』、『スプリントレトロスペクティブでプロセスの改善』という２重の改善がある。

上記は、ダブルループ学習とも呼ばれ、プロダクト自体をよくするとともに、作る過程も最適化していく点が異なっている。

所感

最初は『スクラム？？』という感じでしたが、実際の流れを知ってしまうと『PDCA』を実践する開発手法なんかなと思いました。カンバンなど元々トヨタ生産方式（TPS）が海外にわたり、スクラムとして逆輸入されたと知った時はとても親近感が湧きました。現職でも PDCA を新卒の時に教育を受けましたが、実際の業務では『D』しかなく、これでいいんか 🤔 と思っていたので、スクラムのやり方は PDCA を実践していると感じているのでとてもいいなと思っています。

特に開発をよりしやすくするためには、スプリントレトロスペクティブが最も重要だと思いました。長ったらしい名前で最初は『何？？』となりましたが『ふりかえり』ということで、PDCA の『CA』に当たる部分かなと思っています。意図的にやらないとうまくいかない難しいプロセスですが、やっていくとチームが前向きになりとてもいい活動だと思っています。