※他还好吗？

我试着将听直播时记下的内容写出来。由于可能听漏了一些或者自己对表达进行了一些个人化的简化，所以可能与原文不完全一致，请谅解。

以下备注

参与作为面板公司的活动

Dip、Kakakucom、Kaonavi（敬称略）

单体架构 → 微服务架构

技巧 (jì

• レガシーな状態でやるのはむしろコスト

• モノリスな状態で複雑性をベンチマークしながら下げることを先にコツコツすすめた方がいい

• インフラのリアーキテクトによって捨てられるコードもあるのでそういう手段もある

食べログはkafkaとかを使って16日かかっていた検索用インデックスの同期を3.5時間にした？

DBはあと、先にコード
フロントは変えずバックエンドのリファクタリング
kubernetes（スペルあってるか？）
マイクロサービスのDB分割は後回し？
マイクロサービスの前にAPI化
やりやすいところ、新機能から事例を作る？

マイクロサービスアーキテクチャにとにかく忠実に
revert多発前提
武器屋（チーム）を作る

组织、教育

• CTOが旗を振っている

• CTO配下に専任チームを作った？

• 設計が悪くて開発スピードが出ないという背景をCTOがビジネス側の人たちに説明し、工数なりを捻出

• メンバーへはドキュメント化、丁寧な説明などによって裾野を広げる理解を深める

• モノリスのデメリット、マイクロサービスのメリットを提示しROIのメリットを明確にする

• 6人で6ヶ月？（規模わからね）

• スキル（クリーンアーキテクチャ、DDDらへんの）高いメンバーを寄せ集めてチームを作った

• ワクワクを感じる人達

• 事業継続の面からあるべき姿を定義して経営層への説明などを進めた（冗長化しやすいとか）

横展開（隣のチームが「それうちも使いたい」といって先行しているチームがハンズオンとか外枠の設計とか提供してもらったり）

有沒有課題？有沒有想問的問題？

質とスピードのあるべきすがたのようなものをかなり忠実にやっていけばいいだろうと考えている

プロパーだけでやってる？

BPも巻き込んでいる、分断などはあまりない。自律性はプロパーのほうがある。
人数をと工数を見積もり、欲しいスキルを持った人材をジョブ型的に採用（プロパー、フリーランス、BP問わず）
予算の問題はあまりないが、人員構成とかをきっちり作ることで弾かれない。

向いているプロダクト、組織

あまり解散しない組織は向いている、心理的安全性
スクラムチーム（各自が当事者意識を持っている）
実行力（やる）
マイクロサービスにするだけ大きい組織、プロダクト
フルサイクルだけでなく、スペシャリストを賄えるだけの組織（技術、ビジネスとも）

マイクロサービスの目的

リアーキテクチャリング、正しい顧客へのoutcome
ビジネスモデルに沿って、売上につなげる、そのためにマイクロサービスが最適だろうという仮説
少人数で自立的開発できる（フルサイクルエンジニア）

最后

我想知道是否还有存档在某个地方，因为之前在忙于工作时漏掉了很多。