キミは何故会社を辞めたのか?(その2)/// B社編 ///

前回の僕のリアルな退職理由は意外にも沢山の方から面白いと言ってもらえたので、その勢いで第二回に突入しちゃいます。 前回は結構固めな文体でしたが、皆さんのコメントで調子がでてくればちょうど読みやすい文体まで砕けていけそうな気がしますので、是非コメントもお願いします! で、今回はB社のケースで掘り下げていこうと思います。「あれ、何でA社からじゃないの?」と思われたかもしれませんが、もともと時系列順ではないので、ご容赦くださいませ。 スーパーリベラルなB社 当時のB社はベンチャーの自由な空気が充満していて、若者が夢中で働く会社でした。何より良かったのは、なんの政治もなく、誰が言ったかより何を言ったかで議論ができるスーパーリベラルでめっちゃフェアな会社だったことです。こんな会社で働けることは二度とないだろうと今でも思っています。お世辞ではありません。 入社の面接では 「どんな仕事をしたいですか?」 と聞かれ、ほとんど何の希望もなかったので、 「特に無いです」 という答えが脳裏をよぎったのですが、流石にそれじゃまずいと思い、 「そうですねえ、御社で一番難しい仕事をやらせてください」 と答えました。そう言った方がカッコいいだろうという理由でしたが、、、 そして社長との会食でも意気投合し、「じゃ、やりましょう」と酔った勢いでめでたく内定となりました。オファー面談でサインをする時に「それで何をするんでしたっけ?」と聞くくらい何をするかはどうでもよかったのです。 あと、選考には出てこなかったけどオファー面談に登場した若者の眼光がやけに鋭かったのが、強い印象として残っております。   初日からクレームの嵐 初日から、自分に与えられた中古パソコンが「ボロい」とか、「コピーどうやってとるの?」とか気を遣わず言ってたら、その翌日には社長のところに「あいつは何様なんだ」というクレームのメールが何通も届いたらしい。 入社早々、社長から呼び出しをくらい、 「何様のつもり?」 と叱責を受けることになります。 思わず 「俺様ですが何か?」 と答えそうになるのをギリギリグッと堪え、 「何のことっすか?」 にとどめた当時の不遜な僕を褒めてあげたいです。 (その答えもあかんヤツだけど) そして気づいたらあの眼光の鋭い若者が自分の上司ということになっておりました。 入社早々新規事業に取り掛かるのですが、協業先から 「あんなに感じの悪い男は社長にできない」 という謎の強力な圧力があり、責任者のはずなのに何故か代表取締役ではなく、平の取締役に就任することになります。 感じよくするのって本当に大事だよな、と今更ながら思いますが、もう第一印象悪いキャラ固定化されていて今更変更するのは生物学的仕様上かなりの手戻りが発生するので厳しいらしいです。(涙)   第六感的プロジェクトマネジメント 当初システム開発をえんえんやることになりますが、ガチ文系商社マンだった自分には完全未体験ゾーンです。それでも優秀なエンジニア達が助っ人で参加してくれたり、NTTデータやIBMから上手いこと言って優秀な若者を引き抜いてきて、プロジェクトはなんとか進行していきます。 要件定義の会議はなぜか20人位いて、 「ワシいらんやろ」 と思いつつも一応参加しておりました。 しかしこれが眠いの何のって。ほぼ90%は目を瞑って下を向いておりました。国会中継でもよく見る絵です。 こいつは寝かしといてあげよう、というコンセンサスがあったかは知りませんが、2時間に1回、ばっと顔を上げて 「それ違うんじゃない?」 と発言すると大体何か問題があり、部下からは 「あいつは寝てても間違いがわかるらしい」 と変な切り口で少しリスペクトされることになったようです。   全国ネットでディスられる ようやくサービスローンチを迎えました。 すぐに30%の利用率になる想定だったのが数%にしかならず 「これまた地獄ですか?」 という状況でした。 年下の上司には定例で毎週報告していました。とても頭がきれ、数字の記憶、ロジックの展開には一部の隙もありません。 「こいつ天才かいな」 と認めざるをえないんですが、負けを認めるみたいでそういうことは口に出しませんでした。 そして社内サービスの連携で「お願いします」とこちらから頭を下げて協力してもらう、といった社内調整も意地になってしませんでした。 その上司も会社の主力サービスの一部機能を最速で実現するためさっさと外注してしまい、その機能を開発したかったこちらは後で知るという事もありました。 お互い胸襟を開かないというのはまさにあれだったかと思います。 … Continue reading キミは何故会社を辞めたのか?(その2)/// B社編 ///

