米国修士課程ベストセラーに学ぶ体系的ソフトウェアエンジニアリングの必要性

米国修士課程ベストセラーに学ぶ体系的ソフトウェアエンジニアリングの必要性 DX, AI, MaaS, …に惑わされない実践的エンジニアリングアプローチ ET&IoT2021 水野昇幸
池田暁金子昌永味の素エンジニアリング(株), SEPA翻訳プロジェクト (特非)ソフトウェアテスト技術振興協会(ASTER), SEPA翻訳プロジェクト SEPA翻訳プロジェクト

組込みソフトウェアに携わる人々に対しソフトウェアエンジニアリングを体系的に学ぶ必要性を伝える教育体系改善アセスメント　カリキュラム ESxR ETSS ETEC　体系の外側趣
旨構成キーワード I. 日本の組込みソフトウェア教育ではソフトウェアエンジニアリング体系が参照されていない疑惑 II. 実務/学術、モダン/温故知新のバランスに優れた体系～実践ソフトウェアエンジニアリング第9版の紹介～ III. 体系は更新される財産 IV. 体系の外側～いつかきた道ではない新たな道～

講演アブストラクト（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/組込み開発）  その後フリーランスを中心として、要件定義支援、プロジェクトマネジメント支援、  システム設計、プロセス改善テストプロセス・テスト計画支援を通じた改善等を実施  論文（国際学会のみ）：  ・（共著）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/ Twitter：@Noriyuki Mizuno

講演者紹介　池田暁 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]

講演者紹介　金子昌永 • Twitter • GitHub • SlideShare ◦ masskaneko
• LinkedIn [共訳] 実践ソフトウェアエンジニアリング第9版, オーム社, 2021 [論文] 医療機器ソフトウェア開発を対象とした包括的アセスメントのケーススタディ, 情報処理学会 SES2020 [論文] 不具合と開発現場の実態に基づくテスト分析手法, SQiPシンポジウム2015 [発表] 日立・ソフトウェア革新部会～会社を越境する社内コミュニティ～, XP祭り2019 [発表] モダンなチーム開発環境を追求しよう, SQiPシンポジウム2016 ソフトウェアエンジニアリング研究者 / 日立製作所医療機器向けマネジメント技術開発、社内コミュニティ組込みソフトウェア開発者 / クラリオン車載エンターテイメント機器開発、全社技術向上、教育フリーに転身して自給率を高めるライフスタイルを模索, 業界全体に貢献する道を進む 10年 4年 1年現フォルシアクラリオン・エレクトロニクス

I. 日本の組込みソフトウェア教育ではソフトウェアエンジニアリング体系が参照されていない疑惑

日本の組込みソフトウェア教育 • ESxR • ETSS • ETEC • 一般の技術書 •
組込み系ソフトウェア開発の課題分析と提言 (JEITA) • 組込みソフトウェア産業の動向把握等に関する調査 (IPA/SEC, 経済産業省) • 製造業製品における組込みソフトウェアの重要性向上 • 組込みソフトウェアクライシス • IT業界の成長見込みと開発力の課題始まりと実状教育内容調査・課題分析 • 社内教育 • 一般有志の勉強会 • 高等教育機関の情報/電気専攻扱わない

教育に至る少し前：組込みソフトウェアと製造業への期待(2002, 2003) ソフトウェアが核となる市場は、情報家電・デジタル家電・ユビキタスネットワーク・ ICタグ・IPv6等のこれからの期待分野に留まらない。医療・環境・自動車・航空・宇宙・あらゆる移動体等の分野・・・にも、想像をはるかに超えた、多様なニーズに応えるソフトウェアがますます必要とされている。とりわけ、その主戦場はハードウェアと一体になった組み込みソフトウェアの分野である。この分野で確固としたソフトウェア設計・生産、そしてマネジメントの仕組みを確保しなければならないと言えよう。
前田，重岡：”製造業のためのソフトウェア戦略マネジメント入門”，生産性出版，2003 松下，坂東：”ネット家電とその技術”，裳華房，2002 家電はもともと日本が強い分野でネット家電でも日本がリードできる可能性が高い。ゲーム機、電子カメラ、DVD等は日本製品が世界を制覇している。・・・日本にとって将来性が非常に楽しみのある分野である。

期待と共に訪れた危機（クライシス）西：”製品品質の決定要因としての組込みソフトウェアと組込みソフトウェア・クライシス”，日本品質管理学会誌「品質」 Vol.34，2004, https://qualab.jp/materials/jsqc-article2004.pdf 組込みソフトウェアは、高度化し複雑化した製品の中核となっており、製品全体の品質が組込みソフトウェアに依存するようになってしまった。しかし残念ながら組込みソフトウェアの品質、特に信頼性は十分確保されているとは言えない。いわば「組込みソフトウェア・クライシス」である。 Pressman:
“Software Engineering: A Practitioner’s Approach 1st edition”, 1982 より翻訳 1970年代において、我々は「ソフトウェア危機(software crisis)」と称される状況を認識するに至った。ソフトウェアに関するコストは爆発的に増大し、コンピューターを使用したシステムにおいて最も高価な要素となった。開発計画の通りに進み、完了することはほとんどなかった。ソフトウェアが大きくなるにつれ、品質が怪しくなってきた。そして、ソフトウェア危機に呼応する一連の技術、すなわち「ソフトウェアエンジニアリング」が誕生した。組込みソフトウェア・クライシスは30年遅れ？

