「AWS Well-Architected フレームワーク」の「レビュープロセス」資料がとても良かったので紹介したい

はじめに

仕事の品質を高める上で、知見のある方にレビューをしてもらうプロセスは欠かせません。
ただこのレビュー、やり方や意見の伝え方によっては、期待した効果が得られなかったり、ネガティブな効果を生み出しかねません。そうした結果、レビューという行為自体が開催されにくくなることは、チームにとって非常にマイナスです。
全員のレビューへの期待を整えておくために、レビューの心構えや望ましい運営方法などを、レビューに関わる全ての人が共通認識化しておくことは、非常に重要だと考えています。

今回、このレビューを効果的に進めるポイントをまとめた、とても良い資料を見つけたのでご紹介します。

レビュープロセス - AWS Well-Architected フレームワーク

この資料をおすすめしたい方

エンジニアに限らず、仕事で他者の成果物をレビューをする人、および他者からレビューを受ける人（そう考えると、仕事をする人はすべて、なのかもしれません。）

「AWS Well-Architected フレームワーク」とは？

引用元：AWS Well-Architected フレームワーク - AWS Well-Architected フレームワーク

AWS のソリューションアーキテクトが、10 年以上に渡り、様々な業種業界、数多くのお客様のアーキテクチャ設計および検証をお手伝いしてきた経験から作成した“クラウド設計・運用のベストプラクティス集”です。（下記Youtube概要欄より抜粋）

「AWS Well-Architected フレームワーク」について詳しくは、こちらの動画またはスライド資料をご覧ください。
【AWS Black Belt Online Seminar】AWS Well-Architected Framework - YouTube
AWS Black Belt Online Seminar 2018 AWS Well-Architected Framework

Well-Architectedフレームワーク自体は、言わずと知れた素晴らしいノウハウの塊なのですが、それ自体の説明は趣旨と異なるので、ここでは割愛します。
この中の一節に「レビュープロセス」という章があり、それが今回ご紹介したい内容なんです。

実は上記の動画/資料の中でも紹介されております。

引用元：AWS Well-Architected フレームワーク - AWS Well-Architected フレームワーク

このレビュープロセスの一節、私も拝見したところ、実はAWSのみならず**他のあらゆるレビューに応用できる普遍的な内容でした。**しかも重要なことが端的に言語化されていることに感動し、今回この紹介記事を書いた次第です。

#「レビュープロセス」のエッセンス

コンテンツ自体は5分ぐらいで読めます。是非読んでみてください。
ところどころ翻訳がやさしくないかなと思われる箇所もあるので、気になる方は英語版をご覧頂けるとよいかと思います。ちなみに本文に出てくる「ワークロード」という言葉、AWSになじみの薄い方は少し違和感があるかもしれません。AWS文脈ではAWSのコンポーネントで作られたひとまとまりの「システム」というような意味で使われます。詳しくはこちらをご覧ください。

本文の内容を、活用機会をより広げるために私の方で少し意訳しつつ、構造化してシンプルに整理してみました。

• レビューに臨む基本スタンス

  • 非難しない
  • 深く掘り下げることを奨励する
  • 監査ではなく話し合い
  • 全体の整合性や品質に対して全員が責任を持つ（自分のところだけ良ければOKではない）

• レビューの目的と成果

  • 目的
    • 対策を必要とする重大な問題の発見
    • 改善できる領域の特定
  • 成果
    • 回答に別途調査が必要な質問のリスト
    • 課題リスト（ビジネス文脈に応じて優先順位を設定する）

• レビューの運営方法

  • 一貫した方法で行う
  • レビューに必要な人が全員含まれているかを確認する
  • 共通のフレームワーク／ガイドライン／チェックリストを元にする
    • 過去発生した問題の根本原因が含まれているもの
  • 会議を進行するために次のアイテムを用意しておく
    • ホワイトボードのある会議室　又はオンラインホワイドボードツール
    • 構成図や設計ノート
  • 他チームの人がレビューする場合は、その時初めて中身を理解することがほとんど
  • 正式なレビュー会議よりも、継続的な話し合いが望ましい

• レビューの開催タイミング

  • 一度決めたら変更が難しかったり、後戻りが難しい場合は必ず着手前にレビューを設定する
  • 後で変更できるものの場合はできるだけ軽量にする
  • ローンチしたら終わりではなく、アーキテクチャが劣化しないように、変更が入る場合は継続的にレビューを行っていく

• レビュープロセスの改善

  • プロダクトに重要な問題が発生した場合は、都度レビュープロセスを見直す

• レビューの組織的価値

  • 同一組織内の複数チームで継続的にレビューを行い、その結果を分析することで、組織共通の課題が発見でき可能性がある
  • 発見した共通課題は、仕組み改善やトレーニングなどで適切に対策する

• レビューへの反発対策

  • 「忙しい！」
    • 忙しい時こそミスが許されない。見過ごしている問題を発見できるかもしれない
  • 「指摘を受けても対策をする時間も余裕もない！」
    • 指摘事項全てに対策しなくてもよい。リスクがわかれば、問題が起こった時の対策を事前に備えておくこともできる
  • 「秘匿事項があるからできない！」
    • 秘匿事項をオープンにしなくても、質問への回答はできる

最後に

こうしたチームで仕事をするためのベースとなる考え方は、自分一人だけ理解していても効果は限定的です。是非一緒に働く仲間の皆さんに共有し、これをたたき台に、自分達のチームのレビューの在り方を是非会話してみて頂けるとよいかと思います。
ストレスなく、効果的なレビューを日々運営できるチームが増えると最高です。

あわせて読みたい

レビュープロセスと同様に、エンジニアの汎用的なスキル向上をテーマに何本か記事を書いています。よろしければあわせてご覧ください。

ドキュメント作成スキル向上を目指す人向けおすすめ記事まとめ - Qiita
Google社のテクニカルライティングの基礎教育資料がとても良かったので紹介したい - Qiita
政府CIOの「デジタル・ガバメント推進標準ガイドライン実践ガイドブック」が とても良かったので紹介したい - Qiita