前書き
db tech showcase Tokyo 2017 (db tech showcase Tokyo 2017 | db tech showcase)
A12 : KEYNOTE 2
これからの”本命技術”はこう見つける！～ポスト・リレーショナルデータベース時代を読み解くコツ～
のまとめ記事です。
本セッションはウルシステムズ社長 漆原さんと楽天執行役員 森さんの対談です。漆原さんは専らモデレータを務め、森さんによるお話がほとんどでした。
この前に行われていたKEYNOTEが前倒しになったようで、時刻通りに到着したタイミングではすでに始まっていました。よって、冒頭の部分は欠けていることをご容赦ください。
原則として自分のメモをベースに、Twitterのつぶやきを参考にしながら見直しを行いました。メモしきれなかった内容がTwitterに記録されている場合もありましたので、併せてご参照ください。
#dbts2017 since:2017-09-05 until:2017-09-06 - Twitter Search
10:23～11:28あたり。並行したセッションがないため、ほぼ本セッションに関する話題となっています。
【参考】としている個所は私が挿入しています（補足や参考資料など）。登壇者の講演内容ではありませんので、その旨ご了承ください。
DB技術のカンブリア爆発をどうみるか
単純なインサートだけならRDBである必要は無いという発想から、リレーショナルでないデータベースが増えた。
データの種類も量も増えるのに従い、データベースの種類も増えた。
非構造なデータが増えつつある。
一気にビジネスをスケールさせることを考えると、プラネットスケール（地球規模）で考える必要がある。BtoCのようなサービスで特にいえる。
マシンラーニングはトライアンドエラーの更新を繰り返すため、RDBと相性が合わない。これからはデータを時系列に見ることができるような、タイムアナリシスに向いたデータベースが出てくるのではないか。
これからの注目技術
マルチバンディットアルゴリズム。ABテストではAが全くダメだった場合にテスト期間が全て無駄になる。マルチバンディットはリアルタイムに反応を見ながら変化させられる。極端に言えば10万人に10万パターンを用意できる。まだ流行っていないが、これから伸びてくるかもしれない。
【参考】
バンディットアルゴリズムとは「複数の選択肢がある場合に、どのように選択を行うのが効率的なのか？という問題を解決するためのアルゴリズム」とのことです。
新しい技術ってどうやってみつける・知るの？
（新しい技術の情報をどうやって知るのかという問いかけに対し、）新しい技術はニュースになるが、それはみんなが知っている。相手の会社に行ってエンジニアと直接会い、営業抜きのトークをしたところにネタがある。
新しい技術を探すときはビジネスニーズから調べる。また、AIに関しては論文も調べる。
自社で技術開発するか、外部製品を導入するか？
インターネットサービスは基本的に成長し、データが増えていく。障害や保守体制も考える必要がある。自社だけでその体制を完璧に組むことはできないから、ミッションクリティカルなサービスでは自社も製品もベンダーも組み合わせて、どう進めていくかを考えないといけない。
ベンダーに入ってもらう以上、ベンダーには深く入り込んで欲しい。緊急時を考えると自社エンジニアも技術を理解していることが大切。その上で、バグを踏み抜いたときに一緒に協力して取り組めるかが大事。
クラウドサービスでは自分が作った数ヶ月後に同じようなサービスをGoogleが作ってしまったりする。これは起きるときは起こるし、どうしようもない。なので、考えるべきはどれだけ早く、自分たちの意味がある物にできるかということ。
やる気がある人にリソースをわたせば実現してくれることが多い。上から個人やチームに目標を与えてもイマイチ。やる気のある人が取り組んで成果を出せば、例え後発に追い抜かれたとしても、エンジニアが学んだことに価値がある。でも、それを実現してくれるようなエンジニアとアイデアが出るのは四半期に1回程度かな。
（新しい企画のジャッジはどこで決めるのか？という問いかけに対し、）大きなビジネスジャッジをすると規模が大きくなりすぎて、提案した人が中心になれないし、そのために集められたチームは上から言われたからやっているだけになってしまう。これをマネジメントするのが（森さんの）仕事だと考えている。
ベンダーロックインは構成管理といった周辺サービスとのつなぎや、ついてくるエンジニア次第では許容できる。
OSSでもコミュニティが見つけてないバグを踏み抜くことはあるし、そのときに対応できないと詰む。中のことをわかっているエンジニアか、中のエンジニアとつながっていないとベンダーロックインと変わらない。
外部APIは規約に注意する必要がある。データを流せるか？ユーザに承諾をとる必要がないか？社内で話題になっているAPIは事前にリーガルへ確認したりしている。
EOL(End Of Life)にどう対処するか？これはかなり大きい問題。計画した矢先にEOLを宣告されたり。相手と良好な関係を築いておくとこそっと教えてくれることも。コアなエンジニアと関係を作ることが大事。賞味期限（EOLの目安）は5年ぐらいか。
EOLがあってもデータへの影響は少ない。でも、データにロジックが入り込んでいると詰む。基幹系はカッチリ固めているので起こりにくいが、それ以外だとエンジニアが離れていくので起こりやすい。
本命技術の見極め方
過去10年でトランザクションのありかたが変わった。以前はER図を書ければ食っていけるといわれたが、今どきはER図を書けないエンジニアでも活躍している。つまり、それだけではないということ。
ラーニング（マシンラーニング、ディープラーニング）の欠点は戻せないこと。学習をロールバックできない。間違えた学習をやり直す必要がある。本来はこの時点からやりなおす、というのができないといけないし、これからはそういう用途が求められてくるはず。タイムラインで自由に戻せるというのが重用になるかもしれない。
（こない技術を見極めるために、その会社のリソース投資余力をみるか？という問いかけに対し）それは確かにある。参入障壁はデータや技術によるものだ。Googleはサービスを汎用の形で出してくる。そうではなく、ビジネスにマッチしたサービスを出すスタートアップは生き残れる可能性がある。
海外のエンジニアとリレーション（関係）を作るために、ディスカッションをできるかが重用。良いディスカッションパートナーになれないと、エンジニアが乗り気になってくれない。相手とクロスするポイントを作るために色んな事に深く興味を持っておかなければならない。
これからのエンジニアに期待することは？
サーバサイド、インフラサイドの知識が無いとスケールさせることができず、新しい技術に対応できない。データ系エンジニアであってもこうした分野を苦手とする方はいるし、一緒に協力し合えればよい。
バックアップの考え方が変わってきた。サービスレベルを考えれば、テープから戻さなくてもコピーから戻せば良いよね、みたいな発想もある。過去の常識がすでに陳腐化していないかを意識する必要がある。
最終的に大事なのは人だ。
