COMPANY V6・V7のサポート終了が2027年10月に迫っている
業務データの中心を担うパッケージ製品COMPANYには、バージョンの期限があります。V6とV7は、提供元のWorks Human Intelligence社によって2027年10月にサポートが終了します。サポートが終わると、セキュリティ対応も受けられなくなります。
期限が近づくにつれて、移行作業が一時期に集中する可能性があります。いわゆる最終駆け込みです。余裕のあるうちに計画を立てた企業と、直前に動き出した企業とでは、移行にかけられる時間も確認できる範囲も大きく変わります。
この記事では、このEOL（サポート終了）への対応を出発点にしています。ただし、話はバージョンアップの手順だけにとどまりません。COMPANYは業務データの中心にあり、勤怠、会計、販売、データ活用基盤など多くの周辺システムとつながっています。本体を新しくすれば、その周りの連携も一緒に動かす必要があります。
この記事では、移行を成功させる鍵が「つなぎ方」にある理由と、その具体策として提案されている「DI標準基盤モデル」を順に紹介します。
本体のバージョンアップだけでは終わらない周辺連携
COMPANYのEOS対応では、次の3点が同時に動きます。
- EOL対応そのもの（サポート終了とセキュリティへの対応）
- COMPANY本体のバージョンアップ
- 周辺連携の見直し（影響範囲、方式、切替手順の再確認）
3つ目の周辺連携では、さらに3つの観点を確認する必要があります。
1つ目はデータ項目とコードです。項目の追加、桁数、コード体系などの差分を見ます。
2つ目は連携方式とタイミングです。ファイル、API、中継処理など、送受信の前提が変わらないかを確かめます。
3つ目は切替とリカバリです。停止、再送、切戻しまで含めて、業務を止めない計画になっているかを確認します。
変更の起点はCOMPANY本体にあっても、影響は受け取る側、送り出す側、運用する人へと連鎖します。そのため、データ連携、業務プロセス、切替・運用の3領域を一体で確認することが欠かせません。日次・月次処理や締め、承認、エラー時の再送、手作業の有無といった業務側の事情も、確認の対象に入ります。
COMPANY本体だけを見ていては、周辺連携の最適化はできません。
V8連携の現状と、Ruby保守という課題
COMPANY V8とのデータ連携は、主に4つのAPIで構成されています。
- 認証用API
- 出力処理実行用API
- 処理状況確認用API
- ファイルダウンロード用API
Works Human Intelligence社は、この4つのAPIを使うRubyの連携用サンプルスクリプトを提供しています。連携バッチはこのスクリプトを使って、COMPANYの認証モジュール、出力処理、ファイル管理モジュールを呼び出し、データ連携サーバーに結果を渡します。
課題は、メーカーが提供するのがRubyのサンプルコードだけという点です。実運用に使うRubyコードの開発と保守は、ユーザーが行わなければなりません。Rubyを書ける要員を維持し続けること自体が負担になります。
連携先が増えるほど、保守するコードも増えます。本体の移行に合わせて、この保守体制の問題も解決しておく必要があります。
1対1接続の限界とデータ連携HUBの考え方
保守の問題をさらに大きくしているのが、システム同士を直接つなぐ「1対1接続（密結合）」です。接続の本数は、システムが増えるたびにN×Nで膨らんでいきます。
直接接続を続けた場合の問題を次の3つに整理できます。
- 1か所の改修が全システムへ波及する
- 連携方式やスクリプトがバラバラになり、野良コード化する
- データの経路が不明確で、アクセスログを統制できない
これに対する答えが、データ連携HUBによる疎結合です。システム同士を直接つなぐ代わりに、間にHUBを挟みます。改修の影響は基盤側のマッピングに局所化され、共通の制御エンジンで標準化と属人化の防止ができます。データの流れとエラーログも、中央でまとめて管理できます。
この考え方が必要になるお客様像を3つ挙げられます。
- 連携コストが高止まりしている企業
- 安全に内製化へ移りたい企業
- サイロ化や密結合で身動きが取れない企業
どの場合も課題の本質は個別のI/F開発ではなく、全社のガバナンスと内製化を支える標準インフラ基盤がないことです。
さらに、人事システムに特化した仕組みとして始めても、ERP、販売管理、生産管理、購買管理、WMSなどを加えた全社共通の基盤へ拡張できる、という構想もあるでしょう。
2か月で立ち上げる標準基盤モデルの中身
中核となるのは、データ連携基盤とフレームワークをセットで提供する「DI標準基盤モデル」です。HULFTメーカーの知見と、データ連携基盤の構築・運用の実績を土台にしています。基盤は2か月で提供されます。
基盤の全体像は、AWS上に置くデータ連携HUBです。オンプレミスの基幹システムや社内データベース、クラウド上の業務システムと、外部SaaSや取引先などの外部環境をつなぎます。Salesforce、kintone、Boxなどの外部SaaSも対象です。
標準で備える仕組みは、次の4つに整理されています。
- セキュリティとネットワーク：AWS Private Linkによる閉域接続で、データをインターネットに露出させません。DEV、STG、PRDの3環境を論理的に分離します。
- エラーハンドリングと2層障害通知：現場宛てのアプリメールによる即時アラートと、管理者宛ての基盤障害アラートを分けます。ログは一元化されます。
- リカバリ性と冪等性：一時的な通信エラーには共通のリトライ制御で自動再実行します。手動リランも標準化し、手順書に沿って現場で安全に復旧できます。
- 保守性の向上：基盤側にはデータ形式の変換と伝送だけを持たせ、業務ロジックを入れない原則です。対向システムが改修されても、基盤側への波及を防ぎます。
これを「金融・基幹標準をクリアする環境」と位置づけています。
共通フレームワークと手順書で進める内製化
標準基盤モデルのもう一つの柱が、I/F共通フレームワークです。すべてのI/Fが、同じ1本の標準メインフローで動きます。流れは、開始、受信、変換、送信、送信後処理、終了の6ステップです。
各ステップの制御は共通フレームワークが担います。パラメータの参照、部品の呼び出し、戻り値の判定（正常、警告、エラー）、ログ出力、アラートメール送信を一括で制御します。スクリプトの改修は不要で、実装スタイルが標準化されるため属人化も防げます。
個別に開発するのは、対向システム固有の接続、文字コードやフォーマットの変換、項目マッピング、バリデーションといった「差分」だけです。
完成済みの共通フレームワークを適用することで、従来の個別スクラッチ開発を100%とした場合の開発工数を70%にできます。同じエラーハンドリングとログ出力が保証されるため、品質も均一になります。
さらに、ツールを入れるだけでは現場が事故を起こしやすい点にも対処しています。導入定義書・構成仕様書、開発・リカバリ手順書、設定台帳（CSV）を、ドキュメント一式として標準納品します。手順書がそろっているので、外部SIerへの高額な発注をやめ、自社での内製や安価な運用チームへの移行を安全に進められます。
HULFT Squareで得られる導入効果
実装に使うのは、クラウド型データ連携プラットフォームのHULFT Squareです。オンプレミスやマルチクラウドに分散したデータの連携を一元化でき、REST APIによってCOMPANYとも接続できます。V6・V7を含む既存資産を生かした連携が可能です。
HULFT SquareはGUIで実装します。処理は数個のアイコンで組めるため、ノーコードで実装でき、開発や保守の要員を確保しやすくなります。先に見たRuby保守の課題に、直接答える特徴です。
実績ベースの効果は、次のとおりです。
- 開発期間：6か月から4か月へ
- 開発費用：30%縮小
- 年間クラウド利用量：10%縮小
- 保守コスト：10%縮小
- 内製開発：60%を実現
開発対象を最小化して期間を縮め、標準化によって品質向上とコスト低下を図り、稼働後の保守性と拡張性を確保する、という流れです。ConcurやSalesforceなど、多数のSaaSとの接続を補える点も挙げられています。PoCからすぐに始められるサービスでもあります。
さいごに
COMPANY V6・V7のサポート終了は2027年10月です。移行の成否は、本体だけでなく周辺システムとのつながりを止めずに切り替えられるかで決まります。
この記事で紹介したDI標準基盤モデルは、データ連携HUBによる疎結合、共通フレームワーク、手順書一式を組み合わせて、基盤を2か月で立ち上げるものです。HULFT Squareのノーコード実装と合わせて、Ruby保守の負担を減らし、内製化へ進む道筋をつくります。
まずは自社のCOMPANY周辺にどのような連携があるのかを洗い出すところから始めてみてください。
期限までの時間を有効に使うために、早めの一歩をおすすめします。