システムズ エンジニアリングで学ぶ～日本製品の競争力復活のために必要なもの～

システムズ 03 エンジニアリングで学ぶ ～日本製品の競争力復活のために必要なもの～ L E A R N I N S Y S T E M S E N G I N E E R I N G S E R I E S

システムズエンジニアリングで学ぶ ～日本製品の競争力復活のために必要なもの～ 量など）、安全性（運転時の安定性、衝突時の衝撃、エアバッグ装備など）、信頼性（壊れにくさ）などを含んだ 　色々な日本製品の世界におけるシェアが減っている理由として、過剰品質という より広い範囲の用語です。 話が新聞や雑誌に書かれています。 ● 日本勢、成長の芽つかめず　22年世界シェア調査首位、6品目止まり 　 拡大市場では低下(日本経済新聞、2023/9/5)[1] ● ｢完璧主義｣が招く日本の過剰品質（日経クロステック、2021/6/25）[2] ● ｢日本製品｣が海外で売れなくなった根本原因(東洋経済online、2020/7/13)[3] 今回は、この日本製品が直面している品質課題に関して、システムズエンジニアリング の有用性を解説します。 １．品質と機能 　今更かと思われるかもしれませんが、「品質」とはなんでしょう。品質は、JIS(JIS Q 9000:2015) で次のように定義されています。 「対象に本来備わっている特性の集まりが，要求事項を満たす程度」 もう少し分かりやすく言い換えると、「製品、サービス、プロセス、システム、または他の何かが、お 客様が望むものを満たしているかの程度」であるといえます。具体的に、自家用車を例にとって 考えてみましょう。お客様（ユーザー)が自動車に望むものとは、家族でゆったりとドライブしたい、 通勤に使いたい、近くのスーパーマーケットへの買い物に使いたい、というようなことです。これ は、お客様が自動車を使う目的によって異なります。乗り心地が良い、燃費が良い、加速性能が 良いというように、もう少し具体的なことを要望する場合もあります。 特性とは 　「特性」とは何でしょう。自動車でいえば、搭乗可能人数、ドアの数、荷物の積載容量、 車輪数、燃費、加速性能、サイズなどのことです。これらの特性が、上記に述べたような お客様の使い方に応じた要望を満たしているかどうかという程度で、品質が「良い」「悪 い」と語られます。 似た言葉に「機能」という言葉がありますが、機能は対象に本来備わっている働きを表し ます。例えば、走る、曲がる、止まる、ランプを点灯する、速度を表示する、というようなこと です。一方、「特性」は、機能に加えて、性能（最高速度、加速性能など）、物理的特性（サイズ、重 01

