for Startups Tech blog

このブログのデザインを刷新しました。(2023/12/26)

チームトポロジーを読んだよ

f:id:forStartups:20220121160503j:plain

どうも、ばやし(@bayashimura)です。

首を長くして待ち望んでいた「チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計」を読みました。とても勉強になったので感想を書いていこうと思います。

 

どんな本?

社内に複数チームを抱えるサイズになった企業が、どういうチーム構成にしてどのような相互作用をすればよいのかというのを説明してくれる本です。

そのために4つのチームタイプと3つのインタラクションモードのモデルを提示し、高速に価値をデリバリーする組織の形をパターンとして伝えてくれます。

 

具体的なまとめ内容に関しては翻訳者の一人のryuzeeさんのブログがわかりやすいです。

www.ryuzee.com

 

認知負荷を減らす

これまで私がプロダクトやチームがスケールする現象に抱いていた認識は「複雑になってしんどい、セクショナリズムとか発生してしんどい」といったふわっとしたものでした。

本書ではそれに対して認知負荷という切り口で「チームの認知容量には尊重すべき上限が存在する」と定義してくれたことで、スケールした際のしんどさの正体を明らかにしてくれています。

組織やプロダクトが大きくなるにつれて、少人数では手に負えなくなってきますよね。何故手に負えなくなるかと言うと、プロダクトにせよ人にせよ把握できない部分が増えてくるからです。大量のソースコードや多岐にわたる複雑なドメインに常に気を配らせながら開発をしていると、開発は全然進みません。これが認知に負荷がかかっている状態です。

チームが取り扱える認知負荷は限りがあるので、できるだけ減らしていこうというのがこの本の考え方です。じゃあどうやって減らしていこうかというと、まぁチームを分割します。そして分割したチームを4つのタイプに種別しています。

これはこの本の見所だと思っていて、例えばLeSS(Large Scale Scrum)だと、「クロスファンクショナルなチームが良い」や「長生きなチームが良い」など、どういうチームが良いのかといった部分にのみ言及されています。

less.works

f:id:bayashimura:20220121161900p:plain

そのため、チーム同士はどうコラボレーションすると良いのか、チーム毎に特徴はあるのかといったことは読み手側に委ねられており、ノウハウを一から自分たちで積む必要があります(これはLeSSがフレームワークとして未熟であるというよりはLeSS自体がScrumに則り最小のフレームワークを目指していることによるものだと思います)。

f:id:bayashimura:20220121161927p:plain

この「チーム毎に特徴(タイプ)はあるのか?」という話と「チーム間はどう関わるのが良いのか」という疑問に対してパターンを紹介してくれるのがチームトポロジーで出てくる4つのチームタイプと、3つのインタラクションモードです。

 

4つのチームタイプ

ストリームアラインドチーム
メインになるチームです。バリューストリームに沿って配置されます。職能横断型で他のチームに依存することなくデリバリーできるよう構成されたチームです。なぜプロダクトチームやフィーチャーチームという呼び名ではないのかというと

このように複数チャネルと高度に結合されたコンテキストでは、「プロダクト」はいろいろな意味を持つ。これが「プロダクトチーム」の責任範囲を理解しづらくしている。 (chapter 5より引用)

だそうです。

プラットフォームチーム
その名の通りプラットフォームを提供するチームです。共通化されたインフラ、ツール、プラグインなどを提供します。複数のストリームアラインドチームが共通して取り扱う複雑なものを抽象化して提供することで認知負荷を下げます。

イネイブリングチーム
他のチームのスキル習得をサポートするチーム。

コンプリケイテッドサブシステムチーム
チーム全員が認知するには負荷が高い複雑なサブシステムやコンポーネントを扱うチーム。

またこのチーム同士の関わり方、インタラクションの仕方も3つのモードを提示しています。

 

3つのインタラクションモード

コラボレーション
2つのチームがお互いオーナーシップを持って協働するスタイル。一番認知負荷がきついが、学習は進む。

X-as-a-Service
明確に責任領域を分けて一方が他方にサービスを提供する形です。利用者はインタフェースだけを把握すればよく認知負荷は低そうですね。

