モブプロをすぐに始められるチームとそうでないチームと子供達

こんにちはー!

こちらはモブプログラミング Advent Calendar 2019 - Qiitaの17日目の記事です。

 

qiita.com

 

私は最近、開発現場の支援をしていたりするのでモブプロを紹介することがちょいちょいあります。紹介というか実際に体験してもらうことが多いです。

体験まではあまり大差ないのですが、その1週間後に訪問した時に早速モブを開始しているチームとそうでないチームがあります。もうちょっというと、すぐに導入出来なかったチームは1ヶ月以上経っても始まることはない気がします。

その差について考えてみました。なんとなく「心理的安全性が〜」と言いたくなりますが、もうちょっと自分なりに考えてみようかな、というのがこの記事です。

あと最後に子供達についても書いてます。

 

最初に笹の考察

もうせっかちなので最初に自分の考えを書いちゃいます!

すぐに始められるチームとそうでないチームの差は「OutputとOutcome 大事なのはDOTCH」に差があると思います。もうちょっと言うとやっているビジネスに非常に強く影響されている気がします。

始めた上で効果的に活用できるチームとうまくいかないチームの差は「心理的安全性」や「多様性」にありそうです。

ということで、ここからは当たり前かもしれないことをつらつらと説明していくので、聞く必要がないと思った方はそっ閉じしてもらえればと。

 

体験会での初モブプロ

モブプロとの出会い方が違うから差が出ちゃうという説もありますが、体験会で話していることとやっていることは大体同じつもりです(受け取られ方は分かりませんが)。内容はTDDのよくあるお題(大抵はFizzBuzz自動販売機)をモブプロ+TDDで挑戦してもらうものです。cyber-dojoを使って、チームで好きな言語とテスティングフレームワークを選択してもらい、7分程度(5〜10分程度)でドライバーを変えながらコーディングしてもらいます。チームは4人くらいが多いです。

体験会終了後は「楽しかった」「新しい言語に挑戦できた」「初めてのテストコードだったがみんなのおかげで実装できた」など、ポジティブな意見が多く、実際に外から見ていてもワイワイガヤガヤ学びながら進めて「良い感じだなぁ」と思ったりしています。

 

体験会後のモブプロ活用

モブの第一印象は好感触。このまま発展するかのように見えましたが、その後のストーリーは大きく3つに分かれます(笹調べ)。

  1. すぐにモブプロを採用して効果的に活用している
  2. すぐにモブプロを採用したがうまく機能しない
  3. モブプロを開始できない

 

すぐにモブプロを採用して効果的に活用している

これはめっちゃハッピーなチームなので言うことはありません。やっぱりちょっと言わせてください。とても効果的だなぁと思うチームは「多様性」と「心理的安全性」が高いと思います。国籍や性別関係なく、メンバーそれぞれが異なる長所を活かし、率直に意見を言い合いながらスピーディーに判断・開発をしていく姿は見ていて気持ちが良いです。以上!

 

すぐにモブプロを採用したがうまく機能しない

こちらは1.とは結構違っていてメンバー間の関係が歪であることが多い気がします。リーダーらしき人が「誰も発言してくれない」とか「ずっと教え続けているのに全く成長してくれない」と悩んでいたりします。他のメンバーは「あの人の言うとおりにするのが良い」とか「なんか間違ったこと言うと怒られるんだよなぁ…」なんて思ってたりします。一言で言えばチームになってないってことだと思います。

そうなっている原因はたくさんあるんですが、特にそのドメインや技術に詳しいリーダー的存在が与える影響がかなり大きいと思います。HRTのある行動・佇まい・考え方を実践できるようになるとモブプロと言うかチーム開発が機能しだすと思います。(もちろんリーダーだけの話ではないです)

 

モブプロを開始できない

メンバー間の関係性で開始できないと言うよりは、もっと大いなる力が障壁になっていることが多い気がします。「お金」です。このビジネス上とってもとっても大事な「お金」の稼ぎ方の違いがモブプロを開始できるかに影響していると思います。

  • できるだけ工数をかけずに仕様通りのソフトを完成させることで利益を得る
  • ユーザーに価値あるソフトを作り上げ使用/購入してもらうことで利益を得る

