for Startups Tech blog

for Starupsのテックブログです

Nuxt Bridgeを使ったNuxt3の導入調査してみた

こんにちは。エンジニアの大野です。主にフロントエンド周りを担当しています。

去年の話題にはなりますが、2021年10月にNuxt3のベータ版がリリースされました。

f:id:yyohno:20220329150316p:plain
Nuxt3beta

公式のリリーススケジュールでは、このブログを書いている2022年3月にrc版、 そして2022年6月には安定版をリリースする予定となっており、着々とバージョンアップへの準備が進められている雰囲気が伺えます。

弊社にもNuxt2の環境で運用しているプロジェクトがあるのですが、vue3のリリース直前に作成した環境であるため、Composition Api やTypeScriptは別途runtimeやbuildのモジュールを個別に入れたりしており、package.json やnuxt.config.ts の設定周りがやや煩雑になっていました。

Nuxt3ではこのあたりのモジュールが標準搭載されるということもあり、チームとしても移行を前向きに検討したいという話が挙がり、実環境にNuxt3を入れてもろもろ調査してみよう、ということになりました。

今回は、実際にNuxt3をプロジェクトに導入しようとして行ったことを書いていきます。

はい。あくまで導入「しようとした」だけです。

f:id:yyohno:20220329152103p:plain
https://v3.nuxtjs.org/getting-started/introduction/

Nuxt3自体もまだ本番環境対応はしてませんので、ご注意ください。

Nuxt3へのアップグレードを検討されている方々の参考にでもなれば幸いです。

プロジェクトのフロントエンド事情

Nuxt3導入予定プロジェクトのバージョン周りは以下のようになっています。

node -v
v14.15.4

npm --version
6.14.10

yarn --version
1.22.10

package.jsonのフロントエンド周り

"vue": "^2.6.11",
"@vue/composition-api": "^0.6.6",
"nuxt": "^2.13.0",
"@nuxt/typescript-build": "^1.0.3",
"@nuxt/typescript-runtime": "^0.4.10",

@vue/composition-api がいまだ0.x.x 版なあたりにミーハー感が漂ってますね。

ちなみに、@nuxtjs/composition-api という便利なnuxt用モジュールがあることも後から知ったのですが、 リファクタリング作業が面倒だったので現状未対応でした。

当初の導入想定フロー

スプリント(1スプリント = 2week)開始前に、以下のようにざっくりと計画を立てました。

  1. Nuxt2からの移行用ツールとして公式に用意されている Nuxt Bridge を導入
  2. 開発環境にて動作確認(yarn dev)
  3. ステージング環境にて動作確認(yarn build、CIによるデプロイ)
  4. 既存コードをリファクタし、Nuxt3 に対応させる

結論から言ってしまうと、1スプリントで4の作業まで到達することは出来ませんでした。

本記事にもリファクタ内容などは特に記載していませんので、ご承知おきください。

以下、思い出すだけでも頭が痛くなってくるのですが、実際に導入作業を行った際にハマったポイントなどについて記載していきます。

開発環境が動くまで

影響範囲の大きかったエラーと対処法について、3点ほど書かせていただきます。

500エラーがお出迎え

まずはnodeのバージョンを上げておかないと、yarn install 時にエラーが出て Nuxt Bridge がインストールできません。 そのため、v14.15.4 から、本ブログ執筆時点のLTE版である v16.14.0 にアップグレードしています。

この時点で少々嫌な予感はしていたのですが、その後は公式手順通りに package.jsonnuxt.confit.tstsconfig.json などを書き換えていきました。

前述の通り @nuxtjs/composition-api は使用していなかったので、既存コードの書き換えはこの時点では特に発生せず、良かったな、程度に思っていました。

が、書き換えを終えた時点で yarn dev (nuxi dev)を実行してみると…ローカルサーバーは起動こそするけれどもページ自体は500エラーで開かず、という状態。 この後しばらく新しくなったNuxtのエラーページと戦うことになります。

とりあえずは500エラーのログに node-sass の記載があったため、node-sass もモジュールアップデートする必要があるのかな?と思い、npmを見に行ったところ

f:id:yyohno:20220329152347p:plain
https://www.npmjs.com/package/node-sass

非推奨モジュールになっていました…

仕方ないのでページに記載されている通り、Dart Sass への移行を合わせて行うことにします。

が、置き換えた後に再度 yarn dev を実行してみるも500エラーは解消されず。 詳細を調べてみると、今度はDart Sassのコンパイル時に使用している fiber というモジュールが node v16 に対応していませんでした。

この時点で、nodeのバージョンを下げるか、コンパイル速度の低下を承知でfiberを切るかの2択を迫られたのですが、コンパイル速度の低下がまだ目に見えるほどではなかったため、後者を採用してnuxt.config.ts 内の設定値を書き換えました。

f:id:yyohno:20220329153446p:plain
fiberは使いません

