Jeffry Alvarado

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

またいつもの水曜日みたいにGitHubがサーバーダウンしているだけかと軽い気持ちで開いたら、GitHub自身のソースコードが流出したという、想像以上に深刻な大事件だったので驚きました。

このテーマに興味がある方は、専門家の意見をまとめたFortuneの記事がとても参考になります。 fortune.com/2026/05/01/aut…

以前にも触れましたが、現在ではMassachusetts Institute of Technologyの研究者たちも、エントリーレベルの仕事をAIで置き換えすぎることへの懸念を示しています。 人材育成は、いわばパイプラインのようなものです。新しい世代が現場に入り、実務を通して経験を積み、少しずつ成長していくことで、将来的なシニアエンジニアやテックリードが育っていきます。もしその入口となる仕事が失われてしまえば、将来の人材基盤そのものが弱くなってしまう可能性があります。 また興味深いのは、AIを最も積極的にワークフローへ取り入れようとしているのは、新しい世代の開発者たちでもあるという点です。 そのため、エントリーレベルの仕事を過度に減らしてしまうと、結果として「育つ人材が減る」だけでなく、「AIを自然に活用できる人材も減る」という状況につながるかもしれません。

アプリを開発するときは、「アクティブユーザーのパラドックス」を意識することが大切です。 ユーザーは基本的に、まず自分のやりたい作業を早く終わらせたいと考えています。そのため、多くの場合、最初にドキュメントや操作説明を読む時間を省略しようとします。 しかし皮肉なことに、最初に少しだけ学習しておけば、長期的にはむしろ時間を節約できることも多いです。これがこのパラドックスです。 優れたアプリは、この前提を理解しています。そのため、ヘルプやガイドを「別の場所にある説明書」として扱うのではなく、プロダクト体験そのものの一部として、必要なタイミングで自然に使える形に組み込んでいます。

ソフトウェア開発の古典的な書籍であるThe Mythical Man-Month（日本語版タイトル：『人月の神話』）から学べる重要な考え方のひとつに、「Conceptual Integrity（概念的一貫性）」があります。 システムには、統一されたルールや設計思想があることが大切です。個別には優れたアイデアや機能であっても、関連性のないものを次々と追加していくと、全体として一貫性のないシステムになってしまいます。 新しい機能や改善を加えるときは、そのアイデアがシステム全体のコンセプトと調和しているかを意識することが重要です。

今日初めて知ったのですが、データ型のchar（characterの略）は、ずっと「カー（kar）」だと思っていました。 でも、Bjarne Stroustrup氏本人によると、発音は「チャー（tchar）」らしいです。 これからは「チャー」と読むようにしようと思います。

2022年は、ソフトウェア開発業界が大きく拡大した時期のひとつだったと思います。その後、市場全体の調整やAIブームの影響もあり、状況は大きく変化しました。 ただ、今年に入ってからは、ソフトウェアエンジニアの求人市場は再び上向きの傾向を見せています。

Bunは、Node.jsの人気代替ランタイムとして知られていますが、最近、約100万行（1M LOC）のRustによる再実装が、ほぼClaudeによるLLM自動化だけで進められていたことが話題になっています。 この再実装は、AnthropicによるBunの買収後に進められたもので、現在では既存テストスイートの99.8％を通過したとのことです。完全版が正式リリースされれば、Anthropicはこの事例を「LLMによる大規模開発」の成功例として強くアピールしていく可能性があります。 ただし、この成果の背景には、既に大量のテスト資産が存在していたことが大きく影響しています。単体テストだけでなく、E2Eテストなども含めて、既存の検証基盤が非常に充実していたからです。 また、テストが通ることと、バグが存在しないことは別問題です。さらに、保守性や長期的なコード品質といった領域は、テストだけでは測れません。この再構築されたプロジェクトが今後どのように発展していくのかは、引き続き見ていく必要がありそうです。

先月、Metaのエンジニアたちは、社内全体（約7万8千人以上）のトークン使用量を追跡する内部ランキングを作成したそうです。社員同士で「誰が最も多くトークンを使ったか」を競うような仕組みに見えますが、驚くべきことに、会社全体で1か月に約60兆トークンが使われていたとのことです。 参考として、これを標準的な価格設定（Claude Opus 4.7の入力トークン単価である100万トークンあたり5ドル）で計算すると、1か月で約3億ドル分のトークンコストになります。社員1人あたりに換算すると、月3,800ドル近い計算コストです。 ただ個人的には、トークン使用量を生産性の指標として扱うべきではないと思っています。

AIを活用する開発者の間では、大きく2つの考え方に分かれているように感じます。 ひとつは、実装の細かい部分に関わる機会が減り、開発の楽しさが薄れてしまったと感じる人たちです。 もうひとつは、単調なコーディング作業から解放され、より大きな設計や全体像に集中できるようになり、むしろ楽しくなったと感じる人たちです。 AIの使い方次第で、開発体験は大きく変わってくるのかもしれません。

仕事においては、まず一定水準の技術力が求められます。 ただし、その水準を超えたあとは、追加の技術力だけで評価が大きく上がるとは限りません。 むしろ企業が重視するのは、コミュニケーション力やソフトスキルです。チームメンバーとうまく連携し、協力しながらプロジェクトを前に進められるか、一緒に働きやすい存在でいられるか、といった点が重要になります。 また、チームやプロジェクト、会社全体のニーズを理解して行動できるかも大切な要素です。 必要な技術力に加えて、優れたソフトスキルを兼ね備えていれば、チームにとって非常に価値の高い人材になれると言えると思います。

