日: 2026年9月30日

システムオブシステムズ研究会（第7回）報告

世話人　落水浩一郎

第7回システムオブシステムズ研究会を下記のとおり開催したので報告する．

記

日時：2019年6月10日　18:30～20:30

場所：ソニーシティ大崎　会議室

　　　〒141-0032 東京都品川区大崎２丁目１０−１

• 出席者（順不同）：小笠原　秀人（千葉工大）、日下部　茂（長崎県立大）、艸薙　匠（東芝）、

栗田　太郎（ソニー）、新谷　勝利 (新谷ITコンサルティング) 、瀬尾　明志（日本ユニシス）、奈良　隆正（コンサル21世紀）、羽田　裕（日本電気通信システム）、端山　毅（NTTデータ）、方(ファン) 学芬 (SRA先端技術研究所) 、堀雅和（インテック）、矢嶋　健一（JTB）、

落水　浩一郎（UIT，世話人)，

議事：

• 18:30～20:20　講演　Software
  and Systems Engineering

新谷　勝利 (新谷ITコンサルティング)

• DX（digital transformation）は、2025年問題（レガシーソフトが破滅する問題）と関連して議論されることが多いが、必ずしも適切ではない。JUASは、製品及びサービスの技術的側面と業務プロセス側面の２次元構造で調査・報告している。この構造でDXの進展を述べることが適切かどうかは分からないが、②でのべるプロセスの自動化において日本の多くの企業人は、日本はこの分野で大幅に遅れている/遅れつつあるとの見解を持っている。というか、従来のやり方を変える仕事の仕方を案出するのが苦手なのではなかろうか？
  • システムの定義とシステムズエンジニアリングの定義

システムズエンジニアリングとは、例えば、「予約→デザイン・生地選び・採寸→縫製→発送」

という一連のプロセスを設計・実現（自動化を含む）すること。従来、個々の作業の最適化を指向し、それらを結びつけ、新たな価値を生み出すより広く俯瞰的なプロセスでイノベーションにつながるように工夫することが不得意なのでは？

• システムとは「個を結び付けたもの」という定義が長い間つかわれてきたが、INCOSEによりbehaviorとmeaningという二つのコンセプトをもとにした、新たな定義が検討されている。こここで、behavior
  は項目②の定義に該当する。meaningとは、概念モデルなどを指す。
  • INCOSEを中心とするシステムズエンジニアリングのソサイエティの構造は、アカデミックというより実務家の集合体である。ここでは、システムズエンジニアリングは実務家によるプロジェクトのベストプラクティスの集合であり、その意味で活動範囲が広く分散しており、それがまた、活力の源泉ともなっている。SEBoKは、そのベストプラクティスの集合、すなわちプロセスあるいはトピックスの体系化されたものであることを反映して、1000ページ以上にもわたる膨大な資料となっており、しかも年に二度も改訂されている。システムズエンジニアリングの活動に対する辞書であると位置づけると有益である。
  • SEBoKでは、システムは多くのディシプリン、ソフトウェアエンジニアリングはその内の主要な一つ、があって作られるとしており、よって、ソフトウェアエンジニアリングの成果はシステムズエンジニアリングに多く取り入れられている。例えば、SWEの90年代以降の成果（プロセスモデリング、MDD,
    アジャイルなど）をもってソフトウェアエンジニアリングの成果としている。70年代、80年代のソフトウェアエンジニアリングの成果（要求定義、アーキテクチャ設計、構成管理など）は、システムズエンジニアリングの成果として位置づけている。
  • 日本でシステムズエンジニアリングを教育・研究している大学は、INCOSEによる大学により提供されるコース及び学位の調査から、東工大、慶応、筑波、静岡、北九州大、青山学院大、中央大学など、諸外国に比べて圧倒的に少ない。多分、システムズエンジニアリングがカバーする範囲が広いが故に、それらの環境を持つ企業においてこそ社内人材の育成が容易とされたのかもしれない。ただし、日本企業の低い利益率を考えた時に、企業が広いディシプリンを含む社内教育を実施し得るかは議論を呼ぶところである。
  • SE Vision 2025が最後に紹介されたが、そこに記述されている状況に日本があるかどうかは極めて疑問である。悲観的でさえある。今後、色んな意味で価値創生が言われる社会において、日本における人材育成の現状はそのような期待に応えられないのではないか？
