2011年4月 Archive

福島原発事故を考える(3)　設計・開発のレビュー

110328で、9001規格7.3.2項「設計・開発へのインプット」との関連性を説明しました。その後、20年ほど昔のQA仲間と会う機会があり、レビューをきちんとやっていたのだろうか。という話になりました。　7.3.4項「設計・開発のレビュー」なのです。規格上、設計・開発のレビューは、「適切な段階において、計画された通りに、体系的なレビューを行わなければならない」とあります。
実施する段階も、レビュー計画も、組織が決めますから、自由度が大きく、粗密（実施内容のバラツキ）が予想されるわけです。やっています、記録もあります、では不十分で、実施した内容の濃さ・真剣さが問われるわけです。

設計・開発のレビューの対象についても9001規格は明示していませんから、自分たちで考えることになります。田中の考え方は規格理解のテキストに反映させていますが、設計・開発の計画（7.3.1項）、設計・開発へのインプット（7.3.2項）、設計・開発プロセス（設計・開発として実施している中身、手際）、設計・開発からのアウトプット（7.3.3項）が全て対象と考えます。
計画段階、インプット段階では気づかなかった設計・開発面での欠陥(不足)を、設計・開発段階（途中）で検出できる可能性もあり、アウトプットが出た時点で検出可能ですから、レビューの役割は重要です。さらに、設計・開発の変更管理（7.3.7項）にもレビューは関連します。設計開発上でのなんらかの変更を行う場合には、レビュー、検証、妥当性確認の少なくともひとつを実施するのです。たとえば地震の大きさや襲来する津波の高さに関する新たな情報があった時に設計開発の変更をするのか？しないのか？その変更は新情報を考慮した場合十分な内容か？を議論するのです。リカバリーのチャンスがあるということです。

レビューワーとして誰が適切かについて、9001規格は、「レビューの対象となっている設計・開発段階に関連する部門を代表する者を含める」ことを義務づけています。設計開発部門のメンバーだけで実施するのではなく、お客様相談室の社員がレビューワーになっても良いですし、設備メンテナンス担当者やホームペ＾―ジ担当者がレビューしてもよい、と言っているのです。「設計・開発段階に関連する部門」をどうとらえるかが鍵を握っています。なまじプロ意識、専門家としての誇りを持ちすぎると、他部門、他組織の見解を考慮せず、唯我独尊的な結論に結びつける可能性があります。

設備の改修・変更には国の承認が必要で、手続きがやっかいなため放置してきた　という言い訳が記事になっていましたが、幼稚な言い訳と感じたのは田中だけでしょうか。

レビューの定義を再確認します。"設定された目標を達成するための検討対象の適切性、妥当性、及び有効性を判定するために行われる活動"です。"設定された目標"には、当然"発電所の安定した運転"、"地震等災害時にもメンテナンスしやすく、安全性を確保できる"、"付近住民に不安を与えない"などが含まれているかどうかもレビューする際に重要です。リカバリーのチャンスがあっても、目標が正しく設定されていなければ、レビューを実施しても上っ面(つら)だけになってしまう恐れが十分あります。

考えさせられることが次から次と出てきます。

ベンチマーク（マーキング）

9004規格改定について110225で触れましたが、その8.3.5項に「ベンチマーキング」があります。ベンチマーキングという用語の定義はありませんが、「パフォーマンス改善を目的とする、測定・分析手法である」と説明しています。また、「組織内外のベストプラクティスを模索するために利用できる」とも述べています。

辞書を当たると、「比較のために用いる指標」「物事のシステムやあり方についての規範としての基準、水準」などと書いてあります。もともとは測量する（例：山の高さを平均海水面から測る）際の水準点のことですから、絶対的な権威（正しさ）をもっているものです。現在の用法としてはそこまで厳密なものではなく、自分たちの立場がどのあたりにあるのかを見極めるための尺度であったり、これから到達しようとする目標として設定するもの、と概念を変えてきています。証券業界では「投資信託の運用成果を検証する際の評価基準」という意味で使うなど、業界ごとの使い方もあるようです。

9004規格ではベンチマーキングを3つに区分して考えることを推奨しています。
① 組織内活動
② 競合他社との競争的なもの
③ 他業種組織と比較するもの
なんのためのベンチマーキングなのか（目的/適用範囲）、ベンチマークのパートナーとして何を選定するか（①～③に対応）、比較する特性・項目として何を選定するか、どのようにデータを収集するか等を確定するが、ベンチマーキングの計画に相当します。この計画のよしあしが、パフォーマンス改善の良否につながります。計画に基づいてデータの収集分析⇒ギャップ特定⇒改善計画策定⇒改善活動監視⇒パフォーマンス改善とPDCA的に進んでいきます。

9004規格の特徴は、上記の一連の活動をするだけでなく、「蓄積された経験を組織の知識基盤や学習プログラムに取り込む」ことを推奨していることです。パフォーマンスが改善できたら終了、ではなく、その結果を知識基盤"organization's knowledge base"とすることで、より強固なシステムあるいは体質にしようとしています。
注目する/改善したいパフォーマンスは1項目と限りませんから、学習プログラムに取り込んだ場合には連鎖的にベンチマーキングの活動が実施されることになります。これが、持続的成功には不可欠だと考えているわけです。
もう一つの特徴は「ベストプラクティスを模索」という言葉です。GMP(Good Manufacturing Practice)、GLP(Good Laboratory Practice)、GAP(Good Agricultural Practice)など、G□Pという用語は多数あり、優良□規範などの日本語をあてはめています。
しかし、Goodを「優良」と置き換えるのは実は間違いなのです。Goodは優/良/可/不可の中の「可」でしかありません。目指すべきなのはBest Practiceです。「優」または「秀」を模索するのです。

