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

はじめに

こんにちは。
レバレジーズで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!

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

レバレジーズ テックフェス2024冬レポート

アイキャッチ

はじめに

こんにちは、レバレジーズ株式会社の檜垣・南です。本記事ではレバレジーズグループ全体のエンジニアが参加するテックフェスの様子をご紹介します。基調講演や、社員によるトークセッションなどについて書いていますので、ぜひ最後までご覧ください。

テックフェスとは

レバレジーズグループに所属するエンジニアを対象に、社内で半年に一度行われている技術の祭典です。エンジニアが新しい技術に興味を持ち、勉強をするきっかけを作ることを目的とし、グループ全体の技術力向上を目指します。2月14日に「速さと質の次へ~史上最速でコアコンピタンスを高める組織~」というテーマでテックフェス2024冬を開催しました。

AWS

AWSソリューションアーキテクチャの苅野 秀和氏に「AWS を使って価値提供 に集中しよう」というテーマで特別セッションをしていただきました。AWSのサービスに限定せず、AISASフレームワークを使った戦略の考え方などを発表していただきました。また、求人検索のパーソナライズやBedrockを利用した営業活動支援の最適化など、人材業界でのユースケースも紹介していただきました。人材業界にサービスを多く展開するレバレジーズのエンジニアにとって、コアコンピタンスを見つけるきっかけになったのではないかと思います。

アジェンダ

  • AWSを用いたデータ活用
    • High value & low riskの探索
    • Personalize
    • Bedrock
    • 人材業界でのユースケース
  • 開発者とAWS
    • セキュリティ
    • CodeCatalyst

AWSセッション

基調講演

徳丸浩氏に「今どきのウェブアプリでは脆弱性はどのように発現するのか?」という題名で、現在のアプリケーションにおいて脆弱性がどのように発現するのか、Teratail他のネットの記事のコードを参照しつつ解説していただきました。

登壇者紹介

徳丸浩 氏

  • EGセキュアソリューションズ株式会社 取締役CTO
  • イー・ガーディアン株式会社 CISO
  • 独立行政法人情報処理推進機構(IPA)非常勤研究員 技術士(情報工学部門)
  • 著書: 「 体系的に学ぶ 安全なWebアプリケーションの作り方脆弱性が生まれる原理と対策の実践(ソフトバンククリエイティブ) 」

1985年京セラ株式会社に入社後、ソフトウェアの開発、企画に従事。1999年に携帯電話向け認証課金基盤の方式設計を担当したことをきっかけにWebアプリケーションのセキュリティに興味を持つ。2004年同分野を事業化。 2008年独立して、Webアプリケーションセキュリティを専門分野とするHASHコンサルティング株式会社(現EGセキュアソリューションズ株式会社)を設立。 脆弱性診断やコンサルティング業務のかたわら、ブログや勉強会などを通じてセキュリティの啓蒙活動をおこなっている。 2023年イー・ガーディアングループのCISOに就任。セキュリティレベル向上だけでなく、活動を通して得たノウハウをサービスやセミナーコンテンツにも還元し、広くセキュリティの啓蒙活動に邁進。

アジェンダ

  • アプリケーションフレームワークと脆弱性対策
  • フレームワークとSQLインジェクション
    • Teratailの質問から
    • LaravelでSQLインジェクション脆弱にする
  • フレームワークとクロスサイトスクリプティング(XSS)
    • LaravelでXSSが発生するケース
    • ReactのようなSPAフレームワークの場合
  • SPAとCORS(Cross-Origin Resource Sharing)
  • フレームワークと認可制御

基調講演

セッション

発表してくださった皆さんありがとうございました。

最優秀の発表について

大規模なORMバージョンアップ作業を乗り越えた話 (レバレジーズ NALYSYSグループ 桐生 直輝さん)

speakerdeck.com

概要

