はじめに KINTOテクノロジーズでグローバルグループのモバイルアプリ開発を担当している、謝堯（Yao Xie）、方茂碩（Mooseok Bahng)です。 現在、 Global KINTO App というアプリの開発を担当しています。Global KINTO App (GKA)は「世界中のKINTOサービスを1つのアプリでつなぐ」というコンセプトを持たせたモバイルアプリです。現時点ではタイとカタールのKINTOサービスが実装されています。 既存のアプリのかわりになるプロジェクトを進めている中で、Kotlin Multiplatform Mobile (以下 KMM)の導入を決めましたので、今回お話します。 KMMの導入を決めた背景 KMMの導入を決めた背景には次のような課題がありました。 どうしてもiOSとAndroidの間に Business Logicの実装の差が発生する。 開発チームが物理的に2ヶ所に別れていて、開発の効率が落ちる場合がある。-> チームを KMMとNativeに分けることで改善できると思った。 開発リソースが限られているため、効率的な開発体制を構築したい。 その結果、KMMを検討することになりました。 Kotlin Multiplatform Mobile (KMM)とは KMMは iOS, Androidアプリを開発するためのSDKで、基本言語は Kotlinで、Cross-Platformと Nativeアプリのいいところ取りをしています。 KMMで共通のビジネスロジックを開発して、プラットフォーム依存性がある UIはそれぞれ Nativeで開発できます。 個人的にはそれぞれのOSに最適なUIを提供することが一番いいUI/UXだと思っています。 KMMはUIは基本それぞれの Nativeで開発するため、KMMはUIは基本それぞれの Nativeで開発するため、UI/UXの最適化ができ、iOS, Androidとの依存性が少なく、バージョンアップの影響もほとんどないと思っています。 KMMはまだまだ新しい技術で、十分に成熟してないですが、近年いろいろな会社で使われている状況です。 Kotlin Multiplatform Mobile (source: https://kotlinlang.org/lp/mobile ) Architecture KMMについて説明する前に、現在開発チームで採用しているアーキテクチャーについて説明します。 基本的にMVVMを採用して開発しています。KMMを導入しても基本この方針には変更はありません。 ここで、どこまでKMMに含めるかが悩みでした。選択肢は三つぐらい考えられます。 KMM Native Option 1 Repository, Usecase, View Model UI Option 2 Repository, Usecase View Model, UI Option 3 Repository Usecase, View Model, UI 色々試してみましたが、今のところはView ModelまでKMMにする方向に進んでいます。View Modelは除外することも検討してみましたが、せっかくKMMを導入したのに View Modelを別々にする理由が見つかりませんでした。データをリストに表示するだけなどの簡単なフィーチャーについては特にそうです。 これから複雑な機能が追加されると、View Modelを別にする必要があるかもしれません。その時は一部だけView Modelを別々にしたりすることも考えられます。 iOSのCodebaseはかなりコンパクトになりました。Domain LayerとView ModelまでKMMを使っているので、UIとプラットフォーム依存のあるハードウェア関連の機能だけになり、ソースコードの量は半分以下になるのではと思っています。。 下記はFAQリストを表示する簡単な画面のiOS側の実装になります。共通のUI Utility Classを除くとこれで終わりです。 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()) } ) } } メリット Single Codebase iOS, Androidのネットワーキング、データストレージ、ビジネスロジックなどを Single Codebaseで管理することができます。 Consistency ビジネスロジックを共有するため、基本的に同じUXを提供することができます。 Efficiency KMMの導入によって効率的な開発ができるようになりました。半分に近いタイムコストをカットすることによって、その分、ソースコードの最適化やビジネスの展開に時間を使うことができるようになりました。 Expandable iOS, Androidだけではなく、必要によっては他のプラットフォームにも簡単に拡張することができます。 デメリット iOSのデバッグは別途のpluginのインストールが必要となります。 XCframeworkを適用する場合、Apple Siliconの Macで Simulatorを使うとarm64を参照するため、エラーになります。これは KMM SDK側の修正が必要だと思いますが、暫定的には excluded architectureに arm64を追加するか、x-codeを rosettaモードで実行すると simulatorも使えるようになります。 iOSへの配布方法 Build & Sourcesets Build XCFrameworks KMMの今までのiOSへの配布は Universal (FAT) frameworkが基本でした。最近、やっと公式にXCFrameworkをサポートすることになりましたので、XCFrameworkを採用する予定です。 https://kotlinlang.org/docs/multiplatform-build-native-binaries.html#build-xcframeworks その他 KMMと直接関係はないですが、下記の新しい技術も導入を検討しています。 Ktor 両方のClientに対して同じConfigurationをセットすることができます。 API Requestコードは共通です。 iOS, Androidのエンジンは別々ですが、追加のコードはいらないです。 Apollo Client 既存のプロジェクトではGraphQL APIも一部採用しています。GraphQLのために Apollo Clientの導入を検討しています。 Backendの schema.graphqlsを使い、Queries.graphqlを作成するだけで、Models, Adapters, Queriesが自動生成されます。 https://github.com/apollographql/apollo-kotlin MMKV MMKVはモバイル key-value storage frameworkです。もちろん、Android, iOSを含めて、マルチプラットフォームに対応しています。 https://github.com/Tencent/MMKV https://github.com/ctripcorp/mmkv-kotlin MMKV-Kotlinで MMKVを簡単に私たちのプルジェクトにインテグレートすることができ、shared moduleで key-value storageを管理することができるようになります。 Performance comparison on Android Performance comparison on iOS 今後の展開 Fast growing KMM ecosystems KMMは JetBrainsによって開発されています。Android Studioでシームレスに開発でき、Xcodeも一部対応しています。 開発者の中で広がってきており、KMMのためのオープンソースライブラリがたくさん存在します。 https://github.com/terrakok/kmm-awesome Cross-platform UI Touchlabはすでに Compose UIを iOS、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は公式に cross-platform UIをサポートするようになるかもしれません。 まとめ ここまでKMMの導入について説明しました。 KMMの導入によって下記の改善が期待できるようになりました。 iOSとAndroidの間のビジネスロジックの実装の差を最小限に抑制することができる。 必要によっては、開発チームの構成の最適化ができる。 ある程度開発工数を減らすことができる。 まだまだKMM導入の初期段階なので、課題にたくさん直面し、どんどんノウハウが蓄積するので、進捗があり次第また共有します。 ありがとうございました。

はじめに CIO室 CIOサポートチームの春田です。普段は文字通りCIO景山のサポートとともに主に KINTOテクノロジーズ 全体の財務・法務管理を担当しています。 私たちのチームはKINTOテクノロジーズ全社のバックオフィス業務を担うポジションとして、社内の決裁手続きや取引先様との受発注の調整、社内外の経費精算、請求および支払手続きなど幅広いバックオフィス業務を担っております。 同じくCIO室 CIOサポートチームの北川です。私の担当はパートナーエンジニアの採用窓口で、開発エンジニアをサポートするパートナーエンジニアを日々探しています。私たちのチームは、組織開発、コミュニケーション活性化を担当するメンバーや外国籍スタッフのサポートに注力するメンバーなどもいるという、混成チームと言えます。 今回の記事は当社バックオフィス業務と本チームが実践している開発グループへのサポート内容のご紹介です。 背景 KINTOテクノロジーズが開発したシステムは、親会社である トヨタファイナンシャルサービス株式会社 のアセットとなり、トヨタファイナンシャルサービスから 株式会社KINTO へ利用提供しています。 KINTO：KINTOサービスのビジネスオーナー兼システム利用ユーザー KINTOテクノロジーズ：KINTOサービスにかかるシステム開発運用担当 トヨタファイナンシャルサービス：KINTOサービスにかかるシステム全般のオーナー 上記の通り三社がそれぞれの立場・役割で関わるため、商流および契約面などで複雑化する中、CIOサポートチームはKINTOテクノロジーズの所属としてKINTOテクノロジーズのバックオフィス業務の対応に加えて、一部のメンバーはその他二社を兼務することで、三社間の調整・手続きをよりスピーディかつ正確に処理できるように立ち回っています。 その結果、事務手続きによる開発着手の停滞・遅れを防ぎ、事務手続きの高速化ならびに現場のシステム開発の早期化につながっています。 CIOサポートチームの取組み 1. エンジニアの「めんどくさい」を無くしたい！ 通常の会社では、新たなプロジェクトが立ち上がった際に、担当する開発グループで稟議・決裁を起票し、開発エンジニアが社内で事前説明のスタンプラリーや承認会議などを経て社内承認となり、やっと開発着手となるケースが多いと思います。 当社においても、決裁権限規程に沿って、承認会議を介する決裁はありますが、全決裁の約95%が1～2回の承認ステップで決裁完了します。 しかも、その決裁の作成から起票～回付～承認後の保管まで一環の作業のほとんどを、CIOサポートチームにて一括して対応する体制を整えており、開発エンジニアには開発に専念できる環境を提供しています。 ちなみに、稟議決裁を例にあげましたが契約や知財管理も同様で、例えば外部委託の新規契約の場合「新規に〇〇社と契約したい」とエンジニアサイドから連絡を受ければ代行して相手方との調整を行い、契約締結までCIOサポートで対応するなどエンジニアファーストな組織作りを目指しています。 2. トヨタ生産方式を意識した業務設計 トヨタグループであるKINTOテクノロジーズでは、生産フローの中で徹底してムダを省くトヨタ生産方式を意識し、まだまだ道半ばですが社内の業務フローを組み立るようにしています。例えば、ヒューマンエラーの発生時には問題の真因が判明するまで一旦作業をストップし、「品質は工程内に作り込む」の精神から、再発防止策を組み入れた業務フローにて再開させます。 また、トヨタ生産方式では仕事を、①正味作業＝付加価値を高めるもの、②付加価値の無い作業＝いまは付加価値は無いがやらなければならないもの、③ムダ＝作業する上で必要の無いもの、として区分する考え方があり、私たちの職場では定例会議を待ってタイムリーな情報共有や意思決定ができないようなことになっていないか、資料はレビュアーの求める情報量になっていて有益に利活用できるものになっているか、など事務系業務における仕事のムダを意識しながら日々仕事をしています。 3. パートナーエンジニアの採用 KINTOテクノロジーズでは、中途正社員採用に注力して300人規模まで急成長してきました。 正社員エンジニアをサポートする存在として、多くのパートナーエンジニアに参画頂いています。 各開発グループでしっかりコミュニケーションとって体制を構築しているベンダーさんなどについては開発グループ側にお任せしていますが、プロジェクトの状況やチームビルディングの一環で必要になるピンポイントで高度な人材、ニッチな人材は我々に依頼が来るので、多くの外部委託先を積極的にサーチして採用につなげています。 ​ ※担当領域について マス人材　　←　開発マネージャーが担当 ニッチ人材　←　ココを担当してます 上記のような領域・・・プロジェクトの状況やチームビルディングの一環で必要になるピンポイントで高度な人材、ニッチな人材は我々に依頼が来て、多くの外部委託先をサーチして採用につなげています。 特徴的な点としては、こういったニッチな人材はフリーランスエンジニアも積極的に活用しており、活躍いただいています。 ​ ​ 4. その他の取り組みについて CIOサポートチームには多様なメンバーが在籍しており、様々な課題解決に取り組んでいます。 社内コミュニケーション活性化に取り組んでいるメンバーは、全社的な定例会議や勉強会の運営などを通して、全社の情報共有を促進し、研修を企画して各階層でのコミュニケーションを図っています。 ​ 社内での様々なドキュメントの翻訳を担当するメンバーもいます。KINTOテクノロジーズでは3割弱が外国籍社員であり、英語のほうが得意なメンバーも多いため、言語面で取り残されることが無いように社内の重要な会議の議事録や資料の翻訳を内製で迅速に対応しています。 ​ 現在、KINTOテクノロジーズは東京・日本橋と神保町の2拠点と名古屋、大阪の4拠点でオフィスを構えていますが、各拠点にはアシスタントが常駐しており、社員のあらゆる依頼・要望をキャッチできる体制を取っています。何かあればすぐにエスカレーションされて迅速な課題解決を実施しています。 ​ 基本スタンスとして・・・「Noと言わないチーム」でありたいと思っています。決してYesマンという訳ではなく、どうすれば依頼に応えられるか、要望を実現してエンジニアに貢献することが出来るかを第一に考えています。CIO室マネージャーがよく言っている「サーバントリーダーシップ」を実践し、経験したことのない業務でも必要であれば率先して飛び込むことでエンジニアの活動をサポートし、KINTOテクノロジーズの価値を高められるような行動を意識しています。 今後の課題 上記１～４の取組みを継続し、KINTOテクノロジーズの名サポーターとして"当たり前を当たり前にやり続ける"ことで、急拡大するKINTOテクノロジーズのシステム開発チームの高度化に寄与していきます。また、開発エンジニアに寄り添って、エンジニアが求める期待と要望に応じることが出来るサポート体制を維持・向上していくとともに、限られた人的リソースの中でムダな業務の削減を加速していきます。 さいごに このCIOサポートチームには前職でその道のプロフェッショナルだったメンバーが多数所属し、開発エンジニアのリクエストにプロアクティブに対応しています。まだまだ過不足のある発展途上の組織ではありますが、日々業務を通じてエンジニアファースト、エンジニアのストレスフリーを願い仕事をしています。もし、こちらの私たちの活動から同じような組織・役割をされている方で、何か少なからず共感いただければ嬉しいです。 また、このようなサポート体制を有するKINTOテクノロジーズでエンジニアをしてみたいという方、是非ご一緒にお仕事できることを楽しみにしています。

Introduction Hi, I'm Haruta from the CIO support team in the CIO office. As the name suggests, I support our CIO, Kageyama-san, and handle company-wide financial and legal management at KINTO Technologies . Our team plays a key role in managing back-office operations across the company including coordinating internal approval procedures, orders with vendors, internal and external expense reimbursements, and billing and payment procedures. I'm Kitagawa, also from the CIO support team. I'm in charge of recruiting partner engineers to support our development engineers, constantly looking for new talent. Our team is quite diverse, with some members in charge of organizational development and communication initiatives, while others focus on supporting our international staff. This article introduces our back office operations and the support our team provides to development groups. Background The systems developed by KINTO Technologies are considered assets of our parent company, Toyota Financial Services Corporation , and are provided by Toyota Financial Services to KINTO Corporation for use in delivering KINTO services. KINTO: Business owner and system user of the KINTO services KINTO Technologies: Responsible for system development and operation for KINTO services Toyota Financial Services: Owner of all systems related to KINTO services Since each of the three companies has a distinct role, the commercial and contractual processes can become quite complicated. As such, the CIO support team as a part of KINTO Technologies handles the company's back-office operations. Some members also work for the other two companies, ensuring that coordination and procedures between the three companies can be handled more quickly and accurately. As a result, we're able to avoid holds or delays caused by administrative procedures and help accelerate both administrative procedures and the actual start of on-site system development. CIO Support Team Initiatives 1. Eliminating the "Hassle" for Engineers In a typical company, when a new project begins, the development group has to initiate internal approval processes, attend multiple meetings, and gather stamps of approval before development can even start. At our company, in accordance with the decision-making authority regulations, some decisions are made through approval meetings, but about 95% of our internal approvals are completed in just one or two steps. Furthermore, the CIO support team has built a system to handle nearly the entire approval process, from drafting and submission to routing and final storage, so that development engineers can stay focused on their development. Along with the approval process taken as an example, the same approach applies to contracts and intellectual property management. For instance, when receiving a request from our engineers to "sign a new contract with XX Company," we step in to handle coordination with the vendor and support the process through to completion. Our goal is to build an engineer-first organization. 2. Workflow Design Based on the Toyota Production System KINTO Technologies, a Toyota Group company, embraces the Toyota Production System, which focuses on eliminating waste in the production flow. We still have a long way to go, but we're actively working to build our internal workflows. For example, when a human error occurs, we pause the task until the root cause is identified. Then, following the principle of "building quality into the process," we resume the work with preventative measures in place. In addition, the Toyota Production System classifies work into three categories: 1) Value-added work, which directly increases value; 2) Non-value-added but necessary work; and 3) Waste, which is not necessary for the task. At our workplace, we are conscious of waste in administrative tasks, such as whether we're delaying timely information sharing or decision-making by waiting for regular meetings, or whether the materials we use contain the amount of information reviewers need and can be used effectively. 3. Hiring Partner Engineers KINTO Technologies has focused on hiring mid-career full-time employees and has grown rapidly to a 300-person organization. Many partner engineers have joined us to support our full-time engineers. We leave the management of vendor partners with whom each development group has established solid communication and systems, but when it comes to specialized or niche roles that are needed at specific points in a project or as part of team-building efforts, those requests come to us. We actively search for and recruit top talent from a wide range of outsourcing partners. *Areas of responsibility Mass talent: Handled by the development managers Niche talent: Handled by our team In these niche areas, specialized or niche roles that are needed at specific points in a project or as part of team-building efforts, those requests come to us. We search for and recruit top talent from a wide range of outsourcing partners. One notable aspect is that we actively work with freelance engineers, many of whom are making valuable contributions to our projects. ​ 4. Other Initiatives Our CIO support team is made up of members with diverse backgrounds, and we work together to solve a wide range of challenges. Members in charge of internal communication facilitate information sharing through regular meetings and study sessions, and organizes training to improve communication across all levels of the organization. ​ We also have members who are responsible for translating various documents within the company. Nearly 30% of KINTO Technologies' employees are non-Japanese nationals, and many are more comfortable communicating in English. To ensure no one is left behind due to language barriers, we handle key meeting minutes and internal document translations in-house, delivering them promptly. ​ Currently, KINTO Technologies has offices in four locations: two in Tokyo (Nihombashi and Jimbocho), Nagoya, and Osaka. Each office has on-site assistants who are ready to respond to employee requests. Whenever an issue arises, it's escalated and addressed without delay. ​ Our basic stance is to be "a team that never says no." That doesn't mean we say yes to everything. Rather, our first priority is to think about how we can respond to requests or solve problems to support our engineers and contribute to their success. As our CIO office manager often says, we strive to embody "servant leadership." Even when a task is unfamiliar, we're willing to dive in, support our engineers, and work to enhance the value of KINTO Technologies. Future Challenges By continuing the initiatives outlined in 1 to 4 and consistently doing what needs to be done, we will support the expanding and increasingly sophisticated system development teams at KINTO Technologies. We will continue working closely with our development engineers to maintain and improve a support system that meets their needs and expectations, while also accelerating the reduction of unnecessary tasks, all while making the most of our limited human resources. Conclusion Our CIO support team includes many members who were professionals in their respective fields and they proactively respond to requests from development engineers. Although we're still a developing organization with areas to improve, we always put our engineers first and strive to create a stress-free environment where they can fully focus on their work. If you work in a similar role or team and found any of our activities relatable, we'd be glad to connect. Furthermore, if you're interested in working as an engineer at KINTO Technologies, where this kind of support system is in place, we look forward to working with you.

