KINTOテクノロジーズのブログ - TECH PLAY

TECH PLAY

KINTOテクノロジーズ

KINTOテクノロジーズ の技術ブログ

1113

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.
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テクノロジーズの採用スペースにうまく誘導されるだろうと考えています。 これら2つのフェーズにわたるデザイン変更は現在進行中です。見栄えと機能拡充、ユーザビリティ向上をバランスよく達成したいと思っています。 完成後は、 ユーザビリティテスト プロセスを実施し読者からのフィードバックを収集します。今回の変更があらかじめ定めていたゴールを達成できたかを確認していきます。 次のステップ これらのデザイン変更は始まりにすぎず、改善プロセスは今後も続きます。 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つ記述します。 (1)仕様としての正解を確認する テストを設計する際、システム要件を確認した上で不明点を開発側、業務側にお尋ねします。QAはテストを実施する点から、まずは、要件をもとに仕様の正解を確認します。この作業を通して、仕様の細かい部分に関してQAが指摘することで、要件漏れや仕様の整理につながることがあります。 KINTOのWebサイトで「審査申込の流れ」部分の画面見直しがあった場合を例にご説明します。 この場合、テストの期待結果としては「お申し込みに必要なもの」、「審査お申し込みのステップ」のデザインが、画面仕様と一致していることになります。 お申し込みに必要なものとして、通常のWebからの申し込みの場合は運転免許証画像のアップロードが必要です。ただ、KINTOのサービスは販売店様の店頭でも提供しており、店頭の場合ですとその場で運転免許証を確認できるため、画像をアップロードしなくて良い内容になっています(下記の赤枠の運転免許証の部分)。その点を開発側に確認したところ、だしわけの考慮が必要だということに気づいてもらえたということがあります。 細かい点ではありますが、想定される利用ケースや条件を考慮し、テストの期待結果に相当する正解は何か?という点をしっかり確認します。このように、曖昧な表現や漏れている部分に対して具体的にしていくことで、本来あるべき仕様の確認をします。 先述のように、QAでの仕様確認を通じて、開発側が認識していなかった要件を指摘できることがあります。 また、要件定義段階ではないものの開発工程と並行してテスト観点をまとめることで、テストを実施する前に早めに品質を高めることができます。 (2)テスト設計時における資料整理 短期間に開発する際、開発しながらドキュメントを整理することは時間的に難しい場合があります。 各仕様書があっても、一覧化できていなかったり、操作手順がまとまってなかったりというケースもあります。QAでは上記(1)で仕様の正解を確認しつつ、テスト設計でシナリオ、機能確認、表示確認について、下記のように必要な観点の洗い出しを実施します。 その際、元の情報は開発側にあるので、基本的にはその資料を流用しますが、必要に応じてQA側のテストで確認しやすいように、一覧化したり手順をまとめたりします。 QAが作成した資料を参考にすることで全体の機能を俯瞰して見ることができたり、ある手順を確認するのに役立った等、QA以外の社内関係者から嬉しい言葉を頂くことがあります。 情報としてはプロジェクト内に集約されるため、QAでまとめる資料の内容が最新とは限りませんが、あくまで現状の仕様理解を目的として整理します。また、QAでは並行して動いているプロジェクトを横串に見れている点から、仕様を整理している中で開発側に懸念事項などの情報提供をできることもあり、品質面での支援になっていると言えます。 (3)不具合分析によるフィードバック プロジェクトが完了した後、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の中古車案件担当 グローバルには1年ほど前から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年今年の漢字」の発表や、 リアルイベント(オフラインでの本部会開催)などにも、 徐々にチャレンジしていきたいと思います。 弊社の良い風土の1つは、 『新しい取り組みやチャレンジに関して、会社も社員も、寛容なところ」だと思います。 通常の大手企業グループでは実現が難しいことも、比較的クイック&アジャイルに実施可能です。 また、失敗しても、良くも悪くも前例がないので、 (あまり怒られること無く?)ネクストアクションに活かす事ができます。 もちろん成功したら、褒められます(笑) そして、「やりたい!」と声を上げると、力を貸してくれる社員が多い風土です。 イベントなどでお会いした際には、みなさまの会社の取り組みもぜひ教えてください! 弊社も負けないように、チャレンジしていきたいと思います!
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)というサービスで、フロントエンド開発をしている中本です。 この度、アドベントカレンダーに参加することになりましたので、今年リリースした「車検証の2次元コード読み取りの実装」についてお話させて頂こうと思います。 導入の動機 FACTORY では、現在お客様がお乗りのクルマを「アップグレード」や「リフォーム」、「パーソナライズ」といった観点から長くお乗り頂けるサービスを展開しております。 FACTORY のフロントエンドは EC サイトのような役割となっており、お客様のクルマ情報から、取り付けが可能な商品を検索でき、実際にお申し込みまで WEB 上で完結することができます。 そこで重要となってくるのが、車種や年式・グレードといった、現在お客様がお乗りのクルマの情報となってきます。 車種・年式・グレードなどの情報から、どの商品を取り付けることができるか、や商品の組み合わせ可否、などを判断しております。 FACTORY では、それらの情報を正確に判定するために「車台番号」とよばれるものを使用しております。ご存知の方も居られるかもしれませんが、実は車検証を眺めてみると「車台番号」といったシリアル番号のようなものを見つけることができます。(下図の中の左上から3つ目の欄) ※出所:国土交通省「自動車検査証(車検証見本)」( https://wwwtb.mlit.go.jp/hokkaido/content/000176963.pdf) FACTORY では、こちらの「車台番号」を入力することで、そのクルマに取り付け可能な商品を簡単に探すことができます。 商品一覧ページ(車台番号で商品検索済み) ここで、下図の車台番号を入力するフォーム部分を見ていただくと、リリース当初は図のようにユーザーによる手入力フォームとなっていました。 車台番号入力フォーム 車台番号入力による検索機能は、今年の6月にリリースしたのですが、リリース当初よりこちらの入力欄に直接慣れない英数字を入力することは困難ではないか、と思っていました。 特に、昨今の EC サイトの例に漏れず、FACTORY へのアクセスはスマートフォンからがほとんどとなっております。 画面の小さいスマートフォンで、何桁もの英数字を入力頂くのは手間であり、また入力ミスも起こりやすく、入力ミスしてしまうと車両自体が FACTORY の非対応車両となってしまい、適合する商品が見つからないといった機会損失に繋がっているのではと考えました。 そこで目を付けたのが、車検証の右下の方にひっそりと印刷されている2次元コードでした。 車検証の2次元コードから読み取れる情報 国土交通省の 電子車検証 特設サイト にある通り、車検証の2次元コードから上記の検索で使用する「車台番号」を読み取ることが可能でした。 また、FACTORY で取り付けたい商品が見つかり、実際に購入へ進もうとした場合、まずお客様のクルマ情報を登録する必要があります。この登録には、上記の「車台番号」以外に、ナンバープレートの情報も必要となっております。車検証の2次元コードには、基本的に車検証に書かれている情報が入っており、これらを読み取ることで、上記の商品の検索に加えそのまま購入に進んで頂いたときの車両登録も簡単に行えるのでは、と考えました。 実際に車検証を見られた方だとお分かりかと思いますが、下図にあるように2次元コードには、3つ並んでいるものと2つ並んでいるものとがあり、過不足なく読み取ってもらう必要があります。また、それぞれの2次元コード単体のみでは情報が分割されて格納されており、すべてのコードを読み取った後に順番通りに並べて結合する必要があります。 そこで、それぞれのグループのどの位置のコードを読み取っているか、をわかりやすく画面へフィードバックしたいと考えました。 ※出所:国土交通省「2次元コードについて」( https://www.denshishakensho-portal.mlit.go.jp/assets/files/Two-dimensional_code_item_definition.pdf ) 読み取り UI の実装 スマートフォンのカメラを使って読み取ったものを画像処理し、2次元コードをデコードしてくれる Java Script ライブラリにて解析するといった流れとなります。「カメラで読み取る」部分や、「2次元コードのデコード」は初めての試みだったので WEB で情報を集めながらテストしていきました。 カメラの読み取りには、 getUserMedia() の Web API を、2次元コードの解析には qr-scanner という js library を選定しました。 流れでいうと、 getUsetMedia で読み取ったものを canvas 要素へコピーしつつ、 qr-scanner へ転送しコードを解析、データが読み取れたらどの位置のものかを判断する、といったものとなります。 実装のテストをしている段階で、少し難しかったのが、新車検証の場合2次元コードの読み取り率が少し悪いということでした(なかなか読み取れないなど)。 というのも、実は車検証ですが、今年の1月に電子車検証というタイプに変更がされており、最近クルマを購入された方や車検をした方だとお分かりかと思いますが、以前のもの(A4 サイズ)よりかなり小型化(B5 サイズ)されております。 これに伴い、2次元コード自体も少し密度が高くなったような印象があり、なかなか読み取れない状況でした。 そこで、2次元コードをデコードする qr-scanner のソースを眺めながら、Grayscale の設定値を調整していくことで、新・旧どちらのタイプの車検証もある程度の確率で読み取れるようになりました。Canvas へ画像データをコピーした後、上記 Grayscale の設定値を使って、白黒画像へコンバートしそれを2次元コードの解析ライブラリへ送信するといった動きでしたが、値によっては車検証自体の模様などがゴミとして映り込んでしまい、それにより読み込み率の減少を招いていたようでした。 https://github.com/nimiq/qr-scanner/blob/master/src/worker.ts#L73-L79 UI の実装自体は、リアルタイムにカメラで写している画像を見ながら、読み取れた2次元コードの位置をグループ別に示していきたかったので、上部に読み取りの必要な数だけ BOX を並べ、読み取れた2次元コードの枠にチェックアイコンを表示するようにしてみました。 実際の読み取り画面が下図のようになります。 コードの読み取る順番は関係なく、読み取ったコードの位置が正しく認識されていることが分かるかと思います。すべての情報を読み取ると、手入力にて車台番号検索した時のように画面が遷移します。 リリースしてみて こちらの2次元コードによる検索機能は 10 月にリリースすることができました。このリリースからしばらくは、上記説明の中での画面例のように、商品一覧ページのみへの適応だったので、劇的にこちらの機能が利用されたとは言いづらいですが、現在はトップ画面へも適応されております。トップページから、2次元コードを読み取ることで、対応車両のチェックや商品適合のチェックまで一度で行えることができるようになっており、利用率向上を見込んでおります。 また、「読み取れる情報」の部分でも少し触れましたが、2次元コードには車両登録に必要な情報も含まれているので、今後は車両登録時にもこちらの情報を使っていき、できるだけ手入力部分を減らすことで利便性や入力ミスの削減を狙っていきたいと思います。 最後に スマートフォンの台頭や、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月までの記憶がない」と苦笑いしております。 人事採用グループは第2フェーズへ 2023年12月、KINTOテクノロジーズの社員数は320人になりました。組織の拡大に伴い、部署の階層も増え、役割も増えてきました。現場主導でどういう人に入社していただきたいかを考え、人事採用グループにリクエストが来るようになり、私たちはマネージャーや社員と、より近い距離でヒアリングを行っています。また、新たに面接に関わる方には面接官トレーニングを実施しており、採用に関わる社員も常に増加しています。 岩本一人で始まった採用活動は、今や部門を横断した活動になりました。 現在、人事採用グループは10人が所属しており、採用チーム、労務総務チーム、組織人事チームの3チーム体制になりました。社員の皆様がよりチャレンジし、成長できる会社でいられるよう、人事採用グループ一丸となって2024年も邁進していく所存です。 さて… 年末に人生を振り返ったり、ライフプランを見直したり、転職を検討される方が多いかと存じます。KINTOテクノロジーズでは、様々な職種で新しい仲間を募集していますので、興味のある募集がありましたら、ぜひお気軽にご応募ください。カジュアル面談も承っています。 KINTOテクノロジーズの募集職種は こちら 以上で、「人事採用グループをつくろう」を終わります。 アドベントカレンダーなので、最後はこの言葉で。 メリークリスマス!!