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.
これは、ほんの50年前までは、ソフトウェアがハードウェアとは別の独立した分野として存在することさえ知らなかったということを意味している。その分野の非常に賢い、熟練した専門家たちは、ソフトウェアが「もの」であり、独立した価値を持つものであるかどうかさえ分からなかったのです。
ソフトウェア/ハードウェアが別物として当然だと思っていたので、古典の話は興味深い。
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 で一個のステップ実行時間が長くデバッグが大変だったのを、分割して解決しようとした ... というのを思い出したりした。その他、日々の開発でも意識せずにやってることもあるだろう
付録
https://learning.oreilly.com/library/view/semantic-software-design/9781492045946/ch01.html