初めに こんにちは、グローバル開発グループでID Platformを開発しているリョウです。KINTOサービスは既に複数の国で展開しており、今後もさらに多くの国へ展開される予定です。その中で、ID Platform開発チームのミッションは「世界中のお客さまが国を跨いで一つのIDで、全てのKINTOサービスをスムーズに利用出来るIDシステムを構築する」ことです。その中で、現在FIDO Proof of Concept (PoC)の内容を皆さまにご紹介したいと思います。 アイデンティティ・プロバイダ、IDプロバイダ　IDP アイデンティティ・プロバイダ、IDプロバイダ（英: Identity provider、略してIdPまたはIDP ）は、プリンシパルのID情報を作成、維持、および管理し、フェデレーションまたは分散ネットワーク内の依存アプリケーションに認証サービスを提供するシステムエンティティである。 上記の「アイデンティティ・プロバイダ、IDプロバイダ（以下、IDP）」の説明は、IDPを聞いたことのない方は分かりにくいかと思いますが、簡単に言うと、IDPはユーザの管理、認証、認可を一連担当するシステムです。 FIDOの概念 既にFIDOの概念をご存知の方はいらっしゃると思いますが、FIDO(Fast IDentity Online)とは、一般的なID・パスワードでの認証方法と違い、パスワードレスでオンラインサービスのID認証を実行する新たな認証規格です。FIDOは「秘密鍵」と「公開鍵」の鍵ペアを利用しており、一般的な共通鍵手段より安全性が高い方法です。 FIDO認証の流れ 新規登録の流れは以下になります 登録済みユーザのログインの流れ 一般的な形との比較 一般的な形は： ユーザがアカウント作成する時点でIDとパスワードのペアを設定 サーバーにてIDと暗号化パスワードをデータベースに記入 IDとパスワードをサーバーへ送って判断させる FIDO認証メリット FIDO認証は、パスワードレスで安全的に認証ができる新しい認証方法であり 、FIDOを活用する事によって、パスワードを利用せずに公開鍵暗号で認証できます。ユーザにとって以下のメリットがあります。 サーバーが公開鍵を保存するので、ユーザの秘密情報を保存しない 公開鍵暗号化採用してるので、共通鍵より安全性が高い ユーザはパスワードを覚えなくてもログイン出来る 指紋認証、顔認認証はパスワードを手入力するより操作利便性がある 実現したこと FIDO PoCの目的としては、大きくわけると以下の２つとなります: 現行IDシステムとにおける必要な調整、対応を実現すること 社内、社外のIDシステムをFIDO利用する場合、両方とも簡単に導入出来る案を実現すること 上記の目的を合わせて、以下の４点を実現できました： ECCやRSAの公開鍵を解析すること（目的１） 生体認証によって作られた公開鍵をRDSに保存すること（目的１） 認証が発生時点、正しく認証出来ること（目的１） WebとAPI形両方対応出来ること（目的２） 工夫したこと 基本設計階段でWebとAPI形式兼用 我々は、単にIDPを作る訳ではなく、KINTOのIDPとして世界中に展開しつつ、他のサービスにも導入してもらいたいと考えています。 KINTOの各サービスはAPI式で、簡単にFIDO機能を導入できるようにしており、また、他社の場合でもWeb形式でワンクリックで導入出来るように想定しております。 両方とも対応できる形を工夫してサービスを展開すると、さらに利便性が向上します。 プログラミング言語の変更 公式サイトで手に入れたサンプルコードは、フロントエンド・バックエンド両方ともJavaScriptで書かれています。Spring Bootを利用してサービスを展開中なので、新たな機能としてIDPに追加するとJavaScriptからJava上の変更が必要となります。 JavaScriptで利用されている外部ライブラリと同じ機能のJavaライブラリがない場合には、それを実現するためのコーディングが発生します。 PoC中に遭った問題 ユーザの認証を行う際に、時々RDSに保存された公開鍵に当たらないBugが発生しました。 Debugしてみたところ、RDSに保存されている公開鍵のIDはbase64エンコード済みの文字列は、JavaとJavaScriptのbase64エンコードする関数のエンコード結果が違いました。 JavaScript上では自動補足オフで実行しましたが、バックエンドのロジックをJavaへ移動する際、自動補足の設定に気付かず、Java自動補足を使用してしまいました。 自動補足をオフの状態に切替えることで、無事にBugを解決できました。 Base64.getUrlEncoder().encodeToString(ID文字列) 自動補足を使用したパターンでは、エンコーディング結果が４の倍数に足り無い部分は「＝」イコールマークで補足する Base64.getUrlEncoder().withoutPadding().encodeToString(ID文字列) 自動補足オフモードの場合、エンコーディング結果はそのまま。 　　　 課題 FIDOによって、ユーザーは以前より便利で安全な方法でオンラインサービスを利用できるようになりましたが、その他にもまた幾つかの対応すべきことが残っています。 公開鍵管理に関する問題点： 同じデバイスで複数の公開鍵を追加できる サーバーからは同じデバイスであることを認識できないので、同デバイス内で公開鍵の登録が何回でもできてしまいます。それによってゴミデータがRDSに保存されてしまいます。 デバイスの切り替えなどによる公開鍵の再登録 デバイスの紛失や機種変更などによって、FIDOの再登録が必要です。再登録の際はその人であることを別の手段で確認する必要があるため、ID＆パスワード式より不便だと感じられます。 不要な公開鍵の管理 上記により、不要な公開鍵が生じます。ユーザーが公開鍵のID管理をできないので、公開鍵が無用になると、バックエンド上では公開鍵の有効性がわかりません。公開鍵が無効になっても、長い時間でRDS上に保存しないといけません。 まとめ パスワードレスの形でより良い認証認可の体験をユーザに届きたいので、FIDOのPoCを実施しました。 PoCを実施した結果、有力なソリューションであると感じていると同時に、まだ公開鍵管理などの課題があると感じていますので、これからもしっかり検証をした上で開発を進めていきたいと考えています。 レファレンス FIDO認証とは？ OpenID Connectとは？

初めに こんにちは、グローバル開発グループでID Platformを開発しているリョウです。KINTOサービスは既に複数の国で展開しており、今後もさらに多くの国へ展開される予定です。その中で、ID Platform開発チームのミッションは「世界中のお客さまが国を跨いで一つのIDで、全てのKINTOサービスをスムーズに利用出来るIDシステムを構築する」ことです。その中で、現在FIDO Proof of Concept (PoC)の内容を皆さまにご紹介したいと思います。 アイデンティティ・プロバイダ、IDプロバイダ　IDP アイデンティティ・プロバイダ、IDプロバイダ（英: Identity provider、略してIdPまたはIDP ）は、プリンシパルのID情報を作成、維持、および管理し、フェデレーションまたは分散ネットワーク内の依存アプリケーションに認証サービスを提供するシステムエンティティである。 上記の「アイデンティティ・プロバイダ、IDプロバイダ（以下、IDP）」の説明は、IDPを聞いたことのない方は分かりにくいかと思いますが、簡単に言うと、IDPはユーザの管理、認証、認可を一連担当するシステムです。 FIDOの概念 既にFIDOの概念をご存知の方はいらっしゃると思いますが、FIDO(Fast IDentity Online)とは、一般的なID・パスワードでの認証方法と違い、パスワードレスでオンラインサービスのID認証を実行する新たな認証規格です。FIDOは「秘密鍵」と「公開鍵」の鍵ペアを利用しており、一般的な共通鍵手段より安全性が高い方法です。 FIDO認証の流れ 新規登録の流れは以下になります 登録済みユーザのログインの流れ 一般的な形との比較 一般的な形は： ユーザがアカウント作成する時点でIDとパスワードのペアを設定 サーバーにてIDと暗号化パスワードをデータベースに記入 IDとパスワードをサーバーへ送って判断させる FIDO認証メリット FIDO認証は、パスワードレスで安全的に認証ができる新しい認証方法であり 、FIDOを活用する事によって、パスワードを利用せずに公開鍵暗号で認証できます。ユーザにとって以下のメリットがあります。 サーバーが公開鍵を保存するので、ユーザの秘密情報を保存しない 公開鍵暗号化採用してるので、共通鍵より安全性が高い ユーザはパスワードを覚えなくてもログイン出来る 指紋認証、顔認認証はパスワードを手入力するより操作利便性がある 実現したこと FIDO PoCの目的としては、大きくわけると以下の２つとなります: 現行IDシステムとにおける必要な調整、対応を実現すること 社内、社外のIDシステムをFIDO利用する場合、両方とも簡単に導入出来る案を実現すること 上記の目的を合わせて、以下の４点を実現できました： ECCやRSAの公開鍵を解析すること（目的１） 生体認証によって作られた公開鍵をRDSに保存すること（目的１） 認証が発生時点、正しく認証出来ること（目的１） WebとAPI形両方対応出来ること（目的２） 工夫したこと 基本設計階段でWebとAPI形式兼用 我々は、単にIDPを作る訳ではなく、KINTOのIDPとして世界中に展開しつつ、他のサービスにも導入してもらいたいと考えています。 KINTOの各サービスはAPI式で、簡単にFIDO機能を導入できるようにしており、また、他社の場合でもWeb形式でワンクリックで導入出来るように想定しております。 両方とも対応できる形を工夫してサービスを展開すると、さらに利便性が向上します。 プログラミング言語の変更 公式サイトで手に入れたサンプルコードは、フロントエンド・バックエンド両方ともJavaScriptで書かれています。Spring Bootを利用してサービスを展開中なので、新たな機能としてIDPに追加するとJavaScriptからJava上の変更が必要となります。 JavaScriptで利用されている外部ライブラリと同じ機能のJavaライブラリがない場合には、それを実現するためのコーディングが発生します。 PoC中に遭った問題 ユーザの認証を行う際に、時々RDSに保存された公開鍵に当たらないBugが発生しました。 Debugしてみたところ、RDSに保存されている公開鍵のIDはbase64エンコード済みの文字列は、JavaとJavaScriptのbase64エンコードする関数のエンコード結果が違いました。 JavaScript上では自動補足オフで実行しましたが、バックエンドのロジックをJavaへ移動する際、自動補足の設定に気付かず、Java自動補足を使用してしまいました。 自動補足をオフの状態に切替えることで、無事にBugを解決できました。 Base64.getUrlEncoder().encodeToString(ID文字列) 自動補足を使用したパターンでは、エンコーディング結果が４の倍数に足り無い部分は「＝」イコールマークで補足する Base64.getUrlEncoder().withoutPadding().encodeToString(ID文字列) 自動補足オフモードの場合、エンコーディング結果はそのまま。 　　　 課題 FIDOによって、ユーザーは以前より便利で安全な方法でオンラインサービスを利用できるようになりましたが、その他にもまた幾つかの対応すべきことが残っています。 公開鍵管理に関する問題点： 同じデバイスで複数の公開鍵を追加できる サーバーからは同じデバイスであることを認識できないので、同デバイス内で公開鍵の登録が何回でもできてしまいます。それによってゴミデータがRDSに保存されてしまいます。 デバイスの切り替えなどによる公開鍵の再登録 デバイスの紛失や機種変更などによって、FIDOの再登録が必要です。再登録の際はその人であることを別の手段で確認する必要があるため、ID＆パスワード式より不便だと感じられます。 不要な公開鍵の管理 上記により、不要な公開鍵が生じます。ユーザーが公開鍵のID管理をできないので、公開鍵が無用になると、バックエンド上では公開鍵の有効性がわかりません。公開鍵が無効になっても、長い時間でRDS上に保存しないといけません。 まとめ パスワードレスの形でより良い認証認可の体験をユーザに届きたいので、FIDOのPoCを実施しました。 PoCを実施した結果、有力なソリューションであると感じていると同時に、まだ公開鍵管理などの課題があると感じていますので、これからもしっかり検証をした上で開発を進めていきたいと考えています。 レファレンス FIDO認証とは？ OpenID Connectとは？

