【まとめ】システムズエンジニアリングに基づく製品開発の実践的アプローチ

6.4.1　ビジネス又はミッション分析プロセス
6.4.2　利害関係者ニーズ及び利害関係者要求事項定義プロセス
6.4.3　システム要求事項定義プロセス
6.4.4　アーキテクチャ定義プロセス
6.4.5　設計定義プロセス

2.2　ビジネスコンセプト立案
　2.2.1　事業成長と商品戦略
　2.2.2　Customer(顧客・市場)の分析
　2.2.3　Competitor(競合)の分析
　2.2.4　Company(自社)の分析
2.3　プロジェクトのスコープを決める
　2.3.1　顧客の未解決の課題にスコープを当てる
　2.3.2　ハイレベルなコンセプトを決める
　2.3.3　ハイレベルコンセプトの検証
　2.3.4　マーケティング戦術を決める
　2.3.5　商品戦略書を作成する
　2.3.6　ビジネス要求を作成する

3.2　ステークホルダ意見収集の準備
　3.2.1　ステークホルダの特定
　3.2.2　ステークホルダの意見収集方針を決める
　3.2.3　ステークホルダの意見収集計画を立てる
3.3　ステークホルダの意見収集と分析
　3.3.1　VoC/VoE収集の２つの段階
　3.3.2　デザインシンキングの応用
　3.3.3　ステークホルダを理解する
　3.3.4　ステークホルダの問題を分析する
　3.3.5　問題定義とワークフローへの紐づけ
　3.3.6　既存類似製品のコンプレインとの分析
　3.3.7　ステークホルダの意見収集
　3.3.8　VoC/VoEのまとめ
　3.3.9　対象となる法規制・規格の調査

4.2　初期のステークホルダニーズの導出
　4.2.2　ステークホルダの声から初期のニーズへ変換する
　4.2.3　ニーズの分類
4.3　真のステークホルダニーズを分析する
　4.3.1　ユーザーが本当に達成したいことを分析する
　4.3.2　見落としているニーズを見つけ出す
　4.3.3　ステークホルダニーズの妥当性確認
　4.3.4　ステークホルダニーズが失われている場合には
4.4　ビジネス要求を更新する
4.5　ステークホルダのニーズの絞り込み
　4.5.1　システム化する範囲を定義する
　4.5.2　システムの革新レベルに基づくニーズの取り上げ方
　4.5.3　ビジネス要求に基づくニーズの絞り込み
　4.5.4　ステークホルダ要求図、商品戦略・マーケティング戦術の更新
4.6　ステークホルダの要求に転換する
　4.6.1　定量的な目標値
　4.6.2　定性的な目標値
4.7　法規制の要求

5.2　ステークホルダ要求とシステム要求の関係
5.3　ステークホルダ要求からシステム要求への変換
　5.3.1　システムに求める「能力」への変換
　5.3.2　アイディエーション
　5.3.3　システムの機能コンセプトの作成
　5.3.4　機能コンセプトの自己チェック
　5.3.5　機能コンセプトの段階で物理手段を出すべきか
　5.3.6　機能コンセプトの検証
　5.3.7　PoC資料の作成
　5.3.8　機能コンセプト以外の確認項目
　5.3.9　PoCの実施
　5.3.10　アンケートによるPoC
　5.3.11　技術検討と技術妥当性の評価
　5.3.12　事業性の判断
　5.3.13　システム要求の定義
　5.3.14　システム要求の性能値定義(PoC)
　5.3.15　定量化が難しいシステム要求性能値の定義
　5.3.16　システム全体としての性能バランスを確認する
5.4　システム要求を検証する
　5.4.1　ステークホルダ要求とシステム要求のトレーサビリティの確認
　5.4.2　ワークフロー上で必要な機能が漏れていないかを確認する
　5.4.3　システム要求仕様書の作成
5.5　知財活動と安全分析の開始
　5.5.1　知財活動の開始
　5.5.2　機能安全分析の開始

6.2　論理アーキテクチャとは何か
　6.2.1　システム要求とアーキテクチャ
　6.2.2　論理アーキテクチャと物理アーキテクチャ
　6.2.3　アーキテクチャを定義する3つの視点
6.3　機能ごとの内部の動きを分析する
　6.3.1　入出力を識別する
　6.3.2　システム内部の動作を分析する
6.4　機能ごとの状態を分析する
6.5　動きのない機能の導出
6.6　内部構造の統合
　6.6.1　内部機能の統合
　6.6.2　機能間の矛盾の解消
6.7　システム機能構造の最適化
　6.7.1　システム機能の階層化
　6.7.2　システム状態の統合
6.8　論理アーキテクチャの検証
6.9　論理アーキテクチャの使いどころ
　6.9.1　Make or Buyの判断
　6.9.2　内部機能の組み合わせにおける機能安全分析

