はてなブックマーク

はじめに SNSを開けば、今日もまた誰かが何かに本気だ。 新しい技術やフレームワークに興奮するエンジニア。最新のビジネス書を読んで「人生が変わった」と叫ぶビジネスパーソン。世の中の理不尽に憤慨し、世界を変えようと声を上げる活動家。生成AIの新機能やツールのアップデートに「未来が来た」と歓喜する人々。自己啓発系インフルエンサーの「新しい生き方」に感銘を受け、それがストア哲学やブッダの教えの言い換えに過ぎないと気づかない人々。 世の中には、あらゆることに本気になれる人がいるものだ。 私は、一歩引いた場所から、彼らを観察していた。興味深い現象として。分析対象として。 本を読んだ。いろんな本を。技術書も哲学書も歴史書も。視野が広がった。気づけば環境問題も、格差も、戦争も、技術トレンドも、ビジネス理論も、すべてが複雑に絡み合った世界が見えていた。 そして同時に、絶望も見えた。 簡単な解決策などない。

はじめに 「本が読めない」――多くの人がそう言います。それも、決して能力の低い人たちではありません。仕事は速く、正確で優秀な人たちです。それなのに、本が読めない。数ページで集中力が切れてしまう。気づくとスマホを見ている。「昔は読めたんですけどね」という声もよく聞きます。昔は確かに読めたのに、今は読めない。そして誰もが「最近集中力が落ちて」と言います。まるで集中力が老化とともに自然に衰えるものだと信じているかのように。 よく観察していると、ある共通点が見えてきます。すぐに答えを出そうとする。じっくり考えることをしない。検索して表面的な理解で満足してしまう。「調べればわかるし」と。確かに調べればわかります。でも、それは本当に「わかった」ことになるのでしょうか。 複雑な問題を単純化し、わかりやすい結論に飛びつく。白か黒か、正しいか間違っているか、そんな二元論的な答えを求める。グレーゾーンや曖昧さ

はじめに 「今日も、何もできなかった」。夜の部屋で、私はその言葉を呟く。また。今日も。 仕事をしなかったわけではない。むしろ一日中、何かをしていた。画面を見つめ、キーボードを叩き、メッセージを返し、タブを切り替え続けた。体は疲れている。目も疲れている。頭も疲れている。確かに疲労感はある。なのに、達成感がない。忙しかったのに、何も完了していない。この矛盾が、私を苦しめる。 朝、デスクに座った瞬間から、地獄が始まる。Slackを開くと未読の赤いバッジが十件以上浮かんでいる。「全部返信しなければ」。次にメールを開くと新着が三件ある。「これも返信しなければ」。GitHubのタブをクリックするとレビュー依頼が二件待っている。「これも見なければ」。そしてTwitterを開くとタイムラインに流れてくる技術記事のタイトルが目に入る。「これも読まなければ」。全部が重要に見え、全部をやらなければいけない気がす

はじめに どれだけ技術を学んでも、どれだけ正しいプロセスを知っていても、燃え尽きてしまったら意味がない。才能ある若者たちが最初は誰よりも速く理解して、誰よりも多くのコードを書いていたのに、数ヶ月後には姿を見せなくなる。「疲れた」と言って離れていく。 逆に、最初は遅くても数年経った今も黙々と学び続けている人たちがいる。彼らに共通しているのは、自分を大切に扱う習慣を持っていることだった。ちゃんと眠る。ちゃんと食べる。ちゃんと休む。そしてちゃんと掃除する。その中でも最も基本的な実践が、掃除だ。 在宅勤務を始めて六年目のある朝、ふと自分の部屋を見回した。 今、部屋は比較的綺麗だ。床に物は落ちていない。デスクの上も整理されている。技術書も本棚に並んでいる。窓を開けて空気を入れ替える習慣もついた。カーテンも開いていて、部屋の中は明るい。 30歳のエンジニア、独身。在宅勤務という働き方は自由をくれたはず

