レバレジーズ株式会社 データ戦略室の森下です。 2024/01/25にTECH PLAY Data Conference 2024にて『営業部門と挑むデータの民主化』について発表したので、そのスライドを共有します。 営業人員が多い当社において、データの民主化にどのように取り組み、データ分析の専門家だけでなく、全社員がデータに基づいた意思決定を行い、成果を向上させた取り組みについて紹介しているので、是非ご覧ください。 イベント概要: techplay.jp We are hiring 現在レバレジーズでは一緒に働いてくれる仲間を募集しています。ご興味のある方は、以下のリンクからご応募ください。 エンジニア採用ページ: recruit.leverages.jp データエンジニア採用ページ: hrmos.co

はじめに テクノロジー戦略室クロスエンジニアリングチームの小林京輔です。業務では主にフロントエンドエンジニアとして、複数チームでフロントエンドのレビュー、ペアプロをしてます。 先日、社内のエンジニアと一緒に参加した（株）サードウェーブ主催第一回24時間AIハッカソン（2023年11月3・4日）で準優勝することができたので、ハッカソンで作成したアプリについて紹介したいと思います。 ハッカソン： connpass.com 記事： forest.watch.impress.co.jp 開発したアプリ せっかく作るなら社会課題を解決するようなアプリケーションを作ろうという話になり、最終的に日常生活におけるストレスや精神的な負担を軽減し、誰もがいつでもどこでも気楽にアクセスできるパーソナルヘルスケアAIと銘打って「Kiraku」というアプリを24時間で作りました。 以前、 看護ケアと現象学的研究 を読んだことがあり、現象学的ケアという概念が新鮮に感じられました。 症状について対処するのではなく、患者さんの意向に沿った形でケアを行うこと（現象学的ケア）は、現象学的な文脈における「志向性」に着目した方法だと考え、現象学の流れを汲んだ概念を社会に実装したいという思いがありました。 上記を踏まえて、作成したアプリには大きく分けて２つの画面があり、問診画面、チャット画面があります。 問診画面では、いくつかの設問に答えてもらう形で、ユーザーの傾向を判定しました。 まずは精神的な悩みを抱えたユーザーに対する理解が必要だと考え、直面している問題に対して寄り添いを期待するタイプと、具体的な課題解決を求めるタイプの２つを想定し、プロンプトデザインをすることで問診を行います。 チャット画面では、各タイプに応じた応答をするようにプロンプトを書き、応答させるように設計しました。 寄り添いを期待するタイプのユーザーに対しては、常に共感とカジュアルな会話で悩みを和らげるように応答させ、具体的な解決を求めるユーザーに対しては問題解決に焦点を当てた直接的な質問とアドバイスをするようにし、ユーザーの傾向に合わせてパーソナライズされたチャットボットを作りました。 さいごに 今回、人生で初めて参加したハッカソンでしたが、24時間という短時間で動くものが作れ、また準優勝という結果に結びついたことは素直に嬉しかったです。 また、深夜まで残ってくれたメンバーと一緒に開発して、組織として一つの目標に夢中になれたことは貴重な体験になりました。 レバレジーズでは社会課題を技術で解決していきたいエンジニアを募集しています。 興味のある方のご応募をお待ちしています！

こんにちは！レバレジーズ株式会社テクノロジー戦略室SREチームの蒲生です。 Datadog導入と監視のイネイブリングによってインフラ監視、アラート運用を開発者向けに民主化した事例を紹介します！！ この記事で伝えたいこと インフラ監視をみんなでやるのいいぞ サービスのスケールに柔軟に対応できるぞ インフラのことまで考えて開発ができるぞ ↑の状態を達成するためにやったこと 監視のイネイブリング 監視による開発者への負荷軽減 インフラ構成が簡単に肥大化、複雑化する時代になってきました。 日々成長する事業を支えるために増えていく新規のマイクロサービスやスケールアウトされるサーバーに対して監視の設定をしていくことに悩んだ経験はないでしょうか。 私が主に担当しているレバテックの開発では、インフラ監視に開発者が携われる体制にすることで高速に変化していくインフラ構成に対して柔軟に対応できるようになりました。 当時の課題 当時の開発では以下のような前提と課題を抱えていました。 前提 アーキテクチャ レバテックではAWSのEC2のモノリスアプリケーションからECSなどサーバーレス環境にマイクロサービスとして切り出していくリプレイスプロジェクトが進行中でした。 監視体制 当時の監視ツールはAWS CloudWatchを使用していて、CloudWatch AlarmやLambdaからメトリクスのアラートやエラーログをSlackに流すようにしていました。 アーキテクチャ図 課題 開発スピードに対して監視の対応が追いついていない 前提にある通りECSやLambdaを利用してマイクロサービスに切り出していくため インフラのリソースがどんどん増えていく状態に監視の設定や体制が追いついておらず、計測したいデータが取得できていませんでした。 インフラ関係のインシデントの多さ アクセス負荷やデータ量の変化、不適切な実装によるインフラリソースへの負荷が原因でインシデントが発生してしまうケースが散見されていました。 インシデント発生時にかかる調査工数の肥大化 インシデントが発生したときにログやメトリクスを利用して調査を開始するのですが 先に述べたように取得できていないデータがあったり監視体制が整っていないこともあり 調査工数が肥大化して解決までに時間がかかっていました。 課題分析 当時の課題を以下のようにそれぞれ原因分析してみました。 監視対応の属人化 監視の設定や運用ができる人が社内で限られていて 追加されていくインフラの多さに対してボトルネックになっていました。 設定にかかる負荷が高いため設定漏れなどで取得していないデータがありました。 実際の作業に関する暗黙知だけでなくどの項目に監視の設定をすればいいのか、メトリクスの相関をどう見ればいいのかなどの知見の共有が足りていない状態だったと思います。 インフラリソースの使用状況の曖昧さ 実装者からみてリソースの使用状況が把握しづらい体制でした。 インフラのリソースが普段どのくらい使用されているのかを意識するタイミングが少なく、リリース後しばらく経って変化するメトリクスなどには気づきにくい状態だったと思います。 また当時のCloudWatchだと使い慣れている人でないとデータやメトリクスへのアクセス性が悪く、使用状況をぱっと確認できる手段がなかったのも曖昧になった原因となっていました。 調査時に発生するコミュニケーションコストの肥大化 当時監視設定やメトリクスのモニタリングをSREチームが担当することが多かったのですが、実際に開発をしているのは開発チームというサイロ化した状態でした。 インシデントが発生した際に異変に気づき調査を開始するのはSREチームだけど 何がリリースされたのか、コードがどう実装されているのかまで深く把握していないので開発チームと連携を取る必要があり、そこでコミュニケーションコストが発生していました。 解決策 当時知識があったわけではないですが今から振り返るとDevOpsのCALMSフレームワークでいうC（Culture）、A（Automation）、S（Sharing）を特に意識して解決策を考えたように思えます。 監視設定、運用の負荷軽減 インフラ監視設定の自動/半自動化を進めることで設定漏れと全体の工数を減らし、インフラ監視の知識がない開発者でも設定ができるような状態にすることで属人化の解消を目指しました。 またDatadogの導入によってメトリクスやログの可視性を上げてデータへのアクセス性を向上させました。 監視のイネイブリング 開発チームと一緒にメトリクスやアラートを確認する機会を定期的に作って、開発してリリースしたものがインフラやサービスにどう影響を与えているかを把握してもらうようにしました。 それによって開発者が監視設定や普段のモニタリングを行えるようにして、インシデント発生時に開発者の中である程度対応が完結できるようにしました。 具体的な施策 Datadog導入による監視設定、運用の負荷軽減 普段の設定、運用にかかる負荷を軽減するために 監視SaaSツールであるDatadogの導入を行うことでインフラ監視設定の自動/半自動化による設定工数の削減とメトリクス、ログの可視性向上を進めました。 それまで使用していたCloudWatchでは当時だと取得したいメトリクスの不足や統一的なアラート設定がしにくい、ダッシュボードのUIの使いにくさなどの課題があり、自動/半自動化を進めにくい状態だったのでこのタイミングでツールの切り替えを決断しました。 Datadogのワンちゃん クラウドのリソースに監視用のタグをつけるだけで自動でDatadogにデータを送れるようにし、 新規のサーバーやマイクロサービスに対してはIaCツールによってコード化することで設定にかかる負荷を軽減して開発者によってインフラ監視設定を自走できるようにしました。 それによってSREチームやインフラに詳しい人がいなくても監視設定が進むようになりました。 また監視用のダッシュボードとログ検索機能を用意して、開発者が確認したいタイミングでぱっと見れるようにデータへのアクセス性と可視性を向上させました。 定期的なメトリクス確認会実施による監視のイネイブリング 開発者に監視の知見を深めてもらって運用できる状態にするために メトリクスダッシュボードを使って開発チームと一緒にメトリクス確認会を週次で実施しました。 まず先述したDatadogを使って各サービスごとにダッシュボードを作成し、開発者がいつでもインフラのメトリクスやログを確認できる状態にして そのダッシュボードを利用して週次で開発チームと週次でメトリクスやアラートを確認するメトリクス確認会を実施しました。 ダッシュボード はじめはファシリテーションを私が行ってメトリクスの異常値や状態化したアラートなど会の中で確認したほうがいいものをシェアして、それらに対する調査や改善などのネクストアクションを出すまでを話す時間を作りました。 それによってリリースされたどのコードがインフラやユーザーに影響を及ぼしたかメトリクスやアラートの確認を通して開発者が把握して異変が見つかったら修正行動に移せるようになりました。 Slackでメトリクスについて話されているスレッド 開発者がある程度慣れてきたらファシリテーションをだんだん委譲させることで、SREチーム抜きで会が回るようになっていきました。 今ではインシデント発生時のアラートへの1次アクションは開発チームが行っています。 まとめ 監視設定の負荷が軽減されて開発者が運用に関わりやすい状態になり、サービスのスケールにインフラ監視が追従できるようになりました。 さらに、開発者が週次でメトリクスやアラートを確認する機会を作ることで、開発者が普段の開発がインフラレイヤに及ぼしている影響を把握し、アラートへのアクションを開発チーム内である程度完結できるようになりました。 インフラ監視の民主化の重要性を示すひとつの例となったのではないでしょうか。 なによりSREチームの私としては開発チームの方と共通言語を使ってサービスの課題について話し合えるようになって仕事が楽しくなりましたし 開発チームが独自に監視やログの設計を見直している活動を見たときは嬉しくなりました。 改めてここで伝えたいことのおさらい インフラ監視をみんなでやるのいいぞ サービスのスケールに柔軟に対応できるぞ インフラのことまで考えて開発ができるぞ 今回は監視、アラートに関する取り組みでしたが他にも色々な取り組みを通じてSREチームとしてプロダクトの信頼性を保ちながらより質の高いリリースを可能な限り早くできる状態を目指して頑張っていきます！！ レバレジーズではサービスの信頼性を高める活動をしていきたいエンジニアを募集しています。 興味のある方のご応募をお待ちしています！

前日 ~ 2日目は 前編 に書いています。 こちらの記事は、3日目 ~ 帰国までの記事です。 技術的な記事などは こちら から見れます。 3日目 3日目の会場は、MGM Grandで参加しました。 朝食 相変わらずの甘そうなパンとフルーツに加えて、スクランブルエッグ、ベーコン、ソーセージなどが揃ってました。ベーコンはかりかりでした。 ランチ 本日のランチは中華っぽい感じでした。白いお米もあったので日本人的にも良かったです。 デザートもかなり充実してました おやつ？ 昼過ぎから、ピンチョスみたいなのやお菓子も会場に出てました。 ナイトパーティ ３日目は、AWS Japanが主催してくれた、日本人向けのClosedパーティーに参加しました。2日目は独り言以外で日本語を話さなかったので、かなり日本語話せました。 料理は、話しているウェイターさんが「一つどう？」って声かけてきてもらって食べるという形でした。 二次会 一次会近く地元の飲み屋街でお互い初対面同士で二次会しました。 お酒を1本買うと1本ついてくるという謎システムと、謎のAsada Friesをつまみに飲みました。 4日目 4日目の会場は、Mandalay bayで参加しました。 朝食 甘いパンが割りと控えめでした。その代わりジャムとかが大量にあるパターン。 ランチ ランチは自分で作るホットドッグ。 そしてなぜかポテチも re:Play 4日目の夜は、AWSが主催のクラブイベント。 ステージが３つあり、フードコートなども併設。飲んで踊っての大宴会でした。 5日目 最終日はVenetianにて参加しました。 朝食 安定の甘いパンとフルーツ。後はマフィンバーガー？的なのと、re:Partyでも出てたPupusaがありました。今回のre:Inventで初めて食べましたが、 エルサルバドルやホンジュラスの郷土料理 だそうです。 昼食 re:Inventは5日目の昼に終了なので、ランチは出ませんでした。なので個人でShake Shackに行ってきました。 バーガーのコンボと、赤ワイン頼みました。お酒を頼んでいるとはいえ、$30超えで日本円で5000円以上の贅沢ランチ。 カジノにて 昼のハンバーガーがお腹に残っていて、お腹減らなかったのでビールだけ。 負けました。 帰国 機内食 よくわからない料理でした。(ラスベガスで食べてたもの、大半名前分からず食べてはいましたがw) さいごに いかがでしたでしょうか？ひたすら食べたもの貼り続けただけのブログなのでなんじゃこりゃって感じかもしれませんが、真面目な記事も書いているのでぜひ こちら からご覧ください。 現在、私たちと一緒に挑戦してくださるグルメなエンジニアを募集しています。記事など読んでご興味持たれた方おられたら、ぜひご応募ください。(グルメじゃなくてもご応募ください) recruit.leverages.jp

はじめに レバレジーズ株式会社 テクノロジー戦略室室長の竹下です。技術的なことだけでなく、ゆるっとした内容もレポートしたいと思ったので、現地の食べ物をレポートしようと思います。AWS re:Inventでは開催期間の朝食、昼食が全部出て、夜もパーティーなどが開催されているため、イベントの料理を中心にご紹介していきます。 AWS re:Invent前日以前 まだ始まっていないので前日は自分で店などを探して食べに行きました 飛行機 2食出ました。Chicken or Beafを期待してましたが、Chicken or PastaとYakisoba or Omletでした。残念です。 Chicken と、Yakisobaを選びました ランチ Outback Steakでランチしました。さすがステーキの国。超肉厚 おやつ？ 食べられません(バスソルト) 晩酌 さて突然のクイズです。ビールとビーフジャーキーでいくらでしょう？ 答えはこちら(選択反転で見れます) => 約3300円(22$)インフレと円安やばい AWS re:Invent 1日目 朝食 アメリカンな感じで、甘いパンしか無い。。。ヨーグルトとフルーツもありました。 ランチ ランチはメキシコ風でタコスなどがありました。デザートも有り、かなり満足度が高い。 会場はVenetianで食べましたが、昼食会場もめちゃくちゃ広かったです。 あと、Wynnではコーラなどのドリンクも置いてました 晩ごはん？ エキスポ(スポンサーブース)で様々な料理とお酒が食べ飲み放題でした。皆酒を片手にスポンサーブースを回ってました(もちろん私も) 2日目 朝食 朝食は、相変わらずフルーツと甘いパンが有りましたが、追加で数種類のソーセージだったり、ポテト炒めたものや、卵白を固めたなにかなどがありました(egg white frittataという料理かも？) 甘いもの以外が出たので食べごたえ有りました。 ランチ 2日目は、セッションの間があまり無かったのでサンドイッチのLanch Boxにしました。りんごが丸々1個入っているあたりすごくアメリカを感じました。 ナイトパーティー 夜はDatadogなど4社がスポンサードしているナイトパーティーにお邪魔しました。 料理に関して、ウェイターが机を回っててピンチョスみたいなのを「ひとつどう？」と進めてくる形でした。そのため、会話に夢中で食事の方は撮り逃してしまいました。すみません。(3日目ではちゃんと写真撮れたのでご容赦を。似た感じでした) ちなみに、お酒でワインを頼むと、white/red以外にぶどうの品種の確認されます。「ピノ・ノワールだけどいい？」とか。日本だとぶどうの品種を聞かれることなんて無いので新鮮でした。 3日目~ AWS re:Invent 2023 グルメ紀行 後編 に続きます。 最後に 来年は自分もAWS re:Inventに出て美味しいごはんを食べたい！という方は、ぜひ下のリンクからご応募ください。 recruit.leverages.jp

