THE MODEL -SaaS時代の成長戦略- に参加してきた #themodel

前回ブログを書いたのがいつか分からないくらい久しぶりですが、昨日参加したイベントが素晴らしかったのでレポートを書いてみます。

参加したのは『THE MODEL -SaaS時代の成長戦略-』。マルケト日本法人を立ち上げられた元オラクル、セールスフォースの福田康隆さんが基調講演をされるということで、イベント告知を見つけてすぐ申し込みました。福田さんの著書『The Model -マーケティングインサイドセールス・営業・カスタマーサクセスの共業プロセス-』の出版記念も兼ねているようでした。

THE MODELとは

THE MODELは、マーケティングインサイドセールス、フィールドセールス、カスタマーサクセスの分業体制を体系化したもので最近特にニュースや特集記事等で目にすることが増えてきたような気がします。
「ヤス、何で日本人は生産管理については緻密なプロセス管理をするのに、営業にはそれがないんだ」と言われたことをきっかけに作られたものだそうで、TOCで有名なザ・ゴールの考え方を営業プロセスに移植したようなイメージです。詳しくは各所で解説されているので割愛しますが、これを初めて見たとき(確か2017年のSaaS Conference Tokyo)はなるほどなぁ、感動したのを覚えています。

f:id:nakansuke:20170914162809j:plain なぜセールスフォース・ドットコムは成長を続けられるのかから引用

今やってること、みんながやってることを疑うこと

今回の講演はTHE MODELの詳細の説明や、書籍の紹介がメインになるかと思っていたのですが良い意味で裏切られました。福田さんの講演で一貫していたのが、みんなが言っているからってそれを盲信するのではなく、自分たちの状況に合うようにしっかり落とし込んで考えることが必要であるというところだったように思います。

B2B SaaSと一言でいろんなサービスがまとめられていますけど、セグメントもチャネルも、ビジネスステージも違うしこれってほんとにひとまとめで議論していいんでしょうか」ということから始まり、

「『B2B SaaSやってるんで、これからカスタマーサクセスを立ち上げます、インサイドセールス部隊を作ります』って最近よく聞くけど、本当にそれが自分たちにとって最適なのか考える必要がある」

SaaSの40%ルールやT2D3とかすごく耳にするけど、これはあくまでもVCや投資家の立場から見た指標であって、当事者たちは自分たちのビジネスモデルに合わせ適切な指標で管理する必要がある」

「KPIで管理すればOK、 ビジネスが方程式で回ると勘違いしている人が最近多い。スプレッドシート埋めれば終わりではない」

と、何でも型にはめようとしたり、流行っているから他の人がやっているからという理由で真似をしようとしたりするのは危険である、ということを一貫して述べられていました。
※あくまで私の記憶を元に文字で起こしているので、実際におっしゃっていたメッセージとは異なる可能性があります。

f:id:nakansuke:20190201131738j:plain

THE MODELに関しても元々そのようなフレームワークがあったものをセールスフォースに適用したら大成功した、というわけではなく、その当時のセールスフォースを分析して、どう改善していくことが可能か、生産管理の理論等を参考にしながら福田さんが作り上げられたもので、それが全てのビジネスで有効であるとは限らないということでした。

これには凄く同意で、自分も5年前からSendGridというSaaSを日本市場に提供することに注力してきましたが、各フェーズで何が必要かを考え抜いて取り組んだおかげで成長を続けることができているように思います。こうやった方が良いのでは、他ではこうやっている、というのに簡単に流されなかったのがよかったかと。

重要なのは何を作るかではなく、それまでのプロセスで何を学ぶかということ

登壇中Appleのデザイン責任者であるJony Iveのメッセージが紹介されていました。

I’ve always thought there are a number of things that you have achieved at the end of a project. There’s the object, the actual product itself, and then there’s all that you learned. What you learned is as tangible as the product itself, but much more valuable because that’s your future. You can see where that goes and demand more of yourself, being so unreasonable in what you expect of yourself and what we can expect of each other, that it yields these even more amazing results, not just in the product but in what you’ve learned.”

いろんなことを成し遂げたり、作ったりすると思うけど、重要なのは作ったもの自体ではなく、作までのプロセスで学んだことである。といったニュアンスでしょうか。

今回の福田さんからのメッセージはまさにこれで、お話しされている内容もTHE MODELを創り、マルケトを日本で成功させるまでに得られたこと、学んだことを惜しげも無く披露されており、刺さる話が多すぎました。

