Jeffry Alvarado

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

動画のリンクはこちらです！ youtu.be/Y4O1P3APnYw

YouTubeに新しい動画をアップしました！ 興味のある方は、ぜひ見てみてください。

私は、プロジェクトにどれくらい時間がかかるかを見積もるとき、まず要件を整理し、それをできるだけ具体的な形に落とし込みます。そのうえでマイルストーンを設定し、各マイルストーンを複数の2週間スプリントに分けます。そして、それぞれのスプリントの中に個別のタスクを作っていきます。 こうしてタスクを細かく分けると、個々の作業については比較的正確に見積もりやすくなります。 過去に似た作業をした経験があれば、そのときの感覚や経験則を参考にします。もし完全に新しい内容であれば、過去に似た技術を学ぶのにどれくらい時間がかかったかを思い出し、それを目安にすることが多いです。一般的に、タスクが小さく、独立しているほど見積もりはしやすくなります。 ただ、実際に取り組んでみないと内容がはっきりしないタスクもあります。その場合は、最初の見積もりに少し余裕を持たせるようにしています。私の場合は、だいたい20〜50％ほど余裕を持たせることが多いです。 もちろん、見積もりはあくまで見積もりなので、必ずしも正確とは限りません。実際の開発では、予想していなかった問題やブロッカーが出てくることもよくあります。 また、見積もりの精度は経験にも大きく左右されます。まだ経験が少ない場合は、思っているより時間がかかる前提で考えておく方が安全だと思います。最初に思った時間のおよそ2倍くらいを見込んでおくと、あとで想定外の遅れに驚くことも少なくなります。

vibe codingの広がりで、2026年のテック業界は、まるでドラマ『シリコンバレー（Silicon Valley）』を見ているような展開になっています。

すぐにコードを書き始めるのではなく、まず「どのようなコードがこの問題を解決するのか」をしっかり考えることが大切です。 実際の開発では、ほとんどのタスクが最初に思っているよりも抽象的で複雑です。そのため、一度立ち止まり、取り組むべき課題をできるだけ具体的で明確な形に整理する時間が必要になります。そのうえで、考えられる解決方法について、それぞれのメリットやデメリットを検討していきます。 最初に思いついた解決策にそのまま飛びついてしまうと、それは単に「うまくいくことを期待して進めているだけ」になってしまうことも少なくありません。

長い時間をかけてコードベースを支えてきたエンジニアの努力が、あまり注目されないのは残念なことです。 本番環境で障害が発生したときに、パッチを作って問題を解決した開発者は大きく称賛されることがあります。しかし、そもそも本番環境にバグが入り込まないように、適切なテストや予防の仕組みを整えている開発者こそ、実はもっと評価されるべき存在かもしれません。 目立つのはトラブルを解決した瞬間ですが、本当に価値があるのは、トラブルが起きない仕組みを作っている仕事なのだと思います。

YouTubeに新しい動画をアップしました！ 今回は「2026年おすすめプログラミング言語」というテーマで、初心者から上級者までを対象に、私が注目している言語を紹介しています。 興味がある方は、ぜひご覧ください。

今日になって初めて知ったのですが、私たちが普段よく使っているsudoコマンドは、今でも頻繁にアップデートが続けられているそうです。 実はこのプロジェクトのコードベースはかなり大きく、複数ユーザーへの対応、権限管理、セキュリティポリシーの実装など、さまざまな機能を支えています。さらに、YubiKeyのような新しい認証方式への対応など、時代に合わせた機能追加も続いています。 ただ残念なことに、sudo のメンテナは現在Todd C. Miller氏ほぼ一人で、最近は多くのオープンソースプロジェクトと同じように、運営の難しさに直面しているそうです。本人の話によると、一人で維持するのは大変で、報告されたバグの対応に時間のほとんどを取られ、新しい機能の開発にまで手が回らないとのことです。 資金不足や燃え尽き、そして後継者がいないことも課題になっています。こうした状況は、決して楽なものではないはずです。

