僕がスクラムマスターを辞めたワケ

Adways Advent Calendar 2018 13日目の記事です。

http://blog.engineer.adways.net/entry/advent_calendar_2018


 

こんばんは。 某広告サービスでスクラムマスターを担当していたりょーまです。

今回は先日の記事の予告通り、スクラムマスターを辞めたワケについて書いていきます。

f:id:AdwaysEngineerBlog:20181219110528p:plain


 

理由は三つ

先に答えを書いちゃうと

①スクラムを確立できたから
②後継者ができたから
③良いモノを作りたいから

です。


 

Why Agile ?

まず最初に、そもそもなぜアジャイルなのか?
今年のagile japanのテーマでもありましたね。目的を忘れてはなりません。
で、僕の中では不変な回答があって、それは

価値の高いプロダクトをつくるため

これだけです(去年のブログにも書いてた)

blog.engineer.adways.net


 

理由①:スクラムを確立できたから

スクラムマスターの役割は、スクラムを確立させることです。
この手の定義や理想は色んな人や本がそれこそ色んな事言っているので、自分の中でブレない軸を作ってみました。
確立の理論です。

  • 全メンバーがスクラムを理解している
  • ロールが明確になっている
  • ステークホルダーが明確になっている
  • メンバー間のスキル差が少ない
  • 全メンバーが対等である
  • チームの目的・方向性が一致している
  • タイムボックスを守っている
  • 1チーム1プロダクトである
  • スクラムを深く理解し、ファシリテートできるSMがいる
  • ビジネスに限らず、エンジニアの事を良く理解しているPOがいる

それぞれのために色々なことをやってきたんですが、それを書き出すと年を越しちゃうので割愛します。

チームが主体的にスクラムを回せる状態になった。
これが理由の一つ目。


 

理由②:後継者が出来たから

スクラム確立出来たら、スクラムマスター要らないの?
答えはNOです。
状況によっては要らないかもしれませんが、まだ要ります。って回答のほうが正しいかも。

自己組織化され、自然と改善が回るチームにはなりました。
しかしながら、POはプロダクトの事、開発チームはプログラムの事に優先的に取り組みます。
そんな中チームを俯瞰的に観察・分析し、改善を促進する役割はやはり必要になってきます。

スクラムの失敗あるあるでロールの兼務がよくあります。
見る対象も解決手段も違うので兼務が難しいのは当然なんですよね。

キミに決めた

てことで、後継者を立てました。
彼が新スクラムマスターです。
イイ感じにファシリテートしてくれています

f:id:AdwaysEngineerBlog:20181219133835p:plain

勿論ぽっと出たわけでなく、中長期的にティーチング・コーチングしてきました。
一方的に教えるのではなく、意見をもらったり相談に乗ってもらったりと、教える側にもすごくメリットがあります。
今までありがとう。あとは任せたぜ。
そして、いつか彼も後継者を育ててくれることでしょう。

スクラムマスターを出来る人が増えた。
これが理由の二つ目


 

リーダーは要らない

補足として書いておきたいのが、よくスクラムマスター=リーダーって認識されている事があるのですが、これは少し間違っています。リーダーシップは必要ですが、絶対的なリーダーではないんです。
リーダーの定義をチームを引っ張り、決断する人とします。
スクラム導入初期においてはスクラムマスターが引っ張り、決断することは重要な役割です。
最初はそれこそ何をしていいかわからないですし、最初の一歩を踏み外すとネガティブイメージがつき、嫌になっちゃうので。

しかし、いつまでも意思決定をし続けるのか?これはNOです。

あの人が決めてくれるから、待っていようなチームと
私達はこのように考えるよ、やってみようなチーム

どちらが優れた成果を残せると思いますか?

スクラムにおいては意思決定をするのはチームであるべきです。
(当初から「俺はリーダーじゃないよ」って言い続けていました。まあ、自分の場合はそもそも何でもかんでも決められるスキルを持ち合わせていませんが笑)


 

理由その③:良いモノを作りたいから

