for Startups Tech blog

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

【フォースタ テックブログ】ノーコードで業務効率化、PdMがZapierを活用した話

こんにちは、for Startups, Inc.でSTARTUP DBというサービスの責任者をしている寺田(@yuyaterada)と申します。来年春頃の大型リリースに向けて目下準備中です。

その中で、さまざまなタスク管理や人事業務が発生していますが、エンジニアにはプロダクト開発に集中してもらう為、タスク自動化ツール「Zapier」を導入しています。

今回はSTARTUP DB運営の肝にもなっている「Zapier」について紹介させていただきます。

Zapierとは?

海外の「IFTTT」などのiPaaSのひとつで、複数のウェブアプリケーションを連携させて、定型的な業務を自動化できます。エンジニアに頼んでコーディングせずとも、タスクの自動化をノーコードで実現できてしまいます。

zapier.com

活用事例を紹介します

1/【勤怠管理】インターンの勤怠報告忘れをSlackに通知

STARTUP DBの運営チームにはインターンが多く在籍していて、ジョブカン勤怠管理でシフト管理をしています。

勤怠報告忘れが発生した場合、Gmailに指定したキーワードを含むメールが届いたらSlackに通知するようにしています。

Formatter(text)で指定テキストを切り取り、Slackメッセージの文面調整をしています。

■通知画面

 

2/【問い合わせ対応】Googleフォームに新規投稿されたらSlack通知

STARTUP DBでは各種問い合わせフォームをGoogleフォームにしています。新規問い合わせが入ったら、Slackに通知されるようにしています。

 

3/【タスク管理】毎月1日に自動的にタスクをSlack通知&Trelloカード化

運営する中でのTodo管理はTrelloで行っています。毎月定例で発生するタスクは、自動的にSlackに通知とTrelloのカード化をしています。

 

4/【採用管理】インターン採用の応募をSlack通知&Trelloカード化&スプレッドシートに記録

現在インターン採用はWantedlyを主軸として集客をし、応募後のステータス状況をTrelloで管理しています。また数値分析をGoogleスプレッドシートで可視化し、健康状態を管理しています。

■手法

Wantedlyでエントリーメールがあり次第、自動でスプレッドシートに応募記録、Slack通知、Trelloカード化。応募メールは、ZapierのFormatter(text)で指定テキストを切り取る

リファラルなど、Wantedly以外のエントリーがあったら、手動でTrelloカード作成

 

 

②Trelloカードに面談日を設定し、面談前日になったら、Slack通知でアナウンスする

 

③書類選考から選考進捗があり次第、手動でTrelloのカード移動する

スプレッドシートに移動記録が登録され、選考ステータスによって列に◯or☓が入り、行の背景色の色が変更されるようスプレッドシートの条件付き書式で設定

※TrelloのカードIDで同カードの移動管理をしています

 

スプレッドシートの集計シートに数式を入れ、自動的に更新される

 

おわりに

いくつか活用事例を紹介しましたが、プロダクト開発においてエンジニアのリソースは最大の資産になるので、今後もZapierを使ってノーコードで実装できるものは自動化し、よりエンジニアが開発に集中できる環境を整えていけたらと考えています。最近社内のWikiツールで導入したNotionが近々APIを公開するという噂があるのでZapierにも連携されないか期待しています。

そんなfor Startupsではエンジニア、デザイナーを絶賛募集中です。

Zapierについても是非気軽に情報交換できたら嬉しいです!

【フォースタ テックブログ】既存のRailsアプリからVue/Nuxtを導入してサーバーとフロントを分離した話

 

はじめに

テックラボの藤井(@yutafujii)です。
社内向けのプロダクト「タレントエージェンシー支援システム(SFA/CRM)」のサーバーサイドエンジニアとして日々活動しています。

今回はRailsで作られたプロダクトにVueを導入したプロセスを紹介すると共に、実際に直面した論点や工夫点をお伝えできればと思います。

いま現在の実装環境

いま現在フロントエンド周りはNuxt/TypeScriptで主に動いておりますが、詳細な技術スタックがどうなっているのかは、別途まとめたこちらの記事を参照していただくこととして、本投稿ではRailsだけで書かれていたサービスでフロントエンドフレームワークを導入する過程について焦点を当てて書かせていただきます。

tech.forstartups.com

SPA化の背景

私が担当しているタレントエージェンシー支援システム(SFA/CRM)は、主に社内のヒューマンキャピタリストが利用するもので、顧客管理や業務プロセス管理のような役割を果たしています。

