【フォースタ テックブログ】検索におけるユーザーのニーズに合わせてElasticsearchをチューニングした話

こんにちは、主にサーバーサイドを担当している速水です。

社内向けプロダクト「タレントエージェンシー支援システム（SFA/CRM）」では、検索エンジンとしてElasticsearchを採用しており、最近、検索機能の大きな改善を行いました。今回はそれに伴って、Elasticsearchに関するTIPSを紹介していきたいと思います。

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

tech.forstartups.com

タレントエージェンシー支援システム（SFA/CRM）は、RailsがAPIサーバーとして機能し、Vueでフロントを構成する設計となっています。一部、erbで記述された部分もありますが、直近手を入れている機能については、APIを介してフロント分離をしっかり行っております。この記事では、RailsのAPI開発におけるElasticsearchに関する部分を紹介します。

データ型の見直し（Text型→Keyword型）

Elasticsearchで文字列を扱う場合、Text型またはKeyword型、どちらかを使用すると思います。Text型とKeyword型の違いは、データを格納する際に、Analyzerによって単語に分割され、分割された単語ごとにインデックスが構成されるかどうかですが、これまで使用していたText型では、分割によって検索結果が曖昧になりすぎ、困るシーンがありました。例えば、「Rubyエンジニア」を検索した際に、「Ruby」と「エンジニア」に分解されてしまうことで、Ruby以外のエンジニアもヒットしてしまう、といった状況です。

そういった分割をせずに格納、検索するために、データ型をText型からKeyword型に変更し、検索ワードが"完全一致"したらヒットするようにしました。

indexes :all_resume_contents, type: 'text', analyzer: 'kuromoji_analyzer'

indexes :all_resume_contents, type: 'keyword'

検索結果でのハイライトの実現

検索結果でヒットした箇所のハイライトを行うため、options[:set_highlight]を指定することで、highlightが返却されるようにしました。

filters = @search_definition[:query][:bool][:filter]
...
...(filters.pushやset_sort_query)
...
set_highlight if options[:set_highlight]
__elasticsearch__.search(@search_definition)


def set_highlight
  @search_definition[:highlight] = {
    fields: {
      "**": {}
    }
  }
end

Elasticsearchのhighlightは、wildcardを利用すると全文が返ってくるため、ハイライトを中心に前後40文字と...(省略記号)の形式に、APIを生成する際に加工しました。

copy_toによる検索対象フィールドの集約と返却フィールド

Elasticsearchではcopy_toという機能で、検索対象フィールドをまとめることができます。検索対象のフィールドを少なくすることで、検索スピード向上が期待できます。
もともとresumeというインデックスは、Nested datatypeを使っていました。all_resume_contents単体で検索するより、file_idやnameなどをまとめて検索した方が効率が良いため、copy_toでall_resume_contentsを指定します。

ただ、開発を進めていたところ、all_resume_contentsでヒットした際に、そのフィールドが返却されないことに気付きました。調べていくと、copy_toはあくまでindexed documentであり、source documentではないようです。検索にヒットした際のフィールドや値を使用したい場合は、storeオプションをつける必要がありました。

indexes :all_resume_contents, type: 'keyword', store: true
indexes :resume, type: 'nested' do
  indexes :id, type: 'integer'
  indexes :file_id, type: 'keyword'
  indexes :name, type: 'keyword'
  indexes :content, type: 'keyword', copy_to: 'all_resume_contents', index: false

case-insensitiveの対応

大文字と小文字を区別しないことを、ケース・インセンシティブ（case-insensitive）と言います。今回、データ型の見直しを行ったことで、Rubyとrubyや、HTMLとhtmlの検索結果が異なる、ということが発生してしまいました。Text型の時はAnalyzerで吸収されていた部分ですが、Keyword型に変更したことで発生しました。Keyword型ではAnalyzerが使えないので、代わりにNormalizerを使用します。

www.elastic.co

