はじめに：「言葉が通じていない」のではなく「意味が通じていない」

最近、ベトナム・インドネシア・ミャンマーなど、東南アジアのエンジニアと協働する機会が急増しています。特にフロントエンドやモバイル開発の現場では、React・Vueなどを扱う中でレビューが日常的に行われています。

しかしそこで生じやすいのが、「レビューコメントが意図通りに伝わらない」問題です。

  • 何度指摘しても、同じ構造のコードが繰り返される
  • コメントは理解されたように見えて、直後の実装がそれに沿っていない
  • 実装者が黙ってしまう、あるいは「でも動いてます」と反論する

これは単に英語が通じていないのではなく、使われている言葉の意味が、実装者の中で異なる形で解釈されていることに起因します。
たとえば「Optional」「Wrapper」「State」など、一見共通語のように見える単語が、設計やレビューの文脈でまったく異なる意味を持って受け取られているのです。

本稿では、そうした「設計用語のズレ」によるレビュー誤解の典型パターンを7つ取り上げ、レビューアーがどう向き合うべきかを構造的な観点から考察していきます。

1. 「Optional」＝やらなくてもよいと思われる

たとえばレビューでこう書いたとします：

Comment 
Optionalでよいと思います。

これを読んだ実装者が「これはやらなくてよいんだな」と判断し、実装をスキップしてしまう──というケースは、実際に多くのレビュー現場で見られます。

これは、“Optional” という言葉の解釈が文化圏によって異なることが原因です。
ベトナムやミャンマー出身の開発者には、“Optional” が「任意＝不要」「やらない選択肢」と強く結びついているケースがあります。
つまり、「やるかやらないかを選べる」のではなく、「やらないでいい」の意味に解釈されるのです。

実際に起きたやり取り例

Reviewer: This validation is optional for now.
Developer: OK, I skip it.

→ 実際には「実装してもいいけど、今じゃなくていい」という意味だった
→ しかし「今回はやらなくていい」＝「存在そのものが不要」と解釈された

この誤解が起こる理由
  • Optional＝「選択肢がある」ではなく「やらなくていい」と受け取られる
  • タスク管理文化上、「やるかやらないか」が曖昧な指示が排除されがち
  • 「後でやる」＝「やらない」とされる場面もある
英語で伝えた方がいいか？

否。英語の “Optional” は避けた方がよい。
“Optional” は誤解されやすい単語の典型であり、英語で書くとむしろ誤解を加速する。
代わりに以下のように書き換えるとよい：

  • “Can be implemented later, but still recommended”
  • “Let’s skip this for now, but please prepare for it”

または明確に実装指示を書く：

「後で実装予定なので、TODOとして残してください」

2. 「Component」＝ただの見た目の部品と理解される

Reactにおける「Component」は、責務を分離し、再利用可能な構造単位として設計されるものです。
しかし、外国籍エンジニア（特にHTML・CSSの実装経験からキャリアをスタートした層）には、“Component = 見た目をまとめる箱”という理解にとどまっていることがあります。

たとえば以下のような会話が起きます。

Reviewer: This component is doing too much.
Developer: But it only shows a button…

見た目としてはボタンしかない。だが実際には、副作用のある useEffect、内部状態の管理、外部 API 呼び出しがすべて含まれている──こうした“構造上の肥大化”が、視覚的シンプルさに覆い隠されていることがあります。

「Component」の語義のすれ違い

日本人レビューアーの意図 実装者の解釈（誤解）
構造上の単位（責務分離の対象） 見た目のまとまり、タグのラップ
表示以外の責務も含まれる 表示しかしてない（つもり）
状態や副作用が含まれているかに着目 ボタンしか出してない＝問題なし

このような背景から、「Component が重い」「Component に責務が集中している」という指摘が、“UIが派手”という意味に受け取られることがあります。

レビュー指摘例（悪手）

Comment 
@Reviewer: This component is too complex. Try to split it.

→ 「でもこれ、ただのラッパーじゃないですか？」と返される可能性大

レビュー指摘例（改善案）

Comment 
@Reviewer: This component is rendering UI, managing state, and calling APIs at the same time. Let's extract logic and state management into a hook, and keep this component focused on display only.

このように、“何が重いのか” を構造で具体化すると、意味がブレにくくなります。

英語で伝えた方がいいか？

可。英語でも伝えやすいが、抽象語は避けて具体的にするべき。

“component” という単語は文化により定義が分かれるため、“too big” や “complex” といった抽象語を避け、

  • “It handles rendering + state + effect” のように責務を列挙する
  • “Should be split by concern: rendering, state, side effects” とSoC視点で語る

などの明示的な構造言語を使う方が効果的です。

3. 「Complex」＝行数の話だと思われる

レビューでよく見かけるコメントのひとつに、

