Hello. I'm @hoshino from the DBRE team. In the DBRE (Database Reliability Engineering) team, our cross-functional efforts are dedicated to addressing challenges such as resolving database-related issues and developing platforms that effectively balance governance with agility within our organization. DBRE is a relatively new concept, so very few companies have dedicated organizations to address it. Even among those that do, there is often a focus on different aspects and varied approaches. This makes DBRE an exceptionally captivating field, constantly evolving and developing. For more information on the background of the DBRE team and its role at KINTO Technologies, please see our Tech Blog article, The need for DBRE in KTC . In this article, I will introduce the improvements the DBRE team experienced after integrating PR-Agent into our repositories. I will also explain how adjusting the prompts allows PR-Agent to review non-code documents, such as tech blogs. I hope this information is helpful. What is PR-Agent? PR-Agent is an open source software (OSS) developed by Codium AI, designed to streamline the software development process and improve code quality through automation. Its main goal is to automate the initial review of Pull Requests (PR) and reduce the amount of time developers spend on code reviews. This automation also provides quick feedback, which can accelerate the development process. Another feature that stands out from other tools is the wide range of language models available. PR-Agent has multiple functions (commands), and developers can select which functions to apply to each PR. The main functions are as follows: Review: Evaluates the quality of the code and identifies issues Describe: Summarizes the changes made in the Pull Request and automatically generates an overview Improve: Suggests improvements for the added or modified code in the Pull Requests Ask: Allows developers to interact with the AI in a comment format on the Pull Requests, addressing questions or concerns about the PR. For more details, please refer to the official documentation . Why we integrated PR-Agent The DBRE team had been working on a Proof of Concept (PoC) for a schema review system that utilizes AI. During the process, we evaluated various tools that offer review functionalities based on the following criteria: Input criteria: Ability to review database schemas based on the KIC’s Database Schema Design Guidelines Ability to customize inputs to the LMM to enhance response accuracy (e.g., integrating chains or custom functions) Output Criteria: To output review results to GitHub, we evaluated whether the following conditions could be met based on the outputs from the LLM: Ability to trigger reviews via PRs Ability to comment on PRs Ability to use AI-generated outputs to comment on the code (schema information) in PRs Ability to suggest corrections at the code level Despite our thorough investigation, we couldn’t find a tool that fully met our input requirements. However, during our evaluation, we decided to experiment with one of the AI review tools used internally in DBRE team, leading to the adoption of PR-Agent. The main reasons for choosing PR-Agent among the tools we surveyed, are as follows: Open source software (OSS) Possible to implement it while keeping costs down Supports various language models It supports a variety of language models, and you can select the appropriate language model to suit your needs. Ease of implementation and customization PR-Agent was relatively easy to implement and offered flexible settings and customization options, allowing us to optimize it for our specific requirements and workflows. For this project, we used Amazon Bedrock. The reasons for using it are as follows: Since KTC mainly uses AWS, we decided to try Bedrock first because it allows for quick and seamless integration. Compared to OpenAI's GPT-4, using Claude3 Sonnet through Bedrock reduced costs to about one-tenth. For these reasons, we integrated PR-Agent into the DBRE team's repository. Customizations implemented during PR-Agent integration Primarily, we followed the steps outlined in the official documentation for the integration. In this article, we’ll detail the specific customizations we made. Using Amazon Bedrock Claude3 We utilized the Amazon Bedrock Claude3-sonnet language model. Although the official documentation recommends using access key authentication, we opted for ARN-based authentication to comply with our internal security policies. - name: Input AWS Credentials uses: aws-actions/configure-aws-credentials@v4 with: role-to-assume: ${{ secrets.AWS_ROLE_ARN_PR_REVIEW }} aws-region: ${{ secrets.AWS_REGION_PR_REVIEW }} Manage prompts in GitHub Wiki Since the DBRE team runs multiple repositories, it was necessary to centralize prompts references. After integrating PR-Agent, we also wanted team members to easily edit and fine-tune prompts. That’s when we considered using GitHub Wiki. GitHub Wiki tracks changes and makes it easy for anyone to edit. So we thought that by using it, team members would be able to easily change the prompt. In PR-Agent, you can set extra instructions for each function such as describe through the extra_instructions field in GitHub Actions. ( Official documentation ) #Here are excerpts from the configuration.toml [pr_reviewer] # /review # extra_instructions = "" # Add extra instructions here [pr_description] # /describe # extra_instructions = "" [pr_code_suggestions] # /improve # extra_instructions = "" Therefore, we customized the setup to dynamically add extra instructions (prompts) listed in the GitHub Wiki through variables in the GitHub Actions where PR-Agent is configured. Here are the configuration steps: First, generate a token using any GitHub account and clone the Wiki repository using GitHub Actions. - name: Checkout the Wiki repository uses: actions/checkout@v4 with: ref: main # Specify any branch (GitHub defaults is master) repository: {repo}/{path}.wiki path: wiki token: ${{ secrets.GITHUB_TOKEN_Foobar }} Next, set the information from the Wiki as environment variables. Read the contents of the file and set the prompts as environment variables. - name: Set up Wiki Info id: wiki_info run: | set_env_var_from_file() { local var_name=$1 local file_path=$2 local prompt=$(cat "$file_path") echo "${var_name}<<EOF" >> $GITHUB_ENV echo "prompt" >> $GITHUB_ENV echo "EOF" >> $GITHUB_ENV } set_env_var_from_file "REVIEW_PROMPT" "./wiki/pr-agent-review-prompt.md" set_env_var_from_file "DESCRIBE_PROMPT" "./wiki/pr-agent-describe-prompt.md" set_env_var_from_file "IMPROVE_PROMPT" "./wiki/pr-agent-improve-prompt.md" Finally, configure the action steps for the PR-Agent. Read the content of each prompt from the environment variables. - name: PR Agent action step id: Pragent uses: Codium-ai/pr-agent@main env: # model settings CONFIG.MODEL: bedrock/anthropic.claude-3-sonnet-20240229-v1:0 CONFIG.MODEL_TURBO: bedrock/anthropic.claude-3-sonnet-20240229-v1:0 CONFIG.FALLBACK_MODEL: bedrock/anthropic.claude-v2:1 LITELLM.DROP_PARAMS: true GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} AWS.BEDROCK_REGION: us-west-2 # PR_AGENT settings (/review) PR_REVIEWER.extra_instructions: | ${{env.REVIEW_PROMPT}} # PR_DESCRIPTION settings (/describe) PR_DESCRIPTION.extra_instructions: | ${{env.DESCRIBE_PROMPT}} # PR_CODE_SUGGESTIONS settings (/improve) PR_CODE_SUGGESTIONS.extra_instructions: | ${{env.IMPROVE_PROMPT}} By following the steps outlined above, you can pass the prompts listed on the Wiki to PR-Agent and execute them. What we did to expand review targets to include tech blogs Our company’s tech blogs are managed in a Git repository, which led to the idea of using PR-Agent to review blog articles like code. Typically, PR-Agent is a tool specialized for code reviews. The Describe and Review functions worked somewhat when we tested it on blog articles. Still, the Improve function only returned "No code suggestions found for PR," even after adjusting the prompts (extra_instructions).(This behavior likely occurred because PR-Agent is designed primarily for code review.) To address this, we tested whether customizing the System prompt for the Improve function would enable it to review blog articles. After customization, we received responses from the AI, so we also decided to proceed with customizing the system prompts. System prompt refers to a prompt that is passed separately from the user prompt when invoking LLM. It also includes specific instructions on the items to be output and the format. The extra_instructions that I explained earlier are part of the system prompt, and it appears that if the user provides additional instructions in PR-Agent, those instructions are incorporated into the system prompt. # Here are the excerpts from the system prompt for Improve [pr_code_suggestions_prompt] system="""You are PR-Reviewer, a language model that specializes in suggesting ways to improve for a Pull Request (PR) code. Your task is to provide meaningful and actionable code suggestions, to improve the new code presented in a PR diff. omission {%- if extra_instructions %} Extra instructions from the user, that should be taken into account with high priority: ====== {{ extra_instructions }} # Add the content specified in the extra_instructions. ====== {%- endif %} omission PR-Agent allows you to edit system prompts from GitHub Actions, just like extra_instructions. By customizing the existing system prompts, we expanded the review capabilities to include not only code but also text. Below are some examples of our customizations: First, we modified the instructions specific to the code so they could be used to review tech blogs. System prompt before customization You are PR-Reviewer, a language model that specializes in suggesting ways to improve for a Pull Request (PR) code. Your task is to provide meaningful and actionable code suggestions, to improve the new code presented in a PR diff. # Japanese translation # あなたは PR-Reviewer で、Pull Request (PR) のコードを改善する方法を提案することに特化した言語モデルです。 # あなたのタスクは、PR diffで提示された新しいコードを改善するために、有意義で実行可能なコード提案を提供することです。 System prompt after customization You are a reviewer for an IT company's tech blog. Your role is to review the contents of .md files in terms of the following. Please review each item listed as a checkpoint and identify any issues. # Japanese translation # あなたはIT企業の技術ブログのレビュアーです。 # あなたの役割は、.mdファイルの内容を以下の観点からレビューすることです。 # チェックポイントとして示されている各項目を確認し、問題があれば指摘してください。 Next, we will modify the section with specific instructions so that you can review the tech blog. Changing the instructions regarding the output would affect the program, so we have customized it so that tech blogs can be reviewed by simply replacing code review instructions with text. System prompt before customization Specific instructions for generating code suggestions: - Provide up to {{ num_code_suggestions }} code suggestions. The suggestions should be diverse and insightful. - The suggestions should focus on ways to improve the new code in the PR, meaning focusing on lines from '__new hunk__' sections, starting with '+'. Use the '__old hunk__' sections to understand the context of the code changes. - Prioritize suggestions that address possible issues, major problems, and bugs in the PR code. - Don't suggest to add docstring, type hints, or comments, or to remove unused imports. - Suggestions should not repeat code already present in the '__new hunk__' sections. - Provide the exact line numbers range (inclusive) for each suggestion. Use the line numbers from the '__new hunk__' sections. - When quoting variables or names from the code, use backticks (`) instead of single quote ('). - Take into account that you are reviewing a PR code diff, and that the entire codebase is not available for you as context. Hence, avoid suggestions that might conflict with unseen parts of the codebase. System prompt after customization Specific instructions for generating text suggestions: - Provide up to {{ num_code_suggestions }} text suggestions. The suggestions should be diverse and insightful. - The suggestions should focus on ways to improve the new text in the PR, meaning focusing on lines from '__new hunk__' sections, starting with '+'. Use the '__old hunk__' sections to understand the context of the code changes. - Prioritize suggestions that address possible issues, major problems, and bugs in the PR text. - Don't suggest to add docstring, type hints, or comments, or to remove unused imports. - Suggestions should not repeat text already present in the '__new hunk__' sections. - Provide the exact line numbers range (inclusive) for each suggestion. Use the line numbers from the '__new hunk__' sections. - When quoting variables or names from the text, use backticks (`) instead of single quote ('). After that, add a new Wiki for system prompts, following the steps in "Managing prompts in a Wiki" explained earlier. - name: Set up Wiki Info id: wiki_info run: | set_env_var_from_file() { local var_name=$1 local file_path=$2 local prompt=$(cat "$file_path") echo "${var_name}<<EOF" >> $GITHUB_ENV echo "prompt" >> $GITHUB_ENV echo "EOF" >> $GITHUB_ENV } set_env_var_from_file "REVIEW_PROMPT" "./wiki/pr-agent-review-prompt.md" set_env_var_from_file "DESCRIBE_PROMPT" "./wiki/pr-agent-describe-prompt.md" set_env_var_from_file "IMPROVE_PROMPT" "./wiki/pr-agent-improve-prompt.md" + set_env_var_from_file "IMPROVE_SYSTEM_PROMPT" "./wiki/pr-agent-improve-system-prompt.md" - name: PR Agent action step omission + PR_CODE_SUGGESTIONS_PROMPT.system: | + ${{env.IMPROVE_SYSTEM_PROMPT}} By following the steps outlined above, we customized PR-Agent’s Improve function, which typically specializes in code review, to support the review of blog articles. However, it’s important to note that the responses may not always be 100% as expected, even after modifying the system prompt. This is also true when using the Improve function for program code. Results of installing PR-Agent Implementing PR-Agent has brought the following benefits: Improved review accuracy It highlights issues we often overlook, improving the accuracy of our code reviews. It allows for the review of past closed PRs, providing opportunities to reflect on older code. Reviewing past PRs helps us continually enhance the quality and integrity of our codebase. Reduced burden of creating pull requests (PRs) The pull request summary feature makes creating pull requests easier. Reviewers can quickly see the summary, improving review efficiency and shortening merge times. Improved engineering skills Keeping up with rapid technological advances while managing daily duties can be challenging. The AI’s suggestions have been very effective in learning best practices. Tech Blog Reviews Implementing PR-Agent to our tech blog has reduced the burden of reviews. Although it's not perfect, it checks your articles for spelling mistakes, grammar issues, and consistency of content and logic, helping us find errors that are easy to overlook. Below is an example of a review of an actual tech blog ( Event Report DBRE Summit 2023 ).  Summary of thePull Request (PR) for the tech blog by PR-Agent (Describe)   Review of the Pull Request (PR) for the tech blog by PR-Agent (Review)  Proposed changes to the tech blog by PR-Agent (Improve) It is also important to note that a human being must make the final decision for the following reasons: The PR-Agent’s review results for the exact same Pull Requests (PR) can vary each time, and the accuracy of the responses can be inconsistent. PR-Agent reviews may generate irrelevant or completely off-target feedback Conclusion In this article, we introduced how the implementation and customization of PR-Agent have improved work efficiency. While complete review automation is not yet possible, through configuration and customization, PR-Agent plays a supportive role in enhancing the productivity of our development teams. We aim to continue using PR-Agent to improve efficiency and productivity further.