はじめに レバレジーズ株式会社 テクノロジー戦略室室長の竹下です。 現在 AWS re:Invent 2023に現地ラスベガスで参加しています。皆さんに少しでも早くラスベガスの風を感じてもらうために、月曜午前の”LLMOps: The lifecycle of an LLM”セッションのレポートを、あの会社や、あのブログより最速でお届けしたいと思います。 他の記事も見たい方は こちらの目次 からお辿りください。 セッション概要 LLMOpsを進めるに当たって、E-mailのサマリーを自動で作成するシステムを例に出しながら、どのような観点でどのように意思決定をするかをシミュレーション。また、AWSのサービスをどのように組み合わせてシステムを実現できるかの構成の紹介もあり セッションの内容 今回は、Toolingと、LLMOpsの構築プロセスについての話をしていく。 E-mailのサマリーを自動で行うシステムを例にして話をしていく。 LLMOpsにおいても、「Start small, think big」は大事。 まずは、ただサマリーを作る部分から始めるものの、最終的には各人のドメインを理解したシステムを考えて作る必要がある MLOpsとLLMOpsまたFMOpsの違いはなにか？ どちらもほぼオーバーラップしている LLMOpsには、3タイプのユーザーがいる。 Provider: Tuners, Customer それぞれ必要なスキル、注目点が違っている LLMOps構築までのプロセスと、構築後の改善プロセスがある。 まずは構築段階の話をしていく まずはUseCaseの分析が必要。Criticality, Scale, Task Type, Eloquence, ROIの観点が大きく考えられる。今回のE-mailのサマリーシステムの場合は、 Criticality: Low 内容多少違っていたとしても、メールの本文を読めば良いので、優先度は低い Scale: Low 自分のメールの入力だけで良く、出力もそのユーザーに向けてだけなのでデータ的にスケール要件は低い Task Type: Specific メールの要約というSpecificな範囲 Eloquence: Medium 文章的に自然である必要はある程度ある ROI: 重要。生産性を高めることがちゃんと出来る必要がある LLMモデルを選択するときの判断軸としては以下のような物がある。 この中でUseCaseで重要な項目と優先度を見積もっていく 今回のE-mailのサマリーシステムの場合は Cost > Precision > Speed となる。 また、通常のDeepLearningなどはハイパーパラメーターなどの調整となるが、LLM、GenAIの場合は、プロンプトの調整となる モデルが決定し、調整も出来たら、評価が必要。 モデルは完璧では無いため多層的に、図のようなチーズモデルによって評価し、致命的な問題が無いかを適正にチェックする必要がある。 構築が完了したら、あとは改善のループを回す必要がある。最初の構築はS3がらSageMakerのNoteBookなどを利用し、BedRokSummaryを投げて結果を返す。 システム化する、受け取ったメールのデータを転送、バッチを定期実行、出力された結果をメールする、QuickSightにつなぎこんで評価を可視化するなどをするため、以下のような構成になる 更に進化させるには、Orchestrationも必要となってくる 最後に 現地時間 2023/11/27 12:01 書き上げました。セッション聞きながらリアルタイムでまとめてリリースしたので、きっと世界最速レポートになっていると思います。 聞き漏らしたところもあるので完璧な内容ではない部分もありますが、ご了承ください。 現在、私たちと一緒に挑戦してくださるエンジニアを募集しています。ご興味のある方はぜひ 採用サイト をご覧ください！

AWS re:Invent 2023 に弊社エンジニアが現地ラスベガスで参加しました。 セッションなどのレポート等を随時更新していきます。 こちらはそのレポートなどへのリンクのまとめ記事です。 技術記事 AWS re:Invent 2023 - LLMOps: The lifecycle of an LLM の(おそらく)世界最速レポート 【レバテックLAB】AWS開発文化のベースとなる分散チーム: 組織構造からイノベーションを加速させる仕組み【AWS re:Invent 2023】 おもしろ記事 AWS re:Invent 2023 グルメ紀行 前編 AWS re:Invent 2023 グルメ紀行 後編 さいごに 現在、私たちと一緒に挑戦してくださるエンジニアを募集しています。SREの募集もありますので、記事など読んでご興味持たれた方おられたら、ぜひご応募ください。 recruit.leverages.jp

はじめに 　こんにちは。レバレジーズ株式会社システム本部の田中です。 　2022年11月から新規事業の立ち上げメンバーとして開発業務に携わっており、2023年6月に レバクリ をリリースしました。社内では初となる大規模かつ決済を伴うtoCサービスであり、様々な挑戦をしながら開発を進めてきました。 　レバクリは「あなたの自宅をクリニックにする」をコンセプトに、オンラインで診療予約、診察、決済が完結し、自宅に薬が届くオンライン診療プラットフォームサービスです。「医療のあり方を変え、日本の医療における問題解決の主体者となる」ことをミッションとし、提携している医療機関と連携しながら、患者と医療機関の双方への最適な体験を提供できるサービスの実現を目指しています。 　レバレジーズではエンジニア一人ひとりが要件定義などの上流から実装まで幅広く担当することはもちろん、マーケティングやデザイン、オペレーションなど様々な領域の業務に関わることがあります。特に新規事業の開発においてはエンジニアに限らず少人数チームで始まることが多いため、エンジニアとしてではなく立ち上げメンバーとして様々なことに主体的に取り組むことができます。この記事では新規事業『レバクリ』の開発にあたって私が取り組んだことについて、以下二つの観点で紹介していきたいと思います。 技術的側面 プロダクトマネージメント的側面 　レバレジーズでの新規開発でエンジニアがどのように活躍、成長できるのか、どんな形で貢献できるのか、少しでもイメージが鮮明になると幸いです。 サービスやチームの特徴をベースとした自由な技術選定 　技術選定といえば、新規事業のプロダクト開発の際の醍醐味の1つだと思います。レバレジーズでは技術選定は各チームに任されているので、事業の特性やチーム構成、メンバーの経験などをベースに行うことができます。 　今回、レバクリ開発チームでは「最速でのリリース」と「開発者体験」を考えた技術選定を行いました。チーム発足からリリース予定まで7ヶ月あまりと短かったことから、できるだけ開発速度が出せるように、またチームメンバーの開発体験をできるだけ高めることができるようにという意図でした。 言語 　言語はフロントエンド、バックエンドともに TypeScript を採用しました。 　選定理由はかなり一般的な部分になりますが、 社内でも標準技術となりつつある 実装時に型チェックが効いてエラーを未然に防げる フロントエンド、バックエンドで同じ言語が使える 　ことが挙げられます。 フロントエンド 　TypeScriptで開発できるFWとして Next.js を採用しました。 　Next.jsはFWの大きな特徴として ReactベースでTypeScriptとの相性がいい アップデートやリリースが高頻度でコミュニティも活発 キャッシュ戦略やReact Server Component対応など、高パフォーマンスのアプリケーションを実装するためのベストプラクティスが用意されている 　ことが挙げられます。 　また、私自身入社してから1年半Next.jsを使ったサービスの開発をしていたため、新規プロジェクトへのスムーズな導入が期待できたことがありました。他にNext.jsの経験があるチームメンバーはいませんでしたが、VueやNuxtの経験はあったため順応にさほどコストがかからないと判断しました。 技術面の特徴としては bulletproof-react ベースのディレクトリ構成 featuresディレクトリ内で機能ごとに分けることで、機能間の結合を避けて無駄な共通化を考えずに開発速度を高めることができる GraphQL Code Generator と Apollo Client を組み合わせてデータ取得を実装 バックエンドのスキーマ定義から型を生成できる 自動生成されたApollo ClientのHooksを使ってデータ取得処理やキャッシュ管理の実装工数を削減 App Routerを一部導入 v13.4でstableになったことを受け、一部の機能でApp Routerを採用 といった具合です。 バックエンド/API 　TypeScriptで開発できる NestJS 、APIは GraphQL を採用しました。 　NestJSは TypeScriptで開発されたFW GraphQLと相性がいい Express（もしくはFastify）がベースで実装手法が近い 拡張性を残しつつ、FWとしてほしい機能が一通り揃っている 　といった特徴があります。私自身はTypeScriptでのバックエンド開発経験がほとんどなく、Expressを少し触ったことがある程度でしたが、ドキュメントが充実していて実装方法に癖があまりないのでスムーズに実装に入ることができました。 　GraphQLは 単一のエンドポイントで1リクエストから複数リソースを取得できる 取得する内容をフロントエンドで指定できる バックエンドで定義したスキーマを型としてそのままフロントエンドで使うことができる 　特徴があり、ページ数が多く、同じデータを複数箇所で使ったり少し形を変えて取得したりするプロダクトの特性にフィットしていると判断しました。また、バックエンドとフロントエンドで型が一致することは開発者体験を非常に向上させるものとなりました。 技術面の特徴としては オニオンアーキテクチャベース NeverThrow を使って型安全にエラーハンドリング try-catchでエラーに型がつかない問題をResult型を返すことで解消する ORMとして Prisma を採用 多機能ではないが、直感的で実装が簡単なNode.js用のORM GraphQLのN+1問題も解消してくれる といった具合です。 社内スタッフ向けCMS 　記事などの動的コンテンツの管理には Strapi というHeadless CMSを採用しました。 　Headless CMSというとあまり聞いたことがなかったり、知っていても使ったことはない方も多いかもしれませんが、表示部分（Head）以外の管理画面機能やデータ配信機能（API）を備えたものです。SEO流入獲得のために記事ページを展開する上でCMSの開発は必須ですが、リソースや保守を考えて0からの自作は避けたかったため、カスタマイズ性は確保しつつ実装を最小限に抑えられるCMSを探していました。 　Strapiは TypeScriptに対応している オープンソースなので無料で構築できる REST apiもGraphQL apiもどちらも利用可能 　という特徴があります。自前で環境構築が必要ではありますが、料金がかからずコードを書けば簡単にカスタマイズや拡張ができる点からStrapiを選択しました。 　Strapiについて詳しく書くと長くなるので省略しますが、社内利用に制限されていて機能も最低限の管理画面とAPIが必要な程度だったため、想定よりも手軽に運用に持っていくことができました。 外部サービス 　認証に関しては、有名なIDaaSとして Cognito や Auth0 、 Firebase Authentication がありますが 料金が比較的安い Firebase Authentication < Cognito < Auth0 インフラをAWSで構築しているので親和性が高い セキュリティ的な懸念があまりない Firebase Authenticationには 登録しているユーザーが特定できる問題 がある といった特徴からCognitoを採用しました。フロントエンドはAmplifyと組み合わせることで簡単に実装できるのと、サーバーの処理もAWS Admin SDKを使ってシンプルに実装が可能でした。また、AWSでインフラを構築しているので権限周りの設定も楽に行うことができました。CognitoとAmplifyを合わせた実装については 別のスライド で簡単に説明しているのでそちらも合わせてご覧ください。 　決済プラットフォームは Stripe を採用しました。実装するサービスやプロダクトの特徴によって大きく変わってくるので一概にはいえませんが、StripeはAPIが充実しており開発者向けのドキュメントも豊富なため、高いカスタマイズ性を求める場合に非常に相性がいいです。 ユーザー体験を第一に考えてサービス設計を主導 　技術選定はもちろんですが、新規事業の立ち上げメンバーとしてサービス設計も主導しました。オンライン診療事業としては大きな競合が2社ありました。それらのサービスの機能やフローを分析した上で必要な機能を洗い出し、より良いユーザー体験を届けるためにどうしたらいいか、どの機能がクリティカルで優先すべきかを整理しました。そして、最適なユーザー体験を第一にサービス設計を主導しました。 　ここでは特に設計に工夫をしたtoCのメールアドレス認証とtoBの診療画面について紹介します。 メールアドレス認証 　メールアドレス認証自体は機能として一般的ですが、社内の他サービスでは導入しているものが少なく、導入してCVRが下がった例もあったため、メールアドレス認証を入れるべきかどうかの議論からスタートしました。 　レバクリは基本的に登録したメールアドレスを使ってユーザーとサービス側がコミュニケーションをとる場面が多く、ログイン時のIDとしても使用する場合があるのでメールアドレスが存在しなかったり誤って入力されてしまうことはサービス運営上大きな障壁となります。また、セキュリティ面でもなりすましや第三者にメールが届いてしまうリスクにつながります。医療に関係するサービスであるため、受診歴や問診の回答内容が流出してしまうと大きな問題になってしまいます。ユーザーに安全にサービスを使用してもらうためにもメールアドレス認証は有効な手段でした。 　エンジニアとしてはセキュリティリスクを最小限に抑えるためにメールアドレス認証が必要と判断しましたが、事業サイドのCVRにおける懸念がある以上、セキュリティリスクを説明して理解を得る必要があります。以下のようなフローチャートを作成し、リスクを最小限に抑えるためのパターンについて提示した上で、認証を挟むポイントとしてどこがベストか議論をしました。 　レバクリには複数の機能がありますが全て診療の予約が起点となります。言い換えると診療を予約するまでは流出がクリティカルになるような情報やなりすます機会はないため、診療予約が完了するまでにメールアドレスが認証できていれば最低限のセキュリティ要件を満たすことができます。ユーザー登録に必要な情報を登録してもらい、最後に予約を確定するタイミングにメールアドレス認証を要求するステップに工夫しました。 toB診察画面 　診察を行う医師やクリニックの事務作業を行うスタッフが使用する画面をtoB画面と呼んでいます。toB画面も診察の一覧表示や診察、薬の発送に関する画面など複数の機能が存在していますが、事業の状況やチーム構成によってユーザーが変化する可能性があります。例えば一人で診察から発送まで行う場合と、作業を複数人で分担する場合では導線はもちろん必要な画面の種類や数まで変わってきます。そのため、集客やサービス運営が安定してくるまでに細かい変更が簡単にできるように、あまり作り込まずに最低限の機能を用意してリリースすることを目指しました。 　初期のスコープは医師が全て対応するのを基本線として、提携クリニックの医師にヒアリングをしながら設計しました。医師が普段の診察時に使っているシステムについて知見のあるメンバーがほとんどおらず、リファレンスもなかなか見つからずに難しいタスクでしたが、適宜画面の構成や機能についてすり合わせたり、プロトタイプを触ってもらってフィードバックを受けながら進めました。 　現在はCSチームが設置されたり、作業者の分担があったりと事業の状況も変わってきていて、初期はスコープから外していた検索機能を利用シーンにあった形で実装したりと日々アップデートが行われています。 今後の課題 　最後に今後の課題として取り組んでいきたいことについてご紹介します。 開発組織の体制整備 　チーム発足からエンジニア正社員2名+業務委託数名で開発を続けており、初期スコープではあらかじめ全て設計してから進めるウォーターフォールの形で開発していました。現在はチームメンバーも徐々に増え、複数機能を並行して設計、開発、リリースするアジャイル開発に近い形になっていますが、整備されているわけではないのでタスクの管理工数の増大やチームとしてパフォーマンスを最大化できていません。社内で導入しているチームが多いスクラム開発を含めて、機能開発を進めながら開発組織の体制も整備していきたいと考えています。 プロダクトとして競合に対する優位性の確立 　レバクリはオンライン診療サービスの中では後発になるため、現在は競合のレベルに追いつくための機能開発が中心になっています。着実に機能開発が進んできており、年内には機能として競合に遜色ない状態になる見通しとなっているため、今後は追いついた先で市場1位をとるためにプロダクトの強みを伸ばしていく必要があります。具体的には、予約やオンラインでの診察といった基本機能だけでなく、医薬品の服用をリマインドしたり服用の中での副作用への不安をサポートできるような機能や、診察の結果や自らの健康状態を確認できる機能など、プロダクトとして何度も使ってもらえるような仕組みを作っていくために、ビジネスサイドに食い込んで事業成長に貢献していけたらと考えています。 さいごに 　最後までお読みいただきありがとうございました。レバクリを一番選ばれる最高のサービスにしていくことを目指して、これらの課題に取り組み、より強い開発組織を作っていきたいと考えています。現在、私たちと一緒に挑戦してくださるエンジニアを募集しています。ご興味のある方はぜひ 採用サイト をご覧ください！

