この記事はフリュー Advent Calendar 2023 の19日目の記事となります。
前日の18日目は@yoshida_eriさんのルーター設定をPythonで自動化してみた記事だったのですが、自動化できそうなところは自動化する！（そして楽する）というところにとてもエンジニア感を感じました。普段触らない領域の話だったので、内容もとても興味深かったです。
ぜひそちらの記事もご覧になってくださると嬉しいです。

1.はじめに

この記事では、スプリントレビューでリアルタイムに実装修正をするメリット・デメリットを説明します。

おはようございます、フリュー株式会社でiOSアプリエンジニアをしていた里形です。新卒2年目で、今はサイト側の実装やなんやかんやをしています。

サイト側の実装を担当することになり、最近はReactなどを触っています。
UIKitやKotlinで実装していたネイティブアプリと比較すると、実装したUIの確認がリアルタイムでやりやすく、そこに面白さを感じています。
この、”UI実装をリアルタイムで変化させることができるメリット”に着眼した結果、「スプリントレビューで指摘点をリアルタイムに反映したらカッコ良すぎるんじゃないか？」 という発想に至りました。
実際に試したところ、かなりレビューが盛り上がり、クオリティの向上に寄与できたと思います。（さらにチヤホヤしてもらえます¹。）
なので今回は、体験から導き出されたメリットデメリットをご紹介いたします。

2. リアルタイム修正のやり方

私はリアルタイムで修正するときは、Chromeのデベロッパーツールを使用しています。
詳細に関しては公式のヘルプを参照ください。

3. メリット

スプリントレビューでライブコーディングをやるメリットをあげると、大きく4点あります。

レビュワーのモチベーションが高くなる
改善策の具体像がその場の人全員で認知できる
修正の規模感を非エンジニアに体感してもらえる
言語化できない要求の解消が早い

一つずつ解説していきます。

レビュワーのモチベーションが高くなる

ライブコーディングはレビュワーのモチベーションを高めるのに有効な手法であると考えています。
なぜならば、レビュワーの意見を肯定的に受け入れていることを、ライブコーディングで表現できるためです。
レビューで提案したアイデアを採用してもらうと、誰でも嬉しくなりますよね。
そのため、レビュワーの意見を肯定的に受け入れることで、レビュワーの当事者意識と積極性を高めていくことができます。
その結果、レビュワーから良質なフィードバックを数多くもらうことができ、プロダクトの品質を高めることができるようになります。

改善策の具体像がその場の人全員で認知できる

大人数でレビューを行ったときに、周りは納得しているのに改善策の方向性がよくわからず、困った経験はないでしょうか？
私自身もたまに、言葉だけで改善策が決定したときは、方向性が掴めずにモヤモヤすることがあります。
実際、言葉だけでやりとりをした場合、意図とは異なる受け取り方をされることは多いと思います。
しかし、ライブコーディングで修正を行うことで、その場の全員が視覚的に修正の方向性を理解することができます。
これにより、メンバー間での認識の齟齬を減らしたり、属人性を低くしたりできます。
また、ステークホルダーも次回以降のスプリントに実装されるインクリメントを予測しやすくなり、フィードバックの材料を増やすことができます。

修正の規模感を非エンジニアに体感してもらえる

非エンジニアとやりとりをしている時に、よくいただく意見の一つに「この修正がどのくらい大変かわからないから、気軽に頼んでいいかわからない」といったものがあります。
あくまで体感ですが、こういっていただいた時の50%くらいはとても軽微な修正であることが多いと思っています。（特にちょっとしたデザイン修正など）
ライブコーディングで変更している様子をお見せすれば、ちょっとした修正にかかる時間をそのまま見ることができるので、なんとなくの規模感を少しでも掴んでいただけます。
これによってエンジニアにちょっとした相談をするハードルを下げることができれば、よりプロダクトの改善速度が上がるのではないかな、と予想しています。

言語化できない要求の解消が早い

弊社では、ディレクターチェックなどを行ったときに、言語化できない要望が発生してとても頭を悩ませるといった話を部門の内外で聞くことがあります。
具体的な例を挙げると、「ここがなんか可愛くない²」とか「なんとなくだけどなんか違う」などがよく聞く機会があると思います。
同じような悩みを抱えていらっしゃるエンジニアの方は世の中にたくさんいるんじゃないかな、と感じています。
これを解消するには、"時間をかけてより詳細にヒアリングする"、"デザイナーと再整合する"、"いくつかの案を再提案する"などのアクションを取ることが多いと思います。
しかし、これらのアクションは変更と再チェックが非同期的で、要望の汲み取りが不十分だと、終わらないディレクターチェック³を誘発することが多々あります。
ライブコーディングでレビューを行うと、レビュワーも変更点の比較が瞬時に行いやすく違いがわかりやすいため、徐々に要望の言語化ができるようになります。
そのため、明確なFIXが導き出しやすく、修正の工数がかなり抑えられると感じています。
個人的にはこのメリットはかなり大きいと感じています。

4.デメリット

デメリットとしては、レビューの時間を多めに時間を取る必要があることと、CSSに関する知識がある程度必要なことが挙げられます。

レビューの時間を多めに取る必要がある

デモとフィードバックに加えて修正を行うため、通常のレビューと比較するとかなり多めの時間が必要になります。
経験的には通常の2倍くらいは時間をかけていると思います。
そのため、タイムキーピングをしっかりと行わないと、レビュー全体がグダグダになってしまう可能性があります。
しかし、上記で挙げたメリットを考えると、生産性の面では2倍以上の価値があると体感しているので、事前に時間配分さえ決めてしまえばメリットの方が上回ると考えています。

CSSに関する知識がある程度必要

フィードバック内容を即座に反映するためには、やはりCSSの知識がある程度必要になるかと思います。
僕自身もライブコーディング中に助言をいただくことが何度かありました。
個人のスキルがあれば対応可能範囲もかなり広がると思いますが、チームメンバー全員で実装修正を行えれば、このデメリットもあまり問題にはならないかと思います。
また、フィードバックを受けた箇所の修正方法がわからない場合は、その場では修正をしない選択肢を取るのも一つの手です。
1点目のデメリットでも述べましたが、不用意に時間を使ってしまうと、スプリントレビュー全体がグダグダになってしまう可能性があるためです。

5.まとめ

提案内容をその場で実現してもらえると強い肯定感が生まれ、モチベーションにかなりいい影響を与えていると思います。
また、エンジニアとしてもディレクターやステークホルダーに「すごい」って言われるのは純粋に嬉しい気持ちになります。
パフォーマンスとしての側面だけでなく、生産性の側面で大きなメリットがあると考えているので、ぜひみなさんも実践してみてくださると嬉しいです。

実際にもらえたコメント->「xxxさんとyyyさんのライブ感。かっこいい＆こういうの見るのとても勉強になる。」「パッと変更できてすごい・・」など。 ↩
『ディレクターの「可愛くない」という抽象的なフィードバックで頭を悩ませた』と聞いていたが、都市伝説だと思っていたので、僕も実際に耳にしたときは戦慄した。そして"かわいい"を学ぶ修行をすることを心に誓った。 ↩
僕らは無限ディレクターチェック編と呼んでいる。 ↩