この連載について
本連載では、品質保証（QA）の実務経験をもとに、
- 品質保証とは何か
- 品質はどのように作られるのか
- 良い思考はどのように伝わるのか
- 良い思考はどのように身につくのか
について考察しています。
連載一覧
- 車載ソフト開発で品質保証プロセスが根付かない理由
- 品質保証は品質を保証しているのか？
- QAは何を保証するのか？
- レビューの価値は学習なのか？
- プロセスは思考を設計しているのか？
- 良い思考はどのように伝わるのか？
- 良い思考はどのように組織知になるのか？
- 良い思考はどのように身につくのか？
- 思考訓練はどのように設計すれば良いのか？（本記事）
品質保証について考え始めた結果、レビュー、学習、思考、組織知へと議論が広がってきました。
今回は、その中でも「思考訓練」に焦点を当てて考えてみたいと思います。
はじめに
前回の記事では、「良い思考はどのように身につくのか？」について考えました。
私は、良い思考は訓練によって身につくと考えています。しかし同時に、その習得には長い時間がかかることも経験してきました。
私自身が身につけるまで時間がかかりましたし、他のメンバーへ伝える際にも同様でした。
なぜ思考訓練には時間がかかるのでしょうか。
また、その時間を短縮する方法はあるのでしょうか。
今回は、品質保証活動の中で行ってきた育成経験を振り返りながら、「思考訓練はどのように設計すれば良いのか」について考えてみたいと思います。
なぜ思考訓練には時間がかかるのか
当初、私は成果物をレビューし、問題点を指摘すれば徐々に改善していくものだと考えていました。
しかし、現実はそう単純ではありませんでした。
同じような指摘が何度も繰り返されることがあったからです。
後になって気づいたのは成果物の問題ではなく、その背景にある「考え方」に問題があるケースが多いということでした。
しかし、その考え方は成果物から直接見えるわけではありません。
成果物は結果であり、そこに至る思考の経路は見えないからです。
さらに厄介なのは、人によって思考の癖が異なることです。
一度や二度のレビューでは見極められないことも多く、複数回のレビューを通して共通するパターンを探る必要がありました。
これこそが思考の訓練に時間がかかってしまう理由ではないかと考えています。
試行錯誤しているうちに、以下のような考えが浮かんできました。
品質保証の世界では、不具合が発生した際に根本原因分析を行います。
思考訓練も同じで、私は次第に「思考の不具合解析」をしていたのではないかと考えるようになりました。
思考の不具合とは何か
レビューの中でよく見られたものとして、次のようなものがあります。
- 考慮漏れ
- 前提不足
- 分岐の誤り
- ステップの飛躍
極端な例を言えば、正常系だけを考え、異常系が抜けている。
あるいは、利用環境を考慮せずに結論を出してしまう。
また、要求からいきなりテストケースを作成してしまい、その間の分析過程が見えないこともあります。
これらは成果物の問題というより、思考プロセス上の問題ではないかと考えています。
思考プロセス上の問題が、成果物に表出している、というイメージです。
重要なのは、「どこが間違っていたか」ではなく、「どのような経路でそこへ至ったのか」を把握することだと感じています。
問いの役割
ここで重要になるのが問いです。
私はレビューの際によく、
「なぜそう考えたのですか？」
という問いを投げていました。
しかし、この問いで正しい答えを期待していたわけではありません。
知りたかったのは、相手の思考経路です。
例えば、
- どのような観点を考えたのか
- 他にどのような選択肢があったのか
- なぜその案を選んだのか
を知りたいのです。
そのため、
「他に考えたことはありますか？」
という問いもよく使っていました。
これは考慮漏れを責めるためではありません。
どのような判断を行い、何を優先したのかを理解するためです。
思考訓練における問いは、答え合わせではありません。
思考経路を観測するためのものだと考えています。
思考訓練を設計する、とは何を設計することなのか
ここまで考えてきて、私は思考訓練とは、
「どの問いを、どの順番で、どの粒度で与えるか」
を設計することなのではないかと考えています。
初心者の場合、思考のステップ幅が大きすぎることがあります。
例えば、要求を読んだ後、いきなりテストケースを作ろうとしてしまう。
しかし実際には、
- 利用者は誰か
- どのような環境で使うのか
- 何が起こり得るのか
- どのようなリスクがあるのか
といった中間ステップが存在します。
思考訓練とは、この大きな階段を小さく分解し、一段ずつ登れるようにする活動なのかもしれません。
思考の不具合の背景にある土台スキル
思考の不具合を観察していると、その背景にはさらに別の要因があるように感じます。
例えば、
- 抽象化
- 具体化
- 分解
- 構造化
といった土台スキルです。
ステップの飛躍が起きる背景には、分解する力の不足があるかもしれません。
考慮漏れの背景には、抽象化の不足があるかもしれません。
また、視点・視野・視座も関係しているように感じています。
利用者視点で見られていないのか。
プロジェクト全体を見られていないのか。
あるいは、自分の担当範囲だけに注目しているのか。
これらも思考の質に大きく影響しているように思います。
成長した状態とはどんな状態か
何をもって成長した、思考の不具合が減ってきたと判断できるのでしょうか。
例えば次のような変化です。
- 同じ思考の不具合パターンが減る
- 不具合の質が変わる
- テンプレートを状況に応じて使い分けられる
- 他人の成果物をレビューできる
特に印象的なのは、いくつかあるレビュー項目の一つ目のレビューが完了後、そのレビューの指摘から全体を見直せるようになることがあります。
成長が早い人は、
「このテストケースを修正する(で良いですか？となる)」
ではなく、
「考え方そのものを見直す必要がある」
と気づきます。
その結果、残りの成果物も自ら修正できるようになります。
私は、その状態こそが成長だと考えています。
組織の壁
思考訓練には別の難しさもあります。
それは、短期的には非効率に見えることです。
最初のうちは、ベテランよりも時間がかかります。
レビュー時間も長くなります。
進捗だけを見ると遅く見えるかもしれません。
しかし、できるようになると状況は変わります。
成果物作成も速くなり、レビュー工数も減ります。
そのため私は、メンバーだけでなく上司にも方針を説明していました。
何を狙っているのか。
いつ頃効果が出るのか。
なぜ時間をかけるのか。
思考訓練は個人だけの問題ではなく、組織の理解も必要な活動だと思います。
おわりに
思考訓練とは、正しい答えを教えることではありません。
思考経路を共有し、一緒に辿りながら、どこで思考の不具合が発生したのかを探ることです。
そして、その背景にある土台スキルを育てていくことです。
そのためには、
- どの問いを
- どの順番で
- どの粒度で
与えるかを設計する必要があります。
私自身、まだより良い方法を模索している途中です。
しかし、少なくとも成果物だけを見ていては思考は育たないと感じています。
次回は、なぜ私がQAを思考訓練の題材として有効だと考えているのかについて整理してみたいと思います。
この連載の全体像はこちら：
車載ソフトウェア品質保証を考える：連載まとめ