Introduction Hello! I’m Uehira from the DataOps Group in the Data Strategy Division at KINTO Technologies. I’m mainly responsible for the development, maintenance, and operation of our internal data analytics platform and an in-house AI-powered application called "cirro." "cirro" uses Amazon Bedrock for its AI capabilities, and we interact with it via the AWS Converse API. In this article, I’ll share how I tested Strands Agents in a local environment to explore tool integration and multi-agent functionality for potential use in "cirro." Intended Audience This article is intended for readers who have experience using Amazon Bedrock via the Converse API or Invoke Model API. What Is Strands Agents? Strands Agents is an open-source SDK for building AI agents, released on May 16, 2025, on the AWS Open Source Blog. The diagram below is from the official Amazon Web Services blog: As shown in the diagram, implementing an AI that can use tools requires a processing structure known as an Agentic Loop. This loop allows the AI to determine whether its response should go directly to the user or whether it should take further action using a tool. With Strands Agents, you can build AI agents that include this loop without needing to implement it manually. Source: Introducing Strands Agents – An Open-Source AI Agent SDK Running Strands Agents in a Local Environment *This section assumes that you have prior experience using Bedrock via the Converse API or similar tools. Therefore, basic setup steps such as configuring model permissions are omitted. Exception handling is also skipped, as this is a sample implementation. Setup Libraries Install the required libraries with the following command: pip install strands-agents strands-agents-tools Execution ① If you're lucky, the following minimal code might work: from strands import Agent agent = Agent() agent("こんにちは！") This code appears in many blog posts, but it didn't work in my environment. 😂 Which makes sense—after all, it doesn’t specify the model or the Bedrock region... Execution ② To call the model properly, you need to explicitly specify the model and region like this: In this example, we assume an environment similar to ours, where you log in via SSO and obtain permissions through a switch role. 【Point】 Make sure the model and region you specify are accessible with the assumed role. Example: Model: anthropic.claude-3-sonnet-20240229-v1:0 Region: us-east-1 *The region is specified in the profile when creating the session. import boto3 from strands import Agent from strands.models import BedrockModel if __name__ == "__main__": # セッション作成 session = boto3.Session(profile_name='<スイッチ先のロール>') # モデル設定 bedrock_model = BedrockModel( boto_session=session, model_id="us.amazon.nova-pro-v1:0", temperature=0.0, max_tokens=1024, top_p=0.1, top_k=1, # Trueにするとストリーミングで出力される。 # ストリーミングでツール利用がサポートされないモデルがあるため、OFF streaming=False ) # エージェントのインスタンスを作成 agent = Agent(model=bedrock_model) # 質問を投げる query = "こんにちは！" response = agent(query) print(response) Now you can call Bedrock with parameters like temperature, just like you would with the Converse API. 🙌 But if you're using Strands Agents, of course you'll want to call a tool ! Execution ③ If you define a tool as shown below, the agent will use the appropriate tool based on the question and return a response after executing the Agentic Loop. 【Point】 The function you want to use as a tool is decorated with "@tool". Tools are passed as a list of functions, like this: Agent(model=bedrock_model, tools=[get_time]) import boto3 from strands import Agent from strands.models import BedrockModel #------ツール用に読み込んだライブラリ------------ from strands import tool from datetime import datetime # ツールの定義 @tool(name="get_time", description="時刻を回答します。") def get_time() -> str: """ 現在の時刻を返すツール。 """ current_time = datetime.now().strftime("%Y-%m-%d %H:%M:%S") return f"現在の時刻は {current_time} です。" if __name__ == "__main__": # セッション作成 session = boto3.Session(profile_name='<スイッチ先のロール>') # モデル設定 bedrock_model = BedrockModel( boto_session=session, model_id="us.amazon.nova-pro-v1:0", temperature=0.0, max_tokens=1024, top_p=0.1, top_k=1, # Trueにするとストリーミングで出力される。 # ストリーミングでツール利用がサポートされないモデルがあるため、OFF streaming=False ) # ツールを使用するエージェントのインスタンスを作成 agent = Agent(model=bedrock_model, tools=[get_time]) # 質問を投げる。 ツールを使用しないとAIは時刻が判別できない。 query = "こんにちは！ 今何時？" response = agent(query) print(response) In my environment, I got the following response: <thinking> 現在の時刻を調べる必要があります。 そのためには、`get_time`ツールを使用します。 </thinking> Tool #1: get_time Hello! 現在の時刻は 2025-07-09 20:11:51 です。 Hello! 現在の時刻は 2025-07-09 20:11:51 です。 Advanced Use Regarding the tool, in the previous example, it simply returned logic-based output. However, if you create an agent within the tool and incorporate additional logic, such as having the agent verify a response, you can easily build a multi-agent system where one AI calls another. Here’s a modified version of the tool that returns not only the current time, but also a trivia fact provided by a child agent: 【Point】 We’re reusing the session object declared in the global scope under if __name__ == "__main__": . If you don't do this, model setup takes about a minute in my environment. This is probably due to the time required to allocate resources. @tool(name="get_time", description="現在日時と、日時にちなんだトリビアを回答します。") def get_time() -> str: """ 現在の時刻を返すツール。 注意：この関数では boto3.Session を使った BedrockModel の初期化に グローバルスコープで定義された `session` 変数が必要です。 `session` は `if __name__ == "__main__":` ブロックなどで事前に定義しておく必要があります。 """ current_time = datetime.now().strftime("%Y-%m-%d %H:%M:%S") # モデル設定 bedrock_model = BedrockModel( boto_session=session, model_id="us.anthropic.claude-sonnet-4-20250514-v1:0", temperature=0.0, max_tokens=1024, top_p=0.1, top_k=1, streaming=False ) agent = Agent(model=bedrock_model) # ここが子エージェントから回答を得る部分！ response = agent(f"現在の時刻は {current_time} です。 日時と日付にちなんだトリビアを1つ教えてください。") return f"現在の時刻は {current_time} です。{response}" Here’s the final response I got from the AI: Hello! The current time is 2025-07-10 18:51:23. Today is "Natto Day"! This commemorative day was established based on the wordplay "7 (na) 10 (to)." It was started in 1992 by the Kansai Natto Industry Cooperative Association to promote natto consumption in the Kansai region. Interestingly, while natto has long been popular in the Kanto region, many people in Kansai don't like it. This day was created in hopes of encouraging more people in Kansai to enjoy natto. Today, "Natto Day" is recognized nationwide, and many supermarkets offer special discounts on natto to celebrate. Since it's around dinner time, how about giving natto a try today? Notes While multi-agent systems are relatively easy to implement, in practice, calling multiple AIs increases both token usage and response time, which makes it tricky to decide when to use them. Below is a breakdown of the processing costs when using both a parent and a child agent: Category Parent Agent Child Agent Total Input Tokens 1086 54 1140 Output Tokens 256 219 475 Processing Time 7.2 sec 7.3 sec 14.5 sec As you can see, the overall processing time doubles when the child agent's response is included . For that reason, it may be more practical to limit multi-agent use to cases where output diversity is required or the task is too complex to handle with rule-based logic . Conclusion This time, in order to expand the AI utilization system "cirro" developed by the Data Strategy Division, I introduced the key points for running Strands Agents based on my testing. There were more unexpected pitfalls than I had anticipated, and I hope this article will be helpful when you try it out yourself. Using Strands Agents makes it easy to extend functionality with tools and child agents. At the same time, some challenges became apparent, such as increased processing time and token usage, as well as permission management when integrating with systems. The "cirro" system mentioned in this article is a completely serverless system developed in Python, and one of its key features is that users can flexibly expand tasks and reference data on their own. Currently, we are using it for dashboard guidance, survey analysis, and other internal applications. There is an introductory article on AWS about it, and I hope to share more details in the future! AWS Cirro Introduction Article

