いっそう重要性を増すシステム開発の上流工程 - ipa...2017/09/07 ·...

Software Reliability Enhancement CenterCopyright © 2009-2017 IPA

いっそう重要性を増すシステム開発の上流工程

～企画・要件定義のポイントと見える化～

「デジタルイノベーションで創る“スマートな北海道”」セミナー

於北海道経済産業局会議室

2017年9月7日

独立行政法人情報処理推進機構（ＩＰＡ）

技術本部ソフトウェア高信頼化センター（ＳＥＣ）

山下博之

2Copyright © 2009-2017 IPA Software Reliability Enhancement Center

本講演の趣旨

IoT時代の社会は，現実世界とサイバー空間とが相互に連関するCyber Physical System (CPS)としてモデル化され，現実世界の活動に伴う様々なデータを収集・蓄積し，それらの大量データ(ビッグデータ)をサイバー空間上で解析して現実世界にフィードバックし，種々の社会的課題の解決に役立てる“データ主導社会”と言われている．このような社会は，各種データ利活用による住民サービス充実，新たなビジネス・雇用の創出等，地域の課題解決を図るためにも期待され，多様な分野で地域IoTを推進する施策も進められている．

IoTの進展と共にICTの役割は，“Support Business”から“Do Business”へと変わってきており，今やビジネスの要となっている．このような状況で競争優位を維持し続けるためには，ICTシステムのオーナーは，ビジネス環境の変化に機敏に対応すると共に，ビジネス要求を的確に反映することが必須である．しかしながら，システム構築の上流工程に起因するトラブル（開発プロジェクトの失敗，サービス開始後のシステム障害の発生）が相変わらず多い．ICTシステムを活用して攻めと守りのビジネスを確実に進めるためには，システム開発の上流工程の強化が必要である．

IPA/SECでは，これまで，高品質のソフトウェアを効率的に開発するための手法の取りまとめと普及の活動を行ってきた．本講演では，まず，内外の調査情報等に基づいてIoT時代を概観した上で経営層への期待を述べる．次に，IPA/SECにおける取組み内容に基づいて，私見も交えつつ，システム開発上流工程（企画～要件定義）強化と見える化を中心に，主に経営層向けの視点で説明する．

SECセミナー講演＠北海道 (2017-09-07)


プロローグ IoT時代



IoT時代：Cyber Physical System(CPS)

<出典>「情報経済小委員会中間とりまとめ報告書」，産業構造審議会商務流通情報分科会，平成27年5月21日をもとに加筆．

つながる機器の分野・台数は急増し，従来デジタル化されることなく散在していたデータが

大量にインターネットに流通

より広範囲にビ

ジネス機会の増大

セキュリティ等，

リスク要因も増大

より深く



IoT時代：データ主導社会

<出典> 情報通信審議会第三次中間答申概要，情報通信審議会，平成29年1月27日．http://www.soumu.go.jp/menu_news/s-news/01tsushin01_02000216.html



(参考) 地域IoT実装の推進(1)

<出典> 「地域IoT実装推進ロードマップ（改定）」及び「ロードマップの実現に向けた第二次提言」等の公表，総務省，平成29年5月25日．http://www.soumu.go.jp/menu_news/s-news/01ryutsu06_02000142.html



(参考) 地域IoT実装の推進(2)

<出典> 「地域IoT実装推進ロードマップ（改定）」及び「ロードマップの実現に向けた第二次提言」等の公表，総務省，平成29年5月25日．http://www.soumu.go.jp/menu_news/s-news/01ryutsu06_02000142.html



IoTの導入

(1)

つなげる

(2)

集める

(3)

活用するレベル３：

付加価値創出

レベル２：

改善

レベル１：

見える化

＜活用のレベル＞

＜IoTの構成＞

<出典> 中小企業のためのIoT導入ガイド, ITCA,2017年5月31日．「2. IoTの定義」からキーワードを抽出．



ＩｏＴ時代のビジネス領域

<出典>国内IoT市場グローバル主要事業者分析結果を発表2015年6月10日 IDC Japan株式会社プレスリリースhttp://www.idcjapan.co.jp/Press/Current/20150610Apr.html をもとに作成

システム／デバイス

コネクティビティ

プラットフォーム

アナリティクス

アプリケーション

5つのレイヤ

導入産業分野の拡大

ビジネスの方向

導入目的／導入用途の拡大

導入機器／導入地域の拡大

自社のビジネスはどこか？どの領域を狙うか？

自身の活躍する場はどこか？IoTの導入予測例


http://www.idcjapan.co.jp/Press/Current/20150610Apr.html


ビジネスに関わるIoT時代の特徴

IoT（Internet of Things）時代

モノ，ヒトとネットワークとソフトウェアを組み合わせた強みを活用し，さらにAIやビッグデータ分析等の技術を組み合わせた

グローバルな商品／サービス競争の時代

取り巻く環境の変化が激しい時代

IoT時代における環境の変化に機敏に応じることが可能な

商品／サービスを市場／社会に投入し続ける

→企業／行政活動そのもののアジリティと持続的成長

