どくぴーの備忘録

真面目なことを書こうとするクソメガネのブログ。いつ投げ捨てられるのかは不明

Bonfire Android #4 に参加してきた #yjbonfire

久々に勉強会に行ってきたブログを書きます。

Yahoo! Japanさん主催のBonfire Android #4にブログ枠として参加してきました。

yj-meetup.connpass.com

Bonfire Androidでは毎回テーマを決めてYahoo! Japanさん内外から登壇されるのですが、今回は「UI」がテーマと言うことで、5人のデザイナー・エンジニアの方がチームでのデザイン手法、UI開発といったトピックを発表されていました。本記事では、各発表を振り返っていこうと思います。

Yahoo!乗換案内アプリでのデザイナーの役割について（山浦優樹さん）

エンジニア・デザイナーそれぞれ二人づつで開発されているというYahoo!乗換案内アプリでのデザイナーの立ち回りについて話されていました。初期はデザイン工数等の関係で以前はAndroid/iOSで共通のデザインを使っていた状況からMaterial Designを始めとしたAndroidデフォルトなデザインへ寄せていく中で、デザイナーがMaterial Design、Theme、Design Support LibraryといったUIに関わるAndroidの技術に対しての知識を持っていったことや、実際にLayout XMLをデザイナーが編集する、というようにデザイナーができることを大きくしていく中で

  • デザイナーはUIの磨き込みに集中できるように
  • エンジニアは実装に集中できるように

という2つの環境を実現するためのデザインフローについてのお話をされていました。

一方で、実際にデザイナーがAndroid Studio上でLayout XML/Drawable XMLといったResourcesを作るという役割の拡大について、自分で触ることでエンジニア以外には得にくかった「アプリデザインではプラットフォームごとにどのパーツが使えるかを知れる」というメリットはあるもののそこに踏み込むことの難しさについても触れられていて、HTML/CSSでのWebDev領域のようなハブとなれるプレイヤーを立てることでうまく回るのでは、と述べられていました。

”Material Designの変化”の中でアプリエンジニアができること（中村恵太さん）

speakerdeck.com

2014年6月に公開されたMaterial Design Guidelineにおよそ4ヶ月で準拠したラクマのフリル時代から今の新ラクマまでのMaterial Designまでの変遷に触れて、初期のMaterial Designのメリットとして

  • ユーザエンゲージメントにとどまらないメリットがある
    • 開発効率
    • エンジニアのデザインへの意識が上がる
      • デザイナーとデザインについて議論する際の共通言語になれるかも

という点があるものの

  • ガイドラインに引きずられてしまい、ブランド表現に難がある
    • Google感がやはり出てしまうため
    • iOSと比較すると全体的に暗く、画面遷移も別れてしまう

といったデメリットが有ると述べられていました。その後Material DesignにLaunch ScreenやBottom Navigationといった新しいコンポーネントや2018年5月に公開されたMaterial Design Guideline 2.0によってブランド表現が柔軟になったこと、変化を継続していくデザインシステムになったことを説明し、その中でアプリエンジニアは何ができるのかということで

  • 変化に柔軟（であろう）というエンジニアの強みをUI領域にも持ち込む
    • 個人的にはアンテナを張っている、新しい情報へのリーチが早い、ということかなと解釈しています
  • Material Designのキャッチアップをただの情報共有ではなく課題解決目線として提案していく
    • 何が表現できて、どうプロダクトに取り込めて、結果何が解決できるのかという具体的な提案

というアクションの提案をされていました。この提案のためにSketchプラグインであるMaterial Theming Editorをエンジニアが提案のためのツールとして用いることでデザイナーの改善イメージのサポートに役立てようと動いていることが興味深かったです。

自由度の高いアプリ内UIを実現するためのKARTE SDKの仕組み（中間亮彬）

トラッキングや分析、アプリ内メッセージやプッシュ通知を行うことができるKARTEのアプリSDKについて、特にアプリ内メッセージについての実装面でのお話をされていました。アプリ内メッセージへのアプローチとしてフォーマットに従って配信するネイティブ実装とHTML/CSSを管理画面上で記述するWebView実装があること、カスタマイズ性を重視してWebViewでの実装を選択したことについてまず触れ、実際にKARTE SDKの内部構成やその中でのデータフローといった技術的な要素によってWeb・アプリ双方で同じUIとしてアプリ内メッセージを提供することを実現することについてお話されていました。

