Tojo Management Science Laboratory

Access/Web

 Access/Webによる業務画面例

Accesswebによる業務画面例

◆Access と Access/Web

小規模システムにAccessは広く使われてきましたし、現在もそうだと思います。IT専任でなくてもので、技術の習得ができ生産性の高い開発ツールとして採用されてきました。2013年にAccess/Web(Access 2013)が発表されて、Accessは大型Webシステムの開発にも対応できるようになりました。さらにOffice365下にAccess/Web環境ができたのは、費用をかけず自社開発を可能にする画期的なものでした。

しかしながら、2017年春『Office365下でのAccess/Webのサポート1年後(2018春)まで』とのマイクロソフトの発表があり、残念なことです。もちろん、Azure下や、個別システムではAccess/Webを使い続けることはできますが、圧倒的に安価というわけにはいかなくなりました。

このような事情から、弊社では、Access/Webを強くお勧めいたしてはおりません。

以下は、Access webにつきまして、その優位性を解説いたしたものです。御参考にご紹介いたします。

◆Access/Web

Access/Webは超高速開発ツールのひとつです。

弊社では、Access webは「超高速開発」の道具立ての一つであると考えています。
理由は、文字通り、開発の生産性が大幅に高まるからです。以下にも述べていますが、
一般のプログラミング言語による開発に比し、10倍位の生産性向上が期待できるものと考えています。

Access/webとは

Accessは、よく知られているとおり、1980年代にマイクロソフトにより開発され、全世界的に広く普及しています。極めて多くの中小企業様により、採用されており、多くの業務に適用されてきております。その分野は会計、給与計算、販売在庫管理、生産管理等、およそ、企業の基幹システムと呼ばれているシステムに対して、極めて多くのユーザがあります。

一言にして言えば、データ・ベースを中心として、業務に特化するために、画面設計、計算ロジックの設計、検索、集計処理などを、やさしく一般の皆様でも使えるように考えられています。

一方、Accessはプロの開発者でも使いたい機能も合わせもっています。これらは一般にVBAと呼ばれますが、プログラミング言語そのものです。これが使えるため、相当大きなシステムでも対応することができます。大企業様でも特に、部門システムでは、よく使われています。

Access 2010が発表されたとき、今までの機能に新しい機能が追加されました。それは 1.データマクロの追加 2.Web化の機能追加 これは画期的な追加でした。

しかし、残念ながら、あまり普及しませんでした。理由は、Web化の機能追加は、普通のAccessを開発して、それを、Webに発行するという手順で行うことになっていました。このこと自体は非常に素晴らしい考え方であったと思います。何故なら、今まで通りに作って、ただ、ボタンを押して、Webにする、というだけで、Web化ができてしまうということになるからです。しかし、現実はそうなりませんでした。Web化できるためには、元になるAccessはその範囲で作らないと、エラー続発となってしまう状況でした。現実のWeb化の壁は厚かったのです。

続いて、Access2013が発表されたとき、Web化の方法論は全く変わりました。いきなり、Web化の開発環境の下で、直接、Webシステムを開発することになりました。旧来のAccessの開発の下に行うのではない、ということになりました。ここに実用的な、AccessのWeb開発方法論が確立することになり、現実的なものなったといえます。ようやく使えるものになったということです。

プログラミング言語からの解放

基幹業務を開発するためには、コンピュータのプログラミング言語が必須である、と思っている方々が大半です。しかし、Access Webではプログラミング言語がそもそもありません。プログラミング言語がない、ということが、極めて大きな特徴であると同時に、開発の生産性を大きく高める要因のひとつになっています。そのなバカな、という方が多いのは事実です。なぜなら、金額=単価x数量といったような演算を行わせるためにプログラミング言語が必要ではないかという考え方をもっておれれる方はそのように反論されるわけです。

Access Webではこういった業務処理のことをルールと呼んでいます。ルールは、データマクロというものを記述することによって行います。データマクロはプログラミング言語ではありません。記述の方法は、おおむね、日本語のわかりやすい記述方法がありますので、それにしたがって記述します。

一般的にプログラミング言語によって、業務を記述する場合、いつそれを起動させるのか、起動させるためには、何を準備しておくのか、といったような、細かいコンピユータ処理上の手順を記述していくことになります。経験的には、これらのコンピュータの技術的処理部分が、8割で、実際の業務処理の部分は2割といわれています。

