バックエンドエンジニアを目指すなら、しっかりとした基礎を築くことが重要です。 バックエンドはシステムの中核を担い、データ管理、業務ロジックの実装、サーバーの運用など、幅広いスキルが求められます。こうしたスキルを効果的に習得するためには、体系的に学べる環境で学習を進めることが重要です。 私が開発したバックエンドエンジニア向けの学習ロードマップでは、まずプログラミングの基本概念やデータ構造を理解し、配列やハッシュマップ、ノード、オブジェクトといった日常的に使うデータ構造に慣れることから始めます。その後、ソフトウェア設計やオブジェクト指向プログラミング、データベースの基礎を学び、より高度な開発に対応できる知識を身につけていきます。 さらに、Linux環境でのシステムプログラミング、サーバーサイド開発、デプロイ、ネットワーク管理など、実践的なスキルを習得しながら、バックエンドエンジニアとしての専門性を深めていきます。 Recursionの学習ロードマップでは、「20%のインプット、80%のアウトプット」という学習スタイルを採用しており、実際に手を動かしながら知識を定着させることができます。加えて、チーム開発の機会やイベントも充実しており、実際のプロジェクトを通じてスキルを磨くことが可能です。 特に、最終的には自分自身でバックエンドフレームワークを構築するプロジェクトに取り組みます。これにより、単なる技術習得にとどまらず、ソフトウェアの設計や問題解決能力を実践的に鍛えることができます。 このような段階的な学習プロセスを通じて、バックエンド開発の実務に直結するスキルを身につけ、より実践的な経験を積みながら成長できる環境を提供します。バックエンドエンジニアとして確かなスキルを身につけるために、体系的な学習環境を活用し、実際の開発に挑戦していきましょう。

今週末開催です！興味のある方はぜひ参加ください！

【28卒/29卒の海外大生向け】 海外大から日本企業のエンジニア職を目指す学生向けに、オンラインイベントを開催します！ 登壇するのは、海外大でCSやセキュリティ等を学び、AWS、kubell、ログラス、メドレー、デロイトなどから内定を獲得した学生たちです。 海外大生だからこそ話せる、 ・日本就活の情報収集と始め方 ・選考スケジュールと対策 ・技術学習や個人開発の進め方 ・なぜ海外ではなく日本就職を選んだか ・やってよかったこと、早く知りたかったこと などを実体験ベースで聞いていきます。 日本でのエンジニア就職を考えている海外大生の方はぜひご参加ください！少人数で質疑応答するのがメインのイベントになってます。 ▼詳細・お申し込みはこちら recursion.connpass.com/event… 周りに日本でのエンジニア就活を考えている海外大生の友人や後輩がいれば、ぜひ共有していただけると嬉しいです！

LLMによって発見されるバグやセキュリティ上の脆弱性が急増する中で、オープンソースのメンテナーの負担がさらに大きくならないことを願っています。 AIの進歩によって、脆弱性レポートはメンテナーが対応できる速度を上回る勢いで生成されるようになってきています。 もちろん、脆弱性が早く見つかること自体は良いことです。しかし、その一方で、報告を確認し、再現し、修正し、リリースする作業は、最終的には人が担わなければなりません。 OSSは多くのソフトウェアを支える重要な基盤です。だからこそ、メンテナーが無理なく活動を続けられる環境をどう作っていくかは、今後ますます重要な課題になっていくのではないかと感じます。

もし「自分はコンピューターより頭が悪い」と感じることがあったら、人間の脳がいかに効率的な仕組みなのかを思い出してみてください。 人間の脳は、フル稼働していても消費電力は約15〜20ワット程度と言われています。 一方で、現在のスーパーコンピューターで脳全体の働きを再現しようとすると、桁違いの電力が必要になると考えられています。

「信頼を築く力」は、過小評価されがちですが、エンジニアとして長く活躍するうえで非常に重要なスキルだと思います。 エンジニアとして成長し、より大きな仕事や責任を任されるようになるかどうかは、技術力だけで決まるわけではありません。 むしろ、「この人なら安心して任せられる」という信頼が大きな要素になります。 そのためには、約束した成果を継続的に出すこと、チームメンバーと協力して仕事を進めること、そして日頃から良好なコミュニケーションを築くことが大切です。 こうした積み重ねが、「この人に任せたい」という評価につながり、より大きな責任やチャンスを得るきっかけになるのではないかと思います。

