アプリケーションの処理を40倍高速化!効果的な最適化手法と実践事例の紹介

レバレジーズ株式会社 HRテック事業部の桐生です。

アプリケーション開発において、重たい処理の高速化は避けては通れない課題の一つですが、なんとなくで取り組んであまり良い結果が得られなかったり、そもそもどこから手をつけていいか分からなかったりすることもあるかと思います。

本記事では、処理の高速化を上手に行うための流れと、各ステップで抑えるべきポイントをご紹介します。

実際に私が携わっていたプロダクトでも、今回ご紹介する流れに則って高速化に取り組み、最終的に処理時間を40倍以上高速化することに成功しました。こちらの具体的な事例も含めて詳しくご紹介しますので、ぜひ最後までお読みいただければと思います!

なお、こちらは6月に開催されたレバレジーズ テックフェスにて発表させていただいた内容と同じものです。

大まかな流れ

以下の流れで処理の高速化を行っていきます。

  1. 無駄を含む処理を見つける
  2. 処理の遅い原因を特定する(計測)
  3. 高速化のための手段を考え、実装する
  4. 実装した高速化の効果を測定する

「無駄」を含む処理を見つけるには?

遅い処理を目の前にした時に、まず考える必要があるのは「この処理に削れる無駄は残っているか?」ということです。当たり前の話ではあるのですが、既にリソースを十分に使い切っている処理を高速化するのは難しいためです。

「無駄」が存在していることを判断するのに重要なのが、処理内容から考えてどのくらいの時間がかかりそうかを予測し、それを実際の処理時間と比較することです。「こういう処理だからこれくらいの時間がかかりそう」という予測を精度良く行うことで、無駄を見つけることができるようになります。

処理の性質ごとにかかる時間を計算する

処理時間を見積もる際には、「どんなリソースで」「どれくらいの量の」処理を行っているかに着目します。例えば、多くの処理で使われるであろう「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つご紹介しました。これらを用いて実際に遅い箇所を特定したら、ついに実際の高速化作業に取り組むことになります。

高速化に王道なし

いよいよ実際の高速化作業を行うわけですが、プログラムが遅い原因というのは実に様々で、そのため、高速化のための普遍的な手法も存在しません。ただ、それだけで説明を済ませてしまうのも寂しいので、今回は私が実際に関わった高速化の事例をご紹介して、高速化作業のイメージを掴んでいただこうと思います。

事例:月次処理の高速化

1つ目にご紹介する事例、給与計算ソフトにおける月次の勤怠締め操作の高速化です。こちらは会社ごとの全社員の勤怠データを集計して給与額を計算する処理なのですが、会社あたりのユーザー数が増加すると、計算完了まで何分もかかってしまうという問題がありました。

処理時間の見積もり

まずは、本来の処理時間を見積もってみます。具体的にかかっていた時間ですが、例えば300人程度の会社ですと7分以上かかっていました。ただ、実際に処理するデータの量を考えると以下のようになり、大きな乖離が生じています。

  • 300人 * 30日 = 9000個の勤怠データの集計 + 過去の有給使用データ(300人 * 数十件 = 数千〜1万件)の集計
    • 集計は基本的には時間を累積していくのみ
    • 実際は営業日は30日もないので多めに見積もっている
  • データの取得等含めて考えても何十秒もかかるのですらおかしい
    • 数万件のデータの取得(数秒) + データ処理(1秒以内) + 数万件のデータの書き戻し(数秒)にしかならないはず

これを踏まえると、この処理はまだ高速化の余地があると判断できます。

遅い箇所の特定

次に、実際に何が遅い原因となっているかを計測して調査します。処理部分にログを仕込んで計測した結果、DBのデータ読み書きに大半の時間を費やしていることがわかりました。

さらに詳しくコードを調査した結果、以下の2つの原因が判明しました。

  • 特定のテーブル(大きめ)にインデックスが張られていなかった
  • 1ユーザーの処理ごとに大量のクエリを発行していた

