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

私も「テクニカルエバンジェリスト」などという大層な肩書を会社からいただいており、講演や連載記事などの執筆を行っていますが、私のプレゼン技術は数年前に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:もちろんこんなこと実際にはやっていません

HoloLens所感: 33万円で買える未来

HoloLensを購入しました。$3000(当時の日本円で33万円)と、決して安くはない買い物でしたが、届いてから丸一日経った時点での感想としては、購入の判断は正しかったということでした。

f:id:shiumachi:20170120101108j:plain

左右の物体は、サイズ比較のために置いたパワーブロックです。

元々VRデバイスが欲しくて、HTC Viveを購入するか、あるいは手でものを掴めるデバイスTouchが魅力的なOculusを買うべきか、それともコンテンツのラインナップが一番豊富になりそうなPSVRを買うべきか悩んでいました。

しかし、どれもゲームコンテンツがメインで、私の現在の多忙さを考えるとゲームメインのデバイスだとそれほど長続きしないだろうなあと思い、一番実用的なデバイスは何かと模索していました。

そんな中、HoloLensの存在を知り、値段の高さに驚きつつも購入してみることにした、というのが購入の経緯でした。

高いといっても、PSVRはPS4とセットで10万程度だからまだしも、ViveもOculusもゲーミングPCなども全て買い揃えるとなると結局30万くらいかかるので、それを考えればWindows含めて全部入りのHoloLensは特段高いとは言えないとは思います。

ハードウェア

まず重さですが、1時間連続してつけ続けても特に負担には感じない、という程度でした。筋力のそれほどない人であれば、数十分でも辛いかもしれません。辛いという意味では、目の疲れや頭のバンドの圧迫の方が大きいと感じました。数時間使っていると、目と頭がかなり疲れます。日常業務(8時間利用想定)には耐えられないでしょう。

バッテリーは4時間程度なら充電なしでも問題なく使えるので、思ったより長く使える印象です。頭に被っていても熱くなったりしないので、消費電力はかなり抑えているのだと思われます。充電の端子はmicroUSBです。

付属品として、HoloLensにおけるマウスに相当する「クリッカー」というデバイスが存在します。これもmicroUSB充電なのですが、なんとHoloLensにはmicroUSBケーブルが1本しかないため、標準の付属物では本体とクリッカーの同時充電ができません。もっとも、一日試してみた後の感想としては、特にクリッカーはなくても操作できるのであまり気にならなかったです。

キーボードは付属していないですが、パスワード入力など結局キーを叩かなければいけない場面は何度も遭遇するので、ほぼ必須と思っていいでしょう。Bluetoothキーボードが必要になるので、これから購入するという人は同時にBTキーボードは発注した方がいいと思います。

操作

操作は、顔の向きでカーソルを移動させ、手のジェスチャーでクリックやドラッグを行います。ジェスチャーについては公式サイト参照。

身体の正面で人差し指を真っ直ぐ立てると、点だったカーソルが中空の丸になります。この状態で人差し指を「クリック」すると、実際にクリックすることが可能になります。

もう一つのジェスチャーはブルームといって、手の甲を下にして正面で握りこぶしを作り、花が開くように手をそのまま開いていきます。これがWindowsで言うところの「スタートメニュー」に相当し、このジェスチャーによりメニュー画面を開くことができます。

今のところ利用できるジェスチャーはこれだけです。正直、横にスワイプなどができないのは直感的でなくて大変残念で、このジェスチャー部分についてはまだまだ改善の余地があると思いました。

キー入力はこのインタフェースでソフトウェアキーボードを使って行う。つまり、一文字一文字うつたびに顔の向きを少しづつ変えていき、空中で指を立ててはクリックを繰り返していくのです。キーボードなしで操作することが非現実的なことがわかると思います。

Cortanaを使った音声入力をメインのインタフェースとして位置づけたいという意志は伝わるのですが、なにせ英語しか対応していないので、英語の発音が苦手な日本人には大変辛いものになるでしょう。早めの日本語対応に期待したいものです。

グラフィック

肝心の映像周りについて紹介していきます。

HoloLensは起動時に部屋をスキャンして、壁や障害物の位置を把握します。これによって、「壁にウィンドウを貼りつける」などの演出が可能となります。壁をクリックすると、HoloLensがスキャンする演出をしてくれるが、これがとても美しい。

開いたウィンドウは、普通のPCのウィンドウと同じように、ドラッグすることで移動したり、角を引っ張ることで拡大したりできます。しかし、普通のPCと違い、どの向きにウィンドウを置くか、なども自由に決めることができます。全てのウィンドウは開いたまま位置が記録されるので、部屋をいくらでも散らかしっぱなしにすることができます!

デスクに座った状態で使用すれば、場所を取らないディスプレイをいくらでも量産できます。下のスクリーンショットではウィンドウが1枚しか映ってませんが、実際は右に1枚、左にもう2枚あります。私のデスクの周りには物理ディスプレイ2枚、HoloLensウィンドウ4枚の計6枚があるわけです。

f:id:shiumachi:20170122004709j:plain

もちろんHoloLensを外せば元のきれいなままの部屋です。もしHoloLensを外しても部屋が汚いままであれば、そもそもHoloLensを扱うのに適した部屋ではないので片付けた方がいいでしょう。あちこち動くことになるので、足元が散らかってると危険です。

ウィンドウには近づくことができます。もちろん画面自体のズームも可能ですが、「小さくてよく見えない場合は近づいて見る」という行動が可能になります。ただし、解像度そのものが高くなっているわけではないので、近くで見ても粗くてよくわからないということは十分あります。

画面の拡大について最大の恩恵を受けられると感じたのが、動画の閲覧です。何せ、それこそ30万円では効かないような高価な大画面テレビと同じかそれ以上のサイズの動画を、一切部屋の場所を専有することなく、しかも好きな場所に設置できるのです!家にテレビがない私にとっては、これだけでも十分価値があると感じました。

HoloLensもいいことばかりではありません。最大の問題は、視野角の狭さです。事実上正面の一部分しか見れないと思った方がいいです。上下左右の端にホログラムは現れません。なので、「横目でウィンドウを見る」といった体験を行うことができません。これが私にとって今回最大の落胆ポイントでした。

「仕事しているときにたくさんウィンドウを開きたい」というのが購入の動機の一つでもあったのですが、この仕様により、首をいちいち向けなければウィンドウを確認できないということがわかったので、こうした使い方は不可能ということがわかりました。

アプリ

次に、アプリを紹介していきます。

