ソフトウェア定量化の過去・現在・未来...2016/11/25 · ISBSG（International Software Benchmarking Standards Group ）では、世界中のソフトウェア関連団体からデータを収集

Copyright © 2016 NTT DATA Corporation

（株）NTTデータシステム技術本部生産技術部藤貫美佐

ソフトウェア定量化の過去・現在・未来

JFPUGオープンセミナ2016 資料

2Copyright © 2015 NTT DATA Corporation

藤貫美佐（ふじぬきみさ）(株)NTTデータシステム技術本部生産技術部プロジェクトマネジメント・ソリューションセンタ

自己紹介

・標準開発手順、管理手順、見積り関連ソリューションの研究開発、普及展開に従事しています・日本ファンクションポイントユーザ会の会長です

SystemDevelopmentStandards

Environment

Support

標準開発手順・管理手順

フレームワークと開発支援ツール

研修や教育サービス

開発標準

サポート

開発環境

Copyright © 2016 NTT DATA Corporation 3

過去・現在・未来


ソフトウェア定量化の歴史

① 混乱期 ② 胎動期 ③ 活動期反抗期成熟期

1968 1978 1982 1987 1993～

５０年のはなし




1968 1978 1982 1987 1993～

ローレンス・H･パトナム、ウェア・マイヤーズ（著）、山浦恒央（訳）、初めて学ぶソフトウェアメトリクス～プロジェクト見積もりのためのデータの導き方～、日経BP社、2005

① 混乱期NATOの会議で「ソフトウェア工学」という言葉が使われる工程、品質、コストが制御できず危機感が募る

② 胎動期「計測できなければ制御できない」を「計測すれば制御できる」と変形し、計測の試行錯誤が始まる・McCabeのサイクロマティック数・Halsteadのソフトウェアサイエンス




1968 1978 1982 1987 1993～


③ 活動期・実プロジェクトでのメトリクス適用が活発に行われる・慎重派が登場し、メトリクスの意味を見直し始める

④ 反抗期・計測に予想以上に時間とお金がかかるが、その割に効果が出ないことがわかってくる・ソフトウェアサイエンスへのバッシングが始まる・ソースコード行数と発生バグ件数の計測へと回帰する




1968 1978 1982 1987 1993～


⑤ 成熟期・「混乱期」に戻ったが、一部ではメトリクスが定着し効果を挙げ始める。・ソースコード行数と発生バグ件数を軸に、各開発組織が独自のメトリクスを開拓し、目的、意味、意義を自覚し始める。

・ソースコード以外を対象とした評価も現実的に・多数の開発プロジェクトのベンチマークデータの利用が可能に


ファンクションポイントとベンチマーク1980 1990 2000 2010

汎用機・COBOL CSS・Webオープン

アプライアンス・クラウドPKG、自動化

IFPUG

１９７９手法の公表（A.オールブレクト）

１９９４JFPUG

・生産性のパラドックスを解決すべくファンクションポイント法が誕生、機能規模測定方法として国際標準化・FPの普及展開と呼応しベンチマーク手法も発展

１９８６

１９９８

国際標準化

ISBSG1995

経済調査会、IPA/SEC、JUAS、

１９９７

２００８国際標準化


ＪＦＰＵＧ会員数の推移

0

50

100

150

200

250

300

350

MF→オープン化

FP法に対する期待と誤解

1

0


FPに対する誤解（１）

FP法は精度の高い見積り手法でしょ？

→ いいえ、違います。

1

1


ファンクションポイントとは？

システムの機能要件を定量化する手法です

・入力機能・出力機能・データ蓄積機能・外部連携機能

等々

・性能・信頼性・保守性・セキュリティ・操作性

等々

システム要件

機能要件非機能要件

ここを定量化します

1

2



システムの機能要件を定量化する手法です

機能要件

プログラム

設計製造試験

ここを定量化します

1

3


FPに対する誤解（２）

設計が終わらないと使えないんだよね？


1

4



上流から見積りに活用することができます

FP数

外部設計

プログラム行数

内部設計製造試験

見積り計測

見積り計測

機能量を見積る

機能量と実装方法の双方を勘案して見積る

1

5


FPに対する誤解（３）

FPとソースコード行数、どちらを選べばいい？

→選ぶものではありません

1

6



システム要件

機能要件非機能要件

ＦＰ法

ＦＰ数

実装プログラム

プログラム行数測定規則

プログラム行数

要求仕様の重さ

プログラムの重さ

測定対象外

定量化の対象が異なります

1

7


ファンクションポイント法とは？

ユーザ論理データ

論理データ

論理データ

入出力

入出力

対象システム他システム

主に下記の3種類の機能を計測します。・ユーザとシステム間の入出力機能・システム内でデータを保持する機能・対象システムと他システム間の入出力機能

定量化の対象が異なります

1

8


FPに対する誤解（４）

FPは人が測るから恣意的になるのでは？


1

9



定量化のためのルールが決められています

• 1998年「ソフトウェア機能規模の概念定義（ISO/IEC14143-

1）」を発行し、以後次々と各規格を発行

