勘と経験と読経

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

パタヘネを読む（第１章〜第２章） #デッドライン読書会

book Professional Engineer

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

さて、今回からは新シリーズである。通称パタヘネすなわち「コンピュータの構成と設計　MIPS Edition　第6版　上」を読んでいく。いまのところ1スプリントで2章ずつ読んでいく計画だ。
コンピュータの構成と設計　MIPS Edition　第6版　上コンピュータの構成と設計　MIPS Edition　第6版　下

ヘネパタとパタヘネ

ところで本書「コンピュータの構成と設計　MIPS Edition　第6版　上」は通称パタヘネと呼ばれているわけだが、ヘネパタと呼ばれている別の本が存在する。「コンピュータアーキテクチャ[第6版]定量的アプローチ」である。
コンピュータアーキテクチャ[第6版]定量的アプローチ
上記は最新の第６版だが、私が読んだのは第５版だ。どうでもいいけど第６版で翻訳版の出版社が変わっており、Kindle版がなくなった（第６版はPDFは買えるようである）。権利の関係かもしれないが、驚くべきことに第５版のKindle版も販売を中止しているようだ。これはどうなんだ・・・

  • 歴史的には、「コンピューター・アーキテクチャ」（通称ヘネパタ）の後に「コンピュータの構成と設計」（通称パタヘネ）が刊行された。
  • 「コンピュータの構成と設計」（通称パタヘネ）が刊行された後に、「コンピューター・アーキテクチャ」（通称ヘネパタ）は改定されて役割分担が見直され、重複が減るようにされている。
  • 著者は区別がつくように「ヘネパタ」「パタヘネ」にしている（まえがきでそういう話が書かれていて笑った）。
  • 現在の「コンピューター・アーキテクチャ」（通称ヘネパタ）は「コンピュータの構成と設計」（通称パタヘネ）を読んでいることを前提としているが、そうではない読者のための付録がついている（お世話になった）。
  • 「コンピュータの構成と設計」（通称パタヘネ）はタイトルの通りプロセッサを中心とした内容を扱っている。『並列コンピュータ上でプログラムを効率よく実行することをプログラマが望むのであるならば、少なくとも向こう10年間、ほとんどのプログラマはハードウェアとソフトウェアのインターフェースを理解しなければならないだろう』（パタヘネのまえがきより）
  • 「コンピューター・アーキテクチャ」（通称ヘネパタ）は副題の方が大事で「定量的アプローチ」すなわち性能をどう評価するか、という点が主題である。ただし性能を評価するためにはコンピュータ・アーキテクチャを理解せなばならぬ、ということで切り込んでいく本だったはず。私が読んだ第５版ではマルチコアチップやクラウドコンピューティングにも言及されていて大変面白かった印象がある。
  • その他の参考

パタヘネ第１章〜第２章まで読んだ感想

  • まあ知ってたけど、難しい。大学の教科書という趣。
  • 各章の末尾に演習問題が大量についているのだけれども、それを丁寧にやるほどの時間は取らなかった。
  • 少し記憶があいまいなのだけれども、ヘネパタはダウンロード版の付録までは翻訳されていなかったように思う。一方でパタヘネはダウンロード版の付録もしっかりと翻訳されたものが提供されていて、非常に助かる。いっぽうで電子書籍なのだから付録も統合して提供してくれたらよかったのに、とは思う。
  • 本書を読み解く参考資料

各章の感想

1.コンピュータの抽象化とテクノロジ

抽象度が高くて面白く読める章。

  • 「ポストPC時代へのいざない」として、パーソナル・モバイル・デバイス（PMD）すなわちスマートフォンやタブレット、あとウエアハウス・スケール・コンピュータ（WSC）すなわちクラウドなどについても言及されている点は興味深い。
  • コンピュータの構造の例示も、Apple iPhone Xs Maxが対象となっている。分解して構成要素を示すだけでなく、論理基盤、A12チップの集積回路の構成と深掘りしていくところはワクワクした。
  • プロセッサおよびメモリを製造する技術、うっすら理解していたけど一連のプロセスをちゃんと把握したのは初めて。改めて人類すごい。

2.命令：コンピュータの言葉

いきなり難しい、というか読み進めるのに時間がかかる章。以前に読んだ「30日でできる! OS自作入門」に助けられた。