大きめの破壊的アップデータがあったTypeORM 0.2 -> 0.3 移行について

  • ts-morph を用いたコードの自動置き換え
  • 移行用ライブラリによる漸進的な移行
  • 自動テストを活用した影響調査

の順序でお話し頂きました。

自作の移行用ライブラリを作成し、徐々に0.2 から 0.3に変更を進めて、 1人月+レビュー工数でアップデート作業を終えられていました。

LT

発表一覧

発表してくださった皆さんありがとうございました。

最優秀の発表について

桃栗3年、レコメンドエンジン5年 (レバレジーズ データ戦略室 阪上 晃幸さん)

speakerdeck.com

概要

レコメンドアルゴリズムのリプレイスについて

  • 黎明期
    • データ戦略室の発足時から将来を見据えて着工
    • 事業部長への提案〜アルゴリズム開発
  • 挫折期
    • Covid-19がレコメンド
    • プロジェクトを襲う
  • やり直し期
    • 全く新しい観点でアルゴリズムを開発
  • 新体制
    • アルゴリズムに足りていなかった現場の意見を反映し、使えるものに
  • 熟成期
    • 可用性を高め、LTSF実装に繋げていく1年
  • 離陸期
    • LTSFの内部でレコメンとAPIを使ってもらう

の順序でお話し頂きました。

懇親会

テックフェス終了後は、懇親会も開催。ピザやお寿司、おにぎりを食べながら発表者へ話を聞きに行ったり、他チームの方と交流を深めている様子が見られました。

運営メンバー打ち上げ

後日、運営メンバーで打ち上げに行きました。写真を撮ろうと思っていたのですが、話が盛り上がりすぎてすっかり忘れてしまいました。

最後に

今回の記事では、テックフェスのレポートを書かせていただきました。徳丸浩さんの貴重なお話を聞けたり、社内のエンジニアから普段は聞けない話を聞けて非常に面白かったです。

社内で技術ノウハウの共有を行なうイベントがあったり、外部から著名な方をお呼びして貴重な話が聞ける環境のレバレジーズで皆さんも一緒に働いてみませんか? レバレジーズに少しでも興味を持っていただけた方は、以下のリンクからエントリーをお願いします!

recruit.leverages.jp

【Frontend Night: App Router本番運用企業が語る!Next.js新機能活用法】で発表しました

レバレジーズ株式会社 レバテック開発部の堀内です。

2024/05/29に、PharmaX社、ANDPAD社、弊社の3社による共催イベント「Frontend Night: App Router本番運用企業が語る!Next.js新機能活用法」が開催されました。
Next.jsのApp Routerを実際に本番運用している会社が集まり、App Routerを利用した開発において良かったことや工夫したことを発表しました。

私は『App Routerの開発で気をつけたいこと3選』というテーマで発表しましたので、そのスライドを共有します。
App Routerを利用したプロジェクトを通して、ハマったところや失敗したところがいくつかあったため、気をつけたほうがいいこととして3つ紹介させていただきました。

speakerdeck.com

We are hiring

現在レバレジーズでは一緒に働いてくれる仲間を募集しています。
ご興味のある方は、以下のリンクからご応募ください。

recruit.leverages.jp

TerraformによるIaCの標準化を通じた、全社規模の開発体験の向上への取り組み

はじめに

 レバレジーズ株式会社 テクノロジー戦略室 SREチームの中野です。レバレジーズでは「SRE化を通して、Developer Experienceの改善、事業の拡大への対応、お客様に信頼されるサービスの提供を実現する」をミッションとして、Embedded SREメンバーと協力しながら、サービス改善の文化的土俵の構築や開発生産性の向上を進めています。
 この記事では、開発体験を向上させるための取り組みとして、社内標準となるIaCツールの選定、IaC化の負荷軽減への取り組みについてご紹介します。具体的には、社内標準ツールの選定では決定に至るまでのプロセスや方法をご紹介し、IaC化の作業負荷の軽減への取り組みでは、全体最適を狙った下記のライブラリ・テンプレートの作成についてご紹介します。

  • Terraform Modules
  • GitHub Composite Actions
  • GitHub Repository Template

 また、この記事を通して、弊社の開発体験の向上における取り組みを知って頂くと共に、全社最適を狙ったIaC化の推進について是非ともご参考頂ければ幸いです。それでは、以下で背景を挟みつつ具体的な取り組みについてご紹介します。

