ep.91 『今さら聞けないモブプログラミングのはじめかた・続けかた』 | UIT INSIDE

2021/07/09 に公開2286 views

このエピソードについて

@potato4d が @aloerina_ に、 LINE NEWS でのモブプログラミングの取り組みについて話を聞いてみました。

LINE NEWS のモブ状況紹介

3年前くらい前からスタート
- モブレビューという形で、みんなでコードをレビューするところから始まった
- その後モブプロという概念を知ったことで適用、今ではプログラミングに限らず広く実施
規模感
- いわゆる「モブプロ」は週イチくらい
- それとは別に、一緒にモブ的に仕事をすることは頻繁にある
- 取り組む人数は3~10人

モブプロの概要はこちらの記事を参照

モブ導入のモチベーション

レビューコストが高い
- レビュー内でコミュニケーションが多くなってきた
- みんなでレビューすると意図をその場で知れて良いのではないだろうか
- だんだんコーディングにも落とし込まれていった

運用しての所管

良かったこと

モブが手段として定着した
- 「ちょっとモブいいですか」が当たり前になった

課題感

型通りのモブプロがLINE NEWSのにとってベストではないと思った
結果的にエッセンスを取り入れる形に
現在ではモブプロはあまりしないが、モブワークとしていろんなものをモブで進めている

モブを自然に取り入れていく・続けていくコツは？

モブ以前の話だけど「ちょっと試してみましょう」の文化があるといい
「効率」という言葉に騙されない
- 機能がユーザーに届くまでにやる作業は「コードを書く」作業だけじゃない
- どこにどれだけ時間がかかっているか計測してみるといいかも、レビュー、手戻り等にけっこうかかってる
- モブレビューの経験から、モブすることでコミュニケーションの無駄や手戻りが減ることは体感できていた
続けるためのコツ
- 「だめな理由がないならしばらくお試し継続する」がチームに定着してた
- ルールに縛られない
  - モブプロではなく、モブワークのコツ
  - モブで集まったけど「この部分だけ各自で作業して15分後再集合しましょう」とかアリ
  - ドライバーとか決めなくてもいい。時間で交代しなくてもいい。目的だけ忘れないようにして、自分たちにとって効果的なモブを手探りすればいい。

モブが向いてる現場は？

3〜5人くらいがやりやすい
- 今まで1人、まはた2人で開発していて、これから3人になるってチームはチャンス
- 3人になると自分に見えないコミュニケーションが生まれる→齟齬が増えだす→徐々にずれていく
- そういうズレに気づくきっかけにもなる
モブが向いている作業は「人によって結果が変わる作業」や「結果に至ったプロセスを共有したい作業」
- 新規開発
- 環境構築(人によって起きる問題が違う)
- トラブル調査
モブが向いていない作業は「誰がやっても同じ結果になる作業」
- 軽微なバグ修正

Refs

LINE 新卒採用 2022
- https://linecorp.com/ja/career/newgrads/engineering/
キャリア採用はこちらから
- https://linecorp.com/ja/career/position/475
BGM&SE
- 魔王魂/騒音のない世界/OtoLogic

採用について

使用素材・クレジット

BGM&SE

音声書き起こし

1. オープニング 00:00

Guest 00:04
え。ユーザーインターフェースと、テクノロジーを愛する開発者のためのウィークリーポッドキャスト、いいテインサイド、今週も始めていきたいと思います。

Guest 00:13
今週はですねえ、LINEnewsの開発チームのえ、大槻さんをゲストにえ、モブプログラミングをテーマにえ、話していきたいと思います。

Guest 00:21
おつさんよろしくお願いいたします

Guest 00:23
はい、よろしくお願いします。

2. LINE NEWS のモブプログラミング 00:27

Guest 00:27
それではですねえ、早速本題に入っていきたいんですけど、おつきさんには、過去にえ、何度かyteサイドに出てもらったかなと思うんですけど。今回もLINEnewsの話として、

Guest 00:38
今日はモブプログラミングの話をえーしていただけるかなと思いますので、え、まずは簡単にLINEnewsでのモブプログラミングの活動の状況について教えていただいてもよろしいでしょうか。

Guest 00:49
はい、わかりました

Guest 00:51
もクロを始めたのは、3年ぐらい前になるんですけれど、もえ始めた時は、モグデビューっていう形でスタートしました。

Guest 01:00
何人かでと空いてるところは会議室に集まって、でprを見ながら

Guest 01:06
意見を出し合って、最終的にマージボタンを押すところまで持っていくみたいなことをしてました。

Guest 01:12
で、当時はそれがモブプロと呼ばれるものだってこともあんまりわかってなかったんですけれども、そこからもプロを調べて、レビューだけじゃなくて、行動を各部分もやっていこうっていうことで、モブプロの導入をしてみてから、最終的に今は

Guest 01:26
プログラミング以外のことも結構共同ですることが多いので、モグワークって呼んでるんですけれども、最終的にはモグワークするに至ってます。

Guest 01:34
で、大体3人から10人ぐらいの人数でやることが多いです。

Guest 01:40
てことは、もう結構今広くもプロのような概念をいろんな業務に取り入れてるっていう状態なんですね。はい、そうですね、

Guest 01:49
いや、まあ特に色々え共同でやってるかなと思うんですけど、いわゆるモクロっていうところでいうと、どれぐらいの頻度でやってますかね。

Guest 01:58
そうですね、最近だともうああ、結構まめにやってる

Guest 02:06
かなと思います。ちょっと実装で悩んだことがあった時に、スラック上で、今からもいいですか。って声かけて、集まれる人が集まって

