マーケティング志向のある方必見！「AWS RedShift」と「AngularJS」によるビッグデータ可視化の裏側を公開！さらに現場経験から導かれたエンジニアのキャリア論も！| 技術勉強会「ヒカラボ」のイベントレポート（開催)

「B→Dash」をサーバーサイドから支えるAWS RedShift

初めに登壇された西氏の講演では、フロムスクラッチ社が開発・提供する「B→Dash」のサーバーサイドに用いられているAWS RedShiftについて語られました。

「B→Dash」はオールインワンでマーケティングデータの管理・統合・活用を可能にするツール。簡単にいうと、Google Analyticsの機能に顧客の管理を盛り込んだものをコンセプトとしているそうです。そして「B→Dash」の役割の一つが、企業が所持するビッグデータを解析することであり、そこにAWS RedShiftがマッチしたのだといいます。そして現場での事例に基づきAWS RedShiftについてレクチャーしていただきました。

ビッグデータを有効利用するために生まれた「B→Dash」

AWS RedShiftの解説の前に、まずはビッグデータ活用の再定義からスタート。西氏はビッグデータ活用の流れを、便宜的に4つの工程に分けました（上記スライド参照）。そして実際の現場では「2. データ可視化（基本的な集計パターン）」と「3. 集計パターンの切替」に大きな“壁”があると述べました。

この“壁”について西氏は、現場でよくありそうな「他部署の人間から通常の集計データのレポートとは別に、違った切り口でのレポートを求められる」というケースを例として挙げられました。こういった状況でエンジニアサイドでは「バッチの改修が必要になること」や「他のタスクとの兼ね合い」などから、「3. 集計パターンの切替」がなかなか実施されないのではないかと推測します。

このような状況を打開するべく生まれたのが「B→Dash」であると西氏は語ります。西氏は、マーケティングプロセスは「集客施策」「販売促進」「顧客管理」の3つに分かれるとし、それぞれでツールやデータベースが異なっているため、統括するのが大変なのだといいます。「B→Dash」ではすべてを一括することで“壁”をなくしているのが強みだと述べます。

「B→Dash」のデータ収集を支えるAWS RedShift

次に解説されたのは、「B→Dash」のデータ収集を担うAWS RedShiftについて。
特徴として挙げられたのは、MySQLなどに代表されるRDBMSが行志向型であるのに対し、AWS RedShiftは列志向型であるということ。行志向型は少数の行に対して多くの列を取得するのが効率的にであるのに対し、列志向型は大量の行に対する少数の列の集約処理が効率的であると西氏は述べます。

西氏らがAWS RDSとAWS RedShiftとの検索時間を比較したところ、AWS RedShiftは10～15倍ほど速かったとのことです。ただし、こういった比較自体はあまり意味がないとも述べ、AWS RedShiftは特定の用途ではとても速い一方で、別の用途ではMySQLなどよりもむしろ遅くなることもあるためだとか。

またAWS RedShiftの魅力の一つとして、SSD ver. を選択できる点も挙げられました。開発時にHDDver. も試したそうですが、CPUの性能が高くとも「B→Dash」の実用レベルには達しなかったのだそうです。
列志向型&SSDという組み合わせによって、Group By 句を複数個利用しても処理時間を抑えられるというメリットがあるのだといいます。

AWS RedShiftを採用した理由は、「B→Dash」では「リアルタイムにビッグデータから集計を行うこと」を要件としたため、スピーディーであることが求められるためだそうです。通常、データの集計というものは前の晩に行ったりバッチで行うものですが、その場で観点を切り替えてデータを見たいというお客様の要望に応えるためには、他に選択肢がなかったとのだとか。

AWS RedShiftを利用する上での注意点

もちろんいいことばかりではなく、注意するべきこともあります。

■「クエリを最適化しないと遅い」
開発当初の構想ですと、どんなデータでもGroupの仕方を変えれば、同じようなクエリでいけるのではと想定していたそうです。ですが実際には、取得したいデータによってクエリを組み替えないとデータが返ってこないという状況も発生するため、クエリの最適化が必須であるといいます。

