disaster management on seamless positioning system8 march 2011 [email protected]...

[email protected] March 2011

生きた要求を捕まえる

生きた要求を捕まえる～ＨＴＶ（こうのとり）の開発を通じて学んだこと～

慶応義塾大学大学院

システムデザイン•マネジメント研究科

白坂成功

[email protected]

第5回要求シンポジウム


生きた要求を捕まえる 2

HTV1の紹介



Contents

1.

はじめに–

自己紹介

–

今日伝えたいこと

–

SDM紹介

2.

HTV（こうのとり）の経験

3.

最近のシステムエンジニアリングでの話題

4.

まとめ

3

©NASA



１．はじめに：自己紹介

•

1994年

大学院修士課程修了（航空宇宙工学専攻）

•

1994年

大手電機メーカ入社

人工衛星開発に従事（１５年間）

•

おりひめひこぼし（技術試験衛星VII型）の運用設備の開発、運用メンバー

•

ランデブードッキング試験設備の開発

•

宇宙ステーション輸送機（HTV:H-II Transfer Vehicle）のシステム設計、運

用システムの設計、運用メンバー

•

ドイツAstrium社に駐在（ESAの衛星システムシミュレータ開発）

•

準天頂衛星システム、総合システム開発のプロジェクト管理、システム設計

•

2004年より慶応義塾大学非常勤講師、2010年4月より慶応大学専任准教授



１．はじめに：今日伝えたいこと

•

表面上にとらわれず、本質・根本を考える必要がある–

表面を追いかけるから逃げられる。根本を抑えると逃げられない。

•

Holistic（全体的に）考える必要がある–

一部をみるから、影響を受ける。全体をみておけば、変化は小さい。

–

それでもContext（取り巻く環境）の変化は常にある・・・・

5



１．はじめに：慶応SDM

•

新しく大きな構想を描き、世界をリードしていける人材の育成

•

Vモデルを活用

•

多様な視点からの問題解決–

木を見て、森も見る

•

http://www.sdm.keio.ac.jp/

6




•

多様な学生のメルティングポット

7

平均年齢32歳就業経験：34％

修士

平均年齢42歳就業経験：89％

博士

Manufacturing, 19.6

Communications, 11.2

Consulting, 10.3

Informaton Technology,

9.3

Aerospace, 6.5

Finance, 4.7

Real Estate, 3.7

Government, 3.7

Construction, 3.7

Enegy, 3.7

System, 2.8

Medical, 1.9 Publishing/Med

ia, 1.9

Legal, 1.9 Logistics, 1.9

Teacher, 1.9

Education, 1.9 Material, 1.9

Design, 1.9 Civil

Servant, 1.9

Sports, 0.9 Translation, 0.9 Food, 0.9 Pharmaceutical, 0.9

(%)

多様なバックグラウンド

留学生20%、年々増加中




1.

はじめに

2.

HTV（こうのとり）の経験–

HTVについて

–

フライトセグメント開発より

–

グランドセグメント開発より

3.

最近のシステムエンジニアリングでの話題

4.

まとめ

8

©NASA



Seiko Shirasaka

2．HTV（こうのとり）の経験：HTVについて

9

© JAXA (HTV1Press Kitより)

全長：約9.8m直径：約4.4m総質量：最大16.5ton補給能力：最大6ton



2．HTV（こうのとり）の経験：フライトセグメント開発より

①コンピュータ安全性設計

• 通常の衛星：宇宙には人がいないため、射場での安全性のみ考慮

• スペースシャトル時代：最後は宇宙飛行士が操作可能• 宇宙ステーション時代：巨大な宇宙ステーションを数

名の宇宙飛行士ですべて切り盛りするのは困難。コンピュータに頼らざるを得ない

• HTVの場合、常に人が監視できるわけではない。→人には頼れない

背景




①コンピュータ安全

NASAの新要求• コンピュータ安全要求

コンピュータを安全管理に使う場合の要求

