iOSエンジニアとして、クライアントワークを中心に従事しています。具体的には、アプリのグロース段階で企画や実装に携わったり、プロトタイプを作って検証チームに連携したり。最近はテクニカルディレクターとしてデザインフェーズからプロジェクトに参画し、デザイナーと相談をしながら実装作業を進めています。

私は自社プロダクトのエンジニアとして、オンラインホワイトボード『Strap』の開発設計を担当。特に、ホワイトボード上におけるコラボレーション機能の開発に携わっています。

「デザイン」という言葉には大きく2つの意味合いがあり、1つが「狭義のデザイン」です。みなさんがイメージしやすい“見た目を綺麗に整えること”や“スタイリングをすること”などが、狭義のデザインに当てはまります。

一方で当社が大切にしているのは「広義のデザイン」の視点です。見た目や表層的なデザインにとどまらない、本質的な課題解決やより良いユーザー体験の創出を目的としたデザインを指しています。

デザインという言葉自体にはさまざまな解釈がありますが、本質的には人が抱える課題に向き合い、解決していくプロセスがベースにありますよね。

そのような意味では、エンジニアリングも「広義のデザイン」の一種だと言えるかもしれません。エンジニアも日々の開発業務のなかで、ユーザーのどんな課題を解決したいのか、ユーザーにどういう感情を受け取ってもらいたいかを意識した設計を行っているはずですから。

はい。エンジニアが課題解決を行う際も、ユーザーが何に困っているのか、何を望んでいるのか、どうすれば喜んでもらえるかを思考する場面が多いのではないかと思います。それらの思考プロセスこそが、「デザインの視点」そのものだと考えています。

そうですね。お客様からヒアリングする、ニーズを調べる、使いやすい設計にする、組織がうまく回る仕組みを考える。人にとって、社会にとってプラスに働くアクションに対して「デザイン」という言葉をつけることで、曖昧な概念に対して共通言語が生まれるわけです。「デザイン」という言葉で議論できるようになると、デザイン業界に閉じてしまっている、広義のデザインに対して有効なノウハウを活用できるようになると思います。エンジニアが開発を進めるうえでは他職種との連携が不可欠ですから、プロジェクト内での認識をそろえるという点でも「デザインの視点」は有効だと思います。

やはり、デザインという言葉に対する解釈の違いが大きいと思います。英語の「Design」は広義の意味で解釈されることが多いのですが、日本語の「デザイン」は表層的な意味合いが強いですよね。

そう思います。余談ですが、先日参加したGoogle社のイベントで、Designという言葉が日本語訳ではすべて「設計」となっていたことに驚きました。まさに「広義のデザイン」を指していて、ここでは“デザイン＝設計”のニュアンスで使われているんだな、と。

人によって、または職種によって「デザイン」とするか「設計」とするか、温度差があるがゆえに認識がずれてしまうのかもしれません。当社では設計のプロセスも含めて「デザイン」と表現する傾向がありますが、まずはとらえ方のすり合わせを行う必要があると思います。

基本的に、エンジニアとデザイナーがよくコミュニケーションを取る文化がありますよね。

そうですね。例えば、2～3年前から「エンジニアオフィスアワー」という施策を打ち、職種の垣根を超えてエンジニアに相談できる体制を整えています。当社でクライアントワークを行うデザイナーは、グッドパッチ以外のエンジニアと連携する機会もあり、社外のエンジニアには聞きづらい専門的な知識などを質問されるケースも多いですね。

そのほかにも、エンジニア視点での「UIレビュー」や、エンジニアとデザイナーが同じ画面を見ながらリアルタイムにデザインを行う「ライブデザイン」など、1つのプロジェクトにおけるコミュニケーションの密度を高めることにも注力しています。

自社プロダクト事業に関しては、チームメンバーの入れ替わりが少ないため、最初のマインドセットやプロジェクトの目的など、共通認識を持ちながら開発しやすいという側面があります。だからこそ、エンジニアからデザイナーに対してデザイン面での提案を気軽にできますし、その逆のパターンもあります。互いに質問や相談をしやすい関係性が作られている点が特徴的ですね。

例えば『Strap』には、図形同士をコネクターでつなぐ機能があります。そのリニューアル開発の際に、エンジニアがユーザーからのフィードバック履歴を読んだり、ユースケースを整理するなど、広義のデザインの視点から関わりました。