気分よく開発を続けたいのであれば、技術的負債はできるだけ少ない状態を維持することが大切だと思います。 技術的負債が積み重なっていくと、開発の楽しさは少しずつ失われていきます。 例えば、思わぬバグが原因でリリースが遅れ、スケジュールの遅延を説明しなければならなくなったり、誰も把握していないドキュメントのないモジュールの調査に、想像以上の時間を費やしたりすることがあります。 また、「デプロイしたら何か壊れるのではないか」という不安を抱えるようになることもあります。十分なテストや監視、メトリクスが整備されていなければ、「大丈夫だ」と安心してリリースすることは難しくなります。 さらに、本来は変更したいファイルがあっても、あまりにも多くの箇所から参照されていて、影響範囲が読めず手を付けるのが怖くなることもあります。 企業が技術的負債を健全なレベルに保てなくなると、仕事は苦痛に変わってしまいます。

AIエージェントが本番環境でも誰でも手軽に使えるようになったとき、法的な問題やバグ、セキュリティ上の脆弱性がどの程度増えるのかは気になるところです。 プロトタイプの作成や試作段階でAIエージェントにある程度の判断を任せることは、有効な場面も多いでしょう。一方で、実際のユーザーが利用するシステムでは、人による確認やレビューが欠かせません。 もし誰も内容を確認せずにAIへ判断を委ねてしまうと、責任をAIに任せたつもりでも、その結果生じる責任までなくなるわけではありません。 AIは強力なツールですが、本番環境では最終的な判断と責任を人が担うことの重要性は、今後も変わらないと感じています。

企業の中には、AIを主にコスト削減の手段として活用しているところもあります。 特に、Meta や Google のようにソフトウェアそのものが事業の中核である企業を除くと、ソフトウェアエンジニアは「利益を直接生み出す部門」ではなく、事業を支えるためのコスト部門として位置付けられることも少なくありません。 そのため、開発には一定の予算が割り当てられる一方で、人員の増強や開発ツールへの投資、開発体験を改善するための取り組みなどは、優先順位が下がりやすい傾向があります。 その結果、技術的負債が積み重なり、保守しづらいコードベースになってしまうこともあります。 こうした環境では、企業側はAIによる開発効率化やコスト削減を期待し、開発者側もAIを活用して負担の大きいコードベースと向き合う時間を減らしたいと考えることがあります。 AIに対する期待は同じでも、企業と開発者では、その背景や目的が少し異なるのかもしれません。

オープンソースの世界で残念だと感じることのひとつは、多くの企業が「無料なのに、常に安全で最新の状態であること」を当然のように期待してしまうことです。 不具合のあるアップデートや、脆弱性が修正されないまま放置された場合、その企業が被る損害は非常に大きくなる可能性があります。それにもかかわらず、OSSのメンテナーには「できるだけ早く、しかも無償で対応してほしい」と期待されることが少なくありません。 一方で、メンテナーが開発や保守に対して正当な対価を求めると、「高すぎる」と受け取られてしまうこともあります。 OSSは多くの企業にとって重要な基盤となっていますが、その持続可能性を支えるためには、メンテナーへの適切な支援や対価についても考えていく必要があると感じます。

【28卒/29卒向け】 エンジニア志望の学生向けにオンラインイベントを開催します！テーマは「本選考で後悔しないために今やるべきこと」です。 登壇するのは、27卒としてDeNA、freee、サイバーエージェント、PKSHA Technology、Goなど、メガベンチャー・IT企業から内定を獲得した学生です。 本選考を終えたからこそ話せる、 ・本当にやってよかったこと ・意外とやらなくてもよかったこと ・サマーインターンを本選考につなげる方法 ・個人開発、技術学習の進め方 ・今28卒に戻ったらまず何をするか などを聞いていきます。 28卒/29卒でエンジニア就職を目指している方はぜひご参加ください。 また、周りにエンジニア就活を進めている友人や後輩がいれば、ぜひこのイベントを共有していただけると嬉しいです。 recursion.connpass.com/event…

最近よく耳にするようになったのが 「プラットフォームエンジニアリング（Platform Engineering）」 です。 個人的には、これはDevOpsが登場した頃の考え方に少し似ているように感じます。もともとDevOpsは、開発者自身がデプロイや運用をもっと効率化するために、ツールやプロセスを整備していた流れから生まれました。 しかし、その後CI/CD、自動化ツール、クラウドサービス、設定ファイル、スクリプト、YAMLなどが増え続けた結果、今度はそれらの仕組みを構築・維持すること自体が専門的な仕事になっていきました。 そして現在は、開発者がインフラやデプロイ周りで苦労しなくて済むように、共通の基盤や開発者向けプラットフォームを整備する役割として、プラットフォームエンジニアリングが注目を集めています。 もちろん、こうした役割には実際に大きな価値があります。一方で、流行りのキーワードとして使われているケースもあるため、求人票などを見るときは注意が必要かもしれません。 場合によっては、プラットフォームエンジニアリングと書かれていても、実態としては「アプリケーション以外のことは全部担当してください。インフラも運用も頑張ってください」という意味で使われていることもあるかもしれません。 そのため、肩書きだけで判断するのではなく、実際に何を担当するのか、どこまでの責任範囲なのかを確認することが大切だと思います。

