Kaizen Ad: Creative Performance Report のご紹介

こんにちは。 Kaizen Platform で 動画広告をPDCAするプロダクト「Kaizen Ad」のプロダクトマネージャをしている渡辺です。今回は、 Kaizen Ad で制作した動画広告のパフォーマンスを一覧比較できるツール「Creative Performance Report」の紹介をしたいと思います。

Creative Performance Report とは

Creative Performance Report とは、Kaizen Ad において、配信先プラットフォームから動画広告のパフォーマンスを収集し、クリエイティブ単位で比較可能なビューを提供する機能です。

f:id:kaizenplatform:20190419185109p:plain

Kaizen Ad は、動画広告を作りたい人(広告主や代理店)が、制作指示書(動画の仕様書に相当するもの)を作成して素材データと共にアップロードすると、GH(Growth Hacker)ネットワークに参加するクリエイターが原則5営業日で動画を制作・納品してくれるサービスです。「速く・安く・簡単に」をテーマに、高品質な動画を制作できるプラットフォームを目指して開発しています。

Kaizen Ad のサービスサイトはこちら: https://ja.kaizen-ad.com/

「動画をつくる」部分にフォーカスすると「動画制作のクラウドソーシング」ということになりますが、Kaizen Ad のカバー範囲には制作プロセスだけでなく、制作した動画の配信実績を収集し、比較・分析することで広告効果を改善していく部分も含まれます。

Kaizen Ad では納品された動画をダウンロードすることなく Facebook や Instagram, Youtube といった動画配信メディアへ直接アップロードすることができます。アップロード時に配信先メディアのアクセストークンを取得することで、Creative Performane Report は広告キャンペーンで使用された動画の配信実績を自動的に収集し、クリエイティブ単位に集計して複数動画のパフォーマンスを横断的に比較する機能を提供します。

f:id:kaizenplatform:20190419185314p:plain

Creative Performance Report の構成要素

Kaizen Ad の Creative Performance Report は、データ収集を担当する「Collector」、データ集計を担当する「Aggregator」、データ表示を担当する「Report View」の3つで構成されています。

f:id:kaizenplatform:20190419185551p:plain

Collector

Collector は、あらかじめ保存されたアクセストークンを利用して配信先メディアからパフォーマンス情報を定期的に収集し、Raw Data DB(Google BigQueryで実装)に格納するコンポーネントです。2019年春現在、接続先メディアとして Facebook (Facebook および Instagram) と Google (Youtube) に対応しています。Raw Data DB に格納されるデータは各プラットフォーム固有の情報を保持します。

利用者数や広告キャンペーンの増加に応じて Collector の取得データ量は日々増加します。日次のデータ収集が翌日になっても終わらないようだと、時系列データとして必要なものが揃えられなくなるため、 Collectorではデータ収集処理を並列化することでパフォーマンスを確保しています。

Aggregator

Aggregator は、Raw Data DB に格納されたデータを集計・変換し、Summary Data DB に移し替える役割を担当しています。メディア固有のデータを Summary Data に変換する過程でデータ構造を正規化し、Report Viewer に対し統一されたフォーマットでデータを提供する責務を負います。

Collector と同じように Summary Data の生成も決められた時間内に完了する必要がありますが、Aggregator はデータの集計・変換を一定回数の BigQuery のクエリで行うことで、データ量の増加に比例せずにほぼ一定した時間での処理の完了を実現しています。また、Summary Data の構造やデータ粒度は Report Viewer の進化に合わせて変化していくため、必要に応じて再集計できるようになっています。

Report Viewer

Summary Data DBに保存されたデータを表示します。Firebase でホスティングされたSPAで機能を提供しています。レポートデータの表示機能と、CSVフォーマットで集計データをエクスポートする機能を持ちます。集計処理は Aggregator がすべて事前に済ませているため、APIコール時にデータを都度集計することはありません。

先月のブログ記事「 React + GraphQL から成る Kaizen Ad のフロントエンド 」でも紹介した通り、API Server とフロントエンドアプリケーションとの通信では GraphQLを使用し、データアクセスをバッチ化することで軽快なレスポンスを実現しています。

設計コンセプト

