astamuse Lab

astamuse Labとは、アスタミューゼのエンジニアとデザイナーのブログです。アスタミューゼの事業・サービスを支えている知識と舞台裏の今を発信しています。

データ・オペレーション

データはいささか奇妙な性質を持っています。なんらかの事象の記録という観点では、それは文明の出現と時期をともにします。それが電子的に記録され、流通するようになってからは、まだ日が浅いものの、現在では、私たちの生活において決定的に重要な意味を持っています。

はじめまして。じんと申します。当ブログでは初のお目見えと相成ります。どうぞよろしくお願いいたします。弊社には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 について、慎重に吟味する必要があります。

このことから、データの一次加工物に対しては人手による系統的な品質管理が必要となることがわかります。その体制を構築することも一つの難しい問題です。

流通

在庫管理

さて、とにもかくにも、データが生産されました。当然、それはどこかに保管されます。現代であれば、クラウド上のストレージや何らかのデータベースにそれは格納されているはずです。もしここで、弊社が生産しているものがテレビであれば、生産されたテレビはどこかの倉庫に山積みになっています。データの厄介なところは、それに触れたり、物理的実体として視認することが難しいという点でしょう。例えば、在庫管理の担当者の引き継ぎが行われたとき、少なくとも、後任者は、倉庫にテレビが山積みになっていれば、いやあ、在庫が山積みだなあ……とすぐにわかります。データの場合、この引き継ぎが適切に行われなかった場合、そもそも在庫が山積みである、ということの認識すら難しくなります。いわゆるデジタル・ダッシュボードの果たす役割は実に重要なものです。

会計上、テレビのように物理的実体を伴って出荷を待っている資産は貸借対照表の流動資産の部に計上されます。問題は、データは流動資産としては計上されない、ということです。もしテレビの在庫が倉庫に山積みになっている場合は、それは棚卸資産として評価の対象となりますが、データは会計部門から捕捉されません。この性質もデータの取り扱いを厄介にします。ソフトウェアは無形固定資産として資産に計上できますが、それによって生じたデータは資産にはなりません。しかしデータが決定的に重要なのです。

その一方で、テレビが倉庫に山積みになっており、その倉庫の賃料を求められることと同じように、データもストレージを占有し続け、倉庫の賃料のように、着実に出費を強要してきます。加えて、データにも鮮度があり、古いデータより新しいデータの方が当然有用性が高い場合が多くなります。

雑駁に述べて参りましたが、データは在庫としては以下のような性質があることがわかります。

  1. (データの取り扱いに習熟していない限りは) 直感的に捉えづらく在庫の実態の把握に工夫が必要
  2. 会計部門から監視されないため棚卸しの機会を強要されない
  3. 維持に費用を要する上に徐々に価値が低下していく

言うまでもなく、 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 にメールをお送りいただく形でも結構です!お待ちしております〜!

BigQueryのINFORMATION_SCHEMA VIEWSを触ってみました

データエンジニアのaranです。
月日の流れは早いもので、今年の1月以来3回目の登場になります!

いきなりで、すみませんが
最近ハマっているテレビは、NHKの「みんなで筋肉体操」です。

パワーワードは「自分に甘えない!」です。

この言葉を自分に言い聞かせ、7月中旬から筋トレと1時間弱のウォーキングをしています。
2ヶ月継続したのですが、このブログを書いている時には、高校時の体重に戻りました。
次は体脂肪率も戻そうと頑張っています。

前書き

前回は、BERTについてお話しさせて頂きました。

今回は自然言語処理から離れ、データエンジニアらしく?
BigQueryのINFORMATION_SCHEMAについて調べましたので
そのお話しをさせて頂きます。

何でまた?

弊社では、特許情報を取り扱っており
ある特定の業界・分野の特許群を検索するのに、BigQueryを活用しています。

目的の特許群を検索するには、
いろいろな単語を組み合わるため、検索条件が複雑になり
トライ&エラーを繰り返すため
BigQueryの費用がかかりがちになります。

