はじめに KINTOテクノロジーズでQAグループのリーダーをしている遠藤です。 今回は、QA業務を日々行っていく中で、QA業務に携わっている人であれば誰しもあるあると思われる事柄を題材に、普段我々が行っている取り組みを通して、QAの作業風景をご紹介できればと思います。 既にQAの作業に関しては、 マネージャーのzumeが記述している QAグループ紹介 メンバーのokapiが記述している QA業務の認知度向上 がありますので、合わせて読んでもらえればと思います。 本記事をきっかけに、 『自分たちの現場はこう対応しているよ』 『この作業はどう対応しています？』 など、いろいろご意見いただけると幸いです。 QA作業の流れと注意している視点 QAの作業については、主に 開発プロジェクトのQA実施 保守改修のQA実施 テスト自動化 QA内部改善 QA作業の改善活動 勉強会 があります。　 今回は、この中で、プロジェクトに対して行うQA作業の流れを以下に示し、意識している視点についてご紹介します。 それぞれのQAへの思い QA作業の概要に関しては、入社時のオリエンテーションや、各プロジェクトのkickoffで説明しています。ですが、プロジェクトに携わるメンバーは誰もが経験豊富な社員なので、それぞれの経験に基づいたQAへの理想イメージを持っています。そのため、QAではこういうところまで見てもらえるのでは？といった認識相違は担当者間でもしばしば起こります。ただ、QA範囲の認識違いはあっても、根本的には共通して 　「品質で漠然と不安が残る部分を、QAのタイミングで何とかしたい」 と思っている方が多いかなという印象です。この不安部分にいかに寄り添い、不安を解消し、無事リリースを迎えるかがポイントになるかと思います。 まず最初に、Kickoffのタイミングで関係者にQA作業をイメージしてもらえるように、大きく下記の3点を説明しています。 ①全員で一緒に品質を作りこんでいきましょう！！ ②品質面で何か不安を感じたらいつでも遠慮なく相談してください ③QAの指摘は絶対ではなく、プロジェクトとして対応可否を検討しましょう 品質は「一緒に」作りこむ！！ ①は、言わずもがなですが、QAだけの力では品質は向上しません。前述の認識相違の結果として、 単体レベルの細かい部分の確認 ソース、データの流れを意識した確認 等の、ホワイトボックステスト寄りの依頼が出てくることがあります。 QAの作業はブラックボックステストが中心であり、ホワイトボックステストはQAよりむしろ開発側での実施が適しているので、そうお伝えしています。 このような依頼があるのは、今までQAで対応してもらった経験があったり、自分達では気づかない品質の不安をQAなら「きっと」見つけてくれる、という期待があるからかと思います。 QAの役割として、システムテスト、受け入れテスト、各工程のタイミングで確認することについては、関係者間での認識がある程度一致していても、その人の経験によっては、QAがソースやデータの流れを意識したシステム寄りな確認をしていた、ということもあれば、QAがユーザー視点を意識した確認を中心にしていた、ということもあります。 ただ、全般的には、QAとは開発全工程の標準化を含め、独自の指標を持って品質管理をサポートしてチェックしている部署、として幅広く認識されていると思います。 QAとしてそれぞれのその思いに応えたいとは思うものの、QAの気づきも限界がありますし、テストの期間も無尽蔵にあるわけではないので、限られた期間の中で、目標の品質を保証するべく、品質を「一緒に」作りこむという意識をもってもらうことが必要です。 ただ、QAが認識した要件を検証、指摘し、それを淡々と解消してもらうという関係ではなく、QAの仕様理解やテスト計画、テスト観点のタイミングで、 要件を 『一緒に』 すり合わせ 確認観点を 『一緒に』 認識合わせを実施し 改善内容を 『一緒に』 考える ことで、品質にとって良い効果が生まれると思って活動しています。また、そこでしっかりお話しをすることでテスト設計にいかすことができます。 開発側の不安は、品質向上のヒントの泉 テスト観点のレビューなどで、開発側が思っている不安の内容が具体的になっているものは認識できるのですが、漠然とこの処理が怖いという内容のものもあります。この、具体的には言えないけどここの機能が品質的に不安、という情報は、QAがテスト観点を纏めたり、テスト設計をする上で重要です。根拠はないが、漠然とこの処理が不安というのは、例えば、コーディングが複雑とか要件がきちんと定まってない（処理としては要件を定めたつもりでも、細部まで詰め切れたか不安）など、特に問題なく開発できているので言葉にはできないけれども、なにかしら品質上不安に感じるところがある、という開発に携わっている方の 『勘』 ではありますが、意外とテストをしてみると想定していなかった不具合が発生したりするので、軽視できません。 QAとしては、要件を確認し、具体的な不安点に対して、テスト計画＆設計を行いますが、こういうお話こそが、QAとして試験を強化できるヒントであり、想定より厚めにテストを実施する対策を講じることができます。 QAの工程では、本来、単体・結合レベルの不具合を見つけるというよりは、要件に基づいて何百ケースを実施して、重要、もしくは、致命的な不具合を1件見つけることが腕の見せどころではあるので、この『勘』が外れることの作業の無駄を考えるより、そのヒントを多く聞き出せる雰囲気づくりをして、自由に意見を言ってもらい、確認観点の想定以外で強化できる点を認識することで、品質向上に向けたテスト設計を行うことができます。 例えば、テスト観点の打ち合わせの段階で、 「こういう観点で進めます何かあればご連絡ください。」 で終わるのではなく、一言、 「今回の仕様でどこか気になる点はあります？」 と付け加えることで、「そういえばね・・・」みたいな話しになることがあります。不安点はあるものの、漠然としていて、何を伝えればよいのかわからない、伝えることは無いなと思うより、QAにとりあえず話してみよう！！という雰囲気づくり、そこには、前述した、「一緒に」という姿勢も合わせて対応することで、検証観点の強化、ヒントの泉がそこには隠されています。 QAの指摘に惑わされず、本来のゴールを見失わない 一方的にQAの作業スコープしかテスト実施しないとお伝えすると、QAは 『コードも理解せず、要件をなぞるだけ、細かい指摘ばかりで、リリーススケジュールに影響を与えるところ』 というような誤解をされやすい部分もあります。 ですが、前述のような説明を事前に行うことで、QAは『一緒に』品質を作り上げていく集団であると、180度違った見方をしてもらえることにも繋がります。 とはいえ、見方が変わったからこそというのもありますが、逆に、信頼してもらえることによって、QAの意見を全て受け入れ、テスト実施時に『指摘』したものを全てクリアしないとサービスインできないのでは、と不安に思う方もいます。 ここでいうQAがテストを実施して『指摘』するのは、下記の三つになります。 　 不具合：QAが認識している仕様と異なった動作（表示）を指摘 改善要望：仕様としては問題なく、機能として改善したほうが良いのではないかという提案 質問：仕様で不明確な点を質問 不具合に関しては、こちらが認識している仕様と異なっていた場合に指摘を行い、開発側で確認の上、改修し、改修後にQAの確認作業が入ります。改善要望に関しては、仕様としては問題ないが改善したほうが良いのでは、という提案になります。例えば、その他の画面は右上にボタンがあるのに、途中の1画面だけ左上にあったりした場合、ボタンの機能としては問題ないが、右上の方が良いのではないか？といった内容です。質問に関しては、テストを実施してみると不明確な仕様部分に気づき、不具合として挙げる前に確認、という点から指摘します。 リリースまでにこれらの指摘を全てクリアにするべきかというと、そうではありません。全ての指摘の改修対応を行い、質問も解消されることが一番望ましいですが、プロジェクトの状況によっては何らかの理由で全て対応することが難しい場合があります。全ての対応が難しい場合、指摘した事象の重要度、優先度を加味して、サービスインまでに対応すべきかそうでないかの判断をQAではなく、プロジェクトとして判断してもらいます。 QAの作業は、要件をもとに 『本来こうあるべきだ』 という内容のもと、テスト実施をしていきます。当然、要件をしっかり詰めたはずでも、仕様が不明確な部分が出てくることもあります。それらの全てが対応されることも望ましいですが、限られた時間の中で、QAの指摘を通じて、最終的な仕様を確認し整理することで、本来のゴールを見失わないことが重要になります。 そこで、③のお話しになり、プロジェクトとしてどういったサービスをどのタイミングで提供するかを整理し、ゴールを見据えたうえで、そこに向かって目標の品質を作りこむ。そこにQAは、しっかり品質面でサポートしていくことが重要になります。 ここで、時間が無いのでやりたい要件だけ満たせばその他の品質に目をつぶって妥協してサービスを提供する、とも聞こえるかもしれませんが、そうではありません。 QAは、定義された要件が十分満たされているか、というプロジェクトのゴール設定に向かって対応するとお伝えしましたが、あわせて、使用されるお客様に不利益になるような問題に関しては粘り強く関係者と議論します。決して妥協するのではなく、また、QAの指摘を一方的に押し付けるのではなく、プロジェクトのゴールやサービスの提供を受けるお客様を意識して、プロジェクトとしてどう対応するのかを『一緒に』考えて、対策を講じます。 万が一、リリース後に致命的な不具合が出ると影響が大きいので、QAもしっかり付き合い品質向上に貢献していきます。とはいえ、規模の大きい案件ほど、懸念部分は②のヒアリングで早めに対処していくのと、開発工程の特性上、最後の最後で致命的な不具合が発生することはまずないので、QAの作業が理由でリリース日が変更されることはほぼありません。 あくまで目標のリリース日に向かって、『一緒に』目標の品質を作りこんでいく姿勢が大事になります。 なので、繰り返しにはなりますが、QAとしては、ただ指摘して改修を求めるのではなく、プロジェクトの本来のゴール、例えば、目標の期間までにお客様に提供したいサービスを確認し、そこを見失わず、お客様に不利益やご不便が無いことを配慮しつつ、プロジェクトで合意した品質の確保のため、とことん付き合い『一緒に』品質を作りこみます。 さいごに 今回は、QAとして取り組む姿勢や、コミュニケーションで気を付けている点を中心にご紹介しましたが、技術的な側面で言いますと、QAは各プロジェクト、プロダクトを横串でかつ、俯瞰して見れる唯一の部署です。その点ならではのサポートや、その他、テスト計画やテスト観点、テスト設計の仕方などについて、機会があればご紹介しようと思います。 今回、ご紹介した作業の流れで、恐縮されながらQA依頼を受けることがあります。ここは『一緒に』の姿勢なので、遠慮せずに協力し合える関係性を築いていきたいと考えています。そしてリリース後には、 『とても助かりました！！』 『ありがとう！！』 と声をかけられます。その時私はいつも、いえいえ、QAの指摘に対して、真摯に向き合って対応してもらってありがとうございます。と、プロジェクト関係者全員の取り組む姿勢に頭が下がるとともに、感謝をしています。提供するサービスに対して、QAが品質面でしっかりサポートする、という信頼関係をしっかり築けるよう、日々QAとして精進し、そうやって『一緒に』つくったサービスがお客様にとっても役立つものになれば、それこそがQAの醍醐味というものではないかなと私は思っています。今回の記事でQAという仕事に興味を持っていただければ幸いです。また、同じQAという立場で意見交換できればと思いますので、ご意見お待ちしています。ご意見はTwitterまで。 https://twitter.com/KintoTech_Dev/status/1619979941856280577?s=20

