macOSをアップグレードする際は30GB〜40GBぐらい容量を空けておいた方が安心ですよ、という話

はじめに：インストーラに騙された！？

我が家には仕事用のMacBook Proと家族用のMacBook Pro（以下MBP）があります。
仕事用のMBPがトラブると、文字通り仕事にならないので、まずは実験的に家族用のMBPをmacOS Catalinaにアップグレードしてみることにしました。

Catalinaのダウンロードが終わり、アップグレードを進めようとすると、インストール先のディスクを選択する画面で「空き容量が足りません」というメッセージが標示されました。
「たしかに空き容量が少ないよな。さすがにもうちょっと増やさないとダメか」と思い、「空き容量が足りません」メッセージが出なくなるまでストレージの空き容量を増やしました。
そして、メッセージが出なくなったところでインストールを開始。
これでしばらく待てばCatalinaにアップグレードされるはず・・・と思いきや！！

こんなメッセージが出てインストールが途中で止まってしまいました！！

コンピュータにmacOSをインストールできませんでした
　

Macintosh HDにはインストールに必要な空き領域がありません
インストーラを終了してコンピュータを再起動してからやり直してください。

なんでやねん〜！！さっきお前が「これでOK」っていうところまで空き容量を増やしたやんけー！！と心の中で絶叫しましたが、そんなことを言っても仕方ありません。

画面に再起動ボタンが出ているので、これをクリックすればアップデート前の状態に戻ってファイルが削除できるようになるんだろう・・・と思いきや、再び同じメッセージが！！

コンピュータにmacOSをインストールできませんでした
　

Macintosh HDにはインストールに必要な空き領域がありません
インストーラを終了してコンピュータを再起動してからやり直してください。

おいおい、こんなことしてたら永遠の無限ループじゃないですか😱

で、ここから約6時間にわたる試行錯誤の旅が始まるのですが、いったんその過程はすっ飛ばして「こうすれば一番速かった」という結論を書いておきます。

一番速い解決策

この解決策は事前にTimeMachineでバックアップを取ってあることが前提条件となります。
具体的な手順は以下のとおりです。

Macを復元する（元のmacOSに戻す）

まず、Macを「macOS 復元システム」から起動します。
再起動ボタンをクリックしてマシンがシャットダウンしたら、すぐにCommand + Rボタンを押します。
すると、「macOSユーティリティ」の画面が立ち上がるので、そこから「TimeMachineバックアップから復元」を選びます。

参考 macOS 復元について - Apple サポート

運が良ければMac本体に保存されている「ローカルスナップショット」からMacを復元できます。
ローカルスナップショットを使えば、5分から10分程度の時間でMacをアップグレード前のMojaveに戻すことができます。

参考 Time Machine のローカルスナップショットについて - Apple サポート

空き容量を増やす（注意点あり）

普通にMacが起動すれば、あとはファイルを削除して空き容量を増やすだけ・・・なのですが、いくつか注意点があります。

まず、Catalinaは「空き容量が最低8GBあればインストール可能」らしいのですが（Appleサポート談）、「30GB〜40GBぐらい空けておいた方が安心」だそうです（これもAppleサポート談）。

さらに、念のため気を付けた方がいいのが、「パージ可能」という表示です。
ディスクユーティリティというツールでストレージの空き容量を確認してみてください。
画面上部に表示されている横バーグラフの「空き」という表示が30GB〜40GB以上になっている方が望ましいです。

画面下部の「利用可能」という項目を見たときに、もし「30.22GB（20.46GBパージ可能）」というような表示になっていたら、それは実質10GB程度しか空き容量がありません。

下の図はディスクユーティリティの表示例です。

参考情報：パージ可能な容量だけを増やしても意味がない！？

僕は試行錯誤の過程で、ターゲットディスクモードを使って仕事用のMBPからエラーが出て起動しなくなったMBPのストレージにアクセスし、不要なファイルを20GBほど削除しました。
ですが、「パージ可能」の容量が増えただけで、「空き」には変化が現れず、Macを再起動しても相変わらずインストーラの「空き領域がありません」エラーが出続けました（ちなみにそのときの状況はディスクユーティリティ上の「空き」が11GB程度でした）。

このことから、「パージ可能な領域」をどれだけ増やしても、インストーラの「空き容量が足りません」エラーは解消しないんじゃないかと推測しています。

「パージ可能な領域」を削除して「空き」を増やす方法（やや難）

しかし、この「パージ可能な領域」を削除するのは結構難易度が高いです。
僕は以下のページに載っている手順に従って、なんとかパージ可能な領域を減らすことができました。

