2024年12月から従来の健康保険証が新規では発行されなくなりました。現在はマイナンバーカード（以下、マイナカード）を健康保険証として利用する「マイナ保険証」制度に移行しており、マイナカードを保持していない人には「資格確認書」が交付されます。
こうした制度の変更に伴い、システム改修などの対応を迫られたのがHR部門向けのSaaSです。HRシステムの改修は決して簡単なものではありません。国から「こんなふうにプロダクトを更新してください」と指示があるわけではないため、書類や電子申請の内容から自分たちで仕様を考える必要があるのです。
そんな主体的に対応する必要がある状況の中で、スムーズにシステム改修を行い新制度への対応を済ませたのが、クラウド人事労務ソフト「SmartHR」を開発・提供する株式会社SmartHR。同社はドメインエキスパートと協力した仕様の理解や、抽象化による書類自動作成などの工夫で新制度に対応したそうです。労務プラスアプリ開発部のプロダクトエンジニア、大澤広朗さんと栗田一生さんに開発の裏側について伺いました。
度重なる法改正に対応できるよう、システム改修のやり方を工夫している
―― マイナ保険証への移行対応には、どのようなチームで取り組まれたのでしょうか。
大澤 普段から書類の作成などのシステム開発に携わっているチームで今回のマイナ保険証移行を担当しました。エンジニアは私と栗田、他に4名、そしてプロダクトオーナーを加えた計7名です。
また、当社には人事労務領域の専門知識とITやシステムに関する知識を併せ持つ「ドメインエキスパート」と呼ばれる職種のメンバーがおり、プロダクト開発でエンジニアと連携しています。私たちのチームでは、このドメインエキスパートがプロダクトオーナーも兼任しています。
―― 今回の対応は、会社としてはどのような位置付けでしたか。
大澤 売り上げなどには関係なく、“必ずやらなければならないもの”という位置付けでした。SmartHRを利用している多くのお客様が関係する影響範囲の大きい制度変更ですから、会社としては最優先で取り組む必要のあるシステム改修だったと言えます。
―― どのようにプロジェクトを進めましたか。
大澤 健康保険証が新たに発行されなくなるのが「2024年12月2日以降」であることは、1年ほど前から分かっていました。ただ、書類の内容に関する具体的な変更点が国から出されたのは2024年10月。わずか2カ月足らずでシステム改修を行う必要がありました。
まずは仕様の把握から始めました。マイナ保険証移行と資格確認書の発行に対応するため、書類や電子申請の仕様がどう変わるのか、従来の様式との差分を確認し、項目をスプレッドシートにまとめていきました。
それをたたき台にして、ドメインエキスパートにレビューしてもらい、修正を重ねていくという形で進めましたね。
スプレッドシートに項目をまとめている
―― 制度変更に伴うシステム対応には工数がかかる印象もありますが、今回はどうだったのでしょうか？
栗田 実は、システム改修自体は、それほど大変ではありませんでした。というのも、法改正などによる書類の仕様変更はこれまでも頻繁にあったため、SmartHRではどのような変更にも柔軟に対応できるようデータ構造を工夫しているんです。
―― どんな工夫か、具体的に教えていただけますか。
栗田 書類の様式が変わっても、過去に作った書類については影響が及ばないよう担保できる仕組みを採用しています。新しい書類の様式に合わせて過去の書類まで変更されてしまうと、お客様から見て不整合が生じかねないため、いわばバージョン管理に近い仕組みを設けています。
また、新しく書類を作成する際は、過去に作成した書類をコピーして活用しています。こうすることで、元の書類のフォーマットや構造が整った状態から開発できるため、コードの実装効率が高まります。
大澤 大変なのは、「書類の仕様が本当にこれでいいのか」といった内容に関するチェックです。例えば、マイナ保険証移行で国から提示された新しい仕様では、以前の書類にあったチェックマークが一つ消えていたんです。この変更に対して、私たちのプロダクトはどのように対応するべきなのか、書類から消えたからといって本当にチェックマークを消してしまっていいのか、といったことを議論しました。
―― 書類のとおりに対応するだけでは問題が起きる場合もある、と。
大澤 はい。仮に、従来は事業主による確認のチェックマークがあったのに、新しい様式では消えていたとします。このとき、SmartHRの画面からチェックマークを消しても、手続きにおける事業主の確認はされた状態と捉えてもいいのか……といった解釈の疑問が生まれます。こうした疑問について、一つ一つドメインエキスパートに確認しながら最終的な仕様を決定する必要があります。
栗田 結果的に今回の対応では「資格確認書発行要否」の項目を追加するだけで済んだため、作業負荷としては比較的スムーズに対応できました。
―― 項目を一つ増やしただけだったんですか。
大澤 項目自体はシンプルなのですが、資格確認書に関係する書類は非常にたくさんあるのです。例えば今回は以下の書類の変更が必要でした。
- 健康保険・厚生年金保険 被保険者資格取得届／70歳以上被用者該当届
- 健康保険・厚生年金保険 被保険者資格喪失届／70歳以上被用者不該当届
- 健康保険・厚生年金保険 被保険者報酬月額変更届／70歳以上被用者月額変更届
- 健康保険・厚生年金保険 被保険者賞与支払届／70歳以上被用者賞与支払届
- 健康保険・厚生年金保険 被保険者報酬月額算定基礎届／70歳以上被用者算定基礎届
- 健康保険・厚生年金保険 被扶養者（異動）届／国民年金第3号被保険者関係届
- 健康保険厚生年金保険 育児休業等取得者申出書（新規・延長）／終了届
- 健康保険厚生年金保険 産前産後休業取得者申出書／変更（終了）届
ユーザーにとっては一見同じように見える名前の書類でもまったく別物で、各書類で適切に項目を追加をする必要があります。通常行っている他の開発もあるので、チームメンバーで分担して対応しました。
人事労務の経験と知見が豊富なドメインエキスパートが開発の鍵を握る
―― 先ほどから登場する「ドメインエキスパート」について詳しく教えてください。SmartHRにおける開発で特徴的な職種だと思いますが、どのようなバックグラウンドを持っている方たちなのでしょうか。
大澤 バックグラウンドは本当に多様です。社労士の副業をされている方もいれば、toB向け労務システムの開発にSIerとして携わっていた方もいます。共通しているのは、人事労務に関する豊富な知識を持ちながらも、システムのことを考慮してくれること。エンジニアからすると、非常に頼りになる存在です。
私たちのチームは先ほど述べたようにプロダクトオーナーとドメインエキスパートが同一人物で、社内では珍しいパターンです。他のチームはプロダクトオーナーとは別にドメインエキスパートが必ず一人加わり、プロジェクト内の人事労務に関する内容に間違いがないかをチェックしています。
例えば、開発チームのSlackチャンネルに入ってもらってレビューを逐一お願いしているチームもあれば、開発プロセスのレビューごとに入ってもらうケースもあります。それぞれのチームやプロダクトの特性に応じて関わり方を決めています。
―― 開発の中でドメインエキスパートの方と“解釈のずれ“が起きることもあるのでしょうか？
大澤 用語の捉え方にずれが生じることは少なくありません。例えば、ドメインエキスパートが「被保険者整理番号」とだけ伝えてきた場合でも、それには年金用や健康保険用など、複数の種類が存在します。同じ用語でも文脈によって意味が異なることが多く、書類の項目名だけでは一意に特定できないケースもあります。思い込みで進めると手戻りが発生することもあるので、チーム内では丁寧なコミュニケーションを心がけています。
ドメインエキスパートにはなるべく前段階でレビューしてもらうことも意識しています。開発が進んでしまうと、手戻りが大きくなってしまいますから。
栗田 マイナ保険証移行でも、いきなり開発プロセスに入るわけではなく、まずエンジニアが変更点をドキュメントにまとめ、それをドメインエキスパートにレビューしてもらうステップを加えて、手戻りの発生を防ぎました。
ドメインエキスパートレビューで細かくチェックする
育児時短のような新たな制度に対応する際は、どのプロダクトがそのデータを扱うか、保存場所やAPI設計も含めて慎重に検討しています。たくさんのマイクロサービスが連携する中で影響範囲や再利用性を考慮するため、制度理解から情報設計に至るまでの知見がエンジニアに着実に蓄積されています。ドメインエキスパートとの連携を通じて、実装に至るプロセス自体が貴重な学びの場となっています。
―― ドメインエキスパートに頼れるとはいえ、エンジニアの皆さんもドメイン知識を持っておいた方がスムーズな部分もあるかと思います。情報のキャッチアップについて取り組んでいることはありますか。
大澤 そもそも日々の開発業務を通じてドメイン知識を叩き込まれるわけですが（笑）。それ以外にも「人事労務マイスター検定」等の外部の検定を受験したり、ドメイン知識の勉強会が開かれるので参加したりします。
また、ドメインエキスパートが節目のタイミングで「法改正で何がどのように変わるのか」についてドキュメントをまとめて共有してくれることもあります。これは組織にとって重要な知見の一つとなっています。
ガントチャートでの進捗管理と自動化の取り組みで開発を効率化
―― 開発の進め方も詳しく教えてください。進捗管理はどのように行いましたか。
大澤 ガントチャートで管理していました。毎週のスクラムで、チームでやり切れるポイントを見積もって、それを日々開発する。そして、1週間に1回は経過をチェックするという、基本的なやり方を続けました。
―― ガントチャートを使う上でのルールや工夫はありますか。
栗田 誰が何に対応しているのかを分かりやすく可視化するために、各自のアイコンを置くようにしました。こうすることで、アイコンがない人は手が空いていることが分かるわけです。
また、デイリースクラムでは、理想のラインと現実がどれだけ離れているのかを確認して、開発の遅れについてはすぐに把握できるようにしていました。
―― 自動化にも取り組まれたとか。
栗田 はい。自動化はマイナ保険証の移行対応よりも前、2023年の年末ごろから構想していました。当時、次の期の計画を立てたときに、書類を膨大に作成しなければならないことが判明したんです。今までの開発方法では間に合わないと判断し、2024年の前半に書類を自動的に作成するシステムを開発しました。それがマイナ保険証移行にも偶然ですが役立ちました。
―― 当時はなぜ書類をたくさん作る必要が出てきたのですか？
栗田 社内的な要因もあったのですが、大きかったのは外部要因です。2025年1月から電子申請が義務化された書類がいくつかあり、それに対応するためでした。例えば、労働者死傷病報告、総括安全衛生管理者/安全管理者/衛生管理者/産業医の選任報告、健康診断結果報告、心理的な負担の程度を把握するための検査結果等報告書……などが該当しますね。
―― これらを一つ一つ対応する必要があった……と。一般的な法改正はスケジュールが決まっているのでしょうか。例えば、1年に1回、この時期に必ず変更が入るとか。
大澤 だいたい四半期ごとに法改正があるので、対応が必要になりますね。ドメインエキスパートが法改正をチェックするためのSlackチャンネルがあって、改正があるとそこで議論が起こり、しばらくして現場にも共有されるという流れです。
栗田 加えてマイナ保険証対応のようにイレギュラーな対応が突発的に発生することもよくあります。
プロダクトの“コアを抽象化”してRailsジェネレータで自動生成する
―― 自動化によって、どのような効果が出ているか教えてください。
栗田 そもそも以前は一つの書類を作るのに時間がかかりすぎていました。1種類の書類を作るのに平均して4スプリント以上（SmartHRの場合は1スプリント1週間のため1カ月以上）です。それが自動化を実現してからは、早いものだと2日、平均すると2スプリントくらいで作れるようになりました。
―― 開発全体にかかる時間が半分になったのですね。
栗田 一つの書類を作る場合にファイル数でいうと、だいたい40ファイルくらい手を加えることになるんです。変更する行数でいうと、1万5,000行くらいもの差分が生じます。これを手作業で作っていくのはかなり難しいですし、それをレビューするのも大変です。
そこで、自動で生成された部分に関してはレビューしない方針にしています。これによりレビューのコストはかなり下がっていますが、まだ自動化できる余地は残されていると考えています。
―― 技術的にはどのように実現しているのでしょう。
栗田 AIなどはまったく使わず、「こういった入力に対しては、このようなコードを出力する」というパターンを、Railsのジェネレータでテンプレート化して対応しています。先ほど言及した書類や電子申請の仕様をまとめたスプレッドシートをCSVファイルに変換し、このファイルを入力値として、RailsやReactのコードを出力するように作っています。
大澤 Railsのジェネレータを使った自動化は、誰でも思いつきそうでいて、意外とやっている会社は少ないのではないでしょうか。
Railsのジェネレータでの自動生成のイメージ
―― なぜSmartHRではそれが実現できているのでしょう。
栗田 自分たちが作っているSmartHRというプロダクトを“抽象化できている”ことが大きいと思います。一般的にプロダクトはさまざまな機能が追加されて装飾されていきますが、コアな部分は実はあまり変わりません。ジェネレータを活用する上では、コアとなる処理や構造をどこまで抽象化できるかを突き詰めて考え抜くことが大事だと思います。
―― 現在はAIを使っていないとのことですが、試行はされているのでしょうか。
栗田 一部、プロダクトに組み込まれているAI機能もありますが、私たちが携わっているプロダクトではまだ使えていません。作業段階ではAIに要約させたりしているのですが、正直精度はまだまだです。
ただ、まだ自動化できていない部分でAIと相性が良さそうな工程もあると考えています。例えば、ユーザーが提出する書類を紙で出力するための「プレビュー機能」。今はPDFを出力するのに各項目を手作業でマッピングしていますが、これをAIでできないか検討しています。
「仕組み」と「工夫」で課題を解決する。プロダクトエンジニアの醍醐味
―― お二人が開発時に意識していることや大切にしていることを教えてください。
大澤 エンジニアの感覚だけで進めるのではなく、ドメインエキスパートや人事労務担当者のフィードバックをもらった上で決めていく。そして、第三者の目線で見て、問題なく使えるかどうかを大事にしています。
栗田 大澤と同じような答えになりますが、開発中に自分が打ち出した仮説については、早い段階でレビューを通して答え合わせをすることを意識しています。特にSmartHRは自社の人事労務担当者の意見が聞けるので、そういった方々の意見を大切にしています。
―― 最後に、SmartHRのプロダクトエンジニアとして働く中で感じている開発の楽しさについて教えてください。
大澤 法改正など、対応しなければならない事態が多発するので、それにどう応えていくのか。その中でユーザーにどう利便性をもたらすのかを考えなくてはいけません。開発は大変ですが、それが醍醐味（だいごみ）でもあります。
私は「制限がないと工夫は生まれない」と考えています。課題がたくさんあるということは、エンジニアとして解決できる機会が多く与えられているということ。「期限がある中で、どこまで作り込めるのか」というスコープを意識して、ポジティブに取り組んでいます。
栗田 何か課題があったとき、安易に人的リソースを増やして解決するという方法をSmartHRでは基本的にとっていません。それよりも、「仕組み」と「工夫」で解決しようとする組織文化があります。そういうやり方やカルチャーは、エンジニアとして楽しい環境だと感じていますね。
取材・構成：山田井 ユウキ
編集・制作：はてな編集部