こんにちは KINTOテクノロジーズ モバイルアプリ開発Gの小山です。 モバイルアプリの開発・運用に携わっています。担当はiOSです。 今回はGlobal KINTOのモバイルアプリ開発の中でMVVMを採用した内容を紹介したいと思います。 MVVM と Combine 話をする前にまずこれらについて軽く説明をしておきたいと思います。 MVVM ソフトウェア開発におけるアーキテクチャのひとつです。 MVCモデルの派生系で Model-View-ViewModel という構成を取ります。 細かいことを言うとややこしいので簡潔に示すと、 Model データをひとまとめにした存在であり、データのまとまりと簡単な処理を担います。複雑な処理は行いません。 View 画面描写を担う存在です。画面を生成するのに必要なデータを受け取り、ただ描写します。 ViewModel ModelとViewの中間地点の存在で、複数のModelのデータをまとめたり、Viewの状態を保持するための値を持つ役割を担ったりします。 といった感じです。個人の見解です。 ただこれでもiOSやり始め当初の私には理解が難しかったです。 そこでiOSの開発に当てはめるとこんな感じになります。 Model 扱うデータをただひとまとめにします。基準として辞書型を採用するくらいならModelを一つ作ります。Model内のデータに関わるシンプルなメソッドのみを持ちます。 View ViewControllerや個別のViewがこれに当たります。描写に関わるコーディングのみ行い、データの操作は行わず、受け取ったデータをただ描写します。基準としてif文が全くない状態を目指します。 ViewModel ViewControllerからトリガーを受け取ってデータを返却します。ViewControllerとは1対1で、個別のViewに関しては場合によって上位のViewControllerのViewModelが役目を担っても良いです。 これを実現していきたいと思います。本記事の中では特にViewとViewModelの分割をご紹介したいと思います。 Combine 2019年の6月に登場した、Apple公式のリアクティブアーキテクチャを実現するフレームワークです。 それまではリアクティブアーキテクチャを実現するにはサードパーティ製のRxSwiftを使うことがほとんどでしたが、公式でサポートの厚いライブラリがリリースされました。 ちょ、ちょっと待ってリアクティブアーキテクチャってなんだっけ と、思った方もいるかと思います。 私がそうでした。Wikipediaによると以下の通りです。 reactive programming is a declarative programming paradigm concerned with data streams and the propagation of change. -- Wikipedia | Reactive programming これを和訳すると以下の通りです。 データストリームと変更の伝播に関係する宣言型プログラミングパラダイムです。 いまいち分からないですね。 こちらもややこしくせず理解するには、表計算ソフトをイメージすると良いと聞いたことがあります。 以下のような簡単な計算式を入力したとします。 A B C 10 20 =A1+B1 これを入力完了するともちろんC1セルに計算結果が入ります。 A B C 10 20 30 この状態でA1セルを20に書き換えた場合はどうなるでしょうか。 A B C 20 20 40 もちろんC1セルが40に書き変わります。 このようにA1の変更に対応してC1に直接手を加えずに変更を伝播させていくことを、リアクティブアーキテクチャと呼びます。 初めにデータ処理の宣言（ =A1+B1 ）のみを行い、最後に実データを流す（A1に20を代入）、といったイメージが私はしっくりきました。 背景 前置きが少々長くなりました。我々がなぜCombine、MVVMを採用するに至ったかという話です。 Global KINTOの開発案件を担当した当初、外注していたソースコードを内製に切り替えて間もない状況だったこともあり、既に出来上がっている部分はいわゆるスパゲッティコードの状態でメンテナンス性が非常に悪い状態でした。 あらゆるところでグローバル変数が呼ばれ、どのクラスがどのクラスと依存関係にあるか全く分からない状態でした。 しかし幸いなことに、コードと画面数が比較的少なかったため全体的にアーキテクチャを見直すことで解決をしようと試みました。 この際に、モバイルアプリ開発GにてCombineを使ったMVVMの知見があったため、MVVMのアーキテクチャに則り進めることとなりました。 アーキテクチャに則った設計をきちんとすることで、新規参入したメンバーでも理解しやすく、安全に改修できるようなプロジェクトにすることが目標です。 いざ、実装！ 今回はMVVMに則ると決めたので、ViewとViewModelは責務を分離します。 なお、今回の実装ではUIKitを使用します。 View - Part1 Viewでは一切の演算処理を行わない代わりに、イベント発火のタイミングだけをViewModelに伝えたいです。 これを実装するために、CombineのPublisherを利用していきます。 例えば、viewDidLoadのタイミングを送信する必要がある場合、PassthroughSubjectにVoid型を持たせて定義しておきます。 private let didLoad: PassthroughSubject<Void, Never> = .init() これをviewDidLoad時に送信するようにします。 override func viewDidLoad() { super.viewDidLoad() didLoad.send() } また、ボタンのタップ時にはtapPublisher ^combineCocoa を利用するのがスマートです。 まず、対象のボタンをOutlet接続し、送信用のPublisherを準備します。 もしボタンを押したタイミングで表示されている画面のString値を渡したい場合は、VoidではなくStringでPublisherを定義します。 @IBOutlet weak var button: UIButton! @IBOutlet weak var textArea: UITextField! private let tapButton: PassthroughSubject<String, Never> = .init() その後、tapPublisherを利用してイベントを検知してViewModelに送信します。 button .tapPublisher .sink { [weak self] in self?.tapButton.send(textArea.text ?? "") } .store(in: &cancellables) 続いて、ViewModelを見てみましょう。 ViewModel ViewModelではViewから受け取ったイベントトリガーを元に、情報を取得したり生成したりすることで、Viewに必要な情報を集めて返してあげます。 こちらではCombineのOperator、Subscriberを使って実現していきます。 初めに、View側との接続準備のため、ViewModelとは別にInput,Outputの構造体を定義します。 InputはViewから渡されるデータ、Outputはその結果ViewModelから渡したいデータです。 データのやり取りの際に、渡されるデータとエラーの型がきちんと決まっていれば処理は可能であるため、型は一律AnyPublisherを使います。 struct ViewModelInput { let viewDidLoad: AnyPublisher<Void, Never> // 画面が最初に表示されたときにトリガーが欲しい！ let tapButton: AnyPublisher<String, Never> // ボタンがタップされたときにテキストが欲しい！ } struct ViewModelOutput { let onShowWelcome: AnyPublisher<String, Never> // Welcomeテキストを画面に表示してほしい let onShowText: AnyPublisher<String, Never> // 任意のテキストを画面に表示してほしい let onShowOnlyFirst: AnyPublisher<Void, Never> // 最初にボタンを押された時のみ固定値を画面に出してほしい } 続いて、データの処理部分を作成します。Inputを受け取ってOutputに変換する部分の実装になります。 例えば、viewDidLoad時に特定のAPIを実行するような動作であれば、viewDidLoadのPublisherからOperatorを繋げてAPIリクエストを実行します。 func transform(input: ViewModelInput) -> ViewModelOutput { let apiResponse = input .viewDidLoad .flatMap { api.requestData() } 同様にボタンタップ時、画面上のテキストを基にデータを生成するような動作をしたい場合は、mapを使います。 let text = input .tapButton .map { createText(text: $0) } また他にも、viewDidLoadが呼ばれ、且つボタンのタップもされたときに処理させたいことがあるとします。 そういった場合はPublisher同士を接続することができます。いくつか接続方法がありますが、今回はzipを使います。 let didLoad = input .viewDidLoad let buttonTap = input .tapButton let didLoadAndButtonTap = didLoad .zip(buttonTap) .map { _ in } このように様々なOperatorがCombineやその拡張ライブラリにはすでに準備されているため、コードをシンプルに保ちながら複雑な処理を実現することができます。 Operatorはいくつもありますが、個人的に便利でこれさえ覚えておけばOKというものを以下に挙げておきます。 map flatMap compactMap filter share materialize ^combineExt merge zip combineLatest withLatestFrom ^combineExt そして最後にOutputの型に合わせてreturnしてあげます。 Combineを利用する場合、Operatorを接続するたびに型がどんどん拡張されてしまうため、最後にAnyPublisherにまとめてから生成したデータをViewに返します。 return .init( onShowWelcome: apiResponse.eraseToAnyPublisher(), onShowText: text.eraseToAnyPublisher(), onShowOnlyFirst: didLoadAndButtonTap.eraseToAnyPublisher() ) } View - Part2 ViewModel側が完成したので、Viewと接続して画面描写を行います。 先ほど用意したtransformメソッドを呼び出して、ViewModelでの処理結果を受け取りましょう。 let output = viewModel.transform( input: .init( viewDidLoad: didLoad.eraseToAnyPublisher(), tapButton: tapButton.eraseToAnyPublisher() ) ) 処理結果を受け取ったら、各結果の際にどんな画面描写をするか実装して完成になります。 output .onShowWelcome .receive(on: DispatchQueue.main) .sink { [weak self] in self?.textArea.text = $0 } .store(in: &cancellables) output .onShowText .receive(on: DispatchQueue.main) .sink { [weak self] in self?.textArea.text = $0 } .store(in: &cancellables) output .onShowOnlyFirst .receive(on: DispatchQueue.main) .sink { [weak self] in self?.showCustomMessage("First!") } .store(in: &cancellables) 完成 こうして完成したコードがこちらになります。 class ViewController: UIViewController { @IBOutlet weak var button: UIButton! @IBOutlet weak var textArea: UITextField! private var viewModel: ViewModelProtocol! private let didLoad: PassthroughSubject<Void, Never> = .init() private let tapButton: PassthroughSubject<String, Never> = .init() private var cancellables: Set<AnyCancellable> = .init() func configure(viewModel: ViewModelProtocol) { self.viewModel = viewModel } override func viewDidLoad() { super.viewDidLoad() bind() didLoad.send() } func bind() { let output = viewModel.transform( input: .init( viewDidLoad: didLoad.eraseToAnyPublisher(), tapButton: tapButton.eraseToAnyPublisher() ) ) button .tapPublisher .sink { [weak self] in self?.tapButton.send(textArea.text ?? "") } .store(in: &cancellables) output .onShowWelcome .receive(on: DispatchQueue.main) .sink { [weak self] in self?.textArea.text = $0 } .store(in: &cancellables) output .onShowText .receive(on: DispatchQueue.main) .sink { [weak self] in self?.textArea.text = $0 } .store(in: &cancellables) output .onShowOnlyFirst .receive(on: DispatchQueue.main) .sink { [weak self] in self?.showCustomMessage("First!") // あらかじめメソッドが準備されている想定 } .store(in: &cancellables) } } protocol ViewModelProtocol { func transform(input: ViewModelInput) -> ViewModelOutput } struct ViewModelInput { let viewDidLoad: AnyPublisher<Void, Never> let tapButton: AnyPublisher<String, Never> } struct ViewModelOutput { let onShowWelcome: AnyPublisher<String, Never> let onShowText: AnyPublisher<String, Never> let onShowOnlyFirst: AnyPublisher<Void, Never> } struct ViewModel: ViewModelProtocol { let api: SomeApiProtocol init(api: SomeApiProtocol) { self.api = api } func transform(input: ViewModelInput) -> ViewModelOutput { let didLoad = input .viewDidLoad .share() let apiResponse = didLoad .flatMap { api.requestData() } // Future<String, Never> が返される想定 let buttonTap = input .tapButton .share() let text = buttonTap .map { createText(text: $0) } let didLoadAndButtonTap = didLoad .zip(buttonTap) .map { _ in } return .init( onShowWelcome: apiResponse.eraseToAnyPublisher(), onShowText: text.eraseToAnyPublisher(), onShowOnlyFirst: didLoadAndButtonTap.eraseToAnyPublisher() ) } func createText(text: String) -> String { "\(text) show!!" } } このようにViewとViewModelで明確に役割分担を行うことでコード内に秩序が生まれます。 どのViewでも同じ構成をとることができるため、コードの可読性が向上しメンテナンスもしやすく、役割が決まっているので無理矢理なコーディングが生まれにくいです。 ただしデメリットとしてはCombineやRxSwiftなどのリアクティブプログラミングを経験していない場合、それまでのSwiftとは 言語が変わったかと思うほど理解が難しい 点です。 Global KINTOのiOSのプロジェクトでは、全てのViewをこの構成に則って作成しています。 可読性が向上したことでメンテナンス性も上がり、新規のViewを作成する場合でも作成の仕方にばらつきが出づらくなりました。 最後に モバイルアプリ開発Gでは、本記事のような知見をGlobal KINTO以外のプロダクトに共有したり、これとは全く別の新しいアーキテクチャに挑戦するといったようなことも実践しています。 引き続き、モバイルアプリ開発Gの責務として、iOSの様々な開発手法に挑戦していきたいと思っています！どうぞよろしくお願いします。

KINTOのグローバル展開をサポートしている開発組織を紹介します。 目次 目次 自己紹介 グローバル開発グループの体制について 今後の活動方針の紹介 おわりに 自己紹介 KTCでグローバル開発グループでグループマネージャーをしているFengです。 私は中国でソフトウェア開発を学び、2002年より日本の大学院に進学し、その後は大手電気機器メーカーでソフトウェアエンジニア、自動車部品メーカーでプロジェクトマネージャー、プロダクトオーナーを経て、前職はモビリティ関連部品を取り扱う外資系メーカーの日本トップを務めていたことでKINTOに入社しました。 KINTOに入社してから、各国のステークホルダーたちと密に連携し、KINTOとして必要と思われるグローバル共通なものはどういうものなのかを常に考えながらプロダクト開発及び組織作りをやってきました。 グローバル開発グループの体制について 2019年グループ立ち上げの初期頃は、私がPdMを兼任しながら数名メンバーしかいない中で開発をスタートしていましたが、ちょうど3年経った今(2022年11月)は社員59名になり、その内39名が海外出身ということで、かなりダイバーシティな環境となってきたと感じています。 我々のグループとして、常に海外のKINTOチームとコミュニケーションを取りながら、下記のような業務を遂行してきました。 要件・ニーズを確認してプロダクトを企画・検討 グローバルで共通化できるようなプロダクトを基盤として開発 開発してきたプロダクトを必要に応じて各国への導入開発を実施 よって、今の開発体制もそれらの業務をサイクルとして回せるよう、下記のように構築しています。 PdMチームが企画したプロダクトを、開発チームが開発し、導入チームが各サービスへ導入する流れです。 また、各プロダクトやグループ全体に係る共通のチームとしてUIUXチームと業務エンハンスチームが存在します。 今後の活動方針の紹介 モビリティ事業はまだまだ分からないことがいっぱいある中で、各国KINTO事業をより効率よく支えるために、グローバルで共通化可能なものを念頭に置いて下記四つの方面から活動していく予定です。 おわりに KTCのグローバル開発グループ全体について、簡単ではありますが紹介しました。 各チームの詳細についてはこのあと第二弾でPdMチーム・UIUXチーム、第三弾で開発チーム・導入チーム・業務エンハンスチームの紹介をいたします。 まだ組織として成長している最中であるので、色々課題はありますが、KINTOが目指している Ever Better Mobility For All を実現するために、少しずつ居心地の良い組織をメンバーと一緒に仕上げていきたいと思っています。 また、この記事を見てグローバルでKINTOはどのようなサービスを展開しているのか、グローバル開発グループの雰囲気に興味・関心を持っていただいた方は、ぜひ下記のサイトにもアクセスしてみてください。 KINTOのグローバルポータルサイト KTC採用ページ内グローバル開発Gの紹介記事

はじめに 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もありますのでフォローしてくれると嬉しいです)。

こんにちは。分析グループ(分析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.