また、社員の増加によりBigQueryの利用頻度が増えるため
更なるBigQueryのコスト増が予測でき
コストの見える化、コスト削減策の早期実施が
より重要になってきます。

そこで、2020年8月にINFORMATION_SCHEMA VIEWSが一般提供したこともあり
メタデータを可視化することで、コスト削減箇所を炙り出せるのでは?
と、淡い期待を抱き、調査することにしました。

INFORMATION_SCHEMAについて

INFORMATION_SCHEMAとは
データセット、ジョブ、テーブル、ビュー等のメタデータへのアクセスを提供する一連のビューです。

INFORMATION_SCHEMAの詳細については、
BigQueryの公式ドキュメントで確認できます。

尚、INFORMATION_SCHEMAにアスセスする場合、料金が発生します。
制約等を含め、公式ドキュメントを確認の上、アクセスすることをおすすめします。

INFORMATION_SCHEMAのアクセス方法

INFORMATION_SCHEMAには
リージョン修飾子.INFORMATION_SCHEMA.ビュー
でアクセスできます。

例えば、データセットのメタデータにアクセスするには、以下のSQLを実行します

SELECT * FROM `region-us.INFORMATION_SCHEMA.SCHEMATA`;

また、テーブルに関しては、リージョン修飾子の部分をデータセットIDにすることで
指定したデータセットのテーブル メタデータを取得できます。

SELECT * FROM `dataset_id.INFORMATION_SCHEMA.TABLES`;

BigQueryのコストについて

先程、INFORMATION_SCHEMAにアスセスする場合、料金が発生すると説明しましたが
BigQueryの料金について軽く触れたいと思います。

詳細については、公式ドキュメントにおまかせすることにしますが
BigQueryの料金は大きく2つから構成され

  • ストレージ料金
  • クエリ料金

ストレージ料金は、データを保持する期間とデータ量で課金され
クエリ料金は、SQL実行時に読み込んだデータ量で課金されます。

BigQueryのコスト削減方法はいろいろあると思いますが
今回は以下の2つに絞って、話をすすめたいと思います。

  1. ストレージの削除:削除可能な不要なストレージ(データセット)を見つける
  2. 定額料金の利用:定額料金(スロット数)を見積もる

そこで、INFORMATION_SCHEMAのメタデータを使い
以下の3点を把握できるか調査しました。

  1. データセットのレコード総数とデータ総量の把握
  2. 90日以上アクセスがないデータセットの把握
  3. 定額スロット数の把握(概算見積もり)

データセットのレコード総数とデータ総量の把握

まずは、データセットのデータ総量とレコード総数を調べてみたいと思います。
こちらを把握できれば、毎月のストレージ料金の概算
並びに、レコード数の増加による料金増加率の見積りを期待できます。

データセットのデータ総量とレコード総数は
データセットID.__TABLES__より取得できました

-- データセットのレコード総数とデータ総量を取得
SELECT
  dataset_id,
  FORMAT("%'d", SUM(row_count)) AS row_count,
  ROUND(SUM(size_bytes) /(1024 * 1024 * 1024 * 1024), 2) AS size_tb
FROM
  -- データセットIDは、環境に合わせ適宜変更して下さい
  データセットID.__TABLES__
GROUP BY
  dataset_id
;

尚、今回の調査では、1つのSQLで全データセットを集計する方法は
わかりませんでしたので
データセット分のSQLをUNION ALLでつなげた形で取得しています。
(ご存知の方いらっしゃいましたら、ぜひお教え頂ければと)

一部抜粋した形になりますが、弊社環境で利用しているデータセット一覧は
以下のようになりました
(データセット名はマスキングしております)

f:id:astamuse:20200922235235p:plain f:id:astamuse:20200922235254p:plain

尚、今回の利用しているプロジェクトは特許関連情報を管理しており
アプリのアクセスログ等のように、データ件数はそこまで多くありません。

