新着情報

B'zine

2026/04/23

B'zine - 2026年４月号（Webinar：AI時代のQA（品質保証活動）など）を発行しました

B'zine ４月号を発行いたしました。ショート動画(約30秒)も公開していますので、弊社公式YouTubeより是非ご視聴ください。 B'zineは、１回/月のペースでの配信しています。ご興味のある方は、ここから登録をお願いいたします。 B'zineビジネスガレージ通信（2026年4月号） B'zine 4月号をお届けします。新緑の季節になり、もうすぐ待ちに待ったゴールデンウィーク突入ですね。昨年秋頃から頻繁に取り上げられていたクマ出没ニュースですが、今月になって再びクマの市街地出没ニュースも出ていますので、キャンプ、ハイキング等で山岳地帯にお出かけの際は単独行動を避け、安全に十分留意してください。 【今月のトピックス】 イベント：５月２８日（木）第９回Webinar開催：AI時代のQA（品質保証活動）とは何か？～ 人が行うQA、AIが行うQAを考える ～ コラム：Automotive SPICEは守っているのに、なぜ機能しないのか～ WhatとHowの混同から読み解く設計思想 ～ コラム：制御仕様書という怪物～世界標準とプロセスはズレているのに何故品質は良いのか？～ コラム：Automotive SPICE 能力レベル３とは何か？ それは「プロセスの話」だけではない（前編） 動画公開：【第8回Webinar】AIを活用した次世代要件分析プロセスの考察 お知らせ：HPコラムの執筆背景や想いを語る動画シリーズ「B’talk」始動 お知らせ：Automotive SPICE ガイドライン第３版のドラフトが公開されています 【イベント】 2026年5月28日 Webinar：AI時代のQA（品質保証活動）とは何か？～ 人が行うQA、AIが行うQAを考える ～生成AIをはじめとした技術の進展により、開発環境や仕事の進め方は大きく変わりつつあります。それに伴い、QA（品質保証活動）やQAグループに求められる役割や価値についても、見直す必要があるのではないでしょうか？本webinarでは、AI活用そのものを目的とするのではなく、AI時代にQAやQAグループが担うべき役割や価値を改めて整理します。１．期待されているQAとは２．現状の品質保証グループが抱える構造的な課題３．AIが得意なQA領域／人が担うべきQA領域４．AI時代におけるQAモデルの考察詳細、お申し込みはこちらから→https://www.bgarage.co.jp/event/1930/ 【コラム】 Automotive SPICEは守っているのに、なぜ機能しないのか～ WhatとHowの混同から読み解く設計思想  ～Automotive SPICE（A-SPICE）は、車載ソフトウェア開発におけるプロセス能力を評価するためのアセスメントモデルです。当社では先日、「ソフトウェア開発組織をどう評価するか ～エンジニアリングチーム全体を評価し、組織改善につなげるために～」というコラムの中で、SPICEを含む複数の枠組みを用いながら、開発組織をどのように評価し、改善につなげていくかを整理しました。また、これまでのコラムでも、「ドキュメントが作られているが活用されていない」、「プロセスが形骸化している」といった課題が現場で起きやすいことを指摘してきました。しかし、それらは“現象”としては共有されているものの、なぜ起きるのか、どうすれば防げるのかまでは十分に整理されていないケースも少なくありません。本コラムでは、これらの前提を踏まえたうえで、A-SPICEを「評価モデル」として説明するのではなく、「なぜその評価項目が定義されているのか」という観点から読み直します。詳細はこちら→https://www.bgarage.co.jp/news/1721/ 制御仕様書という怪物～ 世界標準とプロセスはズレているのに何故品質は良いのか？ ～「制御仕様書」。 Automotive SPICEと正面から向き合おうとした瞬間、この文書は必ず行き場を失う。Automotive SPICEの成果物として当てはめようがない。かといって、「これは間違っている」「不要だ」と一刀両断できるほど単純でもない。内容そのものは決して無意味ではなく、むしろ多くの現場で実際に機能してきた歴史がある。だからこそ厄介なのである。Automotive SPICEの成果物に、日本の「制御仕様書」をきれいに当てはめられた人は、果たしてどれくらいいるだろうか？詳細はこちら→https://www.bgarage.co.jp/news/1871/ Automotive SPICE 能力レベル３とは何か？ それは「プロセスの話」だけではない（前編）Automotive SPICE（以下、A‑SPICE）の能力レベル3という言葉から、多くの組織が思い浮かべるのは「組織標準プロセスの整備」や「標準化されたやり方が定義されている状態」ではないだろうか。実際、能力レベル3はそのような文脈で語られることが多い。しかし、それは能力レベル3がもたらすの“結果の１つ”であって、“本質”ではない。能力レベル3が本来問いかけているのは、プロジェクト依存のやり方から脱却し、組織として仕事の仕方を意図的に設計し、再利用可能な形で運用できているか、という一点に尽きる。そしてこれは、決して個々のプロジェクトの努力だけで到達できるレベルの話ではない。詳細はこちら→https://www.bgarage.co.jp/news/1901/  【動画公開】 第8回Webinar「AIを活用した次世代要件分析プロセスの考察」のアーカイブ動画を公開しました。本Webinarでは、生成AIを活用することで、従来の要求分析プロセスがどのように変わり得るのかを整理しています。Webinar動画はこちらから（YouTube）→https://www.youtube.com/watch?v=-NX1B97FBUI  【お知らせ】 HPコラムの執筆背景や想いを語る動画シリーズ「B’talk」始動HPコラムの執筆背景や想いを語る動画シリーズ「B’talk」はじめました。当社HPで公開しているコラムは、Automotive SPICEをはじめとしたプロセス改善や設計現場における「違和感」や「つまずき」を、現場視点で言語化してきました。コラムでは書ききれなかったなぜそのテーマを取り上げたのか、何に違和感を感じ、どこで議論が分かれたのか、設計思想やプロセスを形骸化させないために何が必要なのかといった、思考の背景や議論のプロセスをお届けするため、動画座談会シリーズ「B’talk（ビートーク）」をスタートしました。記念すべき第1回のテーマは、「Automotive SPICEは守っているのに、なぜ機能しないのか― WhatとHowの混同から読み解く設計思想 ―」です。詳細はこちらから→https://www.bgarage.co.jp/news/1915/ Automotive SPICE ガイドライン第３版のドラフトが公開されていますVDC QMDから Automotive SPICE Guidelines 3rd edition のYellow Book が一般レビュー用に公開されています。2026年5月12日までの期間でフィードバックを受け付けているようです。資料はこちら→https://vda-qmc.de/en/publikationen-und-apps/gelbbaende/ ゴールデンウィーク休業のお知らせ誠に勝手ながら、下記の期間をゴールデンウィーク休業とさせていただきます。ゴールデンウィーク休業期間：2026年4月29日（水）から2026年5月6日（水）まで休業期間中にいただきましたお問い合わせにつきましては、5月7日（木）以降、順次対応させていただきます。お客様にはご不便・ご迷惑をおかけいたしますが、何卒ご理解賜りますようお願い申し上げます。

