はじめに QAグループのoshimaです。38年前なんてついこの間という感覚の、関西産・虎党のオッサンです。 大したスキルや資格があるわけではないものの、なんやかんや20年以上QA界隈でお仕事させていただいております。 現在は、すでにリリースされたサービス「KINTO ONE」「KINTO ONE(中古車)」「KINTO FACTORY」「モビリティマーケット」の機能改善やページのデザイン変更、また新規提供車種の紹介ページなど静的コンテンツ系のQAを担当しております。 今回はQA界隈では比較的使い古された概念「Verification」と「Validation」の違いのお話から、現在主に担当している案件に関してのご紹介と注力ポイント、個人的に考える課題（進歩させたい方向）に関して記載していきたいと思います。 「Verification」と「Validation」を取り上げるきっかけとしては、とある転職面接での質問として、「この二つは何が違うか説明せよ」というものがありました。それまであまり意識してこなかった二つの用語とその違いに関しては、十年近く前のことなのに印象深いエピソードとして心に残るとともに、現在のQAとしての仕事を再確認するにはいいキーワードと思い、取り上げました。 「Verification」と「Validation」の違いを簡単に説明 では「Verification」と「Validation」とはそもそも何なのか。そして違いに関してご説明します。 Google翻訳を利用すると、「Verification」も「Validation」もどちらの結果も「検証」となります。これだけ見ると同じようですが、厳密には Verification ・ 仕様書通りの表記や動作であること ・ 「正しく」作られていることを検証する Validation ・ 要求に合った表記や動作であること ・「正しい」ものが作られていることを検証する と検証したい内容が異なります。 例として（適切かどうか怪しいですが）あるイベントの告知ページのテストの際、「申込期限は11月31日」という記載を見つけたとします。ところが仕様書にも「申込期限は11月31日」と記載されている場合 Verificationの観点では、『仕様書とテスト対象が合致しているので正しい』 となりますが、 Validationの観点では、『11月は30日までであり、31日というあり得ない日付を期限にしているので本当に締め切りたい時期を指定できておらず不合格』 になります。 さすがにあり得ない日付を見逃すことはない（はず）ですが、例えばこれが契約に関しての法律用語や新サービスに伴い新たな概念の用語になると、誤字や表現に関して間違いか正しいかをQAで簡単には判断できないことになるので要注意となります。 実担当案件の特徴 上述の通り、私が主にKINTOテクノロジーズで担当しているのは、既存サービスの改善や新しい車種の紹介ページ、イベント案内ページなどの静的コンテンツの最終確認案件となります。その中でも比較的頻度やボリュームの大きい静的コンテンツに絞って話を進めます。 静的コンテンツ関連案件で行うQAは、一般的なプログラムのテスト業務とは少し毛色が異なりますが、KINTOのお客様が直接目にするコンテンツを対象としているため、力を入れて取り組んでいます。 テスト内容としては営業部門の作成した価格表やデザイン部門作成の車両画像などを元に構成されたページに対して、レイアウト崩れが出ないかであったり記載文言や数値の違いがないかの確認が主となります。 先ほど取り上げた「Verification」と「Validation」と絡めると、静的コンテンツ確認は「Verification」が主であり「Validation」の側面が少ない特徴があります。 「Verification」での貢献と課題 静的コンテンツ確認ではデザインや文言などの仕様が確定していれば、実際の確認作業自体は難しくない（注意力は必要）面があります。 ただし、弱点といえば肝心の仕様確定ができない限り、「Verification」の段階まで持ち込めないことにあります。この点、受け身にならざるを得ないところが課題であり、実作業では「〇〇のエリアは確認可能、××については後日更新」といった段階的確認となるため、融通を聞かせた確認作業を都度都度状況見つつ行う現実があります。 「Verification」での貢献としては、逆説的ですが「仕様が決まらない、曖昧である」点に対しての指摘をテスト開始前の段階で行うことで、テスト対象の品質向上を支えていることではと考えています。 テストの自動化を考えた場合、仕様や仕様に基づいた期待値が確定していれば、テストとしては仕様書と実装の差分比較になります。 そのため、自動で差分を検出できるという点では、目視より正確かつ実施工数も削減できることで、導入には適していると思います。 逆に、仕様や期待値が固まっていなければそもそも比較ができない、あるいは仕様変更が実装反映されていないことを検知できず、それだとテストを自動化したところで意味を成さなくなります。 『テストを実施するには正解を用意する』という普通のことをしっかりやる。岡田阪神同様、プロジェクトの成功には大事な点と考えています。 「Validation」での貢献は何ができるか 静的コンテンツの場合はデザインなどは専門部隊マターとなるため、QAから口を出すことはほとんどありません。ただ、UXなどデザイン要素を含めて知見のあるエンジニアならば、この点においても上流からの指摘をできる可能性はあります。 そこまで難しく考えなくても、新しいサービスの説明図をみて、「お客様が理解しやすいか」「図の内容はサービス内容を正しく反映できているか」といった指摘は、サービスの仕様に詳しくなることでやりやすくなると思います。この辺りは仕様書との比較ではなく、提供するサービスがお客様に正しく伝わるという視点での「Validation」につながるのではと考えます。 もっと卑近な例では、上述の「Verification」と「Validation」の違いに近いパターンで、ある車種の案内からリンクされている関連記事の確認を行なった際、指定されたURLは仕様書通りでしたが、記事内で取り上げられている車種が異なっているという間違いを指摘したことがありました。 この場合、Verificationの観点ではOKですが、Validationの観点ではNGとなります。厳密には正解かどうかを質すという視点からは少し異なりますが、間違いではないけどわかりにくい　といった、お客様に提供する品質としては高い状態を維持していければと思います。 おわりに などと大言壮語してみたものの、なかなか現実化できていない夢想に近い内容となっています。とはいえ、いつもの作業の繰り返しに終わらずに少しでも夢想を実現できるよう進歩していきたいです。 QAの進歩を我々と一緒に支えていただける優秀な仲間の方を募集しております。自分たちでは今まで出来なかったことを簡単にこなせてしまうスーパースターの方を特にお待ちしております。スーパーでもスターでもない方も一緒に頑張っていただける方なら大歓迎です。詳細は下記の採用ページをご参照ください。 最後までお読みいただきありがとうございました。

Self Introduction Nice to meet you, I am Iwasaki, the group manager of the Platform Group at KINTO Technologies Corporation. I joined the development and organization department of KINTO Corporation, the predecessor of KINTO Technologies Corporation, in December 2019. As an infrastructure engineer, I have been building and operating systems while promoting the launch of the group. In addition to being group manager, I am also responsible for SRE, MSP, and CCoE. I originally worked at an IT company that ran e-commerce sites. After working as a server administrator for on-premise and private cloud infrastructure environments, SRE team engineer, and part of management, I joined KINTO. My Goals for This Article In this article, my goals are to present you the teams we have in the Platform Group, as well as its past activities and its future, and make you, the reader, want to work with us. Platform Group Role The group is in charge of infrastructure design, construction, and operation with a focus on AWS Characteristics There is a mixture of standardized things and ideas that will be implemented in the future. We enjoy the unknown and proactively help others while receiving help in return. Organizational Structure Team name Number of members Location System Administrator 6 Tokyo and Osaka DevOps 6 Tokyo SRE 3 Tokyo DBRE 4 Tokyo MSP 3 Tokyo and Nagoya CCoE 2 Tokyo and Osaka as of November 2022 Some members are in more than one team Changes in Number of Team Members Although it has been three years, it is still growing, albeit not at the rate of Moore's Law. Team Members' Personalities Our team includes a wide variety of personalities. We are not hiring people in order to collect all 16 personality types, but I'd be happy to get people with different working styles, as we will be able to have more diverse discussions. FY23 Group Slogan This is the slogan for this fiscal year. We envision focusing on increasing the utilization of the various products released in the first half and linking this to our results. FY2023 Group Mission This is the group mission for this fiscal year. For Agility and Stability, we originally aimed for +10% on a quarterly basis, and our message is that we will challenge ourselves to see what we can do to further accelerate that. Team Introduction The System Administration Team :::message Provides a stable infrastructure environment through cloud engineering work (network/system design, construction, operation, response to infrastructure failure) ::: A team of AWS professional engineers and the core of the Platform Group that is responsible for operation work such as IaC system construction and system change, as well as improvements for things such as system pack releases and application monitoring. Recruitment page The DevOps Team :::message Improves development speed and quality through DevOps team launch support :::: A team of professionals who are familiar with AWS and application tuning and operation. It is responsible for providing CI/CD through GitHub Actions and promoting DevSecOps. One of the key figures behind KINTO Technologies Corporation's switch to a container service (ECS), it is currently focusing on implementing and spreading APM, distributed tracing (X-ray), and other processes. Recruitment page: No recruiting planned The SRE Team :::message Ensures safe and secure services by promoting proposals to improve SLA :::: A team of experts responsible for the reliability of future products. It is creating SRE guidelines and building up the SRE hierarchy from the bottom up to find out how to improve reliability. It also narrows down products and provides SRE support to the Development Group. Recruitment page The DBRE Team :::message Uses expertise in databases to make recursive processes and strategic decisions :::: A team of database specialists. It provides tools to visualize databases and improve their reliability and is establishing security measures, masking measures, and other measures. Recruitment page The MSP Team :::message Helps indirectly improve development speed and quality by supporting application operation ::: The MSP Team is the administration team that cooperates with partner companies, which take on the roles of the service desk, handling application failures and inquiries, and primary system maintenance, performing primary operations for failures and routine work. Recruitment page: No recruiting planned The CCoE Team :::message Creates a secure cloud environment governed by appropriate policies :::: A team of cloud security specialists. Creates cloud security guidelines, implements guardrails, and provides AWS/GCP educational support. Recruitment page The Trajectory of the Platform Group's Activities Switching to an In-House Infrastructure Design, Construction, and Operation The first thing we did was switch from an outsourced system environment to our own AWS environment while converting 24x7 surveillance and other operations to make them in-house. Although we considered it a switch to in-house, we started by doing construction work and a system where one person was on 24x7 PagerDuty. Using Terraform IaC (Infrastructure as Code) to Create Modules with a Focus on Overall Optimization Next, we switched to IaC. We had excellent engineers join us, and we decided to fully switch to IaC. We also adopted Terraform with a focus on multicloud. We started EC2 construction by creating an OS image (AMI) with Packer + Ansible and finishing it with Terraform. The initial designs of the Terraform modules were the cornerstone of the switch to ECS. Switching to Container Service (Moving Away from EC2 and Proceeding with ECS) Next, we switched to containers (EC2->ECS). We chose ECS instead of EKS because there were many system configurations built for individual products at the time, and we thought ECS had lower learning costs, including CI/CD, and made it easier to switch to containers. Since we expected that the Development Group would be granted access rights for release work after the switch to containers, we wanted to switch while reducing the engineering burden of the Development Group as much as possible and lowering implementation costs. CI/CD (GitHub Actions) Provision, Education, and Implementation Support CI/CD was essential to drive the switch to containers. Even if I told them that they could use containers with ECS, it was meaningless unless they could see the merits. So, we provided CI/CD with GitHub Actions and started providing DevSecOps elements that allowed information to be pushed and analyzed statically if used with the CI/CD provided by SonarQube. System Release (Reducing the Time Spent Building One System Configuration from Two Weeks to Three Days) Next, we worked on providing a system pack. By narrowing down the system types that are often requested in advance to about six types and having the minimum required input information, we can do the system configuration on AWS and deliver it in three days. This is a system pack. By doing this, we were able to reduce stress and time when doing interviews during the system design process, and I think it contributed to improving relationships with the Development Group. About 70% of requests we have today are to build a Dev environment with a system pack, then have it customized with the content dropped as conditions from STG, PROD, and Pack reflected in the system while the application is being designed. Starting Provision and Implementation Support for MSP (Managed Service Provider) Implementation and Development While we worked on the system packs, we also worked on the Development Group's first response to problems and tried having an external contractor operate the routine work. It might not have been necessary for the Platform Group to do this work at the time, but the company was still growing at the time, and we wanted to further contribute to the development group and started supporting it while cooperating with some of the Development Group members and contractors. Now, the MSP is becoming the center of inquiries from business divisions and affiliates, and it has become an important presence. Enhancing Application Monitoring Next, we worked on strengthening monitoring. However, the infrastructure monitoring and system design were already almost complete, so we targeted application monitoring. Starting Log Platform (OpenSearch) Implementation and Implementation Support Initially, we only provided CloudWatch as a log platform, but when the logs were not stored in JSON format, the logs were separated in chronological order when they were viewed, and it was difficult to analyze them when they were sent from multiple servers. To address this, we built and provided OpenSearch, which is an AWS managed service. At the time, we knew that providing OpenSearch alone would not increase usage, so we also provided the container image of the ECS sidecar (fluentbit), which sends logs to OpenSearch, and added it to the CI/CD template. Starting APM (Application Performance Management: Prometheus and Grafana) Implementation and Implementation Support After switching to containers, it became necessary to monitor resources of in-container applications. To address, we are providing APM with AWS Managed Prometheus and Grafana. We also provide a sidecar (Open Telemetry) similarly to the log platform and provide an easy-to-use environment. related blog: Collecting application metrics from ECS for Amazon Managed Service for Prometheus by @sokasanan Starting Distributed Tracing (X-Ray) Implementation and Implementation Support We have started providing distributed tracing (X-Ray) as three pillars of monitoring enhancement. This makes it possible to visualize communication between containers and communication to the backend endpoint and DB, and problems can be identified instantly. Conclusion After getting through the startup stage, the group has entered a growth period. We are improving our on-boarding process to welcome you after joining the company. If you are interested, please do not hesitate to apply for a casual interview with me.

