◆攻めの品質、守りの品質◆

平成27年7月25日 in NDS

@2G_KSK

4月のNDSの発表より…

やってみました！＠自社

受講者アンケートより

歯ごたえなし記名式アンケートが

悪かった？

受講者アンケートより

[品質]についてのコメントがなかった→[作業内容]や[納期]に比べ、理解が難し

かったと思われる

「品質」をもう一度考えてみる

PMBOK的品質は…【特性（機能）の集まりにより、要求事項を満たす度合、要求事項への適合、使用適合性】

ユーザの要望を満たす＝品質が良いということらしい

「品質の良い服」とは？

手触りがよい

洗っても傷みにくい

サイズがぴったり

→やわらかくて肌触りのよい服を望んでいる

→ひと夏着れることを望んでいる

→表示通りのサイズであることを望んでいる

品質は、要求や使用目的がスタートである

ユーザの要求の内容によって、「品質」が決まる

伸縮性はないけど、ロゴや背番号の加工がしっかりしているので、

満足。

システム開発における品質

真っ先に浮かぶのが「バグ」

バグがいっぱい出ると、「品質が悪い」と判断される

バグにより、本来満たされるべきであった機能（要求）が阻害されるため、「品質が悪い」となる

品質対策…

目標と比べて、バグの数が多いか少ないかをチェックする

バグの数が目標より多い場合、品質が悪いと判断し、再点検を行う

ぴったりくらいだと、十分な品質が確保されているといえる

△

なぜ噛みついたのか？

上述の対策は、出来上がったものに対する対策である→リアクティブな対策

プロアクティブな対策→【攻めの品質】を紹介したい

なぜ、プロアクティブな対策が必要か？

品質は、ものづくりのときに決まってしまうから

あとのフェーズは、品質を保証するというスタンス

意図的に、品質を操作することができるのはものづくりのフェーズだけ

どこで不具合を作っている？

自動車の組み立てを考える車両の設計

→部品の設計→部品の作成→車両の組み立て→組み立てチェック→動作テスト→走行テスト→納品

設計・製造（ものづくりのフェーズ）

その後の確認・テストでは不具合は作りこんでいない

※新入社員向け研修より、抜粋

システム開発でも…

基本設計

概要設計

詳細設計

製造

単体テスト

結合テスト

総合テスト

設計・製造フェーズ テストフェーズ

不具合を作るのは、ものづくりのフェーズ

不具合を摘出し、品質に問題ないことを保証するフェーズ

※新入社員向け研修より、抜粋

攻めの品質：まずは弱点を知る

ものづくり時に不具合を作りそうな箇所を考える

チーム開発の弱点→つなぎ目

多くの人が携わるため、ほころびが生じやすい

具体的には：フェーズ間、設計書間、機能間、…

チーム開発の弱点(1)フェーズ間の情報欠落

基本設計で検討していた仕様が、詳細設計で担当者が変わったため、それが盛り込まれなかった

基本 詳細

弱点の対策(1)フェーズ間の情報欠落

基本設計で検討していた仕様が、詳細設計で担当者が変わったため、それが盛り込まれなかった

調査した結果など、有用な資料があるのであれば、それを次工程のインプットにする！

テキストファイルでも、手書きのメモでも何でもよいので、残す・受け渡すことを意識する！

チーム開発の弱点(2)設計書間の記述差異

一緒に直さないといけない設計書が、片方しか直っていない

DB10桁

FILE8桁

直した！ 直し忘れている…

弱点の対策(2)設計書間の記述差異

一緒に直さないといけない設計書が、片方しか直っていない

お決まりのパターンを洗い出し、チェックリスト化する！

チェックの仕組みを構築する！

ものづくり時に間違えないよう、事前教育する！

弱点の対策(2)設計書間の記述差異

例えば…

帳票に項目追加したら、ファイルにも必ず項目が追加されていること→必ず両方直っていること

DBの項目長より、intで受けるかlongで受けるかを決定する→安易にintとしない、必ずチェックする

チーム開発の弱点(3)機能間の不整合

仕様変更が設計者間で伝わっておらず、不整合が発生

処理１ 処理２ファイル

項目（A、B、C） 項目（A、B、C）項目（A、D、C）

処理２

項目（A、B、C）

出力内容を変更 項目を誤って読み込み、処理が不正になる

弱点の対策(3)機能間の不整合

仕様変更が設計者間で伝わっておらず、不整合が発生

だまって仕様変更しない！リーダは変更内容を把握し、必要な担当者に伝える！

こういった問題が起こらないよう、担当者間のコミュニケーションを推進する！

攻めの品質とは？

以上の対策は、ものづくり前：計画段階に実施できる事前教育・コミュニケーション

これらをメンバ全員が理解し、不具合を作りこまないようにする

計画段階で、品質を上げる策を打つことを、【攻めの品質】と呼ぶこととしました

（参考）PMBOKガイドの言葉

品質は、検査ではなく計画（設計）によって達成すべきである

欠陥ゼロを目指す

検査よりも予防（コストの方が安い）

検査の強化が品質改善の最善策とは見なされない

⇔守りの品質

不運にも、出来上がったものの品質が悪かった場合に、どう対応するか

さらにテストを追加する、CDIを実施する、…

→手当たり次第では、キリがないばかりか、効果がない可能性も

→いかに効率よく、バグを除去するかが重要

ウィークポイントを探せ！

効率を上げるためのヒント→開発時に摘出したバグが手掛かりになる

摘出したバグは、これまでの開発のクセであり、同じようなバグが潜んでいる可能性が高い

摘出したバグの分析方法：複数の軸で分析する

原因別：あいまいな記述、初期化漏れ、実装漏れ、…

混入工程別：要件定義フェーズ、基本設計フェーズ、製造フェーズ、…

作成者別：はじめて開発に入る○○さんが多く出している

機能別：規模が大きいもの、他システム連携部分

摘出したバグの分析方法：パレート図にしてみる

0

0.2

0.4

0.6

0.8

1

0

5

10

15

20

25

記述曖昧 仕様誤り 実装誤り 規約違反 IF不整合 初期化漏れ

バグの主な原因：設計書の記載内容が悪いようである

分析結果を元に、対策を打つ

各分析軸における上位の原因は、誤りやすいものと言える→まだ同原因のバグが潜んでいる可能性がある

上位の原因から、順に対策する→設計書に曖昧な部分はないか？仕様（ロジック）誤りはないか？

分析結果を元に、対策を打つ

さらに…原因×機能で、深堀りしてみる→規模の大きい機能×曖昧な記述→この機能の中で、曖昧な部分はないか？

かけられるコストと相談しながら、方針を絞って対策する

守りの品質→攻めの品質

ここで摘出した弱点を、次の開発に活かす

誤りやすいところ→チェックシート、事前教育へ

まとめ

攻めの品質

品質はものづくり時に決まる

ものづくり前に、計画により品質を向上させる

守りの品質

弱点をあぶり出し、そこを中心に再チェックを行う

終わりに…

バグ数による品質判断は、これまでの開発経験からの推測でしかない。目標値通りだから大丈夫、とは必ずしも言えない

こう計画して作ったから、こう確認したから大丈夫、というふうに、品質を説明できるようにしていくべき

◆攻めの品質、守りの品質◆

～終わり～

平成27年7月25日 in NDS

@2G_KSK