チームは良好、後継者もできた。
これだけでも十分スクラムマスターをやめる理由にはなったのですが・・・

原点に戻りましょう。
我々がアジャイルをやる理由は
価値の高いプロダクトを作る事です。
では、価値の高いプロダクトってなんだろう?
そもそも価値って?
使えるモノ?楽しいこと?
誰が価値と判断する?

何かが足りない。

的なことをぼんやりと考え始めたのが約一年前。
本気で考え出したのが半年前。

どうやらこういう事を考えるのをサービスデザインとかUXデザインというらしい。

これに集中したい。
これが理由の三つ目。


 

スクラムだけで良いモノを作れるのか?

これはあくまでも個人的な解釈ですがYESよりのNOであります笑。

スクラムには大きく4つ(+α)のイベントが用意されています。

  • スプリントプランニング
  • (バックログリファインメント)
  • デイリースクラム(毎日)
  • スプリントレビュー
  • スプリント振り返り

これらを一サイクルとして延々と繰り返すのですが、、ここで問題となるのがプランニングです。
正しい計画の立て方ではあるのですが、それが良いモノ(コト)であるかということはすっ飛ばしており、POあとよろです。

カレーが嫌いな人に、美味しいカレーを届けても意味がありません。
料理をしない人に、キッチンが綺麗な家を作っても意味がありません。

スクラムはそれと決めたモノを正しく作り、また早く気づく事には得意なのですが、それが本当に良いモノであるのか?という問いにはあまりフォーカスしていないです。


 

サービスデザインとの出会い

ということで、良いモノを作るためにどうすればと勉強していたら自然と以下のようなツールに行き着きました。

  • ユーザーインタビュー
  • ユーザーストーリーマッピング
  • ペルソナ分析
  • ステークホルダーマップ
  • カスタマージャーニーマップ
  • ビジネスモデルキャンバス(リーンキャンバス)

これらを総じてサービスデザインとかUXデザインというらしい(まだ細かい定義を説明できるレベルにいないです)。

良いモノ(コト)を考え、検証するためのツールですね。
勿論、今まで全くやっていなかったかというとそんなことはないのですが、ある特定人物に依存していたり、考えてはいるけど透明化されていなかったりといった問題がありました。

そこで、私はこれらを銘打って推進し、チームとして体系化しようと動いている訳であります。

本当に初めてのユーザーストーリーマッピング

f:id:AdwaysEngineerBlog:20181219134012p:plain


 

アジャイルとサービス(UX)デザイン

幸いな事に、アジャイルとサービスデザイン(UXデザイン)は非常に相性が良いです。

いくらサービスデザインを丁寧にやったところで、作ってみない事には良いモノかは絶対に分かりません。
いくら高速に正しく作ってみても、良いサービスでないと売れません。

アジャイルとサービスデザインは互いの問題解決に相互的なのです。

もっと砕いて言えば

サ:良いモノを考える→ア:とりあえずちゃんと作ってみる→ア:だめだやり直そう→サ:もっといいモノを考える→繰り返し

といった具合にサイクル化できます。
うん、仲良し。

これからの開発

サービスデザインで良いモノを考え
スクラムで早く正しく作る

そんな高生産的なチームを目指しています。

気をつけないといけない事は、目的を忘れない事。
価値の高いプロダクトを作る
そのためのなんちゃらマッピングだよという事。


 

最後に

という事で、スクラムマスターを無事卒業したので、
サービスデザインの推進・確立を図ってまいります。

スクラムで良いチームワークが築けたためか、非常にチャレンジしやすい事に幸せを感じています笑

私はスクラムマスター経験者ということもあり、マネジメントやチームビルディングが得意です。
その強みを生かし、サービスをデザインするという事をチームとして出来るように動いていきます。

次回は実際に行った事や成果を具体的に書けたらいいですね!

それでは引き続きAdwaysのアドベントカレンダーをお楽しみください!


 
次は佐土原さんの記事です。

http://blog.engineer.adways.net/entry/advent_calendar_2018/14