プロダクト設計とシステム設計を地続きに捉えて仕様の抜け漏れを防止する

こんにちは。ウォンテッドリーでバックエンドエンジニアをしている小室 (@nekorush14) です。新規プロジェクトの立ち上げや新機能の開発において、仕様の「不確実性」にどう立ち向かうかはよく課題となります。今回は、私が要求から仕様を落とし込み、チームで合意形成する際に実践しているアプローチを紹介します。

はじめに

プロジェクトの初期段階では、プロダクトの「やりたいこと・要求」はあっても、具体的な「仕様」が十分に言語化されていないことはよくあります。

この段階でいきなり詳細なモデリングや実装に入ってしまうと、後から「このパターンの考慮が漏れていた」という致命的な不整合が見つかり、大きな手戻りが発生してしまいます。それを防ぐために、私は常に「画面遷移」と「データフロー」をセットで整理し、そこに「脳内モンキーテスト」を続けて実施するというサイクルを回すようにしています。

この手順を踏むことで、エンジニアだけでなく PdM やデザイナーとも早い段階で認識を合わせることができ、結果として開発の確実性を高めることができています。

画面遷移とデータフローを可視化し致命的な抜け漏れを防ぐ

この手法の最大の目的は、単に画面の並びを確認することではありません。「システム設計」と「プロダクト設計」を地続きに捉え、要求の流れ (ユースケース) に致命的な穴がないかを検証することにあります。

プロダクトが提供したい価値と、それを実現する仕組みは切り離して考えることはできません。画面間のつながりとデータの動きをセットで見ることにより、エンジニアだけでなく PdM やデザイナーとも共通言語で議論できるようになります。

今回は手法のイメージを掴みやすくするため、架空の「ブログ記事作成アプリ」の「記事作成機能」を例に作成した下図の画面遷移・データフローを用いて説明します。

ユーザー体験をベースに画面とデータの流れを整理する

まずはシステム都合の設計を一旦脇に置き、エンドユーザーがたどる「自然で意味のある操作フロー」を定義します。図の例では、記事の「作成」から「保存」に至るまで画面の状態を可視化しています。ここで重要なのは、単に「記事内容を自動保存する」というアクションだけでなく、その裏側で「どのデータをDBとやり取りし、どのような状態で保持されるか」を言語化することです。画面の要素だけを見た時には以下のような観点を考えています。

下書き保存したデータは、一覧に戻った後も正しく再開できるか
既存機能 (例えばプロフィール画面) からこのフローに流入した場合、必要なパラメータは足りているか
「書いている途中でブラウザを閉じても、自動保存されているはず」というユーザーの期待に応えるデータフロー・画面遷移・画面デザインになっているか

このように、画面ごと単体で考えるのではなく、データフローと一緒に捉えることで、個別のAPI設計だけでは見落としがちな「機能としての文脈の不整合」をあぶり出すことができます。

脳内モンキーテストをする

一通りフローが整理できたら、次に「脳内モンキーテスト」を実行します。これは、自分が設計した仕様と事前に把握している機能要求などの前提知識をすべて忘れ、「何も知らないユーザー」として操作をシミュレーションするプロセスです。機能を設計をする際には「正常系」を基準にしがちですが、実運用でシステムを苦しめるのは常に「異常系」や「準正常系」です。脳内モンキーテストをする際には特に以下の観点を意識するようにしています。

登録フローの途中で「戻る」操作をしたり、アプリを強制終了(アプリキルなど)した後に再起動した際にどうなるか
複数のタブで同時に編集した場合や自動保存の最中にオフラインになった場合にどうあるべきか
異なるサイズの端末で操作した場合はどうなるか
ユーザーの認証・認可に応じて正しい挙動となっているか
デザインで要求されたユーザー動線 (CTA や操作フロー) で操作したときに違和感を感じないか
エラー発生時にもユーザー体験に影響を与えないか

「ここでおかしくなりそうだな」や「これが足りていない」、「こうすると自然になるな」という設計に対する違和感をこの段階で見つけ、図上に付箋コメントとして残すようにしています。また、付箋は「確定している仕様/疑問に思ったこと/漏れているな・不確実だなと思ったこと」などを色分けして残しています。
これをベースにPdMやデザイナーと仕様のすり合わせを行うことで、開発終盤での致命的な考慮漏れを防ぐことができます。