Comment 
@Reviewer: This function is too complex.

というものがあります。しかしこれを見た実装者から返ってくる反応として非常に多いのが、

“But it’s only 10 lines.”

という言葉です。

ここで起きているのは、「Complex」の意味が“構造的な複雑さ”ではなく、“見た目の長さやネストの深さ”として解釈されているというすれ違いです。

構文と責務の混同

次のようなコードを見て「シンプル」と答える実装者は少なくありません。

一見短いが責務が交差する関数 
async function handleClick() {
  const user = await fetchUser();
  updateUserName(user.name);
  logUserAction(user.id);
}
  • 行数：3行
  • ネスト：0
  • 変数名：明確

しかしレビューアーから見ると、3つの責務（取得／状態更新／ログ）が同居しており、将来変更時に結合度が問題になります。
これこそが“構造的に複雑”な関数です。

責務ベースで語るレビューへ

レビュー時には「長さ」ではなく「関心事の数」「責務の交差」を基準に伝える必要があります。

責務明示型レビュー 
@Reviewer: This function fetches data, updates state, and logs user behavior. Consider splitting into smaller functions to isolate responsibilities.

このように具体的な役割（do A, then B, then C）を挙げることで、「複雑」の意味が曖昧にならずに済みます。

英語で伝えた方がいいか？

注意が必要。抽象語“complex”の単独使用は避ける。

“Complex” は文化・教育背景により、「長いコード」「ネストが深い構文」などに直結してしまう単語です。
そのため、英語でコメントする場合は必ず次のような形式で具体的に書くことが望ましいです：

  • “This function does three different things: X, Y, Z.”
  • “Can we split this logic into smaller parts to improve clarity?”

抽象語 → 責務列挙 に言い換えるのが鉄則です。

4. 「Wrapper」＝ただのdivと思われる

ReactやVueでは、共通レイアウトやロジックの抽象化として「Wrapper（ラッパー）」コンポーネントが頻出します。
しかし、レビューで「Wrapper使ってるの？」と聞くと、「はい、<div>で囲ってます」という返答が返ってくることがあります。

これは、Wrapperという語が“HTMLのタグの囲い”として解釈されてしまっていることを意味します。

Wrapperの2つの意味の齟齬

用語 レビューアーの意図（構造的） 実装者の解釈（視覚的）
Wrapper 責務を抽象化したHOC / Composition層 スタイリングや配置用のdiv要素
例 withTracking(UserCard) <div class="wrapper">

たとえば、以下のような構成：

設計意図のあるWrapper 
export const TrackedComponent = withTracking(MyComponent);

レビューアーは「責務をラップする構造」として意味付けしているが、これが「見た目のレイアウト」と誤認されることで、HOCやロジック抽出の意図が理解されず破棄されることがあります。

よくあるレビュー誤解

Comment 
@Reviewer: This wrapper adds unnecessary complexity.

→ 実装者視点では「ただのdivを消せってこと？」という受け取りになる。

責務明示のレビュー例

Comment 
@Reviewer: This wrapper adds tracking logic. If we remove it, we may lose behavior. Let's clarify its purpose or rename it accordingly.

“何を包んでいるのか”が明確にされれば、設計意図としてのWrapperが伝わりやすくなります。

英語で伝えた方がいいか？

可。ただし “wrapper” 単体では意味が通じにくいため補足が必須。

“Wrapper” は英語ネイティブでない開発者にとって、HTMLタグのラップと解釈されやすい単語です。
そのため、レビューでは以下のように目的・動作をセットで記述することが重要です。

  • “This wrapper adds logging logic”
  • “This wrapper connects the component to context”
  • “This is a functional wrapper, not a visual wrapper”

Wrapper = 構造責務のために存在する、というメッセージが必要です。

5. 「Responsibility」＝責任追及と誤解される

コードレビューでよく使われるキーワードに「責務（Responsibility）」があります。
たとえば以下のようなコメントは構造的観点からは自然です：

Comment 
@Reviewer: This component has too many responsibilities. Please separate data fetching and rendering.

しかしこの「責務（responsibility）」という単語、一部の文化圏では非常に強い“個人の責任”の意味で受け止められてしまうことがあります。

言葉が設計指摘ではなく「個人批判」に変換される

たとえばベトナムやインドネシアでは、「Responsibility」という語が「担当範囲」ではなく「失敗時に責任を取るべきもの」と解釈されがちです。

  • 「Componentに責任が集中している」と言いたいのに
  • 「あなたが責任を果たしていない」と読まれてしまう

結果として、実装者が委縮したり、防御的になったり、場合によっては黙り込むことすらあります。

設計としての責務を共有する書き換え

責務の設計意図を明確化 
@Reviewer: This component mixes three roles: data fetch, state management, and display. Consider extracting those to maintain single-purpose logic.