•デファクトスタンダード（DS）としてIFPUG法、Nezma法等を認定

•国内でも並行してJIS（翻訳JIS）の発行が行われている

IFPUG

BFPUG

GFPI-ISMA

KFPUG

JFPUG

LASMA

OCCI

SASMA

AEMES-SFPUG

IFPUG（international Function Point User Group）の支部

2

0



定量化のためのルールが決められています

・ルールの明確化・日本国内における計測ガイドを発行“IFPUG法 Japanese Guideline”

・資格試験の実施・日本語のCFPS試験を実施現在国内で22名

JFPUGの取り組み

計測方法のガイドを提供

2

1



① ②

② 定量化のためのルールが決められています

① システムの機能要件を定量化する手法です

ユーザとベンダ間の共通尺度として使用することができます

2

2


ベンチマーク～ ISBSGとは？

ISBSG（International Software Benchmarking Standards Group ）では、世界中のソフトウェア関連団体からデータを収集分析し、その結果を有償で公表しています。

JFPUGはISBSGの支部であるため、JFPUG会員は会員価格でISBSG製品を購入できます。

Data Release 13 - Development & Enhancement Data6,000以上のソフトウェアプロジェクトの開発、及び機能拡充における実績データを集めたリポジトリです。 Excel spreadsheet で提供され、5ユーザまで使用可能です。世界最大のベンチマークデータですので、自社データとの比較や見積

りにおける参考情報として活用できます。

代表的なISBSG製品

2

3


国内の三大ベンチマーク

・一般財団法人経済調査会ソフトウェア開発データリポジトリの分析

・独立行政法人情報処理推進機構（IPA）技術本部ソフトウェア高信頼化センター（SEC）ソフトウェア開発データ白書

・一般社団法人日本情報システム・ユーザ協会（JUAS）ソフトウェアメトリックス調査

国内のソフトウェア開発におけるデータを収集・分析し、業界の相場観として有効。数値情報だけでなく、データの収集方法、分析方法も参考になる。→しかし、個々の計測ルールは。。。

2

4



組織ごとの個別最適へ

FPの計測方法は国際標準

ベンチマークは有効だが、課題もあり


5


2

6


何の数字でしょうか？

４８．４％

３７．５％

2

7


工期遅延・予算超過のプロジェクト

４８．４％

３７．５％

500人月以上の大規模プロジェクトにおける

予算超過したプロジェクトの比率

工期を遅延したプロジェクトの比率

２０１４年度 n=184

一般社団法人 JUAS（日本情報システムユーザ会）発行「企業IT動向調査報告書2015」より

２０１４年度 n=184

2

8


問題プロジェクトの状況

一般社団法人 JUAS（日本情報システムユーザ会）発行「企業IT動向調査報告書2015」より

2004年度～2014年度のトレンド

納期を遅延したプロジェクトの比率予算を超過したプロジェクトの比率

規模 2004年度

2009年度

2014年度

2004年度

2009年度

2014年度

100人月未満

１７．２％（n=746)

２０．６％（n=805)

１５．０％(n=827）

１１．９％（n=742)

１３．４％（n=800)

９．８％(n=817）

100～500人月未満

４３．２％（n=447)

３０．１％（n=339)

２９．６％(n=３３８）

３３．６％（n=443)

２９．２％（n=339)

２２．４％(n=３３9）

500人月以上

５１．４％（n=278)

４３．８％（n=178)

４８．４％(n=184）

４６．７％（n=276)

４３．３％（n=178)

