AccessVBAエキスパートスタンダードの資格を取ってからは、Accessの勉強をしていました。というのもAccessの使い方を知らないことにはAccessVBAは使いこなせないだろうと思っていたからです。
そこで最近はMOS Access2013を取得した時に使っていた『よくわかる Microsoft Access 2013 基礎 (FOM出版のみどりの本)』や『よくわかる Microsoft Access 2013 応用 (FOM出版のみどりの本)』をもう一度読み直していました。
AccessとAccessVBAの資格を取得したことで基礎的な知識がついたし、ある程度落ち着けたということもあって、Excelと比較した場合のAccessの操作性について次のようなことに気づけるようになりました。
それは、何かと「ウィザード」が多いということです。
Accessを操作したことがある人ならわかると思うのですが、例えばクエリ作成、フォーム作成、レポート作成などをする時に「ウィザード」と書かれたダイアログボックスが表示されて設定が進んでいくというものです。
最初は特に気にしてはいせんでした。しかし、勉強を進めていくうちにこのやり方が多いことに気づくようになり、この「ウィザード」というものを調べてみました。
今回は勉強や備忘録も兼ねてAccessの中でよく使われるる「ウィザード」、加えてそこから気づいた「UIデザインパターン」というものについても簡単にまとめてみます。
Accessにおけるウィザードとは
Accessを使っていると、例えば新しいクエリを作る時に以下のようなダイアログボックスが表示される時があります。
Accessにおけるクエリとは、テーブルのデータを操作するオブジェクトのことを言います。指定のテーブルから特定のフィールドの抽出や集計を行う「選択クエリ」、テーブルの指定のフィールドの更新を行う「アクションクエリ」など、クエリにはいくつかの種類があります。
こういったいくつかのクエリを作っていく際に上の画像のような「ウィザード」と書かれたダイアログボックスが表示されます。
これはクエリに限らず、フォームやレポートを作成する時にも必要であれば上記のようなダイアログボックスが表示されます。
この機能の特徴としては、特に難しいコードを使わなくてもそこに書かれている指示に順次答えていく形で進めていくと、自分が作りたいクエリやフォーム、レポートが作れる、といったものです。
この操作やダイアログボックスをAccessの勉強を進めていく中で度々目にしたので今回気になりました。
UIデザインパターンにおけるウィザードとは
ウィザードをインターネットで調べてみた所、以下のサイトに詳しく書かれていました。その中から次の部分を引用してみます。
ウィザードは、情報入力で用いられる一般的なアプリケーションデザインパターンの1つである。これは、実行頻度の低いプロセスでうまく機能する。
ウィザードというものは、数あるアプリケーションデザインパターンというものの中の一つであり、ユーザーに情報を入力してもらうためのアプリケーションのようです。
ユーザーに入力してもらう情報が多い時に一度に全てを入力してもらうと混乱させてしまうので、複数のステップに分割するやり方です。この方法をとることによって、ユーザーのミスを少なくし最後まで情報入力をしやすくできるといった効果があります。
デメリットとしては、入力してもらうための決められたステップが多くなります。また、入力方法の自由度が低いということもあり、アプリケーションを利用する時にこのプロセスが多いとユーザーをうんざりさせてしまう場合もあります。
自分もAccessで新しいクエリやフォームを作る時にそれは感じました。勉強するための本だからそういった操作が度々出てくるのかもしれませんが、確かに実行頻度が低いプロセスで使ったほうが良いですね。
以上が、システム内でウィザードを使う場合の大まかなメリット、デメリットになります。より詳細を知りたい方は上記のリンク先を見ていただければと思います。
自分はリンク先のウィザードの使い方や効果についても気になりましたが、「アプリケーションデザインパターン」という言葉も気になりました。
「アプリケーションデザインパターン」というのは、要はウィザードのように、システムを開発する上でユーザーにとって使いやすい部品や用法みたいなものをまとめたものだろうと思いました。
そこでインターネットでいろいろと調べてみた所、このウィザードのような用法というのは「UIデザインパターン」とも言われて、この中のひとつになるようです。
そこでUIデザインパターンというものについても調べてみました。
UIデザインパターンとは
「UIデザインパターン」とはどういったものなのでしょうか。調べてみた所、この言葉自体の詳しい意味はなかなか見つけられなかったので「UI」と「デザインパターン」という言葉に分解して確認してみます。
UIとは、 ユーザーインターフェイス（User Interface）の略称で、 コンピューターやスマートフォンなどのデバイスとユーザー（デバイスを使う人）とのインターフェイス（接点）のことを指します。例えばパソコンの画面がその中のひとつになります。
では、デザインパターンとはどういったものなのでしょうか。Wikipediaには次のように書かれています。
ソフトウェア開発におけるデザインパターン（型紙（かたがみ）または設計パターン、英: design pattern）とは、過去のソフトウェア設計者が発見し編み出した設計ノウハウを蓄積し、名前をつけ、再利用しやすいように特定の規約に従ってカタログ化したものである。
ソフトウェアの設計ノウハウを使いやすいようにテンプレート化したもの、といった感じで理解すれば良いでしょうか。
つまりUIデザインパターンとは、ユーザーとのインターフェイスにおけるテンプレート化された設計ノウハウといった感じの意味になると思います。
では、UIデザインパターンには具体的にどういったものがあるのでしょうか。自分がインターネットでいろんなサイトを見てまわった所、以下のサイトが豊富にパターンが掲載されて、解説も丁寧だと感じました。
引用したソシオメディアさんのサイト内には、以下のように冒頭部分でも取り上げた「ウィザード」もありました。
図も説明も丁寧で素晴らしいですし、こういったデザインパターンが豊富に掲載されたサイトは、自分のようなプログラミング初心者にとっては非常に勉強になってありがたいです。
他にも以下のようなデザインパターンもあります。
上記の「編集（Editor）」ページは、システムで扱うオブジェクトの内容をユーザーが変更できるような画面設計を見ることができます。
自分は以下のような過去記事も書いているのですが、ExcelVBAのWebBrowserを使う時に「編集（Editor）」ページにあるような画面設計を利用すればよかったと思います。
そうすればユーザーにとってもっと見やすい形で、PDFのリネームといった編集など数多くの機能を追加できただろうなと思いました。
もっと早くこういったサイトに出会えていればなと思いました。
まとめ
今までこういったもの(システム開発していく上での部品群みたいなもの)があったらいいなぁという漠然としたイメージはありました。
しかしそれが具体的にどういったものなのか、どういった言葉で言い表せるものなのかがわからず、基本的に0からシステムをつくるやり方で進めていました。
しかし、自分みたいなシステム開発の経験が不十分な人間が0からシステムを作っていくというのは問題も少なくありませんでした。機能的にもUI的にも不十分な所も多く、「本当にこういった形でいいのだろうか」といった不安感も拭えません。
けれども、自分が今まで漠然としたイメージしか持てていなかったものが「UIデザインパターン」という形で発見できたというのは、大きな安心感を得られたというか「あぁ、やっぱりこういうのあるよね」と思いました。
自分はコードで必要な機能は作れても、それがユーザーにとって必要なものか、使いやすいものなのか、見やすいものなのかという視点が欠けていたと思います。
先程引用したWikipediaのデザインパターンのページには次のようにも書かれています。
それぞれのパターンは、プログラマの間で何度も繰り返し考え出されてきた。したがって、それは最善の解決策ではないかもしれないが、その種の問題に対するトレードオフを考慮した、典型的な解決策ではある。
さらに、コストがかかるかもしれない問題解決を実際に行う前の先行調査として、大変役に立つ。パターンに名前が付いていることが重要である。なぜなら、名前が付いていることで問題や解決策を記述したり、会話の中で取り上げたりすることができるようになるからである。
そうなんです。「名前が付いている」ってすごく重要だと思います。名前が付いているということは「言語化されている」ということなので、他の人にも広めやすいでしょうし、今回の自分のように「こういったものもあるんだ」という風に気づきやすく、理解しやすくなります。
言語化できてしまえば、後は調べるなり本を読むなりすればシステム開発にも上手く活用できると思います。また、そこからさらに派生した概念や用法も見つけれるかもしれないので今後の仕事が捗りそうです。
たぶん、システム開発の経験が豊富な人は、業務ごとにどんな形のシステムにすべきかすぐにイメージできているんじゃないでしょうか。
さらに今回の「UIデザインパターン」のように、この部分はA、この部分はBみたいにどの部分にどういった部品・パターンを当てはめるかも予めイメージできてしまっているんだと思います。
今回の件から、システム開発を進めていく上でコードを使ってどんな機能が実装できるかという点も大事だけれど、UI面で予め作られた部品・パターンをどういった時に有効に使えるのか、さらに業務ごとにどう手を加えられるか、という知識も重要なんじゃないかと思いました。
コメント