プログラマの三大美徳として、「怠惰、短気、傲慢」が知られている。Perlの公式ドキュメントにも、プログラマの三つの美徳として挙げられている。 ここでいう怠惰とは、将来の労力を減らすために、いま自動化や改善へ手間をかける姿勢である。 この考え方は重要だ。 繰り返しの作業を自動化したり、仕組みを改善したりすることは、エンジニアリングの本質の一つでもある。 ただし、「楽にすること」と「楽しむこと」は同じではない。 不要な負担は減らした方がよい。 それでも、仕事や人生には、どうしても楽にはできない時間がある。 この記事では、不要な苦労を減らしながら、避けられない試行錯誤の中に楽しさを生み出す方法、楽しむ技術について紹介する。 2026/07/14 追記 そもそも「楽をしたいだけ」のTakerはこれより以前の話である。 ちなみに「君は楽をしたいだけで、楽にすることもできてない。」って話も良くする。

今回、あきらくんの支援をすることにした。 have-fun.tech この支援をしようと思った背景と、格ゲーコミュニティとプロゲーマーについて思うことを書く。 格ゲーコミュニティはデカくなった 最初にやった格ゲーはスト2。 中学生になってゲーセンに通うようになり、KOF98の頃には地元では強いほうでそのまま高校からはカプエスやギルティという感じでゲーセンで通ってた25年前*1。 あの頃は闘劇があったり、小さいゲーセンの大会があったりで盛り上がってたと思う。だけどここ10年でしっかり衰退して、ゲーセンもどんどん無くなって、格ゲーはこのまま衰退していくのかなと思っていた。 それがスト6というバケモンな大ヒット作が出て、あの当時を超えるような盛り上がりを見せている。 EVOJも何年も参加しているけど、7000人を超えるような大会は例がない。 熱量も闘劇やサミーズカップよりも高いように思う。 特に

下記の記事の解説のPostgreSQLにフォーカスしたslideです。 https://soudai.hatenablog.com/entry/2026/06/05/153530

Djangoのデファクト・スタンダードなRDBMSはPostgreSQLである。 せっかくPostgreSQLを選んでいるなら、PostgreSQLの機能を使わないのはもったいない。 そこで今日はDjangoを利用した開発者がPostgreSQLのどんな機能を知っておくと便利か、という話をする。 例えばこのブログでも紹介しているがPostgreSQLにはJSON、配列、範囲型、排他制約、全文検索、部分インデックス、空間情報、パーティショニング、拡張機能など、アプリケーションの設計を簡単にしてくれる機能が多い。 Djangoもそれを分かっていて、django.contrib.postgres や django.contrib.gis を用意している。 今回はこのようなDjangoユーザがPostgreSQLを使うなら知っておくと便利な機能をまとめる。 なお、記事を眺めるだけだと分かりにくいも

PostgreSQL 15以降 *1 にも、ソフトウェア開発者やDBAが知っておくとよい機能が増えている。 全部を覚える必要はないが、設計や運用の選択肢として知っておくと良い機能をいくつか紹介する。 PostgreSQL 15 なんと言っても UNIQUE NULLS NOT DISTINCT はDjangoユーザに限らず分かりやすく、強力な機能である。 従来、SQLのNULLは一意制約上では別物として扱われるため、NULLが複数入ることを許していた。 しかし業務上は「値が未設定の行も1件だけにしたい」という要件がある。 PostgreSQL 15以降ではこれをDB制約として扱える。 あと MERGE構文も追加された。 自分はINSERT CONFLICT構文でことが足りることが多く、あまり使っていないが差分のDELETEなどをしたい場合はMERGE構文を使うことになる。 PostgreS

そーだい（@soudai1025）です。ソフトウェアエンジニア / データベーススペシャリストです。予防医療領域のスタートアップでCTO・COOを務めながら、技術と事業、組織の間に落ちる問題を拾って前に進める仕事をしています。 専門はRDBMS、特にPostgreSQLを中心としたデータモデリングやシステム改善。 一方、現場では「誰が決めるのか」「何を決めるべきか」が曖昧なまま止まる仕事に向き合うことも多く、技術だけではなく、意思決定や構造整理も含めて仕事を進めることを大切にしています。 その中心にあるのが、「誰もやらないけれど、誰かがやらなければならない仕事」を前に進め続けることです。 「誰もやらない仕事」とは、みんなやった方がいいとわかっているのに、誰も手をつけない仕事のことです。ドキュメントの整備、テストの追加、CIの改善、再現性のない障害の調査。こういった仕事は優先順位リストの下に

こんにちわ。せじまです。 むかしむかし、社内勉強会で話した内容を公開させていただくということが何度かありました。 TIME_WAITに関する話 EthernetやCPUなどの話 CPUに関する話 先日、社内で「データベースを異なる環境や互換性のあるマネージドサービスなどに移行する際、どういうことを考えてるか、幅広い層に向けて話してください」といった要望がありまして。 久々に話をさせていただきましたので、そのときの資料を公開させていただくことにしました。（いちおう、Speaker DeckにもSlideshareにも両方アップロードしておきました。） 互換性のある（らしい）DBへの移行など考えるにあたってたいへんざっくりfrom Takanori Sejima ※このスライドの内容を全部話すと100〜120分くらいはかかりそうなので、社内ではかいつまんで話しました。 個人的に、データベースの

