見えない品質課題をどう炙り出すか─NTTデータMSEが語る組み込みソフトウェアの「健康診断」
目次
自動車、家電、産業機器──
かつてハードウェア制御中心だった組み込みソフトウェアは、いまやAI推論やクラウド連携を前提とした巨大な情報処理システムへと変貌している。開発規模は拡大し、サイクルは短期化。
「結合テスト後に不具合が頻発する」「設計に遡ると要件が揺れている」「品質活動が後追いになる」多くの現場が抱える悩みは、もはや個々の工程努力だけでは解決できない構造課題になりつつある。
では、この変化の時代における品質をどう設計すべきか。品質とは何か。問題が顕在化してから対応するのではなく、予防的に品質を確保するための仕組みとはどのようなものか。
組み込み品質に向き合い続けてきた株式会社NTTデータMSE（以下、NTTデータMSE）の坂本 正（さかもと・ただし）は、「品質を仕組みとして設計する時代になった」と語る。
本記事では、坂本が語る品質の常識が変わる時代の品質に対する考え方とその思想を形にしたNTTデータMSEの取り組み「M-QuEST®」を紐解きながら、これからの組み込み開発に求められる品質のあり方を探る。
インタビュイープロフィール
株式会社NTTデータMSE
札幌事業部 品質ソリューションデザイン室 室長
坂本 正
品質の範囲はどこまで広がるか？複雑化する組み込み開発と揺れる品質の”前提”
IoTやエッジAIの急速な普及により、組み込みソフトウェアは従来のハードウェア制御中心の品質担保だけでなく、クラウド連携・データ処理・AI推論などを含む情報処理の品質まで守る対象が一気に広がった。
市場ニーズも「モノ」そのものよりも、体験価値を重視する「コト」消費へとシフトしている。その結果、ソフトウェアが体験において重要な役割を担う製品やサービスが増加し、企業における品質保証の難易度は跳ね上がっている。
「このような背景が影響して、製造業のお客さまからの相談が増えています」と坂本は話す。
こうした変化により、組み込みソフトウェアの高機能化・大規模化が急速に進んだ。数億行規模のコードを扱う開発も珍しくない。その結果、要件・設計・実装・テスト・保守のどこかで生じたわずかなブレが、後工程で一気に不具合となって噴き出しやすくなっている。
加えて、アジャイル開発やDevOpsの普及により、短期開発サイクルとの両立も求められるようになってきている。そのため、従来の「後工程でまとめて不具合対応する」前提の品質保証は、もはや成り立たなくなりつつある。
現場ではさらに別の問題も生まれていた。
NTTデータMSEでは、大規模開発で複数のチームが並行して開発する体制を採用してきた。そうなるとチームごとのプロセスやルールが独自で生まれてしまい、個別最適の集合体になりやすい。そのため最終的な全体品質は有識者の経験に依存する場面が多く、「属人化された品質保証」の限界が顕在化していたという。
一方、組み込みソフトウェアは一般的なアプリケーションソフトウェアと異なり、一度世に出すと簡単には更新できない。そのためリリース前に不具合を必ず抑えたいが、開発期間やコスト制約の面から、単純に開発規模の分だけ品質確保に工数をかけ続けられるわけでもない。
「人的パワーで品質を守るやり方は、もう限界を迎えています」と坂本は語る。こうした構造課題を前に、坂本が強調するのが品質づくりの「前提」そのものの見直しだ。
「開発の最上流である企画段階から、品質を意識したプロセスを組み込めるよう仕組み化するしかありません。後工程で不具合を追いかけるのではなく、最初の段階で品質の前提やリスク、判断基準を整えることが重要です」（坂本）
なぜ上流なのか──NTTデータMSEが築いた「企画段階からの品質づくり」
NTTデータMSEが2025年10月に提供を開始した「M-QuEST®」は、不具合が顕在化してから対応するのではなく、「企画段階から品質をプロセスに織り込む」という思想を体系化したソリューションだ。これには、創立以来45年以上にわたり積み重ねてきた組み込み品質の現場で得た学びが詰め込まれている。
NTTデータMSEはパナソニックグループの100％子会社だった時代に、年間何十機種もの携帯電話のソフトウェア開発に従事してきた。
「20年前、携帯電話は大規模かつ品質要求が高い組み込み製品の代表格でした」と坂本は振り返る。当時の携帯電話は家電レベルの高品質を前提に、毎年増加する機能を限られた期間で実装する必要があった。テストケースを押さえ込みながら、どこで品質リスクが生まれるかを見極め続ける。その経験から坂本は、「品質は工程単体ではなく構造として捉えるべきだ」という現在の思想に辿り着いた。
こうした経験は後に、自動車やモバイルアプリ、産業機器など、他の製造業のお客さまの品質支援にも生かされていく。これがテスト計画〜実行〜分析までを担う「製品評価サービス」、自動化や管理ツール導入を通じて効率化を図る「評価ソリューション」など、NTTデータMSEが蓄積してきた手法は多様な形に発展した。
しかし、どれほど丁寧にテストや自動化を進めても、「上流の仕様が曖昧なままでは品質は安定しない」という課題は残る。
そこでNTTデータMSEが新たに整備したのが「品質コンサルティング」だ。要件定義書・設計書・バグ票・ソースコードなど、開発プロセス全体を俯瞰し、品質リスクの根本原因を上流から見立てる取り組みである。
こうして、上流の品質設計（「品質コンサルティング」）、下流の評価・分析（「製品評価サービス」）、効率化・仕組み化（「評価ソリューション」）をひとつの思想に沿って体系化したものが新サービス「M-QuEST®」である。これら3つのサービスは単なるラインアップではない。品質をチームで語り、判断を共有するための「共通言語」として機能するよう、意図を持って設計されているのだ。
「品質の健康診断」──見えないリスクをあぶり出す「品質プロファイリング」誕生の舞台裏
「品質コンサルティング」の肝である「品質プロファイリング」では、要件定義書・設計書・バグ票・ソースコードなど多様なインプットを横断的に読み解き、品質リスクがどこに潜んでいるかを構造的に可視化する。
その過程を「まさに、ソフトウェア品質の健康診断です」と坂本は語る。
身体の健康診断が数値の異常を発見し、必要に応じて再検査や治療方針へ進むように、「品質プロファイリング」でもリスクの高さを定量的に示したうえで、深掘りや改善案の方向性まで導く。
実は坂本には長年、「品質を評価する仕組みをつくりたい」という思いがあった。しかし、「何を評価軸にすべきか」という問いに最も頭を悩ませたという。
経験だけでも、文献だけでも不十分。複雑化した現代の組み込み開発を正確に診断するため、携帯電話開発で培った品質知見、他領域の品質理論、社内外との議論、多数の文献レビューなど多様な視点を持ち寄り、評価軸は粘り強く作り込まれていった。
「品質プロファイリングは現在も進化中ですが、見えなかった課題が見えるようになったとすでに複数のクライアント企業から評価いただいているのも事実です」（坂本）
「品質プロファイリング」の特徴は、リスクの見える化にとどまらない点だ。
「品質コンサルタントが自分の言葉で、どう直すべきかを提案します。そこが私たちの価値なんです」（坂本）
改善案がお客さまだけで実行しにくい場合には、PMO支援として現場に入り、プロセス改善・育成支援まで踏み込む。さらに改善結果をテスト計画や分析へ反映したい場合は「製品評価サービス」、ツール導入や自動化を進めたい場合は「評価ソリューション」へと自然につながる。
「3つのサービスは発見 → 改善 → 定着が連続的に回る導線として設計しています。まさに処方箋から治療まで伴走するイメージです」（坂本）
ただし「M-QuEST®」は一度で劇的な改善を生む魔法ではない。重要なのは改善サイクルそのものが持続することである。
「改善策は次の開発で生きる。そしてまた新たな課題が見つかる。その繰り返しが品質を育てます。健康診断と同じで、続けることで現場の意識も変わっていくはずです」（坂本）
「品質のブラックボックス」を切開──現場で見えてきた真因と改善のリアル
ここで、坂本は現場でどのように品質の見立てが行われ、改善のサイクルが動き始めたかを事例とともに紹介した。
産業機器メーカーA社の事例：見えない工程が生む「構造的な難しさ」をどう特定したか
A社では設計から結合テストに至る工程の成果物が開示されず、ブラックボックスになっているという制約があった。こうした状況下でも、プロダクト全体の品質リスクを把握し、より開発の上流でリスクに対処できるような仕組みの導入が求められていた。
依頼を受けた坂本は「品質プロファイリング」を実施。要件定義書や基本設計書、システム評価項目書や市場不具合のログなどのインプットから、どこで、どのように不具合が作り込まれているかと言う構造的な課題を明らかにしていった。
明らかになったのは、いずれも上流工程に起因するリスクだった。
「お客さまのプロセスそのものには踏み込めないため、すべてを一度に解決できるわけではありませんが」と坂本は前置きしつつも、課題の因果関係が見えたことで、A社では改善が着実に進み始めた。
「後継機種の評価では、改善の効果が数値として表れ、品質の向上が確認できました」（坂本）
端末機器メーカーB社の事例：改善が進まない開発を設計レベルの真因から立て直す
B社の課題は「品質問題に対して改善が進まない」ことだった。開発を委託しているベンダーに品質改善を求めても、改善が進まない状況に陥っていたという。
ベンダーチェンジする方法もあったと思うが、おそらく新ベンダー探しのコストとノウハウ引き継ぎリスクの大きさを懸念され、現行ベンダーのまま品質向上を図るべく、NTTデータMSEに「問題の傾向分析までは自社で対応するので、真因分析や対応策の検討に協力してほしい」という支援要請が入った。
NTTデータMSEは、まず改善が進まない理由の見立てから着手。担当者が詳細設計書とソースコードを読み解いた結果、根本原因は詳細設計にあると突き止めた。真因を突き止め、改善案を提示したことで、品質問題に対する改善を進めることができたと坂本は語る。
品質という終わりなき「クエスト」──今こそ求められる設計からの品質づくり
組み込み製品の品質を確かなものにするには、企画・要件定義といった最上流からの取り組みが欠かせない。
これは製品開発に携わる人であれば、誰もが理解していることだろう。だが、短期化する開発スケジュールや機能の複雑化により、「分かっているのにできない」ギャップに頭を悩ませる人も多い。
坂本が繰り返し語るのは「品質は最後の検査工程で守るものではなく、最初から設計するものだ」という姿勢である。しかしながら、そのために必要な視点や知識、仕組みが社内で十分に共有されていない——そんな構造的な課題が多くの現場にはあるだろう。
さらに近年では、生成AIの普及によって品質の前提そのものが揺らぎ始めている。生成AIの活用は効率化をもたらす一方で、誤出力やばらつきといった新しい品質リスクも生む。
「AI時代、今と同じ『品質プロファイリング』をしていれば良いとは言えません。生成AIを組み込んだ製品の品質基準そのものを再考する必要があります。今まさに、私たちはそれに取り組んでいるところです」（坂本）
NTTデータMSEでは、生成AIの普及によって変わり始めた“品質をどう評価し、どう保証すべきか”という根本的な問いに真正面から向き合っている。1つは、生成AIを活用した品質評価プロセス効率化。もう1つは、生成AIを組み込んだ製品・サービスをどう評価するか、という新たな品質基準づくりである。
「M-QuEST®」の名称には、「Quality（品質）」を「Establish（確立する）」ために、探求し続けるという、NTTデータMSEの思いが込められている。
組み込みソフトウェアが複雑化する今、品質課題は増え続ける。だからこそ重要なのは、品質を「検査で取り戻す」のではなく「構造として組み込む」発想だ。品質トラブルに直面したときに見直すべきは、前提・要件・評価軸といった上流の設計である。
つまり、品質は変化に応じて常に再定義される必要がある。そして今は、その前提が大きく動きつつある転換点の時期でもある。だからこそ、品質を探求する旅「クエスト（QuEST）」を始めるには、絶好のタイミングなのだ。
ソフトウェア品質・評価ソリューション「M-QuEST®」
https://www.nttd-mse.com/case/detail/m-quest/
※所属組織および取材内容は2025年11月時点の情報です。