はじめに はじめまして、データ分析部-分析G-分析プロデュースT（兼データサイエンスT）の森本和樹と申します。 普段は大阪オフィス勤務で、リテンションProj・与信Proj・中古車部・MyRouteアプリに関連する分析テーマを取り扱っております。 （詳しい業務内容はおって別テックブログに記載予定していきたいな〜と考えております。） さて、今回の記事では"QuickSight Generative BI"のプレビュー版を使ってみた内容を紹介していきたいと思います。 先月TOYOTAグループ向けAWS生成AIワークショップに参加させていただいた時に紹介があり、「これ結構使えんじゃね？」と思い試してみた結果です。 本記事で書く内容 QuickSight Generative BIの概要 Generative BIで ラーメンサブスク の売上ダッシュボード作ってみた 良かった点/今後に期待 本記事で書かない内容 QuickSightの使用方法 QuickSight Qの説明 Generative BI の利用開始方法（ こちら がよくまとまっておりました） Amazon QuickSight の Generative BI 機能を発表 Generative BIとは 簡単に言うと、"QuickSight Q"に"Amazon Bedrock"のLLMを適用することでより幅広い機能が追加されたサービスです。 元々"QuickSight Q"という自然言語で質問を投げかけると、その回答をグラフで返してくれる機能がありました。 そこに"Amazon Bedrock"のLLM(大規模言語モデル)を適用することで、より自由度の高い分析を自然言語ベースで行えるようになりました。 Quicksight Q ※QuickSight Qは東京リージョン他多数のリージョンで利用可能。 参考 Generative BIでダッシュボード作ってみた それでは早速Generative BIを試していこうと思います。 今回は「 もしKINTOがラーメンのサブスクを始めたら 」という仮想テーマでダッシュボードを作っていこうと思います。 ※KINTOはモビリティサービスを手掛ける会社ですので、ラーメン事業には手を出さない。。と思います。。 目指す姿 今回はCRISPさんが公開している ダッシュボード の"セールス"セグメントを参考にし、下記2つのダッシュボードを作ることを目標におきます。 売上（年月ごと） 契約プラン構成比 前準備 前準備としてラーメンサブスクのサービス概要とサンプルデータを作成します。 サービス概要 ChatGPTにラーメンサブスクの契約プランを考えてもらいました。 思ったより練られたプランが出てきました。笑 即採用です。 サンプルデータの作成 次に以下のプロンプトでサンプルデータをChatGPTに作成してもらいました。 結果 まじでそれっぽいサンプルデータをCSVで作ってくれました。 実践 では早速先ほどのサンプルデータをQuickSightに読み込ませてグラフを作成していきたいと思います。 今回は社内のsandbox環境でバージニア北部リージョンを用いてお試ししています。 ※ 前述の通り、Generative BI利用開始方法は省略します。 1. 売上（年月ごと）グラフの作成 まずは売上（年月ごと）のグラフを作成していきたいと思います。 Generative BIは英語対応のみ（2023/12/11時点）ですので、英語のプロンプトを作成します。 2023年12月11日時点の月次売上見込みを表示 下記のプロンプトを"Build a visual"に入力。 Cumulative Sum(Yen) in 2023-12 Buildを押すと、約3秒ほどで下記のようなボードが作成されました。 想定通りの出力であることを確認後、"ADD TO ANALYSIS"をクリックし、ビジュアルとして追加しました。 年月ごとの月次売上推移グラフを作成 同様に下記のプロンプトを入力。 Cumulative Sum(Yen) per months こちらもほぼ想定通りのグラフが出力されました。 ビジュアル追加後、グラフの大きさを手動で変更した結果がこちら。 横軸が"MM月DD, YYYY HH/hh"形式となっていて見にくいので、ビジュアル変更を行います。 Generative BIはビジュアルの変更も自然言語で行えるようです。 お気づきかと思いますが、私は英語力が高いわけではないので社内AI-chatBOT(しぇるぱ)にサポートいただきます。 打ち込んでみる。 どうやらまだビジュアル編集機能は不十分な模様。 公式 を確認してもまだできることは少なそうですので手修正します。 今後に期待ですね。 都道府県ごとの月次売上ランキングテーブルの作成 次はテーブル形式のビジュアルの出力に挑戦します。 またまたしぇるぱにサポートいただいて、下記プロンプトを入力。 Please provide the monthly fee sum yen for each prefecture in a ranking format in a table in December 2023 （in３つ続いとるやないかい！） 結果 もー感動ですね。まさに欲しかったテーブルを表示してくれました。 ビジュアルに追加（グラフの大きさ等は手修正しております。） 2. 契約プラン構成比 次に契約プラン構成比を円グラフで表示したいと思います。 例に漏れずしぇるぱに翻訳してもらい下記プロンプトを入力。 total unique number of Contract ID per contract plan in pie 完璧ですね。 ついでにプランごとの月額料金の合計も表示してもらいます。 Total monthly fee for each contract plan in table ダッシュボード表示 作成したグラフをダッシュボード化して確認してみます。 折れ線グラフの時系列フォーマット以外は全てGenerative BIに作成していただきました。 結構いい感じではないでしょうか！？ Exective summary ダッシュボードの内容をもとにサマリーを作成してくれる機能もあるようです。 ダッシュボード画面の右上にある"Build"ボタンから"Executive summary"をクリック。 約10秒ほどでサマリーを作成してくれました。 構成としては、ダッシュボード全体の説明、各グラフの説明となっているようです。非常に簡易的ではありますが、内容も正しそうです。 また、グラフごとの説明にリンクが埋め込まれておりました。大規模なダッシュボードとかだとサマリをクリックすると、リンクされたグラフまで飛ばしてくれるので便利ですね。 良かった点/今後に期待 良かった点 自然言語ベースの命令をすることで即座にグラフを作成してくれる。 簡易的なグラフであれば手作業で作るより早い。 カラム名を明確に指示しなくてもある程度は察してくれる。 　→逆に言うと、察してもらうために適切なカラム名をつけておく必要がある。 月次の集計等も自動でおこなってくれる。 Exective Summary は資料の叩き台として使用できる。 今後に期待 グラフの微修正機能がまだ不十分。 ただ、ここは自然言語というより手で行なった方が早そう。 英語対応のみ。（2023/12/11時点） 入力する欄が短く、文章の修正がしにくい。 長い文章を入力した後、思ったグラフが表示されず文章を修正したい場合、少しやりにくかった。。 直近3ヶ月（last 3 months）などの時系列表現を汲み取ってくれない。 さいごに 今回はGenerative BIのパブリックプレビュー版を試してみました。 実業務で使えるかと言われるとまだそのレベルではないですが、今後のアップデート次第ではかなり期待感を持てるサービスだと思いました。 現状の見える化を手軽・高速に行うことができれば、ビジネス改善のサイクルもより早めて行くことができますので、今後が楽しみです。 (本筋とはそれますが、ChatGPTが作ったサンプルデータとイラストの完成度が高くてびっくりしました。) また、分析Gの説明は下記テックブログに記載しておりますので、もしご興味あれば一読ください。 KINTOテクノロジーズ　分析グループを紹介します

