自己紹介＆どんな話？ グローバル開発部のYuki.Tです。グローバル向けプロダクトの運用や保守を担当しています。 グローバル開発部のメンバーの国籍は様々で、話す言葉も様々です。なかでも私のチームには「日本語が話せないメンバー」と「英語が話せないメンバー」が混在しています。そのためチーム内でのコミュニケーションを成立させるために、色々な工夫（苦労？）をしてきました。今回はその工夫の内容と、その過程で得られた気づきを紹介したいと思います。 結論 - 「英語無理だったら、日本語でおｋ。」 - 「喋れないんだったら、せめて書こう。但し正確に。」 - 「大変だけど、頑張るだけの価値はあるよ。」 はじめに（どんなチーム？） グローバル開発部内の私のチーム（運用保守チーム）でのお話です。約8名。 そのメンバー構成と仕事の進め方は、下記の様になっています。 国籍 プロパー社員とパートナー会社メンバーが混在。できて約1年のチーム。 できた当初は日本語メンバーだけ。その後に外国籍メンバーもジョイン。 勤務スタイル リモートと出社のハイブリッド。Agile開発（Scrum）。 各種Scrum Eventも、リモートと出社のメンバーが混在。 コミュニケーション 連絡はSlack、ミーティングはTeamsが主。 タスクやドキュメント管理は、Atlassian Jira, Confluence。 メンバーの語学力は様々ですが、日本語メインの人が大勢を占めます（6人中8人）。 分類 語学力 人数 A 英語オンリー。日本語は全く分からず（外国籍） 1名 B 英語メイン。日本語は日常会話程度（外国籍） 1名 C 日本語メイン。英語は日常会話程度（日本国籍） 2名 D 日本語メイン。英語は話せない。読み書きは何とか（日本国籍＆外国籍） 4名 ちなみに私（日本国籍）は上記の"C"です。TOEIC 800くらい。 話すだけなら多少はいけますが、込み入った議論になると、途端に語彙不足が露呈します。あとリスニングが結構苦手…。 つぎに（YWT） チームができた当初は、上記の分類でいうと"C"や"D"の人（以下「日本語メンバー」）ばかりで、コミュニケーション手段も基本的には日本語オンリー ^2 でした。その様なチームに、英語メインの"A"や"B"の人（以下「英語メンバー」）にジョインしてもらうため、色々な事を試してみました。 ここではその結果を、ふりかえりの手法のYWT[^3]（やった、わかった、つぎやる事）っぽくまとめてみます。シチュエーション毎に、「1.連絡手段(Slack)」「2.ミーティング(Teams)」「3.ドキュメント(Confluence, Jira)」の3つに分けて、紹介していきます。 [^3]:YWT（やったこと・わかったこと・次にやること） | 用語集 | 株式会社 日本能率協会コンサルティング https://www.jmac.co.jp/glossary/n-z/ywt.html 1. 連絡手段（Slack） やった 「日本語分からなくても、翻訳ツールにコピペで訳せば読めるよね？」 分かった 「訳して読んでくれるのは、最初のうちだけ。」 いちいちコピペで訳すのは、結構面倒なんですよね（自分でやってみると分かる）。 自分がメンションされていても、実際はあまり自分に関係しないケースも意外と多いため、「手間かけて訳してみても徒労に終わる」という経験が積み重なり、だんだんコピペ翻訳する気力が削がれていく様子。 またSlackは、単体のメッセージだけでなく、スレッド全体を読まないと意味が掴めないケースも多いです。それもまた翻訳のしにくさに繋がっている様です。 次にやった 「日本語と英語を併記しよう」 本当に伝えたいメッセージの場合は、英語でも書く様にしました。 コツは「日本語全部を訳そうとしない」という事。公開できる良い例が無かったのですが、例えばこんな風に。 何の用件かは英語で分かる様にし、詳細が気になる用件なら、残りは自分で翻訳してもらうなり、個別で訊いてもらう様にしています。全部訳そうとすると、送り手側も大変ですしね。 2. ミーティング（Teams） やった ①「日本語で話すから、Teamsの翻訳機能で字幕を読んどいて」 ②「英語が苦手な人も、頑張って英語でしゃべるんだ！」 ③「よし、じゃあ私が全部通訳してやるぜ！」 分かった ①「読んでも意味が分からない」 「口語の日本語⇒英語の機械翻訳精度は、まだまだ低い」というのが結論です。 特に少人数でのカジュアルなミーティングでの日本語は、言い淀んだり、主語や目的語が曖昧だったり、複数人が同時に話したりと、機械翻訳にとって色々悪条件が重なるのも一因なのでしょう。 ②「誰も幸せになれない」 喋ってる本人も「…これでいいのかな？（不安）」と思いながら、途切れ途切れに話す拙い英語は、日本語メンバーにも英語メンバーにも伝わらず…。あとは「英語で何て言うか分からない事は、そもそも喋らなくなる」ので、日本語で話す場合と比べて、みんな寡黙になりました…。ミーティング自体は早く終わるけど、得られる情報が少ない…。 ③「終わらないミーティング」 日本語メンバーが話した後に、私が英語で話す事になるので、単純計算で2倍の時間が掛かります。さらに日常会話＋α程度の私の英語力だと、"how can I say..."と、どう訳せば良いか、つまづいてしまう事もしばしばで、時間はさらに延びる…。 そして英語で話してる間は、日本語メンバーはただぼんやり待ってるだけになります。そのため、だらけたミーティングになりがちでした。 次にやった 「英語が苦手な人は、日本語でOK」 英語が苦手な人には、無理せず日本語で話してもらう様にしました。そして英語メンバーが関係する内容に絞って、私が通訳する事にしました。これによって、ミーティング時間が極力伸びない様にしました。 「話すのが無理なら、せめて書こう」 これだけだと、英語メンバーに伝わる情報が減ってしまいます。なのでミーティングメモを、なるべく詳しく書く事にしました。そうする事で、その場では分からなくても、後でブラウザの翻訳機能で読んで貰う事ができます。ちなみに聴いた言葉をそのままメモするため、メモは日本語と英語が混在する事もあります。 「それでもやっぱり、努力は必要」 それでもSprint Retrospectiveの様に、事後では無くリアルタイムで意味を伝えないといけない場面もあります。そんな時は時間が掛かってしまっても、その場で訳を書き加えています。例えばこんな風に（青字）。 Sprint Retrospectiveの場合は、みんながKeepやProblemのアイデアを口頭で説明してる隙に、私がコソコソと訳を書き加える等、うまく隙間時間を活用しています。 3. ドキュメント（Jira, Confluence） やった 「日本語で書くから、ブラウザの翻訳機能で読んどいて」 分かった 「Confluenceは割とOKだけど、Jiraはちょっと厳しい」 主にConfluence上にある設計書や仕様書などは、比較的きちんと翻訳されます。またグローバル開発部のドキュメントは、元々英語で書かれているものも多いので、そういうものは手間いらずです。 ただJiraチケットのコメントの翻訳精度はイマイチでした。正式なドキュメントと異なり、チケットのコメントは主語や目的語が省略されている事が多い事が主因の様です。日本語ネイティブが読んでも意味が分からない「自分専用メモ」みたいな日本語コメントもあったりするので、当然と言えば当然です。 次にやった 「正確に・簡潔に書こう」 主語や述語、目的語を省かずに書く事を心掛けました。また、なるべく簡潔な文章で書く様にしました（箇条書きとか推奨）。こうする事で、ブラウザの機械翻訳の精度が上がります。 得られたもの これらの「次にやった」の取り組みのお陰で、現在ではチーム内のコミュニケーションがある程度機能してきました。またその他にも、以下の様な効果がある事が分かってきました。 情報が記録される 些細なミーティングでも、ちゃんとメモを取る習慣ができてきました。その結果、「あの時どういう結論になったんだっけ？」と振り返りたい時に、困る事が減りました。 暗黙の了解が減る 適切な英語に訳すには、日本語の状態では隠れている主語や目的語を、明確にする必要があります。そのため「誰が」これをやるのか、「何を」対象にその変更を加えるのか、を確認する機会が増えました。 やってみると分かるのですが、「誰が」や「何を」がハッキリしていない事は、意外と多いです。そういう場面で「これは〇〇さんが担当してくれるんでしたっけ？」と確認する機会が増えるので、タスクの取りこぼしを減らす事もできます。 あと、「（〇〇さんがやってくれないかな、でも訊きづらいな…）」と遠慮して訊けなかった事も、「英訳するため」という目的があると訊きやすい、という側面もありました。 多様な意見が出せる・得られる 暗黙の了解が減って明確なコミュニケーションが取れる事は、「言いたい事が言える・多様な意見が出せる」に繋がってきた様にも感じます。また英語メンバーからの意見もより多く取り込める様になり、日本語メンバーだけでは気付きにくい視点も得られる様になりました。例えば下記の Try のアイデアです。これは「チケットに、タスクの背景や目的をきっちり書けなかった」という Problem に対する Try だったのですが、1つめのアイデアは、日本でありがちな真面目な内容（失礼）です。それと比べると、2つめの英語メンバーの「まぁちょっと落ち着こう」的な意見は、全く異なる視点からの意見で、私は「なるほどなぁ～」と思わされました。 まとめ 多言語でコミュニケーションを取るには、なかなかの労力が伴います。しかしその苦労は、目先の意思疎通だけでなく、新しい気付きや活発な意見の創出にも繋がっていくのだな、と感じています。 「多様性の実現は、義務やコストではなく、利益でありメリット」 。そう思って、これからも取り組んでいこうと思います。