Creative Performance Report は、設計コンセプトとして「データソースの多様化」と「UIの頻繁なアップデート」にすばやく追従できる拡張性の高さを重視して設計されています。

データソースの多様化に備える

今日(2019年4月現在)のデジタル広告市場は Google と Facebook の2社がシェアの大半を占めている状態ですが、動画広告のニーズ全体が盛り上がっており、今後も継続的に対応メディアが増え、それぞれに対応していく必要が生まれると考えました。データの収集・集計部分は Plaggable な構造にしておいて、新しいデータソースを素早く追加できるようにしています。

UI開発のスピードと柔軟性を保つ

わかりやすく使いやすい Report Viewer はプロダクトの競争力を大きく高めます。UI はデータ構造よりも速いサイクルで進化するので、分析対象データの構造や日々の運用が UIのアップデート可能性を阻害しないような設計にしておく必要があります。表示するデータ項目に変更があるたびにデータを再取得する設計にすると「過去に取得したデータが互換性を失う」「運用開始後のデータ再取得に伴う高負荷やサービスとしてのダウンタイムが発生する」といった問題が起こります。

Creative Performance Report では収集プロセス(Collector と Raw Data DB) と 集計プロセス(Aggregator と Summary Data DB)を分割し、UIを刷新するたびに Raw Data を取り直す必要がない構造になっています。

なぜ Kaizen Platform は今、CTOを募集するのか

皆様お久しぶりです。Kaizen PlatformでCTOをやっている渡部(わたべ)です。 Kaizen Platform、新COOに 渡部 拓也 が就任 でアナウンスさせていただきましたが、4/1よりCOO兼CTOに就任しました。

渡部がCTOとしてやってきたこと : Product Delivery

CTO就任 のプレスリリースは約2年前に出ていました。この2年間で何をやってきたのかをちょっとかいつまんで振り返ってみます。

f:id:kaizenplatform:20190325154028j:plain

私が入社した当時、上図のような組織全体を巻き込んだプロダクト改善の動きができていませんでした。この時感じたのは、「これではいくらプロダクトや技術を磨いてもユーザーにプロダクトの価値を届けることができない」という事でした。

そこで、「ユーザーにプロダクトを届ける = Product Deliveryの為にありとあらゆることをやろう」と決めて以下のようなことをしてきました。

商品の整理とマーケットフィットの確認

実際にセールスシートに手を入れたり、お客様先に営業マンと一緒に同行したりして、我々のプロダクトがどのようなユーザーにもとめられていて、彼らが感じてる価値は何なのか? を研究しました。 そしてそれをどのようにしたらマーケットに広く受け入れてもらえるようになるかという試行錯誤を繰り返しました。

マーケットからのフィードバックを活かしたプロダクト開発への変化

ウォルト・ディズニーは以下のように言ったそうです。

「自分たちのために商品をつくってはいけません。人々が求めているものを知って、人々のために商品をつくりなさい。」

ゆっくりとではありますが、マーケットが望むものは何かを考えてプロダクトづくりをプロダクトチームみんなで考えるようになっていきました。

ムーンショットを狙わない

皆さんも経験があると思いますが(私もあります)、壮大な構想を描き、「これさえ実現すれば世界が変わる」と信じてものづくりをする。しかし蓋を開けてみると大きな失望が待っていた。こんな経験をされたことはないでしょうか? 当社でも当然そういう失敗をしてきました。

もちろんプロダクトのブループリント(青写真)は大きなものを描きますが、それを実現するために着実に機能をプロダクトに追加していく。そして機能が一定量集まるとそれは「ワークフロー」や「UX」を形成していきます。

インクリメンタルにプロダクトの価値を増やしていき、それがしきい値を超えるとプロダクトの桁が上がる、そんな開発方針に切り替え、それがプロダクトチームに浸透してきました。

組織を作り、チームで対応することができるように

特に、Customer Successのチームで顕著だったのですが、優秀なメンバーが揃っているのですが各自が個人商店のような形で案件に対応していて、当社で提供しているサービスレベルもバラバラでした。

チームで対応していくためには、その土台となる組織を作らなければいけません。 そこで、部長/マネージャーという役職を新設し任用と共に彼らへのマネージメント教育を開始しました。特に、部長職は全社の部長ポストの約半数を渡部が兼務しているという状況だったため、内部からの育成と引き上げを行いました。(現在渡部は一つも部長を兼務していません)