TechLead Conference 2026 powered by connpassの登壇資料です。 https://sansan.connpass.com/event/387148/

設計ナイト 2026の登壇資料です。

ブログを書くまでが #onishi50 ということで感想を書きます。アナウンスしておりました、劇場版 Onishi Half Century Conferenceを無事開催できました！おっさんの誕生パーティーにたくさんの方にお集まりいただき感謝です！ 2/15 劇場版 Onishi Half Century Conference 同時上映 新春大LT大会 @京都 のお知らせ #onishi50 - 大西ブログ 劇場版 Onishi Half Century Conference 同時上映 新春大LT大会 - connpass 参加者を見てもらうとわかるのですが、YAPCキーノーターが何名もいたり、関東からお越しいただいた人もたくさんいたり、海外からの参加者もいたり、と60名近くの方に集まっていただいた大変豪華な会になりました。本当にありがとうございます。 きっかけ 本日誕生日を迎え50歳に

エキスパートは突然生まれない。 やるべき仕事で結果を出し続けた人だけが、周囲からエキスパートと呼ばれるようになる。 プロフェッショナルな振る舞いについては、以前の記事で書いたことがある。 soudai.hatenablog.com 今回は、新卒から2〜4年目の若手エンジニアがエキスパートになるために何をすればよいのかについて説明する。 エキスパートとは何か エキスパートとは、ある分野において専門的な知識や技能を持ち、その分野で高い成果を出せる人のことを指す。 つまり、エキスパートとして認められるには、評価者が求める水準を超える成果を出し、認められる必要がある。 そのためには何が必要なのか。 重要なのは、 特定の分野に詳しい人では足りない ということだ。 例えば下記のような例だけではエキスパートとは呼ばれない。 本を読んでいる 資料をよく知っている SNSで発信している 実際の現場で問題を解

ある日の終電後。オフィスには私しかいなかった。 蛍光灯は半分消えている。デスクのモニターだけが、青白い光を放っている。IRCの通知は止まっている。誰も見ていない。誰も知らない。今、私がここで何をしても、誰にも分からない。 三時間前、本番環境で障害が発生した。 顧客からの問い合わせが殺到した。Nagiosのアラートチャンネルが真っ赤に染まった。私はオンコール担当だった。原因を調査した。特定した。十五年前に書かれたコードの中に、バグがあった。 なぜ今頃発火したのか。おそらく、長らく使っていたNFSの性能が落ちていたからだ。十五年間、たまたま踏まなかった地雷を、今夜ついに踏んだ。バグは十五年前からそこにあった。ただ、表に出てこなかっただけだ。 障害は収束した。暫定対応でサービスは復旧した。しかし、根本原因を修正しなければ、また同じ障害が起きる。明日の朝までに、修正をリリースしなければならない。

学ばないとAIを活用できる人とそうでない人の差が広がる、という話を前回書いた では、実際に学ぶためにはどうすれば良いのだろうか。という話を今回はする。 soudai.hatenablog.com 今回の大きなテーマは内省のサイクルを回すために必要なネクストアクションの設定である。 そのために必要なポイントを説明していく。 ネクストアクションを設定する重要性 まず、兎にも角にもネクストアクションを設定することが重要である。 これはよく、1on1などでフィードバックすることでもあるが、コルブの経験学習モデルにおける具体的経験→内省的観測→抽象的概念化→能動的実験のサイクルを回すために必要なことはまず行動することであるからだ。 この話は1on1を定期的にやっている id:da1chi24 も書いている。 da1chi.hatenablog.jp 2023年、最初の1on1で悩みを相談した際、自分

来週、学生たちに向けて『AI時代に学ぶ意味』というテーマで講演を行う予定で、その要点をここにまとめておく。 AI時代に学ぶ意味 概ね、理由は以下のとおり。 良い質問をするために知識が必要 AIの出力を評価する 抽象的なアドバイスを活用する これらを実行するためには、一定の知識とスキルが必要である。 スキルを身につけるためには基礎知識があるうえで経験が必要であり、そのサイクルがまさに学びなのである。 そのため、AIが普及したとしても、人が学ぶことの重要性は変わらない。 その前提を踏まえたうえで、各ポイントについて説明する。 良い質問をするために知識が必要 AIに質問する際には、質問の意味を理解している必要がある。 そして質問するにはまず、自分の無知の状態を認識しなければならない。 無知には5段階のレベルがあって、自分がどの状態にあるのか理解する必要がある。 これをFive Orders of