はじめに KINTOテクノロジーズ CIO室で人事採用チームのリーダーをしています、岩本です。 キャリアとしては、ホテルのフロントスタッフ → 外資系派遣会社にてCA・人事 → メガベンチャーの事業部人事 → スタートアップの人事立ち上げ といった経験をし、現在も人事に関して幅広く担当しております。 普段は、4匹の犬と2匹の猫に囲まれて、ムツゴロウさんのように過ごしています。 この記事では、人事採用チームの紹介をさせていただきます。 何をしているチーム？ 人事採用チームは以下のバリューを軸に、KINTOテクノロジーズの採用・組織構築に携わっています。 具体的には以下の通りです。 採用 KINTOテクノロジーズの開発をリードする、エンジニア・クリエーターの中途採用です。 私が入社した2021年11月頃は160名弱の組織でしたが、2022年12月1日現在、約280名まで拡大し、およそ1年で社員数が約1.5倍になりました。 KINTOテクノロジーズを選んで、入社をしてくださった社員の皆さん、改めてありがとうございます！ 今後は、採用体験の向上や社内情報発信などに取り組み、他社から採用の参考にしてもらえる企業を目指していきます。 社員面談 会社の課題を集め、より良い組織にするための施策として、入社後面談 / 全社員面談・休職者面談・退職者面談を2022年2月から取り組んでいます。 会社が設立されてまだ3年目。急速に組織が拡大したこともあり、抱える課題はたくさんあります。社員の方とのコミュニケーション・ヒアリングを通して実態を把握し、組織開発施策の企画・運用を行うなど、会社にとっても、社員にとっても、強くて魅力的な組織つくりのための活動をしています。 もちろん面談以外でも、困ったことがあればいつでも何度でもご相談ください！^ ^ マネジメント研修 エンジニアリング教育研修プロジェクトメンバーと連携し、グループマネージャー向けの研修を企画・運営しています。 働く環境のアップデート 社員の方がモチベーション高く働けるような環境づくりにも関わっています。 小腹がすいたときにすぐ食べ物が購入できるサービスの導入や、TOYOTAミニカーの設置、自販機を設置した際はKINTOテクノロジーズ仕様にラッピングするなど、KINTOテクノロジーズで働くことが楽しくなるような体験を意識しています！ その他いろいろ 入社時オリエンテーション対応、入社後のフォローアップ カルチャー醸成、ミッションビジョンバリューの言語化 エンジニアイベントのサポート などなど。とにかく、もらったボールや落ちているボールを拾いまくり、KINTOテクノロジーズで働くみなさんを人事面からサポート、時にはリードしながら、日々活動しています！ どんなメンバーがいるの？ 実はこれまで、ひとりで採用や組織調整などを担当しておりましたが、今年の4月にメンバーが加わったことでチームが発足し、今では私を含め7名のメンバーで構成されています。 各々の得意領域は以下の通りですが、何においても線を引かないメンバーが集まっているので（だから落ちているボールに気づいて拾える）、横断的に複数のプロジェクトを担当していることが多いです。 「できないではなく、どうやったらできるかを考える」 「誰かが困ったときは、一緒にできる方法を考える」 そんな考え方が浸透していると感じています。心強いメンバー達です！ チームのこれから 冒頭に紹介した、「人事採用チームが大切にしたいこと」を変わらず大切に、社員の皆さんに頼ってもらえる、期待を超えていけるようなチームを目指していきたいです。 会社と組織を良くするための戦略的なことも仕掛けていきたいと考えており、人事目線にはなりますが、KINTOテクノロジーズはこれからもっとユニークで面白くなる組織だと思いますので、注目いただけると嬉しいです。

Introduction I am JL, an application engineer at KINTO Technologies (KTC) and currently a member of the frontend team under the Global Development Group. Before coming to Japan, I worked in the Philippines for 3-4 years, first in the Fishing Industry as technical support and later in the Finance sector as an Associate Software Engineer. By working on both the front end and business side of projects, I acquired experience in developing web pages, batch processes, and business processses using mainly Java, JSP, JavaScript, and CSS. I also learned professional skills that a software engineer must have to be a productive employee of my company. The company I worked for had its headquarters in Japan, and it piqued my interest in going to Japan. I saw that the engineering team in Japan had strong technical skills, and paired with the fact that Japan has a good reputation in the field of Science and Technology field, I wanted to learn from them firsthand. Joining KINTO Technologies After moving to Japan, I was a contract employee at a dispatching company in Tokyo. Being a dispatched employee, I had limited scopes and responsibilities depending on what project I was working on. When a recruiter introduced KTC to me, I found it interesting for various reasons. As people travel around the world on vacations or business trips, I thought there is growth potential for KTC's worldwide expansion of mobility services. It is also atractive for me that although KTC is still new, it is part of Toyota Group that has been providing better cars and services to the world for many years. I felt that I could learn not only technical skills but also communication and business analysis skills. Also, as an application engineer for the Global Group, I will encounter many opportunities to work on projects from different countries perspectives. KTC is a growing company with a clear vision, with the potential to grow even further soon, and it may develop future products that will be of good use, and I hope to be involved with it. My working life and experiences in KINTO Technologies Global Group is a multicultural group with people from different countries like Japan, China, Vietnam, India, and the Philippines. In my team, we communicate using English, which helps foster good communication and avoid language barriers. Despite being in Japan, the Global Group helps and collaborates with overseas KINTO services like Thailand and Qatar. Global Group is also conducting a monthly survey where we can submit our feedback and suggestions for the improvement of the group. There is also a monthly 1-on-1 with our managers to help us plan our careers and have a vision of what we want to do in the company. When I joined, I was assigned to the frontend engineering team which is responsible for developing the frontend of Global Group's product and enhancing the web layout for it to be eye-pleasing to the site visitors. In that team, I was assigned to develop the Technology Portal. The portal was developed from scratch, and it is used by KINTO partners around the world to see what kind of solutions are available for them to use. It was designed to use Gatsby.js, CSS, and AWS S3. It was challenging but rewarding as I was exposed to a programming language and architecture that I was unfamiliar with. It helped me grow a lot in a short period which I highly appreciate. Currently, I am working on Global KINTO App Landing Page . This page is where one can see the information about Global KINTO App and KINTO Services in different countries. In this project, we are improving an existing website and converting the design elements with the KINTO Design System to unify the design of all KINTO system and products; you can learn more about that here . We are using mainly Vue.js and Vuetify for the project. This time I am learning more about design theory and design best practices. It improves my analysis and creative skills, particularly on how to design a page responsively and use SASS and CSS efficiently. Conclusion To wrap it up. My experience in KTC is what I expected in how my career will go when I decided to go to Japan. At first, I thought I will work only with application development and mobility applications because that is the role I applied to. But I am not limited to such positions as I do design system and website development as well which enhances my skill and gives me the impression that my career growth can be flexible in this company. The short span of how I acquired skills, the challenges I’ve encountered, and the great feeling after successfully clearing those obstacles make you feel grateful to work in this company. I can see that my skills have greatly improved. I am looking forward to more exciting challenges I will encounter shortly. There are plenty of possibilities that KTC offers because they are not limiting their employee to only certain positions; it means I may be involved in application service development or being a technical lead in the future. If you are looking to work in a competitive company for good career growth with many possible opportunities for skill up and role responsibilities why don't you try to work in KTC? Particularly in Global Group, it has a good diversity of skillful people that always update their skills with the current trend in the industry; KTC has a solid foundation and assuredly, you will encounter exciting projects when you work with us. https://www.kinto-technologies.com/recruit/globalkinto

KINTOテクノロジーズにてグローバル開発グループのアシスタントをしている伊東です。メンバーからの問い合わせ対応、資料の翻訳など、こまごまとしたサポート業務をしています。 好きなものは猫と小説です。猫と一緒に寝転がって小説を読むのは天国ですが、ずいぶん前に猫がもう一つの天国に行ってしまったため、ひとりで寝転がって読書する日々が続いています。今年は英語の小説も5, 6冊読みました。以前は、英語で小説を読むのは苦痛以外の何ものでもありませんでしたが、最近、原書で読む楽しさがわかってきました。ですが、外国語を話す一番の楽しみは会話だと思います。英語に限らず外国語が話せるようになると、楽しいことや選択肢が確実に増えます。もちろん、その過程で大変なこともありますが。 外国語を話せるようになるには、どうしたらいいのでしょう？何でもすぐに吸収できる子供と違って、普通の大人はたくさん努力をしなければなりません。語学を習得するために必要なことは、基礎的な文法や単語をわかったうえで、その言語を話す機会をたくさん持つ努力をすること。これに尽きると思います。 本記事では、普通の大人たちの語学力向上のために、グローバル開発グループの業務エンハンスチームが主催しているLanguage Skill Up Projectについて、ご紹介します。 はじまり 現在、グローバル開発グループには60名近いメンバーがいますが、国籍・文化・言語・経歴などさまざまです。その中には日本語があまり得意でない人、英語を今まで仕事ではあまり使わなかったため、話すことに慣れていない人などがいます。メンバーには「開発スキル」という共通点がありますが、言葉の壁のせいで、コミュニケーションがうまくとれなければ、会社にとっても損失になります。この問題を少しでも解消すべく、「メンバーのポテンシャル底上げ」をミッションとする業務エンハンスチームを主体に、Language skill-up projectを始動しました。 総務省が定義するグローバル人材の要素の中に、語学力・コミュニケーション能力、異文化理解の精神というのがありますが、グローバル開発グループにはそれらを培うことのできる環境があります。これを生かしてグローバル人材を育てるのもこのプロジェクトの目的の一つです。グループ内だけでなく、他のグループからも参加できるよう環境を整えています。 言語学習で大切なことは「できないと思わない」ことです。英語で話すこと・日本語で話すことにまずは慣れ、自信をつけていくことを目標に、このあと記載するようなイベントを企画・運営しています。 何をするか 語学力向上の手伝いをすると言っても、一体何をすればいいのでしょう？レベルも様々ですし、何が必要かも人によって違います。 語学学習には何が必要か考えてみました。 基本的な単語、文法（英語であれば中学生レベル）をマスターする 読む（音読含む） 書く 聞く 発音やイントネーションをよくするためにシャドーイングする 会話して話す力をつける 1から5は基本、独学で家にいてもできそうです。6は、お金を払って学校に行くか、オンライン英・日会話をする以外、自分で外に出て行って機会を作るしかありません。そして、おそらく、メンバーに不足しているのは会話する機会でしょう。1から5は、必要であれば、後で付け足すこともできるので、まずは会話する場を提供することから始めました。 日本語カフェ 隔週の昼1時間、楽しく会話するカジュアルな会です。別名ピザ・パーティー。今年（2022年）の4月に始めたので9か月ほど続いています。基本、日本語だけで行われているため、中級から上級レベルの人が多く参加しています。「楽しく」がポイントで、日本語での、より円滑なコミュニケーションができるようになるのが目標です。 日本語カフェ 日本語勉強会 話す機会を持つことが一番とは言っても、日本語カフェだけではさまざまなニーズに応えられないため今年（2022年）8月から始まりました。毎週1回、午後30分。少人数で行っています。 入門クラス　あいさつ、ひらがな、カタカナ、生活で役に立つフレーズなどを学びます。 会話クラス（初級～中級）　買い物、電話などのロールプレイをし、そこで学んだ言い回しを使って会話の練習をしたり、関連した言葉を学んだりします。 漢字クラス（初級～中級）　新しい漢字を学びつつ、言い回しも練習します。 ビジネスクラス（中級～上級）　Slackなどにある業務連絡を教材にして、ビジネスで使われる単語や言い回しを勉強します。 英語カフェ 2022年7月から始まりました。毎週1回、夕方30分～1時間。神保町オフィスで行っていますが、グローバル開発チーム以外から参加する人、リモートで室町オフィスから参加する人もいます。（ピザは出ません。）これまで英語のゲーム、プレゼン、ディスカッションなどをしてきました。日本語カフェ同様、会話を練習したい中級レベル以上の人の参加が多いですが、少人数で行われることが多いため、その時々によりレベルを合わせることは可能です。初級の人や、英語に関する悩み事を話してすっきりしたいという人の参加もお待ちしています。 英語カフェ（密ですね。写真撮影用に特別に集まってもらいました） 英語個人セッション 週1回30分、英語が苦手な方を対象に2022年4月に始まりました。最初の半年は週2回でしたが、英語を話すことに慣れてきたため、現在は週1回行っています。　最初の頃に比べると、参加者の方々は自分から積極的に話すようになりました。「英語を話すことに抵抗がなくなった」「自信がついた」などのコメントをいただいています。話したい内容があるのは、外国語学習の上で大切です。是非、継続してがんばっていただきたいです。 やってみた感想、今後のこと もともと、コミュニケーション活性化が目的の一つでしたが、日本語・英語ともに、どの時間も和気あいあいとした雰囲気で行っていて、チームビルディングにも非常に役立っています。同じグループに所属していても、仕事で直接かかわりがある人以外と話す機会はあまりありません。日本語カフェ・英語カフェに参加することで、普段、なかなか話す機会がない人とも交流できます。参加者の中には日本語も英語も母国語でない人もいますし、バックグランドも多様なため、会話することで、いろいろな事やさまざまな文化について知る機会にもなっています。 Language Skill Up Projectはまだ始まったばかりで、より効果的な方法がないか試行錯誤中です。まだ参加したことがないという人にもぜひ参加していただきたいです。もっとこういうふうにやってほしいというリクエストも受け付けています。モチベーションを持ち続けるための場であったり、各自が外でも話す機会を作るきっかけになればいいなと思っています。 魔法のように外国語がうまくなることは決してなく、日々、自分で努力する以外に方法はありません。言い換えれば、あきらめず努力を続けさえすれば、必ず話せるようになります。話せるようになった後も、意識的に話す機会を持たなければ、残念ながら、簡単に話せなくなってしまいます。知らないことも永遠になくならないので、勉強し続けなくてはなりませんが、それが習慣づく頃には、勉強というよりは生活の一部に変わっているはずです。