はじめに ワークショップが始まる三十分前、会場の隅で、一人の若者がノートPCの画面を凝視していた。 ブラウザには二十を超えるタブが開かれている。Dockerの公式ドキュメント、Kubernetesの公式リファレンス、Qiita、Zenn、個人ブログ。静かな会場に響くのは、マウスホイールを回す音だけで、彼は次から次へとタブを切り替えながら、何かを探すように、あるいは何かから逃げるように、ドキュメントを読み続けていた。読んでいた、という言葉はきっと正確ではなくて、目で文字を追っているだけで、その言葉が本当に頭の中に入っているかどうかは、おそらく彼自身にも分からなかったのだろうし、分からないことに気づかないふりをしていたのかもしれないし、あるいは気づいていたけれど認めたくなかったのかもしれない。 「準備しておかないと」 ぽつりと呟いた声は、誰に向けられたものでもなかった。会場には他にも何人か早め

はじめに 「才能がない」と言われたことがあるでしょうか。それとも、友人や知り合いと自分を比べて、自分で自分にそう言い聞かせたことがあるでしょうか。 学生の頃からエンジニアを志してきた私は、コンテストで優秀な成績を残す人たちを目の当たりにしてきました。大手IT企業に入社し、優秀な同期と出会いました。勉強会やカンファレンスに足を運び、そこで出会った人たちの軌跡を追ってきました。 華々しくスタートアップを立ち上げた人、革新的なプロダクトを生み出した人、OSSコミュニティで名を馳せる人。一方で、いつの間にか表舞台から姿を消した人もいます。これらがごく一部の狭い世界でしかないことも、自覚しています。 そして今、インターンシップやワークショップで若手エンジニアと接する機会が増えました。3年ほど前に始めたこの活動──正直に言うと、自分が未熟なまま始めてしまったという不安は、今でもどこかにあります。 彼ら

sizu.me はじめに 先日、「技術力に優劣はない（技育などに参加している学生に向けて）」という記事を読みました。技育に参加する学生たちへの励ましのメッセージで、技術との向き合い方の多様性を認め、コミュニケーション力の重要性を説き、相互リスペクトの大切さを訴える、とても温かい内容でした。 この記事は、あの記事の対象読者ではない私が、横から口を出すような形になってしまうことを承知で書いています。 元の記事の主張——技術の感受性には段階があること、ジュニアにはコミュニケーションが大事なこと、べき論に揺さぶられないこと、どの段階にいてもキャリアは作れること——これらは本質的に正しいと思います。 ただ、私はこう思います。それでもなお、技術力という軸においては、やはり優劣が存在し、それが中長期的なキャリアに大きな影響を与えます。 このブログが良ければ読者になったり、nwiizoのXやGithubを

はじめに 「Dockerでビルドすると遅いんだよね」「イメージが2GB超えちゃって…」 そんな会話はもう過去の話です。2025年、コンテナ化は劇的に進化しました。Rustも例外ではありません。cargo-chefとBuildKitキャッシュマウントの組み合わせでビルド時間を5-10倍短縮、2.63GBのイメージをdistrolessイメージで約50MB、musl静的リンクならわずか1.7MBという値を達成できます。 この記事では、実践的なDockerfileパターンとベンチマーク結果を詳しく解説します。 実際に検証したAxum Webアプリケーションでは、distroless版で50.3MB、musl+scratch版で1.71MBを達成しました。中規模プロジェクト（約500の依存関係）での初回ビルドは10分、コード変更後の再ビルドはわずか40秒です。 信じられないかもですが、これが202

はじめに 文章を読むとは、自分の中で文章を再構築するということである。 あなたは技術記事を読んで「わかった」と思ったのに、いざ実装しようとすると何も書けなかった経験はないだろうか。ドキュメントを読んで「理解した」と思ったのに、同僚に説明しようとすると言葉が出てこなかった経験はないだろうか。 私にはある。何度もある。悲しい。 これは単なる理解不足ではない。もっと根本的な問題だ。私たちは「読む」と「書く」を別々のスキルだと思い込んでいる。しかし、それは違うと私は考えている。読むとき、私たちは頭の中で文章を再構築している。書き手の言葉を、自分のスキーマ（枠組み）に翻訳し、自分の言葉で理解し直している。読むことは、実は書くことなのだ。ただ、それが頭の中で行われているだけだ。だから、「わかった」と思っても実装できないのは、頭の中で再構築したものと現実の折り合いがついていないのだ。自分の言葉で書き直せ

