人生のスナップショット

この記事は pyspa Advent Calendar 2017の22日目の記事です。前日は
資産運用に取り組み始めた - YAMAGUCHI::weblog
でした。

pyspa-botは、Mersenne Twisterという、世界的に実績がある、非常に有名なアルゴリズムをエンジンとして動作する人工知能プログラムです。

語録コマンドを実行すると、過去に登録されたその人の発言を、botエンジンがランダムに1つピックアップして返してきます。
要するにただのrandomコマンドです。

語録の登録における不文律として、「自分以外の人が登録する」というものがあります。絶対ではありませんし、自分で登録するケースもゼロではありませんが、非常に少ないです。
これが何を意味するかというと、語録には常に、「その当人以外の周りの人にとって心に残ったその人の言葉が登録される」のです。
実際語録を開いてみると、その人の声や顔が鮮明に思い浮かべられるくらい、まさにその人という語録ばかりが並んでいます。
その言葉が、その人の生きている姿を鮮明に映し出すのです。

botは、人生のスナップショットなのです。

pyspa Advent Calendar 参加者 + bot作者の moriyoshi の語録から一つピックアップして紹介しましょう。
公開しても問題なさそうなものだけピックアップしていますので、実際にはもっと個人的なネタやNSFWなネタもあります。
語録が存在しない、あるいは上記のような語録しか存在せず公開できない人は載せていません。

moriyoshi

ケツの穴にバリカン突っ込んで複雑な痔にしてやりたい

wozozo

なんか屁がめっちゃくさい...

tokibito

笑ってられるうちはデスマじゃないと思う

torufurukawa

最もイタリア人っぽい男は・・・俺かな

akisute

どうも四時からワイドの男あきすてです

flag_boy

pyspaには真理しかないよ

voluntas

wozozo が焼き肉をおごる会まだー

aodag

デスマかも?なんて思ってるときはデスマじゃないのさ

tokoroten

共有フォルダ+Excelで管理しようとしたPMは更迭した。

mururu

ぼくをツモりましょう

taichi

俺なんて3DS何台買ったと思ってんだ。4台だぞ。

kuenishi

おいしまうち、これ買ってこい

isoparametric

にしおかどうかは主観だから、俺がそう思うんならお前はにしおなんだろう、俺の中ではな

drillbits

みんなちがってみんなジャバ

turky

以前、一番嫌な死因について考えた結果、じわじわと圧死が一番嫌という結論になりました。

nikuyoshi

危ない橋は渡ったことないので…

cocoatomo

今日, ふと思ったんだけど, 俺無職になったらそのままダラダラ無職続けてしまいそう

mopemope

卒業とか勝手なこと言ってるけど、もうみんなとっくに卒業してんだよ!!気づけ!マヌケ!

takabow

今日も新橋です

ymotongpoo

素直に「ションベン漏らした!!」っていえよ!!!!

shibu_jp

マイ・リトル・ポニーを見ている方がよっぽど有意義というものだ。

chezou

残念ながらソフトクリーム食べながらR書いてます

hiroki.niinuma.5

肩がこった?いいのかい?俺が本気で揉んじまって

shiumachi

最後に、私の語録からも一つ紹介しましょう。

bot人工知能じゃない!神なんだよ!


明日は shibu_jp です。

楽天テクノロジーカンファレンス2017でApache Kuduについて発表してきた

楽天テクノロジーカンファレンスに登壇するという貴重な機会をいただいたので、Apache Kuduについて発表してきました。

主催していただいた楽天様、ご聴講いただいた皆様、ありがとうございました。


社外での英語プレゼンだったのでなかなか準備が大変でした。

以下、補足やFAQです。

これ資料英語なんだけど日本語はないの?


この資料そのものの日本語スライドはありませんが、より詳しいスライドが日本語で公開されています。

資料読むのだるいからKuduについて3行でまとめて

  • Kuduは、HDFS みたいなシーケンシャルリードの性能と、低レイテンシでのランダムアクセスや更新・挿入が得意なHBaseのようなNoSQLの長所を合わせ持った、新しいOSSのストレージエンジンだよ!
  • Kuduを使うと、ラムダアーキテクチャのようなバッチ処理 + ストリーミング処理や、分析クエリ + 更新処理みたいな、今まで複数のコンポーネントを組み合わせないと作れなかったようなシステムがこれ一つでできるよ!
  • Kuduの使い道の代表例としては、IoTなどにおけるセンサーデータのリアルタイム分析や、金融ティックデータ分析などのリアルタイムダッシュボード、UPDATE/INSERT文を含む既存DWHからのオフロード・マイグレーションなどがあるよ!(参考)

KuduあればHDFSやHBaseいらなくない?


Kuduはどちらの特徴も備えていますが、性能的にはどちらについても若干劣ります。よって、HDFSやHBaseだけで足りる用途であればそちらを使った方がいいです。

また、Kuduは型を必ず持つので、型を考えずにとりあえず突っ込んでおきたいという場合には適しません。

HDFSAmazon S3、Azure Data Lake Store のような中央ストレージを持ちつつ、補完のためにKuduを活用していくといいでしょう。

Kuduの性能評価結果を教えて


日本語スライドとしては2015年のスライドのこのページに一応載っていますがちょっと情報古いです。

2017年2月に公開されたCERNによる性能評価が一番新しいと思います。

まとめ

Kuduはリリースされてから2年ほど経って、かなり色々こなれてきた感じがしています。
便利なのでガンガン使っていきましょう!

Kuduについて日本語でもセッション聞きたいという人は、11/7(火)に開催されるCloudera World Tokyo 2017に来てください。私とは別の切り口でのKuduのセッションがあります。

ブラウザ上で簡単にビッグデータを扱えるOSS: Hue についての簡単な紹介

ドワンゴさんの主催でHue Meetupが開催されることになったので、いい機会だから Hue について、自分の復習がてらまとめておきます。

Hue って何?

Hadoopエコシステムを操作するためのWebインタフェースです。
Hadoopエコシステムの多くは、管理Web UIは持っていても、ユーザ用のWeb UIはありません。
ユーザがターミナルからコマンドを叩かなくてもHadoopエコシステムを操作できるようにするのが目的です。
主に、以下のようなことができます。

  • ファイルをアップロードしたり、編集したり、ダウンロードしたりできる
  • SQLを書いて実行したり、SQLを共有できる
  • DBのテーブルを管理できる
  • ジョブ実行のワークフローを作って実行したり、スケジュール実行できる
  • 検索エンジン用のダッシュボードを作成できる

Hueは Apache License のオープンソースです。
詳しくは以下のサイトを見ましょう。

