phone-1537387_1280

基本設計(外部設計)とは

おおよそのシステム全体の目的/概要/機能要件などの要件定義書を元に、次の段階は「基本設計(外部設計)」といわれる設計フェーズに入ってきます。提示されたそれぞれの設計書に対して、依頼者側はどのような点を注意すべきなのか、検討すべきなのかについて説明します。

具体的に、画面構成(レイアウト)や画面内の項目、帳票設計などをおこなっていきますので、より具体的なアプリケーションの顔が見えてくる段階になります。

本設計書は、システム業者が制作を担当し、主に依頼主側が内容を検討する手順になります。

画面レイアウトの設計

EXCELやWORDで作成した画面設計図や、より画面操作(ボタンを押したときの動き)などを解りやすく説明するためにモックアップ(プロトタイプ)を作成し、実際に模擬的に操作しながら確認する手法を用います。

いずれの場合も、依頼主側は実際にシステムを利用するシーンを想定しながら、良い悪い、改善してほしい点などを指摘することが目的になりますので、重要なフェーズになります。

主な検討すべき点

画面レイアウトにおいて、依頼主側が検討すべき点をあげておきます。(システムの内容によって、当てはまらない項目もあるかと思いますが、ご参考まで)

デザイン・操作性 全体のデザイン(色)やフォントの使い方、ボタンの色(形状)などを検討します。やはり、見た目が良いことも重要な要素です。コーポレートカラーや自社のロゴがある場合は、それを利用していただくのも良いと思います。
また、操作性も重要な点です。紙ベースでの確認の場合、難しい場合もありますが、入力しやすい順番で項目は並んでいるか、機能ボタン(登録や検索など)は視覚的に解りやすい場所に配置されているか、なども検討内容になります。
画面遷移 全体の画面と、画面遷移(次の画面に移るまたは戻る)流れを確認します。最近では、ディスプレイの解像度も大きくなり、一画面に表示できる情報も増えていることもあり、画面遷移が少ないシンプルな構造が好まれる傾向にあります。
項目(ラベル) 業務システムでは、その情報を現す項目名(ラベル)を配置し、何を値を表示しているのか/何を入力するのかを明示します。それには、必須(必ず入力しなければならないもの)などがあります。たとえば、必須項目のラベルは赤字で表示するなど視覚的に何をしなければならないかが理解できるように設計してもらいましょう。
用語の統一 項目名やボタン名など、同じ項目、同じ機能には同じ言葉を使うように統一しましょう。
極端な例ですが、ある画面では「商品番号」、ある画面では「製品番号」これが同じものを指しているとしたら、混乱を招くことになります。仮に、普段からあまり用語が統一できていなければ、この機会に統一した用語を整理しておきます。
エラー処理 必須項目の入力漏れや、数字入力項目に文字が入力された場合など、エラーの場合の動きを確認しておきましょう。できれば、エラーの箇所が明示的(例えば、エラーフィールドの色が変わる、メッセージが出るなど)に解るようにすると、操作する側も混乱することが無くなります。また、エラーメッセージなどもメッセージ一覧とその内容などをまとめて整理しておくことで、後の操作マニュアルや運用マニュアルを作成する準備にもなります。

内容が少し細かくなりますが、このフェーズで合意したものがそのままアプリケーションになりますから、この段階でできるだけ細かくチェックし、要求するべきものはしておくことが重要になります。

後で、全体に関わるような修正が発生すると、工期に影響をしたり、大きな改修になり費用の面にも影響がある場合があります。提案されたものをしっかりと確認し、気になったところは遠慮なく相談しましょう。

帳票レイアウトの設計

ペーパーレスを心掛けたとしても、やはり事務処理では紙ベース(EXCELやPDFなどの電子データも含めて)のアウトプットが必要になる場合があります。
こうした、外部に出力するデータや紙媒体として印刷するものを設計するのが帳票レイアウトです。
ここでも、画面仕様と同じように、その内容について検討します。

主な検討すべき点
出力の方法はそれで良いか システム化によって、あるいは改修するにあたって、従来の紙で出力するのか、それともEXCELやPDFなどの電子データで出力した方が良いのかを検討します。後にファイリングするとしても、PC上に保存しておいた方が良い場合もあります。出力後の用途を考えて判断します。
レイアウト レイアウトでは、用紙サイズや出力する項目、位置などを決めていきます。
従来A3用紙だったものを扱いやすいようにA4に変えたり、ヘッダーやフッターを統一したりなど、改善も含めて検討しましょう。
項目 システム化によって、追加した方が良い項目などもあります。たとえば、出力した日時や、版(変更履歴を管理)、出力担当者なども、システムで自動印刷できるようにすると管理の面で役立つ場合があります。
棒グラフや円グラフなどを使う 営業会議資料などでは、表形式よりもグラフを利用することでより視覚的な資料を作成することができるようになります。
要件、用途によって表現方式から見直しを図り、システム化するように要望しましょう。

システム化をきっかけに、ペーパーレスにし納品書や請求書をPDFなどのデータ管理にする方法は良くある改善になります。その場合でも、データ(PDF)の保管場所を考えたり、過去の納品書や請求書をシステムから簡易的に検索でき、再出力できるのか(必要がある場合に)など、運用面も合わせて、検討します。

その他の設計書

制作するシステムの内容によっては、以下の設計書を作成し両社で確認する場合があります。

その図書と、記載されるおおよその内容をは以下のとおりです。

インターフェース仕様書

他のシステムとの情報の連携がある場合に作成するのが、インターフェース仕様書です。
例えば、請求書や領収書の情報を経理システムに連動し、伝票の起票を自動化する場合には、そのタイミングとデータの内容を記載した設計書を作成します。

※本仕様書で依頼者側が注意する点としては、タイミング(いつ、どのような操作が必要なのか)については検討が必要になります。

データベース設計書

次の内部設計書で作成する場合もあるのが、データベース設計書です。画面から登録した内容や計算結果などを保存しておくデータベースの内容を記載した図書になります。

※検索や情報の入出力設計などを考慮し、設計しますのでIT部門や自社に技術者がいない場合は、システム業者に任せて良い図書になります。画面設計や帳票設計でしっかりと確認できていれば、大丈夫な領域です。

The following two tabs change content below.

田邉弘美(たなべひろみ)

メーカーのプログラマーを経て27歳で独立起業。数々多くの企業のシステム構築を手掛けてきました。得意な分野は基幹システムや営業支援、顧客管理など社内業務のシステム構築。プロジェクトでは、主にお客様の要望整理や業務改善などのコンサル部分を担当。私の無理難題も難なくこなす頼もしいスタッフ(技術者)に囲まれ、奮闘の毎日を送っています。

最新記事 by 田邉弘美(たなべひろみ) (全て見る)