「プラットフォームエンジニアリング ―成功するプラットフォームとチームを作るガイドライン」を読んでいる。プラットフォームの作り直しである新バージョン（V2）戦略はうまくなく、現在のものを改善（リアーキテクチャ）することが良いという話が出てくる…

いま「AIエージェント 人類と協働する機械」を読んでいる（良い本だ）のだけれども、その中でずいぶんと懐かしい話が出ていた。それはMicrosoft Windows Vistaのリポジトリと組織に関する研究だ。いわゆるコンウェイの法則の話だけれども、改めていろいろ読…

先日書いた「ソフトウェア開発で「なぜなぜ分析」はアンチパターン」という記事には想定外の反響をいただいた。読んでいただいた方、コメントされた方には感謝する。勉強させていただいた。コメントは全て目を通していると思うが、寄せていただいた意見を参…

なぜなぜ分析、根本原因分析、RCA（Root Cause Analysis）、5 Why手法はソフトウェア開発に適用すべきではなく、アンチパターンだと思っている。何度も説明するのが面倒なのでここにその理由を書いておく。なお、超シンプルで小さなソフトウェアには有効かも…

ちょうど読んでいる本で見かけた「多元的無知」という言葉について興味を持ったので、いろいろ調べたという話。ソフトウェア開発における多元的無知の現象について考えたこと。調べるきっかけとなったのは以下の記述である。 個人レベルでは育休取得に肯定的…

良い言葉を知った。これまでの知識では「縮退運用」なのだけれども、この言い方はネガティブなイメージが強い（縮とか退とかどっちもね）。今後はグレイスフルデグラデーションと言おう。言い方は重要だ。言いにくいので３回くらい声に出して練習した。 翻訳…

いわゆるエンタープライズ向けソフトウェア開発技術者向けにお勧めする本をまとめてみた、というか10年くらい前に書いた記事を見直したもの。後輩から「後輩に勧めたい本を教えてください」という相談を受けることがあって（白目）記事が古くなっていたこと…

牛尾さんの「納期がなぜ生産性をぶち壊しにしているのか？」という記事を読んで考えたこと。あるいはインターネットが屑情報ばかりになってしまう現象への個人的な抵抗。

先日、オライリーのSNSキャンペーンで当選して「プロダクトマネージャーのしごと 第2版 ―1日目から使える実践ガイド」をプレゼントいただいた（皆さんも根気強く申し込みましょう）。自分は普段プロダクトマネジメントを仕事としているわけではない（サポー…

先日読み終わった「みんなのフィードバック大全」が面白かったのだけれども、ふりかえってみるとフィードバックというテーマの本は他にも何冊も読んでいた。おそらく深層意識のどこかでフィードバックに関する課題感を感じているのだろう（大げさ）。復習も…

SNSのタイムラインで「記者ハンドブック 第14版 新聞用字用語集」が話題だったので手に取ってみたら非常に良かった。現代では短文で明確なコミュニケーションをすることの重要性が高まっている。校正ツールに頼れば良いという考え方もあるだろうが、理屈を知…

ソフトウェア開発における要件定義では「要件定義ではHowじゃなくWhatを語れ」とか「UIの議論の前にシナリオ／ユースケースを整理しろ」という話を最近何度かすることがあった。この考え方は過去のいろいろな学習経験とプロジェクト経験から来ているのだけれ…

最近よく聞いているSRE系のポッドキャスト e34.fmのep17で紹介されてた、GoogleのSRE本シリーズの最新作(?)「Anatomy of an Incident（インシデントの解剖学）」を読んだメモ。ポストモーテム（検死解剖）から展開して、Anatomyは解剖学というわけだ。sre.go…

最近読んだ「Web世代が知らないエンタープライズシステム設計」はとても刺激的で良い本だった。企業の情報システム部門およびエンタープライズシステムを受託開発するSIerの中堅技術者は必読だと思う。ただ、書籍タイトルは中身を分かりにくくしている気がす…

「チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計」で紹介されていた「Building Successful Communities of Practice: Discover How Connecting People Makes Better Organisations (English Edition)」が気になったので調べてみたら…

