開発者としてのデザインとの関わり方

背景

Webエンジニアになり約5年が経ちましたが、これまでさまざまなWebのプロダクトに携わることができました。アプリケーションだったり静的サイトだったり、大きいもの小さいもの、いろんなものがありました。

ただその中で共通していたのは、各プロジェクトには専属デザイナーさんがいて、デザイン領域はデザイナーさんが行っていたということです。魔法のように素晴らしいデザインが出来上がっていき、その成果物を我々開発者が実装するという体制でした。要件や仕様もある程度固まっていて、残り20%程度を開発フェーズで詰めていけば良いようなプロジェクトが多かったです。

一方、今担当しているプロジェクトではデザイナーさんはいません。開発者自身がデザインし、実装し、リリースします。そのため開発者としてデザインとの関わり方が大きく変わりました。

このような背景があり、今回デザインとの関わり方というテーマでこの記事を書こうと思いました

デザインの定義

まずデザインと一言で言っても、いろんな領域、解釈があると思います。グラフィックデザイン、プロダクトデザイン、サービスデザイン、UIデザイン、UXデザインなどなど。
自分もこれまではデザインという言葉を特に考えることはなく、「ユーザーがプロダクトを使う際の体験をよくするためのもの」程度の解釈でいました。

この記事ではデザインという言葉を 「モノに意味を与えるもの」 と広く定義し利用したいと思います。これはロベルト・ベルガンティが著書のデザイン・ドリブン・イノベーションで示しているデザインの定義です。
言い換えると、ユーザーはなぜそのサービスやプロダクトを使うのか、それは誰にとってなぜ嬉しいのか、その価値とは何かを考えることです。

伝えたいこと

この記事で言いたいことを先にお伝えしておきます。

それは、ユーザーにとって価値あるものを考え、ソリューションを導き出し(デザイン)、それを実装し(開発)、ユーザに提供するところまでを一貫して行うこと。そして実際そのプロダクトを使ってユーザーが喜んでいる姿を見ることができることは、とにかく楽しいってことです。

大きなプロダクトになると、開発とデザインが分業していることが多いと思いますが、
なぜこのデザインカンプや要件になったのだろう、このプロダクトは誰に対してどのような嬉しいことがあるのだろうと考えると、開発者としても違う面白さが出てくると思います。

なので興味があれば開発者としての枠にとらわれず、デザインも一緒に学んでいきましょうと言いたいのです。

スクラムとデザイン

実際今のプロジェクトでどのようなデザインとの関わり方をしているのかをお話できればと思います。

まず今関わっているプロジェクトではスクラムを導入しています。
そのスクラムとデザインの関係性を簡単に説明しておくと、それぞれ役割が明確に分かれています。スクラムを導入すればデザインも自然といい感じにできるなんてことはありません。
スクラムの詳細の説明は割愛しますが、主にHowの部分、つまりどのようにモノづくりしていくかにフォーカスしているのがスクラムです。一方でWhyやWhatの部分、つまりなぜそれを作るのか、何を作るのかを定義するのがデザインの領域だと言えます。

スクラムの流れは大方以下のようなプロセスになります。

1. プロダクトバックログアイテム(PBI)としてプロダクトに必要なリストが存在します。
2. プロダクトバックログリファイメントでそのPBIの優先順位を決めたり、適切な粒度に分割したり、検証方法を定義したりします
3. スプリントプランニングで開発者が実行できるタスクの粒度までPBIを分割し計画します
4. それをスプリントで実際に実行しプロダクトをインクリメントしていきます

※PBIについて: https://www.ryuzee.com/contents/blog/14564

注目すべきはプロダクトバックログアイテム(PBI)をどうやって作るかは、スクラムの仕組みには入っていないということです。そこは別のプロセスとして行う必要があります。
そしてそのプロダクトバックログアイテム(PBI)を作る行為がデザインにあたるところです。

スクラムチーム内でデザイナーさんが存在する場合は、デザイナーさんが主にPBIを作ることになるでしょう。しかし今のスクラムチームでは、開発者がスプリントと並行してデザインも行っています。
ドメイン知識の習得やユーザーへのヒアリング、プロダクトの意味やなぜ嬉しいかについての熟考など、複数のデザインアプローチを利用して、PBIを開発者自身で作っていきます。

開発者がデザインに関わるメリット

デザインを開発者自身も行うことのメリットと思われる点をいくつか挙げておきます。

①自分たちが作っているものへの理解度がかなり上がる

これは要件や仕様の理解にとどまらず、その上にあるwhyの部分をはっきりと理解できるということです。デザインと開発が分業されていると、そうしたことは中々難しく、果たして今作ってるものは何なのか分からなくなることが少なくないと思います。

②意思決定が早くできる

例えば実装の都合上、難しいことが出てきた際に、工数を多くかけてでも実装するべきなのか、それともそこは手を抜いて良いところなのか、はたまた何か代替ができるものはないかということを開発者が即座に判断でき提案できます。

②デザインとエンジニアリングの振り子が高速に回せる

PBI作成時において、やりたいことを考えることと実現可能性を確かめること(技術検証など)を同時にできたり、開発してる最中に思いついた良いアイデアをすぐに提案できたりします。

デザインアプローチ

デザインを論じられるほど知識がないので、今のプロジェクトで行っている2つのアプローチ方法について軽く紹介します。

一つ目がデザイン思考です。これは問題解決のためのデザインとも言われています。主に既存のプロダクトに対してユーザーのヒヤリングを通じて課題を抽出し、ソリューションを提供していくアプローチです。このアプローチを通して生まれたPBIは、既存のプロダクトの課題を解決するためのPBIになります。

2つ目にクリティカルデザインやデザイン・ドリブン・イノベーションと言われるものです。これはプロダクトに新しい意味を与えるアプローチで、ユーザーがプロダクトを使う理由や意味を問い、howではなくwhyから考えるアプローチ方法です。人々が必要とするものではなく、新たな「意味」を作り手から提示するという特徴があります。

デザインエンジニア

上記のようにデザイン行うエンジニアをデザインエンジニアというそうです。

これまでエンジニアはエンジニアリングのエキスパート、デザインはデザインのエキスパートで、分業してお互い得意なことをやっていくものだと思ってましたが、
デザインとエンジニアリング両方やってしまう方々がいるのだということを知って、素直に面白そう！カッコ良い！と思いました。今後のキャリアとしてとても興味が湧きました。

最後に

色々書きましたが、自分自身スクラムやデザインとしっかり向き合ったのはここ3ヶ月ぐらいでして、まだまだ駆け出しです。デザインに関する知見や技術、デザインアプローチの方法、またエンジニアとしての知識も両方学んで行って、いつしか一人前のデザインエンジニアになれるようにやっていこうと思います。