結局最後は人

THE MODELのようにきっちりと体系立ててプロセスを管理していくことを、強く薦められるのかと思いきやそうではなく、凄く人間味があることを仰っていたのも印象的でした。どんなにプロセスを突き詰めていったところで、結局事業を回すのは人なんだから、人とその感情が重要であると。

会場からの質問で「インサイドセールスを根付かせるために外してはならないものはなんでしょう?」というものがあったんですが、福田さんからの回答は以下のようなものでした。

  • マネージャはチームメイトに厳しく
  • 営業にフォーカスがあたりがちだが、成果が出た時にインサイドセールスにも賞賛をすること(これを完璧にやっていたのがSFDCのマークベニオフ)
  • マネージャーはいい仕事をしているインサイドセールスと、適当な仕事をしているインサイドセールスを注意深く見分けること。結果の数字だけを見てはだめ
  • 結局はコミュニケーションが重要


ということで大いに刺激を受けたイベントでした。書籍をこれから読み進めていくのが楽しみです。福田さん、運営の方々、ありがとうございました!

プレゼン時に気をつけたほうが良いこと(カメラマン視点から)

この記事は、カンファレンスカメラマン Advent Calendar 2017の15日目の記事です。
やべーあっという間に自分の番が回ってきたよ、どうしようと思いながら筆を執っております。(現在15日19時05分、早く飲みに行きたい)

何を書こうか迷いましたが、皆さんカメラや撮影Tipsが多いようなので私はちょっと違った観点からカンファレンスカメラマンとしての記事を書いてみようと思います。

f:id:nakansuke:20171215202054p:plain

いい写真が撮りやすい人はプレゼンもうまい説

コミュニティやイベントの写真を撮るようになって4年以上たつのでおそらく100人を超える発表者の方々を撮影してきたと思うんですが、ある時「んーーーーこの人めっちゃ撮りにくい!」という人は大概プレゼンもちょっとイマイチであることが多いことに気づきました。(もちろん全員じゃありません、マサカリ投げないで)

私も仕事柄プレゼンをする機会が多いので発表のやり方や中身も結構気になってしまうのです。
では何が良くないのか、こうなってる人は気をつけたほうが良いですよ、というのをあげていきたいと思います。

ずっと下むいたまま

オーディエンスに全然目線をやることなく自分のPCばっかり見ているパターン。
パワポにぎっちり文字が入っていたり、原稿をひたすら読んでいたり、つまらない大学の講義みたいな感じです。資料を読み上げるだけなのでずっと目線は下を向いたままで何枚撮っても同じ写真になります。
読み上げるだけであれば資料を公開すれば十分なんですよね。反応を見たり、質問を投げかけてみたり、そういう方が聴いてる方も楽しいと思います。

ずっとスライドみたまま

逆にスライドばかりみていて後ろ姿しか撮影できないパターン。

リハーサル、接続確認をしていない

デモをやったり、音声つきの動画を再生したりする場合は必ず事前確認が必要です。また、プレゼン初心者の方もかならず事前確認をしましょう。思ったのと違ったり、予想していない事態になると上記の2パターンになってしまうことが多いです。

プレゼン中微動だにしない

常に同じ姿勢で喋り続けるパターン。何度シャッターをきっても同じ画になります。
身振り手振りがあるのが必ず良いというわけではないですが、大体このパターンだと抑揚なく延々と喋り続けるので、だんだん聴衆が疲れてきます。

時間を守らない

ひたすら読み上げるタイプの方は割り当てられた時間を守らず延長してしまうことも多いです。時間は守りましょう。後の方にしわ寄せが行ってしまいます。もちろんタイムキーパーがコントロールすべきではありますが。

マイクは正しく持つ

最後はちょっとプレゼンテクとは違いますが、結構間違ってる方多いので一応。
画像の右の持ち方で、かつ上に向けるカラオケ持ち(?)の人。音をうまく拾わないし、ハウりやすいです。 さらに小指とか立ててたりすると写真的にも。。。。 f:id:nakansuke:20171215202112p:plain 引用元:単一指向性ダイナミックマイクの正しい持ち方  
 

結論

しっかり練習して、聴衆に目をやりながら喋りましょう

 
 

カメラマン的に気をつけてもらえるとうれしいこと

