Tortoise Shell

Webサービスの会社で働くデザイナーが、デザインやライフハックについてゆるく書き連ねるブログです。

市谷聡啓さんの「正しいものを正しくつくる」から考える、スクラムにおけるデザイナーの立ち位置

今の会社に転職して、スクラムチームの中で、デザイナーも動くようになった。

かれこれ2年くらい経ったけれど、ずっとモヤモヤしていたのが、スクラムにおけるデザイナーの立ち位置だった。

わたしの観測範囲の中では、スクラムに関する本を読む限り、デザイナーは登場人物としてほとんど登場しないからだ。

去年、会社の中で流行った「カイゼン・ジャーニー」の中でさえ、デザイナーは外部メンバーとしか登場しなかった。

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

 

ひょっとすると、そもそもスクラムの中で並走するようなデザイナーは、動き方として珍しいのかもしれない。

デザイナーは、デイリースクラムやふりかえりといったスクラムイベントに参加すべきなのだろうか。

ユーザーインタビューやカスタマージャーニー作成など、いわゆる「プロダクトバックログ」以前のプロセスを、どうやって組み込めばよいのだろうか。

結局のところ、答えは自分で見つけるしかないのだろう。そう思っていた矢先、同じ著者による「正しいものを正しくつくる」という本が出版された。

正しいものを正しくつくる プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について
 

この本の優れたところは、正しいものを定義するフェーズと、正しくものをつくるプロセスを2つに分けたところだ。

従来のスクラム本では、プロダクトバックログの存在を前提として、それを元にスプリントを回していくプロセスに焦点が当たっていたように思う。

そのため「そもそも何を作るのか」という前提部分は、曖昧なままだった。

POがプロダクトバックログを管理するとあるが、そのプロダクトバックログはどこから出てきたものなのか、ということだ。

つまり、正しいものを定義するフェーズについては、スポットが当たっていなかったのだ。

正しいものを定義するフェーズでは、ユーザーインタビューやカスタマージャーニーなど、いわゆるデザイナーがUXデザインプロセスと呼ぶ工程が登場する。

ここで、UXデザインのプロセスと、スクラムのプロセスが噛み合うわけだ。

しかしながら、この記事のタイトルである「スクラムにおけるデザイナーの立ち位置」については、わたしは著者とは意見が異なるようだ。

スクラムでは、「プロダクトオーナー」「開発チーム」「スクラムマスター」という3ロールが定義されているが、この本ではデザイナーを開発チームの一員としている。

なんとなく、従来のスクラムのプロセスを中心に、デザイナーの位置づけを定義したかのように見えてしまう。

しかし、わたしの思うデザイナーの立ち位置は、上記の3ロールに続く「第4のロール」である。

なぜかというと、わたしのスクラムチーム内での動きは、必ずしも従来の3ロールに含められるものではないからだ。

あるときは、POの相棒として、UXデザインプロセスを駆使しながらプロダクトバックログ作成を一緒に行う。

またあるときは、開発チームの一員として、フロントのコーディング等のプロセスにも参加する。

このように、わたしの動きとしては、正しいものを定義するフェーズと、正しくものをつくるフェーズの両方にコミットしていることになる。

では、なぜ著者はデザイナーを開発チームの一員として位置付けたのかというと、本の内容を読み進めて合点がいった。

スクラムチームにおいて、POはチームのROI最大化に責任を持つロールであり、従来であれば「何をつくるのか」はPOが決めるべきことだからだ。

POが、ユーザーインタビュー等の定性調査もすべて行い、プロダクトバックログを作成し、デザイナーは要件に沿ってデザインするだけなのであれば、確かに開発チームとして位置付けても不思議ではない。

ただし、さらに読み進めると分かるのだが、定性調査もデザインも分かっているスーパーPOなんて多いはずがない。

そのため、POの権限移譲といった形で、実際はチームの中で、POのいくつかの役割を分担することになる。

わたしの動きなどは、まさしくその通りで、この本の中では「本来POがやるべきこと」と定義しているというわけだ。

つまるところ、スクラムにおけるデザイナーの立ち位置について、やはり答えは自分で出さなければならないということだろう。

実際にわたしの周りでも、どこまでがデザイナーの仕事なのかモヤモヤしている、という人を目にしたことがある。POも同様かもしれない。

スクラムチームの中で、お互いが気持ちよく仕事をするためには、初期のチームビルディングを通してお互いへの期待をすり合わせておくことが重要だろう。

わたしだって、例えば「デザイナーはバックエンドのコーディングの理解できて当たり前」という認識を持ったチームに放り込まれれば、ちょっと待ってほしいと言うだろう。

あるいは、これまでデザイナーがかかわった経験のないチームで、デザインもエンジニアが適当にスタイル調整するという場合であれば、逆にこちらから切り込んでいかなければならない。

これをやればOK、こんなチームビルディングのワークショップをやればよいという表面上の問題ではなく、お互いに相互理解を大切にする気持ちが重要である。

スクラムにおけるデザイナーの立ち位置について、かつてのわたしと同じようにモヤモヤしている方がいらっしゃれば、ぜひとも上記の本を読んではいかがだろうか。

もちろん、本に書いてあったからその通りにするのではなく、わたしと同じように自分の状況と照らし合わせて考えてみてほしい。