非インフラエンジニアのためのIstio入門 こんにちは。Woven Payment Solution開発グループの楢崎と申します。 我々は、 Woven by Toyota で Toyota Woven City で利用される決済基盤アプリケーションの開発に携わっており、バックエンドからWebフロントエンド / モバイルアプリケーションまで決済に関わる機能を横断的に開発しています。 その中で私は主にバックエンドアプリケーションの開発を担当しています。我々が開発している決済バックエンドはマイクロサービスを構成しており、City PlatformというKubernetesをベースにしたプラットフォーム上で動作しています。 今回は、 Istio というKubernetes上でマイクロサービスのネットワークを構成する仕組みを、普段ビジネスロジック等のコードを書いているバックエンドアプリケーションエンジニアにもわかりやすくその目的や機能を解説したいと思います。 この記事でIstioを用いた設定の理解がより深まり、トラブルシュート時に原因の切り分けやインフラ・ネットワークエンジニアと円滑にコミュニケーションが出来るような一助になれば幸いです。 Istioって何? マイクロサービスアーキテクチャを採用すると、処理は複数のサービスにまたがり、サービス間の通信が発生することになります。 アプリケーションエンジニアとしては、つながればどうでもいいと思ってしまいがちですが、インフラエンジニアは、そのネットワークレイヤーの制御を効果的に行いたいと考えています。 そこで、ネットワークの経路やセキュリティなどの各種設定をKubernetesのマニフェストと同様に宣言的に一元管理し、ネットワークの状態を統合的に運用監視できることを目指す目的でIstioは作られました。ネットワークが網目状になっていることから、これらの機能をまとめてサービスメッシュ(Service Mesh)と呼ぶこともあります。 Istioのアーキテクチャ: データプレーンとコントロールプレーン まず、Istioのアーキテクチャを知っておく必要があります。IstioはKubernetesと同じく「コントロールプレーン」と「データプレーン」に分かれています。 KubernetesはKubectlなどからAPIのリクエストを受けて、Pod等のリソースをコントロールするコントロールプレーンと、実際にアプリケーションが動作するPodなどがデータプレーンとなります。 Istioのデータプレーンでは Envoy というネットワークプロキシが採用されています。コントロールプレーンが必要に応じて、我々が書いたコードが動作するコンテナの横にサイドカーコンテナとしてEnvoyを注入します。 コントロールプレーンとデータプレーン なぜIstioが必要か Envoyは単体でも動作可能なネットワークプロキシアプリケーションです。その設定項目は非常に多岐にわたり、1つのEnvoyインスタンスを意図した通りに設定するのも簡単なことではありません。(少なくとも非インフラエンジニアにとっては！) 複雑なマイクロサービスアーキテクチャではそのネットワークが網目のようにクラスタ内外を接続し、たくさんのEnvoy Proxyを設定する必要が出てきます。個別に設定して全てを思い通りに動作させていくことが如何に大変か想像に難くないでしょう。 Istioで設定可能なリソース Istioを導入することによって、利用可能になる機能として以下のようなものが挙げられています。 トラフィック管理(サービスディスカバリ、負荷分散) オブザーバビリティ(ロギング、分散トレーシング) 認証・認可などセキュリティ 一方で、バックエンドアプリケーションエンジニアにとってみれば、それぞれがブラックボックスになっていて、実際に何が設定可能なのか、意図せぬ挙動に出くわした際にどの設定ファイルをみればいいのかわからないことが、今までの我々の経験上多々ありました。 Istioの設定可能なリソースがどのような意味を持つのか、いくつか具体的に見ていきましょう。 Gateway IngressとEgressというKubernetesのネットワークに関するリソースがありますが、IstioはGatewayと呼ばれるEnvoy Proxyで通信をインターセプトします。文字通りIstioネットワークへの出入口になります。 以下のファイルで設定できます。このファイルそのものにアプリケーションエンジニアが知っておくべき細かな設定が出てくることはほとんどありませんが、他のファイルから gateways という形で参照されることが多いので、まず適切にGatewayが設定されているか確認しましょう。 apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: test-gateway spec: selector: istio: ingressgateway # Istioをインストールするとデフォルトで使えるLoadBalancer Service servers: - port: number: 80 # Listenしているport name: http protocol: HTTP # 許可しているプロトコル hosts: - "*" # Host名 Virtual Service Kubernetesには Service というDeploymentやStatefulSetをクラスタ内ネットワークからアクセスできるようにする仕組みがあります。 一方でIstioのVirtual ServiceはServiceまでどのような経路をとるかを定義します。 非常に多くの設定値が定義出来て強力な反面、他の設定と重複するところがないか注意が必要です。自分が使っているサービスに対してリクエストが届かない場合は何かしらのミスがVirtual Serviceの設定で起こっている場合があります。 istioctl analyze コマンドで設定ミスを教えてくれる場合もあるので見てみましょう。 apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: test-virtualservice namespace: test spec: hosts: - "*" # 指定されたホスト名。このホスト名が指定されたときに、以下のルールが適用される、という意味。*だと任意のホスト名に対してルールが適用される gateways: - test-gateway # 前述のgatewayを指定。複数指定可能 - mesh # Gatewayを介さないクラスタ内通信を許可する場合ここに'mesh'を定義 http: - match: # リクエストをフィルタリングするためのルールが記述可能 - uri: prefix: /service-a # URIのパターン。Regexなども選べる route: - destination: host: service-a # 宛先のサービス port: number: 80 - match: # 複数のルーティングのルールや接続先を定義可能 - uri: prefix: /service-b route: - destination: host: service-b port: number: 80 　exportTo: - . # このルールをどこに適用するか。Kubernetesのnamespace。.(ドット)の場合、このルールが設定されたnamespaceのみに限られる Authorization Policy 特定のサービス間通信を制御する事ができます。具体的には、プロトコル、特定のパスへのルーティング、HTTPメソッドの指定など、事細かに修正できるので、アプリケーションエンジニア側でも設定する機会が多いかもしれません。 一方で、ルールの設定をミスする場合も多く、思わぬ落とし穴も多いので設定後は必ずテストを実行するようにしましょう。 apiVersion: security.istio.io/v1beta1 kind: AuthorizationPolicy metadata: name: access-allow-policy namespace: test spec: selector: matchLabels: app: some-application # Podについているラベル action: ALLOW # 許可ルール rules: - from: # リクエスト送信元の定義 - source: principals: - cluster.local/ns/test/sa/authorized-service-account # Kubernetesのサービスアカウント to: # リクエスト受信側の定義 - operation: methods: ["POST"] # 許可するHTTPメソッド paths: - "/some-important-request" # 許可するエンドポイント --- apiVersion: security.istio.io/v1beta1 kind: AuthorizationPolicy metadata: name: deny-policy namespace: test spec: selector: matchLabels: app: some-application action: DENY # リクエストを拒否する例 rules: - to: - operation: paths: ["/forbidden-path"] その他の設定 Destination Rule Service Entry Peer Authentication Envoy Filter などの設定ファイルがありますが、ここでの説明は割愛します。基本的に、Kubernetesのリソースと同じく、スキーマが定義してあり、それぞれ設定項目があります。もしチーム内で利用しているリソースがあれば、どんな項目が設定可能か、一度ドキュメントを確認しておくとよいでしょう。 よくあるデバッグ、トラブルシューティングの具体例 まず最初に、設定に不具合がないかを確かめましょう。 istioctl analyze コマンドを実行すれば大体の設定ミスはエラーとして報告されます。本番環境などRBACが有効になっていて、Istio関連のリソースに対して制約がある場合、権限をもつインフラエンジニアに実行してもらいましょう。 設定に関して、エラーになるような設定ミスがない場合、リクエストがどこまで到達しているか確認します。Gatewayで通信が途切れているか、アプリケーションのPodまで来ているかを確認するために、アプリケーションもしくはサイドカーのログをみましょう。Gatewayを通過しているように見える場合は、 kubectl logs pod <pod-name> -c istio-proxy -n <namespace> のようなアクセスされるべきPodのnamespace上でサイドカーコンテナのログを確認するのが良いでしょう。 クラスタ内の通信であれば、 curl をコンテナ上で実行すれば良いですが、最近のDockerのベースイメージはコンテナアプリケーション実行に不要なアプリケーションは含まれていない事が多いので、 k debug <pod-name> -n <namespace> -it --image=curlimages/curl:latest -- /bin/sh のようなデバッグ用のコンテナをアタッチしてクラスタ内で名前解決できるか調べてみましょう。 通信が遮断されているような場合であれば、Virtual Serviceファイルを見る、認証周りが怪しければAuthorization Policyファイルをみることで、設定の不具合の場所までたどり着けると思います。ルーティングや認証周りはどうしても複数のレイヤーで設定された項目がコンフリクトし易い箇所になります。Podにどのような認証ルールが適用されているかは istioctl x authz check <pod-name>.<namespace> というコマンドで一覧に出すことができます。 また、一見ネットワークのエラーのように見えて、実装に問題がある場合も多々あります。並行して実装側もネットワークや認証認可の設定を見直してみると良いでしょう。 以下が私がネットワーク関連のエラーに出くわしたときに実施していることです。 Istioの設定が間違っていないか、 istioctl analyze コマンドを実行したり、ログをみて原因を切り分ける クラスタ内外から curl や kubectl debug コマンド等を利用してネットワークの疎通確認を実施する デプロイしたアプリケーションが正しくインフラレイヤーで指定したportのリクエストをlistenしているか等、アプリケーションの設定を確認する クライアントアプリケーションが必要な認証認可の仕組みを実装しているか、リクエストを調べてみる これらは Kiali などのオブザーバビリティスタックの設定が有効であれば、GUIで設定ミスや通信のステータスを確認することも可能です。 最後に 具体的に設定可能な項目とその意味を知ることによってブラックボックス化されていた機能の一端が垣間見えたかと思います。 また設定項目が意外とシンプル、と思われた方もいるのではないでしょうか？ 一方でIstioの難しさはネットワークを構成することそのものというよりは、継続的に安定して運用する(バージョンアップのパッチを当てる、その度に動作を検証する)といった、本番運用フェーズだと思います。 バックエンドアプリケーションエンジニアとして実際の運用に向けて、Istioの挙動を理解するのはもちろん、アプリケーションの挙動をテストすることも検討したいですね。

はじめに はじめまして！QAグループのyamaです。 2023年5月にKINTOテクノロジーズに入社しました。 普段は主に KINTO Unlimited のQA業務に携わっています。 今回のテーマについて 今回は「品質向上の取り組み」として、私が入社後に取り組んできたことについてお話していきたいと思います。 QAグループ 今後の展望 上図はマネージャーの zume が社内発表時に示したQAグループの今後の展望です。 QAが立ち上がって約3年、チームとして安定してきた所で 次になにをやるか？を表しています。 私が入社したのは、ちょうどそんな時期になります。 前職のシステム開発会社でも、QAを生業として「質が高いテストを提供することで品質向上に貢献する」ことを目標に活動してきましたが、経験を積むとともにテストで品質を担保することの難しさを感じるようになっていました。 バグを潰すだけでは限界がある。そもそもバグを作りこまないようにすることが必要だ…と。 そこで、次はこの取り組みができる職場で仕事がしたいと思い、KINTOテクノロジーズに入社しました。 現状把握 入社後、まずは社内の開発＆QA工程と担当プロジェクト( KINTO Unlimited )の現状把握に努めました。 すると、当初私が想定していたよりも開発スピードに対するウェイトが高いことがわかりました。 (前職でもスピードは求められていましたが、KINTOテクノロジーズほどではありませんでした) これはKINTO/KINTOテクノロジーズが新しいサービスを創り出す事業会社であり、遅れがビジネスチャンスの損失に繋がるためです。 なるほど…と納得しました。 従って、品質向上の施策を打つ際は、開発スピードが低下しないようなやり方が必要だと感じました。 また 前職の経験から、担当者に負担が掛かる(≒メンドクサイ)やり方は長続きしないことも分かっていたので、なるべくシンプルなやり方にしようと考えました。 一方で、今のプロジェクトには現在の品質を客観的に見る指標が足りないことに気づきました。 自分たちが作っているプロダクトの品質状況が見えないと、「バグを作りこまない」ための改善ポイントが見えてこないので、まずは品質を可視化する仕組みを作るところから始めることにしました。 やったこと とは言え、いきなり「品質UPのために●●やりましょう！」とブチ上げたところで、すんなり受け入れてもらうのはなかなか難しいもの。 そこでまずは開発案件を通し、従来より少し踏み込んだ形での品質分析を行い、プロジェクトへ分析結果をフィードバックしてみました。 その時点ではバグ票に品質分析用の項目が充分ではなかったため、一旦QAチームにて個々のバグ票の解決経緯を調査、分類して品質分析を実施しました。 分析資料(抜粋) そして、案件終了時の振り返りの場で分析結果を披露し「バグ票にこういった分類項目があれば、今よりも品質状況や現状の課題が見えてくるかも！」とアピールしました。 分類項目は絞り、入力方法をシンプルにすることで、出来る限り担当者の負担にならないようにすることも添えて。 新たに取り入れた分類項目 その結果、ありがたいことにこちらの提案が受け入れてもらえることになり、現在は上記の品質分類用項目を組み込んだ状態でバグ票の運用が始まっています。 今後やりたいこと 品質向上に向けた取っ掛かりを作るところが出来たので、今後は得られた情報をプロジェクトに定期的にフィードバックし、解決すべき品質課題を開発/QAで一緒に考えていくようにしていきたいと考えています。 またこの取り組みを継続的に行い、品質状況の推移(改善状況)を可視化していく予定です。 そして、ゆくゆくは他案件にも水平展開することで、その流れをより大きいものにしたいと思っています。 それが 冒頭に示した「QAグループ 今後の展望 ⇒ 全体品質向上」に繋がると信じて、取り組んでいこうと考えています。

Hello! I am Asahi from the backend team of the New Car Subscription Development Group of the KINTO ONE Development department. I work on system operation development in order to provide KINTO ONE services. In August 2023, we released a major system renewal. During my years of working in system development, I have worked with many different teams, growing together and gone through many cycles of trial and error. But today I would like to talk about a GitHub Actions workflow we created in my current team, as I am very happy with the result and how is able to speed up pull request (from here on, PR) reviews. Details on processing below Everyone puts off code reviews Do you prefer coding or reviewing code? I prefer coding by far. I am fully aware that code reviews are an important process for ensuring system quality. Even so, do you ever prioritize coding whenever a deadline is near and put off code reviews? Even when we started implementing them in the system revamp project, there were many times when I had PRs that were left open without being reviewed, even though the code was finished. As a result, my team had many of the following issues. We could not complete tasks, and it was hard to measure the team's progress We could not start working on tasks that had dependencies, or they were affected by other tasks Merging conflicts were likely to occur In order to speed up creating PRs and prevent these issues, we introduced a GitHub Actions workflow which I will talk about here. About GitHub Actions Our company uses GitHub as a source management tool. GitHub Actions is an automation tool used with GitHub that lets you describe processes that you want to automate in a workflow, put them in a repository, and process them whenever you want. It is a function of GitHub that integrates well with GitHub events. @ card Automatic reviewer configuration workflow Today, I will talk about using GitHub Actions workflows to automatically set random reviewers and send a Slack notification whenever a PR is created. Comments stating that the PR creator automatically assigned reviewers is put in the PR. Details on workflow processing Workflows are executed when a PR is created. The workflow sends a request to AWS Lambda (from here on, Lambda)[^1]. Information on team members is defined in advance during Lambda processing. At that time, it has the "specifications leader" and "technology leader" attributes. Other than you, a specifications leader and a technology leader will be chosen at random to be reviewers. The reason why it’s two is because of our team rules (at least two people must review in order to merge a PR). Information on the two members picked through Lambda are automatically set to PR reviewers, and comments mentioning the reviewers are placed. The assigned reviewers are notified through their designated Slack channels. Linking with Slack Webhook [^1]: AWS Lambda is a serverless AWS service that can execute processes defined as functions. Recommendations Filter reviewer configurations to the minimum number of people If you limit reviewers to the minimum number of people instead of including everyone, you won't think, "Even if I don't review it, someone else will look at it," and depend on others or put off reviews. Assign team members as "specifications leaders" or "technology leaders" There were concerns that if the number of reviewers was limited, the assigned members' strengths and weaknesses would cause differences in review quality. For that reason, each member was assigned as either a "specifications leader" or "technology leader" beforehand. Members who specialized in information on domains looked at mainly specifications, and members who specialized in technology or had just joined and were studying specifications looked mainly at the technology aspect. Sharing team member information across repositories In order to execute a process in multiple repositories, each repository must have the same workflow. If the information on the members is defined in each workflow, when a member's information is updated (e.g., when a new member joins), all workflows that were configured must be revised. For that reason, we implement the process of randomly selecting reviewers in Lambda and commonize each repository so they can reference each other. This way, we can update information on member just by revising Lambda processing. Instant confirmation is possible with Slack notifications The set reviewer can immediately confirm by using a Slack notification process in the workflow. We have email notifications from GitHub, but integrating all of our communication tools makes sure that nothing is overlooked. Reducing work through automation GitHub Actions has received a lot of attention as a CICD automation tool. Apart from what I covered today, there are other ways to automate work similarly to workflows. Although it was originally meant to speed up PR reviews, I have experienced the benefits of automation after using it myself. If you try this workflow process, you may hesitate to request a review based on the team member's status, or you may need to send additional messages on Slack. These are not major hassles. My team has used these workflows for over two years, and we have saved a considerable amount of labor. This tool is essential to us now. Sample workflow code Here is a sample workflow (one that does not require Lambda). Feel free to customize and use it. name: "Auto Assigning Reviewers" on: pull_request: types: [opened, ready_for_review, reopened] jobs: assigning-reviwers: runs-on: ubuntu-latest if: | github.event.pull_request.draft == false steps: - uses: actions/checkout@v3 - uses: actions/setup-node@v3 with: node-version: 16 - run: npm install @slack/webhook - uses: actions/github-script@v6 with: github-token: ${{ secrets.GITHUB_TOKEN }} script: | const { IncomingWebhook } = require('@slack/webhook') // Define member information const MEMBER_INFO = [ { slackName: "@MsSpecification", speciality: 'spec' ,slackMemberId: "XXXXXX", githubName: "XXXXXX"}, { slackName: "@MrSpec", speciality: 'spec' ,slackMemberId: "XXXXXX", githubName: "XXXXXX"}, { slackName: "@TheSpecSpecialist", speciality: 'spec' ,slackMemberId: "XXXXXX", githubName: "XXXXXX"}, { slackName: "@SkilledEngineer1", speciality: 'skill' ,slackMemberId: "XXXXXX", githubName: "XXXXXX"}, { slackName: "@Specialist2", speciality: 'skill' ,slackMemberId: "XXXXXX", githubName: "XXXXXX"}, { slackName: "@Newbie1", speciality: 'skill' ,slackMemberId: "XXXXXX", githubName: "XXXXXX"}, ] // Acquire PR creator const user = context.payload.sender.login; const author = MEMBER_INFO.find(member => member.githubName === user); // Select two random reviewers const skills = MEMBER_INFO .filter(member => member.githubName !== author.githubName) .filter(member => member.speciality === 'skill'); const specs = MEMBER_INFO .filter(member => member.githubName !== author.githubName) .filter(member => member.speciality === 'spec'); let getRandomNumber = (min,max) => Math.floor(Math.random() * (max - min + 1)) + min; const chosenSkillMember = skills[getRandomNumber(0, skills.length - 1)]; const chosenSpecMember = specs[getRandomNumber(0, specs.length - 1)]; const issue_number = context.issue.number const pull_number = context.payload.pull_request.number const { repo, owner } = context.repo // Set PR reviewers await github.rest.pulls.requestReviewers({ owner, repo, pull_number, reviewers: [chosenSkillMember.githubName, chosenSpecMember.githubName] }); // Set PR assignees github.rest.issues.addAssignees({ owner, repo, issue_number, assignees: [user] }); // Slack notification const title = context.payload.pull_request.title const html_url = context.payload.pull_request._links.html.href const message = `Hi! <@${chosenSkillMember.slackMemberId}> <@${chosenSpecMember.slackMemberId}> \n You were selected as PR reviewer of <@${author.slackId}> 🥳 \n <${html_url}|${title}>` // Specify the webhook URL of the Slack channel you want to notify const webhook = new IncomingWebhook('https://hooks.slack.com/xxxxxxxxx') await webhook.send({ text: message, }) // Comment on PR await github.rest.issues.createComment({ owner, repo, issue_number, body: `@${chosenSkillMember.githubName},@${chosenSpecMember.githubName} was selected as reviewer 🚀` }) Conclusion I spoke as if the idea was all mine, but I should thank my teammate Jeong-san for giving us this wonderful tool and ideas. Jeong-san always proposes convenient tools to us. An article by Super Jeong-san will be published tomorrow, so look forward to that. Have fun automating with GitHub Actions!