How to Reclaim Purgeable Space on Mac - Bambielli’s Blog

ターミナルの操作に慣れている人でないと自信をもって作業できないと思うので、「ようわからん」という人はとりあえず「利用可能」の容量を可能な限り増やしてCatalinaのインストールに再チャレンジしてみましょう。
もしかしたら、それでもうまくいくかもしれません。

「空き」を十分確保したら、アップグレードに成功した

僕は上記の表示例のように、約72GBの「空き」を作ってからCatalinaを再インストールしました。
これだとエラーが出ることなく、スムーズにCatalinaをインストールすることができました。

この表示を見るまで、約6時間かかりました・・・（くたびれた〜）

参考情報：空き容量を増やすための便利アイテム

「空き容量を増やしましょう」といっても、状況によっては削除できるファイルには限界があると思います。
そういう場合は一時的に外部ハードディスクにデータを避難してから、Mac本体のデータを削除しましょう。
macOSのアップグレードが終わったら、外部ハードディスクからMac本体にデータを戻せばOKです。

僕も外部ハードディスクを持っていたので、これに一時的にデータを避難させました。
1TBでも7000円前後、大きさもiPhoneぐらいのコンパクトサイズなので、何かあったときのために1台持っておくと便利です。

I-O DATA HDD ポータブルハードディスク 1TB USB3.0バスパワー対応 日本製 EC-PHU3W1

試行錯誤のあれこれ

上の解決策は「一番の最短ルート」ですが、その解決策に至るまではかなり試行錯誤しました。
僕が試してもダメだった方法を以下に紹介します。

🙅🏻‍♀️Startup Managerを使ってMacintosh HDを選択する

Macが再起動するタイミングでOptionキーを押し続けると、Startup Managerが立ち上がります。
ここで、MBP本体のMacintosh HDを選択すると、アップグレード前のmacOSに戻れる・・・というWeb記事があったのですが、僕の場合は選択直後に「🚫」みたいなマークが出て、そこからMacを起動することができませんでした。

参考 別の起動ディスクを選択する方法 - Apple サポート

🙅🏻‍♀️ターゲットディスクモードで別のMacから不要なデータを削除する

起動しない方のMBPをTボタンを押しながら起動させると、ターゲットディスクモードになります。
この状態でMBP同士をThunderbolt対応のUSB-Cケーブルで接続すると、正常なMBPから起動しないMBPのストレージの内容を読み書きできるようになります。

ここで注意しなければならないのは「Thunderbolt対応のUSB-Cケーブル」という点です。
MBPとACアダプタを繋ぐ白いUSB-CケーブルはThunderbolt対応ではないので、接続しても外部ディスクとして認識されません。
僕はたまたまUSB-C接続できる外部モニタを持っていたので、このモニタのUSB-Cケーブルを「Thunderbolt対応のUSB-Cケーブル」として利用することができました。

EIZO FlexScan 27.0インチ ディスプレイモニター (4K UHD/IPSパネル/ノングレア/ブラック/USB Type-C搭載/5年間保証&無輝点保証) EV2785-BK

ただし、ターゲットディスクモードで接続してもFinderからは多くのディレクトリがアクセス不可になっています。
このため、ファイルの確認やコピー、削除といった作業はターミナルから操作する必要がありました。

参考 ターミナルから外付けHDDとかの外部にアクセスしてみる - 悲喜交々 -へたれの技術メモ置き場-

が、前述の通り、この方法でファイルを削除してもディスクユーティリティ上の「空き」容量が変わらず、結局徒労に終わりました。

ターゲットディスクモードで頑張って2台のMBPを接続する様子（でもダメだった😫）

🙅🏻‍♀️ターゲットディスクモードで動かないMacを起動ディスクとして選択する

これはAppleサポートの人に教えてもらった方法です。
上で書いたようにターゲットディスクモードでMBP同士をつないでおき、正常に動いている方のMacからシステム環境設定の「起動ディスク」を選択、そこから動かないMacのハードディスクを選択して・・・という手順を教えてもらったのですが、そもそも動かない方のMacのハードディスクが一覧に表示されず、そこから何もできずに終わりました。
Appleのサポートの人も「うーん、おかしいですね〜」と頭を抱えておられました。

🙅🏻‍♀️First Aidでストレージを検証する

Command + Rを押しながらMacを起動すると、macOSユーティリティメニューからディスクユーティリティを選択できます。
ディスクユーティリティにはFirst Aidという検証ツールがあるので、このツールを使って動かないMacのストレージを検証してみました。
が、特に異常は報告されず、空き容量にも変化は現れませんでした。

