モブプログラミングまとめ
モブプログラミングにメリットは感じられるが、モブプロをしないことと比べた場合のメリットを(現在は)上回っていないような気がしてきた。自分一人で作業をする機会を久しぶりに得たことで確信に変わったため、その点についてまとめた。 モブプロをやることによって期待していた成果
レビューをリアルタイムに行うことができるため、コードを書くことで価値を出せる人がレビューに追われることがなくなる、また、レビューの待ち時間がなくなる。
「設計が破綻していていたり欠陥があっても作業者は気づかずそのまま作業を勧めてしまい、作業をレビューに出して初めて設計の欠陥に気づいて作業時間が無駄になる」という現象を防げる
スキル格差を埋め、暗黙知を共有する教育的な成果が期待できる
やってみての実感
レビューをリアルタイムに行うことができるため、コードを書くことで価値を出せる人がレビューに追われることがなくなる、また、レビューの待ち時間がなくなる。
確かにリアルタイムで行うことができ、まとめてレビューする必要はなくなった。ただし、コードを書かずに価値を出せる人がレビューに追われることはなくなる一方で、スキル格差がある場合にスキル高い側はモブプロ中ほぼ常にレビューすることになる。これではスキル高い側の負担はあまり変わっていない。スキル高い側もドライバーになることがあるのであれば、「ほぼ常に」というのは嘘のように思えるかもしれないが、これは実感として間違いなくある。以下はその理由
スキル格差がある場合に、教育的な成果もモブプロの目標として求めてしまう。それが原因で、スキル高い側は本来あるべきコードまで段階的に成長するような開発をわざとする。なぜなら、開発のスキルや経験値の高い側が思い描いた適切な抽象化は、低い側にはなぜ必要なのかわからないからだ。だが、それを言語化して説明するとなかなか難しい。抽象化しない場合のコードとそれで困るケースのコードをを書いて見せてみるのはできるが、それもそれで時間がかかる。また、なぜ抽象化が必要なのかもわからないうちに階段を踏み飛ばして雑な抽象化をするクセがつくと困る。そのため、最初はわざと抽象化を抑え、手続き的なコードを書く、あるいは書かせる。そして、そのコードで困るときまで意図的に学習を遅延させる。ただ、そういったコードは適切に抽象化されていないため、汚いコードになる。これをモブプロ内で直すことにはなるのだが、最初から抽象化したコードを書く想定ができていた側からすれば二度手間だ。
コードを書いてもらったあと、あるいは途中で適切な方針、設計に切り替えてほしいときに、それが重要な設計変更であればあるほど口頭では伝わらない。実際にコードを書いてみないと伝わらないのだが、ほぼ完成しているコードをスキル高い側が書いてからでないと真意が伝わらない。これでは、スキル高い側がすべてコードを書いて、レビュイー側がそれを見たほうが生産性が高い。
「設計が破綻していていたり欠陥があっても作業者は気づかずそのまま作業を進めてしまい、作業をレビューに出して初めて設計の欠陥に気づいて作業時間が無駄になる」という現象を防げる
設計の破綻に早い段階で気づけるというのは実感できたが、上記の、わざと汚いコードを書く、あるいは書かせることで起きた設計の破綻もあった。また、モブプロのおかげで早い段階で気づけるようになったと考えていたときもあったが、冷静に考えるとそれは「おかげで」ではなく、単なる「きっかけ」であったような気がする。大事なのは「コードを健全に保つためには設計変更も手段として用いる」、「大きな設計変更の際に合意をとる」という文化だったのではないかと今考えたら思う。それの達成は常にモブプロをしなくてもできるだろう。
スキル格差を埋め、暗黙知を共有する教育的な成果が期待できる
ある意味では成功、ある意味では失敗した。まず、暗黙知の共有という点で言うと、プロダクト特有の知識、ドメイン知識や既存コードのクセなどの面ではかなりの成果があった。また、この成果に関してはスキルの格差はほぼ関係なく、平等にメリットがあった。
一方で、プロダクトによらないプログラミング自体や技術的な知識は、モブプロのおかげでなにかが成功したといえるものはほぼない。仮にあっても、モブプロをやっている期間で本人が自主的に成長した面のほうが大きいだろう。なぜなら、モブプロ内で対峙できる技術上の課題というのは、表面的な問題と根本的な問題が入り混じっているからだ。表面的な問題を解決するだけならモブプロ中に教えられる知識で足りるだろうが、根本的な問題については基礎技術についての理解とその応用が必要だからだ。基礎技術やその応用をモブプロ中に教えるのは範囲が広すぎて現実的ではない。(以前はこれもモブプロ中に教えることができる、と考えていた)また、モブプロをやっていると、自分で四苦八苦する経験を積む機会がなさすぎる。自分で自分のコードを評価し、試行錯誤や実験も交えて本質的な意味でより良いものにしていくという機会は必ず必要だ。モブプロ中にも、試行錯誤をする機会はないわけではないが、自発的なものではないか、自発的だが問題の対象が小さな問題だ。(例えば、変数の命名の見直しなど)
スキルの高い側について考えてみると、モブプロで得る技術的な知識やスキルはほぼ何もない。モブプロの方向性が前述の表面的な問題の解決のみに終始してしまうし、そうでないと開発スピードが許容できないほど遅くなるからだ。(開発スピードが遅くなる原因も同じく前述のわざと汚いコードを書く云々のため)
その他 モブプロをやりだしてから気づいた問題
何が問題なのかの共通認識がずれる
課題に対する解決法がわからず詰まってしまうとき、モブプロをやめて個々人の調査時間をとることがある。それ自体は良いのだが、調査の対象が正しく共有できていないことが目立った。例えば、「ライブラリXを用いて問題Yを解決したい。ライブラリXを用いたコードを書いて解決することはできるが、解決後に別の問題Zが出てきてしまう。どちらの問題も起こさずに解決できる方法を探したい」という趣旨の調査を始めたつもりが、片方では「ライブラリXを用いたコードを書いて問題Yが解決できない」というように伝わっていることがある。詳細は省くが、「ライブラリXを用いたコードで問題Yが解決できる」というのは自分の目から見れば明らかだった。問題の内容が正しく共有できていなかったのは、こうした詳しく説明できていなかったかもしれないし、そうではないかもしれない。ただ、スキル格差によってこのような問題も起きるということがわかった。
編集技術、方法の差で作業速度が遅くなる
テキスト編集方法に差があると、モブプロ中のコード編集に時間がかかる。完成形のコードとしてイメージしているものがお互い同じでも、テキストを編集する順番には個々のやり方がある。これは編集スキルの差も原因に含まれるが、それとは関係なく単純に完成形にたどり着くまでの脳内ルートがお互いに違うことが頻繁にある。このような状態のままモブプロを進めていると、先に書き始めた方に合わせるように自分の脳内ルートを修正しなければならないため、最速の作業速度にはならない。
ドキュメントを残さない場面が増える
リアルタイムで暗黙知の共有をしているため、ドキュメントが残らない。これは、必要なドキュメントを残そうという意思があったとしても起こる。ドキュメントの必要性を感じる場面が少ないからだ。XPの考え方からするとこれも必ずしも悪い状態ではないのかもしれないが、揮発性メモリの脳を持つ私にはコードを振り返ることがつらくなってしまった。
技術者個人への評価が難しくなる
チームの生産性が良かったとしても悪かったとしても、それに対して誰がどのようにどれくらい貢献しているのかを計ることは実質的に不可能。そのため、マネージャーというよりはチームメンバーからの評価が基準になるが、忖度や癒着、あるいは足の引っ張り合いが発生する可能性がある。これについてはモブプログラミングの課題(中間状態)でも記載した。 モブプロという手法に対して教条主義的、宗教的になってしまう
モブプロを試み始めてから数ヶ月は、作業速度などの問題があっても、モブプロのやり方に問題がある可能性があったため、モブプロという手法自体の問題を見ることが少なかった。これは新しい試みなので仕方ないが、モブプロに十分に慣れてきてからも、手法に対して批判的に振り返ることはなかった。モブプロであれば大丈夫、という半ば信仰のような状態になってしまった。これが一番良くないような気もする。
自分なりに出した結論
そもそも、スキル格差を埋めるというのは、企業として高スキル側に依存しすぎてしまわないように、属人性の排除、人材の冗長性の確保を目的としたものだろう。ただ、これを求めすぎるあまり生産性が欠如してしまっているのではないかというのが今の考えだ。今の状況と比べると、自分一人、あるいは少人数で裁量と責任をもってやったほうが圧倒的に速い。