I am Gojo, a software engineer at KINTO Technologies. I am doing backend development for a mobile app called Prism Japan that uses AI to suggest nice places to go around Japan. I co-authored this article with Saito, the Product Owner of Prism Japan. I will talk about how our relatively large agile team improved its overall development and teamwork. About Prism Japan First of all, let me briefly talk about Prism Japan, the service we are developing. In a nutshell, Prism Japan is a user-friendly app that leverages AI to provide personalized travel recommendations, helping users discover exciting places to explore. Have you ever wanted to make the most of your holiday in Japan, but found yourself unsure of where to go? Prism Japan can be your perfect companion, offering personalized travel suggestions to help you plan a memorable getaway. With the "Search by Mood" feature for example, users can simply select a photo, and the app will suggest places to visit based on the chosen mood. Users can look at photos and search for a travel spot that suits their mood. We released the app for iOS in August 2022 and the Android version in April 2023. As of the end of October 2023, the total number of registered members has exceeded 30,000. Prism Japan's Development System Prism Japan can be used on iOS and Android. The team developing the mobile app is divided into: iOS development team and Android development team. 　 The backend is divided into the: API development team and AI development team. Development is led by team members who specialize in their respective fields. In addition to the development team, there are teams in charge of planning, analysis, and design. The Product Owner decides the direction of the entire project and thinks about the functions that the user will need. There are 15 members who are mainly in charge of Prism and 20 members who are involved in development sub-tasks. It might be considered a relatively large family for an agile team. How We Switched to Agile Development The Prism Japan development team now works as a single team, but the frontend team and backend team used to work separately. When we needed to coordinate work between the teams, we sent requests through a Slack channel. After we sent a request, it was left completely to the other team. The jobs were divided because the departments were divided, and we had the following issues managing each team. Since the development process was not shared between the frontend and backend, there was no consensus between teams There was no improvement in the entire team across frontend and backend. Project Managers and remote members were less likely to have ownership because development proceeded on a request-to-work basis When the initial development of Prism Japan was over, we discussed switching to a development method suitable for the improvement phase of the app. When we considered development methods that could address the aforementioned issues, we quickly decided to switch to agile development, which allows users to flexibly change specifications while monitoring user reactions and is compatible with mobile apps. There were experts in the teams, and we decided to adopt the Scrum method, which was very advantageous in terms of communication, which was one of the issues. How We Set Up Scrum from Scratch Not all of our team members had experience with Scrum. We needed to convey what Scrum was to our team members. We started off by having our Scrum Master Koyama teach our teams about Scrum. For more details, you can read Koyama's article below. How an iOS Engineer Took Certified Scrum Master Training and Become a Scrum Master Starting with a Study Session When we decided that we wanted to develop using Scrum, we started by having a study session on Scrum. I think it was very useful. All of the members were determined to start using Scrum, and they all learned the basics. Setting Up Scrum Events The week after the study session, we set up Scrum events. We were fumbling at first, so the Scrum Master and Product Owner took the lead in discussing what to do at each event. First we did tasks like the following. We set up a two-week Sprint The Product Owner created a story Start a daily Scrum of 15 minutes every day Set up Sprint planning Set up Sprint reviews Set up Sprint retrospectives The Scrum Master took the lead in setting up the above events and moderating them. This article will not go into the details of the Scrum events, but we felt like we were actively taking a Scrum approach when we took concrete actions such as: the Scrum Master taking the lead in setting up events, and the Scrum Master and Product Owner working closely together to hold events I found it important in the process to have a passionate Scrum Master pushing the team, along with a team willing to improve; especially during the initial stages when we were still finding our footing. Team Building Through Scrum development, I observed our team's gradual growth overtime. Especially in the following areas: It became easier to discuss specifications Team members actively exchanged opinions regarding the functionalities of the app We can now practice Scrum without solely depending on the Scrum Master I think this is a common experience for many organizations, but Scrum did not initially function effectively for us at the beginning. The first month we formed a Scrum team, our Product Owner Saito and the Scrum Master Koyama played a central role in searching for ways to improve the team. It took about two months to use Scrum smoothly. The Product Owner's Role and Concerns In general, the role of the Product Owner in Scrum development is to manage the development requirements through a product backlog and maximize the value of the product by defining the development direction. It’s a crucial role in Prism Japan as it is in many organizations, and a not an easy one to make tangible decisions to reach this vague concept that is to maximize the value of a product. At first, there were endless concerns over whether their decision was the correct one, or if the user really needed a certain functionality. They took two decisive actions to address their issues, and as a result, they can now make decisions based on an established criteria. Step ①: Redefine user issues that Prism Japan should solve All Scrum team members took part in a workshop based on the Jobs Theory framework. I won't go into the details of the theory, but this allowed us to define the essence of the value that Prism Japan should deliver to its users. Step ②: Implementing data-driven decision making Since our Product Owner has experience as a data engineer and data analyst, he designs user logs, visualizes application usage, and makes analyses based on problem hypotheses. This made it possible for us to incorporate app-related issues into our development policies, while assessing the acceptance of released features by users. The Story of An Issue with Scrum and How We Solved It Finally, I will talk about an issue we had with developing with Scrum and how we solved it. The Issue: the Product Owner and the engineers did not agree on what they wanted to do When we first started developing with Scrum, we struggled to communicate requirements and specifications to each other accurately and at the right time. Various factors contributed to the challenges, including the delay in finalizing specific specifications until development started, or the fact that we relied on verbal coordination, leading to discrepancies in how each team member interpreted the information. The Solution: Use sprint refinement and sprint planning Courtesy is necessary for a good relationship, even with Scrum. Changing the timing and manner of the requests and properly incorporating them into the Scrum events was very effective. Sprint Refinement We also conducted Refinement sessions the week before each Sprint. The Product Owner explains the User Story, agrees to the requirements, and makes a quick quote. The Product Owner has to decide on the User Story they want to address in the next sprint in advance. Sprint Planning Beginning by establishing the priority of User Stories and tasks, we then reach a consensus on the goals of each Sprint. That ensures that the work is feasible in light of past performance, giving engineers accountability and confidence in what they are doing during the Sprint. The Impact of Implementing Scrum Although there were some minor issues using Scrum in the beginning, overall, it brought positive changes to the team. I will look back on what issues we had before we started using Scrum and what benefits it brought. Since the development process was not shared between the frontend and backend teams, there was no cross-team consensus. Now, we are able to understand what both parties are working on at the Daily Scrum. In addition, during refinement, planning and other events, we had many discussions on backend implementation policy based on the requests from the frontend side, and we started development smoothly and avoided a lot of detailed rework. There was a lack improvements that considered both frontend and backend aspects. I think discussions have improved a lot since engineers participate in them with a sense of autonomy, responsibility, and desire to improve the app. We now have discussions at the architecture level considering performance and future scalability, and we can organize things that we would not even discuss if the teams were divided. Members who don’t work with Project Managers closely were less likely to have ownership because they developed on a per-request basis Instead of working only on specific requests, as they work on User Stories, engineers now engage in consideration, discussions, and even proposals to devise the best approach for accomplishing tasks in the most effective manner. Not only did we improve the development, but I felt that many team members grew with each Sprint. Conclusion The development team and the planning/ operation team share a common purpose and work together to make improvements. I hope this article could serve as a reference for those who are developing with Agile Scrum development and those who are just starting! Prism Japan was just released a little over a year ago, and since then, the app has experience growth and attracted an increasing number of members. Feel free to try the app and witness firsthand how it has evolved through our development system! For those who want to try Prism Japan You can install Prism Japan through the link below. iOS: App Store Android: Google Play

