転職ドラフトの体験がすごくいいよ、という話

読み飛ばしていいまえがき

この記事は 転職ドラフト体験談投稿キャンペーン|転職ドラフトReport を見て、ちょっと美味いもの食うか、と思って書いた記事です。 なんですが、記事書いている時点でまだ転職活動が終わっていなくて、

記事は転職ドラフトでご転職の企業への内定承諾日より180日以内に該当フォームから応募されたものに限ります。過去の記事のコピーなどは認められません。

を満たしていないことが書き始めようとした時点で気づきました。 が、まあ転ドラの体験が2度ともとても良かったのでリブセンスさんには感謝しているし1、久しぶりに軽いアウトプットしたい気分だったので書きます2

なので、 こちらの記事は転職ドラフト体験談投稿キャンペーンに参加してい ません

私の転職ドラフト利用歴

僕の転ドラ利用歴を書くと、転ドラで転職2回しています(1個は現在進行中)。 最初は2019年の2回目の転職のときに利用しました。たしか導線はtwitterのPRだったと思います。そのときは転ドラ経由で入社を決めて、今2024年の3回目の転職活動も転ドラを使っています(今面談面接進行中)。

転ドラ、何がいいか

早速推しポイントを語っていきます。

年収の決め方の公平さ

僕の最初の転職はgreenやforkwellなどを使いながら結局GitHubのメールアドレスにDMで来た企業へ入社を決めました。 その企業に決めたこと自体はとても良かったのですが、年収の決め方は今考えるととても残念でした。 こういうときに起きうる不幸が自分を安売りしてしまうことです。 特に最初の転職は本当に自分を採用してくれる企業があるのか不安なので、希望より下の年収を言いがちです。企業側としてはハイスキルな人が来てくれるならどれだけ安くても構わないと考えるところが多いので3、普通に適正年収から百万単位で低い年収になるケースがザラにあります。

僕の場合、後に転ドラを使って当時の自分がどれくらいで入札されるか見てみたところ、やっぱり100万円ぐらいは差があったなあと思いました。

転ドラの場合、複数の企業があなたをこれぐらいの年収で雇用したい、と向こうから提示してくれます。なので、自分を過度に安売りするリスクが低いです。これは転ドラのコアアイデアであり、他の転職サイトにない、非常に優れた仕組みだと思います。

年収についてもちっと書くと、僕は必ずしも高い年収がよいと思っているわけではありません。当然、働く場所が自分にあっているか、事業内容や企業理念・文化がマッチしているかなども人によっては年収より重要ですし4、また自分の成長機会を求めて低い年収でスタートアップに行く、というのもいいと思います。僕の最初の転職はだいたいそういうものでした。 ただ、明確なトレードオフもなく買い叩かれにいくのは反対です。 というのは、年収、言い換えると企業側の社員への投資は期待値でもあるためです。低い年収で買い叩かれるということは、面白い仕事が回ってきづらくなります。重要な役割や大きな意思決定も任せてもらいにくくなります。そういうふうに働きたい、というのでなければ避けたほうが無難です。

選ぶのではなく選ばれることの楽さ

やったことがある人なら分かると思いますが、転職活動はめちゃくちゃ大変です。僕は転職エージェントを使ったことがないのでその場合はわかりませんが、linkedinやgreen-japan, forkwell, マイナビなどの一般的な転職サイトの場合、自分が合いそうな企業を探したり、自分の経歴を見て声をかけてきた企業を無限にフィルタリングする必要があります。これがとても大変です。相手も人間なので断るにしても失礼にならないようにする必要があります。 また、それらを働きながらやる場合は日中仕事をして夜間や休日そういった作業をやる必要があります。とても疲れますし、同僚や会社にいわずに転職活動をしている場合は後ろめたい気持ちもあり心理的に疲弊します。 自分にピッタリの企業があるんじゃないか、もしくは数多の企業内から最良の企業を選びたい、といった心理状況に陥っていると、際限なく時間がかかり、どんどん疲弊していきます。そうなるとどうなるかというと、疲れて早く楽になりたい、という気持ちになり、雑に入る企業を選んだり、逆に転職を諦めてしまいます。

転ドラの場合、向こうがこちらの経歴・レジュメを見て、よさそうだと思ったときに入札してくれます。 これにはいい点がいくつもあります。