その後ようやくビルドが通りこそすれど、 Dart Sass に準拠していない記法が警告を大量に出してきたため、個別に未対応モジュールのバージョンUPを行ったり、既存コードのディープセレクタ周りの記法を書き換えたりする作業が発生しました。

configで別ポートを指定しているにも関わらず、開発サーバーが3000番で起動する

nuxt.config.ts の設定で portを指定して localhostを動作させていたのですが、なぜか yarn dev を叩いても docker-compose up を叩いても localhost:3000 しか開けない、という状態でした。

NuxtConfigの型定義を見に行くと

f:id:yyohno:20220329153307p:plain
あら?

ignoreされるようになったみたいですね。

docker-compose.yml 内で指定するか package.json のコマンドに環境変数として付与するかはちょっと迷ったのですが、最終的には起動コマンドと一緒に渡すように修正しました。

package.json

"dev": "HOST=\"X.X.X.X\" PORT=XXXX nuxi dev",

ホストやポートを指定するため、docker-compose.yml 周りもちょっと確認する必要が出てきたりで、こんなはずではなかった感がほのかに漂ってきています。

src/pages/ に配置したvueファイルを読んでくれない

ルートに置いた app.vue は読み込んでくれるのに src/pages/xxx.vue は読み込んでくれない…という現象でした。

あまり深く追っていないのですが、Nuxt3 では pages ディレクトリがオプション構成に変更されているなどの変更があったので、このあたりのディレクトリ解釈ロジックにも変更が入ったのでしょうか。

f:id:yyohno:20220329153500p:plain
特に注記はなさそう

以前は srcDir の設定値に src/ を指定していたのですが、 ディレクトリ名がまずいのかな? ということで、上記デフォルト値通りに client/ を指定できるようにディレクトリ構成を変更したところ、想定通りの読み込みをしてくれました。

が、こちらは当初から想定外の大きな変更であり、最終的にはdocker周りのbuildspecやMakefile まで修正しにいく羽目になりました。

ステージング環境が動くまで

上記の様々なエラーを乗り越え、ようやく開発環境が今までと近い形で動くようになったので チームメンバーに動作確認を依頼するため、ステージングデプロイを行ったのです、が。 ここからも割と長めの対応作業に追われることになってしまったので、こちらも3点ほど挙げさせていただきます。

@nuxtjs/fontawesome が使えない

fontawesome-svg-core の export がES6形式に未対応のようでエラーを吐いてました。nuxt.config.ts の transpile にfontawesome関連のモジュールを全て放り込んでも解決せず。

@nuxtjs/fontawesome のモジュール更新頻度が低そうなこともあったため、 fontawesome 使用箇所を全てSVGファイルを読み込む形式に修正して対応しました。モジュール側で何かしらの対応がされると良いのですが…

ちなみにこのエラーが開発環境構築時に出てこなかった理由は、単にfontawesomeの設定をコメントアウトにして開発環境を動かしたからです。 問題の後回しは良くないですね。

__dirnameが使えなくなるので書き換えたimport.meta.url も使えない

上記使用したファイル読み込み処理があったため、import.meta.url から情報取得してファイル読み込むように書き換えたのですが、import.metaconst import_meta のようにコンパイルされてしまう始末…

以下の設定を nuxt.config.ts に追記し、nitroのビルド設定を変えることで解決しました。

f:id:yyohno:20220329153832p:plain
nitroではesbuild使ってるんですね

server配下に静的ファイルを配置しても.output(dist)に持っていってくれない

ステージング環境のe2eジョブがこけていたので原因調査したところ、表題にぶち当たりました。

以前は server/api に置いた静的ファイル(JSON)を dist に配置してくれたのですが、NuxtBridgeではimport形式で書かれていない静的ファイルをbuild対象外と判断するようになったみたいです。

jsonファイルを読み込んでいる処理をまるごとimportに置き換えることで解決はしたのですが、既存のコードを追って改修する必要が出たため、こちらも地味に面倒な作業でした。

あとがき

最終的に調査結果としてチームメンバー宛に出したPull Requestは

f:id:yyohno:20220329154051p:plain
152!?

だいぶ気まずい仕上がりとなっていました。

この後にも script setup 記法への変更や inject -> useStateの 置き換え、definePropsの使用などなど…のリファクタリング作業が山程控えており、

まだまだ道のりは長そうなのですが、いつかNuxt3最高、と言える日が来ることを願っております。

Elasticsearch Aggregationsを使用してファセット検索のコンテンツ数を取得したお話

はじめに

こんにちは、エンジニアインターン生の光岡です。

STARTUP DBのエンジニアをしています。

今回は、STARTUP DBでElasticsearch Aggregationsを使用したファセット検索数の取得を実装したので詳細を書いていこうと思います。

Elasticsearchとは

