This article is the entry for day 21 in the KINTO Technologies Advent Calendar 2024 🎅🎄 Introduction Hello everyone! My name is DL, and I’m part of the Business Development Group team in the Group Core System Division at KINTO Technologies (KTC) . Currently, we’re collaborating with KINTO divisions in Latin America to implement an in-house system for KINTO One, a car leasing business with additional services like insurance. As a Business Analyst (BA), I focus on analyzing KINTO's operations and crafting IT solutions to streamline workflows and enhance efficiency. Before business analysis became part of the global team, system designs often fell short to meet KINTO’s global business expectations for enterprise-level solutions that addressed their daily operational intricacies. This is where a BA becomes indispensable in capturing the daily operational processes and addressing pain points, making Business Analysis a strategic pillar for adding value to global projects. Today, I want to invite you into the often-misunderstood world of the BA. You might think, “Isn’t that just a numbers person?” or “Aren’t they the ones writing down what others say?” But being a BA is far more—it’s about problem-solving, strategy, and communication. At its core, a BA bridges the technical and business worlds. Whether improving efficiency, streamlining operations, or adopting technology, the BA steps in to listen, analyze, and design practical, impactful solutions. By engaging stakeholders from executives to end-users, the BA becomes the crucial translator, turning business needs into effective technical solutions. Story 1 - The Power of Listening: A Business Analyst (BA)’s Role One critical skill for a BA is listening—not just to words, but to the underlying needs. In one project, I tackled a financial company’s inefficient reporting process. Business units worldwide submitted quarterly reports via email, creating a bottleneck with over 100 daily emails. Files were manually downloaded, consolidated, and checked for errors—a time-consuming, error-prone process. Witnessing this firsthand, I worked with stakeholders to identify pain points. Collaborating with IT, we developed a secure LAN directory structure for direct submissions. Automated batch and VBA scripts streamlined checking, copying, and aggregating data, reducing manual effort by 70% and enabling more valuable analysis. The solution’s success led to its adoption across the department. Story 2 - A Lesson in Overlooking Stakeholders Afterwards, a SaaS product was introduced without the BA and users’ full review. It was selected for its cost savings and dashboards, but it couldn’t support existing automated workflows, forcing teams back to manual processes... Despite complaints, the decision was final, leaving users frustrated and dissatisfied. This experience underscored the importance of involving a BA early to align solutions with real user needs. The Story Continues… Although Story 2 might initially seem like a letdown, it offers an important lesson: whether we’re introducing process changes or developing new products, the key to success lies in listening to and truly understanding the needs of the end users. This brings us to the critical role a BA plays in KTC’s global project. As mentioned earlier, the global team is working with KINTO divisions in Latin America to implement an in-house system for KINTO One business (a car leasing business with additional services, e.g., insurance). Developing a global product/system means addressing diverse specifications across countries and languages. The challenge lies in creating a system that is flexible enough to accommodate each country’s varying needs. So, how do we approach this? Business users in each country are experts in their own processes and the processes are different country by country. Engineers are tasked with the challenge of building a flexible system that can accommodate all the differences. This is where the BA steps in, bridging the gap between business users and engineers. As a BA, we take a systematic approach: Gathering Business Processes: We carefully document the processes unique to each country. As the BA, this step is highly critical. The BA basically needs to become the expert of the business processes and fully understand every detailed step to ensure no steps are missed. To accomplish this step, our BAs in KTC have visited and been on-site at the businesses in Latin America, which is essential for grasping the nuances of each process. Moreover, the key in this step is to understand the businesses’ current pain points. Why? Because the system KTC develops should address these pain points to add tangible value to the business users’ daily workflows. By addressing the pain points, the business users can see a decrease in manual work, increase in productivity and effectiveness. And this can be measured in terms of hours of work reduced, reduction in lead time, and general welfare of the business users. Conducting Gap Analysis: This analysis highlights the differences and commonalities across these processes for each country. As the BA, there are two critical considerations in this step: Order of Operations: If the countries have similar order of operation, then that’s great news! However, if one country has a reverse order of operation, then this becomes much more complex when designing a system that can accommodate both. For example, to perform a repair on a vehicle, in case 1: the repair is approved first as a KINTO service, and then the execution of service is carried out. However, in case 2: the execution of service is carried out first, then the service is verified if it’s included as a KINTO service. Such differences in the order of operation adds complexity to the system design. External Systems Integration: Another critical consideration in this step is to note the external systems/platforms that are currently being used by the different countries. For example, one country may be using SAP as their accounting system, another country may be using another type of accounting system. This adds complexity to the integration needed for the global product. Collaborating on Solutions: Using the gap analysis, the BA works closely with the engineers to design the flexibility needed to meet the requirements of all countries involved. In this step, the BA is now trying to solve a complex puzzle with the help of the engineers. As the BA, this step is highly critical because the BA basically represents the business users of both countries and needs to design a system that can accommodate both. As an analogy, maybe one country is like a sedan, and the other country is like a van, so the BA works with the engineers to come up with an SUV?... lol... something along those lines. This step involves looking at the details of every step of the process and making sure that every step can accommodate both countries. Then after that, making sure that all the steps can be stitched together to create a cohesive and flexible system. It’s a lot of fun to solve such complex problems! The result is a collaborative effort that ensures the global product not only aligns with business needs but also has the right balance of system flexibility. This demonstrates just how essential the role of a BA is in the success of a global project. The Impact of a Business Analyst (BA) What does it mean to be a BA? It means being a problem solver, a communicator, and a strategist—having the curiosity to ask questions, the patience to listen, and the persistence to find answers. Ultimately, it’s about making a real difference in how organizations run, how people work, and how decisions are made. BAs may not always be in the spotlight, but our work shapes outcomes, saves resources, and makes lives easier. We are the bridge that turns ideas into reality, translating needs into solutions. If there’s one takeaway, it’s this: Never underestimate the power of listening. Whether you’re a BA, a stakeholder, or someone striving to make a difference, real progress comes from listening, translating, and connecting. Thank you!

Introduction This is a report from the organizers of the second "KINTO Technologies MeetUp!" Our Event page: [Second] KINTO Technologies MeetUp! - connpass Previous related articles: Preparations for our first "KINTO Technologies MeetUp!" | KINTO Tech Blog | KINTO Tech Blog (kinto-technologies.com) KINTO Technologies MeetUp! (Organizers’ edition) | KINTO Tech Blog | KINTO Tech Blog (kinto-technologies.com) The first event was held exclusively on-site, but this time we prepared to allow participation online as well. Building on the knowledge gained from our first event, we embraced the challenge of hosting in a new hybrid format. Here’s a look at the organizer’s experience this time around! Pre-Event Tasks Snack arrangement To ensure no one felt “a bit unsatisfied” with the food, we focused on enhancing the snack selection. During the latter half of our last event, we found that the pizza we had prepared wasn’t enough, and some participants commented that they felt “a bit unsatisfied.” Initially, we planned for pizza again and increased the budget to address this, but we eventually learned about Maisen’s mini burgers (thanks to a recommendation) and decided to offer those instead. Here are some of the great things about the mini burger: It is individually packaged and easy to grab. Therefore, there is no need to prepare paper plates. It is easy to give away if there are leftovers, reducing waste. It is designed to be served at room temperature, allowing more flexibility with delivery timing. Although we had a strong desire to serve hot pizza, we decided on the mini burgers after considering the benefits. Additionally we prepared individually wrapped snacks to make it easy for participants to enjoy at their convenience. As a result, many participants enjoyed the mini burgers, and we ended up with just a few leftovers, making it a successful choice overall! Novelty selection We aimed to provide novelties that would make participants think, "I want to take this home and actually use it.” With this goal in mind, we carefully selected items, believing that a good event combined with appealing novelties can bring back fond memories of the day just by looking at them. In choosing the novelties, we considered not only practicality but also whether the items would have an irresistible appeal. For distribution, we thought carefully about how to present the novelties in a way that encourage attendees to take them home. Although not all novelties were taken by participants, we hope that those who did take them will remember the event whenever they see the items. Event timetable design I was entrusted with designing the event timetable, which is an important factor that determines the progression and flow of the event. It was a significant responsibility, and I felt the pressure as I worked through it. My main focus during the planning was, “ Will the participants find the event engaging and enjoyable without feeling bored? ” In the timetable for the previous MeetUp, we missed incorporating break times and a group photo session with participants, which were later highlighted as areas for improvement. For this event, we addressed these points by allocating time for breaks and photos. Additionally, we included a Lightning Talk session to bring energy and keep the pace lively, something that was missing last time. Thankfully, the event proceeded smoothly, mostly according to the timetable, and the atmosphere was lively throughout—a welcome outcome. However, we made some last-minute adjustments to the timetable, and I realized in hindsight that more careful pre-event planning would have helped. Event documents preparation To prepare documents, not only did we organized presentations for speakers but also prepared various guides and resources for attendees, including event instructions, seating arrangements for discussion sessions, and pre-event handouts. These documents were aimed at ensuring the smooth progression of the Meetup. In the previous event, we realized that verbal directions to restrooms or having a QR code for Wi-Fi access would have been helpful, so this time we created documents to cover these needs. Promotion and Outreach Attracting attendees to corporate events can be challenging, and we also faced difficulties. Here are two approaches we found especially effective: Included the product names mentioned in the presentations within the promotional text. Posted in the IT Slack community. Included the product names mentioned in the presentations within the promotional text. Initially, we planned to announce the event on X twice. The first announcement was scheduled for when it went live on connpass, and the second just before the event. However, we soon realized that the key metrics we wanted to focus on were not growing as expected, which were: Views on the connpass event page The number of event participants To address these challenges, we considered increasing the opportunities for people to learn about the event by adding more posts on X. However, simply posting about the event might not catch people’s attention, and awareness of the event could remain low. So, we decided to drill down our thinking to create more effective post content. We asked ourselves, “what kind of post would catch my eye as a reader?” ↓ Would I be more interested if the post mentioned a product I care about? ↓ Would it feel more relatable if it included some of the challenges we faced? Through this simple drill-down, we concluded that the post should include not only the product names mentioned in the presentations but also what we achieved with them. Here’s an example of the posts we created: By posting such kind of content, we successfully increased both the views on the connpass event page and the number of participants, addressing the challenges we had been facing. We couldn't be happier with the results!! IT Slack community posts On the day of the event, we asked some of the on-site attendees how they had heard about the event. All of them answered, “on the IT Slack.” Its reach is truly impressive! As someone who regularly checks the Slack channel #share-event as well, I highly recommend posting announcements there when hosting events related to IT or corporate IT. This time, our event aimed to connect with other corporate IT teams, and the warmth of the IT Slack community was truly heartwarming. To those who participated, whether you found us through connpass or X, thank you, and we look forward to your continued support! Disruptive participants prevention In the past, we experienced a situation at another KTC-hosted event where a person seemed to attend solely for the food. There was an atmosphere that could have escalated into a disturbance, as the person drank excessively and reacted negatively when approached. Through this experience, I decided to firmly establish a clear protocols and preventative measures. After researching how others handle such situations, we adopted the following approaches: Identify and prevent disruptive individuals before they can cause issues. If a disruptive individual does enter (or tries to get in), ensure minimal impact on legitimate participants, and act swiftly to manage the situation. Thoughts on handling troublemakers at networking events | wakatono (note.com) We prepared with the approach of preventing suspicious individuals from entering while also establishing grounds and methods for their removal if necessary. After consulting with the building management team at KINTO Technologies’ Muromachi Office in COREDO Muromachi 2, which was our venue, they assured us that they could intervene if needed, even restraining individuals if the situation escalated. We shared their contact information with the event staff to ensure everyone was prepared to respond if necessary. Additionally, we updated the connpass event page to include a clear policy prohibiting disruptive behavior and informing participants that they may be asked to leave if such actions occur. Fortunately, no such incidents happened this time. However, having these measures in place gave us peace of mind and allowed us to focus fully on running the event smoothly. Event Day Tasks Venue set up We followed the same basic process as in the previous event, but this time we also needed to account for the space required for the streaming equipment. Its placement was determined by the length of our cables, and we also made sure that participants still had a comfortable viewing area while adressing those constraints. While we prepared the basic layout in advance, adjustments were made on the day to accommodate the number of attendees. Although there was some last-minute scrambling, we successfully created a space where participants could relax and enjoy the event. Unfortunately, we weren't able to update the seating layout for the discussion session in time, which caused some confusion during the event. Equipment setup, connections, and control With limited equipment on hand, we carefully planned how to deploy it effectively. Hosting the event in a hybrid format required extra attention to various details. Thankfully, there were no major issues, and we were able to deliver a seamless experience for our online attendees as well. Overall, it turned out to be a successful event! Camera setup Since the camera feed would be projected onto a small wipe, we adjusted the framing to ensure that the speaker's face was clearly visible. The camera had to be connected to the “switcher” used for stream control, so we positioned it near the operation desk (commonly referred as the "ops desk") while ensuring it faced the speaker directly. The camera was basically fixed in place! Minimal adjustments were needed when speakers took turns to correct any misalignment caused by differences in their heights. Audio setup We conducted pre-event checks for microphones, volume levels in the venue, and audio levels for online participants. Since this was a hybrid event, these checks were absolutely essential! We made sure to prevent any issues, such as audio distortion or volume levels that were either too low or too high for both online and in-person attendees. Additionally, during presentations, we continuously monitored the online audio to respond immediately in case of any audio dropouts or sudden distortion. Streaming For this event, we decided on a relatively simple streaming setup, drawing from previous successful experiences. By keeping the setup straightforward, we minimized the risk of unexpected issues during the broadcast. We projected the same video feed onto a screen so that the presenters could see how their slides and wipe were displayed. To ensure the speaker’s slides and the wipe didn’t overlap, we manually adjusted the position of the wipe, moving it around to different corners as needed. Each speaker was able to present using their own familiar laptop, and we managed the visuals without any disruptions. This made the process smooth and hassle-free! Microphones, document projection, the wipe-everything was checked and ready to go! Reception, guidance, and exit support Preparation Since we had the same team as the previous event, we already had a good amount of knowledge. However, we documented tasks in Confluence, assigned roles to each member, and prepared accordingly. By deciding everyone’s roles for the event day in advance, we avoided unnecessary chaos during the event. On the day of the event As soon as the registration closed, we started preparing the building entry passes. They looked too plain on their own, so we added a custom cover for a personalized touch. This small effort, which we’ve also used for other events, really makes a difference. Reception start Since the event took place during rush hour, many non-participants were coming and going. To ensure that attendees could recognize the reception area, we called out to anyone who looked like they might be attending the event (Though sometimes we mistakenly approached unrelated people, haha). This time, we didn’t assign staff to guide attendees from the reception area to the 16th floor venue. Instead, whenever participants headed to the venue, we notified the operations team via Slack with updates like “X number of people are coming!” This was initially done spontaneously but turned out to be very well-received by the team waiting at the venue. In the end, it was a great idea, and I’m glad we did it! Exit support To be honest, we didn’t have detailed discussions about this part as a team, so whoever was available handled it on the spot. Personally, I really enjoyed chatting with attendees in the elevator as they left. Hearing comments like "That was fun!" "Please hold another event again" or "KINTO Technologies seems like such a fun company!" Left me feeling thrilled. Being able to hear this feedback live felt like a special reward! ♬ Moderation and hosting We managed to get through most of it with energy and quick adaptability! About 80% of the moderation was handled this way. Here, I’ll share the remaining 20% of the things we consciously focused on. Adding comments before each presentation In an in-person-only event, transitions like speaker changes are visible and don’t stand out much. However, in a hybrid event, online attendees can only see what’s shown on camera, which creates awkward silences during transitions. To address this, I added short introductions about the upcoming presentation or summarized the previous one, much like the opening remarks before classic Showa-era song performances. This helped create a smoother transition. Separate remarks for in-person and online audiences only at the beginning and end Time constraints were the main reason, but I avoided making separate comments for the in-person and online audiences during the event. For online attendees, hearing jokes or commentary that only resonates with the in-person audience can make them feel left out and reduce their sense of immersion. I kept this in mind while moderating. Using a microphone sparingly after the online broadcast ended This was the opposite approach compared to the one mentioned above. I wanted to maximize the in-person experience! It’s similar to how bands or idol groups sometimes speak directly to the audience without a mic at the end of a concert. It gives you that feeling of being on a live session. Yes, like that moment. I was initially hesitant about speaking in front of the audience, but I’m relieved that I was able to fulfill my role. To anyone reading this, I encourage you to give it a try as well. Snack preparation and distribution Last time was our first external event, and organizing refreshments was a bit of a challenge. But after hosting several other events over the past few months, we’ve gotten the hang of it! This time, we prepared Maisen’s cutlet sandwiches🐷 Everything looks delicious...Kin-chan Which should I take...Take-chan Compared to pizza, it's easier to eat. We adopted a casual style, encouraging participants to grab a sandwich after checking in and enjoy the meetup! while eating. Since the event was held around dinnertime (pretty much), I think this was a welcome addiction! Even though we ordered plenty, the fillet cutlet sandwiches were the first to disappear ( ..)φ [takes notes] We will do our best to adjust the quantities next time. For drinks, beer was the most popular. We had three types available, but after attending another company’s event that offered about ten varieties, I was impressed! Next time, we’ll try expanding our selection. Kaizen, kaizen! Post-Event Tasks Retrospective When it comes to wrapping up team activities, our go-to process is doing Retrospectives. What is a Retrospective Retrospectives are sessions: to look back on what went well, what didn’t go so well, and what happened during an activity or project, and from there, to identify and develop concrete action plans for the future. At KINTO Technologies, retrospectives are deeply embedded in our everyday practices. Across all departments, they are commonly referred to as “furikaeri” or simply “retro,” and they often come up in casual conversations. The event retrospective After the MeetUp concluded, we held a retrospective specifically for the organizing team. While there are no strict rules or fixed formats for these sessions, we often use the KPT framework (Keep/Problem/Try) to guide our discussions, which is what we used this time as well. In event operations, there are always things that could have gone better or areas for improvement. The KPT framework helps us identify these “seeds of kaizen” and turn them into actionable steps for future events. Retrospective preparation When there are many participants and everyone’s time is limited, proper preparation is key to make the most out of retrospective sessions. This time, we followed these steps: Created a Wiki where everyone can freely contribute (we used Confluence as our Wiki tool) Prepared a page with the KPT framework (for this retrospective, we created additional categories such as "Preparation," "Promotion and Outreach," and "On-site Setup" to make it easier to organize inputs). Announced on Slack, asking participants to write down their observations before the retrospective day. The facilitator reviewed the pages right before the retrospective, processes the contributions, and planned the flow of the discussion (for example, deciding what to prioritize and how much time to allocate for each topic). The retrospective: From icebreaker to ground rules And then, the retrospective took place! If we had more time, we would have started with an icebreaker, asking participants to share their best moments of the event to liven up the atmosphere. However, due to time constraints, the retrospective kicked off with a positive summary from the event leader. After the Icebreaker, we explained the “magic rules” (ground rules) to make it easier for everyone to share their thoughts and ensure the best retrospective experience. The following rules were read aloud to all participants: Be active in the conversation! No matter how trivial it may seem, don't hesitate to share it! Don't monopolize the conversation! Do not interrupt others while they’re speaking! Remember that even those who are quiet have something valuable to contribute Trust that everyone did their best Focus on finding causes, not assigning blame Frame it as “the problem versus us” Appreciate the opportunity to learn from mistakes and celebrate our growth! After reading the ground rules, the main retrospective began. The retrospective: KPT implementation Thanks to the contributions made by participants beforehand, we were able to start the session with a clear sense of direction. We began by reviewing the submitted entries one by one. An essential part of the process is having the person who wrote each entry read it aloud. While the facilitator could do this, it’s important for the group to understand the intent and emotions behind the words. That’s why we prioritize self-reading as much as possible. Process: The author reads their entry aloud. The facilitator reflects on the content, organizes it, and opens the floor for comments, additions, and feedback. Consolidate the input and update the Wiki to keep everything organized. For any proposed actions, achieve consensus and add them as a “Try” item. We followed this flow and kept the discussion lively and engaging for as long as time allows. At the end, we celebrated the completion of the event by finalizing the Wiki, enriched with action items (“Try”). A retrospective built together Reflecting on the retrospective Through this retrospective, we were able to create actionable items for the next similar event, leaving a legacy for our future selves to build upon. At the same time, we believe the retrospective served as a space to improve the “quality of relationships” and the “quality of thinking” among participants. By repeating these collaborative events, we aim to create a “positive cycle of success”. Better actions will lead to better results, ultimately strengthening the organization as a whole. Closing thoughts Thanks to the autonomy and dedication of each team member, we were able to host another enjoyable event with no major issues, just like last time! Now that we have established a track record of holding offline/online hybrid events, we plan to leverage this knowledge for future opportunities. This time, we replicated the approach from the first event to achieve the same results with less effort. However, it made me reflect on balancing "standardization" with "creativity." If a task is merely "something to do" without requiring creativity, it's better to standardize it through manuals (as we did this time). However, with each event held by KINTO Technologies, whether it’s managing the reception or arranging light meals, I’ve seen firsthand how creativity and ingenuity make these processes more attractive and efficient. Rather than attempting to overly systematize everything, perhaps it’s more important to create an environment where individuals are empowered to grow through their own autonomy and ingenuity. We also incorporated online participation to reach as many people as possible. However, I found it incredibly valuable to share challenges with other companies’ IT teams during in-person social gatherings. As we move forward, I would like to continue hosting events while carefully considering whether to stick with the hybrid format or focus solely on on-site events.

