勘と経験と読経

略すとKKD。ソフトウェア開発やITプロジェクトマネジメントに関するあれこれ。

GoogleのSRE本の続編(?)「インシデントの解剖学」を読んだ

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

sre.google

本書は書籍の体裁をとっているが、無料でPDF/EPUB/MOBIがダウンロードできる。O'reillyのサブスクにも収録されている。
learning.oreilly.com

全般的な感想

インシデント管理に特化した最新のまとめ小文書という印象。インシデント管理の周辺は適応課題というか悩ましいことが多いので興味深い。GoogleのSRE本やエンジニアリング本は良い本なんだけど、インシデント管理まわり以外の話題も多くて読むのも骨だから本書を手始めにすると良さそう。一方で、あまりディープなことが書かれているわけではない。

ちなみに、インシデント発生時の対処方法であるインシデントコマンドシステム(本書でも推奨されている)について興味があれば「システム障害対応の教科書」がとてもよかったのでオススメしておく。

システム障害対応の教科書

興味深いと思ったのは、インシデント対応メンバーの燃え尽き症候群を防止するために、ものすごく配慮をしているという点だ。Googleではパンデミック以降に大きなインシデントの増大があったそうだが、そのあたりの学びが反映されているのだろうか。対応期間も3日以内と制限され、様々なケア(事前の訓練も含まれる)がほどこされている。確かに現代においてはエンジニアが最も重要かつ希少なリソースであるため、ここを守ることに注力するのは正しいような気がする。

各章に関する覚え書き

1. Introduction(はじめに)

  • 失敗は避けられない。変化は常に予想できない。よって準備が重要
  • COVID-19パンデミックによってGoogleはインシデントの増大にさらされたが、10年以上にわたるインシデント管理への投資によってサービスの提供の継続ができた
  • Googleにおけるインシデントの定義:単独で処理できずエスカレーションされたもの、即時要対応、組織的な対応が必要
  • インシデント管理ライフサイクル:準備、応答、緩和と回復

2. Practicing Incident Response Readiness (Preparedness) インシデントレスポンスの準備

3. Scaling Incident Management (Response) 大規模インシデント管理

  • 階層的なレスポンダー:コンポーネントレスポンダーとSoSレスポンダー
  • Googleにおける2種類のSoSレスポンダー:Product focused IRTと、Tech IRT
  • 共通プロトコル、信頼、尊重、透明性
  • バーンアウト対策:対応期間の制限(3日以内)で人を守る

4. Mitigation and Recovery 緩和策と回復方法

5. Postmortems and Beyond ポストモーテムおよびその後

  • "Googleでは、Ben Treynor Slossが四半期ごとに「Google’s Greatest Hits and Misses」というレポートを発行して、過ちから学ぶことができる力を与える文化を育んでいます"
    • 読みてぇ!が、ちょっと調べた感じでは公開はされていないっぽい
  • ポストモーテムでは、インシデントにおける根本原因とトリガーを区別する
  • システム思考(holistic systems thinking)

6. The Mayan Apocalypse: A Real-World Example マヤの黙示録(現実の例)

7. Conclusion and Moving Forward 結論および今後について

  • インシデント管理に投資する
  • 人の問題に対して備える
  • 改善を繰り返す。ヒロイズムに陥らないようにする

エンプラ技術者の知識継承がうまくいっていないかも、という話

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

さて、同書の冒頭で書かれている、エンタープライズシステム設計に関するノウハウ継承が世代間でうまくいかなたったのではないか、という問題提起が気になったので、考えたことを書いてみようと思う。

Web世代が知らないエンタープライズシステム設計

何がエンタープライズシステム開発のノウハウ継承を阻んだのか?

Web世代が知らないエンタープライズシステム設計」では、2つの要因によって00年前後にエンタープライズシステム開発のノウハウ継承が阻まれたという仮説が提示されている(ノウハウ継承の場であるワイガヤが失われたという文脈)。提示されている2つの要因はこれだ。

私見だが次の2つの「波」を受けた時から議論をする雰囲気、すなわちワイガヤが失われていったのではないか。1つの波はオープンシステムである。企業でしか所有できなかった大型汎用機(メインフレーム)を使う時代から個人でも買えるPCで開発し、動かす時代がやってきた。もう1つは日本企業に目標管理制度が導入され残業規制が厳しくなったことである。


