自分のアイデアが世に出る瞬間を体験！レバレジーズサマーインターンシップの全貌公開！

こんにちは。 レバレジーズのシステム人事戦略室に所属している井上です。普段は新卒採用や採用広報に関わっています。 システム人事戦略室についてはこちら（↗︎）

レバレジーズでは2026年入社のエンジニアを対象にサマーインターンシップを開催しました！毎年開催しているビジネス職向けのインターンシップは、選考通過率が1％前後ですが、今回はそのエンジニアバージョンです。

レバレジーズのサマーインターンは、単なるエンジニア体験ではなく、ビジネス全体に関わる刺激的な機会です。実際の開発だけでなく、課題設定やデータ分析にも触れられ、社会や人の課題解決に貢献するレバレジーズの事業を肌で感じることができます。

インターンの様子を一部公開しますので、レバレジーズのエンジニアサマーインターンについて興味がある方がいればぜひご覧ください！！！

サマーインターンの概要

• 開催日程：9月27~29日
• 開催場所：東京 渋谷本社
• 参加学生人数：9名
• メンター人数：6名
• グループ数：3グループ
• グループ内訳：学生3名・企画メンター1名・技術メンター1名

テーマは、「スカウトサービスの価値を最大化する機能を企画・開発せよ」で実施しました。

メンター紹介

• ベストルーキ賞を受賞した社員
• 事業責任者
• PdM
• PM
• テックリード

など、現場の最前線で活躍するメンバーが直接フィードバックを行い、濃密な学びの機会を提供しています！

参考記事（ベストルーキー賞受賞社員・HRテック事業部 事業責任者）

メンター 一部紹介

レバレジーズのインターンに参加するメリット

自分のアイデアが実際のプロダクトに反映されるかも？！

提案したアイデアは、実際のプロダクトに採用される可能性があります。 インターン終了後は皆さんのアイデアが開発チームに共有されるため、自分の考えがリアルなサービスに影響を与える経験を積めます。

「自分のアイデアが世の中に届くかもしれない」そんなリアルな経験を、レバレジーズのサマーインターンでは体験することができます！！

ユーザー視点でのプロダクト作りが経験できる

レバレジーズのエンジニアは、

• コードを書くだけ
• 言われたものと作るだけ

ではなく、何を、なぜ、どのようにして作るのかをユーザー視点で課題を捉え、最適な解決策を考えるのが特徴です。

そのため、エンジニアは開発だけでなく、

• マーケティング
• ユーザーヒアリング
• デザインディレクション

など、幅広く事業全体に関わります。 マーケター、デザイナー、セールスなどの他職種との連携を密にすることで、顧客の声をダイレクトにサービスに反映できるのが、弊社のエンジニアの面白みです。

インターンでは、ユーザー属性ごとのデータを分析して課題を特定するところから始めるため、レバレジーズのエンジニアだからこその「ユーザー中心のプロダクト作り」を経験できる絶好の機会です。

サマーインターン プログラム紹介

1日目：プロダクト理解と課題設定

1日目のスケジュールは下記の通りです。

• サービス・プロダクト理解
• ペルソナ理解
• データ分析
• 課題解決のアイデア出し
• 機能企画

実際にスカウトアプリの管理画面を操作し、ユーザー属性ごとの開封率や利用状況などのデータを分析しました。 エンジニアリングだけでなく、ユーザー行動データをもとに仮説を立て、ビジネスインパクトを考慮しながら重要な問題を見極めるプロセスを体験することができます！ 「ただ作るだけ」で終わらない、データに基づく意思決定の重要性を学べるのが、このインターンの大きな特徴です。

2日目：機能開発

1日目に設定した課題に対する解決策を形にするために、開発に集中してもらいました。 弊社の技術メンターがサポートに入り、ペアプログラミングを通じて実際にコーディングを行います。 エンジニアとして技術的な課題に向き合うだけでなく、チームメンバーと共に問題を解決するプロセスを体験することで、開発の現場をより深く理解することができました。

3日目：発表と振り返り

2日目に開発した機能をチーム内で発表し、フィードバックをもらいます。

審査基準は下記の3つです：

• ニーズの質
• 事業へのインパクトの大きさ
• プロダクトの質

最終的には、

• 開発部長
• PdM
• VPoE

この3名の審査員によって、最終的な評価が行われました。 経営視点からのフィードバックを直接受けることで、ビジネス感覚も身につけられる貴重な体験です。 ワーク終了後は、各チームのメンターと1on1の振り返りを実施し、学んだことや改善点を共有しました。

サマーインターンの様子

懇親会

プログラム終了後の懇親会では、学生たちと社員がリラックスした雰囲気の中で交流しました。 3日間という限られた時間の中で、企画〜開発まで一貫して対応するという厳しい条件だったこともあり、メンターと学生が互いに「一緒に困難を乗り越えた仲間」という関係が築けていました。 開発の裏側や業務のリアルな話題に加え、互いのプライベートの話などもして大いに盛り上がるなど終了後には「もっと話したかった！」という声も多く、双方にとって学びのある時間となりました。

参加者の声

今年のインターンシップでは、学生たちに実際のプロダクト開発に取り組みながら、レバレジーズのエンジニアとして必要なスキルを身につける体験をしてもらいました。参加者からは、さまざまなポジティブな感想をいただきました！！ ここでは、その中でも特に好評だった点をいくつかご紹介します。

企画から実装まで、実務に近い体験ができた

「データをしっかり分析した上で次の手を打つということの大切さを学ぶことができた。」

「どのようなユーザーを対象にして、どんな課題を持っているのかと言うところを実践を通して学べて、自分のこれからの開発に貢献できると思う。また、プロダクト開発において、どのように道筋をたたて、思考して行くのかと言う部分が少しでも身につけられて、これからも実践していきたいと思った。」

