Semantic Software Design - Chapter 2. The Production of Concepts

2章の途中まで流し読み。抽象度の高い話が続いていて、咀嚼できない。実践的な話だけ拾い集めて読む。3章に入ると「脱構築」や「デリダ」とか出てくるぽくて、そこまで風呂敷広げるんかい〜 。そういうこともあって、Google 翻訳 / DeepL 翻訳で読んでるとちょいと辛い感じがある

Part of the work of the new architect-creative is to help create those requirements, both functional and nonfunctional. To see what needs to be done, what might work, what structure accounts for what we think we want the system to do, or what we think someone else we’ve never met might want or need the system to do three years from now when it’s harder to change and how to accommodate that.


This book has a single primary purpose among many purposes: to help you better design software. To do so, it advances a new model, a new approach, a new set of ideas and tools called semantic software design.


抽象度の高い話が続いていて迷子になりそうなところで、なんのための本なんだっけ? を改めて再確認する

The problem with software—a chief reason our projects fail—is a failure of our language. We are not architects. Not even close. We do not build buildings with an obvious and known prior purpose, which is an approximate copy of the same kind of building people have been making and using for thousands of years, using tangible commodity materials on a factory line. Quite the opposite.


あんちぽさんか、しばたさんが、ソフトウェアってコード書き出すまでは頭の中にあるもんだから みたいな話をずっと前にしてたの思い出す。

Accomplish, Avoid, Fix

To be useful in a typical software project, your concept will generally be about one of three things: accomplishing something, avoiding something, or fixing something:



顧客が達成したいこと、避けたいこと、修正したいことを考える。文章で、この質問に答えてください。 誰が、いつまでに、どのような理由で、何を望んでいるのか?

Divergent and convergent thinking

As you work through your concept, you should go through two stages, divergent thinking, followed by convergent thinking.



convergent thinking は以下の通り続く

1. What absolute constraints are known?
2. How might these candidates fit within a budget, if known?
3. How might these candidates fit within a timeline?
4. What known elements of the business or technology strategy do these candidates support?
5. What new opportunities does this create?
6. What positive and negative elements of our current landscape of People, Process, and Technology does this enhance or aggravate?
7. What people or roles would need to approve or work together with these candidates?


ここで 著者の Concept Canvas が図示で紹介される


1. Concept statement
2. Statement of need
3. Alignment with strategy
4. Idea components
5. Path forward


Semantic Software Design - Chapter 1. Origins of Software Architecture

1章を流し読み。目に留まった箇所の引用を掲載する。引用の翻訳は DeepL による。

This is a way of saying that software didn’t even know it existed as its own field, separate from hardware, a mere 50 years ago. Very smart, accomplished professionals in the field were not sure whether software was even a “thing,” something that had any independent value.



The term “architect” as used in software was not popularized until the early 1990s. Perhaps the first suggestion that there would be anything for software practitioners to learn from architects came in that NATO Software Engineering conference in Germany in 1968, from Peter Naur:

ソフトウェアで使われる「アーキテクト」という言葉が一般化したのは、1990年代初頭のことです。おそらく、ソフトウェアの実務家がアーキテクトから学ぶべきことがあるという最初の提案は、1968年にドイツで開催されたNATOソフトウェアエンジニアリング会議において、Peter Naur氏からなされたものでしょう。

提案自体はずいぶんと古いものらしい (ただし、続く本文で The problem with Naur’s statement is obvious: it’s simply false. It’s also unsupported. として、声明自体が間違っていると主張されている)

Dividing roles into distinct responsibilities within a process is one useful and very popular way to approach production in business. Such division makes the value of each moment in the process, each contribution to the whole, more direct and clear. This fashioning of the work, the “division of labor,” has the additional value of making each step observable and measurable.

ビジネスにおける生産活動のアプローチとして、工程内での役割を明確に分けることは有効であり、非常によく知られている方法の一つです。 このような分割により、プロセスの各瞬間の価値、全体への各貢献がより直接的かつ明確になる。このような仕事の組み立て、すなわち「分業」には、各ステップを観察し、測定できるようにするという付加価値もある。

GitHub Actions で一個のステップ実行時間が長くデバッグが大変だったのを、分割して解決しようとした ... というのを思い出したりした。その他、日々の開発でも意識せずにやってることもあるだろう


インシデントマネージメントについての覚書エントリ - Modern System Administration By Jennifer Davis

12 Managing Incidents の章で オンコール対応とインシデント管理についてページが割かれていた

12. Managing Incidents

インシデント管理の目的を The aim of incident management is to minimize the damage, costs, and recovery time. と唱えてから

  • インシデントの定義は組織によって異なる
  • Blameless な組織文化
  • 役割と責任の分担
  • コミュニケーションの確立
  • インシデント後のふりかえり ( postmortem, after action review ... )

... あたりをさらっと触れている内容だ。よく見かける感じのサブテーマ・構成で書かれている。SRE 本や PagerDuty のドキュメントあたりを読んだことがある人なら、目新しい記述はさほど多くはないだろう。

可観測性とか IaC とか デファクトになった感のあるテーマも抑えてあって、「なるほど これがモダンか」と、さらっと読み流すのによいボリュームの書籍

toruby 175th に参加しました - セコンさん おいで那須

juen29 さんと連れ立って、セコンさん ( @hotchpotch ) さんが初参加の回でした。おいで 🍆 〜



セコンさんの Python トークが主題。

Python の言語仕様の話 (Ruby と比較して言語のパラダイムを比較する ) から、型ヒントの話、機械学習の話までだーっとお話を聞かせてもらう回だった。内容がすごい密度なんだけど、用語や論旨が的確でわかりやすいの、さすがセコンさん節って感じで、懐かしい気分にもひたれた。



会が終わった後に、よねざわさん, セコンさん、june29さんと フライングガーデンで肉

↓ に載ってる系列店。

いまいまは 会食もできる状況なので、よかったよかった。

この辺だと自転車のお店はどこなんだ? とか、みんな どこで知り合いになったのだ? とか、観光にくる人の那須塩原と住んでる人の那須塩原のイメージの食い違いだとか ... そんな話をした。

CloudNative Days Tokyo 2021 「インシデントレスポンスを自動化で支援する - Slack Bot で人機一体なセキュリティ対策を実現する」の発表を終えた - アーカイブ動画の宣伝とふりかえり


2021年11月4,5 日の日程で CloudNative Days Tokyo 2021 がオンライン開催されました。

私は GMOペパボの事例をひっさげて インシデントレスポンスを自動化で支援する - Slack Bot で人機一体なセキュリティ対策を実現する というタイトルでの発表でした。このエントリで、資料をまとめておきます。





PDF もダウンロードできます。

スライド内で引用している書籍やブログのリンクを開きたい場合は、PDF でご覧になるとよいでしょう


twitterはてなブックマークでも いろいろなコメントをいただいており、発表して確かに手応えがあった感じです



しかしながら、現実にはちょっとした綻びでもって可用性・信頼性・完全性が失われてしまい 「インシデント」を引き起こします。平時とは違う緊急のプレッシャーに晒されて対応する人々を支援・組織化するインシデントマネジメント ( 組織の力 + エンジニアリングでの支援 ) を整えておくことで、高いレジリエンスを獲得できるでしょう。

障害対応やセキュリティインシデント(の疑いがある事象) についての対応などは 公開するのが難しいところもあるでしょうが、知見や取り組みをオープンにディスカッションできればと思っています。


CNDT 運営のみなさま ありがとうございました!