Introduction Hello, I am Kang from KINTO Technologies' development head office. I joined the company in January 2022 and have been working on the Website Restructuring Project since then. As KINTO increases its customer base, we are trying to expand various services along the way. The existing website had various issues with scalability when it came to incorporating new functions, so the website restructuring project was started in August of this year to solve these problems and make improvements. In this article, I will talk about the front-end (FE) team behind the Website Restructuring project, of which I am a part of. Website Restructuring FE Team's Goals To create an environment that facilitates new development quickly To change a complex environment into a simpler one To Redefine css and js sources that are intricately interconnected Transfer membership management functions to the member information platform Work with the Creative Group to implement designs effectively (including UI/UX improvement suggestions) The Restructuring FE team worked to accomplish the above goals on the project. During the development phase, we discussed items that could be improved at each sprint meeting and worked with other teams to improve the project and make it more efficient. We updated the code for greater reusability and intuitiveness, making maintenance easier. Using TypeScript prevented unexpected errors, made debugging easy, and improved work productivity. Technological Specs We Incorporated into the Project Our Concerns During the Project In addition to restructuring the specifications of the existing project, we also improved existing functions, added new ones, and refactored code, so it was difficult to measure work in progress amongst us. We struggled with ways to efficiently communicate specifications and development with collaborating teams (BE team, Design team, Infrastructure team, QA team, etc.) How to build a good development environment Creating code that is easy to maintain and reuse How to clear misunderstandings between team members regarding the project's specifications and technology and make code more integrated In order to solve these issues: As development went on, we recognized the importance of reviews, so we decided to create rules for them. We also made every effort to make time for them every day. We decided not to designate a specific person in charge for reviews, and created a system where anyone could freely review different Pull Requests. As a result, it became easier to keep track of each other's work and check on task specifications and components that other team members were working on. We made a Confluence page on changes to specifications with other teams and used it to communicate with them, and we managed to communicate efficiently using other tools that were available for us in the company. The Confluence page contained changes to specifications on the API and swagger provided by the BE Team. It allowed us to quickly understand API specifications and clearly check and address updates. We collaborated with the Creative Team using design tools such as Adobe XD and Figma. With them, we were able to gain a better understanding of the UI/UX to be implemented, allowing us to create components that are not only easier to understand, but also user-friendly and intuitive. We maintained an open communication as we collaborated, and if there were any unclear points or changes, we addressed them quickly through huddle meetings for quick resolution. As a result, we were able to minimize the number of bugs that could occur during the development process. In order to create a better development environment, we made various work guidelines for the team. We communicated using Outlook, Slack, Confluence, and other tools, and we were able to understand each other’s current work situation by having daily meetings. While working on tasks, we actively discussed each other's concerns and collaboratively addressed problems within the team At planning meetings, we checked each team member's progress and divided work for each sprint to prevent excessive workload. We also held retrospectives after each sprint and talked with each other about what we regretted, what was good, and what we wanted to improve in order to build a better development environment. We used the Atomic Design pattern to improve code reusability through continuous refactoring. We consolidated our definitions for Atom, Molecules, and Organisms in a Confluence workspace and shared awareness among team members through meetings. As we developed new features and UIs, we were also able to make independent and pure components. We also tested Storybook and React Jest to ensure the quality of the components. As a result, we were able to create components with higher reusability. We consolidated and shared the specifications for existing projects and new features that were going to be added to the Confluence workspace of the project. We also created reference materials on the FE development environment to enable new participants to adapt more quickly to the development environment. We set rules for code management, on topics such as review flow, branch operation, and how to write code, in order to create consistent code. We took turns to hold book discussion sessions to share knowledge about the technologies each of us were currently using. Summary Through this project, I was able to look back into what is important for a good project. I think each programmer's performance is also an important factor, but I think it is important to constantly communicate as a team. I felt that it was important to work together to create a better development environment within the team and try various things with a flexible way of thinking without fear of failure. In the Restructuring Team, we were able to develop an environment with a positive atmosphere where anyone could freely say and try anything. I think that through this environment and experience, we were able to grow both as a team and individually. Successfully releasing the project in August was made possible thanks to the effort of all the teams within the Restructuring Team, who persevered through the challenges for an extended period. Thank you for reading to the end.

Introduction I'm Kobayashi, a Product Manager (PdM) for internal systems at KINTO Technologies. After joining the company, I was assigned to the website restructuring project of KINTO ONE ( [KINTO] New Vehicle Subscription from Toyota | Full Service Leasing (kinto-jp.com) ), and was in charge of project manager, test promotion, and migration promotion. When I was assigned to the project, it was already a year into development, and we were at the stage of conducting integration tests and releases. However, we encountered a number of challenges afterwards. In this article, I would like to introduce some of the challenges I first encountered as a person in charge of test promotion. What is the Website Restructuring Project? It’s the name of an in-house development project to renew our KINTO ONE New Vehicle subscription e-commerce site, our main KINTO service in Japan. The goal was to improve development productivity through a 360 review of its architecture and data structures. There were more than 20 people involved from different products and services, and a total of about 50 window persons from the business and development sides. First, Grasp the Situation I joined KINTO Technologies in February 2022. The first step was to participate in the regular weekly meetings, gaining an understanding of the situation and taking a stance on implementing testing and transition promotion. The internal integration test was started in mid-January 2022, shortly before I joined the company. It was reported that the project was on track, with a slight delay of a few days. At this point, there was no incongruity in the schedule and the internal integration test was scheduled for completion at the end of May 2022. It was an ideal situation where developers created the internal integration test plan, and a test team of non-developers was responsible for writing and executing test cases. Initial Challenges The internal integration test was planned to be divided into 7 phases, but the progress began to slow down in late February, and the first report in March was delayed by a week. At that time, there were more than 10 bugs that affected the subsequent testing phase. It became apparent that it was a difficult situation where it would take about a week just to fix them. To confirm if we could proceed as planned, we interviewed the developers about the situation, and the following comments came up. Not aware of the completion conditions for unit test Not aware of start conditions for integration test The content of the internal integration test differed from expectations Although the document compiled by the developers describes what kind of tests to be conducted, there is certainly no description of the start and completion conditions. That kind of information is being sought in written policy and plans, but it cannot be found. Well, it made sense. Regarding the expected test content, the document compiled by the developers stated that the test would be conducted through a series of screen transitions, and the test items were described as follows. Is the screen display and transitions correct when the correct data is entered? Are records correctly created in the DB? Is it possible to recover data when the process is interrupted in the middle? From this content, it seems that story-based testing is assumed, aligning well with the test cases prepared by the test team. Consequently, we had to consider what caused the confusion. When you take a look at the documentation compiled by the developers, you will notice the following description about how to run the tests. Conduct testing on each browser (Same as screen test) For the database, directly check the DB values using SQL Stated that it is the same as the screen test conducted in the unit test. In this description, it appears that same tests as the unit test are conducted by integrating the front end and back end. I somehow understood the cause of the confusion. This challenge emphasizes the importance of planning without inconsistencies in understanding. Addressing Challenges The response to this challenge was to stop the internal integration test for 2 weeks, since forcing the test to proceed without stopping could risk further delays. This response had the following effects: Recovery of the Development Side is Possible Stopping the test allowed time to be used for correction and delayed recovery. It also increases quality because it allows us to focus on correction. Developers and the test team are freed from the stress of not progressing testing. Quality Control Policy and Quality Evaluation Criteria Can be Organized Stopping the test made it possible to organize the policy and criteria, not only for the internal integration test, but also for the entire test, enabling the dissemination of the following information. Define the quality to be ensured in each test phase as a quality control policy Define quality evaluation criteria in each test phase Although it was a postscript policy and criteria, the developers accepted it. This flexibility is one of our strengths. The internal integration test began to run successfully. What To Do After Various challenges will continue to arise thereafter. When schedule changes occurred due to other projects, we added quality enhancement tests and revised the plan to improve quality according to the situation, while conducting external integration tests, follow-up intake of other projects, and QA testing. As a result, we successfully released it in August 2023. It is said that, given its size, there are few post-release bugs. Nevertheless, when a bug occurs, it can significantly impact business operations. Therefore, I would like to continue exploring what I can do to improve quality. Conclusion Based on this experience, I believe the following 2 points are important. Plan without inconsistencies in understanding Establishment of quality control policy and quality evaluation criteria I thought that even if it is left to the developers, it's essential to have plan, policy, and criteria in place as a guidepost in case something happens. Also, what I realized while responding to the issue this time is that we never gave work instructions to the developers. In the website restructuring project, the policy was to leave everything from detailed design to internal integration test to the developers. This stands as a project policy that I wanted to uphold. I think I managed to do so. Well, these were some of the initial challenges I encountered in the website restructuring project.

Introduction My name is Rina ( @chimrindayo ) and I’m involved in development and operation of Mobility Market and operation of Tech Blog at KINTO Technologies. I mainly work as a frontend engineer using Next.js. I'm excited that Oden season is here🍢 and this year I’m looking forward to Tomato Oden! 🤤 At KINTO Technologies, we do our best to provide company-wide support for the output of acquired knowledge and skills , such as presenting at external events and posting on the Tech Blog. In this article, I will introduce what we do before a Tech Blog article is released, the process of publication, and our efforts to promote output at each step of the process! The Tech Blog Project First things first, I would like to introduce our team, the Tech Blog Project of KINTO Technologies. We aim to promote the input and output of employee knowledge, starting with the operation of the Tech Blog. There are 8 members in the team, all of us holding concurrent positions. While working as a product manager or an engineer on other projects, we are always in the pursuit of fun ways to create output! https://www.wantedly.com/companies/company_7864825/post_articles/510568 The initiatives I'm about to introduce are part of our ongoing efforts to promote the Tech Blog Project! The Tech Blog Publishing Flow Our publishing flow is divided into 3 main phases. 1. Writing The first phase of the flow. The writing phase involves researching information, deciding on a theme, developing a plot, and composing the article. 2. Review The second is the review phase of the written content. At KINTO Technologies, we conduct a 3-step review to check for typographical errors and ensure the content of articles. 3. Release The third one is the phase of releasing articles. We translate the articles and release them via GitHub. Now, let me show you what kind of support we provide in each phase and what we are actually working on! Until the Tech Blog Article is Published First of all, I'd like to introduce you to the efforts of the Tech Blog team during the writing phase. Consultation Desk During the writing period of the Advent Calendar, us Tech Blog team members take turns to be on call for an hour each day in a huddle meeting on a Slack channel, creating a system where writers could ask questions freely and clarify any doubts in their process. Up to 5-6 people would join the huddle per day, and was used as a place and time to solve minor issues in writing or ask how to convert into markdown format, etc. In fact, we received comments such as "I recommended the Consultation Desk to others!" It was more well received than I expected. ✨ Interviews with Writers For those who think "I can't come up with a story, but I want to write something!" or "I have a story, but I'm not sure how I can make it into a good article," the Tech Blog team is available for interviews with you. The interview takes about 30 minutes and focuses on what kind of work you've been doing since joining the company, as well as how you solve problems and issues in each task. Moreover, based on the results of the interview, we will even make a plot of the article within the interview time. Through the interviews, we aim to bring out the best in everyone who is worried about writing articles, by lowering the hurdle and by reminding them how valuable the work they do every day is. In addition, the content of the article is focused on their relevant work. We ensure to promote everyone’s output, not only creating what is commonly referred to as tech content but also the output of skills from support functions, such as management and office environment, ensuring that all team members contributing to the maximization of technology also bring valuable output. Review After the articles are written, we go through a 3-step review from different perspectives. The goal is to ensure the quality of the article through a 3-step review and to create an article easy to understand from a readers point of view. We also emphasize expressing gratitude to the writer when conducting reviews. Content Review First, we conduct a content review to ensure the accuracy of the article's content. This review is conducted by the writer’s team members or managers, mainly in the below terms. Most articles undergo reviews by 2 to 3 or more reviewers, who provide feedback on suggestions for more reader-friendly expressions and praising its good points as well! Review Perspectives ･ Verify the accuracy of the content as a Subject Matter Expert ･ Check for confidential information The Tech Blog Team Review Next is a review by the Tech Blog Team. We check from the following perspectives: While valuing the tone and voice of the writers, we suggest reader-friendly sentences and article structure, and check for orthotypographical errors such as proper use of prepositions. We also strive to see the article from the reader's point of view, suggesting to add more context in some cases. Review Perspectives ･ Ortotypographical errors ･ Copyright While I mostly review content as a Tech Blog team member, it's interesting to learn and discover new ideas as a reader, such as "JIRA can track the deployment history of GitHub!", and it makes me want to try out these review guidelines in my own projects as well. The CIO Review The final review is from our CIO, Mr. Kageyama . All articles are reviewed by him, and upon his approval, the article is ready for release. I personally believe that this review process helps writers release articles with confidence. Release After all reviews are completed, we make final adjustments for the release. Here, I'd like to introduce "Translation of Articles," where we place particular emphasis on! The Translation of Articles About 25% of employees at KINTO Technologies are non-Japanese (as of November 2023). Therefore, some of our members want to write in their native language or are not too confident writing in Japanese. To meet their needs, writers can choose whether to write in either language and all articles are translated from Japanese to English or vice versa. A Language Service Provider (LSP), an external subcontractor, help us in the delivery of the base translation and the final LQA work is performed internally. LQA stands for Linguistic Quality Assurance. A text composed entirely from an external point view may inevitably lack the accuracy and context to convey the the author's original intent. These adjustment in expressions or spelling errors are checked during the LQA step. (Reference: Proactive Engagement of Foreign Employees ) Conclusion In this article, I have introduced the initiatives undertaken to promote output before the release of the Tech Blog to the public. I would like to continue to make improvements that contribute to a more effective work environment for our colleagues! I also hope that the content we share in the KINTO Technologies Tech Blog is helpful to you. Finally, I would be delighted to exchange ideas with you regarding the operation of Tech Blog and about technical PR! Please feel free to contact me through X with any comments you may have 🕊 https://twitter.com/KintoTech_Dev

