RAKSUL TechBlog

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

シェル起動時にGitHub CLIでPATを生成して開発を効率化!

こんにちは!ラクスル事業本部でエンジニアをやっています、灰原です!

皆さんは普段の開発でGitHubのPersonal Access Token (PAT) を使うことはありますか? ラクスルではいくつかの社内パッケージをGitHub Packagesで管理しており、それらのインストールのためにPATが使われています。 例えばRubyのgemであればbundle configコマンドでPATを指定したり、npmパッケージであれば.npmrcファイルにPATを書いたりします。この対応自体はGitHub Packagesのドキュメントにも書かれているものですが、言わずもがなPATの扱いには注意が必要です。不必要な権限 (scope) を付与しない、有効期限を設定するなど基本的な対策を取るべきでしょう。

しかしPATの有効期限が切れるたびに、GitHubの画面から適切なscopeと有効期限を指定したPATを再生成して、bundlerやnpmなどそれぞれの設定をやり直すという、この一連の作業はそれなりに面倒なものです。

この記事では、そんな面倒な作業をGitHub CLIとちょっとしたスクリプトで効率化する方法について紹介します。

GitHub CLIでPATを取得

まずはPATの作成作業の効率化です。これには GitHub CLI を使います。コマンドラインからプルリクエストを作ったりラベルを付けたりできて便利なGitHub CLIですが、実はGitHubのPATを取得することもできます。

まずは gh auth login コマンドで認証情報を獲得します。これを実行するとワンタイムパスワードが表示され、それをブラウザで開いたGitHubの画面に入力すると、認証が完了します。その後、gh auth token コマンドを実行すると、先の認証時に取得したPATが表示されます。

$ gh auth login # ログイン
$ gh auth token # PAT取得

gh auth token で取得したPATを使って、curlでGitHub APIにアクセスしてみます。

$ curl --request GET \
       --url "https://api.github.com/octocat" \
       --header "Authorization: Bearer $(gh auth token)"

curlでGitHub APIにアクセスする

無事にOctocatが表示されました。

(上記の例では検証のためにcurlを使っていますが、GitHub CLIにはGitHub APIにアクセスする機能があります。)

追加のscopeを設定する

ところでGitHubのPATはscopeが設定されています。 gh auth statusコマンドを使えば、GitHub CLIが提供するPATのscopeを確認することができます。 単にgh auth loginした後の状態のscopeは、admin:public_key / gist / read:org / repo となっていました。

gh auth status

しかしGitHub Packagesからパッケージをインストールする際には、read:packages scopeが必要です。 このような追加のscopeを設定するには、gh auth login コマンドの -s ( --scopes ) オプションを使います。

例えば下記のように、read:packages scopeを追加で要求することができます。

$ gh auth login -s 'read:packages' 

gh auth status コマンドで確認してみると、確かに read:packages scopeが追加されていることがわかります。

gh auth status (read:packages scope付きでログインした後)

これでGitHub Packagesも扱えるようになりました。

envsubstで設定ファイルにPATを埋め込む

envsubstというコマンドを使うと、テンプレートエンジンのように環境変数をテキストに埋め込むことができます。

In normal operation mode, standard input is copied to standard output, with references to environment variables of the form $VARIABLE or ${VARIABLE} being replaced with the corresponding values.

envsubst Invocation (GNU gettext utilities)

これを使うと、gh auth tokenで生成したPATを簡単に設定ファイルに埋め込むことができます。 例えば、.npmrc.templateとして以下のようなファイルを用意しておきます。

@NAMESPACE:registry=https://npm.pkg.github.com
//npm.pkg.github.com/:_authToken=${GH_TOKEN}

そのうえで、次のワンライナーを実行すると、PATを含んだ .npmrc ファイルが生成されます。

$ cat .npmrc.template | GH_TOKEN=$(gh auth token) envsubst > .npmrc

このようなテンプレートファイルと、envsubstを実行するMakefileなどをレポジトリごとに用意するのも1つのアプローチでしょう。