メンターからの手厚いサポート

「超ハイレベルな技術力とビジネス力を持った方々と、自分との差分を感じることができた。」

「今まで参加したインターンの中では一番濃密だったし、サポートも手厚かった。心理的安全性が担保されていて、リラックスして臨めた。」

現場に近いリアルな課題に取り組めた

「実際に運用されているサービスの問題点を洗い出すことは新規事業を考えることとはまた別の面白さがあり、非常に学びがありました。」

「実際にプロダクトで使用している技術やコードを見ることができて、自分のこれから書くコードに反映できそうだと思いました。」

組織の文化や仕事への姿勢に触れることができた

「レバレジーズの仕事への姿勢に感銘を受けました。社員同士が本気で取り組んでいて、こんな環境で成長できるのはとても魅力的だと思いました。」

「ベンチャー気質でありながら、利他性のある人が多いのはイメージと違って好印象だった。人材ビジネスが大きな柱ではあるが、それ以外にもたくさんのチームがありそれぞれがプロダクトを持っているので、「人材系の会社」という第一印象が薄まった。」

最後に

レバレジーズのエンジニア組織は今後さらに強化・拡大を続けていきます。 そのため、課題の本質に向き合い、考え抜ける「未来の組織の核」となる人材を求めています。

また、今回のサマーインターンを通じて、参加者の中から実際に内定者が誕生しました！！！ インターンを通じて、レバレジーズでのキャリアをスタートさせる仲間ができたことは、このインターンシップを運営して本当に良かったと思える瞬間でした。

エンジニアリングはサービスの価値を形作る基盤であり、ビジネスを成功させるために欠かせない要素です。 「開発」だけで終わらず、その先の未来を創り出すレバレジーズのエンジニアリングチーム。インハウスの強みを活かし、他職種の仲間と共に事業を創造、改善、検証していける環境は、新卒エンジニアにとって大きな魅力だと考えています。

We Are Hiring!

新卒エンジニアの皆さんにも、様々な業務を通じて成長の機会を提供し、一緒に未来を切り開いていきたいと考えています。 このような価値観に共感し、「自分のアイデアで世の中に影響を与えたい」 そんな情熱を持ったあなたの応募をお待ちしています！

今年もサマーインターンシップを開催予定ですので、気になる方は下記サイトから応募してみてください〜〜！

◆レバレジーズ 2027卒新卒 エンジニアサマーインターン 応募フォーム

◆新卒採用ページ ◆エンジニア採用サイト

迷わないReactスタイリング設計：Panda CSSが導く最適解（Part1）

ごあいさつ

レバレジーズ株式会社 アジャイルエフェクトチームの田代です。

我々アジャイルエフェクトチームは、スクラムにおける様々なプロセスを可視化し、生産性改善に繋げるためのSaaSプロダクト「Agile Effect」を開発しています。
当プロダクトは、とあるPMの社員が社長に直接事業企画を提案したことがきっかけで誕生しました。昨年4月に事業が正式に立ち上がり、そこからわずか1年後の今年4月に正式リリースを迎えることができました。（レバレジーズは、アイデアを積極的に取り入れられる風土があり、意思決定の速さと挑戦を歓迎するカルチャーが色濃く根付いています！）

アジャイルエフェクトチームの特徴は「どのチームよりアジャイルを体現した組織」であることです。「スクラム改善のプロダクトを開発する上でアジャイルを体現し効率的にプロジェクトを進められるチームであることは大前提」というプライドの下、5名で事業をリードしています。
それぞれの得意分野や主な役割こそありますが、明確な役割分担はありません。日々の業務の中で、POが開発や設計に関わることもありますし、開発メンバーが企画・営業・マーケに関わることもあります。また、Agile Effectを活用することで全メンバーが主体となって改善サイクルを高速で回すことができています。

これにより高いアジリティを発揮し、
「定常的な週2〜3回ペースでのリリース」
「ユーザーから要望があった機能の1週間以内リリース」
などが実現できています。

我々がプロデュースする「Agile Effect」には、社内外でご利用いただいているスクラムチームの知見が詰め込まれており、今後も要望を取り入れながら、プロダクトを漸次的にアップデートし続けていきますので、ぜひ無料でご試用ください。
皆様のご利用をお待ちしております！

はじめに

早速ですが、エンジニアの皆様。

「フロントエンド開発」やっていますか？
「CSS」書いてますか？

当記事では、TypeScriptベースのスタイリングライブラリである「Panda CSS」のご紹介と、実運用で得た知見を共有いたします。
これらの問いに対して「YES」と回答した方であれば、学びに繋がる内容となっていますのでぜひご一読ください。

対象読者

• アプリケーションのフロントエンド開発に携わるエンジニア
  • 特に、スタイリングに関する内部品質で悩んでいる方
• Reactで新しくアプリケーションを作ろうとしている方
• Panda CSSの実運用事例について詳しく知りたい方

記事を通して得られること

• TypeScriptベースのCSSライブラリ「Panda CSS」について
• 他のスタイリング手法（CSS Modules/SCSS/Tailwindなど）とPanda CSSの比較
• 型安全なCSSやデザインシステム構築に役立つPanda CSSの基本知識
• 実際のプロダクトで運用する際に生じる課題と対処方法
• Panda CSSを使った際の開発効率向上や保守性アップの具体的なイメージ

以上の内容をカバーすることで、読者の皆様がPanda CSSの導入メリットを把握し、プロダクトのスタイリング設計をより快適に進められるようになることを目指しています。今後のフロントエンド開発に、少しでもお役に立てれば幸いです。

どう幸せになったのか