Introduction Hello! I'm Hasegawa , an Android engineer at KINTO Technologies! I usually work on developing an app called my route . Please check out the other articles written by members of my route's Android Team! Potential Bug Triggers in Android Development Due to Regional Preferences SwiftUI in Compose Multiplatform of KMP In this article, I will introduce how to get OG information in Kotlin (Android) and how to deal with character codes in the process. To be explained in this article What is OGP? How to get OGP in Kotlin The reason why text in the information obtained by OGP is corrupted How to deal with corrupted text What is OGP? OGP stands for "Open Graph Protocol" and is an HTML element that correctly shows the title and image of a web page when sharing it with other services. Web pages configured with OGP have meta tags that represent this information. The following is a meta tag that excerpts part of it. Services that want to get OG information can read information from these meta tags. <meta property="og:title" content="page title" /> <meta property="og:description" content="page description" /> <meta property="og:image" content=" thumbnail image URL" /> How to get OGP in Kotlin This time, I will use OkHttp for communication and Jsoup for HTTP parsing. First, use OkHttp to access the web page of the URL where you want to get OG information. I will omit error handling since it varies depending on the requirements. val client = OkHttpClient.Builder().build() val request = Request.Builder().apply { url("URL for wanted OG information") }.build() client.newCall(request).enqueue( object : okhttp3.Callback { override fun onFailure(call: okhttp3.Call, e: java.io.IOException) {} override fun onResponse(call: okhttp3.Call, response: okhttp3.Response) { parseOgTag(response.body) } }, ) Then parse the contents using Jsoup. private fun parseOgTag(body: ResponseBody?): Map<String, String> { val html = body?.string() ?: "" val doc = Jsoup.parse(html) val ogTags = mutableMapOf<String, String>() val metaTags = doc.select("meta[property^=og:]") for (tag in metaTags) { val property = tag.attr("property") val content = tag.attr("content") val matchResult = Regex("og:(.*)").find(property) val ogType = matchResult?.groupValues?.getOrNull(1) if (ogType != null && !content.isNullOrBlank()) { ogTags[ogType] = content } } return ogTags } Now ogTags has the necessary OG information. The reason why text in the information obtained by OGP is corrupted I think that I can get the OG information of most web pages correctly so far. However, for some web pages, corrupted text may occur. Here, I will explain the cause. This time, I called string() as shown below. val html = response.body?.string() ?: "" This function selects the character code in the following order of precedence: BOM (Byte Order Mark) information Response header charset UTF-8 unless specified in 1 and 2 More information can be found in the OkHttp repository comments . In other words, what if there is no BOM information, no response header charset, and a web page encoded in a non-UTF-8 format such as Shift_JIS? ... Text corruption occurs. Because it decodes with the default UTF-8. So what do we do? In the next section, I will explain how to respond. How to deal with corrupted text I found the cause of the corrupted text in the previous section. In fact, the character code may be specified in the HTML in the web page as follows. If there is no BOM information and the response header charset is not specified, this information could be used. <meta charset="UTF-8"> <!-- HTML5 --> <meta http-equiv="content-type" content="text/html; charset=Shift_JIS"> <!-- before HTML5 --> However, there is a contradiction that HTML must be parsed according to the character code in order to read the specified meta tag. Or so you might think. For example, UTF-8 and Shift_JIS are compatible in the range of ASCII characters, so it is not a problem to decode with UTF-8 once. (This method may parse twice. If you check the byte array of the meta tag beforehand, you may be able to determine the character code before parsing, but this time I focused on the code comprehensibility.) So, you can write code like the following. /** * Get the Jsoup Document from the response body * If the response body charset is not UTF-8, parse the charset again */ private fun getDocument(body: ResponseBody?): Document { val byte = body?.Bytes() ?: byteArrayOf() // If charset is specified in ResponseHeader, it is decoded with that charset val headerCharset = body?.contentType()?.charset() val html = String(byte, headerCharset ?: Charsets.UTF_8) val doc = Jsoup.parse(html) // If headerCharset is specified, the charset should parse correctly // return as is. If (headerCharset ! = null) { return doc } // Get the charset from the meta tag in the HTML. // If this charset is not present, the character code is unknown and the UTF-8 parsed doc is returned. val charsetName = extractCharsetFromMetaTag(html) ?: return doc val metaCharset = try { Charset.forName(charsetName) } catch (e: IllegalCharsetNameException) { Timer.w(e) return doc } // If the charset specified in the meta tag and UTF-8 are different, parse again with the charset specified in the meta tag // Parsing is a relatively heavy process, so don't double it. return if (metaCharset != Charsets.UTF_8) { Jsoup.parse(String(byte, metaCharset)) } else { doc } } /** * Get the charset string from the HTML meta tag * * Less than HTTP5 -> meta[http-equiv=content-type] * HTTP5 or higher -> meta [charset] * * @return charset character string ex) "UTF-8", "shift_JIS" * Null if @return charset is not found */ private fun extractCharsetFromMetaTag(html: String): String? { val doc = Jsoup.parse(html) val metaTags = doc.select("meta[http-equiv=content-type], meta [charset]") for (metaTag in metaTags) { if (metaTag.hasAttr("charset")) { return metaTag.attr("charset") } val content = metaTag.attr("content") if (content.contains("charset=")) { return content.substingAfter("charset=").split(";")[0].trim() } } return null } Then, let's change the function that creates the Jsoup Document as follows using the process that we just created. - val html = body?.String() ?: "" - val doc = Jsoup.parse(html) + val doc = getDocument(body) Conclusion Thank you for reading this far. Most web pages use UTF-8 character code, and even if you use a different character code, most of the time the charset is specified in the BOM or response header. Therefore, I do not think that this kind of problem will occur very often. However, if you find such a site, it may be difficult to understand the cause and how to fix it. I hope this article will help you.

Hello. My name is Zume, and I am the group manager of the Quality Assurance (QA) Group at KINTO Technologies. Although I have a long and extensive history in QA, I haven’t been particularly focused on sharing my experience or knowledge until now. However, I thought it would be a good idea to take some time to gather my thoughts, but before I knew it, 2022 came to an end with the ringing of the bells on New Year's Eve. It's tough to find time for myself when I’m usually busy with work. This has always been my excuse for not making time for personal projects. If I keep saying "I'll do it next month" a few more times, I'll soon find myself welcoming a new year. About test management This time, I would like to introduce the benefits of the test management tools used by my group and the journey we took to implement them. To all the QA engineers reading this article, how are you managing your test cases? Some of you may already be using some kind of paid test management tool. Generally, Excel or Spreadsheets tend to be used for managing test cases and test executions. However, when using Excel or Spreadsheets for test management, we encountered several challenges: Challenges in the test process - Issues - ⇒ Concerns (potential issues) Test case structuring often becomes personalized by the test designers, and case classifications and formats vary. ⇒When the designer changes, the handover process becomes complicated ⇒Due to the lack of standardized format, it takes time to understand cases when the project changes. To review the cases, you need to open and check the contents of files each time. ⇒It is difficult to share documents and know-how within the team. Stakeholders (other than QA) have a hard time getting an overview of the test content and results. ⇒The QA side needs to prepare reports for stakeholders. For regression testing, a new file needs to be created for each test cycle. ⇒It becomes difficult to track which cases were reused. It is difficult to follow the change history or update history of test cases. ⇒Maintenance, including case updates, takes a lot of time (plus Excel is not suitable for simultaneous online editing by multiple users) Since the test execution results are entered manually, the exact execution time is unknown. ⇒It is challenging to pinpoint the exact time when defects occur Test cases and bug reports are not linked ⇒It becomes difficult to compile statistics such as the defect rate for each function (manual compilation is possible but very tedious). And so on. To address these challenges, we considered implementing tools that support a series of test activities such as test requirements management, test case creation, test execution, and test reporting. In fact, we never considered using Excel or Spreadsheets from the beginning. This is because we knew from our experience that once Excel-based operations become ingrained, it takes a lot of time to shift away from them. Evaluation of tools to be implemented Initially, the tools we considered were: TestLink : An open source web-based test management tool. Free of charge. TestRail : A web-based test management tool. Paid. Zephyr for JIRA : A JIRA plugin. Paid. (Renamed to Zephyr Squad in 2021[^1]) [^1]: Zephyr for Jira is now Zephyr Squad , SmartBear Software., 2021 One of the reasons we considered TestLink was my experience with it at my previous workplace. Another advantage is that it can be tested right away by installing Docker even in a local environment. In fact, I once used a Mac for both testing and running TestLink. However, I joined KINTO Technologies in March 2020 (when it was still KINTO Co., Ltd.), and the project for which we planned to introduce the tool was scheduled to be released two months later, in May. To make things more challenging, the first state of emergency due to the spread of the new COVID-19 was declared in April during this period. In such a nerve-wracking situation, which tool did we choose as the most appropriate option? It was Zephyr for JIRA . The biggest advantage was that it could be implemented quickly as an add-on for JIRA, which was already being used within the company. Additionally, considering the unexpected shift to remote work during the COVID-19 pandemic, it was convenient since it could be accessed from outside the company. Although it was a paid tool, we decided to start using it with the idea that if we could get through the May release, we would reassess its continued use. Looking back at my notes from that time: Since it's a JIRA plugin, I thought I could change the language settings, but it seems only parts of it support Japanese. Zephyr's reports are based on scenarios, and there is no reporting function for individual test steps. etc. [^2] [^2]: ※It seems that requests for step-by-step reports have been made by users as early as 2013, according to the Atlassian community. However, in the comment , TestFLO was recommended as an alternative solution. These notes reflect our trial and error process. It brings back all the memories. Although it was easy to implement, it is still essential for users to be familiar with the system and possess the necessary skills. In that sense, I am still grateful to the team members who flexibly navigated that chaotic period with me. Using Zephyr It's been almost three years(!)Even though it’s an old story, here are my impressions of using Zephyr for JIRA. As it is a JIRA plugin, test cases can be created in the same way as normal issues by selecting the desired issue type. Case items include steps, expected values, results, status, comments, and file attachments, making it convenient to leave screen captures as evidence for each step. On the other hand, it took quite a long time to load the plugin itself. The problem was that it took a few seconds each time we changed screens. A similar question for help was posted on the Atlassian community, so it may be a Zephyr-specific issue . And now to TestLink Now, let's talk about test management after we somehow managed to meet the release schedule and handed off the project in May 2020. We reconsidered the cost aspect as well. Assuming the tool is linked to JIRA and the number of users is around 10 to 20 people, the prices as of 2020 were as follows: Zephyr for JIRA: 11-100 Users ¥510/user/month ⇒ ¥10,200/month for 20 users TestRail: 1-20 Users $32/user/month ⇒ $640 (approx. ¥83,200)/month for 20 users The prices as of 2023 are as follows: Zephyr Squad: 11-100 Users ¥570/user/month ⇒ ¥11,400/month for 20 users TestRail: 1-20 Users $37/user/month ⇒ $740 (approx. ¥96,200)/month for 20 users The fee structure has changed slightly since then, and the prices have gone up a bit. *All prices are calculated at 130 yen to the dollar At first glance, Zephyr seems like a good deal, but since it is a plugin for JIRA, you will actually need to have the same number of licenses as you do for JIRA. In that regard, since not everyone in the Development Division will use it and only QA members will, we want to avoid increasing costs as the organization expands. Still, TestRail is quite expensive. Considering the cost, there is no better option than the free TestLink. Although the UI of TestLink is not the best (it's open source so I won't complain), as a test management tool, it can at least resolve the issues mentioned above as follows. Testing process challenges and their solutions Challenges in the test process When the tool is implemented Concerns when using the tool 1. Test case structuring often becomes personalized by the test designers, and case classifications and formats vary. By describing test suites, test cases, test steps, etc. in a certain format with appropriate detail, a certain degree of granularity is achieved. Easy handover and case deciphering! 2. To review the cases, you need to open and check the contents of files each time. High visibility of implementation items and easy tracing to test requirements make it easy to understand coverage Documents can be easily shared within and outside the team! 3. It is difficult for stakeholders to get an overview of the test contents and results. With real-time tracking of test progress and results viewable in reports, there’s no need for QA to create reports! 4. For regression testing, a new file needs to be created for each test cycle. It can be used on a test suite basis It's easy to identify reusable components! 5. It is difficult to record the change history and update history of test cases. In addition to adding and modifying test cases, the history can be recorded. Case maintenance is easier! 6. Since the test execution results are entered manually, the exact execution time is unknown. Bug reports, execution times, and execution record are accurately logged. You can narrow down the implementation time period! 7. Test cases and bug reports are not linked Easier tracking of requirements/releases, such as test progress rate and defect occurrence rate It's easy to compile data such as the defect occurrence rate for each function! So, we decided to introduce TestLink from June 2020 onwards. Well, I'm sure my teammates will get annoyed if I say it's easy, but the truth is that while the tool isn’t omnipotent, it's a lot easier than using data files like Excel. Postscript Even though it's free, there are still infrastructure costs to run it. We are using an AWS instance for TestLink, which costs several tens of thousands of yen per year. It has been almost three years since we started using it, and so far we have been able to operate it without any major issues. In this article, I explained how we implemented TestLink as a test management tool in the QA group. In future posts, I hope to discuss how TestLink is used in actual projects, its integration with JIRA, and more.

Introduction I am Kanaya, a member of the KINTO FACTORY project, a service that allows you to renovate and upgrade your car. In this article, I will introduce our efforts to improve Deploy Traceability to Multiple Environments Utilizing GitHub and JIRA. Last time, I also wrote an article related to Remote Mob Programming in the Payments Team. Background and Challenges I joined the KINTO FACTORY project from the latter half of the development process. I was assigned as the frontend team leader for the e-commerce site project, and during my time in charge, I noticed the following issues: GitHub Issues, JIRA, and Excel are used for task management, making progress difficult to manage Difficult to track which tasks are deployed in which environment Troublesome to generate release notes when deploying to a test environment  Excel WBS and Gantt chart example First, managing progress was difficult. At the time I joined the project, there were three types of task management tools: GitHub Issues, JIRA, and Excel WBS and Gantt charts, all of which were in use. This lack of centralized control of necessary information made it difficult to manage schedules and tasks. Second, it was difficult to track which tasks are deployed in which environment. During development, there were two target environments for deployment (a development environment and a test environment), making it challenging to know which environment the task under development had already been deployed to. Lastly, Troublesome to generate release notes when deploying to a test environment. Since the test environment was used for testing not only by us engineers, but also by the QA team responsible for quality assurance, we needed to communicate when and which content was deployed to it. We used to create release notes as a communication method, but writing them each time took about 5 minutes and was quite stressful. Our goal was to improve deployment traceability to address these issues. At least issue 2 and 3 (environment-specific deployment management issues, release note generation issues) are expected to be resolved. In addition, we aim to resolve issue 1 (difficulty in managing progress) by changing the way of work, as described later. Policy to Enhance Deployment Traceability First of all, traceability is described in DevOps technology: Version Control | DevOps Capabilities as follows. Among these, it is required that differences between multiple environments are either avoided or quickly identified once they occur. Note that version control of all dependencies can be managed in package.json, package-lock.json of npm for the frontend, so I'll skip that here. No matter which environment is chosen, it is essential to quickly and accurately determine the versions of all dependencies used to create the environment. Additionally, the two versions of the environment should be compared to understand the changes between them. As a policy to improve traceability to manage which tasks are deployed to which environments, we did the following: Manage all tasks and deployments with JIRA Rely on automatic generation of release notes Manage all tasks and deployments with JIRA JIRA has a feature to view development information for an issue . Since we know the status of code, reviews, builds, and deployments, we decided to consolidate all development information into JIRA. To integrate JIRA and GitHub, the following steps are required: Set up for JIRA and GitHub integration Include the JIRA ticket number in the branch name to connect the JIRA ticket with the GitHub pull request Set up the environment during deployment with GitHub Actions The second step was the part left to the work of each engineer. In asking each engineer to include the JIRA ticket number, we have decided to eliminate the use of GitHub Issues and Excel, and unify the use of JIRA. By unifying to JIRA, each engineer can manage tasks more easily, and those who manage progress can also use JIRA's roadmaps for centralized management. JIRA roadmap example For the third step, by passing environment parameter to deploy, the deployment status passed to environment will also be linked to JIRA. For reference, here is some of the deployment code by GitHub Actions we are using. In the environment parameter, $${ inputs.env }} is further passed, so that a key for each environment is created. Since $${ inputs.env } contains the environment name of the deployment destination, the deployment destination will be integrated with JIRA. DeployToECS: needs: [createTagName, ecr-image-check] if: ${{ needs.createTagName.outputs.TAG_NAME != '' && needs.ecr-image-check.outputs.output1 != '' }} runs-on: ubuntu-latest environment: ${{ inputs.env }}-factory-frontend steps: - Specific processing As a result, the development status is managed by JIRA roadmaps and tickets, and each ticket can be viewed to manage whether it is under review, merged but not deployed, and to what environment it has been deployed. Status listed on each JIRA ticket Visualizing the deployment status across all tickets, not just each ticket, is also possible. It is useful to see when each ticket was deployed and to which environment. Visualization of deployment status to each environment :::message GitHub also has a project function that can achieve this to some extent, but in light of the roadmap feature and integration with tools used by the QA team , we are unified with JIRA. ::: Rely on automatic generation of release notes For automatic generation of release notes, we decided to use GitHub's automatically generated release notes feature. The automatic generation of release notes is a feature that lists the titles and links of pull requests for the release note portion of GitHub's release feature . It can be better handled by setting a few rules. Here is an introduction. Define the category of release content The pull requests listed in the release notes are not categorized by default, making them difficult to view. Categorizing the pull requests helps keep release notes organized and easy to view. Categories are represented by labels. This time, I wanted to specifically display major changes and bug fixes as categories in the release notes, so I created 'enhancement' and 'bug' labels to represent each. You can also generate a list of pull request titles by category by creating a file .github/release.yml in the target repository and writing the following. changelog: categories: - title: Major Changes labels: - 'enhancement' - title: Bug Fixes labels: - 'bug' - title: Others labels: - '*' An image of the generated release notes is shown below. Pull requests labeled 'enhancement' and 'bug' are now classified as 'Major Changes' and 'Bug Fixes,' respectively All pull requests without 'enhancement' and 'bug' labels are classified as 'others.' Category sorting and title correction at the time of pull request review It is possible to generate release notes and then manually sort them, but once they are generated, it is difficult to remember and sort them. Therefore, at the time of the pull request review, we assign labels that correspond to the categories. We also check the titles to ensure they are appropriate for the content correction. To avoid forgetting to apply labels, others labels are given to refactoring, etc. This ensures that we know the review and category sorting are complete. Results Through the above efforts, we were able to successfully resolve the issues we were facing. In particular, the JIRA roadmaps have been referenced by other teams and are now used throughout the KINTO FACTORY project. Previously, GitHub Issues, JIRA, and Excel were used for task management, making progress difficult to manage. Now, centralized and managed in JIRA tickets and roadmaps. Previously, it was difficult to track which tasks are deployed in which environment. Now, deployment status of each environment is now visible in tickets. Previously, creating release notes when deploying to a test environment was troublesome. Now, work that used to take 2-3 minutes has drastically decreased to 10 seconds. Future Development By deploying to production environment, JIRA can measure two of the DevOps Four Keys in terms of speed. Our team will collaborate to identify the current status and target metrics for deployment frequency and change lead time for continuous improvement. Deployment frequency to production environment Lead time from merge to deploy to production environment The KINTO FACTORY project is looking for team members who will work together to achieve service growth. If you are interested in this article or KINTO FACTORY, check out the job listings below! [KINTO FACTORY Full Stack Engineer] KINTO FACTORY Development Project Team, Tokyo [KINTO FACTORY Backend Engineer] KINTO FACTORY Development Project Team, Tokyo [KINTO FACTORY Frontend Engineer] KINTO FACTORY Development Project Team, Tokyo

