見出し画像

通勤費管理SaaSの開発で得た気付き

🎄この記事はNAVITIME JAPAN Advent Calendar 2023の1日目の記事です。



こんにちは、ミルクレープです。
ナビタイムジャパンのソリューション事業部で法人向けサービスの開発を担当しています。

私は新卒でエンジニアとして入社し、今年で3年目を迎えました。
今年の4月から新たに『通勤費管理クラウド』の開発を担当しています。
以前は同じ事業の別サービスの開発に従事しており、SaaSの開発は今回が初めての経験です。

今回の記事では、『通勤費管理クラウド』の開発を通して得られた気付きや学びについてお話しします。


『通勤費管理クラウド』は、2023年2月に提供を開始した法人向けの通勤費管理SaaSです。
従業員の通勤費管理の他に、運賃改定に伴う差額の確認や通勤費の一括更新機能があります。2023年12月現在では、鉄道とバスの通勤費に対応しています。

以前、新機能についてご紹介した記事がありますので、ご興味ある方はこちらもぜひご覧ください!

気付いたこと

仕様検討は重要で難しい

仕様をもとにサービスの中身が形作られていくので、とても当たり前に聞こえるかもしれませんが、これが一番最初に頭に浮かびました。

「通勤手当」というものは法律上支給の義務は無く、法律で定められた支給ルールもありません。ただし、通勤手当の非課税限度額は法律で定められています。(※)
通勤手当の支給ルールは、ベースとなるルールがないため、自由度が高いという特性があります。つまり、各社が独自に支給ルールを定義しその内容は様々です。
例えば、下のような支給ルールの例です。

支給ルールの例

※電車・バス通勤者の通勤手当(国税庁)

このような背景から『通勤費管理クラウド』ではお客様からヒヤリングした内容や要望をもとに機能追加や改善のアイデアを得ることが多いです。そして、お客様から得られた情報をもとにどのアイデアを採用するかについて検討を行っています。

私は、お客様からいただいたアイデアから仕様に落とし込むときに主に以下の3点を考慮しています。

1.その仕様は対象ユーザーが限定されるなど、特殊なケースにあてはまらないか
特殊な機能を追加した際に、そもそも使ってもらえる可能性が低いことに加え、その機能を使う必要の無い人にとっては、サービスを触った際に違和感を感じる可能性もあるため重要な観点だと思っています。
ただし、とても判断が難しいです。
世の中に存在するすべての通勤費の支給ルールを知ることができれば、全体像を把握できるかもしれませんが、実現は難しいでしょう。
開発の現場では、アイデアから実際に機能として入れる場合を想定し、懸念点や影響範囲などの情報を整理し、その内容をもとにサービス関係者で協議しながら慎重に判断しています。

2.その機能を入れることで、ユーザーが得られるメリットは何か
観点が偏らないように想定ユーザー(想定利用シーン)を複数決めて、それぞれのメリットを考えるようにしています。もしある場合はデメリットも挙げるようにして比較を行います。

3.技術的な観点で懸念点や実現可能か否か
PJメンバーで技術的な懸念点を整理し、すり合わせを行っています。さらに、こちらは2と合わせて対応する際の優先度にも関わってきます。

ユーザーにとって負担にならないUIを追求する

私が特に思う負担にならないUIというのは、

  • ユーザーが目的を達成するために操作を迷わない

  • 使う頻度が高いページはすぐたどり着ける場所にある

だと思っています。

例えば、メニューの項目(常時画面に表示されている部分)を追加するときは使用頻度が高い機能はメニューの項目に追加しますが、そこまで頻度が高くないものは導線をどこに置くかの検討が必要です。
現状の『通勤費管理クラウド』の管理者メニューは画像の通りですが、管理者が使う頻度が高いであろう機能がメニュー項目に含まれています。

管理者メニュー

一方で、管理者が使う頻度があまり高くないであろう機能は管理者メニューから直にたどりつける導線を設けていません。
例えば、この2つです。

  1. 通勤費のシミュレーション機能
    利用想定シーン:通勤費の最適化や出社日数の見直し

  2. 通勤規程の設定画面
    利用想定シーン:通勤規程の登録 および 編集

1、2 ともに各社が定める通勤費の支給ルールの内容に関わる部分です。支給ルールは就業規則等で定められているケースが多く、短期間で変更するものではありません。したがって、使う頻度はあまり高くないだろうという判断に至りました。

開発者発信の改善点探しに能動的になる

既述の通り、要望やお客様からヒヤリングした内容をアイデアに機能アップデートをすることが多いわけですが、開発者が自分で気付いて改善をしていくことも忘れてはいけないと思っています。

以前、展示会に説明員として参加した際に、来場してくださった方から仕様の質問を受けたのですが、それはサービス画面の表記からは判断がつかない内容の質問でした。

サービス内部に詳しい開発者にとっては当たり前の認識でもサービスに初めて触れる人にとっては分からないことがあります。
ちょっとした細かい表記にも気を配り、「ユーザーがスムーズに使えるように改善できることはないか」という点にアンテナを張っておこうと思うきっかけとなりましたし、今後もその意識は継続していきたいと思っています。

おわりに

『通勤費管理クラウド』の担当になり、数ヶ月が経ちました。この記事で挙げたこと以外でも気付きがたくさんあり、日々学びの連続です。
今後も引き続き多くのお客様に使って良かったと思ってもらえるようなサービス開発に取り組んでまいります。
最後まで読んでいただきありがとうございました。