ささ4000all

SIerの下請で四半世紀暮らしたソフトウェア設計者・開発者。流行りものを食い散らかすのが趣味。

[ミノ駆動 @MinoDriven]

IT業界の人が攻撃的？の件、不確実性も要因のひとつだと考える。

別にITに限った話ではないが、ソフトウェア開発は不確実性との戦い。顧客が解決してほしい問題は何か、顧客が本当に欲しているものは何か、何が答えなのか分からない不確実性の高い中で開発を進めなければならない。

不確実性は企画段階や要求定義といった上流工程ほど不確実性が高い。一方で要件定義、設計、実装と、下流工程に行くほど何をやるかが具体的に決まっていき、確実性が高くなっていく。どういうことかお気づきであろうか？

最後の最後には「本当にシステムとして実現できるかどうか」を答え合わせしなければならない。いくらビジネスサイドで「あれもやろう」「これもやりたい」と言ったところで実現できなければ絵に描いた餅。そしてその答え合わせの役割を担っているのがエンジニアなのである。

仕様に矛盾なく一貫性があるか、現状のシステム構成で吸収可能な仕様なのか、チームの技術スタックや技量で実装可能なのか、納期までに間に合うのか……といった多くの変数を「実現可能性」という名前のお皿に乗せ、検討し、答え合わせをする。

その答え合わせの結果として、「できません」と突き返さなければならない局面がある。そうした局面になった際「じゃあどうやったら実現できるのか」という話になる。何に妥協したら実現できるのか、仕様やシステムの一貫性を維持するためにどうしなければならないのかなど、「厳しく」突き詰めなければならない。「厳しく」というのは、システムには曖昧さが通用しないからである。システムは人間のように「忖度」しないのだ。エンジニアは、そうした「人間に忖度できないシステムの代理人」として話しているケースが多い。

こうした「厳しく」突き詰めるエンジニアの言葉は、「正論パンチ」として人の目に映るであろう。「正論はときに人を傷つける」という有名な言葉にあるように、人間は理想と現実のギャップを突きつけられると、認知的不協和が働き、不快感を覚えやすくなる。その不快感を「攻撃的だ」と認知してしまう、というのが実態ではなかろうか。

もちろん何を言ってもいいというわけではないし、あからさまに言葉選びが悪く人格を傷つけかねない言葉を使う人も実際いるわけで、それは許されないし改善しなければならない。

まとめると、不確実性が高いソフトウェア開発の中で、実現可能性の最後の門番としての役割をエンジニアが担っており、「人間に忖度できないシステムの代理人」としての厳しい発言が正論パンチとして映り、認知的不協和が働いて「攻撃的だ」と認知してしまう、「開発プロセスと人の認知の悪魔合体技」の結果生じる事象ではないかと考える。

[広木 大地/ エンジニアリング組織論への招待 @hiroki_daichi]

実は世の中には無制限に賢い方が優れているタスクと言うのはそんなに多くないんです。

高度なアプリ開発であるとか経営分析であるとか、そういったことについては、賢ければ賢いほど成果につながる可能性があるようなタスクではあります。

ただこれは現在のところの知能レベルにおいてはと言うような言い方をすることはできます。ほとんどの細分化されたタスクにおいては、極めてトークンコストの安いモデルで十分な性能を発揮することができます。アルバイトで十分なタスクに対して東大理三の知能は必要ないって言うわけです。一方で、金融システムのセキュリティーチェックなどは、優れたスペシャリティーを持ったエージェントが長時間推論し続けることによって価値がでます。

知能のレベルを固定した場合、そのタスクに必要なトークンコストと言うのは、年間に10分の1以下になっていきます。

そういった意味で何を行うかと言うことについて、当然価値創出につながるタスクをしていったほうがいいと言うこともあるんですが、トークン効率という観点においては、「この程度の仕事であれば、この程度のモデルで充分である」と言う見極めが必要になります。また継続した実行判断みたいなことについて、エージェンティックフローであるよりもワークフローツールとの統合をする方が効率的である場合があります。コンテクストをむやみに消費しないからです。

例えば、僕の場合、メールチェックに関しては、極めて安いモデルが運用されています。しかし、記事の執筆やソフトウェア開発においては、最新のフロンティアモデルを活用することが多いです。明らかに成果に違いが出てくるからです。ですので、成果の時間が知能によって青天井になり得るようなタスクにおいては、新しいモデルを使っていくことになるでしょうし、それはコストと効果の見合いになってきます。しかし、効果の固定的なタスクにおいては、そのタスクを実行できるようなモデルのうち、最も安価なものを選択的に選んでいく必要があります。その点において、オープンウェイトのモデルや蒸留モデルと言うのは常に選択肢に入れておいた方が良いものです。

僕の場合は、Claude Opus 4.8からGPT5.5への委譲やGPT5.5からComposer2.5やGemini 3.5 flashやKimi などへの委譲を行うようにタスクごとにアプローチを設計しています。