Guest 02:15
じゃなくて、ペアになることもあるんですけど、ま、2人とか4人とか、そのぐらいの人数で集まって作るみたいなことは、1日1回以上は起きてるかなと思います。

Guest 02:25
で、それとは別でえ、チーム全員11人いるんですけど、みんなが集まってえ、モクロしようって決めてる時間もあって、それは週に1回、2時間の枠を取ってるんですけど、

Guest 02:36
そこはどちらかというと、プログラミングよりはデビューしたり。新しいことを試してみたりとか、

Guest 02:43
何かを決めたりだとか、ほんとにもワークとしてやってることが多いかなと思います。

Guest 02:50
いや、なんかあのいわゆるま手を動かす。まも、プログラミングみたいな作業は日常的に行われていて、ま。もっとそれを前提とした。何か新しい取り組みっていうのも、まあ、毎週時間

Guest 03:00
とってやってるっていう風な状況っていうとこですね。はい、そ

Guest 03:03
な感じです

Guest 03:05
じゃ、かなり活発にやってるっていうところだと思いますので、ちょっと後で詳しく、どんな風にやってるかっていうのを聞かせていただければと思います。はい

3. モブプログラミングについてのおさらい 03:15

Guest 03:15
えではですね、ちょっと具体的なLINEnewsでのモブの話を聞いていきたいかなと思っているんですけど、その前に聞いてくださっている方の中には、も、プログラミングっていうところについて、あまり馴染みがないって方もいらっしゃるかなと

Guest 03:29
思いますので、まず簡単にもプログラミングについて概要などいただいてもよろしいです。しょうか、

Guest 03:36
はい、そうですねモグプログラミングって呼ばれるものは、ドライバーと呼ばれるpcを触る人、マシンを触る11人と

Guest 03:45
あとは、発言をするナビゲーターって呼ばれる役割に分かれるかなと思います。で、ドライバーは、ナビゲーターの指示に従って、入力をしていく。

Guest 03:55
タイピングをする役割のような感じですね。やることが多いと思います時間は10分から15分ぐらいで、交代しながら

Guest 04:03
やっていくことが多いかなと思います。

Guest 04:07
なるほど、ま、基本的にまペアプログラミングをもう少し大人数でやるようなイメージっていうとこで、大体そうです。そういないかなってとこですよね。はい、

Guest 04:17
あくまでも、ドライバーと呼ばれる人は、ま手を動かすところが責任であって、まあ、周りの

Guest 04:23
あのナビゲーターにえ、相当する人たちが、どんどん知恵を出していくっていう風なスタイルで開発する手法っていうとこですよね。

Guest 04:31
はい

Guest 04:32
かいです、ありがとうございます。大体1回のサイクルとかって、平均的にはこれぐらいでみたいなのってありますかね。もプロ

Guest 04:40
そうですね、10分とかって言われることも多いんですけど、

Guest 04:43
僕らが始めた時は、15分とか20分とかとって始めました。結構こう短く区切るのって、それなりに難しくて、

Guest 04:51
慣れるまでは長めでとってもいいのかなと思って、20分とかでやってました。

Guest 04:55
なるほど、なるほど、

Guest 04:57
まえ特に慣れていくとどんどんえ、あの、短いサイクルでもできるようにはなるけれども、まあ、初めの方はちょっと長めにとってもいいっていうところ

Guest 05:04
ですかね。あったら、

Guest 05:07
ありがとうございます。その他のもプログラミングについての基本的な。知識だとか、インプット

Guest 05:14
いうところは、今回え、ゲストで出演いただいてる大槻さんが、個人のブログの方にもまとめているので、ちょっとスノートの方に貼っておこうかなと思いますので。え、皆様え、ぜひぜひ、そちらを

Guest 05:25
え3種類いただければと思います。

Guest 05:28
ありがとうございます

Guest 05:30
それではですね、ま、そんなえもプログラミングではありますけれども、今回LINEnewsにおいて、もう3年もモをえ導入してるっていうところかなと思いますので、ま、そもそもの導入のモチベーションとか。

4. モブ導入のモチベーション 05:31

Guest 05:44
どういう風に取り入れていったかっていうところを教えてもらってもよろしいでしょうか。

Guest 05:49
はい、そうですね、最初にもちらっと言ったんですけれど、も、まモブレビューから始まって、もに興味を持ってやっていくっていうことになりました。

Guest 05:57
モレビューをする前はま、各自がえ、自分のデスクでうんえ、チームメンバーprを見て、リクエストを見て、

Guest 06:07
判断をしていたんですけれども、その中でこう実装者に意図を聞きたい部分だったり。

Guest 06:14
自分はこう思うんだけど、チームメンバーはどう思うか、ディスカッションしたい部分とかは、結構あったんですね。

Guest 06:19
で、その辺を解消するために、集まってやると、その場で直接話して解決をしちゃうっていうことをやってみてま。それが思ったよりも、効率がいい、手戻りが減ったりだとか、コミュニケーションの無駄が減ったり、

Guest 06:33
例えば、そのリクエストにコメントつけたので、見てくださいって言って、見てもらうまでの待ち時間が減ったりとかですね。そういうのが

Guest 06:40
重なっていって、結構モで作業するっていいことなんじゃないかなってのが、モチベーションとしてはありました。ですね、で、

Guest 06:49
もクロは実際やってみたもの。さっき言った通りま、20分でやったりとか色々試してみたんですけど、結構大変で。