もちろんカンファレンスの主役は登壇者と参加者です。 なので以下はただの撮影者のワガママですが気をつけてもらえると嬉しいことをあげてみます。

不要なものは演台に置かない

使ってないマイクのスタンドや、飲みかけのペットボトルなど余計なものが置いたままになっていると、それが写り込んでしまいせっかくの良いショットが台無しになってしまうことがあります。

スポットライトが当たっているなら当たる範囲で

せっかくライトが当たっているのになぜか真っ暗なところで喋り続けてしまうことがあります。気付いてないだけだと思いますが真っ暗だとやっぱりきびしいです。

 
 

いかがでしたでしょうか。
プレゼンテクニックとしてよく言われるものも多いと思いますが、プレゼンも良くなって、カメラ写りも良くなって一石二鳥ですね!

是非参考にしていただければ。(自分も気をつけます)

Mailsploitは何が脅威なのかを考えてみる その2

SendGridエバンジェリスト@nakansukeです。

その1では、

  • メールのFromにはエンベロープFrom, ヘッダFromの2種類があること
  • ヘッダFromは送信者が自由に設定可能であるため簡単になりすましが実現可能なこと
  • SPFDKIMという認証技術ができたこと
  • とはいえSPFDKIMはヘッダFromのなりすましを完全には防ぐことはできないこと

と紹介しました。その2ではSPF/DKIMを応用した最新の認証技術DMARCを紹介し、本題のMailsploitの何が脅威なのかを説明したいと思います。

DMARCとは??

DMARCはSPFDKIMを更に進めた認証の仕組みで、SPFおよびDKIMの認証に失敗した際に、そのメールをどのように処理すればよいかを送信側が制御します。SPF/DKIMはあくまでも送信側ドメインDNSに送信元の妥当性を検証するための情報を宣言してあるだけでしたが、DMARCはさらに、認証にした場合にこのメッセージは捨ててください、といったことまで記載することができるようになっています。

f:id:nakansuke:20171213085501p:plain DMARCのイメージ

DMARCの何がうれしいのか

SPF/DKIMでは、認証に失敗したときの受信可否の判断は受信側が行なっていましたが、DMARCの場合は送信側がそれを決めることが可能です。ポリシーを非常に厳しくする(SPF/DKIMの認証に失敗した場合はメッセージを破棄させる)ことで、第三者からのなりすましを強力に防ぐことが可能になります。

DMARCレコードは、_dmarc.example.comにtxtレコードとして以下のような値を設定します。(DMARCはヘッダFromのドメインを検証する仕組みです)

v=DMARC1; p=quarantine; fo=1; adkim=r; aspf=r; pct=100; rf=afrf; ri=86400; sp=none

DMARCのポリシーはpタグで指定し、以下のようにレベル分けがされています

  • 未認証メールを受け取ったときに受信サーバで取るべきアクションについて、特に規定しない(p=none)
  • 未認証メールは、受信サーバで隔離する(p=quarantine)
  • 未認証メールは完全に拒否し、受信しない(p=reject)

という順に厳しくなっています。米国の大手メールサービス提供者である、AOLやYahoo!(yahoo.comのことで、yahoo.co.jpとは別物です)では最も厳しい設定がされています。つまり、AOLやYahoo!のプラットフォーム以外からaol.comやyahoo.comをヘッダFromに指定してメールを出すことは不可能になっているということです。

つまり、DMARCは自分のドメインを利用して第三者がメールを送信することを防ぐことが可能な仕組みであるといえます。

日本でも利用者が多いGmailHotmail(その他MSのメールサービス含む)もそう遠くない未来にrejectに設定変更すると明言しています。(本当はもうとっくになっている予定でしたがやはり影響範囲が大きすぎるためか延期に延期を重ねています)

DMARC周りは、このあたりでも詳しく説明しているので、興味がある方はぜひご覧ください。

今回のMailsploitが脅威なのは、このようにDMARCポリシーで第三者からのメール送信を一切禁止しているドメインをFromに指定して(いるように見せかけて)メールを送ることが可能な点にあります。

Mailsploitの攻撃対象

ヘッダFromは、DisplayName <example@example.com>という形で、単純にメールアドレスだけでなく、DisplayNameをセットで付けることが可能です。多くのメールクライアントではこのDisplayNameを差出人情報として表示します。
通常メールを送るときは非ASCII文字を使用して送信するときにはエンコードして送信し、メールクライアントがデコードして人間が読むことができる形式の文字にして表示します。Mailsploitは多くのメールクライアントに存在するデコード後の文字列処理に関する脆弱性を突きます。

