Updates

新着情報

コラム

“やりすぎFMEA”に終止符を ─ 生成AIを使ってもっと「創造」しよう ─

はじめにあるお客様から「FMEAの作成に膨大な労力を費やしており、作業を効率化したい。」というご相談をいただきました。これは、多くの開発現場に共通する悩みではないでしょうか。FMEAをはじめとした設計ドキュメントは、品質と安全を確保するうえで欠かせないものです。しかし実際の現場では、開発プロセスに則った各種設計ドキュメントの作成に多くの工数と時間が割かれ、「創造」よりも「作業」に没頭する比率が大きくなってしまうケースが少なくありません。そこで私たちは、生成AI(ChatGPT)を活用し、FMEA作成のプロセスをどこまで自動化・支援できるかを試行する取り組みを行いました。結果として、「FMEAとしてそのままでは使えない部分がある」という課題は残るものの、AIによるたたき台生成の有効性と工数削減効果は明らかであり、「生成AIは必ず使える、確信を持てた」という非常に前向きな評価をいただきました。このコラムでは、その検証結果とともに、FMEA作成に潜む根本的な課題と、それらに対する生成AIの有効性についてご紹介します。 FMEA作成における3つの課題ご承知の通り「FMEA(Failure Mode and Effects Analysis:故障モード影響解析)」は、車載システムの信頼性・安全性を向上させる必要不可欠な設計作業のひとつです。しかしその一方で、作成やレビューにかかる労力が大きく、多くの開発チームにとって「やりすぎになりがちな成果物」の代表格でもあります。実際の現場では、以下のような課題を抱えています。 経験と知識に大きく依存し、属人化しやすい機能安全やフェールセーフ設計など、FMEAには高度な専門知識が必要です。そのため、成果物の質が担当者のスキルや経験に左右されやすく、再利用性やナレッジ共有が難しくなる傾向があります。 組み合わせが膨大で、表の編集作業が重い制御ブロックと信号の組み合わせは膨大で、それぞれに対して故障モードや影響、対策を網羅的に記述しようとすると、膨大なセル数のFMEA表が出来上がります。手作業による展開は工数負荷が高く、更新ミスのリスクもあります。 多人数によるレビューが不可欠だが非効率FMEAの信頼性を担保するためには、複数の有識者を集めたワークショップ形式のレビューが必要となるケースも多く、調整と討議に時間も手間もかかり、調整に追われる場面も多く見受けられます。 生成AIは、これらの課題にどう貢献するのか?今回の検証では、ChatGPTに対して「構成ブロック図」「各ブロックの機能概要」「入力信号のリスト」を与えることで、自動的にFMEAのたたき台を生成するプロセスを試しました。その結果、以下のような具体的なメリットが得られました。 ナレッジの再利用・標準化が可能にChatGPTには、FMEAの基本構造や業界でよくある失敗事例、設計パターンがすでに学習されています。そのため、個人の経験に頼らず、一定の質で初期案を出力できるのが大きな強みです。もちろん、閉域ワークスペースで企業独自のテンプレートや言い回しをAIに学習させることで、自社専用のFMEAナレッジベースを築くことも可能です。 膨大な組み合わせを高速処理従来はエンジニアが手動で展開していたパターンを、AIが論理的に組み合わせて網羅的に出力します。これにより、記述作業にかかる時間を大幅に短縮し、レビューや検討といった本質的な作業に集中できます。今回はFMEA作成に必要な入力情報が準備できた状態から、設計者の手作業だと数週間必要な「FMEA初稿作成」が数時間で対応可能でした。(作業時間短縮試算:80時間(10日間)が4時間に!)実際の工程としては、FMEA初稿作成以降の作業工数(レビューや成果物としての仕上げ)が必要ですが、今回は未評価でした。 レビューを「ゼロからの作成」から「AI出力の確認」へシフト生成されたFMEAはあくまで「たたき台」であり、人による確認と修正は必須です。しかし、ゼロから考えるのではなく、AIが出力した案に対してレビューを行うスタイルに変えることで、ワークショップの効率が格段に向上します。 FMEAにとどまらない、生成AIのポテンシャルこの検証を通じて、私たちはFMEAだけでなく、他の設計成果物(機能仕様書、検証仕様書など)への展開可能性でも同様に大幅な効率改善ができると強く感じました。これからの開発プロセスとして、「まずAIにドラフトを書かせる→人がレビューして精緻化する」という流れが、従来の作業スタイルを大きく変える可能性を持っています。我々としては車載システム開発プロセスに生成AIの活用を組み込みたいといったご要望に対応していきたいと考えています。 おわりに創造的な開発のために開発現場はこれまで、品質を担保するために膨大なドキュメント作成やレビュー作業を背負ってきました。しかし、そのプロセスが目的化してしまえば、本来注力すべき設計検討や創造的な活動の時間が圧迫されてしまいます。生成AIは、こうした作業を効率化するだけでなく、エンジニアが本来注力すべき「創造」や「発想」に時間を取り戻すツールでもあります。「やりすぎ設計書」に終止符を打ち、知的資産を活かしたスマートな開発プロセスへ。生成AIとの協調は、技術者の働き方そのものを変える可能性を秘めています。今回のコラムはいかがでしたでしょうか?本コラムの内容が、生成AIの活用や開発プロセスの見直しのきっかけになれば幸いです。お客様のご相談内容に対する具体的な実施内容や効果を導入事例としてまとめました。こちらもお目通しいただければ幸いです。生成AIを活用した設計ドキュメント作成プロセス効率化支援ご相談いただければ、これまでの経験を活かしてお力になれることもあるかもしれません。どうぞお気軽にお問い合わせください。 (越智功)