デフォルトでMicrosoft Edgeが入っているため、ウェブブラウジングは何も問題がありません。最近のウェブサービスはほとんどがブラウザからの操作をサポートしているため、これがあるだけでほとんどのサービスを自由に使えてしまいます。

サンプルホログラムも色々なものが用意してあります。例えば、下のスクリーンショットはスクワットのレクチャー動画のホログラムです。

f:id:shiumachi:20170121193127j:plain

Remote DesktopWindowsしか対応していませんが、Macへ接続するのであればVNCasterというソフト(有償、試用版あり)でVNC接続することができます。ただし解像度の関係と、Bluetoothキーボードのレイテンシの問題で、あまり実用性はありません。SSH可能なターミナルアプリはいくつか見つかったが、いずれも有償で、まだ試していません。

ゲームは比較的面白いものが揃っています。まず、自分の家の壁をこじ開けて襲い掛かってくるエイリアンを撃退するRoboRaid。弾の数こそ少ないですが、プレイしてみると3D弾幕シューティングゲームであることが経験者にはわかると思います。以下のスクリーンショットでは、エイリアンどもに私の家を壊されています。

f:id:shiumachi:20170122003804j:plain

もうひとつはFragmentsです。記憶の断片(フラグメント)を探る超能力者となって、記憶の中の証拠を探して犯罪事件を解決していくというアドベンチャーゲームです。自分の部屋で犯罪現場を再現するため、自分の部屋をくまなく歩き回ることになります。面白いのは、「集中しないと記憶を再現できない」という設定で、視野角が狭く周辺視ができないHoloLensの欠点をうまくカバーしています。

最初におすすめされたもので残念だったのはHoloTourでした。世界中の観光地をツアーするというアプリなのですが、これは先程のFragmentsと逆で、HoloLensの視野角の狭さの欠点がアプリの欠点につながってしまっています。観光ツアーであれば、その土地に実際にいるという感覚が重要なのですが、何せ周辺の視界はいつもの自分の部屋のため、没入感が全く得られません。これだったら、GoogleがリリースしたHTC Vive用のソフトGoogle Earth VRの方がよほど没入感をえられるのではないかと思います(といっても、私はまだGoogle Earth VRを試していませんが)。

Skypeは、HoloLensを被っている自分自身の視界を相手に見せることができます。つまり、ウィンドウが中に浮いている部屋の映像をそのまま相手に見せることができます。部屋に矢印を書いたりフリーハンドで線を描いたりすることができるので、相手に何かを伝えたい場合はとてもいいツールと感じました。一方で、当たり前ですが自分の顔は相手に見えないため、相手は常に自分自身の顔を見ながら会話することになります(顔が写っている画面の移動はできます)。お互いの顔を見たいのであれば、HoloLensは外した方がいいでしょう。

その他気づいたこと

部屋の照明を暗くすることはできません。HoloLensは部屋の明度も壁の位置認識のために使用しているらしく、動画などを観ようとして部屋を暗くすると壁の再スキャンが走ります。

Windowsマシンがないと、HoloLensの映像を同時に他者が見ることはできません(Skype使うという手もありますが)。集団で楽しみたい場合はWindowsマシンが必須ではないかと思います。

所感

正直今のHoloLensそのままでは、いきなり生活が一変するということにはまずならないだろうと思いました(開発版なので当たり前ですが)。生活一変させたければパワーブロック買った方がいいです。*1

面白いアプリはそれなりにあるものの、どれもなくても生活できるものばかりで、触ろうが触るまいが明日生きていくのにそれほど変化はないと思います。

しかし、未来は間違いなくHoloLensの中にあると感じました。視野角の問題はデバイスの改良によって解決していく問題ですし、キラーソフトウェアの不足という問題は市場が大きくなるに従って改善していくでしょう。しかし、ホログラムを自在に扱えるという体験は、他のデバイスやソフトウェアでは絶対にできません。没入感の強さという観点では他のVRデバイスの方が優れているものの、ワイヤレスデバイスで、現実世界を見ながら仮想空間の世界をオーバーレイできる、つまり現実の生活を行いながら仮想現実の世界に踏み込めるという体験はHoloLensだけが提供してくれるのです。

そういう意味で、「顧客が本当に欲しかったARはこれだったんだ」と感じました。今や既にWikipediaの中だけの存在となってしまったセカイカメラよ、あなたは生まれてくるのが早すぎました。

ほぼ確実に、2018年にはもっと安くて性能のいい次世代機が出るでしょうし、2019年、2020年にもその傾向は続くでしょう。5年後には、「2016–2017年の頃に33万も出してあんな低スペックなマシンを買っていたなんてバカなやつらだ。もう少し待てばよかったものを」と言う人が出てくるのは間違いありません。それでも私は、今この瞬間にこの体験をする価格が33万円なら十分安い買い物だと自信を持って言えます。

今のHoloLensを買っても生活は一変しません。しかし、未来を知りたければHoloLensは試した方がいいし、未来について語りたければHoloLensは試さなければいけないだろう、と感じました。HoloLensがある未来をイメージできなければ、未来をイメージすることは難しいのではないかと思います。

変更履歴

2017/01/22 1:30 「その他気づいたこと」追加、所感の部分にパワーブロック押しの文章を追加

*1:パワーブロック、HoloLensの半額以下(12万円)で、確実に人生変わることを保証できるすぐれものです。生活を一変させたい人は今すぐ買いましょう。

2016年アドベントカレンダーのはてブ数の分析

sucroseさんのアドベントカレンダーのはてブ数ランキングを見て、自分もちょっとやってみようと思い、年末年始で作ってみました。
ただ同じことするのは芸がないので、 Tableau Publicを使ってインタラクティブに操作できるようにしました。

Tableau の Viz はこちらです。
スマートフォンには最適化していませんので、デスクトップPCまたはタブレットで閲覧してください。
埋め込んだままの状態だとウィンドウが小さく使いづらいので、右下の全画面表示をクリックするか、TableauのVizを直接閲覧してください。


概要

このVizはQiitaとAdventarに投稿された、全アドベントカレンダー及びそこに登録された記事のはてなブックマーク数を元に、どのカレンダーや記事が人気なのか、あるいはQiitaとAdventarのどちらが人気なのかを視覚化することを目的としています。
以下のダッシュボードを含んでいます。

  • はてなブックマーク数ランキング
    • 記事別(カレンダー自体も含みます)
    • ユーザ別(投稿者名で識別しているため、あるユーザ名が Qiita / Adventar で全く別の人物によるアカウントだった場合に混在している可能性があります)
    • カレンダー毎(カレンダー自体及びそこに登録された記事のはてなブックマーク数の総計のランキング)
  • Qiita と Adventar の比較