こんにちは。KINTOテクノロジーズにてQAグループのグループマネージャーをしているzumeです。 QA歴はそれなりに長く広かったりするのですが、特にこれまで知見や情報を発信するといったことは意識していませんでした。とはいえここらでいったん自分の考えをまとめる時間が取れたらまとめたいなと思いつつ、除夜の鐘とともに2022年も終わっていたのでした。 普段仕事に追われていると難しいですね。と、自分で時間を作れないことの言い訳にしています。来月やろう、とあとN回つぶやいたらもれなく新しい年明けを迎えます。 テスト管理について さて今回は、私のグループで使用しているテスト管理ツールのメリットや、導入に至るまでの経緯についてご紹介したいと思います。 本記事をご覧のQAエンジニアの皆様、テストケースの管理はどうされていますか？ すでに何かしら、有償のテスト管理ツールをお使いの方もいらっしゃるかもしれません。 一般的に、テストケースやテスト実施の管理にはExcelやSpreadsheetが使われる傾向があります。ただ、ExcelやSpreadsheetを使ってテスト管理を行う場合、以下のような課題がありました。 テストプロセスの課題 - 課題 - ⇒懸念（として起こり得ること） テストケースの構成は、テスト設計者によって属人化しがちであり、ケースの項目分類や形式も異なる ⇒設計担当者が変わった場合に作業引き継ぎが大変 ⇒フォーマットが共通化されていないため、プロジェクトが変わるとケースの解読に時間が掛かる ケースを確認するには、都度ファイルを開いて中身を見なければいけない ⇒チーム内でのドキュメントやノウハウの共有が難しい 関係者（QA以外のステークホルダー）がテスト内容、結果を俯瞰しづらい ⇒QA側で報告用にレポートを整える必要がある リグレッション実施の際、テストサイクルの度にファイルを新しくする必要がある ⇒どのケースを再利用したのかが把握しづらい テストケースの変更履歴や更新経緯を追いにくい ⇒ケース内容の更新等、メンテナンスの際に時間が掛かる（加えてExcelはonlineでの複数同時編集に向かない） テストの実行結果が手入力のため、正確な実施時間までは分からない ⇒不具合発生時刻の特定がしにくい テストケースとバグレポートの紐付けが出来ていない ⇒機能毎の不具合発生率などの集計ができない（がんばれば手集計で出来なくもない。けどしんどい） などなど。 これらの課題を解決する手段として、テスト要件管理、テストケース作成、テスト実行、テストレポート など、一連のテスト活動を支援するツールの導入を検討しました。 というか、はなからExcelやSpreadsheetを使うことは考えていませんでした。 なぜなら一度Excel運用が浸透してしまうと、そこから脱却するのに時間が掛かるのも経験則で分かっていたからです。 導入するツールの検討 当初、候補に挙げていたのは以下 TestLink ：オープンソースのWebベーステスト管理ツール。無償。 TestRail ：Webベースのテスト管理ツール。有償。 Zephyr for JIRA ：JIRAのプラグイン。有償。 （2021年にZephyr Squadという名称に替わっていました[^1]） [^1]: Zephyr for Jira is now Zephyr Squad , SmartBear Software., 2021 TestLinkは、元々自分がこれまで過去の職場でも使っていた実績があった、というのが理由のひとつ。 ローカル環境でもDocker立ててインストールすればとりあえずすぐ試せる、という利点もあります。 実際、検証用のMac1台をTestLink兼用にしていたこともありました。 ですが、私がKINTOテクノロジーズに入社したのが2020年3月（当時は株式会社KINTO在籍）、ツール導入のターゲットとなるプロジェクトのリリース予定は2か月後の5月、というスケジュール。しかも新型コロナウイルスの感染拡大による最初の緊急事態宣言が、その間の4月に発令される。 というなかなかしびれる状況の中、その時最も適した選択肢として採用したツールはどれでしょうか？ 実は、 Zephyr for JIRA なのでした。 すでに社内で使われていたJIRAのアドオンですぐ導入できた、また、コロナ禍で予期せず発生したリモートワーク=社外からの利用を考慮しても便利、というのが大きかったです。 有償とはいえ、5月のリリースさえ乗り切ればそのあとの利用継続については再検討する、という考えの元、運用を開始しました。 当時のメモ見ると JIRAプラグインだから言語設定変えればいけるかと思ったら日本語は一部のみ対応っぽい や、 Zephyrのレポートはシナリオ単位であって、ケース（ステップ数）単位でのレポート機能無いんやなやっぱり など ^2 、 試行錯誤していた形跡が残っていましたね。懐かしい。 すぐ導入できたといいつつも、使う側の慣れやスキルも必要不可欠ではあります。そういう意味でも、当時の混沌とした時期を柔軟に乗り切ってくれたメンバーには今でも感謝しかありません。 Zephyrを使ってみて もう3年近く(!)昔の話にはなりますが、Zephyr for JIRAを使ってみた感想としては。 JIRAのプラグインなので、テストケースは任意の課題タイプを選択する手順で通常の課題と同じ様に作れます。 ケースの項目には、ステップと期待値、結果、ステータス、コメントの他にファイル添付があり、ステップごとに画面のキャプチャを証跡として残せるのは便利だなと感じました。 一方で、プラグイン自体の読み込みに結構な時間が掛かっていました。画面を遷移するたびに、数秒掛かるというのが悩みでした。こちらもAtlassianのコミュニティに同様の お悩み相談 が投稿されていたので、Zephyr固有の問題なのかもしれません。 そしてTestLinkへ さてどうにか当時のリリース予定スケジュールを乗り切って、2020年5月にプロジェクトが手を離れたあとのテスト管理についてですが。 あらためて費用面も踏まえて検討しました。 JIRA連携が前提なのと、ツールの利用者数は10~20人程度、とした場合に 2020年当時の価格は以下で、 Zephyr for JIRA：11-100 Users ￥510/user/month　⇒20人利用で￥10,200/月 TestRail：1-20 Users $32/user/month　⇒20人利用で$640（約￥83,200）/月 2023年現在の価格は以下です。 Zephyr Squad：11-100 ￥570/user/month　⇒20人利用で￥11,400/月 TestRail：1-20 Users $37/user/month　⇒20人利用で$740（約￥96,200）/月 当時とは料金体系が若干変わっていたのと、やはり多少値上がりしてますね。 ※いずれも1ドル130円として換算 ぱっと見、Zephyrはお得にみえますが、JIRAのプラグインということもあり、実はJIRAの既存ユーザーライセンス数と同数分が必要になります。 そこに関しては社内でも開発部署全員が使うわけではなく、QAメンバーのみの利用と考えると、組織拡大に伴って費用がかさんでいくのは避けたい。 にしてもTestRailはお高いですね。コストを考えると、フリーのTestLinkに勝る選択肢が見当たりません。 TestLinkに関してはUIがイマイチというのはありますが（オープンソースだから贅沢言わない）、テスト管理ツールとして、少なくとも先述の課題はそれぞれ以下のように解消できます。 テストプロセスの課題とその解決策 テストプロセスの課題 ツールを導入した場合 懸念に対して 1. テストケースの構成は、テスト設計者によって属人化しがちであり、ケースの項目分類や形式も異なる テストスイートやテストケース、テストステップ等を、一定のフォーマットかつ適切な細かさで記載することで、ある程度粒度が揃う 引き継ぎもケースの解読も楽！ 2. ケースを確認するには、都度ファイルを開いて中身を見なければいけない 実施項目の視認性が高く、テスト要件とのトレースもとりやすいため、カバレッジがわかる チーム内外でのドキュメント共有が楽！ 3. 関係者がテスト内容、結果を俯瞰しづらい テストの進捗状況をリアルタイムで把握できるのと、結果をレポートで一見できる QA側でレポート作成する必要なし！ 4. リグレッション実施の際、テストサイクルの度にファイルを新しくする必要がある テストスイート単位での再利用が可能 再利用の対象がつかみやすい！ 5. テストケースの変更履歴や更新経緯を記録に残しづらい テストケースの追加・変更に加えて、その履歴が残せる ケースのメンテナンスが楽！ 6. テストの実行結果が手入力のため、正確な実施時間までは分からない バグレポート、実行時間、実行者の記録も正確にロギングされる 実施時間帯を絞り込める！ 7. テストケースとバグレポートの紐付けが出来ていない テスト進捗率や不具合発生率など、要件/リリース毎のトラッキングがしやすくなる 機能毎の不具合発生率等、集計がしやすい！ というわけで、2020年6月以降はTestLinkを導入することにしました。 まあ、楽と書いてしまうとメンバーからは怒られそうですが、実際のところツールも万能ではないので、Excel等のデータファイルを使うよりかはだいぶ楽ですよ、という感じでしょうか。 追記 フリーといっても、運用に伴うインフラコストは掛かります。TestLink用にAWSのインスタンスを使わせてもらっているのですが、年間数万くらいの費用感です。なお利用開始から3年近く経ちますが、これといった大きな問題もなく今のところ運用出来ています。 今回は、QAグループにおけるテスト管理ツールとして、TestLinkの導入までをお伝えしました。 実際のプロジェクトでのTestLinkの利用例、JIRAとの連携等については、次回以降でまた機会があればお話できればと思います。

