新コべき論―デザインとエンジニアリングの間で
コべき論やデコべ論、デコべき、デべき論と数々の異名で永遠と議論され続けてきた「デザイナーはコーディングできるべきか否か」というナンセンスな論争に終止符を打つべく、現職 SmartHR での実例を交えながら新コべき論として展開していきます。
デザインはデザイン、エンジニアリングはエンジニアリング、ではない世界が当たり前になり “デザインとエンジニアリングの狭間” や “デザインもエンジニアリングもひっくるめた開発” を意図的に選択できる人が増えることを願って。
コべき論とは
まずはコべき論に触れておきます。「デザイナーはコーディングできるべきか」の略で、主にソーシャルメディアなどの場で周期的に盛り上がる話題です。議論の源は、オンスクリーンの制作に関わる現場でデザイナーと開発関係者（エンジニアや PM など）との間に発生する非効率なコミュニケーションによって生まれた負のエネルギーでしょう。その議論の多くは個人の能力に向けられますが、個人で解決できることには限りがあり、根本的な問題はその個人を取り巻く環境にあるのではないか、と私は考えています。
ちなみに私はウェブエンジニア出身ですが、今はプロダクトデザイナーとしてコードを書いています。コードを書けるに越したことはないですし、ウェブに関わるなら HTML と CSS を理解してるよね、くらいには考えます。しかし、プロダクトデザイナーとして「早く」「質の良い」プロダクトを作れればよく、その手段は人に依ります。私にとってコードを書くことは一つの強い武器ですが、それを他人に強いる気持ちはありません。
SmartHR のプロダクトデザイナーについて補足
こんな記事を読んでくれている稀有な読者と前提知識を揃えるために、SmartHR のプロダクトデザイナーについて少し紹介しておきます。プロダクトデザイナーの採用情報における応募要件を見てみましょう。「アプリケーションやソフトウェアの仕組みについての理解や関心」が必須なのは、我々が “デザインとエンジニアリングは不可分である” と考えている現れです。歓迎要件の「オブジェクトデータモデルへの理解や関心」も円滑な開発コミュニケーションのための開発知識を求めた項目です（つい最近まで必須要件でした）。また「デザインの中間成果物を含んだポートフォリオ、またはそれに準ずる物を提示できること」では、プロダクト開発活動におけるすべての活動を “デザイン” と捉え、デザインツールで作るデザインデータばかりが “デザイン” ではないことと、あくまで “デザインデータ” は中間成果物であり “最終成果物” ではないことを謳っています。（余談ですが、私は自分がいかにデザインをしてきたか、何をデザインと考えるかを書き連ねた1枚の作文のような HTML を提出しました。）
一般的な “UI/UX デザイナー” の期待値に比べると開発への理解を求めていますが、「コードが書けるかどうか」という観点では、書けないデザイナーの方が多数派です。「デザイナーもコーディングできたほうがいいかも」と考える人が少しずつ増えている現状こそありますが、「開発の理解 = コードが書ける」ではないのです。
なぜ SmartHR のプロダクトデザイナーは開発への理解を求めるのか
もう少し擦り合わせさせてください。なぜ我々はデザインとエンジニアリングが不可分であると考え、開発への理解を求めるのでしょうか? それは端的に「早く」「質の良い」プロダクトを作るためである、と私は考えます。
プロダクト開発の現場では主に PM とデザイナー、エンジニアの三つ巴になり入り組んでいます。近年でこそアジャイルの浸透により三者の協業は一般的になったかもしれませんが、その職能や役割の溝が埋まった現場は稀でしょう。
その溝を埋めるために我々は PRD や概念モデリング、ワイヤーフレーム、プロトタイプといった様々なツールを使います。溝を越える時に “Handoff（以下ハンドオフ）” と呼ばれる工程を必要とする現場もあるでしょう。それは PM からデザイナーに行われるワイヤーフレームの説明かもしれませんし、デザイナーからエンジニアに引き渡されるデザインメモかもしれません。ご存知の通り Figma は溝を埋め、円滑にハンドオフする非常に優れたツールです。しかし、そもそもハンドオフが生まれている状態こそが問題であり、コミュニケーションコストを大きくしていることを忘れてはいけません。
SmartHR のプロダクトデザイナーの一つの成功はまさにここにあります。すべてのデザイナーが概念モデリングを使いこなし、スクラムの中でプロダクト開発者の一員として PM ともエンジニアとも対等に議論し、共にプロダクトを作り上げ、改善しています。SmartHR UI という共通言語を用いて、効率的にプロダクトをリリースまで導きます。エンジニアのためにデザインデータを綺麗にしたり、仕様を書き記すことはほとんどありません。
開発への理解は、デザインとエンジニアリングの分断を避け、ハンドオフのようなコミュニケーションコストを減らし、「早く」「質の良い」プロダクト作りに向かわせるのです。このスクラムに入り込んで一緒にプロダクトを作っていける “開発者” であるかどうかが、“デザインデータ” を成果物としてしまう “UI/UX デザイナー” との大きな違いでしょう。プロダクトに関わる人がみな “開発者” であったなら、コべき論は生まれなかったかも知れません。
参考： プロダクトデザイナーは新規事業開発にどう関わっているのか
コードを書くデザイナーがもたらすもの
では、そんなハンドオフのない世界で、コードを書くデザイナーやデザインとエンジニアリングが不可分であると理解しているデザイナーはどのような働きができるのか見ていきましょう。
円滑で本質的な開発
まず第一にこれです。コードを書くデザイナーは “実装” という飛び道具はもちろん、エンジニアとの溝を限りなく小さく抑えられるので、コミュニケーションコストが低く生産的です。プロダクトという最終成果物に向かったやり取りを直接行えるため、本質的なプロダクト開発を行えます。
比較するために、ハンドオフのある世界における仕事の流れを極端に表してみます。
- （デザイナーによる）デザインデータの作成
- （デザイナーによる）デザインデータの提出
- （エンジニアによる）デザインデータの理解
- （エンジニアによる）デザインデータを元にした実装
- （エンジニアによる）実装中に発生した課題のフィードバック（1 に戻る）
- （エンジニアによる）実装のデプロイ
- （デザイナーによる）実装物の確認
- （デザイナーによる）実装物へのフィードバック
- （エンジニアによる）実装物に対するフィードバックの理解
- （エンジニアによる）フィードバックの実装
- （エンジニアによる）実装のデプロイ
- （7–11を繰り返す。場合に依っては1まで戻る）
一方、ハンドオフのない世界ではこうなります。
- （全員）仕様の理解あるいは仕様の検討
- （全員）概念モデルのすり合わせ
- （全員）実装
- （全員）何らかのフィードバック
- （3–4を繰り返す。場合に依って1や2に戻る）
そんな馬鹿な、と自分で書いてても笑ってしまったんですが、これ以上に決まった過程はありません。この3つですら境界があいまいで一つの「プロダクト開発」として括りたいくらいです。
比べて見ると、分断していることに依る、分断を埋めるためのコミュニケーションが発生していることがわかりやすいですね。ハンドオフのある世界では、どうしてもデザインデータを介して開発コミュニケーションを取ることになります。お互いを理解し合う工程では非常にエネルギーを必要とするでしょう（特に3や8）。デザイナーはデザインデータという最終成果物を作り、エンジニアはデザイナーが書いた画を実装に起こしています。それは良いプロダクトを作るための工程ではなく、自分の役割や職能を守る非効率な工程ではないでしょうか。アジャイルという小さく改善していく手法を取っても、デザインとエンジニアリングというそれぞれのサイロの中で素早くウォーターフォールを繰り返しているに過ぎないのです。
SmartHR ではコンポーネントライブラリが共通言語として機能しているので、手書きや簡単なポンチ絵で認識を合わせ、デザインデータを作らないことすらあります。デザインと実装を平行に走らせ開発サイクルを短くすることもできます。画面が決まっていない不確かな状況では、エンジニアに「API があれば（JSON が吐き出てれば）なんとかなるので進めちゃって大丈夫です」とお願いし、最終的な UI の実装を引き受けてしまえばいいのです。「ここが 1px ずれています。」というキャッチボールをしている間に、プルリクエストを投げてしまえるのです。
プロダクトの品質
品質と言っても色々あります。使い勝手や視覚設計を含む UI 品質、アクセシビリティやパフォーマンスといった当たり前品質、情報設計やレスポンシブデザインといった様々な状況を加味した設計などなど。これらすべてをデザインとエンジニアリングが分断した状態で達成するのは不可能です。いくら専門家を頼ったところで、役割の溝に落ちる課題を防ぐことはできないでしょう。
繰り返しになってしまいますが、デザインツール上で作るデザインデータとは一体何なのでしょうか? 何を作っているんでしょうか? デザインデータの質を上げても、実際に利用者が触るプロダクトの質が上がるわけではありません。
レスポンシブデザインの例で考えてみましょう。あなたはその “デザイン” を作る時に、まずフレームの大きさはどのように決めますか? モバイルあるいはデスクトップ、タブレットと想定環境が増えた時のフレームサイズはどうですか? その決めた大きさは何ですか? もしかしたら定量データから導き出した平均や中央値、あるいはそれに類する汎化された大きさなのでしょう。どんなに頑張って汎化しても、それは利用者の環境ではないのです。デバイスの多様化もありますが、そもそもデスクトップだから 1024px 以上、モバイルは 320–768px なんて世界はないんです。ウェブは元々レスポンシブなんですから。
ウェブにおけるアクセシビリティはまさにデザインとエンジニアリングが不可分であることを理解していないと実施の難しい領域でしょう。アクセシビリティの前提となる知識はもちろん、HTTP というプロトコルや HTML/CSS などを理解した上で、どう実装するのかまで一気通貫で見ないと芯を食った改善は難しいでしょう。
視覚設計はデザインツール上の試行錯誤で戦えることもありますが、その基なる情報設計はどうでしょうか。RDB の知識や API の知識、UML の知識、文字組版や語彙の豊富さ、といった具合にここには書ききれないほど様々な知識が必要になるでしょう。分断が起きると特定の専門性に依って一見解決される課題が見えるようになりますが、失われる品質も多いことを認識するべきでしょう。
活きるデザインシステム
コードを書くデザイナーはデザインシステムの核心かもしれません。デザイナー自身が、デザインシステムが仕組みとしての “システム” 足るための重要な歯車になり得るのです。デザインシステムの元となるコンポーネントライブラリやドキュメントは手を動かしさえすれば作れます。しかし実際に機能し、活きたコンポーネントやドキュメントを作り続けるためには、利用と還元という単純なサイクルを回し続けないといけません（参考： SmartHR UI を中心としたエコシステムのすすめ）。
利用と還元のサイクルに入る前にまず「作る」があります。作れば何でもいいわけではなく、できるだけ良いものを作ると利用に繋げやすく、後のサイクルの回りやすさに繋がります。横断したプロダクトの振る舞いを理解した上で、特定プロダクトの作りも理解した人が居ないと、利用者にも開発者にもどちらにも “良い” コンポーネントは作れないでしょう。横断した視野を持たないエンジニアは早すぎる抽象化を生むかもしれないし、コードを理解しないデザイナーの作る Figma は文字通り絵に描いた餅にしかならないかもしれません。
デザインシステムやドキュメントというものは基本的に風化していきます。組織規模が大きくなればなるほど、その存在は「誰かがやっている何か」となり関心は薄れていきます。OKR は組織ツリー上に流れ、眼の前のプロダクトに集中すれば全体の成果に繋がっていきます。プロダクトで起きた問題は、プロダクトの中で解決されてしまうでしょう。
特定のプロダクトで発生した課題は、別のプロダクトでも発生する可能性があります。たった1行の改善が全プロダクトを救う可能性もあります。全社で最短距離で遠くに行くためには、組織構造を越えて、プロダクト全般に貢献するデザインとエンジニアリングが不可分であると理解した人が必要なのです。
今年 SmartHR UI ではマルチプロダクト戦略に沿って、内部的な技術刷新に取り掛かりました。これはプロダクトデザイナーとしてグループ会社やサードパーティ開発での課題、開発環境に起因した課題などを肌で感じていたためでした。問題提起から技術選定、技術基盤の構築、技術刷新に依る実装と、コードを書かないとできない SmartHR UI というプロダクトの “デザイン” ができたと思います。
課題と今後の動き
ここまでほぼ私個人にやや属人した話をしてきたので、いち従業員として組織への貢献を考えていきます。SmartHR のプロダクトデザイナーは間違いなく開発を理解したプロダクト開発者の一員ですが、開発ハンドオフのない世界やコードで貢献する世界を確立している人はほとんど居ません。まだまだスタートアップとして貪欲にプロダクトを成長させ続けるために、「早く」「質の良い」プロダクトを提供するのは我々プロダクト開発者の使命です。
いま見えている課題としては、SmartHR UI やデザインシステムがあるんだからもっと早く作れるじゃろう? という「生産性」、プロダクトを横断した集合知や相乗効果を作れていない「属人性」、本当にいいものが作れているのか? という「品質」などがあります。
生産性はすべてに関わる
課題ごとにまとめたいところでしたが、生産性はすべての課題に関連しそうです。
プロダクト開発者の一員としてスクラムにこそ入り込めていますが、まだまだ中間成果物であるデザインデータを介したコミュニケーションが多く見受けられます。半端にハンドオフした結果、実装に width: 242px などいうマジックナンバーが発生していることもあります。余計な労力を生み、時間を失ってしまうため、できる限りハンドオフが発生しない状況を作ることは「生産性の向上」に繋がるでしょう。
React コンポーネントライブラリの SmartHR UI とプロダクションコードの中で使われる SmartHR UI、そして Figma ファイルの SmartHR UI はそれぞれ別々の人が別々の関心で関わっています。一見同じ SmartHR UI を指していても、その理解や解像度はそれぞれ異なります。まずはその解像度を揃え、前提知識を補足し、少しでも溝を小さくできれば、開発コミュニケーションコストが下がり、より効率的にプロダクトを作っていけます。具体的には、コンポーネント一つ一つのドキュメント拡充、プロダクトデザイナーのコンポーネント理解、UI 実装に関わるプロダクト開発者へのコンポーネント理解、コンポーネントや画面を作る上で通底する概念の理解などを推し進めていきたいです。すべてをドキュメントや講義を通して伝えるのは無理そうなので、全プロダクトを行脚していくくらいの気持ちです。
また、20個を超える全プロダクト（加えてグループ会社2社でも使われています）で使われているコンポーネントライブラリですが、デザインシステムが活きているか、効いているかは別の問題です。デザインシステムの浸透率を計測したことはありませんが、プロダクトデザイナーの利用率ですら怪しいのが現状です。中長期的に見て、大きくなり続ける組織の中で「早く」「質の良い」プロダクトを量産するためにはデザインシステムの活用（利用と還元のサイクル）が必要でしょう。各プロダクトで “ちゃんと使えてる” 状態を作れれば、もう利用と還元のサイクルは回り始めたも同然です。プロダクトで発生した課題をデザインシステムで解決し、デザインシステムを通してプロダクトに還元する。そのサイクルの数も、デザインシステムの質も複利のように増え続けていくでしょう。
属人性を下げていくことは「生産性」にも、全体の「品質」にも繋がっていくのです。エンジニアではなくプロダクトデザイナーがコンポーネントライブラリ（コードを含む）やデザインシステムに一番詳しい存在であればプロダクト開発は円滑に進むのではないか、という感覚もあるので、実証しに行きたいです。
コードを書くことがすべての課題を解決するわけではない
あらゆることに言えてしまいますが、万能な解決策などありません。コードを書くことやデザインとエンジニアリングが不可分であると理解することがもたらす影響について書いてきましたが、それだけですべて解決するはずもありません。リサーチやデザインツールを使った高速な試行錯誤も同期的なレビューの仕組みも、何が欠けても「早く」「質の良い」プロダクトは作れないのです。
デザインをデザイナーのものにしてしまう勿体なさと同じように、コードをエンジニアのものにしてしまう勿体なさを伝えたかったのです。
終わりに
デザイナーがコードを書くことによる恩恵を書いてみましたが、これはあくまで私の体験が元であり、SmartHR という下駄を履いた状態です。SmartHR という環境がデザイナーだエンジニアだと職能や役割で評価しない体制や、コードを書くデザイナーへの理解や本質的なプロダクト作りを目指しているから実現しているとも考えられるのです。
コべき論は「デザイナーは」と大きな主語で個人に向けて放たれます。冒頭でも少し触れましたが、本当にその責任は個人にあるのでしょうか。もちろん責任の一端は個人にもあります。しかしハンドオフが発生するような開発体制を整えているのはチームであり、組織でしょう。
ということで、私の新コべき論は「デザイナーはコーディングできるといいが、みな開発者の一員なので開発への理解をするべきである。また、開発者を取り巻く環境（ハンドオフが生まれる環境を含め）は組織の課題である。」として締めたいと思います。我々はデザインだエンジニアリングだ、スクラムだ、ダブルダイアモンドだ、などと分断している場合ではないのです。一人の “プロダクト開発者” として共に歴史に残るプロダクトを作ろうじゃありませんか!