この記事は KINTOテクノロジーズアドベントカレンダー2024 の20日目の記事です🎅🎄 Impact Effort Matrix（インパクト・エフォートマトリックス）を使って社内交流を実践してみた こんにちは、KINTO テクノロジーズの技術広報グループに所属しているMayaと木下です。 はじめに 私たちは過去に神保町で社内交流会を開催し、オフィス内の交流不足を解消し、チーム間のつながりを強化することを目指しました。 実施したときの記事はこちら↓ https://blog.kinto-technologies.com/posts/2023-09-19-JimbochoISM/ このイベントでは、企画段階にImpact/Effort Matrix（インパクト・エフォートマトリックス）を活用して、催しの内容を決定しました。 これにより、イベントを盛り上げるためのアイデアを整理し、タスクの優先順位を明確にすることができました。 その結果、複数回のイベントをスムーズに運営することができました。 この記事では、その時の経験を基に、Impact/Effort Matrixを用いたイベントの企画・実践、振り返りまでのアプローチを紹介します。 本記事が、読者の皆さんのプロジェクトやイベント計画に役立てば幸いです。 ぜひ、最後までお楽しみください。 Impact/Effort Matrixについて Impact/Effort Matrix（インパクト・エフォートマトリックス）は、プロジェクトやタスクの優先順位を効率的に決定するためのシンプルかつ効果的なツールです。 このマトリックスは、タスクやアイデアを 「成果（Impact）」 と 「労力（Effort）」 の2軸で分類することで、どの項目にリソースを集中させるべきかを視覚的に判断できます。 基本構造 Impact/Effort Matrix は4つの象限で構成されます： Quick Wins（すぐに実行すべきタスク） 高い成果をもたらし、必要な労力が少ないタスク 優先的に取り組むべきです Major Projects（戦略的に取り組むべきタスク） 高い成果が期待できるが、労力も多く必要なタスク リソース計画が重要になります Fill-ins（余裕があるときに実施するタスク） 労力が少なく成果も小さいタスク 優先順位は低めです Parking Lot（避けるべきタスク） 成果が低く、労力が多いタスク 基本的に取り組むべきではありません さらに詳しくは Miroのテンプレート説明ページ をご参照ください。 なぜ導入したのか 第1回目の神保町共有会開催後、それなりに良い感想をいただくことができました。 しかし、参加者全員が一体感を持てているわけではなかったため、もっと「ワイワイ感」を出すにはどうすればいいのか？というブレインストーミングをしたかったのです。 運営メンバーで議論し合いながら、目指す目的を明確にし、やるべきタスクとやらないタスクを選定しました。 そして、優先順位をメンバーで共有するための適切な手法を探している中、メンバーが過去に利用経験のあるImpact/Effort Matrixを用いることにしました。 活用して感じたメリット 優先順位付けが明確になる： 4象限に相対的に全ての課題を配置するので、議論を進め、付箋を並べるにつれて、優先するべきタスクが視覚的に浮き上がってくる 容易に共有でき、全員の理解が一致しやすい： 上記の延長線ではありますが、何を優先すべきかを議論するきっかけにもなるため、認識をチームで合わせる時間になります 全員のコンセンサスを得ながら進めるため、コミットメントも高く、全員が自分ごとと捉えて進めやすい チームのリソースを最適化できる： 次のアクションへも全員が納得する落とし込みにもつながるため、出戻りの発生を防げます 苦労したところ・工夫したところ よくある話ではありますが、一番チームで苦労したところは意思決定の部分でした。 2回実施したImpact/Effort Matrixの初回では、意見や共通認識の課題が多く出たものの、その情報をどう整理し、次のイベントの改善に繋げるかのコンセンサスに至るまでたくさん議論を重ねる必要がありました。 整理した内容の粒度がバラバラで、やりたいことのスコープも広かったため、思うように成果を出せませんでした。 2回目では、上記の経験を踏まえて課題の粒度を揃え、目的を明確にし、スコープを絞ることで、より具体的な結果を得ることができました。 メンバーの理解が深まり、プロセスをスムーズに進めることができました。 イベントの方向性をより具体化することができて、二回目も無事に成功し、神保町共有会の三回目に向けたアクションプランを策定し、Jiraボードでタスクを見える化しました。 この時、新しいメンバーが数名加わり、初めてIEMを体験する人たちでした。 未経験者を多く含む状況ながらも、これまでの経験からスムーズに進行することができ、三回目の神保町共有会を盛り上げることができました。 Impact/Effort matrixやってみての感想 Impact/Effort Matrixの手法を理解しても、実際に自分たちの状況に当てはめて実践しようとすると、最初は本当にこれで良いのかと迷うことがあり、チーム全体に不安が広がることもありました。 しかし、違和感を覚える点や改善すべき点について、皆が意見を出し合い、それを尊重し合うことで、私たちは様々なアイデアを整理し、どのタスクを優先すべきかを明確にすることができました。 このImpact/Effort Matrixの手法が上手く機能するまでの過程では、意見の対立もありましたが、それぞれのアイデアを客観的に評価することで、全員が納得できる形で進めることができました。 イベントに向けて準備が進むにつれ、チームとしての一体感が高まり、最終的には社内交流会の参加者から高い評価を得ることができました。 終わりに 今回の記事では、神保町での社内交流会を例に、Impact/Effort Matrixを活用したイベントの企画・実践、振り返りのアプローチをご紹介しました。 初めは手探りで不安もあり、うまくできているのか自信が持てない部分もありましたが、何度か実践を重ねる中で次第に慣れ、運営メンバーが途中で増えたにもかかわらず、スムーズに運営できるようになりました。 この手法が、皆さんのプロジェクトやイベントの成功に役立つことを願っています。 皆さんのプロジェクトやイベントの参考になれば幸いです。 KINTO テクノロジーズでは、一緒に働く仲間を広く募集しています。 ご興味を持たれた方は、ぜひお気軽にご連絡ください。お待ちしております！ https://hrmos.co/pages/kinto-technologies/jobs

この記事は KINTOテクノロジーズアドベントカレンダー2024 の20日目の記事です🎅🎄 はじめに はじめまして、KINTOテクノロジーズ（ KTC ）でモバイルアプリ（Flutter）の開発を担当しているHand-Tomiです。 最近、KTCでは「Flutterチーム」を立ち上げ、アプリケーション開発を進めています。その中で、導入して特に効果的だと感じた手法をいくつかご紹介したいと思います。 今回は、「GitHub Actions」と「Firebase Hosting」を活用して、コードレビュー時に便利なWebプレビューを実現する方法について解説します。 皆さんの参考になれば幸いです。 🎯 目標 この記事の目的は、プルリクに /preview というコメントを追加することで、デバッグ用のWebページリンクが自動でコメントとして投稿される仕組みを実現することです。  上記のリンクをクリックすると、以下のようにFlutterプロジェクトのアプリケーションが表示されます。  🔍 Webプレビューを使う理由 コードレビューする際、動作を確認するにはソースコードをクローンし、設定やビルドを行う必要がありますが、この方法は時間がかかります。一方、 Webプレビュー を設定しておくと、簡単かつ迅速に動作確認を行うことが可能です。 以降では、この仕組みを実現する方法をstep-by-stepでご紹介します。 Firebaseのセットアップ 🌐 Firebaseプロジェクトを作成 まだFirebaseプロジェクトがない場合、Firebaseコンソールから新しいプロジェクトを作成してください。 プロジェクト名は「sample」としました。 他の機能を使用する予定がない場合は無効にしておきます（有効にしておいても問題ありません）。 しばらく待つと プロジェクトの作成が完了しました！ ⚙️ Firebase CLIのセットアップ FlutterプロジェクトにFirebase Hostingを設定する予定です。Firebase CLIを使用すれば簡単に設定できるので、Terminalでセットアップしてみましょう。 1. Firebase CLIのインストール Firebase CLIのインストール方法はいくつかありますが、npmがインストールされているMacOSでは、以下のコマンドを使用することで簡単にインストールできます。 npm install -g firebase-tools 他の環境でのインストール方法は、 こちら を参照してください。 2. Firebase CLIへのログイン 以下のコマンドを実行して、CLI上でFirebaseにログインしてください。 firebase login 🔧 Firebase Hostingのセットアップ 準備が整ったので、FlutterプロジェクトにFirebase Hostingを設定してみましょう。 1. webframeworksの有効化 FlutterアプリケーションをFirebase Hostingにデプロイするためには、実験的な機能である webframeworks を有効にする必要があります。 firebase experiments:enable webframeworks 2. Firebase Hostingの初期化 Flutterプロジェクトのルートディレクトリで、以下のコマンドを実行してFirebaseをセットアップしましょう。 firebase init hosting 上記のコマンドを実行すると、以下のような質問が表示されます。 # Firebaseプロジェクトは先ほど作成したsampleプロジェクトを選択します。 ? Please select an option: Use an existing project ? Select a default Firebase project for this directory: sample-1234 (sample) # こちらは「Yes」で問題ありません。 ? Detected an existing Flutter Web codebase in the current directory, should we use this? Yes # リージョン選択の質問です。デフォルトの「us-central1 (Iowa)」を選択しました。 ? In which region would you like to host server-side content, if applicable? us-central1 (Iowa) # 自分で作成する予定なので「No」にしました。 ? Set up automatic builds and deploys with GitHub? No i Writing configuration info to firebase.json... i Writing project information to .firebaserc... ✔ Firebase initialization complete! 質問に回答すると、 firebase.json ファイルが生成されます。 :::message alert FlutterプロジェクトにWebプラットフォームが含まれていない場合、エラーが発生することがあります。その場合は、以下のコマンドを実行してWebプラットフォームを追加してください。 flutter create . --platform web ::: 3. デプロイ 試しにデプロイしてみましょう。 firebase deploy 上記のコマンドを実行すると、以下のようにHosting URLが表示されます。 ... ✔ Deploy complete! Project Console: https://console.firebase.google.com/project/sample-1234/overview Hosting URL: https://sample-1234.web.app このURLを開くと、Flutterプロジェクトが正常に表示されることを確認できます。 GitHub Actionsの作成 次に、プルリクエストに /preview とコメントすると実行されるYAMLファイルを作成しましょう。 🔑 Firebaseサービスアカウントキーの準備 GitHub Actionsを通じてFirebaseにデプロイするためには、Firebaseサービスアカウントのキーが必要です。簡単にキーを取得する方法は、以下のコマンドを使用することです。 firebase init hosting:github 上記のコマンドを入力すると、以下のような質問が表示されます。ソースコードがあるリポジトリを user/repository の形式で指定してください。 # Github repositoryを入力してください。 `user/repository`のように記載してください。 ? For which GitHub repository would you like to set up a GitHub workflow? (format: user/repository) Hand-Tomi/sample すると、Firebaseが自動的にGiGitHubポジトリのSecretsにサービスアカウントキーを設定し、以下のようにSecretsの定数名を教えてくれます（例： FIREBASE_SERVICE_ACCOUNT_SAMPLE_1234 ）。この定数名は保存しておきましょう。 ✔ Created service account github-action-1234 with Firebase Hosting admin permissions. ✔ Uploaded service account JSON to GitHub as secret FIREBASE_SERVICE_ACCOUNT_SAMPLE_1234. i You can manage your secrets at https://github.com/Hand-Tomi/sample/settings/secrets. 続いて、以下のような質問が出てきますが、必要なものは揃っているので Control+C （Windowsの場合は Ctrl+C ）で終了します。 ? Set up the workflow to run a build script before every deploy? ✍️ GitHub ActionsのYAMLファイル作成 いよいよGitHub ActionsのYAMLファイルを作成しましょう。 Flutterプロジェクトのルートにある .github/workflows ディレクトリにYAMLファイルを作成し、以下のコードを入力します。 name: Command Execute Deploy Web on: issue_comment: types: [created] jobs: deploy-web: if: ${{ github.event.issue.pull_request && github.event.comment.body == '/preview' }} name: Deploy Web runs-on: ubuntu-latest concurrency: group: ${{ github.workflow }}-${{ github.event.issue.number }} cancel-in-progress: true steps: - uses: actions/checkout@v4 with: ref: refs/pull/${{ github.event.issue.number }}/head fetch-depth: 0 - name: Set Up Flutter uses: subosito/flutter-action@v2 with: channel: 'stable' - name: Install Dependencies run: flutter pub get - id: deploy-web name: Deploy to Firebase Hosting uses: FirebaseExtended/action-hosting-deploy@v0 with: firebaseServiceAccount: ${{ secrets.FIREBASE_SERVICE_ACCOUNT_SAMPLE_1234 }} expires: 7d channelId: "issue_number_${{ github.event.issue.number }}" env: FIREBASE_CLI_EXPERIMENTS: webframeworks - name: Comment on Success if: success() uses: peter-evans/create-or-update-comment@v4 with: token: ${{ secrets.GITHUB_TOKEN }} issue-number: ${{ github.event.issue.number }} body: | ✅ Previewがデプロイされました。 - **リンク** : ${{ steps.deploy-web.outputs.details_url }} firebaseServiceAccount には、事前に作成しておいたSecretsの定数名を指定してください（例： FIREBASE_SERVICE_ACCOUNT_SAMPLE_1234 ）。 firebaseServiceAccount: ${{ secrets.FIREBASE_SERVICE_ACCOUNT_SAMPLE_1234 }} その後、該当リポジトリにマージし、プルリクエストに /preview とコメントを残すと、自動的にActionsが実行され、GitHub Actionsがリンクをコメントしてくれます。 💡 参考:GitHub ActionsのYAMLコードの説明 上記のYAMLコードについて解説します。 実行タイミング on: issue_comment: types: [created] issue_comment を使用すると、コメントが作成されたときに自動的にWorkflowが実行されます。このコメントはプルリクエストだけでなく、Issueにコメントされた場合も含まれます。 今回の記事ではプルリクエストのコメントに限定したいので、以下のように jobs の if に github.event.issue.pull_request を入れて、プルリクエストのみ実行するようにします。 jobs: deploy-web: if: ${{ github.event.issue.pull_request && github.event.comment.body == '/preview' }} また、 issue_comment を使う場合、Checkoutする場所を変更する必要があります。 issue_comment は現在のプルリクエストの最新コミット情報を持っていないため、そのままCheckoutするとデフォルトブランチの最新コミットにCheckoutされてしまいます。 そのため、以下のように actions/checkout に ref を指定する必要があります（参考： https://github.com/actions/checkout/issues/331#issuecomment-1438220926 ）。 - uses: actions/checkout@v4 with: ref: refs/pull/${{ github.event.issue.number }}/head fetch-depth: 0 コメントメッセージ確認 コメントのメッセージが /preview かどうかを確認します。以下のように github.event.comment.body を確認し、メッセージが /preview の場合のみdeploy-webジョブ内の処理を実行します。 jobs: deploy-web: if: ${{ github.event.issue.pull_request && github.event.comment.body == '/preview' }} 同時実行の防止 /preview を残した後、すぐに再度 /preview をコメントすると、同時実行になる可能性があります。 concurrency: group: ${{ github.workflow }}-${{ github.event.issue.number }} cancel-in-progress: true この場合、GitHub Actionsは concurrency を通じて同時実行を防止します。 重要なのは、 jobs の下に配置することです。 jobs: deploy-web: if: ${{ github.event.issue.pull_request && github.event.comment.body == '/preview' }} name: Deploy Web runs-on: ubuntu-latest concurrency: group: ${{ github.workflow }}-${{ github.event.issue.number }} cancel-in-progress: true 上記のように jobs の下に配置しないと、 if で github.event.comment.body == '/preview' を確認せずに concurrency が実行され、 /preview コメント後すぐに /preview 以外のコメントを残した場合、Actionが実行されなくなります。 デプロイ 以下のステップはFirebase Hostingにデプロイするものです。 - id: deploy-web name: Deploy to Firebase Hosting uses: FirebaseExtended/action-hosting-deploy@v0 with: firebaseServiceAccount: ${{ secrets.FIREBASE_SERVICE_ACCOUNT_SAMPLE_1234 }} expires: 7d channelId: "issue_number_${{ github.event.issue.number }}" env: FIREBASE_CLI_EXPERIMENTS: webframeworks firebaseServiceAccount: ${{ secrets.FIREBASE_SERVICE_ACCOUNT_SAMPLE_1234 }} : Firebaseのサービスアカウントの認証キーです。以前に取得しておいたものを入力してください。 expires: 7d : 有効期限です。このように設定するとプレビューサイトは7日後に無効になります。 channelId: "issue_number_${{ github.event.issue.number }}" : Firebase Previewのチャンネル名です。 live 以外の channelId を指定すると、Firebase Previewにデプロイされ、有効期限を設定できます。 FIREBASE_CLI_EXPERIMENTS: webframeworks : Firebase CLIの実験的な機能である webframeworks を使用します。Flutter Webの場合は必須です。 リンクコメント peter-evans/create-or-update-comment を使用して、リンクのコメントを残しました。これを使うと、簡単にリアクションを残したり、コメントを追加・編集できます。 - name: Comment on Success if: success() uses: peter-evans/create-or-update-comment@v4 with: token: ${{ secrets.GITHUB_TOKEN }} issue-number: ${{ github.event.issue.number }} body: | ✅ Previewがデプロイされました。 - **リンク** : ${{ steps.deploy-web.outputs.details_url }} if: success() : 成功したときのみこのステップが実行されます。 token: ${{ secrets.GITHUB_TOKEN }} : コメントを残すためには GITHUB_TOKEN が必要です。別途の設定は必要ありません。 issue-number: ${{ github.event.issue.number }} : どのIssueにコメントするかの指定です。 issue_comment で実行したWorkflowの場合、 github.event.issue.number でIssue番号を確認できます。 steps.deploy-web.outputs.details_url : 上記のデプロイステップから取得したURLを表示します。 他の情報を載せたい場合は、 こちら を参照してください。 おわりに 今回ご紹介した手法により、コードレビュー時の動作確認がこれまでよりも迅速かつ簡単に行えるようになります。チーム全体の開発効率が向上し、より良いプロダクトの提供につながるでしょう。 ただし、デバッグ用のWebプレビューを導入する際には、セキュリティ面への配慮が必要であり、OS特有の差異をどのように解決するかも検討する必要があります。OSの機能を多用する場合、メリットよりもデメリットが大きいかもしれません。 しかし、OSの機能をあまり使用しないプロジェクトでは、デメリットよりもメリットが多いため、ぜひ皆さんの開発環境にも導入してみてください。 また、flutterチームのメンバーが執筆した他の記事もぜひご覧ください！ Flutter開発: CustomPaintとPathでQRコードの枠線をデザインする ここまで読んでいただき、ありがとうございました。

