はじめに こんにちは。プラットフォームGのPlatformEngneeringチームでPlatformEngineeringの考え方をベースにツール周りの開発・運用・展開の役割(とチームリーダーのようなことをしている) 島村 です。 この記事は、 KINTOテクノロジーズのAdventCalendar2023 の技術側1日目の記事です。 CICDツールとして、GitHubに付属しているGitHub Actions。 特にPushと手動(WorkFlow_dispatch)をよく使うと思いますが、これが有効になったり動いたりするのはどういう時なのか、たまに混乱しませんか？ 私はします。メンバーとどうだっけ？と話をしたこともよくあります。 なので整理しようというのが本記事です。 背景 PushしたときとかMergeしたときとか手動とか、起動するEventsのうち、 on.push on.workflow_dispatch の際の挙動を整理してまとめたいと思います。 テスト準備 ケース on.push default(main)ブランチにMergeしなくても動くか default(main)ブランチにMergeしたあと、Pushのブランチを変更するとどうか Pushの際に他のブランチに影響がないか on.workflow_dispatch deafult(main)ブランチにMergeしなくても動くか Merge後に別ブランチを作成して修正、Pushしたら反映されるか 基本コード(echo.yaml) name: "TestWorkFlow" on: push: branches: - main - 'test/**' workflow_dispatch: jobs: TestWorkflow: name: "TestWorkFLow Echo" runs-on: ubuntu-latest steps: - name: Echo Branch run: | echo "Branch：${{ GITHUB_REF_NAME }}" 結果まとめ 一枚っぺらのイラストにまとめたのがこちら。 詳細 on.push Mergeしなくても、以下の条件にマッチするならPushしたタイミングで動く 構文などのミスがないこと(ただ、構文ミスがあったとしてもFailで表示される) pushしたブランチとworkflowのon.pushのブランチの条件が合致している on.push.branchesをtest/**のままで"feature/trigger-test"でブランチを切ってpushしても動かない on.push.branchesを"feature/xx"に変更してpushしたら、feature/trigger-testのWorkflowが動く 以下の２つのブランチがある場合の挙動 on.push.branchesを"feature/xx"としているtest/trigger-test on.push.branchesを"test/xx"としているfeature/another-trigger 何か修正してtrigger-testでPushしても、feature/another-triggerのWorkFlowは動かない 何か修正してfeature/another-triggerでPushしても、trigger-testのWorkFlowは動かない on系パラメータはその発生したブランチにあるファイルの内容を見て起動するかを判断している on.workflow_dispatch defaultブランチにファイルが存在しないと、手動で動かすボタンは表示されない Mergeした後に新しくブランチを作成してInputsを追加した 手動起動の場合、ブランチを選択できるので、新しいブランチを選ぶとInputsが増える pushと同じで、ブランチにあるファイルの内容を反映している 検証 on.push default(main)ブランチにMergeしなくても動くか まずは、echo.ymlを作成してPushする。 junpei@:test-trigger-repo$ git add .github/ junpei@:test-trigger-repo$ git commit -m "create workflow" [test/trigger-test 43be511] create workflow 1 file changed, 17 insertions(+) create mode 100644 .github/workflows/echo.yml junpei@:test-trigger-repo$ git push origin test/trigger-test ・・・・・・ Total 5 (delta 0), reused 0 (delta 0), pack-reused 0 remote: remote: Create a pull request for 'test/trigger-test' on GitHub by visiting: remote: https://github.com/junpeishimamura-kinto/test-trigger-repo/pull/new/test/trigger-test remote: To https://github.com/junpeishimamura-kinto/test-trigger-repo.git * [new branch] test/trigger-test -> test/trigger-test junpei@:test-trigger-repo$ 想定だと動かないかなと思っていたが、Actionが走る。 Mergeした後にPushのブランチを変更するとどうか トリガー条件を「test/**」としたmainブランチから「feature/trigger-test」を作成しても動かない＝当然。 ワークフローのファイルを on: push: branches: - main - 'feature/**' workflow_dispatch: と「feature/trigger-test」で修正してPushしたら、もちろん動く。 他のブランチへの影響はないか mainブランチから、「test/trigger-test-other-branch」を作成して、適当なファイルを作成する junpei@:test-trigger-repo$ git status On branch test/trigger-test-other-branch Untracked files: (use "git add <file>..." to include in what will be committed) test-branch.txt nothing added to commit but untracked files present (use "git add" to track) junpei@:test-trigger-repo$ git add test-branch.txt junpei@:test-trigger-repo$ git commit -m "create test-branch.txt" git p[test/trigger-test-other-branch 0c738b1] create test-branch.txt 1 file changed, 1 insertion(+) create mode 100644 test-branch.txt junpei@:test-trigger-repo$ git push origin test/trigger-test-other-branch ・・・・ Total 3 (delta 0), reused 0 (delta 0), pack-reused 0 remote: remote: Create a pull request for 'test/trigger-test-other-branch' on GitHub by visiting: remote: https://github.com/junpeishimamura-kinto/test-trigger-repo/pull/new/test/trigger-test-other-branch remote: To https://github.com/junpeishimamura-kinto/test-trigger-repo.git * [new branch] test/trigger-test-other-branch -> test/trigger-test-other-branch junpei@:test-trigger-repo$ でPushしたら、もちろん動く。この場合のワークフローファイルは、「test/trigger-test-other-branch」のものでMainではない。 追加で、mainブランチから「feature/another-trigger」を切る。この時、前に検証していた「feature/trigger-test」ブランチは残している。 junpei@:test-trigger-repo$ git switch -c feature/another-trigger Switched to a new branch 'feature/another-trigger' junpei@:test-trigger-repo$ git branch * feature/another-trigger feature/trigger-test main test/trigger-test test/trigger-test-other-branch junpei@:test-trigger-repo$ で、ファイルとかを作って、「feature/another-trigger」のワークフローの条件は変更せず(test/**)でPushする。 Actionsは走らない。操作ブランチにあるワークフローの条件に合致するかどうか？が基準となっている模様。 on.workflow_dispatch deafult(main)ブランチにMergeしなくても動くか on.pushで作成したecho.ymlをMainブランチにマージしなくても手動できどうできるか？ workflow_dispatchがYamlにあったとしても、Mainブランチにマージしないとボタンが表示されず動かせない。 ボタンがないので、指定するブランチを切り替えるとういうこともできなさそう。 Merge後に別ブランチを作成して修正、Pushしたら反映されるか よく使うので、検証しませんでした。が、反映されます。 RunWorkflowのボタンを押すと、ブランチ指定ができるので、選ぶと、変更点などが反映されたものが動かせます。 所感 on.pushにおける、「defaultブランチにMergeしなくても動くか」以外は想定通りでした。PushしただけではGitHub Actionsとして登録されない＝Mergeして初めて登録されると認識していたので、整理して認識が違っていたのを把握できて良かったです。今回はBranch条件としましたが、Tagもイベント駆動の種別が同じなので、同様の挙動をすると思います。 本当はCircle.CIとか他のCICDサービスとの比較もしたいと思っていたのですが、多分、同じ形で動くのかなと思っています。GitHub Actionsと違い、SaaS系CICDツールはイベント駆動でソースコードを引っ張ってくるので、イベントが発生したブランチにあるものを判断するんじゃないかな？と。 さいごに PlatformEngneeringチームは、社内向けの横断ツールを統制して必要なものを開発しています。 Platformグループの他チームが作ったものを受け入れたり、必要なものを新規作成や既存のものをマイグレーションしたりしています。CDKにも手を出そうとしてるので、ManagedService以外にもプログラミングも行い始めました。 こういった活動に少しでも興味を持ったり話を聞いてみたいと思った方は、お気軽にご連絡いただければと思います。 @ card

はじめに こんにちは、KINTOテクノロジーズの開発編成本部に所属するカンです。2022年1月に入社し、これまでサイト再構築というプロジェクトを進めてきました。 KINTOをご利用いただくお客様が増えるにつれ、様々なサービスを拡充しようとしており、既存サイトでは迅速な機能追加を行う上で様々な問題点を有していたため、これらの問題の解決と改善のためのサイト再構築プロジェクトが今年 8月にリリースされました。 本稿では、私が所属しているサイト再構築のフロントチームについて紹介したいと思います。 サイト再構築FEチームの目標 新規開発をスピーディーに提供出来る環境の実現を目指す 複雑な環境構築から、シンプルな環境構築の実現を目指す 複雑に絡み合っているcssソース、jsソースを定義し直す 会員管理機能を会員情報プラットフォームへ移譲する クリエイティブグループと連携し、デザインから実装に落とし込む（UI/UXの改善提案も含む） 再構築FEチームは、上記の項目を達成するためにプロジェクトを進めました。 開発段階で改善できる部分について毎スプリントの会議で話し合い、効率的なプロジェクトを構築するために他のチームと連携して改善していきました。 コードの再利用性を高め、メンテナンスに容易な直感的なコードを作成しました。 TypeScriptを使用することで予期せぬエラーが発生することを防止し手軽なデバッグで作業生産性を高めました。 どのような技術スペックをプロジェクトに取り入れたのか プロジェクトを進めながら悩んだもの 既存プロジェクトの仕様を再構築するだけでなく、既存の機能改善や新機能追加、コードリファクタリングも同時に進めていたため、各メンバー間で進行中の業務に対して把握が難しい 連携するチーム(BEチーム、デザインチーム、インフラチーム、QAチームなど)と仕様および開発について効率的なコミュニケーションをとるための方法 良い開発環境を構築していくためにはどんな方法があるか メンテナンス性が高く再利用性の高いコードを作成するためには プロジェクトの仕様と技術に対する各メンバー間の理解の差を解決し、コードの統一性を高めるための方法 解決するために FE チームは 開発を進めるにあたって、レビューは重要性が高いと認識していたためレビューに関するルールを作成しました。また、毎日レビュー時間を作ってレビューを進行するように努力しました。 特定のレビューに対して担当者を指定せず、自由にいろんなPull Requestに対してレビューする方法で進めました。その結果、他のメンバーが進んでいるタスクの仕様やコンポーネントなどの実装について確認しながらお互いの業務内容を把握しやすくなりました。 連携するチームとConfluenceへ変更仕様のページを作ってコミュニケーションし、また業務のツールを利用して効率的なコミュニケーションをとることができました。 BEチームが提供するswaggerとAPIの変更仕様についてまとめたConfluenceのページを通じてAPIの仕様を素早く理解することができ、変更点も明確に確認して対応することができました。 クリエイティブチームとはAdobe XD、Figmaなどのデザインツールを通じて協業しました。 導入するUI/UXに関してよりわかりやすく理解することができ、ユーザーが理解しやすくて操作しやすい直感的なコンポーネントを作成することができました。 コミュニケーションも自由に取りながら協業し不明点や変更点があれば、その場ですぐにハドルmtgを開催して解決していきました。この結果、開発過程で発生しうるバグを減らすことができました。 より良い開発環境を作るためにチーム内の業務に関する様々なガイドラインを作成しました。 Outlook、Slack、Confluenceなどでコミュニケーションを取り、デイリー会議を通じて互いに現在進行中の業務に対する状況を理解することができました。タスクを進行しながら悩むところについてはお互い相談し、チーム内で一緒に問題を解決していきました。プランニングの会議で各メンバーの進行状況を確認しながら次回のスプリントの作業分担を行い、過度な業務負荷がないようにしました。 また、スプリントごとに振り返り会議を進め、該当スプリントの惜しかったところや良かったところと、改善していきたいところについてお互いに相談しながらもっと良い開発環境を構築していきました。 Atomic Designパターンを導入し、持続的なリペクトリングを通じてコード再利用性を高めました。 Atom/Molecules/Organismsの区分に対してConfluenceのワークスペースに定義をまとめ、会議を通じてメンバー間の認識を合わせていきました。 新しい機能やUIの開発を進めながら、独立的でピュアなコンポーネントを作成していきました。 また、コンポーネントの品質を保証するためStorybookとReactのJestライブラリを導入してテストを行いました。 その結果、より高い再利用性を持つコンポーネントを作成することができました。 Confluenceの再構築ワークスペースに既存プロジェクトおよび新たに追加される機能について仕様をまとめて共有しました。 また、FE開発環境に関する参考資料を作成し、新規参加者がより迅速に開発環境に適応できるようにしました。レビューの流れやブランチ運用方法、コードの作成方法などのコード管理に関するルールを設定し、統一性のあるコードを作成しました。 各メンバーごとに順番を決め、現在使用中の技術について輪読会をを開催して知識を共有しました。 まとめ 今回のサイト再構築プロジェクトを通じて良いプロジェクトを進めるために重要なものは何なのか改めて振り返ることができました。 個々人のプログラミングパフォーマンスも重要な要素だと思いますが、一つのチームとして絶えず疎通していくのが重要だと思いました。 チーム内でより良い開発環境を作るためにお互い努力し、柔軟な考え方で失敗を恐れずに様々なトライをすることが重要ではないかと感じました。。 何でも試したいことがあれば、自由に発言して試してみる明るい雰囲気の再構築チーム環境で開発を進めることができたので、個人的にもチーム的にも多くの成長ができたと思います。 長期間のプロジェクトを進めながら一緒に苦労した再構築チームと連携したすべてのチームの努力のおかげで、プロジェクトが今年 8月に無事リリースすることができました。 最後まで読んでくださってありがとうございます。

Introduction Hello. Ryo here, an ID Platform developer in the Global Development Group. KINTO services have already been rolled out in several countries, and we're planning to spread them to even further afield. Our mission in the ID Platform Development Team is to create an ID system that enables customers all over the world to use all of KINTO's services smoothly with a single ID, from any country. Today, I'd like to tell you about our FIDO proof of concept (PoC). Identity provider/ ID provider, or IDP An identity provider / ID provider (IdP or IDP for short) is a system entity that creates, maintains, and manages principal identity information, and provides authentication services for dependent applications in a federated or distributed network. A concept like the "identity provider / ID provider" above (IDP from here on) might be difficult to understand if you've never heard of it before, but to put it simply, it's a system that manages, authenticates, and authorizes users. Overview of FIDO Maybe you know what FIDO (Fast IDentity Online) is already, but in case you don't, it's a new authentication standard that — unlike the ordinary ID and password authentication methods— is all about doing password-free ID authentication for online services. It uses a key pair consisting of a private key and a public key, which is a more secure approach than the ordinary one based on sharing a common key. FIDO authentication procedure The procedure for registering is as follows: Login procedure for registered users Comparison with the ordinary way The ordinary way: ID and password pairs are set when users create accounts The IDs and encrypted passwords are recorded in a server-side database The server gets sent IDs and passwords, and is asked to decide if they're correct Pros of FIDO authentication FIDO authentication is a new password-free, secure authentication method that enables authentication to be done via public key cryptography instead of using passwords. It has the following advantages for users: The servers only store public keys, so they don't store users' private information. The public keys are encrypted, which makes it much safer than using common keys. The users can log in without having to remember a password. Fingerprint and face authentication are more convenient than manually entering passwords. What we have achieved Broadly speaking, we had the following 2 goals for our FIDO PoC: Achieving the necessary tuning and support in the current ID system Coming up with a plan that will enable us to easily adopt FIDO for both internal and external ID systems if desired. In line with these goals, we successfully achieved the following 4 things: Analyzing ECC and RSA public keys (Goal 1) Taking the public keys created using biometric authentication and storing them in the RDS (Goal 1) Being able to correctly authenticate users when needed (Goal 1) Being able to support both web- and API-based paradigms (Goal 2) Neat approaches we devised Covering both web- and API-based paradigms in the basic design stage Rather than simply creating an IDP, we also want to deploy it globally as KINTO's IDP, and get it used for other services as well. For KINTO's services, we're going for easy adoption of FIDO functionality with an API-based paradigm, and we're envisaging being able to adopt it for other companies' ones as well, using a web-based, one-click paradigm. If we can figure out neat ways to support both of these, it'll become more convenient. Changing the programming language The sample code we got from the official website is written in JavaScript for both the frontend and the backend. We're deploying services with Spring Boot, so if we want to add it to the IDP as a new feature, we'll need to change it from JavaScript to Java. If there's no Java library with the same functionality as the external JavaScript-based one, we'll need to do some coding in order to make the change. Issues we encountered during the PoC When authenticating a user, a bug sometimes arose where the public key didn't match the one stored in the RDS. On trying to debug it, we found that the public key IDs stored in RDS were encoded as base64, but the Java and JavaScript base64 encoding functions were giving different results. We'd run it in JavaScript with auto-padding off, but when we moved the backend logic to Java, the auto-padding setting didn't get picked up, and the Java auto-padding got used anyway. Turning off auto-padding fixed the bug. + Base64.getUrlEncoder().encodeToString(ID string) - For patterns using auto-padding, the part of the encoding result that's less than a multiple of 4 gets automatically padded with equals signs ("=") + Base64.getUrlEncoder().withoutPadding().encodeToString(ID string) - With auto-padding off, the encoding result gets left as is.　　　 Problems FIDO has made it easier and more convenient for users to use online services securely, but there are still a few things that need to be taken care of. Public key management issue: Multiple public keys can be added on the same device ** The server can't tell whether the same device is being used, so you can register a public key the same device as many times as you like. This means garbage data gets stored in the RDS. ** Reregistering public keys by switching devices, etc. ** If you lose your device, get a new one, etc., you need to do the FIDO registration again. When you reregister, you need to verify your identity another way. This is less convenient than with ID-and-password authentication. ** Managing unwanted public keys ** The above will result in unwanted public keys. Users can't manage their public key IDs, so the backend can't tell whether public keys are valid when they become unwanted. Public keys still have to be stored on the RDS for a long time even if they become invalid. ** Summary We wanted to give users a better password-free experience with authentication, so we decided to do a PoC for FIDO. As a result, we feel that it's a powerful solution but there are still issues with things like public key management. So, we want to continue to develop things having soundly verified that they're suitable. References What is FIDO Authentication? What is OpenID Connect?

Introduction Hello. Ryo here, an ID Platform developer in the Global Development Group. KINTO services have already been rolled out in several countries, and we're planning to spread them to even further afield. Our mission in the ID Platform Development Team is to create an ID system that enables customers all over the world to use all of KINTO's services smoothly with a single ID, from any country. Today, I'd like to tell you about our FIDO proof of concept (PoC). Identity provider/ ID provider, or IDP An identity provider / ID provider (IdP or IDP for short) is a system entity that creates, maintains, and manages principal identity information, and provides authentication services for dependent applications in a federated or distributed network. A concept like the "identity provider / ID provider" above (IDP from here on) might be difficult to understand if you've never heard of it before, but to put it simply, it's a system that manages, authenticates, and authorizes users. Overview of FIDO Maybe you know what FIDO (Fast IDentity Online) is already, but in case you don't, it's a new authentication standard that — unlike the ordinary ID and password authentication methods— is all about doing password-free ID authentication for online services. It uses a key pair consisting of a private key and a public key, which is a more secure approach than the ordinary one based on sharing a common key. FIDO authentication procedure The procedure for registering is as follows: Login procedure for registered users Comparison with the ordinary way The ordinary way: ID and password pairs are set when users create accounts The IDs and encrypted passwords are recorded in a server-side database The server gets sent IDs and passwords, and is asked to decide if they're correct Pros of FIDO authentication FIDO authentication is a new password-free, secure authentication method that enables authentication to be done via public key cryptography instead of using passwords. It has the following advantages for users: The servers only store public keys, so they don't store users' private information. The public keys are encrypted, which makes it much safer than using common keys. The users can log in without having to remember a password. Fingerprint and face authentication are more convenient than manually entering passwords. What we have achieved Broadly speaking, we had the following 2 goals for our FIDO PoC: Achieving the necessary tuning and support in the current ID system Coming up with a plan that will enable us to easily adopt FIDO for both internal and external ID systems if desired. In line with these goals, we successfully achieved the following 4 things: Analyzing ECC and RSA public keys (Goal 1) Taking the public keys created using biometric authentication and storing them in the RDS (Goal 1) Being able to correctly authenticate users when needed (Goal 1) Being able to support both web- and API-based paradigms (Goal 2) Neat approaches we devised Covering both web- and API-based paradigms in the basic design stage Rather than simply creating an IDP, we also want to deploy it globally as KINTO's IDP, and get it used for other services as well. For KINTO's services, we're going for easy adoption of FIDO functionality with an API-based paradigm, and we're envisaging being able to adopt it for other companies' ones as well, using a web-based, one-click paradigm. If we can figure out neat ways to support both of these, it'll become more convenient. Changing the programming language The sample code we got from the official website is written in JavaScript for both the frontend and the backend. We're deploying services with Spring Boot, so if we want to add it to the IDP as a new feature, we'll need to change it from JavaScript to Java. If there's no Java library with the same functionality as the external JavaScript-based one, we'll need to do some coding in order to make the change. Issues we encountered during the PoC When authenticating a user, a bug sometimes arose where the public key didn't match the one stored in the RDS. On trying to debug it, we found that the public key IDs stored in RDS were encoded as base64, but the Java and JavaScript base64 encoding functions were giving different results. We'd run it in JavaScript with auto-padding off, but when we moved the backend logic to Java, the auto-padding setting didn't get picked up, and the Java auto-padding got used anyway. Turning off auto-padding fixed the bug. + Base64.getUrlEncoder().encodeToString(ID string) - For patterns using auto-padding, the part of the encoding result that's less than a multiple of 4 gets automatically padded with equals signs ("=") + Base64.getUrlEncoder().withoutPadding().encodeToString(ID string) - With auto-padding off, the encoding result gets left as is.　　　 Problems FIDO has made it easier and more convenient for users to use online services securely, but there are still a few things that need to be taken care of. Public key management issue: Multiple public keys can be added on the same device The server can't tell whether the same device is being used, so you can register a public key the same device as many times as you like. This means garbage data gets stored in the RDS. Reregistering public keys by switching devices, etc. If you lose your device, get a new one, etc., you need to do the FIDO registration again. When you reregister, you need to verify your identity another way. This is less convenient than with ID-and-password authentication. Managing unwanted public keys The above will result in unwanted public keys. Users can't manage their public key IDs, so the backend can't tell whether public keys are valid when they become unwanted. Public keys still have to be stored on the RDS for a long time even if they become invalid. Summary We wanted to give users a better password-free experience with authentication, so we decided to do a PoC for FIDO. As a result, we feel that it's a powerful solution but there are still issues with things like public key management. So, we want to continue to develop things having soundly verified that they're suitable. References What is FIDO Authentication? What is OpenID Connect?

自己紹介 KINTOテクノロジーズでモビリティマーケットの開発・運用を担当しているリナです。 普段はフロントエンジニアとして、主にNext.jsを用いて実装しています。 最近のマイブームは、Minecraftです🎮今更始めました。 さて、KINTOテクノロジーズは今年もアドベントカレンダーを実施します🎄 今回の記事では、昨年よりアップグレードしたKINTOテクノロジーズ Advent Calendar2023を先んじてご紹介します！！ これまでのAdvent Calendar KINTOテクノロジーズは2021年よりアドベントカレンダーを実施しており、今年で3回目です🎄 2021年のアドベントカレンダーは、まだKINTOテクノロジーズのテックブログがなく、有志のメンバーが集まってQiita Advent Calendarを執筆していました。 https://qiita.com/advent-calendar/2021/kinto-technologies 次に2022年は、7月にKINTOテクノロジーズのテックブログをローンチし、正式にアドベントカレンダーをスタートできた年です👏 記事の内容は「個人が習得した技術の発信」と「各部署（グループ）紹介」2つのテーマで、KINTOテクノロジーズの社員が持つ技術や社員の働き方を中心に発信しました。 https://blog.kinto-technologies.com/posts/2022-12-01-advent_calendar/ （参考： Advent Calendarとは ） Advent Calendar 2023 そして今年のアドベントカレンダーは、例年と同様にシリーズを2本立て公開します！ 前年は2つのアドベントカレンダーを作成していましたが、今年は1つのカレンダーで2シリーズ・計50記事を公開予定です。 https://qiita.com/advent-calendar/2023/kinto-technologies-tech そしてなんと･･･ プレゼント企画 も実施します🎅✨ みなさま、ご友人や同僚をお誘いあわせの上ご参加くださいませ！ https://qiita.com/advent-calendar/2023/kinto-technlogies それでは、2023年の記事のテーマをご紹介いたします！ 1. 技術記事 KINTOテクノロジーズの社員個々人が習得したスキル・技術を発信します。 インフラ・バックエンド・モバイル・組織開発など、多岐にわたる分野の技術記事を公開予定です。 記事を通して、KINTOテクノロジーズで働く社員が日々どのように課題解決やスキル習得に励んでいるか、業務に取り組む姿勢を知ることができます！ 2. 記事リレー 今年は、5つのテーマで記事リレーをします！ テーマは、今年ローンチした大規模プロジェクトや社内の勉強会で話題のトピックなどを選定しました。 ①新車のサブスク サイトリニューアル 2023年8月に新車のサブスクサイト(KINTO ONE)の完全リニューアルをローンチしました🎉 開発期間約2年半の大規模プロジェクトです。 サイトリニューアルによって新機能の追加や改修がしやすく、よりモダンなサイトを構築できました。 今回はプロジェクトに携わったメンバーが、よりよいサイトを構築するために行った改善や技術スタックを記事にまとめます！ ②アジャイル開発 弊社では、ソフトウェア開発手法であるアジャイル開発を複数のプロジェクトおよびプロダクト開発で取り入れています。 以前からアジャイル開発の勉強会は行われていましたが、部署単位などクローズドな環境での情報共有が主だったため、今年から「 組織横断 でアジャイルな活動を推進すること」に力を入れています。 #help-agile-scrum というアジャイル開発の情報交換ができるSlackチャンネルを作成したり、他チームのスプリント見学会を実施するなど、組織横断で気軽に情報交換ができる状態を目指しています。 今回は、各プロダクトで取り組んでいるアジャイルの事例や工夫をご紹介します！ ③KINTO FACTORY KINTO FACTORY とは、すでに購入されたトヨタ・レクサス車に、その後の技術革新や経年劣化に合わせてソフトウェア・ハードウェアの機能やアイテムをタイムリーに反映することで、お乗りのクルマを最新の状態に「進化」させるサービスです。 KINTO FACTORYではマスタデータをトヨタやトヨタの販売店各社から取得し、トヨタの関連各社と適切なデータ構造を一緒に考えながら実装を進めているのが特徴です。 ECサイト受付～部品発注～納品まで、バックオフィスの運用全体を一部を垣間見ることができる記事も予定されています。 他にも先日リリースされた車検証の分割QRコード読み取り機能など、ユーザー様にとって使いやすいサイトを目指して日々「進化」に取り組んでいる様子もフロントエンドの技術を中心に公開予定。 他にも運用体制の構築や新機能追加など、いくつかの記事を執筆します！ ④QA KINTOテクノロジーズが提供する各種サービスのリリース前検証を担うグループの記事連載です。 トヨタグループに属するKINTOテクノロジーズでは、ソフトウェア開発においても高い品質管理基準が要求されます。 また、KINTO ONEやKINTO FACTORYなどの各プロダクト間ではデータ連携が行われており、複数プロダクトにまたがった検証も品質管理で重要なポイントとなっています。 各プロダクトの開発メンバーは、自身が担当するプロダクトの範囲内でテストを実行しています。 しかし、QAグループではプロダクト単体の検証だけでなく、プロダクト間の検証も担い、プロダクト（プロジェクト）全体のコミュニケーションのハブとして情報収集・連携も行う重要なグループです。 そんなKINTOテクノロジーズには欠かせないQAグループが、提供するプロダクトの検証を進める上での開発チームとのコミュニケーションや品質管理の重要性について執筆いたします！ （参考： QAグループ紹介 ） ⑤Diversity & Inclusion 弊社はさまざまな国籍の多様なバックグラウンドを持つメンバーが多く、約25%のメンバーが外国籍です(2023年11月時点)　また、幼い子どもを抱えながら働くワーキングマザー・ファザーが多く在籍しており、それに伴い男性の育児休暇取得者も増加しています。 今回は、それぞれのライフステージ・ライフスタイルに合わせてどのような働き方をしているのか、また多国籍チームでどのようなマネジメントを行っているのかなど、外国籍メンバーのキャリアや働き方に焦点をあて、リーダシップ・育児休暇・多国籍チームのコミュニケーションのテーマで執筆します！ （参考： 外国籍社員の活躍 ） https://qiita.com/advent-calendar/2023/kinto-technologies-tech プレゼントカレンダー そして、今年はQiita Advent Calendarのプレゼント企画に参加します！ 記事を投稿いただいた方の中から、3名様にプレゼントをお渡しする予定です✨ テーマは「 CCoEクリスマス！クラウド技術を活用して組織をカイゼンした事例を投稿しよう！ 」です。 様々な活動の中で、今回は「CCoE活動」にフォーカス！ 私たちは、AWS Summit Tokyo 2023・AWS Autotech Forum 2023をはじめとする外部イベントへの登壇や、DBRE Summit 2023の開催など、トヨタグループ横断でのCCoE活動をリードしています。 そこで、今回はエンジニアのみなさまから、クラウドに関わる「カイゼン」事例を広く募集します！ クルマ好きの人もそうでない人も、日々の業務の中での小さな「カイゼン」を教えてください。 プレゼント内容🎁 KINTO Unlimited賞（1名） Apple AirPods Max - スペースグレイ KINTO ONE賞（1名） Anker PowerExpand Elite 12-in-1 Thunderbolt 4 Dock (APEX) ドッキングステーション KINTO FACTORY賞（1名） BenQ ScreenBar Halo モニターライト スクリーンバー ハロー USBライト デスクライト https://qiita.com/advent-calendar/2023/kinto-technlogies さいごに 今回は、2023年のアドベントカレンダーの概要をご紹介しました🎄 KINTOテクノロジーズのアドベントカレンダーが、みなさまの新たな気づきに繋がれば幸いです。 また、アドベントカレンダーおよび登壇情報などの最新情報は X で配信します！ ぜひ、フォローお願いいたします。 https://twitter.com/KintoTech_Dev それでは、2023年のアドベントカレンダーもご期待ください✨

Introduction Hi. I'm Nishiguchi, the manager of the KINTO Technologies Analysis Group. Some of you might think it's strange that a tech company has an analysis group. So, that's what I'd like to talk about today. The Analysis Group's role KINTO Technologies' business includes the following: information processing services such as designing, developing, and operating sales and information systems in the digital field; and work related to creating and proposing plans for and providing consulting services for corporate management and marketing strategies. The Analysis Group handles the latter half of this, and of course, KINTO's business in Japan makes use of data from, cooperates with, and participates in the various services run by Toyota Financial Services Corporation group companies, and aims to use data in order to give business value. Giving data value (The scope of the Analysis Group) Are you familiar with the DIKW pyramid? This concept, which stands for data , information , knowledge , and wisdom, revolves around the idea of harnessing and processing vast amounts of information. At our core, we're committed to figuring out how to create value in business while transforming huge volumes of information into new systems. In order to make the DIKW pyramid a reality, we broadly divide our work into 4 areas. 1. Designing and carrying out data acquisition Business data typically consists of the following: transaction data generated from actions such as user order flows; and master data from things like product management. We also view both transaction and master data as having to be generated by something. It's been getting increasingly difficult to acquire data in recent years, notably due to calls to protect personal information. There are data that can only be acquired at certain times (user registration data, for example), and if you fail to get them at those times, you won't be able to later on. We of course set up the right analysis tags on websites, and also work on planning systems to generate data via user actions. 2. Data storage We need to be able to store the resulting data in a data lake or data warehouse quickly and accurately before moving on to the next step (analyzing it). The goal here is to make the analysts' job easier. We'd like to lower the workload that data acquisition and processing impose on analysts, so they can focus on the analysis work more. Not being able to find the data they're looking for easily can get interfere with their train of thought. It's important to create a system that, for example, will make it easy for team A to join forces with team B when they want to. I often tell our team members to put themselves in the receivers' shoes before they pass something on to them. 3. Data analysis Analyzing the data consists of splitting them up based on certain perspectives, and comparing them with other kinds. I think the idea is to find differences by doing so. I also see it as a policy of ours to promote widening or narrowing those differences. It's our job to find those differences from right perspectives, inform business team members about them, and also suggest appropriate actions to take. I tell our members that there are 2 skills they need. The first is to have various perspectives. Specifically, we get them to develop the ability to see things as insects, birds, fish, and bats do respectively. The other is performing "why-why analysis." In order to grasp the essence of things, we have to repeatedly ask why, and in so doing, find the root causes among the correct causal relationships. 4. AI and machine learning AI and machine learning are both a part of advanced data analysis. This is the domain of predicting the future using past data. In this field, we work with the Toyota Motor Mirai Creation Fund to create models using advanced algorithms while also gathering academic information. We're also constantly reviewing models for AI and machine learning in business fields. It's also essential that an MLOps environment be created that will make it easier to modify and implement these models, so we're also working on this together with the Platform Group Giving value to data (Roles and Responsibilities) To reiterate, acquiring data at the right time is critical to giving data value, especially in BtoC business. This is because some kinds of data can only be acquired at certain times. The next-most important point is to store the data so it's easy for people performing the next processes to use. To accomplish this, the Analysis Group has the following team member positions: 1. Data analysts Data analysts at KINTO Technologies are more than just analysts. This is because they're involved right from the data acquisition design stage, where the aim is to acquire data in the right places, at the right times, and in the right forms via websites and apps. They're also responsible for setting up the tags. We believe data analysts should think in advance about what kinds of data the analysis is likely to require, then acquire it without missing any out. The resulting data is then stored in a data lake or data warehouse. From there, the data can be freely extracted using BI tools and SQL, and predictors found, countermeasures proposed, and so on by finding the root causes for things while drilling down from the right perspectives. 2. Data engineers We also need highly skilled data engineers. We don't just store data from the backend database in a data warehouse as is, but also create data in ways that also aim to make things easier for members involved in data analysis. (I think this a unique approach only operating companies take.) KINTO is steadily launching new services, and our data engineers are also responsible for creating the development guidelines, common functions, CI/CD systems, and so on needed to develop things efficiently so that data analysis can start right from when the services are launched. 3. BI engineers It's crucial to turn data into information and quickly inform business members about the business situation. Also, managers and staff have different preferences when it comes to the level of detail they prefer in the information they access. A BI engineer's job is to develop, modify, and maintain dashboards for conveying it in the appropriate forms. 4. Data scientists A variety of services are going to be rolled out by KINTO, likely including more and more related to AI and machine learning. A wide range of support is going to be required for things like images as well as numerical data. No matter how accurate a model you construct, there's no guarantee that it'll actually get used in business. First, you need to convince the marketers, etc. that it's worth it. To that end, KINTO Technologies' data scientists need to be able to explain things using conventional statistical methods, etc., understand the businesses, and be interested in consumers. In other words, data scientists in KINTO's business play the role of marketing data scientists. 5. Analysis producers This is a new position that was created in September 2022. The analysis producers' job is to cross-functionally coordinate the roles of each of the positions 1 to 4 above. They require the business abilities needed to get people to tell them what business issues they're facing, then replace those issues with appropriate analytical problems. Of course, they also need to be highly experienced and knowledgeable about the data involved in 1 to 4. They'll also play an extremely important role in enabling the KINTO Technologies Analysis Group to make its presence felt even more in the future. Team dynamics and workflow approaches in the Analysis Group 1. Team members and atmosphere In the Analysis Group, we confront very difficult challenges daily, with each of our members bringing a unique set of experiences to the table. However, what we all have in common is our high level of motivation and curiosity toward further broadening our understanding of data-related domains, while staying true to each core roles as data analysts, data engineers, data scientists, etc. Whenever a new team member joins, we always take the time to introduce ourselves, as each and every one of us has extremely unique hobbies and things we're into. 2. How we work The Analysis Group is split between 3 locations: Tokyo, Nagoya, and Osaka. Each has teams consisting of data analysts, data engineers, BI engineers, data scientists, and analysis producers, and all the teams go about their work while deftly using online and offline approaches to freely consult with each other. Future challenges we want to tackle We'd like to take on the challenge of connecting and analyzing users across multiple KINTO services we're involved in, and other services besides. In order to do that, the functions and roles of the Analysis Group will need to be linked together organically. It's going to be very challenging, but we hope it'll give us an even deeper understanding of users. KINTO aims to be a top runner in the mobility platform world, and can use GPS and other mobility data to understand the "where" and financial data to understand the "how much." By recording the "who" and "when" in logs of these, we want to gain a deeper understanding of users' preferences and lifestyles. Then, the challenge will be to create systems, predictive models, and so on that will enable us to anticipate their behavior. In conclusion In the Analysis Group, we aim to stay updated with the latest information, and keep working diligently every day, so that we can make our presence felt by contributing to the development of new KINTO services and supporting Toyota Financial Services Corporation.

こんにちは 👋 KINTOテクノロジーズ、グローバルグループ のRuoyang Wenです。* Global KINTO App * チームのフルスタックエンジニアとして勤務しています。当グローバルグループについての詳細は こちら でご確認いただけます 目的 スタートアップ企業ではよくあることですが、初期のプロダクトにはいくつかの妥協点があります。ベネフィットを増やすためには、サービス改善の他に、ワークフローも改善する必要があります。 本記事では、Git-flowからGithub-flowへ変更した理由とその方法をお伝えします。 試み トヨタグループの企業として、当社では日々の作業の中で日本語の「 カイゼン（改善） 」という言葉を使って 改善 を実施しています。お客様からのフィードバックと分析データによって、さらに良いサービスを提供するためのカイゼンはたくさんあります。自動化により、 カイゼン プロセスを加速させることが可能です。 エンジニアにとって、ソースコードをコミットすることは日々の業務であり、単に成果物を提出するだけでなく、サーバー環境でコードをテストすることも含みます。我々は継続的インテグレーションと継続的デプロイ（CI/CD）をチームに導入することで、反復作業の削減を図りました。 CI/CDは、自動化を導入することにより、高頻度でアプリをリリースできる手法です。 ^1 我々はこれまで、Git-flowに従って、ソースコードと開発の進捗を管理してきました。しかし、CI/CDを導入してすぐに、作業プロセスがスピードアップしないことに気がつきました。 推論 git flow ダイアグラム CI/CDスクリプトを利用したり、管理する作業は煩雑です。様々なブランチが多くあるため、ブランチを一つのカテゴリからもう一つの他のカテゴリにマージさせる際、別のスクリプトが必要になります。：_featureからdevelopへ_、_developからreleaseへ_、_releaseからmainへ_、_hotfixからmainへ_、_mainからdevelopへ_、_developからfeatureへ_等… いたるところにコンフリクトが生じます。コンフリクトは自動化スクリプトでは解決できません。自動化により日々の作業量が増大しました。なぜでしょうか。 リサーチを実施して判明したこと： Git-flowは元来、手動かつラグのあるワークフローです。 そこで、新しいワークフローが必要になります。 再試行 先のリサーチで見つけたいくつかのワークフローの中で、私たちはもともとソースコードをGitHubに保存していることもあり、GitHub-flowを試してみることにしました。 github flow ダイアグラム 今回はブランチが二種類のみです： main と 「change-of-anything」 。そして main へ直接コミットすることをブロックします。 main をアップデートする唯一の方法は、 main に対して プルリクエスト を実施することです。その結果、必要なのは1つのCI/CDスクリプトのみとなり、どんなコンフリクトも プルリクエスト の中で発見・解決することが可能です。 新しい課題 我々はブランチ戦略を簡素化し、CI/CDを実施するスクリプトは1つだけで、コンフリクトを管理するためにプルリクエストを利用しました。これですべて解決でしょうか。プラス面もありますが、マイナス面もあります。 プラス面を見てみましょう。反復作業を自動化スクリプトに移管したことで、全員がより生産性の高い作業を行うことができます。リリースとデプロイのプロセスはスクリプトによって処理されるため、ローカルで加えた変更は2分以内にサーバーにデプロイできます。 では、マイナス面を見てみましょう。システムの機能/バージョンの管理ができなくなりました。機能は各ブランチには保存されず、 プルリクエスト 後に直接 main に保存されるため、次のバージョンでどの機能を保留し、どの機能をリリースするかが決められません。また、 main ブランチは最新のソースコードでアップデートされ続けるので、バージョンの番号は1日で数百も増加する可能性があります。 ネクストステップ 幸いなことに我々のみが直面している課題ではありません。すでにこれらの課題に直面している人々がおり、我々は彼らの歩みをたどり、彼らの解決策を見ることができます。 フィーチャートグルを使って、いつでも機能を有効／無効にできます。パラメータの中に保存できるので、新規のリリース／デプロイは不要です。異なる機能の組み合わせを備えた異なるバージョンをリリースするGit-flowよりも優れています。 バージョン番号は、特定のコミットを本番環境にデプロイした後にのみ追加されます。残りの環境には、バージョン番号としてコミットハッシュを使用します。これは、そのコミットのバグや欠陥を即座に見つけるのに役立ちます。 まとめ 疑う余地もなく、すべての問題を解決する完璧なソリューションはありません。GitHub flowには欠点もあり、私はチームと一緒に我々のプロダクトだけではなく、作業方法についても カイゼン するべく動いています。 個人的には、Git-flowはウェブポータルのようなもので、定義されたルールですべてを分類します。誰もミスしなければ、問題なく動作します。一方、GitHub-flowはサーチエンジンのようなもので、本番環境にリリース／デプロイするコミットにバージョン番号をタグ付けし、他の環境ではコミットハッシュがバージョン番号として利用されます。そのため、何か問題があれば、検索でそれらのバージョンを簡単に見つけることができます。 参考 トヨタ生産方式 What is CI/CD? What is Continuous Integration? Git flow for agile teams is a no no Please stop recommending Git Flow! Git Flow vs GitHub Flow GitHub flow - GitHub Docs Continuous Integration Contradicts Features Branches! How to Achieve Continuous Deployment with Feature Flags

はじめに ホアンです。バックエンドエンジニアとして、Global KINTO IDプラットフォーム（GKIDP）チームに所属し、ヨーロッパと南米を担当しています。チームはKINTOテクノロジーズ（KTC）のグローバルグループに属しています。私たちは世界中のユーザーを認証するため、グローバルな課題に取り組んでいます。GKIDPにとって、速くて信頼性が高く、かつ可用性の高いID管理、認証、認可システム（Identity and Access Management (IAM) システム） は必要不可欠です。この記事では、どんな種類のクロスボーダーシステム上でも実行できるロードバランシング／トラフィックルーティングについて、私の考えをシェアします。 HTTP (UDP, DNSも)はステートレス・プロトコルです。つまり、クライアントからサーバーへの各リクエストにおいて、以前のリクエスト情報を一切利用できません。では、なぜステートレスでなければいけないのでしょうか？目的は何なのでしょうか？ これには深い理由があります。ステートレス・プロトコルであれば、どんなリクエストが来ても各リクエストの状態を気にすることなく、任意のウェブサーバーにルーティングすることができます。その結果、スケールアーキテクチャに合わせたロードバランシングが可能になるのです。これにより、ウェブサーバーをグローバルにヨコテンできるようになり、システムレジリエンスの強化とパフォーマンスの向上に繋がります。 この記事では、2種類の主要なロードバランシングについて紹介します。DNSルーティングとハードウェアロードバランサー （別名ロードバランサー）です。これら2つの方法は異なったものですが、組み合わせることで、KINTOの車両サブスクリプションサービスのようなグローバルシステムの強化に利用することができます。 DNSルーティング ユーザーがブラウザにURLを入力すると、ブラウザはDNSサーバーにDNSクエリを送信して、Webサイトのホスト名に対応するIPアドレスを取得します。ブラウザは、Webサイトのドメインではなく、そのIPアドレスを使用してサーバーにアクセスします。以下がシンプルなフローです。  図2.DNSルーティング システムのサーバーが複数の地域に分散しているこのようなケースでは、DNSサーバーは、クライアントを最も適切なサーバーにルーティングし、パフォーマンスと可用性を改善します。DNSがリクエストの転送先を決定する方法を DNSルーティングと呼びます。 DNSルーティングは、ユーザーのリクエストにタッチしないため、簡単な構成でありながらスケーラビリティの高い方法です。多くの場合、データセンターや地域間でユーザーをルーティングするために使用されます。一般的なDNSルーティング方法には、単純なラウンドロビン方式や、位置情報ベース、レイテンシーベース、ヘルスベースのようなダイナミック方式があります。 DNSルーティングには、古いDNSキャッシュの問題といった欠点もあります。DNSは、サーバーがダウンしている場合でも、TTL（生存期間）経過前であれば、あるドメインに対して常に同じIPアドレスを返します。 混乱するかもしれないのでここで説明しておきます。DNSはトラフィックをルーティングしません。DNSクエリに対して、IPアドレスを返すだけです。このIPアドレスでユーザーがトラフィックを送るべき場所が分かります。図2における、ステップ3以降を説明します。サーバーのIPアドレスを取得後、クライアントは実際にトラフィック（HTTPリクエスト等）をターゲットサーバーに送信します。そうするとハードウェアロードバランサーがその背後にある複数のバックエンドサーバーにトラフィックを分散してくれます。ハードウェアロードバランサーについては次のパートで詳しく説明します。 ハードウェアロードバランサー ドメインに対応する変換後のIPアドレスを受信した後、クライアントはトラフィックをターゲットサーバーに送信します。ここで、複数あるバックエンドサーバーの前に設置されたハードウェアロードバランサーが起動し、これらのウェブサーバーにトラフィックを分散させます。実は、ハードウェアロードバランサーはリバースプロキシ、つまりシステムのコーディネーターとしての役割を果たす物理的なデバイスにすぎません。  図3.リバースプロキシとしてのロードバランサー ハードウェアロードバランシングには、レイヤー4ロードバランシングとレイヤー7ロードバランシングの2種類があり、それぞれOSIモデルで言うところのトランスポートレイヤーとアプリケーションレイヤーで動作します。OSIモデルを簡単に説明すると、リクエストはマトリョーシカのように7つのレイヤーに集約されます。より深いレイヤー （レイヤー1からレイヤー7まで）のデータであるほど、より多くの情報を得ることができます。つまり、レイヤー7ロードバランサーは、レイヤー4ロードバランサーと比較して、受信リクエストに関し、より多くの情報を持っているということです。 OSIモデル各レイヤーのデータは以下のようになっています。  図4.OSIモデル各レイヤーのデータ レイヤー4とレイヤー7のロードバランサーは、受信リクエストへの干渉の程度が異なります。 レイヤー4ロードバランサー レイヤー4ロードバランサーは受信リクエストに関する情報をほとんど認識せず、クライアントのIPアドレスとポートのみを認識します。データは暗号化されているので、ロードバランサーはリクエストデータの内容について何も理解できません。そのため、レイヤー4ロードバランシングは、レイヤー7ロードバランシングほどスマートではありません。 メリット： シンプルなロードバランシング データの解読／ルックアップが不要 => 迅速、効率的、安全 デメリット： ロードバランシングの方法が少ない （スマートなロードバランシングができない） キャッシュなし（データにアクセスできないので）。 レイヤー7ロードバランシング レイヤー7ロードバランサーは受信リクエストに関する読み取り可能なデータ （HTTPリクエストヘッダー、URL、Cookie等） に実際にアクセスできます。レイヤー7ロードバランサーは、レイヤー4ロードバランサーよりもはるかにスマートにトラフィックを分散できます。たとえば、非常に便利な戦略としてパスベースのルーティングがあります。 メリット： スマートなロードバランシング キャッシュあり デメリット： 途中でデータを解読する（TLSターミネーション）=> ロードバランサーはデータを確認することになるので、速度が落ち、安全性が低下。 ルーティング／ロードバランシング方法のリスト ルーティング／ロードバランシング方法は目的に応じて複数あります。 ラウンドロビンアルゴリズム：実装する最も簡単な方法：サーバーアドレスが、ランダムまたは順番に返されます。 加重ベースアルゴリズム：各サーバーに送信されるリクエストの割合を制御します。たとえば、少人数のユーザーを対象にカナリアリリースを導入する場合、ユーザーからのフィードバックを得るためにカナリアリリース用に小規模なサーバーを1台設置し、ユーザーの内5％だけをそのサーバーにルーティングします。そして、残りの95％のユーザーには、今までと同じアプリケーションのバージョンを使用してもらいます。 レイテンシールーティングポリシー (通常はDNSルーティング）：クライアントに近く、レイテンシーが最も低いサーバーにルーティングします。低レイテンシーを優先する場合には、このポリシーが適しています。 最小コネクション数 （通常はロードバランサー）：トラフィックが最も少ないサーバーにトラフィックが送られます。このアルゴリズムは、大きなリクエストが特定のサーバーに集中するのを防ぐことで、ピーク時のパフォーマンス向上に役立ちます。 ヘルスチェック （ハートビート）： フェイルオーバー。ライブセッションを行い、各サーバーの状態を監視します。ロードバランサーは、登録されている各サーバーのハートビートをチェックし、あるサーバーの状態が良くない場合はリクエストのルーティングを停止し、別の正常なサーバーに転送します。 IPハッシュ（通常はロードバランサー）：最適なパフォーマンス (キャッシュ等) が得られるように、クライアントのIPアドレスを固定サーバーに割り当てる 位置情報ルーティング (通常はDNSルーティング）：大陸、国といったユーザーの各場所に基づいて、適切なサーバーへ案内します。 マルチバリュー （DNSルーティングのみ）：1つではなく複数のIPアドレスを返します。 パスベースのルーティング (レイヤー7ロードバランサーのみ）： リクエストのパスに応じて、処理を担当するサーバーを決定します。例：/processingの場合、リクエストは処理サーバーへ、/imageの場合、イメージサーバーへ転送されます。 最後に ハードウェアロードバランサーとDNSルーティングは混同されがちです。これらは互いに代替手段というわけではなく、通常は組み合わせて使われています。重要なのは、データセンター間や地域間などの広い地域にまたがる場合にはDNSルーティングが使用されているということです。ハードウェアロードバランサーよりもはるかに安価で高速であるためです。その後の段階で使用されるのがハードウェアロードバランサーで、多くの場合データセンターや地域内においてトラフィックを分散させます。DNSルーティングはDNSクエリを、ハードウェアロードバランサーはトラフィックをそれぞれ処理します。 これら2つの定義の理解は、高いパフォーマンスと可用性を持ったグローバルシステムの構築に不可欠なものです。 参考 https://medium.com/@phamduchoang.eee/but-what-is-osi-model-29578b795f0c https://iq.opengenus.org/layer-4-layer-7-load-balancing https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy-edns0.html

自己紹介 KINTOテクノロジーズ（KTC）でアプリケーションエンジニアをしているJLと言います。現在はグローバル開発グループのフロントエンドチームに所属しています。 日本に来る前はフィリピンで3～4年働いていました。最初は水産業界でテクニカルサポートとして、その後は金融セクターでソフトウェアエンジニア（アソシエイト）として働いていました。 フロントエンドとビジネスサイドの両面からプロジェクトに携わることで、Webやバッチ処理、ビジネスプロセスにおける開発経験を積むことができました。使用していたのは主にJava、JSP、JavaScript、CSSです。また、ソフトウェアエンジニアの専門的スキルも学ぶことができました。当社の従業員として会社に貢献しようとすれば必ず必要になるスキルです。 勤めていた会社は日本に本社があり、それで日本に行ってみたいと思うようになりました。日本のエンジニアチームが高い技術力を持っていることは知っていましたし、日本は科学技術分野で高い評価を受けている国ですから、そういった環境で直接学びたいと思いました。 KINTOテクノロジーズに入社 日本に来てからは、東京の派遣会社で契約社員として働いていました。派遣社員という立場だったので、担当するプロジェクトの範囲や責任は限られていました。 リクルーターからKINTOテクノロジーズを紹介された際、以下のような理由で魅力的に感じました。まず、人々が旅行や出張で世界中を飛び回っている中、KINTOテクノロジーズのモビリティサービスのグローバル展開には成長の可能性があると感じました。 次に、KINTOテクノロジーズはまだ新しい会社ですが、長年にわたってより良い車とサービスを世界に提供してきたトヨタグループの一員であることにも魅力を感じました。そして技術的なスキルだけでなく、コミュニケーションやビジネス分析のスキルも学べると思いました。 また、グローバルグループのアプリケーションエンジニアとして、さまざまな国の視点からプロジェクトに取り組む機会も多くあることでしょう。 KINTOテクノロジーズは明確なビジョンを持った企業であり、今現在もさらなる成長の可能性を秘めています。価値ある未来の製品を開発できるポテンシャルがありますし、その開発に携われることを願っています。 KINTOテクノロジーズでの生活と経験 グローバルグループは国籍豊かな多文化グループで、日本、中国、ベトナム、インド、フィリピンなどから人が集まっています。 チームでは英語を使うので、コミュニケーションが取りやすく、言葉の壁をあまり感じません。 日本にいながら、グローバルグループはタイやカタールといった海外のKINTOサービスの支援をしています。 また、グローバルグループでは毎月アンケートを実施しており、その中で改善のためのフィードバックや提案をすることができます。さらに月に1度、上司との1on1ミーティングがあり、キャリアプランを立てたり、社内において今後取り組んでいきたいことを決めるのに役立っています。 入社後、フロントエンド・エンジニアリングチームに配属されました。チームの仕事は、グローバルグループ製品のフロントエンドの開発と、そのためのWebレイアウトを強化し、サイト訪問者の目を惹くような仕上がりにすることでした。 そのチームで私はテクノロジーポータルの開発を任されました。テクノロジーポータルはゼロから開発されたもので、どのようなソリューションが使えるのかを知るために世界中のKINTOパートナーに利用いただいています。 テクノロジーポータルはGatsby.js、CSS、AWS S3を利用して開発されています。使われているプログラミング言語やアーキテクチャが馴染みの薄いものだったので大変でしたが、やりがいはありました。ありがたいことに、このおかげで短期間で大きく成長することができました。 現在、 Global KINTOアプリのランディングページ の開発に取り組んでいます。このページでは、Global KINTOアプリに関する情報と各国のKINTOサービスに関する情報をご覧いただけます。 このプロジェクトでは、既存のウェブサイトをKINTOのデザインシステムに沿ったデザインに改良しました。このデザインシステムでKINTOのシステムとプロダクトデザインの統一を図ります。詳しくは こちら をご覧ください。プロジェクトでは主にVue.js、Vuetifyを使っています。今回のプロジェクトを通して、デザインのセオリーとベストプラクティスについてより深く学べました。とりわけ、レスポンシブデザインの方法や、SASS、CSSの効率的な使い方に関する分析スキルやクリエイティブさが鍛えられています。 終わりに まとめると、日本に行くことを決めたときに思い描いていた通りのキャリアを、KINTOテクノロジーズで歩むことが出来ています。応募したのはアプリケーション開発とモビリティアプリだったので、最初はこれらだけを担当するものだと思っていました。しかし、そのようなポジションに限定されず、フレキシブルに色んな業務を任されていることで、システムデザインやWeb開発にも取り組み、自身のスキルアップ、キャリアアップに繋がっていると思います。 短期にスキルを身に着け、課題に挑戦し、そしてその課題を見事に解決する。解決した後の爽快感を味わうと、この会社で働けて良かったという気持ちになります。自分のスキルが大きく向上したことに気付きます。 これから出会う、よりエキサイティングな課題への挑戦が楽しみです。社員を特定のポジションに限定しないので、KINTOテクノロジーズには多くの可能性があります。将来的には私でもアプリケーションサービスの開発に携わったり、テックリードとして働く可能性もあり得ます。 会社として競争力があり、スキルアップの機会も多く、責任ある仕事を任され、キャリアアップを図ることができる、そんな職場をご希望なら、ぜひKINTOテクノロジーズで働いてみませんか？ 特にグローバルグループには、多様で優秀な人材が揃っています。各自が業界のトレンドに合わせて常にスキルを向上させています。KINTOテクノロジーズには確固たる基盤があり、ここで働くことになれば、きっとエキサイティングなプロジェクトに取り組むことができるでしょう。 https://www.kinto-technologies.com/recruit/globalkinto

はじめに こんにちは。KINTO Technologiesのグローバル開発部でフロントエンド開発をしているクリスです。 この間 Vue Fes Japan 2023 に参加してきましたので、当日参加した講演の要約と私の所感について紹介したいと思います。 エンジニアになって最初の頃にVueに触り始めて、以降もずっとこれを利用してきたのにも関わらず、2018年に初開催されたこのイベントに今年初めて参加するのは少し恥ずかしい話ですが、初参加というのと、VueとViteのクリエイターであるEvan You氏に会えるのもあって、当日朝からずっとワクワクの状態でした！ そしてようやく会場に着いたら、入り口に書き込みボードがあったのでさっそく弊社の存在をアピールしてみました！ Evan You氏による基調講演 主にVue3の振り返りで、良かったことと反省すべきことについて述べられました。 まず反省点ですが、Vue2からVue3へのマイグレイションが大変だったことについて話されました。具体的には以下のポイントです。 破壊的な変更箇所が多かったこと Vueのエコシステム内になるライブラリーに与えるインパクトを過小評価したこと すべての変更箇所を一気にリリースしなかったこと 一方、バージョンアップそのものに関しては、良かったこともありました。 よりTypeScriptフレンドリーになったこと Composition APIを導入したこと 開発者体験（DX）に投資したこと Vue3が確実に成長していること これらを元に、今後の展望としては、「安定」を重視し、これからのバージョンアップの際に今回みたいに破壊的な変更を抑えていきながら、 スムーズに改善点や新機能を取り入れられるようにし、開発者にとってよい開発体験を与えたいとのことでした。 その一つの例として、VueのエコシステムCIを導入し、今後Vueのバージョンを上げる際にVueをdependencyとしているライブラリーに破壊的な影響を与えていないかを確認するCIツールが立ち上がりましたが、全てのテストが通ったとは言え、例えば本公演の前にリリースされたv3.4 alphaに関しては、リファクタリングが多かったので、やはりコミュニティーのみなさんにいろいろテストしてもらい、フィードバックを求めていました。ちなみにこのリリースには、メモリ制御の改善や、より正確かつ効率的なre-computeの実現などが含まれています。 基調講演を聞いて、自分もVue2からVue3へのマイグレイションで挫折したことがありましたので、それをEvanさんが反省点として取り上げてくださって良かったと思います。 ちなみに余談ですが、講演中HDMIの接続がどうやら悪く、何度も切断されましたが、なんとか無事に講演を終えました（笑） Nuxtに関するアップデート 続いてはNuxtLab CEOのSebastian Chopin氏とNuxt CoreチームメンバーのDaniel Roe氏がそれぞれNuxtについてお話しをしてくれました。 まずはSebastianさんがNuxtの最近のアップデートを紹介し、中にはHybrid Rendering(ページごとレンダリング方法を設定すること)のデモやCloudflareを使ってNuxtアプリをEdgeにデプロイするデモを見せてくれ、最後はNuxtのエコシステムをより大きくするための仲間を募集していました。 一方、DanielさんはNuxtのエコシステムを紹介し、それぞれのツールやライブラリーの最新情報を話してくれました。例えば Nuxt2でもComposition APIなど3系の機能が使えるようにする nuxt/bridge Nuxtのテストに様々な機能を提供する nuxt/test-utils マークダウンファイル(.md)だけでページ作成できる nuxt/content などがありました。 そして最後はNuxt4の方針について、よりDXをフォーカスし、オプトイン方式でたくさんのツールを提供し、そしてよりオープンな開発プロセスを実現するために多くの人に参加してもらいたいと話しました。 お二人の講演を聞いて、Vue/Nuxtのユーザーとして、開発に携わっているみなさんの活躍を見て、将来的には一人のコントリュビュターとしてこのコミュニティーに貢献したいなと思いました。 OSS活動における考え方 本セッションはAnthony Fu氏が、ご自身のOSS活動についてお話されました。 まずはご自身がOSS活動に参加されるきっかけとなった vscode-vue-i18n-ally というエクステンションについて例を挙げましたが、名前通りVSCodeというIDE、Vueというフレームワーク、i18nという機能を利用する人のためのアクセサビリティーツールであり、そう考えると実はターゲットユーザーはかなり限定されてしまうことになります。それではより多くの人に使ってもらえるにはどうしたらいいでしょうか。 Anthonyさんは対象となる二つのアプローチを紹介しました、一つはツールそのものの利用制限をなくすことです。例えば、 vscode-vue-i18n-ally に戻ると、Vue以外のフレームワークも使えるようにすれば、利用できるユーザーが自然に増えることになります。その結果が i18n-ally です（私の知っている限りこちらもVSCode用のエクステンションですが）。そしてもう一つはの方法は複数のツールでツールのユニオンを結成することです。例えば、Nuxtの周辺には多くのサポートツールがあり、それぞれを必要とするユーザーが一定数います。このようなユニオンがあれば、ユーザーは必要なツールを使い、それだけで大きい開発コミュニティを作ることができます。この二つのアプローチは利用ユーザーを増やすだけでなく、利用ユーザーが増えたことによって、最終的にコントリュビュターも増えるという効果が期待されます。 彼の話を聞いて、まだOSS活動に携わったことがない自分から見ると、OSSにも普通のプロダクトと同じく、ユーザー獲得という概念があって、より多くのユーザーに使ってもらえるようにはどうしたらいいか常に考えないといけないなと思いました。 質問コーナー 最後のセッションはEvanさん、SebastianさんとDanielさんに色々質問を答えてもらうセッションでした。1時間なのに、事前にみなさんから投げた質問が多すぎて結局一部しか答えられなかったが、その中には特に印象に残ったのが以下4つでした。 Q: サーバーサイドコンポーネントについてどう思うか A: 結局StaticはStaticのよさがあるので、自分のニーズに合うのを使えばいいが、サーバーサイドコンポーネントを利用した方がいい例を一つ挙げるとしたら、ECサイトでしょう。 Q: Vue, Nuxt, Vuetifyをまとめて2から3にマイグレイションするのが大変で、やり方を教えて欲しい。 A: まずこんなに大変になるのは完全に私のせいですね、そこは申し訳ない（笑） 一つのやり方としては、スクラッチから別のプロジェクトを立ち上げて、少しずつ移行していくのがよいでしょう。 Q: Nuxtにとってのいいコンポーネントのデザインパターンはあるのか？ A: 特にない、Vueを作った時はAngularがプレゼンターパターンを利用してたが、パターンに縛られたくないという思いがあったからこそ今のVueなので、こちらに関してもまずは小さく開発し、ちょっとずつどんなパターンがいいか決めていけばいいでしょう。 Q: VueのNativeアプリ対応についての予定を教えてください。 A: 今のチームだと対応する余裕がまったくない、たぶん数倍くらいのリソースが必要。IonicやNativeScriptを利用するといいのではないでしょうか。 アフターパーティー アフターパーティーは立食形式で、協賛によって洋食と寿司が提供されました。 自分はかなり内向的な性格でいつもパーティーなどでこちらから声をかけることを躊躇っていますが、勇気を持って最後の最後に来日してくださったEvanさんをはじめとするコアチームメンバーに声をかけてみて、色々話せてよかったです！中にはAnthonyさんに初めてオープンソース開発で色々不安を持っている方へのアドバイスについて聞いてみたところ、「1. まずは小さいツールからスタートしてみること、2. とにかく勇気を持つこと」を語ってくれましたが、これを聞いた私からするとすぐ納得いきましたね。 感想＆まとめ 正直に言うと、初めてVueとNuxtのコミュニティイベントに参加し、とても楽しかったですが、それより一番思ったことはやはりOSSコントリュビュターはやはりすごいということでした。VueとNuxtのコアチームはさほど大きくないからこそ、しっかりやることを制限（質疑応答にあったVue Nativeをやらないと決めることなど）したことと、作ったツールをVueだけではなく、他のフレームワークにも恩恵受けるにはどうしたらいいかを考えるマインドセットを持たれていて尊敬しかありません。 来年はどんな形であろうが、またVue Fes Japanに参加したいと思います！

Introduction Hello! I’m Kin-chan from the Development Support Division at KINTO Technologies. It might seem sudden, but on Thursday, August 3rd, we’ll be hosting our very first KINTO Technologies MeetUp! - 4 Case Studies by and for Corporate IT Teams . This event will focus on the corporate IT domain and take the form of case study presentations followed by a roundtable discussion. In this article, I’d like to share the behind-the-scenes story of how we got this study session off the ground. If you’re someone who’s thinking, "I want to start and lead a study session from scratch," I hope this will be helpful and encouraging. What Comes to Mind When You Hear "Study Session"? It might be a bit sudden, but what comes to mind when you hear the term "study session"? Listening to experts in your field and gaining new insights Getting together with others who share your interests to learn and grow together Joining as part of your job, perhaps even being expected to attend, in the name of team skill-building (Though less common during COVID) Participating mainly for the conversations and food at the social gatherings As you can see, study sessions can serve many different purposes and come in many forms. When I think about what a study session means to me, I’m reminded of a community I once helped organize called " DevLOVE ." The concept behind it was to create a "learning space" where knowledge and experience could flow between the workplace and the outside world—to help move our teams and organizations forward. Having always seen value in study groups and communities like this, I joined KINTO Technologies hoping to get involved in opportunities to share and learn within the company. *I’ll go into more detail about how this mindset turned into concrete action in a future post in our "Agile Series." Okay, Then Let's Have a Study Session When I joined KINTO Technologies, I found that the company already had a strong culture of holding regular study sessions and offering many opportunities for learning. For example: Optional company-wide study sessions for engineers Business-focused sessions hosted by business divisions to deepen understanding of our operations Small group study sessions and book clubs organized within each product team What impressed me most was the supportive culture that encouraged participation in study sessions and book clubs—both inside and outside the company—as part of regular work. There’s even a system in place that covers the cost of books needed for learning. It was clear to me that KINTO Technologies genuinely supports its employees' development. In this environment, I started holding small study sessions and group reading sessions for my own team, spending my days learning alongside my colleagues. And somewhere in the back of my mind, I kept thinking, "I wish more people knew about this culture." One day, a discussion came up in our team about how we could better recruit corporate engineers. As we explored various ideas, one thought kept coming back to me: "How can we showcase our strengths and this great culture to more people?" The challenge naturally connected with my earlier desire to share our company’s learning culture more widely. As a result, we came up with the idea: "Why not hold a study session that includes people from outside the company?" I Can't Do This Alone! Help Me Everyone! With that spark, I quickly drafted a "Proposal for a Corporate IT Study Session" and shared it with our team leaders as a formal idea. Each leader gave it a "thumbs-up." That gave us a green light to move forward, but saying "let's do it" was only the beginning. There was still a lot to figure out: What would the theme be? Who would present? Where would it take place? When should we hold it? What would the timetable look like? It was clear that I couldn’t handle all this alone. So the following week, during the full team meeting, I made an announcement: " We’re going to hold a study session! We’re looking for members to join as organizers and speakers! " In the end, a team of six was formed, including volunteers and recommended members! We immediately created a dedicated channel on Slack and began communicating with all the relevant members. To make sure everyone was aligned on the goal, we kicked things off with an internal meeting for the organizing team. Since not everyone had been involved from the initial planning stage, we focused on a few key areas: What is the purpose of the event, and what will it look like? What is the goal state we’re aiming to reach? What has already been decided, and what still needs to be figured out to reach our goal? How will we resolve the unsolved issues? We began by clearly aligning our "goals" and "understanding of the current status." Then, we set the "next milestone to aim for," and each member began preparations. We Can't Do All by Ourselves!! We Need More Help! The next step was for the organizing team to discuss the unresolved topics. We broke it down into five major areas: Content Format and equipment needs Date and timetable Promotion and outreach How to measure success We held in-depth discussions to clarify each point. As we worked through these, we identified what we could manage ourselves and what would require cooperation from other departments. Based on this, we began setting up meetings that included key stakeholders from other teams. *Once the decision to hold the study session was made, our manager had already started reaching out to divisions that might be needed for support. Thanks to that early communication, we were able to smoothly hold a company-wide kickoff meeting. Thankfully, many of the people who participated in the joint kickoff were very positive. In response to our ideas, they offered suggestions like, "How about trying this?" and "We’ve done something similar before, so it can be handled quickly." Their input helped us get closer to our goal. We Need Flexible Yet Transparent Project Management! As our plans became clearer, a number of concrete action items began to emerge in parallel. We realized that if we simply relied on "whoever could handle it" to take things on as they came, it would be difficult to keep track of progress. In other words, transparency would suffer. To avoid that, we decided to define a certain level of visualizing, progress tracking, and role assignments. Visualizing We used Jira to make tasks visible and prioritize them in a structured way using the "Epic > Task" hierarchy Progress Management We set weekly goals at the Epic level. Each week, we reviewed our progress and adjusted course as needed. If all went well, we would then set the next goal. Division of Roles We assigned responsibility for each Epic. If someone was falling behind or having trouble reaching their weekly goal, others would step in to help. This approach helped us achieve iterative, incremental progress in managing the organizing team. [Side Note] How We Applied "Agile Kata" to Run the Organizing Team As a quick aside, the way we approached organizing this event was inspired by the concept of the " Agile Kata ," particularly its idea of "Improvement Kata." According to "Agile Kata," you can apply agile thinking in your daily work by repeating the following steps: Understand the direction and challenges Grasp the current situation Set the next target state Experiment toward that target in an iterative way Even without relying on a fixed framework like Scrum, you can create an agile way of working simply by applying the Kata mindset. And Right Now... Even as I write this article, the discussions and actions needed for the study session are moving forward every single day, bringing us closer to the goal. We’re holding synchronous web meetings by topic, and Slack is buzzing with asynchronous conversations—some threads get more than 50 replies in a single day. It really feels like things are progressing quickly. Everyone’s doing an incredible job!! With preparations steadily taking shape, the " KINTO Technologies MeetUp! - 4 Case Studies by and for Corporate IT Teams " is finally within reach. Please look forward to the event!!

Introduction My name is Zume and I am the Quality Assurance (QA) Group Manager at KINTO Technologies. I'm a lifelong cat lover. Cats truly make everything better. There’s something special about their pure, honest nature. In this article, I’d like to introduce the role and responsibilities of our QA Group. About the QA Group The QA Group is primarily responsible for pre-release verification of various services at KINTO Technologies. Our mission is to improve the overall quality of the products we provide and take the lead in QA initiatives. Current Activities Until recently, our QA efforts mainly focused on domestic products like KINTO ONE (New Vehicle and Used Vehicle). However, KINTO Technologies also has a global development group, so we are now also involved in overseas product projects. We also offer an app called Warikan KINTO, which is developed in collaboration with a Swedish company. As a result, our QA communication for this project is conducted in English. In terms of the development process, our QA work corresponds to the system testing phase, which is paired with requirements definition in the V-shaped model. Our QA testing generally includes the following: Verifying that functions and performance meet requirements. Identifying and eliminating bugs and risks. Confirming that the product meets the release quality standards. At KINTO Technologies, User Acceptance Testing (UAT) is carried out by the business side, QA work involves a series of processes, from test planning, design, implementation, reporting defects, to checking modifications, and reporting release decisions after testing is complete. Depending on the project, QA does not only participate after development is complete, but rather participates from the requirements definition phase. The aim is to understand both business and system requirements at an early stage. The QA Group is also the only division that has the unique ability to perform cross-functional testing across different systems. Therefore, from our QA perspective, we aim to raise any concerns in advance so that we can resolve them at the earliest stage. After each release, we hold internal retrospectives, and participate in overall project reviews where we identify trends in defects and propose improvements. These efforts help ensure smoother progress in future projects. If you’re interested in an overview of our QA work, our team member okapi has written another article , so I’d appreciate it if you took a look as well! Group Members, Atmosphere, and Work Style There are currently nine members in the QA Group, including myself. As our team becomes more international, English proficiency is becoming increasingly valuable. While not strictly required, the ability to communicate in English can open up additional opportunities. Each of us has our own areas of expertise, such as apps or web, but we structure the team so that everyone can handle any product as needed. Our members vary in age, and the gender ratio is roughly 50/50. We don’t rely solely on Slack or Zoom. In fact, we often come to the office and talk face-to-face more than online. We also keep a dedicated Zoom room open all day, so whether you’re working remotely or in the office, there’s always someone you can talk to. Since we work with external partner companies, we frequently use Zoom breakout rooms for meetings. To keep the communication flowing smoothly within the team, we hold morning meetings at the start of the day, an evening wrap-up meeting, and a weekly team meeting. While some members work from home depending on the day, most meetings are held via Zoom. However, our weekly team meetings are usually held in person. We also hold study sessions from time to time to help improve team members’ skills. These are not regular events, but we organize them as needed. For now, the main focus is on deepening our understanding of services and system specifications. In the field of testing, the Foundation Level certification defined by ISTQB is generally considered a basic qualification. However, we do not require it as long as you have equivalent experience and skills. In fact, having a certificate alone is not enough. What really matters is how well you can apply that knowledge in practice. That’s why we place greater value on hands-on QA experience, such as the types of projects you’ve worked on and the specific roles you played, as well as your practical skills. This applies to engineers in general, and QA engineers are no exception. Strong problem-solving skills are essential. Future Outlook In our QA Group, we have been working on test automation for some time now. Currently, automation is limited to certain areas and only covers the web, but in the future we would like to expand it to the mobile (native apps) area as well. We hope to share more about the tools we use, and those we’re considering, in a future post. Since everything we work on is car-related, if you enjoy cars, whether driving or just looking at them you'll likely find it even more enjoyable. Personally, I’ve been driving and owning cars for quite a long time, and I still enjoy learning new things and making unexpected discoveries every day. The QA Group also plays the role of the final checkpoint to ensure product quality before it reaches our customers. At the same time, we’re also the team that gets to experience new services before anyone else. If you find that rewarding and interesting, we would love for you to join us.

Introduction Hello, we're Yao Xie and Mooseok Bahng, who work on mobile app development in the Global Group at KINTO Technologies. We're currently working on an app called Global KINTO App . The Global KINTO App (GKA) was built with the goal of connecting together KINTO services all over the world with a single app. So far, KINTO services have been deployed in Thailand and Qatar. While working on a project destined to replace an existing app, we decided to adopt Kotlin Multiplatform Mobile (KMM). So, we're going to talk about that. Background on why we decided to adopt KMM There were a few issues that lead to our decision to adopt KMM. - No matter what we did, differences always arose in the business logic between iOS and Android. - The development team is physically split between 2 locations, which can impact development efficiency. -> We thought we could improve things by dividing the team into KMM and native. - Our development resources are limited, so we want to create an efficient development system. Based on these, we started to consider KMM. What is Kotlin Multiplatform Mobile (KMM)? An SDK for developing iOS and Android apps, KMM uses Kotlin as its base language, and offers the benefits of both cross-platform and native apps. You can develop a common business logic using KMM, then develop the platform-dependent UI elements natively. We personally think that it's best to provide the optimal UI/UX for each OS. With KMM, you basically develop each UI natively, so the UI/UX can be optimized with little dependence on iOS and Android, and we also think version upgrades are going to have virtually no impact. KMM is still a new technology and isn't very mature, but it's been getting used more and more by various companies in recent years. Kotlin Multiplatform Mobile (source: https://kotlinlang.org/lp/mobile ) Architecture Before we talk about KMM, let's talk about the architecture currently being used by the development team. In short, we develop using an MVVM pattern. This policy basically won't change even though we're adopting KMM. At this point, we were wondering just how much we should include in KMM. There are around three options. KMM Native Option 1 Repository, Usecase, View Model UI Option 2 Repository, Usecase View Model, UI Option 3 Repository Usecase, View Model, UI We tried various approaches, but for now, we're moving in the direction of using KMM up to the view model. We also considered leaving out the view model, but couldn't find any good reasons for handling it separately despite making the effort of adopting KMM. This is especially true for simple features like displaying data in a list. Maybe we'll need to do the view model separately as more complex features get added. When that happens, it should be possible to do just some parts of it separately. The codebase for iOS is now pretty compact. We're using KMM up to the domain layer and view model, so there's only UI- and platform-dependent hardware-related features, and we think it'll probably amount to at most half as much source code as before. Here's some iOS code for a simple screen with an FAQ list. Apart from a common UI Utility class, this is all we need. swift struct FaqView: View { private let viewModel = FaqViewModel() @State var state: FaqContractState init() { state = viewModel.createInitialState() } var body: some View { NavigationView { listView() } .onAppear { viewModel.uiState.collect(collector: Collector<FaqContractState> { self.state = $0 } ) { possibleError in print("finished with possible error") } } } private func listView() -> AnyView { manageResourceState( resourceState: state.uiState, successView: { data in guard let list = data as? [Faq] else { return AnyView(Text("error")) } return AnyView( List { ForEach(list, id: \.self) { item in Text(item.description) } } ) }, onTryAgain: { viewModel.setEvent(event: FaqContractEvent.Retry()) }, onCheckAgain: { viewModel.setEvent(event: FaqContractEvent.Retry()) } ) } } Pros Single codebase We can manage iOS and Android networking, data storage, business logic, and more with a single codebase. Consistency Having a common business logic means we can basically provide the same UX. Efficiency Adopting KMM has enabled us to do development work more efficiently. Cutting our time costs almost in half means we're getting to spend that much longer on source code optimization and business deployment. Expandability We can easily expand development as needed to include other platforms besides iOS and Android. Cons For iOS debugging, you need to install a separate plugin. If you use XCframework, using Simulator on an Apple Silicon Mac results in an error because it references arm64. We think this will need to be fixed on the KMM SDK side, but for the time being, we can use Simulator either by adding arm64 to the excluded architecture, or running Xcode in Rosetta mode. Distribution method for iOS Build & Sourcesets Build XCFrameworks Up to now, distributing KMM to iOS has basically been done with a Universal (FAT) framework. Official support for XCFramework has finally come out recently, so we're planning to go with that. https://kotlinlang.org/docs/multiplatform-build-native-binaries.html#build-xcframeworks Other They're not directly related to KMM, but here are some other new technologies we're also thinking of adopting: Ktor You can use the same settings for both clients. The API Request code is the same. The engines for iOS and Android are separate, but no additional code is required. Apollo Client We're also using some of the GraphQL API in some of existing projects. We're thinking of adopting the Apollo Client in order to use GraphQL. You just need to create Queries.graphql using schema.graphqls in the backend, and Models, Adapters, and Queries will all get created automatically. https://github.com/apollographql/apollo-kotlin MMKV MMKV is a mobile key-value storage framework. It supports multiple platforms, including Android and iOS of course. https://github.com/Tencent/MMKV https://github.com/ctripcorp/mmkv-kotlin With MMKV-Kotlin, we can easily integrate MMKV into our projects and manage key-value storage with a shared module. Performance comparison on Android Performance comparison on iOS Future developments Fast growing KMM ecosystems KMM is being developed by Jetbrains. It can be used seamlessly with Android Studio and has some Xcode support as well. It's spreading among developers, and there are a lot of open source libraries for it. https://github.com/terrakok/kmm-awesome Cross-platform UI Touchlab has already started experimenting with using Compose UI for both iOS and Android. https://touchlab.co/compose-ui-for-ios/ @Composable internal actual fun PlatformSpecificSettingsView(viewModel: SettingsViewModel) { IconTextSwitchRow( text = "Use compose for iOS", image = Icons.Default.Aod, checked = viewModel.observeUseCompose, ) Divider() } KMM may start to officially support cross-platform UIs in the near future. Summary In this article, we talked about how we've adopted KMM. We're now expecting it to bring the following improvements: - Being able to minimize the business logic gap between iOS and Android - Being able to optimize the development team structure if required - Reducing the development time to a certain extent We're still in the early stages of adopting KMM and are going to face lots of issues and steadily build up our know-how, so we'll share more once we've made some more progress. Thank you for reading.

はじめに こんにちは！KINTOテクノロジーズの開発支援部に所属する「きんちゃん」です。 普段はコーポレートエンジニアとして「全社利用するITシステムの維持管理」を行っています。 先日、「 KINTOテクノロジーズ MeetUp！～情シスによる情シスのための事例シェア4選～ 」というタイトルで「コーポレートIT領域に特化した、事例発表＋座談会形式の勉強会」を開催しました。 今回は、その勉強会で事例発表した内容について、補足を交えながらテックブログ上で紹介します。 発表資料 当日の発表資料全体については、以下を参照ください。 【アジャイルなSaaS導入】最小工数で素早く最大の成果を生む秘訣 ここから先は、実際に発表で利用したスライドと共に、資料だけでは分かりづらい部分の補足や、会場ではお話できなかった部分について、色々と補足していきます。 タイトルの選定 さっそくですが、このタイトルです。 「アジャイル」というキーワードについては、多くの方が色々な解釈を持たれており、発表のタイトルとして利用するのは、なかなか悩むところです。 ただ、僕の発表を聴いてくださった/見てくださった誰かが「あ、こういうのもアジャイルなんだ」「そんなに難しい話じゃないな」といった気づきを得て、それがその人の新たな行動の後押しになれば、と考えて「アジャイル」を利用しました。 ※もちろんキーワードとして「惹きがある」という点もポイントでした。 話すこと/話さないこと タイトルで「アジャイル」のキーワードを使ったからには、やはりメインで伝える内容は「アジャイルソフトウェア開発における価値」にリンクできると良いなと思ったので、このような内容にフォーカスしています。 もし「もっと詳しい導入プロセスや、プロジェクトの途中で起きた地味な話を聴いてみたいよ！」という方がいらっしゃれば、ぜひKINTOテクノロジーズへのJoinをご検討ください。 背景 まずはITチームから導入を開始したITSM（IT Service Management≒問合せ/依頼管理）ツールですが、それなりにスムーズな導入ができた背景もあり、IT以外の管理部門にも導入しましょう！という流れができました。 その流れができるまでは、社内であまり「IT以外の管理部門」に接する機会はありませんでした。 僕自身、前職以前を含めて過去に多くの非IT部門の方々とのプロジェクト経験があったため、このプロジェクト推進の指名をもらった時は、過去の経験が活かせると感じたため、嬉しかった記憶です。 「ある程度のゴールイメージはあるものの、具体的な要件や機能については定まっておらず、とは言えなるべく工数はかけずに勝ちを得たい」という背景から、「カッチリと要件を決めてフェーズを切った導入（≒ウォーターフォール）」よりも、「最小限の価値を作り込みながら、対話と軌道修正を繰り返す導入（≒アジャイル）」の方が適している、と判断したものになります。 このスライドでは「アジャイルに進めると良いんじゃなーい！？」と、あたかもプロジェクト開始時点から考えていたように見られますが、実際には「どういうふうに進めようかなー。とりあえず関係者の人たちに話を聴くところからだなー」くらいの感覚でした。 実際には、管理部門の方々とのヒアリングを経た上で、「この人たちとなら、このスタイルで進められそう！」という感覚を得たため、後述の「アジャイルな進め方」に踏み切った形です。 アジャイルについて 僕は、社内で「アジャイルってなんですか？」って聞かれた時に「短い期間でカイゼンを繰り返しながら、価値にフォーカスした仕事を進められている状態です」みたいな回答をしています。 ソフトウェア開発に触れている方であれば「アジャイルソフトウェア開発宣言の価値と原則」は分かりやすいですが、そこにピンと来ない人もいます。 最近では「アジャイルのカタ」という文書も公開されたり、非IT向けのアジャイル書籍も発売されたり、色々と説明しやすくなってきたな、という感覚があります。 プロジェクトの進行について ここからのスライドについては、できるだけ「アジャイルソフトウェア開発宣言における価値」にリンクする形で「どこがアジャイルなのか？」を説明できるように心がけました。 このスライドで伝えたかった事は、「なるべく無駄なコミュニケーションを減らし、本質的な会話にすぐ入れるようにするための仕掛けづくり」です。 良くあるソフトウェア開発の場合は、「今どのような業務をおこなっているのか？」を探索する工程や、「何をやりたいか？」を明らかにしていく工程があります。 今回は「ある程度のカタが決まったSaaSの導入」であるため、「今の業務を元に要件を定めていく」よりも、「カタを前提にした、良い使い方」を模索していく方が適切と考えました。 また、ローコードツールの強みとして、初期段階での「作って壊して作り直す」のコストが圧倒的に低い事もあり、「初回の打ち合わせ前に、最小限の価値が提供できるプロトタイプを作る」事も容易に進められました。 結果として、初回の打ち合わせで「さぁ、どんなものを作りたいですか？」という会話を始めるのではなく、「こういう使い方のシステムだとどうでしょう？何かおかしなところはありますか？」といった、具体的な動くものを対象にした議論からスタートできるようになりました。 これらは、アジャイルソフトウェア開発宣言でいうところの以下の価値にフォーカスした点となります。 プロセスやツールよりも個人と対話を 包括的なドキュメントよりも動くソフトウェアを このスライドで伝えたかった事は、「短い間隔で価値を作り込み、フィードバックを得て、納得の行くシステムを提供するための仕掛けづくり」です。 打ち合わせで良くあるものとして「持ち帰り検討」があります。例えば「どういうメニュー構成が良いか検討してくる」「どういう処理フローが良いか検討してくる」といったものです。 今回は、そのような「持ち帰り検討」を「相手にお任せ」するのではなく、「持ち帰り検討の場に、自分がゲストとして参加させてもらう」方法を取りました。 そうする事で、会話の中で出た質問や懸念・違和感といったものを即座に受け止め、素早く回答したり、その場でシステムの改修に手をつける事もできるようになります。 結果として、「持ち帰り検討の場」であるにも関わらず、「検討を踏まえた仕様変更と、実際の機能改修」までも進めてしまえるようになりました。 また「ここで大きな仕様変更が出た」とありますが、ある意味「作り直し」をした方が良い状況になりました。もちろん、これまで作ったものを捨てる事になりますが、議論の場に僕も参加していた事で「作り変える事の必要性と価値」について十分に納得した上で、その選択を取る事ができました。 これらは、アジャイルソフトウェア開発宣言でいうところの以下の価値にフォーカスした点となります。 契約交渉よりも顧客との協調を 計画に従うことよりも変化への対応を プロジェクトを終えてみて 今回のプロジェクトを通じて、僕が大きく得られたと感じるものは「信頼関係」です。 あくまでも僕からの一方的な意見ではありますが、「この人たちと一緒に仕事をすると、良い結果が得られる」「次も何かあったら相談してみたい」と思ってもらえるようなきっかけづくりに貢献できたのではないか、と感じています。 今回の例にあるような「アジャイルな取り組み方」でなくても、もちろん良い結果を産めるような進め方は多くあると考えています。 ただ、何か進め方に困った場合は、「アジャイル」が持つ価値を参考に、自分の行動をちょっとだけ変えてみる事をオススメします。 ありたい姿を描き、そこに向かってちょっとだけ行動を変えてみる ちょっとだけ変えてみた行動の結果を観察し、そこから更にありたい姿を描く またちょっとだけ行動を変えてみる この繰り返しができてしまえば、それはもう「アジャイル」な状態と言えるでしょう。 最後に 冒頭にも書きましたが、今回の事例を見てくださった誰かが「あ、こういうのもアジャイルなんだ」「そんなに難しい話じゃないな」といった気づきを得て、それが次の新たな行動の後押しになれば、幸いです。

Introduction Hello, everyone. T.S. here, a corporate engineer in the KINTO Technologies IT Management Team. We have an IT Management Team info page here , so please take a look at that, too. In the IT Management Team, we're working hard every day to provide an IT environment that can raise the productivity of the engineering organization that is KINTO Technologies. Our internal IT environment is composed of various elements and it'd be difficult to cover everything all in one go, so in this article, I'm going to focus on device management. What is device management? Premise At KINTO Technologies, every staff member is loaned a set that includes the following: A laptop (Windows or Mac) A smartphone So, if we can understand and manage things like who the devices are being used by and what condition they're in, it'll be easier to support a pleasant development environment. What is MDM? As the premise states, all staff are using mobile devices. So, we've introduced Mobile Device Management tools. That’s right. They're generally called things like "MDM tools." What can you do with it? Essentially, MDM means tools for managing and operating mobile devices like laptops, smartphones, and tablets — e.g., managing their settings and app distribution. I imagine a lot of you might be thinking, "If that's all it's about, why do you need to work so hard to manage them?" But... KINTO Technologies doesn't have them on-site So, in terms of the SaaS* used on a daily basis for work, deciding whether devices can be trusted (i.e., are managed by the company) is a critical security issue. However, in order to make sure the development environment is always convenient as well as very secure, we need to think very carefully about which aspects of the devices we should manage, and which should be left to the users. SaaS = Software as a Service: Services that are installed on clients and used via networks such as the Internet. In terms of deciding which device aspects should be managed, which should be left up to the users, and how to not compromise convenience as a result, we pictured something like this: Seems like these should be managed Would be nice if these didn't have to be Behavior of security-related tools ・ Data leakage measures ・ Means of erasing data if the device is lost, etc. ・ Communicating with improper connection destinations ・ Asset management Applications needed for work ・ User-specific environment settings ・ Keyboards, mice, and other peripherals ・ Physical device storage and management KINTO Technologies' device management Overview The upshot is that this is what KINTO Technologies' MDM consists of: Item Service used IdP(※) Azure Active Directory Windows devices Smartphones Microsoft Intune Mac devices Jamf Pro IdP = Identity Provider: A mechanism for providing authentication services and managing account information. Challenges KINTO Technologies is in a rapid-growth phase, so lots of new staff are joining it every month. That means the number of devices is increasing at the same rate as the employees, so it's going to be extremely tough to manage them through human labor alone. So, we ended up systematizing our device management approach to solve the following issues: Time spent on device kitting Managing device information Managing application installation Controlling OS update cycles Applying encryption and managing recovery keys Remote locking and remote wiping The system we introduced Thinking about the work environment again... Work environment PCs -> Choice of Windows or Mac Smartphones -> Issued to all staff Environment -> Fully cloud-based Groupware -> Microsoft 365 Based on this, for Windows devices and smartphones, we adopted Azure Active Directory and Microsoft Intune, which are highly compatible with Microsoft 365. We could have said, "Let's manage Macs with Microsoft Intune as well, and have a fully unified MDM platform!" However, we decided to go with Jamf Pro instead, because it has a great track record with Apple products, and boasts quick syncing of settings and good flexibility in terms of management policies and items. Here's what our device management looks like: Overview of our device management Results No. Item Result 1 Time spent on device kitting → The time spent on kitting (including configuring settings) has gone down. △ 2 Managing device information → Goodbye ledgers, hello management consoles ○ 3 Managing application installation → Has changed from separate to centralized management △ 4 Controlling OS update cycles → Has changed from being the device users' responsibility to being managed centrally ○ 5 Applying encryption and managing recovery keys → Has changed from being done device by device to system-based management. We're especially glad to now have systemic key management! ○ 6 Remote locking and remote wiping → We can do them now! ○ The above results mean that we've more or less cleared the initial challenges, and should finally be able to say that we're at the starting line of device management. We want to go on improving our device management operations in order to deliver an ever better experience to all staff. Things we want to do in the future 1. Zero-touch kitting We'd like to consolidate the kitting requirements, etc., achieve zero-touch kitting, and reduce the amount onboarding time spent on the devices so that more of it can be spent on actual work. 2. Streamlining application-related operations We've achieved centralized management, but we'd like to refine these operations further so that we can respond to users in a more flexible and timely manner. 3. Managing the condition of devices We'd like to achieve detailed control and operations that address the condition of devices in (e.g.) inventory as well as of ones registered with the MDM, so that the devices can be kept in better condition. In conclusion Thank you for reading my article all the way to the end. I will continue to work hard to create an in-house IT environment that can contribute to the whole company and its business. We are hiring! KINTO Technologies is looking for people to work with us to create the future of mobility together. We also conduct informal interviews, so please feel free to contact us if you are interested. https://www.kinto-technologies.com/recruit/

Introduction Hi, this is Mori from the Global Development Group. I am usually working on the Global KINTO Web as a Product Manager and also responsible for handling personal data related tasks in Global Dev. group. KINTO offers a wide range of mobility services such as Full-Service Lease (car subscriptions), car rental services, etc. These services are available not only in Japan but also in over 30 countries worldwide, operated by affiliated companies and partners. For more information, please check out the list of our KINTO services around the world on the Global KINTO Web 🔎. Today, I would like to write a story about how we complied with personal data related laws in each country, which is crucial for expanding services globally. *Although the Global Development Group is part of KINTO Technologies, the product we develop become assets of our parent company, Toyota Financial Services Corporation . Therefore, we are handling all legal tasks as Toyota Financial Services Corporation. Background KINTO strives to provide seamless mobility experiences to our customers around the world with the brand promise of "Ever Better Mobility For All." To enable seamless access to each KINTO service separately operated in each country, we provide 'the Global KINTO ID Platform' (GKIDP), a solution to connect IDs around the world. I will skip the details of how it works in this article, but GKIDP allows users from one country (Country A) to use the services of another country (Country B) with the same ID. This means the global data transfer of personal data, such as users' names and e-mail addresses occurs across the different countries. As a side note, the definition of 'personal data' varies by country. For example, in the General Data Protection Regulation (GDPR) , 'personal data' is described as below: Article.4 (1) 'personal data' means any information relating to an identified or identifiable natural person ('data subject'); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an 3 identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person; General Data Protection Regulation Currently, strict laws related to personal data have been enacted in various countries, such as the GDPR in the European Economic Area (EEA) and the California Consumer Privacy Act (CCPA) in California, US. Also in Japan, the Amendments to the Act on the Protection of Personal Information was fully enforced in April 2022. This indicates a global trend towards strengthening personal data protection. Prominent companies have been inspected by supervisory authorities, particularly in Europe, and have been subject to substantial fines for non-compliance with regulations. Reference: The Biggest GDPR Fines of 2022 from EQS group blog Considering the above, we work to comply with personal data related laws in each country to provide GKIDP globally. GDPR Compliance and Challenges in Global Expansion: 1. Data Transfer Agreement (DTA): A Data Transfer Agreement (DTA) is an agreement that establishes the conditions for transferring personal data between jurisdictions and organizations, covering the data processing and global data transfer between signed entities. In Global KINTO, we anticipated the global transfer of personal data and have developed the "Global Data Transfer Agreement (GDTA)" framework. GDTA Components Contents Scope of the agreement The project overview and GDTA scope Role and responsibilities of each entity Role definition and responsible scope of each entities Adhension clause Provisions allowing other KINTO service providers to participate in the GDTA Annex Covering the use cases of anticipated roles and processing The entities who join the GKIDP should sign this agreement, and follow the following essential steps: ✅ Identifying the role of each entity and signing the GDTA. ✅ Evaluating the risk level of global data transfer considering use cases. ✅ Applying appropriate data transfer mechanisms. 2. Role Definitions Under the GDPR, the following definitions apply to the processing of personal data, and each entity requires appropriate contracts after defining their respective roles. Roles Definition Controller Alone or jointly with others, determines the purposes and means of the processing of personal data; Processor Processes personal data on behalf of the controller From the definition above, we consider each entity who joined GKIDP framework as Joint Controller for our case. These include: Local KINTO service providers in each countries who determines the purposes or users' personal data. Toyota Financial Services Corporation who developed and owns the GKIDP where users' personal data is stored 3. Use Cases and Data Transfer In order to transfer personal data to other countries, it is necessary to conduct assessments to check whether a country has sufficient regulations in place. As an example, in the GDPR case, countries that have been recognized by the European Commission as having adequate laws and regulations for data protection (receiving an adequacy decision), can rely on that decision as the basis for data transfer. However, for countries without such adequacy decision, it is necessary to implement measures such as signing the Standard Contractual Clauses. The GDPR provides different tools to frame data transfers from the EU to a third country: ・sometimes, a third country may be declared as offering an adequate level of protection through a European Commission decision ('Adequacy Decision'), meaning that data can be transferred to another company in that third country without the data exporter being required to provide further safeguards or being subject to additional conditions. In other words, the transfers to an 'adequate' third country will be comparable to a transmission of data within the EU. ・in the absence of an Adequacy Decision, a transfer can take place through the provision of appropriate safeguards and on condition that enforceable rights and effective legal remedies are available for individuals. Such appropriate safeguards include: in the case of a group of undertakings, or groups of companies engaged in a joint economic activity, companies can transfer personal data based on so-called binding corporate rules; ・contractual arrangements with the recipient of the personal data, using, for example, the standard contractual clauses approved by the European Commission; ・adherence to a code of conduct or certification mechanism together with obtaining binding and enforceable commitments from the recipient to apply the appropriate safeguards to protect the transferred data. ・finally, if a transfer of personal data is envisaged to a third country that isn't the subject of an Adequacy Decision and if appropriate safeguards are absent, a transfer can be made based on a number of derogations for specific situations for example, where an individual has explicitly consented to the proposed transfer after having been provided with all necessary information about the risks associated with the transfer. Reference: What rules apply if my organisation transfers data outside the EU? by European Commision Based on this rule, we classified use cases as follows. Use case Data transfer basis Entities within EEA Since there's no data transfer outside of EEA, simple participate in GDTA. Transfer from EEA to a country that has adequacy decision Adequacy decision as basis for data transfer outside of EEA. * Adequacy decisions by European Commision Transfer from EEA to a country does doesn't have adequacy decision Data can be transferred outside of EEA based on the Standard Contractual Clauses (SCC)[^1] and Transfer Impact Assessment (TIA)[^2] according to GDPR. [^1]: SCC：A set of legal provisions used to ensure that the transfer of personal data from the EEA to countries outside the EEA complies with the GDPR. It's just one mechanism that can be used for cross-border data transfers. [^2]: TIA：An assessment of the privacy protections of the laws and regulations of a recipient country outside of the EU / EEA. It could include evaluating the risk of government access, adequate protections, and the local legal framework. 4. SCC and TIA based on European GDPR For countries recognized as that they don't provide an essentially equivalent level of data protection to that within the European Economic Area (EEA) = don't have the adequacy decision, it is necessary to sign the Standard Contractual Clauses (SCC) and assess the data transfer through Transfer Impact Assessment (TIA) in order to transfer European personal data to those countries. We are working to ensure that joining entities in GKIDP understand this requirement and sign the necessary agreements accordingly, explaining the need for SCC and TIA. Let me skip the details today, but if there's opportunities, I will tell you this story in another article. Reference: Standard contractual clauses for data transfers between EU and non-EU countries Next Challenges The above 1-4 steps must be followed, and each documents should be signed before data transfer can finally take place. It took nearly a year to establish this framework and process, including drafting the actual GDTA with KINTO Italy team as a GDPR stakeholder. Going forward, we will proceed with contracts with GKIDP joining entities in accordance with these steps. The above framework was provided based on GDPR as a reference, but there may be other documents required for global data transfer between different countries. As our GKIDP collaborative services expand, we have been conducting investigations and did necessary tasks to comply with the respective laws and regulations of each country, taking into account the differences from GDPR. In order for KINTO to offer "Ever Better Mobility For All" worldwide, further GKIDP introduction into many more countries is essential. So that we will continue ensuring compliance with the regulations of each country. Conclusion When I was first assigned to this project, I was fresh out of joining the company, and until then I didn't know much about Privacy Policy, much less about GDPR. But now, I find myself working as the counterpart for personal data-related laws in Global Dev. group, answering questions from internal team members, engaging in specialized conversations with experts like the security team. This change comes from the culture at KINTO Technologies that 'values and welcomes individuals who seek knowledge themselves'. Moving forward, I aim to continue enhancing not only personal data relative knowledge but also my overall skill set within this environment. There are various articles available online about GDPR, but I have referred to the following links. They provide comprehensive and easily understandable insights. (*It's for Japanese) Of course, it's important to note that relying solely on amateur knowledge for compliance is risky, and insights from legal and security experts are crucial 👨‍⚖️ Source: 牧野総合法律事務所弁護士法人 / 合同会社LEGAL EDGE (2019) 図解入門ビジネス 最新GDPRの仕組みと対策がよ～くわかる本 個人情報保護委員会 An official website of the European Union

はじめに こんにちは！KINTOテクノロジーズ（KTC）のコーポレートITグループに所属するTKGです。 普段はコーポレートエンジニアとして「サービスデスク・オンボーディング運営」を行っています。 先日、「 KINTOテクノロジーズ MeetUp！～情シスによる情シスのための事例シェア4選～ 」というタイトルで「コーポレートIT領域に特化した、事例発表＋座談会形式の勉強会」を開催しました。 今回は、その勉強会で事例発表した内容について、補足を交えながらご紹介します！ まずは発表資料 発表資料についてはSpeaker Deckに格納しております。 KINTOとKINTOテクノロジーズのヘルプデスクが連携した（していっている）お話 - Speaker Deck テーマ選び 私は現在、KTCとKINTOの両方の籍を有しており、その両方でヘルプデスク領域を担当しております。 その中で何か発表したいと考えていたときに、親しい会社同士でどんな連携をしているのか？という事例はあまり目にした記憶がなかったので、テーマとして選びました。 正直、「映え」るようなことはしておらず、この内容を発表してもよいのだろうか。。。という葛藤はありました。 ですが、そういうネタこそ発表すべき！と自分を奮い立たせて内容をまとめていきました。 KINTOとKTCについて KINTOとKTCの連携の話。となると関係性からお伝えするべきと考えました。 両社の関係はわかりづらいな。と入社前からも入社後もずっと思っていたので、その立ち位置から説明させてもらいました。 親子会社ではなく、兄弟会社であること。また、その生い立ちについてざっくりと解説させてもらっております。 KTCはKINTO向けの開発のみをしている・・？とも思われることもありますが、親会社であるトヨタファイナンシャルサービス（TFS）向けや、一般顧客向けのアプリ（myroute、Prism Japan）の開発もしております。 IT環境は両社でかなーり異なります。 上記の簡易カオスマップ上ではKINTOもフルクラウドのように見えますが、基幹系のシステムは社内NW上にオンプレで動いております。 なお、KTCは社内NW自体ありません。各拠点は独立しております。弊社室町オフィスは7F・16Fに拠点があるのですが、それぞれ独立しております。 オンプレの機器は、各拠点のNW機器と複合機のみとなります。 両社のIT部門の構成になります。 KINTOはサービスデスク（ヘルプデスク）とインフラ管理（ITサポート）の2つに分かれているのに対して、KTC側は5つに分かれております。 今回お話するのは、私が担当しているKINTO側の「ヘルプデスク」。KTCの「Tech Service」になります。 ともにヘルプデスク業務を担っている部門になります。 KTCの各組織の役割については、それだけでも複数記事になるレベルなので、ここでは省略させてもらいます。 以上がKINTO、KTCの関係のお話になります。 エピソード1. 問い合わせの窓口に両社でJira Service Management（JSM）を導入したお話 KTCではJira Software（Jira）を利用して問い合わせの受付をしておりました。 当初はうまく回っていたのですが、従業員が増えるにつれて、従来のJiraでの運用では不具合が出てくるようになりました。 課題としてはチケットが自由記述のみで記載者・ヘルプデスク双方で負荷になっていること。ヘルプデスクでのステータス確認やセンシティブな内容の受付ができないことがありました。（問い合わせ窓口のJiraは全社員に公開されておりました） カスタムしていくことで、これらの課題解消もできたとは思うのですが、ここに工数を割くのではなく、専用のITSM（IT Service Management）ツールを導入し、よりスタッフがエンジニアリング（本来為すべき業務）に集中できる環境に近づけていく。と決まりました。 ツールについてはいろいろと比較検討もしたかったのですが、使える時間は限られていた中で、社内でAtlassian社の製品が使われており、親和性を考えてJira Service Management（JSM）を使っていくことにしました。 10ライセンスが1年間無料利用可能で検証のしやすさがあった。というのもポイントでした。 当初はKTCのみでの導入の流れではあったのですが、KINTO/KTCで連携を進めていた中でKINTOでの課題感も知り、両社で協力して進めていく流れになりました。 導入についてはKINTOから実施しました。 まず「早く勝てる」KINTOで導入・運用実績を作り、それらを活かしてKTCで展開を進めました。 KINTO導入に際しては大きな懸念もなく進められたのですが、KTCでは導入にあたって複数懸念がでてきました。 当時具体的に出てきた懸念としては、下記が上げられます。 Q1. アカウント発行、権限変更等のサービスリクエストにおいて、他のリクエストを参考にできなくなると労力がより大きくかかってしまうのでは？ A. JSMではサービスリクエストの種類ごとに最適化したフォームを作成できるため、他のリクエストを参考にする必要自体がない Q2. （全員が申請できるため）マネージャの許可なしでのサービスリクエストが発生するのではないか？ A. 発生すること自体はあるが、ヘルプデスク側で適宜マネージャに連携するようにした また、最近JSM導入についての意見を複数部署のマネージャに伺う機会を得たのですが、懸念されていたネガティブなことがなく、また自分のリクエストが見やすくなっている。として以前より格段によくなった。という評価をいただきました。 まずは導入。という状態でした。 問い合わせフォームの最適化は適宜進めており、フォーム内の「やってみたらいらない項目だった」を削除したり、一括申請を作成したりと改善を進めております。 また、この中で「ナレッジベースの拡充」をトップに上げていただのですが、問い合わせの分析をしている中で、ナレッジベースが特に必要となるインシデント関係の問い合わせより、サービスリクエストのほうが比重が大きい。ということがわかりました。 これは、KTCは技術者集団でITリテラシーが高いことに起因しているのではないか？と想像します。 そのため、自分で解決できるインシデント系よりも自分で完結できない（＝管理者しか行えない）サービスリクエストの比重が大きくなっているのだと思います。 現在は、サービスリクエストを減らす。より早く処理できるようにする。ことに注力をしております。 Episode.2 KINTOのPCリプレースをKTCのノウハウ使ってコスト削減したり便利にした（していってる）お話 KTCではキッティングは基本アウトソーシングを利用しております。 ですが、急に入場が決まることもあり、MDMを利用したキッティングの自動化を進めております。 多いと月に20名超入場することも！ このあたりの効率化の詳細は下記の発表資料を参照ください。 Windowsキッティング自動化のススメ - Speaker Deck 対してKINTOでは、ベンダーにイメージ展開からの初期的なキッティングを実施してもらい、その後に個別のアプリインストール等行っておりました。 Intuneを利用しての設定等すでに進めていたところもあるのですが、さらなる効率化についてはきっかけがない状態でもありました。 そんなときに、KINTO PCの大規模リプレース案件を進めることになり、KTCとより強く協力して効率化を進めていくこととなりました。 KINTO/KTCで協力しながら過去資料を見直すことで、今までは手作業が必要な部分を廃止したり、手動での設定をIntune代替しました。 その結果、ベンダーに依頼していたイメージ作成対応が不要となり、効率化を実現できました。 効率化について進んで来たところではあるのですが、まだまだ効率化の余地はあると考えております。 KTCとは環境が違うため、「ゼロタッチ」までの距離はだいぶ遠そうですが、少しづつでも改善し、「ちょいタッチ」まで進めていきたいと考えております。 最後に：先人への感謝は忘れず KINTO/KTCはともに創業から数年しか経っていない状態で、急造で環境を整える必要がありました。 当時の方々は、創業の混乱の中で、その時のベターを選択して積み重ねてきましたのは疑いの余地もありません。 環境も変わってきた中で、きっかけがあり改善がうまくできたのが今回取り上げた事例となります。 KINTO/KTCはおたがいに、まだまだ整っていないところも多く、改善の余地は両社でも大きくあります。 われこそは！という方がおりましたら、ぜひぜひJoinして、ともにKINTO/KTCのIT環境をよりよくし、スタッフがエンジニアリング以外に時間を取られない、最高のパフォーマンスを発揮できる場にしていきましょう！

はじめに こんにちは！KINTOテクノロジーズ（KTC）のコーポレートITグループに所属するTKGです。 普段はコーポレートエンジニアとして「サービスデスク・オンボーディング運営」を行っています。 先日、「 KINTOテクノロジーズ MeetUp！～情シスによる情シスのための事例シェア4選～ 」というタイトルで「コーポレートIT領域に特化した、事例発表＋座談会形式の勉強会」を開催しました。 今回は、その勉強会で事例発表した内容について、補足を交えながらご紹介します！ まずは発表資料 発表資料についてはSpeaker Deckに格納しております。 KINTOとKINTOテクノロジーズのヘルプデスクが連携した（していっている）お話 - Speaker Deck テーマ選び 私は現在、KTCとKINTOの両方の籍を有しており、その両方でヘルプデスク領域を担当しております。 その中で何か発表したいと考えていたときに、親しい会社同士でどんな連携をしているのか？という事例はあまり目にした記憶がなかったので、テーマとして選びました。 正直、「映え」るようなことはしておらず、この内容を発表してもよいのだろうか。。。という葛藤はありました。 ですが、そういうネタこそ発表すべき！と自分を奮い立たせて内容をまとめていきました。 KINTOとKTCについて KINTOとKTCの連携の話。となると関係性からお伝えするべきと考えました。 両社の関係はわかりづらいな。と入社前からも入社後もずっと思っていたので、その立ち位置から説明させてもらいました。 親子会社ではなく、兄弟会社であること。また、その生い立ちについてざっくりと解説させてもらっております。 KTCはKINTO向けの開発のみをしている・・？とも思われることもありますが、親会社であるトヨタファイナンシャルサービス（TFS）向けや、一般顧客向けのアプリ（myroute、Prism Japan）の開発もしております。 IT環境は両社でかなーり異なります。 上記の簡易カオスマップ上ではKINTOもフルクラウドのように見えますが、基幹系のシステムは社内NW上にオンプレで動いております。 なお、KTCは社内NW自体ありません。各拠点は独立しております。弊社室町オフィスは7F・16Fに拠点があるのですが、それぞれ独立しております。 オンプレの機器は、各拠点のNW機器と複合機のみとなります。 両社のIT部門の構成になります。 KINTOはサービスデスク（ヘルプデスク）とインフラ管理（ITサポート）の2つに分かれているのに対して、KTC側は5つに分かれております。 今回お話するのは、私が担当しているKINTO側の「ヘルプデスク」。KTCの「Tech Service」になります。 ともにヘルプデスク業務を担っている部門になります。 KTCの各組織の役割については、それだけでも複数記事になるレベルなので、ここでは省略させてもらいます。 以上がKINTO、KTCの関係のお話になります。 エピソード1. 問い合わせの窓口に両社でJira Service Management（JSM）を導入したお話 KTCではJira Software（Jira）を利用して問い合わせの受付をしておりました。 当初はうまく回っていたのですが、従業員が増えるにつれて、従来のJiraでの運用では不具合が出てくるようになりました。 課題としてはチケットが自由記述のみで記載者・ヘルプデスク双方で負荷になっていること。ヘルプデスクでのステータス確認やセンシティブな内容の受付ができないことがありました。（問い合わせ窓口のJiraは全社員に公開されておりました） カスタムしていくことで、これらの課題解消もできたとは思うのですが、ここに工数を割くのではなく、専用のITSM（IT Service Management）ツールを導入し、よりスタッフがエンジニアリング（本来為すべき業務）に集中できる環境に近づけていく。と決まりました。 ツールについてはいろいろと比較検討もしたかったのですが、使える時間は限られていた中で、社内でAtlassian社の製品が使われており、親和性を考えてJira Service Management（JSM）を使っていくことにしました。 10ライセンスが1年間無料利用可能で検証のしやすさがあった。というのもポイントでした。 当初はKTCのみでの導入の流れではあったのですが、KINTO/KTCで連携を進めていた中でKINTOでの課題感も知り、両社で協力して進めていく流れになりました。 導入についてはKINTOから実施しました。 まず「早く勝てる」KINTOで導入・運用実績を作り、それらを活かしてKTCで展開を進めました。 KINTO導入に際しては大きな懸念もなく進められたのですが、KTCでは導入にあたって複数懸念がでてきました。 当時具体的に出てきた懸念としては、下記が上げられます。 Q1. アカウント発行、権限変更等のサービスリクエストにおいて、他のリクエストを参考にできなくなると労力がより大きくかかってしまうのでは？ A. JSMではサービスリクエストの種類ごとに最適化したフォームを作成できるため、他のリクエストを参考にする必要自体がない Q2. （全員が申請できるため）マネージャの許可なしでのサービスリクエストが発生するのではないか？ A. 発生すること自体はあるが、ヘルプデスク側で適宜マネージャに連携するようにした また、最近JSM導入についての意見を複数部署のマネージャに伺う機会を得たのですが、懸念されていたネガティブなことがなく、また自分のリクエストが見やすくなっている。として以前より格段によくなった。という評価をいただきました。 まずは導入。という状態でした。 問い合わせフォームの最適化は適宜進めており、フォーム内の「やってみたらいらない項目だった」を削除したり、一括申請を作成したりと改善を進めております。 また、この中で「ナレッジベースの拡充」をトップに上げていただのですが、問い合わせの分析をしている中で、ナレッジベースが特に必要となるインシデント関係の問い合わせより、サービスリクエストのほうが比重が大きい。ということがわかりました。 これは、KTCは技術者集団でITリテラシーが高いことに起因しているのではないか？と想像します。 そのため、自分で解決できるインシデント系よりも自分で完結できない（＝管理者しか行えない）サービスリクエストの比重が大きくなっているのだと思います。 現在は、サービスリクエストを減らす。より早く処理できるようにする。ことに注力をしております。 Episode.2 KINTOのPCリプレースをKTCのノウハウ使ってコスト削減したり便利にした（していってる）お話 KTCではキッティングは基本アウトソーシングを利用しております。 ですが、急に入場が決まることもあり、MDMを利用したキッティングの自動化を進めております。 多いと月に20名超入場することも！ このあたりの効率化の詳細は下記の発表資料を参照ください。 Windowsキッティング自動化のススメ - Speaker Deck 対してKINTOでは、ベンダーにイメージ展開からの初期的なキッティングを実施してもらい、その後に個別のアプリインストール等行っておりました。 Intuneを利用しての設定等すでに進めていたところもあるのですが、さらなる効率化についてはきっかけがない状態でもありました。 そんなときに、KINTO PCの大規模リプレース案件を進めることになり、KTCとより強く協力して効率化を進めていくこととなりました。 KINTO/KTCで協力しながら過去資料を見直すことで、今までは手作業が必要な部分を廃止したり、手動での設定をIntune代替しました。 その結果、ベンダーに依頼していたイメージ作成対応が不要となり、効率化を実現できました。 効率化について進んで来たところではあるのですが、まだまだ効率化の余地はあると考えております。 KTCとは環境が違うため、「ゼロタッチ」までの距離はだいぶ遠そうですが、少しづつでも改善し、「ちょいタッチ」まで進めていきたいと考えております。 最後に：先人への感謝は忘れず KINTO/KTCはともに創業から数年しか経っていない状態で、急造で環境を整える必要がありました。 当時の方々は、創業の混乱の中で、その時のベターを選択して積み重ねてきましたのは疑いの余地もありません。 環境も変わってきた中で、きっかけがあり改善がうまくできたのが今回取り上げた事例となります。 KINTO/KTCはおたがいに、まだまだ整っていないところも多く、改善の余地は両社でも大きくあります。 われこそは！という方がおりましたら、ぜひぜひJoinして、ともにKINTO/KTCのIT環境をよりよくし、スタッフがエンジニアリング以外に時間を取られない、最高のパフォーマンスを発揮できる場にしていきましょう！

はじめに こんにちは！KINTOテクノロジーズ（KTC）のコーポレートITグループに所属するTKGです。 普段はコーポレートエンジニアとして「サービスデスク・オンボーディング運営」を行っています。 先日、「 KINTOテクノロジーズ MeetUp！～情シスによる情シスのための事例シェア4選～ 」というタイトルで「コーポレートIT領域に特化した、事例発表＋座談会形式の勉強会」を開催しました。 今回は、その勉強会で事例発表した内容について、補足を交えながらご紹介します！ まずは発表資料 発表資料についてはSpeaker Deckに格納しております。 KINTOとKINTOテクノロジーズのヘルプデスクが連携した（していっている）お話 - Speaker Deck テーマ選び 私は現在、KTCとKINTOの両方の籍を有しており、その両方でヘルプデスク領域を担当しております。 その中で何か発表したいと考えていたときに、親しい会社同士でどんな連携をしているのか？という事例はあまり目にした記憶がなかったので、テーマとして選びました。 正直、「映え」るようなことはしておらず、この内容を発表してもよいのだろうか。。。という葛藤はありました。 ですが、そういうネタこそ発表すべき！と自分を奮い立たせて内容をまとめていきました。 KINTOとKTCについて KINTOとKTCの連携の話。となると関係性からお伝えするべきと考えました。 両社の関係はわかりづらいな。と入社前からも入社後もずっと思っていたので、その立ち位置から説明させてもらいました。 親子会社ではなく、兄弟会社であること。また、その生い立ちについてざっくりと解説させてもらっております。 KTCはKINTO向けの開発のみをしている・・？とも思われることもありますが、親会社であるトヨタファイナンシャルサービス（TFS）向けや、一般顧客向けのアプリ（myroute、Prism Japan）の開発もしております。 IT環境は両社でかなーり異なります。 上記の簡易カオスマップ上ではKINTOもフルクラウドのように見えますが、基幹系のシステムは社内NW上にオンプレで動いております。 なお、KTCは社内NW自体ありません。各拠点は独立しております。弊社室町オフィスは7F・16Fに拠点があるのですが、それぞれ独立しております。 オンプレの機器は、各拠点のNW機器と複合機のみとなります。 両社のIT部門の構成になります。 KINTOはサービスデスク（ヘルプデスク）とインフラ管理（ITサポート）の2つに分かれているのに対して、KTC側は5つに分かれております。 今回お話するのは、私が担当しているKINTO側の「ヘルプデスク」。KTCの「Tech Service」になります。 ともにヘルプデスク業務を担っている部門になります。 KTCの各組織の役割については、それだけでも複数記事になるレベルなので、ここでは省略させてもらいます。 以上がKINTO、KTCの関係のお話になります。 エピソード1. 問い合わせの窓口に両社でJira Service Management（JSM）を導入したお話 KTCではJira Software（Jira）を利用して問い合わせの受付をしておりました。 当初はうまく回っていたのですが、従業員が増えるにつれて、従来のJiraでの運用では不具合が出てくるようになりました。 課題としてはチケットが自由記述のみで記載者・ヘルプデスク双方で負荷になっていること。ヘルプデスクでのステータス確認やセンシティブな内容の受付ができないことがありました。（問い合わせ窓口のJiraは全社員に公開されておりました） カスタムしていくことで、これらの課題解消もできたとは思うのですが、ここに工数を割くのではなく、専用のITSM（IT Service Management）ツールを導入し、よりスタッフがエンジニアリング（本来為すべき業務）に集中できる環境に近づけていく。と決まりました。 ツールについてはいろいろと比較検討もしたかったのですが、使える時間は限られていた中で、社内でAtlassian社の製品が使われており、親和性を考えてJira Service Management（JSM）を使っていくことにしました。 10ライセンスが1年間無料利用可能で検証のしやすさがあった。というのもポイントでした。 当初はKTCのみでの導入の流れではあったのですが、KINTO/KTCで連携を進めていた中でKINTOでの課題感も知り、両社で協力して進めていく流れになりました。 導入についてはKINTOから実施しました。 まず「早く勝てる」KINTOで導入・運用実績を作り、それらを活かしてKTCで展開を進めました。 KINTO導入に際しては大きな懸念もなく進められたのですが、KTCでは導入にあたって複数懸念がでてきました。 当時具体的に出てきた懸念としては、下記が上げられます。 Q1. アカウント発行、権限変更等のサービスリクエストにおいて、他のリクエストを参考にできなくなると労力がより大きくかかってしまうのでは？ A. JSMではサービスリクエストの種類ごとに最適化したフォームを作成できるため、他のリクエストを参考にする必要自体がない Q2. （全員が申請できるため）マネージャの許可なしでのサービスリクエストが発生するのではないか？ A. 発生すること自体はあるが、ヘルプデスク側で適宜マネージャに連携するようにした また、最近JSM導入についての意見を複数部署のマネージャに伺う機会を得たのですが、懸念されていたネガティブなことがなく、また自分のリクエストが見やすくなっている。として以前より格段によくなった。という評価をいただきました。 まずは導入。という状態でした。 問い合わせフォームの最適化は適宜進めており、フォーム内の「やってみたらいらない項目だった」を削除したり、一括申請を作成したりと改善を進めております。 また、この中で「ナレッジベースの拡充」をトップに上げていただのですが、問い合わせの分析をしている中で、ナレッジベースが特に必要となるインシデント関係の問い合わせより、サービスリクエストのほうが比重が大きい。ということがわかりました。 これは、KTCは技術者集団でITリテラシーが高いことに起因しているのではないか？と想像します。 そのため、自分で解決できるインシデント系よりも自分で完結できない（＝管理者しか行えない）サービスリクエストの比重が大きくなっているのだと思います。 現在は、サービスリクエストを減らす。より早く処理できるようにする。ことに注力をしております。 Episode.2 KINTOのPCリプレースをKTCのノウハウ使ってコスト削減したり便利にした（していってる）お話 KTCではキッティングは基本アウトソーシングを利用しております。 ですが、急に入場が決まることもあり、MDMを利用したキッティングの自動化を進めております。 多いと月に20名超入場することも！ このあたりの効率化の詳細は下記の発表資料を参照ください。 Windowsキッティング自動化のススメ - Speaker Deck 対してKINTOでは、ベンダーにイメージ展開からの初期的なキッティングを実施してもらい、その後に個別のアプリインストール等行っておりました。 Intuneを利用しての設定等すでに進めていたところもあるのですが、さらなる効率化についてはきっかけがない状態でもありました。 そんなときに、KINTO PCの大規模リプレース案件を進めることになり、KTCとより強く協力して効率化を進めていくこととなりました。 KINTO/KTCで協力しながら過去資料を見直すことで、今までは手作業が必要な部分を廃止したり、手動での設定をIntune代替しました。 その結果、ベンダーに依頼していたイメージ作成対応が不要となり、効率化を実現できました。 効率化について進んで来たところではあるのですが、まだまだ効率化の余地はあると考えております。 KTCとは環境が違うため、「ゼロタッチ」までの距離はだいぶ遠そうですが、少しづつでも改善し、「ちょいタッチ」まで進めていきたいと考えております。 最後に：先人への感謝は忘れず KINTO/KTCはともに創業から数年しか経っていない状態で、急造で環境を整える必要がありました。 当時の方々は、創業の混乱の中で、その時のベターを選択して積み重ねてきましたのは疑いの余地もありません。 環境も変わってきた中で、きっかけがあり改善がうまくできたのが今回取り上げた事例となります。 KINTO/KTCはおたがいに、まだまだ整っていないところも多く、改善の余地は両社でも大きくあります。 われこそは！という方がおりましたら、ぜひぜひJoinして、ともにKINTO/KTCのIT環境をよりよくし、スタッフがエンジニアリング以外に時間を取られない、最高のパフォーマンスを発揮できる場にしていきましょう！

Hello, Tada here from the Cloud Center of Excellence (CCoE) team in the KINTO Technologies Platform Group. The CCoE team's mission is to make mobility product development more agile and secure by actively pursuing cloud-based system development and governance-based control. CCoE at KINTO Technologies CCoE activities Based on the above mission, the CCoE team is pursuing numerous measures as an organization responsible for providing a broad range of support for making use of clouds and controlling the use of them. Let me tell you about some of the main ones. Making use of clouds In order to continuously support efficient development through knowledge sharing and HR development , we're pursuing the following: Cloud-related HR development Improve engineers' skills through study sessions and educational content that use KINTO Technologies' unique AWS skill map. Controlling the use of clouds In order to provide cloud environments that comply with group company security policies and to provide support to maintain security at all times , we're pursuing the following: Cloud security guidelines Pursue IaC development and security tools for compliance with security policies. Security preset cloud environments Provide cloud environments that are preconfigured in accordance with the above security guidelines. Here's a simple picture of what we do. We provide cloud environments that are preconfigured mainly based on the cloud security guidelines, and get the development groups to make use of them. To keep these cloud environments secure, we monitor them using SIEM (Security Information and Event Management) and CSPM (Cloud Security Posture Management). We also use the security guidelines for HR development, information sharing sites, etc. Information about security gets updated daily, and cloud services are constantly evolving, too. So to keep up with these changes, we're aiming for sustainable activities with the guidelines at their core. Now I'll tell you about something we're currently pursuing as a means of supporting controlling the use of clouds: security preset cloud environments (Google Cloud). Working on creating security preset cloud environments (Google Cloud) What are security preset cloud environments (Google Cloud)? Security preset cloud environments are something we're developing as a way to encourage agile development by achieving both agility and security. Our company aims to let its development groups freely utilize cloud environments, so the idea is to impose the minimal restrictions needed to prevent undesirable uses. So, what kinds of specific security do we set? Well, the following 2 security standards are our basic ones: CIS Benchmarks Group companies' security rules And where do we set them? Well, the following 3 places: Organization policies Projects (Set when we create them) CSPM (Cloud Security Posture Management) In the sections below, I'll give you the specifics about the security settings we use in each place. What security have we set in organization policies? We use organization policies to impose the minimal restrictions needed to prevent undesirable uses. This is the same as the concept called preventive guardrails. Preventive guardrails are a collective term for mechanisms and rules that prevent undesirable behavior and risks by providing preemptive constraints and restrictions on systems and processes. They can minimize the risk of security issues and compliance violations due to human error or unintentional acts. For the security preset cloud environments, we aim to keep restrictions to the minimum needed to prevent undesirable uses, so that they won't be too strict. We use the 2 security standards mentioned above as the basis for deciding what that minimum will be. Below are some organization policies we've actually put in place. | Organization policy | Description | ---- | ---- | | constraints/GCP.resourceLocations | Limit the locations where resources can be created. Set multiple regions, including Asia. | | constraints/SQL.restrictPublicIp | Restrict public access to Cloud SQL instances. | | constraints/storage.publicAccessPrevention | Restrict public disclosure of data in Cloud Storage. | | constraints/compute.skipDefaultNetworkCreation | Restrict the creation of default networks and related resources when creating resources. | | constraints/iam.disableAuditLoggingExemption | Restrict principal exclusion settings from audit logs. | These organization policies are set for organizations as a whole, and the same policies are inherited by folders and projects. If it so happens that they can't be accepted on the project side, the project-specific policy will override them. What security have we set when creating projects? We can't set them in an organization policy, but if we want to set rules that will function as preventive guardrails, we set them when creating projects. For example, in "2. Logging and Monitoring" in the CIS Benchmarks , there's a rule "2.13 Ensure Cloud Asset Inventory is Enabled" that we use to automatically activate the Cloud Asset Inventory when a project is created. Here are some of the other CIS Benchmark rules we set when creating projects. | Item | Title | Description | | ---- | ---- | ---- | | 2.4 | Ensure Log Metric Filter and Alerts Exist for Project Ownership Assignments/Changes | Monitor and give alerts about project owner assignment. | | 2.5 | Ensure That the Log Metric Filter and Alerts Exist for Audit Configuration Changes | Monitor and give alerts about changes to audit settings. | | 2.6 | Ensure That the Log Metric Filter and Alerts Exist for Custom Role Changes | Project owners, organization role administrators, and IAM role administrators can create custom roles. Monitor and give alerts about creating custom roles, because they can end up with excessive permissions. | | 2.7 | Ensure That the Log Metric Filter and Alerts Exist for VPC Network Firewall Rule Changes | Monitor and give alerts about the creation or updating of firewall rules. | | 2.8 | Ensure That the Log Metric Filter and Alerts Exist for VPC Network Route Changes | Monitor and give alerts about VPC network route changes. | | 2.9 | Ensure That the Log Metric Filter and Alerts Exist for VPC Network Changes | Monitor and give alerts about VPC network changes. | | 2.10 | Ensure That the Log Metric Filter and Alerts Exist for Cloud Storage IAM Permission Changes | Monitor and give alerts about Cloud Storage IAM permission changes. | | 2.11 | Ensure That the Log Metric Filter and Alerts Exist for SQL Instance Configuration Changes | Monitor and give alerts about SQL instance configuration changes. | Also, although we don't set the following CIS Benchmark rule when creating projects, we do set it for organizations as a whole: | Item | Title | Description | | ---- | ---- | ---- | | 2.1 | Ensure That Cloud Audit Logging Is Configured Properly | Configure audit logging to track all activity and read and write access to user data. | What security have we set via CSPM? Now I'll explain the security we've achieved though CSPM (Cloud Security Posture Management). CSPM is used to detect and give alerts about risky operations in ways that can't be set when creating projects or in organization policies . This is the same as the concept of detective guardrails. Detective guardrails are mechanisms and rules for early detection of abnormal activity and security risks in systems and processes, and focus on detecting and analyzing incidents and abnormal activity. Preventive guardrails and detective guardrails play complementary roles. With our security preset cloud environments, based on the concept of detective guardrails, we're achieving risk detection and alerts using a CSPM product, but there were some twists and turns along the way when selecting which one to use. Which CSPM product have we adopted? Cloud Security Posture Management (CSPM) is a tool for the following: monitoring the security settings and configuration for the resources in cloud environments; and assessing and managing compliance with policies and guidelines based on best practice. Google Cloud has a service called Security Command Center , which has 2 tiers: Standard and Premium. | | Standard | Premium | | ---- |:----:|:----:| | Security Health Analytics (Including identifying critical configuration errors) | ○ | ○ | | Security Health Analytics (PCI, CIS, compliance reports, etc.) | X | ○ | | Web Security Scanner | X | ○ | | Event Threat Detection | X | ○ | | Container Threat Detection | X | ○ | | Virtual Machine Threat Detection | X | ○ | | Rapid Vulnerability Detection | X | ○ | | Cost | Free | Subscription | In our case, we wanted to achieve detective guardrails based on the CIS Benchmarks and other standards, so we opted to use Premium based on our requirements, but it's very costly and doesn't fit the current scale of our Google Cloud usage. For the CSPM product, we picked up a few candidates based on the points below, then conducted desk-checks and proof-of-concept tests. We can use the CIS Benchmarks and other compliance standards. We can also implement our own rules. It's cheap (compared to Security Command Center Premium). The main products and evaluation comments are as follows: Forseti Security (Open-source security tools for GCP) Collects inventory information for Google Cloud resources and checks the auditing rules on a regular basis. The auditing rules available include IAM Policy, Bucket ACL, BigQuery Dataset ACL, and Cloud SQL Network. The CIS and other compliance standards can’t be used. Cloud Custodian (OSS) There's no default rule set for the CIS and other compliance standards, so we'd need to implement each rule from scratch. Third-party product (from Company S) The CIS and other compliance standards are prepared by default, and our own rules can also be implemented with Rego . It's a SaaS product, but is very cheap, and is available to buy from the marketplace. Based on these findings, we decided to adopt the third-party product (from Company S). We vacillated over whether to go for Cloud Custodian, but decided in the end to prioritize speedy product integration and rule implementation. I'd like to write a blog article with more specifics on how we're using this product sometime, but for now, I'll just say that we're working to stay secure by introducing a CSPM product, detecting risky operations based on the CIS Benchmarks , etc., and continually making improvements. :::message Actually, around February this year, it became possible to use Security Command Center Premium for individual projects rather than for whole organizations, making it easier to adopt in terms of cost as well. Premium has many other features besides CSPM, so I want to think about effective ways to juggle using it and the third-party product. ::: What are we doing about IAM permissions? There's one more important thing I want to talk about: the issue of what to do about the IAM permissions for projects sent out to the development groups. In short, users are granted editor permissions. Of course, we're well aware that granting editor permissions is bad practice, but we do it as a trade-off between security and convenience for the development groups. So, we start with these permissions. Instead of this, we're moving toward thoroughly using the Policy Intelligence tools and operating under the principle of minimal permissions. I'd like to write a blog article on this as well sometime. Summary The following points give a summary of security preset cloud environments: They provide cloud environments that development groups can freely make use of, with only the minimal restrictions needed to prevent undesirable uses. They incorporate the concepts of preventive and detective guardrails. Preventive guardrails are achieved by using organization policies , and detective ones by using a CSPM product. In terms of IAM permissions, Policy Intelligence tools are used to thoroughly ensure that operations approach the principle of having the minimal permissions possible. Future CCoE activities Finally, I'd like to touch on our future CCoE activities. I talked about security preset environments for Google Cloud above, but we're preparing ones for AWS as well based on the same concepts. In addition, in order to keep the security preset environments secure, we're considering enhancing our security monitoring services and tools. I also talked a little about CSPM, but besides that, we're also working on developing other tools in an area called CNAPPs (Cloud Native Application Protection Platforms). Also, with the X.1060 framework gradually becoming more prominent these days, we plan to use it to continuously improve our organizational ability to respond to security issues. If I get the chance, I'd like to talk about this more as well sometime. Thank you for reading my article all the way to the end.