月: 2026年9月

システムオブシステムズ研究会（第13回）報告
報告者　落水浩一郎

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

記
１． 日時：2021年4月29日および4月30日　18:30～20:40
第12回と同様に、参加者を変え、同じ内容を29日と30日の両日に報告・議論した
２．場所：オンラインZOOMミーティング
３． 出席者（アイウエオ順、敬称略）：
(1) 4月29日
日下部茂（長崎県立大）、栗田太郎（ソニー）、新谷勝利(新谷ITコンサルティング)、
富松篤典(電盛社)、落水浩一郎（UIT，世話人）
(2) 4月30日
小笠原秀人（千葉工大）、艸薙匠（東芝）、日下部茂（長崎県立大）、栗田太郎（ソニー）、
新谷勝利(新谷ITコンサルティング)、瀬尾明志（日本ユニシス）、端山毅（NTTデータ）、
奈良隆正（コンサル21世紀）、方(ファン) 学芬 (SRA先端技術研究所) 、
堀雅和（新潟工科大）、矢嶋健一（JTB）、落水浩一郎（UIT，世話人）
４． 議事（4月29日）：
(1) 18:30～19:30　講演
落水浩一郎(UIT)「デジタルトランスフォーメーション -その目標と手段-」
MITスローン情報システム研究センター発行の著作「デザインド・フォー・デジタル」の内容を、
以下の点にわたって解説した。
① デジタル技術は新たなカスタマーバリュープロポジションを形成する機会を提供し、新しいカスタマー・バリュープロポジションはデジタルサービス（デジタルオッファリング）の開発を促進する。
② より高度なカスタマーバリュープロポジションを実現するために、イノベーティブなデジタルサービスを開発することをデジタル対応化という
③ 継続的なデジタル対応化のために人材、組織、プロセスを全体的・組織的に構成することをデジタル企業デザインとよぶ
④ デジタル企業デザインを目標として、デジタル企業デザインされていない企業を変革していく過程をデジタルトランスフォーメーションという
⑤ デジタルトランスフォーメーションのため、本書が推薦する手段は5つのビルディングブロックの段階的実現である。

(2) 19:30～20:30　議論
① 2年前に行われたレガシーがよくないというDXの説明はまちがっていたのでは
そう思います
② デジタル対応、デジタルトランスフォーメーション、デジタル企業デザインという用語間の意味の違いをもう少しはっきりと認識したほうがよい。私もデジタルトランスフォーメーションとデジタル企業デザインは同じような意味合いにとれるので混乱している。デジタルデザインの方がより具体的に定義されている。デジタルデザインという言葉はDXの目標をより具体的に定義している。
③ 主要な概念間の関係で、デジタルトランスフォーメーションから出る矢印は、カスタマー・バリュープロポジションとデジタルサービスにも向かうべきだ。その通りです
④ DXはすべての業種の企業を対象にしているのだろうか。事例研究の結果を抽象して得られたモデルであり、事例研究の対象となった企業はすべてデジタルを活用している。そこで、デジタルを使った企業を対象としているのではないか。なるほど
⑤ 自動車の自動運転機能がデジタルサービスでないというのは大変気になる。ユーザが変わっていないからではないか。経営学にダイナミックケーパビリティとオーディナルケーパビリティという概念があるがその違いが明確でないという説もあり、同じようなことではないのか
⑥ 「デジタル技術の活用による新しいバリュープロポジションの創出」というところが話の肝か。はい、そうです
５． 議事（4月30日）：
(1)18:30～20:30　講演 4月29日に同じ
(2) 20:30～21:40議論
① この著書に書かれているようなことを、イノベーションのジレンマを乗り越えて、既存（大）企業が実施できると、著者達は本気で考えているのだろうか。非難しているのではなく、事実を知りたい
② 私の会社はDXに取り組んでいる、5つのビルディングブロックのうち、アカウンタビリティフレームワークを実施するのは日本の企業では難しいと思っている
③ 中小企業にはDXの話はひびかないとおもわれる
④ ビルディングブロックは日本では５＋１になると思う。＋１は「組織カルチャー、人の意識」である。とくに従業員に、終身雇用のせいで、これまでどおりでよいという人が多い
⑤ 日本ではイノベーション（新しい芽）はスカンクワークスでうまれてきた。最近は余裕がなくなって統制がきつくなり次の事業の芽となる新しいアイデアを育てにくくなっている
⑥ 短期間（例えば3か月）での成果がもとめられる時代だ。
⑦ 別の言葉で言えば、「遊ばしてくれない」。遊ぶことを会社が許さない
⑧ 日本人はトップダウンの管理にむいていない。ボットムアップだ
⑨ 日本人は改善はやれるがイノベーションはできない
⑩ 日本でＤＸをやるには、両利き（右利きと左利き）の組織構造をもつ必要があるという話があり、経営者の間で爆発的な人気がある。そのどちらかでＤＸをやることは可能か。無理だろう
⑪ 人間はなかなか変われないので、企業で業務内容を変更するためには、中の人間を入れ替えるしかない。ノキアが生き残っている理由は、従業員の99％の人間を入れ替えたからだ。
⑫ 古い企業は巨象の死ぬ道をたどるのでは、新しい事業は新しい会社がやる。
⑬ 楽天の真似は大企業にはできない
(1) 今後の予定　DXの日本の事例について調査してはどうか