トークンマキシム的な動きによって、どのようなことにAIエージェントが活用できるのかを理解した後の最適化のフェーズにおいて、そのタスクが青天井型のタスクなのか成果固定型のタスクなのかと言うことを理解する必要があります。実はこれもグラデーションである一定のラインまでは青天井だけれども、ある一定のラインからは成果がサチっていくと言うことになります。

AIとの協働とは、相手の能力を見極め委譲を設計するという組織設計そのものの思考力が問われます。

[増田 亨 @masuda220]

先ほど発表した資料を公開しました。

AI 時代のソフトウェア設計の学び方 https://t.co/OrGm6fS6tY

#jjug_ccc #jjug_ccc_g

[Hiromitsu Takagi @HiromitsuTakagi]

日記にしました。これはまずいです。
https://t.co/T8fA24lbDa
個人情報保護法改正案に重大な欠陥、2001年「メディア規制」法案の再来、修正が必要 - 高木浩光＠自宅の日記（2026年5月11日）

[ささ4000all @js4000all]

B2B SaaSの認証認可の変遷 に参加を申し込みました！ https://t.co/fjBlDPXpvf

[長久 勝 @mnagaku]

ソフトウェアの「設計原則」を、なぜ一部のエンジニアは生理的に嫌うのか｜Takami Torao https://t.co/5SUlzC53kL #zenn
なかなか面白い考察

[catnose @catnose99]

人間、何か上手くいくとすぐ調子乗ってプライドが育っちゃうから、ときどきぴよぴよレベルな新しい分野に手を出して自分のポンコツっぷりに直面するの大事

[Takuto Wada @t_wada]

尊い整理整頓だと思う。設計判断力は失敗から学ぶものが多かったが、世の中にあまりにも同じような「良かれと思って失敗する」パターンがある場合はアンチパターンとして共有し「転ばぬ先の杖」としていくのが望ましい / Decision Quality と設計判断失敗パターン - kawasima https://t.co/fa41m51RPI

[John Crickett @johncrickett]

If you can't rebuild it, you don't understand it. Harsh, but true.

I've been writing software for 30 years, and there is a clear pattern I've seen separating good engineers from great ones.

Good engineers use the tool. Great engineers know why it exists.
Good engineers finish the tutorial. Great engineers ask what problem it's solving.
Good engineers trust the abstraction. Great engineers know what's underneath it.

It's not about being smarter. It's about refusing to be helpless when things break.

Because things always break.

The framework throws a cryptic error. Performance tanks in production. The abstraction leaks at 2am. In those moments, the engineers who've gone one level deeper don't panic, they investigate. They've seen the guts before. They know where to look.

That confidence isn't something you get from watching videos. You build it by building things.

Write a web server from scratch and HTTP stops being magic.
Build your own grep and regexes stop being intimidating.
Implement a Redis clone and you finally understand what "in-memory data structure store" actually means.

You don't need a PhD. You don’t need a CS degree. You don't need a bootcamp. You just need reps.

So if you're trying to level up, stop copy-pasting from an LLM and start rebuilding the tools you use every day. It's slower. It's harder. It's the only thing that works.

I run a newsletter of real-world coding challenges designed around exactly this. Writing your own web server, grep, Redis, and more. Link in my profile if you want in.

What's the tool you use every day that you'd struggle to rebuild from scratch?

[Hiromitsu Takagi @HiromitsuTakagi]

Claude Opus 4.6による解説。もうAIに見てもらいなよ。

[610 @610_mto]

スクラムマスターは何もしないの話。
---
スクラムマスターは何もしない、を間に受けすぎて、本当に何もしていない人がいるらしいんですが、スクラムマスターは、モメンタムをつくらなきゃいけないんですよ、モメンタムを。土壌を、雰囲気を、環境を、勢いを。

少なくともスクラムチームのメンバーからは「あの人何もしてないように見えるけど、あの人がいるからうまく回ってるんですよ」ぐらいに認知されてなきゃダメで、ステークホルダーが何もしていなさそうなスクラムマスターを解任しようとしてもメンバーが抗議してくれるぐらいじゃないと。

もしチームが成熟しているなら、組織にスクラムを導入するので今度はステークホルダーが味方になってくれるはず。複数チームにしてもいいだろうか？今のPOの成長課題は何だろうか？アジャイル人材の育成をどうしたらいいか？社内ルールは？などなど、やることは山積み。

それらに対応していれば、たとえスクラムチームが「スクラムマスターはマジで何もしていないんで不要です」って言ったとしても、ステークホルダーが「いやいや、スクラムマスターには今組織課題に取り組んでもらっているんだ。スクラムチームとして不要なのはいいが、今後はアジャイルコーチとして継続してもらう」って庇ってくれるはず。

[広木 大地/ エンジニアリング組織論への招待 @hiroki_daichi]

「属人化をなくすには、その人の知識を移管すればいい」という発想があります。でも多くの場合、それは問題を診断ごと間違えています。

属人化の実態は「個人の中に知識が蓄積されている」のではなく、「構造・プロセス・情報設計の欠損を、熟達した個人が都度補っている」状態です。これは知識の問題ではなく、設計の問題。だから移管しても根本は解決しない。理解できる別の誰かが現れても、同じように「補う役」を担うだけです。

