説明・説得コストについてアレコレ考えたこと
TL;DR
- 払うべき説明・説得コストと、払うべきでない説明・説得コストが存在する
- 払うべき説明・説得コストとは、その行為によって期待する成果
- (積極的に) 払うべきでない、もしくは説明の方向性を逆転すべき説明・説得コストは、下記の通りだと考えている
- 説明される側の、本来職種として持つべき知識の明らかな不足によるもの
- 説明される側の、間違った先入観に基づく一方的な心理的抵抗によるもの
- マネージャーとして、メンバーから説明を受けるときは下記項目を注意する
- 今受けている説明コストは、本来メンバーが支払うべきものか
- メンバーが支払うべきである場合
- 何故にメンバーが支払うべきで、その説明を受け自分はどのようなアクションをするか、そのためにどこまでの品質を求めるのか
- 上記項目が確実にメンバーに伝わっているか
- マネージャーとして、払うべきでない説明・説得コストを支払っているシーンを見たら下記の対策を検討する
- 説明の方向性を逆にする
- なぜその変化が必要なのか。ではなく、なぜ変化を必要としないのか。
- 職種ごとに必要とされる知識の種類と深さについて明文化する
- 学習の工数を確保し、読書会等での業務時間内での学習を奨励する
- 予算を確保し、説明コスト支払われる側の人に、外部の研修を受講してもらう
- 説明の方向性を逆にする
- 説明・説得コストの削減、方向の変更、偏りの是正は、マネージャーとして最も重要な仕事の1つである
- 大抵のケースにおいて、説明・説得コストを払う人は特定の個人に偏る
- 説明・説得コストが特定個人に偏ってしまったチームは成長しなくなる
- 故に、チームが健全に成長していく上で、説明・説得コストの偏りは是正しなければならない
はじめに
- 組織、チームで仕事をしている以上、我々は常に変化の中にいる
- 自分が主体的に変化を促す側になることもあれば、変化を受け入れる側になることもある
- 変化を促すときは、相手の状況に合わせて適切なアプローチをしたいし
- 変化を受け入れるときは、自分の現在地を理解して、適切なフォロワーシップを取りたい
- 変化が起こるとき、そこには説明・説得コストが存在する
- 「エンジニアリング組織論への招待」の著者である広木大地さんが 「Developer eXperience Day CTO/VPoE Conference 2021」 にて、下記のような話をされている
でも組織の文化としてソフトウェア作りが定着する前に、日本の大きな企業や行政機関は、いろいろなものをユーザー企業が丸投げしてしまったりするので、このノウハウが消失してしまいます。ソフトウェアを作ることが、どういうことなのかを理解する間もなく、徐々に消えていってしまう。 一方で、いい文化資本が蓄積する企業や、ソフトウェアエンジニアリングの文化資本、開発者体験を高めていくさまざまな工夫がどんどん蓄積していく環境の会社には就職したいと思ったり、自分のスキルアップになるんじゃないかと思うエンジニアが多い。そうじゃない会社は不遇な目に合うかもしれないし、嫌な思いをするかもしれないので、就職するのは止めておこうという気持ちになったりします。 こういった差が生まれるのは、文化資本の獲得をする際に、説明・説得に費やされるコストの差が、やはり大きいのではないかなと思っています。当たり前のように自動テストを書くことが習慣になっている会社と、「なんでそれをやらないといけないの? CI のツールはなんでそれを使わないといけないの?」と、いちいち説明・説得に費やされるコストがかかる会社は、なかなか定着していきません。
- つまり、マネージャーとしては、不当に説明・説得コストが高い状況があれば是正しなければならない
説明/説得コストの分解
構成要素
- 知識も経験もあり、抵抗もない。というケースは説明/説得コストは極小である
- 知識としてはあるが経験がなく、心理的抵抗もない。というケースは説明・説得コストは少ない
- 知識も経験もなく、心理的抵抗も大きい。という状況が最も説明・説得コストが高くなる
- ※ 間違ったやり方の経験だけあり、それによって心理的抵抗が極めて高い状態は除く
- 説明/説得コストを敢えて計算式で表現するならこんな感じか
説明・説得コストを払っていく
- 心理的抵抗が少ないチームであれば、説明・説得コストの削減は難しくない
- 知識がないのであれば、下記のような対応が検討できる
- 職種ごとに必要とされる知識の種類と深さについて明文化し、読書会等での業務時間内での学習を奨励する
- 予算を取得し、説明コスト支払われる側の人に、外部の研修を受講してもらう
- 経験がないのであれば、下記項目が検討される
- モブプログラミング等で、期限を決めて一緒に実験してみる ( 例: TDDとか )
- 経験者を呼んで、経験談を教えてもらう ( ハンガーフライトみたいなもの )
- 大変なのは心理的抵抗が高い状態
- 特に「知識も経験もないが、心理的抵抗が高くチームとしてのINPUTも出来ていない」状態がやっかい
マネージャーとして説明・説得コストに関して気を払うこと
チームの学習機会の観点から
- 説明・説得コストについて、説明の方向、頻度、分量については、注意が必要である
- マネージャーは、下記のようなケースを見かけたら、特に意識して観察する必要がある
- 例1: 自動テストを導入する上で、導入を推進する側が説明/説得コストを大量に払おうとしている
- 例2: フロントエンドエンジニアとテックリードのどちらが決めても良い内容を、毎回テックリードが決めて、周りに説明している。
- 例3: プロダクトオーナーとカスタマーサクセスのどちらが決めても良い内容を、毎回プロダクトオーナーが決めて、周りに説明している。
- 例4: Scrumについて知らないが、導入する必要がないと考えており、学習する気もない
- 例5: マイクロサービスについて知らないが、導入する必要がないと考えており、学習する気もない
- ※ 別にマイクロサービスを推奨する訳ではないが、自分で学び、経験してもいないのに、判断を下すのは時期尚早である
- それは説明・説得する側に回る人間のストレスを減らすためであり
- 説明・説得される側の人間の、学習機会の損失や主体性の欠如を避けるためでもある
期待値の観点から
- 誰が払うべき説明コストなのかを明確にする
- ドラッガー風エクササイズなどを実行する
- 何が理由で、誰が、何を、どこまで説明する必要があるのか明確にする
- とくに「どこまで」の部分が難しいが、ここをやりきることが大切だと感じてる
蛇足
やってみせ、言って聞かせて、させてみせ、ほめてやらねば、人は動かじ。 話し合い、耳を傾け、承認し、任せてやらねば、人は育たず。 やっている、姿を感謝で見守って、信頼せねば、人は実らず。 山本五十六
やってみせ、言って聞かせて
が知識のINPUTさせてみせ
が経験のINPUTほめてやらねば
が心理的抵抗の除外に結びつく