まず結論をお伝えすると、Panda CSSを採用したことで以下のような改善が実現し、開発体験が劇的に向上しました：

• 型安全なCSS：TypeScriptによるスタイリングで開発速度と保守性が向上。
• 宣言的かつ画一的なスタイリング：動的な値に基づくスタイリングが宣言的かつ1箇所に集約され、保守性/可読性が向上。
• DOMとスタイリングの責務分離：「Typography」「Flex」など、スタイリング用のコンポーネントがDOMに影響してしまう悩みからの解放。
• デザインシステムの踏襲：デザイントークンを型レベルで組み込み、デザインとの乖離を排除。

ご存じのとおり、Reactのスタイリングには「Sass/SCSS」「CSS Modules」「Styled Components」「Tailwind CSS」「Emotion」「StyleX」など様々な選択肢があります。それぞれ一長一短があるため、どれを採用するのか悩ましいところですが、今回紹介するPanda CSSは、これらの手段の“いいとこ取り”を叶えてくれる存在だと感じています。

実運用を通じても開発体験の良さを実感しており、個人的にはPanda CSSが「Reactのスタイリング手法における最適解」だと思っています。 ここで挙げた以外にもPanda CSSを使うことで得られる恩恵は様々であり、記事全体を通してご紹介出来ればと思います。

目次

※記事全体で分量が多くなってしまったため、記事を3つに分けて順次公開していきます。
今回はPart1となります。

• Part1：Panda CSSとの出会いとその魅力
  • 導入背景
  • Panda CSSの特徴と、他のスタイリング手法との比較
  • Panda CSSを使った基本のスタイリング
• Part2：実践！Panda CSSの使い方（Coming soon）
• Part3：Panda CSSの課題と未来への展望（Coming soon）

Part1では、Panda CSSの採用に至った背景とその魅力についてお話しします。
後日公開するPart2/Part3では、実際にどのようにプロダクトで運用しているかを、設計事例とともに紹介する予定です。

導入背景

「Agile Effect」では、Reactを用いてフロントエンドを開発しています。
立ち上げから約1年間はCSS Modulesを使っていましたが、次第に以下のような課題が出てきました：

• 静的型付けが効かない
  • 単純に開発体験の悪さを感じ、エラー発生やコミュニケーション面など、将来的な開発スピードへの影響が懸念されました。
• デザインシステムの作成開始
  • デザイン自体がまだプロトタイプの状態でしたが、本格的なデザインシステム制作がスタート。スタイリング設計を見直す大きな要因に。
• 汎用スタイルコンポーネントの責務拡大
  • 「Typography」「Flex」など、スタイル適用のためのコンポーネントが肥大化し、SRP原則から逸脱しはじめていました。
• デザイントークンの取扱い
  • 基本的なスタイリングはCSS Modulesで行いましたが、デザイントークンに限ってはTypescriptの定数を経由し、Inline Styleで管理していました。この影響で、スタイルの記述が.module.cssと.tsxの双方に散在していました。

これらを踏まえ、スタイリング設計をゼロから見直すことに。
調査と比較検討の末、我々が採用したのが Panda CSS でした。

Panda CSSの特徴と、他のスタイリング手法との比較

CSSは、TypeScriptベースの“ゼロランタイム”CSS-in-JSライブラリです（セットアップなどの基本知識はここでは割愛します）。公式ドキュメントの「なぜPandaを選ぶのか？」にあるとおり、主に以下のような特徴が挙げられます。

• 静的解析：
  • ビルド時にスタイルを解析・分析し、フレームワークに依存しない純粋なCSSファイルを出力します。
• PostCSS：
  • 静的解析の後、PandaはPostCSSプラグインのセットを使用して、ビルド時に解析されたデータをアトミックCSSに変換します。これにより、PandaはPostCSSをサポートする任意のフレームワークと互換性があります。
• Codegen：
  • ブラウザ実行時にスタイルを注入せず、ビルド時に軽量なランタイムJSコードを生成。結果としてランタイム負荷が低くなります。
• 型安全性：
  • Pandaは、cssプロパティとデザイントークンの型安全性を提供するために、csstypeと自動生成された型付けを組み合わせます。
• パフォーマンス：
  • 必要なアトミックCSSのみを最適化して出力。不要なCSSが入らずバンドルサイズが抑えられます。
• 開発者エクスペリエンス：
  • Pandaは、レシピ、パターン、デザイントークン、JSXスタイルプロップなどの豊富な機能により、優れた開発者体験を提供します。
• モダンCSS：
  • カスケードレイヤー、CSS変数、:where/:is等、最新のCSS仕様に対応。

また、私なりに他のスタイリング手法とのおおまかな比較表も作成してみました。

項目	静的型解析	実行タイミング	パフォーマンス	型安全DesignTokenサポート	動的スタイリング
Sass/SCSS （Pure CSS）	×	ビルド時	⚪︎ （肥大化しやすい）	×	△ （JSが必要）
CSS Modules	△ （型生成を支援するライブラリ使用で一部可）	ビルド時	⚪︎ （肥大化しやすい）	×	△ （JSが必要）
Styled Components / Emotion	△ （プロパティレベルの解析不可）	ランタイム時	×	△ （型レベルの厳密性は薄い）	◎
Tailwind CSS	△ （プロパティレベルの解析不可）	ビルド時	◎	△ （型レベルの厳密性は薄い）	⚪︎
Panda CSS	◎	ビルド時	◎	◎	⚪︎

表から分かる通り、Panda CSSにはこれといった大きなデメリットが見当たらず、静的解析や型安全性、ゼロランタイムなどの特色はどれも非常に魅力的でした。
もちろんプロジェクトとの相性等はあるかと思いますが、我々の場合は移行負荷も低く大きな懸念が無かったため、全面的にPanda CSSへ移行することにしました。