■「安価ではない」
世間一般では「AWS RedShiftは安価である」と言われることもありますが、必ずしもそうではないとのことです。ここでいう「安価である」というのは、Hadoopなどで同じシステムを構築するのと比べた場合という相対的なもの。例えばWebのデータを扱う場合、AWS RedShift自体のコストは1つのサービスに対して月あたり10万円かかる見込みだとか。毎月3000万PVほどのサービスの場合だと、月あたり50万円にもなるとのことです。

■「ツールを利用中にデータを更新すると重くなる」
「B→Dash」では、情報をリアルタイムにユーザーへ返すだけでなく、返す情報自体もリアルタイムに更新したいという意図があったそうです。それにも関わらず「バッチによる更新」と「ユーザーによる参照」が重なった場合、重くなってしまうという落とし穴があったのだとか。

その解決策として取った行動が、バッチとユーザー操作とでAWS RedShiftへの権限の振り分けることだったといいます。どんなにバッチで重たい処理をしていても、ユーザー側に一定のリソースを残すことで過度に重くなることを防げるようになったそうです。

AWS RedShiftまとめ

ここまでを振り返り、西氏はAWS RedShiftの特徴として「ビッグデータの解析技術として有力」「比較的に安価（Hadoopなどで同じシステムを構築するのに比べて）」「リアルタイム集計にも耐えうる」とまとめました。ただし「クエリの最適化は必須」であると補足し、講演を締めくくりました。

 

AngularJS利用の成功例と問題点

二番目に登壇された井戸端氏の講演では、「B→Dash」のフロントサイドについてお話しくださいました。「B→Dash」の画面にはAngularJSを採用しているそうですが、井戸端氏らが1年ほど開発に使ってきた経験に基づき、特徴とメリット・デメリットについてレクチャーしていただきました。

AngularJSを採用したことの利点

まず西氏はAngularJSの概要をご説明されました。上記がそのスライドになります。そして、AngularJSを採用して良かったこととして、以下の点を井戸端氏は挙げられました。

■「デザイン、フロントサイド、サーバーサイドに分けた開発がしやすい」
最初にAngularJSの利点として挙げられたのは「デザイン、フロントサイド、サーバーサイドに分けた開発がしやすい」という点。「B→Dash」の開発では、「まず画面をどうしようか」というところからスタートしたそうです。初めにモックをhtmlとCSSで作成し、それをベースに詳細を決めていったといいます。AngularJSはhtmlでViewテンプレートが使えるので、作ったモックをAngularJSでのViewに流用でき、効率的だったとのこと。

またサーバーサイドではRuby on railsが用いられているそうですが、フロントとサーバーとのつなぎこみにはRuby on railsをAPI的に使うようにしているとのこと。これによって、フロントとサーバーの開発を平行して開発できたのもスムーズだったと語ります。

■「生産性が高まった」
次にお話しくださったのは「生産性が高まった」という点について。AngularJSは高い生産性が見込めるフレームワークである一方で、「学習コストが高い」と世間では言われることもあります。ですが、井戸端氏らは実際に使ってみると案外すんなり導入できたのだといいます。

スムーズに扱えた要因として、基本的なフレームワークの概念と、サーバーサイドのスクリプト系言語の仕様を理解していることを挙げられました。さらに前提として「B→Dash」がAngularJSに向いていたということも大きかったともいいます。

また「B→Dash」の開発では、JavascriptでありながらRubyのように書けるCoffee Scriptを採用しているため、サーバーサイド（Ruby on rails）との区別なく書けたことも、学習コストを抑えられた一因であるようです。

■「データドリブンなアプリの開発に適している」
AngularJSは保持しているデータを取り扱う事に長けているフレームワークで、「B→Dash」のようなデータドリブンで使うシステムに向いていると井戸端氏は感じたそうです。反対に画面でユーザーがインタラクティブな操作をするようなアプリケーションなどには、あまり向いていないかもしれないとも続けます。

