RAKSUL TechBlog

ラクスルグループのエンジニアが技術トピックを発信するブログです

ノバセルにおいて意思決定ドキュメントの運用を3ヶ月してみて分かったこと

こんにちは。ノバセルのデータプロダクトチームにて開発エンジニアをやっている山中(yamnaku_)です。 現在は、ノバセルの各種分析システムのバックエンド開発を行なっています。 特に、データウェアハウス製品Snowflakeを利用したデータ基盤の開発・運用に取り組んでいます。

私の所属するチームでは、意思決定を記録するドキュメントとして、Architectural Decision Record(ADR)の運用を始めて3ヶ月ほどが経ちました。 今回は、感じることが出来た効果についてご紹介したいと思います。

背景と課題

ひとつ目のプロダクトである「ノバセルアナリティクス」のローンチから3年が経ち、ノバセルでは様々なシステムが現在稼働しています。 ノバセルはお客様のデータや、検索量といったサードパーティデータをTVCM放映データと掛け合わせて分析を行っています。 そのようなサービスの特性上、モノリシックなシステムが鎮座する形ではなく、小規模なシステムやバッチが多く運用される状況になっています。 特に、以下のような3つのカテゴリに分類されるシステムが多く存在します。

  • データを収集するバッチシステム
  • データを統合し、分析するバッチシステム
  • 分析結果をユーザーが参照・検索できるアプリケーションシステム

そうした中で、各システムのアーキテクチャ意思決定の過程については、ドキュメンテーションが不足していたり、ドキュメントの置き場所が指定されていないことにより散在していました。 特に、以下のようなコードを読んでも分からない点については、ドキュメントによって補う必要がありました。

  • どういった選択肢を検討し、なぜそのアーキテクチャを選択したのか
  • 意思決定の背景にあったビジネス上の事情や顧客の要求

また、メンバーからは「(チームや組織としての)意思決定の流れが見えにくい」という意見ももらっていました。 こうした項目について、共通のドキュメントフォーマットを定め、置き場所を明示することにより、以下のような効果を期待しました。

  • アーキテクチャ選定の意思決定プロセスをフォーマット化し、より早くより良い意思決定を助けること
  • チーム体制の変更や、新メンバーが加入した際に、スムーズにシステムの理解が進むこと
  • 意思決定のフローを透明化し、状況の把握をしやすくしたり、納得感を醸成すること

採用したフォーマット

ドキュメントの運用方法や、フォーマットの策定にあたっては、『Googleのソフトウェアエンジニアリング』の第10章「ドキュメンテーション」を参考にしました。 初期はDesign Documentを参考にしながら以下のような項目を最終的に採用しました。

ドキュメントオーナーと変更履歴

ドキュメントはメンテナンスや維持のため、ドキュメントオーナーを明記すると良いとされています。 そのためドキュメントの冒頭にドキュメントのオーナーを明記するようにしています。 また、オーナーが交代したり、内容が途中で変わってしまうこともあるため、変更履歴も合わせて記述するようにしています。

NotionのTableを使っています。

ドキュメントの目的

このセクションには、何を決めるためのドキュメントなのか、ということを記述します。

優れたドキュメントを作るコツは、ドキュメントにおける目的を一つに限定することです。 そのため、すべての意思決定ドキュメントは、単一の意思決定を出すための目的に限定します。 もし論点が複数存在する場合には、論点ごとにドキュメントを分割しています。

背景

このセクションには、目的に記載した、意思決定の検討事項や論点に至るまでの背景や経緯について記載します。 すでに他のドキュメントでまとめられていることも多いため、他ドキュメントのリンクを貼ることもあります。 もしくは、Notionの「Copy&Sync」機能を使って他のドキュメントの一部を切り出して添付したりして、簡潔に背景を理解できるようにしています。

あまり長く書きすぎると読み手の理解も低下するため、シンプルに記述することを心がけています。 また後述するように、ビジュアルなどを活用することも効果的に思われます。

概要

このセクションには、良い意思決定をするために必要な情報について簡潔にまとめています。 主な情報は以下の通りです。

  • 現状システムの整理
  • 検討した選択肢・代替案
  • 意思決定の軸
  • 最終的な決定事項・結論

選択肢とそれらから一つを選び出す基準作りは、意思決定の質を決める重要な要因になるため、十分に検討しきれているか注意します。 また、意思決定の軸が先に決まっていることにより、選択肢の早期な枝刈りも可能になります。