Hue は誰が使っているの?

Hueは、全ての主要なHadoopディストリビューションに含まれているので、Hadoop触っている人は意識せずとも使ったことある人も多いと思います。


あと、Amazon Athena の UI は間違いなく Hue です。

先日、あるお客様のところに製品紹介にいったときにHueを見せたら、「Athenaみたいですね」と言われました。逆ですから!

EMR Hue の話は、Hue Meetup でミクシィの岩瀬さんが話をしてくれます。

ドワンゴさんはヘビーなHueユーザで、主催者の木浦さんがそのあたりの話をしてくれるはずです。

Hue って何で作られてるの?

Hueは、以下のコンポーネントで作られています。

Hue Meetupでは、@tokibito ことオープンコレクターの岡野さんが、Django開発者という観点からみたHueを説明をしてくれる予定です。


Hueで何ができるの?

色々できます。

ファイルブラウザ

ファイルをアップロードしたり、編集したり、ダウンロードしたりすることができます。

f:id:shiumachi:20170919123511p:plain

f:id:shiumachi:20170919123521p:plain


テーブルブラウザ

HiveやImpalaなどのSQLエンジンが扱うテーブルを閲覧することができます。

f:id:shiumachi:20170919123535p:plain

SQLエディタ

HiveやImpalaなどのSQLをブラウザ上から実行することができます。
簡単な可視化もできます。

f:id:shiumachi:20170919123612p:plain

Pigエディタ

一部で根強い人気の残るPigも実行できます。

検索ダッシュボード

Solrと連携して検索ダッシュボードを作成することができます。


f:id:shiumachi:20170919123653p:plain

(Hue 公式サイトより引用)

ワークフローエンジン

ブラウザ上からワークフローをGUIで作成・管理することができます。

f:id:shiumachi:20170919123711p:plain


(Hue 公式サイトより引用)

まとめ

Hue を使うと、ビッグデータ基盤のWeb UIを簡単に用意することができます。
まだ使ったことない人も、使っているけどもっと色々使いこなしてみたい人も、自分の使い方を共有したい人も、Hue Meetupに参加してみてください。

進捗ヤバいプロジェクトに直面した経験がある人なら(多分)楽しめるカードゲーム「Not My Fault!」


@ さんの主催で仲間内で集まってボードゲーム・カードゲームで盛り上がったのですが、その中で @ が持ってきた「Not My Fault!」というカードゲームが非常に衝撃的でした。


まず、背景設定がすごい。
残り30日で絶対に完成させなければいけないプロジェクトに、プレイヤー達はプロジェクトメンバーとして参加しています。
進捗は絶対に遅れてはいけません。
もし、プロジェクトの進捗が報告されていたよりも進んでいないとしたら?
それはもちろん、進捗を過大報告したヤツの責任です。
監査を入れて、そいつを追い詰めよう!
というのがゲームの設定です。

これを読んで、「あー、そういうのあるよねー」と共感したり、「あー、そんなことあったわ」と遠い目をしたり、「あー、今まさにそんな状況だわ」と暗くなったりということが少しでもあれば、このゲームを手に取ってみるといいと思います。


ゲーム自体はすごくシンプルです。

複数人でプレイし、山札を中心に円になって座ります。
最初に一番目の人が一枚目を引いて、自分の作業の「本当の進捗」を確認します。
その後、自分の目の前の場にカードを伏せて置き、「進捗」を報告します。
二番目以降の人は二つのアクションを取ることができます。
一つは前の人と同様に山札を引き、自分の前に伏せて「進捗」を報告する、もう一つは今までの進捗を「監査」することです。
監査した結果、「本当の進捗」が「今まで報告された進捗」よりも低かったら、前の手番の人は責任を取らされます。
逆に、「本当の進捗」が今まで報告された進捗通りだったら、監査を要請した人は責任を取らされます。
通常は二回責任を取らされるとクビですが、ルールによっては一発でクビ(つまりゲームから退場)することもあります。
誰かが責任を取ったら1ラウンド終了です。

この「進捗カード」は0から6までの数字が振られています。
「本当の進捗」というのは、今まで伏せられた全プレイヤーのカードの合計の数字となります。
例えば、場に0、5、3、1が伏せられていたら、本当の進捗は9となります。
そして、報告する「進捗」ですが、絶対にマイルストーン通りの進捗報告をしなければなりません。
当たり前ですよね?30日で完成するプロジェクトに進捗の遅れなど許されないのですから。
このマイルストーンは、最初がいきなり5日です。
つまり、最初のプレイヤーは、0-6までしかないカードのうちランダムに引いた1枚のみを場に伏せて、「5」と言わなければいけないのです。

しかし、このプロジェクトのプロマネはとても有能かつ広い心の持ち主でした。
どのプロジェクトメンバーも、一度だけなら進捗の遅れを報告しても許されます。
つまり、本来「5」と報告しなければいけないところを、「1」と言っても許されるのです。
二度目は当然ありません。

他にいくつかルールがありますが、基本はこのような感じのルールです。
ルールを見てピンと来た人がいると思いますが、これは要するにトランプのダウトの変形です。
嘘の数字を言って場にカードを伏せ、他のプレイヤーがダウトと宣言して嘘だったら宣言した人の勝ち、本当だったら宣言した人の負け、というのと何ら違いはありません。


このゲームの本当の楽しみ方は、炎上プロジェクトに入った気分になって盛り上がることです!
全く進んでいないのに進捗報告で「オンスケです」と自信満々に報告し、進捗遅れを使う場合は「すいません、ちょっと体調不良で…」などと言い訳する。
監査する場合は「ちょっと進捗報告おかしいんじゃないのかね、君?」と問い詰め、退場することになった場合は「一身上の都合で退職します。今までお世話になりました」と挨拶する。
どう考えてもこんなデスマ案件抜けた方が幸せだろ

要は、「ゲームの勝ち負けよりワイワイ盛り上がって楽しむ」ためのゲームです。
楽しみ方が大分ニッチではありますが、我々のような一部の業界の人にはドンピシャ間違いなしです。
今回はお酒なしでプレイしていましたがそれでも大盛り上がりでした。
飲みながら気軽に楽しむのが一番いいと思います。

私達がプレイしたときは、大体こんな感じのプレイ風景でした。



値段は900円(Amazon価格)と大変リーズナブルです。トランプサイズのカードゲームなので持ち運びにも便利です。
是非一度、エンジニア仲間同士でも、プロジェクトチームのメンバーでもいいので、一緒にやってみてください。
作者さんの紹介ページでは作者さんのAmazonアフィリエイトリンクも貼ってますので、そちらから購入してあげましょう。

