SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine(コードジン) ProductZine

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

Developers Summit 2026 KANSAI セッションレポート(AD)

「言われた通りに作ったのに使われない」はなぜ起きる? WHIが機能ごとに「メリット」を考え抜く理由

【A-3】複雑な業務ドメインを紐解き、「本当に価値がある機能を生みだすプロセス」とは?~お客様のメリットから逆算する思考法~

DeveloperZine編集部[著] / 岩本 隆之[写]

 「言われた通りの仕様で作ったのに、お客様に使われない」。エンジニアなら一度は味わう苦しさだろう。大手法人向け統合人事システム「COMPANY」を提供するWorks Human Intelligence(WHI)の答えはシンプルだ。機能を1つ考えるたびに、その機能は顧客にとって何がうれしいのか、「メリット」を企画書に必ず書き添える。Developers Summit 2026 KANSAIに登壇した同社の平田憲穏氏は、30年使われ続ける製品を支えるこの考え方を、給与計算の法改正対応・法定業務における機能の企画という2つの実例とともに解き明かした。

設計書には、「その機能で誰が得をするか」を書く欄がない

 Works Human Intelligence(WHI)は大手法人向け統合人事システム「COMPANY」を提供する企業だ。従業員数3000人以上の国内大手法人の3社に1社が同社製品を利用(※1)し、約1200法人グループを顧客に持つ。管理する人事データ数は約570万人(※2)で、1年に数十万人ずつ増えているという。人事管理を中心に、給与計算、勤怠管理、タレントマネジメントまでを1つの製品でカバーする。「日本を代表する数多くの企業の人事を支えている会社です」と平田氏は自社を紹介する。

(※1)WHI調べ

(※2)2025年12月末時点の「COMPANY 人事」の契約ライセンス数合計

 平田氏は国内MBAでマーケティング戦略を学んだ後、2012年に新卒入社。「COMPANY 人事・給与」の開発者として、社会保険・公共給与のサブシステムを中心に、数々の法改正対応と新規機能の企画開発に従事してきた。人事業務という複雑な領域を深く理解したうえで、何を作るかを決めるところから開発までを担う「ドメインエキスパート」という役割にある。コンサルタントと議論したり、WHI主催のイベントにて顧客と会話をしたりし、「機能を使って業務が楽になった」という声を何よりの励みとする現場主義の開発者だ。

 その平田氏がセッションの冒頭で投げかけたのは、1つの問いだった。なぜ多くの顧客に「COMPANY」は使われ続けているのか。その答えとして平田氏が挙げたのが、社内で「カタログ」と呼ぶドキュメントと、それを書く過程で身につく思考法だった。

 WHIの言う「カタログ」とは、どの機能をいつ開発するかを定めた、機能開発の羅針盤にあたる文書だ。一般的な開発現場でいえば、要件定義書や設計書を書き始める前段にあたる、「何を、なぜ作るか」を決めるためのドキュメントにあたる。特徴は、その構成にある。1つの機能につき「機能概要」と「メリット」を必ずセットで書く。

 「機能概要はよく聞かれますが、メリットというのはあまり聞かないと思います」と平田氏。この2点セットは、商品カタログという言葉本来の姿に沿ったものだという。カタログとは品目を書き並べたものであり、そこから選ばれるためには目を引くメリットが欠かせない。開発する機能も同じで、メリットが書かれていてこそ選ばれる。だから商品カタログと同じように、機能概要とメリットをセットで書く形にした。

 一般的な設計書と比べると、違いは明快だ。設計書には機能要件が羅列される。もちろんその中にメリットが含まれることもある。しかし機能要件だけが並んだ状態では、メリットを考える行為そのものが無意識になり、「考え抜かれていないものが混じってしまうリスクがある」と平田氏は指摘する。対してWHIのカタログには、その機能を通じて顧客に与えたいメリットが、一つひとつの機能について必ず記載される。

一般的な設計書とWHIの「カタログ」の比較
一般的な設計書とWHIの「カタログ」の比較

 WHIがカタログを重要視している理由は、顧客へ提供するメリット、すなわち価値を機能一つひとつで徹底的に突き詰める思考プロセスを、仕組みとして手に入れることにあった。

顧客目線で「メリット」を考え抜く 手がかりは理想と現実の差

 では、そのメリットはどうやって見つけるのか。

株式会社Works Human Intelligence 製品開発部門 ドメインエキスパート 社会保険Grp マネージャー 平田憲穏氏
株式会社Works Human Intelligence 製品開発部門 ドメインエキスパート 社会保険Grp マネージャー 平田憲穏氏

 平田氏が示したのは、理想の業務と現実の業務の差からメリットを見つけ出すというプロセスだ。まず現実の業務を深く読み解く。深く分かってきた現実に対して、理想の業務は何かを考える。その2つの差分こそが、機能のメリットになる。差が大きければ大きいほど、メリットも大きくなる。だからこそ差を1つずつ洗い出し、大きなところから機能を企画していく。