Introduction Hello, I'm Risako from the Project Promotion Group of KINTO Technologies. I usually engage in various projects in the role of a Project Manager (PjM). In my previous article, I talked about my projects and what PjMs do at KINTO Technologies: How to Start a Cross-Divisional Project and Introduction to PjM Work . Feel free to take a look if you are interested. To provide you with a brief introduction to PjMs at KINTO Technologies: each product has basically its own development group or team, and is led by the Product Manager in each team. For projects that cross product lines, such as launching new services, or for projects that are large in scale even if they are not cross-divisional, a PjM will be assigned on the role of initiating and overseeing the project.  What we call projects include those related to KINTO's existing services such as KINTO ONE (vehicle subscriptions) or KINTO FACTORY, KINTO Technologies' owned media and services, and even new businesses launches under the KINTO brand, along with an array of diverse projects that need to be taken care of. New projects emerge daily and many may even start without clearly defined goals. Every time I embark on new projects, I feel the importance of the ability to move projects forward amid uncertainties, and well as the importance to advance myself too! In this article, I will share my thoughts on the theme of "the ability to move forward" and how that connects to the ability to be a “self-reliant person" ( Jiso-ryoku ).  What is Self-Reliance? Sorry that the intro became a bit lengthy. Now, what is self-reliance? We hear that word a lot in recent years (maybe especially in the job market). I think people have a general sense of what the word means, but it's not entirely clear to everyone. I looked up the definition and found that the term "self-reliance" ( Jiso-ryoku ) does not seem to have a precise definition, but Kotobank provides one under "self-relying." Running on its own power, not relying on the strength of others In other words, it refers to the ability to run (to progress or operate) through one's own capabilities. In the context of work, it can be expressed as "the ability to move forward with a task (and complete it under any circumstances) by one's own thoughts and actions." The part in the parentheses would be perfect if we could do that much! That would be ideal.  Self-reliance = running on your own power! So What Kind of Person Is a Self-Reliant One? I'd like to take a step further and ask, "what defines a self-reliant person?" Someone capable of advancing tasks even when goals are not clear. Someone who can move forward in the absence of defined methods. Someone who can create output from their own ideas, rather than simply imitating others. On the other hand, a person who is not self-reliant is the following (the opposite of people who can move forward by themselves!): Someone who can't work without instructions. Someone who assumes they can't do what they don't know about. Someone who only does what they are told to do. Notice that I wrote "move forward" or "advancing" for "a self-reliant person." But don’t get me wrong, I think that just self-propelling oneself left and right is not good either. "Someone who can properly move forward" is the really self-reliant one!  Don't run wild! Stay in control! How Can I Become a Self-Reliant Person? If there's a sure-fire way to become self-reliant, I’d like to learn about it. In the meantime, let me share what I try to keep in mind when I work on different projects. Value Dialogue When two people work together for the first time, it is natural that there will be gaps between them in many areas. Assumptions are easy to make, so we need to be careful to not presume things or make premature judgments. Instead, share your thoughts with each other. Relationships are formed by sharing ideas. Create Small, Output Small, and Value Feedback Under circumstances where there’s a lot of uncertainty, it’s normal to be afraid of creating deliverables or being assertive when communicating with the team. Start with small outputs to slowly bridge the gap with those around you. Don't view the opinions you receive as ineffectiveness on your part, but rather as feedback (do not take it negatively, but positively). Ensure that The Definition of Done is aligned Since the Definition of Done may vary from person to person, make sure the understanding is the same among all stakeholders. For example, imagine there’s a person assigned to review a team's operation and finishes it by themselves, adding just a manual change and closing it without consultation. But someone else in the team with different expectations, may have actually wanted this person to come back to the team to share what they did and ask for feedback (what is considered normal for you may not be the same for others). Do Not Worry Too Much about Unnecessary Problems Worry about them when the time is right (don’t stress over things that aren’t worth your energy now). It often happens that, even after reflecting very thoroughly, situations evolve differently when the need arises (in which case all that hard thinking was for nothing in the end). What is Value? Be aware of the purpose of the work, for whom and for what the end product is for, and the potential outcomes it will bring (as there is a bad tendency that the means become the purpose of it). When a change request arises during development, developers tends to think that a change mid-process is difficult. However, by considering the value and purpose of the project, they can be more easily convinced to embrace changes in a more positive manner, leading to a more satisfying outcome. Be aware of the meaning and the value you bring (as just doing what you are told doesn’t bring anything.) Be Aware of What You Can Do It's easy to see what you can't do, but be aware of what you can do (your value). For example, think about what has changed (or what you have accomplished) since you started. Identify new capabilities and understand what you can do now that you couldn't before. Learn From Others Be Aware of What You Like about the People around You! Being aware of what you like in others can sometimes bring you a little closer to what you consider good. For example, Mr. XX doesn't talk much, but the materials he makes are very easy to understand! What about them are easy to understand? If you look at it from that perspective, you may find tips on how to improve yourself. This list could go on and on, and I realized it’s somewhat becoming like a textbook... But to some extent, by trying to break down to fundamentals it might end up feeling a bit like a textbook... (For those of you reading, I hope there is at least 1 on the list that caught your eye and mind.) Self-Reliance and The Agile Mindset Some of you might have noticed a similarity to the Agile mindset in many of the things I've talked about today In order to form self-organizing teams rooted in Agile principles, I interpret that each person should be able to work autonomously and be self-sufficient. The foundation of this abilities can be found in Agile and Scrum, and I think these concepts were instilled in me through my previous experiences. The best architectures, requirements, and designs emerge from self-organizing teams. At KINTO Technologies, some groups adopt Scrum depending on the product, while others have a more Waterfall-type approach. However, regardless of approach, I think the overall mindset of KINTO Technologies is Agile (creating value in small increments and making iterative improvements with emphasis on dialogue and cooperation). If you are interested in working in an Agile mindset environment, we would be happy to have you join KINTO Technologies. Also, of course, if you want to demonstrate your self-reliance, you can do so to your heart's content at KINTO Technologies! We look forward to welcoming you. Conclusion Unfortunately, I barely gave any examples to give you an idea of what KINTO Technologies is really like, but I have primarily talked about conceptual issues. However, I would be delighted if this article could: provide examples for those who wonder what self-reliance is and be an opportunity for you to think about your own self-reliance.

はじめに こんにちは、11月入社の鈴木です！ 本記事では2023年11月入社のみなさまに、入社直後の感想をお伺いし、まとめてみました。 KINTOテクノロジーズに興味のある方、そして、今回参加下さったメンバーへの振り返りとして有益なコンテンツになればいいなと思います！ 白井 自己紹介 8月入社のプラットフォームGの白井です。AWSのインフラ設計・構築などを行なっています。入社エントリが面白そうだなー、と思い参加させていただいています！ 所属チームはどんな体制ですか？ Osaka Tech Labに2名。神保町オフィスに5名の7名体制となっています。 KINTOテクノロジーズ(以下KTC)へ入社したときの第一印象？ギャップはありましたか？ フルリモート環境から基本出社(週1~2は在宅)の環境に変わったので、少し戸惑う部分はありました。一方で、今では出社した方が話し合いがしやすいなと思ったので、プラスの印象です。 みなさん技術力が強いなという印象でした。私が元々インフラをずっと触っているというわけではなかったのかも知れませんが、最初は話を理解するのにも精一杯でした。 現場の雰囲気はどんな感じですか？ とてもアットホームです！基本出社しているのでTeamのメンバーに相談することがすぐできて助かっています。また、gatherを導入しており、在宅勤務時の時にも気軽に相談したい相手のところに行って聞くことができます。気軽に相談できるようになっている理由としては、アットホームな感じと、仕事外のことも良い感じに話し合える仲であるところかと思います。 ブログを書くことになってどう思いましたか？ 何事も挑戦だなーと思いました。KINTO TechBlogには良い記事がたくさんあると思っているので、その足がかりとしてはとても良いことだと思っています。実は私はすでに「 CloudFront FunctionsのDeployのプロセスと運用カイゼン 」というタイトルでアドベントカレンダーで執筆しているので、是非見てみてください！ 11月入社の同期から他部署のメンバーへ質問 会社内で同じ趣味を持つ人たちが集まるようなクラブや同好会はありますか？もしあれば、白井さんはどんな部に参加されていますか？ たくさんあります！ Tech Blog でも運動系のクラブが紹介されていました！ 私が参加しているのだと、紹介されていませんがランニングサークル(RUN TO)、e-sports部です！ AKD 自己紹介 コーポレートITG Operation Processチーム、同期の中で唯一のOsaka Tech Lab所属AKDです。コーポレートエンジニアをやっています。いわゆる情シスです。 所属チームはどんな体制ですか？ 当社のPCや各SaaSに関するオン/オフボーディングや各プロセスの可視化や改善を4名体制で担っています。 KTCへ入社したときの第一印象？ギャップはありましたか？ エンジニアの会社だし、そんなにコミュニケーションはないのかも…と思ってましたが定期的に勉強会や部長会議事録を読む会などコミュニケーションの機会は多々あり、そこがいいギャップでした。 現場の雰囲気はどんな感じですか？ 皆さん、いい意味で遠慮することなく、お互いを尊重した関係性を築いているように感じています。 コーポレートITGは室町・神保町・名古屋・大阪にメンバーが在籍しており、またチームも5つあって大所帯ではありますがコミュニケーション用の常設Zoomがあり、そこで拠点やチームを超えた会話が行われていてよい空気が流れているように思います。 ブログを書くことになってどう思いましたか？ 入社エントリってみたことあるけど、選ばれた人が書くのかと思いきや全員書くのか！と思いました。あとシンプルに中途だけど、同期感があって好きです。 11月入社の同期から他部署のメンバーへ質問 1ヶ月経って感じた、Osaka Tech Labの雰囲気を教えてください。 包容力が高い拠点で出張されてくる方、新入社員の方、誰でもwelcomeな雰囲気があります。 SSU 自己紹介 KINTO ONE開発GのSSUです。ディレクターとして、トヨタの販売店に対するDX支援開発のディレクションを担当しています。 所属チームはどんな体制ですか？ オウンドメディア＆インキュベートGのDX Planningチームに所属しています。トヨタ販売店の中でのボトルネックをIT の力で解消し、お客様へ幅広いモビリティの選択肢を届けるということが チームミッションです。プロデューサー２名、ディレクター３名、デザイナー２名の計７名で業務にあたっています。 KTCへ入社したときの第一印象？ギャップはありましたか？ 自動車業界というイメージよりも若い人が多く、自由度も高いというのが第一印象です。 現場の雰囲気はどんな感じですか？ まだ入社１ヶ月ですが、DX Planningチームは個性豊かでみなさんそれぞれ違うなという感じです。一緒に案件を進める中で、MTGや個別にコミュニケーションをとると、この違いによって自分が気づけないことに気づけるのでチームの強みだなと思います。 ブログを書くことになってどう思いましたか？ 人生で初めてのブログが、とうとうきたか、と思いました。 11月入社の同期から他部署のメンバーへ質問 KTCのSlackワークスペースで一番好きな絵文字を教えてください。 キノコがすごい顔で走っている生き急いでる絵文字が好きです。 kiki 自己紹介 人事採用Gのkikiです。採用業務とテックブログ運用PJTにも参加しています。 所属チームはどんな体制ですか？ 採用チームは現在（2023年12月時点）私含め6名です。個性豊かなメンバーがいて、全員が全員の業務に関心を持ちながら切磋琢磨しあいながら日々採用業務に携わっています。 KTCへ入社したときの第一印象？ギャップはありましたか？ 思った以上にフラットでオープンだと思いました。人事という立場もあるかもしれませんが、誰が言ったからという理由で議論が進むことは少なく、妥当性があるかやチームの動き方として「今の最善は何か」という観点で仕事を進めることが多いように感じます。 入社2週目でOsaka Tech Labの情報共有会に参加させて頂く等、すぐに仲間のように迎えてくれて温かい人が多いな、という印象です！ 現場の雰囲気はどんな感じですか？ 話しやすい空間を作るために、敢えて雑談を挟んだりすることも多く組織や人の状況に常にアンテナを張れる環境です。入社したばかりだからといって、最初の2週間位はかなり遠慮していたのですが、採用業務は完全に未経験という訳ではないため、気づいたことや入社したばかりの新参者だからこそ、「ここどうなってるの？」という疑問については都度都度議論しやすい空気感で、その点は有難いです。 ブログを書くことになってどう思いましたか？ シンプルに「嬉しい！」が感想です。テックブログ運用PJTのメンバーも入社初月から関わらせてもらっています。外部発信は積極的に行ってきていないので、問題発言をしていないか、気にしてしまうけれど文章を書くことは好きなので良い実験場という認識をもっています。 11月入社の同期から他部署のメンバーへ質問 ストレス発散方法を教えてください。 普段そこまで聴かないロックを聴いて発散します。Franz Ferdinand、夜の本気ダンスが特に良いです。また、自宅で変なダンスをすると発散できると何かの記事で読んでからは、人目につかないようなら自宅等では踊るようにしています。（めっちゃおススメです！） Y.Suzuki 自己紹介 プロジェクト推進Gの鈴木です。 KINTO FACTORYのフロントエンドエンジニアを担当しています。 所属チームはどんな体制ですか？ 業務委託の方や部署を兼務されている方はいらっしゃるもののマネジメントから実装までKTCのメンバーで構成されたチームです。 その中でフロントエンドは12月にも新たなメンバーが増え6名体制になっています。 KTCへ入社したときの第一印象？ギャップはありましたか？ 入社前は平均年齢も高く事業会社になるのでもっとお堅い環境かと思っていました。入社してみるとフラットなコミュニケーションも豊富で、新しい取り組みや面白いって思えることには寛大でした。 自分よりも年齢や役職の高い方々は経験を活かしながらも遊び心を持ち探究心が高く、カジュアルさと大人の雰囲気をうまく兼ね備えている方が多い環境だなと思いました。 前職は在宅中心だったため出社と在宅のハイブリットの勤務は通勤も辛いし少し嫌かもと思っていましたが、「環境に馴染みやすいし、ハイブリットすごくいい」って気持ちです😳 現場の雰囲気はどんな感じですか？ とにかく最初はわからないことが多いのでお互いに話しやすい人間関係を作らなければと思い入社して１週間経たないくらいの頃デスクで「ねるねるねるね」を食べてみました。みなさんと雑談が生まれ微笑ましく接してくださり、最近はチームのメンバーと仕事の話をしながら みかん を一緒に食べています。 「実はエンジニア業務以外にもこんなこともできるんです」と1on1や食事の場で話したところ「そういうのできる人あまりいないからうまく活かせないか相談してみる」と入社２週間の頃にお話いただき、現在フロントエンド業務にとどまらずプロダクトをよくしていくための業務拡大を模索中です！ 出社でタイミングが合えばみんなでランチも行き、業務にとどまらずコミュニケーションとる機会も多めです。 ブログを書くことになってどう思いましたか？ エンジニアのブログは技術を中心に扱うのですでに存在している内容だったり、たくさんの検証が必要だったり、そもそもお題を決めるの含め書くのはハードルが高い印象でした。今回は純粋に入社エントリだったのでKTCに興味を持っている方に良い情報を伝えられたらなと思いました。 11月入社の同期から他部署のメンバーへ質問 仕事していて一番楽しいと思う瞬間を教えてください。 簡単なことでも相談を受ける時です。まだ入社間もないのですが頼ってくれる部分や自分にもでできることもあるんだなと思うと嬉しいです。できることの幅を増やせるように他の方の尊敬できるところもっと吸収していこうって思っています。 T.F 自己紹介 プロジェクト推進G のT.Fです。 KINTO ONE中古車のバックエンド担当しています。 所属チームはどんな体制ですか？ フロントエンド・バックエンド・BFF(backend for frontend)をそれぞれ社員と協力会社の方で担当しています。 KTCへ入社したときの第一印象？ギャップはありましたか？ 入社してすぐに有給取得できるのに驚きました。引越しを考えているので助かります。 現場の雰囲気はどんな感じですか？ 親切な方が多いです。質問や提案がしやすい雰囲気です。 ブログを書くことになってどう思いましたか？ 入社前の読者だった立場から執筆側になり、不思議な感覚です。 11月入社の同期から他部署のメンバーへ質問 入社１ヶ月での業務内容を教えてください。 まだ入社したばかりなので簡単なことしかしていないです。 小さめの開発やコードレビュー、来年から本格始動する予定の案件の見積もりなどをしました。 ドメイン駆動設計やクリーンアーキテクチャなどの設計を取り入れようと水面下で動いてます。 A.N 自己紹介 共通サービス開発GのA.Nです。 KINTO IDの基盤となる会員プラットフォームのPdMを担当しています。 所属チームはどんな体制ですか？ ６名体制です。（協力会社さん含む） KTCへ入社したときの第一印象？ギャップはありましたか？ 入社初日から風邪をひいてしまい、ついに3日目にダウンしてしまったのですが、初月から傷病休暇を支給されていて助かりました。 現場の雰囲気はどんな感じですか？ マネージャーの方針もあると思いますが、各メンバーの自由を尊重している雰囲気です。皆さんエキスパートなので、自律的に行動されていますね。 ブログを書くことになってどう思いましたか？ 会社のパブリックリレーションズに少なからず影響があると思うと恐れ多いですね。 11月入社の同期から他部署のメンバーへ質問 KTCには趣味や業務外活動のSlackチャンネルがありますが、気になったのありますか？ ちょうど今日教えていただいたのですが、毎朝出社したらただ「グッドモーニング！」とコメントするだけというチャンネルです。なぜこのようなチャンネルを作ったのか謎ですが、参加されている皆さんが楽しそうなので癒されます。 F.T 自己紹介 モバイルアプリ開発GのF.Tです。Android版のUnlimitedアプリを担当しています。 所属チームはどんな体制ですか？ Androidチームは私含め5名体制で開発しています。 KTCへ入社したときの第一印象？ギャップはありましたか？ 中途入社にもかかわらず、オリエンテーションがしっかりあったことに驚きました。 オフィス内でのチームの境目が（物理的にも心理的にも）少ないのがすごいと感じました。 （Android開発者での勉強会があったり、担当アプリ内でOS関係なくコミュニケーションがあったり） 現場の雰囲気はどんな感じですか？ 黙々と作業できる時間が多いです。ただ、困った際はすぐに質問できる優しい雰囲気があります。 ブログを書くことになってどう思いましたか？ 不安でいっぱいでした。 11月入社の同期から他部署のメンバーへ質問 入社して１ヶ月、この会社に入って良かったと思うことは？ エンジニアとしてレベルの高い環境で仕事をできているのが素直に嬉しいです。 多趣味な方が多く、業務外での学びも多いです。 W.Song 自己紹介 データ分析GのデータエンジニアリングチームのW.Songです。主にデータの連携を担当しています。 所属チームはどんな体制ですか？ チームリーダーとメンバー合わせて4人です。 KTCへ入社したときの第一印象？ギャップはありましたか？ 会社に本棚があるのはすごいですね。人気な本がたくさんあり、皆さんの勉強意欲が高いと感じています。 実際はギャップよりも、自分の思い込みかもしれません。入社前にOfficeの写真を見たことがあり、特にジャンクションの写真がとてもおしゃれに見えたんです。フリーアドレスかと思い込んでいました。 現場の雰囲気はどんな感じですか？ ゆっくり話せるかなと思っています。皆忙しい中、丁寧な説明をしてもらえました。本当にありがたいです。久しぶりにたくさんコミュニケーションを取れる環境だと感じます。 ブログを書くことになってどう思いましたか？ 本当に素晴らしいアウトプット方法だと思います。自分のアピールだけでなく、同じ悩みや考えを持つ人たちとつながり、仲間も作れると感じます。 11月入社の同期から他部署のメンバーへ質問 KTCに入社したことで変わったことはありますか？ 車に興味が深まっています。 週３回出社しているので、前より痩せたはずです。 絵文字😇 の印象すごく変わりました。 以前は「嬉しい、やったー、うまくいった」という意味だと思ってよく使っていましたが、「もうダメ、オワタ」と知って驚きました。 さいごに 入社直後の慌ただしい中みなさま感想を教えてくださりありがとうございました！ KINTOテクノロジーズは新しいメンバーも日々増えています。 今後もいろんな部署に配属されたメンバーの入社エントリが増えていくと思いますので楽しみにしていただけたら幸いです。 そして、KINTOテクノロジーズでは、さまざまな部署・職種で一緒に働ける仲間を募集しています！ 詳しくは こちら から

