Upload
others
View
1
Download
0
Embed Size (px)
Citation preview
Copyright©2018 NTT corp. All Rights Reserved.
SQiP2018 C1-1
インキュベーション型プロダクトに対応したソフトウェア開発リスクマネジメント
2018/9/13 日本電信電話株式会社
ソフトウェアイノベーションセンタ○秦泉寺 久美
羽室 大介
ソフトウェア品質シンポジウム2018
2 Copyright©2018 NTT corp. All Rights Reserved.
本発表は NTT(持株会社)研究所のソフトウェアプロダクトアウトにおけるリスクマネジメントに関する制度設計について述べたものである。
本発表で述べる「NTT」とはNTTグループにおける持株会社の研究所を指す。
本発表で述べる「品質」は広義の品質で、ISO/IEC9126の6つの品質特性で説明できるものをさす。狭義の品質である信頼性/バグだけではない。
本発表で述べる「プロダクト」はソフトウェアプロダクトをさす。
まえおき
3 Copyright©2018 NTT corp. All Rights Reserved.
1. 背景(コンテキスト)と課題
~NTTのR&Dとプロダクトアウト体制~
2. リスクマネジメント施策(制度設計)
3. 効果と考察
4. 今後の課題
アジェンダ
5 Copyright©2018 NTT corp. All Rights Reserved.
●NTTはオーバヘッド組織と3総合研究所12研究所からなる。
●NTT研究所は5事業会社に対し研究所成果(=プロダクト)を提供
研究所プロダクト開発はNTT-G内外のベンダへ発注することが多い。
5事業会社は研究所プロダクトをさまざまな方法で利用する。
プロダクトアウトには社内的に技術や費用の観点でのオーソライズが必要
背景(1):プロダクトアウト体制
3総合研究所12研究所 (約2500名の研究員) プロダクト開発時は発注側になる
受託開発
プロダクト提供
NTT-G内外のベンダ企業
事業会社
受託会社
6 Copyright©2018 NTT corp. All Rights Reserved.
NTTのR&Dのフェーズをモデル化すると、①創出フェーズ、②発表フェーズ、③プロダクト化フェーズ、④提供・維持管理フェーズの4つから成る。
研究所の営みの大半は創出フェーズ。
本発表は③プロダクト化フェーズおよび④提供・維持管理フェーズについてである。
背景(2):NTT R&Dの営み
創出フェーズ 発表フェーズ
プロダクト化フェーズ 提供・維持管理フェーズ
開発 プロダクト
アイディアを可視化し、具現化していく段階
プロダクトアウトを目的とした開発をする段階
プロダクト化判断
リリース判定
特許や学会でアイディアを発表する段階
プロダクトアウトする段階
7 Copyright©2018 NTT corp. All Rights Reserved.
事業とのエンゲージメントの強いネットワーク開発は少数となり、事業とのエンゲージメントが強くないインキュベーション型のプロダクトが多くなってきている(=ネットワークシステムが激減している)。
開発者がほぼ全研究所、提供先が全事業会社にわたる。
インキュベーション型プロダクトとは、シーズ指向、次のサービスの核になり得るプロダクト(できたて。使ってみないとわからない側面も)。品質も多様。
背景(3):プロダクト開発の特徴
いにしえ(分社前等) 現在
主力のプロダクトの種類
ネットワークシステム サービス、アプリケーション、処理エンジン、ファームウェア、ミドルウェアなどインキュベーション型プロダクトを含む(多種多様)
開発期間 9ヶ月~1.5年 3ヶ月~6ヶ月
開発部署 特定の研究所 案件数に差はあるがほぼ全研究所
提供先 現:NTT東・西 5事業会社全般
事業とのエンゲージメント
強い 弱い
求められる品質 厳しい商用品質 多様な品質
従来の一般的な開発 新たな形態・課題
8 Copyright©2018 NTT corp. All Rights Reserved.
インキュベーション型プロダクト開発の課題
リリースのための品質基準を一律に定義できない
全研究員(約2500人)が開発者になりえる
(品質保証部門(品質ゲート)等の組織を持たない)
実際にあったトラブル
ベンダ企業に結果的に予定外の作業をさせてしまう、想定する作業がなされないなど、作業(=品質)に過不足が生じる。
事業会社が開発主管(=研究所)が想定をしていない使い方をしてトラブルになる
課題に対するアプローチ
開発の安定化と事業とのトラブル未然防止(目的)のためのリスクマネジメント施策→組織で品質責任を持つことの徹底
施策の確実な運用(研究者全員が確実に適用する)
インキュベーション型プロダクト開発の課題
10 Copyright©2018 NTT corp. All Rights Reserved.
インキュベーション型開発の特性を鑑み、安定した開発および事業とのトラブル防止を目的とし、研究員が自律的な品質活動(品質を計画、管理、把握、事業と合意)し、組織で品質責任を持つことを確実に実施するため制度設計。 インキュベーション型ソフトウェア開発標準を策定し施策の基盤とし、プロダクトアウトする案件は全件適用するようにルールを設定
確実な運用のために全件第三者によるリスクチェックを実施
将来的な施策の簡易化も目論み、自学自習のための統計データ閲覧、開発文書閲覧、e-learning受講を実現
リスクマネジメント施策
インキュベーション型ソフトウェア開発標準
開発主管 (研究開発組織)
受託会社 事業会社
(3)品質を把握
(4)品質を合意
(2)品質を管理
(1)品質を計画
統計データ閲覧 開発文書閲覧 第三者による リスクチェック受診 e-learning受講
②確実な運用
①施策の基盤とルール化
③自学自習
自律的な品質活動
11 Copyright©2018 NTT corp. All Rights Reserved.
① 施策の基盤とルール化 ・インキュベーション型開発標準 ・ルール化
インキュベーション型プロダクトのためのソフトウェアリスク回避施策
12 Copyright©2018 NTT corp. All Rights Reserved.
「リリースのための品質を一律に定義できない」ため、研究者が自プロダクトの品質を定義するのを助けるための開発標準を策定。
SLCP2007をベース。35のプロセスを必須実施事項化。
品質クラスの定義:自プロダクトの使われ方によるクラス化。
品質確認表の提供:ISO/IEC 9126に基づく105の品質観点
インキュベーション型開発標準
開発計画書算サンプル
リリース判定書サンプル 品質確認表
要求仕様書サンプル
文書サンプル
開発プロセスの規定 「品質クラス」
の定義 本文
インキュベーション型開発標準
一般的な開発標準
SLCP2007に基づき35のプロセスを必須実施事項として規定
ISO/IEC 9126の6品質特性/27副特性を基本とし、品質の作りこみ、検証において具体的に考慮すべき105の観点をリスト化
自プロダクトがどのような使われ方をするのかをクラス化
13 Copyright©2018 NTT corp. All Rights Reserved.
品質クラス
品質 クラス
サービス導入の可能性からみた定義 利用例
A 事業会社がほぼそのままサービス導入でき,インフラやネットワークサービスのようにシステムを止めてはいけないような極めて厳しいSLA(Service Level Agreement)下で使用されることを想定したプロダクト
インフラ,ネットワークサービス
B 事業会社がほぼそのままサービス導入できるが,パッケージやソリューションのようにアプリケーションソフトウェアの再起動がある程度許容される状況下で使用されることを想定したプロダクト
パッケージ,ソリューション
C 実証実験のように使い方が一部限定され,事業会社がサービス導入するには機能・非機能要件やアーキテクチャの一部の見直しと一部の追加試験などを要するプロダクト
実証実験
D 機能のデモンストレーションのように使い方が極めて限定され,事業会社がサービス事業導入するには,機能・非機能要件およびアーキテクチャ,試験などについて抜本的な見直しを要するプロダクト
デモンストレーション
E 品質見解が無いプロダクト 研究所利用
使われ方による5段階の定義
品質クラスA,B:そのまま事業に使われる
品質クラスC,D:そのままでは事業に使われない
品質クラスE:品質見解がない
14 Copyright©2018 NTT corp. All Rights Reserved.
品質確認表(抜粋) 品質 特性
品質副特性 確認項目
信頼性 成熟性(試験の妥当性)
①試験項目数②ホワイトボックス試験(カバレッジ)③ブラックボックス試験④非機能試験/システム試験
成熟性(障害収束性)
①収束性②障害摘出③制限事項
障害許容性 ①エラーチェック②エラー時の継続運用③重要入力の確認④ファイル破壊防止
回復性 ①UNDO/REDOの実施②チェックポイントの構築③ソフトウェア閉塞④障害解析用の記録
使用性 理解性 ①チュートリアル②デモ③操作メニュー④マニュアル(障害時)
習得性 ①マニュアル(通常操作時)②ユーザレベル③ヘルプ機能
運用性 ①デフォルト設定②ガイダンス指示③操作の確認④障害の通報⑤運用状況の記録
魅力性 ①魅力的なユーザインタフェース②魅力的な機能③魅力的な非機能
効率性 時間効率性 ①応答時間②スループット③ターンアラウンド④過負荷状態での効率性⑤縮退運転時の効率性
資源効率性 ①メモリ②CPU③HDD④縮退運転時の効率性
品質 特性
品質副特性 確認項目
保守性 解析性 ①マニュアル(保守・解析)②進行状況の確認③障害時の処理履歴④解析情報のダンプ
変更性 ①変更対応容易性②変更内容確認容易性③プログラムやデータの独立性
安定性 ①変更に対する自身への影響②変更に対する他への影響③変更のキャンセル
試験性 ①確認試験要領②退避性③確認性④自己診断機能⑤テスト・シミュレーション機能
移植性 適応性 ①検証実績②多言語対応③OSSなどの導入
設置性 ①マニュアル(導入)②インストール機能③留意事項の明確化
共存性 ①共存できないソフトウェア②共存条件③共存するための変更④データへの排他アクセス⑤データ運用の矛盾なき統合
置換性 ①データ移行②移行前共存ソフトウェアへの非影響
③移行前ソフトへの互換性④移行前共存ソフトウェアへのユーザインタフェース維持⑤移行前システムへの復旧
品質服特性毎に3~5の確認項目を定義
合計105の確認項目
確認項目毎にどの程度考慮するかを0~3で評価 平均値をプロダクトの“品質レベル”と定義
105項目がすべてが3の評価であれば品質レベルは“3”となる
品質クラス毎に推奨基準を設けているが決して必須基準ではない。
(>自分で考えることの徹底)
15 Copyright©2018 NTT corp. All Rights Reserved.
品質確認表の具体的な使い方(どうやって自分で考えるか)
要求やシーズ、利用条件から品質クラスを決定。クラスAであれば、「そのまま事業でのサービスに使われ、厳しいSLA下で動作することを求められる」ことを認識
その認識の下、品質確認表から品質確認項目を選定し対応の度合を決める
品質確認項目の対応度合を具体的に要件と作業に落とし込む。
品質を決めるということはプロジェクトスコープを決めることに他ならない。
品質項目から具体的要件・作業へのブレークダウン
品質確認表による品質確認項目の選定
品質クラスの決定
要求、シーズ、利用条件
要件 (要求仕様書/基本
設計書)
WBS
作業 (開発計画書)
16 Copyright©2018 NTT corp. All Rights Reserved.
以下の2つを運用ルール化し、開発主管組織が品質に責任をもつことを意識付け。 (かつ、2回のプロジェクトレビュー後に資料を施策主管に提出、第三者チェックを受ける)
ルール化
ルール番号 運用ルール
1 プロダクトアウトされるソフトウェアは各案件にてあらかじめ計画したA~Dクラスの品質を確保すること
2 適用対象案件について、二つのプロジェクトレビュー(プロダクト化判断、リリース判定)時に、開発主管組織長が品質クラスに応じた品質とリスクの確認を行うこと
外部仕様検討 開発 (開発標準適用) 維持管理
プロダクト化 判断
リリース 判定
開発主管組織長
品質クラスに応じた品質の計画と把握を組織的に行う。
開発主管組織長
17 Copyright©2018 NTT corp. All Rights Reserved.
②確実な運用・システムの利用・第三者チェック
インキュベーション型プロダクトのためのソフトウェアリスク回避施策
18 Copyright©2018 NTT corp. All Rights Reserved.
案件管理機能による運用の確実化と運用工数の劇的削減
オーソライズ会議主管から案件情報を入手し、登録する
会議付議日を起点に文書の提出遅延者にアラートメールを送付
アラートが限度を超えたらエスカレーションを開発主幹組織に対して発出
アラートメールは資料提出のタイミングで都度発出される
案件管理機能によって1500人時/年の運用稼働を削減
システムによる運用
案件情報/文書/帳票投入
資料送付契機(アラート)、帳票エラー通知等
施策主管
施策主管/開発主管(研究者)
開発主管 DB
他プロジェクトの 文書検索・閲覧
データ分析機能(BIツール)
案件管理機能
文書共有機能
リポジトリシステム
統計情報閲覧
19 Copyright©2018 NTT corp. All Rights Reserved.
開発主管組織長による2回のプロジェクトレビュー後に提出された文書を施策主管が第三者的にリスクチェックを実施。
下表はリリース判定後のリスクチェック観点
19の観点。
1~5のリスク値を各項目に付与。
平均値をプロダクトのリスクレベルと定義する。(1はリスクが最も少ない)
リスクチェック表(抜粋)
チェック観点1 プロダクトの範囲 1.1 要件定義(基本設計)の明確性 機能要件
非機能要件
外部インタフェース要件
システム/ソフトウェア構成の要件
データ要件 2 開発プロセス 2.1 開発プロセス定義の妥当性 開発プロセスの定義
2.2 開発プロセス実施の妥当性 開発プロセスの遂行 3 品質の検証と分析 3.1 品質作り込みの妥当性 要件定義の品質確保
コーディングの品質確保3.2 試験準備の妥当性 試験環境 3.3 試験実施結果の妥当性 単体試験による検証
結合試験による検証
バグ修正や機能追加等による影響有無の検証(回帰試験) システム試験による検証
3.4 バグ抽出と修正の妥当性 抽出バグの解析と展開
抽出バグ数の妥当性 4 品質評価 4.1 品質評価の妥当性 目標品質の達成状況
プロダクトのリスクと制限事項 総合評価の結論
リスク値5:記載がない4:記載がある3:数値的記載がある2:見解がある1:見解から妥当性が読み取れる
20 Copyright©2018 NTT corp. All Rights Reserved.
③開発主管の自学自習を目的にした集合知共有、開発文書公開、E-LEARNING
インキュベーション型プロダクトのためのソフトウェアリスク回避施策
掲載は割愛する。
21 Copyright©2018 NTT corp. All Rights Reserved.
実施結果 2014/07/01-2018/06/30 (リリース1年後の状況は2014/07/01-2017/-6/30にて評価)
3章
23 Copyright©2018 NTT corp. All Rights Reserved.
ほぼ、品質クラスA>B>C>Dの順に各品質特性が考慮されている。
品質クラスに応じて品質が計画されている。
品質クラス毎の平均的な品質考慮状況
0
1
2
3
合目的性
正確性
相互運用性
セキュリティ
機能性標準適合性
成熟性
(試験の妥当性
)
成熟性
(障害収束性
)
障害許容性
回復性
信頼性標準適合性
理解性
習得性
運用性
魅力性
使用性標準適合性
時間効率性
資源効率性
効率性標準適合性
解析性
変更性
安定性
試験性
保守性標準適合性
適応性
設置性
共存性
置換性
移植性標準適合性
品質考慮値
ISO/IEC 9126 品質副特性
品質クラスA 品質クラスB
品質クラスC 品質クラスD
24 Copyright©2018 NTT corp. All Rights Reserved.
品質が考慮されているほどリスクも小さいという結果。品質クラスA>B>C>Dの順に品質が考慮されている品質クラスA>B>C>Dの順にリスクが低い品質クラスA,Bではおもむねリスク値2を下回り、リスクチェック観点について何らかの見解を持つにいたている。
品質レベルとリスクレベル
1
2
3
4
5
0 1 2 3
リスクレベル
品質レベル
品質クラスA
品質クラスB
品質クラスC
品質クラスD
品質が考慮されてる
高リスク
25 Copyright©2018 NTT corp. All Rights Reserved.
過去4年間のリスクレベルの平均値を比較すると、B、Cクラスで減少傾向、Aクラスもここ1年は減少傾向にある。
リスクレベルの経年変化
1
2
3
4
5
リスクレベル
期間
品質クラスA
品質クラスB
品質クラスC
品質クラスD
26 Copyright©2018 NTT corp. All Rights Reserved.
品質クラスBプロダクトに関する問題処理表が全体の85%を占める
リリース後1年間の問題処理票件数割合
B
85%
C
7%
D
1%
A
7%
27 Copyright©2018 NTT corp. All Rights Reserved.
リリース後1年間の1プロダクト当たりの問題処理票の内訳はBクラスが8.1件で一番多い。
品質クラスBにおいて、バグ以外に起因する不具合が全体の23%である。
これらは非機能に対する不具合と考えられ、リリース前に品質の合意がされていない部分と考えられる。(実際に、マニュアルの不具合などが多数を占める)
品質クラス別問題処理票の内訳
1.5 2.4
0.7 0.2
0.3 1.9
0.3 0.0
0.0
3.8
0.2
0.0
0.0
2.0
4.0
6.0
8.0
A B C D
件/プロダクト
品質クラス
バグに起因する不具合
バグ以外に起因する不具合
問い合わせ
28 Copyright©2018 NTT corp. All Rights Reserved.
②確実な運用2014/07/01-2018/06/30 (リリース1年後の状況は2014/07/01-2017/-6/30にて評価)
実施結果
29 Copyright©2018 NTT corp. All Rights Reserved.
月間でのエスカレーション対象件数最大値の推移。
システム導入時に70件あったエスカレーション対象が、導入から3ヶ月で10件を下回り、10件以下で推移。
遅延案件の減少
0
10
20
30
40
50
60
70
802
01
6/0
4
20
16
/05
20
16
/06
20
16
/07
20
16
/08
20
16
/09
20
16
/10
20
16
/11
20
16
/12
20
17
/01
20
17
/02
20
17
/03
文書未提出プロダクト数
時期 2016/3末にシステム導入
30 Copyright©2018 NTT corp. All Rights Reserved.
③自学自習2014/07/01-2018/06/30 (リリース1年後の状況は2014/07/01-2017/-6/30にて評価)
実施結果
31 Copyright©2018 NTT corp. All Rights Reserved.
開発文書をダウンロードする側とされる側の組織の順位が異なることから
他者の経験をうまく利用している様子がわかる。
被ダウンロードランキング: 組織I,E,M(サービス系研究所)
ダウンロードする組織ランキング:組織S,E,T(S,Tはネットワーク系研究所)
開発文書ダウンロード状況
0
100
200
300
400
500
600
700
A C D E F I M Q S T V
件数
組織
被DL数
DL数
32 Copyright©2018 NTT corp. All Rights Reserved.
2014年4月に施策が12研究所へ展開さえれて4年が経過する。
2018年9月現在、総計570以上のプロダクトがインキュベーション型開発標準を適用。適用率はほぼ100%で確実に運用されている。
リスクマネジメントの効果については、各開発プロジェクトが品質クラスに応じた品質の計画、(管理)、把握をしていることを確認。リリース後のバグによる不具合も少ない。一方で合意については課題あり。
自学自習については、他者の経験を利用している様子が文書DL状況から確認される。e-learningは評価中。
今後は施策の軽量化、いっそうの自律的な品質活動促進と、来るべきアジャイル時代への対応が課題。
結論と今後の課題