起業後26年となっています。

「自ら作成したシステムをネットワーク上で提供する」の意味を込めて2000年（以下当時という）に「オンネットな世界」、即ち「オンネット・システムズ」と社名にしました。

私たちの提供するシステムは、販売、購買、在庫などの基幹システムです。当時これらのシステムは、大手メインフレーム、オフコンメーカの市場でした。ただ当時、少し風向きが変わり始めていて、中堅ソフト会社によるWindows、Unixサーバに置換が始まっていました。

そんな時代背景の中26年間、中堅ソフト会社より小規模な当社も業務システムを作り続けていました。長期間、開発を継続するためには、一貫した考え方「錦の御旗」が必要になります。以下の考え方を「御旗」にし、取り組んできました。

「プロダクト指向開発」ということ

「プロダクト指向開発」の解釈は、当社の製品体系「オンネット統合業務」の開発・運用体験を継続改善することです。具体的には「いつも同じ方法でシステムを作る（標準化）」と「部品化、再利用」を徹底しました。この施策により「安価に、確実に、高速」にシステム構築することが可能になり、製品体系「オンネット統合業務」も相当に拡大しました。この事が「技術志向であり、その技術で顧客視点（安価、確実、高速）でのシステム開発」に繋がりました。

以上の事は「古い技術基盤で作る」という事ではありません。「プロダクト指向開発」という考え方を大事にし、利用環境は時代変化に対応しています。WEB化、アプリ化、認証の高度化などにも対応してきました。

「データ指向」であること

当社の「データ指向」は、かつてのDOA（データ指向開発）のことです（世間では、データドリブン経営とかが流行っていますが、それとは違います）。この考え方は、30年前のメインフレーム時代に提唱されている考え方です（世間は「レガシー」とネガティブに評しますが）。当社にとって重要な点は、①データ構造を定義する、②データ構造が決まればプログラム構造が決まる、③データ統合するの３点です。

①は、これまでの開発経験がDB定義として蓄積されました。受注伝票、出荷伝票、請求書などのテーブル定義（エンティティ定義）は経験した項目が反映されています。利用者によってこの項目は異なります。例えば売るもの（例えば、ブルトーザーと蒲鉾では違います）、単価決定、値引きの判断項目などもあります。

②については、データ構造の親子関係が決まればプログラムの基本形は同じということです。当社では、プログラム標準としてテンプレート化しています。

③については、一つのDB環境で①、②の作業をしています。結果として②のプログラム（機能）と①のテーブル（データ）が「オンネット統合業務（販売、購買、在庫など）」全体で関連付けされ付けされることになり、データ統合（重複の排除、同じコード利用など）が推進されます。テーブル間は関連付けされ、データ統合されます。

チョット蛇足になりますが、前述、今流行りの「データドリブン経営」は数量、カネの実績が集積され始めて実現されるものです。この実績集計が難しいのです。その難しさが分かっているは「情報処理技術者」でしょう。未経験者が言っているそれは「野球を見たことのない人がダブルプレーを説明する」と同じに見えてしまいます。

付加価値の所在を考える

当社の付加価値は「オンネット統合業務」の開発と運用です。でも「オンネット統合業務」の運用を考えたとき、例えば、ハンディターミナル、サーバ、クラウド環境などのハード、ソフトが別に必要になります。 これらは「当社の付加価値でない」と考え、商流に入ることはありません。 全体提供は「ソリューション提供」と考えられますが、往々にして手数料ビジネスになり、その金額が管理工数に見合わないためです

基幹業務の提供は、経営の安定化を常に考える必要があります。付加価値の所在を考えることで経営の安全性を確保しています。量による経営は行わないということです。 経営の安全性の点で重要と考えています。

今後は、「事業の継続性」（社員、経営者の高齢化）にも目を向ける必要性があります。現在は、開発の標準化により少人数でも業務が行えておりますが、利用者が増える状況において、対応を考慮する必要があります。継続性確保については、当社１社で取り組むのではなく、各社の付加価値（商品、サービスなど）と連携し、規模、商域の拡大を通じて「事業の継続性」を確実化させたいと考えています。

