レビューを文化にするやさしい設計──非エンジニアチームの実践録 by micchie

レビュー文化を根づかせることは、多くの組織が抱える永遠の課題です。
しかも、そのチームがエンジニアだけでなく、多職種で構成されているとしたらどうでしょうか。成果物も、SQL や Goole Apps Script のコード、Salesforce の設定、業務ドキュメントなど多岐にわたる。
この環境でレビューを機能させるには、「文化」ではなく「構造」と「スキルの定義」が必要でした。
本セッションでは、チームがゼロからレビュー文化を設計・実装し、非エンジニアを含む多様な職能のメンバーとともに運用可能にしたプロセスを紹介します。
話の中心はコードレビューの技術論ではなく、「レビューを通じて組織がどう変わるか」という組織デザインの話です。

「レビューは品質担保のため」では足りなかった

わたしたちのチームでは、日々のアウトプットが事業運営の中枢を支えています。品質を守ることは単なる「きちんとした設計・コード」を超えて、事業そのものの信頼を守る行為でした。
わたしたちはまず、レビューを「品質の最終防衛線」ではなく、「リスクと知識の共有装置」として位置づけ直しました。
つまりレビューとは、属人化を防ぎ、チームの継続性と透明性を保つための仕組みです。
レビューを “誰かが見る” ではなく、“チームで引き受ける” 行為へと再定義した瞬間、ようやく文化づくりのスタートラインに立てました。

レビューを仕組みに落とし込む

レビュー文化は「がんばってやろう」では定着しません。人によって判断が揺れ、レビューの粒度や責任の範囲がばらつくからです。
そのためわたしたちはまず、「どの成果物をどの粒度で、誰がレビューすべきか」を体系化しました。
レビューの種類は、実施可否、方針、成果物、実行の4段階。
単にコードを読むだけでなく、「そもそもこの業務をやるべきか」「どう設計するか」「どのように実行するか」までレビューを拡張しました。その上で、職能ごとにレビュー観点を明文化しています。
エンジニアは品質と再現性、マネージャーは優先度と工数、事業責任者はリスクと価値のバランス。法務・会計・税務といった専門家はそれぞれの観点でレビューに関与します。
こうした役割の整理によって、「誰がどの段階で判断するか」が明確になり、結果として、属人化のリスクが減少しました。

多様な職能を束ねるための「スキルと期待値の見える化」

しかし、レビューの仕組みが整っただけでは十分ではありません。
チームの中には、エンジニアバックグラウンドを持つ人もいれば、業務設計や分析が得意なメンバー、ドキュメンテーションを中心に支えるメンバーもいる。
職能もバックグラウンドも違う彼らが「レビューにどう関わるべきか」を共有する必要がありました。
そこで導入したのが、スキルレベルと組織の Value をかけ合わせたマッピングです。それぞれの Value ごとに、個人がどのステップにいるのかを可視化できます。

これにより、「どのスキルが不足しているか」「次にどの段階を目指すべきか」を、レビューの中で対話できるようになり、レビューは単なる承認の場ではなく、成長と育成の場へと変わっていくのです。

文化を根づかせる「レビューの設計思想」

レビューを日常の一部にするために、意識した設計思想が三つあります。

一つ目は、レビューの優先度を高く置くこと。
自分のタスクよりもレビューを優先する。
レビュー時間を毎日スケジュールに組み込み、チーム全体でレビューを止めないルールを明確にしました。
レビューはスピードを遅らせるものではなく、スピードを維持するための基盤です。

二つ目は、レビューを「会話」ではなく「仕組み」に落とすこと。
Design Doc のテンプレート、チケットの項目設計、リスクレベルの自動分類など、誰がやっても同じ流れになるよう設計します。
これにより、メンバーの習熟度に左右されず、レビューが安定的に回るようになりました。

三つ目は、レビューを個人の責任からチームの責任に変えること。
「誰がミスしたか」ではなく、「どの段階でリスクを拾えたか」を見る。
レビューの失敗を咎めるのではなく、次の改善サイクルに活かす。
こうして、レビューは「チェック」から「共創」に変わっていきます。

セッションで伝えたいこと

このセッションでは、チームが実際に取り組んだ「レビュー文化の仕組み化」と「スキルの可視化」の設計思想を、実例を交えて紹介します。

• 多職種混在チームでレビューを成立させるための設計と運用のリアル
• レビューを成長・育成の仕組みに変えるスキル階層の考え方

これまでの経験の蓄積から見えた、文化のつくり方を共有したいと思います。

想定する参加者層

• レビュー文化を強化したいエンジニア、EM、SRE、テックリード
• BizOps や事業チームと協働するエンジニア・マネージャー
• 属人化や品質リスクに悩むプロジェクトリーダー