はじめに こんにちは。KINTO テクノロジーズで KINTO FACTORY (以下FACTORY) というサービスのバックエンド開発・運用をしている伊藤です。 今回、アドベントカレンダーに参加することになりましたので、FACTORY でのマスタ運用の改善活動について書いてみようと思います。 KINTO FACTORY のマスタ運用について KINTO FACTORY で取り扱っている車種や商品、施工時にお車を持ち込む店舗等の様々な情報をマスタデータとして保持しています。 ※商品価格は2023年12月11日時点での金額です。最新価格は KINTO FACTORY サイト でご確認ください 元となる情報はトヨタや各販売店から提供され、企画の部署で EXCEL に入力します。 その後、EXCEL は開発チームに連携され、CSV に変換して FACTORY に登録されます。 結構つらいオペレーション いざ運用が始まってみると、いろいろとつらみがありました... 10個近い EXCEL を CSV に保存、改行コード変換、BOMの削除を手作業で行うため手間がかかる 入力されたデータのチェックを EXCEL 関数で行っていたため、ファイルが重くなる... チェック用のEXCEL 関数の作りこみが難しく、人の目で見て確認する必要もある EXCEL に入力する項目が多く、重複しているものもあり、入力ミスが発生する 一回きりの作業ではなく、検証環境で確認＆修正を繰り返すため、塵も積もればで工数がかかる 改善したい 上記のようなつらみを解消するために、以下のような改善を行いました。 EXCEL の入力フォーマットの見直し まずは EXCEL の入力フォーマットを見直しました。 将来的に使用することを想定して用意されている項目を削除 重複している項目や、他の入力値によって決定される項目を削除 EXCEL 関数を使用した入力補助 不要項目を削除することによる入力の負担軽減、EXCEL 関数や入力規則による補助で入力ミスも改善前と比べて75%程度削減することができました。 EXCEL から CSV への変換を自動化 次に EXCEL から CSV への変換を行うツールを Golang で開発しました。 EXCELの読み取り、チェック、CSVへの変換を自動化 EXCEL 関数で行っていたチェックをツールで行うことで、使用するEXCEL 関数を減らす EXCEL に項目追加があっても、Go言語で開発したツールの微修正で対応 EXCEL から CSV への変換を自動化することで、変換にかかる手間を削減、手動オペレーションによるミスを軽減し、これまでほぼ1日がかりだった作業が数分で完了するようになりました。 EXCEL で行っていた作業をツールに移行することで、EXCEL職人になりつつある状態から解放されました！（個人的にはこれが一番うれしい） まとめ FACTORY のマスタ運用の改善について書いてみました。 今回は EXCEL のフォーマットを見直し、CSV への変換を自動化したことで、入力ミスの軽減、作業時間の短縮を実現しました。 ただ、まだまだ課題はあり、特に企画と開発間のやり取りの時間はどうしてもかかってしまうため、入力から検証環境への取込、確認を一気通貫で行えるような仕組みを検討中です。 今後もマスタ運用の改善を続けていき、より良いサービスの提供を支えられるようにしていきたいと思います。 さいごに KINTO FACTORY では新たな仲間を募集していますので、ご興味があればぜひ下記の求人をチェックしてみてください！ @ card @ card

はじめに みなさんこんにちは、 KINTOテクノロジーズ株式会社 開発支援部の有留です。 現在は開発支援部にて、いわゆる「組織開発」や「教育研修」の領域をメインに、 会社にとって「必要なこと」にクイック＆アジャイルに対応する仕事をしております。 《今回のお話》 KTCでは、毎月1回全社員（社員・契約社員・派遣社員）が 参加する「開発・編成本部会」を開催しています。 今回は、このミーティングの紆余曲折について、お話したいと思います。 「テックブログなのに、テクニカル要素が無いじゃないか！」という声も聞こえてきそうですが、 私、今日はこの記事をOsaka Tech Labから書いているので、 記事の内容はともかく、書いている場所は「テック」です！ また、仕事柄色々な企業様とお話することがありますが、 どこの企業様も「組織風土醸成」「社員の定着」など「人」「チームづくり」 に関して悩んでいらっしゃるように感じており、 まさに「モノづくりは人づくり！」だと感じる毎日です。 同じように組織づくりで悩んでいらっしゃる方の参考になれば幸いです。 《開発・編成本部会って？》 KINTOテクノロジーズ株式会社の開発・編成本部会は私が入社する前の2021年7月、 社内LT会のような形で、3部署からそれぞれの取組を発表したのがスタートのようです。 当時の議事録によると、参加者は約160名とのこと・・・。 （現在は330名を超える社員がいますので、会社としてだいぶ大きくなりました。） 以降、毎月1回、開催しており、 副社長の景山からのプレゼンに加え、2〜3部門から各部署の取り組みをLT形式で発表し、 その中で1案件「景山賞」を決定。景山より、副賞をプレゼントしています。 《そもそも、なぜ開発編成本部会が開催されていたの？》 元々部署毎に縦割りの風土が強く、情報共有の文化が薄かったこと 事業立ち上げフェーズのため実務がかなり忙しく、どうしても実務優先になってしまい、風土醸成が後回しになったこと 社員数が増えるにつれ、副社長の景山との距離が遠くなってしまったこと などなどの理由です。 コロナ禍の事業立ち上げで、オフラインの交流機会も限られており、 「せめてオンラインで月1回コミュニケーションを図る」ことが経緯のようです。 元々はマネージャー（現・開発支援部 部長K氏）が企画運営を担ってきましたが、 私が入社したことで、内容の見直しに着手することにしました。 2022年4月頃の本部会から運営を引き継ぎ、 1年半、試行錯誤を続けながら、運営してきました。 《課題設定：内容の見直しに向けて〜気をつけたポイント》 リニューアルに向けて、下記3点を課題と捉え、取り組むことにしました。 ①コミュニケーション改善 当初はLT会形式かつ完全オンラインでスタートしていたこともあり、 当初は「一方的に発表を聞く場」になってしまっており、 社員間のコミュニケーションも活発ではありませんでした。 「とりあえず参加しているだけ」の社員も多数見受けられる状況で、 「何だか経営会議っぽい社員総会だな・・・」と驚いたことを覚えています。 ②景山賞の改善 また、現場社員にとっては、実務が多忙な中で、5分程度のLT資料を 作成することが負担になってしまっているように感じました。 また組織の拡大につれて、景山以外のマネージャーも増えていたため、 「よりボード陣が複眼でメンバーの頑張りを表出出来る仕組みづくりが必要」と考えました。 ③他部門の仕事内容理解や取り組み共有 以前より、「他の部門が何をやっているか分からない」等の声が 全社員アンケートで寄せられていたため、本部会という時間を通して、 より他部門の仕事内容/取り組み内容の理解が深まる仕立てにしたいと考えました。 《打ち手〜取り組んだこと》 ①コミュニケーション改善 コメントスクリーン というツールを導入し、 画面上にリアルタイムに絵文字やコメントが流れる仕立てとし、 より双方向のコミュニケーションが生まれるようにしました。 「ライブ感があって良いね！」という声があった一方で、 「茶化してるように感じる」「発表資料が見づらい」という声もあり、 試行錯誤を続け、現在はSlackでのコミュニケーションに移行しています。 全社員が入社と同時に「本部会コミュニケーションチャンネル」に入っており、 毎月の部会では、リアルタイムにSlackでやり取りを重ねています。 毎回「お昼ごはん何食べました？」というラポールが盛り上がります！ ちなみに、弊社オフィス周辺には美味しいご飯屋さんがたくさんあり、 メンバーでランチに行った報告も多い一方、 「レッドブル」「食べてない」といった悲しい声も少数派ですがございます・・・笑 あ、明確に書き残しておきますが、ちゃんと休憩は取れる会社です！ （本当に休みは取りやすい組織風土で、このあたりは弊社の良いところだと思います） ②景山賞の改善 実施趣旨を、「マネージャーが日々のメンバーの頑張りを見逃さないこと」と改めて定義し、 マネージャーがエントリーし、エントリー理由および表彰文を書くスタイルに変えました。 また、以前は受賞案件を副社長の景山が決めていましたが、 マネージャーの事前合議で決定することにしました。 メンバーが、ノミネートや受賞のために資料を作ることがなくなり、 マネージャーが「メンバーの日々の頑張りに気を配る」きっかけなるように仕立てています。 「日々の頑張りが、自然と評価される」風土、文化に変わっていくと良いなと思っています。 ③他部門の仕事内容理解や取り組み共有 毎月、各マネージャーの持ち回りで、グループ内での 注力案件や、取り組み内容を共有してもらう設計に変更しました。 必要に応じて、景山からも補足のコメントをもらうことにしています。 各部署マネージャーの取り組み共有＋景山からの補足が加わることで、 社員にとっては、具体性を持って、会社の動きを知るキッカケになっているようです。 また、年末年始には「今年の漢字」「今年の目標」を発表してもらうなど、 飽きないように、動きをもたせることを意識しています。 それ以外にも、各部署のイベント情報をTwitterから抜粋して投稿したり、 テックブログの取り組みを発表したり、 「本部会に出れば、何となく会社の動きがわかる」場になるように意識しています。 →上記①〜③の取り組みに加え、毎月前月のアンケート結果を冒頭で公開するなど、 　なるべくオープンコミュニケーションの場になるように、気をつけています。 《取り組みの結果》 まだまだ道半ばではあるのですが、本部会への社員参加率は徐々に向上しており、 社員数が増えている中でも、ほぼ全社員（300名近く）に毎月参加いただいています。 カメラオン（顔出し）での参加や、Slackへのコメントも徐々に増えてきました！ また、社員からも、アンケートで嬉しいコメントをいただく開催回が増えてきました。 【社員からのアンケート（一例）】 各部署で何をやっているのか。は毎回興味深いです。 また、各部署に対しての景山さんの想いを聞くのも参考になります！ すごく内容の濃い会となっていて、良いと思います。一般的に、こういう全体会議って、内容が薄いor後で資料だけ見れば良い、みたいなケースが多い中、最近のKTC全体会議は異色（良い意味で）かなと。 普段関わりがあまりない各部の状況がわかる場なので助かります。 おわりに いかがでしょうか？ 今後は、「2024年今年の漢字」の発表や、 リアルイベント（オフラインでの本部会開催）などにも、 徐々にチャレンジしていきたいと思います。 弊社の良い風土の１つは、 『新しい取り組みやチャレンジに関して、会社も社員も、寛容なところ」だと思います。 通常の大手企業グループでは実現が難しいことも、比較的クイック＆アジャイルに実施可能です。 また、失敗しても、良くも悪くも前例がないので、 （あまり怒られること無く？）ネクストアクションに活かす事ができます。 もちろん成功したら、褒められます（笑） そして、「やりたい！」と声を上げると、力を貸してくれる社員が多い風土です。 イベントなどでお会いした際には、みなさまの会社の取り組みもぜひ教えてください！ 弊社も負けないように、チャレンジしていきたいと思います！

