スクラム開発をやり始めて、初心者なりにも色々と考えることが多くなってきたので備忘録として残します。
あくまで1年間やってきた個人の感想なので、正式な団体の解釈とは異なる可能性があります。
結論
スクラム（ひいてはアジャイル）は、全てのプロセスが良いプロダクトを生み出すために存在することを意識し続けることが最も大切
個人的にはそれを実現するために、スクラムというフレームワークがあり、振り返りの手法などが発展しているのだと考えています。
より良いプロダクトを作るには、より良いチームが必要です。そして、より良いチーム作りにはそのチームごとに様々な手法があります。そのサイクルをどう上手く回していくのかが、スクラムマスターとして、あるいはスクラムチームメンバーとして必要だと1年を通じて感じました。
ざっくりスクラム概要
スクラム開発にスクラム開発に馴染みがない方向けに、ざっくりとしたスクラムの説明を載せておきます。
スクラムはアジャイル開発手法の一つで、経験主義に基づいたフレームワークです。
最初から完璧な計画を立てるのではなく、「やってみて、結果を見て、調整する」ことを重視します。
そのために、スプリントという短い期間（1〜4週間）を区切り、以下のサイクルを繰り返します。
- 透明性 (Transparency): チームの状況やプロダクトの状態を見えるようにする
- 検査 (Inspection): 定期的なイベント（デイリースクラムやレビューなど）で現状を確認する
- 適応 (Adaptation): 問題があればすぐに計画や動き方を修正する
このサイクルを回すために、PO・スクラムマスター・開発者という3つの役割が定義されています。
詳しくは、このスクラムガイドに書かれていますが、内容はカタカナが多くて理解しづらい部分もあるかもしれません。
そんな方は、Ryuzeeさんのこのまとめがとても分かりやすいですのでおすすめです。
当初のスクラムに対する見方
スクラム開発初心者の私が、スクラムガイドを読んだり、初心者向けのスクラムの本や記事を読んだりした最初の感想は、
「この仕組みで価値のある開発が本当にできるのか？」
という疑問でした。
内容を読んで、スクラムイベントの意義は伝わるし、チームに合わせて様々なプラクティスがあることは理解しました。しかし、「こんな綺麗事（言い方は悪いですが）が本当にワークするんだろうか？」と疑っていました。
1年やってみて
チームメンバーの支えもあって、個人的にはとても良いスクラムが1年できたと感じます。
「この仕組みで価値のある開発が本当にできるのか？」
という疑問に対する今の私の回答は以下です。
「正しく理解して実践すればできる」
何のために各スクラムイベントがあるのか、ロールがあるのかを理解してくると、「スクラムってよく出来ているな〜」という気持ちになります。
なんとなくでは勿論ワークしない
よくスクラム開発で出るのは、"理解することは簡単だけど、やってみると難しい" という意見です。
スクラムガイドに書かれていることを忠実になぞってやってみたけれど、どこかで「なぜこんなことをやっているんだろう」という気持ちになる場面があったりします。
なんとなくスクラムでプロダクト開発をしてみても、一向に動くものができない、なんて場面もあるかもしれません。
それは、スクラムガイドには書かれていますが、文字だけでは伝わらないポイントがいくつもあるからだと考えています。
例えばスクラムガイドの「デイリースクラム」の項目には、以下のように書かれています。
デイリースクラムの⽬的は、計画された今後の作業を調整しながら、スプリントゴールに対する進捗を検査し、必要に応じてスプリントバックログを適応させることである。
デイリースクラムは、コミュニケーションを改善し、障害物を特定し、迅速な意思決定を促進する。その結果、他の会議を不要にする。
進捗を確認するだけであれば簡単に思えます。
ただ実際は、実装に少し困っている（タスクに遅延が発生する可能性がある）開発者と有識者を引き合わせたり、別にステークホルダーと調整が必要そうな事項が出てきていないかを確認したりするなど、その時点での障害点を明確にする場です。
スプリントゴールまでに予定したPBIを終わらせることに集中するために、何かできることはないかと開発者同士で向き合う場になっていくはずです。
私は1年で何を考えたか？
スクラム開発とアジャイル開発をごっちゃにしない方が良いとは思いますが、私はスクラムの前にアジャイル開発をちゃんと理解していなかったなと気づきました。
この話を深掘りする前に、皆さんはアジャイルソフトウェア開発宣言を読んだことがあるでしょうか？
この文章の最初の一行には以下が書かれています。
私たちは以下の原則に従う:顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
顧客満足を最優先し、価値のあるソフトウェアを提供する
という箇所が、しっかり理解できていませんでした。（これは私個人の甘さで、他の方は出来ていると感じています）
開発を進めていくと、エンジニアリングが好きなこともあってかなり没頭してしまいます。タスクに集中すると、なぜそのタスクが必要なのかが見えなくなってきます。
習慣化し、成熟したリファインメントを経てチーム全員で議論して作ったPBIを、淡々と作業していく。
スクラムチームの開発メンバーだった私には、それがとても心地良かったです。（この時のスクラムマスターの方が色々と配慮してくださっていた結果だと思います）
この時の私は、「開発者として」プロダクトを見ていました。
ただ、視座が少し上がり、もっとPOと今後のプロダクトの方針を議論する場面で壁に当たりました。
「開発者としてプロダクトを見た時」 と、「プロダクト視点で見た時に開発者としてどう振る舞えるのか」 とでは、少し違う景色が見えました。
自分ではプロダクトを考えている開発者のつもりだったのですが、前者は後者に比べると少し受け身っぽいところがあったのです。
単に「開発者としてその機能はこうした方が良い」という観点だけではなく、「プロダクトの未来がこうであるならば、技術的な視点からその機能はこうした方が良い」という意見を出すことが求められていました。
その視点を持った時、ぼんやりしながら作っていたプロダクトが、とても生きたものに感じられてきました。
おわりに： スクラムであるかなんて気にしない
見出しが議論を生む文になっていることはご容赦ください。スクラムの型を崩したらスクラムではないことも理解しています。ただ、スクラムの本質を忘れないようにしたいという意図です。
最後に私が心にグッときた大好きな本の引用をもって、この記事を締めたいと思います。
（まだこの本を読んでない方は是非読んでみてください）
「どうでしょう？私たちはアジャイルでしょうか？」ー アジャイル開発への取り組みを始めてまもないチームからはこうした質問がよく寄せられる。
もっともな疑問だとは思う。誰だって何か新しいことを始めた時には、自分たちが規定通りにやれているかどうかが気になるものだ。
でも、そんなことは気にしなくていいんだ。ただ気づけば良いー守らなきゃならない規則やルールなんかないんだってことにね。
〜中略〜
肝に銘じてほしい。アジャイルで「あること」なんてどうでもいいんだ。大切なのは素晴らしいプロダクトを作ることと、それを君のお客さんにちゃんと届けることなんだ。Jonathan Rasmusson. アジャイルサムライ: 達人開発者への道. 西村直人ほか監訳. オーム社, 2011, p. 287
アジャイルであるか、スクラムであるかといった文脈も必要ですが、「本当にプロダクトに向き合えているか」を問い続けることを、今後も忘れないようにしたいです。