ICTの効率的な利活用



ＩｏＴ時代のシステム/ソフトウェア開発

今や企業／行政活動や市民生活の根幹を担うICTシステムの

迅速でかつ確実な開発・更新

企画～要件定義（上流工程）重視

見える化

定量的マネジメント

適切なマネジメント

組織・プロセスの継続的な改善



企業/行政機関のＩCＴ成熟度

出典：クローズアップ／「身の丈ＩｏＴ」盛ん中小の取り組み紹介（日刊工業新聞，2017年3月6日）をもとに作成

競争力強化

ステージ

効率化

ステージ

置き換え

ステージ

IT導入前の状況

高度活用

導入

活用

AI等先進技術利用

システム開発主導

ICT活用効果定量的管理

専用ソフト開発

クラウド利用

グループウェア

オフィス系ソフト

戦略的活用

基幹業務活用

組織的事務活用

個人事務利用

成熟度を考慮した取組み



内容

プロローグ

1. IPA/SECにおけるシステム構築上流工程強化の活動

背景と課題

取組み概要

2. 経営者／プロジェクト責任者が考慮すべき要件定義のポイント

3. 経営者／プロジェクト責任者が意識すべき「見える化」の要諦

4. まとめ



内容

プロローグ


背景と課題

取組み概要



4. まとめ



背景（１_1） ICTシステムの変遷

インターネット

クラウド

(IoT/IoE)

PCモバイル

PC→携帯→スマホ/タブレット→？

センサー

ビジネスを支援するICT

ビジネスを実行するICT

1980年代 2020年代2000年代1960年代

品質価値スピード

ブラウザ

？

SoE

SoR

(super AI)

SoE: Systems of EngagementSoR: Systems of Record

ＩＣＴシステムの役割が，ますます重要に

攻め

守り



背景（１_2）企業の生存率

資料：（株）帝国データバンク「COSMOS2企業概要ファイル」再編加工（注） 1．創設時からデータベースに企業情報が収録されている企業のみで集計。

2．1980～2009年に創設した企業の経過年数別生存率の平均値を取った。3．起業後、企業情報がファイルに収録されるまでに一定の時間を要し、

創設後ファイルに収録されるまでに退出した企業が存在するため、実際の生存率よりも高めに算出されている可能性がある。

～起業した後、10年後には約3割の企業が、20年後には約5割の企業が退出しており、起業後の淘汰もまた厳しい～

企業の生存率

＜出典＞中小企業白書2011，第3部，中小企業庁．



背景（１_3）企業の平均寿命

倒産企業の平均寿命：23.5年（2014年「倒産企業の平均寿命」調査，東京商工リサーチ）

http://www.tsr-net.co.jp/news/analysis/20150209_05.html

インターネット企業の隆盛


倒産企業の平均寿命推移


背景（１）説明

ICTの役割は、従来の“Support Business”から、今日では“Do Business”

へと変わってきている。すなわち、今やICTはビジネスの要となっている。

また、日本では今後、人口減少に伴うマーケットの縮小が進むものと思

われる。その中で企業が生き残るためには、世界中の企業と

競争しなければならない。すなわち、ビジネスのグローバル化が加速す

る。

このような状況において競争優位を維持し続けるためには、ICTシステ

ムのオーナは、ビジネス環境の変化に機敏に対応し、自ら、そのICTシス

テムに、ビジネス要求を的確に反映することが必須である。



45％

55％7.7

44.1

34.0

30.3

9.2

6.1

18.2

16.7

6.3

14.2

17.5

0 50 100 150 200 250

システム化目的不適当

RFP内容不適当

要求仕様の決定漏れ

開発規模の増大

自社内メンバーの選択不適当

発注会社選択ミス

構築チーム能力不足

テスト計画不十分

受入検査不十分

総合テストの不足

プロジェクトマネージャの管理不足

その他

1.0 5

37

211

163

145

44

29

87

80

30

41

84

プロジェクト数=479

プロジェクト管理

要件定義

背景（２_1）工期遅延理由の分析例

<出典> JUAS・ユーザー企業ソフトウェアメトリックス調査2016

工期遅延理由は，全体の55%が，要件定義の問題（残りの45%がプロジェクト管理の問題）



背景（２_2）開発失敗の主因は要件定義の不備

<出典> 「変わるITトラブル」（日経コンピュータ, 2017年8月3日号）の記事をもとに作成．

0

10

20

30

2000年代 2010年代

原因

別割

合［％

］

年代

開発失敗の4⼤要因とその割合

ユーザ企業が要件をまとめられずベンダが要件を理解できず

ベンダがソフトを開発できず工数・予算の見積り誤り

開発失敗の主因は要件定義の不備（定義をまとめられず，理解できず）



背景（２_3）システム開発の後戻り

企画システム化計画

要件定義

テスト(統合、総合)

プログラム作成

詳細設計

基本設計

運用利用

設計段階からの手戻り

総合テスト段階からの手戻り

運用段階からの手戻り

件数比 85％

件数比 10％

件数比 5％

修正負荷小

修正負荷中

