%e7%84%a1%e9%a1%8c

 【ITに関して自立できる中小企業を目指して】

 

弊社では、IT化に関して、「自立できる中小企業様」をご支援させていただくことが最適である、
と考えております。ITといえば、とかく、外部専門家に依頼して作ってもらう、
というお考えをもった経営者の方々が大半かと思います。
しかし、外部に依頼するということは、色々な障害要因があることも事実なのです。
代表的なものとしましては、
 1.なかなかこちらの意図が相手に伝わらない。
 2.作ってもらっても、その後、変更が必ず発生するが、その際再度打合せに時間がとられたり、
         金額もかさむ。
 3.ITは日進月歩であるが、なかなかそれについていけない。
 4.その結果、昔作ったものがそのままになっており、ビジネスは変化しているのに、ITは昔のままである。
というようなことがあげられる、と思います。

一方、ITの技術は進化してきており、少し、勉強すれば、自社でも自立できるような道具立てが
整備されつつあります。弊社では、このような観点から、中小企業がよく陥る不都合を解決するために
二つの道具立てをお勧めしたいと考えております。
 1.ホームページを自社の広報・宣伝活動の基盤と位置づけ、タイムリーに自社で更新できる
        ようにするため、 次第に主流となりつつある「Word Press」を学んでいただく。
 2.自社のビジネスを支えるための、販売在庫管理システムなどを、自社で開発・維持できるようにするため、
   マイクロソフト社が提供する「Access Web」を学んでいただく。
ということを考えております。

ここでは、Access webにつきまして、その優位性を解説いたします。
もちろん、これは自社でも開発できますが、もし、外部に委託される場合には、以下に解説する優位性をもとに
委託先にAccess Webを指示されても結構です。
ただし、基本的な勉強は2日間で完了しますので、基礎として学ばれることをお勧めいたします。

【Access Webは超高速開発ツールのひとつである。】

 

弊社では、Access webは「超高速開発」の道具立ての一つであると考えています。
理由は、文字通り、開発の生産性が大幅に高まるからです。以下にも述べていますが、
一般のプログラミング言語による開発に比し、10倍位の生産性向上が期待できるものと考えています。
現在、マイクロソフト社では、Access webを超高速開発ツールとしては、位置づけておられないようです。
理由は定かではありませんが、米国には、超高速開発ツールという言葉自体がありません。
この用語は、日本固有のものでしょうから、日本マイクロソフト様としては使いづらいのではないか、
と想像しております。したがいまして、これはあくまでも弊社の見解です。

【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はAccess2016ですが、これはAccess2013とほぼ同等です。Web開発におきましては、
差異はありませんので、安心して、Access2016をお使いいただいて結構です。

以下に解説を進めます。

【Office 365との関係】

 

最新のAccessでWeb開発を行うには、サーバが必要になります。このサーバは、
Share Point Serverと呼ばれます。
そのShare Point ServerのAccess ServicesというものがWeb開発には必要になります。
しかし、このShare Point Serverは、自社で購入することも可能ですが、高価ですし、
導入作業も少々厄介です。中小企業様にはお勧めしずらいものです。

通常は、マイクロソフト社のパブリック・クラウドである「Office 365」を使用します。Office365には、
Share Point Onlineという機能があり、Access Serviceも動作します。これを使いますと、極めて安価に
Access Web開発のためのサーバを利用することができます。
最も安価なものでは、1ユーザ、1ヶ月500円少々です。

Office 365では、メール機能、テレビ会議機能、SNS機能、ファイル共有機能、グループウエア機能、
も同時に使えますので、中小企業様にとりましては、これさえ、契約しておけば、非常に便利です。

弊社にご依頼いただければ、契約手順等のご案内をさせていただきますので、お気軽にお申し付けください。

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

基幹業務を開発するためには、コンピュータのプログラミング言語が必須である、
と思っている方々が大半です。しかし、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は、中小企業様の基幹業務、あるいは、
大企業様の部門業務を開発する場合に極めて生産性高く使用できるツールということになります。
日本では、まだまだこの点の認識が十分であるとは思えません。日本で取り交わされている各種フォーラム
等をみていましてもまだまだこれから、という感じがいたします。
しかし、米国でのフォーラムをみていますと、多くの方々が、次第にレベルの高い議論を展開される
ようになってきており、発展してきていることがよくわかります。

とくに、マイクロソフト社のクラウド・サービスであるOffice365を利用いたしますと、極めて簡単に
かつ、極めて安価に、自社で開発環境、テスト環境、実装環境を作ることができるようになります。
是非とも、この素晴らしいサービスを検討されることをお勧めいたします。