本SQLを実行することで、用途を把握できていないデータセットや
想定以上にデータ量が多いデータセットが存在していることも
恥ずかしながら、わかりました。。

90日以上アクセスがないデータセットを洗い出す

次に、各データセットへの最終アクセス日(最終クエリ実行日)を取得して
90日以上アクセスがないデータセット一覧を洗い出せるか
調べてみたいと思います。

こちらを把握できれば、長期保存に移行したデータセット有無
並びに、データセットの削除やCloud Storageへの移行等が検討できます。

こちらは、 INFORMATION_SCHEMA.JOBS_BY_*を利用することで
取得できました。

SELECT
  s.schema_name,
  j.latest_creation_time
FROM
  `region-us.INFORMATION_SCHEMA.SCHEMATA` AS s
LEFT JOIN (
  SELECT
    referenced_table.dataset_id AS dataset_id,
    MAX(creation_time) AS latest_creation_time
  FROM
    `region-us.INFORMATION_SCHEMA.JOBS_BY_PROJECT`,
    UNNEST(referenced_tables) AS referenced_table
  WHERE
    referenced_table.table_id != '__TABLES__'
  GROUP BY
    referenced_table.dataset_id ) AS j
ON
  j.dataset_id = s.schema_name
-- ジョブメタデータにアクセス履歴がない、または最終クエリ実行日より90日以上経過したデータセット
WHERE j.latest_creation_time IS NULL
  OR j.latest_creation_time < TIMESTAMP_SUB(TIMESTAMP_TRUNC(CURRENT_TIMESTAMP(), DAY), INTERVAL 90 DAY)
;

注意点として
データセットのレコード総数とデータ総量の把握で実行したSQLを対象外にするため
WHERE句に referenced_table.table_id != '__TABLES__' を追加しております。

尚、弊社環境で本SQLを実行したところ
90日以上アクセスがないデータセットが1つ
INFORMATION_SCHEMA.JOBS_BY_*にデータがない(180日以上アクセスがない)
データセットが17つありました。
(※ドキュメントでは、完了したジョブの過去 180 日間の履歴を表示との記述がありますが、弊社環境では100日程度の履歴でした)

定額スロット数の概算見積もり

最後に、定額スロット数の概算見積もりができないかを
調べてみたいと思います。

こちらを把握できれば、クエリ実行毎で課金されるオンデマンドより
定額料金への移行、並びにスロット購入数の見積りを期待できます。

スロットの詳細については、BigQueryの公式ドキュメントにおまかせします

スロット使用率については、 INFORMATION_SCHEMA.JOBS_BY_*を利用することで取得でき
公式ドキュメントのサンプルSQLを参考にし、月平均のスロット使用率を取得してみました。

SELECT
  DATE(TIMESTAMP_TRUNC(creation_time, MONTH), "Asia/Tokyo") AS month,
  COUNT(1),
  -- 月平均のスロット使用率
  SUM(total_slot_ms)
    / (1000*60*60*24* 
        -- 日付を抽出
        EXTRACT(DAY FROM 
          -- 月末日を取得
          DATE_SUB(
            -- 1ヶ月を加算
            DATE_ADD(
              -- 月初日付を取得
              DATE(TIMESTAMP_TRUNC(CURRENT_TIMESTAMP(), MONTH), "Asia/Tokyo"),
              INTERVAL 1 MONTH
            ),
            INTERVAL 1 DAY
          )
        )) AS avg_slots
FROM
  `region-us`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
GROUP BY
  DATE(TIMESTAMP_TRUNC(creation_time, MONTH), "Asia/Tokyo")
;

尚、弊社環境で、本SQLを実行したところ
以下のようなになりました。
(棒グラフがクエリ実行数、線グラフがスロット使用率)

f:id:astamuse:20200922220642p:plain

6月は、他の月よりクエリ実行は少ないが
データ量が多いテーブルへのアクセスが多く
スロット使用率が多いことがわかりました。

最後に

INFORMATION_SCHEMAへの単純なSQLでも
メタデータの把握・可視化ができ、コスト削減できる箇所が
ある程度見えました。

