隣の芝駆動組織開発「よそがやってる良さそうな施策をなんとなくやる」からの脱却。検証と妥当性確認とは？
こんにちわ。従業員体験( EX ) の向上がミッションのエンジニアリング統括室に所属しているてぃーびーです。
私達のチームは開発バックグラウンドを持ったメンバーで構成されています。そういった経緯もあり、チームの Value の一つに「 開発者としての目線を持ち、ノウハウを活用していく 」という項目を掲げています。今回はこの視点から組織開発における検証と妥当性確認について考えます。
組織開発においてはソフトウェア開発に比べて成果物の仕上がりや、それがもたらす効果に対して曖昧に扱うケースが珍しくないでしょう。
例えば
- たぶんこれをやると効果がある / どのような問題をどのように解決するか決まっていない
- こんな感じで実現しよう。たぶん実現できたっぽい / 完成条件が定まっていない
- たぶん良い成果がでてるよ / 要求を実現した状態が定義されていない。また、成果を確認していない
- もっと厳密に？大丈夫、 PDCA まわすから / 実際は改善を回さない
という塩梅です。これらの発生源としてありがちなのが隣の芝駆動組織開発です。「有名なあの企業がこれをやっているから、うちもやろう」そんな鶴のひとこえが上から降りてきて、組織開発の担当が断りきれずに言われるがままに実施。問題が明確ではないので、現場からの反発を受けつつ、上からの声なので止められない。実施を終えてみたが、果たしてこの施策は何を解決したのだろう？そんなケースです。優れた施策を模倣すること自体は省エネでよいことですが、あくまで解決が必要な問題にハマったときにかぎります。隣の芝だけではなく、解決策を提供する SaaS の営業なども How の売り込み部分がキラキラして目にうつりがちで、つい問題を確認する前に解決策に飛びついてしまうこともあるでしょう。
組織開発の施策は全社や組織内の大きな塊に対して実施されるもので、その影響度は非常に大きく、このような曖昧なスタンスではつぎ込んだ各種リソースをドブに捨てるようなものです。そこで、検証と妥当性確認が大切になってくるわけです。
検証と妥当性確認とは？
検証 - Verifications
検証は対象の成果物が基準を満たしているか確認することです。 検証を行うためには、対象の成果物の完成定義を固める必要があります。
妥当性確認 - Validations
妥当性確認は成果物によって、その対象となる要求が満たされたか確認することです。 妥当性確認のためには、対象の要求が満たされたと判断される基準を固める必要があります。
実例
検証
カジュアル面談の立ち位置を事前に説明する資料を作成する。 資料は、
- URL で外部から閲覧可能であること
- カジュアル面談の立ち位置が明確に記載されていること
を満たせば完成とする。
資料が完成したら検証として、上記の観点を確認することになります。
妥当性確認
カジュアル面談は固まった定義がなく、求人企業・転職活動をする候補者の双方ともに認識がずれやすいものになっている。認識齟齬を避けるため、カジュアル面談の立ち位置を事前に説明する必要がある。そのために資料を作成する。
資料作成の結果として
- カジュアル面談の認識が齟齬なく伝わる
を満たせば要求を充足したことになります。
資料が完成したら、運用に組み込んで要求が満たされたことを確認することになります。
例外
基本的には検証と妥当性確認を明確にしたほうが好ましいと思いますが、例えば妥当性確認のコストが高い割に「誰がどうみてもやれば効果がある」と見込まれている施策に関しては、意図的に妥当性確認をスキップするのもありでしょう。
まとめ
組織施策は実施、運用、影響範囲に関してとても高いお買い物です。無駄なお買い物にしないためにも、しっかりと検証と妥当性確認をするのが好ましいでしょう。それらをするためには、そもそもなんの問題を扱っているかを明確にし、問題が解決した状態の定義を明確にし、そのための解決策の完成状態の定義も明確にする必要がでてくるでしょう。
