米国修士課程ベストセラーに学ぶ体系的ソフトウェア・エンジニアリングの必要性 ～DX,AI,MaaS,…に惑わされない実践的エンジニアリングアプローチ
5.6K Views
November 18, 21
スライド概要
2021年11月18日に開催されたET2021でのセッション資料です。
https://f2ff.jp/introduction/5831?event_id=et-2021
■アブストラクト
コンピュータサイエンスのみでは不足していることに産業界が気づき、ソフトウェアエンジニアリングという分野が登場して50年が経った。産業界は実践事例を生み出しながらその体系構築に貢献し、恩恵をあずかるサイクルが生まれている。これは組込みソフトウェアにおいても例外ではない。
現在、組込みを含む業界の進化は加速する一方であり、開発途中に当初見定めた前提条件すら変わってしまうという変化の時代にいる。この状況下で優れたエンジニアリングを継続していくためには、製品に組み込む要素技術のみを追求するのではなく、最新のエンジニアリング体系をベースラインとして自分たちの立ち位置を見直し、不足している部分を学習することが重要となる。
講演者3名を含むSEPA翻訳プロジェクトでは、米国修士課程においてベストセラーとなっている体系的解説書「Software Engineering: A Practitioner's Approach 9th edition」を翻訳し、「実践ソフトウェアエンジニアリング第9版」としてオーム社より12月発刊予定である。https://www.ohmsha.co.jp/book/9784274227943/
これを機に、本セッションでは、ソフトウェアエンジニアリング体系とその実践、立ち位置を見直すために役立つ知見を紹介する。
クオリティアーツ代表／NaITE代表／ASTER理事／AFFORDD運営委員／Bizreach Software Quality Enabler、等。世の中に品質の技術で貢献するために活動中。 https://quality-arts.com/ https://naite.swquality.jp/ https://www.aster.or.jp/ https://affordd.jp/
関連スライド
各ページのテキスト
米国修士課程ベストセラーに学ぶ 体系的ソフトウェアエンジニアリングの 必要性 DX, AI, MaaS, …に惑わされない実践的エンジニアリングアプローチ ET&IoT2021 水野 昇幸 池田 暁 金子 昌永 味の素エンジニアリング(株), SEPA翻訳プロジェクト (特非)ソフトウェアテスト技術振興協会(ASTER), SEPA翻訳プロジェクト SEPA翻訳プロジェクト
趣 旨 構 成 組込みソフトウェアに携わる人々に対し ソフトウェアエンジニアリングを体系的に学ぶ必要性を伝える I. 日本の組込みソフトウェア教育では ソフトウェアエンジニアリング体系が参照されていない疑惑 II. 実務/学術、モダン/温故知新のバランスに優れた体系 ～実践ソフトウェアエンジニアリング第9版の紹介～ III. 体系は更新される財産 IV. 体系の外側 ～いつかきた道ではない新たな道～ キー ワード 教育 体系 改善 アセスメント カリキュラム ESxR ETSS ETEC 体系の外側
講演アブストラクト（Web掲載文） コンピュータサイエンスのみでは不足していることに産業界が気づき、ソフトウェアエンジニアリングという分野が登場して50年が経っ た。産業界は実践事例を生み出しながらその体系構築に貢献し、恩恵をあずかるサイクルが生まれている。これは組込みソフトウェ アにおいても例外ではない。 現在、組込みを含む業界の進化は加速する一方であり、開発途中に当初見定めた前提条件すら変わってしまうという変化の時代に いる。この状況下で優れたエンジニアリングを継続していくためには、製品に組み込む要素技術のみを追求するのではなく、最新の エンジニアリング体系をベースラインとして自分たちの立ち位置を見直し、不足している部分を学習することが重要となる。 講演者3名を含むSEPA翻訳プロジェクトでは、米国修士課程においてベストセラーとなっている体系的解説書「Software Engineering: A Practitioner's Approach 9th edition」を翻訳し、「実践ソフトウェアエンジニアリング第9版」としてオーム社より12月発刊予定であ る。https://www.ohmsha.co.jp/book/9784274227943/ これを機に、本セッションでは、ソフトウェアエンジニアリング体系とその実践、立ち位置を見直すために役立つ知見を紹介する。
講演者紹介 水野 昇幸 SEPA(Software Engineering: a Practitioner's Approach)翻訳プロジェクトメンバー / 味の素エンジニアリング（株） 某電機メーカー（宇宙通信の開発を中心としたSystem of Systems/組込み開発） その後 フリーランスを中心として、要件定義支援、プロジェクトマネジメント支援、 システム設計、プロセス改善テストプロセス・テスト計画支援を通じた改善等を実施 Twitter：@Noriyuki Mizuno 論文（国際学会のみ）： ・（共著）InSTA2019＠西安：Coexistence of test execution efficiency and test ・（共著）InSTA2018＠Sweden：Proposal for Enhancing UTP2 with Test Aspects ・（共著）InSTA2017＠東京：Test Conglomeration ・（共著）6WCSQ20104＠ロンドン：Stepwise Test Design Method 発表（ET関連での発表のみ）： ・ET-WEST2018：なぜ組込みシステムにおけるテストは難しいのか ・ET-WEST2014：組込み開発でのSWテスト自動化のライフサイクル 所属コミュニティ： ・ETロボコン実行委員、JaSST北海道実行委員、RDRA MeetUp運営等 保有資格： ・情報処理エンベデッド、プロマネ、簿記3級、2級、JTSQB－ALTM／ALTA等 現在、PLANTAXISという工場向け設備管理システムのプロダクト開発を支援中 → 実践ソフトウェアエンジニアリング（第9版）、オーム社 の翻訳プロジェクトとりまとめ 設備管理システム「 PLANTAXIS」 https://www.plantaxis.net/
講演者紹介 池田 暁 SEPA(Software Engineering: a Practitioner's Approach)翻訳プロジェクトメンバー / （特非）ソフトウェアテスト技術振興協会（ASTER） 理事 / クオリティアーツ 代表 https://quality-arts.com/ 情報通信系某社にて組込みシステムの設計、品質保証業務を経て、技術支援部門にてテスト技術を中心にアジャイル開発や MBD/SPL等の導入を支援。その後所属を移し医用系、自動車系ドメインの自社製品開発プロジェクトに参画、テスト管理業務 やプロセス活動に従事。 そのほか、全社を対象としたテストプロセス改善や研究による新技術導入、教育など品質確保や効率向上、技術高度化に取り 組んできた。 社外においてはNPO法人ASTER等に所属してソフトウェア開発技術の普及啓発活動に取り組んでいる。ASTER理事、NaITE代 表、SQiP運営委員，AFFORDD運営委員、CO-DEJIMA技術メンター等。 現在はクオリティアーツ（屋号）として独立し、技術向上にまい進する企業に対してコンサルティング支援している。 最近の主な発表： ・JaSST'19 Hokkaido 基調講演 ・JaSST'18 Kyushu 招待講演 著書： ・実践ソフトウェアエンジニアリング第9版（共訳） ・SQuBOK Guide V3（共著） ・[改訂新版]マインドマップから始めるソフトウェアテスト（共著） ・ソフトウェアテストの基礎（共訳）、等。 Twitter: ikedon0505 mail： [email protected]
講演者紹介 金子 昌永 10年 組込みソフトウェア開発者 / クラリオン 現フォルシアクラリオン・エレクトロニクス 車載エンターテイメント機器開発、全社技術向上、教育 4年 ソフトウェアエンジニアリング研究者 / 日立製作所 医療機器向けマネジメント技術開発、社内コミュニティ 1年 フリーに転身して自給率を高めるライフスタイルを模索, 業界全体に貢献する道を進む ● ● ● ● Twitter GitHub SlideShare ○ masskaneko LinkedIn [共訳] 実践ソフトウェアエンジニアリング第9版, オーム社, 2021 [論文] 医療機器ソフトウェア開発を対象とした包括的アセスメントのケーススタディ, 情報処理学会 SES2020 [論文] 不具合と開発現場の実態に基づくテスト分析手法, SQiPシンポジウム2015 [発表] 日立・ソフトウェア革新部会 ～会社を越境する社内コミュニティ～, XP祭り2019 [発表] モダンなチーム開発環境を追求しよう, SQiPシンポジウム2016
I. 日本の組込みソフトウェア教育では ソフトウェアエンジニアリング体系が 参照されていない疑惑
日本の組込みソフトウェア教育 始まりと実状 ● ● ● 製造業製品における ● 組込みソフトウェアの重 要性向上 組込みソフトウェア ● クライシス IT業界の成長見込みと 開発力の課題 調査・課題分析 組込み系ソフトウェア 開発の課題分析と提言 (JEITA) 組込みソフトウェア産業の 動向把握等に関する調査 (IPA/SEC, 経済産業省) 教育内容 ● ● ● ● ESxR ETSS ETEC 一般の技術書 扱わない ● 社内教育 ● 一般有志の勉強会 ● 高等教育機関の 情報/電気専攻
教育に至る少し前： 組込みソフトウェアと製造業への期待(2002, 2003) 前田，重岡：”製造業のためのソフトウェア戦略マネジメント入門”，生産性出版，2003 ソフトウェアが核となる市場は、情報家電・デジタル家電・ユビキタスネットワーク・ ICタグ・IPv6等のこれからの期待分野に留まらない。 医療・環境・自動車・航空・宇宙・あらゆる移動体等の分野・・・にも、想像をはるかに 超えた、多様なニーズに応えるソフトウェアがますます必要とされている。 とりわけ、その主戦場はハードウェアと一体になった組み込みソフトウェアの分野であ る。この分野で確固としたソフトウェア設計・生産、そしてマネジメントの仕組みを 確保しなければならないと言えよう。 松下，坂東：”ネット家電とその技術”，裳華房，2002 家電はもともと日本が強い分野でネット家電でも日本がリードできる可能性が高い。 ゲーム機、電子カメラ、DVD等は日本製品が世界を制覇している。 ・・・日本にとって将来性が非常に楽しみのある分野である。
期待と共に訪れた危機（クライシス） 西：”製品品質の決定要因としての組込みソフトウェアと組込みソフトウェア・クライシス”， 日本品質管理学会誌「品質」 Vol.34，2004, https://qualab.jp/materials/jsqc-article2004.pdf 組込みソフトウェアは、高度化し複雑化した製品の中核となっており、製品全体の品質 が組込みソフトウェアに依存するようになってしまった。しかし残念ながら組込みソフト ウェアの品質、特に信頼性は十分確保されているとは言えない。 いわば「組込みソフトウェア・クライシス」である。 組込みソフトウェア・クライシスは30年遅れ？ Pressman: “Software Engineering: A Practitioner’s Approach 1st edition”, 1982 より翻訳 1970年代において、我々は「ソフトウェア危機(software crisis)」と称される状況を認識するに 至った。ソフトウェアに関するコストは爆発的に増大し、コンピューターを使用したシステムに おいて最も高価な要素となった。開発計画の通りに進み、完了することはほとんどなかった。 ソフトウェアが大きくなるにつれ、品質が怪しくなってきた。そして、ソフトウェア危機に呼応す る一連の技術、すなわち「ソフトウェアエンジニアリング」が誕生した。
期待と懸念の後、どうなったのか？ ２０００ 期待＆ クライシスの 懸念 ２０１０ ２０２０ ①スマートフォン移行 ②組込みソフトウェア によるリコール ITへの投資は 十分だったのか？ ③ITへの投資と成長
①フィーチャーフォンからスマートフォンへの移行（2007～） 2007年にiPhoneが登場後、Android対応スマートフォンの各社初登場時期とシェアの変化 参考：https://ja.wikipedia.org/wiki/Android%E7%AB%AF%E6%9C%AB%E4%B8%80%E8%A6%A7 国内シェア の遷移 2007年 ↓ 2020年 商業的成否分析は以下に示されているが、開発技術が市場投入時期に影響とも読める [参考] 平成24年版 情報通信白書 第1部 第2章 第2節 ガラケーはスマホに「負けた」のか？ https://www.soumu.go.jp/johotsusintokei/whitepaper/ja/h24/html/nc122c00.html
①スマートフォンの起動時間(2012) 0 20 40 Huawei GS02 HTC EVO 3D AQUOS 103SH GALAXY SC-04D iPhone 4S MEDIAS CH 101N REGZA T-01D ARROWS F-05D 秒 ITmedia - 最新スマートフォン徹底比較（2011年度冬春モデル編） https://www.itmedia.co.jp/mobile/articles/1203/29/news081_2.html 最も早かったのがイー・モバイルの「 GS02」 で、わずか6秒ほどで起動する。次いで 11秒 強のHTC EVO 3Dも速い。3位の「AQUOS PHONE 103SH」が26.633秒 シャープ、ソニーモバイル、 Samsung電子の 端末は30秒前後 LGエレクトロニクス、パナソニック モバイル、 富士通の端末は 40～60秒以上 最も遅かったのが「 ARROWS ES IS12F」 で、83.933秒 上記記事より情報を抜粋して作成。同一ブランドから最も高速な機種を抜粋。 起動時間ばかりが品質ではないが、理解しやすく、差の出る指標である。
②組込みソフトウェアによるリコール（2014） 松田晃一，組込みソフトウェアの時代と日本の「ものづくり」，SEC journal 第37号，2014 https://www.ipa.go.jp/sec/secjournal/037.html 日本を代表する自動車メーカーが相次いでリコールを発表しています・・・ そのすべてが組込みソフトウェアの不具合によるリコールである点です・・・ ソフトウェアは目に見えず実態が掴みにくいためか・・・経営陣の関心も低いようです・・ 組込みソフトウェアを中心とする製品の時代に適した新しい「ものづくり」の形に 塗り替えることが何より重要ではないでしょうか。 専用ハードウェア部品の統合 汎用ハードウェアと組込みソフトウェア 「ものづくり」の競争の場はソフトウェアに移った（土俵が変わった） 「オッ」と驚く新しい体験を提供できる価値が勝負の分かれ目になる 変化を早く理解していた人もいたはず。経営陣は理解していないとみなされている？
③ITへの投資と成長： IT人材数の推移 経済産業省：”平成 30 年度我が国におけるデータ駆動型社会に係る基盤整備 ”, 図 3-6 IT 人材数（供給）の推移 https://www.meti.go.jp/policy/it_policy/jinzai/houkokusyo.pdf ヒューマンリソシア: “92カ国をデータで見るITエンジニアレポートvol.1” https://git.resocia.jp/info/post-developers-around-the-globe-survey/ 2020 IT人材数と人口比 1位 アメリカ 477万人 (1.47%) 2位 中国 227万人 (0.16%) 3位 インド 212万人 (0.16%) 4位 日本 109万人 (0.86%) 2021 2015年（994070人）を起点とした伸び率 2018年 +3.7%(実績)、2021年 +10.7%(予測) 2019-2020 IT技術者数伸び率 中国 8.59% インド 5.71% 日本 4.81% アメリカ 3.22%
③ITへの投資と成長： 情報通信業の労働生産性 経済産業省: “平成 30 年度我が国におけるデータ駆動型社会に係る基盤整備 ”, https://www.meti.go.jp/policy/it_policy/jinzai/houkokusyo.pdf 1995- 労働生 産性上昇率 2010- 労働生 産性上昇率 アメリカ 5.4% 2.2% ドイツ 4.2% 4.2% フランス 3.1% 2.3% 日本 2.4% 0.7% 各国の情報通信業の労働生産性上昇率 (上記資料 表3-3をもとに作成) 2010年を基準とした各国の労働生産性推移
③ITへの投資と成長： 世界と日本のIT市場規模 Gartner: “Worldwide IT Spending Forecast”, 2016-2021 e.g. https://www.gartner.com/en/newsroom/press-releases/2017-10-03-gartner-says-global-it-spending-to-reach-3-trillion-in-2018 矢野経済研究所 : “国内企業の IT投資に関する調査 ”, 国内民間IT規模市場 推移と予測 , 2020 https://www.yano.co.jp/press-release/show/press_id/2575 ※ガートナー社が年1回以上公表するデータに基づき作成 2016-2021成長率： 世界 24.2%，日本 8.5%
ここまで ● 組込みソフトウェアによる製品価値向上の期待 ● 組込みソフトウェア・クライシスの警鐘 → 発生 ● 日本のIT人材数は絶対数と人口比で上位であり伸びているが ITの労働生産性とITの市場規模は外国より劣る ○ ※組込み/製造業に特化したデータではないが、同じだとみている ● 品質と生産性に問題があるなら技術は絶対的な振り返り要素 ここから ● 組込みソフトウェアの業界は何を課題と捉えていたのか？ ● 課題に対して何をしてきたのか？ ● それがどれほど妥当だったのか？
[2004-2021] 経済産業省、IPA/SEC の調査 ● 2004-2010 組込みソフトウェア産業実態調査報告書 (経済産業省) ○ ○ 産業政策導出のための実態把握として開始 経済産業省のサイトから閲覧不可、Web Archive に一部あり ● 2011-2012 ソフトウェア産業の実態把握に関する調査 (IPA/SEC) ○ 経済産業省から引き継ぎエンタプライズ系企業も含めて調査 ● 2013-2015 空白の3年？ ● 2016-2018 組込みソフトウェア産業の動向把握等に関する調査 (IPA) ● 2019-2020 組込み/IoT産業の動向把握等に関する調査 (IPA) ○ 対象拡大&Web回答により800社以上に (以前は200-300社) 2011-2012, 2016-2020 の調査報告書が公開されている https://www.ipa.go.jp/ikc/reports/index.html
課題は？ 品質、効率、能力、期間、新製品、コスト 年 1位 2位 3位 4位 ETSS 2005 設計品質の向上 開発効率の向上 開発能力の向上 開発期間の短縮 ESCR 2006 設計品質の向上 開発期間の短縮 開発能力の向上 開発効率の向上 2007 設計品質の向上 新製品の開発 開発期間の短縮 開発能力の向上 2008 設計品質の向上 新製品の開発 開発期間の短縮 開発能力の向上 2016 設計品質の向上 開発能力の向上 開発コストの削減 新製品の開発 2017 設計品質の向上 開発能力の向上 新製品の開発 開発コストの削減 2018 設計品質の向上 開発能力の向上 市場の拡大・開拓 新製品の開発 ESPR ETEC 2005-2008年度 組込みソフトウェア産業実態調査報告書（経営者・事業責任者向け）“組込みソフトウェア開発に課せられている課題” 2016-2018年度 組込みソフトウェア産業の動向把握等に関する調査“組込みソフトウェア開発の課題” をもとに作成 ※回答選択肢は概ね一致するが増減と文言変更あり。2004年度版、2019-2020年度版には該当設問がないため除外。
“設計品質の向上” の解決策は？ スキル，スキル，技術，技術 年 1位 2位 3位 2011 技術者のスキル向上 開発手法・開発技術の向上 プロジェクトマネージャのスキル向上 2012 技術者のスキル向上 プロジェクトマネージャのスキル向上 開発手法・開発技術の向上 2016 技術者のスキル向上 開発手法・開発技術の向上 プロジェクトマネージャの確保 2017 技術者のスキル向上 プロジェクトマネージャのスキル向上 開発手法・開発技術の向上 2018 技術者のスキル向上 プロジェクトマネージャのスキル向上 開発手法・開発技術の向上 2011-2012年度 ソフトウェア産業実態調査報告書 “設計品質向上の課題の解決策”, “組込みソフトウェア開発の課題1番目の解決策” 2016-2018年度 組込みソフトウェア産業の動向把握等に関する調査“課題「設計品質の向上」の解決策” をもとに作成
JEITA による組込みソフトウェア開発の課題分析の変遷 組込みソフトウェア開発力に対する問題提起(2005) ・開発力は国際的に見て強いのか？ ・すり合わせは強みなのか？ ・何を強くすればよいか？ 大きな波(2006) ・大規模化 アンケート& ・複雑化 ワークショップ ・短納期化 ・多機種化 開発スピード阻害要因に着目 (2008-2010) ・要求分析 ・アーキテクチャ設計 ・プロジェクトマネジメント 提言(2007) ・ハード部門等との連携 ・自動化 ・上流工程重視 ・多機種開発 アーキテクチャ設計に着目 ・アーキテクト(2011-2013) ・モデリング(2014-2016) IoTに着目(2017-2018) ・IoT の定義 ・IoT 事例 ・IoT ならではの エンジニアリング、課題 組込み系ソフトウェア開発の課題分析と提言 (2008-2016)，IoT時代の組込み系ソフトウェア開発 (2017)，IoT開発の現状と課題 (2018) https://www.jeita.or.jp/japanese/public/software/index.html
JEITA による組込みソフトウェア開発の課題分析の変遷 組込みソフトウェア開発力に対する問題提起(2005) ・開発力は国際的に見て強いのか？ ・すり合わせは強みなのか？ ・何を強くすればよいか？ 膨大で示唆に富む分析(特にモデリング) 大きな波(2006) 開発スピード阻害要因に着目 ・大規模化 (2008-2010) アンケート& ・複雑化 ・要求分析 課題抽出プロセスに飛躍あり ワークショップ ・短納期化 ・アーキテクチャ設計 見ようとしている課題の存在を確認している？ ・多機種化 ・プロジェクトマネジメント ソフトウェアエンジニアリングの 提言(2007) 参考文献の記載に乏しい ・ハード部門等との連携 アーキテクチャ設計に着目 ・自動化 ・アーキテクト(2011-2013) 結果的にモデリングを起点に幅広いプロセスの ・上流工程重視 ・モデリング(2014-2016) 課題と解決技術にたどり着いているように見える ・多機種開発 IoTに着目(2017-2018) ・IoT の定義 ・IoT 事例 の報告書では ・IoT2017 ならではの ソフトウェア エンジニアリング、課題 エンジニアリングの 参考文献が比較的豊富 組込み系ソフトウェア開発の課題分析と提言 (2008-2016)，IoT時代の組込み系ソフトウェア開発 (2017)，IoT開発の現状と課題 (2018) https://www.jeita.or.jp/japanese/public/software/index.html
IoT時代の組込み系ソフトウェア開発(2017)に登場する ソフトウェアエンジニアリングの参考文献 ※和文のみ抜粋 ● ● ● ● ● ● ● ● ● エクストリーム・プログラミング(2015 ※原著は2004) エッセンシャルスクラム(2014) エンタープライズアジャイル実践ガイド(2013) ソフトウェアプロダクトライン，日刊工業新聞社(2013) チケット駆動開発(2012) UMLモデリングのエッセンス(2005) ソフトウェア品質保証の考え方と実際(1995) ソフトウェアプロセス成熟度の改善(1991) IEEEソフトウェア規格集(1991) ほか、英文文献を合わせて28文献にタグがつけられ参照されている
業界としての調査と課題分析 ● 企業は 「設計品質の向上」 「技術スキルの向上」 を 15年以上求めている ● アンケートとワークショップを重ね、現状整理と課題分析 業界では何が教えられてきたのか？ ● 国策としての組込みソフトウェア教育 ● 組込みソフトウェアの技術書
国策としての組込みソフトウェア教育 ETEC誕生の背景，Bulletin JASA Vol.75, 2020 https://www.jasa.or.jp/archive/bulletin-jasa/ 国策としてのソフトウェア強化構想は2000年に発表されたe-Japan戦略にルーツ・・・ IPAにSECが設置・・・初めて公的な組織に組込みソフトウェアが登場・・・ 開発力強化タスクフォース ESxR：Embedded System development x Reference ESCR ESPR ・・・ 人材育成タスクフォース ETSS：Embedded Technology Skill Standards いかにして知識やスキルを測定するか・・・客観的で量的な制約のない方法・・・ 高度スペシャリストを対象としたES試験のみ・・・一般の技術者を対象としたものは・・・ 2005年より「JASA改革」が推進された・・・ETEC試験事業の着手などが実施された・・・ ETEC：Embedded Technology Engineer Certification 組込み技術者試験
ESxR ● ● ● ● ● ● https://www.ipa.go.jp/sec/softwareengineering/std/emb.html 組込みソフトウェア開発の 標準リファレンス IPA発行 200x：ESCR, ESPR 201x：ほか V字モデル(左)で 範囲が示されている ETのIPAブースで 入手した方は多いのでは
ESxR ESQR 参考文献豊富 要求エンジニア リング未着手 ESPR Ver2 2007 が最終 イテレーティブプロセスなし ● 組込みソフトウェア開発の V字モデルに基づく重いプロセスモデル 標準リファレンス ● IPA発行 ESBR バグ管理は ● 200x V字モデル内でなくマネジメント ○ ESCR, ESPR ● ○ ESTRに影響 ESDRに影響 ● ESMRに影響 https://www.ipa.go.jp/sec/softwareengineering/std/emb.html 201x ● ESDR, ESTR, ESBR, ESQR, ESMR Wモデル(左)で 範囲が示されている ETのIPAブースで 入手した方は多いのでは
ETSS(スキル項目毎4レベル), ETEC(試験：800点満点 ABCグレード) コンピュータエンジニアリング ETECでは出題範囲を限定 ソフトウェアエンジニアリング ETSS導入推進者ガイド https://www.ipa.go.jp/sec/publish/tn08-008.html ※図の引用元 ETECクラス2 https://www.jasa.or.jp/etec/ks-200/ よくわかる組込みシステム開発入門 , 2021 https://gihyo.jp/book/2021/978-4-297-11966-9 ※最新参考書籍
ETEC参考書(2021)の構成比とESPR(2007)からの影響 よくわかる組込みシステム開発入門 ● 116p(74%) ● 40p(26%) (大まかには)コンピュータエンジニアリング ソフトウェアエンジニアリング - V字モデル 今も使える 基礎知識 こちらは？ [p118] 現在、いくつかの開発プロセスが定義されています（例：V字モデル、W字モデル、 スパイラルモデル、ウォーターフォールモデル、プロトタイプモデル）・・・ アジャイル型開発技法を製品開発に取り入れているプロジェクトも増えてきています。 本書では・・・ESPRを基準とする・・・という前提条件でV字モデルを解説します。 スパイラル(1988)，イテレーティブ(1998)，XP(1999)，スクラム(1993, 2001) 訳書：ソフトウェアプロジェクト管理 - 21世紀に向けた統一アプローチ， ウォーカー・ロイス(著)，1999 ウォーターフォールの祖と世間に勘違いされたウィンストン・ロイスの息子、 ウォーカー・ロイスが放った渾身の一冊 V字モデル自体は上下左右の概念把握に有用だが、V字モデルのみ記されていたため、 多くの組込み企業はイテレーティブプロセスに進化する機会を失ったのではないか？
コ ン ピ ュ | タ 組込み技術書の変遷 1 製造業のためのソフトウェア 戦略マネジメント入門 2003 2 よくわかる組込みシステム開発入門 2005 3 組込みソフトウェア開発スタートアップ 2005 4 5 組込みソフトウェア開発のための オブジェクト指向モデリング これだけは知っておきたい 組込みシステムの設計手法 開 発 プ ロ セ ス 2006 2009 6 組込み現場の「 C++」プログラミング 2009 7 テスト駆動開発による 組み込みプログラミング 2013 8 現場がわかる組込みソフトウェア開発 2014 9 モダンC言語プログラミング 2014 10 組込みエンジニアの教科書 2019 チ | ム 組 織 支 援 プ ロ セ ス
コ ン ピ ュ | タ 手薄：要求と支援プロセス 1 製造業のためのソフトウェア 戦略マネジメント入門 2003 2 よくわかる組込みシステム開発入門 2005 3 組込みソフトウェア開発スタートアップ 2005 4 5 組込みソフトウェア開発のための オブジェクト指向モデリング これだけは知っておきたい 組込みシステムの設計手法 2006 2 3 8 5 10 5 3 4 5 3 2009 6 組込み現場の「 C++」プログラミング 2009 7 テスト駆動開発による 組み込みプログラミング 2013 8 現場がわかる組込みソフトウェア開発 2014 9 モダンC言語プログラミング 2014 10 組込みエンジニアの教科書 2019 6 7 8 9 5 1 8 5 9 チ | ム 組 織 開 発 プ ロ セ ス 支 援 プ ロ セ ス
業界取組みの注力領域は？カリキュラム標準で俯瞰する JEITA調査 ESxR ETSS/ETEC 組込み 技術書 情報専門学科カリキュラム標準「 J07」 https://www.ipsj.or.jp/annai/committee/education/j07/curriculum_j07.html その後、J17 に改訂。どちらも ACM CC2005 に基づく。最新は CC2020。 https://www.acm.org/binaries/content/assets/education/curricula-recommendations/cc2020.pdf
情報専門学科カリキュラム標準「J07」：4.ソフトウェアエンジニアリング領域(J07-SE), 2008 https://ipsj.ixsq.nii.ac.jp/ej/?action=repository_uri&item_id=60973 しかし我が国では，CSすら学んだことのない技術者と， 大学等でCSしか学ばずSEは学んでいない技術者によって 多くのソフトウェアが作り続けられているという問題を抱えている． 経験者 30.4% 理工系大学院 21.3% 理工系大学 16.9% 文系/短大等 11.5% 高等学校14.9% 高等専門学校 1.9% 専修/専門学校 2.1% 経済産業省、2008年版 組込 みソフトウェア産業実態調査 経 営者および事業責任者向け 2006年度採用実績より ※古いデータだが近年で 同様の調査がない
「いつかきた道」 と 「新たな課題」 識別のための体系参照 JEITA：”組込み系ソフトウェア開発の課題分析と提言”，2008 エンタープライズ系ソフトウェア開発において過去に経験してきて獲得してきた種々の取 組みやノウハウを役立てることができると思われるが、組込み系ソフトウェア 開発の現場が直面している問題は・・・ハードウェア開発と密に連携して・・・など 「いつかきた道」だけでは済まされない新たなソフトウェア開発上の課題である SE: ソフトウェア エンジニアリング 知識体系 SE∧EmbSE: いつかきた道の一部 EmbSE: 組込みのSE EmbSE∧¬SE: 新たな課題 EmbSE∧¬SE を識別するためには SE を識別する必要がある
体系を参照できていたか疑問が残る ● ● ● ● JEITA調査 ○ 参考文献に乏しい (2017のみ豊富) ○ 何を参照して課題を識別したか不明瞭のまま深堀り (結果、示唆は素晴らしい) ESxR ○ V字モデル＋管理を網羅しようとしているが抜けがある ○ 参考文献に乏しい (ESQR は豊富) ○ 更新されていない(特にESPRは2007で止まっている) ETSS/ETEC ○ コンピュータエンジニアリング(74%) ＞ ソフトウェアエンジニアリング(26%) ○ 古いESPR(2007)によって最新参考書(2021)の足が引っ張られている ○ 手薄領域について別の文献を参照させる記述もなし 組込み技術書 ○ コンピュータ構成、設計モデリング、コーディングに集中 ○ 要求、支援プロセス（プロセスモデル、マネジメント…）は手薄
ソフトウェアエンジニアリング(工学)体系の書籍例 ソフトウェアエンジニアリング基礎知識体系SWEBOK IEEE 2014...2003 ソフトウェア品質体系ガイド SQuBOK SQuBOK策定部会 2020…2007 実践的ソフトウェア工学 石田, 浅井 2019, 2009 CODE COMPLETE マコネル 2005 ソフトウェア工学 有沢 1988 Software Engineering: A Practitioner’s Approach Pressman 2019...1982 Software Engineering Sommerville 2015...1986 CMU/SEI, “Models for Undergraduate Project Courses in Software Engineering”, 1991, pp.20, Table 2: Commonly Used Software Engineering Texts https://resources.sei.cmu.edu/asset_files/TechnicalReport/1991_005_001_15932.pdf
Cambridge Dictionary: “engineering” the work of an engineer, or the study of this work 働き 学問 文部科学省、 ”工学系科学分野の研究動向（要旨） ”，2007 https://www.mext.go.jp/b_menu/shingi/gijyutu/gijyutu4/siryo/attach/1337416.htm ８大学工学部を中心とした 工学における教育プログラムに関する検討， 1998 http://www.eng.hokudai.ac.jp/jeep/08-10/pamph1.html 工学とは数学と自然科学を基礎とし、ときには人文社会科学の知見を用いて、 公共の安全、健康、福祉のために有用な事物や快適な環境を構築することを 目的とする学問である。 ● 電気工学、機械工学、土木工学・・・があるように ソフトウェアにも工学がある (1968～ とされる) ● それはどのようなものなのか？ 特に既存の組込み教育で手薄な領域に着目して紹介する
II. 実務/学術、モダン/温故知新のバランスに優れた体系 ～実践ソフトウェアエンジニアリング（第9版）の紹介～
Software Engineering: A Practitioner’s Approach ～実践ソフトウェアエンジニアリング（第9版）～ ※「本書」と呼ぶ ■書籍（第9版）構成→5部/30章＋ 2章のAppendix 第1部：The Software Process 第2部：Modeling 第3部：Quality and Security 第4部：Managing Software Projects 第5部：Advanced Topics Appendix：UML、データサイエンス ソフトウェアプロセス モデリング 品質とセキュリティ ソフトウェアプロジェクトのマネジメント 先進的な話題
推奨する理由 ● ● ● ● ● 組込み特化ではないが、 全般的に役立つカバー範囲、構成も無難 原著は約5年に1度最新の情報へ更新 累計300万部のベストセラー 米国では教科書採用され大学生から学習 そのため、わかりやすさが重視されている 第4版、第6版が邦訳されており、 旧版も含めて日本でも知られている 実事例、各種書籍の情報を取り入れ 専門職にも役立つ情報がまとまっている 第１章ソフトウェアとソフトウェアエンジニアリング 第１部 ソフトウェアプロセス 第２章 プロセス 第３章 アジャイルとプロセス 第４章 推奨のプロセスモデル 第５章 ソフトウェアエンジニアリングの人間的側面 第２部 モデリング 第６章 プラクティスの指針となる原則 第７章 要求エンジニアリング 第８章 要求分析モデリングの推奨手法 第９章 設計の概念 第１０章 アーキテクチャ設計の推奨手法 第１１章 コンポーネント設計 第１２章 UX設計 第１３章 移動体端末におけるソフトウェアの設計 第１４章 パターンに基づく設計 第３部 品質とセキュリティ 第１５章 品質の概念 第１６章 レビューの推奨手法 第１７章 ソフトウェア品質保証 第１８章 ソフトウェアセキュリティエンジニアリング 第１９章 ソフトウェアテスト－コンポーネントレベル 第２０章 ソフトウェアテスト－統合レベル 第２１章 ソフトウェアテスト－移動体端末と特定ドメインに対するテスト 第２２章 ソフトウェア構成マネジメント 第２３章 ソフトウェアメトリクスと分析 第４部 ソフトウェアプロジェクトのマネジメント 第２４章 プロジェクトマネジメントの概念 第２５章 実行可能で役立つソフトウェア計画 第２６章 リスクマネジメント 第２７章 ソフトウェアサポート戦略 第５部 先進的な話題 第２８章 ソフトウエアプロセス改善 第２９章 ソフトウェアエンジニアリングの新興トレンド 第３０章 おわりに
序文となる対話：ゲーム業界のソフトウェアエンジニアリング 本書はゲーム業界のエンジニア（青年）と原著者（博士）との対話からはじまる。 ゲーム開発においても、ソフトウェアエンジニアリングの知見をうまく取り入れて 改善し続けないと、ビジネスから撤退してしまうだろう、という内容。 ＜省略＞ 博士：（ 彼が首を横に振るだろうと予想しつつつ）ソフトウェアエンジニアリングの手法は何か使っているのかね？ 《彼は300 万行以上のコードで作られたアプリケーションの、ゲームプレイとAI 機能を担当していた。》 青年：（ ゆっくりと頷き）ニーズに応じてですが、もちろん使っていますよ。 ＜省略＞ 青年：（ 肩をすくめ）旧作のゲームのアーキテクチャを拡張し、適応させて、新しい製品を作ります。要件からコードを作成し、 デイリービルドでコードをテストし、他にも博士の本が勧めることをたくさんしなければならないですね。 博士：驚いた。私の本を知っているのかね？ 青年： もちろん、学校で使い、いまも参考にしています。役立つことがたくさん本の中にありました。 博士：君の同僚の何人かと話をしたが、私の本に書いてあることに対して懐疑的だったよ。 青年：（ 顔をしかめ）あのですね、僕たちは IT部門や航空宇宙会社にいるわけじゃないから、博士が提唱するものをカスタマイズしな いと使えないんです。でも肝心なところは同じで、高品質の製品を作らなければいけない。そして、繰り返し可能な方法で達成するに は、独自のソフトウェアエンジニアリング技術のサブセットを作り、適応させないとダメなんです。 今後、ゲームの規模がより大きく、より複雑になるのは確かです。そして、競争相手が増えれば開発期間も短くなります。 徐々に、ゲーム自体が僕たちに開発規律の適用を強いるようになるでしょう。そうしないと、僕たち終わっちゃいますからね。
知っておくと役立つ情報について、一部抜粋して紹介 部の構成自体はESxR（ESPR、ESDR、ESQR）と重なっているようにも見えるが… 過去からの優れた実践事例を取り入れて更新し続けてきた本書から、 組込みにおける学習体系を補完できると考えられる情報について一部抜粋して紹介 １. プロセス ２．プラクティスの本質となる問題解決への言及 ３．原則とモデリング ４．最新の情報の取り込み
その１－１：プロセスの要素・概念の理解 前提：規定プロセスをそのまま扱うのではなく、自分で考えるための知識を得る 特定プロセスを単純に守るのではなく、 プロセスの構造を理解できるようにする プロセスの構成要素、一般例を知り、 各プロセスを分析できるようにする ＜何に役立つのか＞ 実際に行っているプロセスの意味を知り、 自分たちのプロセスを理解し見直す そこから継続的な改善をできるようにする
その１－２：複数のプロセスの特徴を紹介 例えばウォーターフォール（第2章）：その適用しやすい条件 ある問題に対する要求が十分理解されていて、コミュニケーションからデプロイまで順に作 業を実施できる場合がある。こうした状況は、明確に定義された既存システムの修正や拡張 （例えば、政府の規制変更により必ず実施しなければならない会計ソフトウェアの修正等）で 発生する場合がある。
その１－２：複数のプロセスの特徴を紹介 例えばウォーターフォール（第2章）：適さない条件 特定の状況ではよいが、昨今よくある状況には適合しづらい、と明示されている。 →クライシス状況を考慮するとどうだったのだろうか。 1．現実のプロジェクトでは、モデルに示されているワークフローの順番どおり進行することは ほとんどない 2．プロジェクト開始時に顧客が要求事項をすべて明確に述べることは難しい 3．実際に動作するプログラムはプロジェクトの後半になるまで入手できず、顧客は辛抱強く 待たなければならない 4．プログラムが動く段階になるまで大きな問題が発見されない場合がある 今日、ソフトウェア開発はスピードが求められ、（機能やフィーチャ、情報コンテンツに対する） 変更の奔流に晒されている。ウォーターフォールモデルはこうした状況には適していない。
その１－２：複数のプロセスの特徴を紹介 プロセスは盲目的なものではない。 ソフトウェアエンジニアリングプロセスはソフトウェアチームが盲目的にしたがわなければな らない厳格な規定ではなく、俊敏（agile）であり、問題、プロジェクト、チーム、組織文化に対 して適応するものである。（第1章） 万能なプロセスは存在しない→状況にあわせて選択が必要となる。 現実としては、どのプロセスもあらゆるプロジェクトに適用できるような完璧なものではない。 （第2章） どのアジャイル手法もあらゆるプロジェクトに対して万能ではない。（第3章）
その１－２：複数のプロセスの特徴を紹介 各プロセスの特徴を紹介。適用しやすい範囲やプロセス構成の意味を知る。
その１－３：昨今の状況に適した推奨プロセス 変化が当たり前、要求自体を探索する 必要がある（VUCAの）状況において、 変化する状況に適応できるプロセスを ベースラインとして学習する（第4章） ＜何に役立つのか＞ 業務にて適用しているプロセスで 不足箇所を一般的な課題と共に把握し、 効果的・効率的に開発するための 改善へのベースラインとして活用する
その２：プラクティスの本質は問題解決 書籍の序盤で、問題解決の本質の重要性に触れている。 （How to solve it（いかにして問題を解くか）を参照） 問題解決の手続：（ソフトウェア開発との対応、第1章） 1．問題を理解する 2．解決策を計画する 3．計画を実行に移す 4．結果が正しいことを確認する ＜何に役立つのか＞ 手段やルールではなく、問題解決にソフトウェアエンジニアリングを 活用する根本的な原則を常に心にとどめる。
その３：原則とモデリング 単なるノウハウを記載したものでなく、 特定の技術を前提とした手順でもなく、 原則や課題を明示したうえで、 実践されているプラクティスや 各種モデリング手法を紹介している（第2部） ＜何に役立つのか＞ 技術の発展により手段が変わっても、 原則を考慮し柔軟な検討や 適切な技術の選択ができるようになる また、モデリング技術を身に付けて 確実な設計を進めるために役立つ ＜原則の例（他にも多数記載あります）＞ ■計画の原則 第1原則 プロジェクトのスコープを理解する 第2原則 ステークホルダを計画アクティビティに巻き込む 第3原則 計画は反復的であることを認識する 第4原則 わかっていることから見積りをする 第5原則 リスクを考慮する 第6原則 現実的に考える 第7原則 精度 /粒度を調整する 第8原則 どのように品質を保証するか決める 第9原則 どのように変更に対応するか決める 第10原則 頻繁に追跡し、必要に応じて調整する ■モデリングの原則 第1原則 ソフトウェア開発者の一番の目的はソフトウェアを 構築することで、モデルを作成することではない 第2原則 不必要なモデルは作らず身軽に進める 第3原則 ソフトウェアや、ソフトウェアの解決する問題を、 簡潔に説明するモデルを作ることに努める 第4原則 変更を取り入れやすい方法で作成する 第5原則 モデルを作成した動機を明確に説明できるようにする 第6原則 作成したモデルを目の前のシステムに合わせる 第7原則 完全なモデルのことは忘れて、役に立つモデルを作る 第8原則 モデルの記法を押し付けてはいけない。 情報を伝えることができているなら表現は後回しでよい 第9原則 たとえ紙面で見る限り正しくても、直感が間違いを 訴えるモデルには、注意を向けるだけの理由がある 第10原則 できるだけ早くフィードバックを得る
その４：比較的新しい情報の提供 原著自身、2004-5年段階（第6版）でWeb向け体系やアジャイル開発を紹介する等、 該当の時代によく使われている技術を紹介しつつ、比較的利用が少ない技術や、 当たり前となった技術と入れ替えている。 今回の新しい情報としては、次のようなものがある。 ・カンバンやDevOpsといった比較的新しい概念の紹介（第3章） ・「要求を探索する」開発スタイルに適したプロトタイピング、 進化型プロセスをベースとしたプロセスの紹介（第4章） ・User eXperience（UX）設計への取り込み（第12章） ・モバイル（移動体端末）を中心とした開発への言及（第13章、第21章） ・サーチベースのエンジニアリングなど新興トレンドの紹介（第29章） 原著第8版（英語）にあった次のような部分は本書（第9版）では消えている ・Webとモバイルを区別した構成 ・形式手法を中心とした技法の紹介
該当体系のポイント紹介 より実践で役立った事例等から 技術が取り込まれ、時代に即したベースライン となる情報としてまとまっている（右の赤字） 昔から変わらず重要な部分は残り続けている ※マネジメント、品質の概念、テストなど 第１章ソフトウェアとソフトウェアエンジニアリング 第１部 ソフトウェアプロセス 第２章 プロセス 第３章 アジャイルとプロセス 第４章 推奨のプロセスモデル 第５章 ソフトウェアエンジニアリングの人間的側面 第２部 モデリング 第６章 プラクティスの指針となる原則 第７章 要求エンジニアリング 第８章 要求分析モデリングの推奨手法 第９章 設計の概念 第１０章 アーキテクチャ設計の推奨手法 第１１章 コンポーネント設計 第１２章 UX設計 第１３章 移動体端末におけるソフトウェアの設計 第１４章 パターンに基づく設計 第３部 品質とセキュリティ 第１５章 品質の概念 第１６章 レビューの推奨手法 第１７章 ソフトウェア品質保証 第１８章 ソフトウェアセキュリティエンジニアリング 第１９章 ソフトウェアテスト－コンポーネントレベル 第２０章 ソフトウェアテスト－統合レベル 第２１章 ソフトウェアテスト－移動体端末と特定ドメインに対するテスト 第２２章 ソフトウェア構成マネジメント 第２３章 ソフトウェアメトリクスと分析 第４部 ソフトウェアプロジェクトのマネジメント 第２４章 プロジェクトマネジメントの概念 第２５章 実行可能で役立つソフトウェア計画 第２６章 リスクマネジメント 第２７章 ソフトウェアサポート戦略 第５部 先進的な話題 第２８章 ソフトウエアプロセス改善 第２９章 ソフトウェアエンジニアリングの新興トレンド 第３０章 おわりに
該当体系のポイント：参考文献 ・本書は多数の参考文献（書籍、論文）を引用している。 より詳細の情報を知りたい方は、特定分野の 説明から参考文献を辿るのもよい。 ・参考文献数は約560件。 ・邦訳されている書籍も多数あり（以下はほんの一部） 参考文献の引用例
[回想] もしあのとき本書に出会っていたら・・・ 1．本書確認前に要件を引き出すために 業務モデリングとペーパープロトタイプを活用した プロセスを苦労して構築していた。 ※参考：https://www.slideshare.net/NoriyukiMizuno/rdra-236183496 …が、普通に教科書と言える本書に載っていた…_（:3 」∠)_ 2．品質向上の施策として、テスト設計、自動化を組み合わせた 改善活動を試行錯誤して成果は出たのだが、 体系的な知識をもっていればもっと短期間で うまくできたのではないか？と感じている ■考案したプロトタイピング手順 ・ヒアリングで複数案を出す ・複数案を簡易に絞り込み ・（ペーパー）プロトタイプで表現 ・（顧客込み）評価して決定する
III. 体系は更新される財産
クイズ：金づちとのこぎりで小屋は建つでしょうか？ あなたが大工だとします。 問題： 金づちとのこぎりだけで 小屋は立てられるでしょうか？
クイズ：金づちとのこぎりで小屋は建つでしょうか？ あなたが大工だとします。 問題： 金づちとのこぎりだけで 小屋は立てられるでしょうか？ 答え： 気合があればなんとかなる しかし、ビルは？
体系を学ぶ意義 「伝承を知識にまとめ、思考を体系にまとめることは、人間の能力を卑しめてマニュアル に置き換えることと誤解されがちである。もちろん、そのような試みは、ばかげている。 しかし、体系的な知識は、きょうの医者に対し、一〇〇年前の最も有能な医師以上の能 力を与え、今日の優れた医師に、昨日の医学の天才が想像もしなかった能力を与える。 いかなる体系も、人間の腕そのものを伸ばすことはできない。 しかし、体系は、先人の力を借りて常人を助ける。常人に対し、成果を上げる能力を与え る。有能な人間に卓越性を与える。」 「創造する経営者」 P.F.ドラッカー
体系を学ぶ意義 「かのマーク・アンドリーセン曰く、もはや"Software is eating the world." である。ソフトウェア・エンジニ アリングとは、物凄いスピードで変わっていく題材を扱う工学分野である。 理論物理学や理論化学のように数理モデルで説明や予測を行う世界ではない。むしろ 世界中の技術者 が実践しているプラクティスの体系化の意味合いが強い工学的分野であって、理論先行ではない。 そうい う意味では、スポーツ理論や音楽理論などのアプローチに近いかもしれない。 しかし、この体系化され形式知化され共有されることほどパフォーマーたる我々技術者にとって有用なも のはない。スポーツ選手がスポーツ理論を学んでより高いパフォーマンスを出せるよう、音楽家が音楽理 論を学んでより印象的な演奏ができるよう、ソフトウェア技術者もソフトウェア・エンジニアリングを学びより 良いソフトウェアを作ることができる。 プレスマンのSEPA は世界で最も体系的・網羅的に視野を広げてくれる書籍として40 年にわたって改定 が続けられてきた。ソフトウェア技術者なら、この財産を活用しない手はない。」 「実践ソフトウェアエンジニアリング第9版」 榊原 彰
ソフトウェアエンジニアリング ＝ 実践的ノウハウ ソフトウェアエンジニアリングとは、次の特徴を持つ ● ● ● 実践先行である グッドプラクティスが知識化され、体系化される ソフトウェアエンジニアに、 成果を出す手助けをし、卓越性を与える ソフトウェアエンジニアリングを学ぶことは、すなわち業界で実績あるノウハウを学ぶことである なにより、長らくメンテナンスし続けられている体系は、強いノウハウである ソフトウェアエンジニアリングを学ぶことで、世界の標準レベルをキャッチアップできる
（参考）体系を学んできた学生の価値 現在は、特に海外の大学教育において、ソフトウェアエンジニアリングを体系的に学ぶこ とが当たり前となっている。 入社した時点で、新人にソフトウェアエンジニアリングの知識があると たとえ実践と紐づいていないとしても、次のような良い効果を得られる ● ● ● 新人教育コストの削減（ベース知識はすでに持っている状態） 現場配属後、技術面の立ち上がり期間の短縮 （技術概要や用語等、テクニカルコミュニケーション構築の労力低減） 最新の体系の社内へのインプット （体系にまとめられた最新ノウハウの持ち込み） 体系を学んできた新人は、 技術面の効果はもちろんとして、 効率やコストの改善、キャッチアップという面でも メリットしかない
体系は変化し続ける、常識は変わり続ける 「かのマーク・アンドリーセン曰く、もはや"Software is eating the world." である。ソフトウェア・エンジニ アリングとは、物凄いスピードで変わっていく題材を扱う工学分野である。 理論物理学や理論化学のように数理モデルで説明や予測を行う世界ではない。むしろ 世界中の技術者 が実践しているプラクティスの体系化の意味合いが強い工学的分野であって、理論先行ではない。 そうい う意味では、スポーツ理論や音楽理論などのアプローチに近いかもしれない。 しかし、この体系化され形式知化され共有されることほどパフォーマーたる我々技術者にとって有用なも のはない。スポーツ選手がスポーツ理論を学んでより高いパフォーマンスを出せるよう、音楽家が音楽理 論を学んでより印象的な演奏ができるよう、ソフトウェア技術者もソフトウェア・エンジニアリングを学びより 良いソフトウェアを作ることができる。 プレスマンのSEPA は世界で最も体系的・網羅的に視野を広げてくれる書籍として40 年にわたって改定 が続けられてきた。ソフトウェア技術者なら、この財産を活用しない手はない。」 「実践ソフトウェアエンジニアリング第9版」 榊原 彰
主だった体系の改版状況 1990年 2000年 2010年 2020年 New!! PMBOK SWEBOK 1996年 V1 2000年 V2 2001年 V1 2004年 V3 2008年 V4 2004年 V2004 2013年 V5 2017年 V6 2021年 V7 2014年 V3 202?年 V4 New!! SQuBOK 2007年 V1 2014年 V2 2020年 V3 体系はソフトウェア開発を取り巻く情勢や技術の変化に対応して、常に更新され続ける。 また、陳腐化したノウハウや技術はトピックから落とされ、新たに価値があると認められたものが最新の体系に反映される。 自身が学んだ最新の体系が過去版である場合、それは世の中の標準から遅れをとっているということかもしれない。
「実践ソフトウェアエンジニアリング」における体系の変化 第９版（日本語版 2021年） 第６版（日本語版2005年） 第４版（日本語版 2000年） オブジェクト指向 技術がホット 第１部 製品とプロセス 第１章 製品 第２章 プロセス 第２部 ソフトウェアプロジェクトの管理 第３章 プロジェクト管理の理念 第４章 プロセスとメトリクス 第５章 ソフトウェアプロジェクトの計画立案 第６章 リスク管理 第７章 プロジェクトのスケジューリングと追跡 第８章 ソフトウェアの品質保証 第９章 ソフトフェア構成管理 第３部 ソフトウェア工学の伝統的手法 第１０章 システム構想設計 第１１章 要求分析の基本概念と原則 第１２章 要求分析モデル 第１３章 設計の基本概念と原則 第１４章 設計の手法 第１５章 リアルタイムシステムの設計 第１６章 ソフトウェアテスト技術 第１７章 ソフトウェアテスト戦略 第１８章 技術的なソフトウェアメトリクス 第４部 オブジェクト指向ソフトウェア工学 第１９章 オブジェクト指向の基本概念と原則 第２０章 オブジェクト指向分析 第２１章 オブジェクト指向設計 第２２章 オブジェクト指向テスト 第２３章 オブジェクト指向システムの技術的メトリクス 第５部 ソフトウェア工学の進んだ話題 第２４章 フォーマルメソッド 第２５章 クリーンルーム開発 第２６章 ソフトウェア再利用 第２７章 リエンジニアリング 第２８章 クライアント・サーバソフトウェア工学 第２９章 CASE：コンピュータ支援ソフトウェア開発 第３０章 進むべき道 新たな話題として、 アジャイル開発、 アーキテクチャ設 計、ユーザインタ フェース、Webエン ジニアリング、プロ ジェクトマネジメン トなど 第１章ソフトウェアとトウェアエンジニアリング 第１部 ソフトウェアプロセス 第２章 プロセス 第３章 規範的なプロセスモデル 第４章 アジャイル開発 第２部 ソフトウェアエンジニアリングの実践 第５章 プラクティス －一般的な考え方 第６章 システムエンジニアリング 第７章 要求エンジニアリング 第８章 要求分析モデリング 第９章 設計エンジニアリング 第１０章 アーキテクチャ設計 第１１章 コンポーネントレベル設計 第１２章 ユーザインタフェース設計 第１３章 ソフトウェアテスト戦略 第１４章 ソフトウェアテスト技術 第１５章 成果物に関するソフトウェアメトリクス 第３部 Webエンジニアリングの適用 第１６章 Webエンジニアリング 第１７章 Webエンジニアリング他のための定式化と計画 第１８章 Webアプリケーションのための分析モデリング 第１９章 Webアプリケーションの設計モデリング 第２０章 Webアプリケーションのテスト 第４部 ソフトウェアプロジェクトの管理 第２１章 プロジェクトマネジメントの概念 第２２章 プロセスとプロジェクトのメトリクス 第２３章 ソフトウェアプロジェクトの見積もり 第２４章 ソフトウェアプロジェクトスケジューリング 第２５章 リスクマネジメント 第２６章 品質マネジメント 第２７章 変更管理 第５部 ソフトウェアエンジニアリングの先進トピック 第２８章 フォーマルメソッド 第２９章 クリーンルーム開発 第３０章 コンポーネントベース・ソフトウェアエンジニアリング 第３１章 リエンジニアリング 第３２章 進むべき道 新たな話題とし 第１章ソフトウェアとソフトウェアエンジニアリング 第１部 ソフトウェアプロセス て、人間的側面、 第２章 プロセス モデリング、ユー 第３章 アジャイルとプロセス 第４章 推奨のプロセスモデル ザエクスペリエン 第５章 ソフトウェアエンジニアリングの人間的側面 ス、移動体端末。 第２部 モデリング 第６章 プラクティスの指針となる原則 品質とセキュリ 第７章 要求エンジニアリング 第８章 要求分析モデリングの推奨手法 ティが独立した章 第９章 設計の概念 となり、大きくス 第１０章 アーキテクチャ設計の推奨手法 第１１章 コンポーネント設計 ポットが当たって 第１２章 ユーザエクスペリエンス設計 いる。 第１３章 移動体端末におけるソフトウェアの設計 第１４章 パターンに基づく設計 第３部 品質とセキュリティ 第１５章 品質の概念 第１６章 レビューの推奨手法 第１７章 ソフトウェア品質保証 第１８章 ソフトウェアセキュリティエンジニアリング 第１９章 ソフトウェアテスト－コンポーネントレベル 第２０章 ソフトウェアテスト－統合レベル 第２１章 ソフトウェアテスト－移動体端末と特定ドメインに対するテスト 第２２章 ソフトウェア構成マネジメント 第２３章 ソフトウェアメトリクスと分析 第４部 ソフトウェアプロジェクトのマネジメント 第２４章 プロジェクトマネジメントの概念 第２５章 実行可能で役立つソフトウェア計画 第２６章 リスクマネジメント 第２７章 ソフトウェアサポート戦略 第５部 先進的な話題 第２８章 ソフトウエアプロセス改善 第２９章 ソフトウェアエンジニアリングの新興トレンド 第３０章 おわりに 過去に体系を学んだことで満足せずに、 常に学び続けることが大切である
クイズ：金づちとのこぎりでビルは建つでしょうか？ あなたが大工だとします。 問題： 金づちとのこぎりだけで ビルは立てられるでしょうか？ 答え： さすがにそれだけではできない。 様々な道具が必要。 つまり、道具箱のようなものが必要となってくる それが体系、ということであり、 更新し続けること、学び続けることが大切 最新の中身に更新し続ける
参考事例：体系を使った、組織や個人の技術力成熟度判定 体系は、学びに利用できるが、 応用として技術力の成熟度判定モデルとして 利用することもできる。 ・簡単に、すぐに取り組める ・技術者個人を対象とする ・目次をそのまま評価項目とする ・ETSSと併用するために、フレームを合わせる ・個人に入力してもらうことそのものが、 すでに学習効果である
体系を技術成熟度モデル化した例 章・節を項目とする。 （項もいれて 3段階でもよい） 章 ソフト ウェア プロセ ス 節 ETSSにあわせたレベル設定。 ただし、レベル０を追加し、各レベルの定義を再定義 レベル０ レベル１：初級 レベル２：中級 レベル３：上級 レベル４：最上級 当該技術を知らない 技術を知っている 支援のもとに技術を利用できる 技術を他人に説明できる 自律的にその技術を利用できる 技術を他人に指導できる 技術を応用し、高度な利用ができる 技術をもとに、さらに新たな技術を 開発できる プロセス アジャイルとプロセス 推奨のプロセスモデル ソフトウェアエンジニアリングの人間的側面 モデリ ング プラクティスの指針となる原則 要求エンジニアリング 要求分析エンジニアリングの推奨手法 設計の概念 アーキテクチャ設計の推奨手法 ・・・ 各項目について塗りつぶしをしてもらう。 各項目の一番高いレベルの欄に、具体的に、 どのように技術を使っているか記入してもらう のもよい。
体系をチームビルドに生かす（チームのレベル状況可視化） ①個人で記入 ②集約して平均化 ③施策検討 ■ベテラン ■中堅 ■新人 チーム全体としてみると、ほとんど の項目が上級レベルにない。 今回のプロジェクトで必要とされるレベルを 満たしているかどうかを見える化し、 もし不十分であればメンバーの入れ替えや増員、 レベルアップのためのトレーニングを施策化する
体系をチームビルドに生かす（チームメンバー選定） ■ベテラン ①チームとして必要なレベルを決定 ②メンバーを選定 ■中堅 ■新人 他のＥＴＳＳ等のモデルと併用し、 ソフトウェアエンジニアリング面か らもメンバ選定する
IV. 体系の外側 ～いつかきた道ではない新たな道～
本書29章：ソフトウェアエンジニアリングの新興トレンド どのような変化が訪れたとしても、これまでの私たちの努力が幼稚に見えるほどのソフト ウェアやシステムが必要になるだろう。2040年には、超絶的な計算機、人工知能と機械 学習、ナノテクノロジー、広帯域のユビキタスネットワーク、ロボティクスが組み合わさり、 今とは全く異なる世界が実現するだろう。 そのとき、ソフトウェアは現在と同じく時代の核として存在し続けるが、その形態は私た ちがまだ理解していないものであろう。だとしても、ソフトウェアエンジニアリングはあり続 けるだろう。 劇的な進化はやってくる。私たちも進化を実現する主体である。 何が、なぜ、どのように進化するのか、させたいのか。 その理解と合意形成は難しく、知識不足ゆえに進路を惑わされることがある。 体系的知識があれば、バズワードや誇大広告としての DX や AI に惑わされることはない。 ソフトウェアエンジニアリングは、長期的に見た劇的な進化の中で漸進してゆくだろう。
本書29章：ソフトウェアエンジニアリングの新興トレンド ビジネス 組織 テクノロジー 次の10年～ 市場 文化 ソフトなトレンド メソドロジー ハードなトレンド 本章では、ソフトウェアエンジニアリングにおけるいくつかのトレンドに触れる。 ただし、着目することは技術そのものというよりも、次の10年～20年にわたって 重要な影響をもたらす、ビジネス、組織、市場、そして文化的なトレンドである。 本講演では以下を抜粋し、講演者の意見も交えて紹介： 「協働型開発」 「複雑さの克服」 「ソフトウェアプロセス改善」
協働型開発 母語 リモートワーク プロセスモデル ツール 非常勤雇用 グローバル化 文化 タイムゾーン マネジメント階層の減少 サイロの解消 個別チームのアジリティ 組織のガバナンス グループウェア グロースマインドセット 全てのステークホルダは・・・目的、要求、設計の問題・・・あらゆる情報を共有・・・ 協働とは、タイムリーな情報拡散と、意思疎通と意思決定のプロセスを含む。 [参考] ICGSE: International Conference on Global Software Engineering https://conf.researchr.org/home/icssp-icgse-2021
協働型開発：プロセスモデル面 JEITA調査(2007)で ハード部門との連携を示唆 その後プロセスモデルは 何年か扱われず JEITA調査(2017)で RUP for SE を参照し プロセスモデルに言及 家庭用ゲームでの 事例報告あり(CEDEC 2020) https://www.famitsu.com/news/2020 09/04205271.html J. A. Estefan, “Survey of Model-Based Systems Engineering(MBSE) Methodologies”, INCOSE, 2008, http://www.omgsysml.org/MBSE_Methodology_Survey_RevB.pdf
協働型開発：ツール面 - 社内IT化 チケット リポジトリ パッケージ マネージャ CI Web API IDE ● 開発者の個人プレー ● 社内に閉じている ● スタンドアロン ● 多職種のチームワーク ● インターネットへの接続 ● パイプライン 前田, 重岡: “製造業のためのソフトウェア戦略マネジメント入門 ”, 2003, p.178, 統合ネットワーク支援環境 開発部門だけでなく 社内IT部門の協力も必要
協働型開発： 関連 - 技術者採用・定着のための環境投資 StackOverflow Developer Survey 2020 (N≒65000 🌏アメリカとインドで1/3、ほか多数) 仕事選びで何を重視する？TOP5 (上位3つ選択) 51.3% 携わる技術 (プログラミング言語、フレームワークなど) 44.5% オフィス環境、企業文化 43.9% 働く時間の自由さ 41.4% 開発実務に携われること 33.3% リモートワーク選択の自由 好きなプログラミング言語 86.1% Rust 67.1% TypeScript 62.3% Go ・・・ 44.1% Java 使用コラボレーションツール 82.8% GitHub 53.0% Slack 47.7% Jira 41.5% G Suite 37.0% GitLab 32.4% Confluence 環境が悪化すると技術者が退職する例 66.7% Python 43.4% C++ 62.9% Kotlin 33.1% C 新しい仕事を探しているか？ 57.6% 探してないが良い機会があれば検討 25.1% 新しい仕事に興味なし 17.3% 積極的に探している ・6年勤めたNTTを退職しました ・12年勤めたNTTを退職しました
複雑さの克服 設 計 新 興 ト レ ン ド 11 章 システムに存在する技術的負債と、その維持コストを自動的に特定できれ ば、対象となるコンポーネントのリファクタリングに費やす時間を確保するよ う、開発者と経営陣を説得しやすくなるだろう。 複雑なシステムの全てが巨大というわけではない。10万行未満の比較的 小さなアプリケーションでさえ複雑すぎるのだ。 29 何万もの要求、制約、制限の分析において、矛盾をなくし、曖昧さを 章 排除し、漏れをなくし、エラーを正すことができるのだろうか。 将来は、超絶的な複雑さを克服するためにAIが広く使われるだろう・・・ 研究畑生まれのリポジトリマイニングは実務で使われつつある。
複雑さの克服：リポジトリマイニングによるテスト最適化の例 Hu aw ei プロダクトコードの変更履歴、自動テスト実行履歴から、 ①次のテストの成否を予測、②類似テストケースの発見（振る舞いと入力の類似） ③プロダクトコードとテストケースの関係を予測 Tony Chang: “Data Intelligence Enables Intelligent R&D”, ICST 2019 Industry Track Keynotes Fa ce b oo ビルド依存グラフと静的解析によるプロダクトコード：テストコード関係特定に加え k XGBoost を用いたテストケース推薦技術を開発、自動テストのFlakiness対応 M. Machalica, A. Samylkin, M. Porth, S. Chandra: “Predictive Test Selection”, ICSE 2019 ● 失敗しそうなテストケースのみ実行することは複雑さの克服につながる省力化 ○ ● ● 複雑なプロダクト /テストであっても → テスト実行時間短縮，リファクタリングの安全性向上 前提：広範な自動テスト実行/管理の整備、学習データとしての開発履歴 組込みにおける海外の自動テスト事例は OSSJ/ALS で発表される例あり ○ 産業用Linuxボードテスト事例， ビデオ自動テスト事例
ソフトウェアプロセス改善 (SPI：Software Process Improvement) 28 章 CMMIは・・・大変意義のある成果である・・・あるべきアクションについて話し合う土 台となる。 どれだけ考え抜かれたプロセスであっても、有能でやる気のある人材がいなければ 成功しない。People CMMでは人的組織のコンピテンシーと文化を・・・ 揺れ動くビジネスにおける高速なソフトウェア開発では、長期的なSPIの戦略は続か ない・・・製品の短期目標を重視したフレームワークに置き換える必要がある・・ 29 章 SPIを成功させるためには、社会学と人類学の専門性を活かすことが技術的規律を 守ること以上に重要である。・・・変化をもたらす効果的な方法について、集団を扱う 社会学から学べることが多いだろう。
ソフトウェアプロセス改善：単体テストすら非自動からの道 長尾(訳), J.Whittakerほか(著)：”テストから見えてくるグーグルのソフトウェア開発”, 2013, まえがきより 私たちは・・・JUnitなどのツールを使ってテストを自動化することを・・・推奨した しかし、それらの動きは遅く・・・デベロッパーたちは、十分なテストをするには、 テスト対象のコードの1行に対して2、3行の単体テストコードを書かなければならず ・・・同じくらいのメンテナンスが必要・・・ということを認識していたのだ 2007 トイレにテストのtipsを貼る取組みを ブログ掲載 “Testing on the Toilet” 2019 トイレでツールを紹介すると 利用者が激増したという論文発表 “Do Developers Learn New Tools On The Toilet?”, ICSE 2019 https://research.google/pubs/pub47861/ 継続的な活動に脱帽。これも “集団を扱う社会学 ” かもしれない。 2011 M. Striebeck: “Creating a testing culture”, European Lean IT Summit, 2011 https://www.slideshare.net/operaepartners/creating-a-t esting-culture-by-mark-striebeck
ほか、(案外)本書に載っていないこと デプロイの手法 ・A/Bテスト ・カナリアリリース ・ローリングアップデート 監視の手法 ・サイトリライアビリティ エンジニアリング ・オブザーバビリティ 並行/並列処理の 設計/テスト手法 処理の実現方法は あふれるほどあるが 「複雑さの克服」方法、 複雑さの表現方法に乏しい ソフトウェアプロセス モデリング ? 品質とセキュリティ ソフトウェアプロジェク トのマネジメント プログラミング言 形式手法 語選定 過去版にあり 過去版にあり マネジメント3.0 InnerSource
体系の外を開拓する兆しは多く見える。ただし・・・ 本書29章より 業界の権威はこうした新技術の重要性を吹聴し、専門家はその技術を積極的に 採用する。最終的にその技術は・・・何らかの役割を果たすようになるが 謳い文句通りの効果は得られず、探求は続く傾向にある。 本書30章より 先へ進む道には、誇大広告にもかかわらず実際にはうまくいかなかった エキサイティングな新テクノロジーが死屍累々と転がっている では、自ら体系の外を開拓するか？誰かの開拓を待つか？
本書29章より： 技術のイノベーションサイクル (BRETAM sequence) 普 及 率 黎明期 模倣期 経験期 期 待 度 理論化 自動化 成熟期 期 期 過度な 期待 安定 啓発 黎明期 実証的研究 2010 i, 2013 ii TDD 2002 幻滅 本書29章より：ガートナー提唱のハイプ・サイクル User Story (in XP) 1998 Backlog (in Scrum) 2001 普及, 事例蓄積 実証的研究 2019 iii 提唱から実証的研究まで時間を要す例 [i] B.Turhan, L.Layman, “How Effective is Test-Driven Development”, Making Software, O’reilly Media, 2010 [ii] S.Makinen, J.Münch, “Effects of Test-Driven Development: A Comparative Analysis of Empirical Studies”, 2013 [iii] T.Sedano, P.Ralph, C.Péraire, “The Product Backlog”, 2019
普 イノベーター， アーリーアダプター及 ・トップの可能性↑ ・ブランディング ・継続的投資必要 (単発回収不可) ● ● ● ● 率 これ どうよ やって みた 書籍， 経験 発表 黎明期 模倣期 経験期 学術 実証， 反証 定番 ツール 理論化 自動化 成熟期 期 期 レイトマジョリティ， ラガード ・より確実な導入 ・費用少 ・永遠の三流 ・学びと創造の 楽しみの放棄 体系化が進んだ技術であるほど非競争領域 最先端技術は学術機関よりも先端的企業の現場から生まれる可能性 技術者の採用と定着への影響を考慮する（先述：環境を重視する） 調査に留めるか、味見くらいするか、本腰を入れるか、あえて待つか・・・
the work of an engineer, or the study of this work 事例発表 論文 OSS貢献 コミュニティ 社用 /個人ブログ 体系は地図と羅針盤。目的地は自身で定める必要がある。整備された道ほど走りやすい。 道中、小石を取り除く者もいれば、舗装する者も、新たな道を開拓する者もいる。 道の整備と開拓に貢献する者ほど、道の意味を深く理解し、価値ある進路を見出すだろう。
総 括 ● I. 日本の組込みソフトウェア教育では ソフトウェアエンジニアリング体系が参照されていない疑惑 ○ ● II. 実務/学術、モダン/温故知新のバランスに優れた体系 ○ ● 実践ソフトウェアエンジニアリング第 9版(本書)が体系の学習に適した書籍だと説明した III. 体系は更新される財産 ○ ○ ● 業界としての組込みソフトウェア教育に至る 2000年代からの歴史的経緯を説明し、 課題分析と教材内容におけるソフトウェアエンジニアリング体系非参照の疑惑を指摘した ドラッカーと本書の推薦文を参照し、体系は更新される財産だと説明した 本書を用いた成熟度判定方法を説明した IV. 体系の外側～いつかきた道ではない新たな道～ ○ ○ 本書で新興トレンドを扱う章を参照し、新たな道の兆しをいくつか説明した 道の整備と開拓に貢献してほしいと説いた
おわりに 継続的に開発をしていく場合、さらに品質のよい開発を目指す場合に、チームや組織にソフトウェアエンジ ニアリングの知識があると、効果的に活動できるはずです。 是非とも学んでいただき、ビジネス価値の高い開発を、楽しく続けていきましょう。 水野 昇幸 ソフトウェアエンジニアリングは実績ある開発道具箱です。 すでに実績ある足腰を強くするためのノウハウは、再発明せずに活用することが大切です。 ぜひ道具箱を手に入れて、品質高く、効率がよい、幸せな開発を手に入れましょう。 池田 暁 組込みならではの課題があるでしょう。製造業ならではの課題があるでしょう。 家電と自動車と工場設備では課題が異なるでしょう。それでもなお、うちの業界は、うちの会社は特殊だと 思わずに、使えるものは使う姿勢が幸を呼ぶでしょう。 金子 昌永 我々は本書籍や体系を広めていきたいと考えております。 もし我々の企業内でも講演してほしい、議論したい、等ありましたらお気軽にご連絡ください！
当日のQ&A（補足込み）：Q1 Q：今回紹介いただいたSEとは別に組込み向けのEmb SEは、共通要素として成立する ものでしょうか。組込み向けのSEは発散して収束しない可能性もあると感じます。 A（水野）： 紹介した体系の大部分の要素は組込み向けの共通要素としても成立すると考えております。 感覚的には7割程度は共通化できると考えております。 プロセス、品質技術の大部分、マネジメントといった箇所に関してはほぼ共通的な内容と言えます。 今回紹介した書籍で共通要素としづらい部分としては、組込みや System of Systems向けのモデリング要素、 組込み特有の制約を考慮した設計（ただ、こちらは CE側である程度フォローされている）があります。 これらの特有部分についてはあらゆる企業向けに要素を出していくと、ご意見の通り収束しない可能性があると 思われます。「組込み向け」技術というよりも、「製品特有」技術と捉えていただき、残り 3割となる技術を各企業 や職場で補完していただく方がよいかもしれません。
当日のQ&A（補足込み）：Q1 Q：今回紹介いただいたSEとは別に組込み向けのEmb SEは、共通要素として成立する ものでしょうか。組込み向けのSEは発散して収束しない可能性もあると感じます。 A（金子）： これはものすごく重要な質問です。感覚的には 7割くらい共通でしょう。この感覚とは、多少の応用で済むものが どれほどあるか、大幅な応用が必要なものがどれだけあるか、という見積もりの感覚です。仮に同じ応用方法 に辿り着いた人々がいたとき、基礎として採用できることを重視する人「土台は一緒だろ？」、応用が必要なこと を重視する人「組込みならではのことが多い！」に分かれる可能性があります。 本書でいえば全章組込み向けに応用可能と考えています。ツールも、 VSCode, Git, CppUTest, GitLab, Doxygen, PlantUML など業界を問わず使えるものが豊富にあります。ただし、以下に代表される組込み・製造 業ならではの特徴を考慮して応用する必要があります。これらを考慮したエンジニアリングを実現する労力や技 術要素としての大きさの感覚によって、何割共通するとみなすかが変わってくるのだと思います。私からすれば 多少の応用で済むことの方が多く思えます。 7割とはそういう意味です。また、応用可能と構えた方が応用の機 会を見逃しにくく、業界規格準拠を謳うツールベンダーに高値を掴まされることも減るでしょう。 ●製品ライフサイクル (1年？20年？) ●製品ラインナップ (A社向け、B社向け、ハイエンド、ローエンド …) ●製品と部品の価格 ●ユーザーの特 徴（一般消費者、医者、建設業者 …） ●求められる品質特性（セーフティ、ハードリアルタイム …） ●アップデートの市場需要（日々便利に、 1 年は変えないで …） ●アップデートの技術的可能性（オンラインアップデート可否） ●ハードウェア開発プロセスと組織 ●試作機の配備容易性 （1人1台、30人1台…） ●製品の計算機資源 ●GUIの有無 ●業界標準・慣習（ Automotive SPICE, FDA査察）…
当日のQ&A（補足込み）：Q1 Q：今回紹介いただいたSEとは別に組込み向けのEmb SEは、共通要素として成立する ものでしょうか。組込み向けのSEは発散して収束しない可能性もあると感じます。 A（池田）： 体系の大部分は組込み等ドメインがどうであれ共通要素として成立します。今回紹介した実践エンジニアリング の体系はソフトウェアエンジニアとしての一般教養であるからです。 ただ、どの程度共通かというと「組込み」をどの程度のスコープで捉えるかによって、その共用知識が全て共通 なのか、大部分が共通なのか、一部は共通なのか、が変わってきます。 なお、組込み向けの SEが発散して収束しない可能性はその通りです。今回紹介した体系も収束せず変わり続 けています。組込み向け SEとしてはESxR等がありますが、これを更新をしたり、各社が自社の競争力を所持す るために自社オリジナルの体系を（世の中の知見や経験、ノウハウを広く取り入れながら）メンテナンスしていく ことは地道ですが大切ですし、取り組まないと置いていかれることは意識したほうが良いでしょう。
当日のQ&A（補足込み）：Q2 Q：日本はアメリカと違って入社後に企業が教育する文化？が強いと思います。この本 相当の教育が大学でできていない、とするならば、企業の教育に取り入れるしかないと 思うのですが、それは現実的でしょうか。考えられる障害についてもコメント頂けると幸 いです。 A（水野）： 目先の状況を考えると、ご意見いただいたように各企業の教育に取り入れることになると考えております。 懸念されることとしては、分量が多いため教育の時間がかかるといったことがあるかもしれません。 比較的大きな企業では、新人 /初等教育、中堅教育、プロフェッショナル教育という分け方をしておりますので、 そこに参考書なり講座としてソフトウェアエンジニアリングを取り入れて頂ければと思います。 ※例えばダイキンさん辺りは、自前の教育をするため、ダイキン情報大学というものを立ち上げております。 参考：https://www.daikin.co.jp/press/2017/20171205/ ここまでの意見を出すと「小さい企業ではムリだ …」と感じてしまうかもしれません。その場合だとしても、 社内の有志で勉強会を開いて学習を進めるといった方法もあります。 （自分も企業におりましたが、チームで昔の第 6版書籍を用いて勉強会をやっておりました） トップダウンにせよ、ボトムアップにせよ、技術やそれを学ぶことに興味がある人から育つものですので、 適切な技術を取り込んで紹介、教育を進めて頂ければと思います。
当日のQ&A（補足込み）：Q2 Q：日本はアメリカと違って入社後に企業が教育する文化？が強いと思います。この本 相当の教育が大学でできていない、とするならば、企業の教育に取り入れるしかないと 思うのですが、それは現実的でしょうか。考えられる障害についてもコメント頂けると幸 いです。 A（金子）： 製造業ではありませんが実例をいくつか紹介します。少なくとも継続性については現実的と判断します。 ●DeNA 2013: みんな幸せ！ 「自走できるエンジニア」を育成するDeNAの新卒研修 ●DeNA 2021: 新卒エンジニア研修で得られる一番の価値とは？ ●SEGA 2017: そうだ、勉強会を開こう ●SEGA 2019: GDC報告会に見るセガの学習機会と共有の取り組み ●Cookpad 2015: クックパッドの新卒研修2015 ●Cookpad 2018: 総合職・デザイナー向け技術基礎研修2018 (同様の教育をしている製造業もあると想像しますが、すぐ見つかるように公開された情報がありません ) 社外の熟達した講師のもとで講義と演習に取り組める機会として トップエスイー があります。ソフトウェア品質に 特化した内容であれば SQiP研究会 があります。どちらも 1年コースで数十名が受けているそうです。 考えられる障害は（残念ながら経験したものも含む）、教育者は昔のエースであり今の技術に疎い、真にふさわ しい教育者は開発に没頭している、被教育者も目先の開発が優先される、覚えたことを実践する組織的な仕組 みがない…。そうした障害との勝負で明暗が分かれた企業のどちらも現実にいるのだと思います。
- https://codezine.jp/article/detail/7663
- https://engineer.dena.com/posts/2021.07/21-new-graduates-training-operation/
- https://techblog.sega.jp/entry/2017/04/26/100000
- https://techblog.sega.jp/entry/2019/06/25/100000
- https://techlife.cookpad.com/entry/2015/05/22/182046
- https://techlife.cookpad.com/entry/2018/05/09/080000
- https://www.topse.jp/ja/curriculum.html
- https://www.juse.or.jp/sqip/workshop/index.html
当日のQ&A（補足込み）：Q2 Q：日本はアメリカと違って入社後に企業が教育する文化？が強いと思います。この本 相当の教育が大学でできていない、とするならば、企業の教育に取り入れるしかないと 思うのですが、それは現実的でしょうか。考えられる障害についてもコメント頂けると幸 いです。 A（池田）： 現状は企業教育に取り入れるしかありません。 新人研修および技術者教育のメニューに「ソフトウェアエンジニアリング」をとりいれるということです。 例えば、目次をそのまま講座化し、受講者のレベルに応じて座学なのか演習なのかといったデザインをするよ とよいと思います。また、講師は社内で育成すべきです。技術教育を通して講師レイヤー側も技術の習熟や最 新の技術を取り入れていくという「学び続ける」効果を得ることが大切だからです。 全部を取り入れることを想定しつつまずはここから、というようにステップをおいで講座化していくのが現実的と 思います。 以上を取り組もうとすると、「予算」「人」はもちろん障害となりえますが、それ以前のところで「ソフトウェアエンジ ニアリングへの理解」があります。講演中も申し上げましたが、ソフトウェアエンジニアリング体系＝学者の勉 強、という乱暴な理解をする層にどう考えを変えてもらうかです。ここについては、ご自身からの説得も必要です が、ソフトウェアエンジニアリングの社外識者に助言を求めるのも良いでしょう。
当日のQ&A（補足込み）：Q3 Q：ご紹介いただいた書籍を部内に導入して読みましょう、と言うだけでなく、 別途効果を出すためのアドバイスがあれば教えてください。 A（池田）： 効果を出すためには実践が必要です。個人での実践も効果を出すために必要ですが、開発体で捉えた場合、 専門部署や社内コンサルタント・エヴァンジェリストが必要になってきます。生産技術部門や社内技術の水平展 開を行うSEPGのような方々をソフトウェアエンジニアリングのスペシャリストで構成し、企業内の仕組み（プロセ ス、各種ひな形など）を更新する、教育組織側から積極的に教育を促すといったことが必要です。また、スペ シャリストに実際にプロジェクトに入って伴走してもらうことも効果的です。ここへの投資を躊躇すると、組織とし ての技術力の向上は望めません。 A（金子）： 読んだら実践しましょう。知識を取り入れて現場で実践することを組織的に行う習慣はついていますでしょう か？もしなければ実践は個人の強い意志に委ねられます。それがどういうものか架空の物語として簡単に読め る本として カイゼン・ジャーニー をおすすめします。実例を知りたければ SPI Japan や デブサミ などのカンファ レンスをおすすめします。そして、本書などで技術の全体像が把握できていると、様々な実例との抽象 -具体関 係を理解でき、改善する順序、効果、労力を考えた最適解をひらめくセンスが磨かれるでしょう。
当日のQ&A（補足込み）：コメント ソフトウェアエンジニアリング系の書籍は読むだけだと効果が薄いと前に感じたので、ま さに実践しないといけないと思いました。 コメント（水野）： 確かにその通りです！ スポーツの参考書と同じように、知識を得るだけではなく実践することで身に付けていくものとなります。 学んだ内容から自分の業務に使えるところに少しずつ試していくことで、技術として身に付いていきます。 是非とも実践して、成果を出していただければと思います！ 実践の場としては、 ETロボコンのような「本気で取り組める素振りの場」もありますので、新人・若手教育の場と して活用していただくのもよいかもしれません。 コメント(金子)： 実体験に基づいて効果と労力を理解し、本で表現された知識と対応づけることの繰り返しなんですよね。 ゴム肉でも筋を切っておくと美味しいってほんと？そうでもない …もう1回やろう…ほんとだ！みたいな。
当日のQ&A（補足込み）：コメント ソフトウェアエンジニアリング系の書籍は読むだけだと効果が薄いと前に感じたので、ま さに実践しないといけないと思いました。 コメント(池田)： はい、知識だけをたくさん得て頭でっかちになってしまうのは、それはそれで良くないです。 プロのスポーツ選手は、今では科学的なアプローチでスキルの向上に取り組んでいます。 最新のスポーツ理論やスポーツ医学等の知識を取り入れ、仮説を立てて試合で実践し、その結果を評価し、ま た知識の取り入れなどにつなげていくというサイクルを回しています。 ソフトウェアエンジニアも、「最新のサイエンス・エンジニアリング知識を入手 →仮説を立ててプロジェクトや業務 で実践し、その結果を評価し、次の業務に生かす」というベーシックな取り組みを継続していくことが、地道です が一番効果を生みます。知識の入手が先か、実践が先かという議論はあまり意味がなく。大切なことはそれを 行き来し続けることです。 得た知識は、使わないと知恵になりません。ぜひ実践してください。 日々の鍛錬と実践、プロとしての矜持を実行すればおのずと路は開けます！