はじめに

これまでの記事では、品質保証、レビュー、プロセス、良い思考、思考訓練について考えてきました。

本記事は、以下の連載の11本目にあたります。

QAは品質を保証しているのか？〜品質保証プロセスが根付かない理由を考える〜
レビューは品質を保証しているのだろうか
AI時代にQAエンジニアが保証するものは何か？
レビューの価値とは何か
プロセスは思考を設計しているのか
良い思考はどのように組織へ伝わるのか
良い思考はどのように組織知になるのか
良い思考はどのように身につくのか
思考訓練はどのように設計すれば良いのか？
QAは思考訓練の題材として優れているのか
良い思考を組織の活動にするには何が必要なのか？ ← 本記事

前回までは、良い思考をどのように身につけるか、そしてQAが思考訓練の題材としてなぜ有効なのかについて考えました。

今回は、その先の話です。

良い思考を身につけた人がいる。
良いレビューができる人がいる。
良いテスト設計ができる人がいる。
良いプロセス改善を考えられる人がいる。

では、それで組織の品質は上がるのでしょうか。
私の経験では、答えは単純ではありません。

私自身、良い思考を組織全体の活動として十分に成功させた経験があるわけではありません。むしろ、うまくいった部分とうまくいかなかった部分の両方がありました。
そのため本記事は、「こうすれば必ず組織に定着する」という成功論ではありません。

私のこれまでの経験と思っていることをもとに、

局所的にはうまくいった考え方を、組織の活動にするには何が必要だったのか

を考えてみたいと思います。

本記事で考えたいこと

本記事が思いの外ボリュームが出てしまいましたため、
先に、本記事で言いたいことをまとめます。

良い思考を組織活動にするには、プロセスやテンプレートを展開するだけでは足りないと思っています。特に重要なのは、プロジェクトごとのテーラリング判断をレビューできることだと考えています。
そして、その活動が「余計な作業」ではなく「判断品質を高める品質活動」として受け入れられて初めて、文化に近づいていく。

本記事では、この考えを以下の流れで整理します。

個人の実践
  ↓
周辺メンバーへの共有
  ↓
組織化
  ＝仕組み・役割・問い・判断基準がある状態
  ↓
文化化
  ＝それを使うことが自然で価値ある活動になっている状態

良い思考を持った個人がいるだけでは、組織の品質は安定しません。
その考え方が複数人で再現され、さらにそれを使うことが自然な活動として受け入れられていく必要があります。

組織の活動になっている状態とは何か

まず、「良い思考が組織の活動になっている」とは、どのような状態でしょうか。
私は、次のような状態だと考えています。

特定の人がいなくても、同じような問い・観点・判断基準が複数人によって再現される状態

ここで重要なのは、同じ成果物が作れることではありません。

もちろん成果物の品質は重要です。
しかし、本当に組織の活動になっているかどうかは、成果物そのものよりも、その成果物に向き合う考え方に表れると思います。

たとえば、ある人がいなくなっても、

なぜそう考えたのか確認しよう
その判断の前提は何か確認しよう
この要求はどこで保証するのか考えよう
このテーラリングで増えるリスクは何か確認しよう
顧客レビューを通ったことと、十分に考えられていることは別として考えよう

という問いが、別の人から自然に出てくる。
これが、良い思考が組織の活動になっている状態に近いのではないかと思います。

一方で、特定の人がいることで品質が保たれている状態もあります。

その人がレビューすれば品質が上がる。
その人が顧客と会話すれば説明が通る。
その人がメンバーに問いかければ、考え方が深まる。
その人がプロセスを調整すれば、プロジェクトがうまく回る。

これは短期的には非常に強い状態です。

しかし、その人がいなくなると再現できないのであれば、それは組織の活動というよりも、個人に依存した活動です。

私はこれを、ここでは「個人商店」と呼びたいと思います。

