はじめに

最初に「オンネット統合業務（主に販売、購買、在庫）」における「利用対象者の広がり」について述べます。

2010年頃まで業務のシステム利用は、「社内」の範囲でした。利用者は、社員、受入れ出向者、派遣者が主でした。しかしこの社内利用は、今日、①利用場所の観点、②利用者属性の観点で考える必要性が出てきました。利用局面（移動中、自宅、取引先などに）が拡大したのです。「働き方改革」「コロナ禍」によって、その流れは加速しました。「オンネット統合業務」も①、②の観点について対応を迫られました。

例えば①の観点（利用場所）では、社内領域、取引先領域、テレワーク領域、不特定利用領域、②の観点（システム利用者）では、社員、取引先（個人、法人）、受入出向者、不特定多数者などで考える必要性が生じてきたのです。「オンネット統合業務」も、拡大する利用局面に対し、マスタ統合、認証・認可、利用デバイス対応を整備してきました。2015年前後からの試行錯誤の結果、2023年後半に一応の整備が完了し、マスタ統合やこれまでのソフトウエア資産の再利用を図りながらサブシステム利用を開始しています。

■「統合業務の利用形態と認証_業務ロジック_データ統合」
※画像をクリックするとPDFファイルが開きます

説明の全体整理

上述①と②を考える時、システム環境として「オンネット統合業務」利用では、利用者画面は三つあると考えています。（A）Windowsデスクトッププログラム、（B）WEBブラウザ、（C）スマホアプリです。共通して利用されるサーバ側プログラム、ＤＢは区別なく使えることを前提にしていますので、方式による個別開発を抑制しています（「オンネット統合業務」では過去のプログラムを再利用、共通利用しています）。

（A）Windowsデスクトッププログラム

「オンネット統合業務」の主たる画面方式です。一般には、（B）（C）が優れていると感じる方が多くいると思いますが、基幹業務で必要となる複雑画面は、本方式で作成するのが良いと考えています。世界中どこからでも使えますが、安全な場所からの利用が前提となります。ＩＰアドレス、ＵＵＩＤで制限しています。
欠点としては、Windows PCが必要、PC側にプログラムをダウンロードしなければならない（運用中は自動ダウンロードなので、意識する必要はありませんが）ことです。
これは、各社のセキュリティポリシーを意識する必要があります。ただ、以降で述べる（B）（C）方式とは異なり、画面間遷移で、セッションが継続管理されていますので、セッション情報の「盗聴」が無いことも考慮すべきと思います。合理的に安全性を確保できるという点です。

（B）WEBブラウザ

この方式は、ブラウザさえあればどこからでもシステム利用が出来る点、利用者側端末に固有プログラムの配置が不要な点で、他方式に比べ、一番優れていると評価されています。
しかし、複雑画面を作成することに大きな工数を要すること、ローカル側の外部インターフェース（カメラ、GPSなど）利用にＯＳ差異を考慮する必要があるなど、難しさがあります。画面遷移時のセッション維持と、その情報の外部漏洩問題を意識する必要もあります。
ここ３年間で、ブラウザ互換問題の解消、SPA（シングル・ページ・アーキテクチャー）などの整備が進み、複雑画面の作成が徐々に可能になってきています。セッション維持情報の「盗聴」には最大限の配慮が必要です。

（C）スマホアプリ

この方式は、複雑画面、操作性は、（A）（B）の中間になると考えています。ただ、画面利用は主にスマホに限定されるのではないかと考えています。スマホ画面を前提に考えると、表示項目は縦スクロールで、業務利用における表示項目数に問題は、大きく改善されたと思います。しかし、入力項目数は、タッチ入力なので、PCに比べ、操作性が悪くなります。 また、Android、iOSのOS差異を意識する必要があります。今日、クロス開発基盤が整備され、かなり改善されましたが、カメラ、GPS制御などの機器制御、プログラム配布方法などで大きな違いが見られます。 このスマホアプリですが、産業機器として開発されているハンディターミナル派生のAndroidスマホがあります。在庫管理などで有用と考えています。

認証・認可整備の重要性

