<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Logs on sivchari</title><link>https://sivchari.dev/ja/logs/</link><description>Recent content in Logs on sivchari</description><image><title>sivchari</title><url>https://sivchari.dev/images/ogp.png</url><link>https://sivchari.dev/images/ogp.png</link></image><generator>Hugo -- 0.154.5</generator><language>ja</language><lastBuildDate>Mon, 01 Jun 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://sivchari.dev/ja/logs/index.xml" rel="self" type="application/rss+xml"/><item><title>Kubernetes Contributor Award 2025 をいただきました</title><link>https://sivchari.dev/ja/logs/kubernetes-contributor-award-2025/</link><pubDate>Mon, 01 Jun 2026 00:00:00 +0000</pubDate><guid>https://sivchari.dev/ja/logs/kubernetes-contributor-award-2025/</guid><description>&lt;p&gt;&lt;a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/"&gt;KubeCon + CloudNativeCon North America 2025&lt;/a&gt; にて、SIG Cluster Lifecycle から &lt;a href="https://www.kubernetes.dev/community/awards/2025/"&gt;Kubernetes Contributor Award 2025&lt;/a&gt; をいただきました。受賞理由には「being always available to help and for the impact he made in the Cluster API project」と書いていただきました。とても嬉しい一方で、自分がこれまで何をしてきたのかを振り返る良い機会だったので、受賞につながった活動と、そこで自分が学んだことを書き残しておきます。&lt;/p&gt;
&lt;p&gt;&lt;img alt="Maintainer Summit での Kubernetes Contributor Award 2025 授賞の様子。スクリーンに「Takuma Shibuya / SIG Cluster Lifecycle」と受賞理由が映し出されている" loading="lazy" src="https://sivchari.dev/images/logs/kubernetes-contributor-award-2025.jpg"&gt;&lt;/p&gt;
&lt;h2 id="受賞につながった活動"&gt;受賞につながった活動&lt;/h2&gt;
&lt;p&gt;僕が SIG Cluster Lifecycle で取り組んできたことは、大きく分けて 2 つあります。&lt;/p&gt;
&lt;h3 id="kube-api-linter"&gt;Kube API Linter&lt;/h3&gt;
&lt;p&gt;ひとつは &lt;a href="https://github.com/kubernetes-sigs/kube-api-linter"&gt;Kube API Linter (KAL)&lt;/a&gt; です。KAL は Kubernetes の &lt;a href="https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md"&gt;API 規約&lt;/a&gt; や、規約にないルールも含めて API をチェック・強制する linter です。&lt;/p&gt;
&lt;p&gt;僕の最初の関わりは、2025 年の初めに &lt;code&gt;nomaps&lt;/code&gt; linter を追加した &lt;a href="https://github.com/kubernetes-sigs/kube-api-linter/pull/41"&gt;PR #41&lt;/a&gt; でした。そこから &lt;code&gt;duplicatemarkers&lt;/code&gt;、&lt;code&gt;ssatags&lt;/code&gt;、&lt;code&gt;defaults&lt;/code&gt; といった linter を継続的に追加し、やがて reviewer に、そして &lt;a href="https://github.com/kubernetes-sigs/kube-api-linter/pull/190"&gt;approver&lt;/a&gt; に加えていただきました。&lt;/p&gt;</description></item><item><title>Go Conference mini in Sendai 2026 で登壇しました</title><link>https://sivchari.dev/ja/logs/sendai-go-2026/</link><pubDate>Sat, 21 Feb 2026 00:00:00 +0000</pubDate><guid>https://sivchari.dev/ja/logs/sendai-go-2026/</guid><description>&lt;p&gt;2026 年 2 月 21 日に &lt;a href="https://sendaigo.jp/"&gt;Go Conference mini in Sendai 2026&lt;/a&gt; が開催されました。僕は「Who tests the Tests ?」というタイトルで登壇し、参加者としてもセッションや懇親会を楽しんできました。とても楽しかったので、イベント全体の雰囲気、自身の発表内容、仙台でのコミュニティとの交流について書き残しておきます。&lt;/p&gt;
&lt;h2 id="僕と-sendaigo"&gt;僕と Sendai.go&lt;/h2&gt;
&lt;p&gt;僕にとって Sendai.go は特別な意味を持つカンファレンスです。というのも、生まれてはじめて現地参加したオフラインカンファレンスが Go Conference mini 2022 Autumn IN SENDAI だったからです。学生の頃からGo Conference に登壇していましたが、当時はまだコロナが少しずつ落ち着いてきたかなといった時代だったこともあり登壇は全てオンラインで行っていました。オフラインで登壇をすると、発表を本当に聞かれている、リアクションしてくれるというオンライン上では感じ取り辛いライブ感が加わりとても楽しかったことを覚えています。&lt;/p&gt;
&lt;p&gt;その場で交わした会話や紹介してもらった人たちとのつながりは、その後のカンファレンスや OSS 活動を通じて現在まで続いています。Go Conference の運営に関わるようになり、メインオーガナイザーになったことも、そのテーマを「一期一会」にしたことも、Kubernetes や Argo CD のメンテナーとして活動するようになったことも、あのときの一歩が出発点でした。&lt;/p&gt;
&lt;p&gt;そうした個人的な原点とも呼べる場所に、4 年後の 2026 年に登壇者として戻ってくることができたのは、非常に感慨深い出来事でした。&lt;/p&gt;
&lt;h2 id="登壇-who-tests-the-tests-"&gt;登壇: Who tests the Tests ?&lt;/h2&gt;
&lt;p&gt;僕のセッションでは、Mutation Testing と、それを Go 向けに実装した OSS ツール &lt;a href="https://github.com/sivchari/gomu"&gt;gomu&lt;/a&gt; について発表しました。スライドは &lt;a href="https://speakerdeck.com/sivchari/who-tests-the-tests"&gt;SpeakerDeck&lt;/a&gt; で公開しています。&lt;/p&gt;
&lt;h3 id="発表の趣旨"&gt;発表の趣旨&lt;/h3&gt;
&lt;p&gt;近年の開発では AI エージェントによるコード生成とテスト生成が急速に普及しています。人間が書いたコードも AI が書いたコードも、最終的に品質を担保するガードレールは CI であり、その中核にあるのがテストです。しかし「テストが存在すること」と「テストが意味のある検証をしていること」は別の問題です。&lt;/p&gt;
&lt;p&gt;従来、テストの品質指標としては Code Coverage が広く使われてきました。しかし Goodhart&amp;rsquo;s Law &amp;ndash; 「ある指標が目標になると、その時点でその指標は良い指標ではなくなる」&amp;ndash; が示すとおり、カバレッジを追い求めると、assertion を書かずにコードを通過するだけの形骸化したテストが生まれてしまいます。AI エージェントにテスト生成を任せると、&lt;code&gt;t.Skip&lt;/code&gt; を使って実質的に何も検証していないテストを生成されるケースすら存在します。&lt;/p&gt;</description></item></channel></rss>