昔のゲームがどれほど通信量を節約していたのかを見ると、本当に面白いです。 例えばRuneScapeが登場した当時、多くのユーザーは56kbpsのダイヤルアップ回線を使っていました。そのため、通信プロトコルは極限まで効率化されていました。 特に興味深いのが、「周囲のプレイヤーが何をしたか」を通知するネットワークメッセージが、わずか9バイトしかなかったという点です。 比較として、現在のWebサイトで「軽量に最適化されている」と言われる30KB程度のWikiページ1枚でも、RuneScapeの通信量に換算すると約3,000回分以上の周辺状況更新に相当します。 こうした話を見ると、当時の開発者たちが限られた帯域の中でいかに効率的なプロトコル設計を行っていたかがよく分かります。

これまで長い間、インターネット全体のトラフィックはおおむね 「ボット30％、人間70％」 という比率で推移していました。 ところが最近、その状況に大きな変化が見られています。この3か月だけでボットによるトラフィックが急増し、30％から38％へと上昇しました。一方で、人間によるトラフィックは70％から62％まで低下しています。 特に興味深いのは、この変化が何年も続いていた傾向を短期間で覆したことです。AIエージェントや自動化ツールの普及に伴い、インターネット上で活動する「人間以外」の割合が急速に増えていることを示しているのかもしれません。 そして、この増加傾向は今も続いているようです。今後は、Webサービスやインフラを設計する際にも、「利用者のかなりの割合がボットである」ことを前提に考える必要が出てくるかもしれません。

UCバークレーのようなトップクラスのコンピュータサイエンス教育機関であっても、AIの使い方に関する課題が出てきているようです。 特に話題になっているのが、CS10（コンピュータサイエンス入門科目）です。この授業は、プログラミング未経験者も対象とした基礎科目で、コンピュータサイエンスの考え方や問題解決の基礎を学ぶためのコースです。 一部では、自分で考えて学習する代わりにAIへ過度に依存してしまう学生が増えていることが指摘されており、その結果として成績にも影響が出ていると言われています。 BerkeleyTimeのデータによると、CS10の不合格率は現在約35%に達している一方で、2024年やその前年までは10%を超えることはほとんどなかったそうです。 もちろん成績の変化にはさまざまな要因が考えられますが、この事例は、AIを活用することと、自分自身で理解しながら学ぶことのバランスの重要性を改めて考えさせるものかもしれません。

大企業では、「変数名を変更するだけなのに3か月もかかる」という冗談を聞くことがあります。とはいえ、変数名を変えるだけでも数日かかることは十分にあり得ます。 コードの修正自体は数分で終わるかもしれません。しかし実際には、影響範囲の調査、テストの実行、コードレビュー、CI/CD、ステージング環境での確認、本番リリースの手続きなど、多くのプロセスが伴います。 大規模なシステムほど、「コードを書く時間」よりも「安全に変更を反映する時間」の方が長くなることは珍しくありません。だからこそ、一見すると単純な変更でも、想像以上の時間がかかることがあるのです。

SQLの息の長さには本当に驚かされます。 一度しっかり学んでしまえば、何十年にもわたって活かせるスキルのひとつだと思います。 これまで数多くのNoSQLデータベースが登場してきましたが、それでもSQLは衰えるどころか、今なお多くのシステムで中心的な役割を担い続けています。 もちろん用途によってはNoSQLが適しているケースもありますが、データを扱う基礎的な考え方やクエリの知識として、SQLは非常に汎用性が高く、長く価値を持ち続ける技術だと感じます。

会社選びをするときに私が重視していることの1つは、業務の中で新しい技術や技術スタックを学ぶ機会があるかどうかです。 もちろん、すべての会社や職種で実現できるわけではありませんが、個人的には業務時間の一部を学習や新しい挑戦に使える環境は魅力的だと感じています。実際の業務の中で新しい技術に触れられると、学習と実践を結び付けやすいからです。 また、しっかりとした基礎力があれば、ほとんどの技術スタックは互いに近い領域にあります。つまり、新しい技術に出会っても、共通する考え方や経験を活かしながら学び、必要に応じてキャッチアップしていくことが可能です。 成長できる環境は、給与や福利厚生と同じくらい重要な要素だと思います。長期的なキャリアを考えるのであれば、今の仕事だけでなく、将来の成長につながる経験を積めるかどうかも意識しておきたいところです。