Introduction Hello, I am Keyuno and I am part of the KINTO FACTORY front end development team. As part of our KINTO FACTORY service, we are launching a dedicated magazine using Strapi , a headless content management system (CMS). *More details will be shared in an upcoming article, so please stay tuned! :::message What is Strapi? A Headless CMS with high front-end scalability Low implementation costs with default APIs for content retrieval As an open-source software (OSS), APIs can be added and expanded as needed. ::: In this article, I would like to explain how to add custom APIs to Strapi, which we implemented when introducing Strapi. This article covers the following two patterns of custom API implementation. :::message Custom API implementation patterns and use cases Implementing a new custom API We want to retrieve and return entries from multiple collectionType (content definitions) We want it to return the results of business logics that cannot be fully covered by the default API. Overriding the default API We aim to modify entry retrieval by replacing the auto-assigned postId with a custom UID. ::: Optimizing web page management is a constant challenge. I hope this article helps ease the burden for engineers, even if just a bit. Development Environment Details Strapi version : Strapi 4 node version : v20.11.0 Implementing a new custom API This section shows how to implement a new custom API. While this approach offers high flexibility because it can be implemented at the SQL level, overdoing it can make maintenance difficult, so use it wisely. 1. Create a router First, add the routes for the API endpoints you create. Under src/api , there is a directory for each collectionType. In the figure below, the routes directory is under post . Create a file under routes for defining custom-route. *According to the official documentation, there is a command npx strapi generat that prepares the necessary files (though I haven’t used it). In the created file, write the following code: export default { routes: [ { method: "GET", // Refers to the HTTP method. Please modify as needed to suit your purposes. path: "/posts/customapi/:value", // These are the endpoints for the APIs you will implement. handler: "post.customapi", // Specify the controller that this route refers to. } }; method Specify the HTTP method. Please modify as needed to suit the API you are creating. path Specify the endpoint for the custom API you are implementing. The sample endpoint, /:value indicates that the trailing value is received as the value variable. For example, if /posts/customapi/1 and /posts/customapi/2 are called, the value will store 1 and 2 respectively. handler Specify the controller (explained later) that the custom API you are implementing refers to. Specify the name of the function in the controller that you want to reference. 2. Implement the controller Implement the controller referenced by the routes implemented in step 1. Open the post.ts file located in the controllers directory , which is in the same level as the routes directory. In this file, add the handler ( customapi ) specified in the previous routes to the default controller (CoreController) as follows: Before change (initial state) import { factories } from '@strapi/strapi'; export default factories.createCoreController('api::post.post'); After change import { factories } from "@strapi/strapi"; export default factories.createCoreController("api::post.post", ({ strapi }) => ({ async customapi(ctx) { try { await this.validateQuery(ctx); const entity = await strapi.service("api::post.post").customapi(ctx); const sanitizedEntity = await this.sanitizeOutput(entity, ctx); return this.transformResponse(sanitizedEntity); } catch (err) { ctx.body = err; } }, })); What’s changed Added a custom handler customapi() to the default controller Retrieved the result of executing the customapi () service that contains the business logic customapi() , as referenced in line 8. :::message In this section, the business logic is moved to the service layer, but it is also possible to implement the business logic in the controller (choose the layer based on reusability and readability). ::: For details on validateQuery(), sanitizeOutput(), transformResponse() , please refer to Strapi’s official documentation . 3. Implement the service Implement the service referenced by the controller implemented in step 2. Open the post.ts in the services directory , which is at the same level as the controllers directory. Add the method (customapi) specified in the previous controller to the default service (CoreService) as shown below. Before change (initial state) import { factories } from '@strapi/strapi'; export default factories.createCoreService('api::post.post'); After change import { factories } from "@strapi/strapi"; export default factories.createCoreService("api::post.post", ({ strapi }) => ({ async customapi(ctx) { try { const queryParameter: { storeCode: string[]; userName: string } = ctx.query; const { parameterValue } = ctx.params; const sql = "/** Database to use, SQL according to purpose */"; const [allEntries] = await strapi.db.connection.raw(sql); return allEntries; } catch (err) { return err; } }, })); What’s changed Add the custom service customapi() to the default service Line 6: Retrieve the query parameter information Line 7: Obtain endpoint parameter information Line 10: Get the SQL execution results :::message You can use strapi.db.connection.raw(sql) to execute SQL directly , but strapi also provides other ways to obtain data. For other methods of obtaining data, please refer to the Official Documentation . ::: 4. Confirm operation With this, the implementation of the new custom API is complete. Please actually try calling the API and check that it works as expected. Overriding the default API In this section, I will show an example of how to override the default entry detail retrieval API to allow fetching with a custom parameter. [Entry detail retrieval API] [Before override] GET /{collectionType}/:postId(number) [After override] GET /{collectionType}/:contentId(string) 1. Create a router It is basically the same as when implementing a new custom API. Add the following code to the custom.ts under the routes directory: export default { routes: [ { method: "GET", path: "/posts/:contentId", handler: "post.findOne", } }; With this route addition, the endpoint that previously retrieved entry details using /posts/:postId(number) will now retrieve entry details using /posts/:contentId(string) (entry details can no longer be retrieved using /posts/:postId(number) ). 2. Implement the controller The implementation of the controller is basically the same as when implementing a new custom API. Modify the post.ts in the controllers directory, which is at the same level as the routes directory, as follows: Before change (initial state) import { factories } from '@strapi/strapi'; export default factories.createCoreController('api::post.post'); After change import { factories } from "@strapi/strapi"; import getPopulateQueryValue from "../../utils/getPopulateQueryValue"; export default factories.createCoreController("api::post.post", ({ strapi }) => ({ async findOne(ctx) { await this.validateQuery(ctx); const { contentId } = ctx.params; const { populate } = ctx.query; const entity = await strapi.query("api::post.post").findOne({ where: { contentID: contentId }, ...(populate && { populate: getPopulateQueryValue(populate), }), }); const sanitizedEntity = await this.sanitizeOutput(entity, ctx); return this.transformResponse(sanitizedEntity); }, })); What’s changed Added a custom findOne() controller to the default controller In line 12, it extracts records where the contentID column matches contentId . Since .findOne() is used in line 11, the result will be a single object. :::message Lines 13-15 follow the process for applying the populate parameter provided by the default API. If you want to fetch videos or images from mediaLibrary, you must add populate , so please be aware. ::: In this section, the business logic is implemented in the controller rather than the service. 3. Confirm operation With this, the implementation to override the default API is complete. Please actually try calling the API and check that it works as expected. Conclusion This concludes the explanation of implementing custom API in Strapi. I think Strapi is a highly customizable and great tool. Therefore, I hope to continue sharing my knowledge, and I would be happy if you could share your insights as well. We also have other topics, such as: Automatically building applications when publishing Strapi articles. Embedding videos (e.g., mp4) in CKEditor. I will cover these topics in future articles. Thank you for reading.

Overview Hello, we're Mori, Maya S, and Flo from the Operations Enhancement Team at the Global Development Group. The Global Development Group organized an in-house Hackathon-style event called the "KINTO Global Innovation Days" which took place over six days from December 14th to 21st. During the first four days from December 14th to 19th, three seminars were held, followed by two days dedicated to actual development. This was the first time that such an event was held within KINTO Technologies. This article is the first in a series of articles on the event, sharing the journey leading up to it. How it started KINTO Technologies currently consists of about 300 members and has roughly doubled in size in about two years. Among them, the Global Development Group is also currently a large group of 60 members. As an organization, we are subdivided into teams of 5 to 10 members, each performing their tasks but communication across teams has always been a challenge. Even within the Global Development Group, it's common for people to struggle with matching faces to names. In addition, although we had planned and organized internal study sessions to improve communication and skills, they inevitably turned out to be a one-way knowledge sharing. We were looking for an opportunity for engineers to learn through hands-on activities. In July, several of our group members participated in a Hackathon at Toyota Motor North America (TMNA) , which made us think that hosting such an event within our group could address the above issues. So, we decided to start planning and proposing this event at the end of August. Objectives and Timing While hackathon events have a variety of benefits in general, our primary objective this time was to stimulate cross-team communication. We believe that by not leaning too much on the business side, a certain degree of freedom in thinking was gained. We also set a goal of holding the event by the end of 2022 at the latest. The reason was that a major project involving the entire group was set to be completed by November, making it difficult to anticipate tasks beyond the fourth quarter. Research and Content Review Since this was our first time organizing an event, we first researched hackathon cases around the world to consider what an actual event should be like. Maya S was in charge of this research. As various role models were studied, mainly from other companies' tech blogs and hackathon event sites, a pattern began to become apparent. By picking up the elements of the pattern and combining them with aspects that fit our organization and goals, we were able to put together the contents for our Innovation Days. Many examples of findings could be presented, but I will explain three of them below. Finding 1: Benefits As we prepared for the event, we felt the need to communicate the benefits of participating to the participants, stakeholders, and everyone involved. For example, the benefits to the organization include opportunities for gaining ideas for intellectual property, increasing member engagement, and discovering new strengths. As for the benefits to individuals, we emphasized that they can learn in various aspects by coming up with ideas that cannot be tackled in their daily work and by interacting with work processes and members they would not usually encounter. Findings 2: Content ideas Based on the above benefits, the seminars were incorporated as content. We learned that hackathons typically include talks by guest speakers, lectures, and workshops aligned with the event's theme and goals. For Innovation Days, we prepared a workshop on upstream processes which is not usually experienced, a communication workshop, and a workshop on the Toyota Way, given that it was a "Hackathon held by KINTO Technologies." Many people would think of novelty items when it comes to events hosted by IT companies. This time, we distributed stickers, hoodies and clear files to the participants and support members. We also borrowed ideas from various events, like setting up criteria and rules for judging final pitches and deliverables, allocating time for coding, icebreakers, and prizes. Note: After the event name was decided, the UIUX team in the Global Group designed the logo. Thanks to them, we ended up with fantastic novelty items. Appreciate it a lot!!!! Findings 3: Theme setting The last point we want to address is theme setting. Noting that many hackathons have narrowly focused themes and objectives set by organizers, and some even have sponsors for various themes, in our event, the managers decided a "Challenge Theme" and took on the role of "Challenge Owner" to sponsor and explain each theme to the participants. This approach allowed the manager to provide support and encouragement to the participants. Reference: Council Post: Four Tips For Running A Successful Hackathon Urban Mobility Hackathon Find & Organize Hackathons Worldwide - Mobile, Web & IoT Hackathon Guide Theme Review For the content of the themes, four managers (the Group Manager and three Assistant Managers) who will actually evaluate on the day of the event selected four themes. Theme 1-2 Theme 3-4 Encouraging members Since this was the first attempt within the company, it took about three months from the time from the start of planning to recruiting members, through research, content review, and theme selection. At the beginning of November, after finalizing the theme, we held a project briefing for all Global Development Group members, and began recruiting on November 8th. The official event name, "KINTO Global Innovation Days," was decided. There was a proposal to make participation mandatory for all participants, but we chose to respect autonomy and allowed volunteers to opt-in instead. Slack was used for recruiting. 🔻🔻 At the briefing, we received words of encouragement from our managers and told our participants that we had the support from our CEO and CIO. However, recruiting participants was initially challenging, so we focused on highlighting the benefits directly to the team members Flo was responsible for this. We decided to communicate the benefits when talking in person in the office and through DMs. This allows us to ask members who are unable to participate why and make improvements. First, we explained the experience and skills they would gain by participating in the event. We emphasized the opportunities to try programming languages they don't normally use, propose new tools, and suggest improvements that haven't been prioritized. We also appealed to a sense of ownership and investment, as proposals made during the event could be used to improve processes in Global Group (Theme 3), be commercialized as a new service (Theme 1, 2), or be considered for participation in other hackathon events. Among all, our top priority was creating a supportive environment. Although ideas are evaluated and rewarded, the competition is friendly. We also encouraged people who had never participated in such an event, felt they couldn't contribute because they weren't engineers, or thought they'd be of no use to participate because it's an event where they could experience things they normally would not. There are also things that we noticed in conversations. Since the event was held before Christmas, several people were planning to take consecutive holidays or return to their home countries. For this reason, we decided to move the event up a few days. We adjusted the schedule with the instructors of each workshop, and finally set the pre-event for December 14th to 19th, with Innovation Days on December 20th and 21st. This added at least two to three more team members who could participate. As a side note, since there were only three operating members plus one support member, it was convenient for us to have a weekend in the middle of the event. Hosting the event all week long would have been physically demanding. Grouping and Pre-work Thanks to the recruiting efforts, we gathered 30 participants. More than half of the Global Development Group participated, as the group manager, assistant managers, and we operational members were not eligible to participate. Participants came from various teams such as Business Development, PdM (Product Management), UIUX, Frontend, Backend, Testing, and DevOps. We allocated each team leader based on two conditions: 1) involving people who are not usually involved in the work, and 2) ensuring team leaders were separated to maintain a balance of power. We ended up with 5 people in each of the 6 teams. (The members were perfectly divided because we had a total of 30 participants😊) The team members were announced on November 18th, and were then given two weeks to review and submit the following information: Team name Theme of choice Team leader As we are the team that is the most used to interacting cross-functionally in the group, we had concerns about whether the participants would be able to communicate well with each other, or engage actively in the event. However, our worries were unnecessary. As they were participating voluntarily, each team was more proactive than expected, creating their own Slack channels and holding meetings, which gave us hope for future events! 🎉 Review of Preparation Since we started this project with completely no experience, either within the company or from previous jobs, we had to conduct extensive research and seek advice from various people during the preparation. In particular, the approval process took a long time, but involving the CIO and the president was one of our achievements, and a major factor that we believe will lead to future events. In addition, we were able to successfully distribute tasks by combining the strengths of each Operations Enhancement Team member, such as idea generation (including research), planning and reporting, and understanding the situation and inspiring team members, which enabled us to implement the project in a short period of about four months from conception. There were various challenges during the pre-event period and on the day of the event, which will be described in the next article. Conclusion By the way, the planning of KUDOS and this event emerged from our daily conversations within the Operations Enhancement Team. We place a high value on conversations and take pride in our ability to go from casual conversation— like suggesting solutions and sharing experiences —to planning, execution, and results.

Introduction Hello. I am Nakaguchi from KINTO Technologies, Mobile App Development Group. As a team leader of the iOS team, I have previously published articles on team building, which you may find interesting. Please feel free to check them out: Revitalizing Retrospectives Through Professional Facilitators 180-degree feedback: Highly recommended! Recently, I participated in [Probably the world’s fastest event: the "Agile Teams goal-setting Guidebook" ABD Reading Session] My three main objectives for attending this event were as follows: I wanted to experience Active Book Dialogue® (referred to as "ABD" from now on). I was interested in the book featured in the event, "Agile Teams goal-setting Guidebook" . I wanted to meet the author, Ikuo Odanaka. Among these, experiencing ABD for the first time was particularly valuable. I found this reading method incredibly insightful and would like to introduce ABD to more people through this article. Important Notice All individuals and materials mentioned in this article have been approved to be published by the event’s organizers and the respective individuals. About the event This event took place on Wednesday, July 10, 2024, and was held as an "ABD reading session with the author before the publication" of the "Agile Teams goal-setting Guidebook". The event was so popular that the 15 available slots were filled within the same day the registration page was open. I feel incredibly fortunate to have been able to participate. I’m especially grateful to Kin-chan from our Corporate IT Group, who introduced me to this event! About the book I won’t go into too much detail about the book’s content, as I encourage you to read it yourself. However, I’d like to share some insights Ikuo-san introduced during the opening. It seems that goal setting isn’t particularly favored in today’s society. However, if everyone sincerely engages with their goals and strives to achieve them, the world will become a better place. Therefore, creating good goals is extremely important. That said, while setting goals is crucial, finding ways to achieve them is even more important. This book dedicates roughly the first 20% to the process of goal setting, with the remainder focused on how to achieve those goals, incorporating elements of Agile methodology. Although the book doesn’t cover performance evaluations, which are often discussed alongside goal settings, it does include columns written by eight contributors. These columns nicely complement the content, so I highly recommend reading them! Ikuo-san's opening scene About Ikuo-san Although I have never met Ikuo-san before, I was familiar with him through the following LT sessions and articles: ”Keeper of the seven keys four keys and three more ” ”10 reasons Why it’s easy to work with an engineering manager like this!” ”To fulfill the pride of being a "manager." “5 essential books that supported the Ideal EM, Ikuo Odanaka” I found his insights on development productivity, engineering management, and his approach to reading, to be incredibly valuable. I’ve always wanted to meet him and have a conversation. Unfortunately, although I manage to exchange a brief greeting with him during the event, I didn’t have the chance to have a proper conversation. While this was disappointing, I hope there will be another opportunity in the future. About ABD The following is a quote from the official ABD website . What is ABD? Explanation by the developer, Sotaro Takenouchi: ABD is an entirely new reading method that allows both people who are not fond of reading and those who love books to read the books they want in a short period of time. Through the process of dividing the book, summarizing it, presenting and sharing the summaries, and engaging in discussions, participants can deeply understand what the author is trying to convey, leading to active insights and learning. Additionally, by combining the active reading experience of each participants through group reading and discussion, the learning deepens further, and there is potential for new relationships to be fostered. I sincerely hope that through ABD, everyone can take better steps in their reading, driven by their intrinsic motivation. The process Co-summarize Participants bring their own books or divide one book into sections. Each person reads their assigned section and creates a summary. Relay presentation Each participants presents their summary in a relay format. Dialogue Participants pose questions, discuss their impressions and thoughts, deepening their understanding. The appeal of ABD Short reading time ABD allows you to read a book in a short amount of time while gaining a deep understanding of the author's intensions and content. It’s perfect for those who tend to accumulate unread books. Summaries remain After an Active Book Dialogue® session, the summaries remain, making it easy to review and share the key points with others who haven’t read the book. High retention rate Since participants are mindful of presenting when they input and summarize information, followed by immediate output and discussion, the content sticks in memory more effectively. Deep insights and emergence Engaging in dialogue with diverse people, each bringing their own questions and impressions, leads to profound learning and the emergence of new ideas. Multifaceted personal growth ABD helps participants develop focus, summarization, presentation, communication, and dialogue skills, which are all crucial for leadership in today’s world. Creation of a common language When the same team members participate, they share the same level of knowledge, creating a common language. Community building With just one book, you can create a space for dialogue and connect with others, making it ideal for casual community building. Most importantly, it’s fun! The immediate sharing of the excitement and learning gained from reading enriches the experience and, most importantly, makes it enjoyable. Personally, I find the value in 1. Short reading time, 6. Creation of a common language, 7. Community building, and 8. Most importantly, it’s fun! to be exceptionally high. On the day The book was divided into 15 sections. This was the first time I had seen such a sight! lol The book was divided into sections Co-summarize (20 minutes) Each participants read their part and create a summary. We were given 20 minutes to read and summarize the book onto three A4 sheets, which was quite challenging. I was so pressed for time that I forgot to take any pictures. Relay Presentation (1 minute 30 seconds per person x 15 people) Each participant posted their summaries on the wall. The Summaries everyone prepared Then, each person presented their summary in 1 minute and 30 seconds. Everyone’s summaries and presentations were outstanding. This is the photo of me presenting. I was so nervous, and the time was so short that I can’t remember what I said at all! My presentation Dialogue (25 minutes) In this part, we picked three sections from the presentations, and divided into groups to discuss them further. I joined the group focused on "Becoming a team that can help each other." Group discussion Within the group were Scrum Masters and Engineering Managers, and we exchanged various opinions. One particularly memorable discussion was about how we should build teams where people can challenge themselves with what they love, whether it’s their forte (specialty) or something they struggle with (growth opportunity). What I learned from the book through ABD Up until now, I had never used "OKR" (Objectives and Key Results) as a method for goal management, but my understanding of OKR has deepened through this experience. I also learned how crucial it is for a team to set goals driven by intrinsic motivation when creating goals. What stood out to me was the importance of setting goals through discussions within the team, rather than using a top-down approach. Additionally, I was struck by the idea that what truly matters is the “achievement of goals,” not just the “completion of tasks.” The notion that “sometimes, you need the courage to abandon lower priority tasks” was a new perspective for me. Moreover, the breakdown of reasons why we might feel like we don’t have enough time to achieve our goals, such as genuinely not having enough time, being unsure if the time investment is worthwhile, or lacking the motivation, was something I had never considered before. While the idea of “genuinely not having enough time” is easy to grasp, the concepts of “not being sure if it’s worth the time" and "lacking motivation" were new to me, though they resonated with my own experience. The book also offered solutions to these challenges, so I would like to read the book and review it. Thoughts It was my first time experiencing ABD, and I found it both stimulating and very enjoyable. Since all the participants on the day were genuinely interested in book we discussed, the presentations and dialogues were highly constructive, and I learned a lot. I’m considering trying ABD at our company as well, by gathering team members who are interested. However, I also felt that the operational difficulty could be quite high for the following reasons: Facilitators need strong skills because the session must proceed within a limited time. Co-summarizing is challenging, which might lead to differences in the quality of summaries and presentations depending on the participants. Selecting the right book and gathering team members could be difficult. I’ve participated in book study groups several times before, but I found that they often pose challenges like the burden of continuity over a long period and the individual workload (depending on the format of the book study group). In contrast, ABD offers a great alternative by wrapping up the session in a short time, which helps to overcome those drawbacks. However, the trade-off might be a lower understanding of the book due to the shorter session time. I think it’s important to carefully select the book and have prior discussions with participants to determine the most suitable reading method.

はじめに こんにちは、6月入社のahomuでございます。 本記事では2024年6月と7月入社に入社された皆さまに入社後の感想などをテキストで回答いただきました。 KINTOテクノロジーズに興味をもってくださった皆さま、そして、今回参加くださった各位がいつか見返したとき有益なコンテンツになればと存じます！ hosoya  自己紹介 hosoyaです。所属はIT/IS部です。社内情シスのヘルプデスク窓口対応をしています。 所属チームの体制は？ チームは私も含めて5人です。私の所属チームの他に役割別に複数のチームがあり、問い合わせ内容によって他チームと連携を取って業務を行っています。 KTCへ入社したときの第一印象？ギャップはあった？ 情シス内で役割毎にチームが別れ、しっかり連携が取れているところが印象的でした。1人か2人だけの情シスばかりにいたので、すごくしっかりしているなと感じました。 現場の雰囲気はどんな感じ？ 静かで自分の業務に集中できる環境です。しかし周りに話しかけづらいという事はなく、業務の事でも雑談でも話しかけるとすぐに盛り上がるので、明るい雰囲気です。 ブログを書くことになってどう思った？ 業務で関わりがないとなかなか他の方が普段どのような事をされているのか知る機会がないかと思いますので、このブログがそういった機会になればと思います。 他の方からの質問：1日の業務スケジュールを教えてください 回答：朝9:00に出社して夕方18:00の退社までヘルプデスクの問合せ対応をしている感じです。朝と夕方にチームの情報共有の打合せを行なっています。問合せの内容にもよりますが毎日定型の業務を行っている感じです。 my  自己紹介 データ分析部に所属しているmyです。現在、データサイエンティストとして活動しています。これまで、データサイエンティストや機械学習エンジニアとして、データに関わるさまざまな業務に携わってきました。 所属チームの体制は？ マネージャーを含めて4名で構成されています。 KTCへ入社したときの第一印象？ギャップはあった？ 良いギャップとして、オンボーディングが整っており、社内ドキュメントがしっかりしている点や、Slack上の活発なコミュニケーションが印象的でした。 現場の雰囲気はどんな感じ？ 穏やかな雰囲気の中で、技術に関するディスカッションがしやすい環境です。 ブログを書くことになってどう思った？ 情報を発信する機会をいただき、嬉しいです。 他の方からの質問：在宅勤務をする中で買ったら凄く良かったという物を教えてください！ 回答：ハーマンミラーの椅子です。長時間でも快適に座ることができ、とても満足しています。 yi  自己紹介 プラットフォーム開発部QAGに所属しているyiです。QAをやっております。 所属チームの体制は？ チームは10人で、現在は大きくフロントエンド、バックオフィス、アプリの3つのグループに分かれてそれぞれのプロジェクトに対応しています。 KTCへ入社したときの第一印象？ギャップはあった？ 新しい会社だけれど、社内の仕組みはちゃんとしているという印象を受けました。入社前は、色々なことがもうちょっとカオスな状態なのかもと考えていましたが、思ったより落ち着いた感じでした。 現場の雰囲気はどんな感じ？ 各々がお忙しい状況でも、チームやプロジェクトの方には質問すれば答えていただけますし、全体的に穏やかな雰囲気なので馴染みやすい環境だと思います。 ブログを書くことになってどう思った？ こういったブログを書いた経験がないので、何を書いたらいいのか戸惑ったというのが正直なところです。 他の方からの質問：チームの雰囲気はどうでしょうか？ 最近感じたチームの良い点があれば教えてください 回答：先ほども書きましたが全体的には穏やかな雰囲気で、KTCのQAとしては各々担当するプロジェクトのテストをパートナーさんと進めている感じです。複数プロジェクトを担当している方も多く、それぞれお忙しいですが、新人に限らず、お互い質問しあったりする雰囲気があるのは良いと思います。 ahomu  自己紹介 ahomuです。IT/IS部に所属しています。職務経歴としてはWebフロントエンドの開発経験が長めですが、現在は組織横軸のいろいろをやっています。 所属チームの体制は？ じつは、詳細は入社してから考えようという話で入社しており、本稿を書いている時点で部付のソロ活動（社内フリーランス）です (｡•̀ᴗ-)✧ KTCへ入社したときの第一印象？ギャップはあった？ カジュアル面談や選考プロセスのなかで、現所属の部長や副社長が事業が置かれている状況や、組織の雰囲気について明け透けに話してくださっていたのでギャップらしいものは感じていません。強いて言うなら、大企業の傘下にあることからこれまでの経験（メガベンチャーやスタートアップ）と比べて社内統制が良い意味でカッチリしていて新鮮です。 現場の雰囲気はどんな感じ？ ソロ活動とは言いつつ、さまざまな部署のマネージャーやメンバーの方とお話をさせていただく機会があります。各々の立場で事業を担っていらっしゃる責任を感じると同時に、突然話しかけてきた新参者にも快くお話いただけるので助かっています。 ブログを書くことになってどう思った？ あ、そういえばこれは本当に意外でしたが、テックブログの寄稿が社内的にすごく活発で、特に誰彼が追い立てたりしなくてもコンスタントに情報発信できていて伸び代を感じます。 他の方からの質問：名古屋と東京の会社で違うと思う文化、雰囲気等あったら教えてください。 回答：名古屋は人数が20人程度とコンパクトなのと、それぞれで幅広に活躍している方が多く個性的？な気がします。KINTO事業とも距離感が割と近く、親会社とのやり取りをする人も多いかもしれません。最近は名古屋オフィス内の飲み会が不定期開催されるようになりました🍻 つづら  自己紹介 マーケティング企画部/編成グループ所属のデザイナーです！ 所属チームの体制は？ ディレクター9名、デザイナー4名体制です。 KTCへ入社したときの第一印象？ギャップはあった？ 部署やチームが細分化されているので、社員同士の交流はあまりないのかな？っていうのが第一印象でしたが、実際には他の部署のデザイナーさんともランチやプライベートの飲み会に行ったりして交流を持てていて情報共有などできてとても助かってます。 現場の雰囲気はどんな感じ？ うちのチームでいうと、それぞれのプロジェクト毎に動いてるので全員とかかわりが濃いわけではないですが社内で会ったときは雑談したりでも仕事はしっかりしてメリハリがついてる印象です。 ブログを書くことになってどう思った？ どきどきわくわく。 他の方からの質問：所属オフィス近くのおいしいランチを教えてください！ 回答：室町オフィス所属なんですが、「 でですけ サイゴンキッチン 」さんがおすすめ！私はいつもハーフ & ハーフで、フォーとカレーを注文するんですがそれぞれ4種ずつくらい味のバリエーションがありどれも美味しいのでおすすめです。 上原 直希  自己紹介 上原と申します。プロジェクト推進部 KINTO FACTORY開発グループ所属です。バックエンドエンジニアとして働いています。前職では老舗ISPにてニュースメディアの開発をやっていました。好きなプログラミング言語はRust、好きなエディタはNeoVimです。 所属チームの体制は？ バックエンドエンジニアでいくと6名で開発を行なっています。他にフロントエンジニアも含めると20人くらいになります。 KTCへ入社したときの第一印象？ギャップはあった？ あまりオンボーディングも用意されず、いきなり現場に投入されるのかなと思いきや、意外とオンボーディングや1on1などが充実しており、おかげさまでスムーズに業務に入ることができました。社内のあらゆるところに新しいことに取り組もうという雰囲気があって、自分も良い刺激を受けています。 現場の雰囲気はどんな感じ？ 和気藹々とした雰囲気かなと思います。自分はわからない部分があるとすぐ気になってしまうタイプなのですが、メンバの方には質問に対し嫌な顔せず答えていただけるので大変ありがたいです。これまでより開発に集中する時間が増え、エンジニアとしてプロダクトに向き合えるのは良い環境だなと思います。 ブログを書くことになってどう思った？ 実は入社前にKINTOテクノロジーズのTech Blogの ある記事 に助けられた経験があり、今度は自分が記事を書く側になり大変光栄です。個人的にSlackやブログ等で見える形でアウトプットをしようという意識をしており、これからTech Blogで役立つ情報をどんどん発信できればと思っています。 他の方からの質問：行って一番よかったと思う旅行先を教えてください！よければ理由も一緒に～！ 回答：新婚旅行で行った伊勢志摩ですかねー！名鉄が販売している切符「まわりゃんせ」が便利すぎて最高です。東京に住んでると手に入れにくいのですが、じゃらんで特急券なしのまわりゃんせを買うのがおすすめです。 梁 晉榮  自己紹介 台湾出身の梁晉榮です。所属はモバイル開発グループ、主にAndroidアプリの開発をやっています。 所属チームの体制は？ 担当するプロダクトの開発チームでは、私を含めてAndroidエンジニアが6名います。 KTCへ入社したときの第一印象？ギャップはあった？ 所属チームが活気を溢れていて、Androidエンジニアも多数在籍しており、勉強会などを通じて技術面の交流を幅広くやったことが、自分に対してとても良い刺激になりました。 現場の雰囲気はどんな感じ？ 開発時期によっては忙しくなることが多く、結構スピード感のある開発チームだと感じました。それでも良いプロダクトを作りたいっていう気持ちがチーム全員にあるので、細かなコミュニケーションを惜しまずやっています。 ブログを書くことになってどう思った？ 入社エントリーを書くのが初めてで、入社ばかりの時の気持ちを振り返って、これからKTCでどうやっていくのかを考えることができました。 他の方からの質問：最近気になっているスマホアプリあったりしますか？ 回答：PayPayアプリですね。サービスの開始から何年も使っていきましたが、新しい機能が追加されている中で、どうやってアプリの品質を維持しながら開発していくのか、スーパーアプリとしての仕組みに凄く興味があります。 Dara Lim  Toyota FJ25 Land Cruiser - Toyota Dealership in Bogota, Colombia 自己紹介 My name is Dara Lim. I belong to the KINTO Global Development Group in the Business Development Department. My title is Business Development Manager, but the work I do relates closely to working as a business analyst. In my previous job, I worked as a financial analyst and business analyst in the insurance industry. 所属チームの体制は？ There are 3 members on my team and we work closely with the engineering team to develop software solutions for the global full service lease businesses. KTCへ入社したときの第一印象？ギャップはあった？ I really appreciate the orientation/onboarding process and the 1-on-1 meetings. They helped me to smoothly transition into work. My team was also very supportive. 現場の雰囲気はどんな感じ？ I really enjoy the Jimbocho office space and its surroundings. My team sits close to each other so we are able to have discussions readily. ブログを書くことになってどう思った？ Actually, before I joined the company, I was helped by many articles on KINTO Technologies' Tech Blog, so I’m glad to write my initial experience on joining the company. 他の方からの質問：What is the best thing you have noticed since joining KTC? 回答：I have had the experience of traveling to Latin America to visit KINTO businesses in Peru, Brazil, and Colombia. These were very valuable experiences for me to understand the car leasing business, its profitability and best of all, to meet others fellow KINTO members. I think this is the best thing I’ve experienced since joining KTC. 谷 郁弥  自己紹介 KINTO ONE開発部 新車サブスク開発G、Osaka Tech Lab所属の谷です。フロントエンドエンジニアをやっています。制作系からサービス開発系まで幅広くフロントエンド開発をこなしてきました。 所属チームの体制は？ チームは4人体制です。販売店や社内向けのツール群を少人数で開発しています。 KTCへ入社したときの第一印象？ギャップはあった？ 入社前は、大企業とスタートアップの雰囲気が混ざったカオスな環境で、まだまだ業務環境の整備が行き届いていないだろうと勝手に想像していたのですが、蓋を開けてみると、オンボーディングが濃密で、業務量も調整しやすく、フルフレックスで柔軟に働け、残業代もきちんと反映され、福利厚生が手厚く、優しく親切な方が多い、といった感じで良いギャップだらけでした。 現場の雰囲気はどんな感じ？ 分からないことは積極的に質問ができる心理的安全性が高い環境だと思います。勉強会への参加が推奨されているのも魅力的で、併せて、自分のチームの場合、技術選定の自由度が高く、リアーキテクトやリファクタも推奨されている為、総じてスキルアップしやすい環境だと感じています。 ブログを書くことになってどう思った？ KINTOテクノロジーズのことが少しでも解像度高く伝わればと思い、目一杯キーボードを叩こうと思いました。 他の方からの質問：あなたが持っているお気に入りのものは何ですか？またその理由は何ですか？ 回答：SONYのノイズキャンセリングヘッドホン（WH-1000XM5）です！これのおかげで、音に対して敏感な体質の自分でも、すぐにゾーンに入ることが出来る為、非常に重宝しています。 さいごに みなさま、入社後の感想を教えてくださり、ありがとうございました！ KINTO テクノロジーズでは日々、新たなメンバーが増えています！ 今後もいろんな部署のいろんな方々の入社エントリが登場するのでお楽しみに〜。 KINTO テクノロジーズでは、さまざまな部署・職種で一緒に働ける仲間を募集しています！ 詳しくは 採用情報 をご覧ください https://www.kinto-technologies.com/recruit/

はじめに こんにちは、4月入社のウエヤマです。 本記事では2024年４月に入社された皆さまの入社後の感想などをまとめました。 KINTOテクノロジーズに興味をもってくださった皆さま、そして、今回参加くださった各位がいつか見返したとき有益なコンテンツになればと存じます🌸 マツノ  自己紹介 皆さんはじめまして！2024年4月入社のマツノです！ 所属はプラットフォーム開発部プラットフォームGのMSPチームになります。前職ではAWS上に構築されたシステムの保守・運用を担当していました。 所属チームの体制は？ 自分が所属しているMSPチームは4人体制です。他チームより引き継いだ定型業務をメインに担当しています。 KTCへ入社したときの第一印象？ギャップはあった？ 同期の方含めて、優秀そうな方が多いなぁという印象を受けました。あとはフランクな方が多いのは良い意味でギャップがありましたね。 現場の雰囲気はどんな感じ？ 基本的に質問や相談はいつでもしやすい雰囲気です。あとは作業をする時は黙々と作業に集中して、雑談する時は和気あいあいといったメリハリのある感じですね。 ブログを書くことになってどう思った？ 元々テックブログのことは知っていて、興味もあったのでちょうどいい機会だなと思いました！ m  自己紹介 クリエイティブ室所属のmです。前職ではSESのIT企業でUI/UXデザイナーをしていました。 所属チームの体制は？ ディレクター・デザイナーの10名体制です。 KTCへ入社したときの第一印象？ギャップはあった？ オフィスがとても綺麗で、無料のドリンクサーバーもあり快適だと思いました。 現場の雰囲気はどんな感じ？ 年齢層は30代〜40代が多く、知識と経験が豊富な方々ばかりです。 オフィスは割と賑やかなことが多いです。 ブログを書くことになってどう思った？ 自分の考えや知識を発信できる場があるのはいいことだなと思います！ ラセル  自己紹介 バングラデシュから来た2024年4月入社のラセルです。プラットフォーム開発部モバイルアプリ開発GのPrismチームのiOS担当してます。 所属チームの体制は？ チームは、エンジニア、デザイナー、POを含めて約14名です。 KTCへ入社したときの第一印象？ギャップはあった？ モビリティサービスに興味があります。KTCの、トヨタのモビリティサービスをリードするという使命には大変感銘を受けました。ギャップを感じた点はとくにございません。 現場の雰囲気はどんな感じ？ 人々は親切で助けてくれます。最新の技術を使うことに障壁はありません。技術的な問題についても話しやすいです。 ブログを書くことになってどう思った？ このコンテキストでブログを書くのは初めてですが、これは本当にクールで楽しいアイデアだと思います。 ウエヤマ  自己紹介 業務システムGのウエヤマです。前職ではSIerでシステム開発をしていました。 所属チームの体制は？ エンジニア７名です。 KTCへ入社したときの第一印象？ギャップはあった？ 面談、面接時に同じチームメンバーの方と話ができていたので、ギャップはあまり感じてません。 現場の雰囲気はどんな感じ？ 皆さんホント優しくて話かけやすい環境です。 ブログを書くことになってどう思った？ 自己紹介記事をGitHub管理してプルリクを出す形式が驚きでした。 R  自己紹介 プラットフォーム開発部共通サービス開発Gの会員PFに所属のRです。フロントエンド6対バックエンド4くらいで開発をしております。 所属チームの体制は？ PdM1名とエンジニア4名です。 KTCへ入社したときの第一印象？ギャップはあった？ 複数のプロジェクトや会社内外のイベント等をいくつも掛け持ちしておられる優秀な方々を間近で見て、とても自由だなという印象を受けました。 入社前にKTC主催の勉強会に参加し、若手中心ではありますがKTCの雰囲気を一部事前に知っていたこともあり、ギャップを感じた点はとくにございません。 現場の雰囲気はどんな感じ？ バックエンドは黙々と、フロントエンドは実装中の画面について意見・感想等を話して盛り上がることも時々あります。 ブログを書くことになってどう思った？ 読む分には何も身構えることはありませんでしたが、いざ自分が書くとなると何を伝えるべきか分からず困ってしまいました。言語化能力や発信力を鍛えないといけませんね。 kasai  自己紹介 プラットフォーム開発部プラットフォームグループSREチームのkasaiです。前職でもSREやってました。 所属チームの体制は？ グループとしてはたくさんいますが、SREチームは2人体制です！チームについては後日ブログが公開されるのでそちらをお楽しみに！ KTCへ入社したときの第一印象？ギャップはあった？ 面接や面談等からしっかりとお話しさせていただき、認識合わせを行っていたため、ギャップは感じませんでした！ 現場の雰囲気はどんな感じ？ 和気藹々としています！！！！！ ブログを書くことになってどう思った？ ついに・・・この時が・・・来たっ！！！！！！ https://blog.kinto-technologies.com/posts/2022-12-03-ktc_club_introduction/ さいごに みなさま、入社後の感想を教えてくださり、ありがとうございました！ KINTO テクノロジーズでは日々、新たなメンバーが増えています！ 今後もいろんな部署のいろんな方々の入社エントリが登場するのでお楽しみに🍻 KINTO テクノロジーズでは、さまざまな部署・職種で一緒に働ける仲間を募集しています！ 詳しくは 採用情報 をご覧ください https://www.kinto-technologies.com/recruit/

はじめに こんにちは。モバイル開発のヒロヤ (@___TRAsh) です。 弊社ではいくつもの内製開発プロダクトがありますが、多くのプロダクトでXcode Cloudを採用しています。 Xcode CloudはAppleが公式に提供しているCI/CDサービスで、iOSアプリのビルドやCD(TestFlightへのデプロイ)を自動化できます。 今回は、Xcode Cloudでプライベートリポジトリをライブラリとして取り込む方法についてあまり参考資料が無く、ビルドを通すのに苦労したので、調査した結果をこちらにまとめておきます。 対象 今回の内容はiOS環境のCI/CDの話になるので、ある程度iOS開発の知識がある方を対象としています。 環境 - Xcode 15.4 - SwiftPMでライブラリを管理してる - 参照しているライブラリにプライベートリポジトリがある - GitHub Actions + FastlaneでTestFlightへデプロイしてる やりたいこと TestFlightのデプロイをGitHub Actions + FastlaneからXcode Cloudに移行したいと考えています。 これをすることで、Fastlaneへの依存をなくすことができ、App申請までのフローに必要なツールを減らすことができます。 また、申請に必要な証明書の管理もXcode Cloud上で直接Apple Developerの証明書を参照してくれるので、証明書の管理も楽になります。 悩み ここまで利点しかないXcode Cloudですが、ライブラリとしてプライベートリポジトリを参照する際には、ユーザー認証が必要になります。Xcode Cloudではそういった認証設定が考慮されていないため、プライベートリポジトリをライブラリとして参照するには一工夫する必要があります。 そこでXcode Cloudから提供されている ci_scripts/ci_post_clone.sh を活用して認証の設定することで、プライベートリポジトリを参照できるようになります。 .netrcの設定 Xcodeには12.5の頃から .netrc を参照する機能が追加されています。 .netrc はユーザー名とパスワードを記述したファイルで、 ~/.netrc に配置することで、 git clone 時に認証情報を自動で入力してくれます。 また、今回はライブラリをプライベートリポジトリのGitHub Releaseで管理する方法をとっているので、 api.github.com も追加しています。 touch ~/.netrc echo "machine github.com login $GITHUB_USER password $GITHUB_ACCESS_TOKEN" >> ~/.netrc echo "machine api.github.com login $GITHUB_USER password $GITHUB_ACCESS_TOKEN" >> ~/.netrc ユーザー名とアクセストークンをXcode Cloudの環境変数にSecretで設定しておき、 ci_post_clone.sh で参照するようにしています。 追加のリポジトリにURL追加 App Store Connect内のXcode Cloud の設定にある 追加のリポジトリ にライブラリのリポジトリURLを追加します。 defaults delete で設定を削除する 上記の設定でプライベートリポジトリのライブラリを取得できる様になってもまだライブラリの依存関係を解決できず、以下の様なエラーに遭遇しました。 :::message alert Could not resolve package dependencies: a resolved file is required when automatic dependency resolution is disabled and should be placed at XX/XX/Package.resolved. Running resolver because the following dependencies were added: 'XXXX' ( https://github.com/~~/~~.git ) fatalError ::: このエラーはXcode Cloud上でSwiftPMが、Package.resolvedを参照せず、自動でパッケージのバージョンを解決しようとしていることが原因です。 それぞれ、Xcodeのdefaultsを削除するとうまくビルドが通る様になります。 defaults delete com.apple.dt.Xcode IDEPackageOnlyUseVersionsFromResolvedFile defaults delete com.apple.dt.Xcode IDEDisableAutomaticPackageResolution この２つの設定なんですが実は違いが明確にわからなかったです... ローカルで xcodebuild のhelpコマンドを叩いて見てみると、似た様な設定があるのでそちらを参考にしても $ xcodebuild -help ... -disableAutomaticPackageResolution prevents packages from automatically being resolved to versions other than those recorded in the `Package.resolved` file -onlyUsePackageVersionsFromResolvedFile prevents packages from automatically being resolved to versions other than those recorded in the `Package.resolved` file Package.resolvedファイルに記録されているバージョン以外に、パッケージが自動的に解決されるのを防ぎます。 となっているので全く同じ内容しか書かれてないんですよね... 一応SwiftPMのIssueでも同じ様な内容の質問があって、この対応で解決しているので、現状はこれで問題ないと思います。 https://github.com/swiftlang/swift-package-manager/issues/6914 ひとまず、この２つの設定を削除することで、SwiftPMが参照するライブラリの依存関係をPackage.resolvedのみ参照し、依存関係を解決してくれる様になります。 結論 Xcode Cloudで起動前に参照される ci_scripts/ci_post_clone.sh に .netrc を設定することで、プライベートリポジトリを参照できるようになり、ライブラリの依存関係を解決するために、 defaults delete を設定することで、Xcode Cloud上でのビルドが通るようになりました。 #!/bin/sh defaults delete com.apple.dt.Xcode IDEPackageOnlyUseVersionsFromResolvedFile defaults delete com.apple.dt.Xcode IDEDisableAutomaticPackageResolution touch ~/.netrc echo "machine github.com login $GITHUB_USER password $GITHUB_ACCESS_TOKEN" >> ~/.netrc echo "machine api.github.com login $GITHUB_USER password $GITHUB_ACCESS_TOKEN" >> ~/.netrc 最後に Fastlaneは古くからある偉大なツールですが、Xcode Cloudの利用により、App申請までのフローをシンプルにできました。 先にも述べましたが、Xcode Cloudを使うことによるメリットは多いので、ぜひ導入を検討してみてください。 Appendix https://developer.apple.com/documentation/xcode/writing-custom-build-scripts https://speakerdeck.com/ryunen344/swiftpm-with-kmmwoprivatenagithub-releasedeyun-yong-suru https://qiita.com/tichise/items/87ff3f7c02d33d8c7370 https://github.com/swiftlang/swift-package-manager/issues/6914

はじめに こんにちは。モバイル開発のヒロヤ (@___TRAsh) です。 弊社ではいくつもの内製開発プロダクトがありますが、多くのプロダクトでXcode Cloudを採用しています。 Xcode CloudはAppleが公式に提供しているCI/CDサービスで、iOSアプリのビルドやCD(TestFlightへのデプロイ)を自動化できます。 今回は、Xcode Cloudでプライベートリポジトリをライブラリとして取り込む方法についてあまり参考資料が無く、ビルドを通すのに苦労したので、調査した結果をこちらにまとめておきます。 対象 今回の内容はiOS環境のCI/CDの話になるので、ある程度iOS開発の知識がある方を対象としています。 環境 - Xcode 15.4 - SwiftPMでライブラリを管理してる - 参照しているライブラリにプライベートリポジトリがある - GitHub Actions + FastlaneでTestFlightへデプロイしてる やりたいこと TestFlightのデプロイをGitHub Actions + FastlaneからXcode Cloudに移行したいと考えています。 これをすることで、Fastlaneへの依存をなくすことができ、App申請までのフローに必要なツールを減らすことができます。 また、申請に必要な証明書の管理もXcode Cloud上で直接Apple Developerの証明書を参照してくれるので、証明書の管理も楽になります。 悩み ここまで利点しかないXcode Cloudですが、ライブラリとしてプライベートリポジトリを参照する際には、ユーザー認証が必要になります。Xcode Cloudではそういった認証設定が考慮されていないため、プライベートリポジトリをライブラリとして参照するには一工夫する必要があります。 そこでXcode Cloudから提供されている ci_scripts/ci_post_clone.sh を活用して認証の設定することで、プライベートリポジトリを参照できるようになります。 .netrcの設定 Xcodeには12.5の頃から .netrc を参照する機能が追加されています。 .netrc はユーザー名とパスワードを記述したファイルで、 ~/.netrc に配置することで、 git clone 時に認証情報を自動で入力してくれます。 また、今回はライブラリをプライベートリポジトリのGitHub Releaseで管理する方法をとっているので、 api.github.com も追加しています。 touch ~/.netrc echo "machine github.com login $GITHUB_USER password $GITHUB_ACCESS_TOKEN" >> ~/.netrc echo "machine api.github.com login $GITHUB_USER password $GITHUB_ACCESS_TOKEN" >> ~/.netrc ユーザー名とアクセストークンをXcode Cloudの環境変数にSecretで設定しておき、 ci_post_clone.sh で参照するようにしています。 追加のリポジトリにURL追加 App Store Connect内のXcode Cloud の設定にある 追加のリポジトリ にライブラリのリポジトリURLを追加します。 defaults delete で設定を削除する 上記の設定でプライベートリポジトリのライブラリを取得できる様になってもまだライブラリの依存関係を解決できず、以下の様なエラーに遭遇しました。 :::message alert Could not resolve package dependencies: a resolved file is required when automatic dependency resolution is disabled and should be placed at XX/XX/Package.resolved. Running resolver because the following dependencies were added: 'XXXX' ( https://github.com/~~/~~.git ) fatalError ::: このエラーはXcode Cloud上でSwiftPMが、Package.resolvedを参照せず、自動でパッケージのバージョンを解決しようとしていることが原因です。 それぞれ、Xcodeのdefaultsを削除するとうまくビルドが通る様になります。 defaults delete com.apple.dt.Xcode IDEPackageOnlyUseVersionsFromResolvedFile defaults delete com.apple.dt.Xcode IDEDisableAutomaticPackageResolution この２つの設定なんですが実は違いが明確にわからなかったです... ローカルで xcodebuild のhelpコマンドを叩いて見てみると、似た様な設定があるのでそちらを参考にしても $ xcodebuild -help ... -disableAutomaticPackageResolution prevents packages from automatically being resolved to versions other than those recorded in the `Package.resolved` file -onlyUsePackageVersionsFromResolvedFile prevents packages from automatically being resolved to versions other than those recorded in the `Package.resolved` file Package.resolvedファイルに記録されているバージョン以外に、パッケージが自動的に解決されるのを防ぎます。 となっているので全く同じ内容しか書かれてないんですよね... 一応SwiftPMのIssueでも同じ様な内容の質問があって、この対応で解決しているので、現状はこれで問題ないと思います。 https://github.com/swiftlang/swift-package-manager/issues/6914 ひとまず、この２つの設定を削除することで、SwiftPMが参照するライブラリの依存関係をPackage.resolvedのみ参照し、依存関係を解決してくれる様になります。 結論 Xcode Cloudで起動前に参照される ci_scripts/ci_post_clone.sh に .netrc を設定することで、プライベートリポジトリを参照できるようになり、ライブラリの依存関係を解決するために、 defaults delete を設定することで、Xcode Cloud上でのビルドが通るようになりました。 #!/bin/sh defaults delete com.apple.dt.Xcode IDEPackageOnlyUseVersionsFromResolvedFile defaults delete com.apple.dt.Xcode IDEDisableAutomaticPackageResolution touch ~/.netrc echo "machine github.com login $GITHUB_USER password $GITHUB_ACCESS_TOKEN" >> ~/.netrc echo "machine api.github.com login $GITHUB_USER password $GITHUB_ACCESS_TOKEN" >> ~/.netrc 最後に Fastlaneは古くからある偉大なツールですが、Xcode Cloudの利用により、App申請までのフローをシンプルにできました。 先にも述べましたが、Xcode Cloudを使うことによるメリットは多いので、ぜひ導入を検討してみてください。 Appendix https://developer.apple.com/documentation/xcode/writing-custom-build-scripts https://speakerdeck.com/ryunen344/swiftpm-with-kmmwoprivatenagithub-releasedeyun-yong-suru https://qiita.com/tichise/items/87ff3f7c02d33d8c7370 https://github.com/swiftlang/swift-package-manager/issues/6914

はじめに こんにちは！ KINTOテクノロジーズ プロジェクト推進GのRen.Mです。 私は普段、 KINTO ONE(中古車) のフロントエンド開発をしています。 今回は技術的な話ではなく、社内活動についてご紹介したいと思います！ この記事の対象者 社内部活動に興味のある方 社員同士のコミュニケーション不足を感じている方 社内部活動とは 弊社には部活動のカルチャーがあり、社内にいくつもの部が存在しています！（ex.フットサル部、ゴルフ部など） 部活動ごとにSlackのパブリックチャンネルが存在し、参加は個人の自由で誰でも気軽に入部できます！ 中にはいくつも掛け持ちしている人もいるようです！ 私の所属しているバスケ部ではオフィス近隣の体育館を借りて夕方から3時間ほど練習会を行なっています。 体育館の利用は抽選にはなるのですが、基本的に毎月欠かさず活動しています！ また、スムーズに活動するために、 毎月体育館を予約する人 利用料を支払いに行く人 部費を管理する人 などと有志で役割分担をしています。 予約が確定するとSlackでアナウンスをして参加者を募ります！ 日によりますが参加人数は10人前後が多いです！ 活動風景 部活動を通して感じたこと 気分転換できるようになった 弊社にはエンジニアが多く在籍しており、デスクワークしている社員がほとんどです。 また、自宅で業務を行なうこともあるためどうしても運動不足になりがちです。 そのため部活動を通して運動することで心も体もリフレッシュできます！ ただ、どうしても白熱してしまうのでケガだけはしないように注意しながら練習しています！ 他部署の社員と交流できるようになった 個人的に部活動の一番の強みはこの部分だと感じます。 部には様々な部署の社員が所属しているため、普段業務で関わらない社員とコミュニケーションを取ることができます。 ミーティングで初めて顔を合わせるより、部活動を通してあらかじめ交流していた方がその先の業務をスムーズに進めることができるかもしれません。 また、新入社員の方が会社に馴染むきっかけになればいいと思います。 おわりに いかがだったでしょうか。 社内部活動は社員同士の親睦を深めつつ、リフレッシュできる良いカルチャーだと思います！ ぜひ弊社に入社した際は部活動を通して様々な社員と交流してみてください！ また、テックブログには他に様々な記事がありますのでよければご覧ください！

はじめに こんにちは！ KINTOテクノロジーズ プロジェクト推進GのRen.Mです。 私は普段、 KINTO ONE(中古車) のフロントエンド開発をしています。 今回は技術的な話ではなく、社内活動についてご紹介したいと思います！ この記事の対象者 社内部活動に興味のある方 社員同士のコミュニケーション不足を感じている方 社内部活動とは 弊社には部活動のカルチャーがあり、社内にいくつもの部が存在しています！（ex.フットサル部、ゴルフ部など） 部活動ごとにSlackのパブリックチャンネルが存在し、参加は個人の自由で誰でも気軽に入部できます！ 中にはいくつも掛け持ちしている人もいるようです！ 私の所属しているバスケ部ではオフィス近隣の体育館を借りて夕方から3時間ほど練習会を行なっています。 体育館の利用は抽選にはなるのですが、基本的に毎月欠かさず活動しています！ また、スムーズに活動するために、 毎月体育館を予約する人 利用料を支払いに行く人 部費を管理する人 などと有志で役割分担をしています。 予約が確定するとSlackでアナウンスをして参加者を募ります！ 日によりますが参加人数は10人前後が多いです！ 活動風景 部活動を通して感じたこと 気分転換できるようになった 弊社にはエンジニアが多く在籍しており、デスクワークしている社員がほとんどです。 また、自宅で業務を行なうこともあるためどうしても運動不足になりがちです。 そのため部活動を通して運動することで心も体もリフレッシュできます！ ただ、どうしても白熱してしまうのでケガだけはしないように注意しながら練習しています！ 他部署の社員と交流できるようになった 個人的に部活動の一番の強みはこの部分だと感じます。 部には様々な部署の社員が所属しているため、普段業務で関わらない社員とコミュニケーションを取ることができます。 ミーティングで初めて顔を合わせるより、部活動を通してあらかじめ交流していた方がその先の業務をスムーズに進めることができるかもしれません。 また、新入社員の方が会社に馴染むきっかけになればいいと思います。 おわりに いかがだったでしょうか。 社内部活動は社員同士の親睦を深めつつ、リフレッシュできる良いカルチャーだと思います！ ぜひ弊社に入社した際は部活動を通して様々な社員と交流してみてください！ また、テックブログには他に様々な記事がありますのでよければご覧ください！

はじめに こんにちは！ KINTOテクノロジーズ プロジェクト推進GのRen.Mです。 私は普段、 KINTO ONE(中古車) のフロントエンド開発をしています。 今回は技術的な話ではなく、社内活動についてご紹介したいと思います！ この記事の対象者 社内部活動に興味のある方 社員同士のコミュニケーション不足を感じている方 社内部活動とは 弊社には部活動のカルチャーがあり、社内にいくつもの部が存在しています！（ex.フットサル部、ゴルフ部など） 部活動ごとにSlackのパブリックチャンネルが存在し、参加は個人の自由で誰でも気軽に入部できます！ 中にはいくつも掛け持ちしている人もいるようです！ 私の所属しているバスケ部ではオフィス近隣の体育館を借りて夕方から3時間ほど練習会を行なっています。 体育館の利用は抽選にはなるのですが、基本的に毎月欠かさず活動しています！ また、スムーズに活動するために、 毎月体育館を予約する人 利用料を支払いに行く人 部費を管理する人 などと有志で役割分担をしています。 予約が確定するとSlackでアナウンスをして参加者を募ります！ 日によりますが参加人数は10人前後が多いです！ 活動風景 部活動を通して感じたこと 気分転換できるようになった 弊社にはエンジニアが多く在籍しており、デスクワークしている社員がほとんどです。 また、自宅で業務を行なうこともあるためどうしても運動不足になりがちです。 そのため部活動を通して運動することで心も体もリフレッシュできます！ ただ、どうしても白熱してしまうのでケガだけはしないように注意しながら練習しています！ 他部署の社員と交流できるようになった 個人的に部活動の一番の強みはこの部分だと感じます。 部には様々な部署の社員が所属しているため、普段業務で関わらない社員とコミュニケーションを取ることができます。 ミーティングで初めて顔を合わせるより、部活動を通してあらかじめ交流していた方がその先の業務をスムーズに進めることができるかもしれません。 また、新入社員の方が会社に馴染むきっかけになればいいと思います。 おわりに いかがだったでしょうか。 社内部活動は社員同士の親睦を深めつつ、リフレッシュできる良いカルチャーだと思います！ ぜひ弊社に入社した際は部活動を通して様々な社員と交流してみてください！ また、テックブログには他に様々な記事がありますのでよければご覧ください！

ごあいさつ みなさまこんにちは。 モバイルアプリ開発グループの中口と申します。 みなさまはiOSDC Japan 2024はいかがでしたか？？ 今年は8月開催ということもあり、例年以上の熱気でお祭りムードだったのではないでしょうか！！ こちらの記事は、 iOSDCに参加された方 iOSエンジニアの方 カンファレンスが好きな方 に読んでいただけたら嬉しいです。 昨年までのiOSDCの参加状況として、弊社は希望者がそれぞれ自由に参加して、参加者のみ後日社内勉強会でLT形式の共有を行ったり、テックブログを執筆したりする程度でした。 しかし2024年のKINTOテクノロジーズは一味違います！！ 今年は、 「スポンサーになった」「プロポーザルを何人か書いた(しかも1名採択された、すごい🎉！！)」「iOSDCの振り返りイベントを開催した」 と盛りだくさんで臨みました！！ 最後の締めくくりとしてこちらのブログを執筆させていただきます！！ スポンサーの話 KINTOテクノロジーズは今年初めてiOSDCのスポンサーをしました🙌！！！ 弊社は、これまで社内の横断的なイベントを盛り上げてくれていたテックブログチームが技術広報グループとして生まれ変わり、対外的なイベントにもより一層力を入れております！！今回参戦したiOSDCだけでなく、DroidKaigi2024、Developers Summit KANSAI（デブサミ関西）もスポンサーをしております。このように、どんどん大型カンファレンスに顔を出していっております！ その中で、今回のiOSDCではモバイルアプリ開発グループのiOSエンジニアが主体となって、上記の技術広報グループやクリエイティブ室など様々な方からサポートを受けつつ、全社を上げてスポンサーに臨みました。 詳しくは弊社のメンバーが、別記事でまとめてくれていたり、後述するiOSDCの振り返りイベントにて発表したりしているのでそちらをご覧ください！！ 【テックブログ】はじめてのiOSDCスポンサー日記 こちらでは、ノベルティなどの制作物を中心にご紹介しております！！！ぜひご一読ください！ https://blog.kinto-technologies.com/posts/2024-08-21-iOSDC2024-novelties/ 【テックブログ】KINTOテクノロジーズはiOSDC Japan 2024のゴールドスポンサーです&チャレンジトークンはこちら 🚙 弊社社員のインタビュー記事が載っていますのでこちらもぜひご一読ください！ https://blog.kinto-technologies.com/posts/sponsored-iosdc-japan-2024/ 【登壇スライド】iOSDC初出展までにした事を共有したい こちらでは、iOSDCのスポンサー出展について時系列でどんなふうに進めていったかを紹介しています！！カンファレンスでスポンサーに興味がある方には、参考になる内容が多いと思いますのでご興味あればぜひご一読ください！！！ https://speakerdeck.com/ktchiroyah/iosdcchu-chu-zhan-matenisitashi-wogong-you-sitai プロポーザルの話 今年は初めて会社として初めてプロポーザル執筆会を行ないました🙌!!! 登壇に興味があるメンバーが集まって、 こういったスライド を参考に、どうやって書けばいいか、どんな内容を書けばいいかなど、みんなでガヤガヤしながら下記のプロポーザルを出しました！！ https://fortee.jp/iosdc-japan-2024/proposal/7fd624c8-06ec-4dc4-960a-da37f74cf90f https://fortee.jp/iosdc-japan-2024/proposal/a82414cd-54d7-4abb-aa20-e35feb717489 https://fortee.jp/iosdc-japan-2024/proposal/e9e13b6d-0b74-4437-8ec0-ba6598b70ad7 https://fortee.jp/iosdc-japan-2024/proposal/ab0eeedf-0d4f-47a6-8df8-bd792b4d70ca そして下記が採択されています！！ほんとにすごい🎉！！ https://fortee.jp/iosdc-japan-2024/proposal/25af110e-61d0-4dc8-aba5-3e2e7d192868 https://fortee.jp/iosdc-japan-2024/proposal/c3901357-0782-4fb5-89b8-cb48c473f066 その後、他社さんの事例などを聞いているとプロポーザルをレビューする会などがあったり、そもそものプロポーザルの数が違ったりなどうちも負けていられないなぁと思いました。来年はもっと頑張りたいですね！ iOSDCの振り返りイベントを開催した こういった大型イベントにはアフターイベントがつきものでして、昨年もいくつかの会社さんがiOSDC振り返りイベント開催しておりました。 ＼そして今年は、弊社も開催しました🙌！！！／ なぜ開催したのか、開催までの経緯、当日の様子など、けっこう熱くブログにまとめていますので、こちらもぜひご一読ください！！！ https://blog.kinto-technologies.com/posts/2024-09-12-after-iosdc/ ここからは、当日iOSDCに参加したメンバーがどんなセッションを見たのかをまとめましたのでご覧ください。 KINTOテクノロジーズ的セッション視聴ランキング 15名(うち4名のパートナー様含む)の参加があったので、みなさんがどんなセッションを見たのか集計しました。そちらをランキング形式にしています！！ 弊社が、いまどんな技術に興味があるのか、ということが良く分かると思います！！ 同率2位(6名)： Swift 6のTyped throwsとSwiftにおけるエラーハンドリングの全体像を学ぶ https://fortee.jp/iosdc-japan-2024/proposal/c48577a8-33f1-4169-96a0-9866adc8db8e Typed throwsとは何か、そもそもその前提となるUntyped throwsとは何かを対比して説明してくれてとてもわかりやすかったです。 一見するとTyped throwsいいじゃんっと感じる内容でしたが、安易に使うべきでないという公式の発言などにも触れていただいて良かったと思いました。また、発表者のkoherさんの見解も聞けて勉強になりました。 同率2位(6名)： 座談会 「Strict ConcurrencyとSwift 6が開く新時代: 私たちはどう生きるか？」 https://fortee.jp/iosdc-japan-2024/proposal/5e7b95a8-9a2e-47d5-87a7-545c46c38b25 ちょうど弊社でもSwift 6に向けたStrict Concurrencyの調査を進めており、非常に参考になるセッションでした。こちらで発表されていた内容を参考に対応を進めていければと思います。 また、座談会という形式が斬新でみなさんがそれぞれフォローしあっていてとても素敵でした。こういったタイプの発表がもっと増えてほしいなと思いました。 同率2位(6名)： 開発を加速する共有Swift Package実践 https://fortee.jp/iosdc-japan-2024/proposal/52d755e6-2ba3-4474-82eb-46d845b6772c 弊社も複数のアプリを開発しているため、共有Swift Packageという仕組みは非常に魅力的だなと感じた反面、それぞれアプリの性質が違っているため共通化できる部分もなかなかなさそうだなぁというジレンマがあります。一方で共有Swift Package化するステップ(チーム構成とか運用方法とか)はとても勉強になりました。 同率1位(7名)： ルーキーズLT大会 https://fortee.jp/iosdc-japan-2024/proposal/95d397a6-f81d-4809-a062-048a447279b3 こちら弊社メンバーの登壇もあったため応援に駆けつけました！！ ペンライトで応援するスタイル楽しいですね！！ 内容も興味深いものが多く、 来年挑戦してみたい 、というメンバーもいました！ 同率1位(7名)： App Clipの魔法: iOSデザイン開発の新時代 https://fortee.jp/iosdc-japan-2024/proposal/66f33ab0-0d73-479a-855b-058e41e1379b 弊社では、まだApp Clipを導入しているアプリはないため、導入してみたいと思っていたメンバーが多かったです。一方でApp Clipのコードを配布するのはどうしたらいいか、などの課題も出てきそうとのことでした。 下記にそのほかで視聴数が多かったものを掲載いたします。 4人視聴 iOS/iPadOSの多様な「ViewController」の徹底解説と実装例 iOSアプリらしさを紐解く LT大会 後半戦 クロスプラットフォーム普及増加。SwiftでiOS開発はもうやらないのか....? 複雑さに立ち向かうためのソフトウェア開発入門 5人視聴 iPhoneへのマイナンバーカード搭載におけるデータ規格についての理解を深める GraphQLとスキーマファーストで切り開くライドシェアの未来 また、集計したところ今回の1人辺りの平均セッション視聴数は11.25でした！！！ おまけ 今年は、弊社もスポンサーブースを出したので、みんながどんなブースが印象に残ったのか興味がありアンケートとってみました！！ 9名から回答を得られまして、結果はこちらです。(一票以上投票があったブースのみ掲載しております) 　　 　　 　　 印象に残ったブースを集計しました 　　 　　 こちらをご覧いただくと、かなり票数がばらけたことが見て取れるのではないでしょうか。（弊社が6票集めているのは皆さん気を遣ってくれたのだと思います！） そう考えると、万人に受けるブースを作るのは難しいことなんだなぁという事も感じます。 そんな中4票集めているディー・エヌ・エーさんはさすがです。 終わりに 冒頭にも述べた通り、今年のiOSDCは全社的にかなり気合を入れて取り組みました！ スポンサー、プロポーザル、振り返りイベント、どれをとっても個人的にはとても大満足でした。ただし、まだまだ改善できることたくさんがございますので来年はもっとパワーアップしてiOSDCに参加できたらと思います！！ また、各セッションも例年通り非常に勉強になるものが多く、その点も改めて参加して良かったなと思います。

Background Introduction Self Introduction Hello. My name is Li Lin from the DevOps Team of the KINTO Technologies Global Development Group. Until 2017, I worked in China as an engineer, project manager, and university lecturer. In 2018, I started working in Japan. I’m a working mother of two, balancing my job while actively reskilling. Meet our DevOps team The Global Development Group's DevOps team started its operations this year. Our team is international, and the DevOps Team members speak Japanese, Chinese, and English as their native languages. We make sure to communicate smoothly by considering each member’s language skills. As a new team, each member has different experiences, but we always cooperate actively when facing challenges. I believe our teamwork is going well. DevOps Team Responsibilities Currently, there are multiple teams within the Global Development Group. The DevOps Team acts as a common team overseeing the entire Global Development Group. Our specific responsibilities are as follows: Task Work Content Formulate Global team deployment standards for CI/CD and development environment (Git/AWS/Grafana/SonarQube, etc.). Establish deployment standards for common components across Global teams. Improve common DevOps practices within the Global teams. Collect feedback on these tasks, and implement PDCA. Provide customized support individually. For requests not listed above that are not applicable to all groups, we assess their urgency and necessity, and then consider and support the implementation measures. Generally, the DevOps Team provides support, while the Application Team handles implementation. Error Resolution Support DevOps helps resolve errors during CI/CD processes and environment usage. Improve DevOps and AWS knowledge within the group. Conduct study sessions and handle individual inquiries. Contact point with the Platform Group DevOps Team handles inquiries between the Global Development Group and the Platform Group, collects feedback, and establishes operational standards for the groups. Standardization of Operational tasks Establish standards for operational tasks. Some tasks are outsourced to external vendors. Cost monitoring and policy setting. Optimize environment cost. Inquiry correspondence. Accept the inquiries mentioned above. Target audience of this article This article is intended for experienced developers who are considering or have already implemented Flyway. When I first started using Flyway, I did some research online but found that there was very little information providing an overall picture. This article serves as a proposal for introducing Flyway. I would be honored if you find the information helpful. Introducing Flyway What is Flyway? Flyway is an Open-Source database migration tool. It makes it easy to version control databases across multiple environments. The applicable scenarios for each command are as follows: Baseline Running the Baseline command creates the initial version for Flyway. The default version of Baseline is "1". In the Community Edition, you can create a baseline only once. It cannot be updated. If some tables already exist in the target database, you must run Baseline. Otherwise, the Migrate command will result in an error. [Scenario] Step 1) Set the version of the already applied SQL scripts to a number smaller than "1" before introducing Flyway. Step 2) Execute the Baseline command 3) Execute the Migrate command. As a result, SQL scripts with a version number of "1" or higher will be applied. [Reference] Baselines an existing database Clean The Clean command completely clears the target schema. Since this makes the schema empty, you must implement measures to prevent it from being used in production environments. [Scenario] If you want to revert to the initial version, you can do so by following the steps below. Step 1) Run the Clean command Step 2) Run the Migrate command [Reference] Wiping your configured schemas completely clean Info Flyway information is displayed. This command allows you to verify if Flyway can connect to the database. [Scenario] After execution, the following information is displayed (example): | Category | Version | Description | Type | Installed On | State | +-----------+---------+-------------+------+--------------+---------+ | Versioned | 00.01 | initial | SQL | | Pending | | Versioned | 00.02 | initial | SQL | | Pending | +-----------+---------+-------------+------+--------------+---------+ [Reference] Prints the details and status information about all the migrations Migrate Applies new SQL files that have not yet been applied. This is the most commonly used command. It is used every time the database needs to be updated to a new version. [Reference] Migrates the schema to the latest version Repair Removes the execution history of the SQL scripts that resulted in errors. However, the execution results cannot be removed. The Repair command only removes the execution history of failed SQL scripts from the flyway_shema_history table (Flyway's version control table) in the database. The following situation is common: In such cases, carefully check which SQL scripts were applied and make sure all scripts are applied correctly. If a single SQL file contains multiple SQL scripts and an error occurs, the scripts before the error will be applied, while those after the error will not be. [Scenario] [Example] When you are applying V01_07, V01_08, and V01_09, if V01_07 and V01_08 succeed but V01_09 fails, you can take the following steps. Step 1) Fix V01_09 Step 2) Execute the Repair command Step 3) Run the Migrate command again [Reference] Repairs the schema history table Validate This command checks whether the SQL scripts in the project have been applied to the database and also checks if the versions match. You can also use it to verify that the current database matches the version in the cloud. [Reference] Validates the applied migrations against the available ones Background to Flyway's implementation If you don’t use a tool like Flyway, you will need to log in to a bastion server for the database and run update scripts every time you deploy. Most of the Global Development Group's services are composed of microservices. As the number of environments grew, the traditional method of updating databases via bastion servers became increasingly burdensome and risky, leading to operational challenges. These circumstances led us to consider introducing Flyway. Initially, we tried introducing a job that could execute commands in a GitHub job via Lambda on AWS. When we actually tried using it, we encountered the following issues: If you migrate to AWS without sufficiently verifying the SQL scripts in a local environment, the migration may fail, making recovery difficult. If you update the database manually without building a Flyway environment in your local environment, there is a high risk that the structure will differ from the database on AWS. With the above issues in mind, during the first PDCA cycle, we implemented the Flyway system as shown below. Flyway implementation method by KINTO Technologies Global Development Group To use Flyway in a Spring Boot application, we implemented the following functions: Flyway is integrated directly into the application Usage Timing: Migrations are executed automatically when the application is started locally and when it is deployed to AWS. Purpose: This allows SQL migration scripts to be tested locally, and automates the migration process reducing manual effort. Introducing the Flyway plugin Usage Timing: During local development. Purpose: To run Flyway commands using the plugin if automatic migration cannot be preformed locally. GitHub job implementation for Flyway commands Usage Timing: When automatic migration cannot be performed during deployment to AWS, Flyway commands are executed using a GitHub job. Purpose: To enable the execution of Flyway commands without logging into AWS Next, I will introduce the final configurations for each implementation. Integrating Flyway into the application By integrating Flyway into the project, you can achieve the following: Databases in each environment are automatically migrated after the application starts. Migration SQL scripts are validated in local environment before migrating to the AWS database. The details are as follows: By running the following command, you can start a MySQL Docker image locally. Once the application starts, the latest SQL scripts will be automatically migrated. docker-compose up -d ./gradlew bootRun Introducing the Flyway plugin You can also maintain the local database manually using Flyway commands. By using the plugin as shown below, you can execute these commands Introducing GitHub jobs that can execute Flyway commands Once deployed on AWS, the database can be automatically migrated to Aurora. However, if this does not occur, you will need to run the Flyway command manually. Flyway commands are executed via Lambda on AWS. The configuration diagram is as follows: The flow from executing GitHub job to completing Flyway execution is as follows: Upload the execution file from the GitHub job to S3. Extract the necessary parameters from the payload (JSON). Use AWS CLI to extract information required for Flyway execution. Retrieve the zip file containing SQL scripts from the S3 bucket. Execute Flyway (using a Docker image on Lambda). Place the results in the S3 bucket. The image below shows the process when executing the command on GitHub. We have built this system so that it can be run without logging into AWS. This setup allows the following for each environment: Databases in each environment are automatically migrated after the application starts. Migration SQL scripts are validated in the local environment before migrating to the AWS database. Tools for executing Flyway commands are provided in each environment. Using Flyway has brought the following benefits: Deployment time was significantly reduced (by more than half) Eliminating database discrepancies between environments reduced unnecessary bugs and misunderstandings during development. The workload required for managing database versions in each environment was minimized (as long as the version was clearly indicated by the SQL script name). Testing and reviewing can prevent incomplete queries from being executed. No need to log in to a jump server built on AWS to perform operations. Of course, when using Flyway, there are some precautions: If there are many developers, decide on a consistent method of use. Troubleshooting and recovery from errors can be time-consuming. Theoretically, the above mechanism also allows you to start up a database while GitHub Actions CI/CD jobs are running, but we have not yet verified this. I am also considering using Flyway to build a database for automated CI/CD testing. While there are many benefits to using Flyway, it has also caused some issues. I believe there is room for improvement by using the PDCA cycle of usage standards. By gradually introducing Flyway depending on the environment and usage scenario, it can be used more safely and efficiently. If you're interested, we encourage you to give it a try.