期待と懸念の後、どうなったのか？ ②組込みソフトウェアによるリコール２０００２０１０２０２０期待＆クライシスの懸念 ③ITへの投資と成長
①スマートフォン移行 ITへの投資は十分だったのか？

①フィーチャーフォンからスマートフォンへの移行（2007～） 2007年にiPhoneが登場後、Android対応スマートフォンの各社初登場時期とシェアの変化参考：https://ja.wikipedia.org/wiki/Android%E7%AB%AF%E6%9C%AB%E4%B8%80%E8%A6%A7 商業的成否分析は以下に示されているが、開発技術が市場投入時期に影響とも読める [参考] 平成24年版情報通信白書第1部第2章第2節
ガラケーはスマホに「負けた」のか？ https://www.soumu.go.jp/johotsusintokei/whitepaper/ja/h24/html/nc122c00.html 国内シェアの遷移 2007年 ↓ 2020年

①スマートフォンの起動時間(2012) ITmedia - 最新スマートフォン徹底比較（2011年度冬春モデル編） https://www.itmedia.co.jp/mobile/articles/1203/29/news081_2.html Huawei GS02 HTC EVO 3D
AQUOS 103SH GALAXY SC-04D iPhone 4S MEDIAS CH 101N REGZA T-01D 0 40 20 ARROWS F-05D 秒最も早かったのがイー・モバイルの「 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人材数の推移 2015年（994070人）を起点とした伸び率 2018年 +3.7%(実績)、2021年 +10.7%(予測) 経済産業省：”平成 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/ 2019-2020 IT技術者数伸び率中国 8.59% インド 5.71% 日本 4.81% アメリカ 3.22% 2020 IT人材数と人口比 1位アメリカ 477万人 (1.47%) 2位中国 227万人 (0.16%) 3位インド 212万人 (0.16%) 4位日本 109万人 (0.86%) 2021

③ITへの投資と成長：情報通信業の労働生産性各国の情報通信業の労働生産性上昇率 (上記資料表3-3をもとに作成) 経済産業省: “平成 30 年度我が国におけるデータ駆動型社会に係る基盤整備 ”,
https://www.meti.go.jp/policy/it_policy/jinzai/houkokusyo.pdf 2010年を基準とした各国の労働生産性推移 1995- 労働生産性上昇率 2010- 労働生産性上昇率アメリカ 5.4% 2.2% ドイツ 4.2% 4.2% フランス 3.1% 2.3% 日本 2.4% 0.7%

③ITへの投資と成長：世界と日本のIT市場規模 2016-2021成長率：世界 24.2%，日本 8.5% 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回以上公表するデータに基づき作成

ここまで • 組込みソフトウェアによる製品価値向上の期待 • 組込みソフトウェア・クライシスの警鐘 → 発生 • 日本の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位 2005 設計品質の向上開発効率の向上
開発能力の向上開発期間の短縮 2006 設計品質の向上開発期間の短縮開発能力の向上開発効率の向上 2007 設計品質の向上新製品の開発開発期間の短縮開発能力の向上 2008 設計品質の向上新製品の開発開発期間の短縮開発能力の向上 2016 設計品質の向上開発能力の向上開発コストの削減新製品の開発 2017 設計品質の向上開発能力の向上新製品の開発開発コストの削減 2018 設計品質の向上開発能力の向上市場の拡大・開拓新製品の開発 2005-2008年度組込みソフトウェア産業実態調査報告書（経営者・事業責任者向け） “組込みソフトウェア開発に課せられている課題 ” 2016-2018年度組込みソフトウェア産業の動向把握等に関する調査 “組込みソフトウェア開発の課題” をもとに作成 ※回答選択肢は概ね一致するが増減と文言変更あり。 2004年度版、2019-2020年度版には該当設問がないため除外。 ESCR ETSS ETEC ESPR

年 1位 2位 3位 2011 技術者のスキル向上開発手法・開発技術の向上プロジェクトマネージャのスキル向上 2012 技術者のスキル向上
プロジェクトマネージャのスキル向上開発手法・開発技術の向上 2016 技術者のスキル向上開発手法・開発技術の向上プロジェクトマネージャの確保 2017 技術者のスキル向上プロジェクトマネージャのスキル向上開発手法・開発技術の向上 2018 技術者のスキル向上プロジェクトマネージャのスキル向上開発手法・開発技術の向上 “設計品質の向上” の解決策は？スキル，スキル，技術，技術 2011-2012年度ソフトウェア産業実態調査報告書 “設計品質向上の課題の解決策”, “組込みソフトウェア開発の課題1番目の解決策” 2016-2018年度組込みソフトウェア産業の動向把握等に関する調査 “課題「設計品質の向上」の解決策 ” をもとに作成

