「IVRyのエンジニアリング最前線」── プリンシパルエンジニアとCEOが語る技術・組織・未来【ウェビナーレポート】
IVRy公式noteをご覧の皆様、こんにちは。
先日IVRyでは、CEO奥西とプリンシパルエンジニア成田が登壇し、『IVRyのPrincipal Engineerって何してる？IVRyのエンジニアってこんなに面白い』をテーマに、オンラインウェビナーを開催しました。
奥西と成田の対談では、下記のようなトピックについて語りました。
急成長するIVRyで、プリンシパルエンジニアはどんな役割を担うのか？
データ基盤整備の取り組みからLLM Opsの課題
今は必要なさそうに見えても未来に備えて作る、オーバーエンジニアリングの大切さについて など
優秀な仲間に仕事を譲る「良い意味での失職」を喜び、チームの成長を感じる瞬間や、「電話は繋がって当たり前」という緊張感の中で挑戦を続けるエンジニアの姿。このnoteでは、IVRyならではの技術的挑戦と、そこで働くメンバーの熱量をお届けします。
登壇者
奥西亮賀／株式会社IVRy CEO
成田 一生／株式会社IVRy Principal Engineer
「会社全体に影響を与えるプリンシパルエンジニア」── 技術と意思決定の最前線
成田：
プリンシパルエンジニアの定義は会社によって異なりますが、私は「一人のエンジニアとして技術でコミットしながらも、経営に対して意見を提言したり、会社全体に影響を与えるような存在」だと理解しています。エンジニアリングだけでなく、会社の意思決定にも関わっています。
奥西：
成田さんが「プリンシパルエンジニアは、こういう役割なんだな」と明確に思ったのはいつ頃でしたか？
というのも、プロダクトの構想などを議論している中で、成田さんにはIVRyのエンジニアリングや組織において、この辺が技術的な大事なポイントになるだろうなっていうのを結構先回りして予想して、採用活動や組織デザイン、技術的な検証など、いろいろと提案してくれている印象を持っていました。
成田：
そうですね。最初は「一人のエンジニアとしてやらせてください」という話だったのですが、前職でCTOをやっていた経験から、自分が直近で一番価値を出せる部分は、エンジニア組織全体のことや経営に関わることなのかなと思っています。
下手すると、自分がコードをちまちま書くよりも、他の人よりできる部分があるんだろうなという自覚があって、それを封印して入社したんです。でも、完全に封印すると、僕がいても、いまいち手が動かないロートルみたいになっちゃうかなと思って。だから最初は、その価値を出せるところも含めて、仕事したいなという気持ちでやっていました。
やっていくうちに、やっぱり性分として、こう見えてるものはもっとこうしたいなとか、会社もっとこうしたいんだと解像度が上がっていくにしたがって、こうしたい気持ちっていうのはどんどん強くなってきて。で、その機会があるたびに、何か「もっとこうしましょうよ」とか、「こういうふうにしたいですね」っていうのをどんどん言わせていただいてるっていう感じですね。
「自分の役割を奪う仲間を増やせ」── プリンシパルエンジニアが語る成長戦略と組織の未来
成田：
最近やっているのは、データ基盤の整備ですね。最初は何をしようかも全然決めずに入社していたんですけど、社内を見回したときに、データのパイプライン、つまり本番サービスのデータを分析のための基盤の仕組みが、結構レガシー化していて、なかなか手を加えられない状態になっていたんです。
そこから着手した背景は、IVRyが今後成長していくときに、そこがネックになるだろうなと感じたからです。やっぱりIVRyはデータの活用が会社のコアになってくるはずだから、今のうちからデータの基盤を拡充させていくことが重要だと思ったんです。プロダクトは結構ちゃんとしている部分が多かったんだけど、成長に全然追いついてない部分がいくつかあって、その一つがデータ基盤というトピックでした。
奥西：
確かに、成田さんは入社して1週間ぐらいで、「データ基盤を整えた方がいい」と言っていましたね。最近IVRyのことを考えると、よくスタートアップって崖の上からから飛び降りながら、飛行機をつくるようなものだって言われますけど、IVRyの場合は、飛行機を組み立てながら飛ばしていて、宇宙船に変わろうとしているような状態だなと思っていて。目の前の飛ぶ活動ではない機能（ファンクション）に取り組みつつ、中期で飛ぶために何に取り組むべきかを検証しているような、それを両立させることが経営として大事だと思っていることですね。
成田：
中長期のことを考える仕事を長くしてきたからか、私はどちらかというと短期よりも、中長期な課題を解決することに得意なんですよね。一方でIVRyは短期的な課題の解決が得意な人が多いので、他のメンバーにそこをお任せできるおかげで、私は中長期的な領域に集中できてますね。会社としてバランスが取れてると感じています。
奥西：
「プリンシパルエンジニア以外に職位を新設する予定はありますか？」という質問がウェビナーに参加された方から届いていますね。
成田：
一般的には、スタッフエンジニア、プリンシパルエンジニア、ディスティングイッシュトエンジニアという職位がありますが、IVRyでまだ議論にはなっていないですね。
奥西：
他にもそういった職位はあっても良いよねとは思っています。もしその時点で「IVRyで一番できるエンジニア」になったとしても、それより上のグレードがあるべきで、常に上を目指していかないと、会社としてもレベルが上がらないし、もっというと自分達自身が面白くなくなっちゃうと思うんですよね。成長することって面白いことだと思っているので、プリンシパルエンジニア以外の職位を定義していくのは全然アリだと思っています。
奥西：
他にいただいている質問だと、最近、働いていて楽しいと思った瞬間はどんな時ですか？技術的なことでも、組織的なことでも、メンバーとの日常的なことでも、何でも構わないです。
成田：
結論、優秀な仲間に自分の役割をお任せする瞬間に感じます。元々前職でもインフラ周りを中心に携わっていたこともあり、IVRy入社後もインフラ半分・データ基盤半分を担当していたのですが、直近半年で優秀なSREの方にご入社いただいたおかげで、インフラ領域をまるっとお任せしてデータ基盤に集中できるようになりました。いい意味で僕の仕事がなくなっていく現象が何度も起きていることに感動しています。僕はこれを「失職」と表現しているのですが、失職が何回も起きるということは、会社が成長している証だと思いますし、面白くて良い環境だなと感じます。
奥西：
良いですね、僕も失職したいです（笑）エンジニアリングチームだけでなく、プロダクトサイド全体や、ビジネスサイドもみんなそれを目指しているところですよね。
「LLM Ops × 電話AI」── IVRyが挑むリアルタイム対話の最前線
成田：
今この瞬間、特に面白いと感じているのは、LLMを活用していることもあり、AIやデータ基盤の領域です。その次に来るであろう、まだ着手できていないけれど面白くなりそうな領域はいくつかあります。その中でも特に注目しているのが LLM Ops ですね。 IVRyの事業を抽象化すると、「お客様の会話データ（音声やテキストの非構造化データ）」がリアルタイムで流れ込み、それをLLMで処理し、リアルタイムに返すという流れになっています。このやり取りは、通話だけでなく、バッチ処理やストリーミングでの会話クラスタリングなど、多様な形態をとります。そのため、データの流れを支える技術、いわば "データの土管" を作ることが非常に重要になります。
LLM Ops についてですが、我々はAIにデータを投げて結果を返す仕組みを持っていますが、一口にLLMと言っても、さまざまなモデルがあり、日々進化しています。「今はこのモデルが良い」「いや、こっちの方が精度が良い」といった変化が常にあるわけです（笑）。また、モデルの安定性にも課題があり、突然パフォーマンスが低下することもあります。
SREの観点からは、あるLLMモデルの調子が悪くなったら、別のLLMに切り替えることでサービスの継続性を確保する必要があります。その際、多少プロンプトを調整する必要があるかもしれませんが、サービスを止めることなく運用できるのは大事です。また、LLMへのデータフローを安定させ、適切に切り替えながら運用する技術やワークフローの構築は、まだ確立されたベストプラクティスが存在せず、各社が模索している段階です。IVRyはこの領域で強みを持つ可能性があり、非常に面白い分野だと感じています。
さらに、IVRyは電話サービスを提供する会社であり、通信の品質を扱うビジネスでもあるため、セキュリティやプライバシーに関する技術を試せる土壌があります。たとえば、まだ実用化されていない秘密計算技術なども、IVRyであれば活かせる可能性があるわけです。この分野も非常に面白いと思います。
また、IVRyは現在 Twilio を利用して電話サービスを提供していますが、将来的に自社で電話インフラをホストすることも選択肢として考えられます。その最大の利点は コスト削減 です。電話料金はIVRyの事業の原価に直結するため、仕入れコストをどれだけ削減できるかがビジネスに大きく影響します。ただし、自社で電話インフラを運用するのは非常に大変な作業でもあるため、どのタイミングで踏み込むべきか慎重に見極める必要があります。とはいえ、非常に面白い挑戦になりそうです。
奥西：
電話という「リアルタイム対話をどう処理するか」が非常に重要なテーマになっています。これはSREやアプリケーションエンジニアにとっても大きな課題で、アーキテクチャ設計にこだわらないと遅延が発生しやすくなります。 例えば、並列で書き込まれているデータをすべて待ってから処理しようとすると、結果的に「レイテンシー（待ち時間）」が発生し、システム全体のパフォーマンスに大きな影響を与えます。この「待ち時間」をどう削減するか、特に 0.5秒をどう短縮するか は非常に重要な課題です。
また、IVRyのようなサービスでは データ量が多い非構造化データをいかに活用するか も大きなポイントになります。そのため、パイプラインの設計には非常にこだわりが求められます。最終的にアウトプットしたいタスクのレベルや成果を考慮しながら、どの情報をどこまで削るかを決める必要があります。 こうした データフロー（＝土管）の設計 には強いMOAT（参入障壁）が生まれやすいと感じています。そのため、今後IVRyが技術的にユニークなポジションを築いていくことで、「IVRy以外の選択肢は考えられないよね」という状態を目指していくフェーズに入っていると思います。エンジニアとしても、やりがいがあり、技術的なチャレンジが多い面白い領域だと感じています。
成田：
特に電話の通信品質については、日本国内で完結する仕組みを構築できれば、より良いユーザー体験を提供できるはずです。 現在、IVRyは Twilio を利用していますが、Twilioのデータセンターはアメリカにあり、日本国内にリージョンが存在しません。そのため、日本からTwilioを経由して通話をすると、 1往復で約360ミリ秒のレイテンシー が発生します。もし、国内の通信インフラで完結できれば、通話の待ち時間が短縮され、ユーザー体験も大幅に向上するでしょう。この領域は今後さらに深掘りし、改善していきたいと考えています。
「落ちない電話を目指して」── IVRyが挑むLLMと可用性の最前線
成田：
LLMって落ちるんですよ。IVRyでは電話システムにTwilioを使っていて、LLMにはOpenAIなどの外部サービスを利用しています。つまり、外部サービスに強く依存しながら一つの通話を成立させているんです。でも、どこかが壊れると通話ができなくなってしまう。外部システムの数が増えれば増えるほど、故障率が掛け算で上がる。だからこそ、どうやって可用性を担保するのかが技術的に面白いし、難しい部分でもあります。最近は複数のLLMをコールバックできる仕組みを取り入れて、調子が悪かったら自動で切り替えるようにしています。
ただ、Twilioに依存している以上、Twilioが調子悪い瞬間もある。その時は僕らにできることが限られてしまうんです。電話って、誰も落ちると思ってないですよね。災害の時でもつながるものだと思われている。SaaSなら障害事例について聞かれることもありますが、IVRyではほとんど聞かれません。電話は繋がって当たり前だから。だからこそ、すごい緊張感があるし、技術的にも面白い。SREの視点で見ると、どうやって安定性を上げるかが非常に興味深くて、トレードオフの中で開発のしやすさと可用性を両立させるのが難しい。ここがIVRyの技術的な特徴ですね。
奥西：
mirakuiさんが入ってきた頃は、僕もプロダクトチームにどっぷり入っていて、カナリアの構築検討を進めていました。例えば、最新のブランチが載っている環境と、安定した環境を分けて、お客さんのプランに応じて出し分けるみたいなアイデアを検討していましたね。
成田：
カナリアはやりたいんですよね。IVRyのコア部分、つまり自動応答システムに関わるコードにミスがあると、電話が繋がらなくなるリスクがある。だから、デプロイがすごく難しくて、常に緊張感があるんです。その影響範囲を閉じ込めながら、多くのお客さんには安定版を提供して、一方で新機能に興味のあるお客さんにはカナリア版を使ってもらう、といった方法も考えられます。カナリア版は安定性が若干下がるかもしれませんが、最新機能を試せる環境を用意する。そして、環境を分けることで、安定版を使うお客さんには影響を与えずに新機能のリリースがしやすくなる。絶対に落とせない環境には安定版を使う。複数の環境を用意して運用するのもありかなと思っています。
奥西：
それ……やりましょう！（笑） 少なくとも社内の電話環境なら実験的な取り組みも可能なはずです。そういう試みを積極的に進めていきたいですね。
実際、お客さんの中には「新しいことをどんどん試したいからIVRyを導入した」という方々も多いんですよね。つまり、お客さんの期待値としても「安定性重視」から「最新技術に挑戦したい」というグラデーションが存在している。そういうニーズに応えていくこと自体が価値のあることだと思っています。IVRyならではの技術的な挑戦を通じて、お客さんにとっても、僕たちにとっても、より面白く価値のあるものにしていきたいですね。
「今の最適化 vs. 未来の柔軟性」── クラウドコスト管理のリアル
奥西：
次のテーマは、インフラコストとお金で解決するバランスについてですね。
成田：
最近、AWSの費用を1年分先払いして割引を適用するReservedインスタンス（RI）の仕組みを活用していて、4月の更新に向けて見積もりをしていました。どこまで固定費化するかがポイントですね。細かくRIを購入すれば全体のコストを下げられるのですが、その分1年間は使い続ける必要があります。でも、1年後にIVRyのサービスがどうなっているか分からないじゃないですか。もしかしたら別のものをやっているかもしれないし、アーキテクチャが大きく変わっている可能性もある。
僕らのサービスは変化が早いので、今この瞬間に最適化することが必ずしも適切ではないと思っています。コストの面でも、アーキテクチャの面でも、今動いているものを最適化するよりも、将来の拡張性を考えて柔軟性を確保する方が価値がある。短期的には割高になってしまうこともありますが、それはお金で解決できる部分だと思うんですよね。最適化にリソースを費やすよりも、従量課金で時間を買う方が合理的なこともある。SREの視点でも、そういう意識を持って運用しています。
奥西：
今を最適化することがあまり意味をなさない場面も多いですよね。一方で、最低限のコスト管理はしておかないと、無駄な支出が膨らんでしまう。そこはバランスが大事ですね。
成田：
インフラコストを見るのは結構好きで、IVRyに入ってから『インフラコストを見る会』を立ち上げて、もう1年くらい続けています。毎月AWSなどのクラウドコストを分析して、どこが増えているのかを確認するんです。ほぼ趣味みたいなものですね（笑）。
奥西：
今では当たり前のようにコストをチェックする文化ができましたよね。mirakuiさんが入社する以前は僕が一人で「これ、突然コスト増えてるけど大丈夫？」って言って回ってました（笑）。BigQueryのコストがどんどん膨れ上がってしまって……すごい金額を使ってましたね（笑）。
成田：
入社して「IVRyってBigQuery使ってるんですね」と言って、コストを確認したら驚きました。この規模の会社でこんなに払ってるの？って（笑）。
データを活用しているのかと思いきや、実際には無茶なクエリが飛び交っていて、全社員が見るKPIダッシュボードでめちゃくちゃ重いジョインが走っていたんですよ。数千万件×数千万件のジョインが発生して、誰かがその画面を開くたびに数千円がチャリンと消えていくような状態でした（笑）。それを少しずつチューニングして、コスト削減を進めましたね。
奥西：
懐かしいですね（笑）。しかも、削減したコストが結構大きかったので、「mirakuiさん、これちょっと課金してもいいですか？」と聞くと、「減額分を考えたらペイできるし、やった方がいいんじゃない？」って。稟議がすごくスムーズになりました（笑）。
成田：
コストを抑えた分、新しいシステムを導入できるようになりましたね（笑）。
「未来を見据えたオーバーエンジニアリング」── IVRyが挑む長期視点の技術設計
成田：
オーバーエンジニアリングって、エンジニアの間では悪いことのように扱われがちですよね。趣味に走って必要以上に凝ったものを作る、みたいな。
でも僕はIVRyにオーバーエンジニアリングを持ち込みたいと思ってるんです。どういうことかというと、IVRyはすごく成長していて、1年後にはさらに成長しているのが明らかです。そうなると、今のために作った基盤は1年後には足りなくなってしまう。だからこそ、今この瞬間ではそこまで必要ないものでも、準備しておかないと成長に追いつけなくなるんです。「今はそこまでのスペックは必要ないよね」と言って準備を怠るのではなく、自分たちの成長を信じて、しっかり作り込んでいく。この考え方をもっと浸透させたいと思っています。
特に基盤部分は長期間使うものなので、簡単にリプレイスできません。だからこそ、長期的に見てやや過剰な作り込みが、最適になると考えています。難しい技術を使って作ることは、エンジニアにとっても面白いですし、採用面でも強みになる。必要最低限のものを安く作るより、強くてかっこいいものを作る方が楽しいし、長期的に見ても合理的ですよね。その一つがデータ基盤だと思っています。これに共感してくれる人たちと一緒に、盛り上げていきたいです。
奥西：
例えばアカウントの構造や請求単位の構造って、後から変えるのが大変なんですよね。でもIVRyの事業モデルを考えると、スモールビジネスから始めて、エンタープライズに展開する。そうなると、本部と支店、従業員アカウントといった概念が出てくる。この段階で、オーバーエンジニアリングも含めて最初から要件を考えておかないと、後で直すのが大変すぎるんです。
請求単位も同じで、プランと機能を紐付けてしまうと、後で変更が難しくなる。でもビジネスジャッジ的には「やりたい！」となる可能性が高い。短期的には何も影響しないけど、2、3年後に「これ作ったやつ天才じゃん！」って言われる機能になるかもしれない。
こういう視点で設計を進めると、未来を見据えた会社になるし、そのためにはエンジニアが事業の方向性を深く理解することが大事ですね。
成田：
実はIVRyの既存システムにも、「未来を見据えて作られたんだな」と思う設計があるんですよ。例えば、自動化ルールの設定画面と電話システムが完全に分離されている。どちらかが落ちても、もう一方が動くようになっているんです。これがめちゃくちゃ賢い。設定画面はRDBで作られていて、設定が完了するとDynamoDBに転記される。電話のトラフィックが大量に発生するため、通話中にRDBへアクセスしない仕組みになっている。可用性の要件が全然違うからこそ、わざわざDBを分けているんですよね。
普通に考えたら、システムを1つにまとめた方が楽。でも、分離したおかげでIVRyは今でも安定して動いている。この設計を最初に考えたエンジニア、町田さんは本当に天才だと思っています。
奥西：
こういう歴史を振り返ると、最初から「楽しいレベルでアーキテクチャを考えよう」と話していたことを思い出しますね。実は、過去にリクルートで密結合によるシステム障害を経験していて、「サービスレベルが違うものを依存させるのは危険だ」と学びました。その教訓があったからこそ、最初にレビューしたときに「分離したほうがいい」と考えたんです。
成田：
大規模な環境を経験していると、そういう視点が自然と身につくんですね。
奥西：
まさにそうですね。特に1990年から2000年代にかけて急速にインターネット化が進んだ際、多くの企業が時間の制約の中で、アーキテクチャを十分に考慮せずにシステムを構築してきた歴史があります。その過程から多くの教訓が得られていますね。今回は他社の話だったので、また改めてお話しできればと思います（笑）
「RubyKaigiで実感したIVRyの強さ」── 技術と文化が生み出す自然なアトラクト力
奥西：
QAセッションですね。質問が結構あるので、全部は回収しきれないかもしれませんが、できるだけみんなにとって共通性がありそうなものをピックアップしていきます。まず、クックパッドからIVRyに転職して、働き方や視点に大きな変化はありましたか？
成田：
驚かされることがすごく多いですね。カルチャーや人柄に関してもそうですし。最初に驚いたのは、エンジニアのみんながすごく素直なこと。
「こういうふうにしませんか？」と声をかけると、「いいね、それでやろう！」って、疑ったり斜に構えたりすることなく、すっと受け入れて進めてくれる。そういう柔軟さや、人の意見を尊重する文化がある会社だなと思いました。前職は我が強い人が多かったので、その違いには衝撃を受けましたね。「え、人の話をちゃんと聞くんだ！」って（笑）。あと、やっぱりみんな人柄がいいというか、明るいですね。前向きな雰囲気がある。
去年のRubyKaigiでIVRyのブースを出して、エンジニアのみんなでいったんですが、事前に「こういうふうに会社を説明してください」とか細かい指示は一切せず、単に「何時から何時まで担当してください」とタイムテーブルを決めただけだったんです。でも、みんな自然に会社の魅力を語ったり、アトラクトをしたり、デモをしたりしていた。その姿を見て、「すごいな、人間力の高さだな」と感動しました。
奥西：
IVRyは毎月1回「OpenDay」という、会社外の人がたくさん来るイベントをやっていて、そこで知らない人と話す機会が多いんですよね。そういう場を通じて、自然とIVRyについて説明できる人が増えていくし、コミュニケーション能力も鍛えられているのかなと感じます。
成田：
それはすごく感じますね。「初めまして」と自然に話せる力がみんな高いなと。すごいことだと思います。
奥西：
最初にOpenDayを始めたときは、みんなあまり積極的に話せなかった記憶があるので、今は自然とできるようになってきたんだなと。やっぱり継続的なトレーニングが大事ですね（笑）。
「IVRyへのジョインはプレミアムチケット」── 未来を変える挑戦の最前線へ
成田：
エンジニアリングにおける課題としては、今、プロダクトのステージが変わりつつあることですね。これまでは電話の自動応答システムを中心にやってきましたが、今後は蓄積された電話の通話データを活用し、ビジネスコミュニケーションのデータを基にした新しいプロダクトを作ろうと考えています。でも、こういった難しいプロダクトを作った経験のあるエンジニアが社内にまだ少ない。データを大量に扱うことや、それをうまくユーザーに見せることができる人がもっと必要だなと。
今はまさに会社のプロダクトのステージが変わるタイミングで、その変化に対応できる人材がまだ足りていないというのが、今の大きな課題ですね。なので、採用は引き続き頑張っています。
奥西：
逆に、エンジニア視点でIVRyで働く魅力を伝えてもらえますか？
成田：
今のIVRyにジョインできることは、ある意味「プレミアムチケット」だと思っていて、正直あまり安売りしたくないなって思ってるんです（笑）。
今作っているものが、これからIVRyの未来を大きく変えるものになる。その瞬間に立ち会えるのは、日本のどの会社を見渡しても、そうそうない貴重な機会だと思います。だからこそ、ベストな人と一緒に働きたい。
エンジニアとしても、いい意味での「焦り」があります。うちの会社のビジネスチームやPdMには優秀な人が多くて、エンジニアリングとしてもそれに応えないといけない。もしエンジニアリングがボトルネックになって会社の成長が遅くなるなんて、めちゃくちゃ悔しいじゃないですか。だから、エンジニアも「こんなの作っちゃいましたよ！」って、ビジネスサイドの期待を超えていくような状態を作りたいし、そういう緊張感がすごく楽しいんです。
我々って普通の仕事としてやっちゃダメだと思うんですよね。スタートアップだからこそ、今の頑張りが将来の成長の上限を引き上げる。9時5時で言われた仕事をこなしているだけの人が増えたら、間違いなくダメになる。だからこそ、密度を上げて、工夫を凝らして、トライアンドエラーを繰り返しながら、やっと一つの答えをひねり出すような、そんな感覚で仕事をしたいんです。
奥西：
エンジニアリングって、イーロン・マスクがロケットを打ち上げたときに、全員が感動していたあの映像みたいなものだと思うんです。
IVRyが作るプロダクトも、今はまだ世の中にないけど、もし実現できたら社会が大きく変わるかもしれない。そういう信じられるものを形にしていくのが、今のフェーズなんだと思っています。それを、みんなで試行錯誤しながらより良いものにしていって、最終的に「やったぞ！」って全員で感動できる。そのモメンタムを持ってエンジニアリングできるチームであり続けたいし、そういう環境を作っていきたいですね。
「IVRyの未来を一緒に創る仲間へ」── 思いを持つあなたと働きたい
奥西：
まだまだ人が足りていないので、仲間が増えると嬉しいです。エンジニアだけでなく、他のポジションも募集中なので、少しでも興味がある人は、ぜひカジュアル面談で話しましょう！
技術力ももちろん大事ですが、それ以上に「思い」と「熱量」を持っている人と一緒に働きたいので、気軽に声をかけてもらえると嬉しいです！
IVRyでは、一緒に成長していく仲間を全方位で絶賛募集中です。
ご興味をもってくださった方は、ぜひ気軽にご連絡ください。
お待ちしています！