Self Introduction "It's not that I'm so smart, it's just that I stay with problems longer." — Albert Einstein, physicist Problems can be very discouraging at some point. However, I think my nature of being merry also helped me overcome different challenges. No wonder why I think my name suits me very well. Hi, I'm Mary, and I am part of Global Development Group at KINTO Technologies. I joined the company in January 2022 without so much experience about frontend, yet I chose to accept the challenge. From knowing how to use different tools to knowing how to work on different programming languages, I treated all of these as an opportunity for me to start working on the things I have been longing to try. As time went by, I was amazed that I could already develop a website. Being in a global team allowed me to gain different skills and understand other people’s cultures, histories, and beliefs. I started on a project wherein the language used is English, and since this language is not new to me, it was easy for me to understand how such websites are normally written. However, after that project, I was assigned to work on a project for Qatar, and Arabic is something I am not familiar with. Their way of writing is done from left to right. Nevertheless, I treated this as a chance for me to learn about their reading and writing system, as well as how to address this issue on the web pages that I create. KINTO Technologies was just established last year, and there still is lots of room for improvements, learning, and challenges that we have to overcome. Since I am the type of person who treats challenges as opportunities, I will always choose to go out of my comfort zone, where I believe growth takes place. Overview Languages can be written in different directions - horizontally, vertically, from right to left, or from left to right. As one theory suggests, this is due to the history of how people used to write using a specific medium. In the ancient days, Middle Eastern languages like Arabic and Hebrew, which are written from right to left, were chiseled into stones. Most people were right-handed, and right to left writing seemed to be more natural with a chisel. As for East Asian Languages, which are suggested to have been written using scrolls, they are easier if they were written from left to right. On top of this, using ink and writing from left to right will prevent smudging. Although these are only theories, and even though some means used in ancient times are no longer common, we can still see that the writing direction has been adapted to various mediums - including newspapers, books, and even websites. The ability to support the language direction will help the readers easily understand the language since it is written in its original form. Challenges From the perspective of an end-user when browsing a site, I normally use the language I am comfortable in, which is English. However, after coming to Japan, I realized that not all websites have the option to choose a language. Hence, I started searching the internet and found out that I can set up a website to automatically translate languages I am not familiar with. I thought that this automatic translation would suffice to meet the need of an end user. But as machine translation is still not perfect, there will still be cases of incorrect translation or, worse, some words cannot be translated. With this in mind, I found myself interested in finding ways how to solve such issues. Luckily, I was assigned to work on a project for Qatar, where I encountered the following challenges to overcome: Detection of Browser Language Changing Browser Language Setting Language on a Specific Page Displaying with $vuetify.rtl and document.dir Bonus: Since I am only assigned to do frontend, my main focus is to develop the website itself given the resources I have. The translation from English to Arabic is a different story. Here’s a link to how it was done: Language Localization at KINTO Technologies Solution/s When a company is becoming global, I think one of the issues to solve is how we will be able to make it really global. In order for us to showcase a service or a product, one of the possible ways is to have the information available on the Web. But, I believe this is not as simple as it sounds. We have to make sure that the reader, anywhere across the world, is able to understand the message we are trying to convey. In order for me to be able to display the website in its expected language, I have to understand what browser language is being used by the end user first. With this, we are sure that they will be reading the site in the language of their preference. Detection of Browser Language Using @nuxtjs/i18n Options For reference on how to setup @nuxtjs/i18n, please follow the steps written here . Under nuxt.config.js, input i18n locale, and set detectBrowserLanguage: true i18n: { locales: [ { code: 'en', iso: 'en', file: 'en.json' }, { code: 'ar', iso: 'ar', file: 'ar.json', dir: 'rtl' }, ], detectBrowserLanguage: true, }, code (required) - unique identifier of the locale iso (required when using SEO features) - The ISO code used for SEO features and for matching browser locales when using detectBrowserLanguage functionality. Should be in one of those formats: ISO 639-1 code (e.g. 'en' ) ISO 639-1 and ISO 3166-1 alpha-2 codes, separated by hyphen (e.g. 'en-US' ) file - the name of the file. Will be resolved relative to langDir path when loading locale messages from file dir (from v6.19.0 ) The dir property specifies the direction of the elements and content, value could be 'rtl' , 'ltr' or 'auto' . To set the direction attribute, use $nuxtI18nHead method in the layout <script> export default { head() { return this.$nuxtI18nHead() } } </script> Using window.navigator.language const lang = window.navigator.language console.log('language:' + lang) // language: ar Changing Browser Language In order to test if the above language detection is working, we may explicitly change the browser language settings. Listed below are the steps for how to change the language of some of the widely used browsers. (Note that the following steps are specifically for Windows.) Chrome On your computer, open Chrome. At the top right, click More ⋮ > Settings. At the bottom, click Advanced. Click Languages > Language. Next to the language you'd like to use, click More ⋮. If the language isn't listed, add it by clicking Add languages. Click Display Google Chrome in this language. (This option is only available on Windows computers.) Restart Chrome to apply the changes. Firefox Click the menu button ☰ and select Settings. In the Language section of the General panel, choose a language in the drop-down menu. Restart Firefox. Edge Go to Settings and more (...) > Settings . Select Languages from the Settings list. To add a language to the list of Preferred languages, select Add languages. Once the language is added, select (...) next to the language, and then choose Display Microsoft Edge in this language. Setting Language on a Specific Page Although KINTO is still a new company, we still try our best to deliver services based on customer’s needs and demands. I believe the idea of getting international requires an ample amount of time to cover each country. This is where I realized that KINTO might have been focusing on what is needed at a specific time first, then doing the rest afterwards - a matter of priority. In a project I contributed development to, we first set one page to be able to load both English and Arabic. During that time, the page Get the KINTO App - Mobility for all serves as the landing page for Qatar. Thus, it will need to be translated first before the service is released. Setting the language only on a specific page is not very common. Usually, when translations are done, all pages on a website are translated. But in case this scenario is encountered, the following solution can be applied. Situation : Page must be converted to Arabic, and the direction must be Right-to-Left (RTL) if and only if we are navigating to page /sample with Arabic browser language // Check whether the user is navigating to /sample with Arabic browser language const toArabic = this.$route.name === 'sample' && window.navigator.language === 'ar' // Set the direction of document document.dir = toArabic ? 'rtl' : 'ltr' // Set the rtl direction of Vuetify (true or false) this.$vuetify.rtl = toArabic // Set locale using @nuxtjs/i18n // Under nuxt.config.js, select the code to use this.$i18n.setLocale(toArabic ? 'ar' : 'en') Looking at the above code, we can say that it will only work if the browser language particularly uses ar . What if the browser has ar-XX format? We can use several methods to determine the language, and one of them is by using split() . Through this method, setting the locale will also be easy. const x = "ar-XX" console.log(x.split("-")[0]) //ar this.$i18n.setLocale(x) Displaying RTL with $vuetify.rtl and document.dir During the development, I took time investigating why my RTL layout didn't work properly for all components. I tried setting document.dir = ‘rtl' then setting this.$vuetify.rtl = true , but it doesn’t work unless I set them both. Although I only did trial and error, and confirmed that the components were displayed properly when I used both, there was still an urge for me to know the reason behind the issue. Below are the reasons I found why the problems occurred. Using only $vuetify.rtl <template> <v-icon class="left-arrow" size="100px">mdi-chevron-double-left</v-icon> </template> ... <script> export default { mounted() { this.$vuetify.rtl = true } } </script> ... <style lang="scss" scoped> [dir='rtl'] .left-arrow { transform: rotateY(180deg); } </style> Situation Set this.$vuetify.rtl = true and use [dir='rtl'] at the same time Result Icon is still facing to the left and not rotated Cause If the document is inspected, it shows that the html direction is not indicated. Thus [dir='rtl'] will not work Solution Set document.dir = 'rtl' in order to set the html direction to RTL Using only document.dir <template> <v-expansion-panels> <v-expansion-panel v-for="(item,i) in 5" :key="i" > <v-expansion-panel-header> Item </v-expansion-panel-header> <v-expansion-panel-content> Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. </v-expansion-panel-content> </v-expansion-panel> </v-expansion-panels> </template> ... <script> export default { mounted() { document.dir = 'rtl' } } </script> Situation Set document.dir = 'rtl' and use vuetify components Result Some components are not properly displayed Cause RTL not working properly during bootstraping Solution Set this.$vuetify.rtl = true . As seen from the snip, the arrow has moved to the left side. <script> export default { mounted() { this.$vuetify.rtl = true document.dir = 'rtl' } } </script> Summing it up Even if most programming frameworks offer support for multiple languages, there are still some tweaks needed for it to work properly. But I am happy that I was still able to finish the task on time, even with the above challenges. Please have a look! https://www.kinto-mobility.com/app/ As more and more countries introduce KINTO services, other projects in KINTO Technologies will need translation and I am happy that I've done the groundwork for such a feature. Thoughts Being in frontend isn't just about creating a website with breathtaking designs and layouts, we also have to consider the user experience. Imagine having an outstanding design, yet it doesn't give satisfaction to our target customers. Are we really meeting their needs and wants?  Photo reference: https://images.squarespace-cdn.com/content/v1/5c6afc627eb88c46e4f41468/1563183013744-RWOU1N19RO77MT0EAH3M/IMG_0873.jpeg References Overview of Language Directions Why Do We Read English From Left To Right? Right to Left Languages | Why are they written this way | Pangeanic Omniglot index by writing direction @nuxtjs/i18n Introduction window.navigator.language Navigator.language - Web APIs | MDN Updating Browser Language Settings Change Chrome languages & translate webpages - Computer - Google Chrome Help Use Microsoft Edge in another language - Microsoft Support Use Firefox in another language | Firefox Help Vuetify Vuetify — A Material Design Framework for Vue.js

こんにちは こんにちは！KINTO ONE開発Gの中川原です。 参加しているプロジェクトではフロントエンドエンジニアとしてNext.jsとTypeScriptを用いて開発を行なっています。 今回はチームで開発を進める上で欠かせない、コードレビューについてのお話です。 私がコードレビューをする際に気を付けていることをレビュイー、レビュワーそれぞれの場合に分けてご紹介したいと思います。 レビュイーとしてコードレビューを依頼するとき 早速本題に入っていきます。 まず自分がプルリクエスト（以後「PR」と記載）を作成してコードレビューをしてもらう際に気を付けていることを2点ご紹介します。 1. コミットのコメントを分かりやすく記載する 分かりやすく簡潔に書こうと意識することで自然と適切な粒度のコミットになると考えます。 必要があれば2行目以降に補足説明や参考リンクを記載します。 また、コミットメッセージに絵文字のprefixを付けています。 視覚的にどんなコミットなのか分かりやすくなる のと、絵文字に意味を持たせているので必然的に 一つのコミットに修正を詰め込みすぎるのを防ぐ というメリットがあります🌈 以下は実際にFEチームで使用しているコミットテンプレートです。 # ==== Format ==== # :emoji: PBI_id Subject # # Commit body... # ==== Emojis ==== # 🐛 :bug: バグ修正 # 👍 :+1: 機能改善 # ✨ :sparkles: 部分的な機能追加 # 🎉 :tada: 盛大に祝うべき大きな機能追加 # 🎨 :art: 見た目の追加・修正 # 🔧 :wrench: 機能の修正 # ♻ :recycle: リファクタリング # 🚿 :shower: 不要な機能・使われなくなった機能の削除 # 📝 :pencil: ドキュメントやコメントの追加・修正 # 🚚 :truck: ファイルの移動 # 👕 :shirt: Lintエラーの修正やコードスタイルの修正 # 🤖 :robot: テストの追加・修正 # 🚀 :rocket: パフォーマンス改善 # 🆙 :up: 依存パッケージなどのアップデート # 👮 :cop: セキュリティ関連の改善、Warningの解消 テンプレート作成にあたり、以下記事を参考にしました。 atom Emojiで楽しく綺麗なコミットを手に入れる そして実際のコミットがこちら👇 その コミットを単体で見た時に何をしているか分かる ように意識しています。 2. テンプレートを利用してPRを充実させる FEチームではPRのテンプレートが用意されています。 レビュワーがレビューをする際にどのような観点でチェックすれば良いのかが明らかになるため、レビュー効率の向上が期待できます。 以下は実際に使用しているテンプレートです。 JIRA を使用してタスクをチケット管理しているためその チケットへのリンク 、 このPRで対応すること・しないこと 、それによって 何ができるようになるのか などを記載します。 ## チケットへのリンク * https://example.com ## やったこと * このプルリクで何をしたのか？ ## やらないこと * このプルリクでやらないことは何か？（あれば。無いなら「無し」でOK）（やらない場合は、いつやるのかを明記する。） ## できるようになること * 何ができるようになるのか？（あれば。無いなら「無し」でOK） ## できなくなること * 何ができなくなるのか？（あれば。無いなら「無し」でOK） ## その他 * レビュワーへの参考情報（実装上の懸念点や注意点などあれば記載） テンプレート作成にあたり、以下記事を参考にしました。 Pull Requestのテンプレートを作って効率よくレビューしよう！ 上記に加え、必要に応じて情報を付け加えるよう意識しています。 例えば バグ対応のPRの場合は原因も合わせて記載 したり、 UIの変更がある場合は修正前後のスクリーンショットや動画を添付 したりします。 それによりPRの意図やコードの理解がスムーズに進むと考えるためです。 レビュワーとしてコードレビューをするとき 続いては、反対にチームメンバーのPRを見る際に気を付けていること3点についてです。 1. PRの概要を理解する 前段でテンプレートを使用してPRを丁寧に書くとお話しました。 なのでまずちゃんと概要を読みます。 背景や意図、 ここではやらないこと を理解した上でコードを見た方がレビュー効率も良く、的外れな指摘をしないで済むと思っています。 2. ローカルで確認する PRの変更ファイルからもコードは確認できるのですが、以下の理由から挙動に関わる修正の場合はローカル環境にブランチを落として確認するようにしています。 挙動・見た目の確認をするため コード全体を見るため 挙動・見た目の確認をするため 実際に自分で動かすことで期待する挙動・見た目となっているかを確認するほか、変更の目的や意図を理解することができます。 コードだけ見てもなぜその変更に至ったかが理解できていないと適切なレビューができなかったり、今後自分がその箇所に手を入れる際にデグレしてしまう可能性があります。 なのでできるだけ自分の目で処理を追いコードを理解するようにしています。 また、シンプルに対応漏れの場合や、その修正により別の箇所に影響が出てしまった場合に事前に気づくことができるので 思わぬバグの発生防止 にも繋がります🐛 コード全体を見るため 処理を理解するのはもちろん、「同じような処理をしているからこことここはまとめられそう」など、最適化ができそうな箇所に気づくことができるかもしれません。 3. レビューコメントにラベルを記載する コメントの先頭に [imo] や [nits] などのラベルを記載することで温度感が分かるようにしています。（まだ結構書き忘れるので徹底したい） おしまい 長々と書きましたが、まとめると 自分がレビュワーの場合に何が書いてあるとレビューしやすいか、レビュイーの場合にどのようにレビューしてもらえると助かるか を意識しています。 今後の課題としては丁寧さだけでなくレビューの速度も意識していくことと、自分なりの観点表を作成しレビュー品質のムラをなくしていくことだと考えます。 そのレビュー観点についてチームで認識共有をしてみるのも面白そうだなと思いました。 この記事が少しでもコードレビューのヒントになれば幸いです。 最後まで読んでいただきありがとうございました！