本ツイートで触れた「エンジニアの判断力」や「基礎力による直感」について、より実践的な視点から深掘りするため、株式会社kubell（旧Chatwork）CTOの田中さんとイベントを開催することになりました！ 興味のある方は、ぜひ以下のリンクから参加ボタンを押して頂けたらと思います！ recursion.connpass.com/event/384922/

経験豊富なエンジニアへの需要はますます高まっており、基礎力の重要性はこれまで以上に大きくなっています。 LLMは特定のタスクでは非常に優れた力を発揮しますが、多くの場合、過去に存在する解決策をもとに答えを導く仕組みです。人間のように、ゼロから新しい解決策を考え出すわけではありません。 その結果、開発の中で最後に残る20％の難しい部分は、人間のエンジニアが担うことになります。そこでは、判断力や直感、そして基礎力が大きく問われます。 たとえば、読みやすいコードとは何か、関数が最適化されているかどうか、バグの根本原因をどう見つけるか、アーキテクチャのトレードオフをどう判断するかといった力です。また、日々扱うデータ型、設計パターン、一般的な開発プラクティス、開発フローへの理解も重要になります。 さらに、メモリ、並行処理、計算量、レイテンシ、可用性といった概念は、どの分野でも繰り返し登場します。こうした基礎的な知識は、特定のライブラリやフレームワークとは違い、どの領域でも応用できるスキルです。バックエンドでも、ドライバ開発でも、インフラでも、ゲーム開発でも、たとえば「どこでキャッシュを使うべきか」といった判断は常に求められます。 基礎力は直感を育てます。 そしてその直感こそが、まだ誰も解いたことのない問題に対して、自分の力で解決策を見つける力につながります。これは、今のAIにはまだ再現できない部分です。

動画リンク： youtu.be/SMzLt19JzLM?si…

Recursionのバックエンドロードマップで特に良いと感じているのは、コンピュータサイエンスの基礎、ソフトウェア設計、そしてバックエンド全体へと、段階的に基礎を固めていける構成になっている点です。さらに、途中からは自分の力で実際に作りながら進めていくため、その過程で多くの発見や学びを得られるようになっています。 学習にはインプットとアウトプットのバランスが大切ですが、個人的にはインプット20％、アウトプット80％くらいの比率が理想だと思っています。まずは、言語やデータ構造、OOPのようなプログラミングパラダイム、新しいフレームワークなどを、個別のテーマとして学びます。 そのうえで、自分の手で実際に試してみることが重要です。たとえば、プロジェクトをゼロから作ってみること、開発環境を自分で構築すること、コマンドを使ってデータベースのテーブルを作成すること、ライブラリを組み合わせて使うこと、IDEでデバッグを行うこと、そしてどのように解決策を設計するかを考えること。こうした経験を積み重ねていくことで、実践的な力が自然と身についていきます。

【28卒エンジニア向け】 サマーインターン直前、 「企業理解を一気に進める場」を用意しました。 ・人気IT企業5社 × 少人数 ・現場エンジニアと直接会話 ・技術スタック / 開発体制 / インターンの実情まで聞ける 3/7・3/21（土）オンライン開催（無料）ですので、興味のある学生はぜひ参加ください！

最近の2026年の調査レポートによると、開発者の96％がAI生成コードを機能的に完全には信頼していないと回答しています。しかし一方で、AIを使って書かれたコードをコミット前に十分確認している人は50％未満にとどまっているそうです。 個人的には、AIのコードを無条件で信頼することはできません。ただ、企業の立場によっては、現在のAIブームの影響もあり、コード行数（LoC）といった分かりやすい指標を重視してしまう事情もあるのでしょう。 また、AI生成コードは同僚の書いたコード以上にレビューの手間がかかる場合もあり、その点で判断が難しくなるのも理解できなくはありません。

バランスの取れたエンジニアとして成長し、オーケストレーションに必要な基礎力を身につけたい人に向けて、Recursionでは、コンピュータサイエンスやソフトウェア設計に関するコースに加え、実際に手を動かしながら学べるアウトプット重視の演習も用意しています。 また、単にコードを書くことにとどまらず、チーム開発プロジェクトを通じて、設計やコミュニケーション、意思決定など、実務に近い経験を積める機会も提供しています。 学習内容の全体像については、バックエンド開発者になるためのロードマップに記載しています。 recursionist.io/dashboard/road…

