Tbpgr Blog

Organization Development Engineer tbpgr(てぃーびー) のブログ

Sharain pair retrospective で同じ問題に対する解決力の差分を埋める

f:id:tbpg:20170620033918p:plain

Sharain を使ったペア振り返り = Sharain pair retrospective を実施しました。
業務中のものなので詳細はかけませんが、抽象的な記載で情報をまとめます。

手順

  1. 二人で同じ課題に対する思考・行動を詳細に書き出す
  2. diffをとる
  3. diffについて分析する
  4. diffを概念化、抽象化して改善に必要なスキルを把握する

単独で行う場合とちょっと手順が変わっています。
単独で実行した際の手順については下記にまとめてあります。

tbpgr.hatenablog.com

前提

Aさん・Bさんの二人で一つの問題に取組みます。

二人で同じ課題に対する思考・行動を詳細に書き出す

二人で思考・行動を書き出します。
必要に応じて、お互いに「どうしてそう考えたのですか?」などの質問を投げかけつつ
具体的な思考と手順を洗いだします。

diffをとる

お互いのアプローチのよいところ、失敗したところを明らかにします。

ペアの組み合わせごとに以下のようなメリットが考えられます。

ベテランと初心者だと一方が教え、一方が学ぶ形になることが多いでしょうし、
メンターとメンティーの関係なら、メンターがメンティーの考えを詳細に知るきっかけになるでしょうし、
実力が近ければアプローチの違いと言う形で相互に学ぶ機会となるでしょう。

diffについて分析する

diffについて分析します。

成功についてはどのように考えたらその成功にたどり着けるか、を明確にします。
失敗については何が原因を突き止め、次回成功するための手段を明らかにします。
双方のアプローチの違いについては、その考え方はどんな利点があるか、それぞれ明確にします。

diffを概念化、抽象化して改善に必要なスキルを把握する

成功や失敗の改善のための手法やアプローチの違いが抽象化できる場合に抽象化します。
パターン・ランゲージの形式で情報共有ツールに保存すると良いでしょう。

課題

片方が「失敗」とされる部分が多い場合にストレスがかかりやすい。
そういった面を軽減する施策があったほうが気持ちよく実施できそうですね、という意見をもらいました。

例えば、

  • この施策の手順のはじめに Sharain pair retrospective の目的を明確に伝える
  • 実施間隔を短くしすぎない
  • お互いに実施意欲があることを確認した上で行う

などのケアがあるとよさそうです。

このあたりは人の打たれ強さみたいなパラメータもありそうで、性格以外に過去の経験値もあると思います。
ズバッと指摘されることに慣れていない場合はちょっとずつならすことで耐久値を上げていく必要があるだろうと思います。
相手にとってここがラーニングゾーンであるかパニックゾーンであるか見極める、という話ですね。

逆に元から気にしないタイプもいると思いますので、結局は事前に相手のことをよく知っておくことが大切ですね。

※ラーニングゾーン・パニックゾーンに関しては下記記事を参照

empowerment-engineering.hatenablog.com

まとめ

たまたま同じ問題に取り組む機会があったので実施してみましたが、
これを行わなかったら発見出来なかったであろう点を複数発見できました。

例えば、

  • 何か問題が発生した
  • Aさんが解決できない
  • Bさんに助けをもとめる
  • Bさんがパパっと解決した
  • AさんはBさんが何を考え、どうやって解決し、自分が同じことをするには何をすればわからないまま

というようなことって、けっこうあるのではないでしょうか?

Sharain pair retrospective をすることによって
このような問題に遭遇するたびにAさんは成長することになるでしょう。

ちなみにこれを実施するためには「学習する余力」が必要です。
常に納期に追われてギリギリのチームでは試す余力がないでしょう。
ELASTIC LEADERSHIPでいうところの「サバイバルフェーズ」では難しい、ということですね。
ELASTIC LEADERSHIPについては下記記事を参照。

luccafort.hatenablog.com

おそらくペアプロをするときに気の利いたアドバイスで後輩を伸ばすことができる人は、
今回書き出したような内容を会話と頭の中のみで実施できているのでしょう。