初めての画面設計書（＋Notion活用方法公開！）
本記事は、Sun* Advent Calendar 2022、14日目の記事になります。
自己紹介
こんにちは 👋
2022年の春、新卒PMとしてSun*にジョインしたTam Xiuyao（タムシューヤウ）と申します！
多民族社会のマレーシアで生まれ育ちました。当地の高校を卒業後、日本に留学しました。大学ではデータサイエンスと機械学習の周りを研究して、スタートアップ会社でソフトウェアエンジニア（SE）としてインターンをしました。
アプリやサービスの開発以外に、もう少しお客様に近づいて、自分自身からコミュニケーションをとりながら一緒にサービスを作っていきたいので、現在はPM職にチャレンジしています！新卒研修後から今までの半年、ジュニアPMとして二つの案件に参画しました。
執筆背景
研修直後、最初に与えられたタスクは「画面設計書の作成」でした！画面設計書の作成は未経験でしたので、初めての画面設計書を作成時に直面した課題とその解決案、ゼロからイチまでの流れや過程をナレッジストックとして書き留めておきたいと思い、この記事を書きました。
日本語で記事を書くのは初めてですので、よろしくお願いします！
記事で使用した絵文字／略語について
💡 ポイント／「あったらいいな！」情報
💬 よくある質問
UI = ユーザーインターフェース (User Interface)
WF = ワイヤフレーム (Wireframe)
想定読者
・ベビー／ジュニアPM
・画面設計書に興味がある方
・Excel や Google スプレッドシートなどで作成していて、Notionなど別のツールでもっと簡単に画面設計書を作りたい方（Notionでの実例あり!）
画面設計書とは？
さて、そもそも画面設計書とは何でしょうか？ 以下で定義や目的をまとめましたが、画面のレイアウトにアクションなどの説明を盛り込んだドキュメンとになります。百聞は一見にしかず。こんな感じです。
一言で言えば、画面設計書はユーザーが操作する画面のレイアウトや表示項目、アクションなどを定義したドキュメントです。
画面のUIデザインに基づき、画面の構成、画面に表示される項目とその想定アクションや処理を可視化して一つひとつの画面の内容を明確にします。したがって、画面設計書はソフトウェア開発時によくある成果物の一つです。
画面設計書の目的
一番大切な狙いは、最終的な成果物がどのようなものかをイメージしてもらうことです。プロジェクトメンバー全員、クライアントを含めて共通認識であることを確保します。システムの完成イメージを持っている状態で開発を進めて行きます。
💡 これにより、クライアントと開発者の認識の齟齬を減らしてコミュニケーションコストも途中参画したメンバーのキャッチアップコストも大幅に削減することができます。
対象
画面設計書の想定読者は ①クライアント ②開発チーム（エンジニア、QAなど）
作成タイミング
①要件定義フェーズ または ②基本設計フェーズ
WFデザイン／UIデザインができたタイミング ⇔ 開発フェーズ入る前
ツール
・Google スプレッドシート / Excel
・Notion（今回のボーナスコンテンツ！）
画面設計書の中身
次に中身です。画面設計書に含めるべき情報は多いですが、以下のように、いくつかのセクションがあります。（表1参照）
ハンズオン！
記入情報が分かったら、すぐに画面設計書を作成できます！
下記、資料を用意して、さっそく始めてみましょう！ここでは、Google スプレッドシート を使った作成例を紹介します。
💡 画面設計書を作成時によく参照する資料
・画面一覧
・機能一覧／機能要件
・UIデザイン／WFデザイン資料
ステップ１：“このドキュメントとは?” ー 共通／書誌情報を記入する
読み手にこの書類について説明します。今後の管理や運用を円滑にするために、こちらの情報を疎かにするわけにはいきません。
💡 ドキュメントや画面の命名はプロジェクトのルールに従えば良いです。よくあるドキュメントの命名： {画面ID}＿{画面名}
💡 よくある利用対象：一般ユーザー、管理者やスタッフ、共通
時々、作成する画面の利用アクターが多すぎるので、読み手が画面IDと画面名だけでは、一目でわかりにくいこともあります。例えば、「A001_ログイン画面」というような命名の場合、誰のためのログイン画面？ 一般ユーザー？ 管理者？と悩むことになります。この場合「A001_管理者ログイン画面」か、書誌情報に「利用対象」の欄を追加して、利用対象を明確に記入したら、理解しやすくなります。
ステップ２：“画面の様子や見た目は?” ー UIイメージを貼り付けて画面部品ごとにIDを振る
読み手にこの画面について、どのような情報がどこにレイアウトされているかを伝えます。
⓪ UIデザインの画像を用意する（画像ファイルまたはスクリーンショット）
① Google スプレッドシートで 「挿入 → 図形描画」 を選択してUIデザインの画像を貼る
② 図形描画のテキストの機能を使用して画面部品ごとにIDを振る
③ UI／WFデザインのURLを記入する
💡 ナンバリングの目的は、項目定義する際に、各画面部品を識別するためであります
💡 開発時、エンジニアさんが画面や各部品の詳細仕様を把握しやすいため、UIデザインのURLを記入することをお勧めします
💬 よくある質問
Q：ヘッダー、フッター、サブメニューなどの共通画面部品のナンバリングは必要でしょうか？
A：画面数が多い場合、共通画面部品は別の画面設計書で定義して方が良いので、画面ごとにナンバリングは必要ではありません
ステップ３：“この部品は何？” ー 画面部品を定義する
ここは、UIイメージに指定されたIDを持つ各画面部品の名称、オブジェクト、I/O（入出力）、データベースとの連携を定義します。入力制限やシステム側からチェックすべき項目があれば、データバリデーション表で詳細な制限を定義して記入します。
💡 データベースとの連携の書き方
・データベースでのテーブル名とカラムを記入する（テーブル名.カラム名）
・例：users.email (テーブル＝users；カラム＝email)
こちらのステップはとても重要です！理由としては、項目の定義は次に定義されるもの（部品の想定アクションや処理、画面遷移など）と密接な関係があります。部品の定義が間違ってしまうと、開発チームの方での手戻りが発生し、修正するコストがかかってしまうためプロジェクト全体に影響を与える可能性があります。
💬 よくある質問
Q：ボタンは入力か出力か？
A：一般的に入力項目（入力欄、フォーム）以外は全て出力で統一するので、ボタン類は出力でOK
Q：トグルボタン（Toggle）のオブジェクト種類は？
A：ラジオボタン
Q：プレースホルダーの記入は必要か？
A：必要、プレースホルダーや想定された説明文は全て表示名の欄で記入する
ステップ４：“ボタン押下時はどうなるか?” ー 画面部品の想定アクションを記入する
一つひとつの部品がどのようなアクションを想定していて、どのような処理を行うのかを記述します。
部品毎に三つの質問をします：
① アクションはありますか？
② 画面遷移、ポップアップはありますか？
③ 表示するメッセージはありますか？
① アクションについて
各アクションのトリガー、概要はアクション表に記入します。
💡 ページが最初にロードされる際に、画面部品のデフォルト状態があれば、アクションにもそれを明記するが必要です
💡 よくあるトリガー
初期表示、入力時、ボタン押下、リンク選択、バリデーション認証OK／NG
② 画面遷移について
アクションに伴う画面遷移があれば、それを画面遷移表に記入します
💡 ユーザーからのアクションによって遷移画面が変わる場合、それぞれのケースを明記するが必要です
💡 よくある遷移方法
ボタン押下、時間経過
💡 よくある遷移タイプ
通常遷移、別タブを開いて遷移、外部サイト、ポップアップ／モーダルを開く
③ メッセージについて
アクションに伴うメッセージの表示があれば、それをメッセージ表に記入します
ステップ５：他に注意事項等あれば、「その他」セクションに記入する ー なければ、完成！
直面した課題
画面設計書は開発に必要な情報（画面一覧、機能一覧、UIデザイン）を一つの文書にまとめたものです。この一つの画面設計書に従ってエンジニアやQAなどのチーム・メンバーは開発を進めることが多いので、画面設計書は常に最新のバージョンに保っていなければいけません。
画面設計書は、UIデザインが確定した後に作成すると書きましたが、開発とともに変更が発生することもあります。または、WFをもとにUIデザインをおこす際に変更が発生することがあります。そのため毎回変更が発生する度に画面設計書も修正が必要になります。
今回、自分が参画したプロジェクトはUIデザインの変更が頻繁に発生していたので画面設計書の修正もかなり煩雑になっていました。画面設計書を更新する時に、手動で ①画像の差し入れ ②ナンバリングが必要になります。修正はたいしたことないように見えますが、実際には新しい画面設計書作ると同じぐらいの時間がかかってしまいます。
その時、UIデザインの修正の工数を減らすまたは自動化できたらいいな！と思いました。ということで、何か解決する方法はないかと探してみました。
そうだ、Notionを使って解決しよう！
なぜNotion？
理由の一つは、自分がNotionのファンだからです! 大学の時、Notionで自分の授業ノート、卒論の研究などを管理しました。そのため今回の課題でも、Notionなら何か出来るかも！と思いました。
そして、直面した課題について、プロジェクトのシニアPMと相談してみて、次のプロジェクトで「スプレッドシートよりNotionを使ってみてはいかがでしょうか？」と提案して、Notionでテンプレートを作成してみました！
（※現在のプロジェクトはこのNotionテンプレートを運用しています）
実際に運用してみたら、Notionから提供された便利な機能により、画面設計書作成の作業効率がUPしました！
早速、NotionができるTOP 5 ポイント見てみましょう
ポイント①：Notionのプロパティを活用して作成者、作成日時、最終更新者、最終更新日時は自動的に反映してくれます
ポイント②：複数ステータスを持つでも簡単に管理できます。さらに、一覧でステータスを活用してフィルター・ソートできます（※ステータスの表記、カラーなど全てカスタマイズできます！）
ポイント③：Figmaリンクを貼るだけで連携完了、いつも最新版のデザインをプレビューしています。デザインに変更が発生した場合もFigmaと画面設計書をダブルで修正する必要が無いです。さらに、NotionでFigmaを見る時に直接画像を拡大／縮小できます。
💡 Notionは、Figmaだけでなく、他のサービス(Slack、Github、Asana、Miroなど)との連携もできます
ポイント④：NotionでのToggle Headingを活用したら、セクション分けるは簡単になります。さらに、閲覧したいセクションのみを選んで開くことができるので、お客様がレビューする時にもらくらくです！
ポイント⑤：Notion自体はレスポンシブを対応しているので、特に設定を必要とせず、自動的に最適閲覧モードを調整してくれます。スマホ、タブレット、パソコン色んな画面サイズでもドキュメントの閲覧／編集はらくらくです！
Notionを活用することで、まだまだ改善できることがたくさんあります。
こちらは画面設計書、他のパートの様子になります↓
基本的にGoogle スプレッドシート／Excelでできることは、Notionもできます。もちろん、編集履歴が見にくい、表には簡単な公式しか実装できないなど、Notionにもデメリットがあります。しかし、私にとっては、メリットがデメリットを上回っていると感じています。今回紹介されたNotionがみなさんの今後の選択肢のひとつになれば嬉しいです！
総括・次回予告
最後までお読みいただきありがとうございました。今回の記事が少しでも皆様のお役に立てれば幸いです。 明日は、同じユニットのエンジニアである松本裕士さんから「多国籍チームでフロントエンドの実装ガイドラインを作っている話」をお送りします！ぜひ、お楽しみにしていてください ^^