背景
業務データのデザインは、結構プロセス面から何となくで企画されてしまっているし、自分自身でも感覚的にやってしまっていることにずっと課題意識を感じていた。
案件の中でも、アプリエンジニアが多いためか、データの側面からの議論はわりとおざなりにされがちな印象を受けてしまっている。
この業務データがそもそも生まれた背景や企画などを通らないことには、適切なデータの側面におけるコンテキスト境界も定義できないはずだ！という強い情念みたいなものがある。
そこで今回は分析データ系を軽くでも学んだうえで、
どのように業務データをデザインしていくのか？について考察してみる。
前提
自分はアプリケーションアーキテクト兼BPMを主に担当している。
データのマネジメントも軽くではあるがやってはいるものの、充分にデータの品質まで考慮できてはいない。
その業務データは誰にとっての価値となるのか？
まず誰にとって、どんな状況下でその業務データが価値を生むのか？を起点に考えなくてはいけない。
簡単な具体例を考えてみよう。
エンドユーザーの属性データ
たとえばエンドユーザーのエンティティに含まれる性別や年齢といったもの。
あれは結局誰にとって価値を生んでいるのだろうか？
恐らくであるが、プロダクトマネージャーやマーケティング担当者といった人々であろう。
自分たちのプロダクトは、どの市場のどこのセグメントに対して打ち出しているものかを考えた上で、そのセグメントの人々がもっとも価値を感じるであろうモノコトを考えている。
その上でじゃあ実際にはどのセグメントの心に響いているのか？その仮説を検証したいはずだ。
でないと品質改善もへったくれもない。
すると自ずとエンドユーザーの属性として、年齢や性別といったものが欲しいはずだ。
そして集めた業務データを分析集計した分析計のデータを見ながら、
仮説段階で想定していたセグメントと実際の検証によってセグメントとのズレを検証する。
もちろん最初のセグメントで設定したイメージ像によって集める属性も変わり得る。
大事なのは、検証でどんな分析データを見たいのか？それによってどう改善サイクルを回したいのかだ。
イベント系の属性データ
注文といったイベント系のエンティティに対する属性データも考えてみよう。
これも注文日時 とかって思考停止した状態でも必須な属性は出せるが、
何を分析してビジネスの改善に生かしたいのか？を起点に考えるのだ。
たとえばビジネス背景と目的が
「今現在は24時間営業であるが、このところエンドユーザからサービス品質に対するクレームが来ている。
今までは24時間一定したサービス品質を心掛けていたが、現場を見てみると明らかに深夜帯は暇なことが多い割には、従業員の１時間当たりの単価が高い。
さらに調べてみたところ、クレームが来ているのは注文の集中している忙しい時間帯であった。
そこで営業時間を24時間するのではなく、注文が集中していない時間帯にのみ厳選することで無駄なコストをカットし、その分サービス品質向上に回したい。」
というものがあったとする。
すると事業のトップや経営層は自ずと注文の時間毎の濃淡を分析データを通して調べたいはずだ。
注文の集中していない時間帯を傾向から把握した上で、
その時間帯に関してはいっそのことサービスを停止してしまい、浮いたコストで注文の集中している時間帯にコストをつぎ込むという戦略を取ることにする。
そのためには現場で注文日時という属性を含んだ注文という業務データを集めなくてはならない。
GQM(+D)ワークショップ
上記では簡単な具体例を想定して必要な業務データをデザインしていく様を書いたが、若干感性に訴えかけたようなデザインの仕方に思えるので、自分なりに感性ではなく仕組みでデータをデザインする工程を考えてみた。
その際に使うスキルがこのGQMDワークショップである。
ソフトウェアアーキテクチャメトリクスという書籍の最終章でこのGQMについて触れられている。詳細は別の記事を読んでほしい。
また一度企画したデータはそれで終わりではなく、
継続的にもっとメトリクスを集めるのに適したデータは何かな？って考え続けるサイクルを回し続けていく。
そのような活動はアジャイルメトリクスという書籍で触れられている。
要は目標となるゴールがあり、そこを起点に仮説ベースで
「じゃあその目標を何をもって達成したかどうかを考えるの？」と議論し、
メトリクスの候補を考えた上で、そのメトリクスのためにはどんなデータが必要か？
そのデータは実際問題集めることができるのか？
などを集めるコストと、そのデータによって生み出される恩恵効果の両軸から考えるのだ。
これと全く同じ発想が業務データのデザインの時に必要である。
各ステークホルダーにとって想定シーンに応じた目的があり、
その達成度合いを調べるために、業務データや運用上のデータが存在する。
継続的にこのGQMDワークを行うことで、不要なデータも明らかになりやすい。
データの用途
さらにドメインサービス用の業務データなのか？
それとも運用用のデータなのか？については、そのデータを誰が必要とするのか？
を起点に考えればいい。
プロダクトを提供する組織内部の人にとってしか使わないデータは運用上のデータだ。
対して、エンドユーザーなど組織外部の人にとっても使うデータはドメインサービス上の業務データである。
たとえばエンドユーザーは口コミの詳細内容といったデータなどを見て、注文しようかどうか決めたいという想定であれば、口コミの詳細はドメインサービス上の業務データである。
まとめ
今回はデータの企画という原点に立ち戻ってみた。
さらに一度定義したデータが継続的に利用されるとしても、データに求められる非機能部分が変更されるかもしれない。
その場合にも、継続的なGQMDが有効と思われる。
もしもメトリクスに必要なデータが求められる品質を満たすために膨大なコストがかかるなら、
別のデータの方がより費用対効果があるから、そっちを集めた方がいいよねってなる。