AngularJSを使う上での3つの問題点

AngularJSの問題点として、「ベストプラクティスが少ない」「ビジネスロジックがフロントに寄りがち」「開発のフローの中でのスタイル崩れ」の3点を井戸端氏は指摘します。

■「ベストプラクティスが少ない」
AngularJSは比較的新しいフレームワークであるため、実装例が少なく、調べてみても最適な実装例になかなか辿りつけないことがあったそうです。

「B→Dash」ではヘッダー、リスト、コンテンツと3つのViewから構成されており、それぞれのコントローラー間で情報を引き渡す必要があるのだといいます。ですがAngularJSはシングルページアプリケーションに向いているという性質もあり、異なるコントローラー間の情報のやりとりをどのようにやるのが効率的かは諸説あるのだそうです。井戸端氏らはイベントを利用する方法を採用したところ、ロジックが複雑になってしまったといいます。後から振り返るとサービスを採用すればよかったと思いつつも、事例が少ないためベストな方法になかなか辿りつけなかったとのことです。

■「ビジネスロジックがフロントに寄りがち」
井戸端氏は、AngularJSは多機能であるがゆえに、何でもかんでもAngularJSでやってしまうおそれがあると指摘します。

「B→Dash」の事例でいうと、サーバー側からは生に近い形でデータをクライアント側に渡して、クライアント側で整形処理などを行うという実装をしていたそうです。その結果、サーバー側のソースコードはスカスカなのに対し、クライアント側では盛り込みすぎてスパゲッティコードになってしまった箇所もあったのだとか。

この点について井戸端氏は、データに絡むビジネスロジックなどはサーバー側に、画面の表示に関わるような処理などをクライアント側に実装すべきだったと、振り返ります。何でもできてしまうAngularJSだからこそ、開発規約を決め、役割分担をするのが好ましいということでした。

■「開発のフローの中でのスタイル崩れ」
前述した通り「B→Dash」開発では、htmlベースでモックを作ってAngularJSに転用という流れだそうですが、Directiveを利用するためにhtmlへdiv要素を追加する必要となることがあり、スタイルが崩れてしまうという事態が起こったそうです。

現在ではデザイナーの方にAngularJSを使うことを理解してもらい、「ここにはdivが入る」など余分な要素が入ることを踏まえてモックを作ってもらっているとのことです。htmlのテンプレートを転用できるという点はとても便利ではある一方、AngularJSで利用したらどうなるかまでを想定してコーディングを行う必要があると、井戸端氏は述べました。

AngularJSとのベストな付き合い方

AngularJSは多機能で強力なフレームワークですので、ここまでに挙げた注意点を頭に入れた上でプロジェクトを組むと、よりスムーズにプログラミングができるだろうといいます。また、最低限の機能を理解し、開発規約を決めることで、高い生産性を発揮できるとも述べました。特に「B→Dash」のような、データを用いた業務用のアプリケーションにはとても適しているので、検討する価値があると締めくくりました。

 

新しいエンジニアのキャリア論

最後に登壇された東潟氏は、ご自身の経験と「B→Dash」開発現場から導かれた、エンジニアのキャリア論をテーマに講演されました。

エンジニアキャリアの二分化

まず東潟氏は現在のエンジニア事情を、アメリカとの比較で解説。アメリカのエンジニアはユーザー企業に勤務するのが一般的なのに対し、日本では受託企業に勤務するエンジニアが半数以上だと述べます。また日本では、安定した企業で長く働きたいという志向があり、チャレンジよりもリスクヘッジを考える方が多いのではないかと推測します。その他にも、企業の収益モデル＆利益率、エンジニアが生まれる土壌など、様々な観点から比較が行われました。

