Leveragesで働くってどんな感じ?内定者インターンをした感想を綴る。

はじめに

こんにちは。 25卒でLeveragesに新卒エンジニアとして入社予定の、いつきと申します。

エンジニアとして内定をいただいたものの、元々はマーケ職志望で、プログラミング経験は皆無です。 そのため、今は内定者インターンで、同期に先んじてエンジニアのイロハを叩き込まれているところです。

この記事は、そんな私から、今Leveragesを候補に入れて就活を頑張っている方に向けて送る記事になっています。

こんな方は読んでほしい

  • Leveragesを候補に入れて就活中の方
  • 今までエンジニア職という選択肢を考えたことがない方

何を考えて就活していたのか
マーケ職希望なのになぜエンジニアになったのか
Leveragesって、実際どうなのか
未経験でエンジニアはやっていけそうか

などなど。
参考になるところもあれば、まったく参考にならないところもあると思いますが、 就活を頑張っているあなたのお役に立てれば幸いです。

軽く自己紹介

現在、大学4年生です。
化学に魅せられて理系へ ⇨ まわりが強すぎて研究者は断念 ⇨
就職を考え経済学部へ ⇨ モラトリアムを延長するため休学 ⇨ 休学 ⇨ 休学 ⇨ 休学
という経歴をしてます。

休学中は、フリーランスの動画編集者をやりながら2週間ごとに住む場所を変えて全国を巡ったり。 オンラインの動画編集スクールで教鞭を取ったり。 ゲームの社会人サークルを立ち上げて、週1で1年間ほどオフラインの大会を開いたり。

そんなこんなで1年ほど前に、そろそろ落ち着くかということで就活を始めた人間です。

就活、何考えてた?(前編)

さて、就活をする!となると、まず考えることは「どこを目指すか」ですよね。 今悩んでる方も多いのではないでしょうか?

私が就活で会社を選んだ大きな軸は2つです。
・領域が多岐にわたる事業会社であるか
・できることなら若手のうちから裁量権が欲しい

よくある話ですね。
4年間のモラトリアムを経てなお、この分野!というものが決めきれなかった私からすると、色々な領域への挑戦が奨励される会社の方が、魅力的に映りました。
そして、せっかくなら自分がやろうと思ったことは、積極的にやらせてもらえる会社がいいと思ったのです。
この時点では、いわゆるベンチャー企業を広く見ていました。

就活、何考えてた?(後編)

その上で、ベンチャー企業をさらに絞り込むときに見たのは
・規模による自由
・会社自体の自由
の2つです。

まずは規模について。
例えば、従業員10名前後のスタートアップは入社すればなんでもやれるでしょう。
しかしそれは、「やりたい!挑戦したい!」と思ったことをやるというより、「(ヒトやカネが足りないから)やらざるを得ない」という文脈が強いと思ったのです。
裁量権はあっても、使えるリソースが少ないのであれば、やりたいと思ったことに挑戦はしにくいのかもしれない。
であれば、規模はある程度大きい方が良いはず。そういった観点から、ベンチャーの中でもメガベンチャーに焦点が定まりました。

しかし、規模が大きくなると次の問題があります。
それが会社自体の自由、つまり権利者による制約です。上場企業となると、会社の意思決定は社内だけではできません。社外の株主が、意思決定に絡むことになります。
こうなると、「やりたい!挑戦したい!」と思ったことについて、「社内」では積極的に後押しする文化があったとしても、「会社の外の人」によってNGが出る可能性があります。
前述の規模による自由の方が大事ですが、やりたいことに挑戦するためにはできれば未上場の方がいいのです。

規模は大きくて、上場はしていないメガベンチャーの事業会社。
この検索条件で残ったのはLeveragesだけでした。

そんなわけでLeveragesメインで就活を始めます。
職種は特にこれといった志望はなかったので、適性検査の結果を見て営業・マーケへ。
プログラミング経験なんてないので当然と言えば当然ですが、この時点ではエンジニアという選択肢は考えにありませんでした。

Leveragesへの就活(前編)

さあ、いざ就活本番です。
途中の面接はトントン拍子に進んだものの、最終面接で役員の藤本さんから衝撃の一言。

「君はマーケティング向いてない」

事前に人事の方から「君マーケティング向いてそうだね〜」と言われてすっかりその気になってたこともあって結構ショック。最終面接フツーに落ちました。

…落ちたのですが、続いてさらに衝撃の提案が。
「気質的にエンジニアに向いてると思うんだよね。エンジニアとして働いてみる気はない?」

いや、そんなことある???
「自分、プログラミング経験ないですがいいんですか?」
当然の確認ですが、
「エンジニア側でまた面接受けてもらう必要はあるけど、要件としては大丈夫だよ」
とのこと。まじですかそれ。

しかし、マーケティング志望で不合格だったからエンジニアになる、というのも短絡的すぎる。そもそも自分はエンジニアとして働きたいのか?そして働けるのか?
ということで、Leveragesでエンジニアとして働くということについて立ち止まって考えてみることにしました。

Leveragesへの就活(後編)

まず、そもそも自分はエンジニアとして働きたいのか?
確かに、エンジニアのスキルは事業会社でやっていく上で大きな武器になります。
もし将来的に企画や営業に移るとしても、開発側の視点を持っていれば、チームワークもスムーズになるはず。
何より、エンジニアとしてサービスを作れるようになるということは、「ものづくりによる社会貢献」そのもの、つまり事業会社の根幹を支えることです。
やったことがないから選択肢には入れていなかったものの、いざ考えてみると自分にとって魅力的な職業に思えます。

次に、働けるのか? 繰り返しになりますが、未経験です。周回遅れのスタートになります。
しかし先ほど考えて、やる気はあるとわかりました。
学ぶ意欲はあります。
であれば、やるだけです。幸いにも、勉強には多少の自信があります。

こうして改めて、エンジニア職の選考を受けることに決めました。

そして、エンジニアへ

1ヶ月後…
エンジニア部長との面接に臨みました。志望した経緯は正直に伝えた上で、エンジニアという仕事を通じて実現したいこと、そしてエンジニアとしてどのように成長していきたいかを具体的に話しました。技術的な知識はなくても、ものづくりへの情熱と学ぶ意欲、そして何より、Leveragesで働きたいという意思が伝えられたこともあってか、内定をいただくことができました!

いざ、内定者インターン

さて、見事内定をいただいたわけですが…
当然ながら、内定をもらったからといってプログラミングはできるようになりません。コードは読めないままです、どうしましょう。
とりあえず入社までに、少しでも勉強するかと思っていたら、
なんと、内定者向けのインターンがあるそうじゃないですか。行くしかない。

そんなわけで、人事から提案のあった内定者インターンを2つ返事で承諾し、9月から
レバレジーズのHRTech系SaaS NALYSYSの開発チーム
でインターンをすることになりました。

最初の1週間は開発で使うTypeScriptの基礎を学習。
その後は早速、実際の業務の中でトレーニングを行うOJT形式で実践的なスキルを磨くことに。
ここは複数の事業を展開しているメガベンチャーのいいところかもしれません。
やることがたくさんあります。難しいことも、簡単なことも。

難易度が異なる様々なタスクが豊富にあるため、初心者でも無理なくステップアップできる環境が整っていました。

今は主に、バックエンド開発でApolloGraphQLを使い、Web向けのクエリ言語であるGraphQLのAPIクエリを実装して、フロントエンド開発で実装したAPIを用いて値を取得し、Reactフレームワークで作った画面に繋ぎ込んだりしています。
プログラミングなんてやったことがないと何を言ってるかわからないと思いますが、
なんとなく、「4ヶ月で開発に合流できるくらいにはなったんだ。」と思ってもらえれば大丈夫です。

実際どう?未経験でもエンジニアとして働けそう?

結論から言うと、働けそうです!
先輩エンジニアからの丁寧な指導はもちろん、実際の開発業務を通して学んだことを発揮できるので、着実に成長を実感できているのが嬉しいですね。
先ほども言った通り、難しいことでも簡単なことでも、やれることがたくさんあるので
今の自分のレベルでも、会社に貢献できることがあることが働く上では楽しさを感じられます
特に印象的だったのは、自分が開発に携わった機能が実際にリリースされた時です。ユーザーのフィードバックを受け取り、自分の仕事がサービスの成長に繋がっていることを実感した瞬間は、やはりやりがいを強く感じます。
もちろん、まだまだ勉強することは山積みです。
ただこの会社であれば、自分の学ぶ意欲・成長しようとする意思があれば、なんでもできそうだと思っています。

インターンしてみて感じた、Leveragesという会社

今、Leveragesを受けようと思っている方からすると、一番気になるところかもしれませんね。
自分の受けた印象を一言でまとめると、イメージしていた通りの会社...でしょうか。

・社内リソースが多く、裁量権が大きいので意思決定が早い。
・『やるからにはNo.1を目指す』
・声を上げれば、聞いてもらえる。手を上げれば、やらせてもらえる。
・社員全員が向上心をもち、高めあうことができる。

こういった紹介は、正直、どの会社も言うことではありますが、
実際にそれが行動として伴っているのは、Leveragesの大きな魅力だと思います。

だから、説明会を聞き、人事や現場社員との交流を経て「この会社楽しそう...!」「自分もここで働きたい...!」と思ったのなら、きっと楽しく働けると思います。
(逆に、そこまで頑張るモチベは湧かないかも...と思った方は、合わないのかも。)

終わりに

ここまで読んでくれた方の中には、(ちょっとエンジニア面白そうだな...)と思った方もいるかもしれません。
ぜひ一歩を踏み出していただければ、筆者冥利に尽きます。

Leveragesも新卒のエンジニアは、経験未経験を問わず募集しているそうなので、一歩踏み出してみてはいかがでしょうか?(特大宣伝)

最後に、実際のエンジニア現場の雰囲気がわかる動画が、最近Youtubeに上がったので、興味を持った方はみてみてください。


www.youtube.com

レバレジーズ システム本部(開発部)の人事戦略チームの発足

はじめに

こんにちは、レバレジーズ システム本部のVPoEの田中です。
この度、エンジニア組織をエンハンスすることを目的とした人事戦略チームを発足しました。
今回は、エンジニアの採用・教育・評価や組織のエンジニアリングに興味を持つ皆さんに向けて、私たちの取り組みやミッションについてお伝えさせてください。

ミッション

エンジニア特化の人事戦略チームのミッションは、「 エンジニアが顧客への価値提供・価値創出に集中できるようにする 」ことです。
私たちは、エンジニア一人ひとりが最大限のパフォーマンスを発揮できるよう、人材開発、組織開発、制度・環境の整備に邁進しています。

上記ミッションに基づいて、エンジニアリング組織の持続的な成長を支えるために、以下の業務に従事しています。

業務内容

  • エンジニア採用の強化
  • 広報活動
  • 環境・制度の整備
  • 人材開発・組織開発の強化
  • 社内外との接続点の構築

エンジニア特化の人事戦略チームが発足しました

自己紹介

レバレジーズ システム本部に所属しているVPoEの田中です。
2022年9月に中途入社でHRテック事業部にジョインし、エンジニアリングマネージャーとしてNALYSYSの開発に従事していました。今からちょうど1年前に事業部横断でのエンジニア組織マネジメントを行ってみないかというお話をいただき、VPoEとしてエンジニアの人材開発・組織開発に従事しています。

チーム発足の略歴

最初は、2024年1月ごろから私1人で動き始めました。
当初は、エンジニア組織全体として新卒採用のPDCAをしっかり回せていなかったこともあり、新卒採用全体の指揮を取ることから始まりました。また、オフィス移転の話が上がっていたので、ファシリティマネジメント(オフィス設計)も並行して行っていました。エンジニアのバックグラウンドしかなかった私にも新卒採用の全体指揮や200〜300人規模のファシリティマネジメントを任せていただけたのは弊社ならではなのかなと今では思います!