今回は、単純な単位での集計でしたが
更に時間帯別やテーブル単位やユーザ別での集計・分析も
必要になります。

今後もINFORMATION_SCHEMAを使って
更なるメタデータの把握に努めたいと思います。
それ報告はまたの機会に。

アスタミューゼでは、エンジニア・デザイナーを募集中です。
ご興味のある方は遠慮なく採用サイトからご応募願います。是非、お待ちしています。

UIを選ぶとき考慮すべき4つのこと

f:id:astamuse:20200826100717j:plain こんにちは。デザイン部でフロントエンドエンジニアをしているkitoです。
今回は、アプリを作成する際、最適なUIを選定する4つの指針について書きたいと思います。

UIは、人間の心理や認知に深く関わり、アプリへの信頼性を左右する重大な要素ですが、我々がアプリを作成するとき、ほとんどの場合直感的にUIを選択しています。経験豊富なUIデザイナーなら、その直感は間違っていないことが多いでしょう。

ただ、そうはいってもUIはUIデザイナーだけで決定できるわけではないので、直感を言語化して共有することがプロジェクトを前進させる力になります。本文は、学術的な内容ではなく、数多くのUIを実装してきた「現場」からのひとつの私見として書きたいと思います。

UIって?

UIがユーザーインターフェイスの略であることは言うまでもないですが、そもそもUIがアプリで果たしている役割とは何でしょうか。

よくあるUIであるモーダルを例にして考えてみましょう。モーダル型のUIは、ユーザーがボタンをクリックすることで小さなウインドウが展開されて新しい情報が出現します。当たり前のことを言うようですが、UIには、このように隠されていた情報を出現させる役割があります。   

では、なぜ予め情報を隠すのでしょうか。
それは、あらゆる情報が整理されず一挙にユーザーに提供されれば、ユーザーの認知的負荷が上昇しアプリに対する信頼性を低下させるからです。アプリの信頼性が下がれば、自ずと利用率は下がるでしょうしコンバージョンも低下していくでしょう。 見方を変えるなら、UIを作成する作業は情報を整理して隠す作業であると言えます。

1.情報の量と質

UIを決定する主な要因は、情報の量と質です。

ツイッターなどで採用されているタイムライン型のUIを思い浮かべてください。
あのような情報が流れるタイプのUIが採用されているのは、ユーザーが接する情報が膨大でかつ個々の情報を見逃したとしてもクリティカルではないからです。

ツールチップは、少ない情報を付加する際に有効でしょうし、バリデーションのアラートは、情報としては少量ですが、質としては確実に視認させなければなりません。
ただし、情報の質と量が変わらなかったとしても、ユーザー環境の変化で、UIの流行り廃りはあります。

例えば、スマートフォンが普及したことで、Webサイトは縦型になり、スクロールさせるUIやトグル型のUIでコンテンツを折りたたむことが増えました。また、iPhoneでflashが動かないので、その代わりとして、パララックス型やカルーセル型のUIが流行しました。

2.優先度

情報の質のなかでも、その情報がどれぐらい優先度の高い情報であるのかもUIを決定する上で無視できません。優先度によって、情報を表示する場所やタイミングが決まってくるからです。
優先度の高い情報は、アクセス時に画面を専有させたUIで表示させたり、headerの直下など視認性の高い場所に表示します。

情報の優先度は、ビジネスサイドの判断が不可欠なことが多く、UIデザイナーやフロントエンドエンジニアだけで決められるわけではありません。 もっとも、問題になるのはビジネスサイドも情報の優先度を知っているとは限らない点です。

行政のサイトなどでよくある、注意喚起のメッセージが画面のほとんどを専有して、眉をひそめるようなファーストビューになっているサイトを見たことがあるかもしれませんが、これは情報の優先度の決定がうまく機能していないからです。注意喚起やalertメッセージを羅列しても、ユーザーの認知負荷が高まり離脱してしまえば、注意喚起は注意喚起として機能しません。