はじめに 自分の読解力に絶望する瞬間というものがあります。 たとえば、エラーログを読んでいるとき。無意識のうちに「こういうエラーだろう」という仮説を立てて、その証拠を探すように読んでしまっていました。問題を解決した後で同じログを読み返すと、「なんでこんな読み方をしたんだ？」と首をかしげます。明らかに違うことが書いてあるのに、自分の仮説に都合のよい部分だけを拾い読みしていました。 エラーログという機械が出力するシンプルな文章ですら、こうなのです。もっと複雑なドキュメントなら、どれほど読み間違えていることでしょうか？ライブラリのドキュメント、APIリファレンス、技術記事、PRのコメント、issueの議論、Slackでのやり取り。すべて同じ問題を抱えている可能性があります。 これは挑発でも誇張でもありません。「文章が読める人」は想像以上に希少で、自分も含めて、多くの人は書いてあることを読んでいま

はじめに 生成AIの登場により、専門家の役割は根本から問い直されている。 知識はもはや希少ではない。誰もが、数秒で専門家のような回答を得られる。では、専門家の価値はどこにあるのか？ この問いに、ジェラルド・M・ワインバーグ氏の『コンサルタントの秘密』は、40年前から答えを用意していた。彼が発見した「第三の道」——非合理性に対して合理的になること——は、生成AI時代においてどう進化するのか。 コンサルタントの秘密　技術アドバイスの人間学 作者:G.M.ワインバーグ共立出版Amazon 本ブログでは、生成AIという新しい道具が登場した今、専門家が本当に提供すべき価値とは何かを探る。専門家の価値は、もう知識の量では測れない。大切なのは判断力だ。情報を文脈の中で読み解き、的確な問いを立てる——それが今、求められている。 そして何より、責任を背負う覚悟だ。 ※この資料は社内共有会用に作成されたもので

syu-m-5151.hatenablog.com syu-m-5151.hatenablog.com はじめに 正直に言いましょう。システム思考の理論を学んだとき、あなたはこう思いませんでしたか？「で、これをどう使うの?」 前回と前々回の記事で、非線形性、フィードバックループ、氷山モデルを学びました。理論は美しく、説得力がありました。でも、実際の仕事に戻ると、こんな疑問が湧いてきます。 「このぐちゃぐちゃな状況を、どう分析すればいいんだ?」 「フィードバックループを見つけろって言われても、どこから探せばいいの?」 「複雑すぎて、何が何だかわからない」 そうですよね。私も同じでした。 システム思考は強力なツールです。しかし、白いキャンバスの前に立たされて「さあ、目の前の構造システムとして分析してください」と言われても、最初の一筆をどこに置けばいいのか、途方に暮れてしまいます。 でも、もし誰

syu-m-5151.hatenablog.com はじめに 前回の記事では、システム思考の基本的な概念—非線形性、関係性、反直感性、氷山モデル—を見てきました。システムをプラモデルではなく生態系として理解する視点を学びました。 しかし、概念を知っているだけでは意味がありません。テニスの本を読んでもテニスができるようにならないように、システム思考も実践してこそ身につくものです。理論を学んだ今、次のステップは「どう実践するか」です。 この記事では、日々の開発の中でシステム思考をどう使うかを具体的に解説します。取り上げるのは、自己認識の深め方、建設的な対話の作り方、フィードバックループの設計、パターンの見つけ方、そしてモデリングの実践です。これらはシステム思考の実践方法のほんの一部ですが、すべて明日から使える方法ばかりです。 特別なツールや権限は必要ありません。新人エンジニアでも、今日から、今