修正負荷⼤

実行

手戻り

手戻り

手戻り

手戻り

手戻り

実行

<出典> JUAS・ソフトウェアメトリックス調査2014のデータから作成

後工程に行くほど，修正負荷（手戻りのコスト）が増大



(参考) 要件定義に関わるトラブル事例


<出典> 10回広域機関システムの開発に関する第三者評価委員会配布資料更新日：2017年7月5日，電力広域的運営推進機関 https://www.occto.or.jp/iinkai/daisansha/dai3sha_10_haifu.html

全体プロジェクトを設置する認識がなく、全体の目的・ゴール設定、統括責任者設置等がされていなかった。

役員は全体プロジェクトを認識し、統括責任者を設置するとともに、全体プロジェクトの目的、スコープ、ゴール、権限、人材、予算等を明確化する。

・システム開発プロジェクトの責任者は、要件定義工程を実施し、機能要件、非機能要件を定める。

・調達時、実行性を総合的に判断できる基準を設定した上で審査し、リスクがある場合には、必ず後続のプロジェクト計画に織り込む。

・要件定義を十分に実施した上で、精度の高い工数・工期を算出したプロジェクト計画を策定し、適時見直す。

・1.5年と工期が短く、新制度に基づいた、過去に例の無い新規のシステム開発。制度設計と並行し、仮定要件により開発を開始。業務運用検討組織が不在で、粗い粒度でしか発注できなかった。

・プロジェクト計画書は策定されていない。スコープ管理、変更管理、品質確認方法及びリスク管理の記載がないか又は管理方法が不十分。

「電力広域機関システム」のトラブル…開発規模10倍近く，運用開始1年以上遅延

<問題> <再発防止提言>


背景（２）説明

システム構築の上流工程に起因するトラブル（開発プロジェクトの失敗、

サービス開始後のシステム障害の発生）が相変わらず多い。トラブルは、

後工程に行けば行くほど、その解決のためのコストが増大する。

従来、ユーザ企業は、ICTシステムの要件定義（の相当部分）をベンダ企

業に任せるケースが少なくない。

上流工程に起因するトラブルを無くすためには、ユーザ企業

自らが要件をきちんと定義し、システム構築を進めることが必要である。



上流工程

システム再構築に特有な問題による

手戻り

要件定義に関する問題による

手戻り

問題の整理とIPA/SECの取組み

要件定義

基本設計

詳細設計

プログラム設計

企画・計画

上流工程に関わる問題今回設定した取組み対象

稼動後の

トラブル多発

品質問題稼動延伸

運用検証

システムテスト

結合テスト

単体テスト

製造

ビジネスに

役立たない

上流工程への手戻り

本日の対象



上流工程強化の取組みの成果（2016年度）

成果物ターゲット（いつ）／（誰に）/何を

要件定義工程（要件定義工程で行うことに特化して指南）

・ユーザ企業・ベンダ企業

・留意事項・勘どころ

企画・計画工程（各工程で何をすべきか企画工程で指南）

・ユーザ企業・ベンダ企業

・再構築手法選定・計画策定

システムに求められる要求の不確実さが増大するIoT時代を見据えた

上流工程の強化へ

ユーザのための要件定義ガイド～要求を明確にするための勘どころ～

システム再構築を成功に導くユーザガイド～ユーザとベンダで共有する

再構築のリスクと対策～

本日の対象



要件定義ガイドの主なターゲット

要件定義ガイドの内容（何を）

経営者／PM

業務部門

システム部門

ベンダ

主なターゲット（誰に）

留意事項

要件定義を不備なく行う

要件定義ドキュメントの品質を上げる

要件定義に対する意識を変える

勘どころ

プロセス視点

ドキュメント視点

業務要件

システム要件

業務要件

システム要件

業務要件ドキュメンテーション

システム要件ドキュメンテーション

業務要件定義活動

システム要件定義活動

ノウハウ・ポイント

ノウハウ・ポイント

ユーザ企業ベンダ企業（※注）・責任を持つステークホルダを表す･他のステークホルダも協力する

本日の対象



内容

プロローグ


背景と課題

取組み概要



4. まとめ



前提：要件定義関連のプロセス

共通フレーム 2013主ライフサイクルプロセス

要件定義フェーズ

開発フェーズ

システム要件定義

ソフトウェア要件定義

システム方式設計

ソフトウェア方式設計要件定義プロセス

（開発系プロセス）

企画フェーズ

企画プロセス

まず，要件定義や前後の工程の目的を理解する

要求システム要件業務要件 ←要件定義ガイドのスコープ



要件定義に関する問題の分析

要件定義に関する問題



検討WG委員から提起された要件定義に関わる課題

① ビジネス目的と施策が合致していない

② 手段が先行し，「何のために」が理解できていない

③ 業務の複雑さが増している

④ 合意形成が取れていない

⑤ 膨らむ要求を抑えきれない

⑥ 要件定義書の不備が多い

（抜け，漏れ，曖昧，不完全，不整合などへの対策が不十分）

⑦ 非機能要件を決めきれない