こんにちは、またはこんばんわ。 美味しい紅茶を飲みながら機械の分解をするのと写真を撮るのが大好きなグローバル開発 UIUXチームのazがお送りします。 UIガイドラインとは そもそもUIガイドラインとは何でしょうか？ どんな人が使うものでしょうか？ 誰がHappyになれるのか？ 少しずつ紐解いていきたいと思います。 ブランドガイドラインとUIガイドラインの違い 一般的なブランドガイドラインとUIガイドラインの違いについて説明します。 KINTOにも一般には公開していませんが、ブランドガイドラインは存在しています。 ブランドガイドラインとは？ 主に「ブランディング」として守るべき、以下のようなルールが提示されています。 ブランドの思想、理念 ブランド名やライティングの表記ルール 利用するカラーやイメージ 求めるべきユーザー体験 ※画像はイメージです このルールをベースにデザイナー達が表現方法やデザインを考えていきます。 参考： ブランドガイドラインとは？ UIガイドラインとは？ 一方UIガイドラインはデザインシステムなどを用いて「これを使えばOK」という具体的な事例を提供します。 ボタンやテキストなどに使う色や形 画面レイアウトの比率 アイコンやイメージの使い方 基本的にデザインも実装もそのまま使えばいい状態のパーツやスペックが載っています。 要件から実装すると何が起こる？ 例えば「KINTOらしい」ボタンを作るにはどんな条件があるでしょうか。 決まっている色を使って 四角くて 読みやすいラベルがあって ボタンだと分かるもの イメージできましたね。 出来上がったものがこちら。 どれも条件は合っていますが、思っていたボタンと違ってる部分が出てしまいました。 1段目…4方の角丸がない 2段目左…ボタン内の余白の縦横比がおかしい 3段目左…他では使わない影が入っている 同じ条件で同じものを作っているのになぜ細かい部分で揃わないのでしょう？ 何が違っていたのでしょうか？ それは 共通認識 です いつものメンバーがいつものように制作できれば同じものができる可能性が高いですが、実際にはメンバーもチームも流動的です。 出来てから「あぁ…思ってたのと違う…」となると作り直しが発生するのは時間も気持ちもロスが大きいです。 UIガイドラインではメインボタンは「角丸:30px、上下余白:10px、幅：画面比1/12…」といった細かい数値まで設定しているのでアウトプットにずれが生じなくなります。 UIガイドラインの考え方・使い方 フォーマットに則ってデザインすれば、デザイナーもフロントエンドもラクになります。 実際によくある例で説明していきたいと思います。 デザイナーがいなくてもガイドラインに沿えばOK 避けては通れないテキストサイズやスタイルの設定も、使われるスタイル数が決まっているので細かい設計に悩む必要が少なくなります。 サイズや余白が適切に設定されておらずクオリティの安定しないケースもよくありますが、 ガイドラインで設定された余白に沿っていればデザイナーが調整しなくても、見た目が崩れることなく画面が構成しやすいです。 画面サイズ問題が減る デザインファイルの立ち上げ時によく起こる「スクリーンサイズ何pixelにするか」問題。 ガイドラインで比率やブレイクポイントの設定しているのでそこで差異がでないようになっています。 「いつもの仕様」で作れるものが多い 入力フォームの配置 同じような内容や項目が多い代表例が入力フォームですが、項目追加や順番の変更も圧倒的に多いです。 最近のプロジェクトでも変更が何度もありましたが、ガイドラインを使ったデザインだったためデザインファイルの修正と実装を並行で行うことができました。 メッセージの出し方 結果画面やエラー画面のように文言や組み合わせが多数ある場合はとても多いです。 ステータス毎のアイコン、テキスト間のレイアウトが決まっているので、特殊な例をのぞけば全てのパターンを網羅して準備する必要がありませんでした。 困る人が少なくなーれ！ 経験値やスキルの差があっても最低限同じアウトプットを出せること 口頭や文字での伝達ロスを減らし共通認識を保つ この２つがガイドラインの大きな役割です。 困ったらここ見ればいい！解決！ となれるようにこれからも拡充していきたいと思います。