状態	意味	起きやすい問題
個人依存	特定の人がいることで品質が保たれる	その人が抜けると再現できない
組織化	仕組み・役割・問い・判断基準がある	形骸化する可能性がある
文化化	仕組みを使うことが自然に価値ある活動になっている	定着には時間と支援が必要

個人商店が悪いわけではありません。
むしろ、現実のプロジェクトでは、個人の力で支えられている場面は多いと思います。

しかし、品質を継続的に高めようとするなら、個人商店のままでは限界があります。

良い思考を組織の活動にするとは、個人が持っている問い・観点・判断基準を、複数人が再現できる状態に近づけることなのだと思います。

自分の周辺では、なぜ機能したのか

私が過去に関わったプロジェクトの中で、自分の周辺では一定程度、考え方を共有できたと感じることがありました。

レビューの中で、単に成果物の誤りを指摘するのではなく、

なぜそう考えたのか
他にどのような候補を考えたのか
どこで判断したのか
なぜそれで十分だと考えたのか
次に同じことを防ぐには、何を残すべきか

を確認するようにしていました。

また、成果物だけでなく、中間成果物や考え方の経路を残すことも重視していました。

その結果、メンバーの中には、指摘を単なる個別修正として受け取るのではなく、考え方そのものを修正しようとする人も出てきました。

以前ならこちらが指摘していたようなことについて、次のレビューでは、

ここはこのように考えたので、こうしました

と、先に説明してくれることもありました。

これは、私にとってはかなり大きな変化でした。
ただし、今振り返ると、それが機能した背景には、いくつかの条件がありました。

長期プロジェクトだったこと
顧客との信頼関係があったこと
同じメンバーで継続的にレビューできたこと
なぜそのように考えるのかを伝える時間があったこと
すぐに成果が出なくても待てる状況があったこと
メンバーの土台スキルが少しずつ揃っていったこと

つまり、その考え方が成立する土壌がありました。
だから、自分の周辺では機能したのだと思います。

しかし、それは組織全体の活動になっていたわけではありませんでした。

なぜ自然には広がらなかったのか

うまくいった取り組みがあると、上司や組織としては、それを別のプロジェクトにも展開したくなります。

これは自然なことだと思います。
実際、私自身も別プロジェクトにアドバイザーのような形で関わったことがあります。

しかし、そこで感じたのは、良い取り組みであっても、そのまま横展開できるわけではないということです。

自分が関わっていたプロジェクトでは、時間をかけて考え方を共有してきました。
メンバーも、なぜそのような問いをするのか、なぜ中間成果物を残すのか、なぜ判断理由を確認するのかを少しずつ理解していました。

しかし、別プロジェクトのメンバーから見ると、それは突然やってくる新しいやり方です。

すると、次のように見えてしまう可能性があります。

考えることが増えた
書くものが増えた
レビューで細かく聞かれるようになった
なぜそこまでやるのか分からない
今までのやり方を否定されているように感じる

これは、メンバーの能力や姿勢の問題だけではありません。

文脈が共有されていないのです。

なぜこのやり方が必要なのか。
どのような品質リスクを下げたいのか。
どこまで考える必要があるのか。
何を残せばよいのか。
どこまで省略してよいのか。

そうした背景が共有されないまま、プロセスやテンプレートだけを展開しても、受け手には「重い作業」に見えてしまいます。

良い思考は、プロセスやテンプレートだけでは横展開できません。

その考え方を成立させていた文脈、土台スキル、問いかけ、顧客との関係性も含めて考える必要があります。

プロセスやテンプレートだけでは足りなかった

私は、プロセスやテンプレートを整備すること自体は重要だと考えています。

考える順番を示す。
中間成果物を定義する。
観点を明確にする。
判断理由を書く欄を設ける。
レビュー観点を整理する。

これらは必要です。

しかし、それだけでは十分ではありませんでした。

なぜなら、実務で本当に重要になるのは、プロセスやテンプレートを使う場面だけではなく、それをプロジェクトに合わせて調整する場面だからです。

たとえば、

