1. はじめに

ストーリーチケットの作成やリファイメントを行う中で、ユーザー目線の知識を学ぶ重要性を実感しました。開発者が単に指示された内容を実装するのではなく、「なぜその機能が必要なのか？」を理解することで、より良いプロダクトが生まれます。

本記事では、私が学んだ人間中心設計（HCD）の知見と、それを実際の開発現場でどのように活かしたのかについてまとめました。読んだ方にとって、ストーリーチケット作成や仕様決定の意思決定のヒントになれば幸いです。

2. 学んだこと

2.1 ペルソナとシナリオ

ストーリーチケットを作成する際、ペルソナを明確にし、そのユーザーがどのようにアプリを使うのかをシナリオとして整理することが重要であると学びました。

例えば、ある新機能の開発を進める際に、ただ「ユーザーが設定を変更できるようにする」と書くのではなく、

ペルソナ：「30代のエンジニア田中さんが、仕事の効率を上げるためにアプリを使用」
シナリオ：「田中さんは、毎日アプリを開いて作業をするが、設定変更が直感的にできず、時間を浪費している」

といった形で、機能がどのような課題を解決するのかを明確にすることで、開発者も理解しやすくなります。

2.2 ニールセンの10原則

ユーザビリティの評価指標として活用できる10の原則を学びました。

特に、

「システム状態の視認性」 → 長時間の処理中に、ユーザーが進行状況を把握できるようにする
「ユーザーの主導権と自由」 → 誤操作時でも元に戻せるフェールセーフ設計にする
「エラー防止」 → フォーム入力時にリアルタイムバリデーションを入れる

などは、仕様検討時にすぐに活かせる知見でした。

2.3 ユーザビリティの5つの要素

「学習しやすさ」「効率性」「記憶しやすさ」「エラー発生率の低さ」「主観的満足度」の視点を持つことで、

認知不可の軽減
ショートカットの設計
分かりやすいエラーメッセージの追加

といった改善につなげることができました。

2.4 ユーザーストーリーの3C

ストーリーチケットはCard（カード）として記述するだけでなく、

Conversation（会話）を通じてチームと認識をすり合わせる
Confirmation（確認）で受け入れ基準を明確にする

といったプロセスを意識することで、より精度の高いチケットを作成できるようになりました。

2.5 ジャーニーマップ

機能単位ではなく、ユーザーの行動フロー全体を考える視点が重要であると学びました。

どこでユーザーがつまずくのか？
どのステップが最もストレスを与えているのか？

これを意識することで、より実際の利用シーンに即した仕様が考えられるようになりました。

3. 実践したこと

3.1 シナリオをストーリーチケットに記載する

以前は、ストーリーチケットには「〇〇機能を追加」といった簡潔な内容しか記載していませんでした。そのため、開発者として実装する際に「この機能がなぜ必要なのか？」が分からず、単なる作業として実装を進めることが多かったです。

しかし、ある日先輩から「この機能が実装されることで、アプリのこの部分が使いやすくなる」とユーザー視点で説明を受けたことで、実装の目的が明確になり、開発の方向性が理解しやすくなりました。また、テスト時にも観点が浮かびやすく、機能の意図を踏まえたテストができるようになりました。

現在はストーリーチケットを作成する際、単に受け入れ条件を記載するのではなく、その機能の背景や目的を明記し、どのようにアプリが便利になるのかを説明することを徹底しています。こうすることで、開発者がより直感的に機能の意義を理解しやすくなり、開発の質が向上しました。

3.2 ユーザビリティの視点で仕様を精査する

開発者から「この仕様で問題ないか？」と質問されたとき、ユーザー目線の知見が非常に役に立ちました。特に、ユーザーが達成したいことを阻害するような仕様は、機能の目的を再認識したうえで指摘するようにしました。

また、エラー時のフィードバックが適切に表示されるよう仕様を改善することで、ユーザビリティの向上にもつなげました。たとえば、「入力エラー時に適切なメッセージを表示し、次のアクションが分かりやすいようにする」といった改善を行いました。

もし判断が難しい場合には、「この妥協はユーザビリティを損なわないか？」という視点を持ち仕様班と対話をしました。このような判断は、これまで学んできたユーザビリティの知見と経験があったからこそ可能になったと感じています。

3.3 仕様側との対話と提案

仕様策定の段階で、実装の相談や提案をする機会が増えました。その際に重要だったのは、仕様側との対話を大切にし、「Must（必須）」と「Want（希望）」を明確にすることでした。

たとえば、Mustの中でも特に実装が難しい部分は、他の方法で要求を満たせる可能性がないかを議論し、より実装しやすい代替案を提案することで、開発効率を向上させました。

また、ジャーニーマップを活用し、ユーザーがシステムを使う過程でどこにストレスを感じるかを可視化し、ユーザビリティ向上につながる改善提案を行いました。 具体的には、「このステップでユーザーが迷いやすいのでは？」と気づいた場合に、ナビゲーションの最適化やインターフェースの改善を提案し、仕様策定者と一緒にブラッシュアップしていきました。

このプロセスを通じて、仕様策定者も単なる依頼者ではなく、開発者とともにより良いプロダクトを作る仲間であると再認識し、チーム全体でより良いユーザー体験を提供する意識が強まりました。

4. スクラム開発との関連性

スクラム開発では、ストーリーチケットを単なる「開発指示」として扱うのではなく、プロダクトの価値を高めるためのツールとして考えることが重要です。

HCDの視点を取り入れることで、

チーム全体が「なぜこの機能は必要なのか？」を理解しやすくなる
プロダクトの本質を見失わずに開発を進められる
開発者自身が、単なる実装担当ではなく、より良いユーザー体験を提供する役割を担う

この考え方は、スクラムの基本原則である価値の最大化とも直結しています。

5. おわりに

HCDの知見を学ぶことで、ストーリーチケットの作成方法や仕様策定の考え方が大きく変わりました。特に、

ユーザー目線を取り入れたストーリーチケット
仕様策定時の「Must」「Want」の整理
実装前のユーザビリティチェック

は、開発の精度を大きく向上させるポイントでした。

本記事が、ストーリーチケット作成や仕様決定の意思決定をサポートするヒントになれば幸いです。

参考