# CREってなんですか？ のんちゃんとタカマティのボイコード Voicy Engineerの声と出会えるチャンネルボイコード このチャンネルではVoicy Engineerの日々の活動をお話ししています おはようございます おはようございます ボイコードの配信の時間は朝ですので 朝ですね。我々が何時だろうと 結構土曜日の朝7時半ですよね そうですね 起きますね。あれで 目覚ましいですか? 通知で 起きて最初に通知きてるなと思って 見てボイコード そうでした、そうでした いい目覚めの朝ですね しかも最近ね、配信増えてますもんね そうですね ぜひ皆さん聞いてください ワードトークが増えてますね いいですね 最近はどうですか? 最近は 最近 みんなと喋ってないんです タカマティさんとも 業務で何も喋んないですね チーム違いと そう 先日までは同じチームでやってましたもんね そうなんですよ Voicy人数が少ないながらに チームで結構動いてるんですけど 今また また変わりましたよね 変わりましたね 大きく 私は今 開発 開発というか QA半分 半分CSとか カスタマーサポートとか のことをやってますね 二刀流って感じですね 二刀流がじわじわ増えていますね CSのお仕事は これまでは経験したことがないというか 初めて 関わってる感じですか? 全然やったことなくて 今 QAチームとして CRE化というのを 置いてて 次やっていきましょうねという領域として CREという 活動を やり始めてるんですけど 私もこれ知らなくて 調べたんですけど 初めて聞いたかもしれないですね CREは カスタマーリライアビリティエンジニアリング エンジニアリング 顧客信頼性エンジニアリング あんまり最初 SREと何が違うのと思ったんだけど 似てますね どっちかというと もっと 顧客と 直接やり取りするようなところの目線 技術 イメージ SREはどっちかというと リリースとか プロダクトを作っていくところの 技術をサポートしたりとか 作ったりするイメージなんですけど SREどっちかというと もっと顧客との直接の対応とかで エンジニアリングの力で改善していくみたいな イメージかな 違ったらコメントたくさんください 顧客 ユーザーの方々との 直接のやり取りとかも結構しながら やり取りの過程で 技術的な質問だったりとか そういうのもあると思うので そこも技術的な知見から 回答をしたりとか そういう感じですかね そうですね 今私がやってるのは 基本お問い合わせベースなんですけど お問い合わせ来たものの中で えーと 何だろう お問い合わせ 色々いただくお問い合わせを 基本的には 簡単に返せるものと ちょっとこう 何だろうな 対応方法を考えなきゃいけない 不具合だったりとか あと そうですね マニュアル化できないような お問い合わせも色々いただくので そこを よりAI化したり 技術的な調査とか そういうところを もっとスムーズにできないかっていうので もともとCSのチームがいたんですけど そのご対応をまとめて QAチームにもらうというか 感じになってて もともと 何だろう テストとか 実際リリースする前のテストだったりで 色々観点出したりはしてたんですけど 実際リリースした後の 使っていただいてる中で出てきた不具合を どうやって 何ていうんだろうな エスカレーションしてって 適切な形で 適切な人に 技術的なところを相談するみたいな スムーズにするようなことを今やってます ありがとうございます 結構 ユーザーから知ってみた時に ユーザーの皆さんから知ってみた時に 自分もユーザーで色んなサービスとか触ったりするんですけど それを問い合わせをした時に いつ帰ってくるか分かんないとか いつ帰ってくるか分かんないとか そこも 適切な回答が返ってきたりとか そういうのが返ってくると そのサービスに対しての 信頼性がすごく上がると思うので やりがいはありそうでありつつも 難しそうなイメージがありますね そうですね そうですね 私たちってVCアプリのことを結構知ってるから 仕様とかを どの機能のこの部分に問題があるから ここが何だろう 不具合が起きてるのかなって 我々は中の人だから分かるけど ユーザー目線で見ると全然それ分かんないから 何でこれが起きてるのかって お問い合わせも 何をお問い合わせていいのか分かんないみたいな 感じがあると思うので 最初のお問い合わせから どうやって紐解いて 不具合の真のところに迫るのかみたいな これはこれで お問い合わせ技術ってめっちゃあるな お問い合わせ対応技術とか 質問力とか そういうの大変だなと思って 難しいなと思ってますね 質問来た時に なんとなくここが原因なんじゃないかみたいな そういう第一次的に ここを原因を自分の中で特定するみたいな それって結構 QAの知見だったりとかも すごい生きる場面がありそうだなと感じたんですけど 質問はいかがですか? そうかもね 切り分け?不具合の 今までもやってたんですけど 不具合の切り分けって結構大事じゃないですか パターン出しとか そうですね パターン出して この時は起こんないけど この時は起きるから ってことはこの画面が原因だよねみたいなのって QAでやる時に 使ってた技ではあるんですけど それが 実際のお問い合わせの時にも生きるなっていうのは 確かにですね なんか面白いなって思いました 確かにここに ここなんじゃないかって当てをつけるっていう そこがすごい的確なところをついていけると やっぱその問い合わせの対応の やりとりの回数も減らせると思うので そこはすごいQAの時期も生きてる感じがしますね そうかもですね エンジニアも なんて言うんだろう その原因究明みたいな すごい得意なイメージがあって 切り分けとかすごい得意なイメージがあるんですけど エンジニアも それは何力なんですかね 何ですかね 開発してて詰まった時に なんでここが詰まってるのかみたいのを なんて言うの 切り分けて原因特定するところ結構ないですか なんか問題があった時は 必ずその原因はどこかにある まずそこから入るんですけど やっぱまずログを見に行くっていうところをまずやりますね ログを見て 処理の過程の中で いろいろいくつかのポイントポイントで ログとか出してたりするので そのログのメッセージを見た時に これはここの処理だっていうのは まずそこから特定していって そこから周辺の処理を見たりとか そんな感じに特定をしていく感じですかね # 社内の業務をAIでいいかんじに改善する 今、CS対応をしている中で、今までログを自分で見るという技術があるじゃないですか。 その中で今、クロードコードとかを愛の手プロジェクト、多分ちょっと他の放送で喋ってるかなと思うんですけど、 コードが書いたり読んだりできない私たちでも、クロードコードと繋いで、自然言語でここの原因わかりますか、 番号とかだけを伝えてここ解析してくださいという指示で、原因とか何が起こってるのかみたいなところを判断してもらえるようになったので、 それがVoicyS対応の時にすごい役立って初めてちゃんと使ってます。 ログを追うようになったって感じですかね。 そうですね。原因って絶対どっかにあるっていうのは本当そうだなと思いました。 自然言語のやりとりでログ追ってくれるっていう体験すごく良くないですか。 めちゃくちゃ良いですね。 自分の困りごとから。 あとはVoicyアプリってログイン方法がいくつか入って、メールアドレスログインもあればSNSログインとかもあって、 これはブログとして改善しなきゃいけないところなんですけど、 新規登録を各SNSで全部のアカウントで作れちゃうっていうのがあって、 問い合わせを頂いた時にアカウントがね、自分ではそう思ってなかったんだけど、実は3つ作られてましたとかってことがあったりして。 確かに1人の人が複数のアカウントを持っているっていうことですね。 そういう時にじゃあこの不具合はどのアカウントでとか、 そういうのもログだったり社内システムとかから見れるようになったというかしてもらっているので、 そこで結構原因究明とかそこ案内とかも結構スムーズにできるようになって、これはすごいなと思っています。 ありがとうございます。それをできるようにするためのちゃんと意味のあるログを出すっていうのはやっぱり開発者の腕の見せ方が大事なんで、 クロードが変な回答を返さないようにそこは僕も頑張ろうと思います。ちゃんと正確なログを出す。 ありがとうございます。 そうですね。今、次やりたいこと、今はとりあえずCS、カスタマースポートっていうところで、 いろいろまずは自分一人でお問い合わせ対応ができるみたいなところをある程度クリアしたんですけど、 今後やりたいことで言うと、お客様対応の中から得た知見で、アプリのここ使いにくいからここ改善できるんじゃないかみたいな、 ちょっと開発みたいなこともできたらいいなと思って、実際のユーザーさんの困り事からアプリの改善につながったみたいなことができたら最高と思って。 それはやりたいですね。 それは嬉しいですね。 自分が問い合わせして、それがアプリに反映されたっていうのは嬉しいですよね。 そうですね。で、これを何でやりたいかというと、そもそもお問い合わせがない方がいいので、 お問い合わせ自体が減っていくってことを本当にやりたくて、これはできたらいいなと思ってます。 あと、お問い合わせをいただくっていうのは、裏返せば期待をしていただいているってことだと思うので、 しっかり期待にも応えられるようにやっていきたいですね。 高本さんは最近何してますか? 最近はですね、表に出る機能ではない裏側の機能を開発に関わっている感じで、 ちょっとあまり具体名とかは出せないんですけど、 社内で社内の方々、それこそPSチームといわれる方々が使っていただけるような機能を開発しているって感じで、 今、全社的にAIを前提とした業務に置き換えていくって流れがありまして、 結構手作業でいろいろスプレッドシートだったりとか、いろんなものに情報が分散していたりとか、 そういう状況があったりするんですけど、本当にAIを前提に業務を組み換えていく、 それのためのAI機能の開発に、すごい抽象的な言い方になっちゃったんですけど、 AIをベースとした業務にすることによって、業務をさらに効率化していけるようにというところの基盤だったりとか、 っていう機能だったりとかを作るっていうところに勤しんでいる感じです。 そう、ボイシーそろそろ10周年なので、秘伝のタレみたいな作業とか、結構たくさんありますもんね。 そうですね、昔から長いことを突き足しで受け継がれてきた闇のファイルだったりとか、いろんなものがありますね。 それをAIで読めるようにとか書き換えるみたいな形で参照、どこを参照したらどういうふうにスムーズにいくのかみたいな。 そうですね、結構情報が本当にいろんなところに分散しているので、それを一元管理したりとか、そういう整えるっていうところもやってたりします。 そっか、それはテスト観点的なことめっちゃありそうですね。考慮してなかった、ここも参照してたんですか?とか。 やっていく中で、ここの機能というか、ここ落ちてましたとか結構ありそうなので、慎重にやらなきゃダメですもんね。 そうですね、僕はこの業務というかこの仕事で個人的に面白いと感じているのは、今までやってた開発のと、こういう要件があってこういうことをやりたいというのを決まって、ある程度決まったものを作っていくみたいな。 今回に関しては、一応こういうことをやりたいというざっくりとしたものがあるんですけど、それを具体的にこういう形でやっていきたいみたいなそういう細かい要件みたいなものは逆にないというか、 それを自分からこう作っていかないといけない。あとは関係者にこういろんな人が関わっていたりするので、ヒアリングをしていくみたいな。 結構動き方だったりとか、あとは形のないものをこう作って形にしていくっていう、なんかそういうまた今までやったことないアプローチの仕方。 結構あまり得意ではないというか、あまり経験がない部分であるので、いろいろとシクハクしながらやっているという感じであるんですけど、また新しいチャレンジをしているという感覚はあって、苦しくもありつつ楽しくもやれているかなという感じですかね。 ちょっとPDM的な動き方? 近いと思います。本当にそのプロジェクトを回す、中心となって回していくみたいな、そこも積極的に動いていくっていう、そういう力もちょっとずつ身につけていこうとしています。 なんかプロダクトエンジニアって感じですかね。 そうですね。ずっと目指してやっていこうと思います。 要件ありきじゃなく、こういう目的ぐらいのふわっとした要件をもらって、じゃあこれとこれとこれはいるけど、これはいらないですよねみたいな話をヒアリングしながら進めていくみたいな。面白い! 結構面白いと思いますね。 そして自分の中では苦手意識があった分野だったんですね。 そうですね。やっぱり作るものが決まっているってところから入っていくっていうのが、いわゆる受け身じゃないかもしれないですけど、ちょっと受け身に近いみたいな。 誰かが仕様を決めてくれてそれを作っていくみたいな。それを逆に自分から仕様を決めにいくというか、そういうアプローチを変えていっているなという感覚があって。 今AIがあるので、作るのはすぐ作れると思うんですけど、本当に求められている。何が必要で何が求められていて、それを最速で出していく。そこは今後にも生きてくるかなと思うので、次の僕のステップですかね。 いいですね。期待しております。 期待しております?楽しみにしてます。 # コメント返し はい、では今日もコメント返ししていきます。 はい、まず一つ目、最近学んだ技術、先週の えーと、誰と、誰が喋ってた? マサト、トモさんが話してたことで 佐藤健さんからたくさんコメントいただいてます。 ありがとうございます。 ちょっと、えーと、全部読んでいくとあれなので それだけじゃあ、えーと、話すと 20年ほど前、GoogleがAndroidを日米Oの時差を利用して 8時間かける3回、3日、違う、3回日の えーと、24時間開発を密かにしていたとき 大量に書き集められた携帯電話ソフト技術者の人たちがぼやいていたのが ソースコードにコメントはほとんどないことでした。 日本人技術者がソースにコメント書くと コメントがないと理解できない コードを書くな!と怒られるらしい。 コメントを書く暇があったらコードを書けという文化です。 恐ろしさを感じました。 そうなんですか? 結構、コメントってチーム開発とかしていたときに 時間が経つとコードって忘れていくじゃないですか。 なので、どういう意図でこういう風にしているみたいな そういうコメントを残したりとか それはいいかもしれないですけど コードで、このコードはこういうことをやってますみたいな そういうコメントはあまり 読めばわかるような そういうコードは書くべきじゃないとか そういうコメントを書くってことは まずコードを書く人自体があまり理解していなかったりとか ちょっと時間が経てば忘れてしまうんじゃないかと 懸念があるからコードを書いているとか そういう感じですかね。 そこは文化の違いだったりとかもありそうな気がしますね。 面白い。 ありがとうございます。 あとは次 技術ワードトークAWSの放送にもコメント2件いただいてます。 ありがとうございます。 1件目がニューブルさんから せんちゃんまささんともさん いつもありがとうございます。 AWSまたやろうと思ってるけどできてないやつ来ました。 エンジニア説明あるある ボイシー始めて機械エンジニアなどのいろんなエンジニアがあると学びました というコメントいただきました。 ありがとうございます。 これめっちゃわかると思って ボイシー始めてというか 私もともとエンジニアじゃなかったので ボイシー入って全然違う バックオフィスから 3年前とかに初めてエンジニアという仕事を始めたときに まるまるエンジニアめっちゃあるじゃんと思って 全然違うじゃんと思いました。 機械エンジニアって全然違うし モバイルの人とバックエンドの人も全然違うし SREも違うしとか 技術って広って思いました。 確かに本当にエンジニアって一括りにできない たくさんの種類がありますね。 フルスタックエンジニアそうね。 僕はまるまるエンジニアっていう肩書きはないかもしれない 全てをやる男 浅くですね。広く浅く。 すごいすごい。 ありがとうございます。 続いてキングダムさんからコメントいただきました。 せんちゃんまささん友さんいつもありがとうございます。 昨日珍しく新幹線に乗って東京に行きました。 そうなんですね。 車内でインガメガチャーチ私にしてはだいぶ読み進められました。 いろんな登場人物に親近感を持ってみたり遠ざけてみたり ファンダムのケースは難しいですね。 自分が仕事でやっている商品開発でも狙ってヒット商品が作れるように精進してまいります。 というコメントをいただきました。 ありがとうございます。 私まだインザメガチャーチ読めてなくて 寸読というか勝手はあるんですけど読めてないんですよね。 私天の尺で流行っているものをちょっと距離を置いちゃうんです。 ちょっと時間が経ってから読むとか。 私アサイリョウさんの小説えぐられすぎて すごい一週間ぐらいズンってやるぐらい好きなんですよ。 性欲かな? 性食気? 性食気かな? どっちも読んで毎回面白すぎるってなるんで ちょっとビビってますね。 インザメガチャーチもまたそういう状況になるかもしれないですね。 そうなんですよ。 商品開発でも狙ってヒット商品が作れるようにっていうのは そうですね。 ファンダムの形成とかの文明でお仕事されると すごい広がりそうですよね。 今日もお聞きいただきありがとうございます。 次はどの声とつながりますか? 引き続きボイシーでお楽しみください。