開発者のためのシステムズエンジニアリング導入の薦め

第 1.1 版
2017 年 7 月 3 日
独立行政法人情報処理推進機構
技術本部 ソフトウェア高信頼化センター

目次
はじめに .................................................... 4
第１章 製品／サービスの開発に関わる現状の課題 .............. 5
１−１

環境の変化 ....................................................................... 5

１−２

課題 .................................................................................. 7（１）

想定外のモノ・コトのつながり ..............................................7（２）

隣接する分野の事業への進出によるルール変化 .................8（３）

新サービスが生まれることによるビジネス環境のリスク .........9（４）

考慮すべき条件の拡大 ....................................................10

１−３

新しいアプローチの必要性 ................................................. 11

第２章 新たなアプローチ〜システムズエンジニアリング ...... 12

２−１

システムズエンジニアリングとは .......................................... 12

２−２システムズエンジニアリングの４つのポイント ........................ 13（１）

目的指向と全体俯瞰 ........................................................13（２）

多様な専門分野を統合.....................................................14（３）

抽象化・モデル化 .............................................................15（４）

反復による発見と進化 ......................................................16

コラム:IoT とシステムズエンジニアリングについて ............. 17
第３章 システムズエンジニアリングの有用性 ................. 18
３−１

QCD への効果 .................................................................. 18

３−２

有用性を示す事例 ............................................................. 20

第4章

システムズエンジニアリングの導入の取組み ........... 26

４−１

システムズエンジニアリングの４つの主たる活動 ................... 26（１）

システム設計 ...................................................................28（２）

インテグレーション ............................................................28
2

（３）評価・解析 .......................................................................29（４）

システムズエンジニアリング管理 .......................................30

４−２

主たる活動において４つのポイントをどう活かすか ................ 30（１）

システム設計 ...................................................................30（２）

インテグレーション ............................................................32（３）

評価・解析 .......................................................................32（４）

システムズエンジニアリング管理 .......................................34

４−３

補足（調査報告、一般情報） ................................................ 35（１）

システムズエンジニアリングの導入にあたっての推奨事項 ..35（２）

効果的なシステムズエンジニアリング導入のための考慮点 .39

おわりに ................................................... 40
参考資料 ................................................... 41
付録

システムズエンジニアリング適用チェックポイント ...... 44

3

はじめに
IoT の進展により、製品／サービスが多様化しネットワークにつながるようになったことを背景に、これまでにない組み合わせでモノ・コトをつなげて、高い価値をもたらすことを目指す取り組みが始まっている。
一方、その対象となる分野・範囲の広がり等により、製品／サービスの企画・開発を行おうとする際、特定分野に特化した従来型のアプローチそのままでは目的の達成は難しくなっている。
IPA/SEC では、この難しい問題に直面している企業・団体の経営者向けに、2017 年 3 月に「経営者のためのシステムズエンジニアリング導入の薦め」を公開し、事業を成功に導くアプローチと手段の体系として注目されているシステム
ズエンジニアリングを紹介した。
本書はその次の段階として、実際の製品／サービスを企画・開発している担
当者及びその管理者を対象に、システムズエンジニアリングの紹介を行うものである。
そのため、現状の課題につき例を挙げて解説するとともに、システムズエン
ジニアリングの導入の際のポイントをより詳しく説明した。さらに、そのポイント
を実際のシステムズエンジニアリングの活動へ活かすための考え方も新たに書き加えた。

4

第１章 製品／サービスの開発に関わる現状の課題
本章では、IoT 時代の製品／サービスの開発に関わる課題を紹介し、これらの課題を解決するためには新しいアプローチが必要であることを説明す
る。
１−１

環境の変化

１−２

課題

（１）

想定外のモノ・コトのつながり（２）

隣接する分野の事業への進出によるルール変化（３）

新サービスが生まれることによるビジネス環境のリスク（４）

考慮すべき条件の拡大

１−３

新しいアプローチの必要性

１−１ 環境の変化
平成 28 年度版情報通信白書によると、インターネットに接続される IoT デバ
イスの数は 2020 年までに 304 億個まで増大すると予測されている。 今や携
帯電話や自動車、金融システムなど、組込みソフトウェアにより制御された機器やそれらをつなぐシステムは様々な場面に利用され、日常生活や社会経済に欠かせないものとなっている。
例として、自動車の例を見てみよう。6 ページの図１に示すように、現在は多くのエレクトロニクス化された機能部品やコンピュータなどから構成されている。

5

図 １ 自動車とエレクトロニクス
出典：「車載システム開発現場を取り巻くグローバルな課題背景と対応の動向、取り組み」、2015年11月、IPA/SEC

図２に示すように、自動車の開発の歴史をたどると、最初は機能部品を組み立てて作られていたが、次に電子化の波が押し寄せ、機能部品とそれを支援す
るエレクトロニクスが融合したメカトロニクスに移行した。さらに、多くのソフトウェ
アにより機能を実現する仕組みに移行し、複数の機能部品が結合されて動くよ
うになった。これらの機能数の増加は、ソフトウェア指向への移行により実現できていることが分かる。

図 ２ 車両､ECU 開発のソフトウェア指向への移行
出典：「車載システム開発現場を取り巻くグローバルな課題背景と対応の動向、取り組み」、2015年11月、IPA/SEC

6

機能の拡張がソフトウェア規模の増大により実現されているという状況は、
自動車以外の組込みソフトウェアにおいても見られている。
総じて、組込みソフトウェア開発では、機能部品からメカトロニクス及びそれを結びつけるソフトウェアによって機能を拡張させてきた。
このように、先進技術の進歩を背景に、IoT 時代が到来し、製品／サービスの開発を取り巻く環境に変化が起きている。例えば、農業や医療・介護など、様々な分野のシステム開発で、センサー・機器で取得したデータを、インターネット等を介して収集し、多くの新サービス創出につなげるような取組みが始まっている。
また、これまで想定していなかった異業種を結ぶ新ビジネスでは、異なる分野のシステム同士がつながり、従来の単一分野の専門性だけでは対応できなくな
るような変化が生じている。

１−２ 課題
前述した環境変化の下、種々の課題が顕在化し始めている。主なものとして、以下の事項が挙げられる。
（1）想定外のモノ・コトのつながり（2）隣接する分野の事業への進出によるルール変化（3）新サービスが生まれることによるビジネス環境のリスク（4）考慮すべき条件の拡大
以下に、その内容について述べる。

（１）

想定外のモノ・コトのつながり

昨今の IoT の進展や製品／サービスの複雑化のため、事業として考慮しなければならない範囲や開発対象となる製品／サービスの範囲が拡大している。
場合によっては、基準や規制が無い状況で開発をする必要があり、システムの開発とあわせて基準や規制も作っていかなくてはならなくなってきている。
7

