こんにちは！
マンハッタンコードでプロジェクトマネージャー（以下PM）のみちこ（@MHTcode_michiko）とエンジニアのTOM（@MHTcode_TOM）です！

今回は開発に必ず必要なUI仕様書の書き方ついて、弊社が実際に取り組んでいる実績を元にお話させていただきます！

UI仕様書とは？

UIとはユーザーインターフェースの略であり、利用者と製品やサービスの接点を指します。
開発においての利用者との接点は画面になります。
UI仕様書はどこにどのような機能があるのか？どこに遷移するのか？など完成イメージが明確になっている資料のことです。

同じく開発では必ず必要になる設計書というものがありますが、こちらは仕様書とは違い制作過程が記載されているもので、より技術的なことが記載されています。受託開発の場合、仕様書はクライアントと一緒になって作り上げるもので、技術的なことがわからなくても作成することができます。

なぜUI仕様書を作るのか？

先ほども説明しましたが、UI仕様書は完成イメージが明確になっている「結果」が記載されている資料なので、これがない状態で開発を進めると人によって作るものがバラけてしまったり、テストに移れなくなり認識齟齬の回数が増え、工数も増加してしまいます。
開発者間の問題だけではありません。開発者はUI仕様書の内容を満たすように実装をする一方、クライアントはUI仕様書に書かれているものを作ってもらえると考えます。
そのためしっかりとしたUI仕様書を作成することで、クライアント側の要求と異なるものを作ってしまうというリスクを軽減することができます。
誰が見ても完成イメージが伝わるように仕様書を記載しましょう。

また、仕様は最初からずっと変わらないことはほとんどありません。
仕様は変更されるものです。

その変更に合わせて仕様書を更新することも不可欠となります。
更新がなされない場合、その変更を検知しているのが一部の人だけとなる可能性がなります。

UI仕様書が更新されないままプロジェクトがひと段落し、時間が立ってか新たな人が改修するときなどに大きな問題が生まれることとなります。
実際のコードとUI仕様書で差分が生まれた時、何が正しいかがわからなくなってしまいます。

こういった理由で、UI仕様書を整備することはとても重要です。

UI仕様書のサンプル

マンハッタンコードで使用している仕様書は以下の要素でできています。

対象画面（画面左）
どの画面のどの箇所に当てはまる仕様なのか可視化するために必要です。
現状ダミーで情報を入れているものや、未確定のものは吹き出しなどでわかりやすく表現してあげると良いです。

名称
ユビキタス辞書などで定義されているものを使用しますが、名称が決まっていないものがあればクライアントと情報をすり合わせて名称違いが内容にしましょう。

仕様
簡単な機能であっても具体的に記載し、OOだった時などパターンを複数出しておくと開発を進めていく際にスムーズに進めることができます。

ポイント：図を使って視覚的に伝える

上記の画像はログイン画面のUI仕様書でかなりシンプルなものになりますが、どのボタン・ボックスがどんな機能を持っているか実際のデザインデータをもとに表現しています。
簡単な画面だといってテキストだけで箇条書きにしてしまうと、後々画面数が増えたり仕様が複雑になった場合に確認漏れなどリスクになる可能性があります。
また、海外の方と開発をする場合、言葉の壁を乗り越えるためにも視覚的に表現することは重要になります。

まとめ

・UI仕様書は完成イメージが明確になっている「結果」が記載されている資料
・わかりやすいUI仕様書を書くことで開発者間・クライアントとの認識齟齬を減らすことができる
・良いUI仕様書を作るためには図を使って視覚的に伝えることがポイント

ここまでUI仕様書とは何か、その書き方やポイントについてお伝えしてきました。
良いUI仕様書を作成することはプロジェクトの進捗や成果物の精度を上げ、結果的にクライアントの満足度の向上に繋がります。
本記事がUI仕様書作成の参考になりましたら幸いです。

宣伝

お仕事のご相談・ご依頼
マンハッタンコードは、スマートフォンアプリの開発に特化しております。エンジニアリングから、デザイン、プロジェクト推進などアプリ開発を総合的に請け負うことが可能です。
弊社のホームページからお問い合わせください。

お問い合わせの際には「noteの記事を読みました！」と一言入れていただけると嬉しいです！