JEITA による組込みソフトウェア開発の課題分析の変遷組込み系ソフトウェア開発の課題分析と提言 (2008-2016)，IoT時代の組込み系ソフトウェア開発 (2017)，IoT開発の現状と課題 (2018) https://www.jeita.or.jp/japanese/public/software/index.html 組込みソフトウェア開発力に対する問題提起(2005) ・開発力は国際的に見て強いのか？　・すり合わせは強みなのか？　・何を強くすればよいか？大きな波(2006)
・大規模化・複雑化・短納期化・多機種化提言(2007) ・ハード部門等との連携・自動化・上流工程重視・多機種開発開発スピード阻害要因に着目 (2008-2010) ・要求分析・アーキテクチャ設計・プロジェクトマネジメントアーキテクチャ設計に着目・アーキテクト(2011-2013) ・モデリング(2014-2016) IoTに着目(2017-2018) ・IoT の定義・IoT 事例・IoT ならではのエンジニアリング、課題アンケート& ワークショップ

JEITA による組込みソフトウェア開発の課題分析の変遷組込み系ソフトウェア開発の課題分析と提言 (2008-2016)，IoT時代の組込み系ソフトウェア開発 (2017)，IoT開発の現状と課題 (2018) https://www.jeita.or.jp/japanese/public/software/index.html 組込みソフトウェア開発力に対する問題提起(2005) ・開発力は国際的に見て強いのか？　・すり合わせは強みなのか？　・何を強くすればよいか？大きな波(2006)
・大規模化・複雑化・短納期化・多機種化提言(2007) ・ハード部門等との連携・自動化・上流工程重視・多機種開発開発スピード阻害要因に着目 (2008-2010) ・要求分析・アーキテクチャ設計・プロジェクトマネジメントアーキテクチャ設計に着目・アーキテクト(2011-2013) ・モデリング(2014-2016) IoTに着目(2017-2018) ・IoT の定義・IoT 事例・IoT ならではのエンジニアリング、課題アンケート& ワークショップ課題抽出プロセスに飛躍あり見ようとしている課題の存在を確認している？ソフトウェアエンジニアリングの参考文献の記載に乏しい結果的にモデリングを起点に幅広いプロセスの課題と解決技術にたどり着いているように見える 2017 の報告書ではソフトウェアエンジニアリングの参考文献が比較的豊富膨大で示唆に富む分析(特にモデリング)

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 https://www.ipa.go.jp/sec/softwareengineering/std/emb.html • 組込みソフトウェア開発の標準リファレンス • IPA発行 • 200x ◦
ESCR, ESPR • 201x ◦ ESDR, ESTR, ESBR, ESQR, ESMR • Wモデル(左)で範囲が示されている • ETのIPAブースで入手した方は多いのでは ESPR Ver2 2007 が最終イテレーティブプロセスなし V字モデルに基づく重いプロセスモデル要求エンジニアリング未着手 ESBR バグ管理は V字モデル内でなくマネジメント ESQR 参考文献豊富 ESMRに影響 ESTRに影響 ESDRに影響

ETSS(スキル項目毎4レベル), ETEC(試験：800点満点 ABCグレード) 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では出題範囲を限定

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 組込みソフトウェア開発のためのオブジェクト指向モデリング 2006 5 これだけは知っておきたい組込みシステムの設計手法 2009 6 組込み現場の「C++」プログラミング 2009 7 テスト駆動開発による組み込みプログラミング 2013 8 現場がわかる組込みソフトウェア開発 2014 9 モダンC言語プログラミング 2014 10 組込みエンジニアの教科書 2019 コンピュ | タ開発プロセスチ | ム組織支援プロセス

手薄：要求と支援プロセス 1 製造業のためのソフトウェア戦略マネジメント入門 2003 2 よくわかる組込みシステム開発入門 2005 3 組込みソフトウェア開発スタートアップ
2005 4 組込みソフトウェア開発のためのオブジェクト指向モデリング 2006 5 これだけは知っておきたい組込みシステムの設計手法 2009 6 組込み現場の「C++」プログラミング 2009 7 テスト駆動開発による組み込みプログラミング 2013 8 現場がわかる組込みソフトウェア開発 2014 9 モダンC言語プログラミング 2014 10 組込みエンジニアの教科書 2019 コンピュ | タ開発プロセスチ | ム組織支援プロセス 2 3 8 10 3 4 5 5 5 5 6 7 8 8 9 9 1 5 3

業界取組みの注力領域は？カリキュラム標準で俯瞰する情報専門学科カリキュラム標準「 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 ETSS/ETEC ESxR JEITA調査組込み技術書

情報専門学科カリキュラム標準「J07」：4.ソフトウェアエンジニアリング領域(J07-SE), 2008 https://ipsj.ixsq.nii.ac.jp/ej/?action=repository_uri&item_id=60973 しかし我が国では，CSすら学んだことのない技術者と，大学等でCSしか学ばずSEは学んでいない技術者によって多くのソフトウェアが作り続けられているという問題を抱えている．経済産業省、2008年版組込みソフトウェア産業実態調査経
営者および事業責任者向け 2006年度採用実績より理工系大学院 21.3% 理工系大学 16.9% 高等専門学校 1.9% 専修/専門学校 2.1% 高等学校14.9% 文系/短大等 11.5% 経験者 30.4% ※古いデータだが近年で　同様の調査がない

