アドテクスタジオの木村です。今回は私がまだサービスが始まったばかりの頃のAI Messengerと調整していた時の「マインドセット」的なところをゆるく共有していきます。データを集計、視覚化（可視化）、分析しようとするエンジニアが、どのような問題に直面し、どのようにその問題を解決していくかに触れます。
問題設定：服を買いに行く服がない
サービスが開始して間もないプロダクトで、データの集計や視覚化（可視化）や分析を試みようとした場合に、真っ先に直面するのが「データが無い（少ない）」という状況です。
通常、データに触れる人は、ビジネスで次の施策（アクション）に結び付くデータ分析結果の提示を求められます。ですが開始したばかりのプロダクトでは、まだマスタデータもオーディエンスデータも行動ログ（AI Messengerの場合はチャットのログがメインです）も、十分には設計されてはおらず、また蓄積もされてもいません。
データを分析するにはデータが必要です。しかし、どのようなデータを分析対象とすべきなのかを決めるには、ビジネス上の課題、顧客の要望、エンドユーザの性質など、様々な要因に関するデータを集めて、事前に分析しておかなければなりません。
これに加えて、「費用対効果が求められる」とも考えた方が良いでしょう。誰がデータベースのログフォーマットを改修するにしても、開発プロジェクトとして動く以上、そこに投資したリソースに見合う分の対価は求められると考えるべきです。
しかし、この費用対効果を計算する上でもデータが必要となります。プロダクトマネージャなら、例えばEarned Value Analysisなどのような方法を用いて、過去の工数見積の予実差異などの情報から次の開発の工数を予測しようとするでしょう。ですが始まったばかりのプロダクトでは、そうした情報は得られません。「不確実性」が高いとも言えます。
このお話は、機械学習のロジック設計で直面する問題としても再設定することができます。例えばAI Messengerとの関連でも、教師あり学習のアルゴリズムで新しい対話システムのロジックを実験的に構築する試みが為されてきました。しかしその場合に問題となっていたのが、如何にして訓練データを揃えるのかです。大規模なコーパスやオントロジーを自動的に生成するWebクローラやWebスクレイピング技術でも採用しない限りは、膨大なデータアノテーションに時間と労力を費やすことになるはずです。それに見合うほどのロジックを設計できるのかどうか、また新ロジックを搭載した場合の「評価」をどのような指標で実施するのか、諸々問われます。
以上の状況が示しているのは、「データ分析にはデータが必要だが、必要なデータを揃えるにはデータ分析が必要になる」という「卵が先か鶏が先か」の悪循環です。地道に必要と思われるデータの収集に時間を費やしてしまえば、そのリードタイムの間は、傍目から観ると何もアウトプットしていないように視えてしまうでしょう。またその収集データが必要であるという認識に誤謬が無いとも言い切れません。かといって不十分なデータしか集まっていない状況で強引に分析やロジック設計を敢行しても、良い成果が得られるという保証はありません。これは一種の「パラドックス」とも言えます。
問題解決策：自分からデータベース設計案を提示する
サイバーエージェントのアドテクスタジオのように、「データを扱うエンジニア」と「プロダクトを担うエンジニア」を組織的に区別しているような環境では、一見プロダクトのデータストアやデータ収集システムはプロダクトのエンジニアが保守すべきであると思われていそうです。
しかし場合によっては、これは非効率でリスクを伴わせる役割分担になり得ます。分析の対象にしようとするデータそのものが、人間の判断を含んだコミュニケーションによる生成物であることを忘れてはなりません。データとは客観的な真実を表現するものであるという思い込みは避けるべきです。データはデータの収集システムを設計した人物の信念や目的、偏り、そして実用面での制約を含んでいるのです。
ですので、必要なデータが不足している状況を打破するには、自分からデータベース設計案を提示することも、時には必要になります。例えば私が設計を立案する場合には、ER図やUMLのクラス図にスキーマの全体像を作画し、Google スプレッドシートにテーブルの定義を記載した資料を作成して、プロダクトのエンジニアと共有しています。そして、分析に必要なデータはストリーミングデータからGoogle BigQueryに流し込むようにお願いしています。プロダクト側のエンジニアの仕事を奪う形になっても気にしません。
ここで重要となるのは、「データベース設計のノウハウ」と「データ分析のユースケース」のバランスです。例えばOne Fact in One Placeを目指したテーブルの「正規化」を実施すれば、冗長性が排除される代わりに、テーブルの個数が増える場合があります。ですが一方でデータ分析においては、大抵の場合、そうして分割されたデータを一個のデータフレームにマージして処理することになります。こうしたマージするユースケースしか想定できない場合は、非正規化を検討します。これは、純粋にソフトウェア・エンジニアリングの観点から検討される非正規化の場合とは違って、利便性に重きを置いた検討となるでしょう。
問題解決策：問題を抽象化する
上述した通り、一連のデータ分析過程それ自体の「費用対効果」を算出するにはデータ分析それ自体が必要になります。一見するとこれは、難解なパラドックスに思えてしまいます。しかし、これが難解に見えるのは、データ分析の目線で問題を眺めている場合だけです。
プロダクトにはプロダクトが抱えている固有の問題があります。多くの場合、たとえ自分からデータベース設計を立案しても、そうした依頼や提案は、「もともとプロダクトが抱えていた問題」の解決よりも優先して実施されるべきか否かという「比較」の観点に曝されます。何を提案しても重要性と緊急性が問われるのが世の常です。
しかし、上記のデータベース設計案をはじめとしたデータ分析目線での提案に、「もともとプロダクトが抱えていた問題」の解決にも資するほどの「付加価値」があるとすれば、プロダクト側も比較的優先して取り組んでくれるでしょう。逆に言えば、「もともとプロダクトが抱えていた問題」の解決に資する「付加価値」を初めから自分の提案の中に組み込むように設計しておけば、自分の提案は通り易くなるということです。この発想は、「自分はこういう研究や開発がしたい」と主張するだけでは不十分であるということを前提とした発想です。
補足：オブジェクト指向分析
一口に言い換えれば、これは「オブジェクト指向分析(Object-oriented analysis)」と全く同じで、問題領域を抽象化する発想です。共通する問題領域と可変となる問題領域を区別することにより、可変となる問題領域にはそれぞれに具体的なメソッド（問題解決策）を展開すると共に、共通する問題領域には共通の抽象的なメソッド（問題解決策）を適用していくという視点を意味します。
非常に基礎的なところを確認しておくと、オブジェクト指向「分析」は、「オブジェクト指向設計(Object-oriented design)」でもなければ、「オブジェクト指向プログラミング(Object-oriented programming)」でもありません。この問題領域の抽象化という観点は、「仕様(specification)」や「実装(implementation)」の水準というよりは、「概念(concept)」の水準にあるためです。問題領域には様々な「オブジェクト」がありますが、オブジェクト指向の観点から捉えられる「オブジェクト」は単なる「データと操作の集合体」ではありません。ここでいう「オブジェクト」とは、「責任」を意味します。そしてこの「責任」を遂行するのがインスタンスです。
オブジェクト指向に準じたシステム開発では、最初からソフトウェアを網羅的に設計するのではなく、まず開発しようとしているオブジェクトが「そもそも何なのか(What)」を特定するところから始まります。ソフトウェア要求を定義するということです。初めからそのオブジェクトの「実装は如何にして可能になるのか(How)」を考えてしまっては、何を造れば良いのかも定まらない状況で開発を進めることになるため、不確実性が高まってしまいます。 この「そもそも何なのか(What)」を特定する営みは、「（それぞれのオブジェクトが）何の責任を担うのか」を特定する営みとも言えます。このそれぞれのオブジェクトとその責任を特定していくことが、関連する諸概念を明確にしていくことに直結します。
その上で、「実装は如何にして可能になるのか(How)」も決定していくことになります。これは、（それぞれのオブジェクトが）如何にして責任を全うしていくのかという話です。そして、この実装の方法がオブジェクト指向プログラミングということになります。しかし、一つの開発で要求される責任が一つであるとは限りません。複数の責任が問題となる場合、複数のオブジェクトが必要になります。場合によっては、オブジェクト同士を結合することで、複合的な責務を担保しなければならなくなるでしょう。そこでオブジェクト指向では特に、複合的な責任を果たそうとしている複数のオブジェクトの結合部分となる公開インターフェイスの仕様化が目指されることになります。ここでいう公開インターフェイスの仕様化とは、あるオブジェクトがそのオブジェクトを「如何にして利用できるのか(How)」を共有する営みを意味します。いわゆる「仕様」とは、インターフェイスのHow to use it.ということになるのです。
こうした基礎的な思考技術から、ジム・コプリエンの「共通性／可変性分析(commonality/variability analysis)」のようなノウハウが生まれています。問題領域の「何処」あるいは「何」が流動的な諸要素となり得るのかを区別するのが「共通性」の分析で、それらが「如何にして」変異し得るのかを区別するのが「可変性」の分析です。背景にあるのは集合論です。問題領域において共通する諸要素を纏め上げた集合を発見することが先決となります。そしてその上で、その集合内部の諸要素が如何に異なっているのかを明確にしていきます。こうして抽出された差異が可変性です。言い換えれば、諸要素の可変性は共通性の集合の中でのみ観測可能となります。よりオブジェクト指向設計風に言えば、問題領域の部分に流動的な諸要素がある場合、それを纏め上げた「責任」に対応付けられるのが「抽象クラス(Abstract Class)」です。そしてその後の可変性分析によって抽出された流動的な諸要素の個別具体的な「責任」に対応付けられるのが「具象クラス(Concrete Class)」です。
「抽象化すること」は「距離を取ること」ではない
オブジェクト指向分析のような方法からデータ分析の問題を抽象化すれば、プロダクト側が抱えているビジネスやシステムの問題との共通性を発見できる可能性が生み出されます。プロダクト側の問題領域から観れば、データ分析というのは、一種の「具象メソッド」に過ぎません。つまり、数ある具体的な問題解決策の一つに過ぎないということです。プロダクトには、ビジネス寄りの問題解決策（具象メソッド）もあれば、システム寄りの問題解決策（具象メソッド）もあります。プロダクトにとって、データ分析という問題解決策は選択可能な「具象メソッド」に過ぎず、場合によっては選択する必然的な根拠は何も無いとも言えます。
先述したような、「もともとプロダクトが抱えていた問題」の解決に資する「付加価値」を初めから自分の提案の中に組み込むように設計しておくという取り組みは、自分自身の問題設定と問題解決策を抽象化することによって可能になります。抽象化は、プロダクトの個別具体的な現場の問題領域から「距離を取ること」につながるのではありません。その逆です。オブジェクト指向分析のような抽象化の思考技術を習得しておくことは、プロダクトと寄り添い、協力してビジネスやシステムの問題を解決していく上で有用となるでしょう。
問題解決策：認知心理学や神経生理学の知見を増やしておく
プロダクトの問題領域へと肉薄していく場合、「データビジュアライゼーション(Data Visualization)」は不可避となります。データビジュアライゼーションは、膨大なデータの中に潜在化している法則や傾向を顕在化させることを意味します。それは、データ間の視えない関連性を可視化する営みです。特にビジネス上の問題設定に対する問題解決策の一つとしてデータ分析が求められた場合には、人間が目で見てデータの内容やデータ間の関連を理解して利用することが求められるため、データを何らかの方法で視覚化（可視化）する必要があるということです。
注意しなければならないのは、データビジュアライゼーションは、データを「可視化」して終わりであるという訳ではないということです。Visualizationという用語には、「可視化」のみならず「視覚化」という意味も含まれています。データビジュアライゼーションの機能がデータ間の隠れた関連性を視覚化することであるとするなら、「その受け手となる人間が如何に情報を視覚的に認知するのか」という問題にまで立ち返り、人間が事物を視覚的に認識する場合の認知過程や神経生理学的な情報処理過程に関する知見に長けておくことも重要となります。
一例：アフォーダンス理論
認知科学的にユーザー・インターフェイス設計方法を分析してきたドナルド・ノーマンは、機能性と情動を重視した自身のインターフェイス設計理論を記述する上で、知覚心理学者ジェームズ・ギブソンの「アフォーダンス(affordance)」の概念を「誤用」していたことで有名です。ノーマンはアフォーダンスという概念を参照することで、人間とオブジェクトとの関連をユーザーに伝達するユーザー・インターフェイスの設計理論を展開していました。例えばノーマンにとっては、ドアの取手の形状が押し戸か引き戸かという情報を提供(afford)するなどという意味で、アフォーダンス概念は「行為の手掛かりを提示する概念」であるように論述していました。
元来アフォーダンスとは、ギブソンの造語で、必ずしもオブジェクトのユーザーに有益な事柄を提供する訳ではありません。アフォーダンスは、設計者がユーザー・インタフェースを設計することで決定し得る情報ではないからです。むしろアフォーダンスは、ユーザーとユーザー・インターフェイスの「関係」を記述した概念です。それは外部の環境を知覚する生体と外部のオブジェクトの「関係」を前提に決定される環境の「意味」です。インターフェイスとの「関係」も、オブジェクトの「意味」も、ユーザー次第で変化します。言い換えれば、ユーザー次第でインターフェイスのアフォーダンスは可変であるということです。
このアフォーダンス概念は、その思想的背景に問題を孕んでいます。ギブソンによると、知覚は環境による無数の刺激が言わばフィルタリングのように選択されることで成立します。膨大な刺激の全てが知覚される訳ではないということです。知覚を成立させているのは、環境の事実を特定する刺激についての情報です。ギブソンは、環境の性質が不変的な要素で成り立っていると考え、環境を知覚する生体の行為には全く依存しないと言います。環境の諸要素は「実在」に由来するのであって、環境から実在が「構成」される訳ではないということです。ギブソンによれば、環境の諸要素は、ただ「発見されるのを待っているだけ」であるかのように論じます。
これを前提とすれば、アフォーダンス理論に準拠した場合には、オブジェクトとエンドユーザーの「インタラクティビティ(interactivity)」の可能性が視え難くなります。既にサイバーエージェントのアドテクスタジオにはTableauが普及しており、インタラクティブなデータビジュアライゼーションが実践可能になっています。ビューを数回クリックするだけで、データソースのリレーション化、フィルターの追加、ドリルダウンによる情報の参照など、様々なデータを即座に視覚化できるようになっています。こうしたユーザー・インターフェイスを活用すれば、データの可視化を担当したエンジニアが当初想定していなかったデータの潜在的な関連性であっても、Tableauのエンドユーザーによって可視化される余地が生まれます。Tableau上のデータは、「発見されるのを待っているだけ」ではなく、エンドユーザーに自発的に探索して認知することを促す刺激でもあるのです。
一例：ゲシュタルト心理学
この「自発的に探索して認知することを促す刺激」としてのデータ概念は、人間の認知過程を遡及することでより明快となるでしょう。一例として挙げられるのが、1920年代から主にドイツで研究されるようになったゲシュタルト心理学です。ゲシュタルト心理学は、それまで支配的であったヴィルヘルム・ヴント流の要素主義（還元主義）的な心理学に対するアンチテーゼとして確立した心理学で、「心理・認知現象の全体性は部分に還元できない」というWholismの思想から出発しています。全体の「形態(Gestalt)」を部分の諸要素よりも優先させるというコンセプトから、ゲシュタルト心理学は「人間が如何に情報を視覚的に認知するのか」という問題にアプローチします。
ゲシュタルトの基本的な原理は、全体が単純な部分の和ではなく、その個々の構成要素よりも大きな意味を持つということです。この原理から出発するゲシュタルト心理学は、この原理に準拠し、人間の知覚が視覚要素を「統一された全体」に纏め上げる傾向にあるという規則を定義しています。それは人間の知覚処理に対して普遍的に妥当すると今日も考えられており、データビジュアライゼーションやユーザーインターフェイス設計に対して有用な洞察を提供しています。
以下、ゲシュタルト心理学で定義される幾つかの原理を概観していきます。
近接性
近接性(Ploximity)は、直ぐ近くに配置されている諸要素が、一定のグループを形成するものとして知覚されることを指し示しています。各グループの粒度は必ずしも一定であるとは限りません。近接性の原理によれば、我々の視覚認知においては、それぞれの要素数が異なっていたとしても、それをグループとして認識する傾向にあります。
類似性
類似性(Similarity)は、我々の視覚認知過程では、似た形、大きさ、色、向きを持つオブジェクトが纏まったグループとして認識される傾向があるということを指し示しています。近接性の原理と同様に、それぞれの要素数が異なっていた場合にも、我々はそれをグループとして認識する傾向にあります。
対称性
対称性(Symmetry)は、対称な図形ほど認識され易いことを指し示しています。人間の認知過程では、対称的な輪郭がある場合には、そのオブジェクトを意図せずして見出すことがあります。
有名な「ルビンの壺」では、一つの纏まりのあるグループとして認識される部分にあたる「図」と図の周辺背景に位置する「地」とが、相互に入れ替えることができる図形です。白い壷を「図」として認識している時には、灰色の背景が「地」になります。一方、人物が向かい合っていることを「図」として認識する時には、白色が背景の「地」に反転します。「ルビンの壺」は認識の仕方によって全く別の図形を読み取ってしまう典型的な図です。これは、人物も白い壺も左右対称に描かれているために起こり得る「図」と「地」の反転現象と呼ばれています。
ゲシュタルト心理学の応用
こうした原理的な法則は、データビジュアライゼーションの知見となり得ます。例えば、同じ意味や「責任」を担うオブジェクト同士は近くに配置することで、近接性の法則に頼った視覚化が可能になるでしょう。
逆に、それぞれの法則を念頭に置いた上で、全く関連性の無いオブジェクト間は纏め上げられないように設計することも可能になります。意図せずして不用意にグループを形成させないことによって、混乱を招くデータの視覚化を回避できるようになるのです。
「図」と「地」の関係を上手く利用すれば、最も重要なデータだけを「地」として浮かび上がらせることにより、読み手の注目を意図した情報へと誘導することも可能になります。
総じてゲシュタルト心理学によれば、人間のデータ探索やその認知過程には、様々な形態的な原理によって、無意図的あるいは非随意的に実行されるという、こう言って良ければ、自動性が伴っています。勿論こうした認知システムの作動の実態を説明しているのはゲシュタルト心理学だけではありません。同様の主題に言及している様々な理論を比較検討することにより、エンドユーザーの意識に訴え掛けるのではなく、その知覚機能や認知過程に直接影響を及ぼすことで、より効率的に重要なデータ分析結果や判断材料となる情報を共有するノウハウを考えることができるようになるでしょう。
問題解決策：あえて不完全なデータビジュアライゼーションを実践する
自分でデータベースを設計し、ビジネスやシステムの問題領域の諸概念を整理していくといった回り道を辿っていくに連れて、次第にデータが蓄積され始めていきます。しかし、とりわけサービスが始まったばかりのプロダクトにおいては、必要十分なデータが収集されるまで待つべきではありません。また、膨大なデータアノテーションが完成しなければ実践できないようなロジック設計も回避するべきでしょう。
そもそもサービスが始まったばかりのプロダクトにおいて、「何を以って必要十分なデータとするのか」すらも、未規定性が高い問題となります。「何を以って必要十分なデータとするのか」を如何に規定することすらも、やはりデータを分析して観なければわからないことです。ですので、これもまた冒頭で取り上げた「服を買いに行く服がない」問題であると言えるでしょう。こうした状況で、例えばデータアノテーションをプロダクト側のメンバーに依頼したとしても、問題解決策の提案としては響き難いのです。緊急性の観点から後回しにされる可能性もあります。仮に提案が通ったとしても、そうした未規定性が伴っている状況で依頼されたところで、依頼された各メンバーが十分に恣意性を排除した状態でアノテーションを実施できるかどうかも疑問です。
したがって、データ分析目線から満足できる質・量のデータが収集されるのを待つ姿勢は、控えた方が良いでしょう。むしろ私が勧めたいのは、不十分なデータであっても、まずは視覚化（可視化）することです。サービスが始まったばかりのプロダクトでは、業務フローも、KPI設定も、オペレーションも、ビジネスの方向付けも、皆手探りの状態で進めています。誰も明確な「正解」がわからない状況です。
こうした不確実な状況に対して、データビジュアライゼーションは、「警報装置」のようなものとして機能します。多くの場合、ビジネス側と十分に議論せずに実践されたデータビジュアライゼーションは、「具体的にどのようなアクションにつなげるのか」という疑問を招きます。とはいえ視覚化（可視化）されたデータというのは、余程無秩序で乱雑なままに視覚化（可視化）されていない限りは、何らかの意味のある現状を指し示しているはずです。データビジュアライゼーションは、まず「現状把握」を可能にしているという点は揺るがないでしょう。
こうした「現状把握」に対して「具体的にどのようなアクションにつなげるのか」という疑問が投げ掛けられるのは、何故でしょうか。それは、把握した「現状」の何処に「問題」を見い出せば良いのかがわからないからです。ビジネス側の「問題」は、理想・目標と実態・現状との乖離から設定されるものです。アクションというのはその乖離を埋める解決策であると言えます。もしこの理想・目標が設定されており、尚且つ周知徹底されていれば、そもそもアクションにつなげ難い「現状」を提示するデータ分析者が現れることもありません。
これを「逆手」に取るなら、ビジネスにおける先行きの不透明性や現場の状況の不確実性は、あえてデータビジュアライゼーションを実践する動機付けになります。不完全なデータビジュアライゼーションは、そのデータ分析の不完全性のみならず、ビジネス側の不完全性をも諸共露呈させるからです。不確実性に曝された中でのデータビジュアライゼーションは、言わば、データの視覚化（可視化）を通じて、業務フロー、KPI設定、オペレーション、ビジネスの方向付けの不十分さをも視覚化（可視化）するという、二重のビジュアライゼーションを敢行するということを意味します。データビジュアライゼーションにおいては、作為的に失敗することも重要なのです。
まとめ
この記事では、サービスが始まったばかりのプロダクトとやり取りするデータ分析の担当者が直面する「服を買いに行く服がない」という問題設定を前提とした上で、様々な角度から問題解決策を記述してきました。
一つは、直接的にデータベース設計に関与することです。データ分析とソフトウェア・エンジニアリングの垣根やロール的な差異は度外視した方が効率が良いというお話をさせていただきました。
もう一つは、オブジェクト指向設計をはじめとした「抽象化」の思考技術が有用になるという点です。データ分析上の問題設定を「抽象化」した上で、プロダクトがもともと抱えていた固有の問題領域にも視点を拡張させることが、結果的にデータ分析そのものの問題設定の解決にも資する点を主張しました。
更に、バッググラウンドとして養うべき専門分野として、機械学習やデータサイエンスには言及せず、むしろゲシュタルト心理学をはじめとした認知科学や神経生理学のような分野を紹介しました。
最後に、データビジュアライゼーションは不完全であっても、ビジネスにおいては「発見」があれば良いと説明しました。サービスが始まったばかりのプロダクトでは、業務フローも、KPI設定も、オペレーションも、ビジネスの方向付けも、皆手探りの状態で進めています。これに対してデータビジュアライゼーションは、たとえデータ分析としては「失敗」してしまっても、ビジネス上の問題を探索する上で機能します。
このように、問題解決の発想は単純なものでした。単に具体的なデータ分析には固執せず、抽象化の観点からビジネスやシステム、そして他の科学・学問領域に視点を広げるだけなのです。
参考文献
- Coplien, J., Hoffman, D., & Weiss, D. (1998). Commonality and variability in software engineering. Software, IEEE, 15(6), 37-45.
- Gibson, James J. (1986) The Ecological Approach to Visual Perception, Psychology Press; New edition.
- Goldstein, E. B. (1999): Sensation and Perception. Pacific Grove, Brooks/Cole.
- Lattanze, A. J. (2008). Architecting Software Intensive Systems: A Practitioners Guide. CRC Press.
- Norman, Donald A. (2002) The Design of Everyday Things, Basic Books.
- Shalloway, A., & Trott, J. R. (2004). Design patterns explained: a new perspective on object-oriented design. Pearson Education.
- Varela, Francisco J. Rosch, Eleanor., Thompson, Evan. (1991) The Embodied Mind: Cognitive Science and Human Experience, MIT Press.