例えば、iOSのメールアプリの場合は、ヘッダFromにヌルバイト文字が含まれていると、それ以降の文字をスキップするという仕組みになっています。

エンコードされたヘッダFrom : ?utf-8?b?cG90dXNAd2hpdGVob3VzZS5nb3Y=?==?utf-8?Q?=00?==?utf-8?b?cG90dXNAd2hpdGVob3VzZS5nb3Y=?=@mailsploit.com
デコードされたヘッダFrom : potus@whitehouse.gov\0(potus@whitehouse.gov)@mailsploit.com
脆弱性のあるメールクライアントでの表示例 : potus@whitehouse.gov
(引用元:mailsploit.com)

つまり、

hoge@hoge.com(ヌルバイト文字)fuga@fuga.com

と指定すると、実際のヘッダFromはfuga@fuga.comであるのに、受信者にはhoge@hoge.comからメールが来たように見えます。これがMailsploitを利用したなりすましです。

Mailsploitの恐ろしいところ

その1でも説明したとおり、メールはもともと簡単になりすましをすることが可能で、SPFDKIMの認証をpassしたなりすましも可能でした。ではMailsploitのなりすましの何が恐ろしいのでしょうか。

それは、DMARCでSPF/DKIMの認証に失敗したときにメールを破棄する(p=reject)厳しい設定にしているドメインのメールになりすますことが可能な点にあると思います。これはMailsploit以外では実現できませんでした。

たとえば、yahoo.comではp=rejectになっているので、yahoo以外の環境からyahooのアドレスをFromに指定して送信することはできません。つまり、Fromがyahoo.comのアドレスであれば、そのアドレスは確実にyahoo.comから送信されたものであり第三者がなりすましたものではないことが保証されることを意味しています。しかしMailsploitを使用することで(厳密にはヘッダFromではないですが)送信元としてyahoo.comのアドレスが指定できるようになってしまうため、無条件にyahoo.comのメールを信じていた場合には注意が必要になります。

※Mailsploitの脆弱性をつくことで、コードインジェクション型の攻撃も可能なクライアントもあるようですが、本記事ではとりあえずなりすましの部分にのみフォーカスをあてています。

対処方法

JPCERT/CCでは以下の方法を推奨しています。

  • 対応済みのメールクライアントを利用する
  • 不審なメールはメールヘッダーを確認する
  • PGP/GPG などの仕組みを利用する

正直なところPGP/GPGやS/MIMEといったエンドツーエンドで暗号化が可能な方式を採用するのは、現在の普及率からみても現実的ではないので、安全なメールクライアントを利用し、少しでも怪しいと思われるメールはヘッダを確認する、という対応が必要だと思います。

まとめ

ということで、まとめると以下のようになります。

  • メールはその仕組み上なりすましが容易に実現できる
  • SPF/DKIMはどのドメインを認証しているのか注意が必要
  • DMARCで厳しいポリシーにすれば自分のドメインの悪用を防ぐことが可能
  • しかしMailsploitへの対処が済んでいないメールクライアントだとDMARCをスルーすることができる
  • 怪しかったらヘッダを確認しましょう

SendGridのサポートを続けてもう4年になりますが、SPFDKIMも正しく理解されているケースは結構稀です。日頃利用しているメールの周りで使われている技術はどんなものなのか、改めて確認してみるとどうでしょうか。

ではでは。

Mailsploitは何が脅威なのかを考えてみる その1

SendGridエバンジェリスト@nakansukeです。 ここ数日メール周りではMailsploitが注目を浴びてますね。海外出張中だったため若干出遅れてしまいました。。

「送信元を偽装できる」のはメールのもともとの仕様でありどうも脆弱性ということで不用意に騒ぎすぎているように思います。なので、Mailsploitのどこにどういう脅威があるのか整理したいと思います。

まずはメールのFromの整理から

