Booklog 2026

2026-01-07

TEAM OF TEAMS 複雑化する世界で戦うための新原則, read count: 1, page: 1 ~ 22, pages read: 22

序文、はじめに。 状況が高速に複雑に変化する現代では、小さなチームがネットワークで繋がれたチームがもつ適応力こそが重要。 縦割りの階層化された大規模組織の予測と計画による効率性は必要条件ではあるが、もはや十分条件ではない。 変化への適応性、チームワーク、意識の共有、信頼、権限委譲。 これ序文すごない？マネジメントの本で見てきたような話が相当まとまってる感じがした。 はじめにも面白い。絶えず変化していくしか生き残る道がないというのが本質やな。そのためにどのように取り組むかというところか。 本がゴツすぎて読みにくいのだけが難点。

2026-01-06

The DevOps 勝利をつかめ！ 技術的負債を一掃せよ, read count: 1, page: 307 ~ 439, pages read: 133

第 3 部 15 ~ 19 章、エピローグ、参考文献など。一気に読んだ。 概ねサクセスストーリーの部分。活動が良い方向に働き出すと流れがどんどん強くなるようなもの。 FP のくだりも含めて学習が波及していく組織の強さを表してるのかなと。 組織でとなると 1 人の学習がその周りに響いて内発的な動機づけが伝播していかないと効果を発揮しないねんよな。本書でも情熱ある人の集まりで始まるし、ワインバーグ氏・デマルコ氏の著書でも触れられてたような感じ。 事故がなくてもポストモーテムしてリスクの予兆を改善に繋げる。コアとコンテキストに分けてコアに集中するというのはホント重要。エッセンシャル思考に通ずる。 本書はこれで終わり。最後の方のサクセスストーリーは出来すぎてグッと来なかったが面白かった。 前作を全然覚えてないし読み直しても良いかもな。それと参考文献に載ってる積読本や物語の中で触れられたものを読むのも良さそう。

2026-01-05

The DevOps 勝利をつかめ！ 技術的負債を一掃せよ, read count: 1, page: 254 ~ 306, pages read: 53

第 2 部 13 章。 心理的安全性が保証された非難なしのポストモーテムと、顧客第一の考え方を育むために現場での仕事を体験するという話。 第 3 部 14 章。 イベントストリーミングが分離独立と個々の進化を推進する(ただし本書では採用せずマネージドサービスを使った)。あとは楽しみや感謝が開発を加速させるって感じか。 現場を体験させる、これ自体はすごく良い取組だが個人的に苦手なのでそれをサラリとやってのける人に憧れる。 現職はアプリの会社なのでアプリを自分で使うことで特定のセグメントだけは理解できてたら良いのだが。

2026-01-04

The DevOps 勝利をつかめ！ 技術的負債を一掃せよ, read count: 1, page: 212 ~ 253, pages read: 42

第 2 部 11 ~ 12 章。 責務に合わせて分離し、むやみに統合しない。敏捷性と自律性を得るには責任が伴う。リードタイム短縮のためのコミュニケーションパスの最適化。 この章でもおえらいさんの力を使わないと組織構造を変えて例外を作れなかったように、権力がない場合は個々人が現状を疑い組織構造の問題を解決するためにあれこれ手を打つしかないというのが本当のところよな(一部のサイコパスなおえらいさんを除き)。 こういうのに気付くと(諸々面倒なので)融通がきく小規模組織でしか働く気がなくなって、次第に少し大きな組織でも働けなくなってしまうというのが、また悩ましい。

2026-01-03

The DevOps 勝利をつかめ！ 技術的負債を一掃せよ, read count: 1, page: 181 ~ 211, pages read: 31

第 2 部 9 ~ 10 章。 QA ・開発・運用の各チームが平等に扱われない問題点とセクショナリズム。 必要な人たちに必要な権限が付与されない矛盾とプロセスに盲目的に従うことの危険性。 組織構造の欠陥がそのままシステムを複雑怪奇で敏捷性のないものにしてしまう点が描かれてた。 実際こういう組織はよく見てきた。そういう慣習を引きずったままの人がデカい merge をして破壊するのもよく見た。 個々人が現状を疑う能力を持たないとこの状況からは逃れるきっかけは現れないねんよな。

2026-01-02

The DevOps 勝利をつかめ！ 技術的負債を一掃せよ, read count: 1, page: 135 ~ 180, pages read: 46

第 1 部 7, 第 2 部 8 章。 どん底のシステム開発組織を少しずつ改善していくみたいな取っ掛かりの話。 規模の大きい組織では分離独立が重要であるという点、安全に仕事できることの重要さ、何気ない日常的な手抜きがシステムの将来に悪影響を与えそれを日常的に改善していくという本質に触れてる。 1 つ気に食わなかったのは、関数型プログラミングのスタイルでスレッドセーフなコードにすぐに書き換えたという件。純粋関数だけでそんな簡単に race condition を解消できるかな？ わたしも関数型の信奉者だが、一般的にデータハブというチーム特性を考えると、純粋な操作が与える性能の影響に触れられてないのは違和感があった。小説と割り切るかどうかってとこかもな。

2026-01-01

The DevOps 勝利をつかめ！ 技術的負債を一掃せよ, read count: 1, page: 1 ~ 134, pages read: 134

第 1 部 1 ~ 6 章。 ほぼ小説なのと序盤なので特に得るものなし。ひどいプロジェクトで DevOps するために奔走してる感じ。 デマルコ本で習ったような中間層が非公式なネットワークで結束して変化を起こすってのの典型的な展開だなと思った。 技術的負債という言葉がタイトルにあるが、個人的にあまり好きじゃなくなったのでどう使われるのかも気もしてる。今のところ話の流れでは技術的負債云々より組織構造の欠陥が目立つ。 スタートレック見てないから例えのニュアンスが微妙にわからず調べないといけないのが面倒。 実際自動テストに関してはかなり思うところがあるわ。自分で作る分はどうにでもなるがな。 前作 The Phoenix Project と The DevOps Handbook も読んでるけど内容はほぼ覚えてないので新鮮な気持ちで読めてる。 現職は組織も小さく DevOps は考え方として当たり前なので普段意識しないが、去年古典に触れたり読み直した本で得るものがあったし、改めて読むのも良さそうに思った(あと頁数がちょうど良い感じだった)。