コラム

Automotive SPICEを使って業務は改善されているのか?

はじめに「Automotive SPICEを導入してプロセスを整備したけど、本当に現場の役に立っているの?」そんな声を、あなたの組織でも聞いたことはありませんか?たとえば「開発標準は整っているけれど、実際には形骸化していて使われていない」「レビューやチェックリストの数は増えたが、かえって手間が増えて効果が見えない」--こうした現場のモヤモヤは、多くの組織で共通しています。Automotive SPICEの導入やアセスメント対応を契機に、プロセスを整備したものの、「かえって開発がやりにくくなった」「成果が感じられない」という声が上がることも少なくありません。この背景には、“プロセスを定義すること”と“改善すること”が混同されているという問題があります。文書化や標準化はあくまでスタート地点。定義されたプロセスが現場に定着し、実際の課題に対応して見直されてこそ、本当の意味での「改善」と言えます。プロセス改善グループ(EPG:Engineering Process Group)は、開発組織のパフォーマンスを高めるために活動していますが、定めたルールや仕組みも、現場に馴染まなければ“形だけの改善”となり、かえって現場の負荷や反発を招く結果にもなりかねません。本コラムでは、Automotive SPICEなどの成熟度モデルを活用するうえで、プロセス改善が“やりっぱなし”にならず、継続的に成果へとつながっていくための鍵として、EPGと現場との対話、そして改善サイクルの回し方について考えてみます。「やりっぱなし」から脱するには、現場との対話が必要プロセス改善活動のなかで、ありがちな失敗の1つが「とにかく標準を整えよう」「レベルを上げよう」といった目的化の罠です。プロセスの完成度やドキュメントの網羅性を追い求めるあまり、現場の課題感や使い勝手が置き去りになる――その結果、「改善活動が負荷として認識されてしまう」という状況を招いてしまいます。こうした“やりっぱなし”の背景には、「変えたら終わり」という思い込みが潜んでいます。しかし本来、プロセス改善は「一度仕組みを作って終わり」ではありません。運用され、計測され、見直されるというサイクルを回してこそ、本当の意味での“改善”が成立するのです。たとえば、ある開発チームでは、レビューの指摘数や重大バグの混入率といったKPIを継続的に追跡していました。分析の結果、「アーキテクチャ設計レビューでの指摘が少ない一方で、後工程でのバグが多い」という傾向が明らかになり、EPGが設計レビューの観点やタイミングを見直す取り組みを支援しました。具体的には、レビュー観点にシナリオベースの確認を加えたり、関連ドキュメントの整合性チェックを強化するなどして、設計段階での問題発見率が向上。結果として、後工程での重大な不具合流出が有意に減少しました。このように、定量的な観測と実践的なフィードバックを通すことで、改善活動が“やりっぱなし”で終わらず、継続的に改善サイクルを回していく原動力になります。現場に「関わる」ことで、プロセスが生きてくる改善活動が現場に受け入れられ、成果につながるかどうかは、EPGがどれだけ現場に寄り添っているかにかかっています。ある組織では、EPGメンバーが現場のレビュー会議にオブザーバーとして参加することで、レビュー観点の形骸化やチェックリストの実態に合わない運用に気づくことができました。「この観点は、実際には誰も使っていない」「この手順は無理がある」――そんな声を拾い、現場とともにプロセスや観点を見直した結果、レビューの質が改善し、抜けや漏れが減るという成果が生まれました。これは、EPGが“改善する側”ではなく、“一緒に改善する仲間”になることで初めて得られた成果です。プロセス改善を“プロセスのための活動”にせず、現場の本音や実情を反映するためには、こうした「対話」「関わり」「フィードバック」が欠かせません。さいごに今回のコラムはいかがでしたでしょうか?Automotive SPICEは、業務をより良くするための仕組みであるはずです。しかし現実には、「形だけの対応」や「負担ばかり増える」といった声も少なくありません。本コラムが、「改善は本当に現場の役に立っているか?」という視点で、今一度プロセス改善のあり方を見直すきっかけになれば幸いです。EPGという立場だからこそできる“現場との対話”や、“小さな気づき”の積み重ねが、Automotive SPICEを「業務改善のためのツール」として真に機能させる第一歩になります。現場のリアルに触れながら、実践的な改善のヒントを共有できるよう、これからも発信していきたいと思います。(安部宏典)