Access Webの場合、このような、起動処理や、その他コンピュータ処理にまつわる部分は全て、Access Servicesがやってくれます。開発者は、このような厄介な処理に悩まされることなく、業務処理に関連する部分だけ記述することになります。いわば8割部分は書かなくてもよい、ということになります。

この機能のおかげで、プロでなくても、2日間程度、勉強すれば、使えるようになり、大幅な開発生産性の向上が期待できるわけです。

DOAとPOA

1960年代にも多くの基幹業務システムが開発されました。この時代には、どんな処理が必要なのかをまず考えました。その処理に必要なデータをファイルとして定義し、これらの処理の繋がりでもって、基幹システムを開発していました。この方法論のことを「POA」Process Oriented Approachといいます。現在でも、一般の業務を担当しておられる方には、この考え方が広く普及しています。わかりやすいからです。

一方、1980年代頃から、ITの世界では、「DOA」Data Oriented Approachが主流となってきました。現在では、ITの開発方法論の主流は原則、「DOA」です。DOAが当初叫ばれた時代には、色々なシステムが、POAにのっとって、個々バラバラに開発された結果、データの重複があちらこちらにみられるようになり、収拾がつかなくなっていたのを解決する必要があったからです。わかりやすくいえば、給与にも社員情報がありますし、販売管理にも社員情報がある、さらに会計にもある、仕入先も販売先もあちらこちらにあって、何がなんだかわからない、という状況を解決する必要性にせまられたのです。
それがDOAのそもそもの発端でした。

一方、現実には、画面がないと仕事ができませんし、一般ユーザには、データという見えないものより、画面の方がよっぽど、現実的です。そこで、データと画面の関係や、それを動かすプログラムとの関係などを分析する手法が発達していきました。それらを総称的に「DOA」と呼んだのでした。

しかし、時代は変わります。データを定義すると、何とか、該当する画面を自動的に生成し、かつ、必要なプログラムを自動生成できないかという、動きが起こります。1980年代の後期からこれらのための専用の道具立てが整備されていくことになります。イスラエルで開発されたSapienceやウルグアイで開発されたGenexusなどがそれに該当します。

Access Webもこの流れの中にあります。したがって、Access Webも広い意味で「DOA」の範疇に入ります。マイクロソフトでは、この点につきましては、「Data Centric Design」と呼んでいます。この言葉は日本では普及していませんが、DOAと思っていただいても結構です。

すなわち、Access WebはDOAの流れを汲んでいる、と思っていただいて結構です。

自動生成

それでは、Access Webの場合、何が自動生成され、また、何がその役割を担っているのでしょうか.Access Webで業務を開発する場合、開発者は、Access Servicesに対して開発内容を依頼します。Access Servicesは依頼された内容を解読し、必要な自動生成処理を行ないます。結果は、プログラムが生成されるのではなく、仮想コードを生成し、それは、その業務のアプリとして、サーバ上に置かれます。

サーバとは、具体的にOffice 365の場合、SQL Azure データベースということになります。開発者はこのサーバのことを管理、ないし、意識する必要は全くありません。勝手にやってくれます。知らないうちにできているということです。

具体的には、以下のようになります。データ、すなわち、その入れ物であるテーブルを定義します。細かく言いますと、主キーが何であり、外部キーが何であり、必要なデータ項目(これを属性といいます。)である社員番号や、住所、氏名、誕生日といったものを定義してやります。そして、保存ボタンを押します。そうしますと、サーバ側にいるAccess Servicesがそれを解読して、必要なテーブルを作ってくれます。

さらに、必要な画面を二つの形式で作ってくれます。一つは一覧形式(エクセルのようなもの)他の一つは、単票形式です。この各々を、データシートビュー、リストビューといいます。さらに、これらの画面にデータを入れ、テーブルに保存するためのプログラム(トランザクション)も自動生成してくれます。このプログラムは、検索、追加、削除、変更といった、基幹業務上必須の機能を生成してくれます。