その後、2024年4月に1名ジョインし、チームとして発足しまして、この時は元々進めていた事を遂行しつつ、チームとしてどのように本質的問題に取り組んだり価値提供をして組織に貢献できるかを試行錯誤していました。
チームとして発足して3ヶ月後にさらにもう1名がジョインしてくれまして、現在は3名体制で業務に取り組んでいます。チームとして発足して半年が経過したので、この機にどんな方向性でどんな事をしているのか紹介いたします!

具体的な業務内容

当初は1人だったが故に出来ることも限られていましたが、現在では3人に増えているため業務幅も広がっています。
改めて、現在におけるチームとしての具体的な業務内容を紹介いたします。

  • エンジニア採用の強化
    • 新卒採用:
      • 戦略策定、インターンやイベントの企画と実行、面談・面接など、新卒採用の全ての工程に関わっています。
      • また、入社後にいち早く活躍してもらえるように活躍プラン(いわゆるサクセッションプラン)の策定にも携わらせて頂いております。
    • 中途採用
      • 現場マネージャー・現場リーダー・人事と連携をとりながら採用戦略の策定、面談・面接、などに携わっています。
    • 採用サイトLP等を企画〜開発まで行っています。
  • 広報活動
    • テックブログ、YouTube、カンファレンススポンサー、会場スポンサーなど、各チャネルを通して、弊社の技術力や雰囲気や文化を発信しています。
  • 環境・制度の整備
    • エンジニア支援制度やオフィス環境の最適化などを通して、エンジニアが価値貢献をしやすい環境づくりを推進しています。
  • 人材開発・組織開発の強化
    • エンジニアの成長をサポートする制度や評価の整備を行っています。
    • 評価制度システムは一部内製しているため、システム開発も行っています。
  • 社内外との接続点の構築

どの業務も一つ一つが大きなプロジェクトであり、エンジニア人事戦略チームだけでは推進しきれていないため、基本的には、各開発部署メンバーと一緒に上記業務に取り組んでいます!

レバレジーズについて少し紹介

複数の領域にて様々なプロダクトを通して事業を展開しています。
創業〜拡大まで、様々なフェーズの事業があります。

また、オールインハウスでの事業開発・プロダクト開発/運用を行っており、職能を越境して業務に携わることができます。

さらに、エンジニアが成長するためのサポートおよび制度を一部紹介します。
資格や技術書や研修などの自己研鑽に励んでもらうための制度は豊富に用意しており、チーム横断での情報交換やナレッジ共有の機会も多く提供しています。

そもそもなぜ発足したのか

当初は専任として、現在はチームとして、現在に至った背景といたしまして、以下の3点が大きな理由です。

エンジニア採用の強化

IT業界の急速な発展に伴い、優秀なエンジニアの需要はますます高まっています。
私たちの組織も例外ではなく、事業拡大や新規プロジェクトの立ち上げに伴い、エンジニアの増員が急務となっています。
新卒採用では、未来の可能性を秘めた若い才能を発掘し、長期的に企業と共に成長できる人材を求めていますし、中途採用では、即戦力となる経験豊富なエンジニアを迎え入れ、多様な視点とスキルを組織に必要としています!
そのためエンジニア採用の強化が必要不可欠でした。

人材開発・組織開発の強化

エンジニアが自身の能力を最大限に発揮し、組織全体がシナジーを生み出すためには、人材開発と組織開発が不可欠です。個々のキャリアパスを明確にし成長を支援する制度や環境を提供していますが、それらの運用はもちろん継続的な改善も重要となります。
また、組織としての学習文化を醸成し、知識の共有やフィードバックを積極的に行うことで、継続的な人材力・組織力の向上を目指しています。
このように人材開発・組織開発を常に行いつづけることで一人一人の競争優位が高く、組織としても業界No.1を築いていく力を養っていく必要性があります。

社内外との接続点

弊社はレバテックやレバウェルなどの認知度の高いサービスから、レバクリやNALYSYSなどこれからよりグロースしていくプロダクトなど、複数の事業を展開しています。
そのため、弊社に所属しているだけで、創業期〜拡大期の様々な事業フェーズに携わる機会があり、さらにはオールインハウスの体制であることから自身のキャリアパスを自由に創っていけるメリットがあります。
これらのメリットを個人としても組織としても最大限に活用してもらうため社内の接続点を多く設けることが重要と考えています。
また、オープンイノベーションの時代において、技術広報活動やイベントを通じて、他企業のエンジニアやコミュニティとの交流を深め、新しい知見や技術を積極的に取り入れていくためにも社内外との接続点の形成が必要になってきます。

これらの理由より、専任で働きかけるチームが必要と考え、メンバーを募ってチームとして発足させました!

これからどんなチーム・組織にしていきたいか

エンジニアが顧客への価値提供・価値創出に集中できるようにするために

私たちは今まで、”エンジニアが本質的な業務に集中できるように”という目的のもと、
時にはリクルーティングに関する知識やスキルを持って、エンジニアの可能性を一緒に探して最大化するサポートをし、
時にはエンジニアリングの知識やスキルを持って、サイトやシステムの保守運用・改善を行い、
時にはマーケティングの知識やスキルを持って、広報活動を通して情報発信に注力してきました。

私たちのチームは、様々な知識やスキルを身につける必要があり、多方面の協力が必要不可欠なためコミュニケーション能力や求心力を持っていく必要がありますが、
第一線で戦っているエンジニアはより専門的でより高度な知識とスキルを磨いて継続的な価値の最大化を図っているので、
全員が自由かつ有意に働けるチーム・組織にしていきたいと思います。

さいごに

改めて、レバレジーズ システム本部の人事戦略チームは、エンジニアが最大限の力を発揮できる環境を作るために、日々取り組んでいます。
私たちは、まだまだ多くの課題に直面していますが、それらを乗り越えることで組織全体が成長すると信じています。

◆We are hiring!

組織開発やエンジニアリングに情熱を持ち、課題解決に積極的に取り組みたい方、そして新しい環境で自分の可能性を広げたい方をお待ちしています。
詳細な情報や採用に関するお問い合わせは、エンジニア採用サイトをご覧ください。

私たちと一緒に、未来のエンジニアリング組織を創り上げていきましょう。

Tech Leverages 月間技術活動レポート 10,11月号

8,9月中に、レバレジーズが関わった技術イベントのご紹介です。 自社イベントのみならず、共催イベントの開催、イベント登壇と多様な関わり方で、合計7件のイベントに参加しました!

◆主催・共催技術イベント

【VPoE Meetup Vol.1】VPoE経験者が語る VPoEに求められる役割徹底解剖

弊社の開発拠点であるMiyashita Branchのセミナールームで、VPoE等が一堂に会し、これまでの経験や実践的なノウハウを共有するイベントシリーズを開催しました。50人を超える参加者と共に弊社、株式会社メドレー、株式会社ココナラのVPoEの方々が登壇しました。 (イベント詳細はこちらから)

【VPoE Meetup Vol.2】 VPoE経験者たちに聞くVPoEキャリアへのマイルストーン

VPoE Meetup Vol.1に引き続き Vol.2 も弊社の開発拠点であるMiyashita Branchのセミナールームで開催しました。Vol.2 でもVol.1と同じく50人を超える参加者が集まり、株式会社SODA、株式会社Legalscape、ファインディ株式会社、株式会社スペースマーケットのVPoEの方々が登壇してくださいました。 (イベント詳細はこちらから)

レバテック×イオン ~事業会社を支える開発組織のBizDevOps戦略~

レバテックとイオンが共同して、弊社の本社であるスクランブルスクエア25Fのセミナールームで開催しました。 (イベント詳細はこちらから)

speakerdeck.com

成果が見えづらい… 事業会社のEM必見 “縁の下の力持ち”特有の悩みに迫る

レバテックとsansanが共同して、「成果が見えづらい… 事業会社のEM必見 “縁の下の力持ち”特有の悩みに迫る」というタイトルでオンラインイベントを開催しました。(イベント詳細はこちらから)


◆イベント登壇

Product Engineer Night #6 プロダクトエンジニアを育む仕組み・施策

メディアシステム部IPLグループの金が、Product Engineer Nightに登壇しました。(イベント詳細はこちらから)

speakerdeck.com


◆イベントスポンサー

TSKaigi2025 キックオフ

10/9に行われたTSKaigi2025 キックオフにて、レバレジーズのエンジニア拠点であるMiyashita branchのセミナールームを提供しました。(イベント詳細はこちらから)

Security.any #01 セキュリティあるあるLT

11/19に行われたSecurity.any #01 セキュリティあるあるLTにて、レバレジーズのエンジニア拠点であるMiyashita branchのセミナールームを提供しました。またレバテック開発部の松浪が登壇しました。(イベント詳細はこちらから)

speakerdeck.com

◆We are hiring!

レバレジーズ株式会社では一緒にサービスを開発してくれる仲間を募集中です。 もしご興味を持っていただけたなら、こちらのページからご応募ください。

クリスマスに爆誕!オンライン学習支援制度導入後の1年間を振り返る

はじめに

システム本部レバウェル開発部部長の高木です。

レバレジーズでは、企業理念として「顧客の創造を通じて、関係者全員の幸福を追求し、各個人の成長を促す」ことを掲げており、社内で様々な学習支援制度を設けています。

開発組織でも、2023年度から「Leveragese Engineer Growth(仮) 」というタイトルで技術支援制度の運用を開始し、私は「オンライン学習支援(Udemy Business学び放題)」の導入と運用を担当しておりました。

技術支援制度の内容は以下の通りです。

  • 技術書支援:技術書購入を月1万円補助
  • オンライン学習支援:Udemy Business学び放題
  • カンファレンス費用補助:有料カンファレンスの費用を1回上限1万円まで補助
  • スクラムマスター研修補助:一定基準を満たした希望者に対する外部研修参加費補助

オンライン学習支援制度を開始したのが、ちょうどクリスマスからだったので、まばゆく光るクリスマスイルミネーションに思いを馳せながら、1年間運用してみた結果についてまとめてみました。

この記事を読んで分かること

  • なぜUdemy Businessを選んだのか
  • 導入前のちょっとした懸念
  • 1年運用してみた結果

なぜUdemy Businessを選んだのか

技術支援制度策定時には、オンライン学習支援サービスとしてUdemy Business含む4サービスを比較・検討していました。

当時、オンライン学習支援ツールに求めていたのは下記3点で、各ツールが提供している機能を比較したところ、最もバランスが良かったサービスがUdemy Businessでした。 (だんだんUdemyの宣伝をしている気持ちになってきた)

  • ①予算内に収まること
  • ②学習コンテンツの幅が広く・深いこと
  • ③学習促進・管理機能があること

①は自明のため割愛しますが、②と③の要求は、弊社開発組織に所属するエンジニアの特徴を踏まえた内容だったため、それぞれ補足します。

②学習コンテンツの幅が広く深いこと

弊社開発組織に所属するエンジニアの大半は、中途入社者で占められており、一定のWEB開発経験を持った方が多く在籍しています。 ただ、オンライン学習支援サービスの大半は、初学者向けコンテンツがより豊富に用意されていました。 学習コンテンツが初学者向けだと、利用ユーザーが少ない可能性が高いことが想定されたため、なるべく学習コンテンツの幅広さ、そして内容の深さを要求に含めていました。

③学習促進・管理機能があること

エンジニアの学習手段は、オンライン学習の他にも技術書での学習、社内勉強会、カンファレンス参加と多岐に渡ります。そして、他の技術支援制度でも前述した学習手段を支援していました。 オンライン学習支援制度は、 弊社開発組織における学習支援の主軸というより、数ある支援手段の1つという建付けだったため、なるべく管理者が学習進捗へのマイクロマネジメントを行わず、利用者が自分自身の進捗を確認できるような機能を求めていました。

導入前のちょっとした懸念

Udemy Businessは、候補の中でもバランスが良いサービスでしたが、「②学習コンテンツの幅が広く・深いこと」に関してはちょっとした懸念がありました。

