リサーチ業界からDB業界へ転職して

13年過ごしたリサーチ業界から、ECサイト系DB業界へ転職して早1年。
全くの未経験だったので、必死に知識と技術を取り入れる日々を過ごし、気が付いたら1年経っていた・・・というのが正直な感想です。
そんな1年を振り返ってみようと思います。

転職しようと思ったキッカケ

以前の私は、集計を中心に、リサーチ業界でデータの前処理や加工などの仕事を個人で受けていました。
業界としては、リーマンショック以降、会社の統廃合などで業界再編がしばらく続き、コスト削減のために中小のリサーチ会社も集計部隊を自前で抱えるようになりました。

様々な会社の方と話してみた経験から、リサーチャーは専門分野を突き詰める職人気質な方が多く、管理職クラスでも（専門分野外の）経営に関する感覚に乏しいと思われる方は少なくありませんでした。
そのためか、「外注費を減らせば利益が増える」と考えて人を雇った結果、外注費よりも多い人件費が増えることになり、自分で自分の首を絞めているようなリサーチ会社もありました。

これに対する私の予想は、「数年したら、『なぜ外注費を削減したのに利益が減っているのか』の原因に気付いて、再び外注するようになるだろう。」というものでした。

しかし、実際にはそうならず、小さい会社が大手の傘下に加わったり、吸収されたりする動きが目立ち始めました。
この時点で、今の仕事が先細ることはほぼ確定したので、時代の流れに合わせた新たな分野（購買データなどの大規模データ）に手を広げようと考えました。

当然ながらその分野で仕事を受注するには高度な知識と技術が必要で、未経験の人間がいきなり参戦できるような甘い世界ではありません。
かといって、経験を積むにも、その環境を整えるだけの資金力もありません。

ここで、「そういう経験を積むことができる会社に入る」という選択肢が頭をよぎりました。
それまでそんな発想は出てこなかったのですが、そういう選択肢が出てきたということは、そういうステージへ移るタイミングなのかもしれないと思いました。
『やり切った感』が強かったためか、自分でもビックリするくらいスパッと廃業と転職を決断できました。

現実は厳しい

いくつかの人材紹介会社で面談をしましたが、いずれも「経歴が中途半端」という評価でした。
「（かなり拡大解釈して）リサーチ業界経験者」としても「プログラミング経験者」としても「その分野で3年程度経験」という程度にしか評価されず、かつ未経験の分野を希望＆管理職経験も無いということで、選択肢は限りなくゼロというのが現実でした。
当然、人材紹介会社としては、これまでの経験を活かせる同業他社への転職を勧めてきましたが、それは全く考えていないことを伝えると、どこもパッタリと連絡が途絶えました（笑）

分野の掛け算で予想外の評価

そんな状況をフェイスブックに投稿すると、ある方から連絡が来ました。

「私なら希望するお仕事を紹介できるかもしれません。」

そこで、その方に相談してみると、人材紹介会社の人とは真逆のことを言われました。

「『リサーチ業界経験者』で『プログラミング経験者』、実務も土台・裏方もある程度のレベルで知っている人は、実は少ないです。
その２つの領域を掛け算で考えれば、評価はかなり高くなります。
人材紹介会社でこういう見方をできる人は、殆どいないでしょうね。」

その方から（条件的に無理なので）全く考えていなかった会社を紹介されました。
条件に満たない部分（SQLなんて触ったこともない）もあるけど、向こうが求めている人材にピッタリと合うからと。
とはいえ、今後この業界でデータを扱うなら、SQLは避けては通れないだろうと思い、面接までの数日間の間に、 MySQL でクロス集計ができる程度まではSQLをいじってみました。

面接ではSQLについても聞かれましたが、正直に自分の今のレベル感を伝えました。

面接官
「SQL は未経験なんですね？」
私
「はい。ですが、こちらの求人票を見てから、自分の PC に MySQL を入れまして、ネットで調べながらクロス集計までは作ってみました。」
面接官
「おー、そうなんですね。触ってみた感想はどうでした？」
私
「プログラマーとかのレベルに達するのは時間がかかると思いますが、データの処理に使う関数は限られてくるでしょうし、文法？・・・は意外とシンプルなので、通常業務に必要なレベルに扱えるようになれるのは、それほど時間がかからないと思います。」

結果的に、このやり取りが評価され、今の職場に拾っていただきました。

