TDD＋モブプロでワイワイしてきた感想と、業務への取り入れについて
こんにちは。ソリューション開発部 認定スクラムマスターの羽澤です。最近またコードを書く仕事をしておりまして、コードを書く楽しさを実感しております。少し前まではマネジメント系の本を読んだり、勉強会もアジャイル系のものに参加していたのですが、最近はまたプログラム関連の勉強会にも参加し始めました。
というわけで先日、TDD+モブプログラミングでワイワイする会に参加させて頂きました。モブプロは知っていたものの、SIerとしては導入し辛さを感じていたため少々敬遠していたのですが、とても良いプラクティスだなと感じました。何よりもとても楽しい時間を過ごすことが出来たため、TDD＋モブプロがどういうものか、SIerとしてどう取り入れていくか、紹介しようと思います。
TDDとモブプロ
TDDとは
テスト駆動開発のことです。まずはテストコードを書き、テストを失敗させます（実際に処理するコードを書いていないため必ず失敗します）。その後、汚かったり冗長でもよいのでテストを成功させるようにコードを書きます。テストを成功させた状態でリファクタリングを行って良くしていくという手法です。
コードを書く際のプロセスとして、綺麗なコードを設計し、それを動くコードに落とし込むというアプローチがあります。私がそうですし、TDDが一般化する前は大体そうだったのではないでしょうか。TDDは少しアプローチが異なり、まずは汚くても動くコードを書き、その後綺麗にしていくスタイルとなります。自分が今まで取ってきたスタイルとどう違うのか興味はあったものの、今の今まで取り組んで来ませんでした。
モブプロとは
モブプログラミングのことです。2人で一緒にコードを書く、ペアプログラミングが有名ですが、モブプログラミングはさらに人数を増やして一緒にコードを書くというアプローチです。知識の共有というのが主な目的なのかなと理解していましたが、今回は実際に体験してみて、どのような良さがあるのか肌で感じてみたいなと考えていました。
進め方
今回は4人1チームでモブプロをしました。1人がコードを書くドライバー、3人が見ている側のナビゲーターとなります。コードは以下のサービスを利用して書きました。
https://cyber-dojo.org/このサービスがとても良かったです。ブラウザ上でコードを書けるサービスなのですが、テストコードの実行まで出来てしまうのです。今回のように、得意なプログラム言語が異なる人が集まった場合、とりあえず環境構築から・・・になりがちですが、その必要が無くなります。技術を学ぶ際に一番の障害になるのは環境構築だと思いますが、その障害をゼロにしてくれる素敵なサービスです。
ドライバーとナビゲーター
前述の通り、ドライバーはコードを書く人となります。後日調べてみたのですが、ドライバーは自分で考えて勝手にコードを書いてはならず、ナビゲーターの指示に従ってのみコードを書く。という意見を見つけました。我々はそこまで厳密にはやらなかったのですが、基本はナビゲーターと相談しながら手を動していました。これにより、ナビゲーターがぼんやり眺めているだけで、時間の無駄になってしまうようなことは起こりませんでした。
ドライバーが意識することは、これからやることを声に出すことだそうです。FizzBuzzであれば「これから3の倍数かどうかを判定するロジックを書きます」等です。ナビゲーターからうまく導いて貰うには、次に何をしたいのかを表明しながら進めなければなければなりません。
次にナビゲーターですが、ドライバーを導いてあげたり、先回りして調べ物をするのが役割です。調べ物をしている最中は仕方ないのですが、それ以外は自分のPC等を見ることなく、ドライバーと同じ画面を見つめる必要があります。ドライバーの声に耳を傾け、しっかりと自分の意見を主張し、議論しながら導いてあげましょう。
これがモブプログラミングの説明です。4人なのでドライバーとナビゲーターを交代しながらコードを書いていくのですが、交代タイミングについては後述します。
Red→Green→Refactoring
次にTDDの説明です。TDDは以下の流れで実施します。
- 仕様に従ってテストコードを書く。プロダクションコードは書いていないため、コンパイルエラー（そもそもメソッドや関数が無い等）もしくはテストコードが失敗する。
- 書いたテストコードが成功する、最小限のコードを書く。ここではテストコードが成功すればそれで良く、後のことは考えない。例えば足し算をするメソッドに対し、「1と2を引数として渡すと3が返ってくる」というテストを書いたとします。本来は渡された2つの数字（1と2）を足して結果を返すのが正しいのですが、最初は「return 3」というように固定値を返してしまって問題ありません。
- テストコードが成功する状態を保ちつつリファクタリングを行う。
- リファクタリングが終わったら1に戻り、再度テストコードが失敗する状態に戻す。
このサイクルを繰り返しながら進めていきます。1でテストコードが失敗する状態をRedと呼びます。2でテストコードが成功する状態になったことをGreenと呼び、その後3でRefactoringする。という流れです。面白いのは2ですね。最低限のコードを書けば良いので、まずは固定値を返してしまって良いのです。
お題と言語
前半戦はFizzBuzzがお題でした。プログラム言語ですが、今回はElixirを使うことにしました。1名は少しだけかじったことがあるようでしたが、私を含めた他の3名は初めて使う言語でした。
他の方がおっしゃっていたのですが、「慣れた言語で初めてのお題」もしくは「初めての言語で知っているお題」が良いとのことでした。知っていることばかりだと新しい発見が無く、逆に知らないことばかりでも迷走しやすいため良くないようです。
タスクの細分化
コードを書く前にタスクを細分化します。今回はFizzBuzzでしたが、我々は以下のようにタスク化しました。（写真を撮ってなかったので曖昧ですが、確かこんな感じ・・・）
- 100回ループするロジックを作る
- 3の倍数の時に、Fizzを返す
- 5の倍数の時に、Buzzを返す
- 15の倍数の時に、FizzBuzzを返す
- それ以外の数字の時は、そのままの数字を返す
- 上記ロジックで帰ってきた値を標準出力する
これを順にこなし、その仕様を満たすためのテストコードを書いてRedにする→実装してGreenにする→Refactoringする。という流れで作業を進めました。タスク化することで、ドライバーが書くコードが明確になってとても良かったです。
また我々はタスクを書き出す際に「3の倍数の時に、Fizzを返す」という表現を使いました。これ、「3の倍数の時に、Fizzを出力する」でも良かったのですが、「返す」という表現を使いました。「出力する」の場合、3の倍数か判断した直後に値を出力するコードが来ますが、「返す」だったので値を返却するコードとなりました。
これって実は設計なんですよね。タスクを書き出す段階で多少設計が行われており、認識合わせになっているのです。もしタスクを書き出していなければ、書いた後に「あれ、ここで出力するんじゃないの？」「いや返すだけでしょ」「どっちにしようか？」という議論が起こってしまった可能性があります。タスクを書き出すだけでこれほどスムーズに進むのだなと、すこし感動しました。
やってみての感想
ナビゲーターをやってみて
私はまずナビゲーターから入りました。ナビゲーターをやってみた感想は、考えることに集中出来て良いということでした。他のナビゲーターと、こうだよね、ああだよね。と議論し、すり合わせていると、それに従ってドライバーがコードを書いてくれる。この分業がとても心地よかったです。
手を動かしながら考えるのって結構難しいですよね？変な例えかもしれませんが、会議で議事録を取りながら司会をやるのってすごく大変で、司会と議事録係は分けますよね。それと同じような印象を持ちました。考えることと書くこと、いつも同時に行っていることですが、片方に集中するだけで無駄が少なくなりますし、何より気持ちよく作業できました。
ドライバーをやってみて
ドライバーをやってみて感じたのは、ナビゲーターをやった時と同じように分業の心地よさでした。考えないというのは言い過ぎですが、一人で悶々と考えるよりも、ナビゲーターの議論に耳を傾け、納得できればその通り書いていく。納得できなければナビゲーターに口を出すという形で進めました。
また調べものはナビゲーターが先回りして調べてくれていたため、こちらも大変楽でした。今回は初めて使う言語だったので基本的な文法から調べていたのですが、調べてコードを書いて、また調べてコードを書いて…だと、やはりテンポが悪いんですよね。コードは調べなくてもスラスラ書けるようになるまでが辛いのですが、初めて使う言語なのに辛さは一切感じませんでした。技術を学ぶ際の壁をほとんど感じなかったのが驚きです。
TDDをやってみて
Red→Green→Refactoringの章に書いたのですが、必要最低限のコードを書きながら進めます。足し算をするコードなのに実は固定値を返してしまったり等、面白くはあるのですが、ちょっと無駄だなと思うこともありました。先を見越して実装しちゃってもいいじゃん！と思っていたのですが、FizzBuzzの後にお題を変えた時に考え直しました。
https://gist.github.com/yattom/c906216ab1fdf68a133ba0fbade1a...このお題はかなり業務システムに近くなっているので、設計メインになってきます。1回のサイクルでどのくらいまで進めるかというのがポイントなのですが、先を見てあーでもないこーでもないと議論していたら、まったく実装が進まなかったのです。とりあえず動くものを作って、それから綺麗にするという、TDDの理念の正しさを強く感じました。
ふりかえりで上記のようなことを話したのですが、別の方が
「1歩を小さくしすぎると無駄が多くなるし、1歩を大きくしすぎても迷走する。1歩の歩幅をどのくらいにするかっていうのはチームで決めていかなければならないと思う」
というお話されていて、とても共感しました。
全体を通して感じたこと
チームビルディングにいい
今回は使う言語にElixirを選び、全員がほぼ初心者という状況からスタートしました。そのおかげで全員がフラットな関係になれたように思いました。例えば誰かが熟練した言語を使ってしまうと、その人がみんなに教えるというような関係が出来上がるのですが、それが無かったのです。そのような関係が悪いというわけでは無いのですが、上下関係無くフラットな関係で意見を言い合えるというのは、チームビルディングにぴったりだなと思います。
自信につながる
こうしたほうがいいかな？と思っていることを他の方が言ってくれると、とても自信に繋がります。自分とは違う意見だったとしても、「なるほど、そういう考え方もあるのか」と勉強になりますし、いいこと尽くしでした。
SIerでの活用
最初にも書きましたが、モブプロはSIerとして導入し辛さを感じていました。チームの成長も大切なのですが、期日までに決められたものを作り上げなければならないため、1つのプログラムをみんなで作るというのはやはり怖いのです。ですが、目的を絞ってうまく使いたいなと思います。どんなことに使えそうか、いま考えていることを書いていきます。
プログラミングに慣れる
月並みだと思いますが、教育の場で使うというのが、まずは取り入れやすいかなと思います。プログラミングに慣れてもらうためのプラクティスとして効果が高そうです。例えば調べるという行為は、コードを勉強するうえでの障害だと考えています。覚えてからサクサクコードを書くのと調べながら書くのだと、私はサクサク書いている状態の方が楽しいからです。
モブプロでは、言われたとおりに書くドライバーと、調べたり議論して導くことに専念するナビゲーターに分かれます。ドライバーなら調べ物をすることなくコードを書くことが出来ますし、ナビゲーターが調べ物をする際も、他の方が一緒に調べてくれるため、調べ方を覚えることができます。コードを書いたり調べることに慣れるのにぴったりだと思います。
コミュニケーションの一環として
こちらは教育目的ではなく、チームビルディングや、組織のコミュニケーション推進の効果を狙っています。
今回の我々がそうだったのですが、全員が初めて使う言語を選択すると知識の差が出にくくなります。上下関係が無くなるため、ざっくばらんにあーだこーだ言いやすくなります。またFizzBuzzのように（奥は深いけど）単純なお題であれば、コードを書くことに慣れていない人でも発言しやすいのではないかと思います。メンバーのコミュニケーションを促進する1つの方法として、とても優秀だなと感じました。
レビューの代わりに
こちらは実業務に取り入れるパターンです。使いこなす難易度としては一番高いものです。メンバーが実装した後、コードレビューを行うのが一般的だと思います。しかし完成してからの修正はコストが高くなるのも事実です。TDDとモブプロを取り入れることでうまく出来るのではないかと考えました。
例えば
「タスクを細分化し、これとこれを最低限実装してください。最低限実装したら、みんなでリファクタリングしましょう。」
という形で完成の手前まで作業をお願いし、みんなでリファクタリングすると、レビュー代わりに使えて良いのではなかなと考えています。この形であれば、1つのプログラムに数人がつくことにはなりますが、レビュー時間と手戻り時間を無くすることが出来るため、それほど負荷にはならないのではないかなと考えています。
最後に
色々書いてきましたが、純粋にコードを書く楽しさを享受できる、とても良いプラクティスでした。SIerでは取り入れにくいプラクティスだなと思いますが、ポイントを絞って導入することでメリットを享受できると考えていますし、この後実践していこうと思います。
また機会があれば、TDD+モブプログラミングでワイワイする会に参加させて頂くつもりです。この記事を読んで頂いた方も一緒に参加してくれたら嬉しいなと思います。
