アプリエンジニアをやっている鷲田です。参加した多くの方にガイドラインについて興味を持ってもらえました。デザインガイドラインの作成については僕も当事者の一人なので、今回はアプリエンジニアからの視点で考えていたことを書いてみます。(なのでみんな読んで)。開発初期1は手探りのまま勢いで作っていた事もあり、デザインをどれだけ忠実に反映するかの合意がかなり曖昧でした。そのため、以下のような事が起きていました。「治安悪いわー」などと嘆いていました。エンジニアの中で広く受け入れられたりしているような時期で、以前よりも「再利用可能なデザイン設計書を用意するべき」という空気になっていました。いう話があり、トップページや検索画面を作り直すという事になりました。いう事になり、このタイミングでデザインガイドラインが作られ始めました。デザインガイドライン作ってもうまくいかないのでは?という懸念ただ、世の中の設計書やアーキテクチャーがそうであるように「単にデザインガイドラインを導入しただけではうまくいかないのでは?」という懸念が個人的にはありました。以下のような悪いシナリオが想像できます。ガイドラインに合わせられない「例外」が大量発生。ガイドラインが無意味にガチガチすぎて開発効率が悪化。デザイナーとエンジニアやディレクターとの温度感が違い過ぎてコミュニケーションロスが発生。いった事態にならないように、例えば以下の事に気をつけながらガイドラインをうまく運用できるためのお膳立てを行っていました。読み合わせ会をやっています。みんなで読んで持ち回りで分担して書いてあった内容を毎週発表する、という事をしました。これには以下の狙いがありました。知識のベースラインを確保したかったデザイナーとエンジニアではデザインに対する知識や認識にどうしても大きく違いがあります。そのままだとそれぞれの認識で考えてしまい、ちゃんとしたコミュニケーションが取れません。結果デザイナーが「治安の悪い」実装に甘んじるか、デザイナーの慣れた流儀(WebだったりiOSだったり)にエンジニアが合わせて無理矢理実装する事になります。これはある程度は仕方がないのですが、同じ指針をみんなが学習すれば、その指針を元に議論を行う事ができるようになります。合っていないけど、こういう理由があるのであえて変えよう」みたいな根拠を伝える事ができるようになります。FrameworkやUIKit)が用意されていたり、逆にガイドラインの裏に開発環境の文脈が隠れていたりします。いった暗黙的な知識や肌感といったものは開発環境のドキュメントやガイドラインを読むだけでは理解が中々難しいと思います。ガイドラインをたたき台にして立場の違う人達から意見を出し合す事で、お互いの視点をより理解できるようになります。デザインガイドラインを作る数ヶ月前から始めています。正確にはデザインガイドラインを作る際に行った工夫ではないのですが、当初からガイドラインを作るようになる事をある程度見越していたように思います。関するある程度の素養は全デザイナ・アプリエンジニアの中で出来上がっていました。デザインガイドラインに関してもその意図や構成に関しても、それほど大きな認識の齟齬は発生せずに実装まで適用できたと考えています。デザインガイドラインを忠実に実装する実装する際は、ガイドラインの仕様を写したようなコードになるようにしました。以下のような事をしています。いうのも大きな理由です。抜本的でないレベルの仕様変更をある程度見越すのはエンジニアの領域です。ガイドラインにちょっと変更を加えたら表示が崩れたり、直すのに工数がかかり過ぎて変える事ができない、という事態になるのはエンジニア側の問題であり、ちょっと恥ずかしいという思いがあります3。「ガイドラインに無い共通化は行わない」ようにしています。以下のような事は避けています。)共通スタイルをテーマに組み込みすぎないこれも「ガイドラインに修正が入る可能性がある」事を見越したためで、不用意な共通化はガイドラインの修正時に意図しない修正が発生したりします。実装の都合で共通化したくなったら、まずはデザイナーに相談します。結果それほど頻繁ではありませんが、「ガイドラインに小さな修正が入る」事がありました。全体の行間を変えたり、特定の色を濃くしたりなど。上のように実装していたおかげで、実装側の修正箇所も小さくなりました。このようにしたトレードオフとして、デザイナーに対してもある程度の実装のセンスを求める事になっています。同じ色なのにテキスト色と背景色は分けたりするといった思考が要求されるようになっています。これに関してはデザイナーがHTML/CSS/JSの実装をある程度理解していたりするので現状問題になっていないように見えます。ガイドラインを作る事によって開発効率をあまり落とす事なくある程度のデザインの品質を確保できるようになりました(と思います)。上手くいった背景として、デザイナーとエンジニアの距離が近い所があります。デザイナーとエンジニアがほとんどコミュニケーションを取らないような体制だったら、現在のようにガイドラインを調整しながら実装していく事は難しかったでしょう。「使いこなして直していく事で柔軟なデザインガイドラインを育てる(しなやかな設計)」などを意識しています。Sourceのような、開発プロセスやアーキテクチャーなどの文脈で語られる事が多いですが、今回のように「ドメイン」にこだわらなくてもそこにある基本的なアイデアは色々応用ができるのではないかと思います。