Web世代が知らないエンタープライズシステム設計」はじめに、より引用

うーん、どうだろう……

要因1:技術パラダイムの転換 ⇒ 大小のパラダイムシフトに翻弄されたというのはあるかも

本書では大きな技術パラダイムの転換、すなわちメインフレームからオープンシステムへの移行が大きな要因だったと書かれている。しかし実際にはそれ以外にも様々なパラダイムシフトの波状攻撃によって、中核となる技術者の関心が発散してしまったというのが実際のところではないかと思う。

そういえば、「モダン・ソフトウェアエンジニアリング」でもJacobsonが似たような事を言っていた。

今日のソフトウェアエンジニアリングは、未熟なプラクティスによって重大な妨害を受けている。具体的な問題として、以下が挙げられる。

  • エンジニアリングというよりファッション業界でよく見られる一時的な流行の蔓延
  • 妥当性のある広く受け入れられた理論的基盤の欠如
  • 違いがほとんどないにもかかわらず人為的に誇張された無数の手法とその派生形
  • 信頼できる実験的な評価と検証の欠如
  • 業界の慣行と学術研究の分断


モダン・ソフトウェアエンジニアリング」第2章 ソフトウェアエンジニアリングの手法とプラクティス、より引用

ソフトウェアエンジニアリングについては進歩が早いだけでなく、流行もあるので、常に新しいことを学び続ける必要がある。
というよりもむしろ、学ぶことが好きな人にとって、常に新しい学習要素が供給され続けるという状況である。
その結果として、企業情報システムの構築方法という極めて重要度が高いスキルの「深掘り」や「継承」が劣後してしまったんじゃないか、というのが自分の意見だ。

要因2:目標管理制度の導入と労務管理の適正化 ⇒ 共感は出来るけど、もっと包括的な仕事環境の変化が原因なんじゃないか

本書では、目標管理制度、成果主義の導入と残業規制により、技術者が他のプロジェクトメンバーとの意見交換や切磋琢磨しなくなったのが、もう一つの技術継承阻害要因だったと論じている。
これは確かにそう、とも思うのだけれども、より具体的には「フィードバック入門 耳の痛いことを伝えて部下と職場を立て直す技術 (PHPビジネス新書)」で指摘されている問題のほうが大きく影響していそうな気がする。

こうした状況に対して、「私の育て方に問題があるのだろうか? 私はマネジャーに向いていないのでは……」と自分自身を責めている人もいるでしょう。自分の部下に、メンタルをやられて、休職する人が出てくれば、なおさら自分に非があるのではないか? と思ってしまうかもしれません。今の中間管理職の悩みは、非常に根が深いものがあります。 

しかし、そんな悩みを抱える中間管理職の方に、まずは、こうお伝えしたいと思います。
「若い部下が育たないのは、あなたのせいではありません。過剰に自分自身を責めないでください。それは、職場環境の変化によって構造として生まれている現象なのです」と。


フィードバック入門 耳の痛いことを伝えて部下と職場を立て直す技術 (PHPビジネス新書)」第一章なぜ、あなたの部下は育ってくれないのか?、より引用

同書では、

  • 雇用の安定性(長期雇用、年功序列)によって部下を育成する余裕があった
  • 長時間にわたって同じ空間(オフィス~アフター5)で行動をともにしていた。育成を促進する濃密な空間があった
  • 組織がフラット化し、マネージャーの若年化、大量生産が起こったため、上司に学ぶ期間が減った
  • プレイングマネージャーが常態化し、成果を求められるようになったことから、育成余力が減った

などという分析がされている。コレジャナイ?

ちなみに同書は要は、過去は自然に人が育ったが現代では期待できないので、意図して育てるしかない。ではどうすれば、という話が続くのだが強くお勧めしたい
フィードバック入門 耳の痛いことを伝えて部下と職場を立て直す技術 (PHPビジネス新書)

じゃあ、どうすんの?

では、現代のわれわれは、どうすべきなのだろうか。
そんなことがわかっていれば、やっているのだけれども、今のところ私は「これ」という策は見つけられていない。

ただ、少なくとも、何もしなければ人は育たないということだけは確かなのだ。

「セキュア・バイ・デザイン」を読んでいる(2) #デッドライン読書会

読むのがホネな(積みがちな)技術書やビジネス書を取り上げて2週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第40回。常時、けっこうな量の積読があるのだけれども、知り合いと読書期日を約束することによって消化が捗るという仕組み。ここ最近はこんな本を読んでいる。

