「エンジニアじゃないのに書けるのすごい！」から始まったレビューの工夫

こんにちは、しがないエンジニアの k_y16 です。

最近、GAS や Colab を使って業務のちょっとした自動化スクリプトを書く非エンジニアの方が増えてきました。
ここでいう「非エンジニア」とは、普段はバックオフィスやマーケティングなど別業務を担当しているけれど、必要に応じて自動化に挑戦しているメンバーを指しています。

エンジニア同士のレビューと違って、Git 管理やレビュー文化が整っていないケースも多く、運用を見据えた作りになっていないこともしばしば。
だからこそ「どうレビューすればいいんだろう？」と迷う場面が多くありました。

正直めちゃくちゃありがたいですし、いつも助かってます！
最初にレビューをお願いされたときは「うまくレビューできるかな…」という不安もありましたが、同時に「エンジニアじゃないのに書けるのすごい！」と素直に思って、どんなコードなんだろうとワクワクしました。

実際に見てみると、AI の普及もあってかとても丁寧に書かれていて正直驚きました。
エンジニアにとっては当たり前のフィードバックでも「目からウロコでした」と言ってもらえるのはすごく嬉しかったです。

そんな経験を通して、非エンジニアの方が書いてくれたコードをレビューするときに、自分なりに意識していることを整理してみました。

---

レビューで意識していることを一言で

学習コストを増やさず、運用を安定させる

---

まず目的と運用を合わせる

• 何を自動化したいか／頻度／誰が回すか／失敗時どうするかを先に確認。
• 今回は Git 連携をしていないため、証跡は Jira のコメントに残すようにしました。
  正直レビュー観点ではちょっと大変でしたが、まずは「誰が見ても経緯が追える」状態を最低限確保することを意識しました。

---

改善はできるだけ具体的に

• 抽象的な指摘より “こう直す” を提示。
  例）「タイムアウト時は3回だけリトライして Slack 通知」「スプレッドシートIDは定数化」。
• 伝え方も工夫。リトライやエラーハンドリングなど難しい部分は、できるだけシンプルに改善案を示すようにしています。

---

自動化の肝は厚めにレビュー

• エラー処理：try/catch、失敗理由の記録。
• リトライ：最大回数・待機時間・打ち切り条件。
• 途中再開：処理済み行の記録で再実行に強く。
• ログ／通知：Slack・メールで異常を見逃さない。

ここはエンジニア経験の有無に関係なく、運用に直結するのでなるべく丁寧に見ています。

---

綺麗さは最小限、運用直結は細かく

• 変数名・関数分割は「意味が通る／読める」までで十分。
• ただし 運用に効く部分は細かく：定数化（シート名・列番号・URL）、環境変数化（APIキー）、スケジュールや権限の明記。
• 印象的だった指摘の例でいうと、早期 return の活用やネストが深すぎる処理を浅くすること。このあたりは次に見返す自分たちのためにも結構大事。

---

小さなドキュメントを残す

• 今回は README を用意していないので、コードコメントや Jira のコメントで「使い方／前提／よくある失敗や復帰手順」を残すようにしました。
  完璧でなくても、後から見た人が復帰できる最低限の情報を残すことが大事だと思っています。

---

今後の改善

今回のレビューでは Git 連携がなく、証跡は Jira のコメントで残す形を取りました。
ただ正直なところ、この状態だとレビューが結構しんどいです…。
コードの履歴も追いづらく、改善の流れが見えにくいのも課題だと感じています。

なので今後は Git での管理を導入して、よりスムーズかつ効率的にレビューできる体制 を整えていきたいです。
具体的には、ブランチを切って PR ベースでレビュー → コメントや差分がそのまま履歴に残る、という形に移行できれば理想的かなと思っています。

エンジニアにとっては当たり前の仕組みでも、非エンジニアにとってはちょっとハードルが高い部分。
だからこそ仕組み化して「自然に履歴が残る」環境を作るのが一番の改善だと思っています。

---

最後に

レビューのときに大事にしているのは「舐めてかからない」こと。
非エンジニアだからといって手を抜かず、しっかりレビューしつつ、その人の習熟度に合わせて伝え方を変えます。
「将来的にこうするともっと良いかも」と一歩先の改善も合わせて伝えるのが自分のスタイルです。

完璧に書き換えるより、明日も安心して回る状態にすることを優先。
小さな成功体験を積み重ねてもらうのが、非エンジニア向けレビューのゴールだと思っています 🙏