はじめに みなさまはじめまして。KINTOテクノロジーズのIT管理チームでコーポレートエンジニアをしておりますT.S.と申します。 こちらに IT管理チームの紹介記事 がございますので合わせてご覧ください。 私たちIT管理チームは日々KINTOテクノロジーズというエンジニア組織の生産性を高められる社内IT環境を目指して奮闘しております。 社内IT環境は様々な要素で構成されていて一度に全てをご紹介するのは難しいので、本記事ではデバイス管理についてご紹介できればと思います。 デバイス管理って？ 前提 KINTOテクノロジーズでは全スタッフに1台ずつ ノートPC(Windows or Mac) スマートフォン を貸与しております。そのため社内の誰がどのデバイスを利用しており、デバイスの状態はどうか？といった把握・管理ができることで「快適な開発環境を支える」を実現しやすくなる訳です。 MDMとは？ 前提の通り、全スタッフがモバイルデバイスをご利用されるということで、「Mobile Device Management（モバイル・デバイス・マネジメント）」ツールを導入しております。 そうです。一般的にMDMツールなどと呼ばれているものです。 MDMで何ができるの？ そもそもMDMとはノートパソコンやスマートフォン、タブレット端末といったモバイル端末に対してデバイスの設定を実施したり、アプリケーション配布を行ったりといった管理・運用を行うツールです。 それだけならそこまで頑張って管理する必要があるの？と思われる方も多いと思いますが・・・ KINTOテクノロジーズにオンプレはありません よって日々業務に利用するSaaS(※)から見て信頼できるデバイス(≒管理されたデバイス)であるかどうかはセキュリティ的に重要事項です。しかしセキュリティがガチガチなだけでなく開発環境として利便性を落とさないためには、デバイスの何を管理しどこをお任せするか、きちんと考え運用する必要があります。 ※SaaS = 「Software as a Service」 クライアントに導入インターネットなどネットワーク経由で利用するサービス デバイス管理としてここは管理したい、利用者にお任せし端末利用の利便性を下げない区分けはこんなイメージでした 管理できた方が良さそう お任せできると素敵 ・セキュリティ関連ツールの動作 ・データ漏えい措置 ・紛失時等のデータ消去手段 ・不正な接続先への通信 ・資産管理 ・業務に必要なアプリケーション ・利用者ごとの環境設定 ・キーボード、マウス等の周辺機器 ・物理的な端末の保管、管理 KINTOテクノロジーズのデバイス管理 概要 結論としてKINTOテクノロジーズのMDMはこのような構成です。 項目 利用サービス IdP(※) Azure Active Directory Windowsデバイス スマートフォン Microsoft Intune Macデバイス Jamf Pro ※IdP = 「Identity Provider」認証サービスの提供、アカウント情報管理を行う仕組み 課題 KINTOテクノロジーズは急成長フェーズということで毎月多くのスタッフが入社されており、スタッフの数だけデバイスは増加しさすがに人力で管理運用し続けるの厳しい状況になります。 そこで以下の課題解決をするため、デバイス管理のシステム化に至りました。 デバイスキッティング工数 デバイス情報の管理 インストールするアプリケーションの管理 OSアップデートサイクルの制御 暗号化の適用、回復キーの管理 リモートロック、リモートワイプ 導入 改めて業務環境を考えると・・・ 業務環境 PC -> WindowsとMacが選択可能 スマートフォン -> 全員支給 環境 -> フルクラウド グループウェア -> Microsoft 365 という前提から、WindowsデバイスとスマートフォンはMicrosoft 365と親和性の高いAzure Active Directory + Microsoft Intuneです。 MacもMicrosoft Intuneで管理し、MDMプラットフォーム統一！という手段もありますが、ことApple製品運用においては圧倒的な実績もあり、設定の同期が早く管理ポリシー・項目の柔軟性からJamf Proで管理することとしました。 構成はこのようなイメージです デバイス管理の概要 結果 No. 項目 結果 1 デバイスキッティング工数 →設定周りを含めキッティング時の工数は下がった △ 2 デバイス情報の管理 →さらば台帳、管理コンソールようこそ ○ 3 インストールするアプリケーションの管理 →個別管理が一元管理に △ 4 OSアップデートサイクルの制御 →デバイス利用者任せから一元管理に ○ 5 暗号化の適用、回復キーの管理 →1台1台の作業からシステム管理に、特にキー管理のシステム化は嬉しいポイント！ ○ 6 リモートロック、リモートワイプ →対応可能に！ ○ 以上の結果から当初の課題に対しては概ねクリアでき、ようやくデバイス管理のスタートラインに立てた状態ではないでしょうか。 スタッフの皆様により良い体験をお届けするため、デバイス管理運用の改善を進めていきたいと思います。 今後やっていきたいこと 1. ゼロタッチキッティングの実現 キッティング要件等を整理しゼロタッチを実現し、デバイスにかかるオンボーディングの時間を削減し、業務に向けたオンボーディングの時間にできればと思います。 2. アプリケーション運用の効率化 一元管理は実現できたものの、必要になった際より柔軟にタイムリーにお応えできるようここの運用をより洗練させていきたいと思います。 3. デバイス状態の管理運用 MDMに登録された管理対象デバイスとしてだけでなく、インベントリ等のデバイス状態に応じた細かい制御・運用を実現しデバイスの状態をより良い状態に保てるようにしていきたいと考えております。 最後に ここまで読んでいただきありがとうございました。これからも全社に貢献し事業に貢献できる社内IT環境を目指し業務に精励していきたいと思います。 We are hiring! KINTOテクノロジーズでは一緒にモビリティの未来を創る仲間を募集しています。カジュアル面談なども行っておりますのでご興味をお持ち頂けましたらぜひお気軽にご連絡ください。 https://www.kinto-technologies.com/recruit/

はじめに みなさまはじめまして。KINTOテクノロジーズのIT管理チームでコーポレートエンジニアをしておりますT.S.と申します。 こちらに IT管理チームの紹介記事 がございますので合わせてご覧ください。 私たちIT管理チームは日々KINTOテクノロジーズというエンジニア組織の生産性を高められる社内IT環境を目指して奮闘しております。 社内IT環境は様々な要素で構成されていて一度に全てをご紹介するのは難しいので、本記事ではデバイス管理についてご紹介できればと思います。 デバイス管理って？ 前提 KINTOテクノロジーズでは全スタッフに1台ずつ ノートPC(Windows or Mac) スマートフォン を貸与しております。そのため社内の誰がどのデバイスを利用しており、デバイスの状態はどうか？といった把握・管理ができることで「快適な開発環境を支える」を実現しやすくなる訳です。 MDMとは？ 前提の通り、全スタッフがモバイルデバイスをご利用されるということで、「Mobile Device Management（モバイル・デバイス・マネジメント）」ツールを導入しております。 そうです。一般的にMDMツールなどと呼ばれているものです。 MDMで何ができるの？ そもそもMDMとはノートパソコンやスマートフォン、タブレット端末といったモバイル端末に対してデバイスの設定を実施したり、アプリケーション配布を行ったりといった管理・運用を行うツールです。 それだけならそこまで頑張って管理する必要があるの？と思われる方も多いと思いますが・・・ KINTOテクノロジーズにオンプレはありません よって日々業務に利用するSaaS(※)から見て信頼できるデバイス(≒管理されたデバイス)であるかどうかはセキュリティ的に重要事項です。しかしセキュリティがガチガチなだけでなく開発環境として利便性を落とさないためには、デバイスの何を管理しどこをお任せするか、きちんと考え運用する必要があります。 ※SaaS = 「Software as a Service」 クライアントに導入インターネットなどネットワーク経由で利用するサービス デバイス管理としてここは管理したい、利用者にお任せし端末利用の利便性を下げない区分けはこんなイメージでした 管理できた方が良さそう お任せできると素敵 ・セキュリティ関連ツールの動作 ・データ漏えい措置 ・紛失時等のデータ消去手段 ・不正な接続先への通信 ・資産管理 ・業務に必要なアプリケーション ・利用者ごとの環境設定 ・キーボード、マウス等の周辺機器 ・物理的な端末の保管、管理 KINTOテクノロジーズのデバイス管理 概要 結論としてKINTOテクノロジーズのMDMはこのような構成です。 項目 利用サービス IdP(※) Azure Active Directory Windowsデバイス スマートフォン Microsoft Intune Macデバイス Jamf Pro ※IdP = 「Identity Provider」認証サービスの提供、アカウント情報管理を行う仕組み 課題 KINTOテクノロジーズは急成長フェーズということで毎月多くのスタッフが入社されており、スタッフの数だけデバイスは増加しさすがに人力で管理運用し続けるの厳しい状況になります。 そこで以下の課題解決をするため、デバイス管理のシステム化に至りました。 デバイスキッティング工数 デバイス情報の管理 インストールするアプリケーションの管理 OSアップデートサイクルの制御 暗号化の適用、回復キーの管理 リモートロック、リモートワイプ 導入 改めて業務環境を考えると・・・ 業務環境 PC -> WindowsとMacが選択可能 スマートフォン -> 全員支給 環境 -> フルクラウド グループウェア -> Microsoft 365 という前提から、WindowsデバイスとスマートフォンはMicrosoft 365と親和性の高いAzure Active Directory + Microsoft Intuneです。 MacもMicrosoft Intuneで管理し、MDMプラットフォーム統一！という手段もありますが、ことApple製品運用においては圧倒的な実績もあり、設定の同期が早く管理ポリシー・項目の柔軟性からJamf Proで管理することとしました。 構成はこのようなイメージです デバイス管理の概要 結果 No. 項目 結果 1 デバイスキッティング工数 →設定周りを含めキッティング時の工数は下がった △ 2 デバイス情報の管理 →さらば台帳、管理コンソールようこそ ○ 3 インストールするアプリケーションの管理 →個別管理が一元管理に △ 4 OSアップデートサイクルの制御 →デバイス利用者任せから一元管理に ○ 5 暗号化の適用、回復キーの管理 →1台1台の作業からシステム管理に、特にキー管理のシステム化は嬉しいポイント！ ○ 6 リモートロック、リモートワイプ →対応可能に！ ○ 以上の結果から当初の課題に対しては概ねクリアでき、ようやくデバイス管理のスタートラインに立てた状態ではないでしょうか。 スタッフの皆様により良い体験をお届けするため、デバイス管理運用の改善を進めていきたいと思います。 今後やっていきたいこと 1. ゼロタッチキッティングの実現 キッティング要件等を整理しゼロタッチを実現し、デバイスにかかるオンボーディングの時間を削減し、業務に向けたオンボーディングの時間にできればと思います。 2. アプリケーション運用の効率化 一元管理は実現できたものの、必要になった際より柔軟にタイムリーにお応えできるようここの運用をより洗練させていきたいと思います。 3. デバイス状態の管理運用 MDMに登録された管理対象デバイスとしてだけでなく、インベントリ等のデバイス状態に応じた細かい制御・運用を実現しデバイスの状態をより良い状態に保てるようにしていきたいと考えております。 最後に ここまで読んでいただきありがとうございました。これからも全社に貢献し事業に貢献できる社内IT環境を目指し業務に精励していきたいと思います。 We are hiring! KINTOテクノロジーズでは一緒にモビリティの未来を創る仲間を募集しています。カジュアル面談なども行っておりますのでご興味をお持ち頂けましたらぜひお気軽にご連絡ください。 https://www.kinto-technologies.com/recruit/

はじめに グローバル開発グループで言語ローカライゼーションをリードしている榊原です。スペインと日本、２つの文化間で育った私は、異文化間コミュニケーションに深い関心を持ってきました。２回に渡ってお届けするテーマは「ローカライゼーション」です。これまでの私の学習と経験を通じて、その重要性をお伝えした上で、このテーマに少しでも興味を持っていただくのが本記事の目的です。 前編では、弊社における言語ローカライゼーションの考え方や取り組み方について、後編では、これまでの取り組みについて、掘り下げてご紹介します。 翻訳、ローカライゼーション、インターナショナライゼーションの違いとは？ 翻訳 の定義は複数ありますが、私が共感したのは、Hatim and Mason（1997）の「翻訳とは、文化や言語の境界を越えて、別のコミュニケーション行為を中継しようとするコミュニケーションの行為である。（筆者翻訳）」という言葉です。 一方、 ローカライゼーション （localization/l10n）とは、メッセージ、ストーリーやアイデアをターゲットオーディエンスの言語や文化になじませることです。そのために、まずは インターナショナライゼーション （internationalization/i18n）が必要です。ソフトウェア開発におけるi18nの作業は、まずコードを準備し、将来的にどのような言語・文化にも対応できるよう、事前にすべての開発上の決定を行う必要があります。 私自身のタスクは文言面の調整することですが、「ローカライゼーション」の定義の中にはデザイン面も含んでいます。そのため、我々はUI/UXライター、デザイナー、エンジニアと密に連携し、ターゲットユーザーに最高の体験を提供できるよう務めています。  KINTOにおけるローカライゼーション KINTOでは、多様なメンバー間でうまくコラボレーションできるよう、日々"カイゼン"に取り組んでおり、開発プロセス全体の中にローカライゼーションを組み込むことを重視しています。 我々の製品に対し、まずi18nを適用した上で、どのようにローカライゼーションが行われるか、もう少し詳細にご説明します。 以下の英語版 アプリ の画面をご覧ください。  まず前提として、ベース言語が実装されている必要があります。（我々の場合、ベース言語は英語）そして次に、そのデータをどのように管理するかを定義します。アプリやウェブページなどのソフトウェア翻訳では、キーバリュー形式でストアされることが多いです。この画面の文章は、iOS用の英語の「localizable.strings」ファイルでは、以下のような英文になっています。（ロゴと上部のキャッチコピーは対象外） <string name="agreement_description">By using our app, you acknowledge our Terms and Conditions and Privacy Policy.</string> <string name="agreement_accept_all">Accept all</string> ローカライゼーションのために、我々は開発コードとは別に、言語ごとのファイルを作成します。2022年10月現在、我々のアプリ用に日本語・タイ語・アラビア語のファイルを用意しており、それらのファイルにはすべて同じ翻訳キー[^1]が入っていますが、そのキーに対応する文言はそれぞれの言語で記載されています。例えば、アラビア語の「localizable.strings」ファイルには、次のデータが格納されています。 [^1]:Bodrov-Krukowski, Ilya (2020), Translation keys: naming conventions and organizing. < Translation keys: naming conventions and organizing - Lokalise Blog > <string name="agreement_description">باستخدام تطبيقنا، فإنك توافق على الشروط‏ والأحكام و سياسة الخصوصية الخاصة بنا.</string> <string name="agreement_accept_all">قبول الكل</string> このように、英語とアラビア語を比較すると、キーは同じであることがわかります。最初のパラメーターにキーを指定することで、各言語のローカライゼーションファイルから対応する値を取得し、ユーザーが指定した言語に合わせた文言をアプリ上に表示することができます。この例では、言語設定を英語からアラビア語に切り替えると、先ほどの画面は以下のように表示されます。 以上が、ファイルの種類やプラットフォームに関係なく、言語ローカライゼーションを進めていく仕組みです。 ローカライゼーションチームの活動について続けて読みたい方は、ぜひ次回の記事をご覧ください。お楽しみに！ 参考文献と推薦図書 Hatim, B., & Mason, I. (1997), The Translator as Communicator. London, Routledge Khokhar, Sahil (2021), Connecting the dots '96 Web Accessibility through Internationalization and Localization < Connecting the dots '96 Web Accessibility through Internationalization and Localization > Lokalise Academy (2022), Crash course in localization < Crash course in localization >

