00:00
今回のテーマは、複雑になるビジネスのコアロジックを どう分割するのか問題です。
皆さん、どの会社でも経験されていると思いますが、 特にビジネスの中心部分っていろんなロジックが集まってきて
サービスが成長するとどんどん複雑になっていきますよね。 でもこれをやっぱりソフトウェアの設計的に分割してシンプルに保つっていうのは
普遍的な問題だったりもするわけです。 こういうところにエンジニアリングマネージャーとしてどんな観点を持って
アプローチしていくのかっていうところも大事だったりすると思います。 今日はこういったお話とビジネス観点のところも少し聞いていきたいなと思っております。
というわけで、ゲストには前回に続いて株式会社カミナシエンジニアリングマネージャーの 宮本大嗣さんにお越しいただきました。
はい、よろしくお願いします。 前回はどちらかというとエンジニアリングの組織観点の話を中心に
後藤さんといろいろお話しさせていただきましたが、 今日はまた別の方面でいろいろと話を深められればと思っています。
エンジニアリングマネージャーの問題集。
そうですね。今宮本さんからもあったとおり、 前回結構組織っていう観点でお話を伺ったので、
今回エンジニアリングとか、もし時間あれば 事業っていう観点で問題にアプローチしてみたいなと思っています。
このPodcastでは、エンジニアリングマネージャーの方が 立ち向かっている問題について深掘っていこうというのがやっていくことなんですけれども、
私自身、EMっていうのはチームとかエンジニアリング っていうものをマネージしていると考えているんですけれども、
ここは普通のことなんだと思うんですが、 こういったものを取り巻く組織とか事業っていう要素、
こういったものを日々の仕事とは少し違う観点で 問題を見るための道具として使うことで、
エンジニアリングマネージャーが成果を最大化するための 問題を解き明かすっていうことができるんじゃないのかなと考えているんですね。
なので、このPodcastではそういったちょっと違った観点で 問題に対してアプローチしていくっていうことをやっております。
今日はエンジニアリングとか事業っていう観点で お話を伺っていきます。
エンジニアリングのところを早速なんですが、 前回も出ました、組織がスケールしていくときのチームを分割するっていうところに関連して、
ソフトウェアのほうも分割するんだよっていう お話をされていたと思います。
それができると理想だよねっていうのは 僕も重々知っておりますが、
なかなかやっぱりソフトウェアを最初一つだったものを 分解するのって一般的に難しいんですよね。
スパッと分かれるラインというか、チームトポロジーとかで 設立面っていうふうに表現されてたりする面ですね。
03:00
そういうのがあればそこで分けるっていうのが セオリーだと思うんですけれども、
雷さんの中で設立面を見出す分析ワークだったりだとか、 もしくはこれが設立面だよみたいなものがすでに分かってるとか、
なんかその辺ってあったりするんですかね。
そうですね。今まさにそこは非常に悩んでおりまして、
お客さまが記録された情報をエクセルに 特定のセルに出力するとかっていうバッジ処理みたいなことを
やってる機能とかあるんですけど、 そういったものは多分切り出しても問題ないのかなとは思いつつも、
今のチーム人数とかを今後見ると、そこだけ切り出して そちらの担当をする専門のチームを作ると、
今度本体の開発並びに運用面で だいぶ苦しくなってくるっていうことが予見されますし、
今の規模感でその単位だけ割っても、 割られた方のサービスの規模がまだ小さいので、
ちょっとやりがいとかですね、 キャリア育成とかそういう観点でもちょっと苦しかったりするので、
設立面なんとなく見出せてはいつつも、 今そういった観点で分けるのは望ましくないのではというところで、
最適な設立面というものを探すのに苦労している っていうのが今の実情ですかね。
なるほどな、そうですよね。
最初の方にお話いただいたところを もうちょっと聞きたいんですけど、
設立面らしきラインで分かれそうな機能として、
Excelに書き出していくような機能っていう 例を話されていたんですが、
その機能は何ですか、
雷さんのプロダクトのいろんなところに 現れるとか、
そういう意味で設立面が現れてるんでしょうかね。
そこは明確にいろんなところに現れるというよりは、
お客様が記録したものをインプットに Excelに書き出してっていうところなので、
いろんなところには現れないっていうのも 立ち位置としてはある機能なので、
分けやすいっていうのはあるかなと思いますね。
なんか共通ライブラリ的な機能とか そういうことなんですかね。
我々のお客様は最終的に現場で、
例えばチェックリストみたいなもので動作されてる機械が 正常に動いてるかどうかチェックして、
チェックした内容をまとめて報告書みたいなのを 作成されたりするケースがありまして、
そういうときに大体Excelを使われますと。
そのインプットデータを直接Excelに 書き出した状態で報告作業の準備を
だいぶ軽微にできるような このExcel変換機能みたいなものがあるんですけど、
06:00
なんか共通ライブラリというよりは それ専用のそういう機能だったりしますね。
そうかそうか。
比較的本体の業務とは切り離して 考えることができる機能っていう感じなんですかね。
そうですそうです。
そうかそうか。
確かにそれは分離はできそうですね。
そうですね。
分離はできそうだけれど、そこにプロダクトとしての 価値がめちゃくちゃあるのかどうかとか、
開発の変更要求がすごい頻繁にあるのかとか、
そういうところを鑑みると そうでもないっていう感じなんですか。
現時点では特定の契約プランで 使える機能だったりするんですけど、
現時点の規模感だとわざわざ分離して、
適切な時間でちゃんとExcelに変換されるように 動かさなきゃいけないみたいな、
エンジニアリング的には大量のデータのハンドリングって だいぶ難問だと思うんですけど、
まだそこまでの規模感にその単体の機能だけでは至ってないので、
今分けたとしても専用チームを作るまでの形にはなりにくい、
だいぶ過剰なチームスタイルになってしまいそうかなっていう そんなイメージですかね。
なるほど。将来のチーム分割の候補かもしれないけど、 今じゃないっていうことですよね。
そうですね。
そうするとソフトウェア的に今分けたいところって、
どの辺りを分けたいっていう目星的なものってあるんですか。
そうですね。目星が正直なところ今検討中でして、
絶対やらないと決めてるのはWebだけ、モバイルだけ、 APIだけみたいななんて言うんでしょう。
機能単位が縦で分割するとしたらそれは横で分割してる みたいな意味合いになるかと思うんですけど、
横で分割するということはやらないっていうふうに決めていて、
フィーチャー単位って言ったらいいんですかね。
機能単位で分けるっていうことは決まってるだけで、
目星は今非常に頭を悩ませながら見定めているというか 考えてるみたいな段階ですね。
なるほど。
これはやらないっていう例も重要だよなっていうのは思いますね。
それもやっちゃいがちなことだと思うので、
同じプロダクトなのにWeb向けのチームと モバイル向けのチームが別々だったりするっていうのは
実際見たこともあるので、
使ってる技術も違ったりするとチーム分けちゃいがちですよね。
チーム分けるっていうのが目的になっちゃうと そういう構成もあり得るんだけど、
やっぱり一つのプロダクトを作ってるっていう中で チームが分かれちゃうとそこのコミュニケーションが
素になっちゃって、作ってるものに違いが生まれちゃったりだとか、
09:03
余計な冗長なことができちゃうんですよね。
不具合を起こしちゃったりとかね。
そういうのもできやすくなるのかなと思うんで、
それを自覚的に禁止してるっていうのは 結構大事なポイントを抑えてるなと思いました。
ありがとうございます。
でもやっぱりどこを切るのかまだ見つからないっていうのは、
まあそうですよね。
簡単に見つからないですよね。
でもとはいえ何だろうな、
扱ってるソフトウェアのものすごい複雑度が 上がっちゃってる部分とか、
そういうところって何か小さくしていきたいっていうの。
チームの観点とは別で、
ソフトウェアっていう意味だと、
そういうモチベーションって必ずあるものだと思うんですけど、
なんかその雷さんのソフトウェアの中で、
ここどうにかせんとあかんみたいな、
そういうのってあったりするんですかね。
そうですね。
一応雷というサービスが生まれた経緯とか、
代表の諸岡さんのノートとかに載ってるんですけど、
一時期会社の斬新が残り10ヶ月ぐらいになった瞬間があって、
ラストチャンスという形でチャレンジしたのが 今の雷というサービスだったりするので、
正直技術不採を考慮してとか、
そんなこと言ってられなかったので、
技術不採がいって残ってるっていうところは、
今後の機能開発とか、
そういったところをよりスピードに進めるためにも、
適切にコントロールしなければいけないっていうのは 一つありますかね。
技術的不採もあれですよね。
それをゼロでやってる会社っていうのはないと思うんで、
特にスタートアップだったら、
本当に何が正解かもわかんないし、
正しい設計って動いてるものの中からちょっとずつ、
後からわかったことを元に綺麗にしていく っていうことしかできないと思うので、
不採は一定ありますよね。
っていう中でも、
不採は不採なんだけど、
扱ってるビジネスの特性だったり、
プロダクトの仕様っていうのかな、
そういうのによって生まれてる複雑さみたいなものも、
あるんじゃないかなと思ったりしていまして、
それはもう本当に、
やりたいビジネスに対して、
どういうプロダクトの作り方をするかっていう、
最初の頃のプロダクトマネージャーだったり、
アーキテクトだったりのスキルによって、
めっちゃ綺麗になってるものも、
運良くあるかもしれないんだけれども、
なかなかそういうのもないなと思ったりもしてます。
上梨さんだと、
2B向けで、
マルチテナントなわけですよね。
1つのプロダクトで複数の会社さん向けの、
機能を提供してるっていうものだと思うので、
一般論として、
12:00
マルチテナントでかつビジネス向けっていうのは、
まあまあ難易度高いんだろうなって思うわけですよ。
この辺の難しさが、
どういうところでソフトウェアなところで、
現れてきてるのかとか、
もし今わかってるものがあれば、
教えてほしいですね。
そうですね。
おっしゃる通りかなと思ってまして、
そもそも我々のサービス、
いろんな業界で汎用的に使えるような、
作りにしているので、
そこら辺の汎用性を持たせるために、
複雑性は多少あるかなと思ってます。
その複雑なものを、
データベースで結構吸収してるのかなと思ってまして、
データベースがちょっと複雑なところは、
特徴かなと思いますかね。
なるほどな。
いやまあそうですよね。
ビジネス向けでかつ、
汎用性も意識して、
さらにマルチテナントみたいな、
次元をだいぶ上げて考えないといけないので、
これはもうデータベース設計のお題として、
超面白いだろうなと思うんですけど、
いや作るのめっちゃ大変ですよね。
そうですね。
結構セオリーを投資している設計かなと思っていて、
別に隠す必要もないんですが、
一応データベースはAWSのAuroraを、
マイアスケールベースで使ってるんですけれども、
結構階層構造になりやすいデータベースの作り、
テーブルの作りになってまして、
昔はAWSのAuroraのマイアスケールって、
マイアスケールの5系までしかカバーしてなかったので、
マイアスケールの8系から使えそうな機能が使えなかったので、
テーブルの設計もそれによって、
だいたいオライリーさんのSQLアンチパターンとかだと、
内部ツリーという項目で、
階層構造の設計に関して、
アンチパターンにならないようなことについて触れてますけど、
ああいうのをすごい考慮して作ってる結果、
セオリーにはのっとってるけれども、
そういう複雑度を吸収するために、
データベースが若干複雑になってるっていうのが今の状況ですかね。
なるほど。
なんかもうちょっと具体的にイメージしたいので、
これお話しいただけるかどうかっていう、
ちょっと秘密に触れるかもしれないので、
もし秘密に触れたらカットでになっちゃうんですけど、
なんか具体例ってコーナーが1個ないですかね。
具体例ですか。
なんかですね、チェックリストがあるとして、
Aというチェック項目があります。
そこで事前にルールを作れるような機能があって、
ルールに基づいて、
例えばAかB両方どちらかで回答するみたいな回答方式で、
そのチェック項目に関して考えたときに、
15:01
仮にBを選んだら、
次はこういうチェック項目を出すようにしてくださいみたいなですね。
紙なしでノーコードツールっていう側面があってですね、
ウェブからモバイルの業務アプリを作っていくみたいな仕組みなんですけど、
そのモバイルのアプリケーション上に出すチェック項目を、
そうやって回答した内容によって、
いろいろ条件分岐で出し分けられるようになってまして、
それで今申し上げたような、
例えばABの回答方式があって、
Bと回答したら、
次はかっこはみたいな質問を出してくださいと、
そこでまた回答方式として、
なんかABみたいなことを準備して、
今度はAを選んだら、
次はかっこうを聞いてくださいみたいなですね。
そういう条件分岐、
ネスト構造になるような機能があるので、
そこがだいたいツリー構造と言われてるような、
データベースの設計を考慮しなきゃいけなかったりする、
一例だったりしますかね。
そこは結構作りがいがありそうですね。
ものすごく複雑だろうし、
単なるシンプルなツリーじゃなく、
循環参照してるようなものとかも、
おそらくあるんじゃないのかなとかも思うんですけどね。
結構なので、
最適的な処理とかを結構実装面で作っていたり、
結構実装難易度は高いプロダクトかなと、
私から見てても感じますね。
設計はセオリーに則って、
平方テーブルモデルみたいな設計モデルが、
データベースのテーブル設計であるんですけども、
そういうのを使ったりとかしてはいるけれども、
いろんな機能が大体飛び向けたと、
できていくのかなと。
2Cはシンプルだと思いますが、
2Bは複雑な業務要件に応えるケースが多いと思うので、
そういったところで、
やはりデータベースのテーブル設計とかも、
ちょっと複雑度は上がってるのかなと思いますね。
なるほどな。
そうですね。
だから業務プロセスを、
ある種の上梨さんなりのモデルで、
表現できるようにしてるっていうプロダクトだと思うので、
そこがたぶん一番のプロダクトのコアなんじゃないかなという感触を
今、持ちました。
Greenにかけない転職裏話ラジオ、
略してグリテンラジオは、
転職アプリGreenの運営メンバーが、
個人的一押し企業について語ったり、
現場で感じる転職や中途採用のリアルについて話す音声番組です。
毎週月曜朝6時更新です。
通勤や休憩時間のお供にぜひお聞きください。
詳細はカタカナで、
グリテンラジオと検索してチェックしてください。
18:01
そうですね。
そこを少しお話を戻すと、
なんか分解できるのかみたいなところだと思うんですけれども。
分解の余地ってあるのかな、ここは。
それはもうそのものみたいな感じですよね。
そうですね。
各章は結構、密接に絡んで利用されるような、
機能の作り方をしているので、
ここまで話すとだいぶ設立面を探すのが、
なんとなく難しいと、
感じていただけたかなと思うんですけど。
今、私たぶんどっぷり使っているので、
設立面を探すのに苦労しているのかなと思うんですけど、
そういったものは、
新しく入社された方とかにもお話を聞いたりして、
起立頂はやっぱり何かしらは作らないと、
どちらにしてもシステムを分けられないので、
どっぷり使った視点、新しい人の視点、
そういったものをいろいろと組み合わせながら、
なんとか見出したいみたいな、
そういう形になっちゃいますかね。
そうですよね。
本当に僕も見てみないと分からないんですけど、
考えうるアプローチ、
抽象的な話しかできないんですけど、
言うと、やっぱりコアの部分をシンプルにするというか、
抽象化するみたいなことはできるかもしれないと思うんだけど、
それは設立面ともまた違った話かと思うんで、
循環参照もあるような業務フローというか、
チェックリストフローというか、
そこだけを抜き出したような抽象モデルを1個作っておいて、
それを取り巻く、チェックしたら何かしますみたいな、
オプションの動きみたいなのがおそらく、
プラグイン的に後からいろいろ作られていくんじゃないのかな、
みたいな想像をしたんですよ。
そうすると、コアの動きをする部分だけすごく小さく作って、
あとはいろんな個別の会社さんの要件だったり、
ビジネス要件に応じて振る舞い的なものを追加しやすい、
プラグイン的に作れるような、
そういう仕組みとかを想像するかもしれないなって思いました。
ただの僕の感想ですけど。
ありがとうございます。参考にさせていただきます。
設立面みたいな感じではないですね。
それ自体起きるみたいなのは思いつかないですね。
そうですね、いろいろお話を聞かせていただいて、
基本的にソフトウェアを何らかの形で分割していくっていうテーマだけを
今お話ししたんですけど、
難しいですよねっていう回答以外ないのかなというところで、
いろいろ過去から分析アプローチとか研究されてきてるところはあるので、
21:03
やれることはあるんでしょうけれども、
でもやっぱりコア中のコアの部分を
どんどん複雑になっていくのをどう抑え込むかっていうのは、
一番難しい問題だと思うし、
簡単に切って済むものでもないなというのは間違いじゃないとは思いますね。
そうですね。
結局不可逆な意思決定といいますか、
一度決めて進み始めると戻ったら大変なことになってしまうかなと思うので、
そこら辺の意思決定みたいなところとかはどうしても慎重にならざるを得ないかなと
私も思ってますし、当然CTOもそう思ってるっていう感じですね。
今おっしゃられたのですごい大事だなと思ったので強調しておきたいんですけれども、
意思決定の中に戻せるものと戻せないものがあって、戻すのがすごい大変とかいうものがあって、
不可逆的な意思決定っていうのはより慎重になるべきなんですよね、マネージャーとしては。
そういう意思決定をするなら、いろいろ小さなトライアルを重ねてエビデンスを積み重ねたりだとか、
失敗しない形っていうのをちゃんと整えてからやるっていうか、
できるだけそういう意思決定しないように持っていくっていうのがセオリーということだと思いますよね。
そうですね。そういう意思決定にならない状況に守っていけるのが多分一番いいですよね。
ですよね。マネージャーとしていい教訓っていうのも得られました。ありがとうございます。
今、エンジニアリング観点、一つの観点分割っていうところしかお話できてないんですが、
ここ話し出すときにもなさそうなんで、ちょっと一旦ここまでにとどめて、またちょっと違う観点ということで、
事業っていうものを取り上げて、ここもさらっと伺いたいなと思ってます。
これまただいぶ目線が変わるんですけれども、そもそもこの上梨さんの中で、上梨という事業っていうものですね。
例えばエンジニアっていう立場から見たときに、この事業っていうのは結構近い距離感で行われているものなのか、
それともすごい隔離された感じなのかというと、どっちなんでしょうかね。
そうですね。近いかなと思いますね。
特にビジネスサイドだとカスタマーサクセスチーム側が最も近いかなと思ってまして、
不具合に関するお問い合わせをいただいたときとかに、カスタマーサクセスチーム側のほうでいろいろ切り分けをしていただいて、
24:02
本当にシステムに絡むような話とかだけをエンジニア側に共有していただくようにしていただいたりもすることがございますし、
カスタマーサクセスチームには限らないかもしれないですけど、一応上梨のバリューの一つである現場ドリブンというものがあるんですけど、
それに基づいて結構エンジニアの人もお客様の現場、工場だったり店舗とかに訪問させていただくことがあって、
そこは当然エンジニア単体で行くというよりは、カスタマーサクセスチームの方だったりプロダクトマネージャーだったりデザイナーだったり、
時には経営陣の方と一緒に行くことがあるんですが、そういった方々と一緒に現場を訪問して、
共通の一時情報を得て実際作るものを考えるときに、エンジニアはエンジニアなりの目線で話して要件を詰めたりとかできるようにしていたり、
あとは不具合解消に関してどうしても原因を追求するためにお客様の現場に行かなきゃわからないケースとかあって、
そこは結構カスタマーサクセスチームの方が投稿してくださって、いろいろと原因の追求にあたってご協力いただいたりとか、
そういったことを結構やっているような会社なので、かなり近しいところにいらっしゃるのかなと思っております。
なるほど。ありがとうございます。いい感じですね。今伺った感じだと、エンジニアたちがビジネス事業というか現場というところにすごい近い位置で仕事をしていて、
実際のお客様がどんな問題に直面しているのかとか、自分たちのプロジェクトを使って問題解決していたり困っていたりというところがあると思うんですが、
そういった情報もエンジニアたちがダイレクトに持つことによって、エンジニアたちの働き方というか、生産性だったり出せる成果というのも結果的に良くなるみたいな、
そういうふうに考えていらっしゃるということなのかなと思いました。現場取り分ということもカルチャーの中に入っていたりするので。
そういうところを結構推奨している会社さんというときに、エンジニアのほうの、またちょっとチームの話に戻ったりもするんですけれど、
例えばチームが分かれて自分たちのやっていることがちょっと小さなスコープになったりすると、ゆくゆくはそのチームの人たちの知識が、
そうなるかどうかは分からないんだけど、ちょっと閉じた小さな知識というところにだんだんと落ち着いていくんじゃないのかなというか、
それが一般的な流れかなと思うんですよね。認知負荷を下げるとかそういうことをやっていたらそうなると思うので。
そうなったときのチームって、現場のお客さんとかと話に行ったときに話がずれちゃったりだとか、そういうことが起こっちゃうんじゃないのかなということも思うわけですよ。
27:03
やっぱり神谷さんの場合そうじゃない、ちゃんとエンジニアがお客さんのことを理解できるとか、そういうことを大事にされている会社さんだと思うので、
チームを分けてコンテキストを小さくしていくみたいなことに対して、いろいろな取り組みももちろんされていると思うんですが、
その辺に関してもビジネス、会社のカルチャーを失わないようにするみたいなところで検討されていることとかあったりしますかね。
でも今、後藤さんのお話を聞いて、そういえばチームを分けた後の現場に行ったときのお客様の反応って、
私自身あんまり考えきれてないかなっていうのはすごい今感じました、素直に。
なのでおっしゃる通りシステムも分かれ、チームも分かれると、お客様からするとそんな都合は多分知らないわけで、
この機能に関してエンジニアの人にもし聞いたらいろいろ解決してくれそう、分かりそうみたいな期待値があるはずなのに、
来た方が多分違う機能を担当しているエンジニアとかだったら、しかも話が通じなかったら多分ガッカリさせてしまうリスクが正直あるのかなと思うので。
チームは分かれど、一通りの機能をエンジニアもある程度理解している状況というのは、
仕組みで達成できるようにするっていうのも一つの視点として持たなきゃいけないなというのは改めて感じたので、
そこは検討材料に加えていきたいなと思っております。
せっかくこれまですごくうまく現場ドリブンというカルチャーを使いながら、
お客様からの信頼を勝ち得てきた会社さんだと思うので、
それをうまくこれからも維持できるような設計というのがいろんな面で必要なんだろうなというふうに思ったりもするので、
もちろんそういうことは考えていらっしゃると思うんだけど、
エンジニアリングマネージャーとしてもそういうところにも意識を持つと、
よりうまくいきやすいんだろうなというふうに思ったりします。
最後のお話が個人的には一番貴重な話だなと思って、
上梨のカルチャーをエンジニアリング側としても維持といいますか、発展させていくために、
そういった目線が検討材料の中に不足していたので、
今後に活かしていきたいと思います。ありがとうございます。
宮本さん、今回もありがとうございました。
宮本さんからこの2回にわたっていろいろお話しさせていただいたんですけれども、
ご感想などあれば一言伺えるでしょうか。
貴重な初回ゲストに呼んでいただいて非常にありがたいなと思っております。
2回にわたって小藤さんとお話しさせていただいて、
考えていたりすることとか、意思決定慎重になっているところが、
30:01
客観的な目線で見ても動き方として特にネガティブな要素があるのかとか、
そもそも慎重になりすぎていないかとか、そういったところがないっていうのを
伺えたのはよかったなと思っておりますし、2回目の最後のほうでチームが分かれた後、
分かれたチームで雷のカルチャー、バリューを維持できるような仕組みなどを考えてますかっていう
すごいクリティカルな質問をいただけたので、そこを今後の検討材料として生かせるっていう
具体的な収穫というと失礼ですけど、そういったお話もいただけたので、
非常に貴重な機会だったなと思っております。
お呼びいただいて誠にありがとうございました。
ありがとうございました。宮本さんまたお待ちしております。
今回宮本さんとのお話2回目ということで、エンジニアリングのところと、
それからビジネスというところを少し伺いました。
前回からも通じて私が感じたことなんですけれども、スタートアップで成長しているフェーズ
っていうところでなんですけれども、結構先を見据えた組織の分割というか、
いうところの打ち手を検討していらっしゃったり、
でもそのソフトウェアの部分、非常に難しい問題もあるんですけれども、
トレンドに乗ってとりあえずマイクロサービスにしようとか、
そういうこともされておらず、慎重に他で得られた知見などを活かしながら、
組織の中できちんと意思決定をしようとされているというので、
宮本さんだけに限らず、上梨さんというところがいいカルチャーを育んでいらっしゃるんだな
というところもすごく感じるところがありましたので、
私自身に限らず、聞いていらっしゃる方にもいろいろ参考になったんじゃないかなと思います。
前回のエピソードを聞きたい方は、組織についてお話しした第1回のところもぜひお聞きください。
さて、この番組では感想や質問、リクエストなどをお待ちしております。
番組詳細欄にあるリンクよりお気軽にご投稿ください。
TwitterではハッシュタグEM問題集をつけてツイートしてください。
EMはアルファベット、問題集は漢字でお願いします。
そしてApple PodcastやSpotifyのPodcastではレビューも投稿できますので、
こちらにも感想を書いてもらえると嬉しいです。
お相手は株式会社カブクスタイル、COO兼CTOの後藤秀典でした。