背景

 サービス開発体制のSRE化を進めやすくするために、インフラ構築・管理の省力化でIaC化を進めています。しかし、実際にはAWS CDK、AWS CloudFormation、Terraform等の複数のツールが利用されており、開発チーム・SREチームの双方において作業負荷がかかってしまっています。
 実際、ツールの乱立により、開発チームではIaCツールの理解度・習熟度がバラついており、開発チーム間でのナレッジ・ノウハウの共有が困難だったりします。SREチームでも、開発チーム毎に異なるサポートが必要となり、サポート負荷が高くなりがちです。
 この様な状況を解消するためには、ツールの乱立を最小限に抑え、IaC化を低負荷・低工数で進められる様にする必要があると考え、社内標準となるIaCツールの選定と、IaCツールやCI/CDにおけるライブラリ・テンプレートの作成を進めることになりました。

社内標準となるIaCツールの選定

ツール比較

 まずは、社内標準となるIaCツールの比較から始めました。ツールの認知度・利用度の高さを考えてTerraform・AWS CDK・Pulumi・CDKTF・OpenTofuから比較し、Terraform・OpenTofuが最良の選択肢として残りました。理由は下表の通りです。

比較観点 評価理由
成熟度・カバー範囲 殆どのパブリッククラウドに対応しており、SaaSでも対応範囲が広い。
ツールの学習負荷 HCLはJSONライクで学習しやすく、リソース設定が宣言的で見通しが良い。
構築・変更の負荷 リソース設定が宣言的なため、クラウドサービスの構築・更新でコード変更とズレの無い状態差分で期待通りに適用出来る。
状態変更の容易性 import・moved・removed等のブロック設定により、ツールで管理される状態の追加・変更・削除をコードベースで容易に実施出来る。
GenAIとの相性 リソース設定が宣言的なため、簡単なプロンプトで一定以上のクオリティでサンプルコードを生成出来る。

リスク調査

 ツール比較でTerraform・OpenTofuが最良の選択肢として残りましたが、今後IaC化を問題無く推進していくためにツールの将来的なリスクも考えておく必要があり、ライセンス変更によるTerraformの利用制限の可能性について調査しました。
 ライセンスに関する公式情報によれば、Terraformの利用範囲は従来通りでリスクはありませんでした。実際、HashiCorpの競合製品においてはHashiCorp製品が埋め込まれていれば利用制限が発生しますが、社内/個人によるHashiCorp製品の利用においては制限は無いとのことでした。 
 一方で、OpenTofuは今後のツールとしての安定性・充実性が現時点では見込めなさそうなため、Terraformの方がより安定的でリスクが低いツールであると判断しました。

www.hashicorp.com www.hashicorp.com www.hashicorp.com

選定結果・例外

 以上の比較・調査の結果を踏まえ、Terraform を社内標準ツールとして採用しました。今後はTerraformでIaC化を推進していく予定です。しかし、Terraformの導入・移行における費用対効果が必ずしも高く無いパターンもあり、下表を例外として規定しました。これらを考慮しながらIaC化を進めていきます。

例外パターン 対応方針
Terraformへのツール移行 他ツールで管理されているパブリッククラウドやSaaSでは、移行コストと改善効果性のバランスを考え、Terraformへの移行を検討する。
Terraformによるサポートが弱い部分へのIaC化 Terraformのサポートが未対応、またはサポート範囲が狭い部分では他ツールの利用を認める。
外部サービスの仕組みにおけるTerraformの導入 パブリッククラウドやSaaSで提供される仕組みにおいて、Terraform以外の手段で構築されている場合は、その手段の使用を認める。
一時的な利用のシステムへのTerraformの導入 プロトタイプや実験的な環境等の、一時的な利用が確実に見込まれる様なシステムでは、TerraformによるIaC化は強制しない。

