読者です 読者をやめる 読者になる 読者になる

新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エンジニアにとって生き残るための必須能力となりつつある
続きを読む

voluntas-bot の歴史を振り返る

voluntas-bot とは?

voluntas-bot (以下bot) とは、 @moriyoshit が開発した pyspa チャットのための bot ツールである。普通のchatbot同様、コマンド入力に応じた動作を行うことができるのが、sayingコマンド(通称「語録」)という非常にユニークな操作ができるのが特徴である。本記事では、主にこのsayingコマンドの進化に絞った形でのbotの発展の歴史を振り返っていく。

sayingコマンド黎明期

初期の saying コマンドの運用は、まさに文字通り、参加者の語録を保存しランダムに表示するためのものとして用いられていた。

例えば、moriyoshi が「いくつになってもsvnを触るとドキドキするもんだよ」とチャットで発言し、これを私がとても面白いと思ったとする。そのとき、私は moriyoshi の発言をヲ語録として登録することができる。

!moriyoshi いくつになってもsvnを触るとドキドキするもんだよ

このように登録された語録は、あとからランダムで一つ取り出すことができるようになる。

!moriyoshi
> いくつになってもsvnを触るとドキドキするもんだよ

また、任意のユーザを追加できることができる。例えば、私の語録を新規に作成したい場合は以下のコマンドを実行すればいい。

!saying create shiumachi

見ての通り、非常に単純なkey-value型のデータストアをベースとしたコマンドであり、仕組み自体はとても簡素なものである。この基本的なアーキテクチャは現在も全く変わっていない。
しかし、たったこれだけの仕組みで非常に多様な表現ができるようになるのである。その変遷をこれから紹介しよう。

「誰」「何」「サ変」の誕生: 文章の自動生成の始まり

複数の語録を連結して表示する機能が追加され、そして文字列リテラルが追加された。
その後、誰かが「誰」「何」という語録を作成した。続いて、「サ変」という語録を作成した。
これにより、以下のようなコマンドが実行できるようになった。

!{誰}が{何}を{サ変}した
> ドラえもんが10万円を確定申告した

このように、名詞とサ変動詞を語録として保存しランダムに取り出すことで、文章の自動生成が可能になったのである。
当初のsayingコマンド開発時の想定から大きく離れた、全く別の活用方法である。

この品詞語録の特徴はあくまで「人力」ということである。
ただ同一品詞の言葉を集めてをDBに追加するだけなら簡単なのだが、重要なのは pyspa チャット参加者が、pyspa チャットの発言を見て面白いと思ったと品詞を追加するというというプロセスである。
これにより、pyspa チャットの人達の琴線に触れる品詞のみが集積されていき、生成される文章が pyspa チャット参加者にとって面白くなる確率を上げているのである。
上記の文章の例は比較的一般の人でも楽しめるようなものを取り上げたが、実際には pyspa チャット内でのみ楽しめるような内輪ネタのような文も多く生成されている。


また、語録を連結したコマンドそのものも語録として登録できるようになった。
これにより、生成パターンそのものをランダムに出力させることができるようになった。
たとえば、以下のように「日記」語録を作成することができる。

!日記 {今日は}{誰}{と}{どこ}{に行って}{どうした}{。by}{誰}
!日記
> 今日は蒼井そらと歓楽街に行って買い取った。by tokibito

モーラ語録の登場と俳句ブーム到来

品詞語録が作れるのであれば、同じモーラ数で集めた語録も作ることができることは明白である。モーラとは、言葉の音の拍子の数のことである。例えば、「バルク」「あの日」「手術」は全て3モーラである。詳細は wikipedia の該当項目を参照してほしい。 https://ja.wikipedia.org/wiki/%E3%83%A2%E3%83%BC%E3%83%A9

これにより、俳句語録を作成することができるようになった。

!俳句 {2}{3}{" "}{5}{2}{" "}{3}{2}
!俳句
> カツ麻薬 ディープキス事故 破壊キス

俳句というにはあまりに風情のない生成文ではあるが、五七五の音を作り出すことができるようになった。

接頭・接尾語録: 俳句 ver.2