• 20:20～20:30　 今後の予定を以下のように決定した。
  • NTTデータの端山毅さんに新たにSIGSoSの会員として参加いただけることになった
  • 第8回：栗田さん「情報セキュリティに関する内外の動向」
  • 第9回：瀬尾さん「最近の中国、特に深センでのイノベーション活動の実態」

システムオブシステムズ研究会（第6回）報告

世話人　落水浩一郎

第6回システムオブシステムズ研究会を下記のとおり開催したので報告する．

記

日時：2019年3月1日　18:30～20:30

場所：ソニーシティ大崎　会議室

　　　〒141-0032 東京都品川区大崎２丁目１０−１

出席者（順不同）：小笠原　秀人（千葉工業大学）,　日下部　茂（長崎県立大学）,艸薙　匠（東芝）,　

栗田　太郎（ソニー株式会社）,　瀬尾　明志（日本ユニシス株式会社）,　奈良隆正（コンサル21世紀）,　

羽田　裕（日本電気通信システム）,　 堀　雅和（株式会社インテック）,　矢嶋　健一（株式会社JTB），

落水　浩一郎（UIT，世話人)，

議事：

• 18:30～20:00　講演　落水浩一郎　UIT、Myanmar

“費用対効果を考慮したセキュリティ要件の抽出プロセス”

リスク管理、定量的リスク解析、ソフトウェア開発手段を統合した、セキュリティ

　 エンジニアリングプロセスの定義と事例研究の結果について報告した。

セキュリティ対策は重要ではあるが、費用が掛かる。予算に応じたセキュリティ対策を

施す手段が必要である。費用対効果を最大にするようなセキュリティ要件を選択する

プロセスが必要である。

セキュリティ要件の選択を、脆弱性に対する攻撃（リスク）に備えるリスク管理の手段

としてとらえ、リスク管理、定量的リスク解析、ソフトウェア開発手段を統合した、

エンジニアリングプロセスを提案した。機能の絡み合いに伴う複雑さを制御し、

中流・下流工程への拡張に伴うプロセス改善を支援するため、統合の手段として

FRAMを用いた。発展途上国や、日本においては中小企業などの、セキュリティ

対策の  底上げに活用できることを目指している。

　　質疑・コメント

• セキュリティエンジニアリングプロセスに関する研究は事例が少ないように思うが
• CMU　SEIの主任研究員Nancy Mead によって開発された方法論SQUAREの例が

ある。2004年から2005年にわたって多くの事例研究が実施され、論文・報告として

発行されている。また、プロセスをサポートするツールも開発されている。ワーク

ショップ、チュートリアル、教材などがCERTウェブサイトからダウンロードできる。

• UITにおける事例研究はセキュリティに関する一般的な内容であるように見受けられる。
• UITは実はまだ、攻撃を受けたことがなく、学生によるオンラインゲームの被害が最大のものである。今後もっと現実的な事例研究を進める必要がある。
• 日下部先生より、安全性とセキュリティの問題は対応において共通性があるとのコメントがあった。
• 栗田さんより、情報セキュリティに関する国際会議における最近の話題について紹介があった。
• 「セキュリティとSoSは相反する世界に住んでいるのではないか？　セキュリティは閉じておりSoSはオープンである」との矢嶋さんのコメントがあった
• 20:00～20:30　 今後の予定を以下のように決定した。
  • 次回（第7回）：新谷さん「最近のシステムズエンジニアリングの動向（仮題）」
  • 第8回：栗田さん「情報セキュリティに関する内外の動向」
  • 第9回：瀬尾さん「最近の中国、特に深センでのイノベーション活動の実態」

追加：先週、SEAフォーラム「ブロックチェーンは社会基盤になるか」に参加しました。

NTTデータの赤羽さんより、ブロックチェーンは

• 文化が異なる国際的連携を必要とするようなシステムで有用である
• 応用上、トレーサビリティが一つの特徴である

　とのお話をお聞きし大変刺激を受けました。これは、SoSに使えると思いました。

境界不安定、管理維持のためのコミュニケーション支援、進化支援、障害発生の記録と対応

などの問題を、ブロックチェーンで管理し、分散データベースとして共有すればなにかうまく

いくような気がしました。どなたか研究されませんか？

システムオブシステムズ研究会（第5回）報告

世話人　落水浩一郎

第5回システムオブシステムズ研究会を下記のとおり開催したので報告する．