まとめ：よくあるエラーらしいので、みなさん気を付けて！

というわけで、このエントリでは僕がmacOSをアップグレードするために繰り広げた、死闘の数々を紹介してみました。

ちなみに、数時間かけても一向に進まず、自分では解決できそうになかったので、途中でAppleのサポートに電話したのですが、サポート担当の方いわく、僕と同じようにインストールの途中で「容量不足」と怒られて先に進めなくなる事象は、結構たくさん報告されているようです。
というか、電話で話していたサポートの人自身が「実は先日、私もプライベートで同じ問題に遭遇しまして・・・」と話していました（おいおい）。

毎年macOSをアップデートしてきましたが、ここまで四苦八苦したのは今回が初めてです。
これからは「インストールの準備ができましたよ！」というインストーラの言葉を鵜呑みにせず、ストレージの空き容量が十分あることを確認してからインストールを実行しようと思います。

このブログを読んでいるMacユーザーのみなさんも、OSアップグレードには十分注意してください！

あわせて読みたい

Macが起動しないのは非常に焦ったのですが、「最悪TimeMachineから復元すれば何とかなる」と思えたのは不幸中の幸いでした。
みなさんも万一のトラブルに備えてバックアップ環境はちゃんと整えておきましょう。

blog.jnito.com

【2019年10月版】「Everyday Rails - RSpecによるRailsテスト入門」のセットアップ解説動画を作成しました

はじめに

僕が翻訳者として参加している電子書籍「Everyday Rails - RSpecによるRailsテスト入門」は2014年の日本語版発売以来、現在まで随時内容をアップデートを繰り返しています。
今の内容も十分実用性があるのですが、使用しているライブラリのバージョンが若干古くなっているせいか、ときどきネット上で「サンプルアプリのセットアップがうまくいかない」というコメントを見かけたりします。

そこで僕が実際にゼロからサンプルアプリをセットアップする動画を作成してYouTubeにアップしてみました。

今回作成した動画はこちら

今回作成した動画はこちらです。再生時間は約18分です。

【2019年10月版】「Everyday Rails - RSpecによるRailsテスト入門」の環境作成手順

動画の内容

この動画ではGitHubからサンプルアプリをクローンして、サンプルアプリが起動することと、masterブランチのテストがすべてパスするまでの手順を説明しています。
実行環境はGitHubのこのコミット（8b3800f）時点のコード、および本書の2019-10-01版の内容にあわせて次のようになっています。

• Rails 5.1.1
• RSpec 3.8.0（書籍の中では3.6.0が使われていますが、大きな違いはありません）
• Ruby 2.4.9 （2019年10月14日時点のRuby 2.4系の最新版）

ただし、この動画では以下の内容は説明していません。

• rbenvのセットアップ
• gitのセットアップ
• Chromeのインストール

また、対象となる実行環境はmacOSです。（具体的にはmacOSX Mojave 10.14.6）

ざっくりとした手順

というわけで、具体的な手順については動画を見てやってください！・・・で終わってもいいのですが、動画を見る時間がない、という人のために簡単に手順を紹介しておきます。

# GitHubからコードをクローン
git clone git@github.com:everydayrails/everydayrails-rspec-2017.git

# ディレクトリを移動
cd everydayrails-rspec-2017

# 実行環境をRuby 2.4系に設定（2.4系のRubyを事前にインストールしておく）
rbenv local 2.4.9

# Bundlerのインストール（まだインストールしていない場合）
gem install bundler

# gemのインストール
bundle install

# マイグレーション実行
rails db:migrate

# サーバーを起動して動作確認（最初はSign up画面にてユーザーを作成）
rails s

# テストが全部パスすることを確認
bin/rspec 

動画の中でもお話ししたとおり、僕が今回試した手順では特に大きなトラブルもなく、テストが全部パスするところまで実行できました。

2021-3-27 追記

mimemagic gemの過去のバージョンが削除（yank）されてしまった関係で、bundle installすると以下のようなエラーが出る場合があります（参考記事）。

Your bundle is locked to mimemagic (0.3.2), but that version could not be found in any of the sources listed in your Gemfile. If you haven't changed sources,
that means the author of mimemagic (0.3.2) has removed it. You'll need to update your bundle to a different version of mimemagic (0.3.2) that hasn't been
removed in order to install.

このエラーが出た場合はbundle installの代わりにbundle update mimemagicを実行するとgemのインストールができるはずです。

bundle update mimemagic

ただし、gemのインストールが成功しても以下のようなエラーが出る場合があります。