「いつかきた道」と「新たな課題」識別のための体系参照 JEITA：”組込み系ソフトウェア開発の課題分析と提言”，2008 エンタープライズ系ソフトウェア開発において過去に経験してきて獲得してきた種々の取組みやノウハウを役立てることができると思われるが、組込み系ソフトウェア開発の現場が直面している問題は・・・ハードウェア開発と密に連携して・・・など「いつかきた道」だけでは済まされない新たなソフトウェア開発上の課題である SE:
ソフトウェアエンジニアリング知識体系 SE∧EmbSE: いつかきた道の一部 EmbSE∧¬SE: 新たな課題 EmbSE∧¬SE を識別するためには SE を識別する必要がある EmbSE: 組込みのSE

体系を参照できていたか疑問が残る • JEITA調査 ◦ 参考文献に乏しい (2017のみ豊富) ◦ 何を参照して課題を識別したか不明瞭のまま深堀り (結果、示唆は素晴らしい) •
ESxR ◦ V字モデル＋管理を網羅しようとしているが抜けがある ◦ 参考文献に乏しい (ESQR は豊富) ◦ 更新されていない(特にESPRは2007で止まっている) • ETSS/ETEC ◦ コンピュータエンジニアリング(74%) ＞ソフトウェアエンジニアリング(26%) ◦ 古いESPR(2007)によって最新参考書(2021)の足が引っ張られている ◦ 手薄領域について別の文献を参照させる記述もなし • 組込み技術書 ◦ コンピュータ構成、設計モデリング、コーディングに集中 ◦ 要求、支援プロセス（プロセスモデル、マネジメント…）は手薄

ソフトウェアエンジニアリング(工学)体系の書籍例 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 ソフトウェアエンジニアリング基礎知識体系 SWEBOK IEEE 2014...2003 ソフトウェア品質体系ガイド SQuBOK SQuBOK策定部会 2020…2007 実践的ソフトウェア工学石田, 浅井 2019, 2009 CODE COMPLETE マコネル 2005 ソフトウェア工学有沢 1988

文部科学省、”工学系科学分野の研究動向（要旨） ”，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～とされる) • それはどのようなものなのか？特に既存の組込み教育で手薄な領域に着目して紹介する Cambridge Dictionary: “engineering” the work of an engineer, or the study of this work 働き学問

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版」　榊原彰

PMBOK 主だった体系の改版状況 1996年 V1 2000年 V2 2004年 V3 2008年 V4
2013年 V5 2017年 V6 2021年 V7 SWEBOK 2001年 V1 2004年 V2004 2014年 V3 202?年 V4 SQuBOK 2007年 V1 2014年 V2 2020年 V3 1990年 2020年 2010年 2000年体系はソフトウェア開発を取り巻く情勢や技術の変化に対応して、常に更新され続ける。また、陳腐化したノウハウや技術はトピックから落とされ、新たに価値があると認められたものが最新の体系に反映される。自身が学んだ最新の体系が過去版である場合、それは世の中の標準から遅れをとっているということかもしれない。 New!! New!!

