DXを進める際にマネージャが推進すべきこと
DXによる業務革新をとIT業界では色々な取組みがされているようです。そもそも、IT技術は人の仕事の生産性向上が目的であると思っています。表面的には企業の売上を高めたいとか、効率的に事業運営を進めたい等の指標が気になること路です。
しかし、企業は人なりと言うように、組織の人々が効率的に仕事ができ、組織の意思決定が迅速に行われることだと考えています。
その為には、先にIT技術がありきではないと言うことも意見としてありますが、IT技術を使い倒して何ができるかという着眼も必要なことだと思います。
トヨタ式で言えば、まず、社内の無駄な仕事を見つけ、廃止すべきだと言うのが先で、ITはそのあとでも良いとの方も社内には見受けられました。
無駄な仕事は組織の中で見つけることが一般的であると思います。ところが、DXの意図は、組織を超え、更には企業を超えた視点での革新的発見にあると思います。
一つの組織だけでは解決することのできない根本的な取組をテーマにする必要があります。そうでなければ、部分的なシステム構築を継続することになり、システムは乱立、非連携のままになってしまうからです。
自分たちで必要な要件を考え、SIerに丸投げしない
しかしながら、残念なことに、日本は、情報システムの企画提案、要件定義までをアウトソーシングの風習に浸ってしまっています。
社内の情報システム部門だけにDXの取組責任を命じても、社内の大きな課題を共有できる段階までまとめあげることは難しくなっているのではないでしょうか。
これは、もう30年くらい、このような取引関係の仕組みに、システムベンダーもその下請け開発企業も浸ってしまっているからです。
IT企業には大小合わせて多くの企業が存在しています。ちょうど、製造業における中小企業が多く存在すると同じような形になっているのです。
今からすべきことは、少しづつでも、DXの企画、仕様を社内の人だけでまとめあげることだと思います。
私がトヨタ自動車にて行ったことや得たこと
私は、生産技術に27年間従事して、自動車組立ラインの設計や工場建設、多くの新モデルチェンジへのラインや工程、設備の新設や改造を経験してきました。
特に、新モデルにおける製品の生産設計を設計部門と協力して進める構造設計の検討にも長く従事したことで、製品設計と生産技術と製造部との仕事の流れを習得することができました。
人の仕事は、それぞれの部門の役割の達成が中心となり、部門間にての性能、品質、コストなどで意見がぶつかりあうことが多くありました。
このぶつかりが製品の開発と生産には大変重要なことだと思っていました。ぶつかり合うことを当たり前の仕事の進め方と社員が理解していることはお互いの不足している思考、技術の明確化と共有化に多いに役立つことになるのです。
自部署の技術不足の認識が次のモデルの為の生産技術的な開発テーマにノミネートすることになります。設計部門にもいつまでに、この生産技術開発を行うのかの旗を掲げ、逆にプレッシャーとして懸命に取り組むことにしていました。
このように、お互いの部門が責任を持って、課題を解決する姿勢は、ぶつかり合う組織間の連帯意識の醸成に役立っていると何回も思ったことがあります。
昔、先輩の1人が、仕事は改善することだとおっしゃっていました。改善することこそが仕事だと言う意味でした。その後、私はぶつかり合うことこそがまず、重要なことだと強く認識するようになりました。それもフラットに。それによって改善のネタが見つけられるからです。
トヨタ生産方式の改善は、まずは、日常管理の中で標準を作り、その標準とズレが発生したときに、すぐに気が付く状態にして置くことが第一歩です。在庫管理においても、置き場の区画線を明確に床に記すことはその為です。
エンジニアの業務の見える化をする為に必要なこと
では、現場のようにものが見える状態ではなく、計画部門の仕事の見える化は何をすべきだと思いますか？
それは、計画部門の仕事を進める際の問題点を見える化することから始まるのではないでしょうか？問題点のない仕事が進んでいるならば、ロボットにいますぐにでも置き換えることができるはずです。
人の意見がぶつかり合うことは、推進上の問題点が存在していることを示しています。問題点にはいろいろなことがあるはずです。S ,Q ,C,Dと言う分類に包含されると思います。
私たち生産技術の各部は、それぞれ、一回のモデルチェンジにおいて、3000件の問題点をバインダーにA4用紙をファイルして、工場と設計部署を毎日のように行き来して仕事をしていました。
この3000件の問題点を全て解決しなければならないのです。更に、その進捗を生産管理部門が全体進行役を担っていました。製品開発と生産側だけで問題解決するだけではなく、調整役としてのこの機能は何社かのコンサルタントを行ってきた経験からも、他の企業にはないものです。
結局、製造現場における問題点は、安全、品質、生産性などに区分され、対策管理のサイクルが回ると同じように、計画部門の考える仕事においても、問題点が管理され、その解決のために、対策進捗が管理される仕組みが作られていました。
コンカレントエンジニアリングが推進されるためには、関係部署における課題や問題点の社内共有が必要で、それぞれの部署の問題点がオープンにされなければ進まないと言う当たり前のことを本当に真剣に取り組んでいたと思います。
人の仕事の品質を高める為のDXをまず先に行うこと
このような実際の業務を行うことにより、誰もが気づくことは、また、社内では同じ問題や同じような問題点が繰り返されていることにあります。それも、対策が不十分であったために繰り返されてしまうのは大問題です。
製品開発と生産側の部門において、このような素直なぶつかり合いを避けているのは、言葉は良くありませんが、隠蔽体質になっていると思うのです。
残念なことに、大手企業の業務のミスが、隠され、何年も経過してからの、隠蔽や指摘された検査や認証、品質問題などが後を立ちません。ISO9001は本当に機能しているのでしょうか？
認定取得しただけで、運用面が疎かになっていては、本質的な目的を見失っていることになってしまいます。私たちの計画業務の仕事は、考える仕事なので、その問題点を消すことも簡単です。しかしながら、実際は対策しなければ、必ず再燃してしまうことを意識すべきです。
このように、人の仕事の品質をまずは確かなことにするための仕組み作りをDXとして捉えることが大事であると思います。問題点の社内共有の仕組みであれば、特殊なIT技術を必要とすることではなく、今日であれば、すぐにでもWebシステムでグローバルな問題点管理の仕組みを立ち上げることができるはずです。
難しいIT技術を採用することがDXではないと思います。これまで、人が属人的に行っている仕事を社内共有することが第一歩だと思います。
私も30年くらいIT開発に携わり、いろいろなシステム提案を行ってきております。その中でも、問題点管理システムは一番重要であるもので、トヨタの中においても、ずっと維持されているシステムになります。
製造業のみなさんが一番心配することは、製品を購入していただくお客様のとこで発生する製品の機能や品質問題だと思います。
このことは企業の経営リスクになる一大事なことだと思います。物事の取組には当然、優先順位を付けなければいけないことが良くあります。売上をあげることとお客様の品質問題解決のどちらかが優先度が高いかは考えるまでもない自明なことです。
しかし、この当たり前の意思決定が、特定の組織の中だけで、問題認識され、優先順位が決定されてしまうと、間違った決定を下すことが良くあります。
人の仕事は、お互いに牽制されなければいけません。組織もお互いに牽制されなければいけません。それは、悪意を持って牽制するのではなく、人は弱いものであり、個人、一組織の責任に任せすぎると、担い切れなくなった時に、弱さが出てしまうことを皆で助けあうために行う牽制です。
ものづくりで、一番重要な機能品質の確保を必死に行うとなれば、当然、製品設計の製品構造に皆の知見を集約し、問題の発生しないための活動や業務が重要視されるはずです。
どんな天才であっても、生産現場の工程能力が守れることと守れないことを知り尽くすことはできないでしょう。したがって、ロバスト設計は大変重要な視点になります。
製品の設計も多くの分担により行われるでしょうし、エンジニアリング企業からの協力も得て行われるようになっています。何十年も設計を経験している人と、そうでない人の差は悲しいくらいの格差が設計図面に現れてきます。
このような避けることのできない実際の問題点を設計部門はどのように解決を行うとしているかが大事です。そして、それが、自組織だけで、解決できるかを良く考えるべきだと思います。
その点で、トヨタの開発段階の業務の活動や仕組みは、多くの関係組織を巻き込み、問題点を共有しなければ、進んで行くことのできない方式になっています。とっても当たり前のことですが、製品設計者は他部署から自身の作成したアイデアや図面に注文をつけられることは嫌がるものです。
しかし、トヨタの仕事は40年くらい前から、この嫌がる方式を当然の仕事のプロセスとして、各部門が認識して進めてきていることが大切なDNAとなっています。
知らないことを教え合う心構えをマネージャは率先垂範すること
教え合う関係により、設計の開発上の悩みや、生産側の困りごとを知り、それを知った上で、新しいモデルチェンジの設計には、その対策を取り入れようとする組織の姿勢はなかなか真似のできない習慣だと思います。
私もそれを何社かに提案指導しましたが、執念を持って進めるマネージャーがいないため、道半ばで諦めてしまうことに遭遇しました。一番の問題は、マネージャーが自身の言葉でその重要性を訴えていないことが多いと言うことです。
マネージャーは異動が多いです。部下たちが、マネージャーの思いをどれだけ受け取っているかですが、それが希薄なんだと思います。
企業の中の組織間の信頼関係は、特にものづくりにおける製品設計部門と生産部門ではとても重要なことです。これらが醸成されていない企業の製品は不安だと思うのは私だけではないはずです。
問題点管理システムの他に、考えるべきことは、設計部門と生産部門の間でのデザインレビューの進め方です。
ある企業では原価見積もりが決まったのちにデザインレビューを行っていました。おかしなことです。機能品質の設計構想が定まってから、原価見積もりすべきで、設計構想の段階からものづくりの意見を取り入れなければいけないのです。
企業風土・倫理観の改革（DX)はマネージャの仕事
このようなおかしなことに気づきならがも、手を打てないことこそ根本的な問題点なのです。感性のある人材が不足していることも要因でしょう。
しかし、長年、根本的な問題を解決できていないことは、人材育成が不十分であり、マネージメントの能力も怪しいと言わざるを得ません。
企業の中に存在している個別の問題点を束ねて、根本原因に行き着く活動、風土を作り上げなければいけないのです。
このような風土の企業は、製造現場の品質不良が多く、ラインストップも日常化しています。そして、このような問題点は解決されることなく、製品を手直しして出荷しています。
改善活動は形式化しており、本質対策までやり抜く文化が欠如して行きます。
結果的に在庫が増え、逆に欠品が発生し、相乗効果で、在庫が積み上がります。その在庫を減らすために、見た目で目立たない場所に分散配置して隠すことで問題から逃げようとすることをしてしまうのです。
製品開発に話を戻すと、図面検討プロセスを細分化して、何を検討するのかまで明確にすることが必要です。その検討が行えるためには、製品開発部門は、予定通り、検討に値する図面を作成しなければなりません。
時間がない、工数がないからと言って、安易に検討プロセスをスキップしたり、日程を遅らせることはご法度です。そのくらいに、日程の決め方も根拠を持って開発と生産とで合意しながらプロセスを決めることが必要です。
DXをやるには、その前に、このようにやるべきことが多くあります。それを考えること無く、ITツールを導入してもお金の無駄遣いになるだけです。企業の情報化投資が効果が見えないと言われている場合、ほとんどが、システムやツールやデバイスの購入だけの仕事をしているからに他なりません。
