Essays by shiimaxx, beneath the surface. 2026-04-22T00:00:00+00:00 https://shiimaxx.com/writing/feed.xml 2026-04-22T00:00:00+00:00 2026-04-22T00:00:00+00:00 https://shiimaxx.com/writing/constraints-as-guide/ <p>自動化の価値は単なる作業の省力化だけではありません。自動化が利用者にとってじゅうぶんに効果的であるとき、その自動化がもつ合理的な制約が、システム全体に対してまた別の価値をもたらすことがあります。</p> <h2 id="dbinpototurunozhi-yue-gasisutemugou-cheng-nobiao-zhun-hua-wocu-su">DBインポートツールの制約がシステム構成の標準化を促す<a class="zola-anchor" href="#dbinpototurunozhi-yue-gasisutemugou-cheng-nobiao-zhun-hua-wocu-su" aria-label="Anchor link for: dbinpototurunozhi-yue-gasisutemugou-cheng-nobiao-zhun-hua-wocu-su" style="visibility: hidden;"></a> </h2> <p>最近、私の同僚が、技術支援を担当している顧客向けに本番データベースから開発環境にデータを取り込むDBインポートツールを開発しました。本番データを抽出し、機密情報をマスキングしたうえで、開発環境にデータを投入する一連の作業を自動化したものです。この作業は元々SREチームが開発チームからの依頼を受けて手動で実施しており、依頼ごとの作業負担が大きいことが問題になっていました。</p> <p>DBインポートツールの導入後、ツールの利用方法に関する興味深いやり取りがおきました。</p> <p>きっかけは、開発チームから「DBインポートツールで、本番データを開発環境にあるEC2インスタンス内のMySQLにリストアしたい」という依頼がきたことですが、SREチームは、保守性の観点からこの依頼への対応は見送るべきだと考えていました。DBインポートツールは複製先としてマネージドサービス（RDS/Aurora）を前提にして開発したものです。EC2インスタンス内のMySQLへのリストアをサポートするにはツールの改修が必要ですが、一方でこれは例外的な構成なので、積極的にサポートすることは避けたかったためです。</p> <p>そこでSREチームは、依頼に対してこのような提案をしました。「DBインポートツールを利用できるように、EC2インスタンス内のMySQLをRDSに移行してもらえませんか」</p> <p>注目したいのは、この提案がSREチームと開発チームの双方にとってメリットがある内容になっていることです。SREチームは、例外的な構成をサポートするためのツール改修をする必要がなくなり、またシステムを標準的な構成に移行できます。開発チームは、移行に取り組むことでDBインポートツールが使えるようになり、従来SREチームに依頼する必要があった作業をセルフサービスで実施できるようになります。</p> <p>この出来事は、以前読んだあるブログを連想させました。</p> <h2 id="zi-dong-rihuakutaringusisutemunozhi-yue-gakodobesunopin-zhi-xiang-shang-wocu-su-spotifynoshi-li">自動リファクタリングシステムの制約がコードベースの品質向上を促す（Spotifyの事例）<a class="zola-anchor" href="#zi-dong-rihuakutaringusisutemunozhi-yue-gakodobesunopin-zhi-xiang-shang-wocu-su-spotifynoshi-li" aria-label="Anchor link for: zi-dong-rihuakutaringusisutemunozhi-yue-gakodobesunopin-zhi-xiang-shang-wocu-su-spotifynoshi-li" style="visibility: hidden;"></a> </h2> <p>Spotifyのブログ記事『<a rel="nofollow noreferrer external" href="https://engineering.atspotify.com/2023/05/fleet-management-at-spotify-part-3-fleet-wide-refactoring">Fleet Management at Spotify (Part 3): Fleet-wide Refactoring</a>』で紹介されていた事例です。このブログ記事は、Spotifyが抱える何千ものコンポーネント（Fleet: 艦隊）をいかに効率よく管理しているかを紹介するブログシリーズのひとつで、Fleet全体に対する横断的なリファクタリング（Fleet-wide Refactoring）を効果的に行うための仕組みを紹介しています。</p> <p>Fleet-wide Refactoringの中核を担うのは、任意のリファクタリングをFleet全体にプルリクエストとして展開したうえで自動マージする仕組みです。</p> <p>注目したいのは、自動マージを有効にするためには、対象のコードベースでテストが十分に整備されていることが条件となることです。これは不適切な変更の混入を防ぐためにプラットフォーム側がかけた制約ですが、同時にコンポーネントの所有チームが自律的にコードベースの品質を改善する強力なインセンティブとしても機能しています。コードベースの品質を改善することで、Fleet-wide Refactoringの恩恵（自動マージによる省力化）を最大限に享受できるためです。</p> <h2 id="zi-dong-hua-nozhi-yue-gasisutemuwowang-masiifang-xiang-niyou-dao-surugaidoninaru">自動化の制約がシステムを望ましい方向に誘導するガイドになる<a class="zola-anchor" href="#zi-dong-hua-nozhi-yue-gasisutemuwowang-masiifang-xiang-niyou-dao-surugaidoninaru" aria-label="Anchor link for: zi-dong-hua-nozhi-yue-gasisutemuwowang-masiifang-xiang-niyou-dao-surugaidoninaru" style="visibility: hidden;"></a> </h2> <p>システムや組織の規模は大きく異なる事例ですが、どちらも自動化がもつ制約がシステム全体を望ましい方向に誘導する役割を担っていたと捉えられます。自動化が利用者にとってじゅうぶん効果的な仕組みであったため、利用者は制約を受け入れる動機がありました。また、その制約はシステムの観点で合理的なものでした。その結果、人々が制約を受け入れることはシステム全体を望ましい方向に向かわせることになりました。</p> <p>もちろんあらゆるケースでうまくいくようなことではありません。自動化のメリットよりも制約を受け入れるコストが上回る場合には、利用者が制約を受け入れるインセンティブが生まれず、自動化の導入が見送られるでしょう。</p> <p>制約をシステムを望ましい方向に誘導するガイドとして捉え直し、ガイドが機能するバランスを見極めることが、自動化戦略において重要なひとつの要素になります。</p> 2025-12-04T00:00:00+00:00 2025-12-04T00:00:00+00:00 https://shiimaxx.com/writing/rebuilding-my-website/ <p>このウェブサイト（shiimaxx.com）を再構築しました。元々は自分が外部サービスに書いた記事の一覧を表示するだけの簡素なものだったのですが、今後はこのウェブサイト自体にもコンテンツを載せられるようにしました。 最近になって文章を書くことに対して興味が湧いてきて、自分用の書くための場所がほしくなったというのが理由です。</p> <p>元々はNext.jsのStatic Site Generationベースで作っていました。ビルド時に自作Web APIから自分が書いた記事情報を取ってきてレンダリングするという仕組みです。Web APIはApp Engineでホスティングしていました。</p> <p>前述した理由もあってウェブサイトを作り直すことにしたのですが、ウェブサイト自体のメンテナンスにあまり時間をとれないということもありStatic Site Generatorを使うことにしました。</p> <p>具体的にはZolaというStatic Site Generatorを使っています。ChatGPTで「Static Site Generator 2025」をリストアップしてもらいつつ、自分の用途にあっていそうなものに絞り込んでいったところ、最終的にEleventyとZolaが候補になりました。Rust製でCLIベースで操作できるというところに惹かれたのと、今使っているSereneというテーマがシンプルで自分のイメージにあっていたという理由でZolaを使うことにしました。</p> <p>Sereneにはリアクション機能があり、バックエンドAPIを自分で用意すれば記事ページにリアクションボタンを設置できます（このページの右下に表示されているやつです）。 いくつかリファレンス実装もあったのですが、せっかくなので触ってみたいなと思っていたHonoを使ってバックエンドAPIを実装してみました。自分で書いたコードがまったくないというのも少しさみしいなと思っていたので、ちょうどよい規模感でコードが書ける余地があってよかったです。</p> <p>ホスティングにはCloudflareを使っていて、静的コンテンツの配信はPages、リアクション機能用のバックエンドAPIはPages Functions、バックエンドAPIで使うデータストアはWorkers KVを使っています。</p>