IBM Consulting

開発・設計におけるデジタル変革(DX)の成功事例

記事をシェアする:

高田 和彦

高田 和彦
日本アイ・ビー・エム株式会社
IBMコンサルティング事業本部
アソシエイトパートナー

IBMで半導体プロセス開発、小型磁気製品メカ開発を経て技術管理部門で製品情報管理、図面・文書管理などの業務プロセス、業務システムの管理、開発に従事。 それらの経験を活かして製造業のお客様に対する設計プロセス、業務改革支援をご提供

 

近年、製造業のモノづくりプロセスに対するDXの必要性が叫ばれ、適用事例も紹介されるようになってきています。しかし、事例の多くは製造現場における紙中心のプロセスのデジタル化に偏っており、開発・設計プロセスに対する適用事例は件数も限られ、内容も部品情報とCADイメージの連携などの単純なものが大半となっているのが実情です。IBMでは自社の開発・設計業務プロセス改革を実現し、進化・発展させてきた経験から、開発・設計プロセス変革の難しさや、継続的に推進し続ける為の勘所を押さえたDX実現を支援することが可能です。

開発・設計領域におけるDX推進のポイント

開発・設計領域におけるDXの進め方やポイントには多くの共通点があります。

【DXというタイトルで目指すもの】

設計領域におけるDXの目標は「うまくやれている熟練者が意識せずにやっていることを、初心者や領域違いの同僚といった非熟練者でもできるようにすること」です。また、一歩先を目指して「誰でもできるようになったものに関しては設計者がやるのではなくAIにやらせる」までを含む場合もあります。

【設計領域におけるDX推進の阻害要因】

設計者は新しい要求仕様の実現方法を考え出すという創造的な業務を担っています。そのため、設計者に知見や教訓を残すための業務負荷を負わせることは、製品開発のメインのプロセスの進行に悪影響を与えるという認識が定着し、ノウハウの属人化が進行しています。

【局所的な対策の失敗の経験】

設計領域に対しては生産・会計系の基幹システムのような業務プロセスを一貫して誘導・支援するツールが存在しません。PLM系のパッケージソフトの導入についても、機能面では一通りの取り揃えはあるものの、どう使いこなせば自社の製品開発に有効なものになるのかは、導入時の新プロセス設計や移行設計次第です。よくあるケースは、『日程の可視化をしたい』→『プロジェクト管理ツールを入れてタスク定義を求める』→『タスクの管理負荷が増大して後追いの登録となる』→『使われなくなる』といった失敗ケースです。これら失敗経験の積み重なりが、新たな取り組みに対するユーザー部門の否定的姿勢と、推進部門の消極的姿勢の原因となっています。

上記のような状況の中、新たにDXという名のもとで開発・設計領域の改革に取り組むためには、目標を見失わず、あるべき姿・やるべきことが分かっていてもそこにたどり着けない真の原因を考え、その対策を重視した推進方法を関係者全員で検討・合意することが重要になります。
ここではそのポイントを成功事例を参照しながら見てゆくことにします。

開発・設計におけるDXの成功事例

【事例1】スモールスタート(文書管理統合化から始める)

過去のナレッジを活用した設計業務効率化のためには、まず散在している文書の統合化からスタートし、関連する情報に誰でも素早くアクセスできる基盤を整えることが重要です。
忙しい設計者に新たに「あれをしろ」「これをしろ」と言ってもうまくいきません。今までの業務の中から「情報の結びつきを強めることで省力化や効率化の見込めるポイント」を見つけ出し、それを解決する連携の仕組みを提供することで、設計者に次のステップを進めるための余力を生み出します。

 

スモールスタート(文書管理統合化)の事例

スモールスタート(文書管理統合化)の事例

 

【事例2】思考過程に沿った支援機能の提供

設計者にとって新製品の新規性(新しい機能要求に対してどのように対処・実現してゆくのか)を考える作業は最大の負荷であり、過去の知見や教訓、事例の参照が必要になるポイントです。このポイントに対して有効な支援を行うことは設計者にとっても歓迎できることです。新製品と言ってもすべてが新設計というわけではなく、新規部分と流用部分とに分けられ、流用部分では過去の情報の振り返りが行われ、新規部分に関しては新たなチェック項目や検証手順のアイデアを記録しレビューにつなげるという設計者の思考過程、業務過程に沿った画面でのナビゲーションや情報提供、機能提供は設計者にとっても負担感が少なく、納得感の高いものとして受け入れられ、活用されやすいものになります。

 

設計者の思考過程に沿った品質作り込み機能

設計者の思考過程に沿った品質作り込み機能

この事例では、以下の様なユースケースに対応しています。

1.設計者が新製品の機能構成を考えるときには、一般的には過去の類似機種を想定してそれに対する差分(新規性)を考える

  • 過去機種を検索し機能構成を見ながら流用元の製品を決定する
  • 左ペインに選定した過去機種の機能構成が表示され、新規性に基づいた追加削除が行える

2.流用機能に関しては既知の課題の一覧が中央ペインに表示され、今回の製品にも該当するかどうかの判断を行う

  • 「非該当」のチェックとその判断理由を記入することで今回のチェック項目から外すことが可能になっており、必要に応じて追加も可能になっている

3.新規機能に関しては新たな課題想定を行い課題の追加を行う

    • キーワード検索などを活用して機能や部位に関係なく気になる課題を調べることができる

4.過去の課題に関しては分かっている原因や対策、そのために必要な期間や費用、人員などの啓発計画を建てるのに必要な参考情報が表示される(右ペイン)

これらの処理フローや機能は、設計者や品質管理部門との綿密な連携によって構築されており、設計者にとってもこの流れで仕事をすれば見落としが減り、自分だけでは知り得ない参考情報にたどり着け、自分の思考過程も自動的に残せるというメリットが実感できるため積極的な活用を促進できます。結果として「判断過程や知見のデジタル化」「蓄積・再利用」が実現できます。

まとめ

開発・設計領域におけるDXを始めとする効率化や知的資産継承の課題に対しては、開発・設計業務の特性に応じた目標実現へのアプローチが必要です。またその際に必要とされるサポート・ツールに関しても、使い方をしっかり決めてそのとおり運用するといった市販の管理系ツールではカバーしきれない、柔軟な発想に基づく挙動を取り込み表現できる機能が必要になりす。今回の事例でご紹介したツールはIBMのソリューション・アセットである「EI-Core」を活用したもので、このツールはお客様設計部門の多くのユーザーの声によって作成された情報の連携に着目し、その表現と管理を主眼に置いたツールとなっており、これまでうまく実行・推進できなかった開発・設計領域のDX推進において、成功事例の要となっています。

このブログに関するお問い合わせやご相談はこちら


関連情報

More IBM Consulting stories

IBM九州DXセンター AI First BPOサービスの設立 | AIを前提とした業務変革の起爆剤“AI First BPO”

IBM Consulting, 人工知能, 業務プロセスの変革

2024年6月、IBM九州DXセンターとして福岡県北九州市に300名収容のオフィスをリバーウォーク北九州に開設、体制を拡充しました。これまで システム開発及び運用を中心に九州DXセンターの運営を担ってきた日本アイ・ビー・ ...続きを読む


IBM x UiPath、多様性と技術の掛け算で育むデジタル人財

IBM Consulting, RPA, オートメーション...

日本IBMとUiPath株式会社(以下、UiPath)は、2023年9月に「IBM地域UiPath人財育成プログラム」を発表し、デジタル・トランスフォーメーション(DX)人財、特にロボティック・プロセス・オートメーション ...続きを読む