自動車業界のITプロジェクト、上流の人材が求められている領域

自動車業界のITプロジェクトに関心はあるものの、どんな仕事があるのか見当がつかない。SIerや事業会社で上流の経験を積んできた方から、そうした声を聞くことがあります。業界の外から見ると、車を作る会社のITと言われても、工場のシステムなのか、車に載るソフトウェアなのか、範囲がつかみにくいのは自然なことです。

実際には、自動車業界のIT領域はとても広く、車の開発から生産、品質、部品の調達、販売、アフターサービス、そして会社全体の基盤まで、それぞれに大きなテーマがあります。どの領域にも共通するのは、関係する部署や取引先が多く、業務とシステムの両方を分かる人が構想や要件定義の段階から必要とされることです。

この記事では、自動車業界のITプロジェクトを領域ごとに分け、上流の役割が求められやすいテーマを一般論として整理します。特定の会社の事情ではなく、業界の構造から見た話としてお読みください。

開発領域 ― 設計と試験のデータをつなぐ

車の開発では、膨大な設計データと試験データが生まれます。部品の図面や三次元のモデル、部品表、設計変更の履歴、シミュレーションの結果、実車や部品の試験の記録などです。これらが部署ごと、ツールごとに別々に管理されていると、ある設計変更がどの試験に影響するのか、どの部品表に反映されたのかを追うのに手間がかかります。

この領域で上流の役割が求められるテーマには、次のようなものがあります。

• 設計の部品表と、生産で使う部品表のつながりの整理
• 設計変更の流れと、関係部署への伝わり方の見直し
• 試験データの管理と、設計へのフィードバックの仕組み
• 要求から設計、試験までを追跡できるようにする仕組み

たとえば、部品表の整理では、設計部門が持つ部品表と、生産技術や工場が持つ部品表が、それぞれ別の目的で作られています。どちらが正しいという話ではなく、目的が違うから形が違う。その違いを前提に、どこをどうつなぐかを決めるのが上流の仕事です。設計、生産技術、調達、原価管理など、関係する部署が多いため、それぞれの言い分を整理して落としどころを作る力が問われます。

車に載るソフトウェアの役割が大きくなってきたことで、ソフトウェア開発の管理や、要求の追跡に関わるテーマも増えています。ここでは、機械や電子の設計とソフトウェアの開発を、どう同じ流れで管理するかが論点になります。製造業の設計データ管理の経験と、ソフトウェア開発の管理の経験の両方が活きる領域です。

生産領域 ― 工場の現場と情報システムの間に立つ

生産の領域では、生産計画、工程の管理、設備の稼働データの収集、作業指示、実績の収集などが主なテーマになります。工場の中には、設備を制御する仕組みと、生産を管理する情報システムがあり、その間をどうつなぐかが長年の課題です。

上流の担当者が向き合うのは、たとえば次のような場面です。設備の稼働データを集めて見えるようにしたい、という構想がある。しかし工場ごとに設備の年代もメーカーも違い、データの取り方がそろっていない。現場の保全担当は、日々の設備トラブルへの対応で手いっぱい。こうした状況で、何を、どの工場から、どの順番で進めるかを決める必要があります。

この領域で難しいのは、工場ごとのやり方の違いです。同じ会社の中でも、工場によって生産の方式や管理の細かさが違うことはよくあります。全社で仕組みをそろえたい本社と、自分たちのやり方に理由がある工場との間で、標準化の範囲を決めるのは簡単ではありません。現場に足を運び、ラインを見て、作業者や班長の話を聞いたうえで要件をまとめる姿勢が求められます。

設備を制御する側の技術と、情報システムの側の技術は、担当者も文化も違います。両方の言葉を理解し、間に立って通訳できる人は、どの工場でも重宝されます。

生産計画の領域では、需要の変化や部品の入り方に合わせて、計画をどのくらいの頻度で、どの細かさで立て直すかがテーマになります。計画を立てる担当者の頭の中にある判断の基準を、どこまで仕組みに置き換えるか。その線引きを、計画の担当者と一緒に決めていく仕事です。

品質領域 ― 不具合の情報を、早く正しく流す

品質の領域では、製造工程での検査の記録、不具合の情報、市場からの品質情報、部品のトレーサビリティなどが主なテーマです。自動車は安全に直結する製品なので、不具合が見つかったときに、原因を突き止め、影響の範囲を特定し、対策を打つまでの流れを速く、確実に回すことが求められます。

たとえば、ある部品に不具合が見つかったとき、その部品がどのロットで作られ、どの車両に使われたのかを、どこまで素早く追えるか。そのためには、部品の製造記録、組み付けの記録、出荷の記録がつながっている必要があります。記録が工場ごと、取引先ごとに別の形で残っていると、追跡に時間がかかります。

市場からの品質情報には、販売店からの修理の報告や、お客様からの問い合わせなど、形のそろわない情報が多く含まれます。それを分類し、似た不具合をまとめて傾向をつかむ仕組みは、品質部門にとって大きな関心事です。文章のデータを扱う技術の活用も検討されやすい領域ですが、ここでも先に決めるべきは、誰がどの情報をもとに何を判断するのか、という業務の側の話です。

上流の担当者には、品質保証、製造、設計、販売後のサービスなど、品質情報に関わる部署の業務を理解し、情報がどこで止まっているのかを見つける役割が求められます。品質の記録には、社内の規程や取引先との取り決め、法令にもとづく対応が関わることもあります。そうした部分は、品質保証部門や法務部門と確かめながら進めることになります。

