2020年03月14日 17:42

業務のバグ、組織のバグ

 桜の開花の知らせになんとなく鬱陶しいものを感じて窓の外を見れば雪。

 製造業で法務なり監査の仕事をしていると、製品不良やら不具合をはじめ品質保証関連の報告・対策会議に出席する機会が増える。法務としての振り出しの仕事が製品リコール対応だったし当時の関係者の生き残りになってしまった今、時として厳しい意見もいわなければならない。しかし「なんとなくあるべき論」を述べるだけでは、「また監査部門がうるさいことをいう。」で終わってしまうので、設計や製造、品質検査部門に何かしら「引っ掛かり」を残すようにしたほうがといいだろうと思い、ネタを探していたところ手に取ったのが「バグトリデザイン 事例で学ぶ行為のデザイン思考」(村田智明著 朝日新聞出版)。
 
 何かと「デザイン」とタイトルにつける書籍が増えたような気がするのだが、この書籍は本家?ともいえるプロダクトデザインに関するもの。ユーザーが何かしら不具合を感じたら、その製品の設計・製造はじめどこかのプロセスにバグがある、そのバグを除くには人の行為をよく分析することだ、という内容。(雑駁なまとめで申し訳ない)バグと表現しているものの、深刻なものは製造物責任法における設計上や表示上の欠陥に通じると思いながら読んでいる。

 ところでバグというのはプロダクトデザインだけのことか(元々バグという定義のあるコンピューターシステムプログラムなどの領域は除く)というのが本題。
 業務ルール違反や品質不良の事案発生の際に、本社管理部門は「なぜルール通りにできない」と既存のマニュアルの運用を厳格化してしまいがちではある。だが同様の違反や不具合が繰り返し発生しているようなら、ルールやマニュアルの内容そのものにも疑義を向ける必要があると考える。あやまった行為を誘発する、またはそれを防げない要因、本書でいうところの「バグ」が業務プロセスのどこかに存在していると考えるのが自然ではないか。製造現場では日々の現場巡視やQC活動などで非効率・危険性といった「バグ」は取り除かれていくが、本社管理部門はじめ事務部門はどうなのだろう。「バグ」を現場の責任に押し付けてはいないだろうか。
 本社管理部門が作るルールやマニュアルのユーザーは従業員。ユーザーの行為にもっと注視すれば、違反や不正を防ぐ業務や組織のデザインにつなげることができる…かもしれない。
 おりしも在宅勤務を取らざるを得ない状況。在宅勤務を導入してこなかった企業は業務や組織のバグ取りの良い機会となるのではないか。

 と書きつつ、自分はといえば毎日出勤しているのであった。




 




 
  

    このエントリーをはてなブックマークに追加

コメントする

名前
 
  絵文字
 
 
プロフィール

msut

QRコード
QRコード
アクセスカウンター

    • ライブドアブログ