Panda CSSを使った基本のスタイリング

ここからは、Panda CSSにおけるスタイリングの一連の流れを見ていきます。
公式ドキュメントにあるように、Panda CSSは「TypeScriptベースのコード定義をビルド時に解析し、最終的に純粋なCSSファイルを出力する」フローが大きな特徴です。

ポイント:
Panda CSSでは、最新のカスケードレイヤーが活用されているのも大きな特徴の一つです。
CSSレイヤーを活用することで、複数のレイヤーにまたがるスタイルの優先順位が明確化され、アトミックCSSやデザイントークンとの相性がより良くなっています。詳しくは、公式ドキュメントのカスケードレイヤーのページをご確認ください。この仕組みを前提に、次章からはPanda CSSでどのようにスタイルを定義し、ビルドしているのかをご紹介していきます。

基本のスタイリング構文

Panda CSSのスタイリングは、styled-system/css が提供する css() や cva() などの関数を用いて定義します。まずはもっともシンプルなcss()を使った例を見てみましょう。
こちらが最も基本的な定義の例です。

import { css } from '../styled-system/css'
 
const styles = css({
  backgroundColor: 'gainsboro',
  borderRadius: '9999px',
  fontSize: '13px',
  padding: '10px 15px'
})
 
// 生成されるクラス名:
// --> bg_gainsboro rounded_9999px fs_13px p_10px_15px
 
<div className={styles}>
  <p>Hello World</p>
</div>

この定義を基にビルドした結果、CSS出力は次のようになります。

@layer utilities {
  .bg_gainsboro {
    background-color: gainsboro;
  }
 
  .rounded_9999px {
    border-radius: 9999px;
  }
 
  .fs_13px {
    font-size: 13px;
  }
 
  .p_10px_15px {
    padding: 10px 15px;
  }
}

上記のように、TypeScriptのオブジェクト構文でCSSプロパティを記述するだけでOKです（プロパティ名や値は型安全性が効きます）。実行時ではなくビルド時にCSSに変換され、ブラウザに読み込まれるころには純粋なCSSファイルとして提供されます。

ポイント:
css()以外にも、バリエーションを定義するためのcva()や、汎用レイアウトなどをRecipeとしてまとめるdefineRecipe()など、複数のアプローチがあります。どれも「TypeScriptでCSSを記述する → ビルド時に最適化されたCSSが生成される」という点は共通です。（参考）

スタイル生成の流れ

Panda CSSを利用すると、TypeScriptで記述したスタイルがビルド時に最適化され、最終的には純粋なCSSファイルとして出力されます。ここでは、その一連の流れを順に確認していきます。

1.「型付きのスタイル定義」を記述する

まず、開発者が行うのはTypeScriptによるスタイル定義です。css() や cva() に渡すオブジェクトや変数には型安全性が適用されるため、プロパティ名や値の誤りが早期に検知できます。

2.ビルド時に「原子化」と「不要なものの排除」

ビルドプロセスでは、Panda CSSがソースコードを走査し、同じプロパティや重複する宣言をまとめてAtomic CSSへ変換します。
Atomic CSS: CSSプロパティ単位でクラスを生成する考え方です（例: .p_8px_16px, .rounded_4px など）。
使われていないクラスは自動的に削除され、必要最小限のCSSだけがビルド成果物として残ります。

3.純粋なCSSファイルとしてブラウザへ

最終的な変換結果は、特定のJSライブラリに依存しない純粋なCSSファイルとして出力されます。つまり、ランタイムでスタイルを注入する必要はありません。ページ読み込み時には、既に最適化されたCSSが供給されているため、“ゼロランタイム”を実現できます。

ポイント
・型安全にCSSが書ける
・バンドルサイズが肥大化しにくい
・実行時のオーバーヘッドが少ない
・クラス名の競合を最小限に抑えられる

このように、型安全性と最適化済みのCSS出力を同時に得られるところが、Panda CSSの大きな特長です。

まとめ

Panda CSSで「書きやすさ」と「最適化」を両立

書きやすさ
TypeScriptでのオブジェクト記述なので、補完や型チェックが効き、スタイル記述のミスを減らせます。

最適化
ビルド時にスタイルを集約・最適化して出力するため、ランタイムで注入する仕組みよりもパフォーマンス面のメリットがあります。

Part2以降では、これらの基盤を活かしてデザインシステムをどのように型安全に落とし込んでいくか、さらに踏み込んだ使い方を紹介します。

今回紹介した「基本のスタイリング」の部分だけでも十分恩恵がありますが、Panda CSSには、Design TokenやRecipe機能など、より高度なスタイリングパターンをサポートする仕組みが豊富に用意されています。　これらを組み合わせることで「デザインシステムと型安全性の融合」を実現し、プロダクト全体のスタイリングを一貫性のあるものへと導いてくれます。

次章ではさらに踏み込んで、Panda CSSが提供する「Recipe（CVA）」や」Config Recipe」を活用した共通スタイルの定義や、デザイントークンを組み込んだデザインシステム構築など、より実践的な活用事例を紹介していきます。
加えて、テスト環境やStorybookでスタイルが反映されない際のトラブルシューティングなど、リアルな運用Tipsについても触れますので、ぜひご期待ください。

ご一読いただき、ありがとうございました！

年商1兆円を目指すレバレジーズの土台を、システムで創る。iPLチームとは。

はじめに

こんにちは。システム本部メディアシステム部iPLチームの大井です。

本記事では、私が所属しているiPLチームについて紹介します。 レバレジーズという多くの事業を展開し、急成長を遂げている会社であるが故の課題に対してシステムで解決すべく、どのように取り組んでいくのかお伝えできればと思います。

