Booklog 2026

2026-01-28

GE 巨人の復活 シリコンバレー式「デジタル製造業」への挑戦, read count: 1, page: 182 ~ 199, pages read: 18

第 6 章。デジタルで変わる製造現場。 ディーゼルエンジンの分解・修理を担う工場での徹底的な可視化・自動収集・無駄の排除・単純化・ポカヨケ・文化。 施設の稼働状況、施設内機器のセンサー取り付け、デジタルカメラによる画像認識、作業員が携行する Bluetooth デバイス等で集めた情報に基づく改善活動。 作業を単純化しミス低減、顧客第一の文化を作り出す。ここでいう顧客第一は、 GE に関連する他の工場へのナレッジの共有、作業員の安全・効率を指す。 エンジン部品の製造に導入された 3D プリンター。従来より軽く耐久性能も上げられる。また 3D プリンター市場でも存在感を見せる。 この辺りは今にしてみれば製造現場の DX としてありそうな話やが時代を考えれば相当進んでたんやろうな。 GE デジタルと Predix を畳んだ後も社内の DX の成果は生き続けるだろうし。

2026-01-27

GE 巨人の復活 シリコンバレー式「デジタル製造業」への挑戦, read count: 1, page: 165 ~ 181, pages read: 17

第 5 章。 GE が開発したサービス。 デジタルスレッドが施設や作業の可観測性を高める。 Predix で提供される膨大な API はマイクロサービスで実装されていて業務アプリケーションからはそれを使う。 エッジデバイスの一部はオフラインで使える代わりに利用できる API が制限して提供される。 将来は非破壊検査のための超小型ロボットもエッジデバイスに加える計画だった。 Predix を利用する新しい顧客も現れた。 LIXIL は GE の危機を使わず純粋に Predix でシステムを構築、ピツニーボウズ Predix の上に独自のマイクロサービスを構築し、それを販売した。 ここだけ読むとプラットフォームとして成功してそうだが、今は畳んでるし期待ほど伸びなかっただけなんか、或いは。この本だけだといい所しか書いておらず正しく評価できないな。

2026-01-26

GE 巨人の復活 シリコンバレー式「デジタル製造業」への挑戦, read count: 1, page: 138 ~ 165, pages read: 28

第 5 章。 GE が開発したサービス。 GE が Predix を作ったのは産業機器のデータを収集・分析する資産のためのシステム(System of Asset)がなかったから。 SoR ではだめ。エッジデバイスも提供する。 ミドルウェア・マイクロサービス・業務システムの三層。ミドルウェアは OSS と 3rd party の SaaS 。大部分で OSS を利用して最新技術に追いつく戦略。大量のセンシングデータを分散処理して関連付けをグラフ DB で行う。 この章の内容は技術史として正確じゃなさそうなので程々でいいかとに思った。そういうナラティブにしたかったのだろうが Google そっくりというのはちょっと雑な気がした。

2026-01-25

GE 巨人の復活 シリコンバレー式「デジタル製造業」への挑戦, read count: 1, page: 104 ~ 137, pages read: 34

第 4 章。 GE の開発手法。 リーンスタートアップの GE 版 FastWorks をデジタルに留まらず全社的に使う。顧客に要件定義させず自分たちでヒアリングして MVP を作る。 課題の解決策はデザイン思考でアイデア出しする。リーンスタートアップの源流にあるリーン生産方式の現地現物も取り入れている。開発はアジャイルでペアプログラミングを取り入れる。 この様なスピード感のある手法に対応できる組織ではなかったので、組織の単純化・権限移譲で変化しようとした。 デザイナーがファシリテーターとして機能する。データサイエンティストは科学者として活動する。コラボレーションを促進するオフィス等、 GE はこれらのシリコンバレーの規律を学び取り入れた。 今ではよく知られたプラクティスで特に気になるでもないが、仮に GE デジタルが解体されてもこれらが文化レベルで浸透していれば、今の GE は組織として次のステージに進めていると考えられるな。実態はどうかしらんけど。