システムオブシステムズ研究会（第12回）報告
報告者　落水浩一郎

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

記
１． 日時：2020年12月15日および12月17日　18:30～20:40
はじめての試みとして、（参加者を変え、）同じ内容を15日と17日の両日に報告・議論した
２．場所：オンラインZOOMミーティング
３． 出席者（アイウエオ順、敬称略）：
(1) 12月15日
日下部茂（長崎県立大）、栗田太郎（ソニー）、新谷勝利(新谷ITコンサルティング)、
富松篤典(電盛社)、奈良隆正（コンサル21世紀）、矢嶋健一（JTB）、
落水浩一郎（UIT，世話人）
(2) 12月17日
栗田太郎（ソニー）、艸薙匠（東芝）、瀬尾明志（日本ユニシス）、端山毅（NTTデータ）、方(ファン) 学芬 (SRA先端技術研究所) 、堀雅和（インテック）、落水浩一郎（UIT，世話人）
４． 議事（12月15日）：
(1) 18:30～19:30　講演
落水浩一郎(UIT)「デジタルトランスフォーメーション(DX)とマイクロサービス(MS)」
① マイクロサービスは、独自のライフサイクルをもつ、協調する細粒度サービスの利用を促進する分散システムである。
② 細粒度サービスは、境界づけられたコンテキスト（同じ意味で言葉を使う範囲）により定義される。
③ それぞれの細粒度サービスはビジネスドメインを中心にしてモデル化（ヘキサゴナル/オニオン/クリーン　アーキテクチャ）されるので、伝統的な階層アーキテクチャの問題を回避できる。
④ 細粒度サービスの開発と運用は、細粒度サービス毎に少人数のチーム（Two Pizza Team）が担当し、CI/CD(継続的統合と継続的デリバリー)をおこなう。
⑤ マイクロサービス群の協調は、軽量のメッセージキューを介した事象駆動型非同期通信によって達成される。アプリケーションをコンテナ化して実行する実行環境やその周辺ツール群であるDockerを利用することでクラウド上での実装が容易になる
⑥ 顧客重視、プロセスの自動化などを特徴とするデジタルトランスフォーメーションの実現においては、モバイル(as a タッチポイント)、IoT、ビッグデータ、AI、クラウドなどの要素技術を組み合わせることが重要である。
⑦ マイクロサービスは、デジタルトランスフォーメーション(DX)の実現手段の一つとして有望であり、とくに、サービスの連携と進化容易性を保証するものと思われる。
(2) 19:30～20:30　議論
① 最後のスライド、まとめの⑤（プロトコルなど）は誰またはどのチームが考えるのか（栗田）。Dockerなどのコンテナをつかうことが多い。今後の検討課題とする（落水）
② マイクロサービスは、個別自由にやるという思想なので、全体に風呂敷をかぶせる必要があるセキュリティとの相性が悪い（矢島）
③ DevopsとMSは関係があるのか（日下部）。ある（答え）
④ マイクロサービスでは、開発者＝ビジネスマンである必要がある（栗田、矢島）
⑤ AMAZONほど人材がそろってない会社で、MSを実施している例が知りたい（栗田）
⑥ Docker, Kubernetess等のMSの具体的インプリメンターションを勉強したくなった。一番のとっかかりは、bounded contextではないかと。これをもっと追求してみたい。Boundedがどのように認識され、実装の対象として切り出され、それらの非同期性を如何に制御するか？DockerとかKuberunenetisはこれらを容易にするものと考えるが、それらとMSの具体的な接点は？（新谷）
⑦ DXは経営者がリードするトップダウン型である必要があるといわれるが、日本ではトップはリードしないことが見られ、米国ではトランプのように独裁型が見られる。このような環境でbounded contextをどう管理、推進してゆくか、非常な関心がある（新谷）。
⑧ 16日に受けとった矢島さんからのコメント
DXを実現する技術要素の一つがMSで、そのMSは「個別自由にやるという思想」という印象を受けましたが、その印象は「DXは経営者がリードするトップダウン型である必要があるといわれる」というご指摘に、相反しているような気がしていました。DXにも二種類あると思います。
例示されていたUberやAirBnB、Gilt（会員制セールのサービスです）は、ソフトウェアにビジネスそのものをやらせており、それらの会社での仕事とは、売ったり買ったりではなく、ソフトウェア開発です。そこでは、少人数でどんどんソフト開発していかないと、競争に負けるので、MS化が進んでいます。これらのDXは、ソフトウェアに商売そのものをやらせ、ソフトウェア開発が仕事になっている、トランスフォーメーションです。このDXでは、MSは必要不可欠な要素技術で、親和性が高いと思います。モバイル、IoT、クラウドなども同様です。
巷で言われている(＝
に定義されているような）DXには、人やモノが担っていたことをソフトウェアにやらせることも含まれているような気がします。ここには、ソフトウェア開発は必ずしもいりません。これがもう一種類のDXです。このDXを推し進めるには、トップダウン型でなければなりません。というのは、人やモノが、それぞれのやり方でやっていたものを、一つのソフトウェアにするからです。
残念な事実は、どちらのDXにも、日本企業は苦労しているということです。前者は、ソフトウェアにビジネスをさせるという、新たなベンチャー的発想が生まれにくいこと、企業にソフトウェア開発を自らするという文化（能力）がない（端山さんがおっしゃっているように）ため、後者は、カルロス・ゴーンのようにトップダウンで進めていけていない（瀬尾さんがおっしゃっているように）ため、だと思います。
ソフトウェアにビジネスをさせるという発想や、企業が自らソフトウェア開発ができるようになるには、我が社のような100年企業では困難で、新しい企業が生まれて育っていかないと、ダメなような気がします。米国でも、そうではないでしょうか。そうなるためには、大学はとても重要な役割だと思います。学生人気は、メカ・エレキ＜＜＜＜＜ソフト、のようですし。
UberやAirBnB、GiltのようなDXには、MSは必要な技術で、MSの集合体も、SoSだと思います。
SoSの研究を深めていくために、MSは興味深いテーマであり、UberやAirBnB、Giltのような企業で取り組んでいるDXにも、MSやSoSを進めていくための課題解決策が隠れていると思います。
(3) 20:30～20:35　次回会合について
① 次回とは限らないが、MSとSoSは相性がよいので、今後も検討を続けたほうがよい（矢島）

５． 議事（12月17日）：
(1)18:30～19:30　講演 12月15日に同じ
(2) 19:30～20:45議論
① 1)マイクロサービスは、現代版のライブラリの設計・実装の技法なのか。クラウド上で、リソース制約がなくなったことを前提に、-ドメインモデリングに基づく設計、-保守性と拡張性の重視、-オーバーヘッドを気にしないプロセス間通信（コンテナ）など、高速なネットワークとCPU、大容量のメモリを利用して、設計、実装、配備の知的労力を軽減する取り組みに見える。2)マイクロと言いつつ、そこそこ大きい機能単位のようだ。3)社会全体として利用者数/システム数が増大したことにより、過去には流通しえなかった単位での再利用が可能になったのではないか。（端山）
② 1)ソフトウェアマイクロサービスは、あるソフトウェアプラットフォーム上で、簡便に、ビジネスモデルに従って開発し、利益を得たり、だめだったら破棄したりすることに意義がある。2)関係する技術は、OSSなり、プラットフォーム提供会社なりが、提供してくれる。それをうまく使いこなせれば良い。難しい技術の話は、任せれば良い。3)既存のシステムを、マイクロサービス化する意味は全くない。ぐちゃぐちゃを整理して、マイクロサービス化する意義はない。ぐちゃぐちゃならば、今あるものを全捨てして、EAを参考に、ちゃんとシステムを作る。しかしその時APIを解放して、そのシステム上で、マイクロサービスが走るように作れ！10年ぐらいでまたマイクロサービスだらけになったら、全てを捨てて、またEAで、ちゃんとシステムを作れ！（艸薙）
③ 小さいサービスを組み上げてアプリを作る。それぞれのサービスはDeploy可能というところにMSの一つの特徴がある（方）。マイクロサービスについて、最初知ったのは、クラウド、コンテナ環境と関わりの中からです。その中で言われているマイクロサービスは、小さな独立した複数のサービスを組み合わせて一つのシステムを開発する手法はマイクロサービスアーキテクチャとなる。複雑なシステムを小さく分けるといままでの考え方と変りがないですが、分け方として、一つのビジネスの機能をサービスとして、そのサービスは他のサービスの機能に影響を与えることなく開発、デプロイ、実行、スケールする。各サービスは他のサービスとコードまたは実装を共有する必要が一切しないこと。実際のシステムでそんなようなサービスに分解できるか？　かなり難しいと思います。各サービスは正確に定義されたAPIを通じてやりとりできても。システム全体としてうまく統合できるかがよくわかりません。（方）
６． 今後の予定
(1) MSの話を続ける場合は話題を絞って検討したほうがよい（栗田）
(2) つぎの話題をしては、・モノリスからマイクロサービスへの移行法など、いろいろと調べるべきことがあるが、MSの適用領域、有効性、実施上の問題点などを把握するため、MSの事例について調査してみたい（落水）。