このように「役割（role）」「関心事（concern）」などの言い換えを使うことで、個人に向けた指摘ではないことを構造的に伝えることができます。

英語で伝えた方がいいか？

慎重に。Responsibilityは文化によって強い圧力を伴う単語になる。

特に英語非母語のチームでは、“responsibility” が「お前が悪い」ニュアンスに受け取られやすく、心理的なハレーションが起こる可能性があります。

英語で指摘する場合は以下のような単語を推奨します：

  • “This component has multiple roles”
  • “There are too many concerns in one place”
  • “Let’s break this into smaller units for clarity”

“責務”を伝えるには、責任ではなく「構造的役割」として言い換えるのが望ましいです。

6. 「This should be extracted」＝命令に聞こえる

コードレビューでよく使われる文言に「This should be extracted」があります。
たとえば次のような指摘：

Comment 
@Reviewer: This logic should be extracted into a hook.

日本人にとっては「構造を整理するための提案」として自然に読めるこの表現が、相手によっては「命令」として受け止められることがあります。

文法上の「should」の受け取り方が異なる

  • 日本語では “〜すべき” はアドバイス的に使われる
  • しかし英語における “should” は教育背景や文脈によっては「強制的な指示」と理解される

特に「これで動いているのに、なぜ？」という感覚を持っている実装者にとっては、「いきなり命令された」と感じられる場合が少なくありません。

典型的な返答のすれ違い

Reviewer: This should be extracted for clarity.
Developer: But it’s working fine. Why do I have to?

→ 意図：責務の明確化
→ 受け取られた意味：「今すぐやれという強制命令」

調整表現の例：命令から提案へ

より柔らかなレビュー表現 
@Reviewer: Would it help to extract this into a hook? It might improve testability and clarity.

あるいは、ややフォーマルに：

Comment 
@Reviewer: You might consider extracting this part to make responsibilities more explicit.

文法を変えるだけで、指摘のトーンが大きく変わります。

英語で伝えた方がいいか？

伝えるなら “should” は避けて、提案系表現へ置き換えること。

“should” は形式として無難ですが、文法的に「べき論」に聞こえるため、レビュー文脈では強すぎる可能性があります。
以下のような表現がより安全で伝わりやすいです：

  • “You might consider…”
  • “Would extracting this help with…?”
  • “This could be extracted to simplify the logic.”

英語でのレビューでも、構文トーンの調整が極めて重要です。

7. 「State」＝useStateの話だと思われる

Reactコードレビューでは「状態（State）」という単語が頻出します。
しかし、この“State”という言葉がuseState だけを指すと思われてしまうケースがしばしばあります。

よくあるすれ違い

Reviewer: This component has too much state.
Developer: But it only has one useState…

レビューアーが言いたかったのは「データがコンポーネントに集中している」「責務として状態管理を背負いすぎている」ことであり、
実装者が言っているのは「useStateが1つしかない」という数の話です。

ここには、“State”という言葉に対する構造理解の違いがあります。

ReactのState＝useStateに限らない

レビューアーが問題視する「State」には以下のような要素が含まれています：

  • データの保持（props → stateへのコピー）
  • 状態の派生ロジック（例：メモ化、条件分岐）
  • UIの表示条件（開閉、活性化など）
  • 副作用の管理（useEffect内での状態依存）

にもかかわらず、実装者が「useStateの数＝状態の複雑さ」と単純化してしまうことで、構造的な問題が無視されてしまうのです。

より明示的なレビューにするには

Comment 
@Reviewer: This component holds multiple derived states (e.g., loading status, input validation). Consider extracting logic to hooks or moving state up.

こうした具体的な状態の種類・責任範囲を記述することで、“状態が多い”という抽象的表現が構造上の問題として伝わるようになります。

英語で伝えた方がいいか？

可。ただし“state”単独では抽象的すぎるため、状態の種類を列挙する方がよい。

  • “too much state” → “manages loading, error, form input, and UI toggle states”
  • “This component tracks multiple UI and data states” などと展開することで、レビューの意図が明確になります。

英語で伝える場合も、状態の“内訳”を具体的に語ることが重要です。

誤解を防ぐレビューコメント チェックリスト

指摘のたびに確認したい5つのポイント

おわりに：誤解を防ぐのは設計ではなく構造と言語の“橋”

異文化・多国籍のチームにおけるコードレビューでは、抽象語・設計語・英語の表現選択が思わぬ誤解を生む原因になります。
本稿で紹介したような誤解パターンをレビュー観点で予測し、「構造で語るレビュー」＋「文化への配慮ある言葉選び」の両立が求められます。

レビューとは“コードの確認”であると同時に、“構造の対話”でもあります。
その対話の精度は、設計視点と表現の粒度にかかっています。