はじめに こんにちは🎄クラウドインフラグループに所属している島川です。クラウドインフラグループではAWSをはじめとした社内全体のインフラ領域の設計から運用まで担当しています。弊社でも様々なプロダクトで生成AIの活用が進んできておりクラウドインフラグループとしても様々な支援を実施しています。 本記事ではAmazon BedrockのKnowledge BaseをTerraformで構築した際の情報を共有します。またre:Invent 2024で発表された RAG評価 にも触れていきたいと思います。 構成 今回構築する構成はこちらです。 Bedrock Knowledge BaseのVector storeとしてOpenSearch Serverlessを利用し、データソースはS3を指定します。 Terraformで構築 ディレクトリ構造はこちら。それぞれ内容を説明していきます。 なお今回使用しているTerraformバージョンは 1.7.5 です。 $ tree . ├── aoss.tf # OpenSearch Serverless ├── bedrock.tf # Bedrockリソース ├── iam.tf # iam ├── s3.tf # bedrock用のS3 ├── locals.tf # 変数定義 ├── provider.tf # provider定義 └── terraform.tf # Backendなどの設定 ここでは変数定義をしています。 locals { env = { environment = "dev" region_name = "us-west-2" sid = "test" } aoss = { vector_index = "vector_index" vector_field = "vector_field" text_field = "text_field" metadata_field = "metadata_field" vector_dimension = 1024 } } AWS provider、OpenSearch providerのバージョンを指定かつtfstateを保存するバックエンドS3を指定しています。ここで使用しているS3は別途手動で作成したものなので今回のterraformコードには含まれていません。 terraform { required_providers { # https://registry.terraform.io/providers/hashicorp/aws/ aws = { source = "hashicorp/aws" version = "~> 5.0" } opensearch = { source = "opensearch-project/opensearch" version = "2.2.0" } } backend "s3" { bucket = "***-common-bucket" region = "ap-northeast-1" key = "hogehoge-terraform.tfstate" encrypt = true } } AWSとOpenSearchのプロバイダーを定義します。OpenSearchのプロバイダーはindexを追加するために使用します。 provider "aws" { region = local.env.region_name default_tags { tags = { SID = local.env.sid Environment = local.env.environment } } } provider "opensearch" { url = aws_opensearchserverless_collection.collection.collection_endpoint aws_region = local.env.region_name healthcheck = false } OpenSearch Serverlessのリソースとindexを作成します。 Deploy Amazon OpenSearch Serverless with Terraform を参考にしました。 今回はセキュリティポリシーでpublicにしていますが、VPCエンドポイントで制御するのが理想です。 data "aws_caller_identity" "current" {} # Creates a collection resource "aws_opensearchserverless_collection" "collection" { name = "${local.env.sid}-collection" type = "VECTORSEARCH" standby_replicas = "DISABLED" depends_on = [aws_opensearchserverless_security_policy.encryption_policy] } # Creates an encryption security policy resource "aws_opensearchserverless_security_policy" "encryption_policy" { name = "${local.env.sid}-encryption-policy" type = "encryption" description = "encryption policy for ${local.env.sid}-collection" policy = jsonencode({ Rules = [ { Resource = [ "collection/${local.env.sid}-collection" ], ResourceType = "collection" } ], AWSOwnedKey = true }) } # Creates a network security policy resource "aws_opensearchserverless_security_policy" "network_policy" { name = "${local.env.sid}-network-policy" type = "network" description = "public access for dashboard, VPC access for collection endpoint" policy = jsonencode([ ###VPC エンドポイントを利用する際の参考 # { # Description = "VPC access for collection endpoint", # Rules = [ # { # ResourceType = "collection", # Resource = [ # "collection/${local.env.sid}-collection}" # ] # } # ], # AllowFromPublic = false, # SourceVPCEs = [ # aws_opensearchserverless_vpc_endpoint.vpc_endpoint.id # ] # }, { Description = "Public access for dashboards and collection", Rules = [ { ResourceType = "collection", Resource = [ "collection/${local.env.sid}-collection" ] }, { ResourceType = "dashboard" Resource = [ "collection/${local.env.sid}-collection" ] } ], AllowFromPublic = true } ]) } # Creates a data access policy resource "aws_opensearchserverless_access_policy" "data_access_policy" { name = "${local.env.sid}-data-access-policy" type = "data" description = "allow index and collection access" policy = jsonencode([ { Rules = [ { ResourceType = "index", Resource = [ "index/${local.env.sid}-collection/*" ], Permission = [ "aoss:*" ] }, { ResourceType = "collection", Resource = [ "collection/${local.env.sid}-collection" ], Permission = [ "aoss:*" ] } ], Principal = [ data.aws_caller_identity.current.arn, iam_role.bedrock.arn, ] } ]) } resource "opensearch_index" "vector_index" { name = local.aoss.vector_index mappings = jsonencode({ properties = { "${local.aoss.metadata_field}" = { type = "text" index = false } "${local.aoss.text_field}" = { type = "text" index = true } "${local.aoss.vector_field}" = { type = "knn_vector" dimension = "${local.aoss.vector_dimension}" method = { engine = "faiss" name = "hnsw" } } } }) depends_on = [aws_opensearchserverless_collection.collection] } Knowledge Baseとデータソースの作成をします。 data "aws_bedrock_foundation_model" "embedding" { model_id = "amazon.titan-embed-text-v2:0" } resource "aws_bedrockagent_knowledge_base" "this" { name = "test-kb" role_arn = iam_role.bedrock.arn knowledge_base_configuration { type = "VECTOR" vector_knowledge_base_configuration { embedding_model_arn = data.aws_bedrock_foundation_model.embedding.model_arn } } storage_configuration { type = "OPENSEARCH_SERVERLESS" opensearch_serverless_configuration { collection_arn = aws_opensearchserverless_collection.collection.arn vector_index_name = local.aoss.vector_index field_mapping { vector_field = local.aoss.vector_field text_field = local.aoss.text_field metadata_field = local.aoss.metadata_field } } } depends_on = [iam_role.bedrock] } resource "aws_bedrockagent_data_source" "this" { knowledge_base_id = aws_bedrockagent_knowledge_base.this.id name = "test-s3-001" data_source_configuration { type = "S3" s3_configuration { bucket_arn = "arn:aws:s3:::****-dev-test-***" ### バケット名マスク } } depends_on = [aws_bedrockagent_knowledge_base.this] } bedrockが使用するサービスロールを設定します。 resource "aws_iam_role" "bedrock" { name = "bedrock-role" managed_policy_arns = [aws_iam_policy.bedrock.arn] assume_role_policy = jsonencode({ Version = "2012-10-17" Statement = [ { Action = "sts:AssumeRole" Effect = "Allow" Sid = "" Principal = { Service = "bedrock.amazonaws.com" } }, ] }) } resource "aws_iam_policy" "bedrock" { name = "bedrock-policy" policy = jsonencode({ Version = "2012-10-17" Statement = [ { Action = ["bedrock:InvokeModel"] Effect = "Allow" Resource = "*" }, { Action = [ "s3:GetObject", "s3:ListBucket", ] Effect = "Allow" Resource = "***-dev-test-***" ### 作成したS3のARN }, { Action = [ "aoss:APIAccessAll", ] Effect = "Allow" Resource = "arn:aws:aoss:us-west-2:12345678910:collection/*" }, ] }) } Bedrockで使用するS3バケットを作成します。またCORSの設定もしておきます。下記エラー参考画像です。 resource "aws_s3_bucket" "bedrock" { bucket = "***-dev-test-***" ### マスキング } resource "aws_s3_bucket_cors_configuration" "this" { bucket = aws_s3_bucket.bedrock.id cors_rule { allowed_headers = ["*"] allowed_methods = [ "GET", "PUT", "POST", "DELETE" ] allowed_origins = ["*"] } } 実行 terraform apply で一括で作成します。 作成されたものの確認 BedrockでKnowledge Baseが作成されていてデータソースがあることを確認します。 次にOpenSearchのコレクションが作成されていることとindexが設定されていることを確認します。 Knowledge baseの動作確認 S3にデータソースとして使用する適当なテキストを送ります。 犬が好きなものは肉です 猫が好きなものは魚です aws s3 cp ./test001.txt s3://[S3 Bucket Name]/test001.txt 次にデータソースの同期を実施します。 実際に質問を投げかけてみます。（PromptはClaude 3.5 Sonnetを使用） テキストに記載された回答を答えてくれているのと記載されていない内容については回答はしないようになっています。 簡単ではありますが以上Terraformを用いたKnowledge BaseとOpenSearch Serverlessの内容でした。 RAG評価を試してみる 次にここで作成したKnowledge Baseに対してre:Invent 2024で発表された RAG評価 を試してみます。 @ card 事前準備 評価のためのデータセットファイル(jsonl)を用意します。ここではプロンプトとそれに期待する答えを記載します。 {"conversationTurns":[{"referenceResponses":[{"content":[{"text":"猫の好きな食べ物は魚です"}]}],"prompt":{"content":[{"text":"猫の好きなものは？"}]}}]} {"conversationTurns":[{"referenceResponses":[{"content":[{"text":"犬の好きな食べ物は肉です"}]}],"prompt":{"content":[{"text":"犬の好きなものは？"}]}}]} S3から参照させるのでテキストをS3にコピーします。 aws s3 cp ./dataset001.txt s3://[S3 Bucket Name]/datasets/dataset001.txt jobの作成 次にjobを作成します。 マネジメントコンソールからでもOKですが今回はCLIで実施しました。 @ card aws bedrock create-evaluation-job \ --job-name "rag-evaluation-complete-stereotype-docs-app" \ --job-description "Evaluates Completeness and Stereotyping of RAG for docs application" \ --role-arn "arn:aws::iam:<region>:<account-id>:role/AmazonBedrock-KnowledgeBases" \ --evaluation-context "RAG" \ --evaluationConfig file://knowledge-base-evaluation-config.json \ --inference-config file://knowledge-base-evaluation-inference-config.json \ --output-data-config '{"s3Uri":"s3://docs/kbevalresults/"}' knowledge-base-evaluation-config.json 内でjsonlのファイルと結果の保存先の指定が必要です。 jobの確認 15分～20分ほど待ってjobが完了したので中身を見てみます。 まずはsummaryから確認します。ほぼ答え通りのことを書いているので面白みはないですがCorrectness（正確さ）、Completeness（完全）が1になっていて期待通りの動きになっていることがわかります。 Helpfulness（有用性）のみ0.83という数字ですが評価コメントを確認すると 解答は特に興味深いものでも、予想外のものでもないが、この文脈ではそうである必要はない。 文脈がこれである必要はないということがスコアを下げている原因なのではないかと考えられます。 最後に 弊社内でもBedrock含め生成AIの活用が進んできており実際に利用シーンも増えてきています。今後も様々な機能に触れながらプロジェクトの要件を満たせるよう準備を進めていきたいです。このブログが少しでも参考になればうれしいです。

Hello! This is Guo from KINTO Technologies’ Generative AI Utilization Project. How does your company manage AWS resources? Several options are available, including Terraform, the AWS CLI, or manual operations through the AWS Console. This time, I harnessed the capabilities of generative AI to develop a system that allows you to manage AWS resources using natural language commands directly in Slack. The backend utilizes Agents for Amazon Bedrock (hereafter referred to as "Bedrock") to handle resource management seamlessly. System overview The overall structure is shown in the diagram below. System overview How it works Users enter natural language commands in Slack, and the backend, powered by Bedrock, processes these commands to create or delete S3 buckets. How it works Steps to create the system The system can be built in three steps: Create an Agent on Bedrock Set up AWS Chatbot Configure Slack Below, I’ll explain each step in detail. By following these steps, you’ll be able to build the same system yourself, so please give it a try! 1. Create an Agent on Bedrock Open the Bedrock Management Console. Click “Agents” in the left menu. Click “Create Agent” Enter a name and click “Create” You will be taken to the Agent Builder screen. Select a model, such as Claude 3 or Sonnet (you can choose any model you prefer) . Click “Save and Exit” in the top-right corner. Click “Prepare” on the right side. A message saying "Successfully prepared" will appear. Adding an Action Group. Click "Add" in the upper right corner of the Action Groups section. Configure the Action Group. ・Enter an Action Group Name. ・Set the Action Group Type to "Define using function details". ・Under “Specify how to define the Lambda function", select "Quickly create a new Lambda function (recommended)" ・For the Action Group Invocation, choose recommended option: "Quickly create a new Lambda function (recommended)" Adding and configuring Action Group Functions ・ Create the following Action Group Functions: “delete-ai-agent-gu-function" and "create-ai-agent-gu-function" ・Configure each function in the “Description (optional) field as follows: "delete S3 bucket posted bucket name" and "create S3 bucket posted bucket name" ・Add a parameter as following. The name should be bucket_name, the description should be S3 bucket name, the type should be String, and the mandatory value should be True. Adding Instructions for the Agent ・ Open the Agent edit screen and enter the following in the “Agent Instructions” field: You are an agent working with an S3 bucket. Use the appropriate functions to create or delete S3 buckets based on user requests. Task 1: If a user submits a request such as "Please create an S3 bucket named test-gu," trigger the Lambda function named create-ai-agent-gu-function Task 2: If the user requests something like “Please delete an S3 bucket named test-gu,” execute the Lambda function named delete-ai-agent-gu-function. Creating Lambda Functions Access the Lambda console. Since the option to quickly create a new Lambda function was selected, dummy lambda function has been automatically created. Add the code for creating and deleting S3 buckets to dummy_lambda.py import json import boto3 AWS_REGION = "ap-northeast-1" s3Client = boto3.client("s3",region_name=AWS_REGION) location = {"LocationConstraint":AWS_REGION} def lambda_handler(event, context): agent = event["agent"] actionGroup = event["actionGroup"] function = event["function"] parameters = event.get("parameters", []) # Execute your business logic here. For more information, # refer to: https://docs.aws.amazon.com/bedrock/latest/userguide/agents-lambda.html bucket_name = next(item for item in parameters if item["name"] == "bucket_name")["value"] if function == 'delete-ai-agent-gu-function': bucket_instance=s3Client.delete_bucket(Bucket=bucket_name) responseBody = { "TEXT": { "body": f"Instance Deleted: {str(bucket_instance)}" } } elif function == 'create-ai-agent-gu-function': bucket_instance=s3Client.create_bucket(Bucket=bucket_name, CreateBucketConfiguration=location) responseBody = { "TEXT": { "body": f"Instance Created: {str(bucket_instance)}" } } action_response = { "actionGroup": actionGroup, "function": function, "functionResponse": { "responseBody": responseBody }, } function_response = {"response": action_response, "messageVersion": event["messageVersion"]} print(f"Response: {function_response}") return function_response Extract the function value from the event dictionary and route the process to the corresponding predefined action group function, either create-ai-agent-gu-function or delete-ai-agent-gu-function. Grant the Lambda function permissions to manage S3 buckets by attaching the required policies to its execution role. Click Deploy (Ctrl+Shift+U) on the left side. Return to the Agent page, click “Create Alias” at the top. Enter an “Alias Name,” and click “Create Alias.” The alias will be created. This completes the agent setup. 2. Set up AWS Chatbot Open the Chatbot configuration page in the AWS Console. Click "Set up a new client." Select “Slack” as the chat client, and click "Configure." Authorize AWS Chatbot to access your Slack workspace Return to the Chatbot configuration page and click “Set up new channel.” Enter the Configuration Name and Channel ID. For permissions, follow these steps: Specify the IAM Role Name. Attach the AmazonBedrockFullAccess policy to the Channel Guardrail Policy. (For production environments, ensure to adhere to the principle of least privilege.) Click Save in the bottom-right corner. Click the link for the added configuration (in this case, ktc-gu-test). Click the link for the channel role. In the permission policy, click “Add permissions” and select “Attach Policies” Search for "AmazonBedrockFullAccess," select it from the list, and click "Add permissions." This completes the AWS Chatbot setup. 3. Configure Slack Finally, let’s configure Slack. Send the following message in the Slack channel: @aws connector add {Connector Name} {Bedrock agent's Agent ARN} {Bedrock agent's Alias ID} Once the connection is successful, the following message will appear. This completes the Slack setup. Now, let's test the system. System Verification: Enter an S3 operation command in Slack. Enter an operation command like this: @aws ask {Connector Name} {Prompt} S3 bucket creation and deletion should now work successfully! Summary In this demonstration, we showcased how to utilize AWS's generative AI agent service, Agents for Bedrock, to enable S3 bucket creation and deletion solely through natural language input. This approach demonstrates how various operations can now be executed effortlessly using natural language commands. Thank you, and see you next time!

この記事は KINTOテクノロジーズアドベントカレンダー2024 の19日目の記事です🎅🎄 学びの道の駅の中西です。今年は学びの道の駅プロジェクトが立ち上がり組織化されました。そんな中、社内Podcastの運営も行っており、今年のアドベントカレンダーではその内容もお届けしたいと思います。 「学びの道の駅」とは？ 「学びの道の駅」は、社内で頻繁に開催される勉強会をもっと便利に、そして効果的に活用するために立ち上げられたプロジェクトです。社内の有志が中心となり勉強会の開催を支援し社内の知識共有を促進することを目的としています。 WWDC参加報告 KTC学びの道の駅ポッドキャストでは、社内の勉強会を開催している方にインタビューを行っています。その名も「突撃！となりの勉強会」。本日はいつもと趣旨を変えて先日WWDCに現地参加された仲野さんにインタビューを行います。現地でWWDCに参加して持ち帰っていただいた刺激を聞いている皆さんにもお届けできれば幸いです。 インタビュー 明田さん: 本日はWWDCに現地参加された仲野さんにお越しいただきました。よろしくお願いします。 仲野さん: よろしくお願いします。 明田さん: 最初に、仲野さんが普段どんな仕事をされているのか自己紹介をお願いします。 仲野さん: モバイルアプリ開発グループで「KINTOかんたん申し込みアプリ（以降、申し込みアプリ）」のプロダクトマネージャーをしています。仕事の内容としては、申し込みアプリの開発や、Web側のKINTO ONEの新車の方と同期するケースがあるので、毎週のミーティングに参加してキャッチアップしています。また、仕事以外ではKTCの中で司会業などもよくやっています。 明田さん: ありがとうございます。仲野さんは社内でも顔が広いという印象がありますね。では、WWDCに参加したきっかけについて教えてください。 仲野さん: 申し込みアプリがモバイルアプリのサービスなので、リリース時にはAppStoreの審査が必要です。WWDCはApple Developer Programに紐づくアカウントを持っている人が応募できるので、社内で行きたい人がいたら申し込んでみてということで、私も応募しました。前職でもiOSエンジニアをしていて、同じくアカウントを持っていましたが、その時は残念ながら受からず、今回は嬉しいことに当たったので行くことができました。 明田さん: 参加するための費用を勝ち取るのは大変でしたか？ 仲野さん: そうですね、実は受かったとわかった後にどうするかマネージャーに相談しました。最終的には小寺さんに話を持って行くことになり、資料を作って提出し、承認いただけました。運が良かったのと、会社がウェルカムな環境だったのも大きいかもしれません。 明田さん: WWDCに行ってからのエピソードで、他のところで話していないことがあれば教えてください。 仲野さん: WWDCはApple Parkで開催され、その中庭はカリフォルニアの植物で揃えられているみたいでした。果物の木もあり、社員は取らないようにといわれていたり、デベロッパーリレーションの方がトリビアを話してくれたりと、面白かったです。例えば、外周と内周を回るのにどれくらいかかるかなどの話もありました。 明田さん: エンジニアやテックの開発者とコミュニケーションを取った中で得られた学びはありましたか？ 仲野さん: はい、エンジニアと触れ合う機会があり、どんなアプリをお互い開発しているのかを共有したりしました。個人でもアプリを作っている人や、メインの仕事はソフトウェアエンジニアではないけど趣味でアプリを作っている人も多かったです。Apple Parkに来ることでモチベーションが上がったという人がたくさんいました。 明田さん: 参加したことを通じて、アプリの開発や業務にプラスになったことはありますか？ 仲野さん: 直接アプリのコンサルを受けることができ、いくつかの課題に対してアドバイスをもらいました。その結果、アプリのUIやUXを改善する方向で進めています。次のリリースではそのアドバイスを反映したものを出す予定です。 明田さん: 英語に自信がない方でもWWDCに参加できますか？ 仲野さん: 全然問題ないと思います。英語はできた方がいいですが、ノリでいけると思います。Uberで目的地に移動するので、アプリで目的地を指定するため特に困りませんでした。英語ができるに越したことはありませんが、参加する気持ちがあれば大丈夫です。 明田さん: 最後に、これを聞いている皆さんに対して一言お願いします。 仲野さん: 今回の経験を通じて、海外カンファレンスに行って情報収集することの意義を感じました。KTCをもっと良い方向に持っていくために、ぜひ皆さんもチャレンジしてみてください。熱意があればきっと通ると思います。 明田さん: ありがとうございました。仲野さんでした。

Introduction This article shares insights and mindsets I have found valuable as a new leader. It’s written from my personal experience and intended for those transitioning into a leadership role or who have recently started navigating this path. In November 2023, I was assigned my first team leadership role at KTC (KINTO Technologies). Until then, I had virtually no prior experience in leadership, not even in my previous jobs. To make up for this lack of experience, I started studying “leadership and management mindsets” through books, web articles, and advice from my supervisors as soon as the assignment was confirmed. It would have been great to introduce everything I learned comprehensively. Still, some concepts felt too advanced, obvious, irrelevant to my current role, or simply unappealing. Rather than forcing these ideas on myself, I left them for future opportunities when they might resonate more. In this article, I’ll share eight ideas I’ve successfully “installed” into my current mindset. Although this is far from exhaustive, I hope some of these tips will provide helpful hints for your leadership journey. Collective Hunting and Sharing the Mammoths Some say that an organization’s greatest benefit is the sense of unity among its members. While truth exists, it is more of a secondary advantage. A group that hunted mammoth likely bonded over the shared experience of dividing the meat. The camaraderie was a byproduct as the meat took priority. Kodai Ando, The Mask of Leadership: A Mindset Shift from Individual Contributor to Manager The first book I picked up after being assigned the role of team leader was The Mask of Leadership . At first, I imagined leadership as something like "motivating team members" or "connecting with them on a deeper level." However, I vividly remember being struck by the pragmatic and somewhat cold approach of “Shikigaku” (a theory of organizational behavior). Among its many ideas, I was particularly impressed by the concept that individuals benefit only after the collective benefit is achieved. The correct order is this: First, the group achieves collective benefits. Then, individuals gain their share of those benefits. This perspective resonated with me immediately and has become one of the guiding principles for my leadership approach. Management Roles are "Goal Achievement" and "Group Maintenance" There are various perspectives on how to approach these roles, but one relevant framework is the "PM Theory," which highlights two core functions: performance and maintenance. First, the performance function is about achieving goals. It emphasizes the importance of setting and meeting objectives. On the other hand, the maintenance function is about group maintenance. This involves sustaining and energizing the team, ensuring its cohesion and vitality. An article titled Why Are Middle Managers Perpetually Overburdened? Common Pitfalls and Four Steps to Rebuild Management , highlights several challenges faced by managers. It is noted that environmental and societal changes have made both goal achievement and group maintenance increasingly difficult. The article points out that, recently, too much emphasis has been placed on group maintenance, which has hindered the development of managers capable of strategic planning and achieving goals. However, putting aside those difficult things, I was able to simply take the frame that “the job of a manager is to achieve goals and maintain the group.” I was able to clarify what I should do as a manager, which was good in terms of my mental health. Communicate the Purpose and Delegate the Method Some managers perceive their staff’s trial-and-error efforts as a “loss” and try to speed things up by teaching the “right answers” from the start or giving step-by-step instructions. This mindset is absolutely wrong. People only grow through experience. An organization that simply provides answers will ultimately slow down. Without the growth of its members, the organization’s overall speed and efficiency decline over time. Kodai Ando, The Mask of Leadership: A Mindset Shift from Individual Contributor to Manager For those who are capable, simply communicate the purpose and leave the rest to them For those who are slightly inexperienced, provide the purpose along with actionable hints, like “If it were me, I would do it this way.” And for those who are still immature, communicate both the purpose and the specific actions needed. Shu Yamaguchi, Project Management Taught by Foreign Consultants Micromanagement is generally a poor approach. I have understood this intuitively for some time, but I also recognized from my very first day as a team leader that I simply do not have the capacity to sustain micromanagement. Instead, I am constantly seeking non-micromanagement approaches. My aim is to clearly define the desired outcome and the requirements for success, then delegate the rest to my team members. At the same time, I support them as needed to ensure they can move forward independently. If I Enjoy the Work, It Doesn’t Feel Like a Burden. If I enjoy the work, it doesn’t feel like a burden. It varies from person to person, and isn’t something that can be measured by volume alone. Understanding what kinds of tasks each member enjoys can be incredibly helpful. It’s good to properly manage tasks and workload, but it often lacks significant impact relative to the effort it requires. I once sought advice from my manager about understanding team members’ workload capacity. When I asked, "Should I track everyone’s tasks in detail to understand their workload better?" The response to the question was insightful: "You can, but it’s not worth the effort. Instead, focus on understanding what each person likes and dislikes, and allocate tasks accordingly.” This advice stuck with me. While I do monitor working hours and assign tasks based on individual responsibilities, I’ve also started paying attention to whether the work aligns with each person’s preferences. Managing tasks in overly fine detail often takes up time on non-essential aspects, such as aligning things for visibility or rationalization. I also felt that I lacked the capacity to manage everything at such a granular level. So, I decided not to pursue that approach. Instead, I now assign work based on each member’s area of responsibility while keeping the perspective of “Am I assigning tasks in line with their preferences?” in mind. Creating Exceptions, Like Allowing a Car to Speed through an Intersection at 60 km/h Exceptions can make a team or organization incredibly fragile. If you let even one car run a red light because it’s in a hurry, the entire road system will descend into chaos. Kodai Ando, The Mask of Leadership: A Mindset Shift from Individual Contributor to Manager How many members on your team can you trust to “follow the rules 100%”? Whether it’s meeting deadlines, processing data at the start of the month, escalating issues, or sharing files, workplace rules exist for a reason. If trust is lacking, what happens? Someone ends up covertly monitoring tasks, reminding others, or even correcting mistakes behind the scenes. This reliance on manual intervention hinders team autonomy and efficiency. Decoupling Work: Experts in Loosely Coupled Systems (Practical Edition 3) | RINARU To improve workflow efficiency, I aim to create system where tasks can be completed independently, without requiring constant confirmation. Having even one uncertain step can lead to errors or delays. If it is certain, there is no need to confirm. Establishing clear rules—and ensuring that everyone trusts these rules will be followed—is crucial. While overly rigid rules can hinder the value we aim to deliver, establishing a solid framework is crucial. I focus on setting clear and basic guidelines to provide a reliable foundation for our work. Constants, Variables, and "Variables Close to Constants" Both Professor Hayashi and Mr. Morioka emphasized the importance of identifying constants and variables and focusing on changing variables. This means dedicating your time and energy to things you can influence. "Moving Variables, Not Constants" I learned about this concept during a company meeting where my manager shared it with the team. Observing other managers around me, I’ve noticed that they don’t simply fight against the flow. Instead, they assess the dynamics at play and create conditions where things naturally align with their goals. What stood out most from the manager’s insights was that some variables may currently appear close to constants. What’s important is the ability to make this distinction. This includes aspects such as company culture, policies, and people’s mindsets. These may appear unchangeable and resistant to effort, but it’s important to remember that they are variables that can be shifted over time. People Tend to Forget If They’re Told Only Once Team members find it harder to work with a manager who is “hard to understand” rather than one who is simply “incompetent.” Even critical information, if communicated just once, can get lost in the daily flood of information. 　 "The Leader's Communication Skills" That Eliminate Waiting for Instructions The key is to guide team members to repeatedly return to the project’s purpose during their decision-making process. When a team member asks a question, respond with another question that leads them back to the project’s purpose. By doing this, team members will gradually develop the habit of consistently grounding their decisions in the project’s goals whenever they face uncertainty. Shu Yamaguchi, Project Management Taught by Foreign Consultants I tend to be forgetful myself, and there have been many times when someone has said to me, “I already told you,” leaving me frustrated. Conversely, when someone forgets something I’ve said, I believe that communication is not just an individual issue but a shared responsibility between the two parties. If didn’t communicate effectively enough for the other person to remember, I bear part of the responsibility. When it comes to sharing thoughts and ideas I want to convey, it seems best to repeat them frequently, to the point of saying them at every opportunity. Cheerful Leaders and Grumpy Leaders Edmondson defines psychological safety as "a climate in which people feel safe to take interpersonal risks, such as speaking up with ideas, questions, or concerns.” Why "Psychological Safety" Continues to Cause Confusion | Q by Livesense When the flow of information within a team decreases, projects almost inevitably fall into danger. When the sender of information cannot anticipate how the recipient will react, the overall volume of information exchanged drops. Ultimately, teams led by cheerful leaders see an increase in the flow of information, both between members and between the leader and the team. Shu Yamaguchi, Project Management Taught by Foreign Consultants Based on my experience working with many younger co-workers and staff, I can summarize “how to motivate everyone” in one sentence. Leaders must work more seriously and happily than anyone else. There is no better way to inspire and nurture the members. Noriyuki Sakuma, Noriyuki Sakuma's Unfair Work Technique—How I Did What I Wanted without Burning out at Work Simply put, when your boss is in a bad mood, it creates an awkward atmosphere, making it hard for team members to focus (at least for me). That’s why I always try to maintain a cheerful attitude and create an environment where it’s OK to say anything. Of course, I’m not always genuinely in a good mood, and pretending to be cheerful when I’m not can be draining. If you see a leader or manager struggling, take a moment to acknowledge and appreciate their efforts. Conclusion How was it? I hope you found some ideas here that could be useful in your work. At KTC, being a leader doesn’t mean you’re superior or more skilled than others. It’s simply a function or role that can be assigned or removed based on what’s best for the organization and its current situation. On the other hand, if the leader is just a function, then the members are also just functions. Ultimately, success lies in teamwork. It’s not enough for individual members to simply take action, nor for the leader to handle everything alone. What truly matters is the team's ability to face challenges and overcome them together. Let's take it easy and do our best!