Elasticsearchとは、分散型で無料かつオープンな検索・分析エンジンです。*1 スケーラビリティと高可用性に優れているため、多くのサービスで検索システム、ログ分析などに活用されています。
STARTUP DBも企業等の検索機能にElasticsearchを使用しています。 13,000社以上の企業検索の高速化を実現するため、日々改良を加えながら活用しています。

STARTUP DBが抱えていた課題

STARTUP DBではファセット検索を設置しユーザーに検索の切り口を提示しています。検索タグごとにコンテンツである企業数を表示していますが、この数値の更新を行うバッチ処理の負荷が高いという課題がありました。

ファセット検索とは

ファセット検索(ファセットナビゲーション)とは、サイトのナビゲーションの種類を指す用語です。
ユーザーに検索条件を入力させるのではなく、あらかじめユーザーに使いやすいであろう検索条件をサイト側が用意しておき、ユーザーはそれを選ぶだけでコンテンツを絞り込んでいけるような仕組みのことを指します。*2

またSTARTUP DBでは、各タグの右側に、そのタグの検索でヒットする企業数を表示しています。

タグ一覧ページ f:id:hiromitsuoka:20220328184708p:plain

メディアタグによる検索 f:id:hiromitsuoka:20220328184723p:plain

更新処理とパフォーマンスの問題

今まではタグを起点にした検索で企業数を取得していました。
しかし、タグの個数分Elasticsearchにクエリを発行するためパフォーマンスがよくありません。また、企業数の取得は1時間に1回のバッチ処理を利用して更新していたため、そのタイミングだけ繰り返しリクエスト数が上昇していました。

下記グラフは深夜時のリクエスト数のため、バッチ処理以外のリクエスト数は少ないですが、日中はリクエスト数が増加し、リクエスト数が多いことによるエラーが数件発生してしまい、急いで対応する必要のある課題でした。

f:id:hiromitsuoka:20220328184536p:plain
Elasticsearchに対するリクエスト数の推移

解決策

STARTUP DBが検索で利用しているElasticsearchにはAggregationsという、ある特定の条件に基づく集計結果を1つの応答にまとめて返す機能があります。
今回はこのAggregationsを利用することで、タグに紐付く企業数を1回のリクエストで取得できるよう改善します。

Aggregationsとは

ElasticsearchにはAggregationsという機能があり、データの統計情報をグループ化したり展開したりすることができます。検索を実行すると同時に、その検索によるヒットの結果とは別に、集約された結果を1つの応答にまとめて返すことができます。SQLの場合、GROUP BYと同等の機能になります。

公式ドキュメントに掲載されている例として、米国口座の位置情報を保持したElasticsearchに対して、全ての口座を州ごとにグループ化して、下記のような1回のレスポンスに全ての結果を返すことができます。*3

{
  "took": 29,
  “timed_out”: false,
  “_shards”: {
    “total”: 5,
    “successful”: 5,
    “failed”: 0
  },
  “hits” : {
    “total” : 1000,
    “max_score” : 0.0,
    “hits” : [ ]
  },
  "aggregations" : {
    "group_by_state" : {
      "doc_count_error_upper_bound" : 20,
      "sum_other_doc_count" : 770,
      "buckets" : [{
        "key" : "ID",          # アイダホ州
        "doc_count" : 27
      }, {
        "key" : "TX",          # テキサス州
        "doc_count" : 27
      }, {
        "key" : "AL",          # アラバマ州
        "doc_count" : 25
      },  {
        "key" : "MD",
        "doc_count" : 25
      }, {
        "key" : "TN",
        "doc_count" : 23
      }, {
        "key" : "MA",
        "doc_count" : 21
      }, {
        "key" : "NC",
        "doc_count" : 21
      }, {
        "key" : "ND",
        "doc_count" : 21
      }, {
        "key" : "ME",
        "doc_count" : 20
      }, {
        "key" : "MO",
        "doc_count" : 20
      },]
    }
  }
}

また、Aggregationsには合計や平均などを計算して出力するMetric、他の集計結果から入力を得るPipeline、フィールド値や範囲の基準に基いてグループ化するBucketの3つの集計のカテゴリーが存在します。*4

今回の実装ではフィールド値にタグ名を指定してグループ化する必要があるため、Bucketを使用します。

実装

今回の実装では、各タグに紐付く企業数を1回のリクエストで取得していきます。 Aggregationsを用いたクエリを作成し、レスポンスを確認してみます。

クエリ作成

先ほど述べたBucketによる集計を行うため、Terms aggregationによるfield指定で、タグ名毎にbucketを作成して集計していきます。

また、企業情報を持つドキュメントは一部ネストした状態でデータを保持しています。今回対象のタグもネストして保存しているため、Nested aggregationを参考にして企業数を集計するクエリを作成します。

* 企業情報のドキュメント構成(mapping)