このプロジェクトでは、どの中間成果物を残すべきか
どの成果物は省略してよいか
省略したことで増えるリスクは何か
そのリスクはどこで補完するのか
顧客とどこまで合意しているのか
前提が変わった場合、どこで見直すのか

こうした判断が必要になります。
そして、この判断には良い思考が必要です。

私が過去にうまくできなかったことの一つは、このテーラリング判断を十分にレビューしきれなかったことだったのではないかと思っています。

トレーニングはしました。
文脈もある程度伝えました。
最終成果物も作られました。
顧客レビューも通りました。

しかし、後から考えるとプロセスのテーラリング判断や、中間成果物の残し方まで十分に確認できていたとは言えませんでした。

最終成果物と口頭での補足、少しの中間成果物だけで進んでいた場面もありました。

顧客から深い指摘がなかったため、そのまま通ったように見えました。
しかし、それは十分な思考を経たことの証明ではありません。

顧客レビューを通ったことと、十分に考えられていたことは違います。

問題がなかったのではなく、問題が表面化しなかっただけかもしれません。
顧客の見る目が変わったり、プロジェクトの前提が変わったりすると、後から大きな問題になることもあります。

ここに、良い思考を組織活動にする難しさがあると思います。

良い思考はテーラリング判断に表れる

標準プロセスをそのまま実行している場面では、考え方の差は見えにくいかもしれません。

しかし、プロジェクトに合わせてテーラリングする場面では、思考が表れます。

何を省略するのか。
なぜ省略してよいのか。
省略によって増えるリスクは何か。
そのリスクをどこで補完するのか。
どの判断を顧客と合意するのか。
どの中間成果物を残すのか。

これらは、単なる手続きではありません。
品質保証上の判断です。

私は、テーラリングとはプロセスを軽くすることではなく、

品質を保証するための考え方を、プロジェクトに合わせて再配置すること

なのではないかと考えています。

標準プロセスをすべて実施すれば品質が保証される、というわけではありません。
一方で、プロセスを減らせば効率化できる、という単純な話でもありません。

大事なのは、

何を実施し、何を省略し、省略したリスクをどこで補うのか

を説明できることです。

この判断をレビューできるかどうかが、良い思考が組織活動になっているかどうかを判断する一つの重要な観点になると思います。

テスト設計レビューでも同じです。

レビュー対象	表面的な確認	本当に確認したいこと
テスト設計	テストケースがあるか、要求と対応しているか	なぜその観点・条件で十分と言えるのか
プロセステーラリング	標準からの変更点が妥当か	なぜその省略・変更で品質保証上問題ないと言えるのか

テスト設計レビューでは、テストケースの有無や要求との対応だけではなく、

なぜそのテスト条件を選んだのか
何をリスクと見たのか
どこで保証するつもりなのか
なぜそれで十分と言えるのか

を確認する必要があります。

テーラリングレビューも同じです。
標準プロセスから何を変えたかを見るだけではなく、

なぜその変更でよいと判断したのか
何を省略しても品質保証上問題ないと考えたのか
その判断の前提は何か
前提が崩れた場合、どこで検知するのか
増えたリスクをどこで補完するのか

を確認する必要があります。

つまり、テーラリング判断をレビューするには、良い問いかけが必要になります。

プロセスレビューは、単なる手続き確認で終わってはいけません。
判断理由を確認するレビューである必要があります。

テーラリング判断レビューで確認したい問い

テーラリング判断をレビューする際には、次のような問いが必要になると考えています。

確認したいこと	問いの例
変更・省略したもの	何を標準プロセスから変更・省略しましたか
判断理由	なぜそれを省略してよいと判断しましたか
リスク	省略によって増えるリスクは何ですか
補完策	そのリスクをどこで補完しますか
判断の前提	その判断の前提は何ですか
見直し条件	前提が変わった場合、いつ見直しますか
合意	顧客や関係者とはどこまで合意していますか
記録	判断理由はどこに残っていますか