iPLチームとは

iPLはinternal Product Lab.の略で、「社内プロダクトの研究室」をテーマにした他の事業部とは異なったテイストのチームになっています。 平均年齢は27〜28歳、営業、マーケティング部からの出身者、新卒から中途まで様々なバックグラウンドを持った社員が所属しています。

このチームは2024年4月に発足しており、できて1年経っていないような新しいチームです。 設立の背景としては、年商1000億を突破し急拡大するレバレジーズグループの経営資源、いわゆる「ヒト・モノ・カネ・情報」の管理を見直してより効率的に経営判断ができるようなシステムを構築できるようにしようというところから始まっています。 まさに今年度の弊社テーマである「次代を、創る。土台を、創る。」の根幹を担うようなチームとなることを目指して日々仕事をしています。

業務内容

上記で紹介したようにiPLチームではレバレジーズグループの経営に直結する複数のシステム構築や管理を担っています。 その一部を紹介いたします。

新卒採用管理システム(ATS)

レバレジーズグループは新卒の採用を年々拡大しています。 2024年4月にはおよそ700名の新卒が入社しており、次年度以降も採用数を伸ばしていく見込みです。 弊社では外部の採用管理システムを長年使用しておりましたが、年々変化していく採用の体制を見込んだ拡張性や、データの利活用という点で大きなメリットがある自社開発を行なっております。

配賦処理システム

レバレジーズグループは40以上もの事業を展開している会社です。 各事業ごとの予算や目標が存在していますが、社員の中には複数の事業に貢献している社員がいたり、光熱費や備品、オフィスの賃料などの費用は各部署に跨っていることもあります。 そこで必要なのが配賦(はいふ)です。 配賦とは、ある費用を複数の事業や部署に割り当てることを指します。 様々な部署で跨って発生している費用を按分し、より正確な予算立てや目標設定をするためのシステムを開発しています。

統合法人データベース

各事業ごとに営業支援システム(SFA)を持っていますが、そこで得た情報を統合しグループ全体で活用するDBを開発しています。機能としては法人の名寄せや各事業での取引有無、コンプライアンスチェックなどを盛り込んでいます。

類似度判定システム

法人データの重複が発生してしまうと、営業活動の重複や顧客情報の散乱、分析精度の低下、コンプライアンス違反など多くのリスクを抱えることになります。 類似度判定システムは、類似する法人データを示すことで、担当者によるデータ統合・修正作業を促し、正確な法人データの維持を支援します。 現状は法人名といったテキストデータを中心に類似度判定を行っていますが、今後は、テキストデータだけでなく、画像データ（ロゴマークなど）や音声データなどより汎用的な類似度判定を実現するマルチモーダルなシステムを目指します。

従業員管理システム

約3000名の従業員が働くレバレジーズにおいて、適切な人員配置も経営において重要なことです。その人がどういった経歴を持っており、どういった適性があるのかなどを確認できるようなシステムを構築しています。

M&A

レバレジーズグループでM&Aを担当しているM&Aアドバイザリー事業部のシステム関連の効率化を行なっています。企業様どうしのマッチング精度を向上させたり単純作業の自動化などが挙げられます。 お客様への良質なご支援はもちろんのこと、将来的にはレバレジーズグループが実行するM&Aにおいてもノウハウが活かせるようにしていくことを目指しています。

使用している技術について

iPLチームではWEBアプリケーションとして開発されるものもあれば、API単体の開発をすることもあります。基本的にはTypeScript/JavaScriptを採用しますが、機能によってはPythonを採用しています。 開発するシステムも速度や精度を追求するものや、WEBアプリケーションとしてUI/UXにこだわるものなど、様々です。それに応じて柔軟にアーキテクチャも変えているので、幅広い知識も身につけることができます。

一例として、新卒採用管理システム「通称:Atsys(アトシス)」のアーキテクチャを紹介します。

フロントエンド：TypeScript（Remix）

バックエンド：TypeScript（NestJS）

BFF：TypeScript（fastify）

インフラ：GoogleCloud（CloudRun&Docker、CloudSQL（PostgreSQL） etc...）

Atsysはフロントエンド、BFF、バックエンドの3層で、TypeScriptを利用しています。 TypeScriptにした背景としては、複数領域に跨って開発・レビューする際に言語の差異による認知を軽減することや領域ごとに型情報を共有できることがメリットだからです。

• フロントエンド

フロントエンドはRemixを利用しています。 RemixはWeb標準に忠実に従おうという思想を持ったフレームワークであり、従来のReactで直面するであろう状態管理の煩雑さから解放され、開発者体験はとても良いです。 特にremix-validated-formというライブラリでは、クライアントとサーバサイドで同じスキーマを使ってバリデーションを適用でき、フォームの実装を簡単かつ一貫性を持って実装できます。

• バックエンド

バックエンドはNestJSを採用しています。 フレームワーク側でアーキテクチャが比較的固まっていて一貫性を保ちやすいこと、機能が豊富で大規模な開発がしやすいこと、モジュール間での依存関係を解決しやすいことがメリットです。 また、クリーンアーキテクチャを導入し4層で責務を切り分けていること、APIはRestの原則に忠実に従って設計していることにより、特定の箇所の責務が肥大化することを回避しています。

• BFF(Backend For Flontend)

当初はバックエンドとフロントエンドのみで、BFFは存在していませんでした。 ただ、バックエンドがRestAPIとなっており、あるページの描画のために複数のAPIにアクセスして結合する必要がありました。 その結果、ロジックの複雑化、ソースコードの肥大化が問題となっていました。 そこで、APIとフロントエンドの仲介をしてデータ整形を行うBFFを導入しました。 BFFではシンプルな処理を記述するだけなので軽量なfastifyを採用しています。