B'zine

【新着動画公開】Automotive SPICE 4.0特集|B’zine6月号を公開しました!

ビジネスガレージ株式会社が毎月メールでお届けしている月刊ニュースレター「B’zine(ビー・ジーン)」。今回は6月号の動画バージョンを公開しました! 業界の最新動向や、開発現場での活用事例をわかりやすく解説しています。 Automotive SPICE一般開催トレーニング、Webinarのご案内 Modeling & Simulation SPICE 概説資料のご案内 公開中のコラム情報について 車載ソフトウェア開発に関わる方、業界の最新トレンドをキャッチしたい方におすすめの内容です。ぜひご覧ください! ▶ 動画はこちらからご視聴いただけます:https://www.youtube.com/watch?v=4lXto-jehHg

コラム

プロジェクトマネージャーの成長を支える羅針盤──PMCDとは何か?

はじめに現在、車載システム/ソフトウェア開発の複雑な事業環境において、プロジェクトマネージャー(PM)の役割はますます重要になっています。しかし、優れたPMになるために必要なスキルや知識とは、果たして何なのでしょうか?必要な知識をまとめたものとしてはPMBOK® が有名ですが、求められるスキルや育成については明確な定義がありません。そこで登場するのが「PMCD(Project Manager Competency Development Framework)」です。 PMCDの位置づけと背景PMCDは、PMI(Project Management Institute)によって開発されたフレームワークであり、プロジェクトマネージャーに求められる「能力」を体系的に整理したものです。単なる技術的なスキルセットではなく、「知識(Knowledge)」「パフォーマンス(Performance)」「個人特性(Personal Competencies)」の3側面から成り立っており、総合的なコンピテンシーを育成・評価することを目的としています。3つの柱:PMCDのコンピテンシー構造 知識(Knowledge):PMBOK® Guideをベースにしたプロジェクトマネジメント知識体系。プロセスやツール、手法の理解がここに含まれます。 パフォーマンス(Performance):知識を現場でどう活かすか。実際のプロジェクトで成果を出せるかが問われます。 個人特性(Personal Competencies):コミュニケーション能力、リーダーシップ、倫理観など、人物としての資質に関する領域です。この三位一体のアプローチは、単なる資格取得以上に、実務家としての進化に焦点を当てているのが特徴です。さらに、このコンピテンシー構造は、業界や組織が持つ固有のパフォーマンス要件によって、補完&拡張されること許容しています。それぞれのコンピテンスの程度は、コンピテンス指標によって5段階のレベルが定義されています。 3つの柱の内部構造知識のコンピテンスPMP試験や同等の資格認定に合格することで立証されるものとしており、PMCDの定義外ですが、PMに求められる知識を「人」「プロセス」「ビジネス環境」に分類しています。 実践のコンピテンスマネージャーが、プロジェクトマネジメント知識と個人のスキルによって、実施できるまたは達成できていることを評価する領域です。PMBOK® 第3版の知識エリアに基づいて、コンピテンス要素を定義しているだけでなく、パフォーマンス基準と証拠資料を使って、コンピテンス要素を評価する仕組みを提供しています。 個人特性のコンピテンスマネジメントする各プロジェクトメンバの能力に貢献する、振る舞い・態度・文化的な影響およびコアとなるパーソナリティ特性を定義しています。マネージャーは、他者と効果的なやりとりができるスキルをもつことは重要であるため、6つのコンピテンスユニット「コミュニケーション力」「リーダシップ力」「マネジメント力」「認識力」「実効力」「プロフェッショリズム」を定義しています。さらに、実践コンピテンスと同様に、コンピテンス要素を定義しているだけでなく、パフォーマンス基準と証拠資料を使って、コンピテンス要素を評価する仕組みを提供しています。 なぜPMCDが今、注目されるのか?変化の激しい時代において、プロジェクトマネジメントはもはや「計画を守る」だけでは不十分です。ステークホルダーの多様化やアジャイル型の開発環境では、「状況に応じて適応できる力」がPMに求められます。PMCDは、そうした多様な能力を総合的に見える化し、継続的な能力開発のガイドラインを提供する点で、非常に有効です。 ビジネスガレージが提供するPMスキル可視化サービスビジネスガレージでは、組織が求めるPMを育成するご支援の一環として、PMCDや他のフレームワークも活用した、皆さんの組織の特徴や文化に適合したPMスキル可視化をご支援しております。プロジェクト特性や組織特性を考慮して、「会社が期待するプロジェクトマネージャ像」を、お客様と一緒に作り上げます。弊社の熟練専門家が、ドキュメントやヒアリングを通じて、組織の特徴を整理するだけでなく、プロジェクトマネージャへの期待を明文化し、期待するプロジェクトマネージャが保有すべきスキルを言語化します。  既成のフレームワークに囚われない、実用的なスキル定義をご提供しておりますので、興味のある方は是非お問い合わせください。 さいごに自己評価と育成の道しるべとしてPMCDは評価のための“物差し”であると同時に、成長のための“地図”でもあります。自らの強みや課題を客観的に把握し、戦略的にキャリアを築いていくうえで、非常に有用なツールといえるでしょう。 内山哲三

B'zine

B'zine - 2025年6月号(無料Webnar 7/30開催など)発行

先日梅雨入りしたと思ったら、まだ6月なのに連日の猛暑日が続いています。熱中症および体調管理には十分ご留意ください。B'zine 6月号を発行いたしました。B'zineは、1回/月のペースでの配信しています。ご興味のある方は、ここから登録をお願いいたします。   B'zineビジネスガレージ通信(2025年6月号)  先日梅雨入りしたと思ったら、まだ6月なのに連日の猛暑日が続いています。熱中症および体調管理には十分ご留意ください。 【今月のトピックス】 イベント:Automotive SPICE 入門(実務者向け)一般開催トレーニング(7月、8月) イベント:7月開催Webinar:Automotive SPICE/機能安全/サイバーセキュリティを両立する設計アプローチと事例紹介を開催 資料公開:Modeling & Simulation SPICE 概説資料を公開 コラム:システムの論理構成と物理構成について コラム:Automotive SPICE 4.0 トレーサビリティと一貫性に関する変更点(SYS/HWE):HWE導入によるプロセスのギャップ解消 コラム:Automotive SPICE MAN.3計画の計画(GP2.1.2)とは何か? 【イベント】 Automotive SPICE入門(実務者向け)一般開催トレーニング開催のご案内(7月、8月開催)開発現場の実務者に役立つような具体的な事例を含めて、プロセス毎に解説します。詳細・お申込みはこちらから→https://www.bgarage.co.jp/news/1121/ 7月30日Webinar開催:Automotive SPICE/機能安全/サイバーセキュリティを両立する設計アプローチと事例紹介Automotive SPICEが規定する開発プロセスと、機能安全やサイバーセキュリティをどのように融合するかを解説します。詳細・お申込みはこちらから→https://www.bgarage.co.jp/news/1199/ 9月Webinar(予定):Modeling & Simulation SPICE 概説システム開発および運用において、高信頼性のモデルベース開発やシミュレーションの体系的なエンジニアリングプロセスについて解説します。 【資料公開】 Modeling & Simulation SPICE 概説intacs からModeling & Simulation SPICEが公開されましたが、その概説書を作成したので公開します。詳細はこちら→https://www.bgarage.co.jp/news/1197/ 【コラム】  システムの論理構成と物理構成についてAutomotive SPICEのプロセスであるSYS.3システムアーキテクチャ設計プロセスでは、システムの機能要求と非機能要求に関して、静的/動的の両側面での設計が期待されていますが、実際にシステム構成要素にシステム要求をどのように割り当て、実装することが最適なのかを分析・検討することは難しいものです。システムエンジニアリングの国際標準を参考に、システム要求からシステムを設計する流れを解説します。詳細はこちら→https://www.bgarage.co.jp/news/1137/  Automotive SPICE 4.0トレーサビリティと一貫性に関する変更点(SYS/HWE):HWE導入によるプロセスのギャップ解消Automotive SPICE 4.0では、従来のソフトウェア中心の構成から一歩進み、ハードウェアエンジニアリング(HWE)という新たなプロセス領域が追加されました。トレーサビリティと一貫性の観点から、SYS(システムエンジニアリング)とHWEの関係性に焦点を当て、HWE導入がもたらすプロセス上のギャップ解消について説明します。詳細はこちら→https://www.bgarage.co.jp/news/1155/  Automotive SPICE MAN.3計画の計画(GP2.1.2)とは何か?Automotive SPICE の能力レベル2では、プロセスに対する目標設定や計画、監視と制御などが求められています。例えばソフトウェア要求分析(SWE.1)では、要求分析の作業を計画的に進めるためにWBSなどを使用して管理しますが、プロジェクト管理(MAN.3)の作業を計画的に進めるには何を実施すればよいのかわからないケースが多いようなので、MAN.3のGP2.1.2をどのように捉えればよいかを解説いたします。詳細はこちら→https://www.bgarage.co.jp/news/1144/ 