記

日時：2018年5月18日　18:30～20:30

場所：銀座ビジネスセンター，〒104-0061　東京都中央区銀座6-6-1銀座風月堂ビル５階

出席者（順不同）：日下部　茂（長崎県立大），新谷　勝利 (新谷ITコンサルティング) ，

瀬尾　明志（日本ユニシス），堀雅和（インテック），

奈良　隆正（コンサル21世紀），方　学芬 (SRA先端技術研究所)，　

羽田裕（日本電気通信システム），艸薙　匠（東芝），

矢嶋　健一（JTB）落水　浩一郎（UIT，世話人)，

議事：

18:30～20:30　講演「“STAMP/STPAの最新の動向”日下部　茂（長崎県立大）」

およびSTAMP/STPA についての意見交換

日下部先生におまとめ頂いた、日下部先生による講演の概要と，質疑・意見交換の内容を

以下に記す．講演と質疑を通じて，STAMPモデルの考え方と，STPAの手順について，

理解をふかめることができた．

• STAMPモデルとは

まず，背景を含めた概説が行われた． STAMP は，システム理論に基づいた新しい事故因果関係モデルである．ソフトウェア集約的なシステムが増加し，その安全性についての効果的な分析も求められている．しかしながら，ソフトウェアそのものは故障しないし，その利用や運用をする人や組織も故障はしない．そのようなソフトウェア集約的なシステムを，故障という観点で分析することには限界があることなどが説明された．STAMP/STPA では，システムのコンポーネントが故障していなくても，コンポーネント間の非安全な相互作用によっても事故が引き起こされ得るとし，コントロールの問題という観点で対象をモデル化し分析するものとして提唱されている．

図 1　基本的なSTAMPのモデル構成

基本的なSTAMPモデルの要素と構成例を図 1に示す．安全性のような創発性をコントロールする必要がある対象を，コントロール対象のプロセスとし，そのコントローラがコントロールのためのアクションを決定して発行し，その結果のフードバックを得ることを繰り返す． STAMP では，システムの安全制約を守れず，システムがハザード状態になることで望まない損失が発生することを，上記のようなモデル要素で表現されるコントロールストラクチャーを用いてモデル化，分析する．

STAMPとその分析法STPAの入門的解説は，文献[1]をはじめすでに複数のものがあるが，それらを読んで実際に自分でモデルの構築と分析を試みるとよくわからない点が出てくる，といった質問があった．例えば，図 1に示した基本的なモデルの構成要素について文献[1]では以下のように説明されているが，プロセスモデルの “belief” がわかりにくいとの質問があった．

「コントロールアルゴリズムは，コントローラの意思決定プロセスを表わし，コントールアクションを決定する．コントローラは，また，意思決定を行うために使われるコントローラ内部の信じていること(belief)を表すプロセスモデルを持つ．プロセスモデルは，コントロールアルゴリズムによって使用され，コントロール対象のプロセスについて信じていることやシステムまたは環境の他の関連のある側面を含むことができる．プロセスモデルは，コントロール対象のプロセスを観測するために使われるフィードバックによって部分的に更新できる．

図のどの時点でも，問題は発生する可能性がある．例えば，プロセスモデルは，現実と一致しない場合があり（例えば，コントローラが，飛行機が本当は上昇している時に降下していると考えたり，自動車が本当は後退(reverse)に入っている時に駐車(park)に入っていると考えたり，空港の滑走路が空いている，など），これは，非安全なコントロールアクションにつながる．センサの故障が，誤ったフィードバックを引き起こし，非安全な動作につながる可能性がある．ある設計では，必要なフィードバックが欠落しているかもしれないし，プロセスモデルの欠陥と非安全な動作をもたらすような遅延フィードバックを与えているかもしれない．不十分なプロセスモデルは，非安全なコントロールアクションを引き起こす可能性がある．コントローラのプロセスモデルが現実とは一致しない場合，プロセスモデルの欠陥が発生する」

講師から，「例えば，子供を引率する状況を考えてみたときに，子供に的確な指示を出すために指導者の頭に何が入っていないといけないか，といったもの．ある程度抽象的なレベルでも考えることができるし，指示を出す対象の子供の特性や，屋外でのキャンプや工場見学のような状況に関する情報などで特化した上で考えることもできる．」「STAMPは，意図的に緩くなっている側面もあり，機械的に実行できるような記述体系もないため，ある意味敷居が低い反面，記述の基準がわかりにくく感じる場合もあるかもしれない．また，モデル化と分析を複数回繰り返しながら洗練化することも想定されており，適宜見直されることもある．」といった説明があった．