2026-01-24

GE 巨人の復活 シリコンバレー式「デジタル製造業」への挑戦, read count: 1, page: 78 ~ 103, pages read: 26

第 3 章。 GE のデジタルサービスについて。 Airbnb や Uber 同様に、既にある資産、 GE の場合は販売した産業機械から得られる収入を最大化するサービス。 産業機器の CAD データから得られた物理モデルとセンシングデータから生み出した機械学習モデルが鍵。 Google や Amazon に比べてデータ量が少ない点や産業機器に求められる高精度さを物理モデルのシミュレーションでカバーする。 サブスクだけでなく成果報酬型も揃える。 様々な産業機械のデータをつなげたデジタルスレッドが故障予測だけでなく産業機械や施設の運用効率化を生む。 長年蓄えられた産業機械のドメイン知識とセンシングデータの統合しやすさが GE の強み。 本書の時代が多少古いのもありちょっとデータ分析におけるデータ収集部分を甘く見てる感じはするな。 データが汚いとか。例え同じ会社でも組織が異なればスキーマの調整はそううまくいかんやろう。 ビジネスの構造としては至極まっとうな感じがしたので、ビジネスを進める中で顧客が着いてこれなかったとか GE 内での連携がうまくいかなかったとかあるんやろな。

2026-01-23

GE 巨人の復活 シリコンバレー式「デジタル製造業」への挑戦, read count: 1, page: 24 ~ 43, pages read: 20

第 2 章。 GE デジタルの誕生。 報酬は並だが、シリコンバレーの穴場に居を構えて中心地の物価高騰や通勤疲れのエンジニアをターゲットに変革に参加できるというビジョンを売り込んだ。 GE 外から大量のエンジニアを雇用。リーンスタートアップとアジャイル開発を導入。 自社製品だけでなく他社製品も繋げられる IoT ネットワークで製造業のプラットフォーマーを目指した。 調べたら結局 GE デジタルも Predix も解体され各事業部の内部組織に組み込まれたみたいなので、外部から人を集めたのも含め典型的な Center of Excellence の失敗例みたいな感じかな。 素早く立ち上げるには CoE がいいんやろけど。 にしても立地を採用戦略に使うのは面白いな。

2026-01-22

GE 巨人の復活 シリコンバレー式「デジタル製造業」への挑戦, read count: 1, page: 24 ~ 43, pages read: 20

第 1 章。 GE がデジタル参入するまで。 リーマン・ショックで金融事業がダメージを受けて製造業へ回帰する際に、デジタルディスラプションに対抗するため本業である製造業を DX しようとした。 GE にとってはメインフレーム、 IT アウトソーシングに続いて 3 度目のデジタル参入だが、本業をデジタル化するのは初めて。 スタートアップがメディアやエネルギーや医療などの GE の中核事業を蹂躙したのに加え、 IBM が GE の顧客の業界にデジタルサービスを売る戦略を進めたので、対抗するにはそれしかなかったともいえる。 シリコンバレーの流儀を学び、デジタル事業部門も立ち上げた。 ①自社の製造事業をデジタル化により効率化する、②販売する機器のデータを収集して効率的な運用や故障予防といったサービスを販売する、③自社の製造業デジタル化に伴い開発した技術を新しい顧客に販売する、3 つの戦略。 デジタルに舵を切った理由は分かるが製造業に回帰した理由ははっきり書いてないな。祖業で実績があるから勝てると見たとかかな。

2026-01-21

GE 巨人の復活 シリコンバレー式「デジタル製造業」への挑戦, read count: 1, page: 1 ~ 43, pages read: 43