お知らせ

2026/04/23

Automotive SPICE 入門　一般開催トレーニング（6月開催）のご案内

Automotive SPICE 入門一般開催（6月分）の日程をご案内いたします。詳細およびお申込みは、下記リンクあるいは「イベント開催日程」からお願いいたします。 Automotive SPICE 超入門2026年6月10日詳細はこちらからAutomotive SPICE 入門 管理支援編2026年6月12日詳細はこちらからAutomotive SPICE 入門 システムエンジニアリング編2026年6月17日詳細はこちらからAutomotive SPICE 入門 ソフトウェアエンジニアリング編2026年6月25日詳細はこちらからAutomotive SPICE 入門 ハードウェアエンジニアリング編2026年6月24日詳細はこちらから  Teamsを使ったオンラインでの開催となります 教材は、原則開催日の５日前までにご指定場所に郵送いたします ご請求書はPDF版をメールで送付いたします お支払い期日は、ご請求書発行日の翌月末となります ご請求書発行後のキャンセルは、お断りしています（代理出席などの手配をお願いします） お申込者以外の方の聴講および録音は固く禁じます

Webinar

2026/04/22

第９回 Webinar　AI時代の品質保証活動とは何か？　～ 人が行うQA／AIが行うQA ～　開催のご案内

第９回 Webinarは、AI時代の品質保証活動について考察します。生成AIをはじめとした技術の進展により、開発環境や仕事の進め方は大きく変わりつつあります。それに伴い、QA（品質保証活動）や品質保証グループに求められる役割や価値についても、見直す必要があるのではないでしょうか。本webinarでは、AI活用そのものを目的とするのではなく、AI時代にQAや品質保証グループが担うべき役割や価値を改めて整理します。 アジェンダ 期待されているQAとは 現状の品質保証グループが抱える構造的な課題 AIが得意なQA領域／人が担うべきQA領域 AI時代におけるQAモデルの考察 参加ご希望の方は、こちらのページからお申込みください。

コラム

2026/04/21

Automotive SPICE 能力レベル３とは何か？　ー それは「プロセスの話」だけではない　（前編）