Introduction Hi, I am Rina, and I work in the development and operation of “mobility market”, one of our products at KINTO Technologies. I mainly work as a frontend engineer using Next.js. My hobbies include gaming and I recently started getting into Minecraft 🎮. It’s that time of the year again when KINTO Technologies will start with the Advent Calendar 🎄. In this article, I will break down the changes in our 2023 version, upgraded from last year! Past Advent Calendars This year's Advent Calendar will be the third one since KINTO Technologies started holding them in 2021🎄 We did not have a Tech Blog yet when the 2021 Advent Calendar started, so our volunteering team members wrote the articles at the Qiita Advent Calendar. https://qiita.com/advent-calendar/2021/kinto-technologies We launched the KINTO Technologies Tech Blog in July 2022 where we were able to hold our own Advent Calendar that same year 👏 The articles had two themes: the first one, to spread awareness of technologies acquired individually, and the second, to present each department in the organization. They are focused on sharing the employees’ technical knowledge and work styles. https://blog.kinto-technologies.com/posts/2022-12-01-advent_calendar/ (Reference: About the Advent Calendar ) Advent Calendar 2023 As usual, this year's Advent Calendar will come in two series! Last year, we created two Advent calendars, but this year we plan to have one with two series comprising a total of 50 articles. https://qiita.com/advent-calendar/2023/kinto-technologies-tech Not only that... but there will also be giveaways 🎅✨ Please invite your friends and colleagues to join us! https://qiita.com/advent-calendar/2023/kinto-technlogies Now, I will explain the themes of the 2023 articles! 1. Technical Articles We will talk about the skills and technologies that each KINTO Technologies employee has acquired this year. We will publish technical articles on a wide range of fields, including infrastructure, backend, mobile, and organizational development. Through the articles, you can learn how the employees of KINTO Technologies work to solve problems and acquire skills every day, and about their work attitudes! 2. Article Relays This year, there will be an article relay with five themes! The themes were selected among large-scale projects launched this year and topics that were popular at in-house study sessions. (1) New Vehicle Subscription Site Renovation We launched the renovated new vehicle subscription site (KINTO ONE) In August 2023🎉. This was a large-scale project with a development period of about two and a half years. The site renovation made it easy to add new features and improve it, and we were able to build a more modernized site. This series of articles is about the improvements and technology stacks that the people involved in the project have made in order to improve the site! (2) Agile Development The company uses agile development, a software development methodology, for the development of multiple projects and products. We have been holding study sessions on agile development for a long time, but since the main focus was sharing information in a closed environment, such as individual departments, starting this year, we are going to focus on promoting agile activities throughout the organization . We have created the Slack channel #help-agile-scrum, where you can exchange information about agile development, and will hold sprint demonstrations for other teams so people throughout the organization can exchange information casually. In this series of articles, we will give some examples and ideas of Agile that we are working on for different products! (3) KINTO FACTORY KINTO FACTORY is a service enabling Toyota and Lexus vehicle owners to keep their vehicles up-to-date by introducing modularity. It allows users to customize both software and hardware functions promptly, in alignment with new technical updates. KINTO FACTORY obtains master data from Toyota and its dealerships, and the implementation is conducted in collaboration with Toyota's affiliated companies, while considering together the appropriate data structure. There will be articles giving glimpses of the entire back office operation, from EC site reception to ordering of parts to delivery. Other articles will be published focusing on front-end technology. We recently released a split QR code reading feature for vehicle inspection cards. The articles will include how we are developing these features and how we are working daily on "evolving" our site to make it easier for users to use. There will also be articles about building operational structures and adding new features! (4) QA This is a series of articles by the group responsible for pre-release verification of various services provided by KINTO Technologies. KINTO Technologies, which is part of the Toyota Group, needs high quality control standards in software development. Data is linked between each product including those from KINTO ONE and KINTO FACTORY. Verification across multiple products is also important for quality control. Each product development member performs tests in their product scope. The QA Group is important and not only verifies individual products, but also verifies products among other products, and collects information and cooperates as a communication hub for entire products (projects). The QA group, which is indispensable to KINTO Technologies, will write about the importance of communicating with the development team to verify products and managing quality! (Reference: Introduction to the QA Group ) (5) Diversity & Inclusion The company has many colleagues with diverse backgrounds and from various nationalities, and about 25% are not Japanese (as of November 2023). We have many mothers and fathers with young children, and the number of men who take childcare leave is increasing. In this series of articles, we will focus on the careers and work styles of non-Japanese members, including how they work depending on their stage of life and lifestyle, and how they manage international teams, and we will write about leadership, parental leave, and communication in cross-cultural teams! (Reference: Active Non-Japanese Employees ) https://qiita.com/advent-calendar/2023/kinto-technologies-tech Gift Calendar This year, we will be participating in the Qiita Advent Calendar gift project! We will award gifts to the top three people who posts the best content here✨ The theme is CCoE Christmas! Post a story of how cloud technology has helped bring kaizen (improvement) to your organization! . Among the various activities, we will focus on CCoE! We are taking the lead in CCoE activities across the Toyota Group, taking the stage at events such as AWS Summit Tokyo 2023 and AWS Autotech Forum 2023, and hosting the DBRE Summit 2023. Now, we are accepting stories from engineers about how cloud technologies have helped with their kaizen ! Whether you are a vehicle lover or not, tell us about how you have brought improvement (à la Toyota) in your daily work. The Gifts🎁 KINTO Unlimited Award (1 person) Apple AirPods Max - Space Gray KINTO ONE Award (1 person) Anker PowerExpand Elite 12-in-1 Thunderbolt 4 Dock (APEX) Docking Station KINTO FACTORY Award (1 person) BenQ ScreenBar Halo Monitor Light ScreenBar Halo USB Desk Light https://qiita.com/advent-calendar/2023/kinto-technlogies Conclusion In this article, I gave an overview of the 2023 Advent Calendar🎄. I hope that the KINTO Technologies Advent Calendar will lead you to new discoveries. We will post the latest information on the Advent Calendar, lectures, and more on X. Please follow us there. https://twitter.com/KintoTech_Dev I hope you forward to the 2023 Advent Calendar as well ✨

はじめに こんにちは。KINTOテクノロジーズ(以下KTC) プラットフォームグループ PlatformEngineeringチームで内製ツールの開発・運用をおこなっている山田です。 今回はPlatformEngineeringチームで開発をしているCMDBについて、内製化に至った背景、機能や使用技術についてご紹介したいと思います。 CMDBとは CMDB(Configuration Management Database：構成管理データベース)とは、ITサービスを提供する上で必要不可欠な資産とその構成を一元管理するものです。 CMDBの管理対象となる資産(ITサービスの提供に必要なインフラ、プロダクト情報、プロダクト担当者などの人的リソース等)のライフサイクル、情報の管理がCMDBの主な役割となります。 CMDBを内製化した背景 CMDBの導入前では社内のプロダクト数が増えていくにつれてプロダクトごとの資産情報管理が一元管理されず属人化していました。またインシデント発生時にプロダクトの担当者や影響範囲を迅速かつ的確に判断することが困難となっていました。 これらの問題の解決策として社内の資産情報を一元管理するCMDBの導入が検討されました。 CMDBの商用製品はいくつかありますが、導入・運用コストやカスタマイズ性などを考慮した結果、内製化する運びとなりました。 CMDBの機能紹介 KTCのCMDBではプロダクト管理やチーム管理のような基本的な機能に加え、プラットフォームグループの他チームが開発したツールとの連携などの特徴もあります。 まだ開発中の機能もありますが、ここを見れば知りたい情報が見れる！を実現するために日々機能追加に取り組んでいます。 プロダクト管理 ここではプロダクト名や所属部署、管理チームなどの基本的な情報を管理しています。 もしあるプロダクトで障害が発生した場合、簡単にプロダクトの担当者を見つけて連絡を取ることができます。また複数のマイクロサービスで構成されるプロダクトがある場合、どのチームがどの機能を開発しているかも管理されているため、障害発生時に適切な担当者の判別が的確にできるようになりました。 以下がプロダクト詳細画面で、プロダクトに紐づくチームやドメイン情報を確認できます。今後はプロダクトがどの環境に存在するかなどの情報も追加予定です。 また、「SID」という項目がありますがこれは後ほど説明します。 ドメイン管理 プロダクトに紐づくドメインを管理します。 チーム管理 プロダクトに紐づくチーム情報を管理します。 管理者管理 ユーザー、グループ単位で権限を管理します。 DB管理 ここでは同じプラットフォームグループのDBREチームが開発したツールとの連携をおこない、KTCで管理する全てのRDSの情報をCMDB上で簡単に閲覧できるような仕組みを提供しています。 RDSの基本的な情報に加え、DBREチームが設定したポリシーに則ってDB設計ができているかや、ER図を確認することができます。 セキュリティ管理 セキュリティ管理では、ECR上のリポジトリとその脆弱性情報を管理します。 週次でECRリポジトリのスキャンを実行して脆弱性が見つかった場合、運用サポートをおこなうMSPチームがリポジトリを管理するチームへの連携をおこないます。そのときに利用するスキャン結果のExcelファイルと担当者への対応依頼用のJiraチケットを作成するCSVファイルの出力も提供します。 スケジューリング管理 AWSのコスト削減を目的として、開発環境のEC2, ECS, RDSを一定時間停止させるスケジューリング管理機能を提供します。 これにより稼働する必要のない平日の深夜や土日を対象としてサービスを停止させ、コスト削減に繋がるようになります。 外部連携 外部連携ではAWS上のsandbox環境へのAutoProvisioning(自動環境構築)システムとの連携と履歴の管理をおこなっています。 詳しくは以下の記事に書かれているため、是非ご覧ください！ https://blog.kinto-technologies.com/posts/2023-05-30-AutoProvisioning/ SIDについて ここまで機能の紹介をしましたが、これらのデータの紐づけ方法としてKTCには SID という概念があります。 SID とは Service ID の略で、KTCで管理しているプロダクト単位で固有の識別子を設定しています。 例えばCMDBであれば kakazan というSIDを設定しています。 kakazan(花果山)は西遊記の孫悟空が生まれた山とされているため、ここから名前を取りました。 KINTOの名前は西遊記に出てくる孫悟空の筋斗雲が由来となっているため、KTC内でのプロダクトのSIDには西遊記由来のものが多く存在していて面白いです。 このSIDは各プロダクトの名称として使用しており、それぞれのプロダクトの所有者を明確にするなど、KTC内で浸透している概念です。 特にAWSリソース管理の面では、一つのプロダクトでECS、RDS、S3、API Gateway など、多くのAWSサービスを使用します。 どのリソースがどのプロダクトの所有物なのかを判別するために有効なのがTag設定で、リソースにはSIDタグを付けることでリソースとプロダクトを紐づけています。 CMDBではこのSIDタグの設定を活用することで様々な情報と連携させています。 使用技術 ここではCMDBの開発で使っている技術要素について簡単にご紹介します。 フロントエンドはReactで開発していて、バックエンドはSpring Boot製で認証認可やユーティリティクラスを提供する共通フレームワークと、その共通フレームワークを依存関係に持つサービス3つ(メインサービス用、DB管理用、外部連携用)で構築しています。また、バッチ処理はSpring Batchで開発しています。 システム構成に関してはまた別の機会に詳しく書ければと思います。 これから まだ開発中の機能やこれから開発をしたい機能がたくさんあるため、これからも機能追加をしていく予定ですが、それと並行して試したい技術もあります。 例えばKTCではコンテナ実行環境としてECSを使っているためEKSを使ってみたり、(開発規模的に不要ですが)マイクロフロントエンドを試してみたり、PWA(Progressive Web Apps)を導入して社用スマートフォンからCMDBのダッシュボードを見れるようにしたり、、、 社内システムだからこそ試せる部分もあると思うので、将来的に社内に展開できるような技術を試す場としてもこのシステムをうまく利用していきたいと思います。 また、CMDBの開発でも使っている共通フレームワークの機能充実やKINTOのブランドイメージにあわせたReactのコンポーネント群を作成して、ライブラリとして全社に展開できればと思います。 さいごに 今回はKTCで開発しているCMDBについて、その開発背景から機能、そして将来のビジョンについてご紹介しました。 KTCではKINTOで扱っているサービスだけでなく、さまざまなシステムの開発に取り組んでいます。この記事を通じて、KTCの取り組みに少しでも興味を持っていただけたら嬉しいです。

はじめに こんにちは、プロジェクト推進グループに所属している沼田と申します。KINTO FACTORY のバックエンドエンジニアとして日々開発に勤しんでいます。 今回は KINTO FACTORY のサービス紹介と今年の夏に行った DX 化についてお話しします。 KINTO FACTORY とは KINTO と聞くとサブスクの印象を抱く方が多いと思いますが、 KINTO FACTORY （以下 FACTORY）は毛色が違い愛車に長く乗れるようさまざまなアップグレードサービスを提供しています。 具体的にはシート張り替えやホイールキャップ交換など内装/外装を変えたり、ドアの開閉速度を向上させたり、ソフトウェアの書き換えたりするなど愛車をカスタマイズすることができます。 トヨタグループの車種（トヨタ、レクサスや GR）が対象で取り扱う車種や商品、エリアは順次拡大中です。 私はこれまで車といえば一度買うと次の車に乗り換えるまで特に手を加えない印象があったので、FACTORY の取り組みはチャレンジングで面白いと感じています。 施工の流れ FACTORY は KINTO 単体ではなく、トヨタや販売店と連携しながらサービスを提供しています。 ※ 画像内の番号は厳密な流れではなく、あくまでイメージです。 まずお客さまが FACTORY のサイトで商品を申し込むと FACTORY からトヨタに必要な部品を発注すると共に、お客さまが選択した販売店に申し込み内容の共有をします。 販売店は申し込みの内容を確認した後、お客さまと入庫日程の調整を行います。入庫日を確定した後は入庫日にお客さまが販売店に車を持ち込み、販売店は納品された部品を元に施工を行います。 施工が完了次第、販売店からお客さまに連絡を行いお客さまに納車することで施工完了となります。 商品や施工内容によって詳細は異なりますが、大まかな流れは上記のようになります。 施工証明書の DX 化 施工証明書は初めて聞く方もいらっしゃるかもしれません（私は入社してから知りました）。施工完了後にお客さまにお渡しするもので、施工内容や施工日時、施工した販売店などが記載されています。 これまではお客さまに納車する販売店で施工証明書を手作業で作成していましたが、今年の 8 月から FACTORY 上で発行できるようになりました。 施工証明書発行の流れ 購入した商品のステータスが 施工完了 に変わると、マイページ（FACTORY ではマイページのことをマイガレージと表現しています 😃）の購入履歴から発行できるようになります。 画面イメージ: 施工証明書ボタンを押すと下図のように別タブで施工証明書が表示されダウンロードできます。 現在、施工証明書の発行は GR 関連の商品とイベント商品を除くすべての商品に対応しています。 また、2023 年 10月 から始まったインボイス制度にも対応しており、支払い明細書も FACTORY から発行できます。 アーキテクチャや技術スタック アーキテクチャ周りも軽く紹介します。 FACTORY は AWS 上で稼働しており、ざっくりとした概要図ですが上図のような構成でマイクロサービスアーキテクチャを採用しています。 施工証明書を発行するマイクロサービスは Go 言語で開発しており、PDF 発行のライブラリとして gopdf を使用しています。発行された施工証明書は S3 に保存されます。 PDF のテンプレート 弊社は Office365 を導入しているため、PDF の雛形管理にエクセルを用いています。変更があればエクセルの雛型を修正し PDF としてエクスポートします。 トヨタの施工証明書 LEXUS の施工証明書 車種によって施工証明書のデザインが変わることに加え、商品名の文字数もさまざまなためどちらにも影響がないようにレイアウトを決めるのに苦労しました。 手作業で作成していた施工証明書と同じ A5 サイズにしているのは小さなこだわりです。 余談: 今回の対応で初めて PDF をプログラムで扱ったのですが、正直こんなに愚直な作業とは思いませんでした。 施工証明書の DX 化を経て これまで販売店で手作業で行なっていた施工証明書の発行を FACTORY 上で行えるようにすることで、お客さま、販売店ともにより良い体験を提供できるようになったと思います。 施工証明書以外にも手作業で行なっている作業がまだまだあり、自動車業界の DX 化の余地はたくさんあると感じています。 今後も FACTORY はより良い体験を提供できるように、さまざまな取り組みを行なっていきます。 さいごに FACTORY では一緒に FACTORY を盛り上げていく新たな仲間を募集しています。カジュアル面談のご応募お待ちしています！ @ card