さて、今回のお題は前回に引き続き「セキュア・バイ・デザイン」である。
セキュア・バイ・デザイン
けっこうな分量があるので、3回に分けて読んでいる。この記事は2回目で、「第6章: 状態の完全性(integrity)の保証~第11章: ちょっと休憩: 保険料の支払いなしに成立してしまった保険契約」までを読んでの感想になっている。

中盤を読んでの感想

  • とりあえず「設計」と「実装」を別の作業者で切り分けるようなトラディショナルなエスアイアーさん向けの本ではない
  • DDD章(7章まで)では設計をミスると、どんなひどい目に合うかという事例が豊富で学びは深い
  • 8章以降は別の観点で開発プロセスとセキュリティ(というかシステム脆弱性)の観点に関する様々な知見が取り込まれていて刺激的だ

中盤まで読んだところで、改めて著者の以下の主張である「セキュリティを機能(feauture)ではなく心配事(concern)として捉える必要性」が重要であるということがずっしりと腹落ちしてくる。ここまでに列挙されるあんなことや、そんなことは、はっきりいってテストで見つけるのは無理だ。セキュリティテストを最後にやってOKという判断は現実的ではないということがわかる。

しかし一方で、本書に書かれているような「セキュア・バイ・デザイン」を実際に実行することもなかなか難しそうだ。チーム単位で本書(および本書の前提となるいくつかのDDD本)の勉強会を継続的に開催するなどしなければ、プロダクトへの適用は難しそうだ。そういう意味では本書の展開はなかなかの課題だと思う。

DevSecOps

本書では「DevSecOps」という単語そのものは(たぶん)出てこないのだけれども、一番刺激があった「第8章: セキュリティを意識したデリバリ・パイプライン」は現代で言えばDevSecOpsの話であるとは思う。ただ自分の知る限り、DevSecOpsは外挿的というか「セキュリティに関する考慮を外部から強制する」ものという理解なので、すこし立ち位置は違うのかもしれない。

あとDevOpsのプラクティスとしてよく語られるフィーチャートグルについて、セキュリティ的な脆弱性となる場合があるので特に注意をしてテストをすべきという話は、他ではあまり見ないような気がする重要な論点だと思う。覚えておこう。

次回、完結編

さて、なかなかに難しかった基礎編が終わり、次回は「第3部: 応用編」である。レガシー・コードへの適用や、マイクロサービスでの指針などが語られるそうで、ちょっと楽しみである。

「セキュア・バイ・デザイン」を読んでいる(1) #デッドライン読書会

読むのがホネな(積みがちな)技術書やビジネス書を取り上げて2週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第39回。常時、けっこうな量の積読があるのだけれども、知り合いと読書期日を約束することによって消化が捗るという仕組み。ここ最近はこんな本を読んでいる。

さて、今回のお題は「セキュア・バイ・デザイン」である。
セキュア・バイ・デザイン
だいぶ歯応えがありそうなので、3回に分けて読む予定。この記事は1回目「序文~第5章: ドメイン・プリミティブ(domain primitive)」までを読んでの感想になっている。

本を読む前に:そもそも「セキュア・バイ・デザイン」って?

今回取り上げる「セキュア・バイ・デザイン」の書名は時々耳にする本というくらいしか知らなかったのだけれども、ちょっと改めて調べてみた。

で、本書であるが概説はこのようになっているんだけれども、

プログラミングの質を高めることで、セキュリティを向上させることができる― 著者らの考えを様々な形で試し検証を行い、本書「セキュア・バイ・デザイン(Secure by Design)・安全なソフトウェア設計」にまとめました。

うーん、この文章の説明はなかなかに難しい。

まだ全てを読み終わっていないのだけれども、現時点での私の「セキュア・バイ・デザイン」に関する理解はこのようなものだ。

  • システム設計時にセキュリティだけを切り出して考えるのではなく、システム全体の関心事として取扱い、あらゆる設計時に考慮する。
  • ドメイン駆動設計を利用している場合を想定して、具体的な実例と留意点を示す。

抽象度順に並べると

「セキュリティ・バイ・デザイン」>「「セキュア・バイ・デザイン」」>「セキュアコーディング」

という感じか?

前半の感想