この土台の上で、組織として学習し、サービスのレベルを日々上げていくという事が行われるようになってきました。

なぜCOOに就任するのか

上述のように、CTOの役割を飛び越した活動をこれまで行ってきたのですが、更に以下の領域に力を入れていくべく、COOを兼務させていただくことになりました。

ビジネスモデルのさらなる拡大

プロダクトを改善していく流れを作ることはヨチヨチ歩きながらもできてきたのですが、そこでわかってきたことがあります。 これからさらなるビジネスの機動的な拡大をしようと思うと、

  • 商取引の迅速化、省力化
  • 事業KPIなどのリアルタイムでの計測

などをこれまで以上に拡充さえていく必要があります。 ビジネス上の試行錯誤の回転速度を上げ、さらにその投資の判断を迅速にしていく事が必要になります。 これを実現するためにはプロダクトだけを見ていては実現できないことに気が付きました。

コーポレート部門までを横断したリーダーシップが必要

現在管理会計を刷新するためのプロジェクトに関わっていますが、ここでもいろんな気付きがありました。それは、いろんな問題点は川下である経理や管理会計の集計側で発生するのですが、その発生箇所は川上に存在していることが多いということです。

そこで、事業~プロダクト~コーポレートを横断した形でビジネスモデル拡大のための基盤を整えていこうとおもい、COOに就任することになりました。

なぜ今CTOを募集するのか

まず最初に言っておきますと、Kaizen Platformを辞めるわけではありませんw 私の肩書が「取締役CTO兼執行役員」から「取締役COO&CTO兼執行役員」になるだけです。

2-3年後のKaizen Platformを見据える

2-3年後を見据えると、技術やプロダクトで解決しなければいけない問題の難易度はより上がってくると思います。そうなった時に備えて、社内の技術力やプロダクト開発力はもちろん、それを実現するためのチーム力も今から上げておかないといけません。

それを考えると、COOと兼務してる状態の渡部では十分な貢献ができないかもしれません。 これはいよいよ「CTOとしての自分をクビにする時期が来た」と思いました。

新CTOにもとめるもの

渡部はゼネラリスト型の人間です。新しいCTOの方には技術面に特化したリーダーシップを期待したいとおもいます。

幅広い技術分野への興味と知的好奇心

当社の技術は、

  • React + TypescriptをベースとしたSPA(Single Page Application)
  • RDBを使用するバックエンドはRuby on Railsを中心としたマイクロサービス
  • マイクロサービスの一部はGolangやNode.jsも使用している
  • 機械学習やデータサイエンス領域はpythonをベースとしている
  • インフラはAWSをベースにしつつ一部GCP(Google Cloud Platform)を使用して、すべてがコードで管理されている

と多岐にわたっています。これは「問題の領域毎に最適な解決方法を適用する」ことにこだわる技術者集団だからです。

また、これに加えて Kaizen Platformの2019技術構想 : workplace でも書かせていただきましたが、Platformとしていかに各種サブシステムをうまく設計して技術蓄積していくかというアーキテクト的要素も求められます。

幅広い技術に対して好奇心を持って学び続け、その技術の本質的な理解をすることが好きなエンジニアに向いていると思います。

2-3年先の技術動向を見通す先見性

私がKaizen Platformに入社した時は機械学習周りの要素技術がまさに持て囃されていた時期でした。社内外の非エンジニアな方々には「AIには投資しないの?」とよく聞かれたことを覚えています。

当時私は「(要素技術としてのAIを研究することには)投資しません!」と言い切っていました。 これは、機械学習はいずれ近い内に(私が10年前にオンプレミス環境で使っていたMySQLのように)当たり前の技術要素の一つとして利用されることになると思っていたからです。

もちろん、それを「使いこなせるようになる」ことは必要だと考えていたので社内で勉強会をやったりはしましたが、AI自体を自分で作ることには投資してきませんでした。現在、この選択は正しかったと思っています。Google, Amazon, Microsoftから使いやすいソリューションが出ていますが、プロダクトに組み込むためには「使いこなす」ための技術知識が必要です。

