とても良い感じです。

はじめまして、アンドパッドで iOS アプリ開発を担当している西 @jrsaruo_tech です。

最初は Swift の好きなところを30個挙げる記事を書こうと思ったのですが、誰が読むんだろうと冷静になれたので猫をかぶることにしました。Swift の話はまた別の機会に。

さて、アンドパッドでは日々多種多様な社内勉強会が開催されているのですが、その中に『HIG を読む会』というものがあります。
HIG とは Apple が公開している Human Interface Guidelines のことで、Apple プラットフォーム向けのアプリをデザインするうえで必要な知識やベストプラクティスなどがまとめられています。

『HIG を読む会』では、UI デザインに興味のあるエンジニアと UI デザイナーが集まって一緒に HIG を読み、気になったことや関連するテーマでわいわい話しています（「エンジニアとデザイナーが一緒に」というのがポイントです）。昨年11月末から週一で開催しており、先日28回目を迎えたところです。

本記事では『HIG を読む会』を開催するに至った背景、またどのような形式で実施しているかについて紹介したのち、約半年続けてみて良かったこと、もっと良くできそうなことをお話しします。

『HIG を読む会』を始めた背景
- HIG を読みたかった
- HIG を「みんなで」読みたかった
開催形式
半年続けてみて
- 良かったこと
- もっと良くしたいこと
おわりに

『HIG を読む会』を始めた背景

HIG を読みたかった

そのままの理由ですね🙃

筆者が所属している開発チームでは、UI デザインについてデザイナーだけでなくエンジニアも積極的に議論し、ユーザにとって最適な UI を皆で追求しています*1。その際、やはり議論の土台や一貫した判断基準が欲しくなります。そこで HIG です。

HIG には Apple が長年考え抜き蓄えてきた知見がたくさん詰まっているので、そこから得られる知識はデザインを議論する際のベースになりますし、「なぜそのデザインにしたのか」の説得力を底上げしてくれます。そら読まねば。

HIG を「みんなで」読みたかった

なぜ「みんなで*2」読みたかったのかについて説明します。

iOS のデザイン慣習とその重要性を共通認識として持ちたかった

これが筆者にとって最も大きなモチベーションでした。というのも、日々の開発の中で新しいデザイン案を受け取った際に「iOS っぽくないな」「標準の UI コンポーネントを使いたいな」と感じることがしばしばあったからです。

iOS のデザイン慣習から外れた独自 UI には以下の懸念があります*3。

UI 面
- ユーザが使い慣れておらず挙動の予測が難しい
- 標準 UI コンポーネントが提供してくれるアクセシビリティなどの機能をそのまま利用できない（自前で実装する必要がある）
- iOS のアップデートに追従しにくい（アップデートに伴う UI 改善の恩恵を受けられない、壊れやすい）
実装面
- 実装・保守コストが高くなりがち

特に実装面の観点はエンジニアの方が理解が深いため、エンジニア側から「標準の UI を使えないか」と打診することも少なくありませんでした。こうした事情から、HIG をみんなで読んで iOS のデザイン慣習や iOS 標準 UI コンポーネントの有用性を共通認識として持ちたいと思っていました。

HIG を理解するうえで必要な情報を補い合いたかった

HIG にはエンジニア観点の話とデザイナー観点の話が織り混ざっています。つまりエンジニアだからこそ読み解ける内容、デザイナーだからこそ読み解ける内容があるため、エンジニアとデザイナーが一緒に読むことで互いに情報を補完でき、理解を深めやすいのではないかと考えました。

HIG を読むハードルを下げたかった

HIG を読むメリットは先述の通りですが、いかんせん量が多いのと、当時はまだ英語版しかなかった*4というのもあり、1人で全て読み理解するというのはなかなかハードルが高い印象でした。筆者も二の足を踏んでいた1人です。
そこで、いっそ関係者を巻き込んでみんなでわいわい読み進めればモチベーションを維持できるのではないかと考えました。

コミュニケーションの場を増やし、知見共有や議論を活性化したかった

議論する相手が滅多に話したことのない人だった場合、変に遠慮してしまい意見を思うように言えないということもあると思います。普段から雑談も交えつつコミュニケーションを取り、日常的に信頼関係を築いておくことで、話しやすい雰囲気が醸成され、知見共有や議論の心理的ハードルを下げられるのではないかと期待しました。