それらの点を踏まえ、東潟氏は日本のエンジニアを取り巻く状況を上記スライドのように図示しました。
そして、この構造がこの先も続くだろうとしつつも、今は右側のセグメントの価値が高まってきており、この先狙う価値があるセグメントであると述べました。

これからのエンジニアに求められるポータブルスキルとは

次にレクチャーしてくださったのは、これからのエンジニアに求められるスキルについて。東潟氏は、個人に紐づく本質的・ベーススキル、すなわちエンジニアのポータブルスキルを身につけるべきだと主張します。

東潟氏は一般的に言われるポータブルスキルをベースに、エンジニアのポータブルスキルとは何かを解説。
フロムスクラッチの現場経験から、活躍されているエンジニアの方に共通してみられる特徴を基に、エンジニアのポータブルスキルを「問題の要素分解力と構造化力（対課題）」「顧客や現場のニーズの把握力（対人）」「決断力、判断力、機動力（対自己）」と、東潟氏は定義しました。

その他、エンジニアのリテラシーについては、東潟氏ご自身の経験則であると断った上で次のように述べました。活躍する人は「オブジェクト志向を、きちんと概念的に理解している」「パフォーマンスチューニングが得意」といった傾向が見られるのだとか。後者については、「基礎的な理解をベースに解決方法の検討が早い」「ボトルネック探しがうまい」「環境をすぐに理解する」とも補足されました。

東潟氏曰く、新しい言語への理解や応用力といったテクニカルスキルは、即効性が高い反面、陳腐化もしやすいため、それだけでは不十分なのだとか。テクニカルスキルに加えてポータブルスキル（+リテラシー）を身につけることが重要なのだそうです。

また、東潟氏は業界構造的にエンジニアの多能工化が進んできていることからも、ポータブルスキルの重要性が高まっていることを指摘。受託企業ではコスト圧縮やIT人材不足の流れから上流SEの領域まで役割範囲になっていること、自社サービス側でもアジャイルで短い開発サイクルで回すようになっていることなどから、「単にコーディングできます」だけでは通用しにくくなっているという傾向があるのだとか。

自分の価値を高める仕事の選び方

前段で解説されたのはポータブルスキルの重要性について。それでは、どのようにしてポータブルスキルを習得すればいいか。東潟氏は「セグメントにこだわる」「サービス内容を知る」「耐性・役割範囲にこだわる」の3つの切り口で解説してくださいました。

■セグメントにこだわる
受諾側、自社サービス側の2つのセグメントに分け、どちらがいいということではなく、どちらにいくのかを見極める必要があると東潟氏は述べます。特に変化を経験することが重要であるとし、変化がたくさんあるところに飛び込むべきだそうです。

■サービスの内容を知る
サービス内容については、「サービス立ち上げの時期」「競合の有無」「広告やマーケティング、フィンテックなどビジネス的に先端分野かどうか」などに注目してほしいと言います。テクノロジーが差別化になる業界・サービスであれば、結果的に新しい技術の習得にもつながると述べます。

■体制・役割範囲にこだわる
東潟氏は体制・役割範囲について、次のようなポイントに着目してみてはと提示されました。「開発スタイル――ウォーターフォールorアジャイル」「チーム構成――ビジネス側やリーダーとの距離」「他のメンバーのスキル」「オフショア利用の有無」などを挙げ、どういう体制で働くのかを把握しておくべきだそうです。

この3つは「プログラマー35歳限界説」を乗り越えるためでもあると語ります。実はフロムスクラッチ社で活躍されているフリーランスの方は40～45歳くらいの層だそうです。そういった方々が活躍されているのは単に知識や経験が多いからではなく、ポータブルスキルが充実しているからだと東潟氏は分析します。

最後に

東潟氏は最後にまとめとして、「セグメンテーション――マーケットの状況の理解」「ターゲッティング――キャリアをどう積んでいくか」「ポジショニング――何で戦うか」の3点に触れました。特に何で戦うか――差別化の部分は、「ポータブルスキル・リテラシー」の構築を意識することが重要であるとして、講演を締めくくりました。