Drupal 12 は 2026年12月7日の週にリリース予定で、Drupal 10 は 2026年12月9日にサポート終了を迎えます。どちらの日付も Drupal コアのリリーススケジュールという同じページに二行だけ離れて並んでいますが、Drupal 10 のサイトを動かしている人のほとんどはそのどちらにも気づいていません。新しいメジャーの最初のアルファは 2026年9月2日にタグ付けされているので、このリリースの姿はもう推測ではなく記録の問題です。 この衝突こそが話のすべてです。メジャーバージョンが出ること自体は、ふつうサイトの持ち主にとって緊急ではありません。エコシステムが追いつくまで一年か二年は前のメジャーに座っていられるか...
ソフトウェア開発
ソフトウェア開発に関する記事、ガイド、チュートリアル。開発者や企業向けの実践的な情報をまとめています。
Salesforce 連携がプロトコルで失敗することは、まずありません。認証は解決済みの問題ですし、レコードを 1 件登録するのも解決済みの問題です。プロジェクトを終わらせるのは、1 日あたりのリクエスト割り当てと、データモデルの形のほうです。しかもその両方は、たいてい本番稼働から三週間ほど経った頃、夜間ジョブがエラーを返しはじめ、なぜテストでは通っていたのか誰も説明できなくなった時点で発見されます。 パターンは予測できるほど一貫しています。開発者は Developer Edition 組織に対して実装し、すべて通り、顧客が検収します。そのコードがやがて出会うのは、マーケティング用コネクタと、データウェアハウスへの抽出処理...
WordPressのプラグイン開発は、たいてい同じ道をたどります。予約フォーム、フィードの取り込み、決済画面の追加項目が必要になり、開発者がそれを書き、動き、みんな次の仕事へ移ります。二年後、そのサイトは古いバージョンのWordPressに取り残されています。更新してもそのプラグインが無事でいられると誰も確信できず、書いた本人はもういないからです。 原因がコアの変化の速さにあることはまれです。WordPressは互換性を壊すことに保守的で、五年前に書かれた出来のよいプラグインの多くは、今もWordPress 7.1の上で手を入れずに動いています。プラグインが壊れるのは、最初の一週間で下された判断のせいです。機能をテーマに置いたこと、...
CMSの移行は、技術的な作業が完璧に進んでも結果が惨事になりうる、数少ない種類のプロジェクトです。サイトは予定どおり公開され、見た目もよくなり、表示も速くなる。それなのにトラフィックは半分に落ちます。数百本のアドレスが形を変えたのに、その対応表を誰も作らなかったからです。 失われたトラフィックの原因は、新しいプラットフォームではありません。原因は断絶です。以前は応答していたアドレスが応答しなくなり、識別できていたページが新しいページのように見えてしまい、古いアドレスにひもづいて何年もかけて積み上がってきた履歴が、行き場を失います。しかも順位はある日いきなり落ちるのではなく、数週間かけて静かに沈んでいくため、公開当日に問題がないように...
ポストモーテムは、開くのは簡単で、役に立つものにするのは難しい会議です。会議が開かれ、ドキュメントが書かれ、アクションアイテムが四つ記録され、そして六か月後に同じ障害がふたたび起きます。そのころ誰かが、まったく別のものを探している最中に、あの古いドキュメントを見つけることになります。 この話題では「非難なし」という言葉にほとんどの注目が集まります。その原則は実際に重要なのですが、失敗が起きているのはそこではありません。非難なしを厳格に守りながら、それでも何ひとつ変わらないレビューを回している組織はいくらでもあります。理由は単純で、レビューそのものを成果物として扱ってしまい、成果物を生み出すための手段として扱わなかったからです。 あな...
パスワードの保存は、ソフトウェアの世界で「本当に正しい答え」が存在する数少ない領域のひとつです。その答えはすでに公開されていて、継続的に更新されていて、しかも無料で読めます。それにもかかわらず、これほど繰り返し間違えられている領域も珍しくありません。理由は単純で、いま間違いとされている答えのほとんどが、かつてはたしかに正しかったからです。そして正しかった時期を過ぎたあとも、誰もその判断を見直しませんでした。 失敗の中身が奇抜であることは、まずありません。2012年に妥当だった助言に沿って2016年に組まれた仕組みが、いまも動き続け、いまもログインを受け付けている。それだけの話です。そのハッシュ処理を書いた本人が会社を去って以来、誰も...
ソフトウェアサプライチェーンのセキュリティは、専任のセキュリティ部門を持つ大きな組織の課題のように聞こえます。しかし、その捉え方こそが誤解のもとです。いくつかのサービスを運用しているだけの小さなチームでも、実際には誰も中身を読んだことのない数百のパッケージに依存しています。それらはビルドのたびに、自分たちが管理していないレジストリから取得され、デプロイ用の認証情報が置かれているマシンの上でインストールスクリプトを実行します。 危険にさらされる度合いは、会社の規模には比例しません。依存パッケージの数と、ビルドがどこまで自動化されているかに比例します。そして小さなチームほど、前者は多く抱えている一方で、後者に目を光らせる人は少ない、とい...
技術ドキュメントは、いつも決まった、そして予測のつくかたちで失敗します。誰かが二週間ほどの落ち着いた時期に大量に書き上げ、そのあいだにシステムのほうが変わり、誰も更新せず、一年も経てば、その文書は自信たっぷりに間違ったことを述べている状態になります。そこから先は、何もないよりも悪い状態です。書いてあることを信じた読み手が、すでに成り立たなくなった情報にもとづいて手を動かしてしまうからです。 これに対するよくある反応は、もっと書こうという号令です。ところがそれは同じ失敗を早めるだけで終わります。役に立つ反応は、書く量を減らし、そのうえで何を書くのかを選ぶことです。ここでの制約は書く手間ではありません。書いたあとに保守し続ける手間のほう...
開発者のオンボーディングは、たいてい入社手続きや研修が何日で終わったかで測られます。しかしそれは、問題の逆側の端を見ています。本当に意味のある数字は別のところにあります。新しく入ったエンジニアが何かを変更し、そのうえで他のどこも壊していないと自信を持って言えるようになるまでに、どれだけの時間がかかるか。多くのチームでこの数字は、日数ではなく月数で測られてしまっています。 その遅れの原因が本人にあることは、めったにありません。原因は、システムのうちどれだけの部分が他人の頭の中にしか存在していないか、そして最初の二週間のうちどれだけの時間が、それを一回の割り込みごとに少しずつ引き出す作業に費やされるか、という点にあります。 追いかける価...
ソフトウェアエスクローは、日本語ではソースコード預託とも呼ばれ、もっともな不安に答えるために存在します。基幹システムを構築し運用してきたベンダーが事業をたたみ、こちらの手元には、依存しているのに保守できないものだけが残る、という不安です。エスクロー契約はソースコードを中立的な第三者に預けておき、実際にそうなったときにその第三者が利用者へ開示します。 不安そのものは正当です。ところがこの仕組みは誤解されやすく、その隔たりから、毎年費用だけがかかり、いざ必要になった日には役に立たない契約が生まれます。 署名の前に確かめておきたい、居心地の悪い問い: もし明日ソースコードが開示されたとして、社内の誰かがそれを実際に動かせるでしょうか。ビル...