1つは企業選びで無限に時間が取られない点です。上記のような終わりのない疲弊を避けられます。

もう1つは、自分では気づいていないけど実はあっている企業や高く評価されるポイントなどが見つかる点です。僕の2回の転ドラ経験で指名を承諾した企業のうち、事前に知っていた企業は半分だけでした。

最後の点は、応募してみたら実は企業側がすでにそのポジションを募集していなくて、能力如何にかかわらず落とされる、という不幸がない点です。これについてちょっと補足します。マイナビやgreen-japanのような募集サイトの記述ですが、企業側が常にアップデートしているかというと必ずしもそんなことはありません。半年・一年ほったらかしで実は内部的にはもう募集していない、もしくは書いた時は緊急性が高かったけど今はそうでもない、といったことが普通に起きています。 で、そんな募集に応募したらどうなるか。最初のやり取りで「今は募集していないんです、すみません」となるのは最も誠実でマシなパターンで、最悪の場合「もう募集していないけどよっぽどいい人物なら取るか」や「募集していないけど募集していないって言ったら怒られるから面接を形だけして落とそう」となるわけです。 このパターンが最悪なのは、自分の客観的な評価と自己評価がずれることです。例えば自分にKubernetesAWSについての確かな経験があり、募集要項にそれらの能力を持つ人を強く募集!と書いてあったとします。その状態で面接を受け、見えない内部事情により実力にかかわらず落とされたとしたら、自分の実力が足りないのかと不安になります。あるいは企業側が不採用の理由として落とした本質ではない、揚げ足取りのような理由を伝えてくるかもしれません。そうなると自分の実力を誤認するわけです。 この点、転ドラは今必要な人材を毎月指名する形になるので、空募集だった、ということはほぼありえません。

雑なリクルートのストレスがない

greenやlinkedin、twitterあるいはfacebookのような媒体でDMにより声をかけられるのはありがたいこともありますが、転職ドラフトに比べて体験が劣ります。 なぜかというと、そういった接触はリクルーターやエージェント側がこちらのことを良く知りもせず乱発しているからです。多くの場合が、プログラミング言語やSRE、Kubernetesなどのキーワードだけを見て声をかけているわけですね。それでカジュアル面談してみると実はお互いがまったくマッチしていなかった、といったことがザラにあります。 また、テンプレートを使って乱発しているからか、こちらが誠実に返答しても先方が返答なしになったり、数日後にやっと返事が返ってくる、のような失礼な対応も多いです5

じゃあ転ドラはどうなのかと言うと、劇的にマシです。 まず、入札企業はこちら側の職務経歴書その他へ目を通しているため、あからさまにアンマッチな指名は行われません。一方で入札される側は非常に重要な要素である年収が入札時点でわかるため、フィルタリングが劇的に楽になります。 転ドラ上でもレジュメを良く確認せず一旦入札を多数行い、カジュ面・面接で大きく絞るようなことをしている企業がないかといえば、たぶんあります。 が、それ実は転ドラのサイト上で簡単にわかります。

2024年3月回参加企業一覧|転職ドラフト - ITエンジニアを競争入札

このページから各企業の過去の入札履歴がまるわかりなので、その企業の社員数と指名数を比べて極端に指名数が多い企業は注意したほうが良いです6

また、承諾率が極端に低い企業も指名された側の多くが指名理由や年収提示に納得していない → よくマッチングを精査していない、という可能性があります。

指名の透明性が高い

前述のグラフなどもそうですが、各種値を隠さず公開してくれるのは非常に信頼できます。 転職市場そのものが企業側と雇用者側で情報の非対称性があり、その気になれば企業側が買い叩くようなことができる関係上、この透明性の高さは非常に好感が持てます。 また、自分が何となく気になっている企業から指名がなかったとしても、その企業がその月まったく指名がないのか、あるいは自分の業種の指名が今月あったのかなかったのかなどがわかるので、自分の実力が足りなかったのか、それとも単に募集していなかったのかなどがわかります。

これも含め僕は転ドラの開発運営から一貫した誠実さ・正直さを感じるのですが、僕が今回の転職でも最初の手段として転ドラを選んだのはこの点が大きいです。

転ドラ、ここは良し悪し