Normalizerには、char_filterとfilterを定義することができ、今回は大文字と小文字を区別しないようにするため、filterでlowercasesを指定しました。Normalizerはインデックス、検索時の入力、どちらにも適用されます。

indexes :memo, type: 'keyword', normalizer: 'lowercase_normalizer'

analyzer: {
            kuromoji_analyzer: {
              type: 'custom',
              tokenizer: 'kuromoji_tokenizer',
              filter: %w[kuromoji_baseform pos_filter greek_lowercase_filter cjk_width]
            },
            ngram_analyzer: {
              tokenizer: 'ngram_tokenizer'
            }
          },
          normalizer: {
            lowercase_normalizer: {
              type: 'custom',
              char_filter: [],
              filter: ['lowercase']
            }
          }

いかがでしたでしょうか。シーンはかなり限られるかもしれませんが(笑)、Elasticsearchを使った検索機能の開発をするときの参考になればと思います。

今回の検索機能の改善は、フロント、バックエンドそれぞれ細かくタスクを分解し、チームが一丸となって取り組んだものでした。いざ結合して検索してみると、想定と異なる結果が表示されることもありましたが、上記のような解決法を取りながら、1つ1つ対応して完成した機能は、まさにチームでつくりあげたと言えます。

フォースタートアップスではエンジニアを募集中です。チームで協働するスタイルが向いている方は、是非ご応募ください！

【フォースタ テックブログ】社内で実践中！ふりかえりを続けるためのコツ

どうもむらばやし（@bayashimura）です。皆さん「ふりかえり」してますか？ふりかえり挫折しますよね？今回は挫折しがちなふりかえりを続けるためのコツを書いていきます。

この記事は技術書典10で発売された『forstartups tech book 1』のふりかえり再入門から抜粋、一部加筆しております

techbookfest.org

まだみんな前のめりじゃない時にファシリテータを交代制にしない

ファシリテータを一人がやり続けることは、大抵の場合アンチパターンとして捉えられがちです。私もふりかえりのファシリテータがずっと固定されていることには否定的です。しかし物事を新しく始める時に誰か一人、それも情熱を持っている人が引っ張っていくのは大事なことです。

早期にファシリテータを交代制にすることは、ふりかえりにモチベーションもオーナーシップもない人間がファシリテータをやらされることに繋がります。その結果ふりかえりのクオリティは下がったり、もしかしたら開催されないかもしれません。

ふりかえりをこれから始める方、途絶してしまっていたけど再びやろうとしている方はまずあなたが続けるところから始めましょう。あなたが会議を設定し、あなたがチームメンバーを呼び寄せ、あなたがファシリテーションして、あなたがメンバーからのフィードバックをもらいましょう。そういった日々を積み重ね、チームがふりかえりに前のめりになってきた時に初めてファシリテータを譲りましょう。それまではファシリテータを交代制にするのはおすすめしません。

一定のリズムで行う

先に時間を押さえましょう。もしスクラム開発をしているのであれば、スプリントの最後の時間などがいいかもしれません。そうではない方々も、１週間に１回や２週間に１回などの固定の時間を取りましょう。すぐ埋まる会議室を押さえ多忙なチームメンバーのスケジュールを押さえるのにこれだけ簡単な方法はありません。

誰かが思いついた時や開発の節目など固定でないタイミングで行うことは、ふりかえりを開催するハードルを上げます。開催の日時に融通が聞かせられてしまうため、全員が参加できるタイミングをファシリテータが調整する羽目になり労力がかかります。ファシリテータがスケジュールを調整するのではなく、参加者がスケジュールを調整する方向に仕向けることで負荷が分散し継続して開催される可能性が高くなります。

色々なふりかえり手法を試してみる

ふりかえりの種類はたくさんあります。またその性質もそれぞれ違います。チームをポジティブにするふりかえり。チームの問題を発見するふりかえり。チームの目線を合わせるふりかえり。色々なふりかえりを試すことで、チームはふりかえりの多様性を実感します。そうなると次のふりかえりを試したくなり、チームはふりかえりに前のめりになります。そのうちチームメンバーが新しいふりかえり手法を提案してくるかもしれません。もうふりかえりはチームに浸透しましたね。

