for Startups Tech blog

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

【フォースタ テックブログ】フォースタートアップスでWebエンジニアインターンで働くということ

フォースタートアップス（以下、フォースタ）ではクリエイティブ職の長期インターンシップの受け入れを実施しています。

インターンシップというと、短期集中のカリキュラムで就労体験を行うパターンもありますが、弊社では実務に則した開発業務を中長期で行っていただいています。もちろんですが就労分の報酬をお支払いしており、これまでWebエンジニアとデザイナーのインターンを採用しています。

今回、Webエンジニアのインターンとして働く2名にインタビューを行い、インターンをすることになった経緯や自己成長に繋がっていること、未来のインターン生へのメッセージなどリアルな声を聞いてみましたので紹介します。

どのような経緯でインターンをすることになったのか

自己紹介とこれまでの経歴、フォースタでインターンをすることになった経緯などを教えてください。

菊山：インターンをしている菊山と申します。
簡単に自己紹介をしますと、インターンというと学生のイメージがあるかと思うのですが私は社会人経験があり、入社した時は24歳でした。
関西の大学を卒業後、新卒で地元の銀行に就職しています。そして、退職後に一定の期間プログラミングの勉強をした後にフォースタのエンジニアインターンという経歴です。

なぜエンジニアに転職したのかというと、単純にプログラムを書いている時が楽しいのと、学ぶことで作りたいと思えるものを形にしていけるということにテンションが上がるからです。
自分でWebサイトを作ってみたいと思ったことが最初のきっかけで、Webサイト作成の勉強のためのツール、YouTubeで簡単なサービスを作っている動画を真似て作ったりしていくうちに、ハマっていきました。

フォースタのことは、転職活動をしている時に初めて知りました。調べてるうちに事業や会社のビジョンに興味が湧き、応募したところ実務経験がないということでインターンからでもどうか、という提案をいただき採用となりました。

原島：大学3年の原島です。大学では経済学を勉強しています。ゲストハウスでアルバイトをしていた時に「ホームページ作れるけど勉強してみない？」と社員の方から誘われた事がきっかけでプログラミングを始めました。勉強し始めると想像以上に楽しくて次第にプログラミングに没頭するようになり、エンジニアを目指すようになりました。

学生スタートアップでエンジニアとして働いていた経験もありスタートアップが大好きです。Wantedlyでフォースタの募集を見た時に直感で「ここで働きたい！」と思いました。募集は正規雇用の採用だったのですが、ダメもとで「インターンとして働きたい」と伝えたところ、CTOの戸村さんのご厚意もありインターンとして採用して頂きました。

現在の業務内容とインターンを通して学んだこと・スキル・自己の成長に繋がったこと

Webエンジニアインターンとして携わっている業務内容を教えてください。これまでに、または現在進行中でスキル面や自己成長に繋がったことがあれば聞かせてください。

菊山：STARTUP DBの管理システムの開発、保守をメインに行なっています。社内ユーザーからの改善案の一次受けをしたり、緊急度にもよりますが、エラー対応は基本的にインターン内で行なっています。インターンであっても、プロダクトの改善案などをGitHubでIssueをあげることで開発MTGで検討され、採用されることもあります。

エンジニアとして働いて9ヶ月ほどですが、技術面だけではなくそれ以外でも様々な学びがありました。

技術面では、単純に知識量だったり実装方法の考え方であったり、理解しやすいコードを書くことの重要性などです。特に、理解しやすいコードを書く技術はチーム開発、品質を維持していく上でも大切なことなので日々意識しながらコードを書いています。

STARTUP DBはマイクロサービス化されており、役割毎に分離された構成での開発は学べることが多いです。
マイクロサービス構成での開発はフロントエンドとバックエンドを別で管理しているので、各サービスの修正をする際に他のシステムへの影響を考えなくて良いということがメリットとしてあります。これによりバックエンドとフロントエンドの役割が明確になっているので、それぞれが集中して開発でき、開発速度の向上に繋がっています。また修正や原因調査が行いやすいなど開発効率の向上も実感できています。

