誰もが“当事者”になれ、社内改革の主役はあくまで自分：“異端児エンジニア”が仕掛けた社内改革、執念の180日（11）（2/4 ページ）

東京コンサルティングの杉谷と若菜は、須藤たちにプロジェクトの骨子の1つとなる業務プロセスについて話し始める。それは職場の「見える化」と「言える化」を並行して進めることでもあった。ただし杉谷と若菜は、「大切なのは、コンサル会社に頼ることではなく、常に自分たちが“当事者”となることだ」と、こんこんと説く。

[世古雅人，EE Times Japan]

コミュニケーションを取らざるを得ない状況に持ち込む

　例えば、業務プロセスの改善として、納期の短縮を考えてみよう。多くの工程をさまざまな部門が担当して製品が出来上がるメーカーにおいて、自部門だけで納期やLT（リードタイム）を短縮できても、他部門で時間がかかっていたら、全体としての時間は短くならない（＝納期短縮の効果は薄い）。

　また、現場からすると、「カイゼン」と言えば、単に「コミュニケーションを取りましょう」と言われるよりは取っつきやすい。

　納期やLTの短縮では、前後工程の人と、嫌でも話をしないと問題解決には至らない。そして、この過程を通じて、前後工程の業務プロセスも自然と分かるようになる。このような「場」を仕掛けることで、コミュニケーションを促進しつつ、改善も進めていくのである。

若菜：「つまりは、風土改革を前面に押し出すのではなく、コミュニケーションを取らざるを得ない状況に持ち込んでしまうんです。コミュニケーションを取りながら改善やプロセス見直しを進めることで、さらに自分と他部門の人との関係性も高まるということを狙っているんですよ」

杉谷：「いきなり、“皆さん考えてみましょう”と言ったところで、良い意見や創造的な考えは出てきません。そうではなく、考える材料として業務プロセスを与える。これによって、今までさほど話をしなかった前後工程の人とも、より多くのコミュニケーションを取れるようになります」

　今まで、「改善などの活動は本人の意思を問わず、会社や上司の指示命令によるもの。コミュニケーションはたくさん取りなさい」と言われ続けてきた須藤たちにとって、業務プロセスの「見える化」を活用して「言える化」の場面を設けるというやり方は新鮮に映ったようだ。

業務プロセスは「細かさ」が鍵、モジュールで示す

　ここで少し、業務プロセスの話をしてみたい。

　図2は当社（株式会社カレンコンサルティング）が勧める業務プロセスと業務フローの表記方法だ。一見するとフローチャートのようだが、付加される情報量はとても多い。また、業務プロセスの粒度は、「これでもか」というくらいにまで細分化する。この細分化した業務プロセスの1つ1つを「プロセスモジュール」と呼んでいる。

図2：業務プロセスとプロセスモジュール（クリックで拡大）

　赤文字で示された項目が「業務プロセス（プロセスモジュール）」に関するもの、青文字が「業務フロー」に関する項目だ。ここではこれ以上の詳細説明は割愛する。

　このプロセスモジュールは、図中にもあるように、もともとの概念は論理回路のマクロやライブラリからヒントをもらっている。EE Times Japanの読者諸氏の回路設計エンジニアにとってはなじみがあるものだろう。余談だが、筆者がある企業にて業務プロセスの説明で、HDL（ハードウェア記述言語）で話をしたら、技術屋さんにはウケたが、事務屋さんには取っつきにくかったようだ。

　このような話を杉谷と若菜は須藤たちプロジェクトのコアメンバーに説明すると、技術部開発課の須藤や大森、システム課の及川はすぐにピンと来たようだが、メカの設計課や営業、管理系のメンバーはキョトンとしていた。

大森：「けど、ここまで業務プロセスを細かくして、多くの情報を入れ込む必要ってあるのかなぁ？」

須藤：「よく見てみろよ。ISO9001の業務フローはここまで細かくないぞ。恐らく、杉谷さんと若菜さんが言わんとしていることは、“当たり前のようにやっていたことを顕在化する”ってことなんだ。ことの発端となった不正をなぜ抑止できなかったか、われわれの知らぬところで行われたのかも考えてみれば、俺たちは、業務プロセスそのものを分かっているようで分かっていなかったんだ。ブラックボックスであっても仕事が回り、しかもそれでも誰も困らないという今の状況を、もう一度、見直す必要があるってことなんじゃないかな」