はじめに 先日、若いエンジニアと話をしていて、システム思考について話題になった。「物事を個別に捉えるのではなく、全体の関係性や相互作用を理解する考え方」—これがシステム思考の本質だ。僕は彼に、これはどんな分野でも応用できる基本的な教養だと伝えた。特にシステムを構築する立場の人には重要だけど、そうでなくても持っておいて損のないスキルだと。 世界はシステムで動く ― いま起きていることの本質をつかむ考え方 作者:ドネラ・Ｈ・メドウズ英治出版Amazon その会話を終えた後、ふと考えた。僕たちエンジニアは日々システムを作っているのに、どれだけ「システムとして」物事を考えているだろうか、と。 あなたは日々、コードを書いている。機能を実装し、バグを修正し、システムを構築している。そして、予想外の挙動に困惑することがあるかもしれない。完璧に動くはずの機能が、別の機能と組み合わせると謎の不具合を起こす。

はじめに nekogata.hatenablog.com を読みました。 オーナーシップを阻害する構造的な問題について丁寧な分析がされていて、なるほどと思う部分が多かった。しかし、私はこの問題の核心はもっとシンプルなところにあると考えている。 エンジニアが身銭を切っていない。それだけだ。 構造を変えても、制度を整えても、身銭を切らないエンジニアは責任を取らない。逆に、どんな環境でも身銭を切るエンジニアは結果を出す。言い方はなんでもよいが私はそういう覚悟のキマったエンジニアを何人も見てきた。 このブログが良ければ読者になったり、nwiizoのXやGithubをフォローしてくれると嬉しいです。では、早速はじめていきます。 身銭を切るとは何か 身銭を切るとは、「リスクと責任を自ら引き受け、成功すれば報酬を、失敗すれば代償を受け入れる覚悟を持つこと」だと、私は理解している。 ナシーム・ニコラス・タ

Claude Codeを使い始めて様々な発信をしてきましたが、Claude Codeに関する投稿は約2ヶ月ぶりです。この期間、他のアウトプットや諸々の事情で投稿が遅れてしまいましたが、今回は「Subagents」について書きます。 このブログが良ければ読者になったり、nwiizoのXやGithubをフォローしてくれると嬉しいです。 はじめに ここで読むのをやめる人のために言っておくと、Subagentsは「Claude Codeに尖った意思を持たせる」機能です。タスクごとに最適化されたAIを使い分けられます。 特定のタスクを実行するslash commandsとの違いは、slash commands（/コマンド）があなたが明示的に呼び出すショートカットであるのに対し、SubagentsはClaude Codeが文脈を読んで自動的に専門家を呼び出す点にあります。例えば、slash comma

はじめに 私はソフトウェアエンジニアだ。1年前、そう宣言した。「コードを書くこと以外で目立つな」と自分に言い聞かせた。 syu-m-5151.hatenablog.com で、どうなったか。 フォロワーが2000から9500になった。 笑うしかない。自戒したはずの私は、気づけばSNS戦略を「最適化」していた。分析して、仮説立てて、A/Bテストして、PDCAを回す。挙げ句の果てには「ソフトウェアエンジニアのためのSNSサバイバルガイド」なんてマニュアルまで書いていた。 note.com 完全にプロダクト開発と同じアプローチだった。要件定義（達成すべきゴール）、競合分析（類似アカウント）、実装とテスト（仮説検証）、リリースと運用（実行と点検）。SNSを攻略していた。 これもエンジニアリングなのか？パターン認識、システム最適化、メトリクス改善。使っているスキルセットは同じだ。ただ対象がコードやサ

はじめに プログラマーとして働き始めて数年が経った頃、私は壁にぶつかっていた。コードは書ける。バグも直せる。でも、何かが足りない。毎日キーボードを叩きながら、「これでいいのか」という疑問が頭をよぎる。 そんな時期に、勉強会で出会った人が一冊の本を勧めてくれた。私は勧められた本を買うのが好きで、その場で積読として購入した。今となってはその人の顔も名前も思い出せないけれど、あの時の一言には本当に感謝しています。『禅とオートバイ修理技術』――タイトルを聞いた時は、正直なところピンと来なかった。禅？オートバイ？エンジニアである私とどう関係があるのか。 禅とオートバイ修理技術 上 (ハヤカワ文庫NF) 作者:ロバート Ｍ パーシグ早川書房Amazon 禅とオートバイ修理技術 下 (ハヤカワ文庫NF) 作者:ロバート Ｍ パーシグ早川書房Amazon でも読み始めてみると、これが不思議と心に響いた。技

