前著にひきつづき。
TPSや現場の品質管理を頑張るだけでは、各社に程度の差はあれ、それほど大きな違いはすでに生み出すことはできない。
pp. 25-26
当たり前品質と感動品質（要出典）のようなものか。
東側のTPDで企画・設計・開発・試作・試験を経て完成した「設計情報」は、国道248号線の西側に渡され、TPSを実施する工場で実体のある製品（クルマ）に変換される（もちろんいまでは「設計情報」は、世界中の工場に送られている）。
p. 49
ソフトウェアの「設計情報」とはなにか。
つまり主査は、製品の価値と利益と実現手段すべてに責任を持っている。
p. 54
かっこいい。
TPSの本質は、製品を作るというよりは、最小の費用と最初の運転資金でコピー・量産する「プロセス創造」していくことである。
p. 54
これはこれで芸術肌が求められる。
設計情報が社内に残されてさえいれば、過去に発売された製品であっても、再度つくることができる。
p. 88
Executable JAR？コンテナ？
トヨタ流設計情報の記述はきっと単純なテキストではないんだろうな。
TPSによって捻出された資金と、最小運転資金による経営で金利負担を節約した分は、次章で述べるTPDの主査制度に基づく製品開発における原価企画を有利に進めることにもつながっていく。
p. 119
強い財務の視点。
昔トヨタの生産現場では、大野氏ら生産管理と、生産技術（製造工程の機械化を担当する部分）が対立することがあった。生産技術を担当するエンジニアはただ機械化すれば、それだけA→A'のプロセスが効率的になると考えていたからであるが、正しかったのは大野氏で、設備投資をして機会を入れたからといって、最小費用・最小資金の設計情報転写プロセスが作られるわけではない。
p. 123
人間と機械の統合！
「設計情報（A）→製品（A'）」で発生する費用は、それぞれ次のようにカイゼンがなされている。
p. 128
頭数、コンテナ化、アーキテクチャ変更など。全インスタンスに影響するネットワークやサーバなど環境の変更みたいな話。
商品企画は、市場から見て、こういう価値の製品がいくらくらいの価格であれば良いという市場側の要望を主に主査にインプットするわけだが、その段階ではいわば、「絵に描いた餅」であることも多い。絵に描いた餅が、本当に価値があるのか、あるいはどの程度実現可能なのかは商品を企画した段階ではわからない。実際、その商品性を実現する製品を具体的に企画し、開発していく中心となるのが主査ということになる。製品開発に関する全ての決定とその結果についての責任を持つのは製品企画室の主査の役割である。
p. 150
「絵に描いた餅」は商品企画か。
- 一つの専門分野に詳しいエンジニアは普通のエンジニア
- 二つの専門分野に詳しいエンジニアは立派なエンジニア
- 三つ以上の専門分野に詳しいエンジニアは天下のエンジニア
pp. 162-163
藤原和彦氏のレアカードに同じ。
読めば読むほど、戦略マップの4つの視点と完全に一致している。