⑧ 要件定義の記述の粒度や深さの基準が不明、内容の評価ができない

⑨ As-Isの分析，To-Beの可視化が不十分

⑩ 業務部門の参画、理解が不十分

⑪ システム部門が要件を引き出せない

⑫ 体制，役割分担の不備での失敗

システム開発の現状に基づく要件定義に関する課題



要件定義の課題を解決するためのポイント

1. 当該システムを開発する妥当性を検討する経営課題に対して適切な位置付けのIT投資であるかを考える経営者の視点での問題認識と対策を十分に盛り込む技術進歩を予測し，システムを開発するタイミングは妥当かを確認するリスク評価を踏まえた非機能要件について，ユーザの要望を明確にする他社との競争を意識した場合，工期は妥当かを確認する

2. システム化の前に業務を分析・整理する業務部門の責任者が現在のシステムの実態を正しく理解し，要件定義に反映しているかを確認する全社視点で見て，重複作業や無駄を十分に排除したシステムになっているかを確認する

3. 要件定義を確実に効率よく進める合意形成に時間がかかることを前提としてプロジェクトを計画する要求は膨らむことを前提としてプロジェクトを計画する

4. 決めるべきことは決めてから次に進む要件定義工程で決めるべきことを決めるために十分な工期，工数を割り当てる要件定義成果物の品質向上に努める

5. ユーザとベンダの役割分担を考える要件定義の契約基本形は準委任契約であるシステムの効果を評価する責任は業務部門である仕様変更が生じた場合を想定した予算を確保しておく



1. 当該システムを開発する妥当性を検討する（1）

基本的な考え方

ITの役割は、“Support Business”から“Do Business”へと変わってきた。業務を効率化し、サポートする位置付けから、経営課題を解決するためのビジネスの要となっている。

ポイント

ビジネス構造とその最適化対策を準備将来にわたって改革を進める構想を整理グローバルな発展のためにタイミングを重視

メッセージ[1]

経営課題を解決する適切なIT投資かどうかを判断する。



1. 当該システムを開発する妥当性を検討する（2）


果たすべきことは、企業の社会的な責任である。自然災害やサイバー攻撃などの想定外の事態が発生しても、企業には責任を果たすことが求められる。

ポイント

システムに関する想定外の事態をリスクとして把握リスクに対する技術的な対応は非機能要求として明確に非機能要求の明確化は、経営リスクの対応そのもの

メッセージ[2]

ITのリスクは経営者が経営に直結するリスクとして認識する。



2. システム化の前に業務を分析・整理する（1）


ソフトウェアやシステムを全く利用していない企業はない。新たなシステムを開発する前には、既存システムの利用実態を把握する。把握した内容を業務と関連付けて分析した上で、要件定義に反映する。

ポイント

新たなシステムを考える前に、既存システムを分析利用部門や業務部門は、業務とシステムを正しく理解システム部門やベンダ企業とともに、要件定義へ反映

メッセージ[3]

既存システムの活用状況を分析し、投資判断する。



2. システム化の前に業務を分析・整理する（2）


組織改革や業務改善に合わせて、重複する作業や無駄な作業が浮き彫りになる場合がある。新たなシステムに機能を追加するだけではなく、削除すべき既存の機能があることを意識する。

ポイント

全社視点での共通化を注視システム間連携を簡潔にし、企業運営の柔軟性を維持組織や人事を刷新した場合には、重複や無駄を排除

メッセージ[4]

重複や無駄を排除するには、思い切って機能を削除する。



3. 要件定義を確実に効率よく進める（1）


システム化には、予想以上にステークホルダが存在する。要件定義のスケジュールを立てる際には、成果物作成だけでなく、合意形成にかかる期間を十分に確保できているかを確認することが望ましい。

ポイント

目的が曖昧な議論で、要件定義の時間を費やさないステークホルダを把握し、意思決定プロセスを計画業務部門の責任者は、迅速に意思決定する意識を持つ

メッセージ[5]

合意形成には時間がかかることを前提に計画する。



3. 要件定義を確実に効率よく進める（2）


要件定義が進む中でイメージやアイデアが湧く。おのずと要求は膨らむ。要求は膨らむことを前提に、膨らんだ際の取捨選択基準や意思決定方法を予め計画しておく。

ポイント

要求は膨らむことを前提に計画をたてる規模見積りが2でも、4まで膨らみ、2に戻すが、3で完了「2:4:2:3の法則」を念頭にした計画が、成功に導く

メッセージ[6]

要求は膨らむことを前提に計画する。



4. 決めるべきことは決めてから次に進む（1）


仕様が複雑化し規模が増えているにも関わらず、要件定義の工数割合が少ない傾向は、問題化の前兆である。「規模が大きくなると、実時間、実工数でコストも増える」ことから、要件定義の工数割合を増やすことが望ましい。

ポイント

システム稼働後の修正負荷は、2倍から30倍にも拡大要件定義でテスト工程成果物を作成すると手戻り削減にテスト工程の負荷軽減や障害発生防止などの効果

メッセージ[7]

要件定義に十分な工期、工数を割り当てる。