理想の業務と現実の業務の差からメリットを見出すプロセス
理想の業務と現実の業務の差からメリットを見出すプロセス

 このメリットを突き詰めた業務機能の集合体が、統合人事システム「COMPANY」である。日本の大手法人の複雑な人事業務のあるべき姿を描いているからこそ、WHIの強みであるノーカスタマイズの製品が成立する、と平田氏は語る。

 もっとも、このカタログは最初から現在の形だったわけではない。

「理想の業務」は、顧客の想像を超えていくべき カタログ思考の運用で分かったこと

 当初のカタログは、概要(Outline)と機能リスト(Function List)の2部構成だった。世間一般の商品カタログに近い形である。だが、この形式で機能を検討するうちに大きな課題が見えてきた。

 その課題とは、機能リスト・メリットからいきなり書き始めてしまう、つまり解決策から書いてしまうことだ。それによって何が起きるか。理想と現実の差が暗黙の前提に置かれたまま、メリットを考えることになる。

 「業務やお客様への洞察が不明確なまま、理想と現実の差が捉えられてしまって、機能のメリットが浅くなってしまう」

 そこで「COMPANY」の開発者は、メリットを掘り下げるための補助線として、業務調査(Business Investigation)とユーザー調査(User Investigation)という2つの欄を追加した。誰がどんな業務でこの機能を使うのかを先に書き出させる仕掛けである。顧客、ユーザー、そして業務が明確になり、理想と現実の差を深く捉えやすくなる。現実の業務像の解像度は確かに上がった。

業務調査・ユーザー調査を加えたWHIの「カタログ」のフォーマット
業務調査・ユーザー調査を加えたWHIの「カタログ」のフォーマット

 さらに、もう1つ注意すべきポイントがあると平田氏は言う。既存の業務は顧客が知っているのだから、理想も顧客に聞けばいいのではないか、という考え方だ。ヒアリングで理想を教えてもらい、そこから差を見出すスタイルである。

 しかし、顧客にヒアリングした理想を単純に目指すだけでは、本来的な理想に届かない可能性がある。WHIが追求するのは、顧客の想像を超える「本質的な理想」の体現だ。単に1社の要望をそのまま形にするのではなく、開発者が培ってきたノウハウをもとに「真に必要な業務像」を定義する。その結果として、約1200法人グループの皆様に真の価値をお届けできる機能が実現していく。

 そこで同社が取るのは、開発者自身が業務の「理想」を設定するスタイルだ。顧客へのヒアリングはもちろん行う。そのうえで、ヒアリング結果を踏まえて開発者が自ら理想を描く。このプロセスによって、理想と現実の差をもれなく捉えられ、約1200法人グループに通用するメリットを見つけ出せるというわけだ。

 本当に価値ある機能を生み出す秘訣は、カタログを書く過程で業務と顧客を深掘りし、理想を設定して現実との差を見出し、そこからメリットを掘り当てることにある。平田氏はこの一連の考え方が「カタログ思考」であると解説し、セッションの前半を締めくくった。ここからは実際の事例である。

推奨か、必須か 読みづらいニーズの隣に、明確なニーズがあった

 紹介された2つの事例は、いずれも給与計算の法改正対応・法定業務における機能の企画だ。法改正対応はWHIが顧客から高い評価を得ている領域でもあり、顧客の声としては「定額減税、住民税額通知等の人事業務に必要不可欠な領域の最新情報をいち早くキャッチアップし、対応を示してもらえるのは、とてもありがたい」「他社事例があることでイメージを具体的に持てる」といった評価が寄せられているという。

 1つ目の事例は、子ども・子育て支援金の法改正対応である。2026年4月分より給与・賞与から徴収され、健康保険料のカテゴリで個人と事業主が折半して負担する。2026年5月以降の給与明細で「子ども・子育て支援金」の項目を目にした読者もいるだろう。

 この法改正を表層的に理解すれば、「子ども・子育て支援金」という項目を計算するという、決まった要件を実現する対応に見える。だが平田氏の理解は違った。「子ども・子育て支援金を計算する新しい業務の誕生であった」。法改正対応の本質は新しい業務の誕生であり、法を読み解いて見出した新しい業務に対してメリットのある機能を考える。決まった要件への対応になぜ企画が要るのか、という疑問への答えがここにある。

 構造的に見ていくと、まず全法人向けのニーズが浮かぶ。給与明細で子ども・子育て支援金を表示したい、というものだ。ただしこれは「推奨」の扱いで、対応するかどうかは企業に委ねられる。つまり、ニーズが事前に読みづらい。

 深掘りを進めると、もう1つのニーズが見つかった。公共団体向けの会計費目のニーズである。共済組合(保険者)に納付する際、健康保険でいう保険料にあたる「短期負担金」と子ども・子育て支援金とで、会計費目を分けたい。こちらは「必須」であり、ニーズは明確だった。