また、個別のビューとしては以下のものを含んでいます。

詳細は後ほど紹介します。

データソース

Qiita 及び Adventar に登録された、アドベントカレンダー2016の全カレンダーページ。
カレンダーには記事のメタデータが含まれます。
記事そのもののページやユーザページのクロールはしていません。
取得日: 2017/1/9 - 2017/1/11

操作方法

ランキング上位N件

デフォルトは上位10件を表示していますが、右上のパラメータを変更することにより任意の順位まで表示することができます。

f:id:shiumachi:20170115141005p:plain

任意のカレンダーやユーザの表示

ツリーマップやランキングなど、一部のビューではカレンダーやユーザのフィルタを行うことができます。
右メニューのフィルタ名の右にカーソルを合わせると検索アイコンが表示されます。その後、表示したいカレンダーやユーザ名のチェックボックスのみにチェックを入れることで、フィルタを行うことができます。

f:id:shiumachi:20170115142333p:plain

ビュー紹介

QiitaとAdventarの比較

f:id:shiumachi:20170115143755p:plain

ページ数、はてブ数ともにQiitaの方が優勢であることがわかります。
直接の比較とは関係ありませんが、面白いのは日別の記事投稿数の推移で、12/1 から 12/25 にかけて徐々に「脱落」していっていることがわかります。
一方で、はてブ数総計の推移を見ると、なぜか Qiita と Adventar のはてブ数の総計の傾向が連動していて、例えば 12/13 や 12/25 などはどちらも急激に上昇していて、一方で 12/14 などはどちらも低下しています。
統計的に解析したわけではありませんので相関があるとは断定できませんが、分析を進めていけば面白そうです。

カレンダー毎はてブ数ツリーマップ

f:id:shiumachi:20170115144145p:plain

カレンダーと記事のランキングをグルーピングして可視化したものです。カレンダー毎ランキングのトップの多くは、複数の記事ではてブを稼いでおり、特にトップのはてなはてブ数の中央値が125とずば抜けて高く、個別の記事がどれもはてブ数を稼げる内容になっていたことがわかります。(中央値は現在のビューには含まれていませんがそのうち追加します)
一方で、eeicなどは1つの記事で圧倒的なはてブ数を獲得して、それによりカレンダー毎ランキングでも上位に食い込んでいます。

メイキング

この Viz は以下の技術を活用して作成しました。技術的な詳細は別記事に書きました。
また、利用した全ソースコードも公開します。

ダウンロード

Tableau Viz 及び元データ

TableauのVizの右上にあるワークブックのダウンロードをクリックしてダウンロードしてください。

暴漢に襲われた

こんにちは、マンションを一目見てから10分で購入したけどISPへの支払いが出来てなくて現在インターネットが止められているPyspa界の普通の人 shiumachi です。
この記事は pyspa Advent Calendar 2016 の19日目の記事です。昨日は @tokoroten のエントリ でした。

経緯

2016年2月12日、私は会社帰りに友人2人と武蔵小山の居酒屋で酒を飲んでいました。参加者は全員自宅が近いので、終電過ぎても飲んでいて、午前1時半くらいにようやくお開きとなりました。
私と友人Mは方向が同じだったので同じ方向に歩いて帰路についていました。歩道上を、左側がM、右側が私という並びで歩いていました。
私はスーツ姿にコートを着てビジネスリュックを背負っているという格好で、Mは私服でジャンパーを着ており、手ぶらで歩いていました。
すると、前方にふらふらと歩く男が一人現れました。「フ◯ック、フ◯ック」とぶつぶつ言っていて気味が悪い男でしたが、不安定な足取りでこちらに向かって歩いてきました。そして、我々の間に割り込んで肩を思い切りぶつけてきてすれ違いました。
「なんだこの酔っぱらいが」と思いつつ(自分も酔ってはいましたが)、そのまま無視してMとの会話に意識を戻しました。
その直後、その男が後ろから全力で追いかけてきて、Mの頭に殴りかかりました。
振り返ったところに、Mの顔面に命中。Mのメガネが落ちてMのメガネがずれて、Mは体勢を崩しました。
そのままその男は右の拳を振り上げて第二撃を加えようとしましたが、私は反射的にその腕を押さえ、攻撃を防ぎました。
相手がその勢いで襲いかかろうとするのを、私は左手で相手の右腕を、右手で左腕を押さえ(多分。こちらの動きは詳細に覚えてない)、拮抗状態に持っていったところ、相手はそのままくるっと振り向いて歩いて去っていきました。
こちらも荷物を持った状態でしかも酒を飲んでいる状態だったし、殴られたMのことも気になったので、相手を刺激しないようその場から歩いて立ち去り、交番に駆け込みました。

以上が、今年の冬に遭遇した暴漢襲撃事件の顛末です。


(2016/12/20 追記: 友人Mに確認したところ、初撃ではメガネが落ちたわけではなく、メガネがずれたとのことでした。訂正します)

考察

戦闘

まず、長年(15年。ただし数年ブランクあり)の合気道の稽古の成果が確実にあったというのが大きな発見でした。例え酔っていようが不意打ちだろうが、攻撃に対してオートガードを発動できたので、「合気道は護身になる」という触れ込みは間違ってないということを自身の身をもって証明することができました。
しかし、大きな課題もあったのも事実です。
一つ目は、第二撃をガードした後に、そこで膠着状態になったこと。これは極めて危険な状態です。もし相手が左手にナイフや拳銃などの凶器を持っていたのであれば、私は今頃確実に死んでいました。合気道としては、相手の攻撃を受けた段階でその場で投げていなければいけませんでした。詳しくは後述しますが、これは稽古の仕方に問題があったと思われます。
もう一つは、オートガードは自分に対する攻撃に対してしか発動せず、Mに対する攻撃には全く無反応だったこと。これは武道全般に言える話ですが、ほとんどの稽古が自分と相対する敵との戦闘を想定しており、自分以外の第三者に対する攻撃に対して反応する訓練を受けていません。Mが成人男性だからまだよかったものの、より戦闘力の低い老人や子供と一緒に歩いているときにそちらを狙われればただではすまないでしょう。この課題に対する効果的な解決策が見いだせず、今も悩みの種ではあります。

戦術