ライブラリ・テンプレートの作成

 次に、IaC化を低負荷・低工数で推進するために、IaCの移植性・再利用性等を高める様なプラクティスの検討を進めました。Terraformを利用している開発チームにヒアリングしたところ、下記の課題感が出てきました。

  • 実装の際にクラウドサービスの仕様把握が必要で、実装における作業負荷が高い
  • 宣言的な設定のため、リソースが多くなると設定管理における認知負荷が高まる
  • Git RepositoryやCI/CDにおける社内標準の構成が無く、設計・初期作業で時間がかかる

 これらを解決するためには、Terraformにおける社内標準のライブラリ・テンプレートを作成する必要があると考え、Terraform Modules・GitHub Composite Actions・GitHub Repository Templateを全社向けに開発することになりました。

管理方針

 SREチームがライブラリ・テンプレートをメンテナンスしていく予定のため、テクノロジー戦略室向けのGitHub Organizationの配下でライブラリ・テンプレートを管理することにしました。また、ローカルやCI/CDでライブラリを利用する際に、PATをベースとしたアクセス認証でライブラリをダウンロードする様にしました。

作成方針

Terraform Modules

 全社最適のパターンとして、個々に依存しない手段を用いて全社最適を図るか、または個別最適の手段を組み合わせて全社最適を図るかの2種類が考えられ、そこからTerraform Modulesにおける次の構成方針を洗い出しました。

  • (1) 社内のサービス・システムに合わせたTerraform Modules
  • (2) クラウドサービスのリソースに対応するTerraform Modules

 検討の結果、(2)の方針でTerraform Modulesの構成を考えることにしました。実際、(1)の方針ではサービス・システム毎に特化したTerraform Modulesのため、極力少ない設定でインフラ構築・運用が可能です。しかし、サービス毎のシステム構成の変更に追従してTerraform Modulesをメンテナンスしていく必要があり、メンテナンス面で課題がありました。
 一方、(2)の方針では、サービス・システムの個別の設定・構成に依存せずに全社に展開出来るため、メンテナンス面の課題は小さめでした。また、社内要件やクラウドサービスにより推奨される設定をベースとして作り込めば、インフラ構築・運用における作業負荷を軽減可能だと考えました。結果として、メンテナンス性・利用者の負荷軽減のバランスの取れた(2)の方針が最良となりました。
 とは言え、単にクラウドサービス毎にTerraform Modulesを作ってしまうと、汎用性やメンテナンス性は高められるがサービス・システム毎の最適化には繋がらないため、次の2種類のTerraform Modulesを作成することにしました。

種別 説明 用途例
Component Modules クラウドサービスの単体のインフラリソースに対応するTerraform Modules ELB・ECS・EC2・RDS等のリソース毎にModulesで作成する
Catalog Modules クラウドサービスの複数のインフラリソースに対応するTerraform Modules ELB・ECS、CloudFront・WAF等のリソース群をModulesで作成する

 また、社内のサービス・システムの構成パターンを考えたところ、AWSを利用しているものが大半であり、かつCloudFront・WAF・ELB・ECS・RDS・ElastiCacheを用いた構成が多いため、この様なAWSインフラ構成におけるComponent/Catalog Modulesの開発を優先的に進めることになりました。

GitHub Composite Actions

 社内におけるCI/CDツールの利用状況や、CI/CDツールにおけるGitHub向けの連携機能の充実さを考慮し、GitHub Actionsを利用してTerraform CI/CDのパッケージを作成することにしました。
 GitHub Actionsの処理共通化を調べると、Custom Actions、Composite Actions、Reusable Workflowsのいずれかを用いれば良いことが分かり、処理共通化が容易かどうか、下記を満たす形で運用が可能かどうかを考え、Composite Actionsを採用しました。

  • テクノロジー戦略室のOrganization、開発チームのOrganizationは別々である
  • ライブラリ・テンプレートのRepositoryは、テクノロジー戦略室のOrganization管理下である
  • ライブラリ・テンプレートのRepository、開発チーム向けのRepositoryはPrivateである