はじめに 以前のテックブログまでにやったことと課題 各課題とその解決策の分析 特徴量の再利用性の低さ 学習にかかる時間の長期化 単一モデルデプロイフローしか整備されていない パイプライン実行の煩雑化 PoCからシステムへの初期導入のリードタイムの長期化 これまでの取り組み 特徴量の再利用性の低さ 学習にかかる時間の長期化 単一モデルのデプロイフローしか整備されていない パイプライン実行の煩雑化 これからやりたいこと まとめ はじめに 　テクノロジー戦略室MLOpsチームの古賀です。MLOpsチームでは、レコメンドエンジンのMLOps基盤の構築や、AWS PersonalizeなどのMLサービスやLLMなどML活用を、企画から構築まで進めています。本テックブログでは前者のMLOps基盤構築の取り組みを紹介します。 　 以前投稿したテックブログ にあるように、AWS SageMakerとStep Functions Data Science SDKを導入し、データサイエンティスト主導のMLモデル改善フローを構築できました。しかし、ゴールというわけではなく、まだまだ改善の余地がありました。 　そこで、本テックブログでは、課題の洗い出しや分析、解決のための取り組みを紹介します。そもそもMLOpsを行う背景は 以前投稿したテックブログの「背景」 に記載しているので、興味ある方はご確認ください。 以前のテックブログまでにやったことと課題 　まず前提として、今までのMLOpsシステム構成を知る必要があります。下記のような構成になっています。説明の都合上、図を書き直していますが、構成は一緒です。 　一連のMLプロセスがパイプライン化されているため、データサイエンティスト主導でモデル改善フローを実行できます。また、学習-推論時で前処理を共通化しているため、Training-Serving Skewを改善出来ています。 　一方で課題がいくつかありました。 特徴量作成 特徴量を再利用できない 学習：開発時、学習パイプライン（前処理から評価まで）の実行時間が長い デプロイ：単一モデルのデプロイフローしか整備されていない 全体 パイプライン実行の複雑化 PoCからシステムへの初期導入のリードタイムが長い 各課題とその解決策の分析 　各課題を分析し、必要な解決策を説明します。 特徴量の再利用性の低さ 　現状S3に特徴量を出力しています。S3に特徴量を格納している場合、作成者以外の人が特徴量の利用を判断するのが難しくなります。理由は、S3には特徴量のメタデータ管理やバージョン管理の機能がないからです。これらの機能がない状態で作成者以外の人が利用判断するためには、その特徴量が信頼できるデータソースから正しい変換処理により作られているかをソースコードから読み解き確認し、その結果作られる特徴量が正しいかも確認する必要があります。 　そこで、特徴量のメタデータ管理機能やバージョン管理機能を持ったデータストアに格納する必要があります。 学習にかかる時間の長期化 　学習パイプラインの実行による動作確認に時間がかかっていました。理由は2つあります。 不要なステップも実行されるため。例えば、評価の処理を変更した場合、評価ステップのみ実行すべきですが、前処理ステップから実行してしまいます。 SageMaker Processingの起動に時間がかかるため。1つあたり5分程度かかるため、全て実行すると起動だけで15分程度かかります。 　これらの課題を解決するためには、必要なステップだけ実行し、起動時間を減らす必要があります。 単一モデルデプロイフローしか整備されていない 　単一モデルのデプロイのみ実装しており、複数モデルのオンライン評価の仕組みが用意されておりませんでした。そのため、複数モデルのデプロイとそれらのオンライン評価の仕組みが必要です。 パイプライン実行の煩雑化 　デプロイパイプライン以外の動作確認手順が煩雑でした。例えば、ライブラリをインストールし特徴量変換処理を変更した場合、下記の作業が必要でした。 動作確認用のAWSリソースを作成（データ取得パイプライン、S3バケット） Dockerイメージのbuildとpush 動作確認用のデータ取得パイプライン実行notebookを実行 変更するたびに、動作確認手順が変わるのは認知負荷が高い上、対応漏れも発生します。加えて、変更箇所によっては、AWSリソースは他のパイプラインやLambdaの作成も必要になります。これらの課題を解決するには、変更箇所によらない動作確認手段が必要になります。 PoCからシステムへの初期導入のリードタイムの長期化 　レコメンドプロジェクトを下記のように進めていました。 　MLOpsとして最優先で解決したいのは、SageMakerへの載せ替えの長期化です。長期化している理由は2つあります。 プロジェクトごとに一からインフラ構築しているため PoC後にMLエンジニアが構築したパイプラインに載せ替えているため 　特に後者の工数が大きく、PoCではPoC後の移植を想定したコードを書いておらず、スパゲッティコードのような状態で移行が大変でした。加えて、載せ替えにあたり、データサイエンティストとMLエンジニアのコミュニケーションコストもかかっていました。 　これらの課題を解決するためには、データサイエンティストの開発スピードを落とさず、作ったモデルをそのままシステムに組み込めるような基盤が必要になります。 これまでの取り組み 　上記課題の中で実際に取り組んだことを紹介します。特徴量の再利用性についてはFeature Store + Dataflowの検証までになりましたが、他の課題はある程度解決できました。Feature Store + Dataflowの検証についても紹介します。 特徴量の再利用性の低さ 　AWS SageMaker Feature StoreとGoogle Cloud Dataflowを選択し、検証を進めています。AWS SageMaker Feature Storeを採用した理由は下記の通りです。 特徴量のバージョン管理機能やメタデータ機能があり、特徴量の再利用性を高められるため Google Cloud Dataflowを採用した理由は下記の通りです。 データ変更後、リアルタイムに特徴量に変換して格納するため pandas互換のAPIをサポートしており、データサイエンティストも扱えるため 他チームでRDSからBigQueryにETL処理するためにGoogle Cloud Dataflowを導入予定で技術を標準化するため 　現在は下記の構成の検証を進めています。 白抜き部分の実装は概ね完了したので、これから検証 / 本番環境にデプロイし問題がないか確認していきます。問題がなければ、稼働中のレコメンドプロジェクトにも導入していく予定です。 学習にかかる時間の長期化 　SageMaker Pipelinesを導入し解決しました。導入した理由は下記の通りです。 キャッシュモードが存在し、不要なステップの実行をスキップできるため ローカルモードが存在し、SageMaker Processing Jobの起動時間を短縮できるため 処理を変更したステップのみ実行できるので、最小限の実行時間にできました。 単一モデルのデプロイフローしか整備されていない 　複数モデルをデプロイできるようにし、推論エンドポイントであるSageMaker Endpointの前段に配置しているキャッシュサーバーにトラフィックを振り分ける処理を実装しました。なお、トラフィックを振り分ける際は、ユーザーに対して推論するモデルを固定しました。 　まず、ユーザーごとにモデルを固定した理由は下記の通りです。 ユーザーを困惑させないため。レコメンド機能を使うたびに結果が変わると、ユーザーが混乱するため。 分析を簡単にするため。もしトラフィックをランダムに振り分けると、どのモデルが推薦したか追う必要があります。この方法よりは、ABテスト期間内でユーザーごとにモデルを固定した方がシンプルで分析しやすいと判断しました。 　次に、キャッシュサーバーに実装した理由は、SageMaker Endpointのトラフィック振り分け機能はランダムな振り分けしかなく、ユーザーごとにモデルを固定できないためです。そのため、SageMaker Endpointの前段のサーバーに振り分けロジックを実装しました。 パイプライン実行の煩雑化 　どのファイルを変更しても、Github Actionsワークフローを動かせば動作確認できるようにしました。加えて、Model Registryに登録された評価結果を承認し、対象のモデルをデプロイできるようにしました。 　Github ActionsワークフローはDockerイメージのbuildとpush、Lambda関数の作成 / 更新、データ取得と学習パイプラインを作成 / 更新し実行します。どこを変更しても、このワークフローを動かせば確認できるため、認知負荷を減らせました。加えて、必要な時のみDockerイメージの構築やLambda関数の更新を実行しているため、不要な実行時間はありません。 　Model Registryに登録されたモデルを承認し、デプロイパイプラインを実行します。このようなフローにしてる理由は、人間が評価結果を確認してからデプロイしたいためです。ただし、この判断基準を明確なルールにできるならば、Github Actionsワークフローでデプロイまで実行しても良いと考えています。 これからやりたいこと 　短期的には、レコメンドプロジェクトの開発効率を高めるために、解決できてない課題を解決したいです。 特徴量を他プロジェクトで再利用できない Feature Store + Dataflowを本格導入したいです。パフォーマンスに問題が無いことを確認する、他の機能との優先度の兼ね合いなどありますが、実現していきたいです。 PoCからシステムへの初期導入のリードタイムの長期化 MLOpsフレームワークの構築、または、標準構成のテンプレート化などで短縮させたいです。PoCする段階からSageMaker上で開発することで、SageMaker移行の工数を無くすためです。 　長期的には、開発効率だけでなく、ビジネスサイドがレコメンドが事業に与える影響を直感的に分かるようにし、ビジネスサイドとデータサイエンティストのコミュニケーションも効率化させ、レコメンドの精度改善スピードを向上させたいです。 まとめ 　以前のテックブログ執筆時の課題と解決のために、提案し実行した取り組みを紹介しました。まだGoogleが提唱する MLOps レベル1 に達してないですし、使い勝手も改善していく必要があります。加えて、今回は紹介できませんでしたが、ML活用も推進しています。レバレジーズではMLOps基盤やML活用を企画から考え構築までやりたいエンジニアを募集しています。興味のある方の応募をお待ちしています。

はじめに CTO室が設立された背景 CTO室で実現したいこと CTO室の今後 さいごに はじめに こんにちは、レバテック開発部でテックリードを担当している河村です。 私はレバテック全体のシステム設計を担当しており、今後の事業拡大に向けて、理想のシステムを目指して、技術的負債の解消などの推進を行っています。 レバテックはこれまで、マイクロサービス化を主体においた技術スタックの刷新を行ってきました。これからはユーザー体験、業務プロセス、技術的負債を含めて「痛み」となっている部分の解消を進めていき、プロダクトやサービスとしての最適解を探索していきます。 そこで、今回はレバテックのシステム課題である 「分散されたモノリス」の状態から「日本一のデータとシステムを持つ事業とそれを支えるアーキテクチャ」を目指して どのようなことを行おうとしているのか、そこに合わせて新設されるCTO室がどのような活動を行うとしているのか、レバテックの現状と課題を踏まえてご紹介します。 CTO室が設立された背景 レバテック - 事業ポートフォリオ レバテックは現在、フリーランス・派遣・就転職、新卒の各領域を軸に様々なサービス・事業を展開しています。 ※ 主なサービス、関わるシステム レバテックフリーランス、レバテッククリエイター ITフリーランスとしてのキャリアの可能性を広げるエージェントサービス レバテックキャリア、レバテックダイレクト 正社員としてのキャリアの可能性を広げる転職エージェント・スカウトサービス レバテックルーキー ITエンジニアを目指す学生の可能性を広げる就活エージェント・スカウトサービス レバテックプラットフォーム レバテックに登録いただいたITフリーランスのスカウトから、参画後の契約管理までを実現するプラットフォームサービス レバテックID サービスを継続して使い続けてもらうための根幹となる認証認可基盤システム 参考記事： エンジニアが事業戦略の実現のために認証基盤システムを構築した話 上記レバテックのサービスを支えるマイクロサービス群 参考記事： マイクロサービス化を中心においた技術刷新とその狙い レバテック - 事業進捗・サービス展望 レバテックは5年後、10年後の事業拡大に向けて、様々な事業展開を計画しております。 今までは営業とマーケティングの強みを生かして事業展開を行ってきましたが、今後は開発とデータを活用して事業展開を計画しており、開発とデータが強い組織・システムを構築しなければなりません。そのためにも、 「日本最大級のIT人材プラットフォームの進化を支える」組織やシステムを構築する必要があり、ユーザー体験、業務プロセス、技術的負債の改善 に向けて取り組んでいます。 レバテック - 現状のシステム全体像 レバテックの各サービス・事業を支えるシステムは上記のようになっています。 各システム間の連携や営業支援システム、外部サービスとの連携があり、レバテックに関連したレポジトリだけでも200個以上あり、大規模なシステムになりつつあります。 その中でも システムとして最も課題としているのが「分散されたモノリス」のような状態 （参考記事： What is 分散モノリス(Distributed Monolith) ）です。すべての機能がマイクロサービス化されているわけではないので、一般的な「分散されたモノリス」の状態というわけではないのですが、発生している問題としては近い状態です。 上記の図のようにシステムは各サービス・事業ごとに分散されています。ですが、この分散されたシステムは理想的な分割ではなく、既存システムの複製で作られたシステムであったり、人が増えたことにより出来上がったシステム、システムの本来の責務を超えた機能をもっていたりと理想のシステムとかなりギャップがある状態です。 そこで、「分散されたモノリス」となってしまっている原因として以下の問題があります。 密結合なシステム 人材や企業のデータも重複して保持している状態でかつDB直参照やバッチサーバ連携で行っているため、システムの追加や変更を意識して開発しなければならない 非構造化データの存在 文字列やEAVパターンを利用した暗黙的なリレーション構造が存在し、DBに格納される文字列を変更するだけでシステムの障害のきっかけとなり得る マスタデータ（職種やスキルなどのリファレンスデータ）の分散 各システムでマスタデータのIDや項目が異なり、マッピングをして連携や分析を行っている 上記の問題は2、3年前から顕在化していました。ですが、いきなりすべての問題に取り組むのは難しく、また、当時の技術スタックも古い状態で稼働していました。なので、まずは技術スタックの刷新やマイクロサービス化の導入から進めてきました（参考記事： マイクロサービス化を中心においた技術刷新とその狙い 、 レバテックの未来に向けた開発組織の取り組み ）。技術スタックの刷新により、静的型付け言語であるTypeScriptをベースとしたシステムにすることができ、負債を貯めにくい・解消しやすい設計手法であるクリーンアーキテクチャやDDD（ドメイン駆動設計）の導入が行いやすくなり、計画的な負債の解消を進めやすい状態にすることができました。 今後は 「分散されたモノリス」から「それぞれのシステムとデータが”独立化”し”疎結合化”された状態」 を目指して、現在のTypeScriptをベースとしたシステムのリニューアルを行い、今後のレバテックを支える組織・システムを構築していきます。 つまり、今まで行ってきた「リプレース」を生かして、今後は「それぞれのシステムとデータが”独立化”し”疎結合化”された状態」に向けて 「リファクタリング」「リプレース」「リニューアル」を計画的に 進めていきます。 ※ リファクタリング・リプレース・リニューアルの定義 リファクタリング 現在のシステムをI/F（IN/OUT）やふるまいを変えずにコードを変更すること 例：MVCからレイヤードアーキテクチャに移行する リプレース 現在のシステムをI/F（IN/OUT）やふるまいを変えずに別のシステムに載せ替えること 例：PHPがベースで動いているシステムをTypeScriptベースのシステムに載せ替える リニューアル 現在のシステムをI/F（IN/OUT）やふるまいを変えて、新しい価値を生み出すこと 例：システム・データの拡張性を向上させるため、ユーザー登録の仕組みや業務プロセスから改善を行う CTO室で実現したいこと レバテック - CTO室ミッション 上記のレバテックにおけるシステム・データの課題を解決をリードしていくため、この度、CTO室を立ち上げることになりました。 大規模なシステムになってきたレバテックの関連サービスを支え、今後の事業拡大に向けて、総合的なアーキテクチャや設計が求められることになります。特に、最も難しいと考えているのが、今のレバテックにおけるユーザー体験、業務プロセス、技術的負債の中で最も「痛み」となっている部分の特定とその「痛み」の解消です。 すべての課題をいきなりすべて解消できる規模ではなく、今後の事業拡大を鑑みて、 最も「痛み」となる部分を分析・特定し、経営や他職種を巻き込んで、この「痛み」を計画的に解消を進めていく必要 があります。なので、ただ単純に技術的負債を解消を進めていくということではありません。現状のユーザー体験や業務プロセスを含めて最適解を探索する必要があります。 レバテック - CTO室が目指す先 レバテックは現在、登録者数50万人、契約社数1万社を突破し、IT人材の2.5人の1人が登録するサービスになっております。上記の「分散されたモノリス」な状態を脱却し、レバテックにおけるユーザー体験、業務プロセス、技術的負債の中で最も「痛み」となっている部分を解消し、 目指す先は「日本一のデータとシステムを持つ事業とそれを支えるアーキテクチャ」を作ること です。 レバテック - コア要素『D-POS』のAsis-Tobe 「日本一のデータとシステムを持つ事業とそれを支えるアーキテクチャ」になるために上記のTobeのような状態が必要だと定義しています。つまり、データを軸にプロダクト/オペレーション/システム（Data→Product/Operation/System）を再設計していく必要があると考えています。 ここまでをまとめると、 レバテックは5年後、10年後の事業拡大に向けて、様々な事業展開を計画している そのためには、「日本最大級のIT人材プラットフォームの進化を支える」組織やシステムを構築する必要がある 現在、組織・システムとして「分散されたモノリス」という状態の課題を抱えている 理想を「日本一のデータとシステムを持つ事業とそれを支えるアーキテクチャ」と定義 そこに紐づくTobeを目指してレバテックを再設計していく CTO室の今後 今後、CTO室は上記の課題から以下の軸をベースに強化していきます。まだまだ具体的な目標などは決められていませんが、以下を軸にCTO室の役割を拡大していけたらなと考えております。 事業戦略に紐づいたシステム戦略のリード テクニカルとドメインを掛け合わせたドメインの最適化 事業横断した組織・システムの最適化 開発者生産性の向上 事業戦略に紐づいたシステム戦略のリード CTO室は、今後ますます事業戦略に連動したシステム戦略を主導する役割を果たします。この取り組みにより、技術戦略がビジネスの長期的な目標と一致し、我々の競争力を向上させ、新たな市場機会を探求します。「日本最大級のIT人材プラットフォームの進化を支える」組織やシステムを構築し、戦略的な成長を支えることを目標に進んでいきます。 テクニカルとドメインを掛け合わせたドメインの最適化 テクニカルな専門知識とビジネスドメイン知識を融合させて、ドメインの最適化に取り組みます。このアプローチにより、特定のドメインに特有の課題に対処するための優れたソリューションを提供します。そこで、レバテックの事業/開発双方の戦略及び戦術に基づく特定のテクニカルドメイン領域における信頼されるスペシャリストを多く輩出していき、新たな可能性を切り拓きます。 事業横断した組織・システムの最適化 CTO室は、組織とシステムを結びつけ、情報共有と協力を促進し、事業全体での最適化を実現します。これにはイネイブリング、SRE、QA、アジャイルCoEによる事業を横断した組織・システムの強化が必要です。冗長性の排除やリソースの最適利用、可観測性の向上により、より効果的に運営し、ビジネス目標の達成を目指します。 開発者生産性の向上 CTO室は開発者生産性の向上に注力します。新しいツール、プロセス、トレーニングを提供し、開発者がより効果的に作業できる環境を整備していきます。これにより、イノベーションが促進され、プロダクト開発をより支援できたらと考えています。 ゆくゆくはエンジニアが選ぶ「開発者体験が良い」イメージのある企業「Developer eXperience AWARD 2023」ランキング上位5にランクインに向けて取り組みを進めていきたいと考えております。 さいごに これらの目標を達成するために、CTO室は積極的な取り組みを進め、テックカンパニーとしてより高いレベルの開発組織にしていきたいと考えています。現在、一緒にCTO室を推進していただけるエンジニアを募集しています！ご興味のある方はぜひ こちら からご連絡ください！

