これから学ぶ人も、資格取得を目指す人も、最適なカリキュラムを選べます。
これから学ぶ人も、資格取得を目指す人も、最適なカリキュラムを選べます。
CTC 教育サービス
[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes
今回からは、2023年に公開された論文「Improving Design Reviews at Google」を紹介します。この論文では、Google社内でのデザインレビューのプロセスを改善するツールの導入効果が紹介されています。ツールそのものはシンプルなものですが、Google社内でソフトウェア開発者がどのようにデザインレビューを進めているのか、という点に興味を惹かれる読者も多いのではないでしょうか。
デザインレビューは、ソフトウェアシステムの開発を進める際の最初のステップです。システムの設計者は、実際のコーディングに入る前に、まずは、これから開発するシステムの仕様や技術的な詳細をデザインドキュメントと呼ばれる文書にまとめます。これをさまざまなステークホルダーに見てもらい、潜在的な問題点や開発時に発生するであろう課題、あるいは、設計の改善案などのフィードバックをもらいます。デザインドキュメントの作成者は、フィードバックを元にドキュメントの内容を改善していき、最終的にレビュアーの承認を得た後に、次の工程へと作業を進めます。
フォーマルなスタイルでデザインレビューを進める企業では、承認プロセスを回すための専用のシステムを利用することもありますが、Google社内では、デザインレビューは比較的カジュアルなスタイルで行われます。Googleドキュメントの文書でデザインドキュメントを作成して、Googleドキュメントのコメント機能を利用して、ステークホルダーにレビューの依頼を出します。図1は、論文に掲載されている例ですが、(a)はデザインドキュメントを作成したことを関係者に連絡するためのコメントで、(b)はレビュアーに対してレビューを依頼するコメントになります。コメントに記載されたメールアドレスに通知メールが自動で送られるので、これにより、レビュアーは自分への依頼に気がつきます。
図1 Googleドキュメントのコメント機能によるレビュー依頼の例（論文より抜粋）
この後のレビューのやりとりも基本的には、Googleドキュメントのコメント機能や変更提案機能（既存の文書を上書きせずに、変更案を提示する機能）で行います。最終的にレビュアーの承認が得られると、レビュー依頼のコメントの「解決」ボタンを押して、コメントを非表示にします。すべてのレビュー依頼コメントが非表示（解決済み）になれば、このデザインドキュメントのレビューは完了したことになります。
Google社内でのデザインレビューは、このようなGoogleドキュメントの機能だけを利用した簡便なプロセスで問題なく行われてきましたが、この論文の著者は、潜在的な課題に着目しました。端的に言うと、レビューの進行状態を管理するツールが存在しないという点です。あるデザインドキュメントに対して、現在、レビュアーがどれだけアサインされていて、どのレビュアーの承認が未完了なのかを確認する場合、ドキュメントのすべてのコメントを見る以外に方法がありません。あるいは、あるチーム内で、レビュー中のデザインドキュメントがどれだけあるのかを一覧で確認することもできません。
しかしながら、これらはあくまでも潜在的な課題であり、個々の開発者が現実の課題として捉えているわけではありません。そのため、これらの課題に対応するという名目で、まったく新しいツールやプロセスを導入するのは現実的ではありません。そこで、論文の筆者は、Googleドキュメントのアドオンツールを利用して、既存のプロセスを変更することなく、上記の課題を解決する方法を考えました。開発者に求められる対応は、DAC（Design Approval Companion）というアドオンをインストールして、図2の様に、レビュー依頼のコメントに「#approver」というハッシュタグを追加するだけです。
図2 ハッシュタグ「#approver」を追加したコメント（論文より抜粋）
DACは、このハッシュタグを認識して、ドキュメントの先頭部分に、図3の様な表を自動で追加します。ここには、レビュアーの名前とレビューの承認状態がまとめられています。レビュー依頼のコメントの解決ボタンが押されると、承認状態が「PENDING（保留中）」から「APPROVED（承認済み）」に変更されるというわけです。これにより、個々のコメントを確認しなくても、このデザインドキュメントのレビューの状況をすぐに確認することができます。
図3 DACが追加するレビュアーの一覧表（論文より抜粋）
また、DACは、Google Chromeの「Event Notifier（イベント通知）」機能拡張と連携して、ドキュメントの作成者とアサインされたレビュアーに対して、図4の様なイベントの通知を行います。これにより、Googleドキュメントからの通知メールを確認しなくても、ブラウザーのイベント通知でレビュアーにアサインされたことや、レビュアーの承認が得られたことなどが分かります。
図4 ブラウザーへの通知例（論文より抜粋）
そして最後に、チーム内でレビュー中のデザインドキュメントを一覧で確認できるように、DACは、g3docとの連携機能を提供します。g3docは、Google社内で使用されているドキュメントシステムで、チームごとの社内Webサイトが作成できます。DACは、デザインドキュメントの作成者が所属するチームのWebサイトに、図5のような表を追加します。これにより、このチームに関連するデザインドキュメントの一覧とそれぞれのレビューの状況をまとめて確認することができます。
図5 g3docに自動追加される表（論文より抜粋）
今回は、2023年に公開された論文「Improving Design Reviews at Google」に基づいて、Google社内でのデザインレビューのプロセスと、それを改善するためのツール（DAC）を紹介しました。Googleドキュメントだけを用いたカジュアルなレビュープロセスに驚いた方もいるかも知れません。事前に決められたレビュアーを機械的にアサインするのではなく、デザインドキュメントの作成者が本当に必要と考えるレビュアーを自身で選択するなど、レビューの中身そのものを重視する姿勢が反映された形と言えるかも知れません。
次回は、DACの導入による改善効果とDAC利用者からのフィードバックを紹介したいと思います。
Disclaimer：この記事は個人的なものです｡ここで述べられていることは私の個人的な意見に基づくものであり、私の雇用者には関係はありません｡
[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes
