モブプログラミングで技術的負債に立ち向かう––「チームでコードを読む」ことがもたらすもの

小さな成功体験を積み重ねてチームで負債に立ち向かう

佐々木達也氏（以下、佐々木）：では発表させていただきます。『小さな成功体験を積み重ねてチームで負債に立ち向かう』というタイトルで発表します。

クラッシーという会社から来ました。クラッシー、名前聞いたことあるよいう方はどのくらいいらっしゃいますか？

（会場挙手）

おお！　すごい！　ありがとうございます。一切手が上がらないんじゃないかと思ったら上がりました。

（会場笑）

普段ネット上ではささたつ（@sasata299）という名前で活動しています。

クラッシーでCTOをしていて、子供が2人います。最近のマイブームはサイゼリヤで豪遊することです。エンジニアはみんなサイゼリヤが好きじゃないですか。

（会場笑）

それに漏れず僕も定期的に通っていて、明日も会社の同僚とサイゼリヤ飲みがあるのでそれを楽しみに今週はがんばってきました。

あ、そういえばみなさん唐揚げお好きですか？

（会場笑）

唐揚げ、食べるのが好きだよという方？

（会場挙手）

お、意外とみなさん唐揚げ好きなんですね〜。唐揚げ、作るのも好きだよという方います？

（会場挙手）

ありがとうございます。まぁ、なかなかいないですよね。僕は「唐揚げを食べるのが好きなんですね」ってよく言われるんですけど、実際には唐揚げを作るのがけっこう好きです。それだけ今日覚えて帰っていただければなと思います。

（会場笑）

クラッシーの概要

ということで、ここから本題に入っていきます。最初にクラッシーとは？　というところで、なかなかみなさん知らないと思うのでご説明します。クラッシーはベネッセとソフトバンクが作ったジョイントベンチャーになります。

学校に対してサービスを提供していて、学校をより良い場所にしたいなと思ってがんばっています。教育×ITということで、EdTechの会社です。

先生や生徒向けにいろいろな機能を提供しています。学習系の機能や、先生と生徒だったり先生と保護者の間のコミュニケーションの機能とかですね。他にもいろいろありますが、こういった機能を学校に提供しています。

今のところ高校を中心にサービスを提供しているのですが、日本に高校は公立と私立合わせて5,000校あります。

その中で、現在2,100校ほどの学校に使っていただいています。有料ユーザ数と書いてあるんですけど、生徒の数は80万人を超えたくらいになっています。

技術的負債を返却する

今日のテーマは技術的な負債というところで、何を話そうかなと思ったんですけど。負債はみなさんあるかなと思ってます。負債があればもちろん直したいってなるじゃないですか。今日は負債を返却する話をしたいなと思ってます。ただコードは一切出てきません。いらすとやのイラストだけがたくさん出てくるので気軽に聞いてください。

（会場笑）

技術的な負債を返却するためには2つ必要かなと思っていて。1つがオレンジ色で書いてある、改修をするための人だったり時間だったり。リソースが必要かなと思ってます。

もう1つは「いけるいける！」という気持ち。この気持ちが大事かなと思っていて。改修のためにリソースに関しては、もちろん当然必要で。クラッシーとしても会社としてプロジェクト化して進めているんですが、今日はここには触れずにいこうかなと思っています。

今日はこっちの「いけるいける！」という気持ちのほうで話をできたらなと思っています。さっきの2つはどちらも必要かなと思っていて。気持ちの部分はベースの土台として必要だなと感じているんです。

ただ、現実は諦めの気持ちになりやすいかなとも思います。なかなかいろいろなしがらみがあったりするので、「密結合していて影響範囲が～」という話だったりとか、既存コードや設計に対する不満、それから「こうしたいんだけどなかなかできないな」とか、「テストがなくて触れません」とか。いろんな理由があって諦めの気持ちになりやすいかなと思います。

……あれ、そんなことないですか？

（会場笑）

そんなことありますよね。なのでそれをどうやって「いけるいける！」という気持ちに持っていったらいいのかという話ができたらなと思っています。

負債を返却するためにやったこと

現状の体制を簡単に図にしてみました。すごくシンプルにしていますが、機能がいくつかあってそれぞれの機能に1人2人担当が付いて回しています。

1人2人が各機能に付いているので、調査だとか改修だとかいろんな話がきたときに、個人の力で解決しているケースが多いです。いろんな不具合が発生したりして対応するんですが、その対応だけで手一杯になってしまって。

なかなかそれを改善するところまでいかないのが最近の悩みで、これをなんとかしたいなと思っていました。

そんなとき1人新しくジョインしてくれたメンバーがいて、そのメンバーがペアプログラミング・モブプログラミングの経験者でした。そこで、一度やってみることにしました。

モブプロはすでにみなさんご存知かもしれませんが、ペアプロは2人で一緒にコードを書いていくんですが、それが3人以上になったものがモブプロになります。

それをやってみようということになりました。とは言っても僕自身ペアプロ・モブプロの経験はほとんどありませんでした。どちらかと言うとネガティブなイメージを持っていて。やらず嫌いですね。

そもそも見られながらコーディングするのはちょっと緊張するなぁというのと、複数人で、ペアプロだったら2人ですけど、複数人でコードを書くのでなんだか効率が悪いような気がするなぁと思っていました。

ただ、そのメンバーからいいですよと教えてもらったので、まずはやってみようと思ってやってみたんです。そうすると、みんなでワイワイ言いながらコードを見るのが純粋に楽しいなぁと。

いきなりすごいことはもちろんできないんですけど、ちょっとだけでも前進している気持ちが味わえて、これはすごく大きなメリットなんじゃないかなと感じました。