まず問うべきは「その人は具体的に何を補っているのか」です。一次情報へのアクセス不足なのか、業務ロジックの未言語化なのか、設計上の矛盾の放置なのか。補われている対象が構造欠損であれば、知識移管より先に設計変更が必要です。

属人化は原因ではなく、症状です。

[広木 大地/ エンジニアリング組織論への招待 @hiroki_daichi]

仕事とは「タスクをこなすこと」ではなく、「わからないことを減らすこと」だと思っています。

この問いを出発点にして書いた記事を改めて共有します。ソフトウェアがあらゆる定型業務を代替していく今、人間に残される仕事はほぼ必然的に「不確実なもの」になります。だからこそ、不確実性にどう向き合うかが、個人の生産性だけでなく、組織全体の健全さを左右する。

人間の脳は「わからないもの」に対して逃避か闘争で応答するように設計されています。これは動物としての本能で、責める話ではありません。でも、その反応がプロジェクトを停滞させ、チームを機能不全に陥れる。新しい提案にやたらと反論する人、意思決定を先送りにし続けるチーム、誰もが経験したことのある光景の根っこには、この「不確実性への忌避」があります。

夏休みの宿題を思い出してください。得意な科目のドリルから片付けていくと、最後に自由研究や苦手な教科が残る。タスク量は減っているのに、いつ終わるか読めない状態が続く。これはスコープが小さくなってもリスクが集中している状態です。先に不確実性の高いものに手をつけると、予測精度が上がり、残りのスケジュールが見えてくる。仕事も同じ構造をしています。

今の仕事の中で、薄々わかっているのに向き合えていない「一番わからないもの」は何でしょうか。それがあなたの夏休みの宿題です。
https://t.co/NMFkSQs451

[Ryutaro YOSHIBA @ryuzee]

変革をするって言い出した幹部の方へ。チームの稼働を十分に確保しろ。自分も時間を毎週ちゃんと確保してそれを最優先にしろ。他の予定でチームに影響を及ぼすな。会議では末席に座れ。前に出て仕切るな。聞かれたことだけ答えろ。そして本当に大事なときだけ1つ質問しろ。責任は取れ。よろしくね！

[広木 大地/ エンジニアリング組織論への招待 @hiroki_daichi]

業務設計の本質は「人が何をするか」ではなく「人がどこに関与するか」の再定義です。

標準化の時代は「誰でもできる」、可視化の時代は「誰でも判断できる」が目標でした。AI時代はさらに進んで、①人が直接実行できる状態にする、②人が介在しなくても回る、③仮説検証や創造まで委ねる、という3層での設計が求められます。

生産性向上とは作業の高速化ではなく、人間が関与すべきレイヤーを戦略的に選び直すことです。どの判断を人が握り、どの実行をシステムに委ねるか。その境界線の引き方が、組織の構造そのものを規定します。

[広木 大地/ エンジニアリング組織論への招待 @hiroki_daichi]

人材育成でよく混同されるのは、「後から埋められる知識・経験」と「時間をかけて醸成される人間的資質」の区別です。

プログラミング言語やフレームワークは比較的短期間で習得できますが、主体性やコンセプト構築力といった資質は、初期のポテンシャルと長期の経験に依存します。

育成戦略の本質は、この時間軸の違いを理解することにあります。全員一律の育成プランは非効率で、ポテンシャルのある人材には最速で経験を積ませ、資質をこれから養う人材には長期的なアプローチを取る。

「今できること」よりも「変化しにくい資質」を見抜く目が、組織の育成戦略を分けるのだと思います。

[ミノ駆動 @MinoDriven]

会社で作ってるagent skillなんで具体的には明かせませんが、

- 哲学概念「言語ゲーム」、言葉の意味は文脈や目的により変わる
- 目的は人（アクター）が決める
- 言葉の意味が変われば周囲のルールも変わる

アクターの目的を起点に言語ゲームの観点で言葉の意味とルールの境界をAIに推論させるのがポイントです（もう半分以上答え言ってるようなもん）。

[杉本啓 @sugimoto_kei]

建築はリビング・システムではなく、その残余である。建築家の難波和彦さんのことばだが、僕らが作るソフトウェアにも当てはまるし、A Iが現れて、その傾向はさらに強まっている

作り手である我々は、我々が作るソフトウェアが、残余、余白、背景なのだということを思いだすべきだ

建築もソフトウェアも、残余であることによってこそ、豊かな意味を持ちうる。残余であるからこそ、それがつくる背景の上であらゆる活動が生起し得る

[Takuto Wada @t_wada]

"もともと手作業でコードを書く速度よりも、解決したらお金を払ってもいい顧客を特定することのほうが遅いから" "AIで機能開発は早くなっても収益への貢献は期待ほど伸びない" / AIで機能開発は早くなったのに、なぜ収益が伸びないのか https://t.co/Jg3HEIJqba

[ささ4000all @js4000all]

技術選定を突き詰める Online Conferenc​​e ――逆境を乗り越える意思決定プロセス に参加を申し込みました！ https://t.co/NplYDm9ebZ #技術選定con_findy