要件定義おじさん

Fable5が作ったゲーム機の実体がJLCPCBから無事到着。 OTA(Over to Air)にも対応。基板のUVプリントはGPT-Imageで作成。

@itosue 絶対失敗すると思って試したらなぜか一発でできました（笑）

キャンピングカーの水タンクを小さいのに変えようとしたら、元のタンクの蓋と買ったタンクの蓋の大きさが違ったので、3Dプリンターでアダプターを作った。

チームメンバーにユーザーストーリーマッピングのやり方や価値をざっくり理解してもらうために、@kawaguti さんの登壇資料を3回くらい上映してる。特に動画の49分〜57分まで見れば、ユーザーストーリーマッピングをみんなで作るための目線合わせができてめっちゃ助かる。 youtu.be/nWLpTqRdTlQ

Rate LimitでClaude止まってしまったけど、ちょっとしたコード書くだけでも抵抗が出てる。もうAIがないと何も書けない。

このTikTokerの動画、2人目に反撃食らってたからヤラセだろって言われてたけど、本物の不審者だったんだ… ー通行人にわざと接触し、笛を吹いたりイエローカードを出す行為

KFC、イオン、くら寿司…ニチレイシステム障害の影響拡大　不正アクセス復旧めど立たず sankei.com/article/202607… 不正アクセスを受けたニチレイのシステム障害の影響が広がっている。ニチレイは冷凍食品の国内最大手。システム障害が長期化すれば、小売業や外食への影響はさらに広がりそうだ。

無駄にトークン使おうと思ったらいくらでも使えるな。。

ブレずに生きるためのマイルールnote.com/duckseiro/n/ne…

@HappyLuckyAkira ありがとうございます！

@tan_go238 youtube.com/watch?v=C4P7f9… 発見しましたので、苦労している姿をご確認くださいｗ

要件定義のイベントで話します！ 要件定義でお困りの方はぜひご参加ください！ ヒアリングより、観察を。上流を任されたエンジニアが知るべき、手戻りの少ない要件定義のススメ flexy.connpass.com/event/398459/ #flexymeetup

@HappyLuckyAkira ちょっと見てみたいのでURLください！

@tan_go238 私の昨年のは、最初にトラブルがあって困ってるのが永久開示なので大丈夫です！(何が)

@tokutaka ですねー。全体像を見渡すのは難しくて詳細の整理と仕様や設計に繋げる感じですかねー

@tan_go238 煩雑なフローをもつ業務プロセスアプリ開発向けと私は理解してます。 フローそのものを見直すとか、フロー以外の価値にまつわるユースケースを整えるのは苦手かも

今日のイベントでICONIXの説明が難し過ぎて説明ができなかったんだけど、いま考えても難しい。ユースケースが分かっている前提ってなんやねん。

@HappyLuckyAkira 色々説明困ってしまってるところがあるので恥ずかしいです！

@tan_go238 アーカイブ視聴します！

土地勘なさすぎて前にいるスーツの集団に付いて行ったら駅着くだろうと思ったら、知らない会社に着いてしまった。

DJI EV50、これは空撮ドローンではなく、かなり本気の貨物VTOL。 最大50kg積載、270Lの貨物スペース、無積載で最大150km航続。山岳物流、離島配送、災害対応、科学観測みたいな「道がない場所」に刺さる設計になっている。 DJIがここに入ってくると、物流ドローンも試作機の世界から量産・保守・運用パッケージの世界に一気に寄っていきそう。 dronedj.com/2026/07/13/dji…

生産性についての議論は、結果を定量的に計りたくないっていう気持ちが根底にありそう

ニチレイの件、公開情報を追っていて考えさせられた。確認できたことだけ書く。 7月13日、ニチレイは「不正アクセスによるシステム障害」を公表した。影響を受けたのは、ニチレイロジ各社の冷蔵倉庫入出庫業務と、ニチレイフーズの冷凍食品出荷業務。別事業会社の二つの業務系統が同時に止まっている。 影響は国内に限定され、個人情報の流出は現時点で未確認。侵入経路や攻撃手法は公表されていない。 気になったのはDRの設計だ。 ニチレイロジの物流基幹システム「Lixxi」は、西日本をメインサイト、東日本をDRサイトとして両拠点を同時稼働させ、データを常時同期する構成を導入している。西日本側が停止した場合、DR発動からオンライン再開まで約1時間。免震データセンター、異なる通信キャリアの冗長化、クラウド上のDRサイトなど、大規模災害や設備障害への備えとしては非常に強い構成だ。 一方、今回は不正アクセスによる障害だった。 もちろん、Lixxi自体が侵害されたのか、DRへの切り替えを試みたのか、安全確認のために関連システムを停止したのかは公表されていない。 ただ、災害とサイバー攻撃では復旧の前提が違う。 設備障害なら、壊れた設備を正常な設備へ切り替えればよい。 しかしサイバー攻撃では、データ、認証、管理権限、運用端末、ネットワークなど、環境そのものの信頼性が失われる可能性がある。DRサイトが存在していても、それだけで安全に切り替えられるとは限らない。 さらに、外部から公開面を確認すると、業務システムには世代差が見える。物流系の一部はAWSのロードバランサーを利用し、比較的新しいTLS構成で公開されている。一方、社内ポータルにはCentOS 7世代を示すApache、OpenSSL、PHPの構成や、TLS 1.3に対応していないシステムも確認できた。 これが今回の侵入口だったという意味ではない。原因との関係は全く分からない。 むしろ、大規模組織では長年使われてきたシステムと、新しく構築したシステムが共存することは珍しくない。 問題は、新旧が混在することではない。 古いシステムは、更新の難しさや依存関係、保守期限、認証方式などの制約から、相対的に攻撃対象になりやすい面を持つ。 だからこそ重要なのは、そこから侵入されたとしても、他の事業会社や新しい基盤まで到達できない設計にしておくことだ。 ネットワーク、認証、管理権限、運用端末、バックアップ——どこまでを共有し、どこで境界を引くのか。 今回止まったのは、ニチレイロジの冷蔵倉庫入出庫と、ニチレイフーズの冷凍食品出荷という二つの業務系統だった。 どこが共通依存点だったのかは現時点では分からない。認証基盤だったのか、ネットワークだったのか、EDIや統合マスタだったのか、それとも安全確認のために広範囲を停止したのか。 ただ一つ言えるのは、サイバー攻撃では「侵入されないこと」だけを前提にした設計では足りないということだ。 災害では、壊れた設備を切り替える。 サイバー攻撃では、信頼できなくなった環境を切り離し、クリーンな環境へ業務を戻す。 同じ「復旧」でも、設計思想はまったく違う。 これから問われるのは、防御だけではない。 侵入されても事業を止めないために、どこまでを切り離して復旧できるよう設計しておくのか。 サイバーリカバリーを前提としたシステム設計へ、発想そのものを変える時代なのだと思う。 （本稿は公開情報および公開されたシステム情報への通常アクセスによる調査に基づくものです。侵入経路や攻撃手法、影響範囲の詳細は現時点で公表されておらず、原因を特定するものではありません。） #サイバーセキュリティ #サイバーレジリエンス #BCP #ランサムウェア #物流DX

Codex くんが2日くらいずっと TAKT の OpenCode 安定化対応をしてる いつ終わるんだこれ

東京飯最高だった

東京飯