頭ではわかっていても、実際に開発を進めているとその恩恵を感じることができ、理解が深まりました。

また週に1度、勉強会とスキルアップという時間があり、知識の共有であったり各自の技術的なスキルアップの時間が設けられています。自分の知らない技術の紹介であったり、社員の方とモブプロを行って問題を解いたりと、先輩方からの知識やコードを書いている時の考え方など学びになることばかりです。

それ以外にも、会社の成長を体験できました。私が入社した時と比べて、毎月様々な経歴をもつ方々が入社されました。組織の変化を身を持って実感できることは貴重な経験だと思っています。

入社初期と比べると自身の成長を実感することができていますが、最初の2〜3ヶ月はわからないことだらけで大変でした。

Ruby on Railsにも全く触れたことがない状態だったので、ソースコードを理解するのも大変でしたし、DBのテーブルが相当数あるのでデータ構造を理解するのも大変でした。（今でも全部は理解できていません）

ですが、メンターでついてくださっている社員の方々にはコードレビューをしていただいたり、質問があれば一緒に考えていただいたり、助けていただいたおかげで徐々に理解が進み自信がついていきました。また、先輩方の仕事に対しての姿勢、熱量は自分へに刺激になっていると同時に学ばせていただいています。

いつもサポートしていただいている先輩方には本当に感謝しています。

原島：主にSTARTUP DBの根幹である管理画面をRuby on Railsで開発しています。
大量のスタートアップの情報が毎日のように更新されるので、エンジニアにはスピーディかつ正確な開発が求められます。
アジャイル開発の中で運営とも連携を取りながら進めていく事になるので、総合的なチーム開発の能力が身につきました。
また個人としても、メンターの方に毎週の振り返りをしてもらっているので常に自分の目標と課題を明確にする事ができています。

以前働いていた学生スタートアップと比べて感じた違いは、様々な分野から経験豊富なエンジニアが集まっているので、技術書からは得られない知見が溜まっていく事です。

更に、インプット/アウトプットの量が圧倒的に多くなります。普段の会話からも技術的なインプットがあり、意図せずとも知らない技術に触れる回数が増えました。
エンジニアチームでは毎週勉強会と技術書の輪読会があります。発表者の皆さんは勉強会の内容を技術ブログに投稿しているので、自分も刺激されて日々の学びを投稿するようになりました。
自分もジョインして1ヶ月経ったあたりで「初めてハッカソンに参加してみた話」という題材で勉強会に登壇する事ができました。新人がアウトプットする場が整っている環境はフォースタならではだと思いました。

未来のインターン生に向けたメッセージ

最後に、フォースタでインターンをすることについてメリットに感じている部分や体験価値について教えてください。また今後一緒に働くことになるかも知れない未来のインターン生に向けたメッセージを頂けますか？

菊山：フォースタでは、週1回程度でスタートアップの勉強会をしていただく機会があり、スタートアップに興味がある人、将来的に起業を考えている人にとって学べることが多いはずです。またSTARTUP DBでは約13,000社ものデータがあり、日々データを取り扱っていく中で知らなかった企業を知れる機会にもなると思います。

技術力をつけたい、またスタートアップに興味がある人にとって、最高の職場環境です。
まだまだ自分が発見できていない魅力はあると思いますが、少しでもフォースタのインターンに興味を持っていただいた方は、是非お待ちしております！

原島：フォースタには多様なバックグラウンドを持ったメンバーがいるので、皆さんの今後のキャリア形成の参考になると思います。
「スタートアップが好きだ」「日本のスタートアップの成長をテクノロジーで加速させたい」と思う学生にとっては最高の環境だと思います！
フォースタのビジョンへ共感できるエンジニアの方をお待ちしております！

【フォースタ テックブログ】事業成長を目指して社内向けシステムのデータ分析基盤を整える話

 