その例として、自動車におけるつながりを示す。近年、自動車においても、通信機能を持つことにより、自動車のネットワーク化が進んでいる。ネットワークとつながる自動車はコネクテッドカーと呼ばれ、従来のクローズドな製品で考慮していた要件に加え、ネットワークとの接続に起因する安全性やセキュリティなどの種々の要件を考慮し、開発と並行して、新たな基準や規制を作成する必要が出てきた。
また、別の製品／サービスの事例として、スマートフォンによる家庭内の家電製品のコントロールを示す。
例えば、ある一定の条件の下で、エアコン、風呂、家の施錠などが、家庭の外からスマートフォンを通して制御できるようになった。このことはユーザに大きな利便をもたらす一方、操作者の誤操作による風呂の空焚き、及びエアコン温度の範囲外の設定など、人体への影響を与えかねないことが考えられる。そこ
で、こうした事象の防止や、なりすましによる他者からの悪意による制御、情報漏えいなどへの防止対策設定など、今までは検討していなかった事項や基準や規制への対応が迫られている。

（２）

隣接する分野の事業への進出によるルール変化

隣接する分野への進出によって情報セキュリティへの対応や規制への対応など、単一の分野でのルールが通用しなくなることがある。
その例として、健康増進システムの医療分野への進出を示す。
これまでは、個人の健康増進に利用するための情報を体重計、血圧計などの据置き型計測機器を用いて収集し、PC 等で表示・提供することができる、いわゆる健康増進システムが開発されてきた。さらに、近年は人体に装着して、歩数、運動量等を計測するウェアラブル機器の進歩で、それらを統合して管理することも可能になった。
上記は、主に健康な個人に対しサービスを提供するものであるが、現在は糖尿病患者などの生活習慣病患者の重病化を防止するために、このサービスで8

得られる情報を医療機関へ提供して、医師の管理下で患者に指導を行う動きが始まっている。
この際には、健康増進システム側では、患者の本人性の確認、計測データの精度、接続のためのデータフォーマット、情報セキュリティの管理など、今まで考慮していなかった事項への対応が必要となる。

（３）

新サービスが生まれることによるビジネス環境のリスク

新しいサービスの台頭による既存ビジネスの変化と、場合によってはその衰退がリスクとなる。
シェアリングエコノミーに代表される、IoT をベースとした新サービスが生まれることにより、その製品／サービスが置かれる環境（コンテクスト）が大きく変化
し、その結果既存のビジネスが衰退していくリスクが生じている。
例えば、タクシー業界は参入障壁が高く、規制に縛られつつも規制に守られてきた。ところが、米国で、Uber や Lyft1 などが、タクシーよりも軽い規制で、もっと便利で柔軟性のあるライドシェアリングと呼ばれる交通サービスを合法的に提供できることが認められた。その結果、タクシー業界はライドシェアリングに利用者ばかりかドライバーまで奪われ、存在感がどんどん薄くなっている。
また、そこで使用される情報インフラも、これまでの自社管理下の「設備（車）を顧客（利用者）」に提供する B to C モデルのためのインフラから、「顧客（利用者）と顧客（ドライバー）」の仲介という C to C モデルのためのインフラに変化する必要がある。その際、SNS との連携、GPS との連動による位置確認の提供、クラウド上の課金などのオープンな技術に対する柔軟な対応も求められる。さらにそれは、情報インフラとしての基準を満たすだけでなく、交通サービスとしての規制を受けることも考慮する必要が出てくる。
そのほか、タクシー業界だけではなく、レンタカーやパーキングやその他の既1

スマートフォンや GPS などの ICT を活用し、移動ニーズのある利用者とドライバーをマッチングさせるサービス

9存業界、加えて、空き部屋や不動産の貸借をマッチングするルームシェアなどにも大きな変化が起きている。

（４）

考慮すべき条件の拡大

考慮すべき条件の拡大（物理的、時間的）により、開発の遅延や開発量の増
大、コストの増大などの問題を招く。
① 物理的な拡大
IoT 時代には、製品／サービスは、個々に独立した機能やサービスを提供するだけでなく、それらがつながって新たな製品／サービスとなる。これ
に伴って、製品／サービスを構成するソフトウェアはより大規模・複雑になってきている（図３）。

図 ３ ソフトウェア開発の複雑化
出典： 「情報システムの巨大化・複雑化とソフトウェア工学の役割」（IPA/SEC）、2006 年 6 月② 時間的拡大開発が進むにつれ、要求仕様、動作環境などの諸条件が変化する場合がある。例えば、ソフトウェア開発では、想定するユースケースに基づき要件を定義し、仕様に落とし込んでソフトウェアを開発しているが、開発が進むにつれ要件（動作環境等）が変わっていくこと、さらに使っているうちに10

環境が変わっていくことを考慮しなければならないケースが多く見受けられる。

１−３ 新しいアプローチの必要性
１-２で説明したように IoT 時代には多くの課題がある。例えば複数の専門分
野にまたがる製品／サービスの開発においては、従来の単一の専門分野の知識だけでは対応しきれなくなっている。このように、IoT 時代の課題は、既存の手法やアプローチでは解決が難しい。そこで、課題解決のためには新たなアプ
ローチの導入が必要である。
その新たなアプローチとして有効と考えられているものとして注目されているのが「システムズエンジニアリング」である。それについては第２章で説明する。

11

第２章 新たなアプローチ 〜システムズエンジニアリング

本章では、システムズエンジニアリングとは何かを説明するとともに、新たなアプローチとしてのシステムズエンジニアリングの重要な考え方／やるべ
きことの例として、４つのポイントに絞り説明する。
２−１

システムズエンジニアリングとは２−２システムズエンジニアリングの４つのポイント（１）

目的指向と全体俯瞰

（２）

多様な専門分野を統合（３）

抽象化・モデル化（４）

反復による発見と進化反復による発見と進化

２−１ システムズエンジニアリングとは
JCOSE（Japan Council on Systems Engineering）は、システムズエンジ
ニアリングの定義を「システムを成功させるための複数の専門分野にまたがるアプローチと手段である」としている。ここでいう「システム」は、コンピュータシス
テムにとどまらず、機械、電気機器、人間系（操作者）、環境など広い意味を持っている。一般的な認識とは必ずしも一致しない可能性があることを認識されたい。
別の説明を加えれば、システムズエンジニアリングは、航空・宇宙領域で確立した企画・開発のアプローチを汎用的に体系化したものである。ソフトウェア
システムやハードウェアシステムだけでなく、新規事業の開発、社会システムの設計など、様々な領域に適用可能である。
システムズエンジニアリングの効能としては、以下がある。
・ 本来の目的を明確化し、より高い視点や幅広い知見を取りまとめてアプロ

12

ーチする方法なので、新たなビジネスチャンスの把握やリスクの明確化が可能である。
 関係者が共通的に理解できるような概念整理を行い、繰り返しブラッシュアップすることにより、環境変化に耐えうる、よりよい製品／サービスを生み出すことができる。

２−２

システムズエンジニアリングの４つのポイント

ここでは、システムズエンジニアリングの特徴的なポイントを４つに絞って説
明する。

（１）

目的指向と全体俯瞰

システムの企画・開発においては、限られた経営資源（ヒト、モノ、カネ）でゴールに到達することが必要である。また、システムをライフサイクルという時間的視点や、コンテクスト（システムを取り巻く環境）などの空間的視点から俯瞰することが必要である。
そのために、システムズエンジニアリングでは以下のようなアプローチを行う。
‘① 目的指向の考え方によるアプローチ‘② 全体俯瞰の考え方によるアプローチ① 目的指向の考え方によるアプローチ
解決策を考える前に本来の目的を明確に定義し、常に目的を意識しながら考えるアプローチを指す。
例えば、文書管理システムを企画・開発しようとするとき、目的は文書管理業務の効率化であるにもかかわらず、デジタル化のみに焦点を当てて考えてしまうことがある。本来は、業務効率の改善目的なので、操作者の13

