プログラマの三大美徳として、「怠惰、短気、傲慢」が知られている。Perlの公式ドキュメントにも、プログラマの三つの美徳として挙げられている。 ここでいう怠惰とは、将来の労力を減らすために、いま自動化や改善へ手間をかける姿勢である。 この考え方は重要だ。 繰り返しの作業を自動化したり、仕組みを改善したりすることは、エンジニアリングの本質の一つでもある。 ただし、「楽にすること」と「楽しむこと」は同じではない。 不要な負担は減らした方がよい。 それでも、仕事や人生には、どうしても楽にはできない時間がある。 この記事では、不要な苦労を減らしながら、避けられない試行錯誤の中に楽しさを生み出す方法、楽しむ技術について紹介する。 2026/07/14 追記 そもそも「楽をしたいだけ」のTakerはこれより以前の話である。 ちなみに「君は楽をしたいだけで、楽にすることもできてない。」って話も良くする。
自分のまわりですごいなと感じた人は、なんだか目立っていたことが多かった気がする。 そういう目立つ人は何が違うのか、何をしているから目立つのか よくわかっていないので、思い出しながら雑に考えてみる。 考えてみたけれど、2つくらいしかないかもしれない。 1. 問題を解決する 目の前の問題を解決するために、自分がすべきこととできることを常に考えてる感じがする。 ボールが浮いていたら手を上げる、会議で気になることがあったら発言する、直接関係していなくても必要だと思ったら越境する、といった動きは全部問題解決のため。物事を前に進めるために自分が何をするべきか、何ができるかをとにかく考えて行動してる。 特徴としては、失敗を気にしすぎないこと、領域を区切りすぎないこと の2つがあるかも。物怖じせず、誰の仕事かを過度に考えすぎず、問題解決に必要なことは全部やるというスタンスを持ってる。いわゆる "オーナーシ
いわゆるIT系で働き始めて27年ほどが経ちました。転職したり会社が買収されたりして、結果的には7~9社で働いてきました。(転職を沢山したわけではなくカウント方法が複雑なため)前職は20年所属していたのでしっかり長めに働いていました。 働くうちに立場が変わっていき、長く働いていると失敗も成功もしてきました。その過程でずっと疑問だったことがありました。 「なぜ、あの人は信頼されるのか」 はじめのうちは、年長者だからとか役職者だからとかスキルがあるのだと思ってたけど、どうやら違う。頭がめちゃくちゃいい人より、そうでもない人のほうが信頼されてることがある。営業成績がいい人より、売上はそうでもないけど周囲に頼られている人がいる。 その信頼を勝ち得ている彼らは何が違うのか。観察を続けて気づいたのは信頼とは毎日の地味な態度の積み重ねということ。特別なスキルではなくむしろ基本。基本こそが最も大事だというこ
2026年6月17日（水）開催の「エンジニアの役割の変化に向き合うConference」での発表スライドです。
https://forkwell.connpass.com/event/395423 の登壇資料です。
私はエンジニアになってから何度も「マネージャー向きですね」と言われてきた。 理由もなんとなく分かる。問題を整理するのが好きだし、複雑な状況を構造化するのも好きだし、人の認識を揃えるのも好きだからだ。 技術的な課題が絡み合っている状況を見ると、まずは図にしたり論点を書き出したりしたくなる。 そういう振る舞いをすると、「それってマネージャーの仕事ですよね」と言われてきたし、実際にマネージャーになってみたこともあった。 そして時には、もっと直接的に「技術の人じゃないね」と言われたこともあった。 当時の私は、その言葉を半分受け入れていた。 でもずっと違和感も持っていた。 私はマネージャーになりたいわけではなかった 誤解のないように言うと、マネージャーという仕事を否定したいわけではない。実際に優れたマネージャーにもたくさん出会ってきた。ただ、自分がやりたいこととは少し違った。 私は人事評価に強い興
これは何か 今月末で今の職場を離れることになったので、ふりかえりも兼ねて。 これまでの経歴的にスタートアップで働くことが多かったので、前職に限らずこれまでのキャリアをふりかえってみて、日頃どんなことに気をつけながら働いていたか、あるいはこれまでの人生で「もっとこうすりゃよかった」みたいなしくじりを整理したもの。 前職を辞める前に社内でLTぽく話したのを少し改変している。 前提：私はこういう性格 自己肯定感が低い 今やってる仕事は別に誰でもできるよな〜とか思っちゃう ので、俺すごくね？って滅多に思わないし、こんなんやりましたでドヤ！みたいな発信が苦手 他者とのコミュニケーションに必要以上に気を使いがち Slackの投稿文は何回も何回も考えてようやく発信してる @全社all メンションとか極力打ちたくない おしながき 自分が気持ちよく働ける限界値を把握しよう ワイはできてた度：★★★★☆ 周り
時間が全く取れないことはないはずなのに、なぜか時間が過ぎ去っていて時間が取れていないことあるよな。俺はある。そういう時に自分がやるべきことを雑に書き殴ってみる。 やめてみる 勝手に自分がやらないといけないと考えてるだけで、たいてい今自分がやらなくていいことをいっぱいやってるよ。「これやめたら何がどのくらい困るんだっけ？」と一度立ち止まって考えて、思い切ってやめてみるといい。自分だけで想像せず、関わる人に直接聞いてみるのがオススメ。 特にオブザーバーで入ってるミーティングとかね。なんか不安ってだけで出席してるミーティングが週に3つとか入っていないか？まず2週間出ないでみてどうなるか振り返ってみるのもいいと思う。たぶん何の問題もないことに気づけるよ。そうでなくとも関わり方が変わるはず。 立ち止まる 自動化、効率化にちゃんと時間を使わないとジリ貧になる。「2日あったら仕組みを作れるか？」と自分に
AIとかニンゲンとか関係なく、自分なりの意見を持つ癖をつけたほうがいいと思っているんだけれど、あまり考えがまとまっていないので雑に書き殴ってみる。 何事にも「自分はこうしたい」、「自分はこうすべきだと思う」、「自分ならこうする」といった自分の意見を持っておけという話。自分がオーナーの場合にはより強く具体的に持つべきだけれど、そうでなくても自分の考えを持っておいたほうがいい。 意見が正しいかどうかはあまり重要ではなくて、 "自分なりの意見を持つこと" 自体がまずは大事。当たり前やろと思う人もいるかもしれないが、これは意外と訓練が必要で、慣れないとできない。 特に自分がオーナーじゃない時の方がむずかしくて、自分の意見を持てていないことを自覚できていないこともある。オーナーやまわりの意見に対して「たしかに」、「わかる」、「それもいい意見」のような感じで中途半端な同意を示しても意味がない。誰かの意
「ハーネスエンジニアリング」がこの半年で広がった 2026年に入ってから、AI業界で急に飛び交いはじめた言葉がある。「ハーネスエンジニアリング」だ。 OpenAIが2月に「Harness engineering」という解説記事を公開し、Anthropicは前年11月に「効果的なハーネス」を語った。LangChainは「エージェント＝モデル＋ハーネス」というスローガンを出し、ミッチェル・ハシモトが「ハーネスを設計せよ」、マーティン・ファウラーが「ループの中ではなく、外側で人間がハーネスを直すべきだ」と書いた。 半年で、AIを実務に組み込もうとする組織にとっての中心語の一つになった。 「同じモデルでも性能が変わる」という発見 「同じAIモデルなのに、性能が大きく変わる」という現象が次々と報告されたのが大きい。 LangChainが2026年2月に公開した実験では、ある長時間タスクのベンチマーク
自分がオーナーシップを持って物事を進める時には、少なくとも組織内ではその領域のことを一番考えているという自信を持つほうがいいと思っていて、そのあたりの話を雑に書いておきたい。 なんでかというと、結局一番考えてないと説明責任を果たせないからなんだよな。たとえば「なんでこういう方針にしたんですか？」、「このあたりは考慮できていますか？」みたいにまわりから聞かれた時に、「それはもう過去に私の脳が通ってきた道だ」みたいな感じで二周目状態になっていないと説明できない。 自分は昔「説明責任とかしゃらくせえ、"遂行" できればええやろ」と考えていたことがある。それはそうで、小さいタスクだとそれで全然OK。けどねぇ、なんかうまくいかなくなるんだよな。説明しながら "刻む" 進め方を身につけないと、物事を前に進められなくなってくるのよ。もしかしたら "圧倒的" なレベルの人はそんなことはないのかもしれないけ
生成AIを使った開発。個人としては少し手に馴染んできているけど、チームでの開発はどう取り組むのがいいんだろうな？と思っている。この記事は、やってみた結果どうだったというものではなくて、これから試行錯誤するための頭の中の整理。 僕が自分の手でコードを書くことはもうない まず、AIを使っていて感じるのは「今後、僕が自分の手でコードを書くことはないだろう」ということ。すでにこの数カ月間、自分ではコードを書いていない。 誰かと仕事をするときに、コーディングを一緒にするのはいい時間だったなぁと思う。ペアプロやモブプロで知識の交換をしたり、新しいメンバーを受け入れたり、若手を育成したり、そういうときにコードを見ながら「ここはこうしましょう」「それはどうしてですか？」みたいに話せるのはとてもよかった。 でも今後は、そういう時間は中心にはならなさそうに思う。コーディングは誰かと一緒にやるよりは、1人でAI
OpenAI の以下の記事が面白かったので、簡単にまとめました。 ・Harness engineering: leveraging Codex in an agent-first world 1. はじめに過去5ヶ月間、私たちのチームはある実験を行ってきました。それは、手作業で書かれたコードを一切含まないソフトウェア製品の内部ベータ版を構築しリリースするというものです。 この製品には、社内で日常的に利用されるユーザーと、社外のアルファテスターがいます。製品はリリース、デプロイ、そして不具合が発生し、修正されます。これまでの製品と異なるのは、アプリケーションロジック、テスト、CI設定、ドキュメント、可観測性、そして内部ツールに至るまで、すべてのコード行が「Codex」によって記述されていることです。手作業でコードを書く場合の約10分の1の時間で、この製品を開発できたと推定しています。 人間が
たしかに～となった。 Markdownは人間が書きやすくするために表現力を落としてる。でもAIが書くのであれば、わざわざ表現力を落としたMarkdownを使う必要がない、という話。 ※ 補足 AIが「設計確認して」って出してくるMarkdownを読むのはつらい、全部よまないよね、HTMLであれば より読みやすい形、インタラクティブな形になって確認しやすいよね、AIが書くならHTMLでいいよね、という文脈。 確認モレで余計な生成が行われるより、ちょっとリッチに確認しやすい文書だしてもらって、意図通りの生成が走るほうがトータルのトークン数も節約できると思う。 補足おわり ※ もうひとつ追記 いまのAIが、HTMLの出力について、わかりやすく伝わりやすいものが出力できるよう重点的に学習されていることも踏まえておいたほうがいいと思う。 HTML版とJava版で同じアプリ作っても機能性が全く違うよう
上司になる人にアドバイスするとしたらどういうことを伝えるだろうか？ 機能する上司になるのはほんとに難しい。 役職は会社から与えてもらうことができるが、、だからといって部下がついていくかどうか？は別物だ。フォロワーシップのない管理職は本人も部下も辛い。 はじめて管理職になったのはたぶん32歳のときだった。当時の職場には管理職トレーニングなんてなかったし、そもそも上司ってほとんど見たことなかったし（小組織にしかいたことなかった）で、とりあえず現場プレイヤーのまま管理職になり、そのまま突進して、そして組織がでかくなって見事にいちど自分自身でパンクした。 そのときに幾つかの本を読み始めたんだがその一冊がジャックウェルチのエグゼクティブコーチをしてた人の本。 そこにリーダーにありがちな悪癖が20ある。おもいあたることがみなさんもないだろうか？ 極度の負けず嫌い 何かひとこと価値を付け加えようとする。
こんにちは。 朝日新聞社CTO室・採用担当です。 今回は社外CTOの広木大地氏に、「AI時代にエンジニアは不必要か」をメインテーマに、AI時代への向き合い方、エンジニアの目指すべき姿、今後の展望などを伺いました。＜全2回＞ 90対9対1の法則歴史を振り返ってみると、インターネットが登場した当時、多くの人がこう言っていました。「世界中の人とコミュニケーションが取れて、自分で何でも発信できるんだ」と。その時にインターネットを使って世界中の人とコミュニケーションを取り、自分が発信していた人は非常に少なかったんです。実際には、それをやっていない人が多かったですね。 ツールが登場すると、個人がエンパワーメントされるという歴史の繰り返しがあります。1人ではできないと思っていたことが、パーソナルコンピューターによって可能になりました。パーソナルコンピューターの登場により、個人の能力が拡張されました。次に
はじめに 2026年4月17日（米時間金曜）、Anthropicが Claude Design を research preview として発表 自然言語でプロトタイプ・スライド・モックアップ・LPを作れる、Claude Opus 4.7ベースの新機能 競合は Figma Make / v0 / Lovable / Bolt / Google Stitch / Gamma / Canva 発表前後で Figma -6% / Wix -4.7% / Adobe -2.7% / GoDaddy -3% と市場は結構まじめに反応 「Webデザイナー・フロントエンドの仕事が丸ごと消える」のではなく、「初稿を作る工程」と「単純なUI実装」から先に溶ける、というのが現時点での実際的な読み 普段はClaude CodeやAIツール周りの記事を書くことが多いのですが、今回は界隈としてインパクトが大きかった
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
