KADOKAWAが運営する小説投稿サイト「魔法のiらんど」が3月31日をもって、単独でのサービスを終了する。4月以降はWeb小説サイト「カクヨム」と合併し、同サイトの1ジャンルとして運営が続ける。
組み込み用のスクリプト言語として使える Lua はライトな反面、動的型付けや 1-based index といった仕様がボトルネックになりがちです。そうした状況の中、相応の短所も抱えた Lua の代替となりえる C/C++ 開発用組み込み用のスクリプト言語が多く開発されています。しかしながら、それらを横並びで比較及び評価した記事をあまり見かけませんでした。そこで、本記事では AltLua となりうる言語を取り上げ、それぞれの特徴を検証していきます。
むかし米国人の書いたコードをレビューした時のこと。データ量が少ない時は問題なくても増えてきたら必ず遅くなる箇所があったので直すようにコメントした。すると相手曰く「なあ、それは今やる必要があるか？」。もちろん、今やっておかないと後で大変なことになる。「当然だ」と答えた。
すると「どれくらいの確率で問題になると思う？」と聞いてきた。まあ正直分からない。サービスが当たるかどうかなんて事前には分からない。そう答えると「そうだよな。だったら今やる必要はない。日本人てのは起きていない問題まで見つけてくるから大したものだ」。嫌味というより素直に感心している。
「心配事の大半は起きない。だったら期待値の低いことにリソースを振り向けるのは非効率だろ。もっと優先度の高い問題がある」。確かに機能面でもかなりの重大なバグが山積みになっている。非機能はどうしても後回しにされがちなのは日米共通だ。もうこうなると良し悪しというより価値観の問題だ。
結局、客とも相談してコードは直さないことになった。問題になったらまたその時対処しよう、ということになった。リリース後、心配していた性能問題は出なかった。でもその理由はサービスが当たらなかったからではなく、重大なバグが見つかって全面的に処理を作り直すことになったからだった。
日本語だと「不確実性」という一語しかないが、英語ではriskとuncertainty という言葉で区別する。riskは確率がある程度分かるもの、uncertainty はそもそも確率が分からないもの。riskの方は期待値で合理的に対処が出来るがuncertainty は扱いにくい。我々2人とも後者に翻弄されてしまったのだった。
risk管理は米国人も真面目にやる。といっても日本人みたいに全部潰すわけではなく期待値の大きものから優先度をつけて対処する。uncertainty については、ある種の諦念を持っているように見えた。「想定できないものは想定できない」という感じ。
過つは人の常、赦すは神の業。
ちなみに予測可能なriskと不可能なuncertainty の区別は、経済学者フランク・ナイトが行ったもの。これ豆な。
Googleは、Android OSの開発を今後完全に非公開化するそうです。Googleに確認をとったAndroid Authorityが、独占情報として伝えました。
これまで一部のコンポーネントは、オープンソースプロジェクト（AOSP）を通じて公開開発されていましたが、来週からすべての作業を社内の内部ブランチに一本化するとのこと。
今回の決定は、Googleが現在抱える2つの開発ブランチの統合が目的。これまでは社内の非公開ブランチと、公開されるAOSPの2系統で開発が進められており、両者の間で発生するマージ作業の負担が大きな課題になっていました。開発を内部の一本のブランチに絞ることで、開発プロセスの簡略化やスピードアップが狙えるとしています。
一方で、今回の変更による一般ユーザーへの影響はほとんどないそうです。アプリの開発者に関しても影響はなく、これまで通りのアプリ開発が可能。 OSのソースコードも引き続き各バージョンのリリース時には公開となるため、Androidが完全な非公開ソフトウェアになるわけではありません。あくまで開発の非公開化です。
ただし、Androidのプラットフォーム自体をカスタマイズしている一部の外部開発者やROM開発者には影響が出る可能性があります。開発状況がリアルタイムで確認できなくなるため、情報の取得が遅れることになります。ただ、一般的にカスタムROMなどを開発する場合は安定版をベースに行われるため、影響は軽微にとどまるだろうとしています。
Googleは今回の決定について「開発効率化を図るための現実的な選択」と説明していますが、透明性の低下も懸念されます。続報を期待したいところです。
最近DHHがonce.comでのCampfireをはじめとしたプロダクトで、NULL制約やDB制約で防げるようなRailsのモデルのバリデーションを積極的には利用しないでいるという主張をしている。
自信がなくて「どうすればいいと思う？」って聞くくらいなら、Railsのバリデーションを書くコストは高くないから書いた方が良い。バリデーション書いても、DB制約はつけておくべきだし、ユニットテストもするべき。上級者がサービス作成のフェーズで僅かでも工数削減したいから利用するテクニックであり万人に勧められるものではない。また、無理してシンプルなバリデーションをDB制約に置き換えたりということも現場レベルで困っていることがなければしなくて良いように思う。
時代は巡るといいますが、「ググる」という行為に対しても昔同じ感想を抱きました。
「こんな、検索一つで関数やコードの書き方がみつかっていいのか！？全然考えてないのでは？」
でも、今の時代、ググらずにコードを書く人なんかいません。
ググれるようになる前は、WindowsやMac OSのコードブックがオフィシャルからリリースされててそれを死ぬほど読み込んだり、言語の手引書を発狂するほど読んだりしてコードを書いていました。
それしか手段が無かったからです。
ただその行為もさらに昔の開発からすると、かなり充実した環境に感じられました。
昔はOSやCPUの仕様書だけで開発をしていて、必要であればリバースエンジニアリングを行って動作を確認し、コードに組み込んでいたこともあります。
今からの時代はどれだけAIを活用してコードを組むかが重要になってくると思います。
そのうち開発ツールにも組み込まれると思いますし、どんどん活用して上達することをお勧めしますね。
Linuxカーネルの開発者、リーナス・トーバルズ氏がLinux 6.14のリリースを「忘れていた」ことを明らかにし、「純粋に無能だった」と謝罪しました。
かつてSESの人たちは職業プログラマーが多く、休日に勉強するなんてあり得ないというカルチャーだったんですよね。その流れでWeb系の企業に面接に来た際、新しい技術について質問されると、必ず「入ってから頑張ります」といった回答をしてしまい、結果として面接に落とされることが多かったんです。
一方で、Web系の人たちは当時から休日に勉強会へ参加したり、趣味で新しい技術を試したりしていたので、そうした文化の違いが「カルチャーギャップ」として語られていました。ただ、今は未経験から勉強する人が増えたこともあり、業界間のカルチャーギャップは少しずつ縮まってきたように思います。
もともとWeb系の人たちは、勉強会で新しい技術ネタを仕入れ、それを趣味として試したり、社内勉強会で展開したりしていました。そして、それを実務にも活用することで、結果的にWeb系ではモダンな開発環境が整い、そうした取り組みを推進していた人が評価される流れが生まれました。そうした背景があるからこそ、「プライベートで勉強すること」が正しい行いとして定義されていったのかなと思います。
「休日も勉強しろ！」って言ってくる会社って...実はホワイト企業なの知ってましたか？
どういうことかというと...↓↓
エンジニアは休日も勉強すべきか？と質問をよくもらうけど、個人的な結論としては、アウトプットさえよければどちらでもいい。
で、実はこの意見を言う人ってかなり優しい考え方なんですよね。
なぜなら、この質問って先輩エンジニアや経営者が若手を評価するときに質問することが多いんだけど、
実際、エンジニアとしてのキャリアが進むと、部下が休日に勉強しているかどうかなんて関係ない。
「良いアウトプットを出せるか？以上」みたいな。いわゆる結果主義。
ですがもし「休日も勉強しろ」と言われる環境なら”過程”も評価してくれる会社かもしれないので、実はホワイト企業だったりします。
会社選びは表面ではなく本質で判断するのが大事。
今から新規にWebサービスを作るなら、そもそもパスワードは作らせずにメールアドレスで毎回認証させると思う。メールアドレスが盗まれるとログインされる問題はあるけど、そのレベルの人にこそパスワードを作らせるわけにはいかないので一番現実的だと思う。
金融系だとメールアドレスアカウントが盗まれているリスクが無視できないのでSMS認証が広く使われているけど、SMSの奪取は海外だと一般的で、日本でも通信会社によっては脆弱で実際事故があったわけで、しかもSMSは日本だとめっちゃ高い（1通数円程度）ので、そこまで価値があるとは思わない
ITエンジニアが最強だと思っている高度なアーキテクチャが技術力の高い企業に採用されてるのは「サービスが超絶儲かっているから」であって
お前らが担当する、そこそこしか儲からないシステムに高度なアーキテクチャは不要。
ITエンジニアの自己満足はビジネス上、害悪であると言い切った元上司。
梅林 たしかに「メンションの即レスを期待しない」という標語が全社的に使われていますが、それは仕事のコンテキストスイッチを入れないためでもありますね。集中してタスクにあたっているときにレビューやCSのサポートを依頼されますが、そのとき手掛けている仕事の切りのよいタイミングでやってほしいと考えているので。
逆に非同期のコミュニケーションが中心になると、いかにお互いのビジビリティを高めるかが課題になります。例えば開発においては、分からないことがあったら「分からない」と自分で発信できる方がいいんですよ。
コードを書くときに「何か分かんないけど、他のコードではこうなってるな」という状況があったら、黙ってコピーするよりも「何でこうなってるんでしたっけ？」って聞いてくれればその人の理解度も分かるし、なぜそう実装しているかもきちんと説明できます。
そのためには「何でそんなことが分かんないの？」という空気は絶対に作っちゃいけない。会社全体のバリューとして「100回同じことを聞かれても、100回笑顔で答える」というカルチャーでいこうと全員が本気で思っていますし、だからセールスやカスタマーサクセスの人もエンジニアにどんどん質問や相談をしてきます。
── さらにエンジニアの開発スタイルは「マルチタスクアサイン」「セルフサインアップ」「チケットに納期を設定しない」だということですが、これはどうしてでしょうか。
梅林 エンジニアは基本的に管理されたくないんですよ。朝会なんて誰もやりたくないですし、僕自身も管理したくない。僕自身が過去にICとして働いてきた経験から、これは不要だなと感じたマネジメント要素を取り除いた結果、このスタイルになっています5。
梅林 ちなみにチケットは納期こそ決めていませんが、プロダクトマネージャーが状況に応じてソートしていますから、基本的にタスクを上から取っていけばプロダクトにプラスになるようになっています。
その上でレビュー依頼だったり、開発以外のメンバーの相談だったりにはエンジニア個人の裁量で自由に対応できる方がいいですね。要望の本当のペインを確認した上で解決方法を考えるため、エンジニアが直接お客様とのミーティングに参加することもよくあります。
そうして使っているのは誰で、開発すれば誰がよろこぶかということが分かると開発しがいがあります。そうじゃないと何のために開発しているのかが分からなくなりますね。マネージャーのために開発しているんじゃないので。
頭悪そうなプログラマーやSEが軒並みみんな俺の仕事はAIで代替できないって言ってるから多分これは本当に大虐殺が起きるんだろうなと思う、次どんな仕事したらいいんだろうなあ
偽情報の問題が出ているが、インターネットがいろいろな意味で限界に近づいたと感じている。ＮＴＴは２０１９年５月に次世代通信基盤「ＩＯＷＮ（アイオン）」構想を発表した。インターネットの次をそろそろ考えるべきではないかということだ。
情報の概念は、２０世紀半ばにシャノンが定義した。それまでのコンピューターは単なる計算マシンだった。情報を扱うことになったのは２０世紀半ばくらいで、そこからコンピューターが進化してきた。情報の正しさを判別することが技術的に始まり、その後にインターネットが普及し、誰が情報を作ったのかを証明するデジタル署名の技術ができた。最近は、ブロックチェーンのような新しい分散型の仕組みで情報の正しさを証明する動きがある。
問題は、生成ＡＩ（人工知能）が出たことだ。それ以前のＡＩは、人間の勘や経験などを処理するのは難しいと言われてきた。それが、データを学習すればＡＩでもできるということになった。生成ＡＩは人間を超えたようなコンテンツを今後もどんどん製作する。本当に正しい情報なのかを判別するのは技術的に難しい。
インターネットは万能ではなく、欠点がたくさんある。大量の情報を処理するために多くのエネルギーを使うし、偽情報があたかも本物のように全ての人に行き渡ってしまう。新しいインフラ（通信基盤）を考えることが重要だ。
ＩＯＷＮは、光の技術を使っていこうと思っている。情報を遠くに飛ばす時、電気は大量のエネルギーを使うが光はほとんど変わらない。高い潜在能力を持っている。消費電力は１００分の１くらいになり、今までインターネットでできなかったことがＩＯＷＮでできるようになる。
今のインターネットも光を使っているが、使い方が問題だ。今、ＮＴＴは光の全てのリソースをインターネットに差し上げている。産業領域ごとに波長を分けていくことが技術的にできる。すでにオールフォトニクス・ネットワークの商用化を開始した。
インターネットはプロトコル（手順）が決まっているので、どこに情報があるかを明らかにしているのが弱点だ。この部分を一生懸命暗号化して守ろうとしているが、破られる。
国や産業ごとに、情報がどこにあるか分からない世界が技術的にできる。情報を全てインターネットにさらけ出す必要はなく、完全にクローズドなネットワークができ、セキュリティーレベルが上がる。最終的には量子通信と呼ばれる領域まで持っていければ、今懸念しているようなことはほぼ解決できると思う。
年末年始に大きな「ＤＤｏＳ（ディードス）攻撃」があった。ＤＤｏＳ攻撃はこれまで、２００以下くらいのＩＰアドレスが使われていたが、今回は３０００を超えた。攻撃者がＡＩを使ってきた。守る側もＡＩを使うしかない時代に突入した。
サイバー攻撃が進化している。今までは（攻撃で使われるネットワークの）ボットネットを発見して対処するアプローチを取っていたが、ＡＩを使ってボットネットがダイナミックにぐるぐる回るため、（対処が）本当に難しい。
これをどう防ぐか。ＩＯＷＮを使ってインターネットの世界から一歩外れたところで、ＡＩがボットネットを監視して対処するやり方しかないと思う。各国がインターネットの中で対処しようと一生懸命やっているが、限界がある。
今のＡＩはほとんどのことができると思われているが、唯一できないことがある。それは、自分の答えを否定することだ。唯一無二の存在になってしまっている。いろんな専門的なＡＩをたくさん作り、信頼できるネットワークで結び、時として協力して答えを出したり、チェックしたりする。民主的な形でＡＩを利用していくアプローチでいけば、人間社会に近い形でＡＩが進化していくのでないか。
パターン６：操作ログとリクエストIDでUPDATEを冪等にする
パターン７：最終奥義「トランザクション」
パターン２：エラーを区別してDELETEを冪等にする
パターン３：操作をまとめて冪等にする
パターン４：操作を細かくして信頼性を高める
パターン５：操作ログとリクエストIDでUPDATEを冪等にする
大規模なデータに触れることが日常茶飯事になっている今日この頃。この分野のおもしろいところは、いつまで経っても終わらないプログラムを簡単に作れてしまうことかもしれません。エラー処理、リトライそして冪等性*1の３つを抑えていないプログラムは、小規模なデータなら問題ないが、データ量が多くなると使い物にならなくなる可能性が大です。
大規模データをバッチ処理するケース以外でも、リトライは一般にプログラムの信頼性に関わる重要な問題です。
そんなわけで、リトライに関わるいくつかのデザインパターンを、連載でまとめておこうと思います*2。
では、第1回は背景から：
パターン1：IDを付けてCREATEを冪等にする
パターン２：エラーを区別してDELETEを冪等にする
「Ubuntuらしい」チャレンジングな試みが開始されます。Jon Seagerによる『酸化』の試みのDiscourse上のポスト[1]では、coreutilsをRustベースの新実装であるuutilsで置き換え、可能であれば25.10でデフォルトにし、26.04 LTSでも同様にデフォルトとする方向が示唆されています。
coreutils（GNU core utilities）はLinuxシステムにおける基本的なコマンド群で、lsやmvやrm、cp、chownなどなど、「コマンドライン操作では必ず利用する」ツールキット群です。これを別の実装に置き換えるというのは非常に大きな変更といえます。
もっとも今回Ubuntuで行われるアプローチは、全体的にあくまで実験であり、「必ず達成する」性質のアプローチではないことが強調されています。現実的な問題が発見された場合は先送りされることが明言されています。coreutilsは暗黙でシステム全体から依存されており、この置き換えが成功するかどうかは現状では誰にもわかりません。現時点でこうした試みを試すには、oxidizrを用いて既存のコマンドを置き換えるという方法があります。
Ubuntuがこの挑戦を行う目的として、「スピードよりもRust採用による堅牢性（とレジリエンシー＝修正の容易さ）の確保」ということが示唆されています[2]。しかし、C言語ベースの実装からRustへの置き換えというものはどちらかというと「誰か（いずれかのディストリビューション）が試さない限りは未来がやってこない」タイプのチャレンジで、これを実施することで「未来がくる速度を加速する」ことが目的のように読み取れます。
システムにおける「区分」とはカテゴライズ可能な値の集合体を表すものであり、「区分値」とはその集合に属する個々の識別子を指します。
たとえば、あるアイテムの「ステータス」という区分には「下書き」「レビュー中」「承認済み」といった区分値が含まれます。
一見すると、こうした区分値は単なるラベルでしかなく、設計の検討余地があまりないように思えるかもしれません。しかし実際には、区分値の扱い方次第で、システムの柔軟性・拡張性・保守性などに大きな差が生まれます。
本記事では、この「区分値」の設計について、あらためて整理し、より優れたアプローチを再考していきます。
シンボル値による表現は、伝統的な業務システムにおいて長年にわたって広く使われてきた手法ですが、結論から言うと昨今のモダンな開発現場においては 「セマンティック値」での表現を第一に検討することが望ましい と考えます。
そこで本稿ではウォーターフォールやアジャイルなど従来型の開発手法をおさらいしたうえで現在のシステム生成AIプロダクトの問題点を考察し、AIを前提とした新たな開発手法を考えてみたいと思います。
ではAIを使った開発は中小規模のアプリケーション開発及びエディターのような補助的ツールにとどまり、メインストリームになることはないのでしょうか？
先述しましたがアプリケーション開発ツールが中小規模にとどまっているのは土台のないところに枝葉を加えていくことで全体の整合性を取れないことが原因です。
解決策はウォーターフォールのように土台を作ったうえで開発を進めていくことだと考えています。
ただし従来のウォーターフォールに回帰することでスピード感・柔軟性が失われては本末転倒です。生成AIによりさらに変化が激化するIT業界では致命的になるでしょう。
そこでAI時代の新開発手法として超高速軽量ウォーターフォールを提案したいと思います。
これは何かというと従来のウォーターフォールに必要なドキュメントをそのまま作成するのではなく、AIのインプットに必要なドキュメントをAIにより生成することでドキュメンテーション工数を軽量化し高速でウォータフォールを実行する開発手法です。
そもそもアジャイルがスピード感を持って開発できるのはドキュメンテーションをコミュニケーションで代替しているからであり、アジャイルでメンバーにクオリティが求められるのは空中戦になりやすいからです。 なのでアジャイルの方法論はアウトプット定義というよりもコミュニケーション定義及びプロセス定義にフォーカスされたものが多いです。
現状のLLMは良くも悪くも入力された情報を処理して出力する魔法の箱のようなものなので、入力情報が乏しいまたは人間間のコミュニケーションに特化されているアジャイルはむしろAI開発とは相性が悪いように感じています。
基本コンセプトは要件定義から運用までを高速で回すことで柔軟性を担保するという点でよく似ています。
異なる点はリリースポイントです。もちろんスパイラルのようにフェーズに区切って大きな単位でリリースするのもありですが、AIをフル活用する超高速軽量ウォーターフォールでは機能単位の実装が比較的早期に完了するので、機能ごとにリリースすることが可能です。
超高速軽量ウォーターフォールのプロセスは以下です。
(1) 企画・要求をもとに要件定義書を生成
(2) 生成されたアウトプットを人がチェックし修正
(3) 修正された要件定義書をもとに設計書を生成
(4) 生成されたアウトプットを人がチェックし修正
(5) 修正された設計書をもとにソースコードを生成
(6) 生成されたアウトプットを人がチェックし修正
(7) デプロイ
超大手JTCの中に入って実感してきたけど、ありとあらゆることを下請け会社が忖度してやってくれるので、新卒から超大手JTCで働いていたら、それが当たり前だと思うようになるんだろうなー。
外から見たら、尊大で何もできない人達なんだけど、本人達は一生気がつかずに幸せに生きていくのだろう。
解雇規制が厳しいからです。ある企業が「よし、来月から半年間50人体制でプロダクト作るぞー」と思っても、雇用流動性がないので50人の（ちゃんとした）プログラマーを短期間で雇用するのは相当給与水準が高くないと不可能です。しかも半年後には解散か縮小することが分かっていたら、解雇規制が厳しい日本だと更に雇用は難しい。
なので派遣とかSES業者に人出しを頼むことになります。でもそういう会社も空き要員って常にプールしてる訳でもなく、大体他の案件に人が張り付いています。人が空いてるかどうかって運なんです。空いてたとしても50人空いてることは稀なので、その会社で埋められない要員は更に別の会社に依頼することになります。
これが繰り返されて、孫請、ひ孫受け、その先までいってようやく客先の希望要員数が充足します。
案件が長く続いて少しずつパフォーマンスの悪い末端要員がスイッチされたり、案件縮小のタイミングで多少多重構造が改善したりすることがあります。でも納期が短いと難しいですね。長い案件でも、マイルストーン毎の納期が厳しかったりとか。
多重構造は悪、SIerがあくどい人月商売してるからだ、みたいに言われますけど、SIerもそんなに儲かってないです。やりたくてやってるわけでもない。本当は全部自分らで請けたい。客先もそれを望んでる。でも人がいないから外で調達して自分らで管理するという形にせざるを得ない。人月商売批判する人は、じゃあどうすればそれなりのアウトプットを保証できる50人のプログラマを1ヶ月2ヶ月の短期間で用意できると言うのですか。やってみたことありますか。ちなみに多重にしないでスコープ削ると、スコープ大きめで請ける他社に持ってかれて失注します。そりゃ客も楽したいから。
解雇規制がもっと緩くなれば、労働市場に出てくるプログラマーも増えて、チームリーダー含めそのプロジェクト用に直接プログラマーを雇い、完成したら縮小または解散、のようなことも出来るようになると思いますが、まあ当分は無理でしょう。
Xの日本法人は12日、同社のプラットフォーム運営に関して声明を出し、検閲は行なっておらず、シャドウバンも実施していないと説明した。
同社では、一部ユーザーから運営に関する誤解や懸念の声が上がっていることに対し、改めてプラットフォームとしての指針と運営方針を説明するポストをXに投稿。Xが言論の自由を推進するプラットフォームであり、これは国内においても同様だとした。
その上で、Xが安全で健全な環境となるよう常に取り組みつつも、プラットフォームの方針に基づき検閲を行なうことはなく、シャドウバンも実施していないと説明した。なお、Xの定めるルールに違反した場合は、アカウントの凍結やコンテンツの削除を求める場合があるとしている。
まず、容量の割に重くて大きいという点だ。また普及していないので価格が高く、ナトリウムイオン電池はPSE（電気用品安全法）対象外のため、PSE取得マークを付与できない。
モバイルバッテリーなど小型充電式電池を回収してリサイクルする団体「JBRC」の会員であるにもかかわらず、対象外（対象となっているのはニッカド電池／ニッケル水素電池／リチウムイオン電池）ゆえに、家電量販店などに設置してある回収ボックスを使えないというデメリットもある。
エレコムでは「地方自治体に問い合わせいただく、弊社サポートセンターへ問い合わせいただく、エレコムデザインショップへお持ちいただくことで、回収できる」としている。
中央集権的な管理に対して、データスペースは分散型のアーキテクチャでデータを管理します。データは通常、データ提供者が保持しており、そのデータをコネクタと呼ばれる通信モジュールを利用してコネクタ間でデータの交換を行います。
データスペースでは、あるデータ提供者のデータを管理するデータベース(あるいはクラウドストレージ)に障害があった場合でも、影響範囲は限定的され、それ以外のデータ提供者は影響を受けることはありません。また、サービスが終了や垢バンなどによる、サービスの利用継続が不可能などの問題からも開放されます。
また、システムを開発・提供する側としては、データをユーザ(企業・組織)側で保持することにより、各システムのスコープを絞ることができ、モノリシックなサービスを分割しマイクロサービス化を行うようなアプリケーションのモダナイズに似たメリットを享受することができます。更にはデータスペースによる標準化されたデータ交換方式により、データ連携部の開発をスムーズに行うことができます。これらのメリットにより、ユーザ毎のシステム開発速度が向上し新規ビジネスに柔軟に対応できるようになり、また、各システムがデータ利用者・提供者側に寄ることにより、よりユーザの要件に適合した無駄のないシステム開発が可能となります。
データスペースは、中央集権型アーキテクチャの問題を解決するだけでなく、サステナビリティやデータ主権といった、以下のような新たなユースケースでも注目されています。
内部からの告発によって動き出した内部調査委員会の報告が遅れている。
元々24年内予定だったのが遅くとも2月までと遅延し、2月18日には最終的な取りまとめを行なっているとしている。
PyCon JPにおける登壇者採択に関する内部調査委員会の設立
https://pyconjp.blogspot.com/2024/10/selection-view-3.html
なお、調査結果の報告は年内を目標にしており、遅くとも2025年2月までにはご報告できるよう進めています。どうか今しばらくお時間いただけますようお願い申し上げます。
2025年2月18日 現在最終的な取りまとめを行っております。当初の予定より報告が遅れていることをお詫び申し上げます。
経緯はこれら
https://b.hatena.ne.jp/entry/s/qiita.com/python_bokume2/items/7aa80b73010919007581
そして3月に入り休日も過ぎ、平日も過ぎた現在も特に進捗の報告もなく、先日動画配信の報告記事が更新されたが内部調査の進捗には文章中では触れられていない。
信頼が揺らいだ騒動についての報告が最終取りまとめから思ったとおりに進まないということは、単に問題はなかったという報告ではなく込み入った事情が絡んだ報告になるのか。
内容はわからないがともかく、当時の対応、二度の遅延、今の遅延の釈明なし、と現段階では不誠実と感じざるを得ず、報告が問題ないとしても疑わしいし、問題があったと断定してもよほど誠意ある内容でなければこの不信感は消えないものだろう
幾つか理由が考えられます。
1. 拡張性：データサイズには限界があるだろう。おそらくMSとしてはExcelで扱うには不満がある程度には大きなデータを対象にしてる。しかし巨大なデータサイズには対応しそうにない。MS Accessのサーバーを複数台へスケールアウトするのって、ちょっと想像できない。
2. 継続性：Officeファミリーの一部は新版からなくなるモノが多い。継続してくれるか不安。
3. 互換性：新版が出た場合、以前の物と互換性があるか不安。
4. 情報漏洩：セキュリティに不安がある。
.
わたし的には、1レコードのアクセスごとにロックされず、前後の数レコードまとめてロックされるのがいや(RecordLocks プロパティで、2人のユーザーが同じ1つのレコードを同時に編集しようとした時の動作の事ではない)。アプリの設計で、異なるレコードへの同時アクセスの動作が保証されてないとか、例外処理で悩みたくない。例えば、1000番目のレコードと1001番目のレコードを比較してその結果で更新して書き戻すプログラムは書けるが、動作させると（それらは同じ記憶領域の1つのブロックだから）デッドロックになって止まる…とか。
そういうバカみたいな制約から解放されるなら、無料のPostgreSQLを選ぶ。
ちなみに……やたらプロパティとメソッドの呪文がダラダラ長くなる悪癖を持っていても、VBAはロジックとして分かり易いからそれは（わたし的には）問題ない。
経営がDXを推進すべきなのは当然ですが「まずは経営が意識改革しなくてはダメだ」というのも誤認です。「会社でDXが進まないのは、経営|レガシーシステムのせいだ」というのは正しいですが、
- まずは経営が変わらねば
- まずはレガシーシステムを一掃せねば
- まずは内製エンジニア組織を作りSIerを一掃するのだ
という思考に向かうのは、非生産的です。屏風の虎は出てきません。
そんな解けない問題を前に腕を組んで批評だけしていても事態は一向に進みません。もう、2025年です。物事を自分の手で前に進める気がない人は黙ってていただきたい。害悪です。やる気のある若者でも、そういう言説に影響されて腕を組んでしまう。
そうじゃなくて、意識が変わりきらない経営層、色々な問題があるレガシーシステム、足りていない人材という中で「どうやったら会社のDXを進めることができるのか？」という視点に立つべきなのです。
20年前のweb開発、「みんな知らないけど…… HTMLに値を出力するときは………… エスケープというのをするといいらしい！！！！！」（一同感動）みたいなノリだった記憶がある。
本当にみんなエスケープという概念を知らなかったので、その辺のフォームに変な字を入れると30%くらいの確率でXSSできてました。さすがに偽の記憶では？
今回研究者たちが謎のコードを発見したのは、ATARI2600で1982年に発売されたゲーム『Entombed』です。
これは上から下へと画面が移動していく縦スクロールアクションゲームで、プレイヤーは画面に押しつぶされないようにルートを選んで迷路を攻略していきます。
後戻りはできないため、行き止まりにぶつかってしまうとゲームオーバーです（アイテムにより決められた回数だけ壁は破壊できます）。
このゲームの迷路はひどく単純なものに見えますが、当時のゲームカートリッジのメモリでは、予めデザインした迷路セットを保存し、後から読み出して表示するということができませんでした。
そのためこのゲームは、迷路を設定された「手続き」に従ってランダム生成しています。
問題は、このゲームの迷路がどうやって無用な壁の生成や、侵入できないようなエリアの生成を避けているのかという部分です。
このゲームでは、進行に合わせて迷路を連続生成しています。プログラムは現在描画されている迷路を解析し、次に現れるスペースそれぞれに壁を描画するかしないか判断します。
問題は、この壁の配置を決定する基礎理論が、どうやって作られているのか理解できないことです。
壁の配置決定に使われているパラメータテーブルの値が、どうやって導き出されたものなのか全くわからないのです。研究者たちは、テーブルに含まれる値のパターンを見つけようと試みましたが、無駄に終わりました。
しかし、このテーブルの値が僅かに異なったりすると、もう迷路は通行可能な形で描画されません。
研究者たちは後に、このゲームの開発者の1人と接触することに成功しましたが、その開発者も迷路生成のアルゴリズムは当時から理解できなかったと話します。
彼の話によると、担当したプログラマーは「酔って頭をぶつけた拍子に、このアルゴリズムを思いついた」と語ったそうですが、研究者らは問題のプログラマーと接触することはできなかったとのこと。
日本のインターネット黎明期を支えたISPのホームページサービスが徐々に消えつつある。NTTドコモは、ISPサービス「ぷらら」の個人向けホームページサービスを3月末に終了、30年近い歴史に幕を閉じる。
ドコモがぷららの「プライベートホームページ」サービスの終了を発表したのは、2024年6月だった。これによると、25年の3月末をもってサービスを終了し、ユーザーのコンテンツは4月30日に「完全に削除」されるという。
終了の理由は「サービスの利用が近年減少しており、今後継続的にサービスを提供していくことが困難となった」ため。同時に法人向けサービス「BUSINESSぷらら」のホームページサービスも終了する。
4月1日以降はアカウント名やパスワードなどの確認ができなくなるため、過去にアップしたコンテンツをFTPソフトなどでダウンロードしたいユーザーは、3月中に確認することが推奨される。
ドコモのぷらら事業は、1995年に日本電信電話やソニーら5社の共同出資会社として設立されたジーアールホームネットが起源。翌96年からプロバイダー事業を展開してきた。同社はその後NTT東日本傘下となり、22年にはNTTドコモと事業統合している。
インターネット黎明期から続くホスティングサービスには、テキストサイト全盛期に有名になったホームページも複数ある。このためSNSなどでは「（著名ホームページの）侍魂、終わっちゃうの？」「先行者のページ（2000年に中国人民解放軍国防科技大学が発表した二足歩行ロボットを揶揄したコンテンツ）も失われるのか」「我らネット黎明期世代の青春がああああ」などと一部で注目を集めている。
2025年3月2日、C++言語の創始者Bjarne Stroustrup氏が、C++言語を「深刻な攻撃」から守るため、C++コミュニティに支援を呼びかけた。
背景には、過去数年間でサイバーセキュリティ機関や技術専門家がC/C++のメモリ安全性の欠点を指摘し、Rust、Go、C#などの代替言語の使用を推奨してきたことがある。
2024年10月、米国サイバーセキュリティ・インフラストラクチャセキュリティ庁（CISA）は、2026年1月1日までにメモリ安全でない言語を使用している製品のメーカーに対し、メモリ安全性のロードマップ作成か、メモリ安全な言語への移行を求めるガイダンスを発表した。
Stroustrup氏は2025年2月7日に「C++標準委員会（WG21）へのノート」を発表し、Profilesと呼ばれるメモリ安全性フレームワークを提案した。
一方、TrapCプロジェクトを主導するRobin Rowe氏は、Profilesが2026年までに間に合わないと指摘し、自身のTrapCコンパイラが2025年後半に準備できる見通しを示した。
ケンブリッジ大学の客員研究員David Chisnall氏は、言語レベルのメモリ安全性ソリューションに懐疑的な見解を示し、CとC++をより安全にするアプローチを支持している。
現在、C/C++で書かれたコードは世界中で数十億行に及ぶと推定されており、これらを短期間で書き換えることの困難さが指摘されている。
Inceptionという会社のMercuryという拡散言語モデルがすごい。
いつか出るだろうと思っていたのだが、なかなか姿を見せなかった、拡散言語モデルである。
いまAIは、「頭の良さの差」を競う段階に来ている。
「頭の良さ」を測る尺度はたくさんあるが、僕は答えの用意されたテストを解くことをたいして良い尺度だと思っていない。まあ答えの用意されたテストしか解いてこなかった人たちにはそれでも十分な尺度なのだと思うが。
拡散モデルは、画像生成の世界ではトップランナーだった。
最近は拡散TransformerのFLUXのようなものが台頭してきたが、速度という点では未だに拡散モデルに軍配があがる。
ただし画像の拡散モデルも、「正確さ」という点ではなかなか厳しいものがある。
しかしMercuryは、速い上に正確な答えを出す。
Go Module providing robust framework for running complex workload scenarios in isolation, using Go and Docker. For integration, e2e tests, benchmarks and more! 💪
Go と Docker を使用して、複雑なワークロード シナリオを分離して実行するための堅牢なフレームワークを提供する Go モジュール。統合、e2e テスト、ベンチマークなどに使用できます。💪
この世に「プログラミング言語」という存在が生まれた1950年代にも、「使いものにならない」と述べるプログラマがいたらしい。アセンブラどころか、バイナリでプログラムを組んでいた人々だ。
生成AIの吐くコードを「使いものにならない」というプログラマを見るたびに、この逸話を思い出す。
実際、当時のコンパイラは性能が悪く、マシンパワーも弱々だったので、彼らの言い分には一理も二理もあったようだ。そういうところも、現在の「生成AIが吐くコード」に似ている。内容を理解していないのに改修どうすんねん？保守性は？セキュリティは？ってツッコミ、ぜんぶド正論だ。
プログラミング知識ゼロのぼくは、今のところClaude 3.7 sonnetで生成したコードをo1 proにデバッグさせて、o1 proで生成したコードをClaude 3.7 sonnetにデバッグさせている。分からない用語が出てきたらo3-miniに解説してもらう。（※Geminiは触っていないから分からない）
簡単なJavaScriptのゲームなら、爆速で作れる。あと、画像生成AIで作った膨大な枚数のイラストを整理（※一括で名前変更したりリサイズしたり1枚に繋げたり）するためのプログラムを、Pythonで作ったりしている。
計算機の歴史からいえば、Claude 3.7 sonnetのようなコーディングに強い生成AIは、「BASIC」に似ているかもしれない。当時主流だったFORTRANなどの言語は扱いが難しく、文系の学生でも扱える言語を目指して――コンピューティングの民主化を目指して――BASICは生まれたらしい。
かつてコンピューターは非常に高額な道具で、大学や企業の「電算室」から動かせないものだった。パーソナル（個人用）コンピューターなど夢物語だった。しかし1960年代になると「タイム・シェアリング」という技術が開発され、1台のコンピューターを複数人で同時に使えるようになった。
タイム・シェアリングによってコンピューターにアクセスできる人間が急に増え始めたことも、BASIC誕生の背景にはあるらしい。
どの製品を「世界初のパソコン」と見做すかには議論がある。有力な候補の1つが、Altair 8800だ。このマシンで動作するBASICを開発したところから、ビル・ゲイツはキャリアをスタートした。BASICは（直接的にも間接的にも）たしかにコンピューティングを民主化した。
同じようなコンピューティングの民主化が、生成AIで起きようとしている……と俺は感じる。生成AIが起こすであろう世の中全体の変化から見れば、これはごくわずかな一端かもしれないけど。
さて、結論から書くと、クリーンアーキテクチャとフロントエンドの関係は以下です。
- クリーンアーキテクチャは、ソフトウェアの中で変わりやすく重要でない部分と変わりにくい重要な部分を、オブジェクト指向プログラミングの機能を使ってオニオン型のレイヤーで分けようというアプローチ
- クリーンアーキテクチャでは、フロントエンド（UI）やフレームワーク、Web、CLIといった外部と、ビジネスルールを表現する内部を分離、独立させることが重要と説いている
- モダンフロントエンドは、HTML/CSS/JS をセットにした小さいコンポーネントを組み合わせたUI管理のためのフレームワークを使って、単方向なデータフローでスケーラブルなアプリケーションを作るというアプローチ
両者を比較するだけでも、UI構築を主戦場とするフロントエンドにクリーンアーキテクチャを持ち込むという発想自体がナンセンスであることがわかります。
東京商工リサーチ（TSR）が2025年1月に発表した調査では、2024年におけるソフトウエア業の倒産数が223件と2015年以降、過去10年間の調査で最多となった。帝国データバンク（TDB）の調査でも倒産数が189件と、こちらも過去10年間の調査で最多だった。倒産企業の大半は中小規模の事業者という特徴があり、最も大きい倒産規模でも負債額は10億円未満だった。
倒産したソフトウエア業の中でも最も大きな割合を占めるのが、受託開発ソフトウエア業だ。TSRの調査で223件のうち209件、TDBの調査で189件のうち160件を占める。「（2024年の受託開発ソフトウエア業における倒産件数は）2023年調査との比較で約20％増加しており、増加率は高い」（帝国データバンクの旭海太郎情報統括部情報統括課副主任）。
贅沢言うなって言われそうだけど、僕が未経験やジュニアのエンジニアに求めるのは、前述した「具体と抽象を行き来する思考回路」を組み上げる工程に時間がかかることを知ったうえで、時には寝る時間を削ってコードを書くのも厭わない姿勢と踏ん張ってみようとしてくれるか。「このままでは終われんぞ！」っていう気持ちが、少しでも持てるかどうか。
一言で言えば、「もっとわかりたい」と思えるストイックさがあるかどうか。それが全くないなら、この領域は向いてない。この一コマがすごい好きです。
一部CTO達や技術系著者、関係する協会などは、
「開発者体験」「開発の不確実性」「事業へのコミットメント」といった、
今となっては私には不適切に思える言葉を多用する
なぜ不適切に思うか。後述するけど、要するに、過剰なあめ玉を開発者コミュニティに供給し続けたことになっていたと私はみているから
よかれと思ってやってきたのかもしれないけど、日本の開発者とビジネス側の分断、また開発者間の分断、そしてなにより効率低下を促進してしまったように思う
よく誤用される意味での「心理的安全性」をむやみに与えたように見える。不要なぬるま湯
企業を全体最適の視点から、そのビジネスプロセスとシステムを再設計するエンタープライズ・アーキテクト。エンタープライズ・アーキテクトは、データサイエンティストを抜き、今や、米国で人気トップの職業となっています（2022年、米国グラスドア調査による）。 ビジネスプロセスのアーキテクチャ設計の基盤となる概念構造化モデリング手法が「PRePモデル」です。
PReP（プレップ）モデルは、NAIST（奈良先端科学技術大学院大学）ソフトウェア設計学研究室で研究開発された、業務プロセス改善、サービス開発、システム要件定義など、多くのプロジェクトでその有効性が検証されている、プロセスの構造を分析し、設計するための方法です。
最近、SOLIDの原則について考えていて、その有用性に疑問を感じている。 SOLIDの原則は曖昧で、範囲が広すぎて、混乱を招き、場合によっては完全に間違っている。しかし、これらの原則の動機は正しい。問題は、ニュアンスの異なる概念を簡潔な文に落とし込もうとすることにあって、翻訳の過程で価値の大部分を失っているのだ。 これはプログラマーを間違った道へと導いてしまう（私にとっては確かにそうだった）。
私からのアドバイスだ： 単一責任について話すのをやめて、凝集性の話を始めよう。
NHKシステム開発・移行中断の件について
2025年02月7日
2025年2月4日、日本放送協会（以下、NHK）より、日本アイ・ビー・エム株式会社（以下、当社）に対し、営業基幹システムの開発・移行業務（以下、本プロジェクト）に関する業務委託契約の解除に伴う既払の代金の返還及び損害賠償を求める民事訴訟を東京地方裁判所に提起したこと、およびこれまでの経緯が公表されました。
当社は、本日時点において訴状を受領していないことから、NHKによる請求内容に関するコメントは差し控えますが、経緯に関する当社の見解についてご説明いたします。
本プロジェクトは、NHK指定の移行方針のもと営業基幹システムを新しい基盤へ移行するものであり、プロジェクト開始後に現行システムの解析を実施の上、移行方針及びスケジュール等を確定するという契約に沿って検討を進めてまいりました。
現行システムの解析を進める中で、提案時に取得した要求仕様書では把握できない、長年の利用の中で複雑に作り込まれた構造となっていることが判明したため、当社はNHKに対し、解析の進捗状況、課題およびそれに対する対応策を随時報告し、共にその対応を検討してまいりました。こうした中で当社は、同システムを利用する業務の重要性も鑑みて、NHK指定の移行方針による2027年3月までの安全かつ確実なシステム移行にはリスクを伴うことを伝えてまいりました。そして、2024年5月に、従来の納期のもとで品質を確保した履行は困難であることを報告し、取りうる選択肢とそれぞれの利点およびリスク等を提示いたしました。 NHKは、これをふまえて契約を解除することを決定されました。
当社は、これまでの解析・調査結果等をふまえて、より確実な移行方式の実現に向けた建設的な協議の開始について、2024年の夏以降、先月に至るまで幾度も申入れてまいりました。しかしながら、NHKは、協議の開始に応じることなく代金の返還と損害賠償請求を主張するにとどまり、この度当社に対し訴訟提起したことを公表されました。
こうした結論となり、当社としては大変残念ではありますが、当社は、これまでと変わらずNHKと協議の継続を希望します。
並行して、当社は訴状の内容も検討し、裁判のなかで当社のこれまでの対応と見解を主張してまいります。