キミは何故会社を辞めたのか?

ここ数年、転職のお手伝いをしていますが、本当は転職なんかせずに、今の会社で認められ、昇進し、待遇も上がっていけば、それが一番幸せなんじゃないかと思います。 それでも、なんらかの理由で会社を辞めて、転職をしようと思う人は昨今ますます増えています。 そうした転職準備の過程で退職理由というのは、採用面接においても必ず質問されることである為、すべての求職者が適切な回答を用意する必要があります。 仕事柄自分は様々な退職理由を見たり、聞いたりして、結構な割合で他責な理由しか述べられないという感想をもっています。 私のリアルな退職理由 私自身は、これまで何度も転職をしていて、自分の退職理由は、パブリックにはほぼ前向きなもの(面接で適切に聞こえる)にしています。 それは嘘ではないんですが、実際にはそれ以外にも、色々な要因があったりします。 当時を思い返して、その時のリアルな退職理由を書き出してみるとこうなりました。 A社: ベンチャーに日本市場責任者として入社するも、速攻で買収される。その半年後にはようやく採用できた初期チームの半分以上の人員を解雇せよとの命令を受ける。解雇をせずになんとかビジネスを継続させるべく他の関連会社との組織統合を主導した後、更に買収されるという事態と政治的な動きに翻弄され退職を決意。 B社: 数億円を投下した新規事業を責任者として数年かけてなんとか単月黒字化までもっていき、立ち上げに成功するも、B社の給与水準からかなり高めで入社した為、ずっと年収はあがらず、最後の年俸交渉において現状維持といわれ0.5秒で辞めると回答。 C社: リストラで、不本意ながら全く畑違いの部署に放出されたところ、運悪くパワハラ四天王の一人、増長天の番頭代理になってしまい、激務とパワハラで激ヤセ。そこではもう絶対に浮かばれないと観念し転職を決意。 D社: よせばいいのに買収されることが決まった後の外資日本法人に入社。最初は社長の太鼓持ちかと白い目でみられながらも、寝ずに仕事して、社内での信頼も得られたが、結局半年後の組織統合時にクビ。 E社: 初っ端、大事故が発生するなど、散々の船出ではあったが、なんとか事業を軌道に乗せることに成功し、株式上場を経験。しかしIPO後、自由な雰囲気は徐々に失われていくとともに、自分のそれ以上の昇進は望めず、新たなチャレンジを求めて転職。 こうして事実に忠実に書くと、散々失敗したキャリアに見えてしまいますね。 他責な退職理由 それでも、お気づきになられたかもしれませんが、ほとんどが自分のせいではなく、他人のせいにしております。 人に何かを説明する時、人は自ら自分の過失を話すことはできず、どうしても人のせいにしたがるものです。そうして他責な退職理由が量産されるのでしょう。 しかし本当に100%他責要因で退職する人などいるのでしょうか? どんな場合も過失割合は100:0にならないのではないでしょうか? なんでもかんでも自分の過ちにしろと言っている訳ではありません。一部でも認める方が、客観的には、事実に近く正直に話をしているとみられるはずです。 「いやいや、そんなやっぱり会社が悪いんだよ、自分のせいではないよ。」とおっしゃる方もいらっしゃるかもしれません。 私も自分にはなんの過失はないと思っていたタイプでした。 でもそれでもなにか自分の過失がないか、改めて掘り下げてみたところ、そうですやはりたくさんありました。 というよりも、どの場面においても私に非があったと思います。(多かれ少なかれ) 次回は、とても恥ずかしんですが、何が自分の過失だったのか詳細に振り返ってみたいと思います。

動画エンジニアの祭典Demuxed 2019のセッションハイライト -大規模ライブ配信での動画広告のパーソナライゼーションにおける課題とその解決策

10月23日、24日の2日間にわたってサンフランシスコで開催された動画エンジニアの祭典Demuxedで、数千万同時視聴があるような大規模ライブ配信に於いて広告サーバーの負荷を減らしつつ動画広告をパーソナライズして配信するというセッションがありましたのでご紹介します。 日本でも同時再送信が解禁された昨今、それに付随してくる動画広告をいかに効率的に配信するかというノウハウは知っておいて損はありません。 続きを読む...

動画エンジニアの祭典Demuxed 2019のセッションハイライト - エンコードの工夫編

10月23日、24日の2日間にわたってサンフランシスコで開催された動画エンジニアの祭典Demuxedで、エンコード処理に工夫をすることでビットレートを削減したりエンコード時間を短くしたりするというセッションが2つあり、2つとも興味深い手法だったのでご紹介します。 続きを読む...