http://spa-game.com/?p=4937

Twitterでのリプレイ・感想ツイートまとめ (2017/08/01追記)

togetter.com

「Hadoopの時代は終わった」の意味を正しく理解する

Hadoopの時代は終わった、という言説をたまに見かけるようになりました。
もちろん終わってなどいません。しかし、Hadoopとその取り巻く環境が変化したのは事実です。
本記事では、この変化が何なのかを明らかにし、その上で、なぜHadoopの時代は終わったという主張が実態を正しく表していないのかを説明していきます。

DISCLAIMER

私はHadoopを中心としたデータ基盤を取り扱うベンダー、Clouderaの社員です。
中立的に書くよう努めますが、所属組織によって発生するバイアスの完全な排除を保証することはできません。
以上をご了承の上、読み進めてください。

要約

データ基盤は、Hadoopの登場により非常に安価となり、今まででは不可能だった大量のデータを取り扱えるようになりました。
Hadoopは、NoSQLブームの中、処理エンジンであるMapReduceとストレージであるHDFSが一体となっていたため、データ基盤向けのソフトウェアとしての地位を確立していきました。
しかし、2010年代に入ると、ハードウェア、処理エンジン、ストレージの進化により、Hadoopは大規模なデータ基盤として唯一の選択肢ではなくなっていきます。
特に処理エンジンは、MapReduce以外にも優れた処理エンジンが登場してきたため、現在MapReduceはその役割を終えようとし始めています。
一方HDFSは、以前としてオンプレ環境におけるOSSの大規模分散ストレージとして高い地位を占めています。
Hadoopがカバーする範囲も拡大し、新しい処理エンジンやクラウドストレージに対応し、順調に進化を続けています。
よって、Hadoopの時代が終わった、という言葉は正確ではなく、MapReduceの時代が終わった、というのが正しい理解です。

用語の定義

本記事での用語を定義しておきます。
ストレージとは、データを格納する基盤のことを指します。本来はメタデータ(DBスキーマなど)のストアと区別しなければいけないのですが、簡略化のためにストレージとしています。
暗黙的に、その時代における大量のデータを保存することを想定しています。

処理エンジンとは、ストレージからデータを取り出して何らかの処理を行うためのシステムです。ここでは、簡略化のために、SQLなどの、処理エンジンにアクセスするためのインタフェースも処理エンジンの一部として含めて紹介します。
こちらも暗黙的に、その時代における大量のデータを処理することを想定しています。

データ基盤とは、ストレージに格納されたデータを、処理エンジンを利用して、ビジネスにおけるデータ活用を行う基盤のことを指します。バッチ処理、DWH、機械学習など、データを取り扱うものを全て含みます。
なぜ本記事においてビッグデータ基盤と言わないかというと、既に大量のデータを扱うことが当たり前になってきた今日において、ビッグデータブームが始まる前と後で区別することにそれほど意味がないからです。

アプリケーションとは、データ基盤を利用することで新しい価値を提供するソフトウェアを指します。例えば、BIツールやETLツールなどです。ここでは内製ではなく商用ソフトウェアを中心とします。

クラウドストレージとは、オブジェクトストレージを始めとしたクラウド上で利用できるストレージサービス全般を指します。

データ基盤の歴史(1): Hadoopの登場から発展まで(2000年代~2010年代前半)

Hadoop以前(~2006年)

2000年代に入るまで、データ基盤は非常に高価なシステムでした。そのために、本当に重要な一部のデータだけを活用することが常識でした。
データ基盤は、主にメインフレーム、商用RDBMS、商用データウェアハウスなどで構成されていました。
これらは全て、処理エンジンとストレージが垂直統合されていました。
非分散型・スケールアップ型が当たり前の時代だったので、垂直統合しておいた方が効率的だったのです。

f:id:shiumachi:20170709233940p:plain

しかし、Googleは自社の検索ビジネスにおいて、Webサイトのデータという大量の非構造データを、より安価に処理するための基盤を必要としていました。
そこで開発されたのがMapReduceというアルゴリズムとGFSというストレージシステムでした。
この2つの技術に関する論文をGoogleが発表したのは2003から2004年ですが、これを読んだDoug Cuttingがオープンソースで同様のシステムを実装します。
これが、後のHadoop MapReduce (以下MapReduce)と Hadoop Distributed Filesystem (HDFS) となります。 *1

NoSQLの台頭とHadoop一択の時代(2008~2012年)

Hadoop登場と同時に、NoSQLブームが発生しました。NoSQLをどう定義するかは人によって違いますが、一言でいうと「RDBMSが持っていた機能を限定することで、性能のスケーラビリティを重視したストレージ」です。
処理エンジンを内包したストレージも一部ありましたが、価値の根本部分は「スケーラブルなストレージ」という点になります。
多くの人が、そのNoSQLという文字内容から「これからの時代はRDBMSでもSQLでもないんだ」と勘違いしてしまいましたが、NoSQLはあくまでストレージの進化であり、処理エンジンの進化ではありません。

この時代に成功したNoSQLも数多くありますが、同時期におけるデータ基盤向けストレージの勝者は間違いなくHDFSです。
なぜなら、この時代にほぼ唯一の処理エンジンの選択肢だったMapReduceが、HDFSに密結合していた(ように見えていた)からです。

Hadoopは、MapReduce (処理エンジン) + ストレージ(HDFS) が密結合しているように見えてしまっていたため、ほとんどの人がこれらが一体となっていると思い込んでしまいました。
このことは、この時期においては有効に働きましたが、これこそが今回のテーマである「Hadoopは終わった」論の遠因となっていったと私は見ています。

ともかく、Hadoopは、こうした背景から、大規模なデータ基盤としてのこの時代唯一の選択肢として発展していったのです。

f:id:shiumachi:20170709234032p:plain

データ基盤の歴史(2): Hadoop一択の時代を超える(2010年代)

2010年代に入ると、当たり前のように大量のデータを扱う時代が到来し、様々なユースケースにおいて大量データの処理が求められるようになってきました。
元々用途を限定して作られたシステムだった当時のHadoopに対し、新しいユースケースに対応した処理エンジンやストレージが登場し始めます。
そして、古き良きHadoop、すなわちMapReduce + HDFSは唯一の選択肢ではなくなっていきます。
この変化には、複数の領域における発展・変化が関係していきます。

ハードウェアの進化