Hello. I am @hoshino from the DBRE team. The Database Reliability Engineering (DBRE) team operates as a cross-functional organization, tackling database-related challenges and building platforms that balance organizational agility with effective governance. Database Reliability Engineering (DBRE) is a relatively new concept, and only a few companies have established dedicated DBRE organizations. Among those that do, their approaches and philosophies often differ, making DBRE a dynamic and continually evolving field. For information on the background of the establishment of the DBRE team at our company and the team's role, please refer to our tech blog, " The Need for DBRE at KTC. ” This article discusses an issue encountered during the migration from Amazon Aurora MySQL 2 to Amazon Aurora MySQL 3, where the execution of the mysqldump command terminates unexpectedly without displaying an error message. I hope this proves helpful. The root cause of the error Let's start by explaining the cause of the error. The process terminated without an error message in this case because the collation set in the trigger of the Amazon Aurora MySQL 2 database was utf8mb4_0900_ai_ci , which is not supported in MySQL 5. As a result, mysqldump was unable to recognize it. The investigation process that led to identifying the root cause and determining the solution will be explained in detail below. The phenomenon that occurred When executing the mysqldump command directly to export data from Aurora MySQL 2, the process unexpectedly terminated without generating an error message. After executing the command, I checked the exit code, and 2 ( Internal Error ) was returned. It was evident that an error had occurred, but the exact cause could not be determined. $ mysqldump --defaults-extra-file=/tmp/sample.cnf > sample.sql $ echo $? 2 Cause investigation. To determine the root cause of the issue, I followed these steps. First, I examined the behavior by running a different version of the mysqldump command. This time, I am utilizing the mysqldump command from the MySQL 5.7 series for Aurora MySQL 2. $ mysqldump --version mysqldump Ver 10.13 Distrib 5.7.40, for linux-glibc2.12 (x86_64) I attempted to perform the export using the mysqldump command from MySQL 8. $ mysqldump80 --version mysqldump Ver 8.0.31 for Linux on x86_64 (MySQL Community Server - GPL) $ mysqldump80 --defaults-extra-file=/tmp/sample.cnf > sample.sql $ echo $? 0 The result was successful. This indicates that the error might be caused by a version difference in MySQL. Furthermore, to investigate the possibility that the mysqldump command itself might be causing an internal error, I tested various options to determine whether any error messages appeared. The result showed that adding the --skip-triggers option prevents the error. $ mysqldump --defaults-extra-file=/tmp/sample.cnf --skip-triggers > sample.sql $ echo $? 0 The result suggests that the error occurs in the trigger-related part. So, I checked the trigger settings. mysql> SHOW TRIGGERS FROM sample_database \G *************************** 1. row *************************** Trigger: sample_trigger Event: UPDATE Table: sample_table Statement: BEGIN SET NEW.`lock_version` = OLD.`lock_version` + 1; END Timing: BEFORE Created: 2024-10-04 01:06:38.17 sql_mode: STRICT_TRANS_TABLES Definer: sample-user@% character_set_client: utf8mb4 collation_connection: utf8mb4_general_ci Database Collation: utf8mb4_0900_ai_ci *************************** 2. row *************************** (The rest is omitted) Here, I noticed that the database collation was set to utf8mb4_0900_ai_ci . This is a collation that is not recognized by MySQL 5. I modified the trigger definition of the table where the error occurred to utf8mb4_general_ci and then executed the mysqldump command again. mysql> SHOW TRIGGERS FROM kinto_terms_tool \G *************************** 1. row *************************** Trigger: sample_trigger Event: UPDATE Table: sample_table Statement: BEGIN SET NEW.`lock_version` = OLD.`lock_version` + 1; END Timing: BEFORE Created: 2024-10-04 01:06:38.17 sql_mode: STRICT_TRANS_TABLES Definer: sample-user@% character_set_client: utf8mb4 collation_connection: utf8mb4_general_ci Database Collation: utf8mb4_general_ci *************************** 2. row *************************** (The rest is omitted) $ mysqldump --defaults-extra-file=/tmp/sample.cnf > sample.sql $ echo $? 0 The mysqldump command was successful. This difference in collation also explains the successful execution of commands in MySQL 8. This investigation revealed that the mysqldump failed because the database collation set in the trigger was utf8mb4_0900_ai_ci , which does not exist in MySQL 5. Relationship between Amazon Aurora MySQL 2 and MySQL 5.7 Amazon Aurora MySQL 2 is based on MySQL 5.7, but the two are not entirely identical. AWS has added its own extension functions to Aurora, incorporating some features from MySQL 8.0, such as the utf8mb4_0900_ai_ci collation sequence, which was the root cause of the problem. When I try to specify utf8mb4_0900_ai_ci as a collation in MySQL 5.7, the following error occurs: mysql> ALTER DATABASE sample_database CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci; ERROR 1273 (HY000): Unknown collation: 'utf8mb4_0900_ai_ci' On the other hand, the same command is executed normally in Aurora MySQL 2. mysql> ALTER DATABASE sample_database CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci; Query OK, 1 row affected (0.03 sec) mysql> SHOW CREATE DATABASE sample_database; +------------------+---------------------------------------------------------------------------------------------------------+ | Database | Create Database | +------------------+---------------------------------------------------------------------------------------------------------+ | sample_database | CREATE DATABASE `sample_database` /*!40100 DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci */ | +------------------+---------------------------------------------------------------------------------------------------------+ 1 row in set (0.00 sec) Further investigation To determine if the error was solely caused by the trigger, I examined other MySQL objects as well. In an Aurora MySQL 2 environment, I created a view with the collation set to utf8mb4_0900_ai_ci and observed its behavior during the dump process. CREATE VIEW customer_view AS SELECT customer_name COLLATE utf8mb4_0900_ai_ci AS sorted_name, address FROM customers; When I run the mysqldump command, it succeeds without any errors. $ mysqldump --defaults-extra-file=/tmp/sample.cnf > sample.sql $ echo $? 0 Next, I conducted the same test with a stored procedure in the Aurora MySQL 2 environment. DELIMITER // CREATE PROCEDURE sample_procedure() BEGIN DECLARE customer_name VARCHAR(255); -- String manipulation with specified collation SET customer_name = (SELECT name COLLATE utf8mb4_0900_ai_ci FROM customers WHERE id = 1); -- Comparison using collation IF customer_name COLLATE utf8mb4_0900_ai_ci = 'sample' THEN SELECT 'Match found!'; ELSE SELECT 'No match.'; END IF; END // DELIMITER ; In this case as well, the dump completes successfully without any issues. $ mysqldump --defaults-extra-file=/tmp/sample.cnf > sample.sql $ echo $? 0 Aurora MySQL 2 allows you to use the collation utf8mb4_0900_ai_ci , which does not exist in MySQL 5. However, I discovered that when the mysqldump command is based on MySQL 5, it fails to recognize this collation, resulting in errors, particularly in trigger-related sections. Since the issue does not occur with views or stored procedures, I suspect that the problem is related to how collation is handled in triggers. Solution The problem in question occurred because the collation of the database set in the trigger was utf8mb4_0900_ai_ci , which is not supported in MySQL 5. To address the error, I changed the database collation to utf8mb4_general_ci and reconfigured the trigger. This enables the mysqldump command in MySQL 5.7 to correctly recognize the collation, allowing the export to be performed successfully. ALTER DATABASE sample_database CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; -- Recreate the trigger if necessary Another solution is to use the mysqldump command for MySQL 8.0. MySQL 8.0 clients can recognize utf8mb4_0900_ai_ci , so it is possible to export without changing the collation of the database. $ mysqldump80 --defaults-extra-file=/tmp/sample.cnf > sample.sql $ echo $? 0 In certain situations, changing the client version may not be feasible due to environmental or other dependency constraints. Conclusion In this case, the mysqldump command terminated without displaying any error messages, and it was only by checking the exit code that I discovered an error had occurred. If the process concludes without an error message like this, there is a risk of unknowingly exporting or importing incomplete data. Therefore, when backing up or migrating a database, it is crucial to verify the processing results, such as by checking the exit code. Aurora MySQL 2 has already reached its End of Life (EOL) and is no longer supported. Please be mindful if you still have any environments running on Aurora MySQL 2 and are planning a migration

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