システムズエンジニアリングで学ぶ ～日本製品の競争力復活のために必要なもの～ 量など）、安全性（運転時の安定性、衝突時の衝撃、エアバッグ装備など）、信頼性（壊れにくさ）などを含んだ 新興国が、十分な品質かつ必要最低限の機能を有した製品を日本製品より安い価格で供給 より広い範囲の用語です。 するようになった結果、日本製品の競争力が失われていきました。かつての中国製品は、安か ろう悪かろうだったかもしれませんが、お客様のニーズには合致していたということです。 品質の基準はあくまでも「お客様の要求事項」 　ここで気をつけなければいけないのは、品質の基準というのはあくまでもお客様の要求事 項にある、ということです。お客様の求めているものをどの程度満たしているかということで すから、反対に、お客様の求めていないことをどれだけ追求しても、これは「品質」の向上に は結びつきません。例えば、自動車において、小型で短時間使用を望んでいるお客様の車に 豪華な皮シートの座席を搭載しても、これは「品質」の追求ではなく、過剰品質です。このよう にお客様が求めている以上のことを提供することは、必ずしも高品質とは言えません。一方、 信頼性が高い（故障が少ない）という特性は、小型車を求めるお客様でも、高級車を求めるお客 様でも共通の要求事項と言えます。従って、信頼性が高いという特性は、高品質と言えます。 「高品質」と「高機能」であることとは別物 　日本ではしばしば高品質と高機能を混同して使われていますが、高品質と高機能である こととは別物であることに注意が必要です。高機能とは、個々の特性に備わっているものの 働きが優れていることです。例えば自動車のオートドライブ機能、衝突防止機能のような特性 は、自動車が本来持っている「走る」、「止まる」という機能に自動制御という機能を追加した ものであり高機能です。しかしながら、もし衝突防止機能が不十分で事故が防げないような モノであれば、高機能でも品質が悪い自動車ということになります。 　「特性」とは何でしょう。自動車でいえば、搭乗可能人数、ドアの数、荷物の積載容量、 ２．Willingness To Payと日本製品の課題 車輪数、燃費、加速性能、サイズなどのことです。これらの特性が、上記に述べたような お客様の使い方に応じた要望を満たしているかどうかという程度で、品質が「良い」「悪 　高度成長時代以降、「良いものを作れば売れる。」と言われ、日本では海外から色々なシステム い」と語られます。 （製品）を導入してカイゼンを行い、「品質を上げる」ことに努力してきました。この「良いもの」や 似た言葉に「機能」という言葉がありますが、機能は対象に本来備わっている働きを表し 「品質」ということばには、高機能という意味が多分に含まれており、その結果、洗濯機、テレビ、 ます。例えば、走る、曲がる、止まる、ランプを点灯する、速度を表示する、というようなこと 電子レンジなどに使い切れない機能が追加されました。高機能で壊れにくい製品が、かつ安い です。一方、「特性」は、機能に加えて、性能（最高速度、加速性能など）、物理的特性（サイズ、重 価格で提供できた時代には日本製品は海外で競争力を持っていましたが、中国やその他の 02

システムズエンジニアリングで学ぶ ～日本製品の競争力復活のために必要なもの～ 新興国が、十分な品質かつ必要最低限の機能を有した製品を日本製品より安い価格で供給 するようになった結果、日本製品の競争力が失われていきました。かつての中国製品は、安か ろう悪かろうだったかもしれませんが、お客様のニーズには合致していたということです。 Willingness To Pay（WTP）とは 　WTPとは、製品やサービスに対して消費者が自ら喜んで支払う価格のことを表します。 消費者が「これくらいなら支払ってもいい」と思える金額のことで、日本語では「支払意思額」 といいます。このWTPは固定的なものではなく、環境や状況によっても変化します。 例えば、温める時間を設定してスタートすれば良い電子レンジに、色々な調理方法を追加し てその分価格を上げた電子レンジを発売しても、それがWTPと合わなければ消費者は購入 しないということです。日本の携帯電話が「ガラパゴス携帯（ガラケー）」と呼ばれて世界で売れ なかったことは有名です。決して日本に技術力が無かったわけではなく、日本人の価値観で 進化した結果、世界の価値観と合わなかったことが原因です。 　日本では、色々な付加機能を付いた高機能な機種に価値を感じるかもしれませんが、それに 価値を感じない人の方が、世界には圧倒的に多いということです。図で示すと、以下のように 表現できます。 WTP 日本での価値 世界での価値 機能・性能・品質 図： 日本と世界における価値観のズレ 　高度成長時代以降、「良いものを作れば売れる。」と言われ、日本では海外から色々なシステム （製品）を導入してカイゼンを行い、「品質を上げる」ことに努力してきました。この「良いもの」や 日本における製品開発の課題 「品質」ということばには、高機能という意味が多分に含まれており、その結果、洗濯機、テレビ、 　では、売れている他国の製品と同じような品質の製品を作れば良いわけですが、現行製品 電子レンジなどに使い切れない機能が追加されました。高機能で壊れにくい製品が、かつ安い の品質を変更にすることに関して、参考文献[2]において以下のような問題点が指摘されて 価格で提供できた時代には日本製品は海外で競争力を持っていましたが、中国やその他の います。 03

