RAKSUL TechBlog

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

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月にかけて私の所属しているチームで行ったコードお掃除大会について紹介します。

続きを読む

Tech組織が成長し続ける仕組みをつくるTech Organization Enablement

こんにちは。12月1日にラクスルにTech Organization Enablementという役割で入社した宮本です。

「Tech Organization Enablement」とは?

Tech Organization Enablementという役割は、ラクスルの中で初めて作られたポジションです。私自身初めて耳にする役割であり、何をする人なのかわからない方もいると思いますので、まず最初にその役割について説明させていただきます。

Tech Organization Enablementの役割は、ラクスル事業本部のシステム統括において、組織的な成長・改善を横断的に行う役割です。 組織的な課題を言語化・分析し、組織が成長するために必要な施策を計画・推進することで、開発組織が継続的に成長できる環境・文化を構築することをミッションとしています。

この記事では、これまでの組織マネジメント経験で注力していたこと、私の組織マネジメントスタイルと、今後ラクスルでどのようなことを行っていくのかを、簡潔にお話させていただこうと思います。

略歴

2002年、電気技師として建築現場で電気工事に従事。2006年、SESに転職しエンジニアキャリアをスタート。2010年に楽天グループ株式会社に入社し、エンジニア、スクラムマスター、プロデューサー、チームリードと役割を変えながらプロダクト開発・保守・運用に従事。2015年より、楽天デリバリー、楽天Kドリームスのエンジニアリングマネージャーを歴任。2022年、コミューン株式会社のシニアエンジニアリングマネージャー、開発責任者を歴任し、コミューン事業の開発部門を統括。2023年12月、ラクスル株式会社にTech Organization Enablementとして参画。

私の組織マネジメント経験

私は直近の約8年間で、メガベンチャーとスタートアップという規模感や組織のフェーズが全く違う組織にて、エンジニアリングマネージャー、シニアエンジニアリングマネージャー、開発責任者を経験し、モチベーションが下がっていたり、成長意欲が低迷してしまっていたり、これからどのように組織を成長させていけばいいのかが不透明、といった組織をマネジメントし、自律的に長期目標を設定し成長していける組織づくりを行ってきました。

組織づくりを行ってきたと言っても、私一人が何か施策を考え実行に移すのではなく、チームや組織が潜在的に持っている成長や課題解決への意欲を引き出し、組織の総意として長期目標を設定したり、組織の理想像を言語化することで、自律的に組織が成長できる環境整備や組織の支援を行うことで、関わる人達が一丸となって組織づくりができるような仕組みを作ってきました。

中でも、特にリーダーシップを発揮してほしいエンジニアリングマネージャー、テックリード、チームリーダーといったミドルマネジメント層の方々の内発的動機と組織の長期目標を紐付けることに注力し、自力で組織を成長させることができるよう、育成・サポート・環境整備を行うことで、組織のリーダーシップの面を広げ、組織が継続的に成長していける環境を構築してきました。

組織マネジメントスタイル

組織のリーダーシップの面を広げる、とお話しさせていただきましたが、私がこれまでどのようにしてリーダーシップの面を広げてきたのかお話しさせていただきます。

私は、組織に関わる人達全員の小さなリーダーシップをはぐくむことで自律的な組織を作ってきました。

小さなリーダーシップとは、ポジションに関わらず、組織やプロダクト、プロセスに対し漠然とした課題感や不満に思うことに対して課題を明確に設定し、理想の状態に近づけるよう今の自分にできることを実行する姿勢を指しています。

漠然とした課題感や不満は、各々が考える理想の状態が作れていない、または近づけていないときに出てくることが多いように思います。 理想の状態になるためにはギャップがどこにあるのか?何をすれば理想に近づけるのか?実際に何をやっていきたいのか?という部分に焦点をあてて思考することで、それぞれの立場や状況に応じた課題設定から具体的な行動目標設定が可能になります。

また、自分たちで設定した課題や行動目標に対しては、自分たちで振り返ることができ、現状の評価や方向修正も小さなリーダーシップをもって自分たちで進めていくことができます。

小さなリーダーシップが集まることで、リーダーシップの面は広がり、良い組織の基盤となっていきますし、組織が継続的に成長していける環境を構築するためにはなくてはならない重要な要素の一つだと考えています。

ラクスルでどのようなことを行うのか?

これまで、ラクスル事業本部の開発組織はミドル〜シニアにステップアップしていく仕組みづくりが十分とは言えない状況にありました。エンジニアリングマネージャーや更に上のマネージャーになると、これまでの延長線上で役割を担うことは難しく、役割や責任が大きくなります。そのような変化の際には、十分な学習機会やフィードバック、サポートを行うことが非常に重要だと認識しております。

この状況に対し、ミドル〜シニア層への学習機会やフィードバックやサポートを組織横断的に行い、継続的に成長できる仕組みを整えることが、Tech Organization Enablementである私のまず最初のミッションです。

また、自身の入社後オンボーディングは、エンジニアやエンジニアリングマネージャーだけではなく、プロダクトマネージャーや事業のメンバーとの1on1でした。そこでは、開発組織の課題だけではなく、事業の方向性や、プロダクト開発の進め方など、いろんな視点でインプットさせていただきました。

所感として、プロダクト開発のプロセスに関しても仕組みを変えることでよくなっていくだろうな、と思える部分がありました。組織づくりだけにとどまらず、直接プロジェクトに関わっていくことで課題の解像度を上げ、より洗練されたプロダクト開発プロセスの構築にもチャレンジしていきます。

さいごに

私のこれまでの組織づくりの経験を活かし、組織が確実に拡大・成長していける仕組みを構築し、盤石な組織基盤を作っていけるよう尽力することで、ラクスルに所属するエンジニアメンバーが「ラクスルの開発組織って働きやすくて、チャレンジできて、成長できて、超楽しい!!」と感じ、成長し続けることができる開発組織を作っていきます!