ファシリテーション
一方が他方のチームに学習が進むようファシリテーションをするスタイルです。

 

チームパターンの時代

私がこの本を読んで第一に抱いた感想は「新しい時代がきたなぁ」でした。

まずこの本はこの一節から始まります。

"システムを小さくシンプルに保つことは価値あるゴールだが、成功しているシステムの多くはそうなっていない。(まえがきより引用)"

そうなんですよね。チームもシステムも小さくシンプルに保つことは素晴らしいことですし、その努力を怠ってはならないんですけど、プロダクトが1チームを超えるタイミングはありますよね。成功していたらなおさら。

"チームのモデルやスケールデリバリーモデルはたくさんあるが、一見しただけでは個々の違いはわからない。さらに、チームのふるまいのパターンが示されておらず、他のチームとどのように効果的に接するべきかのガイドラインもないままだ。"

という文の通り、今までスケールはするなという教えが先行し、スケールした後にどういうコミュニケーションを取ればいいのか、それぞれのチームに個体差はないのか、といった議論はあまりされていなかったように感じます。

そこに対して、チームのタイプやインタラクションモードをパターンとして記述したこの本は、私としては新時代の到来を感じました。ここで取り上げられた、4つのチームタイプと3つのインタラクションモードはこれから色んなところで共通語になってきそうですね。

振り子?それとも螺旋?

f:id:bayashimura:20220121161953p:plain

振り子と螺旋の話はt_wadaさんの技術選定の審美眼から引用させていただいております。 

speakerdeck.com

 

振り子は同じところを行ったり来たりしている、螺旋は行ったり来たりするように見えて実はどんどん進歩していっているという表現です。

大体の新しいものは現状の悩みごとから出てくるものです。本書も、出てきた背景は「スモールチームで上手くやれるようになったけど、スケールすると上手くいかない」ではないでしょうか。私が読もうと思ったきっかけはそうです。

"システムを小さくシンプルに保つことは価値あるゴールだが、成功しているシステムの多くはそうなっていない。(まえがきより引用)"

前書きの一番最初に出てくるこの一文が示す通り、チームやプロダクトを小さくシンプルにするのはとても大切です。しかしプロダクトが続いていく上でその原理原則通りにやっていけるわけではありません。実際プロダクトが続けば続くほど、人気が出れば出るほど満たさなければならない要求も増え、プロダクトは巨大に複雑になっていきます。

採用も上手くいきチームもプロダクトも大きく複雑になってしまったときにどうすればいいのか、それについての本は私を含め多くの人が読みたかったのではないでしょうか。

ただ少し待ってください。この4つのチームタイプや3つのインタラクションモード、見覚えありませんか?実は多くの既存の大企業がこの形になっていないでしょうか。

システムごとに部署があって、みんなが使う共通のプラットフォームを作る部署があり、難しい技術をレクチャーする部署があり、法務やセキュリティなどの専門領域に対処する部署がありませんか。

自分がアジャイルにハマったきっかけを思い出してみます。膨大なコミュニケーションコスト、何を書いていいかわからない申請書、至るところで発生するセクショナリズム、こういったものに嫌気が指し私はアジャイルスクラムが提唱するスモールチームに惹かれていきました。

この4つのチームタイプと3つのインタラクションモードは組織をあの頃の重厚長大な組織に戻す第一歩だったりしないか?もしかしてスモールチームでうまくやっていた人達が、大企業になっていく中で同じようなペインを抱えてあの頃の大企業になっていくだけの話?果たしてこのチームトポロジーは振り子なのでしょうか。

いいえ、私は螺旋だと思います。

 

まず本書は大前提として

長続きする小さなチームを基準とする

チームがソフトウェアのオーナーとなる

などのチームファーストな思考がベースとなっています。

スモールチームがアジリティ高く価値を継続的にリリースするという、コアな価値観は変わっていません。

これまでのチーム構成が静的でトップダウンで決まるのに対して、この本書でのチーム同士の関わり方は動的に決まります。責務の切れ目が理解できないうちはコラボレーション、理解できてきたらX-as-a-Serviceに徐々に変更していくところなどは、経験主義が息づいてそうです。