システムオブシステムズ研究会（第1１回）報告
報告者　落水浩一郎

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

記

１．日時：2020年11月18日　18:30～20:40
２．場所：オンラインZOOMミーティング
３． 出席者（アイウエオ順、敬称略）：日下部茂（長崎県立大）、艸薙匠（東芝）、栗田太郎（ソニー）、新谷勝利(新谷ITコンサルティング)、瀬尾明志（日本ユニシス）、富松篤典(電盛社)、奈良隆正（コンサル21世紀）、方(ファン) 学芬 (SRA先端技術研究所) 、Huyen Phan Thi Thanh（日立）、堀雅和（インテック）、矢嶋健一（JTB）、落水浩一郎（UIT，世話人）
４． 議事：
(1) 18:15～18:30　接続準備・挨拶他
(2) 18:30～19:30　講演 落水浩一郎(UIT)「VSM(Viable System Model)に基づいたプロジェクト管理システムのSoSへの適用」
複雑系のシステムに対するプロジェクト管理システムの設計、適用例を紹介した。
従来のプロジェクト管理は、まず計画をたて、その進捗を監視し、計画とはずれるところがあれば調整する。プロジェクトが失敗した場合は、その原因を追究し、次回以降の計画に反映させるというものであった。
複雑系システム開発の場合は、確率的、動的、創発的特性のため、不十分かつ部分的な計画しかたてられないので、上記のプロジェクト管理技法ではうまくいかず、環境のスキャニング、内部監視に基づいて、動的安定性の維持を目標としたプロジェクト管理が必要であるとする。
上記の立場から、VSM(Viable System Model)に基づいて設計されたプロジェクト管理システムをSoSに適用した例を紹介し、複雑系のシステムを開発する際、どのようなプロジェクト管理手法をどのように適用すればよいかという問題に関して理解を深めた。得られた結果は、用語の統一、利害関係者のものの見方/考え方の違いの調整など、ごく常識的（平凡）な知見であった。