背景紹介 自己紹介 こんにちは。KINTOテクノロジーズ Globalグループ、DevOpsチームの李琳です。2017年までは中国でエンジニア、プロジェクトマネージャー、大学の先生を経験し、 2018年から日本で働き始めました。 子供を二人持っている母ですが、リスキルしながら仕事をしています。 DevOpsチームの紹介 GlobalグループのDevOpsチームは今年から実働開始しました。Globalグループは多国籍のグループで、DevOpsチームメンバーたちの母国語はそれぞれ日本語、中国語、英語ですので、仕事中は参画者の言語能力を考慮しながらコミュニケーションを取っています。 新しいチームとして、チームメンバーそれぞれの経験は違いますが、普段トラブルあった時には積極的に協力しながら進めています。チームワークがうまくできていると思っています。 DevOpsチームの責任範囲 現在Globalグループ内では複数のチームがあります。DevOpsチームは共通チームの位置付けで、Global全体を見ています。 具体的に言うと担当範囲は下記です。 タスク 作業内容 CI/CD、開発環境（Git/AWS/Grafana/SonarQubeなど）のGlobalチーム展開基準策定 共通部品のGlobalチーム展開基準の策定 Globalチーム共通のDevOps改善 上記内容のFB収集、PDCAの実施 個別カスタマイズサポート 上記内容以外の、全グループ通用可能な改善ではない要望については緊急度と必要性を判断した上で、実施策（基本DevOpsチームはサポートで、アプリチーム独自実装）の検討とサポート エラー解決サポート CI/CDと環境利用中のエラーについて、DevOpsが解決サポート グループ内DevOpsとAWS知見の向上 勉強会実施、個別問い合わせ受け取ること プラットフォームグループとの窓口 Globalグループとプラットフォームグループ間の問い合わせについて、DevOpsがフォローと収集を行い、グループノウハウを蓄積すること 運用の基準策定 運用業務の標準策定、一部外部業者さんに依頼すること コストの監視と方針策定 環境コストの最適化 問い合わせ対応 上記範囲の問い合わせ受付 本記事のターゲット 本記事の対象読者は、開発経験者としてFlywayの導入を検討中または導入済の方です。以前、自分でFlywayの導入を始めたとき、ネットでも色々調べたことがありますが、全体図を書かれている資料が少ないと痛感しました。本記事は、一つのFlyway導入案として執筆しています。ご参考になると光栄です。 Flywayの紹介 Flywayとは Flyway はOpen-Sourceのデータベースマイグレーションツールです。 Flywayを使うことで、複数環境のデータベースのバージョン管理が簡単にできます。 各コマンドの適用シナリオは下記の様です。 Baseline Baselineのコマンドを実行すると、Flywayの初期バージョンを作ります。Baselineのデフォルトバージョンが「1」です。 Community Editionだと、Baselineは一回しか作れません。更新できません。 対象データベースの中に既に一部のテーブルが存在している場合、Baselineを実行しないとエラーになって、Migrateコマンドが実行できません。 【シナリオ】 Step1）Flyway導入前に既に適用済のSQL文のバージョンを「1」より小さい数字にする Step2）Baseline実行 Step3）Migrate実行 結果はバージョン「1」以上のSQL文が適用されます。 【参照】 Baselines an existing database Clean 対象スキーマが丸ごとクリアされます。スキーマが空っぽになるので、本番環境には使わない様な仕組みを入れないといけないです。 【シナリオ】 最初のバージョンに戻したい時は下記のステップでできます。 Step1）Cleanのコマンド実行 Step2）Migrateのコマンド実行 【参照】 Wiping your configured schemas completely clean Info Flywayの情報が出力されます。このコマンドでFlywayからデータベースに繋がるかどうかの確認ができます。 【シナリオ】 実行後下記の様な情報出力（一例） | Category | Version | Description | Type | Installed On | State | +-----------+---------+-------------+------+--------------+---------+ | Versioned | 00.01 | initial | SQL | | Pending | | Versioned | 00.02 | initial | SQL | | Pending | +-----------+---------+-------------+------+--------------+---------+ 【参照】 Prints the details and status information about all the migrations Migrate 新バージョン（まだ適用していない）のSQLファイルが適用されます。一番使われるコマンドです。データベースバージョンアップの時毎回使うコマンドです。 【参照】 Migrates the schema to the latest version Repair エラーになったSQL文の実行履歴を消します。 実行結果は消せません。 Repairコマンドはデータベース中のflyway_shema_historyテーブル(Flywayのバージョン管理テーブル)からエラーになったSQL文の実行履歴を消しただけです。 下記の状況がよくあることです。その場合はきちんとどこまで適用されたかを確認して、全てのSQL文を適用するまで対応してください。 1つのSQLファイルの中に複数のSQL文があって、エラーになった前のSQL文が適用済み、エラーになったSQL文の後のSQL文が適用されていない場合。 【シナリオ】 【例】 V01_07、V01_08、V01_09、適用する時、V01_07、V01_08が成功、V01_09がFailした場合、下記のステップで対応可能です。 Step1）V01_09修正 Step2）Repairコマンド実行 Step3）再度Migrateコマンド実行 【参照】 Repairs the schema history table Validate プロジェクト中のSQL文がデータベースに適用されたかどうか、バージョンがあっているかどうかのチェックができます。 今のDBバージョンがクラウド上のバージョンと同じかどうかをチェックしたい場合も利用できます。 【参照】 Validates the applied migrations against the available ones Flyway導入の背景 Flywayのようなツールを利用しなければ、デプロイする度にデータベースに対する踏み台サーバにログインして、アップデートのシェルなどを実行する必要があります。Globalグループのサービスはほとんどがマイクロサービスで構成されているため、環境が多くなると従来の様な踏み台サーバを利用してデータベースをアップデートするオペレーションでは工数もリスクも大きくなるということが課題になりました。 こういった経緯でFlywayの導入を視野に入れました。最初はAWS上のLambda経由で、GitHubのジョブでコマンドを実行できるジョブを導入してみました。実際に使ってみたところ、下記の課題がありました。 ローカル環境等でのSQLそのものの検証が不十分な状態でAWSにマイグレートしてしまうと、マイグレートが失敗し復旧に手間がかかってしまった。 ローカル環境でFlywayの環境を構築しないままで、手動でデータベースをアップデートすると、AWS上のデータベースと違う構造になるリスクが高いです。 上記の課題をもちまして、一回目のPDCAで、Flywayの仕組みを下記のように作ってみました。 KINTOテクノロジーズ Global チームのFlyway導入方法 SpringBootアプリケーションでFlyway利用するために、下記のところに機能を入れました。 アプリケーションの中にFlywayを導入 利用タイミング：ローカルでアプリを立ち上げる時と、AWSにデプロイする時に自動的にマイグレートされる 意図：ローカルでマイグレーション用のSQL文テスト、自動的にマイグレーションされるので手間がかからないため Flywayのプラグイン導入 利用タイミング：ローカル開発の時 意図：ローカルで自動マイグレートができなかった場合は、プラグインでFlywayのコマンドを実行するため Flywayコマンドを実行可能なGitHubジョブ導入 利用タイミング：AWSにデプロイする時に自動的にマイグレーションできない場合は、GitHub上のジョブでFlywayコマンドを実行します。 意図：AWSに入らなくてもFlywayのコマンドを実行できるようにするため つぎに、それぞれの完成図を紹介いたします。 アプリケーションの中にFlywayの導入 Flywayをプロジェクトの中に導入したら、下記のことができます。 アプリケーション起動後各環境上のデータベースが自動的にマイグレート AWSのデータベースにマイグレート前、ローカル環境でマイグレーション用SQL文検証 詳細は下記の通りです。 下記のコマンドでローカルでMySQLのDockerイメージを起動→アプリケーション起動したら、 自動的に最新のSQL文がマイグレートされます。 docker-compose up -d ./gradlew bootRun Flywayのプラグイン導入 手動でもFlywayのコマンドでローカルデータベースを維持できます。下記のようにプラグインを使えばコマンド実行できます。 Flywayコマンド実行可能のGitHubジョブ導入 AWSにデプロイされると、Auroraまで自動的にマイグレートできますが、できない場合はFlywayコマンドを実行する必要があります。 AWS上にはLambdaを経由でFlywayコマンド実行します。 構成図は下記の通りです。 GitHubジョブ実行からFlyway実行終了までのフローは下記の通りです。 GitHubジョブから実行用のファイルをS3にアップロード Payload(JSON)から必要なパラメータを抽出 AWS CLIを利用し、Flyway実行に必要な情報を抽出 S3バケットからSQLを含むzipファイルを取得 Flyway実行（Lambda上のDocker imageで） 結果をS3バケットに配置 GitHub上コマンド実行時のイメージは下記の通りです。AWSに入らなくても実行できるように構築しました。 これで各環境に下記のことができるようになりました。 アプリケーション起動後各環境上のデータベースが自動的にマイグレートされた AWSのデータベースにマイグレート前、ローカル環境でマイグレーション用SQL文検証できた 各環境にFlywayコマンド実行用のツールが用意された Flywayを使うことによって、下記のメリットがありました。 デプロイ時間が大幅に（半分以上）削減できた 各環境のデータベース差分が無くなったことで開発時の不要なバグ混入や認識齟齬を減らせた 各環境データベースバージョン管理の工数を極小化（SQL文の名前でバージョンを明確すればOK）できた テストやReviewによって不完全なクエリを流すことを防ぐことができた AWS上に構築した踏み台サーバにログインしてオペレーションをしなくて良くなった もちろんFlywayを利用することによって、下記注意しないといけないこともあります。 開発者が多い場合は使い方を決めた上で徹底すること エラーになるときのトラブルシュッティングと復旧は手数をかかること 上記の仕組みで理論上はGitHub ActionsのCI/CDジョブ実行中にもデータベースを立ち上げることもできますが、まだ検証していないです。CI/CDの自動テスト用のデータベースもFlywayで構築した方がいいかなと思っているところです。 Flywayを使うことによって、便利なところもありますが、Flywayが起因となったトラブルが発生したこともあります。この点は利用基準のPDCAで改善の余地があります。環境と利用するシーンによって段階的に導入することで、より安全に効率的に利用できると思います。興味ある方は是非お試しください。

