技術情報

技術情報

「業務パッケージは使うことが目的なので技術論は関係ない」と思われるかも知れません。私たちがここで申し上げたいことは、販売、購買、在庫などの基幹業務は、各社ごとに異なるのが現実で、どうしても個別対応(個別開発)する必要があるのです。ですから、開発技術を用いて如何に、安価に個別対応できるかを主張したいのです。

「オンネット統合業務」は、販売、購買、在庫、生産業務を連動させるシステムで業務自体は普遍的なもので新しさはありません。しかし、今日、これら業務を稼動させる「コンピュータ利用環境が劇的に安価になった」という背景があります。当社の技術は、これらの時代変化の上に、如何に安価に高機能システムを構築するかということです。そのために、プログラミングを職人的作業からなるべく工業製品に近づけることを大切にしているのです。そうすることで、システム製造を効率的に行なえ、その結果、業務機能の高度化に割ける時間を多く取れると考えているのです。

以下の資料は、標準化した技術を文書化(本ページを詳しく述べたもの)しています。ここで申し上げたいのは、「標準化した基盤」により「オンネット統合業務」または、その他の(各社が保持する)業務システムを目新しい技術追及(AI、IoT、スマホ、3Dプリンタ、ビッグデータなど)ではなく、効率化目的である業務が持つ普遍的機能に着目し効率的に、構築したいということです。


    クラウドの積極的利用(経済合理性と安全性の追求)

  • 「オンネット統合業務システム」は、利用環境を選びません
  • クラウド利用の前に、当社が推進する3層システムについて説明します。この3層システムは、クラウド利用、自社設置利用の別を問いません。TCP/IPのネットワーク上にどこでも配置できるのです。
    3層システムとは、プログラム機能を、①「表示部(画面部)」②「業務処理部」③「データベース部」に分けて構築し、そして各機能を疎結合することです。現在、スマホ、タブレットと議論が賑やかなのは①の部分です。ここは、技術進歩というより製品開発が盛んです。当社は、逆に②、③の部分を重視しています。技術変化が少なく、継続性がありますから将来が見通せます。この②、③の部分をクラウド側に配置し、①の部分を高性能になったローカル側PCに配置しています。①の部分は、インストール作業というよりファイルコピーで全国、世界中どこからでも②、③がVPNで安全に利用できます。

    インストール形態

    3層モデルで構築すると上図の様にネットワーク上にそれぞれの層(、①「表示部(画面部)」②「業務処理部」③「データベース部」)を自由に配置できます。現在は、左から2番目の方式でAPサーバをクラウド上に配置しています。画面APは、ホルダコピーのみですぐに利用できます。画面表示は、高性能になったローカル側PCで処理するため、画面表示によるサーバ負荷を低減できる点で理に適っています。

  • クラウドを利用する合理性
  • 当社に於いても「クラウドシステムは、結果的に高価ではないか」という考え方がありました。しかし数年の実際運用を通じて、コンピュータ運用コストを劇的に抑制できることが分かってきました。当社は、主にマイクロソフト社のAzure(東日本、西日本)を利用しています。その中でクラウドを利用するためには若干のテクニックが必要でした。一番大きな項目は、ネットワークのVPN化(仮想私設網)です。VPN化して始めてクラウド側と自社ネットワークの境界がなくなり、社内ネットワークの延長線上(無意識)でクラウド側サーバが利用できます。次に重要なのがバックアップです。Azureは、データ同時6重書き(大阪、東京の地理的冗長)込みですから瞬時的にはデータの消失は無いものと判断しています。しかしながら、本日から3営業日前のデータに戻すという世代管理は、利用者側で実施する必要があります。弊社は、システム運用業務全般を理解し、クラウドシステムを利用しています。


    システム製造技術の標準化(汎用機、オフコンからの学習)

  • なぜ、今の時代に汎用機、オフコンか
  • 私たちの技術追求は、まず、「利用対象の業務を知ること」が最初です。その業務を「単純に」、「確実に」、「安価に」に構築することを追求しています。そのことは、職人技を排し、標準化し、システム製造(主にプログラミング)を工業化することなのです。今の情報処理技術(最近はITとかいう。またICTとかいう言葉も現れた)は、タブレット、スマホ、AIなどの技術風用語に溢れていますが、そこを追いません。かつての汎用機、オフコン技術(世間はレガシーとして、化石技術の様に呼んでいますが)に学んでいます。かつての利用技術の上に超安価になったコンピュータ、ネットワークを適用しようとする考え方です。例えば当社では、「タブレット」を「キーボード利用ができない場所で使うコンピュータ」と定義し、中に入れるシステムに大きな変化は無いと考えています。

  • オンライン、バッチ、帳票の分離と自動生成
  • 私たちの開発手法は、20年前の汎用機、オフコン開発を基盤にしています。理由は、機能分離が明確で、プログラミング技術の追求より業務機能、情報構造からのシステム構築手順であるからです。作成する業務機能が決まると、まず、データ構造を定義します(DB設計)、②次に処理形態に応じてを次の3種類の方式に分けます(①画面からDBに登録するプログラム(オンライン)、②DBのデータを処理する画面を伴わないプバッチログラム。③プリンタから出力するプログラム(帳票))。こうしてシステムを開発すると「いつでも同じ方法で業務プログラムを効率的に作成する」ことができます。

    プログラム生成

    左図は、データベース定義と画面プログラム製造の関係を示しています。画面は、一覧部(検索部)と
    基本部、明細部に機械的に分解しています。画面部は、WEBサービス(SOAP)により業務ロジックに接続されますが、このWEBサービスの雛形は自動生成されます。ですので、業務ごとの固有ロジックの組込みのみが作業となります。「③プログラムの定型化」とはこのように、画面の製造に於いてプログラミング方式を固定化していることを指しています。尚、画面プログラムの起動は、「オンネットメニュー」により行ないます。
    画面から登録されたデータをバッチプログラムで処理します。バッチ処理の殆どは、SQL文の連続化により作成します。SQLを連続化する仕組みをオンネットSQLSequencerというツールを作成しています。
    バッチプログラムの起動には「バッチプログラムのスケジューラ(オンネットジョブマネージャー(OJM))」が使われます。
    これらの技術は、外部ツールを利用せず、自社技術で完結しています。

  • データベース項目の日本語化と項目開示
  • 業務システムは、「データ項目とその構造」によって表現できます。当社では、それをERD(エンティティリレーション図)で表します(抽象化します)。そして、その項目に日本語を用いています。SQL文は、この日本語(漢字)で記述しますので、自然に日本語プログラミングとなります。データ項目を意味理解できる日本語で貫いている着眼点が技術と思っています。英文でもいいのですが、データを構造化するのに足りる(英語の)言語教養がありませんので、日本語としています。そして、この日本語データベースを利用者に提供しています。

  • リモート保守体制の保持
  • 当社は、インターネットが繋がる環境であれば、どこからでもリモートメンテナンスできる環境を整えています。このこと自体は、当社の技術ではありませんが、システムのメンテナンス性を高める工夫をしています。例えば、「フォルダコピーのみでインストールできる(レジストリ書き込みをしない)」「説明手順の整備(オンライン説明用)」などです。
    具体的には、利用者側PCの画面を東京からリモートで操作することで、操作方法説明や問題点解決が可能です。

  • システムの継続性が重要
  • システムを長く使い続けるために、変化の少ない技術を利用しています。決して、不見識に新しい技術(方法論?)に飛びつきません。この見極めが技術と考えています。変化が少ないと考えられる①OS、②データベースとSQL文、③普及しているプログラミング言語を継続的に利用しています。この範囲以外の技術は、余程、気をつけないと数年で、途絶えるケースを幾度も見てきました。

    「オンネット統合業務」はシステム開発基盤

  • 開発基盤とは何?
  • 業務システムを構築する場合は、その開発者が同じ環境、手順で構築する必要があります。「オンネット統合業務」は、以下に挙げるシステム基盤(以下、開発基盤)を前提に構築しています。本開発基盤は、「オンネット統合業務」の機能範囲はもちろんのこと、それを超えて、各社で自由に利用することも可能なのです。

  • 汎用メニューとJOB管理
  • 画面プログラムは、メニューから起動されます。バッチプログラム(画面を持たないプログラム)は、JOB管理(スケジューラ)から起動されます。メニューは構成定義体により自由に構成でき、JOB管理は、予め設定されたスケジュール(本店、支店などの複数カレンダ)によって動作します。実行の正常性はログにより確認できます。

  • プログラム、データの自動配布
  • 「オンネット統合業務」は、画面部はPC側に配置されます(データは一切保持しません)。理由は、基幹業務を(配布不要な)HTML画面のみで行うと操作性が落ちるためです。その際、画面部PC配置で必要になるのがプログラムの自動配布機能です。「スマホのアプリ更新の様に」行うためです。自動配布は、プログラムだけでなくエクセル表、マニュアルなども配布できますので、業務全体の効率化に寄与します。

  • バッチ処理の作成
  • バッチ処理とは、画面の無いプログラムのことです。当社では、このバッチ処理をSQL文の連続化で作成しています。COBOLプログラム800本をすべてSQL文の連続化で代替した経験もあります。この連続化を高度化(ログ出力、条件分岐など)する目的でSQLSequencer(以下、SQLS)というツールを準備しています。作成したバッチ処理をJOB管理で実行すれば、業務処理を高度に自動化できます。

  • WEBサービスの作成支援
  • 前述のとおりです。①業務で扱うデータに着目すればDB構造(テーブルの親子関係)が決まる。②DB構造が決まれば、画面の構成と、それから利用するWEBサービスの構成が決まります。そのWEBサービスの自動生成ツールを準備しています。100%とは行きませんが、60%以上の生成感です。大きな工数削減に寄与します。また、開発者がみんな同じ方法でプログラミングすることになる効果も絶大です。


    「オンネット統合業務」は小さなプログラムの集まり

  • 業務コンポーネントの利用
  • 「オンネット統合業務」のプログラムは、画面単位(メニュー実行単位)、バッチ単位(JOB管理登録単位)に分割して構築しています。このことは、意外に有用で会社ごとの機能変更が簡単にできます。例えば、受注画面のみ変更するとかです。そうすると複数の受注画面がシステム資産として蓄積されるので、場面によって再利用が促進されます。世間では、これをSOA(Service Oriented Architecture)サービス指向構造と呼んでいます。「小さなプログラム群による再利用性の向上施策」などとした方がより伝わると思いますが(余談)。