この表にある問いは、単に相手を詰めるためのものではありません。
むしろ、プロジェクト自身が自分たちの判断を説明できるようにするための問いです。

特に重要なのは、

省略したことで増えるリスクは何か
そのリスクをどこで補完するのか

だと思います。

これがないと、テーラリングは品質保証の再配置ではなく、単なる削減になってしまいます。

組織化と文化化は違う

ここで、「組織化」と「文化化」を分けて考えたいと思います。

良い思考が組織化されている状態とは、良い思考を再現するための仕組みがある状態です。

たとえば、

テーラリング判断をレビューする場がある
判断理由を確認する問いがある
誰がレビューするか決まっている
何を中間成果物として残すか決まっている
省略したリスクを確認する基準がある
アドバイザーや中核メンバーの役割がある

これは、仕組み・役割・プロセス・基準の話です。

一方で、良い思考が文化になっている状態とは、その仕組みを使うことが自然に価値ある活動として受け入れられている状態です。

たとえば、

なぜその判断をしたのかを聞くことが普通である
テーラリング判断をレビューすることが面倒扱いされない
中間成果物を残すことが余計な作業ではなく品質活動として見られる
育成やレビューに時間を使うことが投資として認められる
顧客レビューを通ったからOK、で止まらない

この状態です。

組織化
  ＝ 良い思考を再現するための仕組みがある

文化化
  ＝ その仕組みを使うことが自然に価値ある活動になっている

組織化と文化化は、同じではありません。

仕組みがあっても、文化になっていなければ形骸化します。

テーラリングレビューをやることになっているからやる。
チェックリストを埋める。
承認をもらう。
しかし、判断理由は深く確認しない。

これでは、仕組みはあっても良い思考は実践されていません。

逆に、文化らしきものがあっても、仕組みがなければ広がりません。

特定の人の周辺では深いレビューが行われる。
問いかけもできる。
考え方も共有される。
しかし、その人がいなくなると途切れる。

これは、価値観は共有されていても、組織活動にはなりきれていない状態です。

したがって、良い思考を組織の活動にするには、仕組み化と文化化の両方が必要になります。

価値ある活動として認められるには何が必要か

では、テーラリング判断をレビューすることや、判断理由を確認することが、価値ある活動として認められるには何が必要でしょうか。

企業活動において、コストは避けられません。

レビューを深くする。
問いかける。
中間成果物を残す。
テーラリング判断を確認する。
アドバイザーが伴走する。

これらは短期的にはコストに見えます。

実際、初期段階ではプロジェクトの速度が一時的に落ちることもあると思います。
成果物作成やレビューに時間がかかるためです。

しかし、それを単なる追加作業として見るのか、将来の品質コストを下げる投資として見るのかで、扱いは大きく変わります。

短期的に発生するコスト	中長期的に減らせる可能性があるコスト
テーラリング判断レビューの工数	後工程での手戻り
判断理由を残す工数	顧客レビューでの深い差し戻し
中間成果物を作成する工数	レビュー指摘の再発
アドバイザー伴走の工数	新規メンバーの立ち上げ遅れ
チーム内で問いかける工数	特定個人への依存
セルフ診断を実施する工数	プロジェクト間の品質ばらつき

判断品質を高める活動は、短期的にはコストです。
しかし、中長期的には品質コストを下げる活動でもあります。

ただし、その価値はすぐには見えにくいと思います。
そのため、何が良くなったのかを見えるようにする必要があります。

たとえば、

テーラリング判断の理由を説明できるようになった
省略した成果物に対するリスク補完が説明できるようになった
レビューで同じ指摘が繰り返されなくなった
メンバーが指摘を個別修正ではなく、考え方の問題として捉えるようになった
顧客説明で、なぜその進め方でよいのかを説明できるようになった
中間成果物を全部作るのではなく、必要なものを選べるようになった

こうした変化は、良い思考が組織活動に近づいているサインだと思います。
文化とは、スローガンではありません。

私は、ここでいう文化とは、