背景紹介 自己紹介 こんにちは。KINTOテクノロジーズ Globalグループ、DevOpsチームの李琳です。2017年までは中国でエンジニア、プロジェクトマネージャー、大学の先生を経験し、 2018年から日本で働き始めました。 子供を二人持っている母ですが、リスキルしながら仕事をしています。 DevOpsチームの紹介 GlobalグループのDevOpsチームは今年から実働開始しました。Globalグループは多国籍のグループで、DevOpsチームメンバーたちの母国語はそれぞれ日本語、中国語、英語ですので、仕事中は参画者の言語能力を考慮しながらコミュニケーションを取っています。 新しいチームとして、チームメンバーそれぞれの経験は違いますが、普段トラブルあった時には積極的に協力しながら進めています。チームワークがうまくできていると思っています。 DevOpsチームの責任範囲 現在Globalグループ内では複数のチームがあります。DevOpsチームは共通チームの位置付けで、Global全体を見ています。 具体的に言うと担当範囲は下記です。 タスク 作業内容 CI/CD、開発環境（Git/AWS/Grafana/SonarQubeなど）のGlobalチーム展開基準策定 共通部品のGlobalチーム展開基準の策定 Globalチーム共通のDevOps改善 上記内容のFB収集、PDCAの実施 個別カスタマイズサポート 上記内容以外の、全グループ通用可能な改善ではない要望については緊急度と必要性を判断した上で、実施策（基本DevOpsチームはサポートで、アプリチーム独自実装）の検討とサポート エラー解決サポート CI/CDと環境利用中のエラーについて、DevOpsが解決サポート グループ内DevOpsとAWS知見の向上 勉強会実施、個別問い合わせ受け取ること プラットフォームグループとの窓口 Globalグループとプラットフォームグループ間の問い合わせについて、DevOpsがフォローと収集を行い、グループノウハウを蓄積すること 運用の基準策定 運用業務の標準策定、一部外部業者さんに依頼すること コストの監視と方針策定 環境コストの最適化 問い合わせ対応 上記範囲の問い合わせ受付 本記事のターゲット 本記事の対象読者は、開発経験者としてFlywayの導入を検討中または導入済の方です。以前、自分でFlywayの導入を始めたとき、ネットでも色々調べたことがありますが、全体図を書かれている資料が少ないと痛感しました。本記事は、一つのFlyway導入案として執筆しています。ご参考になると光栄です。 Flywayの紹介 Flywayとは Flyway はOpen-Sourceのデータベースマイグレーションツールです。 Flywayを使うことで、複数環境のデータベースのバージョン管理が簡単にできます。 各コマンドの適用シナリオは下記の様です。 Baseline Baselineのコマンドを実行すると、Flywayの初期バージョンを作ります。Baselineのデフォルトバージョンが「1」です。 Community Editionだと、Baselineは一回しか作れません。更新できません。 対象データベースの中に既に一部のテーブルが存在している場合、Baselineを実行しないとエラーになって、Migrateコマンドが実行できません。 【シナリオ】 Step1）Flyway導入前に既に適用済のSQL文のバージョンを「1」より小さい数字にする Step2）Baseline実行 Step3）Migrate実行 結果はバージョン「1」以上のSQL文が適用されます。 【参照】 Baselines an existing database Clean 対象スキーマが丸ごとクリアされます。スキーマが空っぽになるので、本番環境には使わない様な仕組みを入れないといけないです。 【シナリオ】 最初のバージョンに戻したい時は下記のステップでできます。 Step1）Cleanのコマンド実行 Step2）Migrateのコマンド実行 【参照】 Wiping your configured schemas completely clean Info Flywayの情報が出力されます。このコマンドでFlywayからデータベースに繋がるかどうかの確認ができます。 【シナリオ】 実行後下記の様な情報出力（一例） | Category | Version | Description | Type | Installed On | State | +-----------+---------+-------------+------+--------------+---------+ | Versioned | 00.01 | initial | SQL | | Pending | | Versioned | 00.02 | initial | SQL | | Pending | +-----------+---------+-------------+------+--------------+---------+ 【参照】 Prints the details and status information about all the migrations Migrate 新バージョン（まだ適用していない）のSQLファイルが適用されます。一番使われるコマンドです。データベースバージョンアップの時毎回使うコマンドです。 【参照】 Migrates the schema to the latest version Repair エラーになったSQL文の実行履歴を消します。 実行結果は消せません。 Repairコマンドはデータベース中のflyway_shema_historyテーブル(Flywayのバージョン管理テーブル)からエラーになったSQL文の実行履歴を消しただけです。 下記の状況がよくあることです。その場合はきちんとどこまで適用されたかを確認して、全てのSQL文を適用するまで対応してください。 1つのSQLファイルの中に複数のSQL文があって、エラーになった前のSQL文が適用済み、エラーになったSQL文の後のSQL文が適用されていない場合。 【シナリオ】 【例】 V01_07、V01_08、V01_09、適用する時、V01_07、V01_08が成功、V01_09がFailした場合、下記のステップで対応可能です。 Step1）V01_09修正 Step2）Repairコマンド実行 Step3）再度Migrateコマンド実行 【参照】 Repairs the schema history table Validate プロジェクト中のSQL文がデータベースに適用されたかどうか、バージョンがあっているかどうかのチェックができます。 今のDBバージョンがクラウド上のバージョンと同じかどうかをチェックしたい場合も利用できます。 【参照】 Validates the applied migrations against the available ones Flyway導入の背景 Flywayのようなツールを利用しなければ、デプロイする度にデータベースに対する踏み台サーバにログインして、アップデートのシェルなどを実行する必要があります。Globalグループのサービスはほとんどがマイクロサービスで構成されているため、環境が多くなると従来の様な踏み台サーバを利用してデータベースをアップデートするオペレーションでは工数もリスクも大きくなるということが課題になりました。 こういった経緯でFlywayの導入を視野に入れました。最初はAWS上のLambda経由で、GitHubのジョブでコマンドを実行できるジョブを導入してみました。実際に使ってみたところ、下記の課題がありました。 ローカル環境等でのSQLそのものの検証が不十分な状態でAWSにマイグレートしてしまうと、マイグレートが失敗し復旧に手間がかかってしまった。 ローカル環境でFlywayの環境を構築しないままで、手動でデータベースをアップデートすると、AWS上のデータベースと違う構造になるリスクが高いです。 上記の課題をもちまして、一回目のPDCAで、Flywayの仕組みを下記のように作ってみました。 KINTOテクノロジーズ Global チームのFlyway導入方法 SpringBootアプリケーションでFlyway利用するために、下記のところに機能を入れました。 アプリケーションの中にFlywayを導入 利用タイミング：ローカルでアプリを立ち上げる時と、AWSにデプロイする時に自動的にマイグレートされる 意図：ローカルでマイグレーション用のSQL文テスト、自動的にマイグレーションされるので手間がかからないため Flywayのプラグイン導入 利用タイミング：ローカル開発の時 意図：ローカルで自動マイグレートができなかった場合は、プラグインでFlywayのコマンドを実行するため Flywayコマンドを実行可能なGitHubジョブ導入 利用タイミング：AWSにデプロイする時に自動的にマイグレーションできない場合は、GitHub上のジョブでFlywayコマンドを実行します。 意図：AWSに入らなくてもFlywayのコマンドを実行できるようにするため つぎに、それぞれの完成図を紹介いたします。 アプリケーションの中にFlywayの導入 Flywayをプロジェクトの中に導入したら、下記のことができます。 アプリケーション起動後各環境上のデータベースが自動的にマイグレート AWSのデータベースにマイグレート前、ローカル環境でマイグレーション用SQL文検証 詳細は下記の通りです。 下記のコマンドでローカルでMySQLのDockerイメージを起動→アプリケーション起動したら、 自動的に最新のSQL文がマイグレートされます。 docker-compose up -d ./gradlew bootRun Flywayのプラグイン導入 手動でもFlywayのコマンドでローカルデータベースを維持できます。下記のようにプラグインを使えばコマンド実行できます。 Flywayコマンド実行可能のGitHubジョブ導入 AWSにデプロイされると、Auroraまで自動的にマイグレートできますが、できない場合はFlywayコマンドを実行する必要があります。 AWS上にはLambdaを経由でFlywayコマンド実行します。 構成図は下記の通りです。 GitHubジョブ実行からFlyway実行終了までのフローは下記の通りです。 GitHubジョブから実行用のファイルをS3にアップロード Payload(JSON)から必要なパラメータを抽出 AWS CLIを利用し、Flyway実行に必要な情報を抽出 S3バケットからSQLを含むzipファイルを取得 Flyway実行（Lambda上のDocker imageで） 結果をS3バケットに配置 GitHub上コマンド実行時のイメージは下記の通りです。AWSに入らなくても実行できるように構築しました。 これで各環境に下記のことができるようになりました。 アプリケーション起動後各環境上のデータベースが自動的にマイグレートされた AWSのデータベースにマイグレート前、ローカル環境でマイグレーション用SQL文検証できた 各環境にFlywayコマンド実行用のツールが用意された Flywayを使うことによって、下記のメリットがありました。 デプロイ時間が大幅に（半分以上）削減できた 各環境のデータベース差分が無くなったことで開発時の不要なバグ混入や認識齟齬を減らせた 各環境データベースバージョン管理の工数を極小化（SQL文の名前でバージョンを明確すればOK）できた テストやReviewによって不完全なクエリを流すことを防ぐことができた AWS上に構築した踏み台サーバにログインしてオペレーションをしなくて良くなった もちろんFlywayを利用することによって、下記注意しないといけないこともあります。 開発者が多い場合は使い方を決めた上で徹底すること エラーになるときのトラブルシュッティングと復旧は手数をかかること 上記の仕組みで理論上はGitHub ActionsのCI/CDジョブ実行中にもデータベースを立ち上げることもできますが、まだ検証していないです。CI/CDの自動テスト用のデータベースもFlywayで構築した方がいいかなと思っているところです。 Flywayを使うことによって、便利なところもありますが、Flywayが起因となったトラブルが発生したこともあります。この点は利用基準のPDCAで改善の余地があります。環境と利用するシーンによって段階的に導入することで、より安全に効率的に利用できると思います。興味ある方は是非お試しください。

自己紹介 KINTOテクノロジーズにてCIO室セキュリティチームのチームリーダーを担当している森野です。 趣味は子ども時代を過ごした埼玉県大宮市（現さいたま市）のサッカーチームである大宮アルディージャの応援です。 本記事では脆弱性診断の主担当者であるヘビーメタル大好き中辻さんと共に私たちの脆弱性診断の取り組みについて紹介させて頂きます。 脆弱性とは 脆弱性とは何でしょうか。 脆弱性とはソフトウエアのバグ（欠陥、不具合）の内、情報セキュリティのCIAを損なうものを指します。 CIAは下記3つの単語の頭文字を取ったものです。 Confidentiality（機密性） Integrity（完全性） Availability（可用性） 機密性とは情報に対して許可された者のみアクセス可能であることが保証されることを指します。 例えば給与明細参照用アプリがあったとして私の給与明細（情報）について会社の人事担当者と私（許可された者）のみアクセス可能である状態は機密性が保たれた状態です。 これがソフトウエアのバグにより私の給与明細に他人がアクセス可能である場合、機密性が損なわれた状態となります。 機密性が保たれた状態 アクセス権を持っている人だけ給与明細にアクセス可能 機密性が損なわれた状態 アクセス権を持っていない人も給与明細にアクセス可能 完全性とは情報に欠損や改ざんがなく完全に（正確に）保たれることが保証されることを指します。 前述の給与明細で例えると会社の人事担当者以外は私の給与明細の内容を消したり、書き換えたりできない状態は完全性が保たれた状態です。 私の給与明細を他人が消したり、書き換えたりすることが可能である場合、完全性が損なわれた状態となります。 完全性が保たれた状態 編集権限のある人だけ給与明細の削除、編集可能 完全性が損なわれた状態 編集権限のない人も給与明細の削除、編集可能 可用性とは必要な時にいつでも情報にアクセス可能であることが保証されることを指します。 人事担当者や私が必要な時にいつでも給与明細にアクセス可能である状態は可用性が保たれた状態です。 人事担当者や私が必要な時に給与明細にアクセスできない場合、可能性が損なわれた状態となります。 可用性が保たれた状態 いつでも給与明細にアクセス可能 可能性が損なわれた状態 給与明細にアクセス不可 私たちが取り組んでいる脆弱性診断について 前述した情報セキュリティのCIAを損なうバグを検出することが脆弱性診断の目的です。 私たちの会社では以下のような脆弱性診断を実施しています。 Webアプリケーション診断 プラットフォーム診断 スマートフォンアプリ診断 Webアプリケーション診断 Webアプリケーション診断には大きくわけて静的診断と動的診断があります。 静的診断はアプリケーションを実際に動かして診断するのではなくソースコードから安全ではないコードを発見する手法です。 動的診断は実際に動いているWebアプリケーションを診断する手法です。 いづれも自動診断と手動診断があります。 自動診断は設定に従ってプログラムがソースコード診断やWebアプリケーション診断を自動で実施します。 手動診断は人間がソースコード診断やWebアプリケーション診断を手動で実施します。 静的診断はSAST(Static Applilcation Secuirty Testing)、動的診断はDAST(Dynamic Application Security Testing)とも呼ばれます。 Webアプリケーション診断においてセキュリティチームは主に動的診断を担当していますので動的診断の自動診断と手動診断について説明します。 自動診断 私たちの会社では自動診断ツールに AppScan を使用しています。 例えばWebアプリケーションに SQLインジェクション の脆弱性があるのかないのか診断する場合、入力項目にSQLインジェクションを誘発する攻撃コードを入力、実行して診断します。 すべての入力項目に様々な攻撃コードを埋め込んでWebアプリケーションを診断するのは骨の折れる作業です。 診断中にWebアプリケーションのセッションが切れたらログインからやり直しです。画面遷移の順番が決まっている機能もあり、その画面遷移を繰り返し行うのも大変です。 自動診断ツールはそのような作業を自動化してくれるとても素敵なツールです。 手動診断 手動診断ツールは BurpSuite を使用しています。　 なぜ自動診断ツールがあるのに手動診断を行うのでしょうか。 セキュリティに関するコミュニティの OWASP は、セキュリティインシデントの発生原因を OWASP Top 10 というランキング形式で公開しています。 OWASP Top 10の3位に入っているインジェクションは自動診断ツールが検出を得意とするものです。人間より自動診断ツールの方が様々な攻撃コードを漏れなく入力項目に入力（インジェクション）して診断できそうです。 では、1位のアクセス制御の不備はどうでしょうか。先程、例に挙げた給与明細参照用アプリの機密性が担保されているのか否かを診断するようなケースです。残念ながら自動診断ツールはWebアプリケーションの仕様を理解した上で、その挙動が適切か不適切かを判断するのは得意ではありません。このような種類の脆弱性は人手で診断を行います。 プラットフォーム診断 プラットフォーム診断はファイアウォールやロードバランサなどのネットワーク機器やWebアプリケーションが実行されているサーバの設定やサーバOSやミドルウエアの脆弱性を診断するものです。 プラットフォーム診断ツールは nmap を使用しています。 プラットフォーム診断では以下のような項目をチェックします。 ・不要ポートの解放 ・脆弱なソフトウエアの利用 ・設定の不備 ・プロトコル固有の脆弱性 参考： 政府情報システムにおける脆弱性診断導入ガイドライン P.7 スマートフォンアプリ診断 スマートフォンアプリ診断は通常、アプリ部分の診断とWebAPI部分の診断があります。WebAPI部分はWebアプリケーションと同様の脆弱性診断を実施します。 アプリ部分はOWASPの OWASP Mobile Application Security Testing Guide (MASTG) を参考に静的診断を行っています。 アプリ部分の診断については今後、動的診断および静的診断に対応している MobFS を活用することを検討しています。 脆弱性診断についてもっと学びたい人向けの書籍、資料、ウェブサイト ここまで記事を読んで脆弱性診断についてもっと学びたい人もいらっしゃるのではないでしょうか。 そのような人向けに役に立つ書籍、資料、ウェブサイトを紹介します。 書籍 体系的に学ぶ 安全なWebアプリケーションの作り方 第2版　脆弱性が生まれる原理と対策の実践 通称、徳丸本と呼ばれている脆弱性診断について学ぶ人たちのバイブル的書籍です。鈍器に使えそうな分厚さなので持ち歩いて読みたい方は電子書籍版の購入をお勧めします。 資料 安全なウェブサイトの作り方 IPAが公開している名前の通り安全なウェブサイトの作り方に関する資料です。先程の徳丸本と比べてページ数少な目なので初めて脆弱性診断について学ぶ人はこちらから読み始めるのをお勧めします。 ウェブサイト WebSecurityAcademy 前述した脆弱性診断ツールBurpSuiteの開発元であるPortSwigger社が運営している脆弱性の学習サイトです。 脆弱性に関するテキスト教材とハッキング演習から構成されています。 ブラウザ上で実際に手を動かしながら学習が可能です。 おわりに この記事ではセキュリティチームの脆弱性診断の取り組みについて紹介させて頂きました。 最近WebAPIはREST APIではなく GraphQL による実装が流行っています。 このようにITの世界は技術の流行り廃りが早いため、新しい技術で実装されたアプリケーションの脆弱性診断を適切に行えるよう日々情報収集および業務改善に努めたい行きたいと思います。

はじめに はじめまして、KINTOテクノロジーズでモビリティマーケットの開発・運用を担当しているリナです。 普段はフロントエンジニアとして、主にNext.jsを用いて実装しています。 最近のマイブームは、ガンプラの塗装とスプラトゥーンをやることです🎮 さて、KINTOテクノロジーズでは業務に役立つ書籍を経費で購入しています。 購入した書籍は CIO室 で管理され、従業員が自由に貸出できるようになっています。 そこで今回は、購入した書籍の管理方法をラクにした話を紹介します！ 従来の書籍管理の方法 従来の書籍管理の方法は Confluence を使用して、貸出状況を手作業で更新していました。 管理の流れは、以下の通りです。 管理担当者が、購入書籍をConfluenceの書籍貸出一覧に記載 貸出希望者は、Confluenceの書籍貸出一覧から書籍を選んで、管理担当者にSlackで貸出連絡 管理担当者がSlackの内容をもとにConfluenceの貸出状況を更新 このように書籍を貸出する上で、 貸出・返却希望者Slackで管理担当者に連絡する 管理担当者は、都度貸出状況を手作業で更新する という手間が発生していました。 この手間を解消すべく、書籍の管理方法を一新しました！ 新しい書籍管理の方法 新しい書籍の管理方法は JIRA のワークフローとカンバン方式のボードを使用して、管理者を介さずに貸出状況が分かるようにしました。 カンバン方式のボード 管理の流れは、以下の通りです。 管理担当者が、購入書籍をボードのライブラリーにチケットを登録 貸出希望者は、ライブラリーから書籍を選んで、ステータスを「貸出中」に変更 これだけです！ 管理者はボードに購入書籍を登録するだけで、貸出状況が一目見てわかるようになり、貸出状況を手作業で更新する必要がなくなりました。 一方、貸出・返却希望者は、管理担当者を介さずにステータスを変更するだけ貸出登録が可能になり、Slackで貸出・返却時に連絡する手間を省くことができました。 ラクするためのJIRAワークフロー このボードを作成するにあたって、以下のようなワークフローを設定しています。 ワークフロー 「ライブラリー」「貸出中」「破棄・紛失」3つのステータスを作成し、ステータスを移動する際に一部の情報を自動入力することで、入力する負担を軽減しました。 各ワークフローに設定している内容は、以下の通りです。 Check out (ステータス「ライブラリー」→「貸出中」に変更) 貸出日に本日の日付を自動入力する 担当者（貸出希望者）を自動で割り当てる 貸出回数をカウントする Check in (ステータス「貸出中」→「ライブラリー」に変更) 貸出日・返却予定日を自動消去する 担当者（貸出希望者）を自動消去する さらにラクするための一工夫 全オフィスの書籍の管理状況がわかる さらにオフィスごとに何の書籍があるか、アイコンを設定することで視覚的に把握できるようにしました。 タイプを選択するとオフィス毎の管理状況を絞り込んで表示できるようになっています。 KINTOテクノロジーズは、東京に2拠点と名古屋・大阪に1拠点ずつオフィスがあります。 従来は、各拠点ごとに書籍を管理していましたが、全拠点の書籍が1つのボードで一元管理できるようにしました。 Slackで変更履歴を通知 また、JIRAの通知機能を使用して、管理者用にステータスの変更履歴をSlackに通知しています。 Slackに通知することで、新しく購入された書籍や誰がステータスを変更したかなどが把握できるようにしました。 ラクにした結果 書籍の管理方法を見直した結果、それぞれ以下のようなメリットがあると思っています。 管理担当者のメリット 書籍の管理状況を手作業で更新する必要がなくなった パッとみて貸出状況・貸出者が誰かわかるようになった オフィスごとに管理していた書籍を全オフィス一元管理できるようになった 貸出・返却希望者のメリット 書籍の貸出・返却時にSlackで連絡する必要がなくなった ステータスを変更するだけで、貸出登録ができる（文字の入力不要！） さいごに 今回の記事では、書籍の管理方法をラクにした話をご紹介しました。 ちょっとした手間を省くことで管理者も利用者もハッピーになればいいなと思っています✨