ワークフローに着目し、人の作業とデジタル化の範囲を調和させた業務効率の改善にむけた全体最適を考える必要がある。

② 全体俯瞰の考え方によるアプローチ
視点と視野を変えながら全体を俯瞰して対象を捉えるアプローチを指す。
視点としては、時間的視点、空間的視点、意味的視点がある。
まず、時間的視点での俯瞰とは、例えば製品開発の初期から利用終了
後の廃棄までのライフサイクル全体を考えることである。その中には、置換え対象となる製品の世代交代までを円滑に行うことを含んでいる。
次に、空間的視点での俯瞰とは、コンテクスト（システムを取り巻く環境）のすべての関係性を捉えた上で検討を進めることである。ライフサイクルのステージごとに、コンテクスト（システムを取り巻く環境）が変わることも考慮しておかなければならない。
さらに、意味的視点での俯瞰とは、ユーザはどういう目的でその製品／
サービスを必要とするのか、どのように使うのか、どの機能を必要とするのか、何を用いて機能を実現するのかなどといった観点で検討することを意味する。
実際に製品／サービスを企画・開発する際には、まず「対象とするもの」の課題を認識し、目的を明確にする。次に、時間的視点、空間的視点、意味的視点に沿って、ライフサイクルに着目した考察、課題に関連するコンテクスト（文脈、背景情報、状況）の考察、及びステップを踏んだ考察を付加していく。最終的に、最初の課題の解決策をビジネスに貢献するものとして構築していく。

（２）

多様な専門分野を統合

IoT 時代の製品／サービスは、大規模化、複雑化が進んでいるため、前項でシステムの全体的俯瞰を進めることが重要であると述べた。この全体俯瞰
14

を行うと、多様な専門分野の存在が明らかになり、それらを総合的に最適化することが必要になってくる。そのために、システムズエンジニアリングでは、多様な専門分野の知見を統合し、全体としての特性や特徴を実現する設計を行う。
すなわち、システムズエンジニリングにおいては、特定の専門分野を深める
だけでは達成できない高い付加価値を実現すべく、多様な専門分野に関わる知見を統合した全体設計を行う。つまり、単に複数の専門知識を束ねるのではなく、それぞれの考え、意見を取りまとめて最適化することにより新たなシステムを作ることである。

（３）

抽象化・モデル化

IoT 時代の製品／サービスは、大規模、複雑化が進んでいるため、その企画・開発には多様な専門分野の関係者が関与する。その時、前述したとおり、
俯瞰的に共通理解、本質理解が必要になってくる。そのために、システムズエ
ンジニアリングでは、概念やシステムを抽象化・モデル化するアプローチを行う場合が多い。
抽象化・モデル化とは、対象（概念やシステム）から注目すべき要素を切り出し、その仕組みを単純化して捉えること、およびその単純化した構造で表現することである。対象を俯瞰的に捉えるためには、抽象度をあげることが必要となる。
その実施に際しては、抽象化の視点を柔軟に設定し、目的のために必要となる複数の適切な視点から対象を構造化することが重要である。それによって構造的に整理されたシステムに関する様々な情報のネットワーク（相互関係）が得られる。さらにその関係をわかりやすい形でモデルとして可視化することが重要である。
効能として、異なる関係者間の共通理解を促進することができる。さらに、精度が高く自由度の大きいトレーサビリティの実現、それによる各種エンジニ
15

アリング活動との有機的なつながりの実現なども期待できる。加えて、モデル化により各種検討を機械可読とし自動化につなげることで開発効率を改善で
きる。

（４）

反復による発見と進化システム開発の初期の段階では、目的とする製品仕様を明確に把握して、確定することが難しい事例が出てきている。例えば、第３章で紹介する、次世代
静脈注入ポンプの開発では、使用者のニーズを要求確認段階で盛り込むことが必要であった。しかし、過去の機器使用経験、医療スキルが十分でない使用者にとっては、その段階で明確なニーズを申し出ることは困難であった。このよ
うな場合に、避けられない「初期の不確定要素」への戦略的な対応を図ることが必要である。
システムズエンジニアリングでは、適切に再評価とフィードバックを反復し、新たな解決方法を発見し段階的に明確化・進化させることを行う。このことにより、想定していた環境のその後の変化への柔軟で迅速な対応、「初期の不確定要素」への戦略的な対応ができる。
反復は、全体プロセスを繰り返すことだけではなく、途中段階の部分プロセスにおいて、システム全体としての目的達成に寄与できるかを都度評価し、必要ならば反復的に設計、評価を繰り返していくことを示している。具体的には、開発プロセス全体を通して、想定する使用者と協働して、仮想実験やプロトタイピ
ングを駆使し、評価、確認を繰り返し実行する方法がある。

16

コラム:IoT とシステムズエンジニアリングについて
システムズエンジニアリングの取組みが先行している海外のシステムズエン
ジニアリングの専門家の言葉を紹介する。
●ロッキード・マーティン社 前会長兼 CEO、元米国大統領科学技術諮問委員会メンバー、Norman R. Augustine 氏
システム・エンジニアリングは、科学であると同時に芸術でもあるのです。
システム・エンジニアリングの本質は、複雑なプロジェクトに携わるほとんどの人がレンガの作り方は知っていても、プロジェクトを成功させるためには大聖堂の建築方法を知っている人が必要なのだということに尽きます。

●INCOSE フェロー、Hillary Sillitto 氏
現在のエンジニアリングは科学を置き去りにしています。私たちは特徴付けることも、分析する方法もわからない、さらにはその挙動を完全に予測することもできないシステムを構築しているのです。

●デロイト・コンサルティング社プリンシパル、Brian Meeker氏
最も成功している企業は、システム・エンジニアリングが企業文化に深く根付いているため、その重要性を理解しています。しかしこれは普通ではなく、特別な状態と言えるでしょう。ほとん
どの企業は、システム・エンジニアリングの原則に対応できるように自社のビジネス・モデルやプロセスを進化させていません。優秀なのはほんの一握りにすぎないのです。

出典：ダッソー・システムズ株式会社 公式ブログ（2016/02/26）

http://blogs.3ds.com/japan/mindblowing/

17

第３章 システムズエンジニアリングの有用性
本章では、システムズエンジニアリングに関する事例に基づく知見を以下のトピックスで説明し、有用であることを説明する。
３−１ QCD への効果
３−２ 有用性を示す事例

この章では調査報告などを引用して、システムズエンジニアリングの有用性を示す。まず、INCOSE （International Council on Systems Engineering）の報告に基づき QCD への効果を紹介し、次に、具体的な事例に基づき、第２章で紹介した４つのポイントがどのように活用されているかを含めて、その有効
性を示す。

３−１

QCD への効果

