はじめに KINTOテクノロジーズで、複数のサービスが利用する決済プラットフォームの開発チーム[^1]に所属している金谷です。 新規プロジェクトに対して、リモートでモブプログラミングを行い、オンスケジュールで開発完了させた事例を紹介します。 [^1]: 決済プラットフォームの他の取り組みは、 グローバル展開も視野に入れた決済プラットフォームにドメイン駆動設計(DDD)を取り入れた をご参照ください。 背景 社内向けの決済に関する業務システムを新規で作るプロジェクトが発足し、東京勤務のプロダクトオーナーと、東京勤務のエンジニアに、私含む大阪勤務の2名による3名のエンジニアの体制で開発することになりました。 素早く作りたいことと、運用コスト(特にAWSコスト)を減らしたいことから、フロントエンドには AWS Amplify をベースとしたReactによるSPAを採用し、いくつか必要なAPIの開発には AWSサーバレスアプリケーションモデル を採用しました。 課題 プロジェクト開始直後の時点で、私は既に不安がありました。 具体的には、私自身が今まで使ったことのないAWSのサービスを使うことです。 自分の不安も共有するべくそれぞれのメンバーに話を聞くと、どうやら集まった3人は、技術的にも得意な領域が異なることが分かりました。 具体的には、フロントエンド・バックエンド・インフラ(AWS)の3領域に分けた場合、開発チームの各メンバーは、2つの領域は得意だが1つは自信がないことが分かりました。 例えばKさんこと私の場合、フロントエンドとバックエンドは大丈夫な反面、AWSに自信がない、といった具合です。奇跡的にも、各技術領域について2人は詳しい事が分かりましたので、誰かに頼り切りになる局面がなさそうだという点で安心しました。 メンバー フロントエンド バックエンド インフラ(AWS) Kさん ◎ ◎ △ Tさん ◎ △ ◎ Nさん △ ◎ ◎ スキルの領域と開発メンバーの得意領域の星取表 また会話する上で分かった一番の不安は、チームで開発していく上での共通認識がないことでした。 例えばフロントエンドだけでも、コンポーネントの粒度はどうするのか？状態管理はどの粒度で行うべきか？Promiseベースかasync/awaitで行くか？テストをどこまで書くべきか？などなど、コードが1行もない状況ですので、すべてを決めていく必要があります。一方で、入社後1年未満のメンバーで構成されたことから一緒に仕事をするのが初めてのメンバーなので、あのプロジェクトのように〜といった共通認識がありません。共通認識の構築はいち早く行う必要がありました。 改めて課題を整理しますと、プロジェクトを成功させるために、以下の2つが大きな課題であると考えました。 共通認識が揃っていない状況でスタートするため、共通認識を早めに構築したい (認識齟齬を減らし良い品質のプロダクトを作りたい) 各々の得意な領域を共有・補完することで、技術力を底上げしたい 上記2つの課題を解消するために、今回のプロジェクトでは、開発のスタイルとしてモブプログラミングを採用することにしました。 モブプログラミングとは モブプログラミング(以下モブプロとします)とは、 モブプログラミング・ベストプラクティス という本では「3人以上の人々が1台のコンピューターの前に座って協力しながら問題を解決していくこと」とされています。 ひとつのPC(画面)で皆が参加するのですが、実際には2つのロールがあります。 3人以上で行うため、モブが2人以上いる状態で、議論しながら方針を決め、タイピストが方針に従いコードに落とし込みます。 タイピスト (PCを操作しコードを書く) モブ (開発の方針を議論して指示する) ひとつの仕事に3人以上が関わるモブプロを理解する上で、リソース効率とフロー効率という考え方が重要になります。詳細は フロー効率性とリソース効率性について #xpjug - SlideShare に譲りますが、モブプロはフロー効率に全振りする仕事の仕方です。 フロー効率最大化が目指したいことではないのですが、モブプロをする以上、フロー効率に軸足を置いた仕事の仕方になります。 試行錯誤した内容・工夫したこと チームメンバーは地理的に離れている関係上、リモートでの開発を余儀なくされます。そのためZoomを使ったリモートモブプロが基本になります。 プロジェクトを成功させるために、課題の解消が必要だと考えていたため、以下の工夫をしながらモブプロを取り入れていきました。 情報量を増やす 情報量を増やすために、画面はタイピストのデスクトップ全体を共有しながら作業しました。共有ウィンドウだけでは、ウィンドウ外で何が起きているか分かりません。OSやツールの使い方も共有したいため、デスクトップ全体を共有しました。 次にタイピストは、考えていることをなるべく声に出しながら作業するようにしました。特に実際にアウトプットの作業を出来るのはタイピストだけなので、ズレがないかを確認する意図もあります。 気がつけば、タイピストも議論に加わることも多くなりました。 本来のモブプロのタイピストとは異なるのですが、共通認識を作ることが大事であると考えていたため、議論参加をヨシ！としていました。 時間を管理する 3人以上が自然に集まってモブプロすることは難しいと考えたため、カレンダーで各員の予定を押さえて、モブプロの時間を確保するようにしました。 モブプロの時間を事前に設定しておくことで、1日の開発にリズムが生まれやすくなります。 また、 ZoomのTimerアプリ を入れて、制限時間を設けるようにしました。モブプロは集中した作業のため、時間を区切らず続けてしまうことで疲労しやすくなります。適度な交代と適度な休憩を入れたいため、タイマーで時間管理するようにしました。書籍や他社事例 [^2] を見ると10分交代と非常に短い時間で交代するようですが、次のタスク単位で分ける関係もあり、30分にしました。 [^2]: https://techblog.yahoo.co.jp/entry/2020052730002064/ フィーチャーチケットを更に細分化してTODO コメントとして残す モブプロ対象のフィーチャーについて、作業を事前に細分化して、修正対象の中心となるソースコードに TODO コメントとして残すようにしました。 TODOコメントを残すには2つのメリットがあります。一つは、フィーチャーのゴールの解像度が上がること。もう一つは、区切りのいいタイミングで交代しやすくなることです。 例えば決済処理を行うユーザー情報の更新APIを新しく作る際に、以下のようなTODOコメントを、コードを書く前に書いていました。この時点で作業内容も作業順番もクリアになるため、段取り良く進める事ができますし、交代や休憩もスムーズでした。 # TODO openapiにユーザー情報更新の定義を追加 # TODO infrastructure - ユーザー情報更新のインターフェース作成 # TODO infrastructure - ユーザー情報更新の処理実装 # TODO application - バリデーション処理実装 # TODO application - ユーザー情報更新の処理実装 # TODO sam template に lambda 定義を追加 # TODO デプロイ、動作確認 def lambda_handler(event, context): pass モブプロする・しないの基準を相対的に設定する すべてをモブプロで開発するのか？という疑問は早い段階で上がりましたが、実際にモブプロを進める上で、難しそう・議論が必要そうなフィーチャーを優先的にモブで実施することにしました。 あくまでスプリント内のフィーチャーのうち、相対的に難しそうなフィーチャーという選び方ではありますが、難しそうなフィーチャーに対する認識も揃ったため、皆に納得感がありました。 また簡単なフィーチャーは、モブプロ以外の時間で各自対応するようにしてバランスを取っていました。 難しそうなフィーチャーはモブプロで片付いているため、モブプロ終了後に簡単なフィーチャーのプルリクエストがガンガン飛んできました。 モブ「プログラミング」以外のこともモブプロで行う モブプログラミングなので「プログラミング」だけを対象にしていたかというとそうではなく、プログラミング以外の作業もモブプロ時間にやっていました。例として2つ挙げます。 コードレビュー コードレビューもモブプロでやっていることがありました。すべてをモブプロでやっていたわけではありませんので、どうしても開発過程を見ていないコードが出てきます。 モブプロの時間の最初に、モブプロ以外で作ったコードを説明する場を設けて、皆が聞いて質問するようにしました。この時間があったおかげで、詰まりがちなレビュー工程も素早くパスできました。 運用に関わる作業 運用に関する作業もモブプロの時間を使って行いました。具体的には、初めてCognitoのユーザープールを作るときや、GitHub Actionsに関する設定を追加するときには、モブプロの時間を使って皆で見ながら作業しました。これにより、運用面のイメージも付くようになりました。 プロダクトオーナーとのコミュニケーションをメンバー全員で出るようにする 開発チーム内の共通認識はできるようになったのですが、プロダクトオーナーも入れた会話がないとずれる恐れがありますし、実際にずれたことがありました。最初の頃は、プロダクトオーナーと私ではよく会話していたのですが、特に議事録も残さず意思決定も曖昧なまま進めていたため、認識のずれが発生していました。 対策として、プロダクトオーナーとのコミュニケーションは全員で参加するようにし、合わせて議事録もリアルタイムで残すようにしました。 以降は認識のずれも減ってきて、手戻りも少なく開発を進められるようになりました。 合わせて、お互い出張する機会を作り、重要な意思決定やオフラインでモブプロする機会を増やしました。 オフラインでモブプロする図 スプリントゼロを設ける (モブプロとは直接関係ない) スプリントゼロを設けさせてほしいとプロダクトオーナーにお願いして、1週間のスプリントゼロ期間を作りました。 スプリントゼロでは、スプリント1でいきなり多くのアウトプットを出せるようにするための準備を行ったのですが、特に私がこだわりをもって行った作業は、以下の2点です。 create-react-app が最低限動くリポジトリを作る create-react-appをデプロイできるようにデプロイ先やGitHub Actionsを整備する つまり、開発環境でワンクリックで動作確認出来る状況を一番はじめに作りました。 継続的デプロイができることで、より良いフィードバックを素早く得ることができます。 継続的デプロイの仕組みを早い段階で作ったことで、いつでも誰でも開発環境に最新のコードをデプロイできるようになりました。それどころかスプリント0のスコープを飛び越えてスプリント1のフィーチャーを終わらせる人も出てきて嬉しい悲鳴でした。 モブプロとは直接の関係はありませんが、新規開発の際にスプリントゼロを設けるのはオススメです。 他にも準備することが盛りだくさんのスプリントゼロの詳細については 【資料公開】スクラムプロジェクト開始のベストプラクティス | Ryuzee.com をご参照ください。 結果の分析と次へのトライ 結果 プロダクトオーナーが求める品質を満たしつつ、オンスケジュールで開発を完了することができました。 その際、「これほどの高品質でスケジュール通り終わったプロジェクトは経験したことがなかった」とご評価いただきました。 また、利用者である業務部門のご担当者にも実際に画面を触っていただいてフィードバックを反映し、最終的に「とても使いやすい」とご評価いただきました。 我々開発メンバーも、苦手意識のある領域も自走できるようになりましたし、自分の強みを更に発揮する方向に進んでいます。 次に活かすための分析 プロジェクトとしては非常に良い成果を出すことができたと思いますが、再現性の高そうな理由を考えると、以下になると考えています。 共通認識を早い段階で揃えることにより、品質を高めて後戻りを減らすことができた スプリントゼロで開発の基盤を作ったことで、作業効率が最初から高くなっていた モブプロを通すことでコミュニケーションが多く発生し、早い段階で関係性構築ができた 総じて早期にコミュニケーションや開発基盤の構築など、よい準備ができたことが良かったのでしょう。 フロー効率に全振りするモブプロを積極的に行うことでスケジュールに遅れが出るのでは？と予想していましたが、そうなりませんでした。その理由として、難しい部分をモブプロで対応する一方で簡単な部分は各メンバーが対応したためではないか？と考えています。開発を進める上でのボトルネックとなる部分に集中できたことが良かったのでしょう。 次へのトライ まずは自分たちだけで言いますと、自分たちだけでは解決できないときに、その問題を解決できる人と一緒にモブプロできるといいなと考えています。技術習得面でも、横のつながりの面でも、良い効果が得られそうだと考えています。 また、もう少し規模の大きいプロジェクトでもモブプロをやってみたいです。フロー効率全振りでは難しいという状況になるとは思いますが、まずは早い段階で共通認識を作ることがどのくらい良いのか？試してみたいです。 まとめ フロー効率を最大化するモブプロですが、揃っていない共通認識を揃えるためにも非常に有用でした。難しい実装に集中してモブプロを行うように使い所を明確にすることで、プロジェクトの遅れを出さずに開発することができました。 KINTOテクノロジーズは、東京と大阪に開発拠点があります。どのような人たちが働いているのか？募集職種はどのようなものがあるのか？気になる方は、 募集職種一覧 をご覧ください。お待ちしております！

