今回は、システム開発における画面仕様書の書き方を紹介します。
システム開発には、設計と呼ばれる工程があります。
設計工程では、要件定義工程によって定められた要件を満たすように、どのようにシステムを作成するかの設計書や仕様書を作成する工程です。
設計工程では、このようないくつかのドキュメントを作成するのですが、
画面仕様書というのも、そのうちの一つです。
画面仕様書というのは、システムの画面にまつわる決め事を記載します。
この画面仕様書ですが、作成すると一言といっても何が何やらどこから手をつけたら良いかわからないという方も多いのではないかと思います。
そこで、今回画面仕様書の書き方を紹介したいと思います。
はじめに
残念ながら、画面仕様書の正しい書き方というのは存在しません。
Googleで「画面仕様書 書き方」「画面仕様書 サンプル」と検索してみても、明確な答えは見つかりません。
なので、ここで紹介するのは
「画面仕様書としての体をなすために、これらを書いておけばOK」
という項目の紹介にします。
これらの項目を満たした仕様書を自由に作成し、それ以外のところ（書式の形式、過不足のある項目）は、それぞれの組織で微調整していただければと思います。
というわけで、画面設計書には少なくとも以下が必要となります。
・画面一覧書
・画面遷移書
・画面レイアウト書
・改訂履歴
・表紙
これら5つになります。
では、詳細を見ていきましょう。
画面一覧書
画面一覧書です。
画面を一覧で確認するために存在します。
画面一覧書には、以下の項目を持たせます。
- 画面ID
- 画面を画面名以外で識別するためのIDです。階層ごとや機能ごとに連番を振るのが一般的です。
- 画面名
- 画面名は画面を識別するための名前です。一目でわかりやすい名前が望ましいです。
- 画面説明
- 画面の説明です。体言止めにせず、きちんと主語述語を用いて端的な文にすると見やすいです。
他に、機能も書くこともあるかと思います。
書いても良いのですが、これはあくまで画面一覧書なので、画面に紐づく機能を書くようにしましょう。
（機能一覧を書き出してどの画面に紐づくか...という逆のプロセスを踏まないように注意しましょう。という意味です）
画面遷移書
画面遷移書です。
画面がどのように遷移するのか、どんなイベントによって遷移するのか、全体像を把握するために存在します。
画面遷移書には、画面遷移図を記載します。
画面遷移図は、画面を矢印で結んだ図です。
画面遷移図は、言葉であれこれ説明するよりも、図をみた方が早いと思います。
これに関しては、「画面遷移図」とGoogleに入力して画像検索をすればたくさん出てきます。
後がどれぐらいのクオリティのものを作るかです。
簡素なものを作るのであれば、
・画面名を白枠で囲う
・どのようなトリガーによって画面が遷移するのか矢印付近に書く
この2点だけで十分でしょう。
凝ったものを作るのであれば、
・画面のレイアウトを模したものを使う
・どのウィジェットの動作によって、どの画面に遷移するのかを書く
・エラーの際の遷移も書く
これらに対しても書くと良いでしょう。
注意点としては、矢印の向きがいろんな方向へ向いたり、交差することはできるだけ避けましょう。
画面レイアウト書
画面レイアウト書です。
画面のどこに何のウィジェットを置くのか、画面のサイズはどれぐらいなのかを記載します。
（建築物の設計図をイメージするとわかりやすいかもしれません）
画面一覧書には、画面イメージを記載します。
画面イメージとは、画面を想定した枠の中に、ウィジェットを記載したものに、サイズを記載したものです。
と、言葉で言われてもよくわからないですよね。
画面イメージで最もわかりやすいのは、こちらにありました。
第5回 ［画面編］見れば“わかる”「画面レイアウト」の作り方 | 日経クロステック（xTECH）
リンク先の中断あたりに、先程言葉で説明したものがありますよね。
このように、枠を作成してどの位置に何を置くのかを記載しています。
この例では書かれていませんが、寸法を記載するケースもあります。
つまり、このウィジェットは縦と横が〇〇pixelで、位置は××pixelと記載するケースもあるということです。
（最近では、pixelを決めうちせず、マルチプラットフォームに対応できるように比率で決めることも多いです）
寸法を書くときは、記入のルールがありますので、確認しておきましょう。
寸法の記入の基本ルール
画面一覧書には、以下の項目を持たせます。
- 部品ID
- 部品を識別するためのIDです。
- ちなみに、画面ごとにIDを振り直すので、IDというほどかっちりわけなくても良いです。
- 部品の種類
- 例えば、LabelやButtonなど部品（ウィジェット）の種類を書きます。
- 部品の説明
- 何をする部品で、どういう動作があるのが、どんなイベントがあるのかを記載します。
改訂履歴
改訂履歴です。
いつ、誰が、どこを修正したのかを把握するために存在します。
改訂履歴には、以下の項目を持たせます。
- 改訂日付
- 改訂日付を記載します。
- 改訂者
- 改訂者を記載します。所属まで書いた方が丁寧です。
- 改訂内容
- 改訂内容を記載します。どのページの、何を変更したのかを記載します。
- なぜそのような変更をしたのかについては、改訂を行なった各ページに記載します。
表紙
表紙です。
画面仕様書は、上記を束ねたものです。
表紙自体に特別な意味はありませんが、紙の書類の名残で表紙をつけることが多いです。
表紙には、この書類が画面仕様書であることがわかるように、画面仕様書と記載します。
そして、システム名を記載しましょう。
まとめ
というわけで、画面仕様書の作り方を紹介しました。
書き方は千差万別で環境によって大きく違います。
そこで今回は、どの環境でも最低限必要となることを紹介しました。
・画面一覧書
・画面遷移書
・画面レイアウト書
・改訂履歴
・表紙
これらをまとめて、画面仕様書となります。
ここまで読んでいただき、ありがとうございました。
システム設計を学習するのにおすすめの教材
システム設計について、しっかり基礎から学びたい、実践的なスキルを身につけたいと考えている方向けに、おすすめの書籍を紹介します。
システム設計ができるようになるには、もちろん経験も大事ですが、基礎的な理解も不可欠です。
キャリアの早い段階からシステム設計ができるようになると、上流工程へのステップアップに有利に働くので、こちらで紹介する書籍を読んでおくことを推奨します。
エンジニアなら知っておきたい システム設計とドキュメント
システム開発に必要な、設計書の書き方や標準化や運用まで解説した、初心者向きの書籍です。
システム設計・計画の最新知識を平易に解説
企業や組織のシステム開発では、設計書の取りまとめなどの工程が大切です。本書は「組織でシステムを作る」ことを前提に、必要とされる設計書の書き方と運用の手順を解説します。また、クラウドやアジャイル開発など、現代コンピューティングの新要素を含めた、システム構築の現実解を知ることができます。本書は、インプレスの技術メディアThink ITのWeb連載記事「令和時代のシステム開発では、どのような設計書を書くべきか」を書籍化したものです。書籍化にあたって、大幅に加筆・修正をしました。
システム開発の全体像をざっと把握する分に、非常におすすめです。
図解が多く初学者の方でも理解しやすいような構成になっています。
2022年1月に発売されたため、クラウドやアジャイル開発など令和の現在に使われる内容もサポートしています。