INCOSE の報告では、過去の事例の統計によれば、システムズエンジニアリ
ングを最適に適用した場合と、適用していない場合を比較すると、適用していない場合の納期、コストそれぞれが、1.8 倍、1.4 倍程度になっている（１９ページ
図４、図５参照）。
なお、システムズエンジニアリングは、過大に投資しても効果が増えるわけではなく、かえってプロジェクト全体の納期遅延やコストの増加をもたらすことも示されている。システムズエンジニアリングを有効化する最適な投資規模は、全体投資額のおよそ 15%をシステムズエンジニアリングのコストに投入した場合であるという結果が報告されている。

18

システムズエンジニアリングを適用しなかった場合

システムズエンジニアリング
を最適に適用した場合

図 ４ システムズエンジニアリングの投入コストとスケジュールの相関システムズエンジニアリングを適用しなかった場合

システムズエンジニアリング
を最適に適用した場合

図 ５ システムズエンジニアリングの投入コストとプロジェクトコストの相関
図４、図５ 出典：Ｅｒｉｃ Ｈｏｎｏｕｒ博士の研究成果の引用に加筆
Honour, EC, Systems Engineering Return on Investment, PhD thesis, Univ South Australia 2013

19

３−２

有用性を示す事例

本項で紹介するのは、システムズエンジニアリングの４つのポイントである「目的指向と全体俯瞰」「多様な専門分野を統合」「抽象化・モデル化」「反復による発見と進化」を具現化した事例である。どの事例も一定の効果を達成しており、今後のさらなる活用が期待されるものである。

20

目的指向と全体俯瞰

事例１：鉄道・列車制御システムの更新とサービス継続
SEC Journal 35 号（IPA）「アシュアランス技術を用いた鉄道信号の革新」より

山手・京浜東北線のラッシュ時の混雑（上野・御徒町間で約 240%）緩和の社会的要請が強まっていたのに対し、運転本数を増加できる新しい列車制御シス
テムを 2008 年までに導入した事例である。この際に、旧システムから新システ
ムへのスムーズな移行が重要な要件であった。

◆開発における課題
現行システムに影響しない新システムの検証方法や、運行を維持しながらの新システムへの迅速な切り替えを行えることが必要であった。
◆対策
開発当初から全工程の課題を見据え（時間軸の俯瞰）、システムの切り替
え・移行についても設計時より焦点をあてて方式の設計を行い、旧システム
で運転中に新システムの電文の送信、チェックが可能な方式を採用した。システムのライフサイクルを俯瞰して妥当な対策を施した事例である。
◆効果
テスト、及び切替えを短時間でできるシステムを実現した。これにより、運行
サービスに影響することなくシステム移行を実践することができた。

21

多様な専門分野を統合

事例２：多様な要求に同時に応える自動車の開発
SEC Journal29 号（ＩＰＡ）「SKYACTIV テクノロジーの誕生を支えたモデルベース開発」より

乗り心地、運転の楽しさ、安全、燃費、環境性能等を高度な次元で満足させる自動車の開発の事例である。

◆開発における課題
多様な要求を「同時に」実現するための機能開発として、多様な要素についての高度な技術革新が必要であった。
◆対策
エンジン、トランスミッション、ボディ、シャーシに至るまで、車に搭載するすべての技術と、それらを総合する技術の革新を行った。その中核となったのが、それぞれのメカニズムの解明など技術的研究を深めるとともに、それらの結果を可視化し、予測などにも使用できるモデルとして確立したことであった。
これにより共通理解を促進し、シミュレーション技術も総合して全体最適を図
る設計につながった。
◆効果
低燃費で安定した走りを実現する製品群の開発に成功した。

22

多様な専門分野を統合

事例３：国境にまたがる世界最大の複合構造物の建設
Systems Engineering Handbook 4th Edition, Copyright © 2015 by John Wiley & Sons, Inc.
All rights reserved

デ ン マ ー ク ・ ス ウ ェ ー デ ン 国 境 に ま た が る 車 道 と鉄 道 を 備 え た 斜 張 橋（7.85km）であり、世界最大の複合構造物であるオーレスン橋を建設した事例である。北欧スウェーデンとヨーロッパ大陸が陸路でつながることになり、経済効果と文化交流の面で大きな期待を担ったプロジェクトとして合弁会社を立ち上げて取り組まれた。

◆開発における課題
・多岐にわたる専門領域: 各種構築技術（例：橋梁土木、道路交通、鉄道、船舶
通行、環境保全など）

・両国の規制、基準の違い、鉄道方式の違い等（例：右側・左側通行、電力供給
方式の違い）

・環境問題を含む込み入った要求の発生（例：海流・土砂と生物多様性関係）◆対策・関連専門家／利害関係者との検討、合意形成活動の積重ね (知見の集約と合意形成をとりながら推進するマネジメント活動)
・規制・基準を満たす水準の見極め→最新技法活用を含む詳細なリスク分析。技
術検討を重ね、安全に通行帯交換、電力供給方式切替の技術的実現法発見

・緊密な環境対策のための体制作りと対策の推進◆効果
多岐にわたる開発・運用にも関わらず、深刻な意見対立や大きなトラブルを発生させずに建設に成功した。

23

目的指向と全体俯瞰

抽象化・モデル化

事例４：発展途上国の実情に合わせた保育器の開発
SEBoK(Guide to the Systems Engineering Body of Knowledge)より

乳児死亡数が年間 400 万人に達している途上国に向け、より多くの生命を救うべく、新生児向けの保育器を普及させることを目的に開発が行われた事例である。

◆開発における課題
・先進国で実績のある製品を転用して使用を開始した。しかし、自然環境、インフラ環境の関係で故障が多発した上に、部品が入手できないことから修理網も整備されず、普及に失敗していた。
◆対策
・保育器の本来の目的に立ち返り、新たな製品企画から取り組んだ（目的指向と全体俯瞰）。
・抽象度を上げた分析により本質的な要件を関係者で共有、物理的条件の前提を設けずに実現策を検討（機能と物理の分離）により解決策を見出した。
・新生児を 1 週間暖める対策で約 180 万人を救えることが判明した。暖める
機能と保守性に絞って新規開発した。
・「暖める機能」と「保守可能性」とを両立する「自動車の部品を使用する」という解決策を発見した。
◆効果
途上国で入手できる部品で、保守もできる「暖める機能をもった保育器」を新たに開発して普及を開始することができた。

24

反復による発見と進化

事例５：次世代静脈注入ポンプの開発
SEBoK(Guide to the Systems Engineering Body of Knowledge)より注射薬、栄養液、血液等をプログラムした内容に従って患者の静脈などへ注入する革新的な装置を開発した事例である。それまでの、医療過誤事故が多い背景であった医療機器の難しい操作性を改善し、操作性と患者安全性の観点の機能を強化した装置として企画・開発された。

◆開発における課題
・使用者のニーズを要求確認段階で盛り込むことが必要である。しかし、過去の機器使用経験、医療スキルが十分でない使用者にとっては、その段階で明確なニーズを申し出ることは困難であった。
◆対策・開発プロセス全体を通して、想定する使用者と協働した。具体的には仮想実験やプロトタイピングを駆使し、評価、確認を繰り返す方法で推進した。
具体的には、初期は潜在ニーズの抽出のためのインタビューと病院内での行動観察を行い、実験室段階でのインタビューも含んだ評価と使用感テスト
を交えて開発を進め、最終段階に向け、コンピュータシミュレータでの機能の最終操作性についてのユーザ最終確認を行った。
◆効果・製品展開後、サポート上の大きな問題は起きておらず、満足度の高い結果を得られている。
・最低限の教育を受けた本機初体験の看護師に関し 99.66％が問題なく使用できるという結果が報告されている。

