実践から見えてきたスクラム像 ～スクラムで大事な2つのこと～

私は半年ほど前にアジャイル開発の代表的手法の一つである「スクラム」を採用したプロジェクトへ異動し、開発者としてスクラムデビューを果たしました。今回はその中で感じたことや発見したことなどをスクラムビギナー目線でまとめました。

この記事で伝えたい結論を先に表現すると
「スクラムで大事なことは

• まずはルールを厳守してみる
• 尊敬（Respect）を忘れないこと

であると実感した」

というお話です。

まだまだ勉強中の身ではありますが、アジャイル開発に興味がある方や、これからスクラムにチャレンジする方などに少しでも参考になれば幸いです。

スクラムとは

ご存じの方も多いかとは思いますが、アジャイル開発とスクラムについて簡単にご紹介します。

アジャイル開発は開発期間を短く区切って開発を進め、優先度の高い項目から進めていきます。
この区切った期間で最低限の機能リリースを繰り返すのが大きな特徴です。そして優先度の高い項目は、いつでも入れ替え可能となっています。

このように、プロダクトを生み出す過程であっても常に変更や設計計画の修正ができるため、その時々のニーズに合ったプロダクト生成を目指すことができます。

要件が変化しやすいプロジェクトと相性が良く、 頻繁にアップデートが必要となるWEBサービス開発などでは一般的な開発手法と認知されています。

このアジャイル開発手法の１つがスクラムです。
（「スクラムはアジャイルである」は正しいですが「アジャイルはスクラムである」は間違いです。）

スクラムの基本的な定義・理論は「スクラムガイド」という公式の資料にまとまっており、内容はシンプルですが大事な考え方がぎゅっと凝縮されています。

まだ読んだことがない方は、この機会にぜひ一読してみてください。

実践から見えてきたもの

さて、ここまででスクラムはこの時代にあった便利で優秀なフレームワークである、ということはざっくりお伝えできたのではないかと思います。

ただ、プロジェクトにアサインされた当初の私はスクラムのいろはを身につけるまでとても苦労しました。なにが大変だったかを思い返してみると、大きく以下2点に集約されます。

苦労したこと①：スクラム特有のルールや用語の多さ

プロジェクトへ参画して最初に驚いたのが、話し合いの時間がすごく多いということ。

ユーザーストーリーマッピングやDoneの定義を決めるような開発初期段階のみならず、少しでも全員の認識がズレていそうな話題があれば小まめに確認しあうのが印象的でした。

また、デイリースクラムやレトロスペクティブなどといった作成物の作成・検査・適応を目的とした各スクラムイベントの実施が決められています。

大まかに言うと「チームが正しい方向に進んでいるかを早めに確認し、問題があれば素早く解決していきましょう！」というのが目的で、イベントごとにやるべきことと推奨時間枠が細かく指定されています。

私がいるチームでは1週間スプリントで回していたため、毎週最低でも毎日のデイリースクラム＋プランニング＋リファインメント＋レビュー ＋ レトロスペクティブが打ち合わせとして入ってくるルーティンとなります。こんなに開発以外の時間を費やしていいものなの…？と不安になりました。

さらに、そもそもスクラム特有の用語が多いため、趣旨を理解しながら会話についていくまでにも時間がかかった覚えがあります。

「今回のスプリントではプランニングで決めたゴールの達成は可能だろうか？現状のインクリメントを一旦整理した方が良さそうだね」
「次回以降のスプリントも見据えて、バックログはプロダクトオーナーとリファインメントで調整する必要があると思います」

このような日常会話に最初は全くついていけませんでした…。

苦労したこと②：そこまでしてスクラムに当てはめる意味とは？

少しトゲのある表現になってしまいますが、純粋になぜここまでしてスクラムというフレームワークを適用すべきなのか？という疑問を抱いていた時期がありました。

例えば、

• 話し合いが中途半端な状態でも無理やり時間枠に納めるべきなのか？
• 開発状況に応じてルールを柔軟に変えるのはNG？
• イベントや話し合いの場が多いことが、逆に無駄を生む要因なのでは？
• コミュニケーションツールでのやりとりで十分なのでは？