2022年振り返り＆2023年展望 KINTOテクノロジーズの景山です！ 2022年の振り返りと2023年の展望について書こうと思います。 2022年はさまざまなサービスをローンチしました。 5月のbZ4Xの受注サイトローンチ。ローンチ後にリコール対応が入り、その後、法人顧客が受注できるように改修などローンチ後も開発チームは多くの対応をしてくれました。 7月にKINTO ONE中古車サイトのローンチ。まずは東京都からですが、11月には愛知県も追加。今もより便利にするため各種機能の開発を継続中です。 もちろんKINTO ONE新車も多くの機能を追加開発してきました。 Globalでは10月にFIFAワールドカップカタール2022をターゲットにKINTO RENTというレンタカーサービスをローンチしました。多くのFIFAワールドカップ観戦にいらっしゃった方に使っていただきました。 またGlobalデザインシステムもローンチしました。この内容については、このアドベントカレンダーの 12月7日 に佐々木さん、渡辺さんが書いてくれていますのでご興味ある方はそちらをご覧ください。 これ以外にもGlobal ID PlatformやGlobal KINTO Appの各国のニーズに向けた対応も継続的に行なってきました。 Global ID Platformに関しては、OpenID Foundationにも加入して最新テクノロジーのキャッチアップとプラットフォームへの適用も開始しています。 ウェブやアプリ以外にも今年は販売店さんをテクノロジーで支援する取り組みも開始しました。 販売店の方のニーズをヒアリングして販売店支援のためのツールを開発して提供し、好評かつ改善要望をいただいており、いまも開発チームが毎月updateをしてくれています。 ツール以外にも販売店の方がKINTOはじめクルマを売るために我々の技術で解決できる課題を探し出し、ソリューションを提供する、という取り組みを開始しました。 ちょっと変わったところでは、Rookie Racing(ROOKIE Racing)というレーシングチームの公式ウェブサイトも制作して喜んでいただいています。 データ分析関連でも、Amazon QuickSightを使った全社ダッシュボード機能の開発。事業メンバーが簡単にSQLを発行できる独自データ分析ツール”nicola”の開発、など、営業やマーケとタッグを組んで社内データの活用にプロアクティブに取り組んでいます。 KINTOテクノロジーズの提供する独自アプリとしてPrismというネイティブアプリをローンチしました。まだiOS版のみの提供ですが、モビリティに限らず、みなさんがどこかに行きたいと思ったときにおすすめの行き先を直感で選ぶことができるアプリです。アジャイルで機能改善をどんどんしてくれているので、毎月のように使いやすくなっています。ますます多くのお客様に使っていただけるといいなと思っています。 当社では評価のなかに「自分の技術力をいかに高めたか」「チームや会社の技術力アップにいかに貢献したか」という評価指標があります。 このアウトプットをサポートするために、勉強会や研修参加、参考書籍購入などサポートを充実させています。 勉強会では、コーヒー、ピザ、サンドイッチのデリバリーができるので、カジュアルな雰囲気で開催されている勉強会が増えてきました。 また、エンジニア陣が自主的にテックブログを立ち上げました。執筆する人が出てくるのかなと心配していましたが、多くの社員が積極的に参加してくれて、2月公開分まですでに埋まっています。 エンジニアリング教育研修プロジェクトというものも立ち上げて、エンジニアにどうスキルアップしてもらおうかと、検討議論をスタートしています。 働く仲間が増えるとともに、4月に大阪心斎橋にOsaka Tech Labを開設しました。また6月には東京の2拠点目の神保町オフィスも開設しています。 東京、大阪、名古屋と拠点が違う仲間同士でコミュニケーションをしっかり取れるような環境を用意してくれました。 われわれが利用しているSlack, Zoom, Box, Jira, Confluence, Miro, Adobe, Figma, Google workspaceなどのツールもコーポレートITチームが利便性をそこなわないように考慮しつつ、よりセキュアに利用できるようにマネジメントしてくれるようになり、みなが安心して多様なツールを活用できるようになりました。 みながプロアクティブに課題解決に取り組んでくれて良い年になったな、とおおいに感謝しています。 さて、来年、2023年は、今年以上に新しいサービスをローンチする年になりそうです。 先日、記者発表したKINTO Unlimitedサービスも絶賛開発中で来年前半にフェーズを切ってローンチしていきます。 KINTO Factoryも同様に開発中ですが、これも来年前半にローンチしていきます。 トヨタ自動車とのコラボレーションプロジェクトでデータベース構造やインターフェースの定義で調整に苦労した部分もありましたが、クルマの作り方そのものを変えるようなプロジェクトで、今後のモビリティビジネスに与える影響は大きいプロジェクトですので、開発サイドとしては遅れなくローンチできるように用意周到に進めたいと思っています。 中古車サブスクも展開地域の拡大がありますし、新機能の開発も進んでいます。中古車ビジネスは知見を溜めつつ、システムをアップデートしていますが、来年はいよいよ本格的な展開になりそうです。 もちろん新車のサブスクも多くの機能追加が予定されています。 サブスクサイトの完全リニューアルを一昨年より開始していますが、いよいよ来年半ばにはローンチしたいと思っています。これによって、サブスクサイトの機能追加や新機能導入がたやすくなり、今まで以上に便利で使いやすいモダンなサイトにしていくことができるようになります。 いまはまだお伝えできないビッグプロジェクトも進行中です。 データ活用のレベルも一段階ぐらい上がるのではないかと期待しています。 各事業部の日々の活動がデータドリブンになることで、戦術や戦略の精緻化ができるのではないかと思っています。 GlobalでのKINTOの展開も、コロナ禍がようやく落ち着いてきて、スピードアップしていきます。 社員が海外のメンバーと現地でコミュニケーションする機会も増えることから、KINTOビジネスを推進するための、より現地のニーズに即したITサポートができると期待しています。 すでに社員数は300人になりましたが、まだまだ一緒にプロジェクトを進めてくれる仲間は必要になりそうなので、採用活動も強化していきたいと考えています。 テクノロジー強化も重要な取り組みです。 クラウドを活用したときのパフォーマンス向上策や運用効率化などもっとクラウドを使い倒すスキルを高めていきたいと考えています。幸いにもAWSさん、Googleさんから手厚いサポートをいただいているので、実現できると思っています。 今年以上に忙しくも充実した年になりそうなので、社員一丸となって頑張っていきます！

2022 Review & 2023 Outlook This is Kageyama from KINTO Technologies! I would like to write a review of 2022 and my outlook for 2023. We launched various services in 2022. In May, we launched the bZ4X online subscription sales site. After the launch, we had to deal with a recall, and then we also made modifications to the site to allow corporate customers to place orders. Thus, the development team took a lot of action after the launch. Online used car subscription sales site launch in July. We started with the Tokyo area, but added the Aichi area in November. We are still developing various functions to make it more convenient. Of course, we have also developed many additional functions for KINTO ONE site. In October, we launched a rental car service called KINTO RENT in Qatar mainly for customers who came to watch the World Cup. We also launched the Global Design System. Please refer to the article in this advent calendar written by Sasaki-san and Watanabe-san on 7th of December if you are interested in the details. In addition to this, we have been continuously working on the Global KINTO ID Platform and the Global KINTO App to meet the needs of each country. As for the Global KINTO KINTO ID Platform, we have also joined the OpenID Foundation to catch up with the latest technologies and start applying them to our platform. https://openid.net/certification/ Besides web development and apps development, this year we also launched an initiative to support dealers with technology. We have developed and provided tools to support dealers based on interviews with dealers about their needs. We have also started an initiative to find issues that can be solved by our technology and provide solutions to help dealers sell cars on KINTO and credit. We also created an official website for a racing team called Rookie Racing although they are not a dealership. The team is very happy with the website. https://www.rookie-racing.co.jp/ In the area of data analysis, we have developed a company-wide dashboard function using Amazon QuickSight and a proprietary data analysis tool called "nicola" that allows business members to easily issue SQL. We are working proactively with sales and marketing to improve the use of data in each department within the company. KTC has launched its own app called Prism. It is still only available for iOS. It is an app that allows you to intuitively select a recommended destination when you want to go somewhere, not only for outings using a car. The app is getting more user friendly every month as they keep improving the features in an agile way. I hope more and more customers will use it. Among our evaluation criteria, we have a measure of "how well I have improved my own technical skills and knowledge" and "how well I have contributed to improving the technical skills and technical knowledge of my team and the company. To support this output, we offer a full range of support, including study groups, participation in training, and the purchase of reference books. More and more study sessions are being held in a casual atmosphere, with coffee, pizza, and sandwiches by delivery. Also, our engineering team has voluntarily started this tech blog. I was worried about whether anyone would be willing to write one, but many engineers have actively participated, and it has already filled up to be published in February. We have established an organization called the Engineering Education and Training Project, and we are starting daily discussions on how to have engineers improve their skills. Along with the increase in the number of people working for our company, we opened the Osaka Tech Lab in Shinsaibashi, Osaka in April. We also opened the Jimbocho office in June. This is our second office in Tokyo, and we have offices in Tokyo, Osaka, and Nagoya. The corporate IT team has prepared an environment that allows for good communication between the Tokyo, Osaka, and Nagoya offices. The Corporate IT team has managed our tools such as Slack, Zoom, Box, Jira, Confluence, Miro, Adobe, Figma, Google workspace, etc. in a more secure manner while taking into consideration the convenience of the tools we use. The management of these tools has been improved so that they can be used more securely without compromising their usability, and everyone can use them with peace of mind. I am very thankful that everyone has been proactive in solving issues and that this has been a good year for us. Next year, 2023, will be a year of launching new services even more than this year. The KINTO Unlimited service, which we recently announced to the press, is under development. We will launch it in phases in the first half of next year. KINTO Factory is also under development and will be launched in the first half of next year. This is a collaborative project with Toyota Motor Corporation, and although there were some difficulties in coordinating the database structure and interface definitions, it is a project that will change the way cars are made itself. Since this project will have a significant impact on the future mobility business, I hope that the development team will be prepared to launch without delay. The used car subscription business is also expanding its service area, and development of new features is underway. We are updating our used car business system while accumulating knowledge, and next year will be the year when we will finally be able to fully expand the business. Of course, many new features will be added to the new car subscription business site as well. We have started a complete renewal of the new car subscription site the year before last, and we hope to finally launch it in the middle of next year. This will make it easier to add functionality and introduce new features to the site and make it more convenient, user-friendly, and modern than ever before. We are also working on a big project that I can't tell you about at this time. I expect that the level of data utilization will also become more sophisticated. I believe that each business unit will be able to refine its tactics and strategies by utilizing data. KINTO's development in Global will also speed up as the Corona disaster finally settles in. Since our employees will have more opportunities to communicate locally with our overseas members, I expect that we will be able to provide IT support more in line with local needs to promote KINTO business. We already have 300 employees, but we will still need more people to work with us on projects, so we will also be stepping up our recruitment efforts. Strengthening our technology is another important initiative. We would like to enhance our skills to make better use of the cloud, including measures to improve performance and operational efficiency when utilizing the cloud. Fortunately, we are receiving generous support from AWS and Google, so I believe we can make this happen. It's going to be an even busier and more fulfilling year than this year, so all of us will work together to make it happen!

