はじめに
年末、2025年を振り返る。フォロワーは7倍になった。副業も順調。書籍の執筆や翻訳にも関わった。登壇の依頼も増えた。どこからどう見ても、良い年だったはずだ。
なのに、胸の奥に澱のようなものが溜まっている。
コードは書いた。山ほど書いた。でもそれは、誰かに頼まれたコードだ。お金になるコード。評価されるコード。「これを作ってください」と言われて、「はい」と答えて、作ったコード。自分のためのOSSも、作った。公開もした。そこそこ使われもした。
でも、そこそこ止まりだ。「これが俺の代表作です」と言えるものが、ない。スターはついた。ダウンロードもされた。いくつかは今でも自分で使っている。完走した。自分なりに頑張った。でも、「代表作」と呼べるインパクトには届かなかった。
厄介なことに、nwiizoというアカウントは大きくなってしまった。フォロワーが増えた分、「代表作」のハードルも上がっている。昔なら「動くものを公開した」で満足できた。今は違う。期待値が上がった分、自分で自分の首を絞めている。
でも、諦めたくない。代表作を持つソフトウェアエンジニアに憧れて、この道に入った。あの人みたいになりたい、と思った先輩たちがいる。彼らのようにはなれていない。でも、まだ諦めたくない。
新しいプロジェクトを始めようとするたび、手が止まる。「既存のツールで十分じゃないか」「誰が使うんだ、これ」。もっともらしい問いを自分に投げかけて、そのまま手を下ろす。完走したプロジェクトはある。でも、次の一歩が踏み出せない。検証のふりをした、逃避だ。「作らなくていい理由」を探して、見つけて、安心している。
AIは「どう作るか」を教えてくれる。でも「何を作るか」は教えてくれない。技術力はもうボトルネックじゃない。足りないのは、決断だ。覚悟だ。「これを作る」と宣言して、不確実性の中に飛び込む蛮勇だ。
私は「隙間家具屋」を自称してきた。大きな家具は作らない。洗濯機と壁の間の収納。冷蔵庫の上のラック。誰も気にしないけれど、あると少し楽になる小さなもの。それを作るのが好きだった。はずだった。
2025年、隙間を見つける目は曇っていなかった。手も動いた。完走もした。でも、「これだ」という手応えが残らなかった。
副業は収入になる。登壇は評価される。ブログはフォロワーが増える。全部、目に見えるリターンがある。OSSは違う。作っても誰にも使われないかもしれない。時間を注いでも、何も返ってこないかもしれない。その「かもしれない」に怯えて、私は確実なほうへ流れやすかった。OSSは作った。完走もした。でも、賭け金を上げられなかった。時間を注ぎ込むより、確実なリターンがある副業や登壇に逃げた。結果、そこそこ止まり。「これだ」と言えるものは掴めなかった。
問題は、才能がないことだけじゃない。問題は、狂えなかったことだ。
どこにも振り切れなかった。副業も、登壇も、OSSも、全部やりたかった。全部にいい顔をして、どれにも本気を出せなかった。半端な賭け金には、半端なリターンしか返ってこない。当たり前のことだ。
このブログでは、「狂って量をやって、そこから引き算する」ための思考法を書く。
結論を先に言う。まず狂え。量をやれ。そして、量が満ちたら、容赦なく削れ。
ポジティブケイパビリティとネガティブケイパビリティ
「ネガティブ・ケイパビリティ」という概念がある。不確実さ、不思議さ、疑いの中に、結論を急がずに留まる能力のことだ。
これに対して、「ポジティブ・ケイパビリティ」というのもある。問題を分析し、解決策を導き、実行する能力だ。ゴールが明確なときに発揮される力。私はおそらくだがこれが得意だ。
生成AIは、ポジティブケイパビリティを劇的に強化した。「このAPIを叩いて、結果をパースして、DBに保存するコードを書いて」と指示すれば、動くコードが出てくる。「このエラーメッセージの原因を調べて」と頼めば、調査結果が返ってくる。ゴールが明確なタスクは、AIとの協働で驚くほど速く片付く。
私の2025年は、まさにこれだった。仕事のコードは書けた。クライアントから「これを作ってほしい」と言われれば、作れた。締め切りがあり、要件があり、ゴールが明確なタスクは、以前より速く終わるようになった。
しかし、ネガティブケイパビリティは強化されなかった。むしろ、弱体化した気もする。 以前なら、分からないまま3日間コードを書き続けることができた。今は、30分詰まるとAIに聞いてしまう。「分からない」という状態に耐える筋力が、確実に落ちている。
OSS開発には、ネガティブケイパビリティが必要だ。「何を作るか」は誰も教えてくれない。「これが正解」という保証はない。作っている途中で「これは違うかも」と思うことがある。それでも手を動かし続ける。完成するかどうか分からない。使われるかどうか分からない。その不確実さの中に留まり続ける力。
生成AIに「何を作るべきか」と聞いても、答えは出ない。AIは優秀なアシスタントだが、ゴールを設定するのは人間の仕事だ。
ゴールが明確な仕事が速く片付くようになった結果、私の中で奇妙なことが起きた。「答えがすぐに出る」ことに慣れてしまった。 仕事では、AIに聞けば数分で方向性が見える。それに慣れた脳は、「答えが出ない状態」に耐えられなくなっている。
では、どうすれば不確実さに耐えられるのか。いくつかの仮説がある。ゴールを小さくする（「Kubernetesのログ管理を改善したい」ではなく「Podの再起動ログをSlackに送る」）。「完成」の定義を下げる（動けば完成、READMEは3行でいい）。公開してしまう（不確実性の一部が確定に変わる）。AIに頼らない時間を作る（自分で考える筋力を維持する）。
「狂う」とは何か
「狂う」という言葉を使うと、何か特別な才能や突飛な発想が必要に思える。しかし、私が考える「狂う」はもっと単純だ。
狂うとは、常識的な量を超えて、時間と労力を注ぐことだ。
天才的なアイデアは必要ない。奇抜な発想も必要ない。ただ、普通の人が「そこまでやらなくていいだろう」と思う量を投入する。これが狂うということだ。
しかし、ここまで書いて気づいた。「量をやれ」というアドバイスは、ゴールが見えている人へのアドバイスだ。これはポジティブケイパビリティの話だ。「OSSを20個作れ」と言われても、「何を作るか」が決まっていなければ、手は動かない。私の問題は、量が足りないことではなく、ゴールが見えない状態に耐えられないことだった。ネガティブケイパビリティの欠如だ。
だから、「狂う」にはもう1つの意味がある。答えが出ない状態に留まり続けることだ。
「これが正解かどうか分からない」「誰にも使われないかもしれない」「もっといい方法があるかもしれない」。その不確実さの中で、それでも作り続ける。確信がないまま、手を動かし続ける。
普通の人は、不確実さに耐えられない。「これで合ってる？」と誰かに確認したくなる。確認できないと、手が止まる。狂っている人は、確認しないまま走り続ける。
生成AIは「確認」を容易にした。コードを書いたら、AIにレビューしてもらえる。設計を考えたら、AIに壁打ちしてもらえる。これは素晴らしいことだ。でも同時に、「確認なしで走り続ける」筋力が衰えた。
量を積むことと、不確実性に耐えること。この2つは、実は表裏一体だ。量を積めば、その中から「これだ」というものが見えてくる。不確実性に耐えていれば、やがてゴールが見えてくる。どちらも「狂う」ことでしか到達できない。
狂気の最も簡単な表現方法は、物量か時間を使うことだ。1日1時間を5年続ける。同じテーマのブログを100本書く。OSSを年間20個作る。なぜ20個か。月に1〜2個のペースだ。1つのツールを2週間で完成させる。完璧じゃなくていい。動けばいい。このペースなら、仕事をしながらでも無理がない。かつ、「そこそこ止まり」の自分とは明らかに違う場所に立てる。特別な才能がなくても、量を積めば、誰も追いつけない場所にたどり着く。
ここで「衝動」という言葉を使いたい。不便を見つけたとき、「あ、これ自動化できそう」と思う。その瞬間、手が動き出す。誰に頼まれたわけでもない。でも、気づいたらコードを書いている。これが私にとっての衝動だ。
「将来の夢」とは違う。他者の評価を求めている「有名なOSSメンテナになりたい」は、衝動ではない。衝動は、評価とは無関係に動く。10年経っても変わらない。「不便を見つけたら、すぐ直したくなる」。隙間家具を作るのは、この衝動の表れだ。
問題は、この衝動を他者の目で覆い隠してしまうことだ。「作っても誰にも使われないかも」。そう考えた瞬間、衝動が埋もれる。2025年の私は、まさにこれだった。
衝動は「発見」するものではなく「掘り出す」ものだ。他者の目や評価への恐れで覆い隠されている。それを掘り出すには、まず量をやる必要がある。考える前に手を動かす。作る前に悩まない。作った後に、何が自分を動かしているのかが見えてくる。
まず量をやる
私たちは、最初から量が足りない。
2025年、私のOSSがそこそこ止まりだった理由は何か。作った。完走もした。でも、「代表作」と呼べるインパクトには届かなかった。振り返ると、1つに賭け切れていなかった。あれもこれもやろうとして、どれにも全力を注げなかった。
「ゴールが見えないから突き抜けられない」と思っていた。でも、それは逆だ。一つに賭け切らないから、ゴールが見えない。作りはした。でも、広く浅く。一つに集中しなかったから、どれも「これだ」に辿り着けなかった。
私の経験を話す。以前、「Kubernetesのログをなんとかしたい」という漠然とした不満があった。何を作ればいいか分からなかった。とりあえず、Podの再起動を検知するスクリプトを書いた。動いた。使ってみた。すると、「再起動の直前のログが見たい」という次の不満が見えた。それを解決するコードを足した。使ってみた。今度は「Slackに通知したい」という欲求が出てきた。最初に「Podの再起動時に直前のログをSlackに送るツール」というゴールが見えていたわけではない。作っているうちに、ゴールが形成されていった。
ゴールは、作る前に見つかるものではない。作る過程で見えてくるものだ。量をやることで、初めて「自分が本当に作りたいもの」が浮かび上がる。
完璧な1つより、動く20個。磨き上げた1つより、荒削りな50個。これが私の2026年の方針だ。
物量で狂う。 OSSを年間20個作る。完璧じゃなくていい。動けばいい。20個作れば、1個くらいは当たる。当たらなくても、20個分の経験が残る。
時間で狂う。 毎日30分、何かを作る時間を確保する。1年で小さなツールを20個作れば、5年で100個になる。100個のOSSを持っているエンジニアは、採用市場で見たことがない。
試行で狂う。 1つのアイデアに固執しない。「これは違うな」と思ったら、すぐ次に行く。打席に立つ回数を増やす。三振しても気にしない。次の打席がある。
私は30代で独身だ。守るべきものが少ない。狂えるうちに狂っておく。
量をやることで、初めて見えてくるものがある。どのアイデアに自分の熱量が続くのか。どのツールが使われるのか。作る前に「どれが正解か」を考えても分からない。作った後に、結果が教えてくれる。
量だけでは足りないからセンスを磨く
ここで反論が聞こえる。「量をやるだけなら、生成AIでもできるのでは？」
正しい指摘だ。そして、もう1つ重要な変化がある。ソフトウェアは供給過多の時代に入った。
あらゆる領域で「フロンティアの閉鎖」が起きている。かつてソフトウェアには未開拓の荒野があった。問題はそこら中に転がっていて、誰かが手を挙げて解決すれば、それだけで価値になった。参入障壁が高かったから、作れる人が少なかった。だから「作った」という事実そのものに希少性があった。
今は違う。生成AIが参入障壁を破壊した。誰でも作れる。結果、供給が需要を超えた。ユーザーの時間と注意力が、ツールよりも希少になった。ツールが人を選ぶ時代から、人がツールを選ぶ時代へ。選ばれないツールは、存在しないのと同じだ。
これは「量で勝てた時代の終焉」を意味する。かつての戦略は「とにかく作れ、出せ、数で勝負しろ」だった。今、その戦略は逆効果になりうる。大量の凡庸なツールを公開すると、ノイズを増やすだけで、作り手の信用を毀損する。
つまり、量を公開しすぎることが、むしろマイナスになる時代が来ている。
では、量をやる意味はどこにあるのか。
ここで「センス」について考えたい。センスとは何か。私は、意味よりも先に、形式やリズムを感じ取る能力だと考えている。
普通、私たちは物事を「これは何を意味するのか」で理解しようとする。コードを見て「このツールは何をするのか」と問う。ブログを読んで「著者は何を主張しているのか」と問う。意味を求める。でも、センスの本質はそこにない。
センスとは、意味の手前にある「リズム」を感じ取ることだ。
リズムとは、反復と差異の織り成すパターンのことだ。赤ちゃんが「いないいないばあ」で喜ぶのは、不在から存在への移行、つまり0→1のビートを感じているからだ。予測があり、裏切りがあり、また予測に戻る。この往復運動が快感を生む。
あらゆる表現にリズムがある。音楽のビート。文章の緩急。コードの構造。APIの応答パターン。人間は意味を理解する前に、このリズムを身体で感じている。
優れた表現は、セオリーを押さえた上で、あえてそこからはみ出す。 反復の中に絶妙な差異を混ぜている。予測可能でありながら、どこか予測を裏切る。この「ズレ」がセンスだ。
ここで重要な逆説がある。完璧を目指すほど、センスは死ぬ。
お手本を完璧に再現しようとすると、二つの問題が起きる。一つは、お手本との差異が「欠点」に見えてしまうこと。もう一つは、自分固有のリズムが消えてしまうこと。結果として、劣化コピーが生まれる。
逆に、お手本から離れることを肯定すると、「ヘタウマ」が生まれる。完璧ではないが、作り手固有のリズムがある。技術的には未熟でも、個性がある。その個性が、使う人に刺さる。
なぜ個性が刺さるのか。人間は、パターンを認識する生き物だからだ。
完璧にパターン化されたものは、最初は心地よい。でも、すぐ飽きる。予測通りすぎて、刺激がない。一方、パターンから少しズレたものは、脳に引っかかる。「なぜここでこうなる？」という小さな疑問が生まれ、それが記憶に残る。
AIは反復とパターンを生成できる。しかし、その人固有の「どうしようもなさ」は生成できない。
「どうしようもなさ」とは何か。個人の癖、偏り、こだわり。論理では説明できない選好。なぜか惹かれるもの。なぜか避けたくなるもの。この非合理な偏りが、人間の表現に陰影を与える。
私がツールを作るとき、そこには私の「どうしようもなさ」が刻まれる。なぜこの設計を選んだのか、論理的に説明できない部分がある。それは私の経験、私の好み、私の盲点が複合的に作用した結果だ。AIが同じ仕様で作っても、同じものにはならない。
センスとは、リズムを感じ取る能力であり、同時に、自分固有のリズムを表現する能力でもある。
では、どうやってセンスを磨くのか。答えは逆説的だ。量をやることだ。
多様なものに触れると、最初は不安を感じる。「分からない」「理解できない」。この不安は、パターンを認識できていないサインだ。量を重ねると、パターンが見えてくる。不安が面白さに変換される。これがセンスが磨かれる過程だ。
ここで矛盾が生じる。センスを磨くには量が必要だ。しかし、量を公開しすぎるとマイナスになる。
答えは、「作る量」と「公開する量」を分けることだ。
20個作る。でも、公開するのは、センスが良いと判断した5個だけ。残りの15個は、センスを磨くための練習だ。公開しない。でも、作ったことに意味がある。
量をやることには、二重の意味がある。
1つ目は、センスを磨くこと。多様なものを作ることで、「何が良くて何が良くないか」を判断する回路ができる。リズムを感じ取る力が育つ。
2つ目は、自分の「どうしようもなさ」を発見すること。量をやると、自分のパターンが見えてくる。どういう問題に惹かれるか。どういう設計を好むか。それは私の固有性であり、AIには真似できない。
だから、量をやる意味は「AIより速く作る」ことではない。量を通じて、リズムを感じ取る力と、自分固有のリズムを発見することだ。そして、センスが磨かれた後は、公開するものを厳選する。
供給過多の時代に求められるのは、「たくさん作れる人」ではない。「たくさん作った上で、良いものだけを選べる人」だ。
AIは「どう作るか」を効率化する。でも、「何を作るか」「どれを公開するか」「どう判断するか」は、量を経験した人間にしか分からない。
そして引き算する
量をやった。20個作った。では、20個全部を維持できるか。できない。
私には経験がある。かつて、複数のプロジェクトを同時に走らせていた。イシューは溜まり、プルリクエストは放置され、READMEは古くなった。全部やろうとして、全部が死んだ。量をやることと、量を維持することは違う。 量をやるのは一時的な狂気だ。量を維持するのは持続的な負担だ。人間のリソースは有限だから、量をやった後には、引き算という別の問題が待っている。
私たちは、量が満ちた後に引かなすぎる。 量をやった後は、容赦なく削る。使われないツールは捨てる。熱量が続かないプロジェクトはアーカイブする。失うのは「いつかやるかもしれない」という幻想だ。守れるのは「今、本当にやりたいこと」への集中だ。
削らずに広げ続けた結果が2025年の私だ。副業も、登壇も、ブログも、OSSも、全部やった。全部それなりに成果は出た。でも、どれも「これが俺の本業だ」と言い切れない。器用貧乏の完成形だ。
ここで「引き算」の思考法が必要になる。シーナ・アイエンガー氏の有名な実験では、24種類のジャムより、6種類に絞った方が購入率は高かった。選択肢が多すぎると、人は「選ぶ」という行為自体ができなくなる。
アイエンガー氏は『THINK BIGGER』で、選択肢が多すぎて選べないときの思考法を体系化した。その本質は「引き算」だ。課題を選ぶ、分解する、誰のためかを決める、材料を集める、何を作らないかを決める、他者の目で検証する。すべて「絞る」プロセスだ。
狂って量をやるフェーズでは、複数のアイデアが同時に走っている方が自然だ。順番通りに1つずつ片付けようとすると、むしろ手が止まる。どれかが熱を帯びてきたら、そこに集中する。足し算ではない。引き算だ。
優れた開発者のOSSが失敗するのは、怠けているからではない。正しいことをしすぎるからだ。 ユーザーの声を聞く。機能を追加する。対応範囲を広げる。全部、正しいことだ。でも、正しいことを積み重ねた結果、複雑になり、重くなり、新しく登場したシンプルなツールに足元をすくわれる。
私たちは「正しさ」に殺される。ユーザーの声を聞くのは正しい。だから聞く。機能を追加するのは正しい。だから追加する。テストを書くのは正しい。だから書く。ドキュメントを整えるのは正しい。だから整える。気づいたら、最初に解決したかった問題が見えなくなっている。正しいことの山に埋もれて、本質が窒息している。「正しさ」は麻薬だ。やればやるほど気持ちいい。やればやるほど、完成から遠ざかる。
隙間家具を作るとは、引き算をすることだ。機能を削る。対象を絞る。スコープを小さくする。「これだけは解決する」を決め、残りは捨てる。
生成AIを使うとき、この引き算が難しくなる。AIは指示すれば無限に足し算を提案してくる。「この機能も追加しましょうか」「こういうオプションもあると便利です」「エラーハンドリングをもっと丁寧にしましょう」。全部、正しい提案だ。でも、全部受け入れると、隙間家具は大きな家具になる。
AIは足し算が得意だ。引き算は人間がやる。私がAIに「削らせる」ときに使う問いかけがある。「この機能がなくても、最小限の価値は提供できるか？」。答えがYESなら、その機能は削る候補だ。AIの提案を聞いたら、「本当に必要か？」と問い直す。これが、AIとの協働における引き算の基本姿勢だ。
「何を作るか」を決める
課題を選ぶ
引き算の最初は、「何を作るか」を1つに決めることだ。
私が2025年に「代表作」に届かなかった理由の1つは、課題が大きすぎたことだ。「Kubernetesのログ管理を改善したい」と思った。でも、それは「どのログ」「どう改善」「誰のため」が決まっていない。漠然としすぎていた。結果、インパクトのあるものが作れなかった。
「作りたいものはあるけど、何から手をつければ...」という状態は、課題が大きすぎるか小さすぎるかのどちらかだ。大きすぎると作りきれない。小さすぎると作る意味がない。「1つのツールで完結する」サイズを探す。
課題が大きすぎる例:「Kubernetesの代替」「CI/CDパイプライン全体の改善」「インフラ自動化ツール」
課題が小さすぎる例:「kubectl getのラッパー」「特定のエラーメッセージを整形するスクリプト」
ちょうどいい例:「Podが再起動したときに直前のログを保存するツール」「複数リポジトリのCIステータスを一覧表示するCLI」「Terraformの差分をSlackに見やすく投稿するBot」
ちょうどいいサイズの見つけ方は、「自分が1〜3日かけて解決したこと」を思い出すことだ。それは、深みがある。かつ、1つのツールで完結する気がする。
隙間を見つける
大きなツールが解決していない小さな問題。それが「隙間」だ。
Kubernetes（コンテナオーケストレーション）は素晴らしい。しかし、Kubernetesが解決していない問題は山ほどある。Podが再起動したとき、前後のログを自動でSlack に送りたい。これはKubernetesの仕事ではない。Terraform（インフラ構成管理）も素晴らしい。ただ、差分をSlackに見やすく投稿したい。これはTerraformの仕事ではない。GitHubも同様だ。複数リポジトリのCIステータスを一覧で見たい。これはGitHubの仕事ではない。
隙間を見つけるヒントは5つある。
自分の不便。「こういうツールが欲しいのに、ない」という体験。私が作った隙間家具の中で、最も使われたものは、自分自身の問題を解決するために作ったものだった。自分が不便を感じているとき、そこには片づけたい「用事」がある。でも、それを片づける手段がない。
ここで疑問が浮かぶ。「自分の不便」が特殊すぎるときはどうするのか。自分だけが困っている問題を解決しても、誰も使わないのではないか。だから2026年、私はこう決めた。最初は特殊すぎて構わない。なぜなら、特殊な問題を解決するツールでも、自分が本当に使うなら完成する。「誰かが使うかも」で作ったツールは、途中で手が止まる。まず完成させることが最優先だ。公開してみれば、同じ問題を抱えている人が意外といることに気づく。特殊だと思っていた不便が、実は普遍的だったというケースは多い。仮に本当に特殊で誰も使わなくても、自分の問題は解決している。それで十分だ。
繰り返しの手作業。同じコマンドを何度も打っている。同じ手順を何度も実行している。毎回「面倒だな」と思いながら、やっている。
ここで立ち止まる。この問題は「自動化すべき問題」か、それとも「慣れるべき問題」か。ツール化することで、本当に人間の負荷は減るのか。自動化によって、別の複雑さを生んでいないか。
判断基準は、その作業が月に何回・何分発生しているかだ。月に1回、5分で終わる作業なら、自動化ツールを作るより慣れた方が早い。週に10回、毎回10分かかる作業なら、自動化する価値がある。感覚で判断しない。数字で判断する。
例えば、複数のGitHubリポジトリのCIステータスを確認するとき、1つずつページを開いていた。毎回、5分くらいかかる。週に5回やっていた。月に100分。年に1200分。ツールを作る価値がある。作った。5分が10秒になった。
コンテキストスイッチ。ある情報を得るために、複数のツールを行き来している。Slackを見て、Grafanaを見て、ログを見て、またSlackに戻る。情報を一箇所に集めるツールを作れば、コンテキストスイッチが減る。頭の負荷が減る。判断が速くなる。
暗黙知。「あの人に聞けば分かる」「Slackのどこかにある」「この手順は、前にやったことある人しか知らない」。暗黙知をツールに埋め込めば、誰でも同じことができるようになる。
複雑さ。「このツールは高機能だけど、使いこなせない」「設定項目が多すぎて、何を設定すればいいか分からない」。高機能なツールが、その機能を使い切れていない人たちを置き去りにしている。彼らに、シンプルで分かりやすい選択肢を提供する。これも隙間家具の仕事だ。
課題を分解する
課題が決まったら、5つまでに分解する。
私がよくやる失敗は、分解せずに作り始めることだ。「ログ保存ツールを作ろう」と思って、いきなりコードを書き始める。途中で「保存先どうしよう」「認証どうしよう」「エラーハンドリングどうしよう」と考え始める。そのたびに手が止まる。最初に分解しておけば、こうはならない。
「〇〇を作ろう」だけでは手が動かない。サブ課題に分解して、5つまでに絞る。5つに絞るのは、正直、苦しい。あれもこれも入れたくなる。でも、ジャムの法則と同じだ。サブ課題を10個、20個と出すと、どれに注力すべきか分からなくなる。
例: 「Podが再起動したときに直前のログを保存するツール」
- Podの再起動を検知する仕組み
- 直前のログを取得する方法
- ログを保存する先（S3など）
- CLIのインターフェース
- エラーハンドリング
分解した項目が、そのまま実装の順番になる。「これは本当に必要か？」と自問すると、いろいろ見えてくる。実は同じことをしている項目。なくても動く項目。別のツールに任せた方がいい項目。削ることで本質が見える。
5つに分解したら、次に優先順位をつける。何を基準に「残す1つ」と「後回しにする4つ」を決めるか。私の基準は、「これがないと、ツールとして成立しない」だ。技術的な実現性でも、ユーザーの感動でも、自分の興味でもない。「ツールの存在意義に関わるか」だ。例えば、「Podの再起動を検知する仕組み」がなければ、ログ保存ツールは成立しない。これが最優先だ。「CLIのインターフェース」は後でもいい。最初はハードコードでも動く。
ここまでで、「何を作るか」と「どう分解するか」が決まった。でも、まだ足りない。「誰のために作るか」が決まっていない。
「誰のために作るか」を決める
望みを比較する
同じツールでも、誰向けに作るかで設計が変わる。自分用なら雑でいい。他人に使ってもらうなら、READMEが必要だ。コミュニティに貢献したいなら、テストも書く。
私が2025年に「代表作」に届かなかったもう1つの理由は、「誰のため」が曖昧だったことだ。「これ、公開したら使ってもらえるかな」と考えた瞬間、設計が複雑になる。「あの人はこういう使い方するかも」「この環境もサポートした方がいいかも」。考えれば考えるほど、作るものが膨らむ。膨らめば膨らむほど、作れなくなる。
3つの望みがある。自分が作りたいもの。ユーザーが使いたいもの。コミュニティへの貢献。全部満たそうとすると、どれも中途半端になる。
だから2026年、私はこう決断する。まず自分の問題を解決するツールを作る。当たり前すぎるかもしれない。でも、これが私の経験則だ。自分が本当に困っている問題なら、熱量が出る。熱量のあるツールは、ユーザーにも伝わる。
これは「プロダクト」ではなく「道具」として十分に割り切れているか。プロダクトは他者のためにある。道具は自分のためにある。隙間家具は道具だ。自分の問題を解決するために作る。他者が使ってくれたらラッキー、くらいの気持ちでいい。
汎用性を上げようとして、複雑さを持ち込んでいないか。持ち込みがちだ。「S3だけじゃなくGCSにも対応しよう」「Kubernetes以外でも使えるようにしよう」。その瞬間、道具がプロダクトになろうとする。複雑さが増す。完成しなくなる。
READMEは「思想」ではなく「使い方」を語っているか。思想を語りがちだ。「なぜこのツールが必要か」「どんな設計思想か」。でも、ユーザーが知りたいのは「どう使うか」だ。インストール方法、実行方法、オプション。これだけでいい。
自分以外の利用者がゼロでも、このツールは成立しているか。成立している必要がある。自分の問題が解決しているなら、それで十分だ。他者が使うかどうかは、結果論だ。
「まだ誰も使っていない人」を見る
自分が不便を感じているとき、同じ不便を感じている人は他にもいる。片づけたい用事があるのに、それを片づける手段を持っていない人。私はこの人たちを「まだ誰も使っていない人」と呼んでいる。自分がその一人だったなら、同じ境遇の人が他にもいるだろう。隙間家具は、この人たちに届ける。
ここで注意が必要だ。ツールを公開すると、ユーザーからフィードバックが来る。「この機能が欲しい」「ここが使いにくい」。これは嬉しい。でも、ここに罠がある。
既存ユーザーの声を聞けば聞くほど、既存ユーザーのためのツールになる。そして、「まだ誰も使っていない人」を見落とす。
既存ユーザーの声に応え続けると、隙間家具は大きな家具になろうとし始める。機能が増え、複雑になり、最初のシンプルさを失う。新規ユーザーが求めているのは、高機能ではなく「すぐ使える」「分かりやすい」だ。
「声」と「用事」を区別する
フィードバックを受けるとき、「声」と「用事」を区別する。
私も失敗したことがある。あるCLIツールを公開したとき、「設定ファイルで動作を変えたい」というフィードバックを複数もらった。嬉しかった。使ってくれている人がいる。だから、設定ファイル機能を実装した。YAMLで書けるようにした。オプションを増やした。結果、設定項目が20個を超えた。新しいユーザーは「設定が多すぎて何を設定すればいいか分からない」と言い始めた。シンプルさが売りだったツールは、複雑なツールになっていた。
「声」は、ユーザーが言語化したものだ。「この機能が欲しい」「ここが使いにくい」。「用事」は、ユーザーが本当に片づけたいことだ。なぜその機能が欲しいのか。なぜそこを使いにくいと感じるのか。この「なぜ」の先に、本当の用事がある。
例えば、CLIツールに「YAML出力オプションが欲しい」というフィードバックが来たとする。声をそのまま受け取れば、--output yamlフラグを実装することになる。でも、「なぜYAMLが欲しいのか」を問うと、「他のツールにパイプしたい」「設定ファイルとして保存したい」という用事が見えてくる。用事が分かれば、YAMLだけでなくJSONでも解決できるだろう。あるいは、標準出力をそのままパイプできる設計にすれば、フォーマット変換はjqに任せられるだろう。
「この機能が欲しい」と言われたら、「なぜ」を問う。その人の用事は何か。その用事を片づける方法は、言われた機能だけか。もっとシンプルな方法はないか。
ツールがヒットすると、「汎用化」の要望が必ず来る。「S3だけでなくGCSにも対応して」「Kubernetes以外でも使えるようにして」。これに応えると、隙間家具は大きな家具になる。
だから私は、こう決めている。READMEが複雑になるなら、その機能は入れない。
機能を追加するとき、READMEがどう変わるかを見る。説明が長くなるなら、別のツールにする。READMEがシンプルなら、ツールもシンプルだ。これが私の制約であり、美学だ。
ここまでで、「何を作るか」「誰のために作るか」が決まった。次は、作る前に調べる。
調べて、削る
箱の中と外を探す
いきなり作り始めたくなる。でも、その前に下調べをする。
私は以前、「これ、俺が作らなくても既存ツールで十分だな」と気づいて手を止めたことがある。それ自体は正しい判断だった。でも、その後「じゃあ俺の経験は何に使えるか」を考えなかった。既存ツールを調べて終わり。それでは何も生まれない。似たツールはあるか。どんなアプローチがあるか。先人の知恵を借りる。
「箱の中」は同じ領域の情報だ。公式ドキュメント、他の人の同じテーマのツール、GitHub Issues、Stack Overflow。正確性を担保し、抜け漏れを防ぐ。「箱の外」は自分の経験だ。実際に試した結果、ハマったポイントと解決策、自分なりの工夫や改善。これがオリジナリティの源泉になる。
ここで重要なのは、インプットだ。
本を読む。既存のOSSのコードをちゃんと読む。何のライブラリが使われていて、どのように問題を解決しているかを理解する。これが「箱の中」を深く知ることだ。
例えば、Kubernetesのログ保存ツールを作るなら、既存の類似ツールのコードを読む。どのKubernetesクライアントライブラリを使っているか。どうやってPodの再起動を検知しているか。ログの取得にはどのAPIを使っているか。保存先との接続はどう抽象化しているか。
コードを読まずに作り始めると、車輪の再発明をする。既に解決されている問題を、苦労して解き直す。あるいは、先人が避けた落とし穴にハマる。
インプットの具体例を挙げる。
- 本を読む：技術書だけでなく、設計思想やアーキテクチャの本も読む。『A Philosophy of Software Design』『The Art of Unix Programming』。隙間家具を作る視点が変わる。
- OSSのコードを読む：GitHubで似たツールを探して、main.goやlib.rsを読む。README だけでなく、実装を見る。「なるほど、こう解決するのか」という発見がある。
- ライブラリの使い方を学ぶ：使おうとしているライブラリのexampleを全部読む。ドキュメントを端から端まで読む。「こんな機能もあったのか」という発見が、設計を変える。
「既に同じようなツールがある」は気にしない。同じ課題を解決するツールでも、価値を出せる理由はある。環境が違う。文脈が違う。深さが違う。切り口が違う。あなたのツールにしかない価値は、あなたの環境で動いた事実、あなたがハマったポイント、あなたの言葉での説明だ。「n番煎じ」でも、あなたの経験を加えれば価値になる。
「箱の外」の材料を増やすために、私が意識的にやっていることがある。「自分の仕事を観察する」だ。エンジニアリング以外のインプットも大事だが、それ以上に、自分が日常的にやっている作業を観察する。「今、何に時間を使っているか」「何に苛立っているか」「何を繰り返しているか」。この観察が、隙間を見つける材料になる。
選択マップで削る
材料が揃ったら、「何を作り、何を作らないか」を選ぶ。
私は「全部入り」を目指しがちだ。ログ保存ツールを作るなら、S3もGCSもAzure Blobも対応したくなる。Slack通知もメール通知もつけたくなる。そうこうしているうちに、何も作れなくなる。
選択マップとは、集めた選択肢を視覚的に整理し、最適な組み合わせを見つける方法だ。課題から分岐して選択肢を並べ、各選択肢のメリット・デメリットを可視化する。
例: 「OOMKilled（メモリ不足による強制終了）の調査方法を紹介するツール」
調査方法は複数ある。kubectl top（リソース使用状況確認）、Grafana（可視化ダッシュボード）、pprof（プロファイリングツール）、サードパーティツール。読者に最も役立つのはどれか。kubectl topは簡単ですぐ使えるが、瞬間値しか見られない。Grafanaは履歴を見られるが、セットアップが必要。pprofは詳細に分析できるが、設定が必要で学習コストは高い。
選択結果：読者の多くは「まず何が起きてるか知りたい」→ kubectl top + Grafanaを中心に作る。pprofは発展編として軽く触れるか、別のツールにする。
足し算の発想だと、全部の方法をサポートしようとする。焦点がぼやける。誰にも刺さらない。引き算の発想だと、「これだけは作る」を決める。残りは捨てる。刺さるツールになる。
良いツールは「何を作らないか」で決まる。
スコープを絞る勇気
隙間家具は、特定の問題を解決する。汎用性を追求しない。「このコンテキストで、この問題を解決する」に集中する。
例えば、「KubernetesのPodが再起動したとき、直前のログを自動でS3に保存するツール」。汎用的ではない。Kubernetesを使っていて、ログをS3に保存したい人だけを対象にする。でも、それでいい。特定の問題を、特定のコンテキストで、確実に解決する。これが隙間家具の価値だ。
汎用性は、使われてから考えればいい。最初から汎用的に作ろうとすると、要件が膨らみ、複雑になり、いつまでも完成しない。
ここまでで、何を作るか、誰のために作るか、何を作らないかが決まった。いよいよ作る。
小さく作って、見せる
第三の目で検証する
作った。動いた。自分では完璧に見える。でも、それは危険なサインなんだ。
私にも経験がある。あるCLIツールを作って、自分では「完璧だ」と思った。README も書いた。インストール方法も書いた。でも、同僚に見せたら「これ、何をするツールなの？」と聞かれた。私には当たり前すぎて、説明を省略していた。「前提知識がないと、何も分からない」。そのツールは結局、私しか使わなかった。使い方を説明する手間を惜しんだ結果だ。
作った本人には見えない穴がある。「当然わかるでしょ」と省略している。専門用語を説明なしで使っている。論理の飛躍に気づかない。自分では完璧に見える。だから、他者に見せる。使ってもらう。フィードバックをもらう。
隙間家具を必要としている人は、探していない。問題を抱えているが、解決策があるとは思っていない。だから、「検索してたどり着く」ことを期待できない。
では、どうやって届けるか。自分の体験を語る。
「私はこういう問題を抱えていた。だから、このツールを作った。」「まだ誰も使っていない人」は、同じ問題を抱えているだろう。ブログやTwitterで体験を語れば、「あ、自分もこの問題を抱えている」と思ってもらえる。READMEに機能を列挙するだけでは届かない。「なぜこのツールを作ったか」「どんな問題を解決するか」を語る。
「まだ誰も使っていない人」は、自分の不便を言語化できていないことが多い。だから、状況を描写する。「毎朝、Slackを開いて、Grafanaに移動して、ログを確認して、またSlackに戻る...この作業、面倒じゃないですか？」。機能ではなく、状況を語る。「あ、それ自分だ」と思わせる。ツールの説明ではなく、問題の描写から始める。これが、言語化できていない不便に気づかせるストーリーテリングだ。
入り口を簡単にする
インストールが面倒だと、人は離れる。設定が複雑だと、人は離れる。最初の一歩を、できるだけ簡単にする。
go install 一発でインストールできる。設定ファイルは最小限。デフォルトで動く。これが理想だ。なぜなら、新しいツールを試すとき、人は「動かすまでの時間」を無意識に測っている。5分で動かなければ、「また今度」になる。設定が多いツールは、5分では動かない。だから、試されずに終わる。パワーユーザーは細かい設定を求めるだろう。でも、パワーユーザーは「まだ誰も使っていない人」ではない。最初に届けるべきは、5分で動くシンプルさだ。
新しいツールは、最初は既存のツールより「劣っている」ことが多い。機能が少ない。パフォーマンスが低い。でも、シンプルで、分かりやすくて、すぐに使える。それでいい。隙間家具は、シンプルでいい。1つのことを、確実にやる。それが、「まだ誰も使っていない人」に届く。
「ジャムの法則」をインターフェースにも適用する。CLIツールなら、フラグを減らす。理想は、引数なしで動くこと。mytoolと打てば、最も一般的なユースケースが実行される。設定が必要なら、対話的に聞く。フラグは上級者向けのショートカットだ。最初から覚えてもらうものではない。選択肢を減らすことで、ユーザーは「考える」から「使う」にすぐ移れる。
このツールは「技術的に正しい」より「現場で生き残る」設計になっているか。技術的に正しい設計は、しばしば複雑になる。すべてのエッジケースに対応する。すべてのエラーを丁寧にハンドリングする。でも、現場で使われるツールは、シンプルで、雑でも動く。
エッジケースを切り捨てた理由を説明できるか。説明できる必要がある。「このケースは月に1回しか発生しない。手動で対応すればいい。だから、ツールでは対応しない。」こう言い切れるなら、切り捨てていい。
例外処理より「何も起きないこと」を優先していないか。優先していい。エラーが発生したとき、丁寧なエラーメッセージを出すより、そもそもエラーが発生しない設計の方がいい。入力を厳しくする。想定外の状態を作らない。
現場の雑さ・曖昧さ・不完全さを前提にできているか。現場は綺麗ではない。設定ファイルにtypoがある。環境変数が設定されていない。ネットワークが不安定。この雑さを前提に設計する。「完璧な環境でしか動かないツール」は、現場では使われない。
小さく始める
6ステップを踏んでも、完璧なツールは作れない。だから、小さく始める。
最初から完璧なツールを作ろうとしない。自分の問題を解決するスクリプトから始める。それが動いたら、少し整えて公開する。私の場合、多くの隙間家具は、最初はただのシェルスクリプトだった。自分の問題を解決するために、ちょっと書いた。それが便利だったので、もう少し整えた。それを公開した。
完璧を目指すと、いつまでも公開できない。「もう少し機能を追加してから」「もう少しドキュメントを整えてから」。そうこうしているうちに、作る気力がなくなる。動くものを、まず作る。公開する。使ってもらう。フィードバックをもらう。改善する。このサイクルを回す。
隙間家具を1つ公開したら、終わりではない。むしろ、ここからが始まりだ。
探索を続ける
捨てやすく作る
ここからが、私が一番伝えたいことだ。
隙間家具には寿命がある。状況が変われば、不要になる。だから、捨てやすく作る。
このツールは「自分が将来保守したいコード」になっているか。正直に言えば、保守したくないコードの方が多い。だから、捨てやすく作る。保守したくなるほど愛着が湧くツールは、20個に1個くらいでいい。
半年後の自分が読んで理解できる設計になっているか。なっていなくてもいい。半年後に必要なら、そのとき書き直せばいい。必要なければ、捨てればいい。
機能追加ではなく「削除」するとしたら、どこを真っ先に消すか。この問いを常に持っておく。削除できる部分があるなら、それは最初から作らなくてよかった部分かもしれない。
このコードは、使われなくなったときに綺麗に捨てられるか。捨てられる設計にしておく。依存を少なく。外部サービスとの結合を弱く。捨てるときに、誰にも迷惑がかからないように。
私が作ったツールの中で、すでに捨てたものがある。Kubernetesをインストールするツールを作っていた。当時、Kubernetesのインストールは複雑で、手順を間違えると動かなかった。だから、自動化ツールを作った。便利だった。でも、kubeadmがリリースされて、インストールが簡略化された。ツールは不要になった。リポジトリをアーカイブした。悲しくはなかった。むしろ、「自分の問題意識は正しかった」と思えた。Kubernetesの開発者も同じ問題を認識していたのだから。
このOSSは「本流に取り込まれる未来」を想定できているか。想定しておく。もしKubernetesやTerraform本体に同等機能が入ったら、どうするか。喜んで捨てる。それは「失敗した」のではなく「役目を終えた」のだ。
本流に吸収されるために、意図的にやっていないことは何か。汎用化だ。本流は汎用的になろうとする。隙間家具は特殊なままでいい。特殊だから、本流が取り込みにくい。特殊だから、生き残れる。
隙間家具は、状況が変われば不要になる。Kubernetesのバージョンが上がって、その問題が解決されるだろう。別のツールが登場して、より良い解決策を提供するだろう。だから、依存を少なく、シンプルに作る。捨てやすく作る。
大きな家具は、捨てにくい。多くのリソースを投入している。多くの人が使っている。捨てることが難しい。隙間家具は、捨てやすい。役目を終えたら、捨てる。そして、新しい隙間を見つけて、新しい隙間家具を作る。
「隙間」が「本流」に飲み込まれるリスクもある。Kubernetesのサイドカー機能が進化するように、プラットフォーム自体が隙間を埋めてしまうことがある。これに対する私の戦略は2つだ。1つ目は、捨てやすく作ること。本流に飲み込まれたら、素直に捨てる。自分の問題意識が正しかった証拠だと喜ぶ。2つ目は、本流が手を出さないニッチに特化すること。Kubernetesは汎用的になろうとする。だから、特定の会社の特定のワークフローに特化したツールは、本流が取り込みにくい。汎用化できないほど特殊なニッチを狙う。これも生存戦略だ。
捨てたツールから得られる学びもある。単なる「失敗」で終わらせず、次の探索に活かせる知見を抽出する。私がやっているのは、「なぜこのツールは役目を終えたのか」を言語化することだ。本流に取り込まれたのか。別のツールが出てきたのか。そもそも問題設定が間違っていたのか。この分析が、次の隙間を見つける精度を上げる。「問題設定が間違っていた」が一番の学びだ。次は同じ間違いをしない。
深化と探索
隙間家具を1つ作ったら、終わりではない。
隙間家具の開発には、2つの仕事がある。「深化」と「探索」だ。「深化」は、既存の隙間家具を改善すること。バグを直す。パフォーマンスを改善する。ドキュメントを整える。「探索」は、新しい隙間を見つけること。新しい用事を発見すること。新しい隙間家具を作ること。
問題は、「深化」へ偏りやすいことだ。既存のツールへイシューが立つ。プルリクエストが来る。対応すると達成感がある。でも、これだけやっていると、最初に見つけた隙間だけを相手にし続けてしまう。
競争のないところに宝がある。既存の競合がひしめく場所ではなく、誰も見ていない場所を探す。だから2026年、私はこう決めた。小さな実験を続ける。1つの隙間家具に全力を注ぐのではなく、複数の隙間家具を作り、どれが使われるか見る。全部が使われるわけではない。むしろ、使われないものの方が多い。でも、それでいい。使われなかったツールからも、学びがある。その学びが、次の探索に活きる。
チーム開発での引き算
ここまでの話は、一人で作る「隙間家具」を前提にしてきた。では、複数人で開発するときはどうか。「引き算の哲学」をチームで共有できるのか。
私の経験では、スコープを最初に合意することが鍵だ。「このツールは何を解決し、何を解決しないか」を、開発を始める前にドキュメントへ書く。機能追加の提案が来たら、このドキュメントに立ち返る。「このスコープ外です」と言える根拠になる。
チームでの合意形成は、一人のときより難しい。でも、「1つのREADMEで説明できる範囲」という制約は、チームでも使える。「この機能を追加したら、READMEはどう変わるか」を問う。READMEが複雑になるなら、その機能は入れないか、別のツールにする。この基準は、チームメンバー全員が判断できる。個人の好みではなく、客観的な基準だ。
おわりに
ここまで読んでくれた人に、正直に書く。
この文章を書きながら、私は何度も手を止めた。「こんなこと書いて意味あるのか」「誰が読むんだ」「もっといい構成があるんじゃないか」。書いている最中に、書くのをやめる理由を探している自分がいた。「代表作」に届かない理由と、まったく同じ構造だ。笑えない。
2026年、私は隙間家具を20個作ると決めた。完璧じゃなくていい。動けばいい。使われなくてもいい。作ることそのものに意味がある。そう自分に言い聞かせている。
本当にできるかは、分からない。来年の今頃、GitHubにリポジトリが20個並んでいる保証はどこにもない。また「時間がなかった」「優先順位が」と言い訳しているかもしれない。その可能性は、正直、かなり高い。
でも、書いた。こうして宣言してしまった。
「何を作ればいいか分からない」という人へ。それは正常だ。ゴールは最初から見えているものじゃない。作っているうちに、少しずつ輪郭が浮かんでくる。だから今日、30分だけ時間を取って、最近「面倒だな」と思った作業を1つ書き出してみてほしい。それを解決するスクリプトを書く。動いたら公開する。それだけでいい。
20回繰り返す頃には、自分が本当に作りたいものが見えてくる。たぶん。見えてこなかったら、そのときはまた考える。
ところで、ここまで偉そうに書いてきたが、私は孤独な独身男性だ。家族はいない。守るべきものが少ない分、狂いやすい環境にいるとも言える。歯止めをかけてくれる人がいない分、自分で自分を律する必要がある。友達との飯の予定。ジムの予約。強制的に「コードを書かない時間」を作らないと、際限なく沈んでいく。独身には独身の戦い方がある。
OSSより大事なものはある。友達と話す時間。体を動かす時間。コードは逃げない。隙間家具はいつでも作れる。でも、友人との関係は放っておくと薄れる。健康は一度壊すと戻らない。狂うなら、余裕のあるときに狂え。順番を間違えると、人生ごと壊れる。
......と、説教じみたことを書いたが、たぶん来年の今頃の私は、この文章を読み返して頭を抱えている。「狂う」とか言って、結局また「そこそこ」で終わったじゃないか、と。
nwiizoというアカウントは、また少し大きくなっているだろう。「代表作」のハードルも、また少し上がっているだろう。自分で自分の首を絞める構造は変わらない。
それでも、諦めたくない。憧れたエンジニアたちがいる。彼らのように、「これを作りました」と胸を張れる日が来るまで、手を動かし続ける。
だから、書いておく。
まず狂え。量をやれ。そして、量が満ちたら、容赦なく削れ。
答えが出ない状態は、苦しい。でも、その苦しさの中を泳ぎ続けることでしか、本当に作りたいものは見つからない。完璧を待たない。不完全なまま公開する。恥をかく覚悟で、手を動かす。
2026年は、そういう年にする。できるかどうかは知らない。でも、やると決めた。
隙間を見つけたら、小さく狂おう。
このブログが良ければ読者になったり、nwiizoのXやGithubをフォローしてくれると嬉しいです。