年に一度の動画エンジニアの祭典Demuxed 2019に参加してきました

年に一度、世界中のネット系動画エンジニアが集まるカンファレンスDemuxedをご存じでしょうか。 今年のDemuxedは10月23日と24日の2日間にわたってサンフランシスコのイベントホールThe Midwayで開催され、登壇者38名による33セッションおよび3分間のライトニングトーク15本、参加者750名以上と、ネット系動画エンジニアが集まるカンファレンスとしてはとても大規模なカンファレンスです。 続きを読む...

SportsPro OTT に参加して – #4 スポーツ動画配信に対する大規模な海賊行為の実例

スポーツ動画配信事業者向けのイベントSports Pro OTTサミットのセッションの1つ『The dark side of live sports: Investigating large-scale pirate networks』の中で紹介されていた大規模な海賊行為の事例をご紹介します。 どれぐらいの規模で行われているのか 一般的に海賊行為というと、会社組織 v.s. 会社組織ぐらいの規模のものを想像するかと思います。 しかし、本当に大規模な海賊行為は国対国のレベルで行われています。 中東にカタールという国がありますが、カタールは隣国のサウジアラビア、アラブ首長国連邦(UAE)、エジプトなどから反目されていて、最近では2018年12月3日にカタールがOPECから脱退するという発表もなされていました。それらカタールとその隣国間で海賊行為とその戦いが繰り広げられているのです。 beIN(カタール) 対 beoutQ(隣国) beINは、カタールを拠点とする放送局アルジャジーラからスピンオフする形で2012年にスポーツ専門の放送局としてオープンしました。彼らはMENA地域(中東と北アフリカ)でインターナショナルチャンピオンズカップの独占放映権を持っているなど、MENA地域では有力なスポーツ専門放送局です。 対して、beoutQというサウジアラビアが背後でバックアップしている言われている海賊行為事業者が突如2017年8月に現れました。beoutQではbeINから盗用してきた海賊版コンテンツを視聴することができ、さらに、国という大規模な組織力を生かしてbeoutQ視聴用のセットトップボックスを製造・販売するなどの力の入れようです。   beoutQはIPベースの配信であるため、『ケーブルテレビや衛星の届く範囲』という軛を逃れ、ヨーロッパ全域はもちろんのこと、遠くはアメリカのフロリダでも海賊版コンテンツが視聴できてしまうという有様。 また、スポーツというコンテンツはドラマや映画などに比べて言語の壁が薄いコンテンツであるため、海賊版コンテンツがより広がりやすいという特徴があります。   海賊版に対して更に海賊行為を働く事業者も 海賊版コンテンツは前述の通りライツホルダーに対して莫大な放映権利料を支払うことなく配信されています。そのため、放送コンテンツに対する保護も正規版コンテンツに比べると弱い状態で配信されていることが起こりがちで、その保護の脆弱さを突いて海賊版コンテンツに対して海賊行為を働き、それを海賊版配信するということも起こっています。 beoutQの場合、南アフリカのStartSatがそのようなことをして、海賊版の被害を更に拡大させていました。   大規模海賊行為で海賊行為を働いている事業者を特定することの難しさ 一般消費者が行うようなカジュアルな海賊行為であれば、ウォーターマークを利用して誰が海賊行為を働いているかを特定し、その契約者IDへの配信を止めるというようなことは割と容易に行えます。 しかし、beoutQのような国がバックについている大規模かつ組織的な海賊行為の場合、次のような難しさがあり、海賊版放送を止めるのには時間がかかります。 ウォーターマークが無効化・弱体化されている(そのため、どの契約者IDから漏れているかがわからない) 海賊行為を働くためのハードウェア・ソフトウェアが国をまたいで設置されているので、海外の司法機関と連携して対応に当たる必要があり、足並みの調整に時間がかかる それらの装置を海賊行為事業者がリモート監視している場合があり、警察が踏み込んできたなどといった異変を見つけたらリモートから破壊して証拠隠滅を図られてしまう 実際、beoutQが2017年8月に海賊版配信を始めてから訴訟を起こされるまでには14ヶ月の時間がかかっています。   beoutQはどうやって特定に至ったのか 大規模かつ組織的に海賊行為を働いていたbeoutQはどのように訴訟されるに至ったのでしょうか。 まず、beoutQのWebサイトで利用しているCDNの支払履歴にSelevision(UAEのIPTV事業社)のCEOの名前Raed Khusheimが載っていたというところから足が付きました。次に、さらなる証拠固めのため、beoutQのセットトップボックスの通信パケットを解析したり、セットトップボックスのソフトウェアをリバースエンジニアリングするなどしてSelevisionが深く関わっているというさらなる証拠も見つかりました。   そのような数々の地道な調査を経て、2018年10月にbeINはbeoutQの裏側にいるサウジアラビアに対して10億ドルの訴訟を起こすことができたのでした。