この記事は KINTOテクノロジーズアドベントカレンダー2024 の19日目の記事です🎅🎄 学びの道の駅の中西です。今年は学びの道の駅プロジェクトが立ち上がり組織化されました。そんな中、社内Podcastの運営も行っており、今年のアドベントカレンダーではその内容もお届けしたいと思います。 「学びの道の駅」とは？ 「学びの道の駅」は、社内で頻繁に開催される勉強会をもっと便利に、そして効果的に活用するために立ち上げられたプロジェクトです。社内の有志が中心となり勉強会の開催を支援し社内の知識共有を促進することを目的としています。 WWDC参加報告 KTC学びの道の駅ポッドキャストでは、社内の勉強会を開催している方にインタビューを行っています。その名も「突撃！となりの勉強会」。本日はいつもと趣旨を変えて先日WWDCに現地参加された仲野さんにインタビューを行います。現地でWWDCに参加して持ち帰っていただいた刺激を聞いている皆さんにもお届けできれば幸いです。 インタビュー 明田さん: 本日はWWDCに現地参加された仲野さんにお越しいただきました。よろしくお願いします。 仲野さん: よろしくお願いします。 明田さん: 最初に、仲野さんが普段どんな仕事をされているのか自己紹介をお願いします。 仲野さん: モバイルアプリ開発グループで「KINTOかんたん申し込みアプリ（以降、申し込みアプリ）」のプロダクトマネージャーをしています。仕事の内容としては、申し込みアプリの開発や、Web側のKINTO ONEの新車の方と同期するケースがあるので、毎週のミーティングに参加してキャッチアップしています。また、仕事以外ではKTCの中で司会業などもよくやっています。 明田さん: ありがとうございます。仲野さんは社内でも顔が広いという印象がありますね。では、WWDCに参加したきっかけについて教えてください。 仲野さん: 申し込みアプリがモバイルアプリのサービスなので、リリース時にはAppStoreの審査が必要です。WWDCはApple Developer Programに紐づくアカウントを持っている人が応募できるので、社内で行きたい人がいたら申し込んでみてということで、私も応募しました。前職でもiOSエンジニアをしていて、同じくアカウントを持っていましたが、その時は残念ながら受からず、今回は嬉しいことに当たったので行くことができました。 明田さん: 参加するための費用を勝ち取るのは大変でしたか？ 仲野さん: そうですね、実は受かったとわかった後にどうするかマネージャーに相談しました。最終的には小寺さんに話を持って行くことになり、資料を作って提出し、承認いただけました。運が良かったのと、会社がウェルカムな環境だったのも大きいかもしれません。 明田さん: WWDCに行ってからのエピソードで、他のところで話していないことがあれば教えてください。 仲野さん: WWDCはApple Parkで開催され、その中庭はカリフォルニアの植物で揃えられているみたいでした。果物の木もあり、社員は取らないようにといわれていたり、デベロッパーリレーションの方がトリビアを話してくれたりと、面白かったです。例えば、外周と内周を回るのにどれくらいかかるかなどの話もありました。 明田さん: エンジニアやテックの開発者とコミュニケーションを取った中で得られた学びはありましたか？ 仲野さん: はい、エンジニアと触れ合う機会があり、どんなアプリをお互い開発しているのかを共有したりしました。個人でもアプリを作っている人や、メインの仕事はソフトウェアエンジニアではないけど趣味でアプリを作っている人も多かったです。Apple Parkに来ることでモチベーションが上がったという人がたくさんいました。 明田さん: 参加したことを通じて、アプリの開発や業務にプラスになったことはありますか？ 仲野さん: 直接アプリのコンサルを受けることができ、いくつかの課題に対してアドバイスをもらいました。その結果、アプリのUIやUXを改善する方向で進めています。次のリリースではそのアドバイスを反映したものを出す予定です。 明田さん: 英語に自信がない方でもWWDCに参加できますか？ 仲野さん: 全然問題ないと思います。英語はできた方がいいですが、ノリでいけると思います。Uberで目的地に移動するので、アプリで目的地を指定するため特に困りませんでした。英語ができるに越したことはありませんが、参加する気持ちがあれば大丈夫です。 明田さん: 最後に、これを聞いている皆さんに対して一言お願いします。 仲野さん: 今回の経験を通じて、海外カンファレンスに行って情報収集することの意義を感じました。KTCをもっと良い方向に持っていくために、ぜひ皆さんもチャレンジしてみてください。熱意があればきっと通ると思います。 明田さん: ありがとうございました。仲野さんでした。