はじめに  こんにちは！QAチームのmmmです。  普段は主にKINTOのWEBシステム関連のQA業務に携わっています。 扱うシステムにはお客様が目にされるフロント領域、販売店様が使用されるバックオフィス領域に加え、社内業務用のシステムが複数あり、これらのシステム間では各種データが連携されています。  最近では「 KINTO Unlimited 」、「 KINTOかんたん申し込み 」などのアプリが増えましたが、新しい機能や要件が追加されると既存システムとの関わりや影響を整理しなければなりません。 そのため、システム単位での仕様はもちろんのことですが、その他にもKINTOのサービスにおける一連の業務を理解し、データの流れを掴む必要があります。  システムや新しい機能要件が増えるたびに整理することが増え、QA観点にも影響するので個人的にはQA業務の中で大事かつ大変な作業と感じています。  そこで今回はテスト設計に焦点を当て、 過去担当した案件で直面した課題から現在開発チームとやりとりする際に意識していることについてお話ししていこうと思います。 よくある課題 同じ機能の仕様が複数の資料に存在する  プロジェクトには様々な開発チームが参加していることもあり、同じ機能に対してそれぞれのチームに資料が存在することがあります。そのため下記のようなことが発生しやすいです。 資料間で内容に差異があり、正しい仕様がわからない 資料間で文言揺れがあり、コミュニケーションにすれ違いが起きる 開発側でも本来考慮すべき仕様が埋もれてしまいバグに繋がってしまう 検討中ステータスの仕様が存在する  資料を読み進めていると「確認中」や「？」など、まだ仕様が確定されていない表現で記載されていることがあります。これらはテスト設計、実施に下記のような影響があります。 テスト設計：仮のテスト観点で進めるため、テストケース数が仮決めになる（増減する可能性がある） テスト実施：未確定範囲のテストは進められない、また、仕様変更が生じた際にはケースの修正作業が発生する 各システムの状態を俯瞰できる資料がない  利用者に見えている実際のフロントエンド領域の状態表示に対して、裏側のバックオフィス領域では細かくステータスを保持していることがあるのですが、そこをぱっと見て分かるような資料が必ずしも存在するとは限りません。  たとえば、ECサイトで商品を購入する際、大体は下記のようにお客様側のステータスよりお店側の方が（実際はおそらくもっと）細かく分かれていたりします。  その両方を俯瞰的に見られる資料がない場合、システム間のデータ連携の観点が必要なため、テスト設計に際しQA側で整理する必要があります。 計算系の仕様がコードで記載されている  金額や日数計算が必要なテストがある場合、開発仕様を確認しますがコードでそのまま記載されていることがあります。この場合下記のような影響があります。 読み解くことに時間を要する テスト実施までに第三者が見て分かるように仕様をまとめておかないとQA作業が属人化してしまう 開発チームとのコミュニケーションで意識していること プロジェクトの概要を把握する  前述で挙げた課題はプロジェクトの性質上避けられないこともあるため、 まずはプロジェクトの発足の背景などを聞き、QA側でもその目的や経緯などを理解することで仕様理解の促進にも繋がり、仕様に対して過不足がないかどうかなどの疑問を持てるようになると考えています。 一通りのシナリオオペレーションの説明をお願いする  各システムの仕様書があるので資料に書いてあることは読めばわかる…という話ではありますが、 システムを理解している開発側から直接説明を受けることで下記のようなメリットがあります。 （一通り仕様を認識し、俯瞰できる資料はQA側の理解用に自作することが多いです。） 想定アクター／ユーザーの操作がわかりやすい データの流れのイメージがしやすい タイムリーに質問ができ、理解促進になる 資料の棲み分けを確認する  この機能要件や画面デザインに対して正しい仕様が記載されている資料はどれなのか、ほかにも資料が存在するが古いメモ程度のものなのか、こちらでは判断できないので単純に確認していきます。  各開発チームが担当している領域の内容が最新で正になることが多く、都度質問することが多いので開発側の負担も考えクローズドクエスチョンを意識して質問しています。 ＜例＞ 「●●の仕様については、資料Aが正しい認識でよろしいでしょうか？ 資料Bにも同様の内容が記載されていましたが少し内容が異なるため確認させてください。」 制約事項を確認する  QA作業する上で現状わかっている制約事項がある場合、事前に共有をお願いすることでQA側の対応も検討しやすくなります。 計算系などの複雑な仕様は別途説明会をお願いする  様々な価格やプランが存在するため、その分計算式も複数存在します。 似たような計算式でも持ってくる値が微妙に違うこともあり、間違いを事前に防ぐため開発担当者の説明を求める上で下記を明確にすることを意識しています。 そもそもの金額の意味 計算式に使う値の意味や参照する場所 日数の数え方 テストする上で気をつけることがあるか 計算用ツールの存在  計算系はテスト実施の効率を考え計算用ツールをQA側で自作することが多いため、開発担当者と都度認識合わせを行いながら仕様をまとめ最終的にツールに反映しています。  また、今回計算系をあげましたが、理解が難しいと感じた仕様は素直に開発担当者に直接聞きに行くことが多いです。 おわりに  今回執筆依頼があった際に内容に悩んでいると、本ブログ担当も兼務している開発チームの方から「QA依頼時にQAチームがどんな情報を欲しがっているのか分かると助かる」といった旨の言葉をいただきました。  この内容にはあまり沿ってはいないですが、まずはQA業務のとっかかりであるテスト設計での課題に対する情報を発信することで、テスト以外のQA業務への認知に少しでも役に立つと良いなと思い執筆いたしました。  また、今回述べた課題に対する対応は現在すでに開発チームから配慮いただいているところもあり、QA立ち上げ当初と比較すると随分整理された作業環境になっていると実感しています。  ただ資料だけでは見えない情報を整理するのもQA業務の一つと考えているので、仕様を読むだけでなく他仕様への影響などを模索し整理する作業は引き続き頑張っていきたいと思っています。

Hello (good evening), this is part 2 of the irregular Svelte series. Click here for the previous articles What I learned from using SvelteKit and Svelte for a year *SvelteKit major release supported Comparison of Svelte and other JS frameworks - Irregular Svelte series-01 Svelte unit test - Irregular Svelte series-02 Today, I will write about Svelte unit tests. You can get the module here. We will use three Vitest + jsdom + @testing-library/svelte . Vitest This is a testing framework that uses a tool called vite. It works very fast because it uses vite. https://vitest.dev/ jsdom This is a library that uses the DOM in Node.js. You can parse HTML and call web APIs. https://github.com/jsdom/jsdom @testing-library This is a test library that supports various frameworks. It supports Svelte, React, and Vue. https://testing-library.com/docs/svelte-testing-library/intro/ Environment settings First, add the modules below. *You can use whatever package manager you want. Here, I will use yarn. yarn add vitest jsdom @testing-library/svelte @types/jest *Since we will use TS (TypeScript), add @types/jest , because we also want to add types to the test file. Of course, it is not necessary if it is written in TS. config Next, add a description for the test to vite.config.js. import { sveltekit } from '@sveltejs/kit/vite'; /** @type {import('vite').UserConfig} */ const config = { plugins: [sveltekit()], // Add the following from here test: { // Target file for test include: ['src/**/*.{test,spec}.{js,ts}'], globals: true, // test environment environment: 'jsdom' } }; export default config; jsdom is configured in environment . package.json Add the following to package.json. You can run it with yarn vitest without writing. "test": "vitest" You are now ready to test. Let's test it out I'm going to write a test with a component that has a common add and subtract button. Component side First, prepare the components you want to test. <script lang="ts"> let count:number = 0; </script> <! -- Subtract button --> <button on:click={() => (count -= 1)} aria-label="Subtract">-</button> <! -- defined count variable --> {count} <! -- Add button --> <button on:click={() => (count += 1)} aria-label="Add">+</button> Since it is necessary to read addition and subtraction respectively in testing-library, for this article,we set aria-label. The components are created. The following simple components are drawn on the screen. Press the plus button to add, and the minus button to subtract. Complete figure Test Now we are going to move to the unit test file. Depending on the number of components and personal preferences, I prefer to place them in the same hierarchy without having to move my gaze or the cursor back and forth. import { render, fireEvent, screen } from '@testing-library/svelte'; // $lib is an src/lib alias import Counter from '$lib/components/Counter.svelte'; describe('Counter.svelte', async () => { 　// Initial value test('Initial counter value is 0', async () => { render(Counter); expect(screen.getByText('0')).toBeTruthy(); }); test('Subtraction process', async () => { render(Counter); // define the button const decreaseButton = screen.getByLabelText('Subtract'); // define the event await fireEvent.click(decreaseButton); const counter = await screen.findByText('-1'); expect(counter).toBeTruthy(); }); test('Addition process', async () => { render(Counter); const increaseButton = screen.getByLabelText('Add'); await fireEvent.click(increaseButton); const counter = await screen.findByText('1'); expect(counter).toBeTruthy(); }); }); Now, the test is ready. Let's break it down by test unit. test('Initial counter value is 0', async () => { render(Counter); expect(screen.getByText('0')).toBeTruthy(); }); Considering the test item Initial counter value is 0 , we first render the Counter component which is called by import Counter from '$lib/components/Counter.svelte'; . Then, we run a matcher called toBeTruthy to judge whether or not the Counter component has an initial value of 0. Basically, a matcher is a function used to evaluate tests. See the Jest official website for more details. Jest Next, about testing the subtraction process. Both the addition process and subtraction process have the same logic, so I will only explain the subtraction process. test('Subtraction process', async () => { render(Counter); // define the button const decreaseButton = screen.getByLabelText('Subtract'); // define the event with fireEvent await fireEvent.click(decreaseButton); // const counter = await screen.findByText('-1'); expect(counter).toBeTruthy(); }); The Subtraction process test is done as follows. Draw the component Define the button in the component Set click event Verify that the value decreased by 1 testing-library and async/await make testing easy, are easy to understand, and are highly compatible with Svelte. The addition process test is the same except for the value of findByText , so I will skip it. Let's run it Do the yarn test When it passes like this, a green message saying that it passed is output to the console. Let's see what happens if it fails the test. <script lang="ts"> // 0 => 1 let count:number = 1; </script> <! -- Subtract button --> <button on:click={() => (count -= 1)} aria-label="Subtract">-</button> <! -- defined count variable --> {count} <! -- Add button --> <button on:click={() => (count += 1)} aria-label="Add">+</button> In the test file, the initial value is assumed to be 0 , so if the value 1 is set, there will be an error. If there is a mistake, an error is also output as follows. Also, the details of the error are as follows. There is an error message such as, "The counter component is expected to have an initial value of 0." It's simple. You have completed the unit test. It is useful since both the configuration file and the test execution file require less description. That is all for Svelte unit tests. Next time, I will talk about Storybook with SvelteKit . Look forward to next time!