あるとき、モーラ語録に登録された言葉を三種類に分類できることに気づいた。

  • 句の頭につけないと意味が通らないもの。例: 「青い」
  • 句の最後につけないと意味が通らないもの。例: 「ゆえに」
  • 句のどこにあっても意味が通るもの。例: 「カレー」

これを元に、従来のモーラ語録から一部の言葉を「接頭」「接尾」語録に振り分けた。たとえば「3」語録なら、「3接頭」「3接尾」というようにである。
これを活用し、俳句語録の改良版である「俳句2」語録を開発した。

!俳句2 {3接頭}{2}{" "}{4}{3接尾}{" "}{5}
!俳句2
> 地味な海 邪気眼匂う 秋深し

この改良により、俳句としての美しさが格段に上がり、より深みのある自動生成俳句を楽しむことができるようになった。

初句・中句・結句: 俳句 ver.3

しかし、俳句2もまだ完璧というわけにはいかない。接頭・接尾のような分離が難しい5・
7語録にも問題が残されている。
例えば先ほど例でとりあげた俳句「地味な海 邪気眼匂う 秋深し」は、本来この「秋深し」は初句(一番最初の五の部分)に来るべき内容であり、結句(一番最後の五の部分)に表示されるのはふさわしくない。
これは短歌にしたときに7語録にも同じ話が言える。下の句である七七のどちらの位置で生成されるのがふさわしいかは内容によって異なるのである。
そこで、「5初句」「5結句」「7中句」「7結句」を作成し、「俳句3」を開発した。

!俳句3 {5初句}{" "}{7中句}{" "}{5結句}
!俳句3
> 寂しさに キングファイルが 救世主

rsub関数、let関数の登場と「伝記」語録の開発

「誰」「サ変」に代表されるに品詞語録によって、簡単な文章の作成は行えるようになった。しかし、長文を生成するとなると、生成された単語を繰り返し使う必要が出てくる。これを実現するには変数束縛の仕組みが必要である。
moriyoshiがいくつかの方式を実装したが、文法がかなり複雑であまり普及しなかった。しかし、rsub関数の登場により変数束縛の時代が訪れることになった。

rsub 関数はpython の re.sub() にインスパイアされた、正規表現マッチングによる置換機能を持つ関数である。
最もシンプルな(そして想定された)使い方は、生成された文章の特定の語を置換することである。

!rsub("[ww]", "笑", がーすー)
> 地獄絵図じゃないっすか笑

しかし、正規表現のグルーピングを利用することで、変数束縛を行うことができる。

!rsub("(.*)::(.*)", "昨日、"{$1}"が"{$2}"に行ったら、"{$1}"の妹に会った。", {random}"::"{どこ})
> 昨日、とんぷーがハト小屋に行ったら、とんぷーの妹に会った。

変数束縛したい言葉を第三引数に記述する。第三引数全体にマッチさせることで第三引数は最終的に生成させず、第二引数に記述された「置換後の文章」が実際に生成される文章のベースとなる。