• インフラ

Google Cloudを採用しています。 FE、BE、BFFはいずれもDockerコンテナ上で動作させており、Cloud Runにホスティングしています。 Cloud Runはコールドスタートが非常に早いので使わない時はインスタンスを落としても問題なく、コストを抑えやすい特徴があります。 また、Google CloudにはIdentity Aware Proxyという機能があり、弊社社員のGoogleアカウントを使って簡単に権限管理を行うことができるメリットもあります。

やりがい

iPLチームの魅力はたくさんありますが、その中でも主に3つ紹介します。

・会社のミッション達成に直結する基幹となるシステムを創る
弊社は年商1000億円を突破し、経営における土台を再構築するタイミングになっています。そういった経営に関わる重要なシステムの構築に携わり、これから1兆円を目指していく弊社の重要な歯車として働けるのは大きなやりがいがあります。 また、会社を経営するためにはどんな情報が必要で、どういった形が健全なのか理解できることも魅力の一つだと思います。

・自分で仕様を決めて、設計して少人数で開発できる
社内の経営企画室や各事業部の幹部と連携を取りながら、仕様決め→設計→実装を一貫して行います。我々のチームは少人数で多くのシステム開発を行なっています。メンバーそれぞれがシステムにおける重要な意思決定を行います。特に仕様の部分は個人に大きな裁量があり、理想を叶えるためであれば自由です。言語やFW、インフラ構成なども自身で決めます。これによって、開発プロセスを一通り経験できるのはもちろんのこと、様々な関係者の知識や考えをどうシステムに取り入れていくのか考える思考力を身につけることができます。

・自分で事業を生み出してみることも...！
また、将来的な話ではありますが、開発しているシステムが社内で有効活用されたのちに外販していくことも考えています。iPLチームは社内プロダクトの開発を目的とするチームですが、その枠組みに囚われず事業創造までも成し遂げる野望を抱いています。

働き方(一例)

最後に

エンジニアとして経営に関わりたい、会社を大きくしたいという野望を持つ方とぜひ一緒に仕事をしたいです！ 少しでも本記事を見て興味が湧いた方は、弊社へエントリーいただけますと幸いです！

エントリーはこちら→https://recruit.leverages.jp/recruit/engineer/

お待ちしてまっっっっっっっす！

楽しく開発合宿をしてみたらたくさん予算をもらえる事になった話

はじめに

こんにちは。
レバレジーズでHRTech系SaaS NALYSYSの開発チームでEMをやっております、下畑と申します。

1月の第二週に、あけましておめでとう合宿と題し、
任意でメンバーを募集し、旅費が自腹のプライベート開発合宿を行いました。

取り組みとしてうまくいったので報告いたします。

この記事に書かれていること

• 自腹での開発合宿は今後の合宿予算を取るための布石として行なったのですが、
  目論見を超えた大きな話になったこと
• 実際の合宿の様子
  参加してくれたメンバーたちが楽しかった思い出として見返せるように

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

• 弊社エンジニアの自律性とチームワークが凄い
• 開発合宿は自腹でもやる価値ある
• 開発合宿はそれなりの成果と楽しい思い出を作れる
• 予算取りの一例としての自腹開発合宿、ありだと思います

開発合宿をやるぞ！

ことの発端

昨年のシステム本部キックオフにて、本部長が開発合宿をやりたい人はぜひ提案して欲しいという話をしていました。
その後、私が所属しているチームでは「なんだか楽しそうだから合宿してみたいなぁ」という機運が高まりました。
新しい企画が生まれるごとに、「これ、合宿でつくっちゃう？」といった冗談めいた会話が起こるようになりました。

高いハードル

そんなこんなで合宿やりたいという熱がどんどん高まり、現実的に会社のお金を使って合宿を行うにはどういう調整が必要なのかをPdMと考え始めました。
合宿をやりたいとおっしゃっていた本部長に話を聞いてみたところ、以下の答えが返ってきました。

「GIGAZINEに載るような面白いことをして欲しい。」

GIGAZINEさんはIT系の真面目なニュースからクスッと笑えるニュースまで掲載される歴史あるサイトです。
そこに載るってハードル高くないか？と。
他社でも開発合宿を行っているところは多数あるため、ただ合宿をやるだけじゃだめだと。
でも合宿はしたい！！

会社のお金を使って合宿を行うために我々が出来る現実的な調整としては、
プライベートで合宿をしてみて、その成果を社内外にアピールをしてみることではないかと結論を出しました。
つまり、今回行った開発合宿は、弊社で今後の開発合宿開催予算を取るためのPoCみたいなものになります。

提案と反応

プライベートで開発合宿を行うには、メンバーに宿泊費はもちろん貴重な休日を、半分仕事として消化してもらう必要がありました。
任意参加としてメンバーを募るにしても、人が集まらないと開発はできないため、ある程度のメンバーを集める必要がありました。

ただ、事前に開発合宿をやりたい機運がチーム全体で高まっていたこともあり、すんなり人は集まってしまいました。あっけない。
地方に在住のデザイナーの方も参加していただけたりと、開発するには十分なメンバーが集まりました。

以前チームでフルマラソンに参加した経験もあり、メンバーたちのフットワークの軽さに関しては認識していたものの（以下の記事参照）、
今回も弊社エンジニア達の人柄に対して企画する側としては感謝しかなかったです。 tech.leverages.jp

準備編

いつどこに泊まろう？

これは私の性格なのですが、やると決まったら待ちきれないタイプの人間でございまして、
一ヶ月後ぐらいの日程でみんなが暇そうな日をおさえました。