直近何回かの結果を見ると、1名当たりの平均指名数は3前後です。実際には人気のあるエンジニアには多数の入札が入るので、中央値は2ぐらい、0の人もいるのではないかと思います。 あまり指名が少ないと比較もし辛いので、ある程度の入札はほしいところです。

余談

ここからは自分の経験からの推測ですが、ちゃんといい経験をしてきたのに入札が少ない人は転職ドラフト上で職務経歴や目標、野望などのところをちゃんと書いていないのだと思います。僕がこの企業いいなと思って指名を受諾した企業はみんなちゃんと僕のレジュメを読んでいました。あと、単純に量が書けていない = 判断に足るほどの解像度で書けていない、ということもありそうです。僕の場合、職務経歴書だけで2万文字ありました(多すぎるので、冒頭に重要なプロジェクトはこの3つです、と書いてあります)。 この他にも様々項目あるので企業側としてもかなり大変なはずですが、詳しく書いてある分にはその気になれば読み飛ばせるので、なるべく詳しく書いたほうが良いと思います。

転ドラ、ここがイマイチ

僕は転ドラこんなに推しているのに、利用者が拡大していないのが残念です。 僕はこの ①企業側から入札する ②年収の提示がある というのは唯一無二かつ圧倒的な強みだと思っています。なので転職サービスの覇権を取りうるし、体験がいいので取ってほしいと思っていますが、参加人数を見てもいまいち伸びていません。 確かにいろいろ難しそうな点はあって、別種の2つのお客さんがマッチングする必要がある以上、企業側と雇用者側が足並み揃えて育つ必要がある(出ないとマッチング = 入社が増えない)のは、難しそうです。 あと、エンジニアのレジュメを見るのが大変そうなのもあります。募集要項をサイトに載せれば一旦待ちの姿勢でよい外の転職サイトと違い、転職ドラフトは企業のリクルーター自身が1人1人の潜在的な候補者を精査する必要があります。実際僕のレジュメなんてちゃんと読もうとすると30分はかかります。この辺、機械学習やAI技術を駆使してマッチング度みたいなのを推定できればいいのかもしれません。

まとめ

転ドラの良いところを語っていきました。 実際、僕の3度目の転職も転ドラ経由で決まりそうですし、個人的には転職を考えているすべてのエンジニアに使ってほしいと思っています。 現状の自分の市場価値を知るだけでも結構大きいので、転職を検討中のエンジニアはぜひ一度使ってみてください。指名禁止企業という機能を使えば特定企業から見えなくもできるので、現職にバレずに活動もできます。

メモ: この記事は3時間ぐらい書けて書きました。


  1. リブセンスの採用に真剣に応募しようか何度も考えるほどにはかなり好き
  2. 技術系のアウトプット、自分の専門領域なので間違いがないよう気をつける必要が増しており、最近筆が重くなりがち
  3. 実際には安く買い叩く行為は企業側にもデメリットが有るのですが、ここでは割愛
  4. 僕は事業内容や企業理念はあんまり気にしないタイプです。それらを軽視しているのではなく、運用が大事でつまり文化が最重要だと捉えています
  5. 実はこの記事を書くきっかけになったのがこれ。転ドラに比べてあまりに体験が悪すぎて、転ドラのほうがずっとよかったと書きたくなった
  6. 例えば、社員数50名の会社で入札を30人もしているとしたら、乱発気味の可能性が高い

久しぶりにスクラムしながら思ったこと

久しぶりにスクラムっぽい開発をしていて、感じたメリットを書いてみる

そもそもなぜスクラムマスター資格を持っている僕があえてスクラムをしばらくやっていなかったか

要約すると、スクラムの実行に限界を感じていたから。 具体的には、POとSMを置くことが僕の能力ではどうしてもできていなかった。 人員が常に不足する開発では、POSM設置への効果への疑念が常に付きまとう。 それが、自分の中でやるべきと確信できていれば進めることも可能だったかもしれないが、あまりに周りに成功事例がないこと、自分も成功体験が一切ないことなどからうまく進めることが出来なかった。

なので、いわゆるなんちゃってスクラムをやっている。 が、そのなんちゃってスクラムでも割とメリットあるなというのが本記事の主題。

なんちゃってスクラムをやる前

