2005-04-09

高橋メソッドに真面目に水をさす

高橋メソッドの紹介が流行っているようなんだけど、どうにも腑に落ちないので疑問を呈することにした。それは、「文字がでかすぎて逆に分かりにくくないか?」という一点。これは自分がスライドに求める機能が2つあるからなのだけれど、とりあえず最初から順を追って読んでみてほしい。

技術者を名乗るならプレゼンも設計として捉えよう。プレゼンの設計で気にしなければいけないのは

  • 内容
  • 時間と分量
  • 分かりやすい提示
  • 分かりやすい喋り

なわけだけど1、高橋メソッドは「スライド作り」における技法だと思っている(というかライブで見たことない)ので、「分かりやすい提示」だけに集中して考えればよい。

では「分かりやすい提示」とは何か。これは

  • 資料としてのスライド
  • インターフェイスとしてのスライド

の両方を考える必要があるだろう。

資料としては表やグラフなどがこれに当たる感じがするが、これをもう少し広げると要するに「一覧性」と言い直すことができる。例えば

高橋メソッドの特徴

(1)巨大な文字
(2)簡潔な言葉

というスライドはただの箇条書きだけど一覧性があり、高橋メソッドを説明する際の資料として十分使いものになる。

インターフェイスというのはちょっと苦しい言葉なんだけど、例えば資料性を高めるために30行の箇条書きを1枚のスライドに収めてもとても読めない。これは印刷した際には資料として使えるが、プレゼンの現場では伝えたい情報と聞き手のインターフェイスとして失敗している。では「ぱっと見て分かる」ということなのかというと、そうとも言いきれなくて、アニメーションなんかもインターフェイスに入る。アニメーションは結果だけ見ても意味がなく、その動作中注視している必要があるので「ぱっと見」を定義にすると外れてしまうのである。もちろん効果的なアニメーション以外は失敗だし、基本的には失敗事例の方が多いと思う。例えば1つのスライドに10個もアニメーションが入っているようなものは失敗と見て間違いないだろう。例え結果として適切な情報量になっていてもやりすぎである。同じように全部のスライドで同じアニメーションを使うのもダメ。飽きる。飽きさせたらプレゼンは負けだ。

高橋メソッドは上の2つのうちインターフェイスの方に、つまり、詰め込みすぎて分かりにくいスライドへのアンチテーゼとしての手法に重きが置かれている2。しかし「高橋メソッドについて」を見ていると、「資料としては分かりにくい」と感じないだろうか。言い方は悪いがインパクト勝負になってしまっている部分があり、肝心の要点がどこにも整理されていないという悲しい状態になってしまっている。

そこで

頭と尻にちゃんとまとめを入れろ

と言いたい。例えば利点についての説明では、個々の利点を説明する前に、このようなまとめのスライドを入れるべき。

高橋メソッドの利点

(1)見やすい
(2)表現が簡潔になる
(3)発表しやすい
(4)聞くのに集中しやすい

これを見せたあとに、順番に個々の項目について補足していくという流れにした方がぐっと分かりやすくなる。

しかし高橋メソッドの特徴である「無駄にでかい文字を利用する3」というポイントだけに執着すると、たったこれだけの情報量でも1枚のスライドに収めるのは難しくなる。

同じように全体の流れについても適宜まとめのスライドを入れていくべきなのだが、全体を見て思うのは高橋メソッドは「まとめの提示に向いていない」ということである。なんというか、例えば「ls -la と叩いても4つしかファイルが表示されないくらいに terminal が狭い」みたいな扱いにくさを感じるのだ。分かりやすさのためにはある程度一覧性が必要だと思う。

修正高橋メソッドの登場に期待したい。

余談だけど、プレゼンの装置の設計も大事。今回の話の流れで言えば「会場とスクリーンとプロジェクタの関係」である。大きな会場ではハンディなプロジェクタで力不足になるのは当たり前だし、逆に小さな会場ではプロジェクタの画角が問題になる。要するにワイドコンバータがほしいってことなんだけど、例えば画角が足りないときはプロジェクタを会場後方に配置して VGA のケーブルを長くする(当然ケーブルを長くするのは短いときより気を使う)などの臨機応変さが大事になる。この辺はプレゼンの技法ではなく会場部隊のノウハウである。裏方が好きな人はこの辺を勉強しておくとよいだろう。(ほんとは音響系も大事だけどそっち方面は興味ないので何も書くことはないです。悪しからず。)

……。プレゼンなんて長いことしてないな。ま、必要ないからいいんだけど。

  1. 抜けがあったらツッコミよろしく 

  2. ということは逆にそういう、詰め込みすぎてて全然分かんねープレゼンをしている人がたくさんいるってことなんだろうな。そういう間違いを犯すのはたぶん「スライドを印刷して確認してるから」だと思う。 

  3. これは自分の曲解もかもしれないけど 

About

例によって個人のなんちゃらです

Recent Posts

Categories

Tool 日々 Web Biz Net Apple MS ことば News Unix howto Food PHP Movie Edu Community Book Security Text TV Perl Ruby Music Pdoc 生き方 RDoc ViewCVS CVS Rsync Disk Mail FreeBSD Cygwin PDF Photo Zebedee Debian OSX Comic Cron Sysadmin Font Analog iCal Sunbird DNS Linux Wiki Emacs Thunderbird Sitecopy Terminal Drawing tDiary AppleScript Life Money Omni PukiWiki Xen XREA Zsh Screen CASL Firefox Fink zsh haXe Ecmascript PATH_INFO SQLite PEAR Lighttpd FastCGI Subversion au prototype.js jsUnit Apache Trac Template Java Rhino Mochikit Feed Bloglines CSS del.icio.us SBS qwikWeb gettext Ajax JSDoc Rails HTML CHM EPWING NDTP EB IE CLI ck ThinkPad Toy WSH RFC readline rlwrap ImageMagick epeg Frenzy sysprep Ubuntu MeCab DTP ERD DBMS eclipse Eclipse Awk RD Diigo XAMPP RubyGems PHPDoc iCab DOM YAML Camino Geekmonkey w3m Scheme Gauche Lisp JSAN Google VMware DSL SLAX Safari Markdown Textile IRC Jabber Fastladder MacPorts LLSpirit CPAN Mozilla Twitter OpenFL Rswatch ITS NTP GUI Pragger Yapra XML Mobile Git Study JSON VirtualBox Samba Pear Growl Mercurial Rack Capistrano Rake Win RSS Mechanize Sitemaps Android JavaScript Python RTM OOo iPod Yahoo Unicode Github iTunes God SBM friendfeed Friendfeed HokuUn Sinatra TDD Test Project Evernote iPad Geohash Location Map Search Simplenote Image WebKit RSpec Phone CSV WiMAX USB Chrome RubyKaigi RubyKaigi2011 Space CoffeeScript Nokogiri Hpricot Rubygems jQuery Node GTD CI UX Design VCS Kanazawa.rb Kindle Amazon Agile Vagrant Chef Windows Composer Dotenv PaaS Itamae SaaS Docker Swagger Grape WebAPI Microservices OmniAuth HTTP 分析基盤 CDN Terraform IaaS HCL Webpack Vue.js BigQuery Middleman CMS AWS PNG Laravel Selenium OAuth OpenAPI GitHub UML GCP TypeScript SQL Hanami Document SVG AsciiDoc Pandoc DocBook Develop Jekyll macOS Node.js Vite Heroku Transformer AI Data Cloud Wasm