【その4】基本設計書 ①画面
今から 4 年以上前に MBO に書いてしまった、新人ちゃん向けのメルマガが出てきた。
これで半分！？昔のあたくし、よぉ書いたなぁ～。
今どうやって設計書を書いているのかがとても気になる。
昔と比べたら、今の方がスピード勝負って感じするからね。納期は短くなっていく一方。
そんな中で、どのように設計してるんだろう？
「設計書を書く能力」って、SE にとって未だ必要なのかな？
てか、画面設計やこ、ここ何年もやってないわー。
今やってできるのかしらん？
めちゃくちゃ結合テストを意識して書いているのはよく見てとれたけど。
既にトラウマはあったんだな。
※以下、当時の文章。
前回までは基本設計の概要を紹介しました。
今回からは「基本設計書を具体的に書いていくには？」の部分に焦点を当てて、ポイントを抜粋して解説していきます。
個人的な観点ですが・・・
「設計書を書く」という行為は SE にとって非常に大事なスキルの 1 つだと私は思っています。
少し大きなプロジェクトになると、設計担当とテスト担当が分かれます。
その際、テスト担当が困らないよう、テストに必要となる事項を漏れなく・簡潔に記載することが必要です。
同時に、それは品質向上にもつながります。
例え、どんなに納期の短いプロジェクトであっても。
画面については特にお客さんの目に触れやすい部分であるため、レビューで見直しが入ることはしょっちゅうあります。
その際「何がどうなっていたら正解か」を念頭に置くと、テスト時に困らなくて済みます。
画面設計とは
- 画面設計の意味
画面設計とは何？ Weblio辞書
1）画面設計とは、システム開発において、ユーザーが操作することになる画面のレイアウトや表示項目などの設計を行うことである。
→ 非機能設計であった、「ユーザビリティ」「アクセシビリティ」を考慮する必要がある。
画面設計で決めること
大きく分けて、以下の 4 つです。
- 画面で表示する項目
- DB のどこから取得されるのか
- どのようなイベントがあるのか
- チェック処理
１. 画面で表示する項目
画面上に表示する項目を決めます。
ただ表示するだけではなく、以下のようなものも合わせて決めます。
（細かいかもしれませんが、ここを詰めないとテスト時に何が正しい仕様かが分からなくなり、困ることが多々あります）
＜決める必要のある内容＞
| 内容 | 概要 |
|---|---|
| 画面項目名 （論理名、物理名） |
画面項目の日本語名（論理名）と英字名（物理名）です。 英字名は実装の際に使用します。 |
| 画面項目種類 | 画面項目の種類です。 入力できない項目はラベル、一行テキストはテキストボックス等を記載します。 |
| 表示有無 | 画面表示される項目か、されない項目かを記載します。 画面表示されない項目は処理にのみ使用します。 |
| 表示位置 | 文字や画像等の位置を記載します。 左寄せ、中寄せ、右寄せを記載します。 |
| 初期値 | 初期表示時に表示する値を記載します。 空欄なのか、DB から取得した値なのかを記載します。 |
| 入力桁数 | 画面上で入力を許す桁数を記載します。 DB 上の桁数を意識する必要があります。 |
２. DB のどこから取得されるのか
画面上に表示する項目について、どのテーブルのどのカラムから取得するかを決めます。
画面に表示するデータのほぼ全ては DB 上に存在するため、画面項目とのひもづけを行うことで、取得時の SQL （の大枠）が分かるだけでなく、テストの際もどのデータが表示されるのが正しいかが分かります。
＜決める必要のある内容＞
| 内容 | 概要 |
|---|---|
| 取得元 DB（テーブル名） | 画面項目の取得元のテーブル名です。 |
| 取得元 DB（カラム名） | 取得元 DB（テーブル名）にあるカラム名です。 |
３. どのようなイベントがあるのか
その画面で起こりうるイベントと、その処理概要を決めます。
※イベント：処理が走る部分とその契機となる操作（ボタンを押す、プルダウンの値を変更する、等）。処理が走るという意味で、初期表示もイベントに含めることが多い。
（イベント＝機能 としているプロジェクトも見受けられます）
＜決める必要のある内容＞
| 内容 | 概要 |
|---|---|
| イベント一覧（実行タイミング） | イベントが実行されるタイミング（契機となる操作）を記載します。 |
| イベント一覧（処理概要） | イベント内で走る処理の概要を記載します。 |
＜補足＞※私見です！
イベント概要をどこまで書くか？という問題がよく出てきます。個人的には「詳細設計書があるなら概要のみ、詳細設計書が無いなら処理概要に詳細を書く」方が良いと思います。
４. チェック処理
画面項目に対するチェックを記載します。
チェックが正しく実施されないと、不正なデータのまま DB に登録されてしまったり、正しいデータを入力しても登録されない等、システムとして不整合な状態になってしまいます。
また、テストの際にもどのようなデータが OK で、どのようなデータが NG なのかが分かるため、できるだけ詳細に記載することが望まれます。
＜決める必要のある内容＞
| 内容 | 概要 |
|---|---|
| 必須 | 入力・選択が必須な項目を記載します。 主に DB の NOT NULL 部分です。 |
| 入力チェック | 入力項目に対するチェック内容を記載します。 （日付チェック、相関チェック、等） |
| メッセージ ID | チェックでエラーとなった際に画面に表示するメッセージの ID を記載します。 |
＜補足＞※私見です！
表記揺れの防止やメッセージ文言変更に備え、メッセージは一元管理した方が良いです。
画面設計のコツ
- 画面項目と画面レイアウトは分けて考えること
画面設計では画面項目を決めると同時に画面レイアウトも決める必要がありますが、この 2 つは完全に分けて考えてください。
まずは画面に出す項目を決めてから、画面レイアウト変更を許容する方が絶対お勧めです。
画面項目が決まらずに画面レイアウト変更を許すことになると、画面項目とテーブルのひもづけが変わるだけでなく、テーブル構造も変えなければならない場合があり、詳細設計～実装が進まなくなります。
（現に上記のような状態に陥り、大きく遅延したプロジェクトも存在します）
- 画面項目の名称は統一させること
画面項目の名称はシステム内で統一させてください。
NG 例）
DB 上では同じ項目を取得する画面項目について、A 画面では「ユーザー ID」、B 画面では「ユーザー番号」
→ このような記載はバグの元です。
