失敗・成功事例集の作成

私としては、
?まずはやってみる（作り始めてみる）
?個人的に始めてみる
という２点が大切だと思っています。やり始めてみるとすぐに問題点が出てきますし、個人的にやっているのであれば、即座にやり方を修正できるからです。そこで成功すれば、全体的に広めていけばよいのではないでしょうか。

さて、実際のやり方ですが、これはyukioさんのアドバイスに似ています。必要と思った事柄を、特に整理しようともせず、ノートに時系列的に記載していきます。１頁には１項目しか載せません。必要であれば、資料を切り取って貼り付けます。単にこれを繰り返します。

そのうちノートの量が多くなって検索するのも出来なくなるので、私の場合はACCESSで簡単なデータベースを作りました。切抜きでは対応できないような書類については、このACCESSにリンクを張って、瞬時に検索できるようにしています。また、書いたノートもここから直接読み取れるようにスキャンする予定としています。

新規に技術的検討が生じた場合は、先ずはこのノートを検索します。すると忘れていた事も思い出しますし、新たに知見が得られれば、そこに追記していきます。

自分にとって役に立つと思った時点で、周りの人に公開したならば、彼らにとってもきっと役に立つのではないでしょうか。

お礼

2003/11/26 11:48

色々ご指導頂きありがとう御座いました。まずは下記の様にグループの中で進めて
行きたいと思います。

・「失敗事例集」に書き込む内容は、設計プロセスの目標管理にもしている図面ミスと
　図面変更の中で将来役に立ちそうな事例を「失敗事例」としてファーマットに書き
　ファイルリング。（最初はノートを考えましたがフォーマットを作りました）
・設計をした根拠となる技術データやテストをした記録、苦情・クレームで解決した
　内容などを機械の機種ごとに分類しファイリングしていく。
　（例：○○機械編、電気/電装編、被加工材料編など）
・類似的な設計を多くする部品を絞り込み、類似部品の代用事例をファイリングしていく。

短期的にはそれぞれのファイルを整理し、長期的にその整理した内容を参考に設計の
標準化を行う。これを繰り返し設計プロセスの継続的な改善を行っていく。

グループの各設計者にも設計者としての姿勢、活用の意義を話したところです。
継続は力、更なる設計品質の向上を願ってがんばりたいと思います。

質問者

　２０年ほど前，次のようにトラブル事例をまとめた設計のマネージャーがいました。

　大学ノートに，社内外で起こった設計に関係するトラブルを，時系列（ノートだから当り前）に書いて，関係者に回覧していました。フォーマットはなく，電子化もされていませんでしたが，なぜか皆読んで参考にしていました。（今も利用されています）

　設計ですから，図面もよく付けていましたが，現場に指示した改造図そのものを，コピー機で縮小して，糊で貼っていました。そして，かなり後になって（事例数が増えてきたので），ノートにページ数を付けて，冒頭にタイトルとページを書いた目次を用意していました。

　利用されたという点でこの事例集は成功したのでしょう。その要因は，
?作る人の意気込みから始まったが，そのうち他の人も有効と思い，書き込みを始めた。
?フォーマットにとらわれず，今まさに解決したてのエッセンスを，記憶にあるうちに，殴り書きした（時間はそうかからなかったようです）。
?業務が発展段階にあったので，次々と問題が発生していた。
?ノートは，誰でもいつでも見れるように，設計グループ近くの棚に備え付けておいた。

お礼

2003/11/25 09:48

作る人の意気込み、それを有効利用し、また書き込みをしようとする良い循環が感じられます。なぜみんなが読んだのかは、みなさんに危機感みたいなものがあったのでしょうか？いづれにしても設計の品質を良くしようとする意識（当たり前ですがそれが難しい）がみなさんにあったと思います。ありがとうございました。

質問者

k1さんが紹介された「失敗学のすすめ」の本は私も読んで非常に参考になりました。
この中で私が感心した個所は
(1)客観的失敗情報は役に立たない。
　私どもの会社では災害事例が回覧されますがすべて客観的に整理され「不注意」とかと言う風にまとめられ何故「不注意」になったかという点には触れていません。これでは役に立ちません。「不注意」なった原因、例えば朝女房と喧嘩して気分がむしゃくしゃしていたとか本音の話が大事だと思います。
(2)2万個の失敗情報を集めても意味は無い。
　ある大手自動車メーカがデータベースを作成したが殆ど活用されなかった例が紹介され、その原因は
本当に欲しい情報ではなかったことが上げられていました。
成功事例は「プロジェクトＸ」の番組が参考になるのでは思います。ただこの番組で何時も不思議に思うことは窓際族が頑張って新製品を開発したとかと言う話がありますが、一般の会社で窓際族になると１円の金も使えなくなり、開発など出来るものではないと思いますが。
「失敗・成功事例集」作成を職場活動として実施すのであれば結局リーダに負担がかかり、中途半端になる恐れがあります。まともに取り組むと大変な作業になると思います。まずホームを決めて皆さんに
書いて貰うのもひとつの手と思います。
取り留めの無い話になりましたがご参考まで

お礼

2003/11/21 18:31

あがとうございます、大変参考になりました。
「プロジェクトＸ」は参考になりますね、しかしプロジェクトの大半は成功まで行けず「×バツ」で、涙を飲むことが大半だと思います。何で×になったのかが重要で、失敗原因を知識共有し、多くの失敗から役に立つ成功の糸口が見つけられるような資料を作って行けたらと思います。

質問者

資料がある程度貯まった後のことをお話します。

せっかく工数かけて作った資料も、設計者が見なけ
れば意味がありません。そして、ただファイルした
だけでは設計者は見てくれません。
いかに設計者が今設計しているアイテムに関連した
資料を簡単に参照できるようにするか、が大事です。
具体的な方策は、私も暗中模索中ですが・・・
でかい会社ならPDMという恐ろしく高いシステムを
導入すればできるでしょうが、私のところでは無理。

将来的に参照しやすいシステムを構築するために、
とりあえずは、資料はパソコンデータで作って
おくのがいいと思います。（当たり前だ、と言われ
そうですが）
資料そのものも、設計者を一目でひきつける
ビジュアルに訴えるものにした方がいいです。

大したアドバイスにもなりませんが、こんなところで。

お礼

2003/11/20 14:51

＞ただファイルしただけでは設計者は見てくれません。

確かにそう思います。この様な資料をせっかく作成しても、見て学んでくれなければ失敗の予防にはなりません。色々工夫して価値ある資料にできればなと思います。

質問者

事例集を作ると考えずに失敗事例・成功事例を
あるフォーマットに作り、ある程度事例がたまった
ところで、事例集にすると気楽に考えられた方が
よいと思います。（分類・細分化など）

（一度は、洗出しが必要かな？）

各人の頭の中での知識を書きとめておくことは
共有知識となりやすくなり重要です。

設計標準の裏付け（根拠となる事例・データ）と
して、設計標準作成・改定以降も残したい財産です。

お礼

2003/11/20 09:47

ありがとうございます。
実際、利用経験がないので正直何の役に立つのか
実感できませんが、将来標準を作る上での拠となり、
会社の財産となるのであれば、がんばりたいと思います。

質問者