モブプロのすすめ - チーム円満
モブプロとは？
モブプログラミング(以降モブプロ)とは複数のチームメンバーが1つのタスクに取り組む手法です。 一人の「ドライバー」と複数の「ナビゲーター」が協力してコードを書きます。
モブプロのメリットは品質の向上と知識共有にあります。 複数人が集まってコードを作成することで、バグやミスを早期に発見し修正することができます。また、参加者間でのアイデアやベストプラクティスの共有が促進され、チーム全体のスキルレベルが向上します。
ですが、モブプロの詳細についてはまた改めて解説したいと思います。 今回伝えたいのは「なぜモブプロをすすめるのか」についてです。
ここからはあくまでも書いてる人の見解です。参考程度に読んでいただければ幸いです。
なぜ、モブプロをすすめるのか？
プロジェクトを円滑にすすめるにはチームワークが極めて重要だと実感したから
です。
長い間エンジニアをしていると、良かったプロジェクトもあれば悪かったプロジェクトもあります。 その悪かったプロジェクトはチームワークも悪く、問題が起こると誰かが悪者になりがちでした。
自分がマネージャーやリーダーの立場になるときはそうならないようにしようと思いました。
では良いチームワークってどんなもの？
スポーツのほうがイメージしやすい(はず)。 ラグビーで流行った「ONE TEAM」だったり、野球でのエラーやミス時のフォローといったものです。
そもそもスポーツは相手がエラーやミスをすることで得点が入るものが多く、 ミスを誘発させているとも言えます。 裏を返せば誰でもミスをするものであり、そこをいちいち責めたり責められたりしていてはチームワークが良くなるはずもありません。
進捗の遅れなど、原因追求に長々と打ち合わせをする現場をいくつも見てきましたが、犯罪者を断罪するような現場ではおいそれと遅れ報告ができなくなるので、 問題が顕著化したときには炎上直前なんてこともありました。
つまり、順番として大事なのは
- ミスしてもフォローする。ドンマイと声をかける。責めない。
- その後でどうすればミスが減らせるかを"チーム全員で考える"
の順です。 まずは「ドンマイ」といってフォローしあえるチームを目指したい。
モブプロの反対 > ソロプロの実情
思えばこのIT業界がヘンなのです(個人的な感想)
プログラム言語、フロントエンドの経験などを評価されてメンバーになったりしますが、 アサインされると業務知識とこれまでの経緯がかかれたドキュメントを渡させて、即実戦投入。
なのでSES社員だったときは新規プロジェクト参画時はとても憂鬱でした。
ではほかの業界は？
だけど、これが消防士や医者であればありえない。 トレーニングを積んだからといって、いきなり火事の現場に一人では行かせないし、 医者に至っては何年も先輩といっしょに経験を積む必要があります。
高度な技術が必要だったり、危険な職場であればこれが至極当然です。
ではITエンジニアはどうかというと、文化なのか「ひとりでタスクを消化する」が当たり前なのです。 「隣にいつでもいるから遠慮なく聞いてね」という現場にあったことはありません。
だからモブプロ
モブプロを知ってからは、これが普通であり日常にあるべきだと思いました。
まずはチームで取り組み、メンバー全員で意識を合わせて共に解決する。 全員の合意がとれたらタスク終了 = レビューも終了 = モブも終了。
実に合理的。
もちろん、モブプロが銀の弾丸ではないので、すべてを解決する手法ではないけど、 スタートをモブ、その後ソロにするかどうするかはモブで決めればいいし、適宜開催でもOK。
要はチームワークが大事で、モブプロはその一つの手法だということが共感してもらえると嬉しい。