Failures:

  1) Tasks user toggles a task
     Got 0 failures and 2 other errors:

     1.1) Failure/Error: visit root_path
          
          Selenium::WebDriver::Error::SessionNotCreatedError:
            session not created: This version of ChromeDriver only supports Chrome version 90
            Current browser version is 89.0.4389.90 with binary path /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

この場合はGemfileを開き、"chromedriver-helper"を"webdrivers"に置き換えてください。

 group :test do
   gem 'capybara', '~> 2.15.4'
   gem 'selenium-webdriver'
-  gem 'chromedriver-helper'
+  gem 'webdrivers'
   # Or use poltergeist and PhantomJS as an alternative to Selenium/Chrome
   # gem 'poltergeist', '~> 1.15.0'
   gem 'launchy', '~> 2.4.3'

さらに、"selenium-webdriver"も一緒にアップデートした方が良いので、Gemfileを保存したらbundle update selenium-webdriverを実行してください。

bundle update selenium-webdriver

僕の環境ではこれで全テストがパスしました。

（参考：動作確認した実行環境）

• MacBook Pro (13-inch, M1, 2020)
• macOs BigSur 11.2.3
• Ruby 2.4.10 (rbenvでインストール)
• Chrome 89.0.4389.90 (Official Build) (arm64)

Cloud9で動かしたい場合

Cloud9で実行したい人は以下の動画が参考になるかもしれません。

【2019年7月版】Cloud9上でEveryday Railsの`js: true`付きのフィーチャスペックを実行する手順

Qiitaに書いた以下の記事もあわせてご覧ください。

qiita.com

お願い：質問は「みんなが見える場所」で！

この動画を見てもうまく動かない！という場合は、僕の方でできるかぎりサポートします。
ただし、その場合はTeratailやStackOverflowなど、「みんなが見える場所」で質問するようにしてください。（DMでの技術的な質問は基本的にNGです）
その上でTwitter等で「ここに質問を書いたので見てください」とメンションをもらえれば、何らかのコメントを返すようにします。

なぜ「みんなが見える場所」での質問をお願いするのかという理由については以下のエントリにまとめてあるので、こちらも参考にどうぞ。
blog.jnito.com

まとめ

というわけで、このエントリではYouTubeに公開した「Everyday Rails - RSpecによるRailsテスト入門」のセットアップ解説動画について紹介しました。
もし「Everyday Railsを買ったけど、セットアップがうまくいかなくて困っている」という人がいたら、ぜひこの動画を参考にしてみてください！

【2019年10月版】「Everyday Rails - RSpecによるRailsテスト入門」の環境作成手順

あわせて読みたい

さらに、このサンプルアプリケーションをRails 6にアップデートしたときに発生するテストコードの変更点についてもブログにまとめました。
こちらも動画付きです。よかったら参考にしてみてください。

blog.jnito.com

「Everyday Rails - RSpecによるRailsテスト入門」について

「Everyday Rails - RSpecによるRailsテスト入門」はその名の通り、RailsアプリケーションをRSpecを使ってテストする方法を解説した電子書籍です。
難易度的には「RailsやRubyがある程度わかっている人であればOK、RSpecの知識はゼロでも大丈夫」というレベルになっています。

内容の詳細や購入方法等については以下のエントリにまとめてあるので、こちらを参考にしてください。
blog.jnito.com

ご購入は以下のサイトからどうぞ。
Everyday Rails - RSpecによるRailsテスト入門 - Leanpub

発表でうまく話すためには （富山Ruby会議01のPRをかねて） #toyamark

はじめに

僕は今年の8月末に銀座Railsという勉強会で登壇してきました。
講演が終わったあと、Twitterでみなさんの感想を読んでいたところ、こんなツイートを見つけました。

今回も銀座Rails勉強になったな。
内容もさることながら、伊藤さん、喋りが上手いなぁと思って聞いていた。
構成とかどうやって考えてるとか、練習とかはどのぐらいしたんだろうかとか、後々思い返して結構気になってる。
#ginzarails

— 𝕐.𝕊𝕦𝕫𝕦𝕜𝕚 (@y_s______731) August 29, 2019

どうもありがとうございます！
発表のしゃべり方は、自分でもうまい方なんじゃないかと思っています（笑）。

コメントをくださった方が「構成の考え方や練習量が気になる」とおっしゃっているので、今回は僕が考える「発表でうまく話すコツ」を書いてみようと思います。

【もくじ】

いきなり種明かし ＝ 実はある本の内容を実践してるだけ

僕が初めて人前で話したのは2012年のDevLove関西のイベントです。

blog.jnito.com

