<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0">
    <channel>
        <title>tmf16 - しずかなインターネット</title>
        <link>https://sizu.me/tmf16</link>
        <description>tmf16 さんの記事一覧のRSSフィードです</description>
        <lastBuildDate>Wed, 28 Oct 2026 19:03:31 GMT</lastBuildDate>
        <docs>https://validator.w3.org/feed/docs/rss2.html</docs>
        <generator>しずかなインターネット</generator>
        <image>
            <title>tmf16 - しずかなインターネット</title>
            <url>https://r2.sizu.me/users/1882/avatar.jpeg?v=1700038927484</url>
            <link>https://sizu.me/tmf16</link>
        </image>
        <copyright>© @tmf16</copyright>
        <item>
            <title><![CDATA[期待を伝えよう]]></title>
            <link>https://sizu.me/tmf16/posts/0mf3z9wsxz1s</link>
            <guid>https://sizu.me/tmf16/posts/0mf3z9wsxz1s</guid>
            <pubDate>Wed, 28 Oct 2026 14:22:15 GMT</pubDate>
            <description><![CDATA[期待値を伝えてないのに、その方向に成長してくれると勝手に期待してもそうなることはほぼない。
評価の場などで、本人に期待を伝えずに「ここができていない」と驚かせても納得感が持てないし、どうなって欲しいのかわからない状態では努力を積み上げる方向もよくわからないだろう。
だからこそ、期待をちゃんと伝えることが大切だ。今できる仕事だけ渡しても、期待するような成長はしない。
期待をちゃんと伝えて、少し挑戦の…]]></description>
        </item>
        <item>
            <title><![CDATA[エンジニアの役割は事業成果と生産能力に分かれていく]]></title>
            <link>https://sizu.me/tmf16/posts/zz0xuuwowmkv</link>
            <guid>https://sizu.me/tmf16/posts/zz0xuuwowmkv</guid>
            <pubDate>Fri, 24 Jul 2026 07:13:40 GMT</pubDate>
            <description><![CDATA[自社サービスを開発するエンジニアは、今後、事業成果に責任を持つ側と、開発組織の生産能力に責任を持つ側へ、役割の重心が分かれていくと思います。
AIによってエンジニアが不要になるのではなく、エンジニアが責任を持つ対象が変わっていく。
FindyさんのAI Dev DX 2026に参加し、自分の中でこの考えが一段整理されたのでまとめておきます。
運営・登壇された皆様、ありがとうございました。
事業成果…]]></description>
        </item>
        <item>
            <title><![CDATA[自制できない組織から自由は消える]]></title>
            <link>https://sizu.me/tmf16/posts/4khdbb4h6b4f</link>
            <guid>https://sizu.me/tmf16/posts/4khdbb4h6b4f</guid>
            <pubDate>Mon, 06 Apr 2026 10:38:00 GMT</pubDate>
            <description><![CDATA[エンジニアとしてアウトカムを最大にするには、自由が重要だと思っている。だから私は、エンジニア組織にルールを増やすことをできるだけ避けたい。
以前にも書いたが、ルールは本来、組織の外との約束のために必要なものだと思っている。 組織の内側では、ルールよりも文化で動ける状態でありたい。
ただ、その自由は無条件には成立しない。自由とは、好き勝手に振る舞えることではなく、組織の目的に沿って自分を律しながら働…]]></description>
        </item>
        <item>
            <title><![CDATA[「任せられるチーム」をつくる（Engineering Manager）]]></title>
            <link>https://sizu.me/tmf16/posts/nidxnchdu8kt</link>
            <guid>https://sizu.me/tmf16/posts/nidxnchdu8kt</guid>
            <pubDate>Mon, 20 Oct 2025 09:06:24 GMT</pubDate>
            <description><![CDATA[「EMはコードを書かない人」ではなく、「任せられるチームをつくる人」だと考えます。
そのため、コードを書いているかどうかは本質的な評価軸にはなりません。むしろ問うべきは「そのチームが事業に価値を届け続けられているかどうか」です。
EMの役割整理には「Engineering Management Triangle」(Technology / Product / Team) という有名なモデルがありま…]]></description>
        </item>
        <item>
            <title><![CDATA[「作る」が速くなった時代に、エンジニアとPdMに求められる役割の変化]]></title>
            <link>https://sizu.me/tmf16/posts/sbchfffde9rx</link>
            <guid>https://sizu.me/tmf16/posts/sbchfffde9rx</guid>
            <pubDate>Tue, 14 Oct 2025 08:33:14 GMT</pubDate>
            <description><![CDATA[開発プロセスにAIが導入されて来て、これまでは「実装が大変」「テストが追いつかない」といった、手を動かす部分がネックになりやすかった。
しかし今は、「何を作るか」「なぜ作るか」のほうが難しくなっています。
AIを導入してコードの出力は早くなったが開発自体の速度はそれほど上がっていないとの記事を見かけることもあり、これはボトルネックが移動した形だと考えます。
並行開発数が増える
この変化で一番大きい…]]></description>
        </item>
        <item>
            <title><![CDATA[技術的負債の“返済責任”は誰にあるのか？]]></title>
            <link>https://sizu.me/tmf16/posts/dn5st62dr1mu</link>
            <guid>https://sizu.me/tmf16/posts/dn5st62dr1mu</guid>
            <pubDate>Sun, 27 Jul 2025 06:23:51 GMT</pubDate>
            <description><![CDATA[技術的負とは、ウォード・カニンガム氏が1992年頃に紹介したメタファーが起源です。彼は「今すぐ出荷するために、クリーンでないコードを書くことは、借金をするのと同じだ。返済しないと利息がたまる」と述べています。
つまり、技術的負債とは悪ではなく、意思決定のひとつです。そして、利息（開発速度の低下やバグ修正コストの増大）を見越して、計画的に扱うことが求められます。問題は、技術的負債が返済されないまま放…]]></description>
        </item>
        <item>
            <title><![CDATA[開発生産性カンファレンス2025に参加して考えたこと]]></title>
            <link>https://sizu.me/tmf16/posts/w96xbcrt074s</link>
            <guid>https://sizu.me/tmf16/posts/w96xbcrt074s</guid>
            <pubDate>Mon, 07 Jul 2025 03:09:39 GMT</pubDate>
            <description><![CDATA[開発生産性カンファレンスに参加しました。忘れないように考えをまとめてみました。
# 開発生産性とは
現場レベルでは、DORAの「Four Keys」などの指標を活用しているケースも多いと思いますが、事業や経営の指標とどう紐づけるかについては、まだ試行錯誤の段階という印象を受けました。
生産性 = アウトプット / インプット
インプット（エンジニアの人数や人件費など）は比較的わかりやすい一方で、ア…]]></description>
        </item>
        <item>
            <title><![CDATA[10xエンジニア、再び]]></title>
            <link>https://sizu.me/tmf16/posts/146k4mwo9z2t</link>
            <guid>https://sizu.me/tmf16/posts/146k4mwo9z2t</guid>
            <pubDate>Thu, 19 Jun 2025 03:46:10 GMT</pubDate>
            <description><![CDATA[「エンジニアの生産性には10倍の差がある」（10xエンジニア）という言葉を最近はあまり聞かなくなっていましたが、ここにきて、意味を変えながら再び浮上しているように感じます。
昔は個人のセンスや地頭、技術力を指していましたが、今では“AIをどう使うか”のセンスにこそ、その差が現れていると感じます。
AIの進化により、すでに仕様が固まっているタスクを何日もかけてコーディングするようなケースは、今後ほと…]]></description>
        </item>
        <item>
            <title><![CDATA[マネージャーは結束点]]></title>
            <link>https://sizu.me/tmf16/posts/afo08iefhirn</link>
            <guid>https://sizu.me/tmf16/posts/afo08iefhirn</guid>
            <pubDate>Tue, 05 Nov 2024 15:34:42 GMT</pubDate>
            <description><![CDATA[ボトムアップの施策もあるが、事業の進みたい方向は概ねトップダウン。
組織は事業を実行するための仕組みなので、経営陣が向かう先を示し組織の細部に行き渡るまでに抽象から具体化されていく。
よく何でこれをやっているかわからない。的なことが発生するが、それはメンバー的には抽象から具体までのプロセスに全部参加しているわけではないので、その途中で情報が抜け落ちてしまっているのが原因。
マネージレイヤーは減衰し…]]></description>
        </item>
        <item>
            <title><![CDATA[課題のレイヤー]]></title>
            <link>https://sizu.me/tmf16/posts/s3v860m95eww</link>
            <guid>https://sizu.me/tmf16/posts/s3v860m95eww</guid>
            <pubDate>Tue, 22 Oct 2024 01:24:28 GMT</pubDate>
            <description><![CDATA[課題を解消したいが、レイヤーによって課題の中身が違う
経営課題
事業課題
仕様課題
技術課題
どの課題の話をしているのか。どの課題を解決しようとしているのかは常に意識しておかないとズレてしまう。]]></description>
        </item>
        <item>
            <title><![CDATA[評価に対するズレ]]></title>
            <link>https://sizu.me/tmf16/posts/0va0b555z4fw</link>
            <guid>https://sizu.me/tmf16/posts/0va0b555z4fw</guid>
            <pubDate>Tue, 22 Oct 2024 01:24:07 GMT</pubDate>
            <description><![CDATA[個人から見ると過去の自分からの成長なので絶対評価。
会社から見ると給与は経営資源の分配なので、まわりと比較した相対評価。
なので、仕事してるだけの自然な成長だと、会社から見ると影響力が変わってないので、あまり評価してあげられない。]]></description>
        </item>
        <item>
            <title><![CDATA[ルールを作る仕事、作らない仕事]]></title>
            <link>https://sizu.me/tmf16/posts/fosm435icdzh</link>
            <guid>https://sizu.me/tmf16/posts/fosm435icdzh</guid>
            <pubDate>Sat, 03 Aug 2024 15:10:17 GMT</pubDate>
            <description><![CDATA[VPoEとして意識している二つの仕事
ルールを作る仕事
会社の組織として、評価制度や働き方に対する福利厚生。監査に対する開発ルールなど
ルールを作らない仕事
開発組織として文化作り。ルールにしなくても前向きに仕事をする姿勢や、越境するマインド]]></description>
        </item>
    </channel>
</rss>