1ヶ月単位でのサイクルは作っていた。 その中で見積もりと今月これしようということはざっくり決めていた。

Issueは切るものの、それぞれの中のリファインメントはあまり集中的にはやっていなかった。 そのため、進めていく途中で新事実が発覚して、大きく見積もりがブレることも多かった。 また、そうやって月にやろうと決めていたことができないことがかなり、というかほとんどだったが、それに対する振り返りは行っていなかった。インフラという部署柄、割り込みがかなり多く、それがいいわけになってより深い振り返りを行っていなかったのはある。

なんちゃってスクラム再開後

1週間のスプリントで開発を回すようにした。 それで、バックログリファインメント、スプリントレビュー、レトロスペクティブ、プランニングをがっつりやるようにした。

まず変わったのは振り返り。 今まで外部要因があるからしょうがないよねといわば言い訳していたのを、きちんと要因を切り分けてKPTで分析するようにした。 正直ここは効果が半信半疑だった。というのは、僕自身はこの手のKPTが有意義に継続的に回ったことがないため。 が、メンバーの一人が外部の経験からKPTをリードすると今までと違うものが見えて、格段に良くなった。これで週次の改善がきちんと回るようになった。 いま時点でざっくり振り返ると、今まで僕がリードしたKPTがうまく機能しなかったのは、チーム内で協力してやるという意識が薄く個別主義的だったからではないかと思う。そうなると個々人の振り返りになり他人のProblemに意見を出したりTRYを出したりすることとが難しくなり、表面的になる。今のチームはチームの方向性が束ねられているからKPTが機能しやすい。それが現状に対する僕の解釈。

話を戻す。あと変わったのはリファインメント。 今までより格段にIssueの計画へ時間をかけるようになった。 今は1週間のうち、Issue記述と周辺調査に2~4時間程度かけている。 一見かけすぎのようにも思えるが、POがいるスクラムではPOがプロダクトバックログを四六時中いじっていることを考えれば、POのいない僕たちがその分Issue記述・調査に時間をかけるのはやむを得ない。 それに、それだけ時間をかけただけの効果を感じている。 この記事を書いたモチベーションはそこで、Issue記述へ週の活動のうち1/10もの時間を割いているが、そのおかげでスプリントゴールが達成できるようになってきた。それは結果だが、中身の実行も質が格段に上がっている。具体的には、事前に実行計画がかなり詳細に立つことで実行に集中することができ、結果的に総合的な工数が下がった。なぜなら、実行中に見つけたり発見した事実のために再計画する必要がなくなり、迷ったり調査したりの切り替えで時間ガロスすることがなくなったため。あとは、その発見によるリスケからの調整にかかる時間が少なくなったのとも大きい。 加えて、見逃せないのがタスクスケジューリングの点。 今までは調査と実行が事実上平行であったため、実行がどの濃度で必要か、どの程度連続してできるかの確度がかなり低かった。なので、スケジューリングしても発覚した事実で外部依頼が必要になり、スケジューリング通りに進まないということが多かった。 その結果としてスケジューリングがおざなりになり、外部依頼が必要なことが事前に予測可能なIssueをスプリントの後半にやってしまい、スプリントゴールが達成できない、ということが何度か発生した。 今は事前計画を細かくやっているため、予測可能性が飛躍的に上がった。それによりどのIssueで外部依頼が必要かもわかるようになったため、外部依頼が必要なものをスプリントの最初に日にしよう、といった判断が可能になった。また、依存関係のあるIssueなどもわかるようになったので、依存関係があるIssueは先に着手しよう、などのスケジューリングも可能になった。これらのおかげで、仕事の単位時間あたりのアウトプットは結構高まったように思う。

なぜエンジニアのスキル成長やキャリア的成長を会社は支援するべきなのか

結論

会社やマネージャーが一切の支援を行わず、社員がプライベートな時間や空間を元に上がった能力は転職でしかほぼ還元されないため。

メモ

  • 良い会社組織・事業組織というのは、RoIが良い組織と表現することができる。例えば、コストをいくらかけてもいいのなら建築設計師1人いなくても東京タワーは建つ。いつかは。コストは数百倍以上かければ。

考えがまとまったら続きを書く。

技術文書を20年読んでやっと最近理解した読み方のコツ

