タイトルは釣りです。すみません。
まぁあながち嘘ではなく解釈の問題だと思うが、事はかれこれ一ヶ月ほど前。
Rakuten Technology Conferenceでモブプロの話をちらっと聞き、噂には聞いてたけどこれ凄そうやな >>> でもうちのチームでできるかな？ >>> まぁやってみよ >>> やってみたら噂に違わず全員が効果を実感してちょっとのめり込みそうになったお話。
About Us
- 人数：チームリーダーの私含め5人（3人が東京、2人が福岡）
- チームロール：社内向け業務ツールの開発・運用その他
- プロダクト：ウェブアプリやライブラリなど10数個あり、全員で1つのプロダクトの開発というわけではなく、どちらかというとモブ向きではないかも。
- モブ経験：全員無し。ペアプロは何人かが嗜み程度に。
How to
まず午前中に30分位イントロダクションして、午後2時間かけてモビング、その後30分で振り返りをやった。
- メンバー：東京4名（マネージャー含む）＋福岡2名 別会議が入っていた2人はちょっと遅れて参戦
- ファシリティ：東京会議室＋モニター、福岡会議室＋モニター、各自のラップトップPC（交代時にコミット）
- ローテーション：ドライバー１、ナビゲーター１、ファシリテーター（マネージャー固定） １５分交替
- プロダクト：業務用ウェブアプリケーションのAPI
- 実装言語：Ruby
- フレームワーク：Rails
- 実装した機能: Git上にあるXMLファイルを取得、パースしてRubyのオブジェクトに変換するところまで
- お菓子：ブルボン詰め合わせ
withB - 飲み物：各自用意（ノンアル）
Before
イントロダクションとして、下記WEBに挙がってる資料を参考にさせていただき説明
- モブプログラミングという働き方 #DevLOVE // Speaker Deck
- モブプログラミングを実際にやってみた
- モブプログラミング - Woody Zuill氏とのインタビュー
- 技術なきマネジメントの衰退とその対策
その後各自ランチを済ませ、さぁやるか！の前に、初体験を目前にした気持ちを吐露してもらった。一度経験したらもう二度と味わえない貴重な瞬間の気持ちである。
以下、少し改変したがほぼ原文。多いが参考のためそのまま載せる。
- 期待してること
- ペアプロもしたことないし、他の人のスキルとか知識を吸収できれば成長できそう。
- ワクワクしています。楽しそうです。
- 日本でも流行って欲しい
- モブに大学の研究室的な雰囲気を感じました。
- レビューしなくていいの楽そう
- 興味があって気になっていたので、どんな感じになるか楽しみです
- 超興味あります
- 全員のスキルの底上げに繋がっていけそう。一度ではなく何度かトライしてみたい。
- (私) すごく面白そうでわくわくしてる
- 不安なこと
- どんな感じで進めるのか今時点でイメージがわいてない
- 常に誰かがしゃべり続けるって感じだと思うんでそこが最初どんな風に回るか。止まった時にどうしよ
- (私) リモートなので、NW遅延があると辛いなー
うかな - 話について行けなくなりそう
- 役に立てるように頑張りたい。
- 私が思ったことが言葉にでないかもしれない
- 私が伝えることが論理的・建設的ではないかもしれない
- 開発レベルの違いで参加できなくなっちゃう人がでないかどうか
- その他思うところ
- 日本人特有のどうぞどうぞの精神をなるべくなくす、積極的に参加する精神が重要？
- 分業のときは各自集中できるようにできるだけ人の邪魔をしないようにしていたのですが、協業のときはその真逆でどんどん話すことが結果につながると思う
- ある程度こなれてきたら効率面での効果はちゃんとトレースしたい
On Going
実装すべき機能は前述の通りシンプルなもので、ざっくり言えばクラス一つ、メソッドも一つでいけそうな感じ。
だけどこういうのは代替他の人が既に実装してたりで、意外と空では書けない。今回も最初はどのコアライブラリ使うんだっけ？というのを皆でググるところから始めた。
単純にただGitレポジトリにアクセスしてパースすりゃええんじゃろという空気の中、社内ツールその他のHTTPリクエストではありがちな、プロキシと認証の壁に阻まれた。そこを解決するのに皆の知恵が必要だった。
その過程で、httpクライアントに使うライブラリをアレからコレに変えてまたアレに戻した気がする。
シンプルに書けるとかエラーハンドリングがどうとかそういう理由だった気がするが、なんでそうなったかは覚えていないｗ でも皆で相談した結果、そうなった。それでいい。
そして適当に休憩とか各自トイレをはさみながら約2時間、紆余曲折しながらゴールが達成できた瞬間！（の後改めて撮影）
ヤッターを皆で共有できた！マンモスウレピーチョーキモチー
After
その後30分くらいとってKPT方式で振り返ってみた。
以下、少し改変したがほぼ原文。多いが参考のためそのまま載せる。
- Keep(Good)
- 各人のテクニックがふんだんにシェアされたり、技術の補足がされたりといい要素が見られた。
- 言葉で教えてもらっただけでは理解できないことを、実際にコードを書いて動くところまで見れたので理解が進んだ。例
reload!やRails.root.join('config', 'application.yml') - テストケースのレビューも同時進行でできるからそのあたりのレベル感も共有しながら統一認識が計れて良い。
- 規約や文化といったところも共通認識で作っていける。e.g)パスワードどうするんだっけ、とか
- RubyMineの使い方など、ちょっとした使い方を知れるのがいい（ディレクトリを一気に作れるとか）
- 思ったより全体的に積極的なナビゲート、意見交換ができていた。
- 各々のソリューションを試すことで、問題解決スピードが早かった
- 全員一致でその場でコードをFIX出来ていた
- スムーズにコードを書く人が入れ替われていた
- 途中参加の方がすぐに溶け込めていた気がする
- 自分が知らないテクニックを知ることができた (ex. RubyMine shortcut)
- 自分が知らない他の人の操作方法を見れるのがよい
- その場で実際の開発をしながら技術の共有ができる
- (私) 殆どの人が知らないことでも誰か一人は解を持っていることが多い。問題解決が圧倒的に早い
- (私) 会議室を確保できれば、リモートでも、全然いける
- (私) 毎日もしくは定期的にやりたい
- (私) 一人でも詳しい人がいればいけそう
- (私) 何度も（継続的に）やれば、加速度的にチームが成長し、開発スピードも早くなりそう
- (私) リアルタイムで知識の共有、合意形成ができる。レビューも不要。同時期に一つのプロダクトだけを開発してるチームはこれだけでもいいと思う。
- Problem
- Test code の簡単な作り方 なんかない？ by RubyMine
- リモートだと特にかもですが、Navigatorは指示を明確に（必要以上に丁寧なぐらいでいいのかも）何行目のどこどこ みたいな
- 発言が重なった時に、わたわたする。
- 盛り上がってきたところでタイムアップになる時、厳格に切るのか、少し延長するのかファリリテータの手腕の見せ所
- 程よくリフレッシュしないと全体のレビュー品質が落ちていくかも。
- 15分交代があっという間だったかも。
- 時々拠点間で声が届いていないときがあった。
- Driverが操作している時に、ソースが映された画面を指差して指示してしまいたくなる「ここ」が、伝わらない
- リモートだと指差しでの支持ができない（画面に指差しで支持したほうがやりやすい場合がある。）
- ローカルな会話と全体向けの会話の区別
- 詰まった時に何をすればいいのかわからなくなる。同じことを調べてしまっていることがあるのかも。でも、もしかしたら短時間で解決すれば、これは問題ではないかもしれませんが。
- 全体進捗がわかりづらい。このファンクションをどこまでに仕上げるのかみたいな。
- 交替は15分よりもう少し長い方がいいように感じた。初回で、操作が慣れてないことが原因かも。
- (私) コミットが、Driverのスイッチのタイミングになってしまったので、amend等を使って、理想的な単位でコミットしていった方がいい
- (私) 調べ物をするときに、Driverが画面を切り替え無い方がいい => ディスプレイいくつが望ましい？
- Try
- しばらくの間、ファシリテーター（とか）がメモ取りながらやってもいいのかも。KPTとかTIPSとか。
- test code はcodeと画面分割して書くとやりやすい
- test code は一番外から書くとやりやすい。＃人によるかも
- sprint 終了時に終わる見込みがない開発タスクは モブで解決。
- モブを拠点毎に分割
- コーディングはどこまで進んだかで区切ってローテーションしてもよさそう
- (私) Driverの切り替えタイミングではなく、コミットを細かい単位でしていったほうがいい。
Conclusion
実際、この機能自体は私一人でやれば30-60分くらいで実装できたと思う。ただ、それをチーム全員（＋今回はマネージャーも）で共有したことに大きな意味がある。言わずもがな、（チーム）開発というのはただ仕様を実装すればいいというものではなく、コードや知見を共有し改善し運用していくものだ。
今回、コードレビューはもはや必要無いし、リファクタリングをするまでもなく、既に（チームが理想とする）最もシンプルでメンテナビリティーの高いコードになっている。そしてそのことを皆が知っている。
噂に違わず目から鱗、確かな手応えがあった。そしてそれを6人全員が感じてたと思う。
そして、リモートでもビデオ通話と画面共有ができる環境があれば全然いける。普段からリモートワークやテレビ会議ができる職場や環境であればなんら問題ないだろう。
ただ、熱くなってくると身振り手振りとか「そこそこ」とか指差しで話たりしてしまうので、ヒートアップにはご注意を。まぁすぐに「え、なに？わかんない」と指摘が入ることになるがｗ
あと、会議室はできれば各拠点でおさえておいた方がいい。
上記、ひとまず最初の一歩、モブ初体験について書いてみた。リモートワークというのもあり少し最初のハードルは高かったが、チームが得た経験値と感動は大きかったと思う。論より証拠、未経験の方は是非やってみて下さい！
そして、その後チームで一ヶ月ほど継続しているので、明日は一ヶ月ほど続けてみて振り返った結果を書こうと思う。またアドベントカレンダーで公開するので良ければ読んで下さい。おしまい。