顧客管理やプロセス管理というアプリケーションの特性上、ユーザーは文字通り細かい作業をシステムで行うことが多く、いちいちページロードすると不便であることからリッチなフロントの動きが求められておりました(RailsガイドにあるようなRails-ujsを利用してapp/views/配下にたくさんの.js.erbを作成するには複雑すぎました)。

また、タレントエージェンシー支援システムを社内外問わず他のプロダクトと連携させるためにはAPIのエンドポイントが必要ですが、早めにこれを準備しておきたいという狙いもありました。

まとめると、今回SPA化を行ったのは主に2点の理由ということになります:

  1. リッチなフロントの動きが求められたこと
  2. APIのエンドポイントを用意することで他のプロダクトとの連携に備えること

Vueを選定

SPA化するにあたりフロントエンドにはVueを選定しました。主な背景は以下の通りです:

  1. 当社では他にもVueを用いたシステムが既に存在しており、今回も統一しておくことでVueを書く人を柔軟に配置できる
  2. サーバーサイドエンジニアが多く、学習コストを抑えたい

なお、導入時の各ステップは後述しますが、最初はNuxtは利用せずVueのみで実装しました。タレントエージェンシー支援システムはSEOの考慮が不要でSSRする必要がなかったほか、最初のステップではルーティングも必要としなかったためです。後半過程でフロント/サーバーを分離する際に初めてNuxtを導入することになります。

導入方針を考える時のチームの状況

ざっというと、SPA化しようと話し合っていたころのチームとプロダクトの状況はこんな感じでした:

  • 基本的には全てRailsで書かれている、画面も基本的にerbで実装
  • フロントエンドエンジニアが1名(着任したばかり)
  • サーバーサイドエンジニアが2名
  • デザイナーが初めてチームにアサインされてからまだ3ヶ月目
  • SPA化を前提としたUIのリデザイン案は作成済
  • デザイナー不在でも実装できるようCSSフレームワークが多分に活用されている
  • 事業利益へのインパクトを考えると、SPA化そのものに多くの時間は割けられない

要約するならば、デザイナー・エンジニアのなかでプロダクト・ソースコード・事業への理解度が高いメンバーはごく限られており、小回りしやすいように進めていく必要がありました。

実際に導入する

大きく3ステップに分ける

導入当時のチームの状況から、まずはミニマルなステップとして部分的にコンポーネント化を行い、その間にデザインシステムを完成させてリファクタリングと共にアトミックデザインを実装し、そのあと別途Nuxtで立ち上げるクライアント・BFFの乗ったサーバーに画面を段階的に移行するという3ステップで行うことにしました。

各ステップの概要は以下の通りです。

Step.1

既存のRails/viewファイル中にコンポーネントを導入し、既存ページの一部をVueでリプレイス(合わせてリデザイン)する

実際の最初のコンポーネントを作成した時のerbファイルの様子(変数名などは仮のものに置き換えてあります)

# app/views/clients/show.html.erb
 
<section class="content">
 <%= render 'client_detail', client: @client, display_button: true %>
 
<!-- 
ここにcontroller中で定義したインスタンス変数をDOMにattributeとして仕込み、JSがそれを起点にVueコンポーネントを生成する
-->
 <div id="jobs-list" data-meeting-id="<%= @client.meeting_id %>"></div>
 <%= javascript_packs_with_chunks_tag 'spa/pages/clients' %>
 <%= stylesheet_packs_with_chunks_tag 'spa/pages/clients' %>
</section>

Step.2

デザインシステムを完成させ、アトミックデザインにディレクトリをリファクタリング
さらに別の一部のページをコンポーネント

vueコンポーネント周りのファイルは以下のような構成で管理されるように

Step2を終えた段階のRails側のディレクトリ構成(一部)

app/src/javascripts/spa
├── assets
├── components
│ ├── atoms
│ │ └── 10 files
│ ├── molecules
│ │ └── 10 files
│ ├── organisms
│ │ └── 23 files
│ ├── pages
│ │ └── 1 files
│ └── templates
│ └── 4 files
├── mixins
│ └── 4 files
├── pages
│ └── 4 files
└── store
└── 15 files

Step.3

Nuxt/Vueで新たにクライアント・BFFサーバーを作り、既存機能を段階的にサーバー・フロント分離で実装

新規リポジトリでNuxt/TypeScript、ExpressでBFFを構成

Nuxtサーバー側のレポジトリ構成図

