にほんブログ村ものづくりに関する記事を書いてきました
その一部です
書いている私自身、現役のサラリーマンとして海外の製造会社の経営しながら実践しています
今回、今まで記事に書いてきたような考えをどのような経験をもとに自分の中で構築し、実践してきたか、自分の仕事を振り返っています
今回はその５回目
前回までの記事では、初めての海外製造会社に赴任した間に学んだことを記事にしてきました
今回は、1回目の赴任が終わって日本に再び戻って仕事をした時の話です
赴任中に学んだことの実践モードに入ります
開発部門の責任者として
帰国後担当したのは新商品の開発部門です
私の記事で書いてきたことは以下の４点ですが、今回の職場では①③④の実践でしょうか
①製品開発者が意識するべきこと
②工場の生産性を上げる
③多様性を受け入れる
④現場力強化
商品開発が意識すること
私が開発者に指示する内容の一部です
その中でも、特に
①目標値の設定
②機能設計（論理的設計）
③変化点管理
詳細は以前の記事を参照いただきたいのですが、
簡単に説明します
①目標値の設定
製品開発を始める段階で
お客様の要求品質を物理的な数値に置き換え（S-H変換）許容いただける範囲を設定
この時、製品の性能だけでなく、品質を保証する環境、条件も設定
②機能設計
その目的を達成するための製品設計を論理的に行う
品質を保証するのは試験での評価ではなく、論理的設計で保証する
評価の目的は論理的設計が正しいかの確認
③変化点管理
品質問題は変化点で発生
その変化点を注目し、リスクを洗い出しリスクが発生しないように対策する
てな感じです
これらを日本に戻って、再び実践しました
帰任部門での実践
実は、当時の帰任先は赴任前と同じ部署でした
実は開発について学んだことの多くは赴任前に、その部門で学んだことです
ですので、上記の３点はほぼ部門に定着していたので、それほど多くのエネルギーを使うことなく実践できました
とはいえ、レベル的には十分でない開発者もいます
しかし、そういう開発者は丁寧に指導すればいいわけで、それほどストレスのかかる仕事ではありません
未熟な社員を指導するのは当たり前のことで、これにストレス感じていたら仕事になりません
元の部署での仕事で何が助かるかというと
「言葉が通じる」
これは、非常にありがたい
①目標値の設定
②機能設計（論理的設計）
③変化点管理
といっても、所属部署では当たり前の言葉でも、他の開発部門では全く通じないことは普通にあります
それを説明しなくていいのは非常に助かります
例えて言うと、
・同年代での宴会
・同じ大学の卒業生での宴会
などで、同じ年代だから、同じ大学を卒業しているからわかる言葉、話題の場合、非常に会話がスムーズになります
その感じと同じです
ですので、昔所属していた部署での「開発者が意識すること」の実践はそれほど苦労することは無かったですね
多様性を受け入れる
多様性を受け入れることは、海外赴任を経験し民族の異なる違いを肌で感じることができました
日本に戻っては、「女性」に対して大きく理解が進んだと思っています
私が担当していた製品を企画する部門があります
そこに、すごい女性が３人ほどいてました
ホントにすごいんです
私の勤めていた会社、それまで、責任者（管理職）は９９％男だったと記憶しています
そこに女性管理職が３人
強力なパワーでした
それまで男と仕事するのが当たり前だった私は衝撃受けました
この時「多様性を受け入れること」の大切さを理解し始めた気がします
男社会はやはり発想がショボい
現在は、多くの若い女性が活躍できる環境が整いつつあります
（まだまだ、問題は残っていますが・・・・）
彼女らのパワーを生かして仕事できる会社が勝者になれる
そんな気がしています
現場力強化の実践
現場力強化の実践は少々苦労しました
その原因の一つに「開発部門」の性質上の問題があると考えています
「スキル強化」に関しては、私含め多くのスキル保持者がいましたのでその伝承、それと新たな開発手法は取り入れないと世に送れるので、必然的に動機を持ってもらえます
難しかったのは「改善マインド教育」に関してです
「従来のやり方」にこだわる部分が多くてなかなか浸透しません
「課題を設定」と言っても、「製品開発自体が課題の塊」と多くの開発者は感じています
確かにその通りで、開発業務は困難の連続です
開発中に思うような性能がが出ないことは普通です
しかし、その多くが「従来のやり方の継続での推進」の中で発生している困難であることが多いです
開発を進めながら私は常に「何か新しいチャレンジを設定してほしい」とお願いしていました
これが難しい
開発者はやはり必要以上のリスクを冒したくない
気持ちはメッチャ理解できます
厳しいＱＣＤを守るだけでも大変なのにさらにリスクを冒すことはよほどのマゾでなければ無理です
しかし、
「それをしなければ部門としても技術者としても成長できない」
と訴え、開発の推進だけでなく、設定したチャレンジの取り組みもしっかり評価するようにしました
重要なのは「失敗を許容すること」
失敗を責めていたら、誰もチャレンジないですね
ただし、「失敗からしっかりと学ぶ」ことが大前提です
製品の新しい構造にチャレンジ、開発期間短縮のためのチャレンジ、品質向上のためのチャレンジ等積極的に設定するようにしましょう
やはり「課題」は「チャレンジ」と言う方がしっくりきます
まとめ
一回目の赴任から元の部署（製品開発）に戻ってからの私の考えの実践について書いてきました
もう一つお伝えしたいこと、
赴任先の先生に教わったこと「伝えることは聞くことから」の実践です
赴任前、ガミガミオヤジだった私は、この学びを実践することを本当に心掛けました
これは、大きかったですね
コミュニケーションがホントにスムーズ
以前からの私の部下は最初、違和感感じて警戒していましたが、しばらくしてからはいいコミュニケーションとれたと思っています
海外行って、少し成長を感じた期間でした
コメント