SPICEアセスメントを実施するのか?」の考え方が理解されていないと感じている。事の発端は、他人のプロジェクトのレスキューに入った時に、開発活動がリピータブルでなく、共通理解に基づいたプロジェクト管理となっておらず、行き当たりバッタリの開発現状を如何に突き崩すか、そのことを現場に理解させるにはどうしたらよいか、その手段がアセスメントであった。QCD達成が望めないプロジェクト運営、即ち失敗するプロジェクトは、失敗するプロセスで進行している、そのことを開発現場に理解させる手段としてアセスメントの評価報告は有効であった。このようなクラッシュプロジェクトに対するレスキュー的アセスメントとは異なり、本来アセスメントは、「ターゲットプロジェクト(重要プロジェクト)実施前にパイロットプロジェクトに対してアセスメントを実施し、その評価結果の対策を打ったうえでターゲットプロジェクトにのぞみ、期待されるQCDを達成し、顧客の信頼を得る」ために行うのである。顧客から仕事を得る前に準備をしておこう、と言うのが考え方の根底にある。レベル3組織の意味である事前管理(ことまえかんり)、リスク管理、の出来る組織の考え方である。その前にプロセス改善のニーズがあって、その改善を効果的に実施するための評価手段としてアセスメントが位置付けられるが、今の自動車業界では、アセスメントの目的がPIではなく、PCDなので・・・、と言うか、顧客に言われたから実施する、という何とも情けない状況であるが。サプライヤに依頼したプロジェクトのQCD達成ができそうもない、・・・・、だから、カスタマとしてアセスメントをして開発現場に光明を与えるんだ、みたいな活動をよく見るが、これは、気をつけなければイケナイ。小谷田が実施したクラッシュプロジェクトに対するレスキュー的な意味でのアセスメントは、あくまでも、アセッサに開発経験があり、アセスメントで開発現場に改善の気づきを与えられる場合である。アセスメント後、アセッサが開発者の立場になり一緒に開発現場の中に入ってQCD達成を実行できるスキルと覚悟のあるアセッサによるアセスメントの場合である。開発現場の立場で言うと、評論家はいらない。アセスメントを実施するアセッサに開発経験がない場合、その内容はどうしても評論家的アプローチになってしまう。その様な状態で、アセスメントがプロジェクトの途中で実施されると、開発現場は、QCDが達成できなかったことの言い訳を、「開発途中でアセスメントを実施したから、プロジェクトが失敗した」と言ってくる。ソフト屋さんは、「このプロジェクト、あぶね~ナ」と感じると、意見を言わなくなり、誰かが失敗するのをひたすら待つようになる。その様な時に、無能なアセッサがノコノコやってきて、「君のやり方はこんなところが間違っている、リスクがある」なんて、言おうものなら、待ってました、とばかりに、アセッサ様の指摘対応に着手し、結果、物造り、品質確保が十分できずQCD未達になり、前述の言い訳の材料にアセスメントを持ってくるのだ。開発途中で計画になかったアセスメントを実施する場合は、「アセスメント後、プロジェクトリーダーを俺にやらせろ」ぐらいの覚悟を持って対応するのが小谷田流である。しないと、アセスメント実施組織のカスタマが、アセスメント受診組織のサプライヤから「アセスメントを実施し、あなたが指摘した対応を行ったらQCDが未達となった。あなたのせいでプロジェクトが失敗した」と責められ、結果、商品の市場投入が遅れ、売れないは、顧客の信用を失うは、社長から怒られるは、で、踏んだり蹴ったりの結果となるリスクが大となる。小谷田は、サプライヤがQCD未達ならば金を払わず違約金をがっぽりとるが・・・・、今の自動車業界は金を払っちゃうからどうしようもない・・・・。何とかしてくれ」、なんてこともありました。金は既に支払った、と聞いて「アホカ!」と言ったのは言うまでもなく。今の自動車業界が正にそれでは????、なんて考えてしまう。組込技術者として、「確かに、exactly」である。