これからも技術の動向は変化し続けるとおもいますが、一歩引いた視点から技術動向を見定めて当社の技術的な投資の方向性を指し示し続けていただきたいと思っています。

若いメンバーも含めて導き成長させることへのモチベーション

私が入社した当時当社は「即戦力なシニアなエンジニアしか採用しない」という方針でしたが、私がその方針を覆しました。今は若手のエンジニアが大変多くなっており、シニアなエンジニアと化学反応をおこしています。

これからも若手がより活躍し、シニアがそこにさらなる厚みを加えるようなチームとして一層の成長をしていきたいと思っています。(エンジニアチームだけではなく全社でそうしたいと思っています) その為にはいろいろと悩むことが多い(だろう)若いメンバーに道を指し示し、彼らの成長をより一層加速させることに喜びを見出すリーダーシップを期待したいと思っています。

ご興味いただけた方は、以下のページよりエントリーをぜひお願いいたします。共に成長し、より良いチームとプロダクトをつくっていきましょう! jobs.lever.co

React + GraphQL から成る Kaizen Ad のフロントエンド

Kaizen Platform でフロントエンドエンジニアをしている山本です。この記事では、我々が運営するサービス「Kaizen Ad」のフロントエンド部分をご紹介します。

Kaizen Ad とは

Kaizen Ad は、動画広告をサポートするマーケットプレイスです。
カスタマーがクリエイティブを依頼すると、広告クリエイティブを作成するグロースハッカーから動画広告クリエイティブが納品される仕組みです。

カスタマーにとってはクリエイティブ改善の運用を省力化できると同時に、グロースハッカーにとっても新しい働き方が創造できるソリューションとして提供しています。

ja.kaizen-ad.com

技術選定

技術選定は、モダンシステム化を念頭に置きつつ、運用しやすい設計を目指して行われました。その中でも3つピックアップします。

1. React + TypeScript

Reactは、TypeScriptの親和性や、技術的に明るいエンジニアが在籍していたため選択されました。業界的なメインストリームの一つでもあり、導入に抵抗はありませんでした。 TypeScriptは以下に挙げる項目などメリットが大変多いため導入されました。

  • ランタイムエラーの削減
  • エディターとの相性(visual studio code / WebStorm などで修正箇所がわかりやすい)
  • コンポーネントに渡すpropsのデータがわかりやすくなる

数々のライブラリがTypeScriptへの移行が見受けられ、少なくとも静的型付け言語は今後も利用されていくことが予想されています。Airbnbの発表でも、38%のバグがTypeScriptによって防止された可能性があると報告されています。

www.reddit.com

2. Clean Architecture

Clean Architecture は後述でも説明します。
DDDを意識してドメインに設計の観点を寄せ、プロダクトの拡張性や保守性を高く保つために使っています。マイクロサービスを使ってアプリケーションを構築する昨今のフロントエンド開発において、各機能の凝集度をハンドリングしやすくできることなどがメリットになります。

3. GraphQL

当初、GraphQLをProduction環境で実装する会社は少なかったですが、早い段階で導入することが決定されました。RESTful APIの場合、APIから受け取ったデータを整形してviewにわたすなど、オーバーヘッドが生まれており、GraphQLの場合は、フロントエンドとして必要なデータの形をそのままリクエストすることが可能になるため、ユースケースによりマッチするGraphQLを利用することとなりました。

システム構成

Kaizen Ad のフロントエンドにおけるシステム構成は以下のようになっています。

f:id:kaizenplatform:20190325140005p:plain

React with Clean Architecture

Kaizen Ad の View は 上にも書いたとおりで React + TypeScript を軸にした SPA です。そして、より堅牢なアプリケーションを作るために、設計面では Clean Architecture を採用しました。

Clean Architecture は、ドメイン駆動開発(DDD)などを考慮しつつ、ビジネスロジックの責務を View やフレームワークから分離させる設計です。 有名なのは以下の図で、データモデル(Entity)を中心に4つの円が重なっています。これは円の中心に存在する要素ほど重要なデータとして捉え、依存関係のヒエラルキーを可視化しています。

f:id:kaizenplatform:20190325140022j:plain
出典: https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html