はじめに これまでPythonとGoでプロセス管理システムを実装してきましたが、今回Rustでも実装してみました。各言語にはそれぞれ得意不得意があり、プロジェクトの要件によって最適な選択は変わります。変なとこがあれば教えてください。 この記事では、Rustでプロセス管理システムを実装した経験を共有します。標準ライブラリのstd::processだけでは不十分な要件があったため、より高度な制御が可能な実装を行いました。 doc.rust-lang.org サンプルコードはこちらに配置しておきます。 github.com Python、Go、Rustでの実装経験から見えた違い 3つの言語でプロセス管理を実装してきた経験から、それぞれの特徴をまとめます。 Pythonでの実装 subprocessモジュールは高レベルで使いやすい asyncioとの組み合わせで非同期処理も可能 GILの影響で真の

はじめに ——あるいは、「知っている」と「理解している」の間 Rustのことは、知っていた。学習もしていた。実務でも使っていた。 でも、それは知っているつもりだった。 知ってるつもり　無知の科学 (ハヤカワ文庫NF) 作者:スティーブン スローマン,フィリップ ファーンバック早川書房Amazon 日々Rustで開発し、BoxとRcとArcを使い分け、tokio::spawnでタスクを生成し、?演算子を当たり前のように書いている。FFI？PyO3使えばいいでしょ。WebAssembly？wasm-bindgenがあるじゃない。技術的には、確かに「使える」レベルにはあった。 でも、心のどこかで感じていた違和感があった。 オートバイのエンジンを分解できる人と、エンジンが動く原理を理解している人は違う。コードが動くことと、なぜそう書くべきかを理解することも違う。私は前者だった。メカニックではあった

はじめに エンジニアの勉強会で、こんな経験はないだろうか。 「〇〇って知ってる？」「最近△△が流行ってて」「□□の記事読んだ？」「✗✗さんって知り合い？」 次から次へと断片的な情報を繰り出してくる人。どの話題も表面的で、深く掘り下げようとすると会話が続かない。 そして、ふと気づく瞬間がある――自分も同じような話し方をしているのではないか、と。 コードは書ける。タスクはこなせる。でも技術的な議論になると、借り物の言葉しか出てこない。 この恐怖を、多くのエンジニアが密かに抱えている(と思っている)。表層的な知識だけで話す「Fake野郎」――そう呼ばれることほど、エンジニアとしての信頼と自信を失う言葉はない。 何者（新潮文庫） 作者:朝井 リョウ新潮社Amazon 現代のエンジニアは、かつてないほど豊富な学習リソースに囲まれている。朝から晩まで技術記事を読み漁り、新しいフレームワークを追いかけ、

はじめに 正直に言って、AIエージェントを初めて理解しようとしたとき、私は完全に見当違いをしていた。単なる賢いチャットボットの延長線上にあるものだと思っていた。でも、実際に触れてみて驚いた。これは全く違う生き物だった。 エージェントとは「行為者性（agency）」を持つ存在だ。つまり、ただ反応するだけじゃなくて、目的を持ち、意図的に行動し、経験から学習する自律的な存在だ。これって、ある意味で「生きている」ということに近いんじゃないだろうか。 従来のソフトウェアを思い出してみる。入力に対して決まった出力を返す、予測可能な機械だった。でもAIエージェントは違う。確率的で、時に予想外の振る舞いを見せる。まるでデジタル世界に新しい種類の「生命」が誕生したかのような感覚を覚えることがある。 私たちは今、Andrej Karpathyが言うところのSoftware 3.0の時代にいる。自然言語がプログ

