QAに限らず、イネイブリング活動する場合は待ちではなく自分から動かないとな、という話です。

たとえばこのブログでもたびたび話題にしている「イネイブリングQA」、つまり開発者に対してQA活動の一部を担うためのスキル伝達などを行う場合を考えてみます。

開発者が普段の業務の中で、レビューやテストなどを行う機会はあります。中には「うまくいかないな」となんとなくモヤッとしている方もいるかも知れません。

しかし

  • 開発者が自分（たち）の品質に関する困りごとや課題を自覚し、
  • それを適切に言語化したうえで、
  • イネイブリングQAに「＊＊ができるようになりたいから手伝って！」と頼んでくる

という状況は、ほぼ起こり得ないのではないか、と考えています。

タイトルにも書いたように、「イネイブられたい！来て！」と思っている開発者はたぶん居ないのです。

多くの場合なんとなくモヤッとしていながらも、日々の業務に追われて改善アクションを起こせなかったり、課題感を適切に言語化できるほど品質に関するナレッジを持っていなかったりして、しかるべき相手に相談するまでは至らないはずです。

なので、イネイブリングQAが「お困りでしたらいつでもご相談くださいね！」というスタンスでは、イネイブリング活動は進みません。

そうではなくて、「＊＊で困ってないですか？」「こういう取り組みすると良くなりそうですよ」と、QAの側から見つけて・声をかけていく必要があります。

大事なポイントは

イネイブリング活動の対象としている相手が、改善や品質向上に関して強い「思い」や「願望」を持っているとは限らない。むしろ持っていない前提で動いたほうがいい。

ですね。

他に、イネイブリング活動するにあたってコーチングっぽくなってもダメなのかもなあとも考えています。

いわゆるコーチングについて特別詳しくはないのですが、イメージとしては伴走であったり、なにかコーチが意思決定してくれるわけではなく自分と向き合うお手伝いをしてくれる人、だと思っています。実際に自分がコーチングを受けたときはそのようなスタンスでした。

もしイネイブリングQAがコーチのように振る舞うと、「どこを改善したいですか？」「最終的にどうなりたいですか？」といった問いを相手に投げかけていくことになります。ただコレは開発者・チームにとってかなり負荷が高く、相当上手にやらないとただの厄介者になってしまうように思います。

開発者・開発チームに対して内発的動機づけを！という意見もわからなくはないのですが、イネイブリングの場合はある程度意思決定を肩代わりする部分も要るのではないでしょうか。組織での標準的なやり方を決めて展開する、などです。標準の展開もコレはコレで押し付けにならないようにバランスとる必要がありますが。

若干考えが発散したところもありますが・・・

イネイブリング活動のスタンスとして、相手にむやみに主体性を求めすぎず、ある程度イネイブリングQA側から「こうしましょう」という方向性や具体的な提案を出していくことが、組織全体を前に進めることに繋がるよね、という話でした。