こんにちは。プロダクトマネージャーのふとしです。
この記事は「SmartHRのプロダクトマネージャー全員でブログ書く2024」への参加記事です。25人が持ち回りで毎週記事を投稿します。ぜひご覧ください！
この記事では、私が担当していた部署不定問題というプロジェクトの歴史と、その先にあるものについて話そうと思います。SmartHRでは大きなことをするために、まだまだ地道な開発も必要なフェーズで、その一部を知ってもらえたらと思います。
はじめに・前提
まず部署不定問題について説明します。
SmartHRの従業員データには部署情報を3つまで登録できるのですが、内部的に順序が固定されない仕様になっていました。 それにより色々な課題が発生していたのですが、課題の一例としては部署が前詰めされてしまうというものがありました。
例えば以下の図のような従業員がいたときに、部署2のCSを消してしまうと自動的に部署3のバックオフィスが繰り上がり、部署2がバックオフィスになってしまうという仕様になっていました。
部署が前詰めされてしまうと、参照している部署や役職が変わってしまい、権限やその他アプリなどに影響を及ぼす可能性があるため、部署不定問題を解決する必要がありました。
その他にも色々な課題があり、総称して部署不定問題と社内で呼んでいました。
このプロジェクトが始まったのは2021年3月22日で、完全に解消されたのが2023年の8月23日となっており、約2年半も時間を費やすことになるとはこの時点では誰も思っていませんでした。
最終的な目的は申請の承認経路の拡充
部署不定問題の目的は上述したような課題を解決することも大事ですが、他にも大きな目的があり、それは申請の承認経路の拡充のためです。
SmartHRに昔から多く寄せられる課題の1つに兼務先の役職で承認したいという課題があります。 イメージとしては部署1と部署2の部長を兼務しているとき、部署2のメンバーからの申請は部署2の部長として承認したいなどです。
この課題を解決するためには3つのステップが必要です。
- 従業員情報の部署と役職を紐づけられるようにする
- 役職を部署ごとに登録できるようにする
- 兼務先の役職で承認できるよう申請の改修をする
このブログが出た今日（2024/02/29）もまだ解決できていないのですが、この課題に取り組む前の大きな障壁となっていたのが、部署不定問題でした。
部署が前詰めされてしまったりすると、参照している部署や役職が変わってしまい、権限やその他アプリなどに影響を及ぼす可能性があるため、まずは部署不定問題を解決する必要がありました。
そういう意味では4ステップ必要だったと言えます。
日々増えるプロダクトやお客様への対応
プロジェクトが始まった2021年3月22日に比べると、現在のSmartHRのプロダクトはかなり増えています。 当初はやりとりしていたプロダクトの数は10もないくらいだったのですが、リリースするころには20近くに増えていました。
日々増えるプロダクトに対しても部署不定問題のための対応をしてもらう必要があり、新しく入ったPdE（プロダクトエンジニア）への説明など、リリース前はかなり頻繁なリマインドや調整をしていました。 この辺りの調整は私ではなく、ほぼほぼPdE同士でのやり取りで進んでいたのはとてもありがたい限りです。
またSmartHR内だけでなく、APIを使っているお客様もいますので、早めのお知らせやサンドボックス環境の用意などを経て、懸念点の払拭や検証も進めていました。サンドボックスの環境に関してはリリースの1年以上前から提供をしていました。（リリース日が伸びに伸びたというのもありますが。）
下記の画像は進捗確認に使っていたスプレッドシートになります。
絶対に失敗できないコンバート
部署不定問題は名前の通り部署にまつわる改修です。 従業員情報の中でもトップクラスに重要な情報である部署を、構造が変わったから今までのデータを捨てて新しく作ってもらおう！なんて決断はできません。
部署の構造や履歴、さらに他のプロダクトにも影響を起こさずに昔の構造から新しい構造にデータをコンバートする必要がありました。 部署不定問題では特にこのコンバートの設計、実装、修正に時間がとてもかかっていて、なんと1年近くかかっています。
理由としては、そもそも関係する箇所が多い上に、作っている途中で新しいプロダクトや機能が生まれるのでそれへの追従が必要だったためです。 叩いても叩いても永遠に終わらないように思える改修を、本当によくやりきったなと自分のチームのPdEたちをとても誇らしく思っています。面構えが違います。
このあたりのコンバートの大変さなどは、担当したPdEが書いたブログがありますので是非ご参照ください。 難解！ SmartHRの部署のデータ構造とBiTemporal Data Modelが組み合わさると...
リリース後、大きな障害やお問い合わせは無い
とても丁寧に慎重に実装やテストもしましたが、チームとしては内心とてもビクビクしながらリリースしました。 部署データを利用している機能は基本機能の中だけでも数百箇所以上あるので、何かしら問題が起きてしまうんじゃないかと思っていたのです。
しかしリリースから半年ほど経った現在でも、大きな障害やお問い合わせは起きていません。 胸をホッと撫で下ろしていますし、チーム内では未だに部署不定問題をやり切ったという話でたまに盛り上がります。
いよいよ承認経路の拡充へ
既にお知らせも出ていますが、いよいよ最終的な目的である兼務先の役職で申請を承認できるようにする機能の開発に着手しています。
世の中に存在するワークフローとしては割と当たり前な承認経路ではあるのですが、部署不定問題を乗り越え、今やっとやりたかったことに向き合えています。
まとめ
この記事では部署不定問題〜承認経路の拡充という開発の流れの歴史について紹介しました。 SmartHRの開発は華々しいことばかりではなく、まだまだ地道な開発も必要なフェーズで、その一部を知ってもらえたら幸いです。
時間や労力が多くかかるような開発は、他の課題と比べると議論したりロードマップにのせる意思決定は難しいのですが、長い目で考えて大変だと思うようなことに今後も挑戦していきたいです。
私たちはプロダクトマネージャーを募集しています！
SmartHRでは引き続きPMの採用に注力しています。PM職に関する情報をまとめた記事がありますので、ぜひご一読ください。カジュアル面談のリンクなどもこちらに掲載しております。
