【PM試験対策9】品質マネジメントその2 - 部屋の隅っこで書く技術ブログ

f:id:expajp:20180321224324p:plain

一昨日に続けて頑張ります。

というか、昨日もやってたので3日続けてです。

1ヶ月もあいだが空いてしまうともう死に物狂いでやんなきゃですね。

「Twitter減らせばもっと仕事できるんじゃないですか」みたいなことを言う人に、「Twitterは海女さんの息継ぎと同じで、息継ぎ減らしたらただ海底で死ぬだけですし真珠が増えるわけじゃないです」という説明が通じるようになったので、いい時代になったなあと思う
— 病理医ヤンデル (@Dr_yandel) 2018年3月19日

ところで、なんかこんなツイートがバズってましたね。

しかし、こういう状態で生産性を出せるのは一握りのとても優秀な人だけなので、勘違いしてはいけません。

昨日、仕事中に情報収集と称してやってたTwitterを自重してみたら（全くしなかったとは言ってない）めっちゃ生産性がでたので、へっぽこエンジニアは明後日からも真面目に働きます。

今日は品質マネジメントの続きです。

品質コントロール
問題演習から

品質コントロール

監視・コントロールプロセス群
インプット
- プロジェクトマネジメント計画書
- 品質尺度
  - ここまでは計画でやった
- 成果物
ツールと技法
- QC七つ道具
- 統計的サンプリング
- 検査
アウトプット
- 品質コントロール測定結果
- 妥当性確認済み変更
- 検証済み成果物
「ツールと技法」の検査とは、作業結果が仕様書に適合するか調べるテストのこと
- 全体の検査とは言ってない
- つまり、いつでも行うことができる
- レビュー、テストは品質マネジメント計画プロセスで計画される
  - そして品質コントロールプロセスにおいて実行される

レビュー

デザインレビューとも呼ばれる
- あらゆる成果物の品質状況を検査する
- WFでは各フェーズの終了時に当該フェーズの成果物をレビューすることが必要
レビュー手法として出題されるのは以下
- ウォークスルー
- インスペクション
- ラウンドロビン

ウォークスルー

ストラクチャードウォークスルーという
- ストラクチャーの時点で「ストラクチャーデッキ」が予測変換に出てくるぞデュエリストは表に出ろ
レビューを構造化することで効果を高める
開発者によって自主的に開催され、欠点の摘出のみに焦点を絞る
- バグフィックスの方法は検討外
レビューミーティングの準備
- 成果物を配布し、把握しておいてからレビューミーティングに出席する
- 古いな……Githubでええやないかい
- 人事評価に反映させないために管理者は出席させないのが原則だそうだが、小規模組織かつ管理者に信頼がおけるなら別でしょう
レビューミーティングの実施
- 作成者が成果物の内容をプレゼン
- ユースケースに従って動きを説明することで、不具合を抽出
- 「手によるシミュレーション」
- 集中力が低下しないよう、長時間レビューを避ける
- 欠陥の摘出のみを行う
レビューミーティング後
- 当然というか、成果物の修正
- 漏れはミーティング出席者全員の責任
- レビューが成果物欠陥の責任追及の手段になるのを避けるための措置
  - 100％を目指すようになって生産性悪化しちゃうね

インスペクション

ウォークスルーは開発者による自主活動を想定しているので、実施されないことが多い
- そこで、管理を強化したのがインスペクション
- こうならないのが良いよなあ
- ウォークスルーはとても非効率だけどね。。。
以下の説明以外はウォークスルー同様
モデレータの選任
- レビューミーティングの企画者を選出しておく
- 開催者でファシリテータ、人事評価には絡まない
発見したエラーの訂正状況把握と督促
- モデレータが実装者に不具合訂正を確認する
レビュー結果データの収拾分析とフィードバック
- レビューミーティングの結果データを収集し分析する
- 欠陥の多い機能、作成者、箇所を特定してフィードバック

ラウンドロビン

単なるレビュアーの回し方
サイコロなんて話もありましたね
とてもモチベーションの低い開発者を想定してるなあ……

テストフェーズ

システム開発プロジェクトで実施されるテストは以下の４つ
- 単体テスト
- 結合テスト
- システムテスト
- 運用テスト
WFにおける対応関係は
- 要件定義と運用テスト
- 外部設計・内部設計とシステムテスト
- プログラム構造設計と結合テスト
- プログラミングと単体テスト
単体テスト
- 説明不要
結合テスト
- こちらも説明不要
- どの順番で結合していくかの違いはある
システムテスト
- 名前から実態がわかりにくいが、要は全結合で行うシナリオテスト
- 外部連携や例外処理、性能テストもここに含む
運用テスト
- システムテストと同じことを実際のシステム担当者が行う
- 運用面での課題洗い出しはここ

テスト技法

ホワイトボックステスト
- 網羅の対象がコードカバレッジ、条件分岐、条件網羅、複数条件網羅など
ブラックボックステスト
- 同値分割
- 限界値分析
- 原因結果グラフ
  - これはテストケースの設定を容易にするための補助
  - つまり、テスト技法ではなくテストケース作成技法
レグレッションテスト
- 仕様変更した機能以外が変更されていないことをテストする
- 自動テスト書いとけばなんとかなるよ

レビューおよびテストの計画、実行、監視、コントロール

レビューとテストは同様の計画→実行→監視手順を踏むので、同時に解説する
- 本に書いてある「（テスト）」は全略

レビュー計画

品質管理指標
- 品質尺度とほぼ同じ意味
- 例えばこんな
  - レビュー項目数
  - バグ数/ステップ数
  - 共通ルーチンのステップ数/全ステップ数
  - 仕様変更数
- クソのような尺度が並んでいる……
- 試験で出たのはレビュー時間、摘出欠陥数
- 午後Iでは誤字脱字などをカウントしない旨の解答が求められる
  - そんなの当たり前でしょうよ。。。
- 摘出欠陥数とか決めるとバグ隠しが進むから品質落ちるんだよなあ。。。
  - マネージャの側で持っといて、仕事を減らす目的だけで運用するなどが必要では
スケジュールなどを含むレビュー計画立案
- 品質マネジメント計画の一部
- フェーズごとにレビュー計画をまとめる
  - 期間、実施者、項目、
  - テストデータとその作成方法、正常系の出力、異常系の例
  - 検出予定数、レビュー技法、レビュー対象のステップ数など

レビューの実行

品質実績データの記録
- 計画書に従って報告書を作成する
- 報告書のひとつに「摘出欠陥記録表」があり、是正状況把握のために使われる

レビューの監視・コントロール

差異分析と品質評価
- 所定の日に品質評価を行う
- 評価項目ごとの指標値と実績値を記した比較表を作成する
- 閾値を超えた場合は是正措置を実行
レビュー工程品質管理図
- 信頼性成長曲線は途中で2階微分の正負が変わるS字型
  - つまり、最初はほとんど成長せず、途中から爆発的に成長する
  - 成長段階の途中でまた緩やかになる
  - どういうことかというと、レビューやテストはある程度ちゃんとやらないと効果はないが、やりすぎもまた無意味
- ロジスティク曲線とかゴンベルツ曲線とかいう
- この曲線、なにに使うかというとここまでの摘出状況を見てレビューやテストを継続するかどうかの判断に使う
- 未解決欠陥数は書くことも書かないこともある
レビュー工程品質管理図の例
- ケーススタディ、要は適切な判断を取れということ
- あまり書くことはない