前回は以下のようにAccessからUIデザインパターンを見出したといったことを書きました。
それから「UIデザインパターン」について何か良い本はないか調べてみた所、『デザイニング・インターフェース ―パターンによる実践的インタラクションデザイン』という本があったので購入しました。
本書は、前回の記事でUIデザインパターンを勉強させていただいたソシオメディアさんのサイトにもあった本です。以下のページでも紹介されています。(本書はソシオメディア株式会社が監訳者となっている)
デザイニング・インターフェース 第2版 – パターンによる実践的インタラクションデザイン –ソシオメディア
本書は第二版の定価だと5,000円ぐらいするみたいでちょっと手が出ないので、初版の中古の方をアマゾンで買いました。
自分はデスクトップ上で動作する業務システムをつくりたかったので、そのために良さそうな実用的なUIデザインパターンの本を探していたのですが、なかなか見つけられませんでした。
この手の本はWebやモバイル・スマホ関連のものが多く、デスクトップ上で使うための業務用のUIデザインパターンに関する本は、特に最近のものは少ないようです。
『デザイニング・インターフェース ―パターンによる実践的インタラクションデザイン』は大型で300ページ以上あるのでまだ読みきれていません。そのため書評とまではいきませんが、自分が読んだ範囲でいくつか気づいたことを整理していきます。
本書を購入した目的
システム開発が非常に上手い人が、例えば多くの人に役立つような何らかのシステムを開発したとします。
けれどもそこからわかるのはシステムの使いやすさとか見た目のわかりやすさといった表面的な「結果」であり、そこまでの状態に至った順番や経緯というのは見えてきません。
ですから自分は、よりよいシステムを開発できるようになるため、イメージする結果に至るまでの「途中」の「お手本」が欲しいと思っていました。
そういったものを具体的に知ることができるのではないか、それらを知ることによって逆に「こういったことやああいったこともできるかもしれない」という発想も出てくるのではないか、と思って購入したのが『デザイニング・インターフェース ―パターンによる実践的インタラクションデザイン』です。
自分がシステム開発というものを仕事にするようになってから気づいたのは、そこそこプログラミングができてもそれだけでは良いシステムを作るのは難しいということです。
世間での一般的な考え方では、システム開発には上流工程と下流工程があると言われています。自分の勉強した範囲、調べた範囲では、この上流工程という分野において「概念」の領域から抜け出せずにいました。
この上流工程という分野のひとつには「要件定義」とかシステム開発を実際に行うためのいろいろな取り決めみたいな領域があるのですが、自分はここら辺がなかなか理解できませんでした。
要は「具体的に何をすればいいのか」ということです。
文字とか言葉で、そこに何が書かれているのか、というのは何となくわかるんですが、それらを行った結果、何が見えてくるのかがわかりませんでした。
要件定義というのは、一般的には依頼者からの要望を受けてそれらを開発するシステムに反映させる内容を固める工程です。この時に自分は違和感というか疑問がありました。
「どうやってやるんだろうか」と。
依頼者から受けた内容と完成されたシステムとの間の工程とも言えばいいでしょうか。この部分がよくわからない。
例えば何か建物を建てる時も、種類によって材料とか工程とかだいたいパターンは決まっていると思います。一般的な民家はこんな感じ、一般的な高層ビルはこんな感じみたいな。
猫とか犬みたいな形をした建物はほとんどないと思いますが、建物の種類によってはだいたい形は決まってくるのではないでしょうか。
そうなってくると素材や部品もそれ程突飛なものはないはずです。長年の技術の蓄積や工程の改善によって最適化された、ある程度決まった型みたいなものができあがってくると思うんです。
それと同時に依頼者からの要望で受け入れられる範囲も「作れる部品や使える範囲」が前提になってくるのではないでしょうか。
システム開発において、そういったものは具体的にどういったものなのか、というのが自分は知りたいと思っていました。
依頼者からこういったシステムが欲しいと言われても、自分の能力の範囲内でどこまで作れるのか、作れる部品にはどういったものがあるのか、そういったものがはっきりしていないと依頼者からの要望も理解して聞くのは難しい気がします。
逆に考えると、システム開発にはどういった部品(今回のUIデザインパターンなど)があるのかがわかれば要件定義というのも理解しやすくなるんじゃないかと思いました。
自分の中にこういった部品、こういった作り方があれば、こういった聞き方ができる、さらにはそれらを前提とした提案もできるといったイメージ。
それらのいくつかの工程を理解するためには、具体的に目に見えるUIのパターンを知るのは有効なのではないかと思いました。
プロパティシート
実際のシステムと今回取り上げた本書を照らし合わせてみると、いろいろと見えてくるものがあります。自分にとってのその具体例のひとつが「プロパティシート」でした。
MicrosoftOfficeのAccessを使っていると以下のようなプロパティシートを使う機会があると思います。
挿入した画像の右側の赤枠の部分がプロパティシートになります。
プロパティシートは一般的には、対象のオブジェクトの属性を一覧表として見ながら変更できるUIデザインパターンのひとつです。
例えばVBEで表示されるプロパティシートでは、対象のフォームの表示される文字列を変更する、といったことができます。
『デザイニング・インターフェース ―パターンによる実践的インタラクションデザイン』をパラパラと見ていたら「あれ？これAccessに出てたプロパティシートじゃないか？」と思った箇所がありました。
本書にはプロパティシートについて次のように書かれています。
P.120
- 概要
2カラムまたはフォーム形式のレイアウトを用いて、このページでオブジェクトのプロパティを編集できることをユーザに示す。
- 利用場面
そのインターフェースが、編集可能なオブジェクトをユーザに提示する場合、例えば画像編集ツールで作る作品や、データベースのレコードやクエリ、何らかの専門的な項目(自動車や株式の購入)などがあるだろう。ユーザがそのオブジェクトのプロパティや属性を変更する必要がある場合。
上記に引用した以外にもプロパティシートのUIにおいて、次のような項目の説明が書かれています。
- 理由
- 用法
- 事例
本書は、様々な各UIデザインパターンについて以上のような説明が書かれています。
ExcelVBAでコーディングしようとする時にVBEを使いますが、そのVBEでいろいろフォームを作ろうとする時にも画面の左下に「プロパティシート」が表示されます。
実は自分の気づかない所で結構使われているUIのひとつなのではないかと思いました。
プロパティシートというものが本書のUIデザインパターンのひとつとして掲載されているのを見て、初めて「あ、これもUIデザインパターンなんだな」と気づかされました。
今まではプロパティシートというものをそういった視点では全然見れていませんでした。また、本書に書かれているようにそのUIデザインパターンの利用場面や使う理由、用法があるということを知ることができるのは目から鱗が落ちる思いでした。
複数ペイン
UIデザインパターンのもうひとつの勉強になった事例として「ペイン」があります。ペインとはコトバンクには次のように書かれています。
1つのウィンドウをいくつかの表示領域に分けたとき、そのひとつひとつの領域をペインと呼ぶ。
例えば以下の画像のような感じです。
先程のプロパティシートの項目で使った画像と同じですが、今回はAccessの画面で上と左と中央に赤枠を使っています。上側の領域をリボン、左側の領域をナビゲーションウィンドウ、中央の領域をオブジェクトウィンドウと呼びます。(『よくわかる Microsoft Access 2013 基礎』のP.22を参照)
これらの表示領域の総称をペインと呼ぶようです。
このパターンもよく見かける感じがします。例えばOutlookも同じ3ペインですし、VBEも左側にプロジェクトエクスプローラとプロパティウィンドウがありますけど基本的には同じパターンです。
会計ソフトである勘定奉行の最初の画面も左側がメインメニューとなっていて、そのメニューの中からクリックした項目が中央の領域に階層的に表示される2ペインのパターンになっています。
『デザイニング・インターフェース ―パターンによる実践的インタラクションデザイン』では、このペインについて次のように書かれています。
P.29
- 複数ペインを並べて表示
多くのデスクトップアプリケーションやウェブアプリケーションでは、1つのウィンドウ内に複数のペインを並べて表示する。これは、ウィンドウの操作を最小限に抑えながら一度に多くの情報を見たいユーザにはとても便利だ。
2ペイン構成でデザインされたウィンドウやダイアログボックスは数え切れないほどあるし、Outlookやそれに似たアプリケーションが普及したおかげで、今では3ペイン構成がより一般的になっている。
プロパティシートの時もそうだったのですが、上記の画像の3つの表示領域が実はUIデザインパターンのひとつだった、というのは今まで全然意識したことはありませんでした。
本書ではこのペインについても利用場面や使う理由について書かれています。自分が気づかないところで様々なUIデザインパターンが使われていたんですね。
まとめ
本書を読んでみて気づいたのは、日頃何気なく使っていたシステムが実は多くのUIデザインパターンが使われているのではないか、さらにそういったものの組み合わせでできているのではないかと思いました。
また、システム開発のプロの人たちはこういったUIデザインパターンをいくつも自分の引き出しとして持っているんだろうと思いました。
本書には利用場面や使う理由についても書かれているので、例えば
- Aというシステムを開発する時はCのUIデザインパターンを使う
- Bというシステムを開発する時はDのUIデザインパターンを使う
みたいな考え方をプロの人たちは既に用意しているんじゃないかと思いました。
逆の見方をすれば、本書に書かれているようなパターンを知っていれば、システム開発の依頼者にも「こういったものができますよ」という提案もしやすいのではないかと思いました。
既に書きましたが、本書のようなパターンを理解できれば「これができればこういったシステム、あんなシステムもできる」という発想もしやすくなっていくと思います。
こういった部分も自分が知りたかった箇所のひとつです。
自分は今まで本書のようなパターンを知らなかったので、「システム開発といっても、プログラミングが出来るとどういったものがどこまで作れるのか」については見当がつきませんでした。
しかし本書を購入することで、プログラミングってこんなことやあんなこともできるんだ、ということを具体的な目に見える形でいろんなバリエーションを通して知ることができたのは非常に勉強になりました。
あわせて読みたい
こんな記事も読まれています
- イメージできないシステムはプロが作った完成形やUIをベースに考えてみる
- 上流工程やUMLの勉強が必要な理由のひとつは大規模システム開発が関係か
- 2018年の振返り━SEの上流工程面と外部アプリケーション操作という課題
- SEはプログラミングだけではなく要件定義や仕様書の知識も必要
- ExcelVBAを使いこなすにはもう一段上のレベルの知識が必要なようです