4. 決めるべきことは決めてから次に進む（2）


要件定義ドキュメントのフォーマットを提示するだけでは、必ずしも品質向上にはつながらず、手戻りはなくならない。「どう書くか」と「どう作り上げるか」（何をどのレベルまで書くか）を指南しなければならない。

ポイント品質向上のため、要件定義ドキュメントから抜け、漏れを

どうなくすか（どう書くか）の勘どころを示す[ガイド3章]

要件定義ドキュメントをどう考えて、どう作るか（どう作り上げるか）の勘どころを示す[ガイド4章]

メッセージ[8]

要件定義の品質向上により、手戻りを削減する。



5. ユーザとベンダの役割分担を考える（1）


要件はユーザ企業が責任を持って決めて、定義する。しかし、「責任を持って」というだけでは決め切れないことが多いので、ベンダ企業やユーザ部門、運用部門等と協力して決める。

ポイント

情報システム・モデル取引・契約書では準委任が基本請負契約は、ユーザの参加割合が低くなりがち準委任契約は、ユーザの責任の自覚と覚悟を高める

メッセージ[9]

準委任契約を基本に、ベンダ企業と協力して要件を定義する。



5. ユーザとベンダの役割分担を考える（2）


業務部門は要件定義に責任を持つだけではない。本稼働後にシステムの適用効果を正しく評価するために、効果を測定する指標を定めて、その目標指標が達成できるように要件を定義する。さらに、効果を運用中に実測できる仕組みをシステムに組み込む。

ポイント業務部門が投資効果に対する責任を持つことが必要指標を持ってシステム稼働後に投資効果を測定最終的には目標について効果を評価

メッセージ[10]

要件定義で、投資効果を評価する方法を決める。



要件定義のポイント（メッセージ一覧）

メッセージ

[1]経営課題を解決する適切なIT投資かどうかを判断する。[2]ITのリスクは経営者が経営に直結するリスクとして認識する。[3]既存システムの活用状況を分析し、投資判断する。[4]重複や無駄を排除するには、思い切って機能を削除する。[5]合意形成には時間がかかることを前提に計画する。[6]要求は膨らむことを前提に計画する。[7]要件定義に十分な工期、工数を割り当てる。[8]要件定義の品質向上により、手戻りを削減する。[9]準委任契約を基本に、ベンダ企業と協力して要件を定義する。[10]要件定義で、投資効果を評価する方法を決める。



要件定義のポイント（まとめ）

要件定義とは、

・新たなビジネス価値を創造して

・ビジネスプロセスを改革・改善し、

・それを実現するシステム化要件として定義する

ことである。

それゆえに、ユーザ企業の経営者や業務部門長は、

要件定義に対する認識を新たにし、

要件定義を自ら牽引すべし。


ベンダ企業は，このことを踏まえてユーザ企業を支援すべし。


内容

プロローグ


背景と課題

取組み概要



4. まとめ



見える化の身近な例（１）


135/85mmHg 以上を高血圧と判定（家庭血圧値）

協力者

見える化：

形式知：

１４０

９０

多数・長期間の健診・臨床データ等

分析

＜高血圧対策＞1 肥満解消（運動）2 ストレス解消3 規則正しい睡眠4 禁煙5 減塩6 ．．．

知見：

比較アクション

ヒューマン・ライフサイクル


見える化の身近な例（２_1）

HV車における表示例

表示内容に応じて運転の仕方を改善




バッテリ（電気）使用走行

ガソリン使用走行

バッテリ充電走行（ガソリン使用無し）


走行モード.WMV

走行モード.WMV

航続可能距離.WMV

航続可能距離.WMV



ガソリン使用走行

バッテリ（電気）使用走行

バッテリ充電中（ガソリン使用）

バッテリ充電中（ガソリン使用無し）ガソリン

バッテリ

走行駆動


エネルギー使用.WMV

エネルギー使用.WMV



燃費の推移グラフ



「見える化」のポイント

＜ポイント＞

暗黙知の形式知化（測る化，可視化）

社会智（分かる化）

智の運用

情報の(セミ)オープン化

経験/状態をデータに基づいて見える化，整理・体系化

社会にとって役立つ知見

知見に基づき行動する，知見を継承するための，不断の努力

多様な意見に基づく，ブレークスルー/イノベーションの創出



＜参考文献＞山下: 社会の“インテリジェンス”活用推進に向けた考察, SEC journal, No.23.

「見える化」の進化

暗黙知形式知（知識）

形式知（智恵）

個有

共有

組織

社会

現状

現状

現状

個人が目指すところ

企業が目指すところ

人類が目指すところ

当面のマイルストーン

見える化分析・体系的整理知とその共有に関する進化

オープン・イノベーション



「見える化」は改善のための道具

<出典> TPS/リーン方式の基本原則とアジャイルソフトウェア開発への適用2012/1/3 （社）持続可能なモノづくり人づくり支援協会（ESD21）黒岩惠 ([email protected])https://www.esd21.jp/news/TPSのアジャイルソフト開発への適用（2012）.pdf

「全員参加で見える化のツールを考案し、

見える化により現状と問題点を共有し、

チーム活動により問題解決」

「見える化は改善の道具であり、

管理者の自己満足のツールではない」


https://www.esd21.jp/news/TPSのアジャイルソフト開発への適用（2012）.pdf


改善の見える化：成熟度モデルとプロセス

プロジェクト・プロセス

組織プロセス

エンジニアリング・プロセス

統計的品質管理プロセス

プロセスと技術の変更管理プロセス

レベル２：管理された

レベル３：定義された

レベル４：定量的に管理された

レベル５：最適化している

要求分析、設計、レビュー、テスト

組織標準の確立、教育訓練、ノウハウの共有

要求の管理、開発の計画、進捗の管理、成果物の管理、活動の検証

レベル１：初期

CMMI：（Capability Maturity Model Integration；by Carnegie Mellon University SEI）連続表現モデル（能力度レベル「CL0~CL5」）と段階表現モデル（成熟度レベル「ML1~ML5」）が存在し、一般的には成熟度レベルでの達成度を表現する場合が多い。


成熟度モデル（ＣＭＭＩの例）


(留意点) 現場の自発的活動の落とし穴

ＩｏＴによる「つながる工場」が最大限効果を出すには、

あらゆる工場をつないでビッグデータ（大量データ）を収集し、

分析することが不可⽋だ。

しかし、企業内でも工場や部署をまたいだ⽔平展開は難しい。

特に「カイゼン」など

現場の自発的活動に依存しすぎると⽔平展開に⽀障がでる。

現場の自発的な改善活動

→ 現場は改善するが，部分最適化に陥り易い

経営者の役割

→ 改善活動をサポートしつつ，社内外への水平展開に配慮


<出典> なぜ⽇本は「第4次産業⾰命」を構想できなかったのか，ニュースイッチ，2017年06⽉07⽇．http://newswitch.jp/p/9293

http://newswitch.jp/p/9293


提案：地域/業界の協働による取組み

■問題意識■自己完結では日本のIoTは負ける玄忠雄＝日経コンピュータ，2017/07/26http://itpro.nikkeibp.co.jp/atcl/watcher/14/334361/072500887/

地域等の企業（/行政機関）が協働して・全体最適化・データの共用（定量データも）

キーワードデータの標準化（→オープンデータ）サプライチェーンオープンイノベーション


http://itpro.nikkeibp.co.jp/atcl/watcher/14/334361/072500887/


データに基づく管理（定量的マネジメント）の分類

データ手法見える化ツール(IPA) 主な活用方法

定性

作業日報等ビッグデータ解析 (分析) なし因果関係確認等

失敗/成功事例 (分析) チェックリスト（例:信頼性自己診断ツール）

教訓集

妥当性確認/現状認識(問題点抽出)

再発防止策障害事例 (分析)

定量

開発データインプロセス計測

定量的プロジェクト管理用ツール

異常の予兆検知

(4) 比較による計画策定・妥当性確認ベンチマーキング (分析) データ白書

運用データビッグデータ解析 (分析) なし障害予兆検知等

データマイニング（ビッグデータ解析）

活用（確認・対策等)のための知見の抽出

(4) 定量的品質管理，等

(1) 情報システムの障害状況の整理 (2) 障害情報の収集・分析に基づく教訓の共有(3) 信頼性自己診断ツール (4) 定量的品質管理(5) 定量的プロジェクト管理用ツール (6) ソフトウェア開発データ白書及び関連ツール

(2)(3)

(1)(2)

(5)

(6)

ソフトウェアリポジトリ



定量データの活用によるマネジメント手法

定量データの活用による開発マネジメント手法

・インプロセス計測進行中プロジェクトの改善を図ることが主眼。

（主なフィードバック先は、当該プロジェクト）

・ベンチマーキング品質マネジメント等の改善を図ることが主眼。

（主なフィードバック先は、組織及び標準類）



プロジェクト・マネジメント関連の標準類開発プロセス関連の技術標準類

ポストプロセス計測データ

◇完了プロジェクトの実績データ

◇運用・保守のデータ

開発プロセス

要件定義

基本設計

詳細設計

製作総合テスト

結合テスト

プロジェクト

計画（P) 対策（A)

【個々のプロジェクト・マネジメント】

人の作業

入出力

作業の流れ

プロジェクト内の定量的管理のPDCAサイクル（工程毎に）

【個々のプロジェクト・マネジメント】プロジェクト【個々のプロジェクト・マネジメント】プロジェクト

運用・保守

インプロセス計測データ

分析･予測（C)

【組織のプロジェクト・マネジメントのやり方】

【組織のマネジメントのやり方】

組織のマネジメント関連の標準類組織の技術標準類

計画

測定（D)

分析

改善のフィードバック／フィードフォワード

外部（公開）ベンチマーク

内部ベンチマーク

改善のフィードバック




ベンチマーキング比較・改善検討（妥当性評価）

ベンチマーキング比較・改善検討

定量データの活用に基づく改善のモデル



(参考) EBSE（根拠に基づくソフトウェアエンジニアリング）