チームの紹介と仕事内容 我々のチームはWoven Payment Solution開発Gです。 早速ですが我々のチームについて伝える前に Woven City について知ってもらう必要があります。 Woven Cityとはトヨタ自動車が「幸せの量産」を目的に開発を進める、モビリティのためのテストコースであり実証実験の街です。 Woven Cityはトヨタグループ内のWoven Planet Holdingsが主導して開発を進めています。 我々のチームはWoven Planet内のPayment Solutionチームのメンバーや他のチームのメンバーと一緒にWoven Cityで使われる決済サービスの開発を行なっています。KINTOテクノロジーズとWoven Planetは別会社なのですが、開発においては特にそれを意識することなく一つのチームとして働いています。 Woven Cityは未来の当たり前を発明するモビリティのためのテストコースであり、我々にもそれに資する機能を開発することが求められています。Woven Cityでは全ての住民や関わる人は、何かしらあたらしい価値を作り出す発明家、あるいは発明を一緒に創る人であるとしています。つまりそれら発明家がより良い製品、サービスなど、何かを作るにあたって必要となる機能やデータを提供することが求められます。このことが一般的な決済サービスと、我々が作る決済サービスの大きな違いとなります。 例えばあるサービスがユーザーからの支払いを受け付けるにあたって、UXとして前払い、後払い、あるいは定期払いや他の方法がよいのかなどを検討しやすくしたり、またデータの提供についても、支払いの情報だけでなく、Woven Cityの他のデータと組み合わせて多角的に検討できるような形で提供するということを考えています。 もちろんこれらは発明家の方たちに提供するだけでなく、Woven Cityというしくみそのものをカイゼンしていくことにも用いられます。 (当然ですが、個人に関わる情報をご本人の同意なしで取得するということはありません) 働き方 Woven Planet側のメンバーも含めて、Payment Solutionのチームは自宅からリモートで開発しています。 ただし週一回水曜日はオフィスに出社し、直接相対してコミュニケーションを取る機会を作っています。 コミュニケーションツールとしてはGoogle MeetとSlackを利用しています。 Woven Planetは英語がコミュニケーションの前提となっているため、特に日本語話者以外がいる場合は英語での会話を行なっています。 またSlackや文書においては日本人同士であっても英語でやりとりを行っています。独り言みたいな投稿も英語で行っているので、悩んでいることを書き込むと、他のチームから助言を貰えたり議論がはじまることもあります。また他のチームから相談されることもあり、時にはそのままhuddleで口頭での会話がはじまるなど、リモートであっても活発なコミュニケーションが行われています。 出社した時には、直接顔を合わせて議論をしたり、タイミングが合えば一緒に社食を食べたりと実際に会うことで得られる刺激を楽しんで仕事をしています。 また開発にあたってWoven City建設予定地に見学に行く機会があります。現時点ではWoven Cityは街そのものが建設中であるため、見学のタイミングによって違う表情を見せてくれており、まだまだ更地の部分は多いものの、実際に使われるイメージを膨らませる役に立てています。 利用している技術 プログラミング言語 Kotlin 我々のチームのスコープはサーバサイドアプリケーションとなっており、その開発にはKotlinを利用しています。 Kotlinを選択した理由についてですが、Javaとの高い相互運用性が大きな理由です。 KINTOテクノロジーズおよびグループ内にはすでにJavaエンジニアが多く在籍しており、彼ら彼女らを我々のチームに素早く加入させられるのではないかという目論見があります。 私自身過去にJavaの経験があり、導入にあたってKotlinで簡単なWebアプリを何度か構築してみたのですが、公式ドキュメントを多少参照するだけで特に問題なくJavaと同程度にはスラスラかけるようになりました。 Go, C#, Rubyといった他言語でのサーバサイド開発経験があるものの、Java自体は未経験のメンバーも参加していますが、彼らも特に問題なくKotlinを使えるようになっています。 最初はBetter JavaとしてのKotlinとして使っていたのですが、最近ではJavaを忘れてKotlinを書くという意識で使うようになっています。 またプロジェクト管理にはgradleを使っているのですが、その設定ファイルもKotlin Scriptで記述しています。 利用している主なライブラリ Ktor, Koin, Exposed, Kotest, MockK, etc 我々のサービスは複数のアプリケーションサービスから構成されているのですが、その多くはREST APIを持つWebサービスです。KotlinでもSpring MVCやSpring Bootを使うことは出来るのですが、我々はKtorを選びました。Springを採用しなかったのは、アノテーションを駆使するような魔法のようなコードを可能な限り避けたかったというのがあります。ですがDependency Injectionの仕組み自体はテストのためや依存性の管理のために利用したいと思い、DIライブラリとしてKoinを採用しています。 KoinにもSpringのようなアノテーションによる設定方法が用意されているのですが、DSLでの設定方法も用意されており我々はこちらの方法を利用しています。 KoinやDSL自体の知識は要求されるのですが、アノテーションと比べるとDSLの方が通常のKotlinコードの中に自然に織り込むことが出来るため、意図を明確に表現出来るように感じています。 ほかにもORMにはExposedであったり、テストのためにKotestやMockKを使うなど、様々なFOSSライブラリを利用しています。 Ktor 公式サイト Koin 公式サイト Exposed Github Repository Kotest 公式サイト MockK 公式サイト これはチームというより、完全に個人の興味になりますが、Ktorは GraalVM でも動作するため、チャンスがあればGraalVMを使ったネイティブビルドに挑戦したいと思っています。 参考: https://ktor.io/docs/graalvm.html#prepare-for-graalvm アプリケーション基盤 Kubernetes 我々の開発しているアプリケーションはKubernetes上にデプロイされており、自分達の開発しているサービスについての設定は、自分達でYAMLを書いています。 Kubernetes環境全体の開発や運用については別チームが担当しているのですが、このチームがCDの仕組みも準備してくれており、基本的には新しい設定をPRにし、Github上でレビュー&マージすると、自動的にデプロイまで行われるようになっています。 設定についてやアーキテクチャ、こちらからのリクエストにも対応してもらえており、いつも助かっています。 開発の進め方 テストコースとしての街という前例のないプロジェクトの性格上、自分達のチームが担当しているところだけでなく、全体として未知のことが多く、当たり前に求められる機能を足がかりにして、大まかに仮説と開発プランを考え、作りながら我々自身が自分達のサービス、さらにWoven Cityについて学んでいます。 具体的には四半期ごとに大きなテーマを設定し、それに必要な機能を追加したり更新し、小規模なデモをオフィスで実施して確認するというプロセスをとっています。 そのためアジャイルな開発手法を採用し、JIRAでバックログを管理しながら、二週間をタイムボックスとして反復的に開発を行なっています。厳密なScrumのプラクティスに則っているわけではないですが、作っていくうちに判明した事実や発生した要件の変更に適応的に開発するようにしています。 おわりに このプロジェクトの難しいところは、今この時点でWoven Cityというリアルなテストコースがまだ存在しておらず、当然ユーザーも潜在的にしか存在していないことにあります。 これは我々のチームだけでなく、全てのチームに言えることです。他のチームが開発中の機能を使いたいと思っても、それがまだまだ不安定であることはしょっちゅうです。一方で一般ユーザーがいないということは、ある程度不安定であっても(少なくとも今は)構わないとも言えます。 不安定だから使わないのではなく、お互いに使って叩いて磨き上げるという精神で、この不安定な状況をお互いに楽しみ、尊重し合いながらも率直に指摘して、よりよいものを目指したい人は是非、我々のプロジェクトに参加してもらいたいです。

初めに KINTOテクノロジーズのグローバル開発グループに所属しているパンヌウェイ(PannNuWai)です。グロバール開発グループでテスト自動化チームの担当としてプロダクト開発チーム用のテスト自動化環境の構築と整備をしていたり、プロダクトのテストチームでテストスクリプトを書いています。 私は、KINTOテクノロジーズに入社するまでもテスティングは担当していましたが、入社してから初めてAppiumの自動化テストを経験し、この間、様々なものを学びました。 Appiumは経験が無く、ゼロから勉強するところからのスタートでした。最初の環境設定から手探りで行いサーバーのアーキテクチャデザインまで行うことができようになりました。 この自動化テストでは、スマホアプリをメインにテストしましたが、その中で解決した課題を共有いたします。 本記事では自動化テストためAppium version 1.22.3を使ってDarkMode(ダークモード)に切り替える方法を話したいと思います。 自動化テストとは ソフトウェアテストは不具合のある製品をリリースしてしまわないよう、ソフトウェアの問題を発見するために行う作業のことです。 本記事で「自動化テスト」とは支援ツールを用いてソフトウェアテストのプロセスを自動化することと言います。 自動化テストのメリット ^1 不具合の早期発見 コストを抑えながら品質を高められる 人的リソースが不足していてもテストできる テストを高速で実施できる ヒューマンエラーを排除できる 営業時間外でもテストできる Appium とは iOSアプリ、Androidアプリ、およびデスクトッププラットフォームではネイティブ、ウェブビュー、ハイブリッドアプリをテストするためのオープンソースツールです。[^2] [^2]: https://appium.io AppiumはJava,PHP,Pythonのプログラミング言語をサポートしているのでテスト者が好きな言語を選びながら簡単に使える自動化テストツールです。 Appiumのアーキテクチャでは Appium Client Appium Server End Device という三つのコンポーネントが有ります。 Appium Clientの中にはモバイルデバイスとアプリの詳細を設定されています。 Appium ServerにはNode.js言語を利用してjsonファイルを起動しながらシミュレーター(iOS)またはエミュレータ(Android)の接続を行います。 最後には起動されたAppium ServerによってEnd Deviceが発行されます。 Appium Inspector とは Appium InspectorはモバイルアプリのUI要系を一意に識別するための標準的な手順です。実際のデバイスまたはシミュレーター(iOS)またはエミュレータ(Android)の両方で動作します。 注意点- Appium Inspectorツールはネイティブモバイルアプリケーションの属性のみを取得するように特別に設計されているため、Web ブラウザ(Chrome)でロケーターを見つけることをサポートしていません。 Appiumデスクトップアプリケーションは、Appiumサーバー自体とElementインスペクタの組み合わせで、テストスクリプトの開発中にモバイルアプリケーションのすべての目に見える要素を検出できるように設計されています。 ^3 Dark Mode(ダークモード)とは ダークモードはスマートフォンやノートパソコンなどのユーザーインターフェースの表示設定です。 明るい画面に対して暗いテキスト(ダークモード)が表示されている代わりに、黒い画面に対して明るい色のテキスト(ライトモード)が表示されることです。 現在ではスマートフォンのAndroidとiOS両方の既存ダークモード機能だけではなく、アプリの中にもダークモード機能をよく使います。モバイルアプリの自動化テストを行う場合はダークモード機能のテストも重要なチェック項目になりました。ですので、今回はAppiumを利用してモバイルアプリのダークモードについて話したいと思います。 問題点 Appiumを利用してダークモードのテストを行う場合、問題点があります。例えば、ログイン画面に username と password の文字が表示されているかをテストする際、Appium inspectorから username と password のelement存在する場所を取得します。通常は以下の通りでelementが表示されているのをチェックするのみです。 AssertTrue(driver.findElementByXPath("USER_NAME").isDisplayed()); AssertTrue(driver.findElementByXPath("PASSWORD").isDisplayed()); ですが、ダークモードの場合、 element の存在する場所を取得して表示をチェックするだけは不十分です。画面が黒い色に変更されているかをチェックするのはダークモードの大事な点です。黒い色と白い色のhexadecimal値をチェックする必要があります。 テスト方法 では、実際にAppiumでダークモードテスケースのソースコードを書いてみましょう。 changeToDarkTheme ステップ 1 Appium inspectorからelementの存在する場所（ElementId）を取得します。 ステップ 2 デフォルト設定がライトモードになっているかどうかを assertElementColorMode(MobileElement elementId, ColorMode colorMode) で確認します。 ステップ 3 ダークモードのボタンを押下します。 ステップ 4 Display設定が　ダークモードに変わるかどうかを assertElementColorMode(MobileElement elementId, ColorMode colorMode) で確認します。 public class DisplayChangePage extends Base { public static final String THEME_CELL_ID = "id/theme_parent"; @Test(groups = "DisplayChangePage", dependsOnGroups = "Setting") public void changeToDarkTheme() { driver.manage().timeouts().implicitlyWait(60, TimeUnit.SECONDS); MobileElement themeCell = getDriver().findElementById(THEME_CELL_ID); assertElementColorMode(themeCell, ColorMode.LIGHT); themeCell.click(); driver.manage().timeouts().implicitlyWait(60, TimeUnit.SECONDS); tapElement( findElementByTextContains(ViewType.CHECKED_TEXT, resourceText("darkTheme")) ); themeCell = getDriver().findElementById(THEME_CELL_ID); assertElementColorMode(themeCell, ColorMode.DARK); } } assertElementColorMode Theme cellが存在しているElementIdと変更したいColorModeをパラメータとして設定しています。 ステップ 1 Theme cellが存在しているElementのエビデンスを取得します。 getElementBufferedImage(MobileElement element) を使ってエビデンスを画像ファイルとして保存します。 ステップ 2 保存されている画像ファイルが null にならないようにチェックします。 ステップ 3 画像ファイル(x = 10, y = 10)のポイントからカラーを取得して変更したいダークモードのカラーをチェックします。 public interface AppiumHelpersInterface extends FindElementsInterface { AppiumDriver<MobileElement> getDriver(); Device getDevice(); /** * Get buffered image of mobile element * * @param element Mobile element * @return Buffered image */ default BufferedImage getElementBufferedImage(MobileElement element) { File image = element.getScreenshotAs(OutputType.FILE); try { return ImageIO.read(image); } catch (IOException e) { return null; } } /** * Assert element's color mode * * @param element Mobile Element * @param mode Color mode */ default void assertElementColorMode(MobileElement element, ColorMode mode) { BufferedImage image = getElementBufferedImage(element); Assert.assertNotNull(image); Assert.assertTrue(Utils.getColorString(image, 10, 10).matches(mode.cellRegex())); } } getColorString 取得した画像のx-point, y-pointのカラーをhexadecimalに変更して配列を返却します。 /** * Get color string from image at point x and y * * @param image BufferedImage * @param x int * @param y int * @return Hexadecimal Color String */ public static String getColorString(BufferedImage image, int x, int y) { int rgba = image.getRGB(x, y); int[] rgb = new int[]{ (rgba >> 16) & 0xff, (rgba >> 8) & 0xff, (rgba) & 0xff }; return String.format("%02x%02x%02x", rgb[0], rgb[1], rgb[2]); } cellRegex ダークモードとライトモードの値を判断します。 public enum ColorMode { LIGHT, DARK; public String cellRegex() { // 22222 - lighter black if (this == DARK) return "2[(0-9|a-f)]2[(0-9|a-f)]2[(0-9|a-f)]"; // ffffff return "f[(0-9|a-f)]f[(0-9|a-f)]f[(0-9|a-f)]"; } } public interface ColorModeInterface { String darkModeScript(); Map<String, Object> darkModeSettings(); Map<String, Object> lightModeSettings(); default void configureDarkMode(ColorMode mode) { getDriver().executeScript(darkModeScript(), mode == ColorMode.DARK ? darkModeSettings() : lightModeSettings()); } } 注意点 この方法はAppiumを利用したケースなのでNative Appのダークモード機能だけ使えます。 まとめ 本記事では、ダークモードの切り替える方法について説明しました。 ダークモードの自動化テストのためiOS(version13以上)とAndroid(version 5.0以上)両方で使えます。 今回はNative Appのダークモードテスト機能を行いましたが、今後はWeb Appのダークモードテストも試してみたいと思います。 グローバル開発内のテスト自動化チームは12月から増員しました。今後は、チームメンバーと一緒に、Appiumだけでなく、Katalonなど他のツールも用いた自動化テストに取り組んでいきたいです。 参考 DarkMode Appium Architecture

