見出し画像

hidekのエンジニアと長話 第9-3回【全文書き起こし】~ゲスト:Autify CEO 近澤良氏~

stand.fmで配信中の「hidekのエンジニアと長話」9人目のゲストは、Autify CEOの近澤良さんです。

「hidekのエンジニアと長話」は、メルペイVPoEのhidek(木村秀夫)さんをメインパーソナリティにお招きし、ゲストエンジニアとともに作っていくスペシャルトーク番組です。

第9-3回の今回は、AutifyのCEOである近澤良さんをお招きして、Autifyの技術アーキテクチャやスピードと品質、技術的負債の返済などについて語りました。

※本記事は、2021年9月24日にstand.fmで配信を開始した番組を書き起こしたものです。

ゲスト
近澤良 氏 @chikathreesix
オーティファイ株式会社 CEO

メインパーソナリティ
hidek(木村秀夫)氏 @hidek
株式会社メルペイ VPoE(Vice President of Engineering)

パーソナリティアシスタント
gami(池上)氏 @jumpei_ikegami
株式会社プレイド エンジニア

Autifyの技術アーキテクチャ

hidekさん(以下、敬称略):ちなみになんですけど、当たり前の話なんでしょうけど、Autifyの開発もAutifyを使ってらっしゃるんですか?(笑)

近澤さん(以下、敬称略):そうですそうです。はい。AutifyもAutifyしている、っていう(笑)。

hidek:なるほどね。

近澤:なんか、ちょっと自己矛盾を抱えた感じなんですけれども。

hidek:(笑)。

近澤:ループしている感じで。

hidek:でも、変な話、ドッグフーディングできているわけですから、それはそれでね。

近澤:そうですね。はい。今、AutifyでAutifyするのをすごくがんばっています。Autifyのカバレッジをどんどん上げよう、みたいな感じで、「テストを追加するデー」みたいなのをもうけて、エンジニアがどんどんシナリオを作ってくれていますね、Autifyで。

hidek:へー。いいですね。答えられる範囲でいいんですけど、Autify自体の技術アーキテクチャってどんな感じなんですか?

近澤:そうですね。結構、うちのドメインがユニークだと思うので、アーキテクチャも結構ユニークで。基本的には、Webアプリケーションが起点にはなるので、そこはRuby on Railsで書かれていて。

hidek:うんうん。

近澤:で、ちょっと、だんだんフロントエンドとバックエンドのディカップリングが行われ始めて、だんだんフロントエンドがSPAになってきて、みたいな感じにはなってて。そこでReact・TypeScriptを使って、バックエンドは、今はまだRuby on Railsですけど。最終的には置き換わるかな、みたいな感じにはなっているんですけれども。そこがWebアプリケーションのパートで。ただ、テストを実行する部分は、テストのワーカーと呼んでいるテストランナーがあって。で、テストランナーは、今、実は2種類バージョンがあるんですけれども、もともとのレガシーなシステムだと、「Robot Framework」っていうオープンソースをベースにした、Pythonで書かれたテストランナーがあって。で、それを今、WebDriverベースの、TypeScriptかJavaScript、Node.jsか、で書かれているテストランナーが「バージョン2」みたいな感じで、今、実装していて。で、そういう感じでテストランナーの層があって。

hidek:うんうん。

近澤:あと、実際にテストを実行するブラウザ環境のコンテナ化されたOSと、OSの中にブラウザが入っている、みたいなのがAWSで動いていて。で、そこの実行環境でテストランナーを回して、テストを実行して。で、結果をWebアプリケーション、データベースに書いてWebアプリケーションに返す、みたいな感じの構成がAutifyのWebテストの方で。モバイルの方は、テスト実行の部分をリモートのMacのマシンを使って、その中にVM化されたiOSシミュレータを入れて。で、そのiOSシュミレータとWebアプリケーションをつないで、そこのiOSシュミレータの内容をリアルタイムでプレビューして、そこの操作を記録して実行する、みたいなことをやっていますね。はい。

hidek:なるほどですね。いわゆる差分を検知するマシンラーニングのところって、どういうタイミングで?

近澤:そうですね。そこは、テストワーカーのところに入っていて。

hidek:あー、なるほど。

近澤:マシンラーニングの部分は、今までの……。どういう仕組みになっているか、って言うと、簡単に説明すると、要素の特徴を抜き出して、そこに重み付けをするんですけど。

hidek:うんうん。