例です。各ポイントに重みをつけることも重要です。

これらの情報をまとめた上で、最終的な結論も記載します。

詳細

概要に記載した項目について、実際の調査結果や緻密なシミュレーションを行い、その結果を記載します。 あらゆる情報を集めたり、厳密な意思決定を行おうとして時間をかけすぎないように注意します。

やってみないと分からないことも多く、一定のリスクを許容しないと先に進めない状況があります。 Notionの「Callout」を利用して、受け入れたリスクなどの注意事項については明示しています。

また、概要のセクションで決めた意思決定の軸に照らし合わせ、あまり重要でない項目は調査を簡略化するなどして効率化を図っています。

3ヶ月の運用の結果

私の所属するデータプロダクトチームでは、2023年12月に上記のドキュメントフォーマットを決定しました。 それ以降、全ての意思決定ドキュメントをNotionの一つのデータベースに集約しました。 また、開発における設計フェーズにおいては、このドキュメントを作成した上でチームレビューを行うプロセスを導入しました。 これにより、開発フローの中で、本ドキュメントが自然と運用できることを目指しました。

呼び方の問題

このドキュメントを決める際にはDesign Documentを参考にしていたため、当初DesignDocと読んでいました。しかし、実際の運用としては、各検討タイミングにおける意思決定を整理するドキュメントとなっていました。DesignDocのように中長期にわたってメンテナンスされるものを運用することは現実的でありませんでした。のちのち、Architectural Decision Record(ADR)について知りました。こちらの方が実態と近かったため、現在はADRと呼ぶよう変更しています。

また、DesignDocと呼んでいた時期には、実態からずれていることでメンバーが混乱してしまう、といった事象も生じました。実態に沿った形へ名称を統一するなどの取り組みは、混乱を防ぎ意図を正しく伝えることができるため、ドキュメントを浸透させるために注力すべきことだと改めて感じました。

より良い目的設定や、多くの選択肢が出てくるようになった

このドキュメントでは、目的や背景を最初にまとめていきます。その過程で、目的について立ち返るプロセスが発生します。この時、より本質的な目的や問題設定を行えることがあります。実際に、事前の検討段階で工数大と予測して省かれてしまっていた要件がありました。しかし、目的を整理し直してみると、それが営業観点で重要な要件であり、かつ実際には工数もそれほど変わらないと分かったこともありました。

また、選択肢を検討している場合にも、目的を意識しながら進めることができます。例えば、より工数を少なくするためにはどのような手段が取りうれるのだろうか、というように考えることで、新しいツールや技術の採用を検討することにもなります。また、なんとなくやらないといけないと思っていた作業が、目的に照らし合わせると不要であると気づいたこともありました。

意思決定に関する自信の醸成と型化

この3ヶ月で、チーム内で9つのドキュメントが作成され、3人がドキュメントを作成しました。 ドキュメントのレビューはチームメンバーがお互いに行いあい、曖昧な点や検討が不足している部分などについては事前にコメントし合いました。 アーキテクチャ選定に関する意思決定が透明化され、事前にトレードオフなどを認識した上で次に進むようになったため、自分たちの意思決定に自信を持てるようになったのではないかと思います。

また、ドキュメントを作成した3人のうちの1人はチームに来てくれているインターン生でした。 ドキュメントのフォーマットに従うことで、検討した選択肢などを列挙した上で、実装詳細を詰めていく、という意思決定プロセスを体験してもらうことができました。 複雑な検討が必要な開発内容だったものの、良い実装案の提案・実装を行なっていただきました。

加えて、初めてドキュメントを書く際には、書き方に戸惑うことも多いことがわかったため、今後はドキュメントの意図や書き方についてより丁寧に説明していきたいと思っています。 ちなみに、フォーマットを細かく規定することは避け、一般的な意思決定のやり方や思考の仕方について整理することで、自然と書くべき内容を決めてもらうことが出来るようになればと考えています。

ビジュアルの活用

入社以来、これまで多くのドキュメントを書いてきましたが、ひとつ課題に感じていたのが、ビジュアルが不足しがちという問題でした。アーキテクチャ図もそうですが、業務フロー・シーケンス・意思決定ツリーといった様々な情報を文章で表現してしまうことが多く、直感的に理解しにくいドキュメントを作成してしまっていました。