Hello! I am Tsun-Tsun, a member of the Labor Affairs and General Affairs team in the Human Resources group. We are working to improve office spaces while listening to the voices of our employees. Today, I will talk about what we improved in 2023. Nihonbashi Muromachi Office Placing Miniature Toyota Cars at the Reception Area KINTO Technologies mainly develops mobility services under the KINTO brand, including a vehicle subscription service. One day, an employee said, "We're a vehicle company, but there aren't a lot of vehicle-related elements around the office." I thought, "In that case, let's put some miniature cars." 🔻16F reception area These are Toyota models. They made the reception area lively, but sorry! They're not for sale. By the way, do you know what models they are? Upper row, from left: GR Supra, Sienta, Voxy, GR Yaris, Harrier, Land Cruiser Lower row, from left: Prius, Crown, bZ4X, Corolla Sport, RAV4 🔻7F reception area From the rear left: Harrier, Yaris, Corolla Cross, Passo, and Alphard From the rear left: Corolla, Aqua, GR Yaris, C-HR, Yaris, Roomy Reviewing Work Styles After COVID-19 Was Reclassified as a Class 5 Disease When COVID-19 was reclassified as a Class 5 disease in Japan, the company relaxed some of its restrictions on going to the office, and we used a hybrid work style that involved both working at home and working at the office. Because the restrictions were relaxed, more employees started going back to the offices. We got requests from employees like “I want private booths” and “we need bigger meeting rooms." So, we added more meeting rooms and made two areas for casual meetings. For the meeting rooms, we furnished two unused rooms with smoked glass and air conditioners and added a reservation system for them.   These two rooms can be used now anytime. We've introduced two types of informal meeting spaces. The first is private booths. We use KOKUYO's Fore series.   The area with the booths has windows, so to keep the booths from getting too hot in the summer, we chose a type that wasn't surrounded on all four sides. The second type of meeting area has desks. We use KOKUYO's Join series.  Bottom picture  The chairs have a round bottom and move like a balance ball. Jinbocho Office Greening Plan The Muromachi Office has plants in resting areas, the entrance, and other areas, but the Jimbocho Office has barely any greenery. Some employees commented that they were sad without any plants, so the Jimbocho Office started a greening plan to increase the number of houseplants. Below is a picture of the greening plan for the office and conference room.   Continuing to Improve Office Environments Next year, we will work on more improvements to our office. We have plans to renovate the break room as part of our initiative to improve communication internally. When they are complete, we will announce it here on the Tech Blog too. I go around the office every day, and I can sense the company growing. The Office Changes with the Times I feel that more and more companies are adopting hybrid work styles after the COVID-19 pandemic. I predict that there will be a demand for offices that support hybrid work styles and to crate spaces that make people want to be there. In particular, since our company has employees of various ages and nationalities, we want to create an office environment that accommodates all kinds of people with different values. Lastly, since it is hard to find information on how other companies' facilities are, I wrote this with the hope that it may serve as a helpful reference for others. The KINTO Technologies Advent Calendar is still going on, so I hope you look forward to what’s in store tomorrow!

Introduction Hello! I am Jeong, and I am a member of KINTO Technologies' New Vehicle Subscription Development Group. Our daily work goes beyond just writing code. As technology evolves, it is important to adapt to new trends such as microservices and serverless architecture while maintaining a healthy system. After reading this article, you will understand the importance of observability and how Grafana is used to monitor systems and optimize performance. About Observability Observability refers to the ability to monitor and understand the condition and performance of a system. This concept is essential for quickly identifying and resolving problems within the system. Especially when it comes to microservices and cloud-based architecture, as there are composed of many dynamic parts working together, the entire system must be continuously monitored. There are three main elements of observability: Log: Detailed data that records system activity and errors Metrics: Quantitative data that describes the performance and conditions of a system Trace: Data that tracks the path of an E2E[^1] request or transaction [^1]: E2E (End-to-End): A system or process that works as a whole from start to finish About Grafana Grafana is a powerful open source observability tool. It is used by many to visualize, monitor, and analyze data. Grafana is best characterized by its flexibility and customizable dashboards. Users can integrate metrics and logs from different data sources and present them in a way that is easy to understand. Grafana's key benefits include: Supports various data sources: Can be integrated with Prometheus, Elasticsearch, InfluxDB, and more Data analyses and alerts: Instantly detects system anomalies and sends alert notifications Dashboard: The dashboard can be customized to meet the user's needs Grafana in Action: Focus on Clarity The New Car Subscription Development Group uses Grafana’s dashboard to make data easier to understand for people from different technical backgrounds. In this section, I will give an example of PromQL query and talk about its features that are used in the dashboard panel. Monitoring API Requests  Number of contracts #the value is a sample The most basic query tracks the number of HTTP requests for URI patterns. This query shows the increase or decrease in the number of requests over a time range and is useful for trend analyses. sum( increase( http_server_requests_seconds_count{ uri=~”/foo”, method=“POST”, status=“200” }[$__range] ) ) or vector(0) sum(...): An aggregating function that sums the results. Here, we calculate the total number of requests that meet the criteria. increase(...): Calculates the amount by which a metric over a time range. You can find the increase or decrease in the number of requests. vector(0): Returns 0 if there is no result. This exists so that a value is displayed on the dashboard even if there is not data. Measuring the Number of Applications per Hour  Number of applications by time zone (sample) #sleeps at night Use PromQL which monitors API requests to measure the number of requests per hour and find changes in demand per time zone. This is used as reference data for dynamically allocating resources for different time zones and doing other applications. Identifying the Time-Consuming Requests  There are also those that take 4 seconds or longer When doing performance analyses, identifying requests that take longer is critical to finding bottlenecks in the system. The following PromQL query can help. Calculating the Average Response Time Calculate the average response time for each request. Determine the total response time and the number of requests, then divide them. sum by(application, uri, outcome, method) ( increase(http_server_requests_seconds_sum[$__range]) ) / sum by(application, uri, outcome, method) ( increase(http_server_requests_seconds_count[$__range]) ) sum by(...): Groups results based on the labels (here, they are application, uri, outcome, and method) and calculates the sum of each group. increase(...): Calculates the amount by which a metric over a time range ($__range). Here we calculate the total response time and the number of requests. Aggregating the Number of Requests Aggregate the number of requests. sum by(application, uri, outcome, method) ( increase(http_server_requests_seconds_count[$__range]) ) Identifying the Requests with the Longest Response Times Identify the ten requests with the longest response times in the time range. topk( 10, max( max_over_time(http_server_requests_seconds_max[$__range]) ) by(application, uri, outcome, method) ) topk(10, ...): Returns the ten elements with the highest values. Here, we list the ten requests with the longest response times. max(...): Calculates the largest value for each group. max_over_time(...): Calculates the largest value for each metric within a time range and groups the results by label. This allows you to extract the requests with the longest response times. Client-Side Error Monitoring  Authentication token expired Monitor for errors occurring on the client side and analyze the cause. label_replace( sum by (application, method, uri, exception, status) ( increase(http_server_requests_seconds_count{ status=~”5..|4..”, exception!~”None|FooException” }[$__range] ) ) > 0, ‘uri’, ‘$1/*$2’, ‘uri’, ‘(.*)\\/\\{.+\\}(.*)’ label_replace(...): Changes and adds labels. '> 0': Returns the result if the sum is greater than 0. In other words, it displays data only if there is an error. Advantages of Grafana and Use Cases Learn more about how New Car Subscription Development Group used Grafana to improve their system monitoring. Comprehensive system visualization: With AWS Managed Grafana, we can visualize data from AWS services (RDS, SQS, Lambda, CloudFront, etc.) and application metrics at the same time. This means we can see the performance and bottlenecks of the entire system at a glance, greatly accelerating our approach to problem solving. Efficient data analysis and troubleshooting: By integrating different data sources, you can quickly get the information you need when a problem arises. This allows you to quickly identify the root cause of a problem and handle it efficiently. API Monitoring: Through Grafana, we discovered that certain exceptions are strangely common. As a result of our investigation, we found that an unexpected API was being called on the frontend. This issue was communicated to the frontend team and fixed, making the API more efficient and significantly improving the overall stability and performance of the system. Conclusion Observability is more than just looking at a system. It is the key to maintaining the conditions of a system and ensuring that problems can be dealt with quickly when they arise. With Grafana, we can easily understand complex data and effectively manage the performance of entire systems. Grafana caters to a variety of needs from monitoring API requests to identifying errors. This is worth cooperating with all team members, not just SREs and developers. After all, increasing the transparency and reliability of a system is essential to providing better service and increasing customer satisfaction. I hope that our experience will provide you with a new perspective in your work and help you monitor your systems more efficiently and optimize performance.

社内限定のLT大会を開催しました！ こんにちは、23年10月にKTCに入社したRyommです。普段は my route by KINTO というアプリのiOS開発を行なっています。 さて、今回は弊社の室町オフィスにて社内限定のLT大会を開催したので、みなさまにもお裾分けのレポートです！ 開催までの経緯 直属のボスとの1on1にて「最近人前で喋ってないからラフなLT大会とかやりたいっすね〜」という話になり、他のオフィスでは情報共有会という名目でやってるらしいという情報を得ました。 そこで、 (11月21日)timesでやりたいな〜と言ってみたところトントン拍子で話が進み... timesの様子 (11月27日)有志で集まってキックオフMTGが開催され... 実行委員チャンネルの様子 (11月29日)全社員が参加する会議での告知と室町オフィスへの周知がされ...  室町オフィスチャンネルの様子 かわいいチラシ作りました (12月14日)タイムテーブルを発表し...  かわいいタイムテーブルも作りました (12月21日)LT大会を実施しました！ 会場の様子 ちょうどやりたいと言い出した時から1ヶ月という圧倒的なスピードでLT大会の開催が実現しました！ テックブログチームをはじめ多くの方が積極的に参加してくれたおかげで、とても楽しい会になったのではと思います。 さらにコーポレートITグループの方々にも協力していただき、かなり本格的なZoom配信を行うこともできました！ 発表者も集まるかな〜と不安でしたが、12名の方にエントリーしていただきました。（中には名古屋からいらっしゃる方も！） 最初は本当にノリと勢いだけで動き出したので、みんなで協力して形にできたLT大会だったと思います。 Lightning Talks 発表してくれたLTを、社内限定ということで色々とゆるめにしていたので全てを公開できるわけではないですが、一部ダイジェストで紹介します。 GitHub Flow+Release PleaseによるTag Based Release ⛩さんによるLTです。 GitHub Flow（Git Flowとの比較含む）、Tag Based Release、Release Pleaseそれぞれについての解説と、これらを統合すると自動でCHANGELOGを生成してくれたり、バージョン管理を簡素化できて便利だというLTでした！ 私としては、別バージョンの開発が同時に走っていて、ある機能はまだ公開したくない！というお悩みにも応えてくれていて、Release Please使ってみたいな〜と思いました！ ⛩さんのLT モータースポーツ最高峰「F1 (Formula 1)」のマニアックな楽しみ方 mt_takaoさんによるLTです。 F1の面白さを布教するLTでした。自動車を扱う会社ならではのLTですね！ F1の世界では1秒差は非常な大きな差であり、1000分の1秒差をどうやって埋めていくか、それがF1の面白さだと力説されていました。 最後には2024年4月5日（金）〜7日（日）に三重県の鈴鹿サーキットで開催される「2024 FIA F1世界選手権シリーズ MSC CRUISES 日本グランプリレース（F1日本グランプリ）」の宣伝で締められていました笑 私もぜひ1度見てみたいと思うLTでした！ mt_takaoさんのLT 1月開発編成本部会に向けて ありとめさんによるLTです。 ご自身のキャリアとそこで感じたこと、KTCへの想いと共に「イキイキと働く」ことができるように考えた施策のLTでした。 1月には社内ではじめての大規模イベントを開催されるということで、私も楽しみにしていますー！ KTCのこと発信してみませんか HOKAさんによるLTです。 ご自身の広報としての経験と、KTCで組織人事、採用まで関われる人事としてKTCの認知度をアップするための取り組み、そしてKTCについて発信しよう！というLTでした。 一番簡単な発信はXのリポストだということで、私も早速リポストしました😎✨ HOKAさんのLT Sketchy Investment​ 長谷川さんによるLTです。 英語を勉強することは超ハイリターンな投資！ということで、長谷川さん流の勉強術と英語学習の奨励LTでした！ 最後は会社に英語学習補助導入への検討の要求で締め括られ、会場は沸き立っておりました笑 私も英語...勉強しちゃうか...！？となるくらいエネルギーに溢れたLTでした！ 長谷川さんのLT LT登壇のハードルを限りなく下げるLT＋アジャイル会の告知 きんちゃんによるLTです。 LTは「自分が好き」とか「自分が素晴らしいと思う」ことを伝える場だと定義した上で、「あなたの属性×あなたの好き・得意」を伝えると、オリジナリティのある楽しいLTができるよ！と、参加した方がLTに出たくなるLTでした！ このLTのおかげか、開催後アンケートでも次回はLTに登壇したいと答えてくださった方が約70%ほどおり、「1番いいなと思ったLT」投票においても最多票を獲得したアツいLTでした。 きんちゃんのLT テックブログ執筆が３年後のキャリアに与える影響 なかにしさんによるLTです。 テックブログの執筆を続けていくことで、スキルも向上していき、遂には本も出版できる！というLTでした。 実物を持ってこられていましたが、1087pの分厚い本で、テックブログを書き続けるとこんなに分厚い本を出版できるのかー！？と、驚きました。 https://www.amazon.co.jp/dp/486354104X/ 面倒な予定調整はBookingsにやらせよう 技術と信頼の技信さんによるLTです。 Microsoft Bookingsを使うと、日程調整をはじめ、予約サイト作成やTeams/Outlook連携、アンケート、リマインドメール等を簡単に行うことができるよ、というLTでした！ 実際に今年の健康診断で使用され、参加者の方も「あれか〜」というような反応をしている方も何人かいました。（私は入社前でしたが...） Exchangeを基にしたサービスで、不安定さや想定外の事態が起こることもある...と話してくださった実体験も面白かったです。 私も飲み会の幹事になった時に使ってみようかな〜と思いました！ 早速使っている！ 5分で「モータースポーツ」を見に行きたくさせるLT シナモロールさんによるLTです。 国内で観戦するおすすめのモータースポーツを7つピックアップし、ぜひサーキットに足を運んで観戦してみてほしい、というLTでした！ サーキットの観戦ではエンジン音、臨場感・迫力、コース実況、会場での展示物、クルマでの移動などサーキットならではの良さがあり、一度でいいから体感してみてほしいと力説されていました。 そして、サーキットまでの移動はクルマで行くのが断然おすすめ！やっぱクルマいいな→クルマのサブスクKINTO→KINTOかんたん申し込みアプリ使ってね！と、担当サービスの宣伝まで抜かりないシナモンさんでした笑 KINTOがスポンサーをしているチームのユニフォームを着て発表されており、好きが伝わる良いLTでした！ シナモロールさんのLT クソアプリ作って煙突詰めた♪ あわてんぼうの Ryomm・クロースによるLTです。 個人開発をするにあたってアドベントカレンダー駆動を提案し、自身の体験として「クソアプリハッカソン」「クソアプリアドベントカレンダー」に参加した話をしたLTです。 このLTをした後、3日でクソアプリアドベントカレンダーに挑んでくれた方もいて、嬉しかったです！ RyommのLT LTを受けてアドカレ書いてくれました https://speakerdeck.com/ktcryomm/kusoapurizuo-tuteyan-tu-jie-meta Corporate IT: A new journey! フローさんによるLTです。 ご自身のキャリアとコーポレートITグループでの仕事、将来の展望などのLTでした！ KTCの従業員がHappyに働けるようにする仕事だ、と話すフローさんが眩しかったです...！笑 さいごに 社内限定とすることでカジュアルに人前で話す場を作ることができ、社員同士の交流の場ともすることができて楽しいイベントになったのではないかと思います。 室町情報共有会の旗揚げイベントとして大成功だったはず！ 個人的な工夫点としては、KTCは割とSlackが静かな方なのでテキストコミュニケーションを活発に行なってもらおうと、実況chを作成してオンラインでもオフラインでも一緒に盛り上がれるようにしたことです。 同時に記録として残すことができるので後から見返してもLTに対する反応などを確認できますし、今回不参加だった方にも次は参加したいと思ってもらえるような盛り上がりを視覚化することができたのではと思います。 アンケート等もSlackワークフローを通してスプレッドシート等に収集することで、極力Slackから離脱せずに楽しむことができるようにしました。 反省点としては、配信で使用したZoomウェビナーのチャットは無効化したのですが、リアクションは有効にしたままだったので、そちらのみで見ている層が一定数いらしゃったことでしょうか。次回以降に活かしていきたいです。 今回はホリデーシーズンだったので、せっかくだからクリスマスも楽しんでいきましょう！とクリスマスコスやシャンメリーなどを用意しましたが、意外な発見としてイベントごとに合わせると軽食が決めやすい！というものがありました。 参加者からも有志からも第二回を開催してほしい！という声をいただいたので、次回も何かイベントごとと絡めたいなと思っています。 LT大会後に忘年会があったのですが、他オフィスの方も配信で見てくださっていたようで「見たよ〜」と声をかけていただいて嬉しかったです。発表者の方も「発表見たよ〜」と感想をもらって嬉しかったと言っており、開催してよかった〜！と感じました。 今後も、こういうカジュアルな発表の場を設けていくことで、社内のいろいろな人の話が聞けたらいいな〜と思います。