近澤:その重みから、シミラリティースコアというか「類似度」みたいなのを判定して、一番近しいものを選択する、みたいな感じになっているんですね。そこの重みの部分をマシンラーニングで計算したりとかして、っていうのは、それは非同期で行われている、って感じですね。同期的ではなくて。

hidek:なるほどなるほど。

近澤:ただ、要素を、シミラリティースコアを判定するのは、テストワーカーの部分で同期的に行われている、って感じです。

hidek:あー、なるほどですね。これ、今、ちょっと気づいたんですけど、Android大変そうですね。

近澤:Androidはまだサポートしてないですけど(笑)。

hidek:ですよね(笑)。これ、厄介ですよね。

近澤:いやー、めっちゃ厄介……。いや、正直、まだ全然わかってないです。だから、「どこまでできるのか」とか「どのくらい大変か」って見積もれてないのが現状で。ただ、めちゃめちゃ言われるので、「Androidは対応してください」って。

hidek:まあ、そうですよね。

近澤:当たり前ですよね。皆さん、iOSだけ持っているケースってめちゃめちゃレアなので(笑)。

hidek:そうですよねー。

近澤:なので、いや、「必ずやります」って感じなんですけど。

hidek:あー。日本だと、どうしてもね、どうしてもってことないですけど、iOSの方がシェアが大きいというか、iOSファーストで作るプロダクトも多いと思うんですけど。海外で言うと、それこそAndroidファーストだと思うので。一方で、Androidがね、なかなかOSがdeprecateしないというか(笑)。

近澤:そうなんですよねー。

hidek:いつまで経っても古いバージョン。OSの数も多いし、デバイスの数も多いし。本当にテスト泣かせですよね。

近澤:そう。だから大変だ、っていうのはあるんですけどね。

hidek:うん。

近澤:そうなんですよねー。やっぱり、日本だと、まだ、iOSファーストでいいかもしれないですけどね。シンガポールのお客さんとかと話すと、やっぱり「Androidがないと話にならん」っていう感じ。

hidek:にはなりますよね。そうですよね。

近澤:になっちゃいますね。

hidek:昔もありましたよね。Androidのゲームを作っていると、Chromiumになってからはよかったんですけど、前のWebのやつだと、全然もう、それこそレンダリングの順番が違うだとか。

近澤:そうそう!

hidek:JavaScriptの実行の順番が違うだとか(笑)。

近澤:そうなんですよー。それ、やってたんですよ。僕、DeNAで。

hidek:ですよね。やってらっしゃいましたよね。

近澤:はい。そうなんですよ。Canvasをベースにしたゲームのフレームワークみたいなのを作っていて。Android 2系とかが、もう、地獄でしたね。

hidek:ですよね。

近澤:Canvasの描画にバグがあったので(笑)。

hidek:(笑)。

近澤:ロクに描画されない、っていう。

hidek:常に紀平さんがそれについて悪態ついていて。「いや、あなた、Web好きでしょ」とか思いながら(笑)。

近澤:(笑)。ブラウザにバグがあって直らないので、もう、これ、どうにもならんな、っていう。

hidek:(笑)。でも、その辺も解決していくと、それこそスケールするとは思うので楽しみですよね。

近澤:そうですね。はい。これからがんばらなきゃいけない。

スピードと品質

hidek:なるほどですねー。ちょっと話が飛んじゃうんですけど、品質担保をしていくっていうのが、コストがかかったりだとか、時間も含めて、かかるというところで、スピード・アジリティみたいなところのトレードオフって、よく言われがちだと思うんですけど。Autifyの開発自体でも、結構、さっきの技術負債的な話もあったと思うんですけど、その辺ってどうやって意思決定とか……?

近澤:これ、僕、すごく、hidekさんにもお話聞きたいな、と思っていたんですけれども。そうですね。結構、今まで「クオリティかアジリティか」みたいなので、どっちかを取ればどっちかが落ちる、みたいなのはあったと思うんですけど。そこは、やっぱり、結局、自動化のカバレッジを上げることによって、アジリティとクオリティの両立ってできると思っていて。で、僕らのお客さんでも、「日に13回デプロイします」みたいな、アメリカのお客さんですけど、そういうところもやっぱりあったりして。彼らとかも「マニュアルテストはしない」「全部自動化」みたいな。そういう会社って、すごくアメリカで増えてきていて。で、やっぱり、「それをやればアジリティって上げられるな」みたいなのはすごく感じるんですけれども。

hidek:うんうん。