25

第 4 章 システムズエンジニアリングの導入の取組み
本章では、システムズエンジニアリングの導入に向けた取組みについて説明する。特に、第２章で説明した４つのポイントを実際のシステムズエンジニ
アリングの活動に活かすための考え方を説明する。
４−１

システムズエンジニアリングの４つの主たる活動（１）

システム設計（２）

インテグレーション

（３）

評価・解析

（４）

システムズエンジニアリング管理

４−２

主たる活動において４つのポイントをどう活かすか（１）

システム設計（２）

インテグレーション

（３）

評価・解析

（４）

システムズエンジニアリング管理

４−３

４−１

参考情報（調査報告、一般情報）（１）

システムズエンジニアリングの遂行にあたっての推奨事項（２）

効果的なシステムズエンジニアリング導入のための考慮点

システムズエンジニアリングの４つの主たる活動

システムズエンジニアリングの活動は、２７ページの図６に示すように、①システム設計 ②インテグレーション ③評価・解析 ④システムズエンジニアリン
グ管理に大別できる。
各活動は、システム開発の各段階で行われる。例えばコンセプトの設計段階において、仮説検証のためのプロトタイプ開発を行うとすれば、そのプロトタイプ

26

開発の中にも前述の４つの活動が含まれる。なお、図６は作業の順番を定義しているものではなく、構成する４つの活動の考え方を表したものである。これはIPA/SEC が 2013 年に改訂した｢共通フレーム 2013｣ において設計とテストの対応関係を表した「V 字」とは本質的に異なるものである。

システム要求システム

評価・解析
システム試験計画

システム
設計
サブシステム
要求

システム
試験

サブシステム試験計画

サブシステム設計

コンポーネント要求

コンポーネント設計

コンポーネント
試験計画

システム設計サブシステムサブシステム
試験
コンポーネントコンポーネント
試験

インテグレーション
製造

システムズエンジニアリング管理
システムズエンジニアリング管理

図 ６ システムズエンジニアリングの４つの活動
出典： システムズエンジニアリング入門～IoT 時代の価値実現に必須となるアプローチ～SEC 先端入門ゼミ（慶應義塾大学大学院白坂教授）を基に作成

具体的な実行にあたっては、図６に示した４つの活動の考え方をよく理解した上で、取り組むことが重要である。
システムズエンジニアリングの実践を通して得られた知見を知識体系として整理・統合したものとして INCOSE が発行した SEBoK（Systems Engineering
Body of Knowledge）があり、上記に関する考え方とその際の進め方が、個別の事例などを使い紹介されている。以下にこの考え方に相当する SEBoK の該
当箇所を紹介し内容を概説する。

27

（１）

システム設計ステークホルダーの要求を分析し、全体の整合を考慮しつつ、抜け漏れがない形にすることで、要求を定義する。次に、その定義された要求を実現するために、アーキテクチャ設計を実施する。具体的には、複数の視点（viewpoint）からシステムを見て、それぞれの視点から見えるもの（view）における要素と要素間の関係を定義し、異なる「見えるもの（view）間の関係性」を定義することで、サブシステムへの要求を導出する。この活動は２７ページ図６のモデルの左側として実施される。システム設計の実施時には、図６のモデルの右側で実施されるインテグレーション（試験を含む）のことを考慮して行う。
SEBoK では以下に述べる 2 つの活動について説明されている。
【Concept Definition（概念定義）】
ユースケースの明確化、ビジネスケースの明確化、主要なステークホル
ダーとその要求事項の確定、ステークホルダー間の要求の調整等を行うことである。その検討に際しては、既存製品の変更あるいは新製品の開発がそれにかけるコストに見合うものか関係者間での合意が必要である。
【System Definition（システムの定義）】
システムアーキテクチャの構築、システム要求の程度に関する合意、システムレベルのライフサイクル計画、システムレベルの分析等を行うことである。ここでは、ライフライクルを通したコストの妥当性を検証できることが重要である。

（２）

インテグレーション

インテグレーションの活動においては、実装されたシステム要素（製造成果物、調達物）の提供を受け、それを意図したシステムに組み上げ、その過程で、
verification & validation （V&V＝検証と妥当性確認）も実施する。V&V はインテグレーション活動とは別の活動であるが、相互に密接に関連した活動である。
V&V については、（３）で詳細に記述する。
28

なお、SEBoK では以下のように記載している。
【System Integration（システム統合）】
実装された要素を段階的、反復的に組み上げていくことにより、サブシス
テムあるいは全体システムを構成していくことである。

（３）

評価・解析

エンジニアリング活動における解析及び検証（verification）、妥当性確認（validation）などの活動である。図６の V モデルの左側では、システム設計をシ
ミュレーションで評価したり、代替案をトレードオフ分析したりすることなどがこれにあたる。また、図６の V モデルの右側では、構築されたサブシステムやインテ
グレーションされたシステムを試験することがこれにあたる。
SEBoK では、特に以下の 2 つの活動について詳しく述べている。
【System Verification（検証）】
システムが正しく作られているかを確認する活動である。例えば、システ
ム要求通りに設計仕様が作られているか、およびシステムを構成する要素が設計仕様通りに動作するかを確認する活動がこれにあたる。
【System Validation（妥当性確認）】
正しいシステムが作られているかを確認する活動である。例えば、構築するシステムが、システム全体の目的に照らして妥当かどうかを確認する活動である。

図６で示す V モデルの右側で実施される試験は、対応するレベルの V モデ
ルの左側の設計に従って実施される。また、V モデルの右側で実施される試験をしやすくするために、左側の設計を工夫することを行う。このように V モデル
は、左側と右側は対応させて考えることを示している。

29

（４）

システムズエンジニアリング管理

QCD を満たすために、ライフサイクルを通じて、各種活動の計画・実施・評価を行う活動がこれにあたる。この過程において、どのような範囲で４つの活動を何回適用するかを決めることも含む。
プロジェクト管理における「管理」と、システムズエンジニアリング管理における「管理」の違いはしばしば議論になるところであるが、その範囲の相違についての世界的な合意はない。自組織にあった形で、必要なシステムズエンジニア
リング管理の活動を行うことが重要である。

４−２

主たる活動において４つのポイントをどう活かすか

本項では、第２章で示したシステムズエンジニアリングの４つのポイントが前項で説明した４つの活動の中でどのように活かされるべきなのかを記載する。

（１）

システム設計① 目的指向と全体俯瞰
システムは何らかの目的を持って開発される。開発においては、常にその目的を念頭におき、この目的に照らし合わせて開発・評価されることが必要である。
システム設計においては、まずステークホルダーの要求を分析し、全体の整合を考慮しつつ、抜け漏れがない形にすることで、要求を定義する。その際、本来の目的を明らかにすることが重要であり、たとえばそのために、重要なステー
クホルダーを識別し、そのニーズに基づいて何を実現すべきかを総合的に意見集約することが必要である。
また、対象システムの範疇に限られた制約条件や要求だけに着目せず、その対象システムを取り巻く環境や関係者を含めた視点から全体を俯瞰し、設計を行うことが必要である。さらに、システムのライフサイクル全般を考慮して、運用や廃棄までを考慮した条件を検討し、設計を行うことが必要である。
30

