Access/Web小規模システムにAccessは広く使われてきましたし、現在もそうだと思います。IT専任でなくてもので、技術の習得ができ生産性の高い開発ツールとして採用されてきました。2013)が発表されて、Accessは大型Webシステムの開発にも対応できるようになりました。Office365下にAccess/Web環境ができたのは、費用をかけず自社開発を可能にする画期的なものでした。2017年春『Office365下でのAccess/Webのサポート1年後(2018春)まで』とのマイクロソフトの発表があり、残念なことです。Azure下や、個別システムではAccess/Webを使い続けることはできますが、圧倒的に安価というわけにはいかなくなりました。このような事情から、弊社では、Access/Webを強くお勧めいたしてはおりません。webにつきまして、その優位性を解説いたしたものです。御参考にご紹介いたします。◆Access/WebAccess/Webは超高速開発ツールのひとつです。webは「超高速開発」の道具立ての一つであると考えています。理由は、文字通り、開発の生産性が大幅に高まるからです。一般のプログラミング言語による開発に比し、10倍位の生産性向上が期待できるものと考えています。Access/webとはAccessは、よく知られているとおり、1980年代にマイクロソフトにより開発され、全世界的に広く普及しています。多くの中小企業様により、採用されており、多くの業務に適用されてきております。企業の基幹システムと呼ばれているシステムに対して、極めて多くのユーザがあります。やさしく一般の皆様でも使えるように考えられています。Accessはプロの開発者でも使いたい機能も合わせもっています。これらは一般にVBAと呼ばれますが、プログラミング言語そのものです。これが使えるため、相当大きなシステムでも対応することができます。大企業様でも特に、部門システムでは、よく使われています。2010が発表されたとき、今までの機能に新しい機能が追加されました。これは画期的な追加でした。残念ながら、あまり普及しませんでした。理由は、Web化の機能追加は、普通のAccessを開発して、それを、Webに発行するという手順で行うことになっていました。このこと自体は非常に素晴らしい考え方であったと思います。今まで通りに作って、ただ、ボタンを押して、Webにする、というだけで、Web化ができてしまうということになるからです。現実はそうなりませんでした。Web化できるためには、元になるAccessはその範囲で作らないと、エラー続発となってしまう状況でした。現実のWeb化の壁は厚かったのです。続いて、Access2013が発表されたとき、Web化の方法論は全く変わりました。Web化の開発環境の下で、直接、Webシステムを開発することになりました。旧来のAccessの開発の下に行うのではない、ということになりました。ここに実用的な、AccessのWeb開発方法論が確立することになり、現実的なものなったといえます。使えるものになったということです。基幹業務を開発するためには、コンピュータのプログラミング言語が必須である、と思っている方々が大半です。Webではプログラミング言語がそもそもありません。プログラミング言語がない、ということが、極めて大きな特徴であると同時に、開発の生産性を大きく高める要因のひとつになっています。そのなバカな、という方が多いのは事実です。金額=単価x数量といったような演算を行わせるためにプログラミング言語が必要ではないかという考え方をもっておれれる方はそのように反論されるわけです。Webではこういった業務処理のことをルールと呼んでいます。ルールは、データマクロというものを記述することによって行います。データマクロはプログラミング言語ではありません。記述の方法は、おおむね、日本語のわかりやすい記述方法がありますので、それにしたがって記述します。一般的にプログラミング言語によって、業務を記述する場合、いつそれを起動させるのか、起動させるためには、何を準備しておくのか、といったような、細かいコンピユータ処理上の手順を記述していくことになります。経験的には、これらのコンピュータの技術的処理部分が、8割で、実際の業務処理の部分は2割といわれています。Servicesがやってくれます。開発者は、このような厄介な処理に悩まされることなく、業務処理に関連する部分だけ記述することになります。8割部分は書かなくてもよい、ということになります。この機能のおかげで、プロでなくても、2日間程度、勉強すれば、使えるようになり、大幅な開発生産性の向上が期待できるわけです。DOAとPOA1960年代にも多くの基幹業務システムが開発されました。この時代には、どんな処理が必要なのかをまず考えました。その処理に必要なデータをファイルとして定義し、これらの処理の繋がりでもって、基幹システムを開発していました。Approachといいます。現在でも、一般の業務を担当しておられる方には、この考え方が広く普及しています。わかりやすいからです。Approachが主流となってきました。現在では、ITの開発方法論の主流は原則、「DOA」です。DOAが当初叫ばれた時代には、色々なシステムが、POAにのっとって、個々バラバラに開発された結果、データの重複があちらこちらにみられるようになり、収拾がつかなくなっていたのを解決する必要があったからです。わかりやすくいえば、給与にも社員情報がありますし、販売管理にも社員情報がある、さらに会計にもある、仕入先も販売先もあちらこちらにあって、何がなんだかわからない、という状況を解決する必要性にせまられたのです。それがDOAのそもそもの発端でした。現実には、画面がないと仕事ができませんし、一般ユーザには、データという見えないものより、画面の方がよっぽど、現実的です。そこで、データと画面の関係や、それを動かすプログラムとの関係などを分析する手法が発達していきました。それらを総称的に「DOA」と呼んだのでした。データを定義すると、何とか、該当する画面を自動的に生成し、かつ、必要なプログラムを自動生成できないかという、動きが起こります。1980年代の後期からこれらのための専用の道具立てが整備されていくことになります。イスラエルで開発されたSapienceやウルグアイで開発されたGenexusなどがそれに該当します。Webもこの流れの中にあります。Webも広い意味で「DOA」の範疇に入ります。Design」と呼んでいます。この言葉は日本では普及していませんが、DOAと思っていただいても結構です。WebはDOAの流れを汲んでいる、と思っていただいて結構です。Servicesに対して開発内容を依頼します。Servicesは依頼された内容を解読し、必要な自動生成処理を行ないます。結果は、プログラムが生成されるのではなく、仮想コードを生成し、それは、その業務のアプリとして、サーバ上に置かれます。データベースということになります。開発者はこのサーバのことを管理、ないし、意識する必要は全くありません。勝手にやってくれます。知らないうちにできているということです。具体的には、以下のようになります。データ、すなわち、その入れ物であるテーブルを定義します。細かく言いますと、主キーが何であり、外部キーが何であり、必要なデータ項目(これを属性といいます。いったものを定義してやります。保存ボタンを押します。Servicesがそれを解読して、必要なテーブルを作ってくれます。必要な画面を二つの形式で作ってくれます。一つは一覧形式(エクセルのようなもの)他の一つは、単票形式です。この各々を、データシートビュー、リストビューといいます。これらの画面にデータを入れ、テーブルに保存するためのプログラム(トランザクション)も自動生成してくれます。いった、基幹業務上必須の機能を生成してくれます。プログラムを自動生成しているとはいいましたが、実体はありません。Servicesが同時に実行エンジンとして機能する働きをもっています。Servicesは、一種のコンパイラの機能をもっていると同時に、実効を司るエンジンでもあるのです。Servicesは賢い働きをもっています。弊社の別ページでSapienceの紹介をしておりますが、Sapienceの場合、このプログラムのことをOperationと呼んでいました。Webの場合、眼に見える形でこういったものはありません。Servicesが勝手にやってくれます。開発者は全く意識不要です。Sapienceの場合、operationは結構開発者が意識しています。それを基にして、色々なことを考えます。Webの場合、割り切っています。Operationを開発者に意識させません。どちらが良いかは、判断のできない問題です。どちらにも、長所があります。Webには、データマクロを使うということがありますが、それを使う局面は、データが変化したとき、ということになります。このデータが変化したときというのは、極めて重要な概念です。一般的にデータが変化する局面は、1データ挿入後、2データ更新後、3データ削除後の3つの場合です。新規データが作成されたときは、明らかに、データが変化しています。同様に、今まで記録していたデータが何らかの理由により、例えば、数量が変更されるような場合、データが変化したことになります。データドリブンアーキテクチュアの場合、データが変化したとき、そのデータをテーブルに書き込もうとします。このタイミングで、ちょっと待てといったことになり、変化したときに必要な処理を書いたデータマクロを実行しようとします。実行が完了すると、テーブルに書き込むようにします。データが変化したときに、データマクロに記述されたビジネスルールを実行しようとします。わかりやすくいいますと、ユーザは商品コードとその受注数量までを入力して保存ボタンを押します。その瞬間、データマクロでは、商品コードを参照して、単価をもってきて、その単価と受注数量を掛けて、金額を計算する、というような処理を、データマクロで記述します。Servicesはこの一連の処理を実行制御します。保存ボタンを押すと、テーブルが変化しますので、その変化したタイミングで、データマクロを起動させます。実行が完了すると、テーブルにその結果を書き込みます。これらの順番制御は、開発者の関知するところではありません。Servicesがやってくれます。開発者は、変化したときに実行すべき、業務ルールをデータマクロで記述するだけです。制御にまつわるコンピュータの技術的処理は開発者の関心事ではなくなります。旧来のプログラミング言語処理では、これらの制御手順を厳格にプログラマが書かなければならなかったのとは大きな違いです。これが、開発生産性を高める最も大きな要因です。Webがもっている他の便利な機能と合わせ考えると、10倍の生産性があるものと考えています。10倍とは、約2週間かかる開発期間が1日になるということです。大体こんな感じだろうと思って使っておりますが、実体験とほぼ一致しています。いう3つの局面で、ビジネスルールを記述します。テーブルは、自分のデータ並びに処理の方法をカプセル化していることになります。Servicesの監督下で行われます。開発者は意識する必要がありません。データマクロは、他のテーブルからデータを読み込むという機能もありますし、それに合わせて、自分のテーブルの値を更新するという機能もありますが、さらに、他のテーブルを更新するという機能ももっています。これは極めて重要な関心事です。意味としましては、以下のような例がわかりやすいでしょう。受注業務があるとします。受注しますと、当然、受注内容をテーブルに書き込みます。在庫を更新させることができます。しますと、在庫テーブルでは在庫の数量が変化します。在庫の数量が変化しますと、在庫につけられたデータマクロが自動起動します。このとき、在庫数量が安全在庫を割ったとします。しますと、在庫テーブルにつけられたデータマクロは、発注準備というテーブルを更新させることができます。して、1日が過ぎた後、発注準備というテーブルを参照すると、発注すべき品目がわかりますので、それを別途、発注処理する、というようなことができるようになります。これらの処理を従来のプログラミングでやってもできないことではありませんし、事実色々な方法でやってきています。Webでは、実に簡単にこういった処理を実現できてしまうのです。本例では、受注トランザクション、在庫トランザクション、発注準備トランザクションが3つ動作していると考えることができます。このように3つの関連するトランザクションのことをトランザクションが連携されていると表現します。Servicesはこれらトランザクションの連携を管理してくれています。今の例で、在庫のところのルールで、マイナスが発生した場合、商品を提供できなくなりますので、この受注はお受けできないということになります。この場合、在庫から、Errorを生成するようなデータマクロを記述することができます。このようにしますと、画面には、「その受注はお受けできません」として、メッセージを送ることができます。受注データをロールバックさせてしまいます。画面には入力した値が表示されていますが、受注テーブルには何も書き込まれていないことになります。発注準備において、その商品が受注停止になっているというような場合には、ロールバックさせずに、受注準備ファイルにメッセージのみを送るというようなこともできます。受注停止になっていますので、対策を考えてください、というようなメッセージを送ればよいでしょう。このトランザクション連携はしばしば、活用されています。販売在庫管理システムから、会計へ自動仕訳するときにも、この方法を使います。データを入力している担当者には、背後で、自動仕訳していることは全くみえません。弊社ではこのようなことを称して、リアルタイム会計と呼んでおります。画面を適切に開発いたします。変更や、削除処理を行なう場合、該当するレコードを特定するために検索をする必要があります。受注の変更をする場合には、一般的には受注番号で検索する、といった感じです。検索は、このようにひとつに固定されるものではなく、ユーザ様とお打合せをして、どのような検索をするのか、決めます。それに合わせて、検索するための画面を用意し、そこから該当のレコードを画面に表示してやることになります。開発している方々にとりましては、色々な経験をしておられると思いますが、この打合せと、開発作業は結構な時間を要します。各画面毎に検索のスタイルが変わりますので、それに対応することも必要になります。Webでは、リストビューに対して、検索ボックスが提供されています。この検索ボックスは、全文検索の機能をもっています。高速処理を行ないます。使ってみますとなぜこんなに早いのか驚く程です。この検索ボックスには、例えば、受注番号を打ってもよいですし、その一部を打ってもかまいません。該当するレコードが複数個表示されます。日本語を打ってもOKです。極端な話、金額や日付けを打ってもかまいません。該当するレコードを検索して表示してくれます。この画面は新規登録にも使えますし、変更登録にも、削除登録にも使えます。各専用画面を開発する必要がありません。実はこれも開発生産性を高める要因の一つになります。通常は、この検索ボックスで、間に合うことが大半です。特殊な検索が必要な場合には、それに対応させて開発することもできます。Webにはオートコンプリートという機能があります。これは画面のひとつのコントロールのタイプです。ここには、例えば、商品コードの一部をまず打ってやります。しますと、該当する項目が8ヶまで表示されます。それをみながら、さらに、コードを深く打っていきます。しますと、いずれ該当項目が絞り込まれて、検索が完了することになります。これは非常に便利な機能です。この機能を拡張しますと、バーコードなどをバーコードリーダで読ませると該当する商品が直ちに検索できます。バーコード読み取りは通常読み取り機器が、キーボードエミュレータを搭載していますので、キーボードから打ち込まれたと同じことになり、オートコンプリート機能は、該当商品を直ちに、表示してくれます。何らかの読み取りのためのルールは一切記述する必要がありません。これもシステムを開発するときに結構重宝します。Webは検索するための機能に関して、統一的な回答を用意しています。開発者はこれをうまく使いながら、生産的にシステムを開発することができるようになります。Webは、中小企業様の基幹業務、あるいは、大企業様の部門業務を開発する場合に極めて生産性高く使用できるツールということになります。日本では、まだPRが十分でなく、各種フォーラム等をみていましてもこれからという感じです。Office365のサポートがなくなるのは残念だと思います。29最近の投稿2020年あけましておめでとうございます。構築サービス開始2018年、あけましておめでとうございます。Salesforce.comご支援開始2017年新年おめでとうございます。Institute)を開始いたしました。入力も出力も使い慣れたEXCELで、かつ堅牢な基幹システムができるなんて嬉しくありませんか。