福島原発事故を考える(2)

110328で、福島原発事故を9001規格の面から考えると、7.3.1項「設計開発へのインプット」が最も関連性が強いと書きました。正しくは7.3.2項です。謹んで訂正いたします。

もうしばらく、今回の事故を9001規格の面から考えてみたいと思います。今回のように、監視測定装置が機能せず、必要なデータが入手できないために、現場がどのような状況になっているか不明という中で、今この時間、なにをすることがベストなのかを判断しなければいけないわけで、定常状態だけを想定したマニュアルでは役立ちません。
TS16949の6.3.2項では「ユーティリティの停止、主要設備故障などの事態に備えて、緊急事態対応計画を準備しなければならない。」とあり、9001よりは非常時のことも考えるよう要求しています。これに関連して、新潟中越地震の時にはカーメーカーの対応（部品供給会社への支援）がうまく機能しましたが、今回は自動車の生産を長期間停止せざるをえませんでしたし、日本からの部品が届かないため、海外での生産を縮小したケースも報道されています。対応がむずかしい課題であることは間違いありません。
今回の状況を教訓として、一連の諸活動が終了（定常的な状態に復帰）した段階で、今後に向けた対応を考え直す機会としなければいけません。これまで想定外の状況が現実のものとなったわけですから、リスクマネジメントを含め、マネジメントシステム全体のおさらい（レビュー）が必要です。

9001規格の序文には、次のような表現があります。
「組織環境に関連するリスク、多様なニーズ、固有の目標、提供する製品、用いるプロセス、規模及び組織構造によって、つくりあげるべきシステムは異なる」
QMSを設計し運用する場合に考慮すべき要因を大括りに説明しているわけですが、よく噛みしめる必要がありそうです。ISOのマネジメントシステムに取り組むことがベストでもありませんし、取り組んでいればこんなことにはならなかったというつもりもありませんが、組織としてのマネジメントシステムはあるはずです。今回の事故で明らかになったシステムの一端は、お粗末としか言いようがないものです。結果としてですが、周辺の住民、電力供給を受ける顧客のことに配慮していなかったと言われてもしかたありません。

それにしても、内部電源を復活させるために危険区域に入らざるをえない作業員に対して、放射線の線量を伝えていなかった（コミュニケーション欠如）とか、汚染された水の存在を予想せず（作業環境配慮不足）被曝者が出た、全員には線量計が行き渡っていなかった（必要な資源の不足）ことをなんと説明すればよいのでしょう。マネジメントシステム以前の人権無視と言われてもしかたないのではないでしょうか。地震や津波の発生は天災だが、それに付随して発生した災害は人災であると述べた記事をいくつも見かけます。
9001規格はどのような業態にも適用できる最低限の要求事項を並べたものです。自分たちの業務内容に合わせてしくみをつくり、非常時を想定したマニュアルを作るべきなのです。

東京電力のシステムを責める表現になってしまいましたが、自分自身のシステムを見直し、反省のきっかけにしたいと思います。砂上の楼閣もダメですし、無用の長物もダメです。形式だけ整っているのでなく、役立っている、うまく機能しているシステムの構築は、コンサルタントとしても心しなければいけない課題です。

理事長退任

退任といっても、住んでいる集合住宅の管理組合の話です。築10年を過ぎ、1回目の大規模修繕をいつ頃どのような内容で実施すべきかという議論の時期に理事長となったのでした。

49戸という小さな集合住宅ですが、10年間住み続けているのは3/4くらいで、7年くらい前から所有者の入れ替わりが始まりました。小さな所帯の割に、名前を知らない方も多いですし、今すれ違った人が住人なのか顔がわからない時もあります。
管理組合役員は、毎年6人ずつ持ち回りで１周した後、半数は翌年までという2年間の任期制に変更しました。管理人の派遣をはじめ管理全体を委託していますが、この会社の担当者には顧客重視の考えがあまりなく、言わないとやってくれませんし実施タイミングも悪いので、1年間けっこうイライラしました。

2月末の総会終了で退任し、肩の荷を下ろした、という言葉は実感です。書式は違いますが、メーカーでのサラリーマン時代と同じように引き継ぎ書を作成し、懸案事項/目を離すと心配な事項を引き継ぎました。
幸い、後任の方は1期の際に一緒に理事を務めた方で、気心も知れており安心して後を託せたのです。

品質管理の用語が共通語になるとよい、という話を前に書きましたが、委託した管理会社はISO(9001)に一部門しか取り組んでいないので、「そのような仕事ぶり（仕事の結果）は不適合です。是正処置をとってください。」という言い方ができないのです。100719、101117、101224と、ずいぶん話題にしてきましたが、もうここまで文句をつけてきたから大丈夫、という状態にはほど遠い状態で引き継いだのは多少申し訳ないと考えています。