"mappings" : {
  "dynamic" : "false",
  "properties" : {
    "id" : {                    # 企業ID
      "type" : "integer"
    },
    “name”: {                   # 企業名
      “type” : “keyword”
    },
    “tags” : {                  # タグ情報
      “type” : “nested”
      “properties” : {
        “id” : {                # タグID
          “type” : “integer”
        },
        “name” : {              # タグ名
          “type” : “text”
          “analyzer” : “synonym_keyword_analyzer”
        },
        “slug” : {              # タグのslug
          “type” : “keyword”
        }
      }
    }
  }
}

企業のID、名前などの情報の他に、タグのID、名前、slugをネストさせて構成しています。

タグ毎に集計する際、tag.slugをfieldに指定しグループ分けします。

* 企業数を集計するクエリ

aggs : {
  “tags” : {
    “nested” : {
      “path” : “tags”
    },
    “aggs” : {
      “tag_slug” : {
      “terms” : {
        “field” : “tags.slug”,
        “min_doc_count” : 0,
        “size” : 10000
        }
      }
    }
  }
}

実装上の工夫

クエリ作成時に、ネストしたaggs内でsize指定を行わないと、企業数がタグ10件分しか返ってきませんでした。
原因は、既存のクエリで設定している、ある条件による検索のヒット数に対するsize指定が、ネストしたaggs内での集計結果数には反映されないことでした。そのため、sizeの指定が無い場合、Elasticsearchはデフォルトで10件のみを返します。 今回は、Elasticsearchで設定でき得る最大値の10000を指定して対応しています。

レスポンス

上記のクエリを使用することで、buckets内に ”key”, “doc_count” の組み合わせで、各タグに紐付く企業数の一覧を取得することができます。

{
  .
  .
  “aggregations” : {
    “tags” : {
      “doc_count” : 100,
      “tag_slug” : {
        “doc_count_error_upper_bound” : 0,
        “sum_other_doc_count” : 0,
        “buckets” : [
          {
            “key” : "b2c",
            “doc_count” : 10
          },{
            “key” : "b2b",
            “doc_count” : 9
          },{
            “key” : "media",
            “doc_count” : 8
          },{
            “key” : "finance",
            “doc_count” : 7
          },{
            “key” : "entertainment",
            “doc_count” : 6
          },{
            “key” : "hr",
            “doc_count” : 5
          },
          .
          .
          .
        ]
      }
    }
  }
}

バッチ処理では、このレスポンスを基に各タグの企業数をTagsテーブルに保存しています。

実装前はタグの個数分Elasticsearchにリクエストを送ってしまいましたが、1回のリクエストで取得することができました。

f:id:hiromitsuoka:20220328184418p:plain
修正後のElasticsearchに対するリクエスト数の推移

実装を終えて

1回のリクエストで全てのタグに紐付く企業数を取得できるようになったことで、負荷を下げ、安定したパフォーマンスでElasticsearchを稼働させることができるようになりました。 その結果、バッチ処理の更新期間を短くすることで、STARTUP DB専任リサーチャーが取得してきた企業情報をよりタイムリーに反映することが可能になりました。

STARTUP DBはSTANDARDプランを先月開始し、日々アップデートしています。より最新の情報をお届けできるよう引き続き開発に取り組んでいきます。

参考リンク

フォースタートアップスでやってる輪読会を紹介します

一緒に本を読む子供たちのイラスト(男の子)

 

どうも、ばやし@bayashimuraです。
今日はエンジニア組織で行われている輪読会について紹介していこうと思います。

フォースタでの輪読会

フォースタでは週に一回一時間、業務時間内に輪読会をやっています。かれこれ2年ほど続いており、エンジニアのスキルアップに寄与しています。

これまでに以下の本を読んできました。

特徴としてはプロダクトマネジメントの本から監視の本まで幅広く読んでいるところでしょうか。うちのフルサイクルな開発を行っている特徴が出ていますね。フルサイクルな開発スタイルに関しては手前味噌ですがこちらのスライドでご紹介しております。

speakerdeck.com

目的

輪読会をやる目的として3つあります。

  • メンバーのスキルレベルアップ
  • 共通言語を作る
  • チーム間の交流

メンバーのスキルレベルアップ

エンジニアという職種は、常にキャッチアップが求められる職種です。そのため現状の開発をずっと続けていくだけでは、どこかで限界が来てしまいます。キャッチアップに関して「プライベートでやってね」でもいいのですが、小さなお子さんがいるなど色々な理由でプライベートではキャッチアップ出来ないことも踏まえ業務時間をスキルアップに投資しています。また一人で読むよりも複数人で同じ本を読むことで、自分が理解出来なかったことを聞いたり、逆に聞かれて教えたりすることで理解が深まる建設的相互作用が働くことを期待しています。

共通認識を作る