意思決定ドキュメントを正しく機能してチームで運用できるようにするためには、なるべくビジュアルを活用しドキュメントの理解を容易にすることが重要だと考えています。

そこで、Figjamをノバセルの全開発者分のライセンス分購入することにしました。すでに社内でFigmaが導入されていたことや、豊富な機能を持ちつつ利用料もリーズナブルだったことが決め手です。

また、Notion上のビジュアルとしてはMermaid記法を利用することもあります。 自然言語で図の内容をLLMに伝え、Mermaid記法のコードを書き起こしてもらうこともあります。

Figjamは、ドキュメンテーションの他に、以下のようなシーンでも利用されています。

  • チームの振り返りでのホワイトボードとして
  • ブレインストーミングの場として
  • 意思決定ツリー・マッピングなど、ディスカッションの補助資料として

フローチャートもこの通り。

Figjamの導入は、ドキュメンテーションのみならず、コミュニケーションにおいても大きな助けとなるツールになりました。

まとめ

本記事では、エンジニアのためのより良い意思決定のために、ドキュメンテーションを頑張っていますという話についてご紹介しました。 State of DevOps Report 2023 でもドキュメンテーションの重要性は強調されています。 今回3ヶ月という短い期間での取り組みではありましたが、実感できる効果もあり、今後も改良を重ねつつ続けていきたいと考えています。

一方で、このようなドキュメントが、後々振り返った時のチームや個人への糾弾の材料となるのではないかと危惧したこともありました。 しかし、この3ヶ月の運用の中でその懸念は杞憂だと思うようになりました。 透明性の高いドキュメントに情報がまとめられ、チームのレビューフローにも組み込まれるようになったことで、誰かひとりの責任になることはありません。 そして、このプロセスを踏むことにより、意思決定の質を担保することが出来るようになりました。 また、必要な情報がしっかりとまとめられていることにより、振り返りの際にも建設的な議論が出来るように思います。

エンジニアリングとは問題解決の手段であり、よりシャープな問題設定・解決策を提示することも重要なスキルの一つです。ドキュメンテーションがその助けとなることを感じることが出来た3ヶ月でした。

Wi-Fi接続ログから通勤手当を自動申請:コーポレートエンジニアの取り組み

こんにちは。ラクスルのCorporate Application Developmentに所属している堂野です。 今回はWi-Fiの接続ログから通勤手当を自動申請する方法をご紹介するのですが、その前に、コーポレートエンジニアについて軽くお話しさせてください。

コーポレートエンジニアって何してるの?

「全社のコーポレート業務生産性を向上させる」ことを目指し、日々改善に取り組んでいます。

コーポレート業務とは、経理・会計、人事、総務、法務など、会社や企業の日々の運営や管理に関わる様々な業務活動を指します。これらの業務を効率化し、リソースを最大限に活用するため、様々なプロジェクトに取り組んでいます。

どんなプロダクトをつくっているか・・・

私が所属しているCorporate Application Developmentでは、「CORP DIR」というプロダクトを開発してます。これは、企業ディレクトリ(従業員、部署、資産のマスターデータ管理)やヘルプデスク、資産管理などを行い、企業リソースを効率的に使えるようにするものです。

その他、ITコストの予実管理や社内ナレッジBotの開発なども行い、全社のコーポレート業務生産性向上に努めております。

具体的には?

Wi-Fi接続ログから通勤手当を自動申請

あらまし

コロナを経験しハイブリッドワークに移行が進み、通勤手当の支給が定期代から毎月の申請へと変更となりました。それにより、通勤手当を従業員が毎月申請する手間と、労務が承認する手間、申請の確認に加え督促する手間が増加しました。

この手間を解消するため、Wi-Fi接続ログを活用することで、申請レス, 承認レスの新たな仕組みを構築しました。 新しい流れは、毎月1日にシステムから前月の出社日数が自動的に集計され、月初の2営業日までは必要に応じて修正ができる旨のSlack通知を行い、修正がなければそのまま処理されます。これにより、従業員は毎月の申請作業から解放されるだけでなく、労務部門も確認や督促の手間を大幅に軽減することができました。

課題

勤怠Wi-Fi打刻の仕組みが以前あったため、Wi-Fi接続のmacアドレス毎の接続ログは収集できることが分かっていました。しかし macアドレスに対応するユーザーの自動特定や、多拠点対応まではされておらず、その部分の仕組み構築の工数が効果に見合うかが一番の課題でした。

