※大丈夫なのかな？
リアタイで聞きながらメモった内容を書きだしてみた。
聞き漏らしていたり表現を自分なりにわかりやすくとかもやっているのでまんまではないことをあしからず。
以下メモ
参加パネラー企業
ディップ、カカクコム、カオナビ（敬称略）
モノリス→マイクロサービス
テクニック
- レガシーな状態でやるのはむしろコスト
- モノリスな状態で複雑性をベンチマークしながら下げることを先にコツコツすすめた方がいい
- インフラのリアーキテクトによって捨てられるコードもあるのでそういう手段もある
- 食べログはkafkaとかを使って16日かかっていた検索用インデックスの同期を3.5時間にした？
- DBはあと、先にコード
- フロントは変えずバックエンドのリファクタリング
- kubernetes（スペルあってるか？）
- マイクロサービスのDB分割は後回し？
- マイクロサービスの前にAPI化
- やりやすいところ、新機能から事例を作る？
- マイクロサービスアーキテクチャにとにかく忠実に
- revert多発前提
- 武器屋（チーム）を作る
組織、教育
- CTOが旗を振っている
- CTO配下に専任チームを作った？
- 設計が悪くて開発スピードが出ないという背景をCTOがビジネス側の人たちに説明し、工数なりを捻出
- メンバーへはドキュメント化、丁寧な説明などによって裾野を広げる理解を深める
- モノリスのデメリット、マイクロサービスのメリットを提示しROIのメリットを明確にする
- 6人で6ヶ月？（規模わからね）
- スキル（クリーンアーキテクチャ、DDDらへんの）高いメンバーを寄せ集めてチームを作った
- ワクワクを感じる人達
- 事業継続の面からあるべき姿を定義して経営層への説明などを進めた（冗長化しやすいとか）
- 横展開（隣のチームが「それうちも使いたい」といって先行しているチームがハンズオンとか外枠の設計とか提供してもらったり）
課題はあるかあったか？聞きたいことはあるか？
-
質とスピードのあるべきすがたのようなものをかなり忠実にやっていけばいいだろうと考えている
-
プロパーだけでやってる？
- BPも巻き込んでいる、分断などはあまりない。自律性はプロパーのほうがある。
- 人数をと工数を見積もり、欲しいスキルを持った人材をジョブ型的に採用（プロパー、フリーランス、BP問わず）
- 予算の問題はあまりないが、人員構成とかをきっちり作ることで弾かれない。
-
向いているプロダクト、組織
- あまり解散しない組織は向いている、心理的安全性
- スクラムチーム（各自が当事者意識を持っている）
- 実行力（やる）
- マイクロサービスにするだけ大きい組織、プロダクト
- フルサイクルだけでなく、スペシャリストを賄えるだけの組織（技術、ビジネスとも）
-
マイクロサービスの目的
- リアーキテクチャリング、正しい顧客へのoutcome
- ビジネスモデルに沿って、売上につなげる、そのためにマイクロサービスが最適だろうという仮説
- 少人数で自立的開発できる（フルサイクルエンジニア）
最後に
どこかにアーカイブ残ってないかな、前半結構業務片手間に聞いてて結構逃している。