Introduction Hello. I am Koike, a data engineer in the Analytics Group. At my previous job, which I started as a new graduate, I mainly performed analyses for service growth, but in my current position, I am developing a data analysis platform. To put it simply, I changed my career from a data analyst to a data engineer. In this article, I would like to talk about my journey from being a data analyst to a data engineer. Data Analysts and Data Engineers As there might be some who are not familiar with the roles of each, I'd like to begin by outlining the responsibilities of a data analyst and a data engineer. The responsibilities of each role are shown in the diagram below. Data engineers are responsible for preparing data for data analysts to aggregate and analyze. Their specific tasks are as follows. Acquiring data from other systems and data sources. Processing data obtained in 1 into a form that is easy for data analysts to use. Delivering data processed in 2 to allow data analysts to access it. In contrast, a data analyst is responsible for aggregating and analyzing the data and suggesting how to improve the business. Their specific tasks are as follows. Aggregating data prepared by data engineers using SQL or other tools. Analyzing the data aggregated in 1. Suggesting how to improve the business based on the results of the analysis in 2 Or, they may do the following tasks. Aggregating data prepared by data engineers using SQL, or other tools. Summarizing the data aggregated in 1 in a dashboard and creating an environment where data can be observed at a fixed point I hope this gives you a general idea. With this in mind, in this article, I would like to show you how I changed my career from a data analyst to a data engineer and started working as the latter. I hope this information will serve as a reference for those considering a career transition to become data engineers. The Data Architecture of KINTO Technologies Before talking about data platform development, I will explain the company's data architecture first. It is mainly composed of AWS services, and the general flow of data is as follows. Using a service called Glue, data obtained from external sources is converted, processed, and stored in S3 An SQL query is performed on S3 data using a service called Athena Our data engineers mainly do part 1, creating an environment in which various data can be aggregated and analyzed in Athena. Glue Workflow Development Now that you understand the data architecture, I will talk about the Glue workflow I developed as my first step from data analyst to engineer. Glue has three main features. Job: Function that does preprocessing of analyses (data extraction, conversion, loading) Crawler: Function that creates metadata in the Data Catalog. Trigger: Function that runs jobs and crawlers manually or automatically A Job is the function that performs preprocessing for an analysis. For example, you can define a series of processes such as reading, processing, and outputting CSV data as a single job. The Crawler has the function of creating metadata in the Data Catalog. Basically, you can define data types such as table input/output formats and column names, and put them in a box called a Data Catalog. A Trigger is the function that runs a Job or Crawler manually or automatically. It can be executed at a fixed time every day, or when the previous job is successfully completed. In addition, a workflow combines these three processes into a series of processes to make them easier to manage. By developing a workflow that allows data from external sources to be aggregated in Athena, I got a general understanding of the data flow and took my first step as a data engineer. By the way, when I was a data analyst in my previous job, I was in an environment where data engineers aggregated and analyzed formatted data, so I did not pay much attention to how the data was created. However, during development, I was able to better understand how triggers and jobs are combined and other parts of data preprocessing. It was a great experience. Comparing the Skill Set of Analysts and Engineers So far, I have talked about the job of a data engineer, but I would like to outline the skill sets that are required for data analysts and data engineers. The Data Analyst Skill Set Analysis and design Aggregation Analysis Explaining results of analyses The first skill required by a data analyst is the ability to analyze and design. For example, if a marketer says, “I want this data.” You can just output data as you are told, but doing so could lead to rework. Therefore, it is necessary to clarify the original purpose by asking why they want you to output that data, and determine what kind of data you can output and analyze to achieve that purpose. That is analysis and design. Next is the ability to aggregate. This refers to extracting data that you want using SQL or other tools. It is surprisingly difficult to learn how to check figures to check there are no mistakes in the extracted data written with SQL, or how to write SQL with few mistakes. Next is the ability to analyze. Basically, it is the ability to think logically without subjectivity. To do this, you may need to know about statistics, machine learning, and so on. The last skill is the ability to explain the results of analyses. No matter how sophisticated your analysis is, it has no value unless it can be applied to the business. It only has value when you explain it properly to the decision makers and get them to understand it. The Data Engineer Skill Set Data pipeline Design Code design Data processing The first is the ability to design data pipelines. To compare with what I have explained in this article, you can think of it as the ability to determine how to configure the data processing workflow to produce the data you are looking for. Next is the ability to design code. I think this true for all engineers, not just data engineers, but coding does not end with writing and may need to be modified later. Therefore, it is important to write code that is easy to maintain. The last skill is the ability to process data. We mainly use SQL and Python, it is necessary to be able to handle them sufficiently. We have now compared the skill sets necessary for a data analyst and a data engineer. Future Outlook So far I've told you about half a year of my experience since I changed my career from a data analyst to a data engineer. Looking back, I have been able to grow my skills as a data engineer little by little, but now I feel like I am losing my perspective as a data analyst because I'm concentrating too much on development. Therefore, in the future, I would like to remember to create a platform that is easy for users to use. No matter how beautiful the data platform is for developers, it has no value to the business unless the data analyst effectively communicates its output to the business side. In order to avoid this, I will use my experience as a data analyst and as a data engineer and work hard every day to be able to connect data to value from start to finish!

はじめに こんにちは。ご覧いただきありがとうございます！ KINTO FACTORY （以下 FACTORY）というサービスで、フロントエンド開発をしている中本です。 この度、アドベントカレンダーに参加することになりましたので、今年リリースした「車検証の２次元コード読み取りの実装」についてお話させて頂こうと思います。 導入の動機 FACTORY では、現在お客様がお乗りのクルマを「アップグレード」や「リフォーム」、「パーソナライズ」といった観点から長くお乗り頂けるサービスを展開しております。 FACTORY のフロントエンドは EC サイトのような役割となっており、お客様のクルマ情報から、取り付けが可能な商品を検索でき、実際にお申し込みまで WEB 上で完結することができます。 そこで重要となってくるのが、車種や年式・グレードといった、現在お客様がお乗りのクルマの情報となってきます。 車種・年式・グレードなどの情報から、どの商品を取り付けることができるか、や商品の組み合わせ可否、などを判断しております。 FACTORY では、それらの情報を正確に判定するために「車台番号」とよばれるものを使用しております。ご存知の方も居られるかもしれませんが、実は車検証を眺めてみると「車台番号」といったシリアル番号のようなものを見つけることができます。（下図の中の左上から３つ目の欄） ※出所：国土交通省「自動車検査証（車検証見本）」（ https://wwwtb.mlit.go.jp/hokkaido/content/000176963.pdf） FACTORY では、こちらの「車台番号」を入力することで、そのクルマに取り付け可能な商品を簡単に探すことができます。 商品一覧ページ（車台番号で商品検索済み） ここで、下図の車台番号を入力するフォーム部分を見ていただくと、リリース当初は図のようにユーザーによる手入力フォームとなっていました。 車台番号入力フォーム 車台番号入力による検索機能は、今年の６月にリリースしたのですが、リリース当初よりこちらの入力欄に直接慣れない英数字を入力することは困難ではないか、と思っていました。 特に、昨今の EC サイトの例に漏れず、FACTORY へのアクセスはスマートフォンからがほとんどとなっております。 画面の小さいスマートフォンで、何桁もの英数字を入力頂くのは手間であり、また入力ミスも起こりやすく、入力ミスしてしまうと車両自体が FACTORY の非対応車両となってしまい、適合する商品が見つからないといった機会損失に繋がっているのではと考えました。 そこで目を付けたのが、車検証の右下の方にひっそりと印刷されている２次元コードでした。 車検証の２次元コードから読み取れる情報 国土交通省の 電子車検証 特設サイト にある通り、車検証の２次元コードから上記の検索で使用する「車台番号」を読み取ることが可能でした。 また、FACTORY で取り付けたい商品が見つかり、実際に購入へ進もうとした場合、まずお客様のクルマ情報を登録する必要があります。この登録には、上記の「車台番号」以外に、ナンバープレートの情報も必要となっております。車検証の２次元コードには、基本的に車検証に書かれている情報が入っており、これらを読み取ることで、上記の商品の検索に加えそのまま購入に進んで頂いたときの車両登録も簡単に行えるのでは、と考えました。 実際に車検証を見られた方だとお分かりかと思いますが、下図にあるように２次元コードには、３つ並んでいるものと２つ並んでいるものとがあり、過不足なく読み取ってもらう必要があります。また、それぞれの２次元コード単体のみでは情報が分割されて格納されており、すべてのコードを読み取った後に順番通りに並べて結合する必要があります。 そこで、それぞれのグループのどの位置のコードを読み取っているか、をわかりやすく画面へフィードバックしたいと考えました。 ※出所：国土交通省「２次元コードについて」( https://www.denshishakensho-portal.mlit.go.jp/assets/files/Two-dimensional_code_item_definition.pdf ) 読み取り UI の実装 スマートフォンのカメラを使って読み取ったものを画像処理し、２次元コードをデコードしてくれる Java Script ライブラリにて解析するといった流れとなります。「カメラで読み取る」部分や、「２次元コードのデコード」は初めての試みだったので WEB で情報を集めながらテストしていきました。 カメラの読み取りには、 getUserMedia() の Web API を、２次元コードの解析には qr-scanner という js library を選定しました。 流れでいうと、 getUsetMedia で読み取ったものを canvas 要素へコピーしつつ、 qr-scanner へ転送しコードを解析、データが読み取れたらどの位置のものかを判断する、といったものとなります。 実装のテストをしている段階で、少し難しかったのが、新車検証の場合２次元コードの読み取り率が少し悪いということでした（なかなか読み取れないなど）。 というのも、実は車検証ですが、今年の１月に電子車検証というタイプに変更がされており、最近クルマを購入された方や車検をした方だとお分かりかと思いますが、以前のもの（A4 サイズ）よりかなり小型化（B5 サイズ）されております。 これに伴い、２次元コード自体も少し密度が高くなったような印象があり、なかなか読み取れない状況でした。 そこで、２次元コードをデコードする qr-scanner のソースを眺めながら、Grayscale の設定値を調整していくことで、新・旧どちらのタイプの車検証もある程度の確率で読み取れるようになりました。Canvas へ画像データをコピーした後、上記 Grayscale の設定値を使って、白黒画像へコンバートしそれを２次元コードの解析ライブラリへ送信するといった動きでしたが、値によっては車検証自体の模様などがゴミとして映り込んでしまい、それにより読み込み率の減少を招いていたようでした。 https://github.com/nimiq/qr-scanner/blob/master/src/worker.ts#L73-L79 UI の実装自体は、リアルタイムにカメラで写している画像を見ながら、読み取れた２次元コードの位置をグループ別に示していきたかったので、上部に読み取りの必要な数だけ BOX を並べ、読み取れた２次元コードの枠にチェックアイコンを表示するようにしてみました。 実際の読み取り画面が下図のようになります。 コードの読み取る順番は関係なく、読み取ったコードの位置が正しく認識されていることが分かるかと思います。すべての情報を読み取ると、手入力にて車台番号検索した時のように画面が遷移します。 リリースしてみて こちらの２次元コードによる検索機能は 10 月にリリースすることができました。このリリースからしばらくは、上記説明の中での画面例のように、商品一覧ページのみへの適応だったので、劇的にこちらの機能が利用されたとは言いづらいですが、現在はトップ画面へも適応されております。トップページから、２次元コードを読み取ることで、対応車両のチェックや商品適合のチェックまで一度で行えることができるようになっており、利用率向上を見込んでおります。 また、「読み取れる情報」の部分でも少し触れましたが、２次元コードには車両登録に必要な情報も含まれているので、今後は車両登録時にもこちらの情報を使っていき、できるだけ手入力部分を減らすことで利便性や入力ミスの削減を狙っていきたいと思います。 最後に スマートフォンの台頭や、Web コンテンツのリッチ化、各種 Web API の拡充によって Web サイトの可能性が広がっているように思います。 例えば、リアルタイムによる OCR や NFC タグの読み取りなど、非接触技術なども含めてユーザーの利便性を考えながら新しい技術にも積極的にチャレンジしていきたいと思います。 より簡単に、楽しく KINTO FACTORY を使っていただけるように、色々なアイデアを実現していく方法を模索していきたいです！ 最後に、私の所属する KINTO FACTORY では一緒に働く仲間を募集しています。 ご興味があればぜひ下記の求人をチェックしてみてください！ @ card @ card

こんにちは KINTOテクノロジーズ 人事採用グループのHOKAです。 組織人事と採用広報を担当しています。 X（旧Twitter） も担当しております。 さて、年に1度のアドベントカレンダーの機会に、「人事採用グループがどう立ち上がったか」をTechblog につづります。 どうか最後までお付き合いいただければ幸いです。 開発組織、KINTOテクノロジーズ設立 KINTOテクノロジーズ株式会社（以下、KINTOテクノロジーズ）は2021年4月に設立し、現在3年目です。2023年12月時点で従業員数は320人を越えました。文字通り「急成長」している企業です。 そもそもKINTOテクノロジーズは、株式会社KINTO（以下、KINTO）のITエンジニアを中心とした開発組織「IT開発編成グループ」でした。KINTOテクノロジーズ設立前は、KINTOでITエンジニア採用を担当していましたが、ITエンジニアはどこの企業も人手不足の売り手市場。優秀なITエンジニアを採用するには、採用手法をIT業界に合わせる必要があるのではないか、という仮説が浮上しました。そこで、IT業界でのエンジニア採用経験がある岩本さんがKINTOテクノロジーズで、ITエンジニアの採用をスタートしました。いわゆる「一人目人事」です。 「エンジニア採用」だけがミッションだった 初めは「エンジニア採用」だけが岩本のミッションでした。 岩本さんが参画した2021年11月時点では、KINTOテクノロジーズの社員数は約130人。人事部門を立ち上げる話はなく、採用担当は岩本のみ。秘書の志田さんと共に始動します。 製造業のやり方ではITエンジニアは採用できない まず、岩本さんが着手したのが、IT業界の採用スタイルに変えていくことでした。 PDFだった求人票を、採用管理システム（ATS）導入へ 求人票がPDFだったため、応募する際は転職エージェントへの登録が必須でした。KINTOテクノロジーズに興味を持っていただいたタイミングで応募できるよう、コーポレートサイトの改修を行い、採用管理システム（ATS）を導入しました。 面接は「見極める」のスタンスから「対話」へ 候補者1名：面接官6名の面接スタイルは圧迫感があり、不評でした。 面接官トレーニングを実施し、求職者の方のキャリアをじっくり伺う対話スタイルへ面接を変えました。 候補者に寄り添い、柔軟性のある選考フローに切り替え 候補者の要望をヒアリングし、現場エンジニアとのカジュアル面談や、オフラインでの面談を実施したり、面接スケジュールも候補者に寄り添うことを目指しました。柔軟性のある選考フローへと切り替えました。 内定通知までにかかる日数を5営業日短縮 最終面接後、面接官のコメントを添えたオファーレター（紙）を名古屋に郵送し、採用条件が決裁されるまでに5営業日を要していました。フローを見直し、電子承認システムを導入。最終面接の翌日には承認が終わるようになりました。 転職エージェント向け企業説明会を開催 今後の展望やポジションをより詳しく知っていただくために、KINTOテクノロジーズの取締役副社長である景山さんと、マネージャー数名が登壇する、3時間ほどの説明会をオンラインで開催しました。約15社の転職エージェントが参加し、今もKINTOテクノロジーズの採用を支援いただいております。 そして、最後は力技！！岩本は9:00～21:00まで面接し、並行して上記のカイゼンを行っていました。2022年1月に有能な採用アシスタントの竹野さんが入社し、採用スピードはますますアップしていきました。（現在は18:30頃に退社していますのでご安心ください・笑） 人事採用グループの発足へ 岩本さんの参画後、採用実績は1年間で140人に（2022年1月1日～2022年12月31日）。 一方、組織の拡大に伴い、組織課題が表面化してきました。そこで、2022年4月に労務のエキスパートであるつんつんが入社します。私たちは新入社員を対象とした「入社後面談」や、「退職者面談」など、採用以外の人事業務に少しずつ着手できるようになっていきます。社員の声を経営層に届ける役割を果たすことができるようになってきたのです。同時に オフィスのカイゼン もつんつんが推進し始めます。 そしてついに、景山さんから「人事採用を組織化しよう」という声がかかりました。 2022年8月、社長から「階段の踊り場に立って冷静に」 2022年7月、KINTOテクノロジーズとしては初めての「全社員面談」を実施します。当然、社員にとっても初めての機会なので、会社へのリクエストや課題がたくさん寄せられ、どう解決していくか、人事採用グループは思案に暮れていました。その状況を見て、KINTOおよびKINTOテクノロジーズの代表取締役社長である小寺さんから「階段の踊り場に立って冷静に。組織規模に見合ったマネジメント機能を構築してから、人を採用しなさい。」というアドバイスがありました。2022年8月のことです。 そこからは、あえて採用スピードを落とし、マネジメント研修等を実施し、組織力の向上に取り組みました。そして、徐々にマネージャー同士が連携し始めました。 2022年10月、採用の要件を見直す KINTOテクノロジーズはKINTO以外のサービスも開発し、会社としてできることもエンジニアの役割も大きくなっていました。思い切って採用の要件を見直し、より組織にフィットするよう、自社サービスの開発経験がある人をターゲットとしました。 同時期にメガベンチャーでHRBPの経験がある村中さんが入社します。先に記載したマネジメント機能の構築や、採用スピードを落とし、採用要件を見直したことなど、人事採用グループの舵取りがその後の組織力強化につながっていくのですが、村中さん自身はKINTOテクノロジーズの成長スピードに圧倒され「入社直後の2022年10月から2023年3月までの記憶がない」と苦笑いしております。 人事採用グループは第２フェーズへ 2023年12月、KINTOテクノロジーズの社員数は320人になりました。組織の拡大に伴い、部署の階層も増え、役割も増えてきました。現場主導でどういう人に入社していただきたいかを考え、人事採用グループにリクエストが来るようになり、私たちはマネージャーや社員と、より近い距離でヒアリングを行っています。また、新たに面接に関わる方には面接官トレーニングを実施しており、採用に関わる社員も常に増加しています。 岩本一人で始まった採用活動は、今や部門を横断した活動になりました。 現在、人事採用グループは10人が所属しており、採用チーム、労務総務チーム、組織人事チームの3チーム体制になりました。社員の皆様がよりチャレンジし、成長できる会社でいられるよう、人事採用グループ一丸となって2024年も邁進していく所存です。 さて… 年末に人生を振り返ったり、ライフプランを見直したり、転職を検討される方が多いかと存じます。KINTOテクノロジーズでは、様々な職種で新しい仲間を募集していますので、興味のある募集がありましたら、ぜひお気軽にご応募ください。カジュアル面談も承っています。 KINTOテクノロジーズの募集職種は こちら 以上で、「人事採用グループをつくろう」を終わります。 アドベントカレンダーなので、最後はこの言葉で。 メリークリスマス！!

