はじめに こんにちは、2026年5月入社のyaMayuです！ 本記事では、2026年5月に入社したメンバー2名に入社直後の感想をお伺いし、まとめました。 KINTOテクノロジーズ（以下、KTC）に興味のある方、そして、今回参加してくださったメンバーへの振り返りとして有益なコンテンツになればいいなと思います！ Y.Q 自己紹介 グループコアシステム部　ビジネスディベロップメントGに配属されました。 自動車部品メーカー→ITコンサル→当社　といったキャリアを歩んでいます。 所属チームの体制は？ グループコアシステム部の人数が多いですが、ビジネスディベロップメントGは割と少数精鋭です。（現在6人） 同じグループのメンバーは出身地が多様で（欧州、北米、アジアetc.）グループ内の公用語は英語です。 KTCの入社動機や入社前後のギャップは？ トヨタグループとしての安定感と、若い会社らしいベンチャーカルチャーの両方に魅力を感じたこと、またモビリティサービス領域でのビジネスディベロップメントに携わりたいと考えたことが入社の動機です。 今のところ、大きなギャップは感じていません。 現場の雰囲気はどんな感じ？ 真面目な雰囲気とフラットな雰囲気の、良いバランスが取れていると感じます。 オフィスで気に入っているところ Water Serverがある。 周りにランチできるお店が多い。（立地） yaMayuさんからの 質問：旅行が趣味とのことなので、おすすめの場所やまた行きたい場所があればお伺いしたいです！（日本国内でも、海外でもどちらでもOKです！） 小笠原諸島です！片道1日ほどかかる長い船旅を経て訪れる分、非日常な体験が待っていました（ウミガメの産卵ツアーもおすすめです！）。太平洋に浮かぶ夜の星空や朝日にも感動し、また訪れたいと思っています。 yaMayu 自己紹介 プラットフォーム開発部 Quality Engineering GでQAエンジニアをやっています。 異業種からSESに転職し、第三者検証を経てKTCに入社しました。 京都市出身で今は都内在住、室町オフィス勤務です。 趣味と呼べるものはあまりないですが、移動中はよくオーディオブックを聴いています。読書も好きです。ミステリー多めです。たまに映画を観に行ったりします。 所属チームの体制 Web QA, アプリQA, SETチーム合わせて21名です。 6月にSETチームが新設され、大幅に人が増えました。 QA, SETチームとも室町オフィスとOsaka Tech Labにメンバーがいます。 私はWeb QAチームに所属しています。 現場の雰囲気 大阪のメンバーとは拠点が離れていますが、Slackやzoomで随時連絡や相談をしています。 オフィスに出社しているときは、一緒にランチ行くこともあり和やかな雰囲気だと思います。 KTCへの入社動機や入社前後のギャップ 前職、前々職ではお客様先のプロダクトに携わっていたので、自社プロダクトのQAに携わりたいと思い、転職しました。 プロダクトのジャンルはあまり絞っていなかったのですが、サブスクサービスはいろんなジャンルでどんどん広まっているので、今後も需要がありそう ＝ 多くの人に使ってもらえるプロダクトに携われそう、と思い入社しました。 カジュアル面談～面接～オファー面談でいろいろお話を聞くことができていたので、入社後の大きなギャップは今のところないです。 オフィスで気に入っているところ 地下鉄の駅から直結なので、雨でも濡れない＆日差しも怖くないところ。 周辺においしいお店が多いところ。（お値段は安くはないですが…。） フリードリンクでコーヒーが飲めるところ。 Y.Qさんからの質問：京都出身者として、観光客があまり知らないおススメの場所や楽しみ方をご教示ください！ 最近はネットやSNSですぐ広まってしまうので難しいですね…笑 志津屋のカルネ：もうすっかり有名になってしまいましたが、昔から好きで、今も実家に帰ると必ず食べます！ 法輪寺 電電宮：電気・電波の神様を祀る神社です。（日本唯一らしいです！）IT関連の人にも人気があります。嵐山にありますが、渡月橋から少し離れているので比較的空いていると思います。 明智越：明智光秀が愛宕神社に参詣する際に通った道で、本能寺を攻める際にも通ったと言われています。今はハイキングコースになっていて、歴史と自然を感じられます。（台風や豪雨の影響で道が荒れている場合もあるようなので、訪れる際はご注意を。） さいごに みなさま、入社後の感想を教えてくださり、ありがとうございました！ KINTOテクノロジーズでは日々、新たなメンバーが増えています！ 今後もいろんな部署のいろんな方々の入社エントリが増えていきますので、楽しみにしていただけましたら幸いです。 そして、KINTOテクノロジーズでは、まだまださまざまな部署・職種で一緒に働ける仲間を募集しています！ 詳しくは こちら からご確認ください！

