スクラム開発・・・？

新卒からアジャイル開発のスクラムを採用しているチームに2年半在籍しました。
しかし私のチームにスクラムマスターと役割が定義されているメンバーはおりません。私自身も勉強会や技術記事などで単発式に知識を得る程度で、原点に立ち返り理解しようとする経験はありませんでした。他のメンバーも同じような状況かと思います。このような状態でスクラム開発をやっていると言えるのだろうかと考えるようになりました。そして社外のエンジニアとお話しする機会があり、原点を愚直に実行することで得られる知見があるのではないかとアドバイスをいただいたので、今一度スクラムというものを理解していきたいというのが当記事の趣旨です。

スクラムとは何かを理解していない人、何となくスクラム開発を行っている人、スクラムを推進していきたい人には何か気づきがある記事になるかと思います。

参考資料を最初に記載しておきます

• スクラムガイド
• 正しいものを正しく作る
• リーダーのための「スクラムガイド」手引き

プロダクト開発の核心とアジャイル開発

まず現状のプロダクト開発の課題と、アプローチについて整理したいと思います。
現在のプロダクト開発は誰かが持つ正解イメージがあり、それをうまく取り出してコードにしていくという開発ではなく、誰にも分からない「どうあるべきか」を形にするという新しい開発のあり方へのシフトがあります。

正解がないものを作ることに加えて、プロダクト開発にはいくつもの不確実性があります。

不確実性の要因	説明
市場の変動性	市場のニーズと嗜好は常に変化しており、これは新しい技術の出現、競合他社の行動、経済の変動、政策の変更など、多くの要因によって引き起こされます。
技術の進歩	新しい技術の出現は、製品開発のプロセスと結果に大きな影響を与えます。
リソースの制約	時間、予算、人材などのリソースは常に制約となります。
プロジェクトの複雑性	製品開発は、多くの場合、複数の部門、チーム、スキルセットを必要とします。これらの要素が互いにどのように相互作用するかは、常に不確実性をもたらします。
規制と法律	新しい製品やサービスは、国や地域の法律や規制によって影響を受ける可能性があります。これらの規制は予測が難しく、変更が頻繁に行われるため、不確実性を生み出します。
供給チェーンの問題	製品の製造やサービスの提供には、多くの場合、複数の供給者やパートナーが関与します。これらの関係者のパフォーマンスや信頼性の問題は、プロジェクトの進行に影響を与える可能性があります。
顧客のフィードバック	顧客のフィードバックは、製品開発において重要な役割を果たします。しかし、フィードバックは予測が難しく、また、それに対応するための修正や改善が必要となる可能性があります。

これらのプロダクト開発の課題に対応するために、正解が分からない環境下であたりを付けながら、間違う前提を念頭に置きつつ、ステークホルダー間で合意形成しながら進めるアプローチとしてアジャイル開発が求められることになりました。

• 変化への対応: アジャイル開発は、変化を歓迎します。プロジェクトの途中であっても、顧客の利益を最大化するために必要な変更を受け入れます。
• 頻繁なインクリメンタルなデリバリー: アジャイル開発では、可能な限り短いタイムスケール（通常は1-4週間）で働くソフトウェアのインクリメント（新たに追加された機能）を提供します。
• 協力的なアプローチ: ビジネスチームと開発チームは、プロジェクト全体を通じて日々一緒に働きます。これにより、ビジネスの目標と技術的な実現可能性の間のギャップを埋めることができます。
• 自己組織化したチーム: アジャイル開発では、プロジェクトを進めるために必要な決定を行う能力をチーム自体が持つことが推奨されます。
• 継続的な改善: アジャイル開発では、技術的な卓越性と良い設計への注力と、定期的に振り返りを行い、効率的に働く方法を探すことが強調されます。

上記がアジャイル開発の要点になります。

インクリメンタル・協力的・自己組織化というキーワードはウォーターフォール開発と比較した時の特徴になるかなと思います。

ウォーターフォール開発との採用基準はこんなところなのかなと思います。

	アジャイル開発	ウォーターフォール開発
メリット	顧客のフィードバックに基づいて頻繁に調整可能。変更を容易に取り入れることができる。	プロジェクトの範囲と期間が明確。全体の計画を事前に立てることができる。
デメリット	プロジェクトの範囲が流動的であり、最終的な製品が開始時には明確でない可能性がある。	一度開始すると変更が困難。全ての要件がプロジェクト開始前に明確である必要がある。
採用基準	プロジェクトの要件が頻繁に変更される可能性がある場合、または開発プロセス全体を通じて顧客との密接な協力が可能な場合に適しています。	プロジェクトの要件が明確で、変更の可能性が少ない場合、またはプロジェクトの範囲と期間が明確に定義されている場合に適しています。

もう少し具体的なところでの違いは以下のようなものが考えられます。

ウォーターフォール

