「改善」ってこれでいいんだっけ？ Full ver.

2025年10月16日に実施された「#QATT番外編 秋の夜長に品質ゆるトーク交流会」にて使おうとしていた発表資料です。長過ぎるので当日は簡素化したものを使って話しました。

Transcript

1. すずき (szk.hansuoi@gmail.com) 「改善」って これでいいんだっけ？ QA Tech Talk #番外編 秋の夜⻑に品質ゆるトーク交流会 2025/10/16
2. お前、誰？ • すずき じゅんじ ▪ フリーランスのQAエンジニア ▪ 今までに書いたり喋ったりしたやつ: • 「Semantic-based and Learning-based Regression Test Selection focusing on Test Objectives」共著 • JaSST nano vol.28 #2 「eラーニングコンテンツのチェックリストをVSTePで作ってみたの」 • 「にしさんの教え: ⽇本のテストコミュニティを作った男」共同編集 ▪ 好きなVTuber: 鈴⽊ヒナ • かわいい • とてもかわいい 2 ©LaRa
3. 〜 szkの脳内調べ 〜 「これ改善しようぜ！」の結末あるある BEST3 • 第03位 チェックが無駄に厚くなる ▪ ダブルチェック / トリプルチェックにして「次から気を付けます！」 ▪ チェックリストやテスト観点リスト(？)の⾏数が無限に増える • 第02位 取り敢えず⾃動化 ▪ 誰にも保守できないGASや超⻑時間なCIが⽣まれる ▪ めちゃくちゃ⾼額なツールを導⼊してしまう • 第01位 結局何もしない ▪ 「今のプロジェクトが落ち着いたらね」って 前のプロジェクトの時もそれ⾔ってなかった？ ▪ まぁ確かに忙しいけどさ…… テスト設計‧テスト結果報告‧テスト⾃動化‧etc. 3
4. 改善ってチェック増やせばいいんだっけ？ • いや、ちがう。 ▪ 「業務改善の8原則」も「ECRSの4原則」も まず考えるべきは廃⽌‧排除と⾔っている ▪ • 4 @karaage_rutsuboのツイートより • 業務改善の8原則 1. 廃⽌ 2. 削減 3. 容易化 4. 標準化 5. 計画化 6. 同期化 7. 分担検討 8. ⾃動化 • ECRSの4原則 1. Eliminate (排除) 2. Combine (統合) 3. Rearrange (⼊れ替え) 4. Simplify (単純化)
5. 改善ってチェック増やせばいいんだっけ？ • 問題が発⽣し得ないプロセスを考えてみよう ▪ そもそも今のプロセスはどうなっているのか？ • PFDを描いたら 「あのレポート何にも役⽴ってないじゃん！」となったり ▪ バグやインシデントが 作り込まれないようにできないか？ ▪ ミスる⼯程をより簡単に‧単純にできないか？ • 凝集度が⾼く結合度が低いプロセスを⽬指して プロセスをリファクタリングする • ビール⽚⼿に仕事してもミスらないぐらいに • フールプルーフな仕組みを作れないか考えてみよう ▪ フールプルーフ: ミスができないようにしようという設計思想 • トヨタ⽣産⽅式の「ポカヨケ」 • e.g. 電⼦レンジは扉を閉めないと動かないようにできている 5
6. 改善って⾃動化すればいいんだっけ？ • いや、ちがう。 ▪ 即座に⼿段や実装の話に⾶びつきたくなる気持ちはわかる • 「われわれは腹の中に問題を解きたいという⾃然の欲求をもっている」 (D.C.ゴース, G.M.ワインバーグ著、⽊村泉訳 ライト、ついてますか) ▪ だが我々は 問題の定義や解き⽅の検討が重要だと知っているはずだ • プロダクト開発を経て 痛いほど知っている • テストもプロダクトと同じように 開発するものなのだ という テスト開発なる考え⽅を知っている 6
7. • 改善施策を開発しよう • ▪ プロダクト開発‧テスト開発っぽく整理するならこんな感じ？ • 根本原因分析 → 改善施策設計 → 改善施策実装 → 改善施策実⾏ (→ 効果測定) • ▪ c.f. 改善の⼿順 (by 品質管理⼊⾨) 1. 問題点発⾒‧⽬標決定 2. 改善組織の編成と分担 3. 現状把握 4. 改善⽅法の検討 5. 試⾏案/仮標準の作成 6. 予備試⾏ 7. 結果の確認 8. 標準化 9. 残った問題点と反省‧今後の計画 改善って⾃動化すればいいんだっけ？ 7 • ▪ c.f. 8D問題解決法 (by フォード‧モーター) 0. 準備‧緊急対応措置 1. 改善組織の編成 2. 問題の定義 3. 暫定対策の策定 4. 根本原因と流出原因の究明 5. 恒久的な是正措置の選択 6. 是正措置の実施 7. 予防措置の実施 8. チームの賞賛
8. 改善って⾃動化すればいいんだっけ？ • 根本原因分析の技術⼒を上げよう ▪ なぜなぜ分析(垂直分析)を適切に使えるようになる • パワハラや吊るし上げの道具ではない‧回数制限も無い ▪ なぜなぜ分析のアンチパターンを理解し 察知&回避ができるようになる • 無意味なルート: ⽬的からかけ離れた意味のないルートを突き進んでしまう状態 無意味なルート: e.g. 事故が起きたのはなぜ？ 運動神経が悪いから • 深度不⾜: 「なぜ？」による掘り下げが不⾜しており 深度不⾜: 再発時に同じことを繰り返す未来(e.g. Wチェック→トリプルチェック)が⾒える状態 • 哲学化:⾜ 「なぜ？」による掘り下げが過剰な状態 哲学化:⾜ e.g. ルールを決めていなかったのはなぜ？ 怠っていました なぜ？ ⼈間は愚かなので ▪ ⽔平分析も使いこなせるようになる • 改善施策設計の技術⼒を上げよう ▪ 段階的詳細化と発散とモデリングを使いこなせるようになる 8
9. 改善施策開発の例 9 • 改善施策は 図でモデリングしながら開発するとよい ▪ プロダクト開発‧テスト開発と同様 ▪ 慣れてくれば 最初からドキュメント(テキストでのモデリング) だけでもよいし 議論(⼝頭でのモデリング)だけでもよいかも • 組織の改善施策開発の技術⼒による • ただし 無秩序なお絵描きにならないように注意する
10. 改善施策開発の例 10 まずは根本原因分析 1. 「解きたい問題は何？」 2. 「それはなぜ起こる？」 (なぜなぜ分析/垂直分析) 3. 「他には？」(⽔平分析) 次に 改善施策の基本設計 いきなり具体的な施策は考えず ⽅針レベルから 段階的に詳細化する 場合によっては • As is / To be • 制約条件 • スコープ外とする問題 なども整理‧定義する
11. 改善施策開発の例 11 発散 と 収束 問題やアイデアについて 認識をすり合わせるために 適宜モデルを活⽤する
12. 改善施策開発の例 12 具体的な改善施策‧改善プロジェクトの形に落とし込む 基本設計(⽔⾊の付箋)などとのトレーサビリティを確保し このアクションは何のためにやるのか わかるようにする (⼿段の⽬的化を防ぐ)
13. そうは⾔ってもテストで⼿⼀杯なんだよ…… プロダクトの品質だけでいいでしょう？
14. 製品の質、仕事の質、サービスの質、 情報の質、⼯程の質、部⾨の質、 作業者‧技術者‧管理者‧経営者の質つまり⼈の質、 システムの質、会社の質、⽅針の質、等々 というように、 これらすべての質を管理していこうというのが、 我々の基本姿勢である。 ⽇本的品質管理の⽗ 故 東京⼤学名誉教授 ⽯川馨 14
15. 品質保証ってテストだけでいいんだっけ？ • いや、ちがう。 ▪ テストはあくまで品質を保証するための⼿段のひとつでしかないはずだ • テストの3ム(ムリ‧ムダ‧ムラ)を減らそう ▪ 例えば • 「不安だから⼀応これも」とテストケースをいたずらに増やしていないか？ • オートメーション‧ハイに陥って何でも⾃動化して ⾃動テストスイートをFlakyにしていないか？ • クイックな改善施策開発技術を⾝につけよう ▪ 「いかに早く⽯橋をたたいて渡るか」(⽯川馨著 品質管理⼊⾨) ▪ 例えば • PFDやSTAMPなどのモデルをさっと描けるようになる • ⼩さな範囲でPDCAを実験的に回し 「これイイね！」となった施策についてのみSDCAを回す習慣を付ける 15
16. 品質保証ってテストだけでいいんだっけ？ 16 • PDCAは 頑張って「今より良い状態」にする ▪ もっとがんばればもっと良くなる？ • いや 限界がある ▪ そのままでは 油断すると元の状態に戻ってしまう • SDCAも回して 頑張らなくても 「良い状態を維持できる状態」にする ▪ Standardize(標準化)のS ©Zuken PreSight Inc.
17. でもそれって めちゃくちゃ時間かかるし⼤変じゃない？
18. 18 種を蒔くのよ。⽔をやるのよ。⾟抱強くね。 芽が出るのよ。枯れるのよ。 飽きず倦まず繰り返すのよ。 その間は無限の時がかかるような気がするのよ。 でも、ひょんなタイミングで⼀⻫に咲き出すのよ。 不思議なものよ。 (その間に) ⾜りない、って思うと倦んじゃうから。 ⽇常。そうすることが⾃分にとって⾃然、にする。 明鏡⽌⽔。 ⽇本のテストコミュニティのパイオニア 故 電気通信⼤学講師 にしやすはる
19. すずき (szk.hansuoi@gmail.com) 「改善」って これでいいんだっけ？ QA Tech Talk #番外編 秋の夜⻑に品質ゆるトーク交流会 2025/10/16