TEAM OF TEAMS で GE に触れられてたし良い機会なので読む。去年買ってたらしいが理由は失念した。 プロローグ。ウェルチが脱製造業を進めていたのに対し、リーマンショックの金融事業の打撃を受けてウェルチ路線が会社を危機に陥れたとイメルトは考えた。 製造業回帰を目指し、脱製造業の内に起こったデジタルディスラプションを乗り超えるために DX に取り組んだ。 変化をいとわない GE の学ぶ文化は変わらないまま、ウェルチ時代が日本の製造業の生産方式から学んだのと同じ様に、イメルトはシリコンバレーのスタートアップを徹底的に見習った。 GE の DX の話ぽいな。調べたところその後 DX だけでは企業の評価は上げきれずイメルトは退任、巨大になり過ぎた会社は分割されコングロマリット時代は終わった、みたいな感じかな。 ウェルチ時代を利益追求のためにゆとりを削除した効率化と捉えれば、複雑化した時代に対応するためにイメルトが組織を作り直そうと方向転換しようとしたのはわかりやすい。

2026-01-20

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

第Ⅴ部 第 12 章。謝辞。 敵から学んだネットワークの力により、効率的なマシンから適応力のある複雑な生命体となり、敵を凌駕した。 トクヴィルが民主制の分散型統治に背景理解と権力分散が必要なことを見出したのと同様に、マネジメントにおいても意識の共有と実行権限の付与が必要とされる。 一見危険で無秩序に見える状態も、旧来のメンタルモデルに縛られ新しい発想を受け入れられないだけかもしれない。 テイラーが工業化により新たなマネジメントを生み出したように、チームのなかのチームも複雑さを生み出したテクノロジーそのものによって生まれた新たな組織構造といえる。 本書はこれで終わり。技術も進歩と組織構造の変化が対になるイメージは情報量がポイントなんやろな。 原注の参考文献も気になってた本が載ってるしまた積読が増えそう。面白かった。また読もう。

2026-01-19

ファスト&スロー あなたの意思はどのように決まるか？, read count: 1, page: 1 ~ 36, pages read: 36

序論。輪読会で読み始めた。 直感のバイアスとそのエラーを知る。ヒューリスティックとバイアス、意思決定といった研究成果を見ていく。 速い思考システム 1 と遅い思考システム 2 。ヒューリスティック、バイアス、そして記憶に基づく直感的解決はシステム 1 。 その後熟慮熟考のシステム 2 へ切り替わる。認知心理学が研究の軸足だが、意思決定のプロセスをモデル化したから経済界隈に喜ばれたって流れっぽいな。

2026-01-19

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

第Ⅳ部 第 11 章。 現代のリーダーシップは、かつての英雄的リーダーが全てを制御するものでなく、文化を想像することに変わった。 情報の透明性が高まっても、その膨大な情報を処理仕切れずボトルネックになる。 それに代わり、チームが自律的な行動を取れる環境を菜園主のように手入れするのが現代のリーダーシップで極めて重要であり、またその仕事はリーダーでしかできない。 マイクロマネジメントすべきでないという話はよくあるが、本書の場合は情報の透明性を高めた結果として膨大な情報量と極めて速い状況変化の前提があるから、リーダーがボトルネックになる話の裏付けになって、いいな。

2026-01-18

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

第Ⅳ部 第 10 章。 情報の透明性と信頼による意識の共有がパフォーマンスを向上させたが、最後に意思決定のボトルネックが残っていた。 実際に意思決定を上位層に集中させても、意思決定の品質が高まるわけでなく、むしろ現場に意思決定を委譲した方が迅速かつ的確になる場合が多い。 裁量の拡大と意思決定の集中の例としてペリー提督。権限移譲の例としてリッツ・カールトンとノードストロームを挙げる。 この章もマネジメントの文脈で学んだ内容。ヒト自体がボトルネックになる以上、分散化するしかないんやろな。

2026-01-17

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

