断片的な情報に既存情報を掛け合わせ、業務想定の解像度を高める
そして、もう1つ重要な考え方が、こうした課題やメリットについて「解像度を高めていく」ことだ。そのコツとして、平田氏は「法改正の断片的な情報を"高い解像度"を持つ既存情報とかけ合わせること」と語る。つまり、「業務担当者向けドキュメント」や「既存業務システムのソースコード」といった手元にある情報を、既存制度などと組み合わせることで、業務システムがつくれる水準まで業務想定の解像度を高められるわけだ。
例えば、前述の「公務員共済の短時間労働者への適用拡大」では、「制度変更がなく情報発信がない部分＝厚生年金」について、既存制度では別途申請していることを鑑み、「2つの保険制度に別々に届出を作成する業務が必要」と想定し、開発を行った。
また、「他のルールを拡大適用する」以上の情報がない箇所については、元ネタ制度の事例をかけあわせて業務解像度を上げることを行った。平田氏は「顧客である1200法人グループの厚生年金の短時間労働者向けの指針について把握しており、それをもとに共済にも取り込んだ。実際、過去の事例で2015年に共済年金の制度を取り入れる指針が示されており、読みどおり、共通という前提で開発することができた」と解説した。
そして、カテゴリ決定の情報を保持する項目を追加するための"決定パターン"が示されていなかったことについては、常勤でも判定や決定報酬が異なる場合、片方のカテゴリのみ決定改定するケースが発生すると想定。非常勤だけでなく常勤にも影響を受ける可能性があると思われたため、追加で明確な制度情報を得るまで待った。そして、確定情報を得てすぐに開発し、制度施行前に実装を完了させた。
平田氏は「それができたのも、法改正後の業務想定を具体的に描き、待つべきポイントだけ答え合わせをするつもりで開発を進めていたから。合っていれば機能実装方針を取り出して実装し、間違いがわかればそこだけ直すだけでよいようになっていた」と解説した。
最終形を想定したアップデートや勇気を持った削除で"ツギハギ"を回避
業務想定の解像度を上げて、法改正後に必要な機能を追加していくアプローチで、ハマりがちな課題が「改修を繰り返しツギハギになりがち」なことだ。多くの場合、変化する業務に対応するために、新しいオプションを追加する方法をとる。そうすることで、テスト範囲も限られるため、一見合理的に見える。
しかしながら、これを繰り返すことで「未来の重荷になる」と平田氏は指摘する。例えば、法改正後の新規ユーザーにオプション設定が必要になったり、過去帳票様式のサポートが残り続けたり、使わない様式について新業務パターンでの動きを考慮したりする必要が生じることもある。そこで、「付け足す」のではなく、「アップデート＝変える」ことが重要だ。
平田氏は、この「変える」ための考え方として、「変化した業務の『最終形』かどうかを問いかけることが重要」と語る。例えば、「判定」について法改正後の最終形に変えるかは、「10年後は当たり前になっているか」を考える。平田氏はそうした問いかけをいくつか持っており、「オプションにしたい」という欲求のストッパーとしている。
また、勇気をもって「変える」「削除する」ことも大切だ。例えば、古い帳票も残しつつ、新しい様式の帳票が出た場合、申請先の了解のもと、遡及届も含めて最新様式に近づけ、古い帳票様式は廃止するという。この判断について、平田氏は「遡及届は共済で2年、給与計算などで5年など法定で定められた期間を目安にしている」と語った。
そうしてツギハギを脱却し「変える」ことがかなうと、法改正後の新規ユーザーでも過去の法改正を意識せず機能が使えたり、サポート対象の帳票パターンが必要最低限になって機能改善や将来の法改正対応が容易になったり、さまざまなメリットを得ることができる。
平田氏は、「システム開発と言えば、『定められた業務要件をもとに業務機能を付け足す』イメージだが、実際には『断片的な情報を増幅させて業務を深く想定し、業務機能を変え、まだ見ぬ業務を創り出す』という非常にクリエイティブな仕事。そう考えれば、法改正対応もワクワクするものになっていく。ぜひ開発という仕事で、よりよき未来を切り開いていこう」とメッセージを送り、セッションのまとめとした。
