連携を強化する開発プロセスの核心解説

はじめに

はじめまして！UXDIGです。

UXDIGは、Tech × CreativeのMIXから生まれるコラボレーションを推進するエンジニア＆デザイナーの越境組織です。デザイナーとエンジニアの協業における課題解決を目標に、2021年に社内活動としてスタートしました。現在は月に2回ほどLT会を開催しています。

そんな私たちですが、2024年度の新卒研修で「開発における職能間連携」をテーマに研修を実施しました。この記事はそのリライトとなっており、開発プロセスがどのように進んでいくのかということや、開発を進める上で重要となる仕様書の管理や作成方法、共通認識を醸成するためのER図やUIモデル図について説明しています。

特に仕様書に関しては、デザイナーとエンジニアが思い描く「仕様」がしばしば異なり、そこから誤解やトラブルが発生することが多いです。ここでは、そんな仕様書問題をどのように解決していくかについても考えていきたいと思います。

techtekt.persol-career.co.jp

はじめに
開発プロセスがどのように進んでいくか
仕様書の管理について
実際のデザインデータ
- フォーマットで記載されている情報
- 弊社のプロジェクトでの共通していること
技術仕様作成のポイント
共通認識醸成のためのER図
- OOUIの考え方：ユーザー体験に基づいて考える
  - 体験〜UIモデル図
- ER図とは？
さいごに

開発プロセスがどのように進んでいくか

一般的な開発プロセスは以下のように進んでいきます。

戦略・企画検討
要件定義
仕様・設計
開発製造
テスト
リリース

上流の企画検討まではビジネス（企画）・デザイナー・エンジニア３者合同で進めますが、プロジェクトが進行するにつれそれぞれの責任領域で成果物を作っていきます。
企画フェーズで検討された業務要件や体験設計、機能要件をもとに、各要件を定義し開発スコープが定まり、プロダクトの詳細な仕様設計へと進んでいきます。仕様をもとに実際に開発製造、テストをクリアすればリリースとなります。

しかしながら「こういうものを作ろうね！」（仕様設計）と決めたものがある程度形としてみえてくるのはテスト段階になります。そのとき「思ってたんと違うんですが」が発生しがちです。

この課題は、仕様が「文書化された情報」「画像化された情報」だけで共有されるのではなく、「認識や意図」としてチーム内で十分に伝わっていないことが主な原因です。たとえ要件や仕様が形式的に満たされていても、デザインや動作、ユーザー体験などに関する細部の解釈がズレてしまえば、最終的なプロダクトの完成度に影響を与えてしまいます。そのため、仕様設計の段階から具体的なユースケースやユーザーフローを踏まえた共有を重ね、「目に見えない仕様」も含めて、チーム全体が共通の理解を持つことが重要です。

ここでの状態目標としては「目に見えない仕様もちゃんと共有できている」になります。

その目標に近づくためにも、次に述べる仕様書の管理を適切に行うことが重要になってきます。

仕様書の管理について

アプリケーション開発における仕様とは、製品の機能、ビジュアルデザイン、ユーザーインタフェースなど、開発を進行するための詳細な要件と指示を示す一連のガイドラインのことです。これらをまとめたものを仕様書といいます。
仕様書は、デザイナーもエンジニアも頻繁に使うものであるため、適切な運用をしないと開発を進める上で支障が出てしまいます。
この章では、仕様書の管理について、2種類の方法と、それぞれの特徴について説明します。

管理方法

今回、以下の2つの方法をとりあげます。

ドキュメントツール + Figma で管理する方法
Figma で一括管理する方法

※Figmaは主にビジュアルデザインの作成で使われるツールです。

www.figma.com

ドキュメントツール + Figma

ドキュメントツールと Figma で仕様を管理する相互補完パターン
ドキュメントツールと Figma に重複して情報が掲載してある場合、どちらかを修正するともう一方も修正する必要があり、管理が複雑になる
エンジニアはドキュメントと Figma の両方を確認する必要がある
ドキュメントがあることで、後々仕様を確認する際に検索しやすくなる

Figma で一括管理

Figma で機能的な仕様もUIの仕様もすべて管理するパターン
エンジニアは Figma だけを見て開発をすることができる
Figma のみの管理だと、検索性に欠けるため、後々仕様を確認することが困難になる
小さなプロジェクトだったり、作り切りのアプリケーションであれば向いているかもしれない

どっちがいいの？