SportsPro OTT に参加して – #3 デジタル配信の海賊行為への対抗策ウォーターマークを知る

ウォーターマークの挿入方法を知る 前回のポストでは、海賊行為事業者が海賊行為を行う理由と、海賊行為への対策としてDRMとウォーターマークの2つを紹介しました。特にウォーターマークは法的措置を執るに当たって重要なテクノロジーであることも述べました。 海賊行為への対抗策として有用なウォーターマークですが、映像データに挿入する方法としては大きく分けて3種類の方法があります。 (1)サーバー側で動的に挿入する 配信事業者側のコントロール下にある配信サーバーやCDN側で映像データにウォーターマークを動的に挿入するという方法です。ウォーターマーク挿入処理を海賊行為事業者の手の届かないサーバー側で行う方法であるため、ウォーターマーク自体の堅牢度は非常に高い方法です。 しかしながら、2点ほど課題があり、あまり採用が進んでいない状態です。 まず、サーバー側での動的なID埋め込み処理に対応したハードウェアやソフトウェアなどのインフラが必要であると言うこと。ただし、最近ではAmazon AWSがNAGRAのNexGuardをCloudFrontに統合したということもありインフラを用意する敷居は多少下がってきました。 しかし、この手法の根本的な課題として、サーバー側で映像データを一旦デコードするなどし、動的なID埋め込み処理が行えるような状態に準備する処理が必要という点があげられます。ハードウェアの支援はあれども映像のデコードや前処理のための計算処理はそれなりに時間がかかるため、ライブ配信では利用することができなかったり、VODでも配信インフラをウォーターマークを考慮したものに設計し直す必要があるため、導入のためのハードルは高めになっています。 (2)2種類のウォーターマークの切り替えパターンで加入者IDを表現する サーバー側でIDを埋め込む方法の効率の悪さをカバーする方法として、2種類のウォーターマークの切り替えパターンで加入者IDを表現するという方法があります。 AとBという2種類のウォーターマークを用意しておき、契約者(1)に対してはAABBAA、契約者(2)に対してはABABBAとみせて、パターンの違いで識別するという方法です。 この方法であれば、1つの映像素材に対して2種類のウォーターマークを載せたデータを用意しておくだけで良いため、サーバー側に要求される負荷は比較的低くなります(ただし、エンコーディング費用とCDNのストレージコストは2倍になります)。 この方法の欠点としては、まず、加入者IDを特定するまでの時間の長さがあげられます。2種類のデータの切り替えパターンを使うため、20回の切り替えを行ったとしてようやく104万通りのIDを表現することができます。1回の切り替えを6秒で行った場合、20回の切り替えには120秒かかります。 次に、クライアント側をある程度堅固にしておかないと、海賊事業者に切り替えパターン自体を操作されてしまい加入者IDが特定出来なくなるということがあげられます。 切り替えパターンは、クライアント側に渡ってくるマニフェスト(どの順番でどのファイルを再生するかが書かれたファイル)上に記載されています。クライアントが脆弱だとマニフェストファイルを書き換えることで、A/Bそれぞれの切り替えパターン自体を操作されてしまい、結果契約者IDが特定出来なくなってしまいます。 (3)クライアント側でウォーターマークをオーバーレイする ウォーターマークでは一番よく使われている方法です。クライアント(≒プレイヤー)側でウォーターマークを映像信号にオーバーレイして画面上に描画するという方法です。 前述の2つの方法と比べたとき、既存の配信インフラに手を加える必要がないというところが大きなメリットです。また、ライブ配信のような即時性を求められる配信に対してもウォーターマークを差し込むことができます。更に、映像データの上に何らかの画像データを乗算するというのは比較的軽い処理であるため、CPUやメモリーリソースが限られている小型のハードウェア上でも実行可能です。 欠点としては、ウォーターマークが入っていない映像信号がクライアント側まで来ているため、クライアントの作りを堅固にしていないと生信号をそのまま取られてしまいかねないということがあげられます。 しかしながら、サーバー側での動的挿入も、A/Bパターンの切り替えも、クライアント側が脆弱であればこれらのウォーターマークを破る突破口を与えてしまうという点ではあまり変わりないため、クライアント側オーバーレイ固有の欠点というわけではありません。