Guest 06:58
うん、集中力もすごくつか疲れたりだとか。あと、当時はどんな

Guest 07:03
種類の仕事がももには向いていて、向いていないかってことは判断できなかったのもあって、結構挫折も何度も

Guest 07:11
しながらだったんですけどもやっていくうちに、ま型にはまりすぎない、自分らにとっていいやり方っていうのが見えてきてま。それがだんだんモブワークっていう。肩にははまってないけれど、

Guest 07:23
みんなで集まって早く済ませられるものは、どんどん済ませていこうっていう形になって、定着していったのかなと思います。

Guest 07:31
なるほど、なるほど、じゃあ、結構元々モレビューっていうのを単純にそのなんでしょう。コミュニケーション、コストの削減みたいなところから始めていったのが

Guest 07:40
まも、プログラミングっていう概念に変わっていって、ただま、いわゆるもプログラミングっていうものよりも、まあもっとssを取り入れたモブワークっていうのが、

Guest 07:49
ニュースチームにとっては、ベストかな。っていうところで変わっていったっていうところですかね。

Guest 07:53
はい、そんな感じです。

Guest 07:55
ちなみに、このモブワークっていうのは、やっている業務としては、なんかいわゆるプログラミングや、レビュー以外っていうと、どういったものがあるんですかね。

Guest 08:05
ああ、そうですね、プログラミングレビュー以外だと、

Guest 08:14
なんか、ブレスタに近いようなアイデアを出し合う時間にすることもあれば。勉強会に近いような。ちょっとこれ、

Guest 08:24
このツール触ってみるんで、一緒に見てくれる人いますか。とかですかね、でも、それを行動を書くのって、プログラミングのか

Guest 08:33
とはいえ、まあ、いわゆるフィーチャーの実装みたいなもの以外、もま共同でやるものっていうのを。まあ、結構軸にまももプロのエッセンスを取り入れつつやってるって感じ

Guest 08:43
ですかね。

Guest 08:44
そうですね、なるほど、なるほど

Guest 08:47
いいですね、なんか、こう。あの、結構こういうのって

Guest 08:50
決まってる手法をまあ、真似たくなりがちですけど、いうまくアレンジして、今もワークとして、わしもワークとしてわしてるって感じよって感じですけど、っていう感じ

Guest 09:01
なんですね。そう

Guest 09:02
ですね、結構気軽にちょっとここ聞きた聞きたいんで、時間のある人来てくれますか。みたいなやりとりが多くて、なんでそれで集まったりだとか

Guest 09:12
が多いですかね。なので、もうほんとにもうボって意識せず、困ったことがあったら、すぐ何人かで集まるみたいなのが定着してる

Guest 09:21
感じかなあ、思います。

Guest 09:22
はいはいはいはい、なんかもはやそのそういった行為に、わざわざもプロという名前をつけるまでもない状態になってるって感じですかね。そうですね

Guest 09:32
ねえ、そんな感覚ですね

Guest 09:35
ま、なんか問題はみんなで解決するみたいなのが、ベースにあるっていう風な状態と言えるっていうとこですかね。はい、

Guest 09:44
それすごいいいですね。なんか、こう、自然とそういった流れが生まれてるってのは

Guest 09:49
そうですね。最初からなかなかそうはならなかったんですけど、だいぶ慣れてきて、そうなったところがあるかなと思います。

Guest 09:57
やっぱり初めはなんでしょうこう形式的というか、やっぱりモブプロの時間はいわゆるモブプログラミングをやるけど、それ以外はこれまでのマクロでみたいなところが多かったんですかね。

Guest 10:08
そうですね、始めた直後はほんとにそんな感じでした。

Guest 10:11
うん、なるほど、なるほど、まあモブの時間があるからモブをやろうぐらいで、別に文化として定着してるってわけでは、元々はなかったって感じ

Guest 10:20
そうですね。なんでこう僕のためにこう別の仕事を見つけてくるというか、僕の題材をあえて見つけてきて、試しにやってみて、

Guest 10:29
で、それとは別で、自分の各自の仕事は各地で進めてっていう感じだったので、

Guest 10:35
ま、時間に余裕がないともができないみたいな感覚だったんですよね。

Guest 10:39
ああ、はいはいはいはいけど、今

Guest 10:41
はその自分の持ってる仕事の一部を相談したいから、ちょっともういいですか。って聞く形になってきたので、ほんとに仕事の進め方の選択肢として、僕が定着するように、ま、今はなっただろうなって思います。

Guest 10:55
ま、ちょっと当初はあの始めた当初はまあ一方でちょっと投資の時間でもあったって感じですかね。そうですね、

Guest 11:04
でも、なんか結果として文化として定着したっていうのはいうこと考えると、ま十分ペしてるって言えるかなっていうとこですかね。

Guest 11:12
はい、そうですね、

Guest 11:13
ありがとうございます。結構分割して、定着していく中で、まあちょっと初めの方が定着しなかったみたいなのもあるかなと思うんですけど。

Guest 11:23
あくまでも今えから見た観点で言うと、今やっててよかったことを悪かったことみたいなのって、なんかモブとしてこういうものがありますっていうのってありますかね、

Guest 11:32
そうですね、ま、今改めて振り返って1番良かったなと思うのは、何度も言ってる通り、

Guest 11:40
こう、気軽にちょっといいですか。ってもの選択肢として、全員が捉えられるようになった。それが当たり前になったのが1番良かったことかなと思います。

Guest 11:51
なんかもって問題を解決する手段の1個でしかないので、ま、当然、その手段って、いろんなものが使えた方がいいと思うんですよね。なので、その1個が