ある種の人にはとても難しい本だろうなという感想である。ある種の人とは具体的には、その、なんというか、エスアイアーみたいな名前の……。良いコード、良いデザインを追求する方法として自然にDDDを採用し、その上でセキュリティをどう扱うか、そういう文脈の本だと思っている。逆に言えば、良いコードを追求しないタイプの開発プロセスを採用していると本書で紹介されているようなプラクティスの導入は難しそうな印象。

あと、2章「ちょっと休憩: 『ハムレット』の悲劇」の原題は「Intermission: The anti-Hamlet」つまり反ハムレットの話なのだけれども、要はECサイトで「シェークスピアハムレットの本」を「-1個」購入できるようになってしまうインシデントに関する話だ。これは、とても興味深い。

ACM会員特典からO’Reilly Learning platformへのアクセス権が無くなる

本ブログで何度か紹介している、ACM会員特典にあるO’Reilly Learning platformのアクセス権が、2022年6月末で終了するらしい。新規に会員登録、もしくは更新する場合は注意が必要である。
komad.hatenablog.com

現在すでに、会員特典を説明するページからも削除されてしまっているので確定なのだろう。

以前は以下の記載があったのだが、現在この記載は削除されている

Access to a custom collection of thousands of online books and video courses O'Reilly , including recorded O'Reilly conferences

Hacker Newsでも取り上げられてるようだ
O’Reilly Learning platform no longer as a benefit of your ACM membership | Hacker News
緩和策として、米国の公立図書館が利用できるユーザーは図書館経由でアクセスできるパスがあるらしい。
あとは、ブラックフライデーに割引となるケースがあるようだが、基本的には通常価格で契約するしかなさそうだ。

うーむ、残念

ソフトウェアプロダクトの80%はほとんど使われないという2019年の調査は条件付きで正しそう

吉羽さんの「大規模アジャイルフレームワークの紹介 | Ryuzee.com」という記事に興味深いリサーチに関する記述があったので調べてみた。Pendoの2019年の調査はいくつかの条件を考慮すれば正しそうだ、という話。

なお、こっちの話はダメという話は以前書いた

2019年にプロダクトマネジメント関連のSaaS企業であるPendoが行った調査によると、ソフトウェアプロダクトにおいて平均的な機能の利用状況は次のようになったそうです。

  • まったく使わない: 24%
  • ほとんど使わない: 56%
  • よく使う: 8%
  • いつも使う: 12%

つまり80%の機能はほとんど、もしくは、まったく使われないということになります。 たくさんの人を集めて、たくさんの機能を作るのは、ムダである可能性が高いと言えます。
大規模アジャイルフレームワークの紹介 | Ryuzee.com

Pendoの「The 2019 Feature Adoption Report」

上記情報の元ネタはおそらくこれ。
www.pendo.io

ざっくり読んだところ、以下の通りのようだ

  • Pendoが保有している3か月分の匿名化データをもとに分析している。このデータには金融/銀行、HR、教育、輸送/物流、ヘルスコア、ECなどの業種が含まれている(比率などは明らかではない)
  • 24%の機能は、まったく使わない(Never Used)
  • 56%の機能は、ほとんど使わない(Rare)
    • 「ほとんど」の定義は、全体の5%の使用率(Last 5% of Usage)
  • 12%の機能は、いつも使う(Frequent)
    • 「いつも」の定義は、全体の80%の使用率(Top 80% of Usage)
  • 08%の機能は、よく使う(Moderate)
    • 「よく」の定義は、81%~95%の使用率に収まる範囲(Next 15% of Usage)

なお、はっきりと明言されていなかったり触れられていない事としては、以下があると思う

  • データは言うまでもなくPendoのユーザとなる。基本的にはコンシューマ向けのアプリケーションに限定されるであろう。エンタープライズ向けの基幹システム等が入っているわけはない
  • おそらくだが、利用データは「Pendoを利用し始めたユーザー」に限定していると思われる
    • はっきりと読み取れなかったのだが、「Pendoを1年間利用することによって、上記比率が大きく改善される」という報告になっているので裏を返せばPendoで利用率が最適化されたプロダクトは取り除かれていると考えるのが自然だろう
  • 一定の信頼性はありそうだが、セールス向けマテリアルという点には留意する必要がある
    • なお本レポートは同社のチーフデータサイエンティストが作成とされているので、あまりおかしな操作はされていないだろう