Hello everyone, I’m Mori from the Global Development Division and the Tech Blog team. I usually work as a web product manager (PdM) in the Global Development Division. I, along with several colleagues from my company, attended iOSDC Japan 2023 held from September 1 to 3, 2023! Since an iOS engineer who attended the iOSDC Japan 2023 will cover the content of the interesting sessions, I’ll share my impressions from an event management perspective😎 (#iwillblog is putting pressure on me lol) https://iosdc.jp/2023/ Reason for Participation Why did I participate in iOSDC even though I'm not an iOS engineer? In fact, recently the Tech Blog team has been supporting the operation of study sessions for external audiences and planning internal events. Recently, we have supported the operation of events such as the KINTO Technologies Meetup! hosted by the Corporate IT team and the DBRE Summit 2023 organized by the DBRE team. We are still a relatively new team, so even during planning and events, we are full of concerns like, “How can we make the participants enjoy more?” “How can we facilitate the event better?” 🤔 Hearing the rumor that iOSDC is incredibly exciting, I infiltrated the conference for three days to learn about its planning ideas and how to create such a lively atmosphere!! Our iOS engineers reported on the 2022 iOSDC, so please be sure to check it out as well 👍 https://blog.kinto-technologies.com/posts/2022-10-13-iosdc2022_participation_report/ Reception Upon entering the venue, we first checked in and received name cards. These cards contain QR codes and NFC chips for entrance and exit management. QR codes are used for managing entrance and exit at the venue, while NFC chips allow attendees to collect name badges via an app. This idea is great. I better take notes.📝 https://blog.iosdc.jp/2023/09/01/name-card-nfc-tag-exchange-2023/ In fact, on the second day, I completely forgot my name card, but even then, they smoothly gave me a new one, kindly saying, “You forgot your name badge.” I was impressed by their fine consideration. I better take notes.📝 Sessions The sessions were held across four rooms: two large and two small ones. Attendees were able to participate in the sessions they wanted. 🔻Venue layout: I listened to the talks on the second floor. The first floor was for booths for communication with sponsors. Drinks were available. I had confirmed the timetable for the day before the event, and I was impressed by how much effort went into deciding which talks to give at which times and in which rooms. With four rooms running sessions simultaneously, the time for each session would vary depending on its content, and the days the speakers could attend would also differ. This coordination skill is something I want to acquire. The title and speaker name of each session were read aloud via recording by Fumihiko Tachiki , a famous voice actor known for narrations in TV programs such as The Quest a.k.a. “Sekai no Hate Made Itte Q!” Both the audience and the speakers got excited🥳 Online Distribution By purchasing an on-site attendance ticket, attendees could also watch the sessions online. (There were also tickets available for online viewing only.) The online sessions were streamed via Niconico Live. I watched online the sessions I couldn't attend in person, and what surprised me was that they were streamed almost in real time! It may depend on the device or environment, but the time lags were probably less than five seconds. I was able to chat with on-site participants in real time via Slack. What was impressive was that, during the venue changeover, the streaming screen not only showed commercials from sponsors but also footage of the staff working during the preparation period. We also started hybrid streaming from the August event, so I was watching it while thinking that it might be interesting to stream something like this during the break in our next event. Lightning Talk (LT) Session Even before attending, I was curious about the schedule, which had six or seven 5-minute lightning talks. Since I also usually facilitate internal events and meetings, I was thinking, “Is it really possible to pull off this kind of agenda?” — but they did it!😂 First of all, I thought the most difficult thing would be to finish the presentation on time. Their ingenuity on this point is amazing…! When the 5-minute limit approached, music played to create a sense of urgency for each speaker, and the audience was instructed to wave penlights . It was a great idea to encourage the speakers while ensuring they stick to their allotted time. Plus, it’s fun for those waving penlights…! (It was a production style different from last year.) *They cheered for the speakers with penlights in their signature colors. * To ensure each 5-minute speech proceeded smoothly, no time was allocated for Q&A; instead, a system was set up for attendees to approach the speakers later at other booths. The only preparation needed between speakers was setting up their presentation materials. During this time, the audience are informed of the next speaker’s “signature color” so that they can prepare their penlights accordingly. Of course, that alone would have left some extra time, so the emcee skillfully introduced booths and shared behind-the-scenes stories about the speakers, making the waiting time feel short for the audience. 👏 Of course, the production was great, but this Lightning Talk (LT) Session was also very interesting in terms of content. Since the session was supposed to be cut off after five minutes, it was impressive to see how each speaker came up with creative ways to summarize it. While some speakers probably didn't get to say everything they wanted to say, their time management skills were impressive, and it didn't really feel that way from the audience. I think most people who have experience with presentations or speeches would feel that it’s incredibly difficult to concisely summarize what they want to say in a short time. 😭 I myself tend to talk at length because I’m quite chatty. Structuring a talk with a clear beginning, middle, and end—while also adding a touch of humor—makes this kind of event an incredibly valuable opportunity for a great presentation! Also, giving a short presentation helps sharpen time management skills. Watching them glance at the remaining time and instantly decide things like “I’ll cut this part,” all while effectively conveying their main points, made me think, “They must also be really good at facilitation.” As the Tech Blog team also aims to improve the employees’ output skills, I’d like to incorporate opportunities like this within the company as well.😎✨ Tech blog members enjoying penlights Doing What I Want to Do = Maybe Everyone Will Have Fun…!? This is my simple impression from attending iOSDC, but overall, it was a very meaningful conference even for non-engineers like me. Of course, I don’t understand technical details, but my desire to improve our company’s products is the same as that of the engineers. I participated to learn about event management, but from a PdM perspective, I also realized, “So this is what engineers are thinking,” and thought, “If we incorporate these ideas into our products, they might improve even more!” From the perspective of my original purpose—event management—it was an extremely valuable conference. 🤩 During the social gathering, I fortunately had the opportunity to talk with Mr. Hasegawa , the chairperson of the executive committee. When I asked him about overall event planning and efforts to make an event exciting, he said, “I’m just embodying what I want to do myself.” I thought, this is really a profound truth. Even now, after the event has ended, it really resonates with me. Before participating, I was worried about “How could I make everyone enjoy our event?” but then I came up with a new idea: “If I try doing what I find interesting, maybe everyone else will enjoy it too.” Of course, whether it resonates with the audience or not is another matter, but gaining this new perspective has ignited my passion to plan and manage various events going forward. 🔥🔥🔥 At KINTO Technologies, we will continue planning events for external audiences. We will provide information as needed through Connpass (in Japanese) and other channels, so please feel free to join if you’re interested. ✨

1. Event Overview The fifth SRE NEXT event was held on July 11 and 12, 2025. As a platinum sponsor, our company exhibited at a corporate booth and spoke at a sponsored session. In addition to the many fantastic sessions, we were able to interact with many people at the sponsor booths and book corner, making these two days extremely valuable. This article features a roundtable discussion with KINTO Technologies members reflecting on their first time exhibiting at the event. 2. KINTO Technologies and SRE 2-1. What Kind of Organization Is It? KINTO Technologies is the Toyota Group's first in-house development organization and is responsible for the development, maintenance, and operation of systems for consumer mobility services, including the car subscription service KINTO. As of July 2025, the company employs approximately 400 engineers, designers, product managers, and other professionals, developing services for both internal and external users. Within this organization, the SRE Team is part of the platform group and works with product teams to maintain and enhance system reliability while supporting developers. 2-2. Current State of SRE As Osanai announced during the sponsor session on the day, KINTO Technologies has a well-developed cross-functional organization, with multiple teams sharing many of the responsibilities that would normally be handled by platform SREs at many companies, including cloud infrastructure engineers, DBRE, platform engineering, a security specialist team, and a team that works with CCoE and finance. Here is the presentation material from the day 👉 What Does SRE Do in an Organization with Segmented Roles? - Speaker Deck Two engineers promoting the practice of SREing are working closely with product development teams to implement best practices. Although they face challenges in linking service levels to business metrics and development processes, as well as difficulties applying platform patterns within team topologies, they continue to experiment and refine how to best deliver value. 2-3. Motivation for Exhibition KINTO Technologies launched a Developer Relations Group in 2022, and in 2023 elevated it into a Tech Blog "group" to enhance its communication efforts. In 2024, the company began sponsoring conferences. Recently, its CEO, Kotera, spoke at the Development Productivity Conference. The company has also sponsored conferences across various fields, supporting the engineering community. I believe the appeal of this community lies in conferences where engineers can communicate directly with one another, and I am glad to be part of this opportunity. KTC’s SRE Team is small and currently in a growth phase. We decided to hold a sponsored session, first to raise awareness of the SRE Team's presence, and then to share our unique challenges and efforts within KTC’s segmented-role environment, hoping they could serve as a reference for others facing similar issues. 3. Activities on the Day 3-1. Booth Operation We asked visitors to write on sticky notes under the theme “What’s Your ‘NEXT’?” Those who participated got to spin a gacha-gacha capsule toy machine and receive a novelty gift. We offered KINTO's mascot character Kumobii plush toys (large and small) and Toyota Tomica cars as novelties, which were very well received by everyone. Novelties Offered at the Sponsor Booth In just one day of operating the booth, we received so many "NEXT" ideas that the board was completely filled. It allowed us to experience this year's theme, "Talk Next," together with the participants. Many visitors wrote down their various "NEXT" ideas 3-2. Presentation As a sponsored session by our company, Osanai from the SRE Team gave a presentation titled "What Does an SRE Do in a Role-Fragmented Organization?” As this was his first time presenting at an external event, he seemed very nervous, but despite worrying daily, thanks to his hard work and diligent efforts, he was able to deliver a presentation he was satisfied with. Osanai keyed up at his first external presentation He was very nervous about what kind of reaction he would get after taking the stage, but luckily many people came to the Ask the Speaker session, and he was able to have fun talking to them, including some behind-the-scenes stories that he couldn't fit into the 20-minute presentation! A photo from Ask the Speaker 3-3. New Learning Our company has many young engineers, and many of our members are not used to participating in external events. This event provided many inspiring experiences for our young engineers and served as a very valuable opportunity to interact with renowned engineers, including Brendan Gregg, author of "System Performance." A young engineer thrilled to take a photo with Brendan Gregg Furthermore, many young engineers who began their careers in cloud engineering lacked knowledge of the technologies behind physical networks. At the venue, however, they had the chance to receive clear explanations about the roles of devices like routers and switches—an experience that directly enhanced their technical proficiency. Cloud engineers unfamiliar with physical networks being taught about routers and switches 3-4. Interactions with Participants As a sponsor, we participated with the goal of raising awareness of KINTO and KINTO Technologies among a broad audience. More than anything, the greatest benefit was the inspiration and learning we gained through our interactions with other participants. Organizing members chatting with visitors 4. Roundtable Discussion among Participating Members The organizing members, who had such an enjoyable two days, held a roundtable discussion to reflect on the event. SRE: Osanai and Kasai / Cloud Infrastructure: Kossy and Shirai / TDeveloper Relations Group : Yukachi Organizing members having a round-table discussion in the office 4-1. What Is the Most Memorable Thing? Kasai: “I was at the booth the whole time, so I couldn’t attend the sessions, but I spoke with several people who visited the booth, and I was struck by how many of them were struggling with how to incorporate generative AI into their SRE work.” Osanai: "I was really happy that there were people who were interested in my presentation and came to listen to it. Afterwards, some people came to talk to me directly at the Ask the Speaker event, and I was really grateful for that.” Shirai: "The biggest thing was the passion of all the participants to make the event a success. Since the theme was Talk Next, I really liked how everyone was sharing their know-how and speaking with mutual respect. I'm grateful to the organizing members for creating SRE NEXT, and I would love to participate as a member of the organizing team if I get the chance." Kossy: "What impressed me the most was the enthusiasm of the community. Some people listened to the sessions with deep focus, while others seemed to enjoy lively interactions in different places. I felt it was a really great space for people who struggle with the same themes in their daily work to share their experiences." Yukachi: "I think what stood out was the high level of communication skills of everyone who helped with the event! Each person's personality shone through, and it was great to see them enjoying themselves while working at the booth. I want everyone to check out the highlights I posted on X (lol)."  4-2. How Was Your First External Presentation? Interviewee: Osanai-san Osanai: "The last time I presented in front of people was probably at a piano recital in elementary school... (lol)." Kossy: “What motivated you to take the stage this time? Did you have something particular you wanted to share with everyone?” Osanai: My main motivation at first was to raise awareness about KTC's SRE Team. So I started thinking about what I should talk about to achieve that, but when we got the sponsorship, nothing really stood out to me as “this is it!” Still, once I knew I’d be speaking, I wanted to share something that would resonate with the audience. That’s when ideas like the improvement tools I mentioned in the presentation started to emerge, and from there, the outline gradually took shape. Once that was decided, I started gathering additional information to fill in the gaps in what I wanted to talk about, while also connecting it with the things I had done up to that point. The opportunity to speak gave me some idea of what lies ahead for us and helped me grow so much.” Kossy: "At the booth, many people said that KTC's presentation was great. What kind of questions did you receive during the Ask the Speaker session?" Osanai: "We discussed various topics, including how the New Relic Analyzer I mentioned in the presentation works, and efforts to improve the accuracy of Devin's suggestions. We also talked about challenges raised by the attendees." A person I used to work with also came by, and we had a great time reminiscing about those days and catching up on each other's current lives.” Kossy: "There were questions from participants from companies struggling in similar areas, such as how we approach obstacles that prevent us from taking action." Osanai: "That's right. I realized that everyone has similar challenges." Yukachi: "By the way, the person who was sitting next to me during the presentation turned out to be someone who had visited the booth on the first day. After the presentation, I spoke with that person and found out that this person lives in Fukuoka, and that a Fukuoka office opened in July. From that conversation, I was able to invite the person to an event to be held in Fukuoka." I was really happy that the person became interested in our company because of Osanai-san's presentation!” Osanai: “Two days after SRE NEXT, some candidates came for interviews, so I think the presentation helped them better understand KTC.” Kossy: "It was your first time speaking at an external presentation, so you must have been nervous, but was there anything in particular that you hadn't anticipated or hadn't imagined?" Osanai: "In fact I expected to be so nervous that I wouldn't be able to eat anything for a few days before the event, but surprisingly, I wasn't that nervous. I realized I could eat quite well after all." Yukachi: "I think it’s because it was your first time, and you prepared thoroughly." Osanai: "That may be true. Surprisingly, I could see you all clearly from the stage and I even made eye contact with Kumobii on Kossy-san’s headband, making me speak in a relaxed way." However, when I saw the photo, I had a really stern look on my face, and I thought, "Wow, that's what I looked like... (lol)" Kossy: "Right before the presentation, your eyes were really bloodshot." I honestly thought Osanai-san would be able to speak just fine, but with everyone hyping it up, he seemed a bit nervous, and right before it started I found myself getting nervous too (laughs). But surprisingly, he was really steady, and the content of his talk had a lot of things that were valuable for us as the neighboring team—like, ‘wow, that approach is amazing. Yukachi: "One thing I regretted that day was not giving Osanai-san a pat on the back before the presentation (lol). I wouldn’t worry if it were Kossy-san or Shirai-kun speaking, but since it was Osanai-san’s first external presentation, and his face looked so tense, I was really worried (lol). But once he started, he was solid, and honestly, I was kind of moved (lol)." Kossy: "All in all, it was a success!" Osanai: "The next task will be managing my facial expressions (lol)." 4-3. Talk Next — What's Next? Kasai: "Right now, I'm working on an improvement tool, and I definitely want to see it through. I think the process will give me even more to talk about, so I'd love to share that externally as well." Osanai: "I personally want to improve the quality of our improvement tools and the accuracy of their suggestions. But these tools won’t get anywhere unless people are actually interested in using them. So while continuing development, I also want to promote them to different product teams. We also concluded that trying to decide on service levels among engineers alone didn't work. Moving forward, we want to be able to have conversations with the business side as well—discussing things like what level of quality is actually needed." Through this event, being involved in things like running the conference made me want to expand my network with all kinds of people, and it also gave me the motivation to build a platform that’s easier to use from a developer’s perspective." Yukachi: "This was Shirai-kun's first time staffing the booth, and hearing you say that makes me really happy—it feels like it was a great opportunity for Shirai-kun!" Awata-san and Kossy-san have many acquaintances in the SRE community, and this time, I felt that many people already knew about KTC. By everyone expanding their networks like this, KTC’s recognition will grow, and above all, the more people you know, the more enjoyable it becomes to attend conferences. So, I hope more people will actively participate and get excited about these events!” Kossy: "I want to help build a stronger community with people outside the company, and to do that, I want to foster a culture and put best practices into action within our organization.” 5. Summary 5-1. What We’ve Learned At SRE NEXT this time, we learned the following through presentations by each company and interactions with the participants: Many companies share similar challenges, but there are as many approaches as there are companies, and even similar approaches can produce different results. It is important to consider the SRE approach not only from an engineering perspective, but also from a business and organizational perspective. There were many comments about how building trust with the product team has a big impact on SRE activities, and we were reminded of the importance of daily communication. 5-2. Next Challenges of KTC's SRE With this in mind, KINTO Technologies’ SRE Team intends to take on the following challenges: Further development and promotion of improvement tools Establishment of valid service levels in collaboration with the business side as well Sharing gained insights both inside and outside the company to contribute to community activation 6. Conclusion Many thanks to SRE NEXT organizers as well as those who stopped by our booth, attended our sessions, and connected with our team. It was our first time sponsoring SRE NEXT, and it turned out to be a truly valuable experience. We’ll continue practicing and experimenting with SREing and look forward to future opportunities to share what we’ve learned! Organizing members who participated from KINTO Technologies Recruitment KINTO Technologies is looking for people to join us in building a mobility platform. Please feel free to visit our recruitment website below! 👉 KINTO Technologies Corporation Recruitment Information

Introduction I'm Nakamuraya from the Creative Group of the KINTO Unlimited app. We've recently decided to implement sound into the app, so I'd like to share the process and concept behind it. A business team member on the KINTO Unlimited project casually asked if we could add sounds that make users ”feel so good they end up continuing to use the app”—leaving it entirely up to the Creative Group! There are lots of apps that have sounds built in. Apps that feel good seem to have stylish, well-designed sounds too, don’t they? Just as I was thinking, “Hmm, maybe we could involve that sound designer or artist...” , the dream was cut short—it turned out we didn’t have the budget for such originality. I had envisioned something big, so it was a letdown. But since I couldn't compromise on quality, I decided to use a paid service called Splice ( https://splice.com/sounds ) after looking into various sound services known for their high quality. Although this was a side project to my main work and an area where I didn’t have much experience, if you’re curious about any of the following, take a look at this blog: How should we choose and assemble from such a huge number of sounds? What’s the design process like up to implementation? How is the Creative Group involved in development? What is the Sound World of Unlimited? First, the direction. This is a key part that greatly influences later stages. It is also necessary to verbalize the app’s sound concept, set criteria for sounds, and avoid spending excessive time. Define the scope: As this is experimental, implementation will be limited to a minimal, specific set of experiences. We will focus on feedback sound effects (SEs) for user operation, as well as on background music. The Unlimited service is a new way of owning a car, where your car is upgraded with new technology after purchase, and the keywords are futuristic, innovative, optimized, smart, and secure . We reflect these “keywords” in sounds. The sounds that come to mind here are " modern and comfortable digital sounds that blend into the environment " ( hypothesis ). To avoid narrowing the scope of ideas and expressions, we develop hypothetical concepts at a level that allows flexibility. We search for sounds while imagining a balance between calming elements and a cool, crisp feel. And soon, we realized this wouldn’t work. There's no way that a group of sounds chosen by someone who isn't a sound professional based on instinct could be harmonious and consistent. However... we found it! A method that ensures quality and efficiency. Splice offers sound packs , including packs for apps such as games and UIs. So, we chose a sound pack with modern, sci-fi elements and a comfortable feel, and began selecting sound candidates. We then use Adobe Premiere Pro to try out sound effects on app operation videos and further narrow down the candidates. :::message Tips: Sound packs that include the name of the sound designer in the credits are particularly good! I felt their concepts are consistent and clear, the sound quality and volume are stable (normalized), and they are easy to implement without any unnecessary adjustments. ::: Change of Direction Rather than focusing on perfection, we asked project members to listen to variations early on and provide their opinions on the direction. The basic feedback was positive, but one comment caught my eye: “They’re good, but maybe they should feel a bit more common?” This feedback came from a member deeply involved in the app and service. I felt that the Creative Group should pick up on this feeling and interpret the discomfort that cannot be put into words. “Common” means ordinary, unrefined, and conventional, but we do not take it literally; instead, we interpret it from a design perspective. We interpret that sophisticated, futuristic sounds are not suitable → they are not the value to be provided to users → and we should align more with real users rather than the vision to evoke empathy. As mentioned at the beginning, "To promote continued app use," the app has implemented measures such as beginner content and gamification, promoting usage by focusing on real users rather than offering one-sided value. We realized that the original concept we had in mind was not wrong, but that the app concept was gradually changing and that an update was necessary to keep up with it. We then redefined the sound concept as the provision of an experience that makes the latest technology feel familiar, offering a sense of security as we grow together . Here is a sample of the sounds we reworked based on this concept. https://www.youtube.com/watch?v=oeGNNqRJs50 Familiar sounds reminiscent of one’s own memories, with a playful touch that might become addictive—don’t they evoke that kind of image? Before Implementation We hand over the finalized sound data to the engineers and leave the rest to them! But that's not the end of it. The design phase from here on is also very important in shaping the user experience. For example, it's very pleasant when the sound closely synchronizes with the visual changes that punctuate the animation (e.g., a sound being made the moment a coin flashes). Conversely, if there is a mismatch here, it creates discomfort and causes stress. When it comes to the sound effect (SE) played when a button is pressed, if it sounds exactly at 0.00 seconds the moment it is pressed, it gives a stiff impression. A slight delay of several tens of milliseconds provides a more natural and refined feel. * The approach varies depending on the theme. Based on this way of thinking, we compile specifications to ensure reproducibility of where, when, and how sounds are played. (First, without overthinking feasibility, we incorporate the ideal image of the user experience.) Since this is not a specialized sound app, we avoid delving into technical concepts and compile the implementation specifications as follows: Management ID / Sound file name / Target screen Playback trigger: Clearly specify what user action or event causes the sound to play, such as “When tapping the 〇〇 button” or “When displaying the △△ animation.” Presence/absence of loop playback Volume: Design the volume based on the meanings and relationships of the sounds, such as keeping background music and cancel sounds modest. Delayed playback: This allows playback timing to be adjusted relative to the trigger, keeping the trigger logic simple. Fade-in: This can adjust the start of the sound and help avoid conflicts between sound effects and background music. Fade-out: Stopping the background music with a lingering sound, rather than cutting it off suddenly, creates a more polished impression. Note: Describe the intention behind the playback timing clearly to avoid any confusion. The following is regarding data. The devices on which the app is installed belong to the users, so we must be mindful of the app's size to avoid placing a burden on user devices. The following data specifications are not the highest quality but are set at a sufficiently high level. SE: WAV format or AAC format* BGM: AAC format *For important sounds (brand SEs) and frequently used SEs, WAV is recommended. For SEs exceeding 200KB and longer than 1 second, consider AAC. Basic standard after AAC compression: Stereo source of 256 kbps variable bit-rate (VBR), sampling rate of 44.1/48 kHz. Since sound effects are intended to be played instantly, WAV (uncompressed and highest quality) is suitable as the data is played as is, while AAC (compressed) requires a decoding process for playback, which causes a slight delay. * With recent smartphone processing power, such a slight delay is unlikely to be noticeable except to professionals. In addition to this, there are other items that need detailed definitions, such as audio interruptions and preloading (prior memory read). We will share these with the producer and engineer to an appropriate extent and refine the details together. This is an advantage of in-house development―you can move forward together with knowledgeable people before worrying about things you don’t understand. Conclusion Although these are part of the development details, I will end here for now as a milestone. The reason we were able to make this much progress in this unfamiliar area was the use of AI, including ChatGPT. I was able to identify the necessary perspectives, use AI as a sounding board, and deepen my thinking until it became convincing. However, no matter how much I dig into sound theory, there seems to be no bottom in sight. Therefore, it was important for me to define sounds in a way that would allow for a common understanding within the company . We are careful in creating specifications and communication that are easy to understand within the project without being overly technical. (For example, instead of using dBFS values for volume, we set a reference point and express it as a relative scale value, defining it as an easy-to-understand number between 0.0 and 1.0.) Still, sound is very deep, and I know there's a lot missing here. Furthermore, music is a mass of sensibility perceived differently by each person—or more precisely, depending on their mental state at the time. I introduced the process of incorporating these types of things into the user experience. Finally, at KINTO Technologies, the concept of Minimum Viable Product (MVP) is well established, so once we gain support, we can quickly build an idea and proceed with development. We can then repeatedly update while monitoring user feedback. This is just one example, and I hope it gives you a glimpse into how the Creative Group is involved in such development. Thank you for reading through to the end.

#iwillblog → #ididblog Hello everyone. My name is Koyama and I am in charge of iOS in the Mobile App Development Group. I attended iOSDC 2023, so I would like to share my experience, albeit belatedly. Two of us from our company—GOSEO and I (Koyama)—will each share our experiences. This year, a member of our Tech Blog team who is not an iOS engineer also participated. An article from the member’s operational perspective has been compiled in A Report (Management Perspective) on Participation in iOSDC Japan 2023 , so be sure to check it out! Last year's iOSDC participation report is also available in #iwillblog: iOSDC Japan 2022 Participation Report . Part of KOYAMA This was my first time attending iOSDC in person. I would like to summarize what was presented at the booths of various companies and my impressions from listening to each session. On-site Booths Over the course of three days, I was able to visit most of the booths and hear many stories from fellow iOS engineers actually working in the field. As an iOS engineer, I especially enjoyed LINE's code review challenge and DeNA's mental SwiftUI rendering. In particular, I took on the challenge of solving the mental SwiftUI quiz because I regularly practice working with SwiftUI. However, I couldn't render components I had never used before, and to my chagrin, it was a crushing defeat. (That said, I enjoyed learning a lot from the experience.) I also enjoyed AR makeup at the ZOZO booth. It was a refreshing experience to witness how quickly facial feature recognition could be achieved. It seems that a bright red lipstick suits me far too well, which was a surprising new discovery (?). Because it suited me too well, I covered my face just a little. There were many sponsors who prepared various novelties, and among them, Findy and dip were holding prize lotteries side by side, so I went to try my luck there as well. However, the result was another crushing defeat. Within the one-challenge-per-day limit, I was especially unlucky with Findy’s lottery, drawing “great misfortune” both times I tried. So regrettable··. (Many people drew “excellent luck) before and after me.) It seems that drawing the great misfortune lottery two days in a row is also rare. Wait, am I just enjoying the event? Sessions I Attended Of course, I also attended the main sessions. Among them, I would like to comment on the sessions that caught my particular attention. Getting a Complete Picture of Privacy at Apple One of them was a report on privacy by @akatsuki174 . Apple’s OS controls access to various information such as camera access and location information. Thus, you won’t accidentally access any unintended or inappropriate information. This rigor is one of the reasons I love iOS development. The above-mentioned privacy-related items are often closely checked during the App Store review process, so as an engineer, it's important to keep up with them. One session that particularly caught my attention was about the permission status related to location information. Obtaining location information using CLLocationManager , for example when you want to "always get location information," requires requesting permission in stages, which I had never heard of before. The official documentation states as follows: You must call this or the requestWhenInUseAuthorization() method before your app can receive location information. To call this method, you must have both NSLocationAlwaysUsageDescription and NSLocationWhenInUseUsageDescription keys in your app’s Info.plist file. I see, so in order to constantly collect location information ( requestAlwaysAuthorization() ), you must first obtain permission ( requestWhenInUseAuthorization() ) while the app is in use. It was a function I'd vaguely seen before, but this was the first time I'd learned how it worked, so it was a very educational experience for me. Personally, I liked the funny sight of Akatsuki-san, who appeared on stage for the recording that day, talking while only the head of a mannequin was projected. LOL Everything about iOS App Development Completed Only on an iPad This session was part of lightning talks (LTs) and focused on developing iOS apps solely on an iPad—no matter what. It concluded that it would be possible, but the fact that GitHub couldn’t be used was pointed out as a major issue—and I felt exactly the same. However, the fact that app development is now possible to some extent even without a MacBook really shows how much times have changed. I thought it was great news for engineers to be able to develop iOS apps anytime and anywhere. How to Fight When You Are Accused of a Developer Program License Violation You Didn’t Commit and Your App’s Search Ranking Is Lowered Another interesting session from LTs. It was a sad story of how the developer created an app that saw a sudden increase in the number of accesses at certain dates and hours, but Apple suspected fraud and lowered the app's search ranking, and the developer is still fighting the issue to this day. Given the nature of the app, I understood why the accesses would significantly increase on Setsubun day, and I also fully understood why Apple would view that as a potential risk. However, the fact that Apple hesitates to respond to the developer’s inquiries seems to be a difficult issue to resolve. This was a case of individual development, but since similar patterns can occur in apps developed by companies as well, I gratefully took it as valuable insight for the future. KOYAMA’s Summary That concludes Koyama's part. The festive atmosphere at iOSDC was fantastic! I couldn’t participate for the full three days this year, but I strongly resolved to attend all days next year. I was also able to talk directly and take photos with people from the iOS community that I'd seen on X (Twitter), so in that respect it was a very satisfying event. Part of GOSEO This was my first time attending iOSDC online. I compiled feedback on the sessions I had planned to watch before the event, after actually watching them. Luxurious Novelties While everyone else was saying they had gotten their novelties, I was eagerly and excitedly waiting for mine. I had made a mistake with the address I registered, and the event organizers contacted me to say they couldn’t deliver the novelty item. I apologize to the organizers for the trouble I caused. After successfully receiving the novelty item—a small cup—I’ve been using it with care (only on the days I go to the office). Luxurious novelty box A mug just right for use at the office Sessions I Attended Exploring the Black Box of UI When I heard that the quality of custom UIs tends to be lower than those provided by the OS, but that under certain conditions, custom UIs become necessary, I could really relate—it made me realize that creating custom UIs is something many engineers go through. I've also heard that not all custom UIs are bad, and that their quality can be improved by adhering to the HIG and analyzing the UIs provided by the OS. I'll keep this in mind in future implementations. The speaker also explained where to focus when analyzing, emphasizing the importance of analyzing HIG elements on the screen to discover patterns in the UI. The speaker also said that it's important to implement UI that feels natural and intuitive to the user. The speaker said that by implementing behaviors that feel natural and familiar to users, the app becomes more user-friendly and reduces any sense of discomfort during use. What I found most impressive was the tool for analyzing the UI of the published app itself. The View Hierarchy Debugger is a well-known tool among iOS engineers, but it has the limitation that it can only be used on apps running locally. The speaker introduced the tool Frida, saying it can be used to investigate the UI structure of apps like Maps and analyze UI structures that cannot be seen on the screen. The speaker also kindly explained how to set it up, which really motivated me to try it out. Technology for More Accurate Passport Scanning in Travel Apps ~ MLKit / Vision / CoreNFC ~ The speaker compared and explained MLKit and Vision in terms of their compatibility with SPM, ease of implementation, and OCR accuracy. The speaker judged that both implementation and OCR accuracy were at comparable levels between MLKit and Vision, but Vision seemed to be superior in terms of compatibility with SPM. After that, the speaker explained how to implement reading passport characters using Vision. Specifically, the speaker explained how to use the passport's NFC to supplement OCR reading errors. There was also an introduction to how to implement NFC, making it a very informative session. GOSEO’s Summary That concludes GOSEO’s part. It was a great iOSDC, where I was able to come into contact with knowledge I don’t usually deal with or notice. I definitely want to participate again next year. It was a wonderful event that allowed me to realize things I didn't know, such as my current position and the direction I should aim for. Conclusion This concludes the series with the hashtag #ididblog ! My post was delayed, so next year I want to be able to publish earlier. I can't wait for next year's iOSDC 2024!

Nice to meet you. I'm Aoshima, a UI designer at KINTO Technologies. I usually handle the UI for business applications. A little while ago, we ran a usability test to see how customers use our website, aiming to use the insights for our site redesign. It was also something of a trial test for us, so we kept things small by recruiting participants from within the company. Even so, we were able to collect data that offered plenty of valuable findings. In this article, I'll share the outline of the test and tricks we used to carry it out. What Is a Usability Test? First of all, despite the name, it isn't about passing or failing. It's a method for evaluating three key factors that are essential to the concept of usability. So first, let's take a look at the general idea of usability. The Definition of Usability The term "usability" is often used in a broad or vague way, typically to mean how easy something is to use. However, it actually has a clear definition set by the international standard ISO 9241: "The extent to which specified users can use a product to achieve specified goals with effectiveness, efficiency, and satisfaction in a specified context of use." The three key elements of effectiveness, efficiency, and user satisfaction can be explained as follows: Effectiveness: whether users are able to achieve their goals. For example, on an e-commerce site, can users successfully complete a purchase? Efficiency: whether users, assuming they can achieve their goals, are able to do so via the shortest possible path, without unnecessary steps. Satisfaction: the degree to which users can operate the product comfortably and without frustration, even if there are no major problems with effectiveness or efficiency. For example, on an e-commerce site, if users can't complete a purchase in the first place, usability is either very low or completely absent. Even if users are able to complete their goals, usability is still low if it takes too many steps, like having trouble finding what they're looking for. And if the experience is frustrating or unpleasant for any reason, user satisfaction drops and so does overall usability. Leaving those issues unaddressed could lead to losing your important customers to competing products or companies. To prevent this from happening, it's essential to understand how customers behave when handling your product or using the website, and to take usability into account. Usability Test: What It Can Do and What It's For The foundation of a company's profit-making activities is ensuring that customers are happy to use its products and services, rather than feeling uncomfortable, so if there are any problems with the products or services, they should be improved. The first step is to identify those problem areas. Fortunately, we already had access to a customer survey conducted by our analytics team. The survey included targeted questions about which parts of the website users found confusing, and we used that feedback as a key reference point for our usability test planning. If you can observe how customers behave at those problematic points, it can give you clues as to why those areas are causing trouble in the first place. Gathering this kind of hints is what usability testing can do. To put it another way, surveys are like the English tests you'd take in school. They're good at pinpointing what went wrong, like whether it was listening, grammar, or something else. Usability testing, on the other hand, is better at uncovering why something went wrong and what could be done to improve them. Preparation Before the Test Setting Tasks and Conditions As a first step, we prepared tasks and conditions based on discoveries from a prior survey. The results showed that users across all age groups had trouble understanding certain areas of the website. So, we focused on those points and designed tasks to evaluate two key aspects: effectiveness and efficiency. Setting these tasks and conditions was important for two reasons. The first point was that if we let participants explore the site freely, they might complete the session without ever encountering the problematic areas. Setting tasks helped prevent that. The second point was to have participants with varying levels of digital literacy perform the tasks under the same conditions. Prepare a Script, Questions, and Surveys Next, we prepared three key materials: a script to explain the test to participants, a question sheet to understand their background and digital literacy, and two post-test surveys to be filled out after the session. To help participants feel comfortable taking part in the test, it was important to clearly explain the content and flow of the test beforehand. We also asked questions to better understand each person's background and level of digital literacy, so having a script helped ensure that everything was explained clearly and the test ran smoothly without missing any steps. Ice-breakers and other little things can sometimes take up more time than expected, so it's a good idea to set a rough timetable for the session if possible. The post-test surveys were designed to measure the third and final key point mentioned earlier: satisfaction. For this, we used two metrics called Customer Satisfaction Score (CSAT) and System Usability Scale (SUS). CSAT is commonly used in customer satisfaction surveys and measures how satisfied users are on a five-point scale. SUS, on the other hand, measures how users perceive aspects like ease of use and difficulty. It's widely used as a standard metric for evaluating overall UX. One reason SUS is especially useful is that it comes with a clear benchmark. If the score is below 68, it's a sign that usability needs to be reviewed, which makes the system easy to understand and practical. Device Setup As a final preparation, we prepared a smartphone and a laptop to record the participants' facial expressions and on-screen actions during the test. We used the smartphone to film hand movements and the laptop to record facial reactions, setting up both ahead of time. Once the test began, we logged into Microsoft Teams on both devices and used the built-in recording feature. This function is extremely handy because it automatically saves the recordings to the cloud and combines them into a two-screen layout, making review much easier. By the way, we used a smartphone stand from a 100-yen shop. As a side note, we used two separate video cameras, one for filming hand movements and the other for facial expressions some years ago. The footage had to be saved locally and edited manually to create a synchronized split-screen view for comparison. Thinking back on that process, I was genuinely impressed by how much easier testing has become in just the past few years. Carrying Out the Test Once all the preparation is complete, it's finally time to run the test. After a brief ice-breaker and some explanations and questions, we moved on to the task execution using the website. The test was conducted using the think-aloud method. In this approach, participants are asked to verbalize their thoughts as they perform an operation. By combining flat visual data with spoken thoughts as audio input, it allows us to understand their behavior from all angles. Things to Watch Out for During Testing There are two things you need to keep in mind during the test. First, because participants are not used to speaking out their thoughts while performing tasks, the interviewer needs to consistently prompt them to share what they're thinking to prevent silences. Another point is that participants often ask the interviewer questions during the test, but it's best to gently avoid answering them as much as possible (though not ignoring). During the pre-test explanation, we made it clear that the purpose of the test was not to evaluate how well the participant could use the website, but to assess how easy or difficult the website was to understand. Even so, when subjects felt unsure, they often ended up asking questions instinctively. However, answering those questions could introduce bias, so it was important to judge carefully whether a question was appropriate to respond to. Once the tasks were completed and the questionnaire filled out, the test came to an end. Preparation for Analysis After the test, the next step was preparing for the analysis phase. It would be nice to take a breather after wrapping up the test, but this was actually where the more time-consuming work began. The first thing to do was transcribe the text. For Information Sharing The audio recordings from the test were about 20 to 30 minutes per participant but transcribing them took quite a bit of time since we often had to rewind and replay unclear parts. This might have been the toughest part. That said, converting time-based audio into plain text made information sharing much easier. For the sake of future analysis and collaboration, this was a step worth sticking with, even if it required quiet persistence. (The automatic transcription tools still felt far from reliable at the time.) The next step was to categorize and tag the spoken content to make it easier to organize. We first compiled everything chronologically in a spreadsheet, then copied it into a tool like miro. This allowed us to get an overview of multiple users' behavior and organize insights from various angles. If you want to take information sharing a step further, you can also create short, edited clips of the test footage with subtitles, making it easy to share what happened during the session. If time allows, it might be worth putting in the extra effort. In our case, we had only five participants, which made it manageable enough to go that far, but it was still a very time-intensive and demanding process. From Analysis to Improvement Normally, we would have a group of people analyze the data and use it to make improvements. However, since this was more of a test run to validate the testing process itself, I simply wrapped up my own observations into a report and left it there for the time being. Gather stakeholders in a number sufficient to hold a discussion, exchange opinions, and consider the matter. By going through this kind of process, I believe it becomes possible to move forward with improvements based on a shared understanding. Everything written here has been preparation for reaching that point. Lastly In this article, I wrote about a test we conducted on a small section of our website, which is just one part of the entire service. Even for testing such a limited scope, a great deal of time and preparation was required. But I believe that these small, steady efforts accumulate and ultimately lead to a better experience for our customers. To keep up with the changing world and our customers' needs, we hope to do our best to support the website' growth. I'd be glad if any part of this content is helpful for those planning to run their own usability tests.

Introduction Nice to meet you. I’m Kondo, the manager of the Owned Media & Incubation Development Group at KINTO Technologies. Our group name is so long that no one in the company ever says it correctly. So please feel free to call us Media Incube G . In this post, I'd like to introduce what our group is all about. Group Overview Establishment Media Incube G is a newly formed group that was established in August 2022. Originally, we were part of the KINTO Development Group, which was solely responsible for developing the customer-facing website for KINTO ONE, our subscription-based car service . As our group gradually grew, it became necessary to provide more focused management for each sub-team. In response, the original group was split into two in August 2022. One became the KINTO ONE Development Group and the other became our group, the Owned Media & Incubation Development Group . Products We Handle Here are the main products that each group is responsible for developing. KINTO ONE Development Group Product Overview URL KINTO ONE Develops features for onboarding to the new vehicle subscription service and providing aftercare support. https://kinto-jp.com/customer/login Owned Media & Incubation Development Group Product Overview URL KINTO ONE Produces content for the top page of the new vehicle subscription service, including vehicle listings, terms of use, and landing pages. https://kinto-jp.com KINTO Magazine A media website that provides MaaS-related information from KINTO. https://magazine.kinto-jp.com Mobility Market A service website where users can discover the joy of new forms of mobility. https://mobima.kinto-jp.com Prism Japan An AI-powered app that provides inspiration for places to go. https://ppap.kinto-jp.com/prismjapan/index.html Used Car Product A new mobility service from KINTO focused on used cars. - Dealer Product Develops sales promotion tools for KINTO ONE, designed for Toyota dealership staff. - Mission Our mission at Media Incube G is to deliver the value of KINTO to our customers to the fullest by leveraging the power of technology and creativity in both owned media and new business creation . As our group name suggests, we focus on two main pillars: owned media (our in-house digital media) and incubation (supporting the creation of new businesses) . Owned Media (Our In-House Digital Media) We create media that effectively reaches customers with the value of KINTO's mobility services and products. Relevant Products: KINTO ONE (user-facing content), KINTO Magazine, Mobility Market, Dealer Product Incubation (Supporting the Creation of New Businesses) Together with KINTO, we create and support new mobility services that follow in the footsteps of KINTO ONE, using technology to bring them to life. Relevant Products: Prism Japan, Used Car Product What We Are Working On and Aiming For Quality Assurance Initiatives The user-facing content for KINTO ONE provides customers with essential information during the contract process. In line with frequent business updates, such as new vehicle listings or service changes, our average delivery span is one week. Depending on the timing, we sometimes deliver even faster. Under such conditions, we must maintain a certain level of agility while still ensuring content quality. That’s why we are constantly exploring and implementing initiatives to enhance quality assurance. Here are some of the measures we have implemented: Automatic Checks in Our CI/CD Pipeline We have an in-house QA team, and when requested by product teams, these testing professionals can conduct quality checks. However, due to business constraints, there are cases where content or materials cannot be fully prepared in time for QA testing. In such cases, how can we still deliver without missing anything, even in situations like this? Here’s the approach we’ve taken: When a change is needed, we first commit a temporary version containing a specific dummy string. Once the final content is ready, we replace the dummy text and deploy it to the test environment. If the content is ready in time for QA testing, the QA team checks it on the assumption that it is finalized. If the content is not ready in time, we inform the QA team which parts are still dummy text, and they test it with that understanding. We have set up a test job in GitHub Actions to check for the presence of specific dummy strings. This check is triggered when merging into the main branch. This allows us to pass QA testing while also preventing dummy content from being accidentally deployed to production. Pair Programming Required for Resolving Merge Conflicts Since wide-ranging content updates are often made within a short time frame, merge conflicts occasionally occur. In such cases, we have established a rule that conflicts must not be resolved by a single person. Instead, multiple members must work together through pair programming, viewing the same screen to confirm each change as they go. Additionally, even for pull requests without conflicts, we have configured GitHub to prevent merging unless at least one reviewer approves the changes. Skill Development Media Incube G is made up of members with diverse backgrounds and skill sets. However, it can be difficult to know what members outside of your own product team are working on, or what kinds of challenges they’re facing, just by going through your daily tasks. To address this, we set aside time outside of day-to-day work for skill-sharing sessions and technical knowledge exchanges among team members. Study Sessions Most recently, we’re planning a "Design System + Atomic Design Study Session" led by front-end engineers. Since back-end engineers don’t often get the chance to explore these topics in their day-to-day work, they seem to be looking forward to it. Technical Exchange Meeting We’re also planning a technical exchange meeting with participation from all front-end engineers, including members of the KINTO ONE Development Group. Those attending in person will enjoy snacks and coffee, and the event will also be available online so remote participants can join as well. Teams and Members in the Group As mentioned earlier, Media Incube G handles a variety of products. Within the group, we are organized into three distinct teams. We'll introduce each team next. For clarity, we’ll refer to them based on the main product they handle. Please note that these may differ slightly from their actual team names. 1. KINTO ONE Team Members (as of December 2022): 8 How the Team Works As engineers working closely with the business side, our most important role is to understand the KINTO ONE business and determine how best to shape it through our systems . Rather than simply doing what we’re told, we aim to fully understand each task ourselves, ask questions whenever something is unclear, and move forward based on our own judgment regarding the scope of impact and the optimal logic. Team Atmosphere The team has a strong desire to learn. While individual skill levels vary, no one is content with the status quo. Many of the team’s half-year skill development goals are quite ambitious. Here’s a blog post by our tech lead, who helps drive this culture of continuous learning across the team: Insights from using SvelteKit + Svelte for a year 2. Used Car Team Members (as of December 2022): 4 How the Team Works Due to various reasons, we can’t share too many details about this product. However, one notable aspect of how we work is that we function as one team, where everyone is encouraged to share their opinions regardless of department or company . We hold seven weekly recurring meetings, each focused on a specific theme, and also meet weekly with the KINTO business side. In addition to those meetings, we also communicate regularly through Jira and Slack. Team Atmosphere Our product manager and lead engineer actively engage with the business-side product owner. To be honest, not every engineer has been able to keep up with that pace, but each of us is working to deepen our understanding and improve our skills within our respective roles. Actually, I’m the lead engineer myself. I joined the company in September 2021, and this project kicked off right after that. I've been serving as the lead engineer ever since. That said, as of November 2022, we’ve added more engineers to the team, and I believe we’re now entering the skill transfer phase. I’m looking forward to seeing a new leader step up and guide the team forward. 3. Prism Japan Team Members (as of December 2022): 5 How the Team Works The team consists of one project manager, one product manager, and three engineers. Prism Japan was launched in August 2022 and is now in the operations phase. We’ve adopted an agile approach for the operations and refactoring phase , and to support this, we’ve assigned a dedicated QA member from our QA team. Team Atmosphere This is a team where everyone takes ownership and works independently. There’s a strong sense of mutual respect among members, and they each play to their strengths while supporting one another across areas of expertise. I often hear lively discussions right behind me, as the team frequently exchanges ideas about challenges and potential improvements. We’re Looking for Teammates Like You 1. KINTO ONE Team Product Manager (PdM) We’re working to build a PdM team that can define and propose the ideal form of the product from a system development perspective. Click here to apply for the Product Manager (KINTO ONE Team) position Front-end / Back-end Engineers To bring our ideal product vision to life, we also need engineers who can build it with their own hands. We’re looking for members with the potential to eagerly learn new technologies, understand KINTO's business, and grow alongside KINTO as true partners. Click here to apply for the Front-end Engineer (KINTO ONE Team) position Click here to apply for the Back-end Engineer (KINTO ONE Team) position 2. Used Car Team Front-end / Back-end Engineers We’re looking to grow our team with engineers who can deeply understand the used car business and work hand-in-hand with KINTO to drive system development forward. The knowledge and experience you gain here will not only benefit current products but also play a vital role in shaping KINTO’s future services and offerings. In other words, working on this used car product gives you the opportunity to become an engineer who makes a significant contribution to the value of both KINTO and KINTO Technologies. Click here to apply for the Frontend Engineer (Used Car Team) position Click here to apply for the Backend Engineer (Used Car Team) position 3. Prism Japan Team Back-end Engineer If you’re interested in contributing to the development of a native app and helping to pioneer a new mobility market, we’d love for you to join us. Click here to apply for the Backend Engineer (Prism Japan Team) position

はじめに こんにちは、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 テクノロジーズでは、まだまださまざまな部署・職種で一緒に働ける仲間を募集しています！ 詳しくは こちら からご確認ください！

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

Introduction Hello, I'm Risako.N from the Project Promotion Group at KINTO Technologies (hereinafter referred to as KTC). I joined in March 2023 and have been working as a project manager (PjM). Regarding my career, I have worked in the SIer (system integrator) industry throughout. When I first started, I was heavily involved in developing web-based business systems. After that, I gradually shifted to upstream processes, and over the past few years, I’ve mostly been working as a PM. In this article, I would like to introduce how is the work of a PjM at KTC, drawing on my experience as a PM at a system integrator (SIer). What is a Project? KTC has development teams and PdMs for each product (which I will call PD from now on). These development teams communicate with KINTO’s various business divisions and handle daily feature enhancements and improvement projects for their respective PDs. In addition to projects initiated by the business divisions, there are also those proposed by the development teams, such as legal compliance or architecture renewal projects, so multiple projects are always running in parallel. Depending on the project, it may be necessary to work across multiple PDs and business divisions to achieve a single goal. Work that needs to be carried out across divisions, lasts for a certain period of time (typically 4 to 5 months or more), and has a fixed duration is called a "project." A PjM who holds responsibility for execution is assigned to each "project" to carry out and promote the project. How a Project is Launched Next, I will introduce how a project is launched and the overall process involved. At KINTO/KTC, a project follows the steps below: Project proposal Internal agreement and approval on the feasibility of the project (e.g., whether the product will sell and can ensure profitability) To realize the project, members are assigned from relevant departments, and the project is organized and launched. At the third step of forming the project, a business coordinator and a system PM (or PjM), who act as the driving forces for the business and system sides respectively, are assigned. These PMs lead the project’s launch, execution, and completion. As such, PjMs are generally assigned at the stage when a project is about to be launched (i.e., when the planning has been mostly finalized). Meanwhile, KTC also has a Production Group that supports planning and project initiation from the early stages with a system development perspective. The Production Group is not involved in every project, but if a PM’s assigned project involves the Production Group, the PjM receives a handover of information from it, such as the project’s background, direction, and current challenges; and then launches the project and moves it into the execution phase. ...This is the basic process, but since each project has its own unique circumstances and involves different members, the way each project is launched can vary. For example: A project whose requirement definition was completed last fiscal year and has now resumed in full force this fiscal year A project that was not planned at all last fiscal year but was suddenly proposed and started running And so forth. There are also projects where the planning started, but progress was put on hold due to things that became clear as the planning process progressed or due to changes in the environment. I think this kind of speed in launching and decision-making is something that is unique to KINTO/KTC. How to Proceed with a Project and What to Do as a PjM There are various types of projects. For example, in the KINTO ONE product development project aimed at launching a new plan, the project as a whole is generally carried out simply using the waterfall process. ＜Waterfall Process＞ The reason I used the expression “the project as a whole” is that the PD teams participating in the project have different development approaches, such as: A PD team that repeats the design, development, and testing processes by user story unit A PD team that designs all functions first, then proceeds with development and testing In this process, what a PjM does includes, for example, the following: At the project launch stage, a PM deeply understands the purpose and business requirements of the project, and promotes the system requirement definition while discussing and coordinating requirements with the business division. After the requirement definition, each PD team basically proceeds with design and development. The development scale varies by team and project, and each team is also working on other projects in parallel. Therefore, a PM understands each team's development schedule, regularly checks progress, and manages the overall project. While each PD team proceeds with development, a PM prepares for testing after the PD teams join together, and coordinates with the QA team on testing activities. After the requirement definition phase, a PM handles all coordination with the business division, including requests for addition/change and determination of the release date. After Actually Starting as a PjM The role of a PjM is to create an action plan for the project goal, execute it, drive the project forward, and see it through to completion. I believe this role is largely the same in many other companies as well. However, compared to the SIer projects I have worked on in the past, I feel that I am taking on the role of driving projects in a position closer to the business. In the past, whether I was involved as a system consultant or a PjM, the relationship with the business side was always one of client and vendor, which naturally created boundaries I couldn’t—and shouldn’t—cross. However, in the case of KINTO and KTC, although they are different companies, they share the same root. This allows for open, barrier-free exchange of ideas and genuine collaboration in the best sense. As a PjM, I will of course be responsible for planning and leading system development, but I also hope to gain experience that will allow me to contribute to KINTO’s business expansion from a systems perspective, grounded in a solid understanding of the business, while keeping in view the overall management of projects that integrate both business and systems. And what I found difficult about starting PjM at KTC is that KTC has members involved in various fields, from designers to commercial websites and business system development, and each of them has a wide range of experience, so what was previously considered common sense is not common sense, and each person has their own way of doing things, so while respecting that, I also have to lead them! Also on the business side, I was assigned as a PjM to a project to launch a new plan just two months after joining the company. However, there were so many things I didn’t yet understand, like how a new plan is developed at KINTO, what needs to be considered and addressed as a leasing business, and what kinds of risks may arise in the automotive industry. However, for each thing I didn’t understand, I turned it into something I could understand by gathering information from past projects and asking people around me. At the same time, I used my previous experience to move forward with the launch and execution of each project. In order to participate in and drive a project forward, it is also essential to build relationships with stakeholders. While I mainly communicate online, I proactively made business trips to Nagoya to have face-to-face conversations. By the way, the KINTO Nagoya Office is designed with the idea of "making it an office that people who come here can have fun," so it's quite stylish! (Featured in First Look: Inside the KINTO Nagoya Office! (in Japanese) ) Near the office, there is Yanagibashi Central Market (a full-fledged market that suddenly appears in downtown Nagoya!) as well as a famous bakery... Business trips are great!  Speaking of Nagoya, it's famous for its breakfast sets! Two cups of coffee are served as the norm.  This is the Nagoya meal set!  It seems there are various ways to eat it. But the person I was eating with said none of those are correct… It's not easy to jump into an unfamiliar environment like this and move things forward in it, but it's interesting to gain new knowledge, experiences, and realizations, and I hope to continue meeting different people and broadening my own horizons. Finally KTC is still a young company, and the surrounding environment is constantly changing, so there are many different ways to launch and promote projects. Because of this, there are many new discoveries, and I believe I am in an environment where I can proceed with my own initiative. If you are interested in such an environment and the role of a PjM, we would be delighted to have you join us and work together!

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 テクノロジーズの採用情報もチェックしてみてください！ 最後まで読んでいただき、ありがとうございました。

はじめに こんにちは。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活動についてご紹介しました。 チーム内の一体感や品質へのこだわりが、少しでも伝われば幸いです。 私自身、お客様視点とサービス視点を忘れず、開発メンバーと協力しながら、みなさまに笑顔になっていただける品質を追求していきます。 もし興味を持っていただけた方は、ぜひ 弊社の採用ページ もご覧ください。

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! (^_^)/