こんにちは、2020年10月よりfor Startups, Inc.のテックラボにジョインした速水です。社内向けのプロダクト「タレントエージェンシー支援システム（SFA/CRM）」のサーバーサイドエンジニアとして働いています。

今回は、上記プロダクトでGoogle Tag ManagerやGoogle Analyticsを導入し、データドリブンな施策を進めるための基盤を整えている話をさせていただきます。

タレントエージェンシー支援システム（SFA/CRM）とは

タレントエージェンシー支援システム（SFA/CRM）は、主に社内のヒューマンキャピタリストが利用するもので、顧客管理や業務プロセス管理のような役割を果たしています。顧客管理という特性上、安易に外部のサービスとデータを連携することができず、分析ツールの導入や可視化、分析があまり進んでいませんでした。RedashやKibanaを使った可視化が行われているデータもありますが、プロダクトの利用状況の把握という観点で、もう少し機動性を高めたいと考えました。

tech.forstartups.com

tech.forstartups.com

土台としてGoogle Tag Managerを導入

RailsやNuxtによるアプリケーションのため、Google Analyticsを直接導入することもできますが、連携するデータの加工や、機能自体の開発と計測の分離による機動性向上をふまえ、土台としてGoogle Tag Managerを導入し、その上でGoogle Analyticsと連携する方法を取りました。Railsでは、全ページ共通のテンプレートに、環境ごとに発行したコード(コンテナスニペット)を、環境変数に応じて挿入する形で導入しました。Nuxtでは、nuxt-community/gtm-moduleを使用しました。

いざ利用状況を見てみると、思わぬところがよく使われていたり、逆に要望はあったが実際にはあまり使われていない機能などが、数字として明確に見えるようになりました。また、数字が見えるようになったことで、「ここを細分化して見てみよう！」であったり、「ここのイベントは括って取得した方がより実態がわかりそう」といった議論も活発になりました。新機能の設計をする際も、現状ある周辺の機能がどれくらい使われているのか、実数が把握できると、達成すべきUXを定める参考になります。

連携するデータには注意が必要ですが、データの加工はもちろん、計測の出し入れをプロダクトの機能リリースとは別に行えることで、必要な時に必要なデータがある状態に近づきつつあります。

施策の実現スピードが上がるという副次的な効果も

転職候補者様に向けて提供している候補者様専用ページの中で、NPS®（ネットプロモータースコア）を取得しようというアイデアが出た際に、工数をかけずに最速で実現するにはどうしたら良いか、議論になりました。結果、Google Tag Manager経由で連携することができるHotjarというSaaSを採用し、当初の想定よりもかなり早いタイミングでリリースすることができました。Staging環境でのモックアップの共有も簡単に行うことができ、チームメンバー間のイメージの擦り合わせが早く進み、施策の実現スピード向上につながりました。

指標の設計やデータ取得、可視化、分析はあくまでプロセスで、どれだけ事業の提供価値につなげることができるかが重要ですが、どのフェーズにおいてもスピード感をもって取り組むことは、成果につながるスピードに直結すると考えています。

弊社ヒューマンキャピタリストとの面談後、転職候補者様からフィードバックをいただくことで、面談はもちろん、全体を通して体験の向上に役立てています。（画面はサンプルです。）

さらなるデータドリブンに向けて

フォースタートアップスでは、データドリブンをより加速していきたいと考えています。まだデータ量が少ないところや、取得していても活用し切れていないデータもありますが、一つ一つ課題をクリアして、その基盤を築いていくのは、非常に面白い仕事でもあります。

システムの利用者でもあるヒューマンキャピタリストも増えており、拡大していく組織でビジョンに共感しつつ、データドリブンによる事業提供価値の最大化に熱い思いを持っている人未来の仲間を募集中です！

【フォースタ テックブログ】ノーコードで業務効率化、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 API（https://composition-api.vuejs.org）はTypeScriptとの親和性が高いため、このタイミングで導入してみることにしました。

振り返り

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

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

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

おわりに

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

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

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

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