後の合気道仲間との考察において、ガード時に投げなかったことは、実は護身という観点では結果的によかったのではないかという説がでてきました。一つ目は、中途半端に攻撃せずに相手を逆上させずに済んだのではないか、ということ。もう一つは、慣れない実戦の場で攻撃することで相手に必要以上にダメージを与えてしまい、過剰防衛になってしまうというリスクを避けられたこと。確かに、初めての実戦だったということもあり、私がもし技をかけたとしても到底加減などできるものではないでしょう。加減するあまり相手の怒りを買う可能性もありますし、逆に勢いがつきすぎてコンクリに頭から落としてしまって致命傷を与えていたかもしれません。そういう意味では、ガードのみで終わらせたことは護身的は正しかったのかもしれません。
とはいえ、そもそも肩をぶつけられた時点で危険を察知して逃げるべきだったし、護身という観点から言ってもまだまだ課題が多いといえます。

改善

さて、なぜガードのみで動きが止まってしまったかを説明しましょう。合気道を初心者に教える場合、数ステップにわけて動きを説明していきます。ステップ数は技の複雑さによって様々ですが、どの技においても「相手の攻撃を受け」「技をかける」という最低2ステップがあると思います。これが上達するに従い1ステップで行うように変わっていきます。もちろん、私も1ステップで動いていたつもりでした。ところが、私は呼吸の数を減らしていなかったのです。通常、合気道の場合は呼気、つまり息を吐くときに力を出すと教わります。なので、攻撃を受けるときも技をかけるときも息を吐きながら動くわけです。なので、私は当たり前のように、攻撃を受けるときに吐き、相手を崩してから吸い、相手を投げるときに吐く、という呼吸を行っていました。しかし、これでは二呼吸になってしまうため、攻撃を受けただけで動きが止まってしまうのも当然です。
そこで、私は一呼吸で受けから技の行使までの一連の動作を行うように自分の動きを改善しました。つまり、相手の攻撃が来る前に吸っておき、攻撃が来たと思ったときには吐きながら受け、崩し、そして技をかけるのです。これで、全く動きを止めることなく技をかけることができるようになりました。現在この方法で稽古していますが、動きの滑らかさは格段に上がったと感じています。

将来

危ない場を事前に避けることの護身ですから、この上達がどれほどのものか確かめることはなかなかできないでしょうが、万一そういう場が来たときには自分の正しさを実感できることでしょう。なぜ正しさを確信できるかというと、間違ってた場合は次こそ死ぬからです。

経緯その2: その後

本当はこのくだりは書くつもりはなかったのですが、おそらく「警察はどうなった」などと気にする人が多数出ると思いますので書いておきます。
はじめに言っておきますが、私は警察に対して何か批判的なことを言うつもりはありません。私が書きたかったことの全ては既に書いた通りなので、警察云々の話については言及してほしくないと思ってます。
あくまで記録のため、ここに記します。

交番に駆け込んだMと私は、事情を説明しました。Mは鼻血を流していました。メガネもずれてしまったようです。
すると、警察官は「なんでその場で110番しなかったの?」と言ってきました。
一本道で、しかも相手が見えている状況で110番なんてできないだろうと話しても、
「こういうの現行犯じゃないと捕まえられないよ」
と冷たく言われました。
「一応見回りしている者に見に行かせるので、特徴教えてくれる?」
と言われたので特徴を説明すると、無線で連絡してくれました。
「で、被害届だします?正直、こういうのよくある話だし、出しても時間の無駄になるだけだと思うんだよね。多分一時間ぐらいかかると思うけどいい?」
と、被害届出さないようにとすすめてきました。私は鼻血を出してるMをこのままにしとくのも心配なので、Mと相談の上「じゃあいいです」と引き上げることにしました。
私の家が比較的近かったので家で手や顔を洗ったりなどして応急処置をしたりして、タクシーに乗せて帰らせました。

後日、警察関係に詳しい某知人にこの話をすると、
「そりゃこっちは毎晩数百件そういうの相手してるから疲れるんだよ」
という説明を受けました。
別に私は怒るでもなく、「まあそりゃそうだ」と納得しました。そりゃこんなの毎日やってたら大変だろうな、と思ったので特に怒る気はしませんでした。

この事件のもう一つの教訓は、「いざというとき警察は助けてくれないし、警察が来てくれるとしたら自分か相手のどちらかが戦闘不能あるいは死亡したときだ」ということです。
やはり、自分の身は自分で守れないといけませんね。

余談

この事件の説明の方法について色々思案したあげくに、女性の友人に「暴漢に襲われた」と説明したら、目をキラキラさせながら「詳しく聞かせて!」と言い出してきました。
変な勘違いしないでください。

クロージング

明日は Pyspa 統合思念体のヒューマノイド型インタフェース@shibu_jpです。

新Google翻訳を使って3700ワードの技術文書を1時間で翻訳した

新しいGoogle翻訳がニューラルネットワークに基づく機械翻訳に移行して品質が向上した、というので早速使ってみました。

翻訳対象はHadoopのFair Schedulerに関するドキュメントです。

Fair Schedulerは、Capacity Schedulerと並ぶHadoopの2つのスケジューラの一つですが、挙動が少し複雑で、理解するのに苦労します。ドキュメント自体も長く、英語に不慣れな人には読むのがなかなか大変な文書で、前々から訳したいとは思っていました。しかし、3700ワード(A4に文字ぎっしりで7ページ近く)の技術文書を訳すとなると、かなりの労力が必要になります。少なくとも一日仕事になるのは間違いありません。私も仕事が忙しく、なかなか翻訳の時間がとれなかったため、翻訳作業はタスクキューの底に埋もれてしまっていました。

そこで、今回新しい翻訳がどれほどのものか試すのも兼ねて、翻訳してみました。

その翻訳記事がこちらです。

いかがでしょう?いかにも翻訳文書的で、決してこなれている日本語ではありませんが、ほぼスラスラと読むことができたのではないでしょうか?著名な作家によるウィットに富んだ表現を散りばめた小説ならともかく、OSSプロジェクトの技術文書としては十分な品質ではないかと思います。

この翻訳、たった1時間で完了しました。その作業の大半はコピペと整形作業といった単純作業で、翻訳そのものに費やした時間は半分もありませんでした。一日仕事を想定していたものが、たったの1時間です。もし10時間の作業時間を見積もっていたのだとすれば、作業効率は10倍に上がったことになります。

本記事では、この翻訳作業を通して感じた、新Google翻訳についての私の考えを述べさせていただきます。

Google翻訳は間違いなく破壊的イノベーションである

私が今まで翻訳記事を書いていたときは(例えばこの記事この記事など)、辞書のみを使い、機械翻訳は全く使いませんでした。なぜなら、あまりに読むに耐えない文書が生成されるので、日本語を読む方が大変だったからです。

しかし、新Google翻訳は、スラスラと読める文章を生成してくれます。