「実践ソフトウェアエンジニアリング」における体系の変化第６版（日本語版 2005年）　第１章ソフトウェアとトウェアエンジニアリング第１部　ソフトウェアプロセス　第２章　プロセス　第３章　規範的なプロセスモデル　第４章　アジャイル開発第２部　ソフトウェアエンジニアリングの実践　第５章　プラクティス　－一般的な考え方
　第６章　システムエンジニアリング　第７章　要求エンジニアリング　第８章　要求分析モデリング　第９章　設計エンジニアリング　第１０章　アーキテクチャ設計　第１１章　コンポーネントレベル設計　第１２章　ユーザインタフェース設計　第１３章　ソフトウェアテスト戦略　第１４章　ソフトウェアテスト技術　第１５章　成果物に関するソフトウェアメトリクス第３部　Webエンジニアリングの適用　第１６章　 Webエンジニアリング　第１７章　 Webエンジニアリング他のための定式化と計画　第１８章　 Webアプリケーションのための分析モデリング　第１９章　 Webアプリケーションの設計モデリング　第２０章　 Webアプリケーションのテスト第４部　ソフトウェアプロジェクトの管理　第２１章　プロジェクトマネジメントの概念　第２２章　プロセスとプロジェクトのメトリクス　第２３章　ソフトウェアプロジェクトの見積もり　第２４章　ソフトウェアプロジェクトスケジューリング　第２５章　リスクマネジメント　第２６章　品質マネジメント　第２７章　変更管理第５部　ソフトウェアエンジニアリングの先進トピック　第２８章　フォーマルメソッド　第２９章　クリーンルーム開発　第３０章　コンポーネントベース・ソフトウェアエンジニアリング　第３１章　リエンジニアリング　第３２章　進むべき道第４版（日本語版2000年）第１部　製品とプロセス　第１章　製品　第２章　プロセス第２部　ソフトウェアプロジェクトの管理　第３章　プロジェクト管理の理念　第４章　プロセスとメトリクス　第５章　ソフトウェアプロジェクトの計画立案　第６章　リスク管理　第７章　プロジェクトのスケジューリングと追跡　第８章　ソフトウェアの品質保証　第９章　ソフトフェア構成管理第３部　ソフトウェア工学の伝統的手法　第１０章　システム構想設計　第１１章　要求分析の基本概念と原則　第１２章　要求分析モデル　第１３章　設計の基本概念と原則　第１４章　設計の手法　第１５章　リアルタイムシステムの設計　第１６章　ソフトウェアテスト技術　第１７章　ソフトウェアテスト戦略　第１８章　技術的なソフトウェアメトリクス第４部　オブジェクト指向ソフトウェア工学　第１９章　オブジェクト指向の基本概念と原則　第２０章　オブジェクト指向分析　第２１章　オブジェクト指向設計　第２２章　オブジェクト指向テスト　第２３章　オブジェクト指向システムの技術的メトリクス第５部　ソフトウェア工学の進んだ話題　第２４章　フォーマルメソッド　第２５章　クリーンルーム開発　第２６章　ソフトウェア再利用　第２７章　リエンジニアリング　第２８章　クライアント・サーバソフトウェア工学　第２９章　CASE：コンピュータ支援ソフトウェア開発　第３０章　進むべき道第９版（日本語版2021年）　第１章ソフトウェアとソフトウェアエンジニアリング第１部　ソフトウェアプロセス　第２章　プロセス　第３章　アジャイルとプロセス　第４章　推奨のプロセスモデル　第５章　ソフトウェアエンジニアリングの人間的側面第２部　モデリング　第６章　プラクティスの指針となる原則　第７章　要求エンジニアリング　第８章　要求分析モデリングの推奨手法　第９章　設計の概念　第１０章　アーキテクチャ設計の推奨手法　第１１章　コンポーネント設計　第１２章　ユーザエクスペリエンス設計　第１３章　移動体端末におけるソフトウェアの設計　第１４章　パターンに基づく設計第３部　品質とセキュリティ　第１５章　品質の概念　第１６章　レビューの推奨手法　第１７章　ソフトウェア品質保証　第１８章　ソフトウェアセキュリティエンジニアリング　第１９章　ソフトウェアテスト－コンポーネントレベル　第２０章　ソフトウェアテスト－統合レベル　第２１章　ソフトウェアテスト－移動体端末と特定ドメインに対するテスト　第２２章　ソフトウェア構成マネジメント　第２３章　ソフトウェアメトリクスと分析第４部　ソフトウェアプロジェクトのマネジメント　第２４章　プロジェクトマネジメントの概念　第２５章　実行可能で役立つソフトウェア計画　第２６章　リスクマネジメント　第２７章　ソフトウェアサポート戦略第５部　先進的な話題　第２８章　ソフトウエアプロセス改善　第２９章　ソフトウェアエンジニアリングの新興トレンド　第３０章　おわりにオブジェクト指向技術がホット新たな話題として、アジャイル開発、アーキテクチャ設計、ユーザインタフェース、Webエンジニアリング、プロジェクトマネジメントなど新たな話題として、人間的側面、モデリング、ユーザエクスペリエンス、移動体端末。品質とセキュリティが独立した章となり、大きくスポットが当たっている。過去に体系を学んだことで満足せずに、常に学び続けることが大切である

クイズ：金づちとのこぎりでビルは建つでしょうか？あなたが大工だとします。問題：　金づちとのこぎりだけで　ビルは立てられるでしょうか？答え：　さすがにそれだけではできない。様々な道具が必要。つまり、道具箱のようなものが必要となってくるそれが体系、ということであり、
更新し続けること、学び続けることが大切最新の中身に更新し続ける

参考事例：体系を使った、組織や個人の技術力成熟度判定体系は、学びに利用できるが、応用として技術力の成熟度判定モデルとして利用することもできる。・簡単に、すぐに取り組める・技術者個人を対象とする・目次をそのまま評価項目とする・ETSSと併用するために、フレームを合わせる・個人に入力してもらうことそのものが、すでに学習効果である

体系を技術成熟度モデル化した例章節レベル０当該技術を知らないレベル１：初級技術を知っている支援のもとに技術を利用できるレベル２：中級技術を他人に説明できる
自律的にその技術を利用できるレベル３：上級技術を他人に指導できる技術を応用し、高度な利用ができるレベル４：最上級技術をもとに、さらに新たな技術を開発できるソフトウェアプロセスプロセスアジャイルとプロセス推奨のプロセスモデルソフトウェアエンジニアリングの人間的側面モデリングプラクティスの指針となる原則要求エンジニアリング要求分析エンジニアリングの推奨手法設計の概念アーキテクチャ設計の推奨手法・・・章・節を項目とする。（項もいれて3段階でもよい） ETSSにあわせたレベル設定。ただし、レベル０を追加し、各レベルの定義を再定義各項目について塗りつぶしをしてもらう。各項目の一番高いレベルの欄に、具体的に、どのように技術を使っているか記入してもらうのもよい。