次回

次の2週間は、第３章〜第４章を読む予定。

  • 3.コンピュータにおける算術演算
    • 嫌な予感はある。たぶんビットをたくさん見ることになりそう
  • 4.プロセッサ
    • ここは抽象度が高そう。楽しく読めるといいなぁ

「セキュア・バイ・デザイン」を読んだ（3） #デッドライン読書会

book Professional Engineer

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

さて、今回は3回にわたって読んできた「セキュア・バイ・デザイン」の最終回である。
セキュア・バイ・デザイン
今回は「第3部: 応用編　第12章: レガシー・コードへの適用」から最後まで、いわゆる総集編とまとめである。いやはや、この本は難しかった！

全体を通じての感想

  • 第3部を読んでやっと(?)、著者の主張する「セキュア・バイ・デザイン」の意味を理解できたような気がする。というか（DDDの概念をある程度知っているのであれば）後ろから読んだ方がよかったかもしれない。
  • 先頭から読んでいくと本書はドメイン駆動設計を推奨する本のように見えるが、実際は逆で、現代的なセキュリティ的品質をソフトウェアの設計に練りこんでいくならDDD的なアプローチをすべきという話だったということだ。やっと腹落ちした感。
  • そして、本書が提唱する「セキュア・バイ・デザイン」は、最近バズワード的に使われている「セキュリティ・バイ・デザイン」や「DevSecOps」とも（私の理解としては）まったく異なることがわかる。
    • （私の理解では）「セキュリティ・バイ・デザイン」や「DevSecOps」は上流工程や運用において恒常的にセキュリティを意識することであるが、あくまで外付け／外部から強化するアプローチだと考えている。
    • 一方で本書「セキュア・バイ・デザイン」はユビキタス言語的な世界観の中で、慎重にソフトウェアを設計する（組み立てる）中でセキュリティを達成するという……あー、うまく言語化できない。極めて地道なアプローチである。

しかし、感想文パート2でも書いたけど、これを実現するのはめちゃくちゃ難しいんじゃないだろうか。だいぶ長期戦でチームでアプローチしないと実現できない、という意味ではプロジェクトで採用するのは難しく、プロダクト開発の中で少しずつ近づいていくしかないような気がする。

セキュリティとログの関係について

第3部で一番興味深かったのは、ログの取扱いのあたり。「第12章: レガシー・コードへの適用」「第13章: マイクロサービスでの指針」でもログの扱いについてけっこうな言及がある。
まあ確かに、設計／実装段階で一番意識が不足して、セキュリティが破れてしまうポイントの一つ（盲点）ではあると思う。
最近だとlog4shellの問題もあったばかりだしな……というわけで、このあたりはけっこうメモを取ったのだった。

そしてセキュリティに関する知識を常にアップデートしなければならないという

最終章の「第14章: 最後に：セキュリティを忘れるべからず！」では、結局のところセキュリティを設計に組み込んでいくためには、セキュリティに関する知識の継続的なアップデートが必要であるという身も蓋もない事が語られる。「セキュリティの分野を研究することが重要です」まあ、そうなんだけど……

というわけでなんとか読み切ったのだが、なかなか面白いが内容も難しく、簡単には身につかないような本だった。
さて、次は何を読もうか……

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

Project Management Postmortem book

最近よく聞いている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　結論および今後について

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

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

Professional Engineer Project Management Software Architect

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

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

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

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

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

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

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

うーん、どうだろう……

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

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

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

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

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

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

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

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

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

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

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

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

同書では、

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

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

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

じゃあ、どうすんの？

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

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

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

book Professional Engineer

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

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

中盤を読んでの感想

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

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

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

DevSecOps

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

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

次回、完結編

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

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

book Professional Engineer

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

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

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

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

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

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

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

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

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

抽象度順に並べると

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

という感じか？

前半の感想

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

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

参考

dearjunior.blogspot.com
xn--97-273ae6a4irb6e2hsoiozc2g4b8082p.com

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

safaribooksonline book Professional Engineer

本ブログで何度か紹介している、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
緩和策として、米国の公立図書館が利用できるユーザーは図書館経由でアクセスできるパスがあるらしい。
あとは、ブラックフライデーに割引となるケースがあるようだが、基本的には通常価格で契約するしかなさそうだ。

うーむ、残念