Happy Christmas🎄 こんにちは！KINTO ONE 開発Gの渡邊です。 普段はフロントエンドエンジニアとしてNext.jsやTypeScriptを用いてプロダクト開発を行なっています。 また、テックブログ運営チームとしてテックブログの開発・実装も担当しました。 アドベントカレンダーの最終日の今回は、テックブログのデザイン選定やフロントエンド開発についてご紹介いたします。 テックブログチームの立ち上げ テックブログ運営チームは元々、社内のアウトプットカルチャーを育むことを目的に、リーダーの中西さんを中心に有志4名が集まり発足しました。 残タスクの見える化を意識して運用体制やブログの仕様について話し合ったので、とにかく高速で物事が決まっていったのを思い出します。 その中で私は、ブログ全体のデザインとフロントエンド実装を担当しました。 週次のミーティングでは、議論から生まれたアイデアをプロトタイプに反映し、チームに共有していました。 プロトタイプがあるとチームのモチベーションも上がるので、実装担当として目に見える進捗を意識して開発に臨みました。 Next.js でテックブログ開発 フロントエンドのフレームワーク（ライブラリ）はNext.jsを採用しています。 Next.jsを採用した理由は自分自身一番馴染みがあり、ブログ記事をMarkdownファイルとしてストックし、Static Site Generatorで静的サイトを生成すれば良さそうだなと構想段階から考えていたからです。 作成したプロジェクトからビルド時に静的コンテンツを生成し、成果物をホスティングしています。 また、Next.jsはGitHub上に様々なライブラリを組み合わせた examples を公開しています。 この中の一つに blog-starter があり、ブログの雛形を用意されていたので、着手しやすかったのもNext.jsを採用した理由です。 以上を踏まえて、テックブログを作り上げるために必要なステップを以下の3つに分類し、開発を行いました。 デザイン選定 画面実装（記事一覧ページ・記事詳細ページ） Markdownツールの準備 デザイン選定 デザイン担当を引き受けたが、ブログデザインのノウハウが全くなかったので他社事例のリサーチから始めました。 他者事例から得た特徴や気付きを元に、テックブログに必要なUI要素や情報整理をチームで行いました。 特徴・気付きをまとめたドキュメント デザインリサーチを進める中で、シンプルかつ分かりやすいデザインを目標にして、考慮するべき4つのコンポーネント（ヘッダー・カード・リスト・フッター）に着目しました。 また、実装を担当することも決まっていたので、コーディングがしやすく拡張性の高いデザインを意識して作成しました。 コンポーネント分類 ある程度デザインが出来上がったタイミングでサイトデザインを管理している部署に確認いただき、アドバイスを頂けました。 画面実装 画面のテンプレートはblog-starterで用意されていたので、スタイルのコーディングに集中するべく、CSSフレームワークとして Tailwind CSS を採用しました。 Tailwind CSSの特徴は、標準のクラス名がシンプルかつどのようなスタイルを表しているかを認識しやすいように定義されているので、直感的にスタイルを変更でき、開発コスト削減にも繋がっています（ユーティリティファースト）。 何人かの社内のフロントエンドエンジニアがテックブログの機能拡張やバグ改修で関わってくれてますが、学習コストが少なくスムーズに実装してもらっているのでチーム開発に向いているなと思います。 レスポンシブ対応を同じ className 内で書けるのも魅力的です。 <div className="md:px-6 lg:px-10 md:py-10 md:hover:shadow-xl"> <div className="mb-6"> <CoverImage slug={slug} title={title} src={coverImage} /> </div> <div className="flex items-center mb-4 md:mb-6"> <div className="background-color h-7 flex items-center rounded-lg p-2 md:p-4 mr-3"> <span className="text-white text-xs md:text-base">{category}</span> </div> <div className="text-gray-500 text-sm md:text-base transition"> <DateFormatter dateString={date} /> </div> </div> <h3 className="text-xl sm:text-2xl md:text-2xl lg:text-3xl mb-2 md:mb-6 leading-snug text-color"> <Link href={`/posts/${slug}`}> <a className="hover:underline">{title}</a> </Link> </h3> </div> Markdownツールの準備 テックブログでは、Markdownパーザーとして zenn-markdown-html と zenn-markdown-css を採用しています。 blog-starterで用意されているデフォルトのMarkdown記法ではバリエーションに欠けるかつカスタマイズのハードルが高いのが採用理由です。それぞれのパーサーの役割は以下の通りです。 zenn-markdown-html Zenn独自の記法を含むMarkdownをHTMLに変換（markdownToHtml）するためのパッケージ zenn-content-css zenn-markdown-htmlでMarkdownから変換されたHTMLに適用するためのCSS CSSを適用したいコンポーネントやブロックに className=znc を指定 多種多様な埋め込みコンテンツ等も用意されているので、リッチなブログが作成できます。（TweetのURLを記載するだけで簡単にコンテンツ表示） https://twitter.com/KintoTech_Dev/status/1597900747538046978 今後トライしたい機能 シンプルで分かりやすいを目標にスモールスタートしたテックブログですが、将来的に実装したい機能のアイデアもまとめておきます。 リリース後に社内外から「こんな機能つけてみたらどう？」という意見を多くいただき、日々注目を集めていて嬉しく思います。 実際に RSS機能 を追加したりとアップデートに勤しんでいます。 タグやカテゴリーを付与して、記事検索機能や絞り込み機能を実装 多言語対応出来るようにローカライズ機能を実装 コンテンツ管理をMicro CMSやクラウドサーバーに載せ、ローカル管理をやめる まとめ 限られたリソースの中でしたが、フロントエンドの新しい技術に触れることが出来、楽しく開発が出来ました。 また、修正Pull RequestやIssuesを立ててくれる仲間が増えてきて、徐々に社内のブログカルチャーが出来てきたかなとも思います。 まだまだ改良の余地があるテックブログですが、技術のキャッチアップを忘れず、引き続き頑張っていきたいです。 最後に 今年のアドベントカレンダーを通して、少しでも弊社の取り組みや社員の働き方を知っていただけたら嬉しいです！ そして、KINTOテクノロジーズでは、一緒に働ける仲間を募集しています。詳しくは こちら から 最後まで読んでいただきありがとうございました！ 参考 ZennのMarkdown記法一覧

実は、密かに進化しています。KINTOテクノロジーズ流インハウスクリエイター。 Merry Christmas！ クリエイティブグループでCDをやらせてもらっていますスギモトアヤです。今回は、このブログの場にお邪魔して、チームの紹介（自慢）をさせていただきます。私たちが在籍するKINTOテクノロジーズは、クルマのサブスクKINTOのサービスをドライブさせるエンジニアが中心の会社。名前の通り、テクノロジーの会社なのでエンジニアが中心ですが、その片隅でしっかりと生息しています。大好物は、誰も食べたことのない、一筋縄で解決しない新規案件です（笑）。 クルマのサブスクKINTOサイトの改善や、静的コンテンツ制作、販売店さん支援施策、新サービスのブランディングといった、ビシッと気合いの入る案件から、社内グッズのデザインというほっこり案件まで、クリエイティブなアイデアとお客様視点でお応えする23名の（2022年12月現在）制作集団です。私たちの活動をドラマチックに？！お伝えします。 シーズン1：2021年、お客様視点で考える集団へ いまでは、ビジネスサイトのメンバーと上流工程からディスカッションし、制作に取り組んでいますが、私が入社した頃は、ビジネスサイドから依頼を受けたものを制作するというスタンスでした。 このままでは、インハウスの意味がないので、「質の高い制作物をつくる集団が社内にいるみたいだぞ、相談にも乗ってくれそうだ」と認識してもらうために、まずは、我々発のプロジェクトを社内で立ち上げました。その名も「みんながわかるプロジェクト」。 ビジネスサイドの人に比べると、クルマに詳しくなることは難しいけれど、クルマを知らない人＝お客様視点で企画やUXの改善をすることはできそうだ、ということで社内を横断するチーム体制をつくり、プロジェクトを発足させました。私を含め、入社数ヶ月のメンバーで発足したので、心細かったですが、部長がサポートしてくれました。そして、社長に「お客様視点」での企画をプレゼンし、お墨付きのプロジェクトに。プロジェクト発信から結果を出すことで、社内で徐々に認めてもらえるようになりました。 シーズン2：2022年、共感できる仲間づくりへ 新サービスの上流を担う企画から入り、要件を整理し、制作進行もするWebディレクターと、カタチにするデザイナーは大忙し。社内の期待に応えるためにも、クリエイティブ力の底上げは早急な課題でした。採用を強化し、クリエイティブジャンプアップするためのビジョンに共感してくれるメンバーを増やしました。そして、組織体制に変化を加え、デザインプロセスの見直しなどをし、ビジネスサイドから「依頼される」ではなく、「相談を受け」て、共に施策に向き合うスタイルができあがりました。 いまでは、多彩なメンバーが揃って、頼もしい限り！みんな、ありがとうー！Webまわりだけでなく、グラフィック系、ロゴやネーミングといった新サービスのブランディングにも携わり、お客様のタッチポイントに関わるビジュアル部分の大半に携わることができています。 シーズン3：2023年へ、進化はつづくよ、どこまでも インハウスのクリエイティブとして、魅力的な環境というのは、情報が伝言ゲームにならずに、直接、ビジネスサイドと話ができること。お互いが熱量や夢みたいなものを伝え、カタチにしていくことはクライアントワークとは一味違う深みを感じます。ブランドコンセプトからトータルにデザインできるのはやりがいがあります。とくに、我が社は隣の島にはマーケティングチームがいれば、開発チームも身近にいるという環境。さらに、副社長や社長といった経営層と話せるのもかなり魅力的だと思います。もちろん、ダメ出しもダイレクトにもらえます（笑）！ 2021年、グループのポテンシャルを社内に広く示すためのプロジェクト発足。2022年は、クリエイティブジャンプアップさせることに共感してくれる仲間づくりができた1年でした。 と、そうこうしていたら、今年もあと数日です。2023年は、さらに進化＆深化できるように、幅広い守備範囲をカバーしながら、攻めていきたいと思います。 全ては、より良いモビリティサービスでお客様に感動してもらうため。 課題に取り組みながら、頭を使う。迷いながら、手を動かす。そして、よく食べて、よく寝る。KINTOテクノロジーズにいれば事業の成長とともに、若返りできそうです（笑）。 みなさま、よいお年をお迎えください。まずは、楽しいクリスマスを！

はじめに モバイル開発グループでiOSエンジニアをしている日野森です。 10年以上iOSアプリ開発をしてきた経歴を活かしてシニアエンジニアとして日々業務をこなしています。 今回はそんな日々の業務をやってたらいつの間にか内製化できた話をしたいと思います。 当時の状況 当時の開発の状況は、リリース2ヶ月前。開発はほぼ外部ベンダーさんが請け負っていて、進捗としては7、8割終わっていると言う話でした。また、運営側もスマートフォンアプリの開発も未経験なチームだったので、ベンダーさんにどう指示すれば良いのか困惑している様に感じました。 そんな状況のチームに私を含めた2名のiOSエンジニアが開発メンバーとしてアサインされました。 ちなみに当時は両者とも中途入社したてで、モバイル開発グループという枠組みも出来ていない時期でした。 改善点の洗い出し 最初に渡されたリポジトリの中に見事に出来上がっているスパゲッティコードに軽い眩暈を起こしたのを覚えています。 ジョインしてすぐに外部ベンダーさんと連携をとって大規模なリファクタリングをするのはコミニュケーションコストが高いので、外部ベンダーさんにはそのまま開発を続けてもらって、私たちは仕様理解を進めつつリファクタリングを行う事にしました。 当時のコードは、大きく以下の3つの改善点がありました。 ⛔ 活用されていないCI環境 ⛔ 統一されていないアーキテクチャ ⛔ 縦横無尽に呼ばれるシングルトンクラス 細かくはまだ色々ありましたが、ひとまずこの3つを大きな改善タスクとして進める事にしました。 大規模リファクタリング 大まかな方針は決まったので、まずはコードに直接手を入れない改修から入り、徐々に内部の深いところまで改修を進める事にしました。 ✅　活用されていないCI環境 当時、CI環境は一応用意はしてる様ですが、ほぼ使われてない状態だったので、以下の2点をCIで定期的に実行できる環境を構築。 コードの静的解析 ユニットテスト実行 ユニットテストのカバレッジレートは0%。すぐに数値を上げるのは難しいので、カバレッジレートは表示するだけに止めて、最低限のレビュー環境の整備に努めました。 ✅　統一されていないアーキテクチャ MVVMがベースになっている形跡はありましたが、Viewから処理を分離できておらず、ViewModelが飾りになっているケースがほとんどで、アーキテクチャとして機能していない状態でした。 そこで、MVVMにClean Architectureの原理を適用し、Input、Outputを活用してViewModelでPublisherの操作を行うという実装を全てのViewControllerとViewModelに行い、Viewから不要な処理部をViewModel、Modelに分離しました。 こちらの小山さんの記事にその辺りの開発手法が書かれているので、こちらも読んでくれるとより理解していただけると思います。 https://blog.kinto-technologies.com/posts/2022_12_07_Combine%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%A6MVVM%E3%82%92%E5%AE%9F%E7%8F%BE%E3%81%97%E3%81%9F%E8%A9%B1/ ✅　縦横無尽に呼ばれるシングルトンクラス シングルトンパターンは簡単に使えるのは利点ですが、誤解して使用されることも多く、共依存化、複雑化しやすく、テストも書きづらくかなり慎重な運用をしないと簡単にブラックボックス化してしまいます。 このパターンはチーム開発では非常に危険なので、このシングルトンで運用しているクラスを除去していきました。 この三つのタスクを1ヶ月程度の間に一気に解消した事で、コード全体の視認性が格段に良くなりました。そうすることで、ようやく実コードに落とし込まれた仕様を追える様になり、機能追加も問題なく処理できる様になりました。 そしてチーム開発へ 大規模リファクタリングが終わった事で、自然とベンダーさんがやるよりもこちらでやった方が早いと言う状態になり、こちらで開発作業を完全に巻き取る事が出来ました。 ただ、このままではチーム開発体制の基盤が出来ただけなので、ここから足りないUnitTestの拡充、データフローの整理、UIのリファクタリング、等々色々とありました。 しかし、再構築した基盤とPRのルール、ブランチ戦略・レビューフローを整えたチームはしっかりとしたコーディング思想が根付いてきていて、メンバーが増えても大きなコードの乱れもなく進める様になり、他のメンバーの指摘も適切な指摘が増えて、自走できるチームになったと思います。 👨‍💻👩‍💻 現在は、SwiftUIやモダンなアーキテクチャへのチャレンジをチームで進めることで、チーム全体でモダンな開発手法を取得できる様に日々チームで試行錯誤しています。 さいごに 私たちKINTOテクノロジーズではチャレンジを一緒にしてくれる仲間を絶賛募集中です。 一緒にチームビルディングできる日を楽しみにしています。

自己紹介・記事要約 先月はmy route開発Gのグループマネージャーとして紹介記事を書かせて頂きました岩元です。 実はモバイルアプリ開発Gのマネージャーも兼務しておりまして、なぜそのようなことになっているのかという事なども交えつつ、モバイルアプリ開発Gの紹介記事を書かせて頂きたいと思います。 モバイルアプリ開発グループについて モバイルアプリ開発グループとは モバイルアプリ開発グループは2022年初に設立されたばかりの新しいグループで、その名前の通りモバイルアプリ開発を専門とするエンジニアが集まっています。 モバイルアプリ開発の専門家としてのプライドを持ち、サービスの垣根を超えてKINTOテクノロジーズの関わる全てのモバイルアプリ開発を一手に引き受けています。 基本的には各サービスを担当する開発グループ(主にバックエンドAPIの開発を担当)と協力してモバイルアプリを作っているわけですが、作って納品して終わりという関係ではありません。その後の運用開発や改善にも積極的に関わり、各サービス担当開発グループと一緒に責任を持ってサービスを盛り上げていくグループです。 これまでの軌跡 それでは、なぜモバイルアプリ開発グループが設立されることになったのかという事についてお話ししたいと思います。 KINTO Technologiesの黎明期 KINTOテクノロジーズは(株)KINTOの開発部にルーツを持っています。当時のKINTOはWebでの申し込みが中心でモバイルアプリを持っていなかったということもあり、在籍エンジニアはWeb系のエンジニアばかりで、モバイルアプリの経験者は非常に少ないという状況でした。 my route開発 そんな中、元々はトヨタ自動車の実証実験からスタートしていたMaaSアプリである my route の開発をKINTOテクノロジーズが担当することになりました。当時のmy routeはパートナー企業により受託開発されており、それを内製化するというのが最初のミッションでした。バックエンドAPI開発の内製化は順調に進んだものの、モバイルアプリの開発に関しては専門のエンジニア不足によりパートナー企業頼りという状況が長く続いておりました。その状況を打開するため、モバイルアプリ開発経験のあるエンジニアの異動や積極的な採用活動を通して徐々にモバイルアプリの専門家を増やし、2021年の秋頃にはモバイルアプリ内製化のプロジェクトをスタートさせるところまで体制を持ってくることができました。 my route以外のアプリ開発 my route開発G内のモバイルアプリエンジニアの体制が充実してくるのに伴い、my route開発以外のグループからモバイルアプリ開発に関する相談を受ける事が多くなってきました。 その頃のKINTOテクノロジーズはmy route以外にもいくつかのモバイルアプリを扱うようになっていましたが、モバイルアプリエンジニアの不足からその開発はほとんどパートナー企業任せになっておりました。それが原因の全てとは言いませんが、あまり上手くいっていないケースが多かったのも事実です。 それらの相談に乗ったり開発業務を手伝ったりしているうち、my route開発グループでありながらそれ以外のサービスに携わる業務の割合が徐々に増えてきました。 モバイルアプリ開発Gの誕生 気がつけば半数ほどのメンバーがmy route以外のサービスを担当するようになってくるに至っては、このままmy route開発G内のチームという位置付けも組織的に無理がある状況となってきました。そのため、2022年1月に独立しモバイルアプリ開発グループが誕生することとなりました。 各サービスの開発グループ内にモバイルアプリエンジニアを配置することも検討されましたが、その時点ではそれぞれ出身やバックボーンの違うエンジニアが集まったばかりの状態であったため、今のままエンジニアが散らばってしまうとKINTOテクノロジーズとしてのモバイル開発の標準が確立できないことが危惧された結果、グループを設立するということになりました。 その甲斐もあり、約一年経過した今ではさまざまなことが標準化され、品質の高いモバイルアプリケーションを作れるエンジニアたちが集う組織へと成長しています。 モバイルアプリ開発グループの特徴 チーム構成 2022年末時点で25人ほどの規模まで人数が膨らんでいます。Android/iOSエンジニアの数はほぼ半数ずつで、両方に対応できたりFlutterやUnityなどマルチプラットフォームのスキルを持ったメンバーもおります。また、プロデューサーと呼ばれるPM的な動きをする人たちも数名在籍しています。 今現在はネイティブアプリの開発が中心ということもあり、大きくAndroidチームとiOSチームに分かれていますが、今後はサービス単位のチームに再編してサービスへの結びつきを強めることや両方のOSに対応できるエンジニアのスキルを活かせる組織に変えていく事も検討しています。 国際色 他グループと比べて非常に外国人比率が高いという特徴を持っています。特にAndroidを得意とするエンジニアは8割ほどがグローバル人材です。出身地域も韓国、中国、台湾、ミャンマー、ポーランド、ドイツなど非常に国際色豊かなメンバーが集っています。 英語の得意なメンバーも多いですが、今現在は会社としての共通語が英語化されているわけではありませんので、全員業務できる程度には日本語でのコミュニケーションが可能です。 いろいろな文化を持った人たちが集っていますので、普段からかなり賑やかで闊達なコミュニケーションが行われています。日本人だけの集団に比べてかなりダイレクトなコミュニケーションに面食らうことも多いですが、そういう違いを楽しめるような組織でありたいと思っています。 どんな人たちが集っている？ 採用の際に重視している事は、モバイルアプリ開発のスキルがある事は当然として、それ以上にモバイルアプリの開発に興味を持ち、トレンドを追う姿勢があるかという事です。というのも、モバイルアプリ開発の世界は日々新しい技術や手法が生まれてきており、既存の技術に安穏としていてはすぐに陳腐化し置いていかれてしまうからです。 その結果、モバイルアプリ開発が大好きというメンバーが集っており、業務以外でも切磋琢磨しており、勉強会なども活発に行われています。 新しい仲間へ モバイルアプリの専門家として成長したい、常に最新の技術を活かして業務したい、そんな方には最適の環境だと思います。 実際の業務経験が少なくても、熱意と勉強する姿勢を持っている人も大歓迎です。 私たちと一緒にトヨタグループを支えるモバイルアプリケーションを作っていきましょう！