１．はじめにAutomotive SPICE（以下、A‑SPICE）の能力レベル3という言葉から、多くの組織が思い浮かべるのは「組織標準プロセスの整備」や「標準化されたやり方が定義されている状態」ではないだろうか。実際、能力レベル3はそのような文脈で語られることが多い。しかし、それは能力レベル3がもたらすの“結果の１つ”であって、“本質”ではない。能力レベル3が本来問いかけているのは、プロジェクト依存のやり方から脱却し、組織として仕事の仕方を意図的に設計し、再利用可能な形で運用できているか、という一点に尽きる。そしてこれは、決して個々のプロジェクトの努力だけで到達できるレベルの話ではない。 本来、能力レベル3はプロセス改善モデルの中で、組織としての力を高めていくために、改善を継続的に推進できる状態を指している。プロセス定義は、そのために不可欠な手段の一つではあるが、目的そのものではない。改善を通じて組織力を引き上げるという狙いがあってこそ、プロセスは意味を持つ。にもかかわらず、A‑SPICEの文脈では、能力レベル3が「プロセスを整備したかどうか」という見えやすい側面で捉えられがちであった。その背景には、A‑SPICEがサプライヤー評価モデルとして使われてきた歴史や、プロジェクト中心で読まれやすい構造がある。 本稿では、まず能力レベル3の考え方を起点として、レベル2との決定的な違いを整理し、PPTトライアングル（People・Process・Technology）が示すレベル3の本質を確認する。その上で、なぜA‑SPICEの文脈では、この本質が見えにくくなってきたのかを整理する。なお、本稿は前編として位置づけ、能力レベル3の理解と、その誤解が生まれた背景までを扱う。  ２．能力レベル２との決定的な違いー 「守る」から「設計する」能力レベル2と能力レベル3の違いは、しばしば「標準プロセスがあるかどうか」や「組織で統一されているかどうか」といった表層的な比較で語られる。しかし、それでは能力レベル3の本質を捉えたことにはならない。 能力レベル2までの世界では、プロセスの主語はあくまでプロジェクトである。計画を立て、進捗を管理し、レビューを行い、成果物を管理する。つまり、「決められたことを守れているか」「管理が回っているか」というプロセスの状態が焦点となる。言い換えれば、決められたことを守れているか、が問われる世界である。この段階では、プロジェクトマネージャの力量や、プロジェクト固有の流儀が大きな影響を持つ。うまく回っているプロジェクトは確かに存在し、成果も出る。しかし、それは「そのプロジェクトがうまくいった」という事実に留まり、なぜうまくいったのかが組織として説明できるとは限らない。 能力レベル3で起きるのは、この問いの変化である。 そのプロセスは、誰が何を意図して設計したのか なぜそのプロセスが選ばれているのか プロジェクトごとの違いを踏まえ、どのようにテーラリングするのか 組織として、プロセスをどのように進化させていくのかここで初めて、プロセスは「守るべきルール」ではなく、「意図を持って設計され、使いこなされ、変えていく対象」として扱われるようになる。 レベル3とは、プロセスを単なるルールやチェック対象として扱う段階から、組織の知的資産として扱う段階への転換である。プロセスを通じて、組織としてどのような仕事の仕方を選び、どのように改善していくのかを考え、実行できる状態に移行することを意味している。能力レベル2が「プロジェクト運営を安定させる状態」だとすれば、能力レベル3は「組織としての仕事の仕方そのものを設計する状態」であり、質的に異なる段階なのである。この違いを理解せずに能力レベル3を目指すと、「決め事を増やす」「文書をそろえる」といった活動に陥りやすい。しかしそれは、レベル2の延長線上でできることに過ぎず、レベル3が本来求めている転換点を越えたことにはならない。  ３．プロセスだけでは組織は変わらないーPPTトライアングルが示すレベル３の本質CMMIの世界では古くから、能力レベル3を説明する際に PPTトライアングル（Process・People・Technology） が語られてきた。これは今でも、能力レベル3の本質を的確に突いた考え方である。能力レベル3を「組織標準プロセスを整備する段階」と理解してしまう組織が多い理由の一つは、プロセスという要素が最も目に見えやすく、説明もしやすいからだ。しかし、第2章で述べたように、能力レベル3が目指しているのはプロセスそのものではない。組織として仕事の仕方を設計し、継続的に進化させていく力にこそ本質がある。その前提に立つと、「プロセスだけでは組織は変わらない」という現実が見えてくる。 PPTトライアングルは、CMMIなどのプロセス改善のノウハウとして広く知られるようになったが、その考え方自体は新しいものではない。起源をたどれば、リービットのダイヤモンド・モデルに行き着く。リービットのモデルは、組織を「仕事」「人」「技術」「組織構造」という要素の相互作用として捉え、どれか一つだけを変えても、組織は意図したとおりに変わらないことを示したものである。PPTトライアングルは、この考え方をプロセス改善という実務の文脈で簡潔に整理し直したものだと理解できる。 ここでは、PPTを構成する People・Process・Technology の三要素を取り上げる。ただし、これらを独立した要素として説明する意図はない。三つは相互に影響し合いながら、組織としての仕事の仕方を設計・進化させていくための要素である。  Peopleもっとも重要でありながら、もっとも変化に時間がかかる要素が「人」である。ここで言う「人」とは、単に人数を指すものではない。作業を遂行するためのスキルや技術力、その使い方、さらにはそれを支える文化や価値観を含めた概念である。能力レベル3で問われる「人」とは、プロセスを守るための存在ではない。実際の作業を確実に遂行するために必要なスキルや技術力を備え、それを継続的に向上させていくことが求められる。人の能力が高まれば、より高度なプロセスや技術が必要となり、その結果としてプロセスも変わっていく。人の成長は、プロセス改善の前提条件である。 Processプロセスは固定的なルールではなく、人の能力や使われる技術を前提として設計され、必要に応じて見直されるべきものである。誰が何を意図して設計したのか、なぜそのプロセスが選ばれているのかが説明できなければならず、常に改善の対象として意識されていなければならない。人や技術の成熟なしに、プロセスだけを高度化することはできない。 TechnologyTechnology は、QCD や生産性を向上させるために、設計・実装・テストといった開発活動をどのように支えるかという観点で捉える必要がある。設計やテストに関する新しい技術の導入、使用するツール類の選択、開発環境の整備は、いずれも成果に直結する重要な要素である。重要なのは、技術やツールを単に導入することではなく、人のスキルや能力、そしてプロセスの設計と整合した形で活用されているかという点である。新しい技術の導入は、必要とされるスキルや作業の進め方を変え、結果としてプロセスの見直しを促す。この意味で Technology は、People や Process とは独立した要素ではなく、組織として成果を引き上げていくための重要な構成要素である。適切に選択・活用された Technology は、人とプロセスの力を増幅し、QCD や生産性の継続的な向上を支える。 このように、People・Process・Technology は独立して存在するものではない。どれか一つの軸だけが伸びても、組織全体としての成果（QCDや生産性）は頭打ちになる。三つの要素が相互に影響し合いながら、スパイラル的に伸びていく状態を作って初めて、組織の力は継続的に向上していく。 能力レベル3における組織とプロジェクトの関係能力レベル3においては、改善が組織として回り始め、その結果として、組織とプロジェクトの役割分担と関係性が具体的な形を取るようになる。組織は、標準プロセス、プロセス部品、テンプレート、ツール、テーラリングガイド、そしてプロセス実績データベースといったプロセス資産ライブラリを整備し、プロジェクトに提供する役割を担う。プロジェクトは、これらの標準プロセスや過去の実績データを参照しながら、プロジェクトの特性に応じたプロジェクト用プロセスを設計し、それを前提としてプロジェクト計画を作成する。プロジェクトは設計したプロジェクトプロセスに従って運営され、その結果として得られた実績データが、再び組織のプロセス実績データベースに蓄積されていく。この組織とプロジェクトの間で回るPDCAこそが、能力レベル3における改善の実体である。改善はプロジェクトの中だけで完結するのではなく、組織によって集約され、次のプロジェクトに活かされることで、組織全体としての能力が高まっていく。  帰結として現れるプロセス定義の変化このような前提でプロセス改善が継続的に行われていくと、プロセス定義の在り方そのものも変わってくる。改善が一過性ではなく、PPTの3要素が組織的に回り始めると、プロセスは単なる手順書の集合では維持できなくなる。どの作業がどの目的を持ち、どの成果に結び付いているのか、そして変更がどこに影響するのかを、組織として把握できる形が必要になるからである。その結果として、プロセス定義は必然的に、いわゆるプロセスモデリングに基づいた、よりフォーマルな形へと移行していく。ここで言うプロセスモデリングとは、業務や開発における作業の流れや役割、成果物、相互関係を構造的に表現し、変更や改善の影響を組織として把握・管理できるようにすることを指す。具体的な文書化の考え方やテクニックについては、弊社コラム「プロセスモデリング  〜 プロセス文書化のテクニック」も参照していただきたい。重要なのは、プロセスのフォーマル化そのものが目的なのではなく、改善を継続可能なものにするための自然な帰結として現れる点にある。レベル3におけるプロセスモデリングは、成熟の証明ではなく、改善が組織の中で本当に機能し始めた結果だと言える。  ４．なぜ、この誤解は生まれたのかーAutomotive SPICEという枠組みが生んだ構造的なズレ前章までで見てきたように、能力レベル3は本来、People・Process・Technology を通じて組織としての力を高めていくための入口であり、単なるプロセス定義の段階ではない。しかしA‑SPICEの文脈では、能力レベル3が「組織標準プロセスを整備する段階」として理解されるケースが少なくなかった。この誤解は、特定の組織や個人の理解不足によって偶然生じたものではない。A‑SPICEというモデルがどのような目的で設計され、どのような文脈で使われてきたかを振り返ることで、その背景は構造的に説明できる。サプライヤー評価モデルとして使われてきたA‑SPICEA‑SPICEは、欧州OEMがサプライヤーを評価するための枠組みとして発展してきた。その主眼は一貫して、OEMに影響を与える開発リスクの可視化と低減にある。評価の対象となるのは、あくまで進行中、あるいは予定されているプロジェクトであり、プロジェクトが安定して遂行されるかどうかが最重要関心事であった。この文脈において、能力レベルは「将来に向けた組織変革の成熟度」を測る尺度というよりも、プロジェクトをどの程度安心して任せられるかを判断するための指標として受け止められてきた側面がある。 プロジェクト視点で読み取られた能力レベル３こうした文脈の中では、能力レベル３は自然と、 プロジェクト間で共通に使えるものがあるか 標準化されたプロセスが存在するかといった観点で理解されるようになる。これは、プロジェクトの安定化という目的に照らせば合理的な読み方であり、誤りと断じることはできない。ただし、この理解はプロジェクトを中心に据えた解釈であり、第3章で述べた「People・Process・Technologyを意図的に育て、組織力を高めていく段階」という能力レベル3本来の姿とは、焦点が異なっている。このズレが積み重なった結果、能力レベル3は次第に「組織標準プロセスを整備した状態」とほぼ同義に扱われるようになっていった。 組織としての改善が前面に出にくいモデル構造もう一つ見逃せないのが、A‑SPICEのモデル構造そのものである。A‑SPICEは、開発や管理に関するプロセスを中心に構成されており、人材育成、インフラ整備、測定・分析、継続的なプロセス改善といった組織的活動は、前面には現れにくい構成になっている。CMMIなどのプロセス改善モデルでは、「組織標準プロセス定義」、「組織プロセス改善」、「組織トレーニング」、「測定と分析」といったプロセスが組織プロセス群として定義されている。一方A‑SPICEでは、唯一「PIM.3（プロセス改善）」プロセスが選択されているだけで、「やるべき活動がわからない」という状態になりやすい。このため、能力レベル3を目指す組織の多くが、 まずプロセス文書を整える プロジェクトでそれを使っていることを示すというアプローチに集中し、People や Technology、さらには改善を回すための組織的な仕組みが必要だという発想に至るのは容易ではなかった。なお、組織系プロセスが欠落していることの詳細については、A-SPICEの成り立ちや他のプロセス改善モデルとの比較という観点から、弊社の別コラム「Automotive SPICEの活動を効率良く進めるために」で詳細を整理しているので、併せて参照していただきた。。 誤解は「間違い」ではなく「帰結」であるこうして見てくると、A‑SPICEにおける能力レベル3の理解は、誰かが本質を取り違えた結果として生まれたものではなく、A‑SPICEがサプライヤー評価モデルとして設計され、プロジェクトを中心に使われてきたという背景の中で、自然に形成されてきた理解だと言える。問題は、その理解が固定化され、「能力レベル3＝プロセス定義」というイメージだけが残ってしまった点にある。本来、能力レベル3は、People・Process・Technologyを意図的に育て、組織としてQCDや生産性を継続的に高めていくための出発点に過ぎない。あらためてレベル3の意味を問い直すここまでが、本稿（前編）で整理してきた内容である。能力レベル3を到達点として捉えるのか、それとも次の段階へ進むための入口と捉えるのか。その違いは、改善活動の進め方だけでなく、組織がどこを向いて変わろうとしているのかを映し出す。続く後編では、能力レベル3の先に位置づけられるレベル4・5が何を意味するのか、そしてそれが事業運営や競争力とどのようにつながっていくのかを考察し次のテーマを取り扱うつもりである。後編はこちらから。 レベル3はゴールではない ― レベル4・5が示す世界 20年後を語る企業と、目の前を語る企業 プロジェクトフォーカスから、いつ抜け出すのか このままで、本当にいいのか （日吉昭彦）

