米国修士課程ベストセラーに学ぶ
体系的ソフトウェアエンジニアリングの
必要性
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) 理事 

/ クオリティアーツ 代表 



情報通信系某社にて組込みシステムの設計、品質保証業務を経て、技術支援部門にてテスト技術を中心にアジャイル開発や
MBD/SPL等の導入を支援。その後所属を移し医用系、自動車系ドメインの自社製品開発プロジェクトに参画、テスト管理業務
やプロセス活動に従事。 

そのほか、全社を対象としたテストプロセス改善や研究による新技術導入、教育など品質確保や効率向上、技術高度化に取り
組んできた。

社外においてはNPO法人ASTER等に所属してソフトウェア開発技術の普及啓発活動に取り組んでいる。ASTER理事,NaITE代
表、SQiP運営委員,AFFORDD運営委員、CO-DEJIMA技術メンター等。 

現在はクオリティアーツ (屋号)として独立し、技術向上にまい進する企業に対してコンサルティング支援している。 

主な発表:

 ・JaSST'19 Hokkaido 基調講演 

 ・JaSST'18 Kyushu 招待講演 

著書:

 ・実践ソフトウェアエンジニアリング第9版(共訳) 

 ・SQuBOK Guide V3(共著) 

 ・[改訂新版]マインドマップから始めるソフトウェアテスト(共著) 

 ・ソフトウェアテストの基礎(共訳)、等。
講演者紹介 金子 昌永
● 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年遅れ?
期待と懸念の後、どうなったのか?
②組込みソフトウェア
によるリコール
2000 2010 2020
期待&
クライシスの
懸念
③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
8大学工学部を中心とした 工学における教育プログラムに関する検討, 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版が邦訳されており、
旧版も含めて日本でも知られている
● 実事例、各種書籍の情報を取り入れ
専門職にも役立つ情報がまとまっている
 第1章ソフトウェアとソフトウェアエンジニアリング
第1部 ソフトウェアプロセス
 第2章 プロセス
 第3章 アジャイルとプロセス
 第4章 推奨のプロセスモデル
 第5章 ソフトウェアエンジニアリングの人間的側面
第2部 モデリング
 第6章 プラクティスの指針となる原則
 第7章 要求エンジニアリング
 第8章 要求分析モデリングの推奨手法
 第9章 設計の概念
 第10章 アーキテクチャ設計の推奨手法
 第11章 コンポーネント設計
 第12章 UX設計
 第13章 移動体端末におけるソフトウェアの設計
 第14章 パターンに基づく設計
第3部 品質とセキュリティ
 第15章 品質の概念
 第16章 レビューの推奨手法
 第17章 ソフトウェア品質保証
 第18章 ソフトウェアセキュリティエンジニアリング
 第19章 ソフトウェアテスト-コンポーネントレベル
 第20章 ソフトウェアテスト-統合レベル
 第21章 ソフトウェアテスト-移動体端末と特定ドメインに対するテスト
 第22章 ソフトウェア構成マネジメント
 第23章 ソフトウェアメトリクスと分析
第4部 ソフトウェアプロジェクトのマネジメント
 第24章 プロジェクトマネジメントの概念
 第25章 実行可能で役立つソフトウェア計画
 第26章 リスクマネジメント
 第27章 ソフトウェアサポート戦略
第5部 先進的な話題
 第28章 ソフトウエアプロセス改善
 第29章 ソフトウェアエンジニアリングの新興トレンド
 第30章 おわりに