はじめに はじめまして。KINTOテクノロジーズ オウンドメディア＆インキュベート開発グループ マネージャーの近藤です。 長いので社内でも誰も正確にグループ名を呼んでくれません。通称 メディアインキュベG でお願いします。 本記事では私のグループの紹介をさせていただきます。 グループの概要 成り立ち メディアインキュベGは、2022年8月に誕生した新生グループです。 もともとは弊社の主力サービスである 「クルマのサブスク」KINTO ONEのお客さま向けサイト の開発を一手に担う「KINTO開発グループ」というグループだったのですが、だんだんメンバーが増えてきたため、それぞれのチームをより深くマネジメントできるよう、2022年8月から2つのグループに分かれました。 ひとつが KINTO ONE開発グループ 、 そしてもうひとつが私たち オウンドメディア＆インキュベート開発グループ です。 担当プロダクト 各グループが開発を担当している主なプロダクトをご紹介します。 KINTO ONE開発グループ プロダクト 概要 URL KINTO ONE 新車サブスクリプションサービスの申し込み機能、お客さまのアフターケア・サポートを行う機能の実装 https://kinto-jp.com/customer/login オウンドメディア＆インキュベート開発グループ プロダクト 概要 URL KINTO ONE 新車サブスクリプションサービスのトップページ、取扱車種一覧、利用規約、ランディングページなどのコンテンツ制作 https://kinto-jp.com KINTOマガジン KINTO発のMaaS情報を提供するメディアサイト https://magazine.kinto-jp.com モビリティマーケット 「新しい移動のよろこび」を発見できるサービスサイト https://mobima.kinto-jp.com Prism Japan お出かけ先インスピレーションAIアプリ https://ppap.kinto-jp.com/prismjapan/index.html 中古車プロダクト KINTOが新たに手がける中古車モビリティサービス - 販売店向けプロダクト トヨタ販売店担当者向けのKINTO ONE販促ツールの開発 - ミッション 私たちメディアインキュベGのミッションは、 オウンドメディアと新規ビジネス創出において、テクノロジーとクリエイティブの力でお客さまに KINTOの価値を最大限にお届けする ことです。 グループの名前どおり 「オウンドメディア（自社保有メディア）」 と 「インキュベート（新規ビジネス創出支援）」 の二本柱です。 オウンドメディア（自社保有メディア） KINTOのモビリティサービス・プロダクトの価値をお客さまに有効にリーチさせるためのメディアを創り出す 該当プロダクト：KINTO ONE（ユーザー訴求コンテンツ）、KINTOマガジン、モビリティマーケット、販売店向けプロダクト インキュベート（新規ビジネス創出支援） KINTO ONEに続く新しいモビリティサービスをお客さまに提供すべく、KINTOと共に新規ビジネスを創出し、テクノロジーで支援する 該当プロダクト：Prism Japan、中古車プロダクト グループで取り組んでいること・取り組もうとしていること 品質担保施策 KINTO ONEのユーザー訴求コンテンツは、お客さまのご契約プロセスにおいて大変重要な情報を提供しています。 また、取扱車種やサービスの更新などのビジネスの動きに合わせ、デリバリースパンは平均して1週間です。タイミングによってはそれより短い期間でデリバリーすることもあります。 このような条件下で、一定のアジリティを出しつつクオリティも担保していかなくてはなりません。 従って、今よりさらに品質を担保できるようにするための施策検討と適用は常に行っています。たとえば次のようなものです。 CI/CDパイプラインでの自動チェック 弊社には自前のQAチームがおり、 プロダクトチームが依頼すればテストのプロフェッショナルに品質チェックを実施いただける仕組みが整っています。 ただ、ビジネスの都合によっては、QAテストまでに素材や原稿がどうしても予定通りに揃えられないケースも発生します。 そんな状況でも、抜け漏れなくデリバリーするためにはどうしたらいいか？ 私たちはこんな施策をとりました。 改修発生時点で、特定のダミー文字列を入れた仮の状態でコミットする 正しい原稿が届き次第差し替えていき、テスト環境にデプロイする QAテストまでに原稿が間に合ったものは、「正しい原稿が上がっている」という観点でテストいただく QAテストまでに原稿が間に合わなかったものは、どこがダミーであるかをQAチームに伝えた上で「ダミー原稿が上がっている」という観点でテストいただく GitHub Actionsで「特定のダミー文字列が含まれているか」のテストジョブを構築し、mainブランチへのマージ時にチェックが発動するよう設定する こうすればQAのテストも通せて、かつ本番デプロイ時にダミー原稿のまま上げてしまうことも防止できます。 コンフリクト解消時のペアプログラミング必須化 短期間で広範囲のコンテンツ改修が走るため、マージ時点でコンフリクトが発生することはままあります。 このような場合、ひとりだけの判断で解消作業をせず、必ずペアプロで同じ画面を見ながら複数メンバーで確認しつつ解消作業を行うようルール化しています。 また、コンフリクトが発生していないプルリクでも、少なくともひとり以上のレビュアーがApproveしないとマージできないようにGitHubを設定しています。 スキルアップ 様々な経歴やスキルのバックグラウンドを持つメンバーが集まっているメディアインキュベGですが、 自分の所属するプロダクトチーム以外のメンバーが今なにをやっていて、どんな課題で悩んでいるのか、 日々の業務をこなしているだけではなかなか知る機会がありません。 そこで、日常業務以外で時間をとって、各人のスキル発表や技術情報共有の機会を設けています。 勉強会 直近だと、フロントエンドエンジニアによる「デザインシステム＋アトミックデザイン勉強会」を企画しています。 バックエンドエンジニアは日々の業務でこのへんになかなか触れる機会がないので、楽しみにしているようです。 技術交流会 KINTO ONE開発グループのメンバーを含め、フロントエンドエンジニア全員参加で技術交流会をやろうとしています。 出社参加メンバーはお菓子やコーヒーなどいただきつつ、オンラインでも参加できる形式で予定しています。 グループ所属チーム・メンバー 前述の通り様々なプロダクトを手がけているメディアインキュベGですが、グループ内のチーム構成としては３つに分かれています。 各チームについて次にご紹介しますが、それぞれのチームがメインで担当しているプロダクトで表すのが分かりやすいと思いますので、 実際のチーム名とは若干異なりますがご容赦ください。 1. KINTO ONE等 メンバー（2022年12月時点） 8名 仕事の進め方 事業会社のエンジニアとして、 KINTO ONEのビジネスを理解した上でシステムとしてどうしていくべきかを考える のが最も重要な仕事です。 言われたことをただこなすのではなく、案件の内容を自分の頭で理解し、わからないことはすぐ問い返して解決し、 影響範囲や最適なロジックを自ら判断した上で案件を進めるのがこのチームの仕事のやり方です。 チームの雰囲気 メンバーの学習意欲が高く、スキルレベルの個人差はあれど、現状に満足してとどまろうとするメンバーはいません。 半期の技術スキルアップ目標もチャレンジングなものが多いです。 チームのこういった空気を牽引している技術リーダーの記事がこちらです。 SvelteKit + Svelte を1年間くらい使ってみた知見など 2. 中古車 メンバー（2022年12月時点） 4名 仕事の進め方 このプロダクトについては諸事情によりあまり具体的なことはお話しできませんが、仕事の進め方の特徴としては、 部署や所属会社の分け隔てなく、全員が意見を出し合えるワンチームとして機能している ことかと思います。 テーマ別の定例を週7本実施、KINTOビジネス側とのミーティングも毎週実施しています。 それ以外でもJiraとSlackで都度やりとりを行います。 チームの雰囲気 プロダクトマネージャーとリードエンジニアがかなり前のめりにビジネス側のプロダクトオーナーに突っ込んでいくので、 エンジニアメンバーは正直全員が全員は追いつけていない面もあるのですが、 それぞれの役割の中でスキルを上げつつ業務理解を深めようとしています。 というかそのリードエンジニアは私なんですけどね。 2021年9月に入社してすぐこのプロジェクトが始動し、以来ずっとリードエンジニアを担当していました。 とはいえ、2022年11月時点ではエンジニアメンバーも当時より増えたので、そろそろスキルトランスファーの段階に入ってきています。 新たなリーダーがチームをしっかり牽引してくれることを期待しています。 3. Prism Japan メンバー（2022年12月時点） 5名 仕事の進め方 プロジェクトマネージャーとプロダクトマネージャーがそれぞれ1名ずつ、エンジニアが3名の体制です。 2022年8月にPrism Japanをローンチして運用フェーズに入っています。 運用・リファクタのフェーズ体制はアジャイルを採用 し、そのためにQAチームから専任QAメンバーをアサインしました。 チームの雰囲気 全員が当事者意識を持って自走できているチームです。 メンバーが互いに尊敬しあい、それぞれの専門分野で長所を生かして短所を補いあう働き方ができているなと感じています。 私のすぐ後ろの席で、いつも課題や改善策についてみんなで論じ合っているのをよく耳にします。 こんな仲間を募集しています 1. KINTO ONE等 PdM システム開発の立場からプロダクトのあるべき姿を考え、提案できるようなPdMチームの設立を目指しています。 【PdM（KINTO ONE等）】の応募はこちらから フロントエンドエンジニア・バックエンドエンジニア プロダクトのあるべき姿の実現のためには、実際に手を動かせるエンジニアも不可欠です。 新しい技術を貪欲に学習し、かつKINTOのビジネスを理解してKINTOと並走していけるポテンシャルを持ったメンバーにジョインしてもらいたいと思っています。 【フロントエンドエンジニア（KINTO ONE等）】の応募はこちらから 【バックエンドエンジニア（KINTO ONE）】の応募はこちらから 2. 中古車 フロントエンドエンジニア・バックエンドエンジニア 中古車ビジネスを理解しKINTOとタッグを組んでシステム開発を進めていけるエンジニアをもっと増やしたいと考えています。 そのノウハウは、現在のプロダクトだけではなく、これから生まれるKINTOの新しいサービスやプロダクトにも必ず活かせます。 つまり、この中古車プロダクトの業務を通じて、KINTO/KTCの企業価値に大きく貢献できるエンジニアになれるはずです。 【フロントエンドエンジニア（中古車）】の応募はこちらから 【バックエンドエンジニア（中古車）】の応募はこちらから 3. Prism Japan バックエンドエンジニア ネイティブアプリの開発を通じて新たなモビリティ市場の開拓に貢献したい方、チャレンジしてみたい方にぜひジョインいただきたいです。 【バックエンドエンジニア（Prism Japan）】の応募はこちらから

Introduction On this second part about localization at KINTO Technologies, we would like to share with you what the team has accomplished so far. The task at hand On my previous article I explained how as data type software translations are often stored as a key-value pair and today we will go through how we manage this data. Having these pairs of keys and terms in mind, we proceed to determine how localization project managers handle the base English and request our Language Service Providers (LSPs) to deliver us back the translations. It is common to see -also in my experience as a freelance translator- engineers create an Excel sheet with one column of translation keys and a second column with the source language terms that are then sent to translation by adding as many columns as target languages needed. There are three main problems I see with this management style: Lack of context Inconsistency issues down the line Prone to human error First, Excel sheets are simple rows of text without any context for the translators: is the term a button? Are there any space limitations design-wise? In the case of storytelling, who is speaking and to whom in what kind of situation? The second problem is that those terms without being fed into a Translation Management System (TMS) will not be recorded anywhere. That can potentially lead to inconsistencies in quality and customer experience in the long run: are we calling it "reservation" or "booking"? And that is only with the source language; imagine this issue multiplied by the number of languages. Finally, it has a high risk of causing human errors on the development side. When the translations are stored in Excel files, they will eventually need to be painstakingly copy-pasted manually into the source code one by one (the "localizable.strings" file in our example previously). This can lead to copy-paste errors, typos, or even bugs if there is no proper QA to do the final check. How we solved it To solve these issues, we have decided not to manage translations in Excel and instead introduced a dedicated tool to manage the translation of our products, called Lokalise . Lokalise is a Translation Management System that manages translation tasks and allows us to have all terms centralized in one place. Another benefit of the tool is the ability to maintain a Translation Memory (a database that records how sentences have been translated before) and start a glossary creation -a vocabulary list- that can be applied across all our products. It also has the capability to connect to GitHub where the source files are stored, which allows us to "pull" the keys that our developers create for a new screen or new functionality, thereafter, "pushing" back all the target languages translations' key-and-term pairings with a pull request to GitHub. Automating the process this way not only raises productivity but also reduces the working time for both developers and the localization team. Furthermore, we can also maintain consistent quality, while ensuring that the integrity of the terms is kept and handed over to our engineers accurately. Another enormous benefit of using Lokalise is that it allows us to import screenshots for each of the terms from our design tool Adobe XD to Lokalise, so translators have visual context when translating in the tool and are not blindly typing away on an information-deprived Excel sheet. Below are the flow diagrams before and after implementing Lokalise for our Global KINTO app, where we also needed to deal with file conversions to have it available for both iOS and Android. Lokalise also takes care of the format conversion when exporting, saving us time: Next Steps One of our next steps is to think about scalability. We were able to automate the updates in the source files through Lokalise, but as the pull requests to each of the files are done one by one, it can quickly become a heavy task as the number of GitHub repositories and products grow over time. One solution we are considering is to create an in-house small management tool that would go in-between Lokalise and GitHub, allowing us to centralize all the pull requests with the updates needed on the source files. As part of our efforts to strengthen our QA processes, another plan is to create a series of style guides, akin to our existing Brand Guidelines. This would further ensure that even translations which are requested to our language service providers are easily understood, maintain the brand's tone and manner without gaps between translators, or even between languages. There are still more ideas and exciting projects awaiting us on the horizon, such as the potential to apply yokotenkai (horizontal deployment) of our activities to other KINTO services around the world. I might talk about these at a later point, but for now, I thank you for your interest in my post! I hope I was able to spark a bit of curiosity on this topic, and that next time you download an app, use a streaming service or play a video game, you think about the technical complexities at play for multi-region content.