実際に Kaizen Ad で使用している、 Clean Architecture をベースにした設計をご紹介します。View で Event が Dispatch され、 API からデータを取得し、 それらを View にレンダリングするフローは、従来の Flux などと変わりません。それぞれの役割をレイヤーとして設けていて、ワークフローを図にすると以下のようなっています。

f:id:kaizenplatform:20190325140111p:plain

これをコードベースで説明します。例えば User情報を取得して、Viewに表示するユースケースを実装するとします。

Entity / User.ts

はじめに、Entity層に User というデータモデルを定義します。Userクラス は id と name だけを持った簡単なモデルとします。 Userクラスは fromJSON() という関数を持ち、値のチェックをしつつインスタンスを生成できるようにしています。 Entity は基本的になにかに依存することはありません。

// entity/User.ts

class User {
  public readonly id: string;
  public readonly name: string;

  constructor({
    id,
    name,
  }: {
    id: string;
    name: string;
  }) {
    this.id = id;
    this.name = name;
  }

  public static fromJSON = (json: any) => {
    const { id, name } = Object.assign({}, json);

    if (typeof id !== 'string') throw new Error('id must be a string');
    if (typeof name !== 'string') throw new Error('name must be a string');

    return new User({
      id,
      name,
    });
  };
}

export default User;

Adapter / GraphQLClient.ts

Adapter層 として GraphQL のクライアントを立てます。 apollo-link を使って Adapter層 として独立させることで、GraphQLではない別のクエリ言語を使うことになったとしても、影響範囲を小さくすることができます。

// Adapter / GraphQLClient.ts

import { ApolloLink, execute, makePromise } from 'apollo-link';
import { BatchHttpLink } from 'apollo-link-batch-http';

class GraphQLClient {
  private readonly httpLink: ApolloLink;

  constructor({ endpointUrl }: { endpointUrl: string; }) {
    this.httpLink = new BatchHttpLink({ uri: endpointUrl });
    this.store = store;
  }

  query = async (query: any, variables: Record<string, any> = {}): Promise<Record<string, any>> => {
    try {
      const result = await makePromise(
        execute(this.httpLink, {
          query,
          variables
        }),
      );

      if (result.errors) {
        console.error(result.errors);
      }

      return result.data as Record<string, any>;
    } catch (err) {
      throw err;
    }
  };
}

export default GraphQLClient;

Service / UserWebApi.ts

Service層は名前と通り、外部サービスとの連携を責務とします。よって、 UserWebApi.ts ではUser情報をAPIから取得することを責務とします。User情報はGraphQLを使って取得するため、上で作成した GraphQLClient.ts はここで使用します。

クエリの返り値は User.fromJson() に渡されることで、値のチェックを行いつつインスタンスが生成されます。

// Service / UserWebApi.ts
import gql from 'graphql-tag';

class UserWebApi {
  private graphqlClient: GraphQLClient;

  constructor({ graphqlClient }: { graphqlClient: GraphQLClient }) {
    // graphqlClient = GraphQLClient.ts
    this.graphqlClient = graphqlClient;
  }

  public getMe = async (): Promise<DirectorUser> => {
    let result: any;

    try {
      result = await this.graphqlClient.query(
        gql`
          query User {
            me {
                id
                name
            }
          }
        `,
      );
    } catch (err) {
      throw err;
    }

    return User.fromJSON(result.me);
  };
}

export default UserWebApi;

Usecase / UserUsecase.ts

上で書いた UserWebApi を実行する Usecase層 を作成します。Usecaseはドメイン機能を責務とします。ここでは UserUsecase.ts として、Userを取得する機能を定義します。

よって API を叩く Service層 は Usecase を通して実行されます。

// Usecase / UserUsecase.ts

class UserUsecase {
  private store: Store<State>;
  private userWebApi: UserWebApi;

  constructor({
    store,
    userWebApi,
  }: {
    store: Store<State>;
    userWebApi: UserWebApi;
  }) {
    this.store = store;
    this.userWebApi = userWebApi;
  }

  public getMe = async (): Promise<User | void> => {
    let user: User;

    try {
      // Service.UserWebAPI を使って User を取得
      user = await this.userWebApi.getMe();
    } catch (err) {
      throw err;
    }
    // Reducer に取得した User を投げる
    this.store.dispatch(setUser(user));
  };
}

