主査の担当分野が技術分野にとどまらないので、その点で主任設計者、プロダクトマネージャーなどと異なる。
p. 1
このプロダクトマネージャーが何を指しているか不明だが、そういう捉え方もある。
主査と主査付とは同一人格
p. 3
このあたりの記述を読んでいると、変革プロジェクトチームという捉え方がより一般的かもしれない。
主査向きの人材はライン部門の部次長とは違うゼネラリストである。
p. 3
ですよね。
主査に命令権を与えない理由は「主査の提案が妥当なものであれば必ず相手が納得するはずで、主査が誠心誠意説得すれば必ず相手が心動かされるはずである」にある。
p. 6
難易度高いな。
もし未達成が続く場合、経営目標を達成できない場合、また社内および協力企業の信任が得られない場合には主査は職を辞することになる。
p. 7
なるほど。
市場情勢に合わせて発売時期が決定される。
p. 29
これは完全な顧客ソリューション戦略から導かれるプロセスだと思うが、改めて考えるとなるほど。
一般的に、開発構想には、開発の狙い（経済予測、市場予測、開発意図、市場のポジショニング、商品コンセプトなど）のほかに、車種構成（ボデー型式、エンジン、トランスミッション、乗車定員、グレード、仕様、仕向先ー国内販売チャネルと輸出先ーなど）、生産・販売の規模（総生産台数・車型別生産台数、販売シェアなど）、販売価格・製造原価（代表車型の販売価格・製造原価、目標利益率、設備投資額など）、諸元・構造（全長・全幅・全高、ホイールベース、トレッド、車両重量、構造、装備、新機構、新技術など）、性能・品質（最高速度、加速性能、制動距離、燃料消費率、その他の性能・品質、開発目標など）、開発大日程（デザイン承認、出図、試作、ラインオフなど）などが支持される。 さらに、開発構想には必ず車両設計図が添付される。添付というよりも、車両設計計画図も含めて開発構想であると考えるのが正しい。
pp. 32-33
長い引用になってしまったが、ハードウェアでさえここまで開発構想を書けるのだから、ソフトウェアでもこの水準の開発構想を書けないということはないはずだ。ソフトウェア産業の初期にはきっと書いていたはずだ。書かなくなったとしたらなぜなのか。
指示や現図のほかに、設計部各課が作成した設計図も、設計部各課の担当者、係長、課長、部長のサインを受けた後に、製品企画室の主査付、主査のサインを受けて初めて発効する。
p. 40
このあと実際に間違いを指摘する場面も描かれている。ただただ驚く。
新提案にはまず反対する、不可能だと言う、工学理論を駆使して不可能の根拠を示す。その後にこうすればできるじゃないかと、根拠の不備を指摘されて初めて可能にする方策を考え始める。技術者にはそういう傾向がある。
p. 86
私もそうかも。
当初のラインオフは、早まることはあっても、遅れることは絶対にない。
p. 104
そんなことが可能なのか。
「生産試作では、不具合・問題点が多ければ多いほど良い車になる」
経験的にそう言われていた。
p. 122
なるほど。