STAMPでのコントローラとコントロール対象のプロセスの組み合わせは，機械-機械に限定されず，人間-人間，人間-機械，組織‐機械，などであってよく，実際に様々な組み合わせでのモデリングが行なわれ実績を上げている．STAMPに関する分析法(ツール)には図 2のようなものがあるが，代表的なものは後述のSTPAと，CASTである．STPA は，開発中に潜在的な事故の要因を分析し損失を未然に防ぐための事前の解析手法であり，CAST は，発生した事故/インシデントを評価し，関与していた原因因子を識別するための事後的な解析手法である．

図 2　STAMPと関連ツール(分析法)およびその利用プロセス

• STAMP
  /STPA

STAMPに基づく分析法の最も代表的なものであるSTPA の紹介があった．現在も研究が続いている手法でもあり，その具体的な適用法には様々なバリエーションがあるが，最近発行されたハンドブックでは以下のような手順となっている[1]．

1. 解析目的の定義，
2. コントロールストラクチャーのモデル化，
3. 非安全なコントロールアクションの識別，
4. 損失シナリオの識別

アクシデントなどの用語の使い方は，分野，業界ごとに異なることが多く，ハンドブック[1]では混乱を避ける目的で「損失」という用語を用いている．

手順1　解析目的の定義

STAMP/STPAはトップダウンの手法で，まずモデリングの目的を定める必要がある．どのような損失をその解析で防ぐことを狙っているのか？ STPAを人命の喪失を防ぐような伝統的な安全目標に対して適用するのか？もしくは，セキュリティ，プライバシー，性能，及びその他のシステム特性に対して，より広く適用するのか？解析対象となるシステムは何か？システムの境界は何か？これら及び他の基本的な質問が，このステップで問われることになり，以下の手順からなる．

1. 損失を識別
2. システムレベルのハザードを識別
3. システムレベルの安全制約を識別
4. (オプション)　ハザードの精密化

STAMP では，(業界や分野で定義が異なる可能性のある用語である) 損失，システム，ハザード，安全制約は以下のように定義されている．

損失：利害関係者にとって価値のあるものを失うことに相当．損失には，利害関係者に受け入れられないような，人間の生命の喪失や人間の傷害，物的損害，環境汚染，ミッションの喪失，評判の喪失，機密情報の喪失もしくは漏洩，またはその他のものが含まれる．

システム：いくつかの共通の目標，目的，または，その達成のために，一体として合わせて動くコンポーネントの集合．システムには，サブシステムを含んでもよく，また，より大きなシステムの一部であってもよい．

ハザード：ハザードとは，最悪ケースの環境条件と組み合わさることで，損失につながるような，システム状態，または，条件の集合である．ハザードは対象システムの境界内のものであり，システムの範囲，範囲外の環境との境界が明確になっている必要がある．また，ハザードが実際に損失につながるのは，組み合わさる，最悪の環境条件の存在が必要である．

安全制約：システムレベルの制約は，ハザードを防ぐ（そして最終的に損失を防ぐ）ために満たす必要があるシステムの条件や動作を特定する．典型的には，ハザードが識別されると，それらを逆に反転して考える．トップダウンに考える場合，まず高レベルの安全制約が導かれることになる．最初からすべての安全制約が確定するとは限らず，分析の途中でも導出，修正され得る．

手順2　コントロールストラクチャーのモデル化

コントロールストラクチャーとよぶシステムのモデルを構築する．コントロールストラクチャーは，一連のフィードバックコントロールループとして，システムをモデル化し，機能的関係性及び相互作用を表現している．コントロールストラクチャーは，通常，非常に抽象的なレベルで始まり，システムの更に詳細な情報を表現するために，繰り返し改良されていく．図 1では最も単純な構成のものが示されていたが，一般的に，コントロールストラクチャーは階層的な構造となる．階層的なコントロールストラクチャーの縦軸には意味があり，システム内のコントロールと権限を示している．各エンティティは，その直下のエンティティ対するコントロールと権限を有し，かつ各エンティティは，同様にすぐ上位のエンティティからのコントロールと権限の対象となっている．