序文となる対話:ゲーム業界のソフトウェアエンジニアリング
本書はゲーム業界のエンジニア(青年)と原著者(博士)との対話からはじまる。
ゲーム開発においても、ソフトウェアエンジニアリングの知見をうまく取り入れて
改善し続けないと、ビジネスから撤退してしまうだろう、という内容。
<省略>
博士:( 彼が首を横に振るだろうと予想しつつつ)ソフトウェアエンジニアリングの手法は何か使っているのかね?
《彼は300 万行以上のコードで作られたアプリケーションの、ゲームプレイとAI 機能を担当していた。》
青年:( ゆっくりと頷き)ニーズに応じてですが、もちろん使っていますよ。
<省略>
青年:( 肩をすくめ)旧作のゲームのアーキテクチャを拡張し、適応させて、新しい製品を作ります。要件からコードを作成し、
デイリービルドでコードをテストし、他にも博士の本が勧めることをたくさんしなければならないですね。
博士:驚いた。私の本を知っているのかね?
青年: もちろん、学校で使い、いまも参考にしています。役立つことがたくさん本の中にありました。
博士:君の同僚の何人かと話をしたが、私の本に書いてあることに対して懐疑的だったよ。
青年:( 顔をしかめ)あのですね、僕たちは IT部門や航空宇宙会社にいるわけじゃないから、博士が提唱するものをカスタマイズしな
いと使えないんです。でも肝心なところは同じで、高品質の製品を作らなければいけない。そして、繰り返し可能な方法で達成するに
は、独自のソフトウェアエンジニアリング技術のサブセットを作り、適応させないとダメなんです。
今後、ゲームの規模がより大きく、より複雑になるのは確かです。そして、競争相手が増えれば開発期間も短くなります。
徐々に、ゲーム自体が僕たちに開発規律の適用を強いるようになるでしょう。そうしないと、僕たち終わっちゃいますからね。
知っておくと役立つ情報について、一部抜粋して紹介
部の構成自体はESxR(ESPR、ESDR、ESQR)と重なっているようにも見えるが…
過去からの優れた実践事例を取り入れて更新し続けてきた本書から、
組込みにおける学習体系を補完できると考えられる情報について一部抜粋して紹介
1. プロセス
2.プラクティスの本質となる問題解決への言及
3.原則とモデリング
4.最新の情報の取り込み
その1-1:プロセスの要素・概念の理解
前提:規定プロセスをそのまま扱うのではなく、自分で考えるための知識を得る
特定プロセスを単純に守るのではなく、
プロセスの構造を理解できるようにする
プロセスの構成要素、一般例を知り、
各プロセスを分析できるようにする
<何に役立つのか>
実際に行っているプロセスの意味を知り、
自分たちのプロセスを理解し見直す
そこから継続的な改善をできるようにする
その1-2:複数のプロセスの特徴を紹介
例えばウォーターフォール(第2章):その適用しやすい条件
ある問題に対する要求が十分理解されていて、コミュニケーションからデプロイまで順に作
業を実施できる場合がある。こうした状況は、明確に定義された既存システムの修正や拡張
(例えば、政府の規制変更により必ず実施しなければならない会計ソフトウェアの修正等)で
発生する場合がある。
その1-2:複数のプロセスの特徴を紹介
例えばウォーターフォール(第2章):適さない条件
特定の状況ではよいが、昨今よくある状況には適合しづらい、と明示されている。
→クライシス状況を考慮するとどうだったのだろうか。
1.現実のプロジェクトでは、モデルに示されているワークフローの順番どおり進行することは
ほとんどない
2.プロジェクト開始時に顧客が要求事項をすべて明確に述べることは難しい
3.実際に動作するプログラムはプロジェクトの後半になるまで入手できず、顧客は辛抱強く
待たなければならない
4.プログラムが動く段階になるまで大きな問題が発見されない場合がある
今日、ソフトウェア開発はスピードが求められ、(機能やフィーチャ、情報コンテンツに対する)
変更の奔流に晒されている。ウォーターフォールモデルはこうした状況には適していない。
その1-2:複数のプロセスの特徴を紹介
プロセスは盲目的なものではない。
万能なプロセスは存在しない→状況にあわせて選択が必要となる。
ソフトウェアエンジニアリングプロセスはソフトウェアチームが盲目的にしたがわなければな
らない厳格な規定ではなく、俊敏(agile)であり、問題、プロジェクト、チーム、組織文化に対
して適応するものである。(第1章)
現実としては、どのプロセスもあらゆるプロジェクトに適用できるような完璧なものではない。
(第2章)
どのアジャイル手法もあらゆるプロジェクトに対して万能ではない。(第3章)
その1-2:複数のプロセスの特徴を紹介
各プロセスの特徴を紹介。適用しやすい範囲やプロセス構成の意味を知る。
その1-3:昨今の状況に適した推奨プロセス
変化が当たり前、要求自体を探索する
必要がある(VUCAの)状況において、
変化する状況に適応できるプロセスを
ベースラインとして学習する(第4章)
<何に役立つのか>
業務にて適用しているプロセスで
不足箇所を一般的な課題と共に把握し、
効果的・効率的に開発するための
改善へのベースラインとして活用する
その2:プラクティスの本質は問題解決
書籍の序盤で、問題解決の本質の重要性に触れている。
(How to solve it(いかにして問題を解くか)を参照)
問題解決の手続:(ソフトウェア開発との対応、第1章)
1.問題を理解する
2.解決策を計画する
3.計画を実行に移す
4.結果が正しいことを確認する
<何に役立つのか>
手段やルールではなく、問題解決にソフトウェアエンジニアリングを
活用する根本的な原則を常に心にとどめる。
その3:原則とモデリング
単なるノウハウを記載したものでなく、
特定の技術を前提とした手順でもなく、
原則や課題を明示したうえで、
実践されているプラクティスや
各種モデリング手法を紹介している(第2部)
<何に役立つのか>
技術の発展により手段が変わっても、
原則を考慮し柔軟な検討や
適切な技術の選択ができるようになる
また、モデリング技術を身に付けて
確実な設計を進めるために役立つ
<原則の例(他にも多数記載あります)>
■計画の原則
 第1原則 プロジェクトのスコープを理解する
 第2原則 ステークホルダを計画アクティビティに巻き込む
 第3原則 計画は反復的であることを認識する
 第4原則 わかっていることから見積りをする
 第5原則 リスクを考慮する
 第6原則 現実的に考える
 第7原則 精度/粒度を調整する
 第8原則 どのように品質を保証するか決める
 第9原則 どのように変更に対応するか決める
 第10原則 頻繁に追跡し、必要に応じて調整する