それぞれ詳しく説明します。

テーブルにインデックスが張られていなかった

今回の遅かった箇所の一つが、勤怠集計データを保持するRDBテーブルからのデータ読み込みです。読み取っているデータはユーザーごとに数十件程度なのですが(1ヶ月分のデータしか読み取らないため)、読み取りに異常に時間がかかっていました。これは当該テーブルに必要なインデックスが張られていなかったことが原因です。

データベースから条件で絞ってデータを取得する場合、何も設定しないとテーブル全体を検索するため、テーブル全体のデータ量に比例した時間がかかってしまいます。このため、通常は検索したいカラムにインデックスを張ることでこの時間を一定に抑えるのですが、今回操作していたテーブルでは検索対象のカラムにインデックスが張られていませんでした。このテーブルには過去の全ての勤怠データが保持されており、その総レコード数は数十万にも及んでいたため、不要なデータに対して検索をかけており時間がかかっていたのです。

対処法としては、単純に検索対象のカラムに有効なインデックスを張るだけでした。この対処だけで処理時間が元々の3分の1程度にまで減少しました。

1ユーザーごとに多数のクエリを発行していた

もう一つの原因が、1ユーザーごとにデータの取得・書き出しクエリを発行していたことです。今回の実装においては、1ユーザーごとに必要なデータを全てデータベースから取得しており、また結果データの書き込みも1行ずつ行っていたため、結果的にユーザーあたり100以上のクエリを発行しており、トータルで何万件ものクエリを発行してしまっていました。これによりネットワーク通信待ちとクエリ実行のオーバーヘッドで大きく時間がかかってしまい、何分も処理に時間がかかってしまっていました。

対処法としては、予め処理対象のユーザーのデータをまとめて取得することによりクエリ発行回数を減らしました。また、書き戻しの際もある程度まとめて書き込みクエリを発行するようにしました。


上記2つの施策を行ったことにより、計算アルゴリズムには一切手を加えませんでしたが、最終的に10秒程度まで処理時間を短縮することに成功しました。

事後の計測を忘れずに

高速化作業を行った後は、それが本当に高速化に寄与したかどうかを必ずチェックするようにしましょう。特に、2つ以上の変更を行った場合は、両方の変更に効果があったかどうかをそれぞれ調べないと、効果のない変更を入れ込んでしまうことがあります。実際に自分が高速化を行った際にも、片方の変更は高速化に寄与していたが、もう一方の変更はむしろプログラムを遅くしてしまっていた、という場合がありました。

高速化のためのコード変更というのは一般的にコードをより複雑にしてしまうものなので、効果のないコードはなるべく排除するようにしましょう。

まとめ

ここまでで、処理高速化のための大まかな流れを一通りご紹介しました。見積もりと計測に基づいて高速化作業に取り組むことで、より高い精度で作業を行うことができるようになるはずです。

本記事の内容が少しでも皆様のお役に立てば幸いです。最後までお読みいただきありがとうございました!

レバレジーズテックフェス 2023 春レポート

アイキャッチ

はじめに

こんにちは、レバレジーズ株式会社の堀本・中村です。本記事では私たち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出力を正しく修正するプログラムを作成して処理の中に差し込み、修正済み出力結果を回答として提出します。

課題で取り組むデータ補正の流れ また、それぞれの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と単一責務はあらゆるところについて回るので、注意して実装を進める必要性を感じました。

懇親会

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

最後に

今回の記事では、テックフェスから学んだことや感想を書かせていただきました。加藤潤一さんの貴重なお話を聞けたり、社内のエンジニアから普段は聞けない話を聞けて非常に面白かったです。 社内で技術ノウハウの共有を行なうイベントがあったり、外部から著名な方をお呼びして貴重な話が聞ける環境のレバレジーズで皆さんも一緒に働いてみませんか? レバレジーズに少しでも興味を持っていただけた方は、こちらからエントリーをお願いします!