ひとつのトレーニングとして、スキルの成長に合わせて履歴書を常に更新しておくことをおすすめします。また、実際に求人へ応募して面接を受けてみることも有効です。 たとえば、半年に一度くらいのペースで面接を受けることで、面接力を維持することができます。あわせて、現在の自分のスキルがどの程度通用するのかを客観的に確認する機会にもなります。 さらに、実際に市場に触れることで、自分のスキルがどのように評価されるのかを把握できるため、キャリアの方向性を見直すうえでも役立ちます。

GitHub CLIは、今後ユーザーの利用統計データを収集するようになります。なお、データは個人が特定できないよう加工された状態で、GitHub社の社内分析システムへ送信されます。 公式のリリースノートを見る限り、今回のデータ収集の主な狙いは、AIエージェントがよりスムーズに動作・連携できるように改善することにあるようです。

AIによって、バグやセキュリティの脆弱性を誰でも簡単に見つけられる時代になってきました。その影響もあり、Linuxでは、特に脆弱性のリスクが高い古いネットワークドライバのサポートを打ち切る検討が進んでいます。 古いドライバのコードを維持し続けるコストは高く、保守の負担が限界に近づいているという現実があります。一方で、古いハードウェアまでサポートすることはLinuxの大きな魅力のひとつでもあります。 そのため、今回のような判断は、理にかなっている一方で、受け入れにくい側面もある難しい問題だと言えるでしょう。

AIにコード生成を大きく依存する場合、ある種のジレンマが生まれます。 Anthropicの研究でも、「コーディングスキルの低下が懸念される理由のひとつに“監督のパラドックス”がある」と指摘されています。つまり、AIを効果的に使うには適切な監督が必要であり、その監督には本来のコーディングスキルが求められるということです。 言い換えると、AIに頼るほど自分のコーディングスキルが落ち、その結果、AIの出力を正しく評価・修正できなくなるという悪循環に陥る可能性があります。 そして、適切に監督できなければ、AIが生成するコードの品質も下がってしまうことになります。

今回の変更に興味がある方は、GitHubの公式ブログ記事で詳しく確認できます。 github.blog/news-insights/…

GitHub Copilotは、2026年6月1日からすべてのプランを従量課金制に移行すると発表しました。 ついにこの流れが来た、という印象です。多くの企業は、プロダクトが成熟しユーザー数が十分に増えるまでは、トークンコストを自社で負担して利用者を増やす戦略を取りますが、その段階を越えたということなのでしょう。 Copilotは開発者向けAIアシスタントの中でも特に影響力の大きい存在であるため、今回の動きに続いて、他のサービスも同様のモデルへ移行していく可能性は十分にあると思います。

Metaは、5月20日から再び全体の約10％にあたる人員削減を行う予定とされています。今回は約8,000人を削減し、その後6,000人を新たに採用する方針のようです。 このような動きは、従業員の士気に少なからず影響を与える可能性があり、2022年の状況を思い起こさせます。最近は、長期的な成長や従業員への配慮よりも、効率や成果が重視されている傾向が強まっているようにも感じられます。 実際、2022年にも同様に約10％の人員削減が行われ、その後人員を増やし、再び削減するという流れになっています。こうした動きは、ある種のパターンとして繰り返されているようにも見えます。 この計画が進めば、2026年には従業員数は約7万人規模まで減少する見込みです。

コーディング面接の対策として、解法を丸暗記するだけではあまり意味がありません。それよりも、なぜその解法がうまくいくのか、そしてどのデータ構造がどのように役立っているのかを理解することが重要です。 その解法が、問題に対してどのようにメリット・デメリットのバランスを取っているのかも考えてみるべきです。また、自分が見落としていたエッジケースや、その見落としがなぜ起きたのかも振り返ると、理解が深まります。 もしその問題で使われているアルゴリズムやデータ構造を知らなかった場合は、新しく学ぶ絶好の機会ですし、すでに知っていた場合でも、使い方に関する新しい気づきが得られるはずです。 そうした理解を積み重ねることで、知識を応用できる形に一般化し、パターンとして見抜ける力が身についていきます。

コードベースの中で、小さくて独立した処理であればAIに任せることは十分に有効です。最悪の場合でも、自分で書き直せば済むからです。 ただし、ソフトウェア設計やアーキテクチャをLLMに任せるのは慎重になるべきです。LLMは仕組み上、与えられた内容に対して似たケースの「平均的な設計」を返す傾向があります。しかし実際のプロジェクトには、固有の要件、制約、トレードオフ、現実的な利用シーンが存在し、そこには多くの文脈が含まれています。 そのため、必要なのは平均的な設計ではなく、そのプロジェクトに最適化された具体的な設計です。さらに重要なのは、設計はコードベース全体に影響する土台になるという点です。小さな関数のように簡単に差し替えられるものではなく、一度決めた設計は広く浸透していきます。 もし途中で設計に問題があると分かっても、簡単にゼロからやり直すことはできません。既に実装が進んでいる状態での再設計は非常にコストが高くなります。だからこそ、設計の段階では特に慎重な判断が求められます。