Hadoopが登場した背景には、ハードウェアの進化の限界がありました。
2000年代においてはまだメモリが高価で、CPUもディスクも性能が鈍化していて、データ基盤を構成するにあたって単一のサーバでのスケールアップでは限界があったために、GoogleMapReduceアルゴリズムとGFSは分散アーキテクチャを採用しました。
しかし、2010年代に入ると、CPUの性能はあまり変わらないものの、メモリが以前よりもはるかに大容量・安価になり、こうしたアーキテクチャの変化を前提にしてインフラ全体が変わっていきました。

処理エンジンの進化

MapReduceが出た当時は、他の技術と比較すると確かにシンプルで理解しやすく、書きやすいと思われていましたが、2010年代に入ると逆に複雑なフレームワークとみなされるようになってきました。
また、MapReduceバッチ処理に限定したフレームワークである上に、処理手法が効率よく働くケースが限定的でした。
こうした課題を解決するため、Apache Sparkが登場しました。効率のよいメモリ活用による高速化と、格段に書きやすくなった記述形式、そしてバッチ処理だけでなく、ストリーム処理や機械学習などもカバーする幅広い用途により、2012年の登場してから急速に注目が集まり、2014年の1.0リリースから一気に広まっていきました。この普及の背景には、先述のハードウェアの進化によるメモリの大容量・低価格化も大きな一因となっています。

データ基盤におけるデファクトスタンダードのインタフェースであるSQLにも大きな変化が起こりました。
MapReduceを使ったSQLエンジンとしては既に2008年にHiveが登場していました。
しかし、大量の非構造データを処理する性質を備えつつも、既存のRDBMSやDWHのような低レイテンシを満たせるような新しいSQLエンジンが求められるようになっていきました。
そして、2012年にApache Impala(当初の名称はCloudera Impalaだが、2016年にASFに寄贈)が登場したのを皮切りに、様々な新世代のSQLエンジンが登場しました。

2012年には、Google BigQueryのような、クラウド上にしか存在しない処理エンジンも登場してきました。ストレージの選択肢が事実上Googleだけになってしまうという欠点があるものの、クエリ毎の課金という革新的な価格体系と高速性から、GCPを代表するサービスとして広く普及していきました。

このように、2010年代中頃になってくると、MapReduce以外の処理エンジンが増えていき、MapReduceはあくまで処理エンジンの選択肢の一つとなっていきました。


f:id:shiumachi:20170709234602p:plain

ストレージの進化

2010年代前半に、処理エンジンの選択肢が多様化しても、ストレージとしてはまだまだHDFS一強の時代でした。大量のデータを処理する基盤に適した、安価でスケーラブルなストレージシステムがHDFSしかなかったのです。
Amazon S3 をはじめとしたクラウドストレージを使うと、ストレージシステムの運用から解放され、初期投資が極めて安価でしかも簡単にスケール可能という多くの利点がありますが、2010年代前後はまだ値段も高く、信頼性・実績ともに乏しかったため、メインのストレージにしようという企業はわずかでした。
しかし、クラウドストレージが進化を続け、信頼性の向上と価格の低下が進むと、インターネット系企業を中心にストレージの中核をクラウド上に持つ企業が数多く登場していきました。こうした企業は、もはやHDFSを自前で持つこともなく、クラウドストレージを中心としてデータ基盤を構築していきました。

ストレージのトレンドの変化を受けて、処理エンジンの側にも変化が発生します。
HDFSを持たずにデータ処理を行いたいというニーズに応えるために、処理エンジンもクラウド対応への変化が進んでいきました。
Amazon EMR は S3上のデータを直接 MapReduce で処理することができる、Hadoop をフォークして開発されたサービスですが、後に Apache本家でも別個にAmazon S3への対応が進み、高速にデータを処理できるようになっていきました。
また、Sparkや、Impala / PrestoなどのSQLエンジンもクラウドストレージへの対応が当然のように行われるようになり、オープンソースの処理エンジンはHDFSだけではなくクラウドストレージへ対応することが求められるようになってきました。

f:id:shiumachi:20170709234635p:plain

RDBMS・DWHの進化

RDBMSやDWHも着々と進化を続け、データ基盤のニーズに応えるよう変化しています。例えば、商用DWHでは既にjsonサポートが当たり前になっており、非構造データへの対応が進んでいます。OSSRDBMSにおいても、PostgreSQLは2012年(9.2)からjsonをサポートし、続くバージョンでjson対応を強化していっています。また、扱えるデータ量も増えていっており、商用DWHでは1PB以上のデータのサポートは当たり前となっています。
DWHそのものもクラウド化が進みます。Amazon Redshiftはクラウド上で安価に利用できるサービスであり、従来のDWHを購入するだけの予算がなかったような企業でも簡単にデータ基盤を持つことができるようになりました。

f:id:shiumachi:20170709234714p:plain

現代におけるデータ基盤

現代においては、データ基盤で利用する処理エンジンとストレージの組み合わせは実に多様化しています。
処理エンジンに重きを置く人はまずSparkやBigQueryを前提にストレージエンジンを探すでしょうし、ストレージに重きを置く人はまずHDFSやS3というストレージ選定から始めて処理エンジンを探すでしょう。
あるいは、使っているアプリケーションが対応している処理エンジン・ストレージを選択していくという過程を選ぶ人もいるかもしれませんし、オンプレミスかクラウドか、あるいは両方を使うべきかという、インフラを中心に選択する人もいるでしょう。
そして、これらのうちどれか一つを選ぶのではなく、複数を組み合わせるというのも当たり前になりました。
ストレージとしてオンプレミスのHDFSクラウドのS3を同時に持つシステムは多数存在しますし、既存の MapReduce ジョブを走らせ続けながら新規開発にはSparkを使い、BIツールからの接続にImpalaを使うという企業はますます増えています。
データ基盤を選ぶのではなく、データ基盤を構成する処理エンジンとストレージの組み合わせを選ぶ時代なのです。

Hadoopの時代は本当に終わったのか?

Hadoopは、MapReduceという処理エンジンとHDFSというストレージの二つを組み合わせたものであることは説明しました。
これらのコンポーネントは、それぞれ異なる変遷を辿っていきます。

処理エンジンは、バッチ処理だけに特化していたMapReduceから、ストリーム処理、低レイテンシなSQL機械学習など、様々な用途に対応するための処理エンジンが登場してきました。
バッチ処理についても、より高速で書きやすいフレームワークであるSparkの登場により、MapReduceは既存のプログラムへの後方互換という用途以外の役目を終え始めています。
しかし、Sparkを始めとした新しい処理エンジンは、様々なデータ基盤で採用されています。
そして、Hadoopという名称が指す領域は、MapReduceだけでなくだけでなくSparkやSQLエンジン、さらにはSolrなどの検索エンジンに拡大していっています。

