7/14(2020)に開催された、「第5回データアーキテクト（データ整備人）を"前向きに"考える会」の感想です。

なお、私自身はデータ整備人と言うよりは、整備人の方に様々な整備抽出をお願いする分析者の立場なので、そちら方面から見た感想になると思いますが、とはいえ分析者も、現状は手間の8割がデータ整備なので、内側の視点もあるかもしれません。

あと、私はデータアーキテクト、データ整備人のことを「データエンジニア」と呼んでいますので、以下、そのように記します。

なお、当日の資料はすべてcompassにあがっていますので、ご参考になさってください。私もそれを見直しながら書いています。

抽出の仕事をうまくやるために必要なこと / しんゆうさん

データ抽出の位置づけについての解説。「抽出はデータ分析プロセスの一部」は本当にこの通りで、だいたいデータ分析とは、仮説を検証しうるデータ抽出と加工ができてしまえば、あとはボタンを押すだけ。なので、分析屋は、仮説を検証しうるデータを想像し、あたりをつけて、それを損なわないような形で抽出し、加工し、最後に分析器に掛けるのですけれど、そのほとんどの部分をデータエンジニアが担うことになるんですよね。まったく、分析プロセスのほとんどをデータエンジニアが担うといっても過言ではないです。

その意味で、私はデータエンジニアとデータ分析者（もしくはデータサイエンティスト）はほぼ同義だと思っていて、ただ違うのは、統計的、もしくは高度計算技術的に不安な状態になったとき（例えば、サンプルが少ないにもかかわらず明らかな違いが出ていないとき）に、それを偶然なのか有意に差があるのかを統計的に判断できるかどうか、その程度です。つまり、データエンジニアは、技術の方向は統計解析よりはデータハンドリングやシステムエンジニアリング方面に向いているけれども、そのマインドにおいてデータ分析者であってほしいし、あるべきだと思っています。（なぜそうなのかは第3回の資料で書いた気がします。）

だから、「たかが抽出」などでは決してなく、その抽出、どのように取得されたサンプルから、どのようにサンプリングされて、どのように加工して、どのように見せたか、その一つ一つが分析プロセスであり、結果に大きく影響を与えるファクターになっています。

たまに聞くのが、「データエンジニアは言われたとおりデータを出せばいいんだよ」っていう乱暴な意思決定者。「言われたとおり」出せるくらいにDBの状況を知っているなら、自分でSQLたたけばいいじゃん。現在の情報システムは、意思決定者が思っているほど単純じゃない。「○○をもってきて」と言われて、それが何を意味するのか。様々な意味のブレ、ズレがあるなかで、思った通りのデータを思った通りの加工方法で持ってきてもらうには、普段から意思決定者や分析者のマインドをデータエンジニアが知っておく必要がある、つまり、データエンジニア自身が意思決定者マインド、分析者マインドをもっていなければならない。そうだからこそ、思った通りのデータを、思った通りの抽出、加工で持ってくることができる。それができれば、あとは意思決定者は決断するだけだし、分析者はボタンを押すだけ。

過去何回かの整備人イベントでほぼ全員が繰り返し仰るのは、データ整備人の価値の源は「コミュニケーション」であるということ。SEと話すときにはSEマインドで話し、意思決定者や分析者と話すときは意思決定者マインド、分析者マインドで話す。めちゃめちゃ難しい、重要な役割です。「『雑用』という人とは適度な距離を置く」「会社の方針ならばデータを活用することの未来は暗い」もまさにその通りで、意思決定者のマインドが変わるよう説得するか、もしくはもっと求められるところに転職するか、いずれにしてもミスマッチのまま放置していいことは何もないです。

片手間でもできる！BIレポート整備人のためのガイドライン / ウィルさん

「BIレポート」に特化した興味深いお話。「ゾンビレポート」というキーフレーズが痛い（笑）。ホントそうで、誰も見ていないレポートを作り続けることの虚無感たるや・・・。

あれもみたい、これもみたい、それも必要、で、てんこ盛りになるのは、見たいという側にコスト感が伝わっていないから。データエンジニアは社内的には固定費コストなので、なんでも突っ込まれがちですが、そのせいで他にやるべき重要な作業ができなくなるのは辛いです。

だから、レポートの費用対効果をちゃんと考えましょう、ということで、p11の「例外、誰かのインセンティブに直結する可視化はやるべき」はまさにその費用対効果の「効果」の部分が大きいレポートになります。

p10の診断チャートも、費用対効果で見ればわかりやすい。いいパターンは、「費用はかかるけれどそれ以上に効果がある」「効果は薄いけれど、費用を低く抑えられる」で、悪いパターンは「めちゃめちゃ手間がかかるのに効果が薄い」になっています。