上向きの矢印はフィードバックを表しているのに対し，下向きの矢印はコントロールアクション(コマンド）を表している．これらの約束ごとは，複雑さを管理し，コントロールの関係やフィードバックループの識別を容易にする助けとなる．単にコントロールストラクチャー・ダイアグラムを描くことで，以前に発見されていない欠陥を，明らかにできるケースもある．例えば，安全なコントロールアクションを選ぶのに必要なフィードバックを持たないエンティティによってコントロールアクションが与えられるかもしれない，フィードバックがそれについて何かをする能力を持たないエンティティに与えられるかもしれない，競合を検知したり解決する能力を持たないコンポーネントへ複数のコントローラが競合するコマンドを与えることができるかもしれない，など．

手順3　非安全なコントロールアクションの識別

コントロールストラクチャーのコントロールアクションが最初のステップで定義された損失にどのようにつながり得るかを調べるために，非安全なコントールアクションを分析する．非安全コントロールアクション（UCA）は，ある特定のコンテキストと最悪の環境下で，ハザードにつながるコントロールアクションのことである．これらの非安全なコントールアクションは，以下の四つの側面があり，システムの機能要求や制約を作成するために使われる．

• Not providing causes hazard : コントロールアクションが与えられないことがハザードにつながる．
• Providing causes hazard :コントロールアクションが与えられることがハザードにつながる．
• Too early, too late, or wrong order causes hazard : 潜在的には安全なコントロールアクションを，遅すぎて，早すぎて，または不適切な順序で与えることでハザードにつながる．
• Stopping too soon or applying
  too long causes hazard : (連続的で非離散的なコントロールアクションにおいて) コントロールアクションの停止が早すぎる，もしくは適用が長すぎることがハザードにつながる．

手順4　損失シナリオの識別

システムで非安全なコントロールが発生する可能性のある理由を識別する．損失のシナリオは，典型的には，コントローストラクチャを右上と左下のように対角線で区切るようにして，２つのタイプを考慮する(図 3 参照)．

図 3　損失シナリオ識別の例

1. なぜ，非安全なコントロールアクションが起こるのか？　間違ったフィードバック，不適切な要求，設計ミス，コンポーネントの故障，及びその他の要因が，どのように非安全なコントールアクションを引き起こし，最終的に損失につながり得るのか．
2. なぜ，安全なコントロールアクションが与えられたとしても，不適切に実行される，または実行されず，ハザードに至るのか？

この手順は，対象領域の専門知識が必要となることが多くガイド化が難しいとされていたが，最新のハンドブック[1]では以前より詳細なものが示されている．

• MITにおける国際会議他

最後に関連するツールや， 2018年3月にMITで開催されたSTAMPに関するワークショップの内容が紹介された[2]．ワークショップは年々参加者が増え，2018年3月は登録ベースで32か国，300人越えの参加者があった．主には，航空宇宙・防衛関係，次いで自動車関係であったが，医療機器，ヘルスケア，オイル・ガス，鉄道，化学，ヒューマンファクター，ロボット，セキュリティ，労働環境安全など様々な領域がカバーされていた．ソフトウェア工学関係も若干含まれていた．

文献

[1] Nancy G. Leveson, John P. Thomas著，白坂成功他訳，“STPA_Handbook_JPV02”,

http://psas.scripts.mit.edu/home/get_file2.php?name=STPA_handbook_japanese.pdf, 2018年5月18日確認

[2] STAMP Workshops, http://psas.scripts.mit.edu/home/stamp-workshops/, 2018年5月18日確認

投稿を表示(新しいタブで開く)

システムオブシステムズ研究会（第3回）報告

SIGSoS 世話人　落水浩一郎

第3回システムオブシステムズ研究会を下記の報告のように開催した。

記

日時：2017年5月30日　18:30～20:30

場所：銀座ビジネスセンター
〒104-0061　東京都中央区銀座6-6-1銀座風月堂ビル５階

出席者（あいうえお順）：

小笠原　秀人（東芝）、落水　浩一郎（UIT、世話人)、艸薙　匠（東芝）、

栗田　太郎（ソニー）、塩谷　和範（ISO/IEC SC7エキスパート）、

新谷　勝利 (新谷ITコンサルティング) 、瀬尾　明志（日本ユニシス）、

奈良　隆正（コンサル21世紀）、羽田裕（日本電気通信システム）、