今、「ブリッツスケーリング」を読んでいるのだけれども、ゼネラリスト育成についての説明でGoogle APM（Associate Product Manager Program）が紹介されていたので、オッと思っていろいろと調べてみた。APMをゼネラリスト育成プログラムとしては見ていなか…

有名なソフトウェアのバグ事例の一つにNASAのマーズ・クライメート・オービターの事故というものがあるのだけれども、これをデータソース全体の整合性やクレンジングの重要性を説明する際に使うというのは良いアイデアだと思ったのでメモ。 マーズ・クライメ…

数年前に流行したソフトウェアアーキテクチャのメタファー（？）として「式年遷宮アーキテクチャ」というものがある。最近自分が日本美術史の授業で聞いた話を踏まえると、われわれエンジニアは式年遷宮をちょっと誤解しているような気がする、という話。い…

約10年前にいくつか邦訳されて話題となった「〇〇が知るべき97のこと」という技術書シリーズがある。このシリーズが最近復活したようだ。〇〇には現代的なエンジニアロールが入っているので面白そう。翻訳されるかと思ったけれど、その気配もないので原著で…

先日「Project Retrospectives: A Handbook for Team Reviews (Dorset House eBooks) (English Edition)」を読んだばかりだけれど、別の調べ物をしていたら「Retrospectives Antipatterns」という本が最近発売されたことを知ってしまったので勢いで読んでみ…

読むのが骨な（積みがちな）技術書やビジネス書を取り上げて２週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第17回。今回はSteve McConnell氏の「More Effective Agile」後半部分（13章以降）がノルマである。最高にオス…

対象を決めたら2週間で読み切り、アウトプットして、感想戦をするという読書会企画の第15回。今回の対象は『他者と働く』である。この本は一度読んでいたので再読になる。良い本なのだけれども、なんだろう、この違和感は。他者と働く──「わかりあえなさ」か…

ウィズコロナなのかアフターコロナなのかはよくわからないけど、今回の新型コロナ感染拡大の事態を踏まえて分散アジャイルについての勘所について整理しようと思って、いろいろな調べてみた。世の中にはTips集と精神論ばかりが溢れている気がする。知りたい…

対象を決めたら2週間で読み切り、アウトプットして、感想戦をするという読書会企画の第14回。今回の対象は『チーム・ジャーニー』である。味わい深い本であるため、2回に分けることにしていて、今回は後半である第２部および全体の感想だ。前半の感想はこち…

対象を決めたら2週間で読み切りアウトプットしてから感想戦をするという読書会企画の第12回（意外と続いている）。今回の対象は『みずほ銀行システム統合 苦闘の19年史』である。みずほ銀行システム統合、苦闘の19年史 史上最大のITプロジェクト「3度目の正…

趣味の情報システム障害状況ウォッチ。前回に引き続き、今回も駆け足で確認。元ネタはこちら。みんな見たほうが良いよ！ www.ipa.go.jp これまでのウォッチ履歴 情報システムの障害状況ウォッチ（2019年前半） - 勘と経験と読経 情報システムの障害状況ウォ…

How Complex Systems Fail – Perspectives の記事で紹介されていた「複雑なシステムはどのようにして失敗するのか(How Complex Systems Fail)」という論考が興味深かったので紹介する記事。 How Complex Systems Fail(PDF) 詳細はリンク先のPDF参照だが、紹…

名前だけは知っていた有名なソフトウェアトラブルの事例。「巨大システム 失敗の本質―「組織の壊滅的失敗」を防ぐたった一つの方法」という本で詳しく語られていたのを見て興味が沸いて、いろいろ調べてみた。今は調べたことを、少し後悔している。巨大シス…

趣味の情報システム障害状況ウォッチ。前回に引き続き、今回も駆け足で確認。元ネタはこちら。みんな見たほうが良いよ！ 情報システムの障害状況一覧：IPA 独立行政法人 情報処理推進機構 2018年後半（7～12月）の傾向 2018年前半はかなりハイペースで障害が…

DevOps関連の書籍（DevOps HandbookやEffective DevOpsなど）やPostmortem関連の記事でよく引用されている書籍「ヒューマンエラーを理解する―実務者のためのフィールドガイド」について調べたメモ。ヒューマンエラーを理解する―実務者のためのフィールドガイ…