20年ぐらい技術文書読んできて、最近発見したことがある。

昔からずっと英語の技術文書を読んでいて、読み終わったのに理解度が10~50%ぐらいにしかならないことがよくあった。
難しい文書だと何度読んでも理解度が上がらなくて、苦労していたんだけど、最近コツがわかった。
僕は動詞や文章構造の解釈力が足りないのかと思っていたんだけど、シンプルに単語が何を指しているのかわかっていないだけだった。
https://aws.amazon.com/jp/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/
例えば、elasticacheのこの文章の場合、reserved memoryはelasticache固有の意味を持つ。
これを、単なる英単語の「予約されたメモリ」と読んでいてはその後の文章の意味なんて全然わからない。
僕に必要だったのは英語のボキャブラリや英単語力ではなく、ドメイン言語を理解すること、また、どの単語の意味(ドメイン言語)を理解していないのかを自覚することだった。
技術文書で頻出する、この一般的な用語と思いきやそのプロダクト/サービス固有の意味を持つ単語。これを見極めて一つ一つ調べると格段に理解度が上がるようになった。
知らない単語 (熟語)を見つける → 固有の意味を持ちそうか判断 → 持ちそうならglossaryを見たりググって意味を理解する → 元の文書に戻る
このサイクルで、今までより数割早くプロダクトやサービスを理解できるようになったとも思う。

なぜ5年前の僕はレガシーシステムをリプレースできないのか

レガシーなインフラを改善するつもりが組織の悪者になる話 - Qiita

これを読みながら、僕は5年前に所属していた大手IT企業での仕事のことを思い出した。 その企業は日本のIT企業の中でも老舗で、よくある話だがガラケーiモードのときに一山当てて、その後も業態を替えながら1部上場を維持しているなかなかの企業である。

そんな中で、僕は2012年の入社当時から音楽配信事業に関わっていた。 その企業での音楽配信事業は上場するほどの成長の原動力になった中核事業でありながら、スマホシフトできずに衰退している事業だった。僕は、まさにそのスマホシフトへ挑戦し、そして敗北が決定的になるその時期に新卒として5年以上働いた。

当時、僕は意識はそこそこ高いが頭はあまり良くないエンジニアだった。 だから入社後数年経つと、社内のシステムの多くがメンテされておらず、また多くの前向きな活動 - 機能追加やユーザー体験向上 - を邪魔しているのがそれらのシステムであることに気づいた。いわゆるレガシーシステムというやつである。 当然僕は憤慨した。これらのシステムはなぜメンテナンスされていないのか。既存の問題を解決せず、塩漬けされるのかと。既存のシステムへの手入れを回避するために、新たな機能やサービスは別のシステムとして増築され、その結果ますますサービスの全体は複雑化していった。複雑化するのでサービスの改善はどんどん難しくなり、ユーザーはあっという間にapple musicやその他サービスに流れていった。僕らの敗北はどんどん決定的になっていた。

様々な理由を聞いた。このシステムはもはや開発しないと決定された。 これは言語がXXXだからもう開発できない。これはXXXだから、XXX部署の持ち物で・・・。 そうしているうちに僕自身は無力感が溢れ、敗軍の1兵卒として疑問を持たなくなり、負け犬としてふさわしくなっていった。

さて、8年前の僕に、今の僕がアドバイスをしよう。 より良いアーキテクチャ、より良いレガシーの置き換え、最新の言語、考え方を身につけるのと同じかそれ以上に、事業と、眼の前のシステムが事業にどういった影響を与えているのか理解しよう。 それを僕に説明する責務は、誰かのものにしていいものではなかった。それを理解していないからこそ、僕の提案ややりたいことは、本当にお金や時間を使うに値するのかどうか、上司は判断できなかった。僕が本当に目的を果たそうとする場合、それはXXXの責任だから、という言い訳はするべきではなかった。 もしかしたら、いや、おそらくは8年前の時点ですでに逆転は厳しい状況にあっただろう。だが、少なくとも8年前にそういった視点を持ち、上司やその上と議論ができていれば、少なくとも挑戦はでき、敗北することは出来ただろう。

8年前、挑戦することも出来ず、ただただ惰性で日々をすごく僕は、ひどく凡庸で、どこにでもいる、敗北すらできない傍観者だった。

