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

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

全てのタグを見る

箕浦 彩香

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

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

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

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

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

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

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

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

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

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

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

加美川 真由子

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

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

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

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