■モデリングの原則
 第1原則 ソフトウェア開発者の一番の目的はソフトウェアを
  構築することで、モデルを作成することではない
 第2原則 不必要なモデルは作らず身軽に進める
 第3原則 ソフトウェアや、ソフトウェアの解決する問題を、
  簡潔に説明するモデルを作ることに努める
 第4原則 変更を取り入れやすい方法で作成する
 第5原則 モデルを作成した動機を明確に説明できるようにする
 第6原則 作成したモデルを目の前のシステムに合わせる
 第7原則 完全なモデルのことは忘れて、役に立つモデルを作る
 第8原則 モデルの記法を押し付けてはいけない。
  情報を伝えることができているなら表現は後回しでよい
 第9原則 たとえ紙面で見る限り正しくても、直感が間違いを
  訴えるモデルには、注意を向けるだけの理由がある
 第10原則 できるだけ早くフィードバックを得る
その4:比較的新しい情報の提供
原著自身、2004-5年段階(第6版)でWeb向け体系やアジャイル開発を紹介する等、
該当の時代によく使われている技術を紹介しつつ、比較的利用が少ない技術や、
当たり前となった技術と入れ替えている。
今回の新しい情報としては、次のようなものがある。
・カンバンやDevOpsといった比較的新しい概念の紹介(第3章)
・「要求を探索する」開発スタイルに適したプロトタイピング、
 進化型プロセスをベースとしたプロセスの紹介(第4章)