などなど、私の中で「なぜスクラムをやるのか」が何となく腑に落ちない期間がありました。

スクラムを再認識

色々な疑問を感じつつではありましたが、私なりにこのように咀嚼していきました。

Q. なぜたくさんあるイベントを実施し、そのルールを守るべきなのか？
A. そうしないとレトロスペクティブに反映できず、問題点を正しく認識することができないから

これは実際にやり続ける中でわかったことなのですが、スクラムのメリットはやはり問題をすぐに可視化し、すばやく改善のための行動に移せることだと思います。

例えば、プランニングがいつも延長してしまうので時間枠を30分増やすとします。
仮に一時的に解決したとしても、「バックログの詳細についてプロダクトオーナーと開発者の間で話し合えてなかった」や「バックログの疑問点を挙げにくい空気がある」といった根本的な原因を見逃してしまう可能性があります。
これだとスプリントゴールの達成にも影響が出てしまいます。

まずはスクラムガイドの通りにやってみて、そこからはみ出てしまった部分（問題点）に対してどうやったら改善できるか？をチームで何度も繰り返していくことが非常に大切だと思います。
そのためのイベントであるプランニング → レビュー → レトロスペクティブを細かく反復していくことで、チーム全体が確実に成長していくように感じました。

まさに、スクラムガイドの「スクラムの定義」に書いてある、

スクラムとは、複雑な問題に対応する適応型のソリューションを通じて、⼈々、チーム、組織 が価値を⽣み出すための軽量級フレームワークである。

スクラムはシンプルである。まずはそのままの状態で試してほしい。そして、スクラムの哲学、理論、構造が、ゴールを達成し、価値を⽣み出すかどうかを判断してほしい。

スクラムは「経験主義」と「リーン思考」に基づいている。経験主義では、知識は経験から⽣まれ、意思決定は観察に基づく。リーン思考では、ムダを省き、本質に集中する。

引用元：スクラムガイド

に当てはまるなぁと思います。

大事なことは？

スクラムガイドには大事な考え方としてスクラムの三本柱（透明性、検査、適応）と5つの価値基準（確約、集中、公開、尊敬、勇気）が明記されています。

もし、この中で一番大事なものは何ですか？と聞かれたら私なりの回答は「尊敬」です。（もちろん全部守ってのスクラムである、というのは大前提ですが）

チームビルディングのようなお話になってしまいますが、チームで仕事をする上で心理的安全性を高めることはすごく重要かと思います。

特に、スクラムのようなチーム内の問題と常に向き合っていく進め方には特有のきつさがあるのも事実です。

なので、良いことでも悪いことでも、意見交換の際には相手の気持ちを尊重しつつ、自分の意見を適切に表現することが大事なのではないかと常々感じています。

また、私が所属しているチームには色々なスキルレベルの方が携わっています。様々な経歴をもつ方と常にコミュニケーションを取りながらタスクを進めているため、ありがたいことに技術的なアドバイスだけではなく、色々な視点での課題解決方法を共有していただけます。

エンジニア歴の長い方からはもちろんですが、スクラム経験のない方からあがる率直な質問に対しても「あれ、私理解できていないな…」とハッとさせられたことが何度もありました。

このような経験からも、技術スキルだけではなくチーム全員が成果に向けた意見を素直に言い合える関係性もより良いプロダクト開発につながる、と実感しました。

より心理的安全性の高いチームを目指していくためにも、物事の伝え方を意識し、気兼ねなく意見を言い合える環境づくりを継続していきたいです。

さいごに

以上をふまえて、私なりにスクラムを行う上での大事なことは

• まずはルールを厳守してみる
• 尊敬（Respect）を忘れないこと

だと考えます。

私もまだまだ勉強中ですが、スクラムは経験を重ねることで上手く適用できるようになると考えています。

今後も仕事を進めていく中で自分なりのスクラム論を見つけていきたいです！