export default UserUsecase;

Reducer / User.ts

View における Reducer は以下のようになります。 Kaizen Ad では、 Redux ではなく repatch という軽量Reduxを使っています。repatchは action type ではなく、dispatch に直接コールバック関数を渡せるのがシンプルで良いですね。

// Reducer / User.ts

export const setUser = (user: User) => (state: State): State => ({
  ...state,
  User: user,
});

View / User.tsx

View は以下のようになります。 ここでは Hooks を使って、 componentDidMount() に相当するライフサイクルを実行します。

// view / User.tsx

const User = () => {
  const state = useContext(stateContext);

  useEffect(() => {
    userUsecase.getUser();
  }, []);

  return (
    <p>
      <span>{state.user.id}:</span>
      {state.user.name}
    </p>
  );
}

User.tsx はUser情報を表示するだけのコンポーネントです。UserUsecase を Context API 経由で取得して React のライフサイクルである componentDidMount で実行しています。

上に書いたプログラムの流れを書くと、View からイベントが Dispatch され、 Usecase から Service を実行します。Service は Adapter を使って API にリクエストを投げ、返り値は Entity でチェックされ、問題なければ Props として View に戻りレンダリングが実行、となります。各層ごとに責務と関心が整理され、依存関係の秩序が明確になるため、とても実用的な設計になっています。

React Hooks の導入とその他メンテナンス

細かいところでは、Reactのバージョンアップを行い、recompose の使用箇所を少しづつ React Hooks に移行しています。また、React.lazy と React.Suspend を使用した Code Splitting を実装し、読み込むファイルサイズの削減を実施しました。ツールの選択や細かいメンテナンスも開発者の判断が反映されやすく、とても動きやすい環境になっています。

GraphQL

Kaizen Ad では GraphQL をかなり早い段階から Production で運用しています。 詳しいことはこの開発者ブログの過去の記事にまとめられています。

developer.kaizenplatform.com

多言語対応(i18n)

Kaizen Ad は 米国やその他地域 でもサービスを展開しているため、SPA上で多言語化対応を行っています。こちらも詳しいことは開発者ブログの過去の記事にまとめられています。

developer.kaizenplatform.com

Kaizen Platform のフロントエンド開発

Kaizen Platformのフロントエンド開発は主に以下を担当します。

  • 仕様書
  • WF制作
  • UIデザイン
  • フロントエンド実装(これは上に書いたので割愛します)

ほかにも、本人の意向次第でバックエンドの領域にも挑戦できる土壌が存在します。

仕様書

仕様書は主にQiita:teamを利用してPRD(Product Requirements Document)やDesign docとして作成します。基本的にはPMがPRDを書いて、それをもとにフロントエンドエンジニア・バックエンドエンジニアが Design doc を書くのがフローとなっています。要件は事前にコンテキストから共有されるため、各担当者が腹落ちせずに物事が進行することは少なくなっています。

WF(ワイヤーフレーム)制作

WFの制作には主に whimsical というサービスを使って作成します。whimsical は使用できるオブジェクトがシンプルで、sketch などに比べると少ないですが、その制限が選択の意思決定を少なくさせてくれて、使用感がとても高いため、最近はメインで使用しています。

f:id:kaizenplatform:20190325141210p:plain

UIデザイン

Kaizen Ad の UIデザインは material-ui のテーマをカスタマイズして使用しています。上述の whimsical と material-ui を利用することにより、ある程度簡単なUIであれば、WFからすぐに実装のフェーズに移行することが可能です。作業がエンジニアだけで完遂できるため、よりスピード感やオーバーヘッドの少ない開発に取り組めています。

f:id:kaizenplatform:20190325141236p:plain

もちろん大きなページ作成や回収には WF → UIデザイン → 実装 のようにすることもあり、その際はsketchやfigmaなどが利用してフィードバックをもらいながら進行することが多いです。

Kaizen Platform では フロントエンドエンジニア を募集しています

いかがでしたでしょうか。Kaizen Platform では一緒にプロダクトを作ってくれるフロントエンドエンジニアを募集しています。カジュアル面談からフランクにお話しておりますので、興味を持っていただけたら、以下のページよりエントリーをぜひお願いいたします。

