フィヨルドブートキャンプのチーム開発の(ほぼ)全Issueをペアプロ・モブプロでやった話
はじめに
こんにちは。1ヶ月前くらいに、所属するフィヨルドブートキャンプ(以下FBC)にてチーム開発のプラクティスが完了しました。
私は取り組んだ計13個のIssueのうち11個をペアプロ・モブプロをして取り組んだので、そのときの思い出について書いてみようかと思います。
もくじ
チーム開発とは
フィヨルドブートキャンプでは基礎学習プラクティスを終えた後、実際に学習のプラットフォームとなっているWebアプリを(受講生がIssueを担当しPRを)作るというカリキュラムがあります。 FBCはOSSなので皆さんのお手元でも立ち上げられますし、なんならPRを送ることもできます。
これまで学んできたRails・Vue.jsなどなどの知識を使って、自分たちが実際に使っているWebアプリの開発に携わりながら、GitHubを使ってチームで開発を行う流れや作法を学ぶというプラクティスになっています。
難易度別のポイントが付けられたIssueを割り振られ、20ポイント分のIssueがマージされたらプラクティス完了という流れになります。
チーム開発までのプラクティスは目指すべき成果物が決まっているので、実際に動いているアプリの新機能やバグ修正を行うという明確なゴールのない作業(実際の仕事と近い)を初めて行うことになり、難易度はグッと上がる気がします。
何でペアプロ・モブプロでやったか
元々チーム開発に至るまでのRails、オブジェクト指向、JavaScript、Vue.jsのプラクティスが私にはどれもめちゃくちゃ難しくて、メンターの方やアドバイザーの方、卒業生や同じ課題をやっている受講生などなど、色んな人にペアプロをしてもらって進めていました。特にVue.jsなど最後の方の課題は難しくてひとりでは行き詰まってしまったので、半分くらいの出来で「ここまで出来たので、ここから先をペアプロで一緒に作業してほしいです」とペアプロ前提で提出してメンターの方と一緒に提出物を作っていきました。
あと私は人と喋るのがそもそも好きなので、プログラミングの課題だけでなく、イベントのスライド作りなんかも画面共有しておしゃべりしながら進めていくこともしていました。ひとりだと先延ばししてしまうけど、人と一緒にやるとやる気が出るし、目標が達成できるし、なによりめっちゃ楽しいなと感じていました。
チーム開発のミーティングに初参加すると、メンターの町田さんから「チーム開発のプラクティスはほとんど仕事と同じだから、これを楽しめるかどうかでプログラマーとしての仕事が自分にとって幸せかどうか考える材料にしてほしい」といった旨のことを言われます。
私は輪読会もそうですが、自分が楽しいと感じるのはチームでワイワイすることだと思っていたので、自分なりに楽しめる方法を開拓していった結果として知識も身につけられたらいいなと考え、全Issueをペアプロ・モブプロで行ってみることに挑戦してみました。
それってドーピングじゃない？学習効果的に駄目じゃない？周りに迷惑じゃない？的な懸念もなかったわけではないですが、まあそう判断されたら駒形さんなり町田さんなりに注意されるだろうと思って勝手に進めてみることにしました。実際に働き始めたら、なかなか自分の好き勝手なやり方で作業を進められるわけではないだろうから、好きなことをするいい機会かもなという目算もありました。
結果注意されるどころか「すごくいいのでどんどんやって行きましょう」と後押ししていただけたので良かったです。
実際に取り組んだIssue
私がFBCの開発で取り組んだIssueは下記のものになり、★が付いているものは人と一緒にやりました。
上記はブランチを切るところからPRの作成まで誰かと一緒にやってもらったIssueもあれば、不明点を一部のみ一緒に見てもらったIssueもあります。
一緒にやる相手は、メンターさんである場合もあれば同じ時期に開発に入ったメンバーの方だったりと様々です。自分が他の方のIssueを一緒にペアプロ・モブプロしたり、レビューを頼まれたPRをメンターの方と一緒にレビューしてもらったこともあったので、合計するとこれ以上ありそうです。
ペアプロ・モブプロって楽しい！
人と一緒にやった11個のIssueで1番思い出深いのは、チーム開発同期のメンバー3人でgood first issue(最初に割り振られる簡単なIssue)にモブプロで取り組んだことです。
good first issueは表示されているテキストを一部変更するくらいの簡単なIssueではあるものの、ひとりで取り組んだ方の日報を読んでいると、gitの操作やエディタの操作、PRの作り方などに不安を感じて緊張しながら取り組んだという内容が散見されました。これって単なる慣れの問題だろうし、誰かに見ててもらえば絶対起きない問題じゃない？と思ったので、すでにチーム開発に取り組んでいる方にDiscord上で「誰か見に来て助けて〜！」と声をかけてみました。
そしたらチーム開発プラクティス中の受講生や卒業生、メンターの方、まだチーム開発には入っていないけど興味を持ってくれた受講生などが集まって21時から翌朝まで(！)盛り上がってとっても楽しかったし、gitの操作やPRの作り方、descripitionの書き方などチームの作法を直接教えてもらえてその後の開発にスムーズに入ることができたと思っています。
最初に取り組んだモブプロがあまりに楽しかったため、それから毎日のようにいろんな方にペアプロを依頼してIssueを進めました。 始めたばかりの頃はなんて楽しいし効率的なんだ！ペアプロしてくれた方レビューにお願いすれば、レビューの手間も省けるし最高のアイディアだった！と浮かれて、土日や平日の夜など、普段だったら学習を休んでいる時間をすべてペアプロに充てていました。
その頃の自分の取り組みの様子はSaki (id:Saki-Htr)さんのブログに詳しいです。今思い出してもチームでやってる感が感じられて楽しかったな〜！
やりすぎた
簡単なIssueでうまく行ってるときは良かったんです。分からないことが分かって楽しい！私いまレベルアップしてる！という実感があり、休まずにプログラミングのことを考えるのが幸せでした。 でもMarkdownの中で独自記法でメッセージブロックを書けるようにしたいという、私にとってどう取り組んだらいいのか分からないくらい難しいIssueを担当することになり、受講生・メンターの方と何度もペアプロしてもらっている中で心が折れてしまいました。
せっかく時間をさいて懇切丁寧に説明してもらっているのに話に全くついていけず、緊張と自己嫌悪で適切な質問もできず、ペアプロが自分のプログラミングの適性のなさを思い知らされる場に感じるようになってしまいました。 分からないことだらけで辛いし、私は本当にこんなことをやりたいのだろうか…本当はドストエフスキー読みたいのに夜も土日もプログラミングしてるせいで何もできない…とめちゃくちゃ深刻な悩みとして泣きながら人に相談したりしていました。
↑のようなことをDiscord上や日報で呟いていた結果、駒形さん町田さんに週1の開発ミーティングにて「なんか疲れてませんか？ペアプロしすぎじゃないですか？」と心配されてしまいました。
ペアプロ疲れ
ペアプロが一般的に疲れるものだということを私は知らなかった(楽しいだけかと思っていた！)のですが、現役のエンジニアの方何人もから「疲れるからほどほどにした方がいい」と言われました。
人に見られながら作業をしていると集中できるということは、裏を返すと気が休まる時間がないということでもあります。
ペアプロを業務の一環として導入している会社でも、定時になったら(キリが悪くても)やめたり、ペアの人と朝・昼ごはんを一緒に食べて互いの疲れ具合を平等にするような工夫をしているという話も聞きました。
私の場合を考えると、ペアプロしてくれる人の予定に合わせてextraに時間を割いている状態(普段は休んでいる21時以降と土日とか)だったり、複数の相手と同じ日にペアプロしたりしていたので、疲れて当然だったと思います。
また、これは自分だけかもしれませんが、相手が時間をさいてくれているという状況に申し訳なさ？を感じ、面白いことを言わなければ…楽しそうにしなければ…みたいな無駄な気負いがあったことも疲れの一因だったかもしれません。この気負いは本当にただの自己満足なのでやめようと思ってます！
疲れないための工夫
私が今回の経験で得た教訓をまとめると以下になります。
- 休憩時間をちゃんと取ること。ドライバー側は疲れるので申し訳ないと思わずに積極的に休憩を申し出る。
- 自分の休息をちゃんと確保すること。ペアプロして教えてもらう場合、多少は相手の都合に合わせることになるけど、それでも土日や21時以降は休むみたいな休息のルールを決めるのがよさそう。
- 「相手の時間を奪っているのでは」的な余計なことを考えないこと。仮に奪っていたとしても向こうが合意している以上、none of my businessだから気にしないという強い気持ちを持つ。
- あくまで「分からないことを理解するため」にペアプロしてもらってるという意識を忘れないこと。「楽しさ」が副次的についてくれば最高だけど、相手との関係性・取り組んでいる問題のややこしさ・双方の精神状態などによって叶わないことはおおいにあるので。
- 分からないことが分からないままペアプロしてもらうことを恥じないこと。「わざわざ時間を取ってもらっておいて、自分が分かってないことも説明できないなんて情けなくてつらい」と思うときはあるんだけど、分かるまで聞けなかったら一生分からないままじゃん？？？
工夫しないと疲れるのは疲れるんですが、やったこと自体は後悔していないです。周りに頼るよい訓練になったという点だけでもやった価値があったと思います。
今の私が分からないことだらけで前に進めないというのは事実なので、サポートしてもらうことへの抵抗感をできるだけ減らすことで、チームとしてよりよい状態を目指せるし自分自身の成長にも繋がるのかな〜と思っています。
見つかった課題
メンターの梅本さんにペアプロしていただく機会がたくさんありました。梅本さんの察し能力が天才的なため、自分の「ｱｱｱ(意: 何もわからない😵💫)」レベルの発話でもほぼ100%の意図を汲み取ってもらえてしまい、逆に(自分に対して)危機感を覚えるようになりました。
知識が足らなくて分からないことを聞くのは全然いいけど、「今まで何を意図してこのコードを書いたのか・これから何をしたいと思っているのか」を自分で説明できていないのはよくないと反省しました(もちろんきちんと説明できなくてもひとりで抱え込むよりずっとマシだとは思いますが)。
なのでチーム開発が終わった後に取り組んでいる自作アプリ作りでは、自分の進捗を説明するYouTube動画を撮って公開しています。 説明の練習用に撮っているので人に見てもらうことは期待していないのですが、文脈(自分の作りたいと思っているもののアイディア)を共有していない相手に非同期で今の状況を伝えることもできるという点でも役に立つ予定です。
今のところ、目に見えて説明が上達したとは自分では感じないですが、音声通話での質問や進捗報告のときに以前よりリラックスして話せているとは思っています。
終わりに
しかし、我々の言葉を真に受けないでください。まずは調査し、これらのアプローチが合っているかどうかを試してみるのです。注意深く実行するとともに、やり過ぎないようにもしてください。特定の方法論に対して過度に投資すると、代替策が見えなくなる可能性があります。慣れてしまうと、その他の手法が目に入り辛くなり、硬直化してしまえば、他のやり方に迅速に適応できなくなってしまうのです。
David Thomas/Andrew Hunt『達人プログラマー（第2版）熟達に向けたあなたの旅』村上 雅章 訳、オーム社、2020年、350頁
『達人プログラマー』の↑の文章を読んだとき、これってペアプロしまくってたときの私じゃん…と思いました。 ペアプロはいいものだ！と感じた経験に頼り、それが全てを解決する万能の道具のように思い込んでやりすぎてしまったのです。
私はバカなのでやりすぎて痛い目に遭うまで何も学べないのですが、次になにかにのめり込みそうになったらこの文章を思い出せたらいいなとは思います〜！(多分無理)
ちなみに最近(一概に自分の影響ではないと思いますが)、いろんな方がFBC内でペアプロ・モブプロをしている姿はよく見かけるようになりました。
木曜日の午後からはるぐち(id:haruguchi_yuma)さんがAtCoderのAB問題に取り組む「勝手にモブプロ」会や、チーム開発真っ最中のいっしー (id:isshi-hasegawa)さんも自分のIssueに取り組むモブプロのモブを募集されています。私が始めた、チーム開発に入ったばかりの方がgood first issueに取り組む様子を見守るモブプロもほそぼそと続いています。
皆さんもプログラミングを楽しむ方法のひとつとしてペアプロ・モブプロに取り組んでみるのは悪くないかもしれません。ただし用量・使用法にはよく注意ですね！！