UI改善に繋がるエンジニアの立ち回り（瀬戸優之さん）

speakerdeck.com

デザイナーとやり取りができる、工数の巻き戻しができる人を対象として、必要な知識がデザイナーとエンジニアで重なる部分があるUI改善のためにエンジニアはどう立ち回るべきか、というお話をされていました。

まず普段からエンジニアができることとして、デザイナーがアンテナを張っていても情報を得にくい部分である、

  • 環境について
    • ProgressDialogが非推奨になっている、というような実装レベルでのUIパーツの使用可否
    • Material Design Components（MDC）についての情報
      • そもそもAndroidXが必要
      • ではプロダクトがいつからAndroidXに対応して、いつからMDCを使えるようになるのか
  • 実装について
    • 工数見積
    • Material Design Guideline 2.0で定義されたExtended FABがボタンで作れること
    • ダイアログがダイアログを出すのような二重表示ができないこと

というような情報を共有することで早い段階での気付きにつなげていくという点に触れ、そのためにコミュニケーションポイントを増やす必要があり、頻度が高いコミュニケーションほどコストが掛かるものの、Material Design Guideline輪読会のような定期的な会を行うことでMaterial Designの知見や共通認識・AnimationやComponentといった環境や実装の話といったコミュニケーションを実現するという提案をされていました。また、エンジニアが気にするべきデザインのチェックポイントとして

  • 画面回転や横レイアウト
    • 直しにくい、工数的に厳しい場合は画面回転・横レイアウトを許可しないという手もある
  • Empty Status
  • オフライン時挙動
    • キャッシュを出すのかそもそも動作を止めるのか
  • マルチウィンドウ、縦長ディスプレイ
    • そもそも非対応にするのか、UIの要素を伸ばすならどこか
  • コードレベルでのチェックポイント
    • エラー通知
      • try-catch / onErrorのフィードバックが存在しているか
    • 仕様が複雑化していないか
      • 異常に複雑な実装は仕様からすでに複雑になっているかもしれない
  • ユーザ目線でのチェックポイント
    • 操作の手数
      • エンジニアが操作に疲れるならユーザも疲れる
      • 大体1画面3操作を意識する
    • RAILモデルを利用した動作速度ベンチマーク
      • 操作から100ms反応が無いとユーザは困惑する
      • 1000msかかるとユーザの離脱率が上がる

という点を挙げられていました。日頃の仕事でも考えているものもあれば、全然気にしていなかった事もあって、すぐ効果が出るわけではないものの、これから意識して実践することによって少しでも改善に貢献していきたいと思いました。

エクストリーム・プログラミング開発におけるUIテスト〜ライブコーディングを添えて（飯島彩輝さん、松田悠吾さん）

LEAN XPを導入しているヤフオクチームでの実際の開発事例をライブコーディングを交えて説明されていました。

何を作るか？を絞るLEANとどうやって作るか？を絞るXPを組み合わせたLEAN XPにまず触れ、その中の要素としてペアプログラミング、テスト駆動開発、ユーザーストーリー（とストーリーポイント）を始めとしたものがあること、実際にヤフオクチームで実践しているPivotal Tracker上でのユーザーストーリー管理からのじゃんけん見積もりによるストーリーポイントを決定することによるチーム内での認識齟齬の解消、片方がテストを先に組み、片方が実装を行うペアプログラミングによるテスト駆動開発をライブコーディングしていく中で

  • 同じ画面を見ながら開発で早い段階でミスに気づくことができる
  • どういう実装をチームの人がするのかをリアルタイムで見れることでレビューコストを減少できる
  • テストコードが仕様書と化すので、開発へ大きく時間を割くことができる
  • ユーザーストーリーの実装ごとにリリースを行うことで効果を都度確認することができる

という利点を挙げられていました。また、実際の導入効果として、

  • シナリオテストの失敗率の大幅な減少
  • 手戻りが減った

といった点をお話されていました。

後記

登壇者の方々、主催、運営のYahoo! Japanさん、本当にありがとうございました！
ちゃんとレポートをしたのは久しぶりなのですごく疲れました。

エンジニア懇親会というと、寿司！ピザ！みたいなイメージなのですが、今回の懇親会はすごくおしゃれな感じでした。 きっきパイセン（ @dnc_pop30 ）に聞いてみたところ、ツイートに上げた写真を使っていいと言われたので飯テロ写真を置いておきます（ありがとうございます）。