はじめに
はじめまして、jinjer のプロダクトマネージャー（PdM）の田村です。
jinjer のプロダクト開発組織における PdM の役割は 別の記事 でご紹介したとおりですが、その中でも、私は、前職までのエンジニアとしてのバックグラウンドやシステム開発の経験を活かして、2023年5月の jinjer への入社以降、ジンジャーAPIをはじめとする技術色の強いプロダクトや工程に携わっています。
本記事では、私が PdM として主に担当している ジンジャーAPI に関して、その概要をご紹介するとともに、開発における苦労や課題を通じて、PdM として果たすべき役割・実現すべきことを考察してみたいと思います。
ジンジャーAPIとは
ジンジャーAPIの位置付け
ジンジャーAPIとは、ジンジャーが提供する公開 API であり、統合型データベース（Core HRデータベース）であるジンジャーで扱うさまざまなデータを外部から操作するための RESTful API のエンドポイント群です。
統合型データベースであるジンジャーは、人事労務や勤怠管理、給与計算、ワークフロー、社保手続きなど、HR 領域におけるさまざまな業務を実現するためのアプリケーションを自ら提供しており、それらのアプリケーションが扱うデータはすべてつながっているため、API 等を介した連携は必要ありません。
しかし、一般的に企業において導入・運用される業務システムは HR 領域に留まらず、たとえば販売管理や生産管理といった業務システムも併せて運用されることが想定され、このとき課題となるのが「システム間で従業員情報（ユーザー情報）をどのように連携・同期するか」です。
このような課題に対して、ジンジャーAPIを活用することで、ジンジャーを従業員情報のマスタとして、以下のような連携・同期を図ることができます。
- ジンジャー以外の各システムがジンジャーの従業員情報を GET する
- ジンジャー以外の各システムがジンジャーで発生した業務データ（例. 勤務データ、給与データ）を GET する
- ジンジャー以外の各システムで従業員情報の新規登録や更新が発生する場合、その情報をジンジャーに POST や PATCH する
ジンジャーAPIでできること
上述の通り、ジンジャーAPIを利用することで、従業員情報を含む人事情報の発生源としてのジンジャー、つまり「HR Data Hub」を最大限に活用することができます。
たとえば、ジンジャーでは、変更申請等のワークフローの申請〜承認のプロセスを通じて、品質（鮮度・精度）の高い従業員情報を保持することが可能です。この情報をジンジャー以外の各システムが GET して反映する仕組みを構築できれば、各システムごとに手作業で従業員情報（ユーザー情報）をメンテナンスする必要がなくなり、またそれに伴って「新入社員のユーザー情報がまだない」「退職者のユーザー情報がまだ残っている」といった各システムにおけるデータの品質の問題を回避することができます。
一方で、ジンジャーAPIはまだ発展途上であり、ジンジャーが扱うすべてのデータに対するエンドポイントを提供できているわけではありません。「HR Data Hub」としてのジンジャーの活用をさらに加速させるために、今後さらなるエンドポイントの拡充を目指していく予定です。
ジンジャーAPIの開発における苦労
このように、ジンジャーの標榜する「Core HRデータベース」や「HR Data Hub」の世界観においても非常に重要な意味を持つジンジャーAPIですが、その開発には今日までに多くの苦労があり、またそれらの多くは一朝一夕に解消できるものではなく、今後も継続的に付き合っていく必要があります。
ここでは、私が PdM としてジンジャーAPIに携わる上で苦労した点をご紹介し、特に統合型のデータベース/業務システムに公開 API を実装する際に備えるべき事や考慮すべき点として、一般化された教訓としてご参考にしていただくことを目指します。
1. UI と API の単位を揃えようとすると無理が生じる
一般的に RESTful API を設計する際、原則としてエンドポイントと主たるリソースは 1:1 の関係であるべきだと私は理解しています。
一方で、ジンジャーAPIは、すでに存在するジンジャーというアプリケーション群を前提に、後から新たに API を提供する試みであるため、自然と UI の単位に引っ張られたエンドポイント設計（たとえば1画面が1エンドポイントに対応）になりがちでした。
しかし、統合型データベースであるジンジャーは、1画面が複数のプロダクトやデータを処理している場合も多々あり、画面（UIの単位）とリソースは必ずしも1:1ではなく、画面毎に対応したエンドポイントを作ろうとすると必ず何らかの矛盾や無理が生じます。
正直に申しますと、すでに公開済のジンジャーAPIのエンドポイントのうち、この観点において個人的にあまり出来が良くないと悔やんでいるものもいくつかあり、それらについては、今後のバージョンアップでよりユーザビリティが高いエンドポイントに置き換えていきたいと考えています。
2. 横断的に複数のプロダクトの理解が求められる
ジンジャーAPIを開発することは、ジンジャーが扱うデータのライフサイクルを知ることであり、少なくともリソースとして扱おうとするデータが、どのように発生し、どのように管理され、どのように利用されるかを理解することが求められます。
ジンジャーは、人事労務や勤怠管理、給与計算、ワークフロー、経費精算など、さまざまなプロダクトを提供しているため、それらが扱うデータも多岐に渡ります。それらのデータ、データ間の関係、及びその業務要件を、すべてではないにしても十分に把握する必要があること自体が、ジンジャーAPIの PdM を務める上でのまず最初の障壁でした。
幸い、私は、過去に経費精算 SaaS の開発に携わった経験があったため、一般的なバックオフィス系のシステムにおける従業員情報等の取り扱いの最低限の理解はあったと言えます。このような理解は、単にシステム開発の経験があったということ以上に、ジンジャーAPIの開発に私自身が比較的スムーズに入れた一因であったのではないかと考えます。
3. 各プロダクトの開発スピードに追随することが求められる
繰り返しになりますが、ジンジャーは、人事労務や勤怠管理、給与計算、ワークフロー、経費精算など、さまざまなプロダクトを提供しており、それぞれの開発チームが専属で機能開発をおこなっています。
ジンジャーAPIは、各プロダクトの仕様に準じ、またそのデータベースをリソースとするため、各プロダクトの仕様やデータベースへの変更に速やかに追随する必要、または少なくとも追随する必要があるかどうかを判断する必要があります。
たとえば、従業員情報の何らかのデータ項目がジンジャーから廃止されることになった場合、ジンジャーAPIはそのデータ項目に対応するキーの返却や受付を停止するか、少なくとも参照を廃止する対応を速やかにとらなければ、ジンジャーAPIが受け付けたリクエストに応じてデータベースを参照する際に何らかの例外が発生してしまうはずです。
また、何らかのデータ項目が新たに追加された場合は、ジンジャーAPIが何も対応しなくても例外が発生するようなことはないでしょうが、当該のデータ項目は外部から GET することも POST することもできないままであり、この状態が続くことはジンジャーAPIの価値を低めることになります。
このように、ジンジャーAPI開発には、新たなエンドポイントを提供していくだけでなく、各プロダクトの開発チームが バクソク で進める機能開発に追随して、すでに提供されているエンドポイントを維持・改善、また場合によっては廃止することも求められます。
ジンジャーAPIの課題
ジンジャーにおける “プロダクト”
ジンジャーにおける “プロダクト” とは、人事労務や勤怠管理、給与計算、ワークフロー、経費精算のように、単体でひとまとまりの業務を実現し、ユーザーに価値を提供しうるアプリケーション群を指します。
その意味で、横断的に各プロダクトのデータ（リソース）に対するインターフェースを提供するにすぎないジンジャーAPIは、厳密に言うと “プロダクト” ではありません。
そのため、苦労の節の2点目・3点目とも関連しますが、ジンジャーAPIの開発は、専任の PdM や開発チームが実施するのではなく、各プロダクトが自らのリソースの範疇で実施すべきではないか？という考え方も当然あるでしょう。
ジンジャーAPIは誰のものか
各プロダクトがそれぞれの事情と状況に応じて、それぞれのデータ（リソース）を扱う API を提供すれば、そのリソースに最も詳しい PdM 及び開発チームが、機能開発と同時に関連する API も開発できるようになるため、余計なコストやリスク、リードタイムを削減できるとも考えられます。
しかし、私は、そのような分担は忌避すべき部分最適でありサイロ化だと思います。
冒頭に述べた通り、ジンジャーAPIとは「ジンジャーで扱うデータを外部から操作するための RESTful API のエンドポイント群」であり、さまざまなリソースを扱う複数のエンドポイントをひとまとまりとして提供している点に価値があります。
そして、エンドポイント群のユーザー体験の一貫性を保ったり、同様にドキュメントサイトやヘルプページを体系的に運用したり、またどのプロダクトのデータ（リソース）に対して重点的に API を提供していくかの方針を決めたりすることには、各プロダクトが個々に API を提供するのではなく、API プロダクトとしての横断的なマネージメントが求められます。
よって、ジンジャーAPIは、単体で “プロダクト” であろうとなかろうと、ひとまとまりとして提供すべき体験と実現すべき価値がある以上、専任の PdM と開発チームによって全体最適の視点で開発されるべきものだと私は考えています。
大風呂敷を広げましたが、これが、私自身がジンジャーAPIの PdM として今後も果たしていくべきミッションだと自負しています。
おわりに
本記事では、ジンジャーAPIの概要をご紹介しつつ、その開発における苦労や課題、またそれらを踏まえて、プロダクトとしてのジンジャーAPIが果たすべき役割を述べさせていただきました。
課題の節で述べた、ユーザー体験の一貫性を保つことや、全体最適を実現することは、API に限らず横断的かつ多領域 (multi-disciplinary) にまたがるプロダクトにおいては、課題とみなす向きもある一方で、個別最適では実現しえない価値を提供できるチャンスであり、またそれこそがそのようなプロダクトを任せられた PdM の腕の見せ所であると思います。
Discussion