Full.CX

Full.CX とは

名称は顧客体験を示唆するが、製品の内容は全く別である。二三文の製品アイデアを、開発チームが実装できる文書に変える。

多くのチームが経験する隙間である。要件は曖昧に届き、開発者が自分で穴を埋め、作業後に食い違いが表面化する。想定読者はプロダクトマネージャー、創業者、アナリストを置けない小さなアジャイルチームである。

できること

日常の言葉で要望を記述すると、利用者像、機能の内容、適用場面、検証方法、データの構造をまとめて受け取れる。通常は数日がかりの作業である。

ここで最も重いのは受け入れ基準である。要件を検証可能なものに変える部分であり、チームが最後に書き、粗く書き、あるいは書かない箇所でもある。すべてが共有の一箇所にまとまり、プロダクトと開発が同じ参照を読む。

向いている人

業務として要件を書くプロダクトマネージャーが明らかな読者であり、委ねる先のない創業者が自ら書く場合も同様である。

開発に議論ではなく受け入れを求める小さなアジャイルチームが該当し、受託開発のエージェンシーは同じ成果物を納品書として渡せる。一文の意味でスプリントが揉めた経験があれば、この状況は見覚えがあるはずである。

注意点

生成された基準は記述の前提をそのまま引き継ぐ。意図の段落が扱った範囲の基準が出るだけで、誰も挙げなかった要件こそが後で争いの種になる。

数分で揃う一式の仕様は完成したように見える。危険なのは検討済みとして扱うことであり、誤解を捕まえるのはレビューだが、この完成度ではその省略が安全に感じられる。

機能記述から作られるデータモデルが最も弱い成果である。モデルは既存の保持内容と整合せねばならず、この機能に合っても既存スキーマと衝突する場合は実装開始まで分からない。

ペルソナは実在ではなくそれらしい利用者を描くもので、前提の掘り起こしには役立つが調査ではない。事業者自身の文面は熱意が勝ち、限界についてほとんど語らない。確認時は価格も読めなかった。