Guest 12:00
チームメンバー全員当たり前になったってのはいいことかなと思うんですけど、思っていて、でも悪かったことというか。

Guest 12:08
そうですね、悪かったとまでは言わないんですけど、

Guest 12:12
難しかった困難だなって感じたのは、やっぱ型通りのモブプロをうまく実践するのは、すごく難しいと感じていて、あと、

Guest 12:23
その型通りにすることの恩恵というか、良さを体感するのも結構難しかったなと思います。

Guest 12:31
ああ、なるほど、なるほど、それはなんかどういったところにあったんですかね。難しさを感じたところは

Guest 12:38
そうですね、まもぐ本来のモクロの良さみたいなものは。頭では理解していて、

Guest 12:46
不老効率とかって言われたりしますけど、

Guest 12:49
ま、そのトータルで見たリードタイムが短くなったりだとか、こう細かくちょっとずつアウトグッドが完成して、合意が取れていく。みたいなところが良さだったのは分かってはいたんですけど、ま、ほんとにそれらが自分らに

Guest 13:02
その恩恵を受けられているのかとか、今までの方法と比べた時に、その恩恵がプラスになって上回ってるのか、みたいなところを

Guest 13:10
えっちゃんと計測とかはできてなくて、計測も何度か試したんですけど、そうですね、試すのも難しいし

Guest 13:19
ま試した数回の結果だけでは、ちょっと判断しきれなかったり、たまたまうまくいっただけなのかどうか判断しきれなかったこともあって。

Guest 13:27
そうですね、その本来のボムプロの良さっていうのをしっかり実感するのは、結構難しいんだなって思います。

Guest 13:33
と考えました。なるほど、なるほど

Guest 13:36
ま、どうしてもやり方決まったやり方っていうのを今、既にあっては、ある程度ワークしているような現場に取り入れると、完全に肌にはまらないこともあるかなっていうところだった

Guest 13:46
感じですかね。

Guest 13:47
そうですね、あとま1人1人

Guest 13:51
画面に向かってこう。各自で作業する時って、そのやり方にはこう大きな問題を感じてないことも多くて、

Guest 13:58
なんで、ああ、はいはい、問題がないのに、あえてやり方を変えるのって本当にいるんだっけ、みたいなところにいる。でも、なりやすくてなんでしょうね。

Guest 14:07
課題をやっつける、新しいいいやり方だみたいな前提で取り組んじゃったのも悪かったのかな。

Guest 14:15
そうですね、ま、銀の弾丸じゃないよってよく言われますけど、そういうことかなと思い、

Guest 14:20
確かに課題感があるものを解消するって、やっぱりわかりやすくやりたいことでもありますし、やった恩恵を受けやすいかなと思います。けれども、なんかこう

Guest 14:28
様々な手法がある。うちの1つで、それに恩恵があるっていうのって、なかなかこう実感しづらいところではありますもんね。そうですね、

Guest 14:37
ああ、そういうのも確かに定着までちょっと、まあ、難しいところではありそうですね。ただ、モブっていう概念が

Guest 14:46
ま、その中からモブっていう概念が抽出されて、最終的になんでしょう。言葉というか、まやり概念が

Guest 14:53
共通した共通認識みたいなんが得られたってのが1番いいとこですかね。

Guest 14:57
そうですね、そうですね、共通認識とか、共通の言葉とかが、チームの中に定着したっていうのはよかったことだなと思います。

Guest 15:07
多分、ふわっとお互いみんなでデビューするっていう概念だった。その今でいう今もレビューと故障できているものが、

Guest 15:15
モブレビューという名前がついたことによって、モブという考えが、他にも転用できるようになったってのがま、1番おいしいところって感じ。

Guest 15:27
いや、でも、結構やっぱりもプロとかって話とか聞いてたり、まやってます。って話聞くと、いわゆるもプロ、ほんとのほんとのほんとのって言ったらあれですけど、

Guest 15:35
1番そのいわゆるこう、ガチガチの方に染まったボプロってのが多いかなと思うんですけど、なかなかそうなると

Guest 15:42
頑張れよって上手くいく、上手くいかないってのが。まあ、取り入れ方の問題だけじゃなくて、多分現場との町とかもあって、難しいところもあるのかなと思いますけど、なんか、

Guest 15:51
自分なりにアレンジして加えていくっていう選択肢はなかなか。あまり他の外部のメディアとかでも見たことがないんで、結構珍しい考え方だなと

Guest 16:00
ちょっと思いましたね。はい、かなりいいなと思いました、ありがとうございますはい

5. モブを自然に取り入れていく・続けていくコツは？ 16:10

Guest 16:10
でですね、そんな感じで、ニュースaチームにおいてる。モブの考え方について話していったかなとえ思うんですけれども、

Guest 16:18
こっからですね。ちょっと切り口を変えてみて、結構モブプログラミングとかって、やってみたいって思っている人も多いのかなと思っていて、ま。ただ、その一方でやれてないっていう現状、あるいはやってみたけど、うまくいかなかったっていう人も結構いるのかなと

Guest 16:33
思っています。と

Guest 16:34
でま、それはなんかもしかしたら、なんか、白沼にアンチパターンを踏み抜いてしまっているっていうパターンだったり。まあ、なんか1回やってみたけど、次以降に繋がる要素がなかったみたいなので、1回コッキーになってしまったりっていうのがあるのかなと思う。

Guest 16:45
ですけど、なんか、今、ニュースチームが3年間続けられてるってのは、どういうとこにあるのかなってのがちょっと気になってるんで、

