スクラムに登場する役割は3つだ。
- プロダクトオーナー
- 開発チーム
- スクラムマスター
私の経験上、1番多いのは「プロダクトオーナー」。
次に「開発チーム」。
最後は「スクラムマスター」である。
スクラムマスターが重要という人は、大抵、自分自身がスクラムマスターだ。
加えて、詳しくない人が、スクラムの話なんだから、スクラムのマスター(主)でしょ、という人が若干名。。
私の回答はというと、「全員」である。
優等生的な回答だが、事実なのだから仕方がない。
プロダクトオーナーが1番重要というのはよくわかる。顧客の声を代弁する立場で、正しいものをつくる責任があるから、ここが肝だ。
最上位の組織戦略との整合性を担保し、予算を確保する責任も担う。ここが機能しないと立ちゆかなくなる。
開発チームが重要なのは、唯一、アイデアをカタチにできる部隊だからである。もの作りのエンジンは開発チームである。
要求がいかに正しく、顧客価値を表わしていても、作れないと絵に描いた餅だ。ものやサービスを生み出す力を持っている開発チームが重要だという回答もごもっともである。
3番目のスクラムマスターも、とても重要だ。バランスよく全体最適を実現するために、スクラムマスターの存在が欠かせない。
健全なもの作りにおいて、プロダクトオーナーと開発チームの力関係はイコールではくてはならない。POは理不尽な要求を一方的に押しつけてはいけないし、開発チームも、顧客の安全や、使い勝手を無視したソリューションを提供してはいけない。
互いに対話を重ね、最良のプロダクトを探索し、コラボレーションするよう仕向けないといけない。
スクラムマスターはリスク察知能力が最も高い人物である。リスクが顕在化する前に、開発チームに気づきを与えて未然に防いだり、もの作りのプロセス全体を俯瞰し、安定感を欠いている箇所があれば、改善するようファシリテートする。
だから、特定の一つの役割が偉いということはなく、全員大切なのだ。
あえて言うなら、スクラムチームの成熟度により、フォーカスすべき役割が変わる。
チームの成熟段階により、第一にトラクションをかける役割が変わる。
もし、スクラムを始めたばかりで、もの作りがスクラミー・フォール状態なら、1番ケアしないといけないのは「開発チーム」だ。
正しいもの云々の前に、作る能力が絶対的に欠けている。自転車キコキコの手動状態だからエンジンを積むことを考えないといけない。
テスト駆動開発と常時結合のプラクティス、コードのバージョン管理やテスト自動化の仕組みを入れないと、コーディングとテストが加速しない。上流で要求をどれだけ小粒にしても、単発的な開発しかできず失速してしまうのだ。
スクラムチームが未熟な状況では、まず作る能力をつけることが最優先である。もし作ったものが間違っていたら、軌道修正していけばいい。動力性能は獲得したのだから。
一方、スクラム中級で、常時結合の仕組みもできており、テスト自動化もなされ、アジャイルのエンジニアリング・プラクティスも導入済みなら、「プロダクトオーナー」の仕事が最重要である。
POの仕事のできばえが、顧客が手にする価値の総量を左右する。
ヘタなものを作らせると、開発チームの努力が水泡に帰す。
スクラムマスターは、プロダクトライフサイクル通して、状況を見える化して、気づきを与え、チームが正しく判断できるよう促す。
率先してリスクを検知し、気づきを与え、チームがリスクを回避することを支援する。
何事も、治療よりも予防だ。
スクラムは全輪駆動だ。
前輪も後輪も、右の車輪も左の車輪も、相互に助け合いながら走る。
与えられた役割は異なるが、全員で協業してモノを作っていく。パンクしては走れない。どのタイヤも欠くことはできない。
スクラムでは全ての役割が重要なのである。
![]() |