東北地方太平洋沖地震の影響について

　この度の東北地方太平洋沖地震で被災された方々には、心よりお見舞い申し上げます。

　当社においては事務所内の器物損壊等はあったものの、サーバー等業務を行うにあたって障害となるような被害は受けず、今週から通常業務に戻っております。

　事務所の所在地が仙台市若林区なので、心配して頂いた方もおられましたが、同じ若林区でも仙台東部道路が防波堤となり、当地区には津波の被害は全くありませんでした。

　それにしても宮城、岩手、福島を中心とした東北地方の人的、経済的損失は計り知れず、未だ行方不明者の捜索が続けられ、避難所生活を強いられている方々の将来不安を慮ると暗澹たる気持ちになります。

　昨日も仙台駅周辺に赴きましたが、駅構内には立ち入ることが出来ず、「倒壊中」の張り紙が不気味でさえありました。地盤が至る処で沈下しており、いまだに危険な状態であります。この分ですと数ヶ月は新幹線の復旧は見込めないのではと思います。

　ただ一番町辺りは徐々に活気を取り戻しつつあり、地元の商店街を中心に店を営業している所も増えてきているようです。逆にコンビニやチェーン店の復活は遅いような気がします。やはり東京主導ではなく、地元主導で復興しなければならないと強く感じます。

　東北ははやぶさ開通、トヨタ自動車関連工場の操業開始など全国にも明るいニュースを配信し、又平成２７年開業を控えた地下鉄東西線など楽しみな材料が他の地域に比べれば割とあったのですが、これで一気にどん底に突き落とされた感じがします。

　しかし、これも我々東北人に課せられた運命と受け止め、おそらく今後１０年はかかるであろう地域の復興に、太平洋の海に消えていった何千もの無念の魂に報いるためにも、我々は新たなチャレンジをしていかなければならないと感じています。

スマートフォン狂想曲

 　スマートフォンが売れているらしい。自分も買った。購入した理由はアンドロイドアプリを開発したいと思っている為、実機が必要だったからだ。本当のことを言うと画面を指でベタベタ触って操作するインターフェースはあまり好きではない。

　スマートフォン関連のセミナーも盛んだ。仙台で今月、来月だけで５回もある。一応全部参加する予定だ。一昨日も宮城県主催のセミナーだったが、２００人ほど集まっていた。仙台のキャパにしてはすごい関心の高さだ。

　しかし、あえてここで疑念を呈したい。本当に市場が単純に一方的に拡大していくものなのか。そこに関わる人々が皆WinWinの関係になるのか。反動はないのか、落とし穴は無いのか。

　おそらく、この閉塞した日本の経済状況そしてIT業界において久々にブレイクスルーしたテーマであるし、商売になりそうな気配はある。昨年、一昨年と話題をさらった仮想化、クラウドだが実際に商売として何とかなったかというと非常に疑問が残る。今回に関してはアプリを作って一儲けしようと最後の望みをかけて我も我もと飛び込もうとしている感がある。まさにゴールドラッシュだ。

　そこで、論点は２つある。

　１つ目。アプリ開発の収益モデルは確立しているのかということ。iPhoneアプリで３０万本以上、Andoroidアプリで２０万本以上マーケット上に存在すると言われるが、その殆どは無料だ。有料であっても数百円程度だ。しかも従来のiモードアプリのような月額課金ではなくダウンロード１回限りだ。これで元が取れるのか。広告モデルでやるにしてもたかがしれているような気がする。

　例えば「窓の杜」。フリーウエア、シェアウエア合わせてダウンロード可能本数は１０万本を超えている。この中で本当にビジネスとして成り立っている企業はどれだけあるのか。自分の知り合いでやっている人もいるが、小遣い稼ぎにしかならないそうだ。ほとんどは個人が暇にまかせて趣味の延長でやっているに過ぎないのではないかと思う。

　アプリも結局は個人かスモールオフィスが中心で採算度外視でやっていると思う。もちろんマクドナルドや楽天など本業の収益源があるところはマーケティングの一環としてやっていると思うのでアプリ自体で収益が無くてもいいと思うが、問題はソフト制作自体を生業としている企業が成り立つかどうかなのだ。この市場は企業体のコスト構造では非常に参入しづらいのだ。

　２つ目の論点はプロモーションの問題だ。

　「厳選アプリ１００選」、「ANDROIDアプリ事典」等アンドロイドアプリを紹介する雑誌４，５冊読んで見ると、３割位はアプリがかぶっている。仮に１０万アプリがマーケットにあっても紹介記事として人の目に触れるのは５００本程度、０．５％に満たないのだ。

　どんないいアプリを作ったとしても知ってもらう為には媒体に広告を出すなり、手間暇をかけて告知していくしかないのだ。やはりその為にはコストがかかる。個人が作った無料アプリを費用をかけて宣伝することはあり得ない。この先無料アプリが何十万本に増えようとも埋もれてしまって存在しないも同じだし、使う側も捜しきれない。

　ビジネスチャンスを求めて企業はこぞってこの世界に参入してきているが、ハードメーカーはともかくアプリ開発業者は果たして生業として成立していくのか、このまま消耗戦を強いられ疲弊していくのか、はたまた新たなビジネスモデルを確立して継続的にアプリを提供し続けられるのか。結局は個人の開発者のお遊び、暇つぶし、技術誇示の場として収斂していくのか。

　今回の狂想曲はどんな最終章を奏でてくれるだろう。

リボンの非表示

　今回はマクロの最後としてリボンを非表示にする方法を考えます。

