こんにちは。サイボウズの樋田です。前回はスクラムに参加することのメリットをお話しました。
今回はスクラムのプロセスと伝統的なウォータフォールのプロセスがどう違うのかを比較しながら、実際にスクラムのプロセスでデザインをするためのコツをご紹介していきたいと思います。
スクラムはデザインが完成しない
私が感じているウォーターフォールとスクラムのプロセスでの大きな違いは「デザインが完成しない」ということです。
ウォーターフォールのプロセスでは明確な締め切りがあり、締め切りに向かってデザインは完成へと進んでいきます。締め切りまでに「完成したデザイン」を次の工程へ渡すことで、デザイナーの仕事は終わりです。
では一方、スクラムのようなプロセスではどこまでデザインを作れば完成となるのでしょうか？
そう考えてみると、実はスクラムのプロセスでのデザインには完成がありません。短いスプリントを繰り返すプロセスでは、デザインが常にアップデートされていくので、完成したデザインという状態がそもそも存在しないのです。
kintone開発チームがスクラムを始めた当初はまだウォーターフォール的な名残が残っており、1スプリントも非常に長く、1つひとつのバックログが巨大でした。
デザイナーも「デザインが完成しない」という状態にまだ慣れていなかったため、バックログと同じように、制作するプロトタイプやデザインも大きくなってしまい、アジャイルのプロセスというよりは「ミニ・ウォータフォール」というのが実情に近いような状態でした。
しかしやがてチームがスクラムのやりかたへの習熟度が増してくるとスプリント期間は短くなり、1つひとつのバックログは軽くなりました。デザインもそれに合わせて小さくなり、製品の状況やフィードバックに合わせて柔軟にアップデートを繰り返す「完成しないデザイン」になりました。
完成しないデザインをどう作っていくのか
スクラムに参加しようとしたデザイナーが「1スプリントが短すぎる！」と感じる一因は「完成」させるプロセスに慣れている、からではないでしょうか。自身もかつてそうだったのですが、デザインを完成させることに慣れたデザイナーにとって、完成させることができない状態には、非常に違和感があると思います。
その違和感を持ったまま、短いスプリントの中でこれまでと同じようにデザインを完成させようとしているが故に、スプリント期間内でデザインが終わらない！となってしまうように思います。
スクラムでのデザインプロセスが一直線に進んでいくことは非常に稀です。いくつものアイディアを検証しながらさまざまなフィードバックを得て、その都度学習しながら進んでは戻るを繰り返す、というように、非常に曲がりくねったプロセスをたどるのがスクラムです。
そんなスクラムのプロセスでデザインをするためのコツ。それは、これまでの「完成したデザイン」というアウトプットを一度すべて捨ててしまうことです。
デザインにおけるアウトプットにはさまざまなものがありますが、スラクムでは特定の締め切りまでに必ず用意しないといけない単一のアウトプットはありません。kintone開発チームではデザインにおけるアウトプットをすべて「プロトタイプ」と呼んでいます。
プロトタイプはバックログの検討、テストやヒアリングなどのリサーチ、開発チームに何を作るべきかを伝えるためなど、主な用途はコミュニケーションの手段です。
プロトタイプは完成を目指して丹念に作り上げていく成果物ではなく、プロトタイプを通じて検討のプロセスをうまく回し、バックログ=ユーザーにとっての価値を磨いていくためのツールのようなものだと捉えています。
また、このプロトタイプはデザインデータのレイヤーを整理してきれいにすることもありません。コミュニケーションのためのアウトプットに完璧なデザインデータを用意することは、あまり意味がないからです。こうして作り込みをせず、柔軟にスクラムのプロセスに合わせたプロトタイプを作っていきます。（もちろんデザイン作業の効率化のためのデザインテンプレートの整備は定期的に行っています）
きちんとしたデザインデータを作らないなら、最終的なデザインのフィニッシュはどうするのでしょうか？ kintone開発チームでは「エンジニアと一緒に作る」という選択をしました。
2018年あたりから、kintoneチームではモブプログラミングを導入しています。ひとりのドライバー（操作する人）に対し複数のナビゲーター（指示を出す人）がついて、みんなでひとつのソースコードを書いていくスタイルです。
デザイナーもそのモブプログラミングに参加し、一緒にUIを実装しています。これにより、デザインについての手戻りもなくなり、実装側の状況を考慮したより良いデザインができることが多くなりました。
以前はデザインデータを細かく作りこんで、ZeplinやInVisionなどのサービスを通してデザインの仕様を渡していたのですが、結局それを読み解くのに時間がかかったり、読み間違えたら手戻りになるということも少なくありませんでした。実装を始めてから気づくトラブルなど、予測できないことはいつでも起きるため、そうした運用はやめることにしました。