Hello! 👋 This is Ruoyang Wen from Global Group, KINTO Technologies . I work as a full-stack engineer in Global KINTO App team. You can read more about the Global group here. Objective As a startup company, there are a lot compromises within our first generation product. For the greater benefits, apart from the service we provide, workflow is also where we need to improve. This article shares why and how we changed our workflow from Git-flow to GitHub-flow. Attempt As part of the Toyota group companies, we implement the principle of improvement (or kaizen in Japanese) in our daily work. With customer feedback and analytical data, there are numerous amount of improvements that we can do to better serve our customers. Through automation, the process of kaizen can be sped up rapidly. Committing source code is a daily job for engineers, it’s not just about handing over our daily work but also testing the code in our server environment. We introduced Continuous Integration and Continuous Deployment (CI/CD) practice into the team to help us reduce repetitive work. CI/CD is a method to frequently deliver apps to customers by introducing automation into the stages of app development. ^1 We were following Git-flow to manage our source code and development progress. Soon after CI/CD was implemented we found that our work process did not get any faster. Reasoning git flow diagram It was a mess to use or manage the CI/CD scripts. We have so many different branches, when merging branches from one category to another different scripts are needed: feature-to-develop , develop-to-release , release-to-main , hotfix-to-main , main-to-develop , develop-to-feature , etc… Conflicts would show up everywhere! And they cannot be solved via automation scripts. The automation increased our daily workload, why?! After some research we found that: Git-flow, by definition, is a manual/time delayed integration workflow. OK, we need a new workflow then. Reattempt Among several workflows we found during previous research, we decided to give GitHub-flow a try as we store our source code on GitHub. github flow diagram This time we only have two type of branches: the main and the 'change-of-anything' , and we block any commits to main directly, the only way to update main is to do a Pull Request towards main . As a result, there is only one CI/CD script required and any conflicts can be discovered and resolved during Pull Request . New Issue We have simplified our branching strategy; we have only one script to do CI/CD; we have Pull Request to help managing conflicts. All happy? Yes, but no. Let’s check the pros. We have handed over the repetitive work to automation scripts, so everyone can do more productive work. The release and deploy process is handled by scripts, so any change we made locally can be deployed to server within 2 minutes. However, there are the cons. We lost feature/version control of our system. As features are no longer stored in individual branches but in main directly after Pull Request , we cannot decide for next version which features may be on-hold and which may be released. Also, the main branch just kept updating with latest source codes, version number can ramp up hundreds in a single day. Next Step Fortunately we are not alone. There are people who already faced these issues, and we can follow their journey and see their solutions. Feature toggle can be used to enable/disable any feature at any time. It can be stored in parameters, so no new release/deploy needed; even better than Git-flow which is to release different versions with different combinations of features. Version number only ramps once we deploy a specific commit to the production environment. For the rest of the environments, we use the commit hash as the version number. This helps us to locate any bug or defect to that commit instantly. Summary Undoubtedly there is no perfect solution to solve all problems. GitHub flow has its flaws as well, my team and I are still working together to kaizen not just our products but also the way we work. Personally, Git-flow is like a web portal: it categorizes everything with defined rules; if no one makes any mistake it will work just fine. On the other hand, GitHub-flow is like a search engine: we tag the version number to the commit we release/deploy to the production environment, with other environments having the commit hash as version numbers; so if there is any issue, those versions can be easily found through search. References トヨタ生産方式 What is CI/CD? What is Continuous Integration? Git flow for agile teams is a no no Please stop recommending Git Flow! Git Flow vs GitHub Flow GitHub flow - GitHub Docs Continuous Integration Contradicts Features Branches! How to Achieve Continuous Deployment with Feature Flags

