第 5 章：「読む力」はこうして育つ

公開日: 2025-06-21著者: Yov in YovStudio

良いコードに触れよう

「どうすれば読む力が育つのか？」というのは、多くの人にとって気になるテーマだと思います。私自身、誰かに教えてもらって育てたというよりは、いろんなコードを読んだり、自分で書いて失敗したりしながら、少しずつ育ってきたように思います。その中でも「良いコードに出会うこと」がすごく大きかった。これは間違いなく言えます。

良いコードに触れることで、「あ、こう書けばいいのか」といった具合に、自然と「読む視点」や「書き方の引き出し」が増えていきます。今回は、そんな「読む力の育ち方」について、「良いコードとは何か」を考えながら、私自身の考えも交えて話してみます。

読みやすいコード vs 読みにくいコード比較

たとえば、こんなコードを読んだとき、どちらがスッと頭に入ってくるでしょう？

読みにくいコード（一例）

if (dst !== null && dst > 0 && !fin) {
  const adj = calc(dst, fin, true);
  if (adj !== null) ttl = adj;
}

読みやすいコード（一例）

if (distance === null || distance <= 0 || isFinished) return;

const adjusted = calculateAdjustedDistance(distance);
if (adjusted !== null) {
  total = adjusted;
}

実はこの２つ、処理の内容はざっくり同じですが、変数名・処理の分け方・否定の使い方など、書き方がだいぶ違います。同じ処理をしているのに書き方が違うだけで印象が大きく異なりませんか？

「読みにくいコード」の方の気になる点はいくつかありますが、特に私が気になるのは、変数名や関数名が短縮されていて意図が読み取りづらい点です。
このコードは「dstってどんな変数だ？」「calc()は名前的に何か計算してそうだけど、何を計算している？」「finはおそらく“finished（完了した）”の略かな？ !がついているってことは否定だから“完了してない場合”ってことか」といったように、イチイチ推測しながら読み進めないといけません。 calc()の中身まで見ないとコードの意図が正確に分からず、「読むこと」にエネルギーを使います。

それに比べ「読みやすいコード」の方は変数名や関数名が明確になっていて、頭の中で自然に読むことができます。 distance(距離)、adjusted(調整された)、total(合計)といった単語が明快になっただけで、「なるほど、距離を調整して合計する処理なのね」と予測がつきます。 calculateAdjustedDistance(distance)も、その関数名から距離の調整値を計算していることが分かります。こうしたコードは、余計なエネルギーを使わずに読むことができます。

このような「エネルギーを使わずに読めるコード」を、私は「良いコード」だと考えています。

加えて、「読みにくさ」はしばしばバグの温床にもなります。コードの意図がわかりにくいと、読むことにエネルギーを多く使う上、修正するときにミスしたり、動作を誤解したまま扱ってしまう危険もあります。だからこそ、「読む力」を育てるには、「読みやすい書き方に触れる」ことが大切なんです。

大切なのは短縮しないことではなく、意図が正確に伝わること

あたかも短縮しないことが正義かのように聞こえたかもしれませんが、それは私の本意ではありません。「短くまとまった書き方のほうがスッキリしていて好みだ」という人だって大勢いますし、変数名や関数名が簡略化されていても、そのコードの中で何をしているのかがはっきり分かるようになっていれば、むしろスッキリしているから読みやすいなんてこともあります。

たとえばチームの中で慣れ親しんだ表記ルールがあったり、for 文でよく使う変数”i”みたいな、その書き方が一般的なケースなら、読み手に意図が伝わりやすいので短縮するのも有効です。

重要なのは意図が正確に伝わるかどうかなんです。

良いコードの紹介

ここでは、私が「これは読みやすい！」と感じたコードを紹介します。いずれも、意図が自然に伝わる書き方がされています。

例 1：英文を読む感覚に近いコード

if (user.hasPermission('edit') && file.isLocked()) {
  file.unlock();
}

こういうコードはまさに、英文のように自然に読めます。「もしユーザーが編集権限を持っていて、ファイルがロックされていれば、ロックを解除する」── 頭の中で音読しても意味が通る。こういう書き方が、私の中では理想です。

もちろん、現実の業務コードはもっと複雑だったり、制約があったりもします。でも、こういう理想に触れておくと、「あのコードに近づけるにはどう書こう？」と考えるきっかけになります。

例 2：処理の意図と流れが読みやすいコード

function processOrder(order) {
  if (!order.isPaid || order.isCancelled) return;

  const receipt = generateReceipt(order);
  sendEmailToCustomer(order.customerEmail, receipt);
}

関数名processOrderから「注文を処理する」という目的が明確で、条件チェックも直感的。その後の処理も自然な流れで、「支払い済みかつキャンセルされていない注文のレシートを生成し、メール送信する」という意図がはっきりと読み取れます。

英語が得意じゃないとダメ？

「ここまでで何度か“英文を読むように”という表現が出てきたけど、もしかして英語が得意じゃなきゃダメ？」と思われた方もいるかもしれません。

でも、英語が得意かどうかはあまり関係がありません。単語が多少たどたどしくても、「何をしようとしているか」が自然に伝わる書き方 ── それが「読みやすさ」の本質だと思います。

それに、よく使われる単語や表現はある程度決まっていて、いろいろなコードを読む中で少しずつ覚えていけます。ただし、分からないときに「どういう意味だろう」と関心を持って調べることはとても大切です。そうやって、「前にも見たな」「たしかこういう意味だったよな」と、だんだん自分の中に積み上がっていきます。

「読む力」を育てる習慣や視点

「読む力」って、すぐに身につくものではないと思います。でも、日々のちょっとした習慣の積み重ねで、確実に育っていくものでもあります。

私の場合、たとえば：

他人や AI が作成したコードに「おっ」と感じたらメモして残しておく
知らない単語・書き方に出会ったらその場で調べる
AI が提案してきたコードは学びの宝庫なので観察する

AI が書いたコードも、「知らない書き方だけど合理的」「意外と読みやすい」と感じることは多く、読みの引き出しを広げてくれています。

いろんなコードを読むうちに、「あ、この書き方はよく見るな」「この単語、他でも見たぞ」という感覚が積み重なっていきます。そしてそれが、未知のコードにも自然と見当がつく「読む力」に変わっていくのです。

まとめ

「読む力」を育てるには、まず「読むことに慣れる」ことが第一歩です。
そして、良いコードに出会って「こういう風に書くと読みやすいんだな」と気づくことで、視点が増えていきます。

次章では、この「読む力」が実際の現場でどう活きるのか ──「実務で活きる“読む”」をテーマに話していきます。

article 第 5 章：「読む力」はこうして育つ