＼スニダンを開発しているSODA inc.の Advent Calendar 11日目の記事です!!!／
はじめに
私は2020年6月にSODAにアルバイトとして入り、その後CS（カスタマーサポート）のオペレーションチームのリーダーを約2年間経験し、2023年7月からSODAのCS内でプロジェクトマネージャーをしています。
この記事では、CSの私がなぜプロダクト改善に足を踏み入れたのかと、プロダクトとCSの狭間で約5か月間仕事をしてみて感じたことをお話していこうと思います。
私には技術的な話はできないので、エンジニアの皆さまに限らずCSやその他さまざまな部署の方にもぜひ気分転換程度に読んでいただけたら嬉しいです！
CSのプロジェクトマネージャーとは
私はCSに所属し、CSの中のプロジェクトマネージャーとして主に以下2軸をミッションに掲げて動いています。
- 開発やマーケティング、Bizdev.チームと連携して新しいサービスや施策に対しCS観点での懸念が無いか、最適化できないかを考えると共に、CSのオペレーションチームにスムーズに落とし込み万全な状態でリリースを迎えられるようにする
- CSから挙げられるプロダクト改善案を集約・精査してからプロダクト側に渡し、同じく万全な状態でリリースできるようにプロダクト側とCS側の両観点からサポートする
なぜアドベントカレンダーに参加したか
CSから開発側に依頼していたアプリ上の細かな文言修正に関するIssueを今年の11月半ば頃から自力で修正しようと動いていて、その様子を見ていたPdMのTakatsunさんから「面白いので書いてみたらどうですか！」と声をかけていただき、ぜひ皆さまに発信してみようと思い参加しました。
なぜプロダクト改善に足を踏み入れようと思ったのか
これに関しては、一言でいうととにかくCSの機能改善をスピーディーにしたかったからです。
CSからプロダクト側に依頼するIssueは、細かい箇所だけどお客さまにとっては不親切だったりしてCXの観点で良くないのでCSとしては直したいが、他の機能開発と比べると優先度が下がってしまう改善案が多いです。
そうなると、どうしてもIssueを立ててからすぐに着手することは難しい状況になっていました。
これは決してエンジニアやPdMが悪いという話ではなくて、会社の成長が正義である以上、上記のような改善が後回しになってしまうことはしょうがないことと理解しています。
ですが、CSもCSでお客さまに対して日々向き合っている中で、細かい改善案であっても早く解決されるようにしたい！と、どうにかできないか考えていました。
そこで、大掛かりな修正でなければ、開発を待つより私が習得したほうが早いかもしれない...と思い始めたのがきっかけです。
また、少しでも私が解決することでエンジニアはさらにクリティカルな開発に向き合い続けられる！と思いました。（微量ですがw）
具体的に何をしているのか
私は取引が成立した際のアプリ上の取引画面の文言修正をしています。
さらに具体的に言うと...
- GitHubのコードの中から修正したい文言を探して書き換え
- プルリクを作成してdev環境へ反映
- 正しく修正されているか確認
- エンジニアにレビューを依頼
- 問題なければ、マージをしてほかのリリースに乗せられる状態にする
正直この動きは始めたばかりでもあり、本当に私が今進めるべきなのか含め模索中です。
また、自分のほかのCS業務も持ちつつでもあるので毎日リリースしているわけではないです！
どうやって出来るようになったか
まずは、私の思っていることをレトロスペクティブの時にエンジニアに伝えてみました。
MTGが始まるまでは、「エンジニアの仕事舐めてる？できるわけないでしょ。」と言われる心構えもしていました。
ですが、SDOAのエンジニアはとにかく優しかったです。
「素晴らしい。」
「やるとしたらこの方法だったらできるかもしれない。」
「これをやるにはこの注意点は先に理解しておかないといけなさそう。」
「CSでもやろうと思えばできると思う。一旦試してみたら！」
このエンジニアの言葉を糧に、まずはPdMのTakatsunさんと試しにプルリクを作成してみました。
そこでなんとなくの動きをイメージしやすくなり、さらにスクラムマスターのavexbesukeさんにマンツーマンでがっつり教わる時間をいただきました。
この時間はお金を払えるほど貴重な時間だと悟ったので、動画録画とマニュアル作成を同時にしつつ教わりました。
教わっては分からないことが追加で発生して他のエンジニアに口頭で確認したりして、約2~3時間ほどかかったかと思います。
ちなみに、コードの勉強や開発環境の準備はしていません。
私が叶えたかったのは、細かな文言修正をCS内でスピーディーに解決してしまうこと。
細かな開発Taskとして積まれているIssueをどうにかしたかったのです。
このために自分のほかに持っているタスクや時間を削ってコードの勉強をしてしまうと、CSに所属してKPIを追っている自分に悪影響が生じてしまって元も子もないし、細かな文言修正をするだけの私に開発環境を整えるための高いスペックのPCは不要と判断しました。
やはりエンジニア未経験者には難しいの？
文言修正だけであれば技術的な知識はそこまで必要ないので、大まかな概念や操作方法まわりをサポートしてくれる体制があればできると思います。
と同時に、やはりマニュアル通りでは修正できないことが非常に多いので、ここから発展させていくのはかなり難しいと実感しています。
そして自分で解決できてしまうことだからこそ、より一層品質に対して敏感になったと感じていて、なによりもここの部分が一番難しいし重要だと思いました。
- 本当にこの文言でいいんだっけ？
- 同じ文言を使用しているけど、違うシチュエーションのパターンはなかったっけ？そこは考慮する必要があるっけ？
- そもそも、ここの文言の修正が本当に根本解決になるんだっけ？
普段リファインメントの時に細かくエンジニアが詰め...質問してくる意味がさらに理解できました。
CSがプロダクト改善に足を踏み入れてみて感じたこと
正直、普段プロダクト側とリファインメントを進める際に、「なんとなくここが気になるのでこうしたほうがいいかも。」とふわっと考えることもありました。
ですが、いざプロダクト改善に足を踏み入れてみると、私の一つの判断ミスがお客さまに対して直接何かしらの悪影響を与えてしまう可能性がある、と以前よりも恐怖に近いような何かを感じるようになりました。
もしかしたら、私はここで初めて「自分は何かしらのプロダクトをお客さまに提供している」ということを本質的に考えられるようになったのかもしれません。
CSの私は普段からお客さまの声を聞くことが多いですが、いざ他部署の業務に目を向けてみると、より一層私たちの目の前にはお客さまが存在していることに気づきやすいと感じました。
自分のチームの業務は普段から慣れていて、意識しないと客観的に見ることが難しいですが、他部署の業務から目を向ければそれが容易になる。
私はこの気づきから、他部署の業務に対して「へぇ～、ここの仕事はそういうものなんだな。」と思考を終わらせてしまうことは実はめちゃくちゃもったいないことで、異なる部署間でお互いの業務理解を深めようと動けば、気付けることが多くあるのではないかと思いました。
よく、一番お客さまの目の前にいるのはCSであると思われがちです。
ですが、SODAが発信しているプロダクトもお客さまが実際に見たり触れたりするものなのだ、と再認識できる機会はどこにでも転がっていて、CSだけがお客さまの目の前にいるわけではないことをプロダクト改善に足を踏み入れてみて改めて実感しました。
そこに気づくためには「あそこは他部署である」って思わずに、いかに自分事としてとらえられるかが大事になってくるのかなって思います。
これがSODAのバリューの一つでもある"One Team"なんですかね！
最後に
部署の隔たりを適度に取っ払って、自分ごととして考えてみたら何か面白いことが起こるかも！？ワクワク！って思えるくらいに、「改善」に対してすべての部署が楽しく向き合える環境になったらいいなと思います。
最後まで読んでいただきありがとうございました！
＼明日はスクラムマスターのavexbesukeさんの「自チームの開発プロセス改善の失敗と少し前に進めた気がした歴史(仮)」です！お楽しみに！／