社内限定のLT大会を開催しました！ こんにちは、23年10月にKTCに入社したRyommです。普段は my route by KINTO というアプリのiOS開発を行なっています。 さて、今回は弊社の室町オフィスにて社内限定のLT大会を開催したので、みなさまにもお裾分けのレポートです！ 開催までの経緯 直属のボスとの1on1にて「最近人前で喋ってないからラフなLT大会とかやりたいっすね〜」という話になり、他のオフィスでは情報共有会という名目でやってるらしいという情報を得ました。 そこで、 (11月21日)timesでやりたいな〜と言ってみたところトントン拍子で話が進み... timesの様子 (11月27日)有志で集まってキックオフMTGが開催され... 実行委員チャンネルの様子 (11月29日)全社員が参加する会議での告知と室町オフィスへの周知がされ...  室町オフィスチャンネルの様子 かわいいチラシ作りました (12月14日)タイムテーブルを発表し...  かわいいタイムテーブルも作りました (12月21日)LT大会を実施しました！ 会場の様子 ちょうどやりたいと言い出した時から1ヶ月という圧倒的なスピードでLT大会の開催が実現しました！ テックブログチームをはじめ多くの方が積極的に参加してくれたおかげで、とても楽しい会になったのではと思います。 さらにコーポレートITグループの方々にも協力していただき、かなり本格的なZoom配信を行うこともできました！ 発表者も集まるかな〜と不安でしたが、12名の方にエントリーしていただきました。（中には名古屋からいらっしゃる方も！） 最初は本当にノリと勢いだけで動き出したので、みんなで協力して形にできたLT大会だったと思います。 Lightning Talks 発表してくれたLTを、社内限定ということで色々とゆるめにしていたので全てを公開できるわけではないですが、一部ダイジェストで紹介します。 GitHub Flow+Release PleaseによるTag Based Release ⛩さんによるLTです。 GitHub Flow（Git Flowとの比較含む）、Tag Based Release、Release Pleaseそれぞれについての解説と、これらを統合すると自動でCHANGELOGを生成してくれたり、バージョン管理を簡素化できて便利だというLTでした！ 私としては、別バージョンの開発が同時に走っていて、ある機能はまだ公開したくない！というお悩みにも応えてくれていて、Release Please使ってみたいな〜と思いました！ ⛩さんのLT モータースポーツ最高峰「F1 (Formula 1)」のマニアックな楽しみ方 mt_takaoさんによるLTです。 F1の面白さを布教するLTでした。自動車を扱う会社ならではのLTですね！ F1の世界では1秒差は非常な大きな差であり、1000分の1秒差をどうやって埋めていくか、それがF1の面白さだと力説されていました。 最後には2024年4月5日（金）〜7日（日）に三重県の鈴鹿サーキットで開催される「2024 FIA F1世界選手権シリーズ MSC CRUISES 日本グランプリレース（F1日本グランプリ）」の宣伝で締められていました笑 私もぜひ1度見てみたいと思うLTでした！ mt_takaoさんのLT 1月開発編成本部会に向けて ありとめさんによるLTです。 ご自身のキャリアとそこで感じたこと、KTCへの想いと共に「イキイキと働く」ことができるように考えた施策のLTでした。 1月には社内ではじめての大規模イベントを開催されるということで、私も楽しみにしていますー！ KTCのこと発信してみませんか HOKAさんによるLTです。 ご自身の広報としての経験と、KTCで組織人事、採用まで関われる人事としてKTCの認知度をアップするための取り組み、そしてKTCについて発信しよう！というLTでした。 一番簡単な発信はXのリポストだということで、私も早速リポストしました😎✨ HOKAさんのLT Sketchy Investment​ 長谷川さんによるLTです。 英語を勉強することは超ハイリターンな投資！ということで、長谷川さん流の勉強術と英語学習の奨励LTでした！ 最後は会社に英語学習補助導入への検討の要求で締め括られ、会場は沸き立っておりました笑 私も英語...勉強しちゃうか...！？となるくらいエネルギーに溢れたLTでした！ 長谷川さんのLT LT登壇のハードルを限りなく下げるLT＋アジャイル会の告知 きんちゃんによるLTです。 LTは「自分が好き」とか「自分が素晴らしいと思う」ことを伝える場だと定義した上で、「あなたの属性×あなたの好き・得意」を伝えると、オリジナリティのある楽しいLTができるよ！と、参加した方がLTに出たくなるLTでした！ このLTのおかげか、開催後アンケートでも次回はLTに登壇したいと答えてくださった方が約70%ほどおり、「1番いいなと思ったLT」投票においても最多票を獲得したアツいLTでした。 きんちゃんのLT テックブログ執筆が３年後のキャリアに与える影響 なかにしさんによるLTです。 テックブログの執筆を続けていくことで、スキルも向上していき、遂には本も出版できる！というLTでした。 実物を持ってこられていましたが、1087pの分厚い本で、テックブログを書き続けるとこんなに分厚い本を出版できるのかー！？と、驚きました。 https://www.amazon.co.jp/dp/486354104X/ 面倒な予定調整はBookingsにやらせよう 技術と信頼の技信さんによるLTです。 Microsoft Bookingsを使うと、日程調整をはじめ、予約サイト作成やTeams/Outlook連携、アンケート、リマインドメール等を簡単に行うことができるよ、というLTでした！ 実際に今年の健康診断で使用され、参加者の方も「あれか〜」というような反応をしている方も何人かいました。（私は入社前でしたが...） Exchangeを基にしたサービスで、不安定さや想定外の事態が起こることもある...と話してくださった実体験も面白かったです。 私も飲み会の幹事になった時に使ってみようかな〜と思いました！ 早速使っている！ 5分で「モータースポーツ」を見に行きたくさせるLT シナモロールさんによるLTです。 国内で観戦するおすすめのモータースポーツを7つピックアップし、ぜひサーキットに足を運んで観戦してみてほしい、というLTでした！ サーキットの観戦ではエンジン音、臨場感・迫力、コース実況、会場での展示物、クルマでの移動などサーキットならではの良さがあり、一度でいいから体感してみてほしいと力説されていました。 そして、サーキットまでの移動はクルマで行くのが断然おすすめ！やっぱクルマいいな→クルマのサブスクKINTO→KINTOかんたん申し込みアプリ使ってね！と、担当サービスの宣伝まで抜かりないシナモンさんでした笑 KINTOがスポンサーをしているチームのユニフォームを着て発表されており、好きが伝わる良いLTでした！ シナモロールさんのLT クソアプリ作って煙突詰めた♪ あわてんぼうの Ryomm・クロースによるLTです。 個人開発をするにあたってアドベントカレンダー駆動を提案し、自身の体験として「クソアプリハッカソン」「クソアプリアドベントカレンダー」に参加した話をしたLTです。 このLTをした後、3日でクソアプリアドベントカレンダーに挑んでくれた方もいて、嬉しかったです！ RyommのLT LTを受けてアドカレ書いてくれました https://speakerdeck.com/ktcryomm/kusoapurizuo-tuteyan-tu-jie-meta Corporate IT: A new journey! フローさんによるLTです。 ご自身のキャリアとコーポレートITグループでの仕事、将来の展望などのLTでした！ KTCの従業員がHappyに働けるようにする仕事だ、と話すフローさんが眩しかったです...！笑 さいごに 社内限定とすることでカジュアルに人前で話す場を作ることができ、社員同士の交流の場ともすることができて楽しいイベントになったのではないかと思います。 室町情報共有会の旗揚げイベントとして大成功だったはず！ 個人的な工夫点としては、KTCは割とSlackが静かな方なのでテキストコミュニケーションを活発に行なってもらおうと、実況chを作成してオンラインでもオフラインでも一緒に盛り上がれるようにしたことです。 同時に記録として残すことができるので後から見返してもLTに対する反応などを確認できますし、今回不参加だった方にも次は参加したいと思ってもらえるような盛り上がりを視覚化することができたのではと思います。 アンケート等もSlackワークフローを通してスプレッドシート等に収集することで、極力Slackから離脱せずに楽しむことができるようにしました。 反省点としては、配信で使用したZoomウェビナーのチャットは無効化したのですが、リアクションは有効にしたままだったので、そちらのみで見ている層が一定数いらしゃったことでしょうか。次回以降に活かしていきたいです。 今回はホリデーシーズンだったので、せっかくだからクリスマスも楽しんでいきましょう！とクリスマスコスやシャンメリーなどを用意しましたが、意外な発見としてイベントごとに合わせると軽食が決めやすい！というものがありました。 参加者からも有志からも第二回を開催してほしい！という声をいただいたので、次回も何かイベントごとと絡めたいなと思っています。 LT大会後に忘年会があったのですが、他オフィスの方も配信で見てくださっていたようで「見たよ〜」と声をかけていただいて嬉しかったです。発表者の方も「発表見たよ〜」と感想をもらって嬉しかったと言っており、開催してよかった〜！と感じました。 今後も、こういうカジュアルな発表の場を設けていくことで、社内のいろいろな人の話が聞けたらいいな〜と思います。

Thinking About Explanations as a Product Manager — Book review: Product Management in Practice 2nd Edition Introduction I am Kamei from Woven Payment Solution Development G. My team's job is basically to develop a payment system for Woven City. I was transferred to Woven by Toyota, another company in the Toyota Group, and usually work there. Woven by Toyota has several businesses, one of which is the development of Woven City. In this article, I will also follow up on the promise I made to write a book review when I entered the drawing for the product manager release gift. https://www.attractor.co.jp/news/product-management-in-practice/ How I Became a PdM Actually, I am not a Product Manager (PdM). Even now I am not officially one. I just self-proclaimed myself as a PdM. I was originally a software engineer and worked mainly on backend. I was also a utility player and wrote frontend code when asked. I also have experience with code payment systems, which led me to my current job. After that, I also worked as an engineering manager (EM), so I can work in areas like evaluation, organization, and recruitment. However, when I was moved to this project, I was told that I was supposed to be sort of like a PdM, but with more technical knowledge. In retrospect, I should have asked more specifically what I was supposed to do, but probably nobody really knew. While not really understanding my role, I picked out technologies, built the first prototype, recruited more members, and worked in a hybrid role between a lead engineer and an Engineering Manager. I got a lot of questions from other teams and spent a lot of time preparing materials and giving explanations at in-person meetings (called menchaku meetings in Toyota terminology). Even so, I kept doing operational work like the rest of the staff, but as the team size grew, I started being the bottleneck for task completion. Therefore, I talked with the team, explained the payment functions that I think we needed implementation given my knowledge, and we decided that it would be more productive if I assign rather than take care of tasks myself, splitting the roles amongst us. I think from that point onwards is when I was able to start considering myself as a PdM. That was about a year ago. As for the decision to stop operational work, I made a similar decision back when I was an Engineering Manager, so I didn’t have any complaints about it. Probably the day will come where I'll need to work on operational tasks again; but not for now. How I Got Interested in This Book It's good that I realized that I was a PdM, but I still wasn't sure what exactly a PdM does. There were times when I did whatever job I had in front of me, but no one explained what were the results of what I did. I read a lot of articles and books about product managers, but they didn’t really resonate with me, and I was left feeling unsatisfied. I didn't read the first edition of this book, so you could say I didn't look hard enough. Then I read some comments on this book. They were all very positive, and its subtitle "A Practical, Tactical Guide for Your First Day and Every Day After" resonated with me, but they didn’t really make me want to buy it right away. This is an excuse, but I was skeptical because the comments I saw were all from actual product managers, and I wondered if the book could be understood by people who couldn't relate. Then I found out about the gift project. I was so curious, that I just had to enter. The Book Review First of all, this book is really good. It is useful for people who just became a PdM like me or wants to become a PdM, as well as organizations that want to start introducing the role of a Product Manager. It can also help you find out if there's an unofficial PdM in your organization and help you start using product management in your development process. In that sense, you could say that you can use this book from day 0. What is Product Management It's great that this book acknowledges that the role of PdM varies from organization to organization, and that the roles required of a PdM are just as diverse as organizations in the world or the problems they face. However, if that is the case, the role of PdM does not exist. This book rejects clear definitions of PdM and product management. Instead, it tries to outline it with explanations . An example of a good explanation is "Manager of the value exchange between the business and the customer" from another book, " Product Management: Avoiding Build Traps and Giving Value to Customers ". PdMs and organizations that need a PdM must make explanations for the organization based on this and other explanations . This isn't written in the book, but I think whether the explanations match each other’s concept of one is what’s important when recruiting or assigning a PdM. Of course, this is also true for other positions. However, the PdM role is more abstract than others, and I think explanations are also more important. No matter what background a PdM has, they won't be successful in the organization if there are mismatches in the explanations . CORE Skills The author presents these four skills as required for the abstract role of a PdM. Communicate Organize Research Execute Using the first letter of these four skills, we call these the CORE skills . Most of the book describes how to use them. However, that doesn't mean it has chapters named something like, "The Communication Chapter." This book consists of explanations of common development topics and how to use the CORE skills. The chapters focus on different themes, such as communication and organization building, while combining the CORE skills. Was My Problem Solved? Regardless of my job title, I feel that about half of what I do can be considered being a PdM. That alone made reading this book worth it. If you are thinking about adding another PdM to your team other than yourself, you may be able to better restructure your organization if you make a series of definitions on what you want them to do. You might want to try this. If you are determined to continue being a PdM or want to become one, you should make your own PdM explanations that incorporate the CORE skills. Personally, I'm still not ready to do that. Conclusion Once again, this book is a good guide for thinking about the role of a PdM. I think that whether you're a PdM or not, this book lets you think about how you should use a PdM or product management in your organization and how to make definitions . I would like to thank the author, Matt LeMay, the translator, O'Reilly, and also Attractor Inc. for giving me this book as a gift.