HDFSは、クラウドストレージを選択する組織が増えてきたものの、データ基盤のストレージとして依然大きな存在感を持っています。
HDFSほどスケーラブルで、かつ実績のあるオープンソースのストレージシステムは他にありません。
自社に十分なインフラ資源(人・モノ・金全て含む)が整っている場合、クラウドストレージを使うよりも圧倒的に安価になるため、HDFSは有力な選択肢となります。
また、オンプレミスからクラウドに移行する際にも、クラウド上でそのままHDFSを動かしてしまえば、既存のコード資産をほぼ変更せずに移行できるため、処理エンジン同様ポータビリティが高いという特性があります。
こうした利点を考えると、HDFSはまだまだ活用され、発展していくと言えます。


f:id:shiumachi:20170709234823p:plain


このように見ていくと、MapReduceは確かに新しい処理エンジンにバトンを渡して静かにフェードアウトし始めていますが、新たな処理エンジンとHDFSを携えて、Hadoopそのものは進化を続けていっていることがわかります。
Hadoopの時代は終わってなどいないのです。

では、なぜHadoopは終わったと言われてしまうのでしょう?
私の見解では、HadoopMapReduce + HDFSがセットになっているというイメージが強すぎて、そこからの転換が進んでいないことが原因と見ています。
多くの人が未だにHadoopバッチ処理のためだけの基盤だという誤解をしています。

2014年前後に、Google BigQueryやAmazon Redshiftのような、安価なデータ分析のための基盤の普及が進みましたが、そのユーザの多くはHadoopが既にそうしたデータ分析が可能になっていることを知らず、古き良きHadoopとBigQuery/Redshiftの間に大きな知識の断裂があるように感じます。

2010年前後に有利に働いたイメージが、逆に今は足かせになっている、というのが私の意見です。

f:id:shiumachi:20170709235557p:plain

まとめ

Hadoopの時代は終わった、という言説を見かけますが、MapReduceの時代が終わった、というのが正しい理解です。
Hadoopは、従来のRDBMSやDWHに比べ、大容量かつ非構造データを処理可能でしかも安価な基盤として2000年代後半から2010年代前半にかけて普及しました。
しかし、2010年代中頃には、Sparkを始めとした新しい処理エンジン、クラウドの台頭、ハードウェアの進化、そしてRDBMSやDWHの性能向上に伴い、初期のHadoopアーキテクチャの必要性が失われていきました。
現在のHadoopは新しい処理エンジンやクラウドへの対応が進んでいるものの、初期のHadoopのイメージが残り続け、Hadoopの時代が終わったという言説につながっていっている、というのが「Hadoopの時代は終わった」という主張の原因と私は推測します。

*1:Apache Hadoopとなったのは2006年ですが、開発されたのは実際にはもう少し前

「プログラミングを独習するには10年かかる」を読んでから10年以上経った

ある方から「どうすればコードが書けるようになるんですか?」という質問を受けました。
その場で自分の考えを伝えたものの、そもそもソフトウェアエンジニアでもない自分がそんな質問をされる立場になると思ってもいなかったので、人生どうなるか分からないものだなと思いました。
色々と思考を巡らせていると、ふとプログラミングを独習するには10年かかるという記事があったことを思い出しました。
自分のブックマークを見ると、


Teach Yourself Programming in Ten Years 日本語訳

道は遠い。

2005/08/08 10:25
b.hatena.ne.jp


なんと10年どころか12年近くも前でした。当時どんな思いでこのコメントを書いたのかは分かりませんが、正直面白くないコメントです。
この記事をブックマークした当時は大学の研究室にいてCやらFORTRANやらを触ったりFreeBSDRed Hat Linux 7や9を触ったりしていた頃で、まともにプログラミングを始めてから数ヶ月も経っていない頃で、ロクなスキルも持ち合わせていませんでした。
今も別に自慢できるような技術を持ち合わせているわけではありませんし、所詮は日曜プログラマの域を出ていませんが、当時に比べたら大分マシにはなったかと思います。

過去の自分を振り返ってみて、この元記事のアドバイス通りにちゃんとできたのだろうか、確認してみることにします。

プログラミングに興味を持ち、それを楽しみのためにやること

業務で明示的にコードを書けと言われたのは2009年に当時の会社の社内システムを作るときにPHPで開発したぐらいで、それ以外は業務中の補助のため、あるいは趣味のコードを書いていました。

  • 2006-2007年: LinuxカーネルOSSのコードを追いかけたような気がするけどコードを勉強してた記憶がない
  • 2008-2009年: Rubyの入門書を読んで勉強し、Google Code Jam (以下GCJ)に参加した。参考 業務ではPHPのコードを書いてた。
  • 2010年: GCJに再度参加する際にPythonを覚えた。参考
  • 2011年: Clouderaに入ったので、Javaの勉強がてらいくらかのHadoopへのコントリビューションを行った 参考
  • 2012年: Python温泉にいって道を踏み外した。仕事でシェルスクリプトやらPythonのコードを色々書いていたらしい 参考
  • 2013年: Fabricやってたらしい。 参考 多分社内で構築自動化ツールとか作ってたような気がする
  • 2014年: 何やってたか覚えてないけど多分社内でPythonのツール書いてた
  • 2015年: bot遊びに夢中になってた 参考
  • 2016年: 会社の製品を触るのがメインの仕事になったので、それらを触るために必要なツールをちまちまとPythonで書いてたように思う
  • 2017年: Hololens買ってC# / Unity をかじったり(参考)、Scrapyを使ってWebスクレイピングとデータの可視化を行ったりしたり(参考)、Pythonbotを開発したりしている

年によって波はあるものの、それなりに楽しんでコードを書いてたようです。

他のプログラマーと話をし、他人のプログラムを読むこと。

前職でも現在の職場でも、プログラマーと話す機会には恵まれていたように思います。
コードを読むことについても、この10年OSSの仕事しかしておらず、コード読むことが仕事の一部ですのでこれもクリアしています。

プログラムを書くこと。学習する最良の方法は、実践による学習だ。

先述の通り、プログラムはそれなりに書いていたように思います。業務経験に乏しく、大規模な開発プロセスの経験が不足している気はします。

もし望むなら、四年間大学で(あるいは大学院に行き、更に)学ぶこと。

CS専攻ではないのでやってません。

プロジェクトで、他のプログラマーと一緒に働くこと。いくつかのプロジェクトで、一番のプログラマーになるか、そうでなければしんがりのプログラマーになること。

職業プログラマではないのでやってません。

