Drupal Commerce は、ほとんどのオンラインショップにとって間違った答えです。これは 15 年にわたり丁寧に設計されてきたプロジェクトへの批判ではありません。大半のショップがどういうものかを述べているだけです。数百点の SKU、単一の通貨、消費者である顧客、そして最後にカード決済。この形の事業であれば、重要な軸のすべてでホスティング型プラットフォームが勝ち、議論は始まる前に終わります。 しかし、計算が完全に逆転する少数派が存在し、それは収益性の高い少数派です。バリエーションの表では表現できない構成型の製品。交渉済みの価格表を持つ取引先アカウント。カタログそのものが編集コンテンツであるサイト。在庫と価格を所有し、ウェブサイ...
英国ビジネス
英国ビジネスに関する記事、ガイド、チュートリアル。開発者や企業向けの実践的な情報をまとめています。
Drupal 12 は 2026年12月7日の週にリリース予定で、Drupal 10 は 2026年12月9日にサポート終了を迎えます。どちらの日付も Drupal コアのリリーススケジュールという同じページに二行だけ離れて並んでいますが、Drupal 10 のサイトを動かしている人のほとんどはそのどちらにも気づいていません。新しいメジャーの最初のアルファは 2026年9月2日にタグ付けされているので、このリリースの姿はもう推測ではなく記録の問題です。 この衝突こそが話のすべてです。メジャーバージョンが出ること自体は、ふつうサイトの持ち主にとって緊急ではありません。エコシステムが追いつくまで一年か二年は前のメジャーに座っていられるか...
「Drupal は遅い」という評判の出どころは、ほとんどがホスティングです。そしてそれは、ソフトウェアの問題というより購買の判断の問題です。サイトはきちんと作られ、そのあと PHP ファイルが数本あるだけの会社案内サイト向けに値付けされたプランの上で公開されます。結果として、本格的なレンダリングパイプラインを持つコンテンツ管理システムが、自分では変更できないメモリ上限のなかで、自分では制御できないオペコードキャッシュの上を、自前のツールを走らせるシェルも持たないまま動くことになります。 人が頭のなかで比べている相手は WordPress ですが、その比較は的外れです。WordPress がほとんど何の上でもそれなりに動くのは、その市...
開発者のオンボーディングは、たいてい入社手続きや研修が何日で終わったかで測られます。しかしそれは、問題の逆側の端を見ています。本当に意味のある数字は別のところにあります。新しく入ったエンジニアが何かを変更し、そのうえで他のどこも壊していないと自信を持って言えるようになるまでに、どれだけの時間がかかるか。多くのチームでこの数字は、日数ではなく月数で測られてしまっています。 その遅れの原因が本人にあることは、めったにありません。原因は、システムのうちどれだけの部分が他人の頭の中にしか存在していないか、そして最初の二週間のうちどれだけの時間が、それを一回の割り込みごとに少しずつ引き出す作業に費やされるか、という点にあります。 追いかける価...
稼働率SLAは約束のように見えて、実際には返金規定のように振る舞います。提供側はそれを知っています。契約する側は知らないことが多く、可用性を買ったつもりでサービスレベル契約に署名しますが、実際に買っているのは、可用性が得られなかったときに受け取れるわずかな割引です。 それが必ずしも悪い取引だというわけではありません。ただ、多くの人が結んでいるつもりの取引とは別の取引であり、その違いはシステムが止まって、契約には何と書いてあるのかと誰かが尋ねた瞬間に効いてきます。 スリーナインは完璧に近く聞こえますが、月に43分の停止を許容します。 フォーナインが許容するのは4分です。平日の午後に43分の障害を吸収できる事業なら、99.9%で十分であ...
ソフトウェアエスクローは、日本語ではソースコード預託とも呼ばれ、もっともな不安に答えるために存在します。基幹システムを構築し運用してきたベンダーが事業をたたみ、こちらの手元には、依存しているのに保守できないものだけが残る、という不安です。エスクロー契約はソースコードを中立的な第三者に預けておき、実際にそうなったときにその第三者が利用者へ開示します。 不安そのものは正当です。ところがこの仕組みは誤解されやすく、その隔たりから、毎年費用だけがかかり、いざ必要になった日には役に立たない契約が生まれます。 署名の前に確かめておきたい、居心地の悪い問い: もし明日ソースコードが開示されたとして、社内の誰かがそれを実際に動かせるでしょうか。ビル...
請負契約と準委任契約、つまり固定価格で請けるか、かかった時間で精算するかという選択は、たいていリスクをめぐる選択として説明されます。その説明そのものは正しいのですが、直後に扱いを誤ります。発注側も受注側も、リスクは移動するだけであることを忘れ、どちらかを選べばリスクが消えると思い込んでしまうからです。 リスクは消えません。請負契約では、見積もりが外れるリスクをベンダーが背負い、そのリスク分を提示する金額の中に織り込みます。準委任契約では、同じリスクを発注者が背負います。問われているのは、どちらの契約形態が不確実性を消してくれるかではありません。どちらの当事者がその不確実性を扱いやすい立場にいるのか、そして移転の対価を払う価値があるの...
小規模なチームにおける災害復旧は、たいていの場合、誰も開いたことのないドキュメントの中の一行で終わっています。バックアップは有効になっています、という一文です。その記述自体は事実ですが、何かの答えになっているわけではありません。実際に障害が起きたときに戻ってくるデータがどれだけ古いものなのか、復元にどれくらいの時間がかかるのか、そしてこれまでに誰か一人でも最後まで復元をやり切ったことがあるのか、そのどれについても何ひとつ語っていないからです。 バックアップを持っているという状態と、実際に復旧できるという状態のあいだには、はっきりとした隔たりがあります。ほとんどの障害が本格的なインシデントへ変わるのは、まさにその隔たりの中でのことで...
ソフトウェアの提案依頼書、いわゆるRFPは、本来、複数の発注先候補を横並びで比較できるようにするための文書です。ところが実際に出回っているものの多くは、その逆の結果を生んでいます。解決策を細かく指定しすぎて回答の幅を縛る一方で、金額を出すために誰もが必要とする情報のほうは抜け落ちているからです。結果として、桁が一つ違うほど開いた五つの見積もりが並び、どれも形式上は要求に答えているのに、同じものを測っている見積もりは一つもない、という状態になります。 よくある説明は、ベンダーが言葉を濁しているというものです。それが当たっている場合もたしかにあります。しかし圧倒的に多いのは、その文書に書かれている内容からは導きようのない数字を求めてしま...
ソフトウェア保守費用は、成功したはずのプロジェクトを十八か月後に気まずい話し合いへと変えてしまう数字です。開発そのものは予算が組まれ、承認され、無事に納品されました。ところが本番稼働のあとに起きることは「サポート」という一言でまとめられ、誰かが勘で置いた金額があてがわれます。そしてその金額は、ほとんどの場合あまりにも小さすぎました。 理由は不注意ではなく、構造にあります。開発には値段をつけられる範囲があります。保守には範囲がありません。まだ起きていない出来事によって中身が決まるからです。脆弱性が見つかるライブラリ、取引先が変更するアプリケーション連携の仕様、誰も想定しなかった状況に行き当たる利用者。そういったものが保守の中身を決めて...