場所の案出しをお願いしたところ、グアムなど遊ぶ気満々の候補地も出ましたが、
自腹のことも考えると予算も無理のない範囲で行きたかったので最終的に湯河原にしました。

候補地検討

こちらの記事も参考にしました。
www.yugawara.or.jp
確かに湯河原は開発に集中できる環境だったと思います。

宿は大人数で安く泊まりたかったのでAirbnbを利用しました。
業務委託のデザイナーの方がたくさん候補を出してくれたのですが、
露天風呂付き、サウナ付きというとても面白い宿を予約することが出来ました。

最終的に、交通費と1泊2日の宿代を合わせて一人当たりの予算を2万円弱に抑えることが出来ました。

何をやろう？(結果も)

本部長から言われた「GIGAZINEに載れ」が頭から離れず、とりあえず面白い開発を合宿中にやってみようという話になりました。
宿も平屋の貸切だったため思い切ったこともできるということで、合宿で以下の検証をしてみることにしました。

• 露天風呂での開発は捗るのか？
• サウナで整った頭で開発すると捗るのか？
• 酒飲んで開発すると捗るのか？
• オールナイト開発はパフォーマンスを出せるのか？
• ランニング直後に開発すると捗るのか？

結論を書きますと、
みんなのテンションを上げたりエンターテイメントとしてやりごたえはあったのですが、
開発生産性にどう影響が出たのかはよくわかりませんでした。

露天風呂開発に関して具体的な言及をいたしますと、
腰への負担が座って開発するより少ないのと、外気温が低くのぼせる心配もあまりなかったので
意外に長時間開発に適していると感じました。
ただ、高価なマイPCを水没させてしまうリスクも孕んだ開発となるためおすすめはしません。

湯煙に隠れるディスプレイ

何を開発しよう？

現在開発しているNALYSYSはHRテック系SaaSですが、
HRテックがタッチするドメイン領域は非常に幅広く、我々が共感できる課題を改めて探索するフェイズでした。
ちょうど昨年末は、弊社の人事部に話を伺いながら共感できそうな課題を探していた時期であったため、
何を作ればいいかを合宿直前まで悩みました。
開発の弾を4つやろうという結論が出たものの、チームメンバーだけだと終わらせられるか心配になりました。

仲間を求めて

開発する機能ラインナップに対して人が足りないことに気付いたのは合宿の前々日でした。
こんな直前に声掛けをしても、なにかしらのメリットがないと人も集まらない気がしたので、
宿泊費はチームメンバーで持つから無料で合宿に参加しない？と声掛けをしました。

今回の宿は宿泊費が固定だったため、人数が増えてもメンバー一人当たりの宿泊費が変わらなかったことが幸運でした。

最終的にはその作戦で追加で5人あつまりました。
内訳としては、 同じ事業部の別チームに所属する開発者が2人、PMMが1人、
調子に乗って人数多い方が楽しいからと声をかけてみた別事業部の営業の方と人事の方1人ずつです。

集まれ〜

合宿はこんな感じ

スケジュール

こちらは事前に用意しておいた合宿のしおりに書いたスケジュールです。
露天風呂開発やサウナ開発など色々やりたいことがあったため少しユニークな予定も入ってます。

1日目
13:00 湯河原集合
13:30 飯食う
14:00 買い出しとか
15:00 宿チェックイン
15:10 風呂をすぐにわかしてサウナをON
15:30 開発開始
20:00 夕飯
21:00 酒飲み開発開始

2日目
4:00 開発終了 & 就眠
7:00 マラソン勢は起床し、峠を走る
8:00 走らない人達が起床
8:30 朝飯
9:00 開発開始
11:00 開発終了&チェックアウト

集合

総勢11人での合宿だったのでちゃんとみんなが時間通りに集まるかが少し不安でしたが、ほぼ集合時間に集まりました。すごいぞ。
湯河原駅前には撮影用の大きな風呂桶があるので記念撮影を撮りました。

買い出し

スーパーで買い出しをしたのですが、店に着いた直後やれ鍋が食べたいだのお好み焼きを作りたいだの、各々が買いたいものを買いに散らばっていきました。
人が多いって賑やかでいいなぁと思いました。
多分統率取りたいとかって思ってしまうとストレスになるかもしれないなと思いましたけれど、
別に仕事じゃないですし、みんなが各々好きにやってるのをみて笑ってるくらいがちょうどいいんだと思いました。

宿についてまずやったこと

誰がどの機能をつくるかと、GIGAZINE企画のやること一覧を大きな紙に書いて貼りました。
みんながこれを見てくれたのかは知りません。ただこういうことをやってみたかったのです。

個人的には合宿感が高まりました

開発スタート

ブリーフィングとして、開発を始める前に各チームに対してやりたいことを伝えていき、自分も開発をスタートさせました。
とても驚いたのは自分からやったインプットはそれくらいで、あとは各メンバーが自律的に各々の開発をうまく進めていってくれたことです。

合宿という限られた時間内にアウトプットを出すためにスコープをよしなに切ってくれたり、
新卒1年目の方も周りの先輩をうまく頼りながら開発を進めたり。
各チームがバッグブリーフィングを適切にしてくれたのでこちらも心配なく作業を任せることが出来ました。

メンバーの1人が小型のプロジェクターを持ってきてくれていたのですが、会社以外でチーム開発をするときはとても便利ですね。
レビュー会が開きやすい。
ディスプレイを持ち歩くよりコンパクトですし、専用の設備がない宿で開発合宿を行うのであれば必需品だと思いました。

ごはんは大事

これも驚いたことなのですが、手の空いた方達が自律的に炊事や食器の後片付けをしてくれました。
ヘビーな開発をしている連中が開発に集中できるように大きなサポートになったと思います。ありがとうございました。
開発合宿でアヒージョが食べられるとは思わなかったです。