文字をそのまま追っているだけでは何をやればいいのかわからない・・・

「哲学書」





• 経験者（「きぼう」の開発者）に教えを請う。• 表面的には納得して、NASAと交渉

コンピュータシステムが安全になるにはどうすればいいのか？それを実現するために作られた要求である！

「これなら安全になるはず」と考えたものをベースに、要求の解釈・設計方針をNASAに説明し、合意を得る





どこにも書かれてない要求を後から指摘される（Common

Mode

Failure）

「安全」に対する本質的要求は変わっていない。しかし、何が良くて、何が悪いかという評価クライテリア

が変化した。（明確になった？）

NASAもシャトル開発、ソユーズの運用経験に加え、ATV

（欧州版HTV）の開発を通じて知見を得たのでは？つまり、要求を出す側のContextが変化してしまった。

（「

HTVの安全設計と安全審査の実際」、WOCS2009 中村、白坂より）



2．HTV（こうのとり）の経験：グランドセグメント開発より

②分散シミュレーションシステム

背景• どれほど難しい運用になるか、やってみないとわから

ない。（NASAもやったことがない、まして・・・）→こういう運用でいいだろうという想定で開発

• なるべく実際に近い形で運用訓練をやりたい

高精度なHTVシ

ミュレータ

高精度なHTVシ

ミュレータ高精度なISS

シミュレータ

高精度なISS

シミュレータ

データ交換による協調動作

分散シミュレーションシステムの構築

（「三菱電機における宇宙用クリティカルソフトウェア開発への取り組み」WOCS2002 白坂より）





高精度なHTVシ

ミュレータ

高精度なHTVシ

ミュレータ高精度な ISS

シミュレータ

高精度な ISS

シミュレータ

データ交換による協調動作

NASAミッション

コントロールセンタ（「三菱電機における宇宙用クリティカルソフトウェア開発への取り組み」WOCS2002 白坂より）

©JAXA

©NASA





Step2-1Step2-1A

Step2-2 Pre-Step3 RiskMitigation

Step1Step0

FeasibilityStudy

Step3

SystemIntegration

• 何ができるかわからない- Feasibility

Studyを通じたEvolutional

Model

• その後はRisk

Mitigation：Incremental

Model

実際に訓練を行ってみると、運用

が難しいところが発見され、搭載

ソフトウェアの要求を変更して改

修を実施

HTVフライトセグメントだけでなく、

運用、NASAまで含めた要求の検討

が必要



Seiko Shirasaka

2．HTV（こうのとり）の経験の経験を通じて感じたこと・・

•



•



–


17

表面的な安全要求に適合することより、本当に安全とはどういうことかを考えることが大切だった

自分の担当範囲外の変化が間接的に自分に影響される。NASA自身の開発経験・運用経験の変化が、HTV

のフライトセグメントの要求変化となる



HTV2の紹介



1.

はじめに

2.

HTV（こうのとり）の経験

3.

最近のシステムエンジニアリングでの話題–

視点

–

シリーズとファミリー

–

"７人の侍"

4.

まとめ

19

©NASA



3．最近のシステムエンジニアリングでの話題：視点

•

システムは視点によって違って見えるので、多視点から見る必要がある。（IEEE1471)

20

日経ものづくり2010年10月号より

•

視点だけでなく、範囲（Scope）と分解能（Resolution）によって見え方が変わる。




•

既存の視点：アーキテクチャフレームワークとして、存在

21

•

DoD

Architecture Framework (DoDAF)

•

C4ISR Architecture Framework (C4ISRAF)

•

Federal Enterprise Architecture Framework (FEAF)

•

Air Force Enterprise Architecture Framework (AF-EAF)

•

Zachman

Architecture Framework (ZAF)

•

The Open Group Architecture Framework (TOGAF)

•

経産省Enterprise Architecture

適用範囲を限ることで、その適応ドメインにあった視点を用意システム開発を助ける。但し、適用範囲から外れると使えない。



