はじめに こんにちは。KINTO Technologiesのグローバル開発部でフロントエンド開発をしているクリスです。 今日はフロントエンドの開発におけるちょっとした詰まったこととそれの解決策について紹介したいと思います！ 詰まったこと 普段みなさんは以下のようにアンカータグ(aタグ)を使ってとあるページの特定部分までスクロールさせたい時ありますよね？ スクロール先の要素にidを付与し、aタグに href="#{id}" をつければそれが実現できます。 <a href="#section-1">Section 1</a> <a href="#section-2">Section 2</a> <a href="#section-3">Section 3</a> <section class="section" id="section-1"> Section 1 </section> <section class="section" id="section-2"> Section 2 </section> <section class="section" id="section-3"> Section 3 </section> 記事や規約など長いページだと、ユーザーにとって役に立ちます。 しかし、現実では多くの場合、ヘッダーといったページの上に固定する要素があって、aリンクをクリックし、スクロールされた後に少し位置がずれてしまいます。 例えば以下のようなヘッダーがあるとします。 <style> header { position: fixed; top: 0; width: 100%; height: 80px; background-color: #989898; opacity: 0.8; } </style> <header style=""> <a href="#section-1">......</a> <a href="#section-2">......</a> <a href="#section-3">......</a> ... </header> あえてこのヘッダーを少し透過にしましたが、aリンクをクリックして、移動になった後に、一部のコンテンツがヘッダーの後ろに隠れてしまったことがわかります。 HTMLとCSSだけを用いた解決策 aリンクをクリックした時に、Javascriptでヘッダーの高さを取得し、スクロール位置からヘッダーの高さを引いてスクロールさせれば問題解決できますが、今日はHTMLとCSSを用いた解決策を紹介したいと思います。具体的には本来到達したい <section> より少し上に別の <div> を用意し、その要素までスクロールさせる方法です。 先ほどの例に戻って、まず各セッションの中に一つのdivタグを作ります。そして該当divタグに一つのclass、例えば anchor-offset を付与し、さらに元々 <section> タグに付与したidも新しく作った div タグに移します。 <section> <div class="anchor-offset" id="section-1"></div> <h1>Section 1</h1> ... </section> そしてcssで <section> タグと .anchor-offset のスタイル定義をします。 /* アンカーを設置する必要がある要素のみ付与したい場合はclassを利用 */ section { position: relative; } .anchor-offset { position: absolute; height: 80px; top: -80px; visibility: hidden; } 上記のように設定すると、aリンクをクリックした時に、該当する <section> の本位置ではなく、それより少し(例の場合では80px)上の部分までスクロールされ、ヘッダーの高さ(80px)と相殺されます。 Vueにおける書き方 Vueでは値を cssにバインドする ことができます。この機能を利用し、高さを動的に設定しコンポーネントにすれば、さらにメインテナンスしやすくなると思います。 <template> <div :id="props.target" class="anchor-offset"></div> </template> <script setup> const props = defineProps({ target: String, offset: Number, }) const height = computed(() => { return `${props.offset}px` }) const top = computed(() => { return `-${props.offset}px` }) </script> <style scoped lang="scss"> .anchor-offset { position: absolute; height: v-bind('height'); top: v-bind('top'); visibility: hidden; } </style> まとめ 以上、aタグでページの特定部分までスクロールする際にヘッダーなどの固定要素に合わせたスクロール位置の調整方法でした。 他にも色々なやり方がありますが、ご参考になれたらと思います！

👋Introduction Hello! I am Sasaki, a Project Manager in the Project Promotion Group at KINTO Technologies. In my career to date, I have worked as a programmer, designed as a Project Lead, trained members, and handled tasks akin to those of a Project Manager (defining requirements, managing stakeholders, etc.). In my previous job, I worked on Agile with the whole team for about three years and went through a real Kaizen (improvement) journey. As I am passionate about this topic, I really wanted to write an article about Agile development today! 🚗Toyota and Agile How are you incorporating Agile development methodology into your team? There are various forms of Agile development, such as Scrum for new services and Kanban for operation and maintenance. However, when learning Agile development, many of you may have encountered Lean Development and the Toyota Production System, which is said to be the origin of Agile development[^1]. In this article, I will visualize the approaches to Agile of KINTO Technologies, a Toyota group company. I also hope to help those who are working on Agile in the company gain new insights through visualization. [^1]: Agile books citing Toyota The Agile Samurai Lean from the Trenches Kanban in Action and more ::: message ### This article is useful for - those who want to understand their team's Agile state - those who are a bit stuck in a rut when it comes to how to proceed with Agile - those who are facing challenges reconciling Agile ideals with their realities - those who want to know about KINTO Technologies' approach to Agile ::: Method Quantitative visualization of each team's level of Scrum with the Scrum Checklist Discussion while reviewing the results of Step 1 Casually sharing teams future plans First, use the Scrum Checklist to visualize how much of each Scrum indicator have you accomplished so far.  Once visualized, let discussions begin. Use the 4L Reflection Framework for discussion. https://www.ryuzee.com/contents/blog/14561 :::details Notes on the use of Scrum Checklist The provided Scrum Checklist has a note. Do not use it to compare with other teams for evaluation. It is not intended to compete with other teams. Instead, we use it as an opportunity for discussion to place different Agile teams in a similar context. If you use it in a similar way to this article, please avoid using it as a way to judge or evaluate people or teams, and use it among members in a constructive and mature manner. ::: 🎉Participating Members We asked for cooperation from Scrum Masters -or people in similar positions- who manage Scrum or Agile-like teams in their organization, and 10 teams (10 people from different teams) came! Thank you all for your time and cooperation! How we did it ✅ Scrum Checklist We made various charts. The results varied widely depending on the team's situation, such as some people saying "Although what we do is close to Waterfall, I am running a Scrum event", or others expressing "I felt that there were some issues, but the score came out higher than expected." Some teams had indicators with low scores but no major current issues, such as "We do not have a Scrum Master, but we are rotating Scrum events among developers," or "We do not have a product backlog, but we have a good relationship with the owner." Since each of the participants had different areas of expertise, we were able to encourage mutual learning by having participants teach each other about indicators that some were less familiar. Many teams in Group A had organized backlogs, while many teams in Group B were experiencing challenges with their backlogs. Maybe we can exchange knowledge on organizing backlogs...👀 📒Reflection (4L Reflection) We split into two groups and reflected. In my previous career, I tried hard to get people to speak up, but at KINTO Technologies, the board filled up in 5 to 8 minutes, giving the impression that they were active in sharing their opinions. The red sticky notes are their impressions after seeing other people's notes. Group A Results Group B Results This time, we used the WhiteBoard, a new addition to Confluence recommended by Kin-chan . Sticky notes can be converted directly into JIRA tickets, which can be used to organize action items. 🚩Results of the Reflection Here is some of the feedback among the many voices. Many people expressed a desire to strengthen relationships with product owners (POs) to optimize the use of their services and get faster. I got the impression that many teams were highly self-organized. Liked Visualization helped us understand the team's strengths and weaknesses We were able to understand the areas where we diverged from the ideal Scrum That developers are able to work responsibly and autonomously (self-organized) Lacked Product Owners are not present or not included in many Scrum events Story Point (SP) setting and estimation are not done well Due to the increase in team members, some feel the need to split up the team. Learned I was able to learn about different Agile initiatives and products in our company Sprint periods can be set shorter or longer depending on each team's situation Longed for (excerpt) Although not action items, they were able to set themselves informal goals to keep growing. To revise the length of their Sprints To split teams into smaller ones To improve communication with POs 💭Thoughts I was really surprised that people from different departments and offices, some of whom I had never met before, participated when I called them to gather for this session, even though it was my second month in the company. I would like to thank everyone again for their cooperation. By bringing together the people who practice Agile in the company, I made the following discoveries and learned the following lessons as a facilitator. Scrum checklists can be used to quantitatively visualize a team's level of Scrum Listening to other teams at different stages of their Scrum journey can provide an opportunity for improvement and courage in our activities Connecting Scrum Masters from different teams created an opportunity to find like-minded individuals to ask for advice on various issues. We were able to find issues that were common across teams (such as the need to improve communication with POs and to split teams) I did not participate actively as much as I was focused on facilitation, but when I heard a participant say, "I was on the brink of giving up, but learning about everyone's activities encouraged me," I was almost moved to tears. In the face of Agile challenges in my career, I augmented my solutions and empathy by engaging in external study groups and reading relevant books. I think it's always great to be able to share these challenges within the company and have someone to discuss issues with. 🏔Summary: Which Agile Milestone Are We at Now? At KINTO Technologies, our development approach adapts to the nature of the project. For large-scale projects, Waterfall is more common, and we use Agile for other project types. This time, we tried to visualize the level of Agile within the company from the perspective of Scrum, and found that each team has various ways of approaching Agile and their issues. So... which Agile milestone are we at now? To this question, we found no clear answer! (Sorry!) However, I feel that by gathering with other Scrum Masters, we went further down the Agile path together! ✨ What I Want to Do in the Future I am in a cross-sectional team called the Project Promotion Group. I know this is a bit presumptuous since I just joined the company, but I hope to use this as an opportunity to help promote cross-team development through initiatives such as Scrum of Scrums and reflection of reflections (meetings where team improvements are shared with other Scrum Masters). Agile Samurai ends with the words, "It doesn't matter if it is Agile or not!" I would like to continue to kaizen as much as I can and continue climbing Mount Agile together with all of you. Be Agile! Thank you for reading this article.

Introduction Hello! I am Uemura from KINTO Technologies' Development Support Division. As a corporate engineer, I am mainly responsible for mobile device management (MDM). We recently held a "case study presentation & roundtable study session, specializing in the field of corporate IT" under the title " KINTO Technologies MeetUp! - 4 cases to share for information systems by information systems ." In this article, I will introduce the contents of the case study "Advancement of Windows Kitting Automation: Introducing Windows Autopilot" which was presented in our recent study session, along with supplementary information. What is Windows Autopilot? Windows Autopilot is a way to register Windows devices in Intune. By pre-registering the hardware hash (HW hash) of the device, it is automatically registered in Intune during the setup. I would like to talk about how we introduced this Windows Autopilot into KINTO Technologies' environment to improve the efficiency of PC kitting. How Windows Autopilot automates kitting Firstly, I will explain the mechanism of kitting automation with Windows Autopilot. The vendor or administrator should register the HW hash of the PC in Intune in advance before kitting. Then, the user (or administrator) starts the PC and signs in. By pre-registering the HW hash, the PC will be automatically registered in Intune. By creating a dynamic group that includes the PC registered with Windows Autopilot, any PC registered in Intune will automatically enrolled to that dynamic group. By assigning the dynamic group shown in step 3 to each configuration profile and app deployment settings, device control and app deployment will be performed automatically. As Windows Autopilot itself is responsible for the device registration function, it falls under step 1 and 2. Dynamic groups should be utilized so that profile control and app deployment of registered devices can be done automatically at step 3 and 4. In other words, it is possible to automate kitting by configuring not only Windows Autopilot registration settings but also device control settings and app deployment to run automatically. Introducing Windows Autopilot It took us about a month and a half to introduce Windows Autopilot, including research and verification. In KINTO Technologies' environment, the HW hash registration of all PCs had already been completed, so only the following two things were done this time. Assigning the Autopilot profile, which is the first thing to be executed during kitting, to the HW hash that had already been registered. Replacing static groups for kitting that have been used for kitting with dynamic groups Autopilot Profile Configuration Assigning the Autopilot profile to the HW hash determines that the corresponding PC is registered in Intune by the Windows Autopilot method. As for the contents of the profile, it is possible to set whether or not to skip the selection such as "Language Setting" and "Windows License Agreement" that are mainly selected on the PC setup screen. Dynamic Group Configuration Since Autopilot-registered devices have an Autopilot device attribute, set this attribute to a dynamic membership rule. *For details, please refer to the following Microsoft site. Create a device group for Windows Autopilot | Microsoft Learn Then specify the dynamic group you created to the "Assign" in configuration profile and app deployment settings. This makes it possible to automate the process from device registration to device control. This completes the kitting automation with Windows Autopilot. Results of Introduction How effective has the introduction of Autopilot been? As a quantitative result, we were able to reduce the work items by about 40% compared to before the introduction. On the other hand, we were not able to achieve that much efficiency in working hours due to the significant time required for installing apps and performing Windows Updates. As a qualitative result, the automation and simplification of kitting process has made it less likely to cause human errors, such as work omissions. Conclusion Ideally, I would like to achieve so-called zero-touch kitting, but if asked whether it has been achieved with the introduction of Autopilot, manual work is still necessary. However, I think that being able to automate a series of processes from device registration to device control has greatly improved the efficiency of PC kitting. We will continue to incorporate new features in our ongoing efforts to further improve efficiency!

自己紹介＆どんな話？ グローバル開発部の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.

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.