プログラマの道

1. キャリアのはしご

プログラマにも、スキルレベルに応じた区分があります。かつては「コーダー」「プログラマ」「ハッカー」といった呼び方が使われていましたが、 今ではアメリカのIT業界に由来する英語名にすべて置き換わっています。

開発者には、主に6つの段階があります。

• Intern Software Engineer
• Junior Software Engineer
• Middle Software Engineer
• Senior Software Engineer
• TechLead
• Principal Software Engineer

国や会社によって多少の違いはありますが、だいたいのイメージは次のとおりです。

🌱 Intern Software Engineer — インターンです。プログラミングを学んでいる途中で、 商用経験がないか、大規模プロジェクトへの参加経験がありません。通常は、より経験豊富な同僚の監督のもとで働きます。 主な仕事は、コードベースとソフトウェア開発の基礎を学び、簡単なコーディング作業をこなし、テストにも参加することです。

🐣 Junior Software Engineer — すでにプログラマではありますが、本格的な商用経験はまだないか、 経験が1年未満です。より経験豊富な開発者の指導のもとで働き、プロジェクトの一部を実装したり、 コードレビューのサイクルに参加したりします。この段階では、技術スキルの向上とプロジェクト課題の理解に重点が置かれます。

🦾 Middle Software Engineer（または単に Software Engineer）は、技術的な判断においてより自律的で、 プロジェクトの重要な部分を担当し、経験の浅い同僚のメンタリングを始め、アーキテクチャの議論にもより積極的に参加します。 通常、2〜5年の実務経験があります。

🧑‍🔬 Senior Software Engineer: 複雑なシステムの設計と実装を担当し、チーム内でのメンタリングとリーダーシップを担い、 プロジェクトの戦略立案に参加し、顧客やその他の関係者とのやり取りでチームを代表することも多いです。 通常、5〜10年の経験があります。

🧠 TechLead: プロジェクトの最終的な技術成果に責任を持ち、開発をリードし、最も難しい課題を解決し、 技術標準の遵守を徹底し、開発者の活動を調整します。

🏆 Principal Software Engineer: 最も高い技術レベルで働き、会社の技術戦略の策定、革新的なソリューションの開発、 技術標準の確立に関わることが多く、技術リーダーのための主要なメンターであり、複雑な技術課題における重要な専門家でもあります。

興味深いポイント。大企業では、追加の役割やサブロールがあることもあります。たとえば、Google には次のような役割があります。

• Staff Software Engineer (L6): 自分の部門の技術方針に大きな影響を与えます。
• Senior Staff Software Engineer (L7): 大規模で複雑なプロジェクトに取り組み、会社の技術発展の戦略的方向性を定めます。

2. Lego製品

ずっと昔（1975年）、Pascal言語の生みの親であるニクラウス・ヴィルトは、『Algorithms + Data Structures = Programs』という本を書きました。 それ以来、多くのことが変わりました。現代のソフトウェア製品は、10年前のものとは違いますし、20年前のものとはなおさら違います。 1975年については言うまでもありません。あれから50年が経ちました ⏳

現代のプログラマは、もはやプログラムを手作業で書きません。むしろ、既製の部品（ライブラリ）を組み合わせ、 それらが連携するのを助けるコードを書くのです🧩。現代のソフトウェア製品は、数十から数百ものプログラムで構成されることがあります。 そのうちのいくつかはユーザーのコンピュータやモバイルデバイスで動作し、残りの大部分はデータセンター内のサーバー上で動作します。

Webサーバーやデータベースのようなプログラムの多くは、すでに作られています。あとは正しく設定するだけで、 期待どおりに動作します。もっとも、時間がたつにつれて設定作業が非常に複雑になり、実質的には開発と同じようなものになることもあります。🤦‍♂️

プログラマは、いつも自分たちと戦っています。毎回似たようなコードを別々のプログラムで書き直す代わりに、 それぞれの用途に合わせて設定できるライブラリを作り、必要な場所すべてにそれを接続するのです。

この20年で、プログラマによって非常に多くのライブラリ、フレームワーク、オープンリポジトリが作られました。 その数は本当に数百万にのぼります。いまでは、すべてのコードをゼロから書くのは悪い作法とみなされています。 その代わり、ライブラリ、フレームワーク、パッケージ、モジュールといった高品質で検証済みの解決策を組み合わせてプログラムを作る必要があります 🧱

しかし、このアプローチもすでに古くなりつつあります。ここ10年の傾向はクラウドへの移行です。 大規模なデータセンターが、必要なものをすべてプログラムに提供してくれます。データベースが欲しいですか？ 選べるものは何百とあります。 ちょっと珍しいWebサーバーが欲しいですか？ そんなものもあります。要するに、あとはお金次第です。

3. 「私はエンジニアだ」 © イーロン・マスク

もう、難しくて退屈なものを自分で書く必要はありません。何か機能が必要なら、そのための既製のライブラリやフレームワークがあります。 やるべきことは、a) その存在を知ること、b) 適切な選択肢を見つけること（同等のものが複数あり、品質や細部に違いがあることが多い）、 c) それを自分のプロジェクトにどう統合するかを理解することです 🎓

その結果、仕事はむしろ面白くなりました。今では、新しい機能を製品に10倍速く追加できます。30年前なら、Webサーバーが必要なら 自分でゼロから書いていました。20年前なら、購入して、インストールして、設定していました。今では、Azure や AWS のクラウドポータルに入って、 必要なサービスを有効にするだけです 🌐

ちなみに、これが Go 言語の人気の理由の1つです。高負荷な backend、microservices、クラウドインフラストラクチャの開発に最適です。シンプルな構文、goroutines による組み込みの並行処理、および高速なコンパイルにより、現代の backend 開発者にとって主要なツールの1つとなっています。Docker、Kubernetes、Terraform が Go で書かれているのは偶然ではありません。

したがって、Go Software Engineer という職業も、時間が経つにつれてますます幅広い stack をカバーするようになっています。現代の開発者にとって、相互作用を適切に構築するためには、データベース（PostgreSQL、MySQL/MariaDB、MongoDB など）がどのように機能するかを理解することが重要です。frontend の動作の基本原則（HTML、CSS、JavaScript/TypeScript、React、Angular）を理解する必要があります。そしてもちろん、今や Docker なしでは何もできません。それはすでに業界の標準です 🐳。

現代の開発は、20年前とはまったく違います。プログラマがコードを書く時間は全体の50%以下で、残りはドキュメントを読むこと、 新しい技術を学ぶこと、設計すること、そしてミーティングでチームとして働くことに費やされます。ひとりで黙々と開発するプログラマは、 もはやかなり珍しい例外です。