【スクラム開発】Scrum@Scaleで学んだ2つの視点と役割
はじめに
この記事はScrum@Scaleの研修を受けて学んだ２つの視点と役割について書いて見たいと思います。
この２つの視点・役割が非常に重要で、一つはプロダクト視点、もう一つがそのプロダクトをどう作り上げていくか？というプロセス視点。
この2つの役割の連携がどれだけ重要なのか、そしてこれがいわゆるウォーターフォール開発、スクラム開発の違いの根本であることや、組織でもトップダウン、ボトムアップといった命令系統の違い、上司・部下の関係性、上司が考える戦略と戦術の違い、リーダーシップとはなにか？中間管理職がなんで板挟みで苦しんでるのか？みたいな所まで考えが及んで行くのが面白い体験でした。
Scrum Inc主催のScrum@Scale研修を受講してみた
ここ数年スクラムマスターとして活動していて、プロジェクトではスムーズに各チームが自主的に動くようになってとてもいいチームになってきていると思っていましたが、ゆめみという会社はアジャイル組織なため、社内の組織構造がスクラムチックではあるものの、なかなかチーム間の越境が難しく、「会社がスケーリングしてくのはやっぱりハードルがあるな」と感じていました。
そういう課題に悶々として思っていた時に、久しぶりにScrum Incさん主催のScrum@Scaleの研修が開催するというメルマガが来たので速攻応募。あっという間に席も埋まったのですがなんとか受講できたのでここに感想を書いていこうと思います。
Scrum@Scaleとは、ScrumMasterやProductOwnerの研修の上位というか受けた上で受講するという立て付けの研修です。
文字通りチーム人数が増えてきた際にチームをスケールしていく方法の話になります。
ただ思っていたのと少し違ったのはScrum of Scrumsでチームをスケーリングしていく方法を学ぶのかと思っていたのですが、どちらかというと、さらにもう一歩先に進んで組織開発のイメージでした。
そのためもっと視野が広くなり会社全体でどうなのか？という考えに行き着くことができとても有用な研修でした。
ここから特に印象に残った研修内容の一部を紹介していきたいと思います。
視点と役割が２つある(EMS & EAT)
スクラム開発にはプロダクトオーナーとスクラムマスターの役割がありますが、それらと同様にスケールした場合でも２つの役割があります。
１段回スケールしたScrum of Scrums でいうところの、チーフプロダクトオーナーとスクラム オブ スクラムマスターという役割にあたりはするのですが、単純にScrum of Scrums のように上位をさらにまとめるリーダーポジションの人がいるわけではありませんでした。
その2つの役割というのが、EMS(Executive Meta Scrum)とEAT(Executive Action Team)というチームです。（Scrum of ScrumsでもMetaScrumがあるのでその形の上位階層という形）
より参考になる図はこちらから
https://scruminc.jp/scrum-at-scale/guide/
視点も役割もいわゆる、プロダクトオーナーとスクラムマスターという点では同じなのですが、こちらはチームです。
またプロダクトオーナーやスクラムマスターは兼任が禁止されていますが、こちらは兼務が可能です。（全く同じメンバーというわけではなく兼務している人がいてもいいという立て付け）
ようするに会議体で話す時に、どちらの話をしているのかが重要というような形になります。
プロダクト視点とプロセス視点
簡潔にいうと、プロダクトをどう発展させていくかを考えるEMSと、その展望をどう実現させていくかを考えるEATという構造です。
ここだけ見ると単純でPO、SMと同じ役割ですね。
要するに戦略を考えるEMS。そしてどう作っていくか戦術を考えるEATなのですが、プロダクトの理想像を考えていき方針を打ち出していくEMS。
そして、その方針をどう作っていくかのチームのプロセスを考えるEATなのです。
スクラムはプロダクトを作ることができるチームを作るやり方
今まで、プロダクトをどうしていきたいか？ プロダクトをどう開発していくか？というような話は、開発者であればしてきたと思います。
ただ、プロダクトを作れるチームを作る。という視点を持てているでしょうか？実はプロセスに注目するということはこのチームに注目している状態なのです。
ここから先は自分の頭の中で整理した考えなのですが、いわゆるウォーターフォール開発というのはプロダクト視点の開発方法だと思っています。
プロダクトがどういうふうになっていて、どういうふうにしたいからこう作っていく。という流れ。
ある程度のプロセスはもちろん考えますが、プロダクトを作りきることを目的としているためスケジュールに間に合わなければ残業してでも作り切るというチームを疲弊させてでもやりきるといったアプローチをとりがち。
もちろんきれいに回れば、順番通りに 予定通り進んでいけば滞りなく作れるので、各箇所がしっかり効率化されていれば問題ない進め方です。
（ここではやり方を比べるものでもないですし、どちらがよい悪いという話でもないと思うのであくまで例です。きれいに回っていれば何も問題なし）
スクラム開発ではプロダクト視点とプロセス視点の両方が大切なため、プロダクトオーナーというプロダクトを考えているポジションと、スクラムマスターというチームのプロセスを考えている２つの役割があります。
結局プロダクトを作るのは人でありチームであるため、プロダクトを作れるチームを作ることが大切という話になります。
請負と準委任
ちょっと話がそれますが契約形態についてもメモ的に。
ウォーターフォールでは請負で、スクラム開発では準委任での契約になっている場合が多いと思います。
これを改めて考えてみるとしっくりきます。
ウォーターフォールはプロダクトを主にしているため、プロダクトの値段を決めています。そのため請負で「このプロダクトはいくら」という値付けがされ、もし開発の遅れがでても値段は変わりませんし、チームの人数が増えても減っても値段は変わりません。逆に要件が増えた（プロダクトが変わった）のであれば値段が変わります。
スクラム開発ではプロダクトへの値付けではなく、そのプロダクトを作れるチームに対しての値付けがされています。そのため準委任となりそのチームへの支払いになるため、期間やチームメンバー数により値段が変わったりします。
上手にチームのアウトプット（ベロシティ）を上げていけば値段はそのままでよりよいプロダクトを手に入れることができますし、チーム運用が悪いとアウトプットが下がり納期もコストも増大していくためチームがいかに重要かがわかります。
その意味ではチームビルディングが非常に重要で、良いチームはアウトプットが高いですし、残業を繰り返してチームを疲弊させることはなんの意味もないことがわかります。
上記のように何に対しての金額かという視点で考えるととてもわかり易くなると思います。
EMSとEAT
話を戻しまして、このEMSとEATという２つのチームがあります。
兼務してもよいという話もしましたが、プロダクトの例だけでなく会社の経営方針にも使える話だと思うのでそちらの話で例えてみたいと思います。
会社の方針を決めるチームはどこ？と聞かれたらどこを思い浮かべるでしょうか？部長会議と呼ばれていたりするかもしれませんし取締役会かもしれませんね。
色々な場で決定されているとは思うのですが、例えとして取締役会で進めたいと思います。
取締役会で「今季の目標は売上いくらいくらで、成長率は何十％。顧客倍増。経費を削減して利益を確保」というような目標が立てられたとします。
これってようするに会社としての方針を決めてる形にはなりますが、会社をプロダクトと捉えるとまさしくプロダクトオーナーがなにかを成し遂げたい時に紐付けた目標を立てていると考えられます。（本当はなぜその数字を達成したいかというのがあり、数字にひも付きやすいのは株主に向けた成長や利益というものが多そうではありますね。本当はさらに向こうのビジョンなどがそれにあたるはずで、プロダクトとして考えるとエピックだったりストーリーだったり、イニシアチブだったり）
そしてこの目標が各チーム、会社でいえば部だったり課だったりするのでしょうか。ゆめみは特に部や課はないのですが、とにかく経営陣が考えた方針については全社に共有があるため、それら目標を各チームが各々考えて行動していくことになります。
ここで例えば部にその方針が降りてきたとしましょう。
この時にその目標を達成するために色々考えると思います。この時に考えることがプロセス視点になる場合が多いと思うのですが、実は降りてきた目標を分解していて別の小さい目標を立て直したりしているのは、またプロダクトオーナー視点だったりします。（エピックやストーリの分解のイメージ）
中間管理職が大変なのは、この目標とプロセスを両立して考えるため役割が相反するのに検討する必要があるためなんじゃないか？と思うわけです。
なので、降りてきた目標にたいしても、プロダクト視点なのか、プロセス視点なのかを考えるのが重要で、それらは別で進めなければならない。
先程の例でいうと部はEATにあたるか？というと規模が縮小されているためあたらず、別に同規模のEATがあった方がよく、部の方針を決めているチームがあるならば、部のプロセスを決めるチームもあった方がよいと思っています。（部長が集まる部長会議体なるものはEATにあたるかもですね。部単体はあたらない。）
戦略（プロダクトのビジョン）を考えるEMSやプロダクトオーナー、戦術（それをどう実現するかのプロセス）をチームで考えるスクラムマスター、そして、それらを実現していくチーム。
プロダクトの成長を考えるEMS、PO
チームの成長(プロセス改善)を考えるEAT、SM
自律してどんどん成長していく、チーム
この役割を意識していくことが重要で、プロダクトとプロセスを考えるチームは別に必要で、実行していくチームと合わせて１チームと言えます。
よく検討するチームと実行するチームみたいな分け方をしますが、検討するチームも目標やビジョンを考えるチームと、プロセスを考えるチームは更に分けた方がよいということですね。
さらに１人でそれを考えるのは厳しいためEMS・EAT的なチームがあったほうがよく、取締役がEMSであるならば、対となるEATが必要である。
そういうことに気づけた研修でした。
余談
Scrum of Scrumsで各チーム毎のPOとSMとエンジニアの役割
今までScrum of Scrums のチーム形式で開発をしていたのですが、Scrum of Scrums では各チームにPOとSMがいなくてはいけません。(Lessではこの限りではないですが役割や名称が異なるだけで本質は同じかと思っています)
といっても、小さいチームにPOとSMの２名を置くことは難しくエンジニアが担当することになります。SMはまだ奉仕型リーダーという意味ではエンジニアが担当しても問題ないですが、POとなるとプロダクトに精通してる必要がありそうで不在のままチームは進めていました。
ただこの研修を受けてから少し考え方が変わりました。何もエンジニアはプロダクトの将来を考えていないことはない。エンジニアなりのプロダクトの理想的な状態はある。設計だったり将来的な技術的方針だったり。
そういうことを考えるポジションはリードエンジニアだったり、アーキテクト、テックリードと呼ばれるエンジニアがいます。
むしろアーキテクトがプロダクトとしての理想的な設計などを考えPOとしての役割を担い、リードエンジニアがそれをどう実現していくかプロセス視点で考えて実践していけば、POとSMの役割も分かち合えるのではないか？と。
そうすることでリーダーポジションのエンジニア２名体制でプロダクトとチーム両方の視点でよいものが考えられる。
色々しっくりきそうに思っています。
スクラムイベントにも役割がある
更にもう少し考えてみると、各スクラムイベントにも実はプロダクト視点とプロセス視点の両方のイベントがあることに気付きました。
プロダクトのためのイベントか、チームのためのイベントかという違い。
スプリントプラニング（プロダクト視点）
スケールドデイリースクラム（プロダクト視点）
ここがチーム視点もありながら通常のデイリーと違ってややプロダクト視点が強くなる場合もあるためプロダクト視点としてみました。（個人の感想）
デイリースクラム（チーム視点）
スプリントレビュー（プロダクト視点）
レトロスペクティブ（チーム視点）
リファインメント（プロダクト視点）
このような意識付けで各イベントを進行してみるとまた新たな視点が芽生えてとてもよさそうに思っています。
プロセスって非常に重要でチームビルディングに直結しチームのアウトプットに直結していると改めて感じました。
最後に
EMS・EATと難しい呼び名ですが、Meta ScrumとScrum of Scrumsの関係なので単純に発展型ではあるようです。
ただあらためて視点が２つあり、目標とプロセスを分けて考えることが、POとSMの役割分担だと捉えるといろいろしっくり来ました。
研修ではこれ以外にも他のメンバーの巻き込み方など８アクセルと呼ばれるものなど色々ありました。とても参考になったのでまた機会があれば書いてみたいと思います。
この記事が気に入ったらサポートをしてみませんか？