#279

Public Railsdmで『エンジニアのためのスライドデザイン実践講座』という発表をしてきました #railsdm

Revisions rev10

TAEKO AKATSUKA
Update post. [skip notice]
Updated by taea 2018-07-17 14:18:30 +0900
  • はー、暑いですね。 デザイナーの [@ken_c_lo](https://twitter.com/ken_c_lo) です。
  • 先日開催された、『[Rails Developers Meetup 2018 Day 3 Extreme](https://techplay.jp/event/679666)』 というイベントで、発表してきましたのでご報告エントリです。
  • 先日開催された、『[Rails Developers Meetup 2018 Day 3 Extreme](https://techplay.jp/event/679666)』 というイベントで、発表してきましたのでご報告エントリです。（今回esaの話はほとんど出てきませんmm）
  • <script async class="speakerdeck-embed" data-id="4ce2d11c8e4944fa924f2201b13df89e" data-ratio="1.33333333333333" src="//speakerdeck.com/assets/embed.js"></script>
  • [エンジニアのためのスライドデザイン実践講座 / How to design presentations for engineers - Speaker Deck](https://speakerdeck.com/ken_c_lo/how-to-design-presentations-for-engineers)
  • ## Q&A（補足）
  • Railsdmには、[AMA](http://railsdm.herokuapp.com/issues/76)というQ&Aサービスが主催の [@yhirano55](https://twitter.com/yhirano55) さんにより用意していただいており、こちらにいただいたご質問にお答えしていくとともに、また懇親会などでいただいたご質問などにもお答えして、スライドの補足にしたいと思います。
  • [[Day 3: B-18] エンジニアのためのスライドデザイン実践講座 | AMA](http://railsdm.herokuapp.com/issues/76)
  • ### Q: 吹き出しを並べて書いた時によく、中の文字数によっては吹き出しの大きさが変わってしまうことがあるんですが、その場合は文字が小さくなってでも吹き出しの大きさを統一した方がいいですか？ <br>中の文字としては最低でも何 pt ぐらいみたいなコツもあれば教えていただきたいです。
  • ふきだしを使うシチュエーションによっても変わってきそうですね。
  • 例えば対比を表すためにふきだしを2つ並べた時なんかは、大きさを統一するとともに、中の文字数もなるべく近くして、似たフォーマットにした方が対比がわかりやすくなって良いと思います。 （ [→スライド27ページのような感じです](https://speakerdeck.com/ken_c_lo/how-to-design-presentations-for-engineers?slide=27)）
  • 一方、個別に説明したいことがあって、ふきだしを使っている場合は、特にふきだしの大きさを合わせなくてもよいと思います。 （[→スライド60ページのような感じです]( https://speakerdeck.com/ken_c_lo/how-to-design-presentations-for-engineers?slide=60)）
  • 文字の大きさは、使い方によって相対的に変わってきそうなので、今回ちょっと明確な言及を避けてしまったのですがmm 、例えば [スライド60ページ](https://speakerdeck.com/ken_c_lo/how-to-design-presentations-for-engineers?slide=60) のような状況でしたら、20ptくらい…、最小でも16ptくらいがよいかなあと思います。
  • ### Q: タイトルの文字の両端を揃えるとバランスが取れると仰ってましたが、そのデザインに合わせてタイトルの文字数などを調整するものですか？
  • はい、タイトルの文字数を調整することもありますし、文字の大きさを調整してピッシリ合うように調整することも多いです。 また、触れるの忘れましたが、キリのよいところで改行するというのも大事ですね。
  • ### Q: 情報整理を行う上で、参考になった本はありますか？（会場での質問）
  • [デザイン仕事に必ず役立つ 図解力アップドリル | 原田 泰 |本 | 通販 | Amazon](https://www.amazon.co.jp/dp/4862670903)
  • よい本でした。デザインにおける色んな表現方法のバリエーションやそれぞれの考え方を丁寧に掘り下げて解説しています。意図や考え方を的確にデザインに反映させるために、役立つ知識になると思います。
  • 帯やタイトルにはデザイナー向けと書いてあり、確かにデザイナーにも役に立つ内容だと思うのですが、ノンデザイナーやエンジニアにとっても、デザインとはどういうものなのか？を理解するためのよい内容になっていると思いました。
  • [今日からはじめる情報設計 -センスメイキングするための7ステップ | アビー・コバート, 長谷川敦士, 安藤 幸央 |本 | 通販 | Amazon](https://www.amazon.co.jp/dp/4802510012/)
  • 情報設計する時に考えるべきことを、かなり上位の前提の段階から、概念的にわかりやすく整理して教えてくれる本でした。いい本でした。
  • （すみません、会場で『みんなではじめる情報設計』って言ってしまったんですが、書名間違えてました。。『みんなではじめるデザイン批評』と多分混ざりましたmm）
  • ### Q: コードをスライド中で紹介する時に、小さくなってしまいがち。こういう時によいプラクティスありますか？（会場での質問）
  • そういえば、コード出てこなくてごめんなさいmm
  • 考えられる対策としては
  • - なるべく文字が大きく見えるように貼る
  • - 強調したい部分の文字列を拡大する
  • - 今説明してるコードの現在位置がわからなくて説明しづらいという問題について、スライドのコードの中にリアルタイムで線を引きながら解説するということをやってる人がいて、とてもわかりやすいなーと思った記憶があるんですが、あれはなんのツールを使ってたのか思い出せませんでした…mm
  • - コードの中の、今言及している現在位置にハイライト入れながら説明するのは普通によさそうだし、コードじゃなくても有効そうです。今度試してみよう。
  • ### Q: 赤塚さんがどのように情報設計を学んだのか知りたくなりました。
  • これに答えるべく、連休の間自分の人生を振り返って考えてたんですが、コレっていう答えが見つからず…自分の事はよくわからないものだなあ。。
  • おそらくは、デザイナーになって最初に入った職場の体験が大きいのかなあと思っております。 最初の職場はWebではない、少人数のデザイン事務所で冊子やパンフレットやポスターなんかのデザインを主にやってたんですが、回りの先輩たちがみんな優秀だったのでそのアウトプットを見て学んだところが大きいです。
  • あと、その職場では、デザインと同時にプレゼン企画書を作ってて、例えば会社案内のような冊子ものだと台割りとかコンテンツ企画とかも自分で考えて、企画書を作り込んでデザインカンプと一緒にプレゼンするということをやってたんですが、そのへんの体験が情報設計とデザインの両輪を理解する上で、糧になっている気がします。（プレゼンのトークは社長や広告代理店の人がやってくれたので、トーク力は上がりませんでした。）
  • あと、デザイナー同士でレビューし合うという習慣があったのも大きいかもしれません。必ず誰かに何回か見てもらって、文字校正をはじめ、揃っていない箇所とかを指摘し合うということを日常的にやってました。
  • 自分は割とクラシカルな「師匠の背中を見て育つ」的な職人的な徒弟制っぽい世界で育った人間だと思うんですが、今は若くても優秀な方がたくさんいて、知の高速道路を感じて大変眩しいです。
  • そんなご時世に、「どうやったらデザインができるようになるんですか？」という質問に対して、「先輩の背中を見て育て」「修行！」みたいなのもなんかすごい老害っぽいので言いたくないんですよねえ。しかしじゃあ何が言えるんだろうというところで、まだこれといった答えが出ず… 本なども読んで学びつつ日々模索中ですmm
  • ### Q: Presentation Zen などでは、このように話す情報を全部スライドに書くようなスタイルは明確に否定されているんですよね。（懇親会での言及）
  • そうなんですよねえ。。
  • もともと自分が、しゃべるのがすごく苦手で、資料に全部しゃべることを書かないとしゃべれない、Presentation Zenやジョブズみたいなカッコイイプレゼンスタイルが真似できない…という悩みから、仕方なくこういうやり方をしていました。
  • しかし、いざWebで公開してみると、しゃべるべきことがスライドに全部書いてあるので、リアルタイムで見ていない人にもスライド単体で伝えることができるということから、意外と「わかりやすい」と評価をいただけたりしたので、今回はそのやり方を紹介させていただこうという趣旨でした。
  • えらそうな主語のでかいタイトルつけちゃったせいで誤解を招いてしまったかもしれませんが、決してこのやり方が正解ということはなく、1つのやり方として捉えていただければ幸いです。
  • しかし、Webに資料を広く公開することが前提になったせいで、従来タブーとされていたやり方がそれなりに有効になってきたというのは、面白い現象だなあと思っております。
  • あと、しゃべりやすさという面で言うと、この方法は確かにイマイチなので、今後そのへんをもっと改善していきたいと思っております。
  • ### Q: 聞いてて「なるほど」と思ったけど、いざ自分がやってみたらうまく真似できそうにない。やりすぎたりしてしまいそう。（懇親会での言及）
  • そうなんですよねえ。。
  • バランス感覚の部分に関しては、こうすればできるよ！といった回答が難しくて、何度もやってみて失敗を繰り返して学んだりするしかないのかもしれません。また、識者からレビューされたりするのもよさそう。
  • エンジニアの方々は、情報設計はむしろ専門分野なのでよくできる方がほとんどなのではないかと思っており、それをデザイン的に落とす時の引き出しを多く知っていればできてしまいそうな気もしています。
  • 写経のように、既存の良いデザインをトレースして作ってみるというのも有効かもしれません。
  • また、個人的にオススメしたいのが、ただトレースするだけではなく、自分のオリジナルの目的に適用しつつ既存のものを真似してみるということです。これをやってみると、既存の良いものの背景にある意図などがわかってきたり、また応用力もついてきそうです。
  • ## 感想や反省など
  • - 今回、主催の[@yhirano55](https://twitter.com/yhirano55) さんからよいお題をいただき、今回の発表をすることができました。<br>お話をいただいた時は、「そもそも自分の資料そんなにいいかなー？」とか、「そもそもエンジニアさんプレゼン資料上手い人多いしなー」…とか色々不安もあったのですが、よい感じに受け入れられてほっとしております。
  • - [ズルいデザイン](https://speakerdeck.com/ken_c_lo/zurui-design) とかもそうだったんですが、自分がこれ発表したい！と思っていることよりも、大して自分は言いたいと思ってなかったけど他人から求められて発表するものの方が世間的によく受け入れられることが多いので、改めて面白いなあと思いました。
  • - よいテーマをいただき、ありがとうございました！
  • - 今回のテーマで発表してみて、個人的にも色々と発見がありました。特に、スライドの中でも言いましたが、人のスライドを直すのはとてもやりやすいというのが改めて面白かったです。
  • - スライドの内容を書き出すのと、スライドデザインは別の工程でやるように、普段からしているつもりではあったんですが、自分のスライドだと、いざスライドデザインしようという段階になると、そこでまた内容に対して悩んでしまったり、するんですよねえ。。
  • - 画面を作る前に内容をちゃんと固めて、デザインするときはなるべく客観的な視点を持つようにしたいと改めて感じました。
  • - 発表のとき、指を指しながら説明することが多かったので、レーザーポインターとか持ってくればよかったなあ…。もしくは指差しのいらないプレゼンにしたい。
  • - [AMA](http://railsdm.herokuapp.com/issues/76)、よいシステムなので発表の事前からもっと活用すればよかったなあと思いました。あらかじめAMAを通じて聴きたいことを募ってから、それを発表に反映するようなやり方も面白そうです。
  • - 今回は、[@yu_suke1994 (うなすけさん)](https://twitter.com/yu_suke1994)が事前からうまくAMAを活用されてて、TwitterにAMAのURLを投げて質問を募ったり、また発表の補足として、自分でAMAに質問を投げるという技を編み出してて、すごくよかったです。見てたんなら真似すればよかった！
  • - [@spikeolaf (金子さん)](https://twitter.com/spikeolaf) のRubyKaigiのようなめちゃtechな話で盛り上がった後にこの話するの、すごい緊張しました。両方ともRailsの話が出てこないのにこの温度差…面白かったですｗ
  • - また、今回題材になって下さった[@ukegawa](https://twitter.com/ukegawa) さん、ありがとうございました。<br>[FlyTeam](https://flyteam.jp)、[レイルラボ](https://raillab.jp)と、本当に素晴らしいサービスを作ってる方で、自分はうけがわさんに憧れてWebサービス作るようになったようなものでして、今回の発表を快く許可していただき、大変感謝しております。
  • - [航空ファン・飛行機利用者のためのサイト FlyTeam(フライチーム)](https://flyteam.jp/)
  • - [レイルラボ | RailLab](https://raillab.jp/)
  • Railsdm、[前回に引き続き](https://speakerdeck.com/ken_c_lo/falsendezainafalsetamefalsekonseputo-and-rogozuo-rishi-jian-jiang-zuo-feat-savanna-dot-io) 今回も発表させていただき、ありがとうございました！
  • 毎回、本当に素晴らしいイベントで、聴けた発表もどれも素晴らしくて、久しぶりの友達や、初めての方、ネットで知ってたけど初めてリアルで会えた方もいて、本当に楽しかったです。
  • また、色んな方から発表へのフィードバックもいただけたのもよかったです。
  • 改めて、主催のカルパスさんをはじめスタッフの方々、講演者の方々、お会いできた方々、ありがとうございました！
  • [ハッカーズチャンプルー](https://docs.esa.io/posts/275)、Railsdmと素晴らしいイベントで立て続けに出させていただけて、とても楽しく幸せでした。
  • 柄にもなく外向きの発表が続いたので、しばらくは家に籠もってesaの開発を粛々と進める毎日を送りたいと思います( ⁰⊖⁰)"
  • 暑いしな。

はー、暑いですね。 デザイナーの @ken_c_lo です。
先日開催された、『Rails Developers Meetup 2018 Day 3 Extreme』 というイベントで、発表してきましたのでご報告エントリです。というイベントで、発表してきましたのでご報告エントリです。（今回esaの話はほとんど出てきませんmm）

エンジニアのためのスライドデザイン実践講座 / How to design presentations for engineers - Speaker Deck

Q&A（補足）

Railsdmには、AMAというQ&Aサービスが主催の @yhirano55 さんにより用意していただいており、こちらにいただいたご質問にお答えしていくとともに、また懇親会などでいただいたご質問などにもお答えして、スライドの補足にしたいと思います。

[Day 3: B-18] エンジニアのためのスライドデザイン実践講座 | AMA

Q: 吹き出しを並べて書いた時によく、中の文字数によっては吹き出しの大きさが変わってしまうことがあるんですが、その場合は文字が小さくなってでも吹き出しの大きさを統一した方がいいですか？
中の文字としては最低でも何 pt ぐらいみたいなコツもあれば教えていただきたいです。

ふきだしを使うシチュエーションによっても変わってきそうですね。

例えば対比を表すためにふきだしを2つ並べた時なんかは、大きさを統一するとともに、中の文字数もなるべく近くして、似たフォーマットにした方が対比がわかりやすくなって良いと思います。 （ →スライド27ページのような感じです）

一方、個別に説明したいことがあって、ふきだしを使っている場合は、特にふきだしの大きさを合わせなくてもよいと思います。 （→スライド60ページのような感じです）

文字の大きさは、使い方によって相対的に変わってきそうなので、今回ちょっと明確な言及を避けてしまったのですがmm 、例えば スライド60ページ のような状況でしたら、20ptくらい…、最小でも16ptくらいがよいかなあと思います。

Q: タイトルの文字の両端を揃えるとバランスが取れると仰ってましたが、そのデザインに合わせてタイトルの文字数などを調整するものですか？

はい、タイトルの文字数を調整することもありますし、文字の大きさを調整してピッシリ合うように調整することも多いです。 また、触れるの忘れましたが、キリのよいところで改行するというのも大事ですね。

Q: 情報整理を行う上で、参考になった本はありますか？（会場での質問）

デザイン仕事に必ず役立つ 図解力アップドリル | 原田 泰 |本 | 通販 | Amazon

よい本でした。デザインにおける色んな表現方法のバリエーションやそれぞれの考え方を丁寧に掘り下げて解説しています。意図や考え方を的確にデザインに反映させるために、役立つ知識になると思います。
帯やタイトルにはデザイナー向けと書いてあり、確かにデザイナーにも役に立つ内容だと思うのですが、ノンデザイナーやエンジニアにとっても、デザインとはどういうものなのか？を理解するためのよい内容になっていると思いました。

今日からはじめる情報設計 -センスメイキングするための7ステップ | アビー・コバート, 長谷川敦士, 安藤 幸央 |本 | 通販 | Amazon

情報設計する時に考えるべきことを、かなり上位の前提の段階から、概念的にわかりやすく整理して教えてくれる本でした。いい本でした。

（すみません、会場で『みんなではじめる情報設計』って言ってしまったんですが、書名間違えてました。。『みんなではじめるデザイン批評』と多分混ざりましたmm）

Q: コードをスライド中で紹介する時に、小さくなってしまいがち。こういう時によいプラクティスありますか？（会場での質問）

そういえば、コード出てこなくてごめんなさいmm
考えられる対策としては

  • なるべく文字が大きく見えるように貼る
  • 強調したい部分の文字列を拡大する
  • 今説明してるコードの現在位置がわからなくて説明しづらいという問題について、スライドのコードの中にリアルタイムで線を引きながら解説するということをやってる人がいて、とてもわかりやすいなーと思った記憶があるんですが、あれはなんのツールを使ってたのか思い出せませんでした…mm
    • コードの中の、今言及している現在位置にハイライト入れながら説明するのは普通によさそうだし、コードじゃなくても有効そうです。今度試してみよう。

Q: 赤塚さんがどのように情報設計を学んだのか知りたくなりました。

これに答えるべく、連休の間自分の人生を振り返って考えてたんですが、コレっていう答えが見つからず…自分の事はよくわからないものだなあ。。

おそらくは、デザイナーになって最初に入った職場の体験が大きいのかなあと思っております。 最初の職場はWebではない、少人数のデザイン事務所で冊子やパンフレットやポスターなんかのデザインを主にやってたんですが、回りの先輩たちがみんな優秀だったのでそのアウトプットを見て学んだところが大きいです。

あと、その職場では、デザインと同時にプレゼン企画書を作ってて、例えば会社案内のような冊子ものだと台割りとかコンテンツ企画とかも自分で考えて、企画書を作り込んでデザインカンプと一緒にプレゼンするということをやってたんですが、そのへんの体験が情報設計とデザインの両輪を理解する上で、糧になっている気がします。（プレゼンのトークは社長や広告代理店の人がやってくれたので、トーク力は上がりませんでした。）

あと、デザイナー同士でレビューし合うという習慣があったのも大きいかもしれません。必ず誰かに何回か見てもらって、文字校正をはじめ、揃っていない箇所とかを指摘し合うということを日常的にやってました。

自分は割とクラシカルな「師匠の背中を見て育つ」的な職人的な徒弟制っぽい世界で育った人間だと思うんですが、今は若くても優秀な方がたくさんいて、知の高速道路を感じて大変眩しいです。
そんなご時世に、「どうやったらデザインができるようになるんですか？」という質問に対して、「先輩の背中を見て育て」「修行！」みたいなのもなんかすごい老害っぽいので言いたくないんですよねえ。しかしじゃあ何が言えるんだろうというところで、まだこれといった答えが出ず… 本なども読んで学びつつ日々模索中ですmm

Q: Presentation Zen などでは、このように話す情報を全部スライドに書くようなスタイルは明確に否定されているんですよね。（懇親会での言及）

そうなんですよねえ。。
もともと自分が、しゃべるのがすごく苦手で、資料に全部しゃべることを書かないとしゃべれない、Presentation Zenやジョブズみたいなカッコイイプレゼンスタイルが真似できない…という悩みから、仕方なくこういうやり方をしていました。

しかし、いざWebで公開してみると、しゃべるべきことがスライドに全部書いてあるので、リアルタイムで見ていない人にもスライド単体で伝えることができるということから、意外と「わかりやすい」と評価をいただけたりしたので、今回はそのやり方を紹介させていただこうという趣旨でした。
えらそうな主語のでかいタイトルつけちゃったせいで誤解を招いてしまったかもしれませんが、決してこのやり方が正解ということはなく、1つのやり方として捉えていただければ幸いです。

しかし、Webに資料を広く公開することが前提になったせいで、従来タブーとされていたやり方がそれなりに有効になってきたというのは、面白い現象だなあと思っております。
あと、しゃべりやすさという面で言うと、この方法は確かにイマイチなので、今後そのへんをもっと改善していきたいと思っております。

Q: 聞いてて「なるほど」と思ったけど、いざ自分がやってみたらうまく真似できそうにない。やりすぎたりしてしまいそう。（懇親会での言及）

そうなんですよねえ。。
バランス感覚の部分に関しては、こうすればできるよ！といった回答が難しくて、何度もやってみて失敗を繰り返して学んだりするしかないのかもしれません。また、識者からレビューされたりするのもよさそう。
エンジニアの方々は、情報設計はむしろ専門分野なのでよくできる方がほとんどなのではないかと思っており、それをデザイン的に落とす時の引き出しを多く知っていればできてしまいそうな気もしています。
写経のように、既存の良いデザインをトレースして作ってみるというのも有効かもしれません。
また、個人的にオススメしたいのが、ただトレースするだけではなく、自分のオリジナルの目的に適用しつつ既存のものを真似してみるということです。これをやってみると、既存の良いものの背景にある意図などがわかってきたり、また応用力もついてきそうです。

感想や反省など

  • 今回、主催の@yhirano55 さんからよいお題をいただき、今回の発表をすることができました。
    お話をいただいた時は、「そもそも自分の資料そんなにいいかなー？」とか、「そもそもエンジニアさんプレゼン資料上手い人多いしなー」…とか色々不安もあったのですが、よい感じに受け入れられてほっとしております。
    • ズルいデザイン とかもそうだったんですが、自分がこれ発表したい！と思っていることよりも、大して自分は言いたいと思ってなかったけど他人から求められて発表するものの方が世間的によく受け入れられることが多いので、改めて面白いなあと思いました。
    • よいテーマをいただき、ありがとうございました！
  • 今回のテーマで発表してみて、個人的にも色々と発見がありました。特に、スライドの中でも言いましたが、人のスライドを直すのはとてもやりやすいというのが改めて面白かったです。
    • スライドの内容を書き出すのと、スライドデザインは別の工程でやるように、普段からしているつもりではあったんですが、自分のスライドだと、いざスライドデザインしようという段階になると、そこでまた内容に対して悩んでしまったり、するんですよねえ。。
    • 画面を作る前に内容をちゃんと固めて、デザインするときはなるべく客観的な視点を持つようにしたいと改めて感じました。
  • 発表のとき、指を指しながら説明することが多かったので、レーザーポインターとか持ってくればよかったなあ…。もしくは指差しのいらないプレゼンにしたい。
  • AMA、よいシステムなので発表の事前からもっと活用すればよかったなあと思いました。あらかじめAMAを通じて聴きたいことを募ってから、それを発表に反映するようなやり方も面白そうです。
    • 今回は、@yu_suke1994 (うなすけさん)が事前からうまくAMAを活用されてて、TwitterにAMAのURLを投げて質問を募ったり、また発表の補足として、自分でAMAに質問を投げるという技を編み出してて、すごくよかったです。見てたんなら真似すればよかった！
  • @spikeolaf (金子さん) のRubyKaigiのようなめちゃtechな話で盛り上がった後にこの話するの、すごい緊張しました。両方ともRailsの話が出てこないのにこの温度差…面白かったですｗ
  • また、今回題材になって下さった@ukegawa さん、ありがとうございました。
    FlyTeam、レイルラボと、本当に素晴らしいサービスを作ってる方で、自分はうけがわさんに憧れてWebサービス作るようになったようなものでして、今回の発表を快く許可していただき、大変感謝しております。

Railsdm、前回に引き続き 今回も発表させていただき、ありがとうございました！
毎回、本当に素晴らしいイベントで、聴けた発表もどれも素晴らしくて、久しぶりの友達や、初めての方、ネットで知ってたけど初めてリアルで会えた方もいて、本当に楽しかったです。
また、色んな方から発表へのフィードバックもいただけたのもよかったです。
改めて、主催のカルパスさんをはじめスタッフの方々、講演者の方々、お会いできた方々、ありがとうございました！

ハッカーズチャンプルー、Railsdmと素晴らしいイベントで立て続けに出させていただけて、とても楽しく幸せでした。
柄にもなく外向きの発表が続いたので、しばらくは家に籠もってesaの開発を粛々と進める毎日を送りたいと思います( ⁰⊖⁰)"
暑いしな。

はー、暑いですね。 デザイナーの [@ken_c_lo](https://twitter.com/ken_c_lo) です。
先日開催された、『[Rails Developers Meetup 2018 Day 3 Extreme](https://techplay.jp/event/679666)』 というイベントで、発表してきましたのでご報告エントリです。（今回esaの話はほとんど出てきませんmm）

<script async class="speakerdeck-embed" data-id="4ce2d11c8e4944fa924f2201b13df89e" data-ratio="1.33333333333333" src="//speakerdeck.com/assets/embed.js"></script>

[エンジニアのためのスライドデザイン実践講座 / How to design presentations for engineers - Speaker Deck](https://speakerdeck.com/ken_c_lo/how-to-design-presentations-for-engineers)

## Q&A（補足）

Railsdmには、[AMA](http://railsdm.herokuapp.com/issues/76)というQ&Aサービスが主催の [@yhirano55](https://twitter.com/yhirano55) さんにより用意していただいており、こちらにいただいたご質問にお答えしていくとともに、また懇親会などでいただいたご質問などにもお答えして、スライドの補足にしたいと思います。

[[Day 3: B-18] エンジニアのためのスライドデザイン実践講座 | AMA](http://railsdm.herokuapp.com/issues/76)

### Q: 吹き出しを並べて書いた時によく、中の文字数によっては吹き出しの大きさが変わってしまうことがあるんですが、その場合は文字が小さくなってでも吹き出しの大きさを統一した方がいいですか？ <br>中の文字としては最低でも何 pt ぐらいみたいなコツもあれば教えていただきたいです。

ふきだしを使うシチュエーションによっても変わってきそうですね。

例えば対比を表すためにふきだしを2つ並べた時なんかは、大きさを統一するとともに、中の文字数もなるべく近くして、似たフォーマットにした方が対比がわかりやすくなって良いと思います。 （ [→スライド27ページのような感じです](https://speakerdeck.com/ken_c_lo/how-to-design-presentations-for-engineers?slide=27)）

一方、個別に説明したいことがあって、ふきだしを使っている場合は、特にふきだしの大きさを合わせなくてもよいと思います。 （[→スライド60ページのような感じです]( https://speakerdeck.com/ken_c_lo/how-to-design-presentations-for-engineers?slide=60)）

文字の大きさは、使い方によって相対的に変わってきそうなので、今回ちょっと明確な言及を避けてしまったのですがmm 、例えば [スライド60ページ](https://speakerdeck.com/ken_c_lo/how-to-design-presentations-for-engineers?slide=60) のような状況でしたら、20ptくらい…、最小でも16ptくらいがよいかなあと思います。

### Q: タイトルの文字の両端を揃えるとバランスが取れると仰ってましたが、そのデザインに合わせてタイトルの文字数などを調整するものですか？

はい、タイトルの文字数を調整することもありますし、文字の大きさを調整してピッシリ合うように調整することも多いです。 また、触れるの忘れましたが、キリのよいところで改行するというのも大事ですね。

### Q: 情報整理を行う上で、参考になった本はありますか？（会場での質問）

[デザイン仕事に必ず役立つ 図解力アップドリル | 原田 泰 |本 | 通販 | Amazon](https://www.amazon.co.jp/dp/4862670903)

よい本でした。デザインにおける色んな表現方法のバリエーションやそれぞれの考え方を丁寧に掘り下げて解説しています。意図や考え方を的確にデザインに反映させるために、役立つ知識になると思います。
帯やタイトルにはデザイナー向けと書いてあり、確かにデザイナーにも役に立つ内容だと思うのですが、ノンデザイナーやエンジニアにとっても、デザインとはどういうものなのか？を理解するためのよい内容になっていると思いました。

[今日からはじめる情報設計 -センスメイキングするための7ステップ | アビー・コバート, 長谷川敦士, 安藤 幸央 |本 | 通販 | Amazon](https://www.amazon.co.jp/dp/4802510012/)

情報設計する時に考えるべきことを、かなり上位の前提の段階から、概念的にわかりやすく整理して教えてくれる本でした。いい本でした。

（すみません、会場で『みんなではじめる情報設計』って言ってしまったんですが、書名間違えてました。。『みんなではじめるデザイン批評』と多分混ざりましたmm）

### Q: コードをスライド中で紹介する時に、小さくなってしまいがち。こういう時によいプラクティスありますか？（会場での質問）

そういえば、コード出てこなくてごめんなさいmm
考えられる対策としては

- なるべく文字が大きく見えるように貼る
- 強調したい部分の文字列を拡大する
- 今説明してるコードの現在位置がわからなくて説明しづらいという問題について、スライドのコードの中にリアルタイムで線を引きながら解説するということをやってる人がいて、とてもわかりやすいなーと思った記憶があるんですが、あれはなんのツールを使ってたのか思い出せませんでした…mm
    - コードの中の、今言及している現在位置にハイライト入れながら説明するのは普通によさそうだし、コードじゃなくても有効そうです。今度試してみよう。

### Q: 赤塚さんがどのように情報設計を学んだのか知りたくなりました。

これに答えるべく、連休の間自分の人生を振り返って考えてたんですが、コレっていう答えが見つからず…自分の事はよくわからないものだなあ。。

おそらくは、デザイナーになって最初に入った職場の体験が大きいのかなあと思っております。 最初の職場はWebではない、少人数のデザイン事務所で冊子やパンフレットやポスターなんかのデザインを主にやってたんですが、回りの先輩たちがみんな優秀だったのでそのアウトプットを見て学んだところが大きいです。

あと、その職場では、デザインと同時にプレゼン企画書を作ってて、例えば会社案内のような冊子ものだと台割りとかコンテンツ企画とかも自分で考えて、企画書を作り込んでデザインカンプと一緒にプレゼンするということをやってたんですが、そのへんの体験が情報設計とデザインの両輪を理解する上で、糧になっている気がします。（プレゼンのトークは社長や広告代理店の人がやってくれたので、トーク力は上がりませんでした。）

あと、デザイナー同士でレビューし合うという習慣があったのも大きいかもしれません。必ず誰かに何回か見てもらって、文字校正をはじめ、揃っていない箇所とかを指摘し合うということを日常的にやってました。

自分は割とクラシカルな「師匠の背中を見て育つ」的な職人的な徒弟制っぽい世界で育った人間だと思うんですが、今は若くても優秀な方がたくさんいて、知の高速道路を感じて大変眩しいです。
そんなご時世に、「どうやったらデザインができるようになるんですか？」という質問に対して、「先輩の背中を見て育て」「修行！」みたいなのもなんかすごい老害っぽいので言いたくないんですよねえ。しかしじゃあ何が言えるんだろうというところで、まだこれといった答えが出ず… 本なども読んで学びつつ日々模索中ですmm

### Q: Presentation Zen などでは、このように話す情報を全部スライドに書くようなスタイルは明確に否定されているんですよね。（懇親会での言及）

そうなんですよねえ。。
もともと自分が、しゃべるのがすごく苦手で、資料に全部しゃべることを書かないとしゃべれない、Presentation Zenやジョブズみたいなカッコイイプレゼンスタイルが真似できない…という悩みから、仕方なくこういうやり方をしていました。

しかし、いざWebで公開してみると、しゃべるべきことがスライドに全部書いてあるので、リアルタイムで見ていない人にもスライド単体で伝えることができるということから、意外と「わかりやすい」と評価をいただけたりしたので、今回はそのやり方を紹介させていただこうという趣旨でした。
えらそうな主語のでかいタイトルつけちゃったせいで誤解を招いてしまったかもしれませんが、決してこのやり方が正解ということはなく、1つのやり方として捉えていただければ幸いです。

しかし、Webに資料を広く公開することが前提になったせいで、従来タブーとされていたやり方がそれなりに有効になってきたというのは、面白い現象だなあと思っております。
あと、しゃべりやすさという面で言うと、この方法は確かにイマイチなので、今後そのへんをもっと改善していきたいと思っております。

### Q: 聞いてて「なるほど」と思ったけど、いざ自分がやってみたらうまく真似できそうにない。やりすぎたりしてしまいそう。（懇親会での言及）

そうなんですよねえ。。
バランス感覚の部分に関しては、こうすればできるよ！といった回答が難しくて、何度もやってみて失敗を繰り返して学んだりするしかないのかもしれません。また、識者からレビューされたりするのもよさそう。
エンジニアの方々は、情報設計はむしろ専門分野なのでよくできる方がほとんどなのではないかと思っており、それをデザイン的に落とす時の引き出しを多く知っていればできてしまいそうな気もしています。
写経のように、既存の良いデザインをトレースして作ってみるというのも有効かもしれません。
また、個人的にオススメしたいのが、ただトレースするだけではなく、自分のオリジナルの目的に適用しつつ既存のものを真似してみるということです。これをやってみると、既存の良いものの背景にある意図などがわかってきたり、また応用力もついてきそうです。

## 感想や反省など

- 今回、主催の[@yhirano55](https://twitter.com/yhirano55) さんからよいお題をいただき、今回の発表をすることができました。<br>お話をいただいた時は、「そもそも自分の資料そんなにいいかなー？」とか、「そもそもエンジニアさんプレゼン資料上手い人多いしなー」…とか色々不安もあったのですが、よい感じに受け入れられてほっとしております。
    - [ズルいデザイン](https://speakerdeck.com/ken_c_lo/zurui-design) とかもそうだったんですが、自分がこれ発表したい！と思っていることよりも、大して自分は言いたいと思ってなかったけど他人から求められて発表するものの方が世間的によく受け入れられることが多いので、改めて面白いなあと思いました。
    - よいテーマをいただき、ありがとうございました！
- 今回のテーマで発表してみて、個人的にも色々と発見がありました。特に、スライドの中でも言いましたが、人のスライドを直すのはとてもやりやすいというのが改めて面白かったです。
    - スライドの内容を書き出すのと、スライドデザインは別の工程でやるように、普段からしているつもりではあったんですが、自分のスライドだと、いざスライドデザインしようという段階になると、そこでまた内容に対して悩んでしまったり、するんですよねえ。。
    - 画面を作る前に内容をちゃんと固めて、デザインするときはなるべく客観的な視点を持つようにしたいと改めて感じました。
- 発表のとき、指を指しながら説明することが多かったので、レーザーポインターとか持ってくればよかったなあ…。もしくは指差しのいらないプレゼンにしたい。
- [AMA](http://railsdm.herokuapp.com/issues/76)、よいシステムなので発表の事前からもっと活用すればよかったなあと思いました。あらかじめAMAを通じて聴きたいことを募ってから、それを発表に反映するようなやり方も面白そうです。
    - 今回は、[@yu_suke1994 (うなすけさん)](https://twitter.com/yu_suke1994)が事前からうまくAMAを活用されてて、TwitterにAMAのURLを投げて質問を募ったり、また発表の補足として、自分でAMAに質問を投げるという技を編み出してて、すごくよかったです。見てたんなら真似すればよかった！
- [@spikeolaf (金子さん)](https://twitter.com/spikeolaf) のRubyKaigiのようなめちゃtechな話で盛り上がった後にこの話するの、すごい緊張しました。両方ともRailsの話が出てこないのにこの温度差…面白かったですｗ
- また、今回題材になって下さった[@ukegawa](https://twitter.com/ukegawa) さん、ありがとうございました。<br>[FlyTeam](https://flyteam.jp)、[レイルラボ](https://raillab.jp)と、本当に素晴らしいサービスを作ってる方で、自分はうけがわさんに憧れてWebサービス作るようになったようなものでして、今回の発表を快く許可していただき、大変感謝しております。
    - [航空ファン・飛行機利用者のためのサイト FlyTeam(フライチーム)](https://flyteam.jp/)
    - [レイルラボ | RailLab](https://raillab.jp/)


Railsdm、[前回に引き続き](https://speakerdeck.com/ken_c_lo/falsendezainafalsetamefalsekonseputo-and-rogozuo-rishi-jian-jiang-zuo-feat-savanna-dot-io) 今回も発表させていただき、ありがとうございました！
毎回、本当に素晴らしいイベントで、聴けた発表もどれも素晴らしくて、久しぶりの友達や、初めての方、ネットで知ってたけど初めてリアルで会えた方もいて、本当に楽しかったです。
また、色んな方から発表へのフィードバックもいただけたのもよかったです。
改めて、主催のカルパスさんをはじめスタッフの方々、講演者の方々、お会いできた方々、ありがとうございました！

[ハッカーズチャンプルー](https://docs.esa.io/posts/275)、Railsdmと素晴らしいイベントで立て続けに出させていただけて、とても楽しく幸せでした。
柄にもなく外向きの発表が続いたので、しばらくは家に籠もってesaの開発を粛々と進める毎日を送りたいと思います( ⁰⊖⁰)" 
暑いしな。

はー、暑いですね。 デザイナーの @ken_c_lo です。
先日開催された、『Rails Developers Meetup 2018 Day 3 Extreme』 というイベントで、発表してきましたのでご報告エントリです。（今回esaの話はほとんど出てきませんmm）

エンジニアのためのスライドデザイン実践講座 / How to design presentations for engineers - Speaker Deck

Q&A（補足）

Railsdmには、AMAというQ&Aサービスが主催の @yhirano55 さんにより用意していただいており、こちらにいただいたご質問にお答えしていくとともに、また懇親会などでいただいたご質問などにもお答えして、スライドの補足にしたいと思います。

[Day 3: B-18] エンジニアのためのスライドデザイン実践講座 | AMA

Q: 吹き出しを並べて書いた時によく、中の文字数によっては吹き出しの大きさが変わってしまうことがあるんですが、その場合は文字が小さくなってでも吹き出しの大きさを統一した方がいいですか？
中の文字としては最低でも何 pt ぐらいみたいなコツもあれば教えていただきたいです。

ふきだしを使うシチュエーションによっても変わってきそうですね。

例えば対比を表すためにふきだしを2つ並べた時なんかは、大きさを統一するとともに、中の文字数もなるべく近くして、似たフォーマットにした方が対比がわかりやすくなって良いと思います。 （ →スライド27ページのような感じです）

一方、個別に説明したいことがあって、ふきだしを使っている場合は、特にふきだしの大きさを合わせなくてもよいと思います。 （→スライド60ページのような感じです）

文字の大きさは、使い方によって相対的に変わってきそうなので、今回ちょっと明確な言及を避けてしまったのですがmm 、例えば スライド60ページ のような状況でしたら、20ptくらい…、最小でも16ptくらいがよいかなあと思います。

Q: タイトルの文字の両端を揃えるとバランスが取れると仰ってましたが、そのデザインに合わせてタイトルの文字数などを調整するものですか？

はい、タイトルの文字数を調整することもありますし、文字の大きさを調整してピッシリ合うように調整することも多いです。 また、触れるの忘れましたが、キリのよいところで改行するというのも大事ですね。

Q: 情報整理を行う上で、参考になった本はありますか？（会場での質問）

デザイン仕事に必ず役立つ 図解力アップドリル | 原田 泰 |本 | 通販 | Amazon

よい本でした。デザインにおける色んな表現方法のバリエーションやそれぞれの考え方を丁寧に掘り下げて解説しています。意図や考え方を的確にデザインに反映させるために、役立つ知識になると思います。
帯やタイトルにはデザイナー向けと書いてあり、確かにデザイナーにも役に立つ内容だと思うのですが、ノンデザイナーやエンジニアにとっても、デザインとはどういうものなのか？を理解するためのよい内容になっていると思いました。

今日からはじめる情報設計 -センスメイキングするための7ステップ | アビー・コバート, 長谷川敦士, 安藤 幸央 |本 | 通販 | Amazon

情報設計する時に考えるべきことを、かなり上位の前提の段階から、概念的にわかりやすく整理して教えてくれる本でした。いい本でした。

（すみません、会場で『みんなではじめる情報設計』って言ってしまったんですが、書名間違えてました。。『みんなではじめるデザイン批評』と多分混ざりましたmm）

Q: コードをスライド中で紹介する時に、小さくなってしまいがち。こういう時によいプラクティスありますか？（会場での質問）

そういえば、コード出てこなくてごめんなさいmm
考えられる対策としては

  • なるべく文字が大きく見えるように貼る
  • 強調したい部分の文字列を拡大する
  • 今説明してるコードの現在位置がわからなくて説明しづらいという問題について、スライドのコードの中にリアルタイムで線を引きながら解説するということをやってる人がいて、とてもわかりやすいなーと思った記憶があるんですが、あれはなんのツールを使ってたのか思い出せませんでした…mm
    • コードの中の、今言及している現在位置にハイライト入れながら説明するのは普通によさそうだし、コードじゃなくても有効そうです。今度試してみよう。

Q: 赤塚さんがどのように情報設計を学んだのか知りたくなりました。

これに答えるべく、連休の間自分の人生を振り返って考えてたんですが、コレっていう答えが見つからず…自分の事はよくわからないものだなあ。。

おそらくは、デザイナーになって最初に入った職場の体験が大きいのかなあと思っております。 最初の職場はWebではない、少人数のデザイン事務所で冊子やパンフレットやポスターなんかのデザインを主にやってたんですが、回りの先輩たちがみんな優秀だったのでそのアウトプットを見て学んだところが大きいです。

あと、その職場では、デザインと同時にプレゼン企画書を作ってて、例えば会社案内のような冊子ものだと台割りとかコンテンツ企画とかも自分で考えて、企画書を作り込んでデザインカンプと一緒にプレゼンするということをやってたんですが、そのへんの体験が情報設計とデザインの両輪を理解する上で、糧になっている気がします。（プレゼンのトークは社長や広告代理店の人がやってくれたので、トーク力は上がりませんでした。）

あと、デザイナー同士でレビューし合うという習慣があったのも大きいかもしれません。必ず誰かに何回か見てもらって、文字校正をはじめ、揃っていない箇所とかを指摘し合うということを日常的にやってました。

自分は割とクラシカルな「師匠の背中を見て育つ」的な職人的な徒弟制っぽい世界で育った人間だと思うんですが、今は若くても優秀な方がたくさんいて、知の高速道路を感じて大変眩しいです。
そんなご時世に、「どうやったらデザインができるようになるんですか？」という質問に対して、「先輩の背中を見て育て」「修行！」みたいなのもなんかすごい老害っぽいので言いたくないんですよねえ。しかしじゃあ何が言えるんだろうというところで、まだこれといった答えが出ず… 本なども読んで学びつつ日々模索中ですmm

Q: Presentation Zen などでは、このように話す情報を全部スライドに書くようなスタイルは明確に否定されているんですよね。（懇親会での言及）

そうなんですよねえ。。
もともと自分が、しゃべるのがすごく苦手で、資料に全部しゃべることを書かないとしゃべれない、Presentation Zenやジョブズみたいなカッコイイプレゼンスタイルが真似できない…という悩みから、仕方なくこういうやり方をしていました。

しかし、いざWebで公開してみると、しゃべるべきことがスライドに全部書いてあるので、リアルタイムで見ていない人にもスライド単体で伝えることができるということから、意外と「わかりやすい」と評価をいただけたりしたので、今回はそのやり方を紹介させていただこうという趣旨でした。
えらそうな主語のでかいタイトルつけちゃったせいで誤解を招いてしまったかもしれませんが、決してこのやり方が正解ということはなく、1つのやり方として捉えていただければ幸いです。

しかし、Webに資料を広く公開することが前提になったせいで、従来タブーとされていたやり方がそれなりに有効になってきたというのは、面白い現象だなあと思っております。
あと、しゃべりやすさという面で言うと、この方法は確かにイマイチなので、今後そのへんをもっと改善していきたいと思っております。

Q: 聞いてて「なるほど」と思ったけど、いざ自分がやってみたらうまく真似できそうにない。やりすぎたりしてしまいそう。（懇親会での言及）

そうなんですよねえ。。
バランス感覚の部分に関しては、こうすればできるよ！といった回答が難しくて、何度もやってみて失敗を繰り返して学んだりするしかないのかもしれません。また、識者からレビューされたりするのもよさそう。
エンジニアの方々は、情報設計はむしろ専門分野なのでよくできる方がほとんどなのではないかと思っており、それをデザイン的に落とす時の引き出しを多く知っていればできてしまいそうな気もしています。
写経のように、既存の良いデザインをトレースして作ってみるというのも有効かもしれません。
また、個人的にオススメしたいのが、ただトレースするだけではなく、自分のオリジナルの目的に適用しつつ既存のものを真似してみるということです。これをやってみると、既存の良いものの背景にある意図などがわかってきたり、また応用力もついてきそうです。

感想や反省など

  • 今回、主催の@yhirano55 さんからよいお題をいただき、今回の発表をすることができました。
    お話をいただいた時は、「そもそも自分の資料そんなにいいかなー？」とか、「そもそもエンジニアさんプレゼン資料上手い人多いしなー」…とか色々不安もあったのですが、よい感じに受け入れられてほっとしております。
    • ズルいデザイン とかもそうだったんですが、自分がこれ発表したい！と思っていることよりも、大して自分は言いたいと思ってなかったけど他人から求められて発表するものの方が世間的によく受け入れられることが多いので、改めて面白いなあと思いました。
    • よいテーマをいただき、ありがとうございました！
  • 今回のテーマで発表してみて、個人的にも色々と発見がありました。特に、スライドの中でも言いましたが、人のスライドを直すのはとてもやりやすいというのが改めて面白かったです。
    • スライドの内容を書き出すのと、スライドデザインは別の工程でやるように、普段からしているつもりではあったんですが、自分のスライドだと、いざスライドデザインしようという段階になると、そこでまた内容に対して悩んでしまったり、するんですよねえ。。
    • 画面を作る前に内容をちゃんと固めて、デザインするときはなるべく客観的な視点を持つようにしたいと改めて感じました。
  • 発表のとき、指を指しながら説明することが多かったので、レーザーポインターとか持ってくればよかったなあ…。もしくは指差しのいらないプレゼンにしたい。
  • AMA、よいシステムなので発表の事前からもっと活用すればよかったなあと思いました。あらかじめAMAを通じて聴きたいことを募ってから、それを発表に反映するようなやり方も面白そうです。
    • 今回は、@yu_suke1994 (うなすけさん)が事前からうまくAMAを活用されてて、TwitterにAMAのURLを投げて質問を募ったり、また発表の補足として、自分でAMAに質問を投げるという技を編み出してて、すごくよかったです。見てたんなら真似すればよかった！
  • @spikeolaf (金子さん) のRubyKaigiのようなめちゃtechな話で盛り上がった後にこの話するの、すごい緊張しました。両方ともRailsの話が出てこないのにこの温度差…面白かったですｗ
  • また、今回題材になって下さった@ukegawa さん、ありがとうございました。
    FlyTeam、レイルラボと、本当に素晴らしいサービスを作ってる方で、自分はうけがわさんに憧れてWebサービス作るようになったようなものでして、今回の発表を快く許可していただき、大変感謝しております。

Railsdm、前回に引き続き 今回も発表させていただき、ありがとうございました！
毎回、本当に素晴らしいイベントで、聴けた発表もどれも素晴らしくて、久しぶりの友達や、初めての方、ネットで知ってたけど初めてリアルで会えた方もいて、本当に楽しかったです。
また、色んな方から発表へのフィードバックもいただけたのもよかったです。
改めて、主催のカルパスさんをはじめスタッフの方々、講演者の方々、お会いできた方々、ありがとうございました！

ハッカーズチャンプルー、Railsdmと素晴らしいイベントで立て続けに出させていただけて、とても楽しく幸せでした。
柄にもなく外向きの発表が続いたので、しばらくは家に籠もってesaの開発を粛々と進める毎日を送りたいと思います( ⁰⊖⁰)"
暑いしな。