.
├── README.md
├── babel.config.js
├── deploy
│ ├── prod
│ └── stg
├── docker
│ ├── nginx
│ └── nuxt
├── docker-compose.yml
├── jest.config.js
├── jsconfig.json
├── node_modules
├── nuxt.config.ts
├── package.json
├── shims-vue.d.ts
├── src
│ ├── assets
│ ├── components
│ ├── composition
│ ├── layouts
│ ├── middleware
│ ├── pages
│ ├── plugins
│ ├── server
│ ├── static
│ ├── store
│ └── test
├── static
│ └── sw.js
├── stylelint.config.js
├── tsconfig.json
└── yarn.lock

悩んだ点・検討点など

実際に取り組む過程で遭遇した技術的な検討点などをいくつか紹介します。

認証方法の検討

一般的なRailsアプリケーションに倣って、タレントエージェンシー支援システムでもDeviseでセッションベースの認証を行っていました。APIでは認証をTokenベースで行うか検討したのですが、DeviseとDeviseTokenAuthを併用すると、omniauthリダイレクトのルーティングや一部Configがオーバーライドされるなど(https://github.com/lynndylanhurley/devise_token_auth/issues/1299)イシューが複数見つかり、まずはセッションベースで認証を行う方針にしました。

既存JSやWebpackerとの相性

タレントエージェンシー支援システムではこれまでデザイナーがいなくてもある程度の見た目が担保できるよう、CSSフレームワークを多く活用していたほか、jQueryがまだ随所に残っている状態でした。また、コンパイルにWebpackではなくWebpackerを利用していました。
これらの背景から、追加で実装したVueまわりのソースコードコンパイル時にエラーを生じることがあり、レポジトリ内の他のソースコードを考慮した実装が必要でした。

最初のコンポーネント化を終えてアトミックデザインにディレクトリをリファクタリングしようとしたときの検討メモ

TypeScriptの導入

タレントエージェンシー支援システムは金融・会計のような型の厳密さが要求されるシステムでこそありませんが、サーバーサイドをRailsで記述していることもあり、フロントエンドでは型安全なシステムとして構築することは全体の安定性を向上させると考えました。Vue3.0ではTypeScriptサポートが拡充される風潮も踏まえ、このタイミングで合わせて導入することとしました。

TypeScriptの学習コストは必要ではあったものの、サーバーサイドエンジニア全員でモブプログラミングを行うなど時間を確保して実装スキルの底上げを図りました。

Composition APIの利用

TypeScriptを利用するにあたり、これまでもvue-class-componentsを用いてClassをTypeScriptクラスとして用いる方法が存在しましたが、現在も実装方針が未確定のdecorator(https://github.com/tc39/proposal-decorators#standardization-plan)に依拠しているなどの問題も抱えています。それと比較してComposition APIhttps://composition-api.vuejs.org)はTypeScriptとの親和性が高いため、このタイミングで導入してみることにしました。

振り返り

着想してから9ヶ月が経ち、途中チーム人数も3名から5名に増え、新規機能開発も並走しながらの取り組みでしたが、9月には無事にNuxtのサーバーが本番環境で稼働を開始し、現在も大きな問題なく運用できています。

フロントエンド・サーバーサイドのエンジニア目線で言えば、デザイナーさんがこまめにXDを共有してくれていたことや、ワイヤーフレームを元にSwaggerでエンドポイントの定義を最初に時間をしっかりとって行ったことは良かった点なのかなと考えています。

プロジェクトの振り返りをチームで実施してKPTを洗い出し、次回同じプロジェクトに取り掛かるのであれば最初にDONEの定義を決めておくことなどがTryとして掲げられました。

おわりに

今回はRailsにフロントエンドフレームワークとしてVueを導入する過程について紹介させていただきました。

現在はまだerbで記述された部分もありますが、今後も段階的に画面をVueでの記述に変更していき、最終的にはRailsAPIサーバーとして①データソース(RDB・Elasticsearchなど)からデータを取得する②ビジネスロジックを記述してAPIの戻り値を整形する、という2つの役割に専念させていきたいと考えています。

段階的に移行するという作業はゼロから作り直すより往々にして時間がかかりますが、移行作業で必要な検討事項というものは、ユーザーに負の価値を与えないこと・事業をどう継続させるか考えることに他なりません。こうした実装を通して、プロダクトチームとしてもより事業目線も技術力も高めていきたいと思います。

今後も各プロダクトのフロントエンドを一緒にやってくれる人募集しています!!

【フォースタ テックブログ】AWSのSessionManagerを使ってセキュアなサーバーログインを実現する

リモートワーク中はすぐに眠くなるので困っているSREチームの井原 ( @tossy_yukky ) です。

11月に入り、さすがに寒くなってきたかなと思いきやまた20度を超えてきたりと、過ごしにくい日々が続いてますが皆様いかがお過ごしでしょうか。

さて、今回のテーマは「AWSのSessionManagerを使ってセキュアなサーバーログイン」ということで、登場人物は以下になります。

経緯

これまで、フォースタートアップス(以下フォースタ)のインフラとしては、EC2(サーバー)に対してのSSH接続は基本的に社内から行う、障害対応などで外部から接続する場合には都度セキュリティグループに22番ポートの穴を開けて対応、という形になっていました。

ただ、今回の新型コロナがあり弊社としてもリモートワークが進んできたため、都度22番を開けるというよりは常時開放に近い状態になってしまったので「これはどうにかしないとな」というのがきっかけです。

そんな中、(おそらく)このあたりの記事をなにかの拍子に見つけたことで、コレダ!となり、その勢いで導入した、というお話になります。

要件を決めよう

CTOの戸村( @KenjiTomura ) とも話をして、「よしやろう」ということになったため、実際に要件を詰めていきます。

SessionManagerによってAWSコンソールから接続できるのはPoC時点で確認できていたんですが、このままでは下記のような「今までできていたこと」ができなくなってしまうので、それらは担保する方向にします。

出たのは大きく以下の4つ。

  • ローカルPCからターミナルで接続
  • scp、rsyncなどのover sshでのファイル転送
  • 各自使っているDBクライアントから、SSHトンネリングをしつつDB接続
  • Capistranoでのデプロイ

ローカルPCからターミナルで接続

こちらに関しては言わずもがな。
これができないようではこれ以降の要件も満たせそうにありません。
フォースタではRailsを使ったアプリケーションが多く、まだサーバーにログインしてrailsコマンドを叩くこともあるので、何があっても必須の要件となります。

scp、rsyncなどのover sshでのファイル転送

頻繁にあるものではないですし、TerraformやAnsibleなどを用いてInfrastructure as codeが進んでいる昨今ではそこまで必要ではないと思いますが、何かあった際にはできるに越したことはありません。
sshコマンドが使える状態であれば必然的に利用可能であるというところから、今回この要件そのものに対して何かを行ってはいません。

各自使っているDBクライアントから、SSHトンネリングをしつつDB接続

DBに接続して直接DDLを投げることはさすがにないものの、DML/DCLに関しては投げたいこともあります。
そしてDBはAmazon RDSを利用しており、基本的にPrivateなサブネットに配置しているため、踏み台となるサーバーがないと接続できないようにはなっています。
なので、踏み台サーバーも22番ポートを閉じたとしてもこのSSHトンネリングが可能な状態になっていないといけません。

ざっと周囲に聞いてみたところ、クライアントとしてはSequel ProかJetBrains製IDEが多かったため、それらクライアントでSSHトンネリングしつつDB接続(してクエリを投げられる)を担保する必要がありそうです。

Capistranoでのデプロイ

フォースタのアプリケーションとしては大半がRailsを利用しており、デプロイにはCapistranoを使っています。

デプロイの実行はCircleCIで行っているため、CircleCIで使っているコンテナからのアクセスを許容しなければいけません。

実際の作業

参考にしたのは大体この辺です。

初めてのAWS Session Manager(SSM)
Session Manager を使用した Linux インスタンスへの接続

最初は公式ドキュメントの日本語版から見ていたんですが、あまりの翻訳のひどさに解読を諦めました。。。
2020/10/9時点ではまだ英語版の方が読みやすい気がします。
以前はここまでひどくなかったと思うんですが一体どうしちゃったんでしょうか。

サーバーにSessionManager経由でログインできるようにする

  • EC2にSSM用のポリシーをつけたロールを付与
    • 具体的な手順に関しては上記の参考サイトを見ていただくとして、Qiitaの方の記事では AmazonEC2RoleforSSM となっているポリシーに関しては、設定しようとすると「古いよー、今はこっちだよー」と言われるので新しい方の AmazonSSMManagedInstanceCore というポリシーを選択します。
  • SessionManagerのインスタンス一覧に出てくることを確認
    • 上記ロールを付与してしばらくすると出てくるので気長に待ちます。

ローカルからsshコマンドでログインできるようにする

  • AWS CLIのインストール、ssm-agentプラグインインストール
    • AWS CLIについてはそもそもインストールはしてあったんですが、もしインストールしていない場合は 公式ドキュメント を参考にインストールします。このドキュメントはまだしっかり日本語になってる方ですね。
    • その後、AWS CLIに対してSessionManagerPluginをインストールしておきます。公式ドキュメントの翻訳がだんだんひどくなってきました。
    • この時点で aws ssm start-session ~ コマンドを用いることで、ターミナルからの接続が可能です。
  • .ssh/config整備
    • ただ、後々のことを考えると、今まで同様にsshコマンドで接続できるのが理想なので、その設定をしていきます。
    • 公式ドキュメントにある通り、各自のローカルPCで .ssh/config に以下のように記載します。鍵ファイルやユーザーの指定は適宜行います。
# SSH over Session Manager
host i-* mi-*
ProxyCommand sh -c "aws ssm start-session --target %h --document-name AWS-StartSSHSession --parameters 'portNumber=%p'"
  • こうしておくことで、
$ ssh i-xxxxxxxxxx
  • というコマンドだけでログインできるようになりました。
  • 実際には i-xxxxxxxxxx ではどのホストなのかわからないため、ホスト名をつけた上で --target %h の値をそれぞれ直接書いています。
    • DBクライアントからの接続を確認
  • さて、普通にsshコマンドでログインできるようになったので、このホストを踏み台としてDBクライアントにSSHトンネリングの接続設定を行ってみます。
  • そのままで行けるかと思いきや、ここで問題発生です。
sh: aws: command not found
  • `` awsコマンドがないと言われてしまいました。
  • これはDBクライアントからProxyCommandを実行する際、PATHが読み込まれていないからということなので、ProxyCommandの中を
ProxyCommand sh -c "export PATH=/usr/bin:/usr/local/bin && /usr/local/bin/aws ssm start-session --target %h --document-name AWS-StartSSHSession --parameters 'portNumber=%p'"
  • のようにPATHを無理やり指定してやることで接続できるようになりました。

CircleCIでのCapistrano対応

そして最後はデプロイ周りをやっていきます。

フォースタでは大半のサービスがRailsで構築されており、デプロイには定番のCapistranoを利用しています。

CapistranoSSHで対象ホストにログインしてデプロイを行うので、SSHで使う22番ポートを閉じてしまうとデプロイすることができません。

同時に、デプロイはGithubのmasterリポジトリへのmergeをトリガーにCircleCI上で行っているため、ローカルPCと同様の方法を取ろうとすると対象ホストが増える度に設定ファイルの書き換えが必要になってしまいます。

上記から、デプロイ時にはSessionManagerを利用するのではなく、対象ホストの22番ポートに対してCircleCIのIPを一時的に開放することで対応という形にします。

作業としては この辺り を参考に設定しました。

具体的な内容は上記記事を見ていただくとして、大きく

  • ビルド/デプロイで使用するコンテナにAWS CLIをインストール
  • AWS CLIを使用して対象ホストに紐付いたセキュリティグループを、実行中のCircleCIコンテナのアウトバウンドIPに対して22番ポートを開放するよう変更
  • デプロイ後、上記セキュリティグループを元に戻す

といった形の流れになります。

これで基本的に22番ポートを閉じた状態でもデプロイを行うことができるようになりました。

最後に感想を

SSHというかサーバーへのログインに対するセキュリティというと、今までであれば踏み台サーバーを構築する、VPNを構築する、といったものになると思いますが、(AWS限定ではあるものの)これだけ簡単な作業で22番ポート自体を閉じてしまえるというのは素晴らしい体験だなと思いました。

よく「ロックインされるのが嫌」という話も聞きますが、敢えてロックインされることによって生産性・開発体験が向上するのであれば、そのリスクよりもメリットが上回る典型例ではないかと思います。

【フォースタ テックブログ】フォースタでのフロントエンドエンジニアの働き方

はじめに

テックラボの藤井(@yutafujii)です。

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

今回はいま現在の当社のフロントエンドエンジニアの働く環境についてご紹介できればと思います。

主な技術スタック

当社のフロントエンドエンジニアが関わる技術スタックはざっと以下の通りです。

  • 主な言語:Vue.js (2.6) /Nuxt.js (2.13)
  • その他の言語:TypeScript (3.8),Rails (5.2)
  • Nodeパッケージ管理:yarn
  • CSSフレームワーク:scss
  • BFF:ExpressJS
  • テスト:Jest
  • デザイン:AdobeXD, Figma
  • 環境:Docker
  • インフラ:Terraform,基本的にAWS
  • CI/CD:AWS CodeBuild
  • ソースコードバージョン管理:GitHub
  • タスク管理:Zenhub
  • ドキュメント管理:Notion
  • コミュニケーション:Slack

フロントエンドのフレームワークは最も業務の中で触れることの多い言語になると思いますが、当社ではVueを選択しています。技術選定の背景などは後述しますが、比較的最近ソースコードに取り入れたこともあり、VueはTypeScriptで記述しておりStorybookやComposition APIを利用するなどトレンドの変化を追えるように常に技術に関心を持って取り組んでいます。またフロントエンドエンジニアの方もたまにサーバサイドのRailsを書くこともあります。

Vueを選定した背景

React/Vue/Angularの3大フレームワーク・ライブラリのなかでVueを選定している理由は主に2点で、

1.当社では他にもVueを用いたシステムが既に存在しており,今回も統一しておくことでVueを書く人を柔軟に配置できる

2.サーバーサイドエンジニアが多く,学習コストを抑えたい

というものです。

本格的にVue/Nuxtを用い始めた当時のチームとプロダクトの状況も

  • フロントエンドエンジニアが1名(着任したばかり)
  • サーバーサイドエンジニアが5名
  • デザイナーが初めてチームにアサインされてからまだ3ヶ月目

というもので、学習コストに関する利点は特に選定理由になっていたようです。

働き方

実装の概要

当社のエンジニア組織はまだ大きくなく、フロントエンドエンジニアもRailsAPIを書いたりデータベース設計のマイグレーションを作成するなど、幅広い作業に触れていただいています。もちろん、実際の業務におけるバランスは、チームの状況やメンバーの意向を元に個別柔軟に考える方針となっております。

なお、この点についてはサーバーサイドエンジニアも同様で、TypeScriptでモブプログラミングを行ったりフロントエンドのチケットを受け持っていたり、デザインシステムを利用してモックを作るなどの作業も行っています。

全員が幅広くコードベースを触っているということを表す取り組みとして、GitHubでのPR(Pull Request)レビューはフロントエンドの実装かサーバーサイドの実装かに関わらずまずはランダムにアサインされるようにしています。全員のナレッジをいかに早くシェアし、書き方や思考を揃えることでチーム全体として柔軟に開発できるようになることを狙いとしています。

他にも、プランニングポーカー(工数の見積もり)は全員が全チケットに対して行うので、フロントエンドエンジニアはRailsの実装チケットに関する方針や工数感の議論にも参加しています。

実装案の選定過程

UX/UIデザイナーからは、XDやFigmaなどのデザインツールで作成されたモックをassetsがダウンロード可能な状態でシェアされて実装することが多いものの、アニメーションについては工数感をフロントエンドエンジニアが、理想形をデザイナーがそれぞれ中心となって話していただき、その情報を元に全メンバーで議論して実装案を決めていきます。

実装における技術選定は、CTOとSREチームを巻き込んで行っています。プロダクトの要件やサービス全体の技術面での課題などから新しい技術の採否を検討するにあたり、業務時間の中で技術選定のための時間を一定取って担当メンバーが調査を行い、選定技術の提案を行います。プロダクトチーム・CTO・SREチームで議論を行い決定していきます。

開発フローの改善

ここまでご紹介したのは今現在の当社のフロントエンドエンジニアの働き方の実態ですが、開発フローそのものを改善する振り返りをスプリント最終日に行い、様々な問題やトライをみんなで話し合っています。過去には「今回のスプリントではサーバーサイドのPRレビュー依頼が多くたまってしまい自分のチケットの消化スピードが遅くなっている」という意見が出て毎朝各人どの程度レビューを行う余裕があるかを共有したときもあります。

おわりに

今回はいま現在の当社のフロントエンドエンジニアの働く環境についてご紹介させていただきました。

実際に仕事をする様子がイメージできるブログとなっていたら幸いですが,今後も組織の規模や技術的なチャレンジに合わせて,働く環境や働き方は変化させていきたいと思っています。

プロダクトとしては,これまでサーバーサイドエンジニアを中心に情報設計やデータ化に重きを置いて取り組んできた中で,今後はフロントエンドでの進化を遂げたいというのが各プロダクトの一つの方向感です!そのためにも一緒に事業を成長させてくれるフロントエンドエンジニアを募集しています!!