近澤:だから、結局、ちゃんとカバレッジをトラックして、自動化率を上げていかないといけないんじゃないかな、っていうところで。そうですね。負債の返却っていうのもそうだし、負債の返却とかって、カバレッジの向上みたいなのって、「まとめてやる」じゃなくて「毎回やる」とか「定期的に必ずやる」みたいな感じにしないと、アジリティとクオリティのバランスって取れないんじゃないかな、みたいなのを最近すごく考えていました。

hidek:昔、おととしくらいかな、EOFって、Engineering Organization Festivalだっけ、和田卓人さんが「質とスピード」の話をしていて。

近澤:そう。質とスピード。はい。

hidek:はい。あれ、結構いい話というか、すごく大事な話をたぶんしていたと思うんですけど。あれ、かいつまんで言うと「品質とスピードはトレードオフではない」と。

近澤:うん。

hidek:「二律背反ではなくて、中長期的には、どちらかを犠牲にすると片方も犠牲になるよ」っていうことを、すごく丁寧に説いていたと思うんですけど。要は、内部品質、特に保守性ですよね、を高めればスピードは中長期で上がるし、逆に落とすと中長期でスピードは下がるよ、っていうところを説いていて。あれ自体、すごくわかりやすくいい話だったな、と思うんですけど。ただ、結構、短期の話で言うと、よくQFCDみたいな話で。要は、現実の社会だと、エンジニアリングしていると、どうしてもデリバリーがロックされてる、っていう。さっきのね、「3ヶ月で作らなきゃいけない」みたいな話があったと思うんですけど。デリバリーロックされている中で、まあまああるんですよね。で、その場合に、スコープとかフィーチャーを小さくしたいんですけど、もうこれ以上小さくできなかったりだとか。あと、僕なんか、金融事業をやっていると、一回のリリースのスコープがめちゃくちゃ大きいんですよね。いろいろ考えなきゃいけないことが多いんで。一方で、さっきもちょこっと触れましたけど、金融だと品質、特に「当たり前品質」みたいなところは絶対に担保しなきゃいけない、ってところもあって。

近澤:うんうん。

hidek:あと、コスト。でも、コストって、人を入れてなんとかなる、って大体無理じゃないですか。

近澤:そうですね。限界……。うん。

hidek:その人がドメイン知識を得るための学習コストとかもあって大体うまくいかないので。そうすると、やっぱり残るものって、内部品質を犠牲にせざるを得ない。たとえば、ちょっと汚いコードとか、もしくは、あまりマイクロサービス化しないでモノリシックの上にくっつけちゃうだとか。いわゆる技術的負債を借りてしまうパターンっていうのは往々にしてあって。で、和田さんの話の中では、「『あとで技術的負債を返す』ってやつは大体返さないので詐欺師だ」みたいな話があったと思うんですけど(笑)。

近澤:(笑)。

hidek:そうですね。僕の経験だと、結構、ちゃんとそこをあとで返す、っていうターンを設けさえすれば、短期的なトレードオフを享受しながらも、そこは「返すターン」っていうのをしっかり設ければいいのかな、と思って。そこで、しっかりリグレッションテストの自動化だとかをしていくっていうのは、すごく……。そのあとのスピード、さらに重要だな、と思って。そういうことは結構やれてますかね。なので、QFCDのトレードオフを排除するためにも、やっぱり自動化。技術で、人じゃなくて、そこをいかに短縮するか、っていうのはすごく重要だな、っていう風には思っていますね。

近澤:そうですね。ちょうど先日、他のスタートアップ2社と、10X(テンエックス)とLayerX(レイヤーエックス)って会社2社と合同で「開発のクオリティと改善スピード」みたいな話を3社で話したんですけど。やっぱり、「トレードオフっていうよりか、アジリティとクオリティのバランスみたいなのってステージによっていろいろ変わるよね」みたいな話をしていて。

hidek:はいはい。

近澤:あと、クオリティも、事業とかドメインとかステージによってクオリティの定義が変わるので。初期の場合って、ある程度クオリティを犠牲にして、犠牲にしてっていう言い方はおかしいかもしれないですけど、やっぱりアジリティの方がものすごく大事なので、こうなる、これが正解、みたいな話だったんですけど。

hidek:はい。