はじめに 師走も佳境ということで、自分の開発環境に新しく導入したツールや本年もお世話になったツールを棚卸しがてら紹介できればと思います！ 前提: 普段の開発スタイル 中学生という多感な時期にブラッディ・マンデイというドラマにハマってしまったせいで、ターミナルみたいな無機質な画面に向かって作業することがかっこいいと思っているエンジニアです。そんなわけで、普段の開発はNeovimを使い、ターミナルから出ない生活を送らせていただいてます。 最近は業務でフロントもバックエンドも触るので、tmuxで複数サーバーを立ち上げて切り替えながら作業しています。雰囲気はこんな感じです。 ターミナルはもちろん透過させてます。 私は新しいクルトガを買ってもらうと勉強を頑張れたタイプの人間なので、開発環境も同じ。ツールを自分好みにして気分を上げることで、作業効率も上げていくスタイルを採用しています。 それでは、以下

この記事は「そーだいなる Advent Calendar 2025」の　「13日目」　の記事です。 adventar.org アカセさんの記事を読んでいて、「チケットまで取った映画を観に行かずにクリスマスイブに飲み明かした」ってエピソードで大変笑わせてもらった思い出が蘇り、自分もお礼(なのか？)に書いてみようというものです。 クリスマスにドラゴンボールの映画観ずに飲んでた話、聞いてて爆笑させてもらったので「俺もそーだいアドカレ書かないと行けないかもな？」って気分になってきた 何か書くかも https://t.co/dxjIRI2mIz— 今日も誰かのにちようび(おいしい鮭親子丼) (@o0h_) 2025年12月31日 スライドのつくりを途中から変えた スライドを作る時にそーだいさん風のやつを真似しております。 伝わるでしょうか、こういうやつです。 実際の例として、先日のPHPカンファレン

はじめに前職で技術顧問として そーだいさん にJOINしていただいていた際、私はデータベース設計から仕事の進め方相談まで、本当にお世話になりました。 そーだいさんは「ガタイも(物理的に)声も大きくて、ちょっと圧倒されるな……！」というものでしたが、実際にお話ししてみると、その中身は驚くほど優しく、そして本当にロジカルで誠実な方でした。 その圧倒的な「言語化能力」で、技術的な課題はもちろん、エンジニアとしての振る舞いや問題解決の考え方を、誰にでもわかる言葉で解きほぐしてくれます。 今回は、私が定期的に読み返し、1on1などの場でも「まずこれを読んで！」と周囲に布教している、そーだいさんの発信をいくつか紹介したいと思います。 1. 仕事を進めるうえでのマインドセット1-1. Howだけ考えると複雑さを導入して仕事が増える 「偽の進捗」の連鎖によるリソース枯渇の防止 手段に没頭して手順書の保守や

adventar.org この記事はそーだいなる Advent Calendar 2025の8日目の記事です。 そーだいさんはわたしが働いている会社の取締役CTO兼COOです。 soudai.hatenablog.com 株式会社リンケージで働いております、青ごへいもちです。 2025年4月頃からEM（エンジニアリングマネージャー）の役割を少しずつ担うようになったのですが、当初の自分は、漠然とした「不安」をたびたび感じていました。 なんかつらいな… モヤモヤするな… 自分が無能に感じるな… タスクの進捗、組織の課題、メンバーのマネジメント……。それらに対して、 マネージャーたるもの全て完璧にこなすべし 全部把握できていないと怒られるのではないか さまざまな事象に対して「正解」を持っている必要がある といったプレッシャーを、勝手に背負い込んでいたように思います。 現在、CTOのそーだいさんと

この記事はそーだいなる Advent Calendar 2025の23日目の記事です。 そーだいさんに関する記事であれば何でも良いとのことでしたので、今回は私がそーだいさんと初めてお会いした時に”救っていただいた”話をさせていただきます。 そーだいさんとの初対面 そーだいさんと初めてお会いしたのは、とある山間の谷の街へと続く田舎の畦道...ではなく、高円寺の餃子屋さんでの飲み会でした。 私が所属しているTechBullというコミュニティで、主催の安達さんが「そーだいさん飲み会」を開いてくれたことがきっかけでした。 その時私はすでにそーだいさんの著書である失敗から学ぶRDBの正しい歩き方」を読んでいたので、「作者の人に会える！」とワクワクしながら飲み会に参加しました。 飲み会は10名ほどのメンバーが集まり、そーだいさんを囲んで色々なお話をさせていただきました。 そーだいさんに若手エンジニアが

adventar.org これはそーだいなる Advent Calendar 2025の1日目の記事になります。 そーだいさんが行っている「荻窪.なにか」というコミュニティがあります。 前半読書会、後半飲み会という構成になっていることが多く、後半の飲み会は自己紹介＋読んだ本の紹介というところからスタートします。 読書会という形式のため、そーだいさんと関係ない方どころか、エンジニアでもない方がふらっといらっしゃったりもすることがあったりします。 年齢層は、他の勉強会ではなかなか例を見ない幅広い…… ジュニア〜レジェンド級まで、その時々で顔ぶれが変わり、当然読んでいる本も技術本から一般教養、小説等々まで様々になります。 この「荻窪.なにか」に参加しなければ知らなかったような本に出会うことも多く、積読を消化するのが目的の読書会にも関わらず、積読が更に増えるという脆弱性がこのイベントにはあります。