ぼくらのフロントエンド1.0 - フロントエンドエンジニア育成プロジェクト

はじめに

本記事をご覧いただきありがとうございます。レバレジーズ株式会社 レバテック開発部の三浦です。

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のキャプチャ

弊社は挑戦する人を否定せず讃える文化が浸透しており、Slackなどで多くのポジティブなリアクションをもらうことができたため、最後までモチベーション高くやり切ることができました。

プロジェクトを通して見えた可能性

私自身、このプロジェクトに参画する前は、開発でフロントエンドに絡む課題や要求が発生した際は解決策がわからず、現場の業務委託や他チームの有識者に技術的なアドバイスやヘルプをよく求めていました。

しかし実際にプロジェクトを終えてみて、フロントエンドに対する自己効力感が明らかにつき、大抵のことは自走して解決できるようになった実感があります。これは、2ヶ月間フロントエンド開発にどっぷり浸かり、とにかく多くのアウトプットを出しまくったことから生まれた自信や成長によるものだと考えています。

現在は新しいプロジェクトに参画し、チームメンバーと日々設計に関する議論を交わしつつ、Next.jsのApp Routerを利用した開発に取り組んでいます。

フロントエンドエンジニア育成PJを通して得た経験はあくまでもきっかけでしかないと思っています。組織のフロントエンド開発の先頭に立ち、もっとエンジニアリングのアツい組織にしていけるよう盛り上げていきます。

おわりに

ご覧いただきありがとうございました。弊社では今組織としてエンジニアリングへの積極投資を進めており、フロントエンドエンジニア育成PJもその文脈にある取り組みです。

前述の通り挑戦を否定せず賞賛する文化があり、やりがいという面でもポジティブにチャレンジできる環境があります。 この記事を通して少しでも弊社に興味を持って下さった方はぜひ採用サイトをご覧ください!

エンジニアのためのGitHub Copilotガイド:レバレジーズの全社導入過程で見つけたノウハウ大公開

はじめに

 こんにちは、レバレジーズ株式会社テクノロジー戦略室室長の竹下義晃です。 エンジニアの生産性を高めよりよいサービスを提供するために、エンジニア全員にGitHub Copilotを導入しました。今回は導入過程でわかったGitHub Copilotを使いこなすための知見を赤裸々に公開していきたいと思います。

GitHub Copilot全エンジニア導入背景

会社の方針

 レバレジーズでは主要サービスであるレバテックレバウェルCareerTicketWeXpatsなどの人材サービスをはじめ、最近ではオンライン診療サービスのレバクリをリリースするなど国や業界に関わらず事業拡大を進め、理念である「顧客の創造を通じて、関係者全員の幸福を追求し、各個人の成長を促す」を追求しています。そのために、開発組織を強化し、より早くより良いサービスの実現を目指しています。

 近年、GitHub Copilotを始め、OpenAI ChatGPTGoogle 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

レバレジーズ株式会社ではフロントエンドエンジニアも、それ以外のエンジニアも幅広く募集中です。 もし今回の勉強会の発表を見てご興味を持っていただけたなら、こちらのページからご応募ください。

勉強会の開催も随時受け付け中です

今回はフロントエンドをテーマに合同勉強会を開催しましたが、レバレジーズはオールインハウスで開発しておりフロントエンド、バックエンド、インフラ、機械学習と幅広い領域をカバーしているので、フロントエンドに限らず様々なテーマで合同勉強会を開催してくれる企業さまを募集中です。ご興味ある企業さまがいらっしゃいましたらこちらまでご連絡いただけると嬉しいです。

新人エンジニアが振り返る、学生・インターン・正社員におけるエンジニアリングの違いと3つの学び

はじめに

こんにちは、2022年新卒の河原です。

突然ですが、皆さんは今までどのような開発体験をされてきましたか?
学生時代からゴリゴリに開発していた人もいれば、全く違う職種から独学やプログラミングスクールで学んでエンジニアリングに携わっている人など、人によってキャリアは多種多様だと思います。