• メリット
  1. クライアントの要求を初期段階で全て把握し、それに基づいた開発が可能。
  2. 契約形態が請負契約の場合、開発期間、機能、費用を最初に確定できる。
• デメリット
  1. 全ての要件を初期段階で決定する必要があり、そのための時間と労力が必要。
  2. 初期の要件定義で決定したものだけが開発対象となるため、要件定義と内容の精査が一度に行われる。
  3. プロジェクト初期では全ての情報が揃っていないため、工数の見積もりが難しい。
  4. 開発途中で新たな要件が出てきても、それを取り入れるのが難しい。
  5. 初期に全ての要件を定義しても、後で不要となる部分が出てくる可能性がある。
  6. 要件定義と設計・実装が別フェーズで行われるため、情報が断片化する。
  7. 開発初期に全ての機能を考慮してライブラリやアーキテクチャを選定する必要がある。
  8. 完成品を見ることができるのは、開発がほぼ完了した結合テスト以降。

アジャイル

• メリット
  1. 工数の見積もりは短期間（2,3週間先）までで良い。
  2. イテレーション（繰り返しのサイクル）ごとに要件を見直すため、クライアントにも考える時間が確保できる。
  3. チームには常に要件定義者が含まれているため、情報が断片化しない。
  4. プロジェクトが進行するにつれて、要件定義に必要な知識が蓄積される。
  5. 各イテレーションの時点で最適な実装を最短時間で行うことが可能。
  6. プロジェクトの途中で方針転換が容易。
• デメリット
  1. 数ヶ月後になにが完成しているかのコミットはできない。
  2. 細かい作り直しは必ず発生する（各時点で最適な実装を最短時間で行った結果）
  3. 納品物を定義できない(準委任契約になる)

ここまででアジャイル開発が求められる経緯と簡単な概要について説明しました。
それではアジャイル開発のフレームワークであるスクラムについて解説していきます。

スクラム開発

スクラムガイドには「軽量、理解が容易、習得は非常に困難」という表現で説明されています。
経験主義にもとづくプロセスのフレームワークであり、やってみてわかったことから、次にやるべきことや試すべきことを自分たちの活動に組み込んでいく考え方が後押しされているものです。（スクラムをフレームワークと定義している所以）
「外部からただ取ってきた知識を適用してもうまくはいかない」「実践に支えられた知識を頼りとする」のがスクラムの考え方です。

スクラムの定義や進め方についてはスクラムガイドを確認するのが良いです。
pdf自体は13pしかないため20分ほどあれば読むことはできるでしょう。
スクラムガイド：https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf

以下の項目ではスクラムガイドに対して、自分がどのように理解しているのか、具体的にはどのようなケースが当てはまるのかを記載している。

スクラムの経験主義を支える3つのコンセプト

スクラムの経験主義を支えるコンセプトとして以下の3つがある

• 透明性
  プロジェクトの進行状況と結果が全ての関係者に対して透明であることが求められます。これにより、全ての関係者が同じ理解を持ち、適切な意思決定を行うことができます。具体的には、製品バックログ、スプリントバックログ、バーンダウンチャートなどのアーティファクトやツールを用いて、作業の進行状況や成果を可視化します。例えば、開発チームはデイリースクラムで進行状況を共有し、スプリントレビューで製品のインクリメントをデモンストレーションすることで、透明性を確保します。

• 検査
  プロジェクトの進行状況と結果を定期的に検査し、問題や改善点を特定します。これにより、問題がエスカレートする前に対処し、プロジェクトの品質と効率を維持することができます。具体的には、デイリースクラムで前日の作業をレビューし、スプリントレビューで製品のインクリメントを評価し、スプリントレトロスペクティブでプロセスを反省します。例えば、スプリントレトロスペクティブでは、チームはスプリントの成功と失敗を評価し、次のスプリントで改善するためのアクションアイテムを特定します。

• 適応
  検査の結果に基づいてプロセスや製品を適応させ、改善します。これにより、チームは変化する要件や状況に対応し、製品の価値を最大化することができます。具体的には、スプリントレトロスペクティブで特定したアクションアイテムを実行し、次のスプリント計画で新たなアプローチを採用します。例えば、スプリントレトロスペクティブで、チームがコミュニケーションの問題を特定した場合、次のスプリントでは新たなコミュニケーションツールを導入したり、デイリースクラムの形式を変更したりすることで、問題を解決します。

これらの3つの柱は、スクラムチームが継続的に学習し、改善し、成長するための基盤を形成します。透明性により、全ての関係者がプロジェクトの現状を理解し、適切な意思決定を行うことができます。検査により、チームは問題や改善点を早期に特定し、対処することができます。適応により、チームは変化する要件や状況に対応し、製品の価値を最大化することができます。これらの柱は、スクラムの価値観（確約、勇気、焦点、開放性、尊重）と共に、スクラムチームが高品質な製品を生み出し、顧客の期待を超える結果を達成するための基盤を形成するという考えからきています。

スクラムチームの構成要素

