データはいささか奇妙な性質を持っています。なんらかの事象の記録という観点では、それは文明の出現と時期をともにします。それが電子的に記録され、流通するようになってからは、まだ日が浅いものの、現在では、私たちの生活において決定的に重要な意味を持っています。
はじめまして。じんと申します。当ブログでは初のお目見えと相成ります。どうぞよろしくお願いいたします。弊社には2020年1月より参画し、いわゆるデータ・サイエンティストとして勤務しておりました。講談社サイエンティフィク社様のデータ・サイエンスに関する一連の書籍の一部の執筆を担当させていただいたことがありますので、まあ、データ・サイエンティストを自称してもいいのではないか、とは思っています。
さて、「勤務しておりました」、と過去形となっているのは、どうも自分が現在している仕事はいわゆる純粋な「データ・サイエンス」と呼ばれるものではないのではないか、とここ数ヶ月ほど感じておりましたためです。もちろんデータ・サイエンティストとしての仕事もしているのですが。そこで、はて、自分の仕事はいったい、既存の仕事でいうとなんであろうか、と考えたところ、もっとも適切にそれを表現するのは「オペレーション」と呼ばれる仕事、より粒度を細かくして参りますと、生産管理や流通管理の仕事が最も近いであろう、という認識に至りました。ご存知やもしれませんが、弊社はデータを取り扱うことに重きを置いた企業です。扱っているものはいわゆる洗剤や消毒液などではなく、「データ」という、触ることは難しいものの、しかし価値のある商品を取り扱っています。このデータという商品を生産し、流通させ、販売する機構全体について今日は考えていることを書いてみたいと思います。 DevOps や DataOps 、 MLOps 、 AIOps という概念を多少、広げた話になるのではないか、と思っています。車輪の再発明となる記事かもしれませんが、「データ」の「オペレーション」として、私が「データ・オペレーション」として考えていることをここではご紹介させていただきたいと思います。この記事が公開されたあと、他の有識者のみなさまのご意見を伺いに行こうかと考えています。
生産
さっそくまず生産に入っていきましょう。なんらかの生データを入手し、それに機械学習あるいは人手によって記述された規則に基づいて追加的なデータ、例えばなんらかのタグなどを付与しなければならない状況を考えていきます。
原材料調達
とにもかくにも、原材料が必要です。なんらかのデータですが、典型的には外部から購入できる、あるいは無償で公開されており入手が容易なデータベースなどが考えられます。 Wikipedia などは典型的なものでしょう。付加価値を付与する前のデータがあるとして、それに付加価値を付与しなければなりません。なんらかのタグを付与する際には、注釈づけ (アノテーション) が行われた教師データが必要になります。この注釈づけを適切に行うことは容易ではありません。テキストにおいては、『Natural Language Annotation for Machine Learning』という書籍が参考になります。
ここで一つ頭に留めておかないといけないことは、有償のデータを購入して利用する場合は、その供給者に対して、すなわちデータの仕入れ先に対して、こちらが価格交渉力を保持しているか、という観点です。典型的な Porter’s Five Forces の Power of Suppliers の問題です。もし、独占的にある企業が保有しているデータの入手が必要になった場合、こちらは価格交渉力を持ちません。「足下を見られる」ことになります。相手の言い値で買わざるを得ないことになります。この蛇口を締められてしまいますと、当然、こちらは干からびてしまいますから、仕入れ先の冗長化には気を配る必要があります。
加工
なんらかのタグを付与する対象のデータと、そのための教師データが用意されたとしましょう。さあ、データ・サイエンティストの登場となります。機械学習の問題に帰着できるのであれば、何らかの計算模型 (モデル) を設定し、パラメタを推定し (学習) 、その上で実際にタグを付与 (推論) することになります。
この加工については、実に様々な設定がありうるため、一概に論じるのは難しいところですが、よく感じることは、目的に対して適切な、過小でもなく過大でもない手段で取り組むことが、特に費用や時間の制約が大きい場合は、重要である、ということです。少々乱暴な例ですが、小学生の頃に通っていた塾の講師がよく言っていたことを思い出します。「隣の家の犬がうるさいとき、爆弾を投げるのは過剰だろう。小石でも投げるか、そもそも隣の家の家主を尋ねるべきだ」と。
どうも、この加工において、ひとまず爆弾を投げるような事例を多く見かけるように思います。手段と目的を転倒すべきではありません。人手で規則を書けば済むような問題に対して、これを機械学習で解きたい、というのは単なる自己満足に過ぎません。もちろん、爆弾を保有している、ということを外部に主張することに商業的な意義がある場合はあります。
また、この課題が、どれくらい難しいものか、というある種の「偵察」が重要です。現代の技術や資源ではまず解決不可能な問題と相対している可能性すらあります。こういった観点も上述の『Natural Language Annotation for Machine Learning』で詳説されていますが (しっかりイタレーションを意識する必要があります) 。データと、まず「一揉みしてみる」ことが肝要です。既に確立され、論文も多数出版されている機械学習課題であればある程度の目測を立てることは可能ですが、新しい種類のデータに対して新しい種類の処理、すなわち加工を施そうとする場合は、まずその「硬さ」を調べてみる必要があります。包丁で十分なのか、それともダイヤモンドカッターを持ち出さないといけないのか、そもそも強力な炸薬で爆破する必要があるような課題なのか、こういった問題の難しさをまず見積もる必要があります。解決不能であると考えられるのであれば、埋没費用の誤謬に惑わされることなく、速やかに撤退する必要があります。
品質管理
私が、機械学習を利用した生産において、最大の問題と感じているのがこの品質管理です。10万件のデータ、典型的にはデータベースのレコードに対して機械学習によって何らかのタグを付与したとしましょう。この精度（適合率や再現率といった観点はもちろんありますが、一旦「精度」と捨象します）が、適切に注釈づけ (アノテーション) されたデータの、テストデータに対して、90%の精度を達成したとしましょう。歩留まりだと考えますと（良品率と一旦まとめて考えてしまいます）、10万件のデータに対して1万件の誤りが含まれていることが想定されます。1万件も誤りが含まれているのです。1万件です。菓子パンだと考えると10個に1個は不良品が含まれているのです。これは許されることなのでしょうか。この菓子パンを検品なしにそのまま出荷したら、瞬く間に企業の評判は地に落ち、社内はお客様のお怒りの電話の鳴る音で満たされることになります。
話は脇に逸れますが、この「歩留まり」について感銘を受けたのは名著、『ルワンダ銀行総裁日記』における珈琲豆商人の一節で、これはぜひお勧めしたい一冊です。また、この名著は、巨大な体系を、この場合は開発途上国とはいえ、一国の経済であり、それを専門知識で以って俯瞰する、という点において技術者として実に印象深いものです。手段と目的を転倒させてはならない、ということもこの書籍から深く読み取ることができます。
加えて、実験室のような環境で90%の精度を達成したとしても、現場での生産はその精度を遥かに下回ることがほとんどです。 data availability and user tolerance という考え方があります。要は、豊富に教師データがあり、かつ、結果が誤っていても重大な問題が生じない機械学習課題であれば実用化は容易、ということです。 EC サイトや動画配信サイトの推薦システムを考えますと、お客様の購買履歴や視聴履歴が容易に手に入り (data availability) 、かつ妙な商品やコンテンツを推薦してしまったとしても、本来であればご購入いただけたはずの商品をご購入いただけなかったという機会損失はありますが、被害は大きくありません (user tolerance) 。ただし、未成年のお客様に成人向けの商品やコンテンツを推薦することには大きな問題がありこの点については厳密な制約を加える必要があります。
評判分析も user tolerance の高い課題です。 A 社の X という製品と、 B 社の Y という商品の評判を機械的に調べてみることを考えてみましょう。莫大なツイート集合に対して評判分析を実施し、 X と Y がどのような観点においてどのような評価を、典型的には肯定的な評価と否定的な評価をどのくらい受けているのかを考えます。そもそも、莫大なツイート集合をマーケティング担当者が読解するのは無理がある話です。また、多少の誤りがあっても、そもそもの莫大な母集団を考えますと多少の誤りは許容できます。
問題は、データの一次加工物、すなわち何らかの分析をデータに加えたものと、それに対して更に何らかの加工を加え、特に人手による分析が後段で入ったり、あるいはそのデータがさらに別の機械学習課題の入力として利用される、データの二次加工物では異なる品質を要求されるということです。一次加工の結果、すなわち10万件のデータに1万件の誤りが混入している、そういったものを直接、販売することは果たしてできるのでしょうか。 user tolerance について、慎重に吟味する必要があります。
このことから、データの一次加工物に対しては人手による系統的な品質管理が必要となることがわかります。その体制を構築することも一つの難しい問題です。
流通
在庫管理
さて、とにもかくにも、データが生産されました。当然、それはどこかに保管されます。現代であれば、クラウド上のストレージや何らかのデータベースにそれは格納されているはずです。もしここで、弊社が生産しているものがテレビであれば、生産されたテレビはどこかの倉庫に山積みになっています。データの厄介なところは、それに触れたり、物理的実体として視認することが難しいという点でしょう。例えば、在庫管理の担当者の引き継ぎが行われたとき、少なくとも、後任者は、倉庫にテレビが山積みになっていれば、いやあ、在庫が山積みだなあ……とすぐにわかります。データの場合、この引き継ぎが適切に行われなかった場合、そもそも在庫が山積みである、ということの認識すら難しくなります。いわゆるデジタル・ダッシュボードの果たす役割は実に重要なものです。
会計上、テレビのように物理的実体を伴って出荷を待っている資産は貸借対照表の流動資産の部に計上されます。問題は、データは流動資産としては計上されない、ということです。もしテレビの在庫が倉庫に山積みになっている場合は、それは棚卸資産として評価の対象となりますが、データは会計部門から捕捉されません。この性質もデータの取り扱いを厄介にします。ソフトウェアは無形固定資産として資産に計上できますが、それによって生じたデータは資産にはなりません。しかしデータが決定的に重要なのです。
その一方で、テレビが倉庫に山積みになっており、その倉庫の賃料を求められることと同じように、データもストレージを占有し続け、倉庫の賃料のように、着実に出費を強要してきます。加えて、データにも鮮度があり、古いデータより新しいデータの方が当然有用性が高い場合が多くなります。
雑駁に述べて参りましたが、データは在庫としては以下のような性質があることがわかります。
- (データの取り扱いに習熟していない限りは) 直感的に捉えづらく在庫の実態の把握に工夫が必要
- 会計部門から監視されないため棚卸しの機会を強要されない
- 維持に費用を要する上に徐々に価値が低下していく
言うまでもなく、 3. については多くの商品が該当します。問題は 1. と 2. で、率直に言って、在庫としては非常にいや〜な商品です。この在庫としてのデータの管理についてはまた別の機会に述べてみたいと思います。そもそもデータは一般的な意味において私たちが思い浮かべる「在庫」なのでしょうか。
一つ留意しおきたい点は、この商品に関する私たちの認識です。計算機科学においては「型」となるでしょうか。菓子パンは食べられるものであって、重さがあり、形があり、それはある一定の形態であるべきもので、可能な限り密封されて輸送されるべきものであって、時間とともに食用に耐えられなくなる、という認識を広く想定することができます。在庫管理の担当者や、後述する流通の担当者、例えば菓子パンを倉庫からコンビニエンスストアに輸送くださるドライバの方も、その認識においては齟齬は大きくないでしょう。パンは食品なのです。
一方、データベースのあるテーブルのあるカラムに入っている値の型は、はて、文字列なのか、整数なのか、当然ですが、それは一定の専門知識がなければ把握することができません。私の父や母に SQL をしゃべってもらうことは、まあ、いい歳ですから、今後も不可能でしょう。菓子パンはとても身近なものですが、文字コードに関する知識も含めて、いまお読みいただいているこのテキスト自体が実際はどのようにこの世界に存在しているのか、というのは意外と難しい問題です。このテキストは地球上の、もろもろを捨象しますと、ある計算機のストレージ上にあります。それに簡便に触れていただくために、あれこれとプロトコルがあります。こういった問題を隠蔽するように、すなわちそれを多くの方が気にかけなくてもよいように、計算機科学は進歩してきました。それはすなわち、専門家でなければその実態を把握できない、ということに他なりません。計算機科学に限らず、科学技術というものは本来的にそういった性質があります。なぜ蛇口をひねると水が出るのでしょうか？その水はどこから来たのでしょうか？電気はどうでしょうか？
話はそれますが、この在庫というものは、非常に厄介な一方、なかなか面白いものです。任天堂社様の名コンテンツ『社長が訊く』の『PUNCH-OUT!!』の開発経緯からは、在庫について考えさせられるものがあります。
流通管理
やれやれ、ひとまずちゃんとデータの実態を把握しつつ在庫として確保した、とします。さて、今度はこれを流通させなければなりません。流通は、必要なもの (what) を、必要な場所 (where) の必要な人 (who) に、必要なとき (when) に着実に届けることです。あまり気持ちのよい例ではありませんが、戦争における銃弾や砲弾について考えてみましょう。戦闘が生じる前 (when) に、戦闘が生じる場所近傍 (where) の部隊 (who) に銃弾や砲弾 (what) を届けなければいけません。銃弾がなければ銃も単なる棒になってしまいます。
データのよいところは、それが有線であろうが無線であろうが、その流通に要する計画および実行が物理的な商品と比べて比較的容易であるところです。もちろん回線の容量やデータベースの処理速度という制約がありますし、データベースのレプリケーション一つ取り上げてもあれこれと検討すべきことがあります。しかし、銃弾や砲弾のように、前線で一日にどれだけの銃弾や砲弾が必要で、そのためにはトラック何台を前線と策源地の間を一日何回往復させる必要があり、それはどういうスケジュールでなされ、トラックの稼働率（トラックもいずれ故障しますので全てのトラックが常に稼働するとは期待できません）はいくらで、トラックの修理のための部品と技術者はいくら必要で、トラックの運転手は何名必要で、彼らにもお休みを取っていただく必要があるのでどういうシフトで、また燃料はどれくらい必要で、事故や敵の妨害も加味した安全率も考慮すると……といった複雑な数式を解く必要は少なくなります。
映像のような大容量のデータをオン・デマンドで世界中に流通させるためには、コンテンツ配信網の利用が必要になってきます。これも上述の流通という観点から理解できます。すなわち、大容量の映像コンテンツ (what) を、世界各地 (where) の視聴者の方々 (who) にオン・デマンド (when) でお送り差し上げる、すなわち流通させるためには、大容量回線網の地理的な接続を加味した上で、回線網上に分散した補給点を設置する必要がある、ということになります。高速道路や幹線道路の脇に工場や倉庫が立地していることや、かさばる輸入原材料の加工を行う工場が沿岸部、それも直接、船舶からの荷下ろしが可能な海沿いに立地していることと変わりません。
話を元に戻しますと、一つ厄介な問題は、データを販売を担当する営業部門にお渡しする段階です。データベースに格納されているデータを、さて、どうお渡しすればいいのでしょうか？営業担当者の方が SQL を発行して必要なデータ、すなわち商品を取り出せばいいのでしょうか。営業担当者の方が複雑な SQL をしゃべることができることを期待してもよいものでしょうか。やはりエンジニアが SQL をしゃべって必要なデータを取り出すべきでしょうか。仮に後者だとして、営業担当者の方が必要なデータをエンジニアが適切に SQL に落とすための意思疎通に齟齬は生じないのでしょうか。いよいよ頭が痛くなってきました。
さて、ここで what/where/who/when が現れました。ここまで意図的にいくつかの問題に触れずにいましたが、いよいよ販売の話に移ります。
販売
ようやく、いよいよデータの販売にまでたどり着きました。しかしまだまだ問題は山積しています。
需要予測
いよいよ深刻な問題についてついに触れなければなりません。一般的には、企画部門が、何らかの商品の企画を行い、生産部門において生産が行われ、流通部門がそれを輸送し、営業部門が販売できるように彼らの手元に商品を届けることになります。さて、ある商品がどれくらい売れるのか、どう需要を予測すればいいのでしょうか？この点については近年の典型的なデータ・サイエンティストの仕事となります。大量生産されるある種の消耗品はわかりやすい例でしょう。過去の販売データに基づいて、何らかの計算模型を設定し、パラメタを推定し、推論を行うことである程度の需要は予測できます。地域の人口や年齢構成、収入などからも推定は可能です。
この商品、すなわち、データ (what) は、まあ、売れる、ということが高い確度でわかっているとします。データが必要とされるまでの時期までの時間に余裕がある場合は何とか生産が間に合うでしょう。厄介なのは、特殊な、頻繁には生じない商取引に必要なデータで、これを迅速に提供、すなわち生産する体制を常に生産部門は整えておかなければならないという状況が生じることです。このことから、生産部門の稼働率には常に遊び、すなわちバッファを残しておく必要が生じます。
さらに、異なるデータを同時に、異なる営業部門から求められ、しかも生産部門にはそれを並行して生産する余裕がない状況を想定してみましょう。胃が痛くなる状況です。ここで、 5W1H の残り、 why と how が生じます。なぜ (why) 、またそれはどれくらいの確度 (how certain) で必要となるものか (商品が販売され利益が生じる、と事前に完全に確定している状況はむしろ稀です) 、どれくらいの利益 (how much) を生じさせるものなのか、期待値の計算が必要になってきます。しかも期待値の計算に必要なパラメタである確率 (確度) および確率変数 (利益) を事前に求めることは容易でありません。
価格設定
なんとかデータを売れるようになってきたとしましょう。長い道のりでした。さて、これをいくらで売ればいいのでしょうか？原価計算の登場です。原価としては、原材料としてのデータの調達費、加工費、エンジニアの人件費などが含まれます。データという商品の直接費については、外部から原材料となるデータを購入した場合はその費用、機械学習の教師データを作成した場合はその注釈づけを行ったアノテータの人件費、エンジニアの人件費、さらにデータの加工に要した計算資源の利用費用が含まれます。これにオフィスの家賃やらなにやらの間接費が加わり、概ね原価を計算することができます。さて、付加価値として、おいくら万円、この原価に利益となる部分を上乗せして販売価格とすべきでしょうか？ここには当然、重大な要素として、競合他社を考慮した価格戦略やマーケティングが潜んでいます。 Power of Customers において、こちらが独占的なデータ提供者だとしたとき、売価をふっかけてもいいものでしょうか？当然、お客様は他の調達先を探すことになります。この点については別の理論が出現しますが、またの機会に譲りたいと思います。
法務
ここに来てちゃぶ台をひっくり返すことになりまして誠に恐縮です。この商品はそもそも売っていいのでしょうか？法的な問題があります。大きくは、原材料が何らかのデータベースであった場合は、そのデータベースを加工して販売してよいのか、というライセンス (契約) の問題と、著作権の問題が生じます。これは最初に検討しておくべき問題です。特に、データを生成するために利用されたパラメタについては注意が必要になってきます。例えば、自社ではない他社が注釈づけを行った教師データに基づき、何らかの学習を経て、得られたパラメタは誰のものなのでしょうか。 GitHub で公開されている学習器やパラメタを利用して生成されたデータの扱いはどうなるのでしょうか。ある種のライブラリは、当該ライブラリを使ってデータを生成したことを明示することを求めることがあります。お客様にデリバリ差し上げる商品にその旨を明示することは営業上、許容可能なのでしょうか。また、収集した公開情報を加工して販売することに著作権法上の問題は生じないのでしょうか。頭の痛い問題ですが、これらは早急に生産段階から明瞭にしておく必要があります。
管理会計
ヨシ！データという商品を販売することできました。万歳！……と快哉を叫び祝杯をあげ、べろべろに酔っ払いたいところなのですが、ところがどっこい、最後に本当に面倒な話をしなければなりません。管理会計です。社内で共通に利用され販売されるデータがあるとしても、部署によってその利用頻度には濃淡があるでしょう。生産部門でデータを生産していたエンジニアのお給料はどこから生じたものであるのか、ということを考えると、ある営業部門の売り上げとその売り上げにおけるデータの貢献度を計算する必要が生じてきます。しかし、そのような貢献度を明確に計算できるものなのでしょうか？あるエンジニアが特定の営業部門の仕事のみをしている場合は問題は単純です。しかし、エンジニアのチームが社内で横断的に利用されるデータを整備している場合、それはどうなるでしょうか。これはエンジニアの俸給にも関連する問題です。この問題についてはいまだに明確な回答を私は持ち得ていません……いえ、回答はあるのですが、計算式の算出、すなわち貢献度の計算を行うためには、営業部門の活動に関する専門的な知識と、生産部門が生産したデータの営業部門への貢献度とをすり合わせ、データの価値を売り上げから算出するため体系的な仕組みが必要となり、その方法論をいままさに模索している最中です。
まとめ
ここまでで、原材料の調達、加工、品質管理を含む生産管理、在庫管理を含む流通管理、さらに価格設定や管理会計といった様々な観点が、 GPU をぶん回すことに集中したいデータ・サイエンティストの周りにはうようよと存在していることがわかってきました。私の個人的な経験に基づきますと、これら様々な観点に対して誰かが俯瞰的に目配りをしない限りは、いくら高度な専門知識と経験を兼ね備えているデータ・サイエンティストのチームを編成しても結局のところ成果の極大化は難しいのではないか、と考えています。それは傑出した技術者集団を抱えていた企業が、市場から退出していった歴史となんら変わるところがありません。結局のところ、私自身は、ある特定の種類のデータを処理することにこれまで専念して参りましたが、実用化という観点においては失敗ばかりであり、それはこのような視点を欠いていたからであると認識しています。目下、私の関心は、ここまで述べて参りました、データに付加価値を付与しそれをお客様に提供する過程全体の最適化にあります。
この他の観点としては、財務会計があり、これはデータを資産として計上できないということ、すなわち生産されたデータが単なる費用として表現されてしまい、弊社内のデータの価値を外部の関係者の皆様から適切に評価していただきづらい、という問題を生じさせます。またそもそも、どのようなデータを保持していれば競争上の優位を維持できるのか、といった企業戦略も念頭に置く必要があります。これら様々な要素を加味しながら、関係する専門家の皆様と、データの最適な生産、流通、販売を実現することがデータ・オペレーションの仕事なのではないかと愚考する次第です。この長い記事を最後までお読みくださったことに心より御礼申し上げます。
最後に
弊社は人材募集中です！応募してください〜！お願いします〜！私を助けてください〜！「データエンジニア」および「機械学習エンジニア」でご応募いただければ、たぶん私が現れますので、ざっくばらんに、雑談をさせていただければ幸いです！ h.nishikawa@astamuse.co.jp にメールをお送りいただく形でも結構です！お待ちしております〜！
