収集ぐせは仕事に活きるか

ここ最近やってきたことと、わかってきたことを書き留めておくところ。

わかってきたこと

やっていて私のテンションが上がって、サクサクと進められることがちょっとわかってきました。

• 社内で飛び交っている情報を集めて
• 仕分けして
• 平たくたたいてわかりやすくして
• 誰もがいつでも引き出せるところにおいて

を繰り返していく。これが好き。

そういやデータベースのデータを作成したり分析する面白さがとても好きで。
データベースを下支えしている仕組みとかは全然よくわかんないし、そういうのは得意な人におまかせしたいけどｗ

あと小さい頃から収集が好きなんですよね。
最近のゲームだとポケモンGoとかポケ森とか。集めて整頓、集めて整頓・・・。
フィギュアとかTシャツも集めすぎて、しまう場所に困ったり、どこにしまったか忘れちゃったりする。
集め方も、整頓の仕方も、あとで取り出しやすくする方法も、みんな大事だよなぁ。

集める！集める！集める！

私は開発部に所属していて、日々内外からの相談や依頼が舞い込みます。

やってること

• 他の部からチャットで開発部にくる相談や依頼
• 外部からメールやチャットでくる相談や依頼

これらはすべて開発部にメンションしてもらい、JIRAにチケットを作成します。
JIRAには概要を記載してSlackのスレッドのURLを貼っておきます。
質問やりとりや経過はSlackで流れていくので、あとでJIRAチケット見たときにこの話や依頼って終わったっけ？が確認しやすい。

チケットにするメリット

チケット化しておくとデイリーハドルで「このチケットなんですけどー」って会話しやすい。
ずっと残ってるチケットは気になりますよね。なんで終わってないんだろう？もハドルで会話できる。

放置防止

Slackで個人宛にではなく部にメンションしてもらうのは、放置や忘れ防止。
一部だけその時だけではない、全体へいつでも、の誠意。信頼貯金に関わってきますよね。

優先度

チケット化する際には相手に急ぎ具合を聞きます。100％叶えられないこともあるけれど、これで優先度を決める。
優先度をスコア化して伝えてくれる人もいます。これは運用し始めたところでこれからもどんどん改善していく予定。

カスタマーサポート支援

あと、これもやってます。

• 外部からのお問い合わせに開発部として支援

毎日カスタマーサポートのチームとMTGで来たお問い合わせについて話し合っています。
特に開発部の視点からアドバイスや支援できることを伝えたり。

私で答えられることはその場で説明して伝えますし、そうでないものは開発部へ持ち帰って検討し、サポートメンバーへ説明し伝えます。
開発部の回答としては「事実」であることが多いです。それは出来る、出来ない、とか。
事実は事実として、でも他に代替案はあるか、それも無ければ回避策はあるか、とかを開発部から聞き出したり、カスタマーサポートのチームと相談したりします。

あと、問い合わせいただく方の立場によっては回答の表現を変える必要もあります。
開発者同士であれば、あうんの呼吸でわかることも多いのですが、うちの会社にはいろんな立場の方から問い合わせをいただきます。
的確かつ誤解の少ない表現でわかりやすく伝えることを試す毎日です。

カスタマーサポートはとても大事かつ大変、でも面白い仕事だなぁと見ていて思います。
サポートが表に立って技術者は後ろで答えを出す、みたいな表現をする人もいるのですが、私のイメージは違います。
車の前輪がサポートで後輪が技術者？いえいえ。
サポートと技術者は車の左右の車輪であり、同じ景色を見て一緒に走ることで同じ方向へ向かえるんだと思っています。

毎日のお問い合わせを見ていると、「情報の玉手箱やぁーーー！」ってなります。
「他サービスと比較検討しているんだけど、この部分ってお宅のサービスではどうです？」みたいな問い合わせをいただいているのを目にすると、
「おお、そこが重視するポイントなんだな。じゃこれ強化したらうちのサービス良くなって需要増えるんじゃないかな？」って気づくし。
「こんなこと試しているんだけどうまくいかなくて・・・」って問い合わせをいただいているのを何度か見たら、
「こんなニーズあるのか。じゃ、解決策を公式ドキュメント化して公開したらいいんじゃないかな？」って気づくし。
めちゃめちゃリッチなフィードバック貰えてるよなぁと日々感じています。

出す！出す！出す！

集めた情報はアウトプットあるのみ！
でもアウトプットする場は外部だけではありません。まずは内部で情報を共有するのはとても大事。

内部で共有

内部で認識が合っていることで、外部へのアウトプットの品質が上がります。
人によって言うことが異なり混乱を招く危険性が下がります。

「ああ、あれ前も話した気がするけど・・・誰とだったっけ・・・？おーい！誰か知らない？」はあるあるなのですが。
よく来る質問と回答は集めておいて、そこを参照するようにしておけばよいですよね。
特にカスタマーサポートの立場では情報が分散していたり、曖昧だったり、忙しい人を捕まえないと回答できないのはとてもつらい。

外部には公開出来ないことも、内部なら共有の場に置いておけます。
そして内部で共有出来ている情報を元に、外部へ発信できる情報が作れます。
また随時アップデートしていくことも大事。追加できそうな話がされているのを目にしたら共有している情報に追加していきます。

外部へ共有

外部の方から「こんな相談をよく受けるんだけど、こういう回答をしている。公式からも発信してもらえると助かるんだけど。」と情報をいただくことがあります。
とてもありがたいことですし、情報公開のチャンスですね。
開発者の間ではよく聞かれる「あんた、それ公式ページ確認したんか？」。そう、公式が正しい情報をわかりやすく整頓して公開することの大事さ。
情報が公開されていることで問い合わせが不要となり、ユーザーの負担が減ることになりますし。
このような情報を外部公開することで、うちのサポートも助かるはず。似たような問い合わせが減ったり、来たとしてもページ参照の案内で済みます。

また公式で出す情報の表現についても改善をしています。
うちのサービスは様々な立場の方が利用されることもあり、よく知っている人向けの表現法を避ける必要があります。
よく知っている人向けに情報を公開したところで、例えば2割の人のみ理解できたとして、どんなメリットがあるでしょうか？
初学者にもわかるように、例えば8割の人（よく知っている2割の人を含む）がわかるような情報公開を目指したい。
真のバリアフリー。

とまぁ、つらつらと書いてきたのですが。
これからもどんどんやり方は変えていきますが、「情報の収集と共有」という柱はどっしりと中心に据えてやってきまーす。
（最近ちょっとしかコード書いてないけど、それはそれ。今が楽しい。）