シリーズについて：「職場の暗号辞典」は、エンジニアが職場で使う言葉の「本当の意味」を翻訳するシリーズです。
- Vol.1：設計レビュー編（本記事）
- Vol.2：コードレビュー編（近日公開）
- Vol.3：障害対応・振り返り編（近日公開）
- Vol.4：スプリント・スクラムイベント編（近日公開）
- Vol.5：1on1編
- Vol.6：採用面接編
- Vol.7：見積もり編
- Vol.8：技術選定編
はじめに
設計レビューには独自の言語体系があります。
表向きは穏やかに技術的な議論をしているように見えて、実は全く別のことを言っていることがあります。入社したての頃、先輩の「ちょっと気になるんですが」を字義通りに受け取って大変なことになった経験がある人もいるのではないでしょうか。
この記事では、設計レビューでよく聞く言葉を素直な日本語に翻訳します。笑えるネタのようで、ちゃんと実用的なはずです。
翻訳辞典：設計レビュー編
「ちょっと気になるんですが」
翻訳： それは絶対にダメです
設計レビューで最も危険な前置きです。柔らかいトーンに惑わされてはいけない。これが出てきたら、後に続く指摘は重大な問題である可能性が高い。
「ちょっと気になるんですが」 の破壊力は、その後の言葉の内容と関係なく、むしろ言い方の柔らかさに反比例します。
対処法： 「気になる部分、もう少し詳しく聞かせていただけますか？」と深掘りを促す。
「なるほど、面白いアプローチですね」
翻訳： 全然面白くないし、なぜこうなったか理解できていません
「面白い」という形容詞が設計レビューで出てきたら警戒サインです。純粋な褒め言葉ではなく、多くの場合「理解しきれていないが否定もしにくい」状態を表します。
ただし例外もあります。先輩エンジニアが「これは本当に面白い」と言うときは、本心から感心していることもある。文脈と表情で読み取るしかない。
対処法： 「どの部分が特に気になりましたか？」とピンポイントで聞く。
「スケールしますか？」
翻訳： このままでは数ヶ月後に詰む気がします（でも根拠は薄い）
スケーラビリティへの懸念は正当な指摘のことも多いですが、実は「なんか不安」という直感を技術的な言葉で包んでいるケースも少なくありません。
重要なのは、具体的な数字が伴っているかどうかです。「月間PV1億になったときのDB負荷はどう計算していますか？」なら本物の懸念。「スケールしますか？」だけなら「どのくらいのトラフィックを想定しているんですか？」と数字を引き出しましょう。
対処法： 設計書に「想定トラフィック・データ量」のセクションを最初から入れておく。これがあると「スケールしますか？」系の質問がほぼ出なくなる。
「既存の〇〇でできませんか？」
翻訳： 新しいものを作らせたくない（理由はメンテコストへの恐れ）
新しいコンポーネントやサービスを提案したときに出やすいフレーズです。「既存活用」の精神自体は健全ですが、「とにかく増やしたくない」という感情が動機のことも多い。
対処法： 既存で対応できない理由を先に書いておく。「〇〇で検討しましたが、△△の理由で対応不可と判断しました」という一文があるだけで、この質問がほぼ来なくなります。
「後で対応でもいいですか？」
翻訳： これは永遠に対応されません
設計レビューにおける最も優雅な先送り表現です。「後で」がTODOコメントと同様の運命をたどることは、エンジニアなら全員わかっているはず。
例外：締切が本当に迫っていて、Issueにちゃんと起票される場合。
対処法： 「後で」と言われたら「いつ頃を想定していますか？担当者はどなたですか？」と確認する。答えが曖昧なら、そのまま流すか今やるかの二択です。
「このへんはどう考えていますか？」
翻訳： ここ、考えてませんよね？
優しい問いかけに見えて、実は「考慮漏れを発見した」というシグナルです。設計者が「あ、そこは…」と詰まる様子を見て、指摘者はすでに答えを知っています。
対処法： 設計書を書く前に「自分はここをどう考えているか？」とセルフレビューする習慣をつける。考えていない部分は自分で先に「〇〇については検討が必要と認識しており、△△の方針を予定しています」と書いておく。
「参考までに確認なんですが」
翻訳： これは必ず確認してほしいことです
「参考までに」「念のため」「確認なんですが」は、日本語の職場における強調表現です。本当に参考程度の質問には、こんな前置きはつきません。
対処法： この前置きがついた質問は、最優先で回答する。次のレビューまでに必ず対応する。
「全体的には良いと思います」
翻訳： 個別の問題点はたくさんありますが、まとめると言いたいことがありすぎて収拾がつかない
「全体的には良い」という評価は一見ポジティブに聞こえますが、「全体的には」という限定詞がついている時点で、部分的には良くない箇所があることを示唆しています。
対処法： 「ありがとうございます。特に気になった点があれば教えていただけますか？」と引き出す。
「もう少し詳しく説明してもらえますか？」
翻訳： ①理解できていない、または②理解した上で納得していない のどちらか
レビュアーの質問には2種類あります。純粋に理解のための質問と、同意を求めているが反論したいための質問。どちらかによって、回答の戦略が変わります。
見分け方： 「詳しく説明してもらえますか？」の後に「なるほど」で終わったら前者。「それでも〇〇という懸念は残りますが」と続いたら後者。
翻訳が必要な理由：構造的な問題
なぜこんな言語体系が生まれるのか。
設計レビューは権力関係と知識格差が交差する場だからです。
- シニアが「ちょっと気になる」と言えば、ジュニアは強く言えない
- 「否定する」より「質問する」方が場の空気を壊さない
- 日本の職場文化では、直接的な否定を避ける傾向がある
これは悪ではありませんが、暗号を読み解けない人が損をする構造です。
暗号が少ない設計レビューを作るために
翻訳辞典も大事ですが、そもそも暗号が少ない場を作る方が健全です。
設計者として：
- 「検討しなかった/できなかった理由」を正直に書く
- 不確かな部分を先に「ここは自信がありません」と明示する
- 質問が来やすいポイント（スケール、既存との比較、コスト）を先回りして書く
レビュアーとして：
- 「気になる」ではなく「〇〇という理由でリスクがあると思います」と言う
- 「面白い」ではなく「〇〇の部分をもう少し聞かせてください」と言う
直接的に言える文化は、一人が変えてもなかなか変わらない。でも、自分から始めることはできます。
おわりに
この記事が「あるある」と笑えた人は、少なからず同じ経験をしてきているはず。
設計レビューの言葉を翻訳するのは笑いのためだけじゃなくて、言外の意味を読めるようになることが目的です。暗号が読めれば、ちゃんと対処できる。
次回は「コードレビュー編」。「nit:」「LGTM（ただし…）」「お好みで」の本当の意味を翻訳します。
株式会社なかのひとカンパニーでは随時エンジニアを募集しています。詳しくは採用情報ページをご確認ください。