組織が何を良い仕事とみなし、何に時間を使うことを許容し、どのような判断を評価するか

だと考えています。

テーラリング判断をレビューすることを、余計な作業と見るのか。
判断品質を高める品質保証活動と見るのか。

この差が、文化の差なのだと思います。

逆方向の力もある

良い思考を組織活動にしようとしても、それを妨げる力があります。

一つは外部要因です。

メンバーの入れ替え
短納期
顧客要求の変化
PM/PLの交代
アドバイザー不在
レビュー工数削減
成果物承認だけでOKとする空気

こうした要因によって、せっかく育った考え方がリセットされることがあります。

特に受託企業のように、プロジェクトごとにメンバーが変わりやすい環境では、あるプロジェクトで定着した考え方が、次のプロジェクトではまた最初からになることもあります。

もう一つは、内部の抵抗です。

新しいやり方への抵抗感は自然に起こります。

今までのやり方で回っていたのに、なぜ変えるのか。
なぜ考えることが増えるのか。
なぜ書くことが増えるのか。
なぜレビューでそこまで聞かれるのか。

こう感じる人がいても不思議ではありません。

また、問いかけは扱い方を間違えると、支援ではなく詰問に見えます。

「なぜそうしたのですか？」
「他に考えませんでしたか？」
「なぜそれで十分だと言えますか？」

これらは良い問いにもなりますが、相手との関係性や場の作り方によっては、責められているように受け取られることもあります。

良い思考を組織活動にするには、こうした心理的抵抗も考える必要があります。

監査ではなく、判断品質のセルフ診断へ

自プロジェクトの状態を確認するという意味では、監査という考え方もあります。
しかし、私はこの文脈で「監査」という言葉を使うことには少し慎重です。

監査という言葉には、どうしても、

指摘される
チェックされる
悪いところを探される
守れているか確認される

という印象がつきまといます。

もちろん、監査そのものが悪いわけではありません。
必要な監査もあります。

しかし、良い思考を組織に根付かせたい場合、最初の入口が監査だと、心理的抵抗が大きくなるのではないかと思います。

本当に確認したいのは、ルール違反ではありません。
確認したいのは、判断品質です。

そこで、まずは「判断品質のセルフ診断」という考え方が有効ではないかと考えています。

判断品質のセルフ診断
  ↓
弱い箇所を把握する
  ↓
チーム内で改善する
  ↓
判断が難しい部分だけアドバイザーに相談する
  ↓
テーラリング判断を見直す

プロジェクト自身が、次のようなことを確認します。

セルフ診断で確認したいこと	確認の観点
変更・省略したもの	標準プロセスから何を変更・省略したか
判断理由	なぜそれを省略してよいと判断したか
リスク	省略によって増えるリスクは何か
補完策	そのリスクをどこで補完するか
判断の前提	その判断はどの前提に基づいているか
見直しタイミング	前提が変わった場合、いつ見直すか
関係者合意	顧客や関係者とはどこまで合意しているか
記録	判断理由が成果物や記録に残っているか

これを、人に指摘される前に、自分たちで確認できるようにする。

さらに、セルフ診断の結果として改善点が見えたら、まずはチーム内で見直す。
それでも判断が難しい部分だけ、人のアドバイザーに相談する。

この形であれば、心理的な抵抗は下がるのではないかと思います。

人のアドバイザーも、プロジェクト全体を監査する人ではなく、判断が難しいところを一緒に考える人になります。

これは、かなり大きな違いです。

判断品質のセルフ診断は、監査の代替ではありません。
良い思考を組織に根付かせるための入口です。

うまくいっていないプロジェクトをどう立て直すか

ここまで、良い思考を組織活動にするためには、仕組み化と文化化の両方が必要だと述べてきました。

しかし、実際のプロジェクトでは、すでにうまくいっていない状態から立て直しを求められることもあります。
その場合、「文化を作りましょう」「問いかけを増やしましょう」と言うだけでは間に合いません。

