要件が固まらないのに、なぜ迅速な機能改定ができるのか
「新しい業務にすぐさま対応してほしい……」というリクエストを受けたことがあるエンジニアは決して少なくはないだろう。そんな時に、業務要件が固まっていなかったり、長く使っている業務システムをツギハギで改修し続けてしまったり、なかなか悩ましい問題が生じてくる。
Works Human Intelligence（以下、WHI）が提供する統合人事システム「COMPANY」も同様に、法定業務に関する、社会保険共済や年末調整税計算、人事院勧告などの法改正に迅速な対応が求められる。法改正対応に追加費用がかかるパッケージが多い中、「無償バージョンアップ」を掲げており、法改正後すぐに業務を実現できることを重視している。平田氏は「この姿勢に対して、ユーザーの71.6％が『法改正対応に対する安心感がある』と高く評価している」と胸を張る。
しかも、COMPANYは法改正施行日に対応した業務が実施できるようになっている。通常のシステムならば、法改正は「施行日直前になるまで業務要件が固まらない」という問題があり、対応にブランクが生じることが多い。通常ならば、要件が固まって初めて、改定のための開発・構築を実施するものだからだ。
なぜCOMPANYは、それほどまでに迅速な法改正対応が実現できるのか。平田氏が取り組んだ「公務員共済の短時間労働者への適用拡大」への対応事例を紹介しながら、その対応の秘密について紹介した。
制度変更では、2022年10月以後に、これまで社会保険に加入していた非常勤公務員も「共済短期組合員」として加入できるようになった。しかし、これに対応するための情報取得には、さまざまな問題があった。
まず、共済について「非常勤者も短期加入が可能」という情報は流れたが、制度変更のない厚生年金については情報がなかった。また、「短時間労働者のルールを拡大適用する」という情報はあっても、その詳細は未定となっていた。さらに短期・長期のうち、どのカテゴリを決定するかの情報を保持する項目を、新しいデータ連携に追加する必要があったが、そのカテゴリ決定パターンは提示されていなかった。いわば断片的な情報ばかりであった。
業務担当者からは「法改正後の制度要件に対応できるか」と言われるものの、開発側では断片的な情報だけではシステムは作れない。しかし、COMPANYでは次のような工夫で迅速な対応を実現させた。
断片的な情報から、業務とそのメリットをあぶり出す「カタログ思考」
まず1つ目は、法改正対応によって変化する業務について、「断片的な情報から業務を想定する」ことを前提として要件を設定した。通常の業務システム開発では、業務要件は業務担当者が持っており、そこからヒアリングするのが定石だろう。しかし、「COMPANY」では、法改正後の業務について「誰も分からない」ことを前提に、断片的な情報から業務を想定して企画・開発を行っている。
この業務想定の考え方、「課題を深く想定してメリット（提供価値）をベースに解決策を考える」というアプローチを、WHIでは「カタログ思考」と呼んで重視している。平田氏は「カタログとは『使うとメリットがある』と訴求し、商品を買ってもらうもの。この『メリット』の裏側には課題の想定がある。つまり、課題をどこまで深く理解し想定できるかによって、より高い価値を持つ『メリット』を提供できる」と説明する。
例えば、COMPANYの社会保険サブシステムに「人事給与情報から保険者に電子申請するデータが自動で作成できる」というメリットを持たせるには、「毎月数百人から数千人の申請作成で、必要な情報を複数の情報源から収集するのに手間がかかって困っている」という課題を深く理解し、具体的に想定できていることが必要となる。つまり、製品や機能を使う人の「困りごと」をどれだけ深くリアリティをもって実感できるかがカギになる。
この「カタログ思考」によってメリットある機能を大量に生み出し続けた結果、COMPANYはカスタマイズのいらないパッケージへと成長してきた。平田氏は「この『カタログ思考』を全ての開発者がDNAとして持つことで可能になった」と語る。
これによって、前述の「公務員共済の短時間労働者への適用拡大」についても、「毎月数百人～数千人の共済短期／一号厚年組合員について、複数の保険者制度に即して判定・届出作成する際の手間がかかり、困っている」という課題の想定がかない、COMPANYの共済サブシステムについて「共済短期／一号厚年組合員に対し、複数の保険者の制度に即した標準報酬算定、届出、掛金等控除が自動化できる」というメリットを創出できた。
断片的な情報に既存情報を掛け合わせ、業務想定の解像度を高める
そして、もう1つ重要な考え方が、こうした課題やメリットについて「解像度を高めていく」ことだ。そのコツとして、平田氏は「法改正の断片的な情報を"高い解像度"を持つ既存情報とかけ合わせること」と語る。つまり、「業務担当者向けドキュメント」や「既存業務システムのソースコード」といった手元にある情報を、既存制度などと組み合わせることで、業務システムがつくれる水準まで業務想定の解像度を高められるわけだ。
例えば、前述の「公務員共済の短時間労働者への適用拡大」では、「制度変更がなく情報発信がない部分＝厚生年金」について、既存制度では別途申請していることを鑑み、「2つの保険制度に別々に届出を作成する業務が必要」と想定し、開発を行った。
また、「他のルールを拡大適用する」以上の情報がない箇所については、元ネタ制度の事例をかけあわせて業務解像度を上げることを行った。平田氏は「顧客である1200法人グループの厚生年金の短時間労働者向けの指針について把握しており、それをもとに共済にも取り込んだ。実際、過去の事例で2015年に共済年金の制度を取り入れる指針が示されており、読みどおり、共通という前提で開発することができた」と解説した。
そして、カテゴリ決定の情報を保持する項目を追加するための"決定パターン"が示されていなかったことについては、常勤でも判定や決定報酬が異なる場合、片方のカテゴリのみ決定改定するケースが発生すると想定。非常勤だけでなく常勤にも影響を受ける可能性があると思われたため、追加で明確な制度情報を得るまで待った。そして、確定情報を得てすぐに開発し、制度施行前に実装を完了させた。
平田氏は「それができたのも、法改正後の業務想定を具体的に描き、待つべきポイントだけ答え合わせをするつもりで開発を進めていたから。合っていれば機能実装方針を取り出して実装し、間違いがわかればそこだけ直すだけでよいようになっていた」と解説した。
最終形を想定したアップデートや勇気を持った削除で"ツギハギ"を回避
業務想定の解像度を上げて、法改正後に必要な機能を追加していくアプローチで、ハマりがちな課題が「改修を繰り返しツギハギになりがち」なことだ。多くの場合、変化する業務に対応するために、新しいオプションを追加する方法をとる。そうすることで、テスト範囲も限られるため、一見合理的に見える。
しかしながら、これを繰り返すことで「未来の重荷になる」と平田氏は指摘する。例えば、法改正後の新規ユーザーにオプション設定が必要になったり、過去帳票様式のサポートが残り続けたり、使わない様式について新業務パターンでの動きを考慮したりする必要が生じることもある。そこで、「付け足す」のではなく、「アップデート＝変える」ことが重要だ。
平田氏は、この「変える」ための考え方として、「変化した業務の『最終形』かどうかを問いかけることが重要」と語る。例えば、「判定」について法改正後の最終形に変えるかは、「10年後は当たり前になっているか」を考える。平田氏はそうした問いかけをいくつか持っており、「オプションにしたい」という欲求のストッパーとしている。
また、勇気をもって「変える」「削除する」ことも大切だ。例えば、古い帳票も残しつつ、新しい様式の帳票が出た場合、申請先の了解のもと、遡及届も含めて最新様式に近づけ、古い帳票様式は廃止するという。この判断について、平田氏は「遡及届は共済で2年、給与計算などで5年など法定で定められた期間を目安にしている」と語った。
そうしてツギハギを脱却し「変える」ことがかなうと、法改正後の新規ユーザーでも過去の法改正を意識せず機能が使えたり、サポート対象の帳票パターンが必要最低限になって機能改善や将来の法改正対応が容易になったり、さまざまなメリットを得ることができる。
平田氏は、「システム開発と言えば、『定められた業務要件をもとに業務機能を付け足す』イメージだが、実際には『断片的な情報を増幅させて業務を深く想定し、業務機能を変え、まだ見ぬ業務を創り出す』という非常にクリエイティブな仕事。そう考えれば、法改正対応もワクワクするものになっていく。ぜひ開発という仕事で、よりよき未来を切り開いていこう」とメッセージを送り、セッションのまとめとした。