先述の通り、どちらもメリットデメリットがありますが、UXDIGメンバーが所属しているプロジェクトでは前者を採用しています。また、他社事例を調べたところ、やはり前者のパターンが多かったです。
ただ、プロジェクトのフェーズや人数などの様々な条件によってどの方法が適切かは変わるため、チームメンバーで適宜コミュニケーションを取りながら、最適な方法を模索していくのが良いと思います。

実際のデザインデータ

ここで弊社の某プロダクト開発で使われているFigmaファイルのフォーマットをご紹介します。

Figmaは基本的にはデザインのみが置いてあり、具体的な仕様はプロジェクト管理ツールであるZenhubのEpicで管理し、企画職のメンバーが主に作成/編集しています。
別のドキュメントツールにも仕様書はありますが、実装時には参照してはおらず、時間が経ってから仕様を確認するなどのアーカイブ用となっています。こちらも企画が作成/編集しています。
エンジニアは、画面デザインは Figma を参照しつつ、Epic で細かな仕様の確認をしながら実装していきます。

※ZenhubはGithubと合わせて使用するプロジェクト管理ツールです。

www.zenhub.com

フォーマットで記載されている情報

Epic番号
リファインメント日
リリース日
担当者
Epic名

弊社のプロジェクトでの共通していること

画面の通し番号
要件と画面を突合させつ項番
画面にコメントで機能要件を記載
遷移図

どれが最新かを明示し、要件と画面、技術仕様書のトレーサビリティー、つまり「いつ」「何処で」「誰に」よって作られ、編集されたかが後から追えることが重要です。

技術仕様作成のポイント

プロジェクトにおいて作らなければならない文書

画面デザインの仕様書の管理については上で解説しましたので、今度はプロジェクト全体の視点に立ってみましょう。開発プロジェクトにおいて、作らなければならない文書とはなんでしょうか？

プロダクト要件文書 (Product Requirement Document)
ADR (Architecture Decision Record)
画面設計書
技術仕様書
機能別仕様書
画面一覧
....

調べてみると、たくさん出てきます。

作るべきものが確定している大規模システムであれば、こういった文書を一式作成しながら進んでいく形になるでしょう。

しかし、プロジェクトを立ち上げ、「企画→デザイン→実装→効果検証→改善」のサイクルを高速に回していく時期に、これらすべてを作成できるかどうかというと難しいのが現実です。

そこで、上記の文書の中で、プロジェクト立ち上げ期でも比較的よく作られているもの、以下の三つについて説明します。

画面設計書
プロダクトバックログ＆技術仕様書
機能別仕様書

画面設計書は上で説明したように、画面（ユーザーインターフェースやビジュアルデザイン）についての詳細を定義したもので、Figmaやドキュメントツールを使用して作成されることが多いです。

プロダクトバックログは定義としてはアジャイル開発の用語ですが、ここではプロダクトの中で完成させる必要があるアイテムをまとめたリストという意味で使っています。実現したいユーザーストーリーや解決したい課題をアイテムとして一覧化、プロジェクトとしての優先順位を決定し、見積もりをします。この一覧を定期的に見直していくことで、プロジェクトとしての目標を確認し、必要に応じて調整することができます。
プロダクトバックログのアイテムに技術的な仕様を記述することで、技術仕様書として使用できます。技術仕様書を書くことにより、実現するべきストーリー・解決したい課題について、「なにを・どこまで・どのようにやるか」の認識を合わせることができます。

機能別仕様書は機能詳細仕様書とも呼ばれるアプリケーションの機能要件の詳細を記述した文書です。開発エンジニア、テスト担当エンジニア、プロジェクトマネージャーなどがアプリケーションの動作や要件を正確に理解し、実装・検証するためのガイドラインを提供します。

それでは、これらの文書はプロジェクトのどの段階で作成されるのでしょうか？

ここで、ソフトウェア開発プロセスモデルの1つ、V字モデルを見てみましょう。V字モデルは、ソフトウェア開発における各プロセスを開発フェーズとテストフェーズに分け、それぞれのフェーズが対応する構造になっています。
画面設計書や技術仕様書は基本設計、機能別仕様書は詳細設計の段階で作成される成果物となります。