Background Introduction Self Introduction Hello. My name is Li Lin from the DevOps Team of the KINTO Technologies Global Development Group. Until 2017, I worked in China as an engineer, project manager, and university lecturer. In 2018, I started working in Japan. I’m a working mother of two, balancing my job while actively reskilling. Meet our DevOps team The Global Development Group's DevOps team started its operations this year. Our team is international, and the DevOps Team members speak Japanese, Chinese, and English as their native languages. We make sure to communicate smoothly by considering each member’s language skills. As a new team, each member has different experiences, but we always cooperate actively when facing challenges. I believe our teamwork is going well. DevOps Team Responsibilities Currently, there are multiple teams within the Global Development Group. The DevOps Team acts as a common team overseeing the entire Global Development Group. Our specific responsibilities are as follows: Task Work Content Formulate Global team deployment standards for CI/CD and development environment (Git/AWS/Grafana/SonarQube, etc.). Establish deployment standards for common components across Global teams. Improve common DevOps practices within the Global teams. Collect feedback on these tasks, and implement PDCA. Provide customized support individually. For requests not listed above that are not applicable to all groups, we assess their urgency and necessity, and then consider and support the implementation measures. Generally, the DevOps Team provides support, while the Application Team handles implementation. Error Resolution Support DevOps helps resolve errors during CI/CD processes and environment usage. Improve DevOps and AWS knowledge within the group. Conduct study sessions and handle individual inquiries. Contact point with the Platform Group DevOps Team handles inquiries between the Global Development Group and the Platform Group, collects feedback, and establishes operational standards for the groups. Standardization of Operational tasks Establish standards for operational tasks. Some tasks are outsourced to external vendors. Cost monitoring and policy setting. Optimize environment cost. Inquiry correspondence. Accept the inquiries mentioned above. Target audience of this article This article is intended for experienced developers who are considering or have already implemented Flyway. When I first started using Flyway, I did some research online but found that there was very little information providing an overall picture. This article serves as a proposal for introducing Flyway. I would be honored if you find the information helpful. Introducing Flyway What is Flyway? Flyway is an Open-Source database migration tool. It makes it easy to version control databases across multiple environments. The applicable scenarios for each command are as follows: Baseline Running the Baseline command creates the initial version for Flyway. The default version of Baseline is "1". In the Community Edition, you can create a baseline only once. It cannot be updated. If some tables already exist in the target database, you must run Baseline. Otherwise, the Migrate command will result in an error. [Scenario] Step 1) Set the version of the already applied SQL scripts to a number smaller than "1" before introducing Flyway. Step 2) Execute the Baseline command 3) Execute the Migrate command. As a result, SQL scripts with a version number of "1" or higher will be applied. [Reference] Baselines an existing database Clean The Clean command completely clears the target schema. Since this makes the schema empty, you must implement measures to prevent it from being used in production environments. [Scenario] If you want to revert to the initial version, you can do so by following the steps below. Step 1) Run the Clean command Step 2) Run the Migrate command [Reference] Wiping your configured schemas completely clean Info Flyway information is displayed. This command allows you to verify if Flyway can connect to the database. [Scenario] After execution, the following information is displayed (example): | Category | Version | Description | Type | Installed On | State | +-----------+---------+-------------+------+--------------+---------+ | Versioned | 00.01 | initial | SQL | | Pending | | Versioned | 00.02 | initial | SQL | | Pending | +-----------+---------+-------------+------+--------------+---------+ [Reference] Prints the details and status information about all the migrations Migrate Applies new SQL files that have not yet been applied. This is the most commonly used command. It is used every time the database needs to be updated to a new version. [Reference] Migrates the schema to the latest version Repair Removes the execution history of the SQL scripts that resulted in errors. However, the execution results cannot be removed. The Repair command only removes the execution history of failed SQL scripts from the flyway_shema_history table (Flyway's version control table) in the database. The following situation is common: In such cases, carefully check which SQL scripts were applied and make sure all scripts are applied correctly. If a single SQL file contains multiple SQL scripts and an error occurs, the scripts before the error will be applied, while those after the error will not be. [Scenario] [Example] When you are applying V01_07, V01_08, and V01_09, if V01_07 and V01_08 succeed but V01_09 fails, you can take the following steps. Step 1) Fix V01_09 Step 2) Execute the Repair command Step 3) Run the Migrate command again [Reference] Repairs the schema history table Validate This command checks whether the SQL scripts in the project have been applied to the database and also checks if the versions match. You can also use it to verify that the current database matches the version in the cloud. [Reference] Validates the applied migrations against the available ones Background to Flyway's implementation If you don’t use a tool like Flyway, you will need to log in to a bastion server for the database and run update scripts every time you deploy. Most of the Global Development Group's services are composed of microservices. As the number of environments grew, the traditional method of updating databases via bastion servers became increasingly burdensome and risky, leading to operational challenges. These circumstances led us to consider introducing Flyway. Initially, we tried introducing a job that could execute commands in a GitHub job via Lambda on AWS. When we actually tried using it, we encountered the following issues: If you migrate to AWS without sufficiently verifying the SQL scripts in a local environment, the migration may fail, making recovery difficult. If you update the database manually without building a Flyway environment in your local environment, there is a high risk that the structure will differ from the database on AWS. With the above issues in mind, during the first PDCA cycle, we implemented the Flyway system as shown below. Flyway implementation method by KINTO Technologies Global Development Group To use Flyway in a Spring Boot application, we implemented the following functions: Flyway is integrated directly into the application Usage Timing: Migrations are executed automatically when the application is started locally and when it is deployed to AWS. Purpose: This allows SQL migration scripts to be tested locally, and automates the migration process reducing manual effort. Introducing the Flyway plugin Usage Timing: During local development. Purpose: To run Flyway commands using the plugin if automatic migration cannot be preformed locally. GitHub job implementation for Flyway commands Usage Timing: When automatic migration cannot be performed during deployment to AWS, Flyway commands are executed using a GitHub job. Purpose: To enable the execution of Flyway commands without logging into AWS Next, I will introduce the final configurations for each implementation. Integrating Flyway into the application By integrating Flyway into the project, you can achieve the following: Databases in each environment are automatically migrated after the application starts. Migration SQL scripts are validated in local environment before migrating to the AWS database. The details are as follows: By running the following command, you can start a MySQL Docker image locally. Once the application starts, the latest SQL scripts will be automatically migrated. docker-compose up -d ./gradlew bootRun Introducing the Flyway plugin You can also maintain the local database manually using Flyway commands. By using the plugin as shown below, you can execute these commands Introducing GitHub jobs that can execute Flyway commands Once deployed on AWS, the database can be automatically migrated to Aurora. However, if this does not occur, you will need to run the Flyway command manually. Flyway commands are executed via Lambda on AWS. The configuration diagram is as follows: The flow from executing GitHub job to completing Flyway execution is as follows: Upload the execution file from the GitHub job to S3. Extract the necessary parameters from the payload (JSON). Use AWS CLI to extract information required for Flyway execution. Retrieve the zip file containing SQL scripts from the S3 bucket. Execute Flyway (using a Docker image on Lambda). Place the results in the S3 bucket. The image below shows the process when executing the command on GitHub. We have built this system so that it can be run without logging into AWS. This setup allows the following for each environment: Databases in each environment are automatically migrated after the application starts. Migration SQL scripts are validated in the local environment before migrating to the AWS database. Tools for executing Flyway commands are provided in each environment. Using Flyway has brought the following benefits: Deployment time was significantly reduced (by more than half) Eliminating database discrepancies between environments reduced unnecessary bugs and misunderstandings during development. The workload required for managing database versions in each environment was minimized (as long as the version was clearly indicated by the SQL script name). Testing and reviewing can prevent incomplete queries from being executed. No need to log in to a jump server built on AWS to perform operations. Of course, when using Flyway, there are some precautions: If there are many developers, decide on a consistent method of use. Troubleshooting and recovery from errors can be time-consuming. Theoretically, the above mechanism also allows you to start up a database while GitHub Actions CI/CD jobs are running, but we have not yet verified this. I am also considering using Flyway to build a database for automated CI/CD testing. While there are many benefits to using Flyway, it has also caused some issues. I believe there is room for improvement by using the PDCA cycle of usage standards. By gradually introducing Flyway depending on the environment and usage scenario, it can be used more safely and efficiently. If you're interested, we encourage you to give it a try.