はじめに はじめまして。KINTOテクノロジーズでエンジニアの教育研修を担当している熊谷と申します。 私は海外・国内問わず旅行が趣味なのですが、最近では全国各地の空港巡りに興味があります。レストランエリアがとても充実している新千歳空港や、青い海が目の前に広がる那覇空港など魅力的な空港はいくつもあるのですが、私のおすすめは、富山空港。福岡空港ほどではありませんが市街地からも近く、なにより空港内にある寿司屋が本当に美味しいです。北陸の旅に行かれる際は、是非とも立ち寄ってみてください。 さて、今日は我々の組織、エンジニアリング教育研修PJTが普段どういうことをやっているのかをざっくりご紹介させていただきたいと思います。 プロジェクトが始まったきっかけ 私たちは、2022年8月に本格始動した、いわば出来たばかりの組織です。 KINTOテクノロジーズでは積極的に採用活動を行なっており、エンジニア・デザイナー・QAエンジニアなど含め300名近い組織になってきました。 しかしながら、ここ１、２年で急激に拡大をしたため、 これからはこのプログラミング言語で開発をしていくからこういうスキルを持っていてほしい、 あるいは、このキャリアの先にこういったキャリアパスがあってほしい、 といった議論が乏しいままここまで来てしまったという現実があります。 そこで我々は、エンジニア陣が持っているスキルを再整理し、必要なスキルを学びたいときに研修を受けられる環境を作ることを目指して立ち上がりました。 また同時に、エンジニアが抱えている不満や不安を組織の面から改善し、リテンションを上げていく活動もしています。 自走するエンジニア 私たちのミッションとしては、自走できるエンジニアのために何をサポートできるか、を常に考え、行動に移していくことを心がけています。 グループで現在取り組んでいること 教育 研修の一環として、トヨタ生産方式(Toyota Production System：TPS)の研修が実現できました。 私個人としてせっかくトヨタの関連会社に入社したのだから、リーン開発方式の元となったトヨタ生産方式をもっと知りたいと思っておりました。しかし社内でそのような研修はなかったため、トヨタ自動車にお願いして、２回にわたってTPS研修を開催していただき、50名を超える方々にご参加いただきました。「モノ情」と言われる物と情報の流れ図を書くことにより、どこにムダがあるのか、どこに効率化を阻む要素があるのか、を図で分かるようになり、KINTOの業務でも活かすことができています。 グローバル開発グループでは、社内の縦割りが不満に感じているエンジニアが多いことに加え、勉強会でも座学だけだと飽きるという声を受けて、Innovation Dayという企画をやってみようということになり、サポートしています。 また、KINTOテクノロジーズではAWS(Amazon Web Service)やGCP(Google Cloud Platform)といったパブリッククラウドを全面的に採用しており、AWSやGCPの中で私たちをサポートしてくださる方々とも交流が活発になってきています。サポートエンジニアの方々を定期的にお招きして勉強会を実施する等、AWS、GCPの方々と皆で一緒にパブリッククラウドを盛り上げています。 組織開発 社員サーベイにおいて、社内の情報共有が少ないという不満が多く上がっていました。KINTOテクノロジーズでは月一回全社でおこなっているミーティングはあったのですが、一方的な伝達ばかりのことも多く、相互に情報を共有する場になっていないと感じていました。そこで本部会の運営を見直し、本部長からの開発・事業報告の時間に加え、新たに開設したオフィスの紹介を生中継で行ったり、チャットをオープンにしてタイムリーに質問を受け付ける等の改善をおこなっています。そうすることによって、社内のことがよく分かった、社内の風通しが良くなった、との声が多くいただいています。まだまだ改善の途中ではありますが、引き続きオープンで双方向のコミュニケーションを取れるように尽力していきます。 また、毎月多くの中途採用者に入社いただくのですが、自グループ以外のマネージャーとの接点がないため話しかけづらいという声も耳にしています。そこでOJT期間中に他グループのマネージャー、リーダー陣とコミュニケーションが取れるよう、ビルドアップ(関係性の構築を意味するサッカー用語ではありますが)をしていただくように推奨しています。これにより、社内の多方面でのコミュニケーションがより活発になることを期待しています。 グループメンバー メンバーは今のところ２名体制の少数精鋭チームです。私の他に人材エージェントから転職してこられた方もいますので、その営業力を活かし、カンファレンスのスポンサードや生産性指標を測るツールの導入などを積極的に社内提案しています。その生産性指標のツールの導入をきっかけにオンラインのイベントへの登壇依頼をいただくなど、日々の活動がさまざまな新しい出会いを産み出し、活動の輪をより広げていけています。 また、チームはスクラムのメソッドを使っています。２週間を１スプリントとして、スプリントごとに予定タスクと実績を洗い出しています。私たちは長期にわたる施策を実施することも多いのですが、長期施策は抽象的な話が多く具体的に進めることが時に困難です。ですがスクラムを用いることによって、短期的にチェックポイントを設けそれにコミットすることを通じ、長期的な施策もより具体性を持って進められるメリットがあると感じられるからです。 これから挑戦したいこと まずは、エンジニアスキルを明文化したいと考えています。KINTOテクノロジーズにはこういう人材が集まっていて、こういう点は強みを発揮できる、けれどもこういうスキルが足りないと思われるから研修でそれを補おう、という戦略を立てやすくしたいと思っています。 また、定期的に社員サーベイを取れる仕組みを導入することを検討しています。組織開発は一度に成果があらわれるものでもなく、さまざまな施策を組み合わせた結果として徐々に社員の離職率が下がるのだと思います。ですので、定期的に社員サーベイを実施して、今月はこの施策が効いたから次はブラッシュアップしてみよう、といったさまざまな改善ができたらいいと思っています。

Introduction Nice to meet you. My name is Kumagai, and I’m in charge of the Engineering Education Training Project at KINTO Technologies. I enjoy traveling both in Japan and abroad, and recently I've taken a particular interest in visiting airports across the country. There are many appealing airports, such as New Chitose Airport with its excellent dining options, and Naha Airport, where the deep blue sea stretches out right before your eyes. My personal favorite, however, is Toyama Airport. It's not quite as close to the city center as Fukuoka Airport, but it's still very convenient. Most of all, the sushi restaurant inside the airport is absolutely delicious. If you’re traveling in the Hokuriku region, I highly recommend stopping by. Today, I’d like to give you a brief overview of what our team, the Engineering Education Training Project, usually does. How the Project Started We are a newly formed team that officially began full-scale operations in August 2022. KINTO Technologies has been actively expanding its hiring efforts, and our organization has grown to nearly 300 members, including engineers, designers, and QA engineers. However, because of the rapid growth over the past year or two, we’ve reached this point without having much discussion around key topics, such as which programming languages we’ll focus on moving forward and what skills will be expected, or what kind career paths we hope to offer. To address this, we launched the project with the goal of reorganizing the skills our engineers currently have and building a system where they can access training whenever they want to learn something new. At the same time, we’re also working to improve the organizational issues that cause frustration or uncertainty among engineers, with the aim of increasing retention. Self-Driven Engineers Our mission is to continuously think about how we can support engineers who work independently, and to put those ideas into action. What the Group Is Currently Working On Education As part of our training efforts, we were able to offer a session on the Toyota Production System (TPS). Personally, since I had the opportunity to join a Toyota group company, I had always wanted to learn more about TPS, the foundation of lean development practices. At the time, the company had no such training program, so we arranged for Toyota Motor Corporation to hold two TPS sessions, drawing participation from over 50 people. By creating flow diagrams of goods and information, known as "monojou," participants were able to visualize sources of waste and factors that block efficiency. This has proven useful in our daily work at KINTO. In the Global Development Group, many engineers have expressed frustration with the siloed structure within the company. Others have said that study sessions become dull if they are purely lecture-based. In response, we decided to support a new initiative called Innovation Day. KINTO Technologies has also fully adopted public cloud platforms such as AWS (Amazon Web Services) and GCP (Google Cloud Platform), and we’ve been deepening our collaboration with the people who support us within these platforms. We regularly invite support engineers to lead study sessions, and together with the teams from AWS and GCP, we’re working to promote and energize the use of public cloud. Organizational Development In an employee survey, many people expressed dissatisfaction with the lack of information sharing within the company. At KINTO Technologies, we held a company-wide meeting once a month, but it often consisted of one-way communication. We felt it wasn’t functioning as a place for mutual information sharing. To address this, we reviewed how the meeting is run. In addition to setting aside time for the Director General to share development and business updates, we now livestream introductions to newly opened offices and keep chat channels open to accept questions in real time. As a result, we’ve received a lot of positive feedback, such as “I have a better understanding of what’s going on in the company” and “Communication has become more open.” We’re still in the middle of making improvements, but we’ll continue working to create an open environment that enables two-way communication. We also welcome many mid-career hires each month. However, we’ve heard that it can be hard for them to approach managers outside their own group because they don’t have opportunities to interact. To improve this, we encourage communication with managers and leaders from other groups during the OJT period, recommending that they engage in “build-up”, a soccer term that refers to building connections. We hope this will lead to more active communication across different divisions of the organization. Group Members At present, we are a small team of two. In addition to myself, we have a member who joined from a recruitment agency. Leveraging their sales expertise, we actively propose ideas within the company, such as sponsoring conferences and introducing tools to measure productivity. The introduction of one such productivity tool even led to invitations to speak at online events. These kinds of daily efforts continue to create new connections and help us expand the reach of our activities. Our team also follows the Scrum methodology. We operate in two-week sprints, reviewing both planned tasks and achievements each cycle. Many of our initiatives span the long term, and such efforts often involve abstract discussions that can make concrete progress difficult at times. However, using Scrum allows us to set short-term checkpoints and commit to them, which helps us move forward with long-term initiatives in a more concrete and actionable way. What I Want to Try Next First of all, I want to clearly define and document the engineering skills we have. By doing so, I hope to make it easier to develop strategies that identify the types of talent we have at KINTO Technologies, highlight our strengths, and recognize areas where skills are lacking so we can address them through training. We’re also considering introducing a system that allows us to conduct regular employee surveys. Organizational development doesn’t yield results overnight. I believe that by combining a variety of initiatives, we’ll gradually see a reduction in employee turnover. That’s why I’d like to conduct regular surveys and make ongoing improvements. If a certain initiative proves effective in a given month, we can refine it and apply it again moving forward.

こんにちは。KINTOテクノロジーズ、クリエイティブグループでアートディレクションを担当しているアワノと申します。普段は社内全般の視覚に映るコンテンツの方向性をまとめ、決めることなどが仕事です。 今回は、KINTOテクノロジーズテックブログが生まれた時のお話を少しばかりさせていただきます。拙文、読みづらい点ご容赦ください。 はじまりは、 社内エンジニアの情熱がきっかけ 元々TOYOTAから生まれたクルマのサブスクを中心に、モビリティサービスを展開するKINTO。KINTOのテクノロジー部分を担う部署が、KINTOテクノロジーズ。広くモビリティ分野をテクノロジーの力でドライブさせていくことが期待されています。 私たちのヴィジョンやカルチャーに共感してくれる仲間を増やしたい 私たちのヴィジョンやカルチャー、働き方や使っている技術など、どこかに目に見える形になっていたっけ？発信したりしていたっけ？ということで、テックブログで会社の取り組みを発信していこうとなりました。 社内外の人や想いをつなぐ存在になりたい 上述の通り、大きな目的は、社内の取り組みを発信する仕組みを作り知ってもらおう。そして、その中で想いを同じにしてくれる仲間に興味を持ってもらおう。ということで始まりましたが、 次に、人数も増え、組織も拡大したことから、まだまだ社内での情報共有も整っていない部分があり、あの部署では、どんなことやっているのだろうということが普通にあり、ブログを通して普段取り組んでいること、使っている技術、思っていること、興味を持っていることなどを発信することによって、社内でも人と人を繋ぐような存在に育っていけばいいなということも。 私たちの想いをロゴにしたい 発起人のエンジニアの有志グループが中心となって、上述のような目的や要望をまとめ、それを叶えるためのサイトや運用体制などの要件をまとめていきました。社内での共有を経て、無事プロジェクト化。その後、ロゴがあった方がいいということで、クリエイティブグループに声がかかりました。 （さも、自分がかなり関わっていたかのように語ってしまいましたが、私がプロジェクトに関わったのは、ここが最初です。すみません。） そこで、まずは目標や目的、想いなどをコアエンジニアのメンバーにヒアリングさせていただきました。 そこででてきたのがこのような想い。 （すでにまとめられていました） テックブログのVision アウトプットカルチャーをリード テックブログのMission 業務で得た知識を発信する事で理解を深め、世界へ還元する事でテクノロジーの発展に寄与する テックブログのValues 組織の枠を越えたネットワーク構築 情報発信の壁を取り除きアウトプット力強化 文化を醸造する事で採用力を高めエンゲージメント向上 また、KINTOテクノロジーズのメンバーの「舞台裏」を「表舞台」にという想いも。 上述のテックブログのVisionやMissionなどの想いを元に、柔らかくお話しをしながら、造形のヒントとなるキーワードを抽出していきました。 （個人的に、柔らかさは、忌憚のない意見交換に重要だと思っています） このキーワード、方向性を元に社内のデザイナーにラフを作ってもらいます。 （実際のロゴも自分で作るわけではなく、デザイナーと対話しながら詰めていき、実際手を動かして作るのは、デザイナーさんです。） 初回のロゴのラフ案 全体は上述で抽出した方向性をとらえつつ、各案で、それぞれ押し出したいポイントの割合を変えて作っていきます。この時に、より、いろんな使用シーンでの見え方も含めて選んだ方がいいので、PCで表示の場合、スマートフォンで表示の場合、バナーで表示の場合など、いろんな表示場所にロゴを入れたものもセットでつくります。 （違うところで使おうとすると、どうしてもうまくはまらない。なんかぴったりはまってない。ということを後々感じることが極力ないように。） プロジェクトメンバーに見てもらう テックブログのコンセプトを元に、方向性ごとに数案作成し、プロジェクトメンバーからリクエストや感想を引き出し、いいね！というリアクションがもらえれば、よりコンセプトに合う案を絞っていきます。ここで、ん、みたいな空気になると、求めていた期待とギャップがあるということになり、その差を話しながら埋めていく作業まで戻ります。2マス戻るやふり出しに戻るみたいな感じです。）また、ミーティング中にみんなから意見が出たものは、その場でデザインを調整しつつ、タイムリーに意見をデザインに反映しながら方向性を絞っていけたのも良かったです。 大枠の案や方向性が決まり、ここから、決まった案の細部を調整していくブラッシュアップ作業に入っていきます。細かいズレ、バランス、などで受ける印象が結構違ったりするので、地道に詰めていきます。方法は、基準をまず作り、地道にちょっとずつ変化させたパターンを並べて、ベストを探っていくみたいなやり方です。 よし、バランス良いな！他も試してこのバランスがいいなとなったら、使い道に合わせた形状や色のパターンを作っていきます。 最終的に、できたのがこちらです。 （実制作は社内のデザイナーさんです） はめて完成 あとは、実際のテックブログにはめていただき、問題なければ完成です！ ガイドラインにまとめる 間違った使われ方がされないように、ルールを決めて、ガイドラインを作成します。「ロゴ周りの余白はこの位確保してね。」とか、「変形や装飾などで違う印象を見る人に与えないようにしてね。」など細かく定義していきます。 終わりに こんな感じで、想いを同じにした仲間たちと一緒により良い形を模索しながら進んでいます。テックブログを読んでいただき、私たちの思っていることや、やっていること、に興味を持っていただけましたら幸いです。それでは、またの機会に。

