「スクラム開発の始め方」を考えてみた

はじめに

スクラム開発を始めるとき、何から着手するのか迷ったりしていませんか？

私たちのスクラムチームでは、最初のプロジェクトのMVPがリリースされるタイミングで長期間のふりかえりを行いました。

「タイムライン」や、「象、死んだ魚、嘔吐」といった手法で、プロジェクト全体の課題を洗い出したり、チームの闇（？）と向かい合ったのですが、チームにとって初めてのプロジェクトだったこともあり、ふりかえりが終わった後もメンバーからは沢山の改善点が出てきました。

プロジェクト初期にこうしておけば良かった といった改善点も多かったので、今回はその反省を含めプロジェクトの始め方を改めて考えてみたいと思います！

※ふりかえりをした時に参考にさせてもらった記事はこちらです。

スクラム開発のプロジェクトの始め方をフローチャートで整理してみた

プロジェクトの種から、スプリント１を開始するまでにフォーカスして、フローチャートを考えてみました。

Mermaidで埋め込んだら小さくなってしまいましたので、興味のある方はGitHub上で拡大してご覧ください。

プロジェクト化の判断

スプリント０を開始する前に、ビジネスとしての価値や外部連携を含めたシステム全体のアウトラインを決めて、プロジェクトとして成立することを確認します。
プロジェクト化する場合、最初にプロジェクト管理や情報共有、コミュニケーションの手段を確立することが望ましいと考えました。

スプリント０

スプリント０では、チームビルディングをはじめ、インセプションデッキの作成や、プロダクトバックログの作成と優先順位付け、ＭＶＰの定義といった作業を通じて、プロダクトの価値や背景、ゴールなどをチーム内で共有します。

テックスプリント０

その後、テックスプリント０として、アプリケーションのアーキテクチャを検討したのち、ブランクプロジェクトの作成やGitリポジトリの準備、コーディング規約やブランチ戦略を決めて、プロダクトの実装に入れる準備をします。
これは、スプリント１からインクリメントを提供できるようにするためです。

スプリント１

いざ、開発開始です！

参考）振り返りで出てきた改善点

せっかくなので、長期のふりかえりでどんな改善点が出てきたのか、一部を紹介したいと思います。

様々な観点での改善点が出ましたので、カテゴリに分けてまとめてみました。

🔍 スコープ管理：全体像の可視化と柔軟な見直し

• 初期段階でユーザーストーリーを出し切って全体のボリューム感を把握することが重要。じゃないと、リリース可能タイミングの見極めが出来ないので、スコープの変更可否の判断もできない。
• スコープ変更時は開発チームで影響見積もりを行い、「そもそもスコープ変更すべきかどうか」「リリース時期を調整できるか」などをプロダクトオーナーと共に判断すべき。じゃないと、品質が犠牲になる。

---

👥 プロダクトオーナーとステークホルダーの関わり方

• プロダクトオーナーはできる限り専任が望ましく、スクラムイベントには原則参加してもらいたい。じゃないと、チームとしての醸成がなかなか進まない。
• ステークホルダーの役割や承認権限は明確にしておき、承認してほしい事が含まれるスプリントレビューには権限のある人に積極的に参加してもらう。じゃないと、あとになってテーブルがひっくり返る。

---

🛠 技術的な前提と確認

• Webviewのような制限やクセがある技術や、AWSの新しい機能などについては、初期段階でフィジビリティを具体的にしっかり調査しておくこと。じゃないと、後で作り直す羽目になる。
• API仕様書は記載内容を鵜呑みにしたり、勝手に想像したりせずに、実際のリクエスト・レスポンスの生データを確認すること。じゃないと、後で作り直す羽目になる。

---

📞 コミュニケーションとドキュメント

• 宛先を絞ったメールや、チャットのダイレクトメッセージはなるべく使わない。じゃないと、透明性が保てなかったり、情報展開する手間ばかりかかってしまう。
• 開発やリリースにまつわる社内の手続きや承認フローは、あらかじめ洗い出しておく。じゃないと、リリース計画も立てられないし、漏れてたりすると・・・
• スクラム開発でも、要件定義書は最初から作っておく。じゃないと、スコープもブレるし、ステークホルダーとの認識が合わなかったりする。

---

📗 テスト・検証

• モバイルアプリの場合、実機での動作確認を早い段階から実施していく。じゃないと、デバイスやOS差異、操作感などの細かい指摘が後工程で多発する。
• テスト環境での制約（データの有無や操作制限）を事前に確認する。じゃないと、想定していたテストケースが消化出来なかったりする。

---

📈 タスク分担と育成

• 自主的なタスク取得も良いが、プランニング時にバランスのよいタスク配分を行うこと。じゃないと、スキルの偏りや属人化が進んでしまう。

まとめ

実際のプロジェクトを通じて得られる気付きは多く、次のプロジェクトではさらに高い品質とチームパフォーマンスを目指せると実感しています。スクラムは単なる開発手法ではなく、継続的な改善のカルチャーそのもの。これからも、ふりかえりを通じて一歩ずつ進化していきたいと思います。