以上が当社の「今日この頃、思う事」です。毎年、少しずつ「オンネット統合業務」の商品力が積み上がってきた実感があります。
本年も以上の取り組みを実施します。皆様と情報交換できましたら幸いです。

雑感

AIは安全保障の話題を含め、ここ数年活発です。私は「少し、話題先行ではないか？」と思っている立場です。しかし以下の点について、個人的に着目しています。実際に実用性があるかです。

会話ができる

問いに対して文書が構造化して示される。これは明らかに技術が進展しており、驚いてます。「パット見、その回答が正しい」と感じます。私は情報処理技術に関して「問い」をしますが、回答は「広告が元になっている気配」があります。だから利用者は、回答が評価できるスキルが必要になる感じです。当然ながら回答を評価できないと使えないという感じです。ただ、検索は便利になりました。でも「AIによって雇用が削減された」は実際には、まだ顕在化していないでしょう。今起こっていることは「AI投資に対して他部門の固定費を単純に削減する動き」と見えています。どうかな？

プログラムが自動生成できる

すごく懐疑的でしたけど試しています。一つはビジネス業務領域について「在庫管理機能において赤黒処理する、入庫画面を作成してください」。この問いは人間では仕様があいまいで、実用レベルのプログラム作成できません。AIの回答も商品、数量、単価、金額程度のプログラムは生成します。赤黒は「マイナスデータで起票し、新規黒を登録」で示されました。企業の業務レベルのプログラム生成は、まだ難しい感じです。

もう一つ、私はアマチュア無線などでマイコン機器の実験をします。そこでAIに「arduinoを用いて、ロータリーエンコーダによるカウントアップ、カウントダウンプログラムを割込み処理で作成してください」と問うと、30行程度のプログラムが感心するレベルで生成されます。これを参考にチャッタリング対策などの処理を加えれば実用的になる感じです。 でもよく評価してみると、githubなどに蓄積されているプログラムを成形して表示している印象があります。繰り返し判断などはAIが理解している感じはありますが、どこまで理解し生成しているか？です。確実に言えることは「調査のための検索は効率的になった」ということです。生成されたプログラムは、動作を確実にトレースする必要があります。

両者から感じることは、

• ・販売、購買などの業務システムを自動生成するのは現段階では困難
• ・組み込みマイコンとセンサー、表示装置（ＬＣＤ）などの仕様が固定化されているものは、検索と最初のプログラムとしては有用

もしかしたら前者はシステム学習用の検索、後者は一歩進んで、必要機能の検索と初期コーディング（30行）は、利用性があるといった感じです。

世の中の記事は具体例で評価しないとよく分かりませんね。実際のプログラム例（実用例）と仕様のやりとりと動作の確実性確認が、人間のプログラミングとテスト時間（工数）の比較が必要ですね。プログラミングを経験していない人が「これからは自動生成される、プログラマーが不要になる」は、「ホント？」です。

※写真についての注釈

もうちょっと服は持ってるつもりでしたが、恥ずかしながら、去年と同じポロシャツを着ております・・・。

2026年 6月10日
代表取締役
システム監査技術者
情報処理安全確保支援士
重永 裕祥

---

自己紹介

昭和30年山口県生まれ。昭和49年現東ソーに入社しました。平成12年8月退社後、当社を創立。東ソーでは、10年間程度化学プラントの運転を行っておりましたが、28歳から45歳まで情報処理部門に配属され、主に事務システムの開発に携わっていました。中でも日立製作所と行ったTIMESと呼ばれる全社基幹システムの再構築（プログラム25000本規模）は大きな経験となりました。40歳からは通信のIP化が急速に進み、ホストコンピュータ通信とIP通信網などのネットワーク構築業務を行っていました。

東ソー時代に経験したビジネス管理手法（組織、手続きなど）は、私に大きな影響を与えてくれました。会社設立の動機は「やってきた事を社外で試してみたい！」という事でした。