スクラムチームは、スクラムマスター1 ⼈、プロダクトオーナー1 ⼈、複数⼈の開発者で構成される。階層は存在しない。すなわちリーダーは存在しない。
それぞれは以下の責務を持ちます。

開発者の責任

• スプリントの計画を作成する
• 完成の定義を忠実に守ることにより品質を作り込む
• スプリントゴールに向けて毎日計画を適応させる
• 専門家としてお互いに責任を持つ

プロダクトオーナーの責任

• プロダクトの価値を最大化する
• プロダクトゴールを策定し、明示的に伝える
• プロダクトバックログアイテムを作成し、明確に伝える
• プロダクトバックログアイテムを並び替え、プロダクトバックログに透明性があり、見える化され、理解されるようにする

スクラムマスターの責任

• スクラムを確実にさせる
• スクラムチームの有効性に責任を持つ
• スクラムチームがスクラムフレームワーク内でプラクティスを改善できるようにする
• スクラムチームが完成の定義を満たす価値の高いインクリメントの作成に集中できるよう支援する
• スクラムチームの進捗を妨げる障害物を排除するように働きかける
• すべてのスクラムイベントが開催され、ポジティブで生産的であり、タイムボックスの制限が守られるようにする

スクラムイベント

スクラムイベントとは、スクラムフレームワークの一部として定義されている一連の会議や活動のことを指します。これらのイベントは、スクラムチームが定期的に作業を計画、検討、調整し、進捗を確認するためのものです。以下に主なスクラムイベントです。

• スプリントプランニング
  スプリントの開始時に行われる会議で、スクラムチーム全体が参加します。この会議では、次のスプリントで何を達成するか（スプリントゴール）、どのように達成するか（スプリントバックログ）を決定します。

• デイリースクラム
  スクラムチームが毎日行う15分の会議です。この会議では、前日の進捗、今日の作業内容、問題点や障害があればそれについて話し合います。デイリースクラムは、スクラムチームがスプリントゴールに向けて進行中の作業を調整するための重要な機会です。もしスプリントゴールを達成できないことが認識できた場合はプロダクトオーナーに共有した方が良いでしょう。
  以下の問いにメンバー全員が答えられる状態が理想です。

1. スプリントゴールを達成するために昨日やったことは何か
2. スプリントゴールを達成するために今日やることは何か
3. スプリントゴール達成に向けての障害となるものを目撃したか

• スプリントレビュー
  スプリントの終了時に行われる会議で、スクラムチームとステークホルダーが参加します。この会議では、スプリントで完成したプロダクトバックログアイテムをデモンストレーションし、レビューしてもらい、プロダクトバックログを更新します。

成果発表会ではない。成果をレビューし、次に何をすべきかに着目するものである。

• スプリントレトロスペクティブ
  スプリントの終了時に行われる会議で、スクラムチーム全体が参加します。この会議では、スプリントの成功点と改善点を振り返り、次のスプリントでどのように改善するかを決定します。

スクラムの成果物

• プロダクトバックログ
  プロダクトの改善に必要な要素のリストで、これらの要素は優先順位が付けられています。これはスクラムチームが行う作業の唯一の情報源であり、スプリント内でスクラムチームが完成できるプロダクトバックログアイテムは、スプリントプランニングの時点で選択の準備ができている必要があります。プロダクトバックログの確約（コミットメント）はプロダクトゴールで、これはプロダクトの将来の状態を表しています。

• スプリントバックログ
  スプリントゴール（なぜ）、スプリント向けに選択されたいくつかのプロダクトバックログアイテム（何を）、およびインクリメントを届けるための実行可能な計画（どのように）で構成されます。スプリントバックログは、開発者による、開発者のための計画であり、スプリントゴールを達成するために開発者がスプリントで行う作業がリアルタイムに反映されます。スプリントバックログの確約（コミットメント）はスプリントゴールで、これはスプリントの唯一の目的です。

• インクリメント
  スクラムにおける重要な概念で、プロジェクトのゴールやビジョンに向けた前進的なステップを表します。具体的には、プロダクトインクリメントはスプリント中に完成したバックログアイテムの集合体であり、それには前のスプリントで完成したものも含まれます。各スプリントの終わりには、製品が生産フェーズに移行し、実際に使用可能な状態、つまり「完成」した状態であるべきです。

ここまででスクラムガイドと私の理解・解釈を記載してきました。
要約すると、スクラムは、複雑なプロジェクトを効率的に進めるためのアジャイル開発手法です。メリットとしては、変化に対する迅速な対応、透明性の確保、チームの自己組織化を促進することが挙げられます。スクラムは、一定期間（スプリント）ごとに製品のインクリメントを生み出すサイクルで進行します。スプリント計画、デイリースクラム、スプリントレビュー、スプリントレトロスペクティブといったイベントを通じて、チームはプロジェクトを進め、改善するということです。

記事は徐々に更新するスタイルで・・・（続く）