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

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

全てのタグを見る

近藤 匠真

Lightning Review (以下、LR)開発チーム、入社3年目の近藤です。

オリンピックは終わりましたが、猛暑はまだまだ続きそうですね!
オリンピックで中継では、様々な競技で国を背負って戦うアスリートの雄姿を見て、毎日感動していました。
自分も暑さに負けず、熱く戦っていこうと思います!

さて、今回のブログはレビューの質を高める LR の Tips をご紹介します。

いきなりですが、みなさんはレビュー指摘の分類を設定していますか?
指摘の分類の設定と聞いて、ピンとこない方もいるかもしれません。
私も初めは、指摘の分類を活用できていませんでした。
あらかじめ指摘の分類をレビューの観点ごとに設定し、レビュー時に受けた指摘がどのような分類にあたるのかを登録しておけば、傾向が見えて対策ができます。
ただ、その当時の私は指摘の分類を活用できておらず、レビューごとにどの観点でどのくらい指摘を受けたかを振り返っていなかったため、何度も同じ観点の指摘を受けてしまうことがありました。

そこで、ご紹介したいのが今回の Tips です。

事前準備で、レビュー前に[ファイル]メニューの[レビューの設定]から指摘の分類を設定しておきます。
以下は、外部仕様レビューとしての観点を設定した例です。

setting_classification

あとはレビューの指摘登録時に、忘れず指摘の分類を設定するだけです。

setting_classification

このように、指摘の分類を設定しておき、指摘登録時に指摘の分類を行うことで、指摘の傾向を捉えることができます。

下の図は、指摘の分類を設定しながらレビュー実施した際の分析ページです。
この分析ページからどの分類で多く指摘を受けているのか傾向を一目で見ることができます。
各指摘の登録時に分類を忘れず設定しておけば、レビュー完了時には分析が終わっている状態になります!

setting_classification

上記の図から、「冗長」が多く指摘されていることがわかります。
レビューイは指摘の傾向をもとに改善を図ることで、次のレビューでは同じ観点の指摘を減らし、より深い議論ができるようになります。

1回のレビューでは分からなくても、複数回で同じ観点の指摘が多く続けば傾向が見えてくると思います。
ピボット分析を活用すれば、複数のレビューを横断で傾向を分析することができます。
ピボット分析の活用方法についてはこちらをご覧ください。

今回は指摘の分類から傾向を分析し、作りこみ品質の向上へつなげる Tips をご紹介しました。
日ごろのレビューの機会で、ぜひお役に立てください!

新美 真

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

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

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

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

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

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

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

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

瓜生 賢輝

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

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

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

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

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

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

例えばLRチームではノート機能を以下のように活用していました。
notefunctiob
レビューを行った直後にレビューイ、レビューアが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のとおり修正しました。」と書いている人も多いのではないでしょうか?

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

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

after

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

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