•

Zachman

Architecture Framework

DATA FUNCTION NETWORK PEOPLE TIME MOTIVATION

SCOPE

ENTERPRISE MODEL

SYSTEM MODEL

TECHNOLOGY MODEL

COMPONENTS

What How Where Who When Why

22

５つの視点




3．最近のシステムエンジニアリングでの話題：視点経産省

Enterprise Architecture Framework

政策・業務体系（Business Architecture）

データ体系（Data Architecture）

適用処理体系（Applications Architecture）

技術体系（Technology Architecture）

Standards（データモデル、セキュリティ要件などの標準を策定）

As Is

BusinessArchitecture

DataArchitecture

ApplicationsArchitecture

TechnologyArchitecture

To Be


DataArchitecture



Transitional Processes（業務、システムなどの移行管理計画を策定）

現状（ＡｓＩｓ）モデル

理想（ToBe）モデル

次期モデル

政策・業務体系（Business Architecture）

データ体系（Data Architecture）

適用処理体系（Applications Architecture）

技術体系（Technology Architecture）

Standards（データモデル、セキュリティ要件などの標準を策定）

As Is


DataArchitecture



To Be


DataArchitecture



Transitional Processes（業務、システムなどの移行管理計画を策定）

現状（ＡｓＩｓ）モデル

理想（ToBe）モデル

次期モデル

23

４つの視点




Capability Viewpoint

Operational Viewpoint

Services Viewpoint

Systems Viewpoint

Projects V

iewpoint

Standards V

iewpoint

Data &

Information

View

point

All V

iewpoint

4 “Views” 8 “Viewpoints”

26 “Products” 52 “Models”Added Project & Capability Viewpoints (from MODAF)Added Service Viewpoints (from NATO)

24

DoDAF2.0




25

IEEE1471-2000 Recommended practice for architectural description of software-intensive systems




•

要求はどのような視点で見るのか？

•

上流？

•

超上流？

26

保険金の支払い漏れが発生しないための情報システムの要求は？



3．最近のシステムエンジニアリングでの話題：視点システムの目的

（主目的）

•

顧客が保険金を正しく受け取る

（副目的）

•

査定不服時の請求

•

経営陣による内部管理

•

苦情のくみ上げ

•

内部監査の実施

27




視点の構成

行動促進

目的

行動

モチベーション規則

EnablerUtilize

Utilize Enabler

契約者が正しく保険金を

受け取る

「モチベーション」は人々

が自発的に行動すること

を促す

「規則」は人々が行動を起

こすことを強要する。

行動確認

行動／行動確認支援

Utilize行動

28



行動促進の視点

規則の視点モチベーションの視点

行動確認の視点

目的の視点

行動の視点

行動・行動確認支援の視点

“行動”は目的からブ

レークダウンされる（縦

の関係）

“行動確認”は“行動”に対応し、

目的からブレークダウンされて

いるわけではない（横の関係）

“強制”と“自発”は行動からブレークダ

ウンされる。（縦の関係）相互に関連

している。（横の関係）

“行動行動確認支援”は“行動”と

“行動確認”からブレークダウンさ

れる。（縦の関係）

29




3．最近のシステムエンジニアリングでの話題：シリーズとファミリー

•

今見ている範囲はどこか？

30



3．最近のシステムエンジニアリングでの話題： "７人の侍"

32

“The Seven Samurai of Systems Engineering Dealing with the Complexity of 7 Interrelated Systems”By James Martin



4．まとめ

•



•



–


33

表面的な要求を追いかけるのではなく、本当に必要なのことは何かを考える。（視点）

全体的に見る（シリーズ、ファミリー）。それでもわからないこともあると想定して対処する。（”7人の侍”）

Lenovo、JAXA、NASA、その他記載されている会社名、団体名、

商品名、サービス名等は、各社、各団体の商標または登録商標です。

disaster management on seamless positioning system8 march 2011 [email protected]...

Documents