Guest 16:52
なんかこううまくいかない場合にやってしまって、そうなアンチパターンとかって、なんかあったらちょっと聞いてみたいんですけど、なんかありますかね。そういうのって、

Guest 17:01
ああ、そうですね、やっぱり、僕

Guest 17:05
立が始めようと思った時にもあったんですけど、どうしても効率が本当にいいのってのは気になっちゃうと思うんですよね。

Guest 17:12
3人、例えば3人だったら、3人がバラバラに行動を書く方が効率はいいんじゃないの。って思っちゃうんですけど、やっぱそこはちょっと踏みとがって考えると

Guest 17:22
いいかなと思っていて、さっきフロ効率って言葉をちょっと出しましたけど、ま、リソース効率とフロー効率ってこう

Guest 17:30
2つ並べて話されることもあると思うんですけど。そうですね、ここを書く時間だけではないと思うんですよね。リリースして、ユーザーに届けるまでに必要な時間って

Guest 17:39
まレビューだったりだとか、さっき言ったコミュニケーションしてる時間だとかってのも測ってみると結構あるはずで。

Guest 17:46
で、そういった時間を全て含めてえ、自分たちにとって効率がいいのはどちらかっていうのを考えるのは、1個の選択肢かなと思います。

Guest 17:57
で、あとは、短期的なものだけではなくて、長い目で見た時にその暗黙が溜まっていくだとか、良さもあると思うので。

Guest 18:06
うん、うん、

Guest 18:07
そうですね、そういった意味でもこう。自分がその画面に向かって行動を書く

Guest 18:14
時間だけを見て、効率のよ。足ってのは判断しない方が、文は取り入れやすくなるんじゃないかなと思ってます。

Guest 18:22
ああ、なるほど、

Guest 18:23
なるほど、確かに結構どうしても稼働率みたいなのって、あの、自分のことでもあるから、みんな意識しやすいというか、あ、これぐらいコード書いたなとか、何時間作業してたなとか、

Guest 18:33
なんか、ある日は特にエンジニアとかだったら、どうしてもこう。

Guest 18:36
ミーティングとかもそうですけど、コミュニケーションしてる時間が長いと、あんまり生産性出しきれてないなって思っちゃうことが多いかなと思うんですけど、ま、そうではなくて、まあ、その稼働率が100パーであることよりも、デリバリーの速度が早いっていうところにま良さがあるっていうの、

Guest 18:51
しっかり認知しながらやるっていうところが大切って感じですかね。

Guest 18:55
そうですね、まさにそうだと思います

Guest 18:58
で、なんか僕らもその始めた時、なかなかそのワロ効率、いわゆるリードタイムがどれだけ短くなったかっていうところに意識をこう向けにくかったんですけど、

Guest 19:08
その時にこう

Guest 19:10
こういうふうに考え方を変えたらどうかって、チーム内で話したことの1つがま。今までは、リリースまでにどれだけ多くの機能を詰め込めるかっていう風に考えることが多かったんですけど、

Guest 19:21
そのもうやって不老効率を意識したした時には、ま、どれだけ細かく刻めるか、

Guest 19:26
ちょっとずつ進められるかを意識しようっていう風に、考え方を変えられないかっていうのはつで話したことがありました。

Guest 19:33
刻むっていうと、どういう感じですかね。

Guest 19:36
ちょっとずつ完成させるとか、ちょっとずつ出していくとかですかね。コードの中の合意が取れてる部分、

Guest 19:44
あのアルムと同じ等しい状態になってる部分を、段階的にちょっとずつ作っていくみたいなイメージですかね。

Guest 19:51
ああ、なるほどなるほど、

Guest 19:53
じゃ作業単位っていうのをなんかもう少しあの小さくして、そのどうしても機能を詰め込むってなると

Guest 20:00
こう作業単位とかが膨大になっているけど、滑り込みでセーフみたいな話も出てきがちですけど、まあ、っていうよりは、あくまでもそれぞれの作業っていうところをましっかりと合意を取って、効率的にやっていくっていうのがま、小さな単位でやっていくってのが大切っていうところ

Guest 20:15
ですかね。そうですね、はい、

Guest 20:16
うん、うんうん、なから

Guest 20:19
なんかこう。機能がいっぱい入ってるリリースをやるとやって、達成感ってやっぱりあるかなとは思うんですけど、まあ、そこにとらわれすぎないで、

Guest 20:27
あくまでも、まあ、イテレーション早く回せる状態にあるのが大切だよねっていう考え方にシフトしていくってのは大切ですかね。そうですね、

Guest 20:35
ほんとにそんな感じでした。そうですね、まあ、やっぱリリースのサイクルは簡単には変えられないので。

Guest 20:41
そうですね、チームの中で、そのアプルブ状態なものをどれだけ細かく早く作ってか、うんみたいなところに、僕らは意識を向けるようになった感じですね。

Guest 20:51
なるほど、

Guest 20:52
なんか結構刻むっていうと、こう。どうしてもリリースの頻度の話のイメージになりがちですけど、確かに作業単位でも、ちゃんとチーム内の開発チーム内でできる考え方として、その小さな単位に分解していくっていうのは、すごい大切

Guest 21:06
ですね、ありがとうございます。

Guest 21:09
結構そうですね、ここの考え方のシフトをする、あるいは、ま、初めてモブをやってみるって、タイミングで、全員で意識のすり合わせをしないと、

Guest 21:18
なかなかこうやってみたけど、どうなんだろうなってなりそうなところでもあるんで、重要な気がしますね。