他のプログラマーの後についてプロジェクトに関わること。人が書いたプログラムの理解に取り組むのだ。

ある意味OSSの開発ではこれに近いことをやっていたと思います。bot の開発については原作者の後をついで開発しているのでこれに該当するでしょう。

少なくとも半ダースのプログラミング言語を学ぶこと。

自分が学んだと言えるのは、C/C++FORTRANJavaRubyPHPPython あたりですが、正直まともにスラスラと書けるのは Python ぐらいですね。Hello Worldでしたら30言語ぐらいで書きました(参考)

「コンピュータ・サイエンス」の中に、「コンピュータ」があるのを忘れてはいけない。

ハードウェアについての理解は今の仕事で最重要の分野なのでここは問題ないと思います。

言語標準化の作業に加わること。 / できるだけ早く、言語標準化の作業から離れる分別を持つこと。

そもそもこれ実現している人どれだけいるのか疑問です。


で、お前は何を教えたのか?

私が件の方に質問されたとき、下記のような回答をしました。

  • 「入門書を読んで端から勉強する」というのをやめること。少なくとも私なら確実に飽きる。
  • 興味のある対象についてのコードを書く。
  • 興味のある対象というものが思いつかないのであれば、仕事や生活の中で、自動化できるものを探す。会社の業務の多くはルーチンワークであることが多く、よく探せば自動化できるポイントはたくさんある。こうしたものを少しづつ自動化していく。たとえば、あるエンジニアは、上から指示された作業を完全に自動化し、一日の作業を5分で終わらせておきつつ上司には今まで通り一日の終わりに作業完了報告をし、残りの時間をネットサーフィンに当てていたという。
  • コードを書かなくても、「これはコードで書けそうか、自動化できそうか」について常に考える。考えるだけでも、設計のセンスを磨くことができる。
  • 一度に大きなことをやらず、小さいものから実装すること。例えば「文字列を変換するだけ」「http getリクエストを投げて取得するだけ」など。こうした小さいコードを組み合わせれば、そのうちもっと大きなプログラムもさっと書けるようになる。
  • コードの再利用方法について常に心がけること。ワンライナーや使い捨てのコードを書いているのであれば、それを再利用できるように書くにはどうすればいいかを考えること。
  • 上記に関連するが、保守性の高いコードを書くよう心がけること。特にワンライナーなどは3ヶ月後の自分が読んでも全くわからない。3ヶ月後の自分にも理解できるようにするにはどうすればいいのか考えること。ドキュメントを書いてもいいし、インタフェースを工夫してもいい。
  • ネットで話題になっているプログラムやシステムを、自分が得意な言語で再実装してみる。例えば「Rubyで◯◯した」といった記事が話題になっているのであれば、それをPythonで再実装してみる。完全移植でなくても、一部の機能だけでもいいし、品質を気にしなくてもいい。


上記のアドバイスをしたとき、プログラミングを独習するには10年かかるの記事の内容は全く忘れていたのですが、読み返してみると案外共通点も多いですね。やはり名文は確実に自分の血肉となっているようです。

まとめ

10年経っても勉強することはなくならないですが、10年勉強していると日曜プログラマでもそれなりのことができるようになる、というのは確かなようです。
一生研鑽を続けていきたいものですね。

誰でもできる、プレゼンが劇的にうまくなる基本テクニック

私も「テクニカルエバンジェリスト」などという大層な肩書を会社からいただいており、講演や連載記事などの執筆を行っていますが、私のプレゼン技術は数年前にMSの西脇さんのプレゼンセミナーに参加させていただいて学んだものがほとんどで、正直言うとこのような記事を書いて講釈を垂れるような立場ではありません。
しかし、直近で西脇さんのセミナーがないということと、会社も大きくなり同僚が増えていく中で、速やかに自分のプレゼン技術を共有しなければならないという状況になったため、恥ずかしながら自分なりの方法を説明するためにこの記事を執筆することにしました。

プレゼンとは銘打っていますが、実際にはプレゼンだけでなく、ブログの記事執筆などさまざまな表現の場で活用することができます。"present"とは「伝える」「表現する」という意味であることからもわかるかと思います。

著者の経験

公開イベントでのプレゼンは、小さいものも含めると過去5年で50回行くか行かないかくらいだと思います(数えたことがないです)。
お客様への説明や社内での説明など、非公開の場でのプレゼンの回数はかなり多いと思います(それが仕事ですし)。年50回以上は確実にこなしているでしょう。

対象読者

Cloudera株式会社の社員向けに書いていますが、プレゼンの技法に興味がある人なら誰でも読める内容です。
ただ、くどいようですが私の記事を読むくらいなら西脇さんの執筆された本を読む方が100倍有益ですし、翔泳社のイベント一覧を常日頃からチェックして西脇さんのセミナーを受けるべきでしょう。
あくまで西脇さんのセミナーが開催されないときの代替物程度の内容ということをご承知ください。

目次

  • プレゼン作成の流れ
    1. 「誰」に、「何をしてほしいか」を考える
    2. 「出だし」と 「まとめ」と「締めの言葉」を作る
    3. プレゼンの時間を確認する
    4. 理由を掘り下げる
    5. スライドを作る
    6. リハーサルしながらスライドを直す
    7. 他の人にお願いして、通しでのプレゼンを聞いてもらう
  • プレゼンのコツ
  • やってはいけないこと

1. 「誰」に、「何をしてほしいか」を考える

「誰」、つまり対象となる聴衆は誰かを考えます。「開発者向け」みたいなざっくりしたものより、もっと具体的にイメージした方がいいでしょう。聴衆が誰かわかっているなら、特定の一人の人向けに考えてもいいです。
私がブログを書く場合、幅広い対象よりも、むしろ私の友人達に向けて書くことをイメージすることが多いです。仕事でのプレゼンの場合、製品紹介や会社紹介が多くなりますが、こうした場合に、開発者を想定聴衆とするのか、ビジネス層を想定するか、場合によって変える必要があります。

次に、「何をしてほしいか」を考えます。ここで重要なのは、「何を伝えたいか」ではないということです。このプレゼンを聞き終わった後、相手に何をしてほしいのかを考える必要があります。「よし、すぐにこの製品を買おう」と思ってほしいのか、「とりあえず試してみるか」と思ってほしいのか、「おお、すごいなあ!」と驚いてほしいのか?これらの例はどれも、相手がどう考えるかという視点に立ったものです。「何を伝えたいか」というのは自分視点であり、そんなことをいくら考えても、自分が本来意図した結果を得られる可能性は低いでしょう。