まず必要なのは、そのプロジェクトがどこで詰まっているのかを見つけ、どこから手を入れるべきかを示すことだと思います。
うまくいっていないプロジェクトに必要なのは、できていないことを責めることではありません。

必要なのは、

どこから立て直すとよいかを示すこと

です。

その意味でも、判断品質のセルフ診断は有効な入口になるかもしれません。

たとえば、

詰まり方	最初に見直すとよさそうなこと
目的が揃っていない	成果物が何を判断するためのものか
判断理由が残っていない	迷った判断、省略した判断、後で揉めそうな判断
テーラリングが単なる削減になっている	省略によって増えたリスクと補完策
レビューが成果物確認だけになっている	指摘の背景にある思考の不具合
特定の人に判断が依存している	判断の型、問いの型、相談すべき条件

いきなりプロジェクト外のアドバイザーが入ると、心理的なハードルが高い場合もあります。
しかし、セルフ診断で状態を把握し、必要な部分だけアドバイザーに相談する形であれば、支援を受けやすくなるのではないかと思います。

この話は、本記事では頭出しに留めます。
プロジェクトの立て直しをどこから始めるべきかは、それだけで別の記事になるテーマだと思います。

今後考えたいこと

ここまで考えてくると、さらに気になることがあります。

それは、

どの活動を行うと、組織化や文化化がどの程度進むのか

を見える化できないか、ということです。

たとえば、

プロセス整備
テンプレート整備
問いかけ例の整備
テーラリングレビュー
判断品質のセルフ診断
アドバイザー伴走
PM/PLへの説明
成果の見える化

といった活動が、それぞれ組織化や文化化にどの程度効くのか。

それが見えると、組織に対して説明しやすくなるのではないかと思います。
これは、以前考えた「QAのデジタルツイン」に近いテーマかもしれません。

品質保証活動や組織能力をモデル化し、施策の効果を比較できるようにする。
そのようなことができれば、良い思考を組織活動にするための説明や、うまくいっていないプロジェクトの立て直しにも活用できるかもしれません。

この点については、別のテーマとして改めて考えてみたいと思います。

おわりに

良い思考を組織の活動にするには、プロセスやテンプレートを展開するだけでは足りません。

プロセスを使う人が、どのように問い、どのように判断し、何を省略し、どこでリスクを補うのか。
そこまで扱える必要があります。

特に、良い思考が組織化されているかどうかは、テーラリング判断に表れやすいと感じています。
標準プロセスをそのまま実施することよりも、プロジェクトに合わせて調整する場面で、考え方の差が出るからです。

そして、テーラリング判断をレビューするには、良い問いかけが必要です。

単に手続きが守られているかを見るのではなく、

なぜその判断をしたのか
何を省略したのか
省略したリスクは何か
どこで補完するのか
なぜそれで十分と言えるのか

を確認する必要があります。

また、仕組みがあることと、仕組みを使うことが自然に価値ある活動として受け入れられていることは違います。

組織化とは、良い思考を再現する仕組みがある状態です。
文化化とは、その仕組みを使うことが自然に価値ある活動として受け入れられている状態です。

この差は大きいです。

仕組みだけでは形骸化します。
文化だけでは属人的になります。

良い思考を組織活動にするには、仕組み化と文化化の両方が必要です。

そして、そのためには、判断品質を高める活動を、短期的な追加コストではなく、中長期的な品質コスト低減のための投資として扱う必要があります。

最後に、私は次のように考えています。

文化は、何を実施するかではなく、何を省略してよいと判断するかに表れる。

何をやるかを決めることも大事です。
しかし、実務では必ず、何をやらないか、何を省略するか、どこまで軽量化するかを判断する場面があります。

その時に、判断理由を説明できるか。
省略したリスクを補完できるか。
それをレビューできるか。

ここに、良い思考が組織活動になっているかどうかが表れるのではないかと思います。

この連載の全体像はこちら：
車載ソフトウェア品質保証を考える：連載まとめ