認証とはログインに関する事項です。認可とは「役割」による「利用機能の制限」です。この事を（A）、（B）、（C）で考えた時、（A）を内部認証、（B）（C）を外部認証の二つにグループ分けして考えています。ただ、利用者管理（社員、組織、取引先などと認証・認可情報管理）は、システム全体でマスタ管理されていることが重要です。この管理は（A）で行っています。そして（A）（内部認証）の内容を（B）（C）（外部認証）に転写しています。転写する利用は、内部認証と外部認証の認証方式（仕組み）が違うためです。

認証・認可は、システム利用の前提で重要です。しかし（B）（C）利用において、アクセストークン利用の流れが定着してきたため、その流れに対応する必要性が生ます。これは利用領域が外部に広がり、利用場所でのセキュリティ確保（（A）の方式）では対応できなくなったからです（ゼロトラストの考え方）。
「オンネット統合業務」は2021年より、（B）（C）を外部認証として整備して参りました。この整備が完了したので、（A）（B）（C）方式に対応した認証・認可環境による「オンネット統合業務」開発が可能になりました。
「勤怠打刻」「データ配布」「購買EDI」など、（A）方式による基幹業務と連動しながら機能拡張を続けています。

関連企業を含む利用範囲

利用企業の中では「オンネット統合業務」を「グループ内で利用したい」などの要請がある場合を経験しています。形態は２パターンあります。①「オンネット統合業務」の利用環境を複数設けて利用、②ログイン者範囲を社外者にも拡大して利用、です。

①の場合については、利用環境（仮想サーバとDB）が複数（インストールプログラムは同じが前提）であっても単純にログインIDカウント課金となります。サーバ単位の「B．カスタマイズ保守料金」は不要です。
②の場合はログインIDのカウントで対応できます（社外利用ID管理機能を装備）。

利用者と認証の関係説明

前述までの「利用者と利用場所」と「利用者画面」の関係を表にしました。「オンネット統合業務」はこの表のすべてで機能提供が可能です。しかし、認証・認可機能が整備されているとはいえ、社外環境への情報開示は限定的であるべきと考えています。当社では、概ね下表の様に考え運用しています。各社への適用に当たっては、この表の縦・横関係を検討することになります。

マスタとサーバ機能の共通化が重要

上記の表の通り、システムの画面提供方式は異なります。しかし「オンネット統合業務」は、画面提供方式が異なっていてもシステム全体でマスタは共通化しており、コードは完全統一されています。マスタ管理は（A）方式で集中管理しています。個別に（B）（C）方式で個別管理する事はありません。（B）（C）方式には、転写で同期しています。
また画面提供方式が異なっていても、サーバ機能（HTTPSで動作するサーバプログラム）も「なるべく」共通化しています。この「なるべく」、と書いたのは、画面プログラムとサーバ機能の接続方式がSOAP、WCF、RESTなどに変化してきた経緯があるためです。しかしこの変化は業務ロジックとは別ですので、業務ロジックはそのまま再利用出来るのです。機械的な変更作業で済みます。

プロダクトライン開発であるということ

「オンネット統合業務」は主に（A）方式で発展してきました。その経緯の中で2015年頃からこれまでの説明の通り、利用局面が広がってきました。そこで（B）（C）方式の機能追加を行ってきました。業務機能の追加は問題ありませんでした。単純に（A）方式の機能を（B）方式に転写することで解決したからです（画面表示のみ変更）。
しかし認証・認可の方式が標準化の流れと共に、高度化されてきました。それに合わせて（B）（C）方式についてその実装を行ってきました。その結果「オンネット統合業務」という商品の中に、「認証・認可」「業務機能」を更新、追加しながら（A）（B）（C）方式の違いなく、求められる業務機能の実装作業を日常的に実施することが可能になりました。この事がバラバラ開発で無くプロダクトライン開発による開発効率化であり、運用の効率化なのです。
「オンネット統合業務」は、新しい流れを採り入れながらも、普遍性のある「業務機能」を継承しながら開発を継続している点を強調したいのです。
現在、2024年ですが、2000年当時のプログラムも稼働しているのです。汎用機（メインフレーム）時代の「業務変化に応じた継続利用」（世間ではレガシーなどとネガティブに語っていますが）を受け継いでいます。