全法人向けニーズと公共団体向けニーズ。推奨と必須で性質が異なる
全法人向けニーズと公共団体向けニーズ。推奨と必須で性質が異なる

 全法人向けニーズだけを見ていては気づけなかったニーズである。平田氏はより明確なニーズを持つ公共団体をメインターゲットに据え、2025年春、法施行の1年前より開発活動に早期着手することを決めた。「使われるかもしれないけれども、使われないかもしれない」という状態では、なかなか開発活動に踏み切れない。明確なニーズがあると分かったからこそ踏み込めた判断だった。

 実のところ、公共団体向けに必要な対応と、全法人向けに必要な対応はその大部分が重複していた。そのため、公務員向けニーズに応えるべく早期に着手したことで、全法人向けのニーズにも副次的な早期着手もできていた。 

 結果として、法施行9カ月前にリリースを実現した。全法人向けのニーズだけを把握していた場合、ニーズが読めず開発着手ができないまま法改正直前あるいは法改正後のリリースとなり、慌てて準備をしたり、間に合わなければ紙での暫定運用を用意したりするといった事態を回避した。業務の深掘りが、余裕を持った法改正対応の準備を可能にした。顧客に不要な手間をかけることなく、効率的に新たな業務運用を提供することができた。

顧客の声の“先”を読み取ることにエンジニアの価値がある

 2つ目の事例は、労働保険の継続事業の一括である。

 給与から引かれている雇用保険料の精算業務は、年に1回、6月から7月に労働保険の年度更新として行われる。そこで報告する賃金額を集計する業務に関する機能の企画だ。

 賃金の集計単位は、標準的には「事業」と呼ばれる単位になる。だが小売業のように支店ごとが1つの「事業」となっている会社では、事業の数だけ手続きが発生し、負担が大きい。そこで複数の事業(支店)をまとめて申請する制度が認められている。これをシステムで実現しようというのが本件だった。

 顧客の回答を表層的に解釈すると、賃金は事業よりも大きい業種単位(食料品製造業、交通運輸事業など)で集計しているととらえることができる。この解釈に立つなら、「事業」とは異なる「業種」単位での集計機能が必要となり、開発規模は大きい。

 ところが、顧客の回答に制度の理解を掛け合わせて深く解釈すると、見える景色が変わった。集計されていたのは、継続事業の一括における「指定事業」の単位だったのである。指定事業の一括とは、もともと同一業種内にある複数の「事業」を、親となる「指定事業」が束ねる仕組みである。つまり必要だったのは、「事業」単位の延長線上にある「指定事業」単位での集計機能であり、開発規模は小さかったのだ。

ヒアリング結果から想定した機能像と、制度解釈で見えた機能像
ヒアリング結果から想定した機能像と、制度解釈で見えた機能像

 表層的な解釈のままであれば、大きな改修コストが負担となって開発は進まなかった。深く解釈したことで改修コストを大幅にカットでき、開発は大きく前進してリリースに至った。

 「お客様の回答と制度で深く意味を解釈したら、本当に価値のある機能を低コストで生み出すことができた」と平田氏は振り返る。

使われる機能は、要望の先にある

 2つの事例に共通するのは、目の前の要望や条文をそのまま要件に翻訳しなかったことだ。顧客と業務を深く理解し、理想を想定する。その過程で初めて、メリットのある機能、顧客にとって価値のある機能が見えてくる。

 セッションの締めくくりに、平田氏は改めてカタログ思考を提示した。本当に価値ある機能を生み出す秘訣は、カタログを書く過程で業務と顧客を深掘りし、理想を設定して現実との差を見出し、そこからメリットを掘り当てることにある。

 AIが簡単なコードを書く時代に、エンジニアが身につけるべきは「何を、なぜ作るか」を定義する力だ。30年使われ続ける製品を支えてきたのは、作るものを決める文書に「メリット」という欄を設け、そこを埋め続けてきた思考プロセスだった。

 「ぜひ、このメリットを考える『カタログ思考』を持ち帰っていただいて、日頃の機能の企画や、開発部門で活用していただければと思います」

株式会社Works Human Intelligenceからのお知らせ

 Works Human Intelligenceでは、エンジニア向け勉強会をconnpassにて定期開催しています。興味のあるテーマがあれば、ぜひお気軽にご参加ください!

 また、共に次世代のHRテック製品をつくり上げるエンジニアメンバーを募集しています。今すぐに転職を考えていなくても、カジュアルに面談が可能です!

この記事は参考になりましたか?

提供:株式会社Works Human Intelligence

【AD】本記事の内容は記事掲載開始時点のものです 企画・制作 株式会社翔泳社

この記事は参考になりましたか?

この記事をシェア

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー