なぜ業務改善チームビルダー?


今回は、

「なぜ私が『業務改善チームビルダー』なんてマニアックなことをしようと思ったか」

について書いていきます。

製品開発者としての失敗

私は、新卒で入社した会社で、技術者として、大手メーカーの製品開発の部門(正確にいうとPETボトル開発部門)に配属になりました。

大手製造業において、製品開発ができるということに、当時は表には出しませんでしたが、正直浮かれていました。

ともすると、

「自分が優秀だ!」

という勘違いをしていたのかもしれません。

当然まだまだ未熟だった私は、新製品の開発過程において失敗を繰り返します。

・必要なはずのデータを取っていない
・確認するべきことをしておらず再試験になる
・納期が迫った段階で不良発生の対策が出来ていない
etc…

枚挙にいとまがありません(笑)

今でこそ笑えることかもしれませんが、新製品開発は直接的にお客様に迷惑かけますし、当時はその未熟を補うために深夜残業を繰り返し、休日出勤もせざるを得ない状況でした。お客様立ち合いの最終試験で不良品を大量に発生させて呆れさせてしまったり、量産適性確認で生産ラインでの試験を行っている際には、検討不足で全く成形できず、現場のオペレーターからボトルを投げつけられるなどのこともされました。

今振り返れば、全て自業自得ですが、、。

そのとき周囲の人たちは

実は、私の周りの先輩たちも似たようなことをしていたため、

「これは通る道だ!」

くらいの感覚で見ていたのだと思います。

当時の仕事のやり方としては、試作評価を任される担当は1製品につき1人割り当てられていました。基本的には、その割り当てられた担当者が自ら試作して、評価して、Go / No-Go を判断し、設計へのフィードバックがあれば設計者に内容を伝え、開発を進めていくスタイルでした。

つまり、この試作評価をする担当者1人に大きく依存した仕事のやり方になっていたのです。

その担当者が優秀であれば問題ないのでしょうが、当時の私は当然未熟、先輩たちも、必ずしもうまくいっていることばかりではなく、【属人的】な開発プロセスだったと言えます。

どうやって解決したか

新製品開発の部署に3年勤務し、教育プログラムの一環としてのジョブローテーションで生産工場の品質課に異動になりました。

転機はそのときでした。

普段は生産工場を「製品開発の立場」で見ていたのですが、「生産者」として見ることになったのです。納品する客様との接点も増えました。その時に気が付いたのは、

・生産者としての立場があること
・生産のプロセスも開発プロセスを繋がっていること
・たくさんの人がさまざまな役割で一つの製品に関わっていること

つまり、新製品開発は一人ではできるわけがなかったのです。

2年間の品質課での勤務の後、再び新製品開発の部署に戻りました。

そのときに意識したことは、

みんな良いものを作りたいと思っている!

という大前提でした。

私は、製品開発への取り組み方を変え、作業や判断を他のメンバーに預けることをし始めました。

仕事をサボりたかったわけではありませんよ(笑)

例えば、
・試作そのものは自分がやって、その評価は別の評価の人にお願いして見解を求める。
・その見解をすり合わせ、意見を整理したうえで設計者と相談する。
・設計者には、生産や成形の都合を踏まえて要望を伝える。
・設計者の考える顧客要望とすり合わせより良い案を作り上げる。
・一方で、生産工場にも事前にサンプルを送付し、生産の観点からの指摘と要望の確認をお願いする。
・生産設備部門には、必要になりそうな冶具や設備を確認しておく。
・生産管理課にはあらかじめ試験予定の確保をお願いしておく。

といったような具合です。

自分でなくていいこと、他の専門家がいてお願いしたほうが良いことを、協力を仰ぎながら任せるようにしたのです。自分は製品開発の旗振り役でありチームコーディネートです。

