初めての画面設計書。迷いながらも学んだこと

こんにちは。株式会社アイスリーデザイン　エンジニアリング部の清田です。

2024年の新卒として入社しました。今回アサインされたプロジェクトで、人生で初めて画面設計書の作成をすることになりました。プロジェクトの根幹を支える画面設計書の作成。新人の私にとってこのプロジェクトでの経験は教科書には載っていないリアルなものばかりでした。初めての経験で試行錯誤しながら進めましたが、その過程で感じたことや学んだことをまとめてみたいと思います。

画面設計書とは

画面設計書とは、システムやアプリを構成する画面内の項目や機能を明確にまとめた資料です。主に上流工程で作成されるため、上流工程の成果物の一部として扱われます。その後の開発行程においてはエンジニアやデザイナーが参照する重要な資料となります。画面設計書を作成する目的は、クライアントやエンジニア、デザイナー間で共通の認識を持ち、プロジェクトのスムーズな連携を図ることです。

画面設計書に含める内容は下記の通りになります。

共通情報

共通情報は画面設計書の管理を行うために必要な要素です。具体的には、プロジェクト名、システム名、バージョン情報、作成日、作成者、更新日、更新者などが含まれます。共通情報が整理されていないと、この画面設計書が最新のものなのか、誰がいつ変更を加えたのかがわからなくなるため、記載する必要があります。

画面レイアウト

対象画面のキャプチャや実際に表示されるコンテンツの配置を示す図などを掲載します。

使用API

使用しているAPI名・Method・URL・エンドポイントなどの情報を記載することで開発者がどのようなAPIを呼び出す必要があるのか、どの画面でそのAPIが利用されるのかが一目で理解できるようになります。

項目定義

各画面で表示される項目（ボタンやテキストフィールドなど）の詳細な定義を記載します。具体的にはNo、項目名、文字数制限、必須項目であるかどうか、取得方法、項目説明などが該当します。

アクション

各部品の想定動作や振る舞いを記載します。具体的にはボタンを押した際に実行される処理や画面遷移などが該当します。

作成のタイミング

画面設計書は、基本的に要件定義フェーズまたは設計フェーズで作成されるのが一般的です。

今回のプロジェクトでは設計フェーズで画面設計書の作成を行いました。画面設計書作成までのプロセスは下記のとおりです。

要件整理

PM・エンジニア・デザイナーがクライアントからのヒアリングを行い、要件の整理を行いました。

プロトタイプの作成

整理された要件をもとに、デザイナーがプロトタイプを作成。この段階で画面の大まかなレイアウトやユーザーフローの可視化がされていました。作成されたプロトタイプをたたき台にしてクライアントと共有ミーティングを行い、具体的なデザインや機能についてのフィードバックを元にブラッシュアップを行いました。

画面設計書作成

プロトタイプや要件を元に各画面の画面設計書を作成しました。
本プロジェクトではPM1名と、私を含むエンジニア2名で実施しました。

課題に対して工夫した点

今回のプロジェクトは、業界特有のルールや法令対応などを十分に理解する必要がありました。システムを使う役割によって業務フローが異なり、必要なデータや書類のフォーマットも様々です。業界知識や業務に関する用語をインプットしながらの設計書作成となり、後から振り返ると、非常にハードルが高いプロジェクトだったと思います。

業界ならではの特色を持つ画面設計書の作成を通じて、さまざまな課題に対応する機会があり、知見を深めることができました。その中でも大きく3点に絞って以下にまとめました。

未確定な仕様

業界特有のルールや背景知識が求められるため、具体的な記述に迷うケースがありました。どのように記述すべきか判断に悩む場面が多々ありましたが、作業を止めてしまっては前に進まないため、まずは暫定的な設定で対応を進めつつ、クライアントへの確認やチーム内での議論の頻度を増やすことで対応しました。

作業が滞りそうであれば、途中経過でも早めに内容を共有し、認識を合わせるように意識しました。暫定版でも次の工程へ進むため「ここまで決まっていればOK」といった最低ラインの基準を設けておくことで、全体の進捗を止めないことを心がけました。はじめは戸惑うことも多かったのですが、こうした小さなルールと情報共有を徹底することが、このような状況では有効だったと実感しています。

要件整理の遅れ

上記に関連しますが、画面設計書を作成する段階で要件の整理が完全に終了しておらず、新しい要件が追加されたり、既存の要件が変更されたりすることが頻繁に発生しました。このため作成中に何度も修正が必要となり進捗が良くない状況が続きました。

この状況を冷静に受け止め、何ができるかを考えながら進めました。我々が取り組んだこととしては、チーム内でのミーティングの頻度を増やし不明点を早期に解消する取り組みを行いました。チーム内で完結できること・クライアントに確認すべき事項の整理もでき、要件・仕様の整理も並行して進めることができました。

時間不足

先述した通り法律や決まり事が多い業界であるため、通常のシステム開発よりは設計書作成においても時間がかかるだろうと想像していました。それを見越してのスケジュールではありましたが、実際に業務を進めていくと、想定以上に時間が足りない状況に陥りました。

チームとして全ての画面に対して詳細に設計することが困難であると判断したため、全体の重要な画面や機能を先に作成し、優先度が低い部分については簡略化や後回しにする対応を取りました。この方法により、必要な成果物は時間内に完成させつつ、リソースが足りない部分に関しては後で対応できるようにしました。

学んだこと・気づき

要件定義を徹底することの重要性

要件整理の大切さを身をもって実感しました。最初に時間をかけて要件をしっかり確認・整理しておくことで、その後の作業がスムーズに進みます。逆に、あいまいなまま進めてしまうと、後から「この部分は想定と違った」といった修正が多くなり、余計な手間や時間がかかってしまいます。特に初めての案件では、早く手を動かしたくなる気持ちもありましたが、落ち着いて全体を整理することが結果的に効率的だと感じました。

仕様が未確定の場合の進め方

仕様が未確定の場合でも、暫定的な内容で進めながらクライアントやチームにその都度確認を取るようにしました。曖昧な部分をそのまま放置せずに共有し、早い段階でフィードバックをもらうことで、後戻りを減らし作業の効率化につながったと感じました。こういった取り組みを通じて、完璧を目指すよりも、まずは動きながら調整することの大切さを学びました。