「英語を読んで理解する」ことと、「英語を日本語に翻訳する」ことは全く別のスキルで、脳の使い方が異なります。翻訳はかなり頭が疲れる作業です。いくら内容が難解な技術文書とはいえ、一つの文書の中にはシンプルな文も多く、誰が訳しても大して変わらないような文も数多く存在します。新Google翻訳は、単純な文章ならほぼ完璧に自然な日本語に翻訳してくれます。この部分を手間をかけずに自動化できるというのが大きな利点となります。もちろん、うまく訳せない部分もありますが、翻訳者はそういった「うまくない」訳の修正にだけ集中すればよくなります。翻訳作業に頭を使う時間が減りますので、脳の疲れ方が全く異なります。

また、文脈に合った訳語を出してくれるというのも大きいです。

先の翻訳記事から引用した、以下の原文と翻訳例を読んでみてください。

A custom policy can be built by extending org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.SchedulingPolicy. FifoPolicy, FairSharePolicy (default), and DominantResourceFairnessPolicy are built-in and can be readily used.

カスタムポリシーは、org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.SchedulingPolicyを拡張することで構築できます。 FifoPolicy、FairSharePolicy(デフォルト)、DominantResourceFairnessPolicyは組み込みであり、簡単に使用できます。

個人的には、 "custom policy" をきちんとカスタムポリシーと訳しているのに驚きました。

比較対象として、Excite翻訳の翻訳結果を見てみましょう。Excite翻訳は翻訳としての品質はかなり高く、私は旧Google翻訳よりもこちらの方を多用していたくらいです。(上記の通り、そもそも機械翻訳をあまり使ってはいませんでしたが)

カスタムの方針は、org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.SchedulingPolicyを拡張することによって築かれうる。FifoPolicy、FairSharePolicy(デフォルト)、およびDominantResourceFairnessPolicyは内蔵であり、すぐに使われうる。

意味は正しく取れていますし、固有名詞もきちんと識別しています。この文の意味を理解しろと言われても、不可能ではないでしょう。しかし、日本語ネイティブであれば、この訳が日本語として読みづらいことは明らかです。この訳をベースに翻訳作業すれば、結局のところ全文を書き直すことになるのは間違いないでしょう。

一方で新Google翻訳は、「他の人間でもできる作業」を確実にこなしてくれます。ここが大きな違いと思っています。

翻訳の品質という点ではまだ色々言いたい人もたくさんいることでしょう。実際私も、全文ベタ貼りで翻訳完了とすることはできませんでした。しかし、致命的な誤訳だけ直せば、OSSプロジェクトの技術文書として十分な品質の翻訳が、従来の10倍くらいのスピードで完成してしまうというのは、破壊的イノベーションといえると思います。

Google翻訳OSSプロジェクトに適用することの利点

この新Google翻訳は、OSSプロジェクトの貢献活動にすぐにでも活用すべきだと思います。その利点をいくつか述べます。

利点1: 翻訳の手間を省き、技術に集中できる

OSSにおけるコミュニティ活動で翻訳に携わっている人の多くは、別に翻訳そのものをやりたいわけではないはずです。翻訳そのものにかける時間を減らせば、その分技術的な貢献に時間を割くことができます。
技術文書の翻訳は、単に文書を翻訳すればいいというものではなく、その内容が本当に正しいのか、背景となるソースコードや実際の挙動などの調査も含まれるケースが多くなります。こうした作業へ割く時間を増やせるということは、結果として文書の品質の向上につながります。

利点2: 今まで翻訳できなかった文書が翻訳できる

翻訳活動をする人は限られています。その有限のリソースの中で、どの文書を翻訳するかを選定しているはずです。私を含む翻訳活動家の多くは、「翻訳したら有益だろうけど、時間がないし後回しにするか」という風にたくさんの未訳の技術文書を抱え込んでいます。今回私が翻訳したFair Schedulerの記事もその一つです。翻訳にかける時間を短縮できるということは、翻訳のスループットが上がるということであり、それによって今まで手つかずだった文章が訳されるようになるかもしれません。

利点3: 新規にコミュニティ活動始める人達にとっての参加の敷居が下がる

翻訳活動は、OSSの活動に興味を持つ人が最初に着手しやすい活動の一つですが、こうした活動に興味を持っていても、多忙な中で活動できないという人も多くいることでしょう。一度に費やす時間が減るのならば、参加してみたいという人が増えるかもしれません。

Google翻訳により破壊されるもの・されないもの

Google翻訳さえあれば英語力は不要?

どなたか忘れましたが、このようなことをTwitterで書かれていたのを見た記憶があります。今回の翻訳を通してわかったことは、少なくとも現時点では英語力は必須、むしろ以前より英語力が要求されるケースもあると感じました。

Google翻訳は確かに高い品質で訳してはくれますが、それでも誤訳の可能性はあります。当然ながら、英語を理解していなければ誤訳を見つけることができません。以前より自然な文章を生成するようになった分、誤訳の発見にはかなりの英語力と集中力が必要になるでしょう。

英語を学ぶ必要がない世界はまだ先のようです。

Google翻訳さえあれば翻訳書は不要?

これも上記と関連しますが、誤訳を識別する必要性や、原文自体の内容妥当性の検証などを考えると、翻訳家に要求されるスキルはむしろさらに高度になりますし、そうした翻訳家による検証を通して著された訳書は高い価値を生むでしょう。

一方で、ただ訳しただけの文書は不要になる可能性はあると思います。

Google翻訳さえあれば他の翻訳ソフトは不要?

外部に公開できない文書などを新Google翻訳にかけるわけにはいきませんので、即座に不要になることはないと思います。しかし、将来的にどうなるかはわからないです。少なくとも、ライセンス的に問題のない文書については、現時点でも他の翻訳ソフトの必要性を感じないです。

課題

Google翻訳は確かに素晴らしいですが、全てを手放しで喜ぶというわけにもいきません。

ライセンス

現時点では生成された文書そのもののライセンスがない*1ので、この文書をOSSの翻訳プロジェクトにかけたときにどのようになるかは不透明です。
過去の実績から、OSSプロジェクトにおいてオープンソースライセンスの元で執筆された文書の翻訳に活用することに対し、Googleが文句を言うとは思えないと私は判断しましたので活用していますが、この点については自己責任で行うしかないでしょう。
日本の著作権法親告罪のため、私は「Googleから何か言われたら対応します」というスタンスでいきます。
特にGoogleのビジネスを侵害しているとも思えませんし、新Google翻訳を活用してもっと多くの翻訳文書を出すことの公益を考えれば、取っていいリスクと判断しました。
さらに言えば、仮にアメリカの法律に従う場合は、フェアユースに該当すると思われますので問題ないはずです。

