ソフトウェア開発の結合テストの自動化による開発効率向上が蔑ろにされている件

システムエンジニアがテスト項目に沿ってシステムの操作を行い、画面キャプチャーを取って表計算ソフトに張り付けて確認対象の部分を赤枠で囲い、適宜吹き出しなど追加すると言う非効率な結合テストの実施方法への愚痴ツイートがあった^*1。

このテスト実施方法は、二つの点で非効率だ。一つは、再テスト実施の労働負荷が高い方法になっている。一つは、キャプチャー画像の管理に使うアプリケーションの選択を誤っている。せめてHTMLで書いたて、テスト項目ごとにページを変えた方がよい。キャプチャ画像に矩形や丸や文字を入れられるツールを探して来る必要はあるが。

かなり昔のPCでも、Linux Mint 22.2を入れれば、まだまだ実用できるよ

先日、Linux Desktopの利用者シェアが5%を超えたと話題になっていた^*1。Windows 10のサポート切れと、TPM 2.0必須のWindows 11のシステム要件から、Linuxを試している人が多いのか。来そうで来ないLinux Desktopの時代が来てしまうのか。

手元に古いPCがあったので、私も久しぶりにLinux Mint 2.2をインストールしてみた。ハードウェアの問題が生じづらいので、 Ubuntu Linux 11を最後にLinuxは仮想マシン（VMware/Hyper-V/WSL）で動かしていたのだが、危惧した問題は生じず快調に動く環境ができあ上がった。

Gitは使うのは簡単なバージョン管理システムだよ — 操作ミス後の復旧方法を何となく知っていれば

𝕏/Twitterでは分散バージョン管理システム（DVCS）Gitが難しいと言ったり、Gitの利用を避けている人々を、ITスクール講師とIT技術動画配信者が「いまどきGitを使えないなんて…」と煽る光景を見かけることがある。

GitはLinuxのバージョン管理のためにLinus Torvalds御大に開発されたツールで、今ではオープンソース製品のコード管理の他、ウェブから機械学習あたりのシステム開発でも広く使われている。他にも色々とある^*1が、現状でVCSの第一選択肢だ^*2。

ガバクラ利用に追加された非機能要件「媒体での外部保管及びネットワーク経由での遠隔バックアップ」

ガバメントクラウドなど^*1の利用に関する「地方公共団体情報システム非機能要件の標準」^*2に、媒体での外部保管及びネットワーク経由での遠隔バックアップが追加されたと話題になっていた^*3。

既にこれまでの（もしくは、そうだと思っていた^*4）要件に沿って開発中なので、このタイミングで要件を追加する必要があったのか、追加コストや具体的なソリューションをどうすれば良いか、困惑を招いている。

プログラミングで生成AIをうまく使う方法

熟練プログラマが生成AI（LLM）を使うと生産性が低下するという論文（Becker, Rush et al. (2025)）が、やはりそうか感をもって受け止められていた。

生成AIは最強のコピペ厨なのだが、コピペ厨の域を未だに脱却できていないので、意外ではない。実際のところ推論などはしていない（Shojaee et al. (2025)，Malek et al. (2025)）。現状の生成AIはハルシネーションがあるデータの引き出し方が特殊な巨大データベースに過ぎない。