体系をチームビルドに生かす（チームのレベル状況可視化） ▪ベテラン ▪中堅 ▪新人 ②集約して平均化 ③施策検討 ①個人で記入今回のプロジェクトで必要とされるレベルを満たしているかどうかを見える化し、もし不十分であればメンバーの入れ替えや増員、
レベルアップのためのトレーニングを施策化するチーム全体としてみると、ほとんどの項目が上級レベルにない。

体系をチームビルドに生かす（チームメンバー選定） ▪ベテラン ▪中堅 ▪新人 ②メンバーを選定 ①チームとして必要なレベルを決定他のＥＴＳＳ等のモデルと併用し、ソフトウェアエンジニアリング面からもメンバ選定する

IV. 体系の外側～いつかきた道ではない新たな道～

どのような変化が訪れたとしても、これまでの私たちの努力が幼稚に見えるほどのソフトウェアやシステムが必要になるだろう。2040年には、超絶的な計算機、人工知能と機械学習、ナノテクノロジー、広帯域のユビキタスネットワーク、ロボティクスが組み合わさり、今とは全く異なる世界が実現するだろう。そのとき、ソフトウェアは現在と同じく時代の核として存在し続けるが、その形態は私たちがまだ理解していないものであろう。だとしても、ソフトウェアエンジニアリングはあり続けるだろう。劇的な進化はやってくる。私たちも進化を実現する主体である。何が、なぜ、どのように進化するのか、させたいのか。その理解と合意形成は難しく、知識不足ゆえに進路を惑わされることがある。
体系的知識があれば、バズワードや誇大広告としての DX や AI に惑わされることはない。ソフトウェアエンジニアリングは、長期的に見た劇的な進化の中で漸進してゆくだろう。本書29章：ソフトウェアエンジニアリングの新興トレンド

本書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部門の協力も必要 • 開発者の個人プレー • 社内に閉じている • スタンドアロン

協働型開発：関連 - 技術者採用・定着のための環境投資仕事選びで何を重視する？TOP5 (上位3つ選択) 51.3% 携わる技術 (プログラミング言語、フレームワークなど) 44.5%
オフィス環境、企業文化 43.9% 働く時間の自由さ 41.4% 開発実務に携われること 33.3% リモートワーク選択の自由新しい仕事を探しているか？ 57.6% 探してないが良い機会があれば検討 25.1% 新しい仕事に興味なし 17.3% 積極的に探している使用コラボレーションツール 82.8% GitHub 53.0% Slack 47.7% Jira 41.5% G Suite 37.0% GitLab 32.4% Confluence 好きなプログラミング言語 86.1% Rust 67.1% TypeScript 66.7% Python 62.9% Kotlin 62.3% Go ・・・ 44.1% Java 43.4% C++ 33.1% C StackOverflow Developer Survey 2020 (N≒65000 🌏アメリカとインドで 1/3、ほか多数) 環境が悪化すると技術者が退職する例　　・6年勤めたNTTを退職しました　　・12年勤めたNTTを退職しました

複雑さの克服複雑なシステムの全てが巨大というわけではない。10万行未満の比較的小さなアプリケーションでさえ複雑すぎるのだ。 29 章何万もの要求、制約、制限の分析において、矛盾をなくし、曖昧さを排除し、漏れをなくし、エラーを正すことができるのだろうか。将来は、超絶的な複雑さを克服するためにAIが広く使われるだろう・・・研究畑生まれのリポジトリマイニングは実務で使われつつある。システムに存在する技術的負債と、その維持コストを自動的に特定できれ
ば、対象となるコンポーネントのリファクタリングに費やす時間を確保するよう、開発者と経営陣を説得しやすくなるだろう。 11 章設計新興トレンド

複雑さの克服：リポジトリマイニングによるテスト最適化の例プロダクトコードの変更履歴、自動テスト実行履歴から、 ①次のテストの成否を予測、②類似テストケースの発見（振る舞いと入力の類似） ③プロダクトコードとテストケースの関係を予測ビルド依存グラフと静的解析によるプロダクトコード：テストコード関係特定に加え XGBoost を用いたテストケース推薦技術を開発、自動テストのFlakiness対応 M. Machalica, A.
Samylkin, M. Porth, S. Chandra: “Predictive Test Selection”, ICSE 2019 Tony Chang: “Data Intelligence Enables Intelligent R&D”, ICST 2019 Industry Track Keynotes Huawei Facebook • 失敗しそうなテストケースのみ実行することは複雑さの克服につながる省力化 ◦ 複雑なプロダクト/テストであっても → テスト実行時間短縮，リファクタリングの安全性向上 • 前提：広範な自動テスト実行/管理の整備、学習データとしての開発履歴 • 組込みにおける海外の自動テスト事例は OSSJ/ALS で発表される例あり ◦ 産業用Linuxボードテスト事例，　ビデオ自動テスト事例