使いづらい社内サービスを使わされていた苦い過去を持つ方。プラットフォームチームが提供してくるX-as-a-Service怖いですね。安心してください。本書の中でも明言してくれています。

X-as-a-Serviceモデルがうまく機能するのは、サービス境界が正しく選択、実装され、サービスを提供するチームが優れたサービスマネジメントを実践している場合に限られる (chapter 7より引用)

まだまだ挙げればキリが無いのですが、至るところに「このチームタイプの大事なポイント」「このインタラクションモードの大事なポイント」が存在し、それは以前までの大企業のモデルとは違うことを示唆してくれています。

ということで、チームトポロジーはスケールするチームを支える新しいやり方だと、私は思いました。

ただし「4つのチームタイプと3つのインタラクションモードにすればいいんだろ」といった理解で現場に適用しようとすると「これまでの大企業のやり方と何が違うんだっけ」となりかねないので本書を一読し、コラムなどにも目を通した上で参考にすることをおすすめします。

以上、チームトポロジーの感想文でした。

 

We are Hiring!

f:id:forStartups:20211020192743p:plain

フォースタートアップスでは共に働く仲間を募集中です。本記事を読んで興味を持っていただけましたら採用情報をご覧ください。

E2Eテストを書くことで変更失敗率を下げつつデプロイ回数を上げたい

f:id:forStartups:20220107185001j:plain

こんにちは。エンジニアの藤井(@yutafujii)です。 社内向けのプロダクト「タレントエージェンシー支援システム(SFA/CRM)」のエンジニアをしています。

今回は安心して開発に専念できるようE2Eテストを記述した話をさせていただきます。 アプリケーションはVue/Railsで動いておりCIはCircleCI、テストツールはPlaywrightを用いました。

変更失敗率とかデプロイ回数の話

つい先日t_wadaさんがパフォーマンス指標についてTweetしておりましたが、チームでも直近デプロイ回数を意識した方がよいのではという話になりました。

私が入社した2年前は、PullRequest(PR)はレビューを通ったら都度デプロイしてましたが、1年前に方針を変えていたんですよね。 その時は「なんか自分たちってぬるっとリリースしてるよね」という意見があって、アウトカムかどうかは別としてアウトプットは一定程度まとめて定期的なリズムを作ってリリースしてみましょうか、という話になっていました。

その後1年間は、毎週月曜日をリリース日と定め、前週の金曜日にリリース物をstaging環境に載っけて致命的なエラーがないかを動作確認するという運用を行いました。 その際、根幹となるユーザーストーリーを手動で1つ1つ実行してみて、エラーが起きないかをチェックしていました

f:id:forStartups:20211221134504p:plain
git flowに近い開発をしていた

当時の目的も時とともに薄れていき、あるスプリントの振り返りで「PRレビューが終わったものは都度リリースしてはどうか」という話が出ました。 しかしながらそこでは同時に

「都度すぐにリリースされるのは少し不安」

「コードレビューだけやっておいて金曜日のstagingの動作確認をもってして”リリースできる”か確認する感覚になっている」

という意見もチームから出ました。

これってよくよく考えると、自分たちは「ソフトウェアの変更を常にテストして自動で本番環境にリリース可能な状態にしておく」というCI/CDの目的を本質的に満たせていない状態に陥っていたとも言えます。

じゃあ改善しようという点にみんな異論はなかったのですが、 一方でコードベースも大きくなっていたこともあり、 PRをレビューするたびに根幹となるユーザーストーリーを手動で1個1個チェックするのも負担感が強くなっていました。

そこで、アプリケーションの根幹となるユーザーストーリーに対してE2E(End to End)テストを作成することにしました。

E2Eテストとは

E2Eテストは実際の動作の一連のフローに着目し想定通りの結果となるかを確認するもので、特徴として以下のような点が挙げられます。

  • 複数の処理を一連のフローとして実行して想定通りの結果になるか確認する
  • ブラウザを用いる(実際の動作がブラウザで行われることから)
  • production環境に対してまたは同等の環境に実行するのが理想的
  • 様々なデバイスでのテストで実行するのが理想的

今回私が実装したテストはこれら全てを実現してるわけではないのですが、ブラウザを利用し一連の処理をテストするという点で一定の目的を達成したと考えます。