こんにちは！ 株式会社スタメン 、プラットフォーム部のもりしたです。 7月10日（金）・11日（土）の2日間、東京のTOC有明で開催された SRE NEXT 2026 に参加してきました！ 昨年の SRE NEXT 2025 （昨年のブログは こちら ）ではLOGOスポンサーとしての参加でしたが、今年は SILVERスポンサー としてブース出展を行いました。 本記事では、ブース企画の様子と印象に残ったセッションについてレポートします。 SRE NEXT 2026 スポンサーボードの前で記念撮影。SILVERスポンサーにスタメンのロゴが！ SRE NEXT 2026 の雰囲気 昨年に引き続き、TOC有明での開催でしたが、ブース会場の部屋が変わったこともあってか、昨年よりも広く感じました。 公式の来場者数は確認できていませんが、昨年と比べて参加者が増えた印象で、ブース会場全体に活気がありました。 ブース会場の様子。中央にスタメンブースが見えます 懇親会は昨年と同じ会場でした。 食事もお酒も充実しており、楽しい時間を過ごせました。 懇親会の様子。鏡開きも行われ大いに盛り上がりました スタメンのブース出展 SRE関連カンファレンスでのスポンサーは、今年5月に名古屋で開催した クラウドネイティブ会議 に続き2回目です。 2日間で約 180名 の方にお越しいただきました！ カンファレンス中の運営メンバーはすべて東京本社で働いているスタメンのエンジニアです。写真には載っていないメンバーを含めて、合計 6名 でブースを運営しました。 スタメンブースの様子。お揃いのベースボールシャツでお出迎え！ ブースに設置したパネルはデザイン部が担当。複数の部署が協力してカンファレンスの準備を進めています。 ブース企画：アンケートに答えてスタメンオリジナルのノベルティをGETしよう！ ブースでは、アンケートにお答えいただいた方にスタメンオリジナルのノベルティをお渡しする企画を実施しました。 ノベルティ キーキャップキーホルダー （スタメンの s, t, m, n の文字入り） スタメンロゴ入りマイクロファイバークロス アンケート結果 アンケートパネル。シールを貼って回答いただきました アンケートは2問で、以下のような結果になりました。 Q1. 今年カンファレンスに参加した回数は？ 選択肢 結果 2〜3回 🥇 1番多い 1回（SRE NEXT 2026 が初） 🥈 2番目に多い 4〜5回 🥉 3番目 6回以上 4番目 1月に開催された SRE Kaigi 2026 に参加され、今回の SRE NEXT 2026 が2回目という方が多かったです。中には クラウドネイティブ会議 にも参加されたという方もいらっしゃいました。 tech.stmn.co.jp Q2. あなたの組織の「SRE」の現状は？ 選択肢 結果 独立したSREチームがある 🥇 圧倒的に多い 各開発チームにSRE担当がいる 🥈 2番目に多い これからSREを立ち上げる・検討中 🥉 3番目 SREチームの立ち上げ予定がない 4番目 SREのカンファレンスということもあり、「独立したSREチームがある」が圧倒的に多い結果でした（笑）。 「各開発チームにSRE担当がいる」は 『独立したSREチームも別にあるんですよね』というお話をいただくことが多く、開発チームにSRE担当がいる場合でも、横断的なSREチームが存在するケースが多いと感じました。 「SREチームの立ち上げ予定がない」は、エンジニア組織の規模的にSRE相当の役割を兼務で担っているケースや、SRE立ち上げの支援を行っている企業のため自社にはチームがないというケースがありました。 学びがあったセッション Day1・Day2 を通じていくつかのセッションを聴講しました。 すべて学びがありましたが、それぞれ1つずつピックアップしてご紹介します。 Day1：ABEMAにおける Incident Management 再設計 株式会社AbemaTV SRE/EM 宮﨑 大芽さんによるセッション speakerdeck.com 障害対応自体は回っているものの、「誰が指揮をとるのか」「役割が明確でない」といった課題を抱えていた AbemaTV 社が、Incident Management を再設計した事例のお話でした。 障害対応に関わる定義の明確化や、障害対応をサポートする Bot のブラッシュアップが紹介されました。 Bot では SEV（Severity：障害重大度）判定を直感的に行える仕組みが導入されるなど、実践的な改善が印象的でした。 特に心に残ったのは、 「仕組みを提供しただけでは組織に浸透しない」 というお話です。 Incident Commander の役割を明確に定義したにもかかわらず、実際に障害が発生すると、メンバーは慣れた動き方でぱぱっと対応を進めてしまい、再設計した定義に沿った動きにはならなかったそうです。 私自身も昨年、障害対応の流れや Incident Commander の担当ルールなどを整理した障害対応マニュアルを作成しましたが、現実にはその通りに運用できていない部分があります。 組織への浸透の難しさ、そして難しくても地道に浸透させていくことの大切さに改めて気付かされたセッションでした。 Day2：SREとQA、二人三脚で進めるSLO運用 株式会社estie SRE 杉田 毅博さんによるセッション speakerdeck.com マルチプロダクト体制への移行期に障害が多発する中、SRE と QAE（QA Engineer）が協力して CUJ（Critical User Journey）を定めた事例のお話でした。 発表タイトルは「SLO運用」でしたが、セッションの内容は CUJ の整備と SRE・QAE の協力体制が中心でした。 SRE と QAE は同じ「顧客価値」という目標を異なる視点から見ており、協力し合うことでお互いの強みを活かし、品質を高めていけるという内容に学びがありました。 この事例では、Platform 型の SRE は多くのプロダクトを横断的に見ているため、個々のプロダクトへの理解は深くありません。 一方、QAE はプロダクトのチームに深く入り込み、CUS（Core User Scenarios）という最重要ユーザーシナリオをチームとの合意のもとに作成していました。 SRE は QAE と協力して CUS の中から最も重要なものを CUJ として選定することで、本来最も難しい「チームとの合意」を経た CUJ を整備することができたのです。 私自身もこの事例の Platform 型 SRE と同様の立場にあり、プロダクトに深く入り込めているとは言えません。 深い知見はプロダクト開発メンバーや QAE の方が持っています。 互いの強みや視点の違いは対立するものではなく、補完し合うもの。1つのチームに閉じていたら進まなかった課題も、チームを越えた協力で解決できるという学びを得たセッションでした。 ブース運営を経験して 私自身は今年に入って RubyKaigi 2026、クラウドネイティブ会議、そして SRE NEXT 2026 と、7月時点で3回のブース運営を経験しました。 長くエンジニアをやっていても、ブース運営の経験がある人は意外と少ないのではないでしょうか。今年だけで3回も担当できたことは、とても貴重な経験だと感じています。 普段お話しする機会のない他社のエンジニアや学生の皆さんとの会話はいつも楽しく、よい刺激をいただいています。 さいごに SRE NEXT 2026 では、ブース出展を通じて多くの方と交流でき、セッションからも実践的な学びを得ることができました。今回の学びを日々の業務に活かし、スタメンのプラットフォームをより信頼性の高いものにしていきたいと思います。 今回レポートした Site Reliability Engineer (SRE) や Platform Engineering の領域にご興味のある方は、ぜひご応募ください！ herp.careers