はじめに こんにちは。モバイル開発グループでiOSチームのチームリーダーをやっている中口と申します。 普段の業務では、 KINTOかんたん申し込みアプリ Prism Japan( スマホアプリ版 / 最近リリースされたばかりのWeb版 ) のiOS開発を担当しています。 早速本題ですが、2024年8月22日(木)-24(土)で開催されたiOSDC Japan 2024の振り返りイベントとして、2024年9月9日(月)に 【iOSDC JAPAN 2024 AFTER PARTY】 を開催しましたので、なぜ開催したのか、開催するまでに取り組んだこと、イベント当日の様子などを振り返りたいと思います。 特に、「なぜ開催したのか」の部分については、持論を展開しますが多くの方に共感いただければ嬉しいです。 こちらのブログは 本イベントに参加された方 iOSDCに参加された方 イベントによく参加する方、参加してみたい方 イベントの主催をしている方、主催をしてみたい方 などに読んでもらえたら嬉しいです。 また私自身、本イベントを開催したことでモチベーションが爆上がりしましたので、この思いを多くの方に共有したいと思い、テックブログとして執筆いたします。 なぜイベントを開催したのか こちらのイベントは、私の中で4月ごろから計画がありました。 では、なぜ計画したの？といわれたら、正直なところちゃんと言語化できていなかったと思います。 昨年の10月にチームリーダーという役割になって以降、iOSに関するイベントだけでなく、開発生産性、組織マネジメント、エンジニアリングマネージャーなどのイベントを中心にその他にも気になったイベントにはたくさん聞きに行くようにしました。 その中で、下記のような感情が湧いていることに気がつきました。 イベントに参加するとモチベーションがめっちゃ上がるなー イベントで登壇している人とか開催している人ってめっちゃカッコ良いなー なので、4月ごろの気持ちとしては、強いて言語化するのであれば「なんかカッコ良いし自分もイベントやってみたい！！」といったところでした。 ただ、お金や時間や人など多くの資源を投入して開催するイベントの目的が、「カッコ良いから」では説明がつきません。。。 その後、イベントをする意義について、自分の中で苦悩する日々が始まります。。。。 イベントを開催し終わった今でも、明確な答えには辿り着けていないと思います。 (こんな曖昧な状態でイベントを開催させていただいたことに感謝しかありません) 組織に属しながらイベントを開催する以上、やはり何かしら求められます。 よく言われることとしては「組織のプレゼンスを上げる」、「サービスを普及する」、「採用に繋げる」などでしょうか。これらは、すべて正しくイベントを開催する大きな意義だと思いますし、それらが結果として現れればそのイベントは大成功と言えると思います。 ただ、個人的にはちょっとしっくりきていない部分があります。IT業界におけるイベントでは、参加者の多くは「新たな知識を身につけたい」、「人脈を広げたい」、「イベントに参加すること自体が楽しい」などの自己成長等を目的としてイベントに参加される方が多いと思っており、主催者がどんな組織か知りたい、どんなサービスを出しているか知りたい、その会社に転職したい、などを理由にイベントに参加している方はごく稀だと考えます。 そういった中で、イベントをする意義について悩んだ末、自分なりの結論に達しました。 それは 「一人でも多くの方にモチベーションを伝染したい」 ということでした。 上記でも述べたとおり、イベントに参加すると「モチベーションがめっちゃ上がるなー」という感情になるのですが、これは私以外にも多くの方が実感するのでは無いかと思います。 明日からもっと仕事を頑張ろう、という人が一人でも増えれば、その積み重ねが世の中を良くすることにつながっていくと考えます。 また、モチベーションが上がることによって、私のようにイベントを開催してみたいとか、登壇してみたいという人が出てくるかもしれません。そして、それを見てまた別の人が主催や登壇をしてみたいと思うかもしれません。このように良いモチベーションはきっと伝染すると考えています！。 ということで、現段階ではイベントをする意義として、 「一人でも多くの方にモチベーションを伝染したい」 という思いをもって、本イベントを開催させていただきました(思いついた4月時点ではここまで整理できていませんでしたが)。 (そして、とはいえ組織的な観点で見ると、モチベーションが上がる、という理由だけでイベントをバンバンやろうよ、とはならないので苦悩の日々はまだまだ続きそうです。) 続きまして、本イベントの概要についてご紹介いたします。 イベントの概要 イベント名：iOSDC JAPAN 2024 AFTER PARTY 日時：2024/09/09(月) 19:00〜 参加者：20名前後 ウェルスナビさん、TimeTreeさん、弊社の3社にてiOSDCを振り返る会として合同開催をいたしました。 各社から1枠ずつの計3本のLT + 各社から1名ずつの計3名で実施するパネルディスカッションを行いました。 それでは、本イベントの開催に至るまでをご紹介いたします。 イベントを開催するまで 4月ごろにモバイル開発関連のイベントを開催してみたい、と思い立ったのですがどうやって開催すればいいのかなぁと悩みました。 弊社には、イベント運営をサポートいただける技術広報グループ(DevRel)がありまして、こちらにサポートをお願いすればイベントを円滑に運営することは問題ないだろう、と思っていました。 一方で、 集客 登壇者の募集 イベントのテーマ決め などは、技術広報グループのサポートがあっても難しい部分だろうな、と思ったので弊社1社でモバイル関連のイベントを実施することは、難しいと判断いたしました。 そんな中で、イベントの開催に非常に力を入れており、集客や登壇者募集のノウハウもたくさん持っていらっしゃるであろう、Findyさんにお力を借りたいと思ったため、 5月に開催されたこちらのイベント に伺ってきました。 その時の イベント参加レポート もブログにしていますので併せてご覧ください。 こちらのイベントをきっかけに、Findyさんの担当者と情報交換をさせていただくことができるようになりました。その後、どんなイベントを開催するか議論を重ねた結果、ウェルスナビさん、TimeTreeさんをご紹介いただき、iOSDCの振り返りイベントをやってみよう、という運びになりました。 イベント運営にさまざまな助言・ご協力をいただいたFindyさん、イベントを合同開催いただいたウェルスナビさん、TimeTreeさん、心より感謝申し上げます。 3社にてiOSDCの振り返りイベントを実施してみよう、となってからは、 イベントの座組はどうするか 登壇者やパネルディスカッションのパネラーはどうするか 開催日時 など、さまざまなことがスムーズに決定していきました。 Connpassによるイベント募集ページも無事に完成したところで、次は参加者の募集です。 今回は、イベント参加者とのコミュニケーションに重点を置きたい、という点も3社で共通していたことから、オフラインのみのイベントとしておりました。弊社のイベントスペースで開催としたのでキャパ的に30名くらいの募集を目標にしておりました。 2024/08/08(木)にConnpassページを開設して、数日の間に10名程度の参加登録があり、まずまずの参加数だなと思っていました。ただ、イベントPRの本番はiOSDCが開催される08/22(木)-24(土)の期間で、ここでどれだけ参加数を伸ばせられるかだと思っていました。今年は、弊社が初のスポンサーブースの 出展があるので、ここでしっかりとPRをしたり、弊社の公式XでもiOSDC期間中に複数回にわたってPRのポストをしたりと、かなりイベントの告知に力を入れました。 その結果、iOSDC期間中に増えた参加登録は、なんと 「0人」 でした、、、、 *正直、イベントの参加者募集をナメていました、、、* スポンサーブースでのイベントのPR方法は、振り返って考えてみると改善の必要がありそうだなと思いまいた。ただチラシを配るだけでなく、その場で登録いただくような動線(例えば、参加登録頂いた方にノベルティをお配りするなど)をもう少し検討しておくべきでした。 こちらは、次回以降の反省です。。。 実際に、Connpassにてイベントページの統計確認したところ、08/22(木)-24(土)の間に登録数が全くいない事や、ページビューも全く伸びていない事が見て取れるかと思います。 connpassにて確認した統計 その後は、9/9(月)までの期間、上記画像に示すようなペースで少しずつ参加者の登録をいただいたり、私自身が他社様のイベントに参加した際に、告知のお時間を頂くことができたりなどの効果で、当日時点で24名の参加登録を頂くことができました。 やはり、テーマとして、「iOSDCの振り返りイベント」としたことは一定の集客効果のあるテーマだったと感じました。 ということで、当初目標にしていた30名の参加登録には達成していませんでしたが、個人的には初主催のイベントで十分すぎる登録者数だと感じておりました。 あとは、当日を迎えるだけです。 イベント当日 こういったイベントにはさまざまな事情により当日キャンセルは付きものです。 実際に、本イベントも残念ながら当日キャンセルになってしまった方数名いらっしゃいました。 ただし、私自身は当日を迎えたこのタイミングで参加者の増減に一喜一憂している余裕はありませんでした。 合同開催いただいたウェルスナビさん、TimeTreeさん、および当日ご参加いただいた、参加者の皆様にとって参加して良かった、と思えるイベントにすることに集中しておりました。 ここからは、当日の様子を簡単に振り返っていきます。 緊張しながら皆様が到着されるのを待ちます。会場のセッティングが完了した様子です。 無事に会場のセッティング完了 19時になり、ウェルスナビさん、TimeTreeさん、参加者の皆さんが揃ったので、いよいよ1枠目のLTが始まります。 ウェルスナビ 牟田さんによる「Package.swiftから始めるDX」です。 牟田さんの発表 Swift Package Managerの基本から解説いただき、知っているようで知らないことなどもあり非常に勉強になりました。ウェルスナビさんにおける取り組みや、今後目指す姿などもご紹介いただき他社の取り組みが聞ける貴重な機会だなと思いました。また、今後控えているSwift6に向けての解説などもいただき勉強になりました。 続いて2枠目です。 TimeTree 坂口さんによる 「iOSDCのプロポーザルを形態素解析してトレンドの変遷を探ってみた」 です。 坂口さんの発表 こちらの発表は、タイトルを見た時点から非常に気になっていました。過去数回iOSDCには参加させていただいておりますが、やはりセッションには一定の流行があるような気がしておりまして、それがプロポーザルにもしっかりと反映されていて興味深かったです。また、この解析ツールをXcodeで自作されており、発表中にシミュレーターで実演されていたのも見ていて楽しかったです。 続いて3枠目です。 KINTOテクノロジーズ 日野森さんによる 「iOSDC初出展までにした事を共有したい」 です。 日野森さんによる発表 弊社がスポンサーブース初出展だったこともあり、準備期間における苦労話などを共有いただきました。私も一部の展示物で準備に携わったのですが、どんなコンテンツが来場者の方に受けるのか、どうすれば見やすいのか、など答えがない中で試行錯誤していくのはとても大変でした。 またスポンサーとして制作したものを、 こちらのテックブログでも 詳しく紹介されているのでぜひご覧ください。 次に、休憩や乾杯を挟んでパネルディスカッションを行いました。 パネラーは ウェルスナビ 長さん TimeTree masaichiさん キントテクノロジーズ　日野森さん の3名に登壇いただき、モデレーターとして、私が進行をいたしました。 パネルディスカッションメンバー こちらのテーマをあらかじめ用意しておき、iOSDCを振り返っていきました。 テーマに関しては、事前にパネラーの皆さん、どう言った内容が興味があるか、などをヒアリングしつつ決定させていただきましした。 パネルディスカッションのテーマ 時間の都合で全部のテーマをディスカッションできなかったのですが、話題を見つつその場の流れにあったテーマをピックアップしながら進めるように意識して進行いたしました。 各社のiOS開発の状況や、iOSDCに向けての取り組み、例年と比べての今年の変化などをお話しいただきました。 パネラーの皆様です 最後に参加者全員で集合写真を撮影いたしました。 集合写真 会が終わっての感想 冒頭でも述べた通り、本イベントは4月ごろより計画を立てて開催に至ることができました。無事に会が開催できるだろうか、参加者は集まるだろうか、当日の司会進行はうまくいくだろうか、などイベントが終了するまで常に不安を感じながら準備をしました。 その中で、合同開催のウェルスナビさん、TimeTreeさんのご協力があったり、弊社技術広報グループや当日に運営スタッフを引き受けていただいた方のご協力もあり、私個人としてはとても満足感の高い会を開催できたと感じております。もちろん当日ご参加いただいた皆様にも会を大いに盛り上げていただきました。 本イベントに関わっていただいた全ての皆様に心より感謝をお伝えしたいです。 ●良かったところ ウェルスナビさん、TimeTreeさん、Findyさんなどイベント開催にあたって他社様とのつながりが持てたことはとても貴重な事でした。 また、私自身初のイベント主催でしたが、無事完了できたことで自信が持てました。 ●今後改善していきたいところ 途中でも述べたように、集客面は非常に難しいなと感じました。現状はまだ良い打手が見つかっていないため、次回運営をする際は関係者含めてしっかり検討していきたいです。 また、弊社のiOSチームのメンバーにもっと本イベントに参加頂きたかったです。今回は、LTおよびパネラーとして弊社からはアシスタントマネージャーの日野森さんが登壇したのですが、日野森さんは普段から登壇やイベント参加の機会が多く、本イベントに関しては普段もっと登壇機会が少ないメンバーにチャレンジしてもらいたいという思いがありました。しかし、社内にて募集をしてみたところメンバーからの申し出が無かったため、日野森さんに登壇頂くことになりました。 私自身も社内の募集の段階で、もっと登壇のハードルを下げる工夫をしたり、登壇に向けた準備のサポート体制を整えたりなど、今後の大きな改善ポイントだなと感じております。 最後に 10月にはDoroidkaigi2024の振り返りイベントもウェルスナビさん、TimeTreeさんと3社で開催することが決まっていたり、今後も同様の座組で不定期にこのようなイベントを開催していきたいと考えております。 冒頭で「一人でも多くの方にモチベーションを伝染したい」と述べましたが、本イベントを通して一番モチベーションが上がったのは他でもない私自身だと感じています。 参加者の皆様の方でも、モチベーションが上がったよ、と感じてくれている方がいればこの会は大成功だったのではないかと思います。 今後もこのようなイベントの開催含め様々な活動を通して、関わる全ての人のモチベーションアップにつながる活動をしていきたいと考えています。