［参考］医療分野に「EBM」という言葉がある．EBMは，Evidence-Based Medicineの頭文字を取ったものであり，”根拠に基づく医療”を意味する．簡単には，現在利用可能な最も信頼できる情報を踏まえて，目の前の患者さんにとっても最善の治療を行う，ということ．

＜出典＞ http://spell.umin.jp/index.htm の内容を参考にまとめた．

Evidence-Based Software Engineering

Evidenceの例

・実証に基づく知見（形式知）

・統計データ

・測定データ


http://spell.umin.jp/index.htm


定量管理はしてない

何らかの定量管理の手法を

導入している

76%

54%

24%

46%

プロジェクト成功率と定量管理手法の相関

失敗成功

定量的マネジメントの効果例

＜出典＞［プロジェクト実態調査800社 1］測る企業は成功率が2倍に，IT Pro 2015/11/30．をもとに作成

成功率=

約２倍

経営層の理解が重要

（平均成功率失敗：69% 成功：31%）

参考データ



関連するIPA/SECの成果物

(0) 見える化

(1) 情報システムの障害状況の整理

(2) 障害情報の収集・分析に基づく教訓の共有

(3) 信頼性自己診断ツール

(4) 定量的品質管理

(5) 定量的プロジェクト管理用ツール

(6) ソフトウェア開発データ白書


http://www.ipa.go.jp/sec/index.html



(0) 見える化

http://www.ipa.go.jp/sec/softwareengineering/std/ent01-d.html


(1)プロジェクト「見える化」_100130.ppt

(1)プロジェクト「見える化」_100130.ppt


(1) 情報システムの障害状況の整理


SEC journal （2010年以降）報道された障害事例をリストアップし，一部を分析

http://www.ipa.go.jp/sec/secjournal/info.html


障害に基づく教訓の共有による信頼性向上のしくみ現状（教訓の共有なし）

製品機器/ITサービス

(Ａ社)

社会社会

より高い安全・安心な製品機器/ITサービスの提供


(Ｂ社)


(Ｃ社)

信頼性

信頼性

信頼性

原因分析対策検討

対策実施

教訓Ａ


対策実施

教訓Ｂ


対策実施

教訓Ｃ


(Ａ社)


(Ｂ社)


(Ｃ社)

信頼性

信頼性

信頼性

原因分析・対策検討一般化・抽象化・普遍化

体系的整理

教訓Ａ

教訓Ｂ

教訓Ｃ

対策実施対策実施対策実施障害障害障害障害障害障害

重要インフラ等重要インフラ等

専門家，有識者のご協力を得てIPA/SECや業界団体等が担う共有活動

教訓教訓教訓

機密保持等のルール

類似障害の発生

(2) 障害情報の収集・分析に基づく教訓の共有


http://www.ipa.go.jp/sec/system/index.html


（Ａ）重要インフラ等システム

（Ｂ）企業基幹システム

（Ｃ）その他のシステム

0

20

40

60

80

100関係者の責務

経営層の責務

企画・要件定義段階における留意事項

開発段階における留意事項

保守・運用段階における留意事項

障害対応に関する留意事項

システムライフサイクルプロセス全体における横断的な留意事項

開発手法・ツールの活用及びテスト環境の整備

信頼性・安全性向上に向けた技術の活用及び留意事項

人材育成・教育の実施

組織の整備

契約における重要事項の明確化

情報システム構築の分業時の役割分担及び責任関係の明確化

着実な契約履行

基準点/満点

得点/満点

(3) 信頼性自己診断ツール

各質問の得点状況

83項目の質問への回答項目群対応の得点状況（得点率）

0

2

4

6

8

10

Q1

Q2

Q3

Q4

Q5

Q6

Q7

Q8

Q9

Q1

Q2

Q3

Q4

Q5

Q6

Q7

Q8

Q9

Q10

Q11

Q12

Q13

Q14

Q15

Q16

Q17

Q18

Q19

Q20

Q21

Q22

Q23

Q24

Q25

Q26

Q27

Q28

Q29

Q30

Q31

Q32

Q33

Q34

Q35

Q36

Q37

Q38

Q39

Q40

Q41

Q42

Q43

Q44

Q45

Q46

Q47

Q48

Q49

Q1

Q2

Q3

Q4

Q5

Q6

Q7

Q1

Q2

Q3

Q4

Q5

Q6

Q7

Q1

Q2

Q3

Q4

Q5

Q6

Q7

Q8

Q9

得点

基準点

<使い方> 診断結果に基づき，基準点を下回る項目について，強化施策を講ずる．

システムタイプ


http://www.ipa.go.jp/sec/softwareengineering/tool/dependability.html


http://www.ipa.go.jp/sec/softwareengineering/std/ent01-b.html

(4) 定量的品質管理

SECSoftware Engineeringfor Mo･No･Zu･Ku･Ri

Software Engineering Center 26

定量的な品質管理

品質目標値

時間

信頼性要求水準

プロジェクト特性で補正

適切な指標で状況を“見える化・測る化”