・User eXperience(UX)設計への取り込み(第12章)
・モバイル(移動体端末)を中心とした開発への言及(第13章、第21章)
・サーチベースのエンジニアリングなど新興トレンドの紹介(第29章)
原著第8版(英語)にあった次のような部分は本書(第9版)では消えている
・Webとモバイルを区別した構成
・形式手法を中心とした技法の紹介
該当体系のポイント紹介
 第1章ソフトウェアとソフトウェアエンジニアリング
第1部 ソフトウェアプロセス
 第2章 プロセス
 第3章 アジャイルとプロセス
 第4章 推奨のプロセスモデル
 第5章 ソフトウェアエンジニアリングの人間的側面
第2部 モデリング
 第6章 プラクティスの指針となる原則
 第7章 要求エンジニアリング
 第8章 要求分析モデリングの推奨手法
 第9章 設計の概念
 第10章 アーキテクチャ設計の推奨手法
 第11章 コンポーネント設計
 第12章 UX設計
 第13章 移動体端末におけるソフトウェアの設計
 第14章 パターンに基づく設計
第3部 品質とセキュリティ
 第15章 品質の概念
 第16章 レビューの推奨手法
 第17章 ソフトウェア品質保証
 第18章 ソフトウェアセキュリティエンジニアリング
 第19章 ソフトウェアテスト-コンポーネントレベル
 第20章 ソフトウェアテスト-統合レベル
 第21章 ソフトウェアテスト-移動体端末と特定ドメインに対するテスト
 第22章 ソフトウェア構成マネジメント
 第23章 ソフトウェアメトリクスと分析
第4部 ソフトウェアプロジェクトのマネジメント
 第24章 プロジェクトマネジメントの概念
 第25章 実行可能で役立つソフトウェア計画
 第26章 リスクマネジメント
 第27章 ソフトウェアサポート戦略
第5部 先進的な話題
 第28章 ソフトウエアプロセス改善
 第29章 ソフトウェアエンジニアリングの新興トレンド
 第30章 おわりに
より実践で役立った事例等から
技術が取り込まれ、時代に即したベースライン
となる情報としてまとまっている(右の赤字)
昔から変わらず重要な部分は残り続けている
 ※マネジメント、品質の概念、テストなど
該当体系のポイント:参考文献
・本書は多数の参考文献(書籍、論文)を引用している。
 より詳細の情報を知りたい方は、特定分野の
 説明から参考文献を辿るのもよい。
・参考文献数は約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!!
「実践ソフトウェアエンジニアリング」における体系の変化
第6版(日本語版
2005年)
 第1章ソフトウェアとトウェアエンジニアリング
第1部 ソフトウェアプロセス
 第2章 プロセス
 第3章 規範的なプロセスモデル
 第4章 アジャイル開発
第2部 ソフトウェアエンジニアリングの実践
 第5章 プラクティス -一般的な考え方
 第6章 システムエンジニアリング
 第7章 要求エンジニアリング
 第8章 要求分析モデリング
 第9章 設計エンジニアリング
 第10章 アーキテクチャ設計
 第11章 コンポーネントレベル設計
 第12章 ユーザインタフェース設計
 第13章 ソフトウェアテスト戦略
 第14章 ソフトウェアテスト技術
 第15章 成果物に関するソフトウェアメトリクス
第3部 Webエンジニアリングの適用
 第16章 
Webエンジニアリング
 第17章 
Webエンジニアリング他のための定式化と計画
 第18章 
Webアプリケーションのための分析モデリング
 第19章 
Webアプリケーションの設計モデリング
 第20章 
Webアプリケーションのテスト
第4部 ソフトウェアプロジェクトの管理
 第21章 プロジェクトマネジメントの概念
 第22章 プロセスとプロジェクトのメトリクス
 第23章 ソフトウェアプロジェクトの見積もり
 第24章 ソフトウェアプロジェクトスケジューリング
 第25章 リスクマネジメント
 第26章 品質マネジメント
 第27章 変更管理