当時は人前で話すのが初めてで、僕はプレゼンのやり方について右も左もわかりませんでした。
そこで、プレゼンのイロハを学ぶために買ったのが、この「パワー・プレゼンテーション」という本です。

パワー・プレゼンテーション (グロービス思考シリーズ)

この本が僕にとってはすごく「当たり」で、それ以来、ずっとこの本に書かれている内容を実践し続けて現在に至ります。
（これ以外プレゼン関係の本は読んでいません）

僕が大事にしているポイントあれこれ

というわけで、みなさんもこの本を読めば僕が実践しているコツが全部わかります。以上！！

・・・で、終わると、あまりにも肩すかしなエントリになってしまうので、この本の内容で特に僕が大事にしているポイントとをいくつか挙げてみます。
また、この本の中には載っていないけど、個人的に大事にしているポイントもいくつか書きます。

参考：銀座Railsで発表した内容について

ここでは具体例として、銀座Railsで使ったスライドや話した内容を登場させます。
銀座Railsでの僕の発表については、以前書いたこちらのブログ記事を参照してください。

blog.jnito.com

それでは以下が本編です。

聞き手にメリットを与える

うまく話すための大事なポイントは、聞き手に明確なメリットを与えることです。
これを「パワー・プレゼンテーション」の中ではウィッフィー（WIIFY = What's in it for you?）と呼んでいます。

発表の構成を考えるときは、自分の中にある「これを話したい！」「これを聞いてほしい！」という思いが起点となることは間違いありません。
しかし、そのままスタートを切るのではなく、一度自分の視点を聞き手の視点に置き換えて「それを聞いて何がうれしいの？」「その話のどこがおいしいの？」と自問自答してみると、聞き手にとっていっそう満足度の高い発表にすることができます。

先日の銀座Railsの発表で言えば、「普段あまり目にする機会がない、"他の人がリアルにコードを書いている姿"を見られること（それを通じて、プログラマがコードを書きながら考えていることや、コーディングのテクニックを知れること）が聞き手にとってのメリットになるはず」と僕は考えていました。

A地点は何か？B地点は何か？

書籍の中では、プレゼンは聞き手をA地点からB地点に連れて行くことがゴールだとしています。

A地点というのは、プレゼンを聞く前の聞き手の状態です。
B地点というのは、あなたのプレゼンを聞いた後に聞き手が抱く気持ちです。

すなわち、聞き手が「話を聞く前は○○だったが、話を聞いた後には△△な気持ちになった」という感想を抱けば、その発表は大成功、ということです。

たとえば、先日の銀座Railsの発表で言えば、A地点とB地点の設計はこんな感じになります。

話を聞く前は「すごいプログラマは何でも知っていて、すらすらコードを書く」と思っていたが（A地点）、話を聞いた後は「別にそんなことはないんだ（でも、自分と違うところもたくさんある！）」と思うようになり、その結果、気持ちが軽くなってこのままがんばっていこうと思えた（B地点）

ペルソナを明確にする

プレゼンの内容を考えるときはペルソナを明確にします。
すなわち、「こんな経歴で、ふだんこんなことを考えている人が最も喜ぶ話を提供しよう」と考えることが重要です。

これはプレゼンに限らず、技術記事を書くときも同様ですね。
qiita.com

プレゼン当日に聞き手が100人いた場合、100人全員が喜ぶ話を提供するのはほぼ不可能です。
全員を喜ばせるような内容にしようとすると、逆に何が言いたいのかよくわからない、誰も嬉しくない発表になってしまうかもしれません。

別に100人の中の5人とか10人ぐらいでもいいんです。
「客席にはきっと、こんなことで困っている人やこんなことを知りたがっている人がいるはず」という「仮想オーディエンス」を設定して、その人が大喜びするような内容を考えます。

こういう設計にした方が、内容が濃くて面白い話になりやすいです。
仮に100人中の90人はターゲットでなかったとしても、濃くて面白い話になっていれば「その話はすでに知ってるけど、たしかにそのとおり！」とか、「へ〜、そういう世界もあるんですね。初めて知りました」と、納得してもらえる内容になるはずです。

ちなみに、先日の銀座Railsの発表で僕が設定したペルソナは、

「プログラミング歴があまり長くなくて、自分のプログラミングスキルにあまり自信がなく、なおかつ他の人がコードを書く様子を見たこともないので、"きっと自分以外のプログラマはもっとすさまじいスピードで書いているに違いない"と、何の根拠もなく考えている人」

でした。

背伸びをしない

「背伸びをするな。自分の言葉で語れる内容だけを語れ」