厳しさより楽しさを重視する

ふりかえりは、その性質上、チームに発生した目を向けたくないような事実に目を向けます。そのため反省会や責任の押し付け合いみたいになりがちで、ふりかえりが嫌な行事に思えてきます。
またふりかえりは「チームの悪いところを直す」という方向に向きがちですが、過度な解決思考は良く言えばチームの規律を正しますが、悪く言えば息苦しく高圧的な雰囲気を生みます。

ふりかえりでチームのマインドをポジティブな方向に仕向けましょう。「このチームの凄いところはどこですか？ 」「このスプリントのヒーローは？」 褒められて嫌な人はいません。気恥ずかしいし、自己啓発臭くて嫌かもしれませんが一度やってみましょう。

ネガティブなフィードバックの倍のポジティブなフィードバックを言いましょう。面白いジョークを言いましょう（面白くないのはダメです）。ダメダメな自分たちがちょっとでもマシになるためのアイディアではなくグレートな自分たちが更にグレートになるためには何をしたらいいかを考えましょう。そうすることでチームはポジティブになり、ふりかえりの場が盛り上がります。もうふりかえりを楽しみに一週間を過ごすチームの出来上がりです。

ふりかえりをふりかえる

ふりかえりをしていると白熱して時間を使い切ってしまいがちですが、最後に5分くらい残しておきましょう。そこでふりかえり自体をふりかえることをおすすめします。

何故『ふりかえりをふりかえる』ことで『ふりかえりが継続できる』かというと、ふりかえりを推進している人は孤独で不安です。まだチームにふりかえりが定着していない時などは尚更です。みんなの貴重な時間を使ってふりかえりが盛り上がらない時、次のふりかえりを設定することはみんな の邪魔になるんじゃないかという思いがよぎります。

そんなときは何が必要でしょうか。フィードバックです。参加者は顔に表しませんが、とても有意義だったと思っているかもしれません。ふりかえりのふりかえりで参加者がどう思っていたかを 引き出します。フィードバックを貰えれば後に繋げるのは簡単です。良いフィードバックを貰えれ ば続ければいいし、良くないフィードバックが集まればやり方を変えましょう。どう変えればいいかもフィードバックの内容に含まれているはずです。

ふりかえりが毎回盛り上がりすぎて時間がない場合（タイムマネジメント頑張って！）は、会議室の出口に楽しさと 役立ち度合いの2軸のグラフを作りそこに一言とともに付箋紙を貼ってもらう方法があります。また会議が終わったあとに、slack でコメントを求めてもいいでしょう。どんな方法でも良いです。 フィードバックをもらいましょう。それがふりかえりをすすめる人の活力になります。

早いうちにふりかえりの効果をチームに実感してもらう

チームを巻き込む以上、そしてチームが合理的な時間の使い方を求める以上、あまり効果が感じられない会議体は自然となくなっていきます。つまり、ふりかえりを継続する上で大事なことは「チームのみんなにふりかえりの効果を実感してもらう」ことになります。早いうちにふりかえりの効果をチームに実感してもらいましょう。

もしあなたがふりかえりのファシリテートに自信がない場合は、時間をとってしっかりと準備をしましょう。もしくは近くにふりかえりのファシリテートに長けている人がいれば最初のうちはその人にお願いしましょう。これは身も蓋もない言い方になってしまいますが、ふりかえりの価値を知らないチームメイトはあなたの成長を待ってはくれません。最初のうちは持続的なやり方でなくても良いので、まず価値を感じてもらい、そこからチームメイトと一緒に歩んでいくのがオススメです。

今回はふりかえりを続けるコツについて書きました。
先月発売した技術書典の同人誌の方ではふりかえりの型などに関しても書いているため、ご興味があれば是非読んでみてください！