2.「出だし」と 「まとめ」と「締めの言葉」を作る

「出だし」つまり最初の掴みです。挨拶は「こんにちは」なのか「こんばんは」なのか、「雨の中来ていただきありがとうございます」なのか、「皆さん、Hadoopの運用管理どうしてますか?」と、いきなりスパッと本題に入るのか、方法は色々だと思いますが、この第一声をきちんと考えるのが重要です。続けて、「今日は○○という話をします」という主題の説明につなげていきます。
次に「まとめ」を作ります。このとき、以下のようなフレームワークで作ります。

  • 「○○(最初に説明した主題)は××なんだ!」
    • 理由1
    • 理由2
    • 理由3

最後に「締めの言葉」を作ります。「何かご質問はありますか?」から、「ご清聴ありがとうございました」というのは無難な流れですが、イレギュラーが発生したときでもうまくまとめて終わらせることができるので、こういう無難な締めを一つ持っていてもいいと思います。いずれにせよ、途中でつまづいても締めがしっかりしているだけで印象がぐっとよくなります。

そして、この「出だし」「まとめ」『締めの言葉」だけ何度も練習します。私は大抵3度は練習します。ここさえ確実にしゃべれるようになれば、どんな状況にも対応できます。例えば、30分のプレゼンの予定が10分に減ってしまった場合(よくあります)、途中の説明内容ど忘れして頭が真っ白になった場合(よくあります)、鋭いツッコミを入れられてすっかり萎縮してしまった場合(よくあります!)などの状況でも、最後に「まとめ」「締めの言葉」で終わらせれば、なんとかなるものです。

ここさえ完成すれば、あとの作業は時間はかかりますが、そんなに難しくはありません。

3. プレゼンの時間を確認する

プレゼンの環境について確認するのはこの段階からで大丈夫です。もう骨子はできてるので、あとは時間に合わせて分量を増やしていくだけです。

4. 理由を掘り下げる

「まとめ」で作成した理由を掘り下げていきます。例えば、「ダバ・インディアのカレーマジ最高!」という主題で、「たくさんスパイスが入ってるからおいしい」という理由でまとめを作ったとしましょう。このとき、なぜたくさんスパイスが入っているとおいしいのか、を考えます。自分がスパイス効いているのが好きだからか?あるいは、他の店よりも相対的にスパイスの量が多いからか?スパイスが効いていないとダメなのか?という形で理由を掘り下げていきます。

このとき、データや実例をおりまぜていくことも大切です。「例えば、ランチの定番のマトンとひき肉のカレーは…」といった実際の料理の例を出したり、「実際にスパイスの量を測定してみたら…」というデータを出してみるというのも手でしょう*1。このとき、調査して得た情報はそのソースは何であるかを忘れずに記録しておきましょう。

もし、自分の推測が入る場合は、それをきちんと明確な形で書いておくべきでしょう。聴衆に誤解を与えないという意味もありますが、それ以上に自分が「調査に基づいた情報」とご認識してしまい、説明を作る上で矛盾を発生させてしまうリスクが高くなります。そうなってしまっては誰もプレゼンを聞いてくれなくなるでしょう。

こうして書き出した新しい説明についても、繰り返して理由を掘り下げていきます。

反論を考えるのも忘れてはいけません。「スパイスなんて別にいらなくない?」「そもそもカレーよりラーメンの方がおいしくない?」など、難癖つけているだけとしか思えないような意見も含めて、思いつくだけ出してみます。そしてこれらについて再反論できなければ、そのプレゼンはどこかおかしい可能性があります。重要なのは、誰が対象の聴衆なのかを忘れないようにするということです。例えば、ビジネス層をターゲットにしているプレゼンで、「なんでHadoopはいつまでもIPv6対応しないのか?」といったような開発者しかしないような質問は想定しなくていいでしょう。

5. スライドを作る

実際にスライドを作っていきます。
スライドを作るときの基本的な指針は、聴衆が「自分が今どこにいるのか」をきちんと把握できるようにするということです。
そのために、以下のことに気をつけましょう。

1つのセクションで伝えることは1つだけ

Hadoop概要」という説明の中に、MongoDBの説明が入っていたり、会社紹介の説明が入っていると聴衆は確実に混乱します。セクション内容と異なる趣旨の説明が必要な場合は別のセクションにしましょう。
セクションそのものが小規模なプレゼンスライドのようなものなので、セクションを作るときも、セクションのまとめから作成した方が構造を維持しやすいでしょう。

1枚のスライドで伝えることは1つだけ

複雑な情報や矛盾のある情報をいきなり見せられると人間は混乱します。伝える内容が複数であれば複数のスライドにわけるべきでしょう。

  • 悪い例1 複雑な情報) 「HoloLensの視野角」というスライドタイトルで、「また、コンテンツがまだまだ少ないのも課題」といった別の情報を含めてしまう
    • 修正案) 「HoloLensの課題 (1) 視野角が狭い」というスライドと、「HoloLensの課題(2) コンテンツが少ない」というスライドにわける
  • 悪い例2 矛盾した情報) 「HoloLensは最高」というスライドタイトルで、「しかし高いしコンテンツが少ないから買うのは微妙」とタイトルと反する内容を含めてしまう
    • 修正案1) 「HoloLensの課題」というスライドを作って、「値段が高い、コンテンツが少ない」などのスライドを別に作る
    • 修正案2) 「HoloLensは一見最高……だが」というスライドタイトルにして、「買うのは微妙」というのを主題にする
絵や文字サイズは会場の後ろから見える程度に大きくする

これは上記2つを守っていると自然にできると思いますが、1枚のスライドに色々な情報を詰め込みすぎると、文字が小さくなり、プレゼンの内容がさらに理解しづらくなります。
その昔流行った高橋メソッドのような、大きいフォントで一言だけ、とまでする必要はありませんが、最低でも会場の後ろの席からでもはっきりと読める程度のサイズは必要でしょう。
プレゼンテーションツールのデフォルトフォントサイズ(多分18pt)以上をなるべく維持し、どんなに小さくても12pt (図表の補足的な文字であれば10pt程度)が限度だと思います。
どうしても12pt以下を多用しなければいけないようなスライドや図表を載せたいのであれば、それらは補足資料として別途配布という形にして、プレゼン時はより簡素にした別スライドを用いるべきでしょう。

6. リハーサルしながらスライドを直す

スライドの表現の間違いに気づく一番いい方法は、実際に声に出してプレゼンのリハーサルを行うということです。悪いスライドであれば、プレゼンのときに必ず詰まります。「あれ、この説明さっきもしたな」とか、「Aという説明からCの説明に写るのは話が飛びすぎているな」など、声に出してプレゼンすることでいくつもの違和感に気づくことができます。途中で止めてしまっても構わないので、詰まったら直していきましょう。

