三日間を、最初の四秒で判断されるスライドを作成するのに費やすのは長すぎます。だから、上司が通勤中やコーヒータイムにスマホでファイルを開いたとき、テキストボックスが形から半分以上ずれていたら、それは技術的なバグに思えます。でも、そうではありません。また、より良い「デザイン」をすれば防げる問題でもありません。実際の問題は、あなたの画面上で起きているのではなく、彼らの端末で、あなたが開いたことのないソフトウェア上で起きているからです。 --- **上司が見たファイルはPowerPointでもKeynoteでもなかった** 「プレゼンテーションデザインのコツ」のほとんどの記事で省かれている部分があります：スマホで.pptxや.keyファイルをタップすると（メール、Slack、WhatsApp、またはファイルアプリからでも）、スマホはほとんどの場合、フルのプレゼンテーションソフトウェアを起動せずにプレビュー表示を行います。iPhoneでは、Apple自身のQuick Lookフレームワークのドキュメントによると、Microsoft OfficeドキュメントやiWorkファイルを含む複数の形式をプレビュー表示でき、独自の軽量ジェネレーターを使って実際のPowerPointやKeynoteのレンダリングエンジンではなく、簡易的なスライドの概要（テキスト、形状、基本的なレイアウト）を表示します。このジェネレーターは、埋め込みフォント、精密な行間、重ね合わせオブジェクト、アニメーションなど、より複雑な要素を静かに無視したり再解釈したりします。 だから、上司が「開いた」プレゼンテーションはPowerPointによって拒否されたのではありません。スピードよりも精度を重視していないプレビューツールによって描かれ、そのツールは一度もあなたのカスタムテンプレートを見たことがなかったのです。同じ失敗パターンは、古くなった会議室のプロジェクターでも発生します — コンテンツは変わらないが、あなたがデザインしたものとは異なるレンダリング能力を持つものが表示しているため、どこで切り捨てられるかを警告することはありません。 --- **なぜ特にテキストが崩れるのか** スライド上のテキストボックスは最も脆弱なオブジェクトです。ほとんどの場合、背後で静かに計算を行っています。Microsoft自身のAutoFitに関するサポートドキュメントは、デフォルトでプレイスホルダーが「**形状をテキストに合わせてリサイズ**」または「**オーバーフロー時のテキストを縮小**」に設定されていることを確認しています。つまり、あなたが特定のサイズで作成したボックスは固定されていないのです。それは、その場で実際に利用可能なフォントに基づいて再計算される式です。レンダラーを変更すると、その式の入力を変更することになります。 フォントの置き換えは、ほとんどの人が気づかないほどこの問題を悪化させます。ソフトウェアは置き換えが行われていることを警告しません。PowerPointの専門家によるトラブルシューティングスレッドやMicrosoft自身のコミュニティフォーラムでは、同じパターンが繰り返し記載されています：ファイルを開くソフトウェアに元のフォントが利用できない場合、ソフトウェアは静かに似たフォントに置き換え、元のフォント名を報告するだけです。そのため、インターフェース上で置き換えが行われたかどうかはわかりません。わずかに幅の異なる置き換えフォントでも、見出しが一行から二行に変わることがあり、その下のすべてのボックスが補償して移動することになります。 これが、テキストを強制的に縮小させてフィットさせるのが最初から間違った反射行為である理由です — あなたのマシンで既に限界ギリギリのボックスは、スマホのプレビューレンダラーが独自の置き換え計算を行う際、ゼロの余裕を残すことになります。 --- **アスペクト比は、人が思うほど問題ではない** スマホの縦画面を直接責めるのは誘惑に耐えがたいですが、実際にはほとんどの場合、16:9のスライドが狭い縦画面に収まらないために崩れるわけではありません。Quick LookやOfficeのモバイルビューアーは、写真のようにスライド全体を縮小表示するだけで、再配置を行うことはありません。スライドは小さくなりますが、歪むことはありません。実際に崩れるのは、縮小表示前にすでに緊密な内部スペースです。あなたのラップトップ上でチャートの端から2ピクセル上に配置されたキャプションは、スライド全体が縮小されると、内部の要素が独立して再計算されるため、余裕がなくなります。 --- **再度ファイルを開くよりも時間のかからないチェック** これらのことがすべて、送信前に実際のスマホでテストを行うことを意味するわけではありません — デッドライン中に現実的ではありません。現実的な方法は、重要なファイルを送信する前に、PDFバージョンを並行してエクスポートすることです。PDFは、テキストボックス、フォントの置き換え決定、スペースの選択を、エクスポート時の状態に完全に固定します — プレビューレンダラーが誤って再計算する余地はなく、生のテキストが再配置されることもありません。もし、スマホで開く可能性のある相手に送るのであれば（特にインボックスやチャットスレッドに送られるものであれば、スケジュールされた会議招待とは違い、ほぼ50%の確率でスマホで開かれるでしょう）、そのPDFが実際に届く形になっているのです。 二つ目のチェックは、意外と安価です：ファイルを送信する前に、一度自分のスマホで開いてみるだけです。完璧を求めるわけではありません — 見出しが二行に折り返されるか、画像がキャプションと重なるかどうかを確認するだけです。これは約3秒で判断でき、プレゼンテーションにPDFのバックアップが必要かどうかを教えてくれます。 --- **三日間の作業が本来行うべきこと** この失敗モード全体の最も腹立たしい部分は、これらの問題がすべてデザインのミスではなかったということです。パレットは問題なく、階層も問題なく、コンテンツも問題なく — 三日間を、スマホのプレビューレンダラーが決してそのような観点から評価しないような決定に費やしました。これは、レンダラーやデバイスを超えてテスト済みの構造からプレゼンテーションを始めるべき理由の一つです。つまり、緊急でデッドライン圧力の中で、すべてのテキストボックスのスペース許容をゼロから作成するのではなく — プレゼンテーションプロジェクトのほとんどの時間は、このような目に見えないフォーマット作業に費やされ、誰もが覚えているような部分には費やされていないのです。 次のプレゼンテーションを送信する前に、PDFをエクスポートし、自分のスマホで3秒ほど確認してから、両方のファイルを送信してください。あなたが行ったデザイン作業は問題ありません。ただ、上司の親指が届くバージョンが、あなたが実際に作成したものであることを確認するだけです。