　OFFICE2007以降全面的に採用されている「リボン」ですが、あまり評判はよくないですよね。ましてやエンドユーザーに使用してもらうシステムを提供する場合、リボンがあるのはかなり問題があります。勝手にデザインを変更されてしまいますから。

　リボンを非表示する方法はいろいろありますが、一番確実で簡単な方法を紹介しますが、実装するにはモジュールを作る必要があります。

　モジュールを作るにはリボンから「作成」→「その他」→「標準モジュール」を選択します。

 

　モジュールはFunctionモジュールとして以下の様に記述します。モジュール名は何でも構いませんが、わかりやすい名前にします。Docmdアクションでリボンを非表示にするというアクションを記述します。

Function closeRibbon()
    DoCmd.ShowToolbar "Ribbon", acToolbarNo
End Function

　以前に作成した「AutoExec」マクロにリボンを非表示にする処理を追加します。「プロシージャーの実行」アクションで、実行したいプロシージャー名に作成したおいた「closeRibbon()」を記述します。

　更に「ナビゲーションウインドウ」も納品時には不要ですので、ACCESSオプションで以下の様にチェックを外します。

 

　さて、以上を実装した結果を表示すると以下の様にスッキリしたフォームが表示されたと思います。

 

　さて以上でとりあえずマクロで実装した方がいいと思われる処理の説明が終わりました。前にも言いましたが、より柔軟で複雑なシステムを構築していきたい場合はモジュールを学ぶ必要があります。

　今回でテーブルの設計から始まったACCESSの基礎的な学習は終了します。ACCESSを身につけるには自分で手を動かして数多くのデータベースを作成していくことしか有りません。わからなければヘルプを見るなり、ネットを検索するなりしてサンプルを捜して真似ることが大事です。又エラーになったり、思い通りに動かない場合は、原因をよく考える事です。

　又の機会に今回紹介することの出来なかった応用的な技法を実例を通して紹介したいと思います。

AutoKeys

　ACCESSを学習していく上ではF1キーでヘルプを参照することは頻繁にあると思いますが、業務に使うシステムでエンドユーザーに使用してもらう場合は、ヘルプは不要ですし、F1キーが起動してしまうのは煩わしいと思われるでしょう。

　そういった場合、AutoKeysマクロを使用することによりPFキーの機能を抑止できます。

　AutoKeysはキーボードとアクションを割り当ててショートカットを実装します。AutoKeysもAutoExec同様、ショートカットを意味する予約されたマクロ名です。「A」と「K」は大文字にします。マクロ名に割り当てたいキーボードを指定し、そのキーに対応するアクションを設定します。逆にアクションに何も設定しない場合は、何も機能しないことになります。それだけでなく、元々あるキーの機能も殺します。

　PF1は{F1}と指定します。そのアクションが未設定になっているので、何もしないだけでなく、本来あるヘルプも開かなくなります。同様に{F2}から{F12}まで無効にします。

　+{F1}はShiftキーを押しながらF1キーを押すことを意味します。下の例では+{F5}まで無効にしています。

　ちなみに{F4}を抜かしている理由はPF4はACCESSのフォームにおいて特別な意味があるからです。フォームのコンボボックスのリストを開くときにマウスではなく、キーボードで行うときはPF4を押します。入力フォームのインターフェースとしてコンボボックスは頻繁に使用しますし、入力に慣れた場合はマウスよりもキーボードでの操作の方が速い場合があるのでPF4は生かしておきます。

 

　次回はリボンを非表示にする方法を学びます。

AutoExec

　今回からマクロについて学習します。

　基本的にマクロでやれることはACCESS VBAで実装できます。実際のところ、より柔軟で込み入った処理を組み込んでいく場合、マクロを駆使して実現するよりも、VBAを覚えていった方が結果的には楽です。どうしてもコードを書きたくないというのであれば別ですが。

　ここでは、定番的な処理で、コードを書くよりもマクロで実装した方が簡単に実現できる処理をピックアップして紹介します。

　最初に「AutoExec」マクロを紹介します。これはACCESS起動時に自動的に行わせたい処理を組み込みたい時に使用します。エンドユーザーに使ってもらうシステムの場合は、ACCESSのデータベースウインドウは見せたくありませんからね。

　まず新規にマクロを作りますが、そのマクロ名は「AutoExec」固定にします。「A」と「E」は必ず大文字にします。この名前のマクロはACCESSが起動時に処理するものと判断します。

　システム起動時に必ず行わせたい処理の一つとして、メインメニューを自動的に開くというのがあります。アクションは「フォームを開く」を選択し、フォーム名にメインメニューとして作成しておいた「F_メニュー」を選択します。

　一旦ACCESSを終了させ、作成したDBを開くと「F_メニュー」が自動的に開くようになります。ちなみに「AutoExec」を動作させずに開きたい場合（データベースウインドウを表示する）は、「Shiftキー」を押しながら開きます。

　これは裏テクニックとしてユーザーには教えないようにします。データベースウインドウが表示されて、デザインを勝手に変更されては困りますから。

 

　実は起動時にフォームを開く方法として、「AutoExec」を使わない方法もあります。「ACCESSのオプション」の「カレントデータベース」でフォームの表示で「F_メニュー」を選びます。



　ただ、アクションとしてメインメニューを開くだけでなく、連続して複数の処理を行いたい場合はやはり「AutoExec」を利用した方がいいです。例えばメインメニューを画面の大きさに合わせて最大化したい場合などはアクションで「最大化」を選択します。他に起動に行う処理例としてはデータベースの最適化、バックアップなどがあります。



　次回は「AutoKeys」について学習します。