堀雅和（インテック）、矢嶋　健一（JTB）

議事：

• 18:30～20:15　講演　羽田裕氏、日本電気通信システム“FRAMについて”

およびFRAMの有用性とスコープについての意見交換

羽田氏による講演の概要と意見交換の内容を示す（添付資料参照）

• 自社の通信ネットワーク（電話交換システム相当）分野においては、ソフトウェア障害に比べ，運用・保守作業での障害の割合が増加傾向にある
• 運用・保守作業における失敗事例をベースにして、ケーススタディによるリスク特定教育を社内で実施している。その際、様々の道具を検討した結果、FRAMの導入を決定した。その結果得られた知見を紹介する。
• 従来のリスク特定教育では、リーダクラスの参加者に、リスク分類の視点を与えても，経験知が失敗事例の視点対象の選択に影響を与えるという問題があった。
• リスク特定においては，失敗事例全体に対して経験知を利用するだけでなく，失敗事例を作業に分解した後，作業ごとに経験知を利用するようなアプローチが必要とされていた。
• そこで、運用・保守作業の失敗事例をFRAMモデルとして可視化することにより、作業の相互依存関係を明確にし、経験知をより網羅的に使いつつ，リスクを特定する学習コースを開発・実施した。
• 従来は、文章やフローチャートなどによる、シーケンシャルな作業手順に基づく活動であったが、個々の作業の相互依存関係は、実行順序以外は暗黙的であることが多く、個々の作業を実施するための条件・制約などの検討が困難であった。
• 
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  機能共鳴分析手法の概要は下図（図１）に示す通りである。

　　　　　　　　　　図１　FRAMの概要（別添羽田氏講演資料より）

• 
  
  
  
  
  図１左下の六角形がFRAMにおける機能の表現である。ここで機能とは、例えばシステムの運用者・保守者によって実際に行われた作業や、利用したシステムの機能などを指す。

　　　　　　　　　　　図2　FRAMモデルの例（別添羽田氏講演資料より）

（１０）FRAM記述の一つの特徴は、5つの入力と１つの出力をつなぐ「機能間の関係」の

記述にあり、意味が暗黙的な線・矢印ではなく、明示的な6つの特定の関係を提

供することである。図２は、「エリック・ホルナゲル(著), 小松原明哲(監訳), 社

会技術システムの安全分析‐FRAMガイドブック, 海文堂 (2013)」より、羽田氏

が引用した外科手術のFRAMモデルである。六角形の機能間をつなぐ関係に付いて

いるラベル（説明）は、その時点での作業完了後の状態を示しており、FRAM記述

のもう一つの特徴である。

（１１） 図２に示すような、FRAMモデルを利用して、制御されていない出力の変動（リ

スク）を特定するため「機能の変動」を解析する。変動の要因には3種類の型があ

る。①機能の内的変動、②機能が実行される状況の変動（外的変動）、③上流機能

の変動の影響。このうち、②の変動の認識は複雑であり、今後の課題である。

（１２）リスク特定教育を実施した結果を、理解度、役立度、活用度の3点から評価した結

果、以下のような結果が得られた。

（１３）理解度94％、活用度81％、役立度69％。参加者は、ソフトウェア技術者が12名、ハ

ードウェア技術者が4名であったが、両者によって評価が異なる。

（１４）ソフトウェア技術者：理解度100％、活用度92％、役立度83％。

（１５）ハードウェア技術者：理解度75％、活用度50％、役立度25％。

（１６）注：ここで、ハードウェア技術者は、「もの中心」の考え方であり、必要であるの

に「プロセス中心」の考え方が理解できていないなどの議論があった。

（１７）議論：ここで、「1％の不具合を追及するより、99％の成功をさらに改善する」SafetyIIに関する考え方の紹介があり、当然のことながら、FRAMは

SafetyIIの実現手段として活用すべきであろうという見解の一致をみた。

• 20:15～20:35　今後の予定

落水より、ここまでの検討成果をまとめた図（図３）が示され、一部、それをもとにしながら、今後の活動方針について意見交換を行った。図３において、

