第三者検証活動からの開発プロジェクトマネジメントに...

2017年9月15日

富士通クオリティ・ラボ株式会社

アセスメント事業部

内藤拓[email protected]

第三者検証活動からの

開発プロジェクトマネジメントに

対する改善提案

Copyright 2017 FUJITSU QUALITY LABORATORY LIMITED

ソフトウェア品質シンポジウム2017

【セッション B4】マネジメント、プロセス改善 B4-2

ソフトウェア品質シンポジウム2017

mailto:[email protected]

自己紹介


開発製造

顧客先端技術

富士通

富士通クオリティ・ラボ株式会社

2006年に品質保証本部で培ったノウハウを引継ぎ分社化

電子部品、機器の信頼性評価など信頼性事業部

異物や腐食への材料分析など

アセスメント事業部開発プロセス、製造プロセスに対する改善支援

マテリアル事業部

開発プロジェクト審査を通じて開発プロセスの改善活動を実施

研究営業ＳＥ

開発 A1

開発 A2

開発 A3

部門品証

開発 B1

開発 B2

開発 B3

部門品証

製品：スパコン、サーバ、パソコン、携帯電話、フォトニクスネットワーク、無線基地局装置、ネットワークサービス機器、ミドルウェアソフト、プラットフォームソフト etc

本部A 本部B

開発 N1

開発 N2

開発 N3

部門品証

本部N

・････

品質保証本部

各本部を横断した品質保証

製品ごとの妥当性試験

1 ソフトウェア品質シンポジウム2017

開発プロセス/マネジメントに対する、タイムリーなレビュー、品質リスクの低減により、QCD目標未達を抑止する。

品質マネジメントシステム

開発プロジェクト審査概要

ISO9001

CMMI®

企画計画設計製造試験出荷

計画時審査実施時審査入試時審査 ▲ ▲ ▲

※開発プロジェクト審査での指摘の重み付け

品質リスク


グローバルなプロセス基準に富士通のノウハウを加えたプロセス基準を用いて、開発工程内のプロセスおよびマネジメントに対して審査を実施し、・お客様が期待するトップ品質の製品・高い収益を上げる製品を達成する開発を支援する

富士通ノウハウ

ウォーターフォール開発の例


開発プロジェクト審査の取り組み（1/2）

③審査実施 ②審査チェックシート準備

①開発計画書受領

⑤弱みに対する改善案の立案と実施

④強み・弱みの判定 ⑥フォローアップ実施

教育の実施


審査観点の見直し製品開発計画調査市場品質情報収集

審査フェーズ

審査指摘、強みを DBで公開

各開発本部の強み、弱み分析

改善活動フェーズ

審査を実施するだけでなく、開発プロセスについての教育実施や、指摘内容・強みのデータベース公開などによりプロセス改善を行う


開発プロジェクト審査の取り組み（2/2）

教育の実施


審査観点の見直し審査指摘、強みを DBで公開

改善活動フェーズ

審査を実施するだけでなく、開発プロセスについての教育実施や、指摘内容・強みのデータベース公開などによりプロセス改善を行う

横展開し確認すべきチェックポイント修正

他部門事例の横展開品質人材の育成


開発プロセスとは


プロジェクト管理エンジニアリング

支援プロセス

測定と分析プロセスモニタ構成管理課題分析と解決

成果物統合妥当性確認

技術解検証

要件開発

外注管理

進捗管理

開発計画策定

要件管理

統合管理リスク管理組織プロセス重視

組織教育

組織プロセス定義

プロセス管理

開発者プロマネやリーダー

開発計画に沿って管理

開発計画に沿って開発改善

開発計画書：個々のプロセス領域を関係者間で共有できるよう定義

１．開発背景５．開発体制～～～～～２．開発工程３．規模・体制６．構成管理～～～～～～～～～～～～４．リスク管理７．工程完了基準～～～～～～～～～～～～～～・・・・・・・・・・・・・・

山田

田中山本

○○会社

鈴木渡辺、伊藤

プロジェクト要件に合わせて開発計画を定義・遂行する活動 5 ソフトウェア品質シンポジウム2017

開発プロジェクト審査指摘の傾向（1/3）

開発プロジェクト審査ではプロジェクトの強み、弱みを下記の2種類で分類・分析し品質リスクを定量化する

検証（レビュー/テスト）

プロジェクト計画策定進捗管理

リスク管理構成管理

データ測定と分析

要件管理

プロジェクト管理外注管理

妥当性確認継続的プロセス改善

プロセスモニタ

プロマネやリーダー開発者

開発計画書 Wiki など

①定義されたプロセスに問題があるのかマネジメントに問題があるのか

②12分類のプロセス領域のどこに起因するか

12分類のプロセス領域

※改善ポイントの明確化のため CMMI®レベル3相当の内容を 12種類に変換している

プロセス

Copyright 2017 FUJITSU QUALITY LABORATORY LIMITED 6 ソフトウェア品質シンポジウム2017


品質リスク点およびプロセス不備は審査当初から比較すると減少傾向

マネジメント不備は年度ごとにバラツキが大きい


4.66

3.78 3.5

2.75 2.77

3.4

2.84

3.72

3.01

2.38 2.53 2.5

0

1

2

3

4

5

2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015

プロセス不備

マネジメント不備

品質リスクは横ばいとなってきた

年度

マネジメントについて改善を検討すべきである

品質リスク点

＊＊p<0.01

年間審査数：約100審査累積審査数：1415審査(～17年9月14日)



特に検証プロセスの品質リスクが過半数！！


0% 20% 40% 60% 80% 100%

2015年度

2014年度

検証進捗管理

構成管理リスク管理

マネジメント不備を起こしたプロセス領域を調査

