目的地が設定できる手帳のような使い心地のTODOアプリを公開しています。複数のチームで共有サービスとして開発していく場合と、1つのサービスを1つのチームで開発する場合の考え方を紹介している。1サービス1チームで組むべき。単一チームであるとコミュニケーションのコストが容易且つ、担当サービスへの境界意識が強くなるシステムを構築する人員が疎の場合、モジュール化していく傾向にある。よって、個々のサービスの疎結合を目指すマイクロサービスではチームごとにサービスを担当するのが効率が良いと論じている。共有サービスとチーム分割これいつも思うんだけど、予算、リソースの問題だと思うんだよなあ...本書ではすべてのサービスの開発を横断的に行うチームをフィーチャーチームと称してアンチパターン的に紹介がされている。僕も典型的な予算がない良くないパターンと思っていて、フィーチャーチームの状況でマイクロサービスの開発優先順が決まってしまうなんて事も起こりうる。個々のサービスは自律して開発されていくのが相応しい思想だと思うんだけどねぇ。理想として個々のサービスのビジネスドメインに沿ったチーム構成になっていると、自ずと顧客指向な機能開発となる。はずと本書では示している。少人数であるが故に属人的になりやすいことはリスクでデリバリボトルネックとして事例が紹介されている。個人的には"枯れたマイクロサービス"が予算がつかない、どんどん保守されなくなっていくリスクなんかもあるんじゃないのかなあと思ったりしてたんだけど、きちんと孤児サービスという名称で説明があった。文化が変わるということモノリシックからマイクロに変わるということは、違う言語や新しいOSSを導入したりと未経験のものに踏み込む機会があるということ。そこは期待もあるが不安もあるので柔軟にサポートする必要があったりする。逆に入ってくるパターン、つまり異動が頻繁に起こり得るということを考慮しよう。(2)はてなブログをはじめよう!letitrideさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。