Mob Programmingのコストはどれぐらいかかるのだろうか?

simplearchitect.hatenablog.com

d.hatena.ne.jp

この「Mob Programming」というチーム運営面白いですね。チーム全員の意識を合わせるには、たくさんのイメージボードやイメージムービーを事前制作したり、個人ごとにたくさん雑談してお互いの考え方を共有しつつ、ペアプログラミングなどをベースにするのがベターかと思ってたので、ペアプロのさらに上があるとは目から鱗です。

普通5台のPCで5人が5つの担当モジュールを作ってそれをリードプログラマーが組み合わせていくみたいな手法を取るのが手っ取り早いのですが、Mob Programming は1台のPCを5人で使ってなんならプログラマーじゃない人も混じって意見を言いながらコードを書いて物ができていく手法。

そうすると開発速度は5分の1になってコストも5倍で非効率じゃないかと思うじゃないですか?

でも5つのモジュールを組み合わせた時、実際は多くのバグに悩まされたり、手戻りが発生したり、出来上がったものが実際に欲しいものと違うということおこったり、それは出来上がっていく過程で時代の流れが変わったり、ライバルが似たような商品出してきたり、そもそも最初の設計思想が間違ってたり、ちゃんと伝わってなかったりと理由は様々。そしてこれらを何とかするためにテストやら、レビューやら、いろんな情報共有システムとかが開発されてそこにもっと膨大なコストをかけてるのが現状なんですよね。

もし欲しかったものと違うものができても、現状できあがってしまった以上それを納品するか、無理やり運営でなんとかごまかしつつ、裏でなんとか修正作業するしかありません。その修正作業も土台から作り直さない限り、何か新しい機能を追加するたびずっと設計思想の負債としてコストが大きく膨らみ続けます。土台から作り直す場合再度大きな予算が必要です。

モブプログラミングではプログラマ以外の人も参加することで、出来上がっていくまえから目の前で意見や修正が入ることで、作ったあとから「それは違う」なんて言われずにすみます。本来のほしいものや設計思想が伝わらないこともなく、その時々の全員がもってる情報で修正が入る。テストもレビューも情報共有のコストも「みんなで1つをやればいいじゃん」でこの共有コストを限りなくゼロに近づける。そしてプログラマ全員の何気ないお互いの「暗黙知」を知ってる人と知らない人の差もここで発見されて埋まる。みんなでやるから知らない人にも教育効果が高いと。

コード書くのが5倍遅くなったとしても、製品開発で「コードを書く時間」よりは「コードを読んでチェックする時間」「仕様を修正する時間」のほうが本来ずっと長いわけで、長い方の時間を全員で短縮できるならより早く、より質の高い物を提供できる可能性はありそうです。

ただしMob Programmingを教育とか部分的な導入ではなく部署内で Mob が渡り歩くほど本格的に導入する問題といえば、これによる評価基準、給与査定をどうするかでしょうね。そもそも10倍優秀なプログラマーに10倍の給料を払ってるわけでもないでしょうけど、新しい評価基準をどう作ろうともどこからか文句がありそうです。今の体制や役職や評価、今上手くいってるやり方や今日までコストをかけてやってきたことをわざわざ変える必要がないでしょうし、MSの牛尾さんは日米比較しやすいMSだから危機感をもってるわけで、ブコメみると日本独特のSI構造がこのままそう変わることはないという見方が強そうですが、日本のSIと MobProgramming は分けて考えたほうがよさそうですね。

essaさんの記事でもこうあります。

二人でやるペアプログラミングでも、「それって一本のプログラムを二人で書くってことは、工数が二倍になるんじゃない？」って言われて言葉に詰まったことを思い出す。Mob Programming は、二倍じゃなくて数倍になるので、それを上回る生産性向上がどこから来るのか説明する必要がある。考えただけで頭が痛い。

そのお偉いさんが単純に考えてる工数は「コードを書くコスト」に1億円を払ってるかもしれませんが、実際には1億円から
「コードを書くコスト 2千万」
「(バグ)チェックコスト 4千万」
「情報共有コスト3千万」
「教育コスト 1千万」
「修正コスト 5千万」
にも分配されて、それだと5千万足りなくなるから仕様削った上でデスマーチになって、さらに追加予算もという状況もよく聞きます。実際にこれらは手を付けるまで目に見えてなかったコストなので数値で表せないのが難しい所。

Mob Programming だと確かに「コードをみんなで書くコストが 1億円」で通常の5倍かかりますが、「チェックコスト」「情報共有コスト」「教育コスト」「修正コスト」をみんなで同時に解決していくので、デスマーチになりにくく、チームも成長しやすく、予算内に収まり、当初の設計よりよい物ができますよ。。。と、いえたらいいですね。

チームで何かを達成するにあたって、目に見える開発コスト以外の、共有コスト、チェックコスト、教育コスト、修正コストは常に大きな悩みのタネです。共有しようにも教育しようにも修正しようにも、みんなめんどくさいし何かと忙しいので、共有情報書かない人書かないしアップしないし、例え書いてアップする人がいてもそれを見る人は限られてて、半数以上のメンバーは読みもしないし見もしないし聞く時間もありません。結果チームや開発の問題は個人個人のコミュニケーションエラーでバランスを欠いたままお互い足を引っ張り合い、いつまでもバグは解決せずチームとして成長しないこともあります。Mob Programming というチーム運営手法は、この見えないコストを軽減するよいヒントではないでしょうか?

スライドで他に気になるのは

「開発も"営業"もなんでもモブで行う」

「働き方としてのモブプログラミングを取り入れる」

です。
みんなで1人分の作業? に集中するのはいろいろ応用効くのでしょうか?

例えば4人で1枚の絵を意見出しながら描くとか、3Dモデルを作るとか意味ありますかね?

デジ絵の文法のように、他人の作業工程見るのはとても勉強になりますが、複数人で1枚の絵を描く場合の見えない教育コスト、修正コスト、質の高い完成度などは、どれだけ反映されるのかはかりかねないところです。イラストはある程度の指定イメージから、ラフ案を提出するはずですし、絵を描く所を見られたくない人も多いのでかなり価格の高いアート作品でもなければちょっとピンとこないですが。

この後「Mob Programming のデメリット」という体験者の記事とか出てくるとより判断しやすくなるのですが、さて、、