7.2　物理アーキテクチャ検討の役割分担
7.3　プロダクト分割
　7.3.1　物理境界の分析
　7.3.2　システム内部構造の基本案の作成
　7.3.3　システム内部構造のバリエーション案の作成
7.4　物理アーキテクチャの決定
　7.4.1　Pros/Cons表の作成
　7.4.2　Pros/Cons表の作成上の注意点
　7.4.3　致命的な欠点の確認
　7.4.4　ビジネス部門による物理アーキテクチャの決定
　7.4.5　機能の物理アーキテクチャへの割り当て
　7.4.6　物理アーキテクチャの仕様値の分配
7.5　プロダクト間のインターフェース定義
　7.5.1　インターフェースの抽出
　7.5.2　インターフェース仕様書はプロダクト間の契約書
　7.5.3　インターフェース仕様の定義
7.6　プロダクトフェーズへの準備

8.2　プロダクト要求定義の準備
　8.2.1　プロダクトフェーズへのインプット情報の確認
　8.2.2　検討範囲の確認
8.3　プロダクト要求の分析
　8.3.1　プロダクトの外部機能の分析
　8.3.2　プロダクト分割によるステークホルダ要求の詳細化
　8.3.3　プロダクト外部機能のアイディエーション
　8.3.4　プロダクト間のインターフェース仕様の更新と確認
8.4　ユーザーインターフェースの検討
　8.4.1　検討の流れ
　8.4.2　ユーザーインターフェースの抽出
　8.4.3　UX観点での洗練
　8.4.4　グラフィックユーザーインターフェース(GUI)の洗練
　8.4.5　ユーザーインターフェースのPoCとプロダクト要求の検証
8.5　プロダクト要求仕様書を作成する
　8.5.1　プロダクト要求書のねらい
　8.5.2　システム内におけるプロダクトの位置づけ
　8.5.3　プロダクトに関連するステークホルダ
　8.5.4　プロダクトの機能的要求
　8.5.5　プロダクトの物理的要求
　8.5.6　プロダクトの動作環境要求
　8.5.7　プロダクトのインターフェース要求
　8.5.8　プロダクトのユーザーインターフェース要求
　8.5.9　プロダクトの非機能要求
　8.5.10　プロダクトのエラーに関する方針

9.2　論理アーキテクチャの定義
　9.2.1　プロダクトの内部機能抽出の流れ
　9.2.2　内部機能を実現する方式を検討する
　9.2.3　プロダクトの内部機能構造と最適化の検討
　9.2.4　プロダクトの内部機能の階層化
　9.2.5　論理アーキテクチャの検証
9.3　物理アーキテクチャの定義
　9.3.1　機能から実装手段への転換の流れ
　9.3.2　プロダクト構造(構成要素の関係)を明らかにする
9.4　プロダクト構成要素の技術分野への割り当て
　9.4.1　割り当ての考え方
　9.4.2　プロダクト構成要素の責務
　9.4.3　プロセッサの割り当て
9.5　プロダクトアーキテクチャの検証
　9.5.1　検証の流れ
　9.5.2　アーキテクチャの検証方法
9.6　プロダクト設計仕様書の作成
　9.6.1　プロダクト設計仕様書の構成
　9.6.2　プロダクトの外観と各部の役割
　9.6.3　プロダクト全体構成図
　9.6.4　各部の構成
　9.6.5　プロダクトの機能仕様
　9.6.6　プロダクトトレーサビリティマトリクス
　9.6.7　プロダクト構成要素間、技術分野間のインターフェース仕様
9.7　実装フェーズへの準備

10.1　システムエンジニアリングを推進するためのコツ
10.2　導入時によくある失敗事例とその対策
　10.2.1　気がつけば元の開発に戻っている
　10.2.2　プロジェクトマネジメントとの足並みがそろわない
　10.2.3　分析作業が膨大で途中で挫折する
　10.2.4　成果物作成が目的化してエンジニアリングとしての効果が出ない
　10.2.5　良いシステムを作るには