近澤:ステージが上がっていくと、やっぱり、お客さんが増えてきて「品質が大事」みたいになってくると、だんだんちょっとバランスが変わってって、クオリティの方が少し上がってくる、みたいな感じになってくるのかな、と思っていて。ステージによって「両立の仕方」とか「両立のレベル」みたいなのもすごく変わるよね、とか。クオリティの定義するところも事業によって変わるよね、みたいな話はしていて。すごくそうだな、って思ったりしました。

hidek:本当にそうなんですよ。それこそ、前は、プラットフォームはさすがに落とすわけにいかないですけど。これは怒られちゃうかもしれないけど、ゲームだと最悪詫び石を投げればなんとかなるだろうから(笑)。

近澤:(笑)。

hidek:あるじゃないですか(笑)。怒られる話ですけど。一方で、金融で止めるとどえらいことになりますし、この先、たぶん医療みたいなところになってくると、それこそ止められない。

近澤:そうですね。

hidek:失敗が許されない、みたいなところがあるので。やっぱり、おっしゃるとおり、事業の性質で求められる品質っていうのは変わってくるし、そこでうまくバランスを取らなきゃいけないんですけど。ただ、やっぱり、中長期でプロダクトをグロースさせるためには、やっぱり、内部品質・保守性っていうのは非常に重要で。それを短縮化するためにテストの自動化っていうのはすごく大事だなー、っていう風には思っていますね。

近澤:そうですねー。まさしく。

技術的負債の返済

hidek:うん。なるほどなるほど。でも、結構、それを経営に、自分も経営の立場なんですけど、たとえば、さっき言った「技術的負債を返済するターンがほしい」と。「このクォーターは、ちょっとプロダクト、フィーチャーが出せないかもしれないけど、ここはエンジニアのリソースを技術的負債にあてさせてほしい」っていうのは、借りる前にコミットさせるんですけど。それを話してもですね、なかなか伝わらないことが。世の中のCTO・VPoEはそこをすごく苦労しているとは思うんですけど(笑)。幸いなことにうちの経営陣は、意外とそこの理解があるみたいなんですけど。元エンジニアが経営トップっていう立場だと、そこの意思決定しなきゃいけないじゃないですか? その辺で気をつけていること、もしくは、そういうのをちゃんと受け入れるためのキャッチアップ、普段どうなさっているんですか?

近澤:そうですね。結構、それこそ「クオリティとアジリティ」みたいな話が、僕らもちょうど開発のフェーズが変わってくる中で、やっぱり話題として大きくあがってきて。で、僕も、そのときに、エンジニア全員と1on1して、何が起きているのか、みんながどう考えているのか、みたいなのは、まず理解しようと努めました。で、そこで一個気がついたのが、みんな過去の技術負債に対して、すごくネガティブな感情はあって、「なんとかしたいけど、機能を出していかなきゃいけないから見すごさなきゃいけない」みたいなところにすごく課題を感じていて。で、やっぱり、僕も技術負債って、定常的に返却していかないとスピードが出ない、ってのはもちろん理解はしているんですけど、「じゃあ、それをいつやるのか」とかって、あんまり答えがなかったんですけど。話していく中で、「これって『いつかまとめてやる』じゃなくて、毎回、定期的にやらないとダメなやつなんだな」と思って。

hidek:はい。

近澤:で、そこからは、今は、CTOと一緒に話して、スプリントの中で30%までは技術負債の返却にあてる、好きに使っていい、という感じでやって。どんどん改善のアイデアが出てきて。そこで、結構、みんながモチベーション高く、「どんどん返却していこう」「こんなアーキテクチャにしたらいいんじゃないか」「テストもどんどん増やしていこう」みたいな感じで、エンジニア発信でどんどん改善が進んできた、っていうのが、最近起きた変化ではあったりしますね。

hidek:なるほどですね。僕らのところで結構起こったことで言うと、「技術的負債=悪」みたいな、「絶対に借りない」みたいな、そういう人たちがいたはいたんです。いろいろな経験をなさったんでしょうね。

近澤:わかります(笑)。

hidek:痛い目に遭っているので、よくわかるんだけど(笑)。

近澤:辛い経験が。

hidek:でも、技術的負債っていう「負債」っていうアナロジーって、いろいろな意見があるんでしょうけど、僕は一定うまいアナロジーだと思っていて。負債って別に悪いことではないじゃないですか。しっかり返せば。

近澤:そうですね。

hidek:なので、まず「技術的負債=悪」じゃないよ。だけど、借りすぎはよくないですよ。

近澤:うんうん。

hidek:やっぱり「ご利用は計画的に」というか。