お知らせ

2026/04/17

HPコラムの執筆背景や想いを語る動画シリーズ「B’talk」始動

HPコラムの執筆背景や想いを語る動画シリーズ「B’talk」はじめました当社HPで公開しているコラムは、Automotive SPICEをはじめとしたプロセス改善や設計現場における「違和感」や「つまずき」を、現場視点で言語化してきました。ありがたいことに、「自分たちが抱えていた課題そのものだった」「長年モヤモヤしていたことが整理できた」といったお声を、お客様から多くいただいています。 こうした反響を受け、コラムでは書ききれなかった なぜそのテーマを取り上げたのか 何に違和感を感じ、どこで議論が分かれたのか 設計思想やプロセスを形骸化させないために何が必要なのかといった、思考の背景や議論のプロセスをお届けするため、動画座談会シリーズ「B’talk（ビートーク）」をスタートしました。 記念すべき第1回のテーマは、「Automotive SPICEは守っているのに、なぜ機能しないのか― WhatとHowの混同から読み解く設計思想 ―」 コラムをすでにお読みいただいた方はもちろん、これからAutomotive SPICEやプロセス改善に向き合う方にも、考えるヒントを得ていただける内容です。 関連コラムとあわせて、ぜひご覧ください。▶B’talk #01（YouTube）はこちら⇒https://youtu.be/-9W4wwwxISQ▶本動画の元となったHPコラムはこちら⇒https://www.bgarage.co.jp/news/1721/