それは、UdemyとUdemy Businessでは、学習できる講座数に差があることでした。 そもそも、Udemy Businessは法人向けに用意されたサービスであるため、Udemy上の講座から厳選された講座が、学び放題の対象となっていました。 厳選されているとは言え、1万講座以上はありましたが、エンジニアが学び続けられるコンテンツの幅広さ・深さを担保していると断言はできませんでした。

Udemyを個人で契約して学習しているエンジニアも一定数いたため、ありがたいことにオンライン学習支援制度への期待も寄せられていましたが、学びたい講座が無くログインしない利用者が多いと、導入後の振り返りも難しい…。

上記懸念があったため、オンライン学習支援制度の利用を希望をする方には、Udemy Businessの講座ラインナップの中で自身が学びたい講座があるかを確認した上で、意思表明してもらうようにしてみました。

1年運用してみた結果

希望者制にした結果、この1年でのべ92名のエンジニアが利用し、弊社開発組織内での学習傾向が見えてきました。 そのうち、想定通りの結果と予想外の結果を要約してご紹介します。

想定通りの結果

  • 若手エンジニアの方が、Udemy Businessでの学習時間が長い
  • 開発チームで利用している言語・フレームワークに関する講座が、よく視聴されている
  • AWS認定資格取得講座が、よく視聴されている
  • 導入から時間が経つにつれて、学習時間が減少する
  • Udemy Businessを導入している企業の中では、学習時間が平均以上となった

予想外の結果

  • ソフトスキルに関する講座が、エンジニアの経験問わずよく視聴されている
    • 例:リーダーシップ、ロジカルシンキング、コミュニケーション講座
  • AWS認定資格以外の資格取得講座が、よく視聴されている
    • 例:PMBOK、データスペシャリスト、情報セキュリティマネジメント試験
  • 英会話・TOEIC対策講座が、異様なほど視聴されている

まとめ

想定通りではありましたが、オンライン学習支援制度を導入した当初は希望者・学習時間ともに最大値を記録しましたが、時間の経過と共にいずれも減少傾向となりました。 一方で、特定領域に閉じず幅広く学習したい方にとっては、自己学習の手段として有効である示唆を得られたため、引き続き同制度を運用する予定です。 (来年度の目標は、採用数、定着率、生産性などで定量的に効果を示すことです!)

We're hiring!

今回の記事では、レバレジーズ開発組織で運用しているオンライン学習支援制度の導入検討材料と1年間運用してみた結果について取り上げてみました。

レバレジーズに少しでも興味を持っていただけた方は、こちらからぜひエントリーをお願いします! イルミネーションが光輝く渋谷にて、お待ちしております!💡

未経験のフルマラソンにチームで挑む 〜仕事も趣味も全力なエンジニアって素敵やん?〜

はじめに

こんにちは。
レバレジーズでHRTech系SaaS NALYSYSの開発チームでEMをやっております、下畑と申します。
11月に弊社エンジニア6人 + 人事1人の計7人でフルマラソンに参加しました。
全員フルマラソン未経験でしたが、7人中6人が完走することができました。
この喜びを多くの人に伝えたいと思い、今回記事にしてみました。

この記事を読むとわかること

  • 4ヶ月でフルマラソンを完走する方法
  • 4ヶ月の練習を乗り切る術
  • 弊社エンジニアの人柄
    • フットワーク軽すぎぃ!
    • やり切る胆力もってんだよな
  • 弊社エンジニア組織のハートフル感

ことの発端

弊社では朝の始まりをご機嫌な気分で始めるために、毎朝Good & Newという時間があります。
週替わりで部署を跨いだ社員同士の予定が組まれ、昨日あった面白かったことや、最近始めたことを紹介しあいます。

7月某日のGood & Newがことの発端でした。

弊社PdM「最近妻に太ってるのをなんとかしろって言われてフルマラソン出ることになったんですよ。」
わたくし「いいじゃん。いつ走るの?」
弊社PdM「11月のひたちシーサイドマラソンに出ます。」
わたくし「いいじゃん。俺も出たろ。」

なぜ二つ返事で参加すると言ったかというと、私はPdMのお腹がそこそこ出ていることを知っていたからです。
この人が走れて自分が走れないわけがない。
走れなかったとしても、彼も走れないから別に恥ずかしくない。
だったら出ようと。
そういうことです。

仲間を求めて

2人だけの参加だとイマイチ盛り上がりにかけると思ったので、事業部内のメンバーに声をかけてみました。
日課でマラソンをしている人を筆頭に色々声をかけた結果、今回のエンジニアランナー6人が集まりました。
まさかこんなに集まるとは思いもしていなかったです。
フルマラソンという競技のもつ魅力と、弊社エンジニアのフットワークの軽さに驚きました。

今回仲間集めで学んだことは、
「筋トレをしている方は、有酸素運動の量にうるさい傾向があるため誘わない方がいい」
ということです。

練習メニューの模索

フルマラソンを走るために我々はなにをやればいいのか?
周りに専門家がいるわけでもなかったので、情報収集から始めました。
7月中旬に走ろうと発起したので、本番まで4ヶ月ちょっと。
しらべてみるとこんな記事を見つけました。
【4ヶ月の練習でフルマラソン完走!】初心者用16週間トレーニングプラン

これを守って練習しようと決めました。

要約するとこんな感じです。
1ヶ月目:
平日 30分〜40分 × 2
週末 60分〜80分

2ヶ月目:
平日 30分〜40分 × 2
週末 16km〜20.8km

3ヶ月目:
平日 30分〜40分 × 3
週末 25km

4ヶ月目(最初の2週間):
平日 30分〜40分 × 3
週末 30km以上

4ヶ月目(最後の2週間):
休息期間
週に1時間くらい走る

当時はこのメニューのおそろしさを知らぬまま、4ヶ月の練習でも完走できる希望があることにただ喜んでいました。

絶望と人間の持つ可能性に震えた初週

練習を開始してまもなくみんなが感じたことを書きます。
30分走ると4kmから6kmくらい走ることになりますが、その時点でとてつもない筋肉痛をみんな味わいました。
フルマラソンを走り切るためには10倍くらい走らないといけないと想像したとき、
やろうとしていることの過酷さを感じるとともに、
4ヶ月間このトレーニングメニューをこなしフルマラソンを完走できるのであれば、人間の成長ってすごいんじゃない?
と感じざるをえませんでした。

この困難に打ち勝つにはなにかしなきゃと。様々な策を講じていきます。

困難に打ち勝つための作戦 その1

stravaというサービスをご存じでしょうか?
ランナーや自転車乗り向けのSNSなのですが、走ったデータを記録し、フォロワーに対して共有することができるサービスです。
参加するメンバーにはこのSNSに登録してもらい、走った記録を共有するようにしました。
もちろんSNSなので、いいね機能(stravaだと”kudos”です☺️)やコメント機能があり、
走った記録に対して毎回みんなからいいねやコメントがもらえました。

実際にもらえたkudosやコメント

同じ辛さを共有しているメンバーからの励ましは嬉しいですし、
メンバーの頑張りも見えるのでとても励みになりました。

困難に打ち勝つための作戦 その2

カレンダーに定期ランの予定を入れました。
走ってサウナ入って、たらふく食べて酒を飲む会なのですが、
日々の練習とは違い、おしゃべりしながらゆっくり走りますし、
マラソンのストイックなイメージを払拭するにはいい効果があったかなと思います。
予定はこんな感じで人が集まったら開催です。

参加者が2人以上いれば開催です

スカイツリーを目指して隅田川沿いを走ってました

ランニングステーションはととけんを利用していました。
走ったあとのサウナとビールが最高のお店です。おすすめです。

意外な副作用

定期ランは「フルマラソンに挑戦するのは遠慮しておきます」という方であっても誘いやすく、
会社の飲み会などで興味を持った方を積極的に誘いました。
この定期ランをきっかけに、フルマラソンに参加すると決めた人事部の方がいらっしゃいます。
彼女も無事に完走しました。(すごい)
他部門との交流が多いのも弊社の特徴かもしれません。

怪我との戦いと練習メニューの見直し

毎週1.6km(1マイル)ずつロングランの距離を増やしていきますが、距離が20kmを超えたあたりで皆どこかしらの故障を経験しました。
怪我をすると練習時間を失うため、4ヶ月という限られた時間で練習している我々は精神的にも追い詰められました。
まわりが練習するなか練習できない不安感は筆舌に尽くしがたいものがあります。

フルマラソンを完走するために必要な要件を新たに探し求めたところ、この記事に出会いメンバーに共有しました。
ロングランの距離を伸ばすのではなく、週の距離を伸ばすよう練習メニューを変えた結果、怪我をせずにフルマラソン当日を迎えることができました。

部活動チャンネル

弊社では非公式の部活を勝手に旗揚げすることができます。 slackで部活用のチャンネルを自由に作ることができるのですが、我々もこのようにチャンネルを作成し情報共有する際に使っておりました。

チャンネルでの共有

いざ、フルマラソン旅行

日立市での開催だったので、月曜日に有給を取得し2泊3日のフルマラソン旅行になりました。
マラソンは日曜日だったのですが、翌日のダメージが想像できず、帰りの道路で事故のリスクもあったためこの日程を組みました。

行きと帰りはわちゃわちゃ観光を楽しみ美味いものを食べ、宿はairbnbにみんなで泊まりわちゃわちゃしました。

大洗のめんたいパークに行きました

これまでの練習や仕事で関係性ができていたため、観光中も宿泊中も無駄な気遣いをせず、ストレスなく過ごせました。
これって地味にすごいことかなと思っています。

こうして記事を書いてみると当日のことはあまり書けることはなく、ひたすら辛かった。
皆身体を壊さず完走出来たのが良かったです。

凱旋

東京に帰ってきてから、なんだか思いが溢れちゃってLINEのグループでメンバーへの感謝を伝えました。
それに応じてみんなも色々書いてくれてとてもエモかったです。
6人同時に有給をとった我々を、温かく応援してくれた他のチームのメンバーにもここで感謝させてください。

おわりに

皆仕事の合間を縫ってやりたいことをやるために練習時間を捻出しました。
社会人として大事なことな気がします。
こうして過程を書いてみると、計画を立てたりそれを履行したりと、仕事とやってることあんまり変わらないんじゃねえかと思いました。
ただ、普段はあまり一緒に仕事をしない、チームを超えた関係性のなかでそれが出来たことがとても貴重だったと思います。

また、マラソンの経験者がいるなかでの話だとまた違った感情になりそうだと思います。
みんなが未経験で訳も分からないなかでフルマラソンに挑戦した、という経験がもたらすもののかけがえのなさは確かに存在するのかもなと思いました。

フットワーク軽く誘いにのってくれて、これほどの辛い練習に付き合ってくれたメンバーの皆様。ありがとうございました。

ここまで読んでくれて、こんなハートフルな仲間と働いてみたいと感じた読者の方。仕事を超えた関係性を作りたいと感じたそこのあなた。フルマラソンを人生で1回は走ってみたいと思っているそこのエンジニアの方。
是非是非、こちらからご応募待ってます☺️

我々のチームの雰囲気がよくわかる動画がYoutubeにも上がっておりますので、
興味を持たれた方はお時間ある時にみてみてください。


www.youtube.com

レバレジーズの新規事業の裏側大公開!転職スカウトサービス「キャリアチケット転職」

はじめに

こんにちは。レバレジーズ株式会社システム本部の及川です。

2024年9月に転職スカウトサービスである「キャリアチケット転職」をリリースしました! 既存の新卒向け就職支援サービス「キャリアチケット就職」が生んだ、若手×成長志向に特化した転職メディアとなっています。

今回、求人機能やスカウト機能、応募機能などを盛り込んだ大きなリリースとなりました。このような新規事業では開発にとどまらず、設計やマーケティング、オペレーション周りにも関わることができました。

本記事では「キャリアチケット転職」のリリースにあたって、下記4点を紹介したいと思います。

  • サービスの詳細
  • 技術選定の背景
  • 技術的こだわり
  • 今後の取り組み