第Ⅲ部 第 9 章。 従来の組織構造は情報の不透明性と組織感の競争から囚人のジレンマに陥っており、情報の透明性と信頼の欠如が最善の結果を妨げていた。 信頼関係を築くには時間がかかるが、チームの要員を相互に交換することが互いの目的を理解し全体像を育むことで、信頼関係を築くことになった。 囚人のジレンマの例として、 20 世紀は順調だったがその後苦境に立つ GM と、苦境をワーキング・トゥギャザーで乗り越えたフォードの対比。 情報の透明性と信頼関係が、意識の共有によるマネジメントにおける重要な 2 要素。 交流が生産性を高めるのはペンドランドの研究でも示されている。 この章も見たことあるような話やな。 GM の話は積読してる GM の本に載ってるのかも知れんし読む動機付けされた。

2026-01-16

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

第Ⅲ部 第 8 章。 仕事場の物理的な配置がコミュニケーションに与える影響。一般的な整理されたオフィスほど阻害され、一つの場所に集まるほど促進される。 例としてベル研究所やブルームバーグ時代のニューヨーク市庁舎。 物理的な配置に加え、常に最新の重要な情報が関係者誰にでも手に入る状況とコミュニケーションチャネルを作る。 得られる情報が有用だとわかれば人が自然に集まりコミュニケーションが促進される。 情報の透明性には漏洩のリスクが伴うが、情報を規制することよりも得られる利益の方が大きい。 デマルコ氏の著書で見た話と同じ。にも関わらずキュービクルに労働者を詰め込み近視眼的に仕向ける組織は多い。 経営の予測性を高めるためことと、知性の創発を促進することは相反するようだが、適応すべき領域にあわせてバランスを取るべきなんやろな。バランスが取れてないところが多いのだろうけど。

2026-01-15

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

第Ⅲ部 第 7 章。 NASA がソ連に対して大きく遅れていたのを挽回したのは、ジョージ・ミュラーが組織のマネジメントをシステム思考的に変えたことが大きい。 片や要素還元的な ELDO は組織のブリンクで 5 度の失敗を重ねて解体された。 相互依存と予測が立たない未知の要素で構成された領域には、最新情報を広く共有し小さなチームで認識を共有することで生まれる知性の創発が重要な鍵となる。 その様な組織文化を運用維持するのに相応のコストがかかることも、 NASA のその後の失敗から学べる。 訓練で予想される問題だけに対する強固な対応力を得るよりも、教育で復元力のある基礎的な能力を培う。 昨日の分は読み直さなくても割と読めてた。創発とシステム思考も読んでないから積読したいな。あとブリンクって表現気に入ってきた。接触不良。

2026-01-14

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

第Ⅲ部 第 7 章。 F3EA(Find,Fix,Finish,Exploit,Analyze)の各段階が如何に高速でも部門間の連携のブリンク(接触不良)は取り除けない。 ブリンクの多くは技術的地理的制約よりも社会的なもの。分業化や機密漏洩を恐れた関係者以外極秘はその最たるもの。 計画がうまくいくには全員が全体の流れに目を向けなければならない。 夜間作業以降寝る時間取れなかったので読み切る体力ない。明日読み直す。

2026-01-13

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

第Ⅱ部 第 6 章。 特任部隊のチーム自体の適応力は高いが、それが命令型の階層化組織の元で束ねられると予測不能な敵にの前に十分に機能しない。 従来の組織は MECE のように重なり合いがないが、共通の目的を持ち信頼関係があるチームには MECE でない重なり≒繋りが必要。チームが信頼関係を築ける人数的な制約。他チームのことを考えないチーム同士の壁。 これらの解決案として「チームのなかのチーム」各チームが他のチームの数人と本当のチームのような信頼関係を結ぶことで互いのチームの相互依存的になるよう仕向ける。 ここに来て人月の神話も出てきた。チームがうまくいく人数規模も Two pizza team に近い。色々繋がってる。

2026-01-12

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