そのうえで、まずはエンジニアがプロトタイプを作成し、デザイナーと相談しながら手触り感や体験を改善していくプロセスをとったんです。触り心地やユーザー体験などを直接数値や仕組みで調整できるのは、エンジニアならではの強みです。その結果、製品の品質が格段に高まり、ユーザーからも「使いやすい」という声をいただくことができました。

また、仮にデザイナーから開発難度の高い機能を提案されたとしても、デザイナーと同じ目線で「ユーザーに提供したい価値」を考えることができれば、期待する価値を維持したうえで開発難度の低い代案を提示できる可能性もあるんです。

同様に「狭義のデザイン」においても、エンジニアならではの強みが発揮できると考えています。例えば、iOS、Android、Webなどプラットフォームごとのお作法の違いはエンジニアのほうがよく理解しています。そのような知識を踏まえてデザイナーにデザイン上の問題点を伝えたり、代替案を提案したりなど、エンジニア側からアプローチするケースも多々ありますね。

正直、普段のものづくりの過程で学んでいった部分が大きいのですが、主に狭義のデザインに関しては「デザインの4大原則」の考え方を参考にしています。「近接」「整列」「対比」「反復」という4つの要素に基づく概念を学んだことで、UIフレームワークのコンポーネントの役割やプロパティの意味を深く理解したうえで、デザイナーの意図を汲んだ選択や実装ができるようになりました。特に『ノンデザイナーズ・デザイナーブック』という書籍は、狭義の「デザインの視点」を学ぶうえで役立ちました。

『ノンデザイナーズ・デザイナーブック』は私も読みました。ほかにも『インタフェースデザインの心理学』『UXデザインの法則』『なるほどデザイン』などの書籍は、学術的または論理的に説明されているため分かりやすく、個人的に参考になりました。

一方で広義の「デザインの視点」は、本を読んでステップどおりに行えばできるような、体系化されたものではありません。常に「使う人がどう感じるのか」という観点に立ちながら、意図を持って設計していくことが大切です。

特にエンジニアは製品の内部構造を知っているがゆえに、ユーザーにとって分かりにくいものであっても、分かりやすいと評価してしまう傾向があるように思うんです。内部構造を理解していない人にはどのように見えるのかを考える点でも、「デザインの視点」は有効なのではないでしょうか。

エンジニアのみなさんは、日常的に「開発者が開発しやすいように」「開発者が変わってもメンテナンスがしやすいように」といった目的でプログラムのアーキテクチャ設計を行っているはずです。それこそがまさに「デザインの視点」であり、目的の部分をユーザーに置き換えてみると、分かりやすいのではないかと思います。

広義の「デザインの視点」に関しては、どんな職種のビジネスパーソンにも必要な考え方だと思います。実際に当社はかねて「デザインの5段階モデル」をはじめ、イベントやカンファレンスでの登壇などを通じて、広義のデザインの視点について提唱していますし、あらゆる営みが実はデザインなのだという点を、これまで以上に発信していきたいですね。

エンジニアのみなさんも、例えばFigmaなどを使っても表現しきれない触り心地や、ユーザーの反応に意識を向けてみる。エンジニアが得意とする高速化などもユーザーの体験を良くする「デザイン」の1つですので、まずは身近な領域から取り組んでみるとよいのではないでしょうか。

生成AIの進化にともなって、手書きの絵からUIの実装コードを自動で書き出すなど、便利な機能に注目が集まるようになりました。多くのエンジニアからは“仕事が楽になる”という声もあがっているようですが、私個人としては、人間だからこそ工夫できる事柄があると思いますし、その楽しさをもっとたくさんの人に感じてもらいたいですね。

『Strap』の開発者としては、本プロダクトを通じて「デザインの視点」を活かしたチームを世の中に増やしていくことが目標です。というのも、『Strap』はただのオンラインホワイトボードツールではなく、業務プロセスや思考を整理・見える化し、情報資産としたうえで、それを活用してくためのプラットフォームだからです。

チームの全員が共通の目標に向け、同じものを見ながらコラボレーションをする。その過程で、デザインのプロセスの1つである「視覚化」を誰もが簡単に実践する。職種の垣根を超え、さまざまなビジネスパーソンのみなさんに気軽にデザインの体験をしてもらうことで、当社が考える「デザインの視点」の価値を届けていきたいなと思います。