メインコンテンツまでスキップ

「Lightning Review Tips」タグの記事が8件件あります

全てのタグを見る

角谷 健太

Lightning Review (以下、LR)開発チーム、入社3年目の角谷です!
最近ようやく涼しくなったので、キャンプ場に焚火しに行きました🔥
ついでに、買ってから眠っていたダッチオーブンで燻製も作ったのですが、初めてにしては美味しくできました。
ベーコン、チーズ、ソーセージの燻製を作ったのですが、特にソーセージが美味しかったです。
この調子であらゆるものを燻製にしていきたいですね。

今回は LR のTipsとして、「中間レビューごとに指摘を管理する」使い方についてご紹介します。

大きな変更を伴う開発アイテムを経験の浅い開発者が担当する場合、一度のレビューで成果物の全体を確認すると、似たような指摘が大量に発生してしまうかもしれません。
コードレビューを例に挙げると、私の過去の経験では以下の内容で指摘されることが複数回ありました。

  • ソースコードのコメントの書き方がコーディング規約に沿っていない
  • 処理が共通化されておらず、コピーコードになっている

効率的な開発のためには、早めに問題点を検出し、類似のミスはしないように進めていくことが大切です。

このような問題に対して、私たちのチームでは成果物が完成する前に何度かレビューすることを「中間レビュー」と呼んで実施しています。
開発途中の成果物に対して、中間レビューで識者の指摘をもらうことで、開発者はその後の開発において中間レビューの指摘を参考に、成果物の問題点を事前に摘み取りやすくなります。
中間レビューでもらった指摘は、LR を使うと例えば以下のように管理できます。

中間レビューを実施したレビューファイルの画像

LR では一つのレビューファイル内で複数のドキュメントとアウトラインノードを自由に作成できるので、中間レビューごとにドキュメントやアウトラインノードを用意すれば、指摘を簡単に分類できます。
開発者は中間レビューでもらった指摘と類似の指摘がその後のレビューで出ていないかを確認することで、自身の仕事の振り返りにも活用できます。

ぜひ、試してみてください!

新美 真

Lightning Review(以下、LR)開発チーム、入社6年目の新美です!
11月に入ってあったかいものがおいしい時期になりましたね。
こんな時期には、やはりラーメンが食べたくなってしまいます🍜
寒くなくても週3で食べてしまうんですけどね……

今回は、LRを活用してレビューアへの相談事項を管理するTipsをご紹介します。

レビューで見てほしいポイントは独力では作り込めなかった、あるいは不安なポイントであると思います。
そんなポイントをレビューで相談できるようにLRを活用しましょう。
作り込みの最中でもLRを利用して不安なポイントを保存しておけば、よりレビューアの知識を引き出せるレビューとなるはずです。

たとえば、外部仕様の作り込みで不安なポイントを指摘にします。
具体的には、ダイアログのテキストボックスにおいて不適切な文字列を入力された場合に、ダイアログのOKボタンを無効にするか、OKボタンを押下したあとにエラーダイアログを表示すべきかで悩んだとします。
その場合に上記のような不安なポイントを指摘として登録することで、レビューの場ではどのような考え方や判断をして、どちらを採用すると良いのかをレビューアに聞くことができます。

consultation

そして、レビューアに聞いた方針を元に、レビューイがその方針とした理由とともに修正内容を記し、修正済みにステータスを遷移させます。

modified

レビューアは修正内容を確認し、レビューイの理解度も確認した上で確認済みにステータスを遷移させられるため、指導も指摘修正も、どちらも確実にやり切れます。

上記をヒントにしていただき、相談事項をLRでレビューアと共有すれば自分の不明点も解消でき、より質の高いレビューにつながると思います。

実際、私はレビューア・レビューイの両方の立場となった経験がありますが、レビューのポイントを絞って集中して議論できるため、とても効果的に感じました。

ぜひ、試してみてくださいね!

加美川 真由子

レビューとは一口にいっても外部仕様や実装、テストなど対象となる工程も幅広く、成果物も仕様書や設計書、ソースコードなどさまざまです。
また、レビューでチェックすべき項目や検出される指摘の種類も、工程や成果物ごとに異なります。
このように多様な工程や成果物に対して、レビューを実施するたびに指摘の分類や原因工程・検出工程、カスタムフィールドなどのレビューに必要な情報を毎回レビューファイルに設定するのは大変です。

そこで、工程別のレビューファイルのテンプレートを事前に作成することをオススメします。
指摘の分類や原因工程・検出工程、カスタムフィールドなどが設定されている既存のレビューファイルから指摘を削除し、工程別にテンプレートとして保存します。
保存したテンプレートからレビューする工程に合ったテンプレートを選択してレビューファイルを作成することで、既にレビューファイルに必要な情報が設定された状態でレビューを開始できます。
これにより、複数の工程に対してもレビューファイルの準備に手間がかかったり、もれがあったりすることなくレビューを実施できます。
テンプレート機能の詳細はこちらを参照ください。

さらに、Lightning Review 開発チームならではの使い方を紹介します。
事前に工程別のテンプレートに、図のようにセルフチェック観点をあらかじめ指摘として登録しておきます。
レビュー前に、レビューイはセルフチェック観点に対する処置内容を指摘の[修正内容]欄に記入し、その指摘のステータスを[修正済み]にします。
例えば、実装工程で処理速度が妥当か確認する観点であれば、処理速度の計測結果を[修正内容]欄に記入します。
そして、レビュー時にレビューアが確認して、処置内容が妥当であれば、指摘を[確認済み]にします。
レビューファイルにセルフチェックの指摘があることで、レビューイはレビュー準備の際にセルフチェックを忘れずに実施できますし、レビューアもレビューイがどのようにセルフチェックを実施したかを指摘の[修正内容]欄から確認できるため、重要なチェック項目について認識の誤り・ずれなどがあってもレビューで摘み取ることができます。

selfcheck