KINTO FACTORY開発グループ、技術広報グループ、QAグループなどなど色々な事を兼務でやらせて頂いているエンジニアの中西です。KINTO FACTORYでエンジニアリングリードとしてマイクロサービスアーキテクチャを採用した経緯と、その後の展開についてお話しします。 なぜマイクロサービスを選んだのか 短期的には、運用負荷が増え、開発の手間もモノリシック構成より大きくなることは想定していました。それでも、組織やサービスをスケールさせる段階では、チームを細かく分けられるなどのメリットが大きいと判断したのがポイントです。 また、私自身、過去に担当したシステムでも、顧客規模の拡大に合わせて柔軟にスケールできるよう、マイクロサービスで開発を進めた経験がありました。この経験も判断材料の一つとなっています。ただし、システムアーキテクチャには唯一の正解はなく、サービス開発のスピード感、将来のスケール、チームの規模に応じて、適切に選択していくことが重要だと考えています。 トヨタグループのスケール 私たちはトヨタグループの中で事業を拡大していく役割を担ったソフトウェア開発組織です。トヨタグループは世界最大の自動車メーカーであり、世界中で 1億5000万台ものトヨタ車が走っています 。 KINTO FACTORYはトヨタ自動車のリフォーム、アップグレード、パーソナライズなどを提供しているサービスです。将来的にこれらの車両が私たちのサービスを利用することを想定すると、以下の課題に直面します。 スケーラビリティ : 膨大な数の車両に対応できる拡張性 高速性 : 24時間365日、世界中で走行する車両への即座の応答 コスト効率 : 高負荷に伴うインフラコストの最適化 パフォーマンスとコストの関係 高負荷はそのままコスト増につながります。たとえばAWSであれば、ECSのコンテナ数やインスタンス数が増えるほどコストは大きく変動します。 私は過去の開発経験から、パフォーマンスチューニングにおいて「無駄を削ぎ落とす」ことの重要性を学びました。パフォーマンスを突き詰めていくと、処理はどんどん低レイヤーへと移っていきます。実際、JavaのようなVM環境やSpring Bootのような大規模フレームワークは、相対的にオーバーヘッドが大きくなることもあります。大規模なシステムでは、その特性を理解した上で最適化やチューニングを行うことが求められます。 オンプレ時代には、Apacheで運用していたシステムの性能がボトルネックとなり、アプリケーション層に処理を渡す前にApacheモジュールを自作して対応したこともありました。この経験から、システム設計では「必要な箇所だけを低レイヤーでチューニングできる状態」にしておくことが重要だと考えています。全てを低レイヤーで実装する必要はなく、開発効率とのバランスを取りながら設計することがポイントです。 現在のクラウド環境において、その解決策の一つがマイクロサービスです。マイクロサービスであれば、パフォーマンスが求められる箇所だけを切り出し、ピンポイントでチューニングすることができます。他のサービスはそのまま維持しつつ、必要な部分だけ外出しして最適化できる。これが、マイクロサービスを選択する大きな利点の一つだと考えています。 こうした設計思想を支えるのが、マイクロサービスが持つ「小さく試せる」特性と、それによって広がる 「技術選定の自由度」 です。 マイクロサービスが可能にした技術選定の幅 理想と現実のギャップ マイクロサービスを採用したことで、サービスごとに最適な技術を柔軟に選べる土台ができました。例えば当初は、私自身運用経験がありパフォーマンスも十分なGo言語を使うことを検討しましたが、以下の課題に直面しました。 社内でGo言語を扱える人材が限られていた 組織として過去にGo言語開発経験がないため、採用メッセージが弱かった 当時の開発体制や採用市場を踏まえると、JavaとSpring Bootであれば安定的に人材を確保できるという判断 こうした背景から、初期フェーズではKotlinをメインに選択しましたが、その後エンジニアが増えた現在では、Go言語で開発したサービスも実際に運用しています。つまり、当初の制約に縛られるのではなく、組織の成長や人材状況に応じて技術選定を柔軟に進化させてきた、という点がKINTO FACTORYの開発の大きな特徴です。 Kotlinの採用 開発スケジュールはあらかじめ決まっており、利用可能なリソースを踏まえた結果、KINTO FACTORYの開発開始当初はSpring Bootを選択することになりました。ただし「単にJavaで開発するだけでは、新たなチャレンジが生まれにくいのではないか」と考え、 社内で既に利用実績があったKotlin を採用しました。 私自身がAndroid開発でKotlinを扱っていたことも大きな安心感の一つです。サーバーサイドKotlinの利用は初めてでしたが、社内には知見を持つメンバーがいたため相談できる環境がありました。また、言語的な習熟度についても、JetBrainsのIDE(IntelliJ IDEA)による強力な補完機能のおかげで、Kotlin未経験者であってもJava経験者であればスムーズに開発に参加できることがわかっていました。 さらに、KotlinにはJavaと比べて次のようなメリットがあります。 1. コードが簡潔（ボイラープレート削減） data class Car(val model: String, val year: Int) 👉 Javaだと何十行も必要な getter/setter・toString・equals/hashCode が、Kotlinでは1行で自動生成。 2. Null安全 var car: Car? = null println(car?.model) // 安全にアクセス（nullならnullを返す） 👉 ? を使うことで コンパイル時にNullチェックが担保 され、実行時のNullPointerExceptionを未然に防げる。 3. 関数型プログラミングのサポート val cars = listOf(Car("Toyota", 2022), Car("Lexus", 2025)) val models = cars.map { it.model } 👉 map ・ filter ・ラムダ式・拡張関数などを活用し、 柔軟で表現力のあるコード が書ける。 4. Javaとの高い互換性 // KotlinからJavaのクラスをそのまま利用可能 val date = java.util.Date() 👉 JVM上で動作するため、 既存のJavaライブラリやフレームワークをシームレスに利用 できる。 5. 非同期処理が簡単（コルーチン） import kotlinx.coroutines.* fun main() = runBlocking { launch { delay(1000) println("Finished!") } } 👉 suspend 関数や launch を使って、 複雑な非同期処理を直感的に記述 できる。 3つのポイント KotlinはJavaと比べて 簡潔・安全・表現力豊か Null安全・関数型サポート・コルーチンで モダンな開発 が可能 Java資産を活かしつつ、新しい設計スタイルを取り入れられる Rustへの挑戦 マイクロサービスによりサービス単位で独立して実装できたからこそ、私たちは一部の機能でRustに挑戦できました。もしモノリシック構成を採っていたら、新言語を取り入れるのは難しかったでしょう。マイクロサービスという仕組みがあったからこそ、リスクを抑えながら実験的に適用できたのです。 以下のような理由からRustを選びました。 人材戦略 : 低レイヤーでカリカリにチューニングできるエンジニアを採用できる 技術的魅力 : Stack Overflow でも人気の高い言語として注目されている 将来性 : Rustはその高い安全性と信頼性を持つ特長から、自動車業界での採用が拡大している Rustは自動車業界での活用が広がりつつあり、Woven Planet（現Woven by Toyota）のArene OSチームの求人でも言及されていました。こうした動向も参考にしながら、私たちの開発でもRustを導入することにしました。 小さく試して積み重ねる文化 そして何より大きかったのは、 マイクロサービスにより小さく試しながら成果を積み重ねられたこと です。社内に知見のない言語に挑戦する不安はありましたが、リスクを限定した小規模導入から始め、実運用を通じて成果を蓄積できました。このプロセスがRust採用の推進力となり、今では入社動機につながったエンジニアが活躍する基盤になっています。 将来への挑戦 将来的には、KINTO FACTORYにおいても自動車のハードウェアに近い領域でRustの強みを発揮できるようにし、そうした挑戦に取り組めるエンジニアが集まる環境をつくっていきたいと考えています。 さらに長期的には、Rustに限らず 多様な技術的挑戦を続けられる組織 を目指しています。こうした文化を通じて、新しい価値をともにつくり出せる環境を築いていくことが、私たちの目指す姿です。 スキーマ駆動開発の導入 インターフェースの重要性 マイクロサービスアーキテクチャにおいて、最も重要なのは サービス間のインターフェース定義 です。インターフェースは単なる「入出力の仕様書」ではなく、チームや組織全体の 開発スピードと品質を支える契約 そのものです。 一見地味に見える部分ですが、これを正しく整備できるかどうかで、プロジェクト全体の成否が決まると言っても過言ではありません。 従来はExcelやWordといったドキュメントでインターフェースを管理することが一般的でした。しかし、この方法には以下のような問題があります。 バージョン管理が困難（最新がどれか分からなくなる） 更新漏れが発生しやすく、実装との差分が広がる 複数のチームで並行開発する際に、矛盾や二重管理が避けられない マイクロサービスのようにサービス数が増え、独立してリリースサイクルを回すスタイルでは、この「Excel管理」は早々に破綻します。だからこそ、 常に正しいインターフェース定義にアクセスできる仕組み と、 多重管理や齟齬を起こさない運用設計 が不可欠になります。 スキーマ駆動開発のメリット この課題を解決するアプローチが スキーマ駆動開発（Schema-First Development） です。KINTO FACTORYにおいても、スキーマ駆動開発を導入したことで次のような効果を得ることが出来ています。 自動生成による効率化 バリデーションロジックやスタブコードを人手で書かずに、スキーマから自動生成できます。これにより実装スピードが向上し、ヒューマンエラーを削減できます。 言語非依存の柔軟性 プロジェクト内で複数言語（JavaScript、Kotlin、Rust、Goなど）が混在していても、同じスキーマからクライアントやサーバーコードを自動生成可能。これにより 技術選定の自由度 が広がり、チームごとの得意領域を活かす開発が可能になります。 エラー削減と整合性担保 手作業によるスペルミスや記述漏れといった「人間特有のミス」を大幅に減らせます。加えて、CI/CDパイプラインでスキーマの整合性を常時検証することで、変更が即座に検知され、品質が保たれます。 変更に強い確実性 マイクロサービスが独自に進化しても、スキーマがインターフェースとして存在するため、相互に影響を受けにくい。結果として、 サービスごとの独立性と同時に全体の安定性 を維持できます。 生成AI時代におけるマイクロサービスの重要性 生成AIは「非常に優秀な新入社員」のような存在です。ただし、一度に扱える コンテキスト（文脈） には限界があります。だからこそ、 小さく分割され、明確なインターフェースでつながるマイクロサービス との組み合わせが効果を発揮します。 AIコーディングとの親和性 AIに依頼をする際に欠かせないのは、 あいまいさを排除すること です。明確なゴールが示されれば短時間で成果を出せますが、指示が曖昧だと期待外れの方向へ進んでしまうことも少なくありません。 そのために重要なのは、最初に必要な情報を整理してシンプルに伝えること、そして進行中に確認と修正を行うことです。役割を切り分けたマイクロサービスは、この考え方を実装レベルで支える仕組みだと言えます。役割がはっきりすることで、次のような利点が得られます。 型・制約・具体例 が明確になる DTOやバリデーション処理 などの生成対象が一目で分かる 破壊的変更 を差分として即座に検知できる 実務においては、各サービス単位でAIが理解しやすい構造化された APIドキュメント を整備することが安定性につながります。例えば以下のような内容です。 最新スキーマ リクエスト／レスポンス例 エラー処理の設計方針 これらをREADMEなどのMarkdownファイルにまとめ、 AIに渡す最小限で十分な資料 とすることで、生成結果の精度と安定性は飛躍的に向上します。 コンテキストの問題 生成AIを活用した開発には、次のような課題があります。 大規模なコンテキストを保持・理解するのが難しい システムが複雑になるほど不具合が発生しやすい これは人間にも当てはまります。大規模システムは全体像の把握が難しく、結果としてバグを生みやすい構造を持ちます。 マイクロサービスアーキテクチャ は、この課題を解消するために登場したアプローチです。 マイクロサービスのメリット サービスを小さな単位に分割することで、 生成AIも人間も 理解すべき範囲がシンプルになる バグが発生しにくく、修正もしやすい モジュール化によって 開発効率が大幅に向上する 結果として、マイクロサービスは生成AI時代の開発において「スピード」と「品質」を両立させるための最強の基盤となります。 2つの重要ポイント インターフェースの重要性 KINTO FACTORYの開発を通じて得られた知見は、生成AI時代のシステム開発においても大きな指針となります。 サービスを小さく保つ マイクロサービスに分割することで、チームの独立性と開発スピードを高め、将来的なスケーラビリティを確保できる。 インターフェースを明確にする スキーマ駆動開発により、仕様の曖昧さを排除し、複数チームや複数言語が混在する環境でも一貫性と整合性を維持できる。 これらは単なる設計手法にとどまらず、 生成AIとの協働を前提とした開発の安定性を支える実践知 です。役割を切り分け、仕様を契約として明文化することで、人間とAIがともに安心して開発を進められる環境をつくり出せます。 理想と現実のギャップに直面しながらも改善を積み重ねることで、KINTO FACTORYは進化を続けています。生成AI時代においても、この2つのポイントは変わらぬ指針となるでしょう。最初の思想通りにうまくいった部分とうまくいかなかった部分はありますが、小さな改善を積み重ねながら、現在もサービスを運用しています。 1億5000万台のトヨタ車を視野にした壮大な挑戦は、まだ始まったばかりです。この大きな挑戦に一緒に立ち向かって行ける仲間を募集しています。カジュアル面談なども実施していますので、もし興味を持って頂けましたらぜひご連絡お待ちしております。 https://hrmos.co/pages/kinto-technologies/jobs