プログラムを自動生成しているとはいいましたが、実体はありません。全てAccess Servicesが同時に実行エンジンとして機能する働きをもっています。Access Servicesは、一種のコンパイラの機能をもっていると同時に、実効を司るエンジンでもあるのです。Access Servicesは賢い働きをもっています。

弊社の別ページでSapienceの紹介をしておりますが、Sapienceの場合、このプログラムのことをOperationと呼んでいました。Access Webの場合、眼に見える形でこういったものはありません。Access Servicesが勝手にやってくれます。開発者は全く意識不要です。Sapienceの場合、operationは結構開発者が意識しています。それを基にして、色々なことを考えます。Access Webの場合、割り切っています。Operationを開発者に意識させません。どちらが良いかは、判断のできない問題です。どちらにも、長所があります。

データドリブン・アーキテクチュア

Access Webには、データマクロを使うということがありますが、それを使う局面は、データが変化したとき、ということになります。このデータが変化したときというのは、極めて重要な概念です。一般的にデータが変化する局面は、①データ挿入後、②データ更新後、③データ削除後の3つの場合です。新規データが作成されたときは、明らかに、データが変化しています。同様に、今まで記録していたデータが何らかの理由により、例えば、数量が変更されるような場合、データが変化したことになります。

データドリブンアーキテクチュアの場合、データが変化したとき、そのデータをテーブルに書き込もうとします。このタイミングで、ちょっと待てといったことになり、変化したときに必要な処理を書いたデータマクロを実行しようとします。実行が完了すると、テーブルに書き込むようにします。すなわち、データが変化したときに、データマクロに記述されたビジネスルールを実行しようとします。

わかりやすくいいますと、ユーザは商品コードとその受注数量までを入力して保存ボタンを押します。その瞬間、データマクロでは、商品コードを参照して、単価をもってきて、その単価と受注数量を掛けて、金額を計算する、というような処理を、データマクロで記述します。Access Servicesはこの一連の処理を実行制御します。すなわち、保存ボタンを押すと、テーブルが変化しますので、その変化したタイミングで、データマクロを起動させます。実行が完了すると、テーブルにその結果を書き込みます。これらの順番制御は、開発者の関知するところではありません。

全て、Access Servicesがやってくれます。開発者は、変化したときに実行すべき、業務ルールをデータマクロで記述するだけです。制御にまつわるコンピュータの技術的処理は開発者の関心事ではなくなります。

旧来のプログラミング言語処理では、これらの制御手順を厳格にプログラマが書かなければならなかったのとは大きな違いです。これが、開発生産性を高める最も大きな要因です。

弊社では、この生産性につきまして、特に実測はしていませんが、常識的に考えて、Access Webがもっている他の便利な機能と合わせ考えると、10倍の生産性があるものと考えています。10倍とは、約2週間かかる開発期間が1日になるということです。大体こんな感じだろうと思って使っておりますが、実体験とほぼ一致しています。

トランザクション連携

データマクロは、一つのテーブルに対して、原理原則、挿入後処理、更新後処理、削除後処理、という3つの局面で、ビジネスルールを記述します。すなわち、テーブルは、自分のデータ並びに処理の方法をカプセル化していることになります。いつこれらが起動されるかは、全てAccess Servicesの監督下で
行われます。開発者は意識する必要がありません。

データマクロは、他のテーブルからデータを読み込むという機能もありますし、それに合わせて、自分のテーブルの値を更新するという機能もありますが、さらに、他のテーブルを更新するという機能ももっています。これは極めて重要な関心事です。意味としましては、以下のような例がわかりやすいでしょう。受注業務があるとします。受注しますと、当然、受注内容をテーブルに書き込みます。さらに、在庫を更新させることができます。

そうしますと、在庫テーブルでは在庫の数量が変化します。在庫の数量が変化しますと、在庫につけられたデータマクロが自動起動します。このとき、在庫数量が安全在庫を割ったとします。そうしますと、在庫テーブルにつけられたデータマクロは、発注準備というテーブルを更新させることができます。そうして、1日が過ぎた後、発注準備というテーブルを参照すると、発注すべき品目がわかりますので、それを別途、発注処理する、というようなことができるようになります。