この記事は [KINTOテクノロジーズアドベントカレンダー2024](https://qiita.com/advent-calendar/2024/kinto-technologies) の19日目の記事です🎅🎄 1. Tech Blog デビュー こんにちは！ 生成AI活用PJTのShiori（ @shor_t8q ）です。現在、生成AIの研修・ユースケース開発・技術支援を担当しています！（が、デビュー作はWeb3の内容となりました） このブログは2024/11/28に開催されたKINTOテクノロジーズ超本部会（＝会社の全体会）の懇親会のNFT活用企画についての記事です。会社総会の企画やNFTの取り組みについて関心のある方、KINTOテクノロジーズの会社文化を知りたい方に最適な内容となっています。 前提 このブログで紹介するNFT企画は、超本部会の実行委員、懇親会、ノベルティ、クリエイティブ室メンバーの全員のご協力と尽力により実現できた内容です。 また、この記事で取り扱うNFTサービスの提供企業のスポンサー記事ではありません。あくまで懇親会＆ノベルティ担当の体験、工夫、学び、教訓を共有することを目的としています。 2. 超本部会について  2-1. そもそも超本部会とは？ 超本部会とは、KINTOテクノロジーズが年に1・2回程度開催している会社の全体会です。このブログで取り上げる超本部会は、2024/11/28に開催され、2024/11/28の開催規模はオフラインで300名程度、オンラインで50名程度です。時間は、15時〜21時まで開催され、コンテンツ盛りだくさんの大盛り上がりの会となり、幕を閉じました。 2-2. 懇親会とノベルティ担当になる 超本部会の1.5ヶ月前に、各部のグループからメンバーが集い、実行委員会が結成され、私は懇親会とノベルティを担当しました。  社内のコミュニケーション促進を目的に、デスク用のネームプレートをノベルティとしました。ノベルティはクリエイティブ室のJさんがデザインしました。 2-3. 超本部会のコンセプト コンセプトは、「KTCはキミで、できている」です。このコンセプトは、経営陣 / 部長 / マネージャーの方からの、お気持ち、チームワーク、未来へのビジョンに関する意見をまとめて作成されました。  3. 超本部会の懇親会 3-1. 懇親会とは？ 懇親会は超本部会の一番最後の企画で19:00~21:00の超本部会の最後に開催されました。 超本部会のコンセプトを基に懇親会チームは懇親会ゴールを以下2つに定義しました。 参加者同士、他部署のメンバーとのコミュニケーションを促進する。 参加してよかったと思えるような体験を提供する。 3-2. 懇親会でNFTを活用することになったきっかけは？ 懇親会ではNFTスタンプラリーを実施しましたが、なぜ懇親会でNFTスタンプラリーを取り入れることにしたのでしょうか？私はもともとノベルティ担当だったですが、発想の起点は「まだやったことがなうことを試す」を前提とした時に「ノベルティがNFTだったら面白いのではないか？」、「今後のNFT・Web3プロジェクトのインスピレーションとなるのではないか？」と考えたところにあります。 そこで、本部会のコンセプトに沿ったNFT活用方法を模索し、Web調査をしたところ「NFTスタンプラリー」という概念があることがわかりました。その後実行委員メンバーから、前回の本部会の懇親会の企画で「デジタルスタンプラリー」という企画を実施したことを共有してもらい、「デジタルスタンプラリー」を「NFTスタンプラリー」にアップデートすることにしました。ここで懇親会メンバーと合流して、NFTスタンプラリー活用の検討に入りました。  4. NFTとは？ 4-1. NFTは唯一無二のデジタル資産 NFTとは「Non-Fungible Token」の略で、日本語では「非代替性トークン」と訳されます。これは、他のトークンと交換が不可能な、唯一無二のデジタル資産を指し、独自性と希少性の特徴を持っています。また、NFTはブロックチェーン技術により、取引の透明性が確保されます。例えば、ビットコインは1ビットコインが他の1ビットコインと同じ価値を持つ代替可能なトークンですが、NFTはそれぞれが異なる価値を持つため、代替することができません。  このような「非代替性トークン」特性から、NFTは、アート・ゲーム・音楽・映画・スポーツ・エンターテインメント、企業のマーケティング活動において新しいファンエンゲージメント向上施策ツールとして活用されており、その他の業界においてもNFTの応用が進んでいます。NFTはクリエイターの収益化の手段や企業の新たなマーケティング集団を提供し、取引の透明性とトレーサビリティを向上させる一方で、マイニング（採掘）に伴う多くの消費電力による環境への影響や法的リスク、市場のボラティリティによる価値としての不安定さなどの課題があります。 5.NFTスタンプラリー 5-1. 懇親会でのNFTスタンプラリーの実現可能性は？ 調査実施 そもそも会社の懇親会でNFTを配布したり、交換したりすることは実現可能なのか、検証することにしました。 ウェブ調査の結果、 Sushi Top Marketing という企業がNFTで多くの活用事例があり、NFTスタンプラリーの実績を持っており、トークングラフマーケティングという新しいNFTの概念を提案しているということがわかりました。 トークングラフマーケティングとは？ トークングラフマーケティングは、ブロックチェーン技術を活用し、ユーザーのプライバシーを保護して顧客にアプローチ可能な新しいマーケティング手法です。ユーザーが所有するNFTやその他のトークン情報を基に、その人の趣味嗜好や行動履歴を分析できます。  引用元： トークングラフマーケティングとは？ 初期のアイディア そこで、以下のような初期アイディアをベースにご担当者の方と数回のディスカッションを行いました。 内容 説明 ノベルティコンセプト 普段会わない人とのコミュニケーションを活性化、 コミュニケーションの誘発とイノベーションの促進、団結意識、老若男女問わずもらって嬉しいなどです。 このコンセプトからはズレないようなソリューション。 アクセシビリティー イベントで一日のみ利用可能なため、 操作説明なしでだれでもすぐに利用できるような手軽さが重要。 アプリとQRスキャンの両方に対応しているなど。 ノベルティとしての価値 NFTを個人のウォレットに送金し、 資産として保存できるというような新しいノベルティの概念を伝えたい。 革新性 会社はクリエイティブとテクノロジーを重要な価値基準としており、 まだやったことのない技術的チャレンジに積極的。 ブランド ブランドのキャラクターやカラーを反映したUIにカスタマイズできると嬉しい。 利用イメージ 例えば、「部署ごとに違うスタンプを所有しており、Aさんが違う部署のBさんと話すと、 Bの部署のスタンプをもらうことができて6個のスタンプを集めることを目指す」などの企画は、コミュニケーションを促進できて面白いのではないか。 5-2. NFTスタンプラリーの基盤となるブロックチェーン技術 今回のNFTスタンプラリーでは、Astarを採用しました。Astarは、次世代のブロックチェーン技術として注目されており、スマートコントラクトとdApp（分散型アプリケーション）の開発に特化した技術です。 Astar は、 Polkadot エコシステムの一部であり、異なるブロックチェーン間の相互運用性を実現することができます。  5-3. NFTスタンプラリーの構想 アイディアブレスト 4つのNFTスタンプラリーアイディアをご提案いただきました。 内容 説明 NFTカード交換 複数のNFTカードを交換し合ってお互いにNFTを取得。NFT配布後に、別のNFTを届けることも可能。 動的NFTスタンプラリー 任意のNFTペアを集めると、特別なNFTに変化する仕組み。NFTの組み合わせで、ユニークなNFTを配布可能。 LINEでのNFT配布 LINE公式から記念NFTを配布し、NFT配布後に、記念NFT保持者にギフトを送付。 NFT名刺＆スタンプラリー NFCまたはQRスキャンでNFTが発行できるカードを配布し、スタンプラリーを実施。ノベルティとしての価値を持ちつつ、参加者の収集意欲を刺激。 アイディアを踏まえ、以下の判断基準を基に懇親会メンバーでディスカッションを重ね、アイディアをブラッシュアップしました。 判断基準 内容 説明 工数 約1ヶ月で準備が完了するか。 ユーザビリティ マニュアルや説明が不要、もしくは最小限で、直感的に利用できるか。 運用可能性 300人が集まる懇親会のような自由な雰囲気の中でも運用が可能か。 簡便性 複雑な操作や手順を必要とせず、簡単に利用できるか。 アクセシビリティ 外部サービス利用前提などの制限なく、誰でもアクセスできるか。 先進性 NFTを活用した興味深い体験を提供できるか。 セキュリティ データの保護やプライバシーを確保できるか。 スケーラビリティ 多数のユーザーの同時アクセスに対応可能か。 互換性 スマホデバイスやOS互換性があるか、既存のWeb3プラットフォームと統合可能か。 予算適合性 予算内に収まるか。 最終的に、初期アイディアを組み合わせ次のような企画になりました。 5-4. NFTスタンプラリーの企画内容 NFTスタンプラリーの概要 NFTは、各部署、経営陣、コンプリート用を含め全部で14種発行しました。 参加者が、ゾーン（経営陣や表彰メンバーなどが滞在するスポット）を巡り、懇親会中に自身の持つNFTとは異なるNFTを収集し、普段話す機会が少ない他部署メンバーや経営陣とコミュニケーションを取ることで、新しいプロジェクトのスタートや関係構築を促進します。 全てのNFTを収集すると、コンプリートNFTを取得でき、後日景品と交換できるゲーミフィケーション要素を取り入れました。 NFTのタッチポイント 名札（超本部会の参加者全員が入口で名札を受け取る）にNFCタグ（後ほど解説）とQRコードを入れ、NFCタップとQRのスキャンの両方からNFTを獲得できるようにします。NFCとQRの両方を準備した背景には、NFCタップが利用できない参加者が発生する事態を考慮するためです。 NFTスタンプラリーの流れ 参加者は各ゾーンへ行く メンバー（他部署や経営陣）と交流 NFTに紐づくチャットに、どのような内容を話したのか投稿する（NFTに紐づくチャットに、部署のメンバーとどのような会話をしたのか共有することで、各部署のNFTのユニークな価値にする） 会話をしたメンバーとNFTを交換し、13個のNFTを収集する コンプリートNFTを獲得する コンプリートNFTに紐づくチャットに、Slackの名前を投稿する 後日運営がSlack経由でコンプリートNFTメンバーに景品をプレゼントする NFTデザイン NFTのデザインは、会社の全体会であることを考慮し、統一感や一体感を出すために、KINTOブランドキャラクターであるくもびぃを採用しました。  クリエイティブ室の桃井さんがNFTコレクションをデザインしました。 NFTの工夫 NFTにオリジナルな価値を付与します。 部署ごとに異なるデザイン NFT名はグローバルメンバーを考慮した日英併記 NFTにユニークなコレクション名や開催日の日付属性を追加 各NFTごとに超本部会のテーマ「KTCはキミで、できている」キーワードを仕込み、全てのNFTを集めると懇親会テーマになる # 6. NFTスタンプラリーを実現する上での課題 6-1. NFTをどのように交換するのか？チャネルは？採用技術は？ NFT x NFCタグを採用 今回の懇親会の要素として、「そんなこともできるんだ！」といったようなちょっとした驚きや発見も重要視していました。そこで、サービス提供企業の方からいただいたアイディアと実行委員メンバーのアイディアを融合し、NFCタグにNFTの情報を書き込み、名札に入れたNFCチップにスマホをかざすだけで、NFTを受け取れるようにしました。 *NFC（Near Field Communication）とは、 対応する機器同士を近づけることで無線通信を行うことができる技術・規格 です。NFCは、スマートフォンや交通系ICカード、クレジットカード、家電など、幅広い用途で使用されています。 NFCタグにNFT情報をどのように書き込むのか？ NFCタグ： www.amazon.co.jp/dp/B0DFW9WTRW NFC書き込みアプリ： https://apps.apple.com/jp/app/nfc-tools/id1252962749 AmazonでNFCタグを調達し、13種約300人分のNFT URLをNECタグへ書き込みました。またNFCタグが機能しないことにも備えて300人分のNFT QRコードも準備しました。この工程はマンパワーです。（懇親会メンバーthytさん、岡さんが書き込みをしました。） 書き込んだNFCタグをネームホルダーに入れました。  6-2. NFTスタンプラリーのルールを参加者全員にどのように周知するのか？ NFTスタンプラリー開始前の司会の案内の時に「NFTスタンプラリー進め方ガイド」を投影し、司会と協力して、NFTスタンプラリーのルールを周知しました。  6-3. NFT交換はブラウザベースのウェブアプリ上で行うため、獲得したNFTを見失わないようにするには？ 司会と連携し、以下の内容を投影資料内で案内しました。 ブラウザで利用するウェブアプリであること シークレットモードでは利用しないこと NFTを最初に交換した後、「NFT一覧ページのショートカットをホーム画面に追加する NFT交換時に表示されるNFTのバックアップコードをスクショしておくこと 6-4. コンプリートNFTの発行方法は？ NFTをコンプリートしたら懇親会担当に獲得したNFT一覧画面を見せて、懇親会担当からコンプリートNFTを獲得できるようにしました。  7. 学びと教訓 7-1. 懇親会中に実行できるタスクはNFT交換のみ 懇親会中は、普段あまり話さないメンバーと沢山会ったため、ごはんを食べるのもやっとというような状況でした。そのため、当初想定していたNFTに紐づくチャットに、メンバーとの会話を共有することは難しく、「各部署のNFTに、部署メンバーの気付きやアイディアを蓄積し、各部署のNFTのユニークな価値にする」ということを実現するのは難しかったです。 また当初の企画では、ゾーン（経営陣や表彰メンバーなどが滞在するスポット）を巡ってNFTを交換することを想定していましたが、懇親会という自由なコミュニケーションを促進する場では、ゾーンを設置する必要ありませんでした。 7-2. 全種類のNFTを確認するオペレーションの工夫を 参加者からの意見として、任意のA部署メンバーのNFTを複数取得できるため、A部署のNFT1、A部署のNFT2、、、といったように同じデザインのNFTが一覧に表示され、「どの種類のNFTを獲得したのか、コンプリートまでにあとどのNFTを獲得する必要があるのか、確認するのが少し大変。」という声があり、この点は事前に考慮して対応策を検討していれば良かったポイントです。 7-3. NFTコンプリート後のタスクはシンプルに 「5-4. NFTスタンプラリーの企画内容」で企画想定した通りには上手く機能しませんでした。 この点は、「13種類のNFTを獲得→NFT一覧の画面をスクショしてSlackチャンネルで共有する」 といったSlackチャンネルでコンプリートを証明するオペレーションにした方が、懇親会担当は誰がコンプリートしたのかすぐに把握できるので、スムーズに機能したと思われます。 またSlackチャンネルなどのオープンなスペースでコンプリート報告をすることで、懇親会参加者が「同僚の〇〇さんがコンプリートした！」ということが人目でわかるので、NFTスタンプラリー参加促進の誘発要素にもなると考えられます。 7-4. NFTタッチポイントのチャネル選定は柔軟に 今回の懇親会では300人分のNFT URLをマンパワーでNFCへ書き込みました。しかし、人的ミスや工数を考慮すると、これ以上の大規模イベントでは別のタッチポイントやチャネルを検討した方が良いと考えられます。 7-5. 国際メンバー向けには英語でのフォローアップを KINTOテクノロジーズは約25％が国際メンバーです。投影資料は日英併記で準備しましたが、懇親会で複数人の国際メンバーと会話した際に、口頭でNFTスタンプラリーの進め方フォローアップを行いました。スタンプラリー開始時に、Slackチャンネルで投影資料を共有したり、英語での補足説明をするとさらにスムーズだったのはないかと思います。 8. NFTスタンプラリーの結果 8-1. 10％がコンプリート！！！ 約300人の参加中30人という、 参加者約10％がNFTスタンプラリーをコンプリート しました。  8-2. 全体の結果は・・？ 全体としては、 1734個 のNFTを配布し、一人あたりの NFT平均交換数6.6個 、 NFT交換数の中央値は6 になりました。つまり、約2時間で 1人当たり平均約6部署のメンバーと会話したこと になります。 懇親会で他部署メンバーとの交流をゴールの一つとしていたため、NFTスタンプラリーは、ゴール達成の一助になったと考えられます。 項目 数 NFTスタンプラリーコンプリート人数 30人 NFT発行総数 1734個 NFT平均交換数 6.6個 NFT交換数中央値 6個 9. NFT活用の展望 NFTスタンプラリーを活用することで、懇親会のような物理的なイベントにおける人の動きを可視化できることがわかりました。興味深いことに、今回のNFTスタンプラリーでは、どの部署がどのくらいのNFTを発行したかわかるので、他部署とのコミュニケーションに積極的な部署を把握することができました。 このNFTスタンプラリーを通して、KINTOテクノロジーズが手掛ける、KINTO製品、MaaS関連アプリ、会員向けサービスへのオンライン・オフラインでのNFT活用イメージが広がりました。具体的には、既存の年代や性別といった属性ではない、趣味嗜好ベースでのお客様へのアプローチが可能といったことや、お客様のコミュニケーションと行動の可視化という観点での活用が有効だと思いました。  10. 最後に NFTスタンプラリーの試みを通じて、新たな技術とアイデアの融合がもたらす可能性を実感しました。懇親会という場で、異なる部署のメンバーが交流し、楽しみながらテクノロジーに触れる機会を実現できたのは貴重な経験でした。今後も、新たな技術を活用した取り組みを積極的に行い、興味深い発見や洞察を共有できるよう努めていきたいと思います。 皆さんもぜひ、AIやWeb3など新たな技術を取り入れた企画に挑戦してみてください。何か面白い発見があると思います！ 最後までご覧いただきありがとうございました！

この記事は KINTOテクノロジーズアドベントカレンダー2024 の19日目の記事です🎅🎄 KINTO Technologiesのモバイルアプリ開発グループに所属しているiOSエンジニアのGOSEOです。今担当しているアプリはUnlimitedです。 UnlimitedのiOS担当者の66％は外国籍の方です。日々、外国籍のiOSエンジニアの方と英会話を楽しんでます。 Paradoxが好きで、クルセイダーキングスⅢに今ハマってます。 UnlimitedアプリにおけるGoogle MapsからMapKitへのマイグレーション検証 近年、Appleマップの性能向上により、Google MapsからMapKitへの移行が注目されています。この変更により、利用料の削減やアプリの評価向上が期待できます。 本記事では、UnlimitedアプリでGoogle MapsからMapKitへ移行した際の具体的な実装方法、直面した課題、そして検証結果について詳しく紹介します。 Google MapsからMapKitへのマイグレーション検証とその過程 1. マップの描画とグラデーションラインの生成 Unlimitedでは、Google Maps上にグラデーションラインを描画しています。これをMapKitで実現するには、 MKGradientPolylineRenderer を使い、カラーをセットして、開始地点と終了地点を locations で指定することで可能かどうか検証しました。さらに、将来的にはユーザーの超過スピードに応じてラインの色を動的に変化させる実装にも使えるのではと思いました。 func mapView(_ mapView: MKMapView, rendererFor overlay: MKOverlay) -> MKOverlayRenderer { if let polyline = overlay as? MKPolyline { let gradientRenderer = MKGradientPolylineRenderer(polyline: polyline) gradientRenderer.setColors( [Asset.Colors.primary.color, Asset.Colors.cdtRouteGradientLight.color], locations: [0.0, 1.0] ) gradientRenderer.lineWidth = 2.0 return gradientRenderer } return MKOverlayRenderer(overlay: overlay) } 2. タップ検知の違い Google Mapsでは、地図上でのタップやマーカーのタップイベントを簡単に取得できますが、MapKitにはそのためのAPIがありません。そのため、地図全体のタップ検知には UITapGestureRecognizer が必要でした。しかし、マーカーに対しては didSelect と didDeselect メソッドでタップ状態を把握できます。 マーカーをタップしたのか地図をタップしたのか制御しないのが厄介ですが.....タップ位置にマーカーが存在しているのか確認すれば大丈夫でした。 悩みポイント： 独自にジェスチャーを設定する必要があり、少し面倒ではありますが、なんとか動作は確認できました。 let tapGestureRecognizer = UITapGestureRecognizer(target: context.coordinator, action: #selector(context.coordinator.handleMapTap(_:))) tapGestureRecognizer.delegate = context.coordinator mapView.addGestureRecognizer(tapGestureRecognizer) 3. マーカーの追加と管理 Unlimitedの地図上には、複数種類のマーカーが重なり合う場面があるため、 zPriority を活用して優先的に表示する仕組みを取り入れました。同じマーカー画像のインスタンスを使い回すことでインスタンスをマーカーごとに生成しなくて済むのでパフォーマンス向上も実現できました。 課題： デフォルトのタップアニメーションが消えない... 試行錯誤した結果、MKAnnotationViewに画像を追加せずに、 MKAnnotationViewにUIViewをaddSubviewで追加し、UIImageViewをaddSubviewでUIViewに追加し、UIImageViewに画像を追加することで 、アニメーションを無効にするという方法にたどり着きました。 この解決策は、まさにチームメイトの天の声でした！ 4. レンダリングが遅い 大分から福岡まで走ったテスト走行データを投入して、マップ表示後、拡大縮小を繰り返すと、線のレンダリングが追いついていないバグがありました。座標位置データが23000個あり、地図の表示画面が切り替わるたびにレンダリングが発生していました。そのため、UIの更新においてメモリやCPUのリソース消費が激しくなっていました。。 課題： 座標位置が多いとレンダリングが追いつかない… Ramer-Douglas-Peuckerアルゴリズムを使って、類似している座標位置を削除し、ポリラインの簡略化と分割により、一本のポリラインに合体させる方法で乗り切れました。 // UIColorを補間する関数。fraction値に応じて2つの色の間を補間した色を返す func interpolateColor(fraction: CGFloat) -> UIColor { // 開始色と終了色のRGBAコンポーネントを取得 let fromComponents = Asset.Colors.primary.color.cgColor.components ?? [0, 0, 0, 1] let toComponents = Asset.Colors.cdtRouteGradientLight.color.cgColor.components ?? [0, 0, 0, 1] // fractionを基に色を補間 let red = fromComponents[0] + (toComponents[0] - fromComponents[0]) * fraction let green = fromComponents[1] + (toComponents[1] - fromComponents[1]) * fraction let blue = fromComponents[2] + (toComponents[2] - fromComponents[2]) * fraction return UIColor(red: red, green: green, blue: blue, alpha: 1) } // 座標の配列からポリライン情報を生成する関数 func makePolylines(_ coordinates: [CLLocationCoordinate2D]) -> [PolylineInfo] { // 座標が空の場合は空配列を返す guard !coordinates.isEmpty else { return [] } // チャンクのサイズを計算（最小でも全体を1チャンクとする） let chunkSize = coordinates.count / 20 > 0 ? coordinates.count / 20 : coordinates.count var cumulativeDistance = 0.0 let totalDistance = coordinates.totalDistance() // 全体の距離を計算 var previousEndColor: UIColor = Asset.Colors.primary.color var previousEndCoordinate: CLLocationCoordinate2D? var polylines: [PolylineInfo] = [] // 座標をチャンクに分割し、各チャンクに対して処理を実行 let chunks = stride(from: 0, to: coordinates.count, by: chunkSize) .map { startIndex -> [CLLocationCoordinate2D] in // チャンクの座標を取得し、前のチャンクの最後の座標を追加 var chunk = Array(coordinates[startIndex..<min(startIndex + chunkSize, coordinates.count)]) if let lastCoordinate = previousEndCoordinate { chunk.insert(lastCoordinate, at: 0) } previousEndCoordinate = chunk.last return chunk } for chunk in chunks { let chunkDistance = chunk.totalDistance() // チャンクの距離を計算 let startFraction = cumulativeDistance / totalDistance // 開始点の割合を計算 cumulativeDistance += chunkDistance let endFraction = cumulativeDistance / totalDistance // 終了点の割合を計算 let startColor = previousEndColor let endColor = interpolateColor(fraction: CGFloat(endFraction)) // 終了色を補間で計算 previousEndColor = endColor // ポリラインを簡略化（高精度を維持しつつポイントを削減） let simplified = PolylineSimplifier.simplifyPolyline(chunk, tolerance: 0.00001) let polyline = MKPolyline(coordinates: simplified, count: simplified.count) // ポリライン情報をリストに追加 polylines.append(PolylineInfo( polyline: polyline, startFraction: startFraction, endFraction: endFraction, startColor: startColor, endColor: endColor )) } return polylines } // 座標を簡略化する関数（Ramer-Douglas-Peuckerアルゴリズムを実装） static func simplifyPolyline(_ coordinates: [CLLocationCoordinate2D], tolerance: Double) -> [CLLocationCoordinate2D] { // 座標数が2以下、またはtoleranceが0未満の場合はそのまま返す guard coordinates.count > 2 else { return coordinates } guard tolerance >= 0 else { return coordinates } var result: [CLLocationCoordinate2D] = [] var stack: [(startIndex: Int, endIndex: Int)] = [(0, coordinates.count - 1)] var include: [Bool] = Array(repeating: false, count: coordinates.count) include[0] = true include[coordinates.count - 1] = true // スタックを使用して再帰的に処理 while !stack.isEmpty { let (startIndex, endIndex) = stack.removeLast() let start = coordinates[startIndex] let end = coordinates[endIndex] var maxDistance: Double = 0 var currentIndex: Int? // 現在のラインに対して最も遠い点を探す for index in (startIndex + 1)..<endIndex { let distance = perpendicularDistance(point: coordinates[index], lineStart: start, lineEnd: end) if distance > maxDistance { maxDistance = distance currentIndex = index } } // 最も遠い点がtoleranceを超える場合、その点を含めて再分割 if let currentIndex, maxDistance > tolerance { include[currentIndex] = true stack.append((startIndex, currentIndex)) stack.append((currentIndex, endIndex)) } } // includeがtrueの座標だけを結果に追加 for (index, shouldInclude) in include.enumerated() where shouldInclude { result.append(coordinates[index]) } return result } // 点と線の間の垂直距離を計算する関数 private static func perpendicularDistance(point: CLLocationCoordinate2D, lineStart: CLLocationCoordinate2D, lineEnd: CLLocationCoordinate2D) -> Double { let x0 = point.latitude let y0 = point.longitude let x1 = lineStart.latitude let y1 = lineStart.longitude let x2 = lineEnd.latitude let y2 = lineEnd.longitude // 距離の計算式（2次元平面での点と直線の距離） let numerator = abs((y2 - y1) * x0 - (x2 - x1) * y0 + x2 * y1 - y2 * x1) let denominator = sqrt(pow(y2 - y1, 2) + pow(x2 - x1, 2)) // 直線の長さが0の場合は距離を0とする return denominator != 0 ? numerator / denominator : 0 } 5. 検証結果と結論 MapKitでもUnlimitedアプリでGoogle Mapsを使用して実装されている同様の動作が可能であることが確認でき、Google Mapsからのマイグレーションは実現可能です。これにより、利用料の削減が期待できます。この調査を通じて、Unlimited iOSチーム全員のMapKitの技術理解も深まりました。 おわりに 今後、プロジェクトではMapKitを活用して開発を進めてまいります。 引き続き、さらなる改善を重ね、より良いサービスの提供を目指していきます！

Introduction This article shares insights and mindsets I have found valuable as a new leader. It’s written from my personal experience and intended for those transitioning into a leadership role or who have recently started navigating this path. In November 2023, I was assigned my first team leadership role at KTC (KINTO Technologies). Until then, I had virtually no prior experience in leadership, not even in my previous jobs. To make up for this lack of experience, I started studying “leadership and management mindsets” through books, web articles, and advice from my supervisors as soon as the assignment was confirmed. It would have been great to introduce everything I learned comprehensively. Still, some concepts felt too advanced, obvious, irrelevant to my current role, or simply unappealing. Rather than forcing these ideas on myself, I left them for future opportunities when they might resonate more. In this article, I’ll share eight ideas I’ve successfully “installed” into my current mindset. Although this is far from exhaustive, I hope some of these tips will provide helpful hints for your leadership journey. Collective Hunting and Sharing the Mammoths Some say that an organization’s greatest benefit is the sense of unity among its members. While truth exists, it is more of a secondary advantage. A group that hunted mammoth likely bonded over the shared experience of dividing the meat. The camaraderie was a byproduct as the meat took priority. Kodai Ando, The Mask of Leadership: A Mindset Shift from Individual Contributor to Manager The first book I picked up after being assigned the role of team leader was The Mask of Leadership . At first, I imagined leadership as something like "motivating team members" or "connecting with them on a deeper level." However, I vividly remember being struck by the pragmatic and somewhat cold approach of “Shikigaku” (a theory of organizational behavior). Among its many ideas, I was particularly impressed by the concept that individuals benefit only after the collective benefit is achieved. The correct order is this: First, the group achieves collective benefits. Then, individuals gain their share of those benefits. This perspective resonated with me immediately and has become one of the guiding principles for my leadership approach. Management Roles are "Goal Achievement" and "Group Maintenance" There are various perspectives on how to approach these roles, but one relevant framework is the "PM Theory," which highlights two core functions: performance and maintenance. First, the performance function is about achieving goals. It emphasizes the importance of setting and meeting objectives. On the other hand, the maintenance function is about group maintenance. This involves sustaining and energizing the team, ensuring its cohesion and vitality. An article titled Why Are Middle Managers Perpetually Overburdened? Common Pitfalls and Four Steps to Rebuild Management , highlights several challenges faced by managers. It is noted that environmental and societal changes have made both goal achievement and group maintenance increasingly difficult. The article points out that, recently, too much emphasis has been placed on group maintenance, which has hindered the development of managers capable of strategic planning and achieving goals. However, putting aside those difficult things, I was able to simply take the frame that “the job of a manager is to achieve goals and maintain the group.” I was able to clarify what I should do as a manager, which was good in terms of my mental health. Communicate the Purpose and Delegate the Method Some managers perceive their staff’s trial-and-error efforts as a “loss” and try to speed things up by teaching the “right answers” from the start or giving step-by-step instructions. This mindset is absolutely wrong. People only grow through experience. An organization that simply provides answers will ultimately slow down. Without the growth of its members, the organization’s overall speed and efficiency decline over time. Kodai Ando, The Mask of Leadership: A Mindset Shift from Individual Contributor to Manager For those who are capable, simply communicate the purpose and leave the rest to them For those who are slightly inexperienced, provide the purpose along with actionable hints, like “If it were me, I would do it this way.” And for those who are still immature, communicate both the purpose and the specific actions needed. Shu Yamaguchi, Project Management Taught by Foreign Consultants Micromanagement is generally a poor approach. I have understood this intuitively for some time, but I also recognized from my very first day as a team leader that I simply do not have the capacity to sustain micromanagement. Instead, I am constantly seeking non-micromanagement approaches. My aim is to clearly define the desired outcome and the requirements for success, then delegate the rest to my team members. At the same time, I support them as needed to ensure they can move forward independently. If I Enjoy the Work, It Doesn’t Feel Like a Burden. If I enjoy the work, it doesn’t feel like a burden. It varies from person to person, and isn’t something that can be measured by volume alone. Understanding what kinds of tasks each member enjoys can be incredibly helpful. It’s good to properly manage tasks and workload, but it often lacks significant impact relative to the effort it requires. I once sought advice from my manager about understanding team members’ workload capacity. When I asked, "Should I track everyone’s tasks in detail to understand their workload better?" The response to the question was insightful: "You can, but it’s not worth the effort. Instead, focus on understanding what each person likes and dislikes, and allocate tasks accordingly.” This advice stuck with me. While I do monitor working hours and assign tasks based on individual responsibilities, I’ve also started paying attention to whether the work aligns with each person’s preferences. Managing tasks in overly fine detail often takes up time on non-essential aspects, such as aligning things for visibility or rationalization. I also felt that I lacked the capacity to manage everything at such a granular level. So, I decided not to pursue that approach. Instead, I now assign work based on each member’s area of responsibility while keeping the perspective of “Am I assigning tasks in line with their preferences?” in mind. Creating Exceptions, Like Allowing a Car to Speed through an Intersection at 60 km/h Exceptions can make a team or organization incredibly fragile. If you let even one car run a red light because it’s in a hurry, the entire road system will descend into chaos. Kodai Ando, The Mask of Leadership: A Mindset Shift from Individual Contributor to Manager How many members on your team can you trust to “follow the rules 100%”? Whether it’s meeting deadlines, processing data at the start of the month, escalating issues, or sharing files, workplace rules exist for a reason. If trust is lacking, what happens? Someone ends up covertly monitoring tasks, reminding others, or even correcting mistakes behind the scenes. This reliance on manual intervention hinders team autonomy and efficiency. Decoupling Work: Experts in Loosely Coupled Systems (Practical Edition 3) | RINARU To improve workflow efficiency, I aim to create system where tasks can be completed independently, without requiring constant confirmation. Having even one uncertain step can lead to errors or delays. If it is certain, there is no need to confirm. Establishing clear rules—and ensuring that everyone trusts these rules will be followed—is crucial. While overly rigid rules can hinder the value we aim to deliver, establishing a solid framework is crucial. I focus on setting clear and basic guidelines to provide a reliable foundation for our work. Constants, Variables, and "Variables Close to Constants" Both Professor Hayashi and Mr. Morioka emphasized the importance of identifying constants and variables and focusing on changing variables. This means dedicating your time and energy to things you can influence. "Moving Variables, Not Constants" I learned about this concept during a company meeting where my manager shared it with the team. Observing other managers around me, I’ve noticed that they don’t simply fight against the flow. Instead, they assess the dynamics at play and create conditions where things naturally align with their goals. What stood out most from the manager’s insights was that some variables may currently appear close to constants. What’s important is the ability to make this distinction. This includes aspects such as company culture, policies, and people’s mindsets. These may appear unchangeable and resistant to effort, but it’s important to remember that they are variables that can be shifted over time. People Tend to Forget If They’re Told Only Once Team members find it harder to work with a manager who is “hard to understand” rather than one who is simply “incompetent.” Even critical information, if communicated just once, can get lost in the daily flood of information. 　 "The Leader's Communication Skills" That Eliminate Waiting for Instructions The key is to guide team members to repeatedly return to the project’s purpose during their decision-making process. When a team member asks a question, respond with another question that leads them back to the project’s purpose. By doing this, team members will gradually develop the habit of consistently grounding their decisions in the project’s goals whenever they face uncertainty. Shu Yamaguchi, Project Management Taught by Foreign Consultants I tend to be forgetful myself, and there have been many times when someone has said to me, “I already told you,” leaving me frustrated. Conversely, when someone forgets something I’ve said, I believe that communication is not just an individual issue but a shared responsibility between the two parties. If didn’t communicate effectively enough for the other person to remember, I bear part of the responsibility. When it comes to sharing thoughts and ideas I want to convey, it seems best to repeat them frequently, to the point of saying them at every opportunity. Cheerful Leaders and Grumpy Leaders Edmondson defines psychological safety as "a climate in which people feel safe to take interpersonal risks, such as speaking up with ideas, questions, or concerns.” Why "Psychological Safety" Continues to Cause Confusion | Q by Livesense When the flow of information within a team decreases, projects almost inevitably fall into danger. When the sender of information cannot anticipate how the recipient will react, the overall volume of information exchanged drops. Ultimately, teams led by cheerful leaders see an increase in the flow of information, both between members and between the leader and the team. Shu Yamaguchi, Project Management Taught by Foreign Consultants Based on my experience working with many younger co-workers and staff, I can summarize “how to motivate everyone” in one sentence. Leaders must work more seriously and happily than anyone else. There is no better way to inspire and nurture the members. Noriyuki Sakuma, Noriyuki Sakuma's Unfair Work Technique—How I Did What I Wanted without Burning out at Work Simply put, when your boss is in a bad mood, it creates an awkward atmosphere, making it hard for team members to focus (at least for me). That’s why I always try to maintain a cheerful attitude and create an environment where it’s OK to say anything. Of course, I’m not always genuinely in a good mood, and pretending to be cheerful when I’m not can be draining. If you see a leader or manager struggling, take a moment to acknowledge and appreciate their efforts. Conclusion How was it? I hope you found some ideas here that could be useful in your work. At KTC, being a leader doesn’t mean you’re superior or more skilled than others. It’s simply a function or role that can be assigned or removed based on what’s best for the organization and its current situation. On the other hand, if the leader is just a function, then the members are also just functions. Ultimately, success lies in teamwork. It’s not enough for individual members to simply take action, nor for the leader to handle everything alone. What truly matters is the team's ability to face challenges and overcome them together. Let's take it easy and do our best!

Hello, this is Hiroya (@___TRAsh) 🎅 This year, our Mobile App Development Group has focused extensively on sharing our work with the broader community. We have engaged in various initiatives, such as sponsoring and presenting at events like iOSDC and DroidKaigi, as well as contributing to this tech blog. This has provided us with more opportunities to connect with all of you throughout the year. To wrap up 2024, we’re excited to launch a series of posts as part of the KINTO Technologies Advent Calendar, focusing on Android/Flutter/iOS 🎉 https://qiita.com/advent-calendar/2024/kinto-technologies Our Android/Flutter/iOS engineers are working hard to publish the entire series, so please check them out 🎅 Today, I would like to introduce the Mobile App Development Group, the group behind our Android, Flutter, and iOS app development. What does the Mobile App Development Group do? We develop mobile apps for KINTO Technologies across iOS, Android, and Flutter platforms. The main products we develop are as follows. https://kinto-jp.com/entry_app/ https://kinto-jp.com/unlimited/app/ https://top.myroute.fun/ https://ppap.kinto-jp.com/prismjapan In addition to the above, we also take on development projects in response to PoC requests. Moreover, by leveraging the benefits of being a cross-functional team, we frequently host in-house study sessions to actively share new technologies and knowledge among team members. A survey of our team members This time, we conducted a survey with our engineers. We were able to gather insights that are not usually visible in our daily work, and I would like to share them here. 1. What is your development environment? (Up to 2 responses allowed)  One reason for the high percentage of Android in our development environments is the large number of Android engineers on our team. This is quite rare in Japan, I believe. Also, the Flutter team has been formed this year! We hope to gradually share more about Flutter-related development in the future. 2. How many years have you been developing? ![Development Experience Pie Chart] (/assets/blog/authors/HiroyaHinomori/mobile_advent_calendar_2024_12_01_02.png =450x) Since our company primarily hires mid-career professionals, many of our engineers have extensive experience. I was surprised to see so many with over 10 years of experience. It’s something that I hadn’t realized before. I look forward to learning from these experienced engineers as we continue to grow together. 3. Where are you from? ![Hometowns Pie Chart] (/assets/blog/authors/HiroyaHinomori/mobile_advent_calendar_2024_12_01_03.png =450x) I had a feeling this might be the case, but it turns out that less than half of our team members are Japanese. This is quite a unique workplace! While most communication happens in Japanese, we also hear English, Chinese, and Korean, creating a truly global environment. 4. What do you like about the Mobile App Development Group? We generated a word cloud from the comments we received to showcase the strengths of our team. It’s clear that atmosphere and technology stand out prominently. This seems to reflect the results of our efforts to prioritize communication across product teams and actively share knowledge—something that can be overlooked in daily work. We will continue to do our best next year as well 💪 :::details Summary Technology and learning environment Openness to new technologies: A flexible environment that encourages the adoption and use of the latest technologies. Support for skill development: A learning-friendly setting with active study sessions and knowledge sharing. High skill level: Members with strong technical skills and passion for growth. Focus on output: A dedication to delivering results and achieving goals. Communication and atmosphere Friendly atmosphere: A supportive environment where members can easily ask questions and share comments. Collaborative teamwork: Smooth collaboration both within and across project teams. Diversity and humor: A multicultural and diverse team that embraces individuality and enjoys cultural differences. Flat communication: Minimal barriers between members, regardless of age or background. Work environment Flexible and free work styles: A work culture that respects individual approaches and autonomy. Good team spirit: A cohesive team where everyone works well together. Supportive Environment: A welcoming and safe space where members feel comfortable working. It can be said that these qualities create an ideal team environment where learning, growth, diversity, and collaboration are valued and truly enjoyed. ::: 5. What technology are you most interested in right now? iOS Android We also created a word cloud for this topic using the comments we received. For both Android and iOS, KMP seems to be attracting attention. We can also see mentions of Flutter and Compose Multiplatform, which suggests that many team members are interested in cross-platform technologies. From my perspective, this year has truly been a breakthrough for cross-platform development. Additionally, it appears that many are keeping an eye on the technical evolution of programming languages specific to each platform. Moreover, the attention given to AI-related technologies reflects current industry trends, showing the high level of technical interest among our team members. :::details Summary iOS Top 3 Technologies Swift / SwiftUI Core technologies for Apple platforms, with particular interest in UI development. KMP (Kotlin Multiplatform) Utilized for multiplatform development, including integration on the iOS side. AI (MLC LLM、Apple Intelligence) Growing interest in machine learning and Apple’s AI technologies. Android Top 3 Technologies Jetpack Compose The core UI development technology, with active exploration of efficient coding practices and mastery. KMP (Kotlin Multiplatform) Notable for its use in Android app development and its integration with Compose Multiplatform. Flutter A popular choice for cross-platform development. ::: Summary I feel that the Mobile App Development Group is creating an environment where members can enjoy diversity and collaboration while learning. This is achieved through aspects such as a focus on technology and learning, effective communication and atmosphere, and ease of working. As mobile technology trends evolve rapidly, I aim to stay updated and contribute to the group’s growth. Lastly, I hope this article has conveyed the appeal of the Mobile App Development Group to you 🎅 Stay tuned for our Advent Calendar kicking off tomorrow 🎄

この記事は KINTOテクノロジーズアドベントカレンダー2024 の18日目の記事です🎅🎄 はじめまして。KINTOテクノロジーズのAndroidエンジニア 山田 剛 です。 本記事では、Android View で構築されたアプリを Jetpack Compose を用いたUI記述へ移行させる、もしくは、Android View ベースのUIに徐々に Jetpack Compose ベースのUIを導入する際の第一歩となるような、ちょっとしたテクニックの一部を紹介します。 1. はじめに 宣言的UI のAndroid版として Jetpack Compose の開発開始が数年前にアナウンスされ、2021年7月にバージョン 1.0 がリリースされました。 多くのAndroid開発者が、その以前からJavaに続きAndroid開発の公式サポート言語となっていた Kotlin の柔軟性・拡張性を活用した Jetpack Compose のコンセプトを受け入れ、以降のAndroidアプリ開発において Jetpack Compose の採用が徐々に拡がっているようです。 宣言的UIの導入によって、従来のViewベースのUIと比べて少ないコード量で直感的な記述が可能になり、開発効率/生産性が向上すると考えられています。 最近になって Compose Multiplatform がリリースされ、Android 以外にも Jetpack Compose のスキルを活用できる領域が拡がってきました。 今後は魅力的なライブラリが Jetpack Compose のみに対応される、といったことも増えてくるかもしれません。 その魅力を既存アプリにも取り入れるべく、弊社でも当初 Android View ベースで構築されていたアプリのUIを Jetpack Compose ベースのUIに移行する取り組みを一部の開発プロジェクトで進めています。 しかし従来のViewベースのUIは 手続き的 な要素が多く、Jetpack Compose の 宣言的 なスタイルの導入は簡単というわけにはいきません。 この記事では、Jetpack Compose によって簡潔になったことで削ぎ落とされた、あるいは見えにくくなった要素を補完するためのちょっとしたテクニック、とりわけ Composable の位置やデバッグ情報の確認、 View と Composable の相互運用などについて紹介し、ViewベースからJetpack ComposeベースのUIにできるだけスムーズに移行するための一助となることを目指します。 2. Composable の位置合わせとデバッグ View の表現を今までになかった Composable に替えるという作業をするにあたって、同じ表示内容をどのように表すのか、という課題と同等以上に、正しい位置に配置できるのだろうか、という点が、 Android View に馴染んだ筆者にとっても大きな不安要素でした。まずは、 Composable の表示位置を View と同じに揃えること、そのために必要なデバッグのための情報を取得・確認する方法を紹介します。 2.1. Composable と View の位置を確かめる Android API level 1 から提供されている View は、Java のオブジェクト指向の考え方に基づき、矩形の画面要素としての表現のほか、View 同士の包含関係や相互作用、サブクラスによる機能拡張などもうまく表現しています。 たとえば、単一の View や ViewGroup が内包した多くの View の位置をログに出力することは、以下のようなコードでできます: private fun Resources.findResourceName(@IdRes resId: Int): String = try { getResourceName(resId) } catch (e: Resources.NotFoundException) { "?" } fun View.logCoordinators(logger: (String) -> Unit, res: Resources, outLocation: IntArray, rect: Rect, prefix: String, density: Float) { getLocationInWindow(outLocation) rect.set(outLocation[0], outLocation[1], outLocation[0] + width, outLocation[1] + height) var log = "$prefix${this::class.simpleName}(${res.findResourceName(id)})${rect.toShortString()}(${rect.width().toFloat() / density}dp, ${rect.height().toFloat() / density}dp)" if (this is TextView) { log += "{${if (text.length <= 10) text else text.substring(0, 7) + "..."}}" } logger(log) if (this is ViewGroup) { val nextPrefix = "$prefix " repeat(childCount) { getChildAt(it).logCoordinators(logger, res, outLocation, rect, nextPrefix, density) } } } fun View.logCoordinators(logger: (String) -> Unit = { Log.d("ViewLogUtil", it) }) = logCoordinators(logger, resources, IntArray(2), Rect(), "", resources.displayMetrics.density) ここで View$getLocationInWindow(IntArray) は、View が属する Activity のウィンドウ上での左上の座標を取得する関数です。Android View に慣れている開発者なら、このようなコードで動作を確認するのは簡単でしょう。 一点 Activity$onResume() などから直接これらの関数を呼び出してもまだ View の配置は完了しておらず意味のある情報が取得できないため、多くの場合は View$addOnLayoutChangeListener(OnLayoutChangeListener) などのコールバックから呼び出す必要があることに注意が必要です。 同じようなことを Jetpack Compose ではどうするかよく分からず、 Composable で同じように動作しているか確かめにくく移行作業がおっくう、という開発者も少なくないのではないでしょうか。 Jetpack Compose では、以下のように Modifier の拡張関数 onGloballyPositioned((LayoutCoordinator) -> Unit) を使って Composable の配置を取得できます: @Composable fun BoundsInWindowExample() { Text( modifier = Modifier .padding(16.dp) .background(Color.White) .onGloballyPositioned { Log.d("ComposeLog", "Target boundsInWindow: ${it.boundsInWindow()}") }, text = "Hello, World!", style = TextStyle( color = MaterialTheme.colorScheme.onSecondary, fontSize = 24.sp ) ) } onGloballyPositioned(...) の引数にコールバックを与えることで、Composable の位置が更新されるたびにコールバックで位置の座標を取得できます。 ここで LayoutCoordinator.boundsInWindow() は Composable の矩形の上下左右を Activity 座標系で取得する拡張関数です。 ひとつの Composable に内包されるすべての Composable の位置を一気に取得するのは今のところ難しそうですが、その代わりに単一の Composable の位置は簡単に取得できます。 しかも多くの場合、Activity などの複雑なライフサイクルを気にせずに位置情報を取得できそうです。 onGloballyPositioned(...) に似たコールバックとして onPositioned(...) もあり、こちらは親となる Composable の内部での相対的な位置が決定された後にコールバックが呼ばれるようです。 boundsInWindow() のほかにも boundsInRoot() 、 boundsInParent() などがあり、場合に応じて使い分けることができますが、今回は割愛します。 2.2. 画面表示確認用Composableを作ってみる Composable でも View$getLocationInWindow(IntArray) と互換性のある boundsInWindow() で位置を取得する方法がわかったので、テスト動作させているときの位置の動きをログに出力して動作を確かめながら Composable を作り込んでいけば、徐々に compose に慣れながら View と同じものを作れそうです。 それは正しく、お手軽な方法なのですが、 LogCat は大量の文字が流れていくので、特に情報量が多いときには見づらいことも多々あります。 そこで、画面表示確認用の Composable を別に作ってみることを考えます。 テストのときに限ってアプリの一部にデバッグ用表示領域を作って、常に更新させるようにすれば、流れていく大量の LogCat の中から決定的なログを必死に探す必要もなくなります。 …そんなことは Android View の時代からわかっていたのだがそれを作り込むのがおっくうで…という嘆息が聞こえてきそうですね。 宣言的UI たる Jetpack Compose では、そのようなデバッグ用表示領域を少ない手間で作りやすくなっています: class MainActivity : ComponentActivity() { override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) WindowCompat.getInsetsController(window, window.decorView).isAppearanceLightStatusBars = resources.configuration.uiMode and Configuration.UI_MODE_NIGHT_MASK != Configuration.UI_MODE_NIGHT_YES setContentView(R.layout.activity_main) findViewById<WebView>(R.id.webView).let { webView -> webView.loadUrl("https://blog.kinto-technologies.com/") } val targetRect = mutableStateOf(Rect.Zero) // androidx.compose.ui.geometry.Rect findViewById<ComposeView>(R.id.composeTargetContainer).let { containerComposeView -> containerComposeView.setViewCompositionStrategy(ViewCompositionStrategy.DisposeOnViewTreeLifecycleDestroyed) containerComposeView.setContent { KtcAdventCalendar2024Theme { ScrollComposable(targetRect) } } } val visibleRect = mutableStateOf(Rect.Zero) val outLocation = IntArray(2) findViewById<View>(R.id.layoutMain).addOnLayoutChangeListener { v, left, top, right, bottom, _, _, _, _ -> v.getLocationInWindow(outLocation) visibleRect.value = Rect(outLocation[0].toFloat(), outLocation[1].toFloat(), outLocation[0].toFloat() + (right - left), outLocation[1].toFloat() + (bottom - top)) } findViewById<ComposeView>(R.id.composeTargetWatcher).let { watcherComposeView -> watcherComposeView.setViewCompositionStrategy(ViewCompositionStrategy.DisposeOnViewTreeLifecycleDestroyed) watcherComposeView.setContent { KtcAdventCalendar2024Theme { TargetWatcher(visibleRect.value, targetRect.value) } } } } } サンプルコードで作っているアプリは Jetpack Compose 化作業の途中で、まだ Activity$setContentView(Int) で View を使っており、その View の中で ComposeView を使って Composable を導入しようとしています。 ここでは mutableStateOf(...) で View および Composable の矩形の位置の情報を共有し、画面上での振る舞いを確かめようとしています。 画面構成は下のようになります。HorizontalScrollView の部分を Composable化しようとしており、そのために画面下部をデバッグ情報の表示に利用します:  MainActivity のレイアウトXMLファイルは以下のようになっています: <?xml version="1.0" encoding="utf-8"?> <LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" xmlns:app="http://schemas.android.com/apk/res-auto" xmlns:tools="http://schemas.android.com/tools" android:layout_width="match_parent" android:layout_height="match_parent" android:orientation="vertical" android:layout_marginVertical="48dp"> <androidx.constraintlayout.widget.ConstraintLayout android:id="@+id/layoutMain" android:layout_width="match_parent" android:layout_height="0dp" android:layout_weight="1"> <WebView android:id="@+id/webView" android:layout_width="0dp" android:layout_height="match_parent" android:layout_marginHorizontal="16dp" app:layout_constraintBottom_toBottomOf="parent" app:layout_constraintEnd_toStartOf="@id/scrollView" app:layout_constraintStart_toStartOf="parent" app:layout_constraintTop_toTopOf="parent" tools:ignore="NestedWeights" /> <HorizontalScrollView android:id="@+id/scrollView" android:layout_width="0dp" android:layout_height="match_parent" app:layout_constraintBottom_toBottomOf="parent" app:layout_constraintEnd_toEndOf="parent" app:layout_constraintStart_toEndOf="@id/webView" app:layout_constraintTop_toTopOf="parent"> <androidx.compose.ui.platform.ComposeView android:id="@+id/composeTargetContainer" android:layout_width="wrap_content" android:layout_height="match_parent" /> </HorizontalScrollView> </androidx.constraintlayout.widget.ConstraintLayout> <androidx.compose.ui.platform.ComposeView android:id="@+id/composeTargetWatcher" android:layout_width="match_parent" android:layout_height="300dp" android:paddingTop="16dp" /> </LinearLayout> MainActivity.kt と activity_main.xml は Jetpack Compose 化作業の途中で、View と Composable が混在しています。 WebView などは、本記事執筆時点ではまだ Composable が提供されていないため、現時点では混在させながらうまく運用する実装も必要です。[^1] activity_main.xml において、 HorizontalScrollView の内部に含まれる ComposeView は既存の View を Composable で置き換えようとするもの、もう一方の ComposeView は上の Composable の位置を監視するために設置したものです。 View にとって代わる Composable は以下のようになっており、 "Target" と表示される部分の配置をチェックするべく、 onGloballyPositioned(...) を実装しています。 @Composable fun ScrollComposable(targetRect: MutableState<Rect>) { val textStyle = TextStyle( textAlign = TextAlign.Center, color = MaterialTheme.colorScheme.onSecondary, fontSize = 24.sp, fontWeight = FontWeight.W600 ) Row( modifier = Modifier .fillMaxSize(), horizontalArrangement = Arrangement.Center, verticalAlignment = Alignment.CenterVertically ) { Box( modifier = Modifier .padding(16.dp) .width(100.dp) .fillMaxHeight() .background(Color.Red), contentAlignment = Alignment.Center ) { Text("1", style = textStyle) } Box( modifier = Modifier .padding(16.dp) .width(100.dp) .fillMaxHeight() .background(Color.Magenta), contentAlignment = Alignment.Center ) { Text("2", style = textStyle) } Box( modifier = Modifier .padding(16.dp) .width(100.dp) .fillMaxHeight() .background(MaterialTheme.colorScheme.primary) .onGloballyPositioned { targetRect.value = it.boundsInWindow() }, contentAlignment = Alignment.Center ) { Text("Target", style = textStyle) } Box( modifier = Modifier .padding(16.dp) .width(100.dp) .fillMaxHeight() .background(Color.Cyan), contentAlignment = Alignment.Center ) { Text("4", style = textStyle) } } } これを監視する Composable が以下です。ここではこの Composable 自身も onGloballyPositioned(...) を使って、自身のサイズを取得しています。 @Composable fun TargetWatcher(visibleRect: Rect, targetRect: Rect) { if (visibleRect.width <= 0f || visibleRect.height <= 0f) return val rootAspectRatio = visibleRect.width / visibleRect.height val density = LocalDensity.current // For calculating toDp() val targetColor = MaterialTheme.colorScheme.primary.copy(alpha = 0.25F) var size by remember { mutableStateOf(IntSize.Zero) } Box( modifier = Modifier .fillMaxSize() .onGloballyPositioned { coordinates -> size = coordinates.size } ) { if (size.width <= 0F || size.height <= 0F) return@Box val watchAspectRatio = size.width.toFloat() / size.height val (paddingH: Float, paddingV: Float) = if (rootAspectRatio < watchAspectRatio) { (size.width - size.height * rootAspectRatio) / 2 to 0F } else { 0F to (size.height - size.width / rootAspectRatio) / 2 } with(density) { Box( modifier = Modifier .padding(horizontal = paddingH.toDp(), vertical = paddingV.toDp()) .fillMaxSize() .background(Color.Gray) ) } if (targetRect.width <= 0f || targetRect.height <= 0f) return@Box with(density) { Box( modifier = Modifier .padding( // Caution: exception is thrown if padding is negative start = max( 0F, marginOf( size.width, paddingH, visibleRect.left, visibleRect.right, targetRect.left ) ).toDp(), end = max( 0F, size.width - marginOf( size.width, paddingH, visibleRect.left, visibleRect.right, targetRect.right ) ).toDp(), top = max( 0F, marginOf( size.height, paddingV, visibleRect.top, visibleRect.bottom, targetRect.top ) ).toDp(), bottom = max( 0F, size.height - marginOf( size.height, paddingV, visibleRect.top, visibleRect.bottom, targetRect.bottom ) ).toDp() ) .fillMaxSize() .background(targetColor) ) } } } private fun marginOf( sizePx: Int, halfPx: Float, visibleFrom: Float, visibleTo: Float, px: Float ): Float { val alpha = (px - visibleFrom) / (visibleTo - visibleFrom) return (1 - alpha) * halfPx + alpha * (sizePx - halfPx) } このComposable関数で、Activityの画面と "Target" と表示される Composable の位置関係を図示しています。 padding の設定が少しわずらわしいですが、難しい算術ではありません。 Composable は形式的には関数ですが、 MutableState や remember を用いて状態を継続的に保持することでUIの表現を成り立たせています。同時に、継続的な情報が変更されたとき Composable の再描画 (recomposition) が行われるようになっており、わずらわしいイベント処理の記述を減らすことができ、 宣言的 なコーディングを可能にしています。 画面右上部分の HorizontalScrollView を左右にスクロールすると、画面下の Composable がスクロールに追従して位置を表示してくれます。ScrollView の内部に存在する View や Composable の位置を View$getLocationInWindow(IntArray) や LayoutCoordinator.boundsInWindow() で取得すると画面外の座標も得られますので、画面の内外を正常に行き来できるかどうかを確かめられます（Composable で Modifier.horizontalScroll(...) や　 Modifier.verticalScroll(...) などを用いてスクロールさせる場合はこの限りではありません）。 従来からの View でこのようなデバッグ情報を表示するには、レイアウトXMLファイルと Java/Kotlin のコードをそれぞれ書き換える必要があり、リリース後のアプリに反映されない作業としてはちょっとわずらわしいものでした。変数の更新に追随するレイアウトXMLファイルを作成できるデータバインディングも提供されましたが、直感的とはいいがたいものでした。Jetpack Compose は情報をデザインに直接書き込むような感覚で画面を設計でき、時間のかからない作業で実装の成果を確認できます。 なんでもグラフィカルに表示するのがよいわけではありませんが、表現の選択肢が増え、コーディング作業に入っていきやすくなると思います。 [^1]: WebView の機能を Composable として利用するラッパー が accompanist のライブラリで提供されていますが、現在は 非推奨 となっています。View の Composable化はご本家でも簡単ではないようですし、一般のアプリ開発で View と Composable の同居が長く続くのは特におかしなことではありませんので、安心してComposable化に踏み切りましょう。 2.3. 宣言的にデバッグ情報を書く Composable によるデバッグ情報の表現は、さらに少ない手数で情報の追加を行なえます: @Composable fun TargetWatcher(visibleRect: Rect, targetRect: Rect) { // ... // ... Text( text = when { targetRect in visibleRect -> "Target: inside screen" visibleRect.overlaps(targetRect) -> "Target: crossing edge of screen" else -> "Target: outside screen" }, modifier = Modifier.align(Alignment.TopStart), style = TextStyle( textAlign = TextAlign.Center, color = MaterialTheme.colorScheme.onSurface, fontSize = 24.sp, fontWeight = FontWeight.W600 ) ) } } /** * "operator fun receiver.contains" defines in and !in (syntax: other in(!in) receiver) */ private operator fun Rect.contains(other: Rect) = left <= other.left && top <= other.top && right >= other.right && bottom >= other.bottom 上記では Text(...) を使ってデバッグ情報を追加しています。 Text(...) の引数 style は、デフォルト設定で充分なら省略できます。 Log.d(...) や println(...) などとほとんど変わらないタイプ数で情報を表示できます。しかもそれらと違ってスクロールで流れていってしまうこともありません。 「print文デバッグ」のような手軽さでUI構築ができるのも、 宣言的UI の意義の1つでしょう。 アプリをビルドして実行し、右上のスクロールビューを横スクロールすると、以下のように画面下部でアプリの動作する様子が確認できます: 画面外に表示中 画面の境界上にかかっている 画面内に表示中 3. LaunchedEffect で手続き的な処理 これまで 宣言的UI の意義を説明してきましたが、状態が変わったときのイベント処理や、状態が変わったことを示すアニメーションなどを実装するには、 手続き的 な処理も必要です。従来からの View で行なってきたイベント処理など手続き的な記述もできなければ、Jetpack Compose へは移行できません。 Jetpack Compose では LaunchedEffect を使って状態の変化に応じた処理を書くのが一般的です: @Composable fun TargetWatcher(visibleRect: Rect, targetRect: Rect) { // ... // ... var currentState by remember { mutableStateOf(TargetState.INSIDE) } var nextState by remember { mutableStateOf(TargetState.INSIDE) } var stateText by remember { mutableStateOf("") } var isTextVisible by remember { mutableStateOf(true) } nextState = when { targetRect in visibleRect -> TargetState.INSIDE visibleRect.overlaps(targetRect) -> TargetState.CROSSING else -> TargetState.OUTSIDE } LaunchedEffect(key1 = nextState) { if (stateText.isNotEmpty()) { if (currentState == nextState) return@LaunchedEffect stateText = when (nextState) { TargetState.INSIDE -> "Target: entered screen" TargetState.OUTSIDE -> "Target: exited screen" TargetState.CROSSING -> if (currentState == TargetState.INSIDE) "Target: exiting screen" else "Target: entering screen" } currentState = nextState repeat(3) { isTextVisible = true delay(250) isTextVisible = false delay(250) } } stateText = when (nextState) { TargetState.INSIDE -> "Target: inside screen" TargetState.CROSSING -> "Target: crossing edge of screen" TargetState.OUTSIDE -> "Target: outside screen" } isTextVisible = true } if (isTextVisible) { Text( text = stateText, modifier = Modifier.align(Alignment.TopStart), ) } } } enum class TargetState { INSIDE, CROSSING, OUTSIDE } LaunchedEffect の key は複数個の設定も可能です。また、Composable が呼び出される最初の1回だけ処理を行ないたい場合は、 LaunchedEffect(Unit) { ... } として実現できます。 ここで key に指定された nextState が変化するたびに、その変化に応じた処理が行なわれます。上記のコードは、状態が変化した直後の1.5秒間はテキストが点滅しながら直前の状態と比較した現在の状態を表示し、その後は静的な状態を表示します。 LaunchedEffect の key に状態の変数を指定し、それが変化したときの処理をブロック内に記述することでイベント処理が可能です。 LaunchedEffect の ブロック内では delay(...) などの suspend関数 を使った時間のかかる処理の記述が可能です。ブロック内の処理が終わる前に次の状態の変化があった場合、ブロック内の処理はキャンセルされ、次の状態の変化に応じた処理が最初から行なわれます。 LaunchedEffect の ブロック内では 手続き的 な処理を書いていますが、その後の Text(...) は手続き的に与えられた変数の値にしたがって 宣言的 に記述されていることに注目してください。UIの変化に応じた処理は LaunchedEffect を利用するのがよいでしょう。このほか、 SideEffect や、Activity および Fragment のライフサイクルに応じた処理を行なう DisposableEffect など、さまざまな状況への備えが用意されています。 一方、必要以上に複雑にならないよう、このような処理を多く書きすぎないことも重要です。たとえばインターネットからのレスポンスやNFCなど各種センサーの入力を契機としたイベント処理は ViewModel などに記述して、Composable 内の手続き的な記述はUIに関する要素のみにとどめることをお勧めします。 4. ComposeView と AndroidView の相互運用 Activity や Fragment の中で Composable を使う場合、上記のように ComposeView を使って Composable を表示できます。 逆に先述の WebView などを Composable の中で使うために AndroidView または AndroidViewBinding を使って View を Composable に埋め込むこともできます。方法は こちら（Compose でビューを使用する） をご参照ください。 本記事では詳細は省きますが、 AndroidView Composable の存在によって、Composable化の作業を進めたものの一部の View は Composable への置き換えが困難、もしくは非常に時間を要する、といった場合にも、Compose と View を混在させながら開発を進めることができます。 この相互運用は非常に強力で、 ComposeView で呼び出している Composable の中で AndroidView を呼び出し、その中で再度 ComposeView を設置して Composable を呼び出し、さらにその中で AndroidView を…という階層構造も可能です。Composable の中に View を使う余地を残すことで、Composable化作業が思ったように進展しない、あるいは Composable への置き換え作業に開発スプリントの期間を大きく超える時間を要する、といった場合にも、作業に費やした時間を無駄にするリスクが抑えられています。 5. Preview関数 Composable も View と遜色ない水準で位置合わせやデバッグ情報取得のテクニックが使え、手続き的な処理も書くことができ、あるいは Composable化の障害に直面しても強力な相互運用によって一部を View に戻す選択肢がある、と、これまで来た道を振り返ることのできる柔軟さについて主に述べました。ここでは Composable化によって新たに得られる果実、Preview関数の簡単で強力なプレビュー機能について述べます。 5.1. Preview関数を作成する レイアウトXMLファイルによる View の表現も Android Studio のプレビュー機能が利用できましたが、Jetpack Compose ではさらに強力なプレビュー関数を書けます。 @Preview アノテーションで修飾した関数を作成するだけで、Composable がプレビュー表示されます: // ... private class TargetWatcherParameterProvider : PreviewParameterProvider<TargetWatcherParameterProvider.TargetWatcherParameter> { class TargetWatcherParameter( val visibleRect: Rect, val targetRect: Rect ) override val values: Sequence<TargetWatcherParameter> = sequenceOf( TargetWatcherParameter( visibleRect = Rect(0f, 0f, 100f, 300f), targetRect = Rect(90f, 80f, 110f, 120f) ), TargetWatcherParameter( visibleRect = Rect(0f, 0f, 300f, 100f), targetRect = Rect(80f, 90f, 120f, 110f) ) ) } @Preview @Composable private fun PreviewTargetWatcher( @PreviewParameter(TargetWatcherParameterProvider::class) params: TargetWatcherParameterProvider.TargetWatcherParameter ) { KtcAdventCalendar2024Theme { TargetWatcher(params.visibleRect, params.targetRect) } } 上記は PreviewParameterProvider を利用して、ひとつのプレビュー関数で複数のパラメータを与えてプレビュー表示する例を示しています。 Android View のレイアウトXMLファイルで tools:??? 属性を使ってプレビューを設定する方式では、このようなことはできません。 PreviewParameterProvider を使わなくても、 @Preview と @Composable の2つのアノテーションで修飾された関数内で Composable関数を呼び出す記述を書くだけでプレビュー表示が可能です。 筆者といたしましては、新しい Composable を作り始めたときにはすぐにプレビュー関数を作成することをお勧めします。Composable の新規作成時に最初から強力なプレビュー機能を使える長所だけでも、Jetpack Compose への移行の動機として充分であると考えます。 デバッグ情報の表示の確認がプレビュー関数で行なえることも、Composable を活用してデバッグする利点の1つでしょう。 また最近では、 roborazzi などのライブラリを利用してプレビュー関数をUIテストに利用する手法が注目されており、テスト効率化の観点からもプレビュー関数の作成は有用です。 5.2. Preview関数を実行してみる こちら（プレビューを実行） に書かれている通り、Android Studio の左側の**Run '...'**アイコンをクリックすると、Preview関数をAndroid実機またはエミュレータで実行してみることができます。従来からの特定のActivityを実行する機能と同じようなものですが、Preview関数が簡単に書けること、およびインテントなどの要素がなく単純化された状況での実行が可能であることから、より強力になっているといえます。ボタンタップなどのUIアクションのコールバックも実行されるので、Preview関数をあたかも簡易なアプリであるかのようにテストに使えます。 ただし、Preview関数でテストができることを重視するあまりに Composable に多くの機能を持たせすぎることはお勧めしません。ビジネスロジックはできるだけ ViewModel や Circuit における Presenter などの別のクラスないしは関数に分離し、Composable はあくまでも 宣言的UI であり続けるべく、極力UIの表現のみを記述することをお勧めします。 6. おわりに 本記事が、ひとりでも多くの開発者にとって Android View から Jetpack Compose に踏み出すきっかけとなれれば幸いです。考え方の異なるUIシステムへの移行は一筋縄ではいかず、挫折の不安がつきまといます。その第一歩の足取りができるだけ軽やかになること、かつ徒労に終わるリスクができるだけ抑えられることを願っています。 7. 参考文献 Android API reference ［Android］View の位置を取得する関数たち Jetpack Compose Modifier 徹底解説 What can Advanced / Lesser Known Modifiers do for your UI? — A Comprehensive Exploration in Jetpack Compose A Journey Through Advanced and 備考 Android ロボットは、Google が作成および提供している作品から複製または変更したものであり、 クリエイティブ・コモンズ 表示 3.0 ライセンスに記載された条件に従って使用しています。[^2] [^2]: https://developer.android.com/distribute/marketing-tools/brand-guidelines#android_robot

初めに KINTOテクノロジーズのQAグループに所属しているパンヌウェイ(PannNuWai)です。QAグループでアプリチームのテスト自動化担当として KINTOかんたん申し込みアプリ のテスト自動化環境の構築と整備をしていたり、テスト仕様書とテストスクリプトを書いています。 前回は、 Appiumを利用したDarkMode自動化テスト に関する技術ブログを記載しました。 Appiumによる自動化テストに携わったのは3年になり、自分のチームでは自動化テストソースコード前にテスト仕様書作成の順番で行なっております。 だからAppiumのJavaソースコード書く時とても役に立ているテスト仕様書作成方法についてお話ししたいと思います。 テスト仕様書作成前になぜこの仕様書作成方法が必須ですかの質問について回答させて頂きます。 テスト仕様書作成のメリット 自動化テストソースコード書く場合時間削減できる 自動化テスト者以外の方にも分かり安い 画面ごと、ソースコードクラスと操作機能によって分別してるので読みやすい 本記事ではKINTOかんたん申し込みアプリのログインシナリオ仕様書をサンプルテスト仕様書として説明します。 ログインステップ こちらにKINTOかんたん申し込みアプリログインの各ステップについて教えます。 ステップ 1 ステップ 2 ステップ 3 ログインに関するテストデータを収集する ログインテスト仕様書作成の初期ステップとして、テスト環境、テストアカウント、パスワード、テスト実行後に自動出力されているレポート名、テスト実行ファイルなどのテストデータを収集する必要があります。それでは、iOSのログインシナリオ仕様書から始めましょう。 データ名 データ情報 環境 Stg4 テストアカウント ******@gmail.com パスワード ******** レポート名 iOS用 iOS.poc.login android用 android.poc.login 実行ソースファイル iOS用 iOS.poc.login.xml android用 android.poc.login.xml iOS用のログインシナリオ仕様書 確認機能 画面 操作 確認ポイント 実行ファイル(xml) ソースファイル メソッド ログインする メイン画面 マイページロゴを押下する ログインボタンが押下できる iOS.poc.login.xml iOS.MainPage clickMyPagingLogo マイページ画面 『お申し込み内容』を押下する 『ログインはこちら！』を押下する iOS.MyPagingPage clickApplyTab clickLoginHereButton ログイン画面 『メールアドレス（KINTO ID)』に上記のテストアカウントを記入する 『ログインパスワード』に上記のパスワードを記入する 『My KINTOへログイン』を押下する iOS.LoginPage fillMailAddress fillPassword clickToMyKintoLoginButton これからシナリオ仕様書の各画面によってJavaのクラスを作成しましょう。まずは、メイン画面(MainPage.java)のマイページロゴを押下します。 MainPage.java public class MainPage extends Base { public static final String MY_PAGING_LOGO = "//XCUIElementTypeButton[@name=\"マイページ\"]"; /** * メイン画面の『マイページ』ロゴのクリックするテストメソッド * * このメソッドはXPathを使用してメインページ上の"マイページ"ロゴを特定し、 * クリックアクションを実行する * */ @Test(groups = "MainPage") public void clickMyPagingLogo() { driver.findElementByXPath(MY_PAGING_LOGO).click(); } } ステップ 2　としてマイページ画面の『お申し込み内容』を押下した後『ログインはこちら』をクリックします。 MyPagingPage.java public class MyPagingPage extends Base　{ public static final String APPLY_TAB = "//XCUIElementTypeButton[@name=\"お申し込み内容\"]"; public static final String LOGIN_HERE_BUTTON = "//XCUIElementTypeButton[@name="My KINTOへログイン\"]"; /** * マイページ画面の『お申し込み内容』をクリックするテストメソッド * * このメソッドはXPathを使用してマイページ画面の『お申し込み内容』を特定し、 * クリックアクションを実行する * */ @Test(groups = "MyPagingPage", dependsOnGroups = "MainPage") public void clickApplyTab() { driver.findElementByXPath(APPLY_TAB).click(); } /** * マイページ画面の『ログインはこちら』をクリックするテストメソッド * * このメソッドはXPathを使用してマイページ画面の『ログインはこちら』を特定し、 * クリックアクションを実行する * */ @Test(groups = "MyPagingPage", dependsOnMethods = "clickApplyTab") public void clickLoginHereButton() { driver.findElementByXPath(LOGIN_HERE_BUTTON).click(); } } 次は　ステップ 3　として『ログイン画面』にメールアドレスとパスワードを記入しながらログインボタンを押下します。 LoginPage.java public class LoginPage extends Base { public static final String EMAIL_TEXT_FIELD = "//XCUIElementTypeApplication[@name=\"KINTO かんたん申し込み \"]/XCUIElementTypeOther[2]/XCUIElementTypeTextField"; public static final String PASSWORD_TEXT_FIELD = "//XCUIElementTypeApplication[@name=\"KINTO かんたん申し込み \"]/XCUIElementTypeOther[3]/XCUIElementTypeSecureTextField"; public static final String ENTER_KEY = "//XCUIElementTypeButton[@name=\"Return\"]"; public static final String TO_MY_KINTO_LOGIN_BUTTON = "//XCUIElementTypeButton[@name=\"My KINTOへログイン\"]"; /** * ログイン画面の『メールアドレス（KINTO ID)』にテストアカウントを記入するテストメソッド * * このメソッドはXPathを使用してログイン画面の『メールアドレス』で * xmlファイルのテストアカウント（Parameter)を記入する * */ @Parameters("email") @Test(groups= "LoginPage", dependsOnGroups = "MyPagingPage") public void fillMailAddress(String email) { driver.findElementByXPath(EMAIL_TEXT_FIELD).click(); driver.getKeyboard().sendKeys(email); } 　　/** * ログイン画面の『ログインパスワード』にパスワードを記入するテストメソッド * * このメソッドはXPathを使用してログイン画面の『ログインパスワード』で * xmlファイルのパスワード（Parameter)を記入する * */ @Parameters("password") @Test(groups= "LoginPage", dependsOnGroups = "MyPagingPage") public void fillPassword(String password) { driver.findElementByXPath(PASSWORD_TEXT_FIELD).click(); driver.getKeyboard().sendKeys(password); driver.findElementByXPath(ENTER_KEY).click(); } /** * ログイン画面の『My KINTOへログイン』を押下するテストメソッド * * このメソッドはXPathを使用してログイン画面の『My KINTOへログイン』を特定し、 * クリックアクションを実行する * */ @Test(groups= "LoginPage", dependsOnGroups = "MyPagingPage") public void clickToMyKintoLoginButton() { driver.findElementByXPath(TO_MY_KINTO_LOGIN_BUTTON).click(); } } 下記のxmlファイルは自動化テストのテスト実施ファイルです。テスト仕様書に基づいて各機能を順番に書いています。 <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE suite SYSTEM "http://testng.org/testng-1.0.dtd"> <suite name="iOS.poc.login"> <test verbose="2" name="iOS.poc.login"> <classes> <class name="iOS.MainPage"> <methods> <include name="clickMyPagingLogo"/> </methods> </class> <class name="iOS.MyPagingPage"> <methods> <include name="clickApplyTab"/> <include name="clickLoginHereButton"/> </methods> </class> <class name="iOS.LoginPage"> <methods> <parameter name="email" value="******.gmail.com"/> <parameter name="password" value="*********"/> <include name="fillMailAddress"/> <include name="fillPassword"/> <include name="clickToMyKintoLoginButton"/> </methods> </class> </classes> </test> </suite> まとめ 本記事では、AppiumのJavaソースコード向けのテスト仕様書作成方法を説明しましたが、Appiumだけではなく他の自動化テストソースコード作成にも参考になるように期待しています。

この記事は KINTOテクノロジーズアドベントカレンダー2024 の18日目の記事です🎅🎄 学びの道の駅の中西です。今年は学びの道の駅プロジェクトが立ち上がり組織化されました。そんな中、社内Podcastの運営も行っており、今年のアドベントカレンダーではその内容もお届けしたいと思います。 「学びの道の駅」とは？ 「学びの道の駅」は、社内で頻繁に開催される勉強会をもっと便利に、そして効果的に活用するために立ち上げられたプロジェクトです。社内の有志が中心となり勉強会の開催を支援し社内の知識共有を促進することを目的としています。 Figma勉強会 KTC学びの道の駅ポッドキャストでは、社内の勉強会を開催している方にインタビューを行っています。その名も「突撃！となりの勉強会」。本日のポッドキャストのゲストは、Figma勉強会のご担当であるT.M.さんとM.K.さんです。早速ですが、お二人の業務について教えていただけますか？まずはT.M.さんからお願いします。 インタビュー T.M.さん: モビリティプロダクト開発部のDX企画推進グループDXプランニングチームに所属しています。普段は社内の販売店DXに関するプロダクト開発をデザイナーとして担当しています。最近はモバイルアプリのデザインに注力しており、秋頃にリリースを予定しています。チームができてまだ1年ほどなので、これから本格的に事業化を目指していく段階です。 明田さん: ありがとうございます。ではM.K.さん、お願いします。 M.K.さん: マーケティング企画部のデザイナーとして働いています。主にビジュアルデザインとUI/UXデザインを担当しており、最近は新車サブスクサービスのサイトデザインを手掛けています。 明田さん: ありがとうございます。さて、先週金曜日に開催されたFigma勉強会についてですが、開催のきっかけは何だったのでしょうか？ T.M.さん: 中西さんがふらっとやってきて、「Figmaの勉強会してよ」と声をかけてくださったのがきっかけです。ただ、その前からKTC内でFigmaの使い方に改善の余地があると感じていたので、良いタイミングでした。そこでM.K.さんと共に、どういった形が良いか詰めていき、先週の金曜日に初回を開催しました。 明田さん: 中西さん、その最初の声かけのきっかけは何だったのでしょうか？ 中西: T.M.さんが入社されてから、デザインの改善意欲が強いと感じました。Figmaの勉強会もできたらいいねという話が出ていたので、そろそろその時が来たかなと感じて声をかけました。 明田さん: ありがとうございます。実際に勉強会を開催してみて、参加者の反応はいかがでしたか？ T.M.さん: 反応はまずまずでした。多くの参加者がFigmaについてさらに知識を深めたいと感じているようでした。特にQ&Aセッションでは多くの質問が上がり、皆さんが関心を持っていることが分かりました。 M.K.さん: 私も同様に感じました。皆さんがFigmaの使い方やUI/UXの改善に興味を持っていることが分かり、良い機会だったと思います。 明田さん: 具体的にはどのような質問がありましたか？ T.M.さん: テクニカルな質問から、KTC内でのUI/UXの取り組みについての質問まで様々でした。特にエンジニアからの質問が多く、彼らもUXに対して強い関心を持っていることが分かりました。 明田さん: これからの勉強会の展望について教えてください。 T.M.さん: 短期的には、生産性向上や効率化を目指し、必要なテーマやコンテンツを提供していきたいです。長期的には、デザイナーのプレゼンスを上げ、ビジネスの成功に貢献するための手段としてFigmaを活用していきたいです。 M.K.さん: 私も同じ意見です。エンジニアやデザイナーが共通言語を持ち、コミュニケーションを取れる場を増やしていきたいと考えています。 明田さん: ありがとうございます。最後に、このポッドキャストを聞いている皆さんに一言お願いします。 M.K.さん: デザインはビジュアルだけではありません。誰でも意見を持つことが大切です。気軽にコミュニケーションを取りましょう。 T.M.さん: 良いプロダクトを作るためには、全員がデザイナーであるという意識を持つことが重要です。気軽に相談してください。 明田さん: ありがとうございました。本日のポッドキャストはここまでです。T.M.さん、M.K.さん、ありがとうございました。Figma勉強会の取り組みや、デザインに対する熱意が伝わりました。これからもKTCのデザインが進化していくことを楽しみにしています。 今回はFigma勉強会の詳細と、その運営の背景、今後の展望についてお届けしました。次回の勉強会も楽しみにしてください！

この記事は KINTOテクノロジーズアドベントカレンダー2024 の18日目の記事です🎅🎄 学びの道の駅の中西です。今年は学びの道の駅プロジェクトが立ち上がり組織化されました。そんな中、社内Podcastの運営も行っており、今年のアドベントカレンダーではその内容もお届けしたいと思います。 「学びの道の駅」とは？ 「学びの道の駅」は、社内で頻繁に開催される勉強会をもっと便利に、そして効果的に活用するために立ち上げられたプロジェクトです。社内の有志が中心となり勉強会の開催を支援し社内の知識共有を促進することを目的としています。 Figma勉強会 KTC学びの道の駅ポッドキャストでは、社内の勉強会を開催している方にインタビューを行っています。その名も「突撃！となりの勉強会」。本日のポッドキャストのゲストは、Figma勉強会のご担当であるT.M.さんとM.K.さんです。早速ですが、お二人の業務について教えていただけますか？まずはT.M.さんからお願いします。 インタビュー T.M.さん: モビリティプロダクト開発部のDX企画推進グループDXプランニングチームに所属しています。普段は社内の販売店DXに関するプロダクト開発をデザイナーとして担当しています。最近はモバイルアプリのデザインに注力しており、秋頃にリリースを予定しています。チームができてまだ1年ほどなので、これから本格的に事業化を目指していく段階です。 明田さん: ありがとうございます。ではM.K.さん、お願いします。 M.K.さん: マーケティング企画部のデザイナーとして働いています。主にビジュアルデザインとUI/UXデザインを担当しており、最近は新車サブスクサービスのサイトデザインを手掛けています。 明田さん: ありがとうございます。さて、先週金曜日に開催されたFigma勉強会についてですが、開催のきっかけは何だったのでしょうか？ T.M.さん: 中西さんがふらっとやってきて、「Figmaの勉強会してよ」と声をかけてくださったのがきっかけです。ただ、その前からKTC内でFigmaの使い方に改善の余地があると感じていたので、良いタイミングでした。そこでM.K.さんと共に、どういった形が良いか詰めていき、先週の金曜日に初回を開催しました。 明田さん: 中西さん、その最初の声かけのきっかけは何だったのでしょうか？ 中西: T.M.さんが入社されてから、デザインの改善意欲が強いと感じました。Figmaの勉強会もできたらいいねという話が出ていたので、そろそろその時が来たかなと感じて声をかけました。 明田さん: ありがとうございます。実際に勉強会を開催してみて、参加者の反応はいかがでしたか？ T.M.さん: 反応はまずまずでした。多くの参加者がFigmaについてさらに知識を深めたいと感じているようでした。特にQ&Aセッションでは多くの質問が上がり、皆さんが関心を持っていることが分かりました。 M.K.さん: 私も同様に感じました。皆さんがFigmaの使い方やUI/UXの改善に興味を持っていることが分かり、良い機会だったと思います。 明田さん: 具体的にはどのような質問がありましたか？ T.M.さん: テクニカルな質問から、KTC内でのUI/UXの取り組みについての質問まで様々でした。特にエンジニアからの質問が多く、彼らもUXに対して強い関心を持っていることが分かりました。 明田さん: これからの勉強会の展望について教えてください。 T.M.さん: 短期的には、生産性向上や効率化を目指し、必要なテーマやコンテンツを提供していきたいです。長期的には、デザイナーのプレゼンスを上げ、ビジネスの成功に貢献するための手段としてFigmaを活用していきたいです。 M.K.さん: 私も同じ意見です。エンジニアやデザイナーが共通言語を持ち、コミュニケーションを取れる場を増やしていきたいと考えています。 明田さん: ありがとうございます。最後に、このポッドキャストを聞いている皆さんに一言お願いします。 M.K.さん: デザインはビジュアルだけではありません。誰でも意見を持つことが大切です。気軽にコミュニケーションを取りましょう。 T.M.さん: 良いプロダクトを作るためには、全員がデザイナーであるという意識を持つことが重要です。気軽に相談してください。 明田さん: ありがとうございました。本日のポッドキャストはここまでです。T.M.さん、M.K.さん、ありがとうございました。Figma勉強会の取り組みや、デザインに対する熱意が伝わりました。これからもKTCのデザインが進化していくことを楽しみにしています。 今回はFigma勉強会の詳細と、その運営の背景、今後の展望についてお届けしました。次回の勉強会も楽しみにしてください！

この記事は KINTOテクノロジーズアドベントカレンダー2024 の17日目の記事です🎅🎄 学びの道の駅の中西です。今年は学びの道の駅プロジェクトが立ち上がり組織化されました。そんな中、社内Podcastの運営も行っており、今年のアドベントカレンダーではその内容もお届けしたいと思います。 「学びの道の駅」とは？ 「学びの道の駅」は、社内で頻繁に開催される勉強会をもっと便利に、そして効果的に活用するために立ち上げられたプロジェクトです。社内の有志が中心となり勉強会の開催を支援し社内の知識共有を促進することを目的としています。 セキュリティ&プライバシー勉強会 KTC学びの道の駅ポッドキャストでは、社内の勉強会を開催している方にインタビューを行っています。その名も「突撃！となりの勉強会」。本日のポッドキャストのゲストは「セキュリティ＆プライバシー勉強会」を開催している桑原さん、森野さん、笠井さんにインタビューします。みなさん、どうぞよろしくお願いいたします。 インタビュー 森野さん: セキュリティ・プライバシーグループの森野です。よろしくお願いします。 笠井さん: データ＆プライバシーガバナンスチームの笠井と申します。よろしくお願いします。 桑原さん: セキュリティCoEグループの桑原です。よろしくお願いします。 HOKAさん: では、まず皆さんの普段のお仕事について教えていただけますか？ 森野さん: 私たちのチームは三つに分かれています。データ＆プライバシーガバナンスチーム、インフォメーションセキュリティチーム、そしてサイバーセキュリティディフェンスチームです。データ＆プライバシーガバナンスチームは、データとプライバシーに関するルールの整備やガバナンスの効かせ方を担当しています。インフォメーションセキュリティチームは、情報セキュリティのスタンダードに基づいてアセスメント活動を行います。そして、サイバーセキュリティディフェンスチームは、脆弱性の管理や脅威情報の収集・調査を担当しています。 笠井さん: 私のチーム、データ＆プライバシーガバナンスチームは、データに関するセキュリティ管理や個人情報の管理に関するルールを制定し、リスク評価を行い、それを経営に報告しています。 桑原さん: セキュリティCoEグループは、AWS、Azure、Google Cloudなどのクラウド環境のセキュリティを担当しています。安全にクラウドを利用するためのガードレールの設定や、危険な兆候の監視・サポートを行っています。 HOKAさん: 次に、セキュリティ＆プライバシー勉強会について教えてください。どのような勉強会ですか？ 桑原さん: この勉強会は、社員の皆さんにセキュリティに関連する知識を広めるために開催しています。昨年度から具体的なガイドラインを作成し、それを周知させるために勉強会を始めました。 森野さん: この勉強会を通じて、セキュリティバイデザインやプライバシーバイデザインが当たり前の要件として検討され、実装されることを目指しています。 笠井さん: 私たちの目的は、社員の皆さんがエンジニアリングに集中できるようにし、プライバシーやセキュリティのリスクについては我々がサポートすることです。 HOKAさん: 勉強会の反響はいかがですか？ 桑原さん: 今月までに計4回実施しました。反響は良く、勉強になったという声や改善要望もいただいています。 森野さん: 参加者からは、説明がわかりやすくなったという声もあり、工夫を重ねています。 HOKAさん: この勉強会を通じて、KTCにどのような変化を期待していますか？ 森野さん: セキュリティやプライバシーの機能が標準として実装される状態を目指しています。 桑原さん: 私たちの仕事が不要になるくらい、セキュリティが当たり前になることが理想です。 笠井さん: エンジニアの皆さんが安心して開発に集中できる環境を作りたいです。 HOKAさん: 最後に、皆さんがこの分野に進んだきっかけを教えてください。 森野さん: 私はソフトウェア開発からセキュリティに興味を持ち、学び続けています。 笠井さん: もともとセキュリティやプライバシーには関心がありませんでしたが、ガバナンスの面白さに引かれました。 桑原さん: 私はインフラエンジニアとしてキャリアを始めましたが、自分の管理するメールサーバーが侵害された経験からセキュリティに取り組むようになりました。 HOKAさん: 本日はありがとうございました。セキュリティ＆プライバシー勉強会がKTCの皆さんにとって有益なものになることを期待しています。 皆さん、どうもありがとうございました。 今回はセキュリティ&プライバシー勉強会の詳細と、その運営の背景、今後の展望についてお届けしました。次回の勉強会も楽しみにしてください！

自己紹介 こんにちは。KINTOテクノロジーズの小山（ @_koyasoo ）です。今年からアジャイル推進に注力し始め、普段はスクラムマスター専任でチーム作りに励む毎日を送っています。今回はその中の活動を紹介したいと思います。 レトロスペクティブといえば・・？ みなさん、ふりかえり（レトロスペクティブ）していますか？ レトロスペクティブといえばKPT。ふりかえり手法のもはや代名詞と言われるようになってきましたね。KPTを使っている現場はものすごく多いと思いますが、果たしてそれは機能しているでしょうか？ 私は今年の6月にスクラムフェス大阪に参加し、色々なセッションを受ける中で1つ強烈に印象に残ったセッションがありました。 OODA！！！！！ （わかる人にはわかる） はい、いくおさん（ @dora_e_m ）ですね。いくおさんのふりかえりに関するセッションがとても印象に残りました。それまでふりかえりにはKPTしか使っていなかった私に 「ふりかえりが実りある場であり続けるために マンネリ化を避けたい」 という言葉がとても刺さりました。そこで「ふりかえりならいつもやっているし、すぐに行動に移せるのでは？」と思いました。 @ card 特にセッションの22ページ目に書いてあるように、KPTをYWT（KPTと似ている）に変更しただけで、めちゃくちゃ意見が出たというところが目から鱗でした。発想を変えるだけで意見って出るのか・・。  いくおさん資料22ページより引用 そこで、本記事では私が実際に実践した5つのふりかえり手法をご紹介します。 ふりかえり手法の使い分け方まとめ いくおさんのセッションにもあるように、状況にあったふりかえり手法を切り替えることができると、より良いチームの成長につながると考えています。以下に各手法の特徴をまとめてみたのでぜひ参考にしてください。 こんな時に使える！ 気をつけること KPT いつでも使えるオールマイティ こればっかりにならないこと 熱気球 チームの未来を考えたいとき 現状ある課題より過去のふりかえり要素が小さくなる LeanCoffee いろんな話題をしたいとき, ふりかえりじゃなくても使える 時間に追われてディスカッションするので少々疲れる Celebration Grid 事実に基づいてディスカッションしたいとき 実施したことが少なく、感じたことが多いタイミングだと意見が出ずらい FunDoneLearn ポジティブにふりかえりたいとき ネガティブが無視されがち 象、死んだ魚、嘔吐 チームに不満が溜まっていそうなとき チームが崩壊しないようにファシリテーションする 以降では、それぞれの振り返り手法について具体的にご紹介します。 ふりかえり紹介！ この記事を読んでくれた方（特に今までKPTしかやっていない方）にぜひ、 別手法を試す第一歩を踏んでほしい！ と考え、実施の仕方をできるだけ具体的に紹介したいと思います。やりやすいもので構わないので、ぜひやってみてください。意外とやってみたらKPTとそんなに変わらないです！ なお、紹介する例では基本的にオンラインホワイトボードツールの Miro を使用しています。 @ card 1. 熱気球 中央に描かれる「熱気球」を自身のプロダクトと置き換え、それに対しどんな「荷物」があったか、「上昇気流」は何か、今後妨げとなりうる「雲」は何だろうか、という考え方でふりかえりを進める手法となります。 熱気球のイメージ画像と、3種類の見分けられる付箋を準備しておけば実施可能です。我々のチームではこのような熱気球が作成できました。 熱気球の図 実施方法は以下のとおりです。 まず「上昇気流」について書き（5分）、ディスカッションを実施（8分）。 次に「荷物」について書き（5分）、ディスカッションを実施（8分）。 同様に「雲」について書き（5分）、ディスカッションを実施（8分）。 最後に「より熱気球を高く飛ばすために重要なことは？」という観点で議論（10分）。 この手法では現在を見つめ直し、未来を想像することにフォーカスが当たる議論が生まれやすいです。KPTと比べるとProblemがProblem（現在）、Problem（予想）に分解されるため、より課題点をディスカッションしやすい手法とも言えます。 2. LeanCoffee 話題の洗い出しから始まり、さらにそれらに対して短いタイムボックスに区切って様々な会話を実施する手法です。 話題洗い出し用の付箋を編集できるエリア、ディスカッションに選出された付箋を順番に処理するエリアを準備しておけば実施可能です。こちらはMiroにテンプレートがありましたのでそちらを使ってみました。 LeanCoffeeの図 実施方法です。 はじめに参加者にお題を挙げてもらいます（8分）。このときテーマを指定してあげると参加者が意見を出しやすいです。 投票機能などを使い参加者の興味のあるお題を特定します。 票数の多いものから順番に以下のサイクルでディスカッションします。 最初は5分間、お題の説明するところを含めてディスカッションを開始します。 5分経った時点で一旦議論を止めます。そしてこのお題でまだ続けるかを参加者に問います。投票機能を使っても良いです。 続ける場合は追加で3分、終わる場合は次のお題に移ります。 3分経った時点でも同様に議論を止め、再度続けるか問います。 続ける場合は追加で1分、終わる場合は次のお題に移ります。 最後の1分が終わったらそのお題は終了です。追加で話したい場合は別途時間を設けるようにして、その時間でのディスカッションは終了させましょう。 この手法はとにかく色々な話題が次々に移り変わりますので、たくさんのことについてディスカッションができます。また、チームメンバーのその時興味のある方向性が傾向としてみれます。さらに、メンバーのタイムボックスへの意識付けにも使えるかもしれません。 ファシリテーション時には特に議論を止めるのが難しいですが、タイマーで音を鳴らしたり、会話の切れ目などで何とか止めるようにしましょう。この手法はタイムボックスが守れないと崩壊してしまいますので注意です。 3. Celebration Grid 実施した事柄に対して「成功」「失敗」の軸と「間違ったやり方」「実験的なやり方」「既に知っているやり方」の軸で、六象限に分けてディスカッションを進める手法です。名前の通り、成功・失敗に関わらず起きたことをお祝いするポジティブなマインドで進めます。 こちらのサイトの図を使用して進めることが多いみたいです。 @ card  CelebrationGridのテンプレート 図の通り、それぞれのエリアは事象が発生する確率に合わせて大小サイズが異なっており、以下のような意味合いがあります。これらに沿ってディスカッションを進めました。 間違ったやり方 実験的なやり方 既に知っているやり方 成功 ラッキーだったね！ いい体験をしたね！ 正しいことをしたね！ 失敗 なるべくしてなった 大丈夫、学びはあったさ 運がなかった Celebration Gridをやってみた図 実施方法です。 期間を指定して「やったこと」を挙げてもらいます（5分）。それぞれどこに属すかを考えながら挙げてもらうように誘導します。 それぞれについて深掘ります。 最後に多くの気づきがあったことを全員で祝って終了します。 ぱっと見、難しそうな手法かと思いきや結構シンプルです。「発生した事象・事実」に基づいて会話が進むので、思想に捉われず事実と分離しながらディスカッションできます。逆に「事実」をまず挙げなければいけないので、参加者によっては意見が出ずらい場合があります。メンバーを集める際にできるだけ実働している人を選定するとうまくいきそうです。 4. FunDoneLearn 文字通り、Fun（楽しかったこと）、Done（やったこと）、Learn（学んだこと）を挙げていく手法になります。それぞれを包含する要素は円が重なるところに書いてもらいます。 それぞれの円を重ねたベン図のようなテンプレートを用意しておけば実施可能です。重なるエリアを大きくしておくと付箋が貼りやすいです。 FunDoneLearnの図 記載するほどではないですが、実施方法です。 期間を指定して、付箋を貼ってもらう（5分）。 それぞれに対してディスカッションする Funの要素があるように、ポジティブにフォーカスする手法です。全体的にハッピーな気持ちで振り返りが実施できると思います。逆にProblemのようなネガティブ要素が少ないので、それらが多そうな場合はあまり向かないかもしれないです。 5. 象、死んだ魚、嘔吐 3つの角度から課題を洗い出す手法です。象（みんな知っている課題）、死んだ魚（放置するとまずい課題）、嘔吐（心の中にある課題）といった具合で、メンバーから普段言いづらいことをぶっちゃけてもらいます。 象と魚と嘔吐の図があれば実施可能ですが、メンバーの個人間の対立を防ぐために大きめにルールを書いておくことを推奨します。 象、死んだ魚、嘔吐の図 実施方法です。 まずルールの説明をします。この手法でチーム内を対立させたいわけではなく、今ある課題に対して打ち手を考えたいだけであることを説明します。この手法では大事なポイントだと思っています。 それぞれに沿って付箋を挙げてもらいます（8分）。私のチームではネガティブに寄りすぎないように、反転してポジティブな意見になればピンクの付箋で追記してもらうよう案内しました。 特にこの手法では意見出しの最中に他のメンバーの内容が見えてしまうと、場合によってはモヤモヤしてしまうかもしれないため、編集中の付箋は公開しないようにします。MiroであればPrivate Modeを使うと良いです。 Private Modeを解除し、それぞれに対してディスカッションします。 ネガティブに向き合う手法のため、他の手法に比べると少々気を遣うことが多いです。ですが、そこまでネガティブな雰囲気にはならず、「そんなこと気にしてたのか〜」「同じこと思っていた！」などの意見が出ると予想されます。チームでの課題解決の方向性を合わせるのに非常に有効だと思います。 どのふりかえりにも言えること KPTを含め6つのふりかえりを実施した私の所感ですが、共通項は意外と多いです。 最終的なゴールはいつも「ネクストアクションをチームで合意する」 大きめにルールを書いておくと参加者が迷わない 意見は会の中で挙げてもらえばOK！ベースは5分、考えさせる内容なら8〜10分 ディスカッションではまず付箋を説明してもらい、次に「自分で感想を言うか」「感想ありそうな人に雑に振る」！（雑な方がフラットに意見が出やすいと思ってます笑） 自分も意見を出す場合は、事前に付箋を用意しておいた方がファシリテーションに集中できる 特に1番目の「ネクストアクションを合意」が意識できていれば、どの手法も回すことができます。それさえ決まればふりかえりを実施した価値になります。他のことは全て忘れても良いくらいです。 参加者からの感想 新しい手法を新しいメンバーで実施した後はいつも不安になります。ぶっちゃけKPTで良かったんじゃないか・・、色々指示しすぎて果たして振り返れていたか・・。 もしこんな思いをしていたら（自分のように）、恐れずにメンバーに感想を聞いてみましょう！きっとポジティブな意見しか返ってこないですよ。 いつもと違うふりかえりで新鮮だった。楽しかった。（熱気球） タイムボックスを意識して話ができたので、いつもは同じ話題で終わってしまうが色々な話ができて良かった。課題点が明確になった。（LeanCoffee） 失敗が多くなってしまったが、それがいい失敗なのか悪い失敗なのか分けて考えることができた。（Celebration Grid） チームメンバーが何に楽しさを感じて仕事をしているのかわかって良かった。シンプルに楽しかったことをシェアできたのも良かった。（FunDoneLearn） 思っていた課題がチームの共通認識にできて良かった。ぶっ込んでくれて助かった。（象、死んだ魚、嘔吐） まとめ どれかの手法に固定するのではなく、シーンに合ったふりかえり手法を選んで実施できるようになると、より良いチームになっていくと考えます。私もまだ6手法しか試せていないので、これからどんどん増やしていきたいと思います！ 冒頭でも記載した通り、まだKPTしかやっていない方がいればぜひどれかの手法を試してみてください！まずは本記事記載の流れで。慣れてきたらアレンジしてチームに合わせてみるなんてどうでしょうか。 この記事がレトロスペクティブで悩めるスクラムマスターの後押しになったら嬉しいです。

This article is day 1 of the KINTO Technologies Advent Calendar 2024 . 🎅🎄 Hello! Rina ( @chimrindayo ) here. I am an engineer at KINTO Technologies, where I am involved in the development and operation of Mobility Market and part of the Developer Relations (DevRel) Group as well. Today, I would like to tell you about a study session called “Mobility Night” that we have formed together with t-kurimura-san at Luup, Inc. 🙌 What is Mobility Night? Source: Documents created by t-kurimura-san Mobility Night is a collaborative study session aimed at advancing the mobility industry. It provides companies and organizations in this field with a platform to share their software technologies and expertise 🚀 We believe that many technical challenges in mobility-related software are shared across the industry, including areas such as GPS, IoT, quality assurance, and product design. This study session was created with the hope that sharing unique insights from the mobility industry on such topics will drive the advancement of software technologies and contribute to overall product improvement across the entire industry. The name "Mobility Night" was chosen to reflect our vision of creating a casual and inclusive space where everyone can come together to share and exchange information freely. Holding a Closed Event For the first event, we held a closed study session called “ Mobility Night #0 .” We invited Luup, Inc., Charichari, Inc., GO Inc., newmo, Inc. (all of which gave presentations), along with many other mobility companies, to join us. Participants shared mobility-related insights, with a focus on introducing their businesses and products to one another. We initially decided to hold a closed event to gauge interest in a technical study session focused on the mobility industry. This approach allowed us to assess whether such an event would resonate with participants and to identify common themes that could make future open study sessions meaningful and valuable for the community. Results from Holding a Closed Event Thankfully, the closed event was a big hit and a huge success. The event was so lively that some attendees continued the excitement by heading straight to an after-party 🍻 It felt inspiring to see people from different companies in the mobility industry engage in passionate discussions about current trends and what the near future holds 🔥 Here are some of the impressions shared by attendees in the study session questionnaire: Gathering insights about the mobility industry was highly beneficial. Industry-specific study sessions are great, aren’t they? With everyone focused on mobility, every discussion was incredibly engaging and fascinating to listen to! The information shared was closely related to my field, making me think, "I want to connect with these people again in the future." It had a warm and welcoming vibe, almost like being at home. Mobility Night Going Forward To ensure the continuity of these study sessions, we plan to hold them every other month (during even-numbered months) to start with. Currently, as the event is still in its early stages, only companies invited by the organizing members are giving talks. However, in the future, we aim to foster an environment where anyone feels comfortable stepping up to share, regardless of whether they were specifically invited by the organizers! If you’re interested in giving a talk, feel free to submit your entry via Connpass 🙌 (If we receive a large number of entries, speakers may be selected through a lottery.) We’re also sharing the latest updates about Mobility Night on Discord. If you’d like to participate in Mobility Night, are interested in giving a talk but want to discuss it with us beforehand, want to join as an organizing member, or are curious about it in any other way, please feel free to join us on Discord! Personally, I hope it becomes a space not only for sharing information about Mobility Night but also for initiatives like finding collaborators to co-host mobility-related study sessions. https://discord.gg/nn7QW5pn8B Notification about the Next Session We are going to hold Mobility Night #1! The schedule is as follows: https://mobility-night.connpass.com/event/334400/ Date and time December 5, 2024 (Thu), starting at 6:30 p.m. Theme GPS and location information Venue KINTO Technologies Muromachi Office We welcome everyone interested in the mobility industry to join us, whether or not they are currently part of mobility-related companies or organizations! Spots are limited, so if you’re interested, be sure to apply soon! We genuinely look forward to seeing you there.