他の職人と同じように、私も道具を大切にしています。道具がなければ仕事ができないからです。しかし、大工や配管工とは違い、私の道具は絶えず変化するため、新しいバージョンが出るたびに評価しなければならないという、うらやましくない立場に置かれています。残念ながら、それは不可能です。仕事を終わらせなければならないのですから、主要アプリケーションの新しいバージョンが出るたびにテストスイートを実行する必要はありません。短期的にはアップグレードを拒否することも常に選択肢の一つですが、特に新機能やバグ修正が重要な場合は、いつまでも先延ばしにすることはできません。
これは、Pages 4.3 が EPUB エクスポートをどのように変更したか、そして BBEdit 10.5 が Automator の重要なアクションをどのように壊したかという、2 つの問題のあるアップデートに関する話です。さらに言えば、これは Apple と Bare Bones Software という全く異なる 2 つの企業が顧客をどのように扱っているかという話です。
Pages 4.3 に何時間も費やす— すべては、Kirk McElhearn の「Take Control of iTunes 11: The FAQ」を出版する時期が来た時に始まりました。現在、私たちは Take Control 電子書籍の執筆、編集、制作に Pages を頼りにしています。Pages は多くの点で優れており、私たちはその欠点や長年のバグを回避することができました (「Take Control が Pages で EPUB を作成する方法」2011 年 9 月 30 日、および「Word から Pages への移行戦略」2012 年 1 月 18 日を参照)。
マイケル・コーエンがカークの電子書籍のEPUBファイルのエクスポートを始めたとき、予想外の問題に遭遇しました。様々なボタンのインライングラフィックが大きすぎて、正しい位置に表示されないことがしばしばありました。特にiBooksではひどかったのです。控えめに言っても、これは予想外でした。PagesからEPUBをエクスポートするのはかなり前からやっていましたが、このようなことは初めてでした。
マイケルとトーニャは、当初問題がファイルの破損によるものかどうかを突き止めるのに数時間を費やしましたが、様々なテストを進めていくうちに、新しいファイルでも問題が発生していることに気づきました。さらに数時間の作業の後、マイケルは問題の一部を特定しました。2012年12月中旬にリリースされたPages 4.3では、EPUBコードにおけるグラフィックの処理方法が変更されたのです。以前はPagesはSPAN要素を使用していましたが、4.3ではAppleは、、、にCSSスタイルを直接適用したDIV要素に切り替えdisplay:inline-block;ましvertical-align:baseline;たwidth。
翌日、Tonyaと私はEPUBのコードとBBEditに向かい合い、テキストファクトリーでgrepを使ってDIVをSPANに変換する方法を考え出しました。（BBEditはEPUBを展開せずに編集できますが、展開せずにEPUB内のすべてのファイルを検索することはできません。）それほど難しくはありませんでしたが、結果は信頼できるものではありませんでした。そこで、Pages 4.3は単に異なるEPUBコードを書き込んでいるだけでなく、以前のバージョンとは異なるグラフィックをエクスポートしていることに気付きました。
問題はこうです。Pages は優れたグラフィックツールを備えた WYSIWYG アプリなので、グラフィックをインポートした後、最適なビジュアルレイアウトを実現するためにサイズを変更することがあります。以前のバージョンの Pages では、EPUB 用のグラフィックは（当然のことながら）サイズ変更後のサイズでエクスポートされていましたが、Pages 4.3 ではインポート時のサイズでグラフィックをエクスポートし、widthDIV スタイルの属性を使用してサイズを変更しようとします。これが可能かどうかは私には完全にはわかりませんが、いずれにせよ Pages 4.3 はこれを間違って行っており、インライングラフィックが大きすぎる状態になっていたのはそのためです（そしてもちろん、私は Apple にバグを報告しました）。もしこれがうまく機能するのであれば、このアプローチは本質的に悪いアイデアではありません。なぜなら、
理論的には EPUB 読み取り環境の他の変数に基づいてグラフィックのサイズを変更できるからです。欠点としては、結果として得られる EPUB のサイズも、グラフィックが大きくなったため、3 MB ではなく約 18 MB と大幅に大きくなってしまったことです。
いずれにせよ、私たちは困っていました。EPUBコードを変更することはできても、問題となるグラフィック部分を簡単に特定したり修正したりすることができなかったのです。この時点でPages 4.2では問題が発生しないことはわかっていましたが、私たちが利用できるMacの中で、そのバージョンがまだインストールされていたのはたった1台、TonyaのMacBook Airだけでした。他にも、まだPages 4.1が動作している古いMacが数台（TristanのMacBookとMichaelが以前使っていたiMac）ありましたが、Pages 4.3がリリースされた2012年12月に、制作用のマシンはすべてPages 4.3にアップグレード済みでした。
「制作プロセスの重要な部分で、どうしてそんなに不注意だったんだ？」と疑問に思うかもしれません。あらゆるアップグレードでテストスイートを実行するのは現実的ではないと言ったことを覚えていますか？ さて、私たちは愚かにも、AppleのPages 4.3（iWork 9.3アップデートの一部）のリリースノートをそのまま信じてしまいました。その内容は、以下の通りです。
iWork アップデート 9.3 では、iOS 1.7 アプリ用の iWork のサポートが追加されました。
たった1行しかないので、行間を読んで他の変更があったと推測することすらできません！そして、少なくとももう1行あるはずだと推測できる人は誰もいません。
EPUB エクスポートでグラフィックを処理する方法を変更します。
ということで、全員アップグレードしました。今度はPages 4.2にダウングレードしたかったのですが（iOS版iWork 1.7のサポートは私たちにとって重要ではありません）、Time Machineからの復元はうまくいきませんでした。12月初旬に復活したPages 4.2はファイルを保存できず、試すたびにクラッシュしてしまうのです。
iWork '09 DVDからPagesを再インストールし、バージョン4.2へのアップグレードを試みましたが、これも同様に失敗しました。この方法の方が可能性は高かったかもしれませんが、Appleは原因不明で全く役に立たない理由で、Pagesをバージョン4.2にアップグレードするiWork 9.2アップデートを削除してしまいました。（なぜ？ユーザーが将来やりたいことをなぜ阻止しようとするのでしょうか？）この方法を使ってiWork 9.1アップデートでPagesをバージョン4.1にアップグレードすることはできましたが、Time Machineで復元したバージョン4.2と同様に、この方法で復元したPages 4.1にも保存の問題が発生しました。
途方に暮れた私は、技術に詳しい友人たちのプライベートメーリングリストに投稿しました。すると、ある人が最終的な解決策を提案してくれたので、大変嬉しくなりました。Time Pages.appMachineからパッケージだけでなく、/Library/Application Support/iWork ’09iWorkアプリで共有されているフレームワークが多数含まれているフォルダも復元するというのです。サポートファイルの不一致が問題を引き起こす可能性が高いと思われたので、KeynoteとNumbersの以前のバージョンも復元しました。
正確な記録は取っていませんが、AppleがPages 4.3にひそかに変更を加えたことで、10～15人分の作業時間が失われたと推定します。もし全員に時間給が支払われていたとしたら、元の状態に戻すだけで500～1,000ドルもの無駄な費用がかかったことになります。しかも、Appleがリリースノートでこれほど重大な変更について言及しなかったことが、すべて無駄になったのです。
これはAppleの顧客に対する深刻な無礼さを示すものであり、特にプロフェッショナルが使用するツールに関しては、その態度は甚だしい。iTunes 11の大幅な変更（iTunes 10.7へのダウングレード不可）など、Appleが一般ユーザーに深刻な頭痛の種を突きつけるだけでも十分に問題だ（「iTunes 11：Appleが削除した機能と代替手段」2012年12月4日記事参照）。しかし、Appleの変更点を隠蔽するという決定が生活の危機に瀕している今こそ、顧客を大切にする企業のツールを見直すべき時だ。
BBEdit 10.5 が Automator ワークフローを壊して修復— そういう会社は確かに存在します。Pages での私の経験とは対照的に、先週、BBEdit 10.5 へのアップグレードで問題が発生した時の話をしましょう。Bare Bones Software の透明性と顧客への配慮によって、いかに迅速に問題が解決されたか。
BBEditにはAutomatorアクションがいくつか付属していますが、私にとって最も興味深いのは「検索と置換」アクションです。grepをサポートしているため、Automatorでは通常不可能なファイル名のテキスト操作をはるかに効率的に実行できるからです。完成したTake Control電子書籍を配布するために、複雑なAutomatorワークフローを作成しましたが、「Take Control of iTunes 11: The FAQ」で配布しようとしたところ、ファイル名が正しく変更されなかったためにワークフローが失敗しました。ワークフローをステップ実行していくうちに、BBEditの検索と置換アクションに問題があることが分かりました。そこで、「BBEdit 10.5 検索と置換 Automator
アクション」でGoogle検索してみました。
2 番目の結果は、このバグを解決した BBEdit 10.5.2 のプレリリース ビルドのリリース ノートでした。
[257587] 「Grep を使用する」がアクションのオプションでオンになっていると、「検索と置換」Automator アクションが誤動作を起こすバグを修正しました。
完璧です！Bare BonesがBBEdit Talkメーリングリストで公開しているBBEdit 10.5.2の最新プレリリースビルドをダウンロードしてインストールしたところ、20分後には作業が再開できました。修正プログラムを探すのに20分も費やしたくなかったのですが、バグは起こるものです。最も重要なのは、開発者が問題をどのように認識し、対処するかです。簡単に言うと、変更点について透明性を保ち、プレリリースビルドを公開することで、Bare BonesはBBEditを使って仕事をこなせるよう、本当に気を配ってくれていると感じました。
ここでの違いは、Bare Bones が数万、あるいは数十万のユーザーを抱える小規模企業であるのに対し、Apple が数百万人のユーザーを抱える巨大多国籍企業であるという点にある、とよく言われます。私は Apple の姿勢に全く共感できません。1370億ドルの現金を保有する Apple のような企業が、顧客を支援するシステムの構築や行動を怠るわけにはいきません。Apple が Pages 4.3 の完全なリリースノートを公開していれば、この状況は避けられたはずです。また、ダウングレードを望む正当な理由があることを認め、手順書や旧バージョンを公開していれば、復旧もはるかに容易だったでしょう。
こうした行為は Apple にとって目新しいことではない。だが、プロユーザーですら技術的な詳細を知る必要はないという同社の言い分は、物事がきちんと動かないと崩れ去り、Apple のソフトウェアは iOS 6 から Pages 4.3 に至るまで、ますます機能不全に陥っている。ハードウェアは素晴らしいのに、ソフトウェアはますますずさんになっている。Apple は自社製品の問題を決して認めようとしない。これはマーケティングレベルでは全く問題ないが、サポートレベルでは全く受け入れられない。だからこそ、ティム・クックが iOS 6 のマップの問題について謝罪したことは注目された。あれはマーケティングだったのだ。しかし、Apple のサポートページにリリースノートが掲載されているのだろうか? リリースノートを読むのはソフトウェアの変更点に関心のある人だけだ。これらは
サポート文書であってマーケティング資料ではない。バグを認めず、根本的な変更を認めないということは、Apple 製品に依存する私たちと、私たちの仕事に対する Apple の敬意の欠如を露呈している。
近い将来、Macから乗り換えたり、Pagesを廃止したりするなど、大それたことを言うつもりはありません。目標は仕事をこなすことであり、そのためには今持っている使い慣れたツールを使うのが一番です。とはいえ、まるでチャーリー・ブラウンとフットボールのようで、Appleがルーシー役を演じているような気分です。ですから、新しいソフトウェアツールを探す時期が来たら、私からボールを奪い取らないような企業を探すつもりです。