<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Nguyen Le Phong: ブログ</title>
    <link>https://nguyenlephong.github.io/ja/blog</link>
    <description>ソフトウェアアーキテクチャ、AI、チームの働き方についての記事。</description>
    <language>ja</language>
    <lastBuildDate>Thu, 12 Mar 2026 00:00:00 GMT</lastBuildDate>
    <atom:link href="https://nguyenlephong.github.io/ja/blog/feed.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>AIエージェント、誇張なしで解説：それが何か、どう動くか、何をしてくれるか</title>
      <link>https://nguyenlephong.github.io/ja/blog/ai/ai-agents-explained</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/ja/blog/ai/ai-agents-explained</guid>
      <pubDate>Thu, 12 Mar 2026 00:00:00 GMT</pubDate>
      <description>「AIエージェント」という言葉が急速に広まっています——質問に答えるだけでなく、実際に仕事をこなしてくれるソフトウェアです。でも、エージェントとは本当に何でしょう？すでに使っているchatbotとどう違うのか、どこで本当に役立ち、どこで静かに問題を起こすのか？これは、技術的な知識の有無を問わず誰でも読めるフレンドリーなガイドです。すべてのエージェントが動く単純なループ、エージェントを構成する5つの要素、co-pilotからauto-pilotまでの自律性のレベル、職場と日常生活での具体例、気をつけるべき失敗パターン、そして今週から使える第一歩を丁寧に解説します。</description>
      <category>AI と未来</category>
      <category>AI</category>
      <category>AIエージェント</category>
      <category>Agentic AI</category>
      <category>自動化</category>
      <category>仕事の未来</category>
    </item>
    <item>
      <title>promptからworkflowへ：毎週何時間も節約するAI workflowの作り方</title>
      <link>https://nguyenlephong.github.io/ja/blog/ai/ai-workflows-that-save-hours</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/ja/blog/ai/ai-workflows-that-save-hours</guid>
      <pubDate>Wed, 11 Mar 2026 00:00:00 GMT</pubDate>
      <description>ほとんどの人はAIを一度に一つの質問で使い、その価値の大部分をテーブルに残したままにしています。本当のレバレッジは巧みなpromptではありません。繰り返せるAI workflow——一度設計して永遠に再利用できる、毎回2時間かかる雑務を2分のレビューに変える小さなステップの連鎖です。技術的な知識の有無を問わず誰でも読めるこの実践ガイドでは、promptとworkflowの違い、すべてのworkflowが共有するシンプルな構造、職場と日常生活ですぐに使えるworkflowの例、手動から全自動への3つのレベル、自分のworkflowを設計する6ステップ、そして本当に時間を節約しているかを確かめる簡単な計算式を解説します。</description>
      <category>AI と未来</category>
      <category>AI</category>
      <category>AI Workflow</category>
      <category>自動化</category>
      <category>生産性</category>
      <category>仕事の未来</category>
    </item>
    <item>
      <title>2026年に注目すべきAIトレンドと、それを本当の価値に変える方法</title>
      <link>https://nguyenlephong.github.io/ja/blog/ai/ai-trends-2026-into-value</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/ja/blog/ai/ai-trends-2026-into-value</guid>
      <pubDate>Tue, 10 Mar 2026 00:00:00 GMT</pubDate>
      <description>毎週「これがすべてを変える」というAIの見出しが届いて、信号とノイズを見分けようとするだけで疲れ果てています。これは2026年に本当に重要なAIトレンドを穏やかに整理したガイドです——agentic AI・マルチモーダル・すでに使っているアプリに組み込まれたAI・オンデバイスのインテリジェンス・人間の強みとしての判断と検証の台頭——そして、ほとんどの記事が省略する部分とセットにして解説します。どんなトレンドも仕事と生活に実際の価値へと変えるための実践的なフレームワーク。ハイプと価値のフィルター・価値のはしご・シンプルな価値の方程式・具体的な実例・30日プランを手に入れて、ニュースを追いかけるのをやめて、メリットを積み上げ始めましょう。</description>
      <category>AI と未来</category>
      <category>AI</category>
      <category>AIトレンド</category>
      <category>Agentic AI</category>
      <category>仕事の未来</category>
      <category>生産性</category>
    </item>
    <item>
      <title>Ports &amp; Adapters（Hexagonal Architecture）をやさしく解説</title>
      <link>https://nguyenlephong.github.io/ja/blog/architecture/ports-and-adapters</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/ja/blog/architecture/ports-and-adapters</guid>
      <pubDate>Sat, 07 Mar 2026 00:00:00 GMT</pubDate>
      <description>Hexagonal Architecture の入門ガイドです。ポートとアダプターが実際に何であるか、それを成立させる唯一のルール、そしてどこまで適用すべきかを、ソロ開発者からエンタープライズチームまでに向けてわかりやすく解説します。</description>
      <category>ソースコード &amp; アーキテクチャ</category>
      <category>ソフトウェアアーキテクチャ</category>
      <category>Hexagonal Architecture</category>
      <category>Ports and Adapters</category>
      <category>Clean Architecture</category>
      <category>システム設計</category>
    </item>
    <item>
      <title>Clean・Onion・Hexagonal Architecture：一つの北極星、三つの名前</title>
      <link>https://nguyenlephong.github.io/ja/blog/architecture/clean-vs-onion-vs-hexagonal</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/ja/blog/architecture/clean-vs-onion-vs-hexagonal</guid>
      <pubDate>Fri, 06 Mar 2026 00:00:00 GMT</pubDate>
      <description>三つのアーキテクチャが対立しているように見えますが、実は同じアイデアです――依存は内向き、フレームワークは端に置く――を三通りに描いたものです。それぞれが何を加えているのか、どれを選べばよいかを解説します。</description>
      <category>ソースコード &amp; アーキテクチャ</category>
      <category>ソフトウェアアーキテクチャ</category>
      <category>Clean Architecture</category>
      <category>Onion Architecture</category>
      <category>Hexagonal Architecture</category>
      <category>システム設計</category>
    </item>
    <item>
      <title>Dependency Injection と Inversion of Control——魔法なしで理解する</title>
      <link>https://nguyenlephong.github.io/ja/blog/architecture/dependency-injection-and-ioc</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/ja/blog/architecture/dependency-injection-and-ioc</guid>
      <pubDate>Thu, 05 Mar 2026 00:00:00 GMT</pubDate>
      <description>DIコンテナは、根底にあるシンプルなアイデアを見るまで魔法のように感じられます：コードが自分で依存を作るのをやめ、外から受け取るようにする、それだけです。初歩から始めるガイドで、実例とテストの恩恵をお届けします。</description>
      <category>ソースコード &amp; アーキテクチャ</category>
      <category>ソフトウェアアーキテクチャ</category>
      <category>Dependency Injection</category>
      <category>Inversion of Control</category>
      <category>SOLID</category>
      <category>テスト</category>
    </item>
    <item>
      <title>コードベースの構成：レイヤー・フィーチャー・ドメイン、どれを選ぶ？</title>
      <link>https://nguyenlephong.github.io/ja/blog/architecture/structuring-code-feature-vs-layer</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/ja/blog/architecture/structuring-code-feature-vs-layer</guid>
      <pubDate>Wed, 04 Mar 2026 00:00:00 GMT</pubDate>
      <description>トップレベルのフォルダーを controllers/services/models にすべきか、orders/billing/auth にすべきか？この選択はコードベースの成長を静かに形作ります。レイヤー別・フィーチャー別・Screaming Architecture を実践的に比較し、会社の規模ごとのトレードオフを解説します。</description>
      <category>ソースコード &amp; アーキテクチャ</category>
      <category>ソフトウェアアーキテクチャ</category>
      <category>プロジェクト構成</category>
      <category>Screaming Architecture</category>
      <category>Modularity</category>
      <category>コード構成</category>
    </item>
    <item>
      <title>モノリス・Modular Monolith・マイクロサービス：正直な意思決定ガイド</title>
      <link>https://nguyenlephong.github.io/ja/blog/architecture/monolith-to-microservices</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/ja/blog/architecture/monolith-to-microservices</guid>
      <pubDate>Tue, 03 Mar 2026 00:00:00 GMT</pubDate>
      <description>マイクロサービスは組織的スケールのために払う税金であり、出発点ではありません。モノリスから Modular Monolith を経てマイクロサービスへの誇大広告なしのウォークスルーと、いつ（そして本当に）分割すべきかを示すシグナルを解説します。</description>
      <category>ソースコード &amp; アーキテクチャ</category>
      <category>ソフトウェアアーキテクチャ</category>
      <category>Microservices</category>
      <category>Modular Monolith</category>
      <category>システム設計</category>
      <category>分散システム</category>
    </item>
    <item>
      <title>Micro-Frontends：いつ価値があり、何が実際にかかるか</title>
      <link>https://nguyenlephong.github.io/ja/blog/architecture/micro-frontends-when-why-and-cost</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/ja/blog/architecture/micro-frontends-when-why-and-cost</guid>
      <pubDate>Mon, 02 Mar 2026 00:00:00 GMT</pubDate>
      <description>フロントエンドを独立してデプロイ可能なピースに分割することでチームが解放されることも、複雑さに埋もれることもあります。Angular ホスト＋ React モジュールをスケールで出荷した経験から：Micro-Frontends が見返りをもたらす場面と、それに伴うコストを正直にお伝えします。</description>
      <category>ソースコード &amp; アーキテクチャ</category>
      <category>ソフトウェアアーキテクチャ</category>
      <category>Micro-Frontends</category>
      <category>フロントエンドアーキテクチャ</category>
      <category>Module Federation</category>
      <category>スケーラビリティ</category>
    </item>
    <item>
      <title>コードレビューという技術：人を傷つけずにコードを批評する方法</title>
      <link>https://nguyenlephong.github.io/ja/blog/culture/how-to-review-code-kindly</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/ja/blog/culture/how-to-review-code-kindly</guid>
      <pubDate>Sun, 01 Mar 2026 00:00:00 GMT</pubDate>
      <description>コードレビューは、チームカルチャーが育まれるか壊れるかの分岐点です。コードをより良く仕上げながら、書いた人がより成長して戻ってこられるレビューの実践ガイド——具体的なフレーズ、レビュアーのチェックリスト、そしてレビューを静かに有害にしてしまう習慣を紹介します。</description>
      <category>エンジニアリング文化</category>
      <category>エンジニアリング文化</category>
      <category>コードレビュー</category>
      <category>Pull Requests</category>
      <category>フィードバック</category>
      <category>チームコラボレーション</category>
    </item>
    <item>
      <title>Kind Engineering：優しさがあなたをより良いエンジニアにする理由</title>
      <link>https://nguyenlephong.github.io/ja/blog/culture/how-to-be-a-kind-engineer</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/ja/blog/culture/how-to-be-a-kind-engineer</guid>
      <pubDate>Sat, 28 Feb 2026 00:00:00 GMT</pubDate>
      <description>優しさはお人好しでも、柔弱でもありません。フォース・マルティプライヤーです——より明確なフィードバック、より安全なインシデント対応、より速く成長するチームメンバーを生み出します。「Kind Engineering」とは何か、そしてコードレビュー、インシデント対応、日常の仕事の中でそれをどう実践するかを解説します。</description>
      <category>エンジニアリング文化</category>
      <category>エンジニアリング文化</category>
      <category>Kind Engineering</category>
      <category>心理的安全性</category>
      <category>共感</category>
      <category>チームコラボレーション</category>
    </item>
    <item>
      <title>レビューしたくなるプルリクエストの書き方</title>
      <link>https://nguyenlephong.github.io/ja/blog/culture/how-to-write-a-great-pull-request</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/ja/blog/culture/how-to-write-a-great-pull-request</guid>
      <pubDate>Fri, 27 Feb 2026 00:00:00 GMT</pubDate>
      <description>優れたプルリクエストはレビュアーへの贈り物です：小さく、説明が丁寧で、Yesと言いやすい。レビュー可能なプルリクエストの解剖——サイズ、タイトル、説明、コミット衛生、セルフレビュー——を具体的なビフォー・アフターの例で解説します。</description>
      <category>エンジニアリング文化</category>
      <category>エンジニアリング文化</category>
      <category>Pull Requests</category>
      <category>コードレビュー</category>
      <category>Git</category>
      <category>チームコラボレーション</category>
    </item>
    <item>
      <title>届くフィードバック：エンジニアとして批評を与え、受け取る方法</title>
      <link>https://nguyenlephong.github.io/ja/blog/culture/giving-and-receiving-feedback</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/ja/blog/culture/giving-and-receiving-feedback</guid>
      <pubDate>Wed, 25 Feb 2026 00:00:00 GMT</pubDate>
      <description>フィードバックの与え方を学んでいるエンジニアはほとんどいません——受け取り方も同様です。具体的で、優しく、実行可能なフィードバックへのフィールドガイド、そして受け取る側で開かれた姿勢を保つための方法。すぐに使えるスクリプト付き。</description>
      <category>エンジニアリング文化</category>
      <category>エンジニアリング文化</category>
      <category>フィードバック</category>
      <category>コミュニケーション</category>
      <category>心理的安全性</category>
      <category>メンタリング</category>
    </item>
    <item>
      <title>エンジニアのメンタリング：ジュニアをシニアに育てる方法</title>
      <link>https://nguyenlephong.github.io/ja/blog/culture/mentoring-engineers</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/ja/blog/culture/mentoring-engineers</guid>
      <pubDate>Tue, 24 Feb 2026 00:00:00 GMT</pubDate>
      <description>優れたチームは採用するだけでなく育てることで生まれます。エンジニアリングチームのリードとして得た経験から：ペアプログラミング、教えるチャンネルとしてのコードレビュー、ちょうど良いストレッチ課題、そしてジュニアを誰にでも任せられる存在に変えるマインドセットの転換を紹介します。</description>
      <category>エンジニアリング文化</category>
      <category>エンジニアリング文化</category>
      <category>メンタリング</category>
      <category>キャリア成長</category>
      <category>リーダーシップ</category>
      <category>チームコラボレーション</category>
    </item>
    <item>
      <title>コンテキストエンジニアリング：AIを使いこなせる人とそうでない人の差</title>
      <link>https://nguyenlephong.github.io/ja/blog/ai/context-engineering</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/ja/blog/ai/context-engineering</guid>
      <pubDate>Sun, 22 Feb 2026 00:00:00 GMT</pubDate>
      <description>AIの結果が期待外れなのは、モデルが悪いからではなく、コンテキストが薄いからです。コンテキストエンジニアリングの実践ガイド——モデルのウィンドウに何があるか、優れたコンテキストの5つの柱、よくあるアンチパターン、そして一貫して良い結果を生む再利用可能なテンプレート。</description>
      <category>AI と未来</category>
      <category>AI</category>
      <category>コンテキストエンジニアリング</category>
      <category>プロンプトエンジニアリング</category>
      <category>LLM</category>
      <category>開発者生産性</category>
    </item>
    <item>
      <title>レイヤードアーキテクチャと Vertical Slice Architecture</title>
      <link>https://nguyenlephong.github.io/ja/blog/architecture/layered-vs-vertical-slice-architecture</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/ja/blog/architecture/layered-vs-vertical-slice-architecture</guid>
      <pubDate>Wed, 11 Feb 2026 00:00:00 GMT</pubDate>
      <description>レイヤード構成は最初は整って見えます。一方、Vertical Slice は変更を実際の機能に近づけます。両者の良さ、痛み、移行の合図を落ち着いて考えます。</description>
      <category>ソースコード &amp; アーキテクチャ</category>
      <category>ソフトウェアアーキテクチャ</category>
      <category>Vertical Slice Architecture</category>
      <category>Layered Architecture</category>
      <category>コード構成</category>
      <category>Modularity</category>
    </item>
    <item>
      <title>健全な 1-on-1 のかたち</title>
      <link>https://nguyenlephong.github.io/ja/blog/culture/anatomy-of-a-healthy-one-on-one</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/ja/blog/culture/anatomy-of-a-healthy-one-on-one</guid>
      <pubDate>Sun, 08 Feb 2026 00:00:00 GMT</pubDate>
      <description>健全な 1-on-1 は、やわらかい status meeting ではありません。context、信頼、feedback、career direction を扱うための小さく定期的な場所です。</description>
      <category>エンジニアリング文化</category>
      <category>Engineering Culture</category>
      <category>One-on-One</category>
      <category>Management</category>
      <category>Feedback</category>
      <category>Leadership</category>
    </item>
    <item>
      <title>Prompt Engineering は結局コミュニケーションである</title>
      <link>https://nguyenlephong.github.io/ja/blog/ai/prompt-engineering-is-just-communication</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/ja/blog/ai/prompt-engineering-is-just-communication</guid>
      <pubDate>Sat, 07 Feb 2026 00:00:00 GMT</pubDate>
      <description>よい prompt は魔法の言葉ではありません。context、意図、constraints、example、feedback を明確にするコミュニケーションです。</description>
      <category>AI と未来</category>
      <category>AI</category>
      <category>Prompt Engineering</category>
      <category>Communication</category>
      <category>LLM</category>
      <category>AI Literacy</category>
    </item>
    <item>
      <title>Developer として「No」と言う練習</title>
      <link>https://nguyenlephong.github.io/ja/blog/perspectives/learning-to-say-no-as-a-developer</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/ja/blog/perspectives/learning-to-say-no-as-a-developer</guid>
      <pubDate>Fri, 06 Feb 2026 00:00:00 GMT</pubDate>
      <description>No と言うことは難しく振る舞うことではありません。focus、quality、trust を守るために tradeoff を見えるようにする skill です。</description>
      <category>Perspectives &amp; Field Notes</category>
      <category>Personal Growth</category>
      <category>Software Engineering</category>
      <category>Boundaries</category>
      <category>Career Growth</category>
      <category>Communication</category>
    </item>
    <item>
      <title>Daily standup は status report か、それとも今日の strategy か</title>
      <link>https://nguyenlephong.github.io/ja/blog/ways-of-working/daily-standup-status-report-or-strategy</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/ja/blog/ways-of-working/daily-standup-status-report-or-strategy</guid>
      <pubDate>Thu, 05 Feb 2026 00:00:00 GMT</pubDate>
      <description>Daily standup は昨日を報告する儀式にも、今日の flow、risk、attention を整える短い戦略会話にもなります。</description>
      <category>Ways of Working</category>
      <category>Agile</category>
      <category>Daily Standup</category>
      <category>Scrum</category>
      <category>Team Collaboration</category>
      <category>Delivery</category>
    </item>
  </channel>
</rss>
