toB SaaSでデザイナーが正しく「設計(Design)」するということ

株式会社HERPでデザイナーをしているオオカワラです。「HERP Hire」という採用プラットフォームを作っています。
toB SaaS領域でのデザインであり、どういうことをしているかなかなか表になりづらいのですが、今回はHERP社で現在大事にしている「正しく設計する」ということを少しお話させてください。

正しい「設計」とは何か

toB SaaSの領域でアプリケーションを作るということは非常に複雑で難しく、その難しさは作ろうとしているアプリケーションにまつわる業務フローが複雑かつ当事者としてインサイトを掴むことの困難さに起因します。そんな難しさがある中で、デザイナーとしてアプリケーションを正しく「設計」することはもちろん容易なことではありません。

では、デザイナーとして正しく「設計」するとはどういうことでしょうか？
結論からいうと「機能あるいはその集合に最適な意味を与え、高い解像度で表現する」ことだと私は思っています。

アプリケーションは大きくわけて「ユーザーインターフェース」とそれを表現する「コード」（「仕様」とも言える）から成立しています。実際に顧客へ提供するのは「ユーザーインターフェース」の部分であり、「ユーザーインターフェース」を通じて求める機能そして価値が届けられます。その中で「ユーザーインターフェース」が具体的にどう在り、どう振る舞うかについて規定しているのは「コード」であり、つまるところ「コード」は顧客へ届ける価値に対して大きな影響を与えると言えます。

「コード」がなぜ顧客へ届ける価値に対して大きな影響を与えるのか

例えば「顧客管理ツールにおいてタスク管理機能を作りたい」という要求が生まれたとします。このとき、

・タスクはタイトル・詳細・期日・担当者・Open/Close/Doneの状態を持つ
・タスクを一覧して管理することができる
・タスクの期日の1日前にリマインドされる

などというような「こうだったら便利そう」という振る舞いは誰でもパッと思いつきます。

そしてこのようなぼんやりとした「振る舞い」は、entityやusecaseといった曖昧さを一切許さない「コード」という形で表現されます。
「タスク」というentityが存在しpropertyとして「タイトル」「詳細」「期日」「担当者」「タスクの状態」「ID」を持っており、かつどのpropertyが必須/任意なのか、「タスクの状態」は正規化されたstateとして管理したいのか、そしてその必然性はあるのか。「タスクの期日の1日前にリマインドされる」ということに対して、「1日前」という部分だけでも「期日」の24時間前なのか「期日」の前の日のある任意の時刻なのかという厳密さをusecaseとして表現しなくてはいけません。

ある一言で表現された「振る舞い」でも、その中で出現する概念や動きをどう捉えてentityやusecaseとして切り出すかはいくらでもパターンがあり、パターンによって実際に得られる機能および体験、即ち価値は全く違うものとなりうるのです。だからこそ「コード」は顧客へ届ける価値に対して大きな影響を与えると言えるのです。

デザイナーに必要な役割

先ほどパターンがあると述べたように、entityやusecaseの設計は、業務フローや今後どのようなアプリケーションにしたいか（言わばコンセプト）に依存するため決まった正解はありません。正解はない中で非常に難しいですが、業務フローやコンセプトをベースとして要求・要望の正体を見抜いて、どのようなことに概念として意味を与えてあげればいいのか、そしてどう振る舞えばいいのか考えること（ここでの考えるはentityやusecaseまで表現することも含む）はデザイナーができるべき仕事です。

実際にコードとして表現し書く専門性を持つということでこの「設計」をエンジニアに丸投げされることも多々ですが、機能や体験を規定する以上デザイナーもentityやusecaseといったレイヤーでエンジニアと同等の解像度で議論でき、最適解を全員で探していかなければならないはずです。

HERPでのデザイナーとしてのチャレンジ

そしてこれは私も含めた話ではありますが、このような正しい「設計」をすることができるデザイナーは本当になかなかいません。私も最近ようやく意識できるようになりはじめたくらいです。そして、いまHERPでは正しく「設計」していくことにチャレンジしています。

機能(あるいは概念)の定義と振る舞いに対する曖昧さを許さないようにentityやusecaseベースでの議論をし、意図しない体験や仕様を生み出すことを防いだりコーナーケースをよりクリアにしやすくしたり、機能の進化を見据えた設計にして中長期的なスパンでの実装のしやすさとそれに伴う価値提供のコストパフォーマンスの最大化ができないか探っています。

このように正しく「設計」するということに興味があり、一緒にチャレンジしていける方を現在HERPでは探しています。もしよろしかったらまずはお話でもさせてください（TwitterでDMするなり以下のページから応募ください）。

また「設計」に関する具体的な方法論やポイントに関してはノウハウが溜まったらまとめようかなと思っています。
みんなで絶対にいいプロダクトを作っていきましょうね。