例えば、要件定義に不足や不備があった場合に、それを発見できるのはシステムテストの段階になります。要求分析や要件定義などの初期のプロセスに問題があると、それを発見できるのはプロジェクト終盤の段階になる場合があることがわかります。
特に初期リリースまでの間はこのV字モデルに近い形でプロジェクトが進行することが多くあります。したがって、プロジェクト初期の段階でチームの認識を合わせることは、終盤に入ってから致命的な問題が発見されるのを防ぐことに繋がります。そのために、上記のような文書が必要となってきます。プロジェクト立ち上げ期においては、初期の段階で速やかに合意形成を行うこと、そのために必要な最低限の成果物に絞って作成をすることが重要になってきます。

プロジェクトの状況を考慮する

どういった文書の作成が必要かは、プロジェクトの状況によっても変わってきます。

アプリケーションの初回リリース前、MVP(Minimum Viable Product) を開発中のプロジェクトはどうしているでしょうか。
このフェーズでは「作るもの」の認識を合わせるために、画面設計書をFigmaでビジネス側とデザイナーが共同で作成する場合もあります。その画面設計書をもとに、エンジニアが技術仕様書を作成します。ビジネス側が技術仕様書の要件部分を記載し、詳細化をエンジニアが記載することもあります。
開発速度を高く保つことが必要なため、各役割に固定化せずフレキシブルに作成を進め、作成される文書の種類は絞り込んで最小限に保つことが多いです。

それでは、アプリケーションが初回リリースされた後はどうでしょうか。
このフェーズになると、プロジェクトに関わる人数が増えていきます。プロダクト要件文書(Product Requirement Document)やADR(Architecture Decision Record)を作成し、チーム全体で認識を合わせて前進していくことがより重要になっていくでしょう。
プロダクト要件文書は開発チームが製品を作る上で必要な情報を網羅的にまとめた文書であり、プロジェクトの目的や目標、ターゲットユーザー、機能要件、非機能要件、制約事項などが詳細に記載されています。
ADR はプロジェクトのアーキテクチャに関する重要な意思決定やその背景、理由、代替手段などを記載した文書です。これにより、チーム全体でアーキテクチャに関する知識や経験を蓄積し、後からプロジェクトに参加したメンバーがプロジェクトの過去の意思決定をより深く理解することができるようになります。
このフェーズになると、画面設計書はデザイナーが作成し、その画面設計書とビジネス側からのインプットをもとにエンジニアが技術仕様書を作成することが多くなり、職能ごとの役割の明確化・分業がより進んでいく形になります。

プロジェクトがグロースフェーズへと向かうと、チームのメンバーの入れ替わりも増え、関わる人数も飛躍的に増えていきます。そのプロジェクトの目的や製品の種別に合わせ、どのような文書を作成していくかを個別に検討していく必要が出てきます。

何を書けばいいのか

実際のプロジェクトで作成された文書をサンプルとして、どういった項目が記載されるか概要を説明します。

技術仕様書

たとえば技術仕様書として、以下の項目を記載します。

要件定義
- ユーザーストーリー
- 目的
- 行動変容仮説
- ASIS
- TOBE
- ASISとTOBEで計測する項目
機能仕様
- 利用可否
- 機能
- 詳細や課題など
- 画面設計書へのリンク
- 経緯

要件定義の項目により、機能の目的や期待される効果が明らかになります。まず、機能の追加あるいは変更によって実現されるユーザーストーリーを定義します。そこから、追加・変更された機能によりユーザーの行動がどのように変わるかの仮説を立てるとともに、現状（ASIS）と変更後（TOBE）を明記します。期待された通りの効果が見られたかどうかをどうやって計測するかもあらかじめ検討しましょう。
機能仕様の項目によって、機能の詳細、そして機能を提供する範囲、が明確になります。また、機能の詳細を定義するうえでの経緯について記載することで、将来機能を改修する際に気をつけるべきポイントを明らかにすることができます。現時点では解決できない課題についても記載します。
これらの項目により、これから作ろうとしているものについて、ビジネス側、デザイナー、エンジニア間でより詳細に認識を合わせることができます。

機能別仕様書

たとえば機能別仕様書として、以下の項目を記載します。

画面レイアウト
表示項目・項目説明
初期表示
ボタン操作
画面遷移・モーダル表示
必須項目
処理
フィルター条件

