約30年の歴史に培われた「COMPANY」が抱える課題とは
大手法人向け統合人事システム「COMPANY」シリーズのはじまりは1996年。同社の前身である株式会社ワークスアプリケーションズが開発に着手したことに端を発する。以来、社会の変化とともに進化と拡張を重ねてきた。2019年には分社化でHRテックを掲げる株式会社Works Human Intelligence（以下、WHI）が設立され、「COMPANY」シリーズがWHIに引き継がれた。
「COMPANY」シリーズは豊富な管理項目があり、人事情報だけではなく、グループ会社も含めた組織情報も一元管理できて、給与計算や勤怠管理とシームレスに連携できるのが特長だ。長い歴史を経て機能も業務範囲も広く拡張した一方、巨大なモノリシックであることの課題も抱えていた。
例えば年末調整など特定の業務だけを修正・適用したくても、そう簡単ではない。巨大さゆえに、小さな改修でもどこに影響があるか全体を確認する必要がある。これは開発生産性のさらなる向上において足かせとなっていた。また、各業務機能がシームレスに統合されていることと、かつてはオンプレミスで提供されていたこともあり、全プロダクトで一括のリリースとなっておりデプロイはテナント（顧客）ごとに日程調整して実施している。つまり、今どきのホットデプロイができない。リリース頻度を高めたくても難しい。
そこでWHIでは、システムの大きさによる課題はモダナイゼーションで、リリースプロセスの課題はリリース最適化で解決を図ることとして改善を進めてきた。
課題解決へのアプローチ：モダナイゼーション
「COMPANY」シリーズは幅広い機能を統合的に提供できる一方、巨大な1つのモジュールとして存在しているため、ビルドに時間がかかり、影響範囲が大きいのが難点だ。例えばアクセシビリティで改善を重ねたいとしても、本来使うべきHTMLタグではなくdivを装飾しているなど、UI以外のものがロジックとして混じっていて手を加えにくい。
こうした課題に対して、モジュール分割（フロントエンドの分離）、CIやCopilotの活用、アクセシビリティチェック、部署全体への啓発活動によって解決を図った。
まずはモジュール分割、つまりフロントエンドを分離することだ。現状ではJavaサーブレットで動いており、すべての業務機能が1つのリポジトリに格納されている。これらを最終的には1つのwar（Web Application Archive）としてコンパイルしている。そのため「画面に不具合があったから、フロントだけ修正したい」としても、フルビルドで1時間以上を要してしまう。さらに適用後も環境の再起動が必要になるなど、植野氏は「とにかく機動力が足りない」と言う。
フロントエンドだけを分離するとしても、元が巨大なので難しい。例えば雇用発令の入力業務部分など、特定の領域のフロントエンドを切り出すといった形のストラングラーパターンで分離を少しずつ進めている。
周辺で活用したいのがCIやCopilotだ。CI環境にLinterやFormatterを組み込むことで、ソースコードにスタイル違反などを検出し、コードを整形する。さらにCopilotになるとLinterで気づけない部分も指摘できるので有効だ。
アクセシビリティはJIS X 8341-3:2016のレベルA、国際的なガイドラインのWCAG 2.2のレベルAに準拠を目指しており、基本的にはaxe DevToolsでチェックしている。他にもコントラストなど機械的に検知が難しいものは、都度対応している。
モダナイゼーションはイネーブリングチームが啓発活動として進めているため、組織横断的に働きかけていく必要がある。まずは第一歩として、月次の部署ミーティングで取り組みを取り上げ「なぜ必要か」を説明するなどして、最終的には各部署で自発的に実施できることを目指している。
同時並行で進めているのが部署内インターンだ。他のチームから一時的にモダナイゼーションチームにインターンという形で加わり、GitHubのイシューなどの仕事を手伝ってもらう。今後それぞれのチームでモダナイゼーション活動の先駆者になってもらおうという考えだ。
課題解決へのアプローチ：リリース最適化
リリース最適化の話題に移る前に、「COMPANY」のクラウドサービス化の経緯を振り返っておこう。クラウドでのサービス提供を迅速かつ確実に開始するため、必要な改修は実施しつつ、プロダクト構成、モジュール構成、デプロイ方式は維持する一方、ビルドやリリースのパイプラインなど再構築が必要な部分は統合して中央集権で構築した。
長い歴史のなかで培ってきたビジネス資産を活かしてクラウド化への第一歩を進めるには「妥当な判断だったと思う。しかし今後も価値提供を続けるには、小さく早いリリースを実現するために分割するといった改善が必要」と髙橋氏は話す。
繰り返しになるが、現状では主要な全プロダクトを一斉にリリースするので頻度は低く、デプロイに時間がかかってしまう。顧客とスケジュールを調整する必要があり、一定のダウンタイムも生じてしまう。そのため小さく、早くリリースできるようにリリース最適化を進めている。
マイクロサービス化として先行したのが法定帳票出力機能だ。社会保険の手続きに関する法改正対応の一環で、法定帳票の出力をマイクロサービス化して「COMPANY」と接続することで、新しい様式に速やかに追従することが可能となった。
それだけで終わらせないようにするために、各プロダクトの開発部門にCI/CD・開発環境改善の専任チームを立ち上げた。これで全体の開発環境改善と生産性向上の施策実行を、複数チームが連携して推進する土台ができ、プロダクト固有の課題解決も含めて生産性向上のための施策が動き始めた。
そしていよいよリリースシステムの分割である。ビルドやリリースのパイプライン分割や、作業手順やプロセス整備を通じて、プロダクトごとのリリース（Hotfix）を順次開始している。現段階では一部のプロダクトのアプリケーション本体が対象になる。
今後は会社で規定する品質担保の基準を満たせば、組織体力に応じて無理のない形でプロセスを整備・運用できる。プロセスの軽量化とリリース承認の権限をプロダクトオーナーに委譲したことで、リリース承認から提供開始のリードタイムが最大で1/3程度に短縮できている。今後はHotfixの範囲を拡大し、ダウンタイムの縮小、ひいては撤廃に向けて進めて行く。
こうした取り組みを進めていく上でのポイントとして、1点目は「理想を追求するあまり作りこみすぎない」。ここは価値観のシフトが必要なところだ。アジリティの高いサービスを提供するための完ぺきな仕組みを追い求めるよりもインフラ面も含めて小さな改善を早く提供すること、そのためには「デプロイ頻度は高いほうがいい」というアジリティを広く共有できるようになるほうがいい。
続いて2点目は「内外の関係者との会話を怠らない」。スピード感を持ち施策を進められるのは信頼あってのことだ。人事のように重要なシステムの変更となると、顧客が不安を感じるのも無理はない。ここは顧客に寄り添い、賛同してもらえるようにコミュニケーションを怠らないことが重要になる。
さらに3点目は「巨大なシステムでも、小さくまとまった部分なら生成AIを活用しやすい」。巨大なモノリシックなコードを解きほぐすのに現状の生成AIではまだ難しいかもしれないが、小さい範囲なら扱える。CI/CDはその好例で、例えば担当者の退職などで知識が失われたジョブでも、コード化されていれば仕様を調査することができる。コードや開発環境が失われた内製ツール（ビルドに組み込まれているもの）があっても同様だ。デコンパイルして、Copilotに仕様調査を依頼して、リライトしてCI/CDに組み込み直すこともできる。
最後に植野氏は「技術的負債解消と開発者体験向上で価値提供を加速させていこうということで、モダナイゼーションやCI/CDに取り組んでいます。皆さまのお仕事の課題に、私たちの取り組みがひとつでも参考になれば幸いです」と述べた。