jobs.lever.co

Kaizen Cloud Engine の裏側をご紹介

Kaizen Platform で プロダクトマネージャーをしている河部です。今回は先日リリースされた Kaizen Cloud Engine がどのようにできているのかをご紹介したいと思います。

Kaizen Cloud Engine とは

Kaizen Cloud Engine は、これまでKAIZEN TEAM for Xとして提供させていただいているサービスの裏側で当社メンバーが活用していたシステムをユーザー様にも直接ご利用いただけるようにパッケージングしたものです。

Kaizen Platform、開発者向けパーソナライズ統合開発基盤「Kaizen Cloud Engine」を月額15万円から提供開始

f:id:kaizenplatform:20190221195910p:plain
Kaizen Platform が提供するソリューション

Kaizen Platform と聞くと ABテストのイメージがあるかもしれませんが、最近ではパーソナライズされたWebサイトを構築するサービスとしてご利用いただくケースが大半になっています。

パーソナライズといっても幅が広いのですが、例えば以下のような形でご利用いただいています。

f:id:kaizenplatform:20190221160747p:plain
ユーザーに合わせた、より身近なランキング表示に

求人検索サイトやレストラン検索サイトで、ユーザーが見ている条件に合わせて地域別・ジャンル別などに絞ったランキング表示ができます。

ユーザーから「自分には関係ない」と思われやすい”全国”ランキングを、ユーザーの興味・関心を基にしたマイクロランキング=「関係のある」コンテンツに変えることは、回遊率向上の効果が見込めます。

開発コンセプト

「かゆいところに手が届く、本気で改善したい人向けの開発基盤」をコンセプトにしています。

開発に至るまでにいくつかのパーソナライズ・Web接客サービスを調査しましたが、GUIは優れているもののそれ故に細かな設定やチューニングができない、といったケースがありました。お客様へヒヤリングした際もそういった声があったため、 Scriptを書けば柔軟に表現力を上げられるようにしています。

その分、学習コストを極力減らすため、世の中にある既存サービスを活用しています。例えば後述の Customer Datastore では、ログを直接見れるよう Google Big Query のコンソールをお客様に開放しています。クエリ画面や独自SQLを用意するのはユーザー様にとっても覚える手間であり(私自身もそう感じたケースが少なくありません)、見慣れた画面でログを触れる方がUXが良いと判断しました。
(仮に Big Query を初めて覚えるにしても、当社でしか使えない仕様を覚えるよりも遥かに有用でしょう笑)

Kaizen Cloud Engine 詳解

f:id:kaizenplatform:20190221154926p:plain
Kaizen Cloud Engine 構成概要

Web Plugins

お客様サイト上に設置する JavaScript です。お客様はWebサイトにタグを設置するだけで Kaizen Cloud Engine の利用を開始することができます

  • Kaizen Analytics
    • Google AnalyticsのようにWebサイト上のユーザーアクティビティを取得します
    • 任意の JavaScript コードを実行することもできるので、カスタマイズされたアクティビティログの取得も可能です
  • Personalized Content Management System (with AB Test)
    • もともと Kaizen Platform が提供していたAB Test の機能を進化させたものです
    • ユーザーの属性などによってコンテンツを柔軟に出し分けることが可能です
    • もちろん、クラウドソーシング上のクリエイターから募集したデザイン案も表示可能です

Log Management Systems

Web Pluginsから送信されてきたログを処理するシステムです

  • Log Manager
    • Kaizen Platformのこれまでの技術蓄積を生かした堅牢な Log Manager が高トラフィック環境でも安定してログの処理を行います
    • Node.js で動作しています
  • Site Script
    • ログの加工を行う必要がある場合、ここで任意の処理を JavaScript で実行可能です

Data Management Systems

Log Management Systems で処理されたデータを保存するプライベートDMPの機能を提供します

  • Customer Datastore
    • Web サイト上の行動ログと、それ以外のあらゆるデータを保存可能なデータウェアハウスを提供します
    • Big Query を使用して実現されています
  • Data Script
    • Web サイト上の行動ログの集計やオフラインデータの取り込みなどを行うスクリプトを作成することができます
    • Web サイト上のデータとCSVなどのオフラインデータを結合して新しい集計データを作成することも可能です

