builderscon tokyo 2018 に行ったよ
builderscon tokyo 2018 に行ってきた。
builderscon.io
びるこん、一番最初のセッションが分からなすぎたので（これはやはりアカンかったか…）と挫けそうになったけどちゃんと頷きながら聴けるものもあってよかった…
— hikari (@_ave_h) 2018年9月7日
全体の感想は後ほどとして、いち参加者としてかなり満足度の高いカンファレンスでした。
書きたい時が書き時だ！ということで聴いたセッションについて自分なりにまとめた内容や感想を。今回は以下について。
デザイナーとうまく協働する方法
Yasuhisa👨💻 (@yhassy) | Twitter さんのセッション。
昨今の「デザイン」を取り巻く状況
UI/UXデザイナーの需要は昔に比べて今後もどんどん高まっていくだろうこと、しかしデザイナーは業界的に（慢性的に？）不足している状況。
デザイン投資するとこんなに儲かるんですよねというのも結果として出ている。
- 雇用も変わってきている
- 需要も高い
- 経営者も「デザイン経営」宣言してたりする
まさにこの世は Design Changes the World ・・・
でもデザイナーと他職種（エンジニア、営業）での認識の違いだったり、デザインの解釈の違いで距離感生まれることはよくある。
例えば「デザインは重要です」という一文をとっても、
- デザイン
- どのくらいの範囲を指すの？
- 重要
- 誰にとって、どう重要なの？
- 営業にしたら自分の儲かる範囲までなの？
とか受け取る人によって違う。
こういう discommunication はよく発生する。
どうして距離感が生まれてしまうの？
- エコーチャンバー現象に気づいていない*1
- 「デザイン」はデザイナーの中にあるという思い込みとか、当たり前という先入観
- 「察して欲しい」という受け身の態度
よくあるのとして上の3つとかがある。
同じ職種同士で意見を交わせるのみで閉じてしまっていて、そこから発展しない。「デザインはデザイナーが決めて」というお互いの範疇に入り込もうとしない。
デザイナー×エンジニアで意見を交わしても、「こちらはこれだけやった」という努力を認めて欲しいというコミュニケーションになってしまい、チームがバラバラになる。
そのような状況だとどんな新しいツールとかを使っていようがすれ違いが生まれてしまう。
どうすれば良いのか？
デザイナーでもエンジニアでも、「良いモノを作りたい」という仲間であるというのは一緒であって・・・
すれ違いを生まない、協働のためにできることは「言語化」と「明文化」。
それだけ言うと「やってるよ！」と思う人が多いけど、あくまでそれを「どのレベルまでやるか」が重要。
言語化
「言葉を合わせる」こと。
例えば某アプリのような、料理レシピに対してお気に入りをつけるようなアプリを作るとして、
料理のレシピを作るような”料理人”はプロダクトでどう表記する？英語表記はどうする？
デザイナーとエンジニアで論議の際に飛び交う言葉を合わせておかないと、それを翻訳する作業が必ずどこかで発生する。効率も悪い。
対エンジニアとしては、システム設計の際のモデリングをするときに、エンジニアだけじゃなくちゃんとデザイナーを呼び込んで議論することも大事。
デザイナーには「モデルとユーザを考慮したデザインを作る」という、モデリングをした上でデザインをして欲しいと伝える。
言葉あわせのためのモデリングも重要。
この辺、同業種に発信するのは簡単だが、異業種に対しては同じようには行かないということや
- 自分の独自言語で話してないか？
- 自分が発信している言葉は外に言って伝わるのか？
という内容も話されていて超わかる！！・・・と頷きながら聴いてた...。
また、使うユーザから見えないようなガイドラインにない言葉が飛び交うのも良くない。開発・デザイン以外の視点も考慮する必要がある。
そして互いにUIや機能の捉え方を共有・学習するのも、認識の溝を埋めるのに大事なこと。
yasuhisa.com
紹介されていたこちらの「要素名クイズ」、面白いなーと思った。
現場においてそれは正しいのか、業種を超えて認識をすり合わせするのは大事・・・。
議論があさっての方向に向かってる・・・って時も、言い方が違うだけで実はやってるのが同じってこともある。
あとこれめっちゃあるあるっていうか「そうだな」と思ったのだけど、
よく飛び交う「かっこいい」ってなに？「イケてる」ってなに？みたいなニュアンスの共有 大事。
チームにおける「良い」ってなに？を共有する。
せめて自分たちが何を基準にそれを言っているのか？はちゃんと言葉にしよう。
明文化
デザインの評価をする際、言語化された「言葉」から原則を作り、価値に基づいた評価をすることが重要とのこと。
- 課題を解決しているかどうか
- ユーザへ提供する価値は何か
- プロジェクトメンバーが納得できる施策か
それをスムーズに評価できる状態に持っていくために、
例えば「これはどうですか？」みたいな感じでいきなり成果物をエイヤ〜と出すのは良くない。
ちゃんとどうしてこういう成果になったのか？を残すこと。
「かっこいい」「イケてる！おk！」で決めるのではなく、課題解決に議論をシフトさせるために
どうシフトしてこういう結果になったのか？理由をちゃんと説明してもらって、徹底的に議論をするようにしよう。
エンジニアがシステムのドキュメントを残すのと同じで*2、明文化はデザイナーも必須。
自分たちの思考プロセスをちゃんと共有して、お互いの溝を埋めていく。
上に書いたように自分も言語化・明文化「やってるよ！」と一見思いはしたけど、それでもこうやってデザイナーの目線から聴くとまだまだ考え直して取り組まなきゃいけないとこ多いなぁ、と頷きながらのセッションだった。面白かった。
ちょっとカンファレンス自体の感想
こういうカンファレンス、今まではPHPカンファレンスくらいしか行ったことがなくて
仕事でやってる中で久々に大きなお祭りに参加してみたいな〜というのと風を取り込みたい（ニュアンスが雑）という気持ちがありワクワクドキドキしながらの参加だった。
自分が聴きに行って話分かるんだろうか・・・と尻込みしてて不安なところもあったけども。
2日行ってみてセッションも楽しく聴けたものが多かったし、会社の人がスピーカーとしてどう話してるんだろうというのも聴けた（見れた）し、主催側・スポンサー企業のイベントに対するホスピタリティも感じられて良い時間だった。