(3) 19:30～20:30　議論
① 今回紹介した論文で対象としている複雑系のシステムは、われわれの世界（情報システム）に現実に存在するのか？
 ソフトウェアシステムの場合、結果的に複雑になるにせよ、最初から複雑になるわけではない。作るときはシンプルを心がけている（富松さん他、多くの参加者の意見）。
② 環境のスキャニング・内部監視に基づいて動的安定性の維持を保つというプロジェクト管理法は危険ではないか？
 状況がかわるのを管理するということの必要性はある。例えば携帯の開発では、アジャイル開発を行い、ユーザとともにシステムを進化させていくことを心がけている（栗田さん他、多くの参加者の意見）。
③ 複雑系システム、動的安定性の維持を目標としたプロジェクト管理、その理論的背景としてのVSMモデルをどう評価するか
 作り話であるような気がする（多くの参加者の意見）。
 アジャイルスクラムの理論的背景をVSMをもとに作れないか

(4) 20:30～20:35　次回会合について

５． 今後の予定
第12回：SoSとマイクロサービス（落水予定）

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

報告者　落水浩一郎

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

記

１．日時：2019年11月18日　18:30～20:40

２．場所：ソニーシティ大崎　会議室　〒141-0032 東京都品川区大崎２丁目１０−１

• 出席者（順不同）：日下部　茂（長崎県立大,
  Zoomによる参加）、艸薙匠（東芝）、栗田太郎（ソニー）、斎藤善治（IPA）、瀬尾明志（日本ユニシス）、端山毅（NTTデータ）、方(ファン) 学芬 (SRA先端技術研究所) 、矢嶋健一（JTB）、落水浩一郎（UIT，世話人)，
• 議事：

18:30～20:40　「システムズエンジニアリング体験ワークショップ紹介」、端山毅氏(NTTデータ)　

ワークショップの目的：　製品／サービスに対する期待や要請が高度化、複雑化し、システムを企画開発する上で検討すべき範囲が広がる状況に対して、システムズエンジニアリングがどのような考え方やアプローチを提起しているか、特に上流部分に重点を置き、事例や演習を通じて体感して頂くことを目指す。

• 狙い　システムズエンジニアリングを体験する（具体的には、ビジネスレベルの困りごとを分析し解決する手法をトレーニングする）。

IPA（端山氏、斎藤氏グループ）が推奨するシステムズエンジニアリング活動