Contents Management Systems

作成したデータを元に、どのようなコンテンツをユーザーに表示するかをカスタマイズできるシステムです

  • Contents Planner
    • どのデザインをどのユーザーにどのくらい表示するか、というコンテンツの配信計画を設定することができます
    • AB Test の機能が発展したものになります
  • Experience Script
    • デザインの表示のカスタマイズを行うためのスクリプトをJavaScript で記載可能です
    • より詳細なコンテンツ出し分けを行う際に利用します

今後の開発

今回リリースされた機能は Kaizen Cloud Engine の一部の機能をお客様ご自身でご利用いただけるようにしたものです。今後もご利用いただける機能を拡充し、Web サイトの総合的な開発環境としてご利用いただけるようにしていこうと思っています。

Kaizen Platformの2019技術構想 : workplace

Kaizen PlatformでCTOをしている渡部です。 今回は2019年のKaizen PlatformのProduct開発の方向性としての技術構想を書いてみたいと思います。

Kaizen Platformが目指しているもの

https://recruit.kaizenplatform.com/aboutus こちらのページに詳しく書いてあるので詳細はぜひ読んでいただければと思いますが、本投稿で特に関連が深いのは以下の記述になります すでに存在している法人向けサービスと比較して10倍以上生産性が高く、圧倒的な競争力を保有するプラットフォームを構築する。

これを実現するためにPlatformとしては以下を実現していく必要があります

  • オフラインで働くのと同等以上の環境(= workplace)をオンライン上に用意する
  • 時間と場所にとらわれない環境(=クラウドソーシング)がこれまでよりも多くの才能を惹きつけることができる
  • 結果として従来よりも精度の高い仕事のマッチングを提供できる

f:id:kaizenplatform:20190115103600p:plain

これをスケールさせる仕組み

f:id:kaizenplatform:20190115103641p:plain

Kaizen PlatformはもともとWebサイトのABテストから始まった会社です。そこからサービスが進化して、マーケティング活動の改善を包括的に行うKAIZEN Team for Xというサービスになりました。それにくわえてKaizen Adという動画改善のサービスが2018年初から立ち上がってきました。

Kaizen Platformはこれらのサービスをクラウドソーシングを通じて提供しているので、サービス提供者側の視点で見ると、この2つのサービスはかなり共通点が多いことがわかりました。

f:id:kaizenplatform:20190115103707p:plain そこでこれらのサービスを分解したものが上図になります。

  • Platform Core
    • Creatorの制作活動を支えるworkplace
  • Domain
    • ビジネスドメインに特化した機能
    • 例 :
      • Webサイト : ABテスト、 Analytics
      • 広告 : 広告Platform(Facebook, Google等)API連携

技術でこれをどう実現していくか

f:id:kaizenplatform:20190115103757p:plain

当社のビジネスのコアである「クリエイティブな仕事を提供するPlatform」としてのPlatform Core部分をしっかりと分離することで、今後新サービスを立ち上げて行くことのコストを大幅に減らすことができると考えています。 取らぬ狸の皮算用ですが、Kaizen Adを立ち上げてきた1年を振り返ると、同様の新サービスを立ち上げるときは1/5くらいのコストと時間で立ち上げができる様になるのではないかと目論んでいます。

f:id:kaizenplatform:20190115103819p:plain

workplaceって考えてみると、我々が日々オフィスで行っている仕事と結構似てるんですよね。なので、採用~受け入れ~教育~業務管理~情報共有~評価~給与支払い、みたいに会社で行われていることをPlatform Coreとしてはオンライン上でサポートしていくとClient&Creator双方の生産性がかなり上がるんじゃないかと思っています。 (内部向けに2019年に開発したいと思っていることをプロットした図なので分かりづらい点もあると思ったのですがご容赦ください)

これ、言うのはまぁ簡単なのですが、現実の仕事環境はじゃあきれいに整理されてるかというとそうでもないんですよねw (皆さんの会社でも完璧!といえる状態ではない部分は多いと思います)

なので、適切な抽象度での設計をしていくことはやってみると意外と難しく、だからこそ面白い。

Kaizen Paltformのものづくりチームはこんなことに取り組んでいますというご報告でした!