しんどくなったので説明した。良くなるかもしれないし悪化するかもしれません。 はじめに 私たちは常に「強くあること」を求められている。生成AIよりも成果を出すことを求められている。 NEXUS 情報の人類史 下　AI革命 作者:ユヴァル・ノア・ハラリ河出書房新社Amazon かつては人間同士の競争だった。同僚より早く仕事を終わらせ、他社より良い製品を作り、去年の自分を超えることが目標だった。しかし今、比較対象は常時稼働し、瞬時に大量のアウトプットを生成し、日々賢くなっていくAIになった。「毎年成長し続ける」「常に結果を出す」「社会の変化に乗り遅れない」という従来のプレッシャーに加え、「AIより価値のある仕事をする」という不可能に近い要求が加わった。 ブルシット・ジョブ　クソどうでもいい仕事の理論 作者:デヴィッド グレーバー岩波書店Amazon 朝、デスクに向かう。スマホには新しいAIツール

Claude Codeを使い始めて、様々な発信をしてきました。俺の(n)vimerとしてのアイデンティティを取り戻してくれたので感謝しています。settings.jsonやCLAUDE.md、.claude/commands/**.mdの設定について書いてきました。今回は「Hooks」について。これも設定しておくと、Claude Codeがグッと使いやすくなる機能です。 syu-m-5151.hatenablog.com このブログが良ければ読者になったり、nwiizoのXやGithubをフォロワーしてくれると嬉しいです。では、早速はじめていきます。 はじめに ここで読むのをやめる人のために言っておくと、Hooksは「Claude Codeがファイル編集した後に必ずフォーマッターを実行する」みたいなことを自動化できる機能です。CLAUDE.mdに書いても忘れちゃうようなことを、システムレベ

⚠️ 文章の半分以上を酔っ払った状態で作成しています。その点はご容赦下さい。 そのため良い文章ではある気がするのですが散文になってしまってます。 はじめに 「うちのエンジニアチーム、生産性どうなの？」 この質問を受けたとき、あなたはどう答えますか？Four Keysの数値を見せますか？プルリクエストの量を報告しますか？それとも、売上への貢献度を説明しますか？ dora.dev 昨晩、オタク達との飲み会で、この話題が出ました。先週、Findyさん主催の開発生産性カンファレンス2025があったからだと思います。 dev-productivity-con.findy-code.io 正直に言うと、私自身も長年この問題に悩んでいました。数値で示せと言われるけれど、何を測れば本当に意味があるのか。測定すれば改善するのか。そもそも測定する価値があるのか。経営層からのプレッシャーと現場の実情の間で、いつ

はじめに 私はかつて、自分の技術思想とキャリア戦略が100%正しいと信じて疑いませんでした。そして、それを受け入れない企業、同僚たちが100%間違っていると本気で思っていたのです。 今思えば、それはソフトウェアエンジニアという職業に就いた多くの若い人が陥る、ある種の思春期的な錯覚だったのかもしれません。技術的な正しさを盾に、社会的な配慮を無視し、人間関係の機微を「非論理的」と切り捨てていました(エンジニアの論理的なんて往々にして論理的ではないのに)。 この記事は、かつての私のような「正義のエンジニア」だった自分への懺悔であり、同じ過ちを犯している人たちへの警鐘でもあります。媚びないことと無礼であることの区別もつかないまま、技術的優位性を振りかざしていた—そんな恥ずかしい過去を、今こそ正直に振り返ってみたいと思います。 DD(どっちもどっち)論 「解決できない問題」には理由がある (WPB

はじめに 2025年6月29日、「#女オタ生成AIハッカソン 2025 夏の陣@東京」なる場において、「生成AIで小説を書くためにプロンプトの制約や原則について学ぶ」という題目で登壇させていただく機会を得た。ハヤカワ五味さんからお声がけいただいた時、私の中でエンジニアとしての好奇心が強く刺激された。エンジニアリングの視点から生成AIの本質を解き明かすことで、創作者の皆様に新しい視点を提供できるのではないか。異なる分野の知見を融合させることで、何か面白いことが起きるかもしれない。そんな期待を胸に、私は登壇に臨んだのであった。(これは嘘で前日不安で酒を飲みすぎた⋯。) note.com 実は、プログラミングの世界では既に大きな変革が進行している。Tim O'Reillyが最近発表した「The End of Programming as We Know It」という論考が示すように、AIの登場に