デザイナとエンジニア間でどんなやりとりをするのが良いのか？「コーダーがデザインすべきなのか」 #tryswiftconf
はじめに
おばんです、try! Swift Tokyoは今年で3回目、皆勤賞の田中です。
このエントリーはtry! Swift Tokyo 2018のセッション 「コーダーがデザインすべきなのか」(Sash Zats) のまとめになります。
講演内容
公式サイトより引用。
ほとんどのソフトウェアエンジニアは、デザイナーがコーディングする世界がより良い世界であることに同意します。 このトークでは、反対の考えを探求したいと思います。 コアデザインの原則を知っていることによって、時間を節約し、よりプロダクトに実用的な課題に対する弾力性を持たせ、ユーザーとのコミュニケーションを改善し、スマートで楽しいプロダクトを作るのに役立つということを探究したいと思います。
このセッションの要約
多くの人が、「デザイナーがコードを書けると良い」という話に同意していますが、登壇者の Zats さんはそれに反する話をします。
なぜ反対するかというと、以下の理由からです。
- エンジニアならば、エラーケースを想定することができるから
- エンジニアならば、最新のAPIを利用することができるのでよりユーザーにとって便利な機能を提案することができるから
講演資料
デザインは複数の意味で定義されている
- デザインとは単にどのように見えるか、どうのように感じるかということではない。どう機能するかだ by Steve Jobs
なぜコーダーがデザインすべきなのか
- 今日するデザインの話 = 機能面にフォーカスしたデザインの話
- Avoid "lack of context" mistakes (コンテキストの欠如を回避するため)
- Be more independent (より独立して動くために)
- Unblock yourself (ユーザーの行動を制限しない)
- Resolve undefined behaviors (未定義動作を解決しよう)
- ものを作るときはエラーを想定すべきである
- エンジニアはエラーを想定できる
- Evangelize (伝道するために)
- 「エラーケースが欠けている」という指摘だけでなく、コンテキストも含めて人に伝える必要がある
技術専門者として貢献できること
- どうすればエンジニアとしてよりよく貢献できるか
- 最新の技術やAPIが利用可能だということは強み
- 技術的に何が可能かをチームメイトに理解させる手助けをする
Habitation 習慣化
- ユーザーは慣れてくる
- なにかの計測値がわかっても、ユーザーは最適な設定値に設定することはできなかった
- 電気の利用量がわかっても、最適な利用量をユーザーは設定できなかった
- 子供/若い人のように考える
- 子供がするような質問もどんどん考えていくことが大事だと思う
- 子供の言葉から未来を考える
- 空飛ぶ車や、冷蔵庫の中身が自動で補充される、など
- Q. 「なんで車は自動運転しないの？」
- A.「そうできているからだよ」
- ではなく、ちゃんと答えられるように考える
Outro まとめ
- デザインはなにかものを描くということではない
- なにがどう機能するかを考えること
- 技術はリベラルアーツや人間性と一緒になることで我々の心を歌わせる製品やサービスに昇華される by Steve Jobs
Q&A
セッションのあとのQ&Aで、補足としていくつか質問をさせていただきました。
エンジニアとデザイナが負うべき仕事/責任
- Q. それぞれの役割において負うべきものの境界であったりはどこにありますか？
- A. ものを作るときは互いに尊敬する心を持って、相互によりよいやり方を探っていくもの。そこに境界のようなものはないと考えています
エンジニアとデザイナの協業について
- Q. セッションの中でも語られていたように、エンジニアはエラーケースをよく知っています。その上で、エンジニアはデザイナとどうコミュニケーションをとっていけばよいですか？
- A. なにかあったらもちろん都度相談する必要があります。エンジニアがエラーケースに対するデザインをどうすべきかを聞いたり相談したり。
決められた期間の中で、どれだけコミュニケーションをとっていけばいいか
- Q. 僕がいつも悩んでいることとして、決められた期間の中でできるデザイナとのコミュニケーションの時間は長くはとれないということです。それはどう解決する or どこに妥協点を持っていたりしますか？
- A. 先に言ったように、それぞれのケースに対してどうすべきかを都度聞いていると時間が足りなくなります。なので、デザイナーとも早い段階から話し合いを始める必要がある。そうすることで手戻りであったりを減らせると思っています
どのようなタイミングでデザインと技術の話をしていけばよいか
- Q. 早い段階からデザイナとエンジニアが話し合いを始めるべきという話がありましたが、どういうタイミングでそういった話し合いの場を設けるのがよいですか？またそういう場でエンジニアがデザイナと話をするうえで気をつけているポイントなどはありますか？
- A. タイミングについては難しいですが、それを作ることに熱中してたら気付かずにそういうタイミングを設けているはずです。デザイナとエンジニアの橋渡しの良いあり方はチームによって異なるので、最適解はありません。誰もが良いものを作り上げることに熱心だと仮定するならば、デザイナがエンジニアに質問するのと同じくらい、エンジニアがデザイナに質問するためのフローを改善しなければいけないと考えています
田中の感想「エンジニアとデザイナがやり取りしやすいフローを考えてみよう」
要約にも書いていますが、以下の点に特に共感しました。
- エンジニアならば、エラーケースを想定することができるから
- エンジニアならば、最新のAPIを利用することができるのでよりユーザーにとって便利な機能を提案することができるから
通信結果やアプリの状態変化に伴ったエラーケースにどんなものがあるのかというのは、エンジニア側が発見したり、持っている知識です。その上でなぜそうなるのか、ユーザーのためにこういったことを考慮してあげるべきではないか、というのはエンジニアから話題に出すことです。 ただしそこに役割による境界はなく、作るものをより良くするというのはチームの課題です。
チームで協力して改善していくために、どういう提案の仕方だとデザイナ/エンジニア相互にやり取りがしやすいのかどうか考えて見て、フローを作ってみたいと思いました。
