こちらはdoda Developer Group Advent Calendar 2024 の20日目の記事です。
- はじめに
- スクラムって開発が早くできるようになるんですよね？
- スクラムって柔軟な変更を受け入れるフレームワークだから綿密な計画は立てなくていいんですよね？
- スクラムってドキュメントとか作らなくていいんですよね？
- 開発者ってプログラミングする人ですよね？/プロダクトオーナーって企画する人ですよね？/スクラムマスターってプロジェクトマネージャー的なやつですよね？
- おわりに
はじめに
こんにちは、パーソルキャリアでdodaの開発組織のマネジメントや組織横断の開発プロセス改善を担当している地家です。
dodaでは多くのチームがアジャイル開発、具体的にはスクラムを採用しています。本記事では生命、宇宙、そして万物についての究極の疑問の答え*1はお伝えできませんが、スクラムにおけるよくある誤解や偏見、陥りがちなアンチパターンについて、スクラムガイドやアジャイルソフトウェア開発宣言に書かれた内容も参照しながら解き明かしていきたいと思います。
スクラムって開発が早くできるようになるんですよね？
なりません。
みなさんも一度は言ったり言われたりしたことがあるのではないでしょうか。
スクラムによって現在のマネジメント、環境、作業技術の相対的な有効性が可視化され、改善が可能になるのである。
引用元：スクラムガイド（2020年版）
とスクラムガイドにも書かれている通り、スクラムはあくまでも現状を可視化するフレームワークです。現状を可視化*2することによって課題が浮き彫りになり*3、課題を解決することによって結果的に開発パフォーマンスが向上する*4、というサイクルを回し続けることが重要です。
スクラムって柔軟な変更を受け入れるフレームワークだから綿密な計画は立てなくていいんですよね？
ダメです。
アジャイルソフトウェア開発宣言を見てみましょう。
計画に従うことよりも変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。引用元：アジャイルソフトウェア開発宣言
変化への対応が重要であると書かれていますが、計画を立てなくてもよい、とは言っていません。初期段階では見えていなかったタスクが開発を進める中で出てきたり、見積もりの前提が変わる場合はありますが、状況に応じて適切に見直していくためにもベースとなる計画はきちんと作成しておく必要があります。
スクラムってドキュメントとか作らなくていいんですよね？
いいえ。
もう一度アジャイルソフトウェア開発宣言を見てみましょう。
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
（中略）価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。引用元：アジャイルソフトウェア開発宣言
上記からわかるように、ドキュメントよりも動くソフトウェアに価値があります、ということを言っているだけで、ドキュメントには価値がありません、という話ではなさそうです。
どういう意図でこの記載があるのかを知るために、アジャイル宣言の背後にある原則の中で関連しそうな記述を見てみましょう。
情報を伝えるもっとも効率的で効果的な方法は
フェイス・トゥ・フェイスで話をすることです。動くソフトウェアこそが進捗の最も重要な尺度です。
引用元：アジャイル宣言の背後にある原則
これを見る限り、情報伝達や進捗報告のためのドキュメント作成に時間を費やすなら、動くソフトウェアの開発に注力しましょう、ということのようです。
逆に言えば、ソフトウェア開発のために必要なドキュメント作成については否定していません。どのようなドキュメントであれば作成すべきなのか、チームやステークホルダーと合意しておくとよいでしょう。
開発者ってプログラミングする人ですよね？/プロダクトオーナーって企画する人ですよね？/スクラムマスターってプロジェクトマネージャー的なやつですよね？
違います。スクラムチームの3つのロールについてそれぞれ見ていきましょう。
開発者
開発者はスクラムチームの⼀員である。各スプリントにおいて、利⽤可能なインクリメントのあらゆる側⾯を作成することを確約する。
開発者が必要とする特定のスキルは、幅広く、作業の領域によって異なる。
引用元：スクラムガイド（2020年版）
上記の通り、単語からイメージする『開発者=エンジニア』ではなくもう少し広い役割を想定しているようです。また、スプリントの計画作成や適応など、ウォーターフォール型のプロジェクトではプロジェクトマネージャーの仕事とされる部分についても開発者の責任とされています。
プロダクトオーナー
プロダクトオーナーは、スクラムチームから⽣み出されるプロダクトの価値を最⼤化することの結果に責任を持つ。組織・スクラムチーム・個⼈によって、その⽅法はさまざまである。
プロダクトオーナーは、効果的なプロダクトバックログ管理にも責任を持つ。
（中略）
上記の作業は、プロダクトオーナーが⾏うこともできるが、他の⼈に委任することもできる。いずれの場合も、最終的な責任はプロダクトオーナーが持つ。
引用元：スクラムガイド（2020年版）
プロダクトオーナーの役割はチームの生み出すプロダクトの価値の最大化であり、そのための手段としてプロダクトバックログアイテムの作成、並び替えなどの管理を行いプロダクトバックログを効果的に保つ、という構造であることがわかります。
また、最終的な責任がプロダクトオーナーにあればプロダクトバックログ管理の作業自体は他の人に委任することができる、と書かれています。例えば、プロダクトオーナーが優先度高く解決したい課題を提示し、それをどう解決するかを開発者が要件として具体化する、という分担になっているチームもあるのではないでしょうか。
スクラムマスター
スクラムマスターは、スクラムガイドで定義されたスクラムを確⽴させることの結果に責任を持つ。スクラムマスターは、スクラムチームと組織において、スクラムの理論とプラクティスを全員に理解してもらえるよう⽀援することで、その責任を果たす。
スクラムマスターは、スクラムチームの有効性に責任を持つ。スクラムマスターは、スクラムチームがスクラムフレームワーク内でプラクティスを改善できるようにすることで、その責任を果たす。
スクラムマスターは、スクラムチームと、より⼤きな組織に奉仕する真のリーダーである。
引用元：スクラムガイド（2020年版）
スクラムマスターの役割は、チームやプロダクトオーナー、組織を支援することでスクラムへの理解を広げ、チームを有効に機能させることです。
チームや組織の状態によって効果的な関わり方は変わるため、例えば立ち上げ初期のチームであればスクラムの基礎を改めてチームに説明し、時には指示的なコミュニケーションが必要な場面もあるでしょう。また、一定成熟してきたチームにおいてはスクラムマスターはチーム内への関与よりもチーム外の組織とのコミュニケーションを増やすことで、よりチームが有効に機能する環境を作れるかもしれません。
逆にスクラムマスターがイベントのファシリテーターなどチーム内での役割を担う場合は、それがスクラムマスターやチームにとって最も有効な関わり方なのか、ファシリテートをすることでの狙いは何なのか、を意識しておくとよいでしょう。
自分自身の経験を振り返っても、明確なタスクが定められていないのがスクラムマスターの難しさであり面白みでもあると感じます。逆に言えば、スクラムマスターのチームとの関わり方が長期間変わっていなければそれ自体が改善すべき課題の兆候と言えるかもしれません。
ということは
スクラムガイドの記述から、開発者はプログラミングだけでなくプロダクトの価値を高めるための作業全般を担う必要があり、プロダクトオーナーは企画/要件定義をする人ではなくプロダクト価値の最大化に責任を持ち、スクラムマスターは一般的なプロジェクトマネジメントではなくチームが有効に機能するための役割である、ということがわかりました。
みなさんのチームではどうなっているでしょうか。
おわりに
ここまでご覧いただきありがとうございました。
スクラムは非常に軽量なフレームワークであり、いざやるとなると具体的に何をどう進めればよいのかがわからない、自分たちのチームがうまくスクラムを実践できているか不安、という方も多いと思います。そんなときは本記事のようにスクラムガイドやアジャイルソフトウェア開発宣言に立ち戻ることで新たな気付きや改善の糸口が見つかるかもしれません。
地家 伶人 Reito Jike
ITアーキテクチャ統括部 プロセス管理部 ゼネラルマネジャー
2014年にパーソルキャリア（旧インテリジェンス）に新卒入社。アルバイト求人情報サービス『an』でプロジェクトマネジャーを経験したのちエンジニアとしてスマホアプリ開発に従事。その後dodaアプリのスクラムマスターやプロダクトオーナー、dodaの開発組織マネジメントを務め、2024年4月からパーソルキャリア全体の開発品質改善・プロセスの高度化を担当。
※2024年12月時点の情報です。
