そのデータは本当に必要?
ものレボのCTO森松です。
会議にデータを持ち込んで発表するときに、とにかく数字が並んだものを持っていく方。
そのデータは、本当に整理ができてますか?
技術的な知識を交えて、データ整理の大事なポイントをご紹介します。
- 構造化しよう
- プロセスを洗い出そう
- 総合評価する
構造化しよう
理解が難しくなるのは、ほとんどの場合、構造化が曖昧だからです。
データを出す前に、そのデータのモデリングをしてみてください。
IT開発でよく使われている、DDDというデータモデリング手法に触れながら説明します
1. オブジェクトを定義する
オブジェクトというのは、同一性の定義です。
どこまでを同一としてみなすのかは、設定したゴールに準拠することが大切です。
例を挙げましょう。
採用活動の何らかのゴールがあるとして、採用される人側のオブジェクトを定義します。
候補者
これだけです。「採用される人側」と言いましたので、業界用語に言い換えました。仮に候補者(男)・候補者(女)とオブジェクトを定義したとします。それは、候補者という同一の性質を持ってるのに、性別で分けるのはもう定義が壊れてると言えるでしょう。ゴールに立ち返り、同一性の定義に矛盾を出さないことが重要です。ものレボでは、「WHYに立ち返る」と言ってます。
余談ですが、WHYに立ち返って同一性を定義すると、無駄な差別も区別も起こらないと思ってます。オブジェクトを定義を重ねてきた経験は、言葉を選ぶための重要な一つの要素として有効です。
オブジェクトには2種類あります。何となく程度に読んでください。
エンティティ
- 同一性により区別される
- 同じ属性であっても、区別される
- 可変である
値オブジェクト
- 透過性により比較される
- 交換が可能である
- 不変である
簡単に言うと、実績系は値オブジェクトですが、人とか物はエンティティになります。
深く考えなくても、ざっくり全部をオブジェクトと呼びましょう。
2. 要素を定義する
候補者オブジェクトには、その存在に必ずある情報があります。これはどういう扱いなのでしょうか。
一例として、「名前」の話をしましょう。私で言えば、名前の中に「森」という漢字がありますが、その森は木が3つあります。木が多いから森になったのかなと(よく知りませんが)文字から読み取れる情報はまだあります。
ここでWHYに立ち返ります。採用に「森」の成り立ちは必要でしょうか?まったくどうでも良い情報です。しかし、仮に名前がないとすれば、面接のときに候補者が誰なのかわからなくなり、挨拶したくても名前がわからなくなってしまいます。
WHYに立ち返ると、名前そのものは必須ですが、それ以上の情報はいりません。
この場合、オブジェクトの中にある「要素」として取り扱います。要素そのものはオブジェクトにもなれますが、ゴールに準拠すれば、そう取り扱う方が適切であるということです。
3. 関連性を定義する
オブジェクト間の関連性を線と文字で表します。仕事をしていれば誰でも聞いた事のある、「1対多」とか「多対多」とか言うやつです。
1からの手順を踏まえて、サンプルを作ってみました。
関連情報が加わり、全体像が把握しやすくなりました。
ゴールに準拠しつつ、シンプルに構造化することによって、整理の土台が出来上がります。
プロセスを洗い出そう
オブジェクトはプロセスを通ることによって、何かしらの影響を受けて変化していきます。
採用で言えば、候補者はカジュアル面談を経由することによって、より採用企業の事を理解出来た候補者になります。
以下に例を作りました。
プロセスは、ユーザー像(ペルソナ)毎に出してください。オブジェクトの図と比較がしやすくなります。プロセスは左から右へ時間軸が動いてます。サンプルは少し大雑把ですが、行うべき/行っている全てのプロセスを洗い出してください。
総合評価する
さぁ、オブジェクトとプロセスを繋げましょう。関係があるオブジェクト/要素をプロセスに紐付けてください。プロセスに何かしらの対応行動をうってるのであれば、オブジェクト図にわかるように追加してもいいでしょう。相関図に相当するものも作っても良いかも知れません。
※私の普段使いの照らし合わせ手法もありますが割愛します。方法は一つでありませんし、長くなるので・・・。
あなたの本当のボトルネックをみつけてください。そのボトルネックに直接関連する数値こそが、あなたが本当に発表したい内容のはずです。
以下のような項目を確認してみてください。
- プロセスを改善する対策は存在しているか。
- プロセスに紐付く対策は実行できているか。その対策は十分に機能しているか。
- 限りあるリソースのなか、ゴールの数値が最大化するポイントはどこか。
- 対策の優先度は正しいか
- オブジェクト(関心をもつべき事柄)は、十分に出せているか。または、多すぎないか。
- etc…
発表時に、真に必要な数値を導出する数値やオブジェクトは、出来るだけ出さない方がUXが良くなります。
UX改善のためにも構造化が効いてくるでしょう。
最後に
発表するときは、「ユビキタス言語」でお願いします。簡単に言うと、組織の共通語です。
オブジェクトを設計していると独自のオブジェクト名を作ってしまいがちです。使わないようにするのではなく、その言葉を聞き手に浸透させる努力を忘れないようにしましょう。
ものレボはビズサイドを含めて技術屋集団です!興味もった人は応募をお願いします。