GitHub Repository Template

 大半の社内サービス・システムでAWSが利用されているため、Terraform・AWS用のGitHub Repository Templateを優先して作ることにしました。また、開発チームのGitHub Repositoryで最適と思われるものを基準にして、GitHub Repository Templateの構成を考えました。
 Repositoryの生成・設定については、テンプレート内のコード・資料等をスクリプトで書き換える様な仕組みを導入し、テンプレートからTerraform用のRepositoryを低工数で設定出来る様にしました。
 更に、Terraformの管理基盤を構築する際に、Repositoryの設定だけでなく下記の作業も対応する必要があり、下記における設定手順の資料やTerraformの設定ファイルをテンプレートに含め、Terraformの導入における初期作業を全体的に低工数で済む様にしました。

  • Slack通知の初期設定
    • 通知チャンネルの作成
    • Webhook連携の設定
  • Terraformの初期設定
    • Terraform Backendの構築
    • CI/CD用のIAMロールの作成
    • CI/CDの設定作成・有効化
  • クラウドサービスの初期設定
    • 月額予算アラートの設定
    • 監査ログ、セキュリティ検知の設定
    • アラート通知の仕組みの構築

今後の活動

 以上の様に、社内標準のIaCツールの選定と、IaCツールのライブラリ・テンプレートの作成を進めてきました。しかし、現状ではライブラリ・テンプレートにおける開発のルール・フローや全社展開・要望吸い上げの体制が整い切れていないため、今後はこれらを整備してIaC化を推進していく予定です。
 また、現在はAWSを対象にIaCツールのライブラリ・テンプレートを作成していますが、今後はGoogle Cloud、Datadog、GitHub等のAWS以外のクラウドサービスも検討し、ライブラリ・テンプレートの対象範囲を広げていきたいとも考えています。

最後に

 レバレジーズでは、全社のSRE導入に向けて、サービス改善の文化的土俵の構築や開発生産性の向上のための取り組みを手伝って頂けるエンジニアを募集しています。
 SREの文化・体制に興味があったり創っていきたい方や、これからフルスタックエンジニアになっていきたい方は、是非ともご応募をお待ちしております。

TSKaigi2024にプラチナスポンサーとして支援させていただきました

レバレジーズ株式会社 システム本部の檜垣です。

レバレジーズでは、2024/05/11に中野セントラルパークカンファレンスで開催されたTSKaigi 2024で最上位のプラチナスポンサーとしてスポンサーブースを出展しました。

レバレジーズでは、TypeScriptをフロントエンド、バックエンドで幅広く使っていることもあって、日頃の感謝を込めてTypeScriptのコミュニティへの貢献のためにプラチナスポンサーとして支援させていただきました。また、私も微力ながら運営スタッフとして開催をお手伝いしました。

ブース内容

TSKaigiに参加した皆様に楽しんでいただくために、ブースでは、「スクラム開発のための業務効率化支援ツールのAgile Effectのデモ」や「レバ社員を探せ!くじ」などを行いました。

ブースの様子

くじ

楽しく談笑中

agile-effectのデモの様子

記念撮影

たくさんの人に訪れていただき大盛況でした。

agile-effectのデモでは、大変気に入っていただきその場で契約していただいた会社様もいました。

ブースに来てくださった皆様ありがとうございました。

We are hiring

レバレジーズ株式会社ではTypeScript大好きなエンジニアも、それ以外のエンジニアも幅広く募集中です。 もしご興味を持っていただけたなら、こちらのページからご応募ください。

recruit.leverages.jp