はじめに 本記事は、2026年3月10日に開催された Elastic{ON} Tokyo での発表「 『定型』を許さない製造業データへの挑戦 」の内容をもとにした連載の最終回です。 第1回：ビジュアル情報を活かす 第2回：分断されたデータを繋ぐ 第3回（本記事）：止めずに進化させる 第1回ではビジュアル情報を使った類似図面検索、第2回ではデータソース横断検索の設計について書きました。最終回の本記事では、製造業データの「非定型性」にどう向き合っているか、そして進化し続けるインデックスをどうやって無停止で運用しているかについて書きます。 「正解のデータモデル」が存在しない 製造業のデータにおける3つ目の壁は、データモデルの多様性です。 データ構造がバラバラ 図面の「表題欄」ひとつとっても、会社ごとに記載項目やフォーマットは驚くほど違います。しかもこの違いは会社単位に留まりません。部品の種類によっても、設計者の書き方によっても、データの持たせ方は変わります。 たとえば同じ「部品データ」でも、機械部品の「部品図」と電気制御の「回路図」と仕様を書いた「仕様書」ではデータ種そのものが違う。同じデータ種の中でも、図番や品名のような共通項目以外は「材質」だったり「熱処理」だったり「表面処理」だったりと、作るモノ次第で必要な情報が変わる。極端な話、ネジ一本と大型エンジン筐体では管理すべき項目が全く違います。 普通のシステムなら共通スキーマを事前に定義するところですが、製造業データではそれが通用しないのが厄介なところです。 検索ニーズもバラバラ データ構造がバラバラであるように、検索の切り口もバラバラであるということも重要です。 同じ部品を探したいという目的でも、立場が変われば検索の切り口は全く違います。設計は「形状」から入りたいし、調達は「発注実績」から入りたいし、品質管理は「不具合履歴」から入りたい。 もっと厄介なのは、一人のユーザーの中でもこのコンテキストが動的に切り替わるということです。最初は「似た形の図面」を漠然と探していた設計者が、良い事例を見つけた瞬間に「このサプライヤーで作った実績はあるか？」と調達の視点に切り替わる。実績を見たら今度は「この加工方法での不具合率は？」と品質の視点に潜っていく。 固定の検索項目では、この思考の連鎖には追従できません。どんな切り口から入ってきても、コンテキストがどう遷移しても、データ間の関係性を提示し続けられる柔軟さが必要です。 進化し続けるインデックス、止められない制約 ここまで書いてきた多様性は、データ構造や検索の切り口が日々変わり続けた結果として生まれたものです。新しい製品カテゴリが増えれば管理すべき属性が変わるし、探し方も変わる。そしてこの変化は今後も止まりません。 こうした変化に追従するには、データや検索の切り口に合わせてインデックス設定を切り替えていくことが重要です。すなわち、マッピングの更新、アナライザーの調整、フィールドの追加や型変更など、インデックス定義を継続的にアップデートする必要があります。 ただ、ここに大きな制約があります。 CADDi Drawer は今この瞬間の意思決定を支えるアプリケーションなので、インデックス構造の変更でユーザーの業務が止まるのは許容できません。一方、Elasticsearch の reindex 処理ではデータの一貫性を保つために書き込みを止めるのが一般的な手法です。 「常に最新のインデックスに進化させたい」と「24時間365日、更新も検索も止めてはいけない」。この2つの要求は正面からぶつかります。 ゼロダウンタイム reindex の仕組み 標準的な reindex の問題 Elasticsearch でインデックス定義を変更する通常の手順はこうです。 新しいマッピングでインデックスを作成する 旧インデックスから新インデックスへデータをコピーする（reindex） エイリアスを切り替えて新インデックスを参照させる 旧インデックスを削除する 問題はステップ2です。reindex 中に旧インデックスへ書き込まれたデータは新インデックスに反映されない。書き込みを止めれば一貫性は保てますが、ユーザーの更新がブロックされる。止めなければ、切り替え時にデータが欠損する。どちらも受け入れられません。 私たちのアプローチ そこで、ゼロダウンタイムでインデックスを切り替えられる仕組みを自前で実装しました。 書き込みと読み込みのパスを抽象化し、新旧のインデックスを並行稼働させながら、一貫性を保った状態でトラフィックを切り替えます。 具体的には、reindex を開始したら新旧両方のインデックスに書き込むことで、新インデックスにも最新データが反映されるようにしています。reindex が完了したら、読み取りパスを新インデックスに切り替える。この切り替えは瞬時に行われるので、ユーザーの検索は中断しません。書き込み順序の保証やデータ整合性のチェックも組み込んでいて、データが欠損しない仕組みになっています。 ユーザーからはメンテナンスの存在が見えず、常に最新のインデックス構造で検索できる状態を維持しています。 スキーマ変更を恐れずに回せる 個人的には、このゼロダウンタイムの仕組みで一番大きいのは、スキーマの変更を躊躇なくやれるようになったことだと思っています。 製造業のデータモデルに正解がない以上、スキーマは仮説です。現場のフィードバックを受けて継続的に直していくしかない。ユーザーから既存スキーマでは表現できない属性の要望が出てきたらフィールドを追加するし、検索精度を上げたければアナライザーの設定を見直してインデックスを再構築するし、新しいデータソースが接続されたら非正規化構造ごと変える場合もあります。 こうした変更のたびにサービスを止めていたら、改善のサイクルは回りません。ゼロダウンタイム reindex があることで、本番環境のインデックスを継続的に進化させ続けられています。 連載のまとめ 3回にわたって、CADDi Drawer の検索基盤について書いてきました。 第1回では、図面をベクトル化して kNN 検索で類似図面検索を作った話。第2回では、10兆規模の組み合わせを用途別インデックスと動的制御で捌いている話。そして今回は、スキーマが変わり続ける中でゼロダウンタイム reindex でインデックスを進化させ続けている話。 振り返ると、3つの壁はそれぞれ独立した問題のように見えて、根っこでは繋がっています。ビジュアル検索がなければ探索は始まらないし、データソース横断がなければ探索は完結しないし、スキーマを柔軟に変え続けられなければ探索は陳腐化する。どれか一つが欠けても「探索」にはならない。 3つの壁を個別の技術課題として解くのではなく、「探索」という一つの設計思想で貫けたことが、振り返ってみると一番大きかったと思っています。 製造業のデータはこれからも変わり続けます。私たちの検索基盤も、それに合わせて進化し続けていきます。 本連載の内容は Elastic{ON} Tokyo での発表をもとにしています。発表スライドは こちら からご覧いただけます。