また、フォースタートアップスではエンジニアを募集中です！
ふりかえりをして成長していくチームで働きたい方は是非ご応募ください！

【フォースタ テックブログ】Regional Scrum Gathering℠ Tokyo 2021で配信スタッフとして参加してきました

Copyright 2020, ScrumTokyo. All rights reserved

どうも村林です。
Regional Scrum Gathering Tokyo 2021（以下、RSGT）に配信担当としてスタッフをしてきたので感想書きます。

Regional Scrum Gathering Tokyo 2021とは

Regional Scrum Gathering℠ Tokyo 2021は、東京で行われるRegional Gatheringとして10回目になります。運営母体である一般社団法人スクラムギャザリング東京実行委員会は、スクラムを実践する人が集い垣根を超えて語り合う場を提供するという目的によりコミットしています。

アジャイル初学者からその道の達人までいろんな人達が集まってギャザリングするイベントです。
今年は新型コロナウィルスの影響もあり、オンラインの人もオンサイトの人もギャザリングできるようハイブリッド開催でした。

ハイブリッド開催とは話す人も聞く人も会場かオンラインかを好きに選べるってことです。また会場の人はオンサイトの人の発表しか聞けないなどの制約もなく、会場でオンラインの人の発表を聞く、オンラインの人が会場の発表を聞く、なんなら一緒にOST（Open Space Technology）とかしちゃう。みたいな感じでした。

この要件を満たすために、会場とオンラインの人を双方向に繋ぐということが必要でした。そこらへんをどうにかするべく色々やったのが配信担当です。私は品川アジャイルという品川にまつわる人やまつわらない人が日夜集まってアジャイルの話をするコミュニティに属しているご縁で担当しました。

配信構成

全体像はこちらです

多分これだとなんのこっちゃという話だと思うのでユースケース毎に解説していきます。

まず会場にいる人の発表をオンラインで聞くケースを考えます。

会場のマイク音声はもちろん会場に流さないといけないので、会場の音響設備につなぎます。そして会場の音響設備から分配し、配信用PCに入れます。配信用PCはZoomに接続していて、受け取った音声をZoom側に流します。
これで音声は良さそうです。

次は映像ですが、映像に関しては発表資料と講演者の姿の２つの画面があります。
発表資料は講演者が会場のプロジェクタに接続し、またその画面をZoomで画面共有してもらうことで会場にもZoomにも発表資料を共有することができます。
講演者の姿に関してはカメラで撮影したものを配信用PCに入れ、そこからZoomに出力します。
これでZoomでも講演者の発表スライド、発表姿、音声が全部Zoomに届きますね。
PinP（映像の中に映像をはめ込む）なども考えたのですが、RSGTの参加者のペルソナを考えたときにこちらで映像を組み合わせた状態で渡すより、そのまま渡して参加者の方で勝手に組み合わせられるようにした方が満足度が高いかなということでやめました。幸いZoomは複数の映像のレイアウトを柔軟に変えられますし。Zoom凄い。

次に会場の発表に対してオンラインの人が質問してくるケースを考えます。

講演者が聞くためにZoomからの音声を会場に流す必要があります。
これは配信用PCが受けたZoomの音声を会場の音響設備に流すことで対応できます。

次はオンラインの発表を会場に流すケースです。

基本はオンラインの人が質問してくるケースと同じです。
ただし一点違うのは講演者が会場にいないので、会場のプロジェクターに接続するPCがありません。
これは運営で借りたPCを投影用PCとして置くことで対応しました。
この投影用PCでZoomに接続し、会場のプロジェクタに流すだけで映像はOKです。

最後にオンラインの発表に対して会場の人が質問をするケースです。

これも会場の発表と同じですね。
会場のマイクを使って質問してもらうと、配信用PCを通ってZoomの先にいる発表者の人に伝わります。注意なのが、マイクの音声しか拾っていないのでマイクに向かって話さないと聞こえないことです。

素人でも積み重ねてできた

いかがでしたでしょうか。よくわかりませんね。