３７．５％(n=184）

100人月未満：一時悪化したものの改善傾向100～500人月未満：改善傾向500人月以上：工期は悪化、予算は改善傾向がみられるが依然高い比率

システムの複雑化、要求の高度化などから難易度の高い大規模プロジェクトが増加

2

9



工期、コストの悪化理由TOP5

工期の遅延理由工数、コストの増大理由

１要件仕様の決定遅れ２０．６％開発規模の増大１９．９％

２要件分析作業不十分１５．９％要件定義不十分１８．９％

３開発規模の増大１４．２％要件仕様の決定遅れ１４．７％

４構築チーム能力不足８．５％品質不良によるテスト工数の増大１０．７％

５テスト計画不十分７．８％構築チーム能力不足７．３％

・工期、コストともに、要求仕様の決定遅れ、要件定義不十分、開発規模の増大が約半数 →双子の兄弟・体制の弱さ、品質悪化も一定数あり

一般社団法人 JUAS（日本情報システムユーザ会）発行「ユーザ企業ソフトウェアメトリックス調査2016」より

3

0


１０／２６

１９／４５

何の数字でしょうか？

3

1



１０／２６

１９／４５

「動かないコンピュータ」に掲載された公共プロジェクトの比率

「情報システム事故報道記事」に掲載された公共プロジェクトの比率

2015年度日経BP社発行「日経コンピュータ」連載「動かないコンピュータ」より

2015年度独立行政法人情報処理推進機構発行「SEC journal」より

一般社団法人経済調査会発行「公共調達と会計監査」より

3

2




公共IT調達のこれからの課題～業務の進め方の違い～公共建設工事情報システム開発

１事業分類の標準化・事業分類、工事種類を分類・事業分類ごとに基準類を標準化

・事業の類型化がされていない

２工程の定義・設計と施工の工程を完全分離

・作業工程標準化のための「共通フレーム」を国際標準に準拠し策定・大枠の規定であり、テーラリングが前提

３設計図書の標準化・設計標準は構造体ごとに設計（構造）計算ができるよう規定

・各種手法はあるが、採用する手法によって図の描き方が異なる

４設計・施工の関係・設計と施工の分離発注・設計と施工の一体発注

５施工管理・発注者が監理業務を実施・発注者の関与が希薄なケースが散見

６施工業者のランク付け

・建設業者の経営や技術力に応じランク付けを実施

・技術力に応じたランク付けはない

3

3




公共IT調達のこれからの課題～見積りの標準化の違い～公共建設工事情報システム開発

１積算・見積り手法の標準化

・発注者が設計図と数量積算基準を基に施工量を算出・施工量の単位が明確

・広く使用されているSLOCは計測方法の標準がなく、作り方によって変動・FPは定量的客観的に計測できる唯一の手法であるが浸透度が低い・要求が固まらないまま発注・計測者が少ない・計測に手間がかかる

２工数・労務量は人日で規定・8時間を基本として数量を算出

・人月を使用することが多いが作業日数、時間が標準化されていない

３生産性・施工量に対する労務量（人日）

・施工量の規模尺度が明確でないため労務量（人月）が取引のベース

４費用見積り・工種別に費目を分けて積算し、施工量で除算し単価を設定

・WBSによる積み上げた労務量（人月）

3

4



公共IT調達のこれからの課題

・業務の進め方業務分類、設計標準、設計図が規定されていない→設計と施工の一体発注→発注者の関与が希薄

・見積りの標準化施工量（規模）、労務量（工数）の基準が明確でない→取引のベースが人月→施工量（規模）の増減に応じた契約金額の変更が困難

政府情報システムの整備及び管理に関するガイドライン＊

・IT発注力の向上・調達手続きの改革・プロジェクト管理、資産管理の強化→規模見積りは原則FP法を適用

＊内閣官房情報通信技術(IT)総合戦略室。総務省行政管理局により発表H27年4月より施行

3

5


問題プロジェクトは業界全体の課題

“要件”と“見積り”が2大要因


開発プロセスと見積りの標準化が課題


6


3

7


このままではいけない

プロジェクトの成功のために１．ＱＣＤ＋Ｓの測る化２. STEPからの脱却

業界の発展のために３．ベンチマークの有効活用４．受発注の適正化

3

8


要員

スコープ

Ｓ

Ｄ

Ｑ

Ｃ

設計書システム

コスト

スケジュール

WBS

Ｑ

１．QCD＋Sの測る化

スコープ

納期

品質

コスト

一品生産の多いシステム開発プロジェクトの場合、QCDでは足りない。基点となるスコープの定量的管理が重要

3

9


①全体量

②変動状況

SCOPE

TIME

上流のスコープを定量化し、状況を可視化


4

0


ユーザ論理データ

論理データ

論理データ

入出力

入出力

対象システム他システム

スコープが増大するポイント

①

②

①要件の詳細化に伴い、データ、機能のヴァリエーションが増加②他システムインターフェースの検討は後手に回りがち

画面帳票数、STEP数では定量化できない分野FPを使う事で初めて把握できる。


4

1


プログラム

設計、試験の工数は、“機能要件”の規模に比例製造の工数は、“プログラム”の規模に比例

２．STEPからの脱却

設計製造試験

機能要件

4

2


プログラム

作らない開発では、“機能要件の規模”と“プログラムの規模”にギャップが発生


設計製造試験

機能要件

4

3


プログラム

機能要件

1,000FP

①STEP数に換算

50kstep②STEP数から全体の工数を見積り

設計製造試験

過小見積り

過小見積り

ソースコード行数だけに依存した見積りは、設計、試験の工数が過小になる


4

4


３．ベンチマークの有効活用

・計測方法の標準化

・プロセスの標準化

・活用方法の普及推進

4

5


黒字案件赤字案件

規模（KS）

生産性危険領域

３．ベンチマークの有効活用

実現可能性の低い生産性の共有

4

6


プログラム

４．受発注の適正化

設計製造試験

機能要件

どれだけ作ったか、どれだけ手もがかかったかからどんな機能を提供したかで取引できる世界に！

→FPベースの単価での取引

4

7


プログラム

４．受発注の適正化

設計製造試験

機能要件

事業目標達成状況

事業目標に対しITが価値を創造できているかを指標とする→ GQM+Strategies®

48Copyright © 2016 NTT DATA Corporation 複製厳禁・無断転載禁止

ご清聴ありがとうございました

Documents

ソフトウェア定量化の過去・現在・未来...2016/11/25 · ISBSG（International Software Benchmarking Standards Group ）では、世界中のソフトウェア関連団体からデータを収集