こちらは「Service Designer's Advent Calendar 2018」の、1日目の記事です。
こんにちは！クラウドワークスのデザイナー、田村（@tamusan100）と申します。
この度、Service Designer's Advent Calendar 2018 というタイトルで、アドベントカレンダーを始めることになりました。
Service Designer's Advent Calendar 2018 では、デザインブログを運営している事業会社6社が集結。
各社のデザイナーたちが、プロダクト、UI 、ブランド、組織など、さまざまなテーマについて、毎日記事を公開していきます。
- BIZREACH Designer Blog / BIZREACH
- CrowdWorks Designer Blog / CrowdWorks
- DeNA DESIGN BLOG / DeNA
- eureka.design / eureka
- Mercari Design / Mercari
- ChatWork Creator's Note / ChatWork
というわけで、わたしが1日目。なんだか緊張しますね。笑
アドベントカレンダーといえば、12月に始まるということもあり、まずはこの1年を振り返ってみたいと思います。
1年前...。デザイナーの人数も少なく、開発チームの中に、やっとデザイナーが本格的に入り始めた頃だったと思います。懐かしい。
クラウドワークスでは、その頃から既に、スクラムをベースにしたチーム開発が行われていました。
しかし、当時のわたしは、スクラムについて何も知らない状態でした。
そんな中、開発チームに入ってからの1年で、いくつも失敗をしてきました。
せっかくの年末ですし、この失敗をブログに書いて、少しでも誰かのお役に立てたらと思います。
というわけで、今回は「デザイナーのわたしが、1年間スクラムを経験して失敗してきた3つのこと」をお送りします。
1. プランニングを分けて実施したこと
1つ目の失敗は、プランニングを分けて実施したことです。
起こったこと
開発チームに入ったばかりの頃、初めてスプリントのプランニングに参加したときのことを覚えています。
当時は、POやエンジニアが実装について話していることが理解できず、出席しても仕方がないように思えました。
見積もりのためタスクにポイントを付ける際にも、デザインタスクと実装タスクで中身が違いすぎたので、お互いにどうすればいいか分からない状態でした。
そのため、「別々に実施した方がスムーズではないですか？」と提案し、「PO・デザインプランニング」と「開発プランニング」を分けることにしました。
しかし、この判断は裏目に出てしまいました。
例えば、開発プランニングの際にモックアップを見て、エンジニアがあらためてデザイナーの意図を確認したい場合があります。
その際、わたしがその場にいなかったため、開発プランニングのネックになってしまうことが何度かありました。
改善したこと
そこで、プランニングは、やはり1つに統合しました。
1つに統合してからは、エンジニアからチームに提案があり、見積もりにプランニングポーカーを使い始めました。
これは、前述した「お互いのタスクがよく分からない」という問題を解決するのに、とても役に立ちました。
開発チームに入ったばかりの頃、タスクにポイントをつけると聞いて、随分と混乱したものです。
例えば、UIデザインのモックアップを作る前に、ラフスケッチを書くというタスクがあったとします。
わたしは「ラフ案がいくつ出るかも分からないのに、それにポイントを付けるなんて意味が分からない。」と思っていました。
この手法は、エンジニアの実装タスクでは有効でも、デザインタスクに流用することは難しいとも思っていました。
当時は、タスクにポイントを付ける目的や意義を、あまり理解していなかったのです。
不確実性が高い中でも、チームでの対話を通し経験に基づいて見積もりを行うことで、プロジェクトの見通しは立てやすくなります。
経験に基づいて行うのであれば、POのタスクでも、デザイナーのタスクでも、何でもポイントを付けることができるのです。
今では、全てのタスクに対して、全員でプランニングポーカーを使ってポイントを付けています。
面白いもので、最初はお互いばらばらに付けていたポイントが、今では波長が合うようになりました。
このようにして、開発チームの見積もり精度は上がっていくのだと実感しました。
2. タスクボードを分けて管理したこと
2つ目の失敗は、タスクボードを分けて管理したことです。
起こったこと
クラウドワークスの開発チームでは、タスク管理にカンバン方式を採用しており、ツールは主にTrelloを利用しています。
前述したプランニングのときと同様、当初はTrelloに追加されていく実装タスクの意味が、ほとんど分かりませんでした。
エンジニアとPOも、わたしが追加するデザインタスクの意味に、ピンときていなかったようです。
そのため、「一緒に管理してもよく分からない感じになるし、別々にしませんか？」と、タスクボードを分けさせてもらいました。
ですが、これもまた、裏目に出てしまいました。
確かに、実装タスクとそうでないタスクを分けたことで、ボードはある程度シンプルになりました。
しかし、全体として、何がどこまで進んでいるのかが分かりづらくなったのです。
また、実装フェーズでエンジニアから得られたフィードバックを、素早くデザインの追加検討タスクとして反映しづらくなりました。
気付かぬうちに、アジャイルではない、硬直的なプロセスになっていたのです。
改善したこと
そこで、分けていたタスクボードも、やはり1つに集約しました。
本来であれば、同じゴールから逆算して動いているのですから、タスクボードを分ける必要もありませんでした。
今では、実装タスクも、デザインタスクも、POタスクも、何でもTrelloに突っ込んで管理しています。
全体の状況も分かりやすくなりましたし、分からないタスクの内容があれば、相互に質問し合うようにしています。
例えば、デザインタスクだと、ラフ案とは何をどこまで作るのか。モックアップはどこまで詳細に作り込むのか。何を持って完了とするのか。
このように、1つのタスクに対して、アウトプットイメージとゴールを共有するようにしています。
わたしもまた、実装タスクやPOタスクについて、何をやるのか理解できるまで教えてもらうようにしています。
3. デザインと実装で別々に動きすぎていたこと
3つ目の失敗は、デザインと実装で別々に動きすぎていたことです。
起こったこと
ちょうど1年前くらいから、デザイナーが主導していた定性調査のプロセスに、エンジニアやPOも加わるようになりました。
当時から、これまで別々に動いていたデザイナーが、開発チームに融合してきたと言われ始めていました。
しかし、今振り返ると、それはあくまでも表面的な話でしかなかったと思います。
開発チームに入ってしばらくの間は、わたしは実装のプロセスについては触れず、POやエンジニアも、デザインのプロセスにはあまり触れない状態でした。
そのため、わたしの場合、既存の実装の状態と整合性のないアウトプットをして、エンジニアに迷惑をかけてしまうことがありました。
その一方で、わたしはPOやエンジニアに対して、定性調査にもっと積極的に参加してほしいと思っていました。
開発だけではなく、ユーザーが本当に求めているものは何かということに、もっとこだわってほしかったのです。
改善したこと
この問題についても、ふりかえりを通して、今後は積極的にお互いのプロセスにも参加していこうと決意しました。
わたしの場合、実際にフロントコーディングのプロセスに参加することで、学びを得ることができました。
例えば、1pxのレイアウト調整や色を変えるだけでも、場合によっては難しこともあるのだと身をもって実感しました。
POやエンジニアも、定性調査を始めとするデザインのプロセスに、積極的に参加してくれるようになりました。
元々、フロントコーディングにも挑戦する旨を伝える際、表向きには「興味があるのでやってみたい。」とだけ言っていました。
しかし、本心では、デザイナーから専門外のプロセスに踏み込むことで、代わりにPOやエンジニアからのコミットメントを引き出す算段でもありました。
このように、まずは自分から小さな取り組みを始めることも、ひとつの有効な手段だと思います。
スクラムにおける、デザイナーの立ち位置
以上、3つの失敗についてお送りました。
ところで、スクラムをベースとしたチームにおいて、デザイナーはどう振る舞うべきなのでしょう。
世間でも、あまり多くは語られていませんよね。
例えば、POはプロダクトバックログを作成し、開発メンバーはプロダクトの実装を行い、スクラムマスターはプロセスを支援すると言われています。
このとき、デザイナーはどこに分類されるのでしょう。
POでしょうか？ それとも開発メンバー？ あまりしっくり来ないですよね。
クラウドワークスの場合、デザイナーは定性調査を元にユーザーの体験を可視化し、POと共にプロダクトバックログ作成の前段階をリードすることがあります。
また、実装の前段階としてプロトタイプを作成し、開発メンバーと共にマークアップやスタイリングまで踏み込むこともあります。
どうも、既存のスクラムの枠組みに、そのまま当てはめることが難しく思えるのです。
わたしは、クラウドワークスに転職して、初めてスクラムというものに触れました。
その時、手始めに何冊かの本を読んで調べたことがあります。
しかし、アジャイル開発やスクラムの話の中で、デザイナーはあまり登場しません。
以前に社内でも流行した「カイゼン・ジャーニー」や「エンジニアリング組織論への招待」を読んでみても、主要な登場人物としては、やはりデザイナーは出てきませんでした。
（「カイゼン・ジャーニー」では、「クライアントが連れてきたデザイン制作会社のデザイナー」の音無さんという方が後半から登場し、デザイナーとの協働についても触れられています。）
スクラムにおけるデザイナーの立ち位置とは、むしろ今日の現場で働くわたしたちが、これから作っていくものかもしれませんね。
おわりに
最後までお読みくださり、ありがとうございました。
「Service Designer's Advent Calendar 2018」は、25日まで、毎日ノンストップで更新されます。
明日は、DeNAさんの更新です。どうぞお楽しみに！