P.S. 約10年経ったが、未だに僕はソフトウェアエンジニアリングにハマっている。 失敗ばかりだが、それでも物を作ることは楽しい。

自炊のコツ

  • 全体
    • 裁断、スキャン、目視の確認。それぞれだけをやったほうが全体の作業効率はよくなるが、裁断が切り詰めすぎていたりスキャン設定がまずいことを似早めに気づくため、5冊ぐらいは順番にやったほうが良い。
    • 裁断とスキャンののそれぞれの最大枚数から、裁断は200ページごとに、スキャンは100ページごとに行うと作業がしやすい
  • 裁断について
    • なるべく端で裁断すると画像が多く残るが、ノリ・接着剤が残りスキャン時に詰まったり紙が引っかかり敗れる原因になる。時間が4倍かかるようになるのでノリが残らない程度に切るのがよい。
  • スキャンについて
    • 百ページごとにスキャンすると、あとで飛ばしていないかの確認が楽になる
    • ノイズはスキャン部のガラスに残ったノリ。固まっていて手触りでわかるものもあるがノイズとして触ってもわからないものもある。アルコール液とティッシュでかなり強めに拭き取ること。
    • スキャン設定について
      • エクセレントは画集などの一部だけにする(遅い)。基本はスーパーファインでOK
      • ホワイトぺージ飛ばしは無効(削除はあとからできる)
      • カラー白黒判定は無条件でカラー固定(白黒の画質が微妙&白黒にはあとからできる)
      • 小説などの小さいものは横に倒してスキャンすると紙が滑り落ちず良い。
        • 2018/06頃にやったときは横に倒すと文字が傾いてスキャンしてしまいがちだった。よくないかも
      • 右90度回転の右・左綴じが小説に最適
      • 継続読み取りは有効がおすすめ
      • 読み取った紙の端にノリがつく気がするので、大きな本から順に単行本までスキャンすると良さげ

