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

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

全てのタグを見る

加美川 真由子

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

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

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

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

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

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

after

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

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

佐々木 勇輔

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

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

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

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

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

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

reviewproperties

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

pivot

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

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

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

新美 真

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

2月といえばバレンタインですね!自分はもらう相手がいませんが、並んでいるチョコを眺めるのは好きです。
ちょっと贅沢して甘いものを食べてみるのもいいかもしれませんね。

さて今回は、レビューのステータス機能を利用して、完了したレビューをクローズするTipsをご紹介します。

レビューは開発アイテムごとに、あるいは工程ごとに行うことが多いかと思います。
そうすると大量のレビューファイルができてしまい、目当てのレビューファイルを探すのにも手間取るといった状況に遭遇した方もいらっしゃるのではないでしょうか。

ただ、実施完了したレビューであっても、レビューが完了したエビデンスになるため、レビューファイル自体を消したくない方も多いかと思います。

そのような方は LR の機能でレビューをクローズすると便利です!
レビューをクローズすることで、スタートページやレビューエクスプローラで実施中のレビューのみにフィルタできます。

startPage

reviewExplorer

この機能を利用いただくにはクローズしたことを表すステータスを設定する必要がありますが、LR ではプリセットで[承認ステータス]を用意しているため、簡単に設定できます。
LR の[ファイル]-[レビューの設定]メニューから開いた[レビュー設定]ダイアログの[レビュー]タブから[承認ステータスを追加]ボタンをクリックすることで、[作成中]・[作成済]・[検討済]・[承認済]の4ステータスを一括で作成できます。
このとき、[承認済]がレビューをクローズしたことを表すステータスとなります。

createApprovalStatus

なお、レビューをクローズするステータスを個別に定義したい場合は、[ステータス]の[追加]ボタンをクリックして、[レビューをクローズする]チェックボックスにチェックしたステータスを追加します。

checkReviewClose

その後、レビューが完了したタイミングでそのステータスに遷移させましょう。
これにより、前述の通りスタートページやレビューエクスプローラで実施中のレビューのみにフィルタできるようになります。

transitionApprovalStatus

ぜひ、気になった方はこのレビューをクローズする機能をご活用してみてくださいね!

瓜生 賢輝

Lightning Review(以下、LR)開発チーム、入社1年目の瓜生です!

冬本番ですね…!この前は雪が降ってました⛄寒すぎてエアコンを頻繁に使ってしまっているので今月の電気代を見るのが非常に怖いです…

さて今回は、LRを用いて複数のレビューの進捗状況を管理するTipsをご紹介します。

普段の業務の中で、レビューの進捗状況を俯瞰したいことなどはありませんか?
複数のプロジェクトを管理するマネージャ層の方であればプロジェクトを横断して、レビューの進捗状況を確認したい場合などがあると思います。

例えば進捗状況を確認したいレビューの数が2、3個ならまだいいかもしれません。
しかしそれが10、20個などになってくるとどうでしょう?
1つ1つレビューファイルを開きそれらの進捗状況を確認していくのは非常に手間がかかりますよね。

気を配るレビューが増えるほど、指摘が未修正のまま残ってしまっていることに気づかないということが起きてしまう可能性が高くなってきます。
そして指摘が未修正のまま開発を進めていくと不具合を残して次工程に進んでしまったり、それにより手戻りが発生して計画遅れにつながる危険性が出てきます。

そこで用いるのが今回紹介するレビューエクスプローラ機能です!まずはこちらをご覧ください。

reviewExplorer

1つ1つレビューファイルを開かなくとも複数のレビューの進捗状況が俯瞰して分かりますし確認漏れがないかを確認できます。
上の図の例ではほとんどのレビューファイルが青色のアイコン(すべての指摘が確認済み)ですが、いくつか赤色のアイコン(未修正の指摘が残っている)のレビューファイルが残っています。
このようにレビューファイルの状態が一目で分かるので、マネージャ層は、指摘の残っているレビューファイルがあればすぐに気づいて、担当者に修正するようにフォローすることができます。

こちらの設定はスタートページにおいても共通のものとなっておりスタートページでも同様に確認できます。

startPage

このようにこれらの機能を用いることで簡単に複数のレビューの進捗状況を管理できます!

以下設定方法です。対象のレビューファイルを1つのフォルダにまとめLRのワークスペースフォルダに登録します。

addWorkspaceFolder

たったこれだけで登録したフォルダにある複数のレビューの進捗状況を確認することができるようになります、便利ですね!

私も、普段の業務の中で、自身の成果物に対するレビューを行う際にレビューエクスプローラを使用しています。
レビューエクスプローラだとレビューの確認状況が一目で分かります。
これにより先日は指摘をすべて修正し確認依頼を出したはずのレビューがまだ完了していないことにすぐ気づくことができ、レビューアに修正確認のフォローができました。
このように担当者層にも嬉しいことがありますよ!

非常に有用な機能ですのでぜひ使ってみてください!!

前川 寛

Lightning Review (以下、LR)開発チームに参画して、半年の前川です。
以前のチームでは一番年下だった私が、このチームでは上からかぞえた方が早くなりました。。。歳を感じる今日この頃です。

さて、レビューファイルに指摘を追加した後、修正者をどこまで割り振ったのかわからなくなったことはありませんか?

LR の修正者の割り当てについて

LR は、指摘を追加したときに先頭に設定されたメンバを自動的に修正者に割り当てます。
この機能はとても便利なのですが、1つのレビューファイルに対して複数人が修正を並行して行うようなケースでは、指摘ごとに修正者を割り当てる必要があります。

しかし、レビュー時に都度、修正者を割り当てるのは手間であるため、修正に着手する時に修正者を変更することが多いかと思います。
このようなケースでは、修正者が自動的に割り当てられることで、逆にどこまで適切に修正者を割り振ったのか、わからなくなることがしばしばあります。

修正者の割り当てが適切にされないと、メンバ間の認識の齟齬によって、1つの指摘を複数人がそれぞれ修正してしまったり、お互いが手を付けずにお見合いしてしまったりすることが発生します。
こういった事象は、プロジェクトの管理を難しくする一因になります。

未定を表すメンバを追加して解決する

この問題を解決するための効果的な方法があります。
それは、未定を表すメンバを追加して、このメンバを修正者として自動的に割り当てられるようにしておくことです。
これにより、修正者が割り当てられていない指摘が一目瞭然になり、プロジェクトの管理が格段に楽になります。

未定を表すメンバの追加手順

001.png 次の手順で、未定を表すメンバを追加します。

  1. [概要]ページを表示させ、ナビゲータの[メンバ]を押下することで、メンバの設定画面を表示させます。
  2. [メンバ追加] ボタンを押下すると、[新規メンバ]というメンバが追加されるので、メンバ名を(未定)に変更します。
  3. (未定)のメンバを選択して、[↑]ボタンで一覧の最上位に移動させます。

この設定を行うことで、指摘を新規に追加したときに、修正者に(未定)が設定されるようになります。

(未定)のメンバを追加したテンプレートを利用したり、スクリプトから追加したりすることでメンバ追加の手間も減らせます。
ユースケースに合わせて、利用してみてください。

まとめ

修正者の割り当てに焦点を当て、スムーズなレビュープロセスを実現するための Tips をご紹介しました。
この Tips を適用して(未定)のメンバを追加することで、複数人で1つのレビューファイルの処置をするときに、誰がどの指摘を修正するかが一目瞭然になり、プロジェクトの管理が格段に楽になります。

是非、この Tips を実践して、スムーズなプロジェクト管理ができるようなプロセスを構築してみてください。

では、また次の記事でお会いしましょう。