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

小島 優介

Lightning Review 開発チームでプレイングマネージャーをしている小島です。

私事ですが、IT技術者向けの月刊誌「Software Design」で連載記事を執筆しています。
連載のテーマ名は「ハピネスチームビルディング」で、チームの皆が主体性を発揮して成長するための様々な知見を紹介しています。
2022年4月号から連載していまして、半年分の記事をWeb上でも公開しました。
以下の記事タイトルの中に、もしも興味のあるものがあれば、読んで参考にしていただけると幸いです。

  1. リモートワークのつらさを共感して楽しいに変える
  2. メンバー間で活発に議論する朝会にしよう
  3. ファシリテーターを皆に任せて楽しい振り返りに
  4. コーチングプログラミングで楽しく成長する
  5. 分報で各自の作業を可視化して皆で協力し合う
  6. 新しいものを試行する風土を作る

ちなみに本誌掲載時は、下図のように楽しそうな雰囲気のイラスト付きでカラー掲載してもらってます。
素敵なイラストをご用意してくださった編集部の方々に感謝です。

software-design

新美 真

Lightning Review(以下、LR)開発チーム、入社6年目の新美です!
11月に入ってあったかいものがおいしい時期になりましたね。
こんな時期には、やはりラーメンが食べたくなってしまいます🍜
寒くなくても週3で食べてしまうんですけどね……

今回は、LRを活用してレビューアへの相談事項を管理するTipsをご紹介します。

レビューで見てほしいポイントは独力では作り込めなかった、あるいは不安なポイントであると思います。
そんなポイントをレビューで相談できるようにLRを活用しましょう。
作り込みの最中でもLRを利用して不安なポイントを保存しておけば、よりレビューアの知識を引き出せるレビューとなるはずです。

たとえば、外部仕様の作り込みで不安なポイントを指摘にします。
具体的には、ダイアログのテキストボックスにおいて不適切な文字列を入力された場合に、ダイアログのOKボタンを無効にするか、OKボタンを押下したあとにエラーダイアログを表示すべきかで悩んだとします。
その場合に上記のような不安なポイントを指摘として登録することで、レビューの場ではどのような考え方や判断をして、どちらを採用すると良いのかをレビューアに聞くことができます。

consultation

そして、レビューアに聞いた方針を元に、レビューイがその方針とした理由とともに修正内容を記し、修正済みにステータスを遷移させます。

modified

レビューアは修正内容を確認し、レビューイの理解度も確認した上で確認済みにステータスを遷移させられるため、指導も指摘修正も、どちらも確実にやり切れます。

上記をヒントにしていただき、相談事項をLRでレビューアと共有すれば自分の不明点も解消でき、より質の高いレビューにつながると思います。

実際、私はレビューア・レビューイの両方の立場となった経験がありますが、レビューのポイントを絞って集中して議論できるため、とても効果的に感じました。

ぜひ、試してみてくださいね!

角谷 健太

Lightning Review(以下、LR)開発チーム、入社2年目の角谷です!
10月に入ってから非常に寒くなりましたね🥶
私は年がら年中羽毛布団で寝ているのですが、ついに毛布を引っ張り出しました!
これから本格的な冬にかけて、1枚ずつ布団及び毛布が追加されていく予定です。

今回は、レビューファイルを高速に読み取り可能なライブラリ「LightningReview-ReviewFile」をご紹介いたします!

LRでレビューを実施すると、".revx"という拡張子のファイルに、レビュー記録として指摘や修正状況などが保存されます。
通常、このレビュー記録の情報を取得するには、LRでレビューファイルを開く、またはLRに同梱されたピボット分析ツールが必要です。
しかし、独自の集計ツールを用意して、大量のレビューファイルに対して集計したり、品質分析を自動化したい、といった要望もあると思います。
そんな時に使えるのが、「LightningReview-ReviewFile」です。
例えば、これを使って作成したプログラムを、毎晩自動実行するように設定しておくことで、社内で日々行われている100以上のレビューを対象としてデータ収集し、

  • レビューの指摘が日々どれだけ検出されているかをモニタリング
  • 予定に対して遅れているレビューが無いかをモニタリング

なんてこともできるようになります!

「LightningReview-ReviewFile」はLR開発チームがメンテナンスしているオープンソースソフトウェアです。
このライブラリは、主にレビューと指摘に関する情報を取得でき、1000ファイルのレビューファイルの読み込みが数秒程度と非常に高速に処理が可能です。

具体的には、以下の2つのライブラリがあります。