これは書籍の内容ではなく、僕が初めてDevLove関西で登壇するときに、弊社ソニックガーデンの倉貫社長から言われたアドバイスです。

これはプレゼン初心者に多いと思うのですが、人前で話す自分を想像すると、「あいつ、バカなんじゃない？」とか「大したことねーのに偉そうにしゃべりやがって」みたいにdisられるんじゃないかと、つい妄想してしまうことがあります（僕もそうでした）。

こういった恐怖心があると、「えーと、あまり詳しいわけじゃないんだけど、この話も盛り込んでおいた方がいいかな・・・」という、「見栄をはりたくなる気持ち」が湧きあがってきます。

が、自分がよく知らない話をプレゼンに盛り込むのはやめた方がいいです。

自分がよく知らない話は自信をもってしゃべれないので、説得力がなくなります。
また、質疑応答で「あまり詳しくない話」に質問が来ると、しどろもどろになってロクな回答ができなくなります。

それよりもむしろ、自分がちゃんと理解している内容、自分自身の考え、自分自身の経験だけを話すようにしてください。
その方が話が生き生きとして、説得力が高まります。
質問が来ても自分の中にある話なので、自信をもって答えることができます。

自分が理解していることを自分の言葉で堂々と語っていれば、話のレベルが低いだの高いだの、そんな文句を言う人は出てきません。

アイスブレイクは重要だが、ウケ狙いは不要

プレゼンの冒頭では軽いアイスブレイクを入れて、聞き手の気持ちをほぐしておくと、その後のトークもなごやかに進めやすくなります。

アイスブレイクは何でもいいです。
簡単なのは「〜な人がいたら挙手！」みたいな感じで、会場に向かって質問を投げかけることですね。

先日の銀座Railsでは、「今日、僕は新幹線で東京までやってきたんですけど、この中で僕と同じように新幹線で来た人はいますか！？」と質問を投げてみました。（絶対いないだろうと思ったら、1名だけいましたw）

その一方で、発表中に笑いを取りに行くのは、僕は非常に危険だと思っています。
ウケを狙おうとすると失言につながったり、意図せず誰かを傷つけたりしやすいからです。
会場では何も問題が起きなくても、スライドを公開したあとにSNSで大炎上、みたいなこともよくあります。

また、ウケを狙って盛大に滑ってしまったときは、自分へのダメージも大きいですし、聞き手も痛々しい気持ちになってしまいます。

とはいえ、始終お堅い話ばかりしてもしんどいと思うので、僕は「クスッと笑えるぐらいの軽いユーモア」を入れることはあります。
大爆笑を狙いに行くのではなく、あくまで「クスッと笑える程度」に留めておくのがポイントです（そのさじ加減はなかなか難しいと思いますが）。
軽いユーモアであれば、仮に滑ったとしても致命傷にはなりにくいです。

たとえば、銀座Railsでは若干自虐気味にこういうスライドを挟み込んだりしていました。

客席に目をやる、問いかけを盛り込む

発表中は頻繁に客席に目をやることも大事なポイントの一つです。
話すのに必死になって、ずっと目の前のパソコンを見ていたり、会場のスクリーンに向かって話し続けていたりすると、話し手と聞き手の心の距離がどんどん離れていきます。

発表中は何度も客席の様子を確認しましょう。
自分の話にうなずいてくれる人が何人かいたら、いい感じに自分の話が伝わっている証拠です。

また、発表の途中に「問いかけ」を盛り込むのも効果的なテクニックのひとつです。
「〜ですよね？」とか、「〜だったりしませんか？」とか、「〜ってご存じですか？」とか、こういった問いかけを挟み込むことで、聞き手はあなたと会話をしているような気持ちになります。
そうすると、話し手と聞き手の心の距離が縮まって、聞き手はあなたの話にじっくり耳を傾けてくれるようになります。

以下は銀座Railsで使ったスライドの「問いかけ」の例です。

スライドを読ませない（聞き手の意識をスライドに集中させない）

自分の話したいことをふんだんにスライドに盛り込もうとすると、スライドが文字だらけになります。
スライドが文字だらけになると、聞き手はスライドの字を読むことに必死になります。
スライドを読むのに必死になると、聞き手の意識があなたの言葉ではなく、スライドの文字に集中します。
結果として、聞き手は「あなたの話を聞いた」というよりも、「スライドをがんばって読んだ」という形になります。

このように、「うまく話す」という観点においては、情報量が多すぎるスライドはマイナスに作用します。
そもそも、自分が話したいことをすべてスライドに盛り込むのであれば、何も話さずにスライドを配って終わりにすればいいはずです。

情報量が多すぎるスライドを防止する方法のひとつは、「スライドの中の文字を絶対に折り返さない」という制約を課すことです。
この制約を守るようにすると、自ずとスライドの文字が削られていきます。

以下は「絶対に文字を折り返さないスライド」の一例です。

また、最初から全部スライドの文字を見せると、やはり聞き手の意識がスライドの文字に移ってしまいます。
なので、僕はアニメーション機能を使って箇条書きをひとつずつ表示するようにしています。

同僚にレビューしてもらう

初めての発表で慣れていないときは、発表の構成やスライドがある程度できた時点で会社の同僚にレビューしてもらいましょう。
ちょっと恥ずかしいかもしれませんが、軌道修正は早ければ早いほど良いです。

完全に作り込んでしまう必要はありません。
むしろ、完全に作り込んだあとでは、「発表直前に大量のフィードバックを受けて途方に暮れる」といった事態になりやすいです。
「だいたいこんな感じ」というイメージが固まった時点で早めにレビューしてもらうことをオススメします。

そして最後に練習、練習、練習！！

ところで、冒頭で紹介した感想ツイートの中に「練習とかはどのぐらいしたんだろうか」というコメントがありました。
「練習ってwww 僕がそんな泥臭い努力をするわけないじゃないですか！」と言いたいところですが、めちゃくちゃ練習してます。はい。

練習の重要性は書籍「パワー・プレゼンテーション」の中でも説明されています。

では、どうしたら命を吹き込むことができるのだろうか。それは、「声に出して練習する」ことだ。

その際には、本番で使用するスライドを使い、大きな声で練習してほしい。実際に聞き手の前に立ってプレゼンテーションするつもりで行おう。この「声に出して練習する」プロセスなくしては、効果的なプレゼンテーションなどありえないのだ。

「パワー・プレゼンテーション」183p.

僕はだいたい発表当日の1週間前にはスライドをいったん作り終えて、練習（というかリハーサル）を始めます。

本番までに最低でも4〜5回、多いときは10回以上やります。
ときどきPCの画面と自分の声を録画して、自分で動画をチェックすることもあります。

MacであればQuickTime Playerを使って画面を録画することが可能です。
（参考：MacのQuickTime Playerで画面を収録する - Apple サポート (日本)）

事前に練習を繰り返すと、次のようなメリットが生まれます。

当日の時間配分をほぼ完璧にコントロールできる

リハーサルをやると、自分のトーク時間がわかります。
これ、意外なことに時間をオーバーしてしまうケースの方が圧倒的に多いんですよね。
今までリハーサルをしてみて、予定時間より早く終わった経験は一度もありません。

なので、リハーサルをまったくせずに本番にのぞむと、たいていの場合、制限時間をオーバーしてしまうと思います。

時間が足りないと最後だけ急に早口になって「このスライドは飛ばします」みたいなセリフを連発したり、「あっ、あっ、あと5分ください！」とお願いしたりするハメになります。

こうなると聞き手も変に焦ってしまいますし、時間をオーバーするとタイムテーブルが押してしまって、あとの登壇者に迷惑がかかったりします。

ですので、リハーサルを繰り返して、自分のトーク時間をコントロールできるようにしましょう。
リハーサルでは時間をオーバーしても誰にも迷惑がかかりません。
明らかに制限時間を超えてしまう場合は、スライドの枚数や口で話す内容を減らして、トーク時間を調整しましょう。

リハーサルを4〜5回やってトーク時間が制限時間内に収まれば、本番でも同じように制限時間内にしゃべれるはずです。

スライドやトークの内容が洗練される

練習を繰り返したり、録画した自分の発表をチェックしたりすると、第三者の視点で自分の発表を振り返ることができます。
そうすると、「ちょっとここはわかりにくいな」とか、「ここはこういう説明の方がいいな」という改善点が見つかります。

そういった改善を繰り返していけば、スライドやトークの内容がどんどん洗練されていきます。

発表中に挟む軽いジョークなんかも、練習を繰り返すうちに「あ、ここでこういうジョークが入れられるかも？」と気づくことが多いです。

落ち着いて話せるようになる（えー、あー、あのー、の回数が減る）

ぶっつけ本番で話そうとすると、芸能人やアナウンサーではない僕たちは、「えー」「あー」「あのー」みたいな言葉がしょっちゅう出てきてしまいます。

練習を繰り返すと、落ち着いて話せるようになるので、えー、あー、あのー、の回数が減ります。

多少の「えー、あー、あのー」であれば口に出しても問題はありませんが、頻繁にこの言葉が出てくると聞き手も少し落ち着かない気分になってくるので、プレゼン初心者の方は要注意です。
（練習を録画して自分で見直してみると、自分がどれくらい「えー、あー、あのー」を連発しているのか、よくわかります）

また、上で述べたように、発表中はなるべく客席に目をやることが大事です。
これも余裕がない人ほどパソコンやスクリーンに集中しがちになります。
ですので、事前に練習を繰り返して「心の余裕」を十分持つようにしましょう。

まとめ

というわけで、このエントリでは僕が普段意識している「発表でうまく話すためのコツ」をいろいろと紹介しました。

もちろん、発表の上手・下手はこれまでに踏んできた場数によっても変わってきます。
ですが、場数だけがすべてではありません。

ここで紹介したようなコツを意識すれば、プレゼン初心者の人でも「発表、とてもお上手ですね」と言われるはずです。
ですので、みなさんもこのエントリで紹介した「発表のコツ」をぜひ実践してみてください！

パワー・プレゼンテーション (グロービス思考シリーズ)

あわせて読みたい

Macで使えるプレゼンソフト、Keynoteの使い方を解説した記事です。
スライドの作り方に慣れていない人は、こちらの記事も参考にしてみてください。

blog.jnito.com

最後に宣伝：富山Ruby会議01で発表します！

さて、最後にちょっと宣伝をさせてください。
今度、2019年11月3日（日）に開催される富山Ruby会議01で、招待講演として「○○からRubyへ」という発表をさせてもらいます。

スライドはまだ作り始めていませんが、だいたいこんな発表にしようと考えています。

聞き手のペルソナ

この講演のターゲットとなるのは「普段は地元のSIerでコンパイル型の言語を触っているが、Rubyの名前はよく聞くし、密かに憧れをもっていたりするSEやプログラマ」です。

A地点とB地点

A地点は「Rubyはまだ使ったことがないけど、ちょっと興味がある。でも、実際どうなの？いいの？悪いの？」と疑問を持っている状態です。

B地点は「へ〜、Rubyってちょっと面白そう！このイベントが終わったらちょっと試してみようかな」と思う状態です。

講演のターゲットとなる方々が、僕の講演を聞いてこんなふうに感じてくれたら、僕の発表は大成功、ということになります。

「伊藤さんのプレゼンスキル」は果たして！？

当然のことながら、今回のエントリで紹介した「発表のコツ」は、この発表でもすべて実践するつもりです。
ふつうに発表を聞いてもらうだけでも構いませんが、このブログを読んだ人は「発表のコツがどこで使われているか？」を意識して僕の発表を見てみると、より楽しめるかもしれません。

また、僕の講演だけでなく、このイベントでは著名なRubyプログラマの方々が登壇されるので、その内容も必聴です。
さらに、普段北陸地方とあまり縁がない方は、旅行を兼ねて美味しい魚料理やお寿司を楽しむのも良いと思います（僕も妻と金沢や富山を旅行する予定です😄）。

北陸地方に住んでいる方はもちろん、東京や関西など、遠方に住んでいる方たちもぜひ足を運んでもらいたいです。

登壇者情報と参加申込みページはこちらです。
toyamarb.github.io
toyamarb.connpass.com
それではみなさん、11月3日の富山Ruby会議01でお会いしましょう〜！

追記：フィヨルドブートキャンプの受講生のみなさんへ（2022.3.12追記）

フィヨルドブートキャンプの受講生のみなさんが内部LT会の参考資料としてこのエントリをよく見に来ている、という話を聞いたのでちょっと追記しておきます。

このエントリで想定しているのは「ガチめの発表」です。
「ガチめの発表」というのは、オーディエンスが50人以上いて、発表時間も20分以上あって、発表者はオーディエンスにとって価値のある情報を提供することが期待されている、そういう発表のことを指します。

一方、LT（ライトニングトーク）というのは、この業界（ITエンジニア業界）では「ゆるくて雑な発表（でもOK）」と捉えられることが多いです。

少し古い動画ですが、ベテラン勢が考える「（いわゆる）LT」っていうのはこういうイメージなのではないでしょうか（YouTubeでたまたま見つけてきただけなので、ここでこの動画を紹介することに深い意味はありません）。

www.youtube.com

もちろん、LTでもきっちり作り込んで発表するのはまったく構いません！
ですが、もっといい加減で雑な発表であってもLTであれば許されるはずです。
なので、LT会で発表しようかどうか迷っている人は自分の中のハードルを下げて、もっと気楽に登壇を申し込んでみてください😄