プレゼン・LTを「ちゃんとした1つの話」に仕立てる、5つの仕掛け達人ライトニングトーカーへの道(3)(1/2 ページ)

ライトニングトークをすると、これまで得られなかった気付きやノウハウを得られる。コミュニティとLTをこよなく愛するエンジニアによる「LT」解説

» 2012年08月06日 00時00分 公開
[嵩原將志@IT]

退屈なプレゼンの正体

 印象的なプレゼンテーションと退屈なプレゼンテーション、両者を分けるものは何でしょうか?

 まずは退屈なプレゼンテーションから考えてみましょう。事実を淡々と説明されて、聞き終わった後に「……で?」と感じてしまうと、退屈だと感じますね。

 こういう退屈なプレゼンテーションをしてしまう話し手自身は、退屈させようとは思っていません。ただ、「あれも伝えたい、これも伝えたい」といった思いに駆られて、知っていることを何でもかんでもスライドに放りこんでしまうだけです。しかし、これでは「とにかくすごい情報量でした!」という印象は残せても、内容は聞き手の印象には残りません。

 「結局、何が言いたかったの?」――おそらくこういう印象しか残せないでしょう。

では、説得力のあるプレゼンって?

 説得力のあるプレゼンテーションには、発表時間に関係なく、それ相応の情報量(トピック数)が必要であると、前回「初心者のためのLT作成講座――5分で収まるスライドを作る3つのTip.s」で説明しました。ただし多くの場合、トピックの関連性を理解しているのはスピーカー本人のみです。そこで、編集が重要になります。的確に編集を行い「ちゃんとした1つの話」にするのです。

 よくプレゼンのノウハウを説明する文章では、「物語性を持たせる」という言葉で紹介されています(個人的に、物語と言ってしまうとなにやら一大巨編みたいな感じがして気が引けてしまうので、私は「ちゃんとした1つの話にする」と表現しています)。

 とはいえ、「物語性が重要」「ストーリー性を持たせなさい」と言われても、具体的にどのようにして物語性を持たせればいいのでしょうか? 一般的には「起承転結」や「ホールパートホール」など、さまざまな手法がありますが、本記事ではもうちょっとシンプルに考えて「組み立て方」に共通するコツを解説します。

話の骨格を作る

 「ちゃんとした1つの話」は、以下の構成要素で組み立てます。

  1. 前フリ(伏線)

  2. 問題提起

  3. 解法パターン&伏線回収

  4. 聞き手への呼び掛け

  5. オチ

 それでは闇アジャイラーを例に1つ1つ解説します。以下のスライドを眺めながら記事を読み進めてください。

●1.前フリ(伏線) p.1.〜p.11

 前フリはスライドの1枚目から始まっています(参考)。某有名ロボットアニメの画像(一部違うものも含む)が10枚並んでいる画像は、ソフトウェア開発に携わる人の多くが見たことがある「タイヤのブランコ」画像のパロディです。

「タイヤのブランコ」の画像のパロディ 「タイヤのブランコ」の画像のパロディ

 この絵は、コミュニケーションエラーが原因で生まれる、ソフトウェア開発の失敗パターンを説明しており、これから話す内容の方向性を匂わせています。

 次に「闇プログラマー」を取り上げます。闇プログラマーが何者であるかという説明はあえて割愛しますが、彼はITや著作権について大きな誤解をしており、ソーシャルメディア上で多くの人から忠告を受けたにもかかわらず、自身の過失を認めず、不遜な態度を取り続けた結果、周囲との間に軋れきを生み、炎上を招きました。

闇プログラマー 闇プログラマー

 以上のように、ここでは「失敗」「コミュニケーション・エラー」といったネガティブな情報を配置しています。悪い兆候があることを聞き手に感じてもらうことが狙いです。

 そして「闇アジャイラー」という、キャッチーなタイトルで聞き手の興味を一気に釣り上げます。「闇アジャイラー」は、ソフトウェア開発における良くない慣行を片っ端から体現する架空の人物として作りました。当然、モデルになった人物は存在しません。

●2. 問題提起 p.12〜p.42

 前フリで得た「聞き手の感情の変化」をさらに深化させ、「強力な共感」を得るのが、ここでの狙いです。

 「闇アジャイラー」はソフトウェア開発における良くない慣行を体現する人でなので、実態を手っ取り早く伝えるため「アジャイルソフトウェアの12の原則」のアンチパターンを作って紹介しました。

 わざと「アジャイルソフトウェアの12の原則」を端折ったり曲解することで、短絡的で目先のことしか考えない人を想起するようにしています。聞き手に「あるある……」とか「ひどいわこれはー」といった感想をもってもらえれば、目的達成です。

 なお、このLTでは4つしか紹介していませんが、実際には12つ作りました。時間制約はもちろんですが、12つを並べてもくどいので、4つに減らしました。もちろん、この4つの闇原則の並び順にもちゃんと狙いがあります。

  • 1つ目:アジャイルに対する盲信
  • 2つ目:目的の履き違え
  • 3つ目:間違った独自運用
  • 4つ目:独自運用の結果

 個条書きの項目を説明する際、順番に気を使うかどうかで、聞き手の理解しやすさが大きく変わります。「自然に、違和感なく話がつながっているか」が重要です。

 続いて、p.20からはじまる「【図解】闇アジャイラーが生まれるまで」。ここでは、コミュニケーション・エラーが引き起こす悲劇をパラパラ漫画ライクに説明をしています。問題提起をしつつ、問題個所の特定を行っています。これは、次に続く「3. 解法」の説明がスムーズに行えるための準備です。

【図解】闇アジャイラーが生まれるまで 【図解】闇アジャイラーが生まれるまで

 図の中心に赤くモヤモヤとした「いろいろな要求とか」と緑色の矩形の「文書化されたモノゴト、完了したモノゴト」を配置しています。よく「見積もりミス」や「過小見積もり」がプロジェクト炎上の原因になりますが、つまりは「見積もる対象のミス」です。

 「決まっていないこと」「あいまいなこと」をいかにコントロールするかという、リスク・マネジメントの話なのですが、ここらへんをおざなりにすると、後になって「言った・言わない」の揉めごとにつながることが多いようです。

 「闇アジャイラー」のスライドに登場する人たちは「もっとベンダをこき使え!」とか、助けを求められても「だが断る」と言って無慈悲で無責任なように見えるかもしれませんが、彼らは彼らなりに良かれと思ってやっています。ただ、その顛末が全員そろって「みんな死ぬまで働けばいいんだ!」という実に不幸な結論を導き出します。

闇アジャイラー爆誕! 闇アジャイラー爆誕!

 もちろん、ここで紹介をした「闇アジャイラー原則」も「【図解】闇アジャイラーが生まれるまで」も、聞き手に炎上プロジェクトを分かりやすく伝えるために作り出した架空のプロジェクトです。当然、モデルになったプロジェクトなど存在しません。

       1|2 次のページへ

Copyright © ITmedia, Inc. All Rights Reserved.

スポンサーからのお知らせPR

注目のテーマ

Microsoft & Windows最前線2025
AI for エンジニアリング
ローコード/ノーコード セントラル by @IT - ITエンジニアがビジネスの中心で活躍する組織へ
Cloud Native Central by @IT - スケーラブルな能力を組織に
システム開発ノウハウ 【発注ナビ】PR
あなたにおすすめの記事PR

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。