<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0">
    <channel>
        <title>やまぐちたくや - しずかなインターネット</title>
        <link>https://sizu.me/yamat47</link>
        <description>やまぐちたくや さんの記事一覧のRSSフィードです</description>
        <lastBuildDate>Tue, 15 Sep 2026 11:44:38 GMT</lastBuildDate>
        <docs>https://validator.w3.org/feed/docs/rss2.html</docs>
        <generator>しずかなインターネット</generator>
        <image>
            <title>やまぐちたくや - しずかなインターネット</title>
            <url>https://r2.sizu.me/users/20314/avatar.jpeg?v=1706675123876</url>
            <link>https://sizu.me/yamat47</link>
        </image>
        <copyright>© @yamat47</copyright>
        <item>
            <title><![CDATA[プラットフォームエンジニアリングの大切さはアメフトをやったことがある人ならよくわかるかも？]]></title>
            <link>https://sizu.me/yamat47/posts/79o6813fkce3</link>
            <guid>https://sizu.me/yamat47/posts/79o6813fkce3</guid>
            <pubDate>Sat, 10 Aug 2024 02:37:56 GMT</pubDate>
            <description><![CDATA[『炎のランニングバック』が YouTube Music で流れてきて、なんとなく思いついたのでメモ。特に RB や OL をやっていた人なら同感してもらえるんじゃないかなと思う。
まず、プラットフォームエンジニアリングとはこのようなもの：（ChatGPT より）
プラットフォームエンジニアリングとは、企業内でソフトウェア開発を効率化するための共通プラットフォームやツールを提供する専門的なエンジニア…]]></description>
        </item>
        <item>
            <title><![CDATA[本を読むときに、理解のための要約はしないし使わないと決めている]]></title>
            <link>https://sizu.me/yamat47/posts/v0mo0en8a9wk</link>
            <guid>https://sizu.me/yamat47/posts/v0mo0en8a9wk</guid>
            <pubDate>Wed, 06 Mar 2024 23:33:36 GMT</pubDate>
            <description><![CDATA[身近な人何人かに聞いたがあまり賛同は得られなかったので、この話が役に立つ場面は少ないかもしれません。悪しからず。
本を読んで学びを得ようとするとき、要約されている文章を読んだり自分で要約をしたりする人がいる。最近だと ChatGPT をはじめとする生成 AI が当たり前のものになっていて、全文にじっくり目を通す人はますます減っているのでは。
一方で僕は本の要約について、
理解の促進のために自分で要…]]></description>
        </item>
        <item>
            <title><![CDATA[KPT をしたら「T が今までできていなかった理由」まで深掘りするようにしてる]]></title>
            <link>https://sizu.me/yamat47/posts/67ne6z2d5xwn</link>
            <guid>https://sizu.me/yamat47/posts/67ne6z2d5xwn</guid>
            <pubDate>Sun, 18 Feb 2024 04:13:49 GMT</pubDate>
            <description><![CDATA[振り返りをする際に KPT のフレームワークがシンプルかつ強力なのでよく使っている。
そして加えて、タイトルの通りだが「Try をこれまでできていなかった理由」についてもその場で考えるようにしている。
単に「これまでやってみようと思ったことがなかったから」ならいいが、そうではないこともしばしばあって… そういうときに、結局 Try が全く実行されないような事態が起きうるので。
ちょっと抽象的すぎる…]]></description>
        </item>
        <item>
            <title><![CDATA[インシデントは「ソフトウェアが意図しない動作をしている状態」くらいな認識でいると良い]]></title>
            <link>https://sizu.me/yamat47/posts/8x688xeexcei</link>
            <guid>https://sizu.me/yamat47/posts/8x688xeexcei</guid>
            <pubDate>Wed, 31 Jan 2024 14:46:05 GMT</pubDate>
            <description><![CDATA[いわゆる「インシデント対応フロー」が整備されてる組織は多いはず。今所属している会社でもそうで、第一発見から暫定対応・恒久対応、何ならポストモーテムの実施も含めて手順が明文化されている。
一方で「対応フローを発動するか」の基準についてはどうだろうか。要はインシデントの定義とは？という話。
調べてみると、いろいろな人がいろいろな定義をしているように感じる。絶対的な正解はなく流派のようなものがあるような…]]></description>
        </item>
        <item>
            <title><![CDATA[役割に縛られてタスクを選んでいることってありません？]]></title>
            <link>https://sizu.me/yamat47/posts/o36sowe4thav</link>
            <guid>https://sizu.me/yamat47/posts/o36sowe4thav</guid>
            <pubDate>Fri, 15 Dec 2023 02:34:14 GMT</pubDate>
            <description><![CDATA[フロントエンドエンジニア
バックエンドエンジニア
セキュリティエンジニア
インフラエンジニア
SRE エンジニア
QA エンジニア
… etc.
といった名前付けは、自分自身の役割（タスク）に固定観念を与える可能性があるのですごく慎重にせねば、と思っている。
ラベリングによって、タスク選定にまつわる条件が（本来不要なのに）増えてしまう、みたいなイメージ。
フロントエンドエンジニアだから、バックエン…]]></description>
        </item>
    </channel>
</rss>