部屋の隅っこで書く技術ブログ

中の人は20代後半Web系エンジニアです。テーマは闇鍋ですが、マネジメント、Ruby/Rails、ブロックチェーンの話題が多めです。

【PM試験対策9】品質マネジメント その2

f:id:expajp:20180321224324p:plain

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

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

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

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

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

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

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

品質コントロール

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

レビュー

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

ウォークスルー

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

インスペクション

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

ラウンドロビン

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

テストフェーズ

テスト技法

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

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

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

レビュー計画

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

レビューの実行

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

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

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

問題演習から

  • 応答時間などは「効率性」
    • 「性能」って言葉を使いたくなるよね
  • JIS X 0129-1は出題例が多い模様
    • 他に分かりづらいのは「信頼性」かな
    • 安定した性能を発揮する能力のこと
  • スコープ・ベースラインはスコープ記述書、WBSWBS辞書
    • インプットとして非常に多く用いられる
  • レグレッションテストは「退行テスト」ともいう
    • デグレがないか調べるテスト
    • 不正解っぽい選択肢なので注意
  • デザインレビューのデザインは「設計」
    • 設計フェーズの成果物を調べる
  • 「流れ図」は「フローチャート」のこと

覚えることが多いですが、QC7つ道具の使い方とJIS X 0129-1を頭に叩き込めばあとは応用ですね。

この試験、「考え方が身についているか」を問うものですね。

考え方がまともなら、知識がなくても正解できる問題が多くなっているような気がします。

流石にレビューとかテストの手法は古くさすぎてイライラしましたけど。

次は一番短い「人的資源マネジメント」です。

ブラックなことが書かれていませんように。