チェック地獄にはコレ。ビジネス職もマネしたいエンジニアの仕事術
こんにちは。ファームノート編集部の秋山ウテです。
今回紹介するのは、札幌オフィスエンジニアチームの仕事術。
エンジニアといえば、1人で黙々とコードを書いているイメージがありました。
ただ、札幌オフィスを覗きに行ったところ、ビジネス職の僕にとって意外な仕事の仕方をしていました。
モクモクやるのもいいけれど…
ファームノートエンジニアチームの”team S”。
札幌オフィスを拠点に、データのインプットがよりスムーズになる仕組み作りを、3人で取り組んでいます。
チームの立ち上がり当時は、3人個別でコードを書いて、こんな感じでモクモクとやっていたそうです。
＊Slackの対応をする、普段の”team S”メンバー＊
ただ、エンジニアあるあるらしいのですが、3人で分担してコードを書いていくと、壁にぶち当たる懸念があったそうで…
レビューを意味あるものに
それが、レビュー地獄！
プログラムを作る時、一般的にはチームメンバーが書いたコードを、別のメンバーがレビュー（チェック）をします。
これが相当つらいそうなんです。
例えば、レビュー時にこんなことが見えづらくアドバイスに悩むことも…
『どうしてそうしたの？』
『そもそもこれってなんのために始めたの？』
もっと早く相談してくれれば…と思うこともあるそうです。
そのうち聞くこと自体が億劫になって、『うん、なんか動いているし良さそうだねー。』で進んでしまう可能性も…
レビュープロセスの意味がなくなっちゃうリスクがあったそうです。
なら、同時にやってみよう！
そんな危惧から、エンジニアの北村さん提案で”モブプログラミング”を始めた、”team S”。
ざっくり説明すると、モブプログラミングとは、複数人でプログラミングとレビューを同時に行うもの。
コードを書くこととチェックを同時にやるので、コードの背景や経過がわかります。
背景がわかるので、適切なアドバイスができて、よりよいコードになるそうです。
また、経過もわかるので、間違いに気づきやすいのです。
＊”team S”が実践しているモブプログラミングの様子＊
で、実施するときは、ドライバー（1名）と、ナビゲーター（それ以外）に分かれます。
そして、ドライバーの画面を大きめのモニタに写して、コードを書いてもらいます。
＊ドライバーの画面を大型モニタに同期させています＊
で、同時にナビゲーターがコードのレビューやアドバイスをしていきます。
ドライバーがずっと書き続けていると疲れてしまいます。
そこで、"team S"では10分おきに交代をしているようです。
手に入れた、前に進んでいる感
やり始めて気づいたのは、物事が前進している実感があること。
複数人で同じことをやるので、単体でやるよりも最初の一歩を踏み出しやすくなるんですね。
3人寄れば…
また、"team S"に聞いたところ、3人同時に取り組むことで、早く解決策が見つかったことがあるそうです。
『プログラムがこんな動きをするはずがない！』といった謎の不具合が発生したときに、みんなで取り組むことで迅速に解決。
まさに、3人寄れば文殊の知恵ですね！
で、逆にやってみて良くなかったことは？と聞いたところ、「ないですね、1人でやっている時の方が集中してないかも。夕方にはヘトヘトです。笑」とのことでした。
やってみてわかったこと
実際にやるにあたって気をつけるべきことも聞いてみました。
Q：やるにあたって、大事なことってありますか？
A：大事なポイントは、”素直さ”。
自分の疑問点を素直に言える人なら大丈夫だそうです。
適切なアドバイスが行えるためのマナーなんですね。
Q：新人のメンバーが入っても大丈夫ですか？
A：新人が入ってきても大丈夫だと思いますよ。
レビューのとき、人間的な相性の問題でうまくいかないケースがあると思います。
ただ、レビューする人が複数人いるので誰かしらその場でフォローできるかなと。
Q：何人までいけます？
A：3〜5人らしいです。
3人だとちょうどいい感じ。
自分がそこにいて意義があると思える状況が大事。
＊＊＊
この仕事術は、エンジニアチームだけでなく、応用すればビジネスサイドでも有効だと思いました。
（実際に資料作りのときにやってみます！）
また、僕たちが大切にしているバリューの一つ、Connectedな仕事術だなーとも感じました。
さらに！"team S"のmohyaさんが、モブったときの体験記をまとめてくれたので、あわせてどうぞ☺
次回もお楽しみに！
取材：髙木健介& 秋山ウテ
編集：秋山ウテ
取材日：2019年4月25日
このnoteを気に入っていただけたら、「♡」をぜひ！
より良いコンテンツを作っていく原動力になります。
リクエストもお待ちしているので、お気軽にコメントください！