はじめに こんにちは、2025年7月入社のhidenoriokaです！ 本記事では、2025年7月入社のみなさまに入社直後の感想をお伺いし、まとめてみました。 KINTO テクノロジーズ（以下、KTC）に興味のある方、そして、今回参加下さったメンバーへの振り返りとして有益なコンテンツになればいいなと思います！ hidenorioka  自己紹介 KINTO ONE開発部 新車サブスクFE開発グループでWebフロントエンド開発を担当しています！ 所属チームの体制は？ 東京・大阪・福岡と、複数の拠点に所属するフロントエンドエンジニア8名で構成されています。 現場の雰囲気はどんな感じ？ プロジェクトを推進することでサービス成長させることは勿論、プロダクトの品質改善や開発体験の向上まで主体的に提案・コミュニケーションできる環境だと思います。 質問や相談事はチーム内で日常的に会話されているので、とても気軽にコミュニケーションが取れています！ KTCへ入社したときの入社動機や入社前後のギャップは？ 入社前までクルマやモビリティ業界には全く縁がなかったのですが、KINTOの新車サブスクを初めて知った時に「こんなサービスがあるんだ！」と驚きました。更なるサービスグロースに自分も関わってみたいと思ったのが入社のきっかけです！ 事前にチームメンバーの方とお話しする機会があったり、外部メディアへの発信も多くあったので、入社前後でギャップはありませんでした。 オフィスで気に入っているところ 最寄りの三越前駅からオフィスまで地下直通なので、暑い日も雨の日も快適に通勤できるのが地味に嬉しいです。 K.S.さん ⇒　hidenoriokaへの質問 室町で働くようになって感じる良いところを教えてください。 オフィスがある日本橋・室町エリアにはランチスポットがたくさんあるので、お昼に散策するのが楽しいと思います！ S.N  自己紹介 新サービス開発部で中古車をメインで担当しております。 前職はバックエンドエンジニアからPMをしておりました。 アイコン画像はペット（黒柴：おはぎ♂、猫：つゆ♀） 所属チームの体制は？ 私が担当している中古車ECサイトは現在、KINTO（新車）でご利用いただいた返却車両を、中古車として再掲載しお客様にご利用いただくwebサービスでございます。 中古車のチームとしては私含め9名ですが、部では30名近いメンバーが在籍しております。 現場の雰囲気はどんな感じ？ コミュニケーションがとりやすく、相談しやすいです。 タスクに対して常に疑問を持つメンバーが揃っているので、根本的な解決策を考えられる環境です。 KTCへ入社したときの入社動機や入社前後のギャップは？ 前職では、エンジニアとPMを担当しておりましたが、ITの技術を駆使して事業に貢献する会社で働きたいと考えました。 大きなギャップはありませんでしたが、想像以上にスピード感をもって案件を動かしていく必要があるので、ついていくのに必死です。笑 オフィスで気に入っているところ 室町オフィスのジャンクションが、想像よりもおしゃれでした。 hidenorioka ⇒　S.Nさんへの質問 これからKINTOテクノロジーズのキャリアで挑戦してみたいことを教えていただきたいです！ まずは任されたプロダクト・プロジェクトをしっかりと成功させ、経験を積んでいきたいです。そしてお客様が求めるサービスを自分発信で提案し、実現できるようにしたいです！ M.H  自己紹介 新サービス開発部 KINTO FACTORY開発Gにジョインし、ディレクション業務を担当しています。 前職では大手事業会社でプロデューサーとして、UX領域を中心に携わっていました。 所属チームの体制は？ フロントエンドエンジニア4名、バックエンドエンジニア3名、PdM1名、QAエンジニア1名という体制で、設計からQAまでを一貫して対応できるチームです。 現場の雰囲気はどんな感じ？ 私は総合企画やクリエイティブ室の方と接する機会が多いため、チームメンバーとの関わりはあまり多くなく、雰囲気はよく分かりません。ただ、前職の職場は良い意味で「ピリッとしているけれど淡々と進む」雰囲気だったので、それと比べると、こちらでは楽しみながら仕事をしている印象を受けます。 KTCへ入社したときの入社動機や入社前後のギャップは？ これまで長くToC向けサービスに携わってきた経験を、即戦力として活かせると感じたため。 前職が内製開発を備える事業会社だったこともあり、事業部とのやり取りや内製開発の体制の理解も持っていたため、特に大きなギャップは感じていません。 オフィスで気に入っているところ 大きな窓から差し込む自然光による明るさと開放感、そして島と島の間隔が広く圧迫感のない空間がとても気に入っています。 S.Nさん ⇒　M.Hさんへの質問 今乗っている車、または乗ってみたい車があったら教えてくださいー！ ヴィンテージカーが好きなので、「 初代トヨペット クラウン 」は、永遠の憧れです。 Kevin Diu 自己紹介 DBREチームに所属しております。 前職はSoftware Engineerとして働いていました。 所属チームの体制は？ ６人チームです。scrumという開発フレームワークで開発を進めています。 組織横断でDatabaseに特化したエンジニアチームです 現場の雰囲気はどんな感じ？ 開発言語：Goはメイン AWSは結構使っている KTCへ入社したときの入社動機や入社前後のギャップは？ 入社動機：自分の技術力で自動車業界に貢献してみたい 入社前後のギャップ：あまりないです オフィスで気に入っているところ 正直あまりない。。 M.Hさん ⇒　Kevin Diuさんへの質問 香港と日本の働き方の違いについてあれば教えてください。 実際日本で働いてみてどう感じているか教えてください。 香港人は、「時間はお金だ」という思いが常にあり、仕事や議論には常に時間を意識して進めるので、結論や成果物はささっと出ることが多いですが、日本ですと議論や原因まで究明することが多いです。どれも一長一短だと思います。 実際日本で働いてみて、想像よりみなさん優しく思っています。昔は日本のドラマをよくみていて、「半沢直樹」みたいに働かないといけないという思いがありましたが、実際は全然違いますw H.Y  自己紹介 いままではSierでインフラ系のシステム構築/移行/運用を実施していましたが、2025年7月からKTCにジョインました。初めての事業会社となるので、より一層、自分事として意識して業務できればと思っています。 所属チームの体制は？ 自社サービスとは別となりますが、主にTMC(トヨタ自動車)案件に携わっております。 現場の雰囲気はどんな感じ？ 案件によりさまざまですが、アサインされているプロジェクトでは、M365を使用しています。 KTCへ入社したときの入社動機や入社前後のギャップは？ KTC社内のプロジェクトは、モダンスタイルなので、いわゆるJTCのような雰囲気がないところが良い意味でのGAPですね。 オフィスで気に入っているところ 神保町：最近リニューアルしていて、全体的にフレッシュなところがいい感じです！ Kevin Diuさん ⇒　H.Yさんへの質問 最近ハマっているものは？ ここ最近は Zwift やってます! H.H  自己紹介 QAグループでWebのQAを担当しています。拠点は大阪(OsakaTechLab)です。 前職でも同様にWebのQAをしておりました。(某宿泊予約サイト、某車買取サイト、などなど…) 所属チームの体制は？ QAグループ全体は12名で、自身が所属しているWebチームは5名体制です。 現場の雰囲気はどんな感じ？ どなたも優しく、質問もちょっとした雑談もしやすい雰囲気です。 KTCへ入社したときの入社動機や入社前後のギャップは？ 入社動機：テスト自動化やAI活用といった最新技術に触れたく、KTCには既に導入事例があったため。 入社前後のギャップ：毎週のようにITに関する勉強会やイベントが社内で開催されており、いい意味で驚きました。 オフィスで気に入っているところ 「Park」と呼ばれているオープンスペースがとても素敵です。 タイヤを使用したテーブル、車の形をした椅子、横断歩道がデザインされたマット、など細部までこだわりを感じます。 H.Yさん ⇒　H.Hさんへの質問 オフィス周辺（大阪）で、おすすめのお店おしえてください！ OsakaTechLabと同じビルの10階にある「浪花ろばた 頂鯛」というお店が近くて個人的におすすめです！ OsakaTechLabにいらっしゃった時はぜひ！ ばんぶー  自己紹介 新卒以来、ずっと福岡で働いてます。1社目ではガラケーの開発に始まりいろんなプロジェクトに携わってました。前職の銀行では、スクラムマスターやアジャイル浸透なんかをやってました。 過去、私が入社した直後に、リーマンショックやらコロナショックやらが起きてるので、投資家の皆様は警戒しておいてください(笑) 何事も楽しく、がモットーです！技術広報として(?)非公式につぶやいてますのでフォローお願いします！ ばんぶー@KINTOテクノロジーズ（@shell_in_bamboo）さん / X アイコンはAIに適当に指示しすぎて原形がなくなったものです。 所属チームの体制は？ 新たな拠点・Fukuoka Tech Labで立ち上げをしてます！上司の新田さんと2人でしたが、8月に新たなメンバーが加わってくれて盛り上がってます！今後も続々と増えるはず！ 技術広報も兼任していて、社内・社外のイベント活動やこのテックブログの運営などを学ばせてもらってます。前向きで活発なメンバーばかりで刺激をもらってます！ 現場の雰囲気はどんな感じ？ 福岡では3人で濃密な時間を過ごしています。和やかで、楽しい雰囲気で仕事してます。たまに出張者が来ると嬉しくてみんなでソワソワしてます。 技術広報は、みんな優しくてビビります。仕事も早いしビビります。ビビるって死語？ KTCへ入社したときの入社動機や入社前後のギャップは？ 入社動機は「天下のトヨタグループなのに圧倒的ベンチャー感」と「社長、副社長のメッセージやカジュアル面談で感じた組織文化」 入社後のギャップは「オフィスめっちゃいい・・・！」です。東京、名古屋、大阪のオフィスはめちゃくちゃオシャレで快適ですし、福岡は↓に記載のとおり。 オフィスで気に入っているところ 福岡オフィス内はまだお披露目できないんですが、窓からの眺めが最高！です。 H.Hさん ⇒　ばんぶーさんへの質問 Fukuoka Tech Labを今後どのような拠点にしていきたいか、目標や希望があれば教えてください！ まだまだ人数の少ない拠点なので、いい意味で実験や新しい取り組みができたらいいなと思ってます。他の拠点から知見を取り入れ、福岡で試したことを他拠点に展開し、相互作用を生んでKTCや地域に貢献できると嬉しいです。 youhei  自己紹介 入社以来 Fukuoka Tech Lab の立ち上げ責任者として奔走しています。 前職では開発組織のマネージャーをしていました。前職と前々職でも組織の立ち上げ期を経験しているので、その経験を今回も活かせればと考えています。 所属チームの体制は？ まったくのゼロベースから拠点の立ち上げに挑戦できる環境です。拠点所属のメンバーは現在３名で、採用も活発化していますしどんどん拡大していく予定です。 他の拠点のメンバーも福岡拠点の立ち上げに積極的に協力してくれるので、裁量を持って多くのプロジェクトを進行できる環境です。拠点間連携を深めることも今後していきたいですね。 現場の雰囲気はどんな感じ？ 立場上全ての拠点に行ったことがあり、それぞれの特徴を掴んだつもりです。そんな中で福岡の拠点は開放的で気兼ねなく会話できる雰囲気が最大の特徴ですね。出張者も普段の責任ある立場から少しリラックスしてオープンマインドで接してくれますね。少人数でも賑やかなところがとても良いのでこの空気を今後も大切にしたいです。 KTCへ入社したときの入社動機や入社前後のギャップは？ 今このタイミングで福岡に新しい開発拠点を立ち上げることに意義を感じたことが大きかったですね。トヨタグループの内製開発という大きな仕事を小さなチームで推進できることにKTCの可能性を感じました。詳しい話は 今度登壇するイベント で話す予定です。 入社して一番のギャップはこれまで在籍した企業で最も技術的にフラットな点です。特定の技術にロックインすることがないので、自分が無意識に制約していた箱の外にある技術も選択肢に入れて良いんだと自分のバイアスに気付けたのが良かったです。 オフィスで気に入っているところ 眺望ですね。自分の住む街の美しさを感じられます。福岡空港、博多と天神の市街地、博多湾、福岡タワー、眺めているだけで癒されますし、福岡という街をより好きになりました。 ばんぶーさん ⇒　youheiさんへの質問 趣味でPodcastを配信されてますが、もし誰でも呼べるとしたら、ゲストに誰を呼びたいですか？？理由も教えてください！ ご紹介ありがとうございます（笑）。 ほっとテック というPodcastを３年ほどやっています。ゲストを呼ぶ機会があって、いつもテック系の文脈でお声がけしてます。その制約をとって誰でも良いなら自分が好きなミュージシャンの誰かを呼んで彼らの創作に対する感謝を伝えられたら最高ですね。 K.S.  自己紹介 データ戦略部のデータサイエンティストです。これまで金融機関やコンサルティング会社で、クオンツやデータサイエンティストなど、定量分析の仕事をしてきました。 所属チームの体制は？ プロダクト開発、データアナリスト、データエンジニア、データサイエンスの4つのグループがあり、データサイエンスではKINTO事業部やトヨタグループからの依頼を受けてデータ探索やモデル開発を実施しています。 現場の雰囲気はどんな感じ？ グループごとに異なりますが、データサイエンスは自身で考えて動くことが求められます。事業寄りのグループほどよく話している印象です。 社内の雰囲気がフラットで、上席者が話を聞く姿勢で居てくれるためありがたいです。 KTCへ入社したときの入社動機や入社前後のギャップは？ KTCのクライアントにはしっかりとした事業があり、その成果にデータ分析で関われる環境があります。単に数字を分析して終わりではなく、その結果が事業にどう影響したかを実際に確認できると考えて入社しました。 会社の規模が少しずつ拡大しているので変化も多いですが、想定の範囲内でしたので、入社前後のギャップはないです。 オフィスで気に入っているところ 開放的なオフィスかつ、駅近で通勤しやすいです。リモートと出社を組み合わせた柔軟な働き方ができるのが気に入っています。 youheiさん ⇒　K.S.さんへの質問 モビリティの世界に来てこれまでの世界におけるデータサイエンスと比べて同じところ、違うところを一つずつ教えてください。 大きな違いは、位置情報やセンサー情報といった、これまで金融やコンサルではあまり扱わなかった種類のデータが豊富に存在することで、分析の視点や手法にも新しい発想が求められます。その未知のデータに触れること自体が、日々の知的好奇心を強く刺激してくれます。 一方で、データを正しく理解するためには、背景となる業務知識が欠かせないという点が同じです。数値や項目の意味を把握し、文脈と照らし合わせることで初めて価値ある示唆を導き出せる点は変わらないなと感じます。 さいごに みなさま、入社後の感想を教えてくださり、ありがとうございました！ KINTOテクノロジーズでは日々、新たなメンバーが増えています！ 今後もいろんな部署のいろんな方々の入社エントリが増えていきますので、楽しみにしていただけましたら幸いです。 そして、KINTO テクノロジーズでは、まだまださまざまな部署・職種で一緒に働ける仲間を募集しています！ 詳しくは こちら からご確認ください！

