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

Lightning Review (以下、LR)開発チーム、入社7年目の新美です。

7月に入って夏も本番、毎日とても暑いですね～！
スタミナがつく料理を食べて元気に夏を乗り切りたいですね。

さて、今回のブログはレビューの進行状況を確認しやすくする LR の Tips をご紹介します。

みなさんはレビューファイルをどのタイミングで作成するでしょうか？
必要になったタイミングでレビューファイルを作る人が多いと思います。
そのようなやり方でももちろん LR を活用できますし、自分もそのやり方をしていました。
ただ、そのやり方をしていたときに自分は残りのレビューをあとどれくらいやる必要があるのか、全体感を見通せないことに課題を感じることがありました。

そこで、ご紹介したいのが今回の Tips です。
（この Tips は過去にご紹介した「工程別のテンプレートにセルフチェック観点を登録する」と組み合わせたものになっております。 よろしければ、ご一読ください。）

開発する機能が決まった段階で、一番最初に、機能×工程で、ワークスペースフォルダにレビューファイルをすべて作成します。
こうしておくことで、実施すべきレビューの全体感を把握できます。
また、レビューファイルにセルフチェック観点の指摘を登録していれば、未完了であることがよりわかりやすくなります。

上記の状態からレビューを進めていくと、各レビューファイルのステータスが遷移します。
これにより、どれが終わっているのか、レビュー中なのか、あるいは未実施なのかがぐっとわかりやすくなります。

今回はレビューの進行状況をわかりやすくするための Tips をご紹介しました。
レビューの全体感を把握し、漏れなくやり切るための工夫のひとつとして、ぜひお役に立てください！

Lightning Review (以下、LR)開発チーム、入社2年目の瓜生です。
もう6月も後半、2024年も半年が終わってしまいます、早いですね！
1年が充実したものであったと振り返られるように毎日を過ごしていきたいところです！

さて、今回のブログはレビュー実施をより有意義なものとする振り返り活動と、その振り返りに役立つ LR の Tips をご紹介します。

改善の余地のある活動を行った後、その振り返りを行うことには、メンバーの成長や仕事の改善につながるなどのメリットがあると言われています。
こちらは、もちろんレビューにも当てはまります。
レビューを通じてメンバーの成長や仕事の改善を狙いたい場合は、レビューを実施した後、そのレビューの振り返りを行うと良いでしょう。
レビューの振り返りにおいては様々な実施観点が考えられますが、例えば以下の観点で振り返ります。

• レビューは適切に実施されたのか
• もっと良くするためにはどうすればよかったのか

どこが良かったのか悪かったのか、例えば説明の順序をこうしていればよかったなど、次のレビューではその振り返りが活かされることでしょう。

また、振り返った内容を記録として残しておくと知識の蓄積にもなります。
そんなとき役に立つのが LR のノート機能です。
この機能では、テキスト形式またはマークダウン形式で議事録やメモを取ることができます。
レビューの振り返りで挙がった課題や改善案をノートに記録しておけば、次のレビューを実施する前にレビューファイルを確認することで、振り返りの内容を活かして自分の仕事の進め方を改善できます。

例えばLRチームではノート機能を以下のように活用していました。

レビューを行った直後にレビューイ、レビューアが2人でそのレビューを振り返りました。
その振り返りでは、レビューの効率を上げるための以下の改善案が出されています。

• レビュー対象の概要を先に説明する
• 成果物の内容ではなく、どのような考えで成果物を作成したのか説明する

その結果、以降のレビューでは、より効率的にレビューができるようになりました。

レビューの振り返りを行うことのメリット、さらに、振り返りをより有意義にする LR の活用方法をご紹介しました。
日々のレビュー実施をより有意義なものにするお役に立てたら嬉しいです！

Lightning Review (以下、LR)開発チーム、入社6年目の箕浦です。

久々のブログ担当です！もう5月も半ばですね！
だいぶ暖かくなってきて、毎朝ギュンギュンの満員電車で出社するだけで汗だらだらです💦
これから梅雨に入り、さらに湿気が加わって滝汗必至ですね。恐ろしい😱

さて、今回のブログはレビュー実施の際に気を付けたい「レビューアとの成果物の目的の共有」 について、私の失敗談も交えて、その重要性とやり漏れを防ぐ Tips をご紹介します。

みなさんはレビューアにレビューをお願いする際に、成果物の目的を共有していますか？
これは、特にマニュアルに対するレビューなど、ドキュメントレビューを効果的に行うために重要だと考えています。

目的を共有しておけば、少なくともそれに沿った観点で成果物レビューするので、なんとなくのレビューを防止し、より効果的なレビューがしやすくなります。
また、成果物の作成者も目的の再確認ができ、レビュー前に成果物を改善できる機会となります。

過去に私は、ユーザー向けにアプリの新機能を紹介するドキュメントをレビューすることがありました。
この成果物の目的は、ユーザーに新機能の利用シーンを具体的に想像させ、価値を伝えることでした。
しかし、レビュー時に成果物の目的をすっかり忘れていて、正確に伝えられているか（誤記や日本語としておかしくないか、仕様と合っているか等）のようななんとなくの観点で成果物を見て、指摘を出して終わりとしたことがありました。
正確に伝えられているかも大事ですが、漫然と見ていては、成果物が妥当であるか判断した（レビューをした）ことになりません。
例えば、今回の例に挙げている成果物の目的の場合、少なくとも以下の観点を持ってレビューをした方が、よりドキュメントの改善につながったと思います。