2023年振り返り＆2024年展望 KINTOテクノロジーズの景山です！ 2023年の振り返りと2024年の展望について書こうと思います。 今年はコロナ禍があけて、世の中があっという間に正常化したように感じています。 といってもコロナが5類移行したのは5月8日ですから、半年ちょっとしかたってないんですよね。 なにかすごく昔のできごとのように感じるのは、5類移行のあと、いろいろなことが目まぐるしく動いたからかな、と思っています。 今年も新サービスや新機能をかず多くリリースしてきましたが、インパクトの大きなものは KINTO ONEのサイト の再構築でした。 再構築中にも既存サイトへの改修をギリギリまで止めない、というチャレンジだったので、2年以上かかりましたが、みなの頑張りで8月にリリースできました。 組織面では、カルチャー＆ワーキングスタンスを制定しました。 経営が考えるというよりも、メンバーが自主的に議論を重ねて少しずつ形にしてくれたものです。 これまでは内製カルチャーというあいまいな表現で、我々のワーキングスタイルを表していました。 これでは内製開発を経験したメンバーしか具体的な働き方が分かりません。 それがより具体的に表現されたこのカルチャー＆ワーキングスタンスはとても重要だと思っています。 システム、カルチャーの両面でベースが作れた一年でした。 このベースのうえ、来年はさらに進化したKTCをめざします。 そのために、下記の3つを高めていきます。 技術力 開発生産性 リリーススピード 技術力に関しては、今年もテックブログや勉強会を強化してきました。 テックブログを書くことで、あらためて自分のスキルの棚卸しができたり、気になっていた新しい技術やプロセスに取り組んだり、そういったきっかけになっています。 来年はより多くの社員を巻き込んでいこうと思います。 勉強会も社内で開催するのもだけでなく、AWS Summitのような外部のイベントでプレゼンする機会も増えてきました。 また、自分たちで外部の方も参加できるイベントの開催も始めました。 社内だけでなく社外も巻き込んだ技術情報の相互交流により、自分たちの技術力やナレッジも強化されます。 こうした機会も増やしていきます。 開発生産性に関しては、エンジニアの生産性を視える化するツールの導入をはじめました。 徐々に効果が出ていますが、このツールだけでなくさまざまな観点からエンジニアの生産性を高めていきたいと思います。 生成AIの利用にもチャレンジしはじめていますが、実用に向けて組織的な取り組みを増やしていきます。 エンジニアにフォーカスするだけでなく、要求仕様定義からリリースまでの開発プロセス全体を見直して、一般的ではないKTCにもっともフィットする開発プロセスを全社的に展開できたらと考えています。 これはビジネス部門も巻き込んで進めることで、内製開発ならではのやり方で生産性向上につながるものと期待しています。 リリーススピードに関しては、とくにネイティブアプリについて機能の部品化を進めることで、リリーススピードを高められると考えています。 また、開発する機能を必要最小限にすることでプロダクトを早期にリリースし、顧客のフィードバックをもとに改善をクイックにするというやり方ができます。 ビジネス部門からの要求を自分たちで咀嚼して、必要最小限の機能を判断するとともに、エンジニア視点で最小工数になるような仕様変更を提案する。 そしてバッファーはもたず最短のリリース時期を提示し、要件が増えるならそれに合わせてリリース時期も遅らせる。 こうしたやり方はビジネス部門との一体感醸成に大いに役立ちますし、内製開発部隊でしかできないやり方です。 こうした開発スタイルを全社に浸透させていけたらと考えています。 今年も忙しかったですが、来年もさらに忙しくなりそうです。 上記のような取り組みで、プロジェクトを効率的に進められるようになれば、同じ人数でもより多くのプロジェクトを遂行できることになります。 技術力、開発生産性、リリーススピードを高めることでより多くのプロジェクトを遂行できる体制を構築していきます。 来年もKTCをどうぞよろしくお願いいたします。 KINTOテクノロジーズ 取締役副社長 景山 均

A Look Back To This Year And Into 2024 It's Kageyama, from KINTO Technologies! I will look back into 2023 and look ahead to 2024. This year, it feels like the world quickly returned to normal after the end of the pandemic. However, it's been only a little over six months since the reclassification of COVID-19 to Class 5 on May 8th. It might feel like a long time ago because a lot of things happened rapidly after that. We've released many new services and features this year, but the most impactful one was the reconstruction of the KINTO ONE website . It was a critical challenge not to stop making improvements to the existing site during the reconstruction, so it took over two years, but we have released it in August finally. Thanks to everyone's hard work. On the organizational side, we established a Culture & Working Stance. It was not something management thought of, but rather something that members discussed voluntarily and shaped little by little. Previously, our working style was ambiguously expressed as "in-house culture," which only the members who had experienced in-house development understood. I believe that this Culture & Working Stance, which more concretely represents our working style, is very important. It has been a year where we have been able to build a strong foundation in both system and culture. Building on this foundation, we aim to further evolve KTC next year. To achieve this, we will focus on enhancing the following three aspects: Technical proficiency Development productivity Release speed With regard to technical skills, we have continued to strengthen our Tech Blog and study sessions this year. Writing the Tech Blog has given team members the opportunity to reassess their skills, work on new technologies and processes that they had been curious about, and more. In the coming year, my plan is to engage a greater number of employees in this initiative. This year we also had more opportunities to present at external events such as AWS Summit, as well as to hold study groups internally. We have also started hosting our own events that were open to outside participants. Through mutual exchange of technical information involving talent, not only within the company but also outside, our own technical skills and knowledge will be strengthened. We will also seek to increase these opportunities. With regard to development productivity, we have begun to introduce a tool to visualize engineer productivity. The tool is gradually proving effective, but we would like to increase the productivity of engineers from various perspectives, not just with this tool. We are beginning to take on the challenge of using generative AI, and we will increase our organizational efforts towards its practical application. In addition to focusing on engineers, we would like to review the entire development process from requirement specification definition to release, and develop a company-wide development process that best fits KTC, not relying on common patterns. By involving the business division in this process, we expect to improve productivity in a way that only in-house development can. In terms of release speed, I believe that the speed of releases can be increased, especially for native apps, by promoting the componentization of functions. Also, by minimizing the number of functions to be developed, products can be released early and improvements can be made quickly based on customer feedback. We can digest the requirements from the business department, determine the minimum necessary functions, and propose changes to the specifications to minimize man-hours from an engineer's point of view. If the requirements increase, the release date can be delayed accordingly. This approach is very useful in fostering a sense of unity with the business department and is something that only an in-house development team can do. I hope to spread this style of development throughout the company. This year has been busy, and next year will be even busier. If we can make our projects more efficient through the above efforts, we will be able to carry out more projects with the same number of people. We will build a system that enables us to carry out more projects by improving our technical capabilities, development productivity, and release speed. We look forward to your continued support for KTC in the coming year. KINTO Technologies Corporation Executive Vice President Hitoshi Kageyama

はじめに I joined KTC in November 2020, developed the front end and API of KINTO Web, and am currently a developer on the mobile Android app team.👋🏾 "I was asked to write my thoughts and experiences on being a woman in IT, but honestly, I do not think there is any gender difference, nor it should be! Since this article is one of five articles in a series exploring diversity, delving into various work styles and perspectives at KINTO Technologies, I would like to share my thoughts and personal progress regarding leadership at the development team I am responsible for at KTC. Here's a quick summary about me : 😊 career history: 💡 Fun fact: Started working in high school with a personal business for 10 years. 🌱 I came to Japan to study game programming and have 15 years of development experience. 💼 Previous Job: Mobile app Engineer, Software(SmartTV) Engineer, WEB Engineer (Full stack),Digital signage startup. 📫 Joined KINTO in 2020. What is a good leader? When I first became a team leader from a developer, the first question I asked myself was “What makes a good leader?” The senior who gave me the role of leader for the first time explained the difference between a leader and a boss, and it was then that I thought I should become a leader like this. A leader is a person who leverages the power of members to work together, create outstanding results, and share them. In order to do that, I think I lead the team from the front and act as a support guide behind the scenes to push the team to move in a good direction. The development team's ultimate mission is to utilize the resources we have to create the services we need as quickly and completely as possible. Additionally, the goal of the development team is not only to develop well, but also to create maximum value through development. In the end, this shows up as a good result of the team, and the idea is that this is a good team and the leader who supports this is a good leader. The importance of ‘teamwork’ So, how can we create a good team that produces results? What does a good team need most? How can you get your team members to focus on one goal? I think the driving force behind this is teamwork. Below, I will share what I did with my team members to encourage teamwork. All team members become leaders We share the current team goals through the “Team Goal Task Content Sharing Meeting” and allow people to choose their own tasks. In general, leadership is only necessary for team leaders and group leaders, and unless you actually hold a position in an organization, you don't see many people who think that leadership is their role. I think a leader should help team members have a sense of leadership in their own work and a sense of “leadership” responsibility for the tasks they are assigned to. And I think this plays an important role in the team. I believe that when there is autonomy, one is motivated and plays a role in raising an individual's capabilities to the highest level. Work is created by development culture I believe that the reason a development team does a good job is not because of the “work,” but because of the team’s “culture.” For example, creating work processes, creating documents, and clearly communicating specifications These are the basics of “work.” I think that successful development teams believe that the team's "culture" makes things work well. How do team members communicate with each other? How do we come together? What do I do after the decision is made? Do you express opposing opinions, do you support them, do you criticize them behind your back? Etc. This is the development culture and this is the team culture Recognizing and embracing diversity Team members each have their own strengths. I think the most important thing is to make the most of its strengths and create maximum value. So what is our team doing? Daily Scrum Leader: Everyone on the team becomes a daily leader Our team holds a meeting every morning at 11am where team members gather together to briefly share what they did yesterday, what they will do today, and work-related blocking issues. What is different from a regular team meeting is that team members take turns to facilitate in a horizontal atmosphere rather than a vertical reporting format. We proceed in a “sharing” manner. If a team member has a problem and cannot proceed with the task, after the Daily Scrum is over, we have a “mutual help meeting” to resolve the problem. Also, since you may not remember all the work you did yesterday, you can write it down in Confluence so your team members have time to see it, schedule and plan what they need to do. This is how the KINTO ONE Subscription Team conducts Daily Scrums. Today’s Daily Scrum facilitator explains the agenda of the Daily Scrum. 'In the first week, we start by sharing what our team needs to improve or try for the next two weeks. Although it is a short period of time (about 10–15 minutes every morning), by having everyone take turns to lead in this way, leadership can be practiced in daily work, and team members can take the lead in sharing the team's current tasks and goals and contributing to the tasks. I believe that by understanding the importance, you can improve your “Leadership Mindset” and eventually it will become your internal motivator that leads to better results. Code Review: Motivation and Autonomy Many developers are highly “motivated” by their creativity. Developers aspire to share their work and expressions with people who appreciate and value them. Likewise, I enjoy seeing what other people have done, immersing myself in the code, and being shocked by other people's ingenuity. Through Code Review time, we can share our work with each other and learn from each other. If there is a better method than the current method, I will share it and make bold changes. Of course, any change must be agreed upon by the entire team. Through this, we grow day by day through discussing good code and exchanging code reviews. I believe that great colleagues and excellent collaboration experiences continue to strengthen trust within the team. Brainstorming: Let’s focus on one goal We take time to think about why we need to do this work and why we need to provide this service to users. We think deeply about how to create, how to communicate, and how to make things happen, and the level of value that the service we will create will give to users. By considering the lifespan of the code, scalability of components, and overall design from the user's perspective, Each developer team member can make technical decisions independently as a development leader for each purpose and function. Our team's brainstorming proceeds according to these rules. Let’s focus on the topic Let’s freely express ideas Let’s combine ideas Come up with as many ideas as possible Don’t evaluate ideas Let’s visualize Decide on an idea If you have decided on your own, the goal is to autonomously create a “prototype” without a complicated communication process and then deliver it to the planning team to turn it into a product. Staying flexible for development culture growth I believe that in the process of taking small actions for the growth of myself, my team members, and everyone, a good development culture will be born and we will all grow together as a result. Personally, I am always grateful to be part of a team with good colleagues. Since our development culture is a means and tool for us to create good services, not the goal, I believe that our team's culture will continue to change and move in a good direction in the future. Lastly, in my opinion, the philosophy of a good leader is to push and support the growth of team members and rather than controlling it, and to establish a good development culture in the team where we help each other. Building a good team like this may not necessarily guarantee greater success, but I believe it can increase the chances.