Introduction Mabuhay! It has been almost a year since my last blog, and I'm still Mary the merry of the Global Development Group at KINTO Technologies. (BTW, feel free to check out my first blog here ). Well, what has changed since last year? I can say that there are times when am fully occupied with tasks I have to accomplish, and wish to have a personal assistant. I believe they can help us track our tasks which are deemed essential but may be too time-consuming if we do it ourselves. If we are lucky to have one, it will allow us to be able to keep our focus on other bigger things that have to be done as well. This thing about personal assistant is similar to frontend’s state management. It keeps track of the changes we make or actions we take and ensures that our application is running properly as expected. State is the information that we need to drive our app, and we have to manage it throughout our application development. Unveiling the Power of State Management 💪 In one of KINTO’s back office systems, the user is allowed to download multiple data across the website. Initially, one download would only take a second or two until it finishes. However, as time went by, the data grew larger and larger until it came to a point wherein the download was already taking several seconds to a couple of minutes. At this point, nothing is being displayed during the progress and this confused the user as to what happened after he clicked the download button. To get rid of the confusion, we have decided to display a download notification component that will show the download status together with how many downloads are still in the queue.  State management was introduced to me during this project, and I was able to see for myself how powerful it is in front-end development. Responsive User Interface - The website contains several pages with download buttons and every time the user clicks a button, we update our download count icon and show the users how many downloads are in progress. Accuracy - The display inside the download notification component relies on the website’s download buttons. Since the state is the source of truth and we update it every time the user clicks the download button, we are able to make sure that what we show to the user is accurate. Easy debugging - The state is stored in a single location, and it allows us to debug faster. Maintenance - Reusable codes can be created in state management, and it makes our code readable and easy to maintain. Choosing Pinia over VueX  As I have only become aware of state management during this project, my colleagues introduced me to Pinia and VueX. Both of these are state management libraries for Vue.js, and I am free to choose which one to use. After some time researching these 2 libraries, I have decided to use Pinia over VueX mainly due to these reasons: Modular by Design - Pinia allows us to create multiple stores and import only to components where they are needed; while VueX provides us with only one store. Although I only needed one store meant for download in this project, this doesn’t mean that this will be all that we need in the future. It will be easier to manage if in cases we need to add a different module sooner or later. Simpler API - The simple API allowed me to get started easily with state management. States can be directly updated in actions, and mutations have been removed. Official State Management Library for Vue - This is my top reason as to why I chose Pinia over VueX. Pinia is the official state management library for Vue right now. Although VueX can still be used, it is already in maintenance mode, and will no longer have new features. Exploring Alternatives to State Management Libraries If in case we decide not to use any state management libraries, there are other possible ways for us to manage the state and we have to evaluate which of these solutions fit our needs. Listed below are some of the solutions: Props and events - If we need parent-child communication, this one should be our top choice. A parent can pass the data down to its child; while a child can emit events and communicate changes back to the parent. Local Storage/Session Storage - If there is data we want to persist, we can use the browser’s local storage/session storage.  This is ideal for scenarios such as saving user preferences. Event Bus - If there are unrelated components wherein we need to facilitate communication, we can use an event bus. While this approach is discouraged, we can use it in simple scenarios. Conclusion State management plays an important role in frontend development. While our application grows bigger, chances are there will be more and more states we need to manage. Pinia is a friendly state management library and is easy to understand for a junior developer like me. Although nothing technical is discussed here in-depth, I also encountered some issues when using Pinia. How about we meet again in my next blog? 😊 References Pinia What is Vuex? | Vuex The Power of State: A Deep Dive into State Management State Management in Frontend Development: An Overview and Case Study Advantages of Pinia vs Vuex Vue.js State Management: Pinia vs. Vuex Vue.js Events API | Vue 3 Migration Guide

はじめに QAグループのokapiです。 前回の記事では「 QA業務の認知度向上 」というタイトルで、 QAが案件に参画してどのようにQA作業を行っているかを記載しました。 今回は、私が最近ネイティブアプリの案件を多く担当していることもあり、 「ネイティブアプリのQA業務の特徴」について書きたいと思います。 ネイティブアプリのQA業務について 基本的なQAの設計では、テスト範囲（テスト対象/対象外）を明確にしたテスト観点を作成し、 その観点に基づいてテストケース（前提条件・手順・期待値）を作成していきます。 しかし、ネイティブアプリの設計では上記に加え ・iOSとAndroid ・テスト対象のOSバージョンとスマートフォン端末 ・ネイティブアプリの機能 を考慮する必要があるため、機能がそれほど複雑ではないネイティブアプリでも 「テストの規模が大きくなりがちな特徴」があります。 項目 特徴 iOSとAndroid ・iOSはApple社が開発したOS ・AndroidはGoogle社が開発したOS であり、開発環境が異なるため、テストの分量も単純に倍の計算になります。 テスト対象のOSバージョンとスマートフォン端末 一般に発売されているスマートフォン端末は種類が多く、 それらすべてとOSバージョンの組み合わせを網羅したテストは現実的に不可能 ネイティブアプリの機能 携帯端末独自の機能やスペックがアプリの機能に影響するため、 それらの特性をふまえた上で、インストールされたネイティブアプリの動作を確認する必要がある ・Push通知 　ーアプリがユーザにお知らせを送る機能 ・タッチスクリーン 　ー画面上の領域をタッチすることで操作する機能 ・パーミッション 　ーアプリが端末にアクセスする時にユーザに許可・許可しないのポップアップを表示する機能 iOSとAndroid iOSとAndroidのOSが異なるため、「テストの分量も倍」となるので、 工数を抑えたいところです。 しかし、開発チームもiOSとAndroidとBFFで分かれていることもあり、 iOSで不具合がなくても、Androidで不具合が発生する Androidで不具合がなくても、iOSで不具合が発生する APIで不具合があり、Android, iOS両方でテストが必要となる これらのパターンが各機能で発生する可能性があります。 そのため、iOSで確認済みだからAndroidでは省略、（あるいはその逆）というような進め方をすると 「品質に影響する不具合」が残存する恐れがあるため、どちらのOSでも基本実施する方針で進めています。 テスト対象のOSバージョンとスマートフォン端末 OSと端末の「全ての組み合わせのテストは不可能」であるため、 対象アプリの推奨環境（例：iOS15.0以上/Android9以上）を確認した上で、 各OSのシェア率を考慮して、メインで検証する「OS」を決定します。 そして、 メインOS　　：全テスト実施 メインOS以外：表示確認＋OS関連の不具合が発生した箇所 と割り当てます。 「端末」に関しては、端末依存の不具合は稀で、発生しても致命的な事象とはなりづらいので、 基本的に上記のOSに準拠した端末でテストを実施しています。 ただ例外もあり、 カメラ起動を伴う機能テストは、上記OSと端末の割り当てルールとは異なり、 持っている全ての種類の端末でテストを行います。 理由としては、これまでのネイティブアプリのQAで初回のテスト時に、いずれかの端末でカメラ起動時にアプリがクラッシュする、という不具合が割と高頻度で発生していたからです。 ネイティブアプリの機能 ネイティブアプリのQAでは、携帯端末の機能をふまえた上で アプリが仕様通りに動作するかを確認する必要があります。 しかし、仕様書には「アプリの仕様」のみ記載されており、 携帯端末側の機能までは言及されていないことが多いです。 そのため、端末の機能がアプリの挙動に影響することで不具合が発生し得るため、 「端末の機能」を理解した上でテスト設計を行うと、ユーザビリティ観点の不具合を検出できます。 項目 アプリの仕様 端末の機能 ユーザビリティ観点の よくある不具合 Push通知 ・Push通知の 　-タイミング 　-内容 　-タップした時の遷移先 ・アプリ内のお知らせの通知バッジの 　-表示タイミング 　-削除タイミング ・アプリアイコンの通知バッジ 　-複数溜まった時の表示 　-表示タイミング 　-削除タイミング ・状態の変化による仕様 　-ログイン/ログアウト 　-アプリフォアグラウンド/バックグラウンド/ロック画面 ・複数通知受信時にアプリアイコンの数が通知数に一致しない ・アプリアイコンの通知バッジが 　-表示されない 　-表示されるタイミングが遅い ・アプリアイコンの通知バッジが 　-消えない 　-消えるタイミングが遅い ・通知対象でログイン→ログアウトの時に通知が 　-受け取れない 　-通知押下でエラーとなる ・アプリフォアグラウンドの時に通知が届かない タッチスクリーン ボタンやリンクをタップした時の動作 ・ダブルタップ 　-タップを素早く２回行う ・フリック 　-指先で左右に弾くスワイプ ・スワイプ 　-ゆっくりと左右スライド ・ピンチイン 　-二本の指で同時に画面に触れて距離を狭めて縮小 ・ピンチアウト 　-二本の指で同時に画面に触れて距離を広めて拡大 ・ダブルタップで 　-同じ画面が2重で開く 　-登録内容が2重で登録される ・フリック/スワイプ/ピンチイン/ピンチアウトの操作した時に表示崩れが発生 パーミッション ー ・Push通知の許可・許可しない ・位置情報の許可・許可しない ・カメラの許可・許可しない ・Push通知の許可設定が設定と連動しない ・位置情報の許可やカメラを許可でクラッシュ 今後の課題 ネイティブアプリのQA業務では、 「システム要件に沿った仕様」と「アプリ特有の機能」を確認しており、 アプリ開発のQAに本格的に参画していく中で、iOSの審査が厳しいということを知りました。 例えば、 「非ログインでも利用できる」形でないとリジェクトされる GooglePlayのリンクが入っているだけでもリジェクトされる などの内容です。 こういった知見もナレッジに加えていくことで、アドホックテストに観点として組み込んだ上で、 さらなる品質向上につなげていけると考えています。 さいごに 今回は、ネイティブアプリのQA業務の特徴について「テストの規模が大きくなりがち」と紹介しました。 しかし、ネイティブアプリでは、iOS,Android,APIと様々な観点でQAから多くの不具合が起票されるため、改修の対応を行う開発側の負担も高く、 Webアプリと比べて双方のコストが高い傾向にあり、現状では効率性があまり高くないと感じます。 直近で携わったアプリの開発言語はそれぞれAndroidはKotlin、iOSはSwiftでした。 プラットフォームごとのネイティブ開発には、細かなチューニングを行なえる個別最適化といったメリットがあります。 同一のソースコードで開発できるKotlin Multiplatform Mobile（KMM）やFlutterのようなクロスプラットフォームもありますが、端末の制御※など個別のOSに依存する部分は別に学ぶ必要があるなど、デメリットもあります。 ※カメラ、GPS、センサー系等 その点、ネイティブ言語は対応するOSが直接サポートしている言語なので、端末の機能の活用性に対しては自由度が高くなります。 今後は開発エンジニアの指向やアプリの開発目的も踏まえて、最適な開発手法が取られていくと予想・期待しています。 QAエンジニアの立場からも、開発手法に合わせて柔軟にQAテストの効率を上げていけるよう精進していきたいです。