もう一つの目的として、みんなで同じ本を読み同じ知識を共有することで組織の共通認識になることを狙っています。共通認識を作ることで、スピーディな議論や意思決定ができます。例えばうちのチームでテーブル設計の議論をしている際に以下のような会話が出てきます。
「それってSQLアンチパターンで出てこなかったっけ?」
「あ〜確かに。SQLアンチパターンの〜に当てはまりそう。しかも書いてあったリスクもろかぶりしそうですね。ちょっと考え直します」
テーブル構造に問題を見つけた人が、どういう構造的問題があるか、それによってどういうデメリットやリスクがあるかを一々説明しなくてもSQLアンチパターンの〜ですね、で会話が通じます。スピーディ。

チーム間の交流

フォースタは大きく分けてSTARTUP DBチームとタレントエージェンシープロダクトチームの2チームが存在します。輪読会はチーム関係なくみんなが参加します。日常業務ではそこまで交流がないため、お互いの知識が交換されるタイミングが少ないのですが、こういった輪読会を行うことで交流が発生するようにやっています。お互いのプロダクトの本に該当しそうな部分を紹介することで、お互いのプロダクト理解にも繋がります。

 

やり方

本の選び方

各々読みたい本を持ってきて「読みたい本紹介バトル」をします。

ルールはビブリオバトルと同じです。読みたい本紹介バトルは推薦人も読んでないケースが多いので「何故読みたいか」を熱く語ります。

www.bibliobattle.jp

例えば以下のような感じです。

「今我々はマイクロサービスでやっているが、マイクロサービスに対しての理解が各人でばらつきがある。ここはSam Newmanの『マイクロサービスアーキテクチャ』を輪読したい」

「先程の紹介ではSam Newmanのマイクロサービスアーキテクチャを紹介していたが、単純にマイクロサービスアーキテクチャをおすすめするだけではない(ってレビューで書いてあった)『モノリスからマイクロサービスへ』を読みたい」

「メンバーも増えてきて知識のベースラインを揃えていきたい。ここは『体系的に学ぶ 安全なWebアプリケーションの作り方』を輪読しよう」

こういった紹介をみんなで行いその後投票し、一番票が集まった本を読みます。

 

読み進め方

輪読会までにみんなで1章分くらい読んできます。以前は「みんなどうせ事前に読んでこないだろ」と思い、最初の30分をみんなで本を読む時間に当てていました。しかし参加メンバから「もっと議論する時間が欲しい」という意見が上がり、事前に読んでくる今のスタイルになりました。

その後チームに分かれチーム内で色々議論します。チームを分ける理由としては

  • 人数が多くなると発言する人が偏る
  • 「自分こんなこともわかってないことみんなにバレたくない」を抑止する

みたいな感じです。みんなが発言できるワイワイ感が出るのは、今のうちの組織だと5人くらいが丁度良さそうという感覚を持っています。

またチームの分け方も出来るだけパーソナルな面が出るような質問で分けてたりします。例えばこれまででは以下のような質問をしました。

「本を読むときは 『電子書籍派』or『紙派』」
「北海道行ったこと 『ある』or 『ない』」

前述の通り輪読会は数少ないチーム同士の交流の場であり、そこでお互いの人間性を知り共通の話題を得ることを目的にしています。ただパーソナルな部分は出てほしいのですが、そこに抵抗感や本気の対立が生じると不本意なので、出来るだけ会話に繋がりやすくかつ軽いテーマを考えるのに毎回一苦労です。

議論の進め方は基本的にその時その場で作られたチームによって違いますが、大体は「染みた一文」や「疑問に思ったところ」を会話のきっかけに40分くらい話します。過去のプロジェクト、今やってるプロダクトの話、最近twitterで見た話など、横道にそれるのは大歓迎です。みんなの中にある知識、疑問が表出するのも輪読会の良いところだと思っています。

議論中はファシリテータがファシリしながら話した内容をnotionにまとめます。みんなで勝手に修正したりもします。話したあとは、各チーム集まりチームの中で話した内容を共有します。こんな感じでちょっとずつ読み進めていきます。

本の分量にもよりますが、大体2,3ヶ月に1冊読み終わります。読み終わったらまた本の紹介バトルが始まります。

 

以上、フォースタの輪読会の紹介でした。

 

フォースタはエンジニア、デザイナー大募集中です。こういうのやりたいなーと思った方は一度カジュアルに話しませんか?

Meetyはこちら

meety.net

国内最大級の(オープンイノベーション)グローバルカンファレンス FUSE vol.2 を盛り上げたクリエイティブ

f:id:forStartups:20220222122106j:plain

はじめに

今回は2022年1月20日に行われた、フォースタートアップスとCIC Tokyo主催の国内最大級の成長産業支援カンファレンス「FUSE」vol.2をクリエイティブで支えたデザイナーたちがそのコンセプトや制作秘話を綴っていこうと思います。

FUSEとは?
昨年開催され3,000名以上の方が参加した、日本経済の再成長のため、スタートアップや大手企業、アカデミア、行政などの協業・共創をプロデュースするイベント、『FUSE』。

国内スタートアップエコシステムに加えて、海外セッションも多数登場。イノベーショントレンドや日本への関心についてなど、海外投資家や大手外資企業が登壇。日頃聞くことが出来ないリアルな海外市場についてお届けする成長産業カンファレンスです。

キービジュアルについて

Webサイト及びキービジュアルを制作したデザイナーの長峰です。

ヒアリングの実施

まず、プロデューサーへのヒアリングからスタートしました。
その中でもグローバルに発信していくことは特に重要視しており、日本のスタートアップを世界へ発信する場にしていく強い意志がありました。

f:id:forStartups:20220222122213p:plain

要件を整理するために、感性要件(感性に作用するイメージ部分)と機能要件(具体的に作用すべき部分)に分けました。

f:id:forStartups:20220222122347p:plain

ブランドカラーを設定しました。

f:id:forStartups:20220222124101p:plain

ブランドロゴ

FUSEロゴを継承しながら、比類なき挑戦を表現するためvol.2の文字はブランドカラーの描き文字としました。

f:id:forStartups:20220222124234p:plain

キービジュアル完成

このカンファレンスに参加される方は成長産業に期待し、挑戦している方達です。その挑戦者たち一人一人をドットに例えて、たくさんのドットがFUSEをハブにすることで繋がり、イノベーションが起こる様子を可視化しました。

f:id:forStartups:20220222124313p:plain

アレンジver.

f:id:forStartups:20220222124349p:plain

WEBサイトについて

WEBサイトはキービジュアルをベースに、コンテンツの魅力を最大限可視化していくことが必要です。今回、デザインから実装までシームレスに行う必要があったため、ノーコードツールのWebflowを使用しました。また多くの登壇者、セッションが盛り込まれているため、情報を効率的に表示させるためCMSを設計し、プロジェクトチームと連携できるようにしました。

トップ画面

トップ画面はオープニングムービーを背景とし、カンファレンスの熱量が伝わるようにしました。

f:id:forStartups:20220222124455p:plain

Speakers

CMSを活用し、プロジェクトチームと連携して、データベースに情報を格納するとデザインが反映する設計にしました。

f:id:forStartups:20220222124535p:plain

プログラム

CMSを活用し、クリックすることでオートマティックに詳細情報を表示できるように設計しました。

f:id:forStartups:20220222124613j:plain

詳細情報

f:id:forStartups:20220222124641p:plain

その他、Parallaxやfade inなどのインタラクティブ表現を駆使して、スクロールする感触を味わえるサイトを目指しました。

完成したサイトが以下です。 

fuse.forstartups.com

オープニングムービーの制作

FUSE vol.2のオープニングムービーを制作したデザイナーの多治見です。
2021年11月にフォースタに入社し1ヶ月も経たず任されたのが、こちらの映像制作でした。

f:id:forStartups:20220222124723j:plain

私は前職でグラフィックデザイナーとして新卒から5年間働いており、映像制作はお遊び程度でしか経験がなくこんな大々的なイベントの映像を作るには知識も経験も時間も足りない。ましてや入社1ヶ月も経ってない…イヤイヤ〜無理ですよ〜笑とやんわり断ろうと思ってました(そもそも周りも本気で任せようとも思っていなかった様子)。ですが、もしこれで動画をカッコよく作れば入社まもない自分の絶好のアピールチャンスなのでは…?と思い始め、いろんな葛藤がありつつも映像の制作を請け負うことにしました。

先ほども綴ったように、映像制作のノウハウもない私なので、まず最初はかっこいい映像を見てモチベーションを上げ、いざAE(アフターエフェクツ)を立ち上げ、制作に着手すると、文字の一つもカッコよく動かせない….というか動かし方がわからない…Adobe製品をいくつか触ったことのある自分なら感覚でどうにかなると思っていた自分を殴ってやりたい気持ちでいっぱいでした。…

それからは、YouTubeでAEの使い方を教えてくれている方の動画を見て業務中も休日も勉強をしまくる毎日でした(便利な時代に感謝)。そんな感じで日々インプットしては、試して見てうまくいったりいかなかったりを繰り返し、制作を進めていきました。

f:id:forStartups:20220222124817j:plain

f:id:forStartups:20220222124834j:plain

f:id:forStartups:20220222124851j:plain

今までグラフィックデザイナーとして静止画一枚のデザインをしていただけに、映像の動きと音楽がマッチして動いた時は、なんともいえない高揚感に襲われ、映像制作楽しい!となりました。

未熟なりに、ある知識だけで試行錯誤して映像を完成させ、社内で発表した時はいろんな方達から良い感想が頂けて、本当に挑戦してよかったと心から思いました。

ほぼ未経験の状態から1ヶ月に詰め込んでの作業でしたので、映像の改善点は数知れずですが、映像制作の楽しさを知れたので、これからも引き続き学んでいき、来年のFUSEにはもっとかっこいい映像を作れるよう精進していきたいと思います。

完成したオープニングムービーがこちらです。

youtu.be

まとめ

今回開催したイベントFUSEに関連するクリエイティブは、グラフィックデザイナーのお二人のセンスの光る完成度の高いものとなりました。すでにWebflowでコーポレートサイトを作っていたという経験も活きて、今回は短いスケジュールのなかで更新性も高いサイト構築ができたと感じています。

私たちデザイナーが所属するテックラボでは、自分の専門性を活かしチカラを発揮することは勿論、専門性を深め、そして広げるためのチャレンジをメンバーが日々行っているのが特徴と言えると思います。

成長産業支援を行うフォースタートアップスは、「(共に)進化の中心へ」というミッションを掲げています。それは私たち自身が成長していかねばならないという良い意味でのプレッシャーにもなっています。

現在(2022年2月時点)フォースタートアップスには4名のデザイナーと2名のデザイナーインターンが所属していますが、それぞれがそれぞれの場所で自分の専門性を発揮しつつ、デザイナー同士の連携も行いながら業務に取り組んでいます。
デザイン組織・デザイナー組織としてはまだまだこれからではありますが、日々コミュニケーションをとることを意識しお互いの知見を生かしたFBを行うなど、共に成長する環境が整いつつあると感じています。

まだまだ挑戦の日々ではありますが、こんなチャレンジングな環境で自分のスキルを深め、広げたい仲間を絶賛募集中です!ご興味のある方は是非一度気軽にお声がけいただき、カジュアルにお話を聞きに来て貰えたら嬉しいです。

We are Hiring!

f:id:forStartups:20211020192743p:plain

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

「すべては、スタートアップスのために。」for Startups(フォースタートアップス)の技術スタックを紹介します(2022年1月更新)

はじめに

フォースタートアップスCTOの戸村(@KenjiTomura)です。

フォースタートアップスでは展開している各事業の中で、プロダクトや管理ツールなどを開発しています。もちろんインフラ構築から監視、開発に採用する技術選定まで全てチームで議論して採択しています。

自由度があり非常にやりがいのある環境であると感じているのですが、「実際にどんなことをやっているのかよく分からない」というお声をいただくこともあります。本稿においてサービス(プロダクト)と技術視点でフォースタートアップスの取り組みと技術スタックを紹介します。

フォースタに興味のある方や、未来の一緒に働く仲間に読んでいただけると嬉しいです!

フォースタートアップスのご紹介

「for Startups」というビジョンのもと、インターネット/IoTセクターをはじめ、Fintech、リアルビジネス領域も含めた(IT、AI、SaaS、DeepTech、DisruptTech、ドローンテック、MaaS、5G市場など)の転職支援と起業支援を中核とした成長産業支援事業を推進しています。

サービスも提供しており、成⻑産業領域に特化した情報プラットフォーム「STARTUP DB(スタートアップデータベース)」(※スタートアップを中心とした13,000社以上の企業情報を掲載)を展開しています。

ここからフォースタートアップスで利用されている技術スタックについてご紹介させていただきます。

「サービス」と「技術スタック」のご紹介

1. STARTUP DB

STARTUP DBは、国内最大級の成長産業領域に特化した情報プラットフォームです。

企業データベースは、13,000社を越える日本のベンチャー・スタートアップ企業の情報を保有するとともに、起業家・投資家、エコシステムビルダーの方々累計150名以上のインタビューコンテンツをリリースしています。

また、世界最大級のベンチャー企業データベース「Crunchbase」とデータ連携し、日本企業の情報を海外のプロフェッショナルに届けることで、国内の成長産業領域市場の発展に貢献しています。

企業情報は専任リサーチャー用の管理画面を用意し、毎日情報をキャッチアップして更新していくのに加え、ニュースなどの公開情報を自動収集する技術的チャレンジも行っております。

 

今後の開発について

2018年にSTARTUP DBが誕生して3年目。2021年3月に大幅リニューアルを行った新生STARTUP DBがリリースされました。

そして2021年7月にSTARTUP DB ENTERPRISEをリリースし、BtoB SaaSプロダクトとしてグロースフェーズに入っています。

技術スタックとしてはリニューアル時に導入していたNuxt.jsやTypeScriptのおかげで、より開発しやすく、より厳密に、より速く、新しい価値をお届けすることができるようになっています。

IEなどのレガシー環境に対する対応も、LambdaTestとJestを組み合わせた自動テストを用いることで、効率的に行っています。

今後は、STARTUP DBに蓄積された大量のデータとフォースタ全体のスタートアップに関する知識を効果的に用いて、利用者に対しもっと高精度な多くの情報を届けていきます。

 

技術スタック

■フロントエンド:Nuxt.js / Vue.js / Express / TypeScript
■サーバサイド:Ruby on Rails
■インフラ・開発環境・CI/CD・監視:AWS(ECS・Redis・CloudFront・AWS WAF etc.)/ Firebase Authentication / Terraform・Terraform Cloud / Docker / CircleCI / Rollbar / Sider / Mackerel / Github Actions
■ツール・ドキュメント管理:GitHub / Slack / LambdaTest / Figma / Notion

 

2. スタートアップスデータプラットフォーム(SDP)

スタートアップスデータプラットフォーム(以下、SDP)はユーザーの皆様に安心して素早く大量に精度の高い情報を提供するシステムとなっています。
現在はSTARTUP DBおよびタレントエージェンシー支援システムのバックエンドのAPIサーバーとして稼働しています。
また、精度の高い情報を提供するため、情報を収集する仕組み、および、管理画面もSDB管理システムで開発しています。

 

今後の開発について

まずはSTARTUP DB、タレントエージェンシーシステムを利用しているユーザーに、可用性高くサービスを提供するべく開発を進めています。
これは、障害に対応するということだけでなく障害を発生させづらくする改善なども随時行っています。

また、SDPはAPIサーバー、管理画面、バッチサーバーと多くの役割を担っていることでシステムとして肥大化してきています。直接関連していないシステムを分割することで保守性を高くしていくことにもチャレンジしていきます。

 

技術スタック

■サーバサイド:Ruby on Rails / Flask(Python
■インフラ・開発環境・CI/CD・監視:AWS(ECS・Lambda・Elasticsearch・Redis・SageMaker・CloudFront・AWS WAF・Lambda@Edge etc.)/ Firebase Authentication / Terraform・Terraform Cloud / Docker / CircleCI / Rollbar / Sider / Mackerel / Github Actions
■ツール・ドキュメント管理:GitHub / Slack / Zapier / LambdaTest / Figma / Notion

 

3. タレントエージェンシー支援システム(SFA/CRM

タレントエージェンシー支援システム(SFA/CRM)は、日本を代表するスタートアップと、それを加速させることができるタレント(才気あふれる人々)とのより多くの対話の機会を創出するための「マッチングプラットフォーム」です。

また、ヒューマンキャピタリストの生産性向上を通して、「起業は人のブライトキャリア」というマインドのイノベーションを加速させることを狙いとしています。

※今後の展望に関しては、全てをこちらで語ることはできないので是非カジュアル面談でお話しさせていただけると嬉しいです。

 

今後の開発について

組織の拡大に伴いこのタレントエージェンシー支援システムがカバーする領域も拡大しており、重要なデータについては集約を進めるとともに、デプロイ頻度を高く保ちつつ安全なリリースが行えるようE2Eテストの導入も行いました。

事業を支えるプロダクトとして更なる機能改善はもちろん、開発において小回りが利くようにバックエンドとフロントエンドの責務分離やIaC管理の改善も行っていきます。

 

技術スタック

■フロントエンド:Nuxt.js / Vue.js / TypeScript
■サーバサイド:Ruby on Rails / Python
■インフラ・開発環境・CI/CD・監視:AWS(ECS・Lambda・Elasticsearch・Redis・CloudFront・AWS WAF etc.) / Terraform・Terraform Cloud / Docker / CircleCI / Rollbar / Sider / Mackerel / Github Actions
■ツール・ドキュメント管理:GitHub / Slack / Zapier / LambdaTest / Adobe XD / Notion / Playwright

開発手法・環境

アジャイル

弊社では継続的にアジリティやプロダクトの価値を上げ続けるため、スクラムをベースにアジャイルのプラクティスを組み合わせて開発しています。具体的に現在実施している内容としては、定期的なふりかえり、短いイテレーション、モブプログラミング、カンバン、プランニングポーカーなどです。ただしアジャイルコーチ経験があるメンバーと共に自分たちにとって最適な開発スタイルを探求し続けているため、これは現時点でのスナップショットになります。

 

その他

ソフトウェアエンジニアは業務の中で学習をし続けることが大切だと思っています。そのため週に1時間の輪読会、週に30分のLT大会の時間を設けています。これまでの輪読会では「プロダクトマネジメント」「Rubyで作るRuby」「UNIXという考え方」「SQLアンチパターン」「入門 監視」などを読んできました。

終わりに

フォースタートアップスのサービスの紹介と技術スタックをまとめてみました。

私たちはビジョンドリブンのチームです。

エンジニアドリブンでもプロダクトドリブンでもありません。

ビジョンを達成するために、どのようなものを作らないといけないか。

そのためにはどのようなエンジニアリングで取り組まないといけないか…という形で落としこんでいくので「技術のみに興味がある」といった志向の方は、少し合わない可能性があります。

ただ、技術的な挑戦がないわけではありません。

ビジョン達成のためには、技術を駆使して解決しなければいけない課題は多く、新しい技術を知らなければいけないので、当然のこととして様々な技術を取り入れています。

もしご興味を持っていただけましたらまずはカジュアルにお話をさせていただきたいです。

 

We are Hiring!

f:id:forStartups:20211020192743p:plain

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

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

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