まずは自己紹介
ナレッジワークでエンジニア組織の仕組み作りなどを担当しているsedoと申します。
Enablement Groupという部署に所属していて、社内のプロジェクト管理の仕組みを整えたり、社外への情報発信イベントの運営サポートなどをしています！
「なんか読みにくいんですよね…」から始まった話
読める。動いてる。エラーも出てない。
でも――なんでこう書いたんだろう？と、コードの前で手が止まる。
誰かの実装にケチをつけたいわけじゃない。
でも、判断の理由が見えないコードって、どこか触るのが怖い。
レビューもしづらいし、直す勇気も出てこない。
ある日の定例ミーティング後、若手エンジニアのナギサさんが、そっと言った。
「△△さんのあの処理なんですけど、動作自体はちゃんとしてるんです。でも、正直ちょっと読み解くのが大変で…」
ナギサさんは、物腰が柔らかくて丁寧な、でもとても優秀なエンジニアだ。
このときも、相手を傷つけないように、慎重に言葉を選んでいた。
「意図はあると思うんです。でも、コメントもないし、変数名もちょっと抽象的で…。うまくレビューもできなくて」
結局、「これは触らない方がいいやつかも…」とそっと閉じてしまう。
そうやって、保留のコードが積み重なっていく。
このときふと感じたのは、「ルール」が足りないんじゃない。
「判断の基準」が共有されていないことが、根っこにあるんじゃないか――ということだった。
ルールがあるのに、なぜこうなる？
ふりかえってみると、ルール自体はちゃんと決めていた。命名規則も、ディレクトリ構成も、ドキュメントもある。
だけど、現場ではそれが「うまく使えない」「活かされていない」と感じることが増えてきた。
- ルールは知ってるけど、具体的なケースにどう当てはめるか迷う
- 想定外のパターンに遭遇すると、例外を許すかどうか判断できない
- 誰かの意図が見えないと、指摘も修正も難しい
ルールが守られないのは、怠慢ではない。
判断のよりどころがないから、みんなが自信を持てないのだ。
判断基準が見えないと、コードもチームも迷子になる
「意図が見えない」と、手が止まる
過去のコードに触れていて、こう感じたことはないだろうか？
- 「この順番で処理してるのって、なにか理由あるのかな…？」
- 「ここだけ例外処理が丁寧なのって、バグ回避のため？」
- 「この責務の分け方、なんか他と違う…？」
きっと、そのときの実装者には理由があったはず。
でも、それを知る手がかりがなければ、触る側は不安しかない。
不安だから手が出せない。レビューもしづらい。結局、そっとスルー。
そんなコードが少しずつ増えていくと、チーム全体の判断力も揺らいでいく。
小さな「迷い」の連鎖が、複雑なコードを育てる
「とりあえず動くようにしておいた」
「このへんはたぶん、他の人が詳しいから触らないでおこう」
「うーん…まあ今回はこれでいいか」
そんな小さな選択が積み重なって、気づけば誰も触りたくないコードができあがっている。
「判断基準」を共有することで、迷いを減らす
ナギサさんがふと漏らした。
「これって書き方の話じゃなくて、考え方の違いなんですよね」
「なんでそうしたかが分かれば、もっと納得できるし、レビューも対話になりそうで」
その一言が、チームの変化のきっかけになった。
判断基準を育てるための、ちょっとした仕組み
・PRテンプレートに「なぜこの実装にしたか」を書く
たった一文の背景説明があるだけで、レビューの空気は大きく変わる。
「初期リリースの範囲を優先し、汎用性よりもシンプルさを選びました」
ナギサさんも「こういう一文があると、レビューの姿勢が変わるんです」と話していた。
・レビューコメントに「判断理由」を添える
レビューをする側も、単に「こっちのほうがいい」と言うだけではなく、
「なぜそう思ったのか」「どういう観点で見ているのか」を一緒に書くようにすると、レビューは指摘ではなく対話になる。
「以前この実装でバグが出たことがあるので、今回は安全側で設計してもらえると嬉しいです」
背景を共有することで、受け手も納得しやすくなるし、考え方の擦り合わせにもつながる。
・SlackやNotionで「良い判断例」を気軽にシェア
ナギサさんは、判断に迷った場面や、納得できた実装をメモに残していた。
「こっちは処理が短くなるけど、未来の自分が読めなさそうだったので、あえて冗長に書きました」
日常の中に埋もれがちな良い判断を拾って残す。
それだけで、判断基準の種が育っていく。
・ふりかえりで「判断に迷ったところ」を話す
「実は、ここの設計、拡張性とシンプルさでめちゃくちゃ悩んだんですけど…」
迷った記録も、立派な判断の材料。
その葛藤を言葉にしてみるだけで、他の人の視野にもなる。
判断基準は育てていくもの
判断基準は、誰かが最初から持っているわけじゃない。
対話や振り返り、ちょっとした共有の中で、チーム全体で育っていくものだ。
- 押しつける ではなく、聞き合う
- 指摘する ではなく、なぜそうしたかを語る
- 評価する ではなく、迷いを言葉にする
そんなチームで開発できたら、レビューも実装も、
少しずつやさしく、しなやかなものになっていく気がする。
ナギサさんは、今日もまた、丁寧にレビューコメントを書いていた。
誰かを正すためじゃなく、その人の考えに寄り添うために。
あなたのチームでは、どんな判断基準が育っていますか？
最後にちょっと紹介
他にも以前に私が投稿した記事を紹介しておきます。ご興味あれば読んでみてください。