概要 グローバル開発G業務エンハンスチームの森、榊原、Floです。グローバル開発G主催のKINTO Global Innovation Daysの連載記事２本目となります。 前回の記事はこちら 👈 本記事では、12/14~12/19の4日間で行ったプレイベント3本と、Innovation Days当日の様子をお届けします。一連のスケジュールは以下の日程で行いました。 Design Dash Workshop 組織が拡大するにつれ、メンバーのタスクが細分化されるため、同じチーム内であっても役割が異なるとどういった考えでタスクをこなしているのか見えにくくなってきます。この課題を踏まえ、ターゲットの抱える課題を解決するためのソリューションを検討するワークショップを行いました。 あるお題に基づいてインタビューを行い、インタビュイーの悩みを解決するプロダクトを企画、提案、デモする形式です。 このワークショップの目的は以下の４つ： Ideation Rapid Desision Making Discovery Practice Improve Communication 学びを参加者自身に感じてもらいたかったので、あえて目的を言わなかったのですが、後日行ったアンケートでは72%の参加者に満足いただき、「課題発見力を得られた」「限られた時間内でどのようにソリューションを見つけ出すかを知った」「ユーザーセントリックな商品設計の仕方を学べた」「チームワークがとても重要だと理解した」などの声をいただき、自然と目的を達成することができました。 Communication Workshop 各自のタスクが細分化されてくると、プレゼンやアウトプットの機会も減ってきます。参加者の中にも普段はほとんどそういった機会が無いメンバーもいました。「機会」を与えることは本イベントの最終ピッチで実現できましたが、その事前準備として「相手が求めているものを把握する力」が必要だと考えました。相手の立場によって求めているものは異なり、それを把握できないと的外れなアウトプットをしかねないからです。事前準備として、ステークホルダーの立場と状況をしっかりと把握し、何を求めているのか、相手は今何を欲しているのかを把握できるようなコミュニケーションのワークショップを設けました。 コピーライター、デザイナー、開発者、ダイレクター、セールスという別のロールに分かれ、プロジェクトの各自の悩みを踏まえて共有し、それぞれのTO DOに落とし込んでいくというような形式でした。 こちらも56%の満足度を得られ、「必要な情報を相互へシェアする重要さ」「それぞれ違うところにフォーカスがある人たちの意見を集約し、どのようにDeliverableとして出すか学んだ」「異なるロールの視点を見ることができた」のような声をいただきました。 Toyota Way Workshop Innovation DaysをKINTOテクノロジーズで行うベネフィットとして、トヨタグループならではの学びを得たいという理由から、アジャイルの由来でもあるトヨタ生産方式を学べる機会を設けました。 具体的な方法については割愛しますが、トヨタウェイやトヨタ生産方式についてトヨタ自動車史や創業者の精神に沿って学べるセッションを設けました。ただ一方的なインプットではもったいないので、各自感じたことをチームで共有しあい、翌日からのInnovation Daysで大切にしたいマインドを宣誓していただきました。 これも72%と非常に高い満足度を得ることができ、「トヨタウェイが言葉としてだけでなく歴史を通じて理解できた」という声がありました。 Innovation Days 前日までのワークショップで学んだことを踏まえ、いよいよInnovation Daysの当日です。 当日のスケジュール🔻🔻 Opening Ceremony 事前収録した社長からのメッセージや細かいルール説明、アイスブレークを行いました。 Code of Conduct ルールはいろいろな事例を参考にしながら以下を規定。Code of conductを遵守することを強調しました ✨ 発表コンテンツ プレゼン時間の規定（pitch 5分 + Q&A 2分） 開発に使用して良いツール Deliverables提出方法 評価方法・ポイント 運営チームからのアドバイス  Icebreaker IcebreakにはTelestration = お絵描き伝言ゲームを使いました。けっこう難しかった様子。 Ideathon もともと検討いただいていたアイデアの種を育ててもらうところから始めました。自分たちのアイデアに対してValue Proposition Canvasを用いてターゲットと課題、そこに対するソリューションが提供する価値を検討してもらいました。 普段、グローバル開発Gではこういった検討はPdMが担当していますが、エンジニアも含めてチームで検討できる、滅多にない機会となりました。 Hack Start!!! さて、実際の開発スタートです。各チーム、オフィス内の部屋にわかれてそれぞれの開発をスタートしていただきました。様々なメンバーがいるのでコードを書くだけでなく、翌日のPitchに向けた準備や、デザインなどを担当するメンバーもいます。 2日間の内、実際の開発時間は7.5時間程度でした。限られた時間の中で、どこに優先度を置いてどこまで開発し、また、Final Pitchではどのようなポイントを訴えるかを検討してもらいました。 2日間のInnovation Daysではランチセッションもありました。Day#1はチームでランチに行ってもらうことで、アイデアを深めました。Day#2はチームの1人が別のチームに交じってランチをすることでアイデアや開発内容に対するフィードバックをしてもらいました。交流の目的もありますが、雑談の中で生まれるアイデアはInnovation Daysのみではなく、実業務に対しても良いものが生まれたようです。 Final Pitch!!! Day#2の夕方、全員で集まってPitchをしてもらいました。持ち時間は各チーム5分＋QA2分です。 それぞれ詳しいアイデアは割愛しますが、既存プロダクトの改善提案や新しい機能の提案、新サービスの提案など、各チームユニークなPitchとDemoを行ってくれました。 尚、公平を期すために発表順はその場でくじ引きにしました。自分の番がいつ来るかわからないのでドキドキです！ Judgement 全てのPitchが終了してから、グループマネージャーとアシスタントマネージャー4名による評価の時間です。うち2名はリモート参加だったので、4人で集中してJudgeされていた姿が印象的でした。 Judgementの評価軸は以下 🔻🔻 評価軸 / Evaluation axis 割合 / Ratio オリジナリティ / Originality 10% UIUX 10% 技術力 / Tech Skill 30% チームワーク / Team Work 20% 実用性、事業性 / Practicality, Feasibility 20% ワクワク感 10% 評価の結果、優勝したチームにはオリジナルスマホスタンドとケーキの賞品を贈呈しました。優勝したチーム以外も楽しそうに参加いただいたのが印象的で、会場内はとてもいい雰囲気でした。 ※撮影のタイミングだけマスクを外しました。 まとめ KINTOテクノロジーズ初のイベントとしてグローバル開発Gが企画したイベントでしたが、もともと目的としていた「コミュニケーション活性化」はもちろん、KINTOに対する新しいアイデアや普段の業務では使うことのできなかった新しい技術の利用など、様々な結果を出すことができました。 参加者はもちろん、マネージャーや役員など、全てのステークホルダーにとって好評なイベントとなりました。我々は運営側でしたが、ハプニングへの対応、ファシリテーション、タイムマネジメントや多方面の調整力など、運営チームとしても様々なスキルを得られました。そして何より、チーム内の絆が深まりました ✨ さて、ここまで運営チーム目線で企画段階の様子と当日の様子を記事にしてきましたが、参加者目線ということで優勝チームのインタビュー記事を掲載予定です。乞うご期待！