この記事を通じて、本サービスの詳細だけでなく、技術選定の背景や私たちの技術へのこだわりが伝われば幸いです。

サービスの詳細

まず今回リリースしたサービスの特徴を説明します。

サービスの背景として、既存の「キャリアチケット就職」では、2017年のサービス開始以降、年間1.4万人の学生一人ひとりの価値観に合った就活支援を行ってきました。
昨今の若手の転職ニーズの高まりを受け、キャリアチケットの強みである「一人ひとりに適したキャリア支援」を行い、現状のキャリアに不安や迷いを感じる若手を支援するサービスとして、「キャリアチケット転職」をリリースすることになりました。

サービスの特徴としては、求職者には経歴だけでなく、仕事で重視することや実現したいことを記入してもらうことによってより価値観が合った求職者を見つけることを可能にしています。

技術選定の背景

次に技術選定の背景についてです。
レバレジーズの新規事業は技術選定も0から自分たちで行うので、自分が挑戦したい技術なども選択肢に出しやすく、モチベーションアップに繋がりました。
今回のプロジェクトでは、スピード感を持った開発を最優先事項として掲げ、開発メンバーの技術力向上も同時に目指しました。そのため、既にチームに知見のある技術を基盤として採用しつつ、メンバーが挑戦できる新しい技術も積極的に取り入れるようにしました。

アーキテクチャ

言語はフロントエンドにTypeScript、バックエンドにGoを採用しました。TypeScriptのメリットは、静的型付けにより事前に型エラーが分かる型安全性があることが挙げられます。また既にチームに知見のある技術でもありました。

Goのメリットは文法がシンプルで覚えやすく、直感的に書けるため学習コストが低いこと、静的型付けによる型の安全性があること、パフォーマンスが高く運用コストが抑えられることが挙げられます。社内で知見の多いPHP(Laravel)やTypeScriptもバックエンドの候補に上がりましたが、開発メンバーの技術力向上を目指して新しい技術としてGoを採用することになりました。

フロントエンド

TypeScriptで開発するにあたり、フレームワークとして Next.jsを使用しました。これらはチームメンバーの知見が豊富であることを理由に選定しています。

さらに、データ取得には GraphQLを利用しており、GraphQL Codegenを用いることで、型安全なクエリやミューテーションの操作を自動生成しています。生成された Document を活用して、useQueryやuseMutationといった React Hooks 経由で簡潔かつ型安全にクエリを実行できる仕組みを構築しています。

フォーム操作では react-hook-formを採用しており、軽量で柔軟性の高いフォーム管理を実現しています。また、サーバーからのレスポンスに基づいた動的なバリデーションも組み込みやすくなっています。

テスト環境では、msw (Mock Service Worker) を利用して、API レスポンスをモックすることで、ネットワーク依存を排除したテストを可能にしています。これにより、開発初期段階やバックエンドが未完成の場合でも、フロントエンド側でのテストやデバッグが容易になっています。

これらのツールを組み合わせることで、開発の生産性とコードの品質を高めるとともに、保守性の向上を図っています。

バックエンド

Goで実装するにあたってFWは採用しませんでした。理由としてBEがAPIサーバーとしての役割だったので、 標準ライブラリ(net/http)で十分であり、FWを使わない方がシンプルに実装ができると考えたからです。

ORMはSqlBoilerを採用しました。SqlBoilerはデータベースのスキーマからコードを自動生成するため、型安全性が高く、SQLクエリの構築ミスや型の不一致によるエラーを未然に防げます。 また、CRUD操作が即座に利用可能なコードを生成するため、開発効率も向上します。スキーマ変更時も再生成でコードを簡単に更新できるため、保守性が高いのも特徴です。ただし、マイグレーション機能は備わっていないため、外部ツール(golang-migrate)を併用して対応しています。これにより、安全で効率的なデータベース操作が実現可能です。

API

APIには GraphQL を採用しました。 本サービスはマイクロサービスアーキテクチャを採用しているため、GraphQL Federationを活用することで、各サービス間のデータ統合を効率化し、パフォーマンスの向上を目指しています。GraphQL Federationについては後ほど詳しく説明します。

また、APIの効率的な処理を実現するために Apollo Routerを活用し、これと併せて Apollo を採用しました。Apollo Routerは、高速でスケーラブルなGraphQLリクエストのルーティングを可能にするツールであり、特にマイクロサービス環境やGraphQL Federation構成においてその真価を発揮します。これにより、複数のサービスからのデータを統合し、シームレスでパフォーマンスの高いAPI提供を実現しています。

インフラ

インフラ周りはAWSを基盤として、環境の構築はAWS CDKを採用しました。TypeScriptでコード化することで、インフラの知識があれば慣れたプログラミング言語で誰でも簡単にインフラ環境を構築できて、コードやCLIから簡単にレビューできる体制を目指しました。

技術的こだわり

次に技術的こだわりを紹介します。

GraphQL Federationの活用

GraphQL Federationは、複数のGraphQLサービスを統合して一つのGraphQL APIとして提供する設計手法およびツールセットです。これにより、分散型アーキテクチャでも効率的にデータへアクセスが可能となっています。

各マイクロサービスが独自のGraphQLスキーマを持ち、独立して開発・デプロイできるため、当サービスで採用しているマイクロサービスアーキテクチャとの親和性が高いです。

さらに、スキーマの拡張性が高く、あるサービスで定義した型を他のサービスで簡単に拡張することが可能です。この特性により、マイクロサービス間でのデータ共有や拡張が柔軟に行うことができます。詳細については、以下のリンクで図を用いて分かりやすく解説されているので、ぜひご参照ください。

www.apollographql.com

モノレポの導入

モノレポ(Monorepo)は、複数のプロジェクトを1つのリポジトリで管理する手法です。この仕組みにより、以下のメリットを実現しています。

  • コードと依存関係の管理が簡単  共通ライブラリやユーティリティをリポジトリ内で共有し、外部パッケージのバージョン管理の複雑さを軽減しています。

  • 一貫した開発環境 ESLint、Prettier、テストフレームワークの設定が統一され、全プロジェクトに一貫性を持たせています。

CI/CDの自動化

当サービスでは、継続的インテグレーション(CI)と継続的デリバリー(CD)を自動化することで、開発とデプロイの効率化を実現しています。

  • 一貫性のあるビルドとテスト コード変更がリポジトリにプッシュされるたびに、自動でビルドとテストが実行されます。これにより、バグを早期に発見し、リリースの品質を高めることができます。

  • 自動デプロイ 特定のブランチにマージされたコードは、ステージング環境または本番環境に自動的にデプロイされます。このプロセスにより、手動デプロイによるミスを防ぎ、リリースサイクルを短縮します。

  • モノレポとの連携 モノレポ内の変更に応じて、影響を受けるプロジェクトのみをビルド・デプロイする仕組みを採用。たとえば、Aサービスに変更が加わった場合、Bサービスのデプロイはスキップされます。これにより、CI/CDプロセスの実行時間を大幅に短縮できます。

これらの仕組みを通じて、迅速かつ高品質なリリースを継続的に行えるようにしています。

開発環境構築の自動化

エンジニアが迅速に作業を開始できるように、開発環境の構築プロセスも自動化しています。これにより、個々の環境構築にかかる工数を削減し、全員が一貫した環境で開発を進められるようにしています。

  • Dockerコンテナの活用 開発環境をDockerコンテナで構築し、各エンジニアが同一の環境を再現可能にしています。これにより、「自分の環境では動作するが他の環境では動作しない」という問題を排除しています。

  • セットアップスクリプトの提供 必要な依存関係や設定をインストールするセットアップスクリプトを提供しています。新しいエンジニアがリポジトリをクローンした後、スクリプトを実行するだけで、必要なツールやライブラリが自動的にインストールされます。

これらの取り組みにより、エンジニアは環境構築に時間を取られることなく、すぐに本来の作業に集中できるようになります。

今後の取り組み

私たちのチームでは、エンジニアに限らず、マーケターやデザイナーを含めた多職種のメンバーが、より良いサービスを目指して日々議論を重ね、多様な施策を実行しています。 私自身もエンジニアとして、利用者を増やすためのアイデアを提案したり、エンジニアの視点からデザインにコメントをしたりと、チーム内で積極的にコミュニケーションを図っています。

その中で、私たちが今後取り組んでいきたいと考えている施策は以下の通りです。

  • 求人数・求職者数の増加 サービスの成長のため、より多くの求人情報や求職者をプラットフォームに集めることが重要です。これにより、求職者に多様な選択肢を提供し、ユーザー満足度の向上を目指します。

  • 精度の高いマッチングの実現 求人数や求職者数の増加に伴い、マッチング精度の向上がこれまで以上に重要となります。これを実現するため、検索アルゴリズムの強化や高度な検索機能の開発、求職者のユーザー体験(UX)の改善を図っています。これにより、システム全体の性能を向上させ、各ユーザーにとって最適な結果を提供できるよう進化を続けていきます。

 求職者向け:希望条件に基づき、最適な求人の選択肢を提供します。これにより、求職者が自分に最も適したキャリアの選択ができるよう支援します。  採用担当者向け:企業の条件や組織風土に合致する求職者をレコメンドすることで、採用プロセスの効率化の向上を支援します。

  • パフォーマンスの向上 ユーザー数の増加に伴い、システム全体のパフォーマンス向上も重要な課題です。安定したサービス提供を維持し、快適な利用体験を保証するために、インフラやアーキテクチャの最適化を継続して行っていきます。

これらの課題に取り組むことで、サービスの価値をさらに高め、多くのユーザーに選ばれるプラットフォームを目指していきます。

さいごに

最後までお読みいただきありがとうございました。 キャリアチケット転職を通してより多くの求職者を支援することを目指して、これからの課題に取り組んでいきたいと思っております。 そして本記事を通じて、サービスの詳細をはじめ、技術選定や私たちの技術へのこだわりのイメージを持っていただけたなら幸いです。

現在、私たちと一緒に挑戦してくださるエンジニアを募集しています。ご興味のある方はぜひ採用サイトをご覧ください!

レバレジーズの機械学習エンジニアの1年を振り返る

この記事を読んで分かること

  • レバレジーズの機械学習エンジニアの今年1年の活動について分かります!
  • レバレジーズの生成AIを活用した取り組み状況について分かります!


はじめに

システム本部テクノロジー戦略室AI/MLエンジニアリンググループの稲垣です。

AI/MLエンジニアリンググループはいわゆる機械学習エンジニアが所属するチームになっており、現在は私含め3名が所属しています。

チームの主な役割としては以下があります。

  • データサイエンティストが作成した機械学習モデルのプロダクトへの組み込み、MLOps基盤の整備
  • 生成AIを活用したプロダクト改善、機能追加、社内業務効率化

この記事では、今年1年の振り返りをすると共に、来年はどんなことをやっていきたいのかについても触れていきたいと思います。

また、上記を書いていく中で「会社のためになると思うことは自由にチャレンジしてOK」というレバレジーズのエンジニア文化が少しでも伝われば良いなと思っています。

レバレジーズの機械学習エンジニアの働き方について興味がある方にとって、有益な情報になれば嬉しいです。

今年やったこと

生成AIへのリソース全振り

結論から言うと、今年の我々のチームは生成AIに関することにリソースを全振りしよう、という形になりました。

背景としては、社内の機械学習モデル関連のタスクが一段落していた点と、みなさんもご存知の通り今年も昨年に引き続き生成AI関連技術の進歩が著しかったことがあります。

また、生成AIの特性上、モデルを1から作る必要は無くベンダーが提供するAPIを叩くだけで使用できるため、データサイエンティストの所属するチームではなく我々のチームの方が相性が良いだろう、という判断もあった点もあります。

最初にぶつかった壁:そもそも社内で生成AIを使える状態にする

今年の1月時点では、社内での生成AIの活用事例はほぼゼロでした。
また、社内で生成AIを使う上でのガイドラインなども存在しておらず、社内で生成AIを使ってよいのか良く分からない、誰も知らない、という状況でした。

