【脱・コピペ】新人エンジニアの壁「抽象化」を攻略する！日常でできる脳内トレーニング法

2025年11月30日 2025年11月30日山崎講師

山崎講師

こんにちは。ゆうせいです。

プログラミングを学び始めて少し経つと、先輩エンジニアからこんなことを言われたりしませんか。

「もっと抽象化して考えないとダメだよ」

「このコード、汎用性がないね」

正直なところ、最初は意味がわかりませんよね。具体的に動くコードを書くだけでも精一杯なのに、抽象化なんて言われても雲をつかむような話に聞こえます。

しかし、この「抽象化」というスキルこそが、ただのプログラマーと、設計ができるエンジニアを分ける大きな壁なのです。

今日は、そんなエンジニア必須のスキルである「抽象化」について、難しい参考書を使わずに、日常のちょっとしたゲームで身につける方法をお伝えします。

そもそも「抽象化」とは何なのか

難しく考える必要はありません。抽象化とは、一言で言えば「枝葉を切り捨てて、本質的なルールだけを抜き出すこと」です。

RPGゲームを例に考えてみましょう。

「勇者がスライムに剣で攻撃する」

「魔法使いがドラゴンに杖で攻撃する」

これは具体的ですね。これをそのままプログラムに書くと、勇者用のコードと魔法使い用のコードを別々に書かなければなりません。

しかし、エンジニアの目には、これらは全く同じ処理に見えています。どういうことでしょうか。

攻撃者対象ダメージ計算

これだけです。「誰が」「誰に」「どうやって」という具体的な中身を捨ててしまうと、残るのは「AがBにアクションを起こす」という共通の構造だけになります。これが抽象化です。

数式で表すとわかりやすいでしょう。

具体的な計算式が次のようなものだとします。

勇者のダメージ $= 10 \times 2$

魔法使いのダメージ $= 5 \times 4$

これらを抽象化して、一つの計算式（関数）にまとめるとこうなります。

ダメージ基礎攻撃力倍率

具体的な数字（10や5）を、意味のある変数（基礎攻撃力）に置き換える。これができれば、キャラクターが100人増えても、このたった一つの式ですべて計算できるようになります。

ゲーム感覚で鍛える「アナロジー思考」

では、どうすればこの脳の使い方ができるようになるのでしょうか。

おすすめなのは、日常生活の中で目にしたものを、強引に「プログラミングの概念」や「全く別のもの」に例えるゲームです。これを「アナロジー（類推）思考」と呼びます。

やり方は簡単です。街中にあるものを見て、「これは〇〇と同じ仕組みだ！」と言い切るだけです。

いくつか例を出して一緒にやってみましょう。

例1：自動販売機は「関数」と同じ

自動販売機を見かけたとしましょう。そこですかさず心の中で呟きます。

「自動販売機って、プログラミングの関数（メソッド）と全く同じだよね」

そう言ったら、すぐに理由を考えます。

「だってお金とボタンという『引数（入力）』を渡すと、内部でガチャンと処理が走って、ジュースという『戻り値（出力）』が返ってくるからね。中身の機械がどう動いているか、外からは見えない『ブラックボックス』になっているところも、カプセル化されたクラスと同じだ」

どうでしょうか。自動販売機という具体的な物体から、「入力」「処理」「出力」という構造を抜き出せましたね。

例2：ファミレスのメニューは「クラス」と同じ

次はファミレスに入ったとします。メニュー表を見てみましょう。

「このメニュー表は、クラス（設計図）と同じだよね」

理由はこうです。

「メニューにはハンバーグの写真や値段が載っているけれど、これはまだ食べられない。つまり実体がない設計図の状態だ。注文して初めて、目の前にアツアツのハンバーグという『インスタンス（実体）』が生成される。クラスとインスタンスの関係そのものだね」

このように、全く関係ないように見える二つの事象から、共通する「構造」を見つけ出す練習を繰り返してください。これが、抽象化能力を劇的に高めます。

抽象化のメリットとデメリット

この力が身につくと、どんな良いことがあるのでしょうか。また、気をつけるべき点はあるのでしょうか。

メリット：変更に強い最強のコードになる

抽象化ができると、コードの重複がなくなります。

例えば、消費税率が変わったとしましょう。あちこちに $1.1$ と書いてある具体的なコードだと、すべて書き直さなければなりません。

しかし、 TaxRate という変数に抽象化してあれば、たった一箇所を直すだけで全ての計算が修正されます。

修正時間ほぼゼロ

これが最大の魅力です。

デメリット：やりすぎると誰も読めなくなる

ここが落とし穴です。なんでもかんでも抽象化すればいいというわけではありません。

あまりに抽象化しすぎて、「生物が物体に行動する」のようなプログラムを書いてしまうと、後から見た人が「これは攻撃なの？挨拶なの？」と理解できなくなってしまいます。

過度な抽象化は、可読性（読みやすさ）を下げてしまうのです。初心者のうちは、「3回同じようなコードを書いたら共通化する」くらいの感覚でいるのがちょうど良いでしょう。

今後の学習の指針

いかがでしたか。

「抽象化」という言葉に身構えず、まずは身の回りのものを「これって〇〇と同じ仕組みじゃないかな？」と疑ってみることから始めてみてください。

これからの学習としては、以下のステップをおすすめします。

身近な例え話を作る：今日紹介したゲームを、通勤中や散歩中に1日1回やってみてください。
コードのリファクタリング：過去に自分が書いたコードを見直し、「似ている処理」がないか探してみてください。
デザインパターンの学習：先人たちが考えた「よくある抽象化のパターン（シングルトンやファクトリーなど）」を学ぶと、一気に視野が広がります。

エンジニアとしての成長は、コードを書く量だけでなく、こうした「思考の深さ」で決まります。

ぜひ、今日から脳内トレーニングを始めてみてくださいね！

セイ・コンサルティング・グループの新人エンジニア研修のメニューへのリンク

投稿者プロフィール

山崎講師代表取締役

セイ・コンサルティング・グループ株式会社代表取締役。
岐阜県出身。
2000年創業、2004年会社設立。
IT企業向け人材育成研修歴業界歴20年以上。
すべての無駄を省いた費用対効果の高い「筋肉質」な研修を提供します！
この記事に間違い等ありましたらぜひお知らせください。