第5部 ソフトウェアエンジニアリングの先進トピック
 第28章 フォーマルメソッド
 第29章 クリーンルーム開発
 第30章 コンポーネントベース・ソフトウェアエンジニアリング
 第31章 リエンジニアリング
 第32章 進むべき道
第4版(日本語版2000年)
第1部 製品とプロセス
 第1章 製品
 第2章 プロセス
第2部 ソフトウェアプロジェクトの管理
 第3章 プロジェクト管理の理念
 第4章 プロセスとメトリクス
 第5章 ソフトウェアプロジェクトの計画立案
 第6章 リスク管理
 第7章 プロジェクトのスケジューリングと追跡
 第8章 ソフトウェアの品質保証
 第9章 ソフトフェア構成管理
第3部 ソフトウェア工学の伝統的手法
 第10章 システム構想設計
 第11章 要求分析の基本概念と原則
 第12章 要求分析モデル
 第13章 設計の基本概念と原則
 第14章 設計の手法
 第15章 リアルタイムシステムの設計
 第16章 ソフトウェアテスト技術
 第17章 ソフトウェアテスト戦略
 第18章 技術的なソフトウェアメトリクス
第4部 オブジェクト指向ソフトウェア工学
 第19章 オブジェクト指向の基本概念と原則
 第20章 オブジェクト指向分析
 第21章 オブジェクト指向設計
 第22章 オブジェクト指向テスト
 第23章 オブジェクト指向システムの技術的メトリクス
第5部 ソフトウェア工学の進んだ話題
 第24章 フォーマルメソッド
 第25章 クリーンルーム開発
 第26章 ソフトウェア再利用
 第27章 リエンジニアリング
 第28章 クライアント・サーバソフトウェア工学
 第29章 CASE:コンピュータ支援ソフトウェア開発
 第30章 進むべき道
第9版(日本語版2021年)
 第1章ソフトウェアとソフトウェアエンジニアリング
第1部 ソフトウェアプロセス
 第2章 プロセス
 第3章 アジャイルとプロセス
 第4章 推奨のプロセスモデル
 第5章 ソフトウェアエンジニアリングの人間的側面
第2部 モデリング
 第6章 プラクティスの指針となる原則
 第7章 要求エンジニアリング
 第8章 要求分析モデリングの推奨手法
 第9章 設計の概念
 第10章 アーキテクチャ設計の推奨手法
 第11章 コンポーネント設計
 第12章 ユーザエクスペリエンス設計
 第13章 移動体端末におけるソフトウェアの設計
 第14章 パターンに基づく設計
第3部 品質とセキュリティ
 第15章 品質の概念
 第16章 レビューの推奨手法
 第17章 ソフトウェア品質保証
 第18章 ソフトウェアセキュリティエンジニアリング
 第19章 ソフトウェアテスト-コンポーネントレベル
 第20章 ソフトウェアテスト-統合レベル
 第21章 ソフトウェアテスト-移動体端末と特定ドメインに対するテスト
 第22章 ソフトウェア構成マネジメント
 第23章 ソフトウェアメトリクスと分析
第4部 ソフトウェアプロジェクトのマネジメント
 第24章 プロジェクトマネジメントの概念
 第25章 実行可能で役立つソフトウェア計画
 第26章 リスクマネジメント
 第27章 ソフトウェアサポート戦略
第5部 先進的な話題
 第28章 ソフトウエアプロセス改善
 第29章 ソフトウェアエンジニアリングの新興トレンド
 第30章 おわりに