Introduction I am Morimoto from KINTO Technologies' New Vehicle Subscription group. I work as a backend engineer. For the 2022 Advent Calendar, I wrote an article about holding a study group for GraphQL: For this year’s 2023 Advent Calendar, I would like to talk about the renovation of our subscription site (KINTO ONE) which I worked on for two years from August 2021 when I joined the company, to its launch in August 2023. More specifically, I would like to focus on the considerations we did when reviewing its table design, which was my first job after joining the company. What Went Into the Table Design Below is an illustration of the table before and after the renovation, although it’s not exactly the same one we work with. The table contains information on employees and can be tracked by logically deleting a record and adding a new one whenever there is an update. Note: A logical deletion is when a record is not deleted, but is flagged and treated as if it is deleted. One advantage is that it can track the revision history of important values. Before Renovation id employee_id mail_address pref group_and_role delete_flag 1 E-001 email1@XX.XX 23 HR_Manager false 2 E-002 email2@XX.XX 25 HR_Staff true 3 E-002 email2@XX.XX 14 Development_Manager false 4 E-003 email3@XX.XX 1 Development_Staff false After Renovation id employee_id mail_address prefecture group staff is_deleted 1 E-001 email1@XX.XX AICHI HR Manager false 2 E-002 email2@XX.XX SHIGA HR Staff true 3 E-002 email2@XX.XX KANAGAWA Development Manager false 4 E-003 email3@XX.XX HOKKAIDAO Development Staff false Each column contains the following information. id : an ID that uniquely identifies a record in the employees table employee_id : an ID that uniquely identifies an employee mail_address : email address pref / prefecture : prefecture group_and_role / group and role : group and role that an employee belongs to delete_flag / is_deleted : whether the record has been deleted The Four Key Areas We Reviewed Not using abbreviations for columns Not replacing values with numbers Not giving multiple meanings to a single column To Not Name Flag Columns _flag 1. Not using abbreviations for columns We did not abbreviate column names, like we did for pref . One can more or less figure out that it represents Japanese prefectures. However, if you use this in documentation or source code, there is a high chance that it will be mixed up with pref or prf . Some people may not know what the abbreviation stands for in the first place. Because of that, we did not use abbreviations, and used full notations such as prefecture , even if they were long. 2. Not replacing values with numbers As you can see in the Before Renovation table, pref has a value of 23. Maybe you can arrive to the conclusion that 23 represents of one the 47 prefectures of Japan, but which one is the 23rd? It is not intuitive, so it's impossible to tell what this value means. Every time you look at a value, you have to refer to a list of numbers and prefectures, which makes it less readable. It also makes it harder to find mistakes. Because of that, we stored the prefectures using their names, such as AICHI . One advantage is that if there is an invalid value, it comes up as an error when it is read into a program. As an example, here you have the structure if we used Java as programming language and JPA was used as an O/R mapper. Also, if we define the enum class of prefecture as follows and use that type with the user entity, it will raise an error if there is an invalid value such as AICHIA . public enum Prefecture { HOKKAIDO ("Hokkaido"), . . . AICHI ("Aichi"), . . . OKINAWA ("Okinawa"); private String value; } @Entity public class Employee { /** ID */ @Id private Long id; . . . /** Prefecture */ @Enumerated(EnumType.STRING) @Column private Prefecture prefecture; . . . } If mapping is not possible, the following exception will be raised. java.lang.IllegalArgumentException: No enum constant com.example.demo.values.Prefecture.AICHIA 3. Not giving multiple meanings to a single column Before the renovation, columns such as group_and_role had two pieces of information in one column: an employee's department and their role. This may seem fine at first, but this makes it less flexible when adding, deleting, or changing a value. Suppose there are four definitions as follows. HR_Manager HR_Staff Development_Manager Development_Staff If you try to rename the Development group to NewDevelopment , the update SQL condition becomes more complex. HR_Manager HR_Staff Development_Manager　→ NewDevelopment_Manager Development_Staff → NewDevelopment_Staff There are also problems with searching and sorting. Search queries become more complex, and you have to separate the part after the _ (underscore) when sorting. It also makes them less readable. Because of that, for the site renovation, we separated each column so each one has one meaning. 4. Do Not Name Flag Columns as _flag You can see that the delete_flag column indicates that an item was deleted. However, it is unclear whether "true" means it was deleted or not. So, we decided to use the verb "to be" with a past participle, like in is_deleted . This way, it is clear that "true" means an item was deleted, and "false" means it was not deleted. It is important that there are no inconsistencies with the name of the column and the values in it are clearly understood. For example, the is_deleted column lets you logically delete old records when you are updating information on employees. true: deleted false: not deleted If a third state other than true or false appears in a flag column, you should change it from the flag column. Continuous Improvement The design of the tables was not a one-time event, but it kept being refined right till a few months before the official launch. Changing a table while various tests are being conducted, can have a large impact. In addition to improvements added by the development team, it sometimes included updates from feedback of re-run tests that the backend and frontend team did combined. Not only were we able to establish a connection between the backend program and the table, but since we wanted a smooth integration with the API interface, we worked with each team in charge of the APIs as well. I think everyone involved with the project focused on the main goal to renovate, instead of worrying about the scale of the problems in front of them. Another good thing within the backend team was that we could proactively voice suggestions for topics we thought that needed improvement. Not just when it came to the the table design, but the continuous improvement throughout development was I think one of the factors that led to the success of the renovation project. Conclusion We made major changes to the previous tables, such as changing the structure itself and deleting unused columns. This was the first task I was involved in when I joined the company, and I had to start designing the structure of the subscription site without fully understanding its features. In the middle of development, we checked operations, noticed values that were not made permanent, or even found out only during tests that some parts were defined incorrectly. Even after the launch, there were many times when we thought, "Why did we name it like this?" or “Maybe we should have separated the table here.” However, thanks to team members and the people who accepted the changes to the tables throughout the project, we were able to launch the site without issues. As we continue to improve them, we will continue to do out best to make them easier to understand.

