こんにちは、インフラエンジニアのryuです。
新人インフラエンジニアが本番作業をするとき、手順書や作業計画を先輩が確認してから実施する。そんなルールを置いている現場は多いのではないでしょうか。
いわゆるダブルチェックです。ミスを防ぐ仕組みとして、とても大切なものです。
ただ、ひとつ聞いてみたいことがあります。そのダブルチェックのあと、新人は何か新しいことを学べているでしょうか。
先輩が赤字で直して返し、新人がそのとおりに修正して、作業が終わる。これを1年繰り返しても、新人が自分で手順書を書けるようになっていない。育成担当の方から、そんな声を聞くことがあります。
今日は、どの現場にもある作業レビューを、ミス防止だけでなく育成の場として機能させるための設計を考えていきます。
作業レビューは、間違い探しのためだけにあるのか？¶
レビューの目的と聞くと、多くの人はミスや抜け漏れを見つけることを思い浮かべます。それは間違いではありません。
ただ、ソフトウェア開発の世界では、レビューにはそれ以外の効果もあることが知られています。
2013年にMicrosoftの研究者が発表した調査があります。社内の開発者やマネージャーを観察・インタビュー・アンケートし、数百件のレビューコメントを分類した研究です。
欠陥を見つけることはレビューの主な動機であり続けているものの、実際のレビューは予想ほど欠陥に関するものではなく、知識の移転、チームの状況把握の向上、問題に対する別の解決策の創出といった追加の利点をもたらしている。 （Bacchelli, Bird "Expectations, Outcomes, and Challenges of Modern Code Review" の要旨より意訳）
つまり、レビューは知識が人から人へ流れる通り道でもある、ということです。
Googleが公開しているコードレビューの指針にも、同じ考え方が書かれています。レビューには、言語やフレームワーク、設計の原則について新しいことを教える役割があり、学びにつながるコメントを残すのはいつでも良いことだとされています。さらに、うまくできている点を伝えるほうが、間違いを伝えるより育成の面では価値がある場合もある、とまで書かれています。
これはソフトウェアのコードに限った話ではありません。インフラエンジニアの手順書や作業計画、設定ファイルの変更も、同じように知識が流れる場所になり得ます。
ダブルチェックが育成につながらない3つの理由¶
では、なぜ多くの現場では、レビューが育成に結びつかないのでしょうか。よく見かける原因を3つ挙げてみます。
理由1: 先輩が直して返してしまう¶
いちばん多いのがこれです。先輩が手順書を読み、気になった箇所を自分で書き直して返す。
作業の品質は上がります。しかし、新人に残るのは「直された」という事実だけで、なぜ直されたのかは残りません。
料理教室にたとえると、生徒が作った料理を先生が味見して、黙って塩を足して「はい、完成」と言うようなものです。料理はおいしくなりますが、生徒は次も同じ味付けをするでしょう。
理由2: 指摘の重さが分からない¶
もうひとつは、指摘がすべて同じ重さで並んでいることです。
「この手順だとサービスが止まる」という致命的な指摘と、「コマンドの書き方はこちらのほうが読みやすい」という好みの指摘が、同じ赤字で並んでいる。新人から見ると、どれが絶対に直すべきもので、どれが参考程度なのかが分かりません。
結果として、全部を等しく直すことになり、本当に覚えてほしい指摘が埋もれてしまいます。
理由3: 結果だけを見ている¶
3つ目は、レビューの対象が完成した手順書だけになっていることです。
インフラエンジニアの作業では、手順そのものより、その手順にたどり着くまでの考え方のほうが大切な場面がたくさんあります。影響範囲をどう見積もったのか。切り戻しの判断基準をどう決めたのか。
完成品だけを見ていると、こうした考え方に触れる機会がないまま、形だけ整った手順書が量産されていきます。
育成につながる作業レビューをどう設計するか？¶
ここからは、先ほどの3つの理由をひとつずつ裏返していきます。
指摘にラベルを付けて、重さを伝える¶
まず取り入れやすいのが、コメントにラベルを付けるルールです。
Googleのレビュー指針では、スタイルガイドにない細かな改善点には Nit: という接頭辞を付け、必須ではない磨き上げの指摘だと相手に分かるようにすることが勧められています。これをインフラエンジニアの作業レビューに合わせて広げると、次のような形になります。
| ラベル | 意味 | 新人に求める対応 |
|---|---|---|
| 必須 | 直さないと障害や事故につながる | 必ず修正し、なぜ危ないのかを自分の言葉で説明する |
| 質問 | レビュアーが意図を確認したい | 考えた理由を答える。答えられなければ一緒に考える |
| 提案 | より良いやり方の紹介 | 採用するかは本人が判断してよい |
| Nit | 表記や書き方の好み | 直さなくてもよい |
| Good | うまくできている点 | 次も同じようにやる |
ポイントは、Goodのラベルを表に入れていることです。できていることを言葉にして返すと、新人は何を続ければよいのかが分かります。
直す代わりに、問いで返す¶
次に、先輩が直して返す習慣を変えます。すべての指摘を問いの形にする必要はありませんが、必須の指摘のうち、考え方に関わるものは問いで返すのがおすすめです。
たとえば、次のような違いです。
【直して返す例】
手順5の前に、設定ファイルのバックアップを取る手順を追加しました。
【問いで返す例】
[質問] 手順5で httpd.conf を書き換えたあと、元に戻したくなったら
どの手順で戻しますか？ 切り戻しの章から逆にたどってみてください。
問いで返すと、レビューのやり取りは1往復増えます。それでも、新人がバックアップの必要性に自分で気づく経験は、赤字で直された経験よりもずっと記憶に残ります。
手順書を読む側の心構えについては、新人向けに手順書をそのまま実行する前に確かめることという記事も書いています。レビューの問いと、この記事の観点をそろえておくと、新人は何を聞かれるのかを事前に予想できるようになります。
成長段階に合わせて、レビューの深さを変える¶
すべての新人に、同じ深さのレビューをする必要はありません。むしろ、段階に合わせて変えるほうが自然です。
| 段階 | レビューの対象 | レビューの重点 |
|---|---|---|
| 入社〜3か月 | 先輩が書いた手順書を新人が読んで説明する | 手順の意味を理解しているか |
| 3〜6か月 | 新人が書いた手順書 | 抜け漏れ・切り戻し・確認手順 |
| 6か月〜1年 | 作業計画（影響範囲・実施判断を含む） | 考え方と判断の根拠 |
| 1年〜 | 新人が他人の手順書をレビューする | 観点を持って読めているか |
段階を上げる条件は、本番環境の権限を渡すタイミングとそろえておくと運用しやすくなります。権限の段階設計については本番環境の権限を3段階で考える記事で詳しく解説しています。
新人をレビュアーにすると、何が変わるのか？¶
表の最後の段階について、もう少し補足させてください。
新人がレビューする側に回ると、観点が一気に言語化されます。 人の手順書を読んで、どこが危ないかを指摘するには、自分の中にチェックの基準がなければなりません。
最初から一人で任せる必要はありません。先輩のレビューに並走させて、新人が先にコメントを書き、そのあと先輩がコメントを足す。この形なら、新人の見落としがそのまま学びの材料になります。
レビューの観点を、チームの共通言語にする¶
新人をレビュアーにするときに役立つのが、観点のチェックリストです。たとえば、次のようなものです。
作業レビューの観点（例）
1. 作業の目的と、完了の判定条件が書かれているか
2. 影響を受けるサービス・利用者と、その時間帯が書かれているか
3. 各手順の前後に、確認のコマンドと期待する結果があるか
4. 途中で失敗したときの切り戻し手順と、切り戻す判断基準があるか
5. 作業ログをどこに残すかが決まっているか
このリストは、新人のためだけのものではありません。先輩ごとにばらばらだったレビューの基準が、チームの共通言語になります。
5番目の作業ログについては、新人向けに作業ログ（証跡）の残し方をまとめています。レビューの観点に入れておくと、ログを残す習慣も自然に定着していきます。
仕組みとして回すために、押さえておきたいこと¶
最後に、作業レビューを育成の場として続けていくための注意点を整理しておきます。
レビューの時間を、業務として確保する¶
問いで返すレビューは、赤字で直すよりも時間がかかります。この時間を先輩の善意に頼っていると、忙しい時期にすぐ元に戻ってしまいます。
育成を担う先輩の役割と時間の確保については、OJTを仕組みに変えるトレーナー制度の記事で書いたとおりです。レビューにかける時間も、トレーナーの業務としてあらかじめ見込んでおくことをおすすめします。
完璧を求めすぎない¶
Googleのレビュー指針には、完璧なコードは存在せず、あるのはより良いコードだけだ、という考え方が示されています。レビュアーは細部まで磨き上げることを求めるのではなく、前に進むことと指摘の重要さを比べて判断すべきだとされています。
新人の手順書にも同じことが言えます。必須の指摘がなくなれば、あとは提案とNitにとどめて、作業に進ませる。完璧になるまで何往復もさせると、レビューそのものが新人にとって怖いものになってしまいます。
レビューのゴールは、完璧な手順書を作ることではありません。次の手順書を、新人が今回より良く書けるようにすることです。
作業のあとに起きた失敗を責めずに学びに変える考え方は、ブレームレス・ポストモーテムを新人育成に組み込む記事でも扱っています。作業前のレビューと作業後の振り返りがそろうと、新人は作業の前後で学べるようになります。
研修の段階から、レビューに慣れておく¶
現場に出てから初めてレビューを受けると、新人は指摘を「怒られた」と受け取りがちです。できれば、研修の段階から手順書を書いてレビューを受ける経験を積んでおくのが理想です。
InfraAcademyの法人プランでは、新人インフラエンジニア研修の中でLinuxやネットワークの操作を体系的に学べるようにしています。基礎を研修で固めておけば、現場のレビューでは手順の意味や判断の根拠といった、より本質的なやり取りに時間を使えるようになります。研修の設計でお悩みの方は、ぜひ一度ご相談ください。
現場でよく聞かれる疑問に答えておこう¶
ここまでの内容を育成担当の方にお話しすると、決まって出てくる質問がいくつかあります。代表的なものに答えておきます。
急ぎの作業でも、問いで返すべきですか？¶
いいえ、そこまでこだわる必要はありません。障害対応のように時間の制約が厳しい場面では、先輩が直接直して作業を進めるほうが正しい判断です。
大切なのは、急ぎの作業が終わったあとに、短い振り返りの時間をとることです。「あのとき手順をこう直したのは、こういう理由だった」と後から伝えるだけでも、直して返すだけの場合とは残るものが違います。
問いで返すレビューは、時間に余裕のある定例作業や、手順書の新規作成のときに集中して使うのが現実的です。
レビューのコメントで、新人が萎縮してしまいます¶
コメントの量が多すぎることが、原因になっている場合がよくあります。一度のレビューで20も30も指摘が並ぶと、どんなに言葉を選んでも、新人には否定の山に見えてしまいます。
そんなときは、必須の指摘を優先し、Nitは思い切って省くのがひとつの手です。Goodのコメントを最低ひとつは入れる、というルールをチームで決めておくのも効果があります。
もうひとつ有効なのが、レビューの一部を対面や通話で行うことです。文字だけだと冷たく感じる指摘も、画面を一緒に見ながら話せば、単なる確認として受け取ってもらいやすくなります。
まとめ¶
今日の内容を振り返ります。
- レビューには、ミスを見つけるだけでなく、知識の移転やチームの状況把握を助ける効果がある
- ダブルチェックが育成につながらないのは、先輩が直して返す・指摘の重さが分からない・結果だけを見る、の3つが主な原因
- 指摘にラベルを付け、考え方に関わる指摘は問いで返す
- 新人の成長段階に合わせてレビューの深さを変え、最後は新人自身をレビュアーにする
- レビューの時間は業務として確保し、完璧を求めすぎない
作業レビューは、新しい制度を作らなくても今日から変えられる育成の場です。 まずは次のレビューで、コメントにひとつだけGoodを付けるところから始めてみてはいかがでしょうか。
新人が自分の手順書に自信を持てるようになる日は、きっとそう遠くないはずです。
