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

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

全てのタグを見る

近藤 匠真

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

先日、大谷翔平選手の飼っているワンちゃんの"デコピン"が始球式をして話題になりましたね。
とても賢くて、ボールを持って走る姿に癒されました~。
そして大谷選手はどこまで記録を伸ばすのでしょうか・・・!?

さて、今回は、現在開発中の新機能、SharePoint 連携についてご紹介します。

SharePoint 連携の最大の特長は、SharePoint に格納したレビューファイルを、複数人で同時に編集できるようになることです。
この機能により、ネットワーク上の共有フォルダから問題なく SharePoint 環境に移行できます。

近年、成果物などのドキュメントの管理場所をネットワーク上の共有フォルダから SharePoint へ移行する企業も多いと聞きます。
私の開発チームも、一部のフォルダが SharePoint に移行しました。

もともと、レビューファイル を複数人で同時編集したい場合は、レビューファイルを[共有モード]に設定して、ネットワーク上の共有フォルダに格納して運用していました。
LR の共有モードは、保存時に他のユーザーの変更をマージしてから保存するので、先祖返りすることなく安全に複数人で同時編集することができました。
しかし、ネットワーク上の共有フォルダが廃止となると、同時編集できる管理場所がない・・・といった状況になってしまいます。
そんな状況下でも LR をこれまでと変わらずご利用いただけるようになるのが、今回紹介する SharePoint 連携です。

それでは、SharePoint 連携の特長である保存機能をご紹介します。
以下の動画では、SharePoint のレビューファイルを開いて編集し、保存した場合の実際の動きです。

マージ

このように、これまでと変わらず保存ボタンを押下するだけで、他のユーザーの変更がある場合はマージします。
従って先祖返りすることなく、SharePoint のレビューファイルを複数人で同時編集することが可能になります。

また、今回の拡張機能では上述の通常の保存操作に加え、LR から SharePoint にレビューファイルをアップロードできます。
以下は、その実際の動きです。

名前を付けて保存

このようにして、LR から SharePoint へレビューファイルを保存できるようになります。
現在、SharePoint 環境の方は、多くの人がローカルにダウンロードして手動でアップロードしているかと思います。
レビューファイルに関しては、この機能を使用すれば、簡単にアップロードできます。

ここまで、SharePoint 連携の保存に関する機能を説明しました。
次回は、SharePoint 連携のもう一つの目玉機能である、SharePoint に格納しているレビュー対象ドキュメントの登録についてご紹介したいと思います。
SharePoint 連携は現在開発中ですので、リリース後に、ぜひご利用ください!

近藤 匠真

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 の活用方法をご紹介しました!
何かの参考になれば嬉しいです!