Introduction Hello. I am Shimamura from the Platform Groups’ Platform Engineering team. I am responsible for the development, operation, and deployment of tools based on platform engineering thinking. This is the first technical article of the KINTO Technologies Advent Calendar 2023 GitHub Actions is a CICD tool in GitHub. You probably use Push and Manual trigger (WorkFlow_dispatch) often, but do you sometimes get confused when this is enabled or working? I do. I often have to ask my team members to refresh my memory. In this article, I will organize my thoughts on this. Background I want to summarize what would happen for the trigger events below. on.push on.workflow_dispatch Test Preparation Cases on.push Does it run even without merging the original workflow to the default(main) branch? What if I change the branch that is pushed to after merging the original workflow to the default(main) branch? Are other branches affected when pushing to the branch? on.workflow_dispatch Does it run even without merging the original workflow to the default(main) branch? If I create a new branch, edit the workflow, and push it to the branch after merging, will the changes be applied? Basic code (echo.yaml) name: "TestWorkFlow" on: push: branches: - main - 'test/**' workflow_dispatch: jobs: TestWorkflow: name: "TestWorkFLow Echo" runs-on: ubuntu-latest steps: - name: Echo Branch run: | echo "Branch：${{ GITHUB_REF_NAME }}" Summary of the results Here are the results in one picture. Details on.push Even if you don't merge it, it runs whenever you push if the following conditions are met: There are no syntax errors (although it will be shown as Fail if there is a syntax error) The conditions of the pushed branch match those of the workflow's on.push branch Even if you leave on.push.branches as test/** and create a branch with "feature/trigger-test" and push it, it does not run If you change on.push.branches to "feature/xx" and push, the feature/trigger-test workflow runs Behavior when two of the following branches exist: test/trigger-test with on.push.branches filter set as “feature/xx” feature/another-trigger with on.push.branches filter set as ”test/xx” Even if you fix something and push it with trigger-test, the feature/another-trigger workflow does not work Even if you fix something and push with feature/another-trigger, the trigger-test workflow does not work The "on"-type parameters looks at the contents of the file in the branch where it occurred and determines whether to launch on.workflow_dispatch If there are no files in the default branch, the manual run button is not displayed After merging, we create a new branch and add Inputs When launching manually, we can select branches, so we select the new branch and increase inputs Just like when pushing, it shows the contents of the file in the branch Verification on.push Does it run even without merging the original workflow to the default(main) branch? First, create echo.yml and push. junpei@:test-trigger-repo$ git add .github/ junpei@:test-trigger-repo$ git commit -m "create workflow" [test/trigger-test 43be511] create workflow 1 file changed, 17 insertions(+) create mode 100644 .github/workflows/echo.yml junpei@:test-trigger-repo$ git push origin test/trigger-test ・・・・・・ Total 5 (delta 0), reused 0 (delta 0), pack-reused 0 remote: remote: Create a pull request for 'test/trigger-test' on GitHub by visiting: remote: https://github.com/junpeishimamura-kinto/test-trigger-repo/pull/new/test/trigger-test remote: To https://github.com/junpeishimamura-kinto/test-trigger-repo.git * [new branch] test/trigger-test -> test/trigger-test junpei@:test-trigger-repo$ I thought it would not work the way I assumed it would, but the Action runs. What if I change the branch that is pushed to after merging the original workflow to the default(main) branch? Naturally, even if you create "feature/trigger-test" from the main branch with the trigger condition "test/**", it will not run. If you revise the files in the workflow and modify it as "feature/trigger-test", then push it, it will run. on: push: branches: - main - 'feature/**' workflow_dispatch: Is There Any Effect on Other Branches From the main branch, create "test/trigger-test-other-branch" and create a suitable file. Then push with the following, and it will run. junpei@:test-trigger-repo$ git status On branch test/trigger-test-other-branch Untracked files: (use "git add <file>..." to include in what will be committed) test-branch.txt nothing added to commit but untracked files present (use "git add" to track) junpei@:test-trigger-repo$ git add test-branch.txt junpei@:test-trigger-repo$ git commit -m "create test-branch.txt" git p[test/trigger-test-other-branch 0c738b1] create test-branch.txt 1 file changed, 1 insertion(+) create mode 100644 test-branch.txt junpei@:test-trigger-repo$ git push origin test/trigger-test-other-branch ・・・・ Total 3 (delta 0), reused 0 (delta 0), pack-reused 0 remote: remote: Create a pull request for 'test/trigger-test-other-branch' on GitHub by visiting: remote: https://github.com/junpeishimamura-kinto/test-trigger-repo/pull/new/test/trigger-test-other-branch remote: To https://github.com/junpeishimamura-kinto/test-trigger-repo.git * [new branch] test/trigger-test-other-branch -> test/trigger-test-other-branch junpei@:test-trigger-repo$ The workflow file in this case is "test/trigger-test-other-branch" and is not Main. Additionally, create a new branch called "feature/another-trigger" from the main branch. We keep the branch "feature/trigger-test" that was verified earlier. junpei@:test-trigger-repo$ git switch -c feature/another-trigger Switched to a new branch 'feature/another-trigger' junpei@:test-trigger-repo$ git branch * feature/another-trigger feature/trigger-test Main test/trigger-test test/trigger-test-other-branch junpei@:test-trigger-repo$ Make a file, and without changing the "feature/another-trigger" workflow conditions, push as (test/**). Then you’ll see that the Actions, does in fact, not run. The point seems to be whether it meets the workflow conditions in the operation branch. on.workflow_dispatch Does it run even without merging the original workflow to the default(main) branch? What can you do manually without merging the echo.yml created with on.push into the main branch? Even if workflow_dispatch is in Yaml, the button is not displayed and cannot be moved unless it is merged into the main branch. Since there is no button, it seems that it is not possible to switch the specified branch. If I create a new branch, edit the workflow, and push it to the branch after merging, will the changes be applied? I use it often, so I don’t need to check it. The changes are reflected as I expected. If you press the RunWorkflow button, you can specify the branch, so if you select it, you can run the one that shows the changes. Impressions For on.push, all of the items work as expected except “Does it run even without merging the original workflow to the default(main) branch?” Pushing alone does not register as GitHub Actions. Because it was recognized when it is registered after merging, I fortunately discovered that it was recognized incorrectly after adjusting it. I used the branch condition, but since Tag has the same event-driven type, I think it will behave the same way. I wanted to compare it with Circle.CI and other CICD services, but I think it will work the same way. Unlike GitHub Actions, SaaS-based CICD tools are event-driven and hold back the source code. I think it judges what is in the branch where the event occurred. Conclusion The Platform Engineering team manages and develops tools used internally across the organization. We adopt what other teams in the Platform group have created and based on the company's requirements, we either build from the ground up or migrate components as needed. I also tried it with CDK and started programming with tools other than Managed Service. If you are interested in any of these activities or would like to hear from us, please feel free to contact us. @ card

​ こんにちは( º∀º )/ 予算統括G、テックブログPJTのゆかちです。 12月24日、本日は有馬記念ですね！わたしの推しはソールオリエンスです🏇 どの馬もレベルが高いので、今年はどんな物語が生まれるか楽しみです・・ ！ みなさんはどうお過ごしでしょうか。 さてさて　今回は(自称)U-35×社長の交流会を開催してみた についての記事を書いてみようと思います。 開催するまで わたしが入社したのは2020年12月、丸3年となりました！！ 当時は従業員数も少なかったな～と思って確認したところ・・・ 20代：5名 30代：14名 全体：58名 （KINTOテクノロジーズ設立前の　株式会社KINTO 開発編成部 時代） ！！！！ 少なすぎる・・！！ そしてそしてなんと今現在、 20代：43名 30代：131名 全体：360名 なんという成長っぷり・・・ ・・・！！！ 成長の裏側は人事採用G、 HOKA 執筆の記事でどうぞ☟ 人事採用グループをつくろう　～3年で社員数300人に急成長した組織の裏側～ | KINTO Tech Blog | キントテックブログ 少人数時代は社内全体の飲み会もあったり横のつながりもありましたが、 この人数ではグループごとの飲み会が限界・・ これだけ毎月のように入社者がいると誰が誰だかわからん状況・・・ そんなときの今回の企画者、アイデア出し得意な ちむりん ！ いつも、これやってみようよ！ といろいろな案を出してくれます。 社長と直接交流する機会がない！という声や 他部署との関わりがもっと欲しい！の声に応えて 社長×若手の交流イベント開催しちゃお！！といった流れ。 そしてみんなで協力して形にしていきます。 そんなこんなでぱちぱち～！ 今回は社長の小寺さんに学生時代や過去の経歴、現職のこと、将来についてなどいろいろなことを話していただきました。 このパートは1時間でしたが、もっと話を聞きたかった！がアンケートにたくさんあがっていました。 さすがお話上手の小寺さん！ さてさて わたしの記事あるあるのいい写真が撮れたので見せつけたいだけのコーナーを設ける 雰囲気が伝わればいいなという想い！ 滞りない司会さすがでしたありがと！ 普段関わりのないいろいろな部署間の交流だ！ 入りたてほやほやの新入社員も！ 小寺さんはまじめにお話されてたのであまりカメラ向けれなかったのです・・ トリプルゆうじ 弊社の映えスポットで撮りがち お片付けもみんなで協力してワイワイ 会が終わって小寺さんが帰られたあとも盛り上がっており、 なかなか戻ってこないメンバーを心配して見に来た上田マネージャーの会も開催されましたｗ 『こんなことになっててうれしいよ』からはじまり熱く語ってましたね 今回参加されなかった20代の社員に なんでこなかったの～？と聞いたら もっと堅い会だと思っていた　社長と話すなんて恐れ多い！などの意見をもらいました。 写真を見ていただければ伝わるかと思いますがゆる～い会ですし、 小寺さんはとても気さくで、いろんな人とのむの好きだよ～！って方です。 アンケートを一部抜擢！ 一貫して、KINTOのサービスが良いものだということと、車のサブスクの重要性を説いていることが学びになった。 新しいサービスを作っていくのは大変だと思ったが、やり続けること、人と人との繋がりの重要性 を知ることができた。 KTCの成り立ちについて、作り上げてきた当事者である小寺さんの口から聞くことで、リアリティを持って理解することができた 小寺さんのエピソードや話し方、表情から、小寺さんという人をより知ることができた気がした 先のことばかり考えて仕事をしていたけど、 今を精いっぱい頑張ることのほうが大事なのかなと小寺さんの働き方を聞いて思った 小寺さんの人柄を知るとともに、同年代と知り合えるきっかけにもなった 業務で関わることがない方と交流することができてよかった 同年代と似たような悩みを共有できた！ アンケート結果を見る限り満足度高そうでよかった・・！ 小寺さんにも締めのご挨拶で『正直めちゃくちゃたのしかった！』 とのコメントもいただけまして、第2回も開催予定です！！ さいごに 他部署との関わりは偏りがちで、きっかけがないと関わることがなかなかありません。 わたしは非エンジニアですが、同年代のエンジニアたちにいろんなことを助けてもらっています。 たとえば： ちむりん 執筆✏ 書籍の管理方法をラクにした話 これは、なんか管理大変そうだね～、Jira使えばゆかちの負担減るのでは！？って 有志で集結してぱぱっと作成してくれちゃった愛と感動の物語です！ここで自慢しておこう 小寺さんがこの会でお話されていたように、人と人との繋がりは職場において大事だなと。 いろんな部署に知り合いがいると困ったときに相談しやすいし お互い様で協力しあって仕事を進めることができる ＝職場の環境がよい　につながるのでは？！ こういう”仲間”をつくるきっかけはいくつあってもいいのではと思うし これからもそういうきっかけの提供をみんなと一緒にしていきたいな～と思います！ では、ここまで読んでいただきありがとうございました！メリークリスマス！

Hi, my name is Tim, and I am from the Global Product Development Group at KINTO Technologies (KTC). Previously, I have written about developing our company's Design System and how it has informed design decisions at KTC. I am also a father of two: a 2-year old daughter and a son who was born in August 2023. Today I would like to talk about my experience balancing fatherhood and professional life. This article marks the fourth installment of a five-part series in our Advent Calendar, exploring diversity and different work-styles in KTC. Fatherhood in Japan When I became a dad for the first time I was already living and working in Japan, albeit for a different company. Taking advantage of one of the longest paternity leave programs in the world I proceeded to take 6 months of paternity leave. While the time spent on bonding with my new child was priceless and I was very lucky for a privilege most countries don't have , I felt that I could have been able to return to work sooner to contribute to relevant projects and to regain a sense of professional identity. When my wife became pregnant with our second child, I was a full-time employee at KTC but I felt torn about whether to take yet another paternity leave. After all, despite generous policies, workplace culture often discourages taking leave. It made me worry about how it would look to take leave, especially as a relatively new employee. Paternity Leave, or Not Amidst these concerns, I learned about the diverse workplace culture at KTC and its flexible work hours policy, both of which alleviated my worries. In response to COVID-19, the company had implemented a temporary policy that encouraged employees to work from home in the morning and then come to the office in the afternoon, providing a practical way to balance work and family responsibilities. This was a game-changer not only to myself, but also to my family. I was able to spend time changing diapers, rocking my crying baby to sleep, and supporting my recuperating wife - all while maintaining a manageable workload in my professional life. Then it crossed my mind that forgoing paternity leave is somehow conceivable, and after lengthy discussions with my wife we have made the conscious decision not to take paternity leave, and instead, leverage the company's flexibility and support to continue with my personal and professional growth. How has the decision affected my work-life balance As I gradually acclimated to the work environment after my son was born, I began to witness firsthand the genuine support from my colleagues, line manangers and human resource department to prioritize family alongside career aspirations. The open dialogue and encouragement from them who had navigated similar experiences instilled a sense of confidence in me to embrace the company's philosophy of work-life integration. My newborn son with congratulatory gift from my colleagues Conclusion Looking back, I realize that KTC's culture made it possible for me to be a dad without feeling like I had to choose between work and family. It's been a journey, but I'm grateful for the support and understanding I found at my workplace. To those who are considering starting a family, I wholeheartedly encourage you to take that step, knowing that our work culture is incredibly supportive of employees with family commitments. As someone who has experienced first-hand the flexibility that KTC offers, I can confidently say that this is a place where you can embrace both your career and your role as a parent. The welcoming atmosphere make it possible to navigate the challenges of parenthood while excelling in your career. Credit Cover Image by BiZkettE1 on Freepik

Introduction Last weekend, original article published on Jul 2023, there was an announcement from OpenAI, and a ChatGPT (GPT-4) function called Code Interpreter was released. It is a convenient service programmed in Python that allows you to analyze data without code just by giving instructions in Japanese or English. Japanese text cannot be displayed when drawing graphs or doing other tasks, but I have found a way to display Any fonts, and I will explain it in this article. Code Interpreter had its name changed to Advanced Data Analysis on August 29, but it is called Code Interpreter in this article In this article, you can replace Japanese font with any fonts which you prefer to use on ChatGPT. What You Can Learn from This Article The steps to outputting graphs, images, and PDF files with Japanese fonts using Advanced Data Analysis (formerly Code Interpreter) How to analyze X (formerly Twitter) log analytics with Advanced Data Analysis (formerly Code Interpreter) If you don't need an introduction and just want to know how to output graphs, images, and PDFs with Japanese fonts in Code Interpreter, click here . Self-Introduction Though it's a belated introduction, I am Aoi Nakanishi , the lead engineer of KINTO FACTORY . In addition to development, which is my main job, I manage events, the Tech Blog, and the official account from X (formerly Twitter), so I also manage Technical Public Relation activities in our company. Prerequisites To have paid for ChatGPT (ChatGPT Plus) To have Code Interpreter enabled Only the above two are required Enabling Code Interpreter Enable Code Interpreter from Settings -> Beta Features -> Code Interpreter as shown in the image below. You can skip this step. Advanced Data Analysis is already regular feature on GTP-4 Steps to Switching to Japanese We know that Code Interpreter does not draw in Japanese automatically without instructions, so let's explore ChatGPT and what it can do. Draw this in Japanese! First of all, I tried instructing "Draw this in Japanese" but it returned that Japanese fonts cannot be embedded in the current environment. Try to Find Out Why It Cannot Draw Japanese Font Notice that it says, in Japanese, “ in the current environment .” Let's ask how the graph image is generated. Ask How to Draw Japanese Font Since we know that it uses Python and Matplotlib, I will ask it how to display Japanese. As an example, here is the code that came out. It said that I could not download fonts or change my system settings because my Internet access was disabled. I can upload files, but it seems that I cannot download them. I did a separate check, and it seems that I cannot use system functions. Uploading Japanese Font Files It says, " Cannot download ", so I will immediately ask if I can upload, instead. It is possible to upload files, so I will try it right away. Downloading Japanese Fonts The font Noto Sans was written in the sample code that ChatGPT taught me, so I will use Noto Sans. Download fonts from: https://fonts.google.com/noto/specimen/Noto+Sans+JP (There are other usable fonts, although I haven't tested them) Uploading Japanese Fonts and Switching matplotlib to Japanese Let's try generating a graph in Japanese, or any language's fonts. Uploading Japanese(any) Fonts Upload a file by clicking the plus button at the bottom of the screen. In addition, instruct it to use the Japanese font that was uploaded when drawing graphs by telling it, " Please use this Japanese font when drawing graphs ." ↓ ↓ ↓ Summary of How to Use Japanese Fonts in ChatGPT (GPT-4)'s Code Interpreter You can now display graphs in Japanese by following the steps below. Download Japanese(any) fonts locally Upload the fonts to ChatGPT Specify a font to use when drawing graphs in ChatGPT Upload the required data and draw a graph Also, if the title is not in Japanese when the graph is drawn, you can say; Switch the title to Japanese, and see that the title are regenerated in Japanese. Remember to instruct ChatGPT to draw in Japanese using the uploaded Japanese font file. You can use these steps for PDFs and other file types to output files that can display Japanese correctly. Analyzing Logs from X (formerly Twitter) Now that you are ready to output results of analyses in Japanese, let’s start analyzing logs from X right away. https://x.com/KintoTech_Dev We will analyze data for this X account. You can download detailed data from X Analytics and perform various analyses, but today we will do conduct them using publicly available data. We will use the following information: Main body of the tweet Date and time of the tweet Number of retweets Number of replies Number of likes This data is publicly available and can be accessed by anyone, not just the owner of the account. Uploading a CSV File Select a file by clicking on the Upload button just like when uploading a font, and upload the data you want to analyze. I uploaded a CSV file this time, but it seems that it is possible to read basically any data that can be handled by Python. Also, when I checked the maximum file size that can be uploaded, it did not give the exact number, but it said that several hundred MB were acceptable. I upload the file to ChatGPT and ask it to analyze the file. After answering some questions from ChatGPT, it gave the following analysis results. The following are the results, including explanations of the analyses of the number of impressions, number of retweets, number of likes, and main body. Analysis of Impressions ChatGPT: There is no clear trend at any particular time of day or day of the week. However, it seems that the number of impressions is slightly higher at a particular time on Tuesdays than at other times. KINTO Technologies often posts articles on Tuesdays and makes a tweet when they are published. That seems to be the reason for this result. Analysis of the Number of Retweets ChatGPT: Again, there is no clear trend at any particular time of day or day of the week. However, it seems that the number of retweets is slightly higher at a particular time on Tuesdays than at other times. It seems that the number of retweets is proportional to the number of impressions. Analyzing the Number of Likes ChatGPT: There is no clear trend at any particular time of day or day of the week regarding the number of likes, as well. However, it seems that the number of likes is slightly higher at a particular time on Tuesdays than at other times. You can see that impressions, retweets, and likes are correlated. ChatGPT: Since the number of Tweets in this analysis is relatively small, it is recommended that you keep these results for reference only. This is stated because there are parts that are difficult to understand even if you look at the heat map in the results of the analysis, and it seems that it is necessary to increase the number of tweets and followers first. Analyzing the Main Body of the Tweet Here are the results of a topic modeling analysis of the top ten tweets with the most impressions made with ChatGPT. You can see that our desired information is in the results of the analysis. Item Description Visual element that attracts attention Attracts users' attention and increases engagement Use of hashtags Makes tweets easier to find Clear explanation of the subject of the article Explains the subject of the article clearly Specific call to action Includes the specific call to action, "If you are having trouble building and managing your development environment, please take a look!" Advance notice of upcoming articles Garners interest from users and increases engagement by notifying them when a new article is published Emphasize a specific theme Emphasizing themes will attract users who are interested in an event or the company's activities Summary of the Results of the Tweet Analysis From the analysis thus far, we found that the time posted, content, and use of URLs are key factors in optimizing Tweets. Item Description Post time optimization Although it is not obvious, engagement tends to be higher on Thursday and Friday nights. It is possible that users have more free time and search for content more when it is close to the weekend Tweet content optimization A Tweet that is related to an event or the topic of a new article has a high level of engagement Tweets that contain a URL Tweets with a URL to the Tech Blog have a high level of engagement Summary In this article, I explained how to analyze data with ChatGPT's Code Interpreter and create graphs and other files in Japanese. I hope that it will be useful to you in your daily analyses. We will continue to publish useful articles. If you are interested in reading the latest news, please follow us here. https://x.com/KintoTech_Dev KINTO Technologies is looking for talent to contribute in shaping the future of mobility together. If you are interested, please feel free to contact us for a casual interview. https://www.kinto-technologies.com/recruit/

はじめに 「KINTOテクノロジーズに入社するまで、Web業界は未経験だった」と言うと、えっ？という顔をされます。そんなキャリアの人が何で入社した（できた）んだろうという戸惑いの顔。しかも20代の若手じゃなくて、40代のおっさんが、何で？ 異世界の歩き方 もともとは、家電の組み込みソフト開発のプログラマー。そこから車載ECUの制御ソフトを経験して、前職では欧州系の会社でエンジンなどの試験設備を導入するプロジェクトマネージャーをやってました。ソフトはあくまで全体の一部であり、機械/電気/計測/流体/シミュレーションなど、色々なものを組み合わせてシステムを構成していました。 4線式3相交流 の 中性点接地 や 配管のフランジ接続 に 熱交 の 圧損 と ねじり振動解析 や CFD みたいな世界から、クラウドのモダンアーキテクチャの世界です。 まるっきり異世界に飛び込んでから3年と少々。どんな風に歩いてきたか振り返ってみたいと思います。  40代のWeb未経験者を生成AIに描いてもらうとこんな感じ プロGのお仕事 配属されたのは、さすがにWebシステムをゴリゴリ開発するエンジニア枠ではなくて「プロデュースグループ」への配属でした。社内では「プロG」と呼ばれています。1名が育休中なので、いま稼働しているのは4名。KINTOテクノロジーズで一番小さなグループです。 バウンダリースパナー プロGの役割について語るとき、人と組織を繋ぐ「バウンダリースパナ―」というのが、いちばん近いと思います。KINTOのやりたいことを実現するためにどんなシステムを作るかを、ビジネス部門のメンバーと一緒に考えて、システム開発部門と繋いでいく仕事です。中でも私は、大～中規模の案件のいちばん上流工程で「システム構想検討」を主に担当しています。  ビジネスとシステムを繋ぐプロデュースグループ（なんか若い） つくりすぎない どんなシステムを開発するか。ビジネスニーズが満たされていることは大前提ですが、それだけでは不十分だと思います。「つくりすぎない」ことが、とても大事です。初期のシステム化要望は、あれもこれも詰め込んだリッチなものになりがちです。ビジネス部門が求める幹となる部分を理解し、本当に必要な機能を特定して、必要十分な開発スコープに落とし込んでいくように心がけています。 KINTOが手掛けるビジネスは、ほかに前例がないものが大半です。事前に頭の中であれこれ想像してシステムを作りこんだとしても、実際にそれが全て役に立つとは限りません。やってみて初めて分かることもあります。まずは必要最小限のシステムでビジネスをスモールスタートし、そこからビジネスの成長に合わせて、システムも段階的に育てていくのが良いと思います。 また、内製開発部隊はKINTOの貴重な戦力なので、そのリソースは無駄なく活用しなければなりません。案件ごとの優先度とターゲット日程に応じて効率的に割り当てる必要があります。開発スコープをコンパクトにすることで、できるだけ短期間で開発し、いちはやく市場に投入していく。そうしたスピード感はKINTOの文化であり強みだと思います。  ビジネス部門の担当者さんは、システム開発への要求出しに不慣れなことがあります。システムを利用することはあっても、なかなか立ち上げに関わる機会はないので、全く初めてというケースも珍しくありません。システムの立ち上げは、家を建てることに似ているとも言われます。どんな家にしたいか、施主さん自身も初めてでよく分からない。プロGは、そうした担当者さんをリードする役割も担っています。 内製開発部隊だからこそ、ビジネス部門と対等にやりあったり、時にはリードしたりして、絶妙な「つくりすぎない」システムを提案することができます。KINTOテクノロジーズ全体に浸透している意識だと思いますが、プロGのミッションはその中核にあると思います。  狩猟系民族 プロGは基本的に自分で獲物（案件）を見つけに行く狩猟系のスタイルです。グループミーティングで新しい大規模案件の噂が出ると皆が目を輝かせます。そして、向こうの山でマンモスを見つけたときのネアンデルタール人みたいに、いそいそと狩り支度を始めます。そうして一番最初に獲物に飛びついた勇者が、その案件の主担当になる。そういうしきたりになっています。 ※実際は勤務地や得意分野を加味して担当割り振りされることもあります。 半分活かして、半分手放す 異世界を歩きはじめるときは、できるだけ身軽にしておくのが良いと思います。 経験をフル活用、しない 新しい場所で心機一転スタートするとき「これまでの経験をフル活用して」と思うかもしれません。即戦力を期待されているのだから丸腰で飛び込むのはちょっと怖い。新しい環境での不安感を支えてくれるのは、これまでの経験しかないような気がします。けど、経験や価値観を抱えたままだと重たいですし、新しいものを取り入れるスペースもありません。過去の実績はもう動かないものだから、抱えていると足に根が生えたみたいになってしまいます。私も初めての転職のとき、それで失敗したことがありました。  忘れてても、ちゃんと助けてくれる だから、半分は手放します。こだわりとかスタイルみたいなものは真っ先に手放してしまいます。半分活かして、半分手放すくらいがちょうどよいバランスではないでしょうか。手放すのは「失う／否定する」ではなく、いったん「置いておく／忘れる」ということ。普段は忘れていても、必要な時にスッと引き出しが開いてちゃんと助けてくれる。誰かが盗んでいくわけではないのだから、ずっと両手に抱え続けることはない。そう考えるとラクになるので、そうしています。  自分の経験のストックを仕分けする ＜活かしているもの＞ プロマネの気持ち 私くらいの世代だと「うさぎって寂しいと死んじゃうんだよ」というのがありましたが、同じくらいプロマネも孤独に弱い生き物です。前職ではひたすらプロマネをやってまして、うまくいってるプロジェクトは良いのですが、うまくいかないと加速度的に孤立化が進むのを知っています。メンバー/顧客/オーナー/上司/財務部門/営業部門/サービス部門/本国/外注先/協業先と、各方面から同時に圧迫されて、あっというまに逃げ場がなくなります（そしてトドメに家庭が…っていう人もいました）。KINTOだと皆優しい感じなのでそこまでには至らないと思いますが、それでも孤独でしんどい仕事です。応援したいと思います。  炎上するプロジェクトは、そもそものベースライン（スコープ, 日程, 完了条件）がグダグダになっているケースが大半です。プロGの自分にできることとしては、そこをちゃんと整えたうえでプロジェクトを渡していくことです。 結局なんとかなる 前職の6年間だけでも40件弱のプロジェクトを回してきました。場数だけいえば多い方だと思います。失敗して青くなったり、予算が赤になってしまったり、先行きが真っ暗になったり色々ありましたが、どのプロジェクトも結局はなんとかなりました。イメージ通りに格好よくゴールできなくて、息も絶え絶えに転がり込んだとしてもゴールはゴール。行き止まりで万事休すと思っても、必ずどこかに打開策はあるはずだという気がします。さんざん痛い目に合いながら性懲りなくそう思えるのが、自分でも不思議です。 多様性があたりまえ 色んな人と仕事をしてきました。国籍だと、ドイツ、オーストリア、フランス、スウェーデン、チェコ、イギリス、インド、スリランカ、マレーシア、タイ、インドネシア、シンガポール、台湾、韓国など（なぜか、アメリカと中国には縁がない）。職種としても、ソフト開発、機械設計、電気工事、配管工事、搬入設置工事、営業、財務、調達、倉庫、ゼネコン、消防署、自動車の設計開発、産業用ロボット、コラボしたライバル企業 などなど。プロジェクトには多様な人々が参加するのが当たり前で、違うから参加してもらう意味があるという感覚です。KINTOにも色んな職種の人や、癖のある人がいて面白いです。 ＜手放したもの＞ プロマネは決めるのが仕事 前職の上司が「プロマネは決めるのが仕事」と言っていて、私の実感としてもその通りだと思っていました。判断ミスよりで責められることよりも、判断しないことを責められるほうがより深刻。決めないというのは「プロマネとして仕事をしていない」ということを意味していました。上司に助言を求めることはあっても、判断を委ねることは絶対にありえません。それは、運転席に座りながらハンドルを自分で操作しないのと同じこと。誰かに判断を委ねるようではプロマネとして失格で、運転席から降りるときでした。グローバル企業でしたが、どこの国のプロマネもそんな感じだったと思います。  そんな価値観で過ごしてきたので、驚きでした。KINTO/KINTOテクノロジーズのプロマネの皆さんを見ていると、自分で決めるのではなく、関係者の合意をもって決定としている。このギャップにはかなり戸惑いましたが、そのうち、これもプロジェクトマネジメントの実践としてアリなのだと理解できました。私の前職が Decision and Order の直接的なマネジメントだとすると、KINTOは Facilitate and Agreement とでも言うべき間接的なマネジメントをやってるんだなというのが今の認識です。むしろ、とても高度なことをやられているなと尊敬する気持ちです。全て自分で決めるほうがシンプルで簡単です。 とはいえ、間接的な "合意の促進" だとスピード感には欠けます。直接的な "判断と命令" も個人に委ねるリスクがあります。それぞれの良いとこどりができないものかと思います。 思い立ったら直電 仕事道具といえばガラケーでした。何か思い立ったらすぐに電話。発信も着信も多くて、1日の履歴が数十件になることも普通です。プロジェクトメンバーが全国の現場に散っているので、すぐ捕まえるには電話しかありません。夜中でも平気で電話してました。KINTOテクノロジーズだともちろんそんなことはなくて、Slackを中心にスマートなコミュニケーションが浸透しています。そんな当たり前のことに驚いていた私は、まるで過去からタイムスリップしてきた人みたいだったと思います。 とはいえ、1分の電話で片付く要件が、Slackのやり取りだと30分かかることもあるので、コミュニケーションツールの使い分けというのは必要です。皆さん実践されてると思いますが。 組み込みソフトの常識 私のルーツであり、思い入れが深いのですが、さすがにこれは手放さざるを得なかったです。Webシステムなので、リアルタイム性の要求が無い（応答速度の要求はあるけど、別物）ですし、Event-Mode-Action のステートマシンで動くわけでもない。PIDみたいな連続系の制御システムとも違う。基本的にはハードウェア非依存なので、リソース制約も限定的です。なので泣く泣く、引き出しの奥にしまい込んでいます。AWSのSQSなんかは、昔手作りしたFIFOのリングバッファを思い出して懐かしい気分になります。 それでも、この先もしかしてSDV（Software Defined Vehicle）や IoTみたいなエッジ領域と、KINTOのクラウドに接点ができたら出番が来るかも？と、少し引き出しがウズウズしています。 ざっくり適当に理解する 異世界なので、ただ歩いているだけでも未知のあれこれに出会います。 アルパカを理解する 初めてアルパカを見たとき「首の長いヒツジみたい」と思う人。「毛の白いラクダみたい」と思う人。漢字で 羊駱駝（ひつじらくだ）と書くくらいなので、どっちもアリです。その人の生まれ育ちや直観的な感じ方に素直に従うしかありません。初心でアルパカと向き合って、ゼロから理解するのは今さら無理なので。だから、自分の知ってる〇〇みたいだなと、最初はざっくり適当に理解すれば良いと思っています。   そこまで一所懸命に観察しなくても大丈夫 違うけど、だいたい同じ 違いに着目するより、同じに着目したほうが、異世界に慣れる助けになるはずです。自分も組み込みソフトやエンジン試験装置についての経験から、ざっくり適当に理解することをよくやります。ただそれは「分かったふりをする（他人を欺く）」ではなく「分かった気になる（自分の深掘りをいったん止める）」ということ。知識を実際に使って仕事をするときは「分かっていない」という事実と向き合う必要があります。逆に言えば、それまではいったん浅いところで置いといても、たぶん大丈夫ということ。 正しさよりも全体感 足元をみて丁寧にひとつずつ正しく理解するより、少しくらいの思い込みや未消化な部分があっても良いので、浅く広く全体感を把握するほうが自分には合っているみたいです。点の集合でも、眺めてるうちに隠されたストーリーを何となく感じ取ったり（星座みたいなもの？）、登りたいところへたどり着くための手がかりになったりします（ボルダリングみたいなもの？）。特にプロマネやバウンダリースパナ―みたいな役割は、そういう全体感の把握が助けになると思います。  素潜りできるところまで 全体感を眺めて読み取れるのはあくまで仮説です。「〇〇だとすると、こんな風に進められそうだ」みたいな仮説が浮かんで来たら、必要に応じて深掘りします。今からその領域のプロになる気はない（なれない）けれど、プロの人と会話できるくらいになれれば十分です。私の場合、それでだいたい仕事は進みます。素潜りの副産物としては、それまで点だった知識が繋がって、線みたいになっていくこと。そうやって少しづつ線を繋げて地図をつくっていきます。 反抗期の過ごし方 仕事に慣れてくると、だんだんと湧いてくるものがあります。 違和感とイライラ 誰でも新しい仕事に慣れるまでは謙虚で、少し臆病なくらい周囲の様子を伺いながら過ごしていくと思います。そのうち仕事に慣れてくると、だんだんと湧き出てくるものがあります。「あれ？ この会社の仕事のやり方おかしくないか？」みたいな、これまでのキャリアで経験してきたやり方とのギャップから生まれる違和感です。それ自体はとても貴重な気付きで、うまくすれば何かの改善に繋がるかもしれません。けれど、私の場合だけかもしれないですが、そこにフラストレーションが伴うことがあります。なんだかイライラした気持ち。 転職後反抗期 個人的に「転職後反抗期」と呼んでいます。早ければ3ヶ月頃から始まって、2年目くらいまで続きます。3回の転職を経験しましたが、毎度必ずやってきます。違和感自体は良いとしても、イライラを周囲にまき散らすわけにはいきません。自分の場合は 1 on 1 を使って消化させてもらいました。直属の上司と、2コ上の上司と、3コ上の上司に、それぞれ話を聞いてもらいました。話を聞いてもらうためには違和感を言語化する必要があって、まずその過程で客観視するので少し冷静になれます。少し格好つけて提言っぽくまとめたくなります。そうやって率直に対話をしていくと、だんだんと違和感が消化されていきます。 2コ上は副社長、3コ上は社長という距離感。フラットさはKINTOテクノロジーズの魅力です。 違和感を整理していくと、そのいくつかは自分のミッションに落とし込めることがあります。  生成した “大人の反抗期”（1枚目と同じ人が出てきた） おわりに たぶん、今がいちばん積極的に新しい技術や知識に気持ちが向いているかもしれません。 昔の引き出しが開くとき 社内の色んな職種の人の話を聞くのも、社外の展示会や他の企業さんと話をするのも面白い。刺激を得て考え方を再構築するうちに、さび付いていた昔の引き出しがスッと開いて、新しいものと古いものが化学反応を起こすことがあります。ボルダリングの例えを書きましたが、ほんの少し登ると景色が変わって、次に手が届きそうだとか、思ってたのと違うから考え直そうとか、色々と分かってきます。そういう変化を素直に受け入れると、次の変化も楽しめる。逆に苦しい気持ちになる時は、たいていそこに留まろうとしているときでした。 そうやって生き延びていく 「 タイガー手回し計算機 を使っていた」とか「 パンチカード が読める」とか。新卒で入社したころ、そうしたベテランエンジニアの方が現役で活躍されていました。「クラウドネイティブなモダンアプリケーション」も「LLMの生成AI」も、いずれ枯れた技術としてコンピューターの年表に並ぶことになります。技術は移り変わり、求められる役割も変わっていきます。そのとき何をしているか想像もつかないけれど、自分の半分をどんどん入れ替えながら、しぶとく生き延びていければ良いなと思います。  かつての最先端技術とリンゴが並ぶ

取材対象 KINTOテクノロジーズ内のグローバル開発部には、多国籍で多様な背景を持つDevOpsチームが存在します。 メンバーそれぞれが得意とする言語、技術、経験は異なりますが、チームとしては非常にスムーズに仕事を進められています。 今回は、そのチームリーダーである李さん（ Flyway記事の作者 ）に取材を行いました。多国籍チームの運営に興味があれば、ぜひご一読ください。 自己紹介とチーム状況紹介 自己紹介 KINTOテクノロジーズグローバル開発部でDevOpsチームリーダーをしています、李です。 卒業後、日本のメーカーのIT子会社で5年間働きました。その間、社内の共通言語が日本語だったため、日本語や日本の文化、さらには異文化とのコミュニケーションスキルを学びました。当時は、Webアプリケーションの開発、設計、評価から始め、システムエンジニアとプロジェクトマネージャーとしての経験を積みました。開発経験だけでなく、開発プロセスとマネジメントの知識も身につけました。 その後、大学で3年間講師を務め、新しい技術と教育学を学びました。これにより、効率的な学習方法についても理解を深めました。 日本に移住した後、次女が保育園に入園したのをきっかけに、IT分野に復職しました。 これまでの異文化コミュニケーションスキルや開発経験、マネジメント能力や人材育成の経験を活かし、現在はグローバル開発部でDevOpsチームのリーダーを務めています。 チーム状況紹介 現在、私たちのDevOpsチームはCI/CD、インフラ、テストの3つのサブチームで構成されています。チーム内6人が下記のように、国籍も専門分野もそれぞれです。 DevOpsチーム設立当初からの理念は、あえて異なるスキルセットを持つメンバーを組み合わせることで、アプリケーション開発チームをサポートすることです。 No. サブチーム 前職経験 国籍 英語力 日本語力 1 CI/CD 開発、プロジェクト管理、品質保証、システム設計 中国 B B 2 Infra Infraエンジニア、プロジェクト推進、インテグレーション、設計 中国 C A 3 Infra Infraエンジニア、開発、プリセールス 中国 C B 4 Test ネットワークエンジニア、プロジェクト管理 ニュージランド A C 5 Test 開発エンジニア インド A C 6 Test テスト、開発、設計 ミャンマー B C ＊語学力： A：細かいニュアンスまで再構成して表現できる B：幅広い複雑な話題でも議論可能 C：自分の考えとその理由を表現できる D：日常会話可能 Q＆Aコーナー 多様な言語、文化、技術背景を持つチームの日常業務は、想像しにくいかもしれません。 そこで、今回はチームリーダーの李さんにいくつか質問をしてみました。ここではQ&A形式でまとめ、チームの様子を少しでも皆さんに伝えられればと思います。 Q＆Aその１ 質問: チーム内に様々な専門経験を持つメンバーがいる中で、皆をDevOpsチーム共通の目標に向かわせるにはどのようにしていますか？ 回答: 私たちは、下記のようにチーム内で明確なロードマップを共有し、それに基づいて目標を具体的にし、メンバー全員が同じ方向を目指すようにしています。 チーム内には、品質保証をしたい人、インフラを担当したい人、開発に携わりたい人など、様々な希望を持つメンバーがいます。私たちは、それぞれの強みや志向を理解し、皆が納得できるロードマップの作成に努めています。 ロードマップ（例） Q＆Aその２ 質問: チーム内の7人は4つの異なる母国語を話します。コミュニケーションにはどの言語を使用していますか？文書やメッセージはどうですか？ 回答: 口頭でのコミュニケーションや文書の作成は、その人が得意とする言語（英語または日本語）を使用しています。 チーム全員が英語を理解できるため、メッセージは主に英語で送信しています。また、理解を深めるために翻訳ツールの利用も推奨しています。 多言語コミュニケーションでは、発表者がゆっくりと話し、簡単な単語を使用するよう努め、わからないことはすぐに質問する雰囲気を作っています。 Q＆Aその３ 質問: 文化的にも技術的にも多様なチーム内での知識共有はどのように進めていますか？ 回答: 私たちのチームでは知識共有を重視しており、下記の三つの方法を用いています。 期間 手段 内容 目的 アイスブレーキングフェーズ 各メンバーの専門分野について知識共有会 今までの領域の知識 お互いに理解し、自身の知識を広げること 配属から一年後 オンラインコース学習（Udemyにある自動テストツールやマイクロサービスアーキテクチャなどのコース） 仕事に使うスキルで足りない部分（システムアーキテクチャとか、自動テストツールとか、AWSとか） 今の仕事上必要なスキルの向上 随時（異なるタスクが終わった後） ドキュメント化して残す 手順やノウハウなど（ 自動テストのブロック 　） 将来横展開しやすくするため Q＆Aその４ 質問: 母親として、異文化間のチームをリードするのは難しいですか？ 回答: 私が母親であることに対して、チームは非常に理解があり、親切です。グローバル開発部の文化として、多様性を尊重し、互いに敬意を払い、適切な距離感で接しています。自分は小学生の子供を2人持っており、学校行事への参加が必要な時、チームメンバーは日程調整やタスクの再配分を通じてサポートしてくれます。 例えば、最近家族全員がインフルエンザにかかった時、約2週間出勤できませんでしたが、チームメンバーが積極的に業務を引き受け、私の負担を軽減してくれました。 そのサポートにはとても感謝しています。 Q＆Aその５ 質問: 多国籍なチームを管理する際、どのようにして様々な標準（労働倫理やプロフェッショナルな基準など）を統一し、メンバーのモチベーションを維持しつつ、一定水準の成果を出すことができますか？ 回答: 異文化の合理性を認め、尊重することが重要です。私自身も外国出身であるため、日本と海外の慣行の違いを理解しており、この視点からチームに説明することができます。ここは日本なので、基本的には日本の標準を遵守していますが、外国人の視点からの解説も提供しています。 また、管理学やPMP（プロジェクトマネジメントプロフェッショナル）などの知識を活用し、業界共通のやり方を取り入れています。 チームでは、メンバーに広範な裁量を与え、彼らが望む仕事を行うことでモチベーションを維持することを重視しています。 最後に 質問:　こういった多国籍なチームをまとめる上で、李さんが一番大事にしていること、または工夫しているところは何ですか？ 回答:　やはりコミュニケーションが最も重要だと思います。PMPの理念に沿っています。私たちのチームでは、皆が明確かつ具体的に自分の考えを伝えることを心掛けています。仕事の中で、いつも「5W1H」を用いてコミュニケーションを取っています。また、異なる考え方にも敬意を払います。基本的に、人々が異なるということを認識した上でコミュニケーションを行っています。 質問:　チームメンバーからもサポートがもらえるのは信頼があるからだと思います。その秘訣はありますか？ 回答:　普段の業務では、私自身もメンバーのサポートと指導に意識的に取り組んでいます。メンバーがそれぞれの目標を達成できるよう協力しています。私たちは一つのチームとして、各々が欠かせない一員であり、共に目標達成を目指しているため、リーダー・メンバーというポジションの関わらず、お互いにサポートし合えているのだと思います。やはり素直な心が必要だと思います。 まとめと今後の展望 この記事ではグローバル開発部DevOpsチームのリーダーである李さんにインタビューをし、多国籍なチームでの異文化間コミュニケーションや知識共有の方法、母親とチームリーダーのバランス、そして多国籍なチームのマネジメントなどについて取り上げました。 最後の回答にあったように、多様な背景を持つチームであっても、常に「人は異なる」ということを意識し、異なることに敬意を払い、5W1Hなどを通じて考えをわかりやすく伝える。こういったことの積み重ねによって信頼が生まれ、同じ目標に向かって効率的に互いをサポートし合えることがわかりました。これは決して多国籍なチームだけではなく、同じ国籍であっても同じことではないでしょうか。 多様な背景を持つチームのマネジメントに悩んでいる方にとって、この記事が少しでも参考になると幸いです。 今後、DevOpsチームは事業の展開やテクノロジーの進化に伴い、さらなる挑戦に直面することでしょう。 しかしこれまでの取り組みと、多様性を受け入れられるチームの精神があれば、どんな障害も乗り越えていけると、チームの今後の成功と成長に期待しています。