Webinar

第4回 Webinar ~ Automotive SPICE/機能安全/サイバーセキュリティを両立する設計アプローチと事例紹介 ~ 開催のご案内

第4回 Webinarは、車載開発に要求されいてる2つの規格(ISO 26262 および ISO 21434)を効果的に適用するためのアプローチについてご紹介いたします。これらの要求は、既に開発済みの開発プロセス(車載開発組織では Automotive SPICE に準拠した形で作成するのが一般的)に共通の方針で取り組むことで、開発者へ効率的なプロセスを提供することが可能です。弊社では、サイバーセキュリティプロセス開発の事例や、ISO 26262・ISO/SAE 21434導入ガイドラインも発行していますので、是非こちらもご参照ください。 参加ご希望の方は、下記フォームからお申込みください。

WhitePaper

Modeling & Simulation SPICE 概説資料を公開しました

Intacs から公開されている Modeling & Simulation SPICE の概説書を作成いたしましたので公開いたします。ご興味のあるかたは、是非ダウンロードして活用してください。 コンテンツに含まれるもの: Modeling & Simulation SPICE の構造  信用できる決定プロセス群(DEC) DEC.1 エンジニアリングおよび決定タスク分析 DEC.2 サブタスク定義 DEC.3 結果評価および決定 モデリングおよびシミュレーションエンジニアリングプロセス群(MSE) MSE.1 シミュレーションサブタスクおよび目標分析 MSE.2 シミュレーション設定要求分析 MSE.3 シミュレーション設定設計 MSE.4 シミュレーション設定実装(エレメント構築) MSE.5 シミュレーション設定エレメント検証 MSE.6 シミュレーション設定統合および検証 MSE.7 シミュレーション実施および評価 MSE.8 シミュレーションサブタスクおよび目標達成の決定 信憑性保証プロセス群(CRD) CRD.1 重要度特定 CRD.2 信憑性尺度および手法 

コラム

Automotive SPICE MAN.3 計画の計画(GP2.1.2)とは何か?