システムズエンジニアリングで学ぶ ～日本製品の競争力復活のために必要なもの～ 　「品質を現地の要求に合う水準にすることを目指しました。現行の製品をベースとして、 一方、新製品開発に対する問題点が、参考文献[3]に以下のように記載されています。 必要以上に高い品質を「落とす」というアプローチです。ところが、品質をどう落とすべきか 答えが見つかりません。その最大の原因が、設計経緯のブラックボックス化です。設計を進め 　「主な敗因は、日本のものづくりが変わってしまったと言うよりも、「変われなかった」点にある。 る中では何度も設計変更が入りますが、実は「念のため」の修正も数多くあります。（中略） 日本も世界のトレンドも「完璧」を目指してはいるが、追い求める「完璧さ」が世界のトレンドとズレ 「本当に必要か分からない設計変更」を実際の製品では何十回、何百回も繰り返しています。 てしまっているのだ。」（中略）「日本は、1つのプロダクトに時間をかけ、器の中の「盆栽」のように、 そのため、いざ品質を適切な水準に下げる方向に設計変更しようとしても、機能や性能に 減点型のミニマムな完璧をつくって広めようとする。それに対して世界のトレンドは、完璧を目指 どんな悪影響が出るか、もはや分からないのです。」 すまでに、いくつものプロダクトをつくり、高速に発売・改良・バージョンアップを繰り返し、大地に 根を張る「大木」のように加点型のマキシマムな完璧をつくって広めようとする。」 問題は、設計経緯のブラックボックス化です。図で表すと以下のようになります。 　ここでいう「完璧」とは、品質の高さを意味しています。日本の企業は最初から高品質を目指し ていますが、世界のトレンドは、ある程度の品質のものを低価格で早く市場に出してシェアを拡大 機能1 HW1 していく戦略を取っています。ドローン市場をほぼ独占している中国のDJIは、正にこのようにして 機能2 HW2 高いシェアを維持しています。つまり、日本が得意としてきたものづくり手法ではお客様のWTPに ブラック HW3 見合った製品を市場に供給できてないということです。市場ニーズが分からないことが原因であ 機能3 ボックス れば、それはマーケティングの問題ですが、市場ニーズが分かっていながらそれに応える製品を SW1 供給できないのであれば、それはエンジニアリングの問題です。 安全性 SW2 「カイゼン」型の設計を繰り返して来たエンジニアやマネジャーにとって、世界トレンドのようなモノ の開発への対応はハードルが高いと考えます。 トラブル対策 設計変更 機能追加 図： 設計経緯のブラックボックス化 　初期のシステム開発においては、設計時に要求機能・性能等を構成品となるハードウェア(HW) やソフトウェア(SW)に割付けていたはずです。その後、機能向上や信頼性向上（トラブル対策）の ために部分的な設計変更を繰り返して、上位要求と実装との繋がり（アーキテクチャ）が分から なくなってしまったのです。海外からライセンス導入したシステムの場合は、そもそもの割付が明確 に理解できないようなケースもあります。 その結果、グレードダウンもできない訳です。日本企業の強みとして長く続けて来た「カイゼン」型 のエンジニアリングの結果です。多くの製造企業がこの問題に直面しており、設計に携わるエン ジニアの大部分がこの設計手法しか経験がなく、他の設計手法を知らないことも問題です。 04

