Slide 1

Slide 1 text

宇宙開発のプロフェッショナル によるSE/PM研修 複雑な製品開発を成功に導く

Slide 2

Slide 2 text

images from: nasa.gov アポロはなぜ⽉に⾏けたのか? 百万点以上の部品、 何百万⾏というソフトウェアコード、 40万⼈にもおよぶプロジェクト関係者

Slide 3

Slide 3 text

アポロ計画をなど、宇宙‧航空などの分野の中で培われてきた 複雑だけど価値あるものを実現するためのベストプラクティス 特に重要なことが、 ● 単⼀の専⾨的な視点ではなく、 システムの幅広い横断的な視点を扱うこと ● 横断的な視点を持って全体像を描くことで、 正しく設計できているだけでなく、 正しいシステムを作れていることを確認する NASAのプロジェクト成功の秘訣 出典: NASA systems engineering handbook 3 プロフェッショナルな協働を⽀える技術 システムズエンジニアリング(SE)

Slide 4

Slide 4 text

システムズエンジニアリングの導⼊効果 1. QCDを満⾜できるシステム開発ができる 2. ⾼付加価値の製品を⽣み出せる 3. 全体像を描き、臨機応変に適切な判断ができる⼈材が育つ 品質(Q) コスト(C) 納期(D) 品 質 を 上 げ る た め に は ス ケ ジ ュ ー ル が 必 要 品 質 を 上 げ る た め に は コ ス ト が 上 昇 スケジュールを短縮するためには コストが上昇 Customer Value Human Capital Global Optima 4

Slide 5

Slide 5 text

システムズエンジニアリングの基本プロセス システム要求の明確化 アーキテクチャ設計 構成要素の設計‧製造と検証 システムインテグレーションと検証 (注)検証:与えられた要求を満⾜していることを確認する⾏為(図⾯確認、解析、検査、試験等を組合せて実施) 5

Slide 6

Slide 6 text

Vモデル 6 System Development Upper Level System Element Development Lower Level System Element Development Lower Level System Element Realization Upper Level System Element Realization Solution/System Realization Integration, Verification, & Validation Planning I, V, & V Planning I, V, & V Planning Architecture Decom position  &  Definition Architecture Integration  &  Verification システムの設計開発は、分割と統合から成る 分割の段階から、統合や検証のことを考えることが⼤切 (INCOSE, Systems Engineering Handbook)

Slide 7

Slide 7 text

プロジェクトの総コストは、上流設計で8割が決まる ライフサイクルコストに対する各開発段階での意思決定の影響 (NASAの32の主要プロジェクトの分析結果) 7

Slide 8

Slide 8 text

「上流設計」とは 要求とアーキテクチャについて 関係者間の合意を得るプロセス ビジネス分析 プロセス 利害関係者要求 定義プロセス アーキテクチャ 定義プロセス 設計定義プロセス システム分析 プロセス 実装プロセス 統合プロセス 検証プロセス 移⾏プロセス 妥当性確認 プロセス 運⽤プロセス 保守プロセス 廃棄プロセス 要求定義プロセス ISO/IEEE 15288:2015 p17-Fig.4で定義されている システムライフサイクルプロセスのうち技術プロセスを抜粋 上流設計 なんのために、どのような解決策を つくるのか?について合意を得るプロセス 8

Slide 9

Slide 9 text

要求定義のプロセス ステークホルダ要求 境界の明確化 成果物の明確化 システム要求仕様 要求定義 関係する要求洗い出し 対象システムの範囲明確化 使用方法の明確化 ConOps: Concept of Operation 機能・性能明確化 検証性識別 要求記述明確化 9

Slide 10

Slide 10 text

アーキテクチャ設計: システム要求仕様を満⾜する、かつ最適な設計解を⾒つけること 機能‧性能 運⽤‧使⽤⽅法 構成品 安全性 アーキテクチャ 設計 アーキテクチャ設計とは 10

Slide 11

Slide 11 text

アーキテクチャの検討プロセス システム サブシステム1 サブシステム2 サブシステム3 サブ機能2.3 サブ機能2.1 サブ機能2.2 サブ機能1 サブ機能3.1 サブ機能3.2 ①機能設計: システムに要求される 機能を分割し、その機能 を構成する下位機能の 集合に置き換える ②物理設計: 分割された下位の機 能を、システムを構 成する要素に割り付 ける ③仕様定義: 構成要素の仕様およ び構成要素間のイン タフェース仕様を定 義する システム 要求機能 サブ機能1 サブ機能2 サブ機能3 サブ機能2.1 サブ機能2.2 サブ機能2.3 サブ機能3.1 サブ機能3.2 サブシステム1 サブシステム2 サブシステム3 サブシステム間 インタフェース 11

Slide 12

Slide 12 text

ちょうどいいシステムズエンジニアリング レヴィのソリューション

Slide 13

Slide 13 text

SEプロセス×構造化思考 = ちょうどいいSE 13 使えるSEの組織定着 SEはベストプラクティスを集めた実践知 プロセス理解とともに「構造化思考」の⼒を⾼めることが業務活⽤の近道 システムズエンジニアリングを 実践する システムズエンジニアリング プロセスを理解している 構造化思考ができる 人材が揃っている 専門家による講義と 実践を通じた伝授 構造化思考を鍛えられる ツール「Balus」を活用

Slide 14

Slide 14 text

機能 物理 運⽤ 抽象度⾼ 抽象度低 抽象度が⾼過ぎるところ で合意しても、 認識がずれる 抽象度が低すぎると 合意形成が難しい ⼀番⼤切なエッセンスは「ちょうどいい抽象度」と「視点の切り分け」 理解に必要な視点が揃っていることが重要 14

Slide 15

Slide 15 text

どうやってやる? 15

Slide 16

Slide 16 text

構造を描き対話しながら「ちょうどいい」を探索する 16 複雑な製品の構造を描くには ① 要素の間の関係性を考える ② いろいろな視点(ビュー)から⾒る ③ 抽象度を上げたり下げたりする 構造化 構造を可視化し、対話を通じて 構造を変えていく

Slide 17

Slide 17 text

つづきが気になる⽅は ぜひお問い合わせください。 17