メールの送信元/差出人(From)には2種類が存在します。 エンベロープFromとヘッダFromの2種類で、よく郵便物の封筒とその中に入っている便箋にそれぞれ記載されている差出人に例えられます。

  • エンベロープFrom : SMTPのMAIL FROMコマンドで指定するアドレスで、メールヘッダのReturn-Pathに記載されます。そのため、受信者が直接目にすることは基本的にはありません。RFC5321.MailFromとして定義されています。
  • ヘッダFrom : メールヘッダのFROMで指定されるアドレスで、メールクライアントでは送信元として表示され受信者が目にするのはこちらのアドレスです。RFC5322.Fromとして定義されています。

f:id:nakansuke:20171211080845p:plain ヘッダFromとエンベロープFromのイメージ (引用元:dmarc.org)

なりすましの仕組み

SMTPの仕様上、ヘッダFromは好きなように指定することができるので、エンベロープFromとヘッダFromが異なっていても問題にはなりません。これがなりすましメールを簡単に実現できる理由です。 GmailなどではヘッダFromを変えるためには色々と設定が必要で、自分が保有するアドレスやその組織のアドレスしか指定できないようなルールがあって簡単には実現できませんが、メール送信用のプログラム等では簡単に指定可能です。

システムのアラートメールなどでは、差出人に適当なアドレスを指定しているケースも多いのではないでしょうか。例えばGmailから送信されたメールではないのに、ヘッダFromにGmailアドレスを指定しているのであればそれは立派ななりすましメールです。

なりすましを防ぐため認証技術の登場

受信者に見える差出人の情報を好き勝手変えることができるのでそれを悪用したメールが後を絶たず、それを防ぐための仕組みが必要とされるようになりました。

そういう流れでできたのがSPFDKIMです。

SPF/DKIMの仕組み

SPF/DKIMは、いずれも送信側ドメインDNSサーバに自分が自分であることを証明するための情報を格納しておき、受信者がメール受信時に確認する仕組みになっています。

f:id:nakansuke:20171211080920p:plain

  • SPF : DNSサーバに送信元メールサーバのIPアドレスを予め宣言しておきます。受信側では実際の送信元IPアドレスと、送信者がここから送信するとDNSに宣言しているものと一致するかを確認します。異なっていたらなりすまされているということです。
  • DKIM : DKIMの場合はIPアドレスではなく、公開鍵をDNS上においておきます。そして秘密鍵電子署名を付与して送信します。受信者は公開鍵を利用して署名が復号できるか確認します。DKIMによって送信元が正当であることとともに、メールが改ざんされていないことが確認できます。ちなみにディーキムと読みます。

SPF/DKIMが検証するドメイン

SPFエンベロープFromドメインを検証する

RFCではSPFで検証する対象のドメインはMAIL FROMつまり、エンベロープFromであると定義されています。 多くの人が勘違いしているのですが、SPFのチェック対象はヘッダFromではありません

なので hoge@example.com というアドレスからメールを送信するときに、example.comSPFレコードを設定しなきゃ!となるのは正しくありません。エンベロープFromのドメインexample.comであるならそれでいいのですが、異なるのであればそちらに設定しなければなりません。

ちなみに、SendGridの場合は、エンベロープFromのドメインは、ヘッダFromのサブドメインを使用するので、ヘッダFromドメインSPFレコードを指定する必要はなく、既存のSPFレコードには影響を及ぼさない仕組みになっています。
参考:独自ドメインを利用する

DKIMは署名内のdタグのドメインを検証する

DKIMで検証するドメインは、ヘッダに記載されたDKIM署名のd=タグで指定されたドメインです。これまたDKIMもヘッダFromドメインを検証するわけではありません
下のような署名が入っているのであれば、sendgrid.infoを検証します。(厳密には、smtpapi._domainkey.sendgrid.infoを検証します)

DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=sendgrid.info; h=from:to:subject; s=smtpapi; bh=36gYllQgpA7ZWa26ryLrOZA0+io=; b=gPvxfw3p3DVuUCBD+30D7I4X7St/a fFh1qQLSoRPniqhYBM3KE(以下略)

SPFDKIMでなりすましは防げるか

上述の通り、SPFエンベロープFromを検証しますし、DKIMは署名内で宣言されたドメインを検証します。そのため、それらが必ずしもヘッダFromと一致するとは限りません。そのためSPF/DKIMの認証がOKであってもそれはヘッダFromの認証が通ったというわけではなく、あくまでもエンベロープFromとDKIMドメインが正当であるということを意味します。

つまり、SPF/DKIMによって防げるなりすましは、

が一致する時に限るということになります。