Webページ翻訳が未対応

Webページ翻訳が新Google翻訳に未対応のため、現時点では
https://translate.google.com/ に原文をベタ貼りするしかありません。単純に面倒臭いです。

こちらはそのうち解決するとは思います。

まとめ

Google翻訳はかなり自然な日本語で翻訳してくれるので、翻訳の生産性を10倍に高める破壊的イノベーションです。
OSSコミュニティ活動に活用すれば、翻訳者は技術に集中したり、未訳だった記事の翻訳に着手できるようになったり、コミュニティ活動の敷居を下げて参加者を増やせると期待しています。
しかし、新Google翻訳を使っても英語力はむしろ今以上に要求されるケースもありますし、技術検証の必要性などを考えると技術書の翻訳書も当分はなくならないと思います。一方で、他の翻訳ソフトは公開可能な文書の翻訳にはほぼ不要になると思います。
Google翻訳によって生成された文書のライセンスはまだ不透明な部分があるとは思いますが、公益の大きさを考えれば多少のリスクを背負ってでもOSSコミュニティにおいて積極的に活用する価値はあると考えています。

*1:少なくとも私は発見できませんでした。知ってる方いらっしゃったら教えてください

セールスエンジニアという仕事

現在の自分の肩書である「セールスエンジニア」という仕事がどのようなものか知らない方も多く、毎回説明するのが大変なのでブログ記事にしました。セールスエンジニアという仕事はなかなか馴染みがありませんが、20代後半から30代のITエンジニアのキャリアパスとしては面白い仕事の一つだと思います。マネージャーになるかどうか考える前に、是非一度読んでください。

この記事では、ClouderaのようなB2BのITソフトウェアベンダーのセールスエンジニアを想定して執筆しています。他の業界のセールスエンジニアについては確実に状況が異なりますのでご注意ください。

要約

セールスエンジニアとは、お客様が自分たちの製品を正しく活用できるよう情報を提供していき、営業が製品・サービスを販売するのを助ける仕事です。お客様への製品紹介と提案が主要業務ですが、その方法は様々です。お客様の要望を満たすようなサンプルプログラムを数日で書くといったような、品質よりも速度を要求される開発も必要となります。

セールスエンジニアとは?

「セールスエンジニア」という名前は非常に誤解されます。しかも海外では略称がSEのため、日本でいうシステムエンジニアと混ざってしまい余計に誤解を招いてしまいます。この記事では誤解を避けるため、あえて略称を使わないことにします。

よく「営業ですか?」と聞かれます。違います。セールスエンジニアは営業ではありません。しかし、ソフトウェアを開発するわけでもありません。「技術面で責任を持ち」かつ「営業と同様に売上に責任を持つ」職務、というのがセールスエンジニアの基本的な定義です。

スーパーの野菜を買うのに毎回専門家に相談する人はいないでしょう。しかし、ある程度価格が高く、しかもその価値の理解が難しいような商品であれば、自分一人で購入するかどうかを決めるのは難しくなります。そういう場合は、購入の判断材料として専門家の意見を聞くことが必要になってきます。

業務システムに大規模に組み込むようなソフトウェア製品では、営業が商品カタログを紹介するだけでは購入すべきか判断がつきません。そこで、セールスエンジニアの出番となります。

セールスエンジニアは、お客様が自分たちの製品を「正しく」活用できるよう情報を提供していきます。ここでいう「正しく」というのは、単に技術的に正しい活用方法というだけでなく、どうすれば自分たちの製品をお客様のビジネスに活かせるか、もっと端的にいうと「どうすればお客様がもっと儲けられるか、あるいはコスト削減できるか」といった説明も含まれます。セールスエンジニアはビジネスと技術のどちらについても説明できなければなりません。

Clouderaのような、ビッグデータのための基盤を提供する会社では、ビジネスと技術双方の理解がより一層重要になってきます。大量のデータを効率よく活用するには技術を理解していなければいけませんし、ビッグデータ活用の技術を活かすにはビジネスを把握しなければいけません。この両者を組み合わせて説明できるセールスエンジニアは、Clouderaにおいては花形の職業と言えます。

具体的な仕事内容

まず、メインの仕事となるのはお客様への製品紹介と提案です。営業に紹介されたお客様に自社の製品の説明をしたり、あるいはお客様のやりたいことをヒアリングして、それにあった製品あるいはその組み合わせを提案することで、製品の価値を伝えていきます。

一口に価値を伝えるといっても、その方法は様々です。エンタープライズ向けの高価なソフトは、簡単なカタログ紹介だけで購入してもらえることはまずありません。セールスエンジニアは自分の持つ技術や知識を駆使して、そのソフトが本当にお客様の望むことを実現できるかどうかを伝える必要があります。

セールスエンジニアの仕事にデモ実演というものがあります。一見簡単な仕事のように見えますが、非常に難しい仕事です。お客様によって要件は全く異なるため、その要件に合わせて一つ一つ作っていかなければいけません。Hadoop や Spark、HBase や Impala といったソフトの動作について詳しければいいというものではなく、どういうデータを取り込んでどういう処理を行っていくのかなどを設計し、しかも実際に動くものを作らなければいけません。これを一週間や数日といった非常に短い時間で作ることが要求されます。

Web上での情報公開やカンファレンスでの発表といった活動も行っていきます。勉強会での発表、githubでのコード公開、こうした活動全てが、セールスエンジニアにとっては通常業務の一つとなります。

どの技術がお客様にとって不要であるかということを説明することも仕事の一つです。お客様に自社製品を購入しないよう薦めるケースも多々あります。Hadoopではなく、ExcelGoogleスプレッドシートPostgreSQLを使うことを推奨するケースも多いです。

Clouderaのセールスエンジニアの鉄の掟として「絶対にウソをついてはならない」というものがあります。分からなければ分からないと言わなければいけません。「セールスエンジニアの信用」というものにこだわったり、あるいはお客様に無理矢理売るために、その場を切り抜けるだけのウソを言ってしまうことは絶対にしてはならないのです。

セールスエンジニアの何が面白いの?

実際にお客様と話をして、そのお客様が本当に必要としているものを提供できることが一番楽しいです。「顧客が本当に必要だったもの」というジョークのような状況を回避できるわけです。どんなにいい製品でも使い方を間違えれば意味がありません。高価な商品を買ってもらうので、それに見合う価値があることを正しく理解してもらい、満足してもらうことが楽しさの一つですね。