シェル起動時にまとめて設定する

もう1つのアプローチとして、bundlerの設定したり、ホームディレクトリ直下に.npmrcを置いたりするシェルスクリプトを作り、それをシェル起動時に読み込ませる方法もあります。

例えば以下のようのシェルスクリプトです。

#!/bin/bash

set -eu

function login() {
    if gh auth status; [ $? -ne 0 ] ; then
        gh auth login -s 'read:packages'
    fi
}

function substitute() {
    token=$1
    template=$2
    file=$(echo ${template} | sed -e "s/\.template$//")

    cat ${template} | GH_TOKEN=${token} envsubst > ${file}
    echo substitute: ${file}
}

function main() {
    login
    token=$(gh auth token)

    # bundle
    bundle config --global https://rubygems.pkg.github.com/raksul w-haibara:$(gh auth token) 

    # npm
    substitute ${token} ~/.npmrc.template
}

main

おわりに

GitHub CLIを使ってPATを生成し、それを各種設定ファイルに埋め込む方法を紹介しました。 小さなところから日常の手間を減らしていきたいものですね。

ノバセルでデータエンジニアへのジョブチェンジをした話

こんにちは。ノバセルのデータプロダクトチームでデータエンジニアとして働いている森田です。 現在は業務として Snowflake や dbt を用いたデータ基盤周辺システムの開発や運用に携わっています。

ノバセル以前の会社ではバックエンドエンジニアとしてソフトウェア開発に携わっていましたが、転職を機にデータエンジニアへジョブチェンジをしました。 入社してから6ヶ月間ノバセルでデータエンジニアとして働いてみて、一般的なソフトウェアエンジニアとの違いなどいろいろな気づきがありましたので紹介します。 データエンジニアに興味がある方にとってなにか参考になるものがあれば幸いです。

データエンジニアのきっかけ

データエンジニア以前は普通のソフトウェアエンジニアとして、Webサービスやモバイルアプリの開発などに携わっていました。 当時はデータエンジニアという職種を意識したことはなく、ご縁があってノバセルの選考を受けさせていただいたときにデータエンジニアとして選考を受けてみないかという話をいただいたことが最初のきっかけです。

ただ、今振り返ってみると前職でデータエンジニアに近いことをしていました。

アプリケーション開発として、Scala を用いてデータを保存・加工し、検索エンジンに Feed していくバッチ処理システムや、 Apache Flink と Amazon EMR を用いてストリーミングデータ処理を開発していました。 その一方で、BIツールの Redash を使ってデータ分析を行いビジネスサイドの方と議論したりといった活動も行っていました。

こういった業務内容がデータエンジニアとしてのキャリアチェンジにつながったのだと思います。

データエンジニアとして働いてみて

実際にノバセルのデータエンジニアとして働いてみて従来のソフトウェアエンジニアリングと違いや新鮮さを感じた点がいくつかありました。 大きくわけて以下の 3 つです。

  • Modern Data Stack
  • メンタルモデル
  • エンジニアリング以外

Modern Data Stack

データエンジニアとして働いてまず驚いたのが、Modern Data Stack とよばれるデータ活用・管理のためのサービス・ツール群です。

以下の記事でカオスマップが紹介されてますが、データエンジニアリングのさまざまなカテゴリーで活用できるツールや SaaS が大量にあります。 lakefs.io

正直、最初はどれ使ったら良いかわからずかなり混乱しました。 しかし裏を返せば、発展していることの証明であり非常にホットな領域だと改めて実感します。

ツール選定の機会が非常に多くなったため、調査 => 意思決定の精度の重要さを日々感じています。 以下の記事でも紹介されていますが、ノバセルでは ADR (Architecture Decision Record) を用いた運用を通してその精度を上げる取り組みも行っています。 techblog.raksul.com

個人的に技術選定について以下のスライドがとても好きなのでこちらも貼っておきます。