クラウドの時代になってきて、レポート用のデータはDWHから直接作れるようになってきているので、自動作成もかなりしやすくなってきました。また、BIもある程度機能を絞り込むところまで画面を作って上げれば、ITに疎い経営者でも扱えるようになってきています。全体的に仕組みのコストはどんどん下がる方向ですので、人件費が最も高くなっています。そのレポートを作るのに正味何時間かかっているかに人件費単価を掛けて、レポートの価格を出しておくと、いろんな目安になるので話しやすい、説得しやすいと思います。

「#前向きデータ整備人」を参考にデータ基盤を立ち上げた話 / おおたさん

Cloud Composer × Big Query × Looker ということで、まさに理想的な環境です。すべてのデータエンジニアが垂涎ではないでしょうか。

逆に言うと、多くの現場はいろんな障壁があって、このような環境を作りたくても作れない理由があると思います。システム側からの要請（現行システムやSIerとの関係性、セキュリティの問題、・・・）だったり、経営者側からの要請（コスト）だったり。

改めて資料を見直していますが、データエンジニアリングとして完璧ですね。問題意識から実行まで筋が通っていますし、将来にもちゃんと意識が向いて、意思決定者とデータエンジニアとのコミュニケーションが十分円滑な様子が伝わってきます。同じように立ち上げを検討している方は、この理想型をぜひご参考になさってください。また、理想型から外れそうになったときは、何が阻害要因なのか、なぜこれがウチではできないのかをよく考えると、突破口が見えるかもしれません。

あとは、今後これをどのように組織として維持するか。立ち上げ当初は、何も無いところに理想的な構築ができますが、この先だんだん人が増えると些細な利害対立が積み上がりますし、人が入れ替わると理念が薄れたり、失われたりします。少しずつ理想から離れていくのが、よくあるパターンです。そうならないような仕組み作り、マインド作りをどうしていくか。こうなるともうデータエンジニアリングの範疇を飛び越えて、組織論ですね。永遠の課題だと思います。

DataOpsという観点からデータ整備人を考える / ぼうさんさん

大きな市場はIBMさんと一緒に動きます。データアーキテクト、データ整備人、データエンジニア・・・この整備人イベントに参加していらっしゃる方々はこの分野でのイノベーター～アーリーアダプターですが、それだけでは市場は動かない。IBMやNTTデータ、FNHが動き出して初めて、国内のレイトマジョリティ～ラガードが本格的に動き始めます。その意味で、IBMの方がここでお話ししてくださったのは、市場の拡大に繋がるターニングポイントになると思います。

一方で、やはりまだそういった大手SIerさんたちのマインドが、「モノ売り」から抜け出せていないんじゃないかというのが気になります。サーバーを売る、クラウドを売る、ソフトウェアやサービスを売る、そのオペレーターとしての「データ整備人＝データスチュワード」がいる、そういう見方をしている限り、データエンジニアリングをいくらレイトマジョリティ～ラガードに売りつけたところで、「使えない」烙印を押され、Buzzwordとして消費され、ハイプサイクルを下った先には幻滅しか残らず、また大挙して別の新しいバズワードに群がっていく、そういういつか来た道を、データエンジニアリングの業界では繰り返したくない。

データエンジニアリングはコミュニケーションであり、その中心は人であり、最重要課題は人材育成です。サーバーや、クラウドや、サービスではない。

IBMさんは大きいので、別の方にも同じ話をしたことがありますが、どこまでご理解いただけたかは今後注目していきたいと思います。今のところ、大手SIerの中でIBMさんが一番近いところにいるように思います。一方で、ヒトは投資対効果が高々linearなので、経営判断として避けるのもアリだとは思います。

繰り返しますが、データエンジニアリングは人です。モノからヒトへの転換が図れるでしょうか。この整備人イベントに集う人たちは、他のご発表でもわかるように、すでに十分な「データエンジニアリングマインド」を持っていらっしゃいます。この人達をサポートして、情報共有の場を作り、横の連携を支援し、適切な部場所とのマッチングを行う。一方で、まだ市場に参入していない、本質的にはデータエンジニアリングを必要としつつも、まだそこに到達していない不慣れな意思決定者を啓蒙し、みんなが喜ぶ大きな市場を作って刈り取るのが、巨人IBMのやるべきことなんじゃないかなと思います。

ゼロから作ったデータサイエンス組織で意識した事 / 高橋さん

データサイエンティスト不在で社内にデータサイエンスグループを作った、とのことでしたが、全く不思議ではありません。本来のデータサイエンス、その意味を推し量るにデータ分析とは、「仮説～検証のプロセス」です。このプロセスはなんら特別なことではなく、ましてや「データサイエンティスト」と最近呼ばれるようになったごく一部の特殊能力者だけが持っている技術ではない、世の中のほぼ全ての人が、程度の差こそあれ、当然のようにやっていることです。