いらぬ詮索かもしれませんが、行政のサイトを運営している公務員の言い分を忖度するなら、彼らとしては、ある市民にとっては重要な情報であるけれどある市民にとっては重要でないという、多様なユーザーを相手にする行政組織の特殊性や、また公務員の人事評価が減点主義なので、注意喚起のメッセージを表示させないリスクの方が、情報を整理して埋もれてしまうリスクより大きいのかもしれません。
なんにしろ、UIがそれを運営している組織のロジックに影響されるのは、妙なことですがありえることです。

UIの優先度は、ビジネスサイドとのコミュニケーションで解決することが多いですが、解決しない場合は、コストはかかりますがA/Bテストを提案してUIをユーザーに決めてもらうのも一案です。
(なおA/Bテストの限界については、過去私が書いたこのエントリーが参考になるかもしれません)

3.学習済みUI

UIを選定するうえで、そのUIの使い方について想定しているユーザーが学習済みであるかどうかも考慮するポイントです。

ハンバーガーメニューは、一般的な学習済みのユーザーであるなら、メンタルモデルが出来上がっているのでサイトを回遊するためのメニューが隠されていると認知できます。
一方、ITに疎いユーザーにとっては、ハンバーガーメニューは三本線の謎の模様に過ぎず、何ができるのかすぐには把握できないでしょう。だからハンバガーメニューを使うべきではないと言いたいわけではなく、UIの選定に想定ユーザーのリテラシーを考慮すべきだと言いたいのです。
UIデザイナーやフロントエンドエンジニアは、なまじ自分がUIについてよく知っているだけに盲点になりがちです。

ITに疎いユーザーを対象にアプリを作成するなら、ハンバガーメニューを使うとしても下に文字で「メニュー」と情報を付加するような対応が考えられます。
ヤフーのiPhoneアプリでは、様々なユーザーが使うことを想定してか、画面下部のナビゲーションには、アイコンと文字が並べて表示されています。こういったことが参考になるでしょう。

また、優れたUIは新規につくるというより既にあるものなので、デバイスに標準的に備わっているUIかBootstrapのような広く使われているUIライブラリを優先的に使用したほうが、ユーザーの負荷だけではなく実装の負荷も低くなります。

4.考えさせない

ユーザーに考えさせないでという観点も重要です。

単にスムーズに使えて認知的負荷がかからないというだけではなく、人間が意識していない「無意識」にアプローチする手法です。
例えば、アプリの最上部と最下部は、コンテンツの両端にあるので人間の認知として注目しやすい場所です。無意識に目が行きやすい場所なので、コンバージョンポイントやナビゲーションが設置されることが多いはずです。UIの設置場所や目線の導線を適切に設計するなら、ユーザーの意識に顕在化させる前に意図した行動を促せるでしょう。

また、UIに没入させることを少し考えてみても良いかもしれません。ボタンをクリックしてスッと画面が切りかわり、それがなんとなく心地よいので気がつくと登録フォームを完了していたということがあります。
正直言って胸を張って言えることではないですが、ユーザーが熟慮の末、慎重にボタンを押さなければならないUIは良いUIではなく、(適切なマーケティングで集めた対象ユーザーを)軽率に登録させるUIの方が良いUIと言えます。

あるいは、バナーデザインでよくある、人間が美男美女を無意識に信頼してしまう傾向を利用し、美男美女の画像を掲載してサイトの信頼性と混同させる手法がありますが、UIデザインにおいてもこの手法が使えるでしょう。
例えば、信頼性の高いデータを心地よいUIで見せることで、サイトへの信頼性と混同させ・・・
人相が悪くなってきた気がするので、今日はこのあたりで終わりたいと思います。

アスタミューゼでは、エンジニア・デザイナー・PM・コンサルタントを募集中です。ご興味のある方は遠慮なく採用サイトからご応募ください。お待ちしています。

Copyright © astamuse company, ltd. all rights reserved.