ロール

ロール #

スクラムではアジャイル開発チームにおける役割を3つ規定しています。

  • プロダクトオーナー
  • プロダクト開発チーム
  • スクラムマスター

それぞれについて見ていきましょう。

プロダクトオーナー #

プロダクトオーナーはプロダクトの責任者です。 後述するプロダクトバックログの管理の管理者でもあります。 プロダクトオーナーはプロダクト開発チームを活用してプロダクトが生み出す価値を最大化する責任があります。 そのため、プロダクトバックログの管理の他に以下のような役割を担います。

  • プラダクトのビジョンを明らかにし、周りと共有する
  • おおよそのリソース計画を定める
  • 予算を管理する
  • 顧客やエンドユーザとプロダクトバックログの項目の内容を確認したり、作る順番、実現時期を相談して決める
  • 既存のプロダクトバックログの項目の内容を最新の状態に保つ
  • プロダクトバックログの項目の内容を関係者が理解できるように説明する
  • プロダクトバックログの内容が完成しているかどうかを確認する

プロダクトオーナーが決めたことを他人が勝手に覆すようなことはあってはいけません。 プロダクトオーナー自身が決めることで、結果に対して責任を負えるようになります。

プロダクト開発チーム #

プロダクト開発チームですが、これは更に2つのロールに細分化することができます。 仮説検証を担いユーザ体験に責任を負うプロダクトデザイナーと、 プロダクトの実装を担いプロダクトのデリバリと品質に責任を負うプロダクトデベロッパーです。

それぞれについて見ていきましょう。

プロダクトデザイナー #

プロダクトデザイナーはユーザー体験の責任者です。 プロダクトデザイナーは「エンドユーザは現状こういうことに困っているのではないか？」 「こういう機能があればエンドユーザの抱える課題は解消するのではないか？」というものを挙げて検討します。 これを仮説といいます。 仮説を立てたら、プロトタイプを作ります。プロトタイプは紙芝居や張りぼてのようなもので大丈夫です。 この時点では実際にプロダクトデベロッパーがものを作るということはしません。すぐに形にできるものであることが大事です。

プロトタイプができたらエンドユーザに対してヒアリングを行い、立てた仮説が正しいかどうかを確認します。 これを仮説検証といいます。 仮説検証の結果、エンドユーザにとって価値があるとわかったものをプロダクトオーナーと連携してプロダクトバックログを作成します。

プロダクトデザイナーは仮説立案とその検証を繰り返して、ユーザ体験そのものをモデリングしていきます。 デザイナーという肩書からプロダクトの見た目を担う役割だと想像されるかもしれません。 もちろん見た目も仮説検証の対象ではありますが、プロダクトデザイナーの役割はそれだけにとどまりません。 Designという言葉の意味は設計です。決して見た目のような表面的なものではありません。

プロダクトデベロッパー #

プロダクトデベロッパーはプロダクトの実装を担い、その品質に責任を負います。 プロダクトバックログにはプロダクトデベロッパーが実装すべき仕様が並びますが、 それをどのように実装するかはプロダクトデベロッパーにすべて一任されています。

どのようなアーキテクチャを採用するか、どのようなフレームワークを採用するか、 どのような言語を採用するか、どのような製品やライブラリを採用するか・・・ プロダクトの実装に関わるありとあらゆる裁量がプロダクトデベロッパーに委ねられており、 それを都度決定しながらプロダクトを責任持って製造し、エンドユーザに提供するのがデベロッパーの役割です。

デベロッパーは非常に高い裁量を持っていますが、それと同時に負うべき責任も非常に大きいロールとも言えます。 まず、デベロッパーにはプロダクトを作るために必要なすべての作業ができなければいけません。 要求の分析、設計、実装、サーバの構築、テスト、デプロイ、監視・・・ありとあらゆる範囲をカバーするチームを構成します。 これを機能横断的なチームと呼びます。 ウォーターフォールの開発では「要求分析チーム」、「アプリチーム」、「DBチーム」、「基盤チーム」、「テストチーム」のような専門のサブチームを作って作業を行いますが、 スクラムではそうした専門のチームを作ることはしません。 開発メンバーごとにできることが違ったり、能力に差があったりしますが、作業を進めていく過程でなるべく個人が複数のことをできるようにしていきます。

スクラムマスター #

スクラムマスターというロールは少し特殊で、直接プロダクトの実装にかかわることはしません。 スクラムマスターは第三者的な目線でスクラムがうまく回るように立ち振る舞う役割です。 マネージャーや管理者ではありませんし、タスクのアサインや進捗管理もすることはありません。

スクラムマスターはスクラムのルールや作成物、進め方をプロダクトオーナーや開発チームに理解させ、 効果的な実践を促し、スクラムの外にいる人からの妨害や割り込みからプロダクトオーナーや開発チームを守るという役割を担います。 また、開発チームがスクラムでの開発に慣れていない段階では、やり方を教えたり、 イベントの司会進行をしたり、コーチングをしたりします。 開発チームが自律的にうまく仕事をすすめるようになったら、うまく仕事をすすめるようなヒントを与えたり、 プロダクトオーナーや開発チームがの求めに応じて作業を助けたりします。

スクラムマスターを置くべきかどうかというのは議論があるところですが、 筆者はスクラムマスターを置くべきという考えです。 というのも開発チームとして作業をしていると、次第に作業がルーチン化していきます。 そして、ルーチン化した作業に対してなんの疑問も抱かなくなるためです。 ルーチン化した作業は自律的な改善が効かなくなり、プロダクト開発プロセスにムダを残すことになってしまいます。

こういった自体を防ぐために、第三者的な目線からチームのプロダクトの開発の様子を俯瞰できる立場は非常に貴重ですです。 これを担えるのはスクラムマスター以外にいません。

スクラムマスターは直接的にプロダクトの生産に関わるロールでないため、生産性がないロールと誤解されがちですが、 スクラムマスターは開発チームの自己組織化を促し、生産性の向上や維持に必要不可欠なロールだと言えます。

急にプロダクトバックログのような成果物の話が出てきて混乱されたかもしれませんが、問題ありません。まだ説明していないのだから当然です！

次にスクラムチームが作成すべき成果物を見てみましょう。 もし気が向いたら成果物やイベントのページを見たあとでこのページを再度読んでみましょう。 新たな発見があるかもしれません。

スクラムにおける成果物