• 目的指向と全体範囲
• 多様な専門分野を統合
• 抽象化・モデル化
• 反復による発見と進化
• 必要性　環境の変化に伴う新しい状況への対応能力を養成する必要がある。たたきあげの人材の出現を待っていては間に合わない。
• 対象　経営者、IoT技術者、ソフトウェアエンジニアたちの再教育
• 事例　居酒屋チェーンのクレーム対策としてカメラを設置する。「電子お薬手帳」の例もある
• 進め方　事例によるワークショップ形式。

趣向の異なる居酒屋を5種類設定（想定されるクレームが違う）。

５チームそれぞれが異なる客層、内装、料理などを想定して演習を進める。

郷土料理が売りだったり、ステージとかスクリーンがあったり、

方言や外国語が飛び交ったり、子供が騒ぎ出すとか、

といった話で盛り上がってもらいます。

隣のチームとは違うシステムになっても、それはそれでOK.

• システムズエンジニアリングの解説　　　 60分
• 事例によるワークショップの進め方説明　 20分
• チーム編成、課題の説明、付帯条件選択　 20分
• グループ演習　　　　　　　　　　　　　150分
  • ビジネスあるいはミッションの分析
  • 利害関係者ニーズと要求事項の定義
  • システムの要求事項の定義
• 発表　　　　　　　　　　　　　　　　 　20分
• 手法やツール　自然語、図、討論
• 質疑
  • ねらいや対象は何か？システム分析設計手法は昔から教育されており、またそれなりのエキスパートも数多く存在するのではないか？（落水）
  • IoTなど世の中の環境の急激で大きな変化に伴う新しい状況への対応能力を養成する必要がある。この分野でのたたきあげ人材の出現を待っていては間に合わない。経営者、IoT技術者、ソフトウェアエンジニアたちを対象に、ねらいは彼らの再教育である。システムズエンジニアリングの理論に裏打ちされた、ビジネスレベルの困りごとを分析し解決する手法をトレーニングする（端山、斎藤）
  • 昔の教育は現場経験に基づく、パワハラによるたたき上げ教育であったが、システムズエンジニアリングの理論に裏打ちされた教育手段を整備したところが評価できる（艸薙）
  • システムズエンジニアリングの理論とは何か？（落水）
  • 「目的指向と全体範囲」、「多様な専門分野を統合」、「抽象化・モデル化」、「反復による発見と進化」である（端山、斎藤）
  • このような教育を大学生にも実施できるか（日下部）
  • 東工大で4人の学生を対象に実施した経験がある。結果はそれなりであった（端山）
  • 手法やツールはどのようなものを採用しているのか？（日下部）
  • 自然語による討論である（端山）
  • 学生などへの教育を考えた場合、議論を誘発するような図式言語などがあった方がよいのではないか（落水）
  • 手法の最初の部分と後半の部分は、日本では、契約上、SIerの担当範囲外になっていることが多い(瀬尾)
  • ソフトウェアシンポジウムのワーキングで実施してみてはどうか（落水）
  • 賛同する。（端山）
• 今後の予定

第11回：VSM(Viable System Model)に基づいたプロジェクト管理システムのSoSへの適用（落水）

第12回：SoSとマイクロサービス（落水予定）

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

報告者　瀬尾明志

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

記

１．日時：2019年9月9日　18:30～21:00

２．場所：ソニーシティ大崎　会議室　〒141-0032 東京都品川区大崎２丁目１０−１

• 出席者（順不同）：小笠原秀人（千葉工大）、艸薙匠（東芝）、栗田太郎（ソニー）、新谷勝利

(新谷ITコンサルティング) 、瀬尾明志（日本ユニシス）、端山毅（NTTデータ）、

方(ファン) 学芬 (SRA先端技術研究所) 、矢嶋健一（JTB）、落水浩一郎（UIT，世話人)，

• 議事：

18:30～21:00　講演「深センでのイノベーション活動の実態」瀬尾明志 氏(日本ユニシス)