近澤:返済できなくなっちゃうから(笑)。

hidek:はい。やっぱり「小さく借りて小さく返す」っていうのを連続的に行う、っていうのは非常に重要だね、というところは通って。それはやっぱり経営側にも伝えなきゃいけないし、そういう技術的負債に対してアジリティを、ともすればオーバーエンジニアリングになっちゃうような人たちに対しては、そういうのを説いたりしてバランスを取ってみたりとかはやったりとかはしましたかね。

近澤:うん。難しいですよね。だから、エンジニア側にも「負債は悪じゃない」って、「アジリティを大事にしなきゃいけないところもある」みたいなところのバランス感覚を持ってもらわなきゃいけないし、経営側にも「負債を返却していくっていうのが大事」っていうことを説かなきゃいけない、って感じですよね。

hidek:たぶん、世のCTO・VPoE・エンジニアリングマネージャーさん、みんな、その辺苦労してるんだろうな、っていう(笑)。

近澤:いや、わかります。僕も、もともとエンジニアですけど、やっぱり「なんでこんなにスピードが遅いんだろう」とか「そのリファクタリング、今、いるのかな」とか、僕でも思っちゃったりするので。それは、やっぱり技術がわからない人からすると、「そんなことやっている場合じゃないだろう」って絶対思うだろうな、と(笑)。

hidek:そうなんですよね。そこをちゃんと説いていく、っていうのは結構大事。だから、和田さんの話っていうのは、すごくわかりやすく。あれ、経営側に見せるとすごくいいんだろうな、っていう風には思って見ていましたね。

近澤:そうですね。

技術キャッチアップの方法

hidek:なるほどなるほど。そうですねー。あと、全然話が飛ぶんですけど(笑)。普段、お休みの日って、今、すごく忙しいと思うんですけど、何をなさってるんですか?

近澤:結構、本当に週末はちゃんと休んでて。

hidek:なるほどなるほど。

近澤:はい。土日に、基本的にはもうほとんど仕事はしない、っていう感じで。

hidek:うーん。

近澤:はい。で、そうですね。週末は家族のために時間をあててる、みたいな感じになってますね。はい。

hidek:うん。なるほど。技術キャッチアップみたいなのって、どういうタイミングで、どういう形でやってるんですか?

近澤:あー。それは、結構課題ですよね(笑)。昔みたいに時間が取れなくなっちゃったから。だから、最近は、今までって、エンジニアのときって、新しい技術があったら「自分で使えるようになろう」だったんですけど。

hidek:うんうん。

近澤:今は「そこの概念がわかればいい」っていうのがゴールにはなるので。

hidek:あー、なるほどね。

近澤:「わかる人に聞く」っていう感じですね。だから、エンジニアとかに「これって何なの?」みたいな。「こういう理解なんだけど合ってる?」とか「こういうアルゴリズムで動いていると思うんだけど、そういう理解でいいの?」みたいな、そういう感じでアップデートしている、みたいなのが現状ですかね。

hidek:家族ができると、どうしてもそういうところはだんだん時間が使えなくなるし。うん。一方で、今の技術領域って、すごく広くて複雑じゃないですか?

近澤:そうですねー。

hidek:それこそ、我々がやっていたようなころからすると(笑)。だいぶ技術領域って広くなってて。だから、意外と、「分業制」って言ったらあれなんですけど、スペシャリストに聞いて、っていうのが、たぶんいいんだろうな、とは思うんですけどね。

近澤:どうされてるんですか? hidekさんは。

hidek:僕はですねー、コードはもうほぼ書かないんですけど、書籍は一応読むようにはしていますね。

近澤:うんうん。

hidek:はい。いまだに『WEB+DB PRESS』とかは読むようにしていたりだとか。

近澤:うん。

hidek:間違った判断はしないように。やっぱり意思決定とかは求められるんで。で、経験はあるんですけど、やっぱり書いていない分、直近の新しい技術に対しては……。まあ、意思決定を間違えない、と。知見っていうのは、書籍だとかインターネットから入れるようにはしているんですよ。でも、おっしゃるとおり、細かいところはわからんので、その辺は愚直に聞いてって、謙虚に聞いていく、っていうのは心がけてますね。

近澤:いや、本当に、日進月歩が凄まじいので。

hidek:早いですよね。最近、そんで。

近澤:最近、聞いたことないライブラリとかサービスが出てくるので、もうやばいな、と思って(笑)。

hidek:(笑)。

