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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• WHIのconnpassページ

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

• お申し込みはこちら