インフラ構成 課題図

費用対効果の試算

まず初めに費用対効果の試算を行いました。 仕組み構築にかかる費用が約30人日であるのに対し、削減効果は1ヶ月あたり約2人日であり、投資の回収見込期間は15ヶ月でした。 しかし、コロナ収束後に定期代支給へと再び見直される可能性を考慮すると、回収期間が長すぎて費用対効果として見合わないという試算でした。

当初の設計では、各オフィスのスイッチから Macアドレス毎の接続ログを収集し、Macアドレスに対応するユーザーは デバイス管理に導入しているjamf と Intune から取得することを考えていました。しかし費用対効果が合うか微妙であったため、対象とするオフィスを目黒オフィスのみに絞ることにしました。目黒オフィスは Wi-Fi に Mist AI を利用して認証しているのでMist AI の APIからユーザー毎の接続ログが取れるため、システム構成をシンプルにすることができることからそのような結論に至りました。その結果、回収見込期間は10ヶ月に短縮できました。目黒オフィスで対象従業員の80%強はカバーされており、その他オフィスはWeb上で容易に出社日を登録できる機能を提供することでカバーしました。

実装方法

Mist AI導入済みのためAPI経由で接続ログを取得することができます。APIで取得可能な情報には、接続アクセスポイント、接続日、メールアドレスが含まれており、接続ログから取得したメールアドレスにより、ユーザーの識別が可能です。

Mist AI の APIからのデータ収集は、日次のECS Task とし、保存先は CORP DIR が利用している RDS としました。性能的に問題となりそうであれば DynamoDB 等の利用も考えましたが、現時点では問題なさそうなので、RDSに保存しています。

また障害時のリカバリを容易にするため、日付指定で簡単にリランすることができるようにし、過去データを更新できる仕組みにしました。

本格開発する前に実現可能性を検証

Mist AI利用は初めてなので技術面やデータ精度に問題がないか検証ができるよう、簡易スクリプトでMist AI の1ヶ月のログを取得して判定した出勤日をGoogle スプレッドシートにまとめて、実際の出勤日があっているか各ユーザーに確認してもらいました。

そこで、以下のような課題が明らかになり、対応目処をつけてから本格開発しました。そのことにより、開発の手戻りもなく本番リリース後のトラブルもゼロにすることができました。

検証で検出した課題 対応
Guest Wi-Fi接続で出勤と判定されない Guest Wi-Fi接続にメールアドレスの入力を必須に
0時以降オフィスに残り誤判定 日替わり時刻を4時に設定して判定するように
同月内で貸与PC交換で利用者が変わり誤判定 接続日より前の最終認証ユーザーを取得して利用する
共用端末でのWi-Fi接続で誤判定 判定対象外の端末を画面登録できるように

まとめ

Wi-Fi接続ログを用いて通勤手当の自動申請を実現するために、以下の2点に焦点を当てて開発を進めました。

  • コスト意識を高く持ち、MVPを重視する

    完璧を目指すのではなく、最低限必要なものと費用対効果のバランスを重視しました。

  • 実現可能性を低コストで検証してから本格開発を行う

    開発に費用をかけたが品質が低い場合、ユーザに価値を届けることができず、その後の対応に余計なコストがかかり本末転倒となる可能性があります。

おわりに

今後は生成系AIの活用など、さらなる技術の導入も考えています。これらの取り組みを通じて、より効率的な企業運営を実現し、社員の皆さんがさらに働きやすくなるように貢献していきます。

承認時間が半減!Slack Boltでワークフロー承認を最適化してみた

こんにちは!ラクスルのCorporate Application Developmentに所属している高橋です。
普段の業務としては社内システムの機能開発・改善に取り組んでいます。
ラクスルでは上司への承認依頼などのワークフローを管理するシステムを自社開発しています。
最近ではワークフローをSlack上で完結させる機能開発を行いました。
この取り組みにより、申請してからワークフローの全ての承認が完了するまでに要していた時間が平均6時間20分から2時間54分に短縮されて承認時間が約半分になりました。

目次

なぜワークフロー管理を自社開発しているの?