画面設計書を元に画面レイアウト、表示するべき項目とその説明を記載します。項目の初期表示、ボタンが有効化・無効化される条件、ボタンやリンクがクリックされたときのアクションやアニメーション、インプットのバリデーション、項目が必須かどうか、など、動作の詳細をここで定義します。
これらを明確にすることで、実際のアプリケーションの機能や挙動の認識を、開発エンジニアとテスト担当エンジニアの間で合わせることができます。これにより品質検証をスムーズに進めることができます。
この記載をベースに、プロジェクトマネージャーやその他のステークホルダーとも、アプリケーションのあるべき動作について認識を合わせることができます。

共通認識醸成のためのER図

続いて、チームメンバー間の共通認識を醸成するために重要なOOUI（オブジェクト指向ユーザーインターフェース）やER図について説明します。

www.sociomedia.co.jp

OOUIの考え方：ユーザー体験に基づいて考える

ER図の話に入る前に、ER図と概念が近いUIモデル図作成の話をお話しします。

現実世界で「ねこ（モノ）」を見つけてから「なでる」行動をするように、UI作成の際にも現実と同じ手順でインターフェイスを構成する事で、直感的な操作を可能にし説明しなくてもユーザーが使いやすいサービスを構築しようという考え方がOOUIの考え方の一つになります。
ユーザーの関心の対象であるオブジェクトをそのままUI上に表していくので、UI作成にはユーザー体験が大切になります。

体験〜UIモデル図

体験設計であるカスタマージャーニーマップ(CJM)やアクティビティフロー図作成からオブジェクトを取り出し、次の図のようなUIモデル図を作成することができます。

ER図とは？

添付の画像のような、モデル/プロパティなどの塊で、それぞれの関連性なども記載してサービスのデータの関連性などを示し、枠や骨組みのような部分になります。

OOUIで作成したUIモデル図との相性が良く、ほぼ同じような情報になるのでそのまま転記することが可能に見えます（特に抽象度が高いケースではそのままの転記で良さそう）。
プロジェクトによって、書いていたりしなかったりするが、共通認識を作るための数多くのドキュメントの一つになります。

ER図とは？ / 各要素の説明

エンティティ（実態）
重要なデータのまとまりを表すオブジェクトまたは概念です。エンティティ内には属性の意味がある「アトリビュート」が入ります。
アトリビュート（属性）
エンティティ内にある属性情報を指します。エンティティの特性です。
リレーション（関係）
エンティティ同士の関係を表現する線のことです。
カーディナリティ（多重度）
「1対1」「1対多」「多対多」など、リレーションの詳細を表現できる記号です。

ER図とは？ / 詳細

書き方は複数あるが、基本的には「IE記法」で書かれることが多いです。
概念モデル / 論理モデル / 物理モデルの書き分けの方が大事で、右にいくほど抽象度が下がって、具体度があがります。

なんでER図（ドキュメント）を作るか

主にこんなことに使うことが可能です。

画面やワイヤーの作成（デザイナー）
DBの作成（エンジニア）
設計確認・テスト（テスト）
要求の確認（to 企画 | SO）/ 抽象度をあげて全体を見ることで、要求とあっているか

などなど、様々なシーンで「何のために何をするのか」/ 「それぞれの目的とそれに対応する手段」を確認することが可能です。

以下の図は、上でも提示したサービスのV字モデルですがそれぞれのフェーズで、異なる職能の人が一つのものを作っていきます。
何もないところから、共通の認識を持つことは意外と難しいのですが、ドキュメントを用意することで共通の認識をもち、当初に計画したコンセプトや要求通りのものをリリースすることに繋げることが可能です。

さいごに

ここまで読んでくださってありがとうございます！

さいごに、新卒研修後の参加者アンケートの一部抜粋でご紹介いたします。
定量評価として、役に立った度合いは平均5.57点でした（7点満点）
いただいたコメントとしては、「職種同士で考え方の違いがあるということが分かっているだけでも、デザイナーの自分はエンジニアの人の立場に寄り添うことができたような気がする」「デザイナーがどのように考えて作っているのかなどを把握することができた」と一定の理解をいただくことができました。

開発プロセスの進行から、仕様の管理方法、デザイン仕様書として機能するデザインデータのフォーマット紹介、技術仕様作成のポイント、共通認識を醸成するためのER図やUIモデル図、と多岐にわたる内容をご紹介しました。
実際に案件に携わると、自分の担当領域以外を目にする機会は減ってしまうかもしれません。それでも大小の「仕様」を通じた対話を重ねながら、チーム全員でより良いプロダクトを共創していくことが何より大切です。
この研修で触れた内容を手がかりに、一緒に価値あるプロダクトを作り上げていけたら嬉しいです。