ソフトウェアプロセス改善 (SPI：Software Process Improvement) CMMIは・・・大変意義のある成果である・・・あるべきアクションについて話し合う土台となる。 28 章 SPIを成功させるためには、社会学と人類学の専門性を活かすことが技術的規律を守ること以上に重要である。・・・変化をもたらす効果的な方法について、集団を扱う
社会学から学べることが多いだろう。 29 章揺れ動くビジネスにおける高速なソフトウェア開発では、長期的なSPIの戦略は続かない・・・製品の短期目標を重視したフレームワークに置き換える必要がある・・どれだけ考え抜かれたプロセスであっても、有能でやる気のある人材がいなければ成功しない。People CMMでは人的組織のコンピテンシーと文化を・・・

ソフトウェアプロセス改善：単体テストすら非自動からの道長尾(訳), J.Whittakerほか(著)：”テストから見えてくるグーグルのソフトウェア開発”, 2013, まえがきより私たちは・・・JUnitなどのツールを使ってテストを自動化することを・・・推奨したしかし、それらの動きは遅く・・・デベロッパーたちは、十分なテストをするには、テスト対象のコードの1行に対して2、3行の単体テストコードを書かなければならず・・・同じくらいのメンテナンスが必要・・・ということを認識していたのだ M.
Striebeck: “Creating a testing culture”, European Lean IT Summit, 2011 https://www.slideshare.net/operaepartners/creating-a-t esting-culture-by-mark-striebeck 2007 2011 トイレにテストのtipsを貼る取組みをブログ掲載 “Testing on the Toilet” 2019 トイレでツールを紹介すると利用者が激増したという論文発表 “Do Developers Learn New Tools On The Toilet?”, ICSE 2019 https://research.google/pubs/pub47861/ 継続的な活動に脱帽。これも “集団を扱う社会学” かもしれない。

ほか、(案外)本書に載っていないことソフトウェアプロセスモデリング品質とセキュリティソフトウェアプロジェクトのマネジメントデプロイの手法・サイトリライアビリティエンジニアリング・オブザーバビリティ
並行/並列処理の設計/テスト手法プログラミング言語選定監視の手法マネジメント3.0 形式手法過去版にあり過去版にあり・A/Bテスト・カナリアリリース・ローリングアップデート処理の実現方法はあふれるほどあるが「複雑さの克服」方法、複雑さの表現方法に乏しい ? InnerSource

体系の外を開拓する兆しは多く見える。ただし・・・業界の権威はこうした新技術の重要性を吹聴し、専門家はその技術を積極的に採用する。最終的にその技術は・・・何らかの役割を果たすようになるが謳い文句通りの効果は得られず、探求は続く傾向にある。本書29章より先へ進む道には、誇大広告にもかかわらず実際にはうまくいかなかったエキサイティングな新テクノロジーが死屍累々と転がっている本書30章よりでは、自ら体系の外を開拓するか？誰かの開拓を待つか？

