フォントの購入なら、国内No.1のフォント販売サイト《デザインポケット》へどうぞ。主要なフォントメーカーの書体はもちろん、ここでしか買えない希少な書体も多数取り揃え。取り扱いフォント商品 国内No.1のフォントダウンロードサービスです。

テクノロジーで好きなキャラクターが現実に。CODE27は声・表情・反応をリアルタイムで再現する、次世代キャラクター体験

## はじめに 年末、2025年を振り返る。フォロワーは7倍になった。副業も順調。書籍の執筆や翻訳にも関わった。登壇の依頼も増えた。どこからどう見ても、良い年だったはずだ。 なのに、胸の奥に澱のようなものが溜まっている。 コードは書いた。山ほど書いた。でもそれは、誰かに頼まれたコードだ。お金になるコード。評価されるコード。「これを作ってください」と言われて、「はい」と答えて、作ったコード。自分のためのOSSも、作った。公開もした。そこそこ使われもした。 でも、そこそこ止まりだ。「これが俺の代表作です」と言えるものが、ない。スターはついた。ダウンロードもされた。いくつかは今でも自分で使っている。完走した。自分なりに頑張った。でも、「代表作」と呼べるインパクトには届かなかった。 厄介なことに、nwiizoというアカウントは大きくなってしまった。フォロワーが増えた分、「代表作」のハードルも上がっている。昔なら「動くものを公開した」で満足できた。今は違う。期待値が上がった分、自分で自分の首を絞めている。 でも、諦めたくない。代表作を持つソフトウェアエンジニアに憧れて、この道に入った。あの人みたいになりたい、と思った先輩たちがいる。彼らのようにはなれていない。でも、まだ諦めたくない。 新しいプロジェクトを始めようとするたび、手が止まる。「既存のツールで十分じゃないか」「誰が使うんだ、これ」。もっともらしい問いを自分に投げかけて、そのまま手を下ろす。完走したプロジェクトはある。でも、次の一歩が踏み出せない。検証のふりをした、逃避だ。「作らなくていい理由」を探して、見つけて、安心している。 AIは「どう作るか」を教えてくれる。でも「何を作るか」は教えてくれない。技術力はもうボトルネックじゃない。足りないのは、決断だ。覚悟だ。「これを作る」と宣言して、不確実性の中に飛び込む蛮勇だ。 私は「隙間家具屋」を自称してきた。大きな家具は作らない。洗濯機と壁の間の収納。冷蔵庫の上のラック。誰も気にしないけれど、あると少し楽になる小さなもの。それを作るのが好きだった。はずだった。 2025年、隙間を見つける目は曇っていなかった。手も動いた。完走もした。でも、「これだ」という手応えが残らなかった。 副業は収入になる。登壇は評価される。ブログはフォロワーが増える。全部、目に見えるリターンがある。OSSは違う。作っても誰にも使われないかもしれない。時間を注いでも、何も返ってこないかもしれない。その「かもしれない」に怯えて、私は確実なほうへ流れやすかった。OSSは作った。完走もした。でも、賭け金を上げられなかった。時間を注ぎ込むより、確実なリターンがある副業や登壇に逃げた。結果、そこそこ止まり。「これだ」と言えるものは掴めなかった。 問題は、才能がないことだけじゃない。問題は、狂えなかったことだ。 どこにも振り切れなかった。副業も、登壇も、OSSも、全部やりたかった。全部にいい顔をして、どれにも本気を出せなかった。半端な賭け金には、半端なリターンしか返ってこない。当たり前のことだ。 このブログでは、「狂って量をやって、そこから引き算する」ための思考法を書く。 speakerdeck.com **結論を先に言う。まず狂え。量をやれ。そして、量が満ちたら、容赦なく削れ。** ## ポジティブケイパビリティとネガティブケイパビリティ 「ネガティブ・ケイパビリティ」という概念がある。**不確実さ、不思議さ、疑いの中に、結論を急がずに留まる能力** のことだ。 これに対して、「ポジティブ・ケイパビリティ」というのもある。**問題を分析し、解決策を導き、実行する能力** だ。ゴールが明確なときに発揮される力。私はおそらくだがこれが得意だ。 生成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種類に絞った方が購入率は高かった。選択肢が多すぎると、人は「選ぶ」という行為自体ができなくなる。 選択の科学 コロンビア大学ビジネススクール特別講義 (文春文庫 S 13-1) * 作者:シーナ アイエンガー * 文藝春秋 Amazon アイエンガー氏は『THINK BIGGER』で、選択肢が多すぎて選べないときの思考法を体系化した。その本質は「引き算」だ。課題を選ぶ、分解する、誰のためかを決める、材料を集める、何を作らないかを決める、他者の目で検証する。すべて「絞る」プロセスだ。 THINK BIGGER 「最高の発想」を生む方法：コロンビア大学ビジネススクール特別講義 (NewsPicksパブリッシング) * 作者:シーナ・アイエンガー * ニューズピックス Amazon 狂って量をやるフェーズでは、複数のアイデアが同時に走っている方が自然だ。順番通りに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つある。 **自分の不便** 。「こういうツールが欲しいのに、ない」という体験。私が作った隙間家具の中で、最も使われたものは、自分自身の問題を解決するために作ったものだった。自分が不便を感じているとき、そこには片づけたい「用事」がある。でも、それを片づける手段がない。 私のGithub リポジトリからのスクショ ここで疑問が浮かぶ。「自分の不便」が特殊すぎるときはどうするのか。自分だけが困っている問題を解決しても、誰も使わないのではないか。だから2026年、私はこう決めた。**最初は特殊すぎて構わない** 。なぜなら、特殊な問題を解決するツールでも、自分が本当に使うなら完成する。「誰かが使うかも」で作ったツールは、途中で手が止まる。まず完成させることが最優先だ。公開してみれば、同じ問題を抱えている人が意外といることに気づく。特殊だと思っていた不便が、実は普遍的だったというケースは多い。仮に本当に特殊で誰も使わなくても、自分の問題は解決している。それで十分だ。 **繰り返しの手作業** 。同じコマンドを何度も打っている。同じ手順を何度も実行している。毎回「面倒だな」と思いながら、やっている。 ここで立ち止まる。この問題は「自動化すべき問題」か、それとも「慣れるべき問題」か。ツール化することで、本当に人間の負荷は減るのか。自動化によって、別の複雑さを生んでいないか。 判断基準は、その作業が月に何回・何分発生しているかだ。月に1回、5分で終わる作業なら、自動化ツールを作るより慣れた方が早い。週に10回、毎回10分かかる作業なら、自動化する価値がある。感覚で判断しない。数字で判断する。 例えば、複数のGitHubリポジトリのCIステータスを確認するとき、1つずつページを開いていた。毎回、5分くらいかかる。週に5回やっていた。月に100分。年に1200分。ツールを作る価値がある。作った。5分が10秒になった。 **コンテキストスイッチ** 。ある情報を得るために、複数のツールを行き来している。Slackを見て、Grafanaを見て、ログを見て、またSlackに戻る。情報を一箇所に集めるツールを作れば、コンテキストスイッチが減る。頭の負荷が減る。判断が速くなる。 **暗黙知** 。「あの人に聞けば分かる」「Slackのどこかにある」「この手順は、前にやったことある人しか知らない」。暗黙知をツールに埋め込めば、誰でも同じことができるようになる。 **複雑さ** 。「このツールは高機能だけど、使いこなせない」「設定項目が多すぎて、何を設定すればいいか分からない」。高機能なツールが、その機能を使い切れていない人たちを置き去りにしている。彼らに、シンプルで分かりやすい選択肢を提供する。これも隙間家具の仕事だ。 ### 課題を分解する 課題が決まったら、5つまでに分解する。 私がよくやる失敗は、分解せずに作り始めることだ。「ログ保存ツールを作ろう」と思って、いきなりコードを書き始める。途中で「保存先どうしよう」「認証どうしよう」「エラーハンドリングどうしよう」と考え始める。そのたびに手が止まる。最初に分解しておけば、こうはならない。 「〇〇を作ろう」だけでは手が動かない。サブ課題に分解して、5つまでに絞る。5つに絞るのは、正直、苦しい。あれもこれも入れたくなる。でも、ジャムの法則と同じだ。サブ課題を10個、20個と出すと、どれに注力すべきか分からなくなる。 **例** : 「Podが再起動したときに直前のログを保存するツール」 1. Podの再起動を検知する仕組み 2. 直前のログを取得する方法 3. ログを保存する先（S3など） 4. CLIのインターフェース 5. エラーハンドリング 分解した項目が、そのまま実装の順番になる。「これは本当に必要か？」と自問すると、いろいろ見えてくる。実は同じことをしている項目。なくても動く項目。別のツールに任せた方がいい項目。削ることで本質が見える。 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**をフォローしてくれると嬉しいです。 ## 参考文献 人生にコンセプトを (ちくまプリマー新書) * 作者:澤田智洋 * 筑摩書房 Amazon センスは知識からはじまる * 作者:水野学 * 朝日新聞出版 Amazon センスの哲学 (文春e-book) * 作者:千葉 雅也 * 文藝春秋 Amazon 人生の経営戦略――自分の人生を自分で考えて生きるための戦略コンセプト２０ * 作者:山口 周 * ダイヤモンド社 Amazon 「面白い！」を見つける ――物事の見え方が変わる発想法 (ちくまプリマー新書) * 作者:林雄司 * 筑摩書房 Amazon THINK BIGGER 「最高の発想」を生む方法：コロンビア大学ビジネススクール特別講義 (NewsPicksパブリッシング) * 作者:シーナ・アイエンガー * ニューズピックス Amazon わかったつもり～読解力がつかない本当の原因～ (光文社新書) * 作者:西林 克彦 * 光文社 Amazon 知ってるつもり 無知の科学 (ハヤカワ文庫NF) * 作者:スティーブン スローマン,フィリップ ファーンバック * 早川書房 Amazon 私が間違っているかもしれない * 作者:ビョルン・ナッティコ・リンデブラッド,キャロライン・バンクラー,ナビッド・モディリ * サンマーク出版 Amazon 不完全主義 限りある人生を上手に過ごす方法 * 作者:オリバー・バークマン * かんき出版 Amazon 熟達論―人はいつまでも学び、成長できる― * 作者:為末大 * 新潮社 Amazon 新版 いくつになっても、「ずっとやりたかったこと」をやりなさい。 * 作者:ジュリア・キャメロン,エマ・ライブリー * サンマーク出版 Amazon いくつになっても恥をかける人になる【DL特典 恥克服ワークシート】 * 作者:中川諒 * ディスカヴァー・トゥエンティワン Amazon 増補改訂版 スマホ時代の哲学 なぜ不安や退屈をスマホで埋めてしまうのか (ディスカヴァー携書) * 作者:谷川嘉浩 * ディスカヴァー・トゥエンティワン Amazon 自分とか、ないから。 教養としての東洋哲学 * 作者:しんめいP * サンクチュアリ出版 Amazon 人生のレールを外れる衝動のみつけかた (ちくまプリマー新書) * 作者:谷川嘉浩 * 筑摩書房 Amazon 行動する人に世界は優しい―自分の可能性を解き放つ言葉― * 作者:佐藤航陽 * 新潮社 Amazon