00:00
はい、kameiです。 yykamei's Podcastやってきます。 今回はモブプログラミングについて喋ってみようと思います。
先日、Kaigi on Railsというイベント、 カンファレンスに参加してきました。
Kaigi on Railsって何かというと、 開発者向けのイベントですね。
Rubyというプログラミング言語があって、 そのRubyを使ったライブラリ、
フレームワークのRuby on Railsというものがあります。 それをベースにしたテーマにしたイベントになっています。
そこのKaigi on Railsで見たセッションの中に、 ペアプログラミング、モブプログラミングをやるみたいなのがありまして、
それを見てかなり驚きを覚えました。
タイトルは、
ペアプロしようぜ!3人で登壇! 楽しくて早いペアプロモブプロ開発というものですね。
このモブプロ、3人でやるんですけど、 そもそもモブプロって何って話ですよね。
モブプログラミングっていうのは、 プログラミングを複数人でやろうというものになります。
なんでこれ複数人でやった方がいいのかというと、 諸説あるというか、いろいろな主張があるんですけど、
いくつか見た中で言うと、
プログラミングをするにあたって、こういうやり方でやるとか、 こういう方針でやるみたいなのってあると思うんですけど、
それを1人で書いた後に、その成果物を実際に、
動いているサービスに反映させていくっていう時に、 だいたいレビューっていうものが発生するんですよね。
そのレビューっていうものをやると、
もうちょっとここ直した方がいいんじゃないか、 みたいなのが出てくるんですけど、
開発をしてからレビューになるまでに、 結構な時間が経つと、
ちょっとストレスですよね。 例えばもうすでに開発というか実装がプログラミング終わっているのに、
後でレビューでここ直してくださいって、 なんかちょっと面倒くさいというか、思い出す作業もありますし、
なかなか実際に動いているサービスに反映っていうのができずに、
ちょっとモヤモヤする体験になるかなというのが一般的なものなんですけど、 それをもうそもそも、
03:05
開発段階からやっちゃえばいいじゃんと。 出た時に、なんならもうプログラミングをみんなでやれば良くないと。
そうしたらレビューとかもその場で言えばいいよねということが、
MOVプログラミングで
できるメリットかなと。他にもいろいろあるんですけど、 私が思っている目立ったメリットはそんなところです。
要するに、レビューをもう開発段階からやっちゃおうよと。
そのMOVプログラミングで結構重要なポイントがあって、
キーボードでプログラミングする人と、それを指示する人みたいな役割が分かれるんですよね。
これが役割を分かれることによって結構良いメリットがあって、
例えば
指示をする人は、うまく言語化をしないとちゃんとした指示が出せないんですよね。
指示って言っても本当に細かい指示じゃなくて、ザックバラに何とかっていうものを書いてくださいみたいな、そのレベルなんですけど、その何とかっていうものを
ちゃんと言語化ができる、むしろ言語化できないんだったらそれは
しっかりした構造になってない、しっかりしたロジックになってないということなので、実はあんまり良くなかったりする。
言語化するっていうのは、つまり他の人にも伝わるっていうことなので、誰かが思っている人の知識っていうのが他の人にも伝わる。
それに対してすぐさま別の人が、それはこうの方がいいんじゃないかとか、それはいいねとか、
ポジティブだったりネガティブだったり、フィードバックをすぐに与えることができる。 これがすごくいいんですよね。
モブプロの説明をしてきてきたわけですけど、そういったようなメリット、他にもいろいろある中をこの開業レールズの
ペアプロ使用税のセッションでは、しっかり伝えてくれまして、そしてさらに注目すべきは
後半で モブプロのライブコーディングをするっていうのをやったんですよね。
ライブコーディングって何かというと、あの登壇で その場でプログラミングをするみたいなやつなんですけど
あの結構、大きめのイベントとかでもよくやられていると思うんですよね。
ちょっと私出たことないですけど、AppleのWWDCとかそういうやつですか、でも結構やってたりするらしいんですけど
06:00
ライブコーディングって本当にプログラミングをするので何が起こるかわかんなくて、みんなすごくしっかりリハーサルするんですけどそれでも怖いものかなと思っています。
そんな中で このセッションではライブコーディングをモブプロでやると、つまり3人でライブコーディングするというのがありました。
個人的には それ相当すごいなって思ってまして、今まであんまりその3人で
ライブコーディングする、モブプロでライブコーディングするっていうのを見たことがなくて、もう本当に驚きました。
たぶん会議オンレールズっていずれ YouTubeか何かに動画が配信されると思うので、ぜひとも見ていただきたいなとは思うんですけど
ネタバレすると、モブプロで
あるタスクの作業をやり切ったんですよ。
本当にやり切った瞬間感動しました。ちなみにあのモブプロでは、さっき言った指示をする人、指示を受けてタイピングする人
大まかに分けてこの2種類。他にも、例えば指示を与えないけど、指示をする人をサポートしたり、なんとなく
第三者的な立ち位置の人みたいな役割もあるんですけど、大まかにさっき言った指示と指示を受けるですね。
その役割って、タイマーとかを使って
交代するんですね。 10分とか15分とかそれぞれそれはチームによって異なるんですけど、今回は
セッションの都合なのか、これぐらいでいけるだろうってことなのかわかりませんけど、タイマーを11分にセットして
モブプロの1役割、交代をする瞬間まではないんですけど、
1セッションって言った方がいいかな。それを11分でやって、11分の中で
最初に、じゃあ今回は我々はこのタスクやっていくぞ、この方針でやっていくぞ、みたいなことを決めて
実際に実装に移って
開発ですね。
開発したものがテストして通るところまでやったと。
開発者には馴染みがあるワードですけど、TDDっていうテストドリブンデベロップメントか、
09:09
テスト駆動開発っていう手法がありまして、何かっていうと最初にテストを書いて、それがエラーになる
ことを確認して、それが通る、テストがパスするようにコーディングをする。
テストがパスしたら、さらにリファクタリングをして、テストが通りつつも綺麗なコードにするみたいな手法があるんですけど、
このモブプロのライブコーディングのセッションでは何も言わずにTDDをやっていて、それも素晴らしいなと。
ちなみにTDDがみんな当たり前のようにやってるかって言うと、多分そうではなくて、
別にそれが正解でもないから、必ずしもTDD正義ってわけじゃないんですけど、
このモブプロのライブコーディングは
いろいろなものが詰まっているんですよね。本人たちも100分は一見にしかずやってみましょうっていう形でやってたんですけど、本当に100分は一見にしかずで
素晴らしいものでした。モブプロって結構これっていいのかなとか、あと他の人のモブプロを見るっていう機会が少ないと思ってるんですよね。
ハンターインダストリーズみたいな会社、ホールチームプログラミングみたいな本を出してる会社、 ちょっとすみませんちゃんとしたタイトルわかんないですけど、
見学していいよみたいな感じでやってたりするんですけど、日本でそんな会社なかなかなくて、そんな中でこういう登壇の場で、
我々のモブプロはこうだよってやってくれるのは本当に素晴らしいことで、それをやってのけたこの3人方は素晴らしいなっていうのを、
そうですね、語彙が少なくて申し訳ないんですが、とにかく素晴らしいという話です。
私の所属する会社もなんとなくモブプロで開発するぞっていうのが流行ってるというか、
だんだんみんなやり始めてきた感じなんですけど、やっぱりちょっとこれでいいんだっけみたいなのがどうもあって、
私結構興奮をしてまして、このモブプロライブコーディングが素晴らしすぎて、視聴会をやっちゃったんですね。
視聴会やってみたら、やっぱり結構いい反応が得られたんですよね。
こういう風にやってんだねとか、この最初の段階で方針決めするの素晴らしいですねみたいなのとか、
12:07
あともうなんでしょうね、そのライブコーディングじゃなくて前半のこのモブプロでよくおちりがちな罠みたいなところで、
指示出される側の人がなんかもう、つまりタイピングをする人ですね、もう一人でどんどん進んじゃうみたいなのとか、あるあるだよねーみたいな話をしたりして結構盛り上がりまして、
そうですね、こういってこの会議オンレールズが終わった後も視聴会で盛り上がれて、いやー本当に
嬉しいなーって思ってます。 モブプロがこう、正義というかモブプロが必ずしもいい
っていうのはやっぱ違うとは思うんですけど、なんでしょうね、さっき言ったその一人で開発するときの問題っていうのは全然今後もあると思うので
1回ぐらいは検討してもいいやっぱりソリューションな気はします。ソリューションというか手法な気はしますよね。
私自身もモブプロに関わっているんですけど、
最近そうですね、ちょっと
なんでしょうね、私が
見ているチームというかが、ちょっと一人のメンバーが一時的に抜けている状態、一時的なんですよね。だからその
穴埋めって言っちゃいい言い方悪いかもしれないですけど、
ヘルプ要員でそのモブのメンバーになったんですけど、なんかこう 私なりには結構真面目にやってたつもりはあったんですけど
その振る舞いがモブの一員として、なんて言ったらいいんでしょうね
主体的、そうですね、当事者意識がないようにどうも他のメンバーの方には感じられてしまったようで
そこのモヤモヤが発生しました。
そうですね、そうなんですよ、そういう難しさもあって
なんでそういったことが起こったんだろうなって分析してみると、そのメンバーの方にも言われたんですけど、 目標の共有みたいなのってが実は違う
私はヘルプ要員で入ったみたいな立ち位置もあって、私自身が今期というか
今目標にしているものってのがあって、実はそのモブのメンバーの中でも共有の共通のゴールみたいなのがあったんですね、そこを
15:07
実は私はそこまで終えてなくて
ゴールが共有されてないというか、私が見てなかった状態なんですよね
それは本当に良くなかったなって思いつつ
何言いたいかっていうと、モブって実はモブプログラミング、プログラミングってワイルドがついてますけど
プログラミングの現場だけの話じゃないんですよね
プログラミングをするにあたってのそのモブのメンバーによる共同作業なので
さっきの目標を共有するっていうのもそうですし、その他の作業ですよね
例えば問い合わせ対応が来たら、じゃあみんなで取り組むかみたいなのとか、あとはその今取り組んでいるタスク
を整理しようって言ったらみんなで整理しようなんですよね 私はそこをこれちょっと
わかりづらくないですかみたいな、言うだけだったんですよね まあそれは良くないよねという話になりました
まあだから端的に言えば当事者意識がなかったってことなんですよね
なんかまあそれを指摘受けた時は結構ショックを受けるわけですよね
でなんならいやーこんなにモブプロをしている自分は実はモブ
向いてないんじゃないかみたいな結構悩みました まあ結構悩んだんですけどさっき言った通り結局その私の思っているゴールっていうのは
違うしまあ当事者意識ないってそれは当事者意識ないんですよ だってただのヘルプ用意と私は思ってたわけですし
なのでまあ しょうがないというかそんなもんだなという気はしています
まあでもあれですねあの 私
なんか本当自分のチームっていうのが実はなくてその 一緒の一緒にモブやるメンバーっていうのがいないんですよね
まあ独りぼっちなんですよはい まあそれはいいんですけど
ちょっとあれですね会議オンレールズの ペアプロ仕様でのセッションから視聴会をやりそして私の反省に至るというところで
なりました 今回はそんなところですかね
はいそれでは今回は終わりにしたいと思います ありがとうございます