様々なお客様のシステムを知ることができるというのも楽しみの一つです。◯◯という会社で××という有名なシステムがあるけど、そこにHadoopを使おうとしている、あるいは既に何年も使っている、ということを知るのはとても楽しいことです。

単にそうしたシステムを知ることができるだけでなく、そうしたシステムを運用する方と一緒に問題解決に携わることができるということが一番楽しい部分でしょう。先進的なシステムを相談できる相手はなかなかいませんので、我々の知識と技術でもってそうした問題の解決に役立てるというのはとても楽しい経験です。

セールスエンジニア FAQ

営業なの?

違います。

営業と一緒で売上に責任持たされるの?売上出ないとクビになるの?

どういう風に売上の責任持たされてるのかは企業秘密だと思うのでここでは書きません。
セールスエンジニアが売上だけでクビになることはないと思いますが、どの道うちみたいな会社は能力を発揮できなければクビになります。

よく誤解されますが、普通に仕事してればクビにされることはそうそうないです。大会社とかでよく見かける「この人なんでクビにならないんだろう」と噂されるような、全く働かない人が実際にクビになるという話です。日本の会社で平均的な勤勉さをもって働いている人なら普通クビにならないと思います。

ただ、会社の業績悪化等で部門ごと消滅したりまとめてクビ切りというのは可能性としてあります。そういうケースのときにすっぱりあきらめられる程度の覚悟は必要でしょう。

クビになるかどうかの話については、 リスクヘッジと給料と英語 も読んでみてください。

コード書けるの?

書けます、というより書かなければいけないケースは結構あります。
通常のソフトウェア開発と根本的に違うのは、品質よりも時間最優先になるということです。
「実際に動かすとこんな感じになりますよ」というのを説明できればいいので、いかにスピーディに作り上げられるかが重要になります。

じゃあソフト作れるの?

開発の責任はないので普通は作りませんが、セールスエンジニアとしての職務の傍ら普通にOSSプロジェクトや社内のプロジェクトにコードをコミットしている人もいます。化物です。ちなみに私の上司はチームミーティングで、「飛行機で移動中に書いたんだ」と自分のgithubのページを開いてコードの説明を始めます。

毎日スーツ着なきゃいけないの?

客先にいかないときは普通に私服ですし、お客様によってもスーツだと堅苦しい雰囲気になるような会社にはTシャツ+ジーンズで行ってます。もちろんスーツを着なければいけないケースはありますが、大体週1-2回ぐらいの頻度じゃないでしょうか。着ないときは1週間ずっと着ませんし、毎日着る週もあります。

儲かるの?

売上分のインセンティブは懐に入ってきます。なので儲かるときは儲かります。
営業よりも売上の責任は少ない分、売ったときのインセンティブは少なくなっている(はず)です。
インセンティブをどう設定しているかは秘密です。

どんな人がセールスエンジニアに向いているか

日本ではこのセールスエンジニアという仕事があまり多くないため、なかなかこの仕事に踏み込みづらいと思う人もいるでしょう。
しかし、よくある「求めるセールスエンジニア像」というものは、顧客目線で云々とか、イマイチピンとこない説明ばかりです。
そこで、私の独断と偏見で、どんな人だったらこの仕事ができるのか、あるいはできないのかについて書いてみました。

ここで「向いていない」というのはあくまでセールスエンジニアという仕事に対してのみですので、他の仕事に対する適性とは全く異なります。むしろ、あえて他の仕事において長所とみなされるような特徴をリストアップしてみました。

技術力があることは大前提なので以下には記載してません。

セールスエンジニアに向いていると思う人

  • 技術ブログ書いたりQiitaに投稿したり勉強会で発表したりと、技術情報を発信するのが好きな人
  • ドキュメント書いたり、ドキュメント翻訳が好きな人
  • OSSコミュニティで質問によく答えてる人
  • コード書くのが速い人。コード読むのが速いとなおよし
  • 本読むときにとりあえずサンプルコードちゃんと動かす人
  • 他人のために料理作るのが好きな人

セールスエンジニアに向いていないと思う人

  • コードしか書きたくない、一日中コード書いて過ごしていたい人
  • ソフトウェアをじっくり開発したい人
  • 自社システムなど自分の問題解決のことだけ考えたい人
  • とにかく売上だけを伸ばしたい人
  • 降ってくる仕事をひたすらさばきたい人

セールスエンジニアのキャリアパス

多くのセールスエンジニアは数年間の技術職のバックグラウンドを持っています。ソフトウェアエンジニアから研究職まで、その職種は様々です。新卒でセールスエンジニアになる人は少ないと思います。少なくとも私は会ったことがありません。私の場合は8年ほどサポートや開発、コンサルなどを行ってから現在の仕事に移りました。

セールスエンジニアから次のキャリアパスは、概ね以下のパターンに分かれると思います。

  • 転職・異動などにより他の製品・技術のセールスエンジニアとなる(専門性の強化)
  • セールスエンジニアのマネージャー
  • コンサルタント(製品の販売ではなく、契約に従ったプロジェクトの遂行に責任を持つ技術者)
  • ソフトウェアエンジニア

まとめ

セールスエンジニアという仕事がどのようなものか、少しは理解できたでしょうか。グローバルや外資系IT企業ではメジャーな仕事ですが、日本の企業においては馴染みの薄い仕事です。しかし、20代後半から30代のITエンジニアのキャリアパスとしてはなかなか悪くない仕事ではないかと思います。「30代になって、マネージャーになるか一生エンジニアを続けるか」といったような悩みを抱えてる方には、是非こうしたキャリアパスがあることを知ってもらいたいです。


Cloudera でセールスエンジニアとして働きたいと思ったらこちらの募集要項を読んでみてください。


2016/06/04追記: コメントに対する回答

色々とコメントもらったので、いくつかとりあげて回答します。

なんでセールスエンジニアみたいな当たり前の仕事のことをわざわざ取り上げるの?

特に外資系IT企業に勤めているとセールスエンジニアという職業が当たり前に存在するので不思議に思うかもしれませんが、日系企業ではセールスエンジニアは非常に珍しく、そもそも存在すら認知されていないことが多いのです。
この記事に対する多大な反響を見れば理解できるかと思います。

それ、セールスエンジニアじゃなくてXXX(職種名)では?

セールスエンジニアに相当する職種名としては、システムズエンジニア(日本のSEとは違う)、フィールドエンジニア、プリセールスなどの呼び方があります。ここではセールスエンジニアで統一しています。

それ、コンサルじゃないの?