これからの時代において、「オーケストレーション（全体を組み立て、指揮する力）」は最も重要なスキルのひとつになっていくと思います。 コンピュータサイエンスには「分割統治」という重要な考え方があります。大きな問題を小さなタスクに分解し、それぞれを解決してから統合することで、全体の問題を解くというアプローチです。 AI支援ツールを活用する前提であれば、問題を小さく切り分ける力が極めて重要になります。単純な関数、パイプライン内の1プロセス、個別のモジュール、マイクロサービス、APIエンドポイントなど、粒度の小さなタスクを適切に設計することが不可欠です。 こうしたタスクは、局所的で、理解しやすく、LLMが力を発揮しやすいだけでなく、テストやレビューがしやすいという利点もあります。 その結果、エンジニアは、AIでは解けない本当に難しい問題に集中できるようになります。一方で、比較的単純なタスクについては、LLMにある程度任せながら全体を調整・統括する役割を担うことになります。これが、これからの開発におけるオーケストレーションの本質です。 そのため今後は、アーキテクチャ設計やソフトウェア設計の経験がこれまで以上に重要になります。また、関心はコードそのものだけでなく、コード品質、ベストプラクティス、セキュリティ、保守性、そして企業のコンプライアンス要件といった領域にも広がっていくと思います。

今週末、28卒学生向けに交流会を実施するので、興味のある方はぜひ参加ください！ x.com/jalva_dev/stat…

一見すると意外ですが、vibe codingは、極端に大規模なコードベースではうまく機能する可能性があります。 その理由のひとつが、Stripeのような巨大なコードベースの存在です。Stripeでは300万件以上のテストが用意されており、本番環境にバグを出さないことを重視したCI/CDパイプラインが構築されています。これは、自動生成されたコードが正しいかどうかを検証するうえで非常に大きな武器になります。 また、コードベース自体も成熟しており、明確なコーディングガイドラインやポリシーが整備されています。テストを通過したコードであっても、最終的には経験豊富な開発者がレビューを行い、判断するという点も重要です。 個人的に興味深いのは、StripeのAI活用方針である 「2回失敗したら人間に戻す（fail twice, you’re out）」 という考え方です。最初か2回目で正しく動くのであれば、それはLLMが十分に扱えるタスクであり、プロンプトも明確だったという判断になります。一方で、それ以上うまくいかない場合は、開発者自身が対応すべきタスクとして切り替えます。これは、プロジェクト全体の中でも最も難しく、時間と労力を要する20％の部分に人が集中する、合理的な分担だと感じます。 ただし、技術的負債をどう管理していくのかについては少し不安も残ります。自動生成されたコードによって新機能が次々と追加されても、ドキュメントが整備されず、テストも書かれていなければ、将来的に大きな問題になりかねません。もっとも、Stripeの開発者たちは、まずは社内ツールや内部ライブラリといった低リスクな領域でコーディングエージェントを実運用しているはずで、その点は慎重に進められているのだろうとも思います。

Linuxの開発者であるリーナス・トーバルズ氏が、Linux 7.0を4月中旬から下旬にかけてリリースすることを認めました。 「バージョン7.0」と聞くと、何か劇的な変化がある大きな節目のように思えますが、実のところ、中身はこれまでの地道な更新と変わりありません。 実は、開発者のリーナス氏がバージョン番号の桁を上げる（例えば 6.19 から 7.0 にする）タイミングは、技術的な理由ではなく、指と足の指を使って数えきれなくなったからという彼なりのジョークに基づいた個人的な基準で決まります。今回も、これまでの慣例と同じように「数字が大きくなりすぎたから、キリよくリセットしよう」というだけの理由のようです。 つまり、本来なら「6.20」になるはずのところが、単に「7.0」という名前に変わるだけ、ということですね。