Introduction Hello. I am Nakaguchi from KINTO Technologies, Mobile App Development Group. I participated in the event TechBrew in Tokyo Facing Technical Debt in Mobile Apps , held on May 23, 2024. I would like to report on the event. The event day The venue was at the Findy where their office was newly renovated . I had heard the rumors, but seeing the spacious and beautiful event space in person was exciting 😀 True to the name “TechBrew,” there were plenty of alcohol and snacks available, and the atmosphere was very relaxed. However, since I had an LT (Lightning Talk) presentation later, I refrained from drinking alcohol until the presentation was over👍 1st LT "Steps to evolve Bitkey's mobile app" They shared the history of Bitkey's mobile app up to the present day. The app was originally built with React Native, but it was evolved through transitioning to native development, implementing SwiftUI, and then adopting TCA. However, they said that the SwiftUI implementation is still a work in progress and might have been a mistake. They faced challenges because the behavior of SwiftUI changes depending on different iOS versions, which was something I could relate to from my own experiences. During the LT, the comments that really stood out to me were, "Everything we thought was good was the right choice," and "The decisions we made at that time were probably the right ones." It made me realize how true it is. I also had the opportunity to chat with the presenter, Ara-san, during the social gathering after the LT. We talked about many things, including Swift on Windows, and I learned a lot of new information. It was a very enjoyable conversation. 2nd LT "Approaching technical debt in mobile apps as a whole company" They discussed what technical debt is and how to tackle it. One of the speakers highlighted the need to distinguish between: Debt we are aware of, but accept it to gain returns. Debt we are unaware of, or that became debt due to changes in the circumstances. They mentioned that the former is manageable, but the latter can become problematic if ignored for too long. To address technical debt, they stressed the importance of negotiating time to resolve it, even if it means pausing business tasks. They emphasized that technical debt is a shared problem, involving not just the development team but all stakeholders, which I also agree with. I feel that such negotiation skills are especially important for engineering managers and team leaders. They also mentioned that they use FourKeys to visualize the situation, but warned against focusing too much on numerical goals. I also feel the same that visualizing a team's development capability is challenging, and I am careful not to rely too much on frameworks like FourKeys. 3rd LT "How to deal with technical debt in Safie Viewer for iOS" The presentation covered the challenges and strategies in developing their app that has been around for 10 years. The app still uses many technologies from its initial release, and while there is a desire to re-architect, the current system is stable and capable of adding many new features. As a result, they were unable to justify the time-consuming refactoring, and were unable to take any action to eliminate the debt. Currently, they are addressing the issues by doing what they can, with the following two main policies. Take immediate actions if possible: Updating to the latest Xcode version as soon as it is released. There is code that cannot be written unless the version is upgraded, which leads to creating legacy code. Implementing Danger A steady approach Currently using MVC/MVP Asynchronous processing is closure-based Re-architecting from this state is risky. Test new features with modern technology. I thought it made sense that to actually get started, you need to draw up a specific schedule. I'm often hesitant about major refactorings, so I’ve learned the importance of setting a clear schedule and sticking to it. 4th LT "Ensuring safe mobile development with package management" Like LT3, this talk also focused on an app with a long history of 8 years. They discussed how they addressed technical debt by focusing on commonization and separation. A recent challenge they face is excessive commonization . For example, their Channel data has around 100 parameters (borrowing the speaker’s terms), and there are many situations where they end up with data that is not used every time. On the other hand, they warned that excessive separation of responsibilities can also be problematic. There were instances where functions were separated even though they were only called from one place, leading to an overdone state. The importance of "thoughtful commonization" and " thoughtful responsibility separation" left a strong impression on me, and I realized I might have separated things without much consideration. They also explained that it is a good idea to manage these issues using Package Manager and introduced some ideas and methods for doing so. 5th LT "Tackling technical debt with GitHub Copilot" This was my presentation. You can find the presentation content here . I discussed the use of GitHub Copilot in Xcode. Compared to VScode, which officially supports GitHub Copilot, Xcode still has many limitations, and its usage rate is not growing as much. However, I found that Xcode's Chat function can significantly help in addressing technical debt, so I focused on that in my presentation. During the presentation, I demonstrated the Chat function, and I felt that the attention of the entire audience became even more concentrated. I was very happy that everyone seemed to be listening with interest. This was my first time speaking at an event outside of our company, but everyone in the audience listened warmly, and I was able to complete my presentation without any problems. Conclusion After the LT sessions, there was a social gathering where I had the opportunity to exchange information with many attendees. It was a very stimulating experience, and I felt motivated to continue participating in and speaking at such external events in the future. I also had a chance to speak with Takahashi-san, the organizer of the event. We discussed how great it would be to hold a joint event between our Mobile App Development Group and Findy. I look forward to actively pursuing such collaborations. As a souvenir, I received a bottle of IPA brewed by Findy!

