RAKSUL TechBlog

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

ラクスルでのエンジニアリングマネージャー半年を振り返る

こんにちは。ラクスルのプロダクト基盤部のEM兼PdMを担当している安尾(@yusuke_yasuo)です。

2023年8月にラクスルに入社して以来、ラクスルにおける決済基盤の構築を担当しています。 引用:2024年7月期第2四半期 決算説明会資料

EM候補として入社して10月に正式にEMとなり今月で半年になるため、一度振り返りをしてみようと思います。

目指すEM像

振り返る前に私が目指すEM像について簡単に紹介したいと思います。

一言で言うと、こちらの記事で書かれているような「強めのEM」が私が目指すEM像です。

引用:エンジニアリングマネージャ/プロダクトマネージャのための知識体系と読書ガイド

会社によってはピープルマネージメントやテクノロジーマネージメントを行うのがEMというところもあるかもしれませんが、経験上チームとしての成果を最大化するためにはプロダクトマネージメントやプロジェクトマネージメントのスキルが重要になる場面も多いと感じており、その時々でチームの成果を最大化するために最も効果的なレバーを見つけてそれを引くことができるようなEMになれればと考えています。

ちなみに、ラクスルにおける理想のEM像もまさにこの「強めのEM」というイメージで、会社における理想のEM像と私の目指すEM像の一致度はとても高いと感じています。

ラクスルはマイクロサービスで動いており、異なる目的や特性を持ったシステムが存在し、所属エンジニアのスキルセットも当然チームによって様々なので、ラクスルのEMは各チームの状況にあわせてレバレッジが効くスキルを発揮することで成果を上げていると感じています。

半年間を振り返って

一言で言うと、とても充実した半年が過ごせたと思っています。

ちょうど大きなプロジェクトが始まるタイミングに入社した幸運もありますが、決済基盤構築プロジェクトの計画から実行まで、大きな裁量を持ってチャレンジできていることが一番の要因です。

プロジェクトを「なぜやるか」が明確になっている状態で参画し、「何をつくるか」「どうやってつくるか」「どういう体制でつくるか」などについては自分で主体的に考えられる環境だったため、これまで経験したことがないような多くのチャレンジをすることができました。

本記事では、印象に残っているチャレンジについていくつか紹介できればと思います。

基盤システムの要件定義

いま構築しているプロダクトは約10個のECから利用される決済基盤です。

過去にも色々なプロダクトの開発に関わってきましたが、ラクスルほど大規模なプロダクトははじめてで基盤システムの開発と言えば、過去に2つのシステムから利用されるID基盤の開発にエンジニアとして少し関わったことはあったもののほぼはじめての経験でした。

これまでプロダクトマネージメントをする際は、ユーザーインタビューやデータ分析を通してユーザーのニーズやペインを理解することでプロダクトの方向性や仕様を決めていましたが、基盤システムとなるとエンドユーザーだけでなく、基盤システムを利用する社内の各プロダクトへの深い理解が必要になるので勝手が違ってきます。

決済基盤を利用する各ECの決済周りの仕様を把握した上で慎重に仕様を決めないと、これまでできていたことができなくなったり使い勝手が下がりユーザーの離脱につながってしまいます。価値向上のために多くのリソースを投下しているにも関わらずそうなっては本末転倒です。

また決済はしたら終わりではなく、その後キャンセルになることやトラブルによって返金したり、追加請求が発生することもあります。さらには決済された金額と決済代行業者から入金された金額を突合したり、最終的には正しく経理処理が行われる必要があります。

結果的に、各ECの仕様やオペレーション把握のために入社して3ヶ月の間に30名程度の方からヒアリングをさせていただきながら要件を固めていったのですが、これほどステークホルダーが多いシステムの要件定義ははじめてで、考慮すべきことがとても多いのが印象的でした。

ラクスル全体の理想を意識した概要設計

冒頭でも触れましたがラクスルはマイクロサービスで動いており、約10個のECに加え、特定の役割に特化した基盤的なシステムも複数存在します。今回はそこに決済基盤を新たに追加することになるのですが、システム間のAPIの設計を失敗すると密結合・低凝集なマイクロサービスができあがってしまい中長期にわたって大きな負債となり、事業の成長速度の悪化やエンジニアの開発体験の悪化を引き起こす懸念がありました。

とは言っても、私はラクスルに入りたてでしたので、既存システムや事業に関する解像度が浅く、1人で適切な設計をするのは現実的ではありませんでした。

