インキュベーション型プロダクトに対応したソフト...

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の６つの品質特性で説明できるものをさす。狭義の品質である信頼性/バグだけではない。

本発表で述べる「プロダクト」はソフトウェアプロダクトをさす。

まえおき


1. 背景（コンテキスト）と課題

～NTTのR&Dとプロダクトアウト体制～

2. リスクマネジメント施策（制度設計）

3. 効果と考察

4. 今後の課題

アジェンダ


背景と課題

１章


●NTTはオーバヘッド組織と３総合研究所12研究所からなる。

●NTT研究所は５事業会社に対し研究所成果（＝プロダクト）を提供

研究所プロダクト開発はNTT-G内外のベンダへ発注することが多い。

5事業会社は研究所プロダクトをさまざまな方法で利用する。

プロダクトアウトには社内的に技術や費用の観点でのオーソライズが必要

背景（１）：プロダクトアウト体制

３総合研究所12研究所 (約2500名の研究員）プロダクト開発時は発注側になる

受託開発

プロダクト提供

NTT-Ｇ内外のベンダ企業

事業会社

受託会社


NTTのＲ＆Ｄのフェーズをモデル化すると、①創出フェーズ、②発表フェーズ、③プロダクト化フェーズ、④提供・維持管理フェーズの４つから成る。

研究所の営みの大半は創出フェーズ。

本発表は③プロダクト化フェーズおよび④提供・維持管理フェーズについてである。

背景（２）：NTT R&Dの営み

創出フェーズ発表フェーズ

プロダクト化フェーズ提供・維持管理フェーズ

開発プロダクト

アイディアを可視化し、具現化していく段階

プロダクトアウトを目的とした開発をする段階

プロダクト化判断

リリース判定

特許や学会でアイディアを発表する段階

プロダクトアウトする段階


事業とのエンゲージメントの強いネットワーク開発は少数となり、事業とのエンゲージメントが強くないインキュベーション型のプロダクトが多くなってきている（＝ネットワークシステムが激減している）。

開発者がほぼ全研究所、提供先が全事業会社にわたる。

インキュベーション型プロダクトとは、シーズ指向、次のサービスの核になり得るプロダクト（できたて。使ってみないとわからない側面も）。品質も多様。

背景（３）：プロダクト開発の特徴

いにしえ（分社前等）現在

主力のプロダクトの種類

ネットワークシステムサービス、アプリケーション、処理エンジン、ファームウェア、ミドルウェアなどインキュベーション型プロダクトを含む（多種多様）

開発期間９ヶ月～1.5年 3ヶ月～6ヶ月

開発部署特定の研究所案件数に差はあるがほぼ全研究所

提供先現：NTT東・西 5事業会社全般

事業とのエンゲージメント

強い弱い

求められる品質厳しい商用品質多様な品質

従来の一般的な開発新たな形態・課題


インキュベーション型プロダクト開発の課題

リリースのための品質基準を一律に定義できない

全研究員（約2500人）が開発者になりえる

（品質保証部門（品質ゲート）等の組織を持たない）

実際にあったトラブル

ベンダ企業に結果的に予定外の作業をさせてしまう、想定する作業がなされないなど、作業（＝品質）に過不足が生じる。

事業会社が開発主管（＝研究所）が想定をしていない使い方をしてトラブルになる

課題に対するアプローチ

開発の安定化と事業とのトラブル未然防止（目的）のためのリスクマネジメント施策→組織で品質責任を持つことの徹底

施策の確実な運用（研究者全員が確実に適用する）

インキュベーション型プロダクト開発の課題


インキュベーション型プロダクトのためのソフトウェアリスク回避施策

２章


インキュベーション型開発の特性を鑑み、安定した開発および事業とのトラブル防止を目的とし、研究員が自律的な品質活動（品質を計画、管理、把握、事業と合意）し、組織で品質責任を持つことを確実に実施するため制度設計。インキュベーション型ソフトウェア開発標準を策定し施策の基盤とし、プロダクトアウトする案件は全件適用するようにルールを設定

確実な運用のために全件第三者によるリスクチェックを実施

将来的な施策の簡易化も目論み、自学自習のための統計データ閲覧、開発文書閲覧、e-learning受講を実現

リスクマネジメント施策

インキュベーション型ソフトウェア開発標準

開発主管（研究開発組織）

受託会社事業会社

(3)品質を把握

(4)品質を合意

(2)品質を管理

(1)品質を計画

統計データ閲覧開発文書閲覧第三者によるリスクチェック受診 e-learning受講

②確実な運用

①施策の基盤とルール化

③自学自習

自律的な品質活動


① 施策の基盤とルール化・インキュベーション型開発標準・ルール化



「リリースのための品質を一律に定義できない」ため、研究者が自プロダクトの品質を定義するのを助けるための開発標準を策定。

SLCP2007をベース。35のプロセスを必須実施事項化。

品質クラスの定義：自プロダクトの使われ方によるクラス化。

品質確認表の提供：ISO/IEC 9126に基づく105の品質観点

インキュベーション型開発標準

開発計画書算サンプル

リリース判定書サンプル品質確認表

要求仕様書サンプル

文書サンプル

開発プロセスの規定「品質クラス」

の定義本文

インキュベーション型開発標準

一般的な開発標準

SLCP2007に基づき35のプロセスを必須実施事項として規定

ISO/IEC 9126の6品質特性/27副特性を基本とし、品質の作りこみ、検証において具体的に考慮すべき105の観点をリスト化

自プロダクトがどのような使われ方をするのかをクラス化


品質クラス

品質クラス

サービス導入の可能性からみた定義利用例

A 事業会社がほぼそのままサービス導入でき，インフラやネットワークサービスのようにシステムを止めてはいけないような極めて厳しいSLA(Service Level Agreement)下で使用されることを想定したプロダクト

インフラ，ネットワークサービス

B 事業会社がほぼそのままサービス導入できるが，パッケージやソリューションのようにアプリケーションソフトウェアの再起動がある程度許容される状況下で使用されることを想定したプロダクト

パッケージ，ソリューション

C 実証実験のように使い方が一部限定され，事業会社がサービス導入するには機能・非機能要件やアーキテクチャの一部の見直しと一部の追加試験などを要するプロダクト

実証実験

D 機能のデモンストレーションのように使い方が極めて限定され，事業会社がサービス事業導入するには，機能・非機能要件およびアーキテクチャ，試験などについて抜本的な見直しを要するプロダクト

デモンストレーション

E 品質見解が無いプロダクト研究所利用

使われ方による５段階の定義

品質クラスＡ，Ｂ：そのまま事業に使われる

品質クラスＣ，Ｄ：そのままでは事業に使われない

品質クラスＥ：品質見解がない


品質確認表（抜粋）品質特性

品質副特性確認項目

信頼性成熟性(試験の妥当性)

①試験項目数②ホワイトボックス試験(カバレッジ)③ブラックボックス試験④非機能試験/システム試験

成熟性(障害収束性)

①収束性②障害摘出③制限事項

障害許容性 ①エラーチェック②エラー時の継続運用③重要入力の確認④ファイル破壊防止

回復性 ①UNDO/REDOの実施②チェックポイントの構築③ソフトウェア閉塞④障害解析用の記録

使用性理解性 ①チュートリアル②デモ③操作メニュー④マニュアル(障害時)

習得性 ①マニュアル(通常操作時)②ユーザレベル③ヘルプ機能

運用性 ①デフォルト設定②ガイダンス指示③操作の確認④障害の通報⑤運用状況の記録

魅力性 ①魅力的なユーザインタフェース②魅力的な機能③魅力的な非機能

効率性時間効率性 ①応答時間②スループット③ターンアラウンド④過負荷状態での効率性⑤縮退運転時の効率性

資源効率性 ①メモリ②CPU③HDD④縮退運転時の効率性

品質特性

品質副特性確認項目

保守性解析性 ①マニュアル(保守・解析)②進行状況の確認③障害時の処理履歴④解析情報のダンプ

変更性 ①変更対応容易性②変更内容確認容易性③プログラムやデータの独立性

安定性 ①変更に対する自身への影響②変更に対する他への影響③変更のキャンセル

試験性 ①確認試験要領②退避性③確認性④自己診断機能⑤テスト・シミュレーション機能

移植性適応性 ①検証実績②多言語対応③OSSなどの導入

設置性 ①マニュアル(導入)②インストール機能③留意事項の明確化

共存性 ①共存できないソフトウェア②共存条件③共存するための変更④データへの排他アクセス⑤データ運用の矛盾なき統合

置換性 ①データ移行②移行前共存ソフトウェアへの非影響

③移行前ソフトへの互換性④移行前共存ソフトウェアへのユーザインタフェース維持⑤移行前システムへの復旧

品質服特性毎に３～５の確認項目を定義

合計１０５の確認項目

確認項目毎にどの程度考慮するかを０～３で評価平均値をプロダクトの“品質レベル”と定義

１０５項目がすべてが３の評価であれば品質レベルは“３”となる

品質クラス毎に推奨基準を設けているが決して必須基準ではない。

（＞自分で考えることの徹底）


品質確認表の具体的な使い方（どうやって自分で考えるか）

要求やシーズ、利用条件から品質クラスを決定。クラスＡであれば、「そのまま事業でのサービスに使われ、厳しいSLA下で動作することを求められる」ことを認識

その認識の下、品質確認表から品質確認項目を選定し対応の度合を決める

品質確認項目の対応度合を具体的に要件と作業に落とし込む。

品質を決めるということはプロジェクトスコープを決めることに他ならない。

品質項目から具体的要件・作業へのブレークダウン

品質確認表による品質確認項目の選定

品質クラスの決定

要求、シーズ、利用条件

要件 (要求仕様書/基本

設計書)

WBS

作業 (開発計画書）


以下の２つを運用ルール化し、開発主管組織が品質に責任をもつことを意識付け。（かつ、２回のプロジェクトレビュー後に資料を施策主管に提出、第三者チェックを受ける）

ルール化

ルール番号運用ルール

1 プロダクトアウトされるソフトウェアは各案件にてあらかじめ計画したA～Dクラスの品質を確保すること

2 適用対象案件について、二つのプロジェクトレビュー(プロダクト化判断、リリース判定)時に、開発主管組織長が品質クラスに応じた品質とリスクの確認を行うこと

外部仕様検討開発 (開発標準適用) 維持管理

プロダクト化判断

リリース判定

開発主管組織長

品質クラスに応じた品質の計画と把握を組織的に行う。

開発主管組織長


②確実な運用・システムの利用・第三者チェック



案件管理機能による運用の確実化と運用工数の劇的削減

オーソライズ会議主管から案件情報を入手し、登録する

会議付議日を起点に文書の提出遅延者にアラートメールを送付

アラートが限度を超えたらエスカレーションを開発主幹組織に対して発出

アラートメールは資料提出のタイミングで都度発出される

案件管理機能によって1500人時/年の運用稼働を削減

システムによる運用

案件情報/文書/帳票投入

資料送付契機（アラート）、帳票エラー通知等

施策主管

施策主管/開発主管（研究者）

開発主管 DB

他プロジェクトの文書検索・閲覧

データ分析機能（BIツール）

案件管理機能

文書共有機能

リポジトリシステム

統計情報閲覧


開発主管組織長による２回のプロジェクトレビュー後に提出された文書を施策主管が第三者的にリスクチェックを実施。

下表はリリース判定後のリスクチェック観点

１９の観点。

１～５のリスク値を各項目に付与。

平均値をプロダクトのリスクレベルと定義する。（１はリスクが最も少ない）

リスクチェック表（抜粋）

チェック観点1 プロダクトの範囲 1.1 要件定義(基本設計）の明確性機能要件

非機能要件

外部インタフェース要件

システム/ソフトウェア構成の要件

データ要件 2 開発プロセス 2.1 開発プロセス定義の妥当性開発プロセスの定義

2.2 開発プロセス実施の妥当性開発プロセスの遂行 3 品質の検証と分析 3.1 品質作り込みの妥当性要件定義の品質確保

コーディングの品質確保3.2 試験準備の妥当性試験環境 3.3 試験実施結果の妥当性単体試験による検証

結合試験による検証

バグ修正や機能追加等による影響有無の検証（回帰試験）システム試験による検証

3.4 バグ抽出と修正の妥当性抽出バグの解析と展開

抽出バグ数の妥当性 4 品質評価 4.1 品質評価の妥当性目標品質の達成状況

プロダクトのリスクと制限事項総合評価の結論

リスク値５：記載がない４：記載がある３：数値的記載がある２：見解がある１：見解から妥当性が読み取れる


③開発主管の自学自習を目的にした集合知共有、開発文書公開、E-LEARNING


掲載は割愛する。


実施結果 2014/07/01-2018/06/30 (リリース１年後の状況は2014/07/01-2017/-6/30にて評価)

3章


①リスクマネジメントの達成状況品質の計画、管理、把握、合意

実施結果


ほぼ、品質クラスＡ＞Ｂ＞Ｃ＞Ｄの順に各品質特性が考慮されている。

品質クラスに応じて品質が計画されている。

品質クラス毎の平均的な品質考慮状況

0

1

2

3

合目的性

正確性

相互運用性

セキュリティ

機能性標準適合性

成熟性

(試験の妥当性

)

成熟性

(障害収束性

)

障害許容性

回復性

信頼性標準適合性

理解性

習得性

運用性

魅力性

使用性標準適合性

時間効率性

資源効率性

効率性標準適合性

解析性

変更性

安定性

試験性

保守性標準適合性

適応性

設置性

共存性

置換性

移植性標準適合性

品質考慮値

ISO/IEC 9126 品質副特性

品質クラスA 品質クラスB

品質クラスC 品質クラスD


品質が考慮されているほどリスクも小さいという結果。品質クラスＡ＞Ｂ＞Ｃ＞Ｄの順に品質が考慮されている品質クラスＡ＞Ｂ＞Ｃ＞Ｄの順にリスクが低い品質クラスＡ，Ｂではおもむねリスク値２を下回り、リスクチェック観点について何らかの見解を持つにいたている。

品質レベルとリスクレベル

1

2

3

4

5

0 1 2 3

リスクレベル

品質レベル

品質クラスA

品質クラスB

品質クラスC

品質クラスD

品質が考慮されてる

高リスク


過去４年間のリスクレベルの平均値を比較すると、Ｂ、Ｃクラスで減少傾向、Ａクラスもここ１年は減少傾向にある。

リスクレベルの経年変化

1

2

3

4

5

リスクレベル

期間

品質クラスA

品質クラスB

品質クラスC

品質クラスD


品質クラスＢプロダクトに関する問題処理表が全体の８５％を占める

リリース後１年間の問題処理票件数割合

B

85%

C

7%

D

1%

A

7%


リリース後１年間の１プロダクト当たりの問題処理票の内訳はＢクラスが8.1件で一番多い。

品質クラスＢにおいて、バグ以外に起因する不具合が全体の２３％である。

これらは非機能に対する不具合と考えられ、リリース前に品質の合意がされていない部分と考えられる。（実際に、マニュアルの不具合などが多数を占める）

品質クラス別問題処理票の内訳

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

件/プロダクト

品質クラス

バグに起因する不具合

バグ以外に起因する不具合

問い合わせ


②確実な運用2014/07/01-2018/06/30 (リリース１年後の状況は2014/07/01-2017/-6/30にて評価)

実施結果


月間でのエスカレーション対象件数最大値の推移。

システム導入時に７０件あったエスカレーション対象が、導入から３ヶ月で１０件を下回り、１０件以下で推移。

遅延案件の減少

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末にシステム導入


③自学自習2014/07/01-2018/06/30 (リリース１年後の状況は2014/07/01-2017/-6/30にて評価)

実施結果


開発文書をダウンロードする側とされる側の組織の順位が異なることから

他者の経験をうまく利用している様子がわかる。

被ダウンロードランキング：組織Ｉ，Ｅ，Ｍ（サービス系研究所）

ダウンロードする組織ランキング：組織Ｓ，Ｅ,Ｔ（Ｓ，Ｔはネットワーク系研究所）

開発文書ダウンロード状況

0

100

200

300

400

500

600

700

A C D E F I M Q S T V

件数

組織

被DL数

DL数


2014年４月に施策が１２研究所へ展開さえれて４年が経過する。

２０１８年９月現在、総計５７０以上のプロダクトがインキュベーション型開発標準を適用。適用率はほぼ100%で確実に運用されている。

リスクマネジメントの効果については、各開発プロジェクトが品質クラスに応じた品質の計画、（管理）、把握をしていることを確認。リリース後のバグによる不具合も少ない。一方で合意については課題あり。

自学自習については、他者の経験を利用している様子が文書ＤＬ状況から確認される。e-learningは評価中。

今後は施策の軽量化、いっそうの自律的な品質活動促進と、来るべきアジャイル時代への対応が課題。

結論と今後の課題

インキュベーション型プロダクトに対応した ソフト...

Documents

インキュベーション型プロダクトに対応したソフト...