• 講演の本題である深セン視察の話題に入る前に、なぜ深センを視察したのかについて説明があった。講演者の瀬尾氏は、所属企業において、長く技術経営を担当し、海外のテクノロジービジネスの動向をリサーチする立場にあり、その業務の一環として、今年１月に深センを視察したとのことであった。ITサービス企業における技術経営は、メーカーが製品ロードマップを描く（テクノロジーアウト的）のとは異なり、マーケット（顧客）を見て、どのようなテクノロジーを、どのタイミングで、どのような立ち位置で、どのような技術レベルで、提供できるようにしていくかが重要であるとのこと。
  • リサーチ会社IDCが提唱する第１～第３のプラットフォームの変化を用いて、IT業界の変遷の説明があった。第１のプラットフォーム（メインフレーム）：IBMなどによる自社で研究開発を行った時代、第２のプラットフォーム（オープンシステム）：HPやOracleによる企業買収により事業・企業を拡大していった時代、そして現在、第３のプラットフォーム（クラウドやビッグデータ）：Amazon、Microsoft、Googleがすべてのテクノロジーを提供する時代に移りつつある。
  • 現在のIT業界の構造は、(1)メガクラウド事業者、(2)メガクラウド事業者になり切れていないメーカー、(3)メーカー、(4)ITサービス専門業者、(5)アプリケーションやSaaSの専門業者の5に分類できる。日本のIT企業のほとんどは(4)である。(4)では、コンサルティング企業の躍進が目立つ。
  • 広東省 深センは、40年前、貧しい小さな漁村だったが、経済特区に指定され、急速に発展（特に最近）。香港に近く、1月でも暖かい。面積は東京都と同じくらいだが、人口は東京より多い1400万人。地下鉄が11路線あり、交通インフラも整っている。環境対策に力を入れていて、バスやタクシーはほとんど電気自動車であり、緑や花が多く植樹されている。街が新しいので、中心部は新しいビルが多く、若い人が多い。
  • YouTube動画や写真を使って、深センの町の様子、秋葉原の何十倍もの規模の電気街、自動決済できる無人コンビニ、放置されるシェア自転車、ネットとリアルが融合したスーパーマーケットなどの紹介があった。
  • 深センは「ハードウェアのシリコンバレー」と言われ、「深センの1週間はシリコンバレーの1カ月」とも言われる。そのスピードを実現するための、ハードを開発する会社、スマホアプリを開発する会社、全体をコーディネートする人、国際特許をとる会社、などなど高速に新製品をローンチしていくためのエコシステムが整っている。
  • 深センには、ビジネスモデル上検討が不十分、システムの仕様上検討が不十分、安全性の対策が不十分、製造品質が不十分な状態でのチャレンジを許容する風土がある。そのような状態で実証的な本番をどんどんしていき、ダメなものは、どんどん淘汰されていく。製品やサービスの新陳代謝が段違いで早いのである。
  • 中国には、アメリカのGAFAに対応するテクノロジー企業BATHがある（Google≒バイドゥ、Amazon≒アリババ、Facebook≒テンセント、Apple≒ファーウェイ）。深センにはBATHのうちTとHの本社があり、BとAも重要拠点を置いている。iPhoneの製造メーカーである台湾のホンハイ（フォックスコン）の大規模工場もある。
  • 多くの深センのスタートアップ企業に共通した特徴はマネタイズしないことである。それらの企業はBATに買ってもらうことを目標としているので、マネタイズする必要がない。BATは南山区（深セン中心部）あたりのスタートアップを争うように買っている。
  • 深センにはBATHがあるため、優秀な人材が集まっていて、テンセントなどは日本の給与水準を上回っている。米国の大学を卒業したり、米国企業での勤務経験のある人が中国に戻ってくる海亀族も多い。
  • あらゆることがスマホでサービスされている。家電などの製品にも、サービスにも、レストランなどの店にもスマホアプリが用意されている。QRコード決済はどこでも利用できる。出張中、現金を持たずに、アリペイやWeChatペイだけで過ごすことが可能である。
  • テンセントはユーザ数10億人のWeChat（LINEのようなアプリ）の上で動くミニプログラムという仕組みを2018年にリリースした。ミニプログラムはスマホネイティブのアプリより開発が簡単で、とても広く使われている。それぞれの店が自分の店のミニプログラムを作っている。
  • 今の中国製品は性能も品質もデザインもアップルに引けを取らないレベルになっている。シャオミは多くの家電をシャオミブランドで出していて、どれもセンスが良い。ファーウェイのスマホはサムスンの最新スマホやiPhone XSと比べて、性能もデザインも質感も負けていない。
  • 中国でスタートアップの企業数やユニコーン企業数が一番多いのは、実は北京の中関村というところである。アカデミックな北京、マイクロソフトなど米国系が多い上海、自由な雰囲気の深セン。それぞれの主要都市に特色があり、中国全体でバランスが取れている。
• 今後の予定

第10回：「システムズエンジニアリング体験ワークショップ紹介」、端山毅氏(NTTデータ)　

IPAが作成したシステムズエンジニアリングの概要紹介とグループ演習の資材について説明する。製品／サービスに対する期待や要請が高度化、複雑化し、システムを企画開発する上で検討すべき範囲が広がる状況に対して、システムズエンジニアリングがどのような考え方やアプローチを提起しているか、特に上流部分に重点を置き、事例や演習を通じて体感して頂くことを目指す。

第11回：VMSに基づいたプロジェクト管理システムのSoSへの適用（落水予定）

第12回：SoSとマイクロサービス（落水予定）

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

世話人　落水浩一郎

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

記

日時：2019年8月2日　18:30～21:00

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

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

