運用保守フェーズ：UX計測
しばらく投稿が空いてしまいましたが，その間にデザイン部からプロダクトマネジメント部に配属が変わりました。これで晴れて（?），もうデザイナーがPjMに挑戦！ではなくなって，PjMが本職になりました。
今回は開発フェーズから運用フェーズへ変わる節目に考えなくてはいけない，運用し始めてから計測したいことについて書きたいと思います。
運用保守フェーズでは，改善したり，新機能を追加したりすることがメインの開発になるかと思いますが，ただ闇雲にやりたいことベースで行っていくといつの間にかそのプロダクトは肥大化してしまうといったことが発生しやすいです。
原型を留めないほど肥大化したプロダクトは例えば，やたらめったら使わないボタンの付いているTVのリモコンや全く使ったことがないかんたんに料理ができそうな番号が50件以上ならんでいる電子レンジなんかを想像していただくと良いかと思います。
これは，決してただ開発者がやりたいことを詰め込んだ結果起きているわかえではありません。実際ユーザーの声を聞いた結果なのだと思います。これがよく言われる「ユーザーは本当に欲しい物を言語化できない」現象です。
「ユーザーは本当に欲しい物を言語化できない」
これは風邪で病院を訪れた時をイメージするとわかりやすいでしょう。
患者：「先生，くしゃみが出たり，咳が出たりしているんです」
医師：「風邪のようですね。」
患者：「風邪を治す薬がほしいです。」
医師：「風邪が治る薬というものはこの世にないんです。」
と言われるようなもので，実際は「痰を出しやすくする薬」「炎症を抑える薬」なんかを出されますよね。現在あるユーザーのペインというものは「風邪を治す」のではなく「くしゃみがたくさん出る苦しみを止めたい」「咳がたくさん出る苦しみを止めたい」なのです。
ここまで，ユーザーの声を聞いてどうプロダクトを良くしていくべきかについて話しましたが，運用保守に入る前はどうでしょうか。
まだ，実際に使っているユーザーはいないのでどんな声が出てくるかわからない状態です。ただし，少人数の限定的なグループのユーザテストからの声や開発側からここはもっとこうよくできるのではないかという声は既に得られているのではないでしょうか。
また，PjMとして全体を俯瞰して見た時に，
「ここはユーザーの不満が出るかもな」
「ここはこうなっていればさらに使いやすくなりそうだな」
といったイメージを持っていると思います。
そこで，今後どうしていきたいかというリストをまずは用意しておきます。
私の場合は，開発中に上がってきた声はすべてAsanaで検討チケットをつくるようにしました。リリース日としてあげている開発には含めないけれど，その後に開発したいものを検討用セクションにあげます。
開発後半になってそのリストを見返すと，いらなかなっているものや，無駄に思えるものもあるかも知れませんが，一旦はそのままにしておきます。
そして，運用保守フェーズでそのリストから，何を今後検討したいかMiroでまとめていき，優先順位をつけます。
そして，その内容を検討するためにはどんな数値が出れば，検討が可能かを考えるのです。
そこから，その数値を出すためには何が必要か，ボタンのクリック数なのか，データの処理時間なのか，等を検討し，その次はバックエンド実装なのかフロント実装なのかを考えるという流れになります。この最後のブロックは，エンジニアさんと一緒に行うことがより確実で色々な方法が考えられると思います。
ここまで来たら，後は実装とそのデータが見えるようにすることで検討材料を得られるようになります。
この数値を取るための実装は，実際にユーザーが使い始める前までに実装されていることが望ましいでしょう。特に，ユーザーが初めてこのプロダクトを触るときのデータというのはとても貴重なものです。
数値化についてのもっと詳細な考え方を知りたい方には，以下の本がおすすめです。数値を考えることにアレルギーの合った私でも苦なく読めたので，数字を考えるのが苦手な方にも読みやすくなっているかと思います！
この記事が気に入ったらサポートをしてみませんか？