デザインは軽視するには重要すぎる
大竹雅登氏（以下、大竹）：はじめまして。さっそく始めさせていただきたいと思います。dely株式会社の大竹と申します。
いまCTOとして、活動させていただいております。
kurashiruというレシピ動画サービスを運営してる会社なんですが、kurashiruを知っている方、挙手をお願いいたします。
（会場挙手）
では、サービスの説明は割愛させていただきます（笑）。レシピ動画サービスをやっております。
今日はセンセーショナルなタイトルを付けさせていただいたのですが、ディスらないでください。これは有名な言葉のもじりです。「デザインは軽視するには重要すぎる」という話です。
大きく3つ、3構成でお話します。
自分が考えるデザイン組織の定義と、デザインの領域、カバー領域と、デザイン知見共有方法について、ざっくりお話できればなと思います。
まず1個目、僕の定義ですね。デザイン組織とは、デザインに短期的・一時的ではなく、長期的・継続的にコミットするチームのことをデザイン組織と呼ぶ、と僕は思っております。
デザインに長期的・継続的にコミットすることが重要な理由なんですが、「デザイン負債」という概念があります。
日本ではあまり言われていないかもしれませんが、「技術的負債」という言葉を聞いたことある方いますか？
（会場挙手）
ちょっといますね。そのデザイン版だと思っていただければいいです。何かというと、一言で言うと一貫性がプロダクトのなかで欠如するような状態のことを、「負債がたまっている」と表現します。
これは僕が勝手に作ったグラフなんですが、一貫性のなかに2つの軸があって、ビジュアルかファンクション、見た目か機能かというところと、インターナルとエクスターナル、内部的なものなのか外部的なものなのかというところでマトリックスに落とし込んで、今日は2通りで考えたいと思います。
内部的一貫性とは何か
まずは、内部的一貫性についてです。
これは何かというと、これは海外のブログから持ってきた例ですが、モーダル画面が日を追うごとにいろいろ改善されるんですが、すべてが一括で改善されなかったり、とりあえずABテストしてみたみたいな感じで、どんどん残っていって条件分岐がえげつないことになると。
ユーザーから見ると、なんかモーダルがいっぱいあると。ここに一貫性がない。きっと自分のサービスのなかで別々の存在、同じ機能なのに別々の見た目をしてるとか、そういった内部的な一貫性がないという状況になってしまいます。
例えばボタンだったら、最初は四角に角丸なしのボタンだったり、ドットが付いてたりとか、ボタンのABテストもするだろうし、デザインが変わるということもあると思うんですが、そこもなかなかメンテナンスできなかったりします。
これはある程度しょうがないかなと思っていて、技術的負債と一緒で、それを解消していくという発想が必要なんじゃないかなと思ってます。
1つは、デザイン組織の役割は、デザインのリファクタリングをちゃんとやりましょう、というところかと思います。ですので、新機能の開発だけじゃないかなと思ってます。
1つは、リリース初期は全部整合性が取れてるような構造になっていますが、1ヶ所改善してみました。
そしてそれに紐付いて改善していったら、なんだか整合性が取れてないと。
これ、ちょっと見にくいんですが、緑色と赤色のところで、ぜんぜん違うデザインの考え方で設計されてる、みたいなことが起こりうると思うので、これをパチッと1つの設計のもとにリファクタリングするのが、デザイナーとして、デザイン組織として重要かなと思っております。
デザイントレンドをキャッチアップする
もう1個が外部的なものなんですが、こちらはデザイン組織の役割として、デザイントレンドをキャッチアップしましょう。
例えばこれを見た時に、「ちょっと古くさいな」って思う人は、感覚的にもう知っていると思います。
これはiOSの昔のデザインの設計で、スキューモーフィズムという立体感を出して、物理的なものに見せるというデザインですが、いまこんなデザインのアプリがあったら、「ちょっとダサいな」と、「古いな」と思うと思います。それを気付かないとヤバいよねと。
こんなにわかりやすくなくても、もっといっぱいあります。例えば、フラットデザインだったり、それ以外にもいろんな要素あると思いますが、このようにキャッチアップしていかないと、自社のアプリがこう思われてしまいます。そこにコミットするのがデザイン組織です。
デザイン領域はどこまでカバーすべきか？
もう1つ、デザインの領域をどこまでカバーするべきか考えてみました。ちょっと詳細は省きますがうちは実装フェーズとデザインフェーズで分けていて、上のほうで仮説検証を回すようにしてるんですよね。
デザインの領域というのは、この上のところかなと思っています。
デザインフェーズでどんな課題なのかという検証、プロトタイプを回すところまでやります。
あとは実装フェーズでピクセル単位のデザインをする、スケッチレベルでデザインする、というところまでがデザイナーの役割で、ここは切り分けないほうが良いかなと個人的には思っています。なので、デザイン組織で人数をちゃんとカバーして、横断的に見られるようにしたほうが良いんじゃないかと思っています。
実際になにかの施策をやる時、課題の事実があって、仮説があって、それに対する解決策があると思います。
それを自分たちで定義して、「どこを改善していきましょう？」というのを考えていくことが必要かなと思っています。ここまでがデザイナーの領域。だから、ビジュアルを作るだけがデザイナーの領域なのではなく、課題発見からがデザイナーの領域かなと思ってます。
あと、しっかりユーザーテストをしていきます。うちだと、新機能やリリースする前のデザインフェーズは、しっかり動画まで撮って、後から振り返って、ちょっとでも細かいところを見て、どんなところにデザイン的なボトルネックがあったのかを検証するフェーズを設けています、そこまでもデザイナーの領域かなと思ってます。
デザインの知見の共有
デザインの知見の共有では、うちはdely.designというドメインでデザインブログを運営してるんですが、こういうところにしっかり書いていきましょう。
テックブログってけっこうあると思います。ですが、デザインブログはあんまり多くありません。なぜやらなくければいけないかというと、知見の共有が必要です。それは社内に対しても必要だし、社外に対しても必要だなと思っていて。とくに社内だったら、「うちはこういうデザイン設計で考えてるんだよね」というのを、再確認する意味があるかなと思います。
こちらが、いままで書いたなかで一番バズりましたけど、このくらいまでいくと、会社のブランディングとしても効果的かなと思っています。これは自分たちのおさらいという意味と、社外で「こんなことやってるんだ」ということをして、新しく採用にもつながるかなと思うので、ここでしっかり組織化していくというところは、採用としてもつながっていくかなと思ってます。
デザイン組織の定義とは
最後にまとめです。デザイン組織の作り方ということで何が一番重要なのかと思った時に、なぜそんなものを作らなければいけないのかというところに対して、説得力のある理由を説明できる、というところが一番だと思います。
いまって、「なんでエンジニアリング組織が必要なんですか？」と言われることはそんなに多くないと思います。でも、「なんでデザイン組織が必要なんですか？」と言われることって、それなりにあると思うんです。
それは、なぜ必要なのかパブリックに理解されていないからだと思います。こういう感じで自分たちでしっかり定義して、なぜこれが必要で、しっかり成果も出てるよね、ということを定義できるようにしたほうが良いんじゃないかと思います。
まとめると、デザイン組織の定義としては、一貫性をメンテナンスすることだと思っています。デザインの領域としては、上流工程から全部コミットしてやる。デザインの知見の共有は、テックブログだけでなくデザインブログも運営して発信していきましょう、というのが僕のまとめです。
「Design is important for success！」。成功するためにはしっかりとしたデザインとデザイン組織が必要です。ありがとうございました。