サプライチェーン領域 ― 多くの取引先とつながる

自動車は多くの部品から成り立っており、その部品は何層にも重なる取引先から調達されています。サプライチェーンの領域では、部品の所要量の計算、発注、納入の指示、在庫の管理、取引先とのデータのやり取りなどが主なテーマになります。

この領域の特徴は、自社だけでは完結しないことです。取引先には規模の大きな会社もあれば、小さな会社もあり、システムの整い方もまちまちです。データのやり取りの仕組みを変えようとすると、取引先側の対応も必要になります。上流の担当者は、自社の都合だけでなく、取引先にとって無理のない移行の進め方を考える必要があります。

部品の所要量の計算は、生産計画、部品表、在庫の情報がそろって初めて正しく動きます。どれか一つの精度が低いと、発注の量がずれて、欠品や過剰な在庫につながります。システムを入れ替えるだけでは解決しないことが多く、元になるデータの持ち方や更新の手順まで踏み込んで整理する必要があります。こうした業務のつながりを見渡せるかどうかが、上流の担当者に問われます。

災害や部品の供給の混乱が起きたときに、どの部品が、どの取引先を通じて影響を受けるのかを早く把握したい、というテーマもあります。そのためには、直接の取引先の先にある取引先まで、どこまで情報を持つかを決める必要があります。情報を集めるほど把握はしやすくなりますが、取引先の負担も増えます。そのバランスを、調達部門と一緒に考えるのが上流の役割です。

販売・アフターサービス領域 ― 販売店とお客様の情報

販売とアフターサービスの領域では、販売店との受発注、車両の在庫や配送の管理、お客様の情報、点検や整備の履歴、補修部品の供給などがテーマになります。車は売って終わりではなく、点検、整備、部品の交換、買い替えと、お客様との付き合いが長く続く商品です。

この領域では、メーカー、販売会社、販売店と、情報を持つ主体が分かれていることが多く、お客様の情報をどこまで共有するか、誰が管理するかが論点になります。個人情報の扱いも関わるため、法務やセキュリティの担当者と確かめながら要件を決める必要があります。

通信機能を持つ車から得られるデータを、サービスにどう活かすか、というテーマもあります。ここでは、技術の検討より先に、そのデータで誰に何の価値を届けるのか、データの扱いについてお客様にどう説明するのかを詰めることが求められます。構想の段階から、事業の担当者と一緒に考えられる人が必要とされる領域です。

販売店の業務を支えるシステムでは、現場での使いやすさも大きなテーマです。メーカー側で決めた仕組みを、多くの販売店がそれぞれの業務の中で使うことになるため、現場の声をどう拾い、どこまで反映するかの判断が要ります。

補修部品の供給も、地味ですが欠かせないテーマです。生産が終わった車種の部品を長く供給し続けるには、需要の予測、在庫の配置、古い部品表の管理など、生産とは違う難しさがあります。

全社基盤 ― 会計、人事、データ、セキュリティ

領域ごとのテーマとは別に、会社全体の基盤に関わるプロジェクトも大きな比重を占めます。たとえば次のようなものです。

• 会計、人事、購買などの基幹システムの刷新
• 各領域のデータをまとめて使えるようにするデータ基盤の整備
• グループ会社や海外拠点を含めたIDと権限の管理
• 取引先とのつながりも含めたセキュリティの強化

自動車業界の会社は、国内外に多くの拠点やグループ会社を持っていることが多く、全社基盤のプロジェクトは規模が大きくなりがちです。拠点ごとに業務のやり方や法制度が違う中で、どこまで標準化し、どこを各拠点に任せるのかを決めるのが、上流の大きな仕事になります。

基幹システムの刷新では、長年の作り込みをどこまで標準に寄せるかが大きな論点になります。現場の業務を変えることになるので、システムの話だけでは進みません。業務部門の責任者と一緒に、変える業務と残す業務を一つずつ決めていく、根気のいる仕事です。

データ基盤の整備では、開発、生産、品質、販売と、ここまで見てきた各領域のデータをどうつなぎ、誰が使えるようにするかが論点です。技術の選定より、データの定義と持ち主をそろえる作業に時間がかかります。各領域の業務を横断して理解できる人は、この種のプロジェクトで強く求められます。

領域が違っても、共通して求められること

ここまで領域ごとに見てきましたが、どの領域にも共通して求められることがあります。関係者が多い中で論点を整理し、合意を作っていく力です。設計と生産、本社と工場、自社と取引先、メーカーと販売店。立場の違う人たちの間に立ち、業務とシステムの両方の言葉で話を進められる人が、構想や要件定義の段階から必要とされています。

自動車業界の経験がないことを、過度に心配する必要はありません。部品表、生産管理、品質管理、受発注、基幹システムの刷新といった経験は、他の製造業や他の業界で積んだものでも、かなりの部分が活きます。業界特有の言葉や慣習は、プロジェクトに入ってから身につけていくものです。

この業界のプロジェクトは、構想から要件定義、開発、各拠点への展開まで、同じテーマに長く関わるものが少なくありません。短い期間で成果物を納めて抜けるより、関係者と信頼を積み上げながら進める仕事のしかたが合う人に向いています。

この記事を読んで関心を持った方は、まず、自分のこれまでの経験を、ここで挙げた領域に当てはめて書き出してみてください。どの領域のどのテーマなら、自分の経験がそのまま使えそうか。それが見えると、自動車業界のプロジェクトに参画するときの自分の強みを、具体的な言葉で説明できるようになります。