また、上記のライブラリをコマンドプロンプトやPowerShellから簡単に利用できるコマンドラインツール「ReviewFileToJsonCLI」を公開しています。
こちらは、このリンクからダウンロードできるzipファイルを解凍して、格納されたexeファイルを実行するだけで利用できます。

それでは、「ReviewFileToJsonCLI」の実際の利用例をご紹介します。
このツールでは、フォルダ内に複数格納されているレビューファイルに登録されたレビューや指摘のデータを、JSON形式で出力できます。
下のgif画像では、Windows のコマンドプロンプトにて Lightning Review のファイルが複数格納されたフォルダを指定して実行することで、output.jsonというファイルを出力しています。

output

JSON形式で出力したoutput.jsonは、Excelの機能を利用して表形式に変換できます。
下のgif画像では、上で出力したoutput.jsonをExcelで表に変換して表示しています。
レビューファイルが保持しているそのままのデータを一覧に表示できるため、その後はお好みの形に合わせて分析できます。
このように、JSONファイルを入力に、どの機能に重大度の高い不具合が集中しているか、Excelや独自ツールで分析できます。
取得できるデータはこちらを参照ください。

data_transform

上記はコマンドラインツールを通してレビューのデータを取得する例ですが、「LightningReview.ReviewFile」および「LightningReview.ReviewFileToJsonService」ライブラリはNuGetパッケージとして公開しているため、ご自身で作成したプログラムから直接利用できます!

ライブラリは随時更新しており、つい最近、LR2.0に対応するためにバージョンアップしました(私が担当しました!)。
ぜひ、使ってみてくださいね!

加美川 真由子

Lightning Review 開発チームの加美川です。
私事ですが、このたびWomen Developers Summit 2022の公募セッションに当選し、11/2(水) 16:55~より、スピーカーとして登壇することになりました!

セッションタイトルは、『プログラミング未経験のエンジニア女子が、アウトプット頑張ったら設計わかるようになれちゃった話』です。

実は私はプログラミング未経験で新卒入社しており、社会人三年目の現在に至るまで、ソフトウェアの設計力・実装力の不足に悩まされてきました。
そんな私がLightning Reviewチームに入り、『デザインパターン』の学習とその成果のアウトプットを通して後輩に設計を説明できるようになるまでに取り組んだこと、学んだことを当日はお話ししようと思っております。

ご興味があれば、ぜひセッションを聴講していただけますと嬉しいです。

https://event.shoeisha.jp/devsumi/20221102/session/4039/

加美川 真由子

レビューとは一口にいっても外部仕様や実装、テストなど対象となる工程も幅広く、成果物も仕様書や設計書、ソースコードなどさまざまです。
また、レビューでチェックすべき項目や検出される指摘の種類も、工程や成果物ごとに異なります。
このように多様な工程や成果物に対して、レビューを実施するたびに指摘の分類や原因工程・検出工程、カスタムフィールドなどのレビューに必要な情報を毎回レビューファイルに設定するのは大変です。

そこで、工程別のレビューファイルのテンプレートを事前に作成することをオススメします。
指摘の分類や原因工程・検出工程、カスタムフィールドなどが設定されている既存のレビューファイルから指摘を削除し、工程別にテンプレートとして保存します。
保存したテンプレートからレビューする工程に合ったテンプレートを選択してレビューファイルを作成することで、既にレビューファイルに必要な情報が設定された状態でレビューを開始できます。
これにより、複数の工程に対してもレビューファイルの準備に手間がかかったり、もれがあったりすることなくレビューを実施できます。
テンプレート機能の詳細はこちらを参照ください。

さらに、Lightning Review 開発チームならではの使い方を紹介します。
事前に工程別のテンプレートに、図のようにセルフチェック観点をあらかじめ指摘として登録しておきます。
レビュー前に、レビューイはセルフチェック観点に対する処置内容を指摘の[修正内容]欄に記入し、その指摘のステータスを[修正済み]にします。
例えば、実装工程で処理速度が妥当か確認する観点であれば、処理速度の計測結果を[修正内容]欄に記入します。
そして、レビュー時にレビューアが確認して、処置内容が妥当であれば、指摘を[確認済み]にします。
レビューファイルにセルフチェックの指摘があることで、レビューイはレビュー準備の際にセルフチェックを忘れずに実施できますし、レビューアもレビューイがどのようにセルフチェックを実施したかを指摘の[修正内容]欄から確認できるため、重要なチェック項目について認識の誤り・ずれなどがあってもレビューで摘み取ることができます。

selfcheck