ソフトウェア高信頼化推進委員会 システムズエンジニアリング推進 WG 第 1 回議事要旨 1. 日時 2017 年 9 月 4 日 ( 月 )14:00-17:00 2. 場所 独立行政法人情報処理推進機構 (IPA)13 階会議室 A 3. 出席者 ( 敬称略 順不同 ) 主査 白坂成功 ( 慶應義塾大学大学院 ) 委員 参加者 足立正和 ( 株式会社デンソー ) 石橋金徳 ( 慶應義塾大学大学院 ) 大西純 ( 株式会社三菱東京 UFJ 銀行 ) 梶本一夫 ( パナソニック株式会社 ) 川野卓 ( 東日本旅客鉄道株式会社 ) 艸薙匠 ( 株式会社東芝 ) 末冨隆雅 ( マツダ株式会社 ) 豊島真澄 ( 株式会社デンソー ) 長堀泉 ( 株式会社富士通総研 ) 福島祐子 ( 日本ユニシス株式会社 ) 松並勝 ( ソニーデジタルネットワークアプリケーションズ株式会社 ) 松本雅行 ( 松本信号システムコンサルタント ) IPA 出席者 技術本部ソフトウェア高信頼化センター (SEC) 中尾昌善 事務局 技術本部ソフトウェア高信頼化センター (SEC) 端山毅 西原栄太郎 室修治 新谷勝利 岡本拓也 齋藤毅 齊藤善治 4. 配布資料資料 1 (17-SEWG-1) 第 1 回システムズエンジニアリング推進 WG 議事次第資料 2 (17-SEWG-1) システムズエンジニアリング推進 WG 委員名簿資料 3 (17-SEWG-1) システムズエンジニアリングの推進に向けた IPA/SEC の取り組み資料 4 (17-SEWG-1) システムズエンジニアリング推進 WG 運営方針案資料 5 (17-SEWG-1) システムズエンジニアリング推進 WG の目的及び計画資料 6 (17-SEWG-1) システムズエンジニアリング推進 WG の具体的な進め方資料 7 (17-SEWG-1) 基礎解説書の要件
資料 8 (17-SEWG-1) 基礎解説書 : 事例のまとめ方検討 資料 9 (17-SEWG-1) 基礎解説書 : システムズエンジニアリングプロセスの解説方法 参考 1 (17-SEWG-1) 15288 プロセス説明 ( 非公開 ) 5. 議事 (1) 事務局より連絡 説明 資料 3に基づいてシステムズエンジニアリングの推進に向けた IPA/SEC の取組みについて説明が行われた 資料 4に基づいて WG 運営方針の説明が行われ 活動期間とそれぞれの役割 及び 資料の原則公開の方針について承認された 資料 5に基づいて WG の目的及び計画についての説明が行われた (2)WG 開始にあたっての挨拶 委員自己紹介白坂主査から挨拶が行われた また 各委員から自己紹介が行われた (3)WGの具体的な進め方 事務局より 資料 5に基づき WG の具体的な進め方の案が紹介された ( 討議は資料 6~9の説明後に併せて行うこととした ) (4) 本日の論点の説明 事務局より 資料 6, 資料 7, 資料 8, 資料 9 及び参考 1に基づき 本日の 4 つの論点について説明が行われた 論点 1 基礎解説書の要件 : 想定読者 記載内容 論点 2 事例のまとめ方 : 効果的な事例の使い方 構成 論点 3 プロセスの解説方法 : 範囲と詳細さ 論点 4 基礎解説書の目次案 : 事例とプロセスの組合せ (5) 本日の論点の討議 発言内容 ( 具体的な進め方 ) 事例を振り分けて扱うのか 1 件の事例について見方を変えて 全体的なポイント説明と 部分的なプロセス 技法説明の両方に使うこともある ( 論点 1: 資料 7 基礎解説書の要件 : 想定読者 記載内容 ) 上流だけが強調されて 下流が見過ごされてはいけない 下流で発生する問題を上流で検討し 要件や設計に対策を取り込むことが重要 重要なことはライフサイクル全体を見渡した検討を上流で行うこと 想定読者の想定 1 の表現は不適当 想定読者についてはもっと明確に絞ったほうがよい 漠然とした要求に対して企画を創出するような状況 ( IoT で何かせよ など ) はプロセ
ス思考やメソドロジーで解決するということではなく 今回の基礎解説書の対象外と考える 対象読者をより明確にするためにも これを読むことでどうなってほしいか ということを想定しておく必要がある ゴールは決まっているが どのようにゴールにアプローチすればよいか 進め方が分からない場合にシステムズエンジニアリングは役に立つ What to make よりは How to make がシステムズエンジニアリングの役割といえる システムズエンジニアリングの全体像は何なのか 例えばソフトウェアエンジニアリングでいうと何を示せば全体像と言えるか と同様で表現は視点による システムズエンジニアリングに基づいて検討する際に周辺領域の検討も必要になる システムに要求される特性 ilities はシステムズエンジニアリングの実務上必要になるが システムズエンジニアリングではない システムズエンジニアリングは 全体を俯瞰し分析していくところと 分析結果を総合していくところ システムズエンジニアリングという言葉に限らず 周辺も含めた役立つ部分を出せばよいという考えもある ソフトウェア開発ではそれぞれの会社に開発プロセスの標準がある それが与えられているため 開発にあたって自身が考えることがなくてもできる という環境にありがち どうやってあのゴールに向かうかをゼロから考えないことも多い ソフトウェア開発がシステムズエンジニアリングに学ぶべきは 案外 もっと上流で先のことをちゃんと考えるべきということ うまく伝えるにはどうしたらよいか 想定読者として こういう課題感のある人 こういうことをやらなければいけない人たちをターゲットにしている ということをいれなければならない それに対して 事例を通じてシステムズエンジニアリングはこういうことを考えて こういうプロセスがあるから こういうことができるようになる というのを示していくという想定 そこに システムズエンジニアとはどういう人なのか こういうことができる人 それはこういうプロセス こういうところを活用している ということがうまくつながればよい 実際に進めている経験からは 人のイメージをもってもらうと伝わりやすく システムズエンジニアの振る舞いのイメージを持ってもらうことが多い プロジェクト内にシステムズエンジニアリングの知識 経験を持った人がいて 要所要所で勘所を押さえていく形態になる ただし システムズエンジニアが何をするのか というのはドメインにより異なるので一般的な解説は難しい システムズエンジニアは 15288
(ISO/IEC/IEEE15288 システムライフサイクルプロセス ) を実際の開発で技術的に考 えながら進める人のことである システムズエンジニアリングの知識だけあっても実践できない 実務経験が必要である 実際には指導者がいないと育たない 本件については現場の指導者の育成も今後の課題 である 学びのモティベーションを持ってもらうのが最初の入り口でよいという考え方もある システムズエンジニアリングに企業内で取り組む場合 どのような体制 役割構成が必要か 明確に示してほしい 個々の技術者の思いでは実施できない どんな組織でやったのか リファレンスになる組織のアーキテクチャを示してほしい 組織の解説を書くと 対応組織を作ればよいと誤解されがち 組織を作ったが実態は進まず 形骸化するケースがこれまでに多く見られている ドメインに依るので 組織のあるべき形を具体的に示すことはしない システムズエンジニアリングに関するロールモデルを明らかにするのはよいが 具体的な組織配置は各々の会社で決めるのが良い ( 論点 2: 資料 8 事例のまとめ方 : 効果的な事例の使い方 構成 ) 実際の事例が集まるかが大事 委員の方には 事例の提示をお願いする 次回 WG の事前に事務局よりご連絡させていただく ちなみに実施前の段階のものでも事例として分かりやすければよい 公開が難しく討議用に限るなどの条件があれば 事務局に相談 ( 論点 3: 資料 9 プロセスの解説方法 : 範囲と詳細さ ) システムズエンジニリングの特徴の際立つプロセスを重点にということで システムライフサイクルプロセスの技術プロセスの中から7つのプロセスを特に詳しく紹介している システムライフサイクルプロセスがソフトウェアライフサイクルプロセス (ISO/IEC 12207) と大きく異なる部分として 技術プロセスの中の上流に相当するプロセスを選んだ ( 論点 4: 資料 6 基礎解説書の目次案 : 事例とプロセスの組合せ ) 事例とプロセスの結び付け方が実際に書いていく上での課題 事例についてはまとめながら見ていってイテレーティブにブラッシュアップしていくのがよい
(6) まとめ 具体的な進め方はおおむね了解された 事例を基に具体的に検討していく 論点 1 要件はおおむね了解された 指摘点について事務局にて見直し 次回提示する 論点 2 方向性について了解された 事例を基に具体的に検討していくため 各委員の方に事例の提供をお願いした 論点 3 方針は了解された 選定した7プロセスをベースに作業を進め 討議の中で必要と判断した場合には適宜見直していくこととした 論点 4 まとめながらイテレーティブにブラッシュアップしていくこととした 6. 連絡事務局から 以下の連絡を行った 次回の WG は10 月 12 日 15 時慶應義塾大学日吉キャンパス来往舎で行う 次回の WG への委員からの事例の提示については 詳細を事務局より連絡する 以上