開発のやり方をそう変えることで、試作の質が桁違いに高まりました。量産移行時のトラブルも減りました。それはそうですよね!みんな良いものが作りたいと思っていて、あらゆる立場の人が事前に少しずつ検討してくれている。いざ、デザインレビューにの場では、もうほとんど議論の余地なんて残されていないほどになっていました。他の開発担当者のデザインレビューの会議が1.5H~3.0Hかかっていたところ、私のデザインレビューは約30分。結果の報告と今後のスケジュールの報告くらいで済みました。

1人では大したことができない

これが大きな教訓であり、そのときに新製品を開発する【チーム】ということを強く実感しました。

ITとの出会い

話は少し変わりますが、10年間勤務した会社を辞め、製造業のコンサルタントに転身することを決めました。

この経緯は別の記事で詳細を紹介しますね!

その製造業のコンサルタントとしての活動は、製造や開発のプロセスにITツールを導入し、生産性を向上させようというものでした。

幸いにも、製品開発プロセスと生産プロセスの両方を知識として持っていた自分は、このITを活用する場面なども頭に浮かび、お客様に紹介しながら生産性向上のアドバイスができるようになりました。

ところが、このようなソフトウェアを販売するベンチャー企業は世の中にたくさんあり、競争は熾烈です。各々がソフトウェアの特徴を出し、各企業へ売り込んでいきます。私たちコンサルタントも、製造業の現場を理解していることを強みにソリューションの提供に励みました。

ITコンサルの実態はどうだったか

撃沈

さて、その実態と本音を書きますね(笑)

・売れない!
・コンサルとは名ばかりでソリューション販売営業!
・導入しても成果出ない!

これが実態でした。

とはいえ、ソリューションの導入をしていただけたお客さまもいました。コンサルの役目は、自分たちのソリューションにお客様の業務プロセスを当てはめる提案をすることでした。お客さまが納得して導入したはずが成果につながらない。そんな現場も多くありました。

それはなぜか。

【現場が納得していない!】

ITソリューションの導入は高額です。導入に当たっては、必ず経営者が判断します。売上欲しさに経営者にダイレクトに交渉し、IT化・IoT化の提案をした場合、現場の意見はあまり考慮されないため、現場の“押し付けられた感”が大きかったです。

そりゃあそうです。実際にソリューションのワークフローを押し付けるわけですから。

その結果、

・ワークフローが馴染まない
・担当者があまり使いたがらない
・一部の上司から命令された人しか使えない
・効果が出ない

そんな構図になってしまうのです。

生産性向上の活動が進まない本質は何か

私は、ずっとジレンマを抱えて仕事をしていました。

・ソリューションが売れないと売り上げに貢献できない
・ソリューションを適用することは必ずしもお客様の問題を解決しない
・現場の問題や経営者の悩みはITで解決できないことの方が多い

幸いにも、経営者の方や現場の方とお話しさせていただく機会が増え、たくさんの意見を伺っていると、

経営者と現場の担当者の感覚にズレがあるな

と感じることができました。

経営者が経営目標を掲げ、重点課題を取り上げて旗を振っている一方で、現場は目標に向かって改善活動を行えていない。そんな印象でした。

問題は現場で起きている

その問題を解決するのもまた現場

現場を“腹落ち”させて行動を促進させる

現場が解決する目の前の問題と経営課題をつなげる

このようなことを考えるようになりました。今のままでは本当の意味でお客様の役に立つコンサルタントにはなれない。

現場で業務改善を自発的に進めていくチームがあることこそが、企業成長の原動力となり、延いては日本の産業第一線を輝かせる。

そのための手段はITかもしれないし、新設備かもしれない。いずれにしても、その核は問題を解決するべき現場の自発的な行動であるべきだ。

そこで、2年9ヶ月勤務した会社を辞める決意をしたのです。

さいごに

とはいえ、私自身の生活面や提供するサービスの確立など、問題は山積していました。こういった点については、また追々記事にしていきたいと思います。

【経営】と【現場】をつなぎ、自発的に業務改善を進める現場チームを作る

このミッションを掲げ、今も日々活動しています!


コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です