UI設計ユーザーが画面上で扱うコントロール部品にはいくつか種類があります。どんな画面でもそれら数種類のコントロール部品の組み合わせで出来ています。そのため、画面設計をする際にはシステムサイドがそれらのコントロール部品の特性を理解しておかないと、ユーザーが求めている要件にマッチした適切な画面設計が進められません。以下に主な入力系のコントロール部品とその特性を紹介します。1テキストボックス・・・数字や文字を入力する部品です。数字しか入れられなくするとか制御の仕方は様々に制御できます。2ボタン・・・データ検索や更新などのアクションを担う部品です。イベントドリブンなプログラムを作るときには必須ですね。3ラジオボタン・・・複数の選択肢から1つだけ選択させる場合に使用する部品です。同一グループ内で複数選択はできません。選択肢を画面上に並べて配置するので、選択肢が多い場合は見にくくなります。4リストボックス・・・ラジオボタンを同じく、複数の選択肢から1つだけ選択させる場合に使用する部品です。同一リスト内で複数選択はできません。画面上は1項目分のスペースしか消費しませんが、リストボックスを開かないと選択肢全体が見えません。5チェックボックス・・・ラジオボタンのように選択肢を画面上に並べて配置するので、選択肢が多い場合は見にくくなりますが、複数個を同時に選択することが可能です。6コンボボックス・・・チェックボックスと同様に複数個を同時に選択することが可能な部品ですが、選択肢がリストのように縦に並べられています。画面上に一度に表示する行数は自由ですが、表示外のリストがある場合はスクロールバーが表示されます。上記以外にもタブフレームやカレンダーコントロールなどいくつかの種類がありますが、まずは上記のコントール部品を使いこなせれば、それなりの画面設計ができます。イメージを掴むために、ExcelのフォームコントロールやActiveXコントロールなどで実際にシート状に配置して動かしてみてください。見て触ったことがある部品ですので、すぐに特性を理解できると思います。ポイント・コントロール部品の特性をユーザーに理解してもらったうえで、部品の画面配置を決定しましょう。・プロトタイプを作ってユーザーに操作イメージを掴んでもらおう。UI設計WEBシステムでも業務システムでも、使う側が誤認してしまうような入力ボックス、ボタン、リンクなどに出会ったことってありますでしょうか?最近のホームページなどを含むWEBシステムでは、よくできたテンプレートが用意されていることも多いし、フルスクラッチで開発するにしてもフレームワークやライブラリを活用することが殆どだと思うので、そのようなダメなユーザー・インターフェース(UI)に出会うことは以前ほどはなくなってきたと思います。ユーザビリティの低いシステムだと、ラジオボタンにすべきところをチェックボックス(複数選択不可なのでわざわざエラーチェック掛けてるとか)にしているとか、文字を強調するために文字色を青にして下線を入れる(リンクと間違えやすい)とかがあったりします。画面のファーストビューでは、最低限必要な情報が1画面にコンパクトにまとまっているのがベターですが、ユーザー要望を聞き入れるあまり、すべての項目が1画面に収まりきらずに仕方なくスクロールバーを用意するなど、実は不便な仕組みになってしまったりすることも多いものです。最大限必要な情報が1画面に収まりきらない場合はどうしたら良いのでしょうか?あくまで私の考えですが、ファーストビューではデータ項目を絞る代わりに一覧形式で表現することが多いです。一覧画面でデータを選択して、すべての項目を参照できる詳細画面に遷移するという具合です。システムによるので必ずということではありませんが、できれば項目数は1画面に収める、かつ目の動線を考えて項目を並べる、ということは守った方がより満足度は高くなると思っています。そのシステムを使うのは、意見を言ったユーザーだけではないので声の大きい1人の意見に振り回されないようにすることも大切です。ポイント・一覧画面から詳細画面に遷移する画面構成を考える。・一覧画面はスクロールなしの必要最小限の項目に絞る。基本設計工程は、ユーザーレビューを繰り返しながら設計仕様を固めていく工程ですが、まずはユーザー・インターフェース(UI)設計が取っつきやすいと思います。ユーザー・インターフェース(UI)設計とは、システムとユーザーの設定となる箇所の設計のことです。データ入力するための「画面」や処理結果を確認するための「帳票」が代表的なユーザー・インターフェース(UI)となります。それ以外にも画面操作の方法を決めることもユーザー・インターフェース(UI)設計との重要な要素となります。「キーボード」を使って操作や入力をするのか、「マウス」をどのように使うのか(使うのか使わないのかも含めて)、「タッチパネル」なのか、最近の技術だと「音声認識」で制御するのかなどが該当します。これらをキチンと業務部門とレビューの中で確認しないと、最も「言った・言わない」問題に発展しやすい箇所なので後々トラブルの元となります。ならないためにもまずは、どれくらいインターフェースが必要となるのか、どのようなインターフェースが必要なのかを洗い出すことから始めます。前述したDFDやユースケース図が役に立つのですが、それらに登場する「人」や「システム」から伸びている線を確認します。DFDやユースケース図に記載漏れがなく十分に描かれていれば、基本的にその線の数がインターフェースの数となると考えて差し支えありません。マスター連携やユーザー認証などのシステムを維持するための管理面の要素は別途考えなくてはいけませんが、ユーザー向けのサービス面という意味ではこれでも問題ないと思います。この場合、「人と人」が線で紐づいている場合であれば、オフラインでの業務なのでシステムは関係ありません。「人とシステム」や「システムとシステム」が紐づいているものがあれば、インターフェースを開発する要素として設計を行う対象とします。ポイント・DFDやユースケース図からインターフェースを洗い出すことができる。・「人とシステム」、「システムとシステム」が紐づくものはすべてインターフェース設計の対象とする。要件定義工程で確認された要件をインプットとして進めていきます。要件定義工程では、「何を」行うか?または実現するのか?という観点で整理してきたと思いますが、基本設計では、それらを「どうように」行うのか?を定義していきます。ポイントは上で述べたとおりなので省略。その後の業務受入テストのテストシナリオを作成する際に参照する文書となります。そのため、ドキュメントが最新かつ正確な状態になっていなければ、誤ったテストケースを設定することになってしまい、いざテストを実施して不具合が発生した際に正しい判断ができなくなってしまうことにもなりかねません(プログラムが間違っているのか、ドキュメントが間違っているのか分からなくなってしまう)。要件定義の内容は、工程の最中にも頻繁に内容が変わったり、そのあとの工程でも変更が必要になったりすることもあります。そのたびに要件定義書の内容を修正して最新化していくのは手間のかかる作業です。要件定義の内容が正確でないと、その後の設計や開発に与える影響が大きいのと、問題が発生した際にユーザーとの間で「言った、言わない」の水掛け論になってしまう可能性もあるので必ず最新化して、ユーザーに承認されたことを確認できる状態(要件定義書に押印してもらうことやメール履歴に残すなど)を作っておくようにしましょう。ポイント・要件定義の内容は、ドキュメント化してユーザーの承認をもらうこと。・要件定義書は、後工程で修正が入った場合でも最新化を忘れないこと。要件定義工程ER図は、人、物、情報といった対象をエンティティとして長方形で表し、エンティティ同士をリレーションと呼ばれる線で結んで表現します。エンティティは、データ項目やキー項目を属性として表現するようにします。リレーションについてですが、2つのエンティティを結ぶときに、一方の1つのデータについて他方のデータが必ず1つにだけ結びつく場合もあれば、一方のデータ1つに対して複数のデータが結びつく場合もあります。複数のデータに対して複数のデータが結びつく場合もあるはずです。銀行業務を見た場合、通常支店は複数あり、1つの支店には複数の口座番号を持っていて口座番号には顧客氏名が1つありますね。口座番号には、別途定期預金などの別の口座番号が紐づく場合もあります(ない場合もあります)。そのような場合、支店エンティティ1件に対して口座エンティティは複数件結びつき、口座エンティティ1件に対しては、定期預金口座が0件以上結びつくようなER図の構造ができあがります。最後の定期預金口座の有無のようなものは、条件付きリレーションといいます。次に、エンティティについてですが、エンティティに含まれる属性情報のうち、そのエンティティ内で必ず一意になるデータ項目に着目します。これを主キーといいます。1つのデータ項目では一意に識別することができず、複数のデータ項目を合わせて一意に識別することでも構いません。この場合の主キーは複合キーといいます。先ほどの銀行業務でいうと、支店番号や口座番号などが各エンティティの主キーとなります。仮に、銀行が合併することになった場合はどうでしょう?A銀行とB銀行の支店番号が同じになってしまう、なんてことも起きる可能性は高いと思います。口座番号なんてのも重複が発生しそうですね。した場合は、支店番号エンティティのデータ項目に「銀行コード」を追加して、「銀行コード+支店番号」の複合キーを作って一意とするなどの対処をすることで大きな修正をすることなく設計を進めることが可能となります。最後に、エンティティを作る際のグループ化の考え方ですが、まず全くグループ化されていないトランザクションデータなどがあるとします。その状態のデータを非正規形といいます。繰り返し出現するデータ項目に着目して、それを別エンティティとして切り出します。この作業を行った後のデータの形を第一正規形といいます。続いて、キーとなるデータ項目とそれ以外のデータ項目の従属関係を調べます。従属関係とは、ある項目の値を決めると一意に値が決定する項目があると思います。それらの項目の関係を従属関係といいます。従属関係のあるデータ項目を1つのグループにまとめてエンティティ化します。この作業を行った後のデータの形を第二正規形といいます。次に、キー項目以外のデータ項目間の従属関係をしらべて、もしあればそれらをグループにまとめてエンティティ化します。ここまで実施したデータの形を第三正規系といいます。ポイント・ER図のリレーションは、1対1、1対多、条件付きの関連がある。・ER図のデータ項目が、他のエンティティの基本キーとなっているなら関連性あり。・エンティティは、第三正規形まで行ってグループ化せよ。Diagram)を作成する手順としては、最上流の(端的に言うと一番大雑把な)業務プロセスから作成していきます。これをレベル1とします。これは通常、業務全体を構成する複数のプロセス・ボックスと、主要なデータ・フローやデータ・ストア、外部エンティティから構成されます。このレベル1のDFDを眺めて、対象の業務全体が把握できる状態になっていることを確認してください。次に、レベル1で作成した各プロセス・ボックスをブレークダウンして徐々に詳細化していきます。レベル1の直後にいきなり細かいことを書き出すのはやめてください。詳細化していくことが漏れをなくすためにも重要です。このことは、「木を見て森を見ず」と同じことです。細かいことに集中するのはいいのですが、森全体を見ないがために全体像の把握ができず、方向性が誤っていることにも気づきにくいためです。ポイント・DFDは対象業務の全体像が把握できるものを作ってから、順次ブレークダウンすること。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。