本題へ入る前に、我々が所属しているCorporate Application Developmentでの開発方針について軽く触れておきたいと思います。

  • SaaSを積極的に採用し、独自業務の価値がなければSaaSに業務を合わせる
    • SaaSにロックインされないように重要データは自社管理し、いつでも乗り換え可能にしておく
  • コーポレート業務の生産性や体験を大幅に向上させる機能や、コストパフォーマンスの良いSaaSがない機能のみ内製開発する

導入に至った背景

それでは、なぜSlack上でのワークフロー完結化を目指したのか、その背景を見てみましょう。

改善前のSlack通知
改善前のSlack通知では承認をするためにはタイトルリンクをクリックし、別の画面に移動してから承認ボタンを押す必要がありました。
そのため、承認画面に遷移するのが手間で通知を見てそのまま放置されるケースもありました。

承認画面を経ずにSlack上で完結できるようなUIを実現できれば、承認作業の手間が軽減されることを期待されて開発に至りました。

改善後のSlack通知がこちらです。

改善後のSlack通知
承認者はSlack上で申請内容を確認し、画面に移動することなくボタンを押すことで承認することができます。

どのように実現したか

今回はSlack公式のフレームワークであるBoltを採用しました。

BoltはSlackの公式で提供されているSlackアプリ開発フレームワークです。
SlackBoltを使用すると、メッセージやイベントを受信し特定のアクションを実行するSlackボットも簡単に作成できます。
現時点ではPython、Javascript(Node.js)、およびJavaで利用することができます。
今回は、チーム全体が慣れ親しんでいるNode.jsを採用することにしました。

システム構成図

承認依頼

承認処理

Slack Appsの設定

まず初めにLambdaとSlackの連携が必要です。
承認ボタンを押したときにPOSTするURL先を設定します。

Slackではインタラクティブコンポーネントという仕組みがあります。
これを使うとユーザーがボタンをクリックするアクションをトリガーすることができます。

Slack App管理画面のInteractivity & Shortcutsから設定が可能です。

Node.jsの実装例

SlackではBlock KitというUIのフレームワークが提供されており、それを利用することで簡単にボタンを表示することができます。

それでは、実際に承認ボタンを表示する例を見てみましょう。 以下のようにJSON形式でSlackに表示させたいUIを指定することができます。

approve_action_id = 'approve_action_id'
{
    block_id: "button_group",
    type: "actions",
    elements: [
      {
        type: "button",
        style: "primary",
        text: {
          type: "plain_text",
          text: "承認する",
        },
        confirm: approveConfirm(locale),
        action_id: approve_action_id,
      }
    ],
  }

詳細な設定については、公式ドキュメントを参照してください。

block_actionsに承認ボタンで指定した同じaction_idを設定することでボタンを押した時の処理が実行されます。