第Ⅱ部 第 5 章。 チームが発揮する能力は個々人の能力の総和を上回る。 軽微なトラブルながら墜落したユナイテッド航空 173 便と危機的な状況でも全員が助かった US エアウェイズ 1549 便の対比は、上意下達の組織の脆さとチームの適応力を示している。 ネイビーシールズは類稀なる個々人の能力を持つが、本質は地獄の訓練 BUD/S で培われたチームワークにある。 ユナイテッド航空 173 便の悲劇の本質は、技術が発展し難解でなく複雑化したコクピット、機長が単独で全てを理解しようとしたチームワークの欠如にある。 CRM(crew resource management) の導入により事故数は著しく低下したのは、緊急事態にチームを形成して共通の目的に邁進する能力が向上したため。 特殊部隊もその成り立ちは同様だったが、さらなる複雑化に対応するために大規模な組織全体をチーム化する必要があった。 共通の目的に向かう情熱があってのチームというのはデマルコ本などでも触れられていたのと同じ。ほぼ一人で仕事してるとこういう情熱があるチームはやはり憧れるな。

2026-01-11

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

第Ⅰ部 第 4 章。 復元力(resilience)とは「システムが混乱を吸収し、なお基礎的な機能と構造を保持する力」をいう。 例としてオランダの流水管理の方針転換。効率化は不測の事態に対する復元力を損なう。 効率化≒専門化で予測の範囲外の事態に対応できなくなる。強固さが弾力性を損なう。 階層化組織は上意下達の効率化で対処すべき問題が別れている限りは問題ない。 ただしネットワーク型の組織に対しては無力で、対抗するには同様にネットワーク型の組織に変化する必要があった。 デマルコ氏の著書で触れられてた話と同じだ。極度に最適化されてゆとりが無い組織は急激な変化に対応できない。

2026-01-10

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

第Ⅰ部 第 3 章。 ローレンツのバタフライ効果。複雑と難解は異なる。 複雑系は要素間の相互依存性により非線形的に振る舞う。それが影響を及ぼすのかどうかも事実上予測不可能。複雑系の例として気象・経済・ NGO ・外来種等。 複雑さは予測を前提としたマネジメントと根本的に相容れない。ビッグデータでさえも、複雑な現象が如何に起こったかを知るのには役立つが、予測には役立たない。 昨日感じた技術の進化が世界の変化の速度を高め従来の組織構造が通用しなくなったという話と繋がる。 参考とする文書も凄く多いので積読候補やな。

2026-01-09

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

第Ⅰ部 第 2 章。 従来の戦場では厳しい訓練で培った厳密な標準化と統一性が戦場という特殊な状況に予測可能性と秩序をもたらしそれが素早く効果的だった。 フレデリック・ウィンスロー・テイラーと要素還元主義の例。産業の機械化により手工業の時代よりも複雑な作業が必要となったが、標準化により効率性を高めた。 この考えが階層化組織の基礎。米軍特任部隊も同様だったが、全く新しい敵に直面したことでそれらを捨て去る必要があった。 産業の機械化のくだりで漸くわかったが、この環境の変化と組織構造の対比って、つまり環境が技術の進化によって変わる速度に組織構造の変化がついていってないという話やねんな。 階層化組織の構造は意図的に手を加えないと変わらないので、うまく行かないことに気づいたときかなり遅れてると。 常に変化し続ける必要があるわけ。

2026-01-08

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

第Ⅰ部 第 1 章。 AQI のような情報化された相互関連性と即時伝達能力を活かし、分散ネットワーク化して常に変化する敵に対応するためには、効率性を重視した従来の組織ではない環境に対する適応能力が必要となる。 そのために透明性の高い情報共有(意識の共有)と決定権の分散化(実行権限の付与)の方針のもと、小規模チームが結合した有機的で柔軟な組織に変化する必要があった。 歴史からの学びとして、ネルソン提督の本当の才能は、撹乱作戦よりも部下に自律と批判的思考を育て上げた日頃からのマネジメントとリーダーシップであるととく。 章末のポイントがよく書かれてて自分でまとめるまでもない気もするが何とかひねり出して自分の気になったところをまとめる練習としておく。

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 は考え方として当たり前なので普段意識しないが、去年古典に触れたり読み直した本で得るものがあったし、改めて読むのも良さそうに思った(あと頁数がちょうど良い感じだった)。