SPF/DKIMの認証が通ったというのは、あくまでも、エンベロープFromのドメインのチェックがpassしたということであり、dタグドメインの署名が正当なものであったということで、ヘッダFromの正当性を保証するものではありません。

これはMailsploitがどうこうというのは関係なく、もともとなりすましが可能であったということです。ではMailsploitは何が脅威になるのでしょうか。 ちょっと長くなってしまったのでここでいったんきって、その2に続けたいと思います。

※12/13 9:00追記 その2書きました。

カンファレンスカメラマンカンファレンスで発表してきました

カンファレンスや勉強会等のイベントで撮影スタッフをやっている人たちが集まって好き勝手ワイワイやるイベント、カンファレンスカメラマンカンファレンス (長い)が開催されるということで、そりゃー発表するっしょ!ということでカメラマンLT枠で申し込んで発表してきました。

何を話そうか

とはいえ、ワイワイするということ、カンファレンス撮影に関してあればテーマはなんでもOKということしか決まってないので何を話そうかすごく悩みました。

結果、カメラ歴7年程度で、一応フルサイズではあるがエントリーモデルで頑張ってる自分が、コミュニティで写真を撮り続けることで、どんなことが起きたか、そして、そうなるにはどういうことを心がけてきたかというのを共有することにしました。

資料はこちら

写真を取り続けることで何が起きたか

沢山写真を撮って共有することで、

  • プロフィール写真に使ってくれる人が出てくる
  • イベントの撮影スタッフとして声がかかる(ギャラが出るものも)
  • メディアで使ってもらえる

ということが起きました。

いずれも自分の承認欲求が満たされるので、これが起きるたびに更にのめり込んでいきます。写真はただ撮っているだけではなく、作品でもあるのでそれを認めてもらえることはとても嬉しいのです。

気をつけたこと

では、ちょっといいカメラを買ってパシャパシャやってればそれでいいかというと決してそうではなく、こういうことを気をつけたのが良かったんだと思う、という話につなげていきました。

資料ではシンプルにまとめているので当日かなり口頭で説明しましたが、やっぱり重要なのは、 写る人のことをどれだけ考えて、思いやってシャッターをきるかだと思います。
それには、より良い写真にするために基礎を勉強する必要もあるし、その会場のいる人達のじゃまにならないように配慮しながら自分の足で画を決めて撮ると。そして周りのフィードバックをもとに改善を繰り返す必要があると思います。

とまぁ結構偉そうなことを喋りました。色々ディスりもいれました。が、特にこれから写真頑張りたい、そうやれば良くなるのかわからない、という方々に思いが少しでも伝わっていたとすればうれしいです。

私で良ければアドバイスはできますので、なんかよく分からん!どうすりゃええのか分からん!って人は是非お声がけください。

その他の発表者の方々の様子

写真はこちらにアップしてますので興味のある方は御覧ください。

想像してた以上に色んなトピック満載で、ノウハウの塊でした。ガチ勢から駆け出しの方までみんな満足いく内容だったと思います。

細かい内容は発表者の方や、誰かがまとめると期待して、おもしろかったのが、

  • コスプレ写真をflickrにアップすると死ぬほどアクセスが来る
  • カメラへの感謝を忘れない
  • 筋肉重要
  • M4/3のボケなさが逆にいきることがある
  • やっぱりみんなプロフィールに使われるとうれしい
  • 頭皮がレフ板になる問題(詳細省略)

というあたりでしょうか。

最後に

イベント企画、運営、会場提供をしてくださった加我さんありがとうございました。いや、まじ最高でした。他人を批判する人もいなく、ひたすら持論を延々と述べる人もいなく、ただイベントでカメラを撮るのが好きな人たちが集まった感じで、興ったばかりのコミュニティってこんなんだろうな、と感じるすごく素敵なイベントでした。 そう遠くないタイミングでまたやりたいですね。今度は懇親会をしっかりやりたい。

ではでは。Happy Photo Lifeを。

f:id:nakansuke:20170821214522j:plain

 
 

追記 2017/8/24 13時

ASCIIさんでイベントレポートが公開されました。記事内の写真は私が撮ったものを使っていただいております。やった!

ascii.jp

3年前の今日はSendGridを日本向けに提供開始した日

これはSendGrid Advent Calendar 2016の10日めの記事です。

SendGridエバンジェリスト@nakansukeです。12月10日は自分の誕生日であり、3年前に日本向けのサービスを開始した日でありとても思い入れのある日なんです。