そのため、例えばあるプロダクトに生成AIを使った機能を追加するアイディアがあっても、社内で生成AIが使えない状態であったり、社内における生成AIに対する認知/理解があまり無い状態のため前に進めることは困難でした。

このような状況であったため、チームとしてまずは

  • 社内で生成AIを誰でも使える状態にすること(社内インフラと社内ルールの整備)
  • 社内での生成AIの認知/理解を高めていくこと(社内での生成AI活用推進)

を行っていこうという方針となりました。

また、今年のレバレジーズの全社スローガンが「次代を、創る。土台を、創る。」であったため、その内容にもマッチしていて良さそう、という背景もありました。

CAIL(社内AIチャットツール)の開発

CAILとは「Chat AI for Leverages」の略で、その名の通りレバレジーズ社内用のAIチャットツールです。
(補足:昔のwindowsにいた某イルカとの関連は全くありません!)

CAILは簡単に言うと社内用ChatGPTのようなもので、上述の通り「社内の誰でも生成AIを安全かつ自由に使えるようにする」ことを目的に開発しました。

特に、社内限の情報を扱う際に情報漏洩のリスクが怖くて生成AIを使わないようにしている、という方が社内に多くいたため、その辺りの不安を解消することがCAIL開発を始めた大きなきっかけでした。

CAILの開発を始めるにあたり、フルスクラッチで開発する路線もありましたが、AWSが提供している「BedrockClaudeChat」という非常に素晴らしいAIチャットツールのOSSがあったため、そちらをベースにして開発しています。
(フルスクラッチで作っていたら多大な時間がかかっていたので、このOSSのコミッターの方々には足を向けて寝れません...)

社内ニーズがあるがOSS側では実装されていない機能(モデル追加、google認証、権限管理、コスト管理、PDF入力機能など)については社内で開発し、できる限り使い勝手が良いツールとなるよう努力しています。

CAILの社内認知

CAILを社内に展開し始めたのは今年の3-4月頃ですが、現在では約2000人(全社員の半分程度)のユーザーがおり、社内での一定の認知を獲得したツールに成長させることができました。

ただCAILの社内展開は最初から上手くいった訳ではなく、展開し始めた頃は社内で「生成AI=得体の知れないもの」という雰囲気があり、ユーザー数の増加に苦労した時期もありました。

ユーザー数を増やすに当たっては

  • 社内で生成AIへの感度が高い社員を探し出しCAILを使ってもらう/他の方にもオススメしてもらう
  • 生成AIの業務への活用事例集を作る、CAILの使い方マニュアルを手厚めに作成し使い始めるハードルを低くする
  • 社内の各組織の部長レイヤーの方にCAILを宣伝させてくれないか提案しにいく

などの草の根活動を地道に行い、じわじわ社内認知を広めていく作戦を取っていました。

社内用Difyの整備

Difyとは、OSSで提供されている生成AIのノーコードツールです。

通常のチャットツールでは対応しにくい、生成AIの高度なユースケースへの社内ニーズがあったため導入することにしました。

こちらも全社員誰でも使えるように社内のクラウド環境でデプロイを行いました。

デプロイに際しては社内のSREが所属するチームと協力し、DifyをKubernetesクラスタ上に稼働させることで柔軟なインフラ構成を実現しています。

社内QAボット

レバレジーズは年々社員数が増加しており、社内のバックオフィス系の問い合わせ対応工数もそれに伴い増加していました。

そこで問い合わせ工数削減のため、まずは情シス宛ての問い合わせ回答の一部自動化を目指し、生成AIを使ったQAボットを開発&導入しました。

導入後は1日に大体10~15件程度の問い合わせを捌いており、かつ的を射た回答も一定数できているため、今後は情シス以外のバックオフィスへの拡大を検討している所です。

その他具体的な内容は書けないが業務効率化したもの

これまで社内業務で手作業で実施していたもののうち、生成AIと相性が良いものに対してツールを開発し一部自動化を行いました。

結果、パートさん複数人分の工数が削減できる程度の効果があり、これまでリソースを割けていなかったタスクへの再配置、という改善を行うことができました。

toC/toBサービスへの機能開発

上記の活動が実を結んだのか、今年の後半ではtoB/toCプロダクトへの生成AIを利用した機能の開発の熱感が高まってきました。

現在進行中のものとしてはNALYSYSのQAボット開発や、レバテックへの機能追加の検討が進行中です。

来年やりたいこと

ここまで、AI/MLエンジニアリングチームで今年1年間で行ったことについて紹介しました。

以降は来年に向けてやっていきたいことについて書いていきます。

CAILの機能強化

より使い勝手を上げるべく、ArtifactsGrounding, Agentなどのより高度な機能の追加を行っていきたいと思っています。

また、現状CAILはChatGPTやClaude.aiのコピー版になっている節があるため、社内のBigQueryやGoogleDriveとの接続など社内チャットツール独自の機能の追加が出来ないかについても考えていきたいです。

toC/toBサービスへの生成AI機能の組み込み

この領域に対しては来年特に力を入れて進めていきたいです。

具体的には、

  • 現在検討を進めているプロダクトへの生成AI系機能追加を無事リリースする
  • 生成AIをどうプロダクトの価値向上に活用できるか考え、提案していく
  • 他の開発チームとのコラボレーションを進めていく

あたりを頑張っていきたいと思っています。

社内の業務効率化

こちらは今年もいろいろ取り組みましたが、社内にはまだまだ人の手で実施されているタスクがあり、効率化の余地は残されているかと思います。

そのため、生成AIの力が上手く使えそうなものについてはツール/システムの開発を行い、業務効率化を進めていきたいと考えています。

生成AI以外の機械学習モデルのサービス組み込み、MLOps基盤の整備

今年はほぼリリースが回せなかった領域ですが、
来年は古くなった求人レコメンドシステム、APIサーバの刷新など、積極的に着手していきたいと思っています。

社内での評価

今年1年のAI/MLエンジニアリングチームの活動が評価され、今年の10月にベストエンジニア賞を頂くことができました。

今年我々のチームで行った動きは、上から司令として降ってきた訳ではなく、チーム内で話し合い目標を立てて始めたボトムアップ的な動きでした。

そのような中で結果として会社から評価された点は、「会社のためになると思うことは自由にチャレンジして良い」というレバレジーズの社風の影響を感じました。

最後に