Hello (or good evening), let’s start. This is the first part of our irregular Svelte series. Last time , I roughly described the process to get SvelteKit running. (It has been updated to fit SvelteKit's major update, so please read it.) This time, I will compare the characteristics of Svelte, which is based on the concept of " Write less code ," with other JS frameworks. Svelte / React / Vue.js Although React and Vue.js uses virtual DOMs and Svelte does not use DOMs, they are often compared to each other, and we will do that here. *I will use Svelte (v3) / React (v18) / Vue.js (v3). Fetching & looping Fetching and looping are often written in sets, so let’s write them together and compare them. Svelte Let's start with Svelte. Svelte has its own await/block syntax, that can be written neatly. <script> const fetchItems = async function() { const items = await fetch('URL'); return await items.json(); } </script> {#await fetchItems()} <p>Loading</p> {:then items} {#each items as item} <p>{item.name}</p> {/each} {:catch error} <p>{error.message}</p> {/await} 　 React There are more lines of code compared to Svelte. However, it is usually split up and is almost never left like this. In the beginning, useState is used in the definition. Perhaps this is what is typical of React. function FetchComponent() { const [error, setError] = useState(null) const [isLoaded, setIsLoaded] = useState(false) const [items, setItems] = useState([]) useEffect(() => { fetch('URL') .then(res => res.json()) .then( (result) => { setIsLoaded(true); setItems(result) }, (error) => { setIsLoaded(true); setError(error) } ) }, []) if (!isLoaded) { return <div>Error: {error.message}</div>; } else if (!isLoaded) { return <div>Loading...</div>; } else { return ( <ul> {items.map(item => ( <li key={item.id}> {item.name} </li> ))} </ul> ); } } Vue.js Writing with React feels similar to writing with Vue 3 and 2. <script setup> import { ref } from 'vue' const items = ref(null) const error = ref(null) fetch('URL') .then((res) => res.json()) .then((json) => (items.value = json)) .catch((err) => (error.value = err)) </script> <template> <div v-if="error">{{ error.message }}</div> <div v-else-if="items"> <ul v-for="(item,index) in items"> <li>Number:{{index+1}} Name:{{item.name}}</li> </ul> </div> <div v-else>Loading</div> </template> Reactive This is an essential mechanism in modern frontend applications where components are reused. Svelte In Svelte, preface with $: to make the code reactive. If you do not add $: , it will not be executed even if you change dependent values. If you are used to other frameworks, you may be confused at first, but once you use it, you'll be impressed by how clear it is. $: foo = false React Without getting into details, you generally use useState to define in React. Comparing it to Svelte, useState has the same role as $: . import {useState} from 'react' const [foo] = useState(false) Vue.js When using Vue, it changes when you generate with reactive . <script setup> import { reactive, computed } from 'vue' const state = reactive({ count: 0 }) const increment = () => { state.count++ } </script> About props I will now compare by passing a basic string. They all seemed different, but they have almost the same writing style. Svelte <script> export let name </script> <p>Hello, I'm　:{name}</p> <script> import ChildComponent from './ChildComponent.svelte' </script> <ChildComponent name="Svelte" /> React const ChildComponent = (props) => { return <h1>Hello, I'm　:{props.name}</h1>; } export default ChildComponent; import ChildComponent from './ChildComponent.jsx' function App() { return ( <ChildComponent name="React" /> ); } export default App Vue.js <template> <p>Hello, I'm　{{name}}</p> </template> export default { props: { name: String, } } <script> import ChildComponent from './ChildComponent.vue' </script> <template> <ChildComponent name="Vue" /> </template> Import the child component and pass the value. All of them were easy to understand. General comments This was a short comparison of Svelte, React, and Vue.js. What do you think? Each one has its own merits, Svelte's focusing on " Write less code ." You will notice that it is remarkably accessible. Have a good Svelte life. And if you are new to it, please write with Svelte, it is a very fun framework.

はじめまして！グローバル開発グループ UXUI チームのモジです。 KINTOテクノロジーズでの私の主な役割はプロダクトデザインで、自分のビジネス知識とデザイン・スキルを融合できる点が気に入っています。私は、使いやすく、美しく、測定可能な結果を生み出すユーザーインターフェースの創造を目指しています。 私の究極の目的は、複雑な問題をシンプルでユーザーフレンドリーな体験に変え、ユーザーが満足できるようにすることです。 TechBlogに初めて記事を書きます！ TechBlog 自体のデザイン変更プロセスについてご紹介します。楽しんでいただけると嬉しいです。 取り組み範囲と困難だったこと 昨今のデジタル社会では、変化に適応するために刷新と再開発が常に必要です。 KINTOテクノロジーズ では、TechBlogのデザイン変更を2つのフェーズ段階に分けて実施することを決定し、大きな変化を遂げました。 KINTOデザインシステムに準拠することを大前提として、各フェーズにはユーザーエクスペリエンス向上と機能性向上といった明確な目的を設定しました。 以下の画像は、TechBlogチームと協議した結果、デザインを変更した範囲を示しています。 デザイン変更の範囲 デザイン変更のプロセスでは、入り組んだ迷路を進むように様々な困難が待ち受けていました。 KINTOデザインシステムは、動的で常に進化を続けています。また、ウェブパターンについては、デスクトップビュー用の組み合わせに限られてしまっていました。このような状況においては、 新しい機能をKINTOデザインシステムに合わせる ために、綿密な計画を立て実行する必要があり、これが大きな課題のひとつとなりました。 こういった複雑さに加えて、時間的な制約と、モバイルビューとデスクトップビューという2つのプラットフォームに対してデザイン変更を行う必要性がありました。 以下の画像では、モバイルとデスクトップの両方のビューにおける現デザインの主な問題点を示しています。 モバイルビューの主な問題点 デスクトップビューの主な問題点 第1フェーズ：ユーザビリティとアクセシビリティ重視 デザイン変更プロセスの初めの段階では、主に デスクトップとモバイルの両方 でTechBlogのユーザビリティとアクセシビリティを向上させることに取り組みました。 関連する記事や情報にアクセスしやすくするための重要機能として、 検索バー を導入しました。 読者は、この機能があることで幅広いブログコンテンツをスムーズに検索することができるようになります。 モバイルビューの検索バー デスクトップビューの検索バー このフェーズでのもうひとつの大きな改善ポイントとして、 カテゴリータグ を配置しました。この機能を利用すれば、読者はテクノロジー関連のトピック全体を簡単に分類、把握できます。コンテンツを検索するプロセスが強化され、閲覧体験の向上につながります。 スクロール可能なカルーセル形式のカテゴリータグ カテゴリータグを右サイドバーに配置 このフェーズでの重要なビジュアル変更は、トップページの ブログ記事サイズ の調整でした。 デスクトップとモバイルの両方でこの変更を行いました。これにより、コンテンツの読みやすさと全体的な視覚アピールのバランスが良くなり、ユーザーインターフェースが向上しました。 デスクトップビューでのブログ記事サイズ　ビフォーアフター 第2フェーズ：機能性と多言語アクセスの強化 TechBlogデザイン変更の第二フェーズでは、他にも便利な機能が統合され、全体的な機能性とユーザーエクスペリエンスの向上につながりました。 特筆すべきは、 言語切り替え が導入され、英語と日本語両方の読者に対応できるようになったことです。 この機能は、トップ・ナビゲーション・バー（モバイルビュー）のスペースの制約があるため当初は難航したものの、最終的には、読者が簡単に言語オプションを切り替えられるような形で盛り込むことができました。 モバイルビューでの言語切り替え デスクトップビューの言語切り替え このデザイン変更のフェーズでは、記事ページの インデックスの配置 をモバイルビュー用に調整し、長文のブログ内のナビゲーションを効率化しました。 モバイルビューのインデックス配置 さらに、 ソーシャルメディアボタン も配置変更したことで、共有が簡単になり、デスクトップビューでのユーザーエンゲージメント向上に寄与します。 デスクトップビューの共有ボタンの配置 存在しないページや削除されたページにつまずく可能性のあるユーザーを誘導するため、 404ページ も本フェーズの一環としてデザインしました。 また、各記事の末尾には KINTOテクノロジーズの採用セクションへの直接リンク を貼り、技術に精通した読者を優しく誘導し、キャリアの可能性を探ってもらうことができます。 モバイルビュー デスクトップビュー さらにこのフェーズでは、記事を執筆者の名前で検索できる機能を組み込みました。このために 2つのフォーマット をデザインしました： シングルオーサー（単著）フォーマット ：複数の執筆者を1つのプロフィールに収容。各ライターの名前をクリックして記事検索が可能。 マルチオーサー（共著）フォーマット ：執筆者の名前で記事を整理できるほか、それぞれの専用プロフィールを表示。 2つ目のフォーマットは優先順位が低かったため、開発チームは1つ目のフォーマットでまず進めました。執筆者のプロフィールを合理的なアプローチで表現することでユーザーエクスペリエンスの向上を図ります。 モバイルビュー モバイルビュー デスクトップビュー デスクトップビュー 目的 このデザイン変更の根本的な目的は、ユーザーエクスペリエンスを豊かにすることでした。 検索のしやすさ、関連コンテンツへのアクセスのしやすさ、ユーザーインターフェースの全体的な向上を目指し、微修正・追加・調節をしていきました。 モバイルビューおよびデスクトップビューでのデザイン変更前と変更後 KINTOデザインシステムが重要な役割を果たしました。このシステムに依拠してはいますが、必要な改造も行いました。いくつかのコンポーネントはスクラッチで作成したり、ファイル内でローカルな微調整をするなどして、要求を正確に満たせるよう段階的に作業していきました。 このようなアプローチをとることで、ダイナミックなデザインシステムとTech Blog特有の機能要件の両方に対しバランスよく沿うことができました。 以下の画像では、最初にTech Blogで使用できるようデザインされた フッターコンポーネント が、 KINTOデザインシステム へ組み込まれ、他のプロジェクトに適用された際にどのようになるかを示しています。 モバイルビューでのフッターコンポーネントの例 デスクトップビューでのフッターコンポーネントの例 予想される効果 期待される主な効果について、以下に概要をご説明します： 検索バーとカテゴリータグを組み込むことにより、記事の検索がしやすくなりました。検索の手間を省き、コンテンツ発見プロセスの改善につながっています。 多言語機能の導入により、言語の壁が無くなり、多様な読者（特に英語または日本語を使う方）に記事を理解してもらえるようになりました。 デザインを修正したことで、ブログ記事の見栄えと実用性が改善されると考えられます。SNS共有ボタンを配置し、404ページを工夫、記事サイズの調節も行い、機能拡充を図りました。これによりユーザーエンゲージメントの飛躍的向上が期待されます 各記事の末尾に採用情報のリンクを付けたことで、技術志向の読者がKINTOテクノロジーズの採用スペースにうまく誘導されるだろうと考えています。 これら２つのフェーズにわたるデザイン変更は現在進行中です。見栄えと機能拡充、ユーザビリティ向上をバランスよく達成したいと思っています。 完成後は、 ユーザビリティテスト プロセスを実施し読者からのフィードバックを収集します。今回の変更があらかじめ定めていたゴールを達成できたかを確認していきます。 次のステップ これらのデザイン変更は始まりにすぎず、改善プロセスは今後も続きます。 Tech Blog向けとしてローカルコンポーネントの微調整とデザインを行ったわけですが、これらがKINTOデザインシステムに統合できるかどうか、精査することになります。 承認が下りれば、他プロジェクトでも利用できるようになります。これにより今回のデザイン変更は、当ブログの枠を超えた将来的な統合に向けてポジティブな効果を及ぼしていくことと考えられます。 急速に変わるデジタル社会の中で、KINTOテクノロジーズが変化し続けていく中、今回のデザイン変更がテックブログの今後にどう影響するか、楽しみです。 参考 KINTOテクノロジーズ - TechBlog KINTOテクノロジーズ– 企業情報 KINTOテクノロジーズ- 採用情報 ニールセン・ノーマン - ユーザビリティ・テスト

はじめに こんにちは KINTO テクノロジーズで KINTO ONE(中古車) のフロントエンド開発を担当している中原です。 KINTO ONE(中古車) は KINTO ONE でのリースアップ車両を再度リース契約いただくための EC サイトとなっており、実際の在庫車両情報の確認や契約までの手続き、契約の管理などができるようになっています。 KINTO ONE(中古車)サイト 新車の納期が長期化して久しいですが、比較的短い納期で高品質な車両を利用できることや、中途解約時の解約金が 0 円と設定されている手軽さがおすすめのサービスとなっています。（2023 年 12 月現在、東京都・愛知県のみでのサービス展開となっています。） 車両画像の問題 新車と異なり中古車を扱うサイトにおいては、商品として個別の車両を扱うことになり、当然 EC サイトとしてはそれぞれの車両の画像を掲載することとなります。 KINTO ONE(中古車) では、リースアップ車を商品化するにあたり各車両の撮影を行い、その画像がバックエンドの車両管理サービスに格納されるようになっていました。 サイトの表示にあたっては、バックエンドから画像 URL を含む車両情報を取得しフロントエンドのサーバコンテナにてページとして構築し、車両画像に関してはクライアント側から車両管理サービスの画像配信パスから取得するようになっていました。 --- title: サーバ構成（概要） --- flowchart LR %%外部要素のUser U[User] %%グループとサービス subgraph GC[AWS] subgraph FE[中古車サイトフロントエンド] subgraph CF["Cloudfront"] end ECS("フロントエンドサーバ") end subgraph BE[車両管理サービス] UCAR("車両管理サーバ") end end %%サービス同士の関係 U --> |"サイトアクセス"|CF CF --> ECS ECS --> |"車両情報の取得"|UCAR U --> |"車両画像の取得"|UCAR %%グループのスタイル classDef SGC fill:none,color:#345,stroke:#345 class GC SGC ここで、車両管理サービスが配信する車両の画像はワンサイズの JPG となっていたため以下のような問題がありました。 非効率な圧縮方式 表示サイズに関係ないサイズでの配信 実際のサイトでの表示サイズに関わらず、横 1000px 超の画像を配信していた 実際にサイト性能を測定する PageSpeed Insights でも、車両画像に関する指摘が多く挙げられていました。 PageSpeed Insights の指摘 ありたい姿 まず挙げられるのは、PageSpeed Insights で指摘されたポイントの改善です。 効率的な圧縮方式で配信している 表示サイズに応じた画像サイズで配信している これらにより、ページ表示のスピード改善・クライアントのネットワーク通信量の削減ができるだけでなく、サーバ側のコストも改善されます[^1]。 また、開発・運用上の観点から次の点もありたい姿としてあげます。 追加リソース[^2]は最小限に フロントエンド側から画像の変換設定の要求ができる 費用を抑えて、クイックに対応できる リソースを追加すればそれに付随する管理工数も増えるため、できるだけ小さな構成でできることが望ましいです。 また変換設定については、デザインの変更や、新しいタイプ高解像度のデバイスの追加などにより表示する画像への要求が変わりうることを念頭に置いています。こういった時にフロントエンド側から容易に取得する画像の解像度や圧縮方式が変更できることが望ましいです。 [^1]: KINTO テクノロジーズでは主に AWS 上にサービスを構築していますが、インターネットへのデータ送出もコストがかかるポイントです [^2]: ここで言う「リソース」とは AWS のリソースだけでなく、画像変換の外部サービスなども含めた概念です。 画像変換手法の検討 車両管理サービス側で写真登録時に画像変換・配信 この方法は、事前に定めたものを作るだけならば要求を満たしていると言えますが、前節「追加リソースは最小限に」や、「フロントエンド側から画像の変換設定の要求ができる」の部分に合わないため選択しません。 外部サービスの利用 imgix をはじめ、さまざまな画像変換機能を持つ CDN がありますが、こちらも選択しませんでした。 サイトの利用状況から月額で言えば、200-300USD のプランがフィットしそうでした。また、作業として現状の画像を管理しているストレージに対する設定変更やそのための社内調整などで、そこそこの工数が発生しそうです。 外部サービス利用し監視等の工数がかからないことは良いですが、 KINTO ONE(中古車) 　はまだまだ途上のサービスであり、導入効果の見積りも難しい中、金銭的・時間的コストを鑑みて選択しませんでした。 Next.js のリモート画像最適化 最も実装の工数がかからない方法としては Next.js の Image コンポーネントを用いて画像を最適化させる方法ですが、この方法も現在のサイト状況に見合わず取らないこととしました。 現状、Next.js をフレームワークとして利用し、サーバサイドレンダリングによるサイト配信を行っていますが、サーバとしては比較的小さなインスタンス構成で実行しています。しかし、1 ページあたりの画像の点数も多く、処理の負荷がピーキーになることから、最小負荷時におけるインスタンスサイズを大きくする必要がありそうでした。実際にサービス初期に同様の設定を行っていた際にサイトがダウンしてしまうこともありました。 画像変換のためだけにインスタンスサイズを大きくすることは避けたかったのでこの方法も選択しませんでした。 Lambda@Edge で自前で構築（★ 採用） Cloudfront と組み合わせでエッジ側で画像変換を行う関数を実行し、変換後の画像を配信する方法です。サイト自体は Cloudfront 経由で配信していましたので、少し設定を追加するだけで素早く導入できそうでした。費用面も画像の枚数から変換処理に関してはほぼかからず、サイズを圧縮することから転送費用も圧縮できます。実装の手間は少々かかりますが以降はサーバレスで動作してくれるので、同時実行数にさえ気をつければそこまで管理の手間も掛からなそうでさそうでしたのでこの方法で行くことにしました。 Lambda＠Edge での画像変換機能追加 以下のような構成へと変更します。 --- title: サーバ構成（改修後） --- flowchart LR %%外部要素のUser U[User] %%グループとサービス subgraph GC[AWS] subgraph FE[中古車サイトフロントエンド] subgraph CF["Cloudfront"] LM["Lambda@Edge<br>リサイズ・WebP変換"] end ECS("フロントエンドサーバ") end subgraph BE[車両管理サービス] UCAR("車両管理サーバ") end end %%サービス同士の関係 U --> |"サイトアクセス"|CF CF --> ECS ECS --> |"車両情報の取得"|UCAR U --> |"車両画像の取得"|CF LM --> |"車両画像の取得"|UCAR %%グループのスタイル classDef SGC fill:none,color:#345,stroke:#345 class GC SGC 車両画像のパスへアクセスした際のビヘイビアを追加し、Lambda@Edge でリサイズ・WebP への変換を行なった結果を返却するようにしました。 Lambda@Edge での処理内容については、先例 ^3 や AWS 公式のガイド ^4 など、情報が多くあるのであまり詳しくは記載しませんが、今回の実装におけるポイントに触れておきたいと思います。 クエリパラメータでの画像変換内容指定 画像の変換設定は以下のクエリパラメータで指定できるようにしておきます。 query 説明 width リサイズ後の画像の横幅を指定 quality 画像変換時の画質を設定 これによりサイト側から表示したいサイズの画像を指定したサイズ・画質で取得できるようになります。 キャッシュ設定 上記のクエリパラメータをキャッシュキーとして設定するようにします。これを怠ると、先に生成されたサイズの画像がキャッシュされてしまい、大きなサイズの画像を要求したのに小さいサイズの画像が表示されてしまう、といったことが起きてしまいます。 next/image のカスタムローダー設定 Cloudfront 側で画像変換をできるようにしたら、ページ側でも対応する実装が必要になります。 本サービスは Next.js でサイト構築していますので、Image コンポーネントに対してカスタムローダーを設定することで細かな設定をすることなく表示されるサイズに対して最適な画像のサイズでリクエストすることができます。 なお、表示に対して最適なサイズを選択するためには sizes プロパティの設定 が重要なので注意しましょう。 この値を設定することにより、Image コンポーネントのレンダリング時に srcset プロパティを実際の表示サイズに適した値で設定してくれます。 import Image, { ImageLoaderProps } from "next/image"; // 車両画像用コンポーネント export function CarImage({ src, sizes, alt = "車両画像", className = "" }) { // カスタムローダー function optimizeLoader({ src, width, quality }: ImageLoaderProps) { return `${src}?width=${width}&quality=${quality}`; } return ( <Image className={className} src={src} alt={alt} sizes={sizes} quality={90} loader={optimizeLoader} loading="lazy" /> ); } このようなコンポーネントを作成し利用することで、サイト上の表示サイズに応じた画像サイズのパラメータでリクエストされ、リサイズ・WebP 変換された画像を表示できるようになります。 結果 今回の手法で画像最適化を行うことで、PageSpeed Insights の画像に関する指摘が解消していることが確認できました。 PageSpeed Insights の画像に関する指摘が解消されました 最後に 今回はサイトパフォーマンス改善のうち、表示画像について最適化を試みました。ですがまだまだパフォーマンスの問題は多く山積しています。 引き続きサイトパフォーマンスの改善をし、ユーザにより快適な体験をしていただけるように取り組んでいきたいです。

はじめに KINTOテクノロジーズでQAグループFEチームのリーダーをしている遠藤です。 普段、私の作業としてはKINTOテクノロジーズで開発しているKINTO Webサイトのフロントエンド部分について、複数のプロダクトやプロジェクトからQA案件を確認させてもらい、各QA担当者の作業の割り振りや管理をしています。 作業をしているとQA内部だけでなく開発側の方々とお話しする機会も多く、今回は雑談をしている時に、 「なぜQAをやるのか？」 という質問があがり、こういう場をいただいたので私なりの思いを書いてみようと思います。 開発においてQAは、不要か？ 「なぜ、QAをやるのか？」をテーマにQAの役割や必要性を書く前に、 そもそもQA自体必要なのか？ という点について考えてみたいと思います。 品質のセミナーや記事とかで、QA不要論があがったりすることがあります。アジャイル開発の中でチームの外にQA部隊を置くのではなく、それぞれのチームメンバーの中にQAの役割が備わっていれば、QAは不要だというのが私が聞いたお話です。 たとえばアジャイル開発チームとは別にQA部隊がある場合、以下のような懸念が考えられます。 スプリントの中で、仕様変更に柔軟に対応しようとすると、そのあとのQA工程に影響が出る可能性が高い QAが仕様を理解するまでのリードタイムが別に掛かることで、QA工程が長くなる 不具合が発生した場合、スプリントの中で対応しないためその分の手戻りが大きくなる このような点から、アジャイル開発においてはチームの中に開発からQAの役割を含んだテストまで対応できるメンバーさえいればこれらの懸念無く対応できる、というのが話の主旨かなと思っています。 ここで、QA部隊は必要なくともQAの役割自体は否定されてない点が重要だと考えています。 逆に、あくまでQA部隊が必要というお話をされている方の意見として挙げられるのが、 開発とは独立した客観的に判断するQA部隊があることで、違った視点からより品質を高められる 仕様のナレッジがQA部隊に集中しやすくプロジェクト情報を横串で得られる ナレッジを元に、並行して動いている他のプロジェクトに対しても考慮漏れや必要な情報を組織として提供できる という部分かと思います。 一方で、QAの役割をアジャイル開発チーム内に置くことの難しい点として、 開発からシステムテストまで、テストという面において、高度なスキルを持つメンバーを集めることができるのか 集められない場合にはメンバーの育成が必要になるが、適切なスキルを取得するまで時間がかかる スキルを持つメンバーにナレッジが集中しやすく、そのメンバーがチームから離脱するとQA対応が難しくなる ということが挙げられるかと思います。 他の企業のコラムなどでもQAという部やグループは置いてないが、サービス利用者のためにQA作業は行っているという記事を読んだことがあります。つまり、QA部隊を組織として作るか作らないかは開発手法だったり、組織文化を考慮して選択する。ただし、システム要件にもとづき利用者のために全体的な品質を確認するQAの役割が必要だということは、皆さん共通認識をもっているのかなと感じています。 テストだけではないQAの役割 確認・検証を行うにあたり、QAはテストをするためのテスト専門チームで、QA＝テストと錯覚する方も多いのですが、QAの役割としてはテストだけではありません。その点に関して大きく3つ記述します。 （１）仕様としての正解を確認する テストを設計する際、システム要件を確認した上で不明点を開発側、業務側にお尋ねします。QAはテストを実施する点から、まずは、要件をもとに仕様の正解を確認します。この作業を通して、仕様の細かい部分に関してQAが指摘することで、要件漏れや仕様の整理につながることがあります。 KINTOのWebサイトで「審査申込の流れ」部分の画面見直しがあった場合を例にご説明します。 この場合、テストの期待結果としては「お申し込みに必要なもの」、「審査お申し込みのステップ」のデザインが、画面仕様と一致していることになります。 お申し込みに必要なものとして、通常のWebからの申し込みの場合は運転免許証画像のアップロードが必要です。ただ、KINTOのサービスは販売店様の店頭でも提供しており、店頭の場合ですとその場で運転免許証を確認できるため、画像をアップロードしなくて良い内容になっています（下記の赤枠の運転免許証の部分）。その点を開発側に確認したところ、だしわけの考慮が必要だということに気づいてもらえたということがあります。 細かい点ではありますが、想定される利用ケースや条件を考慮し、テストの期待結果に相当する正解は何か？という点をしっかり確認します。このように、曖昧な表現や漏れている部分に対して具体的にしていくことで、本来あるべき仕様の確認をします。 先述のように、QAでの仕様確認を通じて、開発側が認識していなかった要件を指摘できることがあります。 また、要件定義段階ではないものの開発工程と並行してテスト観点をまとめることで、テストを実施する前に早めに品質を高めることができます。 （２）テスト設計時における資料整理 短期間に開発する際、開発しながらドキュメントを整理することは時間的に難しい場合があります。 各仕様書があっても、一覧化できていなかったり、操作手順がまとまってなかったりというケースもあります。QAでは上記（１）で仕様の正解を確認しつつ、テスト設計でシナリオ、機能確認、表示確認について、下記のように必要な観点の洗い出しを実施します。 その際、元の情報は開発側にあるので、基本的にはその資料を流用しますが、必要に応じてQA側のテストで確認しやすいように、一覧化したり手順をまとめたりします。 QAが作成した資料を参考にすることで全体の機能を俯瞰して見ることができたり、ある手順を確認するのに役立った等、QA以外の社内関係者から嬉しい言葉を頂くことがあります。 情報としてはプロジェクト内に集約されるため、QAでまとめる資料の内容が最新とは限りませんが、あくまで現状の仕様理解を目的として整理します。また、QAでは並行して動いているプロジェクトを横串に見れている点から、仕様を整理している中で開発側に懸念事項などの情報提供をできることもあり、品質面での支援になっていると言えます。 （３）不具合分析によるフィードバック プロジェクトが完了した後、QAテストの結果を元に、不具合分析を行います。下記のようにプロジェクト毎に行うのが中心になっていますが、プロジェクトやプロダクト毎の特徴により、要件定義段階での考慮を厚くしてもらうとか、単体テストを強化してもらうなどのフィードバックを行います。 こういった内容を振り返りの場でプロジェクト関係者にフィードバックをすることで、次回のプロジェクト進行の参考にしてもらいます。 不具合分析する際に、プロダクト毎での不具合傾向やプロジェクトとしての課題などを明確にするという点を挙げていき、それについて認識を合わせます。 弱み部分だけの報告ではなく、例えば要件の詰め方を他のプロジェクトとは違った手法を取ってみたとか、単体テスト部分を工夫したという場合に、その効果が出ているという点もしっかり伝えることが大事になります。この報告は、取り組みが良い方向に向かっておりさらにその部分を強化する指針となるので、フィードバックの際には、マイナス面だけにならないよう注意しています。 このようにテストだけではなく、品質を作りこむ面でもQAの役割には意義があります。 結局、QAってなんでやるの？ Webやアプリでサービスを提供する我々にとって、例えば デザインは一致しているが、ボタンの位置が画面ごとに異なる 画面遷移に時間がかかる PCでは問題ないが、スマホだと表示サイズが変わることで文字が読みにくくなる という事象があった場合、提供したいサービスの魅力を伝える以前に、使いづらい見づらいという点から利用されなくなる恐れがあります。 要件としては満たされていることの確認だけではなく、サイトの訪問者が快適に使えるように改善できる点においてQA作業を行う意義はあると思います。 また、QA業務を通して横串でシステム要件を確認できるため、ある程度の仕様情報が得られることで、想定していないプロジェクトのリスクを発見できたりする役割もあります。 KINTOテクノロジーズでは、各プロダクト毎に複数のプロジェクトが並行して動いているため、 プロジェクトのリリースタイミングによるリスクが発生しないか？ 共通の仕様が変更される場合、影響があるであろう他のプロダクトがその内容を認識しているか？ 一連の試験を実施することで、プロダクトをまたがるようなデータの連携を含めた機能に問題ないか？ という、事前にプロジェクト側で考慮が想定されている部分においても、QAのタイミングであらためて確認を行うことで、残っているリスクを洗い出し品質の作りこみを実施しています。 このように、実際にサービスを利用されるお客様のためにQAが客観的な視点から要件を確認し、品質面の作りこみのサポートを行う必要性はあると思います。 この「お客様のために」という気持ちは私は大事だと思っています。我々のサービスは大多数の方々に利用されています。ただ、お客様は、個人としてそのサービスに向き合います。そのお客様が、ちょっとでも使いづらかったり、見づらかったりすることで、二度とサイトを開かなくなるという事態は、避けなければいけません。 なので、この「お客様のために」という気持ちが、本来伝えたいサービスの魅力を伝え、更なるお客様の獲得につながるという、好循環のスパイラルをにぎる重要な役割と考えています。 さいごに 今回、そもそもQAなんでやるのという漠然とした点から私の考えを記述しました。記事にも書いたように、QAの役割は組織ごとに異なるものでもあります。今回の内容に賛同いただける方や、私が持っていない意見をお持ちでQAに興味のある方など、ご意見ありましたらご連絡いただければと思います。 また、一緒にQAやってみたら楽しそうだなと思った方々、QAを盛り上げてもっと良くしていきたいと思っている方々、いつでも大歓迎ですので以下の採用ページからぜひ応募してください。カジュアル面談からでもOKです。 https://hrmos.co/pages/kinto-technologies/jobs?category=1783696806032474116

Hi, my name is Shida from the CIO office at KINTO Technologies (KTC). I usually work to support everyone at KTC! Aiming to be a bridge between teams and people, I place importance on communicating with everyone on a daily basis. In this article, I would like to introduce you to the community activities we are doing outside of the company. What are Community Activities? At KINTO Technologies, like-minded employees organize activities for the purpose of communicating more between each other. Many of these are frequently formed through shared interests, such as a community of individuals who appreciate one thing or the other. I myself am a member of multiple communities (maybe 21 or so...) and feel the following benefits from the expansion of communication. Benefits of Expanding Communication Opportunities Among Colleagues Deeper relationships can be built when you get to know different sides of your colleagues that don't come up in our everyday work. Provides an opportunity for a break to recharge yourself. Team members who don't typically collaborate frequently can deepen their ties. It often translates into effective collaboration in our daily work by becoming close through club activities. Stimulating communication ＝ more opportunities to get to know each other Internal communities can contribute to cultivating corporate culture from bottom up. I also believe that effective communication is the foundation of a strong organization and can contribute to keeping a vibrant business. I might have gone a bit overboard in making it sound too grand, so let’s move on to the second half in a more casual way! Usually, we spend our days staring at the PC in the office, so physical activity is a must! Let me introduce you to some sports communities I'm in (^o^)/ Sports Communities 🏀Basketball Club🏀 ＼Characteristics／ Members: 25 Anyone with a passion for basketball is warmly welcomed! About 10 joiners every match, even on weekends Cheering each other and sweating together lively by passing and shooting practice. Introduce a fresh form of communication distinct from the usual. Held in a beautiful gym close to the office In super intense games, the energy is so high that the camera loses focus completely lol ⚽️Futsal Club⚽️ ＼Characteristics／ Members: 39 An atmosphere where both beginners and experienced members can enjoy (we even have a former J-League player joining!) It’s a great opportunity to communicate with people from other teams and have a good time together. It's okay to just join to cheer or watch them play. Anyone can casually join when they feel like. Communication beyond age and nationality (sports transcends language barriers) My memorable first shooting scene⚽️ (I lack composure in my arms, right?) Whether I scored a splendid goal after this... I leave it to your imagination, everyone(˘ω˘) Even in sudden torrential rain, the game goes on. You can still experience the vitality of youth as a working adult!✨ ⛳️ Golf Club ⛳️ ＼Characteristics／ Members: 21 A community that transcends team divisions and positions We practice at the driving range and play rounds together (about once a month during the season) Direct OJT from the manager, fostering camaraderie and contributing to personal growth Communication throughout the day (including training camps) A refreshing feeling of a driver shot in the midst of nature cannot be experienced in the city. (Wanting the echoing sound of striking a ball to be my alarm clock!) Several members have started playing golf since they joined the company (close-knit ladies) In the tension-filled green surroundings, we silently cheer for each other, ‘Go for it!’ . 🎾 Tennis Club 🎾 ＼Characteristics／ Members: 20 There are many experienced members that kindly offer advice for those who are starting out. The matches will be a real test for both newbies and seasoned players! Held after work at a tennis court close to the company. Enjoy beer after tennis! (Everyone loves alcohol). Practice scene Since half of us are beginners, the experienced members offer friendly lessons on techniques ＼( ˙-˙ ＼)(／ ˙-˙ )／ Thanks to their careful instructions, every beginner caught on quickly! Summary Did any of these activities interest you? As communities are formed organically, a new one might be emerging as we speak...! How to spend your time after work or the weekends varies from person to person. As one option, KTC offers many opportunities to enjoy sports and connect with other employees. You can make the most of your free time by refreshing yourself through exercise! We look forward to welcoming you to these communities when you join KTC 🤗

はじめに みなさまこんにちは！グローバル開発部兼テックブログ運用チームの森です。普段は Global KINTO Web のPdMや各国個人情報関連法の対応リードを行っています。（まぁつまりいろいろやってます。笑） 私事ですが、私の プロダクトエンハンスチーム が社内の組織体制変更に伴って7月より新しいレポートラインになりました。(名前も若干変わりました！) 新しいグループマネージャーは水野さんです。今までもコミュニケーションがありましたが、他のチームとの交流もあまりなかったので、これを機にマネージャーとチームリーダー陣で「リーダーズインテグレーション」を実施しました。本日はそのレポートです📝 8月に実施したのですが、私の筆が遅く、年末の記事リリースになりました 😅 リーダーズインテグレーション？ インテグレーション(Integration)とは統合を意味し、リーダーとチームメンバーの意思疎通を図り、チームの結束力を高めるためのフレームワークです。 新しいリーダーを抜擢した時や、チームの関係性に課題があり、結束力を高めたい時に実施すると効果を発揮します。 参考: リーダーズインテグレーションのすゝめ 私がこのワークショップを知ったのはコーポレートITグループで実施したと伺ったのがきっかけです。どうやら前職でご経験があった様子。 「新しいリーダーを抜擢した時」とはちょっと違いますが、ちょうど私が新しいレポートラインに所属したタイミングだったのと、他のチームとあまり交流できていなかったので、「これ、ええやん…！」となってマネージャーに持ち掛けたところ、快諾いただけたので、コーポレートITのずーしみさんにファシリテーションをお願いして実施しました✨ リーダーズインテグレーションの流れ 開催日時：2023年8月29日 17:30~19:30 場所：神保町オフィス 参加者：グローバル開発部グローバルプロダクト導入グループ マネージャー1名 リーダー5名 ファシリテーター：ずーしみさん from コーポレートITグループ Time Action Time (m) 17:30 取り組み説明/ファシリテーター自己紹介 5 17:30 リーダーからご挨拶 3 17:33 (リーダーお部屋から退出) 17:35 リーダーについて知っていることを書き出す 15 17:50 リーダーについて知らないことを書き出す 15 18:05 自分たちのことでリーダーに知っておいて欲しいことを書き出す 15 18:20 リーダーのため、グループのために自分たちが出来ることを書き出す 15 18:35 (メンバーお部屋から退出、リーダー入室) 18:40 リーダーがみんなから出た意見を見て回答を考えるタイム 10 18:50 (メンバーお部屋に戻ります) 18:55 リーダからの回答タイム！ 30 19:25 バッファ&フリートーク 5 20:00 懇親会 導入 まずはファシリテーターとリーダーそれぞれから、本ワークショップを導入した背景とワークショップの説明をしてもらいます。今回、水野さんからは「普段の1on1やミーティングとは異なる場としてみんなから意見をもらえると嬉しい」とのお言葉をいただきました。 そしてその後、なんとリーダーは退席します！ここからが本番です。 メンバーによる書き出しタイム リーダーについて「知っていること」「知らないこと」「知っておいてほしいこと」「リーダーのためにできること」を書きだします。プライベートの話も入るのであまり多くは書けないですが、少しだけ挙がったものを書いてみます。（水野さん、おゆるしを。） リーダーについて知っていること📝 KINTOテクノロジーズ入社当時はJapanの中古車案件担当 グローバルには１年ほど前からJoin 猫が好き🐱 運転がお好き🚗　などなど 私にとっては新しいマネージャーでしたが、他のリーダー達にとってはそうでなかったので、「へ～、そうなんだ」と思うことが多かったです。 リーダーについて知らないこと📝 なぜKINTOテクノロジーズに入社したのか これまでの経歴 開発経験 💻 評価するポイントは？　などなど ここは逆に「意外とみんな同じこと思っているんだな」という印象でした。 リーダーに知っておいてほしいこと📝 もっとコミュニケーション取りたい R&D開発とかしてみたい メンバーのマネジメントに悩んでいる みんなでキャンプしたい⛺　などなど ちょうど弊社の評価時期だったこと、また、組織体制が変わったことで全員初めて評価する側になったこともあって、同じことに悩んでいることがわかりました。 リーダー・グループのためにできること📝 車両や自動車業界の知識がある 愚痴、聞きます 他の開発チームとのコネクション エンジニア向け勉強会開催できます 新しいビジネスアイデア出します　などなど 各自自分ができることがポンポン挙がってきたことに良い意味で驚きました。 リーダーからの回答タイム リーダーが合流し、貼られたふせんそれぞれに回答します。とは言っても、誰が書いた？とかを聞くことはなく思っていることをお話いただく形です。マネージャーの思っていることを聞く機会なんて意外とないので、30分もあっという間に過ぎさりました。 猫アレルギーなのに猫好き（かわいそう）、トップス白、パンツは黒のセットのクローゼットがある（どこかで聞いたような…）といったプライベートな内容から、評価は期初から何が変わったか？が大事、腐らずにやっていってほしいといったメンバーに対する意見などをお伺いできました。 特に、リーダーに知っておいてほしいこと・グループのためにできることに対しては、前のめりなふせんが多かったからか、「評価や組織の悩みは共有しあおう」「コミュニケーションの課題を解消するために協力してもらいたい」「もっと任せても良いんだなとわかった」といったコメントをいただきました。なんとなく、チームがUniteされた印象で、熱い気持ちになりました。 モザイクだらけですが、こんなにたくさんのふせんが貼られました！ 所感 メンバーとして参加してみて、マネージャーとの繋がりが深まったのはもちろんなんですが、各チームリーダー達が思っていることを聞けたことがとても良かったです。プロジェクトによっては普段全く関わらない方もいるため、参加者みんなが想像以上にKINTOテクノロジーズやグローバルKINTOに対して真剣に考えていることがわかりました。 参加者からの声： 自分以外のチームメンバーが抱いている課題など知れてよかった。 自分が上司に求めている事/知っている事の深さ/広さを、他のメンバと比較して客観的に見る事ができた 話しやすい雰囲気を作るために、怒ったりネガティブな感情を出さないようにしていましたが、あながち間違っていなかったのかもなという発見があった。 実際に本当にそれが反映されるかわからないので、振り返りなど数ヶ月後にやると良いかも。 敢えて伝えたいと思ってない事でも、相手にとっては意味が有る事もある。それを敢えて引き出すには、こういった場は有効 私自身としては新しく参画したグループだったので、タイミングとしては良かったですが、他の皆さんにとっては「なぜ今さら？」感もあったようで、行うタイミングは検討すべきだったかな、と反省もあります。一方で、全く意味が無かったという意見もなかったので新しいリーダーが就任するタイミングなどではさらに効果的なのかな、と感じました！ さいごに 全体を通して時間配分や書き出している間の声掛けなど、ファシリテーションによって結果が大きく左右されると感じました。なかなか書き出しできないときに、「○○と思ったことってないですか？」「○○なんですね！それも新しい発見じゃないですか！」などという声掛けをいただいたり、臨機応変に時間配分を検討したり。わざわざ神保町まで来てくださったずーしみさん、ありがとうございます🙏 最後に、「リーダーズインテグレーションをやるならこちらをぜひ！」と勧められた本をご紹介させてください。ファシリテーションの力は偉大です！🥺✨ https://www.amazon.co.jp/%E3%82%B6%E3%83%BB%E3%83%95%E3%82%A1%E3%82%B7%E3%83%AA%E3%83%86%E3%83%BC%E3%82%BF%E3%83%BC-%E6%A3%AE-%E6%99%82%E5%BD%A6/dp/4478360715 長くなりましたが、懇親会でいただいたおそろしくどでかい羊肉で締めさせていただきます 🍖🤤 ごちそうさまでした🙏

はじめに 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の取り組みに少しでも興味を持っていただけたら嬉しいです。