![見出し画像](https://assets.st-note.com/production/uploads/images/31917032/rectangle_large_type_2_08a4c3ad229907c571ef0a29206fa5dc.png?width=1200)
チームで臨むサービスデザイン〜ペアデザイニングのすすめ
弁護士ドットコムでデザイナーをしているぴーや(@taka_piya)です。
入社以来「弁護士ドットコム 業務システム(gyosys)」の開発に携わっており、体験設計、UIデザイン、フロントエンド開発の部分を主に担当しています。
🎉 祝! リリース! 🎉
先日プレスリリースも発表され、ようやくこのシステムも使って頂くスタート地点に立ちました
👇これまでの経緯はこちら
チームではコミュニケーションを取ることを大切に活動しています。
今回は取り組みの1つである「ペアデザイン」とそのポイント、メリットを紹介します。
取り入れた当初は「個別開発のほうが効率的では」と考えていましたが、始めて3ヶ月経った今、チーム全体で開発スピードがかなり上がってきたと認識しています💪
導入の背景 - 急拡大したチーム
コロナ禍での人数の倍増
業務システムのチームは6人です。ビジネス2、エンジニア2、デザイナー2人で構成されています。
去年までは3人で活動していましたが、今年2月に2人、3月に1人メンバーがジョインし、今のチーム体制に。
同時にコロナによる影響で全社でリモートワークが導入された結果、新規のメンバーはオンボーディングもほとんどされないまま(現実で対面したのは今でも2,3回しか無い...)、オンラインでのやり取りだけで開発がスタート。
小さな機能改善が1ヶ月リリースされない
リモートワークの開始当初はいままでの貯金として仕掛品があったので順調に進んでいましたが、6人になって2ヶ月たった4月末。
小さな機能の改善施策が、手戻りや齟齬が多く発生し1ヶ月以上かかってしまう事件(!)が発生。これはやばいねとリリース後に振り返ることに。
新規サービスの検証段階では、シンプルに作り、使ってもらってフィードバックを得るループを回すことが重要です。
しかし、リリースできなくても来週...また来週...とリリースに結び付けなければという目標達成への熱が確保出来なかったこと、チームとって今の最重要課題はなにか共通認識がなかったこと、それぞれが大切だと思う事で活動してしまっていたことを反省し、コミュニケーションの大切さを痛感しました。
👆振り返りのmiro
ペアプログラミングならぬ、ペアデザインの導入
先立って状況を改善すべくフロントエンドの開発において、デザイナーとエンジニアでペアプログラミング(ペアプロ)の導入していました。ペアプロをやってみて良さそうな感触を得ていたので、、デザイナー間での作業もペアでやることに。
ペアデザインのやり方
長くなりました。 意気揚々とペアデザをやろう!といきなり始めたのですが、当然最初上手く行かず、探り探り進めてきました。結果、現在のgyosysのペアデザインのやり方は以下に落ち着いています。
1️⃣ 課題の終了条件を決める(チーム全員)
ペアデザに限らず大切ですが、上記の課題から、チーム全員でチケットの終了条件を決めることをしています。現在チームではリファインメントの時に、チケットに書くことでアウトプットのズレを防ぎます。
👆チケットはこんな風に切っています
2️⃣ 進め方を認識合わせしておく(ペア)
終了条件に達するまでに何を、何のためにする必要があるのか大体のあたりをつけておきます。
デザインプロセスは直線的ではない前提で、大まかなデザインプロセスを合意しておくことで、方向性の大きなブレをなくすことを目的に「このチケットはどのように進めていこうか?」と会話しましょう。
👆gyosysデザインチームの基本的なデザインプロセスはこんな風に
3️⃣ スケジュールとタスクを決める(ペア)
ペアなので、スケジュールを取っておきます(チームは大体前日夜に、明日の朝○時スタートで〜と決めときますが、私用とかでずれることもままあります)。
当日作業を始める時に「何から始めましょうか...」とならないように、予めやることの認識を揃えてから作業を始めます。
4️⃣ ペアで課題に取り組む
そして実作業を行います。
ペアプロでは、ナビゲータ・ドライバーに分かれるパターンが多いですが、ペアデザではお互いが手を動かします。ある考えについて説明しながらmiroを動かし(具体化)、そういうことならば〜(抽象化)...とmiroで書いたオブジェクトをコピーして更に手を加える(具体化)...ピンポン法を取っています。
ポイントは発話しながら作業することです。一足飛びに答えを出すのが難しい問題もあると思いますが、分かっているところから言葉にしてやり取りすると、解像度が高くなっていきます。
5️⃣次の作業計画を立てる
終了条件を達成orペアデザの作業時間が終了したら、次の作業計画を立て4️⃣に戻ります。
日によって1〜4回(つまり1日max4時間)くらい行います。
お互いがお互いを承認できる環境を創ること
ペアプロは「2人で1つのマシンを使って本番用のコードを書くこと」ですが、つまり「2人でコミュニケーションを取り、アウトプットがみえて、アウトプットに対してお互いが承認できる環境を創る」ことが大事です。
リモートでもその環境づくりが肝になります。
現在チームではmiroとfigma、ボイスチャットツールのdiscordを合わせて使っています。声で会話しながら、マウスで指差してこの辺が...というのがいい感じに出来ていいです。
💬MTG、アイデア出し、設計(ワイヤーフレーム)の時
→Miro(議事録、可視化)
→Discord(ボイスチャット)
miroで内容を可視化しながらdiscordで会話します。miro上には自分・相手のカーソルがどこにあり何を選択しているのか表示されるので、相手が何に注目して話をしているのかわかります。
figmaではなくmiroを使う理由は、ふせん、基本図形、矢印、テキストと表現が固定されているため必要以上の書き込みをしなくなるからです(ノートでワイヤー書く時に太いペンを使うのと同じ)
👆会話しながらmiroを使うとこんな感じ
💻フロントのコーディングのとき
→VSCode + LiveShare(コード共有)
→Discord(ボイスチャット+画面共有)
これはいわゆるペアプロですが、デザイナー同士でやることもあるので念の為。
必要なのはコードと動いているものと会話環境です。
VSCodeのLiveShareで書いているコードを共有しながらdiscordで会話します。Live ShareのShared serversやShared terminalを使って環境も共有し同じものを見るようにします。
ペアデザのメリット
1. アウトプットが出来上がるタイミングが早い
2人ともデザインを考えるようになるレビューという形では、良いアイデアを見つけることがありますが、その発見はそのタイミングは大体遅いです。
その点フィードバックループが小さく早く回せるので、最終的にはアウトプットされるタイミングは早くなりました。
2. アイデアに別角度のから意味が与えられる
自分の中で「なんか良い気がするんだけどなぜかは説明できない...」という案が、ペアによって意味が与えられ、捨て案だと思っていた案が中心となる機能と成長しました。
3. ストレスが減る
デザインレビューの話しをするときには「レビューは人格否定ではない」という話がよく上がりますが、個人的にはそんなにきれいに割り切れないと思っています(強い言葉で言われると辛いもんは辛い)。
そういった意味でも、2人で作ったというのはある種のストレス軽減、自己防衛にもなりますし、いろんな職種を巻き込んでペアデザをすれば、全員で作ったという状況も作れます。
全員がサービスをデザインするチームへ
ペアデザ続けていくにつれて、ペアデザはデザイナー間だけではなくビジネス、エンジニアを巻き込んだ、ペア作業、モブ作業に発展してきました。
👆現在のデザイン会議体
いろんな職種の考えが一つのプロダクトになる、それが実現出来てきました。
機能案を現実のメタファーから考えることはエンジニアのMVCやコンピュータの歴史に関する知見がもとになっていたり、
いま設計している機能は何のために...?となった時には、ビジネスサイドが作ってくれた、カスタマーサクセスのライフサイクルを参考にしたり。
コミュニケーションが活発になることで、メンバーや他職種の考え方を知ることが出来る、結果としてきちんと、全員の考えが1つのアウトプットに反映される。(そして自分も成長できる)
その環境を作るためにも、「ペアデザ」という取り組みは、みんなでサービスに取り組むきっかけになりました。
最後に
今回はペアデザインを実際に行うときのフローとポイント、メリットを書きました。
・チーム全員でアウトプットの認識を揃えておく
・ペアで進め方の認識を揃えておく
・リモートでもお互いのアウトプットをすぐに承認できるようなコミュニケーション環境を整える
ペアデザをやりたいという理由で始めてもまず発見があると思います。
デザイナーだけでも、設計、プロトタイピング、ワイヤーフレーム、ビジュアルデザイン....どのプロセスでも取り入れられます。
たまたま、gyosysチームにはこのやり方が向いていましたが、他の新規サービスにおけるデザイナーの働き方やチームのコミュニケーション方法についてお聞きしたいので気軽にツイッターでリプください🙏 → @taka_piya
おわり。
参考
エクストリーム・プログラミング(Kent Beck)
https://www.amazon.co.jp/dp/B012UWOLOQ/
Pair design (Gretchen Anderson, Chris Noessel)
https://www.oreilly.com/content/pair-design/
第四次産業革命とデザイン
https://www.meti.go.jp/committee/kenkyukai/sangi/sangyo_design/pdf/004_s01_00.pdf