そこで、CTOや社内のシニアエンジニアなど既存システムに詳しい方々の協力を得て、数ヶ月にわたって毎週設計レビュー会を実施させていただきました。最初に決済基盤で実現したいビジョンや要件を共有した上で論点の洗い出しを行い、その後はひとつひとつの論点に対する議論を行いました。

その際に意識したのが、現状からの積み上げで考えるのではなく、できる限り理想からの逆算で設計を行うということでした。現状からの積み上げで考える方が短期的には圧倒的に楽で速いのですが、それでは全体の理想からは遠ざかってしまう可能性があります。遠回りでもまずは目指すべき理想について関係者間で認識をあわせた上で、プロジェクトにかけられる期限や予算を考慮した落とし所を決めるというステップを意識することで、長期で見ると最短距離を進んでいるということを目指しました。

チーム一丸を目指した目標共有会

EMの仕事と言えば、チームメンバーの目標設定や評価をイメージする方も多いのではないでしょうか?ラクスルのEMもそのイメージに違わずチームメンバーの目標設定や評価を行います。

チームにおけるテクノロジーマネージメントやプロダクトマネージメントについては各EMの強みやチームメンバーの構成によって能力発揮の必要性は大きく異なっているように感じますが、ピープルマネージメントについてはもれなく一定レベルの能力発揮が必要とされていると感じます。

私が各チームメンバーの目標を設定して評価までには大まかに以下のようなことを行いました。

  1. 上長や共働するBizメンバーとチームのOKRを決める
  2. チームメンバーのWill(中長期の目指す姿やそのために獲得したい能力)を1on1でヒアリングする
  3. チームのOKR達成のためにやるべきことを分解する
  4. 分解したOKRの担当メンバーを現時点での適性とWillを考慮しながら割り当てる
  5. 4で割り当てた担当について各チームメンバーと1on1をしながら認識合わせをする
  6. チーム全員で目標共有会を開催して、全員が目標を達成するための作戦を立てる
  7. 6で立てた作戦がうまくいっているか月次で全員で振り返りを行い、作戦を調整する
  8. 週次で各チームメンバーと1on1を行い、目標達成への進捗や課題の確認をする
  9. 半期の終わりに振り返って評価を行う

色々とやっていますが、特に6の目標共有会と7の月次の振り返りが効果的だったと感じています。

過去のチームでは、これをやらなかったことで、お互いチャレンジしたいことが被ってしまったり、誰もやらずに放置されてしまうタスクが発生したりというような問題が発生することがあったのですが、これを実施することでチャレンジが被りそうな部分や放置されそうなタスクについて事前に調整を行うことができました。それ以外にも一人ひとりの目標達成に向けて他のメンバーにはどのような協力ができるかということも論点として議論をすることで、全員が自分の目標達成だけでなくチーム全員の目標達成を意識して一丸となって業務に取り組むことができていたと感じます。

今後のチャレンジ

今後チャレンジしたいことはたくさんあるのですが、1つだけピックアップしたいと思います。

ベトナムの開発チームとのコラボレーション強化

私のチームはこれまで日本語での会話や読み書きが可能なメンバーのみで開発を行っていました。今後さらに開発速度を上げたり、多くのことにチャレンジしていくには国内のエンジニアだけでは難しい状況のため、近々ベトナムの開発チームと共に開発していくことが決まっています。

ただ、これまで日本語を前提とした開発プロセスやドキュメンテーションを行っていたためベトナムメンバーが持っている能力を発揮できるようになるためには様々な改善が必要になることは明らかです。

私をはじめ、今いるチームメンバーは英語でのリアルタイムのコミュニケーションは難しいため、スクラムイベントを透明性を持って開催するにはどうすれば良いかというのも大きな課題です。

これらはぶつかるであろう課題のほんの一部で実際やってみるともっと色々と躓くのだと思います。一朝一夕で解決できない課題も多いため、目指す姿を明らかにしつつ時間をかけて一歩一歩根気強く取り組んでいくしかないと考えています。

ハードルは決して低くないですが、実現できた後の姿を想像するとワクワクするため、実現に向けて頑張っていきたいと思います!

最後に

今回は私がラクスルのEMになってからの半年を振り返ってみました。

ラクスルには良い意味で多くの取り組むべき課題があり、Willがあれば様々な機会提供が受けることができると強く感じています。

今後も定期的に振り返りをしつつ、初心を忘れずにチャレンジを続けていきたいと思います。

シェル起動時に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の活用など、さらなる技術の導入も考えています。これらの取り組みを通じて、より効率的な企業運営を実現し、社員の皆さんがさらに働きやすくなるように貢献していきます。