入門書が役に立たない圧倒的なデータ量

入社までに入門書で SQL の自習をし、いざ入社してデータを扱ってみると、入門書が全く役に立たないという現実に衝撃を受けました。

データは『SQL で抽出・ダウンロード、Python で加工、R で解析』が定石

みたいなことが書かれていたのに、そもそもデータ量がダウンロードできるサイズじゃない（笑）
抽出したログデータは、今まで聞いたことがないような件数。
もちろん、データを処理するサーバーは他の方も使っているので、下手な処理をするとサーバーに負荷がかかり、他の方にも迷惑が掛かります。
最初の 2 ヶ月くらいは「これがビッグデータの世界か・・・」と痛感させられる毎日でした。

SQL ・・・慣れない、読みにくい

SQL は、1 つの処理なら理解できるものの、複数並ぶと処理の流れがなかなかイメージできず、処理内容を追いかけるのが大変でした。
また、使用しているテーブルの数も 1 つや 2 つではないので、基本 1 つのデータファイルで完結しているアンケートデータを扱ってきた私には、その関係性を把握するのにとても苦労しました。

結局、初見でも SQL の内容と流れをある程度把握できるようになるまで、3 ヶ月程度かかりました。
これは、SQL に対する慣れの他に、扱う Database の理解も進んだことが影響しているものと思われます。

Row Data 的発想から Transaction Data 的発想へ

Row Data（アンケートデータのような、1 人のデータが 1 行（row）で表現されているもの）では、「必要なデータを処理・加工してから集計」が基本になっています。
一方、Transaction Data は、操作単位（取引、アクセス、クリックなど）でデータが入っているので、当然同じ人の一連の処理が複数行に入ってくるし、データ量も膨大になってきます。

目的にもよりますが、基本的に「いかにデータ量を減らすか」という思考が求められます。
それこそ、「集計したデータを集計する」という発想が必要な場合もあります。
これは、この業界に入るまで考えたことがない発想でした。

アンケートデータのように、「必要なデータを全てつなげてから集計する」ということもしますが、私見では「集計結果に必要なデータを連結する」という処理を行う場合が多い気がします。

頭の体操が続く日々

職場の環境では SQL で変数が使えないこともあり、Row Data ではしなかった苦労も多々ありました。
1 人のデータが 1 行にまとめられていれば、（変数処理が行えなくても）簡単に行える処理が、Transaction Data では複数回の処理を行わないと実現できなかったりします。
その処理を考えるのは、業界経験が長い人には何でもないかもしれませんが、私にはナゾナゾの答えを考えているような感覚でした。
その度に上司にニヤニヤされ、私は「DB ってやつは！」と発狂していました（笑）

リアルタイムで大まかな処理の流れが頭に浮かんだ日

新しい仕事の依頼が来ると、

1. クライアントから要求を聞く
2. アウトプットイメージを作成
3. それを見ながらデータマートを設計
（アンケートで言うところの『データクリーニング後の Raw Data（生データ）』もしくは『加工後の変数付き Rad Data』）
4. それを作るための SQL の設計＆作成

というような流れで処理を進めています。
でも、これがなかなか大変で、アウトプットイメージですら自力で作れるようになったのは、入社して半年経った頃でした。
そして、アウトプットイメージが固まっても、どんなデータをどう処理すればいいのか、ほとんど道筋が見えない状態。

ところが、入社 9 ヶ月の頃、ある新規の相談を受けたとき、要望を聞きながら「アウトプットイメージ」「データマートの大まかな設計」「SQL の大まかな設計」が頭の中に浮かび、「詳細は分からないけど『実現できそうかどうか』は判断できる」という状況になりました。

そこまで来ると、SQL もサクッと設計して、あっさりと作成できるようになっていました。
今までそんなにスラスラ作業ができたことが無かったので、なんだか気持ち悪かったのを覚えています（笑）

次の 1 年に向けて

これを書いている時点で、既に入社から 1 年 3 ヶ月が経とうとしているわけですが（笑）
今後はより良い提案をクライアントにしていけるようになることを目指していますが、そのために必要なのは、更なる DB 理解なのか、広告の知識なのか、分析に関する知識なのか・・・といった状況です。
まぁ、全部必要なんでしょうけど（笑）

自分が納得できる自分の姿で来年の 8 月を迎えられるように、今後も精進していく所存ですm(_ _)m