!伝記 rsub("(.*)::(.*)::(.*)",{"その昔、"}{$1}{"という日本人が"}{$2}{"で活躍したという文献が残っている。
"}{$1}{"は旅の"}{職業}{"だったが実は"}{$3}{"の達人で、秒間"}{nine}{num}{"回も"}{$3}{"することができたため、"}{$2}{"が危機に瀕したときに大いに役立った。
"}{$1}{"の子孫は"}{random}{"という名で、今も日本にその血筋が残っている。"},{random}{"::"}{国}{"::"}{サ変})
!伝記
> その昔、とんぷーという日本人がカザフスタンで活躍したという文献が残っている。
とんぷーは旅のゲームクリエイターだったが実は割り勘の達人で、秒間63回も割り勘することができたため、カザフスタンが危機に瀕したときに大いに役立った。
とんぷーの子孫はaodagという名で、今も日本にその血筋が残っている。


それからしばらくして、let関数が実装された。これによって変数束縛はより容易になった。上記のrsub関数による伝記語録は、以下のは、語録と等価である。

let({"その昔、"}{主人公}{"という日本人が"}{活躍国}{"で活躍したという文献が残っている。
"}{主人公}{"は旅の"}{職業}{"だったが実は"}{スキル}{"の達人で、秒間"}{nine}{num}{"回も"}{スキル}{"することができたため、"}{活躍国}{"が危機に瀕したときに大いに役立った。
"}{主人公}{"の子孫は"}{random}{"という名で、今も日本にその血筋が残っている。"}, 主人公(random), 活躍国(国), スキル(サ変))

まとめと今後の展望

以上、botコマンドのうち特に語録コマンドの発展について説明した。現在よく使われている語録である儀式、自由律俳句などについては文章量の都合上割愛した。
今後の展望としては、botコマンドのオープンソース化が挙げられる。現在、ある事情があってソース公開には至っていない。また、公開のためにはいくつかのハードルがあり、現在のところ解決できていない。pyspaチャット参加者以外の人でbotを使ってみたいという人はもうしばらく待ってほしい。
その他、管理コマンドの追加、特に統計情報の取得・表示などが開発要望として挙げられている。

謝辞

開発者の moriyoshi、私と同じくらいのbotヘビーユーザであるaodag、そしてbotとともに生活する全ての pyspa コミュニティの参加者達に心から感謝いたします。

転職してから4年が経ちました

といっても4月1日の話なのでもう一ヶ月以上も前になるのですが、色々と忙しくて後回しにしてました。
ブログで転職報告してから4年の間、どういう仕事をしてきたのか書いてないことに気づいたので、せっかくなのでちょっとまとめてみようと思います。

1年目(2011年)

「朝、ベッドから起きると、そこが職場になっていた」

この感覚は今でも忘れません。オフィスも同僚もいなかった私は、在宅勤務という形で Cloudera での仕事を始めました。1Kの小さいマンションに住んでいたため他の作業部屋がなく、自分のベッドの横の机がそのまま仕事場になりました。

サポートエンジニア(今は COE = カスタマー・オペレーション・エンジニアという名前になっている)として今の会社での仕事を始めたのですが、肩書き通りの仕事だけをしていればいいなんていうことは当然あるわけもなく、日本にいる唯一のエンジニアとして何でも仕事をこなさなければなりませんでした。 (営業などは別にいました)

私が日本で最初に行った仕事らしい仕事は、Hadoopのトレーニングの講師の補助でした。当時はまだ日本のインストラクターがいなかったため英語で開催していたのですが、通訳などのコミュニケーション補助を行いました。


前職 NEC とは全く異なる文化で、本当に驚くことばかりでした。一番衝撃だったのはクビを切ることに対する文化です。

初めての出張で US のオフィスに行き、オフィスのトイレであるエンジニアと会話しました。

「よう、お前日本から来たんだってな。お前の斜め後ろの席あたりに座ってるから、なんかあったらいつでもいってくれよな!」

この会社に入ってから感じのいい人ばかりに巡りあっていて、この人もまた愛想のいい人だったので、やっぱりこの会社に入ってよかったなとそのときは思いました。

一時間後、一通のメールが全社員宛に届きました。

「◯◯はもうこの会社にはいない。本人のプライバシーを守るため、本件については一切口外しないように」

青ざめました。あまりに怖くて、彼が座っていたデスクの方を振り向くことさえできませんでした。どんなにみんなフレンドリーでも、ここはアメリカの会社なんだと再認識しました。
今ではすっかり名作アニメとなってしまった、当時放映されたばかりの「魔法少女まどか☆マギカ」の巴マミの末路を思い出し、いきなり目の前から人が消えるってこういうことなんだなと感じました。


それから数日後、別の社員がメールを送ってきました。

「新人研修を担当している××だ。アメリカにいるうちに研修やるから、来週の月曜時間空けといてくれよ」

彼は月曜に出社しませんでした。メールボックスには「××はもうこの会社にいない」という全社宛のメール。最初の一件のインパクトが強すぎたのか、2回目は最初ほどショックを受けませんでした。結局この研修を受けることはありませんでした。

衝撃的だったのはその週の金曜夜でした。会社の飲み会があって参加したのですが、普通にクビを切られた彼も参加していたのです。
「だからオレ達の会社がさ、おっと失礼、君たちの会社がさ、」なんてジョークを飛ばして笑い合ってたのです。日本における「クビ切り」とは全く感覚が違うのだとそのとき理解しました。

一応後から学んだ知識で補足すると、この彼は多分どちらかというと例外に属し、実際にはクビを切られるというのは多くの人にとってあまり気分のいいものではないのは間違いないはずです。ただ、クビを切られる=人生の終わり、みたいに捉える人はまずおらず、誰にでも起こりうることという捉え方はされています。

2年目(2012年)

年の始めにようやく小さなオフィスを構えることができました。といっても用意されたのはオフィススペースだけで、家具は自分達でそろえなければなりませんでした。その当時のメモがこちらに残っています。

日本でも少しづつ知名度が上がり始め、顧客もパートナーも増えてきたため、次の社員を雇う必要がでてきました。

英語もしゃべれて技術力もあり、しかもこんな小さい会社に来てくれる人となると探すのが非常に困難です。

そこで友人の @ に声をかけることにしました。こんな簡単にクビを切られるような会社に友人を誘うというのは本当に勇気がいるものです。彼にはこの会社に勤めるリスクやデメリットなど、知りうることを全て説明しましたが、それでも彼は来ることを選択してくれました。

今では日本はもちろん Cloudera のグローバルでもトップクラスの COE として活躍しています。正直ここまで活躍してくれるとは想像もしませんでしたが、本当にいいエンジニアを誘えたと思っています。

3年目(2013年)

@ が一人前の COE としてサポート業務の活動を回せるようになる一方で、私はサポート以外の業務がどんどん増えていきました。そこで、当時社内でもかなり特殊な仕事だったプロアクティブサポートエンジニアという職種にロールチェンジすることを選択しました。

このプロアクティブサポートエンジニアは、サポートチームに属してはいるものの顧客対応がメインの仕事となるため、当時の自分の業務内容にピッタリな仕事でした。
後にプロアクティブサポートの仕事のうちの顧客対応の部分はセールスエンジニア側に継承されていき、ロール自体はよりサポート特化となっていきますが、これが後の私の2回目のロールチェンジにつながっていきます。
この当時はサポートを実際に購入した顧客向けの、ある意味「ポストセールスSE」としての活動がメインでした。

また、この年から APAC として組織的な強化をし始め、同じタイムゾーンの同僚が急激に増えていきました。
今まではほとんどの同僚がアメリカやヨーロッパに住んでいたために時差を気にして仕事をすることが多かったですが、同じ業務時間中に連携できるというのは非常に心強いことでした。

4年目(2014年)

長らく日本の面倒を見てくれていたコンサルの方が外れ、新しい日本のトップがチームに加わりました。この人は日本語を全くしゃべれなかったため、オフィスの言語は英語になりました。

この年に私は2回目のロールチェンジを行い、セールスエンジニアとなりました。といってもサポートチームの仕事もある程度引き続き行っていて、結局のところ二足のわらじを履いていたのが非公式から公式になったようなものでした。

このセールスエンジニアという仕事はサポートとはまた違う方向で面白い仕事です。
サポートを行っているとどうしても異常系に偏って技術力が伸びる傾向になり、どこをどうすれば壊れるか、という知識は多くなります。
一方セールスエンジニアは、どこをどう使えばやりたいことを実現できるか、という正常系の知識が多く要求されます。

セールスエンジニアは顧客が購入にいたるまでの技術的な責任を持つというのが仕事で、自社の製品をどう使えばどのようなことができるのかということをきちんと理解し、場合によっては独自に調査する必要があります。
当然自分だけの知識では対処しきれないため、グローバルの人達の力を借りることになります。各技術の最先端のエンジニアと様々な議論をしながら顧客のニーズを実現するための方法を模索していくというのは非常に楽しい仕事です。

そして5年目(2015年)

日本ではもちろんのこと、もうすっかり社内でも古株になってしまいました。
入社当時に比べて社員の規模は10倍以上になりましたし(正確な数字は秘密)、日本もどんどん人が増えていっています(こちらも正確な人数は秘密)。先日はオフィスも新しい場所に移り、大分広くなりました。

さすがに会社に在籍中の身なので書けないこともたくさんありますが、上に書かれていないところで大変なことがたくさんありました。順風満帆とはほど遠い道のりをたどっていますし、何度も「もうおしまいだ」と思ったものです。
そもそも明日どうなるかも分からない世界です。こんな記事を書いてて翌日にクビになっててもおかしくありません。

面倒なことだってたくさんあります。やりたくない仕事もあります。それでも会社を辞めないのは、やりたいことがたくさんあるからですね。

Hadoop を日本で広める手伝いをしようと思って今の会社に転職して4年経ちましたが、それでもまだまだ普及にはほど遠い状況です。
既に US では昔の Hadoop から脱却して汎用の大規模分散処理・大規模分析処理の基盤としての地位を確立しつつあるのに、日本では昔の Hadoop すら理解していない人が多い状況です。

昔も今もたびたび Hadoop 不要論が唱えられたりしていますが、実際に顧客の話を聞いてみると、明らかに Hadoop を使った方がやりたいことを実現できるというケースはたくさんあります。
そうした人達にこの技術の価値をもっと伝えていければと思っています。

また、この会社には一流の技術者がたくさんいます。それも、世界でトップクラスの技術者です。技術者だけじゃなく、ビジネス側にも優秀な人達がたくさんいます。こうした人達と一緒に仕事できるというのは本当に楽しいです。

社員だけでなく顧客も優秀です。海外はもちろん日本でもかなり先進的な取り組みをしているお客様がたくさんいます。こうした人達と一緒に仕事できるのも魅力ですね。

……と、こんな感じでこの会社のいい部分というのをたくさん挙げることができるうちは他の会社に行かなくてもいいかなと思ってます。

そんな私と一緒に東京でセールスエンジニアとして働きたい!と思った方はこちらからご応募ください。

質疑応答

最近 ask.fm 始めましたので質問があればこちらに。

http://ask.fm/shiumachi

有用そうな内容はこちらの記事にも転載します。
質問は公開されます。どうしても個人的に質問したいのであれば、別の方法でご質問ください。

いくつかの想定質問と回答を先に書いておきました。

ぶっちゃけいくらもらってるの?

よく聞かれるんですがそんな言うほどもらってないです。同じ業界のエンジニアと話してたら「そんな安いの?」って驚かれたレベル。それでも前職よりはもらってます。
生活できるので別に困ってないし不満にも思ってないです。

セールスエンジニアってどんな仕事してるの?どうせ単なる営業だから技術のことやらないんでしょ?

「営業活動に関わる技術全般」です。デモ環境作ったり技術説明のプレゼンをしたりというのが定番ですが、ぶっちゃけ何やってもいいです。
Cloudera だと ASF で開発やっててコミッターになったりとか本書いたりとか色々います。個人的には会社のエンジニアの中で一番フリーダムな仕事と思ってます。

英語どこで学んだんですか?

普通に大学受験の勉強ですね。面接は当然英語なのでそこでもまた事前に特訓しましたが、今の英語力はほとんど入社してから身につけました。

英語の勉強法については私が4年前に書いたこちらの記事をご覧ください。

(追記) 「お前帰国子女だろ!」ってツッコミがあちこちから入りましたが、ぶっちゃけ小学校低学年の語学力なんて大したことないので今の英語力にほとんど影響ないと思いますよ……。

もらった質問に対する回答

ask.fm を埋め込む方法がわからなかったのでツイートで代用してます。


アメリカとイギリスのドローン規制

首相官邸へのドローン襲撃事件をきっかけに、日本でもドローンに対する規制の議論が盛り上がってきました。
意外と規制反対している人が多くて驚きましたが、実際に海外だとどんな規制があるのだろうと思って調べてみました。

(注意: 私は法律の専門家でもドローンの専門家でもありませんので、記載内容の正当性に関して何ら保証することはできません。この記事を利用して発生したいかなる損害についても責任は負いません)

イギリスのドローン規制

元ネタ: http://droneflight.co.uk/pages/summary-of-uk-legal-requirements
ドローン開発会社 Droneflight 社による、イギリスでの法規制のまとめです。
法律そのものを読みたいかたはこちら: http://www.caa.co.uk/docs/33/CAP393_ANO_Jan2015.pdf
管轄: イギリス民間航空局 (UK Civil Aviation Authority)

用語 説明
航空機 ドローンを含む航空機全般。ここではドローンと読み替えて問題ない
小型無人航空機 要するにドローンのこと。
遠隔操縦者 要するに操作している人のこと。
CAA イギリス民間航空局

先ほど紹介したページに、以下のような項目としてまとめられています。

  • 航空機の操作によっていかなる人・モノも危険に晒してはならない。
  • 航空機は遠隔操縦者が視認できなければならない(通常水平方向500m以内、高度400フィート(約120m)以内)。これより遠距離まで操縦する場合はCAAの許可を取得しなければならない。
  • その質量に関わらず、偵察目的の小型無人航空機は、あなた(訳注:ここでの主体所有者、実行指揮者、操縦者なのかは不明)の管理下にない人及び資産の近くで飛行するときに最低距離に関してより厳しい制約を受ける。この最短距離よりも近い距離で飛行したい場合、操縦を開始する前にCAAの許可が必要である。
  • 金銭を対価にして行われる全ての飛行にCAAの許可が必要である。
  • 遠隔操縦者は、飛行が安全に行われることについて自分自身で責任を負う。
  • 以下の飛行禁止エリアを飛行してはならない。
    • 密集地帯の上空及び150m以内
    • 1000人を超える、野外の組織だった集会の上空及び150m以内
    • 航空機の責任者の管理下にない船舶、車両、構造物の50m以内
    • 離着陸時を除く、あらゆる人の50m以内。航空機の責任者を除くあらゆる人の30m以内を飛行してはいけない。


また、上記とは別のドローンに関連する規制が存在します。

故意かどうかに関わらず、小型無人航空機に搭載された偵察カメラの利用時に収集された個人を特定できる画像は、データ保護法の管理下にあることに注意すること。この法律にはそのような画像の収集、保存、利用についての要求が含まれているので、小型無人航空機の操縦者は適切な要求及び免除規定に従っていることを保証しなければならない。詳細については www.ico.org.uk を参照のこと。

アメリカのドローン規制

元ネタ: http://knowbeforeyoufly.org/for-recreational-users/
Know Before You Fly という、無人航空システムのNPOであるAUVSIを始めとしたいくつかの団体による啓蒙キャンペーンのサイトです。
上記の規制まとめは個人用で、他に商用向けと公共団体向けが存在します。情報が多いので全部はまとめません。必要に応じて原文を読みましょう。
管轄: 連邦航空局 (Federal Aviation Administration)

用語 説明
UAS unmanned aircraft system. 無人航空機、すなわちドローンのこと。
sUAS small UAS。小型無人航空機。
FAA 連邦航空局


繰り返しますが、この規制は個人向けです。商用の場合は上記リンクから別ページを参照してください。

  • Academy of Model Aeronautics (AMA) が作成したコミュニティベースのガイドラインに従うこと。
  • 飛行は高度400フィート(約120m)未満にし、可能なら周囲の障害物の下を飛行すること。
  • 常にsUASを視認できる位置にすること。必要なら観測者の支援を活用すること。
  • 有人航空機とは無縁の位置で飛行し妨害しないこと。また、他の航空機や障害物を常に視認して回避すること。
  • 故意に保護されていない人や走行中の車両の上を飛行しないこと。個人や壊れうる資産から少なくとも25フィート(7.6m)は離れること。
  • 空港から5マイル(約8km)以内で飛行する場合は空港や管制塔に連絡すること。
  • 悪天候(強風あるいは視認性が悪い天気)で飛行しないこと。
  • 飲酒やドラッグを使用した状態で飛行しないこと。
  • 操縦環境が安全であること、操縦者がsUASの操縦に習熟していることを保証すること。
  • 近づいただけで物議を醸すような場所、例えば発電所浄水場、刑務所、交通量の多い道路、政府関係の建物などの近く及び上空は飛行しないこと。
  • 私有地上空を飛行する前に現地の法律及び条例を確認し従うこと。
  • 該当する個人の許可なしに、プライバシーが保持されるべき場所で人を関しあるいは撮影しないこと。(AMA のプライバシーポリシーを参照のこと http://suas.modelaircraft.org/ama/images/sUAS_Safety_Program_web.pdf )

個人的な感想

どれもまともな内容で、むしろこのくらいの規制が日本にないことの方がおかしいと思います。
首相官邸ドローン襲撃事件についても、アメリカ・イギリスどちらの法律でも十分規制できる内容です。
規制されるとイノベーションが阻害されるという意見がありますが、上記と同レベルの規制で阻害されることなどまずありえないと個人的には思います。むしろ、こういう線引きがはっきりした方がドローン研究・事業に安心して乗り出せるのではないでしょうか。

ニューヨークの #ingress ポータル紹介

先日ちょっと出張でニューヨーク行ってきたのでingressをプレイしてきました。
たくさんポータルキーを取得したのですが、帰国後は特に使い道もなかったので泣く泣く処分。
ただ捨てるのももったいないので、記録として残すことにします。
また、NYCでプレイした感想も記しておきます。

NYCでのプレイ感想

プレイしたエリアはセントラルパーク南部からブロードウェイあたりです。

忙しくてほとんど時間がなく、まともにプレイできたのは帰国直前の2時間程度でした。それでも UPV 200 / UPC 60 ぐらいは稼ぐことができました。

ポータルは両陣営ともボロボロで、まともにリンクすら張られていません。旅行前に X8 を集めておけば、簡単に落とすことができるでしょう。

相手陣営からの反撃もありません。「ならやりたい放題じゃん?」と思うかもしれませんが、そうは甘くはありません。リアルに危険なので、常に現実世界の周囲に気を配ってプレイする必要があります。日本のように、夜中にスキャナ見ながら歩くなんてことはできません(日本でやっても危ないので控えましょう)。

ポータルの数は確かに多いのですが、日本に比べて圧倒的に広く、ポータル密度はかなり薄いです。山手線の主要駅の密度の半分以下と思って間違いないです。なので、徒歩で移動するのはかなり大変です(先述のスコアはかなりの早歩きで達成)。

高層ビルが多く、GPSがとりづらいところも多いです。西新宿や渋谷、東京丸の内GPSの飛び具合をイメージしてもらうとわかりやすいでしょう。

治安についてのメモ

注: 私はNYCに数日滞在しただけなので、以下の感想が正しいかどうかは全くわかりません。このメモを信じて行動して何かあっても責任とりませんのでご注意ください。

  • 全般: どの時間帯でも物乞いや、何かわめいている人はあちこちにいて、油断してるとすぐにリアキャプされる。
  • 平日朝: 通勤してる人が多く、早歩きの人達の中でゆっくりプレイするのはかなり大変。
  • 平日夜: 危険だと聞いたけど、出歩けないほど危険とは感じなかった。ただし、ingressプレイできるような状況ではない。ものすごい人の数で、どこにスリがいてもおかしくない雰囲気。日本人と中国人がアメリカ人に入れ替わった夜の新宿歌舞伎町ぐらいの感じ。
  • 土曜朝: 人が非常に少ないが、いないというほどではないので、プレイには最高の時間帯だった。危険そうな人達も、かなり遠くから視認できるので事前に回避可能。

NYCポータル紹介

はてなフォトライフの制限に引っかかったのでここでは全部を紹介しません。全部見たい人は下のリンクを見てください。


201410 New York Ingress Portals


芸術作品系


図書館


教会


シアター

ブロードウェイらしく、シアターもたくさんポータルになっています。


レストラン

レストランが申請通るのは知りませんでした……。結構たくさんあります。


商業施設

複数の店が集まったような商業施設もポータルになるようです。

不明

人が映ってるのに…