実は我々は映像や音声に関して素人だったのですが、ちょっとずつできることを積み重ねていき、こんな最初はよくわからない構成でもある程度できるようになりました。
最初から色んなことをやろうとしない、基本が安定してできるようになると次のステップアップもそんな負荷なくいける。そのステップアップも当たり前にやりだすと、次のステップアップをする。こんな感じでできることを積み上げてできたのが今の構成です。
なので詳しくなってきたらもうちょっと複雑か高度な構成になるかもです。それかよりシンプルになるかも。未来は誰にもわからない。

あと初期案はRSGT実行委員長で品川アジャイルのメンバーでもある川口恭伸さんが考えてくださったのですが、川口さんがこの構成を考えたときに留意した点は以下の通りだそうです。

1. 登壇者にとって最小変更
2. その変更点も慣れているZoom対応のみ
3. 映像系は登壇者、音声系は会場設備（ハウリング対策）
4. どのPCがこけても全落ちしない（ある程度は相互にリカバーできる）
5. ネットがこけても平然と会場は進行できる（ハイブリッドなのだけど、実績ある部分を優先）
6. リモート参加者/講演者に追加のオペレーションを求めない（説明しきれない）
7. 会場に複雑な機材を入れない（PC中心）
8. 運用者はみんなプロじゃなくて参加者に近いコミュニティメンバーなので、習熟の時間をとる（お金を人件費より教育研修費で使いたい）
9. ホールは別に業者さんにお願いすることでリスクヘッジ （ただこの構成は踏襲していただくことでコストは下げる）

大規模なイベントを継続してやってきた川口さんのノウハウが詰まってますね。
新しく発生するリスクに対してはできるだけ冗長化する。
慣れているものでやるのが一番安定してできる、という思想があるような気がします。

得た学び

留意した点の8番に関しては私は恩恵に与かりました。
何をしたかと言うとわざわざ本番の二週間前くらいにカメラを機材レンタル屋さんから借り、その他機材も家に持ち帰り、年末年始にお家で配信設備の構成を試して遊んでました。
そこでようやくぼんやりしていた配信構成が解像度高く自分の中に入りました。
「こうすれば動くらしい」から「これはこういう仕組みだから動く」って感じですね。
仕組みがわかったことで当日昼休みのときに会場に何も流れてなかったのが寂しくてDiscordの映像を会場に流したり、機材トラブルがあった際に土壇場で違う構成で乗り切ったりすることができました。
基本をしっかりするから応用ができるという学びです。

またスタッフ内で印象的だったのが「疲れない、頑張らない」を大事にしていたことでした。大体のイベントでは「燃えつきろ！一生懸命だろ！！」って方向に行きがちなんですがイベントスタッフって頑張っちゃうんですよね。勝手に。
だってみんなに楽しんでもらいたいし、やりがいもあるし。スタッフが追加で動かなきゃいけないときって大体誰かが困っているときだし。
で、頑張ると燃え尽きて、来年からはちょっと出来ないなぁとスタッフがどんどん離脱してイベントの持続可能性が減ってしまう。
営利団体でもないことも相まっていつでも辞められるから、辞めないように工夫する。
スタッフが楽しくて疲れないのが第一。そうすると来年も開かれる。

という思想があるのかなーと思いました。
コミュニティを持続的にしていきたい人は参考になるかもです。

おわりに

ということで、配信スタッフとしてRSGTに参加してきた話でした。

最後に実行委員、スタッフ、発表者、参加者の皆さんお疲れさまでした！
また来年お会いしましょう！

あ、あとフォースタートアップスではRSGTと聞いてピンとくるアジャイルに興味のあるエンジニアを募集中です。
プロダクトに向き合ってより良くあろうとするチームで働きたい場合は是非ご連絡ください！

【フォースタ テックブログ】フォースタートアップスで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社ものデータがあり、日々データを取り扱っていく中で知らなかった企業を知れる機会にもなると思います。

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

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