② 多様な専門分野を統合定義された要求を実現する設計を行うためには、多様な専門家を束ねることが必要となる。多様な専門家の意見・知見を統合して全体最適を満たすシステ
ム設計を進めることが重要である。例えば、個別技術的専門家だけでなく、環境分析の専門家、法律の専門家、経理の専門家などの意見を聞くことが必要である。

③ 抽象化・モデル化
システム設計では、全体を俯瞰的にとらえ、複数の専門家を統合して行うことが必要であるので、抽象化・モデル化が重要である。
抽象化を行うとは、物事をシンプルに捉えるために概念定義を行うことである。
システム設計を行うときには、俯瞰的に対象を捉えることが重要であるが、細部をみていては、全体を捉えることは難しい。抽象度をあげることで、漏れなく全体を俯瞰できるようになる。ただし、どのような方向に抽象化するかは、目的にあった方向を選ぶ必要がある。
モデル化とは、適切な抽象度を設定し、本質を抽出することである。目的に対して、必要な情報（含む、関係性）を漏れなく、適切な粒度に単純化することをモデル化という。
多くのステークホルダー間の調整や、異なる専門家をまとめていくことが必要になる。関係者間の共通の理解を得るため、抽象化・モデル化を行って、対象をよりわかりやすく整理することが有効である。
ただし、モデルにすべての要素を反映できるとは限らないので、重要な評価
ファクターが欠落しないように留意することが必要である。

④ 反復による発見と進化
反復は、システム設計、インテグレーション、評価・解析、システムズエンジニ
31アリング管理を繰り返すことを通じて、新たな気づきの発見と、それによりシス
テムの進化を行うことである。
これにより、システム設計自体が変わっていくこととなる。また、システム設計
内でも、要求定義とシステム定義を繰り返すことで発見・進化を行うこともある。

（２）

インテグレーション
インテグレーションの活動は、４－１で説明したように、実装されたシステム要素（製造成果物、調達物）の提供を受け、それを意図したシステムに組み上げることである。
① 目的指向と全体俯瞰
目的指向と全体俯瞰については、他の３つの活動の項を参照。

② 多様な専門分野を統合
インテグレーション活動においても、複数の専門家の知見を統合して、その手順等を検討する必要がある。この過程において、V&V の実施も統合的に考えることが必要である。

③ 抽象化・モデル化
抽象化・モデル化については、他の３つの活動の項を参照。

④ 反復による発見と進化
反復は、システム設計、インテグレーション、評価・解析、システムズエンジ
ニアリング管理を繰り返すことを通じて、新たな気づきの発見と、それによりシステムの進化を行うことであるため、インテグレーション活動も影響をうける。

（３）

評価・解析

① 目的指向と全体俯瞰
32開発したシステムが、設計仕様のみならず目的に合致していることを評価・解析することが必要である。
検証においては、システムが正しく作られていることを確認することが必要である。例えば、設計仕様がシステム要求を満たしているかを確認することはこれにあたる。具体的には、トレーサビリティを確認することや、設計仕様のレビ
ューを通じて、システム要求が正しく設計仕様に落とし込まれていることを確認することなどがこれにあたる。
また、構成要素が設計仕様を満たしていることを確認することも検証として考えられる。あるいは、要求仕様が試験されているか、設計仕様が試験されているかを確認することも検証にあたる。
妥当性確認においては、目的に合致しているかを確認する作業を行う。そこ
では、対象システムが想定される環境、協働する人間とともに所定の目的を達成できるかを、想定されたユースケースで確認することなどが考えられる。

② 多様な専門分野を統合開発したシステムの評価・解析においては、個別技術面からだけでなく、すべての関連する側面において統合的に行われる必要がある。単一的技術的側面で問題がなくても、他の側面で問題が発生するようでは、システムは受け入れられることができない。例えば、個別技術だけでなく、関連する技術、環境分析、法律などの面でも評価・解析をする必要があることも考えられる。

③ 抽象化・モデル化
システム設計で用いたモデルは理解の共通化が主な目的であった。一般に、システム設計を行う担当者と評価・解析を行う担当者が異なる場合が多いと想定される。その場合、担当者間の共通理解に抽象化・モデル化は有効である。
また、抽象化・モデル化は設計上の課題抽出にも用いることができる。具体的には、実際のシステムを完成させる前のシステム設計の段階でも評価・解析
33

ができるので、手戻り時のコスト削減が可能となる。
例えば、モックアップや試作品によるデザイン評価／ユーザビリティ評価、
3D・CAD などによる機構部品相互の干渉評価、シミュレーションによる性能確認などが相当する。

④ 反復による発見と進化
前述のとおり、反復は、システム設計、インテグレーション、評価・解析、シス
テムズエンジニアリング管理を繰り返すことを通じて、新たな気づきの発見と、それによりシステムの進化を行うことである。

（４）