システムズエンジニアリングで学ぶ ～日本製品の競争力復活のために必要なもの～ 一方、新製品開発に対する問題点が、参考文献[3]に以下のように記載されています。 　「主な敗因は、日本のものづくりが変わってしまったと言うよりも、「変われなかった」点にある。 日本も世界のトレンドも「完璧」を目指してはいるが、追い求める「完璧さ」が世界のトレンドとズレ てしまっているのだ。」（中略）「日本は、1つのプロダクトに時間をかけ、器の中の「盆栽」のように、 減点型のミニマムな完璧をつくって広めようとする。それに対して世界のトレンドは、完璧を目指 すまでに、いくつものプロダクトをつくり、高速に発売・改良・バージョンアップを繰り返し、大地に 根を張る「大木」のように加点型のマキシマムな完璧をつくって広めようとする。」 　ここでいう「完璧」とは、品質の高さを意味しています。日本の企業は最初から高品質を目指し ていますが、世界のトレンドは、ある程度の品質のものを低価格で早く市場に出してシェアを拡大 していく戦略を取っています。ドローン市場をほぼ独占している中国のDJIは、正にこのようにして 高いシェアを維持しています。つまり、日本が得意としてきたものづくり手法ではお客様のWTPに 見合った製品を市場に供給できてないということです。市場ニーズが分からないことが原因であ れば、それはマーケティングの問題ですが、市場ニーズが分かっていながらそれに応える製品を 供給できないのであれば、それはエンジニアリングの問題です。 「カイゼン」型の設計を繰り返して来たエンジニアやマネジャーにとって、世界トレンドのようなモノ の開発への対応はハードルが高いと考えます。 ３．システムに対する要求を出すのは誰か 　「品質とは、お客様の要求を満たしているかの程度」と書きましたが、実はこれは必要条 件であり、十分条件ではありません。システムへの要求を出すのはお客様のみではなく、 　初期のシステム開発においては、設計時に要求機能・性能等を構成品となるハードウェア(HW) 他にも多くのステークホルダーの要求が存在するため、彼らの要求も満足して初めて品質 やソフトウェア(SW)に割付けていたはずです。その後、機能向上や信頼性向上（トラブル対策）の の良いものと言うことができます。 ために部分的な設計変更を繰り返して、上位要求と実装との繋がり（アーキテクチャ）が分から 自動車のステークホルダーと要求の例を下図に示します。自動車の使用者に限らず、製造 なくなってしまったのです。海外からライセンス導入したシステムの場合は、そもそもの割付が明確 する人や保守する人、車の型式を認証する国の機関、最近ではSDGｓの観点からの要求 に理解できないようなケースもあります。 もあります。この他にも社内から、将来の拡張性、コスト低減のためのモジュール化や その結果、グレードダウンもできない訳です。日本企業の強みとして長く続けて来た「カイゼン」型 プラットフォーム化というような要求もあります。 のエンジニアリングの結果です。多くの製造企業がこの問題に直面しており、設計に携わるエン ジニアの大部分がこの設計手法しか経験がなく、他の設計手法を知らないことも問題です。 05

システムズエンジニアリングで学ぶ ～日本製品の競争力復活のために必要なもの～ 製造者 メーカ社長 整備工場 ・ 製造容易 ・ 儲かる ・ 保守容易 ・ 検査容易 ・ 顧客満足 ・ 部品入手性良 使用者 ・ 部品標準化 ・ 故障診断容易 ・ 乗り心地良い ・ 標準化 ・ 恰好いい ・ 燃費が良い 解体業者 ・ 安全性が高い ・ 解体容易 ・ 乗員数 ・ 部品再販 ・ 適切な価格 ・ 環境汚染少 ・ 保険が安い ・ 壊れにくい 国 ・ オプション 世界 住民 ・ 事故少 ・ SDGs ・ 騒音少 ・ 環境汚染少 ・ EV化 ・ 環境汚染少 ・ モデル認証 図： 自動車のステークホルダーと要求（例） 　これらの要求を全て取り入れた完璧なシステムを作っていたのでは、前項で書いたように WTPに合わないものになってしまいます。従って、これらの多岐に渡る要望を理解した上で 何をシステム要求とするか、それをいくらの価格で市場に出せば売れるのかを開発目標とし て設定し、開発を進めることが必要となります。 しかしながら、最初にミニマムの機能の製品を市場に出し、次のバージョンではゼロから作り 直していたのでは意味がありません。その為には、最終系は見えずとも柔軟に要求追加、 改良、バージョンアップができるようなアーキテクチャの設計が鍵となります。 この要求定義とアーキテクチャ設計を進める上で役立つのが、システムズエンジニアリング です。 ４．システムズエンジニアリング 　システムズエンジニアリングは、システム全体の設計、開発、運用に関連するプロセス を体系化しており、要求設定から設計、検証をどのように進めると良いかを理解すること ができます。システムズエンジニアリングの詳説は、システムズエンジニアリングハンドブック [４]を参照願います。 ここでは、システムズエンジニアリングのプロセスと品質との関係を説明します。 06