モブプロをやってみると、例えば自分がある機能の担当になってその機能をいきなり全部把握してくださいと言われるとすごくハードルが高いんですが、みんなで一緒になってコードを読むと、1人だと読めなくて諦めてしまうコードであっても読めると感じました。

複数人で読んでいると、そんなに詳しくなくても多少仕様や背景を知っているメンバーがいたりします。そういう人たちから適宜「ここはこういう背景でこうなってるよ」と教えてもらうことでだいぶ違うなというのを実感しました。

仕様の理解がすごく早くなって、物事が進むというところ。あとは複数人でみんな同じ時間を過ごしているので、知見はもちろん、やれた感が貯まります。

やる前は「これはちょっと難しいよね」ってみんな思っていたんですが、やってみると「意外とできたね」という気持ちが参加者の中で醸成されました。

整地部が始動

なかなかいいなと思ったので、整地部という活動を社内で始めました。これは会社の中でフットサル部だとか、クラッシーの場合だとスイーツ部というスイーツをただ食べるという部とか、いろんな部活動があるんですけど。その1つとして整地部というのを立ち上げました。

週に2時間集まって、みんなでコードを改善していこうという活動です。ちょっとしたことなんですが、変数名を変えるとか、コードの一部分を別メソッドに切り出すとか。ボーイスカウトルールの精神でやっていこうという集まりです。

ボーイスカウトルールはみなさんご存知かもしれませんが、すごくいいなと思ったのが、「汚したのが自分じゃなくてもしっかりきれいにしていこう」という考え方です。これをみんなが意識して、地道な活動ですが繰り返していくことで大きな結果につながるんじゃないかなと思って始めています。

凶悪なSQLに複数人で読み解く

これはとある一例なんですけど。

（会場笑）

凶悪なSQLがいて、「ウッ」ていう、個人だったら見なかったことにしようとしてしまうSQL。会社の中でみんな、このSQLはやばいという共通認識がありました。「やばい！」とは言うんですけど、みんなそのあとなにも言わないという。そういうやつです。

（会場笑）

これを改善したいんですが、やっぱり読み解くのが辛かったりとか。そもそもこの部分にテストが書かれていなかったりして、下手に触るとデグレしちゃうんじゃないかというところでなかなか手が付けられませんでした。

ここでちょっとモブプロを試してみようと思って、複数人で集まってコードを読んでみました。読んでみると意外とそんなにたいした処理はしてなくて。なんでこんなたいした処理じゃないのに複雑に書いてるんだっていう疑問はあるんですけど。そんなに複雑なことはしてなくて、読めました。

読んだから、次はまずテストを書いてみようという話になりました。やってみると、多少時間はかかったんですけどしっかりテストも書けました。テストがあれば今度は改善はしやすいじゃないですか。デグレすることはないので。という状態まで問題なくもっていくことができました。

先ほど「やれた感」と言いましたが、「意外とやれたね」というのが集まったメンバーの中で共通認識になったっていうのがすごく大きな成果だったかなと思っています。

成功体験が自信を生み出す

ほかにも、整地部というラベルを付けて活動してるんですが、コードの改善をしたり、メトリックを取れるようにしたりとか。

よくありがちだと思うんですが、呼び出されていないように見えるメソッドが、でもなかなか消せない問題とか。

これも4、5人集まっていたので、そのメンバーで「これ絶対いらないよね」っていう合意をして、もし呼ばれていたらわかるような仕組みにしてしばらく様子を見ました。そうして、最後には全員で確認しながら消すのをやっていたりします。

これもすごくやってよかったなと思っています。今まで「改善しなきゃ」「やらなきゃ」と言っていたところが少しずつできてきたのを実感しています。小さなことなんですが、物事がきちんと進んでいるなと思っていて。成功体験だなと感じるんです。

この成功体験が積み重なっていくことで、だんだんと「いけるいける！」という前向きな気持ちになってきたなと思っています。これがすごくよかったなと。

モブプロなどを経て、技術的負債の返却は大変なんですが、やれないことはないというマインドになってきたのがすごく大きな成果でした。

コードをたくさん書く＝価値ではない

ただ、素朴な疑問として、1人で書いたほうがコードは何倍も書けるよねという話は当然みなさん思われるかなと思います。

ただ、そこはちょっと待ってください。我々は問題解決のためにコードを書いているのであって、決してコードをたくさん書きたいわけではないと思います。

その観点で考えると、プルリクを出すまでは1人が間違いなく早いですが、結局プルリクって誰かがレビューしなきゃいけなくて。レビューするのってベテランがやりがちな作業だったりするので、結局時間はそれなりにかかっています。

プルリクをマージしてリリースしてというところまで考えると、どっちが早いんですかね？　っていう。そこはぼかして終わろうかなと思うんですけど。

（会場笑）

いろんな知見が貯まるということもあるので、メリット・デメリットはありますが、モブプロにもメリットはあるんじゃないかなと思っています。ベテランがしっかりコードを書くのに時間が割けるというところも1つのメリットなのかなと感じます。

最近はPRのレビューもペアプロでやったりします。いちいちGitHub上で非同期のやりとりすると時間かかっちゃうので、これはこれで便利なときもあるなと思うんです。

ということでまとめです。

小さな成功体験を積み重ねることで、だんだん「いけるいける！」という気持ちになってくるはずだと思っています。そのために別にこれだけがやり方ではありまあせんが、モブプロも1つの有効な手段なのかなと感じています。

クラッシーでも、みなさんと一緒ですがエンジニアを絶賛募集中なので、興味のある方は一緒においしい唐揚げを食べにいけたらなと思います。

今日もすごくおいしい唐揚げが出るんですけど。もっと食べたいという方は来てください。

（会場笑）

ご静聴ありがとうございました。

（会場拍手）