連載目次
- 車載ソフト開発で品質保証プロセスが根付かない理由
- 品質保証はプロセスを監査するだけなのか
- レビューで確認したいのは成果物なのか思考なのか
- レビューの価値とは何か
- プロセスは思考を設計しているのか
- 良い思考はどのように組織へ伝わるのか
- 良い思考はどのように組織知になるのか
- 良い思考はどのように身につくのか
- 思考訓練はどのように設計すれば良いのか？
- QAは思考訓練の題材として優れているのか（本記事）
はじめに
私はこれまで、品質保証活動を通じて多くのメンバー育成(というよりは成長支援)に関わってきました。
思い返してみると、
「良い品質保証活動を行うためには、良い思考が必要である」
ということです。
そしてさらに、
「良い思考を身につけるための題材として、QAの活動は非常に優れているのではないか」
と考えるようになりました。
なお、本記事で扱うQAは品質保証活動全体を指しているわけではありません。
監査や品質保証プロセス改善といった活動もQAの重要な役割ですが、本記事では主に
- テスト分析
- テスト設計
- レビュー活動
を題材として話を進めます。
きっかけは顧客からの質問だった
私が思考訓練について考えるようになったきっかけは、ある顧客からの質問でした。
なぜそのテストで十分なのですか？
当時、私はその質問に十分答えることができませんでした。
もちろんテスト設計書は存在していました。
しかし、
- なぜそのテストを選んだのか
- なぜその観点が必要なのか
- なぜそれで十分と言えるのか
を説明できなかったのです。
その時に気づきました。
テスト設計書は単なる成果物ではなく、
要求仕様書に対するレビュー結果でもある
のではないか、と。
テスト設計は要求仕様書のレビューである
テスト設計は要求仕様書をベースに作成されます。
当然ですが、要求仕様書と矛盾するテストを作ることはできません。
一方で、要求仕様書に書かれていないことが現実には発生します。
その時に考えることは、
- 要求漏れなのか
- 他の仕様書に記載されているのか
- 設計側に委ねているのか
- 別レベルのテストで保証するのか
ということです。
私は要求仕様書を、
「現時点での解答集」
だと考えています。
もちろん完璧な解答集ではありません。
しかし、誰かが考えた結果がそこに書かれています。
テスト設計者は、その答案を見ながら、
「なぜその答えになったのか」
を考えることになります。
QAは他人の思考を追跡する訓練になる
要求仕様書には、最終的な結論だけが書かれていることがあります。
例えば、
A → D
という結論だけが記載されている状態です。
しかし実際には、
A → B → C → D
という思考の流れがあったはずです。
その途中が、
- 他の仕様書に書かれている
- 前提知識として扱われている
- あえて省略されている
場合があります。
テスト設計者は、その省略された思考を推測しなければなりません。
重要なのは、最初から要求漏れと決めつけないことです。
例えば、
- サプライヤに設計自由度を残している
- 他システム側で保証する
- 別レベルのテストで保証する
- 別冊の仕様書に記載されている
といった理由も考えられます。
つまり、確認したいのは
「何が書かれていないか」
ではなく、
「なぜそうなっているのか」
なのです。
これは単なるテストケース作成ではありません。
他者の思考を追跡し、理解しようとする活動です。
私はこれが、QAが思考訓練の題材として優れている理由の一つだと考えています。
QAで身につくのはQAだけのスキルではない
テスト設計を通じて鍛えられる能力として、
- 分解
- 抽象化
- 具体化
- 構造化
- 視点切替
があります。
また、
- 仮説を立てる
- リスクを考える
- 根拠を説明する
ことも求められます。
これらはQAだけで必要な能力ではありません。
要求分析でも、設計でも、システムエンジニアリングでも、共通して必要になります。
USDMやMBSEにもつながる
私は以前、自然文で書かれた要求仕様書をUSDMへ変換する活動を支援していました。
その際に苦労する人が多かったのは、記法ではありませんでした。
思考の構造化です。
USDMでは、要求を分解し、階層化し、関係性を整理する必要があります。
これは、
- 抽象化
- 具体化
- 分解
- 構造化
そのものです。
また、MBSEやSysMLでも同じような能力が求められます。
つまり、QAで鍛えられる思考は、QAだけのものではなく、
上流工程にも適用できる汎用的な能力なのです。
成長した人は何が違ったのか
このように思考を鍛えた例として、
過去に思考の訓練を支援したメンバーの中で、大きく成長した人をご紹介いたします。
顧客が既にある要求仕様書をベースにして、要求が漏れていないか確認する方法がないか、と依頼して来ました。
上記のメンバーと一緒に取り組むことにしました。
私が構想を検討し、その人には構想から具体化するところをお任せしました。
この時点である程度、私の中では固まっていましたが、このメンバーに経験を積んで頂きたいと思って
このようにしました。
もちろん丸投げではありません。
私はレビュアとして、責任者として関わっています。
しかし、その人は、
- 自ら情報収集を行い
- 要求分析プロセスを定義し
- テンプレートを作成し
- 顧客へ展開できるレベルまで作り上げました
私はその時、その人が学んだのはQAスキルではなく、
思考の仕方そのもの
だったのではないかと感じました。
QAをやれば成長するわけではない
ここは誤解してほしくない点です。
QAに関われば自動的に成長するわけではありません。
例えば、
- 過去成果物を流用するだけ
- チェックリストを埋めるだけ
- 指摘を待つだけ
では思考訓練になりません。
大切なのは、
- なぜそう考えたのか
- 他の選択肢はなかったのか
- どこで保証するのか
- なぜそこで保証するのか
を考えることです。
QAは思考訓練の題材として優れていますが、思考しなければ訓練にはなりません。
QAの先にあるもの
私はQAを最終到達点だとは考えていません。
QAで身につく思考は、要求分析や設計にも応用できます。
そして最終的には、V字プロセスの両側を考えられるようになることが重要だと思っています。
- 要求を考える
- 設計を考える
- 検証を考える
- 品質保証戦略を考える
その上で、左側を深めるのか、右側を深めるのか、
あるいは全体戦略を考える立場を目指すのかは、各人のキャリア次第でしょう。
私は、ある程度経験を積んだら反対側にも触れてみることが重要だと考えています。
開発者であればQAを学ぶ。
QAであれば要求分析や設計を学ぶ。
そうすることで、V字プロセス全体を理解できるようになるからです。
おわりに
私はQAを思考訓練の題材として優れていると考えています。
それはQAが特別だからではありません。
QAが、要求と検証の対応関係を考え、他者の思考を追跡し、
品質をどのように保証するのかを考える活動だからです。
そしてそこで身につく思考は、QAだけでなく、要求分析や設計、
さらにはシステムエンジニアリングにも応用できます。
品質保証活動を通じて身につくのは、テスト技術だけではありません。
「どこへ行っても考えられる力」
なのではないかと、私は考えています。