とてもおいしかった

いい景色

飲酒開発

夕食を終えてからはお酒を飲んで開発を行いました。
すぐ眠くなる方がいたり、テンションが上がってウキウキで開発する方もいたり面白いものが見れました。
自身の開発を終えたメンバーから就寝していきました。

ランニング

翌朝マラソンするメンバーは箱根に向かう十国峠をランニングしました。
普段走っていないPdMも走りましたが、登り降りで往復6kmを完走。
これからも一緒に走りましょうね。

翌日の筋肉痛が大変だったらしい

チェックアウト

無事開発合宿を完走し、みんなで後片付けをしてチェックアウトしました。寂しかったなぁ。

被写体に叫んでもらうといい感じの写真が撮れるとのこと

合宿を終えて

本番環境へのデプロイ回数

8回
たくさんデプロイできたと思います。

機能開発

開発予定だった4機能中、3機能は本番リリース完了まで漕ぎ着けました。
残りの機能に関しても、翌週の業務で開発を終えて本番リリースすることが出来ました。

GIGAZINE企画

サウナに入ったら眠くなってしまったので、サウナ整い開発に関しては検証できませんでしたが、他は色々試すことが出来て楽しかったです。
ただ開発するだけではなく、普段できない開発をやってみることで開発合宿に深みが出たなと自己満足しています。

総括と今後

メンバーのおかげで成果を出せた

チームメンバーにも恵まれていますが、フットワーク軽く誘いに乗ってくれたゲストの方々がいたおかげで、想像以上の成果をあげることが出来た開発合宿だったと思います。

オールインハウスの強み

弊社は開発営業マーケティング部門を網羅的に揃えているオールインハウスの会社です。
NALYSYSは社内でも利用しているサービスであり、社内顧客からのFBも参考にしながら開発を進めています。
今回は事業部外の方にもご参加いただき仲良くなれたので、FBをもらえるパイプを増やすことが出来ました。
今後製品開発を進めていく上でよい状況が作れたと思います。

開発合宿おすすめです

開発に集中できるように食事付きの宿にすべきだったことや開発要件の計画性の無さからくる場当たり的な人員調整等、反省する点は多々ありました。
ただ、いろいろな調整がめんどくさいからという理由でやるか迷っている方はとりあえず自費でやってみることをお勧めします。

PoCとしての成功

この合宿の結果を事業部長が社長に見せてくれたおかげで、正式に合宿の予算が取れることになったようで、PoCとして大成功でした。
事業部長が話を更に大きくしてくれて、事業部全体で開催する運びになったそうです。
事業部長と社長の距離が近く、そういった調整がスムーズに口頭で進む点も弊社の面白いところなのかなと改めて思いました。

最後まで読んでくれた方へ

これからも開発合宿は継続的に行われていくと思います。
どうせ開発職として働くのであれば開発って楽しいなと思いながら働きたいと思っている方も多いと思います。
もしかしたら弊社であればそれを叶えられるかもしれません。
ご興味を持っていただけた方がいらっしゃいましたら是非以下の採用サイトからご応募してみてください。 recruit.leverages.jp

我々の普段の開発の雰囲気はこちらのYouTubeをご覧ください。
youtu.be

我々の作っているSaaSはこちらになります。
nalysys.jp

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

はじめに

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

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

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

こんな方は読んでほしい

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

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

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

軽く自己紹介

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

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

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

就活、何考えてた？（前編）

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

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

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

就活、何考えてた？（後編）

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

まずは規模について。
例えば、従業員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、カンファレンススポンサー、会場スポンサーなど、各チャネルを通して、弊社の技術力や雰囲気や文化を発信しています。
• 環境・制度の整備
  • エンジニア支援制度やオフィス環境の最適化などを通して、エンジニアが価値貢献をしやすい環境づくりを推進しています。
• 人材開発・組織開発の強化
  • エンジニアの成長をサポートする制度や評価の整備を行っています。
  • 評価制度システムは一部内製しているため、システム開発も行っています。
• 社内外との接続点の構築
  • 他職種や他事業部、さらには社外のコミュニティとの連携を深めています。
    • 参考記事
      • tech.leverages.jp
      • tech.leverages.jp

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

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

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

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

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

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

当初は専任として、現在はチームとして、現在に至った背景といたしまして、以下の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ボットを開発＆導入しました。

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

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

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

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

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

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

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

来年やりたいこと

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

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

CAILの機能強化

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

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

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

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

具体的には、

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

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

社内の業務効率化

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

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

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

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

社内での評価

今年１年の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チームから直接学ぶことができる無料の１Day イベントです。 セッションでは他社のDatadogを活用した様々な取り組みを知ることができます。現場の生の声を聞く貴重な機会です。

www.datadoghq.com

参加の背景

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

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

カンファレンス支援制度

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

セッション

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

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

アーカイブ動画

youtu.be

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

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

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

利用しているDatadogの機能

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

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

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

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

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

docs.datadoghq.com

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

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

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

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

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

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

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

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

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

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

後半の「今後の展望」ではシステム担当とビジネス担当が同じデータを見てサービス価値向上に努めていきたいというお話がありました。 これは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

余談

ご飯

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

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

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

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

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

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

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日間でいくつもの新たな技術に触れ、自分の技術スタックが増えるきっかけになりました。今回支えてくださった社員とメンターの方々、本当にありがとうございました！
レバレジーズのエンジニアがどういった働き方をしているのかだったり、実際の雰囲気を感じ取れるインターンシップでしたので、興味のある方はぜひ応募してみてください！！

レバレジーズ 2027卒新卒 エンジニアサマーインターン 応募フォーム

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