はじめに はじめまして、KINTOテクノロジーズで分析グループのマネージャをしています西口です。Tech企業の中に分析グループということで不思議に思われる方もいらっしゃることでしょう。今回はそのあたりのお話をさせてもらいたいと思っています。 分析グループの役割 KINTOテクノロジーズの事業内容は、「デジタル分野における情報システムの設計、開発、運用管理および販売等の情報処理サービス」「企業経営戦略、マーケティング戦略の企画、立案およびコンサルティングに関する業務」となっています。私たち分析グループは後半部分を担っており、日本のKINTO事業はもちろんですがトヨタファイナンシャルサービス株式会社のグループ会社が運営する各種サービスでのデータ利活用にも協業で参画し、データを使ってビジネスに価値をもたらすということを目指しています。 データに価値をもたらすために（分析グループの守備範囲） DIKWピラミッドをご存じでしょうか。膨大な情報の活用プロセスをData, Infomation, Knowledge, Wisdomの4つの頭文字から名づけられたものとなります。私たちは膨大な量の情報をいかに新たな知識体系に変換していきながらビジネスで価値をもたらすことができるかということにこだわっています。 そのDIKWピラミッドを実現するために、下記に述べる大きく4つのパートに分けて業務に携わっています。 1. データ取得設計・実装 通常、ビジネスデータはユーザーのご注文フローなどでのアクションから「発生する」トランザクションデータと商品管理等のマスタデータというものがあります。私たちはトランザクションもマスタもともに「発生させる」というところも意識しています。近年、個人情報保護の観点もあり、データは取りにくくなってきています。あるタイミング（例えば、ユーザー登録時など）でしか取れないデータというものもあり、そこで取り漏れるとその後取ることができなくなるものも少なくありません。私たちはWEBサイトへ適切に分析タグを設置していくことはもちろんのこと、ユーザーアクションによりデータを発生させる仕掛けや仕組みの企画までも取り組んでいます。 2. データ蓄積 そして発生した/させたデータを迅速に適切な形でデータレイク・データウェアハウスに格納して、次の工程（データ分析）に進めるようにしなければなりません。ここでのこだわりは分析者への負担の軽減です。分析者の「データの取得・加工」にかける工数を必要最小限にして、より分析に注力できるようしたいと思っています。簡単に取得したいデータが取得できないと分析者の思考の進化・深化の障害になりかねません。たとえば、「Aサービスの会員とBサービスの会員を結合したい」といった場合に容易に突合ができるような仕組み作りが重要になってきます。よくメンバーには「受け手のことを考えてパスを出せるように」ということを言っています。 3. データ分析 分析とはある切り口で分けて、それらを比較すること。そこから差を見出すことだと考えています。そして、その差を広げることあるいは縮めることを促進させるのが「施策」だと考えています。私たちはその差を適切な切り口で見つけ出し、ビジネスメンバーに知らせること、さらには施策を提案するところまでが役割です。 これらに必要なスキルとして、メンバーには２つのことを伝えています。ひとつは、「多角的な視点を持つこと」。具体的には、“虫の目、鳥の目、魚の目、蝙蝠の目”でものごとを見ていける力を養ってもらっています。もう一つは「なぜなぜ分析」です。ものごとの本質に行きつくためには何度もなぜを繰り返しながら、正しい因果関係のなかで根本要因を見つけ出すという姿勢が必要です。 4. AI/機械学習 高度なデータ分析の位置づけとしてAI/機械学習を位置づけています。過去のデータから未来を予測することはこの領域です。この分野では、トヨタ自動車未来創生センターともコラボレーションしアカデミックな情報も得ながら、高度なアルゴリズムを使ったモデルの作成も行っています。またビジネス分野におけるAI/機械学習はモデルの見直しは常に行われます。そういったモデルの改修～実装をしやすくなるようなMLOpsの環境構築も必要不可欠で、このあたりも当社プラットフォームグループと協力しながら作り上げていっています。 データに価値をもらたすために（担当・役割） 繰り返しになりますが、特にBtoCビジネスにおいて、データに価値をもたらすためには、適切なタイミングでデータを取るということが非常に重要です。その時しか取れないデータというのがあるからです。そして次の工程で使う人が使いやすいようにデータを貯めるということが次に重要な点です。それらを成し遂げるために、分析グループには次のような肩書のメンバーがそろっています。 1. データアナリスト KINTOテクノロジーズのデータアナリストは単なるアナリストではありません。WEBサイトやアプリの適切な箇所で適切なタイミングで、また適切な形でデータを取るためのデータ取得設計から関わり始め、タグの設置も担っているからです。データ分析で必要になりそうなデータを事前に想定して漏れなく取っておくという動きは、実際に分析するデータアナリストこそがすべきタスクだと考えているからです。そして発生したデータはデータレイク・データウェアハウスに蓄積されています。そこからBIツールやSQLを使って自由自在にデータを抽出し、適切な切り口でドリルダウンしながら事象の根本要因を見つけ出すことで、予兆の発見や施策の提案などを行っていきます。 2. データエンジニア データエンジニアにも高いスキルを求めています。事業会社ならではだと思いますが、バックエンドのデータベースからそのまま情報系のデータウェアハウスにデータを格納するだけではなく、データ分析に関わるメンバーが使いやすくなるように配慮してデータを作っていくようにしています。KINTOではどんどん新しいサービスが立ち上がっており、サービス立ち上がりと同時にデータ分析が始められるように、効率な開発のための、開発ガイドライン策定、共通関数化、CI/CDの仕組みなどの構築も担っています。 3. BIエンジニア ビジネスメンバーにデータを情報に変換して迅速にビジネスの状況を知らせていくことは非常に重要です。またマネジメント層と現場サイドでも見たい情報の粒度は異なります。それらを適切な形で伝えていくためのダッシュボード開発・改修・メンテナンスがBIエンジニアの役割です。 4. データサイエンティスト KINTOではさまざまなサービスがこれからも展開されていきますが、そこでもAI/機械学習関連はどんどん出てきそうです。数値データはもちろん、画像関連なども幅広い対応が求められます。ビジネス現場ではいくら精度の高いモデルを作ってもそれが使われるとは限りません。マーケターなどに説明して納得してもらう必要性があります。そのためには旧来の統計手法なども適切に使いながら説明を行う必要があり、ビジネスの理解や消費者への興味・関心というところもKINTOテクノロジーズのデータサイエンティストには必須のスキルとなります。言うなれば、KINTOビジネスにおけるデータサイエンティストは、マーケティング・データサイエンティストという役割になってきます。 5. 分析プロデューサー 2022年9月に新しく設けたポジションです。上記1～4のそれぞれの役割を横串でコーディネートするのが分析プロデューサーの役割です。ビジネスサイドでの課題を聞き出してそれを適切な分析問題に置き換えるビジネス力が必要とされます。もちろん1～4のデータに関わる業務の経験・知識も必要とされ高度な能力が要求されます。KINTOテクノロジーズ分析グループが今後さらなるプレゼンスを発揮していくためにも非常に重要な役割です。 分析グループのメンバー・雰囲気・業務の進め方 1. メンバー・雰囲気 非常に難易度の高い業務に日々取り組んでいる私たち分析グループですが、メンバーの経験はそれぞれいろいろです。ただ共通しているのは、データアナリスト、データエンジニア、データサイエンティストなどの柱を持ちながら、さらにデータに関わる領域で幅を広げたいという志向性・モチベーションを持った好奇心旺盛なメンバーばかりです。新メンバーがジョインしたときにはいつもメンバー全員で自己紹介をする時間を設けているのですが、各自の趣味やマイブームは大変ユニークなものとなっています。 2. 業務の進め方 分析グループは、メンバーが東京・名古屋・大阪と３拠点に分かれています。データアナリスト、データエンジニア、BIエンジニア、データサイエンティスト、分析プロデューサー、それぞれのチームがあり、各リーダーのもとで、オンライン・オフラインをうまく使って気軽に相談しながら業務を進めています。 今後、挑戦したいこと 今、私たちの関わっているKINTOおよびその他のサービスについても、サービスを跨いでご利用いただいているユーザーを繋げて分析するということに挑戦したいと思っています。そのためには、分析グループの担う機能・役割が有機的に結びつかないと実現しません。難易度は高いですが、これを実現することでユーザーをより深く捉えていきたいと考えています。 モビリティプラットフォーマーのトップランナーを目指すKINTOにおいては、GPSなどの移動データからWHEREが、お金のデータから、HOW MUCHを捉えることができます。これらのログにWHOとWHENが記されることで、ユーザーの嗜好性やライフスタイルの分析を深めていきたいと考えています。そして、行動の先読みをできるような仕掛け・仕組みの構築、さらには予測モデルなども作っていくというのがこれからの挑戦です。 おわりに 分析グループは、今後もKINTOの新しいサービス発展への貢献、トヨタファイナンシャルサービス株式会社グループへの支援を通してさらなるプレゼンスを発揮していけるように、アンテナを張りながら情報をキャッチし、日々精進していきたいと思っています。