オブジェクト指向
技術がホット
新たな話題として、
アジャイル開発、
アーキテクチャ設
計、ユーザインタ
フェース、Webエン
ジニアリング、プロ
ジェクトマネジメン
トなど
新たな話題とし
て、人間的側面、
モデリング、ユー
ザエクスペリエン
ス、移動体端末。
品質とセキュリ
ティが独立した章
となり、大きくス
ポットが当たって
いる。
過去に体系を学んだことで満足せずに、
常に学び続けることが大切である
クイズ:金づちとのこぎりでビルは建つでしょうか?
あなたが大工だとします。
問題:
 金づちとのこぎりだけで
 ビルは立てられるでしょうか?
答え:
 さすがにそれだけではできない。
様々な道具が必要。
つまり、道具箱のようなものが必要となってくる
それが体系、ということであり、
更新し続けること、学び続けることが大切
最新の中身に更新し続ける
参考事例:体系を使った、組織や個人の技術力成熟度判定
体系は、学びに利用できるが、
応用として技術力の成熟度判定モデルとして
利用することもできる。
・簡単に、すぐに取り組める
・技術者個人を対象とする
・目次をそのまま評価項目とする
・ETSSと併用するために、フレームを合わせる
・個人に入力してもらうことそのものが、
すでに学習効果である
体系を技術成熟度モデル化した例
章 節 レベル0
当該技術を知らない
レベル1:初級
技術を知っている
支援のもとに技術を利用できる
レベル2:中級
技術を他人に説明できる
自律的にその技術を利用できる
レベル3:上級
技術を他人に指導できる
技術を応用し、高度な利用ができる
レベル4:最上級
技術をもとに、さらに新たな技術を
開発できる
ソフト
ウェア
プロセ
ス
プロセス
アジャイルとプロセス
推奨のプロセスモデル
ソフトウェアエンジニアリングの人間的側面
モデリ
ング
プラクティスの指針となる原則
要求エンジニアリング
要求分析エンジニアリングの推奨手法
設計の概念
アーキテクチャ設計の推奨手法
・・・
章・節を項目とする。
(項もいれて3段階でもよい)
ETSSにあわせたレベル設定。
ただし、レベル0を追加し、各レベルの定義を再定義
各項目について塗りつぶしをしてもらう。
各項目の一番高いレベルの欄に、具体的に、
どのように技術を使っているか記入してもらう
のもよい。
体系をチームビルドに生かす(チームのレベル状況可視化)
■ベテラン
■中堅
■新人
②集約して平均化 ③施策検討
①個人で記入
今回のプロジェクトで必要とされるレベルを
満たしているかどうかを見える化し、
もし不十分であればメンバーの入れ替えや増員、
レベルアップのためのトレーニングを施策化する
チーム全体としてみると、ほとんど
の項目が上級レベルにない。
体系をチームビルドに生かす(チームメンバー選定)
■ベテラン
■中堅
■新人
②メンバーを選定
①チームとして必要なレベルを決定
他の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. 体系の外側~いつかきた道ではない新たな道~
○ 本書で新興トレンドを扱う章を参照し、新たな道の兆しをいくつか説明した
○ 道の整備と開拓に貢献してほしいと説いた
おわりに
継続的に開発をしていく場合、さらに品質のよい開発を目指す場合に、チームや組織に
ソフトウェアエンジニアリングの知識があると、効果的に活動できるはずです。
是非とも学んでいただき、ビジネス価値の高い開発を、楽しく続けていきましょう。
水野 昇幸
ソフトウェアエンジニアリングは実績ある開発道具箱です。
すでに実績ある足腰を強くするためのノウハウは、再発明せずに活用することが大切です。
ぜひ道具箱を手に入れて、品質高く、効率がよい、幸せな開発を手に入れましょう。
池田 暁
組込みならではの課題があるでしょう。製造業ならではの課題があるでしょう。
家電と自動車と工場設備では課題が異なるでしょう。それでもなお、うちの業界は、うち
の会社は特殊だと思わずに、使えるものは使う姿勢が幸を呼ぶでしょう。
金子 昌永

ET-IoT2021-SEPA9thJa