技術選定の審美眼(2023年版) / Understanding the Spiral of Technologies 2023 edition - Speaker Deck

メンタルモデル

ソフトウェアを開発しているとプログラミングという行為を通してアプリケーションが実現したい、もっというとユーザーが望んでいる振る舞いを開発するのがメイン業務になります。データは振る舞いにより得られる副産物といったメンタルモデルでした。

しかし、データエンジニアリング領域ではデータが主でありかつ、データがプロダクトであるといった考えが浸透していると感じました。 ロジックはデータを加工するためにあり、データはプロダクトなので信頼性を確認するためにテストの実施も行うといったメンタルモデルです。

もちろんデータとソフトウェアは切り離せるものでないですが、メンタルモデルとしてデータ側に重心をおいた考えに自然となりました。

ノバセルではまさにデータがプロダクトとなる事業を行っているため、こういった組織の中でデータエンジニアというポジションでデータに向き合うことは重要であり、とても面白いと感じています。

エンジニアリング以外

データをどう活用するかという点について、エンジニアリング以外の知識も非常に重要だと感じています。

データエンジニアについて調べている中で出会ったのが、DMBOK というデータを資産として活用するために必要なナレッジが集まっている書籍です。

DMBOK : データマネジメント知識体系ガイド | Metafindコンサルティング

データを扱うということが、それ自体学ぶべき内容がある重要なテーマという点が面白いなと思いました。

社内 Slack でも DMBOK という単語がちらほら見受けられ、以前は輪読会も開かれていたようです。自分も一部しか読めてないので読んでいこうと思っています。

ソフトウェアエンジニアが貢献できること

データエンジニアリングはソフトウェアエンジニアリングと異なる点もありますが共通点も多くあります。

まず、ソースコードの読み書きはデータエンジニアリングでも変わらず重要なことです。 とくに dbt などを触っているとその周辺ツールに触れる機会が多く、それらは主に Python で書かれていること多いため Python に精通しているとこれらの周辺コードが何をしているかという点を深く理解できます。

直近だと、data-diff というテーブル間のデータ比較をするデータ品質のためのツールのソースコードを精読する機会がありました。

GitHub - datafold/data-diff: Compare tables within or across databases

また、データエンジニアリング領域でソフトウェアエンジニアリングから移植されてきた概念が多くあります。

例えば以下のような分野です。

  • Data Observability
  • DataOps
  • Data Mesh

これらの分野は、それぞれデータ領域で課題となることに対してソフトウェアエンジニアリングの領域から移植されているものです。

Data Observability は Observability、DataOps は DevOps、Data Mesh は Microservices や Platform Engineering 周りから影響を受けているものという認識です。

これらはまだまだ日本語の書籍がすくないですが色々と書籍がでていて、まさにいま Hot なトピックということが感じられます。

これらのような歴史的にソフトウェアエンジニアリングが解決してきた問題をデータエンジニアリング領域にも適用させる試みは規模の大きさはあれど無数にあると思っています。 これらの点で、ソフトウェアエンジニアとしての経験を活かして貢献していくことができると信じています。

さいごに

ソフトウェアエンジニアリングからデータエンジニアにジョブチェンジしてみた際の気づき等を書きました。 幸いにもノバセルにはデータエンジニアリング領域にとても明るい方が多数在籍しているため、ここでデータエンジニアに入門できたのは非常に幸運でした。

データエンジニアリング領域にはまだまだ学ぶべきことが大量にありますが、データ周辺のエンジニアリング全般を行うために色々なスキルを磨いていこうと思います。

この記事がデータエンジニアへの挑戦を考えている方の一助になっていれば幸いです。

ノバセルにおいて意思決定ドキュメントの運用を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で行っていますが、今回のように他の言語も採用しています。
特定の技術に縛られることなく、ユーザーの課題解決に貢献できる手段を積極的に採用するようにしています。
また社内で利用されているシステムであるため、改善した際には直接ユーザーからの喜びの声を聞くことができるのもやりがいに感じています。