これらの処理を従来のプログラミングでやってもできないことではありませんし、事実色々な方法でやってきています。しかし、Access Webでは、実に簡単にこういった処理を実現できてしまうのです。本例では、受注トランザクション、在庫トランザクション、発注準備トランザクションが3つ動作していると考えることができます。このように3つの関連するトランザクションのことをトランザクションが連携されていると表現します。そして、Access Servicesはこれらトランザクションの連携を管理してくれています。

今の例で、在庫のところのルールで、マイナスが発生した場合、商品を提供できなくなりますので、この受注はお受けできないということになります。この場合、在庫から、Errorを生成するようなデータマクロを記述することができます。このようにしますと、画面には、「その受注はお受けできません」として、メッセージを送ることができます。さらに、受注データをロールバックさせてしまいます。画面には入力した値が表示されていますが、受注テーブルには何も書き込まれていないことになります。

さらに、発注準備において、その商品が受注停止になっているというような場合には、ロールバックさせずに、受注準備ファイルにメッセージのみを送るというようなこともできます。受注停止になっていますので、対策を考えてください、というようなメッセージを送ればよいでしょう。

このトランザクション連携はしばしば、活用されています。販売在庫管理システムから、会計へ自動仕訳するときにも、この方法を使います。データを入力している担当者には、背後で、自動仕訳していることは全くみえません。弊社ではこのようなことを称して、リアルタイム会計と呼んでおります。

検索機能

これも、弊社の見解ですが、一般に基幹業務を開発する際には、新規作成や、変更処理、削除処理の画面を適切に開発いたします。特に、変更や、削除処理を行なう場合、該当するレコードを特定するために検索をする必要があります。例えば、受注の変更をする場合には、一般的には受注番号で検索する、といった感じです。しかし、検索は、このようにひとつに固定されるものではなく、ユーザ様とお打合せをして、どのような検索をするのか、決めます。それに合わせて、検索するための画面を用意し、そこから該当のレコードを画面に表示してやることになります。

開発している方々にとりましては、色々な経験をしておられると思いますが、この打合せと、開発作業は結構な時間を要します。各画面毎に検索のスタイルが変わりますので、それに対応することも必要になります。

Access Webでは、リストビューに対して、検索ボックスが提供されています。この検索ボックスは、全文検索の機能をもっています。しかも、高速処理を行ないます。使ってみますとなぜこんなに早いのか驚く程です。この検索ボックスには、例えば、受注番号を打ってもよいですし、その一部を打ってもかまいません。該当するレコードが複数個表示されます。勿論、日本語を打ってもOKです。

あるいは極端な話、金額や日付けを打ってもかまいません。該当するレコードを検索して表示してくれます。しかも、この画面は新規登録にも使えますし、変更登録にも、削除登録にも使えます。わざわざ、各専用画面を開発する必要がありません。実はこれも開発生産性を高める要因の一つになります。通常は、この検索ボックスで、間に合うことが大半です。勿論特殊な検索が必要な場合には、それに対応させて開発することもできます。

さらに、Access Webにはオートコンプリートという機能があります。これは画面のひとつのコントロールのタイプです。ここには、例えば、商品コードの一部をまず打ってやります。そうしますと、該当する項目が8ヶまで表示されます。それをみながら、さらに、コードを深く打っていきます。そうしますと、いずれ該当項目が絞り込まれて、検索が完了することになります。これは非常に便利な機能です。

この機能を拡張しますと、バーコードなどをバーコードリーダで読ませると該当する商品が直ちに検索できます。バーコード読み取りは通常読み取り機器が、キーボードエミュレータを搭載していますので、キーボードから打ち込まれたと同じことになり、オートコンプリート機能は、該当商品を直ちに、表示してくれます。何らかの読み取りのためのルールは一切記述する必要がありません。これもシステムを開発するときに結構重宝します。

このように、Access Webは検索するための機能に関して、統一的な回答を用意しています。開発者はこれをうまく使いながら、生産的にシステムを開発することができるようになります。

まとめ

以上の観点よりまとめてみますと、Access Webは、中小企業様の基幹業務、あるいは、大企業様の部門業務を開発する場合に極めて生産性高く使用できるツールということになります。日本では、まだPRが十分でなく、各種フォーラム等をみていましてもこれからという感じです。

やはり、Office365のサポートがなくなるのは残念だと思います。

PAGETOP
Copyright © 東條経営科学研究所 All Rights Reserved.