heyでSTORESのECサービスを開発をしている morihirok です。

STORES ECでは2019年ごろからモブプログラミングを徐々に導入し始め、今ではモブプログラミングだけでなくいろんなモブ〇〇が誕生したので、その紹介をします。

そもそもモブプログラミングとは

モブプログラミングを簡単に説明すると「チーム全員で同じ時間に同じ画面を見ながらプログラミングすること」です。

詳細な説明はここでは割愛しますが、私たちのチームで初めてモブプロに参加する人を受け入れるときに読み合わせる資料を紹介させていただきます。

なお、弊社（hey社）は昨年よりほぼリモートワークに移行しており、「チーム全員で同じ時間に同じ画面を見ながらプログラミング」は、ビデオ会議システムの画面共有機能を使用して実現しています。誰かの共有された画面を見ながら、チームでわいわい話しながら進行していくイメージです。リモートワークの方が自分が慣れた環境で行えるためむしろやりやすいとの声があるほどで、特に苦労せず行えています。

誕生したいろんなモブ〇〇

モブプログラミングは私たちの多くのチームにマッチしていたようで、広く採用されるようになりました。また、この良さを応用し様々な場面でモブ〇〇が誕生し実践しているのでその紹介をしていきます。

モブレビュー

STORESではモブプログラミングを採用していますが、全ての仕事をモブプログラミングで行っているわけではありません。

例えば、一人で深くじっくり考えて設計してコードにしていった方が良い場面もあるでしょうし、カッとなって何かを作ることもあると思います。こういう瞬間がエンジニアをやってて楽しいと感じるときだったり成長を感じるときだったりするので、最大限やっていきたいという気持ちはありつつ、こういうコードは得てして差分がデカくなりがちです。そして差分がデカいPull Requestはレビューするのに腰が重く滞りがちになります。

そういう時に使うのがモブレビューです。

コードを書いた人（レビュイー）とレビュワー数人が集まり、レビュイーは画面共有しながら自分が書いたコードを説明していきます。レビュワーは随時質問をすることができ、すぐにレビュイーから回答を得ることができます。この会が終わったのち、もう一度レビュワーはいつも通りコードレビューします。

この取り組みの良いところは、自分が書いたコードの説明の意図や質問が気軽にできることです。

私はコードレビューをしていてわからないことがあったとき、さっと聞けばよいのについついフレームワークやプロダクトの詳細な実装をわかるまで調べてしまって必要以上に時間をかけてしまうことがあります。それはそれで良いこともあるのですが、モブレビューではそれをする前にまず聞こうという気持ちになれるので、レビューのハードルを下げることができます。

またレビュイーとして、Pull Requestの説明にコードや設計の意図を書き切ろうと思っても、文章だと伝わり切らないことがあります。モブレビューではレビュワーが知りたいと思った設計の意図を、ここに至った心境の変化まで含めて説明することができるので、より伝わりやすいと感じています。

おまけに「もっとこうすれば良いのでは？」というコメントがあればそのままモブプロに移行もできるのでとても便利です。

そもそも大きい差分になるPull Requestはもっと細かい粒度にしようという話もあると思いますが、それが大事な場面もあれば大きいものを大きいままレビューすることができるならそっちの方が良い、ということもあると思うので、チームで用法用量を守ってストアオーナーさんに一番安全かつ素早く価値を届けられる手法を選択することが大事だと思っています。

モブオンコール対応

サービス運営を行う中で切っても切り離せないのがオンコール対応です。ログ調査、コードリーディング、データ修正スクリプトの作成などなど、これらを臨機応変に組み合わせて対応する必要があります。

こういった対応もモブで行うと良いと感じました。ひとりの画面を複数人で確認しながらオンコール対応を行うのです。

オンコール対応にはどうしてもプレッシャーがかかります。プレッシャーがかかるとミスが発生し、より重大な問題に発展してしまう危険性があります。モブで行うことによってひとりひとりにかかるプレッシャーを分散させることができ、同時にダブルチェック機構にもなるのでミスが起きる可能性を減らすことができます。

また、複数人で行うことで様々な知見を持った人によって対応することになるので、ひとりでは思いつかなかったより良い対応策を実施できる可能性もあります。さらに、オンコールの際の温度感や何が課題だったのかを複数人で共有することによって恒久対応までのスピード感も上がります。

モブQA

STORES ECには専属のQAチームは存在しないので、QAは開発者をはじめプロダクトに関わる全員を巻き込んで行っています。そしてSTORES ECのQAは手動のリグレッションテストが大部分を占めます。

STORES ECは機能が多いサービスなので、リグレッションテストはなるべく自動化してやるべきQAに専念したい。それは本当にそうなのでそういう改善が現在進行形で行われているのですが、今そうなっていないなら安心安全なシステムをストアオーナーさんに届けるためにもやらないといけない。しかし手動での動作確認を網羅的にやるのは集中力を要する。特にこのリモートワーク環境においてはひとりで集中力を保つのは辛い。

ということで、これらの作業をモブでやるという試みも多く行われています。

「モブで行うことによってひとりで行うより集中力を保つことができた」

「動作確認中に気になった細かいことをメンバーに気軽に聞けて、おかげで改善につながった」

「モブでやっても辛いものは辛い」

といった意見が出ていたので、良いところは残しつつも手動によるリグレッションテストの自動化とより良いQA体制の構築は今後STORES ECの課題のひとつと言えそうです。

モブスキーマ定義

STORES ECではSwaggerを利用してスキーマ定義を行い、それをフロントエンドチームとバックエンドチームが参照する形で開発を行っています。そして、このスキーマ定義自体をフロントエンドチームとバックエンドチーム合同のモブで行っています。

swagger.io

モブで行うことによって、APIの設計がバックエンドの都合に引っ張られることを防ぎ、フロントエンドが使いやすいAPIを設計しやすくなると感じています。さらに、スキーマ定義にフロントエンドチームもバックエンドチームも関わることによって、そもそも開発するものに対する認識のズレを整理することができ、手戻りを少なくすることができています。このときに「こういう選択肢もあると思うけど、こういう理由でこっちにした」みたいな話もできるので、後になって「私はこっちの方がよいと思っていた」みたいなコミュニケーションも発生しにくくなります。スキーマ定義は選択肢が増えやすいので、そのコンテキストまで含めて共有できるのは有用だと感じています。

モブスキーマ定義にはフロントエンドチームもバックエンドチームも全員参加しているので、そこそこの開催コストがかかっていますが、それでも十分にペイできるほどの効果があることを実感しています。