はじめに KINTOテクノロジーズでmyroute by KINTOのデザイナーをしている山本佳と申します。 普段はmyroute by KINTOに関わる、LPやバナーデザインなどの広告デザイン、アプリの画面遷移の整理やガイドラインなどの制作を担当しています。 myroute by KINTOとは、移動手段の検索・予約・決済まで、移動に関する一連の機能をひとつのアプリ内で完結。「街の賑わいを創出」するイベントスポット・店舗情報の提供を行い、街中における円滑な移動のサポートをするマルチモーダルモビリティサービスです。 解決したい課題 チケットの販売枚数の向上、週の利用頻度増加という目標がある中での施策の一つとして、トヨタファイナンシャルサービス株式会社の担当者の方と協力させていただきました。 myroute by KINTO内に特集記事というコンテンツがあり、そこに誘導するポップアップを出して記事を選んでもらい、お出かけに繋がり、アプリの利用拡大を狙っています。 そこで今回のデザインのタスクとしては、アプリ内に出すポップアップデザインの品質向上となります。 クリエイティブ改善施策 「クリエイティブの品質の向上」と、かなり曖昧で現状と目指したいゴールの差異を埋めることが大切になると考えました。 まずは課題の棚卸、そこから今回のデザインにとってマストでやるべき3つの課題を抽出しました。 ①ターゲットに合ったアプローチにする。 担当者間で共通した人物像を形成して、どんな人に届けるのかを明確にすると、ユーザーにあったカラートーンで角の丸みは..などデザインを考えるのも楽になりました。 ②記事とデザインの整合性を保つ。 極端な例ですが、スタイリッシュなポップアップデザインがあったとして、その記事の内容が「紅葉に行ってかわいいカフェにおでかけ」のような記事では、読んでもらえずにすぐに離脱してしまいます。 ですので、デザインをする前に記事を読み込んで適切な表現を想像することが大切でした。 ③おでかけがしたいとおもえるワクワクを届ける。 抽象的でわかりにくいですが、よくネットなどで見かける「限定商品！」や「1000円はお得！」などのような、誰が見てもわかりやすいユーザーにとってのメリット要素は無く、今回のポップアップは「おでかけして楽しんでみませんか？」というアプローチなので、自分で広告をみたときの「ワクワク感」を大事にしました。 ポップアップの見せ方 デザインの課題とは別にポップアップの見せ方も重要だったので検討しました。 ABテストをして効果の高い見せ方の調査もしたいと思い、いくつかのレイヤーパターンを出しました。 「①は広告感が強いが表示させたいものがユーザーにとって適切だと効果が高い傾向にある。大手動画メディアの広告表示でやっていた。②は詳細の文章を入れているので親切で優しいタイプだが、文章が長いと飽きられそう。③は汎用性が高いタイプ、キャリア形のポップアップでよく見かけることが多かった、今回の施策に向いているだろうか...」など、様々な見せ方を検討していました。 結果 このように、デザインとしてできるアップグレードをいろいろな方向性から模索していました。 毎週ポップアップを打ち出した3ヶ月後の結果として、1100DAUの向上（この施策以外にも様々なキャンペーンなどをしているので、その効果も反映されています）、ポップアップのクリック率は7%から毎回19%近くにあり、11%の向上となりました。 クリック率の改善として良い結果が出たのは、トヨタファイナンシャルサービス担当者のビジネスサイドの課題解決策も素晴らしかったことはもちろんですが、私としては隔週でコミュニケーションをしてビジネスとしての狙いや記事の内容、デザインの方向性の理解を深めることができたことが何よりもこの結果に繋がったのではないかと考えています。 今後の課題 今回の施策について各地域のパートナーにも共有して、効果が高い広告デザインについて知識を深めることやデザインのガイドラインを制作して品質のブレを無くすなど、まだまだ課題があります。 今後もPDCAを回してデザインをアップグレードしていきたいと思います。

