情報設計のためのヒント

この記事は 弁護士ドットコム Advent Calendar 2019 の23日目の記事です。

昨日は @NaokiTsuchiya さんの ISO704 Terminology work — Principles and methodsとドメインモデルという記事で、めっちゃ勉強になりました。今日の記事もモデリングに近い話ですが、国際標準よりドメスティックな取り組みの話です。

はじめに

サービスを作るとき、みなさんは何からはじめるでしょうか？
言語の選定？フレームワークの選定？データベース設計？

当然ですが、データベース設計は「なにを作るか？」がないと作れませんよね。
これらはシステムを作る際に重要なのですが、それよりも重要なのは「ユーザーは普段どういう情報処理をしているのか？」ということではないでしょうか。

MVCとはなにかという題で話した際、中華料理店での複写式伝票を使った情報処理のお話をネタにしたのですが、ぼくにとってはこうした観察は空論ではなくて、普段の実践と関連していたりします。今回はそういったことを書いてみようと思います。

弁護士向けの情報管理サービスをつくる

仮に、じぶんに降ってきたお題が見出しのようなものだとします(いや、仮の話です)。

これだけだとあまりに考えるための取っ掛かりがなく、どうしたものかと思うのですが、ちょっとインターネットで調べてみましょう。弁護士の使用している手帳についてという記事がありました。弁護士には「弁護士日誌」「訟廷日誌」という弁護士用の手帳があり、これらを使っている人がそれなりに多いようです。

弊社は弁護士を対象としたサービスを作っていますし、弁護士有資格者が何名かいますので、幸いにも弁護士日誌の実物がゲットできました。実物はこんな感じです。

弁護士日誌

手帳のコンテンツは、大まかには事件表(民事/刑事)とカレンダーの２つです。
この時点でちょっと面白いなと思ったのですが、事件表には「民事」と「刑事」があるのですね。なるほど。
中身をちょっと見てみましょう。

事件表(民事)

民事の場合の事件表はこんな感じです。

語彙は以下の通りです。

• 依頼者
• 相手方
• 裁判所
• 部係
• 法廷
• 事件番号
• 事件名

「依頼者名」がいちばん左に来ていて、インデックスとしての役割を果たしています。

事件表(刑事)

刑事の場合の事件表はこんな感じです。

語彙は次の通り。

• 被告人
• 罪名
• 事件番号
• 裁判所
• 部係
• 法廷
• 勾留年月日
• 起訴年月日

一番左に来ているのが「被告人」になっています。用語は民事の場合と違っていても実は情報の構造は同じで、「被告人」とは畢竟弁護士にとって依頼者のことです。これも民事の場合とおなじくインデックスとしての役割を持ちます。

民事と刑事で比較してみる

刑事の事件表の用語はすべて裁判の用語です。
民事の場合は裁判に至るかどうかは状況次第なのに対し、刑事の場合はほとんど訴訟前提になっていると思われます。「被告人」は訴えを起こされた方の人です。民事の場合、弁護士にとっての依頼者は被告にも原告にもなりえますが、刑事の場合は原告が検察と決まっているので依頼者は必ず被告人です。なかなか面白いですね。
もう少し分析してみると、民事の左から二番目のカラムは「相手方」で刑事の二番目のカラムは「罪名」です。これは民事と刑事の関心事の差ですね。民事の場合は相手方との交渉なりが多いですが、刑事の場合は訴えられている罪が何か、に関心がある。

カレンダー

カレンダーは通常のカレンダーと似ているのですが、弁護士向けらしく以下の様な項目が並んでいます。

• 時:分
• 裁判所
• 部係/法廷
• 依頼者
• 相手方
• 摘要

主に裁判の日時を書き込む用途になっています。
また、土日には裁判所開廷しないため、土日欄は小さかったりします。

検討してみる

弁護士が業務に利用している手帳を検討してみました。次のようなことがわかります。

• 事件表はCRM的な機能をもっている。依頼者名をインデックスとして使う。
• 事件表では重要な順でカラムが並べられている。
• 刑事と民事で業務の構造が違う。
• カレンダーは時系列情報。依頼者情報と紐付けるためには何かしらの管理番号が必要。

これらを弁護士はどうやって使っているのか？ということについても、ブログなどにいくつか記載があります。使っていない人ももちろんいますが、この手帳には業務理解が表現されていて、よくできたデザインになっていると思います。

検討したものをどう使うの？

先日、一緒に仕事をしているデザイナーがこんな発表をしていました。

新規サービスにおける デザイナーとエンジニアの関わり方

このスライドにこんな資料があります。

道具の分析は、ユーザーが普段理解しているであろう情報についての共通理解をもたらします。
この「情報」は、UIのコンポーネント名やテーブル名、チーム内での議論など、開発のあらゆる局面で利用できます。つまりこれはチーム内でのユビキタス言語の基礎として役に立ちます。

エリック・エヴァンスは、ユビキタス言語について、ピジン語を引き合いに出して次のように説明しています。

例えば、異なる言語で育った人々が貿易のために集まった時、共通言語がないと、ピジン語(通商用混合語)と呼ばれる言語を考案する。ピジン語は、話者が本来使用している言語ほど包括的ではないが、さしあたりの作業には適している。

(第一部第二章「コミュニケーションと言語の使い方」のなかの「声に出してモデリングする」の箇所より)

道具がもっている情報構造を分析してみることは、ユビキタス言語のためのたたき台になります。これらをもとにチーム内で議論を繰り返しているうちに、チーム内で気づけばピジン語のようなものが形成されていくでしょう。

まとめ

ぼくは弁護士ではないので、このドメインについての知識がほとんどありません。サービス開発においてこういう状況はままあるのではないかと思います。
そういったときに、ユーザーが普段使っている道具は、ドメインについての多くの情報をもたらすと思います。

この手帳は、当然このままこれから作るサービスになるわけではありません。このままであればサービスを作る必要などないからです。しかし、「どういう語彙を拾ってくればよいか？」「ユーザーの業務はどうなっているか？」「コンピュータシステムに変換するときにどういう点に差がありそうか？」「サービスを作る際にどこを一捻りすればよいか？」などなど、多くのヒントをくれます。

「チームにドメインエキスパートがいないから、理想的なドメイン駆動設計にならない」ということをたまに聞きます。そんなときは、ユーザーが使っている道具を詳しく検討してみると、ドメインに立ち返ることができるかもしれません。