私の場合はこれまで、学生・インターン・正社員としてシステムの開発に携わってきました。まだ社会人になってから1年と少ししか経っておらず、学生時代の経験もある程度は新鮮に覚えています。

この記事では、そんな私が学生・インターン・正社員でのエンジニアリングを通して痛感した『開発体験の差』と、今後に活かしたい『3つの学び』をご紹介したいと思います。

日々の業務に追われ、過去を振り返ることを忘れがちになっている方々が「私もこんな経験があったな」「僕はどう成長してきただろうか」と思い出す・考えてみるきっかけになるような記事になれば嬉しく思います。

自己紹介

まずはじめに、自分の経歴を軽く紹介させていただきます。

学生時代、高専でコンピューターサイエンスを広く浅く学び、情報系の大学・大学院へ進学して情報系に特化したことを学んできました。
研究は、自然言語と音声といった複数の感覚次元を機械学習させるマルチモーダル感情認識を題目として扱っていました。当時はまだ最近話題のGPTの「GPT-2」が論文として発表され、様々なベンチマークを更新し、GeneralなLLMの台頭にワクワクしていた思い出があります。

その後レバレジーズに内定し、「早くから社会で通用する本格的な開発経験を積みたい」と思い、2021年の8月からエンジニアとして早期のインターンを始めます。
インターンでは、未経験のエンジニアが中心で構成された教育目的のチームにて、小さめの社内システムを要件定義・技術選定から設計・開発まで一通り経験させてもらえました。

そして、去年4月に正社員として入社し、現在は正社員として、若年層領域の事業を展開する『ハタラクティブ』や『キャリアチケット』というサービスで、営業職が使用するSFA(Sales Force Automation)開発に携わっています。
今のチームに移動してきて1年ほど経った状態です。

学生と社会人の違い

開発の『目的』

私が学生と社会人(インターン・正社員含む)で感じた開発体験の最も大きな違いは、開発の『目的』です。
どのように目的が違うのでしょうか?私の経験と合わせて、具体的に説明していきたいと思います。

私の学生時代は趣味や学業の一環で、簡単な

  • 2Dゲーム
  • 組み込みシステム
  • Webシステム
  • AIモデル構築

など様々な開発をしていました。
これらは、学業で必要になったり、興味関心が沸けば「開発してみる!」といった具合で、特に大きな目標はなく『開発を楽しむ目的』でいろんな開発をしてみていました。

しかし、どれも『システムが完成して目的を達成すれば、開発も終わり』のような拡張性がなく、モチベーション頼りの単発な開発でした。
結果として、作り上げたシステムとしての品質は高いとは言えず技術的な深掘りもあまりできておらず、また自身の能力的が成長した実感もあまりありませんでした

それに対して、社会人での開発目的は『利益を生み出す目的』へと変わりました。
社会人は全員「ビジネス的な視点」を持つ必要があります。
それはエンジニアも例外ではなく、開発したシステムを含めて、最終的には市場において競合優位性を確保する「サービス」を作り上げて『利益を生み出す目的』に合致したシステムを開発していく必要があります。

観点の多さと責任範囲

目的に付随して『責任』や『観点』にも違いが生まれてきました。
学生時代の開発観点は、システムの機能性ばかりに注目し、「とりあえず動けばOK!」のような考えが先行していた記憶です。

対して、社会人では利益を生み出すために正確で安全なシステムが、迅速にリリースされる必要があります。
そのため、開発観点はさらに多角的になり、

  • コードの可読性
  • 保守性
  • スケーラビリティ
  • アジリティ
  • セキュリティ

などの品質を満たした開発が必要になりました。

責任の変化なども加えて、感じた特徴の違いをまとめると以下になります。