スクレイピングについてのライオットのスタンス(原題: Riot's stance on Scraping)

元URL: [Riot's stance on Scraping \- Riot Games API](https://developer.riotgames.com/discussion/announcements/show/oklxAP21)

Riot's stance on Scraping
スクレイピングについてのライオットのスタンス
submitted about 2 years ago in Announcements by Riot Sargonas
ライオットサーゴナスによる2年前に投稿されたアナウンス

I wanted to share some updates regarding the Riot API and other LoL data.
私はRiot APIと他のLoLデータについてのいくつかの更新について共有したい。

When we released the Riot API, we had many goals in mind. The biggest, naturally, was to help empower folks like you to build amazing content for the League community.
私達がRiot APIをリリースしたとき、私達は心の中に多くのゴールがあった。その中で最も大きく、自然なゴールはリーグコミュニティのために素晴らしいコンテンツを構築するあなたのような人々を支援することだった。
We also wanted to help provide a unified resource for accessing data, rather than relying on janky workarounds and undocumented resources.
私達はまたゴミのような代替案とドキュメント化されていないリソースの代わりに、データアクセスのための統一されたリソースを提供したかった。
We've been hard at work trying to level up what the API offers over the last few months, and we feel like it is starting to reach a state that truly empowers our community to build off of.
私達はここ数ヶ月の間に求められているAPIについてレベルアップを試みよく働いた、そして私達は(build off ofするための)私達のコミュニティを真に支援する状態にたどり着き始めたと感じている。


We've now reached the point where we need to focus on another one of our key goals with the API: to help relieve stress on our live services.
このAPIの私達の鍵となる他のあるゴールへフォーカスする必要がある点まで私達は今たどり着いた: そのゴールとは私達のライブサービスのストレスを和らげる手伝いだ。
Prior to the existence of the Riot API, many parties relied on scraping our live service platforms to obtain information.
このRiot APIの存在より前、多くのパーティが情報を取得するために私達のライブサービスプラットフォームへ依存していた。
We allowed this process to continue as we rolled out the API over the last few months
このAPIを公開したここ数ヶ月にわたって私達はこのプロセスの継続を許容した
(even though we did include provisions against doing this in the API Terms of Use because we understood the API was a fledgling service at the time.
(API利用規約の中でこれを行えるように条項を含めたあとでさえ、なぜなら私達はこのAPIはこの時点では出来立てのサービスだったから.
We’ve reached the point, however, where we need to move forward with phasing out 3rd party reliance on scraping.
しかしながら、私達はスクレイピングについての3rdパーティの頼りを段階的に停止させていく必要がある点に達した。
Scraping can cause occasional stability issues for us, and most importantly, it also increases the complexity and difficulty for Riot to detect and fix problems with our Live Services without first sorting through the “white noise” of these extraneous connections.
スクレイピング不定期の安定性問題を私達に引き起こす可能性があり、そして最も重要なことは、それはRiotにとって私達のライブサービスの問題発見・解決をより複雑かつ難しくさせている、これらの例外的な接続の"ホワイトノイズ"を最初にソートし終えることなく。
We need to be able to focus on giving players the most reliable platform as possible, and removing this variable from the equation will go a long way towards that.
私達はプレイヤーたちに最も信頼できるプラットフォームを可能な限り提供することにフォーカスする必要がある、そしてこの方程式からこの変数を除去することはそれに叶うだろう。


Because of this, we've decided to establish a deadline of October 1st for all 3rd parties to discontinue the practice of scraping our live services.
これらの理由により、私達はすべての3rdパーティのために10/01の締め切りを設けることを決めた、そこで私達のライブサービスのスクレイピングの実践は継続されなくなる。
Moving forward from that date, the only authorized method of communication with the Riot systems will be through the API itself, per the API Terms of Use.
この日より先は、Riotシステムとのコミュニケーションの認証された方法はこのAPIそれ自身を通してのみとなり、このAPI使用規約。


We understand that this may have a direct impact on how some sites currently function, however as always our first focus is on providing the best experience for the players, and the reliability of our platform plays directly into this.
私達は理解している、これは直接影響があるかもしれない、いくつかのサイトの今の機能に、しかしながら私達の最初のフォーカスは常に最高の経験をプレイヤーに与えることであり、そして私達のプラットフォームの安定性はこれへ直接影響する。

However, while it might change some of the user experience, we feel the majority of these issues can easily be overcome by creative solutions using existing data in the API.
しかしながら、それはユーザー経験のいくらかを変更するかもしれないのに対して、私達はこれらの問題の大部分は簡単に克服できると感じている、このAPIの存在するデータを使用する創造性に飛んだ解決策により。
We’re also committed to working to bring some of the data unique to RTMP calls to the API at a later date.
私達はまたいくらかのデータをもたらすための仕事にも協力している、後ほどこのAPIを呼ぶRTMPコール。
However, we cannot commit to a time frame at this time due to a vast quantity of work needed to establish this functionality.
しかしながら、私達はこのときはまだこの時間帯をコミットすることはできない、なぜなら膨大な量の仕事がこの機能を確立するために必要であるから。
Therefore, it is unlikely that it would be completed before the 1st.
これにより、それは1stより前に完了しないかもしれない。


We know this is a lot to digest, so if you have any questions, we’re here!
私達はこれが多くのことの要約であることを知っている、もし質問があるなら私達はここだ!


(edit - we should probably be clear that all of this applies to "Riot Regions", that is, Regions where Riot runs the systems and not our partners like Garena.
(追記 - 私達はおそらく明確にするべきである、この適用の"Riot領域"のすべてについて、それはつまり、Riotがこのシステムを実行する領域とGarenaのようなRiotではない私達のパートナーについて。
In those regions how they wish to craft policy around this is up to them, as they handle the live systems.)
これらの領域ではかれらはこれは彼らに委ねられておりポリシーの工作をしたいと思っている、かれらはライブシステムの制御をしているように。


(edit 2 - As to the spectating question, this does not apply to the spectating and generation of replay files by op.gg and other sites.
(追記 2 - この観戦についての質問にように、これは観戦とリプレイファイル(op.ggと他のサイトによる)には適用されない。
They are welcome to keep this functionality for the time being and we hope one day to maybe even add spectator based replay generation to the API to make it easier for all, possibly.)
かれらはこの機能の維持をさしあたっては歓迎しており、私達はいつの日にか観戦ベースのリプレイジェネレーションのためのAPIがすべてを簡単にすると願っている、たぶんね.)