<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0">
    <channel>
        <title>miraoto - しずかなインターネット</title>
        <link>https://sizu.me/miraoto</link>
        <description>miraoto さんの記事一覧のRSSフィードです</description>
        <lastBuildDate>Wed, 24 Jun 2026 09:25:05 GMT</lastBuildDate>
        <docs>https://validator.w3.org/feed/docs/rss2.html</docs>
        <generator>しずかなインターネット</generator>
        <copyright>© @miraoto</copyright>
        <item>
            <title><![CDATA[AI時代のアウトプットは何が変わるのか]]></title>
            <link>https://sizu.me/miraoto/posts/69bt2n95mv6m</link>
            <guid>https://sizu.me/miraoto/posts/69bt2n95mv6m</guid>
            <pubDate>Tue, 16 Jun 2026 00:27:47 GMT</pubDate>
            <description><![CDATA[良いアウトプットの増え方を「量が増える」ではなく、「意思決定の質が変わる」という観点で整理してみる
良いアウトプットの増え方
選択肢が増える
プロトタイプの数が増える
検証できる仮説の数が増える
試せるUI・文言・導線のパターン数が増える
ボツ案が増える
パーソナライズされた解決策を試せる
一度作ったものを理想状態に合わせて作り直せる
「優先度は低くないが工数の都合で後回しになっていた施策」を実行…]]></description>
            <enclosure length="0" type="image/png" url="https://static.sizu.me/api/og-image/fdb544d4d2ba?theme=user&amp;username=miraoto"/>
        </item>
        <item>
            <title><![CDATA[組織は誰の速度に合わせて作られるのか]]></title>
            <link>https://sizu.me/miraoto/posts/2iens0kuate8</link>
            <guid>https://sizu.me/miraoto/posts/2iens0kuate8</guid>
            <pubDate>Tue, 26 May 2026 23:49:42 GMT</pubDate>
            <description><![CDATA[組織は誰の速度に合わせて作られるのか
最近、「自分、集団行動とか計画立てて進めるのとか全然できないんですよね」みたいな話を聞いていて、少し違う見え方をするようになった。
それって単純に「できない」のではなく、「自分の速度を落としてまで全体に合わせたくない」に近い感覚なんじゃないかと思った。
チームで動き始めると、仕組みやルールはどうしても「詰まりやすいところを減らす」方向に最適化される。進め方を揃…]]></description>
            <enclosure length="0" type="image/png" url="https://static.sizu.me/api/og-image/fdb544d4d2ba?theme=user&amp;username=miraoto"/>
        </item>
        <item>
            <title><![CDATA[追いかけ続けないための学習]]></title>
            <link>https://sizu.me/miraoto/posts/9s73t7nw70rz</link>
            <guid>https://sizu.me/miraoto/posts/9s73t7nw70rz</guid>
            <pubDate>Fri, 22 May 2026 03:50:46 GMT</pubDate>
            <description><![CDATA[情報が足りなかった時代は、「何を知るか」が重要だった。
でも今は、情報もツールも多すぎる。
新しいAIサービス、MCP、SaaS、エディタ、エージェント。毎日のように新しいものが出てくる。全部を追いかけようとすると、結局どれも浅くなるし、「試して終わり」になりやすい。
なので最近は、意図的に学習対象をかなり絞っている。
今、自分の中で中心に置いているのは、
Anthropic の Claude（特…]]></description>
            <enclosure length="0" type="image/png" url="https://static.sizu.me/api/og-image/fdb544d4d2ba?theme=user&amp;username=miraoto"/>
        </item>
        <item>
            <title><![CDATA[『実装できる』は、もう意思決定にならない]]></title>
            <link>https://sizu.me/miraoto/posts/75762009dw4a</link>
            <guid>https://sizu.me/miraoto/posts/75762009dw4a</guid>
            <pubDate>Thu, 21 May 2026 02:03:03 GMT</pubDate>
            <description><![CDATA[AIで開発コストが下がると、「とりあえず作る」のハードルは確実に下がる。
でも、それは「作ることの価値」が上がるというより、「作ることの希少性」が下がるに近い気がしている。
だからこそ逆に、
本当に作る必要があるのか
運用で吸収できないか
既存の導線変更だけで解決しないか
そもそも解くべき課題なのか
みたいな、「作らない判断」の重要性はむしろ上がっている。
特にAI時代は、試作や実装が速くなる分だ…]]></description>
            <enclosure length="0" type="image/png" url="https://static.sizu.me/api/og-image/fdb544d4d2ba?theme=user&amp;username=miraoto"/>
        </item>
        <item>
            <title><![CDATA[    良いエンジニアは「主体的な経験」の総量でできている]]></title>
            <link>https://sizu.me/miraoto/posts/bmk370rx9tus</link>
            <guid>https://sizu.me/miraoto/posts/bmk370rx9tus</guid>
            <pubDate>Fri, 15 May 2026 03:04:06 GMT</pubDate>
            <description><![CDATA[良いエンジニアは、知識量やセンスだけで突然生まれるわけではなく、ある程度の「時間」と「主体的な経験」の積み重ねによって形づくられるのだと思うことが増えてきた。
AIによって調べる速度は上がったし、実装の初速もかなり変わった。ただ、それでも最終的に差になるのは、「なぜその設計にしたのか」「どこで壊れやすくなるのか」「どの判断を後から後悔したのか」「何を諦め、何を守ったのか」みたいな、実際に責任を持っ…]]></description>
            <enclosure length="0" type="image/png" url="https://static.sizu.me/api/og-image/fdb544d4d2ba?theme=user&amp;username=miraoto"/>
        </item>
        <item>
            <title><![CDATA[AI時代の開発チームでいま起きていること]]></title>
            <link>https://sizu.me/miraoto/posts/wnia339hv59k</link>
            <guid>https://sizu.me/miraoto/posts/wnia339hv59k</guid>
            <pubDate>Mon, 11 May 2026 06:34:26 GMT</pubDate>
            <description><![CDATA[AIで作業の摩擦が減るほど、チームのボトルネックは別の場所に移っていく。仕様の言語化、設計の見立て、レビューの役割分担、引き継ぎ、そして保守。ここ最近の1on1や雑談で聞いた話を手がかりに、AI時代の開発チームに起きやすい特徴をメモとしてまとめる
アウトプットは増えるが、品質・保守性のリスクも増える（身の丈に合わない実装、評価できないコードが増えやすい）
「コードを読まない/見ない」前提が進み、抜…]]></description>
            <enclosure length="0" type="image/png" url="https://static.sizu.me/api/og-image/fdb544d4d2ba?theme=user&amp;username=miraoto"/>
        </item>
        <item>
            <title><![CDATA[目標を達成する意味を理解して目標を立てる]]></title>
            <link>https://sizu.me/miraoto/posts/2cze0ot25a1b</link>
            <guid>https://sizu.me/miraoto/posts/2cze0ot25a1b</guid>
            <pubDate>Wed, 06 May 2026 02:15:58 GMT</pubDate>
            <description><![CDATA[いきなりかなり身も蓋もない話をすると、 目標を設定して達成すると、だいたい次のことが起こる。
給料が増える
成長する
裁量が増える
逆に言うと、この3つすべてが見込めない目標は、 あまり良い目標ではない可能性が高い。目標は「やることリスト」ではなく、 自分の働き方や役割を前に進めるためのものだから。
理想的にはこの3つすべてが見込める目標。 少なくとも2つは見込める状態。
とはいえ、これは評価のタ…]]></description>
            <enclosure length="0" type="image/png" url="https://static.sizu.me/api/og-image/fdb544d4d2ba?theme=user&amp;username=miraoto"/>
        </item>
        <item>
            <title><![CDATA[役割は、与えられただけでは機能しない]]></title>
            <link>https://sizu.me/miraoto/posts/55d36dc6x0hs</link>
            <guid>https://sizu.me/miraoto/posts/55d36dc6x0hs</guid>
            <pubDate>Tue, 05 May 2026 15:00:00 GMT</pubDate>
            <description><![CDATA[役割は、認知されてはじめて意味を持つ。
その認知は、肩書きではなく、引き受けている裁量と責任の積み重ねから生まれる。
少し前までは、役割は「与えられるもの」だと思っていた。任命されて、名前がついて、その瞬間からその役割になる、みたいな。
でも実際には、そういうものではなかった。
役割は、与えられただけでは機能しない。周囲が「この人がその役割を担っている」と認識して、はじめて立ち上がる。
だから、役…]]></description>
            <enclosure length="0" type="image/png" url="https://static.sizu.me/api/og-image/fdb544d4d2ba?theme=user&amp;username=miraoto"/>
        </item>
        <item>
            <title><![CDATA[AIのある開発で、まだ名前のついていない感覚]]></title>
            <link>https://sizu.me/miraoto/posts/hkz3rdoh7sft</link>
            <guid>https://sizu.me/miraoto/posts/hkz3rdoh7sft</guid>
            <pubDate>Mon, 04 May 2026 22:41:01 GMT</pubDate>
            <description><![CDATA[気づけば、AIを前提に開発することが当たり前になってきた。
実装は以前よりも軽くなって、試せることは確実に増えている。 その一方で、何をもって「よい状態」とするのか、少しわかりづらくなった気もしている。
できることが増えたはずなのに、 考えることはむしろ増えているような感覚がある。
まだうまく言葉にはできていないけれど、 最近感じていることを、そのまま残しておく。
AIの変化について、ポジティブに…]]></description>
            <enclosure length="0" type="image/png" url="https://static.sizu.me/api/og-image/fdb544d4d2ba?theme=user&amp;username=miraoto"/>
        </item>
        <item>
            <title><![CDATA[組織にとって良いサービスとは何か]]></title>
            <link>https://sizu.me/miraoto/posts/r62idto76fbe</link>
            <guid>https://sizu.me/miraoto/posts/r62idto76fbe</guid>
            <pubDate>Mon, 06 Apr 2026 23:47:11 GMT</pubDate>
            <description><![CDATA[サービスの良し悪しは、ユーザーにとっての価値で語られることが多い。
それは間違っていないのだけど、 実際にそれを作り、運び、持ち続ける側の視点に立つと、少し違う輪郭が見えてくる。
どれだけ価値があっても、持ち続けられないサービスは長く残らない。 そして、組織は「持ち続けること」によって静かに疲弊していく。
普段、最近考えていることをいくつかの観点で整理してみる
持ち物が少ないこと
サービスは作った…]]></description>
            <enclosure length="0" type="image/png" url="https://static.sizu.me/api/og-image/fdb544d4d2ba?theme=user&amp;username=miraoto"/>
        </item>
        <item>
            <title><![CDATA[オーナーシップとはなにか？]]></title>
            <link>https://sizu.me/miraoto/posts/59kkrimb0o5a</link>
            <guid>https://sizu.me/miraoto/posts/59kkrimb0o5a</guid>
            <pubDate>Tue, 10 Mar 2026 01:26:35 GMT</pubDate>
            <description><![CDATA[※ この文章は校正以外でAIを使っていません
「チームメンバーにもっとオーナーシップを持ってほしい」とか、「昔はもっとオーナーシップがあった」みたいな話をたまに聞くので、オーナーシップとはどういうもので、それはどうすれば獲得できるのかをつらつら書いてみた。
オーナーシップとは？
いろいろな定義があると思うが、ここで言うオーナーシップは以下とする。
”組織において従業員が業務を自らの所有物のように主…]]></description>
            <enclosure length="0" type="image/png" url="https://static.sizu.me/api/og-image/fdb544d4d2ba?theme=user&amp;username=miraoto"/>
        </item>
        <item>
            <title><![CDATA[過去うまくいった仕組みを、別の場所に持っていくときに考えていること]]></title>
            <link>https://sizu.me/miraoto/posts/0bxvnkm8dr5x</link>
            <guid>https://sizu.me/miraoto/posts/0bxvnkm8dr5x</guid>
            <pubDate>Mon, 23 Feb 2026 14:48:58 GMT</pubDate>
            <description><![CDATA[過去にうまくいった取り組みは、つい別の場所でも使いたくなるので、自責の念も込めてまとめておく
仕組みではなく「成立条件」を持っていく
うまくいった理由は、 仕組みそのものの優秀さではないことが多い。
たまたま意思決定者が参加していた
ちょうど痛みが共有されていた
改善の権限がその場にあった
目標・背景がシンプルだった
つまり、その仕組みが機能していたのは、成立するための条件が揃っていたからだったり…]]></description>
            <enclosure length="0" type="image/png" url="https://static.sizu.me/api/og-image/fdb544d4d2ba?theme=user&amp;username=miraoto"/>
        </item>
        <item>
            <title><![CDATA[遠くに行くためには、遅くなることに寛容でなければならない。
早く遠くに行くことはできない。]]></title>
            <link>https://sizu.me/miraoto/posts/i0zze8a81azk</link>
            <guid>https://sizu.me/miraoto/posts/i0zze8a81azk</guid>
            <pubDate>Mon, 23 Feb 2026 14:37:50 GMT</pubDate>
            <description><![CDATA[「早く行くなら一人で行け。遠くに行くならみんなで行け」ということわざがある。
遠くに行くためには、遅くなることに寛容でなければならない。早く遠くに行くことはできない。そういうことを言っているのだと思っていた。
けれど、一般的には、「早く遠くに行きたい」という期待が見え隠れすることがある。
できることなら、その両方を取りたい。でも、速さという点では、やはり一人の方が有利だ。
判断が速く、迷いがなく、…]]></description>
            <enclosure length="0" type="image/png" url="https://static.sizu.me/api/og-image/fdb544d4d2ba?theme=user&amp;username=miraoto"/>
        </item>
        <item>
            <title><![CDATA[過去決めた基準や計画に今従うことの難しさについて]]></title>
            <link>https://sizu.me/miraoto/posts/8ed4wxt4xs4s</link>
            <guid>https://sizu.me/miraoto/posts/8ed4wxt4xs4s</guid>
            <pubDate>Fri, 23 Jan 2026 03:22:23 GMT</pubDate>
            <description><![CDATA[この辺りを見た感想。
自分たちは日々、意思決定や活動の基準・計画を「決める」ことで未来の行動を最適化しようとする。しかし、過去に策定した基準や計画をそのまま使い続けることには、構造的な困難がある。
これは単なる「守るべきルール vs 柔軟性」といった二元論に留まる問題ではなく、組織・チーム・個人が変化する環境にどう対応するかという本質的な課題に直結している。
過去の基準は「判断の節約装置」である
…]]></description>
            <enclosure length="0" type="image/png" url="https://static.sizu.me/api/og-image/fdb544d4d2ba?theme=user&amp;username=miraoto"/>
        </item>
        <item>
            <title><![CDATA[開発における慣習負債について]]></title>
            <link>https://sizu.me/miraoto/posts/wn7exvhmi55w</link>
            <guid>https://sizu.me/miraoto/posts/wn7exvhmi55w</guid>
            <pubDate>Wed, 17 Dec 2025 06:42:32 GMT</pubDate>
            <description><![CDATA[「一般的にはこうなっているはず」という前提が、 そのプロダクトや組織ではまったく当てはまらない状態。
APIの設計、ディレクトリ構成、権限の考え方、運用フロー。 どれも一つ一つは理由があって、動いてもいる。 でも、一般的な慣習からはズレている。
その結果、何が起きるかというと──
経験者が、経験者として振る舞えない
過去の知識やスキルが、そのまま使えない
キャッチアップはできるけど、判断に手応えが…]]></description>
            <enclosure length="0" type="image/png" url="https://static.sizu.me/api/og-image/fdb544d4d2ba?theme=user&amp;username=miraoto"/>
        </item>
        <item>
            <title><![CDATA[答えを投げるな。問いを投げろ]]></title>
            <link>https://sizu.me/miraoto/posts/xhb24v5n7us3</link>
            <guid>https://sizu.me/miraoto/posts/xhb24v5n7us3</guid>
            <pubDate>Mon, 08 Dec 2025 15:01:01 GMT</pubDate>
            <description><![CDATA[AI時代になって、世界は“答え”で溢れかえっている。たいていのことは、AIに聞けばすぐに構造化された情報として返ってくるし、整理された知識も、ベストプラクティスらしきものにも、検索すら要らず手元に届くようになった。
ただ、その整った答えを前にしても、心が動かないことがある。「なるほどね」で終わってしまう。熱量が生まれない。
自分的に、答えはプロセスの副産物で、興味があるのは試行錯誤とか、失敗とか、…]]></description>
            <enclosure length="0" type="image/png" url="https://static.sizu.me/api/og-image/fdb544d4d2ba?theme=user&amp;username=miraoto"/>
        </item>
        <item>
            <title><![CDATA[開発者体験の良い環境は学習意欲を促す]]></title>
            <link>https://sizu.me/miraoto/posts/66r1d8itrwxw</link>
            <guid>https://sizu.me/miraoto/posts/66r1d8itrwxw</guid>
            <pubDate>Mon, 08 Dec 2025 01:17:49 GMT</pubDate>
            <description><![CDATA[と思った。]]></description>
            <enclosure length="0" type="image/png" url="https://static.sizu.me/api/og-image/fdb544d4d2ba?theme=user&amp;username=miraoto"/>
        </item>
        <item>
            <title><![CDATA[AIが書いたコードをレビューする際、最も重要なのは、コードそのものよりも「モデリング」が正しく行われているかどうか]]></title>
            <link>https://sizu.me/miraoto/posts/2366se8uce2t</link>
            <guid>https://sizu.me/miraoto/posts/2366se8uce2t</guid>
            <pubDate>Wed, 26 Nov 2025 14:42:40 GMT</pubDate>
            <description><![CDATA[この動画が色々よかったので自分なりに最近の体験含めまとめておく。
TL;DR
AI が生成したコードは“動くかどうか”より、そもそも “どんなデータ構造・責務分割・境界” を想定して作られたか＝モデリングが正しいかの方が重要
AI は「それっぽいコード」は書けるが、正しい構造を作る能力は弱い
AI は syntax や API 呼び出しは綺麗に書けるが、
データ構造どうする？
境界（責務）どこで切…]]></description>
            <enclosure length="0" type="image/png" url="https://static.sizu.me/api/og-image/fdb544d4d2ba?theme=user&amp;username=miraoto"/>
        </item>
        <item>
            <title><![CDATA[開発における「直列の生産性」と「並列の生産性」について]]></title>
            <link>https://sizu.me/miraoto/posts/86twxh67z403</link>
            <guid>https://sizu.me/miraoto/posts/86twxh67z403</guid>
            <pubDate>Tue, 11 Nov 2025 06:02:56 GMT</pubDate>
            <description><![CDATA[最近ふと思ったので、忘れないようにメモしておく
それぞれの定義
直列の生産性：自分やチームが待たされる時間を減らすこと（ビルド・CI・レビュー待ち・承認）
→ “同じ列に並ぶ人を速く流す”。測る対象はサイクルタイムの内訳。DORAで言うLead Time for Changesに強く効く。
並列の生産性：ブロックなく同時に前へ進める能力（プレビュー環境、ローカル本番同等、分離されたDB/キュー、権…]]></description>
            <enclosure length="0" type="image/png" url="https://static.sizu.me/api/og-image/fdb544d4d2ba?theme=user&amp;username=miraoto"/>
        </item>
        <item>
            <title><![CDATA[技術負債を「構造・文化・運用」の3層で考える]]></title>
            <link>https://sizu.me/miraoto/posts/5ikhdmnuszem</link>
            <guid>https://sizu.me/miraoto/posts/5ikhdmnuszem</guid>
            <pubDate>Fri, 07 Nov 2025 05:52:46 GMT</pubDate>
            <description><![CDATA[脳内整理メモ。技術負債に関する認識を整理した
技術負債の主な影響
技術負債には大きく3つの側面がある
プロダクト価値の制約
新機能開発や改善の選択肢が狭まり、「やりたいことが実現できない」状態を生む。 結果として、ユーザーへの価値提供スピードや質に直接的な影響が出る。
障害・不具合の発生 
設計や実装上の負債が原因で、予期せぬ障害が発生するリスクが高まる。 　信頼性や安定性が損なわれ、対応コストも…]]></description>
            <enclosure length="0" type="image/png" url="https://static.sizu.me/api/og-image/fdb544d4d2ba?theme=user&amp;username=miraoto"/>
        </item>
        <item>
            <title><![CDATA[バイブコーディングを運用中のコードに適用してみた]]></title>
            <link>https://sizu.me/miraoto/posts/hcazcdruxr9x</link>
            <guid>https://sizu.me/miraoto/posts/hcazcdruxr9x</guid>
            <pubDate>Tue, 04 Nov 2025 02:15:47 GMT</pubDate>
            <description><![CDATA[実装を進めるだけなら普通に開発したほうが早いが、書いて動かして直すまでのサイクルが少し重くなる分、コードの理解は深まる。既存の設計に合わせる手間もあるものの、「なぜこのコードがこうなっているのか」を丁寧に読み解くきっかけになる。
コードを単なる修正対象としてではなく、意図を読み取る対象として扱える感覚がある。 キャッチアップやリファクタリングの入口としては有効で、「進めるための開発」ではなく「理解…]]></description>
            <enclosure length="0" type="image/png" url="https://static.sizu.me/api/og-image/fdb544d4d2ba?theme=user&amp;username=miraoto"/>
        </item>
        <item>
            <title><![CDATA[新しい職場・新しい上司・新しい文化で効果的に動くためのチェックリスト]]></title>
            <link>https://sizu.me/miraoto/posts/rev8h4vxu8zs</link>
            <guid>https://sizu.me/miraoto/posts/rev8h4vxu8zs</guid>
            <pubDate>Thu, 09 Oct 2025 14:34:59 GMT</pubDate>
            <description><![CDATA[何はともあれまずはメンタル
意図: 長期的にパフォーマンスを発揮できる心の土台を整える。
過去の自分や他者と比較しない（比較は成長ではなく焦りを生む）
「今の自分ができること」に集中する
周囲のスピードに焦らず、自分のリズムを見失わない
失敗を「評価の終わり」ではなく「学習の始まり」と捉える
不安や疑問は抱え込まず、早めに言語化して相談する
批判ではなく「事実ベースの自己観察」を心がける
自分を責…]]></description>
            <enclosure length="0" type="image/png" url="https://static.sizu.me/api/og-image/fdb544d4d2ba?theme=user&amp;username=miraoto"/>
        </item>
        <item>
            <title><![CDATA[システムアーキテクチャの成功は何で測るか？]]></title>
            <link>https://sizu.me/miraoto/posts/9ks83eiv5b6d</link>
            <guid>https://sizu.me/miraoto/posts/9ks83eiv5b6d</guid>
            <pubDate>Wed, 08 Oct 2025 13:22:40 GMT</pubDate>
            <description><![CDATA[メモ程度に
TL;DR
事業の変化に追従しながら、安定性・効率性・経済合理性を両立する状態
1. ビジネス適合性
アーキテクチャは事業の変化に追従できているか？
開発スピード／リードタイム：新機能を出すまでの時間が短縮されたか
変更コスト：仕様変更やA/Bテスト対応の負担が減ったか
スケーラビリティ：利用者やデータ量の増加に耐えられる設計になっているか
ビジネス要件の適応性：新しいビジネスモデル・…]]></description>
            <enclosure length="0" type="image/png" url="https://static.sizu.me/api/og-image/fdb544d4d2ba?theme=user&amp;username=miraoto"/>
        </item>
        <item>
            <title><![CDATA[こんなリーダーと働きたい]]></title>
            <link>https://sizu.me/miraoto/posts/x94hfirv9c14</link>
            <guid>https://sizu.me/miraoto/posts/x94hfirv9c14</guid>
            <pubDate>Thu, 04 Sep 2025 08:13:31 GMT</pubDate>
            <description><![CDATA[ひとことで言うと「普段は任せ、必要なときは守り、最後は背負う」
安心できる
心理的な拠り所になり、メンバーが不安を感じても落ち着いて任せられる存在
リリース直前に重大なバグが見つかったときに、慌てず「大丈夫、リリース日をずらす判断も含めて一緒に考えよう」と声をかけ、メンバーの焦りを和らげる
決断できる
曖昧な状況でも迷い続けず、責任を持って適切な判断を下せる
新しいライブラリを採用するかどうか議論…]]></description>
            <enclosure length="0" type="image/png" url="https://static.sizu.me/api/og-image/fdb544d4d2ba?theme=user&amp;username=miraoto"/>
        </item>
    </channel>
</rss>