というわけで、参考にする場合はいろいろ注意が必要だとは思うが、非常に興味深いレポートである

「Team Topologies」後半読んだ #デッドライン読書会

読むのがホネな(積みがちな)技術書やビジネス書を取り上げて2週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第38回。常時、けっこうな量の積読があるのだけれども、知り合いと読書期日を約束することによって消化が捗るという仕組み。ここ最近はこんな本を読んでいる。

今回のお題は先週に引き続きの「チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計」である。
チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計
Kindle版を読んでいるので分厚さが実感できないが、2スプリントに分割。前回Part.2までを読んだので、今回はPart.3以降が対象である。

「チームトポロジー」通読した感想

前回の感想でもこう書いたけれど

非常に良い本だと思うし、本書で使われた用語はしばらく業界内で通用しそうな気がする。中堅以上の、ソフトウェア開発のチームリード的立場の人は必読ではないだろうか。

改めて、中堅以上のソフトウェア開発のチームリード的立場の人、PM、アーキテクト、あとソフトウェア開発組織をマネジメントする人にとっては必読な本だと思う。少なくとも私は、本書を読んだ人とチーム設計の議論がしたい。

一方で、日本の一般的なソフトウェア開発チームの文脈を考えると次のような注意事項があるだろう。

  • 本書が想定しているのは現代的なプロダクト企業、チームである。受託開発プロジェクトで本書をストレートに適用することはできない(もちろん参考にすべきアイデアはあるが)
  • ビジネスとデベロッパーが分断されているような組織構造も想定されていない(統合されている前提のように見える)。「ユーザー部」という単語を使っているチームに本書の内容はそのまま適用できない
  • つまり、一般的なお前には10年早い(死)

というわけで、本書には高い壁があるのだけれども、それを乗り越えて本書が提示する概念/パターンは重要だと思う。本書で紹介されている概念やパターン(本書で言うところのトポロジー)をベースに、自分の組織の現状を描いてみることから始めるのが良いだろう。自分はいろいろ描いてみて、いくつか発見もあった。

「チームトポロジー」後半(Part.3~)の感想

さて本書の後半は「Part.3 イノベーションと高速なデリバリーのためにチームインタラクションを進化させる」である。
このパートは3章で構成されているが、最後の章は本書全体のまとめなので、実質2章である。ここでは、

  • チーム間のインタラクションのパターン(7章 チームインタラクションモード)
  • チーム構造を進化させる戦略(8章 組織的センシングでチーム構造を進化させる)

が語られている。

定義される3つのインタラクションパターンは非常に有用な整理だと思っている(コラボレーション、XaaS、ファシリテーション)。チーム構造を分析設計する際に活用しやすく、独立している。
そしてチームの進化は、まさに逆コンウェイ戦略の要点であると思う。最初から最適なチーム構造を設計実装できることは無いという制約を踏まえて、どう発展させていくかの話は非常に参考になった。

おすすめ復習コンテンツ

というわけで本書を手に取る事をオススメする一方で、読むかどうか悩んでいる方、もしくは読んだ後に復習したい人向けのコンテンツをいろいろ発掘できたので紹介しておく。でも以下を見て読んだ気にはならないほうが良さそう。

Quick Reference Card(QRD)

本書で書かれている内容が「Quick Reference Card(QRD)」としてまとめられているのだけれども、以下のページで日本語訳されているので、ざっくりどんな本か知りたい場合は参照すると良さそう。
scrapbox.io

fukabori.fm

個人的には、読んだ後に聞くのがお勧め。

ちなみにmiholovesqさんが以下のようなこと(不正確かもしれません)を言っていたが、強く共感。

  • Team Topologiesの前提には、アジャイル的文脈の小規模チームと、DevOps(書籍「LeanとDevOpsの科学(Accelerate)」が紹介しているもの)がある
  • エンジニア的資質や上記背景を知らない人が本書を読んで、イキナリ組織設計に走るべきではない

Forkwellさんの勉強会「チームトポロジーを成功させる実践方法の探求 - Team Topologies Study」のアーカイブ

もしかしたら公開期間に制限があるかも……
www.youtube.com

上記勉強会で説明された、訳者のひとりである吉羽さんの資料はこちら
www.ryuzee.com

上記勉強会で説明された、kameikeさんの資料はこちら
timee.notion.site

というわけで、たいへんに勉強になった。さて、次はなにを読みますかね