YouTube

2026/04/17

【第8回Webinar動画公開】　AIを活用した次世代要件分析プロセスの考察

第8回Webinar「AIを活用した次世代要件分析プロセスの考察」のアーカイブ動画を公開しました。本Webinarでは、生成AIを活用することで、従来の要求分析プロセスがどのように変わり得るのかを整理しています。▶Webinar動画はこちら（YouTube）https://youtu.be/-NX1B97FBUIこのWebinarで扱っているテーマ本Webinarでは、EARS形式を前提とした要求仕様作成を題材に、システム要求分析の基本的な考え方と、生成AIを用いることで要求分析プロセスをどのように拡張できるかを考察しています。AIツールの使い方そのものではなく、「どの作業をAIに任せ、どこを人が判断すべきか」「従来の手作業中心の分析プロセスと何が変わるのか」といった観点から、プロセス全体を整理しています。Webinarの構成 今回のテーマ設定の背景 システム要求分析の基本フロー 生成AIを活用した要求分析の実践 プロセス適用に関する考察 まとめこのような方におすすめです 要求分析が形式的な作業になってしまっていると感じている方 要求仕様の品質をどのように高めるべきか悩んでいる方 生成AIを上流工程や要求分析に取り入れるヒントを探している方 要求分析というプロセスを、AIの時代にどのように再設計すべきかを考えるきっかけとして、ぜひご視聴ください。▼ ビジネスガレージ公式YouTubeチャンネルhttps://www.youtube.com/channel/UCeAR1GHu-Ievpfo-3lnP-Ap

お知らせ

2026/04/13

ゴールデンウィーク休業のお知らせ

平素より格別のご高配を賜り、誠にありがとうございます。誠に勝手ながら、下記の期間をゴールデンウィーク休業とさせていただきます。 ゴールデンウィーク休業期間：2026年4月29日（水）から2026年5月6日（水）まで 休業期間中にいただきましたお問い合わせにつきましては、5月7日（木）以降、順次対応させていただきます。お客様にはご不便・ご迷惑をおかけいたしますが、何卒ご理解賜りますようお願い申し上げます。今後とも弊社をご愛顧賜りますよう、よろしくお願い申し上げます。

コラム

2026/04/11

制御仕様書という怪物　～　世界標準とプロセスはズレているのに何故品質は良いのか？　～