黎明期模倣期経験期理論化期自動化期成熟期普及
率本書29章より：技術のイノベーションサイクル (BRETAM sequence) 本書29章より：ガートナー提唱のハイプ・サイクル期待度黎明期過度な期待幻滅啓発安定 [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 TDD 2002 実証的研究 2010 i, 2013 ii Backlog (in Scrum) 2001 実証的研究 2019 iii User Story (in XP) 1998 提唱から実証的研究まで時間を要す例普及, 事例蓄積

黎明期模倣期経験期理論化期自動化期成熟期普及
率レイトマジョリティ，ラガードイノベーター，アーリーアダプター定番ツール学術実証，反証書籍，経験発表やってみたこれどうよ・より確実な導入・費用少・永遠の三流・学びと創造の楽しみの放棄・トップの可能性↑ ・ブランディング・継続的投資必要 (単発回収不可) • 体系化が進んだ技術であるほど非競争領域 • 最先端技術は学術機関よりも先端的企業の現場から生まれる可能性 • 技術者の採用と定着への影響を考慮する（先述：環境を重視する） • 調査に留めるか、味見くらいするか、本腰を入れるか、あえて待つか・・・

the work of an engineer, or the study of this
work 体系は地図と羅針盤。目的地は自身で定める必要がある。整備された道ほど走りやすい。道中、小石を取り除く者もいれば、舗装する者も、新たな道を開拓する者もいる。道の整備と開拓に貢献する者ほど、道の意味を深く理解し、価値ある進路を見出すだろう。事例発表論文社用/個人ブログ OSS貢献コミュニティ

総　括 • I. 日本の組込みソフトウェア教育ではソフトウェアエンジニアリング体系が参照されていない疑惑 ◦ 業界としての組込みソフトウェア教育に至る 2000年代からの歴史的経緯を説明し、課題分析と教材内容におけるソフトウェアエンジニアリング体系非参照の疑惑を指摘した
• II. 実務/学術、モダン/温故知新のバランスに優れた体系 ◦ 実践ソフトウェアエンジニアリング第 9版(本書)が体系の学習に適した書籍だと説明した • III. 体系は更新される財産 ◦ ドラッカーと本書の推薦文を参照し、体系は更新される財産だと説明した ◦ 本書を用いた成熟度判定方法を説明した • 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年コースで数十名が受けているそうです。考えられる障害は（残念ながら経験したものも含む）、教育者は昔のエースであり今の技術に疎い、真にふさわしい教育者は開発に没頭している、被教育者も目先の開発が優先される、覚えたことを実践する組織的な仕組みがない…。そうした障害との勝負で明暗が分かれた企業のどちらも現実にいるのだと思います。

当日のQ&A（補足込み）：Q2 Q：日本はアメリカと違って入社後に企業が教育する文化？が強いと思います。この本相当の教育が大学でできていない、とするならば、企業の教育に取り入れるしかないと思うのですが、それは現実的でしょうか。考えられる障害についてもコメント頂けると幸いです。 A（池田）：現状は企業教育に取り入れるしかありません。新人研修および技術者教育のメニューに「ソフトウェアエンジニアリング」をとりいれるということです。例えば、目次をそのまま講座化し、受講者のレベルに応じて座学なのか演習なのかといったデザインをするよとよいと思います。また、講師は社内で育成すべきです。技術教育を通して講師レイヤー側も技術の習熟や最
新の技術を取り入れていくという「学び続ける」効果を得ることが大切だからです。全部を取り入れることを想定しつつまずはここから、というようにステップをおいで講座化していくのが現実的と思います。以上を取り組もうとすると、「予算」「人」はもちろん障害となりえますが、それ以前のところで「ソフトウェアエンジニアリングへの理解」があります。講演中も申し上げましたが、ソフトウェアエンジニアリング体系＝学者の勉強、という乱暴な理解をする層にどう考えを変えてもらうかです。ここについては、ご自身からの説得も必要ですが、ソフトウェアエンジニアリングの社外識者に助言を求めるのも良いでしょう。

当日のQ&A（補足込み）：Q3 Q：ご紹介いただいた書籍を部内に導入して読みましょう、と言うだけでなく、別途効果を出すためのアドバイスがあれば教えてください。 A（池田）：効果を出すためには実践が必要です。個人での実践も効果を出すために必要ですが、開発体で捉えた場合、専門部署や社内コンサルタント・エヴァンジェリストが必要になってきます。生産技術部門や社内技術の水平展開を行うSEPGのような方々をソフトウェアエンジニアリングのスペシャリストで構成し、企業内の仕組み（プロセス、各種ひな形など）を更新する、教育組織側から積極的に教育を促すといったことが必要です。また、スペシャリストに実際にプロジェクトに入って伴走してもらうことも効果的です。ここへの投資を躊躇すると、組織としての技術力の向上は望めません。
A（金子）：読んだら実践しましょう。知識を取り入れて現場で実践することを組織的に行う習慣はついていますでしょうか？もしなければ実践は個人の強い意志に委ねられます。それがどういうものか架空の物語として簡単に読める本としてカイゼン・ジャーニーをおすすめします。実例を知りたければ SPI Japan やデブサミなどのカンファレンスをおすすめします。そして、本書などで技術の全体像が把握できていると、様々な実例との抽象 -具体関係を理解でき、改善する順序、効果、労力を考えた最適解をひらめくセンスが磨かれるでしょう。

当日のQ&A（補足込み）：コメントソフトウェアエンジニアリング系の書籍は読むだけだと効果が薄いと前に感じたので、まさに実践しないといけないと思いました。コメント（水野）：確かにその通りです！スポーツの参考書と同じように、知識を得るだけではなく実践することで身に付けていくものとなります。学んだ内容から自分の業務に使えるところに少しずつ試していくことで、技術として身に付いていきます。是非とも実践して、成果を出していただければと思います！実践の場としては、ETロボコンのような「本気で取り組める素振りの場」もありますので、新人・若手教育の場として活用していただくのもよいかもしれません。
コメント(金子)：実体験に基づいて効果と労力を理解し、本で表現された知識と対応づけることの繰り返しなんですよね。ゴム肉でも筋を切っておくと美味しいってほんと？そうでもない …もう1回やろう…ほんとだ！みたいな。

当日のQ&A（補足込み）：コメントソフトウェアエンジニアリング系の書籍は読むだけだと効果が薄いと前に感じたので、まさに実践しないといけないと思いました。コメント(池田)：はい、知識だけをたくさん得て頭でっかちになってしまうのは、それはそれで良くないです。プロのスポーツ選手は、今では科学的なアプローチでスキルの向上に取り組んでいます。最新のスポーツ理論やスポーツ医学等の知識を取り入れ、仮説を立てて試合で実践し、その結果を評価し、また知識の取り入れなどにつなげていくというサイクルを回しています。ソフトウェアエンジニアも、「最新のサイエンス・エンジニアリング知識を入手 →仮説を立ててプロジェクトや業務
で実践し、その結果を評価し、次の業務に生かす」というベーシックな取り組みを継続していくことが、地道ですが一番効果を生みます。知識の入手が先か、実践が先かという議論はあまり意味がなく。大切なことはそれを行き来し続けることです。得た知識は、使わないと知恵になりません。ぜひ実践してください。日々の鍛錬と実践、プロとしての矜持を実行すればおのずと路は開けます！

米国修士課程ベストセラーに学ぶ体系的ソフトウェアエンジニアリングの必要性

米国修士課程ベストセラーに学ぶ体系的ソフトウェアエンジニアリングの必要性

More Decks by Akira Ikeda

Other Decks in Technology

Featured

Transcript