レバレジーズ株式会社 HRテック事業部の桐生です。 アプリケーション開発において、重たい処理の高速化は避けては通れない課題の一つですが、なんとなくで取り組んであまり良い結果が得られなかったり、そもそもどこから手をつけていいか分からなかったりすることもあるかと思います。 本記事では、処理の高速化を上手に行うための流れと、各ステップで抑えるべきポイントをご紹介します。 実際に私が携わっていたプロダクトでも、今回ご紹介する流れに則って高速化に取り組み、 最終的に処理時間を40倍以上高速化することに成功しました 。こちらの具体的な事例も含めて詳しくご紹介しますので、ぜひ最後までお読みいただければと思います！ なお、こちらは6月に開催されたレバレジーズ テックフェスにて発表させていただいた内容と同じものです。 大まかな流れ 以下の流れで処理の高速化を行っていきます。 無駄を含む処理を見つける 処理の遅い原因を特定する（計測） 高速化のための手段を考え、実装する 実装した高速化の効果を測定する 「無駄」を含む処理を見つけるには？ 遅い処理を目の前にした時に、まず考える必要があるのは「この処理に削れる無駄は残っているか？」ということです。当たり前の話ではあるのですが、既にリソースを十分に使い切っている処理を高速化するのは難しいためです。 「無駄」が存在していることを判断するのに重要なのが、処理内容から考えてどのくらいの時間がかかりそうかを予測し、それを実際の処理時間と比較することです。「こういう処理だからこれくらいの時間がかかりそう」という予測を精度良く行うことで、無駄を見つけることができるようになります。 処理の性質ごとにかかる時間を計算する 処理時間を見積もる際には、「どんなリソースで」「どれくらいの量の」処理を行っているかに着目します。例えば、多くの処理で使われるであろう「CPU」「ストレージ」「ネットワーク通信」は、以下に示すように1回の操作にかかる時間が非常に大きく異なります。 このため、処理の性質によって以下のように見積もりを変える必要があります。 計算処理が中心の処理の場合、時間がかかると感じるには少なくとも 数百万回〜数千万回程度 の計算ステップが必要になります。ソート処理や大規模な文字列処理、および画像処理等はこれに該当することがありますが、一般的な業務アプリケーションでこのレベルの計算負荷を求められる場面は比較的まれといえます。 逆に、ストレージ・ネットワークアクセスが中心の場合、もっと小さな数字でも時間がかかる場合があります。 処理時間を概算してみる 上記を踏まえて、実際に処理時間を見積もってみましょう。例として、以下のような処理を想定します。 1000件/ユーザーのデータを、100ユーザー分集計する 集計は単純な平均・合計等 データはDBサーバーから取得する この場合、行われる処理は以下のように分類できます。 CPUでの計算: 1000×100 = 10万のオーダー → 1秒は決して超えない データ取得: NW通信1回 + 読み出しに1秒〜数秒？ これらのことから、どんなに長くても数秒〜10秒程度で完了することが予想できます。よって、これよりも遥かに長い時間がかかっている場合はほぼ確実に無駄が潜んでいると考えられるわけです。 このように、処理内容から想定の処理時間を見積もることで、無駄を含んでいる処理を見分けることができます。 計測せよ！ 無駄を含んでいそうな処理を特定できたところで、次はこの処理を速くしようという話になるわけですが、ここでやってしまいがちなのが「何となくここが遅そう」という推測だけで高速化に手をつけてしまうことです。しかし、これは次に示すように、可能な限り避けるべきです。 ロブ・パイクのプログラミング5カ条 プログラミング界隈で有名なロブ・パイクの「プログラミング5カ条」より、処理時間に関する2つのルールをご紹介します。 ルール1: プログラムがどこで時間を消費することになるか知ることはできない。ボトルネックは驚くべき箇所で起こるものである。したがって、どこがボトルネックなのかをはっきりさせるまでは、推測を行ったり、スピードハックをしてはならない。 ルール2: 計測すべし。計測するまでは速度のための調整をしてはならない。コードの一部が残りを圧倒しないのであれば、なおさらである。 (引用元: http://www.lysator.liu.se/c/pikestyle.html ) ここで述べられている通り、処理の重さが具体的に何に起因するのか、推測によって特定するのは非常に困難です。このため、推測によって作業に手をつけると、 全く遅くない箇所を一生懸命高速化する という事態に陥る可能性があるのです。 このように、高速化を行う際には「どこが遅いのか」を計測して特定し、処理時間の占める割合が大きいところを削っていく必要があるのです。 処理時間の計測のための手法はいろいろと存在しますが、ここでは代表的なものを2つご紹介します。 タイマーによる計測 一つ目は非常に愚直な方法で、処理の前後の時刻(タイマーの値)を記録することで処理時間を計測する方法です。 例として、JavaScriptのDateクラスを使って処理時間を計測する方法を示します。 function run() { // 開始時の時刻を記録 const startTime = Date .now(); someHeavyWork(); // 終了時の時刻を記録 const endTime = Date .now(); // 経過時間は、終了時時刻 - 開始時時刻 で求められる const elapsedTime = endTime - startTime; console.log(‘someHeavyWork:’, elapsedTime, ‘ms’); } Date.now()を呼ぶことで、その時点での時刻(ミリ秒単位)を記録することができます。今回は例としてJavaScriptの機能を用いましたが、他の言語でも現在時刻のタイムスタンプを取得する関数(PHPのmicrotimeやRubyのTime.now等)を用いることで同様に計測できます。これを利用して処理の開始時・終了時の時刻を計測し、その差を取ることで、間に挟んだ処理にどのくらいの時間がかかったかを知ることができます。 ※なお、JavaScriptの場合は console.time という関数を用いることでより簡単に時間を計測することができます。詳しくはMDNの該当ドキュメントをご参照ください。 このような時間の記録処理を、重い可能性のある処理の前後に挟むことで、実際に重い部分を絞り込んでいきます。(最初は大きめの範囲を挟んで、徐々にその範囲を狭めていく) この方法は非常に原始的なので、どんな処理にでも適用できるという良さはあるのですが、その反面、計測処理を手動で挟んでいく必要があるため手間がかかります。次に紹介するプロファイルを用いると、手動で処理を挟まずに時間を計測することができます。 プロファイラの活用 プロファイラとは、関数ごとの処理時間を自動で記録してくれるツールです。プロファイラを用いると、プログラム実行中の関数呼び出しを追跡して、時間のかかっている部分を特定することができます。大抵のプラットフォームではそれぞれのプラットフォームごとに専用のプロファイラが存在しており、例えばNode.jsプロファイラを使って計測を行うと以下のような出力を得ることができます。 各関数の中でかかった時間が帯状に表示されています。また、グラフの上下関係は関数の呼び出し関係を表しています。下側にいくほど関数の呼び出し階層が深くなっていっています。 今回用いたNode.jsプロファイラの使い方の参考記事: Node.js の CPU プロファイリングでボトルネックを特定する –- 今回は処理時間を計測する方法を2つご紹介しました。これらを用いて実際に遅い箇所を特定したら、ついに実際の高速化作業に取り組むことになります。 高速化に王道なし いよいよ実際の高速化作業を行うわけですが、プログラムが遅い原因というのは実に様々で、そのため、高速化のための普遍的な手法も存在しません。ただ、それだけで説明を済ませてしまうのも寂しいので、今回は私が実際に関わった高速化の事例をご紹介して、高速化作業のイメージを掴んでいただこうと思います。 事例：月次処理の高速化 １つ目にご紹介する事例、給与計算ソフトにおける月次の勤怠締め操作の高速化です。こちらは会社ごとの全社員の勤怠データを集計して給与額を計算する処理なのですが、会社あたりのユーザー数が増加すると、計算完了まで何分もかかってしまうという問題がありました。 処理時間の見積もり まずは、本来の処理時間を見積もってみます。具体的にかかっていた時間ですが、例えば300人程度の会社ですと7分以上かかっていました。ただ、実際に処理するデータの量を考えると以下のようになり、大きな乖離が生じています。 300人 * 30日 = 9000個の勤怠データの集計 + 過去の有給使用データ(300人 * 数十件 = 数千〜1万件)の集計 集計は基本的には時間を累積していくのみ 実際は営業日は30日もないので多めに見積もっている データの取得等含めて考えても何十秒もかかるのですらおかしい 数万件のデータの取得(数秒) + データ処理(1秒以内) + 数万件のデータの書き戻し(数秒)にしかならないはず これを踏まえると、この処理はまだ高速化の余地があると判断できます。 遅い箇所の特定 次に、実際に何が遅い原因となっているかを計測して調査します。処理部分にログを仕込んで計測した結果、DBのデータ読み書きに大半の時間を費やしていることがわかりました。 さらに詳しくコードを調査した結果、以下の2つの原因が判明しました。 特定のテーブル(大きめ)にインデックスが張られていなかった 1ユーザーの処理ごとに大量のクエリを発行していた それぞれ詳しく説明します。 テーブルにインデックスが張られていなかった 今回の遅かった箇所の一つが、勤怠集計データを保持するRDBテーブルからのデータ読み込みです。読み取っているデータはユーザーごとに数十件程度なのですが(1ヶ月分のデータしか読み取らないため)、読み取りに異常に時間がかかっていました。これは当該テーブルに必要なインデックスが張られていなかったことが原因です。 データベースから条件で絞ってデータを取得する場合、何も設定しないとテーブル全体を検索するため、テーブル全体のデータ量に比例した時間がかかってしまいます。このため、通常は検索したいカラムに インデックス を張ることでこの時間を一定に抑えるのですが、今回操作していたテーブルでは検索対象のカラムにインデックスが張られていませんでした。このテーブルには過去の全ての勤怠データが保持されており、その総レコード数は数十万にも及んでいたため、不要なデータに対して検索をかけており時間がかかっていたのです。 対処法としては、単純に検索対象のカラムに有効なインデックスを張るだけでした。この対処だけで処理時間が元々の3分の1程度にまで減少しました。 1ユーザーごとに多数のクエリを発行していた もう一つの原因が、1ユーザーごとにデータの取得・書き出しクエリを発行していたことです。今回の実装においては、1ユーザーごとに必要なデータを全てデータベースから取得しており、また結果データの書き込みも1行ずつ行っていたため、結果的にユーザーあたり100以上のクエリを発行しており、トータルで何万件ものクエリを発行してしまっていました。これによりネットワーク通信待ちとクエリ実行のオーバーヘッドで大きく時間がかかってしまい、何分も処理に時間がかかってしまっていました。 対処法としては、予め処理対象のユーザーのデータをまとめて取得することによりクエリ発行回数を減らしました。また、書き戻しの際もある程度まとめて書き込みクエリを発行するようにしました。 上記2つの施策を行ったことにより、計算アルゴリズムには一切手を加えませんでしたが、最終的に10秒程度まで処理時間を短縮することに成功しました。 事後の計測を忘れずに 高速化作業を行った後は、それが本当に高速化に寄与したかどうかを必ずチェックするようにしましょう。特に、2つ以上の変更を行った場合は、両方の変更に効果があったかどうかをそれぞれ調べないと、効果のない変更を入れ込んでしまうことがあります。実際に自分が高速化を行った際にも、片方の変更は高速化に寄与していたが、もう一方の変更はむしろプログラムを遅くしてしまっていた、という場合がありました。 高速化のためのコード変更というのは一般的にコードをより複雑にしてしまうものなので、効果のないコードはなるべく排除するようにしましょう。 まとめ ここまでで、処理高速化のための大まかな流れを一通りご紹介しました。見積もりと計測に基づいて高速化作業に取り組むことで、より高い精度で作業を行うことができるようになるはずです。 本記事の内容が少しでも皆様のお役に立てば幸いです。最後までお読みいただきありがとうございました！

はじめに こんにちは、レバレジーズ株式会社の堀本・中村です。本記事では私たち2人が運営側として参加したレバレジーズグループ全体のエンジニアが参加するテックフェスの様子をご紹介します。基調講演や、社員によるトークセッションなどについて書いていますので、ぜひ最後までご覧ください。 堀本自己紹介 私は2020年4月にレバレジーズへ新卒入社し、グループ会社であるレバテックでの法人営業を2年間経験したあと、レバレジーズのエンジニアに異動しました。現在は社内業務効率化のツールを開発しています。 中村自己紹介 私は2022年4月にレバレジーズに中途入社し、医療介護領域のオウンドメディアを中心に開発に携わってきました。現在は、レバウェル事業部にてSRE業務に取り組んでいます。 テックフェスとは レバレジーズグループに所属するエンジニアを対象に、社内で半年に一度行われている技術の祭典です。エンジニアが新しい技術に興味を持ち、勉強をするきっかけを作ることを目的とし、グループ全体の技術力向上を目指します。6月7日に「急がば品質。ワンランク上のレバクオリティへ」というテーマでテックフェス2023春を開催しました。 基調講演 概要 基調講演については堀本がお話ししていきます。 「いかに開発効率と品質を高めるか：ドメイン駆動設計と組織パターンの視点から考える」という題名で、現代のソフトウェア開発に求められる効率性と品質の重要な要素である、ドメイン駆動設計（DDD）と組織パターンについて加藤潤一さんにお話しいただきました。 登壇者紹介 ドメイン駆動設計や関数型プログラミング、アクタープログラミング、OSGiなどのモジュラープログラミングを研究しており、執筆活動や講演、OSSの開発などに取り組んでいる。 Chatwork株式会社テックリード。ZOZO技術顧問。 技術評論社 WEB+DB PRESS Vol.63~68 再考するJava 執筆。 日経BP社 日経ソフトウエア 特集 特集2 〜5 執筆。 日経BP社 Javaツール完全理解 第2部　最新Eclipseで良いJavaプログラムを書こう 執筆。 ライブラリ Baseunits for Scala 作者。 学んだこと DDDについては、DDDの基本原則や主要な概念の説明から始まり、どのようにアーキテクチャのパターンに影響を与えるか、またDDDが開発の効率化と品質向上にどのように寄与するかを学びました。 その後の組織パターンについては、どのようにドメイン設計と相互作用し、開発効率の向上に寄与するかを詳しくお話しいただきました。 DDDのお話の際には、ユーザ側にとって重要な部分は必ずしもコアドメインに該当しないとおっしゃっていて、事業側とユーザの価値は別であることに気をつけなければならないと思いました。 内容についての感想 講演の終盤では実際の開発現場で、どのように適用して具体的な成果を出すかまで説明していただき、DDD と組織パターンの理解を深め、開発効率と品質の向上に役立てられそうな有意義な内容でした。 加藤さんがテックリードをされているChatworkでの取り組み事例まで知ることができ、具体的にイメージすることができました。 テックバトル 概要 テックバトルとは テックバトルについては中村がお話ししていきます。 テックバトルとは、エンジニアがチームに分かれて共通の課題に取り組み、そのスコアで競い合うイベントです。テックバトルは以下を目的として実施します。 楽しむこと テーマを意識し、業務改善に活かすこと チームワークの強化 舞台設定 今回は、「品質」をテーマとして課題を作成し、実務でもあり得そうな以下の舞台設定にしました。 ​ 皆さんはSFA開発チームのエンジニアです。 流入求職者の情報をシステムへインポートしたいです。 しかし、そのままではインポートできず、変換が必要です。 ​ 必要な変換処理が他部署のAPIで実装されていたため、 他部署のAPIを利用して変換することにしました。 ​ しかし、APIにはバグがありました。 バグにより出力データが意図しない結果となるため、 正しい形に変換するプログラムを作ることになりました。 ​ また、APIにバグが多く他部署メンバーも困っているので、 いろいろな入力値でデバッグして協力することになりました。 課題の詳細 以下で、今回取り組んだ課題を紹介させていただきます。 取り扱うAPIは2種類存在しており、それぞれの出力結果に誤りがあります。 参加者が、それぞれのAPI出力を正しく修正するプログラムを作成して処理の中に差し込み、修正済み出力結果を回答として提出します。 また、それぞれのAPIに対して特定の入力値を与えると、あらかじめ用意された例外コードが返却されます。これをできるだけ見つけ出すのも課題の目的になります。 運営側が用意していない例外を見つけた場合には、報告することでボーナス点が入ります。 上記のルールで、1チーム3〜4人の制限時間2時間で開催しました。 バトル中の様子 各チーム、活発にコミュニケーションをとりつつ、役割分担をして課題に取り組んでいました。修正プログラムの実装とエラー調査で分けているチームが多く、全体統括に人員を割いているチームもありました。 上位のチームは、作業内容の認識合わせを丁寧に行いつつ素早く役割分担をすることでタイムロスを削減していました。これは実務でも活かされる動きですね。 セッション セッションについては堀本がお話ししていきます。 今回のセッションでは3名の方が、幅広い分野の発表をしました。 speakerdeck.com speakerdeck.com speakerdeck.com 最優秀の発表について 最優秀の発表は Nalysysグループの桐生さんの「その処理、本当に遅いですか？ ~無駄を省く達人になろう~」でした。問いかけられる題名から興味を惹かれます。 発表内容 処理高速化のアプローチを下記4段階に分けて説明しました。 「無駄」のニオイを感じ取る 処理の遅い原因を特定する（計測） 高速化のための手段を考え、実装する 実装した高速化の効果を測定する 感想 処理を高速化する方法は原因や状況に応じて異なるため泥臭くやっていく必要があるとした上で、実際に桐生さんが関わった高速化の事例を紹介してくれました。発表で特に印象に残ったのは、無駄を感じ取るためには処理時間の予測精度を上げることが必要で、計算量について学ぶのと、より細かい内部の仕組みを学んで予測するセンスを磨くことでした。もちろんこの後に予測だけで終わるのではなく、計測までするようにとおっしゃっていました。この2つを勉強して、まずは無駄を感じ取る嗅覚を磨いていきたいと思います。 LT LTについては中村がお話ししていきます。 発表一覧 今回のLTでは6人の方が、幅広い分野の発表をしました。 speakerdeck.com speakerdeck.com speakerdeck.com speakerdeck.com speakerdeck.com speakerdeck.com 最優秀の発表について 品質よりリリース優先した末路 (山城 直輝さん) 概要 こちらの発表では、品質よりリリースを優先して実装すると何が起こるのか3つのケースで紹介いただきました。具体的に紹介されていたケースは、以下の通りです。 不具合修正のために本番環境のコードを直接いじる 過去に修正した不具合が再発する インフラ環境構築をIaC使わずにGUIで作成 手順も残してないため、環境が壊れても再現できない エラーレベルを考えずにエラー通知を設定 通知が多すぎて重要エラーに気づかない 実際にやってしまったり見かけたことがあったりと、身に覚えのあるエンジニアは多かったようです。 学んだ/考えたこと 初めて使用するインフラリソースだと、まずGUIで作ってみてからIaCで再現するという手順を踏むこともあると思います。できることなら一からIaCで頑張るか、GUIでの設定を並行してIaCで書いていくのも一つの対策になると考えました。全体を通して、 「一旦〜」「とりあえず〜」「後で〜」は封印しなければならないと感じました。 DRY原則を誤った結果生まれた技術的負債 (野中 柊さん) 概要 こちらの発表では、「teratail」での事例を元に、単一責務を考慮せずに誤ったDRY原則に従って実装した際の問題点と改善方法を紹介いただきました。 具体的には、一つのコンポーネントに <a> タグと <button> タグを出し分けさせていた事例でした。これにより以下の問題点が生じます。 内部コンポーネント制御用のPropsが際限なく追加される 制御変数が多くなりすぎて内部実装が複雑になる 他のライブラリの組み込みがしづらくなる 学んだ/考えたこと 以前Atomic Designで実装していたプロジェクト参画時に、大量のPropsを持っているボタンに遭遇しました。どこが再利用したい部分なのか分かりづらく、Propsでの制御量が多すぎて一から定義しても変わらないのでは・・・と感じるほどでした。今回の発表に照らして考えてみると、 実は <a> タグなどの別タグとして切り出すべき機能を持っていた ボタンとしても単一責務を考慮してコンポーネント分割できた という可能性があります。DRYと単一責務はあらゆるところについて回るので、注意して実装を進める必要性を感じました。 懇親会 テックフェス終了後は、懇親会も開催。ピザやお寿司、ケーキを食べながら発表者へ話を聞きに行ったり、他チームの方と交流を深めている様子が見られました。 最後に 今回の記事では、テックフェスから学んだことや感想を書かせていただきました。加藤潤一さんの貴重なお話を聞けたり、社内のエンジニアから普段は聞けない話を聞けて非常に面白かったです。 社内で技術ノウハウの共有を行なうイベントがあったり、外部から著名な方をお呼びして貴重な話が聞ける環境のレバレジーズで皆さんも一緒に働いてみませんか？ レバレジーズに少しでも興味を持っていただけた方は、こちらからエントリーをお願いします！

はじめに 本記事をご覧いただきありがとうございます。レバレジーズ株式会社 レバテック開発部の三浦です。 4月中旬〜6月末までの2ヶ月半にかけて、弊社レバテック開発部にて「フロントエンドエンジニア育成PJ」と題してフロントエンドをリードできる人材を育成するプロジェクトに参画しましたので、その内容についてご紹介します。 背景 現在、レバテックでは理想のシステムを目指して大規模リニューアルを計画的に進めており、フロントエンドをリードできる人材を増やすことで、よりリニューアルの加速を図ろうとしています。 そこで、フロントエンドエンジニア育成PJでは2ヶ月半という期間でがっつり育成にコミットし、まずは自走しつつ一定の品質でアウトプットできるところまで育成対象者のレベル引き上げることをゴールとしました。 方針としては以下の領域（赤線部分）のベースとなる知識を得るために広く浅く伸ばしていくイメージです。 ※「 モダンフロントエンド開発者に求められるスキルとは 」より引用 実際には、TypeScript + React + Next.js + MUI で実際に開発しつつ、上記の領域を学習をしつつ社内に発信するということをやっていました。具体的な内容については後述します。 プロジェクトに参画した育成対象のメンバーは私含め4名でした。いずれもフロントエンドの経験が浅いメンバーで、レガシーな環境で開発をしていたメンバーから営業から異動してきたメンバーまでバックボーンは様々です。 私は人から感謝される仕事がしたいと考えていたため、業務としてより人に近いマネジメント業務をメインでこれまで担当していました。ただ、マネジメント業務を経験していく中で、エンジニアとして人から感謝される価値のある仕事をするためには、しっかりとした技術的なバックボーンが無くてはいけないのではと考えるようになりました。 その中で、上長からこのプロジェクトへの推薦をいただいたことをきっかけに参画に至りました。ちなみに、フロントエンドの経験としてはHTML／CSS／jQueryを多少かじったことがある程度でした。 カギとなったのは圧倒的アウトプット量 このプロジェクトで特筆すべきはとにかくアウトプットにコミットし切ったという点です。 ざっくり2ヶ月半でのアウトプットを並べると以下の通りです。 GitHubと連携した開発生産性可視化アプリケーションの新規開発（1ヶ月） 既存で稼働している営業支援ツールのリプレイス（1ヶ月） 4冊の書籍とtype-challengesの内容でQiita記事を作成（計48記事） 4冊の書籍とtype-challengesの内容で社内勉強会を開催 週1回のレビュー会での成果物のプレゼン 開発生産性可視化アプリケーションの新規開発 まず最初の1ヶ月で以下のような開発生産性を可視化するアプリケーションを開発しました。 ここ最近で弊社の開発組織では開発生産性を可視化したいという気運が高まってきており、その流れを汲んで社内向けにTypeScript + React + Next.js + MUIで構築しました。 このアプリケーションはGitHubと連携しており、GitHubから取得したデータをもとにFour Keys Metricsやその他PR数などの生産性に関わる指標をグラフで可視化できるようにしています。 営業支援システムのリプレイス 開発生産性可視化アプリケーションを社内リリースした後の1ヶ月で、以下のような既に稼働している営業支援システムのリプレイスを行いました。 こちらはレバテックキャリアに登録した求職者が、求人に応募したりエージェントから求人の提案を受けたりすることができるシステムですが、こちらもTypeScript + React + Next.js + MUIの構成でリプレイスしました。 前述した開発生産性可視化アプリケーションでは社内向けということもあり比較的シンプルな仕様でしたが、こちらは実際にサービスとして長らく本番稼働しているシステムであったため、プロダクションコード特有の複雑なロジックの実装を経験することができました。 Qiita記事の作成 上述した2つのシステム開発と並行して、 type-challenges と以下の4冊の書籍を学習しその内容をQiitaの記事としてまとめました。 プロを目指す人のためのTypeScript入門 （通称 ブルーベリー本） TypeScriptとReact/Next.jsでつくる実践Webアプリケーション開発 フロントエンド開発のためのテスト入門 フロントエンド開発のためのセキュリティ入門 作成した記事は計48記事で、個々人が1ヶ月に6記事を開発と並行して作成した計算になります。作成された記事は社内に公開されており、React や Next.js を採用している開発チームでも技術のキャッチアップで利用されています。 社内勉強会の開催 学習した内容をもとに、社内で勉強会を開催しました。育成メンバーは全員登壇し、各々で学習した内容をプレゼンしました。 speakerdeck.com このようなスライドをもとに発表しましたが、弊社ではTypeScriptを採用している開発が多いため、特にtype-challengesの内容が反響がよかったです。 週1回のレビュー会でのプレゼン これまで述べた開発と学習に関して、記事の作成や勉強会とは別に週1で成果物のレビュー会も実施しました。 こちらは実際の様子を写真等でお見せできず残念ですが、組織のマネージャーとテックリードを招き開発した機能をデモで見せたり、学習した内容についての学びや気づきを共有し、アドバイスをもらうことを実施しました。 育成チームの成果物を週次で社内にSlackで公開し、アウトプットした成果も共有しました。 弊社は挑戦する人を否定せず讃える文化が浸透しており、Slackなどで多くのポジティブなリアクションをもらうことができたため、最後までモチベーション高くやり切ることができました。 プロジェクトを通して見えた可能性 私自身、このプロジェクトに参画する前は、開発でフロントエンドに絡む課題や要求が発生した際は解決策がわからず、現場の業務委託や他チームの有識者に技術的なアドバイスやヘルプをよく求めていました。 しかし実際にプロジェクトを終えてみて、フロントエンドに対する自己効力感が明らかにつき、大抵のことは自走して解決できるようになった実感があります。これは、2ヶ月間フロントエンド開発にどっぷり浸かり、とにかく多くのアウトプットを出しまくったことから生まれた自信や成長によるものだと考えています。 現在は新しいプロジェクトに参画し、チームメンバーと日々設計に関する議論を交わしつつ、Next.jsのApp Routerを利用した開発に取り組んでいます。 フロントエンドエンジニア育成PJを通して得た経験はあくまでもきっかけでしかないと思っています。組織のフロントエンド開発の先頭に立ち、もっとエンジニアリングのアツい組織にしていけるよう盛り上げていきます。 おわりに ご覧いただきありがとうございました。弊社では今組織としてエンジニアリングへの積極投資を進めており、フロントエンドエンジニア育成PJもその文脈にある取り組みです。 前述の通り挑戦を否定せず賞賛する文化があり、やりがいという面でもポジティブにチャレンジできる環境があります。 この記事を通して少しでも弊社に興味を持って下さった方はぜひ 採用サイト をご覧ください！

はじめに 　こんにちは、レバレジーズ株式会社テクノロジー戦略室室長の竹下義晃です。 エンジニアの生産性を高めよりよいサービスを提供するために、エンジニア全員にGitHub Copilotを導入しました。今回は導入過程でわかったGitHub Copilotを使いこなすための知見を赤裸々に公開していきたいと思います。 GitHub Copilot全エンジニア導入背景 会社の方針 　レバレジーズでは主要サービスである レバテック や レバウェル 、 CareerTicket 、 WeXpats などの人材サービスをはじめ、最近ではオンライン診療サービスの レバクリ をリリースするなど国や業界に関わらず事業拡大を進め、理念である「顧客の創造を通じて、関係者全員の幸福を追求し、各個人の成長を促す」を追求しています。そのために、開発組織を強化し、より早くより良いサービスの実現を目指しています。 　近年、 GitHub Copilot を始め、 OpenAI ChatGPT や Google Bard など様々なGenerative AIが登場しており、AIを業務に取り入れることで、業務の効率化が様々な分野で進んでいくと考えられます。我々は現在パラダイムシフトの真っ只中にいると考えており、この新しい技術をいかに使いこなしていくかが今後の成功の鍵を握っていると考えています。そのため、まだ評価の固まっていない技術ではあるものの、社内でAIガイドラインを策定し、最大限AIを活用していきたいと考えています。 GitHub Copilotの選定 　GitHub Copilotを選定したのは、Generative AIの中で現時点で最もエンジニアリングの効率化に効果が高いと考えたためです。 主な理由は以下の4点です。 フローを維持できるため、業務効率を下げず、開発者体験の向上につながる (おそらく)コード生成AIとして最も性能が良い GitHubが出した調査結果も、良好な結果 個人でも使っているがとても便利 フローを維持できる 　導入した結果業務効率の低下が起きてしまうと意味がありません。GitHub Copilotは各種IDEのプラグインが提供されており、弊社で利用しているVS CodeやIntteliJ、PHP Stormを始め主要なIDE、テキストエディタに対応しています。そのため、IDEの中だけで完結するため、エンジニアのフローを妨げません。Copilot不慣れな場合でも、普通に使うだけで強力な補完機能として利用開始できるため、業務効率を下げる可能性は低いです。 　また、ChatGPTなどのWebサービス型のGenerative AIの場合は、ブラウザと言ったり来たりするためフローを崩してしまい、業務効率を低下させてしまう可能性があります。さらに、適切なタイミングで適切なプロンプトを記述して質問を投げるスキルも必要なため、ある程度のAIリテラシーが無いと効率が上がりきらない可能性もあります。 コード生成AIとして最も性能が良い 　コード生成AIとしては、他には Amazon CodeWhisper が有名です。性能比較はしていないのですが、 こちらの記事 だと日本語が怪しかったり、 動きがもっさり だったりするようで、アルゴリズムもChatGPTで、学習データとしてもGitHubのデータをファーストパーティーとして使えるGitHub Copilotが最も性能が良いと判断しました。 GitHubが出した調査結果 　データとしても、 GitHubの調査結果 が公開されており、そこでも開発効率が上がったとレポートされています。 個人でも使っている 　GitHub Copilotが出た直後から個人で趣味の実装時に使っていました。体感値としてもGitHubの調査と乖離もなく、かなりコーディングの効率が上がった実感がありました。 導入過程 　とはいえ、レポートが外部の情報しかなく、いきなり全エンジニアに展開するのは難しかったため、まずは一部のチームにだけ提供し効果測定を行いました。チーム単位でいくつかのチームに導入し、3週間ほど試用してもらった上で定性評価のためのアンケートの実施を行いました。その結果、開発効率が下がったという人はおらず、9割以上の人が開発効率が上がったと回答したため、全エンジニアへの導入に踏み切ることにしました。 アンケートから見えた開発効率を高める方法 分析手法 　分析のために、試用してもらったチームメンバーへアンケートをとりました。アンケート項目は、効率化したかどうかより、高い効率化に成功した人がどのような使い方をしているか、またはどのような環境、状況で使用しているかを見つけることに焦点を当てて作成しました。 　アンケートでは以下の項目を聞きました。 items 　アンケート結果は、python+pandasを使用し数値化と、one-hot encoding(ダミー化)処理を行った後、Googleスプレッドシートで、平均値等の統計分析や、各アンケート項目同士の相関値マップを作成しました。(pandasでは こんな感じの処理してます ) 結果 統計値 　Copilotの継続利用は評価1~5で、平均4.51でした。また、コーディング効率が上がったかどうかは、下がったと答えた人は0人、1,2割以上上がったと答えた人は全体の70%に達しました。 rating coding_efficiency カラム間相関値マップ corel-map 赤枠で囲った列が、コーディング効率との相関を示しています。黄色く囲ったあたりが相関値が高く出ており 生成コードを、レビューはするが修正はせずに利用 テストコードの作成での効率が上がった人 それぞれ、0.5、0.4程度の相関値になっています。 そのため、次のことが言えると考えています。 GitHub Copilotの生成コードをそのまま使っている人ほどコーディング効率が向上する テストコード生成に使った人がコーディング効率が向上する フリーテキストからの考察 　高い効率化ができたと感じている人のコメントだけを抜き出し、共通項を探しました。そうしたところ、コメントを書いてコードを生成、または、コードからコメントを生成している人が多くいました。 結論 結果を箇条書きにすると 9割の人が導入に満足している GitHub Copilot導入により開発効率は下がった人はいない 7割以上は体感できるぐらいコーディング効率が高まった GitHub Copilotの生成コードをそのまま使えている人ほどコーディング効率が向上する テストコード生成に使った人がよりコーディング効率が向上している 効率が大幅に上がった人は、コメントを書いてコードを生成、または、コードからコメントを生成に利用している 　現時点でGitHub Copilotを上手く使うコツとしては、テストコードの生成や、コメントからのコード生成、コードからのコメント生成などを中心に、人が修正しなくても良いコードを上手くGitHub Copilotに生成させられれば、高いコーディング効率の向上を見込めるということが言えるかと思います。 余談 GitHubのActivityはまだ分析できていない 　GitHubのActivityも収集し分析も進めていますが、まだ定量的な結果までは出せていません。今後も継続してデータ収集していきたいと考えています。一応、「Copilotを使うチームの出すPullRequest数が、Copilotを使っていないチームより多くなった」ことに有意差は出ていました。定量的な結果とは言えず、データの正確性も検証しきれていないので、参考までにお願いします。 費用対効果(クソ雑概算) 　GitHub Copilot for Businessは月額$18で年間$216、執筆時点の為替1ドル142.46円では日本円にして30771.36円です。 　一方、日本のITエンジニアの平均年収は442万円となるため、その平均から算出される年間3万円分の効率化達成には、 3 / 442 = 0.006 = 0.6%となり、0.6%以上効率が上がるならGitHub Copilotを使うほうがお得となります。定量評価は難しいものの、0.6%以上の作業効率は上がると確信しています。 よりGitHub Copilotを使いこなすためのネクストアクション 全エンジニアでのノウハウの共有の取り組み 　個々で見つけたコツや使い方を共有し、昇華していければと考えいくつかの施策も継続予定です。 常設アンケートと、テクノロジー戦略室による使い方のコツのサマリー共有 　常にGitHub Copilotを上手く使うコツを収集するアンケートを用意し、そこに投稿された内容を毎月サマリーして共有していく予定です。 ノウハウ共有LTの開催 　また、ノウハウ共有の強化としてLT大会も開催を考えています。ライブコーディングなどを通じて、文章だけでは伝わりづらい使い方も共有していければと考えています。 追加分析 　 全エンジニア拡大後に再度アンケート実施 　 　全エンジニア展開後に再度アンケートは実施予定です。 GitHubでのActivityの分析の継続 　定量的な分析も引き続き行っていきたいと考えています。アンケートからだけでは分析できにくい、言語やドメイン領域など様々な観点からの分析や、アンケート結果の裏付けを行っていければと考えています。 おわりに 　GitHub Copilotの全エンジニア導入により、ユーザーにより早く、より良いサービスを提供できるようになるだけでなく、エンジニアにとっても、開発者体験の向上によってより楽しくサービス開発してもらえると良いなぁと思っています。 　今回はGitHub Copilotの採用とはなりましたが、他にも様々なAIサービスが登場しています。また、社内現在のAIを取り巻く環境はどんどん進化を続けており、もっと良いサービスも出てくるかもしれません。なので、今後もトレンドを追いつつ(追い抜きたい)、どのようにAIを活用すればよいかを探求し続けたいと思っています。 We Are Hiring! 　レバレジーズ株式会社ではエンジニアを募集中です。AIを活用しながらの開発や、AIの活用方法を考えることに興味ある方は、是非 こちら のページからご応募ください。

レバレジーズ株式会社 システム本部の田中です。 2023/7/11に、ココナラさん、ニフティさんと、フロントエンドをテーマに合同勉強会を開催しました。 以前に エイチームさんと開催した合同勉強会 に続きいて今回も connpassで一般公開 し、ココナラさん、ニフティさんを弊社の渋谷本社にお招きしてオフラインでの開催でした！ この記事では、弊社のエンジニアの発表内容を簡単にご紹介したいと思います。 発表内容 弊社からは、私を含めて3人が発表しました。 speakerdeck.com フロントエンドをリードするエンジニアの育成を目的としたPJで取り組んだことについての発表です。 speakerdeck.com AWS CognitoとAmplify SDKを使ってフロントエンドの認証処理を爆速で実装したという発表です。 speakerdeck.com Next3、TypeScript、urqlを使ってmonorepo構成で新規プロダクトの開発に取り組んだことについての発表です。 We are hiring レバレジーズ株式会社ではフロントエンドエンジニアも、それ以外のエンジニアも幅広く募集中です。 もし今回の勉強会の発表を見てご興味を持っていただけたなら、 こちらのページ からご応募ください。 勉強会の開催も随時受け付け中です 今回はフロントエンドをテーマに合同勉強会を開催しましたが、レバレジーズはオールインハウスで開発しておりフロントエンド、バックエンド、インフラ、機械学習と幅広い領域をカバーしているので、フロントエンドに限らず様々なテーマで合同勉強会を開催してくれる企業さまを募集中です。ご興味ある企業さまがいらっしゃいましたら こちら までご連絡いただけると嬉しいです。

はじめに こんにちは、2022年新卒の河原です。 突然ですが、皆さんは今までどのような開発体験をされてきましたか？ 学生時代からゴリゴリに開発していた人もいれば、全く違う職種から独学やプログラミングスクールで学んでエンジニアリングに携わっている人など、人によってキャリアは多種多様だと思います。 私の場合はこれまで、学生・インターン・正社員としてシステムの開発に携わってきました。まだ社会人になってから1年と少ししか経っておらず、学生時代の経験もある程度は新鮮に覚えています。 この記事では、そんな私が学生・インターン・正社員でのエンジニアリングを通して痛感した 『開発体験の差』 と、今後に活かしたい 『3つの学び』 をご紹介したいと思います。 日々の業務に追われ、過去を振り返ることを忘れがちになっている方々が「私もこんな経験があったな」「僕はどう成長してきただろうか」と思い出す・考えてみるきっかけになるような記事になれば嬉しく思います。 自己紹介 まずはじめに、自分の経歴を軽く紹介させていただきます。 学生時代、高専でコンピューターサイエンスを広く浅く学び、情報系の大学・大学院へ進学して情報系に特化したことを学んできました。 研究は、自然言語と音声といった複数の感覚次元を機械学習させるマルチモーダル感情認識を題目として扱っていました。当時はまだ最近話題のGPTの「GPT-2」が論文として発表され、様々なベンチマークを更新し、GeneralなLLMの台頭にワクワクしていた思い出があります。 その後レバレジーズに内定し、「早くから社会で通用する本格的な開発経験を積みたい」と思い、2021年の8月からエンジニアとして早期のインターンを始めます。 インターンでは、未経験のエンジニアが中心で構成された教育目的のチームにて、小さめの社内システムを要件定義・技術選定から設計・開発まで一通り経験させてもらえました。 そして、去年4月に正社員として入社し、現在は正社員として、若年層領域の事業を展開する『ハタラクティブ』や『キャリアチケット』というサービスで、営業職が使用するSFA（Sales Force Automation）開発に携わっています。 今のチームに移動してきて1年ほど経った状態です。 学生と社会人の違い 開発の『目的』 私が学生と社会人（インターン・正社員含む）で感じた開発体験の最も大きな違いは、開発の 『目的』 です。 どのように目的が違うのでしょうか？私の経験と合わせて、具体的に説明していきたいと思います。 私の学生時代は趣味や学業の一環で、簡単な 2Dゲーム 組み込みシステム Webシステム AIモデル構築 など様々な開発をしていました。 これらは、学業で必要になったり、興味関心が沸けば「開発してみる！」といった具合で、特に大きな目標はなく 『開発を楽しむ目的』 でいろんな開発をしてみていました。 しかし、どれも『システムが完成して目的を達成すれば、開発も終わり』のような拡張性がなく、モチベーション頼りの単発な開発でした。 結果として、 作り上げたシステムとしての品質は高いとは言えず 、 技術的な深掘りもあまりできておらず 、また 自身の能力的が成長した実感もあまりありませんでした 。 それに対して、社会人での開発目的は 『利益を生み出す目的』 へと変わりました。 社会人は全員「ビジネス的な視点」を持つ必要があります。 それはエンジニアも例外ではなく、開発したシステムを含めて、最終的には 市場において競合優位性を確保する「サービス」 を作り上げて『利益を生み出す目的』に合致したシステムを開発していく必要があります。 観点の多さと責任範囲 目的に付随して『責任』や『観点』にも違いが生まれてきました。 学生時代の開発観点は、システムの機能性ばかりに注目し、 「とりあえず動けばOK！」 のような考えが先行していた記憶です。 対して、社会人では利益を生み出すために 正確で安全なシステム が、 迅速にリリースされる 必要があります。 そのため、開発観点はさらに多角的になり、 コードの可読性 保守性 スケーラビリティ アジリティ セキュリティ などの品質を満たした開発が必要になりました。 責任の変化なども加えて、感じた特徴の違いをまとめると以下になります。 学生 社会人 目的 開発を楽しむため 利益を生み出すため 開発物 いろいろ Webシステム 開発観点 ・機能性 ・正確性 （上記も品質は低い） ・機能性 ・正確性 ・保守性 ・スケーラビリティ ・アジリティ ・セキュリティ などなど… 目的・要件 シンプル 複雑で多種多様 機能 少なめ 多め 技術 モダンなものが中心 新旧混在 開発 FE・BE・インフラ全て BE中心 <td style="padding: 5px; font-weight: bold; border-right: double;""> 開発体制 ウォーターフォール スクラム システムの『役割』の理解の深さ 特徴や規模、言語・技術が全く違う2つですが、ここで感じたことは「システムの役割を理解する必要がある」ということです。 インターン時代は、 『新規社内向けシステム』 ということもあり、純粋にエンジニアとして開発に必要な知識や経験を培い『Webシステムの開発』に注力することができました。 これは当時いたチームの目的が 「手を動かしながら学習して、PDCAを回し、システム開発に必要な基礎を身につける」 ことにあったためです。 作成していたシステムを振り返ると、未経験中心のチームであったこともあり、決して品質が高いとは言えませんでしたが、チームの目的を達成するための役割は果たしていたと思っています。 私個人としても、当時未経験でありながら、包括的な開発体験をさせていただけたことはとても良いファーストキャリアになったと思っています。この時の 業務で知識不足を痛感する 知識不足と感じたことを学習する 学習した内容を業務に活かす というエンジニアにとっては当たり前のサイクルが、開発体験上大きな成長実感をくれました。 対して、現在の 『SFA開発』 は、サービスの根幹を支える基幹システムです。メリットである機能の多さやデータの一元化の対価として、 デメリット は、 8年前から存在する古いコードと新規のコードが混在すること 複雑な要件・関係者が多いといった特徴による開発の鈍化 などが挙げられます。 これは、例えば、新規機能開発にてテーブル構造を変えれば、そのテーブルを分析に利用しているマーケティング職の業務に影響が生じたりします。 そんなSFAの役割は何に当たるでしょうか？ これは明確で、SFAの利点が上げられると思います。開発した機能や蓄積したデータ活用によってビジネス的な利益に結びついているためです。 そのため、 『機能性・拡張性・保守性・セキュリティが比重重めに重要視される』 反面、相対的に 『UI/UXといった使用性は軽視される傾向になる』 ことはあります。 システムの役割が明確で、開発に軸があることで、数々の開発タスクの優先度や重要度を振り分け、サービスや組織全体にとってより良い開発を進めることができています。 システム品質特性は様々な観点がありますが、優先・重要視される観点は『システムの役割』によって多面的に変わると思います。皆さんが携わるシステムはどんな特性を重要視されていますでしょうか？ 3つの学び これまでで学生時代から、インターン、正社員での開発体験の違いを説明してきました。 開発のポートフォリオも目的も技術もそれぞれ違いますが、これらを通して痛感した、以下の3つの学びがあります。 新しい技術が最適とは限らない 負債を生む可能性を常に考慮する 基礎が大事 新しい技術が最適とは限らない インターン時代は、frourioと呼ばれるフルスタックフレームワークで用意したTypeScript・Next.js・Material-UIなどを用いた開発を行っていました。 対してSFAは、BEはphpのフレームワークであるCakePHP・Laravel、FEはscss、jQueryとReact・Graph-ql（JavaScriptとTypeScript）が混在しています。 インターン時代は新しめの技術が中心でしたが、当時は自分やチームのメンバー含めて、Webシステム開発の知識や経験が浅かったこともあり、以下のようなことが起きていました。 インターネット上に参考となる事例が少ないことによる開発のつまづき 発展途上の技術は、カバーされてない箇所もあること 扱う人の知識不足で各技術の利点を活かしきれていないこと あるあるだと感じる人も多いのではないかと思いますが、特に3つ目はエンジニアにとって無くしていきたいことだと思っています。 対して、SFA開発ではどうでしょうか。 現在主にフレームワーク移行中であるLaravelは、非常に高機能で、開発者としての使い勝手の良さがある FEで利用しているjQueryは現代の主流とは言えないですが、複雑な業務的な要件を満たす機能は果たしてくれています これらを通して僕が感じたことは、 新しい技術のみが万能ではない ということです。 「古い技術の方が良い！」というわけではありませんが、どんな技術も 扱う開発者のスキル システム（≒サービス）の性質 によってその価値は変わると思っています。 例えば、エンジニアとして、現在のSFAのFEをjQueryからReactなどのモダンなフレームワークへリプレイスさせたいなという気持ちはあります。 しかし、現在のSFAの特徴として、 システムが多機能なことから、リプレイスに要する時間は多大なこと その他の観点と比べると、UI/UXといった使用性が軽視される傾向にあること があります。 そんなシステムにおいて、 FEコードのリプレイスを行うビジネス的な価値は果たしてどのくらいあるのでしょうか？ これはとても難しい判断だと思います。 この疑問は、営業職やマーケティング職が数値を根拠に仮説を立てて業務を行う職種の働き方を間近で感じられるレバレジーズで培われた視点かもしれません。 エンジニアはしばしば手段と目的を逆にしてしまうこと（「この技術を使いたいから、これをしよう！」など）がありますが、その行動の価値を証明する根拠を正しく策定しなければ、この後に書く「負債」につながると思います。 負債を生む可能性を常に考慮する 1年前の自分が書いたコードを見ると恥ずかしい気持ちになる方は、経験が浅い方であれば誰でもあると思います。 私自身もそれは痛感しており、それは自身が成長しているという実績でもあると言えますが、 意図しない将来的な技術的負債を残しているという事実 にも繋がります。 現在のSFAは古めのシステムであるため、 設計思想が今と合わなくなっていた 機能拡張を繰り返した ことが要因で、コード品質が低下していました。また、業務要件が複雑で綺麗な設計が難しい場合も多いです。 多くのテスト駆動開発や開発アーキテクチャの文献でもそう述べられている通り、将来的な技術的負債を軽減させることは重要です。これがシステムの保守性や拡張性に大きく関わってくることは、フレームワーク移行・新規機能拡張の業務を通して痛感しています。 自分のコードの品質が高いかどうかの判断は難しいですが、品質向上のための学習や仕組みによる解消、適切な指摘が行えるチームビルディング・コミュニケーションを怠らないことが必要だと感じています。 また負債とは、 特に技術だけではありません 。それは、例えばドキュメンテーションや開発ルール、会議など様々です。 作成したはいいものの、保守されていなくて結局使われていない資料 なぜこうなっているのかわからないけど、みんなで守っている運用・開発ルール どの立場として参加はしているかわからず、意見のまとまらない会議 開発だけでなく、仕事をする上では様々な将来的な負債が発生している可能性はあり、それは自分だけでなく、チームや組織にも当てはまります。 本当に解決したい課題は何なのか？ その機能はスケールできるのか？アジリティは高いのか？ 品質のスコープはどこまでなのか？また、それはなぜなのか？ といった目的と手段の整合性や効果を明確にすることが重要であり、それを正しく行うためには、賛同と同程度に建設的な批判ができるチームや組織が理想であると思っています。 これは開発職以外と関わることが多い自社開発企業におけるメリットであるとも感じます。他職種においても、仮説立てやロジカルシンキングを用いて施策を提案しています。 その姿勢から学べることもたくさんあります。 基礎が大事 全ての体験で共通して感じたことですが、結局 基礎が最も大事 だなと痛感します。 現代は便利なフレームワークやインフラサービスが豊富な時代ではありますが、最終的にはHTMLやCSS、JavaScript、SQLなど基礎的なWebシステムの技術に帰結すると思います。 インターンやSFA開発、どの開発段階においても、基礎となる部分の知識不足の壁にぶつかり、バグや障害発生の問題の根本を掴めず、適切な対応ができない・対応が遅れることがありました。ですが、逆に基礎を理解していると、新しいフレームワークや技術に対する理解のハードルも下がりました。 つまりは、新しい技術の習得や興味を持つこともとても大事ですが、それ以上に基礎的なスキルが必要不可欠だと感じます。学生時代の勉強や開発が、この基礎の学習において役立っていることは言うまでもありません。 私の場合、最近はBE周りに携わることが多いため、データベースそのものの仕組みや、SQL・データ指向のアプリケーションのようなBEに関わることを 達人に学ぶDB設計 徹底指南書 初級者で終わりたくないあなたへ 達人に学ぶSQL徹底指南書 第2版 初級者で終わりたくないあなたへ データ指向アプリケーションデザイン - 信頼性、拡張性、保守性の高い分散システム設計の原理 等の書籍やWeb上の事例を用いて、基礎から学びなおして応用まで学習の範囲を広げてみています。データ指向アプリケーションデザインはまだ読書中ではありますが、この3冊は非常に有益であったので、BEに関わる方におすすめしたい書籍です。 最後に 学生・インターン・正社員での開発体験の違いと今後に活かしたい3つの学びをご紹介させていただきました。 今回の記事で、自分の体験を忘れないための備忘録と、今後も意識したい学びを書き留めることにより、将来の自分が過去を振り返るきっかけになったと思います。 今後も学んだことをチームや組織に活かせる社会人になるために、BEを中心としてまだまだコンピュータサイエンスを深く学んでいきたいと思います。 読者の皆様も、日々の業務に追われ、新しいことを立て続けに学んでいる日常であると思います。 そんな日々で、過去を振り返る機会が減ってしまってはいないでしょうか？ 自分の過去や現在の開発経験のふりかえり、得られた学びをまとめてみることで新たに見えてくるものや自分の目指す方向性を再確認するきっかけになると思っています。 レバレジーズでは、様々な体験ができるシステム開発を行っています。ぜひ、みなさんも一緒にサービスを作っていきませんか？レバレジーズに少しでも興味を持っていただけた方は、是非下記リンクを覗いてみてください！ （詳しくは こちら ）

レバレジーズ株式会社 テクノロジー戦略室室長の竹下です。 2023/3/24に、エイチームさんと、フロントエンドをテーマに合同勉強会を開催しました。 以前もプレイドさん と合同勉強会を開催したことがあるのですが、前回は2社クローズだったところを今回は connpassで一般公開 して開催しました！ また、弊社の開発拠点が東京の渋谷で、エイチームさんの開発拠点が名古屋なので、リモートでの開催でした。 この記事では、弊社のエンジニアの発表内容を簡単にご紹介したいと思います。 発表内容 弊社からは、4人が発表しました。 speakerdeck.com AWS Amplify Studioと Figmaを組み合わせて、HTML,CSS + Reactを自動生成し、ランディングページの開発効率を爆上げしたという発表です。 speakerdeck.com 代数的データ型(Algebraic data type, ADT)とGraphQLの組み合わせて、TypeScriptのUnion TypeやGraphQLのコード生成を使用したエラーハンドリングの定義方法のご紹介です。 speakerdeck.com Nuxt2からNuxt-bridgeを経てNuxt3への移行を完了した奮闘記です。 speakerdeck.com React + Vercelを組み合わせて、Markdownの記述を補助するツールを短期間で作ってみた！という発表です。 We are hiring レバレジーズ株式会社ではフロントエンドエンジニアも、それ以外のエンジニアも幅広く募集中です。 もし今回の勉強会の発表を見てご興味を持っていただけたなら、 こちらのページ からご応募ください。 勉強会の開催も随時受け付け中です 今回はフロントエンドをテーマに合同勉強会を開催しましたが、レバレジーズはオールインハウスで開発しておりフロントエンド、バックエンド、インフラ、機械学習と幅広い領域をカバーしているので、フロントエンドに限らず様々なテーマで合同勉強会を開催してくれる企業さまを募集中です。ご興味ある企業さまがいらっしゃいましたら こちら までご連絡いただけると嬉しいです。

はじめに レバレジーズ株式会社でフロントエンドエンジニアとして勤めている森山です。 今回は振る舞い駆動開発（Behavior Driven Development、通称BDD）をご紹介します。 ここでの振る舞い駆動開発とはDan North氏が提唱しているBDDの要点を掴み、自チーム流に昇華させたものです。 振る舞い駆動開発を導入して最も良かったことは、アジャイルにおいても開発スピードを保ちつつ一定の品質を担保できたことです。 一定の品質というのは機能適合性が担保されているということです。 また振る舞い駆動開発をすすめていく中で副次的に開発者のプロダクトへの理解度や視座が高まり、より良いプロダクトを作ろうという意思が一人ひとりに芽生えたと感じています。 概要 振る舞い駆動開発の目的は以下です。 開発スピードを維持しながら一定の品質担保 振る舞い駆動開発の手順は以下になります。 ユビキタス言語の定義 ユーザーストーリーの定義 ユースケースの定義 テストケースの定義 プロダクト実装 テスト実装 振る舞い駆動開発ってなに？ そもそも私が振る舞い駆動開発をどう定義しているのか説明します。 観点としては以下になります。 目的はなに？ 振る舞い駆動開発ってなに？ テスト駆動開発とは何か違うの？ 振る舞いってなに？ 目的はなに？ 開発スピードを維持しながら一定の品質担保です。 振る舞い駆動開発ってなに？ 端的に言うと「システムの振る舞いに焦点を当てたテスト駆動開発」です。 一般的に振る舞い駆動開発はテスト駆動開発の1つの流派として捉えられています。 テスト駆動開発とは何が違うの？ テストの対象が異なります。 イメージとしては、テスト駆動開発よりも振る舞い駆動開発の方がテスト粒度が荒く、網羅性が低いです。 振る舞い駆動開発はその名の通りシステムの「振る舞い」のみをテストの対象としています。 一方、テスト対象以外はテスト駆動開発と振る舞い駆動開発もテストファーストな開発手法としては同じです。 テストファーストとある通りテストコードを先に書いてから、 そのテストコードをパスするような実装とリファクタリングを繰り返します。 テストファーストは以下のメリットがあります。 致命的な欠陥を開発終盤に持ち越さない。 開発者がシステム要件を深く理解できる。 デグレードを恐れずリファクタリングができる。 ただテストファーストな開発はメリットだけではないと思っています。 以下のような難点も存在します。 プロダクトコードのみを書く場合よりも開発が遅い。 テストすべき内容や粒度をどのように判断するのか難しい。 仕様が変更された時の影響が大きい。 上記はウォーターフォール開発であればさほど目立ちません。 そもそも短期間で成果を出すことは求められていないですし、 テストで担保したい基準も最初に決定するはずです。 また手戻りがあるとしても要因は考慮漏れくらいで、外的要因による仕様の変更も少ないはずです。 つまりテスト駆動開発の恩恵を存分に享受できます。 しかし上記の難点は、アジャイルな開発だと顕著になります。 特に課題に上がるのは以下です。 スプリント期間内でアウトプットを出す難易度が高い。 機能毎にテストの粒度を判断するコストが高い。 仕様変更による手戻りの影響範囲が大きい。 プロダクトコードと合わせてテストコードも書く必要があるので、短期的に見ると開発スピードは落ちます。 そのためスプリント期間内に動くものをアウトプットする難易度が上がります。 またテストはどの粒度で定義するのかという迷いも生じます。 最初に決めることができればよいですが、それも難しいはずです。 なぜなら、システムの最終ゴールが分からないからです。 そもそも開発当初にシステムの最終ゴールが見えないために、アジャイルな組織体制で市場の変動等に適応していく手段を選択していたりするのかなと思います。 テスト粒度の線引が完璧にできないので、機能毎に都度どこまで網羅的にテストをするのか判断していくことになります。 例えば、「データを描画するだけならこの程度で良いか。」、「決済機能は重大なインシデントに繋がるからカバレッジをできる限り高めよう」などです。 また過去に実装した時は適切な厳密さでテストができていたが、機能拡張で再度判断が必要になることもあります。 スプリントの中で都度テストの厳密さを適切に判断していくというのはコストが高いです。 さらに手戻りが発生した時の影響範囲も大きいです。 改修範囲がプロダクトコード + テストコードになるので当然ではありますが、手戻りの改修がしんどくなるのはアジャイルの良さが失われてしまいます。 とはいえテストファーストで一定の品質を保ちつつ開発者のシステム要件の理解度を上げていきたいので、アジャイルで開発しつつもテスト駆動開発の旨味を享受するためにテスト対象として「振る舞い」に着目します。 振る舞いってなに？ 振る舞いとは、ユーザに価値を提供できるシステムの動きです。 極端な例ですがECサイトを考えます。 ユーザーが実現したいことはオンラインで欲しい物を購入できることです。 その過程として、「商品をカートに入れる」はユーザが実現したいことを叶えるためのシステムの動きです。 しかし「ボタンを連打できない制御」が施されていたとしてもそれはユーザーが実現したいことに密接には紐付きません。 「商品をカートに入れる」ことができれば、ボタンの連打制御は無くてもいいです。 あれば嬉しいなくらいです。 端的に言えば機能要件よりも非機能要件を重視したいということになります。 またこれは私の持論ですが、困りごとが解決できる手段があれば多少使い勝手が悪くても嬉しいです。 確かに入念なテストをパスしたソフトウェアは安心感があります。 しかし多少レイアウトが崩れていたり、フォームにバリデーションがない状態になっていたとしても課題を解決できる手段があることの方が圧倒的に嬉しいです。 ソフトウェアが提供する価値の種類にもよるので一概にも言えませんが、アジャイルな開発で求められるソフトウェアは上記がほぼ当てはまるのかなと思っています。 つまりテストをする際にもまずは動くことを担保するテストを優先させたいということです。 ただ単純にテストという言葉に引っ張られると大抵「xxxであるべき」という文言を使って理想状態を定義します。 そしてそれを満たしているかテストコードを書いていきます。 「xxxであるべき」となると各テスト項目はビジネスインパクトに関わらず、どれも等しく満たしている必要があるように見えます。 そしてテストを書いていく中でも「xxができていない。」、「yyは担保しなくていいのか？」と不安にも駆られます。 開発者としても「システムとしてあるべき状態を担保するテストを書け」と言われると際限がないように思えます。 しかし「ユーザが実現したいこと（振る舞い）を担保するテストを書け」と言われると自然と機能要件に着目しそれ以上を闇雲に目指すことは無いはずです。 もう一度、この章の冒頭の言葉を引用すると「振る舞いとは、ユーザに価値を提供できるシステムの動き」です。 この振る舞いにフォーカスすることで、アジャイルで開発していく中でも特に必要な機能をテスト対象として選定できます。 また「振る舞い」はコード上ではシステマチックに定義されます。 振る舞いひとつの構成は以下です。 Given: システムがこの状態の時に When: この動作をすると Then: システムはこう振る舞う 詳しくは後述しますが、振る舞いは1つのユーザーの1つのアクションに対してシステムがどう動くのかを定義します。 そしてこの振る舞いが複数集まることでユーザーがどの順番で、何を成し遂げたいのかも見えてきます。 振る舞い駆動開発の手順 振る舞い駆動開発の手順は以下になります。 ユビキタス言語の定義 ユーザーストーリーの定義 ユースケースの定義 テストケースの定義 プロダクト実装 テスト実装 上記の手順が生まれた背景・思考プロセスはざっくり以下です。 一定の品質を保ちながら開発をすすめるためにテストファーストな開発をしたいな。 テストファーストな開発をするためには、何をテストすべきか決まっている必要があるな。 何をテストすべきか決めるにはシステムがユーザーに提供したい価値や手段を明確にする必要があるな。 ユーザーに提供したい価値を明確にするためにはユーザーストーリー、ユースケースの定義が必要だな。 ユーザストーリーやユースケースを開発者やPDM等、誰が読んでも一律同じ解釈ができるためにはユビキタス言語の定義が必要だ。 上記の背景・思考プロセスを逆転させて振る舞い駆動開発の手順となっています。 次章から各手順でどんなことをしているのか説明します。 ユビキタス言語の定義 ユビキタス言語とは 開発者やPDMを含むチーム全体の共通言語のことです。 例えば、会社を表現する時にそのまま「会社」という表現を使うのか、「企業」という表現を使うのかをチームの中で決めておくということです。 またプロジェクト独自の概念や造語も含まれます。 ユビキタス言語を定義する目的 目的は以下の3つです。 コードやドキュメントを誰が読んでも一律同じ解釈ができる状態にすること システム上での表記揺れを無くすこと 新規参入者のオンボーディング ユビキタス言語の定義方法 定義方法は簡単で、テーブル形式で記載しています。 以下がその一例です。 ドキュメント 類義語 プログラム単数 プログラム複数 意味 企業 会社、組織 corporation corporations 利益を得ることを目的にして事業を行う組織体のこと。 引き直し 再登録 paymentReload - サブスクリプションサービスを解約していた人が再契約した時に決済予定が記録されること。 各カラムについて説明します。 ドキュメント 開発者やPdMが会話上やドキュメント上で活用していく表現です。 類義語 端的に言うとNGワードのような扱いです。 定義されたユビキタス言語が「表記ゆれを起こすとしたらこんな表現だろう」という言葉が類義語というカラムに記録されます。 なので類義語を見つけたら開発者やPdM間で指摘し合います。 プログラム（単数/複数） コード上で変数名やテーブルのカラム名として活用されます。 プログラム上でもユビキタス言語が無いと企業idをフロントエンドではcorporationIdと定義しているのに、 バックエンドではcompanyIdという命名で定義しているということが起きてしまいかねません。 念の為複数形も定義しておくと良いです。 基本的には英語の複数形のルールに従えばOKですが、プロジェクト独自の概念や造語があるとブレそうになる場面があります。 概念として複数形が存在しない時はハイフンを入れています。 意味 その単語の意味です。 ユビキタス言語の恩恵 ユビキタス言語の恩恵としては、コードやドキュメント上で顕著に発揮されています。 特にコード上で、企業idをフロントエンドではcorporationIdと定義しているのに、バックエンドではcompanyIdという命名で定義しているというような場面を稀に見かけます。 これの悪いところは、変数名を変更するという改修が顧客に対して価値を生み出さないところです。 ビジネスインパクトが弱いからという理由で修正が後回しにされていくことが多いです。 しかし個人的にこれは大きな技術的負債です。 見るたびに脳内でcorporationId = companyIdという変換でメモリが食われて本当に考えたいことに100%のリソースを避けないことが永遠に続きます。 たった1つであれば問題ないと考えているとどんどん増えるので見かけたら即直してユビキタス言語を更新する方が良いと思っています。 ユビキタス言語は新規開発者のオンボーディングでも役に立ちます。 ユビキタス言語の一覧表を眺めるだけでそのシステムが何をしたいシステムなのか雰囲気をさっと掴むことができます。 ユーザーストーリーの定義 ユーザーストーリーとは ユーザーストーリーとは、ユーザーができるようになりたいことをまとめたものです。 システムが何を提供すべきかではなく、ユーザーが何をしたいかに焦点を当てます。 ユーザーストーリーの目的 ユーザーストーリーの目的は開発するシステムに引っ張られずにユーザーに提供したい価値を見える化することです。 ユーザーストーリーがあることで開発者は「振る舞い」を実装・テストする際にそもそもその振る舞いは何を実現したいのか？を見極め自分自身でシステムとして適切な機能なのか有効なテストなのか判断できます。 ユーザーストーリーの構成 ユーザーストーリーは以下の要素から構成されています。 アクター エピック ユーザーストーリー それぞれ何を意味するのか説明します。 アクター ユーザーストーリーに登場する人物の列挙と各人の説明です。 エピック ユーザーストーリーの骨子です。 エピックはユーザーストーリーよりも1段抽象度が高い概念です。 複数のユーザーストーリーのまとまりがエピックです。 ユーザーストーリー ユーザーのニーズと背景が2つセットで表現されます。 ユーザーストーリーは箇条書きで記載しています。 ユーザーストーリーの具体例 例としてフリマサイトのユーザーストーリーを書いてみます。 アクター 出品者 商品の出品者 購入者 商品の購入者 エピック 出品者は、商品を出品する。 購入者は、商品を検索する。 購入者は、商品の詳細を確認する。 購入者は、商品をお気に入り登録する。 購入者は、商品を購入する。 ユーザーストーリー 出品者は、商品を出品する。 出品者は、出品する商品の画像をアップロードする。 なぜなら、商品がどんな商品なのか購入者に画像で知らせたいから。 出品者は、出品する商品の価格を設定する。 なぜなら、商品をその価格で販売したいから。 出品者は、出品する商品の詳細情報を設定する。 なぜなら、商品の画像で伝わらない商品の情報を購入者に伝えたいから。 出品者は、商品の出品を完了する。 なぜなら、設定した内容で商品を出品したいから。 出品者は、自身の出品リストを確認する。 なぜなら、先ほど出品した商品が出品できているか確認したいから。 なぜなら、出品した商品の設定内容に誤りが無いか再確認したいから。 購入者は、商品を検索する。 購入者は、 …etc 上記のように箇条書きで羅列する形式でユーザーストーリーを書いています。 ユーザーストーリーの定義方法 定義方法の要点は3点あります。 フォーマット 行動はシステムを介さないユーザー視点 いきなりユーザーストーリーを書かない 1.フォーマット フォーマットとしては、以下の体裁を守っています。 [アクター]は、xxxする。 なぜなら、yyyしたいから。 ユーザーのニーズと背景が必ず一対一もしくは一対多で紐付く形式にするためです。 2.行動はシステムを介さないユーザー視点 商品の出品完了に関しては「商品の出品ボタンをクリックする。」ではなくわざと「商品の出品を完了する。」のようにやや抽象度の高い表現になっています。 些細な違いですが、「出品ボタンをクリックする。」になっているとこの時点で出品ボタンがある前提のUIが設計されます。 「完了する。」にしてUI決定の余地を残しておくことで、もしかしたら上にスワイプすることでリッチなアニメーションと共に出品が完了するようなUIになるかも知れません。 また場合によってはシステムが介入しないユーザーストーリーも存在しえます。 例えばシステム上のデータをプリンターでプリントアウトする。等です。 労務系の業務システムであれば帳票を印刷して行政に提出するようなアナログな動きが業務の中に含まれることもあり得ます。 3.いきなりユーザーストーリーを書かない ユーザーストーリーをいきなり箇条書きで列挙するとユーザーにはそのニーズ以外を満たす余地を与えないタスク指向のシステムになってしまいやすいです。 事前にユーザーストーリーマッピングやオブジェクト思考UIを絡めて定義していくのが良いです。 ユースケースの定義 ユースケースとは ユースケースとは、端的に言うとユーザーストーリーを具体化したものです。 ユーザーストーリーを実現するためのユーザーとシステムのインタラクティブな動きを表現するものです。 ユーザーストーリーとの違いは、システムが介入するかどうかです。 ユースケースの目的 ユースケースの目的は、ユーザストーリーを実現するための画面上での遷移や操作を表現することです。 単にシステムがどう振る舞うかのドキュメントではなく、「ユーザーストーリーを実現するための」というところが重要です。 システムの振る舞い1つ1つがユーザーストーリーを実現するために適切な動きなのか、適切な導線設計なのか、開発者からも深ぼって確認することができます。 ユースケースの構成 ユースケースは以下の要素から構成されています。 アクター エピック ユースケース それぞれ何を意味するのか説明します。 アクター ユースケースに登場する人物の列挙と各人の説明です。 エピック ユースケースの骨子です。 エピックはユースケースよりも1段、抽象度が高い概念です。 複数のユースケースのまとまりがエピックです。 ユースケース ユーザーのアクションとシステム挙動が2つセットで表現されます。 ユースケースは箇条書きで記載しています。 ユースケースの具体例 例としてフリマサイトのユースケースを書いてみます。 アクター 出品者 商品の出品者 購入者 商品の購入者 システム エピック 出品者は、商品を出品する。 購入者は、商品を検索する。 購入者は、商品の詳細を確認する。 購入者は、商品をお気に入り登録する。 購入者は、商品を購入する。 ユースケース 出品者は、商品を出品する。 出品者は、フリマアプリにアクセスする。 システムは、ログイン画面を表示する。 出品者は、ログイン情報を入力する。 システムは、トップページを表示する。 出品者は、「出品ボタン」をクリックする。 システムは、出品画面に遷移する。 出品者は、「商品の画像アップロードボタン」をクリックする。 システムは、OSのファイルシステムを起動する。 出品者は、出品したい画像を選択する。 システムは、アップロードされた画像を表示する。 出品者は、商品の価格に3000と入力する。 システムは、商品の価格を3000と表示する。 システムは、商品の手数料を300と表示する。 …etc 購入者は、商品を検索する。 購入者は、 …etc 上記のように箇条書きで羅列する形式でユースケースを書いています。 ユースケースの定義方法 定義方法の要点は3点あります。 フォーマット ユーザーストーリーと紐ついていること ケースの網羅は不要 1.フォーマット フォーマットとしては、以下の体裁を守っています。 [アクター]は、xxxをする。 システムは、yyyする。 2.ユーザーストーリーと紐ついていること 基本的にユースケースは何かしらのユーザーストーリーと一対一で紐ついています。 また、エピックも同様です。 ユーザーストーリーで定義されたエピックは、ユースケース上にも存在します。 3.ケースの網羅は不要 基本的にユーザーストーリーを実現する手段は細かく見ると複数存在します。 例えば、「出品者は、画像をアップロードする」というユーザーストーリーでも以下の3種類のアクションが考えられます。 デバイスのカメラを起動して撮影してアップロード OSのファイルシステムを起動してアップロード ドラッグ&amp;ドロップでアップロード ユースケースはユーザーストーリーを実現するための詳細な挙動なので3パターンのユースケースが想定できますが、 基本的には最も発生頻度が高そうなケースで1パターン書かれていれば良いです。 ユースケースの主たる目的としてユーザーストーリーという1つのフローを実現するための大まかな動きを確認することだからです。 テストの定義 テストケースとは ここでのテストケースとは、振る舞いをシステマチックにテストケース化したものです。 振る舞いはユースケースの一つ一つから以下のようなフォーマットで作成されます。 Given: システムがこの状態の時に When: この動作をすると Then: システムはこう振る舞う 上記の様にGherkin記法と呼ばれる書き方で記載します。 Given = 前提条件 When = ユーザーのシステムに対する動作 Then = ユーザーの動作に対するシステムの挙動 Given、When、ThenのそれぞれをStepと呼びます。 またこれらのStepの塊をScenarioと呼びます。 そして1つのユースケースが1つのScenarioとしてテストケース化されます。 テストケースの具体例 テストケースの具体例としては以下になります。 Feature: 商品の出品 Background: 前提条件 Given ログインしていること Scenario: 出品の開始 Given トップページにアクセスしていること When 「出品」ボタンをクリック Then 商品の出品画面に遷移していること Scenario: 商品価格の入力 Given 商品の出品画面にアクセスしていること When 商品の価格フォームに3000と入力 Then 商品の価格が3000と表示されていること * 商品の手数料が300と表示されていること Scenario: 商品詳細の入力... Gherkinではまず上記の様にFeatureとしてユースケースのエピックに該当する大項目を記載します。 その後、各Scenarioに共通する処理があればBackgroundに表現します。 （BackgroundはJestで言うところのBeforeEachのような役割です。） そこから各Scenarioを列挙していきます。 振る舞いのテストケースでは1アクションnレスポンスの形式になっています。 なので各ScenarioにおけるWhenは1つになるのが一般的です。 1つのアクションに対して複数の動作が発生することはありえるのでThenは複数になることもあります。 テストの実装 Gherkin記法で定義したテストケースに紐付くテストを実装していきます。 テスティングライブラリとしてCypressを活用しているのでcypress-cucumber-preprocessor（以下、CCP）というライブラリを用いています。 テストの実装自体はCypressを用いた実装になりますが、CCPの関数を間に挟むことでテストケースと紐付くテストが存在していることを機械的に担保できるようになります。 例として、先ほどのユースケースに紐付くテストを書くと以下になります。 import { Given ,When, Then } from '@badeball/cypress-cucumber-preprocessor' ; Given( &quot;ログインしていること&quot; ,()=&gt; { cy.login(); } ); // 出品の開始 Given( &quot;トップページにアクセスしていること&quot; ,()=&gt; { cy.visit( &quot;http://toppage&quot; ) } ); When( &quot;「出品」ボタンをクリック&quot; ,()=&gt; { cy.get( '[data-cy=&quot;ExhabitButton&quot;]' ).click(); } ); Then( &quot;商品の出品画面に遷移していること&quot; ,()=&gt; { cy.url().should( &quot;equal&quot; , &quot;http://exhabit&quot; ); } ); CCPは、各Step（Given、When、Then）の関数を提供してくれています。 テストファイルの中ではGherkin記法で書いた各Stepの文面を第一引数に取ってCCPのStep関数を呼び出します。 各Step関数の中では、Cypressのテスト関数がそのまま使えるので対応するユーザーのアクションを定義していきます。 イメージとしてはCypressのE2EテストをCCPのStepでラップしてカテゴライズしているような感覚です。 テストファイル内での各Step関数の第一引数はGherkinファイルで定義した各Stepの内容と完全一致している必要があります。 CCPのアルゴリズムとしては、まずテストケースの中身を上から順番に読み込みます。 その中でStep（Given、When、Then）があればそのStepに紐付く文面をテストファイルの中から探しに行きます。 テストファイルの中でStep関数の第一引数が完全一致したStepの中身を実行します。 完全一致する文面が存在しなければエラーを返します。 以下は「商品の出品画面に遷移していること」というテストが存在しなかった時のerrorです。 そもそもテストが存在しないときには、紐付くテストを定義するようにサジェストされます。 Gherkin記法で記載したテストケースとそれに対応するテストが実装されていない場合は上記の様にテストがfailするので担保したい振る舞いがテストできていることを機械的に検知できます。 サジェストにあるように”pending”という文字列をStep関数で返却するとテストをスキップすることができます。 Then(( &quot;商品の出品画面に遷移していること&quot; )=&gt; { return &quot;pending&quot; ; } ); テスト結果ではPendingの件数が表示されます。 なのでプロダクトコード実装前に動作を担保したい振る舞いはテストの中身をPendingで全て仮定義します。 プロダクトコードの実装が進むと同時にテストの中身を実装しPendingのテストを潰していきます。 実装結果にPendingの件数が表示されるので担保したい振る舞いのテストが未実装のまま放置されてしまうことも無いはずです。 振る舞い駆動開発の恩恵 最も実感しやすかった恩恵は実装スピードを落とさずに一定の品質を担保できているところです。 元々は、開発者とPdMの目線があっていないことが原因で手戻りが発生していました。 しかし以下がシステマチックに管理されることでその手戻りは激減しました。 システムはどう振る舞うべきか？ その振る舞いはユーザーにどんな価値を提供するのか？ またテストの実装漏れも少なくなり、実装段階から品質を担保することができるようになりました。 そして開発者が機能の背景を理解していることで「ユーザーがこのニーズを満たしたいのであればxxの機能があったほうが良いのでは？」等の新たな提案も生まれやすくなりました。 振る舞い駆動開発の副次的な恩恵として開発者がやらされ仕事で実装するのではなく、視座を高くもって開発に取り組むことが実現できたことも良い点でした。 終わりに いかがでしたでしょうか。 私の所属する事業部は発足してまだまだ成長段階でプロダクトの状況も0-1フェーズにあります。なのでこういったどういう構成で開発を進めるべきかなどを検討・決定していける機会が多いです。この記事をご覧になり、この事業部を一緒に盛り上げてみたいなと思う方が1人でも増えれば嬉しく思います！（詳しくは こちら ）

はじめに こんにちは、レバレジーズ株式会社の髙橋です。2020年に新卒エンジニアとして入社して以降、エンジニア向けQ＆Aサイト「teratail」のメンバーとして働いています。最初の2年弱を企画メンバーとして過ごした後に、開発メンバーとしてのキャリアを今日まで進めてきました。 本記事では、新卒から2年弱を開発せずに過ごした結果、 どのような経験をし、 どのような能力を身につけ、 どのようなエンジニアへと成長して行ったのか を、時系列に沿って以下の7章綴りでお送りいたします。 入社前から変わらない、私のキャリア目標 エンジニアの課題解決を促進していく。これからのteratailを考える 抱える苦悩、同期の成長とベクトルの違う自分 大規模なプロジェクトが動き出す そしてエンジニアへ 自分で企画し、要件を定義し、開発できるエンジニア レバレジーズで歩む、ユーザーファーストなエンジニアとしてのキャリア（まとめ） 本記事（私のキャリアパス）を通して、なかなか知る機会のないレバレジーズでのエンジニアキャリアをお伝えし、少しでもレバレジーズの魅力をお伝えできればと思います。 また、本記事では私がキャリアを歩む上で抱えた苦悩も紹介しています。 エンジニアでありながら、開発をせずに過ごす上で、本記事で紹介するような苦悩はつきものと思っております。全てが良いことだけで歩めるキャリアではなかったため、同じキャリアを歩まれている方に向けて、同じ悩みを抱える私を知ってもらうことでエールを届けられたらと思っております。 ※ お忙しい方は、後半2章をご覧ください。現在の姿はここに詰まっています。 対象読者 対象読者は以下になります。 レバレジーズでのエンジニアキャリアに興味がある方 エンジニアとしての仕事に興味がある方 エンジニア経験が浅く、今後のエンジニアとしてのキャリアパスが定まっていない方、あるいは、悩んでいる方 入社前から変わらない、私のキャリア目標 私のキャリアの目標は 「あったらいいな」を実現できるエンジニアとなり実現していくこと です。「あったらいいな」とは、自分だけでなく周囲のさまざまな人が抱えている悩みを解消するものであったり、あるいは、夢や空想上の欲しいと思うものやサービスのことです。私がこのキャリアの目標を立てたときは、ソードアートオンラインという作品のナーヴギアというゲーム機に憧れがあり、こうした憧れを実現できるような人になりたいと思っていました。そのためには、自分を含め、人が持つ「あったらいいな」を分析し、システムとして表現できる能力をつける必要がありました。 こうして、エンジニアとしての就活をはじめ、レバレジーズのエンジニアとなり、キャリアをスタートさせていきます。 エンジニアの課題解決を促進していく。これからのteratailを考える 入社後の研修を経て2020年7月にエンジニアとしてteratailチームに配属されました。最初は、teratailのサービスとシステムの理解を深めるために、過去のドキュメントの確認や簡単なバグの修正を通してオンボーディングを進めました。 当時のteratailは開発と企画の2チームがあり、開発はサービスの運用や機能追加・修正などを担当し、企画はteratailのユーザーを分析し、どのようにサービスを拡大するかを企画することをメインで行っていました。 エンジニアとして配属された私は当初、エンジニアとして開発スキルを伸ばすために開発をすべきであると考えていましたが、ユーザーを分析しサービスを改善・拡大するという企画チームの業務内容を知ったことをきっかけに、自分の目指すエンジニアになるためには企画での経験値を積んだ方が良いのでは？ と思い始め、teratailでの企画に興味を持つようになりました。 さて、なぜエンジニアである私が、開発ではなく企画に興味を持ったのでしょうか。 理由は大きく二つあります。 一つは、自身のキャリア目標を踏まえた時に、ユーザーの目線に立って企画を進める経験は重要で、必要な能力であると考えたからです。「あったらいいな」を考えるためには、 誰を ターゲットとして どのようなこと に悩んでいて 何を 必要としていて なぜ それを必要としているのか といった視点で考察できる必要があると考えており、このような視点で考察する能力を養ううえで、企画することは学びを得られる場であると考えました。 もう一つは、teratailでの企画の仕事はやりたくてもなかなかできない仕事だと考えたからです。teratailでの企画は、機能の改善のための企画だけでなく、サービスの今後を考え、どのように拡大していくのかを決めることまで担っていました。こうしたタスク（特に後者）に入社まもないうちから着手し経験を積めることも、自身のキャリアにとってプラスになると考えました。 そして、企画のタスクに手を挙げ、teratailを利用するユーザーの課題解決に向けた企画を進めることになります。 抱える苦悩、同期の成長とベクトルが違う自分 企画の仕事に携わるようになりしばらくした頃でした。 新卒のエンジニアとして入社した同期が皆、それぞれの配属先でエンジニアとしての成果を出すようになりました。同期との交流が盛んだったこともあり、互いが今どのような開発をしているのかを話す機会も多く、同期の活躍が自然と耳に入ってきます。 最初はこうした話を嬉しく思っていたのですが、次第にある不安を抱えるようになります。 それは、同期と比較した時の自身の「 開発力の低さ 」と「 成果を実感しにくい 」ことです。 配属されて間もない頃から企画に取り組んできていたため、開発はほとんどできていませんでした。同期が業務を通して開発力を伸ばす一方で、私の開発力は停滞したままでした。エンジニアであるのに開発力が伸びていない状況は、エンジニアとしての自信をなくす要因となりました。 そして、企画を通して実感できる成果のなさが、さらに自信を無くさせることになりました。開発では、作ったものをリリースすることですぐにエンドユーザーに届き、利用してもらえるため、目に見えた成果を実感しやすいです。一方で企画の仕事は、ただ企画をするだけでは目に見える成果とし現れず、そこから要件定義や開発を通して初めて形となります。また、企画としての完成度が高くなければ開発に動き出すことができず、何度も企画をやり直し、終わりの見えない仕事に成果を実感することはありませんでした。 こうして、同期との開発力の差の広がりや実感できる成果の少なさから、自分の仕事に自信をなくしていきました。 大規模なプロジェクトが動き出す 企画をしている頃、開発チームでは、CakePHPをTypeScriptを使用したマイクロサービスへとリプレイスするプロジェクトが始まります。 ※ 本記事では技術的な内容は記載しません。もし興味がありましたら、これに関する記事を公開しておりますので、以下からご覧ください。 tech.leverages.jp tech.leverages.jp 1年以上をかけてリプレイスを行うことになるのですが、私はリプレイスプロジェクトへはほとんど参画しません。これまで通り企画に従事しつつ、開発メンバーが行っていた保守運用の仕事を引き受けることになります。ここで、ようやく開発に少しずつ着手することになりました。 そして、リプレイスプロジェクトも終盤に差し掛かった頃に、サイトの動作テストを担当することになります。 比較的規模の大きいサイトでもあったため、一時的なテストチームを組むことになるのですが、エンジニアは私のみでした。限られた時間でテストを完了するには、非エンジニアの方でもスムーズにテストを進められるテスト項目書を作成する必要がありました。 このテスト項目書の作成の際に、企画で培ったユーザーやサービスを見る力が活きることとなります。それは、 サービスを利用する カスタマー テスト項目書を利用する テストチームのメンバー の2者のユーザーを考えてテスト項目書を作成することです。 サービスを利用するカスタマーが、普段、teratailをどのように利用しているのかを考えることで、サービスとしてあるべき姿をテスト項目として抽出し、 テスト項目書を利用するデバッグチームのメンバーが、どのような属性を持っているのか（どれくらいITリテラシーがあるかなど）を考えることで、テスト手順を書く際に理解しやすく表現することを自然とできるようになっていました。 このような形で企画の時に培った能力を発揮できていたことで、過去に感じられなかった成長を感じることができました。 こうしてデバッグを終え、リプレイスのプロジェクトが一段落しました。 　 そしてエンジニアへ 大規模なリプレイスプロジェクトが一段落したころに、本格的に開発をすることになります。バックエンド開発に始まり、次第にフロントエンドに寄っていき、現在に至るまで、フロントエンド開発に携わっています。 開発をする上でも 企画の経験が活きる 瞬間があり、また、過去に感じていた 不安が払拭し始めます 。 開発メンバーとして開発を始めたての頃は、設計や言語仕様への理解が浅く一つ一つのタスクをこなすだけで精一杯なことが多く、とてもエンジニアとはいえないレベルでした。それでも、実装したものをすぐにユーザーに利用してもらえ、Twitterやサービスのお問い合わせを通して多くのフィードバックを受けられるようになったため、成果を実感しやすくなりました。開発を通したこの体験が、過去に抱えていた不安を次第に解消してくれました。 そして、開発に慣れてからは、協働するメンバーが読みやすいコードとなるように意識したり、作業時間の短縮による時間的な余裕が生まれ、機能追加と併せてリファクタリングできる箇所を併せて修正したり、簡単に直せるバグや機能追加であれば対応することができるようになっています。 ここまでの開発経験を通して、ある程度自走したエンジニアとしてチームに貢献ができるようになりエンジニアとして自信が持てるようになっていきました。 自分で企画し、要件を定義し、開発できるエンジニア バックエンド・フロントエンド両方の開発に慣れ、開発に自信がつき始めたころ、小規模な機能追加プロジェクトを立ち上げることになりました。このプロジェクトでは、企画、要件定義、プロジェクトマネジメント、開発全てに携わる形で、これまでに得た能力を掛け合わせて遂行しました。 企画や開発ではこれまでに体験し得た能力をそのまま活かし、要件定義やプロジェクトマネジメントでは、企画や開発を通して得たユーザーファーストな思考から、 その機能を通してサービスのユーザーにどのような体験を生み出し、実現するか プロジェクトを遂行する上で、いかにしてメンバーの働きやすさを実現するか を自然と意識して取り組むことができるようになりました。 また、「 企画、要件定義、プロジェクトマネジメント、開発全てに携わりながらプロジェクトを遂行する 」ことは、私のキャリア目標である「 「あったらいいな」を実現できるエンジニアとなり実現する 」ことでもありました。 3年目にして、必要な基礎能力を一通り揃えることができ、こうして一つの機能として実現できたことで、「あったらいいな」を実現できるエンジニアとしてのキャリアを始められた気がします。 レバレジーズで歩む、ユーザーファーストなエンジニアとしてのキャリア（まとめ） これまでのまとめです。ここまでお読みいただいた方、本当にありがとうございました。拙く長い文章で読みにくかったことと思いますが、あと少しだけお付き合いください。 今日に至るまで、多くのことに挑戦させていただきました。サービスの企画を通してユーザー志向を身につけ、設計や開発の際に応用することで、サービスのユーザーや協働するメンバーに価値を提供することができるようになりました。（道中で苦悩もありましたが、、、 とはいえ、まだまだ至らぬ部分も多く成長できる余地が多いため、今後も「あったらいいな」を実現するエンジニアとして、より多くの価値を提供していけるように努めて参ります。 新卒からの3年間をこのように歩み、「あったらいいな」を実現するエンジニアをスタートさせることができたのは、「エンジニア = システム開発をする人」という枠にとらわれずに、さまざまな職域に挑戦できるレバレジーズの文化が大きく関わっています。レバレジーズには、こうした挑戦をするメンバーを支えてくれる上司やメンバーが多くいます。私の他にも開発以外の職域を経験しているエンジニアは多く、それぞれが違ったスキルを持ち、関わり合うことでより大きな価値を生み出しています。 本記事を読んで、レバレジーズのエンジニアとしてのキャリアに興味を持ってくださった方は、ぜひ、 採用フォーム よりご応募ください。 最後までお読みいただき、ありがとうございました。 https://recruit.jobcan.jp/leverages recruit.jobcan.jp

レバレジーズ株式会社 テクノロジー戦略室室長 兼 テラテイルチームリーダーの竹下です。 Architect New World on AWS 2022 のイベントで発表した際のスライドです。 teratailのリプレイスのインフラ面に注目した発表になっています。 現在レバレジーズでは一緒に働いてくれる仲間を募集しています。ご興味のある方は、以下のリンクからご応募ください。 https://recruit.jobcan.jp/leverages/