システムズエンジニアリング管理① 目的指向と全体俯瞰
システム開発を俯瞰的に捉えて管理を実施することは大変重要な活動である。特に技術者は、自分の技術に注目してしまう。システムズエンジニアリング
管理を実施する場合には、目的指向と全体俯瞰をおこない、個別技術に偏ることがないよう、目的を達成するための最適なポートフォリオとなるようマネジメントを実施することが必要である。これらを行うために、Systems Engineering
Management Plan (SEMP＝システムズエンジニアリング管理プラン）を作成し、ライフサイクルに渡ってマネジメントを行うこともある。

② 多様な専門分野を統合
多様な分野の専門家の意見が適切に集約できるような機会を設定し、適切にマネジメントを行うことが重要である。

③ 抽象化・モデル化
抽象化・モデル化は、その目的に応じて何をどのように抽象化・モデル化し、どのように活用するかによって変わってくる。抽象化・モデル化したものは、シス
34

テムのライフサイクルを通じて活用することが可能である。例えば、開発を効率化するために抽象化・モデル化するのであれば、それにあった情報を抽象化・モデル化し、その目的にあわせて活用していくことが重要である。やみくもに抽象化・モデル化をしても、そのメリットを享受することは難しいので、プロジェクトの開始段階に検討しておく必要がある。

④ 反復による発見と進化
反復的な取組みを行うためには、反復による再設計を見込んだ計画をしておくことが必要である。反復には、計画可能なものと、計画ができないものがある。
例えば Technology Readiness Level （ TRL ＝技術成熟度）を活用した反復は、計画が可能なものである。計画時に、どのように反復することで、どのように技術の成熟度をあげていくかを織り込むことができる。

４−３
（１）

補足（調査報告、一般情報）システムズエンジニアリングの導入にあたっての推奨事項

システムズエンジニアリングをこれから導入する企業への参考情報として、
先進的欧州企業におけるシステムズエンジニアリング事例の調査結果から、これから取り組む企業への推奨事項を紹介する。
システムズエンジニアリングの導入にあたっては、組織改革から始め、技術開発につなげる必要があるという観点から、組織の在り方（表１）、技術開発の進め方（表２）に分けて示す。

第４章の「４－１ システムズエンジニアリングの４つの主たる活動」 及び 「４－２ 主たる活動において４つのポイントをどう活かすか」 においては、システムズエンジニアリングについて SEBoK の主として Part3 の記載情報を抜粋して紹介した。なお、SEBoK の 2017 年 3 月
現在の最新版は V1.8 であり、INCOSE のホームページから無料でダウンロード可能である。

35

以下の表で、以下の活動報告において、調査結果の分析から得られた推奨事項を引用したものである。この説明においては、調査結果の事実などと合わせて推奨事項が記載されているため、本書への掲載にあたり、特に推奨事項
について下線で示している。
対象の活動報告は IPA/SEC が WEB 公開している以下の情報である。
『 「ドイツ・欧州企業における「システムズエンジニアリングの実践に関する調査・分析結果報告」および 「システムズエンジニアリング 実践課題とベスト
プラクティス」を公開 』 （2016 年 12 月 19 日公開）（https://www.ipa.go.jp/sec/reports/20161219.html）

36

表 1：推奨事項（組織の在り方）
項目

説明

１

組織改革戦
略

２

システムズエンジニアリン
グ能力

３

ソフトウェア
開発能力

企業の 80%が、システムズエンジニアリング実践の主要な課題は組織改革であると答えている。
どのような組織構造及びプロセスが最適かをオープンに考えることが重要である。特に、改革の動機付けと伝達を的確に行って、あらゆるステークホルダーをそのプロセスに取り込むことが重要である。
システムズエンジニアリングに関して内部トレーニングプロ
グラムを作成し、外部トレーニングプログラムを購入することが、ほとんどの組織で義務化されていた。
さらに、最新の開発情報を得たり知識・経験を共有したりするために、国内外のシステムズエンジニアリング関連のコンファレンスに参加し、各コミュニティの積極的なメンバになることを推奨する。
元々の業種がハードウェア開発寄りであるにも関わらず、企業の 85%以上が製品でソフトウェアが主要な役割を果たすと答え、また今後も伸びるとしている。企業が適切なソフトウェア開発能力を構築する、あるいは維持するには、製品がソフトウェアに依存する度合いと、企業の主要な IP（ Intellectual Property ： 知 的 財 産 ） 及 び USP （ Unique
Selling Proposition：独自の売り）がどこに存在するかによって異なる。
IP／USP がソフトウェアそのものに存在する場合、ソフトウ
ェア開発の分野で自らのリソースを構築する。
ソフトウェアが 1 つの目的を達成するための手段にすぎな
い場合は、外部のソフトウェアサプライヤー及びパートナーを管理するための能力を構築することは、少なくとも理にかなっている。

４

プロジェクト・ポートフォリオ管理

大規模組織が、改善のための着目点として挙げているため、プロジェクトのポートフォリオ全体の管理と、プロジェクト間の相互連関及び依存関係に特に重点を置くべきである。

37

表 2：推奨事項（技術開発の進め方）
項目

説明

１

システムズエンジニアリングの統合アプローチ

２システム要求開発

３

モデル駆動システム開発

４システムの検証と妥当性確認

５

仮想システム開発

６

統合されたシステムズエン
ジニアリングのツール・チェー
ン

新製品を市場投入するまでの時間が短縮されるのと同時に、製品の複雑化が進んでいるため、システムプラットフォー
ム及びシステム統合の場合に重要性が高い。
これには、関与するすべての専門分野間で十分に統合された、また調整されたアプローチが必要となる。
時間とともにシステム要求はますます複雑化し、製品の種類も増加している。システムレベルでどうやって要求を引き出し、あるいは開発し、長期にわたり系統立って管理するかについて検討する必要がある。
また、どう下位レベル（特にソフトウェア）の要求に落とし込むかも考えなくてはならない。
システムのモデル駆動開発が組織にとって重要な実践と見なされていることが確認された。
組織はシステム仕様のどの側面をモデリングするか、妥当な範囲でどんな言語とツールサポートを利用できるかを評価する必要がある。ここでのツール選定は、開発プロセスのツー
ル環境においてシームレスな統合を実現する上で適切なツールによって提供されるインタフェースの影響も受ける。
システムの検証と妥当性確認、ならびにテスト駆動開発のために適切な技法及び手法の確立を検討する必要がある。また、システムの検証と妥当性確認を、常にシステム要求と適切に関連付ける必要もある。
製品がますます複雑化し、複数の専門分野にわたる開発が進むにつれて、物理的に様々なシステム部品を構成することは難しくなり、コスト負担も非常に重くなる。そのため、モデルに基づく仮想システム開発を使用できるかどうかについて検討する必要がある。これは開発速度を上げるという点で改善が見込まれる。
組織においてはシステムズエンジニアリング実践のために多様なツールが使用されている。
ツール・チェーン統合は、主要な改善点である。このため、ツールの相互運用性と、ツール・チェーンをできるだけ統合することに特に重点を置くべきである。

38

（２）

効果的なシステムズエンジニアリング導入のための考慮点

カーネギーメロン大学ソフトウェア工学研究所は、CMMI の実践を通して、シ
ステムズエンジニアリングを効果的に実践できている場合とそうでない場合のケーススタディを 2008 年から継続しており、報告書をホームページ、カンファレ
ンスでの発表等を通して公表している。ここでは、そのうちの一つを紹介する。
詳細は、以下を参照されたい。
“The Business Case for Systems Engineering Study: Results of the
Systems Engineering Effectiveness Survey,” Joseph P. Elm, Dennis R.
Golderson, November 2012, Special Report CMU/SEI-2012-SR009,

https://resources.sei.cmu.edu/asset_files/SpecialReport/2012_003_00
1_34067.pdf

本報告書の最後の第７章サマリーにては、どのようなプロセスがどの程度有効かをサマリーすると共に、以下の記述で終えている。
システム開発者は、本報告書を用いて、システムズエンジニアリングを実践するにあたり、能力度の改善を如何に図るかを計画できる。

システム開発者は、本報告書の情報を用いて業界でのベンチマークが可
能になる。



システムズエンジニアとその管理者は、本報告書を用いて、システムズエ
ンジニアリングを実施するに際しての推測が可能になると共に、正当化できる。



発注者は、本報告書を用いて受注者の評価を計画できる。



プロジェクトの実施を通して、発注者は受注者からのデータ収集を可能に
する。

39

おわりに
システムズエンジニアリングの適用対象は、航空、宇宙だけにとどまらず、交通、ヘルスケア、農業など多くの分野に広がろうとしている。実際の適用に当たっては、本書で述べているポイント及び活動への活かし方に加え、事業領域特有の条件を考慮した（ドメインスペシフィックな）進め方も必要になる。その面にも配慮し、システムズエンジニアリングの活動を進められたい。

40

参考資料
第１章 製品／サービスの開発に関わる現状の課題
１−１ 環境の変化
IDC、国内 IoT 市場のテクノロジー別予測――IoT 基盤や分析ソフトが急成長、business network.jp 編集部 2016.05.18
http://businessnetwork.jp/Detail/tabid/65/artid/4555/Default.aspx

１−２ 課題「IoT(Internet of Things)の現状と展望」、みずほ産業調査 2015 No3https://www.mizuhobank.co.jp/corporate/bizinfo/industry/sangyou/pdf/
1051_all.pdf「車載システム開発現場を取り巻く グローバルな課題背景と対応の動向、取り組み」、2015 年 11 月、SEC セミナー資料。アイシン・コムクルーズ(株)鈴村延保氏
http://sec.ipa.go.jp/users/seminar/seminar_tokyo_20151126-04.pdf「情報システムの巨大化・複雑化とソフトウェア工学の役割」、鶴保 SEC 所
長プレゼンテーション、2006 年 6 月
https://www.ipsj.or.jp/10jigyo/seminar/2006/2006-1-4-tsuruho.pdf「平成 28 年度版情報通信白書」
http://www.soumu.go.jp/johotsusintokei/whitepaper/ja/h28/pdf/

第２章 新たなアプローチ～システムズエンジニアリング
２−１ システムズエンジニアリングとはJapan Council on Systems Engineering(JCOSE) ホームページ
https://www.jcose.org/home/se とは/２−２

システムズエンジニアリングの４つのポイント「経営者のためのシステムズエンジニアリング導入の薦め」～IoT 時代の製品やシステムを開発するための新たなアプローチ方法～

http://www.ipa.go.jp/sec/reports/20170329.html

コラム「気の遠くなるような複雑さ〜IoT の課題に取り組むために必要不可欠なシステムエンジニアリング〜」、ダッソー・システムズ、2016/02/26
http://blogs.3ds.com/japan/mindblowing/

41

第３章 システムズエンジニアリングの有用性
Systems Engineering Body of Knowledge (SEBoK)
http://sebokwiki.org/wiki/Download_SEBoK_PDF

Systems Engineering Return on Investment (SE-ROI)
http://www.hcode.com/seroi/
SEC Journal 29 号（IPA） 「SKYACTIV テクノロジーの誕生を支えたモデルベース開発」
https://www.ipa.go.jp/files/000002662.pdf
SEC Journal 35 号（IPA） 「アシュアランス技術を用いた鉄道信号の革新」
https://www.ipa.go.jp/files/000036644.pdf

第４章 システムズエンジニアリングの導入の取組み「システムズエンジニアリング入門～IoT 時代の価値実現に必須となるアプローチ～」(SEC 先端入門ゼミ）慶應義塾大学大学院白坂成功教授
http://www.ipa.go.jp/files/000056124.pdf

SEC Journal 48 号（IPA） 「システムズエンジニアリング概要～
VUCA 時代のシステムデザインアプローチ～」
https://www.ipa.go.jp/files/000057578.pdf「システムズエンジニアリングの基本的な考え方-初版」（宇宙航空研究開発機構）
https://ssl.tksc.jaxa.jp/isasse01/kanren/BDB/BDB06007BSEkiho
n.pdf「ドイツ・欧州企業におけるシステムズエンジニアリングの実践に関する調査・分析結果報告」、第２部: 回答者が直面したシステムズエ
ンジニアリング関連の課題 「3 本調査・分析で判明した重要項目」「4 推奨事項とその活動分野」、Fraunhofer IESE、2016
https://www.ipa.go.jp/sec/reports/20161219.html「The Business Case for Systems Engineering Study: Results of
the Systems Engineering Effectiveness Survey」 Joseph P. Elm,
Dennis R. Golderson, November 2012, Special Report CMU/SEI2012-SR009,
https://resources.sei.cmu.edu/asset_files/SpecialReport/2012_003_001_34067.pdf
42

全体
Systems Engineering Body of Knowledge (SEBoK)
http://sebokwiki.org/wiki/Download_SEBoK_PDF

Systems Engineering Handbook 4th Edition,
John Wiley & Sons, 2015 ISBN 978-1-118-99940-0

43

付録

システムズエンジニアリング適用チェックポイント

今後、複雑なシステムを対象とした製品／サービスの企画／開発に関しては、前述の内容に対応した観点が求められることになります。本チェックシートを利用いただ
くことで、システムズエンジニアリングの導入の切り口を見つけてください。

1. 目的に照らして俯瞰的視野で推進していますか？
□ 開発する対象物だけでなく、その外側にある影響要因（社会、業界などの環境、関わる人、他のシステムなど）から受ける影響を考慮していますか？
□ 開発する対象物だけでなく、使う人やつながるシステムなど外部に与える影響も考慮していますか？
□ 利用期間を通した保守体制の維持や、利用終了時の廃棄、さらには世代交代まで考慮していますか？

2. 多様な専門家を束ねる必要性を考えていますか？
□ 目的の達成のために必要となる専門分野とそれらの関係性を見極めて、必要な専門家をアサインして体制を組んでいますか？
□ マネジメントとして、専門分野間の境界のテクノロジー面の問題について、全体の問題として情報共有する仕組みを設けていますか？そして、内容の把握に努めていますか？
□ 関係する利害関係者間の調整はとっていますか？

3. 目的を明確化した上で抽象化・モデル化を行っていますか？
□ 何のために何を抽象化・モデル化することが適切かを考えた上で、抽象化・モデル化を行っていますか？
□ モデル化を実施することで、上記目的は果たせていますか？

4. 当初の不確実さを織り込んで「段階的に明確化する」アプローチを認めていますか？
□ 経験知を蓄積するため小さな失敗を奨励されていますか？
□ 「仮説検証型での予測した失敗」と「意図に反した失敗」の相違を識別していますか？
□ ”初期段階に不確定な要素があること“ を前提にして、戦略的に開発に取り組め
るよう仮説に遊びや修正余地が織り込まれていますか？
□ チャレンジした結果の仮説却下をこだわりなく認めていますか？
すべて YES の場合 ⇒NO がある場合⇒

システムズエンジニアリングを組織的な取り組みとして進めていただくことをお薦めします。
システムズエンジニアリングの取り組みをお薦めします。

44

開発者のためのシステムズエンジニアリング導入の薦め
2017 年 7 月 3 日 WEB 公開
編著者(敬称略 所属は 2017 年 6 月時点)
独立行政法人情報処理推進機構
技術本部 ソフトウェア高信頼化センター
ソフトウェア高信頼化推進委員会
システムズエンジニアリング推進ＷＧ委員
主査

白坂 成功
大西 純
小笠原 秀人
梶本 一夫
末冨 隆雅
豊島 真澄
長堀 泉
松並 勝
松本 雅行

慶應義塾大学大学院
株式会社三菱東京 UFJ 銀行
株式会社東芝
パナソニック株式会社
マツダ株式会社
株式会社デンソー
株式会社富士通総研
ソニーデジタルネットワークアプリケーションズ株式会社
東日本旅客鉄道株式会社

IPA/SEC
中尾 昌善
岡本 拓也
齋藤 毅
齊藤 善治
新谷 勝利
杉崎 眞弘
西原 栄太郎藤原 由起子
室修治

45

開発者のためのシステムズエンジニアリング導入の薦め

独立行政法人情報処理推進機構© Information-Technology Promotion Agency, Japan. 201746