The first commemorative request This is HOKA from the Manabi-no-Michi-no-Eki (Learning Roadside Station) team. In February 2024, during our monthly company-wide meeting, we announced the launch of our "Manabi-no-Michi-no-Eki (Learning Roadside Station)" initiative. Following this announcement, Nakaguchi-san from the Mobile App Development Group’s iOS team reached out with a request: "I'm looking for some advice on how to organize my study sessions." Study Session Consultation for the Mobile App Development Group This was our first inquiry. We quickly organized a meeting with the four team leaders of the iOS team and three of us from the Learning Roadside Station team. The iOS team has been holding weekly study sessions since June 2023, aiming to enhance the team’s overall skills . In the first week of each month, they decide together on what topics they want to focus on, and then they spend the second to fourth weeks working on those topics. Facilitators also take turns. They mentioned that they have also conducted various activities like casual conversation, LT (lightning talks), and reading groups, and even presented about HIG (Human Interface Guidelines). As for myself, my impression was: "Everything seems so well organized" "What else do they have to worry?" I thought. But this is a common way KINTO Technologies employees are perceived. As a result of this consultation meeting, three members of our administrative office were invited to observe their study sessions! A Peek into the Study Session Next Door Self-introduction and casual chat session So, we decided to do our own "A peek into the study session next door." The date was March 12, 2024. The iOS team gathered online and in a meeting room to start their study session. Since there were new members joining that day, the theme was a casual chat session where everyone could introduce themselves. First, everyone introduced themselves, 1 minute x 18 people = about 20 minutes in total. They shared their names, the products they were in charge of, and recent updates. Although each introduction was only one minute, we made use of Slack chat comments to react, which made it an efficient introduction time for those who were participating for the first time to get to know the members’ personalities. The Learning Roadside Station team also took the opportunity to introduce ourselves. In the second half, the casual chat began. One member mentioned that Awata-san, who visited the Muromachi office yesterday, said that deploying from Slack was reaching its limit, and he suggested creating a mobile app that could integrate without needing to sign in. Then, another member proposed, “Why not develop it in our spare time? Our Mobile App Development Group has producers a火曜nd backend developers. If you're interested, we've created a Slack channel so let's talk about it there." Wow! Then, assistant manager Hinomori-san suggested, “How about developing a Learning Roadside Station app? It would be great to create an internal app. Maybe we could integrate NFTs and KTC tokens.” Yajima-san added, "How about giving points for attending study sessions?" Hinomori-san said, "What if those who accumulate points by the end of the year get some kind of reward? It sounds fun and could be a good way to work on projects that are not yet ready to be released externally. " Nakano-san added, "It might be great for internal members to develop for internal use!" A surprising positive turn for our Learning Roadside Station!!! I'm so pleased. "There's likely more we can learn from this activity beyond just writing source code." Comments flew around during the casual chat, providing hints for growth as engineers. This study session is going great, isn't it? The chat continued, and our March study session’s excitement centered around the "try! Swift Tokyo” event which will be April’s study session topic. With their assignments in hand for the next week, the iOS engineers returned to their own paths.