慶應義塾大学 システムデザイン・マネジメント研究科(ＳＤＭ)の公開講座「現代ソフトウェアエンジニアリングの俯瞰図」の第一回に行ってきた！報告
内容は、こんなかんじ。
■慶應義塾大学 システムデザイン・マネジメント研究科（大学院）の紹介
２００８年新設
２０代〜６０代、過半数は社会人学生
システムズエンジニアリング講座 ＪＡＸＡ向け
デザイン指向（チームによるイノベーション）講座
■第一回「高品質のソフトウェアを効率的に開発するための
ソフトウエアエンジニアリング」 松田所長
・１９４６年 ＥＮＩＡＣ 最初の大型汎用デジタルコンピューター
１９６０年後半〜７０年代 商用コンピューターＩＢＭ ３６０シリーズ
→ソフトウェア危機：全人口がプログラマにならないと・・・
→６８年 国際会議で、はじめてソフトウェアエンジニアリングという言葉
１９７０年代 ＩＢＭ３７０
１９７１年 電電公社 ＤＩＰＳ−１
現在：ソフトウェアの問題は、解決したのか？
（１）ソフトウェア開発プロジェクトの現状
・自分で使うオフとウェアの開発
・他人に使ってもらうソフトウェアの開発
自分の趣味の延長にあるのではないかという誤解
→ぜんぜん違うもの
こちらの問題を扱う
・ソフトウェアの規模は、どうはかる？
・ソースプログラムの行数（ＳＬＯＣ）
Ｂ５に１枚３０行印刷すると１０万行は３４００ページ
広辞苑の机上版にの１冊分３４６０ページ
→Windows３．１ ３００万行
Windows２０００ ６０００万行
第３次オン 数百万行
自動車組み込み レクサスＬＳ４６０ ７００万行
ナビを入れると１７００万行
ＥＣＵが７０から１００個／台、１ＥＣＵ：１０万行。
ケータイ ５００万行
→スマホだとダウンロードできるので、もっと多い
・ソフトウェア開発プロジェクトのデータ収集・分析
「ソフトウェア開発データ白書」：現在、２３社 ２５８４プロジェクト
ソースの行数：１０万行以下が６割強、ただし、尾が長い
期間：１年以内が８割、中央値７ヶ月
工数：だいたい１５０人月までが８割強、真ん中３６人月
全体の規模と、開発している規模はちょっと違うけど・・・
（２）ソフトウェア開発プロジェクトの成功とは？
ＱＣＤというパラメータとＳ
Ｑ：品質
Ｃ：コスト
Ｄ：納期
Ｓ：スコープ（ソフトウェアの実現範囲）
・ソフトウェアは成功したか？
ＱＣＤのすべてが成功 ６０％
ＱＣＤの成功が２つ ２５％
→６０％位が成功 ：会場では、６０％以下の人が多数。
→優良プロジェクトで、データを取っているもののうち、６０％ということで、
悪いプロジェクトもあわせれば、もっと数字が悪くなるはず・・・
・日経コンピューター
成功３０％というのが、平均的らしい。
管理指標を導入している：成功４０数％
導入していない：２４％
８０項目のデータをＩＰＡはとっている：きちんと管理しているプロジェクト
→残念ながら、ＱＣＤがほぼ計画通り言ったものは、３０％というのが、世の中
・ソフトウェアエンジニアリング
技術面＋管理面
・ソフトウェアエンジニアリングの難しさ−１
自然現象、物理現象：一定の原理、法則に支配
ソフトウェア：人間の知的活動によって作られた人工物
普遍的な原理原則に基づくものではない
ソフトウェア工学
現実の開発事例をできるだけ多数集めて、良い結果が
生まれたモノを類型化して、広く使える方法として一般化
ソフトウェア・エンジニアリング・センター：２００４年設立
現場の事例の一般化
・ソフトウェアエンジニアリングの難しさ−２
ソフトウェアは見えない
→はだかの王様
ソフトウェアも・・・
みんな残業して、一生懸命
期限の前に、いや、遅れています・・・
Ｔｏｍデマルコ 「測定できないものは制御できない」
（ソフトウェア開発プロジェクト技法）
→定量的プロジェクト管理（８，１１，１２回で）
・ＱＣＤは計画通りだったか
それぞれについて
→計画の＋−１０％くらい：Ｃ８６％、Ｑ７８％、Ｄ８４％
→品質は犠牲？
ＣとＤは１４００答えている、Ｑは１０００
→品質は測ってない？
（３）ソフトウェア開発のＣ（コスト）とＤ（納期）
・開発規模：プログラム行数などの推定
↓・開発大勝があいまいな状況の見積もり
・仕様が決まらない、途中で変わる
工数：人月などの推定
↓・規模からの工数推定の確かさ？
・同規模でもしゅしゅの要因で変動
コスト・納期
・推定が、どの程度正確か？
＜＜規模について＞＞
割合乗っかってる。
計画した規模より大きくなるものも
少なかったケースは少ない
→規模は、大体推定できる
＜＜工数について＞＞
規模は見積もれたけど、工数は外れたというケース
・工数見積もり方法
経験ベース型 デルファイ法など
データ駆動型 Cocomo,ANOVA
混合型 CoBRA法（経験と勘とデータでＫＫＤ １０回）
・生産性
言語による生産性：開きがある
１人が１時間で５〜６行
１人月１６０人時
１人月６０万〜１２０万
→１時間当たり６０００円、１行１０００円
→１０万行で１億円
（４）ソフトウェア開発のＱ
・ソフトウェア品質
機能性、信頼性、使用姓、効率性・・・
→信頼性をとりあげる
３．１１直後のみずほトラブル
どれくらいの頻度で起きている？
報道ベースで、大体月に１件とか２件
ＳＥＣジャーナル「情報システムの障害状況 ２０１０年データ」
・組み込みソフトの不具合事例
エアバスＡ３２０の墜落
Therac-25：放射線を過剰に被爆
発熱→実はソフトの不具合
・電子カルテシステムに不具合
：日経コンピューター／動かないコンピュータ
→組み込みでなくても・・
・ソフト事故
・ソフト事故の影響範囲の拡大
・ソフト事故の損失の甚大か
・ソフト事故の質的な変化
・新規発生不具合
・キロ当たり０．０２件、０，０３件
・クスマノも０．０２件
→各国に比べ、１桁、２桁いい
それでも、事故が起こっている
・正しいソフトウェアを正しく作る
・仕様どおりソフトウェアを正しく作る
→かなり正確に
・用途に適合した正しいソフトウェアを作る
→相変わらず残っている・・
・Financial Electronic Data Interchange softwear
要件定義のバグが３０％
どういうものを、どういう条件で
機能要求 非機能要求
→セットで！
非機能要件の例：第６回
・開発の失敗（第５回）
２０１２年２月２日 日経コンピューター：特許庁
２０１２／３／３１ 日経産業長官
日本ＩＢＭ
・上流工程の品質向上策
要件定義
形式的仕様記述（第１４回）
形式手法の利用レベル
レベル０：形式的仕様記述
１：形式的開発及び検証
２：形式的証明
自動改札機運賃計算仕様書
→形式的仕様記述（ＶＤＭ＋＋）
外部設計書の検証
（５）変化へ対応できるソフトウェア開発
（６）むすびは省略
■質問＆コメント
・開発の仕方が変わっていくよね。
環境の違いの中で、ある部分では継続、ある部分は環境適応、その辺の取り組みは？
（４）までは、スコープ固定、
最近は、環境によっても、変動していくよね。
そのなかでの対応をちょっとしたかった。
どういう対応はなかなかむずかしい、
今まであるもの、かえていかないものは、どこにあるかをみながら、
しゅうせいしないといけないよね
問題意識は持っている。
最後のほうで話す。アジャイル（１７回）
・形式仕様のよさは、なかなか見えないよね。
それを改善するにはＳＥＣは何してる？
できるだけ、成功事例を積み上げ、普及すれば・・
これをやれば大丈夫と言うわけではない。
いろんな現場から拾い上げ、
・ソフトウェアエンジニアリングから
システムエンジニアリングへ
上流、超上流、超超上流と少しづつシフトへ・・
内容は、こんなかんじ。
■慶應義塾大学 システムデザイン・マネジメント研究科（大学院）の紹介
２００８年新設
２０代〜６０代、過半数は社会人学生
システムズエンジニアリング講座 ＪＡＸＡ向け
デザイン指向（チームによるイノベーション）講座
■第一回「高品質のソフトウェアを効率的に開発するための
ソフトウエアエンジニアリング」 松田所長
・１９４６年 ＥＮＩＡＣ 最初の大型汎用デジタルコンピューター
１９６０年後半〜７０年代 商用コンピューターＩＢＭ ３６０シリーズ
→ソフトウェア危機：全人口がプログラマにならないと・・・
→６８年 国際会議で、はじめてソフトウェアエンジニアリングという言葉
１９７０年代 ＩＢＭ３７０
１９７１年 電電公社 ＤＩＰＳ−１
現在：ソフトウェアの問題は、解決したのか？
（１）ソフトウェア開発プロジェクトの現状
・自分で使うオフとウェアの開発
・他人に使ってもらうソフトウェアの開発
自分の趣味の延長にあるのではないかという誤解
→ぜんぜん違うもの
こちらの問題を扱う
・ソフトウェアの規模は、どうはかる？
・ソースプログラムの行数（ＳＬＯＣ）
Ｂ５に１枚３０行印刷すると１０万行は３４００ページ
広辞苑の机上版にの１冊分３４６０ページ
→Windows３．１ ３００万行
Windows２０００ ６０００万行
第３次オン 数百万行
自動車組み込み レクサスＬＳ４６０ ７００万行
ナビを入れると１７００万行
ＥＣＵが７０から１００個／台、１ＥＣＵ：１０万行。
ケータイ ５００万行
→スマホだとダウンロードできるので、もっと多い
・ソフトウェア開発プロジェクトのデータ収集・分析
「ソフトウェア開発データ白書」：現在、２３社 ２５８４プロジェクト
ソースの行数：１０万行以下が６割強、ただし、尾が長い
期間：１年以内が８割、中央値７ヶ月
工数：だいたい１５０人月までが８割強、真ん中３６人月
全体の規模と、開発している規模はちょっと違うけど・・・
（２）ソフトウェア開発プロジェクトの成功とは？
ＱＣＤというパラメータとＳ
Ｑ：品質
Ｃ：コスト
Ｄ：納期
Ｓ：スコープ（ソフトウェアの実現範囲）
・ソフトウェアは成功したか？
ＱＣＤのすべてが成功 ６０％
ＱＣＤの成功が２つ ２５％
→６０％位が成功 ：会場では、６０％以下の人が多数。
→優良プロジェクトで、データを取っているもののうち、６０％ということで、
悪いプロジェクトもあわせれば、もっと数字が悪くなるはず・・・
・日経コンピューター
成功３０％というのが、平均的らしい。
管理指標を導入している：成功４０数％
導入していない：２４％
８０項目のデータをＩＰＡはとっている：きちんと管理しているプロジェクト
→残念ながら、ＱＣＤがほぼ計画通り言ったものは、３０％というのが、世の中
・ソフトウェアエンジニアリング
技術面＋管理面
・ソフトウェアエンジニアリングの難しさ−１
自然現象、物理現象：一定の原理、法則に支配
ソフトウェア：人間の知的活動によって作られた人工物
普遍的な原理原則に基づくものではない
ソフトウェア工学
現実の開発事例をできるだけ多数集めて、良い結果が
生まれたモノを類型化して、広く使える方法として一般化
ソフトウェア・エンジニアリング・センター：２００４年設立
現場の事例の一般化
・ソフトウェアエンジニアリングの難しさ−２
ソフトウェアは見えない
→はだかの王様
ソフトウェアも・・・
みんな残業して、一生懸命
期限の前に、いや、遅れています・・・
Ｔｏｍデマルコ 「測定できないものは制御できない」
（ソフトウェア開発プロジェクト技法）
→定量的プロジェクト管理（８，１１，１２回で）
・ＱＣＤは計画通りだったか
それぞれについて
→計画の＋−１０％くらい：Ｃ８６％、Ｑ７８％、Ｄ８４％
→品質は犠牲？
ＣとＤは１４００答えている、Ｑは１０００
→品質は測ってない？
（３）ソフトウェア開発のＣ（コスト）とＤ（納期）
・開発規模：プログラム行数などの推定
↓・開発大勝があいまいな状況の見積もり
・仕様が決まらない、途中で変わる
工数：人月などの推定
↓・規模からの工数推定の確かさ？
・同規模でもしゅしゅの要因で変動
コスト・納期
・推定が、どの程度正確か？
＜＜規模について＞＞
割合乗っかってる。
計画した規模より大きくなるものも
少なかったケースは少ない
→規模は、大体推定できる
＜＜工数について＞＞
規模は見積もれたけど、工数は外れたというケース
・工数見積もり方法
経験ベース型 デルファイ法など
データ駆動型 Cocomo,ANOVA
混合型 CoBRA法（経験と勘とデータでＫＫＤ １０回）
・生産性
言語による生産性：開きがある
１人が１時間で５〜６行
１人月１６０人時
１人月６０万〜１２０万
→１時間当たり６０００円、１行１０００円
→１０万行で１億円
（４）ソフトウェア開発のＱ
・ソフトウェア品質
機能性、信頼性、使用姓、効率性・・・
→信頼性をとりあげる
３．１１直後のみずほトラブル
どれくらいの頻度で起きている？
報道ベースで、大体月に１件とか２件
ＳＥＣジャーナル「情報システムの障害状況 ２０１０年データ」
・組み込みソフトの不具合事例
エアバスＡ３２０の墜落
Therac-25：放射線を過剰に被爆
発熱→実はソフトの不具合
・電子カルテシステムに不具合
：日経コンピューター／動かないコンピュータ
→組み込みでなくても・・
・ソフト事故
・ソフト事故の影響範囲の拡大
・ソフト事故の損失の甚大か
・ソフト事故の質的な変化
・新規発生不具合
・キロ当たり０．０２件、０，０３件
・クスマノも０．０２件
→各国に比べ、１桁、２桁いい
それでも、事故が起こっている
・正しいソフトウェアを正しく作る
・仕様どおりソフトウェアを正しく作る
→かなり正確に
・用途に適合した正しいソフトウェアを作る
→相変わらず残っている・・
・Financial Electronic Data Interchange softwear
要件定義のバグが３０％
どういうものを、どういう条件で
機能要求 非機能要求
→セットで！
非機能要件の例：第６回
・開発の失敗（第５回）
２０１２年２月２日 日経コンピューター：特許庁
２０１２／３／３１ 日経産業長官
日本ＩＢＭ
・上流工程の品質向上策
要件定義
形式的仕様記述（第１４回）
形式手法の利用レベル
レベル０：形式的仕様記述
１：形式的開発及び検証
２：形式的証明
自動改札機運賃計算仕様書
→形式的仕様記述（ＶＤＭ＋＋）
外部設計書の検証
（５）変化へ対応できるソフトウェア開発
（６）むすびは省略
■質問＆コメント
・開発の仕方が変わっていくよね。
環境の違いの中で、ある部分では継続、ある部分は環境適応、その辺の取り組みは？
（４）までは、スコープ固定、
最近は、環境によっても、変動していくよね。
そのなかでの対応をちょっとしたかった。
どういう対応はなかなかむずかしい、
今まであるもの、かえていかないものは、どこにあるかをみながら、
しゅうせいしないといけないよね
問題意識は持っている。
最後のほうで話す。アジャイル（１７回）
・形式仕様のよさは、なかなか見えないよね。
それを改善するにはＳＥＣは何してる？
できるだけ、成功事例を積み上げ、普及すれば・・
これをやれば大丈夫と言うわけではない。
いろんな現場から拾い上げ、
・ソフトウェアエンジニアリングから
システムエンジニアリングへ
上流、超上流、超超上流と少しづつシフトへ・・