• よくあるユースケースになっているか
• 表示するデータは現実離れしていないか
• 機能を利用した結果どのように嬉しいのか明確に書いてあるか

私だけでなく、他メンバも同様の問題に遭遇することがありました。
そのため、私たちのチームでは、LR のレビューテンプレートに、以下のセルフチェック項目を指摘として登録しておく工夫をしています。

• レビューイは成果物の目的とレビュー観点を記載した上でレビューを依頼すること

これにより、レビュー前に必ず成果物の目的を共有でき、漫然と成果物がレビューされることはなくなりました。

レビューアと成果物の目的を共有する重要性、さらに、それを漏らさないための LR の活用方法をご紹介しました！
何かの参考になれば嬉しいです！

Lightning Review (以下、LR)開発チーム、入社5年目の加美川です。

最近、社内で色々な方に「もう5年目なの！？」と言われます。
そんなことを言われても正直困ってしまいます。
なぜなら、私自身が「えっ、私もう5年目になっちゃったの……！？😱」と思っているからです。
いつまでも新人気分でいたかったなあ～、と、ナウでヤングでピッカピカの新入社員たちをうらやましく(？)眺めている今日この頃です。

さて、今回のブログでは、 LR の ちょっとニッチな Tips をご紹介します。

LR は、レビュー対象の成果物の指摘箇所や修正箇所をキャプチャして登録することで、それをレビューイやレビューアに直感的かつ確実に伝えられるのが大きな特長です。
ところで、成果物のひとつの指摘に対して関連する修正箇所が複数あった場合など、修正箇所の画面のキャプチャが複数枚にわたることはしばしばあると思います。
LR では、もちろん複数枚の指摘画像や修正画像を指摘に登録することができます。
その際、どの指摘画像とどの修正画像が対応づいているのか、わからなくなることはありませんか？
修正内容欄に、「指摘画像2枚目の指摘箇所については、画像1-2,1-3のとおり修正しました。」と書いている人も多いのではないでしょうか？

例えば以下の画像のように……。

実は、LR では、指摘画像を選択した状態で修正箇所をキャプチャすると、修正画像の番号を指摘画像の番号と対応づけることができます。
例えば、2番目の指摘画像を選択した状態で修正箇所をキャプチャすると、修正画像は[2-1]、[2-2]...のように番号が振られ、2番目の指摘画像と対応づけられます。
そして、修正画像を選択すると、指摘画像欄の表示も修正画像と対応づけられた指摘画像に変わります。

これにより、レビューイは修正画像が複数枚あっても対象の指摘画像と対応づけることができるため、どの修正画像がどの指摘画像に対応しているかを、よりレビューアに分かりやすく伝えることができます。
また、修正内容を確認するレビューアも、たとえ修正画像が多くあったとしても、どの指摘画像に対応した修正画像かが番号からすぐに分かるうえに、選択した修正画像に合わせて指摘画像の選択も変わるため、修正前と修正後の画像を見比べて確認するときの手間が軽減されます。

知る人ぞ知るLR の便利機能、使いこなして日々のレビューをよりスマートに進めていきましょう！

Lightning Review (以下、LR)開発チーム、入社5年目の佐々木です。

暖かくなってきて過ごしやすい気候になりましたね。
外に出るのが楽しくなりますし、新しい活動を始めるのに最適な季節です。

今回は LR の Tips として、「どの工程で流出不具合が多いのか分析する」使い方についてご紹介します。

どうしても開発を行うなかで不具合は出てしまうものですが、どの工程で不具合を見つけるかで対応工数は大きく変わります。
工程内のレビューで検出できた不具合と比較して、次以降の工程に流出した不具合は、その対応工数が数倍から数十倍かかることもあります。

流出不具合を減らすように改善したいと考える方も多いかもしれませんが、改善するにはまず、現状の把握ができないといけません。
LRの機能を用いることで、不具合の検出率を見える化し、分析することで効果的な施策を打つことができます。

LRでは、指摘の登録時に「原因工程」と「検出工程」にてどの工程で不具合が入ってしまったのか、またそれをいつ検出できたのかを記録できます。

記録した「原因工程」と「検出工程」をピボット分析で見える化することで、例えば、外部仕様に対して、外部仕様DRで34件の不具合を検出した後、次工程の設計DRでさらに24件の不具合を検出していたと分析できます。
ピボット分析の詳細はこちら。

外部仕様工程と設計工程間で多くの手戻りがあるということは、仕様の定義時に考慮漏れが発生していることが考えられるので、設計工程で必要な観点を外部仕様定義時に漏らさないようチェックリストを作るといった施策を打つことができますね！

不具合の件数だけでなく、どの工程で発生し、いつ検出できたか？を分析することで効果の高い施策を考えることができます。
工程ごとの流出不具合数は、プロジェクトの状態を測る指標としても活用できます。工程ごとの流出不具合を過去実績と比較することで、品質を評価することができます。

是非、この Tips を実践して、不具合を工程内で検出して解消できるようにしましょう！