• 左側の青色で記述した部分が対象分野であり、分散システム、社会技術システム、システムオブシステムズ、IoTシステムなどを対象としている。
• その分野では、社会技術システムの複雑性の制御、SoSの境界定義、ディペンダビリティ保証、創発特性への対応などが解決すべき問題として列挙されている。
• それに対する攻め口の例として、システム要素毎のインクリメンタル開発・テスト、システム構成要素間の不適切な相互作用の解析などを挙げている。
• 問題に対する解の実現手段として、FRAMとSTAMP/STPAが挙げられている。
• その他、いまだ調査中の対象が数多く存在し、適切な講師を招くことにより、考察をさらにふかめることの重要性が共有された。
• 図中、?がついている項目は今後の調査検討が必要とされる部分の例示であり、いまだ信頼できる情報でない、または、未調査であることに注意されたし。

　　　　　　図３　SIGSoSにおける、これまでの検討内容と今後の検討課題

　また、第4回以降の話題について下記のような提案が会員各位からあった。

• システムズエンジニアリングの新しいアプローチ（新谷氏）
• ソフトウェアエージングと若化（広島大学　土肥先生）小笠原氏提案
• テストに対する考え方あれこれ（電通大　西先生）小笠原氏提案
• 安心・安全なIOT社会実現に向けた提言（情報セキュリティ大学院大学学長、内閣府SPIプログラムディレクタ　後藤厚宏（ごとう　あつひろ）先生）奈良氏提案

システムオブシステムズ研究会（第2回）報告

第2回システムオブシステムズ研究会を以下の報告のように開催した。

SIGSoS 世話人　落水浩一郎

日時：2017年3月17日　18:30～20:30

場所：北陸先端科学技術大学院大学　東京サテライト　研修室A

　　　東京都港区港南2-15-1 品川インターシティA棟19F

出席者（あいうえお順）：

小笠原　秀人（東芝）、落水　浩一郎（UIT、世話人)、艸薙　匠（東芝）、

塩谷　和範（ISO/IEC SC7エキスパート）、鈴木　正人（北陸先端大）、

奈良　隆正（コンサル21世紀）、羽田裕（日本電気通信システム）、

Huyen, Phan Thi Thanh（日立）、堀雅和（インテック）、矢嶋　健一（JTB）

議事：

1. 新規会員羽田裕（ゆたか）さん、および、

初出席会員Huyen, Phan Thi Thanhさんの自己紹介　

• 講演：矢嶋健一氏「システムオブシステムズ～旅行業界編」18:40～20:20

前回に引き続いて、旅行販売システムの事例について、矢嶋氏から講演をいただき、それに基づいて、システムオブシステムズの特徴や問題点を検討した。

• 旅行販売システムは旅行商品の造成・管理・販売を支援するシステムであるが、販売促進や、オーバーブッキングなど種々のトラブルへの対応は、人間系によってなされており、典型的な社会技術システムである（注：技術システム、例えばソフトウェア、だけで解決しようとすると、実現が複雑かつ困難になる問題を、組織や人間も含めたシステムとして解を構築するのが、社会技術システムの一つの特徴である。）。
  • 旅行製品の造成のため、国内外の航空会社のシステムやホテル業界のシステムとデータ連携をしている。それぞれのシステムが独自に管理されており(Organizational Independence)、システムオブシステム独自の問題点を保有している。
  • 外部システムとの連携目的は、販売用在庫の取得、委託販売、クレジット決済、予約伝達などである。なかでも海外のシステムとの連携は、カルチャーが異なるため大変である。
  • 連携先の複数のシステムと改変計画を揃えなければならず、合意形成に、困難を感じている
  • 国内での連携は、「システムの安定」を優先するが、欧米との連携では「システムの改善」が優先され、その双方を制御できる手法を必要としている
  • 旅行販売システムは、会社の業務の発展、拡大、変更にあわせて発展してきたため

アーキテクチャが必ずしも統一されておらず、また、その全容を把握している人は少ない。とくに、何が起こるかわからないので、レガシーなソフトウェアを廃棄できない状況である。また、そのシステムを管理・進化させる組織も大規模であり、それぞれの担当が自身のまわりしか見えない状況があり、問題である。しかし、何故か、うまく対応していけている。

• システム変更による影響波及の回避あるいは対応が困難である。
  • 旅行販売システムの特徴は以下の通り。「情報（データ）を取り扱うシステムである」、「価値の有効活用およびセキュリティのためのデータの一元管理」、「さまざまなシステム間連携」、「トランザクション中心のシステム」。
• 羽田裕氏「SS2017ワーキングの開催案内」