学生 社会人
目的 開発を楽しむため 利益を生み出すため
モチベーション ・興味のあるものを作ってみたい
・学業で必要になったから
・システム、サービスをグロースさせたい
・社会に役立つシステムにしたい
開発物 いろいろ Webシステム
開発期間 完成すれば終了 継続的な利用がされる
開発観点 ・機能性
・正確性
(上記も品質は低い)
・機能性
・正確性
・保守性
・スケーラビリティ
・アジリティ
・セキュリティ
などなど…
責任 基本自分のみにかかる システム、サービス、会社全体へ影響することもあるため大きい

開発に向かう姿勢

ここまでで、違いを紹介してみましたが、決して学生時代の開発が良くなかったわけではありません。

学生時代の自由な開発がなければ、そもそもエンジニアリングに携わってみようというモチベーションも発生していなかったかもしれません。また、どんなシステムでも作ってみることで、わかることはたくさんありました
現在も、興味のある技術があれば、上手く開発できるかどうかはさておき触ってみたりしています。それは、個人開発の自由さと楽しさを知っているからだと思っています。

しかし、私個人としては作成したシステムが利益につながりより多くの役割を果たすことで、社会の役に立っていると実感できる社会人での開発の方が楽しく感じています。
これは、元々アルバイトなどの仕事が好きであった私の性に合っていたのかもしれないですが、システム開発を通して利益を生み出し、サービスをグロースさせるのは社会人ならではの醍醐味だと感じています。

インターンと正社員の違い

続いて、インターンと正社員で感じた開発体験の違いについてです。はじめに、それぞれの業務内容を説明します。

インターン時代は、小さめの社内システムを要件定義・技術選定から設計・開発まで一通り行いました。新規システムであり、かつ規模も小さいことから採用した技術はモダンなものが中心でした。

そして現在は、正社員としてSFA開発に携わっています。 SFAは、営業プロセスの自動化・効率化を行い、業務上の顧客の流入から売上の確定に至るまでの全てのデータを一元化することで、

  • 営業業務の効率向上
  • データ分析による戦略の立案
  • 施策の効果検討

など多方面に役立てられています。 営業・マーケティング・企画・データ戦略室といった関係者が存在し、システム自体も8年ほど前から存在するため、非常に高機能かつ規模も大きめなシステムです。

開発はスクラム体制で、新規機能開発とCakePHP→Laravelへのフレームワークリプレイス作業がメインです。
技術選定やインフラに触れる機会は減りましたが、複雑な要件を把握して適切なソリューションを考案し、設計・開発を通して解決していくことは、良いエンジニアリング経験になっていると感じています。

それぞれの特徴をまとめると以下のようになります。

インターン 正社員
特徴 社内で利用目的の新規システム 約8年前から開発・運用しているSFAシステム
目的・要件 シンプル 複雑で多種多様
規模 小さめ 大きめ
機能 少なめ 多め
関係者 ・主にエンジニア
・関係者数が少ない
・営業、企画、マーケティングなど
・関係者数が多い
技術 モダンなものが中心 新旧混在
担当業務 ・要件定義、技術選定
・設計
・開発
・運用保守業務(フレームワーク移行・インシデント対応・法務対応)
・新規機能設計・開発
開発 FE・BE・インフラ全て BE中心
開発体制 ウォーターフォール スクラム

システムの『役割』の理解の深さ

特徴や規模、言語・技術が全く違う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

レバレジーズ株式会社ではフロントエンドエンジニアも、それ以外のエンジニアも幅広く募集中です。 もし今回の勉強会の発表を見てご興味を持っていただけたなら、こちらのページからご応募ください。

勉強会の開催も随時受け付け中です

今回はフロントエンドをテーマに合同勉強会を開催しましたが、レバレジーズはオールインハウスで開発しておりフロントエンド、バックエンド、インフラ、機械学習と幅広い領域をカバーしているので、フロントエンドに限らず様々なテーマで合同勉強会を開催してくれる企業さまを募集中です。ご興味ある企業さまがいらっしゃいましたらこちらまでご連絡いただけると嬉しいです。