イネイブるとき、全体施策どーんとやるのと並行して、細かく「助かったわ〜」と思ってもらう場面を積み重ねるのも大事やなと
— Yoshiki Ito/伊藤由貴 (@yoshikiito) February 15, 2025
トップダウンとボトムアップ両面からイネイブリングしていくのが大事だなと、最近は考えています。
このブログのメインターゲットはQAエンジニアとその周辺の方々なので、QAや品質・ソフトウェアテストについてイネイブリングしていく、という文脈で話をします。
ボトムアップ
個人や個別の開発チームに対して貢献して、信頼を得つつイネイブリングしていく方法です。
たとえばQAがいきなり「テスト技法を身に着けてください!」と言っても受け入れてもらいにくいですよね。 そうではなくて「テスト設計してみたよ」という共有から入って、「このテスト整理されててわかりやすいっすね!」等の反応をもらってから「実はこれには技法があってね・・・」と進めていくほうがすんなり聞いてもらえます。
あとは探索的テストなど行ってクリティカルなバグを見つけたりすると、感謝されて信頼度がアップします。
トップダウン
ここで言っているトップダウンというのは、偉い人に意思決定してもらって組織に広めてもらう、という意味合いではありません。
開発組織や、複数チームまとめた広い範囲に対してルールや標準などを決めて「みなさんこれでお願いしますね」というやり方のことです。
もちろんここでは事前のネゴや、アイディアレベルで意見を聞いて進めるなど、「決めたので絶対守ってください」と強制するのは悪手です。
両方大事
ボトムアップだけだと、特に開発組織が大きい場合は変化のスピードがゆるやかになるので、マネージャー等から見てわかる成果がなかなか出なかったりします。もちろんそこで焦らずじっくりイネイブリングしていくのが大事なのですが、ゆっくりじっくりだけではQA組織の地盤がゆらぐこともあります。
その点トップダウンのほうが組織全体に影響を及ぼせますし、自分たちの思う理想の姿を素早く組織に広めることができます。が、それはあくまでもスムーズにいった場合の話。トップダウンは広く意見を聞きつつ進めないと反発を生むので注意が必要です。 反発をできるだけ少なくするためにも、ボトムアップでイネイブリングしながら信頼関係を構築して、そのうえでトップダウンの施策も行う、というのがきれいな形ではありますね。