はじめに QAグループのokapiです。 私は、QAの主担当として案件に参画させて頂くことが多いため、今回は、KINTOテクノロジーズ株式会社で、QAが案件に参画して、どのように開発チームとコミュニケーションを取って、作業を進めているかを記事として作成します。 本記事の目的 QAと関わったことがないチームと案件を進める場合、 QAは何をやってくれるのか、どのように進めてくれるのかと探り探りで進む事が多いので、 そういった場合でもスムーズに進められるように「QAの認知度」をあげたいと思っております。 QAとは QAは、「Quality Assurance」の頭文字をとってます。 「Quality Assurance」は、「品質保証」という幅広いとらえ方となりますが、 「ユーザーにとって不利益が生じていないか」「ユーザーが使いやすいか」という観点で、 ユーザーの実際の利用想定に基づくシナリオテストや、画面UIの検証といった、 ユーザー視点でのテストを実施しております。 主なQAと開発チームのテストにおける役割分担に関しては、下記の表に記述します。 項目 QA 開発 備考 システム要件に沿った 仕様の確認 ㅤ◎ㅤㅤ ㅤ〇ㅤㅤ QAは、システム要件通りに機能と性能が満たされているかを、ユーザー視点を踏まえて確認 ユーザーの利用を想定したシナリオに沿った確認 ㅤ◎ㅤㅤ ㅤ△ㅤㅤ QAがメインで確認 上記以外 ㅤ△ㅤ ㅤ ㅤ◎ㅤㅤ 依頼があった場合、開発チームの外部結合テストやQAが確認可能な範囲でリソース的に問題なければ確認 QA作業の概要 作業フェーズ 概要 テスト計画フェーズ ㅤㅤㅤㅤㅤㅤㅤㅤ プロジェクト全体のスケジュールと仕様が分かる資料（システム要件、画面仕様書等）を連携頂き、QAが以降のフェーズの作業をどのように進めるかを記載したテスト計画を作成 テスト分析フェーズ 仕様が分かる資料（システム要件、画面仕様書等）から、 テスト範囲(テスト対象/対象外)を明確にしたテスト観点を作成 テスト設計フェーズ テスト観点からテストケース（前提条件・手順・期待値）を作成 テスト実施フェーズ 作成したテストケースを基にテストの実施を行い、 不具合報告・改修確認を行う 開発チームとコミュニケーションが必要な点 テスト計画フェーズ QAがテストを実施する期間/検証環境/QAの実施担当者・開発チームの窓口担当者/ 対象端末・ブラウザを纏めたテスト計画を基に開発チームと認識がずれていないかを確認します。 テスト分析フェーズ テスト観点を作成するために必要な情報は、JIRA or Confluenceを活用して質問し、 認識が合わない部分や開発チームの担当者が複数になる箇所は、 打ち合わせを行い確認して、仕様を整理します。 仕様が整理できたら、テスト範囲(テスト対象/対象外)を明確に分かるような テスト観点を作成して、開発チームと認識がずれていないかを確認します。 テスト対象/対象外については、ブラックボックステストの観点から、 ユーザーが実際に使う部分（QAが案件で必要だと思った所）を対象として、 ユーザが触れることのない部分（たとえばシステムの管理画面等）を対象外としております。 ただ、シナリオテストで一連の流れの確認も行うため、ユーザー側のテストで通る部分は、 対象外部分でもテスト対象となります。 ※リグレッションの箇所については、品質が保証されているので、 　連携頂いた期間とリソースを基にどこまで対象とするかを調整しています。 テスト設計フェーズ テストを実施するための手順を確認しますが、 テストケースについては、テスト観点で認識あわせた箇所に基づいて作成するため、 開発チームとの認識合わせは、ここでは基本行わないです。 テスト実施フェーズ 不具合（仕様と異なる期待結果）、 質問（仕様として存在しない、もしくは仕様が不明瞭な箇所）、 改善要望（仕様と一致しているがユーザーに分かりづらい箇所）をJIRAで報告、 開発チームで対応（修正）後に、QAチームで再確認をしてます。 テスト実施は、テストケース＋上記JIRA起票分の対応を含み完了 or 残っているJIRAの起票分が今回のQA確認対象外になった場合に終了となります。 実施が完了したら、全体の振り返り(KPT分析等）に参加して、 改善点を相談させて頂き、今後の案件に活かすようにしてます。 今後の課題 プロジェクトやプロダクトによって、「資料の纏め方」が異なる事があるため、 JIRA or Confluenceで仕様の認識を合わせた上で、QAでも、 ユーザーに関わるシステム全体の仕様やシステムの流れを資料に整理して進めています。 ただ、システムの規模によっては、時間がかかる箇所となりますので、 QAチームでの纏め方や進め方を整理した上で、開発チームと円滑なコミュニケーションを取り、 効率良く「QAチームで仕様を正しく理解するためのまとめ作業」をできるようにしたいです。 さいごに QAチームが独立した組織になってるので、 開発チームからみるとQAチームに作業を依頼してる形になり、 テストをやってもらっているという認識になる事がありますが、 QAとしては、同じKINTOテクノロジーズ株式会社の一員として、 品質の良いシステムを一緒に作り上げたいと思っております。 そのため、今後も協力的な関係を築き上げていきたいです。

自己紹介 KINTOテクノロジーズのグローバル開発Gで業務エンハンスチームに所属している森です。我々が普段行っている業務については チーム紹介記事 をご参照ください。 我々チームのミッションの１つに「グループ全体のポテンシャル底上げ」があります。今回はこのミッションの一環として取り組んでいる「KUDOS」の活動を紹介いたします。 KUDOSとは？ 「Kudo(s)」とは、直訳で「称賛」「賛辞」を表す言葉です。もともとギリシャ語で名声や栄光を表す言葉が語源になっているようです。近年、Kudosは、名前こそさまざまですが、社内の人に対して感謝や称賛の気持ちを表す「称賛文化」導入の取り組みとして多くの企業で取り入れられています。 称賛は従業員のモチベーション向上に有効です。自分の功績を認められた人は、仕事に対して満足度を向上させ、パフォーマンスを上げることにより、今までよりもさらに会社の生産性に貢献するようです。 参考： Where Does Kudos Come From? The Origin of Kudos と、堅いことを書いてみましたが、社内だけでなく日常生活でも多く用いられています。 ワークアウト用SNS「Strava」の例： Kudos👍をあげよう！ Slack app「Colla」の例： キャンディ | Colla 「褒められること」がモチベーションを向上させるというのがわかりやすいですよね 🥰 実は、私自身も前職で「Thanks card」という同じような活動がありました。管理職が感謝を表したいときにカードを渡します。もらうのはただの紙ですが、めちゃくちゃ忙しくて心がつぶれそうになったときでも上司からThanks cardをもらうだけで、「この仕事をやっててよかったんだ」と救われた気がしました。 チーム内での運用 人との関係の中で感謝・リスペクトはとても大事です。立場に関係なく、どのような人に対してもこの想いを持った上で接することで、信頼関係が築けます。 2022年春ごろ、業務エンハンスチームが設立した際もこの考えを大事にしたかったのですが、我々は個々に違うタスクに従事しているためなかなかその意を表明できませんでした。 そこで、チームのWeekly meetingで「Kudos」を取り入れることにしました。Kudosという名前はチームメンバーが起案してくれ、週次のチームミーティングで「今週の〇〇さん、XXXの提案ありがとう」のように感謝の意を伝えます。「ちゃんと見てくれているんだな」「私のこういうところを評価してくれているんだな」というのが目に見えて、単純にうれしかったです。 🔻業務エンハンスチームのWeekly meetingテンプレート。カジュアルに感謝を伝えています。 グローバル開発グループへの導入 グローバル開発Gは現在約60名が所属する社内最大の組織です。組織拡大によって陥る課題は様々ですが、我々も例外なくこの壁にぶち当たりました。 参考： 組織拡大で生じる「30人、50人の壁」とは？ そこで、グループ内のモチベーション向上を目標として、まずは率直な意見を聞くために2022年5月より「Global KINTO: Monthly your voice」[^1]を始めました。 [^1]: KINTOおよびKINTOテクノロジーズでは社内の声を拾うため「Montly your voice」なる従業員アンケートを行っており、これをグローバル開発G版として始めたものです。 当初は自由筆記制にしていたのですが、グローバルの良い部分を伸ばし、悪い部分を改善できるようにするため2022年7月にリニューアルし、アンケート形式で運用開始しました。 Kudosについても、この一項目として設けました。今までチーム内で活用していて効果があることはわかっていましたが、グループ内に取り入れることで、感謝の気持ちを言い合うことによる信頼の形成、他チームやマネージャー層へのアピール等につながることが期待できました。 🔻 実際のGlobal KINTO: Monthly your voice質問項目例 運用の効果 運用は以下のサイクルで回しました。 1️⃣ 月初にMonthly your voiceのアナウンス 2️⃣ 2週間のアンケート期間 3️⃣ 3週目で集計 4️⃣ 最終週に行うグループの月次定例会でMonthly your voiceのサマリーと共に発表 サマリーの発表時、Kudosをもらった人全員発表しますが、中でも良く頑張っていたな、という人やチームに対しては今月のMVPという形でマネージャー陣から表彰いただいています。 約5ヵ月運用しましたが、実際にグループメンバーからも「嬉しい」「グループの雰囲気が良くなった」という声をいただいています。私自身としても、前よりグループ内のコミュニケーションが活発になったと実感しております。 運営側としても「このチームはうまくやっているな」「この人ってこういうタスクに取り組んでいるんだなぁ」というのが目に見えるのでメンバーのことがよくわかるようになりました。 🔻 直近のアンケート結果でも改善したという声を多くいただいています 😊 課題と改善 これまでアンケートの形式で行っていたKudos投票ですが、前述の通り投票期間が２週間だけ、かつKudosを投票するにはアンケートに答える必要があるので、投票の数が少ないのが現状です。 Kudosは他人へリスペクトを伝える場として用意したので、もっと気軽に、いつでも投票できるべきかと思っています。グループ内からも「いつでも投票できるようにしてほしい」との声をいただいたので、11月中旬からは「Paper Kudos」として紙に書いていつでも投票できるようにしてみました。 まだまだ運用したばかりですが、早速「紙のKudos嬉しい」という声もいただいており、以前よりも投票しやすくなったかな？と感じております。 🔻 アナウンス時の様子。Slackでの反応も上々でした。 🔻 こんな感じで置いてます。 今後取り組みたいこと Kudosの活動は今後も様子を見ながら改善予定です。まずは、物理的に本人にKudos cardを渡せるようになったので、手書きメッセージを渡すつもりでいます。書いた人の気持ちが入っているのがわかりやすいかと思います。 また、表彰の方式や運用の方法についても改善を考えています。今は月次定例で発表してMVPを表彰するのみですが、例えば紙をオフィスに掲示したり、Kudos cardが何枚たまったら景品（ノベルティ）がもらえる、など、Kudosを楽しめる活動を検討しています。 グローバル開発Gだけではなく、KINTOテクノロジーズ全体としてもSlack内に#thanksチャネルがあり、称賛の文化が広まっています。グループ内ではKudosの形で活動を行っていますが、これからも社内全体の称賛文化拡大に貢献できればいいな、と考えております 🎉✨ KUDOS for reading my article😊💗

We would like to introduce some teams that support the global expansion of KINTO. Self introduction My name is Mori and I am part of the Business Enhancement Team in the Global Development Group at KINTO Technologies. If you would like to know more about what we do on a daily basis, please visit the Team Introduction article. One of our team missions is to increase the potential existing in our department. As an activity related to that mission, I will introduce our KUDOS system today. What are KUDOS? Kudos are a way to praise and express admiration to someone or something for an achievement. It derives from ancient Greek, meaning glory or renown. In recent years, Kudos has been adopted by many companies as an initiative to introduce a "culture of praise" that conveys appreciation and admiration for people within an organization, although the name may vary. I believe praise is effective in motivating employees. Those who are recognized for their accomplishments may improve their satisfaction in the organization and contribute further to the company's productivity than before and increase their performance. Reference: Where Does Kudos Come From? The Origin of Kudos But enough about serious stuff. It can be used not only within a corporate context, but also in daily life. - Examples can be seen on the workout social media "Strava": Giving Kudos👍! - or on the Slack app "Colla": Candy | Colla It's easy to see how "praise" improves motivation 🥰 In fact, I had a similar activity called "Thanks card" at my previous company. Cards were given by managers to staff when they wanted to express their appreciation. It was just a piece of paper, but receiving a Thanks Card from my boss when being overwhelmingly busy, really helped me feel validated about all my efforts at work. How Kudos work in our team Gratitude and respect are very important in our relationships with others. Regardless of position, you can build a relationship of trust by treating any person with this thought in mind. We wanted to keep this idea when the Business Enhancement Team was established in the spring of 2022, but it was difficult to express this in any form as we were all working on different tasks. So we decided to incorporate "Kudos" in our team's weekly meetings. A team member came up with the activity, and from that point onwards, we started thanking each other at our weekly team meetings, such as “thank you A for suggesting this idea!” I felt happy hearing praise from others, made me feel seen and was also nice to see the points where people value my work. 🔻 Weekly meeting template of the Enhancement Team. We express our thanks in a casual manner. Implementation on the Global Group The Global Development Group is currently the largest organization in the company with approximately 60 members. There are a variety of challenges that one encounters when expanding an organization, and us as well are faced with this situation. Reference: What is the "30, 50 person barrier" that arises in organizational expansion? Therefore, with the goal to increase motivation within the group, we started "Global KINTO: Monthly your voice"[^1] in May 2022 to first listen to our colleagues’ candid opinions. [^1]: KINTO and KINTO Technologies have an employee survey called "Montly your voice" to gather feedback from within the company, and we started a Global Development Group version of it. Initially we were just collecting comments, but in July 2022, we renewed it and changed it to a questionnaire to make sure we could see development of the good parts and improve the bad parts. Kudos was also established as one of these improvement points. We had been using the system within the team and knew it was effective, but by incorporating it into a bigger scope, we hoped that it lead to more positive circumstances such as trust-building through mutual expressions of gratitude or enhanced visibility and presence among the different teams and management. 🔻 Actual content from the Global KINTO: Monthly your voice Benefits of Kudos The operation followed the below cycle. 1️⃣ Monthly voice announcement at the beginning of the month. 2️⃣ Two-week survey period. 3️⃣ Tallying in the third week. 4️⃣ Presentation of Monthly Your Voice summary during the group's monthly meeting in the last week. During the presentation of the summary, all Kudos recipients are announced, and managers award one "MVP of the Month" to individuals who have excelled and to the team that has achieved the highest performance. After running this process for approximately five months, we have received positive feedback from group members who expressed their satisfaction and noticed an improvement in the group atmosphere. As for myself, I feel that communication within the group has become more active than before. As the organizer, I have observed that the team is performing better, and that it helps provide visibility on assigned tasks. This visibility allowed me to gain a better understanding of my colleagues and their work. 🔻 Many of our most recent survey results also show improvement 😊. Challenges and improvements Kudos voting is inside a survey form, but as mentioned above, the voting period is only two weeks and the survey must be completed fully in order to write Kudos, so we have received just a few of them at this point. Since Kudos was created as a way to express appreciation to others, I think it should be easier to do and people should be able to give them any time. Some members of the group asked us to make it possible to vote any time, so from mid-November onwards, we started "Paper Kudos". Although we have only just started, we have immediately received comments from people saying they are happy with them, and we feel that it has become easier than before. 🔻 How we announce it: the response on Slack was also very positive. 🔻 We placed them like this in the office. What we would like to work on in the future We plan to continue and improve upon our Kudos-giving culture. Now that we can physically give Kudos cards, we intend to keep the format of handwritten messages. I think that the writer's feelings can been seen more clearly this way. We are also considering improvements in the method of awarding and organizing the awards. Currently, we limit the presentation of MVPs to the monthly meetings. However, we are exploring additional activities to enhance the activity to show appreciation to others, such as displaying the cards in the office or offering small prizes to individuals who accumulate a sufficient number of Kudos cards. Moreover, not only the Global Development Group, but KINTO Technologies as a whole, has a #thanks channel in Slack and the culture of praise is spreading. We have our Kudos system in our Group, but we hope we can continue to contribute expanding the culture of praise throughout the company 🎉✨ KUDOS to you for reading my article 😊💗

はじめまして、KINTOテクノロジーズでUIデザイナーをしている青嶋と申します。 普段は業務用アプリケーションのUI周りを担当をしております。 少し前になりますが、弊社サイト改修の参考にしてもらうべく、サイトでお客様がどの様に振る舞っているのかを調べるため、ユーザビリティテストを実施しました。 テストのテストといった意味合いもあったので被験者を社内で募り小規模に行ったところ、きちんと考察に値するデータを得ることができましたので今回はテストの概要と実施時の工夫について書きたいと思います。 ユーザビリティテストとは まずユーザビリティテストとはテストと言っても合格や不合格を判定するためのものではなく、ユーザビリティという概念に欠かせない3つのポイントを見定めるためのテストです。 ですのでまずユーザビリティという概念について説明します。 ユーザビリティの定義 ユーザビリティという言葉自体は使い勝手とか使いやすさなど漠然とした意味合いで使われることが多いと思いますが、実は国際規格 ISO 9241によって、次のように定義されています。 「ある製品が、特定のコンテキスト（利用状況）において、特定のユーザーによって、特定の目的を達成するために用いられる際の、効果、効率及びユーザーの満足度の度合い」 そして効果、効率及びユーザーの満足度という3つの項目は以下のように説明可能です。 効果（effectiveness） : ユーザーが目標を達成できるかどうか。（例：ECサイトならちゃんと買い物ができるかどうか） 効率（efficiency） : ユーザーが目標を達成できる場合に、無駄な手順を踏まずなるべく最短経路で目標を達成できるかどうか。 ユーザーの満足度（satisfaction） : 効果や効率に大きな問題がなかったとしても、ユーザーがどのくらい不愉快に思わずに操作できたかの度合い。 例えばECサイトならばそもそも買い物という目的が達成できなければ、ユーザビリティが低いもしくは無いことになります。そしてもし目的が達成できたとしても、なかなかお目当てのものにたどり着けないなど無駄な手順が多ければ、同じくユーザビリティが低いということになりますし、その他の原因でイライラしてしまうなど不快な思いをすればその分ユーザーの満足度は低くなり、同じくユーザビリティが低いということになります。 その様な状態のまま放置しておけば、いずれライバル企業やライバル製品に大切なお客様が流れてしまうという自体を招きかねません。 そうならないためにも製品の取り扱い時やサイト上でお客様がどう振る舞っているのかを知り、ユーザビリティを考えることはとても大切なことではないかと思います。 ユーザビリティテストにできること / 目的 お客様が不快な気持ちにならず、むしろ喜んで製品やサービスを利用していただくことが会社の営利活動の礎となるので、製品やサービスに問題点があったらそこを改善していくべきです。なのでまずは問題点を明らかにするべきところから始めていくわけですが、幸いにもすでに分析グループによるお客様アンケートが存在しており、サイトのどこが分かりづらかったのかというピンポイントの設問がありましたのでそれを参考にさせていただきました。 そしてその問題となっているポイントでお客様がどの様に振る舞っているのかを知ることができれば、なぜそこが問題点となっているのか？のヒントに繋がっていくと考えられます。そのヒント集めがユーザビリティテストにできることだと言えます。 例えれば、アンケートは学生時代の英語のテストと同じようなもので、リスニングがだめだった、文法がだめだったなどどこが悪かったのかを導き出すことを得意としているのに対して、ユーザビリティテストはではなぜそこが悪かったのか？という理由やどうすればよくなるのか？のヒントを導き出すことを得意としていると言い換えることが出来ます。 テストを行う前の準備 タスクや条件を設定 まず最初の準備としては、アンケートによると年齢層に関係なくサイト上で分かりづらいと感じる箇所があるようでしたので、そこを中心に「効果」、「効率」の2つのポイントをテストするためにタスクや条件を設定しました。 このタスクや条件の設定は2つの点で大事だと言えます。まず一つは、被験者に自由に操作してもらっても問題点にふれることなく終わってしまうかもしれないというので、それを防ぐという点。2つ目は様々なリテラシーの方々に同じ条件の下で考えて操作してもらうという点です。 台本・質問・アンケートを用意 次なる準備として、テスト内容を被験者に説明するための台本と彼ら/彼女らのバックグラウンドやリテラシーを知るための質問表、さらにテストが終わった時に行ってもらうアンケートを2種類用意しました。 被験者の方達に安心して参加していただくためにも、テストの前に内容や流れをきちんと説明してあげる必要があります。さらに被験者のバックグラウンドやリテラシーに迫るための質問も行いますので、漏れなく速やかに説明・進行するためにも台本は必要です。アイスブレイクやらなんやかんやで割と時間がかかってしまう場合もありますので、できれば進行の時間割もしておくほうが良いと思います。 テスト終了後に行うアンケートというのは先述の3つのポイントの最後の項目である「ユーザーの満足度の度合い」を図るためのもので、CSAT（CUSTOMER SATISFACTION SCORE）とSUS（SYSTEM USABILITY SCALE）という指標を用いました。CSATは顧客満足度と呼ばれる調査で使われることが多く、満足の度合いを5段階で評価するものです。一方のSUSはわかりやすさや難しさなどの受け止められ方を指標化したもので、いわゆるUXの評価指標としてひろく使われているものです。ちなみにSUSでは導き出される点数が68点以下の場合ユーザビリティを見直す必要があるという基準があるところが分かりやすくて重宝されている理由ではないかと思います。 デバイスのセッティング 最後の準備として、テスト時に被験者の表情や操作の様子を録画するためのスマホとノートPCを用意します。スマホでは手元の操作を、PCでは顔の表情を録画させてもらいますのでそれぞれセッティングを行います。テストが始まったら両方のデバイスでウェブ会議ツール（Microsoft Teams）にログインし録画機能を利用して録画を開始します。（この録画機能は撮影終了後クラウドに自動的に保存されて、しかも自動的に2画面になっているので非常に便利です。） ちなみにスマホスタンドは100円ショップで購入したものを利用しました。 余談ですが一昔前は手元撮影用と表情撮影用でビデオカメラを2台使用し、撮影したデータをローカルに保存して、2画面同タイミングで見比べられるように編集して、、、など行っておりましたので、数年前に比べて遥かに簡単にテストが行えるようになったなぁと少々感動しました。 テスト実施 ここまで準備ができたらついにテスト実施となります。 アイスブレイクもそこそこに説明・質問とを行って、サイト操作によるタスクの実行に移っていきます。 テスト自体は思考発話法で行いました。この方法は被験者に操作を行っていただきながらその時思ったことを口に出してもらうという方法です。平面的な映像情報と、思ったことの発話という音声情報により、立体的に振る舞いを把握しようという方法です。 テスト時の注意点 この時に気をつけなければならないことが2つあります。 一つは、被験者は操作をしながら頭に浮かんだことを発話するということに慣れていないので、黙ってしまわないように常にどう思っているのかをインタビューアーが促し続けていく必要があります。 もう一つは被験者がインタビューアーに質問をすることがよくあるのですが、それはなるべくスルーしなければならないということです（無視ではないです）。 事前の説明では、「被験者が上手にサイトを使えるかどうかのテストではなく、サイトが分かりやすいか難しいかなどを判断するためのテスト」だということを必ず伝えるのですが、それでも被験者は自信のない場面では何気ない気持ちで質問してしまいたくなるものです。しかしそれに答えてしまうとバイアスがかかってしまうこともあるので、答えても差し支えのない質問なのかどうか判断して返答する必要があります。 そしてタスクを終えてアンケートも記入していただいたら、テスト終了となります。 考察に向けての準備 テストが終わったら、次に考察へ向けての準備が始まります。 テストが終わって一段落と行きたいところですが、ここからがむしろ時間がかかる工程となります。 まずやることとしては、文字の書き起こしです。 情報共有のために テストの音声データは一人につき20分〜30分くらいなのですが、聞き取りにくい部分は何度も巻き戻したりすることで結構な時間がかかります。ここが一番骨の折れる作業と言えかもしれません。しかし時系列的な音声情報を平面的な文字情報に変換することで、情報共有が一気にやりやすくなるので、ここは未来のために我慢して黙々とやり続ける必要があります。（音声を自動でテロップ化してくれる機能はまだまだ使い物にならない印象でした。） 次にその発話内容をカテゴリ分けしたりタグ付けしていくなどして分類可能な状態にします。 最初にスプレッドシートなどでまず時系列的にまとめておいて、その後にmiroなどのツールにコピペしていくことで、複数人数の行動データを俯瞰的に眺めたり、様々な軸でまとめたりすることが可能になります。 さらに情報共有をするならば映像データを短く編集しテロップを付けておくことで、テストの様子も簡単に共有することが出来ます。時間的に余裕がある場合はそこまでやってもいいかもしれません。 この時のテストは被験者が5人というごく限られた人数だったこともありそこまで行いましたが、これも非常に骨の折れる作業でした。 考察から改修へ 本来であれば得られたデータを元に複数人数で考察を行い改修へとつなげていくのですが、この時はテストのテストというレベルでしたので、自分の考察をまとめレポート化し一旦ここで終了となりました。 議論のできる人数でステークホルダーを集めて、意見を交わし考察する。そういった工程を経ることで同じ目線で改修へと繋げていくことが可能になるかと思います。ここに書いてきた全てはその為の準備です。 最後に 今回はサービス全体の一部であるウェブサイトの更にその一部分をフィーチャーしてテストした時のことを例に書かせていただきました。そんな一部分のテストにもこうした時間のかかる準備が必要になるわけですが、こうした小さな積み重ねの集積がお客様のサービス体験につながっていくと考えております。 世の中の変化やお客様の要求にすこしでも応えるため、ウェブサイトの進化を支えていけるよう尽力できればと考えております。そしてこの内容がこれからテストを行いたいと考えている方の何かの参考になれば幸いです。

はじめに KINTOテクノロジーズの開発・編成本部-プロジェクト推進グループの岡本です。グループ・マネージャーを務めています。よろしくお願いいたします。 私は2020年12月に株式会社KINTOに入社、プロジェクト・マネージャーとして活動しつつ、その後、KINTOテクノロジーズ株式会社の設立に伴い転籍し、現在はグループ運営を中心に活動しています。 経歴としては以下となります。 大手SIer24年　SE、PM Salesforce専業のSIer　PM 外資系損保会社　会社合併に伴うシステム統合の推進、アーキテクト 若い時はAssemblerでのプログラミングを経験してたりするかなりのオジサン。 エンジニア、PMとして、いろんなことを経験していて、小さな引き出しをいっぱい持ってるのが強みだと自負しています。（要は広く浅くですが。。。。） KINTOテクノロジーズでも幅広く会社、システムを理解することで、組織、プロジェクトをリードできるよう心掛けています。 グループのミッション では、プロジェクト推進グループの紹介をさせていただきます。 主なミッションは以下の3つです。 KINTO国内事業に関する組織横断プロジェクトのマネージメント KINTOが立ち上げるサービスに関わるシステム開発プロジェクト 既存サービスへの商品追加などのエンハンス系のプロジェクトもあり プロダクトの運用・保守 本番稼働しているシステムの運用および保守（エンハンス）開発 上記プロジェクトに加わり開発することも多々 開発サポート 統合検証環境運用、DevOps環境構築支援、B to B領域のUI/UX支援 関連会社であるトヨタファイナンシャルサービス株式会社、トヨタファイナンス株式会社との決済関連サービスの開発に関する協業や支援活動 KINTOテクノロジーズは若い会社ですから、まだ組織構造は柔らかく、KINTOの成長に合わせて変容し続けています。プロジェクト推進グループはその変容真っ只中にいるグループ。プロジェクトを扱うグループ名ながら、プロダクトの運用・保守も担っているのはそういう背景からです。今の状態が完成形ではなく、今後も分割、新たなグループ統合が継続的に行われていくはずです。 プロジェクト 前記の通りいくつかミッションがあるのですが、メインとなるプロジェクトについてお話ししたいと思います。 担当するプロジェクトはKINTOが手掛ける新サービスのシステム開発、既存サービスへの商品追加対応などなど。 直近だとKINTO ONEへの bZ4X 専用商品追加、 KINTO ONE中古車 などを手掛けました。 他にも、進行中のプロジェクトの中には現在進行中のプロジェクトもありますし、企画部署から起案されるプロジェクトだけではなくだけでなく、開発側から起案して進めているアーキテクチャー更改のようなプロジェクトもあります。 プロジェクトは様々な形態、性質のものばかりで、プロジェクト・マネージャーはそのプロジェクトに応じた最適な計画を策定する必要があります。 基本的にはいくつものシステム・プロダクト・組織・業務が関わり合って、未知のサービスを生み出すことになるため、「わからないこと」「知らないこと」を多く抱えてのプロジェクト運営になることがほとんどです。 これは作り上げるものが世の中初のサービスだったり、業務を知らないところからのスタートだったり、社歴が浅いメンバーが多いチームだったり、故にいたることで初顔合わせの状態だったり、といった背景があります。 そのため、プロジェクト・マネージャーには以下のような活動をリードする力が求められます。 「わからない」を「わかる」にする 「知らないこと」を検知する 不確実な事象、曖昧な事象を明確な要件、仕様に落とし込む また、これらの活動を推進するにあたっては、会社、事業、システムを理解し、詳細な要件の提示・確定を待つのではなく、ゴールに適ったソリューションをくみ上げていく必要があります。 そのためには開発内に留まらず、関係者間で共通理解を得るためのコミュニケーション力も求められます。 前向きに捉えれば（且つ大袈裟に言えば）、形がないものを具現化していけることを実感できるし、それはシステムやサービスのみならず、人間関係も含めて作り上げていける。 こういう思いでやっていける方、世の中にサービスを打ち出すことをやりがいと思える方、是非プロジェクト・マネージャーの募集要件をご覧いただき、応募くださいませ。 プロダクト 次にプロダクトの運用・保守についてご紹介します。 プロジェクト推進グループでは、以下のプロダクトの運用・保守を担当しています。 業務システム KINTO ONEの申込審査、契約管理をサポートするシステム KINTO ONEの車両発注、登録、お客様への納車等の販売店業務をサポートするシステム お客様からの問合せに対応するカスタマー・センター業務をサポートするシステム KINTO ONE中古車 KINTO ONE中古車ECサイト KINTO ONE中古車の申込審査、契約管理をサポートするシステム リース料金を計算するシステム KINTO ONE契約終了車両の返却・査定・KINTO ONE中古車物件登録をサポートするシステム KINTO が所有する車両を管理するシステム 他社ECサイトからのKINTO ONE申込連携システム リース料金を計算するシステム KINTO ONE中古車の申込審査、契約管理をサポートするシステム 直売カーセンサーとのデータ連携システム みなさんがよく目にされる KINTO ONE 新車のサイトは別のグループが運用・保守を行ってるのですが、実は、そのサイトやサービスを支えるために、いくつものプロダクトが存在し、それらを私たちグループが担っています。。 これらのプロダクトは、プロジェクトを通じて生み出すところから関わり、リリース後の運用・保守を行うところも自分たちで行っています。 基本的にプロダクト・マネージャー、リード・エンジニアはKINTOテクノロジーズの社員が担っています。エンジニアについては、社員では絶対数が不足しているのでパートナー数社にご協力いただいてる体制で、社内エンジニアの採用も進めてます。 我々KINTOのシステム・プロダクトの多くは、まずは世の中に提供するサービスとしてミニマムな機能実装でリリースします。 そのため、本番運用開始後、徐々に機能追加を行っていくのが通常です。プロダクト・マネージャーは関係事業部の要求事項、システムの改善事項等をバックログとして管理し、関係者との定例Mtgなどで優先順位を決定します。開発チームをリードし、定期リリースを行いながらプロダクトを通じてサービス強化に貢献していきます。 また、既存システムへの商品追加プロジェクトが立ち上がった際には、機能改修対象プロダクトとしてプロジェクトに参画し、事業部、他システム・プロダクトとの調整を行いながら新たなサービス、商品のローンチに貢献していきます。 我々は基本的に内製体制を目指しています。故に要求があった部署と密接にやりとりしますし、社内のリード・エンジニアがアジリティを発揮して開発をリードしてくれるので、会社がサービスとして何をやりたいか、また、リリースした機能のフィードバックを近い位置で感じれるのはプロダクト担当メンバーがやりがいを感じるところです。 進行中のプロジェクトもあり、今後も運用・保守対応が必要となるシステム・プロダクトは増えていきますので、プロジェクト推進グループではプロダクト・マネージャー、エンジニアを募集しております。 最後に プロジェクト推進グループは2022年12月時点で37名が在籍しています。 上記プロジェクト、プロダクトの担当以外に、開発サポートやトヨタグループ会社のサポートを行っているメンバーも数名おり、いろいろな仕事の機会があります。 いずれのポジションにおいても、KINTOのサービスの継続的発展に寄与するのが我々の最大のミッション。トヨタ固有のノウハウや文化、安定感がありながらも、ベンチャー・マインドをもって実践できるのは非常に強みだと思っています。 加えて、全員が中途採用者で組織の文化、風土みたいなものはまだ育ってきてません。 そのため、これらを作り上げていくことに参加できるのも創業期である今ならではの魅力の一つかな、と思います。 グループ紹介ながらお仕事紹介のような記事になってしまいましたが、興味をお持ちいただいた方は採用ページも覗いていただければと思います。 https://www.kinto-technologies.com/recruit/projectpromotion/

Introduction My name is Okamoto and I work in the Project Promotion Group on the IT＆Creative Development Headquarters at KINTO Technologies. I am the Group manager. Thank you for your time reading this article. I joined KINTO Corporation in December 2020 as a project manager. Following the establishment of KINTO Technologies Corporation, I transferred there and have since been mainly in charge of group management. Here is a summary of my career: 24 years at a major system integrator as a systems engineer and project manager Project management at a Salesforce-focused system integrator Architect responsible for system integration following a corporate merger at a foreign-owned non-life insurance company I'm an old-timer and I've been around since the days of Assembler programming. With broad experience as both an engineer and a project manager, I take pride in having a wide range of "small tools" at my disposal. (Though in other words, I'm a generalist with breadth more than depth...) At KINTO Technologies, I aim to lead organizations and projects by building a broad understanding of the company and its systems. Group Mission Let me introduce my team, the Project Promotion Group. We focus on three main missions: Managing Cross-Organizational Projects for KINTO's Domestic Business This includes system development project for services launched by KINTO. Also enhancement projects like adding new products to existing services. Product operation and maintenance This involves operations and maintenance (enhancements) for systems already in production. I also often jump in the above projects and develop them. Development Support This covers managing integrated test environments, setting up support for DevOps environments, UI/UX support in the B2B domain. Also includes working with group companies (Toyota Financial Services Corporation and Toyota Finance Corporation) on payment-related service development and support. KINTO Technologies is a young company, so our organizational structure is pretty flexible and continues to evolve as the company grows. The Project Promotion Group is right in the middle of that ongoing transformation. That's why, even though the name suggests we only handle projects, we're also in charge of product operations and maintenance. What you see now isn’t our final form. We expect more group splits and integrations as we keep evolving. Projects We have several missions as mentioned above, but I would like to talk about our main projects too. It includes system development for KINTO's new services, as well as updates such as adding products to existing services. Most recently, we've worked on adding exclusive bZ4X products to KINTO ONE, and took on project management for the KINTO ONE Used Vehicles project. Other projects are ongoing too. Some are already in motion, others still in the early stages. And it's not just the planning department coming up with ideas; sometimes it’s the development team that kicks off projects, like large-scale architecture overhauls. Projects vary widely in type and nature, so project managers need to come up with plans that best fit each one. In most cases, projects bring together various systems, products, teams, and operations to create entirely new services. That means managing them often involves navigating a lot of "unknowns" and "things you’ve never dealt with before." That's often because we're building a brand-new kind of service or working in an unfamiliar business area. With many newer members on the team, it's also common for people to meet each other for the first time on the project. Therefore, project managers are expected to take the lead in things like: Turning unknowns into knowns Spotting what we don't know yet Translating uncertainty or ambiguity into clear requirements and specifications In addition, when carrying out these activities, it is necessary to understand the company, business, and systems, and to put together solutions that meet the goals, rather than waiting for detailed requirements to be presented and finalized. To achieve this, strong communication skills are key to building shared understanding across all the teams and people involved. If you look at it positively (and in an exaggerated way), you can realize that it is possible to materialize something that has no form, and this can include not only systems and services, but also human relationships. If that resonates with you, and you find purpose in launching services that make a real impact, we'd love for you to check out the Project Manager role and consider applying. Product Next up, here's a look at how we handle product operations and maintenance. The Project Promotion Group takes care of the operation and maintenance of the following products: Business Systems Application screening and contract management for KINTO ONE Dealer support operations for vehicle ordering, registration, and customer delivery for KINTO ONE Customer support system for handling inquiries via the customer center operations KINTO ONE Used Vehicles KINTO ONE Used Vehicle e-commerce site Application screening and contract management for KINTO ONE Used Vehicles Lease fee calculation system System for supporting vehicle returns, appraisals, and registration of used vehicles after KINTO ONE contract completion Asset management system for vehicles owned by KINTO Application Integration for KINTO ONE via External E-commerce Sites Lease fee calculation system Application screening and contract management for KINTO ONE used vehicles Data integration system with third-party sales platforms like Car Sensor While the KINTO ONE new vehicle website you often see is actually run and maintained by a different team, many of the behind-the-scenes systems that support it are owned and maintained by our group. We're involved with these products from the ground up, from the initial project phase all the way through to post-launch operations and maintenance. Generally, product managers and lead engineers are KINTO Technologies employees. As for engineers, we don't have enough in-house staff at the moment, so we're working with several partner companies while also actively hiring in-house engineers. Most of our KINTO systems and products are first released with a minimum features needed to go live as a public release. From there, we roll out additional features incrementally. The product manager keeps track of requests from related business divisions and system improvement items in a backlog, and works with stakeholders in regular meetings to set priorities. Leading the development team and delivering regular releases allows us to steadily improve and strengthen the services. When a new project is added to an existing system, we'll join the project as the team responsible for product updates. We coordinate with the business side, related systems, and products to ensure a smooth launch. We basically aim to keep things in-house. That's why we work closely with the teams making new requests, and our in-house lead engineers show agility in driving development. For the product team, it's rewarding to stay close to what the company really wants to deliver and to quickly hear feedback on features after release. As the number of products and systems we support continues to grow, so does the need for more hands on deck. That’s why we’re actively looking for product managers and engineers to join the Project Promotion Group. Conclusion As of December 2022, the Project Promotion Group has 37 members. Besides handling the projects and products mentioned above, some of us also support development tasks and help out other Toyota group companies. There's a wide range of opportunities, but our core mission is to keep KINTO services growing and improving. What sets us apart is the unique blend we bring: a startup mindset backed with the experience, culture, and stability of the Toyota group. Since everyone joined mid-career, our company culture is still a work in progress. We see shaping that culture together as one of the unique perks of working at our company now, in the early stages of its founding. This ended up being more of a job introduction than a team overview, but if any of this caught your interest, feel free to check out our careers page. https://www.kinto-technologies.com/recruit/projectpromotion/