アジャイルプラクティスガイドブックが7月20日に発売されます #agileprag
昨年から執筆を進めていたアジャイルプラクティスガイドブック (#agileprag) が7月20日に出版されます。
どんな人に向けた書籍か
Regional Scrum Gathering Tokyo 2022の登壇をきっかけにお声がけいただき、アジャイル開発に取り組む上で取り入れるとよい技術プラクティスやノウハウを濃縮し、ぎゅっと閉じ込めました。現職のRetty・および前職での経験を踏まえ、116ものプラクティスを紹介しています。
アジャイル開発に取り組む上での技術プラクティスの知見は書籍・ブログ・カンファレンスや講演・口伝・各現場での工夫など多数ありますが、まとまった形で体型立ててキャッチアップすることが難しいと感じていました。この書籍はそんな課題を感じてる方に向けたものです。
豪華コラムを 10編 11編収録
現場寄りの開発知見をより盛り込めるよう、アジャイル開発を実践している方にお願いし、11編のコラムを寄稿いただきました。Amazonの書影は10編になっていますがその後増えて11が正解です。 書籍が無かったら読むことができなかったであろう多彩なコラムが読め、私が一番喜んでおります。
- グラデーションで考える12年間のアジャイル実践 （きょんさん）
- ペアプログラミングの効果と影響 （やっとむ（安井力）さん）
- 開発と運用、分けて考えていませんか？―ダッシュボードのその先へ― （河野通宗さん）
- インフラ構築を自動化しよう （吉羽龍太郎さん）
- Logging as API contract （牛尾剛さん）
- 開発項目をコンパクトに保つには、クリーンなコード（大谷和紀さん）
- テスト駆動開発ではTODOリストがテストよりも先 （大谷和紀さん）
- チームで1つずつ終わらせよう （椎葉光行さん）
- チームに命を吹き込むゴール設定 （天野祐介さん）
- AIフレンドリーなドキュメントを書こう （服部佑樹さん）
- 技術的負債―問題発見までの時間とリスクをビジネス側に説明する（川口恭伸さん）
監修・レビュアー・編集の皆様のおかげで読みやすい書籍にできました
本書は川口 恭伸さん、松元 健さんのお二人に監修いただきました。また昨年末は多くの方にレビュー協力をいただきました。書籍内容はもちろんのこと、プラクティス導入の背景や狙いを段階を追って説明できているか、見解の偏った主張や説得力の薄い箇所がないか、アジャイルコミュニティの過去の経緯や蓄積を押さえられているか、書籍としての読みやすさなど多くの助言をいただき、書籍のクオリティを引き上げていただけました。
小田中育生さん、藤原大さん、大金慧さん、石毛琴恵さん、粕谷大輔さん、守田憲司さん、岩瀬義昌さん、粉川貴至さん、森田和則さん、伊藤潤平さん、山口鉄平さん、半谷充生さん、飯田意己さん、今給黎隆さん、木本悠斗さん、渡辺涼太さん、小迫明弘さん、池田直弥さん、今井貴明さん、皆様本当にありがとうございました。
常松さん渾身の #agileprag 、わたしもレビュワーとして参加してます。
— いきいきいくお (@dora_e_m) 2023年5月21日
よくこんなに集めたな！という錚々たる顔ぶれのレビュワーによるレビューで強度を増した一冊、発刊がとても楽しみ。 https://t.co/OjEC8f0ID1
↑レビューに参加いただいた小田中さんのツイート。私自身もレビューアーからのコメントが書籍の内容よりためになるのでは(!?)と思いながら手を入れていました。
また書籍の各章・項の冒頭には漫画を挿入しました。開発現場で起こりそうなよくある事例と合わせて読み進めてもらうことで、自分の現場で推進・実践していくイメージが湧きやすく仕上がっています。
書籍の目次
Amazonに章立てが出ていますが、出版社のページではもう一段階細かい目次が確認できます。
第1章 アジャイルな開発を支えるプラクティス 1.1 プラクティスの実践 1.2 高速に石橋を叩いて渡る 1.3 広く知られたアジャイル開発手法とプラクティス 1.4 プラクティス理解に役立つ考え方 第2章 「実装」で活用できるプラクティス 2.1 実装方針 2.2 ブランチ戦略 2.3 コミット 2.4 コードレビュー 2.5 協働作業 2.6 テスト 2.7 長期的な開発／運用ができるソースコード 第3章 「CI/CD」で活用できるプラクティス 3.1 継続的インテグレーション 3.2 継続的デリバリー 3.3 継続的テスト 第4章 「運用」で活用できるプラクティス 4.1 デプロイ／リリース 4.2 モニタリング 4.3 ドキュメント 第5章 「認識合わせ」で活用できるプラクティス 5.1 関係者との認識合わせ 5.2 開発内での認識合わせ 5.3 計画の継続的な見直し 第6章 「チーム連携」で活用できるプラクティス 6.1 チームの基本単位 6.2 属人化の解消 6.3 パフォーマンスの測定 6.4 円滑なコミュニケーションのアイデア 6.5 意識を揃えるワークショップ
章・項の中でさまざまなプラクティスを紹介しています。
本書で取り上げる開発のシーン 実装方針の検討、タスクの分解、ブランチ戦略の検討、コミット、コードレビュー、複数人での共同作業、テスト、運用を見据えたソースコードの整備、CI/CD、デプロイ、リリース、モニタリング、関係者間の認識合わせ、チーム内外との連携
PACEモデル - P&Gの責任の割り当てプロセス
複数人で業務にあたるときに、誰が何の責任を持つのか明確にして割り当てるためのフレームワーク。P&G由来らしいのだが調べてもあまり紹介されていない。
PACEの意味と役割
P : Process Owner
プロセスオーナー、業務(プロセス・プロジェクト)の始まりから終わりまでを把握して主導する人。 承認者が意思決定できるように実行すべきことを考え、スケジュールや関係者の巻き込みや、フォローアップ・報告に責任を負う。 スクラムマスターに少し似ている? 気のせい?
A : Approver
承認者。意思決定が役割。 上で紹介した「米P&Gの危機管理体制」の記事によると、複数人ではなく1人が請け負うらしい。この辺りはスクラムのプロダクトオーナーと似た側面がありそう。
C : Contributor
プロセスオーナーからの要求に応じて意見や専門知識を共有する貢献者。 プロセスオーナーの進め方や、承認者の決定について議論することはできないらしい。専門知識を持つ部外者という役割なのかな?
E : Executor
承認者が決めたことを実行する役割。
どう使うと良さそう?
会議の議事録テンプレートに入れておき、最初に埋めるようにすると、役割定義の理解をぶらさずに明確にすることができてよさそう。
「ゾンビスクラムサバイバルガイド: 健全なスクラムへの道」の感想
翻訳者の皆様から献本いただきました。
こんな本です
「スクラムで開発しているけど成果も感じられず、うまくできていない状態」を指してこの本ではゾンビスクラムと読んでいます。ただ決められたやり方を繰り返しているだけの状態を指す表現としてぴったりだと思います。なぜゾンビ化してしまうのかの理由と、ゾンビ化を防ぐためのプラクティスが難易度と効果がセットでいくつも紹介されています。
スクラムを紹介する書籍や資料は数多くあり、プラクティスや背後にある考え方を教えてくれますが、よくあるスクラムの失敗状態から抜け出る方法を扱った書籍はそういえばありません。「ステークホルダーを巻き込まない」「リリースを溜めてしまう」「おかしな状態・問題ををみてみぬふりする」この辺りの問題が丁寧に説明されています。
こんな方におすすめ
スクラムの入門書籍は読んで、組織・現場で実践し、うまくできている気がするけど「こんなもんなのか」と感じているような状態で読むのが一番効果があると思います。 「私たちのスクラムがうまくいってない気がする」となると外部のアジャイルコーチやコミュニティに顔を出して助けてもらうのが良くある定石ですが、私が外部からのコーチとして招かれたらきっとこの本に書いてあることを1年ぐらい指摘し続ける気がします。今所属しているRetty株式会社でアジャイルな開発を広める際もこの書籍の内容を再三社内で言ったなーと思い出しながら読みました。
組織内に複数のスクラムチームがあり、スクラムマスターが複数人いるのであれば、この書籍の内容を輪読するとスクラムマスターとしてのレベルが確実に1段階上がると思われます。
会社でも1冊購入しましたが、献本いただいた分も活用して、社内のスクラム運用レベルを引き上げるのに役立たせていただきます。
個人的にこの本の好きなところ
- 挿絵がかわいい
- 表紙に翻訳者3名の似顔絵があるが似すぎている
2022年1〜3月に社内で共有したアジャイル開発関連の記事
社内でアジャイル開発を議論するSlackチャンネル #tech_agile に見かけた良記事のまとめです。
ノウハウ・知見
フィーチャーファクトリーにならないように注意
有名なMVP図の解説
デュアルトラックアジャイルの実践
フィーチャーフラグの分類
ユニコーン企業の秘密をベースとしたスケーリングの考え方
落合博満に学ぶ
技術負債に立ち向かう前の話
TDDの考察
スクラムチームを生産的にするパターンランゲージ
プロダクトバックログの整理の秘訣
捨てましょう。
30分で分かった気になるチームトポロジー
他社事例
メルカリCAMPシステム
現在はCamp単位でLeSS(Large-Scale Scrum)を入れるように推奨しています。そして必要があればAgileコーチやScrum Masterをアサインしています。
LIFULL
LeSSっぽいけどLeSSと明言してないので何か大きな違いがあるのかも。
GitLabで学んだ最高の働き方
atama+ LeSS事例
Regional Scrum Gathering Tokyo 2022
スライドまとめ
後日公開された動画
いい感じのチームを作る考え方
ChatworkのScrum@Scale事例
永和システムでの学び直し・スキルアップの取り組み
学びのサイクルを繰り返しながら機械学習など新領域を習得してもらうの言われるとすごく良さそうだけどこれまでみたことなかった気がするので新鮮
www2.slideshare.net
プロダクトゴールについて
スプリントゴールについて
Agile Fluencyモデル
RSGT 2022 2日目の基調講演より。うちは今Optimizationかなーと思いながら聞いていました。
プロダクトバックログについて
これは教科書
Yahoo LeSS事例
ブルシットプロダクト
その他
Women in Agileコミュニティ
CircleCIの開発の雰囲気
1つのカードが長くても3日で終わるくらいの大きさで。優先順に並んでて。カードごとに、ゆるめのAC（受け入れ条件）があって、本番デプロイしてる。メンバーはそれぞれ得意分野があるけど、得意分野じゃないカードも取って、得意な人にペアしてもらったり、レビューしてもらったりしてる。そんなの。
— Mitsuyuki Shiiba (@bufferings) 2022年1月25日
リモートペアプロを扱った書籍
リモートペアプロの本があった
— 角 征典／Masanori Kado (@kdmsnr) 2022年3月2日
Practical Remote Pair Programming: Best practices, tips, and techniques for collaborating productively with distributed development teams (English Edition) https://t.co/ujPqI1i5jh via @amazon
「プロダクトバックログが降ってくる」という表現は危険の兆候
プロダクトの価値を最大限にするために、チームがプロダクトバックログを調整するというのが検査と適応なので、「プロダクトバックログが降ってくる」というのは、だいぶ危ない臭いがしますね。
— HARADA Kiro (@haradakiro) 2022年3月3日
速さにはベロシティとアジリティがある
速さには、ベロシティ(まっすぐが速い)とアジリティ(止まったり方向転換が素早い)という要素があって、しばしば対立するんですよね。アクセル全開だとカーブ曲がりきれないので、適切にコントロールする技術が大事かなと。(その車に乗ってない人にとっては関係ないかもですけど)
— Yasunobu Kawaguchi (@kawaguti) 2022年3月7日
MVPには名前をつけておく
MVPには名前をつけておくと良いです。運悪くユーザーを見つけられなくて使われなかったとしても、チームが次のMVPを決めるときの語彙として生き残ります。
— HARADA Kiro (@haradakiro) 2022年3月26日
「Googleのソフトウェアエンジニアリング」の感想
2021年11月末に発売されてからすぐに入手したはずですが、少しずつしか読み進められず、先日ようやく読み終わりました。
25章ある書籍の内容をざっくり分類すると
- トップ層のエンジニアを集め、実業務を通じてGoogleが分析・見出したベストプラクティス
- Googleの規模でないと起こらないであろうスケール問題
- Googleにしかなさそうな謎内製ツール/謎内製ソフトウェアの紹介
かなと思います。
中堅以上のソフトウェアエンジニアなら技術的にも思想的にも面白いと感じるポイントが必ず見つけられ、頭から読み進めずとも気になる章をつまみ食いして読むこともできる面白い書籍です。
以下気になったトピックを順不同で紹介します。
Hyrumの法則が面白い
Hyrumさんはこの書籍の著者で、こんな考えを披露しています。
あるAPIに十分な数のユーザーがいるとき、APIを作った者自身が契約仕様として何を約束しているかは重要ではない。 作られたシステムが持つあらゆる観察可能（observable）な挙動に関して、それに依存するユーザーが出てくるものである。
「要件として合意した」「仕様として明記している」とかに関わらず、暗黙的な挙動に依存した実装になってしまっていることはよくあります。 有名なところだとハッシュの順序問題とか。「OSSライブラリを更新するとテストが通らなくなった」も同種の問題かと思います。
実装だけで起きるのではなく、組織のあらゆるレベル・コミュニケーションでこのような暗黙的な依存が発生するのが、法則としてよくできているなと感じます。
マネジメントについて
・自分が居合わせなかったとしても組織自体がその問題を解けるようにすることも、自分の仕事である
・優れたマネジメントの95%は観察と傾聴で、5%はちょうど正しい場所に決定的に重要な調整を加えることである
GoogleのマネジメントスタイルはGoogle re:Workとしてもまとまっていますが、エッセンスが短くまとまっている上記の書籍表現が気に入りました。 マネージャーとしてチームやメンバーと伴走することも時にあるかもしれませんが、自分がいなくても同じように物事が動くよう仕組みを作るのが一番効果的ですよね。
テストコードの読みやすさ
・テストは後からの付け足しであってはならない。
・テストコード自体のテストはかかれないため、テストコードでは分岐・繰り返しなどの制御構文を使うべきではない。
・なるべくモック使うな
Googleの開発規模・エンジニア数ともなると、不安定なテストが少量でも入ると、他の開発者の時間を奪ったりリリースブロックとなり得たりと与える影響がものすごく大きいことが心に残っています。なので当初からテストをきちんと書くし、テストコード自体も読みやすさを重視するし、なんならモックをなるべく使わずテストすることを考えるそうです。
テストをしっかり書こうとするほどモックの書き方に時間が取られているような気がしていたので、「モックを使いこなすことが必ずしも良いことではない」という意見があることが知れてよかったです。
レビューは設計を議論する場ではない
・コードレビューは、過去に既に行われた設計上の決定について討議するための時間ではない。
・コードレビューは提案されるAPIの設計を紹介するための時間ではない。
コードレビューの目的が事前に擦り合わせられていないと、つい設計方針や実装技巧の議論をしがちではありますが、レビューはそういう時間ではないと一刀両断してくれました。そうですよね。
ドキュメントは読み手を意識して書く
・(ドキュメントは)読者に向けて最適化せよ。
ドキュメント整備について、Googleは他社よりも時間・工数をかけているのだろうと思っていて、書籍を読み終わった今もその認識ですが、それでも完璧ではないと感じているそうです。ドキュメントは「Googleでも一級市民として扱われていない」だとか。
ドキュメント管理は定期的に新しいツールが出てきますが自分の中ではこれといった決定版と受け取ることができず、内容が古びたものを見直し・淘汰できる仕組みが入っているといいのかなーと思ったりしました。
ソフトウェア開発に関する意識の持ち方
コードは債務であり資産ではない。
「技術的負債」という言葉が広く使われるようになったせいか、負債でないなら資産なのだろうと私とかは考えてしまいがちですが、本書では運用・メンテナンスが必要なことから「債務」と表現していました。利用者が使い続けられるように考慮・サポートが必要なことからですが、先に紹介したHyrumの法則にもつながる考え方かと思います。
定期的な再デプロイの強制化
本番環境には半年ごとに再ビルド・再デプロイされなければならない
だそうです。
開発がひと段落したサービスだとライブラリ更新を怠ったり、頻繁に更新されないサービスだとビルド・デプロイの自動化を後回しにしてしまいがちですが、こういうルールを決めておくことで問題を軽減することができそうです。外部環境の変化でいつのまにかデプロイできなくなった/動かなくなったというのも避けやすくできそうです。
Bazel / アーティファクトベースのビルドシステム
モノレポ(全てのコードを1つのリポジトリにまとめて管理する)とセットで導入するビルドシステムとしてよく名前を聞いていましたが、アーティファクトの依存関係を宣言的に定義しておくことでツール側で再ビルドの必要性を正しく判断でき、ビルドに要する時間を短縮できると知り、仕組みにとても感心しました。Bazelについて調べてみると、現実は「Bazel職人」のようなノウハウを蓄えている人が生まれてしまう負の側面もあるようですが、それでも機会があれば一度は触ってみたいなと思うように考えが変わりました。
おわりに
少しずつ読み進めていたため、Twitterに #Googleのソフトウェアエンジニアリングのタグで感想を呟いていましたが、書籍で推奨しているハッシュタグは #swebookjpだということを一番最後に知りました。ぜひ両方のハッシュタグを眺めてみて、書籍を手に取ってみてください。
Regional Scrum Gathering Tokyo 2022に参加してきました #RSGT2022
はじめに
2019年が初回で、通算4回目の参加でした。
- Regional Scrum Gathering Tokyo 2019に参加しました - tuneの日記
- Regional Scrum Gathering Tokyo 2020に参加しました #RSGT2020 - tuneの日記
- Regional Scrum Gathering Tokyo 2021に参加しました #RSGT2021 - tuneの日記
参加者(2019)→スポンサー(2020)→参加者(2021)ときて、今年は登壇機会がいただけ新しい楽しみ方ができました。 登壇に関しては来週あたりに会社のブログで別途書きます。
聞いてきた話など
「録画で後で見れるし、他のオフライン参加者と親交を深めるか」と考えて発表を聞いたのは半分くらいです。 3日目は家族都合 & 会社都合で不参加でした、後日録画で見ます。
Agile Program Management: Scaling Collaboration Across the Organization
「スケールする際にコラボレーションを増やしてスケールしよう」というのはわかる。LeSSだと「ただ話す」とかなのかな?
Software Program Teamはよくわからなかった。コラボレーションを絞る方向の仕組みだと思うけど、でも何かを決める仕組みが時に必要なのは同意。
Leading Skilled Agile Teams: Investing in Team Outcomes with the Agile Fluency® Model
Agile Fluencyの図がなるほどなーと思って聞いていました。 チーム文化を変える→チームスキルを上げる→組織構造を変える→組織文化を変える の中で、自社の今はOptimizeのあたりかなーと思いあたります。 「アジャイルである」領域を広げる際に、気持ちではなく仕組みで工夫する必要があり、とっかかりを試行錯誤していた自分にとってはしっくりきた図でした。
今年の感想
ゴールに関する発表が多い
プロダクトビジョン・プロダクトゴール・スプリントゴールなど、目標やゴールに関する話が多かったし、講演後も議論しているのを良く見かけた気がします。
1チームのスクラム・立ち上げはできるところが増えてきて、LeSS / Scrum@Scale / Spotify Modelなどスケール手法を試すところが出てきて、「複数チームの方向性を束ねて力を引き出すにはゴール設定で認識揃えるのが大事だと考える人たちが増えてきた」とかかなーと思っています。 自社でもプロダクトゴールが明確に作れてなかったり、スプリントゴールをフワッと決めてしまうところがあり、今ひとつしっくりきてない感じがあったので長沢さん・稲野さんの発表を踏まえて試行錯誤します。
建設的な議論をカンファレンス中にやりたい
コロナ禍となり、オンラインカンファレンスになってからテキストチャットで感想を伝えるからか「いい話」のようなコメントが増えたような気がしています。
どんなことを言っても受け止めてもらえる場は大事だけど、議論して課題を見つけていく・考えることはもっとやった方が良いんじゃないかなと感じました。気心の知れたメンバーと個別に行っていたり、自社・自分の現場に持ち帰ってあーでもない・こうでもないと話しているような気がします。 できることなら会期中に「こんな意見もあるんだ」という観点を得てもらうのに見える形でできた方が良いなと。単にDiscordに撒き散らしていると荒らしっぽく攻撃しているように見えちゃうけど、RSGTの参加者ならうまくやれる方法を見出せるような気がしたり。
全体として前進できているかな?
プロダクト・現場を良くするため、知見を持ち寄って協力するギャザリングだと思うので、数年単位で見たら変化が感じられるような場であってほしいなと思うようになりました。もちろん新規参加の裾野は広がり続けるし、うまくいったり・いかなかったりを繰り返しながら螺旋のように改善が進んでいくと思うのですが、全体としてどうなんだろうと。一部の人は成功体験を積んで前進しているけど、個人に紐づいている割合が大きいような気がします。
その意味で伊藤さんの発表は考えさせられるポイントがいろいろあるなと感じました。この講演を聞いた人が次世代の社内アジャイルコーチとして業界全体のレベルを引き上げたり、伊藤さんが新たな視点を経てRSGTに戻ってきたりとか、そんな瞬間に立ち合えるといいなと思っています。
自分の4年前を思い出すとできていることが増え・フェーズが変わってきた実感がありますが、参加者全体で見ると参加者・登壇者が開発・アジャイルコーチに寄りすぎていて、もっとステークホルダー(経営層・幹部層)やプロダクトマネージャーなどが増えると良さそうだし、基調講演の反応が変わってきたりするのかなと思いました。
「モノリスからマイクロサービスへ」を読んで考えたこと
2021年に会社で読書会をし、社外の方とも別途読書会をしたほどの本でしたが、タイミングを逃して感想を書いてなかったので残しておきます。
マイクロサービスに取り組む上での基礎や重要事項が丁寧に説明されている
1章と5章が特に良かったです。
- なぜマイクロサービスに取り組むのか。
- 3つの疑問。1. 達成したいこと、2. 代替案がないか、3. 成功の基準。
- マイクロサービスで守るべきこと
などなど。
3章と4章はテコ入れの界面を見定めて徐々に新しステムに切り替えていくストラングラーパターンをサービス内・DBで行うような似た話が続いており、ここを工夫できればもっと短く上手くまとめられそうなのになと感じました。
書籍全体の印象としてはマイクロサービスを考え始めたぐらいの時期から、実際に進めていて壁にぶつかったあたりまでに読むのが良さそうです。 関係者の知識や思想を揃えるにはいい本でした。マイクロサービスを推進していく上での実践テクニックはそこまでカバーされていません。
モジュラモノリスそんなにいいものだろうか
書籍ではマイクロサービスが一押しというわけではなく、なぜマイクロサービスに取り組むのか・モノリスではダメなのかという話も同じくらい重きを置いて説明されています。 デプロイ単位としてまとまっているが、内部の作りは分けられたモジュラモノリスも書籍で触れられていますが、読書会でもモジュラモノリスに惹かれるメンバーがいました。個人の感想としてはモジュラモノリスはフレームワークの後押しが欠かせないと感じていて、知っている限りだと取り組むのに向いているフレームワークはあまりないかなという印象です。強いて言えばRails Engineなのかな?
自社でも一つ、小さなサービスの寄り合いになっているサービスをモジュラモノリスのように作ってみましたが、内部で知らず知らずのうちに依存関係を持ってしまったことが後日わかり、切り離す判断が遅れていたらもっと結びつきが強くなってただろうなと思います。フレームワークで依存関係を防止できるか検出できるようになってないと厳しい印象です。 モジュラモノリスに取り組んでいるところがあればぜひ話を聞いてみたいなと思いました。
マイクロサービス移行は文化の変革である
自社のマイクロサービス移行は数年かけた計画になっており、早くともあと3〜4年かかるかなという見立てですが、書籍でもマイクロサービス移行は文化を変える必要があり、長い時間がかかるとはっきりと書かれています。 自社の力不足や怠慢で時間がかかっているのではなく、開発文化を変えながら進める必要があるためこれぐらいかかるのが当たり前だという時間軸の認識を揃えられたのが良かったです。
異なるプロダクトに取り組んでいる人同士で話すと違った気づきがある
冒頭で触れた通り社内読書会と社外読書会で2回読みましたが、それぞれ違った気づきがありました。
社内メンバーとの読書会は会社のプロダクトの歴史を踏まえ深く議論することができますが、経験が似ているからか観点は偏りがちで、書籍で意図が汲み取れなかった箇所が社内メンバー全員わからずといったこともありました。
社外メンバーとの読書会では、経験・背景が異なるので、「こういう経験があった」「こういうことかと受け取った」といった話を広く聞くことができ、いろんな視点から本の内容を考えることができました。2022年も何かの本を選んで社外の方と話をすると面白いかも。
他に気になっているマイクロサービス本
会社でマイクロサービス導入を始めた2019年に読んでこれは完走しました。だいぶ前の本ですが、内容が大きく古びていることもなく今でもおすすめかと。
まだ未読ですが、「モノリスからマイクロサービスへ」よりも実践的な内容がカバーされている印象を持っています。