じゃあアドベントカレンダー10日めは自分で書きます、3年の振り返りでも書きます、と言っておきながらいざ書こうと思うと全く筆が進まない。。数字で振り返る、とかしようと思ったけど生々しくて無理だし、色々ありすぎて何を書けばいいのか。。

んでは始まった経緯ではどうかなと思い、日本向けリリースにいたった流れを書いてみようと思います。

2012年11月29日

日本でもビジネス展開をするために、パートナー企業を探してSendGridの経営陣が構造計画研究所(以降、KKE)に来ました。クラウドに特化したビジネスを展開していたわけでもないし、メールに関するソリューションを提供していたわけでもないし、なんで?とよく聞かれるのですが、CEO同士が20年以上の付き合いで、以前からKKEでは彼の会社が提供していたパッケージを代理店販売していました。それだけでなくコロラドとは非常につながりが深く、SendGridのあるデンバーに駐在している社員もいました。

海外企業が日本展開することの難しさをよく理解していたこと、KKEに対する強い信頼感があったことからパートナー候補として第一にあがっていたみたいです。

海外と関われる仕事をやりたい!とその前から積極的に手をあげていた私を、たまたま上司が打ち合わせの場に呼んでくれたことから今に繋がっています。(参加してなかったら今頃何やってたんだろう。。。) ちょうどHerokuやAWSを触って遊んでたときにSendGridも既に使っていたというミラクル。それもあって打合わせでは盛り上がり。米国ではこんな感じだが日本はどうなの?今後どうなると思う?みたいな話をした記憶があります。

その後会食へ。4年も前になるとさすがに若い。。。 f:id:nakansuke:20121129212819j:plain
翌日社長から「よし、中井やってみるか。来週デンバーでイベントやるからそれ手伝いに行って、SendGridとも打ち合わせしよう」と言われ、当然二つ返事で「やります!」と。スピード感が楽しかったですね。久々の米国でテンション上がりまくり。

2012年12月10日

デンバーでうちあわせ。クラウドの日本市場の動向をわかる範囲でまとめて、発表。当時からAWSの話がほとんどでした。次はメール配信サービス市場も調査して、SendGridがどう入っていくかを考えることに。

もう最初からパートナー契約をする前提で進んでいたようでした。

2013年3月4日

調査結果を報告しつつ、ローンチまでに必要なタスクを整理。

契約のこと、Webサイトのこと、日本語ドキュメントのこと、決済処理のこと。

5月に1ヶ月位滞在して、トレーニングを受けたり、各チームとミーティングを持つことに。

2013年5月

1ヶ月くらいトレーニング。ここで一気に理解が深まり。友達もたくさんできました。Hey Kansuke!!と気軽に声をかけてくれる陽気な人達が多いです。楽しい。

f:id:nakansuke:20130519054934j:plain コロラドにはマイクロブリュワリーがめっちゃあります。ビール美味しい。

2013年7月

SendGridチームができる。それまでは基本一人でしたが組織変更のタイミングで5人チームになりました。PLもちらっとやったことがある程度で、マネージメントに関してはずぶの素人だったため非常に四苦八苦。メンバーの方々に支えてもらいました。

2013年8月

Webサイト作成プロジェクト始動。当時クラウドパックのエバだった吉田さんさん経由でアイレットアーキタイプにお願いすることに。

このころ契約も無事形になって一安心。

2013年9月3日

業務提携発表

2013年9月7日

デンバーで打ち合わせして、リリース記念イベントを自分の誕生日である12月10日に設定(笑) これでもう後ろをずらすことができなくなり、まさにケツに火がついた状態。ここからの3ヶ月は思い出したくもないくらいハードだった。。何より時差がつらい。

2013年10月22日

SendGrid Nightを初めて開催。正直メールソリューションっていうので人どれだけ集まるのか、という不安があったものの会場は一杯。最初っからビールも入れて盛り上がって一安心。

ここから後は気合気合気合。色んなコミュニティに顔を出しつつ、Webサイトとか日本語ドキュメント、リリースイベントの準備。

2013年12月10日

Webサイト公開&リリースイベント開催

さいごに

なんか後ろに行くに連れて適当になってしまったw まぁこんな感じで始まったわけです。いつかもっと大きく成長して、その後どんな取組をやってきたか紹介できるようになりたいと思っています。

