電話は、繋がって当たり前。渡部が挑む、答えのない信頼性 ── Tech and Me #10
電話は、繋がって当たり前。他のサービスは落ちても許されるというよりは、電話はそのドメインの特性から非常に高い可用性が求められます。その瞬間に音声が途切れたり、転送に失敗したりすれば、それはもう体験の崩壊です。
今回登場するのは、IVRyでSREのTech Leadを務める渡部 龍一（@ryuichi_1208）さんです。Linux向けファイルシステムの開発からキャリアを始め、Web、そしてSRE(Site Reliability Engineering=サービスの信頼性をエンジニアリングで高める領域)へ。一貫して信頼性と向き合ってきた渡部さんは、IVRyで対話AIという前例の少ない領域に取り組んでいます。
「答えのない場所にこそ、面白い仕事がある」
その言葉の背景を辿ると、IVRyでSREをやる面白さと、その難しさの正体が見えてきます。
本シリーズ「Tech and Me」では、IVRyのエンジニアが“技術との向き合い方”を通して、自分やチーム、そしてIVRyという組織をどう前進させているのかを語ります。日々の意思決定や価値観、挑戦の裏側を通して、IVRyの技術文化を紐解きます。
渡部 龍一/ SRE Tech Lead（@ryuichi_1208）
2016年からソフトウェアエンジニアとしてのキャリアを開始。キャリア初期はLinux向けファイルシステムの開発に携わり、クォータ機能の実装を担当。その後、インフラ/バックエンドエンジニアとして、WebニュースサイトやEC作成支援サービスの開発・運用を経験し、SREとしての活動を本格化させる。現在はIVRyのSRE Tech Leadとして、共通基盤・監視基盤の整備と、対話AIプラットフォームへの参画(Embedded SRE)という二つのプロジェクトを担う。SREや障害対応をテーマにした書籍「SREの知識地図」の共著者。SRE NEXTでは2024年から2025年にかけてCo-Chairを務め、地域コミュニティ「Tamachi.sre」の主催も行うなど、SREを広める活動にも携わる。
ファイルシステム開発から、信頼性の世界へ
── まず、これまでのキャリアについて教えてください。
2016年からソフトウェアエンジニアをやっています。キャリアの最初は、Linux向けのファイルシステムの開発でした。クォータ機能の実装を担当していて、Webでもなく、本当にLinux自体をいじる人、という感じです。世の中にはあまりいないタイプかもしれません。
その後、インフラやバックエンドのエンジニアへと移っていきました。Webニュースサイトの運用や、EC作成支援サービスの開発・運用に携わる中で、SREとしての活動を本格化。信頼性や運用性を意識した設計・改善、障害対応、EOL対応といった、サービスの継続性を支える領域に、強い関心を持つようになりました。
── そもそも、エンジニアを目指したきっかけは。
学生の頃から、そういうものが好きだったというのが一番大きいです。むしろ、それ以外の仕事がないんじゃないかと思いながら就活をしていました。
きっかけをたどると、親がプログラマーで、パソコンが早い時期から家にあったんです。それで「あれを使う仕事がしたい」と思い始めたのが、たぶん小学生くらいの頃でした。コードを書いていたわけではなくて、ガジェットで遊ぶのが好きだった、という感覚に近いですね。
── SREに興味を持ったのは、どんな理由からですか。
過去携わっていたシステムがバグが多くて障害も起きやすいシステムだったんです。それを一つずつ直していく仕事をしているうちに、思いのほか楽しくなっていったのが入り口でした。
実務で得た知見を整理して、再現可能な形で共有する活動も続けています。書籍「SREの知識地図」の共著として執筆に参加したり、SRE NEXTの運営やTamachi.sreという地域コミュニティの主催をやったりしています。SRE NEXTでは、2024年から2025年にかけてCo-Chairを務めました。SREの実践知や信頼性エンジニアリングの価値が、より多くの現場に広がるといいなと思って活動しています。
期待値が最初から高いプロダクトに、加わる楽しさ
── IVRyに入社したきっかけを教えてください。
最初に知ったのは、SRE NEXTのジョブボードでした。「IVR」という文字を見かけて、「電話のSREって面白そうだ」と思ったんです。1週間後くらいにカジュアル面談をお願いして、業務内容やチームの姿勢を知る中で、一気に興味が深まっていきました。
特に共感したのは、電話を扱うサービスという特性上、信頼性やパフォーマンスといったサービスレベルが極めて重要になる点です。面談では「SREがIVRyにどう価値を提供できるか」というテーマで、今後の取り組みを具体的に伺いました。
── 最終的な決め手は何だったのでしょう。
応答時間や通話成功率といった具体的な指標を定義して、それを維持・向上させていく。その話が、すごく印象的だったんです。まさに「これから始まる」というフェーズで、このタイミングで自分が加われば、最初からこのプロセスを一緒に作り上げていける。その楽しさを確信したのが大きかったですね。
世の中の多くのサービスは、サーバーが少しくらい落ちることを想定していることもあります。でも電話は、ほんの少しもシステムを落とすことができない。最初からユーザーの期待値がめちゃめちゃ高いシステムなら、そこに挑む価値がある。その「許されない環境」が、むしろ面白いなと思いました。
── 落ちてはいけないプロダクトには、プレッシャーも伴うと思います。そこはどう受け止めていましたか。
むしろ、そこに自分の強みがあるだろうと思っていました。どうやったら落ちないかを考えると、技術的にいろいろ知っていかないといけない。緊張というより、技術的な挑戦として楽しそうだな、というくらいの感覚でしたね。
── 入社前と入社後で、ギャップはありましたか。
それはほとんどなかったです。ポジション自体を自分で作って、自分で進めていく立場だったので、ギャップが生まれにくかったんだと思います。
強いて挙げるなら、思っていたより発信する人が多いな、という驚きはありました。そこは良い意味での驚きでしたね。
外から言うのをやめてプロダクトに入り込んだ
── 現在は、IVRyでどんな役割を担っていますか。
SRE Tech Leadとして、二つのプロジェクトを担当しています。
一つは、共通基盤や監視基盤の整備です。全社で使う基盤をどう整えていくか、障害対応をどういうフローで進めるか、といった組織横断のテーマを扱います。
もう一つは、AI対話のプロダクトチームに入り込んで信頼性を設計する、Embedded SREとしての活動です。「AIを活用した音声対話システムにおいて、何をもって信頼性が高いと言えるのか」。いま、この問いに向き合っています。
── なぜ、外から関わるのではなく、中に入り込む道を選んだのでしょう。
最初は、外から進めようとしていた時期もあったんです。でも、数ヶ月やってみてうまくいかなかった。対話AIシステムが、それほどまでに難しい対象だったんです。
音声認識やLLM、音声合成といった外部サービスがリアルタイムに連携するので、従来のWebのような単純なメトリクスでは測れない。ドメイン知識がない状態で外から言えることって、教科書的な話に留まってしまうんです。それが刺さるとは限らない。刺さるものは、結構ドメイン知識が必要なものだと分かってきた。だから、入り込んで具体的な知識を得た上で改善していく方針に切り替えました。
── 中に入って、変わったことは。
二つあります。一つは、システムが異常になったときに、その状況をどれだけ把握できるか。その見通しが格段に良くなりました。もう一つは、「信頼性が高い」とは何かを、ちゃんと言語化できるようになったこと。これは、入り込んだおかげかなと思っています。
── 全社最適と個別のプロダクト、二つの視点を行き来する難しさはありませんか。
あまり頭の切り替えはしていなくて、全社最適で考えたものを、個別のプロダクトに落とし込む、という順番でやっているんです。
いま入り込んでいるプロダクトでは、すでにチームからある程度の信頼を得られています。だから、実験的に何かしたいというのも受け入れられるようになってきた。むしろ、そのほうがやりやすいなと感じながらやっています。
会話が成り立っているかを信頼性にする難しさ
── これまでで、特に難しかった技術的な意思決定について教えてください。
対話AIシステムにおける、SLI/SLO(SLI=サービスの状態を測る指標、SLO=その目標値)の設計と合意形成ですね。これは難しかったです。いわゆるWebシステムとは考え方が全然違うものを、ゼロからどうやって指標にするのか。そこは技術的にかなり難しかった。
入り込んだからといって分かるものばかりではなくて、分からないことが大量にある。AI対話向けの書籍を読み込んだ上で、やっと少し分かってきた、というレベルでした。今まではある程度調べれば分かったものが、ここだけは違う世界だったな、と改めて感じました。
── 具体的には、どのあたりが難しいのでしょう。
システム的には正常、つまりステータスは200で返っていても、応答が遅ければ、会話としては破綻しているんです。逆に、一部でエラーが起きても、フォールバック機能でユーザーが目的を達成できていれば、問題ないケースもある。
たとえば、年齢を聞かれて名前を返す。システム上は応答できているので、成功に見えます。でも、会話としては成り立っていませんよね。普通のWebシステムでは絶対に起こらないことで、そこが難しかったですね。
── その難しさに、どうアプローチしたのですか。
コンポーネント単体の可用性を追うのを、やめたんです。代わりに、主要なユーザージャーニー、CUJ(Critical User Journey)を定義して、そこから逆算して指標を設計していきました。ユーザーが目的を達成できたか、自然な対話ができたか。システムの正常性ではなく、その観点からSLI/SLOや可観測性を再定義した、という感じです。
── 一番の学びは何でしたか。
難しかったのは、技術的な実装ではなかったんです。「組織として何を品質と呼ぶか」の合意形成。そこが一番難しかった。PdMやアプリケーションエンジニアと泥臭く議論を重ねて、「私たちは何を守りたいのか」を言語化する。その重要性を、強く実感しました。
技術的にはなんとかなる一方で、何を守りたいのかを言語化して、チームとして、組織として運用していくには、気持ちの部分が欠かせない。そこが難しさでもあり、面白いポイントでもあるのかなと思います。
やり直せない電話だから、成果が事業価値になる
── IVRyで働くSREの魅力を、どう捉えていますか。
二つあると思っています。一つは、信頼性がプロダクトの価値、つまりユーザー体験に直結していること。
Webページのように、リロードしてやり直すことができないのが電話の世界です。音声の途切れや転送の失敗は、その瞬間に体験の崩壊を意味する。だからこそ、SREの成果がそのまま事業価値になるんです。月に1,000万回のリクエストがあるとして、1万回くらいなら失敗してもいい、という世界と、1,000回しか失敗してはいけない、という世界では、技術的な面白さが全然違う。そこに組織として投資する価値があると、経営の側でも認識されている。そこまで信頼性が重視されるサービスは、そう多くないと思います。
もう一つは、AIとSREの掛け合わせという、まだ正解のない領域に挑戦できることです。複数のAIコンポーネントが絡むシステムの信頼性について、業界全体にベストプラクティスがまだない。障害が起きてから対応する人ではなく、Embedded SREとして新機能の設計段階から入り込んで、障害が起きにくい仕組みを一緒に作れる。そこが面白いポイントですね。
── AIが主軸にあるかどうかで、SREの難しさはどう変わるのでしょう。
AIがサブ機能なら、ある程度落ちていても許容できるんです。たとえばLLMは、それなりの頻度でエラーになります。それを許容できるサービスが、世の中のほとんどなんですね。
でも、対話AIでそれを許容してしまうと、そのたびに電話が切れてしまう。もはや使い物になりません。だから、エラーになっても使い物になるようにシステムを組む。そういうことをやっている人は、他にあまりいないはずで、そこが面白いところです。
── 落ちないようにする、というだけではないんですね。
どちらも大事なんですが、落ちても会話を継続させるほうは特に重要です。支えるサービスが落ちていても、最低限、会話自体は継続させる。そのための判断を常にしていくのが面白いポイントですね。
たとえば、AIが応答に使うサービスが失敗しても、うまくいくような仕組みを用意しておく。音声合成に使うAPIについても、同じようにフォールバックを用意しておく。落ちないようにするだけでなく、落ちても会話が止まらない仕組みを設計する。そこに、まだ誰も正解を持っていない領域の手応えがあります。
全人類が同時に電話をかけても、耐えられるか
── 今後、どんなチャレンジをしていきたいですか。
技術と組織、二つの方向があります。
技術的には、去年からチームの理念に掲げているフレーズがあって。「全人類が同時に電話をかけてきても耐えられるサービス」。これを実現したいんです。
電話網、音声認識、LLM、音声合成など、多数の外部システムと連携する中で、障害を前提とした設計、Design for Failureを進めていく。自動切り替えや自動復旧によって、極限のレジリエンスを実現したい。もちろん、現実には電話線が足りないので、文字通りには難しい。でも、極限までどこまでできるのか。それを突き詰めること自体が、技術的な挑戦だなと思っています。
── もう一つの、組織的なチャレンジとは。
信頼性を、SREチームだけの責任にしないこと。プロダクトチーム全体が、開発プロセスの中で自然に信頼性を設計・考慮できる文化を作りたいんです。
実は、すでに嬉しい兆しがあって。地道に開発チームに入り込んでいった結果、いまはSRE以外のメンバーからも、信頼性について前向きに触れてくれることが増えてきました。IVRyのエンジニアは、もともとプロダクトやユーザーに対する気持ちがすごく強いんです。だからこそ、「ユーザーのためにより良いものを」という想いの延長線上に、信頼性を大切にする意識が自然と芽生えつつあるのかなと感じています。
全員で信頼性に向き合える。そういう会社になっていくと、本当に強いよなとずっと思っているので、この文化をさらに確固たるものにしていくのは、チャレンジしがいがあるなと思っています。
── どうすれば、誰もが信頼性を考えられるようになるのでしょう。
一つは、テンプレートの整備です。「このサービスはどれくらいまでエラーを許容するか」を定めたテンプレートを用意して、それをもとに設計していくと、信頼性を前提としたサービスになっていく。それをみんなが当たり前に使うものにしていく、という考え方です。
もう一つは、AIの活用ですね。最近はAIが、信頼性を考慮した上で実装したり、設計に反映したりするようになってきました。考慮が漏れていないかをAIがレビューする、というやり方もあると思っています。IVRyには、信頼性が高い設計になっているかをレビューするAIが、すでに存在するんです。
── AIがレビューを担うと、何が変わりますか。
開発者は本当に機能そのものに集中できて、信頼性のチェックはAIが補う。そういう世界に近づいてきていると、ここ数ヶ月見ているだけでも思います。
以前は一人ひとりに言って回らないといけなかったことを、いまはAIがコードレビューの中で指摘してくれる。SREがいなくても回るような世界になっていくかもしれません。
── それは、SREが不要になるということでしょうか。
そうではないんです。全員が当たり前に信頼性を考えてくれるようになれば、SREは他にやるべきことに集中できる。たとえば、インフラの構成から変えていくような作業ですね。そこに集中できたほうが、全社的には良いよね、ということです。
技術は手段で目的は課題解決。大切にする四つの軸
── キャリアや技術に向き合う上で、大切にしている価値観を教えてください。
四つあります。
一つ目は、技術は手段であって、目的は課題解決だ、ということ。新卒くらいの頃に、先輩から言われた言葉です。最新技術を学ぶこと自体は好きなんですが、それ以上に、その技術を使って、誰のどんな困りごとを解決できるか。そこを最優先に考える、というのは今も思っているところです。
── 二つ目は。
キャリアを重ねても、現場で手を動かし続けること。自分でコードを書いて、障害対応をして、システムを観察する。そこから見えてくる本質的な課題があるんです。手を動かさないと、教科書的な内容しか分からない気がするので、そこは大事にしたいですね。
── 三つ目は、仕組みで解決すること、と伺いました。
そうですね。個人の努力や頑張りで乗り切るのではなく、自動化や可観測性、SLI/SLOといった、組織全体が継続的に改善できる仕組みへと落とし込んでいく。これはSREを学ぶ過程で大切にするようになった考え方です。今では、手動でやる前にもう自動化されている、という状態が当たり前になっていて、仕組み化を意識すること自体が少なくなっているくらいですね。
── 四つ目が、本質を見極める力。
AIによって、開発スピードが爆速化して、システムがどんどん複雑になっていく時代です。だからこそ、何が本当に重要な問題なのか、それを意思決定する力がすごく重要になる。いらないものが大量に生成されてしまうので、なおさらですね。
── 本質を見極めるために、意識していることはありますか。
これを解かなかったらどうなるか、を考えるのかもしれません。この課題を解くことで何が嬉しいのか。一方で、何かを作れば、システムはその分だけ複雑になる。そのトレードオフを常に意識している気がします。
── その見極めの力は、どう身につくのでしょう。
結局、手を動かしてやってみた上で分かる世界なんじゃないかと思います。一度やったからこそ、これは複雑になるだけで意味がないな、と感覚で分かるようになる。なぜそうなのか、と一段上のレイヤーから見るためにも、一度通ったことがあるかどうかは重要な気がします。
── 新しい技術への向き合い方にも、この価値観が表れていそうです。
最新だから使う、ということはあまりないですね。最適な答えが古い技術ならそちらを選ぶし、最新が最適ならそちらを選ぶ。見えている範囲で、最適なものを選んでいる感覚です。普段から本を読むのが好きなので、「これは使えそうだ」というものを引き出しに貯めておく。それをやっていたりします。
枠を越えて、信頼性に踏み込める人と
── いま、IVRyが求めるSREはどんな人ですか。
信頼性の課題解決が好きな人ですね。インフラや運用の枠に閉じこもらず、必要ならアプリケーションやアーキテクチャにも踏み込んでいける人。そういう人がいると、一緒に働いていて楽しいだろうなと思います。
もう一つは、全社を巻き込んで、信頼性の文化を推進・醸成していける人。開発メンバーやビジネスサイドも含めて、信頼性への興味や重要性を広げて、組織全体のカルチャーをアップデートしていける。そんな推進力のある人と働けたら、楽しいだろうなと思っています。
── 技術で変化を起こしたいと考えている人に、IVRyに来る理由を挙げるとしたら。
答えのない場所にこそ、面白い仕事があると思っています。AI×音声のSREは、まさにそういう領域です。誰かが作ったベストプラクティスがあるわけじゃないので、それを自分で考えていくのは面白い。
IVRyはスタートアップなので、新しい課題が日々生まれます。自分たちで考えて、試して、失敗も許容される。会社のフェーズは進んできていますが、これからの信頼性のあり方をゼロから作り上げる面白さを、まだ味わえる段階にあると思います。
── 挑戦しやすい理由は、どこにあると思いますか。
専門性の高いエンジニアが多いことは、大きいと思います。強いエンジニアが持ち込む課題は、そもそも難しい。でも、解けば世の中に価値が出ると分かっているものでもある。タスクを作る時点で、すでにチャレンジングなものが大量に出てくる。それが価値になると信じられるから、挑戦しやすいんです。
経営の側に、技術への深い理解があることも大きいですね。代表が技術に強くて、エンジニアと話すような感覚で会話が成り立つ。その様子を見ると、やっぱり大きいんだろうなと感じます。
電話は、繋がって当たり前。その当たり前を、技術で支え続ける。答えのない領域で、これからの信頼性のかたちを描く仕事が、IVRyにはあります。
キャリア登録 / カジュアル面談
IVRyでは「イベントや最新ニュース、新着ポジションの情報を受け取りたい」「会社について詳しく話を聞いてみたい」といった方に向けて、キャリア登録やカジュアル面談の機会をご用意しています。ご興味をお持ちいただけた方は、ぜひ以下のページよりご登録・お申し込みください。