こうした背景から『HIG を読む会』は爆誕しました。

開催形式

誰でも気軽に参加できることとモチベーション維持を重視し、開催形式を以下のように設定しました。

任意参加
週1回30分
- 1つのページを3回程度に分けて読むくらいのゆったりしたペース
予習は不要
- 飛び入り参加ももちろんOK
毎週代表者1名が読み上げ、合間で興味深かったことや補足があれば好きにわいわい話す
- 代表者は立候補制でその場で決める

半年続けてみて

とても良い感じです（2回目）。

良かったこと

HIG をもとに議論し、プロダクトを改善できた

アンドパッドでは社内のデザインシステム『Tsukuri』の開発・導入を進めているのですが（Tsukuri の詳細については『BtoB SaaSプロダクトで「機能する」デザインシステムを目指して - Speaker Deck』をご覧ください）、『HIG を読む会』で得られた知識が早速 Tsukuri でも活用されています。

例えば「先日読んだ HIG の○○のページに記載があった通り、ここはシステム提供の□□を使うべきではないか」という会話を通して Tsukuri を改善することができました。これまでは□□を使うべき理由を別途説明しなければならなかったところを、「HIG に記載があった通り」とスムーズに伝えられるようになったのは良い成果だと思います。

知見を共有し合う場ができた

期待通り、会では毎度 HIG の内容に関してたくさんの意見が飛び交い、エンジニアとデザイナーとで活発に情報交換できています。例えばデザイナーからは

色のコントラスト比とテキストの読みやすさとの関係
Tsukuri との対比
ANDPAD 特有のデザイン観点
- 例）使おうとしている色は現場の職人さんが太陽光のもとで判別しやすい色か？

エンジニアからは

「セーフエリア」「マテリアル」など iOS アプリ特有の用語の解説
iOS バージョンに関する注意点（バージョンごとのデザイン差異や利用可能バージョンの下限など）
「この UI は実装コストが低いので取り入れやすそう」といった意見

のように、お互いの観点から様々な知見が共有されています。

HIGを読むハードルが下がった

参加者の方から

一人では読む気になれなかったHIGをこの会のお陰で読めています！

という嬉しい声がありました。みんなで読むという場はやはり良いきっかけになったようです。

エンジニアとデザイナー間のコミュニケーションが取りやすくなった

交流の場ができたことで、以前に比べてエンジニアとデザイナー間で意見交換する敷居が下がったように感じます。別チームとのミーティングで「先日 HIG を読む会でお会いしましたね」という会話があったことも。

予習なしは長続きのコツかも

会が始まってから半年強経ちますが、第1回からコンスタントに10名くらいの方に参加いただいています。また、会の存在を知って興味を持ってくれた方が途中から飛び入り参加してくれることもしばしばあります。

理由はいくつかあると思いますが、予習・準備が必要ないというのは長続きの1つの理由かもしれません。普段の業務もあるなかで予習もしないといけないというのはなかなか負担が大きいですし、後から興味を持ってもらえたとしても参加しづらいと思うので、今回は正しい選択だったように感じます*5。

シンプルに楽しい

HIG を読んでいると様々な学びや楽しさがありました。インクルーシブデザインとユニバーサルデザインの違いや、普段触れることのない Right to Left 言語圏の文化など、興味深いコンテンツが多いです。最近では SF Symbols に追加されたアニメーション機能で盛り上がりました。

おおおおおおおお！すげーーーーーすご！楽しいおおおおおおおお Wifiすごい電波めっちゃウケるすごーー！ — SF Symbols のアニメーションを見てテンションが上がっている大人たちの様子

もっと良くしたいこと

プロダクトへの直接的な還元をさらに増やしたいと思っています。

現状でも先述の通り Tsukuri にフィードバックできていますし、HIG の知識をインプットすること自体長期的に見て効果があると思いますが、「今作っているアプリのここは HIG にならってこう直せそう」といったアクションにももっと繋げていきたいです。例えば開発中のアプリを HIG の横に並べて、読みながらアプリ上で関連する場所を触ってみるなどは効果があるかもしれません。

また、HIG だけでなく WWDC のデザイン関連のセッションを見るというのも面白そうです。