検証プロセスにおけるマネジメント不備を改善しないといけない

『検証』の目的は生産物が指定された要件を満たすようにすること。具体的にはレビューやテストに対しての準備や遂行、是正処置の実施 ⇒品質目標に対して影響を及ぼすプロセス領域

プロジェクト計画策定


検証プロセスに対するマネジメントの指摘製品品質目標・プロジェクト特性品質目標値などの違いなどにより策定される

検証プロセスの内容は変わる

プロマネやリーダー開発者開発計画の伝達、開発の管理

工程

工程完了基準

インプット

アウトプット

品質基準

必須レビュア

完了承認者

・・・

FD (外部設計)

開発機能単位で下記を基に工程完了を判断する。・生産物を全て作成・コンポ単位でレビューを実施・レビュー指摘分類は別紙に従う・レビュー指摘事項の修正確認・品質基準値をもとに品質分析を行い、品質対策を実施

基本設計書

・機能設計書・システム鳥瞰図・異常分析シート・レビュー記録票・工程完了報告書

レビュー時間： 0.7h/枚バグ数 1.2件/枚

PM コンポPL 関連コンポPL

PM

・・・

開発計画書（工程完了の簡略例）

この状態で品質上問題ないか未確認のまま工程完了承認している

開発者もプロマネも開発計画に従った運用をできていない

検証プロセスでよくある指摘例（抜粋）・計画したアウトプットを未作成/未格納・レビュー指摘の分類が機能によってバラバラ・必須レビュアをレビューに未招集・品質基準値を計画と異なる値を使用


開発計画に従った運用

なぜ開発者もプロマネも開発計画に従った運用をできないのか？

プロマネがマネジメントする能力に欠けている

開発者とコミュニケーションを取れていない

開発者が開発計画書の必要性を感じていない

そもそもプロマネも開発計画書の必要性を感じていない

・前開発の流用

・開発計画書の審議の遅延


開発計画へのインプット（1/2）


部門QMS

○○規定

○○規定

開発計画書作成規定

・・

品質施策A 品質施策B

開発計画書

前開発、類似開発

障害分析

振り返り分析

プロジェクトリスク - 先行技術の検証 - 過去障害事例 - プロジェクト特性・新規OSSの利用・新規協力会社 etc

開発計画書へのインプット

製品品質目標値の未達 ⇒○○工程の工程内目標値の未達 ⇒品質施策A：必須レビュアとして関連コンポのリーダを召集する ⇒品質施策B：ゾーン分析を行い工程内の品質分析を強化する


発見すべき工程混入工程

ST IT CT MK SD FD BD

検出工程

BD FD SD MK CT IT ST



開発計画へのインプット（2/2）

計画設計/実装/検証出荷判定

運用

振り返り分析障害分析

つくり込み要因

流出要因

前回の開発・類似の開発

今回の開発製品品質目標・プロジェクト特性を考慮して内容反映

開発計画が前回の開発の分析内容を基に立案されているかを調査

計画設計/実装/検証

開発計画書

品質施策


調査

調査時期：2016年6月～2017年6月

調査製品数：79製品

調査方法：以下を確認する・振り返り分析を実施し、その内容を次開発に反映しているか・障害分析を実施し、その内容を次開発に反映しているか


発見すべき工程混入工程

ST IT CT MK SD FD BD

検出工程




流出要因

障害分析振り返り分析


結果


分析未実施、引き継げない運用のプロジェクトが7製品(8.9%) 分析内容を活用できていないプロジェクトが13製品(16.5%)

活用できている,

56

分析未実施, 3

記録不十分, 4

運用不十分, 13

その他, 2

調査数 n=79

分類指摘例（概略）

分析未実施

前開発で振り返り会のプロセスを未定義かつ、未開催

記録不十分

振り返り会の結果をメールで周知しており、内容が伝わっていない

分類指摘例（概略）

運用不十分

例①：再発防止策を単なる処置と是正処置に分析したが、是正処置への対応計画を立てておらず未実施例②：品質施策として開発レビュー、妥当性検証部門レビューの両面の改善策を立てたが、妥当性検証部門のレビューを未実施

開発計画の妥当性を十分に精査されていない

開発計画を策定する上で、インプットすべき内容が整備されていない


M-SHELモデルより


L

H

E

L

S

M

開発計画書プロマネ

開発者

改善への意識・風土

ツール組織支援

L-S,L-L,L-M インターフェイスを適合させていく 15 ソフトウェア品質シンポジウム2017

まとめ

開発計画を立てるためのインプットとして、「活用できる統計手法を基にした振り返り分析方法」や、「根本原因の分析方法」を提言するとともに、妥当な開発計画の必要性を意識付け

振り返り分析/障害の分析した結果を元にプロジェクトの要件に適合した開発計画の妥当性を検証


製品品質目標値発見すべき工程混入工程

ST IT CT MK SD FD BD 検出




流出要因

品質施策

工程内目標品質施策A 品質施策B

インプットレビュー


今後の課題


部門QMS

○○規定

○○規定

開発計画書作成規定

・・

品質施策A 品質施策B

開発計画書

前開発、類似開発

障害分析

振り返り分析

プロジェクトリスク - 先行技術の検証 - 過去障害事例 - プロジェクト特性・新規OSSの利用・新規協力会社 etc

製品品質目標値の未達 ⇒○○工程の工程内目標値の未達 ⇒品質施策A：レビューメンバの強化 ⇒品質施策B：セキュリティテスト強化

もうひとつのインプットであるリスク抽出の妥当性を検証していく


第三者検証活動からの 開発プロジェクトマネジメントに...

Documents

第三者検証活動からの開発プロジェクトマネジメントに...