Guest 21:25
そうですね、そうだと思います。あとま、アンチパターンではないんですけど、

Guest 21:32
あの、僕らにこれがあったおかげで導入しやすかったなって思うものは、あの、結構何事も

Guest 21:39
ちょっと試してみましょう。って言ってくれるチームメンバーが多かったんですよね、なんで僕もちょっと試してみましょうって言って、

Guest 21:47
ま、まずは試してから判断するっていうことができたから、よかったなって思うのと、あと、それとセットで

Guest 21:54
ま試した結果。明確なダメな理由がないんだったら、しばらくはお試しを継続するっていうのもあるの

Guest 22:03
なんだ。文化とまでは言わないですけど、ま、習慣として定着していたので、もうももまこれがダメってわけじゃないから、ちょっとやってみようか、もうちょっとやってみようかっていう風に

Guest 22:12
だったのが、継続のきっかけにはなりました。

Guest 22:15
ああ、それはすごい大切ですよね。なんか、多分初めから100点にするってできないんですけど、60点ぐらいを目指そうっていうのができるものがあったとして、

Guest 22:25
うん、60点悪くはないけど、微妙だし、やめちゃうかっていうのって、やっぱり多いかなと思うんですけど、それよりも明確にダメじゃない限りは、継続するっていうのはなんかいいですね。

Guest 22:34
すごく

Guest 22:36
そうですね、結構助けられてますね。その考え方というか、みんながそういうて受け入れてくれることには、結構助けられてるなと思います。

Guest 22:44
それは、すごい継続するために、必要な、すごい重要なファクターな気がしますね。

Guest 22:51
なんか、他にこういうのをうまくワークさせるためにとか、続けるためのコツみたいなのって、他にあったりしますかね。

Guest 22:58
そうですね、ま、1度型通りの桃を試してみたけど、ももクロを試してみたけど、うまくいかなかった

Guest 23:08
ていうチームであれば、ルールに縛られないっていうのもありかなと思います。やっぱ、1度は型通りのモを経験することに

Guest 23:17
しておくと、価値があるんじゃないかなと思うんですけど。ま、どうしてもルール通りにやって、うまくいかないところはちょっとほぐしてみて、それも試してみて、

Guest 23:25
本来のルール通りの方とどっちがいいかって、比較しながらやっていくのがいいんじゃないかな、と思います。

Guest 23:32
なんか、あくまでももプロって概念にとらわれすぎないというか。そうです。ま、あ、くまでも、まあ、エッセンスをしっかり吸収できたら、それで、

Guest 23:39
私たちのチームにとっては、ベストやねっていう考え方でやっていくっていうのが大切とこですかね。

Guest 23:45
そうですね、この場合は、そのさっきは不労効率をもうちょっと良くしたいっていうのは、結構チームの意識になとしてはあったので、ま、不労効率が良くなるんだったら、この部分はちょっとほぐしてみてもいいんじゃないかってことで。そうですね。ま、最初は

Guest 24:00
ドライバーの交代時間をルーズにするところから始めて、

Guest 24:05
その後はもうドライバーとかそんなにかっちり決めなくてもいいんじゃないかなっていたりすかね。

Guest 24:15
あとは、そっちかにルールにその縛られない

Guest 24:19
代わりに、今日の自分たちのやり方って、今までと比べてどうだったっていう振り返りを定期的にというか、毎回するようにはしてました。

Guest 24:27
ああ、はいはいはいはい、

Guest 24:32
確かに振り返りはちゃんとやらないと

Guest 24:34
こう

Guest 24:34
なんでしょう。打性でやることになり、

Guest 24:37
あれですね。そうです

Guest 24:38
ね、脱せになることもあるし、あとまただルール壊して

Guest 24:43
気持ち的に楽になってるだけで、実はこれてないとかってこともあると思うので。そうですね、振り返りは結構毎回してました

Guest 24:52
ちなみになんか振り返って、こういういいあの、振り返りの時間になったみたいな例ってあったりします。

Guest 24:59
ううん、ちょっともう思い出せなくなっちゃってるはいね。そうですね、なんか、当時

Guest 25:08
振り返ってた方法だけは覚えてて、最初の頃はよくあのファンダーラーンって呼ばれる方法を使ってました。

Guest 25:15
で、あのファンとダンとララで楽しかったこととえでやったことと、学んだことを書き出していく感じですね。はい、

Guest 25:25
でやっていくと、どうしてもわわ悪かったところというか、次直したいところも出てくるので、ま、それに加えて、

Guest 25:31
次試したいことっていうのは、別の軸でプラスアルファに出したりとかもしてました。で、だんだんまあこう楽しかったこととか、こう

Guest 25:39
経験になったことに目を向けるだけじゃなくて、もうちょっとこう問題点とか、うまくできてないところに目を向けようってことで、あのケプト

Guest 25:48
やり方を変えていったりだとかっていう風にま振り返りのやり方自体も色々変えながら振り返っていたなっていうのが記憶にありますね。

Guest 25:58
確かに、なんか初めっからケプトを採用し出すと、こう。どうしても、まあ頑張ってキープでモチベーション上げても、大体ピート的に

Guest 26:06
目が行きがちっていうところがあるんで、まはまあ、まずはファンを重重視していくっていうのは大切かもしれないですね。

Guest 26:13
ですね、特に最初の1回とかはそれでもいいのかなって今でも思ってます。

Guest 26:17
確かに確かに

Guest 26:19
だから、これはまたモブとは別軸の話で、なんかフェフェーズに合った振り返りの話として話、聞きたいところではありますね。