来たる6月8日～9日にかけて宮崎で開催される、ソフトウェアシンポジウム2017に、「システムオブシステムズと機能共鳴分析法（仮題）」を提案したい旨の紹介があり、SIGSoSとしては、全面的に協力することとした。運営方法は今後の検討課題である。　

• SIGSoSの運営について
  • 日本電気通信システムの羽田裕氏が新しく会員となられた
  • 会員の発表についても、3000円の謝礼を払うこととした。
  • 塩谷さんより、資料「VSE（Very Small Entity）標準　導入のガイドブック」が、感想文を提出することを条件に、SIGSoS会員（出席者）に配布された。
  • 次回は5月に開催する。講師は羽田さんとし、機能共鳴手法についてご紹介頂く。

以上

システムオブシステムズ研究会（第1回）報告

第１回システムオブシステムズ研究会を開催いたしましたので、ご報告いたします。SIGSoS 世話人　落水浩一郎
日時：2017年1月20日　18:30～20:30
場所：北陸先端科学技術大学院大学　東京サテライト　研修室A
東京都港区港南2-15-1 品川インターシティA棟19F
出席者（あいうえお順）：
小笠原　秀人（東芝）、落水　浩一郎（UIT、世話人)、艸薙　匠（東芝）、
栗田　太郎（ソニー）、塩谷　和範（ISO/IEC SC7エキスパート）、
鈴木　正人（北陸先端大）、瀬尾　明志（日本ユニシス）、
奈良　隆正（コンサル21世紀）、堀雅和（インテック）、矢嶋　健一（JTB）
議事：
1. 会員自己紹介　18:30～18:50
2. SIGSoSの運営について　18:50～19:00
(1) 当面年4回程度の開催とする
(2) 外部/内部から講師を招聘して、事例研究を中心にSoSに関する理解を深める。外部講師の場合5000円程度の謝礼を払う。また、研究成果のサーベイも適宜実施する。IoTに関する話題もSoSとの関連で含める。
(3) 活動の成果を全員共著の本としてまとめる。
3. 講演　落水浩一郎、“システムオブシステムズとデペンダビリティ”19:00～19:50
(1) いくつかの文献のサーベイを基にして、SoSの定義と問題点、および、
デペンダビリティ・エンジニアリングプロセスを紹介した（第一回例会資料（落水））
(2) 以下の質疑がなされた
① 「システムの再利用」という言葉づかいは適切ではない。
「システムの連携」とすべきであろう。
② それぞれ異なる組織に属し、独立に進化するSoS構成要素間の調整をどのようにして実現するのか。
組織を渡る会合を設けて、ネゴシエーションや調整を行う。
③ 社会技術システムにおいて、第1層の規則に違反する第2層のプロセスやオペレータが存在する場合、どのように取り扱うのか
規則を順守することを前提としていると思われるが、今後の検討課題である。
④ SoSは還元主義のアプローチでは攻めきれないという意見が、紹介された文献に記載されているが、これについての見解を聞きたい。
文献には、全体論的アプローチ（holistic approach）をとるべきであるとの見解が示されているが、具体的にどうすればよいかについての考え方は示されていない。その是非も含めて今後の検討課題である。
4. 事例研究と意見交換　矢嶋健一、“旅行業界の事例”19:50～20:25
(1) 旅行業界の旅行販売システムがSoS的特徴をもつことが、以下の点にわたって紹介された（会員への資料配布は内容を整備の上、後日あらためてとの連絡あり）。
① 異なる組織によって管理される多くの情報システムと連携して、旅行販売システムは構築されている
② 独立して管理・進化することによって発生する不整合は、国内のシステムが対象の場合、長時間（例えば6ヵ月）にわたる交渉によって解決する。国際的なシステムの場合は、力の強いところに合わせるしかない。
③ データを中心としたシステム連携であり、APIを介して利用する。連携相手ごとにデータの維持・管理の方針が異なり、それに関する調整は大変である。　組織をわたって利用されるデータの一元管理が必要になる。
(2) 大変興味深い事例であり、SoSの特徴（問題点）とその対策を検討するのに適切な題材であるとの共通認識が参加者の間で持てたので、次回あらためて検討をすすめることになった。
5. 次回の予定　20:25～20:30
(1) 次回は3か月後を目標に、議事４の内容（旅行業界の事例）を再度検討し、SoSに関する理解を深めることとなった。