はじめに KINTOテクノロジーズでKINTO ONE新車サブスクリプションシステムのフロント開発を担当しているカンと申します。 現在担当している、プロジェクトから簡単にご紹介させていただきます。 KINTO ONE新車サブスクリプションシステムは新アーキテクチャの適用を順次取り込んでいます。 フロントチームはNext.jsとTypeScript、デザインパータンとしてAtomic Designを採用して開発を進めていています。 本記事では実際にプロジェクトで使っている「Atomic Design」についてご紹介させていただきます。 Atomic Designとは？ Atomic Designの定義 Brad Frost氏によって作成されたUI設計方法論で、パーツ単位でUIデザインを設計する手法のことです。 最小のコンポーネント単位を原子(Atom)に設定してそれを基に上位コンポーネントを作ってコードの再利用を最大化することができます。 最近のJavaScriptを用いた、Webフロント開発はフレームワーク・ライブラリとして主にVueやReactを使用して開発を行う事例が増えてきています。 Vue、Reactはコンポーネント単位で開発を進めることが特徴であるため、コンポーネント中心の設計パターンであるAtomic Designがさらに注目されています。 Atomic Designのメリット Atomic Designでは、段階別にコンポーネントを分けることでコンポーネントのリサイクル性を高める仕組みを設計することができます。 コンポーネントのリサイクル性を高めることができる。 アプリケーションと分離してコンポーネントを開発・テストできる。 (別のライブラリであるStorybook、Jest等を利用するとコンポーネント単位で確認やテストが可能です) 特定のコンポーネントにCSSが強く結合されているため、CSSを管理しやすい。 既存のコンポーネントを再利用しているため、デザインを一貫して統一できる。 Atomic Designのデメリット コンポーネントのリサイクル性を高める設計が必要になるため、事前のページ要素の確認が必要になり、構成コンポーネントが増えることによる複雑性が高くなる可能性があります。 リサイクル性の高いコンポーネント設計がないと簡単に進められない。 コンポーネントの修正が頻繁に発生すると、複雑になり、メンテナンスが困難になる可能性がある。 試行錯誤した内容・工夫したこと フロントエンド開発のコンポーネント構造 PresentationalコンポーネントとContainerコンポーネントを分ける Presentationalコンポーネントは画面の見た目を構成する役割を、ContainerコンポーネントはAPIのコールやフロント側のロジックを実行する役割を担っています。 const MypageContainer: React.FC<Props> = ({ setErrorRequest }) => { const { statusForCancellation, cancellationOfferDate, callGetCancellationStatus } = useCancellationStatus(); const { authorizationInfo, memberType } = useAuth(); useEffect(() => { ... }, []); useEffect(() => { ... }, [currentItem]); const initSet = async () => { try { //　APIコールやレンダーする際に必要なデータの設定 ... } finally { ... } }; const onChangeCurrentItem = (currentSlideNumber: number) => { // イベントロジック処理 ... }; /** * 渡されたPropsや設定されたstateとflagなどでレンダー判定を行う * 判定に従うcomponentをレンダーする。 * 各コンポーネントはPresentationalコンポーネントに組み立てている */ return isLoading ? ( <Loading /> ) : ( <div className="p-mypage"> <div className="l-container"> <div className="l-content--center"> <MypageEstimateInfo data={estimateInfo} getEstimateInfo={getEstimateInfo} setErrorRequest={setErrorRequest} /> </div> <div className="l-content--center"> <MypageContactContent data={entryInfo} memberType={memberType} /> </div> <ErrorModal isOpen={errorDialogRequest.isOpen} errorDialogRequest={errorDialogRequest.error} onClose={() => setErrorDialogRequest({ ...errorDialogRequest, isOpen: false })} /> </div> </div> ); }; export default MypageContainer; const MypageContactContent: React.FC<Props> = ({ data, isContactForm = true, memberType }) => { return ( <> <div className="o-contactContent"> <ContentsHeadLine label="お問い合わせ" /> // --> atom {isContactForm && <ContactAddressWithFormLink />} // --> molecules <TypographyH4>電話でのお問い合わせ</TypographyH4> // --> atom <ContactAddressWithForAccident // --> molecules tel={CONTACT_ADDRESS_TEL.member} isShowForAccident={memberType === MEMBER_TYPE.MEMBER} /> </div> </> ); }; export { MypageContactContent }; 上記の container コンポーネントで API から取得した値やロジック処理後に設定した値に基づいて、コンポーネントの構成を判定していることが確認できます。 そして、レンダーされるコンポーネントは container から Props として渡された値を通じて presentational コンポーネントを組み立てて画面を表示するようになります。 コンポーネントグループの構成(Atoms, Molecules, Organisms, Template, Pages) Atom これ以上分解できないデフォルトのコンポーネントです。Atomを結合してMolecule、Organism単位で有用に使用できます。 Molecules 複数のAtomを結合して、独自の特性を持ちます。Moleculeの重要な点は一つ仕事をすることですね。 Organisms 前のステップよりも複雑で、サービスで表現できる明確な領域と特定のコンテキストを持ちます。Atom、Moleculeに比べてより具体的に表現されるかつ、コンテキストを持つため相対的に再使用性が低くなる特性を持っています。 Template ページを作成できるように、複数のOrganism、Moleculeで構成できます。実際のコンポーネントをレイアウトに配置し、構造化するワイヤフレームです。 Pages ユーザーが見ることができる実際のコンテンツを盛り込んでいます。Templateのインスタンスと言えます。 Storybookとのシナジー効果がある StorybookはオープンソースのUIテスターツールです。 Storybookを使えば、UIコンポーネントを作成しながらすぐに描画内容を確認できます。 Storybookライブラリと連携でUI管理がもっとしやすくなります。(UIテストが簡単にできます。) まとめ Atomic Designをプロジェクトに適用しながら、感じたことについてまとめてみました。 実際に適用するにあたって曖昧な部分があり、コンポーネントのグルーピングの範囲や分類をプロジェクトに合わせて変形させました。(Organismの範囲外に想定されているコンポーネントはFeaturesという単位で管理するとか) 最初から明確な設計がされていないと途中でコンポーネントを再設計・再作成したり、再分類するケースも発生するので注意を払う必要がありました。(階層構造にもっと多くの段階を置くとか) デザインチームと開発チームの連携やコミュニケーションがすごく重要だと思いました。(デザインから Atom、Molecule、Orgaism に細分化されて設計されなければならないため) 各コンポーネントグルーピングの基準についての認識合わせが必要があります。 設計はデザイナーが担当して開発は開発者がするため、コンポーネント単位の体系化された設計になるためには開発者とデザイナーが一緒に会議で認識を合わせる必要があります。 Atomic Designはメリットとデメリットが確実に存在するため、適用する前にチーム全体として明確に理解して設計すれば協業しやすくメンテナンスが容易なフロント開発環境を構築できると思います。 お読みいただきありがとうございます。 参考 atomic-web-design Brad Frost design systems are for user interfaces

モバイル開発グループ勉強会（黄） KINTOテクノロジーズのモバイル開発グループでAndroidアプリ開発をしている黄です。 本記事ではKINTOテクノロジーズのモバイル開発グループ勉強会についてご紹介します。 チーム文化誕生の源泉 本格的にソフトウェア開発文化について話をすると、一つ目は「共有の文化」だと思います。 複数の人と情報を共有することによる長所は様々でありますが、 一番は様々な視点を持つ人々の知識と意見が反映され、プロジェクトリスクが減少するのはもちろん、未知の情報まで得ることができます。 勉強会、必要ですか？ 会社でコーディングするのも忙しいのに、技術共有の勉強会は必要ですか？このように考えがちですが、ソフトウェア業界は バブルドットコム時代を過ぎて過去20年間、ソフトウェア業界は非常に急速に高度化し、規模が拡大し、開発技術も急速に変化し複雑になりました。 それに応じて、ソフトウェア開発のスキルが増すにつれて、習得すべき知識の範囲が広がり、効率的な意思決定とコミュニケーションのために情報とスキルを共有する開発文化が非常に重要になっています。 解決したい課題 入社してからずっと一つのプロジェクトに集中しているため他分野の知識習得が難しい中、前職でもやっていた勉強会を実践することによって色々な技術の知見を身につけることができるので開催しました。 一人が勉強する時間は限られているし、情報を取得するのも一人よりメンバーでやった方が効率的であります。 実現したいこと 技術共有文化が発達すると組織メンバーの成長が速くなり、成長した組織メンバーが複数の技術コミュニティに貢献し、これにより良い人材が成長できる会社に発展するようになります。 技術共有文化の形成 私たちのモバイルチームの勉強会は、APIチーム、Androidチーム、iOSチームで構成されています。 基本的に毎週一人ずつ、自分が持っているノウハウや関心のある技術トレンド、研究中の技術について発表をします。 発表が終わると、そのスキルに対してお互いにオープンな姿勢で意見や質問をする時間があります。 また知りたい技術などがあれば掲示板に記載し、誰かノウハウを持っているメンバーが共有する形式も運営しています。 すべてのモバイルチームエンジニアは、入社後、モバイル研究会で技術共有文化を学びます。 モバイル開発グループ勉強会はこんな形 課題は自由（自分が興味がある分野） 毎週木曜日共有 参加者20人ぐらい ファシリテーターは順番制 発表の内容は、Confulenceで作成して共有 私たちは正しい方向に向かっていますか？ 勉強会を1年間進行しながら、いくつかの注意点が見られました。 Problem: 非常に多くの人が参加するプロジェクト、私たちが正しく行っているかどうかを勉強会をさらに活性化する方法が必要でした。 Try : 問題が生じたら、みんなで目標を握って統合してうまくいくのかみんなで集まり、会議をします。 うちの勉強会は正しく行っているのか、互いに理解してコミュニケーションをとっているのか、皆が主導的になって、勉強会や開発文化を作っています。 社内情報共有に投資 モバイルチーム勉強会では、社内情報共有のための文書システムとしてConfluenceを使用しています。 勉強会のメンバーは、Confluenceに自分が知っている技術の内容、仕事上必要なさまざまな文書を作成して整理しています。 会社で情報を円滑に共有するためには、このような社内文書システムConfluenceの役割が非常に重要だと思います。 そのため、モバイルチームは、他のチームメンバーが何かを必要とする知識を検索するときにより効率的に文書システムを利用できるように、 着実にConfluenceに勉強会の内容を作成しています。 Tryしたいこと 外部イベント発表者のサポート モビリティサービスは日本で数少ない会社であり、技術カンファレンスやコミュニティで良い事例を発表して着実に共有しようと努力しています。 社内開発文化や社内で開発した技術、ノウハウなどを他社開発者と共有するイベントにしていきたいと思います。 終わり 多くの開発者が良い開発文化を望んでいます。 私が考える良い開発文化は Core Value: サービスの核心価値を理解しており、互いに知識を共有し、その根幹となる技術開発に積極的な文化 Dev Ops: 短い開発サイクルと障害耐性、高品質コードのためのコードレビュー/テストを共感する文化 Professional: 結果に対する責任感と仕事に対する誇り、専門性を互いに向上させることができる文化 ではないかと考えます。 実際、このような技術共有活動を着実に続けて文化を作っていくためには、少なくない努力と時間がかかりますが、 良い開発文化を持つチームは、開発段階中に遭遇した問題と解決ノウハウを共有して試行錯誤を減らし、最適なサービスを提供できるからです。 また、会社と開発組織のメンバーが絶えず成長するには、これらの活動が必ず必要であると確信しています。 モバイルチームは、さまざまな方法で外部開発者との関係を継続し続けます。 技術を共有し、一緒に成長していく開発文化、モバイルチーム勉強会で追求する価値かと思います。 一緒に勉強したい方は、いつでもご連絡をお願いいたします。

はじめに こんにちは、KINTOテクノロジーズのグローバル開発グループでPdMをしている高羽です。 今回はPdMとして様々なステークホルダーと話をしながら進めていくために効果的なコミュニケーションの取り方、またそのメソッドについて書いていきます。 これまでプロダクトに関わる仕事を長年やってきて、人とのコミュニケーションがプロジェクトの雰囲気やプロジェクトの成功にダイレクトに繋がると感じてきました。 その中で私がこれまで経験した、また今でも実践し日々トレーニングしている事を紹介します。 ピラミッド型の話し方 PdMの仕事をする中で人に何かを伝えるという事が多々あります。その中で私は相手に分かりやすく、相手がより理解できるために、あるメソッドを意識してコミュニケーションを図っています。 そのメソッドとは ピラミッド型のロジカルな話し方 です。 そのメソッドを使うかの根拠としては3つあります。 1つ目は、自分がそもそも口下手で人前で話すのがあまり得意でないので、何かしらのメソッドが必要だと感じている事です。 例えば、プレゼンやディスカッションしているとき、本当に伝わっているか心配になり、さらに上手く伝えられなくなってしまうというループに陥らないためにそのメソッドを使います。 2つ目に、PdMという仕事はいろんな人々と話す事が多々あり、必然的にいろんな意見が出てきて調整するのに大変ですが、そのメソッドを使うことで割とスムーズに進めることができます。 例えばPdMはプロダクトに関わる多くのステークホルダーと話をして、プロダクトをまとめ上げる役割ですが、ステークホルダー同士の意見が違ったり、どの意見を選択すればいいのかわからなくなりがちです。そのときにこのメソッドを使えば割とスムーズに解決することができます。 3つ目として、物事を相手に正確に伝える為には、ロジカルに話す事が必要です。 ロジカルに話すことで聞く相手の理解を高める事ができます。例えば他人に何かを説明する際に、一般的には、ロジカルに話す方が話を聞く側が理解しやすいという傾向があります。ロジカルな内容、伝え方をすることで相手に対して理解しやすい親切な伝え方を実現できるという事があります。親切な伝え方はプロジェクトの雰囲気や成功にも関係してくるので、物事の伝え方は非常に大切です。 さて、今話した内容はピラミッド型のロジカルな話し方を意識して話しました。 このメソッドは以前私が勤めていたインターネットの会社でセミナー等で直接指導して頂いた伊藤羊一さんが執筆された本「1分で話せ」[^1]に記載されています。 その一部を使って私が最初にPdMとして必要なものとしてピラミッド型のロジカルな話し方について説明しました。 では、ここでピラミッド型の伝え方について説明します。 このピラミッドの1番上にあるとおり、まず最初に「結論」を伝えます。「一番伝えたいことを最初に言う」 ということです。 次の段がその「根拠」となります。なぜその結論となるのかの理由を述べます。根拠の数は1つだけでは弱いので、３つ位が良いとされています。 そして３段目は、「たとえば」と事例を説明していきます。人は具体的な事例があればあるほど聞き手は納得する傾向にあるので、この部分は納得の肉付け（または理解の肉付け）のようなものとなります。より具体的なもの、イメージしやすいものであればベターです。 ではまたサンプルを使って説明します。 サンプルとして「プロダクト定例会議は週に1回の頻度が好ましい」という結論を、ピラミッド型で説明すると以下のようになります。 このピラミッド型のロジカルな話し方は初歩的で、ビジネスマンとして話をする上で当たり前とされている事が多いですが、実際に日々の仕事の上で使っている人はどれ位いるのでしょうか？ 実際に使っている人はそれほど多くないような気がします。おそらく、自分が理解できているので相手も理解できているであろう前提で、端折って話す人も多いのではないでしょうか。また私のように単純にめんどうくさいから端折って話す人もいるでしょう。 ロジカルに話すことはトレーニングです。日常的に使っていればより精度の高いものになり、聞く側が理解しやすいコミュニケーションをとる事につながっていきます。 ピラミッド型の話し方は仮説思考でもある ロジカルシンキングの教科書には逆のことを記載されていることもあるようです。 ピラミッド型のように結論から作ると、後付けで根拠を考える事になるので「唯我独尊なロジック」になりがちです。 しかし著者は言います。「でもスピードが大事な時代ですから僕は『唯我独尊だろうが何だろうが早く作ればいいじゃん』と思っています」。 たとえそれが不完全なものであったとしても、根拠までステークホルダーに共有するだけでもその結論を見つけるプロセスになりうるからです。 まさにその通りで、例えばプロジェクトにおいては早い段階でプロジェクトメンバー全体で議論し、認識を合わせながらブラッシュアップしていくことがスピードアップにもプロジェクトの成功にも繋がります。共有して議論する上で、それぞれのメンバーの主観（意見）が出てきます。 そしてそのたくさんの主観をすり合わせていく中で、みんなにとってより良い客観的な結論を出していくことができると思うのです。 スピード重視の現場の中でこのような仮説思考（上の結論からものを考える）は効率が良く、さらに客観性を持つものであれば鬼に金棒だと感じます。 聞く力のトレーニングにも使えるピラミッド ここまで相手に話す側の視点でのピラミッドを話してきましたが、このメソッドは聞く側の力のトレーニングにもなりえます。 先日、仕事上ある人から話を理解する力を伸ばすようにとの指摘をいただきました。その時に頭にピンと思いついたのが、このピラミッドを使った理解方法でした。 ピラミッドの「結論+根拠」にあたる情報の箱を頭の中につくって、話を聞きながら、箱の中に振り分けていくのです。箱に振り分けながら話を聞いていると、何が話の幹なのか、そこに何が足りないのかということがわかりやすくなります。 引用元：伊藤羊一(著), 「1分で話せ」, SBクリエイティブ, 2018 [^1] これもトレーニングですぐに出来るわけではないので日常の会話の中でも実践しながら聞く力、理解する力を高めていけるので、日々このメソッドを話す、聞くという両面でトレーニングしています。 最後に ここまで私が日々の業務の中で使っているコミュニケーションのメソッドについて紹介しました。 皆さんも普段意識して使っているメソッドなどはありますでしょうか？もしこのピラミッド型の話し方に興味を持たれたら、ぜひ試してみてください。 より良いPdMを目指していくにはコミュニケーションスキルは非常に大事だと考えているので、私も皆さんと一緒にこれから邁進していきたいと思っています。 参考文献 [^1]: 伊藤羊一(著), 「1分で話せ」, SBクリエイティブ, 2018

こんにちは、KINTOテクノロジーズ CIO室の志田です。 普段は一緒に働く皆さまのサポート全般を担当しています！ 人と人を繋ぐ架け橋のような存在を目指して、日々いろんな方とコミュニケーションを取ることを大切にしています。 こちらの記事では、社外で行っているコミュニティ活動についてご紹介いたします。 コミュニティ活動とは？ KINTOテクノロジーズでは、社員同士の親睦や交流を目的として、様々なコミュニティ活動が行われています。「○○が好き」同士のコミュニティから派生するなど、小さな共通点やきっかけから生まれることが多いです！ 私自身も複数（多分21個くらい…）のコミュニティに参加しており、コミュニケーションの場が広がることで、以下のメリットを感じております。 社員同士のコミュニケーションの場が広がるメリット 仕事中には発見できない相手の一面を知ることで、より深い人間関係が築ける ちょっとした気分転換と気持ちのリフレッシュができる 業務上接点の少ない人と親睦・交流を深められる 部活を通じて仲良くなり、その後業務に活きるということもよくあります コミュニケーションの活性化＝相手を知る機会が増えること 社内コミュニティは企業カルチャー・社風のボトムアップにも繋がっていきます。 また、コミュニケーションは強い組織の土台であり、経営の活性化にも通ずると思います。 なんだか壮大な話になってしまいましたので、後半はカジュアルに！ 普段デスクワークのため運動も大事ということで、今回は運動系コミュニティをご紹介させていただきます(^o^)/ 運動系コミュニティ紹介 🏀バスケ部🏀 ＼特徴／ メンバー数：25名 バスケを楽しむ気持ちがあれば大歓迎 休日にも関わらず毎回10名程参加 互いに声を掛け合いながらわきあいあいと、パス練習やシュート練習で汗を流す コミュニティーを通して普段の業務中とは異なるコミュニケーションも生まれる 会社近くの綺麗な体育館で開催 ガチ試合で躍動感のあまりピントが全く合いません（笑） ⚽️フットサル部⚽️ ＼特徴／ メンバー：39名 初心者も経験者も楽しめる空間（元Jリーガーの方も！？） 他事業部の方と楽しい時間を共感できるとても良い機会に 応援だけでもいい、参加したい時にフラッと参加も可能 年齢、国籍の垣根を超えてコミュニケーションを図れる（スポーツは言語の壁を超える ） 記念の私の初シュートシーン⚽（腕に落ち着きがないですね） この後華麗なゴールインしたかは・・・皆様のご想像にお任せします( ˘ω˘ ) 突然のゲリラ豪雨でも試合続行。社会人になっても青春は味わえます✨ ⛳️ゴルフ部⛳️ ＼特徴／ メンバー：21名 部門や役職の垣根を超えたコミュニティー 打ちっぱなし練習に行ったりラウンドを回ったり（シーズンになると月1ペースで開催） マネージャから直接OJTを受けられるので親睦を深めると共に成長へも繋がる 1日を通してコミュニケーション（合宿もあり） 大自然の中でのドライバーショットは都会では味わえない爽快感（カッキーンと響き渡る打球音を目覚ましにしたいほど） 入社してからゴルフデビューするメンバーが多いです（仲良し女子） 緊張感もピークのグリーン周りで互いに心の中で入れ～！と応援しています。 🎾テニス部🎾 ＼特徴／ メンバー数：20名 経験者多めなのでベテランメンバーが優しくレクチャーしてくれる 試合は初心者もベテラン勢も本気！ 会社帰りに会社近くのコートを利用し開催 テニスのあとは美味しいビールをいただきます（皆さんお酒好き） 練習風景。初心者が半数なので、経験者のメンバーから打ち方など丁寧にレッスンしてくれます ＼( ˙-˙ ＼)(／ ˙-˙ )／ 丁寧な指導のお陰もあり、 皆さんキャッチアップが早い！ おわりに みなさん気になる部活はありましたか？⸜(　˙-˙　)⸝ 社内のコミュニティは作り放題なので、きっとこの時間にも新たなコミュニティが存在していることでしょう。。。。！ アフターシックスや休日の過ごし方は人それぞれ。 そのうちの選択肢としてKINTOテクノロジーズには社員同士の親睦を深めながらスポーツできる場があるので、がっつり身体を動かしてリフレッシュしたい！と思う方も有意義なひとときを過ごすことができます！ ご入社された際はぜひご参加お待ちしています🤗

概要 グローバル開発グループの崔です。現在はGlobal KINTO Appチームのプロジェクトマネージャーを担当していますが、以前はグローバル開発Gで開発しているバックオフィスシステムのプロジェクトマネージャーを担当していました。 今回は、そのバックオフィスシステム開発チームにてソースコードを管理する際に採用した、Gitのブランチ管理方法（Gitflow）についてお話します。他のプロダクトにも流用できると思いますので、ぜひ参考にしてください。 Gitflow 注意：今回は、あくまで私の開発チームで採用したGitflowについて説明します。以下の説明ではブランチ名を「master」と書いていますが、GitHubを利用する場合、masterは古い呼び名になるため、現在ではデフォルトブランチは「main」になります。役割は全く同じです。 全体図は以下の通りです： 各ブランチの役割 master: リリース済みのソースコードを管理し、本番環境に動いているアプリケーションと同じソースバージョンを持つブランチ。リリース毎にタグが付けられます。 develop: 開発済のソースコードをまとめるブランチ。本番環境にまだリリースされていない機能を含み、常に最新機能を持ちます。一般的には回帰テスト(regression test)はこのブランチでデプロイして実施されます。 feature: 新機能、修正機能の開発用ブランチ。開発する機能や、タスクなど単位でdevelopから分岐し、結合テストが完了したら、developにマージします。一般的には１つのユーザーストーリーにつき1つfeatureブランチが作れらますが、開発チーム内である程度自由に決めることができます。 hotfix: リリース後のバグフィックス用ブランチ。masterから分岐し、バグを修正しテストを通ったら、このブランチで本番環境へデプロイします。本番作業が完了したら、該当ブランチをmaster, develop共にマージします。必要に応じて、一部のrelease, featureブランチにもマージします。 release: プロダクトリリース用のブランチ。 リリース予定の機能が反映された状態でdevelopブランチから分岐します。 このブランチを使って本番環境へデプロイします。本番作業が完了したら、masterとdevelopブランチにマージして、該当ブランチを削除します。 support: 旧バージョンをサポートし続けなければいけないプロジェクトでは support ブランチが必要です。support ブランチでは、旧バージョンの保守とリリースを行います。サポートが必要なバージョンの master ブランチのコミットから派生させ、サポートを終了するまで独立してバグフィックスやリリースを行います。 bugfix: 上記５つ標準のブランチ種別以外、bugfixというブランチ種別も定義します。 詳細は後述しますが、リリースの前にバグが見つかった場合、releaseブランチからbugfixブランチを分岐して修正対応を行います。 開発の流れ ① 初期化作業 masterからdevelopを作成します。 注意： masterとdevelopブランチはGitflowのメインブランチとして常に存在するものになり、一度作成されたら、削除できません。(GitHubで設定する) ② 新機能、修正機能の開発 1．developブランチからfeatureブランチを作成し、新機能、修正機能の開発作業を開始します。 2．featureブランチの命名規則：feature/xxxx その「xxxx」は開発チームが命名ルールを決めて良いです。 　例：feature/GKLP-001、feature/refactoring、feature/sprint15 また、結合テストを行う前にpull requestを作ってソースレビューを行うため、主とするfeatureブランチからさらに作業用ブランチを作るのがお勧めです。具体的なパターンは後述します。 3．ソースコード修正のコミットは作業ブランチにて行い、終わったらPR提出し、他の人にレビューしてもらいます。 4．ソースレビューが完了したら、主とする機能ブランチにマージし、結合テストを行います。 5．結合テストが完了したら、developブランチにマージするPRを提出し、マージします。 　　注意：リリース計画により開発完了してもdevelopにマージしてはいけない時がありますので、 マージするタイミングを常に確認してください。 6．developにマージした後にfeatureブランチを削除します。 パターンNo.1: 機能ブランチと作業ブランチ このパターンでは、該当機能ブランチから切ったすべての作業ブランチがマージ済みになってから、結合テストが行われます。 １つの機能の開発規模が大きく、複数スプリントを跨ぐことが見込まれる場合、このパターンを採用するのが適切です。 パターンNo.2: スプリントごとのブランチと作業ブランチ このパターンでは、すべての作業ブランチがマージ済になってから結合テストを行うことに限らず、スプリント内の1機能に必要な開発分がマージ済みになったら、その機能に対して結合テストを行うのもいいです。 開発する機能が規模が小さく、1スプリント内で完了と見込まれる場合、このパターンを採用するのが適切です。 推奨しないパターン(No.3)：機能と作業ブランチを同一にする このパターンでは、PR提出と結合テストのタイミングがはっきりせず、developにマージする頻度も高くなるので、QAとリリース計画を作る際にとても面倒になると想定されます。そのような無計画なやり方は推奨しません。 その代わりに、システム開発、運用の際にちゃんとリリース計画して、それに合わせてfeatureブランチの切り方を決めるのがお勧めです！ ③ リリース&デプロイ developブランチからreleaseブランチを作成する。 releaseブランチにタグを付ける。(命名規則は下記のTag命名規則を参照) 本番環境へのデプロイが終了したら、releaseブランチをmasterブランチにマージする。 マージ完了後にreleaseブランチを削除する。 リリース計画 本番環境にリリースする予定がある開発については、早めにリリース計画を作りましょう。 featureブランチの運用ルール、featureの機能ブランチをdevelopにマージするタイミングはリリース計画に合わせて決められます。 一番簡単なリリース計画としては、developブランチに開発済みの機能をすべてリリースすることで、releaseブランチを作るだけで済みます。 但し、同時に複数開発チームがそれぞれ違う機能を開発し、複数回リリースするように計画する場合、先にリリースブランチを作成して、対象となる機能を1つずつマージするようにしましょう。 例えば、feature 1, 2, 3を同時に開発するが、先にfeature 1, 2をリリースし、数週後にfeature 3をリリースする場合： 上記release 1.0, 2.0のようなreleaseブランチは、一旦developから分岐して作成したら、原則的には二度とdevelopから修正ソースコードをマージしない、というルールにしましょう。 理由は、複数回リリース計画がある場合、releaseブランチ作成後、別の機能がdevelopにマージされることがあるので、さらにdevelopからマージしてしまうと、テストが終わっていないにも関わらず誤って機能がリリースされてしまいます。 以下の図のように： また、featureブランチは開発完了したらすぐにdevelopにマージする訳ではないです。一旦developにマージすると、次回のリリースに含まれますので、 featureブランチをdevelopにマージするタイミングは、リリース計画に合わせて確認しましょう。 リリースの前にバグが見つかった場合 bugfixブランチを該当releaseブランチから分岐して作りましょう。そのうえでバグを修正し、PRを提出しreleaseブランチにマージします。修正されたバグはリリース作業後、releaseブランチがmaster, developにマージされると反映されます。 以下の図の通り： ④ 本番環境のバグ修正 本番環境でバグが発生した場合、以下の手順で修正します。 まず、masterブランチからhotfixブランチを作成する。 hotfixブランチにて修正が終わったら、タグを付ける。（命名規則は下記のTag命名規則を参照） 本番環境へのデプロイが完了したら、hotfixブランチをmasterとdevelopブランチにマージする。 マージ完了後にhotfixブランチを削除する。 保守用ブランチ プロダクトのバージョンアップポリシーにより、マイクロサービス単位でバージョン管理され、各メジャーバージョンに対しては、一定の保守期間があります。ですので、該当マイクロサービスのGitHubリポジトリには、各メジャーバージョンの保守用ブランチを作る必要があります。 例えば、「自動車」というマイクロサービスは、これまでV.1, 2, 3の３つメジャーバージョンがリリースされた場合、保守用ブランチは以下のようになります： 古いメジャーバージョンにおいて、マイナーチェンジや、バグ修正などを行うには、もちろん該当する保守用ブランチから分岐するのですが、開発規模によって適当なリリース計画を作って、併せて開発用ブランチや、リリースブランチなどを決めたらいいです。 Branchコミット規則 Gitのブランチに修正ソースコードをマージするには、2種類の方法があります： ・直接コミットする方法 ・pull requestを提出してレビュー担当者が承認してからマージする方法 原則的には、pull requestを作ってからマージする方法を採用しましょう。 但し、以下のブランチには、直接コミットしてもいいです： 1．新機能、修正機能を開発する作業用featureブランチ 2．リリース直前のバグ修正用bugfixブランチ 3．リリース後バグ修正用hotfixブランチ Tag命名規則 dev環境 1.1 GitHubの上に、手動的にリリース時（非推薦） 　→ gitブランチにタグを付ける 　命名規則：x.x.x-SNAPSHOT 　例：1.0.0-SNAPSHOT 　→ ECRに登録する時、イメージのタグはタグ＆時間により、自動的に付ける。 　 　イメージのタグ名：x.x.x-SNAPSHOT_yyyyMMdd-hhmmss 　例：1.0.0-SNAPSHOT-20210728-154024 1.2 JIRAチケットを利用し、自動的にリリース時（推薦） 　→ gitブランチにタグを付けない。 　→ ECRに登録する時、イメージのタグは現在のブランチ＆時間により、自動的に付ける。 　イメージのタグ名：ブランチ名_yyyyMMdd-hhmmss 　例：develop-20210728-154024 stg&prod環境 releaseブランチ又はhotfixブランチにタグを手動的に付ける。 命名規則：release.x.x.x 例：release.1.0.0 このGitブランチ戦略で解決した課題 私たちの開発チームは1年前に発足しました。当初、メンバー達の持っている開発経験とバックグラウンドがそれぞれ違うため、ソースコード管理についてかなり混乱していました。 また、同じプロジェクトに本社にいる開発者たちが組んだ「コア」チームと、オフショアにいる開発者達が組んだ「スター」チームがありました。 両チームはそれぞれ違う機能を分担して開発しますが、やはり同じソースファイルを同時に修正することが避けられません。 よって、以下の問題が発生しました： ソースコードのコンフリクトが発生する時、誤って他人の修正分を削除してしまう 古いソースコードをベースに機能開発してしまう 段階的なリリースが実現できない 我々はシステム開発をする上で、チームワークを大事にしています。全員に認められ、そして実行できるルールが不可欠です。 Gitflowはまさにこういうものです。 それぞれ違う機能の開発を担当する人は、それぞれ違うfeatureブランチを作成して、互いに影響しないようにソースを修正できるでしょう。 また、スプリントの開発周期に合わせて最新ソースコードをdevelopブランチに保持することで、次の開発周期がスタートする際に、みんなが最新ソースコードをベースに各自の担当分を展開できるでしょう。 さらに、「リリース計画」ごとにreleaseブランチを作成することで、開発される機能を少しずつリリースすることが実現できますので、開発者の負担を減らすことができ、プロジェクト自身のリスクも減らせるでしょう！ このGitブランチ戦略を導入したことで、私が当初リードしていたバックオフィスシステムの開発チームは混乱期を乗り越えて、安定的に機能開発・リリースすることができました！今後、アプリ開発のプロジェクトマネージャーを担当することになったのですが、アプリ開発でも似たような課題に直面するときに、この経験を参考にして、また改めてチャレンジしてみたいと思っています。皆さんもご自分自身のプロダクト開発に参考してみてはいかがでしょうか？

自己紹介 はじめまして、KINTOテクノロジーズ（株）でプラットフォームグループのグループマネージャをしている岩崎です。 私は2019年12月よりKINTOテクノロジーズ（株）の前身である株式会社KINTOの開発・編成部に入社しインフラエンジニアとしてシステム構築・運用を実施しながらグループの立ちあげを進めてまいりました。現在ではグループマネージャーの他にSRE、MSPとCCoEも担当しております。元はECサイトを手かげるIT企業出身。オンプレミスやプライベートクラウドなインフラ環境におけるServer Administrator、SREチームのエンジニアやマネジメントを手がけた後KINTOへ入社しております。 本記事の位置付け 本記事はプラットフォームグループのチーム紹介およびこれまでの活動とこれからについて皆様に知っていただき一緒に働いてみたい！と思っていただけることが目的となります。 プラットフォームグループ 役割 AWSを中心とするインフラ設計、構築、運用などを担当 特徴 「標準化されているもの」「これから導入するもの」が混在しているため積極的に他者を助けたり、逆に助けを得ながら未知を楽しんで活動しています。 組織構成 チーム名 所属人数 拠点 System Administrator 6名 東京・大阪 DevOps 6名 東京 SRE 3名 東京 DBRE 4名 東京 MSP 3名 東京・名古屋 CCoE 2名 東京・大阪 2022年11月現在 チーム兼務あり 所属人数推移 まだ3年ですがムーアの法則とは行かないなりにも成長を続けております。 メンバーの性格 多種多様な性格の方が集まっています。 全16種制覇のためにまだいない性格の人は優遇？ではないですが来ていただけるとまたさまざまな議論ができそうで嬉しいです。 FY23グループスローガン 今期のスローガンはこちらにしております、前期までに色々とリリースをしてきたものの利用率をあげて成果をだせるところにスコープを置くことをイメージしてこちらに設定しております。 FY23グループミッション 今期のグループミッションはこちら↓です。元々、AgilityとStabilityに関しては4半期ベースで+10%を目指してやってきましたのでさらにそこへ加速できるために自分達が何ができるかをチャレンジしてもらうというメッセージを込めてます。 チーム紹介 System Administrator チーム :::message クラウドエンジニアリング業務(ネットワーク/システムの設計、構築、運用、インフラ障害対応)を通じて安定的なインフラ環境を提供 ::: AWSのプロフェッショナルエンジニア集団、IaCによるシステム構築やシステム変更などの運用業務を担いながら、システムパックのリリースやアプリケーションモニタリングなど改善業務もこなすプラットフォームグループの中核。 採用募集ページ DevOpsチーム :::message DevOpsチーム立ち上げサポートを通じて開発のスピード、品質向上を実現 ::: アプリケーションのチューニングや運用や、AWSまで熟知したプロフェッショナル集団。GitHub ActionsによるCI/CDの提供やDevSecOpsの推進などを手がける。KINTOテクノロジーズ（株）のコンテナ(ECS)化の影の立役者、現在はAPMや分散トレーシング(X-Ray)などの導入・普及にも注意力している。 採用募集ページ：採用予定なし SREチーム :::message SLA改善提案を推進することで安心安全なサービスの提供を実現 ::: 未来のプロダクト信頼性を担うプロフェッショナル集団。信頼性向上のためにどんな事ができるのかをSREヒエラルキーを下から積み上げながらSREガイドラインを作成中。プロダクトを絞って開発グループへのSREサポートも並行して実施しております。 採用募集ページ DBREチーム :::message データベース専門知識を用いて再帰性のあるプロセスや戦略決定を実現 ::: データベースのスペシャリスト集団。データベースの信頼性向上のために見える化するツール提供から、セキュリティ対策やマスキング対策などの施策も順次準備中。 採用募集ページ MSPチーム :::message アプリケーション運用サポートにより間接的な開発スピードと品質向上に貢献する ::: アプリケーションの障害・問い合わせ受付業務を行う「サービスデスク」と障害の１次オペレーションや定型作業を実施する「一次システム保守」の２つの役割を担っていただける協力会社との連携を行う事務局的役割。 採用募集ページ：採用予定なし CCoEチーム :::message 適切なポリシーで統制されたセキュアなクラウド環境の実現 ::: クラウドセキュリティのスペシャリスト集団。クラウドセキュリティガイドラインの作成から、ガードレールの実装やAWS/GCPの教育サポートまでを手がける。 採用募集ページ プラットフォームグループ活動の軌跡 インフラ設計・構築・運用の内製化 まず初めに実施したことは外部委託されていたシステム環境を自前のAWS環境へ移行し、同時に24x7監視を含めた運用含めて内製化を実現させました。内製化と言っても構築作業はもちろんのこと1人で24x7のPagerDutyを受け続けるという体制でのスタートとなっております。 IaC(Infrastructure as Code) Terraformを利用し、全体最適を意識したモジュールを作成 次に実施したのはIaC化です。優秀なエンジニアにJoinいただいたのでIaC化を本格的に進めることにしました。当時はマルチクラウドも意識してTerraformを採用しております。EC2構築にはPacker＋AnsibleでOSイメージ（AMI）を作成し、Terraformで仕上げるところから始めています。 このTerraformモジュールの初期設計が後のECS化の礎となっております。 コンテナ化（EC2の脱却と共にECS化を推進） 次に仕掛けたのはコンテナ化(EC2->ECS)です。EKSでなくECSにしたのは当時はプロダクト単体で構築されるシステム構成が多くECSの方がCI/CDを含めた学習コストが低くコンテナ化しやすいと考えたからになります。コンテナ化した後のリリース業務などは開発グループ側へ権限付与を想定しておりましたのでなるべく開発グループのエンジニア負荷をさげて導入コストも抑えながらコンテナ化を実現したいという思いがありました。 CI/CD(GitHub Actions)提供・教育・導入サポート実施 CI/CDはコンテナ化を推進するには提供が必須でした。ECSでのコンテナ使えますよと案内してもメリットを感じてもらえないと意味がありませんでした。そこでGitHub ActionsでのCI/CDを提供し、同時にSonarQubeも提供したCI/CDを使えば情報がPushされて静的解析されますよというDevSecOpsの要素も入れて提供を開始しました。 システムのリリース（1システム構成の構築を2週間から3日間へ短縮） 続いて仕掛けたのはシステムパックの提供です。システムパックとはあらかじめよく依頼されるシステムの型を６種類ほどに絞り必要最低限のインプット情報をいただければ3日間でAWS上にシステム構築してお渡ししますよというものになります。 これによりシステム設計時のヒアリングによるストレス軽減や時間の短縮が可能となり開発グループとの関係性改善にも寄与した試みだったと思います。今では７割ぐらいの依頼がシステムパックでDev環境構築を依頼され、その後アプリケーション設計を進める中でSTG、PRODとPackから要件として落とされた内容をシステムに反映したカスタマイズされるという流れができております。 MSP(Managed Service Provider)の導入・開発Gへの提供および導入サポート開始 システムパックと同時に仕掛けたのは開発グループ側の障害対応1次受けや、定型作業を外部委託先で運用いただくという試みになります。 こちらは当時のプラットフォームグループで受けるべき作業ではなかったのかもしれないのですが、まだまだ会社として成長途中でしたので開発グループへの貢献をよりできないかという観点から開発グループの一部のメンバーや外部委託と協力してサポート開始しております。 今ではMSPが事業部や関連会社からの問い合わせ窓口の中心になりつつあり重要な存在となっております。 アプリケーションモニタリング強化 次に仕掛けたのはモニタリング強化です。但し、インフラのモニタリングは既にシステム設計と共にほぼ完成されておりましたのでターゲットとしてはアプリケーション監視となりました。 ログ基盤（OpenSearch）導入・導入サポート開始 ログ基盤として初期はCloudWatchのみを提供しておりましたが、ログ格納時にJSON形式で格納しないとログが閲覧時に時系列でバラバラになりさらに複数サーバから送信されると解析しにくいという問題がありました。 これに対応するためにAWSのManaged ServiceであるOpenSearchを構築して提供しております。 この時にOpenSearchだけを提供しても利用促進とならないことはわかっておりましたので同時にECSのサイドカーとしてOpenSearchへログを送信するサイドカー(fluentbit)のコンテナイメージ化とCI/CDのテンプレートへ導入するなどして同時に提供しております。 APM(Application Performance Management：Prometheus+Grafana)導入・導入サポート開始 コンテナ(ECS)化を推進したことでコンテナ内アプリケーションのリソースモニタリングが必要となりました。これに対応するためAWS ManagedのPrometheus＋GrafanaでのAPMを提供しております。 こちらもログ基盤と同様にサイドカー(Open Telemetry)を提供して利用しやすい環境を提供しております。 関連ブログ：Amazon Managed Service for PrometheusにECSからアプリケーションメトリクスを収集する by @sokasanan 分散トレーシング(X-Ray)導入・導入サポート開始 モニタリング強化の３本柱として分散トレーシング(X-Ray)の提供も開始しました。これによりコンテナ間通信やバックエンドのエンドポイントやDBへの通信状況の見える化ができ問題点も瞬時にわかるようになりました。 さいごに グループは立ち上げ段階をへて成長期に入っております。入社後の受け入れとしてOn bordingコンテンツも充実させておりますのでご興味のある方はカジュアル面談からでもお気軽にご応募ください

Introduction My name is Hoang, I am a backend engineer who is responsible for Europe and South America as part of the Global KINTO ID Platform (GKIDP) team at Global Group in KINTO Technologies (KTC). We deal with global problems to authenticate users all over the world. Providing a fast, reliable, and highly available Identity and Access Management (IAM) system is a MUST with GKIDP. In this article, I would like to share my thoughts on how we could do load-balancing/route traffic on any kind of cross-border system. We know that HTTP (or UDP, DNS also) are stateless protocols, which means that each request from clients to servers does not retain any information from the previous request, but why it should be stateless, and what for? The deep reason is a stateless protocol can be load balanced for scale architecture since any request can be routed to any web server without concern about each request state. That makes web servers can be horizontally scalable by spreading servers in global maps for making the system resilient and high-performance. In this article, I would like to introduce two main types of load balancing: DNS Routing and hardware load balancer (a.k.a Load balancer). These two methods are separate from each other but can be mixed to enhance global systems like KINTO vehicle subscription services. DNS Routing When the user types a URL into the browser, the browser will send a DNS query to the DNS server to get the IP address associated with the hostname of the website. The browser will use that IP address and not the domain of the website to access the server. The simplest flow is like the below:  Figure 2. DNS Routing In this case, where the system contains multiple servers across regions, the DNS server's responsibility is to route the client to the most appropriate server to improve performance and availability. The way DNS decides where to forward requests is called DNS routing. DNS routing is an easy configuration with a high scalability method because it does not touch user requests. Frequently, it is used to route users among data centers or regions. Some common DNS routing methods are simple Round Robin, and dynamic methods like geo-location-based, latency-based, and health based. DNS routing has drawbacks like outdated DNS cache problems: DNS always returns the same IP address for one domain in TTL (time-to-live) duration even if that server is down. There is a confusion that must be explained here: DNS does not route any traffic, it only responds to the DNS queries the IP address — the location where the user should send traffic. In Fig. 2, from step 3: After getting the server IP address, the client really sends traffic (like HTTP requests) to the target server, and the hardware load balancer takes the place to distribute traffic among multiple backend servers behind it. I will explain in detail the hardware load balancer in the next part. Hardware Load balancer After receiving the translated IP address corresponding to the domain, the client will send the traffic to the target server. From now, the hardware load balancer stands in front of a fleet of backend servers and distributes traffic to these web servers. Indeed, the hardware load balancer is nothing but a reversed proxy — a physical device that takes responsibility as a coordinator of the system.  Figure 3. Load balancer as reversed proxy There are 2 main kinds of hardware load balancing: layer 4 load balancing and layer 7 load balancing which occurs in the Transport Layer and Application layer of the OSI model, respectively. Briefly explaining the OSI model, the requests are compressed by 7 layers, like Matryoshka dolls. The deeper (from layer 1 to layer 7) the data is extracted, the more information is revealed. It means that the load balancer in layer 7 has more information about the incoming requests compared to the level 4 load balancer. Take a look at the data on each layer of the OSI model below:  Figure 4. Data on each layer of the OSI Model Layer 4 and layer 7 load balancers differ in how deep they interfere with the incoming request. Layer 4 load balancing At layer 4, the load balancer knows little information about incoming requests, only the client IP address and ports. Because it is encrypted data, the load balancer can not understand anything about the content of the request data. That makes load balancing at layer 4 not smart like layer 7 load balancing. Advantages: Simple load balancing No decrypt/lookup on data => Faster, efficient and secure Disadvantages: Only a few load balancing methods (not smart load balancing) No caching, cause you can’t access data. Layer 7 load balancing At layer 7, the load balancer really can access readable data of the incoming request (for example, HTTP request headers, URL, cookie, etc. ). The layer 7 load balancer can distribute traffic much smarter than layer 4, for example, a very convenient strategy is path-based routing. Advantages: Smart load balancing Caching enabled Disadvantages: Decrypts data in middle (TLS termination) => Slower, less secure because load balancer has rights to look at data. Routing/Load balancing methods list There are some routing/load balancing methods that vary in their purposes. Round Robin algorithm: The simplest method to implement: The server address is returned in a random or rotating sequential manner. Weighted-based algorithm: Control the percentage of the requests that go to each server. For example, if you want to introduce a Canary release for a small group of users, so you will set up one small server for the Canary release for getting user feedback, and route only 5% of users to this server. The left 95% of users still go to the stable application version. Latency-based policy (usually on DNS routing): Route to the server that has the least latency close to the client. In case low latency is a priority, this policy is a suitable method. Least connections (usually on load balancer): Traffic is directed to the server having the least traffic. This algorithm helps for better performance during peak hours by preventing big requests converge on one particular server. Health Checks (heartbeats): a.k.a failover. Monitor the health of each server by establishing a live session. The load balancer will check the heartbeat of each server registered with it, and it will stop routing requests to one server if that server’s health is not good, then forward it to another healthy server. IP Hash (usually on load balancer): Assign the client’s IP address to a fixed server for optimal performance (for example, caching) Geo-location-based routing (usually on DNS routing): Based on user location by continent or country then return the appropriate server on each location. Multi-Value (Only for DNS Routing): Return the numbers of IP addresses instead of one. Path-based routing (Only for Layer 7 Load balancer): according to the path of the request, decide which server should handle the request. For example: /processing, LB will forward the request to the processing server, /image, LB will forward to the image server. Before we leave The hardware load balancer and DNS routing can be easily confused with each other. They are not substitutes for each other but are usually mixed with each other. The thing is, they use DNS routing for large scales like between data centers or large regions because it’s much cheaper and faster than a hardware load balancer. Following that are hardware load balancers, which often distribute traffic inside that data center or region. DNS routing deals with DNS query, while hardware load balancer deals with traffic. Understanding these 2 definitions are essential for scaling a global system with high performance and availability. References https://medium.com/@phamduchoang.eee/but-what-is-osi-model-29578b795f0c https://iq.opengenus.org/layer-4-layer-7-load-balancing https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy-edns0.html

こんにちは。CIO室 人事採用チームの丸山と申します。 普段は大阪拠点（Osaka Tech Lab といいます）にて、採用や採用広報を担当しています。 最近キンクマハムスターを家族に迎え入れ、日々愛ででおります🐹 2つのアドベントカレンダー🎅 KINTOテクノロジーズは2022年2つのアドベントカレンダーを掲載いたします。 技術記事 グループ紹介記事（本記事はこちら側です！） なぜグループ紹介記事？🤔 2022年12月現在、KINTOテクノロジーズは14グループ・2プロジェクトチームで構成されています。 今年1年で社員数はおよそ1.5倍と急拡大しているので、来年はもっと増えているかもしれません。（楽しみ！） それぞれのグループによって関わるプロダクトやプロジェクト、それに伴って開発体制も様々です。 2023年も多くのメンバーにテックブログを通して技術情報を発信いただく中で、各グループの紹介記事があると、前提情報が共有でき、読者の方により解像度の高い情報をお届けできるのではと思い、アドベントカレンダーで掲載することにしました。 各グループのマネージャー / リーダーが記事を執筆しております。 記事を通して、会社やグループ、メンバーについても知っていただき、KINTOテクノロジーズで働くイメージも伝えられると嬉しいです！ こんな記事もあるよ👀 KINTOテクノロジーズ。実は、80%以上がエンジニア・デザイナーで構成されています💻 そんなメンバーの方々が参加する部活動や勉強会、個性的なデスク紹介など、KINTOテクノロジーズのなかみについて知っていただける記事がアップされていきます。 ぜひクリスマスまでの時間をアドベントカレンダーと一緒にお楽しみいただけますと幸いです🎄✨

自己紹介 はじめまして、KINTOテクノロジーズでモビリティマーケットの開発・運用を担当しているリナです。 普段はフロントエンジニアとして、主にNext.jsを用いて実装しています。 最近のマイブームは、ガンプラを組み立てることです！ Advent Calendarとは 12月1日～25日にかけて、クリスマスまでの期間をカウントダウンするカレンダーのことです。 IT業界では、期間中に1日1記事投稿することで、日頃の取り組みや情報を発信するイベントとして毎年楽しまれています。 弊社でアドベントカレンダーを実施するのは、今年で2回目です！ 昨年の記事は こちら からご覧ください。 Advent Calendar 2022の記事 今年のアドベントカレンダーは、テックブログの開設を記念して2本立てで公開します✨ 1. 技術記事 インフラ・モバイル開発・QA・デザインなど、多岐にわたる分野の技術記事を公開する予定です。 記事を通して、KINTOテクノロジーズのエンジニアやデザイナーが、日々どんな業務を遂行しているか垣間見ることができます。 https://qiita.com/advent-calendar/2022/kinto-technologies 2. グループ紹介記事 KINTOテクノロジーズのオフィスや各グループ(部署)が担う業務内容を紹介します。 また、有志の勉強会や部活動の様子も公開する予定です。 記事を通して、KINTOテクノロジーズの社員の日本国内およびグローバルにおけるKINTOの取り組みや社員の働き方を知ることができます。 https://qiita.com/advent-calendar/2022/kinto-technologies-introduction ぜひ、お楽しみに！ さいごに 今年のアドベントカレンダーを通して、少しでも弊社の取り組みや社員の働き方を知っていただけると嬉しいです！ そして、KINTOテクノロジーズでは、一緒に働ける仲間を募集しています。詳しくは こちら から 2022年のアドベントカレンダーにご期待ください！

はじめに こんにちは。分析グループでデータエンジニアをしている小池です。新卒入社した前職では主にサービスグロースのための分析を行っていたのですが、現職ではデータ分析基盤の開発をしています。平たくいえば、データアナリストからデータエンジニアへキャリアチェンジしたというわけです。この記事では、私がデータアナリストからデータエンジニアになるまでのお話をしていければと思います。 データアナリストやデータエンジニアとは データアナリストとデータエンジニアの責務がわからないかたもいらっしゃると思いますので、まずはそこから説明します。それぞれの職種の責務は次の図のようになっています。 データエンジニアは、データアナリストが集計・分析するためのデータを用意する役割を担います。具体的な業務内容としては次のようになります。 他システム、別データソースからのデータ取得 1で取得したデータをデータアナリストが使いやすいような形に加工 2で加工したデータにデータアナリストがアクセスできるようデリバリー 対して、データアナリストはデータを集計・分析し、ビジネスをどう改善すればよいか示唆出しをする役割を担っています。具体的な業務内容としては次のようになります。 データエンジニアが用意したデータをSQLなどを用いて集計 1で集計したデータを分析 2で分析した結果を元にビジネスをどう改善すればよいか示唆出し あるいは、次のような業務も行います。 データエンジニアが用意したデータをSQLなどを用いて集計 1で集計したデータをダッシュボードにまとめ、データを定点観測できる環境を整備 なんとなくイメージはつかめたでしょうか？ これを踏まえて、この記事では私がデータアナリストからデータエンジニアへとキャリアチェンジし駆け出しデータエンジニアとして駆けてゆくさまをお見せできればと思います。同じくデータエンジニアへキャリアチェンジしようとしているかたがたの参考になれば幸いです。 KINTOテクノロジーズのデータアーキテクチャ データ基盤の開発についての話をする前に、まずは当社のデータアーキテクチャについて説明します。主にAWSのサービスを用いて構成されており、大まかなデータの流れは次のようになっています。 Glueというサービスを用いて外部ソースから取得したデータを変換・加工してS3に保存 Athenaというサービスを用いてS3のデータに対しSQL検索 当社のデータエンジニアは主に1の部分を行い、さまざまなデータをAthenaで集計・分析できるような環境づくりを行っています。 Glueのワークフロー開発 データアーキテクチャについて理解したところで、データアナリストからエンジニアへの第一歩として開発したGlueワークフローについての説明をします。Glueには主に次の3つの機能が搭載されています。 ジョブ : 分析の前処理(データ抽出、変換、ロード)を実行する機能 クローラ : データカタログへメタデータを作成する機能 トリガー : ジョブ、クローラを手動または自動で実行する機能 ジョブは分析の前処理を実行する機能のことです。たとえば、CSVデータを読み込んで加工し出力するといった一連の処理を一つのジョブとして定義できます。クローラはデータカタログへメタデータを作成する機能を持っています。テーブルの入出力形式や列名などのデータ型を定義し、それをデータカタログという箱に入れることができるというイメージです。トリガーはジョブ、クローラを手動または自動で実行する機能のことです。毎日決まった時間に実行させたり、一つ前のジョブが正常終了したときに実行させたりできます。また、これら三つを一連の処理としてまとめて管理しやすくしたものをワークフローといいます。 私は「外部ソースからのデータをAthenaで集計できるようにする」ワークフローを開発することでデータの流れを大まかに理解し、データエンジニアとしての一歩を踏み出すことができました。ところで、前職でデータアナリストをやっていたころはデータエンジニアが整形したデータを集計・分析するという環境だったため、データがどのように作られているかどうかには気を配ることはあまりできていませんでした。しかし、この開発でトリガーやジョブの組み合わせ方などデータの前処理部分の理解を深めることができたのはとても大きな経験になりました。 アナリストとエンジニアのスキルセットの比較 ここまでデータエンジニアの業務について述べてきましたが、私の考えるデータアナリストとデータエンジニアそれぞれに必要なスキルセットを整理してみます。 データアナリストのスキルセット 分析設計 集計 分析 分析結果の説明 まず、データアナリストに必要なスキルとして分析設計の能力が挙げられます。たとえば、マーケターに「このデータがほしい」と言われたとします。言われるがままにそのデータを出すこともできますが、それだと手戻りが発生してしまうこともあります。そのため、そのデータを出したい理由は何なのかを質問することで元々の目的を明確にし、どんなデータを出して分析すればその目的が達成できるかを定めるといったことが必要になります。これが分析設計です。 続いて、集計する能力です。これは、SQLなどを用いてほしいデータを抽出することを指します。SQLを書いて抽出したデータにミスがないかをチェックするための検算や、ミスが起きにくいSQLの書き方を身につけるのは意外と難しいです。 次に、分析する能力です。ベースとなるのは、主観を入れず論理的に物事を考えられる能力です。ここに、統計や機械学習などの知識が必要になる場合があります。 最後に、分析結果を説明する能力です。いくら高度な分析を行ったとしても、その分析結果がビジネスに活かせなければ価値があるとは言えません。意思決定者に適切な説明を行い、理解してもらうところまでできて初めて価値が出てきます。 データエンジニアのスキルセット データパイプラインの設計 コードの設計 データ加工 まずは、データパイプラインの設計能力です。本記事で説明したことと照らし合わせると、データ加工のワークフローをどのように構成すれば求めているデータを作れるかどうかを見定める力といえばよいでしょうか。 続いてはコードの設計能力です。これはデータエンジニアだけではなくすべてのエンジニアに共通することだと思いますが、コードは書いて終わりではなく、のちのち修正する必要が出てくる可能性があります。そのため、いかに保守運用しやすいコードを書くかということは重要です。 最後に、データ加工の能力です。主にSQLやPythonを使うため、これらを満足に扱える能力が必要になってきます。 以上がデータアナリストとデータエンジニアのスキルセットの比較です。 今後の展望 ここまで、データアナリストからデータエンジニアへキャリアチェンジしてからの半年間についてお伝えしてきました。振り返ってみると、データエンジニアとしてのスキルを少しずつつけることができていますが、今度は開発に集中しすぎてデータアナリストとしての視点を失いつつあるような気がしています。そこで、今後の展望としては「利用者が使いやすい基盤を作る」ことを意識できればと考えています。開発者にとってどんなに美しいデータ基盤を作ったとしても、データアナリストが適切にビジネスサイドへアウトプットしていかないとビジネス的な価値があるとは⾔えません。そうならないために、データアナリストとしての経験もデータエンジニアとしての経験も活かして一気通貫でデータを価値につなげられるような人材になれるよう日々邁進していきます！

By Ikki Ikazaki, MLOps/Data Engineer at Analysis Group This is the last part in a multi-part series on how KINTO Technologies Corporation(KTC) developed a system and culture of Machine Learning Operations(MLOps). Please have a look at Part1( How We Define MLOps in KTC ), Part2( Training and Prediction as Batch Pattern ), and Part3( Metadata Management or Experiment Tracking Using SageMaker Experiments ). Situation The previous post (Part1) discussed the goal and scope of MLOps and I tried to gain understanding from my colleagues. However, just talking about the concept is not enough for engineers and ML practitioners. People establish their skills once they understand both the idea and how. For software engineers, it seemed to be easy to understand the concept and techniques of the B part of Reliable System Integration while for data scientists A part of Project Management With Speed. This difference in understanding and interests makes it difficult to have better communication and thus a bridge over the gap between them was needed. Task The bridge is an opportunity to let them understand each other's interests and methodologies by making an effort together. Conducting a study session on the common ML platform, SageMaker, was expected to be such an opportunity. The goals of study session was set up as follows: To build a good relationship between software engineers and data scientists. To form a common understanding on MLOps and SageMaker. Action I didn't make a presentation but just focused on organizing the study session by planning how we proceed. The basic flow was as follows. Define a scope of contents. Assigned who takes charge of the contents. Give the material to be studied. Prepare for the session by creating slides and notebook in two weeks. Hold the study session. Back to 2) and continue until all the topics have been discussed. First of all, I outlined the study contents. SageMaker is a huge platform and we don't need to catch up on everything about it. The outlined contents are the below seven. The basics of SageMaker and SageMaker Studio SageMaker's Training Job Batch prediction and Endpoints SageMaker Processing SageMaker Experiments SageMaker Pipelines SageMaker Projects (CI/CD) Then, I proposed to colleagues at both my team (Analysis Group) and another team (Platform Group) about the study session. There were four presenters who come together — one is a data scientist and the other three are infrastructure or DevOps Engineers — and I assigned them the above contents. Because of the difference in interests of each role, I took care of who will be in charge of the contents so that all attendees understand the contents without a lot of preparation. Especially, some contents are targeted at engineers such as SageMaker Processing and Projects while some contents are for data scientists such as SageMaker's Training Job and Experiments. About the study contents, since I've read through the entire developer's guide on SageMaker before and this guide is really well-written, I let the presenter read as well by specifying a scope and executing the relevant notebooks. I believe this way of preparation saves a lot of time for presenters to summarize the information and ensures the quality of the sessions because it is already offered by AWS. To be honest, I just wanted to let them know how well the developer guide is prepared. Result All seven sessions were held bi-weekly from November to January. I hope this study session contributed to building common knowledge about SageMaker and understanding about each other's roles. Through the sessions, it was good that one of the DevOps engineers understood how to deploy SageMaker Pipelines and actually he incorporated it into the internal CI/CD program which is based on GitHub Actions. I hope we can talk about how we developed the CI/CD pipeline of SageMaker with GitHub Actions someday. The study session was a really good way to build a shared culture for both software engineering and data science. How about the four-part series of blog posts on how KINTO Technologies Corporation developed the system and culture of MLOps? Follow our Tech Blog for future posts to stay up to date.

自己紹介 KINTOテクノロジーズにてCIO室セキュリティチームのチームリーダーを担当している森野です。 趣味は子ども時代を過ごした埼玉県大宮市（現さいたま市）のサッカーチームである大宮アルディージャの応援です。 最近は機動戦士ガンダム 水星の魔女にハマっていて毎週日曜日午後5時の放映を楽しみにしています。 本記事では先日初参加した 情報セキュリティワークショップin越後湯沢2022 のセッションの中から印象に残った講演を幾つか紹介させて頂きます。 情報セキュリティワークショップin越後湯沢とは 情報セキュリティワークショップin越後湯沢は1998年から年次で開催されている非常に歴史の長い情報セキュリティワークショップです。 2022年は10月7日(金)、10月8月(土)の2日間、デイタイムセッション会場は湯沢町公民館、デイタイムセッション中継・ナイトセッション会場は湯沢グランドホテルで行われました。 越後湯沢と言えばナイトセッション 越後湯沢の名物と言えば美味しい日本酒と温泉。。ではなくナイトセッションです。 例年チケット争奪戦が激しく、私もナイトセッションのチケットが取れず参加を諦めていましたが、幸いにも直前にチケットを譲ってくれる方が現れ参加することができました！ コロナ以前は講演者と参加者が車座となり議論を交わしていたそうですが、今年はコロナが収まっていないため講演者と参加者の距離を置いたセッションとなりました。 しかし、セッション中は参加者から講演者に対して活発に質疑応答が交わされていました。 帰ってきた！セキュリティのアレ in 越後湯沢 私も毎回配信を楽しみにしているポッドキャスト セキュリティのアレ を配信している方々によるナイトセッション。 SBテクノロジー株式会社　プリンシパルセキュリティリサーチャー　辻 伸弘 氏 インターネットイニシアティブ(IIJ) セキュリティ本部 セキュリティ情報統括室長　根岸 征史氏 セキュリティインコ兼協力研究インコ　piyokango 氏 piyokangoさんからは突然発生するサイバー攻撃に翻弄されないように天気予報のように攻撃を予兆することをやりたいというお話がありました。 汎用的なものは難しいかもしれませんが、例えばフィッシング犯罪はフィッシングサイトが実際に立ち上がる前にフィッシングサイトに使用するドメイン取得や証明書取得が行われます。 その活動を捕捉できればフィッシング犯罪の天気予報のようなことが行えるのではとお話を伺いながら思いました。 根岸さんからはCVSS(Common Vulnerability Scoring System)のスコアの高低だけで脆弱性対応の緊急度を判断するのではなく、実際にサイバー攻撃に使用されているのか否かを考慮するべきという問題提起がありました。 CVSSは名前の示す通り情報システムの脆弱性の深刻さを数値化する仕組みです。 参考：IPA 共通脆弱性評価システムCVSS概説 日々、脆弱性情報を収集し自社システムへの影響を判断する者としては算出されたスコアから脆弱性対応の緊急度を計ることができるため大変便利です。 しかし、スコアが低いものでもサイバー攻撃に使用されることがあるため注意が必要とのことでした。 アメリカのCISA(CyberSecurity&Infrastructure Security Agency)がサイバー攻撃に使用された脆弱性を 公開 し随時更新しているので、このような情報を脆弱性対応の判断基準に加えることで、より安心・安全なシステムを提供できそうです。 辻さんは。。途中、他のセッションに参加したため聞き逃してしまいました。。辻さん、ごめんなさい。 フィッシングハンターもたまには温泉で休まナイト 日々フィッシングサイトと格闘している方々によるナイトセッション。 自称イケメンフィッシング詐欺ハンター　にゃん☆たく 氏 ozuma5119 氏 KesagataMe 氏 サイバー侍KAZUMI 氏 講演者の皆さんがフィッシングに引っかかる人が一人でも減るようにSNS等で拡散して欲しいと依頼されていたスライドをこのブログにも添付させて頂きました。 SMSやメールのリンクがフィッシングなのか否か判断することは非常に困難であるため、SMSやメールのリンクはクリックせず、ブラウザのブックマークや検索エンジンの検索結果から目的のサイトに移動しましょう。 若年層のネット活用の現状と、我々ができること 株式会社ラック サイバー・グリッド・ジャパン ICT利用環境啓発支援室　七條 麻衣子 氏 私には中学生の子どもがいるためとても興味深く講演を拝聴しました。 子ども達が専用のスマートフォンを持つ時期ですが9歳の時点で3割に達し13歳の時点では9割に達するそうです。私の想像より遥かに割合が高く驚きました。 若年層のネット活用の特徴について私の知らなかった点は以下の通りですが、共有に関して、スマートフォンアプリを使用してお互いの位置情報を共有するだけではなく、スマートフォンの電池残量まで共有していることには非常に驚きました。 チャット・メッセージでの長文はNG 長文は画像で（メモ帳をスクショ） アカウントの使い分け 高校生の約半数がSNSでは実名登録（仮名だと友だちに見つけて貰えないため） 実況&動画で情報と時間の共有 お話を伺って理解できない使い方や危なっかしい使い方だと感じる点が多々ありました。しかし、理解できないと子どもに伝えるのは禁句で、それを伝えた瞬間に子どもは心を閉ざしてしまうそうです。理解はできなくてもありのままの現実を受け入れなさいとのことでした。 講演後に子どものSNSの使用について相談させて頂いたところ、危ないからといって禁止しても親に隠れて使用するだけで却って危険なため、親の監視の下、安全な使い方を教えながら使用させた方が良いとのアドバイスを頂きました。 脆弱性対応と情報共有～社内バグバウンティ制度の取り組みを通じて見えた事～ エヌ・ティ・ティ・コミュニケーションズ株式会社　林　郁也 氏 ／ 塚越 さくら 氏 バグバウンティ制度とはソフトウエアの脆弱性を発見した方に対して報奨金を支払う制度のことです。 社外の方々に対してバグバウンティ制度を提供する場合、脆弱性を報告してくれた方が信頼できる方なのか否か判断することは非常に難しい問題です。 そこでエヌ・ティ・ティ・コミュニケーションズ株式会社では従業員を対象にバグバウンティ制度を提供することにしたそうです。従業員なら身元が確かなためです。 結果、ユーザの権限昇格が可能な深刻度の高い脆弱性が見つかるなど実際にシステムのセキュリティ強化に役立ったそうです。 副次的な成果として、自発的にグループが結成され勉強会が行われたり、エンジニア職以外から報奨金を得る方が現れるなど、従業員の新たな才能を発見する機会にもなったそうです。 当社でも社内バグバウンティ制度を取り入れてみたいなと感じました。 おわりに 日常業務から離れ様々な略歴を持った方々の講演を拝聴したり、ワークショップで出会った方々とお話させて頂いたことはとても刺激になりました。 記事の中で言及させて頂いた脆弱性対応の緊急度の判断方法はすぐにでも当社の業務に反映していきたいと考えています。社内バグバウンティ制度についてもすぐには難しいかもしれませんが当社にも導入できたら良いなと考えています。 越後湯沢以外にも温泉兄弟と呼ばれる兄弟ワークショップが各地で開催されています。皆さんも参加を検討してみては如何でしょうか。 サイバー防衛シンポジウム熱海 サイバー犯罪に関する白浜シンポジウム サイバーセキュリティシンポジウム道後 九州サイバーセキュリティシンポジウム

こんにちは。分析グループ(分析G)でMLOps/データエンジニアしてます伊ヶ崎( @_ikki02 )です。 こちらは「KINTOテクノロジーズ株式会社にてどのようにMLOpsを適用していくのか」というテーマでの連載最終回です。1本目の記事「 KINTOテクノロジーズのMLOpsを定義してみた 」、2本目の記事「 SageMakerを使った学習&推論のバッチパターン 」および3本目の記事「 SageMaker Experimentsを用いた実験管理 」はそれぞれのリンクよりご確認ください。 背景(Situation) 1本目の記事では、MLOpsの定義とスコープについて紹介しましたが、一緒に働くメンバーと理解をすり合わせる活動にも取り組んできました。 エンジニアやデータサイエンティストといった異なる職掌がいる中で共通理解を得られるように布教するのは実際難しかったです。勉強会開始時点では、1本目の記事で紹介した図で言うと、ソフトウェアエンジニアは「(B) 信頼性を高めるシステム連携」の項目（推論基盤やIaC、CI/CDなど）が得意な一方、データサイエンティストは「(A) PJ管理・高速化」の項目（学習基盤、メタデータ管理（実験管理）など）に対する前知識があったように思います。このような背景や興味関心の違いは、ワードチョイスに微妙な違いがあったり、議論が右往左往してしまうことに繋がったりするように感じました。概念や用語の共通認識とそれを実装する方法を共有し、お互いの認識の差異を吸収する機会が必要だったように思います。 業務(Task) その機会として勉強会を企画しました。共通の機械学習基盤たるSageMakerについてお互いが学び合う機会となることを期待したのでした。 ゴールとしては以下のように設定しました。 MLOpsを進めるにあたって関係者の関係構築 MLOpsおよびSageMakerに対する共通理解の形成 やったこと(Action) 私個人としては企画とファシリテーションに集中したかったのと、コンテンツの習熟をメンバーに促す趣旨から、コンテンツの準備に焦点を当てました。具体的な勉強会開催の流れは以下の通りです。 勉強会のスコープ策定 各勉強会の担当者割振。担当分のコンテンツ共有 勉強会用スライドおよびノートブックの作成準備（隔週開催） 勉強会開催 2に戻る まず「勉強会のスコープ策定」を実施しました。SageMaker全体をスコープにすると膨大な量になるため、以下の7つの項目に絞りました。 SageMaker全体像およびStudioの概要 訓練ジョブの作成 推論の実行(バッチ推論と推論エンドポイント) SageMaker Processing (ETL特化のジョブ) SageMaker Experiments (実験管理) SageMaker Pipelines (パイプライン) SageMaker Projects (CI/CD) 上記スコープを分析グループおよびプラットフォームグループのメンバーに提案し、4名のプレゼンター(データサイエンティスト1名、インフラ&DevOpsエンジニア3名)が集まりました。バックグラウンドの異なるメンバーが集まった中、なるべく準備に負担をかけずに一定の品質を担保したかったので、それぞれの得意領域を意識して、各勉強会の担当者を割振るようにしました。具体的には、「訓練ジョブ」や「SageMaker Experiments」はデータサイエンスの業務プロセスの理解が必要だったためデータサイエンティストへ割当て、「SageMaker Processing」や「SageMaker Projects」はコンテナ周りやCI/CDの知識が背景に求められるためエンジニアにお願いしました。 また、勉強会のコンテンツとしては、AWS公式のドキュメントである「 developer guide 」とそこに掲載されている「 SageMaker関連のサンプルノートブック 」を土台として作成を依頼しました。公式のドキュメントは画面のスクリーンショットやサンプルコードの掲載など、本当によくできているので（ 日本語の機械翻訳が面白いことがあるのはご愛嬌 ）、イチから新たに作り直すというよりは、そこにある内容を各個人の理解に合わせて切り貼りしてまとめてもらうのが良いと考えています（個人的にはdeveloper guideの良さを布教しつつ、一次ソースの引用癖を付つけていくのも狙いでした）。 結果(Result) 上記の内容で、2021年11月〜2022年1月までの期間で隔週開催しました。嬉しかったのは、勉強会後、参加メンバーがSageMaker Pipelinesのデプロイ方法を習熟し、社内で開発運用しているGitHubActionsのCI/CDのSageMaker版を構築したことでした(この連載でも触れたバッチパターンのCI/CD基盤としても活用しており、SageMaker Projectsとの差別化のお話などもいつかこちらのテックブログでご紹介できればいいなと思います)。 個人の想いとしては、ソフトウェアエンジニアリングとデータサイエンスという様々な知識や役割を超えて共通認識を構築していく勉強会は改めて大切な取組みだなと感じており、この勉強会が目的通り共通認識の形成と関係構築に少しでも貢献できていたらよいなと思います。 いかがでしたでしょうか？ 本掲載にて「KINTOテクノロジーズ株式会社にてどのようにMLOpsを適用していくのか」というテーマでの連載は一旦最終回を迎えますが、プロジェクト的にも組織的にもまだまだ変化の多いフェーズのため、MLOpsも進化を続けなければなりません。プロダクト開発に機械学習を組込む取組み、そして価値提供を改善し続けていく取組みはまだまだ始まったばかりなので、引続きアップデートをお伝えしていければと思います(本テックブログのTwitterもありますのでフォローしてくれると嬉しいです)。

こんにちは。Woven Payment Solution開発グループの小野です。 私達のチームは Toyota Woven City で使われる予定の決済プラットフォームの開発を行っています。少し古い内容ですが、私達のやっていることについてはこちらをご覧ください。 20220422 Woven City Tech Meetup Tech Talk by Rie Ono 今回は私達の決済システムを設計する際に利用したDDDのモデリング手法の一つ EventStorming を使っています。まだ研究途中なのですが、現時点で分かったことをご紹介しようと思います。 EventStorming とは Alberto Brandolini さんが提唱したシステムをモデリングするためのワークショップ形式の手法です。 EventStorming のサイトを参照すると、以下のように書かれています。 EventStorming is a flexible workshop format for collaborative exploration of complex business domains. (意訳）Eventstormingとは複雑なビジネスドメインを協業的に探求するための柔軟なワークショップフォーマットです。 また、 Learning Domain-Driven Design のChapter 12.EventStorming には以下のように書かれています。 EventStorming is a low-tech activity for a group of people to brainstorm and rapidly model a business process. In a sense, EventStorming is a tactical tool for sharing business domain knowledge. (意訳）EventStormingはメンバーからアイデアを引き出し素早くビジネスプロセスのモデルを形作るためのローテクなアクティビティです。もう一方ではEventStorming はビジネスドメインの知識を共有する戦術的なツールです。 つまり、以下のような目的のためのワークショップです。 難しくないやり方でドメイン知識を有識者から引き出す ステークホルダーへドメイン知識を共有する ドメインモデルを設計する EventStormingのための準備 誰に参加してもらうのか？ 上記の Learning Domain-Driven Design には参加者の人数は10人以下が望ましいと書かれています。人数が多すぎると発言に躊躇したり、意見をまとめにくかったりするかもしれません。 また異なったバックグラウンドの人を集めることでいろいろな発見があるかもしれない、と書かれています。それらを踏まえると、参加する人を選ぶのが最初の難しい課題になるかもしれません。 ファシリテーター フェーズごとに時間を区切ったり、途中で話が広がりすぎたりしないように調整するファシリテーターがいると良いです。私達の場合は、設計を行うエンジニア自身が担当しました。 エンジニア アプリケーションを設計・開発するエンジニア。 私達の場合は当チームのメンバーに加え、ネイティブアプリを開発するアプリチームのメンバーにも、ドメイン知識を共有する目的で参加していただきました。 ドメインエキスパート ドメインエキスパートは対象のドメインについて深い知識を持つ人です。既存のシステムや他社のビジネス、その分野に詳しい人を集めましょう。EventStormingの目的としてはソフトウェアの設計のための他に、ドメインエキスパートの人たちから知識を吸い出すことにもあります。 私達の場合、幸いなことにビジネスチームには決済業務に携わってきたメンバーが多く在籍しており、協力していただけることになりました。 また、私達のチームをリードしている亀井は過去に決済分野に携わっており、決済とエンジニアリングの両方の視点から指摘ができる方です。 UI/UXデザイナー、QAエンジニア 今回は実現できなかったのですが、できればアプリケーションの開発に関わるUI/UXデザイナーとQAエンジニアも含まれていると良いと思います。業務知識を共有してUI/UXやQAの設計の効率化が図れます。 準備するもの EventStormingは時間がかかります。事前の準備をすることでスムーズに進行できるようにしましょう。 参加者のスケジュール確保 参加者の時間をできれば1日か半日は抑えたいところです。いろいろなチームから人を呼ぶので、全員が参加できるスケジュールを押さえるのが困難とおもいますが、重要です。 場所 やはりオフラインだと発言がしやすい気がします。 いろいろな色の付箋 図のような色の付箋を準備します。 ホワイトボード・マーカー 付箋を貼っていく大きいホワイトボードとマーカーを準備しましょう。 リラックスのためのお菓子や飲み物 を準備…したかったのですが、感染症対策のため断念しました。 前提の知識 EventStormingを開始する前や、事前のテキストコミュニケーションとして、今回作ろうとしているシステムの目的、前提、すでに決まっている事項など、を共有し、ある程度の前提知識を持ってもらいました。 また、初対面同士の参加者が発言しやすいように、それぞれの簡単な自己紹介時間を用意しました。 今回は英語でEventStormingを行ったので、ファシリテーションのやり方やドメイン知識についての英単語を事前に調べておきました。 感染症予防のため対面時間を短縮する方法を考えてみた Alberto Brandoliniさんは Remote EventStorming で、リモートで行うのは難しいという旨を書かれています。ですがこのご時世なので、オンラインでもできないか試してみました。 オフラインで実施する場合は、感染症対策のために、密にならない程度に広く、それでいて集中できる会議室や広場を準備しましょう。 オンラインで実施する場合は Miro が便利でした。 使いやすいテンプレートがあります。 Judith Birmoser's Event Storming template | Miroverse 対面時間を短くするために、少人数メンバーで後述のPhase2までたたき台をつくっておきました。実施時には全参加者にレビューしてもらい、足りない箇所を追加してもらったり、間違っている箇所を指摘してもらいます。 やってみた ここからはEventStormingをどのように進めたかを書いていきます。 Phase1 : Big picture まずはビジネスプロセス全体を明らかにするため、Big Pictureをつくっていきます。 ブレインストーミングしながらドメインイベントをオレンジ色の付箋に書き出していきます。例：「決済が行われた」 各ドメインイベントについて意見を出した人に説明してもらい、重複したものを取り除いたり、正しい理解かをドメインエキスパートに確認したりして、リファインメントし、時系列に並べなおしていきます。 Phase2: Process Modeling 次に、Event間のプロセスをモデリングしてきます。 洗い出したEventに以下の付箋を追加していきます。 Actorを黄色で追加します。 誰が、または何がコマンドを実行するのかを考えます。 Eventの原因となるコマンドを青色で追記します。 View modelができるならばを緑色に書き出します。 Policyを紫色で書き出します。このPolicyの考えが私としては難しいと感じています。コマンドの前提や条件を書き出すみたいです。 なにか疑問やリスクになりうる事項があれば、赤色の付箋に書き出しておきます。 ドメインエキスパートには、イベントの内容や時系列が正しいかチェックしていただいたり、質問に答えていただきます。 Phase3: Software Design 次に、まとめられそうなコンテキストについて詳細に考えて行き、コーディングが始められる状態にしていきます。 ビジネスドメインとしてデータの整合性が保てる範囲としてまとめられそうな箇所をAggrigate（山吹色）としてまとめてみます。 外部システムを介す場合はピンク色で追加します。 サブドメインとしてひとまとまりにできそうな箇所を区切ってみます。 この時点でUIが定義できそうならば、ペーパープロトタイプを作ってみるのも良いと思います。 だいたい出来上がって来たら、赤色の付箋について詳細にディスカッションしてみるか、すぐに結論が出せないならば、そこを別の機会に深堀りEventStormingします。 その後 ここまできたら、抜け漏れがないか、逆順にたどっていきます。 Software design as a cooperative game with EventStorming また、私達の場合は全体のドメインを洗い出したあと、スコープを絞って更にEventStormingを行ったりしました。 やってみた感想 以下は、EventStormingをやってみてよかった点です。 業務を知っているであろう人に、個々にヒアリングに行って要求や仕様を作成するよりも網羅的、偏らない、事業把握ができる。かえって時間がかからないかもしれません。 いっぺんで数人のメンバーへ知識の共有・確認ができるのも良い点だと思いました。 一度やってみて、ゼロから何かを作るときにやると効果が大きいだろうな、と思ったのですが、考えているものの答え合わせという効果もあると感じました。 副産物として、 モデリングをするうちに、忘れていた・見えなかった課題が見つかった その業務内容を初めて知るメンバーによる初心者目線での疑問が課題提起となる場合があった 普段、あまり顔を合わせることのないメンバー間でのつながりを作ることができた 以下は難しかった点です。 時間がかかるので、メンバーのスケジュールを抑えること、加えて、集中力を持続させるのが難しいと感じました。 ファシリテーションが難しい。これは慣れの問題であるので、回数を重ねていけば解決するかもしれません。 また、自分としては英語でファシリテーションをしたりディスカッションをするのも大変で、練習していきたいと思っています。特にドメインエキスパートの方々は日本の商習慣に特化した決済についての説明を英語で行うのは、かなり大変だったと思います。 これからの課題 これからもEventStormingができる機会があれば、回数を重ねてエンジニアメンバーがEventStormingをファシリテートできるようになれば良いと思っています。 また、このEventStormingで洗い出せたドメインを実際のコードに落としていくステップをもう少し研究したいです。 例： ドメイン記述ミニ言語 に落としてみる イベントソーシング への応用 以上、EventStormingをやってみた感想でした！

By Ikki Ikazaki, MLOps/Data Engineer at Analysis Group This is the third part in a multi-part series on how KINTO Technologies Corporation(KTC) developed a system and culture of Machine Learning Operations(MLOps). Please take a look at Part1( How We Define MLOps in KTC ) and Part2( Training and Prediction as Batch Pattern ). The fourth and final post will discuss "Benkyo-kai", a series of internal study sessions, to form the common knowledge about SageMaker and MLOps with other departments. Situation As we have already gone through the reason why metadata management is needed in Part1, this chapter will focus on the situation in KTC. Since it has been only four years since the establishment of KINTO Corporation, it was urgent to build relationships between the business and data science teams by presenting a clear output quickly. Sometimes this leads to sacrificing the code quality or documentation, which causes the data science process to be essentially a black box. This approach is not bad at the initial phases of a project, but now the situation has changed and the number of data science projects and members are increasing. We started to look for a better way of management. Task The key concepts of metadata management are "sharable format" and "easy tracking". Since there are a few data scientists in our team, we need to have a common format so that the team can manage their work in a standardized way. The aim of having a common format is that every data scientist can reproduce the model building process and its results. This means they need to track the development environment, the data they use, code scripts, ML algorithm, hyperparameters, etc. There is a trade-off between a common format and easy tracking because the more you leave the records for others to easily understand, the more effort is needed. It is ideal if the information that shows up repeatedly such as the container image name, execution time, data storage path, and more is recorded automatically. With SageMaker Experiments, once you write down the definition of SageMaker Pipelines, the information about the development environment is automatically integrated and so the data scientists can focus on the metrics they really want to track. The way of tracking is possible by a few lines of code using SageMaker SDK, so the effort for implementing the tracking is minimum. Action Naming Convention It is a good start to introduce the managed service for metadata management, but just using it is not enough. SageMaker Experiments is actually composed by small fragments called Experiment and Trial where Experiment is a group of Trials which usually represents a specific use case while Trial stands for each iteration of ML processings. Then, a proper naming convention is required to manage those components so that data scientists can refer to each other's projects or iterations. The below table of naming convention about SageMaker Experiments is used in our team. We consider that metadata management is required mainly on occasions: Experiment of pipeline and Experiment of EDA(Exploratory Data Analysis). Experiment of pipeline is used to track the information about every step of pipeline used in production, so it offers the possibility to reproduce when the pipeline fails somehow. By following the naming convention above, you can find the environmental information at 1.1's Trial — SageMaker Pipelines automatically creates this trial —, and analytical information at 1.2's Trial — you need to create this trial on your own in the pipeline. Also, it is often the case that data scientists want to track their experimental code and model outcomes outside of the production pipeline. Then Experiment of EDA allows them to track the information flexibly. The naming convention of this type is also flexible compared to the Experiment of pipeline, but it may be updated in the future once we find the pattern in experiments. Result Utilizing the managed service is good because there is the benefit of "Standing on the shoulders of giants". SageMaker Experiments provides us with the way of metadata management and analysis on it. By looking up 1.2's trial of Experiments of pipeline, you can inspect the metrics of the model building pipeline. You can even create pandas DataFrame of the Experiments and analyze the time series of its trials. For example, if you track the precision rate at every pipeline execution, you can make a line chart to see the historical change in the metrics. It is useful to detect what is called "model drift" in advance. The sooner you detect some type of anomalies, the faster the ML continuous training process begins. What do you think about this article? Next time, the last post of this four-part series will introduce "Benkyo-kai" and how we share technical knowledge in our company( now available ). Please follow the KTC Tech Blog for future posts to stay up to date.

Introduction As someone who grew up living between two cultures -Spain and Japan-, I have always been passionate about cross-cultural communication. My name is Maya Sakakibara and as the lead of language localization at KINTO Technologies, the topic I would like to introduce to you in two parts is precisely that: localization. The objective of these two articles is to share with you the importance of it through my studies and current experience, hopefully making you a little bit more interested on this topic in the process. In this first part, I will go through key concepts and how we tackle language localization in our company, and on the second part, I will delve deeper into what we have been up to so far at KINTO Technologies. What are translation, localization, and internationalization? You will find many definitions of translation , but one of many that resonates with me is the following from Hatim and Mason (1997) who considers translation as "an act of communication which attempts to relay, across cultural and linguistic boundaries, another act of communication." Localization (l10n) on the other hand, is adapting the way messages, stories, and ideas feel natural to the intended audience's local language. But to be able to do so in the context of software development, we first need to prepare the code or make all the product and development decisions needed to accept variations so that terms can be easily adapted and localized later to any language. This process is what we call internationalization (i18n). My task is to take care of the wording aspect, but it is worth noting that localization in the broader sense of the term also encompasses the design aspect. Due to this, what we do internally is to work closely with UI/UX writers, designers, and engineers to bring the best experience possible to our target audiences.  If you want a fun example of word-unrelated localization you can check how certain smartphone apps will shift their date format, layouts and icons when you change your default language from English to Arabic. Localization in KINTO Here at KINTO, we are trying daily to apply kaizen (improvement) principles and think of better ways to maintain a collaborative environment. It is important for us to integrate the translations into the overall CI/CD (continuous integration and continuous delivery) process. In slightly more detail, I would like to explain a bit about how language localization is done for our products by first applying i18n. Take the below English screen of our app :  The premise is to have a base language implemented and deployed; in our case it's English. Up next is to determine how to manage the data. The data type of software translations, such as the ones for an app or webpage is often stored as a key-value pair. For the sentences used in this screen (the logo and the copy on top are excluded from our localization scope), the data of the English terms will look as below in our English "localizable.strings" file for iOS: <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> To localize we will create separate files for each display language, away from the code. As of October 2022, we have Japanese, Thai, and Arabic files for the app, and those files will all contain the same translation keys[^1], but with the terms in the corresponding languages. For instance, our Arabic "localizable.strings" file has its homologous data stored as follows: [^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> As you can see, the keys are the same if you compare them both. By specifying keys as the first parameter, this method allows the app to pull the corresponding value from the localization file and display the localized value according to the language that the user specified. For our example, when switching the language setting from English to Arabic, our previous screen will be shown as such: That is in essence the mechanism of how we proceed with language localization, regardless of file type and platform. If you would like to keep reading about what the localization team has been up to, please check out my next article! See you in the next one! References and further recommended readings 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 >

はじめに グローバル開発グループの森です。普段は Global KINTO Web のPdM 兼 グローバル開発Gでの個人データ関連法の窓口を担当しています。 KINTOは日本国内のみではなく、関連会社やパートナーによって、世界中30か国以上にサブスクリプションやレンタカーなど様々なサービスが展開されています。 Global KINTO Web ではその一覧をご確認いただけますので、ぜひご確認ください🔎今回の記事はサービスをグローバルに展開する上で避けては通れない各国の個人データ関連法に対応したお話です。 ※グローバル開発グループはKINTOテクノロジーズの所属ですが、開発した製品は親会社である トヨタファイナンシャルサービス株式会社 のアセットとなるため、本法令対応はトヨタファイナンシャルサービスとして対応しています。 背景 KINTOは「Ever Better Mobility For All」をブランドプロミスとして、世界中の方々にシームレスな移動体験を提供すべく、日々製品・サービスの開発を行っております。世界中のKINTOサービスをシームレスにご利用いただけるよう、各サービスのIDを連携させる仕組み 「Global KINTO ID Platform (GKIDP)」 を提供しています。詳細について本記事では割愛しますが、このGKIDPを利用することで、A国のKINTOユーザーがB国のKINTOサービスを同じIDで利用できるようになります。つまりあらゆる国の間でKINTOユーザーの氏名やメールアドレス等、個人データの移転が発生します。 尚、「個人データ」とは、国によって定義が異なり、例えばGDPR上の「個人データ」は以下のように定義されます。 個人情報保護委員会は「識別された自然人又は識別可能な自然人（「データ主体」）に関する情報」と訳しています。 氏名のように単体で個人を識別できるものだけでなく、組み合わせることで、個人を識別できるデータも対象になります。 引用： 【用語解説】GDPRとは？個人データを守るための重要ポイント｜CX Clip by KARTE また、欧州経済領域 (EEA、以下、欧州)のGDPR (General Data Protection Regulation)や、米国ではカリフォルニア州のCCPA (California Consumer Privacy Act)等、各国で強力な個人データ関連法が制定されており、日本国内でも2022年4月に改正個人データ関連法が全面施行されるなど、個人データ保護を強化する動きは世界中で加速しております。欧州を中心に規制当局によって名だたる企業が法令違反の指摘を受け、高額な制裁金を科されています。 参考： 高まるプライバシー保護の重要性--GDPR違反による高額な制裁金を振り返る こういった世界中の動きの中、各国KINTOサービスへGKIDPを提供する上で各国の個人データ関連法への対応をすることとなりました。 GDPR準拠とグローバル展開時の課題 1. Data Transfer Agreement Data Transfer Agreement (DTA) とは、個人データを別の管轄区域や組織に送受信する際の条件を定めたAgreementで、サインした事業体間の個人データ処理およびグローバルなデータ転送をカバーすることを目的としております。今回、我々はグローバルに個人データを送受信することを想定し、”Global Data Transfer Agreement (GDTA)"のフレームワークを整備しました。 GDTAの構成 内容 Agreementのスコープ Projectの説明とGDTAの範囲を記載 各事業体の役割と責任 役割の定義と責任の範囲を記載 附従契約条項 他のKINTOサービス提供者がGDTAに参画することを認める条項 別紙 想定される役割と処理のシナリオをカバーする条項を含む GKIDPに参画する各社はこれにサインせねばならず、新しい事業体がGKIDPに参画する場合に以下のステップが必須となります。 ✅ 各事業体の役割を特定し、GDTAにサイン ✅ ユースケースを考慮した個人データのグローバル移転に関するリスクレベルの評価 ✅ 適切なデータ転送メカニズムの適用 2. 役割の定義 個人データを処理する上でGDPR上では以下の定義がされており、各事業体はそれぞれの役割を定義した上で適切な契約が必要です。 役割 定義 管理者 (Controller) 単独または共同で個人データ処理の目的と手段を決定する 管理者はデータ処理の適法性の責任を負いGDPR違反に対する責任を負う 処理者 (Processor) 管理者を代理して、個人データの処理を行う GKIDPの場合は以下のような整理から、GKIDPに関わる全ての事業体を 「共同管理者 (Joint Controller)」 と位置付けます。 各KINTOサービスを展開する事業体（各国KINTOサービス提供者） GKIDPを開発し、ユーザーデータを管理する事業体 (トヨタファイナンシャルサービス) 3. ユースケースとデータ移転 個人データを移転するにはその国が十分な規制を持っているかなどの評価が必要です。例えばGDPRのケースでは、 欧州から見て十分な法令を所持していると認定（十分性認定）された国 はその認定をデータ移転の根拠とすることができます。一方で、認定を有していない国に関しては別途Standard Contractual Clausesを締結するなどの処置が必要です。 EU域内から域外へ個人データを移転するには、 十分な個人データ保護の保障 （欧州委員会が、データ移転先の国が十分なレベルの個人データ保護を保障していることを決定） BCR（Binding Corporate Rules：拘束的企業準則）の締結 （企業グループで1つの規定を策定し、データ移転元の管轄監督機関が承認） SCC（Standard Contractual Clauses：標準契約条項）の締結 （データ移転元とデータ移転先との間で、欧州委員会が認めたひな形条項による契約の締結） 明確な本人同意 等、一定の条件を満たさなくてはなりません。 引用： GDPR ｜個人情報保護委員会 その上で、今回我々は各ユースケースごとに以下の整理としました。 ユースケース 移転根拠 欧州域内の事業体間 欧州域外にデータ移転が無いため、GDTAに参画するのみ 欧州→十分性認定の ある 国 十分性認定を根拠として、欧州域外へのデータ移転が可能 ※ 欧州の十分性認定がある国一覧： GDPR ｜個人情報保護委員会 欧州→十分性認定の ない 国 GDPRに基づいて、GDTAに付随する形でStandard Contractual Clauses(SCC) ^1 とTransfer Impact Assessment (TIA) ^2 にサインをした上でデータ移転が可能 4. 欧州GDPRに基づくSCCとTIA 欧州から「十分な法令を有していない＝十分性認定が無い」と判断される国は、欧州のデータを自国に移転させるためにStandard Contractual Clauses (SCC)を締結した上で、さらにそのデータ移転をTransfer Impact Assessment（TIA）にて評価する必要があります。GKIDPに参画いただく事業体にも、この必要性を説明した上でそれぞれサインするように動いています。 今回は詳細は割愛しますが、機会があれば別の記事でお話します。 参考： 個人データの第三国への移転のための標準契約条項に関する2021年6月4日付欧州委員会実施決定（EU）2021/914 今後の課題 上記１～４のステップを踏み、それぞれサインをしてようやくデータ移転が可能となります。このプロセスを形にするために、GDPRの当事者としてイタリアと実際のGDTAのドラフトを含んで１年近くかかりました。今後はこのステップに則ってGKIDP参画事業体との契約を進めます。 上記はあくまでGDPRを基準にして記載しましたが、他の国にもデータをグローバルに移転させる上で必要な文書が存在する可能性があります。連携サービスが増える度、それぞれの法令とGDPRの差分を調査し、対応を進めて参りました。今後、KINTOがEver Better Mobility For Allを世界中に提供できるようになるためには、更に多くの国へ導入が必要となりますので、それぞれの国が持つ法令への遵守します。 さいごに このプロジェクトには入社したての頃にアサインされ、それまでGDPRはおろかプライバシーポリシーすら流し読み程度でした。そんな私が今ではグローバル開発グループの個人データ関連法窓口として、内部メンバーの質問に答えたり、社内のセキュリティチームなどの有識者と専門的な会話ができたりするようになったのは、「自ら知識を得ようとする人を歓迎・評価する風土」がKINTOテクノロジーズ内にあったからです。これからもこのような風土の中で個人データ以外にも自身のスキルアップに努めたいです。 尚、GDPRについての詳細は、インターネット上でも様々な記事が公開されておりますが、私は以下を参考にしていました。情報がまとまっていてとてもわかりやすいです。もちろん、素人だけで対応するのは危険なので、有識者からの意見は大事です 👨‍⚖️ 出典： 牧野総合法律事務所弁護士法人 / 合同会社LEGAL EDGE (2019) 図解入門ビジネス 最新GDPRの仕組みと対策がよ～くわかる本 個人情報保護委員会 An official website of the European Union

はじめに モバイル開発グループの日野森、木下、中口で、 iOSDC Japan 2022 に参加しました。2年ぶりにオフラインイベントが開催して、オンライン配信とオフラインのハイブリッドでしたので、それぞれの状況に合わせて参加しました。 本記事では参加した感想、印象に残ったトークを紹介します。 感想 日野森 ​ まず初めに、僕は今年で５年目の参加になりますが、毎年ノベルティがすごいですね！ パンフレットも年々分厚くなってるので、時間がある時にゆっくり眺めたいと思います。 定番のTシャツは今年もおしゃれなデザインで早速家着として着倒しています。 ノベルティ パンフレット   今年は３年ぶりのオフラインとオンラインの同時開催でしたが、 育児世代の僕は休日に１日外出は厳しいので、泣く泣くオンラインで試聴しました。 ​ （ニコニコ生放送での視聴期間は 2022/10/12(水) 23:59 までのようなので、未試聴の方は忘れずに。） ​ 今回も気になるセッション盛りだくさんでしたが、今回はSwiftUI周りのセッションの話をしていきたいと思います。 ​ ウーニャ、しってる。みんなふんいきでSwiftUIをつかってる。 Viewの分割のケーススタディがとても参考になりました。ルールをドキュメント化するのは大事ですが、ドキュメントが見やすいところにあるかも大事なのかなと思いました。 SwiftUI Navigation のすべて pointfreeさんのswiftui-navigationの話はとても良い情報でした。NavigationStackまでの繋ぎで使えそうな感じがします。 UIKit ベースの大規模なプロジェクトへの SwiftUI 導入 すでにリリースされているアプリをUIKitからSwiftUIに切り替える辛みが伝わる内容でした。iOS13初期バージョンはやはり鬼門ですね。 SwiftUIとUIKitを仲良くさせる UIKitとSwiftUIが混ざった状態での実装の注意点や対応方法についてのお話でしたね。まだまだUIKit <-> SwiftUIを行き来することが多いので、参考になりました。 ​ iOS16がリリースされ、多くのアプリの最低動作OSがiOS14に上がり、本格的にSwiftUIを使用する事を検討するタイミングだと思うので、関係するセッションも多く見掛けられました。 弊社でもこれからどんどんSwiftUIへシフトチェンジしていく予定ですが、やはり、過去のOSバージョンを加味するとフルSwiftUIでアプリを作成するには色々と乗り越えないといけない課題がある様なので、まだまだ注意が必要ですが、今回得た知見を元に弊社でも知見を増やしていきたいですね。 木下 iOSDCには、練馬で開催されたときから毎年参加していて、今年のナレーションもとても豪華でした。例の声を聞くと、帰ってきたなと思い出に浸れました。 今回のiOSDCで、個人的に覚えているセッションは以下になります。 Unreal EngineとiPhoneを使って始めるリアルタイムAR配信 頭のスッキリとした朝に視聴したことや、日々の先行開発としてPoCを回している業務中でUnityのライブラリを使ってUaal with Flutterを試していたこともあり、このセッションが記憶に残りました。Uaal with Flutterについては、今回は深く触れず、機会があれば別のブログ記事で紹介できればと思います。 セッションの発表者の記事や資料は、以下の登壇者の方のブログ記事にあります。 iOSDC 2022に登壇しました 様々なプラットフォームで実績のあるUnityではなく、Unreal Engineを用いた事例だったため珍しく、とても興味深かったです。 冒頭のリアルタイムAR合成のデモシーンでは、きれいに投影されていてニコ動のコメントも盛り上がってました。 3Dレンダリングソフトをモバイルに組み込んで扱いやすくするという情報は、少ない割に需要があると個人的には感じます。 Uaal with Flutterでアプリを作成しているときも、情報にあまり触れることがなかったこともあり、Unreal Engineができるなら試したかったので、もっと早く知れたらなと思いながら視聴していました。 世間的にメタバースがもっと盛り上がってきて、どんどんこの辺りの知見が溜まって、共有されていったら面白いと思いました。 また今回のiOSDCでは、会場でお弁当や飲み物の提供はなかったので、早くコロナが収まって、どぶ漬けが復活してくれることを願ってます。 会場の参加者と恒例のアレを片手に乾杯できるiOSDCが戻ってくることを楽しみに待っています。 運営スタッフの皆様、今年もお疲れさまでした。 また来年もよろしくお願いします！ 中口 iOSエンジニアとしてのキャリアは 約2年で、iOSDCに本格的に参加したのは今回が初めてとなります。最近、ようやくMVVMやCombineに慣れてきたところだったので次のステップとしてSwiftUIやConcurrencyを勉強していきたいなと考えていたところでした。今回のiOSDCでは、それらの内容のセッションが多く大変参考になりました。書籍や技術記事など文字ベースのものだけではなかなか理解しにくい部分も多くいのですが、発表で聞くとクリアになる部分もありました。今後も、発表を復習してさらに理解を深められたらと思っています。 ウーニャ、しってる。みんなふんいきでSwiftUIをつかってる こちらのセッションでは、SwiftUIの中でも特に分割に関する内容を発表されておりました。 どのように分割していくかは絶対的な正解があるわけではないからこそ、非常に難しく悩ましい部分かと思いますので大変参考になりました。 また、非常に大事だなと感じた考え方として「言語化する」、「プロジェクトごとにルールをドキュメント化する」といったことを挙げられており、みんなが悩む部分だからこそしっかりと明示する必要があるのだなと感じました。 Swift Concurrency時代のリアクティブプログラミングの基礎理解 上記で述べた通り、Concurrencyに関しては勉強を始めたばかりということもありそもそもの有用性のようなものがあまり理解できていませんでした。 こちら発表ではいわゆるモバイルアプリのリアクティブプログラミングからConcurrencyに置き換えることができる場所とそうでない場所を明示していただけたので、Concurrencyの使い所が明確になりとてもスッキリしました。 Concurrencyは、可読性の高さからなるべく取り入れていけたらと思うのでこちらの発表を参考にしていきたいと思います。 おわりに iOSDC Japan 2022は、とても楽しかったです！ iOSDC Japan 2023年に皆さん、またお会いしましょう！ 2023年まで待てない方は、ぜひ KINTOテクノロジーズの採用情報 をご覧ください。 エンジニアに限らず、絶賛募集中です。 入社して会えるのも待ってます！