approve_action_id = 'approve_action_id'
app.action(
    { type: "block_actions", action_id: approve_action_id },
    async ({
      body, ack, client,
    }) => {
  // 承認ボタンを押下時の処理を書く
 }

つまずいたSlackの3秒ルール

開発が完了し、いざリリースとなった際に問題が発生しました。
それはSlackアプリにおける3秒ルールです。
Slackからのリクエストに対して3秒以内に応答がない場合は、タイムアウト扱いにされるという仕様があります。

具体的に問題となったのはコメント投稿をした場合にエラーが表示されるようになりました。
これまでの処理フローとしては以下の通りでした。

  1. 2度押し防止のため、承認/否認/コメントのみのボタンを非表示にする
  2. ワークフロー管理システムのコメント投稿APIにリクエストを送信する
  3. Slack APIにコメントが作成された旨のメッセージを投稿する
  4. 承認/否認/コメントのみのボタンを表示する

実装中に処理時間が増加し、気づかぬうちに3秒以上かかっていたようです。
一旦3と4を非同期化することで3秒以内に対応できましたが、今後は2の処理も非同期化する予定です。

まとめ

Slack上で承認作業を完結することによって承認時間を約半分まで短縮できた事例の紹介でした。
フレームワークを利用することで、Slackアプリの開発もそこまでハードルが高くないと感じました。
開発は主にRubyで行っていますが、今回のように他の言語も採用しています。
特定の技術に縛られることなく、ユーザーの課題解決に貢献できる手段を積極的に採用するようにしています。
また社内で利用されているシステムであるため、改善した際には直接ユーザーからの喜びの声を聞くことができるのもやりがいに感じています。

一番読まれた記事はコレ!RAKSUL Tech Blog 2023PVランキングTOP10!

こんにちは、ラクスル技術広報の和田です。
いつもTechBlogをご覧いただき、ありがとうございます。

2024年のはじまりに、RAKSUL TechBlogで2023年にもっとも多くの方に読んでいただいた記事を、年間PV数によるランキング形式でTOP10まで発表いたします。
是非ご覧ください!

10th place

  • OpenAPI Generator typescript-fetch を使ってみる

techblog.raksul.com

こんな方にオススメ!

  • OpenAPI のクライアントコードを自動生成する方法を知りたい方
  • typescript-axios の挙動の変化について知りたい方
  • OpenAPI のクライアントコードの品質向上に取り組んでいる方

9th place

  • StepFunctions を CDK + Typescript で構築するサンプル集

techblog.raksul.com

こんな方にオススメ!

  • StepFunctions を CDK を使って構築したい方
  • StepFunctions の基本的な使い方を知りたい方
  • AWS の各種サービスを連携させたワークフローを構築したい方

8th place

  • マイクロサービスにSagaパターンを用いて検証を行った

techblog.raksul.com

こんな方にオススメ!

  • マイクロサービスアーキテクチャにおけるトランザクション管理に興味がある方
  • Sagaパターンの概要やメリット・デメリットを知りたい方
  • マイクロサービスアーキテクチャにおけるSagaパターンの実装例を知りたい方

7th place

  • 機械学習の推論用REST APIサーバーをAmazon SageMakerで構築するまでに考えたこと

techblog.raksul.com

こんな方にオススメ!

  • 機械学習の推論をREST APIとして提供したい方
  • SageMakerを利用した推論サーバーの構築を検討している方
  • FastAPIを用いた開発に興味がある方

6th place

  • iframe で複数の管理画面を1つの統一されたサイトに見せるパターンのまとめ

techblog.raksul.com

こんな方にオススメ!

  • iframe を使って複数の管理画面を統合したい方
  • iframe を使って複数ページのサイトを構築したい方
  • 既存の管理画面をリニューアルしたい方

5th place

  • Sidekiq queues & job priorities management

techblog.raksul.com

こんな方にオススメ!

  • Ruby でバックグラウンドジョブ処理を行うシステムを開発している方
  • Sidekiq をジョブキューシステムとして活用している方
  • ジョブの優先順位付けに課題を抱えている方

4th place

  • Protocol Buffers で快適な API 開発環境を構築した話

techblog.raksul.com

こんな方にオススメ!

  • マイクロサービス化に伴い、Web API の開発を検討されている方
  • IDL の導入を検討されている方
  • Protocol Buffers の利用を検討されている方

3rd place

  • 【全2回】AWS Lambda x FastAPIによるPythonモダンAPI開発のすゝめ

techblog.raksul.com

techblog.raksul.com

こんな方にオススメ!

  • Pythonを使用して新しいプロジェクトを開始しようとしている方
  • Python開発に役立つリンターやフォーマッターなどの効率的なライブラリを探している方
  • Pythonでの開発に際して参考にしたいアーキテクチャを探している方

2nd place

  • 【Ruby】Array から Hash を作る方法7選(a.k.a. やっぱり Array#zip はかわいいよ)

techblog.raksul.com

こんな方にオススメ!

  • Array から Hash を作成する実装方法を知りたい方
  • Array#zip 以外の方法も知りたい方
  • Ruby を使っている方

1st place

  • HonoとDenoで社内ツールを作ってみた

techblog.raksul.com

こんな方にオススメ!

  • モダンな技術スタック(Hono、Deno、Twind、Alpine.jsなど)に興味がある方
  • 社内ツールの開発に携わっている方
  • 社内ツールの開発を検討している方

おわりに

RAKSUL TechBlog 2023PVランキングはいかがでしたでしょうか。
2024年もブログを通して、さまざまな技術情報を発信していきます!
引き続き、RAKSUL TechBlogをよろしくお願いします!

年末年始にソースコードのお掃除大会をした話

ラクスル事業本部サーバーサイドエンジニアの杉山です。2023年4月に新卒で入社しました。もう数か月で入社から1年とは、時の流れがはやいですね。 現在は印刷のラクスルにおける商品追加やその他運用・保守開発に携わっています。

今回の記事では、2023年12月末から2024年1月にかけて私の所属しているチームで行ったコードお掃除大会について紹介します。

続きを読む