• 出席者（順不同）：小笠原　秀人（千葉工大）、艸薙　匠（東芝）、栗田　太郎（ソニー）、瀬尾　明志（日本ユニシス）、奈良　隆正（コンサル21世紀）、方(ファン) 学芬 (SRA先端技術研究所) 、堀雅和（インテック）、矢嶋　健一（JTB）、落水　浩一郎（UIT，世話人)，

議事：

• 18:30～20:20　講演　情報セキュリティ技術の内外の動向

栗田　太郎 (ソニー)

• 1984年から毎年開催されている「暗号と情報セキュリティシンポジウム（SCIS）」の2019年度（800名以上の参加者、300件以上の発表）の会議録をもとに情報セキュリティ技術の動向について講師より紹介・解説があり、下記のそれぞれの話題について質疑・討論を進めながら、内容についての理解を深めた。
  • CC（コモンクライテリア、ISO/IEC15408）とは、情報技術セキュリティの観点から、情報技術に関連した製品及びシステムが適切に設計され（セキュリティ機能要件）、その設計が正しく実装されている（セキュリティ保証要件）ことを評価するための国際標準規格である。CC認証とも呼ばれる。評価保証レベル（EAL ：Evaluation
    Assurance Level）が規定されており、実装の確かさの評価方法についてのレベル付けが決められている。以下に大まかな分類を示す。EAL1～3：一般民生用,EAL4：政府機関向け,EAL5～7：軍用レベルほか、政府最高機密機関レベル向け（例えば、EAL７は形式的検証済み設計およびテストが必要である）。
  • サイドチャネル攻撃（side-channel
    attack）とは、暗号装置の動作状況を様々な物理的手段で観察することにより、装置内部のセンシティブな情報を取得しようとする攻撃（暗号解読）方法の総称である　（差分）電力解析攻撃、故障利用攻撃、電磁波解析攻撃、音響解析攻撃、キャッシュ攻撃などの攻撃手段がある。たとえば、暗号機能付きのICカードなどのように攻撃者が処理時間や消費電力を精密に測定できる場合には、平文や暗号文だけではなく、これらのサイドチャネルから漏洩する情報も考慮することが必要である
  • Adversarial Exampleとは、深層学習（分類器）に対する脆弱性攻撃のことである。分類器が正しく分類できていた画像に、人の目では判別できない程度のノイズをのせることで、作為的に分類器の判断を誤らせることができる。
  • GAN（敵対的生成ネットワーク、Generative
    Adversarial Network ）は、AI、特にディープラーニング、の進化にとってきわめて大きな障害となる「膨大な手作業の必要性」を解消するものである。通常、ニューラル
    ネットワークは、たとえば猫の写真を認識するための学習を行う場合、何万枚もの猫の写真を分析することになる。しかし、それらの写真をネットワークのトレーニングに使うためには、各画像に写っているものに人が慎重にラベルを付けていく必要があり、時間とコストがかかってしまう。GAN は、ディープラーニング
    アルゴリズムのトレーニングを行うのに必要なデータの量を削減することで、この問題を回避する。そして、既存のデータからラベル付きのデータ (ほとんどの場合は画像) が作成されるように、ディープラーニング アルゴリズムに対する独自のトレーニング手段をもたらす。研究者は、単一のニューラル
    ネットワークが写真を認識できるようにするためのトレーニングではなく、２つの競合するネットワークのトレーニングを行う。前述の猫の例でいうと、まず、生成ネットワークが本物の猫のように見える偽物の猫の画像を作成しようとする。次に、識別ネットワークがそれらの猫の写真を調べて、本物かどうかを判別しようとする。この競合する ２つのネットワークは、互いに学習を行う。たとえば、一方が偽物の画像を見つけ出す能力を高めようとするなら、もう一方はオリジナルと見分けがつかない偽物を作成する能力を高めようとするわけである。
  • GDPR（一般データ保護規則、General Data
    Protection Regulation） EU一般データ保護規則とは、欧州議会・欧州理事会および欧州委員会が欧州連合 (EU) 内の全ての個人のためにデータ保護を強化し統合することを意図している規則である。欧州連合域外への個人情報の輸出も対象としている。EU一般データ保護規則の第一の目的は、市民と居住者が自分の個人データをコントロールする権利を取り戻すこと、および、欧州連合域内の規則を統合することで、国際的なビジネスのための規制環境を簡潔にすることである。2019年8月8日の讀賣新聞の記事によると、GDPRに関して以下のような問題が発生している。2019年1月に、日本はEUから個人情報水準のお墨付き「十分性認定」を獲得した。実は、認定の対象は民間企業だけで、大学や独立行政法人は対象外となっている。このような事態が発生した背景には、民間と公的部門で監督権限が異なる日本の個人情報保護法制の「バラバラ問題」がある。例えば、自然科学研究機構（国立天文台、核融合科学研究所、生理学研究所などを有する大学利用機関法人）は2019年4月にも、世界の8つの電波望遠鏡をつなぎあわせてブラックホールの撮影に成功するなど、様々な国際共同研究を展開している。当然、欧州の研究機関との間で個人データをやりとりする機会も多い。ところが、EUのGDPRでは、EU域外に個人データを移転させることは原則禁止。移転するには、本人の明確な同意取得や個別の契約締結など特別な対応が必要で、膨大な手間と費用がかかる。違反すれば、2000万ユーロ（約24億円）または年間売り上げの4％の制裁金を科される恐れもあり、現地の研究者の人事情報や国際シンポジウムの参加者リスト、脳画像や遺伝情報などの研究データを共有するにも不安が募る。産官学共同の国際プロジェクトへの影響が心配されている。今後日本全体で十分性認定を獲得する上でカギとなるのが、来年にせまる個人情報保護法改正だ。分野ごとにバラバラの法制度に懸念が示されている。一日も早く世界水準を満たす保護法制を作り、企業のグローバルな活動を支えて欲しい。
  • ビッグデータ活用の前提条件として、ビッグデータの匿名化技術が必要である。k匿名性技術などは代表的なものである。
  • 現在の暗号技術は量子コンピュータの出現により、早ければ10年後に破られる可能性があり、耐量子暗号、格子暗号などの新しい暗号化技術が出現している。以下は、草川恵太氏（NTTセキュアプラットフォーム研究所）「耐量子暗号技術の研究動向」よりの引用である。

