デジタルプロダクトを作るデザイナーとしての知識の接続

## この記事の概要

私は事業会社にて UI デザイナーとして働いています。

デザイナーとしてデザインのことだけを考えるよりも、様々な知識を接続してサービス全体を考えた方が、発揮できる価値が大きいと思っています。

現時点で私がどんなことを考えているかを記事にしてみました。

## 全体像

```mermaid
graph TB
  Domain["ドメインの知識"] --> Modeled_Product(["モデル化されたプロダクト"])
  UML["UMLなどの知識"] --> Modeled_Product
  UI_Design["UI デザインの知識"] --> Mockup(["プロダクトのモックアップ"])
  Modeled_Product --> Mockup
  Modeled_Product --> Entity(["無形資産として扱うに値するエンティティ"])
  BS["B/S的な知識"] --> Entity
  Mockup --> Actual_Product(["実際に操作できるプロダクト"])
  Coding["実装の知識"] --> Actual_Product
  Product_Management["プロダクトマネジメントの知識"] --> Improvement(["プロダクトの改善案"])
  Actual_Product --> Improvement
  Improvement --> Shot(["ショットの売上"])
  Analysis["分析の知識"] --> Stock(["ストックの売上"])
  Improvement --> Stock
  Organizational_Management["組織マネジメントの知識"] --> Improvement
  Entity --> Growth_Cycle(["モデル化されたグロースサイクル"])
  Growth_Cycle --> Stock
  Product_Management --> Growth_Cycle
  PL["P/L的な知識"] --> Shot
```

書き出してみたら自分でもよく分からなくなってきています。
まだあまり整理できていない証拠なのかもしれません。

基本的な構造は以下のどちらかです。

- ある知識 + 別の知識 = 成果物
- ある知識 + ある成果物 = 別の成果物

## ドメインの知識 + UMLなどの知識

ドメインの知識がないままで良いものづくりはできません。
事業領域、顧客、独自の商慣習など、知らないと土俵に立てないことも多くあります。

上記の知識を知れたとしても、関係性が混沌としたままでは上手くプロダクトに落とし込めません。
どんな要素がどんな構造になっているかを整理するための知識も必要です。

2 つを組み合わせることで、モデル化されたプロダクトを得られます。
この時点では見た目に関する成果物はきっと 0 で、クラス図や ER 図などがあるくらいでしょう。

（逆に、見た目に関するリファレンスや、欲しい機能を並べたリストから作ってしまっている場合、価値発揮しづらいと思います。）

## UI デザインの知識 + 実装の知識

上記のように、デジタルプロダクトを作る際は要件や構造が重要です。

そのため 5 段階モデルでいう表層に関する知識・テクニックだけがあっても出来ることは限られています。

実際のデータの構造やエンティティ同士の関係を理解しながら、どう触るとどう動くのかを加味してものを作る必要があります。

厳し目な言い方をすれば、Figma データなどはあくまで中間生成物であり、ここに膨大な時間をかけたとて顧客には何の価値も提供できません。

動くもの・触れるものを作るためにはどんな準備が必要なのかを常に念頭に置きます。

## モデル化されたプロダクト + B/S的な知識

プロダクトを ER 図などとして整理できると、自ずから「無形資産[^1]として扱うに値するエンティティ」が見えてきます。

[^1]: 本来の意味の無形資産よりも少し拡大したニュアンスで使っています。

例えば Qiita であれば投稿された記事は資産といえます。
記事の数や質が非常に重要であるとしてマークし、組織全体で認識しておく必要があります。

資産をどう活かして収益を作るかが重要なのですが、デジタルプロダクトだとこの思考が抜けがちだと思います。

## プロダクトマネジメントの知識 + 無形資産として扱うに値するエンティティ

無形資産として扱うに値するエンティティが分かれば、それを中心としてグロースサイクルを定義することができます。

なんでもかんでも伸ばせれば良いですが、現実は時間も人手も限られています。
どこが一番のポイントなのかを見極めるにあたり、プロダクトマネジメントの知識以外にも、B/S 的な知識は役立つはずです。

なお、グロースサイクル自体の説明は、他に良い記事がたくさんあるためそちらを紹介します。

https://note.jp/n/ne0b658deeac3

https://note.com/ku_ni_29/n/na5dcb441e8d4

## 実際に操作できるプロダクト + プロダクトマネジメントの知識 + 組織マネジメントの知識

実際に操作できるものが出来上がっても、それで終わりではないのがデジタルプロダクトです。

改善をするにあたり、プロダクトマネジメントの知識と、組織マネジメントの知識と、両方が必要です。

結局は人が集まって作るのですから、理論上正しくても感情的に受け入れづらいとか、長期的に見て成長が見込めない采配とか、そういうのではいけません。

チーム編成、採用や登用の基準、評価の仕組みなどなど、事業状況も踏まえつつアップデートする必要があります。

## プロダクトの改善案 + 分析の知識

グロースサイクルを上手くまわし、効果的な事業成長を実現するためには、分析の知識も必要です。

予め測定可能なように施策を準備することや、施策実施後に統計的に誤りがないように確認をすることなど、多岐に渡ります。

デジタルマーケティングの世界では A/B テストでもって成果の有無を測っていることが多いと思います。
しかし、ランダム化比較試験としてどれだけの意味があるやり方をできているのか？などは検討する余地があるでしょう。

## プロダクトの改善案 + P/L 的な知識

資産を上手く回転させて収益を高めるのが理想ではありますが、外部要因などを含め、突発的にトップラインを伸ばさなければならない場面もあるでしょう。

そういった際、プロモーションやセールス的な観点で考える必要もあります。

ものづくりに携わる人は、多かれ少なかれ「良いものは何もしないでも売れる」「Sales-Led Growth より Product-Led Growth」といった考えを持っている人が多いと思います。

それはそれで気持ちは分かりますが、時と場合によってはそうも言ってられません。
今、事業のために一番何をすべきか？を考え、必要であれば P/L 的なアクションに倒すことも必要でしょう。

（もちろん、それが常態化しないようにすることまでセットで考えたいですが）

## 気持ちのまとめ

個人的な感情だけで言えば「好きなものだけを好きなように作っていたい！」と思う日も結構あります。

ただそれはそれとして、ビジネスパーソンとして事業を成長させるためにはどうしたら良いか？と考えていたら、こういった思考になっていました。

この記事を何年後かに見返したら「こんな狭い範囲しか見ないでよく語ったもんだな」と思えるようになっていたいです。