例えば、「勘と経験」はデータ分析です。

経験値というインプットに対して、脳細胞が適応して、何らかの事象に対して判断する、意思決定すること。例えば、朝の空の様子を見て、田んぼの水の量を調整する農家の方、これはまさに「データ分析」です。空の様子という画像情報について（もしくは、それに気温や湿度なども検知して）、過去の自身の経験からその日の雨を予測し、水の量を制御しています。そんな難しいことに限らず、チラシを見て今日行くスーパーを決めるとか、お客さんの顔色をみて何を握るか決めるとか、これらすべて、自分の感覚器から入ってきた情報を分析し、意思決定をしています。

大学で学ぶすべての学問も、データ分析です。仮説と検証を、より顕示的な方法で実施します。これは理系文系関係ありません。例えば何らかの古文書が見つかったとき、「これは○○ではないか」と仮説を立て、それを検証するために様々な情報を収集し、論理的帰結に導く作業はデータ分析のプロセスですし、理想の色に近づくために炉の中の配置や釉薬の配合を様々に変えて試すことも、データ分析のプロセスそのものです。

ですから、データ分析は俄に「データサイエンティスト」と呼ばれるようになった人たちだけの技術ではなくて、すべての人が持っていて、かつ、高等教育を受けた人は既に体系的にそれを学んでいると言っていい。

本事例は、「データサイエンティスト」不在だったからこそ、逆に狭義の「データサイエンス」の、理解しがたいキーワードに振り回されなかった分、理想的な組織作りができたのかもしれません。もちろん、データサイエンス自体の研究領域ではそれらは大いに意味があるし、人類の進化を支えているアクティビティの一つであることは間違いないのですが、新しくデータサイエンス組織を作る現場にはミスマッチです。それよりもむしろ、こういう場所には経営学などの方がぴったり合うと思います。OKRなども出身は経営学方面の用語だろうと思うのですが（似たようなキーワードはたくさんあるのですが、本質的に考え方は同じですので、キーワード自体を気にする必要はあまりないです）、そういうマインドを持って、データを集計、可視化できれば、勘と経験からすこしだけ拡張したデータ経営には必要十分です。いきなり非線形とか、機械学習とか、そういうややこしい概念に手をつけてもほぼ失敗します。

全員がSQLを書ける、の裏側に暗黙に隠れているのが、全員が「何のデータがどういう名前でどこに格納されているか知っている」ことです。SQLを書けるというのは、抽象的、一般的なSQLの文法だったり、プログラミングのような技術のことを指すのではなくて、データの所在と素性を脳みそに叩き込むことにあたります。そして必要なのはSQLの教科書ではなくて、実際のテーブルだったり、それを集計した結果だったり、そのクエリに至るまでの仮説だったりします。だから、現場にほどよく近くないといけない。データを活かせるかどうかは、そのデータが一体何なのかをどこまで深く知っているかにかかっています。データの素性を知っておくことは、データエンジニアの最も大切な仕事の一つです。（もう一つは、何をしたいか。意思決定者側。）あとは書くだけです。

最後に統計的効果検証手法が掲載されていますが、これもいい感じですね。ここでいきなり機械学習とかAIとかに飛びつきがちですが、そんなのが有意に活かされる現場はほとんどありません。それよりも、地に足をつけて、集計、可視化の次に必要になる手法はここにあるような統計手法です。一足飛びに駆け上がってけがをするよりも、着実に一歩一歩登りましょう。

おわりに

ということで、今回も非常に興味深いご発表揃いでした。ありがとうございます。自宅にいながらこういう貴重なお話をきけるって素晴らしいですね。特に、東京以外の方にとってはメリットめちゃめちゃ大きいのではないでしょうか。

あと、最後に、本イベントがこうだったらいいな的な話。

アンケートにも書いたのですが、やはり質疑応答があったら嬉しいです。準備してきてくださった内容を聞くことに大きな価値があることは前提として、しかし、全てを知っている登壇者と、あまり知らない側のオーディエンスとでは情報落差があるので、いまいち伝わらなかったり、そこもうちょっと聞きたい、ってところもあると思います。

一方で、既に500人超えの大所帯になっているイベントですから、聞いているときりがないのもまた真。

そこでアイデアですが、登壇者同士で質問し合うのはいかがでしょうか。質疑応答は、自分が質問したいことは結構誰かが質問してくれますので、登壇者が聞きたいことは、オーディエンスが聞きたがっていることとだいたい似通っていると思いますから。ただ、登壇者の負荷が増えるのが難点ですが・・・。もちろん、しんゆうさんおよび登壇者の皆さんのご意向最優先で。