私が「アジャイル開発とスクラム」という本に初めて出会ったのは、2013年3月30日に開催された Kanazawa.rb meetup #7「Agile x Kanazawa.rb のイベントでした。
当時の開発現場ではウォーターフォール型が主流でしたが、イベントでアジャイルのプラクティスに触れるうちに、その柔軟で効率的な考え方に魅了され、現場での導入を試みるようになりました。
このイベントには、「アジャイル開発とスクラム」の著者でもある 株式会社永和システムマネジメントの平鍋健児（現在、同社の代表取締役社長）さん が登壇されており、アジャイル開発の実践例について語っていました。
振り返ると、当時はスプリントの設計やチームの連携において準備不足から失敗することもありましたが、それでもアジャイルの価値を信じ、実践を続けてきました。その結果、得た学びと気づきは、私のキャリアに大きな影響を与えています。
そして、2021年に発行された「アジャイル開発とスクラム【第2版】」を手に取りました。
このレビューでは、12年間のアジャイル開発の実践を経て、本書がどのように役立つのかを振り返ります。
結果を急いだ失敗と、アジャイルの本質への気づき
初めてアジャイルに触れたのは2013年のことでした。
当時、私はある企業でプロジェクトマネージャー兼システムエンジニアとして7年目を迎えていました。
どれだけ大規模なプロジェクトでも、要求定義書、基本仕様書、画面遷移図、画面詳細図、ユースケース図──すべてのドキュメントを完璧に仕上げてから開発に渡すのが私の役割でした。
そんな中、「ドキュメント作成に追われる仕事から解放されたい」という不純な動機でアジャイル開発に飛びつきました。
しかし、すぐに気づかされます。アジャイルは単にドキュメントを減らすためのものではないということに。
大事なのは「ドキュメントを減らしたいからアジャイルを導入する」のではなく、「アジャイルを導入することで、役割が明確になり、やるべきことが整理され、結果として必要なドキュメントだけが残る」という点です。
つまり、アジャイルを正しく運用すれば、チーム内で情報が自然に流れ、余分なドキュメントは不要になるのです。
この考え方に気づいたとき、私のSEとしての仕事のスタイルは大きく変わりました。
「何事も結果を急いで飛びつくと失敗する」──その教訓とともに、アジャイルの本質を学び始めたのです。
ソフトウェア開発の進捗確認、本当に「見えて」いますか？
ソフトウェア開発において、進捗確認を開発者の自己申告に頼っていませんか？
もしそうなら、「どこまで終わっているのか分からない」「予定通り進んでいるのか不安」といった悩みを抱えているかもしれません。駆け出しのプロジェクトマネージャだったころの私も悩んでいました。
プログラムのソースコードは物理的に目に見えないため、開発の進行状況を把握するのは難しいものです。
特にウォーターフォール型の開発では、最終的な成果物が完成するまで、実際の進捗が分かりにくいという問題が生じがちです。
しかし、進捗の見える化だけが問題ではありません。 開発がうまく進まないもう一つの大きな原因は、「発注者と開発者の間にあるすれ違い」です。
要件が伝わらない、仕様が変わる、納品後に期待していたものと違う──このような問題は、単なる進捗管理の問題ではなく、発注者と開発者の協力不足から生じることが多いのです。
ここで重要なのが、「プロダクトオーナー（PO）」の存在です。
POが発注者側の人間であれば、仕様変更にも柔軟に対応でき、開発チームと一緒により良い製品を作り上げることができます。
たとえば、以下のようなアジャイルのプラクティスを活用することで、進捗管理と発注者との連携を強化できます。
✅ バーンダウンチャート：タスクの消化状況を視覚化し、計画と実績のズレをすぐに発見
✅ プロダクトバックログ：優先度の高い機能やタスクをリスト化し、進捗を管理
✅ スプリントバックログ：短期間の計画を立て、達成状況をチームで確認
✅ タスクかんばん：作業の「ToDo」「進行中」「完了」を視覚的に整理し、進捗をひと目で把握
スクラム開発の役割とプロダクトオーナーの理想的な関与
スクラム開発では、以下の3つの役割が重要です。
- プロダクトオーナー（PO）（発注者が務めるのが理想的）
- プロダクトの価値を最大化する責任者
- 開発チームと密に連携し、適切な優先順位をつける
- 発注者がPOになれば、仕様変更にも柔軟に対応可能
- スクラムマスター（SM）
- スクラムの理解と実践を促進する
- チームの障害を取り除き、開発プロセスを最適化
- 開発チーム
- 実際に開発を行うメンバー
- 自己組織化され、スプリントごとに価値のある製品を作り出す
プロダクトオーナーが発注者であることのメリット
本来、プロダクトオーナーは発注者の代表が務めるのが理想です。
発注者がPOとして開発に参加することで、以下のような利点があります。
✅ 仕様変更がスムーズに：POが常に開発に関与していれば、現場の状況を見ながら柔軟な意思決定ができる
✅ 丸投げ開発がなくなる：開発者と発注者が対話を重ねながら進めることで、認識のズレが減る
✅ Win-Winの関係が築ける：発注者も開発者も「作って終わり」ではなく、価値を共創できる
この仕組みを導入することで、アジャイル開発は単なる進捗管理の手法ではなく、「顧客第一の開発プロセス」として機能するのです。
スクラム開発の役割と機能
進捗の見える化と並んで、もう一つ重要なのが「スクラム開発における役割と機能」です。
アジャイル開発にスクラムを取り入れることで、チームのマネジメントを最適化できます。
スクラムのマネジメント機能について
基本的には3つの役割と、5つのイベントで成り立っています。
スクラムの3つの役割
- プロダクトオーナー – プロダクトの価値を最大化する責任者。プロダクトバックログの管理や優先順位付けを行い、ステークホルダーとの調整を担当します。
- スクラムマスター – スクラムの理解と実践を促進する役割。チームの障害を取り除き、スクラムの価値やルールが正しく実践されるよう支援します。
- 開発チーム – 実際の開発作業を行うメンバー。自己組織化されたチームとして、スプリントごとに価値のある製品を作り出します。
３つの作成物
- プロダクトバックログ（製品機能リスト） – プロダクトに必要な全ての機能や要件を優先順位付きで管理するリスト。プロダクトオーナーが責任を持って維持・更新します。
- スプリントバックログ（スプリント機能リスト） – 現在のスプリントで実装する機能を詳細化したタスクリスト。開発チームが見積もりと進捗を管理します。
- インクリメント（製品増加分） – スプリントで完成した、動作する製品の増分。「完成」の定義を満たし、検証可能な状態である必要があります。
スクラム5つのイベント
- スプリント – 1-4週間の期間で、実際の開発作業を行う反復的な開発サイクル。この期間中にプロダクトバックログから選択された項目をスプリントバックログとして実装し、インクリメントを作成します。
- スプリントプランニング – スプリントの開始時に行われる計画会議。プロダクトバックログから実装する項目を選択し、スプリントバックログを作成します。チーム全体で「何を」「どのように」実現するかを決定します。
- デイリースクラム（朝会） – 毎日15分程度の短い進捗確認会議。各メンバーが昨日の進捗、今日の予定、障害の有無を共有し、スプリントバックログの進捗を確認します。
- スプリントレビュー – スプリント終了時に行われる成果物の確認会議。完成したインクリメントをステークホルダーに提示し、フィードバックを得ます。プロダクトバックログの更新にも反映されます。
- スプリントレトロスペクティブ（ふりかえり） – スプリント終了後のプロセス改善会議。チームの作業プロセスを振り返り、次のスプリントでの改善点を特定します。これにより、継続的な開発プロセスの改善を図ります。
アジャイル開発のプラクティス
スクラムマネジメントを支えるために使えるプラクティス。
必須ではないが利用したほうがより、効率よくスクラム開発支えるフレームワークの紹介。
フレームワークの基本を自分たちのチームに合うようにアレンジすることもいいと思う。
プラクティスばかりが目立って、
- バーンダウンチャート – 残作業量の推移を示すグラフ。予定と実績を比較し、スプリントの進捗状況を可視化します。
- インセプションデッキ – プロジェクトの目的、課題、制約などを整理するためのツール。チームの方向性を統一し、プロジェクトの基礎を固めるのに役立ちます。
- ユーザーストーリー – 「誰が」「何を」「なぜ」したいのかを簡潔に記述する要件定義の手法。ユーザー視点での価値を明確にします。
- プランニングポーカー – チーム全員で作業の見積もりを行うゲーム形式の手法。各メンバーが同時に見積もりカードを出し、認識の違いを議論します。
- 朝会（デイリースクラム） – 毎日15分程度の短いミーティング。昨日やったこと、今日やること、困っていることを共有し、チームの同期を取ります。
- ふりかえり（レトロスペクティブ） – スプリント終了時に行うチームの振り返りミーティング。良かったこと、改善点を話し合い、次のスプリントに活かします。
- KPT（Keep、Problem、Try） – ふりかえりで使用するフレームワーク。継続すべきこと、問題点、次に試してみることを整理します。
- タスクかんばん – 作業の状態（ToDo、進行中、完了など）を視覚的に管理するボード。チームの作業状況を一目で把握できます。
まとめ
今回「アジャイル開発とスクラム【第2版】」を読んで、改めてアジャイル開発の本質を振り返ることができました。
アジャイル開発の成功は、進捗の可視化やスクラムのフレームワークを活用することだけではなく、「発注者と開発者が協力して価値を生み出すこと」 にあります。
もしあなたがプロジェクトマネージャーや管理職として、開発の進め方に悩んでいるなら、まずはプロダクトオーナーのあり方を見直し、発注者を巻き込んだスクラムの導入を検討してみるのも良いかもしれません。。