モブプロは後者で非常に効果を発揮しますが、前者(受託開発とか)だと難しい場面が多いです。不向きであると言いたいのではなく、そもそも周りやマネージャーの承認を得るのが非常に難しいです。「ゴミでもいいからモノができれば良し!Output最高!」の場合、ソロ+マルチタスク(リソース効率MAX)で進める方が直感的にOutput量を増やせる気がします。Outputの増減については厳密に比較することがとても難しいです。また、実際はコードの品質と言うか、将来的なスピード・Outputについても考える必要がありますが、将来のことは断言できないので難しいです。

そうなるともっともらしい直感に対して理論的にモブプロを実施するメリットを説明できずに開始できません。また、そう言う状況で無理やりやったとしても、確執が生まれたり、たまたま失敗したときに責められたり、あまり良いことがありません。

実際に前職(受託開発の時)で初めてモブプロをやろうとした時に「モブプロとかやったら3倍工数かかっちゃうじゃん。ダメダメ!」とマネージャーに言われました。幸いにもリモート2名と私のチームだったのでskype経由でリモートモブをやることで目立たずやれました。めでたしめでたし。

Outputを最優先している組織では、まずはOutcomeを重視する考え方に切り替えていく必要がありますが、そのためには「お金の稼ぎ方」を変えていく必要があると思います。そうなると何度か年越しするくらいの長期戦を覚悟した方が良いかもしれません。

また、全面的にモブプロ宣言してやらなくても良いわけで、「問題が発生したときにしれっとやってみる」といった方法もあります。まずはポイントを選んでやるのが良い気がします。

 

急ですがうちの子供達の場合

うちには4歳の息子と7歳の娘がいます。更に6歳の甥っ子、9歳の姪っ子がいます。よく遊びに来るので4人で遊ぶことがあります。この頃はNintendo Switchで遊ぶことが多いです。ちなみに私は息子と一緒にポケモンソード&シールドをやっています。

それは置いといて子供に戻ります。子供4人集まってSwitchをやるとなった時にマリオパーティーよりもマリオメーカー2をやっていることが多いです。コントローラーを持つのは1人ですが、2,3人がそれを見ながら「それだと簡単すぎる!」「ここにコクッパを置こう!」「それじゃクリアできないよ!」なんてことを言っています。甥っ子姪っ子は操作方法についてあまり詳しくないので「マグマをここまで上げるにはどうするの?」とか「クリア条件ってどうやって設定するの?」とか聞くことがあります。聞くと娘がコントローラーを受け取り設定してあげます。それでみんながやり方を覚えます。そんなこんなしていると「天才ゲーマーのお父さんにクリアできないコースを作ろう」とか壮大なビジョンも完成します。「この仕掛けってどう動くのかな?」と軽く試してみたり「一回この部分だけ進めるか試してみよう」とか言いながら怪しい箇所は単体テストもしています。(まぁ実際は「次は自分が作りたい!」とかいざこざもあるわけですが)

最終的に、難しくしすぎて子供達自身ではクリア出来ず、クリアできるか分からないただただ難しいものが私の元にデリバリーされるわけです。しかし天才ゲーマーである私はそれを華麗にクリアします。大体何かの考慮が漏れていて、例えば壁けりしてからプロペラを使うと越えれない予定の壁を越えれちゃったりするのでそういうのを利用します。するとそれを見ていた子供達は「ずるーい!もっと壁高くしよう!」とか言いながら、なぜか壁以外にめっちゃテレサを配置したりします。そしてすぐに自分のところに持ってきてクリアできなくなるまで調整ループが繰り返されます。

エンドユーザーである私の要求は「ギリギリクリアできるコース」なんですが、それを無視している以外は非常に良い開発だなぁと思って見ています。作り手は一つのビジョンに向かって年齢など関係なく意見を出しあっています。結果として色んなアイデアの検討・試行・採用・修正が行われます。分からない時は分かる人がやってみせ、今後は誰でもできるようになります。ある程度できたところでユーザーフィードバックをもらいにきます。そこで気付いたことはすぐに対応します。

 

まとめ

すぐに始められないチーム・組織に共通していることは「時間あたりのOutput量を最大にしなければならないという考え」だと思います。もうちょっと言うと「Output量と利益が比例するビジネス」にありそうです。

と、それっぽくモブプロをやれる理由/やれない理由とかを考えてきましたが、子供の行動を見ていると、人は難しい課題に対してモブ的に対応するという本能があるように思えます。教えてもないのに勝手にそうするので。

理由とか固定概念とか忘れて、素直に課題に向き合って素直に開発していきたいものですね!

 

次回

chiemi_wtnbさんの「ろうの学生たちとモブプロしようとしてる話」です。あまり馴染みのない領域なので気になります!