<aside> 💡 これはスクラム研修用の事前学習コンテンツです。 スクラム研修ではワークショップを通じた体験学習を重視しているため、このコンテンツでは全てを説明することはせず、必要な要素を厳選して作成しました。 もっと詳しくを知りたい人は、下記参考資料をご覧ください。

</aside>

目次

参考資料

1.スクラムについて知ろう

スクラムとは

scrum guide 2020によるとスクラムは下記のように定義されている

引用: Ken Schwaber & Jeff Sutherland著, スクラムガイド，2020年，p.4．https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf (参照 2024-3-22)

<aside> 💡 スクラムは全てを解決する銀の弾丸ではありません。 スクラムは「理解は容易、習得は困難」と言われます。 手段の1つでしかなく、スクラムフレームワークを遵守していれば良いというものでもありません。 スクラムは変化に適応できるチームであり続けるための学習の習慣化フレームワークです。

</aside>

スクラムが解決したかったこと

<aside> 💡 2001年に、17名の著名なエンジニアがソフトウェア開発について今後どのようにあるべきかについて議論した結果を**「アジャイルソフトウェア開発宣言」として公表しました。 スクラムとは、この「アジャイルソフトウェア開発宣言」**という概念の基となった実際の開発手法の一つとなります。

</aside>

| 「アジャイル宣言の背後にある原則」原文 (したいこと) | 原文から読み取れる課題背景 (解決したかったこと) | 何が困るのか？ | | --- | --- | --- | | 顧客満足を最優先し、 | 顧客満足を最優先にしてこなかった | 利用者（顧客）の満足度が上がらない・印象が悪くなる | | 価値のあるソフトウェアを早く継続的に提供します。 | 早く継続的に価値を提供できなかった | 日々変化し続ける利用者のニーズ・ビジネスのニーズに適応した価値を早く届けられない | | 要求の変更はたとえ開発の後期であっても歓迎します。 | 要求の変更は歓迎されなかった | 変更された要求と作り始めているソフトウェアの整合性をとるのにコストがかかっている | | 変化を味方につけることによって、お客様の競争力を引き上げます。 | 変化は敵だったので、お客様の競争力を引き上げられなかった | 常に変化し続けるビジネス要件への適応ができず、ビジネス競争力が落ちる | | 動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。 | できるだけ短い時間間隔でリリースできなかった・しなかった | 常に変化し続けるビジネス要件の確認もしづらく、既存ユーザーへの改善もすぐに反映できない | | ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。 | ビジネス側と開発者側で、コミュニケーションをとることが少なく同じものを作るという意識がなく、協働してこなかった | ビジネスが考えている意図とは違うものが出来上がってしまう | | 意欲に満ちた人々を集めてプロジェクトを構成します。 | プロダクトの価値向上に対する意欲に満ちた人々を集めることが重要視されていなかった | 利用者・プロダクトに向き合うメンバーが少なく、本当に必要な機能の判断を誤る | | 環境と支援を与え仕事が無事終わるまで彼らを信頼します。 | 環境と支援が満足に与えられず、メンバーも信頼されていなかった | 良い環境と支援がないため開発効率が悪く、かつ、信頼されていないので過剰なマネジメントが発生し、更にモチベーションが下がる。 | | 情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。 | メール、電話、チケット、仕様書等の相手の顔が見えない情報伝達ばかりを利用し、効率が悪くなっていた | 読み違いや温度感の捉え間違いで情報のすれ違いが発生し、大量の修正が発生してしまう。 | | 動くソフトウェアこそが進捗の最も重要な尺度です。 | 動くものではなく、工程毎の成果物、実態が見えない進捗報告や消費した工数・費用で評価していた | 工程毎の成果物を出すことや、発注者を無意味に喜ばせるための作業報告書提出が目的になってしまい、手段が目的化されてしまう | | アジャイル･プロセスは持続可能な開発を促進します。 | 持続可能な開発ができなかった | 既存の開発プロセスだと立ち上げからリリースまでに時間もお金も大きくかかるため、何度も開発を繰り返すことができず機能拡張などがなかなかできなかった | | 一定のペースを継続的に維持できるようにしなければなりません。 | 一定のペースで継続的に開発ができなかった | タスク量が時期によりかなり異なるので、残業・徹夜などが定期的に発生してしまい、品質・生産性が安定せず且つメンバーも疲弊しチームが安定しない | | 技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。 | 優れた新しい技術や設計に注目せず、古い技術や設計のまま開発をし続けることで変化に機敏に対応できなかった | 古い技術や設計のままなので、対応できる人員がいなくなったり、新しい機能を追加しようと思っても簡単にできなかった | | シンプルさ（ムダなく作れる量を最大限にすること）が本質です。 | 無駄な制作物が多くシンプルではないことがおおかった | 必要だと思われる機能を想像で作っているので、使われない機能が増え顧客課題の解決に時間を取れなくなる | | 最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。 | 最良のアーキテクチャ・要求・設計は、上流工程の担当者が決めていて、絵に描いた餅であることが多かった | 実際に作ってみたら良くなかったということが多く手戻りが増える | | チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。 | 振り返りなどなく、適宜効率を高める対処プロセスがなかった | 改善プロセスがないため、プロジェクトマネージャー・リーダー次第でプロジェクトの成否が決まってしまう |