こんにちは、プロダクトエンジニアのutakahaです。
2025年6月末までプラットフォーム開発ユニットというチームに所属し、SmartHR Plusの開発やSmartHR APIの改修を担当していました。
本稿では、SmartHRのプロダクト群の中でも少し特殊な立ち位置にあるSmartHR Plusというプロダクトについてご紹介し、開発をしていく中でどのような課題と向き合い、そして改善してきたのかをお話しします。
SmartHR Plus
まず、SmartHR Plusについて簡単に説明します。
SmartHR Plusは、SmartHRをより便利に活用するためのアプリを掲載しているアプリストアです。
SmartHR Plusでは、SmartHRの外部パートナーが開発した連携アプリを掲載し、ユーザーがそれらのアプリを利用できるようにしています。
SmartHR単体では実現しきれない課題解決や機能拡張を可能にする一つの手段としてアプリストアを提供しています。
詳しくはSmartHR Plus についてをご覧ください。
以降では、私たちが直面した3つの課題と、それらをどのように解決したかを説明していきます。
- プロダクトマネージャー不在による課題と解決策
- 専任プロダクトデザイナー不在の課題と解決策
- ビックバンリリースの課題と解決策
プロダクトマネージャー不在による課題と解決策
SmartHR Plusは、アプリストアを利用するユーザーだけでなく、アプリを掲載するパートナーにも価値を届ける必要があります。
パートナーにとっても掲載価値のあるプロダクトとするため、実装する機能は双方の視点で価値を見極めて検討する必要がありました。
ですが、SmartHR Plusを開発するプラットフォーム開発ユニットには専任のプロダクトマネージャーがおらず、プロダクトエンジニアがその役割も兼務していました。
具体的には、プロダクトエンジニアがビジネス側と密にコミュニケーションを取ってユーザーやパートナーの課題を整理して仕様を策定し、実装まで一貫して担っていました。
また、必要に応じてプロダクトエンジニアがパートナーとの打ち合わせに同席し、連携仕様について直接議論することもありました。
一定の成果はあったものの、複数の課題が徐々に顕在化してきました。
その中でも最も大きな課題は、ヒアリングや仕様検討に時間を要することによる開発着手の遅れとリリース速度の低下でした。
この課題に対して、開発前の仕様検討を必要最小限にとどめる方針を取りました。
最低限必要な機能の仕様と、後から変更が困難になるインターフェースやデータ設計のみを事前に確定し、早期に開発へ着手しています。
そのうえで、リリース後もインクリメンタルに改修を重ねることで、解像度が高い状態でプロダクトの課題に対応できるようになりました。
具体例として、パートナー向けのアプリ入稿システムの申請機能の開発は、当初は申請をリジェクトする機能も初回リリースに含める予定でした。
しかし、リジェクト前後の運用フローが不明瞭であり、また実務上はリジェクトするよりもメール等で修正点を伝えて対応いただくケースが多かったため、初回リリースからは除外しました。
リジェクト機能は今後、課題が明確になったときに具体的なユースケースと業務フローを整理した上で実装する予定です。
リソースが限られる中、価値の高いアイテムに集中し、ユーザーやパートナーの反応を見て次の手を打つことで、最小限のリソースで解像度を高めながら改善できるようになりました。
専任プロダクトデザイナー不在の課題と解決策
SmartHR Plusは専任のプロダクトデザイナーが不在で、機能の追加や修正の際は、都度お手伝いしていただいてるプロダクトデザイナーに相談していました。
小規模な改善は開発チームでデザインを検討し、プロダクトデザイナーのレビューで対応していましたが、大規模な新機能の開発ではこの運用に限界を感じていました。
この課題に対して、ニュービジネスマーケティング部所属のディレクターとデザイナーに専任で入ってもらう体制を構築しました。
ニュービジネスマーケティング部はディレクター、マーケター、デザイナーの混成チームで、主に新規事業におけるマーケティングとコミュニケーションデザイン領域を担当している部署です。
なお、本稿において「デザイナー」は、マーケティング/コミュニケーション領域のクリエイティブ制作・アートディレクション、ブランド観点のコミュニケーション設計の品質担保を担う役割を指し、「プロダクトデザイナー」は、ユーザー課題の達成を目的に、要件定義とUI設計、デザインシステム/ガイドラインの構築・運用を行い、プロダクトのインターフェース品質を担保する役割を指します。
SmartHR Plusは、業務ツールではなくアプリストアです。ユーザーはカタログのような使い心地でアプリを比較・検討するため、他のSmartHRのプロダクトとは性質が異なります。
求められるUI/UXもメディアサイトに近いものでした。
そのため、アプリストアというドメインではコミュニケーションデザインの知見が活きると判断し、事業部としてニュービジネスマーケティング部と連携して開発する意思決定を行いました。
現在は、一緒に開発を進めているデザイナーに仕様を含めたデザインをリードしてもらい、ディレクターにコミュニケーションデザインの視点で機能やサービスの全体像を設計してもらっています。
これにより、仕様を決めていく初期段階からディレクターとデザイナーと共に議論して開発するようになり、プロダクトとしての完成度や一貫性が高まりました。
ビックバンリリースの課題と解決策
新機能が大規模になると開発が長期化し、ビッグバンリリースになりがちで、デプロイ時の負担も増大していました。
この課題の解決に向けて、以下の改善に段階的に取り組みました。
リリース作業の改善
従来はSlackのワークフローでデプロイしていましたが、git-pr-release を導入しました。
これによりPull Requestをマージするだけでリリースできるようになり、さらにPull Requestのdescriptionも自動で更新されるため、リリース担当者の負担が大幅に軽減されました。
リリース後の確認作業の最適化
SmartHR Plusのコア機能を現在の仕様に合わせて再定義し、リリース後に確認すべき項目を整理しました。
また、end-to-endテストが不足していた箇所に正常系のテストを追加し、自動テストが通れば安心してリリースできる体制を構築しました。
Pull Requestテンプレートの改善
Pull Requestのテンプレートにいくつか形骸化していた項目があったため、従来8項目の記入が必要だった内容をRailsのpull_request_template.mdを参考に必要最小限へ絞り込みました。
直接リリースの課題に関わる問題ではないものの、この対応でPull Requestを作る負荷が下がり、変更がしやすくなりました。
現在は以下の5項目を記入しています。
- 関連リンク
- チケットやDesign Docのリンク
- 概要 / 背景
- なぜこの変更を行う必要があるのか
- 詳細
- 補足情報
- 代替案はあったのか、なぜこの変更方法を選択したのか
- パフォーマンスの測定結果など
- 確認方法
- どうすればこの変更の動作確認ができるか
以上の改善により、リリース頻度を段階的に高めていき、最終的にはほぼ毎日デプロイする運用になりました。
最後に
本記事では、プラットフォーム開発ユニットが直面した課題とその解決策を紹介しました。
SmartHR Plusは、SmartHRの他のプロダクトとは異なる性質を持っており、その特性に合った開発体制や専門性が求められます。
現在では、SmartHR Plusをグロースさせるための専任メンバーが集まるユニットが立ち上がり、より効果的な開発・運営が進んでいます。
We Are Hiring!
SmartHRでは、SmartHR Plusをはじめとする多様なプロダクトに関わる仲間を募集しています！
少しでも興味を持っていただけたら、カジュアル面談でざっくばらんにお話ししましょう！
Source link
コメント