そこでは、中国企業のビジネスに一貫する「できるだけ早く失敗しよう（Shift-left testing）」といった思考を理解する必要もありそうだ。このコスト重視の反復志向の取り組みは、中国のファストファッションと同じようにテストプロセスの前倒しを繰り返した結果（Shift-left）、「とにかくまずは市場に出そう。それこそがもっとも効率的なテストだ」になってしまった。
これによって私たちは「最新プロセッサー搭載モデルをめちゃくちゃ早く、しかも驚く価格で！」手に入れられる。もちろん、テスト結果が悪ければブランド価値は毀損する。けど、それに備えてたくさんのブランドを並行で展開しているから、炎上ブランドはひっそり廃止するとか、まあ、どうにでもなるわけだ。ブランドWebさえろくにつくっていないのだから。
身近なアップルは、LTV（Life Time Value、顧客生涯価値）重視の反復志向の取り組みをしていて、私たちはそれに慣れてしまっている。ブランドには価値があり、その維持のために長期的なストーリーテリング、価値観、倫理観、それらを顧客の信頼に結びつける努力を重ねるのが「普遍的な」ビジネス思考だと信奉している。
だから、ブランドとは「使い捨てのために利用」するものであって、ブランドの一貫性やアフターサポートへの配慮ゼロな中華ミニPCの世界はなかなか理解できない。
画像ファイルフォーマットのひとつであるPNGが、22年ぶりに新仕様となる第3版を発表しました。この第3版ではハイダイナミックレンジ(HDR)やアニメーションPNG(APNG)、Exifがサポートされています。
時流に乗ろうというビジネスと、時流を作ろうというビジネスがある。僕がやりたいのは常に後者だ。これはずっとそうだった。
前者が悪いというわけじゃなく、ただ、僕にとってはつまらなく感じられるだけだ。
気象庁が、台風進路予測の精度向上などに向けた技術開発基盤に、さくらインターネットのGPUクラウド「高火力 PHY」を採用する。約25億5000万円の契約になるという。同社が6月25日に発表した。
「Wayland」は、「X11」に代わる新しいLinux向けのディスプレーサーバーであり、より現代的で安定性が高く、安全性にも優れている。Waylandは、描画性能の向上、複雑なGUIのより効率的な処理、セキュリティ面での大幅な改善を実現する。
Waylandは以前から存在していたが、課題となっていたのは、長年使われてきたX11からの移行に、Linuxディストリビューションやデスクトップ環境が時間を要していた点である。
しかし、状況は現在変わりつつある。人気の高いLinuxデスクトップ環境の1つである「GNOME」が、「GNOME 49」でX11セッションのオプションを無効化し、「GNOME 50」ではX11関連のコードを全て削除する方針を発表したためである。
Jordan Petridis氏によれば、「5月6日にGNOMEリリースチームで会議を行い、その中でX11セッションの扱いについても議論した。カラーキャリブレーションに関する既知の問題が1件あったが、それについては修正が予定されていた。会議では、X11の削除に関するスケジュールと想定されるシナリオについて検討し、GNOME 50や『Ubuntu 26.04 LTS』まで延期するよりも、『Ubuntu 25.10』のリリースとタイミングを合わせてGNOME 49で進めるのが最適であるという意見が出た。その後、この件はいったん保留とし、1週間後に予定されていたUbuntuチームからのフィードバックを待つことになった」と述べている。
その後、6月にUbuntuの「Discourse」サーバー上で、Ubuntu 25.10（開発コード名：Questing Quokka）から「Xorg」ベースのUbuntuセッションを廃止する方針が発表された。これにより、Ubuntuデスクトップの進化における重要な一歩を踏み出すことになる。このリリース以降、「GNOME Display Manager（GDM）」におけるUbuntuセッションは、Wayland上でのみ動作するようになる。
- 移行が必要なシステム
- 不十分なドキュメント
- 不十分なテスト
- 低品質なコード
- デッドコード/放棄されたコード
- 劣化したコード
- 専門知識不足のチーム
- 不安定な依存関係
- 失敗した移行
- 洗練されていないリリースプロセス
空の安全を守る米国の航空管制塔で、システムの老朽化に伴うトラブルが続発している。米連邦航空局（FAA）は管制システム近代化の計画を表明し、「フロッピーディスクと紙の運航票はもうやめる」と断言した。
直近でトラブルに見舞われたのは、ニューヨークへの空の玄関口、ニューアーク・リバティ国際空港の管制塔だった。4月下旬から5月にかけて、管制システムの通信障害や画面のブラックアウトなどのトラブルが繰り返され、同空港を利用する便の欠航や遅延、行先変更が続出。対応を強いられた管制官がストレスのため次々に病欠してさらに欠航が増える悪循環に陥った。
[...]そうしたトラブルが起きるたびに指摘されてきたのが、システムの老朽化だった。米公共放送NPRによると、米国の管制塔ではフロッピーディスクや紙の運航票、さらには「Windows 95」搭載のPCが今も普通に使われており、「米国内の管制塔に足を踏み入れると、まるで20世紀にタイムスリップしたような錯覚に陥る」という。
航空管制システムの近代化を求める声は以前から噴出していた。FAAは23年の時点で、米国内の管制システムの3分の1以上について、時代遅れの機能やスペアパーツ不足などを理由に「持続不可能」と判定していた。
ただし管制システムはノンストップで稼働させ続ける必要があり、入れ替えは簡単にはできない。そうした事情から、これまでに獲得した予算はアップグレードよりも、主に現在のシステムを稼働させ続けるために使われてきたという。しかしどれだけ修理を行っても、老朽化したシステムはいずれ使用不可能になる。
アップグレードにあたってはセキュリティ対策の徹底も課題になる。もし管制システムがサイバー攻撃を受ければ甚大な影響が出る。これまでは航空機の動きを運航票で記録して、システム間のデータのやりとりにはフロッピーディスクを使っていたことから、不正侵入とは無縁だった。24年7月に米CrowdStrikeのシステム障害が世界を襲った際に、管制塔が影響を免れたのは古いシステムのおかげだったともいわれる。
カーパシー氏は、ソフトウェアというものが過去2回にわたって急速に変化したものと考えています。最初に登場したのがソフトウェア 1.0です。ソフトウェア1.0は誰もがイメージするような基本的なソフトウェアのことです。
ソフトウェア1.0がコンピュータ向けに書くコードであるのに対し、ソフトウェア2.0は基本的にニューラルネットワークであり、特に「重み」のことを指します。開発者はコードを直接書くのではなく、データセットを調整し、最適化アルゴリズムを実行してこのニューラルネットワークのパラメーターを生成するのです。
生成AIが洗練されるにつれ、ニューラルネットワークの調整すらAIの助けを得て行えるようになりました。これらは専門的なプログラミング言語ではなく、「自然言語」で実行できるのが特徴です。自然言語、特に英語で大規模言語モデル(LLM)をプログラミング可能になった状態を、カーパシー氏は「ソフトウェア 3.0」と呼んでいます。
まとめると、コードでコンピューターをプログラムするのがソフトウェア 1.0、重みでニューラルネットワークをプログラムするのがソフトウェア 2.0、自然言語のプロンプトでLLMをプログラムするのがソフトウェア 3.0です。
カーパシー氏は「LLMは新しい種類のOSのようなものだと感じました。CPUの役割を果たすような存在で、LLMが処理できるトークンの長さ(コンテキストウィンドウ)はメモリに相当し、メモリと計算リソースを調整して問題解決を行うのです。これらの機能をすべて活用しているため、客観的に見ると、まさにOSに非常に似ています。OSだとソフトウェアをダウンロードして実行できますが、LLMでも同様の操作ができるものもあります」と述べました。
DuckDBの公式ブログにおいて、メタデータ管理をデータベースで担う新しいLakehouseフォーマット「DuckLake」が発表されました。
本記事では、DuckLakeがどういったものか簡単に紹介し、ローカルで軽く触ってみたのでその内容をまとめてみます。
「『Microsoft Teams』との関係はもう終わりだ」。ドイツのシュレースヴィヒ＝ホルシュタイン州のデジタル化担当相であるDirk Schrodter氏は、オープンソースのビデオプラットフォームでこう宣言し、Microsoft製の全てのソフトウェアを州政府の職場から段階的に廃止していくと発表した。目標は、Microsoft製プログラムからLinuxおよびオープンソースプログラムへ3カ月以内に完全に移行することである。
この決定の影響は、ほぼ全ての公務員、警察官、裁判官など、約3万人の職員に及ぶ。その他の公務員（主に教師）も、最終的にはオープンソースに移行することになる。この抜本的な改革は、「デジタル主権」に向けた重要な一歩であり、米IT大手への依存に対する欧州の抵抗の高まりを示すものとして支持されている。今回の発表の直前には、デンマーク政府高官がMicrosoft依存からの脱却を表明していた。
シュレースヴィヒ＝ホルシュタイン州の今回の動きは、しばらく前から計画されていた。同州の内閣は2024年4月に移行を宣言。Schrodter氏は当時、移行の理由を次のように語っている。「そのような（プロプライエタリーな）ソリューションの運用プロセスや、データの取り扱い、第三国へのデータ流出の可能性に対して、政府は影響力を行使できない。州には市民や企業のデータの安全を守るという大きな責任があり、使用するITソリューションを常に掌握し、州として独立した行動を取れるようにしなければならない」
Schrodter氏は今回の決定に関して、次のように付け加えた。「ここ数カ月の地政学的な動向により、われわれが選んだ道に対する関心が強まっている。ウクライナ戦争によって、エネルギー依存の問題が浮き彫りになった。そして今回、デジタル依存があることも明らかになった」
シュレースヴィヒ＝ホルシュタイン州には、Microsoftと決別する理由が他にもあった。プロプライエタリーソフトウェアから脱却することで、政府と市民の機密データをドイツの法的管轄下にとどめて、米国企業によるアクセスのリスクを排除したい考えだ。つまり、Microsoft製のソフトウェアを廃止するだけでなく、同州のデータを「Microsoft Azure」から欧州ベースのクラウドに移行する、とSchrodter氏は述べた。
言うまでもなく、同州はMicrosoftのライセンス料と予測できない必須のアップデートのコストを削減することで、数千万ユーロの節約を見込んでいる。後者に関してSchrodter氏が言及したのは、「Windows 10」から「Windows 11」への移行のようだ。
Linuxとオープンソース技術への移行は段階的に進められる。第1段階はすでに進行中で、「Word」と「Excel」を「LibreOffice」に置き換える。次の段階では、「Open-Xchange」を実装し、「Exchange」と「Outlook」を「Thunderbird」に置き換える予定だ。
最後に、LinuxがWindowsに取って代わる。具体的なLinuxデスクトップディストリビューションは明らかにされていないが、デスクトップインターフェースは「KDE Plasma」になるだろう。同州政府が使用する可能性のあるデスクトップとしては、「Ubuntu」の公式KDEフレーバーである「Kubuntu」や、「SUSE Linux Enterprise Desktop」（SLED）、「openSUSE Leap」などが考えられる。また、他のMicrosoft製品の廃止によって生じた穴を「Nextcloud」などのオープンソースツールが埋めるはずだ。
このような動きは失敗が目に見えている、という意見もあるだろう。よく挙げられるのが、ドイツのバイエルン州の州都であるミュンヘンの例だ。ミュンヘンは2004年にWindowsからLinuxに移行したが、Linuxを10年間使用した後、Windowsに戻した。これには、Microsoftの欧州本社をミュンヘンに誘致したいという市長の意向が少なからず影響している。しかし、詳しく調べてみると、「LiMux」は失敗に終わったものの、ミュンヘンは現在もオープンソースソフトウェアを使用しており、特にLibreOfficeに大きく依存していることが分かる。
欧州のLinuxプログラムには、10年以上前にUbuntu Linuxに移行したフランスの国家憲兵隊など、成功例もある。2024年6月の時点で、憲兵隊のワークステーションの97％に相当する10万3000台以上で「GendBuntu」（憲兵隊向けにカスタマイズされたUbuntuベースのLinuxディストリビューション）が使用されている。このプロジェクトはメンテナンスとアップデートが活発に実施されており、「GendBuntu 24.04 LTS」への最新アップグレードは2024年12月に完了した。
つまり、筆者が一貫して主張してきたように、WindowsからLinuxへの移行をうまくやり遂げることは可能だ。欧州連合（EU）が米国とそのテクノロジー企業への不信感を募らせている今、このような動きはさらに拡大していきそうだ。
先月開催された今年の Python Language Summit のライトニングトークに、Python の生みの親であるグイド・ヴァンロッサムが登場し、「悪いほうが良い（Worse is better）」原則は今でも通用するのか、と問いかけている。
プログラミング言語の Python の開発初期、主要プラットフォームだった UNIX の「悪いほうが良い」哲学には大きな影響を受け、長年この考え方がとても有用だったとグイド・ヴァンロッサムは認める。
この考え方のおかげで3か月で何かを動作させることができたと彼は言うが、その後、年月を経て、自分が手抜きしたすべてが最終的には修正されたとも認める。「当時はテストすらなかった」と言って、彼は笑いを取る。
その上で、『悪い方が良い』という考え方に今でも役目はあるのだろうかと彼は問いかける。今では Python には巨大なコミュニティがあり、開発体制も初期とはまったく異なる。
グイド・ヴァンロッサムは、機能の完成度に目をつむってコミュニティに試してもらうものを提供できた昔を懐かしんでいるようだが、昔に戻すこともできないのは承知している。
彼は最後に、Python で Rust を利用するためのバインディングを提供する PyO3 についての講演を引き合いに出し、これの開発には『悪い方が良い』原則が見られると評価している。PyO3 の開発は CPython よりずっと楽しそうだと言い、「とは言え、私は個人的に Rust を学ぶつもりはない……けど、後で試してみるべきかもな」と言って会場を笑わせたそうな。
今回はメタデータ管理をPostgresqlやMySQLなどのSQLデータベースが担う新しいOSSのLakehouseフォーマット、Ducklakeについて試してみました！
今回はPostgresql+s3(minio)+DuckDBで構築してます。
Ducklakeは公式HPの一文によるとSQLデータベースをカタログ置き場に、データをparquetファイルに保存する形式のLakehouseフォーマットだそうです。
今回は、TypeSpec を中心にしたスキーマ駆動開発をご紹介します。
結論からいうと、筆者は TypeSpec について「OpenAPI からの移行コストや技術的ロックインリスクを伴わず、開発体験を向上する最高のツール」と評価しています。その理由を順にご紹介します。
1: どんなフレームワークもいつか身の丈に合わなくなる
2: デザインパターンや方法論は、やがて通用しなくなる
3: 規模は時間とともに常に拡大する
4:「ストーリー」に注目するべし
5: 目指すべきは「真実」と「明快さ」である
6: 孤立を味わう可能性がある
7: それでも真実の追求を諦めないこと
一般社団法人PyCon JP Association 理事の石田です。
昨年10月に設立を宣言した、PyCon APAC 2023における登壇者採択に関する調査について、内部調査委員会による調査が完了しましたのでご報告します。
調査および取りまとめに時間を要し、当初お約束していた時期よりも遅れてのご報告となったこと、お詫び申し上げます。
PyConAPAC2023における登壇者採択に関する調査結果.pdf
内部調査委員会による指摘の通り、一般社団法人PyCon JP Associationは、今後もよりよいコミュニティ運営のための改善を責任持って継続していきます。
引き続き皆様のご協力・ご支援をよろしくお願いします。
- 実装手順書の管理は難しい上、人間はミスをする
- 手順に不備があることをコンパイルエラーとして表現したい
- Kotlinでは網羅性チェックを用いることで、コンパイルエラーとすることが可能
- 網羅性チェックを用いて手順の不備を検知することができるかも？
- 今回の実装例では大きく２つの定義を用いた
- コスト連携のステップを定義したインターフェース
- コスト連携の対象となるオーダーの定義
- V2の実装ではコンパイルエラーにより手順に不備があることを検知できた
ここ1年でプロダクト開発の環境は大きく変わりました。
AIエージェントが開発現場で“当たり前”のように使われる時代になりつつあります。
そんな中で、「DDD(ドメイン駆動設計)って今の時代にも必要なの？AI時代になったらもう使わなくなるのでは？」と疑問に思う方もいるかもしれません。
私はこう思います。
DDDは、AI時代にこそレバレッジを効かせることができる、価値を届けるための“武器”になる。 (少なくとも、あと数年はね。)
これまで長い間この国の施策に汗水を流してきた事業者を自治体システムの知識が低いワーキングメンバーがあたかもコスト増は事業者の責任の如く失礼極まりない会議が行われ公開処刑に近い形の議事要旨が公開された。界隈にいる人ならどの事業者かは想像に難くないだろう。
99％政治マターに踊らされた国の失敗である。無論これまでの自治体システムにおいて事業者側にもやるべきことがあったことは認める。しかし、今回の失敗は国の責任だ。これは曲げようもない事実。こちらは何度も軌道修正を呼び掛けたが応答することはなかった。いや、失敗が明らかになってから応答したものもある。時すでに遅し。処方箋は病気発覚後すぐに投薬するのがベストだ。お迎えまじかの患者に投与しても意味はないのである。
フロントエンドカンファレンス北海道2025実行委員会の実行委員長を務めております、n13u（西村航）です。この度は当実行委員会が運営する公式ウェブサイトの乗っ取りにつきまして、皆様に大変ご心配をおかけいたしました。
現在、公式ウェブサイトでは対応を行い2024年度開催分のページが公開されています。また、後述する原因に基づき、各種設定の見直しを行い再発防止策を実施済みです。公式ウェブサイトへのアクセスについて問題なく行えることを確認しておりますが、DNSレコード設定の反映等で一部の環境にて正しくない、または不正なウェブサイトが表示される可能性もございます。反映が完了する数日程度は継続してウェブサイトの閲覧をお控えいただくようお願いいたします。
まとめ
- Go におけるエラーハンドリング冗長性は長年の課題である。
- Go チームは check/handle → try → ? と三度の大規模提案を試みたが、いずれも広範な合意に至らず撤回された。
- 構文変更にはメリットもあるが、デバッグ容易性や設計哲学、移行コストなどマイナス面も大きい。
- 当面は構文をいじらず、ライブラリやツールでの支援に軸足を置くという結論に落ち着いた。
窮屈で仕方ない。決められたものを、決められた日までに作るだけ——プロジェクトの成功とは、そういうものなのか。
そんな疑問が頭をもたげるスクラムチームは、自らを “もどき” だと感じるようになります。スクラムで開発しているはずが、気づけば違うものに変わってしまっていた、と。
はじめから “何を作るか” にばかり集中すると、そうなります。そして、チームは次の四段階を経て、静かに侵食されていきます。
- はじめから全体を詳細に詰める
- 決定を開発へ一方通行で流す
- すべてのパーツを作ってから組み上げる
- スプリントレビューを進捗報告の場にする
優れたアイデアやデザインがあっても、それだけではソフトウェアプロジェクトを成功させることはできません。プロジェクトを円滑に進めるためには、ステークホルダーの理解と支持を得て、チームが協力できる環境を作ることが重要です。本書では、そのために不可欠で効果的なコミュニケーションの方法を解説します。具体的な例やパターンを通じて、適切にメッセージを伝えるためのドキュメントや図の作成方法を紹介します。
まず、ソフトウェアアーキテクチャの視覚表現を活用し、受け手にわかりやすくメッセージを伝える方法を解説します。次に、書面・口頭・非言語コミュニケーションの技法を用いて、相手に意図が正しく伝わるように工夫する方法を紹介します。また、ナレッジマネジメントを強化し、チームや組織の集合的な知識を最適化することで、生産性と革新性を向上させる手法についても解説します。さらに、アーキテクチャに関する重要な意思決定を的確に記録し、関係者と共有する方法を学びます。そして、リモートやハイブリッド環境において、同期・非同期の手法を適切に使い分けながら、円滑に連携するためのアプローチについても詳しく説明します。
『Five Lines of Code — How and When to Refactor —』(Christian Clausen著、MANNING刊)の日本語版。
リファクタリングはソフトウェア開発やプログラミングの世界においてコードの品質向上や保守性の確保のために重要です。 何をリファクタリングすべきかは、問題の兆候を示す「コードの臭い」で説明されてきましたが、この概念は抽象的で、経験の浅いプログラマーには理解しづらいものでした。
本書では、「メソッドを5行以内で実装する」といった明確なルールを用いてリファクタリングを行うテクニックをステップバイステップで解説します。ルールの解説後には、そのルールの元となった「コードの臭い」についても説明されており、効率的に「コードの臭い」への感覚も養うことができます。
第1部では、GitHubで公開されている2Dパズルゲームのコードを主要な題材としてリファクタリングのプロセスを示しながら、適用するルールやパターンを解説します。
第2部では、チームでの開発にも焦点を当て、ルールとリファクタリングパターンを実務でどう活用するかを掘り下げます。コンパイラの機能の活用や、コメントを極力書かないようにするためのコツ、価値あるコメントの見極め方、コードの安全な削除／追加方法、将来的なリファクタリングで見落とされないように悪いコードをさらに悪く見えるようにして品質レベルを明確にするテクニックなど、実践で役立つトピックを広範に扱っています。
新山祐介さんの投稿で知ったが、プログラミング技術に関するナレッジコミュニティ、共同創業者のジョエル・スポルスキーの表現を借りれば「ロングテールなプログラミングの質問のWikipedia」である Stack Overflow だが、「ほとんど死んだ」と評されている。
「投稿される質問の数はピーク時の1/10程度、黎明期の2009年あたりの数まで激減している」というのはショッキングである。
投稿される質問数でいえば、2014年～2017年あたりがピークで、コロナ禍が始まった2020年にも急上昇しているが、その後衰退期に入り、ChatGPT 開始とともにダメ押しのごとくガクッと下がっている。やはり AI が Stack Overflow の衰退を後押ししている。
AI活用が当たり前になる開発環境において、コードの「なぜ」を残すことは、技術的負債を防ぐ重要な実践だ。2年後により良いAIが登場したとき、過去の意思決定を理解できれば、真に価値のある改善が可能になる。
私たちエンジニアは、常に未来の自分や同僚のことを考えてコードを書いてきた。可読性、保守性、拡張性—これらはすべて「未来の誰か」のための配慮だ。AI時代においても、この精神は変わらない。むしろ、AIの進化速度を考えれば、より一層重要になる。
プロンプトは新しい形の設計書だ。コードレビューと同じように、プロンプトレビューが必要になるかもしれない。リファクタリングと同じように、プロンプトリファクタリングが日常になるかもしれない（プロンプトの可読性を議論する日も近い）。
PDRのような仕組みの標準化は、AI時代のソフトウェア開発における必須要件となるだろう。エンジニアとして、この課題に真剣に取り組む時期に来ているが、個人ではどうにもならない気もするので。頑張れ、Anthropic！！！
ソフトウェアテストには、対象とする品質要件に応じて様々な「手法」が存在します。しかし、個別のテスト手法を断片的に学ぶだけでは、プロダクトの品質を総合的に高めることはできません。本書は、複数のテストを補完的に組み合わせて、あらゆる側面から品質を検証するための技術・戦略を、体系的に学べる骨太なガイドブックです。
取り上げるのは、以下10種のテスト手法。それぞれについて、テストの原理原則・導入戦略・実践方法を、具体的なWeb／モバイルアプリケーションでの適用例を交えながら詳しく解説します。
□手動探索的テスト
□自動テスト
□継続的テスト
□データテスト
□ビジュアルテスト
□パフォーマンステスト
□セキュリティテスト
□アクセシビリティテスト
□モバイルテスト
□クロスファンクショナルテスト
本書は、各領域のテストを一貫した視点で解説するため、それぞれのテストの「役割」と「つながり」がよく理解できます。本書を通じて、広大なテスト分野を迷わず歩くための「体系的な知識地図」をインストールしてください。
【石破茂首相の発言】
「税率変更する時に、一体どれくらいの期間がかかるかということでございます」「スーパーを見れば分かりますが、そのシステムを変えるだけで1年はかかるということでございます」
（5月21日、立憲民主党の野田佳彦代表との党首討論で）
首相発言が「レジの変更に1年」と拡散 SNSで批判
石破茂首相は21日、立憲民主党の野田佳彦代表と党首討論をした。
物価高対策として、食料品の消費税を1年間ゼロにすると掲げた野田代表に対し、「減収が5兆円になる」と指摘。さらに、「スーパーのシステムの変更」に1年かかると述べた。
討論後、フジテレビが首相発言を「スーパーのレジなどシステム変更に1年かかる」などと伝えた上で、都内の商店街の小売店主らの「1日でできる」「一晩」などといった意見を報じた。SNS上では、首相の「1年発言」に対し、「1年もかかるわけねえだろ」「すぐばれる言い訳」などの批判が拡散した。アカウントの中には、投稿が見られた数や影響力などを示す「インプレッション数」が800万を超えたものもあった。
加藤財務相「短期間で可能とする事業者もいたが……」
首相が言う「スーパーのシステム」について財務省は、店内に複数レジがあるスーパーや小売りチェーンなどで導入されている、各レジの売り上げを集計する「POSシステム」としている。
加藤勝信財務相は27日、参院財政金融委員会で野党議員の質問に対し、複数の大手システム事業者への聞き取りの結果として「短期間で対応可能とする事業者があった一方で、少なくとも1年は要すると見込む事業者も複数あった」と答弁。「1日でできる」という声を紹介した一部報道については、「個人商店の場合は、割と簡易なシステムでありますから、そういった声も確かにある」などと述べた。
大手メーカー「1年以上でもおかしくない」
実際、POSシステムの税率変更にどれほどの期間が必要なのか。合わせて業界シェアの7～8割を占める大手システムメーカー3社（東芝テック、富士通、NECプラットフォームズ）に聞いた。
そのうちの1社の担当者によると、「個人商店などで使う単体の電子レジスターの設定変更なら別だが、POSシステムの税率変更はシステム改修が必要。過去の税率変更の際も、すべての顧客の対応が終わるのに1年はかかった」と話す。
別の社の担当者も、税率変更に伴いPOSシステムに関連する会計管理システムや在庫管理システムのチューニング（調整）が必要になると説明する。「期間限定かどうか、軽減税率をどうするかなどでも所要期間は異なるので一概に言えないが、1年以上かかったとしてもおかしくはない」という。
この2社によると、消費税をゼロにする場合は、「そもそもそういう設定を想定しておらず、新たなシステム開発に近い」ため、単なる税率変更よりも改修期間が長引く可能性があるという。
一方、「そこまで大規模な改修は必要ないので、数カ月から半年」とした社もあった。この社では、外食産業や小売りチェーン、企業の社食のシステムを多く担当しているという。
ただ、「あくまで、メーカー側で要する時間。小売り側の都合やスケジュールもあるので、実際は数カ月から半年より、もう少しかかるのではないか」と話している。
【判定結果=ほぼ正確（一部は不正確だが、主要な部分・根幹に誤りはない）】
スーパーやコンビニ、小売りチェーンなどで使われるレジの販売記録を管理する仕組みは、「POSシステム」と呼ばれる。システムメーカーの大手3社に取材したところ、2社はシステム改修などが必要になるため1年以上かかる見通しを示し、1社は数カ月から半年と回答した。
本書は、コードレビューに関する実践的なガイドブックです。「なぜコードレビューを行うのか」から始まり、ワークフローの徹底解説、最初のプロセスの構築と、段階的に解説します。さらに高度な要素として、「チームワーキングドラフト」「自動化」、そして最も大事な「効果的なコメント」について、じっくり説明します。「伝わるコメント」には、言葉遣いや文章のトーンが重要で、それを実現する著者の経験から生まれたメソッドが明かされています。
本書を通して、ソフトウェアテストの知識・技術を体系的に学びます。そしてその中でテストによって次の課題にどのように対応していくか学び、現代的なソフトウェア開発に対応するため総合力・基礎力を強化します。
- 開発成功や顧客満足実現をどう支えるか
- 開発の高品質と高スピードの両立を支えるアプローチとは
- アジャイルや継続的デリバリー、DevOpsの導入にどう対応するか
- テスト自動化といったテスト技術導入を成功させるには
- チーム全体でテストを推進していくためには
- 定番のテスト失敗要因に対しマネジメントでどう対策すべきか
総務省は2025年5月29日、情報流通プラットフォーム対処法第20条第1項に基づき、新たに4者を「大規模特定電気通信役務提供者」として指定すると発表しました。違法・有害情報の拡散防止や削除対応の迅速化を目的とした措置です。
今回指定されたのは、Pinterest Europe Limited（Pinterest）、株式会社サイバーエージェント（Amebaブログ）、株式会社湘南西武ホーム（爆サイ.com）、株式会社ドワンゴ（ニコニコ）の4社です。ドワンゴの「ニコニコ」については、同法施行規則に定める一部サービスを除外対象としています。
情報流通プラットフォーム対処法は、インターネット上での権利侵害の救済と表現の自由の両立を図る法制度であり、大規模事業者に対して削除申出窓口の整備や削除判断の通知、運用状況の公表などを義務付けています。これにより、利用者が被害を受けた際の対応を迅速かつ透明に行えるようにする狙いがあります。
総務省は今後も対象事業者の追加指定を検討しており、指定を行う際には改めて発表する方針です。
他人がAIに書かせた記事を読みたいと思います？
自分が読みたい文章を、いくらでもAIに書かせられるのに。
他人に教えて欲しいのは、有用なプロンプト(切り口、観点)だけでは？
それを自分好みにアレンジして、自分が読みたい文章をAIに生成させた方が自分好みの文章が読めますよね。
GoでLuaのユニットテストを書くモチベーション
端的に言うとGoで書いているアプリケーションサーバでValkeyを使っており、Valkeyの機能を拡張するのにLuaで処理を記述する必要が出たためです。
- ブラウザ上で動作するオープンソースのゲームエンジン「PlayCanvas Engine」、バージョン2.7.5にアップデート
- 3D Gaussian Splattingを用いた3DCGデータを圧縮する「SOGS」が導入
- 「SOGS」を活用したサンプルシーンも公開中。約1GBのデータを55MBに削減した結果を確認できる
SQLite-JS is a powerful extension that brings JavaScript capabilities to SQLite. With this extension, you can create custom SQLite functions, aggregates, window functions, and collation sequences using JavaScript code, allowing for flexible and powerful data manipulation directly within your SQLite database.
SQLite-JS は、SQLite に JavaScript 機能を追加する強力な拡張機能です。この拡張機能を使用すると、JavaScript コードを使用してカスタム SQLite 関数、集計関数、ウィンドウ関数、照合シーケンスを作成できるため、SQLite データベース内で柔軟かつ強力なデータ操作を直接実行できます。
1. WindowsはMicrosoftの優先事項ではない
2. Linuxが有力なゲームプラットフォームに
3. Linuxは使いにくいわけではない
4. Linuxデスクトップへのソフトウェアのインストールは容易
5. LinuxはWindowsよりもはるかに安全
とはいえ、Linuxデスクトップにも問題はある。Linus Torvalds氏（伝説の人物であり、Linuxの公式マスコット「Tux」の生みの親）の言葉を引用すると、「さまざまなベンダーの断片化がLinuxデスクトップの発展を阻害してきた」。現在では、270種類以上のLinuxデスクトップディストリビューションが存在するため、適切なものを選ぶのは本当に大変だ。「Ubuntu」の開発元であるCanonicalでさえ、Linuxデスクトップを最優先事項にしていないことも忘れてはならない。
(1) 収益性を重視し、設備投資が抑制された
(2) 基地局の調達を国内ベンダーに依存していた
(3) 「なんちゃって5G」を導入しなかった
販売管理システムのRFP回答をすべてのベンダーから辞退されてしまい、内製でやるしかないとコンサルから提案されるも弊情シスの誰も内製出来ないから詰んでる。
ニッチな業界のケースでパッケージは存在するものの魔改造＆短納期リクエストに変更してしまったため総スカン喰らってる。コンサルはベンダー選定までの支援契約で結局内製方針をぶち上げて「あとは知らね」のクロージングモードに突入。
■ Go に今逆風が吹いている
記事の冒頭では、フィンテック系スタートアップのエンジニア Yash Batra が半年で Go から Kotlin へ全面移行した体験を取り上げている。Batra は「 私たちはツールを作るためにツールを作っていた 」と述べ、Go の最小主義がプロダクト開発の速度を著しく低下させたと回顧する。
また、長年 Google で Go を率いてきた Ian Lance Taylor が 2025 年 4 月に退職したことも、コミュニティに衝撃を与えた。Taylor は「Go は“単なる一言語”の段階に到達した」と述べ、環境変化に合わせた言語進化の必要性を強調した。
Go は 2007 年に Rob Pike、Ken Thompson、Robert Griesemer が開発し、クラウド・インフラ向け言語（“C of the Cloud”）として脚光を浴びた。しかし 2022 年頃から、早期採用者の間で「プロトタイピング専用言語」「入門用言語」として位置づけ直す声が増え始めた。背景にはエコシステムの限界や AI ワークフローとの相性の悪さがある。
Go から離脱する開発者が挙げる代表的な不満点は次のとおりだ。
- エラー処理が冗長で、同じ if err != nil パターンが散在する。
- goroutine は強力だが、競合状態や静かな失敗を招きやすく、テストが難しい。
- “No frameworks” 文化により、共通機能を一から実装する負担が大きい。
- Go エンジニアの母数が少なく、採用・オンボーディングコストが高い。
- 生成 AI が慣用的な Go コードを出力しづらく、Python などに比べ生産性が劣る。
一方で、パフォーマンスとシンプルさを兼ね備えた Zig、豊富なツールチェーンを持つ Kotlin、安全性と速度で評価される Rust などの新たな言語は、Go言語への不満を解消する選択肢として、開発者たちの関心を集めているという。特に Zig は GC を持たず、async/await を標準搭載する点で注目されている。
フューチャー株式会社の有志が作成する良いアーキテクチャを実現するための設計ガイドライン
WebAPI設計ガイドライン
バッチ設計ガイドライン
DB設計ガイドライン
Terraform設計ガイドライン
データマネジメント設計ガイドライン
Gitブランチフロー規約
Markdown設計ドキュメント規約
コードレビューガイドライン
Slack利用ガイドライン
Joel on SoftwareにNetScapeを例に、古いプログラムを捨てて1から書き直したくなるのは戦略ミスだって書いてあるけど、あのとき書き直してなかったら続いてないんではって思ったので、1から書き直して続いてるソフトウェアを挙げてみる。
Joel on Softwareには、移行のための3年というのはインターネットの世界では非常に長いと書かれていたけど、それから20年たって動きも落ち着いて、3年はそう長くないようにも見える。 AIに関わらないプロダクトだと、3年のギャップはそこまで問題にならないんでは。逆にAIに関するプロダクトは3ヵ月の遅れが致命的になってる。
ただ、見返してみると、FirefoxもWindowsもmacOSも、20世紀のコードを21世紀に入って捨てたもので、それ以降は安定して書き換えるという話になってないですね。
はてなブログも、2012年くらいに稼働してると思うけど、それ以降はコードベースが古いという話になっていないです。
企業システムも、メインフレームからオープンシステム、自前サーバーからクラウドのようなアーキテクチャ変更がモチベーションにあるように思います。
インターネットの世界も落ち着いて、16bitから32bit、クラウドやスマホのような実行基盤の変更も起きないように見えるので、今後は新しい実行環境で動かすために1から書き直すということは減っていきそう。
創業期につくったシステムが成長が一段落したときにユースケースが変わっているので作り変える、といったことはあるのかもしれないけど。