Guest 26:26
ま、結構振り返りってのケトみたいなのってお多い気がするんで、ちょっと。これはまた別にエピソードとって聞きたいところではあります。

Guest 26:35
はい、そうですね、また話したいです

Guest 26:37
あ、でも結構そうですね。なんか、ルールに縛られないとかま継続してみるみたいなのが、あのワークするまでやってみることっていうところですかね。

Guest 26:46
うん、それが1番かなとま、実体験の中では思いますね、

Guest 26:51
ありがとうございます

6. モブが向いてる現場は？ 26:53

Guest 26:53
最後にですねえ、今回LINEnewsのチームは。今全体で11人いてもの作業自体は3人から10人でやってるって話があったかなと思いますけど、なんか結構現場によっては人数もえ、プロジェクトの人数も違うのかなと

Guest 27:08
思ってて、例えば、え、LINEの中では他のプロジェクトで言うと、大体2人ぐらいから4人ぐらいの

Guest 27:14
開発者でやってるのが多いかなと思うんですけど、なんか、それぐらいの規模でも、モブとかってやった方がいいのかな。それとも、なんかもっと適正人数って他にあるのかなっていうのが気になっていて、

Guest 27:24
その辺お月さん的にはどう思いますかね。

Guest 27:27
そうですね、4人とかはほんとにもクロするので、ベストな人数だろうなって思っていて、3から5人ぐらいは結構やりやすい人数だと思います。

Guest 27:37
逆に、僕ら11人全員でやるのは結構しんどいので、2グループに分けちゃうこともあるし。そうですね、ほんとにコード書ってなったら、

Guest 27:47
もっと少数でやってます。何かを決めるとか、試すぐらいが軽いものだったら、11人みんな集まることもあるんですけど。

Guest 27:55
そうですね、ま、5人ぐらい5人以下ぐらいだと、やりやすいんじゃないかなとは思います。

Guest 27:59
じゃあ、なんかあれなんですね。結構暗黙地をえ、減らすとか、みんなでえ。合意を取るってなると、人数が多い時にワークするようなイメージ持つ人も多いかなと思うんですけど、そんなに多すぎない方がいいって感じですかね。

Guest 28:11
そうですね、それも内容次第だと思うんですけど、コード書くとなると、

Guest 28:17
さすがに10人とか集まってこう行動した方が移行した方がいいってなると、空中戦と言いますか。ここ

Guest 28:26
意見だけ言い合う時間がすごく伸びちゃって、はいはいはい、コードに書き起こされる量が減ってきて、

Guest 28:33
そうするとこう議論できてるつもりでも、あんまちゃんと議論できてなかったとかにもなりやすいかな。思うので、ま、議論しやすい人数って意味で5人以下ぐらいがいいんじゃないかなと思います。

Guest 28:44
確かに、なんか特になんかも。プロの場合は、作業者が1人の中で話す人が多いっていう感じになりますしね、

Guest 28:51
なんか、結構なんでしょう、先道多くして、船山にと言いますかしまさにって感じですよね。

Guest 28:59
基本的にはまあ4人まあ、多くても5人ぐらいっていうのでやるといいかなっていうところですかね。はい、そう

Guest 29:06
ですね、この体幹席のおすすめは、5人ぐらいかなと思います。

Guest 29:09
ちなみに、その中で、人数と同時にタイミングっていうのもあるかなと思うんですけど、なんか、どういった時に取り入れていくと、こういうの。あの、もうプロの導入って、なんかうまくワークすると思いますか。

Guest 29:21
ああ、そうですね、ま1つはチームの人数が増えた時

Guest 29:29
はいいかなと思ってま。特に、2人から3人に変わる瞬間は大事かなと思ってて、

Guest 29:36
2人の時って、1対1のコミュニケーションなので、大丈夫なんですけど、3人でなく、自分の知らないところで会話が生まれるので、こう知らず知らずのうちに

Guest 29:45
3人の中にこう。祖母とかズレが生まれてきやすいので、それを潰すって意味でも、モブの場があるといいかなと思うのと、

Guest 29:54
あとは、タイミングとちょっと違うんですけども、向いてる作業みたいなのはあるかなと思っていて、やる人によって結果が変わる作業と、

Guest 30:03
あとはその結果に至るプロセスが人によって違う、または、そのプロセスもちゃんと共有したい作業は

Guest 30:11
方に向いてるんじゃないかなと思います。例えば、

Guest 30:15
新規の機能開発とかですかね。なんで、この実装にしたんだってと、この設計にしたんだって言って、プロセスは共有してあった方がいいはずだし

Guest 30:24
ま。最終的にできる結果って人によって違うと思うので、もが向いてるかなと思います。

Guest 30:29
あ、あともう1個おすすめのあのもぐの導入案件は環境構築がいいなと思ってて、

Guest 30:37
はいはいはい。あの、新しいメンバーがチームに入った時に、その新規のメンバーをドライバーにして、

Guest 30:45
残りのメンバー既存のメンバーがナビゲーターになって、みんなで環境を構築するっていうのはいいかなと思います。

Guest 30:51
環境構築って、結果は一緒かもしんないんですけど、その起きる問題って、結構マシーンによって違うとか、その時のまいろんな状況によって変わってくるので、

Guest 31:01
結構こう集合値が役に立つ場面だと思うんですよね。な

Guest 31:04
ああ、そうですね、うん

Guest 31:07
で、しかも、なんか自分1人が