Developers.IO 2016 で公式カメラマンとして参加してきました #cmdevio2016

2016年2月20日にSAPジャパンさんで開催された Developers.IO 2016 に公式カメラマンとしてお手伝いをしてきました。

Developers.IO 2016とは

ブログの会社で有名なAWSプレミアコンサルティングパートナーのクラスメソッドさんが開催するプライベートイベントです。7トラックで全29セッションもある盛りだくさんでした。

当日はあいにくの雨模様だったので若干申込数に対して少し参加者は減ってしまったのかもしれませんが、それでも350人?ほど参加された大きなイベントです。 日々ブログをたくさん投稿しているクラメソ社員さんはもちろん、ゲストとして多くの社外の方も登壇されているとても豪華なイベントです。参加者としてゆっくり勉強したいところではあるのですが、中の人にお願いされ渋々(といいながらかなり楽しみながら)お手伝いしてきました(笑)

各セッションレポート

は、当然クラメソの方々がめちゃくちゃアップされてますのでそちらをご確認ください (記事数43。すごい・・・)。

なんでカメラマンやってんの

私はプロのカメラマンでもなんでもなく、カメラ歴も5年程度のペーペーですがJAWS-UGやMashupAwardsなどの様子を趣味で撮影し、皆に共有していたらありがたいことに色々なところからお願いされるようになりました。

(大げさですが)一生残るものですし、責任もプレッシャーもかなりあるのが正直なところではありますが、練習にもなりますし基本的にはお願いされたら受けるようにしています。信頼してお願いされるというのはやはり嬉しいものです。

使用機材

大概以下の装備で挑みます。基本的に普段は単焦点派ですが、勉強会やイベントでは明るめのズームも使います。70-200mm F2.8も欲しいけどさすがに重い、でかい、高い。

撮り方

いまだにどうやって撮るのが最適なのかわからないので、こういうの詳しい人に教えていただきたいです。
我流ではありますがイベントの様子を撮るときにやっているのは以下のようなことです。参加者に迷惑をかけないようにするというのを一番気をつけています。

絞り優先もしくはマニュアル設定

基本的にズームレンズの一番明るい設定で固定してISO感度で明るさを調節します。カメラに任せて露出がおかしくなるような場合は、マニュアル設定でシャッタースピードと絞りを固定してとります。しかしいまだに最適な感度が全然わからない。。。ぶれる写真よりは高感度で荒い方がよいとは思うけどそこの兼ね合いも難しい。

フラッシュ使わない

大概勉強会とかこういうイベントは被写体が暗く、かつすぐ横に明るいスクリーンがあり、またプロジェクターの光って特殊なので撮影環境としてはかなり難しいと思います。でも暗い空間でストロボを焚くと参加者に迷惑だし、あと単純に持ってないのでw

連写しない

連写していいのをピックアップするというのもありだとは思うのですが、なんとなく嫌でやりませんw
AF合わせてひたすらいいタイミングが来るのを待ちます。自分が狙ったタイミングで一枚一枚丁寧にとりたいというのとあとうるさいというのもあるんですよね。これは完全に好みです。

気づかれないように撮る

どんなシーンでもカメラ目線をもらって撮る写真がなぜか苦手です。カメラを意識していない自然な様子を切り取るのが好きなんですよね。

当日の様子

f:id:nakansuke:20160220115144j:plainf:id:nakansuke:20160220125819j:plainf:id:nakansuke:20160220130820j:plainf:id:nakansuke:20160220135748j:plainf:id:nakansuke:20160220180020j:plainf:id:nakansuke:20160220175006j:plain

感想

光栄なことに作年に続いて依頼をうけました。昨年の出来が相当よかったらしくセミナー等のプロフィール写真としても使っていただいているそうで。
写真のいいところは、うまく撮ることができれば動画と違って動きも、音もないのにその時の様子をありありと思い出せたり、そのタイミングでは気づかなかったような素敵なシーンを形として残せたりというところがあると思います。まともに撮り始めて以降4万枚くらい溜まってますが、見てるだけで楽しくなったり、あー今だったらもう少しうまく撮れたのになぁと思ったりと面白いです。

スマホでいくらでも綺麗な写真が撮れるようになりましたがしっかりとした機材でいい写真を残すのも楽しいですよ。 と、タイトルと全然関係ない話になってきたのでこれくらいで。