エンジニア未経験が現場4ヶ月目までに痛感した「抽象化」というスキルの大切さ

1. はじめに

皆さんは抽象化とは何かわかりますか？

グループ化？構造化？
一見わかりそうでわからないのが抽象化というワードですが、具体化の逆として考えてみてください。

抽象化とは一言でまとめると、複雑なものを本質的な構造に落とし込むことです。

例えば、「ユーザー登録」「商品購入」「レビュー投稿」という3つの具体的な処理を「ユーザーが行うアクション」という1つの概念にまとめること。これが抽象化です。

しかし、私はこれまで抽象化を意識しておらず、エンジニアとして未経験で転職してプロジェクトに参画してから苦労しました。

私は以前まで「エンジニアの仕事はコードを書くことだ」と思っていました。

しかし、実務の世界に入ったとき、その考えは大きな勘違いだったと気づきました。

実務の現場では、
コードを書くことより前に、考えること、整理すること、伝えることが求められていました。
特に私は、

エンジニアは"抽象化して考える力"と"コミュニケーション"が仕事の9割を占めているといっても過言ではない

という現実に直面しました。

抽象化ができないことで、私は多くのコミュニケーションエラーを起こし、何度も落ち込みました。

この記事では、私が感じたリアルなギャップと、複雑な開発現場で抽象化がなぜ必要なのかを体験をもとにお話ししたいと思います。

---

2. 実務に入って最初に感じた壁

現場に入った当初、私はこう思っていました。

• 「言われた通りの仕様を理解して、コードを書けばいい」
• 「技術力を上げれば問題は解決する」
• 「コードを書くスピードが早い人が優秀」

しかし、実際には全く違いました。

実務のプロジェクトに参加して最初に直面したのはコードを書く前に理解しなければいけない情報量の多さでした。

• APIの仕様
• データの流れ
• 設計思想
• チーム間で共有すべき前提
• どのレイヤーで何を扱うべきか

そして何より私を驚かせたのは、定例が毎日行われておりとても多くのコミュニケーションをしていることでした。

---

3. エンジニアは「ただコードを書く仕事」ではなかった

スクールでは黙々と手を動かす時間が多く、「エンジニアは一人で作業する職業」という印象がありました。しかし実務は真逆でした。

• 仕様確認の打ち合わせ
• やるべきことの優先順位調整

コードを書くより、言葉で整理して説明し、認識のすり合わせをする時間のほうが圧倒的に多いと気づきました。

そしてこのコミュニケーションの中心にあるのが抽象化でした。

抽象化ができないと、

• 説明が長くなる
• 会話がすれ違う
• 問題の本質に辿り着けない

という状態に陥ります。

私は最初の頃、問題の本質を捉えられず、報告や相談のたびに話が噛み合わず何度も落ち込みました。

しかし抽象化を意識し始めてから、コミュニケーションが劇的に変わりました。

---

4. 実務での抽象化の具体例

4-1. Repository / Service / Client の理解

私が特に苦労したのは、バックエンドのレイヤ分割でした。
Goを使った開発に参加し、次の3つの役割の違いが理解できず混乱しました。

• Repository
• Service
• Client

しかし一緒に参画していた先輩エンジニアがこう説明してくれました。

Repository: “どこに保存するか”の抽象
Service   : “何をしたいか”の抽象
Client    : “どう実現するか”の具体

この説明を聞いた瞬間世界が変わりました。

それまでは「ファイルがたくさんあって意味が分からない」という感覚でしたが、抽象化して捉えるとそれぞれが役割を持って存在していることが理解できました。

---

4-2. 例として：ユーザー登録のフロー

あるAPI連携が必要なユーザー登録機能を例にします。

要件はこうでした。

1. ユーザーが登録フォームを送信する
2. 外部APIにデータを送信する
3. 外部サービスで検証が行われる
4. 成功ならIDが返却され、システム側でユーザーを保存する

抽象化せずに考えると、

• どこでAPIを呼ぶのか
• どこでDBに保存するのか
• エラーはどこで処理するのか
• どのファイルを修正すべきか

全く分かりませんでした。

しかし、抽象化すると次のように整理できました。

Service：ユーザー登録という行為そのもの
Client ：外部APIに対してユーザー情報を送信する処理
Repository：ユーザーをDBに保存する処理

すると、どこを触るべきかが明確になりました。

抽象化は複雑な情報を扱える形に変換する強力なスキルでした。

---

5. 抽象化できていないことで起きたコミュニケーションエラー

抽象化ができないことで、実際にコミュニケーションエラーが発生することを経験しました。

具体例ばかり並べて、問題の本質が伝わらない

外部APIの仕様確認の際、具体的なエンドポイントやパラメータを全て説明しようとして「このエンドポイントでこのパラメータを送って、あのエンドポイントで...」と詳細を並べ立てました。しかし聞き手は「結局このAPIは何をするものなの？」と混乱し、APIの本質的な役割が伝わりませんでした。

共通点を見出せず、会話がすれ違う

複数の外部APIで似たような仕様があったとき、それぞれを個別の具体例として説明しました。しかし抽象化できず共通点を伝えられなかったため、「それは別のAPIの問題では？」と認識がずれ会話が噛み合いませんでした。

---

6. 抽象化を鍛える方法

仕様を1行で要約する

外部APIは必要な条件が揃っていないと次の処理に進ませません。

「共通点」を探す

まず「何をしたいのか」「どういう構造なのか」を理解します。
全体像を把握することが重要です。

実際に行っていた練習方法

私は日常的にニュース記事を読む習慣があるので、その時間を使って抽象化の練習をしました。

見出しを1行で要約する
長い記事を読んだ後、「結局何が起きたのか」を1行でまとめます。例えば、「〇〇企業が新サービスを開始、△△地域で展開」という記事を「〇〇企業が△△地域向けに新サービスを開始した」と要約します。

複数の記事から共通点を見つける
同じ日に複数の記事を読んだとき、共通する構造を探します。「A社が新規事業を発表」「B社が市場参入を表明」という2つの記事から「既存企業が新市場に参入している」という共通点を見出します。

記事の構造を捉える
「誰が、何を、なぜ、どうした」という構造で記事を整理します。細かい数字や固有名詞ではなく、構造で理解することで本質的な情報だけが残ります。

---

7. まとめ：抽象化は努力の方向を決める武器でした

抽象化を意識し始めてから、少しずつではありますが以下のような変化がありました。

• 仕様が整理できました
• 相談・報告が通じるようになりました
• 誤解が減りました
• 設計の意図が見えるようになりました
• 技術習得が速くなりました

そして気づきました。

エンジニアの仕事は、コードを書くことではなく、“問題を整理して解決すること”でした。

抽象化はその中心にありました。

これから実務を目指す人には、ぜひ最初に「抽象化」という視点を持ってほしいと思います。