皆さんご承知のように、Automotive SPICE の能力レベル2では、プロセスに対する目標設定や計画、監視と制御などが求められています。例えばソフトウェア要求分析(SWE.1)では、要求分析の作業を計画的に進めるために、WBS(Work Breakdown Structure)などを使用して管理するわけですが、プロジェクト管理(MAN.3)の作業を計画的に進めるとなると、何を実施すればよいのかわからなくなってしまうケースが多いようです。そこで今回は、MAN.3の GP2.1.2 をどのように捉えればよいかを解説いたします。 ここでは、「計画の計画って何?」ということを良く耳にします。「プロジェクト計画策定計画」なる書類を作成しているプロジェクトも見たことがあります。おそらく、MAN.3 の主要成果物がプロジェクト計画書なので、プロジェクト計画を作成するための計画が MAN.3 の GP2.1.2 になると言いたいのだろうと思います。確かに、プロジェクト計画書はプロジェクトの初期に作成することが重要でありながら、タイムリーに作成されないことが多く、プロジェクト計画を作成するための計画が必要だということは間違っていないのかもしれません。しかしながら、あまりにも Automotive SPICE にこだわりすぎた事例だと思いませんか?プロジェクト計画作成というタスクが1つ(あるいは不随した複数のタスク:例えば日程計画、工数見積もりなど)あれば十分だと思います。  実際に実施している作業や、計画・管理として重要な側面を考えていくことで、実施すべき作業(あるいは Automotive SPICE への適用)が見えてくると思います。 実際に、計画に関連する作業を一般事例の中から抽出してみます: ウォーターフォール的なライフサイクルを適用している場合  プロジェクトの開始当初に、大日程を作成する- 機能一覧を作成し各機能に必要な概算工数を見積もる- 大日程上の各工程で必要となる作業を洗い出し中日程を作成する- 各工程に必要な概算工数を算出し、プロジェクト合計工数として積み上げる  各工程の開始時に、工程内で必要なタスクを抽出し、小日程を作成する- 各タスクに必要な工数を算出する- この際、当初算出した工程工数との差異を分析する- 必用に応じて対策を検討し、全体計画を修正する  各工程の終了時に、工程内で使用した実績工数を集計する- 工程開始時に算出した工程工数との差異を分析する- 必用に応じて対策を検討し、全体計画を修正する アジャイル的なライフサイクルを適用している場合 プロジェクトの開始当初にイテレーション数、スプリント回数・期間を決める- バックログを作成する- 各イテレーションに割り当てる要件を決定する  各イテレーションの開始時に、スプリントを計画する(スプリントプランニング)- 各スプリントに割り当てる要件を選択して、ストーリーポイントを算出する- 各スプリントに割り当てる要件をバックログから選択する- 要件毎に作業タスクを決定する 各スプリントの終了時に、スプリントの状況を評価する(スプリントレトロスペクティブ)- 次のスプリントに持ち越す要件、中止する要件などを精査しバックログを修正する 各イテレーションの終了時に、イテレーションの状況を評価する- バックログを精査し、全体の計画を見直す いかがでしょうか?ここに記載した内容はプロジェクトの中で当たり前のように実施している作業だと思います。計画の計画(MAN.3 のGP2.1.2)とは、これらの作業が実際に行われていれば良いのです。つまり、プロジェクト計画書作成計画というような計画書だけが焦点ではなく、都度進んでいく工程(アジャイルの場合はイテレーションやスプリント)ごとに、初期計画を詳細化する(あるいは見直す)ことが、計画作業そのものなのです。これらを計画的に進めるためには、WBSタスクの設定や作業者のアサイン、作業工数の見積もりなどが必要になってくることは言うまでもありません。 最後に余談ですが、MAN.3 GP2.1.3(リソースのニーズを決定する)/GP2.1.4(リソースを識別し、利用可能にする)について補足いたします。上記で説明した例のように開発ライフサイクルが異なってくると、人的リソースや物理的リソースへの要求事項も変わってきます。例えば、アジャイル手法を用いるプロジェクトでは、プロダクトオーナーやスクラムマスターといった役割が登場します。また、管理手法もカンバンやバーンダウンチャートなどを使用することになります。プロジェクトで採用するライフサイクルにより、計画・管理のタスクや役割・スキル要件、必要なツールが異なってくることを再認識できますね。例えば今回の計画の計画のように、一瞬戸惑うことがあるかもしれませんが、日々実施していることを整理することで、無駄な作業を追加することなくAutomotive SPICEへの適用ができるはずです。 日吉昭彦