akippa株式会社でWebプランナーをしている谷口です！
前回は、未経験からWEBプランナーとしてのキャリアをスタートさせる準備段階のお話をさせていただきました。

今回から、実際に業務をこなしていく中で起こったこと、その時感じたことを書いていきたいと思います。

プランナーとしての最初の試練

引き継いだ大型改修をリリース

プランナーとしての初めての仕事は、駐車場オーナー様向け管理サイトのUIフルリニューアルをリリースすることでした。

弊社PdMの熊谷主導で企画・実装が進んでいて、あとはリリース周りの調整をするだけ、という状態で僕が引き継ぎました。

社内関係部署へのレクチャーや駐車場オーナー様へのアナウンス、事前に発見できた不具合を潰したりと、リリースに向けて着々と準備を進めます。

そして引き継ぎから約1ヶ月後、初の大型リリース作業が無事完了して少しだけホッとしていた過去の自分に言ってやりたいです。

「ここからが本番やぞ」

当たり前のことですが、新しいプロダクトをリリースして終わりではありません。もちろん頭では分かっていたつもりでしたが、それを身をもって体験することになります。

リリース後の問い合わせ対応

ホッとしたのも束の間、フルリニューアルをリリースした直後から一気に慌ただしくなります。

社内のVOC（Voice of Customer）チャットではオーナー様からの生の声が届き、営業担当からもオーナー様から受けた質問・要望が次々と舞い込んできます。

1. 明細書の数字が見にくくなったので今すぐリニューアル前に戻して欲しい

2. サイトにアクセスしてもうまく表示されない

3. トップページに新たに追加された機能の使い方が分からず教えて欲しい

4. 〇〇ボタンを押しても反応しないけどどうなってる？

5. 画面上部にページ切り替えボタンを設けてほしい

ちなみに↑にあげた問い合わせの例5つのうち、本当に優先して確認しなければいけない（=不具合の可能性がある）ものは2と4になります。

にもかかわらず、全部の問い合わせに急ぎで対応しないといけない気になってしまった僕は、一つ一つを真正面から受けとめてあっという間にテンパってしまいました。

弊社PdMの井上、熊谷をはじめチームメンバーの方々のフォローのおかげで、なんとか問い合わせの嵐を乗り切ります。

学んだこと

「優先順位をつけていくこと」が何よりも大事だと感じました。

当たり前に思えることですが、"それぞれの立場の自分ごと"である問い合わせと向き合うためには、受ける側で判断基準をあらかじめ準備しておかないと当時の僕のようにパニックになってしまいます。

例えば今回のような新しいプロダクトをリリースする場合、
トリアージ（triage：緊急度判断）のわかりやすい基準は
「不具合の可能性があるかどうか」です。

1. 不具合：こちらが意図した動作をしていない

2. 考慮漏れ：設計する段階で詰めきれていなかった

3. 改善要望：あればより快適に使える

スーパーざっくりですが、その問い合わせが上3つのどれに当てはまるかを考えるだけでも、落ち着いた判断ができるようになる気がしています。

終わりに

今回は、大型リリースとその後の問い合わせ対応について書かせていただました。

次回以降も、プランナー業務をこなしていく中で、実際に起こったこと感じたことをベースにお伝えさせていただければと思います！