こちらの記事を読んで興味を持ったので読んだ。
2. アメリカのハイテク・ベンチャー企業を育てたのは、もっぱら政府の強力な軍事産業育成政策である。
3. イノベーションは、共同体的な組織や長期的に持続する人間関係から生まれる。
4. アメリカは1980年代以降の新自由主義的な改革により金融化やグローバル化が進んだ結果、この40年間、生産性は鈍化し、画期的なイノベーションが起きなくなる「大停滞」に陥っている。
5. 日本は1990年代以降、アメリカを規範とした「コーポレート・ガバナンス改革」を続けた結果、アメリカ経済と同様に、長期の停滞に陥っている。
pp. 223-236
以上が本書の骨子である。
Big Techのカスタマーサポートについての見解。ここは、「ギジュツ」で勝負できるところなのかもしれない。
非常に興味深い。
新着図書を眺めていて見つけた。
図表が多いので、パラパラと眺めるだけで楽しめる。学生の頃に情報デザインを学んでいたときのことを思い出した。
個人的にひときわ目を引いたのは「8章 「世界」を収集し、分類し、体系化する ポール・オトレの20世紀型《百科全書》」の「アトラス・モンド」（Atles Monde）、これは私の理解では百科事典と十進分類を同時にグラフィックにしようというようなものかと。
「世界」は、もの（自然、人類、社会、神）、空間、時間、自己、（人間の）創造、表現、未知の7要素に分類される。
p. 245
上記リンク先の1枚が各要素に対応している。図書館情報学に思想がちかいので興味深かった。
朝日新聞の書評。
「アプリケーション基盤」で検索していて見つけた。
製造業では、製品を製造することが生産プロセスであるのに対して、情報システム開発では、情報システムの生産するものは、画面の出力結果や帳票であり、生産プロセスとは情報システムの稼働・運用を意味する。
p. 359
13. Production Engineering at Facebook - Seeking SRE [Book]以外でこのメタファーを使う人初めて見た気がする。私も、developmentとproductionで切るのに賛成。理由は単純にこのメタファーによって生産マネジメントの知見を取り入れられるから。
（3） 情報システム開発＝｢情報生産工場」を作ること
情報システム開発において必要な設計対象として、工程アーキテクチャ（開発プロセス自体の設計、一般には、標準的工程モデルを採用し、その都度設計はしない）、システム・アーキテクチャ（対象システムの構造設計）、プログラム・アーキテクチャ（各プログラムの構造設計）、データ・アーキテクチャ（データモデル設計）が挙げられる。
「情報生産工場」の特徴として、① プログラムは工作機械に相当し、情報を加工するのが役目、② データモデルは部品表6 に相当、③ オンライン即時処理は「1個流し」生産に相当、④ 情報システムの開発工程は新製品開発工程であり、期間短縮が重要、⑤ 情報生産工場の生産性 7 として処理能力・処理性能が重要、が挙げられる。以上を踏まえて、情報システムと製造業とを比較すると、図1のようになる。
pp. 359-360
情報システムが「情報生産工場」、データモデルがBOMなどのメタファーはなるほどという感じ。
このような工程直列の制限を解除して工程のオーバーラッピングを行うとすると、例えば、概要設計工程での詳細な機能仕様の決定と並行して、詳細設計をオーバーラップさせることが出来れば、その分だけ期間短縮が可能になる。この時、概要設計担当者と詳細設計担当者の間に最終結論ではない仕様を動的に調整できる組織能力構築が必要となる。自動車産業では、そのような前後の工程のオーバーラッピングにより、製品開発の期間短縮が実現している。
pp. 361-362
納期短縮のために積極的に工程のオーバーラッピングを行うらしい（それを可能にする組織能力が前提）。色々と目からウロコである。
本論文が参照している「生産マネジメント入門」はぜひ読んでみたい。
品質保証の活動※1は、予防、検知および修正に大別され、品質保証活動を構成する個々の手段（予防活動、検知活動および修正活動）相互の関係が重要になります。
p. 15
なるほど。
で区分するのか。これを応用して
と区分するのはどうか。
品質機能展開（Quality Function Deployment：QFD）とは、設計・開発の源流から始まるすべてのプロセスで品質を確保する「製品開発の品質保証（Quality Assurance：QA）」のための具体的方法を提供するものです。まず顧客※2が満足する設計品質を設定し、次にその設計の意図と品質保証上の重点を製品の生産段階まで展開します。これは製品の品質を確保する方法として、内外を問わず各企業の製品開発や品質保証を行う上で広く活用され、成果が認められてきています。
p. 17
Quality Function Deploymentは全く知らなかった。面白そう。
レビューの効果に関して、前項での欠陥除去コスト（正味棄却コスト）の低減以外に、定性的な効果として開発に必要となる知識の共有や技術移転促進などが挙げられます。
p. 23
レビューの重要性をどうすれば定量的に示せるか。
dependabilityで検索した。
"In other words, I think that if “cloud native” has to be a synonym for anything, it would be “dependability.”"
via Check out this quote from Cloud Native Go - https://learning.oreilly.com/library/view/-/9781492076322/ch06.html
reliabilityよりもdependabilityのほうが硬派で好みだなと思っていたが、この筆者はcloud nativeすなわちdependabilityだと主張している。
"Why are there “site reliability engineers” but no “site dependability engineers”?
There are probably several answers to these questions, but perhaps the most definitive is that the definition of “dependability” is purely qualitative."
via Check out this quote from Cloud Native Go - https://learning.oreilly.com/library/view/-/9781492076322/ch06.html
なぜSDEではなく、SREなのか。おもしろい。
"Interestingly, as illustrated in Figure 6-2, these four categories correspond surprisingly well to the five cloud native attributes that we introduced all the way back in Chapter 1."
via Check out this quote from Cloud Native Go - https://learning.oreilly.com/library/view/-/9781492076322/ch06.html
が、dependabilityを高めるmeansで、
がcloud nativeであると。てか、この本は本当にGoの本なのか？
"As such, many fault prevention techniques come into play during the design and implementation of a service."
via Check out this quote from Cloud Native Go - https://learning.oreilly.com/library/view/-/9781492076322/ch06.html
production engineeringの考え方に、この上流工程への影響を考慮できればいいものになる。
てか、この本が非常に面白いので、cloud native系の本一通り読みたくなる。error budgetの話が出てこないのも好感が持てる。
"There are exactly four ways of finding latent software faults in your code: testing, testing, testing, and bad luck."
via Check out this quote from Cloud Native Go - https://learning.oreilly.com/library/view/-/9781492076322/ch06.html
笑。
"Static analysis is useful for providing early feedback, enforcing consistent practices, and finding common errors and security holes without depending on human knowledge or effort."
via Check out this quote from Cloud Native Go - https://learning.oreilly.com/library/view/-/9781492076322/ch06.html
レビューというと何かと誤解を受けるので、今後はレビューのことを静的解析と呼ぶことにしよう。
"Designing for manageability, first introduced back in “Manageability”, allows a system’s behavior to be adjusted without code changes. A manageable system essentially has “knobs” that allow real-time control to keep your system secure, running smoothly, and compliant with changing requirements."
via Check out this quote from Cloud Native Go - https://learning.oreilly.com/library/view/-/9781492076322/ch06.html
コード変更なしに要求変更に追従できることをmanageabilityというらしい。Goにアイディアをもらうのは良いとして、Javaで実現することはできると思う。
長いこと積読になっていたが読む。
It is increasingly clear that relying on a single, static organisational structure, like the org chart or matrix management, is untenable for effective outcomes with modern software systems.
p. 8
Simon Brown氏が言うところのdiagrams vs.modelsの話なのではと思った。org chartというひとつのviewでは全てを表現できないというだけの話なのでは。
結局のところ「Team Topologies」とは何かがいまいちハッキリしないのだが、Agile/Leanみたいな組織論におけるなにがしかの体系を示す固有名詞くらいに捉えるのが良さそう。
かな。
- Stream-aligned team: aligned to a flow of work from (usually) a segment of the business domain
- Enabling team: helps a Stream-aligned team to overcome obstacles. Also detects missing capabilities.
- Complicated Subsystem team: where significant mathematics/calculation/technical expertise is needed.
- Platform team: a grouping of other team types that provide a compelling internal product to accelerate delivery by Stream-aligned teams
https://teamtopologies.com/key-concepts
- Collaboration: working together for a defined period of time to discover new things (APIs, practices, technologies, etc.)
- X-as-a-Service: one team provides and one team consumes something “as a Service”
- Facilitation: one team helps and mentors another team
話は変わるが、コングロマリット企業はその出自からして自然に各事業単位ではmicroservice architectureを取るのではと思う。各事業内をさらにmicroserviceに分割するのは不自然かもしれない。
When we change the organization structure to accommodate Coway's law, we are aiming to improve the space (context, constraints, etc.) in which organizations search for solutions with software systems.
p. 28
アルゴリズムの空間計算量の話みたいで面白い。どちらかというと、時間計算量のnを減らすみたいな話の方が分かりやすい。