デジタル庁クラウドチームのサービスレベルの計測の話の日本語が(´･ω･`)ｼｮﾎﾞｰﾝ

まず、用語の整理からはじめたい。業務システムの価値は、利便性とコストの削減になる。業務システムの信頼性、可用性、応答性などの状態を、サービスレベルと呼ぶ。サービスレベルを定量化して評価項目としたのが、サービスレベル指標（SLI）。SLIの目標値を、サービスレベル目標（SLO）と呼ぶ。

デジタル庁クラウドチームの「非同期処理」の説明が混乱している件

デジタル庁が詳細設計をするわけではないのでプログラマ的には問題ではないが、その説明が拙いために役所の情シスの皆さんを困惑させている気がするので指摘したい。デジタル庁クラウドチームの「非同期処理」の説明は混乱している。

デジタル庁クラウドチームはモダン化されたシステムの要件として、非同期処理を勧めて来る。

デジタル庁クラウドチームが説明しようとしないIaCを導入する本当の意義

デジタル庁クラウドチームはモダンなシステム構築の手法としてIaCの利用を勧めている。しかし、これまた説明に具体性がなくよくないので役に立つのか疑問に思われている。

IaCは宣言型プログラミング言語でインフラストラクチャーのリソース配置を記す技術（e.g. terraform）の総称で、クラウド事業者のサービスやコンテナオーケストレーションツール（i.e. Kubernetes）にそのコードを書いたテキストファイルを読み込ませることで、クラウドの設定を行うことができる。

デジタル庁クラウドチームの推すメッセージキュー（バッチ処理のイベントドリブン化）が有用になる場面

デジタル庁テックブログの「ガバメントクラウドにおけるモダン化の意味と定義」の説明がよろしくないので「それ何の役に立つの？」と言う反応が出てしまっているメッセージキュー（バッチ処理のイベントドリブン化）なのだが、困ったときに上手く使うと便利なので紹介しておきたい。

業務システムは、ウェブアプリなどのオンライントランザクション処理（OLTP）と、バッチ処理に大きく分かれる。OLTPでは入力してから3秒反応ないと利用者が困惑する（あばれだす）と言われ、30秒から60秒以内で処理を完了しないと、だいたいのミドルウェアの標準設定でリクエスト・タイム・アウトになってしまう。一方、バッチ処理は原則として時間制限がない。

オートスケール不要な地方自治体のシステムでも、オブジェクトストレージとコンテナ化技術は有用だよ

デジタル庁クラウドチームがクラウドサービス上でオートスケールを動かすと言う観点でしか話をしないので、コンテナ化技術（Docker, Kubernetes）とオブジェクトストレージの有用性が疑われているようだ。しかし、オンプレミスなシステムでも、地方自治体のシステムでも、有用な面があるので指摘したい。

デジタル庁クラウドチームはセールススローガンだけを並べるのを止めるべき

デジタル庁テックブログの「ガバメントクラウドにおけるモダン化の意味と定義」が、SNSで強い反発を受けている^*1。

その理由はおそらく二つだ。一つは、踏み込みすぎな感のある要素技術の布教になっている^*2。一つは、紹介しているモダンな技術の利点を十分に説明できていない。モダンな技術の長所・短所を理解できているのか、どうも疑わしく感じる。

Rによる統計解析をシステムに組み込むのは、言うほど非現実的ではないよ — メッセージ・キューを使えばね

「R言語は本当に実装向きではないのか？— 固定観念を問い直す」と言う記事を見かけたのだが、シングルスレッドだからシステム構築に向いていないと言う主張がされていた。Pythonのウェブアプリケーションもシングルスレッドで使われているわけで、話がおかしい。恐らくシステム構築に関わったことが無い人が書いている。

ガバメントクラウドに関係なく、自治体のセキュリティー対策がしっかりしていた件

自治体によっては難航している^*1ガバメントクラウドの導入理由の一つに、セキュリティーの向上がある。しかし、クラウド化自体はセキュリティの向上をもたらすわけではなく、アプリケーションにおける効果は極めて限定的に思えた^*2。

これまでネットワークなどでセキュリティが不十分だったので、クラウド化と同時に強化しようと言う話かと思い、ガバメントクラウド前の市区町村のセキュリティー対策を確認してみたのだが、意外にしっかりしたものとなっていた。

コンテナ化技術（Docker, Kubernetes）の時代

ウェブやデータサイエンス方面のソフトウェア構築では、気づくとコンテナ化ソフトウェアのDockerが必須技術のように言われており、コンテナオーケストレーションツールのKubernetes（クバネテス）がデータセンターの新たな基盤になったような話を見かけるようになった。コンテナ化技術の時代。

コンテナ化技術は、データセンターのクラウド化（IaaS）を可能にした仮想マシン技術とよく対比される。技術的には随分と異なる。仮想マシンはオペレーティング・システム（OS）にまるでハードウェアがあるかのように見せる技術だが、コンテナ化はOSの名前空間とプロセス管理をつかったアプリケーションの隔離である。しかし、コンテナ向きの仕事を、仮想マシンがしばらく担ってきた。

デジタル庁の認証ポリシーがOAuth/OpenID Connect/SAMLがぶ飲みで良い感じな件

デジタル庁のテックブログのクラウドチームの記事には、認証まわりの話がほぼ無い。アプリケーションを書く立場からすると、「ログインどうするんだよ？」となってしまう。しかし、デジタル庁が抜けていたわけではなく、むしろ認証まわりはガッチリ固めていた。クラウド化と同時展開しないでくれと言う感じではあるが。

デジタル庁クラウドチームの推す技術スタックに無かったアレ

あるツイートを目にしたのをきっかけに^*1、デジタル庁クラウドチームのテックブログをだいぶ読み込んで来て、だいたいスケーラビリティとレスポンスの良さを目指しているのが分かってきた。しかし、技術スタックに何かが足りない。そう、long pollingが無い^*2。

ガバメントクラウドが要求するモダン化されたアプリケーションだからと言って、セキュリティー万全とは言えないよ

ガバメントクラウドは、クラウドの中でもシステムの土台の方へのサービス（IaaS，PaaS）に関する認定で、政府情報システムのためのセキュリティ評価制度（ISMAP）に基づき高いレベルのセキュリティ対策が必要になる。しかし、ガバメントクラウド上で動く（SaaSを含む）アプリケーションに関しては、特段の監査は行われない。

地方自治体向けのアプリケーションのASP向けの規制案「ガバメントクラウドにおけるSaaS（公共SaaS）について（案）」が出て来て、不十分なセキュリティ対策ではないかと言う声が上がっている。ASPは事業者で、SaaSはアプリケーションを提供するサービス。対策不十分と言うだけではなく、何か勘違いをしている可能性がある。

デジタル庁クラウドチームのWeb API（と言うかSPA）推しにあふれるスケーラビリティ重視

ウェブアプリケーション全盛の時代だが、その外見は大きく二つに分けることができる。従来型の複数のページを遷移していくマルチページアプリケーション（MPA）と、ひとつのページの中の情報が置き換わるシングルページアプリケーション（SPA）^*1だ。

組み合わせることもできる^*2ので分類ではなくて比重の問題だが、ショッピングサイトやコンテンツ管理システム（CMS）、画面遷移がある方がユーザーが混乱しない場合はMPAであることが多く、𝕏/Twitterのようなマイクロブログ型SNSやチャットはSPAになっていることが多い。

デジタル庁クラウドチームの推奨アーキテクチャへの移行をしても、複雑怪奇な夜間バッチは複雑怪奇なイベント処理にかわるだけ

バッチ処理は、パンチカードでプログラムを書いていた時代からの、電子計算機の最古の利用形態だ。汎用機では、昼間にオンライン処理で入力したデータを、夜間にオフラインバッチ処理する利用方法が長く取られて来た。リソースが空く時間にまとまった処理ができる合理性があるからだ。大企業では数千のバッチ処理が複雑に連携して動いている^*1こともあるそうだ^*2。

ギーク感あふれるデジタル庁クラウドチームのデータベースへの理解

筆が滑っただけだと思うが、デジタル庁クラウドチームのデータベースへの理解が不十分な気がしてきたので指摘したい。データ中心主義（DOA）からプロセス中心主義（POA）に逆戻りしている。また、業務要件からデータベースのトランザクションが満たすべき性質を考えていない。

古臭い話で、クラウド大好きギークの皆さんは好きではない概念だと思うが、忘却すると地獄の業火に焼かれることになる。