7. 他の人にお願いして、通しでのプレゼンを聞いてもらう

一通りスライドの作成が終わったら、同僚や友人などにお願いして、通しでのプレゼンを聞いてもらいます。このとき、説明が変なところや詰まったところなどは全て記録してもらい、リハーサルが終わった後にその記録を受け取ります。これにより、全体を見たときの矛盾点や違和感などを検出します。レビュアーからは「ぶっちゃけつまらない」「眠い」などの率直な意見をもらった方がいいでしょう。

また、時間も測ってもらいましょう。短すぎるのであれば説明をもう少し増やすべきですし、予定時間を超えたのであれば、スライドを削るか、説明を簡略化するなどして対応しましょう。

プレゼンのコツ

可能な限り聴衆に目と顔を向ける

プレゼンに慣れていないと、ノートPCの資料を読むだけ、という形になってしまいがちですが、なるべく顔を上げ、聴衆に目を向けるようにします。これだけでも結構印象が変わります。

まっすぐ姿勢よく

猫背になったり、左右に傾いたりせず、まっすぐ立ちます。目線と同様、こういったちょっとしたことで印象が変化するのでやって損はないです。

後ろの席の人にも聞こえる程度に大きな声で話す

プレゼンをしていると、ボソボソと小さい声でしゃべってしまい、マイクを使っていても後ろの席からほとんど聞こえない、ということがあります。
後ろでぼーっとしていても聞こえる程度の音量でしゃべった方がいいです。
自分の声がどのように聞こえるかは自分ではわからないので、実際の会場で、他の人にお願いして声が聞こえるかテストした方がいいでしょう。

速く話さなくていいから、はっきりよどみなく話す。「えー」「あー」を極力避ける

プレゼンに慣れていないと、「えー、これは…」「こうすると、あー、ここがこうなって…」みたいに話してしまいがちですが、テンポが乱れて印象が悪くなります。
慣れないうちは、話す情報量を減らしてもいいので、ゆっくり、はっきり話した方がいいです。

次のスライドをめくる前に、次のスライドの内容を話し始める

Hadoopとは」というスライドの次に、「Hadoopの歴史」というスライドがあるとします。普通に考えると、「Hadoopの歴史」というスライドに移ってから、「次に、Hadoopの歴史を紹介します。」のように説明を始めるものと思ってしまいます。

こういう説明だと、テンポが途切れてしまい、聴衆の集中力が切れてしまいます。

現在のスライドを開いた状態で、次のスライドの説明を始め、しゃべりながらページをめくるようにすると、テンポが途切れずとても聴きやすくなります。

先程の例で言えば、「Hadoopとは」のスライドを開いた状態で、「このHadoopが作られたのは2006年で…」と話し始めながらページをめくり、次のスライドに移る、という流れになります。

慣れるまで少し練習が必要ですが、こういう話し方に変えるだけで聴きやすさが劇的に変わるので、是非実践してほしい技術の一つです。

やってはいけないこと

基本のポリシーは、誰が聞いても問題のないプレゼンにするということです。そのために、以下のようなプレゼンを避けるよう気をつけてください。

悪口を言う

誰か、あるいは何かの悪口を言った分だけ、そのネガティブなイメージだけが聴衆の記憶に残り、結果としてプレゼンの評価を下げます。やめましょう。

内輪ネタ

内輪ネタに入れない人は疎外感を抱き、その結果プレゼンに対してネガティブなイメージを持つようになります。やめましょう。

特定のコンテキストを前提としたネタ

これは広い意味で内輪ネタの一つです。例えば、よくエンジニアのプレゼンなどで流行りのアニメのキメ台詞やネットのスラングなどを使って笑いをとろうとするのを見かけますが、わからない人にとっては疎外感を抱くことになるため、印象がよくありません。やめましょう。

特定のコンテキストそのものが主題であり、そのコンテキストを共有している人が聴衆であることが明確な場合は、多少であれば構わないでしょう。例えば、アニメの視聴率データの分析に関するプレゼンを、アニメ愛好者達に向けて行うのであれば、アニメネタを織り込むことにためらう必要はありません。しかし、こうしたネタの多用は単位時間あたりの情報の密度を下げることとなるため、濫用は禁物です。どうしても印象づけたいという場所だけに限定して使うべきでしょう。

著作権違反

ライセンスの確認なしに、ネットで「拾ってきた」画像を使うのはやめましょう。また、こうした手法は、大抵の場合、先述の内輪ネタも含まれているため、二重によくありません。

差別、人権侵害、宗教、ポリティカルコレクトネスに反する内容

男性のプレゼンでたまに見かけるのですが、「男ならこうあるべき」みたいなことをさらっと言ってしまう人がいます。性別、人種、宗教、セクシャルマイノリティ等、差別発言ととらえられてしまう可能性がある話題に触れる場合は、本当にプレゼンに必要なものであるか考えてから使いましょう。考えた結果、プレゼン内容に不要であれば避けた方がいいでしょう。
逆に、プレゼンとして必要な話題であれば恐れる必要はありません。

自虐ネタ

そもそも私自身はあまり自虐ネタを使わないのでいい例がパッと思いつかないのですが、特にプレゼンに慣れていない人や若い方で、自虐ネタを混ぜてプレゼンされる方がいます。
プレゼンへの自信のなさなどもあるのでしょうが、こうしたネガティブなネタは、ネタ自体は記憶に残らなくてもネガティブな印象だけはしっかりと記憶に残りますので、全体の評価を下げてしまいます。
慣れないプレゼンで不安かもしれませんが、自虐ネタは避け、堂々とした内容をアピールしましょう。

時間をオーバーする

どんなにいいプレゼンでも、時間をわずかでもオーバーしてしまえば、聴衆の印象は最悪なものに変わります。時間が遅れるくらいなら早く終る方が数段マシですので、時間は常に見ておくようにしてください。

まとめ

自分なりのプレゼンの方法について説明しました。これはあくまでベーシックな方法を説明したものであり、実際には状況に応じて色々な方法をとっています。こうした臨機応変の対応を身につけるには慣れるしかないので、まずはプレゼンの数をこなしてなれてください。

更新履歴

2017/02/01 8:00 くらい 初版作成
2017/02/01 10:00 自虐ネタ、文字サイズ、プレゼンにおける話し方について追記しました。thx @LET_Japan 様、@kuenishi

*1:もちろんこんなこと実際にはやっていません