私は Tim です。KINTOテクノロジーズ（KTC）のグローバルプロダクト開発グループで UI/UX デザイナーをしています。私たちの UI/UX チームには、建築からビジネス、地質学まで様々な文化的、学術的背景をもつ計 4 人のデザイナーおよびリサーチャーが在籍しています。このような多様性を強みとして、複雑なデザイン課題に対しあらゆる方法論で対処でき、全方位的かつ実効性の高いソリューションを提示してきました。 課題 KINTO テクノロジーズにおける重要なデザイン課題のひとつは、 モバイルアプリケーション から マーケティングウェブサイト に至るすべてのKINTO テクノロジーズプロダクトにおいて、デザインプラクティスを標準化させ一貫したブランドランゲージを確立することです。この課題に対処していくため、書体、カラーパレット、キービジュアルなどの正しい使用法を含むデザインガイドラインをまとめたブランドポータルをリリースしました。 ブランドポータルの全容 このガイドラインを KINTO テクノロジーズプロダクトに適用するにあたり、ブランドポータルだけでは不十分だということが複数の理由により明らかになっています。 非デザイナーによる理解の必要性 ：デザイナーではない人にとっては、それぞれのデザインにおける判断の背景にある意図を直接理解していないと、ブランドポータルを自分のプロジェクトに適用するのは難しいことです。 コラボレーションの必要性 ：デザインアセットライブラリがないと、デザイナーは自分の作業をエンジニアと直接共有することができません。その結果、複数のエンジニアが仕事を引き継ぐことでそれぞれのプロジェクトの外観に相違が生じてしまい、それらが一人のデザイナーによる制作であったとしても本来のコーディングと矛盾してしまいます。 開発コストの増加 ：デザインの更新や変更が行われると、エンジニアはコードベースを手動で書き直す必要があるため、一貫性が失われるリスクが生じますし、時間とコストの浪費にもつながります。 こういった問題が続く中、一貫性と汎用性のあるソリューションを確立すべきと全員が考え、 全社的、部門横断的なデザインシステム を構築していくことがチームの指針となりました。 デザインシステムとは Invision 社 では、デザインシステムの定義がわかりやすくまとめられています。 A collection of reusable components, guided by clear standards, that can be assembled together to build any number of applications. 明確な基準に基づいた再利用しやすいコンポーネントを集めたもので、それらを組み合わせることでいくらでもアプリケーションを構築できるもの（筆者翻訳） デザインシステムは、相互に関連する 3 つの要素によって成り立っています。 ユーザーインターフェース （ボタン、テキストフィールド、アイコンなど）が、 ビジュアルスタイル （色、グリッド、活字など）によって形成され、 ウェブパターン （ヘッダー・フッター、コンタクトフォーム、コールトゥアクション）で表示される。 デザインシステムの定義を図示 プロダクトデザインの文脈では、ブランドポータルとデザインシステムには少し似ていますが、前者はプロダクトのブランドと見た目にフォーカスしている一方、後者はビジュアル以上にインタラクションデザインや UI コンポーネント、デザインパターンやユーザビリティガイドラインの範囲にまで及びます。 デザインシステムを綿密に整理しておくことにより、全員が同じデザイン原理に従うことが可能となり、それぞれのプロダクトやプラットフォーム間でのビジュアル上の一貫性および機能上の一貫性を維持することができます。 KINTO Design System はどのように作られたか？ 無からは何も生まれません私たちのチームでは、ゼロからデザインシステムを構築するのではなく、既存のオープンソースフレームワークを利用することにしました。最終的には、 Vuetify をフロントエンドフレームワークとして採用し、組織のデザインランゲージとして Material Design を選択しました。同時に、アクセシビリティやインクルーシビティなどの見過ごされがちですが大切なデザイン要素については Human Interface Guidelines を参照しました。 KINTO Design System の方法論とツール この判断が、デザインチームとエンジニアリングチーム双方にとって大変有益な結果をもたらすことになりました。というのも、全プロジェクトメンバーがデザインシステムの共通部分と異なる部分に対して、初めて同時に作業できるようになったからです。 Figma などのデザインツールを使用し、コンポーネントを構築するのと同時に、エンジニアが設計をレビュー、プロトタイプ作成、テストを行いコード化していきました。このような手法のおかげで、開かれたコミュニケーションを続けるきっかけができ、部門間の協業がこれまでにないレベルで浸透していきました。 KINTO Design System モバイルビュー画面の実装 私たちのエンジニアチームでは、デザインシステムのドキュメント化について Storybook で幅広く紹介しています。 結果と次のステップ KINTO Design System は、デザインとコードでシームレスに運用できるため、エンジニアおよびステークホルダーの皆様にとっては、私たちの成果を単なるデザイン提案という以上に KINTO テクノロジーズプロダクトに必要不可欠な要素とみなしていただけるようになっています。結果的に、エンジニア側では、トラブルシューティングの必要がなかったとしても、デザインとコーディング両方の仕様を満たす目的でデザインシステムを学習、採用しようという意志をみせてくれています。 たとえば、ユーザーのサインアップフローでよく使用されるステッパーのセットを最初からコーディングするには 3 時間かかります。しかし、KINTO Design System と Vuetify を使えば、 完了するまでに10分もかかりません 。 ステッパー作成時に要するコード行数　95行 vs 20行 KINTO Design System はプロダクトの共存関係にじかに影響を及ぼすことができますが、いまだ発展途上のものであることには誰もが納得していただけると思います。新しいユーザーインターフェースやウェブパターンが様々検討されている昨今、デザインアプローチに関する試行錯誤を続けながら、多様なパートナーたちと部門横断的かつ実効性ある対話をしています。私たちの長期目標は、内部向けプロダクトおよび外部向けプロダクトの双方におけるユーザビリティの向上です。KINTO Design System は、その最初の一歩となるものです。 当記事は、KINTO Design System に関する 2 部構成のシリーズの第 1 回目です。第 2 回目の記事では、実際の KINTO テクノロジーズプロダクトにおける適用事例を詳しく説明していきます。どうぞご期待ください！ 参考 デザインシステムハンドブック - DesignBetter ヒューマンインタフェースガイドライン | Apple Developer Documentation Material Design Vuetify — Vue.js 向けマテリアルデザインフレームワーク Figma:コラボレーティブ・インターフェース・デザイン・ツール Storybook:UI 開発用フロントエンドワークショップ

Introduction Hi, I'm Daichi, Front End Engineer from the Global Development Division at KINTO Technologies(KTC). Currently I'm developing the e-commerce website for KINTO Factory . KINTO Factory is a vehicle upgrading service for Toyota and Lexus car owners. It offers the opportunity to integrate the latest hardware and software technologies into their vehicles through the introduction of three primary services: Reforms, Upgrades, and Personalization. As a growing e-commerce website, SEO and page load time take a fundamental role in reaching more users and delivering a better user experience. I'd like to share how we improved SEO and page load time in KINTO Factory by optimizing the Core Web Vitals score. Let's take a closer look. What is Core Web Vitals? Core Web Vitals is Google's initiative to measure real-world user experience for loading performance, interactivity, and visual stability of the page. In May 2021, Google officially announced that Core Web Vitals would become a ranking factor for search results affecting SEO. These are the current(2023) 3 main Core Web Vitals metrics: Largest Contentful Paint (LCP) - measures how long it takes to load the largest image or block of text in the viewport(your PC/phone screen). First Input Delay (FID) - measures how long it takes for the browser to respond when a user engages with the page (button click, tap, input, etc). Theres another pending metric called Interaction to Next Paint (INP) similar but focuses on the responsiveness of the page after it has initially loaded. Google announced that INP will replace FID in March 2024. Cumulative Layout Shift (CLS) - measures the visual stability of a webpage during loading. Before optimization There are many tools out there to measure your website, but I recommend Google PageSpeed Insights , which gives you a detailed report pointing areas to improve(even gives you tips of how to improve the issues) and you can see how your page has performed in the real world(based on Chrome browser data). Before the optimization, KINTO Factory's score was as below for mobile and desktop. As you can see in the image above(Core Web Vitals thresholds) and comparing it with the results below the red color is not a good sign. Before optimization MOBILE DESKTOP After analyzing the reports, some of the main issues for the slow page load were related to the images: The assets(especially images) loaded on the first page load were too large. Around 13MB in mobile and 14MB in desktop. The image size was too large(most of them having 300+ KB). Improper image size according to the screen size. Using the same image for mobile and desktop. Largest Contentful Paint image was lazily loaded. Image elements without an explicit width and height causing layout shifts through the website. Loading mobile and desktop specific images everytime because of how the markup and css were implemented. Mobile assets size(before) Desktop assets size(before) After optimization So now that we measured the website performance and know some of the issues slowing down the page, we started working on it. What we did to optimized KINTO Factory: Check all the images, optimized them according to the screen size. Use a proper format for each image. Using webp images as well, especially for the Largest Contentful Paint images in the first view. Lazy load images that are not shown in the first view and load them when needed(when showing in the screen). But preventing lazy loading images in the first view. Set explicit height and width for images to prevent layout shifts(especially for the Largest Contentful Paint images in the first view). Establish early connections with rel=preconnect resource hint for faster font load(Google fonts). Prevent layouts with mobile and desktop markup, which was causing to load unnecessary images in every page load, since the image elements were rendering but showing only by styling(css). Like the code below. <!-- Before --> <img src="pc-image.png" class="show-on-desktop-size" /> <img src="sp-image.png" class="show-on-mobile-size" /> <!-- After --> <picture> <source media="(min-width: 600px)" srcset="sp-image.png" /> <img src="pc-image.png" alt="🙂" /> </picture> After implementing the above optimizations, we managed to: Cut the assets size over 60%. Improve page load time. Reduce the cumulative layout shift(CLS) almost to 0. After optimization(mobile/desktop) BEFORE AFTER Mobile assets size(after) Desktop assets size(after) Conclusion Core Web Vitals is a great way to measure your website overall performance. As you saw in each report, just with simple asset(images, fonts) optimizations, you can deliver a better user experience and rank higher in search results improving SEO. As the first step for KINTO Factory we optimized the top page, and I believe it was a great step. However, the scores are still not yet optimal, so I think there is more work to do, to keep improving so that we can give all users the best experience.