「公開鍵暗号 やデジタル署名の中でも現在広く使われているのが，素因数分解問題の困難性に基づく暗号アルゴリズム（RSA 暗号，RSA署名など）や離散対数問題の困難性に基づく暗号アルゴリズム （Diffie-Hellman鍵交換，楕円曲線 Diffie-Hellman鍵共有，DSAなど）です。大規模かつ安定して計算が行えるような量子コンピュータが完成すると，現在広く用いられている暗号アルゴリズムは安全でなくなります。公開鍵暗号技術の中でも，量子コンピュータが苦手とすると考えられている問題を基に暗号アルゴリズムが設計されているものを，耐量子公開鍵暗号技術と呼びます」

　　　　格子暗号などがある。

• 量子アニーリングは「組合せ最適化処理」を高速かつ高精度に実行すると期待されている計算技術である。1998年に東京工業大学の門脇正史氏と西森秀稔氏によって提案され、2011年に量子アニーリングを実行する商用ハードウェアD-Waveが発表された。現在ではいくつかの企業が利用し、量子アニーリングの活用シーンを探索している。
  • メルセンヌ・ツイスタ (Mersenne twister、通称MT) は擬似乱数列生成器 (PRNG) の1つである。1996年に国際会議で発表されたもので（1998年1月に論文掲載）松本眞と西村拓士による。既存の疑似乱数列生成手法にある多くの欠点が無く、高品質の疑似乱数列を高速に生成できる。考案者らによる実装が修正BSDライセンスで公開されている。2¹⁹⁹³⁷-1 という長い周期が証明されている。この周期は、名前の由来にもなっているように メルセンヌ素数であり
  • （瀬尾さんコメント）現在、大変重要な問題であるにも関わらず、SCISにランサムウェアに関する研究がないのは、技術的にはどうしようもないからであろうか
  • セブンペイ問題も話題に上った。問題発生の本質は企業統治（ガバナンス）にあるとの意見が公開されたが、2019年8月10日読売新聞の記事によると以下の通りである。セブンペイはもともと、スマホ専用に独立した決済アプリとして2018年2月に開発が開始された。だが、同年末、急きょ、大幅な仕様変更があった。2018年6月に始まったセブン－イレブン・ジャパンの「セブン－イレブンアプリ」が利用者を増やしたため、同アプリの一つの機能として組み込むよう方針転換した。同アプリやグループ全体のネット通販サイト「オムニ７」なども含めた共通のID「セブンID」を利用することにし、その過程で、「2段階認証」の仕組みは導入されなかった。その結果、過去に流出したIDやパスワードを悪用する「リスト型攻撃」を外部から受けやすい状況になった。安全対策より利用者の拡大を優先したため、2段階認証には対応しきれなかった。セブンIDが決済向けに安全対策を講じていなかったことも、今回の不正アクセスを招いた可能性がある。デジタル戦略担当の副社長は記者会見で、「セキュリティというのは経営と切り離せない」と強調した。セブン＆アイは自前のシステムにこだわったものの、経営陣にITに精通する役員を置いていなかった。
• 20:55～21:00　 今後の予定を以下のように決定した。
  • 第9回：瀬尾さん「最近の中国、特に深センでのイノベーション活動の実態」
  • 第10回：NTTデータ端山毅さん
  • 第11回：SoSとマイクロサービス（落水予定）

システムオブシステムズ研究会（第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日確認

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