💡 この記事の3行まとめ
- Issueが遅いのは翻訳が遅いからではなく、どこから読むか毎回考えているからです。
- 読む順序を「ラベル ➔ 最後のコメント ➔ 再現手順 ➔ 差分」に固定すると、翻訳の回数そのものが減ります。
- Mac専用OCR翻訳『Zipp』は
⌃Sで囲んで 0.3秒、Apple Visionによる端末内処理で画面画像の外部保存ゼロ。無料でダウンロード（登録不要）、1日15回までです。
📌 この記事の対象読者
- Issueを開くたびに、上から順に読むべきか結論から読むべきか迷う方
- 1件のIssueに10分以上かかり、調査の初動がいつも遅れてしまう方
- 翻訳ツールは入れたものの、読む順番が決まらず結局使わなくなったエンジニア
最速にならないのは、翻訳の速度ではなく順序が決まっていないから
Issueを読むのが遅い原因を、多くの人は翻訳の速度だと考えます。だから速いツールを探し、ショートカットを覚え、コピーを工夫します。しかし実際に時間を測ってみると、速いツールを入れても劇的には変わりません。時間を使っているのは翻訳そのものではなく、読む前に「どこから見ようか」と考えている時間だからです。
Issueのページには、情報が層になって積まれています。タイトル、ラベル、マイルストーン、本文、コメント群、リンクされたPR、CIのチェック結果、関連Issue。どれも読もうとすれば読めます。読めるからこそ、順番を決めていないと、目に入った順に読んでしまいます。上から下へ流し読みし、途中で分からない単語が出て翻訳し、また戻る。この往復が積み重なって、1件に10分かかります。
さらに悪いことに、上から順に読む方法は結論が最後に来る構造と相性が悪いものです。長いIssueでは、解決策が最後のコメントに書かれていることがよくあります。上から読むと、すでに古くなった仮説や、後から否定された原因を、正しい情報として先に処理してしまいます。読んだ量は多いのに、判断に使える情報は少ない。これが「読むのが遅い」の正体です。
つまり最速化の対象は、翻訳のレイテンシではなく読む順序の設計です。順序が固定されていれば、翻訳する回数も、囲む範囲も、自動的に決まります。逆に順序が決まっていなければ、どんなに速い道具を入れても、迷う時間は残ります。速さは道具ではなく手順から出る、というのがこの記事の前提です。
解決策：読む順序を固定し、翻訳を4回に収める3手順
手順1：順序を先に決めて、Issueを開く前に宣言する
Issueを開く前に、読む順序を決めます。おすすめは次の4段階です。
- 第1段階：タイトルとラベル（30秒）… 何の種類のIssueか、開いているか閉じているか、
bugかenhancementかquestionかを見る。 - 第2段階：最後のコメント（1分）… 結論がここにあることが多い。メンテナの最終判断、回避策、修正コミットへのリンク。
- 第3段階：本文の再現手順（2分）… 何をしたら何が起きるか。番号付きの手順とコードブロックだけを読む。
- 第4段階：リンクされた差分（2分）… 修正が入っているなら、そのdiffだけを見る。
この順序の利点は、早期に「読まなくていいIssue」を判定できることです。第1段階で question かつクローズ済み、最後のコメントに答えがある、と分かれば、本文を読む必要はありません。30秒で1件が終わります。全部を同じ丁寧さで読むのをやめるだけで、1日の読解量は何倍にもなります。
手順2：段階ごとに1回だけ囲む
各段階で、翻訳は1回だけにします。⌃S（Control + S） を押し、その段階で必要な範囲をドラッグして囲みます。0.3秒 で訳が最前面に表示され、原文は隠れません。
- 第1段階では、タイトルとラベルの行を囲む。ラベルの英語（
needs reproduction、good first issue、stale）は、意味が分かれば以後は訳す必要がありません。 - 第2段階では、最後のコメントの末尾3〜4行だけを囲む。結論は末尾に来るからです。
- 第3段階では、番号付き手順のブロックを囲む。
- 第4段階では、diffの追加行と削除行のうち、コメントが付いている行を囲む。
ポイントは、段階を飛ばしたら翻訳もしないことです。読まないと決めた部分を訳すのは、純粋な無駄になります。囲む回数を減らすことが、そのまま速さになります。
手順3：4回で足りないときだけ戻る
4段階を終えても判断できないときだけ、戻ります。戻り先は本文の「期待する動作」と「実際の動作」のブロックです。ここに書かれている差分が、Issueの本質だからです。
この「戻る」を3回までに制限します。4回戻るようなIssueは、読解では解決しません。メンテナに質問する、関連Issueを探す、自分で再現する。読む以外の手を打つべき合図です。読解の打ち切り基準を持っていることが、結果として最速になります。無限に読めるから無限に読んでしまう、という状態を防ぐのが、順序を固定する本当の目的です。
Issueの読み方を比べる
【読む順序】
従来：画面の上から下へ、目に入った順
Zipp：ラベル ➔ 最後のコメント ➔ 再現手順 ➔ 差分に固定
【翻訳の回数】
従来：分からないたびに何度でも
Zipp：段階ごとに1回、計4回が上限
【結論への到達】
従来：末尾まで読んでから
Zipp：第2段階で先に掴める
【読まない判断】
従来：全部読んでから決める
Zipp：第1段階で30秒で決められる
【原文の可視性】
従来：別画面へ移動し、原文が見えない
Zipp：訳が重なるだけで原文は隠れない
【試しやすさ】
従来：用途ごとに契約と設定の確認が必要
Zipp：無料でダウンロード（登録不要）／1日15回まで
よくある質問（FAQ）
Q. 結論が最後のコメントにあるとは限らないのでは？ A. 限りません。だから第1段階でラベルを見て、open かつ活発に更新されているIssueは、最後のコメントを先に読む価値が高いと判断します。外れた場合は第3段階で本文に戻るだけです。順序は固定しても、戻る経路は残しておくのが実務的です。
Q. 速く読むと、大事な情報を見落としませんか？ A. 見落とす可能性はあります。ただし上から全部読む方法でも、長いIssueでは後半の集中力が落ちて見落としが起きます。順序を固定すると、どこを読んでいないかが自分で分かるのが利点です。「第4段階の差分は見ていない」と把握できていれば、必要になったときに戻れます。
Q. 英語のラベルが読めないまま進めて大丈夫ですか？ A. ラベルは種類が限られているので、最初の数件でまとめて訳しておくと以後は不要になります。本文を読みながら毎回ラベルに戻るより、ラベルだけを先に片付けるほうが総量は減ります。
Q. 1日15回で、Issueを何件読めますか？ A. 段階を飛ばす判断ができれば、1件2〜3回で済むこともあります。逆に全部を丁寧に訳すと1件で10回以上かかります。回数の上限は、順序を守る動機づけになります。まず今日のIssueを1件、4段階で読んでみてください。
速さは、読む前に決まっている
Issueを読むのが遅いのは、英語が読めないからでも、翻訳が遅いからでもありません。どこから読むかが決まっていないからです。ラベルで種類を見て、最後のコメントで結論を掴み、再現手順で差分を確認し、必要なら差分を見る。この4段階と、段階ごとに1回だけ囲むという制約を持つだけで、同じIssueが数分で読めます。
順序を決めるのは、今日の5分でできます。次のIssueを開く前に、4段階を頭に置いてから ⌃S を押してみてください。読む量を減らしたのに判断が速くなった、という感覚が、最速への近道です。
▼ 無料でダウンロード（登録不要・1日15回まで）
zipp-mac.surge.sh