目標値達成に向けてコントロール品

質

2010-01-30 Copyright © 2009-2010 IPA, All Rights Reserved


(2)1定量データ活用_100130.ppt


(2)2定量的品質管理_100130.ppt


(5) 定量的プロジェクト管理用ツール

http://www.ipa.go.jp/sec/softwareengineering/tool/ipf/index.html


WBS進捗推移

WBS進捗変化

ツールの例


(6) ソフトウェア開発データ白書


http://www.ipa.go.jp/sec/reports/20151116.html

(6-2) 組込み系

データ白書(本編)

金融・保険企業編情報通信業編製造業編

(6-1) エンタプライズ系

http://www.ipa.go.jp/sec/reports/20161012.html




内容

プロローグ


背景と課題

取組み概要



4. まとめ



★ ビジネスの３要素

５

ビジネスの３要素ヒト

モノ

カネ

ビジネスの４要素

ビジネスの５要素変化対応の機敏性（Ａｇｉｌｉｔｙ）

Business Intelligence

BigData情報

時間

IoT時代のフォーカス

データ


参考データ

ＩＴプロジェクト成功の定義（あるアンケートの例）

<出典> CHAOS MANIFESTO 2014

Triple constraints 15%On budget 32%On time 30%On Target (scope) 26%On goal 29%Valuable 52%Satisfied 41%All of the above 33%

3 要素(予算，納期，機能充足)

予算

納期

機能充足（スコープ）

目標(*1)

価値

満足

上記6要素の全て

(*1) 組織の戦略目標にどれだけ合致しているか?

6要素のうち，4つまで選択可．(回答数=309)

15%

32%

26%

29%

52%

41%

33%

30%

Ｃ

Ｄ

Ｑ

「価値」を適切に要件へ


技術者

経営層


見える化による智恵の共有


135/85mmHg 以上を高血圧と判定（家庭血圧値）

協力者

見える化：

形式知：

１４０

９０

多数・長期間の健診・臨床データ等

分析

＜高血圧対策＞1 肥満解消（運動）2 ストレス解消3 規則正しい睡眠4 禁煙5 減塩6 ．．．

知見：

比較アクション

ソフトウェア・ライフサイクルソフトウェア開発データの収集・蓄積

ソフトウェア開発における基準ソフトウェア

開発プロセスの

標準作業手順ソフトウェア開発に関するメトリクス

・日々のデータ測定・表示

協働

４．まとめ（に代えて）


見える化による改善

ソフトウェア開発の例ソフトウェア開発に関するメトリクス

・日々のデータ測定・表示

表示内容に応じて開発の仕方を改善




イノベーションの観点

<出典>（ニッポンの宿題）イノベーションへの道黒川清さん, 朝日新聞, 2017年4月21日.

イノベーションは、従来の枠組みを壊す「破壊的」なものと、改善の先にある「漸進的」なものがある。日本は「破壊的」には弱いが、「漸進的」に強みがある。そのような「弱み」と「強さ」を意識することは、とても大事です。

<出典>（経済気象台）忘れられる「普通の人々」 by 山人, 朝日新聞, 2017年4月15日.

政府や多くの識者は、エリートによる華々しい技術的成果こそが経済成長の原動力であると断じ、そこに多くの経済資源を投入する。しかし米シカゴ大研究者らの分析によれば、イノベーションとそれによる経済成長をもたらすのは、いわゆる創造的破壊ではなく、既存の技術や製品の地道な改良だという。それを支えるのは、日々努力を積み重ねる多くの普通の人々であるに違いない。



イノベーションのジレンマ


（参考）エンジニア向けセミナー（DEOS主催）のご案内

上流工程強化研修主催：(株)北海道ソフトウェア技術開発機構

10月11日テーマ：失敗しない要件定義の勘どころ

～ビジネス要求を正しくシステム化要件として定義するポイントの解説～

対象：要件定義について学びたいエンジニア

10月27日テーマ：システム再構築を成功に導くための手法選択と計画立案

～再構築におけるリスクの正確な把握と対策の合意手順の解説～

対象：システム再構築について学びたいエンジニア




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

アンケートへのご協力をよろしくお願いいたします．



以降，参考



IoTの導入予測例

<出典> Why the Internet of Things could change politics, WEF, 2016-10-03https://www.weforum.org/agenda/2016/10/why-the-internet-of-things-could-change-politics

参考データ



インターネット関連企業の隆盛

<出典>Emma Luxton: Farewell oil, hello tech - the world’s 5 most valuable companies in 2006 and 2016, WEF,21 September 2016.

注) AlphabetはGoogleグループの持株会社（2015年10月設立）

諸行無常・盛者必衰

参考データ



定量的プロジェクト管理用ツールの例


定量的プロジェクト管理ツール「EPM Base Ver. 2.0」株式会社オープンストリームhttps://www.opst.co.jp/epm/

Lychee Redmine株式会社アジャイルウェアhttps://lychee-redmine.jp/

市販ツール例（質疑応答用）

いっそう重要性を増すシステム開発の上流工程 - ipa...2017/09/07 ·...

Documents