#Book [[📒「正しく」失敗できるチームを作る──現場のリーダーのための恐怖と不安を乗り越える技術]] ## 第3章　「正しい失敗」は技術革新によって作り出された ### 3.3クラウドとコンテナ技術の発展 > 技術進化によって同時に技術が[[🗃️コモディティ化]]するようになりました。悪い意味でとらえれば、誰が実装しても“だいたい”同じような高品質なサービス提供が可能になり、エンジニアのスキル自身もコモディティ化するようになったといえます。良い文脈でいえば、コンピュータリソースを少人数でもサービス規模に関係なくマネージドサービスで管理できるようになったため、以前のように多くのエンジニアを投入してスケールさせなくても、サービスが提供できるようになったともいえます。 ^ref-11203 ### 3.4セクショナリズムと[[🗃️DevOps]] > プロダクトを運用・保守するにあたって、運用チームは人数によってスケールするのではなく、 自動化ツールの提供によるスケール を目指すべきだということ ^ref-20570 > 運用チームはツールを開発し提供することで、直接プロセスには介入せずに運用チームが開発したツールを利用してもらう形になりました。これによってリードタイムが短くなっただけではなく、運用チームはプロダクトが多くなっても、プロダクトごとに運用チームを配置する必要はなく、ツールを提供すればよいため、スケーラビリティがとても向上しました。つまり、運用チームもスモールチームで成り立つようになりました。 ^ref-28178 ### 3.5　マイクロサービスとコンウェイの法則が，スモールチームとシステムのあり方を定義した > [[🗃️マイクロサービス]]という考え方を広めたのは、James Lewis氏と、2001年のアジャイルソフトウェア開発宣言を策定した1人でもあるMartin Fowler氏が書いた「Microservices - a definition of this new architectural term」という記事でしょ ^ref-10476 > 単一のアプリケーションを、小さなサービス単位に分割し、それぞれが独自のプロセス（多くはAPI：アプリケーションプログラミングインタフェース）で通信するしくみです。これにより、ビジネスドメイン単位で分割され、互いの依存関係が少なく、独立して開発を遂行できるソフトウェアアーキテクチャの形が生まれました。これを「マイクロサービス」と呼びます。 ^ref-16295 > [[🗃️コンウェイの法則]]の法則とは、組織の集合体とアーキテクチャの相関関係の現象を表したものです。メルヴィン・コンウェイ氏が提唱した概念で、一言で言えば、以下の表現で言語化できます。 「システム設計（アーキテクチャ）は、組織構造を反映させたものになる」 ^ref-64484 > 組織の形状を設計するときに理想のシステムアーキテクチャを描き、最初からそれに合わせた組織の形状をグランドデザインしてしまおうという考え方が逆コンウェイの法則です。たとえば、マイクロサービス化を進めるのであれば先にドメイン境界をもとに「どういった単位で分割するか」を決め、そこにチーム編成を合わせていく。 ^ref-16759 ### 3.6フルサイクルでの エンジニアリングが可能に > Full Cycle Developers”という概念です（ 図3-6-1）。Netflixが2018年に提供した概念で、端的にいえば「アイデアがあり、それをユーザーへ届けるまでを1つのサイクルと定めて、それをすべてのエンジニアができるようにする」 ^ref-10636 💭これは[[🗃️ストリームアラインドチーム]]的なやつかな