最初にアジャイル開発に加わった際に行った3つのアクション
樋田氏は、制作会社でのデザイナー勤務を経て2016年にサイボウズに入社。現在は、業務改善プラットフォーム「kintone」の開発にデザイナーとして携わる。kintoneとは、業務で必要なシステムを、ドラッグアンドドロップなどの直感的な操作によって、ユーザー自身が簡単に作ることのできるクラウドサービス。通常のシステム開発に必要なプログラミングは不要だ。
樋田氏のデザイナー歴はおよそ10年。「デザインのプロセスは、かつて想像していたものから大きく変わってきている」と振り返る。
「以前の私が考えていた“求められる”デザイナー像というのは、高いスキルや斬新なアイディアを持った“スーパーデザイナー”。そのため、とにかくまずは高いデザインスキルを身に着けようと考えていました。しかし2016年にサイボウズに入社し、kintone開発チームにジョインしてから考えかたがガラっと変わった。kintoneはプロダクトの規模が大きいですし、画面の数も多く、仕様も複雑です。デザイナーがひとりで全体像を把握することは難しいと気づきました」
kintoneの開発チームには、エンジニアやライター、プロダクトマネージャー（以下、PM）など含め、40人を超えるメンバーが関わっている。そのためデザイナーも、多様な役割をもつメンバーとともに、プロジェクトを進めていかなければならない。
「私がkintone開発チームに携わりはじめた当時、チーム専任のデザイナーは不在。そんな中でスクラム開発が始まったのですが、それまでの開発プロセスでは、PMが考えた企画をもとに開発チームが製品を開発し、デザイナーは『ここのデザインを調整してほしい』など、最後に少し関わる程度でした。そういったプロセスでは、たとえとても高いスキルを持ったスーパーデザイナーがひとり現れたとしても、その価値はユーザーには伝わらないのではないかと思いました」
こうした背景を踏まえ樋田氏は「まずはデザイナーとしてプロセスに参加していくこと」が重要だと判断。具体的に3つのアクションをとったという。そのひとつが「未完成のデザインを共有する」ということだ。
「これまで自分が経験してきたウォーターフォール型の開発では、デザインのフェーズがしっかりと決まっていたこともあり、あまり横やりを入れられたくないという思いなどから、未完成のデザインを見せることは一般的ではありませんでした。ですが、kintoneのような複雑なプラットフォームを多くの人と関わりながら開発する、という状況では、デザインしているものを隠すことはあまり意味がない。それよりも、早く公開して早くフィードバックをもらいながらデザインを進めていくほうが間違いが少ないだろうと思い、私の制作プロセスをオープンにし、作っているものをどんどん公開するようにしました」
ふたつめは、プロトタイプの作成。
アジャイルのプロセスでは、ウォーターフォール型で制作していた緻密なデザインカンプではなく、粗くてもいま考えているアイディアをチームのメンバーと検証できるものが求められている――。そう感じた樋田氏は、それを可視化するために、さまざまな粒度でプロトタイプを作り、提示することを徹底した。
最後は「一緒に考える」ということ。kintoneのような複雑なプロダクト開発では、デザイナーひとりで案件の全容を把握することは難しい。また、スピード感のあるアジャイル型のプロセスでは、デザイナーがひとりで判断をしていると間違った方向に走ってしまうリスクがある、と樋田氏は指摘する。
現在も、デザインを作っている途中で、プロダクトマネージャーの机に走っていき、その場でエンジニアも巻き込みながらデザインの調整をしていくということは日常茶飯事だという。
こうした活動を続けていくうちに、樋田氏はチームに変化が生まれたことを感じる。
「次第にデザイナーという存在が、『最後に画面をきれいにしてくれる人』から、『上流から検討を支援してくれる人』へと変わっていったんです」
検討プロセスにデザイナーが入りプロトタイプを活用することで、PMが考えるバックログをより洗練させることが可能になった。そのため、バックログの正確なイメージをエンジニアに渡すことができるようになったのだ。
ボトルネックはデザイナーとエンジニアの間にあった
kintoneチームがスクラム開発を始めたのは、およそ3年半前。最初はなかなか上手くいかなかったものの、スクラム開発のプロセスが洗練されることで、プロダクトの開発サイクル（スプリント）は3週間から1週間に、リリースは3ヵ月に1度から1ヵ月に1度へと頻度が高まった。結果的にアップデートの数も年に5件から13件へと増加した。
そのように成果が上がった一方、デザイナーと開発チームのコミュニケーションがボトルネックになっていることも判明した。
アジャイルのプロセスでは、デザインが完成しても検討漏れが見つかったり、デザイナーが追加の修正を施すといったことが頻繁に起こる。サイボウズではこういった課題を解決するべく「モブプログラミング」を利用した。
モブプログラミングとは、コーディングをする「ドライバー」を、複数の「ナビゲーター」が囲んで開発をするという手法。もともとは、コードレビューの時間短縮や経験の浅いメンバーののサポートのためにエンジニアが導入したものだったが、樋田氏らは、スクラム開発のボトルネックを解消するべく、モブプログラミングにデザイナーを加えたのだ。
「これによって、『完成したデザインをエンジニアに引き継ぐ』のではなく、『モブプロで一緒に作ろう』というように、デザインを完成させず、スプリントの中で一緒に作っていくスタイルに変わりました」
このようにエンジニアの手法のなかにデザイナーも入っていくことで、エンジニアからのフィードバックを素早くデザインに反映し、デザイナーの意図やコンセプトなどをディスカッションすることで、エンジニアもより良いコードがかけるようになった、と樋田氏は話す。表現を変えれば、バックログを作る過程にのみならず、エンジニアとUIを実装するといった開発プロセスのすべてにデザイナーが関わるようになったわけだ。
その結果、2019年にkintoneのモバイル版を大幅にリニューアルしたタイミングでは、開発後にエンジニアからデザイナーを評価する意見があがったのだという。社内のkintoneにこんな発言が書き込まれた。
そんなエンジニアからの感想を聞き、「デザイナーはチームに欠かせない存在になったんだなと強く実感しました」と樋田氏は振り返る。
「10年後も生き残るデザイナー」とは
樋田氏は、デザイナーがチームで活躍するためには、次の3つのポイントを認識しておくことが重要だと講演をまとめる。
ひとつはデザインする対象がどんどん複雑化しているということ。デザイナーがひとりで完結できる業務は少なくなっているとし、それを自覚した上で「孤高のスペシャリストからチームに貢献できるデザイナー」へ変わらなくてはいけないと指摘する。
ふたつめは、アジャイル型の開発プロセスによって、デザインは常に未完成になった、ということだ。これにより、そのデザインが正しいかどうかは、製品やサービスをリリースしてみないとわからないという状況になるため、常に変化しながら進めていくことが求められる。その際に、さまざまな職種のメンバーと協力しながら柔軟に対応することはもちろん必須だ。
最後に樋田氏があげたのは、「デザイナーがプロダクトマネージャーやエンジニアなどの職種の境界が曖昧になってきている」という点。デザイナーがモブプログラミングでエンジニアと一緒にコードを書く、エンジニアがデザインをする、といった動きが増えている中で大切なのは、「デザインの領域を明確にする」のではなく「境界を超えていく、または壊していくこと」だと樋田氏。
これらをふまえ、チームにとって不可欠なデザイナーを次のように定義し、セッションを締めくくった。
「必要とされるデザイナーになるために大切なのは、『チームのために変わることができるかどうか』だと思っています。10年後どうなっているかはまだ自分にはわかりませんが、私が10年後もチームにとって欠かせない存在になっているとすれば、それはチームのために変化できているということ。それを続けられるデザイナーが、チームにとって必要な存在なのではないでしょうか」