はじめに KINTOテクノロジーズでmy routeのAndroidを開発しているHand-Tomiと申します。 最近、私たちのプロジェクトでは、RecyclerView内のRecyclerViewアイテムが完全に表示された際のイベントトリガーが必要になりました。これを実現する方法はいくつかありますが、RecyclerViewのAdapterに少しコードを追加することで解決できる方法を見つけました。この方法とその実装について、皆さんと共有し、意見交換をするためにこの記事を執筆しました。 :::details RecyclerViewとは RecyclerViewは、Androidアプリケーションで効率的な動的データセットの表示と管理を行うための拡張可能で柔軟なUIコンポーネントです。 ::: この記事の目的 複数RecyclerViewのアイテムが完全に表示された際にイベントをトリガーする方法について説明しましょう。 例えば、左の画像(←)が表示されたときに、 Title1 の Card1 と Card2 、そして Title2 の Card1 と Card2 がトリガーされることを想定します。そして、 Title2 をスクロールして右の画像(→)のように表示を変えた際に Title2 の Card3 をトリガーする方法について解説します。 左の画像(←) 右の画像(→) 単語 親RecyclerView : 縦スクロールが可能な全体のレイアウトに配置されたRecyclerViewです。 子RecyclerView : 「親RecyclerView」のアイテムとして横スクロールが可能なRecyclerViewです。 親RecyclerView 子RecyclerView スクロールイベントの受け取り まず、アイテムの表示に変化があった場合、その表示状況を確認するために以下の二つイベントをトラッキングする必要があります。 親RecyclerViewが縦スクロールされる時 子RecyclerViewが横スクロールされる時 これらのイベントをトラッキングするためには「子RecyclerView」に、 viewTreeObserver.addOnScrollChangedListener を設定します。 recyclerView.viewTreeObserver.addOnScrollChangedListener { // TODO: 表示状況の確認 } viewTreeObserver では全体のレイアウト変更や描画開始、タッチモードの変更など、ViewTreeのグローバルな変更を監視するリスナーを登録するために使用されます。 viewTreeObserver の addOnScrollChangedListener を登録することで画面に含まれているスクロール変更イベントを取得することができるようになります。 「子RecyclerView」がレイアウトに配置された際にイベントを取得するため、「子RecyclerView」のAdapter内で onAttachedToRecyclerView() メソッドに設定し、 onDetachedFromRecyclerView() メソッドで解除するコードを記述します。 private val globalOnScrollChangedListener = ViewTreeObserver.OnScrollChangedListener { checkImpression() } override fun onAttachedToRecyclerView(recyclerView: RecyclerView) { super.onAttachedToRecyclerView(recyclerView) this.recyclerView = recyclerView recyclerView.viewTreeObserver.addOnScrollChangedListener(globalOnScrollChangedListener) } override fun onDetachedFromRecyclerView(recyclerView: RecyclerView) { super.onDetachedFromRecyclerView(recyclerView) recyclerView.viewTreeObserver.removeOnScrollChangedListener(globalOnScrollChangedListener) } private fun checkImpression() { // TODO Check } 上記のコードを実装することで、親または子のRecyclerViewがスクロールされた際、または初めて表示された際に、イベントが checkImpression() 関数に渡されます。 「子RecyclerView」の完全表示をチェック 「子RecyclerView」自体が完全に表示されていなければ、その中のアイテムも完全に表示されていないと見なされます。したがって、まず「子RecyclerView」が完全に表示されているかを確認する必要があります。この確認のために以下の関数を作成しました。 private fun RecyclerView.isRecyclerViewFullyVisible(): Boolean { if (!this.isAttachedToWindow) return false val rect = Rect() val isVisibleRecyclerView = getGlobalVisibleRect(rect) if (!isVisibleRecyclerView) return false return (rect.bottom - rect.top) >= height } View.getGlobalVisibleRect(rect: Rect): Boolean このメソッドは、Viewが画面上に一部でも表示されている場合に true を返し、全て表示されていない場合には false を返します。 rect には、画面の左上を原点とするViewの位置とサイズが格納されます。 if (!this.isAttachedToWindow) return false RecyclerView がレイアウト階層に含まれていない場合、 getGlobalVisibleRect メソッドは true を返すことがあります。そのため、レイアウト階層に含まれていない場合はチェック処理をスキップし、 false を返します。 (rect.bottom - rect.top) >= height 表示されているViewの高さを確認し、Viewの高さを比べてViewが完全に表示されているか確認します。 この関数を checkImpression() メソッドに組み込むことで、「子RecyclerView」が完全に表示されていない場合、処理をスキップします。 private fun checkImpression() { if (recyclerView?.isRecyclerViewFullyVisible() == false) { return } // TODO 「子RecyclerView」のアイテムが完全に表示しているか確認する } 「子RecyclerView」で完全表示アイテムのPositionを取得 LinearLayoutManager は、RecyclerViewのアイテムが画面に表示されているかどうかを確認できる関数を提供しています。 findFirstCompletelyVisibleItemPosition() 画面に完全に表示されている最初のPositionを返します。 findLastCompletelyVisibleItemPosition() 画面に完全に表示されている最初のPositionを返します。 findFirstVisibleItemPosition() 画面に部分的にでも表示されている最初のPositionを返します。 findLastVisibleItemPosition() 画面に部分的にでも表示されている最初のPositionを返します。 この記事では、アイテムが 完全に表示 しているかどうかを確認することです。そのため findFirstCompletelyVisibleItemPosition() と findLastCompletelyVisibleItemPosition() を使いました。 private fun checkImpression() { if (recyclerView?.isRecyclerViewFullyVisible() == false) { return } val layoutManager = layoutManager as? LinearLayoutManager ?: return null val first = layoutManager.findFirstCompletelyVisibleItemPosition() val last = layoutManager.findLastCompletelyVisibleItemPosition() // TODO 新しく表示されたアイテムがある場合、イベントをトリガーする } アイテムが新しく完全に表示された際のイベントトリガー 上のセッションで取得したPositionでそのままイベントをトリガーすると、現在完全に表示されているアイテム全てに対して何回もイベントをトリガーしてしまいます。 重複した情報を取得したいわけではないので「アイテムが新しく完全に表示された時」にイベントをトリガーする実装してみましょう。 private var oldRange = IntRange.EMPTY private fun checkImpression() { if (recyclerView?.isRecyclerViewFullyVisible() != true) { oldRange = IntRange.EMPTY return } val layoutManager = recyclerView?.layoutManager as? LinearLayoutManager ?: return val newFirst = layoutManager.findFirstCompletelyVisibleItemPosition() val newLast = layoutManager.findLastCompletelyVisibleItemPosition() val newRange = newFirst..newLast for (position in newRange.minus(oldRange)) { // 新しく完全に表示されたアイテムのPositionが届きます。 onImpression(position) } oldRange = newRange } fun onImpression(position: Int) { // ここでインプレッションイベントを送信します。 } newRange には、現在画面上で完全に表示されているアイテムの位置（Position）が格納されます。重複したイベントのトリガーを避けるために、以前にトリガーした oldRange を除外した後、新たなイベントをトリガーします。 このようにして、新しく完全に表示されたアイテムのPositionは onImpression() 関数に渡されます。そして、この関数内でイベント送信のコードを実装することで、インプレッションイベントの送信処理が完了します。 まとめ 上記のコードを利用することで、アダプター側でインプレッションイベントの監視が可能になると思います 本PJでは便利性を向上させるためにインプレッション機能を備えた ImpressionTrackableAdapter を作成し、必要なAdapterが ImpressionTrackableAdapter を継承することにしました。 この ImpressionTrackableAdapter のコードを下記のトグルに添付しておりますので、必要な方はぜひコピー＆ペーストしてご利用ください。 :::details 全体コード abstract class ImpressionTrackableAdapter<VH : RecyclerView.ViewHolder> : RecyclerView.Adapter<VH>() { private val globalOnScrollChangedListener = ViewTreeObserver.OnScrollChangedListener { checkImpression() } private var recyclerView: RecyclerView? = null private var oldRange = IntRange.EMPTY abstract fun onImpressionItem(position: Int) override fun onAttachedToRecyclerView(recyclerView: RecyclerView) { super.onAttachedToRecyclerView(recyclerView) this.recyclerView = recyclerView recyclerView.viewTreeObserver.addOnScrollChangedListener(globalOnScrollChangedListener) } override fun onDetachedFromRecyclerView(recyclerView: RecyclerView) { super.onDetachedFromRecyclerView(recyclerView) this.recyclerView = null recyclerView.viewTreeObserver.removeOnScrollChangedListener(globalOnScrollChangedListener) } private fun checkImpression() { if (recyclerView?.isRecyclerViewFullyVisible() != true) { oldRange = IntRange.EMPTY return } val layoutManager = recyclerView?.layoutManager as? LinearLayoutManager ?: return val newFirst = layoutManager.findFirstCompletelyVisibleItemPosition() val newLast = layoutManager.findLastCompletelyVisibleItemPosition() val newRange = newFirst..newLast for (position in newRange.minus(oldRange)) { onImpressionItem(position) } oldRange = newRange } private fun RecyclerView.isRecyclerViewFullyVisible(): Boolean { if (!this.isAttachedToWindow) return false val rect = Rect() val isVisibleRecyclerView = getGlobalVisibleRect(rect) if (!isVisibleRecyclerView) return false return (rect.bottom - rect.top) >= height } } ::: 終わり この記事が、複数のRecyclerViewを扱う際のインプレッションイベントのトリガーに役立つことを願っています。ご質問やフィードバックがありましたら、お気軽にお寄せください。お読みいただき、ありがとうございました！

Self Introduction I am Morino, leader of the CIO Office Security Team at KINTO Technologies. My hobby is supporting Omiya Ardija, the soccer team from my childhood hometown Omiya (now part of Saitama City), in Saitama Prefecture. Lately I’m into watching Mobile Suit Gundam: The Witch from Mercury, and eagerly look forward to catching it every Sunday at 5 p.m. The other day I went to the Information Security Workshop in Echigo Yuzawa 2022 for the first time, so in this article, I'm going to talk about some of the talks that left an impression on me. What Is the Information Security Workshop in Echigo Yuzawa? The Information Security Workshop in Echigo Yuzawa has a long history, having been held annually since 1998. The 2022 iteration was held on October 7 and 8 (Fri & Sat). On both days, the Yuzawa Community Center was the venue for the daytime session, and the Yuzawa Grand Hotel was the venue for the live broadcast and for the nighttime session itself. The Night Session — The Highlight of Echigo Yuzawa Echigo Yuzawa is famous for its delicious sake and hot springs... I meant, its night session. The battle for tickets is fierce every year and I'd given up on getting one, but then someone gave me theirs at the last minute; I was so lucky! Before COVID-19, the speakers and participants would sit in a circle for the discussions. However this time, they were placed further apart from each other, since the pandemic was still a major concern. Nevertheless, the Q&A exchanges were still very lively. They're Back! “That Security Thing” in Echigo Yuzawa I always look forward to seeing the members of That Security Thing do their podcast in the night session. Nobuhiro Tsuji, Principal Security Researcher at SB Technology Corp. Masafumi Negishi, General Manager at the Security Headquarters Security Information Office at Internet Initiative Japan (IIJ) piyokango, the security-researching parrot Given how cyberattacks can strike out of the blue, piyokango said that he wants to do something like a weather forecast that predicts them, so that people won't be at their mercy quite so much. A general-purpose one might be tricky, but with phishing attacks for example, domains and certificates for the phishing sites are obtained before they're launched. As I listened, I was thinking that if we could detect those activities, then maybe we could to do something like a phishing weather forecast. Mr. Negishi called our attention to an important problem—namely, that we shouldn't judge the urgency of responding to vulnerabilities based solely on their score in the CVSS (Common Vulnerability Scoring System), but should also take into account whether they're actually being used by cyberattacks. As its name suggests, CVSS is a system for quantifying the severity of vulnerabilities in information systems. Reference: IPA Common Vulnerability Scoring System CVSS Overview As someone who collects information on vulnerabilities and evaluates their impact on my own company's systems on a daily basis, I find it extremely handy to be able to decide how urgently they should be addressed based on their calculated scores. However, even ones with a low score can be used by cyberattacks, so caution is required. The Cybersecurity & Infrastructure Security Agency (CISA) in the United States publishes information on vulnerabilities used by cyberattacks and updates it as needed, so I think adding information like that to our criteria for prioritizing them will help us provide systems that are even safer and more secure. What about Mr. Tsuji? Well, I missed your session because I went to another one. I'm very sorry, Mr. Tsuji. Phishing Hunters Sometimes Need to Relax in Hot Springs Too This was a night session event by people who battle with phishing sites on a daily basis. - Self-proclaimed handsome phishing scam hunter Nyan☆Taku ozuma5119 KesagataMe Cyber Samurai Kazumi To prevent as many people as possible from falling victim to phishing scams, they asked us to share some slides they'd made about them on social media and so on. So I've added them to this blog article too. It's extremely hard to tell whether links on social media and in emails are phishing attempts, so don't click on them at all. Instead, go to the target site via your browser's bookmarks or a search engine. How Young People Are Using the Internet, and What Can We Do About It Maiko Shichijo, ICT Usage Environment Awareness Support Office, Cyber Grid Japan, LAC Co., Ltd. I have a child in junior high school, so I listened to this lecture with tremendous interest. Apparently, 30% of children have a smartphone of their own when they're 9, and 90% do when they're 13. These percentages are much higher than I'd imagined, so it was a real eye-opener. I've listed below the things that were news to me about how young people tend to use the Internet, but I was utterly shocked to hear that they use smartphone apps that not only share their location, but even their phone's battery levels. - They don't like wordy chat messages. They use images for long passages of text. (Notepad screenshots.) They use different accounts for different things. About half of all high school students use their real names on social media (because their friends won't be able to find them if they use aliases). They share information and video in real time. As I listened, I was struck by how much we don’t understand about how children are using the Internet, and how dangerous it can be for them. But we mustn't tell them that we don't understand, because they'll stop listening as soon as we do, mentioned the presenter. The message was that we should accept the reality that children use the Internet in ways we don’t understand. After the presentation, I got to discuss children's use of social media, and the takeaway was that they should be allowed to use them under parental supervision, while being shown how to do so safely instead of banning it completely. They could use it behind your back anyway, which will make things even worse. Vulnerability Measures and Information Sharing: What We Learned From Establishing an In-house Bug Bounty System Ikuya Hayashi and Sakura Tsukakoshi, NTT Communications Corporation The idea with a bug bounty system is to pay people rewards for uncovering software vulnerabilities. When someone outside the company submits a software vulnerability report, it's hard to decide whether to trust them or not. So NTT Communications Corporation decided to provide a bug bounty system to mobilize its employees. That's because if you get a bug report from a fellow employee, you can be sure of their credentials. The system really did help to strengthen their security, they said, including the disclosure of a serious vulnerability that allowed common users to have high-level privileges. As a result, voluntary study sessions were held, non-engineers got rewards, and it created the opportunity to discover new talent among employees. I thought it might a good idea for us to establish a bug bounty system, too. In Conclusion Taking a timeout from my daily work to meet and hear talks by people from a variety of backgrounds was a very stimulating experience. I'd like to start using the vulnerability prioritization criteria mentioned above in our company as soon as possible. I think it'd be great to have a bug bounty system, too, although it might be difficult to get one up and running straight away. Besides the hot spring workshop in Echigo Yuzawa, there are other sister ones (so to speak) all over Japan. So, how about trying those out, too? Battlefield Symposium Atami Shirahama Cyber Crime Symposium Cyber Security Symposium in Dogo Kyushu Cyber Security Symposium

​ はじめに こんにちは！　KINTO テクノロジーズ、プロジェクト推進Gの青嶋と申します。 Figmaに新たに追加されたバリアブル機能ですが、とても便利なのに日本語で書かれたチュートリアルが少ないかなという思いから、僭越ながら初心者の方にもご参考になればということで記事を書かせていただきました。 ​ Figmaのバリアブル機能を使ってショッピングカートのモックアップを作ってみよう！ ​  ショッピングカート 完成図 Figmaのバリアブルの機能を使ってインタラクティブに動作するショッピングカートの機能を作ってみようという内容で2回に分けて説明していきたいと思います。 ​ パート1はバリアブルの説明に始まり、商品数を増やしたり減らしたりできるカウントアップ機能と商品の個数に応じた小計を計算する機能を説明したいと思います。 ​ パート2はカート内の商品数を2つに増やした上で小計の計算、送料無料設定、合計金額の設定、送料無料になったときに文言を変更する設定について書いていきたいと思います。 ​ 【パート1】 バリアブルとは パーツ作成 まずはカウントアップ機能 変数の作り方、割当方 カウントアップ機能の作成 小計設定 ​ 【パート2】 商品を2つに増やしてみる​ 小計の設定 送料無料設定 合計の設定 送料無料の文言に変更 完成 ​ 【パート1】 ​ バリアブルとは ​ バリアブルとは2023年6月にFigmaに追加された新機能の一つで、オプジェクトに割当てることのできる変数の事です。バリアブルとは英語のvariableの事で、日本語では変数と呼ばれます。 変数とは”色々な情報や値を一時的に持っておく「箱」のようなもの”などと説明される事が多いです。 ​ Figmaで用意されているバリアブルの種類は4つ（数字、色、テキスト、ブーリアン値）で、この4種類の情報や値をバリアブルに代入できることになります。しかし種類をまたがることはできないようですので、「数値」の変数を途中で「テキスト」に変更することはできないようです。 ​ パーツ作成 では早速制作に入っていきたいのですが、今回作りたい機能は以下の2つの機能になります。 ​ カウントアップ機能：プラスボタンを押したら商品の個数が増え、マイナスボタンを押したら個数が減る 小計設定：個数に合わせて、合計金額が変わる まずこれらの機能を作るために必要なパーツを作成し、バリアブルの作り方と割当て方をお伝えしたいと思います。 ​ ベースパーツ作成 カウントアップ機能を作るに当たって、ジョッピングカートのベースとしてコーヒーショップをイメージしたデザインを作成し、コーヒー豆がカートに入っている状態を用意しました。 ​  ベースパーツ　商品が１つカートに入っている状態 ​ ボタンパーツ作成 続いてボタンにマウスオーバーした時にボタンの色が変わるアクションを入れ込みたいので、ボタンのコンポーネントを作成しバリアントを作成します。サンプルではデフォルト状態は薄いグレーでマウスオーバー状態は濃いグレーに設定しました。 ​  ボタンのバリアントを作成 ​ バリアブルの作り方、割当方 必要なパーツが揃いましたのでここからはバリアブルの作り方と割当て方を説明していきます。 ​ バリアブルとは主に（クリックなどのアクションによって）変化させたいオブジェクトに対して割当てるもの になります。例えばプラスボタンやマイナスボタンを押した時に商品の個数を変化させたいので、個数の数字に対してバリアブルを割当てることになります。 ​  赤枠の個数部分に対してバリアブルを割当てます ​ バリアブルを作成するには右カラムから「ローカルバリアブル」をクリックしウィンドウを開き、ウィンドウ左下にある「バリアブルを作成」ボタンをクリックします。 ​   今回は個数なので種類は「数値」を選択し名前は「個数」にちなんで”Kosu1”としました。そしてすでにカートに商品が1つ入っている状態を想定しているのでMode1欄に入れる数字は1にします。これでバリアブルが1つ作成されました。 ​ 次にこのバリアブルをオブジェクトに割当てていきます。 デザイン上の数字の1を選択し、右カラム内のテキスト情報欄にある八角形のアイコン（三点リーダーの上）をクリックします。 すると作成したバリアブルの一覧リストが出てきますので、そこからKosu1を選択します。 これでバリアブルの割当てが完了しました。 ​  割当て可能なバリアブルの一覧がリストで出現 ​ プラスボタンとマイナスボタンに挟まれた「1」にはバリアブル「Kosu1」が割当てられ、値として1が代入されています。この値を2に変えるとオブジェクトの方の数字も2に変わります。 ​ カウントアップ機能の作成 パーツも揃いバリアブルの設定もできたので、次にプラスボタンを押したら商品の個数が増えるという機能を作っていきたいと思います。 そのためにはプラスボタンにアクションを割当てる必要がありますので、プラスボタンを選択し右カラムの最上部にある「プロトタイプ」のテキストをクリックしてモード変更をした後、「インタラクション」の右にある＋マークをクリックすることでマウスアクションを割当てることが可能になります。  バリアブルを選択して式を記入します。 アクションの種類としてはプラスボタンをクリックした時に個数を増やしたいので、デフォルト設定の「クリック」のままで大丈夫です。そして「バリアブルを設定」を選択し、以下の手順で設定します。 クリックした時に変化させたいバリアブルを選択 クリックした時にどうなるかの式を記入 記入を終えると図のようになります。  バリアブルを選択して式を記入します。 ​ この式は、 （プラスボタンをクリックした時に）Kosu1を（=上の段）Kosu1+1する（=下の段） ということを表しており、Kosu1が1の時にプラスボタンをクリックしたら、1+1で2になります。これをプレビューすると、プラスボタンをクリックするたびに個数が1つずつ増えていくことが確認できると思います。 これと同じ様にマイナスボタンにもアクションを割当てていくのですが、マイナスボタンの時は1つ注意することがあります。それはプラスボタンと違い、なんの制限（条件）も付けないと個数がマイナスになってしまうことです。 ​ この様な場合は以下の図の様な「条件付きアクション（if文）」を設定する必要があります。  この式は、 Kosu1が0でない場合、Kosu1をKosu1から-1した状態にする ということを表しています。例えばKosu1が1の時にマイナスボタンをクリックしたら、1-1で0になります。ですがKosu1が0の時にマイナスボタンをクリックしても何もアクションは起きないので0のままになります。 ​ これをプレビューするとプラスボタンクリックで数が増えていき、マイナスボタンクリックで数が減り且つ0以下にはならないことが確認できると思います。 ​  カウントアップ機能の動き ​ 以上でカウントアップ機能は完成です。 ​ 小計設定 最後に小計を設定していきたいと思います。パート1では商品が1つしか無いのでその合計金額を小計として扱います。 ​ バリアブル作成と割当て 小計も個数に応じて変化するオブジェクトですので、バリアブルを設定する必要があります。先程と同じ手順でバリアブルを作成し名前はShoukeiとしました。そしてショッピングカートには元々商品が1つ入っている状態を想定していますので、小計は¥100となり代入する値は100となります。 数字へのバリアブル割当ても先程と同じ手順で行います。 ​  赤枠の金額部分に対してバリアブルを割当てます ボタンへのアクション入力 小計金額を導くには個数の場合と同じくプラスボタンやマイナスボタンを押した分だけ商品の値段を増減させるという方法でも実現可能ですが、multiplication（掛け算）の演算子を使用して個数×値段でも可能です。さらにプラスボタンとマイナスボタン両方に同じ式を使用する事ができるので少しだけ楽ができます。 ​ 記入を終えると図のようになります。  この式は、 ShoukeiをKosu1 x 100の状態にする ということを表していますので、Kosu1が1の場合は小計=1x100となり、¥100となります。 これをプレビューするとプラス（マイナス）ボタンクリックで商品数が増減し、それに伴って小計の値段も変化することが確認できると思います。 ​  小計の動き ​ 以上で小計設定は完成です。 パート1でお伝えした内容だけでも例えば「いいねボタン」や簡単なカート機能のモックを作ることは可能ですので色々と応用が効くと思います。 ​ パート1はここまでとなります。次回パート2は応用編としてカート内の商品を2つに増やし一定の金額を超えたら送料無料にするといった内容をお伝えしたいと思います。 ​ この内容が参考になれば幸いです。

こんにちは、KINTO テクノロジーズ (以下 KTC) で DBRE をやっていますあわっち( @_awache ) です。 KTC では、モビリティサービスを提供する基盤として Amazon Web Services (以降 AWS と略します) 上で Amazon Aurora 等の Database を多く運用しており、Database Reliability Engineering (以降 DBRE と略します) を組織として設立し、事業のアジリティとガバナンスを両立するための取り組みを実施しています。 本投稿では KTC はなぜ DBRE を必要としたのか、について記載させていただきたいと思います。 Database Reliability Engineering (DBRE) とは DBRE とは Database Reliability Engineering の略で「Software Engineering と Database 管理の Best Practice を組み合わせたアプローチ」を行っていく役割です。主なものとして SLO/SLI を定義、測定し、それに合わせた開発組織へのアプローチ 自動化、自律化推進による生産性の向上 Backup/Restore などサービス稼働率の向上 Database Security の担保とガバナンスコントロールの実現 他分野のスペシャリストとの分野を超えたコラボレーション などが挙げられます。 これらの役割を一言で言うと「Database に対する専門知識と判断を用いて サービスの信頼性を担保する 」こと、と言えると思います。 DBRE は企業にとって必要なのか？ 「DBRE」というキーワードは、ある人にとってはとても魅力的に映るかもしれません。しかし、なぜそれが必要なのかを考えなければ、持続的な DBRE 活動を実現することは困難になります。 なぜなら AWS をはじめとした Public Cloud の爆発的な進展、DevOps/SRE 思想の成熟、AI 技術の進歩など Cloud を活用することによって誰でも一定のレベルで課題を解決できる土壌が揃っており、Database Engineer の専門知識の必要性が小さくなってきているからです。 一方で、過去も現在も実は Database そのものに対する基本的なアプローチはこれまでと変わっていないことも事実です。 環境分離 構成管理 パフォーマンス測定 Backup/Restore Security の担保、など 変化しているのは Database を取り巻く周りの環境である と考えることができます。 こういった時代の変化を判断し、その上で DBRE の必要性がある場合には皆様の会社でも DBRE を検討するといいでしょう。 なぜ KTC に DBRE が必要だったのか ではなぜ KTC が DBRE を実践しているのか、を以下で説明します。 Software Engineer と Database Administrator の関係性の変化 Software Engineer と Database Administrator の役割が明確に分かれていた時代 まだ企業においてオンプレミスの構成がメインであった時代、一般的には Software Engineer と Database Administrator はそれぞれの役割が明確に分かれており、それぞれの専門領域の分野で活動を行なっていました。 例えば下記のような分類がされていることがあったと思います。 Software Engineer 領域 サービスの稼働率を守り、その成長を促進するための活動 ユーザーからのリクエストで必要なデータを抽出する クエリの変更など Database の DDL に対する変更を必要としないチューニング Database Administrator からの要望に対するアプリケーションへの適用 Database Administrator 領域 Database そのものの稼働率を守るための活動 両者の大きな違いはそのリクエストやユーザー要望に対する対応速度と専門性であると言えます。 Software Engineer はサービス提供側に近いところにあるためどちらかというとニーズに合わせて可能な限り素早く応える必要があります。 Database Administrator はサービスというよりも Database そのものに重点を置いているため、多少レスポンス速度は遅くとも専門知識を用いて様々な課題を解決していきます。 図に表すと下記のような形になります。  このような組織では DBA は組織横断的に課題発見と課題解決を行っていました。 Public Cloud の台頭による DBA の役割の縮小と SWE の領域の拡大 AWS をはじめとする Public Cloud が台頭してきて両者の役割は大きく変化してきました。特に Database そのものの稼働率を守るという点に関しては Public Cloud が担ってくれることから Database Administrator の役割は大きく縮小してきたと言えます。 代わりにこれまで Database Administrator が担ってきた役割のうち Database Administrator と Software Engineer の役割が被っている部分、具体的には 環境分離 構成管理 パフォーマンス測定 Backup/Restore Security や Governance Control などを現場の Software Engineer が自分達で担う必要が出てきました。 その結果どうしても Database にまで注意が行き届かないというケースも存在してしまいます。  KTC ではこの点に課題を持ち始めました。継続的に事業成長を加速させるためには Software Engineer が事業成長に注力できる状態でなくてはいけません。 Cloud 利活用を主軸とした現在において、Software Engineer が事業活動に注力できる状態にするためには DBRE が Public Cloud との間に Hub となって活動する必要があります。 DBRE に求められる主な役割としては Database を軸としてサービスの稼働率を守る 現場のエンジニアの生産性を高める データベースセキュリティへの対応 内的要因、外的要因から Database を守る を通じて企業の継続的成長を促進することが挙げられます。  次の章ではそれぞれの役割について補足します。 Cloud 時代の DBRE の役割 Database を軸としてサービスの稼働率を守る 一般的にサービスが正常な状態は Database が正常に機能していることが前提となります。つまり Database のダウンタイムはそのままサービスのダウンタイムにつながってしまうのです。サービスの稼働率を維持するためには正しく適切に迅速に Database を復旧しなければなりません。 そこで DBRE に必要とされるのは Cloud 上で稼働するデータベースに対するスキルと言えるでしょう。 現場のエンジニアの生産性を高める Database を運用していく中で、標準化を推進することは企業に対して大きな貢献ができるポイントです。例えば企業のガイドラインを提供した Platform の適用、ER 図をはじめとした Database ドキュメントの自動生成、定常的なオペレーションの自動化などが挙げられます。 また、日々進化する Cloud 技術の新機能検証と企業への適用、スロークエリなどのアプリケーションのボトルネック対応のサポート、そしてトラブル対応などを DBRE としてサポートすることも重要な役割となります。 これらは DBRE だけができてもスケールしません。DBRE は Software Engineer に比べて非常に限られたリソースの中で活動を行う必要があります。 大切なポイントは DBRE によってアウトプットされた物事は Software Engineer に還元され、そして誰でも扱える状態になることです。 データベースセキュリティへの対応 Database の重要性は事業の成長と共に高まっていきます。そしてその価値が高まった Database は常に狙われる一つのコンポーネントとなります。 万が一データ流出が発生した場合、財務的な損失だけでなくそれに伴う甚大なレピュテーションリスクを抱えることになってしまいます。 企業を継続的に成長させるためにはこういったリスクから Database を守ることが必要不可欠です。そのためにも DBRE は Database に対するセキュリティを企業単位で適用することが重要となるのです。  内的要因、外的要因から Database を守る データはその重要性から外部要因の変化による影響も受けやすい一つの要素です。そのため Database 運用に求められることは年々厳しくなっています。 特に政治・法律・世論の変化など、企業や個人ではコントロールできない要因に適切に対応することは企業に求められるものとなります。例えば個人情報保護法など定期的に改定されており、その度に罰則が厳しくなる傾向にあります。 外部要因による影響を各サービスが独自に適用しているのではコスト的なリスクだけでなく、適用漏れなどによるリスクも発生してしまいます。 DBRE に求められることは外的要因によるリスクを適切に把握し、企業内全ての Database に対して最適なガバナンスコントロールを行うこととなります。 KTC DBRE の目指すべき姿 KTC における DBRE は横断組織です。自分達のアウトプットがビジネスに反映されることによって価値提供されます。横断組織はそこにあるだけでは何に使われるかわからない税金と同じです。ビジネスに対してどのように良い影響を与えることができるか、が重要です。 今の時代、ルールやレビューだけで対応できるほど事業の変化のスピードは遅くありません。DBRE の持っている Database の知識を現場のエンジニアに還元して KTC 全体の Reliability を守ることが重要になります。 そのためにも私たちは Database に対するモノゴトを可能な限り Engineering によって解決しようと試みています。 ルールでがんじがらめにするのではなく、現場のエンジニアと協働して解決する、高いアジリティを保持しつつサービスのガバナンスコントロールを実現することでビジネスへの良い影響を提供していきます。 まとめ KTC DBRE の役割 現場のエンジニアが事業成長に注力できる環境を提供すること KTC DBRE に求められる主な役割としては Database を軸としてサービスの稼働率を守る 現場のエンジニアの生産性を高める データベースセキュリティへの対応 内的要因、外的要因から Database を守る を通じて KTC の継続的成長を促進することが挙げられます。 この役割を軸として、ルールに縛られるのではなく、現場のエンジニアと協力して問題を解決し、高いアジリティを保ちつつサービスのガバナンスコントロールを実現することで、ビジネスへの良い影響を提供していくことが求められています。 僕たちと DBRE ディスカッションしませんか？ 僕たちの DBRE はまだまだ始まったばかりです。なぜ DBRE があり、何を実現するためにどんなことをしていくのか、試行錯誤をしています。 お互いのやっていること、やりたいことなどをざっくばらんにお話しできると僕たちも視野が広がります。 僕たちからも多くをインプットしていただけるように取り組んでいることをお話しさせていただきたいと思います。 興味がある方は Twitter DM でも構いませんのでご連絡ください。 We are Hiring DBRE の採用に関する課題は非常に大きいなと思っています。僕たちの活動に興味がある方はぜひ 採用ページ からご登録ください。 カジュアルに話を聞きたい、という方も Welcome です。 そのうち DBRE を実践している企業様とコラボレーションして DBRE Meetup 的なイベントもできたら嬉しいと思っていますのでその際はどうぞよろしくお願いします！

はじめに こんにちは、KINTO FACTORY のバックエンドエンジニアをしている西田です。 KINTO FACTORY をローンチして早いもので半年が経ったので、サービス運用を開始してからリリースやシステム監視を中心に遭遇した課題や、私たちが学んだことをみなさんと共有したいと思います。 KINTO FACTORY について はじめに KINTO FACTORY のサービス概要を少しだけ。 お乗りのクルマに適合するハードウェア・ソフトウェアといった機能やアイテムをアップデートできるサービスとなります。 これまでのクルマのアップデートはディーラーでの作業が必要であったり、いわゆるメーカーオプションのような注文時にしか選択できないアイテムを KINTO FACTORY ではウェブ上から申込みができます。 また、KINTO 契約車両だけでなくトヨタ/レクサス/GRのクルマが対象となっており、適合するクルマであればアップデートを行うことができます。 今年の夏にローンチし、半年が経過しようとしています。 @ card 運用について リリースは2週間に1回のペースで行い、GitHub Actions をメインに CI/CD を構築してデプロイしています。 サービスの監視は、運用チームといった専用の組織を設けずに開発メンバーが中心となり、当番を回して運用をしています。 ローテーションは PagerDuty のスケジュール機能を利用しています。 また、インシデントの検知は次のようなイメージで構成されています。 アプリケーションログやサービス監視の情報を OpenSearch に連携し、ユーザー影響を判断して PagerDuty に通知が行われます。(画像は対応完了後のものです) その後 Slack にも通知がされることで監視当番が対応を行います。 基本的には担当者が対応しますが、必要に応じて有識者を巻き込んで対応をするようにしています。 また、対応者だけでなくチームとして把握ができるように翌日のデイリースクラムで対応内容を共有しています。 課題と対応 運用を始めてから遭遇した課題と、それをどのように対応したかを共有します。 リリース準備の負担が大きい テンプレート化されていないこともありリリースのたびにデプロイのための準備を1から行っていて、粒度も統一されておらず時間がかかっていました。 中でもリリース手順書周りは Confluence ベースで管理していて、手順の確認や修正が煩雑でした。 ⇒ リリース手順書をコード管理へ移行することで、バージョン管理やテンプレート化、差分確認をできるようにすることで、リリース準備の負担を軽減することができました。 インシデント検知が多発 ローンチ後、数日間のインシデントの件数が↓の通りで アプリケーション側のエラーハンドリング設計が甘かったため、ユーザー影響がないものであってもクリティカル扱いとして検知され、運用開始後は毎日のようにインシデントが発生し監視の負荷が大変なことに... ⇒ 対応するには数が多く一括で対応が難しかったため、緊急度が高くないものは出力を見直すように修正、修正がすぐできない場合は通知されないように除外設定を組み込んで最適化を図りました。 インシデント対応の初動に時間がかかる 対応フローの手順などが整っていなかったためメンバーによって認識の差があり、対処に時間がかかってしまう場面がありました。 PagerDuty の操作に慣れていないこともあり確認済みステータスへの更新が漏れてたりも。。。 ⇒ Slack でワークフローを定義して、コマンド入力でインシデント対応を開始して手順に沿って対応が進められるように環境を整えて改善を図りました。 また、インシデントVSチームという構図になるようにまずは全員が集まって対応をモブ作業として行い、認識を擦り合わせながら対応をすることで、アラートが発火してから対応開始するまでの時間を1/10以下に短縮することができました。 まとめ ローンチ直後は色んな課題が起きてバタバタな日々を過ごしていましたが、継続的に改善を行うことで少しずつ改善されてきました。 あらためてふりかえるとメンバーの経験値や知識による対応の差があったため、事前にどういった運用をしていくのかをきちんと整理しながら運用を開始することで、立ち上がりもスムーズにできたのかなと実感しました。 まだまだ改善の余地はありますが、これからもユーザーにとってより良いサービスを提供できるように運用を継続していきます！ さいごに 今回はサービス運用で遭遇した課題とその対応を共有しました。 私たちの経験が何かの参考になれば嬉しいです。 また、KINTO FACTORY では新たな仲間を募集していますので、ご興味があればぜひ下記の求人をチェックしてみてください！ @ card @ card