１．初めに － Automotive SPICE と制御仕様書「制御仕様書」。筆者にとって、長年自動車業界に向き合ってきた中でも、とりわけ扱いに困る存在である。Automotive SPICEと正面から向き合おうとした瞬間、この文書は必ず行き場を失う。Automotive SPICEの成果物として当てはめようがない。かといって、「これは間違っている」「不要だ」と一刀両断できるほど単純でもない。内容そのものは決して無意味ではなく、むしろ多くの現場で実際に機能してきた歴史がある。だからこそ厄介なのである。 Automotive SPICE の成果物に、日本の「制御仕様書」をきれいに当てはめられた人は、果たしてどれくらいいるだろうか？SYS.2なのか、SYS.3なのか？あるいは、SWE.1なのか、SWE.3なのか？ 真剣に考えれば考えるほど、どれにも完全には当てはまらない。そして一度は「今回はこれでいこう！」と割り切ったはずの整理が、時間を置くと再び蒸し返され、同じ議論を繰り返すことになる。筆者にとって「制御仕様書」とは、できることならなるべく触れずに済ませたい、そんな難物だった。 一方で、日本車の品質が世界最高水準にあることに異論を唱える人は少ないだろう。この事実を踏まえると、制御仕様書を単純に「悪者」として片付けることにも、強い違和感を覚える。 当てはめられない成果物でありながら、品質は高い。この一見矛盾した状況の背景には、日本独自の開発文化と、その象徴ともいえる「制御仕様書」の存在があるのではないか？そう考えるようになった。 本コラムでは、これまで業界内でもあまり正面から語られてこなかった、ある種「アンタッチャブル」な領域に踏み込み、制御仕様書を起点として日本の車載ソフトウェア開発の実態を整理し、筆者なりの見解を述べてみたい。その性質上、通常のコラムよりも記述は長くなってしまった。しかし、それは論点をぼかさず、背景・因果・限界まで含めて整理しようとした結果でもある。本コラムが、制御仕様書や Automotive SPICE に違和感を抱いてきた読者にとって、考えるための材料となれば幸いである。 ２．制御仕様書に感じる違和感の正体本題に入る前に、日本の多くの車載開発現場で作成されている「制御仕様書」とは、具体的にはどのような内容を含んでいるのかを整理しておきたい。筆者がこれまで目にしてきた制御仕様書には、多くの場合、以下のような内容が一つの文書の中に同時に記載されている。 実現したい要求 車両またはECUとしての振る舞い 制御ロジックや状態遷移 ソフトウェアが実装すべき内容 例外処理やフェイルセーフの考え方全体を通して見ると、「このシステムを、このように作ってほしい」という意図を記述した文書のように見える。また、作成者は必ずしもソフトウェアやハードウェアの専門技術者とは限らず、プロジェクト全体の取りまとめ役や、制御・車両側の担当者であるケースも少なくない。 ここまでは理解できる。しかし、筆者が根本的な違和感を覚えるのは、これらの内容が制御仕様書として提示された結果、ソフトウェア技術者が、その記述通りに関数設計を進めてしまう点である。本来であれば、要求を受け取った上で、ソフトウェアの専門家が、ソフトウェアとして最適な構造を検討し、機能をどう分割し、どこに配置するかを設計すべきである。ところが制御仕様書が詳細に書かれているほど、「まずは書かれている通りに作る」という流れが生まれやすくなる。 この違和感について、実際に現場の担当者に問いかけたことがある。その際に帰ってきた答えは、次のようなものだった。 「制御仕様書がないとソフトウェアが作れない。」 「制御仕様書があれば、その通りにソフトウェアを作るだけだ。」この言葉は、制御仕様書が果たしている役割の大きさと同時に、問題の核心を端的に表しているように感じられた。 筆者の視点では、制御仕様書とは、システム全体としての機能的な振る舞いを記述した文書であり、ソフトウェアをどのように実装するかを直接指示するものではない。言い換えれば、制御仕様書はソフトウェアへ割り当てられる前段階の「システム的な振る舞い」を定義しているものと捉える方が自然ではないかと考えている。その意味では、制御仕様書に記載されている内容は、ソフトウェアへ割り当てられたシステム要求として理解することも、一つの解釈である。もし、その振る舞いの検討段階からソフトウェアの専門家が深く関与し、処理概要や構造上の制約を織り込んだ上で記載されているのであれば、また異なる評価も成り立つだろう。 興味深いことに、この制御仕様書に対応する明確な英語名称を、国際標準や各種規格の中で見つけることはできなかった。類似する文書は存在するものの、日本で一般に使われている制御仕様書と同じ役割・粒度を持つ成果物は見当たらない。このことからも、制御仕様書はグローバルな視点で見ると、かなり特異な存在であることがうかがえる。そしてこの問題は、特定の企業や組織の事情というよりも、日本の車載開発に広く共通する構造的な特徴であるように思われる。 この違和感を起点として、次章では、そもそもなぜ制御仕様書がこのような形で発展してきたのか、その歴史的背景を掘り下げてみたい。 ３．制御仕様書が生まれた歴史的な背景制御仕様書が現在のような姿になった背景について、筆者は「開発文化の欠陥」ではなく、歴史的な必然性として捉えるべきだと考えている。車載開発は、その長い歴史の大部分において、メカニカルとワイヤー、油圧を中心とした世界で成立してきた。その時代では、システムの振る舞いは、物理的な構造と機械の動きによって実現されており、設計者とって重要だったのは、「入力と出力の関係」や「状態遷移」、「メカとワイヤーを通した制御の流れ」といった点に集約されていた。このような世界においては、システム全体の振る舞いを一貫した形で記述することが合理的であり、それを担う文書が必要とされた。制御仕様書は、まさにこの文脈の中で生まれたものだと推測できる。 やがて、制御の実現手段としてソフトウェアが導入される。しかし、当初のソフトウェアは、あくまでメカニカルとワイヤーによる制御を置き換える手段として捉えられていた。制御対象の本質が変わったわけではなく、実現手段が変わったにすぎない、という認識が支配的だったと考えられる。そのため、「要求と設計を厳密に分ける」「抽象度の異なるレイヤーを明確に定義する」といったソフトウェア工学的な思考は、当時は開発の中心的なテーマではなかった。重要なのは、システムとして意図した振る舞いを、確実に実現できるかどうかであり、そのための記述として、従来の制御仕様書の枠組みがそのまま踏襲された。結果として、制御仕様書には、 システムとしての振る舞い 制御ロジック 実装上の注意点といった内容が次第に積み重なっていった。これは設計上の誤りというよりも、既存の思考様式の中で、新しい技術を取り込んでいった結果であると理解する方が自然である。このように捉えるならば、制御仕様書とは、メカニカルと制御工学が主導してきた時代に培われた現場の知恵と経験が凝縮された成果物だと言える。現在の視点から見れば整理不足に映る部分もあるが、それは当時の前提条件のもとでは、極めて合理的な選択だった可能性が高い。 この歴史的背景を踏まえることで、制御仕様書を単なる「古い慣習」や「是正すべき悪習」として扱うことの危うさにも気づかされる。問題は、過去の選択そのものではなく、前提条件が大きく変化した現在において、その役割を再定義できているかどうかにある。 次章では、この歴史的背景を踏まえ、日本と欧米で開発アプローチがどのように分岐していったのかを見ていく。 ４．欧米との決定的な分岐点日本と欧米のソフトウェア開発の違いは、技術力の優劣によるものではない。筆者は、開発の重心をどこに置いてきたかの違いが、その後の進化の方向性を分けたと考えている。欧米では比較的早い時代から、ソフトウェアが製品開発の中核として位置付けられてきた。制御対象が同じであっても、それをどのように記述し、どのように分解し、どのように責任分担するかという点に、強い関心が向けれらていた。その結果として、次のような考え方が段階的に定着していく。 要求（What）と設計（How）を明確に分離する 成果物と責任範囲を明文化する 大規模ソフトウェアを前提とした抽象化とレイヤー化 プロセスの妥当性によって品質を担保するという発想これらは単なる開発手法の違いではなく、不確実性をいかに制御するかという思想の違いでもある。 この背景には、欧米の社会構造や文化的要因が強く関係していると考えられる。多民族・多文化社会においては、個々人のバックグラウンドや価値観が異なることが前提となる。その中で協働を成立させるためには、暗黙の了解ではなく、明文化されたルールや契約が不可欠となる。すなわち、 役割を明確にし 責任範囲を定義し 成果物によって合意を形成するという開発スタイルが、社会的にも合理性を持っていた。 一方、日本では、状況は大きく異なっていた。車載開発の中心には、あくまで車両性能があり、その品質は実車評価や現場での調整によって作り込まれてきた。設計と評価、開発と調整は明確に分断されるものではなく、むしろ密接に結びついていた。成果物の境界を厳密に切るよりも、「同じものを見て同じ理解を持つ」ことの方が重要だったのである。その結果、日本では制御仕様書という形で、要求、設計意図、制御ロジック、注意点が一つの文書に集約されていった。一方、欧米では同じ情報を、レイヤーごとに分解し、それぞれ異なる成果物として管理する道を選んだ。 重要なのは、どちらも各々の前提条件においては合理的な選択だったという点である。日本は「現場で品質を作る」道を、欧米は「プロセスで品質を保証する」道を歩んできた。その違いが、制御仕様書のあり方や、成果物の構成として表れただけだと整理できる。弊社では、「日本と欧米におけるソフトウェア開発アプローチの違い」というコラムを掲載しているので、こちらも参考にしていただきたい。 次章では、このような背景を踏まえた上で、なぜ日本の車載開発が結果として高い品質を維持してきたのか、その因果関係を整理していきたい。 ５．なぜ日本製品は高品質なのか？ここで一度、日本の車載開発が高い品質を維持してきた理由について、因果関係を整理してみたい。日本の多くの開発現場では、要求と設計が明確に分離されておらず、制御仕様書に多くの情報が集約されている状況が、今も一般的に見られる。この状況は、グローバルスタンダードの開発プロセスに照らせば、抽象度が揃っておらず、成果物の境界も曖昧で、工学的・プロセス的には未成熟に見えることは否めない。しかし重要なのは、この構造が必ずしも品質低下に直結してこなかった、むしろ逆の結果を生んできたという点である。 制御仕様書という形で、実現したい要求、システムとしての振る舞い、制御ロジック、例外時の考え方までが一つの文書に集約されることで、関係者が共有する文脈は極めて強固なものになる。設計、実装、評価に関わるメンバーが、同じ前提条件のもとで議論を行いやすくなるのである。その結果、設計段階では、「これは正しい動きか？」、「もっと良い方法論はないか？」あるいは「ここでエラーが発生したらどうすれば良いか？」といった検討が、要求・設計・実装を横断した形で行われやすくなる。議論の焦点は、「仕様に書いてあるから正しい」という形式的な妥当性ではなく、「実際の振る舞いとして妥当かどうか」に置かれる。さらに日本の開発では、机上で仕様を完結させるよりも、実際に動かして確認することが重視されてきた。実車や実機を用いて挙動を確認し、問題があれば調整する。必要であれば、仕様そのものを見直す。この一連のプロセスが、暗黙の前提として開発サイクルの中に組み込まれてきた。このような反復的な確認と調整の積み重ねによって、日本の品質は次第に作り込まれてきたと言える。 つまり、日本の品質は、 設計段階で完全性を保証することによって守られる品質ではなく 現場での確認、修正、潰し込みを通じて形成される品質として形成されてきたと言える。 このアプローチは、想定外事象や実使用条件への耐性を高めるという点で大きな効果を発揮してきた。ただし、この品質形成メカニズムは、すべての条件下で普遍的に有効というわけではない。開発対象の規模拡大、ソフトウェアの複雑化、開発スピードへの要求の高まりといった環境変化の中で、このやり方が新たな制約やリスクを生み始めていることも事実である。 次章では、日本方式がこのようにして高品質を実現してきた一方で、なぜ現在、その強みが限界やリスクとして現れ始めているのかについて整理していく。 ６．日本方式の限界とリスク日本の車載開発の方式が、長年にわたり高い品質を実現してきた事実は揺るがない。しかしその一方で、開発環境が大きく変化した現在、この方式が将来に向けてどのような限界やリスクを内包しているのかを冷静に見つめ直してみたい。 文書構造の限界抽象度の異なる情報が混在することで、成果物の役割や責任範囲が曖昧になりやすいという構造的な限界を持つ。特に、レイヤー分離を前提とするグローバル標準に基づく開発プロセスでは、この曖昧さは整合性の低さとして表面化する。その結果： グローバルな分業開発が進めにくい 成果物の責任範囲が不明瞭になる 変更に対する影響の把握に時間を要するといったリスクが顕在化しやすい。これは、国境を超えた多拠点共同開発が世界的に常態化した現在、無視できない制約条件となってくる。 属人性というリスク日本方式の品質は、現場の判断力や調整力、すなわち「人の力」に大きく依存してきた。経験豊富な技術者が、状況を読み取り試行錯誤を重ねながら最適解を導き出す。このアプローチは、過去において大きな成果を生んできた。一方で、この構造は属人性が高く、再現性に乏しいという本質的な課題を抱えている。要員の変更によって判断基準や暗黙知が失われやすく、品質や進め方にばらつきが生じる可能性をはらむ。また、海外拠点や外部パートナーに同様の開発文化を展開することは容易ではない。個人や特定チームの力量に依存する開発モデルは、プロジェクト規模の拡大や組織の分散化に対して脆弱であり、スケールしにくい構造を持つ点がリスクとなる。 アーキテクチャの弱さによる長期的な技術負債のリスク制御仕様書に多くの情報を集約するスタイルでは、個々の制御ロジックを理解するうえで有効だが、ソフトウェア全体を構造として設計・管理することが難しくなる。抽象化やレイヤー化、インタフェースが曖昧になったまま開発が進むと、結果として： アーキテクチャの重要性が意識されにくい プラットフォーム化が進まない ソフトウェア資産の共通化・再利用が困難になるといった状況が生まれやすい。その結果、短期的には大きな問題がなく見えても、長期的には技術負債として蓄積され、将来の変更・拡張時に大きなコストを生むリスクが高まる。また、初期段階でアーキテクチャを確定できない場合、発生し得ない事象にまでDRBFM等の対策工数を割くことになる。一方、スコープを限定し、例外処理が構造化された設計を実現できれば、品質を担保しつつ開発時間を大幅に削減できる。 開発工数の増大と開発期間の長期化という現実的リスクもう一つのリスクとして、開発工数の増大と開発期間の長期化が挙げられる。この問題の本質は、仕様が十分に明確化されないまま開発が進み、後工程ですり合わせによる検討や調整を繰り返す構造にある。多くの現場では、要求や仕様が抽象的な状態で検討や実装に入ることが少なくない。その結果： 不明確な行間や解釈の違いを、すり合わせで解消する 実装してから課題に気づく 実際に動かしながら仕様そのものを調整していくといった進め方が常態化しやすい。このプロセスは最終的な品質向上には寄与するものの、仕様検討と実装・評価が混在した反復作業となり、工数が限りなく膨らむ原因となる。 さらに、ソフトウェアアーキテクチャが十分に設計されていない場合、この傾向は顕著になる。アーキテクチャが不適切であると： 変更の影響範囲の見極めに時間がかかる 修正のたびに広範囲は確認と修正が必要となる 本来不要な検討や後戻りが発生するといった状況が生じ、検討・調整に要する時間が増大する。開発スピードが競争力の重要な要素となっている現在、これらの制約はグローバル競争という観点で、品質とは別の次元で無視できない経営・技術的リスクとなりつつある。 ７．これからのあるべき姿では、これまで見てきた課題に対して、どのような方向を目指すべきなのだろうか。少なくとも、「これまでの日本方式を捨て、欧米方式に全面的に置き換える」という単純な発想は現実的ではないだろう。日本方式は多くの課題を内包しつつも、高い品質を長年にわたって実現してきた。その強みを切り捨てることは、合理的な選択とは言い難い。一方で、ソフトウェアが製品価値の中核となった現在、ソフトウェア工学に基き、仕様や設計を階層化し、構造として管理していくことが不可欠であることも明らかである。これまで述べてきた内容は、日本の車載ソフトウェア開発の「実態」を整理したものであり、理想論ではない。実際、日本の製品開発においても、車載分野以外を見れば、ソフトウェアを中心とした高度なシステム開発や、IT系ソフトウェアでは、従来からソフトウェア工学に基づく開発手法が導入されてきた。特に、日常的にグローバル競争にさらされている事業領域においては、もはやそれが当然の前提条件となっている。 筆者自身も、日本方式と欧米方式を完全に統合した「唯一の正解」を提示できるわけではない。しかし、少なくとも一つの方向性として以下の考え方は共有されるべきだと考えている。まず、ソフトウェア工学に基づいたプロセスと成果物を、製品開発の前提条件として明確に位置付けることである。特にソフトウェアにおいては、製品のマスターとなる要求仕様書や設計書が存在しなければ、保守、機能拡張、再利用は著しく困難になる。グローバルなリソース活用や多拠点開発においても同様である。現在の製品開発では、新たにスクラッチからソフトウェアを開発するケースはむしろ少なく、多くは既存製品に対する拡張や機能追加である。マスターとなるドキュメントは、プロジェクトごとに毎回に作り直すものではない。一度整備されていれば、その後の改版工数は相対的に小さく抑えられる。 その上で、派生開発や機能追加の局面において、日本方式の強みを意図的に活用するのである。具体的には、追加する機能に対して、その制御の流れを記載した「変分仕様書」を作成する。これは従来の制御仕様書に近い形態を持つが、重要な違いとして、修正部分を「変更前」と「変更後」という形で明示的に記述する点が挙げられる。変更内容は常にマスタードキュメントの差分として取り扱われ、プロジェクトの完了までに、その差分をマスタードキュメントへ反映（改版）していく。こうすることで： マスター文書による構造的な整理と再利用性 変文仕様書による現場主導の調整力と具体性を両立することが可能になる。「変分仕様書」を導入したプロセスや、具体的なドキュメントの例については、次の機会で紹介する。 最後に、視野を広げて歴史を振り返りたい。携帯電話、液晶テレビ、通信制御システム、通信サービスなど、日本がかつて世界をリードしていたにもかかわらず、世界標準の流れに乗り切れなかった製品・技術は少なくない。その多くは、国内での成功体験に安住し、構造的な変化への対応が遅れた結果、競争力を失っていった。 自動車産業は、日本にとって極めて重要な事業領域である。だからこそ、同じ歴史を繰り返してはならない。そのためには、「日本方式か、欧米方式か」という二項対立ではなく、強みを理解した上での意識的な再設計が求められている。この課題に対して、単独の正解は存在しない。しかし、問題を正しく認識し、共に改善の方向を探り続けること自体が、最も重要な第一歩であるはずだ。ご不明点、ご質問、ご相談事項あれば弊社ホームページのお問い合わせからご連絡ください。 （日吉昭彦）