モブワークして失敗した話

この記事は、モブプログラミング Advent Calendar 2018 19日目の記事です。
前日の記事はこちら

敬愛する先輩に煽られた紹介していただいたため、参加します。
駄記事かつおしゃれなリンク等つけれずすみません

アドベントカレンダー13日目
http://kdnakt.hatenablog.com/entry/2018/12/13/080000
上記記事のアンサーブログです。失敗した後輩とは僕のことです。

モブプロを導入して失敗した話を書きます。
導入方法から、失敗の考察までを少し行ったので、諸先輩方からのアドバイス、お待ちしております。

状況整理

行った人数

自分(6年目)と、自分のメンティー2人(配属1年未満と配属2ヶ月)

行った時間

1日2時間
1人のやつ1時間ずつ
3週間

仕事内容

新機能設計資料作成
機能カタログから機能デザイン

モブワーク以外でやったことを発表してもらい、
おかしい部分を修正、更に進めていく。

結果

3週間で私がギブアップ
→その後私が部署異動し自然消滅

発生した事象

(1) 海外にいる上司に、決まったことをひっくり返されることが多くあった
弊チームは海外に上司をもっており、その上司のレビューを通過して初めてそのタスク完了となる。
私の指摘と上司の指摘が違っており、メンティーを困惑させる自体が度々発生した
(これは私の能力不足)

(2) 私の進捗に著しい遅れが発生した

(3) 事象(1)の結果私の求心力がなくなり、事象(2)の結果私のモチベと評価が下がった

チーム内に、「あれ、この先輩、言ってること信用できなくね？」という空気が流れた(と思った)そしてちょっと私は自信をなくしたｗ
また、弊社はマネージャー以外に「後輩の教育」という評価観点がない。したがって、私の進捗遅れ=評価下がるとなる。したがって、後輩が良い教育を受けれるかどうかは先輩の力量と性質次第、という状態。

→結果、私の進捗と評価を取り戻すためモブワーク中断して自分のリカバリーをする、という自体に陥った。

考察など

良い点と悪い点があったのでいくつか考えていく。

こうすればよかったのでは、、

もう少しスモールスタートするべきだった

@radiocat さんの
ボーナスステージで実践するモブプログラミングのメリットとデメリット
のように、ボーナスステージで行うなど、最初は本業から一歩引いたところで行うべきだった気がする。

行う仕事を、もっと私にとってコントローラブルな仕事にするべきだった

※ここは先輩諸氏から意見ほしいところ
実際、完全わからん問題にあたって、これ辛いなぁ(ちょっと一人でじっくり考えて答え出したいなぁ)と思うことがあった。ファシリテーター(ここではメンターである僕にあたる)はすでにその答えについて知ってる(またはちょっと考えればわかる)状態であるべきなのかな、とおもった。

自分の仕事を減らすべきだった

自分はファシリテートや教育に集中する代わり、持ってる仕事を離すべきだったな、と思った。
または、先に終わらして、個人的ボーナスステージ範囲内でやるべきだったのかな、、？

上司の理解を得るべきだった

実際上司はモブプロに対して納得していない状態だったのも問題だったな、と感じた。
上司目線で見れば部下が急に「もぶぷろしたいっす！」とか言ってきて、しかも進捗に遅れを出し始める。
という状態だったのだろう、、、、
上司にも#モブプロはいいぞ を吹聴し、説得し、納得感もってはじめるべきだったな、、

上司をモブプロに参加させるべきだった

これ重要だっただろう気がする。。 @TAKAKING22 さんもモブプログラミングのよくある誤解で「モブプロはチーム全体で常に同期した状態をつくるのが良いこと」とおっしゃっていたので、意思決定者が参加していない時点でなにかおかしいことは確かなのだろう、、、
(TAKAKINGさん、間違ってたらすみません、ご指摘ください)

良かったこと

良かったこともあげておきます、

一応長く働いている私の仕事のやり方、思考順序や、実際の作業風景を後輩たちに見せれたのは彼らにとってプラスだった(よな？そうだよな？頼むぞ)

みんなでやるとチーム感あって楽しい

まとめ

モブプロはいいぞ。
ただ、ボーナスステージにスモールスタートで行うと多分さらにいいぞ。
意思決定者を参加させるといいぞ。
上司が納得してる状態でやるといいぞ。