Introduction Hello! My name is Kameyama, and I'm a web engineer in the Project Promotion Group at KINTO Technologies. I'm currently studying frontend development. In modern web development, **component-oriented ** architecture has become the standard. By breaking the UI into reusable components, efficiency and maintainability can be improved. Web Components and Tailwind CSS are both powerful tools that support component-based frontend development. Web Components is a technology that's been gaining attention in recent years. It allows you to create reusable, encapsulated custom elements based on web standards. Tailwind CSS, on the other hand, is a CSS framework that offers fast UI styling through a utility-first approach. The recent release of Tailwind CSS v4 has brought even better performance, and it continues to receive active updates. At first glance, these technologies may seem like a good match. The idea of "encapsulated markup and logic per component (with Web Components)" combined with "easy styling with utility classes (with Tailwind CSS)" sounded ideal, I thought. But once I started developing, things wouldn't work out the way I expected. As I dug deeper, I found that the Shadow DOM , a core part of Web Components, and the styling mechanism of Tailwind CSS are fundamentally at odds with each other. In this article, I'll share what I've learned about why these two don't work well together, especially from the perspective of the Shadow DOM, and why combining them is generally discouraged. About Web Components What is Shadow DOM? First of all, Web Components are mainly made up of the following three technologies: Custom Elements: An API for defining your own HTML elements (e.g., <my-button> ) Shadow DOM: A technology that isolates (encapsulates) a component's internal DOM tree and styles from the outside world. HTML Templates: <template> and <slot> elements to hold reusable markup fragments Among these, the existence of Shadow DOM plays a key role in why Web Components and Tailwind CSS don't work well together. When you attach Shadow DOM to an element, that element becomes a Shadow Host and contains a hidden internal DOM tree called Shadow Tree . As a general rule, styles applied to elements inside a shadow tree are not affected by anything outside of it, such as the main document or a parent shadow tree. Likewise, styles defined outside the shadow tree generally won't apply to its internal elements either. This mechanism provides powerful style encapsulation , preventing a component's styles from being affected by external CSS and keeping internal styles from leaking outside. This helps ensure that your components won't break or look inconsistent, even in environments where multiple CSS design approaches are used. Here is an example of source code showing how the two are used together. class MyStyledComponent extends HTMLElement { constructor() { super(); // Shadow DOMをアタッチ（openモードで外部からアクセス可能に） const shadowRoot = this.attachShadow({ mode: 'open' }); // Shadow DOM内部のHTML構造 const template = document.createElement('template'); template.innerHTML = ` <div class="container mx-auto p-4 bg-blue-200"> // Tailwindクラスを使用 <p class="text-xl font-bold text-gray-800">Hello from Shadow DOM!</p> // Tailwindクラスを使用 <button class="bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded"> Click me </button> </div> `; shadowRoot.appendChild(template.content.cloneNode(true)); // ★ ここが問題 ★ Shadow DOM内部にスタイルを適用するには...？ // 外部のスタイルシートは原則届かない } } customElements.define('my-styled-component', MyStyledComponent); As shown in the example above, even if you use Tailwind classes like <div class="container mx-auto p-4 bg-blue-200"> inside the Shadow DOM of MyStyledComponent , those styles won't be applied by default. About Tailwind CSS Utility-First and Global CSS Tailwind CSS takes an approach to building UIs quickly by writing low-level utility classes such as flex , pt-4 , and text-blue-500 directly into HTML. During the build process, Tailwind scans your project's HTML, JavaScript, TypeScript files, etc. and generates CSS rules for any utility classes used. The generated CSS is typically output as a single global stylesheet , which is then loaded into the HTML document, often in the <head> . For example, if your HTML contains something like <div class="flex pt-4"> , Tailwind will generate the following CSS rules and include them in the global stylesheet: /* Tailwindによって生成されるCSS（の例） */ .flex { display: flex; } .pt-4 { padding-top: 1rem; } A key point about Tailwind's styling mechanism is that CSS rules are defined in the global scope . A Hopeless Incompatibility Shadow DOM Encapsulation vs. Tailwind's Global Styles Here's the crux of the problem. Shadow DOM encapsulates internal elements to prevent external styles from being applied to them. Tailwind CSS , on the other hand, generates CSS rules in the global scope based on the utility classes you use. There is a clear contradiction between the two. CSS rules like .flex { display: flex; } generated globally by Tailwind do not cross the Shadow DOM boundary to reach elements inside the Shadow Tree. In the earlier TypeScript example, the reason Tailwind styles do not apply to <div class="container mx-auto p-4 bg-blue-200"> is because the corresponding CSS rules exist outside the Shadow DOM, in the global scope of the main document. The Shadow DOM blocks those rules from being applied inside the component. A Note on Tailwind CSS v4: Tailwind CSS v4 boasts better performance thanks to a new engine. However, its core styling mechanism remains the same: it scans project files and generates global CSS based on the utility classes used. As a result, even with v4, the incompatibility with Shadow DOM remains unresolved. Is There Any Way Around This? While researching ways to solve this issue, I did come across a few possible workarounds. However, all of them either compromised the strengths of Web Components or Tailwind CSS, or required a high implementation cost. In the end, I couldn't find any solution that truly solves the problem. Still, here are some workarounds, even if they feel like desperate measures. Copy and Paste the Built Tailwind CSS into the Shadow DOM. This method involves manually or using a build tool to extract the CSS rules corresponding to the Tailwind classes used in each Web Component and embedding them as a <style> tag inside the component's Shadow DOM. Disadvantages: Very time-consuming and difficult to maintain Leads to duplicated CSS for each component, increasing file size The advantages of Tailwind's JIT compiler, which only generates the styles you use, cannot be fully utilized. Deviates from the Tailwind operational workflow, including config files and plugins Don't Use Shadow DOM This approach places elements in the Light DOM instead of using Shadow DOM in your Web Components. In this case, the elements are considered part of the main document's DOM tree, so global Tailwind styles are applied to them. Disadvantages: The biggest benefit of Web Components, which is style encapsulation, is lost in this case. As a result, external CSS may affect the component, and the component's styles may leak out as well, compromising the independence of the component. As you can see from these approaches, it is clear that the strong encapsulation provided by Shadow DOM and Tailwind CSS's reliance on global style sheets are basically different in design philosophy. Trying to combine the two tends to undermine the benefits of one or the other. Conclusion: Web Components and Tailwind CSS Should Not Be Used Together As we've seen, combining Web Components, especially when using Shadow DOM, with Tailwind CSS should generally be avoided since the advantages of each technology tend to cancel each other out. This is because the two technologies have fundamentally different approaches to styling, which end up clashing with each other . Web Components (Shadow DOM) are designed to completely encapsulate component styles and isolate them from the outside. Tailwind CSS , on the other hand, generates CSS corresponding to utility classes as a global stylesheet , assuming it will be applied across the entire page. Because of this, the convenient utility class styles generated by Tailwind cannot cross the strict boundaries of the Shadow DOM and therefore do not apply inside the component. Although there are workarounds, they often sacrifice component independence and increase development complexity. In many cases, these solutions become counterproductive. To maximize the benefits of each technology, it would be wise to avoid this combination. I hope this article serves as a useful reference for anyone considering combining Web Components and Tailwind CSS.

Hello! My name is Oka, and I work in recruitment for Osaka at KINTO Technologies Corporation. Our Osaka Tech Lab has recently moved to a new office. In this article, I'll take you behind the scenes and show you what's so great about the new office! What is Osaka Tech Lab? Osaka Tech Lab, located in Shinsaibashi, opened in 2022 as an engineering hub in western Japan. We recently moved to a building with direct access to JR Osaka Station, making our location even more convenient. Engineers from a variety of fields, including software development, cloud infrastructure, and data analysis, gather here to develop and improve our in-house products. "Osaka Tech Lab 2.0" Built Together by Everyone How the concept was born The office relocation marks the start of the "Osaka Tech Lab 2.0" project! This project wasn't something pre-planned by anyone. It all began with team members sharing ideas about what kind of space they wanted to create and we built it together. From this the concept came up: "Get Together! Spark Ideas! CO-LAB" "We didn't want just a place to work; we wanted a space that reflects Osaka's vibe and culture, and where we could co-create new value together." With that mindset, we reflected on our past activities and named it together as a team.  The "Who's in?" Culture Another phrase that naturally emerged at Osaka Tech Lab. That's "Who's in?" When someone has an idea or something they want to try, they simply speak up. Others respond with "Sounds good!" or "Let's do it together," and a group naturally forms around it. Such scenes are common around us here. We call this the "Who's in?" style.  In fact, the office relocation project followed this style. One person called out, and others came together to help build. Our new office is filled with that spirit. Now, let me show you a glimpse of what it looks like! Highlights of Our New Office!  The office floor is decorated with road-like lines that guide you toward the meeting room. **🛝 PARK Area | Take off your shoes and have a break **  We created a relaxing space where you can take off your shoes and unwind in comfort. It's the perfect for casual meetings or short breaks. It has already become a popular spot during our all-hands meetings, where everyone naturally gathers.  🚗 The names of the meeting rooms are also Osaka Tech Lab style The meeting rooms are named with themes inspired by garages and pits. Some of them even have uniquely Osaka-style names that tie in with mobility like "Motor Pool." *Motor Pool: A term commonly used in Osaka meaning "parking lot."  The name emerged naturally from casual conversation during repeated brainstorming sessions on Slack. We all had fun deciding on a name that suited us.  (And the final names were chosen through passionate discussions with a touch of Osaka humor!)  🛣️OSAKA JCT Like KINTO's Muromachi Office, a communication space called "OSAKA JCT" has also been created. The wall design is a creative piece that Osaka Tech Lab's designers are very proud of, having embodied a concept that everyone shaped together.  We planned and held the opening ceremony in the JCT space, using our "Who's in?" approach to form a volunteer-led committee. The relocation event itself was also led by team members, and we invited the managers and held an internal kickoff session. From start to finish, it was a fully handmade event, built by everyone.  We've received lots of feedback from members about the new office: I feel naturally more motivated to work. It's the kind of space that makes you sit up straighter. The shared space "PARK" has an open feel and is a comfortable place where even larger groups can gather naturally. Mobility-themed ideas can be found throughout the office. The area is filled with playful details, such as the names and signs of the locations, road-patterned flooring, tire-shaped tables, and even car-shaped mobile benches, making it exciting just to walk around. During interviews at the opening ceremony, many team members said things like, "It feels great to see our voices being reflected in the office," and "We feel a sense of attachment to this place as 'ours.'" What I Felt at Osaka Tech Lab To be honest, this atmosphere of "creating together" has been around since our previous office.  When we closed down that old space, we held a warm and casual farewell party. Everyone just showed up with drinks and toasted together. Regardless of department or title, people just gather together and before you knew it, a relaxed get-together had started. This kind of culture has taken root naturally at Osaka Tech Lab. As a recruiter, I believe that this closeness and the culture where everyone's voice is heard and valued are what make Osaka Tech Lab so appealing. Even now in the new office, that atmosphere hasn't changed. We hope that this will continue to be a place where people can casually chat about the future. Why don't we "Get Together! Spark Ideas! CO-LAB" Event Information At Osaka Tech Lab, we regularly host events where you can experience our culture. If our "Who's in?" culture resonates with you, we'd love for you to drop by. One of our core initiatives is CO-LAB Tech Night, an event where Osaka Tech Lab members share insights and know-how from their daily development work. CO-LAB Tech Night vol.1: Full in-house cloud development in Osaka! #1 Date and time: Thursday, July 10, 2025 / 19:00-21:30 Overview: Under the theme of cloud development, Osaka Tech Lab members will share their current initiatives and key insights on cloud infrastructure, SRE, and data analytics. Details: https://www.kinto-technologies.com/news/20250702 CO-LAB Tech Night vol.2 , Cloud Security Night #3 Date and time: Thursday, August 07, 2025 / 19:00-21:30 Overview: This event will focus on cloud security in multi-cloud environments, including AWS, Google Cloud, and Azure, and will deepen knowledge of cloud security through case studies from various companies. We're excited to bring the third "Cloud Security Night" to Osaka which is typically held in Tokyo! Details: https://www.kinto-technologies.com/news/20250709  **For the latest information, check the Osaka Tech Lab's special website! ** Osaka Tech Lab will continue to share information on a variety of topics, including engineering, cloud computing, and data analysis through events and the Tech Blog. Event information will be updated regularly on the Osaka Tech Lab special website. If you are interested, check out the event list (CO-LAB events)! ▼ Osaka Tech Lab special website here: https://www.kinto-technologies.com/company/osakatechlab/  (The Osaka Tech Lab special website was also born from our "Who's in?" culture) Launched alongside this article, the Osaka Tech Lab special website is yet another initiative that came to life through our "Who's in?" culture. It all started with members saying things like "We want to share more!" or "Let's show what Osaka really feels like." People naturally came together to plan, design, write, and launch the site by hand. We also collaborated with members from the Creative Office in Tokyo, making this a true CO-LAB effort and Osaka-style initiative. This special website is also packed with our unique culture. Come and take a look! Open for Casual Chats If you'd like to hear more about what Osaka Tech Lab is like, feel free to sign up using the link below! https://hrmos.co/pages/kinto-technologies/jobs/1859151978603163665

Introduction I’m Kai Yamamoto, a designer for my route by KINTO at KINTO Technologies. I mainly handle advertising design for my route by KINTO, including landing pages and banners, as well as organizing app screen flows and developing design guidelines. my route by KINTO is a multimodal mobility service that provides a complete set of travel features—all in one app—from searching and booking transportation to making payments. It also enhances urban mobility by offering information on event spots and local shops that help “bring the city to life.” Challenges to Solve Aiming to boost ticket sales and weekly usage, we worked together with representatives from Toyota Financial Services Corporation as part of our initiatives. my route by KINTO includes a content section called Feature Articles. Users are guided to these articles through in-app pop-ups, designed to encourage outings and increase app engagement. The design task this time was to improve the quality of the in-app pop-up. Creative Improvement Approaches "Improving creative quality" is a fairly vague goal, so we focused on narrowing the gap between the current state and the intended outcome. We started by identifying the issues, and from there, extracted three key challenges we needed to address in this design. Take an approach that fits the target audience. By building a shared understanding of the target user among the team, it became easier to make design decisions—such as choosing a color tone or adjusting corner roundness—that matched the user. Ensure consistency between the article and the design. As an extreme example, even if the pop-up has a stylish design, users might lose interest and exit without reading it if the article is about something like "going out to see autumn leaves and visiting a cute café." That's why it was important to read the article thoroughly beforehand and imagine expressions that aligned with the content. Deliver a sense of excitement that makes users want to go out. This may sound abstract, but unlike typical ads that highlight clear benefits like "Limited time offer!" or "Only 1000 yen!" this pop-up simply asks, "Why not go out and have some fun?" With that in mind, we focused on creating an excitement factor that would resonate when users saw the ad. Pop-Up Presentation Approaches In addition to design-related challenges, we also considered how to present the pop-up, as this was another important factor. We wanted to run A/B tests to identify the most effective presentation, so we explored several layer patterns. Pattern 1 had a strong advertising feel but tended to be effective when the content shown was relevant to the user. This approach was also seen in ad displays on major video platforms. Pattern 2 felt more friendly and thoughtful, as it included detailed descriptions. However, if the text was too long, users might lose interest. Pattern 3 was a versatile type, commonly seen in carrier pop-ups. We wondered whether it would be suitable for this particular campaign.We tried multiple approaches with these considerations in mind. Results As you can see, we explored various directions to upgrade the design. Three months after introducing weekly pop-ups, daily active users (DAU) increased by 1,100. While this figure also reflects the impact of other campaigns, the click-through rate for the pop-ups improved from 7 % to nearly 19 % each time, marking an 11 % increase. This positive result was certainly supported by the strong problem-solving efforts on the business side by the Toyota Financial Services team. However, I believe the key factor was the bi-weekly communication, which helped us deepen our shared understanding of the business goals, article content, and design direction. Future Challenges There is still room for improvement. Going forward, we aim to share this initiative with regional partners, deepen our understanding of effective advertising design, and develop design guidelines to maintain consistent quality. We will continue to refine our designs through the PDCA cycle.

開発生産性が優れたエンジニア組織を表彰する 「Findy Team+ Award 2025」 にて、KINTOテクノロジーズ（以下、KTC）を「Best Practice Award」に選出いただきました。 表彰式ではKTCの取り組みについて、ご紹介の時間もいただきました。 今回はその内容を中心に、KTCの「リリースファースト」の実現状況についてご紹介します。 リリースファースト推進と部署紹介 「リリースファースト」は、今年できたばかりのEngineering Officeという組織の活動の一環で推進しています。 Engineering Officeはいわゆる横断型のEnablingチームと呼ばれるような形でプロダクト開発に関わり、組織力・開発力向上に取り組むチームです。チームの詳細は以前「 KINTOテクノロジーズの開発組織を強くしたい Engineering Office のご紹介 」という記事でも紹介されていますので、ご覧ください。 今回受賞のテーマにもなっている「リリースファースト」は、2025年の展望として副社長の景山より発信された「 2024年の振り返りと2025年の展望 」で最初に触れられた、注力テーマの一つです。 リリースファースト （最短リリース） は、われわれが開発するプロダクトをいかに最短でリリースするか、知恵と技術を使ってここにこだわっていきたいと思っています。 （中略） 自分たちでプロダクトの価値について深く考え、最短リリースを実現することが内製開発部隊の強みであり、これが最大の事業貢献だと思っています。 来年は徹底的にこれを突き詰めていきます。 このメッセージを受け、現在は各プロダクトがリリースファーストの実現に向け、邁進している最中です。 Engineering Officeでは、開発生産性の観点を軸に各プロダクトの活動のサポートを行っています。 Findy Team+導入の状況とKTCの現状 Findy Team+は、KTCでは約20チーム／解析対象160人に導入されています（2025年8月現在）。Four Keysでの分析や定量的な現状把握が浸透しつつある状況で、チーム内で定期的な改善への話し合いを進められるチームが増えてきたところです。 改善活動が進み、Four Keysの向上も見られる中、リリースが早くなっている「実感がない」ことが次の課題となりました。 現状把握を行うために、 情報 × 思考 × 行動 のサイクルを粘り強く続けることが重要です。 （情報）Findy Team+を導入し、チームの現状を定量的に把握する （思考）収集した情報をもとにチームで話し合い、アイデアを出し合う （行動）アイデアをもとに行動を起こし、フィードバックを得る と並べてみると、一見できているように見受けられます。 それでも「実感」につながらないのはなぜか？ 情報×思考×行動サイクルを重ねることで、解像度は上がります。より解像度を上げるためには、 深さ：原因・要因・方法等を具体的に掘り下げる 広さ：考慮する原因・要因、アプローチの多様性 構造：「深さ」「広さ」で見えた要素を分類し、要素間の関係性等を把握する 時間：経時変化や因果関係、プロセスや流れを捉える​ という4つの観点を組み込むことが重要です。（この考え方は、馬田隆明氏著『解像度を上げる』​​で紹介されています。） https://eijipress.co.jp/products/2318 開発生産性の視点で分析し、「情報」の不足に起因し課題の解像度が低くなっている、という仮説を立てました。 Four Keys以外に指標がないこと Findy Team+に新しい機能（プロジェクト投資分析／プロジェクトアウトカム分析／プロジェクトプロセス分析）が提供されても、概ね計測ができない状況にある この2点を踏まえ、「情報の不足」が「思考」と「行動」の幅を狭めてしまっていると考えました。定量が不足しているならば、定性情報を増やす・獲得する行動を起こそうと、ケイパビリティ調査とValue Stream Mapping（以下VSM）に取り組みました。 ケイパビリティ調査 ケイパビリティがパフォーマンスに影響を与える、という調査結果がGoogle Cloudの DevOps Research and Assessment（DORA）チームから提供 されています。また、 技術・プロセス・組織文化の計27項目のケイパビリティも公開 されており、項目に沿って計測・評価することが可能です。 インタビューシートの作成 インタビューの実施 Engineering Officeによる分析とレポート という流れで実行しました。 このプロセスの中では、インタビュー形式の対話が特に重要となります。 アンケート形式で渡して回答を収集することもできますが、あえてインタビューにすることで「なぜその回答になったのか」「今の仕事の進め方」など、チームの現状について深掘りが可能です。 開発チーム自身も、インタビューを通じ観点を得て言語化することで、自分たちの現状を再認識することになります。 インタビュー実施後は、Engineering Officeで結果に対して分析を行います。そうすることでインタビュー結果やFour Keysが構造化され、より解像度を高められます。 ケイパビリティ調査と分析は、チームごとに行い、それぞれの現状の報告と改善提案を合わせてレポートしています。 ケイパビリティ調査後の行動 調査後は、技術カテゴリーやチーム単体でできるケイパビリティ強化・獲得の行動が、それぞれ着実に増えているように感じています。 一方で、チームを超えて取り組む必要があるところに関しては鈍化する傾向にあります。 ［バリューストリームでの作業の可視化］項で、「他のロール・チームの仕事の進め方についてはよくわからない」という意見が上がり、結果的に思考や行動も自分のチームの中に留まる、という傾向が見えました。 そこで、プロダクト全体でのVSMにチャレンジすることにしました。 Value Stream Mapping（VSM） Value Stream Mapping^[（引用）By DanielPenfield - Own work, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=28553995]とは、製品がユーザーに届くまでの「ものと仕事の流れ」を見える化する手法です。 各チームから数人ずつ参加して、現在のチームの「ものと仕事の流れ」を可視化します。 その後、開発チーム全体を集めてVSMの共有をして認識合わせをし、課題感や理想像についてのディスカッションを行います。その結果をインプットに、チーム体制の改善計画を立てていきます。 この取り組みで大事なのは全体での認識合わせと課題のディスカッションです。 全員が全体像を理解し、思考する。それが一人ひとりの行動変容につながります。 解像度の視点では、広さ・時間・深さ・構造ともに高まります。 VSM実行後の変化 VSMを受け、プロダクト全体でのチーム活動の改善計画・改革を絶賛実行しています。 曖昧だった役割、会議体、コミュニケーションを可視化し、新しい仕事の進め方に合わせて見直しました。また、拠点が分かれていたメンバーが1拠点に集結し、物理的なコミュニケーション強化も行いました。 さらにJIRA（Atlassian社開発のプロジェクト管理ツール）も、新しい仕事の進め方に合わせて改修を行っています。今後、Findy Team+で工程ごとのリードタイムが計測できるようになる見込みです。 試みのまとめと今後の課題 情報×思考×行動のサイクルを実行しても「実感」につながらないという現状解決に、 （情報）取得量を上げるため、Findy Team+の他にケイパビリティ調査、VSMを追加 （思考）Engineering Officeが収集した情報の分析サポートを行い、プロダクト全体で話し合いを実行 さまざまなロールの観点が合わさり思考を深めることにつながった （行動）チームを超え、プロダクト全体でリリースファーストを目指し行動を増やす という取り組みを行っています。 それでもまだ課題は残っています。 VSMで得た「新しい仕事の進め方」が本格的に始まるのはこれからです。フィードバックも得ながら、チームに定着するまでは継続的な議論と改善が必要となります。 また、ケイパビリティ調査やVSMは一定の効果が見えているものの、社内の他のチームへの展開はできていません。深く、広く、時間軸を考慮した情報を得る活動や、上手に思考する方法は、質の高い結果を得られます。分析・改善することで、他のチームの「リリースファースト」推進にも効果が見込めるので、順次展開を進める予定です。 発表スライドの全編は、Speaker Deckからご覧いただけます。 https://speakerdeck.com/kintotechdev

ご挨拶 こんにちは！KINTO FACTORYチーム、フロントエンジニアで二児の父の三上です。 今回は自分の在宅勤務のとある１日を紹介します。 同じ境遇のパパ・ママエンジニアの方へ「KTCではこんな働き方ができるんだ」というイメージを掴んでいただけると幸いです。 とある一日の流れ 時間 内容 07:00 起床 子供より少し早く起きて朝ごはん準備 07:30 子供の朝食 ~ 保育園送迎 パパとママで協力体制 08:00 在宅勤務開始 大体いつもチームで2番目に早いです。（1番早く出社するメンバーもパパ） 11:00 保育園から電話 次女、38度の発熱。 11:15 一度業務を中断してお迎えへ チームに連絡をし、保育園へ 11:45 業務再開 子供の様子を見つつ抱っこしながら 12:30 昼ご飯 この日のご飯はサクッと 14:00 ミーティング 抱っこ紐で抱えながらミーティング参加 15:00 子供の通院 またチームへ連絡して病院へ 16:00 業務再開 薬をもらったりで再開までに１時間 18:00 ママ & 長女帰宅 次女を託し集中モード 19:30 業務終了 お疲れ様でしたー この日は子供が熱を出してしまいお迎え+通院と色々盛りだくさんの１日でした。 見ていただけるとわかりますがKTCではこれだけフレキシブルな働き方が可能です！  KTCの働きやすい環境 フルフレックス制&ハイブリッドワーク KTCではフルフレックス制を採用しており、コアタイムがありません。子供の送り迎えや急な発熱などに合わせて、柔軟に勤務時間を調整できます。 この日も8時から勤務を開始し、子供の体調不良で一時中断しましたが、19:30まで働くことで必要な業務時間を確保できました。「9時〜18時」という固定的な勤務時間に縛られないため、家庭の事情に合わせた働き方が可能です。 また、ハイブリッドワークにより在宅勤務とオフィス勤務を選択できます。子供の体調が心配な日は在宅勤務を選択し、すぐに対応できる環境で仕事ができるのは大きな安心感につながっています。 パパ・ママ向けの制度充実 KTCでは育児休業制度や時短勤務制度はもちろん 看護休暇や家族手当制度など子育て世代をサポートする制度が充実しています ※最新の情報はコーポレートサイトの 福利厚生 をご確認ください 突発的な出来事への寛容な文化 この日のように子供の急な発熱でお迎えが必要になることは、子育て世代にとって避けられない出来事です。 KTCでは「家族優先」の文化が根付いており、チームメンバーに連絡すると「お大事に！」「子供さん優先で！」という温かい言葉が返ってきます。決して「会議があるのに...」「締切が...」というプレッシャーを感じることはありません。 また、急な離席があってもチーム全体でカバーし合う体制が整っています。普段からドキュメント化やペアプログラミングを推進しているため、誰かが急に離席しても業務が滞らないよう工夫しています。 私のチームメンバーの半数以上が子育て中のパパ・ママエンジニアです。お互いの状況を理解し合える環境があることも、働きやすさにつながっています。 まとめ 子育てをしながらエンジニアとして働くことは、時に大変なこともあります。しかし、KTCの柔軟な働き方と理解ある環境があれば、家族との時間を大切にしながらキャリアを積むことが可能です。 フルフレックス制、ハイブリッドワーク、充実した子育て支援制度、そして何より「家族優先」を理解してくれる文化。これらがKTCで働く大きな魅力です。 今後もチーム・会社全体でしっかりカバーし合える環境で子育てとエンジニアリングの両立を実践していきます！

Introduction My name is Iwamoto, and I lead the HR recruitment team in the CIO Office at KINTO Technologies. My career includes working as a hotel front desk staff member, as a career adviser and HR staff member at a foreign-owned dispatch agency, and as an HR staff member in a mega venture’s business division and also setting up the HR operations at a startup. I’m responsible for a wide range of HR-related work these days, too. I’m usually surrounded by four dogs and two cats, so I my everyday is a bit like Mutsugoro-san’s, the well-known Japanese animal lover. In this article, I’m going to introduce the HR Team. What Does the Team Do? The HR Team is involved in recruitment and organization building at KINTO Technologies, based on the values below. Specifically, the details are as follows. Recruitment This is mid-career recruitment of engineers and creators to lead the development work at KINTO Technologies. The organization had just under 160 employees when I joined it in November 2021, but as of December 1, 2022, that figure has grown to around 280. So, the number of employees has gone up by a factor of about 1.5 in around a year. Once again, let me thank all you employees for choosing to join the KINTO Technologies family! Going forward, we’re going to work on improving the recruitment experience, spreading information internally, and more, with the aim of becoming a company that other companies use as a reference for all things recruitment. Employee Interviews As a measure to gather information about the company's issues and make it a better organization, we have been conducting post-employment interviews, interviews with all employees, interviews with employees on leave, and interviews with employees leaving the company since February 2022. The company was only founded three years ago. Partly due to its rapid organizational expansion, it’s facing many challenges. What we’re doing is building up a picture of the actual situation through communication and interviews with employees, then planning and running activities like organizational development initiatives to create organizations that will be strong and appealing for both the company itself and for its employees, too. Of course, if you have any concerns, then please feel free to discuss them with us anytime and as often as you like, not just during interviews! :-) Management Training In cooperation with engineering education and training project members, we’re planning and running training for group managers. Updating Working Environments We’re also involved in creating environments that will enable employees to feel highly motivated as they work. We’re making a conscious effort to create experiences that will make working at KINTO Technologies fun. Examples include an office snack station where employees can buy food when feeling a little bit hungry, displaying TOYOTA miniature cars, and installing vending machines wrapped in a KINTO Technologies-themed design! Other Miscellaneousr Things Orientation support upon joining the company, and follow-ups afterward Cultivating culture and putting missions, visions, and values into words Support for engineering events And lots more. Anyway, we’re working hard every day to provide HR support—and sometimes even lead—for everyone working at KINTO Technologies, both carrying the balls we’re handed, and picking up ones that have been dropped, too! What Kinds of Members are There? Actually, until recently, I’d been doing the recruitment and organizational adjustment work all on my own. However, a team was launched with the addition of more members this April, and there are now seven of us including myself. Our respective areas of expertise are as below, but we don’t draw lines in the sand about anything (which is why we’re able to spot and pick up dropped balls), so we’re often working on multiple projects in a cross-disciplinary fashion. "Instead of thinking about what you can't do, think about how you can do it." "When someone is in trouble, think about how you can help them together." I feel that kind of mindset is well-rooted. They’re heartening members have on board! What Lies Ahead for the Team I want us to go on valuing the things the HR Team should cherish that I covered at the beginning of the article, and to aim to be a team that employees can rely on, and one that exceeds their expectations. I’d also like to start rolling out strategic measures to improve the company and its organizations, and from an HR perspective, I believe that KINTO Technologies is going to become an even more unique and interesting organization than it already is. So, I really hope you all watch this space.

Introduction and Summary Hi, I'm Iwamoto. Last month, I had the opportunity to write an introductory post as the group manager of the My route Development Group. As it happens, I also serve as the manager of the Mobile App Development Group. In this article, I'd like to introduce the group and share a bit about how I came to manage both. About the Mobile App Development Group What is the Mobile App Development Group? Formed in early 2022, the Mobile App Development Group is a relatively new team made up of engineers who, as the name implies, specialize in mobile app development. With pride as a mobile app development specialist, we take full ownership of all mobile app projects involving KINTO Technologies, transcending the boundaries between individual services. Basically, we create mobile apps in collaboration with the development groups in charge of each service (mainly those responsible for backend API development), but our involvement doesn't end at delivery. We stay actively involved in post-launch development and enhancements, working closely with each service group to take shared responsibility in driving the service forward. Our Journey So Far Let’s explore how the Mobile App Development Group was formed. The Early Days of KINTO Technologies KINTO Technologies has its roots in the development department of KINTO Corporation. At the time, the service primarily handled applications via the web and had no mobile app. So, the engineering team was made up almost entirely of web engineers, with very few members having any experience in mobile app development. my route Development Amid these circumstances, KINTO Technologies was assigned to develop my route , a MaaS app that originally began as a pilot project by Toyota Motor Corporation. At the time, My Route was being developed under contract by a partner company, and our first mission was to bring that development in-house. Although the in-house development of backend APIs progressed smoothly, mobile app development remained heavily reliant on partner companies for quite some time due to a shortage of specialized engineers. To turn things around, we gradually built up in-house expertise by reassigning engineers with mobile app experience and actively hiring new talent. By fall 2021, we had a solid internal foundation in place and were ready to kick off our in-house mobile app development project. Development of Apps Other Than my route As the mobile app engineering team within the My Route Development Group grew more capable, we started receiving an increasing number of inquiries about mobile app development from teams outside of My Route. By that time, KINTO Technologies had started handling several mobile apps besides my route. However, due to the ongoing shortage of mobile app engineers, much of the development work was still outsourced to partner companies. I wouldn't say that was the sole reason, but it's true that many of those projects faced challenges and didn't go very well. As we continued offering support and assisting with these external projects, our involvement in services beyond my route gradually increased, even though we were still technically part of the my route Development Group. The Birth of Mobile App Development Group Before we knew it, nearly half of our members were working on services other than my route. At that point, it no longer made sense from an organizational or operational perspective for us to remain a team within the my route Development Group. As a result, the Mobile App Development Group was established as an independent team in January 2022. We also considered embedding mobile app engineers directly into the development teams for each individual service. However, since the team had only just been formed—bringing together engineers with diverse backgrounds and skill sets—there were concerns that spreading them out too soon would make it difficult for KINTO Technologies to establish a consistent standard for mobile app development. This led to the decision to create a dedicated mobile app development group. Thanks to that, about a year later, we have established a number of development standards, and the group has grown into an organization of engineers capable of delivering high-quality mobile applications. Features of the Mobile App Development Group Team Composition As of the end of 2022, the group's size has grown to about 25 people. The number of Android and iOS engineers is roughly half and half, and some members are skilled in both platforms or have multi-platform experience using tools like Flutter and Unity. We also have a few members called "producers," who take on PM-like roles. Currently, our development work is centered on native apps, so the team is broadly divided into Android and iOS groups. However, we are considering reorganizing into service-based teams in the future. This would allow us to strengthen ties to each service and make better use of engineers who have the skills to work across both operating systems. International Diversity Compared to other groups, our team has a notably high ratio of non-Japanese members. In particular, around 80% of our Android specialists are global talent. Our group includes members from a wide range of countries, including Korea, China, Taiwan, Myanmar, Poland, and Germany, making for a truly international environment. Many of our members are fluent in English, but since English has not yet been adopted as the company's official language, all members are able to communicate in Japanese well enough to perform their daily work. With people from many different cultural backgrounds, the team enjoys a lively atmosphere and open, energetic communication on a daily basis. The communication style can feel much more direct compared to all-Japanese teams, which can be surprising at times. Even so, we aim to be an organization that embraces and enjoys these differences. What kind of People Work Here? When it comes to hiring, technical skills in mobile app development are a given. What we value even more is a strong interest in the field and a proactive mindset toward staying up to date with the latest trends. That's because the mobile app development landscape is constantly evolving, with new technologies and techniques emerging every day. Relying solely on existing knowledge quickly leads to obsolescence in such a fast-paced environment. As a result, the team is made up of members who are truly passionate about mobile app development. Many go beyond their daily work to improve their skills, and study sessions are held regularly. To Our Future Members If you're looking to grow as a mobile app specialist and want to work with the latest technologies, this is the perfect environment for you. Even if you don't have much hands-on experience yet, we warmly welcome those who bring passion and a willingness to learn. Let's work together to create mobile applications that support Toyota Group!

はじめに こんにちは。KINTO テクノロジーズで KINTO FACTORY (以下FACTORY) というサービスのバックエンド開発・運用をしているS.Itoです。 今回は、FACTORY開発チームで執筆祭りということで、私のとある一日を紹介したいと思います。 技術的な話というよりも、私の一日のスケジュールを中心に、KINTO FACTORY の BE チームの雰囲気を感じてもらえたらと思います。 KINTO FACTORY の BE 開発チームについて KINTO FACTORY の BE チームは、現在3名 + 協力会社さんで開発しています。 私以外の2名は大阪勤務で、私は東京で勤務をしています。 物理的に離れているため、バーチャルオフィスツールを活用してコミュニケーションをとっています。 最近では Devin や Claude Code などのAIツールも活用しつつ、日々開発を進めています。 一日のスケジュール 時間 内容 詳細 9:50 出社 エンジニアの朝は早い。 10:00 朝会 (全体) 全体の進捗や困りごとの共有、全体へのお知らせ事項の確認。 10:30 朝会 (BE) バーチャルオフィス上の会議室に集まり BE のメンバーで、状況の詳細な確認。設計の方針の相談などの込み入った話もあったり。  11:00 レビュータイム 生成AIツールを使い始めたことでPRの量が爆増。チームで時間を決めて一気にレビューを片付けます。 12:00 ランチ FACTORY開発Gのメンバーとオフィス近くでランチ。BE メンバー以外とも仲良しです。 13:00 開発タイム 生成AIツールを活用しつつ開発。相談事などはバーチャルオフィス上で話しかけて即解決。 随時 運用作業 データ抽出など運用作業。地味かもしれないけどサービスにとってはとても大事。 当番の時はリリース準備なども。 随時 問い合わせ対応 他チームからの問い合わせなどに対応。即レスを心がけます。 20:00 終業 一日の振り返り。翌日の予定を確認して帰宅。 それ以外にも 上記のスケジュール以外にも、月次での定例会議や振りかえりなども実施しています。 ときには大阪に出張して、直接会って話すこともあります。普段のオンライン上でのコミュニケーションでも困ったことはないですが、やはり直接会って話すのは良いものです。 BEチームの魅力 少人数で意思決定が早い バーチャルオフィス常時接続で即相談可能 出張でのリアルな交流も確保 新しいツールや働き方に積極的にチャレンジ 物理的な距離に関係なく、 「すぐ聞ける、すぐ助け合える」 のが私たちの強みです。 おわりに 今回は、私のとある一日を紹介しました。 KINTO FACTORY の BE チームは、少人数ながらも密にコミュニケーションを取りながら、日々サービスの開発・運用に取り組んでいます。 興味を持っていただけた方は、ぜひ KINTO テクノロジーズの採用情報もチェックしてみてください！ 最後まで読んでいただき、ありがとうございました。

Howdy from Osaka ( º∀º )/ My name is Yukachi from the Event Team on the Developer Relations Group. In July 2025, we finally got our long-awaited event space at the Osaka Tech Lab! This time, I would like to give you a quick and easy guide on how to get to our new venue, Osaka Tech Lab JCT !  The Osaka Tech Lab JCT has around 40 seating Address: 20th floor, North Gate Building, 3-1-3 Umeda, Kita-ku, Osaka City, Osaka 530-0001 JR Osaka Station: 2 minutes from either the Central Gate (1F) or the Bridge Gate (3F) Osaka Metro Umeda Station: 5 minutes from the North Gate Hankyu Railway Umeda Station: 7 minutes from the 2nd Floor Central Gate Hanshin Railway Umeda Station: 7 minutes via the connecting bridge The location is right next to LUCUA 1100. ** Look for signs that say LUCUA 1100 or Office Tower: that’s where you're headed! ** If you’re coming via Hankyu or Hanshin Railway, first make your way toward JR Osaka Station! [accessosaka1](/assets/blog/authors/uka/accessosaka/0.png =600x) *Use this as a landmark! *  From JR Osaka Station, exit the Central Gate or Bridge Gate and head to the Office Tower  From Osaka Metro Umeda Station, exit the North Gate and head toward the Office Tower  For those coming from the 1st floor, go this way  For those coming from the 3rd floor, go this way *  Take the escalator up to the 4th floor for connecting passage. It’s even quicker if you hop on from the 3rd floor!  Go straight ahead to the automatic door  Enter through the main entrance and turn right :::message **Please note that due to building security, the main entrance may be locked during certain hours. ** In that case, please contact us using the "information board with QR code" located at the front entrance! A staff member will come to escort you shortly. :::  Please take the nearest elevator to the 20th floor  KINTO Technologies is right in front of you after you get off the escalator! Welcome！ In Closing We hope you enjoy your time at the Osaka Tech Lab! Thank you so much for visiting! We look forward to seeing you again soon! (^_^)/

はじめに こんにちは。KINTOテクノロジーズで KINTO FACTORY サービスのQAを担当している遠藤です。 2025年5月から「インプロセスQA」として活動を始めました。今回は、QAの視点からFACTORYの開発風景をご紹介します。 このブログを通じて、FACTORYというサービスやKINTO全体の開発に、少しでも興味を持っていただけたら嬉しいです。 インプロセスQAとして開発チームに溶け込む - KINTO FACTORYの品質文化 インプロセスQAとは 「インプロセスQA」とは、開発チームの一員として日々の開発プロセスに参加し、その中で品質保証活動を行うQA（品質保証）エンジニアのことを指します。 従来のQAは、リリース直前に独立した立場でテストを行い、不具合を洗い出す「最後の砦」の役割を担ってきました。 一方、インプロセスQAでは、開発初期から仕様検討や設計レビューに関わり、早い段階で課題を発見・改善します。これにより、手戻りを減らし、品質と開発スピードの両立を実現します。 KINTO FACTORYでは、このインプロセスQAを2025年5月から導入しました。 まずは従来の最終QAプロセスを維持しつつ、開発チームの中に入り込み、「一緒に品質を作り込む」文化を育てています。 この取り組みにより、仕様段階から品質の視点を取り入れることができ、ユーザーにより安心して使っていただけるサービス提供を目指しています。 項目 従来QA インプロセスQA 関わるタイミング 開発後半（リリース前） 開発初期から継続的に 主な役割 最終テスト・不具合検出 仕様検討・設計レビュー・早期改善 メリット リリース前の品質担保 手戻り削減・品質とスピードの両立 関係性 開発と別組織的 開発チームの一員として活動 課題 後工程での不具合修正コストが高い 文化として根付くまで時間がかかる FACTORYの開発チームに加わる意味 これまでQAチームは、リリース直前に不具合を洗い出し、障害の防止や納期遵守、安定稼働に大きく貢献してきました。 その経験と知見を活かし、FACTORYチームでは、従来の最終QA工程を続けながら、少しずつ開発の前工程にも関わる取り組みを始めています。 今回はチーム内にQAが一人から参画し、まずは仕様検討や設計の場に顔を出し、早期に課題を共有できる環境づくりを進めています。 まだ加速的に進められる段階ではありませんが、日々のやり取りの中で開発とQAの距離を縮め、自然に協力し合える体制を目指しています。 こうした地道な取り組みが、やがては後工程の手戻り削減や品質向上につながると考えています。 では、この体制の中でどのようなQA作業を行っているのか、次の章で具体的にご紹介します。 FACTORYチームのQA作業とは？ 基本的には、従来の各サービスで行ってきたQA業務と大きな違いはありません。 主な作業内容は以下の通りです。 中・長期的な案件対応 短期的な改善対応 テスト自動化対応 中・長期案件対応 管理ツールの新規開発や、販売商流の新規追加に伴う機能開発では、短期間では終わらない丁寧な準備が欠かせません。 まず関係者と時間をかけて仕様を確認し、その内容をもとにテスト計画を練り上げます。 そして、仕様確認からテスト計画、実施までを数カ月かけて丁寧に進め、品質を確保したうえでリリースにつなげています。こうしたプロセスを踏むことで、リリース後のトラブルを防ぎ、安心して使っていただけるサービスを提供しています。 短期改善対応 画像の見栄えや一時的な表示変更など、軽微な修正や改善は1〜2週間程度で対応します。 着手前にはチケット内容の認識合わせを行い、必要に応じて3日ほどでQAを実施することもあります。 短期間であっても品質を犠牲にせず、ユーザーに素早く価値を届けられるよう心がけています。 テスト自動化対応 Autifyを活用し、2週間ごとのリリースサイクルに合わせて自動テストシナリオの追加・更新・メンテナンスを行っています。 これにより、繰り返し発生するテストを効率化しつつ、リリースごとの品質を安定的に確保しています。 将来的には、PlaywrightとAIを組み合わせ、エンジニアに依存せずQA主導でテストコードをメンテナンスできる仕組みづくりも進めています。 長期案件と短期案件の違い 項目 長期案件 短期案件 期間 数カ月 1〜2週間 対象 新サービス / 大規模開発 軽微なUI修正 / 表示改善 QA期間 約1カ月 約3日 主な課題 仕様の複雑さ、関係者調整 認識齟齬によるミス防止 QAとして意識していること 私の信念は、 「QA作業は開発スケジュールを阻害しない」 ということです。 時間と品質の両立を常に意識して取り組んでいます。 例えば、計画段階でリリース日から逆算して開発スケジュールを立て、QA期間を2週間と想定していたとします。 その後、見積もり依頼を受けた結果、実際には1カ月かかると判明した場合、QA作業を優先するとリリースが遅れます。 リリース遅延は、開発メンバーだけでなく、マーケティングや営業、経営陣、さらには利用を待っているお客様にも影響します。例えば、広告出稿やキャンペーンの開始日を合わせて準備していた場合、それらが無駄になったり、季節やイベントに合わせた需要のピークを逃したりします。さらに、競合他社が先に類似サービスをリリースすることで、市場での優位性やユーザー獲得のチャンスを失う可能性もあります。 このように、リリース時期の後ろ倒しは、関係者全員が予定していた成果を得られなくなるだけでなく、事業成長に直結する重要な機会を逃すリスクを伴います。 そのような場合は、関係者と再度確認を行い、 「適切なタイミングで」「必要な範囲のQAを」 行うことを提案します。 大事なのは、QAだけの都合でスケジュールを動かすことではありません。 まずはプロジェクト全体のゴールをはっきりさせて、そのゴールを叶えるために一番いい方法を、プロジェクトとして判断することが大切です。 もちろん、緊急で不具合や障害の改修が必要なときもあります。そんなときは、スケジュールを守りつつ、できるだけ早く対応します。 ただし、スピードを優先するあまり品質を犠牲にすることはありません。短期対応であっても、ユーザーが安心して使えるレベルまでしっかり仕上げてからリリースするのが基本姿勢です。 FACTORYチームの一員としてのQA 従来のQAに加え、FACTORYサービスに特化した新たな取り組みも進めています。 ここでは「シフトレフト」の考え方を取り入れています。 シフトレフトとは、テストや品質の確認をできるだけ開発の早い段階（＝左側）で行い、手戻りや修正コストを減らすアプローチのことです。 具体的には、 チケット起票段階からQAの観点を盛り込み 、開発メンバー側が手の回らない部分の品質もサポートできるよう、まずはできる範囲から早めに着手しています。 理想は、「痒いところに手が届くQA」。 開発だけでは見落としがちなポイントや、通常はQAが対応しない結合テストなど、品質面で不安が残る領域も積極的にカバーしていきます。 実際の作業風景 案件対応では、仕様資料をもとにテスト計画や観点をまとめます。 複雑な内容は事前説明を受けることもありますが、基本は資料をベースに進行します。 早期に仕様を理解し、開発メンバー側へ質問しながら進めることで、作業をスムーズに進行できます。 短期対応の場合は、変更点が明確なため、具体的なテストケースを作成し、認識違いがあれば即時修正します。 また、質問だけでなく、雑談レベルの不安も積極的にヒアリングします。 「申し込みできるか不安」「システム連携が正しくできているか」など、細かな不安も解消できるよう努めています。 開発メンバーの方々は、QAの質問や対応依頼など積極的にかつ前向きにとらえて実行してもらえています。 そのため、QA作業もスムーズに進行し、開発メンバー側との連携も良好です。 この環境に甘えることなく、QAとしてできることを常に考え、開発メンバーの皆様と一緒に品質向上に取り組んでいます。 これからの活動 Autifyに加え、これまで開発メンバー側主導で使用してきた Playwright を活用した自動化にも取り組みます。 AIを活用してテストコードをエンジニアに頼らずメンテナンスできるようにし、QAが主体的に改善・運用できる体制を整えていきます。 さらに、シフトレフトの推進やテスト範囲の拡大も計画中です。 上流工程での品質作り込み、結合テスト、データフローの確認などにも積極的に取り組み、開発メンバーとQAの連携をより強化していきます。 QAは品質の最後の砦であると同時に、開発メンバーの伴走者でもあります。 チーム内に加わったことで、これまで以上に早い段階から伴走者として関わり、 同じゴールを目指しながら品質を作り込み、必要な対応は即時に行えるよう日々取り組んでいます。 さいごに 今回は、FACTORYチームのQA活動についてご紹介しました。 チーム内の一体感や品質へのこだわりが、少しでも伝われば幸いです。 私自身、お客様視点とサービス視点を忘れず、開発メンバーと協力しながら、みなさまに笑顔になっていただける品質を追求していきます。 もし興味を持っていただけた方は、ぜひ 弊社の採用ページ もご覧ください。

はじめに こんにちは、KINTO FACTORYのバックエンドエンジニアをしている西田です。 今回は、7/24にYOUTRUSTさん×KINTOテクノロジーズで共催させていただいた「 関西エンジニアプライド、ここに集結。Tech Boost LT 」で登壇した「開発チームに生成AIを導入して変化したこと」について、発表内容を記事としてまとめてみました。 KINTO FACTORY で取り組んでいる生成AIの活用を知っていただくきっかけになれば幸いです。 KINTO FACTORYについて KINTO FACTORY は、「安心安全なカーライフを愛車で長く楽しめるアップグレードサービス」です。 従来の新車を売って終わりではなく、販売後もお客様の幸せを量産できるように、クルマを進化させ、クルマの一生に寄り添うライフタイムサービスの提供を目指しています。 チーム体制 開発チームの体制としては、エンジニアだけでなく、PdM（プロダクトマネージャー）、デザイナー、マネージャー、ディレクターなど多様なメンバーが協力し合いながら開発を進めています。 また、東京、大阪とそれぞれの拠点にメンバーが在籍していてリモートでコミュニケーションをとりながら開発しているのも特徴です。 開発チームで抱えていた課題 ローンチしてから、約2年が経過し、サービスが成長する中で、以下のような課題が表面化してきました。 限られたリソースでの開発 複数の案件を開発することでコンテキストスイッチ負荷の増大 技術負債の蓄積 組織の拡大を見据えつつ採用活動といった人材獲得を積極的に進めつつもすぐに改善できることでもないため、 この 限られたリソースでどう戦うか が重要になってきます。 なぜ開発チームに生成AIを導入したか ここからは、開発チームに生成AIを導入した理由についてお話しします。 前述の課題を解決するための期待値と会社の環境が揃ったことが、生成AI導入の大きな理由です。 期待 増加するタスクへの効率化 開発負荷の軽減 少人数でも戦える体制作り 環境 会社として今期の開発テーマに「 AIファースト 」を掲げており、AI活用の推進が積極的に行われていた これらの要素が揃ったことで、生成AIの導入を積極的に進めることができました。 生成AI導入の歩み これまでの生成AI導入の歩みを振り返ると、コードレビュー自動化から始まり、コーディング支援、タスク実行まで生成AIツールの進化によって対応領域を広げてきました。 2024年〜 PR-Agent : レビューの自動化 GitHub Copilot (Agent) : コーディング支援 2025年〜 Devin : リポジトリ横断的な調査や開発タスクの実行 Claude Code : より高度な思考力で設計、開発タスクを実行 Devinを使った活用事例 その中でも、特にDevinを使った運用事例として実際に起きたインシデント対応を紹介したいと思います。 インシデント対応 KINTO FACTORYではインシデントが発生した際にSlackで検知する仕組みを導入しています。 通常であれば、エンジニアが手動で調査を行い、修正を行う必要がありますが、今回はDevinを使って対応することにしました。 はじめに、Slackから通知されたエラー内容を元に、Devinに調査を依頼します。 調査結果から原因が特定できたらそのままコード修正も依頼します。 細かい修正もSlack上で行うことができます。 その後、PRを作成し、approveされるとDevinから通知を受け取りマージします。 調査、修正、PR管理までをDevinに任せることで、修正までの時間を大幅に短縮することができました。 今回の対応ではこれまで2日程度かかるところを、Devinを使うことで1日で対応できました。 Devinでタスク実行する前にやっていたこと Devinにタスク実行を依頼する前に、以下のような準備を行っていました。 Knowledge機能 デフォルトで設定しておきたいプロンプトを定義 呼び出し時にインプットされた状態でタスク実行できる Devin's Machine機能 開発環境のセットアップを事前に行うことでタスク実行時のwaitingが短縮される これらの機能を活用することで、Devinにタスク実行を依頼する際の準備がスムーズになり、実行までの時間を短縮することができました。 生成AI導入後の成果 KINTOテクノロジーズでは、生産性を可視化するためのツールとしてFindy Team+を導入しています。 今回、こちらのツール上でも生成AI導入前後で変化が起きていることが確認できました。 コミットからオープンまでの時間 の改善 生成AIによるPR作成数が増え、トータルの PR数も増加 デプロイ頻度 の改善 生成AIを導入することで、開発の効率化が進み、チーム全体の生産性が向上していることが数値としても確認できました。 学び 今回、生成AIの導入を進めることで、開発チームの生産性向上に大きく寄与しました。 特に以下の点が大きな学びとなりました。 定型作業の効率化 既存コードから挙動を横断的に調査（そのまま修正も） イメージ通りになるまでプロンプトを叩く → 技術負債の蓄積を減らす 一方で注意点もあります。 生成AIの提案を鵜呑みにすると想定しない挙動（バグ）が仕込まれることも コンテキスト不足だと的外れな改修（ハルシネーション）が発生する コンテキストの解像度を高めて、最後はヒトの目を通せる仕組みが重要 であることを実感しました。 まとめ 今回、生成AIツールを段階的に導入することで活用できる領域を広げ、 生産性向上の改善に繋げることができました。 生成AIは開発者を置き換えるのではなく、開発者をエンパワーする存在です。 限られたリソースで戦う開発チームにとって、生成AIは強力な味方になることを実感しています。 私たちの経験が、同じような課題を抱えるチームの参考になれば幸いです。

Hello! I'm Kasai from the SRE Team. KINTO Technologies Corporation (hereinafter referred to as KTC) will be a platinum sponsor of "SRE NEXT 2025" which will be held at TOC Ariake on Friday and Saturday, July 11 and 12, 2025. This will be KTC’s first time sponsoring SRE NEXT. Our SRE Team got a fresh start last year. While we face the daily challenges of practicing SRE, we continue to work on improving the reliability of our services. I’m sure many of you are also going through the similar process of trial and error. We decided to become a sponsor because we wanted to support a space where SREs can come together and connect. What is SRE NEXT? SRE NEXT is a conference for engineers with a strong interest in reliability practices. It is organized and hosted primarily by members of "SRE Lounge," another community-based SRE study group. The theme of SRE NEXT 2025 is "Talk NEXT." Building on the values introduced at SRE NEXT 2023— Diversity, Interactivity, and Empathy—the event will provide a space for discovering new insights through discussions and communication on a wide range of SRE-related topics, including technology, organizational design, and talent development. Home | SRE NEXT 2025 Event Overview Date: July 11 (Fri) and 12 (Sat), 2025 Venue: TOC Ariake and Online Official Website: https://sre-next.dev/2025/ There Will Be a Sponsored Session! On Day 2 (July 12), from 13:00 to 13:20 on Track B, Osanai will be holding a sponsored session titled: "What Does an SRE Do in a Role-Fragmented Organization?" In a fragmented organization where roles often overlap, questions naturally arise, such as "What should we be doing?" and "Where does the value of SRE lie?" This session will share how our SRE Team has faced and worked through questions like these. Details: https://sre-next.dev/2025/schedule/#slot081 We’ll Also Have a Booth! We’ll have a short and easy questionnaire available at our booth. If you participate, you can spin a gachapon machine for a chance to win original novelty items. Be sure to stop by and give it a try! Our SRE Team members will also be at the booth, so come and talk with us about SRE.

Hello, I am Maya from KINTO Technologies and today I’d like to quickly share a kaizen the Localization team implemented along with our Product Development team. Keeping internationalization (i18n) files aligned across systems is a challenge every growing product faces. For our team, revising the data of a specific project, together with the development team revealed how quickly inconsistencies can sneak in, and how painful manual fixes can be. The Problem When working across multiple GitHub repositories, both teams discovered a mismatch in one of the i18n files we were relying on for a product. We huddled together one day and created a problem framing grid to visualize the issue to product managers and team leads alike in the hopes to gain support (which we quickly did!) so we could work on implementing a solution. Category Details Who The Product Developers and Localization team What We found that i18n file data diverged between GitHub and Lokalise Where Issues were detected in both GitHub repositories and Lokalise projects When During cross-checking of all i18n files for a certain product project Why it matters ・Unnecessary or outdated data can accumulate. ・If left unresolved, the Single Source of Truth (SSOT) breaks down. ・Manual verification means going line by line, which is time-consuming and error-prone. The Impact By not having ways to detect data discrepancies, developers risk working with broken keys, outdated strings, or misaligned naming conventions. On the localization side, we sadly wasted effort working on content that did not exist in production. We learned the hard way that these misalignments may seem so small and harmless at the beginning, but if left unchecked, could end up creating and accumulating unnecessary data that clutters the files and leads to inefficiency. This can also contribute to higher costs and cause inconsistent user experiences in the long run. From Idea to Solution We needed a way to automatically keep track of i18n files, detect changes in GitHub as soon as they occurred, and have an alert that lets us know (the Localization side) so we could work on reconciling differences between GitHub and Lokalise before the files drifted too far apart. To achieve this, we built a GitHub Action that runs whenever a Pull Request (PR) touches any i18n file. The action inspects the files in the PR and, if changes are detected, sends an alert to a dedicated Slack channel. The Localization team is instantly notified and can decide whether a change is a legitimate key rename or removal, and whether the same update should be reflected in Lokalise. This small automation keeps development and localization in sync and sparks quick conversations before issues pile up. The following diagram illustrates how it works: 1. Repositories A to E each contain i18n files. 2. The GitHub Action monitors these files and triggers whenever a PR modifies one. 3. The Action sends an alert to a dedicated Slack channel we called #notice-localization-watcher. 4. The Localization team reviews and syncs updates with Lokalise if needed. The alert looks like this and is sent to me, the Localization team and the Product Development team we added to the channel: Benefits Using GitHub Actions to watch i18n files turned a tedious manual job into a simple, scalable process. It’s already making work smoother and saving both teams time and effort. We accomplished: • Faster detection of unnecessary data and avoiding surprises during cross-checks. • Cleaner data, keeping GitHub and Lokalise in sync as a Single Source of Truth. • Quicker team collaboration prompted by the alert, which allows us to do small check-ins via Slack between teams to check which data is needed and which isn't. Drawbacks & Next Steps Like any automation, it has its ups and downs. Although we haven't experienced it yet, frequent alerts could cause noise and fatigue, especially if every PR triggers a notification. Alerts also provide limited context as they flag that “something changed” but don’t show which keys were added, removed, or renamed at a glance unless you access the full PR. Without an even clearer way to define and maintain the source of truth, file drift can continue despite the above efforts. To improve, we plan to add diff snippets to alerts so changes are immediately visible, and filter to focus on meaningful updates like key additions, deletions, or renames. Another idea is to batch alerts into daily or weekly summaries to reduce noise. We’re excited to see how these refinements make it even smoother!

弊社の大阪オフィス「Osaka Tech Lab」が7月に引越ししました。（ 新オフィスの様子はこちらをチェック ）このオフィスでは「イノベーション・新しいもの・実験を加速させること」「Osaka Tech Lab発信のプロダクトをつくること」という目標がありました。その目標に賛同してくれる人を「この指と〜まれ」で集めて、どんどん巻き込んでいこうという動きが自主的に生まれ、東京支社にいるクリエイティブ室の私のもとへも依頼がきました。 大阪オフィスメンバーの熱い想いにクリエイティブ視点で叶えたい！私もこの一員として実現したい！と思い、微力ながらジョインすることに（やりたいことをやる、この柔軟性も魅力ですね）。 まずは、新オフィスが誕生する今、どうあるべきかを可視化するために、コンセプトをつくり、オフィスのインテリアや採用プロモーションにつながるストーリーをつくることにしました。タイトルは「Osaka Tech Lab2.0 STORY」。 「Osaka Tech Lab2.0 STORY」目的に向かうまでのストーリー そもそも、大阪にオフィスをつくった会社の思いからはじまる、目指すべき未来へのストーリーを社長や副社長にインタビュー。いつかの理想を叶えるために「いま、そのためにどうするのか、どんな場にするのか」という部分がこの新オフィスプロジェクトのコンセプトになってくると考えました。 こちらの軸を基本に、社内のどの人が見てもわかりやすい言葉にし、みなの意識統一のための合言葉（コンセプトワード）をつくりました。この辺りが出てくる頃には、週一の定例で大阪メンバーと東京在籍の制作陣もコミュニケーションをとっていたので、「めっちゃブレークスルーしようや！」という意識が生まれていて、ポロッと話した言葉がそのまま活かされるなど、やわらかい頭のなかを言葉にできる楽しい会議でわきあいあいとできました。（ワイワイやろうや〜というプロジェクトマネージャーに感謝） そして、生まれたコンセプトワードがこちら コンセプト企画書時点では、「Co-LAB」の表記でしたが「CO-LAB」とCompanyの略称ではなく、 幅広い意味をもたせるため「CO」と大文字にすることになりました。 集ゴウは、やってみようの意味をもたせて「GO」とし、発シンには様々な「シン」の意味をもたせたかったので「SHIN」としました。大阪オフィスのメンバーの気合いが入っているので、コンセプトという堅苦しいものではなく、あいことばとして使っていこう！となりました。 デザイナーやエンジニア、マネージャーなど、肩書きとはいっさい関係なく意見やアイデアを伝え、形にしていきたいという気持ちがこもった言葉になりました。 あいことばは決まった！つぎは、社内外の人が集まる空間の壁デザイン 大阪オフィスには、東京の室町オフィス同様、ジャンクションと呼ばれる空間があります。社内外の人が集まり、イノベーションを起こしていく場にしようという意味でつくられた空間に、横8400mm×高さ2500mmくらいの壁になにか意味のあるグラフィックを描こうというプランが生まれました。 はい、こちらが、その壁に描いたグラフィックになります。ずっとオフィスに残るものなのでクリエイターとしてはとてもやりがいのあるものになります。Osaka Tech Labに在籍しているデザイナーと東京にいるデザイナーとでアイデアを出し合い、生成AIを駆使しながら、Osaka Tech Lab所属のデザイナーが仕上げました。あいことばである、「集GO！発SHIN！CO-LAB」や、「めっちゃブレイクスルーしよう！」がつまったデザインです。 おもしろいデザインの仕掛けは次の機会に！ 次回、コンセプト「集GO！発SHIN！CO-LAB」から生まれたデザイナーのこだわりが詰まった壁や、 LP についての制作ストーリーを書いてみたいと思います。

Introduction Hello! I'm high-g ( @high_g_engineer ) from the New Car Subscription Development Group at the Osaka Tech Lab. In this article, I'd like to introduce the front-end study group that we started within the company. Background One day, I had the opportunity to show my supervisor the TSKaigi 2024 timetable during a one-on-one meeting in the New Vehicle Subscription Development Group. He responded positively, saying, "This covers a wide range of topics and is a great teaching material. It'd be great if we could use this to hold study sessions where front-end engineers across departments to share insights and build horizontal connections." Those words prompted me to reach out to front-end engineers who seemed eager to join, and I began planning an in-house study group. Purposes of the Study Group This study group has three goals: Learning : Deepen our understanding by discussing and sharing presentations from external conferences and web standards Applying : Take what we learn and put it to use in real projects Sharing : Share the outcomes, challenges, and insights from real-world applications to accumulate knowledge across the organization This is a practical study group that aims not to simply acquire knowledge, but to get to the point where we can actually use it on the job. We set aside a one-hour time slot once a week and conduct the sessions in a format appropriate to the content, such as read-along, mob programming, hands-on sessions. Main Themes and Development History Since September 30, 2024, 34 events have been held to date, and the following topics have been addressed: Sharing insights from conferences and tech events (Session 1 to 17) To get things rolling, we focused on the latest trends in front-end technologies using presentations from events like TSKaigi 2024 and JSConf JP 2024 as starting points. Thinking about the Future of Prettier (Session 1): The future direction of code formatters Improving TypeScript Performance (Session 2): Comparing with issues in actual business code **This is What Happened When We Unified Everything with TypeScript! ** (Session 3): A full-stack development case study TypeScript Journey: Helpfeel's journey of trials and errors on the road to success (Session 5) Type-Safe and Efficient Routing with TanStack Router (Session 7) ** Storybook-Driven Development: Reproducibility and Efficiency of UI Development ** (Session 9) Setting Trust Boundaries Instead of Blindly Relying on TypeScript Type Declarations (Session 10) LAPRAS Open Performance Tuning by Mizchi-san (Sessions 12-13): Performance improvement learned from external case studies ** Micro-Frontends on the Top Page of Yahoo! JAPAN** (Session 15): A development example from a large organization JavaScript Module Resolution Interoperability (Session 16) You Don't Know Figma Yet - Hacking Figma with JS (Session 17) Cross-Team Knowledge Sharing & Understanding (Sessions 18-24) As more people joined, we started sharing personal skills and the status of each division's front-end team. This helped shape the future direction of the study group and gave us a chance to review different projects at the code level. It also allowed us to identify common front-end challenges across KINTO Technologies. Looking Back So Far (Session 18): Discussing the direction of the study group Self-Introductions with Career Backgrounds (Session 19): Promoting mutual understanding among members Frontend Development Status Sharing Session for Each Team (Sessions 20-24): A five-session series in which each team shares their tech stack, ongoing challenges, and current initiatives in detail Understanding and Applying Web Standards (Sessions 25-28) At the retrospective session, some expressed interest in better understanding web specifications. Therefore, we decided to dive into the Baseline project together. https://web.dev/baseline?hl=ja Dive into Baseline (Sessions 25-27): A systematic study of web standards in a three-session series Baseline Review and Discussion of Next Steps (Session 28): Summarizing what we learned and discussing what to explore next Practical Performance Improvement (Sessions 29-Present) Using Mizchi-san's public performance tuning video as a reference, we began applying performance improvements to actual products. https://www.youtube.com/watch?v=j0MtGpJX81E ** FACTORY Performance Improvement** (Sessions 29-30): A two-session series sharing specific optimization strategies and the results TSKaigi 2025 Presentation Sharing Session (Session 31): Preview of presentation content by internal members ** KINTO ONE Performance Improvement** (Sessions 32-34): A three-session series where everyone worked on real performance improvements through mob programming, resulting in our most hands-on learning experience The Impact of Ongoing Sessions Increasing and Retaining Participants We kicked off the study group with just 5 members, but over time and with consistent sessions, it's grown into a group of over 10 regular members. Participants are not only from the New Vehicle Subscription Development Group but also from other groups, realizing horizontal connections. Many of the original members are still actively involved and the retention rate of new members is also high, proving that this study group has become a truly valuable space for everyone. Gradual Improvement of Organizational Technical Capabilities Knowledge gained from conferences and tech events often stays at the individual level, but by learning simultaneously with front-end engineers from each department who have different perspectives on issues, not only does it benefit the entire organization, but it also leads to insights that are hard to gain alone. Members who consistently took part in the Baseline series now understand web standards at a specification level, rather than just using the technology vaguely, which helps them make more well-founded decisions when choosing tools for their work. Acquiring Practical Problem-Solving Skills In the most recent sessions, we used a mob programming format to work on improving the performance of actual products such as KINTO ONE and KINTO FACTORY. By applying the knowledge gained in the workshop directly to the product and actually doing it, the participants were able to overcome their aversion to performance tuning. This was a practical and valuable initiative that also led to increased sales. Deepening Technical Collaboration Between Teams Through the development status sharing sessions, we've had more chances to learn about the technical efforts and challenges of other teams that we hadn't fully understood before. As a result, there's been a growing number of cases where teams with similar issues follow up individually after sessions to consult and collaborate. The study group is no longer just a place for learning; it's becoming a hub for solving real business challenges. Conclusion This study group, which was started with the aim of strengthening horizontal connections between front-end engineers within the company, began by sharing knowledge at external conferences and has now evolved into performance improvement based on actual products. We plan to keep it going, fostering collaboration while helping raise the overall technical proficiency of the organization.

はじめに こんにちは、2025年6月入社のemimです！ 本記事では、2025年6月入社のみなさまに入社直後の感想をお伺いし、まとめてみました。 KINTO テクノロジーズ（以下、KTC）に興味のある方、そして、今回参加下さったメンバーへの振り返りとして有益なコンテンツになればいいなと思います！ Jun 自己紹介 業務システム開発部 業務システムGで、中古車を扱う業務システムを担当しています。 前々職はSIerにて受託開発案件のPMをしたり、前職ではスタートアップでB2BのSaaSプロダクトの開発をしたりしていました。 所属チームの体制は？ 私が所属しているチームはKINTOで扱う中古車の業務で使うシステムの開発と運用を担当しています。 私が所属しているチームには私を含めKTCのメンバーが5人います。開発（プログラミング）の大半をパートナーさんに委託しており、KTCのメンバーは主にプロダクトマネージメント、プロジェクトマネージメント、要件定義、システム設計、運用保守を担当しています。 現場の雰囲気はどんな感じ？ 事業の拡大に合わせて常に業務とシステムの見直しが動いており、また、新しい技術の活用なども積極的に推進されていて飽きる暇がない雰囲気です。 現在担当しているシステムではバックエンドにはJava、フロントエンドはVue3を使っています。AIの活用はまだあまりできていないですが、GitHub CopilotやDevinを開発で活用しようとしています。 KTCへ入社したときの入社動機や入社前後のギャップは？ ITと事業が直結している会社にてシステム開発をしたくKTCへ入社しました。業務・システム運用を楽にするための開発にもっと時間を割きたいところですが、まだそこまで手が回っていません。 オフィスで気に入っているところ 日当たりが良いところに小さな休憩スペースと給茶機があり、いつもそこで昼食を食べています。特に豪華な設備があるわけではないですが、良い気分転換になります。 Sさん ⇒　Junさんへの質問 いろいろな車に乗りたいとおっしゃっていたので、今一番気になっている車とその理由を教えてください！ GRヤリスです。本格的なスポーツカーに乗ってみたいです。 なかの  自己紹介 DXソリューションGという販売店向けのDX支援を行うチームに所属しています。PdM業務や今後の計画業務などに携わっています。 所属チームの体制は？ PdM+デザイナーで8名で構成される、販売店DXプロダクトの設計やディレクションを担うチームです。 同部門中の営業や開発チームの方と連携してプロジェクトを進めます。 現場の雰囲気はどんな感じ？ 穏やか、優しい、シゴデキな方ばかり！ システム開発だけでなく、複雑な販売店業務への理解・興味をみなさんがもたれている事に驚きました。 KTCへ入社したときの入社動機や入社前後のギャップは？ 前職が広告代理店でITは事業の一部だったので、会社の軸がIT & 知見のある方が集まる会社で働きたい！と考えていました。入社後もそういう方々の集まりだ、という印象は変わりません！ オフィスで気に入っているところ Osaka Tech Lab所属で、自席から見える大阪一望の窓がめっちゃ気に入っています。（どの席からでも見える） 山も見えて、仕事の合間で癒やされる景色があるのはありがたい... Junさん ⇒　なかのさんへの質問 KTCに入社して、ここがすごい！と思ったことを1つ教えてください 🙇 前のめりでポジティブな方が多い所です！ 入社してから常に情報が動き続けていて、みなさん仕事、技術、拠点の成長、他色々…前のめりに取り組まれているんだなと感じます。（Osaka Tech Labの一体感はホントにすごい） Kazuki Otaka 自己紹介 6月にクラウドセキュリティグループにJOINした大高です！業務では、クラウドセキュリティ分野に携わっており、CSPMや脅威検知の仕組みを活用して、マルチクラウド環境のガードレール監視とカイゼン活動を行っています。過去にテックブログにも投稿していますので、ぜひご覧ください。（過去の投稿は、 こちら ） 所属チームの体制は？ Osaka Tech Labに2名と、神保町オフィスに1名の3名体制です。 現場の雰囲気はどんな感じ？ 落ち着いた印象で、フレンドリーな人が多い印象です。社内では勉強会やLT大会やBeer Bashなども頻繁に開催されています。技術力の高くプロフェッショナルな人もたくさんいるので、自分も置いていかれないように頑張りたいと思います！ KTCへ入社したときの入社動機や入社前後のギャップは？ 前職では、オンプレミス環境のシステムの構築に携わる機会が多く、クラウド環境を用いたシステム構築・運用のスキルを身につけたいと考え、フルクラウドでシステムを構築しているKINTOテクノロジーズに入社を決めました。AWSを中心にIaC化が進んでいたり、生成AIの検証・活用を進めていたり、想像していた以上にクラウドインフラ運用の最前線の環境にあると感じています。 オフィスで気に入っているところ 普段は静かで落ち着いた感じですが、突然、社内に機器が設置されて、PoC（概念実証）が始まるところなどは、新しいことにチャレンジしていく雰囲気が肌で感じられて意外と気に入っています。 なかのさん ⇒　Kazuki Otakaさんへの質問 セキュリティ界隈の仕事のおもしろさ、難しさを教えてください！ セキュリティは、被害が生じるとビジネスに大きな影響を与えるリスクがありますが、逆にセキュリティを高めすぎるとビジネスや開発を阻害する可能性があります。サイバー攻撃も進化する中で、いかにビジネスの成長を妨げずに、必要なセキュリティを実装・運用していくかのバランスが難しいところでもあり、逆に面白い部分でもあるかなと思っています。 ゆな  自己紹介 業務システム開発部 業務システムGで、販売店の方が利用する業務システムのチームに所属しているゆなです。現在は、販売店が商談時に利用するシステムのリニューアルプロジェクトを担当しています。 最近、KINTOで契約した車が納車され、毎週末ドライブへ出かけるのがすっかり趣味になりました。 所属チームの体制は？ 私含めてプロパー3人のチームです。リーダーともう一人のメンバーから日々サポートを受けながら、要件定義や保守運用に取り組んでいます。新しい知識やスキルを吸収しながら、着実に貢献していけるよう取り組んでいます。 現場の雰囲気はどんな感じ？ チーム内外問わず温かく迎え入れてくださって、とても良い雰囲気です。 KINTOの商品や業務は複雑で、把握すべき情報も多いですが、丁寧に教えていただきながらキャッチアップし、業務を進められています。 KTCへ入社したときの入社動機や入社前後のギャップは？ 前職に引き続き、プロダクトマネージャーとして入社しました。 自身のキャリアをさらに伸ばすため、「自分がプロダクトマネージャーとしてやりたいことを実現できそうか」という観点で会社を探し、KTCに出会いました。 面接では現マネージャーやリーダーの方とお話しし、具体的な業務内容を確認できたこと、また社員の皆さんの雰囲気が良かったことが決め手になりました。 入社前から、前職よりもテック寄りの領域に関わることは理解していましたが、業務が始まり、より高いスキルが必要だと実感し、現在は日々勉強しています。 オフィスで気に入っているところ 室町オフィスの16Fで働いています。三越前駅・新日本橋駅から地下直結でアクセスできるので、雨の日も快適です。 ビル内にはスタバがあり、周辺には飲食店やショップも多く、とても便利な環境です。昼休みに少し散歩をすると良い気分転換になり、午後の仕事もはかどります。 Kazuki Otakaさん ⇒　ゆなさんへの質問 趣味のお菓子作り・パン作りで、一番お気に入りのものはありますか？私もパンにハマっていた時期があり、学芸大学付近にあるパン屋さんに通っていました！ 夏らしく、旬のとうもろこしをたっぷりのせた「マヨコーンパン」を作るのが最近のお気に入りです。甘いとうもろこしとマヨネーズの香ばしさがふんわりしたパン生地にしみ込んで、焼き上がりを待つ時間も幸せになります。 emim  自己紹介 Engineering Officeという組織横断チームで、組織全体の開発力を高めるための分析や仕組みづくり、各部署やチームへの働きかけ等をデザイナー目線で行っています。 所属チームの体制は？ チームには私を含め3名しかおらず、一人はフロントエンド開発が本職ながら組織全体に目を向けているマネージャー、もう一人はソフトウェアプロセス改善を軸に開発生産性を見られています。私は開発組織の中でのデザイナーのプレゼンスを上げる為の様々な取り組みを行っています。 現場の雰囲気はどんな感じ？ Engineering Officeが極めて特殊で、それぞれが全く違うことに取り組んでいる一方で、拠点も一箇所なわけでもないのに情報共有及び連携がものすごくしっかりしています。少し特殊な技能を持ったメンバーが集まっているからこそな気がしています。 KTCへ入社したときの入社動機や入社前後のギャップは？ 元々クルマも好きだったのもありますが、モビリティ業界はとても遠いと考えていました。私がこれまで身につけてきたスキルを転用できる所があると気づき、応募しました。 入社前にかなり解像度の高い情報共有をチームメンバーからできていたので、そこまでギャップは持っていません。 オフィスで気に入っているところ 日本橋室町という立地自体が、毎日の出社がとても楽しいです。 ゆなさん ⇒　emimへの質問 映画やドラマがお好きとのことだったのですが、これまでに見た映画やドラマで、“デザインの仕事に活きた”作品はありますか？ 趣味を覚えててくださってありがとうございます！SFがとても好きで、見たことのないようなUIや端末が出てくるのに毎度ワクワクしています。デザインの道を選んだのも、あんな未知のデバイスのデザインがしたかったのがもとで、どんな情報端末でも正しく情報提供出来るような情報設計……という志向で、デザインについて学んでいる／向き合っているフシがあります。 Taka  自己紹介 n=1と統計のあわいで思考して戦略を作るのが生業だと思っています。目標達成のための定量データ分析とデプスインタビューが大好きで、ずっとやってられます。自分が人生において発露してきた重要な衝動は3つで、「Observe（観察する）」「Weave a story（物語を紡ぐ）」「Curate（再構成する）」です。 所属チームの体制は？ 事業会社（大企業〜スタートアップ）経験者と、優秀なデータアナリスト、優秀なエンジニアが所属しています。 現場の雰囲気はどんな感じ？ カルチャーとしては目標達成マインドを大事にしているチームです。前例にとらわれずに、自発的に問題解決を行って行く姿勢が重視されています。 KTCへ入社したときの入社動機や入社前後のギャップは？ 入社動機は、自動車業界が世界的に変革期にある今、重要なのはn=1起点のマーケティングだという仮説を持っており、それを実践し、変革を推進するため。 オフィスで気に入っているところ 室町オフィス16Fの大きな窓から入る明るい陽射しです。窓の周囲が大きなビルで囲まれていないから、大きな空と自然光を感じながら仕事ができるのを嬉しく思っています。 emim ⇒　Takaさんへの質問 これまでジョブチェンジされながら色々なお仕事をされてきたと伺っていますが、もしやり残した仕事があればそれを教えていただきたいのと、現在の（最高の）スキルを持った上でのKTCでの野望を教えてください！ そうですね、ジョブチェンジして来ましたが、実は軸は変わっていないと捉えていまして、やって来たことは「人と人とを繋げるためのデザイン」だと思っています。やり残したことは起業してないことです。野望は入社動機に書いた通りになります！ S  自己紹介 KINTO ONE（新車サブスクサービス）のフロントエンド開発を行うチームに所属しています 所属チームの体制は？ メンバー構成はエンジニア8名（東京6名、大阪1名、福岡1名）です 開発の体制はスクラム開発を採用しており、1スプリントを1週間として進めています 現場の雰囲気はどんな感じ？ 私は大阪所属で1人なので基本的にオンラインでのやり取りになりますが、気軽に質問もしやすく良い雰囲気の中で仕事ができています チャットで質問などをしてもすぐに返事が返ってくるので業務で困ることもありません KTCへ入社したときの入社動機や入社前後のギャップは？ 入社動機はモビリティ領域がこれからさらに発展していく分野だと考えており、その成長を支えるプロダクト開発に携わりたいと思ったからです 入社前にチームの状況などはしっかりと聞くことができていたので、ギャップはほとんどありませんでした オフィスで気に入っているところ やはり大阪駅直結で通勤しやすい・オフィスが広くて綺麗なところと、オフィス内にガレージや道路を模したところがあるのが面白いなと思います Takaさん ⇒　Sさんへの質問 Sさんが、ご自身ではとても好きなことや興味深いことなのに、人に話したら少し相手に引かれたエピソードがあれば教えてください。（そこにSさんの衝動が隠れていることがあります） 普段の食事で完全栄養食が準備に手間がかからず楽なので、いろんなメーカーのものを試しています。冷蔵庫の中もほとんどそれで埋まっているのですが、周りの人に話すと「考えられない」とよく言われます さいごに みなさま、入社後の感想を教えてくださり、ありがとうございました！ KINTOテクノロジーズでは日々、新たなメンバーが増えています！ 今後もいろんな部署のいろんな方々の入社エントリが増えていきますので、楽しみにしていただけましたら幸いです。 そして、KINTO テクノロジーズでは、まだまださまざまな部署・職種で一緒に働ける仲間を募集しています！ 詳しくは こちら からご確認ください！

Hello. My name is Momoi ( @momoitter ), and I’m a designer in the Creative Office at KINTO Technologies. In this article, I’ll walk through the process of using Midjourney V7’s new Omni-Reference feature to keep the look of the original character KTC AI WEB consistent. This article is for: Those who want to learn more about Omni-Reference in Midjourney V7 Those looking to generate character images with a consistent look Those interested in creating high-quality visuals using AI tools I’ll walk through how to use Omni-Reference, along with tips for fine-tuning, using actual prompts and generated images. What is Omni-Reference? In May 2025, a long-awaited feature called Omni-Reference was introduced in Midjourney V7. This feature allows you to generate new images while maintaining visual consistency by referencing a specific image. It is now possible to maintain characterization, which was previously difficult in V7, and it’s not limited to people; it works with objects and vehicles, too. There’s also a parameter called Omni Strength (ow), which lets you fine-tune how closely the output follows the reference image using numerical values. About "KTC AI WEB" What is KTC AI WEB? In November 2024, an AI-generated character named KTC AI WEB made her debut in the opening video of KINTO Technologies’ internal event CHO All-Hands Meeting. Since then, she’s served as a navigator, appearing at developer events and recruitment events to help introduce KINTO Technologies. Read the story behind KTC AI WEB’s creation here. https://blog.kinto-technologies.com/posts/2025-03-07-creating_a_mascot_with_generative_AI/ Why Unify Her Appearance? Since the birth of KTC AI WEB, image and video generative AIs have evolved rapidly. As a result, her original visuals started to feel a bit outdated. Shortly afterwards, Midjourney V7 and Runway Gen-4 were released, dramatically improving generation quality. We also decided to update KTC AI WEB’s visuals at this time. See the update process. https://blog.kinto-technologies.com/posts/2025-06-06-ai-character-movie-making/ However, while V7’s expressive power is extremely high, it didn’t initially offer a way to keep a character’s appearance consistent. KTC AI WEB’s face changed slightly with each generation. Furthermore, while the update improved quality, it came with a side effect—some of KTC AI WEB’s original approachable charm faded. Meanwhile, in May 2025, a new feature called Omni-Reference was added to Midjourney V7. I used this feature to reconstruct an "evolved KTC AI WEB" that combines the beauty and realism of V7 with the original character’s look and feel. Let’s Put it into Practice! Consulting ChatGPT To start, I asked ChatGPT the following: I want to upload an image to Midjourney V7’s Omni-Reference to generate a front-facing image of this pink-haired female character with a clean background while keeping her look consistent. Give me some prompts for Midjourney." ChatGPT responded with these prompts: upper body portrait of a female virtual operator in a clean futuristic interior, facing camera directly, symmetrical composition, looking straight ahead, centered, gentle expression, slightly relaxed face, subtle smile, brightly illuminated face, soft front lighting, high key lighting on the face, studio-style lighting setup, clear and vivid facial features, softly lit background, minimalistic sci-fi control room, white and silver tones, crisp details How to Use Omni-Reference Step 1: Drag and drop the image Drag the image you want to reference into the Midjourney prompt input box. A bar labeled Omni-Reference will appear at the top of the screen, drop it there. Step 2: Adjust Omni Strength (ow) Omni Strength allows you to adjust the strength of consistency (how closely the output matches the reference image). The numerical value is specified by the parameter called ow. Step 3: Start generating Enter the prompt you got from ChatGPT and start generating! Changes by "ow" values Low ow (e.g. 100-200): Less similar to the original image, but with Midjourney’s signature soft, beautiful rendering. High ow (e.g. 800-1000):Closer to the original image, but with less of Midjourney’s distinctive feel. ow100 ow200 ow400 ow600 ow800 ow1000 Finding the Right Balance After much trial and error, I found that setting ow between 200 and 400 worked best for updating KTC AI WEB. With these values, the output preserved her original features while still capturing Midjourney’s signature soft, beautiful rendering. At one point, "This is it!" I came across an image that felt just right. It was the ideal image capturing KTC AI WEB’s feature with Midjourney’s signature fine, delicate beauty. Expanding Scenes and Building a World Using the final image as a base, I expanded the composition and backgrounds using Omni-Reference. I also consulted ChatGPT again to get scene ideas and prompts for Midjourney. Having a solid base made it easier to build out a consistent world around her. The updated look for KTC AI WEB is also featured at the start of the company’s introduction video. https://www.youtube.com/watch?v=8Df_0StDAiw Application: Expanding to Other Internal Content KTC AI WEB was also featured in presentation materials for a recent internal study session. Thanks to Omni-Reference, there’s no need to stress over whether the visuals stay on-model, making it much easier to use her across slides, event visuals, and other materials. Tips Learned Through Practice Omni-Reference is a very powerful feature, but the reference can be too strong. Want to change the outfit -> Attach an image that only shows the face Want to change the hairstyle, too -> Focus on just the eyes or another minimal area Fine-tuning the reference range like these allows for consistent facial features while preserving Midjourney’s signature creative flexibility. Summary: A Time When Anyone Can Create "KTC AI WEB" The introduction of Omni-Reference has made it possible to create high-quality scenes while maintaining consistent character visuals. In other words, we’ve entered a time when anyone can create something like KTC AI WEB. It feels like a waste to keep her confined to my own imagination. That’s why I hope KTC AI WEB will continue to grow through the creativity of everyone in the company. I want to expand the range of expression and help her spread her wings even further. As AI technology continues to evolve, so will KTC AI WEB.

はじめに こんにちは。KINTOテクノロジーズ株式会社（以下、KTC）でプロダクトマネージャー（以下、PdM）をしているK.Ichinoseです。 「PdMって企画を考えるだけの仕事じゃないの？」 そんなイメージを持っている方も多いかもしれません。実際には、日々の業務は多岐にわたり、関わる人も多種多様です。 この記事では、私が担当している 「KINTO FACTORY」 のPdMとしての一日を通して、KTCのPdMのリアルな働き方をお伝えします。 読んだ後に、「PdMって面白そう！」「KTCで働くイメージが湧いた」と感じてもらえたら嬉しいです。 KTCにおけるPdMの役割とは？ 一般的にPdMは、プロダクトの方向性を定め、企画から開発、リリース、改善までをリードする役割です。 KTCの場合、 モビリティサービス に関するプロダクトを扱っています。 私はその中で、 KINTO FACTORY （以下、FACTORY）というサービスを担当しています。 FACTORYは、TOYOTA・LEXUS純正オプションを正規販売店で「後付け」ができるアップグレードサービスです。 これにより、購入後でも最新の機能やパーツを追加でき、クルマの価値や使い勝手を高められます。 私は「プロダクトマネジメントトライアングル」でいうところの開発者寄りの領域を主に担当し、ビジネスと開発者の橋渡しを担っています。 データ分析も最近始めています。 図はPdMの役割を「ビジネス」「顧客」「開発者」の3領域で表したものです。 具体的には、企画や要求をヒアリングして要件を整理し、開発スケジュールを組み、リリースまで推進します。 さらに、KTC全社で複数プロダクトを横断する開発案件では、社内調整や他チームとの連携も重要な仕事です。 PdMの一日の流れ ここでは、私の一日のスケジュール例をご紹介します。 （KTCはフルフレックス制ですが、私は毎日ほぼ同じ時間に始業しています。規則正しい方が集中できるタイプです） 時間 活動内容 09:30 始業・メールチェック Slackやメールを確認し、今日のタスクを整理します。 「誰に確認が必要か」「今日中に決めるべきことは何か」をこのタイミングで把握します。 10:00 朝会（デイリースクラム） 開発チームと進捗や課題を共有。 小さな課題でも早めに共有することで、後の大きな遅延を防ぎます。 10:30 開発チーム内レビュー PRD（プロダクト要求文書）やDesignDoc（設計ドキュメント）、その他仕様書のレビューを行います。 11:00 ビジネス担当(トヨタ or KINTO)と定例ミーティング FACTORY関連の新機能要件や仕様を確認します。 KTCからの提案や要望を伝えることもあります。 12:00 昼休憩 オフィス周辺でランチ(会社のある室町は少々お高め・・・)。 13:00 要件整理・提案資料作成 企画段階で受け取った要求を要件に落とし込み、エンジニアやデザイナーと共有できる形にまとめます。 15:00 開発案件の実現性、工数確認 エンジニアリーダーと要件をすり合わせ、実現方法や課題、必要工数を確認します。 ここで現実的なスケジュールを固めます。 16:00 社内全社PJの定例ミーティング 複数プロダクトにまたがる案件の進捗や課題、スケジュール調整を行います。 17:00 データ分析 利用データを分析してユーザー傾向を把握。改善のヒントを探ります。 随時 問い合わせ対応 KTC内の仕様や設計に関する質問、運用改善、テスト改善、リリース調整などを行います。 また、KINTO/トヨタからの新機能や、運用相談など多岐にわたります。 KTCのPdMとして働く魅力 モビリティ業界の未来に関われる クルマの価値を高める という新しい挑戦に直接関われます。 様々なステークホルダーとのコミュニケーション トヨタ、KINTO、社内外のさまざまな立場の方と関わり、異なる視点からの意見を聞けるのは刺激的です。 チームの雰囲気 役職や年齢に関係なく意見を言いやすく、議論も前向きです。 やりがい FACTORYはまだ世の中で認知度が高くない新しいサービスです。 その分、成長の余地が大きく、方向性に関わる仕事はサービスの成長をダイレクトに感じられます。 自分が関わった機能がリリースされ、実際にユーザーが申し込みしてくれる瞬間は大きな達成感があります。 これからKTCのPdMを目指す方へ 私が思うKTCで活躍できるPdMの条件は、次の3つです。 コミュニケーション力 関係者と信頼関係を築き、スムーズに情報をやり取りできる力。 柔軟さ 変化を前向きに受け入れ、改善につなげられる力。 プロダクトへの愛着 担当するプロダクトを深く理解し、こだわりを持てること。 特に3つ目は、仕様や細部へのこだわり、改善アイデアの源泉になります。 愛着を持つことでチーム全体のモチベーションにも良い影響を与えられます。 おわりに KTCのPdMは、変化の激しいモビリティ領域で、まだ新しいサービスをより良い形に育てていくやりがいのある仕事です。 この記事が、「PdMって面白そう！」と思うきっかけになれば嬉しいです。 もし興味を持っていただけたなら、ぜひ一緒にKTCで未来のモビリティをつくりましょう！