近澤:「え、それ何?」「知らないんすか?」みたいな(笑)。

hidek:フロントエンドのところって、だいぶ技術の移り変わりが落ち着いた感があるけど、それでもちょいちょいありますもんね。

近澤:そうですね。うん。

hidek:一時期、ひどかったじゃないですか?

近澤:一時期は、もう、ひどかったですね。はい。そのくらいのタイミングで、僕、割りとフロントエンドをゴリゴリやっていたので。

hidek:あー、大変ですね。

近澤:でも、そのときのやつがだいぶ安定してきた、みたいなのが現状な感じはするので。はい。今はまだ延長線でやれる感じするんですけど。5年後、10年後は無理だろうな、って(笑)。

Autifyの営業を募集中

hidek:(笑)。はい。わかりました。ありがとうございます。そうですね。どうですかね、今、時間的には。

gamiさん(以下、敬称略):時間的には1時間ちょいくらいなので、こんなもんかな、と思います。

近澤:いろいろお話できましたね。

hidek:録れ高、いい感じですか?

gami:ばっちりでございます。

近澤:いい録れ高。いやー、ありがとうございます。いろいろとおもしろいお話ができて。

hidek:いえいえ、こちらこそ。結構、この辺は課題が多いし。でも、逆に課題が多いんで伸び代はあるというか、いろいろ技術の工夫のし甲斐があるというか。

近澤:そうですね。ぜひ、メルペイさんでも使っていただきたい。

gami:(笑)。

hidek:いきなり営業が来た(笑)。

近澤:(笑)。

gami:たしかに。でも、聞いていて、すごくAutifyを使ってみたくなりましたね。

近澤:本当ですか? ありがとうございます。

hidek:まさに、この領域、Burning needs、あちこちで燃えているので。

近澤:めちゃめちゃ燃えてます。アプリもめっちゃ燃えてますね。

hidek:ですよねー。ここは、めちゃくちゃ楽しみにしています。

近澤:ぜひ。はい。

gami:聞いていただいている方もエンジニアの方が多いと思うので、「使いたい」っていう声を社内であげてもらえると、近澤さんもうれしいんじゃないかな、と(笑)。

hidek:(笑)。

近澤:Webでもモバイルでも、どっちでもいけますんで。はい(笑)。

hidek:Founderが営業に来ます。

近澤:そう。僕、今、営業してるんですよ。本当に。営業がなかなか取れなくて。

gami:そうなんですね。まだ、やられてるんですね。

近澤:いやー、そうなんですよ。いや、僕がやっちゃいけないとは思うんですけど、人手が足りなさすぎるので。はい。モバイルの営業、僕とCOOがやってますね(笑)。

gami:おー(笑)。

近澤:いやー、もう、本当に営業ができる人が来てほしいな、って。やっぱりエンジニア向けの製品なので、エンジニアと会話するのでなかなか、ね。

hidek:そうですよね。

近澤:「ゴリゴリ営業畑」みたいな人だと難しい。

gami:たしかに。そうですね。

hidek:セールスエンジニア的な人がやっぱり必要ですよね。

近澤:そうなんですよー。

gami:お聞きの方で興味のある方がいたら、ぜひ(笑)。

hidek:(笑)。

近澤:「エンジニアから営業に転向したい」みたいな人はすごくウェルカムです。

hidek:あー、最高ですね!

gami:たしかに。

近澤:僕もそう。僕も別にプロの営業じゃないですけど。

hidek:(笑)。

gami:ありがとうございます。

近澤:ありがとうございます。

gami:そしたら、こんな感じで締めていければと思いますが。ぜひ、お聴きの方、番組への感想をいただければと思います。出ていただいた近澤さんもフィードバックがあるとうれしいかな、と思いますので。

近澤:ぜひ!

gami:ぜひ、stand.fmのコメント機能、Twitterのハッシュタグ、#hidekのエンジニアと長話、までお願いします。はい。じゃあ、こんな感じですかね。

hidek:はい。

gami:話し足りないことなど、大丈夫ですか?

hidek:大丈夫です(笑)。結構話しちゃった。めちゃめちゃ楽しかったです。

近澤:大丈夫です。めちゃめちゃ楽しかったです。ありがとうございます。

hidek:ありがとうございます。

gami:本日は近澤良さんをゲストにお迎えしてお送りしました。ありがとうございました!

近澤:ありがとうございました!

hidek:ありがとうございました!


この記事が気に入ったらサポートをしてみませんか?