レバレジーズ株式会社では一緒にサービスを開発してくれる仲間を募集中です。(採用サイトはこちら

AI/MLエンジニアリングチームでは、機械学習周りに強みを置きつつ、インフラ、バックエンド、フロントエンドまで広く携われる点、ユーザーのニーズの拾い上げからプロダクト開発まで一貫して経験できる点が魅力かと思います。

最後に、今年触れていた技術スタックについて参考までに記載します。
(今年は生成AIに染まっていたので普通のML系は少なめです)

  • Infra:AWS,GoogleCloud
  • IaC:AWSCDK,Terraform
  • AI/ML:GoogleVertexAI,AmazonBedrock,AmazonSageMaker
  • workflow:Airflow,GithubActions
  • Backend:Python,FastAPI,LangChain
  • Frontend:TypeScript,React

ここまで読んでいただきありがとうございました。

監視ツールの枠を超える!Datadog Summit Tokyoで得たDatadog活用のヒント

はじめに

レバレジーズ株式会社 レバウェル開発部の山口です。 2024年10月に開催されたDatadog主催のイベント「Datadog Summit Tokyo」に参加しました。Datadogは監視ツールとしてだけでなく様々な活用方法があるということを知り、とても勉強になるイベントでした! その内容を皆さんに紹介したいと思います。

Datadog Summitの紹介

Datadogは、クラウドベースの監視(モニタリング)ツールです。システムやアプリケーションのパフォーマンスや動作状況をリアルタイムで可視化し、問題を早期に発見・解決するためのプラットフォームを提供してくれます。

そしてDatadog Summit Tokyoはオブザーバビリティの専門家やDatadogチームから直接学ぶことができる無料の1Day イベントです。 セッションでは他社のDatadogを活用した様々な取り組みを知ることができます。現場の生の声を聞く貴重な機会です。

www.datadoghq.com

参加の背景

Datadog使いこなせてないかも?

総合転職サービス「レバウェル」のスカウトサービスでは監視ツールとしてDatadogを利用しています。しかし導入以来あまりメンテされておらず、新機能はおろか基本的な機能もフル活用できていないように見受けられました。 もっと活用したらサービスの品質を高い状態で維持したり、障害発生時の復旧速度を上げられるのでは?というモチベーションでチームとして知識向上に取り組み始めていました。 そんな時にDatadog Summit Tokyoの開催を知り、「これは行くしかない!」と他メンバーを誘って一緒に参加することを決めました。

カンファレンス支援制度

レバレジーズではエンジニアの支援制度の一つに「カンファレンス支援制度」というものがあります。これは勉強会やカンファレンスの参加費の補助と、業務時間内での参加が可能になる制度です。今までこの制度を利用したことがなかったので、「せっかくなら使える制度はどんどん活用してチームのモチベーションも上げていこうぜ!」ということで業務として参加させてもらうことにしました。

セッション

イベントでは様々なセッションがありましたが、その中でも「Datadogってこんな使い方できるんだ!」という驚きがあったものを紹介したいと思います。 どのセッションも思わず聞き入ってしまうような内容だったので、ご興味ある方はぜひアーカイブ動画の視聴をお勧めします!

【Datadogダッシュボードで見える化する、新たなビジネス価値創造のチャンス】NTT Docomo - 野部 大貴 様

アーカイブ動画

youtu.be

こちらのセッションは大きく3つのテーマについて扱われました。

  • 利用しているDatadogの機能
  • ビジネス価値向上への貢献事例
  • ダッシュボードとの向き合い方

この中でも特にダッシュボードに関するお話がとても勉強になりました。 全体的な内容をまとめつつ、「こんな使い方があったんだ」といったDatadogを使いこなすヒントになる情報を紹介していきたいと思います。

利用しているDatadogの機能

紹介のあった機能と主な使い方は以下の通りです。

  • 障害検知にMonitor
    • Slackへの通知
    • 普段と挙動が違うときに通知(Anomaly機能)
  • 分析にAPM
    • どこの通信、サーバーで問題が起きているのかを特定
  • 網羅的な情報のモニタリングにダッシュボード
    • 意味のあるデータが整理整頓されている
    • 用途に応じたダッシュボードを作成

この中で私たちもぜひ活用したいと感じた機能がAnomaly機能です。 AnomalyとはDatadogのMonitorの中の種類の一つであり、いわゆる異常検知モニターというものです。以下、公式サイトからの引用です。

引用元:https://docs.datadoghq.com/ja/monitors/types/anomaly/

異常検知は、傾向や、季節的な曜日や時間帯のパターンを考慮しながらメトリクスの挙動が過去のものとは異なる期間を認識するアルゴリズム機能です。これは、しきい値ベースのアラート設定では監視することが困難な強い傾向や反復パターンを持つメトリクスに適しています。

docs.datadoghq.com

現在は主に閾値を用いた異常検知を行っていますが、アラートを鳴らす閾値を正しく設定するのが難しい場合もあります。例えば曜日によってアクセス数の傾向が大きく変わる場合などです。閾値が低すぎると偽陽性アラート(本当は問題がないのに問題があると通知する)が増えてしまいますし、逆に閾値が高すぎると異常を検知することができません。 Anomaly機能を利用すると過去のメトリクスをもとにパターンを学習し、そのパターンから外れた時にアラートを出してくれます。つまり「何かいつもと違う!」を検知することができます。より柔軟な監視設定をすることが可能になるため、ぜひレバウェルでも導入を検討したいです。

ビジネス価値向上を実現するためのダッシュボード作成

1つ前のテーマである「利用しているDatadogの機能紹介」でも触れられていましたが、情報の見える化・網羅的な情報のモニタリングにダッシュボードを活用しているというお話でした。

実際のビジネス価値向上事例

  1. 新機能であるd払いスタンプ機能をリリース
  2. モニタリングのためにダッシュボードを作成
  3. モニタリングの結果、決済数は増加しているが宝箱開封率が低い、つまりお得さを届けきれていないお客様がいることが判明
  4. 宝箱開封を促すメッセージ機能の実装で開封率が32.3%向上し、KPI改善に貢献
  5. システム担当が積極的にビジネス観点も見るようになった

この事例の中ですごいと感じたのが、新機能をリリースして終わりではなく、システム担当がしっかりモニタリングまで行っている点です。 モニタリングをする際はシステム観点(問題なく使えているか)はもちろん、サービス観点(目的達成に貢献できているか)で計測することを意識しているとのこと。 具体的にはユーザーストーリー毎にエラー数やレイテンシを計測し問題なくスムーズに使えているかを確認したり、アクセス数を計測してどのくらい使われているかを確認しているそうです。 Datadogで確認した情報がきっかけで新たな検討に繋がり、ユーザーへより良い価値を届けられるという点が非常に素晴らしいですね。

ダッシュボードとの向き合い方

1つ前のテーマでもあった「システム担当が積極的にビジネス観点も見るようになった」という変化は、ダッシュボードへの向き合い方が変わってきたからこその結果と考えているとのこと。 具体的な内容は以下の通りです。

  • 価値に繋がるデータは何か、どんな見方が良いのかを徹底的に考える
    • 機能が目標通り使われているか?(リクエスト数)
      • 目標達成の見込みを把握できる
    • 起動時間はどれくらいかかるのか(レイテンシ)
      • 改善が必要な処理を特定する
    • 多く使われる動線はどちらか
      • ニーズが高い動線を把握可能
  • 今後の展望
    • ダッシュボードURLを発行して共有することで様々な人と議論できる
    • ビジネス担当にも広げていきたい
      • 一緒にデータを活用するという意識を高めた
      • 同じデータを見ることでシステム改善の速度が向上する
      • システム担当とビジネス担当が一体となっていきたい

前半の「価値に繋がるデータは何か、どんな見方が良いのかを徹底的に考える」はエンジニアにとって非常に重要な視点だと感じました。 私たちのチームでも日々様々な施策の開発を行っていますが、1つ1つの施策の目的をしっかり理解できているだろうか?と思わず自問自答してしまいました。 目的を理解していなければ、顧客へ届ける価値に紐づくデータがなんであるかも分かりません。ここはチームでも改めて考えてみたいと思います。

後半の「今後の展望」ではシステム担当とビジネス担当が同じデータを見てサービス価値向上に努めていきたいというお話がありました。 これはDatadogが掲げる「Datadogを通じて同じデータを共有し、部門の壁を破壊する」というコンセプトともマッチするものだと思います。 発表の中でも触れられていたダッシュボードの共有機能も今まで使ったことがありませんでしたが、とても便利な機能ですね! この機能を使えばDatadogのアカウントを持っていないユーザーにも気軽にダッシュボードを共有することができます。 自分自身も部門や職種の壁を感じることは多く、ビジネスサイドがどのような数値を追っているのか明確には分からないというのが正直なところです。 開発サイドとビジネスサイドが同じデータを見て、同じ目標を追って施策を打てるように働きかけていきたいと思いました。

docs.datadoghq.com

ワークショップ

午後はワークショップ「APMと分散トレーシング - 高品質なソフトウェアの提供」に参加しました。講義スタイルではなく、Datadog Learning Centerでワークショップ用のコースを1人で進めていき、分からないことがあれば個別に質問するスタイルでした。 Datadogを利用してオブザーバビリティを高めることで、いつどこで何が起こったのかを把握することができます。

ワークショップの内容に入る前に簡単にAPMとオブザーバビリティについて簡単に説明します。

APM(Application Performance Monitoring)

APMアプリケーションのパフォーマンス監視機能のことです。アプリケーションのパフォーマンスと信頼性を監視、トラブルシューティング、最適化することが可能です。APMは、アプリケーション内の各リクエストの流れを詳細に追跡し、ボトルネックやエラーの特定、パフォーマンス向上に役立ちます。 より詳細な内容については公式を参照ください。

docs.datadoghq.com

オブザーバビリティ(Observability)

オブザーバビリティ(Observability)とはシステムやアプリケーションの内部状況を外部から観測可能にすることです。つまりアプリケーションの中でいつ・どこで・何が起こったのか把握することを可能にします。 オブザーバビリティの実現には以下の三つを収集する必要があります。

  • ログ
  • メトリクス
  • トレース

ログはアプリケーション内で発生したイベントの記録です。エラーログやアクセスログなどが該当します。
メトリクスはアプリケーションのパフォーマンスやリソース使用量を定量的に計測したものです。CPU使用率やエラーレートなどが該当します。
トレース(分散トレーシング)はリクエストがシステム全体でどのように処理されるかの流れを追跡するものです。リクエストに付与されたユニークなトレースIDを元に、処理時間などの情報を記録・収集します。

ワークショップの内容

ワークショップの内容は主に以下の通りです

  • APMデータを収集するためにDatadog Agentを設定する
  • RubyのアプリケーションにAPMを構成する
  • PythonのアプリケーションにAPMを構成する
  • Datadogを使ったアプリケーションのデバッグ
  • ボトルネックを特定する
  • 最適でないSQLクエリの検出する
  • アラート設定を追加する
  • 継続的プロファイリング
  • ダイナミックインスツルメンテーションによるオブザーバビリティの向上

今まで知らなかった機能の中で「これいいな!」と思ったものがダイナミックインスツルメンテーションのプローブ機能です。 プローブを使用すると、プログラムの実行を停止することなく、コード内の特定のポイントからデータを収集することができます。イメージとしてはアプリケーションを止めずにデバッグできる感じです。またプローブの設定をするためにリリースする必要はないため、不具合調査のためにどうしてもこのポイントのデータをみたい!という時にコード内にログを仕込んでリリースする...などという手間がなくなります。 ただし現時点(2024/11/22現在)でダイナミックインスツルメンテーションのサポートはPython、Java、.NET、PHP で構築されたアプリケーションに限定されているなど、環境の制限があることに注意です。

docs.datadoghq.com

余談

ご飯

イベントではなんと朝昼夕の3食が提供されました! 朝食はパンやハム、チーズに加えてフルーツも盛りだくさん

朝ごはん食べると頭がシャキッとしますね!

夜は懇親会 他社の方とSRE文化についてお話したりと有意義な時間を過ごすことができました。

立食形式で他社の方と気軽に交流することができました

Datadogのマスコットキャラクター「Bits」のチーズケーキ 可愛すぎて食べるのが勿体無い。。。(※3つ食べました)

ワンコ好きにはたまらん可愛さ

AWS GameDay

お昼休みはAWS GameDayのスピードランに挑戦しました。 課題としてAWS LamdaとDatadogを連携したオンラインストアのアプリケーションが用意されており、設定のミスや問題点を見つけて修正していくという流れでした。 普段AWS Lamdaを使うことがないので解けるか心配でしたが、チームでも参加できましたしDatadogの方がサポートでついてくれていたので楽しく取り組むことができました!

Datadog認定プログラムを新たに資格取得支援制度の対象へ

レバレジーズのスキルアップ支援制度の一つに資格取得支援制度があります。これは業務遂行に必要・有益な資格について、受験費用や年間登録料、更新手数料を会社が補助してくれる制度です。 Datadogの認定プログラムは元々支援対象に入っていませんでしたが、Datadog Summit Tokyoの中で認定プログラムの紹介があったこともあり、業務に有益であると考えて追加申請を行いました。その結果無事に支援対象に追加されたため、Datadogのスキルアップの一環として認定プログラム受験がしやすくなりました!

まとめ

Datadog Summit Tokyoは想像以上に色々な情報を得ることができて有意義なカンファレンスでした。Datadogって色々な機能があるけど全然使いこなせていないな、、、という意識から、監視ツールとしての機能はもちろん、部門の壁を破壊するプラットフォームとしての役割を果たしてくれる協力なツールであるということに気がつきました。 特にダッシュボードを活用したデータの可視化は非常に有用であると感じたため、今後チームでも取り組もうと考えています。他にも今回は触れていませんがSRE文化の醸成に関するセッションなども非常に興味深く、どのセッションも学びのある有意義なものでした。ぜひ次回の開催にも参加したいです!

レバレジーズにはエンジニアのスキルアップを支援する様々な制度があり、またそれを活用して様々な挑戦を楽しむ開発メンバーがたくさんいます! そういったメンバーと一緒に仕事をしたい方はぜひエントリーお願いします!

recruit.leverages.jp

Tech Leverages 月間技術活動レポート 8,9月号

8,9月中に、レバレジーズが関わった技術イベントのご紹介です。 自社イベントのみならず、共催イベントの開催、イベント登壇と多様な関わり方で、合計6件のイベントに参加しました!

主催・共催技術イベント

TSKaigiサブイベント #1 フロントエンド

8/6に、弊社の拠点である渋谷一丁目支店のセミナールームで、TSKaigi運営チームが開催する定期イベントの開催をしました。「フロントエンド」をテーマとし、TSKaigi2024の選考委員でもある”うひょさん”にトークを行っていただきました。

SREの組織と文化

9/6に、コミューン社、 弁護士ドットコム社の方を招いて、「SRE組織と文化」がテーマのLTイベントを開催しました。各社のSREが、実際に業務でどのようにSRE文化の浸透と醸成を行ってきたのか、赤裸々にお話ししていただきました。

Tech-Debt Meetup ~技術的負債と向き合うLT Night~

9/12に、渋谷スクランブルスクエアにある弊社の本社にて、「技術的負債との向き合い方」がテーマのLTイベントを開催しました。

OPTiM × レバテック ビジネス価値を追求する開発生産性

9/4に、OPTiM社とレバテックの共催でLTイベントを開催しました。OPTiMとレバテックでの 開発生産性の向上の具体的な取り組みについて発表しました。

イベント登壇

SRE MeetUp

レバテック開発部の金澤が、SRE MeetUpにて登壇しました。

speakerdeck.com

DevRel Guild Conference Mini

レバテックのDevRelメンバーの山本が、DevRel Guild Conference Miniに登壇しました。

speakerdeck.com

イベントスポンサー

SRE NEXT 2024 シルバースポンサー

8/3に行われたSRE NEXT 2024にて、レバテック株式会社がシルバースポンサーとして協賛しました。

We are hiring!

レバレジーズ株式会社では一緒にサービスを開発してくれる仲間を募集中です。 もしご興味を持っていただけたなら、こちらのページからご応募ください。

AIボット開発に挑戦!レバレジーズの開発サマーインターン2024レポート

自己紹介

レバレジーズのテクノロジー戦略室、AI/MLチームで二週間の就業型サマーインターンシップに参加した、早稲田大学創造理工学部経営システム工学科3年の住井と、慶應義塾大学理工学部情報工学科3年の小山です。

インターンシップの内容

僕たちは、NALYSYSというツールの問い合わせ機能を充実させるため、以下の二つのプロダクトを作成しました。

  • QAbot
  • QAbotの精度評価基盤.

作業を二人で分担することにし、QAbotのアプリ面の開発を住井、内部のRAGの精度向上・評価、QAbotの精度評価基盤の作成を小山が担当しました。メンターの方からいくつかのテーマを提示していただき、その中から我々の興味と能力に合わせて選択しました。

一日の流れは、以下の通りでした。

  • Good&New
  • チーム朝会
  • 作業
  • ランチ
  • 作業
  • 1on1

Good&Newはチームを跨いだアイスブレイクのようなもので、他チームの方と接する機会の一つでした。また、毎日1on1を実施していただいたので、相談もしやすく、サクラステージ内にある別オフィスの見学だったり、スクランブルスクエア内の本社での作業日を設けるといったような気軽な要望もスピード感を持って取り入れてくださいました。

技術スタック

今回は以下の技術スタックを使用しました。

QAbot

  • フロントエンド
    • React(Typesript)
  • バックエンド
    • Python
  • インフラ
    • AWS
  • UI
    • TailwindCSS
  • IaCツール
    • Terraform

評価基盤

  • フロントエンド
    • streamlit
  • バックエンド
    • Python
  • インフラ
    • AWS

QAbotのアーキテクチャ図は以下の通りです。

難しかったこと

触れたことない技術

NALYSYSの既存の技術スタックに合わせるため、今まで触れたことのない技術をいくつか使うことになりました。具体的には、React、Terraform、AWS Kendra、AWS Amplifyなどです。
特にTerraformは複雑で、最初は理解するのに苦労しました。しかし、最後の追い上げでなんとか形にすることができました。
これらの技術はReactやTerraformをはじめ、どれも現在多くのアーキテクチャで採用されているものです。今回のインターンシップはこれらの技術を学び始めるとても良いきっかけになりました。

RAGの精度と応答時間

今回は、精度も重視していたため、HyDE(Hypothetical Document Embeddings)、RAG-Fusion、Rerank、といった手法で精度改善を比較検討しました。しかし、実際にRerankやクエリ拡張、クエリ変換を処理に挟むと応答時間が増えることでUXの低下が著しく、精度向上とのトレードオフに悩まされました。シビアにUXを考える体験は、個人開発との違いを大きく感じました。

精度評価

実際にプロダクトに組み込むにあたり、一定の精度を担保する必要があったため、精度評価と精度改善に取り組みました。しかし、課題に着手した時点でNALYSYSには、評価に使用できるようなQA集が存在しませんでした。そのため、質を担保しつつ、評価用のQAを新たに作成する必要が生じました。

この課題に対し、単に現状の問題を解決するだけでなく、将来的な展開も見据えた解決策として、今後の機能拡張時や他サービスでのQAbot導入時にも活用できる、自動で評価用データセットの作成からRAGの評価まで行うツールを開発しました。

また、QAbotの評価の仕方自体も前例が少なく、難しい点でした。今回のRAGでは、プロダクトのヘルプページの内容を参照するようにしていたので、この時、特定のソースからQAを生成することで、自動生成のQAにGround Truthを与え、検索性能を評価しました。また、RAGの出力が「正確な回答」「一部不正確」「回答できていない」「間違った情報を含む」、のどれに相当するかを複数のLLM(GPT-4o, Claude)で評価し、スコアをAveragingすることで回答生成の評価を行いました。

社内・AI/MLチームの雰囲気

インターンシップの期間中は毎日出社しました。メンターの方とのコミュニケーションを密に取りながら作業を進めることができ、会社全体やAI/MLチームの実際の雰囲気を直接体験することができました。エンジニアは、ストレスフリーな環境で、チームの方も和やかで、非常に質問しやすいオーラを放っていました。

テクノロジー戦略室の室長の竹下さんは常にバランスボールに乗って作業しているくらいには自由でした。エンジニアのフロアであっても、和気藹々とした雰囲気があり、居心地が良かったです。

こういった環境のおかげでインターンシップでの学びを最大化することができたと感じています。

ランチ

ランチは、毎日別のチームの方に連れて行っていただき、渋谷のランチに詳しくなれた気がします。最終日ランチは宮下パークの筋肉食堂でした。フルリモートのインターンも多い中、出社してランチの機会があったことで会社の生の雰囲気が良く感じ取れた気がします。
AI/MLチームの社員の方は多種多様な企業から転職して来ており、前職のお話や、前職と今の違いだったりも聞く機会もありました。
一つのインターンシップで単なる技術的な学び以上の発見もあり、ランチタイムに感謝。

終わってみての感想

インターンシップ期間中に一定のまとまった成果物を完成させることができたのは、大きな自信につながりました。また、この10日間でいくつもの新たな技術に触れ、自分の技術スタックが増えるきっかけになりました。今回支えてくださった社員とメンターの方々、本当にありがとうございました!
レバレジーズのエンジニアがどういった働き方をしているのかだったり、実際の雰囲気を感じ取れるインターンシップでしたので、興味のある方はぜひ応募してみてください!!

recruit.leverages.jp

レバレジーズではAgile開発をやっていないのか?

はじめに

こんにちは、今年(2024年)の7月からレバレジーズにJoinした藤咲です。

私はこれまで「AgileでVUCAの時代をHappyに!」をモットーに、様々な開発チームにコーチングしてきました。 ですので、レバレジーズの「顧客の創造を通じて関係者全員の幸福を追求し、 各個人の成長を促す」という企業理念に非常に共感できました。 またグループ会社であるレバテックでは、昨年設立されたCTO室がAgile開発推進の役割も担うため、そこの所属となりました。

まだJoinしてから2ヶ月半というタイミングではありますが、レバレジーズでのAgile浸透へのFirst Stepについてご紹介します。

Agile CoP、はじめました。

レバレジーズではAgile開発に取り組んでいるものの、なかなか浸透しない上に効果がイマイチわからないという声が上がっていました。実際に各開発チームの進め方を見ていると、自信をもってスクラムをやっているチームと、なんとなく用語を使っているだけのチームが混在していました。

そこで、まずはAgile CoPというコミュニティを作ることで、組織内での知見を共有することから始めることにしました。

弊社におけるAgile CoP(CoP: Community of Practice)の位置付け

Agile CoPを作ろう!と声をかけたら40人も集まったが、、、

まずは私自身が発起人となり、レバテックを含むレバレジーズグループの開発者全体に向けてAgile CoPを作ろうとをSlackで投げかけると、全体の約20%にあたる40名もの方が参加意思を示してくれました。 そしてKickOffを実施したところ、多くの方がAgile開発の実践経験者であることがわかりました。

ところが、皆さんの自己紹介を聞いていると、

「なんちゃってAgile開発」

「Agileっぽい開発」

「Agile開発と呼んでいた何か」

という表現が非常に多かったんです。

つまり、Agile開発を実践してはいるけれども、今自分たちがやっている開発を自信を持ってAgile開発だと言えない状況であるということがわかりました。

例えば、

  • スクラムで開発している(?)けれどもスクラムマスターはいない
  • スプリント単位にインクリメントの価値を高められていない
  • 事業部を巻き込めておらず開発チームだけで回している

といったように。(まぁ、Agileあるあると言えばそうですが。)

Agile CoPをAgileに運営する

現状は把握できたので、どうすればAgile CoPの活動を通して「自信を持ってAgile開発を実践している」と言える状態にできるか、を次に考える必要があります。 これは今や常套手段でもありますが、弊社ではコミュニティ活動自体をAgileに進める、という方法をとっています。

具体的には、最低限以下のルールで運営を開始しました。

  • 週に1回30分のセッションを開催(1週間のイテレーション)
  • テーマは悩みや相談ごとをメンバーが持ち寄り(バックログ)
  • 各回の終わりに次回のテーマを1つのみ決める(WIP制限:1)
  • 進め方自体の改善提案も常にWelcome(ふりかえり)
  • みんなが主役!(マインドセット)
  • 管理はAsanaボードで!(チケットドリブン)
    Agile CoPタスクボード(Asana)

なんちゃってAgile開発からの脱却を目指す今後の取り組み

まだまだ立ち上がったばかりでご覧の通りバックログも積み上がっていない状態ですが、千里の道も一歩から、ということでスモールにスタートを切っています。 各チームの悩みやうまくいかいない状況に対して、コミュニティでの活動を通して解決のヒントや糸口を掴み、自ら改善していく。そんなメンバーが集まるコミュニティを目指し今後も活動していきます。

一方で、コミュニティ内だけでは解決しきれない課題というのが既にいくつか散見されています。

具体的には、

  • スクラムマスターを目指せるキャリアパスやポジションがない
  • 事業部を巻き込んだ形での推進体制が作れていない

といった、組織の制度や体制に関わる問題です。

そこはCTO室として動かなければならない領域でもあるので、コミュニティと経営をつなぐ立場として、中長期的な対応にもチャレンジしていきます。

レバレジーズの開発メンバーのみんなは、より良い実践をしていきたいというマインドは既に十分に持っています!

そういった前向きなメンバーと一緒にチャレンジしたいという方、ぜひ私たちとHappyに働いてみませんか? recruit.leverages.jp

テックフェス2024夏 レポート

はじめに

こんにちは。今年の4月にレバレジーズ株式会社に入社しました古川修慈です。

本記事では 8/8(木) に開催されたテックフェスという社内イベントの様子をご紹介します。
BuySell Technologie社CTOの今村氏による基調講演や、レバレジーズグループが持つ技術的な課題とその解決方法を紹介するセッション、事業部の垣根を越えて楽しくゲームをする様子を紹介するので、ぜひ最後までご覧ください。

テックフェスとは

レバレジーズグループに所属するエンジニアを対象に、社内で半年に一度行われているイベントです。一日を通して、技術的な課題解決事例やノウハウを共有したり、トレンドの技術を解説することで、社内の全てのエンジニアの技術力を伸ばすことを目指します。
今年の夏は、「次代をつくる」という意味を込めて、「Let’s Hack Leverages 〜そして伝説へ〜」というテーマで開催しました。

基調講演

今回はBuySell Technologie社CTOの今村氏に「CTO視点で語る、これからの時代に活躍するエンジニア像について」というテーマでお話していただきました。

登壇者紹介

今村雅幸 氏

  • 株式会社BuySell Technologies 取締役CTO
  • 一般社団法人 日本CTO協会 理事
  • ファインディ株式会社 社外取締役
  • 株式会社イベンターノート代表取締役
  • 投資先 技術顧問

ヤフーに新卒エンジニアとして入社後、新規事業や特許取得に追従。独立しVASILYを起業後、取締役CTOとして200万人以上が利用するファッションアプリの開発をリードする。M&AでZOZOへ売却後は、ZOZO(旧ZOZOテクノロジーズ)に執行役員VPoEを経てCTOへ就任。ZOZOTOWNリプレイスや400人を超えるエンジニアの採用・教育、情報システム、セキュリティなど幅広くDXを推進する。その後、BuySell Technologiesの取締役CTO就任。全社のテクノロジー戦略や研究開発、エンジニアリング組織マネジメントなどテックカンパニー化を推進する。

コンテンツ

「素晴らしいエンジニア」の定義から始まり、それがどのような要素から構成されるかを公演していただきました。参加されていたみなさんは今村氏のお話に一気に引き込まれているようでした。
その後に、具体的にどう素晴らしいエンジニアになるかを語っていただきました。圧倒的なインプットというすぐ業務に活かせるものから、技術トレンドを抑えるというキャッチアップ的なものまで、さまざまなTipsを紹介してくださいました。
マクロな視点で個人的に印象に残った言葉が「結局事業貢献を作るためには、自分達が良いと思う文化を作っていく必要がある」です。もしそれができれば、事業貢献が生まれ、新たに良い文化が生まれるというサイクルが生まれる、という点も教えていただきました。


セッション

発表者のみなさん、ありがとうございました。

JestランタイムをHackしてCIの実行速度を3倍にした話 (レバレジーズ NALYSYSグループ 桐生 直輝さん)

「APIが遅い」という問題に対処するために、

  • Jestのソースコードを読み、原因を突き止める
  • Jestの制約を掻い潜って高速化する

の順序で発表をしてもらいました。
単純な事例だけでなく、Jestのソースコードを読むコツや、一見意味がわからないエラーの原因を突き止めるための方法も紹介していただきました。

生産性改善を徹底的に考え、実践してみた (レバレジーズ アジャイルエフェクトチーム 西 慎一郎さん)

自分のチームで実際に取り組んだ生産性改善の具体的なTipsとツールを紹介してもらいました。
具体的には、Miro、 Cursor、Gamma などを用いたメソッドを共有してくれました。
「0から作ることを極力やめる」という信念のもと、AIといった最新の技術から、USMやモププロなど一般的なプラクティスまで広く取り入れていた点が印象的でした。

LT

発表者のみなさんありがとうございました。
今回はNALSYSチームから多くの方が発表がありました。
5分という短い時間でしたが、課題から解決策までわかりやすくまとめた発表が多かったです。

以下全てのタイトルと発表者です。

  • 大量ユーザーへのSlack通知を実現せよ (レバレジーズ NALYSYSグループ 岡本 侑樹さん)
  • 競艇自動予想アプリつくってみた (レバレジーズ CXグループ 田上 達也さん)
  • AgileでVUCAの時代をHappyに! (レバレジーズ CTO室 藤咲 浩さん)
  • FEテストの技術選定 (レバレジーズ NALYSYSグループ 松本 悠太郎さん)
  • GCP小話 (レバレジーズ NALYSYSグループ 香川 淳さん)
  • ムダヅモなきテスト戦略 (レバレジーズ NALYSYSグループ 下畑 剣一郎さん)

テックバトル

参加されたみなさんありがとうございました。
テックバトルでは運営チームが作った技術用語の百人一首を行いました。経験度合いに左右されず楽しめる内容だったため、大いに盛り上がりました。


懇親会

写真を取ろうと思っていたのですが、盛り上がりすぎてうっかり忘れてしまいました。
技術のことからプライベートのことまで、事業を横断して幅広い交流が生まれていました。

最後に

今回の記事では、テックフェスのレポートを書かせていただきました。LTという短時間の発表とは思えないほど内容が濃く、セッションではまさに事業部のナレッジが凝縮されていました。基調講演では、エンジニアとしての生き方を考えることができました。

レバレジーズは、社内で技術ノウハウの共有を行なうイベントはもちろん、外部から著名な方をお呼びして貴重な話を聞く機会を積極的に設けています。 レバレジーズに少しでも興味を持っていただけた方は、こちらからエントリーをお願いします。

recruit.leverages.jp

Tech Leverages 月間技術活動レポート 7月号

7月中に、レバレジーズが関わった技術イベントのご紹介です。 今月は、イベントへのスポンサーと登壇をメインに7件ありました。

イベントブース出展

Developer eXperience Day 2024

CTO協会が主催しているイベントで、レバテックがゴールドスポンサーとして協賛しました。ブースも出店し、七夕が近かったので「レバテックに願いを」という、エンジニアの願いを短冊に書いてもらう企画も行いました。数多くの登壇者、参加者の方に書いて貰い、大盛況でした。お書きくださった皆様、ありがとうございます。

Platform Engineering Kaigi 2024

こちらもゴールドスポンサーとして協賛し、ブースの出展をしてきました。こちらも、「レバテックに願い」を実施し大盛況でした。

イベント登壇

Developer eXperience Day 2024: 経営層を開発者体験向上にコミットさせる方法論 ~ Developer eXperience Day 2024 ~

TiDB User Day 2024: TiDBは銀の弾丸になるのか? ~ レバテックの課題と新たな挑戦 ~ TiDB User Day 2024

Platform Engineering Kaigi 2024: いつPlatform Engineeringを始めるべきか?〜レバテックのケーススタディ〜 Platform Engineering Kaigi 2024

Developers Summit 2024 Summer: 開発と事業を繋ぐ!SREのオブザーバビリティ戦略 ~ Developers Summit 2024 Summer ~

D-Plus Tokyo #4: ~しくじり事例から学ぶ!開発生産性の取り組みLT会~ FourKeysだけで開発生産性 は測れないと気付くまでの話

おまけ

【レバテック開発部に聞いた】ITエンジニアにおすすめの本18選!という記事も公開しています。良ければこちらの記事もお読みください。

We are hiring!

レバレジーズ株式会社では一緒にサービスを開発してくれる仲間を募集中です。 もしご興味を持っていただけたなら、こちらのページ からご応募ください。

Elasticsearchによるマイクロサービス間検索の基盤をNetflixの事例を参考に構築した話

はじめに

レバレジーズシステム本部 NALYSYSグループ テックリードの桐生です。

NALYSYSとは、ピープルマネジメントを支援する「NALYSYSモチベーション管理」や労務業務を効率化する「NALYSYS労務管理」などの機能を多数持った、人事労務に関わる課題を解決するためのSaaSです。

そんなNALYSYSでは、今年4月に新たに「NALYSYS従業員ライブラリ」をリリースいたしました。こちらのプロダクトではマイクロサービスを跨いだ検索を実現する必要があったのですが、これにより今までにない設計上やパフォーマンス面の問題に直面し、また短い納期の中でこの問題を解決する必要がありました。今回の記事では、これらの問題をNetflixの事例を参考に爆速で解決に導いた取り組みをご紹介いたします。

NALYSYS 従業員ライブラリについて

現在のNALYSYSは、「NALYSYS Admin」に登録された従業員の基本情報を中心として、それにぶら下がる形で「NALYSYSモチベーション管理」や「NALYSYS労務管理」などに追加の情報を保持しています。同じ従業員の情報であっても分野ごとに異なるプロダクトに保存されているため、これらのデータを活用するには複数のプロダクトを行き来する必要があり、ユーザーにとって不便な状態となっていました。

これを解決するために企画されたサービスがNALYSYS従業員ライブラリです。

従業員ライブラリが新たにNALYSYSに加わることで、複数のプロダクトに分散している情報を集約して閲覧することができ、プロダクトをまたいだ従業員の検索も行うことができるようになります。

全プロダクトのデータを集約するという性質上、権限やパフォーマンスに関して今までにない課題に直面することとなりました。また、今回は企画立案〜リリースまでが3ヶ月という短いスケジュールだったため、その期間で実現可能な方法を選ぶ必要がありました。 本記事では、直面したさまざまな課題の中から「プロダクト横断検索」に関わる部分をピックアップしてお届けします。

マイクロサービス間検索における課題

NALYSYSのバックエンドではマイクロサービスアーキテクチャを採用しており、それぞれのマイクロサービスごとに独立したデータベースを持っています。(マイクロサービスアーキテクチャでは各サービスの独立デプロイ可能性を確保するためにデータベースを分離する必要があります)このため、マイクロサービスを跨いだ検索を行おうとすると、検索に利用したいデータが複数のデータベースに分散しているという点が問題となります。具体的には、愚直に検索を実装する場合、複数のマイクロサービスに対してそれぞれデータ取得操作を行なった後、それらを集約して検索結果を構築する必要があります。特に、特定のマイクロサービスに関する検索条件がゆるい場合には大量のデータをロード・転送しなければならないため、データ量に対してスケールしにくくなってしまいます。実際に既存のプロダクトでも在籍状況+プロダクト固有の情報で検索する場合などに同様の問題に直面し、パフォーマンスが低下していました。

今回は、この問題を根本的に解決するため、単一の検索用データベースに全てのサービスのデータを集約することとしました。具体的には、以下のNetflixの事例を参考に、マイクロサービス間に分散したデータをElasticsearchに集約してインデックス化し、横断的な検索を実現します。

netflixtechblog.com

検索システムの構成

構築した検索システムの概要を以下に示します。

先ほど紹介したNetflixの事例と同様、Elasticsearchの検索インデックスに各サービスからかき集めた従業員の情報を合成して登録していきます。実際にユーザーが検索リクエストを送った際には、従業員ライブラリのマイクロサービスがそれをElasticsearch用の検索クエリに変換して検索を実行します。検索処理は全てElasticsearch内で完結し、DBのスキャンが必要ないため高速な検索処理を実現することができました。

インデックスの更新方法について

Elasticsearchに登録されている従業員データは元々のサービスからコピーされたものであるため、元のデータが更新された場合これを随時インデックスに反映していく必要があります。

先ほどのNetflixの事例では、各マイクロサービスが送出するデータ更新イベントをトリガーにしてElasticsearchへのデータ再登録を行うという手法をとっていました。Netflixのシステムでは元々Kafkaに変更イベントを送出する仕組みが整っていたため、このような手法を少ない労力で実装できたようです。

一方、NALYSYSにはNetflixで行われているような変更イベントを流す仕組みがありませんでした。マイクロサービス間を疎結合にするという観点で、Netflixと同様にメッセージベースのやり取りを実装するのが望ましくはあったのですが、開発期間が短い中でそのような仕組みを設計・構築する余裕がなかったため、今回は代わりにLogstashのJDBC Input Pluginを活用した変更検知を実装しています。

JDBC Input Pluginを用いると、データベースに対して定期的にクエリを発行し、データの差分を取り込むことができます。以下の公式ブログに詳しい実装方法が説明されています。

www.elastic.co

この方法を用いる場合、Logstashのデプロイおよび必要な設定ファイルの作成を行うだけでインデックスの自動更新を実装することができるため、自前で更新のための仕組み(差分イベント送出・検知)を実装するのに比べて大きく工数を削減することができます。一方で、各サービスのデータベースの構造とLogstashの設定ファイルが密結合になるためメンテナンス性が低下するという問題も抱えています。今回は短納期を実現するために必要な負債としてこれを受け入れることとしました。

まとめ

ここまで述べた取り組みによって、高速な横断検索機能を予定期間内に作り上げることができました。今回は従業員ライブラリに特化した仕組みとなってしまったので、今後は他のプロダクトにもこの仕組みを展開しつつ、メッセージベースの変更検知によってサービス間の結合度を下げる取り組みも行っていきたいと考えています。

レバレジーズでは、ソフトウェアの力で人事労務に関わる課題解決に挑戦する仲間を募集しています!ご興味のある方はぜひ採用サイトをご覧ください!

Tech Leverages 月間技術活動レポート 6月号

6月中に、レバレジーズが関わった技術イベントのご紹介です。
自社開催から、共催、スポンサー、運営の手伝いと多様な関わり方で、合計5件のイベントに参加しています!

主催・共催技術イベント

イベントグループ「Tech Leverages」始動

イベント開催プラットフォームのconnpassにて、Tech Leverages グループをリニューアルしました。今後弊社で開催するイベントはこちらで公開していきますので、興味がある方はグループ登録をお願いします。

渋谷一丁目支店・初技術イベント: Agile Effect MeetUp なんちゃってスクラム開発からの脱却

6/27に、弊社の新しい拠点である渋谷一丁目支店のセミナールームで、Agile Effect MeetUpを開催しました。スクラムマスターの服部 翔太氏や、株式会社aby CTO 向後 澄哉氏にご参加いただき、パネルディスカッションを行いました。

イベントブース出展

AWS Summit 2024 ブース出展 & ミニセッション登壇

6/20,6/21に幕張メッセで開催されたAWS Summit 2024で、レバテックプラットフォームでのAmazon QuickSightの活用事例を紹介するブースを出展しました。

また、ミニステージにて、弊社エンジニアの塚原と内藤が、技術の詳細の発表も行って来ました。

イベント登壇

UX Design Conference 2024:『VoLT:レバテックのデザインシステム』電光石火の構築プロセスと目指す未来

弊社CTO室テックリードの河村とプロダクトとデザイン責任者の山本が、UX Design Conference 2024で登壇しました。

イベントスポンサー・手伝い

日本CTO協会 新卒合同研修 会場スポンサー

6/19に日本CTO協会様が実施されている合同新卒研修で、会場スポンサーとしてレバレジーズ本社のセミナールームを提供いたしました。今回の内容は「インテリアデザインを通したアジャイル開発の体験」で、グループワークを通してアジャイル開発がどのように進むかを疑似体験するというものでした。

ScalaMatsuri2024 運営スタッフとして手伝い

6/8,6/9に、国際交流館 プラザ平成で開催されたScalaMatsuri2024に、弊社テクノロジー戦略室室長 竹下が運営スタッフとして開催を手伝ってきました。コロナ後初のフルリアル開催となり、日本中のScala使いが集結しました。

また、竹下が、酒を飲みながらLeetCodeを解くという「アルコーダー」の発表?を行ってきました。

We are hiring!

レバレジーズ株式会社では一緒にサービスを開発してくれる仲間を募集中です。 もしご興味を持っていただけたなら、こちらのページからご応募ください。