はじめに こんにちは。KINTOテクノロジーズでバックエンドを担当している森本です。 KINTO ONE開発グループに所属しています。Javaをメインに利用してKINTO ONEの開発をしています。今回は業務とは別に実施しているGraphQLの勉強会について紹介させていただきます。 GraphQLとは GraphQLとはクエリ言語の一つです。SQLのような他の言語とは異なり、特定のデータストアに限らず複数のデータソースとデータをやりとりすることができます。 バックエンド側でスキーマを定義しておけば、フロントエンド側はその定義に従って自由にオブジェクト内の項目を取得することができます。REST APIとは異なり、フロントエンドがバックエンドから返却してほしい情報を柔軟に指定できます。利用しない情報を無駄に取得する必要がなくなり、またネスト構造になっているオブジェクトを取得するために複数回APIを呼ぶ必要もなくなります。 勉強会の目的 勉強会の目的は以下の2つです。 技術力をアップしたい グループを超えて交流したい 技術力をアップしたい 普段の業務で利用している技術とは別に新しい情報をキャッチアップしたいが、ハードルが高いとメンバーそれぞれが感じていました。例えば言語の知識が足りないことが挙げられます。今回のGraphQLのチュートリアルではTypeScriptが利用されていました。そのため、GraphQLを学ぶ前にまずTypeScriptを学ぶ必要がありました。知識や経験が異なるもの同士で補うことで、このような課題をクリアして学習のコストを下げることができます。 グループを超えて交流したい 所属するグループ、チーム、プロジェクトがそれぞれ異なる年齢の近いメンバー同士が交流するきっかけにしたいという思いもありました。既にお互いを認知している仲の良いメンバー同士ではありますが、定期的に集まることでより仲良くなろうという魂胆です。また勉強会を通してお互いの持っている新たな一面を知ることができる機会になるとも考えました。 実施内容 なぜGraphQLか バックエンドでAPIを普段実装しているメンバーは、要件が発生するたびAPIを作成する必要があることに悩みを抱えていました。もちろんサーバー側で処理を行った方が実行速度が速いものはありますが、情報をそのまま返却するAPIを増やしていくのは面倒だと感じていました。そこでGraphQLが解決策として良さそうだという話を聞き、ぜひ試したいと常々思っていました。 また既にGraphQLを利用したことがあるメンバーもいましたが、全体の処理の流れを把握したいという思いがあり、GraphQLを学習することにしました。 勉強会に利用したチュートリアル GraphQLのライブラリにはApollo GraphQLを選び、チュートリアルは以下リンク先のものを使用しました。 GraphQL Tutorials 理由としては、チュートリアルの量が充実しており、入門編として適切だと感じたためです。また勉強会メンバー内に業務でApollo GraphQLを利用したことがある人がいたため、既に社内で実績があると判断したためです。 勉強会の概要 日時 週に1回、18時以降でメンバーの時間が揃うところで実施しました。 メンバー メンバーは25歳から28歳までの若手8人です。それぞれ所属が異なり、Webアプリのフロントエンド・バックエンド、またモバイルアプリのフロントエンド・バックエンドと多様な経験を持つメンバーが集まりました。 実施した範囲 チュートリアルのLift-off IからVまでの全5章を実施しました。GraphQLを実装するにあたり、基本的な事項が記載されています。 形式と工夫した点 勉強会では以下の流れで実施しました。 もくもく会でチュートリアル実施 チュートリアルの内容を発表形式でアウトプットして知識定着 初めはいわゆるもくもく会を実施しました。もくもく会とは、集まったメンバーがそれぞれ黙々と作業・学習をする勉強会のことを指します。 Apollo GraphQLを利用したことのあるメンバーもいると記載しましたが、それでも処理の全体像を把握しているメンバーはいませんでした。そのため、まずはそれぞれが同じチュートリアルを実施し、分からないことが出てきたタイミングで話し合いをして解決する、という流れで実施しました。 しかし本当に理解できているか怪しく、このまま先に進むよりはまずは復習するべき、との意見が出ました。そこで同じチュートリアルを持ち回りで発表し合うことにしました。 発表形式では、発表者はチュートリアルを一言一句理解する必要がありました。もくもく会ではなんとなく進んでいた箇所も、あらためて読み直すと答えが書いてあったということもありました。発表の際には質問ができたり、ソースコードを変更して試してみたり、1人では見つけられなかった新たな気づきもありました。 勉強会の様子。手前には勉強会用に用意したサンドイッチが写っています。 さいごに まずはGraphQLについて深く理解できました。それぞれが持っている知識・経験を使ってお互いを補い合うことで、1人よりも速く・確実に進められました。また学習を共にする仲間がいることで、挫折しそうなときも諦めずに続けられました。 今後はApollo GraphQLのチュートリアルの残っている章を進めたり、さらに新しい技術事項を取り上げて学んでいったりする予定です。 また、何らかのアプリケーションを作ってみたいという話も上がっています。それぞれがトライしてみたい言語やフレームワーク、アーキテクチャを利用してみて、さらに技術力向上に努めていきたいと思います。

はじめに こんにちは。KINTOテクノロジーズでバックエンドを担当している森本です。 KINTO ONE開発グループに所属しています。Javaをメインに利用してKINTO ONEの開発をしています。今回は業務とは別に実施しているGraphQLの勉強会について紹介させていただきます。 GraphQLとは GraphQLとはクエリ言語の一つです。SQLのような他の言語とは異なり、特定のデータストアに限らず複数のデータソースとデータをやりとりすることができます。 バックエンド側でスキーマを定義しておけば、フロントエンド側はその定義に従って自由にオブジェクト内の項目を取得することができます。REST APIとは異なり、フロントエンドがバックエンドから返却してほしい情報を柔軟に指定できます。利用しない情報を無駄に取得する必要がなくなり、またネスト構造になっているオブジェクトを取得するために複数回APIを呼ぶ必要もなくなります。 勉強会の目的 勉強会の目的は以下の2つです。 技術力をアップしたい グループを超えて交流したい 技術力をアップしたい 普段の業務で利用している技術とは別に新しい情報をキャッチアップしたいが、ハードルが高いとメンバーそれぞれが感じていました。例えば言語の知識が足りないことが挙げられます。今回のGraphQLのチュートリアルではTypeScriptが利用されていました。そのため、GraphQLを学ぶ前にまずTypeScriptを学ぶ必要がありました。知識や経験が異なるもの同士で補うことで、このような課題をクリアして学習のコストを下げることができます。 グループを超えて交流したい 所属するグループ、チーム、プロジェクトがそれぞれ異なる年齢の近いメンバー同士が交流するきっかけにしたいという思いもありました。既にお互いを認知している仲の良いメンバー同士ではありますが、定期的に集まることでより仲良くなろうという魂胆です。また勉強会を通してお互いの持っている新たな一面を知ることができる機会になるとも考えました。 実施内容 なぜGraphQLか バックエンドでAPIを普段実装しているメンバーは、要件が発生するたびAPIを作成する必要があることに悩みを抱えていました。もちろんサーバー側で処理を行った方が実行速度が速いものはありますが、情報をそのまま返却するAPIを増やしていくのは面倒だと感じていました。そこでGraphQLが解決策として良さそうだという話を聞き、ぜひ試したいと常々思っていました。 また既にGraphQLを利用したことがあるメンバーもいましたが、全体の処理の流れを把握したいという思いがあり、GraphQLを学習することにしました。 勉強会に利用したチュートリアル GraphQLのライブラリにはApollo GraphQLを選び、チュートリアルは以下リンク先のものを使用しました。 GraphQL Tutorials 理由としては、チュートリアルの量が充実しており、入門編として適切だと感じたためです。また勉強会メンバー内に業務でApollo GraphQLを利用したことがある人がいたため、既に社内で実績があると判断したためです。 勉強会の概要 日時 週に1回、18時以降でメンバーの時間が揃うところで実施しました。 メンバー メンバーは25歳から28歳までの若手8人です。それぞれ所属が異なり、Webアプリのフロントエンド・バックエンド、またモバイルアプリのフロントエンド・バックエンドと多様な経験を持つメンバーが集まりました。 実施した範囲 チュートリアルのLift-off IからVまでの全5章を実施しました。GraphQLを実装するにあたり、基本的な事項が記載されています。 形式と工夫した点 勉強会では以下の流れで実施しました。 もくもく会でチュートリアル実施 チュートリアルの内容を発表形式でアウトプットして知識定着 初めはいわゆるもくもく会を実施しました。もくもく会とは、集まったメンバーがそれぞれ黙々と作業・学習をする勉強会のことを指します。 Apollo GraphQLを利用したことのあるメンバーもいると記載しましたが、それでも処理の全体像を把握しているメンバーはいませんでした。そのため、まずはそれぞれが同じチュートリアルを実施し、分からないことが出てきたタイミングで話し合いをして解決する、という流れで実施しました。 しかし本当に理解できているか怪しく、このまま先に進むよりはまずは復習するべき、との意見が出ました。そこで同じチュートリアルを持ち回りで発表し合うことにしました。 発表形式では、発表者はチュートリアルを一言一句理解する必要がありました。もくもく会ではなんとなく進んでいた箇所も、あらためて読み直すと答えが書いてあったということもありました。発表の際には質問ができたり、ソースコードを変更して試してみたり、1人では見つけられなかった新たな気づきもありました。 勉強会の様子。手前には勉強会用に用意したサンドイッチが写っています。 さいごに まずはGraphQLについて深く理解できました。それぞれが持っている知識・経験を使ってお互いを補い合うことで、1人よりも速く・確実に進められました。また学習を共にする仲間がいることで、挫折しそうなときも諦めずに続けられました。 今後はApollo GraphQLのチュートリアルの残っている章を進めたり、さらに新しい技術事項を取り上げて学んでいったりする予定です。 また、何らかのアプリケーションを作ってみたいという話も上がっています。それぞれがトライしてみたい言語やフレームワーク、アーキテクチャを利用してみて、さらに技術力向上に努めていきたいと思います。

About me I am Bharath from Global KINTO. I am a part of Global KINTO ID Platform team and product engagement team. I have also been supporting ad hoc projects like TechPortal and UserPool management screen. I am well versed in OIDC and AWS Cognito. Feel free to reach me anytime at bharath.tv@kinto-technologies.com if you would like to discuss these. I am always excited to talk about ID. About today's topic In order to create contact points with overseas group companies, cultivate the ability to play an active role in the global arena, and further evolve as a global technology company, KINTO Technologies (hereinafter referred to as KTC) participated in the global hackathon "toyotaswarm" hosted by Toyota Motor North America (hereinafter referred to as TMNA) on July 2022. Since I participated in this event from Japan remotely as well, today I'd like to share what we did for this event. Regarding TMNA “SWARM“ Hackathon The second year of this initiative was held over three days from July 27 to 29, 2022, with a total of 270 participants in 40 teams from Toyota Group companies around the world. There were 3 challenges announced this year. #1 Safety #2 Innovate to Carbon Neutral #3 Open Global Technology Innovation Since we thought digital identity is a major challenge and my team has been working on this topic so far, we were selected to participate in the hackathon this year. Idea from our team We at Global KINTO, are focused on making it all easy and simple for the end user to access our mobility services. Our Global KINTO App, aims to be the single app that connects all KINTO services. My team, Global KINTO ID aims to make it easy for end users to access any KINTO service across the globe by registering only once. So the problem we wanted to address in the hackathon also was a similar one. How an end user can share their information across services hassle-free. It doesn’t make sense when a user has to share their name and other details repeatedly to start using a different service. We decided to do a PoC (proof of concept) of a service that can share user information with other services upon consent from the user. About our team Due to visa restrictions, we only have 3 members who participated in the event at Dallas (HQ of TMNA in Texas, US) and the remaining members supported the activity from Japan remotely. Onsite team: Captain: Feng Xu (Group manager) PdM: Dai Sasaki FE: Alex Remote team: FE: Chris.L BE: Bharath During the hackathon We got all warmed up in a few days, and finalized our concept and how to achieve it. Finally, even though we only had 3 members onsite, that didn’t stop us from going forward. We brushed up the idea with the team and built 9 screens, 11 APIs, including many AWS components and over 1100 LoC (Lines of Code). The event started upbeat when the Olympic gold medal winner, Erin Jackson joined us in the event. This is the closest we would have ever gotten to a Olympic medal. The teams were given separate tables to start working on their concepts. It was nice to see all the hyped-up teams get into action. Meanwhile, my team had a tough time getting work done due to a few of us working offsite in a different time zone. It was quite clear what actions each of us should do but we have to integrate everything to come up with the working model. Typical problems like connecting our server to a different IP address or working with AWS CDN in a different region happened but overall things went well. As a result, we cleared round 1. Since only half the teams would pass round 2, it was stressful. We did our best but unfortunately that we didn't pass round 2. What impressed me here was the high degree of perfection of the other teams' ideas. As an example, the idea of prevention of drunken driving and the idea of reducing carbon emissions passed round 2. For both of these, they do not only have a software part, but they also had an embedded solution proposal which included both software and hardware. What we learned from participating TMNA senior management was around the hackathon the whole day, anyone can easily talk with them if they wanted. It was a great opportunity to get close to them and understand their thoughts directly. The people who came from other countries were very open and kind to connect with us. It was a perfect opportunity to make connections between several different organizations which hopefully creates some synergy. Since this event is going to be a regular event from now, we are looking forward to participating in it next time as well and bringing more value for Toyota and the whole world through this activity.