概要 グローバル開発G業務エンハンスチームの森、榊原、Floです。グローバル開発Gでは12/14 21の6日間にわたり、「KINTO Global Innovation Days」と称した社内Hackathonのようなイベントを開催しました。12/14 19までの4日間でセミナーを3本と、実際の開発は2日間の構成です。このようなイベントを開催するのはKINTOテクノロジーズ内でも初めてのことでした。本記事では本イベントに関する連載記事の１本目として開催に至るまでの様子をお伝えします。 きっかけ KINTOテクノロジーズは現在約300名で構成され、2年ほどでおよそ倍の人数になりました。その中で、グローバル開発Gも現在60名の大所帯です。組織としては5~10名程度のチームに細分化され、それぞれタスクをこなしていますが、チームを横断したコミュニケーションは常に課題でした。同じグローバル開発G内でも顔と名前が一致しないこともしばしば…。また、コミュニケーションとスキル向上のために内部で勉強会を企画・運営していたものの、どうしても一方的な知識共有になってしまっていました。 エンジニア自身が手を動かして学べる機会を模索していましたが、7月にグループ内の数名が Toyota Motor North America (TMNA) のHackathon に参加したこともあり、これを我々グループ内で開催することで、上記の課題解決に繋がるのでは？と考えて、8月末から計画をはじめ、提案に移すことにしました。 目的と開催時期 一般的にHackathonイベントから得られるベネフィットは様々ですが、今回我々は「コミュニケーション活性化」を第一目的としました。ビジネスに寄りすぎないことである程度自由な発想が得られたと思います。 また、開催時期については遅くとも2022年内開催を目標としました。グループ横断で携わっていた大きなプロジェクトが11月に目途が着きそうなこと、4Qまで差し掛かると先のタスクが読めないことが理由です。 調査とコンテンツ検討 初めてのイベント開催だったため、実際のイベントがどうあるべきか検討すべくまずは世界中のHackathon事例を調べました。調査担当は榊原です。 他社のテックブログやHackathonのイベントサイトを中心として様々なお手本を調べているうちに、パターンが見えてきました。そのパターンの要素をピックアップし、最も我々の組織や目的に則したポイントを組み合わせることによってInnovation Daysの内容を組み立てる事ができました。調査結果の例はたくさん取り上げることができるのですが、その中から3点解説します。 調査結果１：ベネフィット イベントの準備を進めるにつれて、参加者や関係者、ステークホルダーに対して、参加することによってどういった効果が見られるかを伝える必要性を感じました。例えば、組織へのベネフィットは知的財産権になるアイデアを得る機会であることや、メンバーのエンゲージメントを高め、新たな強みの発掘ができる機会であることを挙げられます。また、個人へのベネフィットは、普段の業務では取り組めないアイデアを考えたり、あまり関わることのない業務工程やメンバーと接することによって、いろんな面での学びとなることを訴えかけました。 調査結果2：コンテンツのアイデア 上記のベネフィットを踏まえ、コンテンツとして取り入れたのがセミナーです。Hackathonのようなイベントが開催される際には、ゲストを招いてトークを行ったり、Hackathonのテーマや目的に沿った講義やワークショップが開催されることがあることを知り、今回Innovation Daysでは普段経験しない上流工程のworkshop、コミュニケーションworkshop、そして「KINTOテクノロジーズが開催するHackathon」なので、トヨタウェイのworkshopを準備しました。 IT企業が開催するイベントといえばノベルティー！という方も少くはないかと思います。今回我々はステッカー、パーカーとクリアファイルを参加者とサポートメンバーへお渡ししました。他にも、最終ピッチや成果物の判定基準やルールの設定、コードに付与する時間、アイスブレイクやプライズ等も様々なイベントからアイデアを拝借しました。 ※イベントの名称が決まってからグローバルG内のUIUXチームにロゴも作成いただきました。おかげで素敵なノベルティーができました。Appreciate it a lot!!!! 調査結果3：テーマ設定 最後に取り上げたいポイントが「テーマの設定」です。多くのHackathonでは開催側からテーマや目的が絞って掲げてあり、各種テーマをスポンサーする存在もいる場合もあることからヒントをもらい、我々のイベントではマネージャーが「チャレンジテーマ」を1つ決め、各テーマのスポンサーとして「チャレンジオーナー」となって参加者にテーマの説明を実施しました。こういったテーマの設定によってマネージャーから参加者へのサポートも示すことができ、エールも送ることができました。 参考： Council Post: Four Tips For Running A Successful Hackathon Urban Mobility Hackathon Find & Organize Hackathons Worldwide - Mobile, Web & IoT Hackathon Guide テーマの検討 テーマの内容については、実際に当日評価をするマネージャー４名（グループマネージャー+アシスタントマネージャー３名）に４テーマを選定いただきました。 テーマ 1-2 テーマ 3-4 Encouraging members 社内で初めての試みということもあり、企画を始めてから調査、コンテンツ検討、テーマの選定を経てメンバー募集するまでに3ヶ月ほどかかりました。最終的にテーマが決定した11月頭にグローバル開発G全員を集めた企画説明を行い、11月8日にメンバー募集を実施しました。この際、公式イベント名を「KINTO Global Innovation Days」と題しました。 尚、参加者については全員強制で参加させる案もありましたが、自主性を尊重するために参加したい人に挙手する形式としました。実際に募集したSlack 🔻🔻 説明会でマネージャーからもエールの言葉をいただいたり、CEOやCIOのサポートもいただいている旨を伝えたりしましたが、当初はなかなか参加者が集まりませんでした。 そこで、ベネフィットなどをメンバーに直接訴えかけるようにしました。担当はFloです。オフィスで直接会話する際やDMなどでベネフィットを伝えることにしました。それによって、参加できないメンバーにその理由を聞いて改善できるからです。 まず、本イベントに参加することで、どのような体験ができてどのようなスキルが得られるか伝えました。普段使えないプログラミング言語を試せる、新しいツールを提案できる、優先度が低かった改善案を提案できる、など様々な体験が得られると訴えました。 また、イベント内での提案はグローバルGでのプロセス改善に活用されたり（テーマ 3）、新サービスとして製品化されたり（テーマ 1, 2）、もしくは他のHackathonイベントへの参加も検討され得るなど、当事者意識と投資意識にも訴えかけました。 中でも、我々が一番に心がけたのはサポート環境です。アイデアは評価されて表彰されますが、あくまで切磋琢磨するイベントなので、こういったイベントに参加したことがない、技術者ではないから貢献できない、自分は役に立たない、と思っている方にも、「普段体験しないことを経験できるイベントだからこそ参加してほしい」と説明しました。 会話の中で気づいたこともあります。開催日程がクリスマス前だったため、連休を予定したり母国へ帰省したりする方が複数名いました。そのため、イベントを数日前倒しすることにしました。各workshopの講師とスケジュールを調整し、最終的に12/14-19をプレイベント、12/20-21をInnovation Daysとしました。これによって参加できるメンバーが少なくとも2-3名増えました。 余談ですが、運営メンバーはたったの3名＋サポート1名だったため、土日を挟んだのは我々にとっては好都合でした。1週間ぶっ通しでのイベント開催だったら体力的に厳しかったと思います。 グルーピングと事前ワーク リクルートの甲斐もあって、実際の参加者は30名となりました。グループマネージャーやアシスタントマネージャー、我々運営メンバーは参加対象外なのでグローバル開発グループの半数以上が参加してくれました。 Business development, PdM, UIUX, Frontend, Backend, Testing, DevOpsなど様々なチームから参加者が集まったので、それぞれを①できるだけ普段業務上関わらない人②パワーバランスを取るためにチームリーダーは分けることを条件として配分しました。5名×6チームです。（30名というキリの良い人数だったのでちょうどいい感じのメンバー数に分けられました 😊 ） チームメンバーは11/18に発表、その後2週間で以下を検討・提出してもらいました。 Team name Theme of choice Team leader 普段、グループ内で最もいろんな人と関わる我々チームとしては、参加メンバーがうまくコミュニケーションを取れるか？積極的にイベントに参画してくれるか？など親心的に心配しておりましたが、その心配は無用でした。参加者は自主的に参加してくれていることもあり、それぞれのチームがSlackの独自チャネルを作ったり、ミーティングを開催したり、思った以上に積極的に動いてくれたので、今後のイベントにも期待が持てました！ 🎉 事前準備の振り返り 社内はもちろん、前職での経験も完全に何もないところからスタートした企画だったので、いろいろな調査や様々な方からのアドバイスを受けながら準備を進めてきました。特に承認プロセスは時間がかかりましたが、CIOや社長まで巻き込めたことは成果の一つであり、今後のイベントにも繋がる大きな要素だったかと思います。 また、アイデア出し(調査含む)、企画＋上位層への報告、状況把握とメンバーの鼓舞、と業務エンハンスチームメンバーそれぞれが得意なことを組み合わせてうまくタスクを分散できたことで、構想から約4ヵ月の短期間で実行に移せた要因です。 プレイベント期間や当日も様々な課題がありましたが、その様子は次回の記事に記載いたします。 最後に 余談ですが、KUDOSや本イベントなどの企画は業務エンハンスチーム内の日常会話から生まれています。我々チームは会話をとても大事にしていますが、「 この課題を解決するにはこういう手があるかも 」「 こういうのあったらいいよね 」「 前職ではこういうことしていた 」などのカジュアルな会話から企画・実行・結果に残すことまでできる力を持った業務エンハンスチームを誇りに思います。

はじめに みなさまはじめまして。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テクノロジーズにて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😊💗