ちなみにソフトウェアのテストをUnitテスト・Integrationテスト・E2E(End to End)テストの3つのレイヤに分けて、ピラミッド状にテストケースの数を構成するテストピラミッドという考え方があります。

f:id:forStartups:20211221143046p:plain
テストピラミッドの種類
出所)freeCodeCamp

Unitテストは実行時間が短い代わりに検証範囲が限定的で、 E2Eテストは実行時間が長い代わりに広範囲の検証を行えるというトレードオフがあり、 それぞれのレイヤのテスト数をどうバランスするかという論点への一つの考え方がテストピラミッドです。 私たちの場合は図左側の順三角形型(Unitテスト数が多く・E2Eテスト数は少なめ)のバランスを目指しました。

Playwrightを利用する

f:id:forStartups:20211221183823p:plain
Playwright LPより

E2Eテストのライブラリは以下の記事を参考にしながらPlaywrightを選定しました。軽量で速い・信頼度が高い(SeleniumやPuppeteerに比べて処理手順の安全な実行が可能)という点を評価して選定しています。

Playwrightはauto-waitsにより、安全な処理手順の実行が可能になっている →例えば、Puppeteerの場合だと待機時間を手動で設定しておく必要があるなど、 E2Eの一番のネックとなる部分がPlaywrightで抽象化されたので嬉しい。

PlaywrightでフロントエンドのE2Eテストを自動化してみた話

テストの設計

今回のE2Eテストではアプリケーションの根幹となるユーザーストーリーに焦点を絞ります。 プロダクトはCRMに分類されるアプリケーションなのですが、SaaSに例えるなら「リードを獲得するところから、顧客の収益化まで」にアプリケーションで行われる基本ケースの処理をすべてフローで実施して結果をテストします。

以下のフローを実行するようなイメージです(SaaSに例えた場合)

  • トップ画面を開く
  • 獲得リードの入力
  • リードナーチャリングで送信した情報の入力
  • 活性化した顧客の商談入力・ステータスを進捗させる
  • 受注処理

また、都度のCIビルドでE2Eテストを実行するのはテスト結果の示唆が待ち時間に見合わないと判断し、staging環境へ載っける準備ができた段階のソースコードに対してのみテストが実行されるようにします

テストの実装

Playwrightパッケージをレポジトリに追加し、テストコードを記述していきます。

$ yarn add @playwright/test playwright

テストを <application root>/e2e 配下に配置していきます

// e2e/test.spec.ts

import { test, expect } from '@playwright/test'

const config = require('./env.json')

