「優れたデザインにとってコンセプトが重要な理由」を読みました

「優れたデザインにとってコンセプトが重要な理由」という本を読みました。面白かったので読書メモを残しておきます。

優れたデザインにとってコンセプトが重要な理由: 使いやすく安心なソフトウェアを作るために

コンセプトとは

この本では「コンセプト」を使ったソフトウェアデザインの方法を説明しています。ソフトウェアデザインの抽象度を以下の 3 段階に分類したときの、最も抽象度の高い 3 番目を「コンセプト」レベルのデザインとして定義しています。

1. 物理的：色、大きさ、レイアウト、タイプ、タッチ、音声

2. 言語的：アイコン、ラベル、ツール、ツールチップ、サイト構造

3. コンセプト：意味、アクション、データモデル、目的

この「コンセプト」は、D.A.ノーマンのいう概念モデル(Conceptual model)と同じもののようです。「誰のためのデザイン？」では、概念モデルが正しく伝わるように「アフォーダンス」や「シグニファイア」を活用しましょう、という話でしたが、概念モデルそのものをどう考えるか、についての説明はありませんでした。
その結果、概念モデルの重要性をみんなが認識していても、実務で扱うには抽象的過ぎて会話が空中戦になりがち、という問題があったように思います。

この本では、以下に紹介するコンセプトを形式的に記述する枠組みを提供することで、この問題を解決しようとしている、と解釈しました。

コンセプトの記述方法

コンセプトの定義は、以下の形式で記述します。クラス設計に似てますね。

• 名前（concept）

• 目的（purpose）

• 状態（state）

• アクション（actions）

• 操作の原則（operational principle）

例として、ToDo のコンセプトの定義は以下の用になります。

concept todo
purpose keep track of tasks
state
  done, pending: set Task
actions
  add (t: Task)
    when t not in done or pending
    add t to pending
  delete (t: Task)
    when t in done or pending
    remove t from done and pending
  complete (t: Task)
    when t in pending
    move t from pending to done
operational principle
  after add (t) untile delete (t) or complete (t), t in pending
  after complete (t) untile delete(t), t in done

これを見ると、ToDoのコンセプトは、以下のように読みとれます。

• todoコンセプトは、Taskを管理するのが目的である

• todoには、複数のTaskを束ねた、done、pending という2つの状態が存在する

• addというアクションは、あるTaskがdoneでもpendingの状態でもない時に、pending状態として追加する

• deleteというアクションは、あるTaskがdoneまたはpendingの状態である時に、doneまたはpending状態から削除する

• completeというアクションは、あるTaskがpendingの状態である時に、pendingからdoneへ移動する

• addしたtaskは、deleteまたはcompleteを行うまで、pendingの状態にある

• completeしたtaskは、deleteを行うまで、doneの状態にある

これにより、「ToDo」というコンセプトを、PMでもUXデザイナーでも認識ズレなく扱う事ができる、という寸法です！
一方、この記述方法によりプリミティブなコンセプトは定義できますが、実際のソフトウェアはもっと複雑に複数のコンセプトが絡まり合っています。
それを表現するために、「コンセプトの合成」と「コンセプトの依存関係図」というものがあります。

コンセプトの合成

複数のコンセプトは、アクション同期によって合成できます。
あるアクションが実行されたときに、連動して別のコンセプトのアクションが実行されるよ、というようなルール付けにより、複数のコンセプトを合成します。

例として、ToDoとLabelという2つのコンセプトを合成する例を挙げます。

まずLabelコンセプトを、複数のitemをlabelにより整理するもの、として定義します。itemに対して複数のlabel付けができたり、labelのついたitemを検索したりするコンセプトです。

concept label [Item]
purpose organize items into overlapping categories
state
  labels: Item -> set Label
actions
  affix (i: Item, l: Label)
    add l to the labels of i
  detach (i: Item, l: Label)
    remove l from the labels of i
  find (l: Label) : set Item
    return the items labeled with l
  clear (i: Item)
    remove item i with all its labels
operational principle
  after affix (i, l) and no detach (i, l), i in find (l)
  if no affix (i, l), or detach (i, l), i not in find (l)

この時点ではLabelコンセプトとToDoコンセプトは全くの無関係であり、独立しています。
このLabelコンセプトを使ってToDoコンセプトを整理する場合、以下のように記述します。

app todo-label
include
  todo
  label [todo.Task]
sync todo.delete (t)
  label.clear (t)

todoコンセプトとlabelコンセプトの自由合成の例。
黒矢印が同期。左側の○はユーザが可能な操作を表す。

これは以下のように読みとれます。

• todo-labelアプリは、todoとlabelのコンセプトを含む

• labelコンセプトのItemをtodoコンセプトのTask 型として実体化する（label [todo.Task]の部分）

• todo.deleteのアクションを行うと、それに同期（sync）してlabel.clearのアクションが実行される

これにより、todoとlabelコンセプトを連携したtodo-labelアプリの概念を表現できました！
英語で記述してるので専門用語のように見えるかもしれませんが、日本語で箇条書きしても良いと考えると、実際にはかなりシンプルにコンセプトを記述できると思います。

この例は「自由合成」と言われる合成方法になります。本の中ではさらに 2 つの合成方法について紹介されています。

• 自由合成：コンセプトは互いに独立して動作するが、複数アクションが同時に行われるように見える

• 協調合成：複数コンセプトが協調することで、新しい機能が提供される

• 相乗効果のある合成：複数コンセプトが密接に連携し、あるコンセプトが他のコンセプトの目的達成を助ける

コンセプトの依存関係図

コンセプトそのものは独立しており、他のコンセプトとは依存しません。
ですが、アプリケーション全体における役割として依存関係が表れます。

例として、チームでtodoを管理するアプリの依存関係図を書いてみました。

チームのtodo管理。役割（Role）によってtodoに対して可能な操作が異なる。

• 四角枠：コンセプト

• 太線四角枠：中心となるコンセプト

• 実線矢印：主要な依存。そのコンセプトを取り入れる理由が、矢印の先のコンセプトに依存する

• 破線：二次的な依存。そのコンセプトを取り入れるのに必須ではないが、付加的な理由付けになる。

これにより、どの概念が必須なのか、どの部分集合がどんな価値を提供するのか、等を可視化できます。また、アプリケーションについて説明する際には中心となるコンセプトから部分集合毎に説明すると、分かりやすく説明できます。

おわり

コンセプトを記述する枠組みについて紹介しました。この記述方法を使って概念モデルを具体化することで、チーム内のコミュニケーションが円滑になり、より良い情報設計やUI/UXデザインができそうです。

書籍の中ではさらに、コンセプトの原理（特異性や完全性など）や、身の回りのサービスを例にした具体例、設計例がたくさん紹介されておりとても勉強になります。いろんなサービスのコンセプトを分析して、みんなで共有しあうのも面白いかもしれないですね。

優れたデザインにとってコンセプトが重要な理由: 使いやすく安心なソフトウェアを作るために