- はじめに
- 給与計算オプションの開発で最初に困ったこと
- なぜ開発部だけでなく事業部にも給与計算の知識が必要だったのか
- まず、初心者向けの課題図書を選んだ
- MVP開発に必要な知識に絞って、学習コンテンツを作った
- 仕様説明では、「なぜその機能が必要なのか」まで説明した
- リリースまで進めるうえで大事だったこと
- まとめ
はじめに
楽楽勤怠のプロダクトマネジメントをしている @k0First です。
2026年4月に、楽楽勤怠から給与計算オプションをリリースしました。
給与計算オプションの開発で難しかったことの一つが、給与計算というドメインの理解でした。
私は前職で給与計算システムの開発経験があり、一定のドメイン知識を持っていました。
一方で、今回の開発では、自分以外の開発部・事業部メンバーの多くが、給与計算の知識をほとんど持っていない状態からのスタートでした。
給与計算は、勤怠データや賃金規定、各種手当、控除、割増計算、端数処理など、さまざまな要素が絡み合う複雑なドメインです。
しかも、最終的に扱うのは「給与」です。
「だいたい合っていそう」では済まされません。
PdM/POである自分だけが理解していればよい、というものではありませんでした。
開発部が仕様の背景を理解して設計・実装できること。
事業部がリリースに向けた説明やマニュアル作成を進められること。
そのためには、関係者がそれぞれの役割に必要な範囲で、給与計算を理解している必要がありました。
給与計算オプションは、2025年7月に開発を開始し、2026年4月にリリースしました。
この期間でリリースまで進められた理由の一つは、早い段階から開発部・事業部のドメイン知識を底上げし、関係者が自分の役割の中で判断しやすい状態を作れたことだと思っています。
この記事では、給与計算を知らないメンバーと給与計算オプションをリリースするために、どのようにドメイン知識を身につけてもらったのかを書いていきます。
給与計算オプションの開発で最初に困ったこと
給与計算オプションの開発で最初にぶつかった壁は、給与計算というドメインそのものの難しさです。
給与計算は、単に勤怠時間を集計して金額を出せば終わり、というものではありません。
会社ごとの賃金規定に基づいて、基本給、各種手当、控除、割増賃金、端数処理などを組み合わせて計算します。
さらに、会社によってルールや運用が異なります。
ある会社では当たり前の計算方法が、別の会社ではまったく違う。
そんなことも普通に起こります。
つまり、給与計算オプションを作るには、画面や機能の仕様を理解するだけでは足りません。
その裏側にある業務や、「なぜその計算が必要なのか」まで理解する必要があります。
私は前職で給与計算システムの開発経験があったため、ある程度の前提知識を持っていました。
しかし、自分以外の開発部・事業部メンバーは、給与計算の知識がほとんどない状態です。
このまま開発を進めると、何が起きるか。
開発部からは、こんな確認が出てきます。
- この項目はなぜ必要なのか
- この計算ルールはどの業務に使われるのか
- この仕様で、どこまでのケースに対応できるのか
こうした質問に答えること自体は、PdM/POの大事な役割です。
ただ、すべての確認や判断が自分に集まる状態になると、開発のスピードが落ちてしまいます。
さらに、リリースに向けた説明やマニュアル作成を進めるときにも、毎回自分が説明しないと前に進まない状態になってしまいます。
ここで最初に考えたのは、「自分がもっと詳しく説明できるようにしよう」ではありませんでした。
それよりも、
みんなが自分の役割に必要な範囲で、給与計算を理解できる状態を作らないといけない
ということでした。
給与計算オプションをリリースまで進めるためには、自分だけが詳しい状態から抜け出す必要がありました。
なぜ開発部だけでなく事業部にも給与計算の知識が必要だったのか
最初は、開発部のメンバーに給与計算の知識を身につけてもらうことが重要だと考えていました。
開発部が仕様の背景を理解していないと、設計や実装の判断が難しくなります。
例えば、以下のような判断です。
- ある計算ルールをどう表現するか
- どこまで設定で変更できるようにするか
- どのような条件でエラーを返すべきか
こうした判断は、仕様書に書かれている内容だけでは決めきれません。
給与計算の業務背景を理解しているからこそ、判断できることがあります。
ただ、開発を進める中で気づきました。
「あれ、これは開発部だけの話じゃないぞ・・・？」
今回の開発では、事業部もリリースに向けて重要な役割を担っていました。
例えば、マニュアル作成です。
操作手順だけを書けばよいなら、画面を見ればある程度進められるかもしれません。
でも実際には、それだけでは足りません。
- なぜこの設定が必要なのか
- この項目を設定すると、どの計算に影響するのか
- お客様はどの場面でこの機能を使うのか
こうした背景がわからないと、マニュアルの説明も薄くなってしまいます。
お客様にリリース内容を説明する場合も同じです。
今回の給与計算オプションで何ができるのか。
どのような業務を支援する機能なのか。
どこまでが対象で、どこから先は対象外なのか。
これらを説明するには、事業部側にも給与計算の基本的な理解が必要でした。
つまり、給与計算オプションをリリースするには、開発部だけでなく事業部にもドメイン知識が必要だったのです。
開発部が実装を進める。
事業部がお客様に向けた説明やマニュアルを準備する。
そして、リリースに向けてそれぞれの立場で判断していく。
その流れを止めないためには、関係者がそれぞれの役割に必要な範囲で、給与計算を理解している必要がありました。
まず、初心者向けの課題図書を選んだ
最初に取り組んだのは、初心者向けの課題図書を選ぶことです。
給与計算について学べる本はたくさんあります。
ただ、実際に探してみるとけっこう大変でした。
専門的すぎる本もあります。
法律や制度の説明が中心の本もあります。
実務担当者向けに、かなり細かい手続きまで書かれている本もあります。
もちろん、どれも重要な知識です。
ただ、今回の目的は、開発部・事業部のメンバーを給与計算の専門家にすることではありません。
必要だったのは、給与計算の基本的な考え方を理解し、仕様やリリース内容を理解できるようになることです。
そこで、本屋や図書館に行き、実際に本を手に取って選びました。
このとき見ていたポイントは、主に次のようなものです。
- 給与計算の全体像がつかみやすいか
- 初心者でも読み進めやすいか
- 専門用語が多すぎないか
- 実務の流れをイメージしやすいか
- 開発部・事業部のどちらが読んでも役立ちそうか
いくつか本を見比べながら、「最初に読むならこれがよさそうだな」という本を選びました。
ここは、思った以上に大事な工程でした。
最初に触れる情報が難しすぎると、「給与計算ってよくわからない」「自分には関係なさそう」と感じてしまいます。
逆に、最初の一冊で全体像がつかめると、その後の仕様説明や議論がかなり進めやすくなります。
選んだ本は、開発部・事業部共通の課題図書として指定し、事前に読んでもらいました。
ただ、いきなり課題図書を読んでもらうだけでは、少しハードルが高いとも感じていました。
給与計算をまったく知らない状態だと、本を読み始めても、最初の用語や業務の流れでつまずく可能性があります。
そこで、超初心者向けに給与計算の超概略資料も作成しました。
この資料では、細かい制度や計算方法には踏み込みすぎず、まずは以下のような全体像をつかめるようにしました。
- 給与計算とは何をする業務なのか
- 勤怠情報と給与計算がどうつながるのか
- 支給、控除、割増といった基本的な考え方
- 賃金規定が給与計算にどう関係するのか
まずは概略資料でざっくり全体像をつかむ。
そのうえで課題図書を読む。
この流れにすることで、学習のハードルを下げることを意識しました。
課題図書を共通にしたのは、全員に同じレベルの知識を求めたかったからではありません。
まずは、「給与計算ってこういうものなんだ」という感覚を持ってもらいたかったからです。
例えば、「賃金規定」「割増賃金」「控除」「支給項目」といった言葉を聞いたときに、まったくイメージが湧かない状態と、なんとなくでも意味がわかる状態では、その後の理解度が大きく変わります。
まずは、給与計算の世界に入るための入口を作る。
課題図書と超概略資料には、そんな役割を持たせていました。
MVP開発に必要な知識に絞って、学習コンテンツを作った
課題図書を読んでもらうことで、給与計算の基本的な考え方に触れてもらうことはできました。
ただ、一度読んだだけで身につくものでもありません。
給与計算の範囲はとても広いです。
全部をちゃんと学ぼうとすると、本当に終わりが見えません。
一方で、開発は前に進めなければなりません。
全員が給与計算のすべてを理解するまで待っていたら、開発速度が落ちてしまいます。
そこで考えたのが、今回のMVP開発に本当に必要な知識を、まず最初に身につけてもらうということでした。
必要だったのは、給与計算のすべてを理解してもらうことではありません。
- 給与計算オプションのMVP開発に必要な知識
- 仕様を理解し、判断するために必要な知識
- リリースに向けた説明やマニュアル作成に必要な知識
この範囲に絞って、学習コンテンツを作成しました。
ここで大事にした狙いは、主に2つあります。
1つ目は、本当に必要な知識から先に身につけてもらうことです。
給与計算の知識をすべて網羅しようとすると、どうしても時間がかかります。
もちろん深い理解は大事ですが、今回まず必要だったのは、開発やリリース準備を進めるための最低限の理解でした。
そのため、MVP開発に関係する内容を中心に整理し、優先的に学べるようにしました。
2つ目は、本を読むだけではなく、別の形で復習できるようにすることです。
本を読んだだけだと、どうしても理解が曖昧なまま残る部分があります。
一度読んで「わかった気がする」と思っても、仕様説明や実際の議論の場になると、うまく結びつかないこともあります。
そこで、読むだけではなく、聞いたり、確認したりできる形にすることで、理解度を高められるようにしました。
この学習コンテンツ作成に活用したのが、Google NotebookLMです。
具体的には、自分で整理した内容や、業務上扱える情報をもとに、音声解説や理解度確認テストの作成に活用しました。
Google NotebookLMを使ってよかったのは、知識を「読むもの」だけでなく、「聞けるもの」「確認できるもの」に変えられたことです。
音声解説では、給与計算の基本的な考え方や、今回の給与計算オプションで扱う範囲について、初心者でも理解しやすいように説明をチューニングしました。
理解度確認テストでは、ただ読んだり聞いたりするだけではなく、自分がどこまで理解できているかを確認できるようにしました。
ここで特に気をつけたのは、説明の粒度です。
給与計算に詳しい人向けなら、専門用語を使えば短く説明できます。
でも、今回の対象は給与計算をほとんど知らないメンバーです。
いきなり専門用語から入ると、そこで止まってしまいます。
そのため、
- なぜその考え方が必要なのか
- どんな業務に関係するのか
- 今回の仕様ではどこに関わるのか
という流れで理解できるようにしました。
また、あえて説明しすぎないことも意識しました。
給与計算のすべてを詰め込むと、情報量が多すぎて、かえって大事なことが見えにくくなります。
今回は、MVP開発に必要な知識に絞る。
その範囲ではしっかり理解できるようにする。
この割り切りが、かなり重要だったと思います。
「給与計算を全部学ぶ」のではなく、「今回の開発を前に進めるために必要な知識を身につける」。
この目的をはっきりさせたことで、学習コンテンツの方向性も定まりました。
仕様説明では、「なぜその機能が必要なのか」まで説明した
ドメイン知識を身につけてもらう取り組みと並行して、仕様説明のやり方も変えました。
給与計算オプションの仕様は、画面や機能だけを見るとかなり複雑です。
入力項目も多く、設定する内容も多岐にわたります。
そのため、「この画面ではこの項目を設定します」という説明だけでは、なかなか理解しきれません。
むしろ大事なのは、その先です。
- なぜこの画面が必要なのか
- なぜこの設定項目が必要なのか
- この機能は、どの給与計算業務を支えるものなのか
- MVPではどこまで対応し、どこから先は対象外にするのか
ここまで説明して、ようやく仕様が立体的に見えてきます。
例えば、ある設定項目を説明するときも、単に「ここに値を入力します」とは言いません。
- この項目は、こういう賃金規定を表現するために必要です
- この設定によって、この計算結果が変わります
- 今回のMVPでは、まずこの範囲に対応します
というように、業務上の意味や判断の背景をセットで伝えるようにしました。
すると、少しずつ会話の質が変わっていきました。
単なる仕様確認だけではなく、
- このケースも考慮したほうがよさそう
- この表現だと、お客様には伝わりにくいかも
- ここはMVPでは割り切ってもよさそう
といった会話が出るようになってきました。
これは、とても大きな変化でした。
自分が一方的に説明し続けるのではなく、開発部・事業部がそれぞれの視点で考え、判断しようとしてくれる。
その状態に近づいていったことで、開発もリリース準備も進めやすくなりました。
仕様を伝えるだけでは足りません。
特に複雑なドメインでは、「なぜその仕様なのか」まで伝えることが大事だと改めて感じました。
リリースまで進めるうえで大事だったこと
今回の開発を振り返ると、リリースまで進めるうえで大事だったことは、大きく4つあります。
1. 自分だけが詳しい状態にしない
PdM/POがドメイン知識を持っていることは重要です。
ただ、それだけでは開発は進みません。
特に給与計算のような複雑なドメインでは、開発部・事業部がそれぞれの役割の中で判断できる状態を作る必要があります。
2. 開発部・事業部が必要な知識を持てるようにする
開発部には、仕様の背景を理解したうえで設計・実装するための知識が必要です。
事業部には、顧客説明やマニュアル作成を進めるための知識が必要です。
役割は違っても、リリースに向かううえで必要な知識は重なります。
3. すべてを学ぶのではなく、今回必要な範囲に絞る
給与計算の知識は本当に広いです。
全部理解してから進めようとすると、かなり時間がかかります。
だからこそ、今回のMVP開発に必要な知識に絞りました。
概略資料で全体像をつかみ、課題図書で基本を押さえ、学習コンテンツで今回必要な知識を補う。
この進め方は、現実的で効果的だったと思います。
4. 仕様の背景や目的まで伝える
仕様書や画面だけでは、なぜその機能が必要なのかまでは伝わりにくいです。
その機能がどの業務課題を解決するのか。
なぜその項目が必要なのか。
どこまでをMVPで扱うのか。
こうした背景や目的を説明することで、関係者が自分の役割の中で判断しやすくなります。
振り返ると、今回の開発では「仕様を作ること」だけでなく、「理解できる状態を作ること」にかなり時間を使いました。
最初は遠回りに見えるかもしれません。
でも、複雑なドメインでは、この遠回りが結果的に近道になることがあります。
関係者が理解し、自分の役割で判断できるようになると、開発やリリース準備が止まりにくくなるからです。
まとめ
給与計算オプションの開発では、給与計算という複雑なドメインに向き合う必要がありました。
今回あらためて感じたのは、複雑な業務ドメインのプロダクト開発では、PdM/POが詳しいだけでは不十分だということです。
開発部が仕様の背景を理解して設計・実装できること。
事業部がリリースに向けた説明やマニュアル作成を進められること。
そのためには、それぞれの役割に必要な範囲で、ドメイン知識を身につけてもらう必要があります。
課題図書、超概略資料、学習コンテンツ、Google NotebookLMを使った音声解説や理解度確認テストなど、やったことはいくつかあります。
ただ、一番大事だったのは、自分の中にある知識を、関係者が理解しやすい形に変えて届けることだったと思います。
2025年7月に開発を開始し、2026年4月にリリースまで進められた背景には、こうした取り組みによって、開発部・事業部がそれぞれの役割で動きやすくなったことがありました。
何を作るかを考えることと同じくらい、誰がどこまで理解している状態を作るかも大事。
今回の開発を通じて、そんなことを強く感じました。