通常コンサルタントは契約に基づく有償対応を行う職種となります。セールスエンジニアは常に無償対応です。
お客様の立場から見ると無償対応できるセールスエンジニアはお得なように見えるかもしれませんが、逆に言えば対応を行うかどうかはセールスエンジニア側にイニシアチブがあるということでもあります。他に優先度の高い作業があれば当然対応できません。
「絶対に」対応してほしいのであればコンサルの契約を結ぶ必要があるということです。

それ、結局営業じゃないの?

下記参照。

営業は何やってるの?

営業はお客様とビジネスの話をメインに行い、価格交渉などを経て最終的に取引を成立させることに責任を持っています。よって、案件があった場合の責任者はあくまで営業であり、セールスエンジニアは営業の依頼で技術対応を行う、という関係になります。
営業は正直門外漢なので私では説明できないことも多いですが、真面目にやろうと思うと非常に難しい仕事あるのは間違いありません。営業もまた一つの専門職です。

外資系だと新卒のセールスエンジニアいるよ

外資系大企業で働いたことがないので知りませんでした。
少なくともClouderaには現在のところ新卒からセールスエンジニアという人はいません、としておきます。
一番若くて20代後半〜30手前くらいの印象ですね。30代が大半で、40代も珍しくないという印象です。

なんか随分中途半端な仕事だな

営業寄りになりすぎてもいけないし、技術寄りになりすぎてもいけないし、うまくバランス取らないと中途半端になってしまう危険は確かにあると思います。
ただ、私が今まで会ったセールスエンジニアの中には技術も完璧で、かつ営業スキルを持ち合わせたスーパーマンみたいな人は何人もいます。
そういう風になれるかどうかは本人の資質もあると思うので、人を選ぶ職種だとは思いますね。

2016/06/05追記

それ、エバンジェリストじゃないの?

エバンジェリストは何らかの担当(普通は製品やサービス)を普及させることに責任を持ちますが、案件対応に責任を持つわけではありません。
それに対し、セールスエンジニアは個別の案件対応(正確に言うと案件支援。詳細は後述)に責任を持ちます。
私はテクニカルエバンジェリストという肩書を持っていますがあくまで兼務。

それ、エンジニアじゃないんじゃないの?

日本だとなぜかIT系のエンジニアはコード書いたり製品開発したりする人という認識が強いですが、そもそもエンジニアというのは技術者という意味なのでセールスエンジニア(営業の技術者)という職種は名称として実態を正しく説明していると思ってます。

それ、技術営業なんじゃないの?

私も日本のお客様に自己紹介するときはセールスエンジニアと名乗っても理解してもらえないのでついつい技術営業と説明してしまうのですが、私の主観では技術営業とセールスエンジニア(営業の技術者)は違うものだと思ってます。
セールスエンジニアは営業ではないからです。営業との違いについては他の回答を参照してください。
この辺は別にコンセンサスが取れているわけではないと思いますので、あくまで私の個人的な意見という風に受け止めてください。

やっぱりやってることは営業じゃないか!!

先述の追記をしてもまだこういうコメントをいただくので、ちょっと外資系の業務について補足します。
外資系の会社では、業務において必ず責任範囲というものを定義されます。
その中で、営業はビジネス案件をハンドリングし、クローズする(例えば、製品ならそれをお客様にご契約いただく)ことに責任を持っています。
一方セールスエンジニアは、営業が案件を上手くハンドリングしていくのを支援することに責任を持ちます。
この違いは非常に大きいです。案件の責任を持たない限り、セールスエンジニアは決して営業ではありません。
営業っぽいセールスエンジニアがいようと、技術に詳しい営業がいようとこの事実は決して変わりません。
もちろん、企業によってロールや責任の定義は異なりますので、上記と異なる企業もあるでしょうが、多くの外資系企業では上記の通りではないかと思います。

セールスエンジニアの評価基準ってどうなっているの?

評価基準の設定は組織の活動効率に直結するため、割と機密性の高い情報となります。
ここでは概ねこのような傾向という形で説明します。

基本的に、「自分が支援した案件の売上」が評価基準となります。営業ほど案件についての責任は重くありませんが、自分達の支援によって営業が受注できるかどうかが変わってくるため、ある程度業績は連動します。
これ以外にも、「チーム全体の売上」も評価基準としてチーム間の協力体制を取りやすくしたりなど、様々な工夫が存在します。
逆に言えば、細かい行動は全て自由なため、どういう方針で行動するかは個々のセールスエンジニアによって大きく異なります。
お客様の目の前でライブコーディングしてデモする人もいれば、製品のソースコードレベルまでやたら詳しく説明する人もいますし、あるいはビジネス側の会話メインのほぼ営業みたいな人まで様々です。
Clouderaのセールスエンジニアはかなり技術寄りの人が多いと思います。これがいいことかどうかはわかりませんが……。

エンジニアに薦める仕事じゃないだろこれ

おそらくソフトウェアエンジニアのことを指してるのだと思いますが、そもそもこの記事は「プログラマかマネージャーかでキャリアを悩んでる人」向けに書いたものなので、ソフトウェアエンジニアとして一生やっていく覚悟を決めている人にはあまり関係のない記事だと思います。
その二択だけがITエンジニアの人生じゃないよ、ということを言いたかっただけですね。

製品の説明できない営業の方が問題じゃないの?

営業は当然カタログレベルの製品紹介はできます。しかし、製品の詳細な機能の説明(たとえばHBase APIの使い方)や、基盤技術の説明(たとえばHadoopなら「どのように分散処理を行っているのか」など)、デモやプロトタイプ作成などを営業が一人でこなすのは荷が重すぎます。
営業は、特にセールスエンジニアの支援を必要としない案件も含めてこなしていますし、案件になる前のお客様との打ち合わせも数多くこなしているため、技術の深い部分に割く時間はありません。
そこで、技術的な詳細が必要な部分だけ専門家であるセールスエンジニアに任せる、という形で分業しているのです。
ちなみにClouderaはオープンソースビジネスを行う企業のため、セールスエンジニアはApacheのJIRAのパッチの調査や説明なども行います。

リスクヘッジと給料と英語

この記事の要約

  • 英語が話せるようになれば、日本の人材市場ではなくグローバルの人材市場で自分の価値を判断されるようになる
  • ITエンジニアにとって日本語のみの仕事はグローバルに比べて給料・待遇ともに劣っていて、各種経済予測からこれが改善されることは絶望的
  • 英語使ってグローバル企業で働くことは、「一攫千金や立身出世を狙う野心家のキャリアパス」ではなく、ITエンジニアにとって生き残るための必須能力となりつつある
続きを読む