test.describe('MyApp', () => {

  // テスト毎にトップページへの遷移まで終えておく
  test.beforeEach(async ({ page }: any) => {
    // ログイン画面
    await page.goto(`${config.baseUrl}/`)

    // トップページ画面を表示していることを確認
    expect(await page.waitForSelector('text=MyApp')).toBeTruthy()
    await page.screenshot({
      path: 'e2e/screenshots/top.png',
      fullPage: true,
    })
  })


  test('基本フロー1', async ({ page }: any) => {
    await page.click('text="あああ"')
    expect(await page.waitForSelector('text="あああ一覧"')).toBeTruthy()
    // ... 15手順ほど続く
  }

  test('基本フロー2', async ({ page }: any) => {
    await page.click('text="あああ"')
    expect(await page.waitForSelector('text="あああ一覧"')).toBeTruthy()
    // ... 40手順ほど続く
  }
}

テストを書き始めるときはPlaywrightのTest Generator機能を使って実際にテストスコープとなるフローを手動で実行し、自動で書き起こされたテストコード利用すると便利です。

# Generator 起動コマンド
$ yarn playwright codegen <your_site_url>

E2Eテストの実行コマンドをpackage.jsonスクリプトに記載しておいて、CIコンテナでの実行時の呼び出しコマンドとしておきます。

  "scripts": {
    "test:e2e": "npx playwright test e2e/",
  },
# テスト実行コマンド
$ yarn test:e2e

E2EテストのCIへの導入

作成したE2Eテストは以下のようにCircleCIの中で実行されるようにします:

  • CircleCIに追加のジョブを作成
    • staging環境だけ実行されるように設定
  • ジョブ
    • 必要なライブラリのインストール・データベース構築
    • サーバーを起動
    • E2Eテスト

新しく追加するパイプラインの設定箇所

# .circleci/config.yml

workflows:
  main:
    jobs:
      - build:
          context: xxx
      - e2e:
          filters:
            branches:
              only: /^staging.*/
          requires:
            - build

ジョブのConfigurationはこのような感じです。

jobs:
  build:
    (省略)
  e2e:
    working_directory: ~/<your_github_organization>/<repository>
    shell: /bin/bash --login
    environment:
      CIRCLE_ARTIFACTS: /tmp/circleci-artifacts
    parallelism: 1
    docker:
       - image: circleci/ruby:2.7.x-node-browsers
         environment:
           RAILS_ENV: development
           DB_HOST: 127.0.0.1
           DB_USERNAME: 'xxxxxxxx'
           DB_PASSWORD: 'xxxxxxxx'
       - image: circleci/mysql:5.7.x
         command:
           mysqld --sql-mode=NO_ENGINE_SUBSTITUTION
       - image: redis
         name: redis
    steps:
    - checkout

E2Eテスト実行までの各ステップはこんな感じ

# パッケージやライブラリのインストール

    - run:
        name: Bundle Install
        command: bundle check --path=vendor/bundle || bundle install --jobs=4 --retry=3 --path vendor/bundle
    - run:
        name: Yarn Install
        command: yarn install --cache-folder ~/.cache/yarn
    - run:
        name: Elasticsearch install
        command: |
          wget -O ~/elasticsearch-6.5.x.tar.gz https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-6.5.x.tar.gz && \
          tar -xvf ~/elasticsearch-6.5.x.tar.gz -C ~/ && \
          if [ -z "`~/elasticsearch-6.5.x/bin/elasticsearch-plugin list | grep analysis-kuromoji`" ]; then \
          ~/elasticsearch-6.5.x/bin/elasticsearch-plugin install analysis-kuromoji; fi
# サーバー立ち上げのために必要な準備

    - run:
        name: set up database
        command: bin/rails db:create db:migrate RAILS_ENV=development
    - run:
        name: set up elasticsearch
        command: |
          ~/elasticsearch-6.5.x/bin/elasticsearch -d
          sleep 5
          bundle exec rake elasticsearch:setup:index  # Elasticsearchの全インデックス作成タスク
    - run:
        name: seeding
        command: |
          ~/elasticsearch-6.5.x/bin/elasticsearch -d
          bundle exec bin/delayed_job start
          bin/rails db:seed_fu RAILS_ENV=development
          bundle exec rake seeding:candidates[2]
    - run:
        name: put env.json
        command: |
          cat \<<-TEXT > e2e/env.json
          {
            "baseUrl": "http://localhost:3000"  # テストしたいドメインを与える
          }
          TEXT
# E2E test!
    - run:
        name: E2E test
        command: |
          ~/elasticsearch-6.5.x/bin/elasticsearch -d
          bundle exec bin/delayed_job start
          bin/rails s -d
          curl localhost:3000 > /dev/null 2>&1
          yarn test:e2e

ここまで書いたらブランチ名を staging/foo とかにしてGitHubにpushすると、、

f:id:forStartups:20211221163537p:plain

実行されました!

E2Eを導入してみて

承認されたPRを都度リリースすることで1週間のリリース回数は大幅に増え、作ったものがすぐユーザーに届く開発体験の良さを取り戻せました。

f:id:forStartups:20211221140957p:plain
週間リリース回数

E2Eテストが稼働していることで、これまで手動で行なっていた「根幹機能の動作確認」も不要になり、開発効率も間違いなく上がっていると思います。

E2Eテストを導入してから2ヶ月くらい経ちますが、実際にE2Eが失敗してソースコードのバグに気づけたこともあり効果を実感しています。

これからもユーザーに価値を素早く届け、かつ良質な開発体験が得られるような工夫を続けていきます

We are Hiring!

f:id:forStartups:20211020192743p:plain フォースタートアップスでは共に働く仲間を募集中です。本記事を読んで興味を持っていただけましたら採用情報をご覧ください。

「STARTUP DB」に込められた想いとは?

f:id:forStartups:20211108190136j:plain

こんにちは、フォースタートアップスで運営している成長産業に特化した情報プラットフォーム「STARTUP DB」のプロダクトオーナーの寺田@yuyateradaです。

今回は「STARTUP DB」とはそもそもどのようなプロダクトか、直近リリースしたENTERPRISE機能、今後の戦略についてご紹介します。

 

「STARTUP DB」が目指すGOAL

f:id:forStartups:20211108185630j:plain

STARTUP DB」は国内13,000社以上のベンチャー・スタートアップ企業の情報、起業家・投資家、エコシステムビルダーの方々累計150名以上のインタビュー記事が閲覧できる情報プラットフォームです。エコシステムビルダーは国内スタートアップエコシステムに関わるVCやCVC、大手事業会社、海外企業、金融機関、政府自治体、教育機関などあらゆるステークホルダーの方々を対象にしています。

プロダクトのゴールは「国内スタートアップエコシステムのキャッシュフローを増やすこと」です。そのプロダクトゴールに向け、「国内スタートアップとエコシステムビルダーの方々がそれぞれ信頼のできるパートナーと出会いをつくっていくこと」を目指し、運営をしています。「STARTUP DB」があることで、スタートアップエコシステムがブーストされ、インフラとなるような存在を目指しています。

STARTUP DB」はデータベース販売しているとイメージされることもあるのですが、あくまでも企業データベースはスタートアップエコシステム内での良い出会いをつくっていく手段として考えています。

また、プロダクトポリシーとして、会社のバリューでもある「Startups First(注1)」を1番の重きにおいています。プロダクトポリシーである「Startups First」を大事にしている事例として、よく色々な企業よりデータベースを営業リストとして販売してほしいという問い合わせを頂くのですが、提供をお断りすることがあります。スタートアップは限られたリソースの中で事業運営をしているため、営業の問い合わせ数が増えてしまうことで事業運営におけるノイズになってしまうことがあるためです。もちろんプロダクトしてマネタイズは大事でありますが、信頼のできるパートナーとの出会いをつくる場として価値提供していくこと、軸をぶらさないよう大事にしています。

現在、メインの企業データベース以外の機能では、スタートアップ向けの無料会員機能「CLUB」、スタートアップとの事業創造をサポートする機能「ENTERPRISE」(次の章で紹介)を提供しています。

その他「STARTUP DB」が保有するスタートアップのデータは、テレビや新聞、雑誌などの様々なメディアへのデータ協力や、金融機関や大学研究機関、政府自治体といった公共機関のリサーチにもデータが活用されています。

f:id:forStartups:20211108185700p:plain

注1:全ては日本の成長のために。スタートアップスのために。スタートアップス=『進化の中心』にいることを選択する挑戦者達。

 

スタートアップとの事業創造をサポートする機能「ENTERPRISE」

スタートアップとの事業創造をサポートする機能として「ENTERPRISE」を21年7月に正式版をリリースしました。主に大手事業会社や投資家を中心としたエコシステムビルダーの皆様と国内スタートアップ、それぞれが信頼のできるパートナーとのアライアンス機会をつくるための機能になります。

現状スタートアップとの事業創造における課題として、「Googleなどの検索サービスを利用しても、網羅的に効率よく調べることができていないこと」や「比較検討の際に、類似企業の抽出などのリサーチや情報整理に時間がかかってしまっている」などが生じています。ENTERPRISEを導入頂くことにより導入企業社の業務工数の削減、業務クオリティの向上に繋げていきたく、以下のような機能を提供しています。

①スタートアップに詳しい専門チームのサポートにより精度の高いソーシングに対応

f:id:forStartups:20211108185727p:plain

②無制限でエクセルデータのダウンロードが利用可能

f:id:forStartups:20211108185753p:plain

検索したスタートアップ企業の一覧で、表示順上位100社を一覧データとしてダウンロードできます。企業紹介、合計資金調達額など分析に必要なデータを全て提供しています。また、個別の企業ページからファイナンス情報などの詳細データをダウンロードすることも可能です。これらのデータダウンロードが回数無制限で可能です。

 

③すべての検索機能が利用でき、すべての検索結果から比較検討が可能

f:id:forStartups:20211108185805p:plain

ソート機能や全検索結果の閲覧、類似企業情報が可能になります。一般ユーザー様は検索や検索結果の表示数などの機能に一部制限がかかります。

それ以外にも、現在新機能を仕込んでいますので、乞うご期待ください。

 

絶賛仲間募集中です!

今後は現状機能としてある「CLUB」と「ENTERPRISE」を基盤としながら、スタートアップエコシステム内でのより良い出会いをサポートする機能を色濃くしていく予定です。スタートアップ×エコシステムビルダーやスタートアップ同士、エコシステムビルダー同士などの様々なパートナーとの出会いが同時多発的に創出されるようにするために、まだまだ仲間が必要です。

少しでもご興味頂けそうな際は、是非カジュアルにお話をしましょう!

 

▼Meety特集ページ
https://meety.net/articles/t2--lbkb5t1gd9

Wantedly
https://www.wantedly.com/companies/forstartups/projects

ブラウザで本番データの分析をするためにRedashとGoogleColabを組み合わせてみた話

f:id:forStartups:20211020185235j:plain

こんにちは。エンジニアの藤井(@yutafujii)です。

社内向けのプロダクト「タレントエージェンシー支援システム(SFA/CRM)」のエンジニアをしています。

当社ではデータ分析を専門に行う人がまだいないので、私たちエンジニアがごく簡単なデータ分析を行う場面があるのですが、それを行うためにPythonでの分析環境を手軽に構築しました。

具体的には、複数のRDBやログデータを対象に、RedashでSQLを書いてデータレイク的状態(あるいはデータウェアハウス的状態)を形成し、Google Colaboratory(以下Colab)を用いてその出力をPythonで分析するという流れを説明します。

データ分析を本格化する前のサービス運用をしているPdM・エンジニア・マーケターや、片手間にPythonで分析したいという人を想定読者とさせていただきます。

モチベーション

一言でいえば「データ分析基盤もないし分析者もいないけどちょっとデータ分析したい」というのがこれを思いついたきっかけです。

私は本業がプロダクト開発でデータ分析をする稼働もあまり割けないという事情もあり、いきなりがっつり構築して運用コストがかかるのは避けたいところでした。というわけでざっと満たすべき制約や要件を挙げると次のようなものになりました。

要件

  • Pythonで分析できる
  • 分析が属人化しないこと
  • 当たり前ですがセキュリティリスクが低いこと
  • 運用コスト(労働コスト・費用)が低いこと

なお私が入社したときには既にBIツールとしてRedashを利用している状態でした。

Pythonで分析するだけであればBIツールのSQL結果を自分のPCにダウンロードして、ローカルで立ち上げたJupyter Notebook上で分析するということで良いのですが(もちろんこれもやりました)、分析方法や結果の共有をするために

  • GitHubを通して分析コードを共有する
  • 共有者のローカルでjupyterを立ち上げる
  • データをローカルにダウンロードしてもらい分析する

という複雑なステップを踏む必要があります。また、本番データがローカルPCに蓄積することのセキュリティリスクも気になります。

共有のしやすさという観点からブラウザ上で分析したいなと思いつつ、Jupyter NotebookコンテナをAWSのサーバーで起動させることも考えましたが、そこまで使わないのにメンテナンスも認証もセキュリティ対策も全部自分でやるのは面倒だなと思い、Colabを思いつきました。

初めて知る方のためにも、RedashとColabについて簡単に説明しておきます。

Redashとは

f:id:forStartups:20211019215332p:plain
f:id:forStartups:20211019215401p:plain
出所)LP

RedashはオープンソースのBIツールです。弊社ではEC2に載せてRedashサーバーを起動することでブラウザから利用しています(これらの構築手順もHPに載っています:https://redash.io/help/open-source/setup)。

Redashにはざっと以下のような機能があります。

1.認証・認可

Google OAuthの設定が容易にできる。また権限設定も簡単

2.複数のデータソースと接続

RDBMS、各種NoSQL、Google Analyticsスプレッドシートなど

3.クエリ結果の保存

→Redashが保有する固有のデータベース(SQLite3)に格納される

4.クエリ結果へアクセスするAPIの発行

CSVJSON形式でそれぞれ固有のURLが発行される

5.複数ソースからデータの結合

→クエリ結果を保存するRedashのデータベースに対してSQLを発行することで実現

これらの機能を活用することで、データレイクや、データウェアハウスを形成することができます。クエリを書かずに集計ができないため非エンジニアが使いにくいとか、クエリの説明を付ける場所が小さすぎて出力数字の定義を把握しづらいとか、承認フローなどがないのでSQLが一方的に増えがちなどの課題もありますが、それでもクエリを一元的に発行出来る場所があることは非常に助かっています。

Colabとは

f:id:forStartups:20211019215446p:plain

Colabの愛称で利用されているColaboratoryはGoogleが提供しているサービスで、ブラウザでのPython実行環境を提供しています。その特徴は

  • 構築作業がゼロ
  • GPUへのフリーアクセス
  • シェアの容易さ

というもので、今回の要件にどストライクなサービスです。pipにもanacondaにも触れることなくいきなり

import numpy as np
import pandas as pd
import seaborn as sns

from sklearn.linear_model import LinearRegression
from sklearn.model_selection import train_test_split

といったコードを書き始めることができます。

Google Driveと同様のアクセス権限・共有設定が可能なので、認証と認可も実装することなく使えます。ソースコードや演算はGoogleクラウド上で行われますが、利用規約を読む限りそれらがGoogleに利用されるということはなさそうです。もちろんGoogle側の脆弱性があった場合に自分たちのデータもリスクに晒されるわけですが、一旦このリスクは許容しています。

f:id:forStartups:20211019221815p:plain
Colabの利用イメージ

構成

というわけでRedashとColabを組み合わせてできる分析構成は以下の通りになります。

f:id:forStartups:20211019221914p:plain
全体の構成

まず、Colabで分析したいデータをRedashで構築しておきます。

Colab側で利用するSQLを作成し

f:id:forStartups:20211019221959p:plain

右上の3点リーダーから「Show API Key」を選択

f:id:forStartups:20211019222023p:plain

クエリ結果へのアクセスリンクが表示されるのでJSONフォーマットのURLをコピー

f:id:forStartups:20211019222047p:plain

Colabを開いて、あとはコピーしたURLにアクセスするだけです

f:id:forStartups:20211019222104p:plain

Colabサンプルコード

import numpy as np
import pandas as pd
import requests
import json

# Redash query resultにリクエスト
URL = 'https://YOUR_REDASH_DOMAIN/api/queries/QUERY_ID/results.json?api_key=XXXXXXXXXXXXXXXXX'
raw_html = requests.get(URL).content
x = json.loads(raw_html)

# Create Dataframe
d = x['query_result']['data']['rows']
df = pd.DataFrame(d)
df

以上です、構築は非常に簡単ですし、エンジニアでなくてもできるのではと思います。

実際に作られたColab上での分析です。快適ですね。SQLでは面倒な集計、細かい設定の可視化や線形回帰などを実際に書いています。

f:id:forStartups:20211019222130p:plain
実際に分析したグラフ

おわりに

冒頭の「モチベーション」で記載した「データ分析基盤もないし分析者もいないけどちょっとデータ分析したい」という目的と制約要件は、Redash + Colabで問題なく充足することができました。

要件

Pythonで分析できる

 →ColabでPythonを利用できる

分析が属人化しないこと

 →ColabはURLシェアだけで他の人とシェア可能

当たり前ですがセキュリティリスクが低いこと

 →認証、サーバー構築を自作せずGoogleにリスクを転嫁

運用コスト(労働コスト・費用)が低いこと

 →Colabはフリーで利用可能

構築の手間を考えると非常に便利だと思いつつ、今後はしっかりデータパイプラインを構築してデータレイク・データウェアハウスをきちんと整えていきたいところです。現状ではまだ乱立したローデータと、データレイクとデータウェアハウスが混在したようなRedashクエリ結果しかないため、このあたりを改善してくれる人がいたらぜひお話しさせてください。