システムズエンジニアリングで学ぶ ～日本製品の競争力復活のために必要なもの～ 1　要求定義 が、ジグソーパズルとレゴブロックを比較してみて下さい。同じ組立パズルですが、ジグ 要求定義は、お客様のみならずステークホルダーの要求を分析し、どのようなシステム ソーパズルは最終形が決まっており、各ピースのインタフェースはバラバラです。もし、 を作るのかを決め、それを機能・性能等のシステム要求として落とし込むプロセスです。 その一部を取り換えようとしたらインタフェースを合わせるのに苦労します。一方、レゴ もう少し具体的には、システムの運用、スコープ、外部インタフェースの定義を行い、 ブロックは、拡張性があり、各ピースのインタフェースが標準化されています。これが その後システムがどのように機能し、パフォーマンスするべきかを定義します。その他に、 アーキテクチャであり、両パズルは全く別のアーキテクチャを取っています。工業製品で 前項でも説明しましたが、物理的な特性、安全性要求、信頼性要求、保全性要求など 言えば、自動車は前者のようなアーキテクチャ（インテグラル型）製品であり、PCは後者の の特性を明確にします。 ようなアーキテクチャ（モジュラー型）製品です。 要求定義において特に重要なことは、お客様の本当に望んでいることを適切に特性と もう一つ、非常に優れたアーキテクチャの例を示します。ネットワークの通信システムで して落とし込むことです。お客様が、やりたいことの目的と、それを成すための手段を混 適用されているOSI参照モデルです。国際標準化機構（ISO）によって定められた通信機 同して要求するようなケースもあるので注意が必要です。要求が不正確もしくは曖昧な 能を役割毎に７つの階層に分類しています。下図のように、計算機間のデータ伝送は、 状態で次の設計プロセスに移ると、当然のことですが、お客様が望んでいるものが出来 標準の通信プロトロルに従ってこの各階層で処理され、ネットワーク上の任意の端末間 上がることはありません。つまり、品質の良いものを市場に出すことはできません。 で確実なデータ伝送が行えるようになっています。日頃何気なく、LAN、Wi-Fi、データ 通信サービス等を切り替えて使っていますが、それができるのはこの標準アーキテク 既存製品の「カイゼン」の場合、システム要求の中でどこがどのように変更されるのか、 チャのお陰です。 どのような要求が追加されるのかなど、他の要求との整合性に問題は無いか等を確認 することが必要です。そのためには、初期の開発時の要求を維持管理することが重要 です。 2　設計 設計プロセスにおいては、上記のシステム要求を段階的にサブシステム、構成品（ハード ウェアとソフトウェア）に割付けると共に内部インタフェースの設定を行います。これがアーキ テクチャ設計です。アーキテクチャ設計の解は、一つではありません。複数の設計解の中 から調達や製造の容易性、設計変更への柔軟性、コスト等を考慮し、QCD(Quality, Cost, Delivery, 品質，コスト，納期）のバランスで、どのアーキテクチャを取るかを決めることが重要で す。 ハードウェアの設計であれば最終的に部品図まで展開されますが、出来上がった図面 からは部品に配分された要求は分かりません。機械部品であっても熱的な特性や電気 的な特性も合わせてもっているかもしれません。アーキテクチャを見える化しておくこと により、将来の設計変更やバージョンアップ時に迷子にならずに済みます。要求同様に アーキテクチャの維持管理も必要です。ソフトウェアの設計も同様であり、ソフトウェアの 変更やバーションアップがスムーズにできるかどうかは、アーキテクチャ設計に掛って います。 アーキテクチャを理解する上で分かりやすい例を紹介します。システムではありません 07

システムズエンジニアリングで学ぶ ～日本製品の競争力復活のために必要なもの～ が、ジグソーパズルとレゴブロックを比較してみて下さい。同じ組立パズルですが、ジグ ソーパズルは最終形が決まっており、各ピースのインタフェースはバラバラです。もし、 カイゼン型のシステム開発では、変更箇所の影響範囲を重点的に検証すると思います その一部を取り換えようとしたらインタフェースを合わせるのに苦労します。一方、レゴ が、設計経緯がブラックボックス化されたシステムの場合は、思わぬところに影響範囲が ブロックは、拡張性があり、各ピースのインタフェースが標準化されています。これが 隠れており、検証されぬまま市場に出てから問題が発生する例があります。特にソフトウェ アーキテクチャであり、両パズルは全く別のアーキテクチャを取っています。工業製品で アは、改修を繰り返してスパゲティー化してしまうとその可能性が高くなります。 言えば、自動車は前者のようなアーキテクチャ（インテグラル型）製品であり、PCは後者の このようなトラブルに関しては、エンジニアは、トラブルの原因究明の中で想定外であった ようなアーキテクチャ（モジュラー型）製品です。 ことを認識することになります。このようなトラブルを未然に防止する観点からもアーキテク チャを見える化して維持管理しておくことは重要です。 もう一つ、非常に優れたアーキテクチャの例を示します。ネットワークの通信システムで 適用されているOSI参照モデルです。国際標準化機構（ISO）によって定められた通信機 能を役割毎に７つの階層に分類しています。下図のように、計算機間のデータ伝送は、 標準の通信プロトロルに従ってこの各階層で処理され、ネットワーク上の任意の端末間 で確実なデータ伝送が行えるようになっています。日頃何気なく、LAN、Wi-Fi、データ 通信サービス等を切り替えて使っていますが、それができるのはこの標準アーキテク チャのお陰です。 データを送信 データを受信 レイヤー7 アプリケーション層 レイヤー7 アプリケーション層 レイヤー6 プレゼンテーション層 レイヤー6 プレゼンテーション層 レイヤー5 セッション層 レイヤー5 セッション層 設計プロセスにおいては、上記のシステム要求を段階的にサブシステム、構成品（ハード レイヤー4 トランスポート層 レイヤー4 トランスポート層 ウェアとソフトウェア）に割付けると共に内部インタフェースの設定を行います。これがアーキ レイヤー3 ネットワーク層 レイヤー3 ネットワーク層 テクチャ設計です。アーキテクチャ設計の解は、一つではありません。複数の設計解の中 レイヤー2 データリンク層 レイヤー2 データリンク層 から調達や製造の容易性、設計変更への柔軟性、コスト等を考慮し、QCD レイヤー1 物理層 レイヤー1 物理層 (Quality, Cost, 図： OSI参照モデル Delivery, 品質，コスト，納期）のバランスで、どのアーキテクチャを取るかを決めることが重要で 3　インテグレーションと検証 す。 このプロセスでは、製作された構成品を段階的に組み立て、初期に設定したシステム ハードウェアの設計であれば最終的に部品図まで展開されますが、出来上がった図面 要求を満たしていることを試験で確認します。 からは部品に配分された要求は分かりません。機械部品であっても熱的な特性や電気 検証においては、要求定義にて設定された特性が全て満足されていることを確認する 的な特性も合わせてもっているかもしれません。アーキテクチャを見える化しておくこと ことが必要です。検証されたシステムが本当にお客様の望んでいるものであるためには、 により、将来の設計変更やバージョンアップ時に迷子にならずに済みます。要求同様に 最初に設定したシステム要求が正しく、それが適切に設計に落とし込まれていなければ アーキテクチャの維持管理も必要です。ソフトウェアの設計も同様であり、ソフトウェアの なりません。また、確実に検証するためには、要求が検証可能である必要があります。 変更やバーションアップがスムーズにできるかどうかは、アーキテクチャ設計に掛って 例えば、「画面が見やすいこと」というような要求は曖昧であり、何をもって要求を満足 います。 しているかを客観的に判断することは不可能です。従って、品質の良いシステムを構築する アーキテクチャを理解する上で分かりやすい例を紹介します。システムではありません ためには、要求作成時にどのように検証するかを考えて文書化することも重要となります。 08

システムズエンジニアリングで学ぶ ～日本製品の競争力復活のために必要なもの～ カイゼン型のシステム開発では、変更箇所の影響範囲を重点的に検証すると思います が、設計経緯がブラックボックス化されたシステムの場合は、思わぬところに影響範囲が 隠れており、検証されぬまま市場に出てから問題が発生する例があります。特にソフトウェ アは、改修を繰り返してスパゲティー化してしまうとその可能性が高くなります。 このようなトラブルに関しては、エンジニアは、トラブルの原因究明の中で想定外であった ことを認識することになります。このようなトラブルを未然に防止する観点からもアーキテク チャを見える化して維持管理しておくことは重要です。 ５．システムズエンジニアリングの導入について 　先に述べたように、日本の製造業の設計者の多くは、部分変更的な設計であったり、専門 分野（機械設計、電気設計、ソフトウェア設計など）の設計業務を主体的に行っており、システム全体の 要求を作成したり、アーキテクチャ設計を行ったりする機会が少ないと思います。 企業のみならず、日本の工学系の大学においても要素技術教育を重視して、システム設計 を教えるようなことをしていません。参考文献[5]にSystems engineeringの学位を取れる 大学のリストがあります。米国の100校に対して、日本は６校です。このような所からも日米企 業のエンジニアのシステム開発能力や意識の差が伺えます。 最近のシステムへの要求は、高機能化、コネクティッド、セキュリティ、安全性等どんどん複雑 化しており、従来の進め方では新たなシステム開発が困難です。複雑なシステムでなくとも、 市場のニーズに合ったシステムをQCＤのバランスを取って開発するためには、システムズ このプロセスでは、製作された構成品を段階的に組み立て、初期に設定したシステム エンジニアリングは有効な手法です。 要求を満たしていることを試験で確認します。 新たな手法の導入に当たっては、リソース、時間、コストの課題や心理的な抵抗もあると思い 検証においては、要求定義にて設定された特性が全て満足されていることを確認する ますが、製品の国際競争力を取り戻すために、今からシステムズエンジニアリングを始めて ことが必要です。検証されたシステムが本当にお客様の望んでいるものであるためには、 みませんか。 最初に設定したシステム要求が正しく、それが適切に設計に落とし込まれていなければ なりません。また、確実に検証するためには、要求が検証可能である必要があります。 【参考文献】 [1] 日本勢、成長の芽つかめず　22年世界シェア調査首位、6品目止まり 日本経済新聞, 2023/9/5 例えば、「画面が見やすいこと」というような要求は曖昧であり、何をもって要求を満足 [2]「 完璧主義」が招く日本の過剰品質, 日経クロステック, 2021/6/25 しているかを客観的に判断することは不可能です。従って、品質の良いシステムを構築する [3]「 日本製品」が海外で売れなくなった根本原因, 東洋経済online，2020/7/13 [4] システムズエンジニアリングハンドブック 第4版 単行本 ‒ 2019/4/16 ためには、要求作成時にどのように検証するかを考えて文書化することも重要となります。 西村 秀和 (監修, 翻訳), デイビッド・D・ウォルデン、他 (編集) [5] List of systems engineering universities, Wikipedia 09

システムズエンジニアリングで学ぶ ～日本製品の競争力復活のために必要なもの～ ■ もっと学びたい人へ サルでもわかるNASA式システム開発 https://levii.co.jp/downloads/guidebook-03/ インタビュー：日本のものづくりは「カイゼン」の積み重ねではもう勝てない？ https://go.levii.co.jp/se-story-001 羅針盤 https://go.levii.co.jp/compass-blog システムズエンジニアリングで学ぶ01 ～ドローン・航空機の認証取得～ https://levii.co.jp/downloads/learn-in-se-01/ システムズエンジニアリングで学ぶ02 ～システム開発のプロジェクトマネジメント～ https://levii.co.jp/downloads/learn-in-se-02/ ■ 執筆者プロフィール 竹内 芳樹 株式会社レヴィ 顧問 三菱重工業株式会社に37年間勤務後、株式会社ispaceに1年半 勤務。2021年7月にレヴィの顧問に就任。三菱重工では主に宇宙 事業に携わり、宇宙ステーション実験棟「きぼう」および同補給機 「こうのとり」の開発においてシステム設計やプロジェクトマネジメント を実施した。 米国PMI認定プロジェクトマネジメントプロフェッショナル 趣味は、登山、ゴルフ、ランニング。日本百名山全山登頂。 座右の銘は、「知彼知己者、百戰不殆」。 制作： 株式会社レヴィ システムデザイン研究所 https://levii.co.jp/ contact@levii.co.jp 10