Guest 31:09
ぶつかった問題って、あんまりこうログとか残さなかったりするので、他の人は起きないからいいやとかなった問題をが役に立ったりもするので、環境構築はモブでやるってのは結構おすすめかなと思います。

Guest 31:21
なんか、環境構築であれば、特にあれですもんね、その公立みたいなところも、まだ意識しなくていいタイミングでもありますしね。そうですね、

Guest 31:29
逆にまもが向かないのはさっきの逆ですけど、ほんとに

Guest 31:32
誰がやっても同じ結果になる作業かなと思ってて、うちのチームだと、簡単なバグ修正とかはまさしく、それに該当するかなと思ってて、

Guest 31:42
それだったら、各自が1人ずつバグズしていった方がま、レビューするときだった。大してコストはかからないし、

Guest 31:48
ま、誰がやっても結果は一緒だし、プロフェッサーも一緒だから、そんなにこう

Guest 31:52
なんでこんな修正にしたんだっけみたいなずれも置きにくいってそうですね、バグ修生とかは、個別にやることが多いと思います。

Guest 32:00
ああ、なるほど、なるほど、なんか、頭の数が多い方がいい時と、手の数が多い時がいいもので、分かれてるって感じですかね。

Guest 32:07
そうですね、それいい条件ですね、わかりやすいと思いま。

Guest 32:12
確かにそうですね、バグ修正は手を動かせる人がおき、多ければ多いほどいいいって言ったらあれですけど。っていう風なものですけど、環境構築とかは知恵がたくさんある方がいいです

Guest 32:21
ね。そうですね、

Guest 32:23
特に環境構築、3人目の環境構築てっていうのが、じゃあ1番いいかもしんないですね。そうです

Guest 32:29
ね、いいと思います。あのれ、ほんと練習もしやすいというか、こうそれこそ型にはまったドライバーナディエーターみたいな役割も明確につけやすいので、

Guest 32:39
いいんじゃないかなと思います。

Guest 32:41
確か、3人だと、まあ、ちょっとぐってもカバーしやすいというか、まだ人数的にもとこもありますもんね。確かにかに

Guest 32:50
じゃ、ちょっともしも検討してみてるっていう時は、ま、誰かのボーディングみたいなのが必要になるタイミングでちょっとやってみるとか。まあ、

Guest 32:58
あの、新しく新規開発するみたいな時に、一旦合意形成のレビュー代わりに使ってみるっていうところがいいかなってとこですかね。そうです

Guest 33:05
ね、そう思います

Guest 33:07
結構

Guest 33:08
なんでしょ、もブやろう。さっきのえおつきさんの話もありましたけど、なんかモブやろうから、始めてしまうとも、ブ用の仕事を持ってきたりとかっていうのから、始まったってところがあったかなと思う。

Guest 33:17
ですけど、そういうのはこういうこううまくいくパターンの私たちのラインでの経験則とかも、他のえ、会社の他のチームに

Guest 33:25
うまく活用してもらえるといいですね。そうですね、

Guest 33:30
じゃまあまずはえ。まあ、新しいメンバーが入ってきた時とか、まえとま少人数で何かできる時にま、新規開発や環境構築からやっていって、

Guest 33:39
あの、うまくアレンジしていけるといい感じですかね。

Guest 33:42
はい、

Guest 33:43
ありがとうございます。

Guest 33:44
いや、今日はちょっとねとLINEnewsでの取り組みから。え、自然に始めていって、続けるためのごつ。最後に現場の話まで色々聞いちゃいましたけど。おつきさん今日はありがとうございましたはい

Guest 33:54
こそありがとうございました。

Guest 33:58
では、そろそろクロージングに行きたいと思います。

7. クロージング 34:03

Guest 34:03
というわけで、本日はえ、LINEnewsで取り入れているえ、モブプログラミング改めてモブワークのえと、現在の状況について大つきさんにえ、聞いていきました。

Guest 34:14
LINE株式会社のフロントエンド組織UITではま、このようなフロントエンドにえ関わらずですね。開発に対するえ、様々なコミュニケーションをえ、日々行っております。

Guest 34:25
中にはですね。UIT INSIDEのエピソードとして、公開している元々は、社内での勉強会で行われていた議題などなどもありますので。今後もこんな感じでLINE社内でのえ、取り組みについて、

Guest 34:36
どんどん公開していこうと思っておりますので、ぜひぜひまた聞いていただけると幸いです。

Guest 34:42
またえ本ポッドキャストについてのフィードバックは、twitterなどなどで受け付けております。

Guest 34:48
ハッシュタグえ、シャープUIT、アンダースコアインサイド見てつぶやいていただけます。とえ、運営スタッフの方で拾ってえ。できるだけ反映していこうかなと思いますので、

Guest 34:57
まご意見やご感想などがあれば、えどしどしツイートしていただければと思います。

Guest 35:02
またえ、最後になりますが、え、LINE株式会社ではえ、一緒に開発を行う仲間を募集しております。

Guest 35:08
このエピソードの小ノートのですね、サ花部の方に、求人へのリンクの方を貼っておりますので、え、新卒中途とし、年募集しておりますので、カルメなからでも、え、ぜひ

Guest 35:19
お話できればと思っております。

Guest 35:21
なんとかさんと話したいです。とかあったら、え書いてもらったら、おつきさんが出てきたりするので、ぜひぜひなんかそういうことを書いていただければと思います。

Guest 35:29
はい、終わります

Guest 35:30
というわけでえ、本日はえ、モブプログラミングについて話していきました。え、お聞きいただきありがとうございました、

Guest 35:37
ありがとうございました。