はてなキーワード: バックエンドとは
そのネットワークシステムの分散化を目指すことが発表され、再びSNSの分散化へ注目が集まっている。
Twitter is funding a small independent team of up to five open source architects, engineers, and designers to develop an open and decentralized standard for social media. The goal is for Twitter to ultimately be a client of this standard. 🧵— jack 🌍🌏🌎 (@jack) December 11, 2019
この発表は日本語圏でもテック系を中心とした様々なWebメディアが取り上げており、日本でも注目されている。
Twitterのこの発表は驚くべきことだ。何故なら誰でも参加できるオープンなAPIプロトコルを整備するということなので、これまで開発・運用されてきたWebコミュニケーションサービスによって結論付けられたものと逆行した動きだからだ。
この結論はテック系で持て囃されているチャット系WebサービスSlackの例を出すのが理解しやすい。
一時期チャット系サービスではXMPPというオープンなプロトコルを採用するのが一般的だった。これはYahoo!メッセンジャーでもGoogle Talk(現ハングアウト)でもMSNメッセンジャーでもFacebookメッセンジャーでも採用されているプロトコルだ。
しかし、Googleはハングアウトの展開と同時にXMPPのサポートを辞めることを発表しXMPPの流れが変わった。
XMPPを採用しているとすべての会話ログをユーザは得ることができる。会話ログというのはコミュニケーションの歴史であり、ある時は強力な証拠となり、それは貴重な資産であることは明らかだ。
だからこそSlackはXMPPのサポートを辞めた。Slackの有料プランにある検索機能が意味をなさなくなるからだ。ユーザは別にSlackへ課金せずともXMPPを介して手元へ全ての会話ログを保存し検索できた。
ビジネスとして見るならばGoogleやSlackの判断は理解が可能であるし、だからこそ何度となく資金難が騒がれているTwitterが会話ログへ自由にアクセス可能なAPIプロトコルを整備しようとすることに一部の有識者は驚きを隠せないのである。
ある有識者たちは言う
「会話ログのマネタイズよりも通信コストを抑えたほうがTwitterとしては低コストとなる試算が出たのではないか」
「分散化をするとして現在Twitterの収益の中心である広告配信システムはどうするのか」
「Twitterが握っているシェアを分散化するとは考えにくい。Twitterの言う分散化とはメッシュ型分散化ではなくTwitterをトップとするツリー型分散化なのではないか」
「Twitterは言論の管理に疲れ果て、各国の分散Twitterサーバ管理者へ言論の管理を任せるのではないか」
様々な憶測が流れ、更にはジャック・ドーシーはブロックチェーンにまで言及したため仮想通貨界隈の魑魅魍魎までもが反応してしまうという事態へ至っている。
SNS分散化において最も理解ある集団と言えば間違いなくActivityPubプロトコル界隈だろう。
より理解しやすい表現をするならば、こう言えば良い「Mastodon界隈」だと。
ここに来てドワンゴやpixivがマネタイズへ失敗し、Mastodonブームの際にインターネットユーザからTwitterとの違いがわからないと一蹴されたMastodon界隈が、Twitterの分散化方針の発表により最大の理解を示すというのは何ともドラマティックである。
正確にはMastodonがサーバ間通信へ利用しているプロトコルがActivityPubであり、ActivityPubを採用しているのはMastodonだけでなく他にも数多くの分散SNSが存在しており、ActivityPubを採用している分散SNSは相互に通信可能なので、Mastodonをも含んだActivityPub界隈はTwitterの分散化へ興味深く関心を寄せている。
それは「分散Twitterの登場を待つ」「既にあるActivityPubへ投資する」の二択である。
現在、日本語圏でSNSの主流になっているTwitterの分散化方針は示された。この方向性は数年後はわからないが数カ月で変わるような方針ではないだろう。
なぜ数カ月で変わらないのかと言えば、Twitterは既にバックエンド開発でBitTorrentを用いたP2P分散化による運用をしているからである。つまりTwitterにはもう既にある程度のネットワーク分散化のノウハウが存在するのだ。
分散化のノウハウがある中でTwitterはユーザが体験するサービスまでも含めて、わざわざ専門チームまで立ち上げつつ、分散化の方針を示したのだ。これは本気度が高くなかなか変わりようがない。
問題はTwitterがどのような分散化をするのか現状では一切わからないことである。
Mastodonのようにセルフで分散Twitterサーバを立ち上げられるのか、許可制の代理店方式か、単にAPIを利用できるのか、全くわからない。
しかも、先例であるActivityPubは主にITエンジニアリング界隈からの評価が既に定着しており、分散SNSの開発速度は現状で間違いなくActivityPubの方が速い。来年の仕事始め2020/1/6からActivityPubでSNS開発を始めようと言えば始められるくらいに速い。
IT業界、特にWeb界隈は移り変わりが速く、しかも先駆者が強い傾向があるのは明白だ。分散Twitterを待ってActivityPubがデファクトスタンダードへのし上がったときは目も当てられない。
しかし、ActivityPubがデファクトスタンダードになるかはわからない。シェアをどちらがより多く獲得するかは神のみぞ知るというところだ。
どこのサービスを真似してください
たまに来る依頼がこんな感じ。
頭に綿でも詰めてるんですかってくらいのリテラシの低さとビジネスモデルを提げて、自信満々でやってくる。
大体リソースさけませんで断り入れるけど往々にして巻き込まれる。でもってなんとか片付けてきた。
でもそろそろ気付いて欲しい。
ビジネスモデルがクソなら売れないし、金のかからないプロダクトなんて知れた機能しか使えない。
AI使うにしても使わなくてもできますが?と言うと売り文句として使いたいんだとか。
いくらまで運用費かけますか?の質問で20kと答えられた時の絶望感。
心の中でできねーよボケ!と思いつつ最善策を出す日々。
意外と知られてないのはSaaSに関しては見積もりが出しにくいこと。当然ながらフェイルオーバー対策するとそれなりの額はいくし、レンサバみたいな定額制じゃなくて従量制。それにその時点で目標PVを聞くと答えられないケースがほぼ。
大体この手の客はレンサバの費用間で掲示してくるのが常。で、バックエンドとフロントエンドの金額感が混ざってる。
アホか!
動画全部一括で落とさないと検索出来ないとかアホか。アプリ開発のど素人か!
最近無限スクロール実装したと思えば、一度に取ってくる件数少なすぎだし
アホか!てめーでバックエンド改修しろ!PHPだかRubyだかしらねぇが大したことない修正だろうが。工数半日だ馬鹿野郎
1ユーザーが購入してる件数なんて大したことねーだろうが、バックエンドでsqlのlike検索で十分だろうが
つかちと前なんて購入済み動画とかお気に入り一覧表示するの遅すぎだったぞこら!
ど素人からオメーら金あんだろ!機能改善のペースも遅すぎんだろ!
最後にもう一回
10/28 に行われたGo言語のカンファレンスに参加してきました。
いつからGo conferenceが行われているのかはよくわかりませんが、例年春と秋に開催されるのが通例のようです。
今回私は、Wantedlyが行う「学生応援支援プログラム」という枠組みの中で参加することになりました。学生応援支援プログラムというのは、学生に対してカンファレンスへの参加に伴うチケット代や、会場までの交通費を全て負担してくれる制度です。詳しくは https://boards.greenhouse.io/wantedlygoscholarship/jobs/4459011002 を参考にしてください。
Go conference 2019 autumnに限った話だと、Wantedlyの他にも同じようなプログラムを実施している企業がいくつかありました。
今後もそのようなプログラムが実施されることがあると思うので、学生に限った話ではありますが、興味がある人は応募してみるといいと思います。
ここからは私が今回のカンファレンスに参加しての感想を書いていきます。
私は、大してプログラミングの経験があるわけでもなく、技術力も高いわけではありません。Go言語に関しても今回のカンファレンスに参加する半年ほど前から触り始めたというレベルでした。それでも、そのくらいの経験値の人が特定のプログラミング言語をテーマとするカンファレンスに参加して何か得るものは有ったのか、みたいな視点で書いていきます。
今回参加して良かったと思えたことの1つは、Go言語そのものに限らず、幅広い知見が得られたことです。カンファレンスの各セッションで触れられる話題というのは、コンパイラやアセンブラなどの低レイヤな話から、テストや設計に関する普遍的な原則、また比較的新しい技術スタックを使用したプロダクトを開発・運用していく中で得られた発見など、かなり多岐に渡ります。そのため、Go言語をテーマの主題としつつも、普段であれば自分から能動的に掘り下げない分野・領域についての話を聞くことができます。
これは、私にとっては特に嬉しいものでした。私は、Go言語を使ってAPIサーバのバックエンドを実装したり、簡単な CLIツールを作ったりしたことがあるのですが、その時に自分で調べることは、あくまでも目の前で分からないことがあって、それをどうすれば解決できるか、という狭い範囲についてでした。
そのような狭い範囲の探求を繰り返すことも開発を進めていくためには重要ですが、自分が経験したことの無い領域、また自分が詳しくは知らない領域について学習することも大切だと考えています。しかし、そのような領域についての学習は自分の中での優先順位が低く、かつ調べるためのキーワードすら分からないので何をすればいいかもよく分かっていない、という状態でした。
そのような一種の停滞状態を打開するものとして、今回のGo conferenceは絶好の機会でした。
これは、今回のGo conferenceに限った話ではなく、他のconferenceや技術イベントについても言えることだと思いますが、自分の知らないor詳しくはない領域についての学習を続けることで、技術に対する新陳代謝(?)のようなものを常に保っていくための機会は大事なものだと思います。
アプリケーションエンジニアをやっているとしばしばお客さんにイライラすることがある。
下記みたいな意識の差だろうなと思う。
1. デザイン
2. UI
3. サービス
人それぞれだとは思うけど全て見る場合、おそらくこう。
4. UI
5. デザイン
お客さん「おう、動きがおかしいぞ。早く直せや」
って言われると、イラっとしながら、外に出て深呼吸して気持ちを入れ替えて仕事をする必要がある。
まあ、どんな仕事でも一緒なんだろうけどさ。
だから、何か伝える時に
オブラートに包んでいても、「致命的」とか「結構」とか「まずい」とか付けられると神経を逆撫でされるから言わないようにしよう。
逆に言われても重く捉えないようにしようと心に刻んで仕事してる。
まだフリーランスになったばかりで、経理周りについても自分なりにかなり調べたもののまだ不安が拭えないので、
というツッコミがあればむしろ欲しいくらいの気持ちで書いてます。
例のごとく経歴はちょっとごまかし入ってます。年数とか月数の計算が微妙に合わない部分はその影響かもです。
・フリーランスになったら、月単価75万+消費税7.5万=82.5万円がほぼ丸ごと手取り(年収換算990万)でテンション上がってる
・常駐稼働フリーランスは外税での請求が主流なので、消費税10%が丸ごと所得になるというライフハック
都内一人暮らし、30台独身のWebエンジニア。奨学金500万絶賛返済中。実家は埼玉で通勤圏内。
March以下の文系4大卒、プログラミングほぼ未経験から新卒で社員数5名の小さいソフトウェア開発の会社に入り(初年度の年収は240万)、
その後約6年で3社経験して退職。最終年度の収入は400後半台。大手と比べるとだいぶ安いかな程度。
スキル的にはインフラ・バックエンド・フロントと全部面倒を見て、新規サービス立ち上げ〜1年半くらいの運用・追加開発くらいならエンジニア1人体制で回せるタイプで
特に立ち上げ期のスタートアップであれば、今この瞬間で言えば売り手なポジションだと思ってます。
そのあとは200万弱あった貯金で数ヶ月くらいニートをやって、
フリーランスに転向。別にやりたいこともあるので多分半年くらいの予定。
周りにフリーランスがたくさんいたのもあって金額の相場や求められるスキル感には非常に詳しかったので、
月単価80±5くらいで、かつ何かしら未経験の技術スタックがある、という条件で案件を探す。
大手エージェント経由で5件くらい面接をして、常駐で月単価75の案件に決まって夏頃から稼働中。
・仮に月単価85万行くと、額面年収1000万円到達で、キャリアとしては大台に乗るかなぁ
・でも手取り換算だと多分50万後半くらいだから別に嬉しくないし、明らかな贅沢ができるわけでもない。
・月単価85万はそこそこハードル高い。80万はいける(条件面で蹴った案件は80万だった)
・約半年弱働いてなかったから、正社員時代と合わせても、今年度の年収が400万前後に収まる
↓
・払うべき年間の税金が、控除後所得195万のラインに乗れば所得税+住民税で20万程度、
仮に195万超えても40万程度(しかも正社員時代の所得税は源泉徴収済み!)
・給与所得ではなく、常駐系のITエンジニア界隈は外税が主流なので請求書の金額に+10%の消費税が上乗せ。(月額ベースで75000円!)
・売り上げ1000万円以下なので消費税支払い免除(というかそもそも開業2年間は免除)
(厳密には、請求先が免税事業者の場合は消費税の支払いをしなくてよかったり、そもそも免税事業者との取引を渋るケースもあるらしいけど、支払いが大手エージェント経由なのもあって当面は問題なさそう)
・しばらくは月単価75万+消費税7.5万=82.5万円ほぼ丸ごと手取りですウハウハ。
・税金は、とりあえず年間で40〜50万円くらいキープしておけばOK。
・現状、税金は所得税+住民税で社員時代と大差なし。給与所得控除65万円がなくなるのが痛いけど、そこまで経費精算しないといけないほどシビアでもない(むしろ今年は白色申告でもいいんじゃね感)
・社保→国保になるのはまあまあ痛い。
ーーーーー
一番びっくりしたのが、フリーランスになると、条件次第で消費税請求分10%が丸ごと手取りになるというカラクリ。
もちろん日々の支払いに10%上乗せされてる訳だから本質的にはプラマイゼロだけど、
会社員時代は手取りからさらに消費税8%を店で払ってたのを考えるとその差は歴然。
これに気づいたのが最近で、気分的にはいきなり30万近くボーナスが降ってきた感じです。
話がうますぎて、正直まだなにか見落としてるんじゃないかと思ってます。
年間売り上げを1000万円前後に収めて消費税請求分を丸儲けっていうパターンはすごい汎用性高くて
益税だ、フリーライダーだと罵られても仕方ないレベルだと思いました。
もちろん40台、50台になると厳しい業界でもあるし、
結婚子育てをするとなると今の最大瞬間風速の年収でも全然余裕はない。
(というか年収1000万近くあってこれなので、タワマンとか都内に一戸建て建ててるような奴らはどう稼いでいるのか全然想像もつかない)
ただ、対して高学歴でも無く、就活もぶっちゃけ適当すぎて失敗してて、
たまたまプログラミング適性があったからプログラマーになりました、
くらいのずぼらな人間が30台前半でこれくらいの収入レベルを得られるとなると、
20台後半くらいでプログラミングスクール通ってWebエンジニア転向、みたいな人も周りにたくさんいるので、
年収低すぎ仕事もつまらん人生真っ暗だ!思う人がいたら、ぜひIT系への転職をやってみてください。少なくてもあと5年は天国です。
こういうのを実装したいと思ってるだがどんな言語とライブラリ使って
業務で使うというよりは習得メインだから回答の精度とかは二の次でいい
ちなみに自分のスキルは一応本職だからPythonは触ったことないけど
MySQLいじったりテーブル設計したり学習データ管理用のGUI作ったりとかMeCabの知識とかはどうにでもなると思う
あ、ただ微分積分とか行列については全くわからないと言っていいレベル
最近はWebの知識をフロントエンド/バックエンド/フレームワーク/アーキテクチャと
総合的に勉強するより機械学習の方がむしろ低いとか聞くけど意味不明な記号の羅列を見てるとにわかには信じられない……
”そこそこの大学をでて大学数学をちゃんと習得している人にとっては”的な条件があるのだろうか
このくらいの仕組みならパパっと作れたりするのかなぁ
tl;dr
さっさと転職しよアホらしw
最近SI業界に存在する何もできないおっさんSEの記事を読んだ。
恐ろしい事に、私は今までSESとしてその業界を渡り歩き、まさに記事のようなおっさんが存在する事を知っている。
私とそのおっさん達との違いは給与くらいなもので、私はSESのため商流が2つほど挟まって利益が会社や自分の手元に来る。
つまりこのまま時間が経てばそのおっさんの下位互換として業界に居座る形になるわけだ。
はっきり言って虚無の未来としか言いようがない。現場での私の単価が100万としても、手元に来るのはおよそ30万ない程度だ。
ここから100万円の仕事をしている自負が生まれるのか?私にその自負は持てなかった。
ならば所属元がコンテンツサービスを作成して自社開発にリソースを割くようになった時に戻れるように研鑽しつつ耐えるしかないのか?
無理だ。何年耐えればいい?
私はすでに自社開発を見越して現場に出てもらっていると聞いてから4年経過しているが、現在自社でコンテンツを作成しているのは2名ほどしかいない。
自分は仮想化インフラ基盤の業務を選任にしているが、それが自社で求められるとは到底思えないし、開発にコンバートして間もないレベルの技術力で少ない開発陣に貢献できるとも思えない。
私が経営層の視点なら、現場で開発経験を積んだ人間から優先的に戻すに決まっている。
つまり間もなく自分の惰性で生きてきた人生のツケを払う事になる。
幸い今の現場では自身初のバックエンド開発案件に参画することができ、今までとは比べものにならないモダンな開発環境でサービスを作ることを学べている。
日を経るごとに自分の至らなさを痛感するが、その分成長している手応えもある。
大丈夫、やれば何でもできるようになるから。現場の方から背中を押され、自分に言い聞かせ、少しずつ未知の分野が拓かれていった。
転職しようと。
私はSIが嫌いだ。一部本当に尊敬できる人間を除いて技術の研鑽やサービスのあるべき姿に向き合ってる人間が少なすぎる。
顧客のIT理解度が低く、エンジニアを見下した仕事の進め方が嫌いだ。
歩み寄る気の無い仕事の指示、消耗品として補充しては潰れるまで決して効率的ではない悪習残る仕事を延々とさせる思考が。
そして5年弱自分の糧になる環境を与えてくれたSESにしても、ついぞ好きになることはできなかった。
皆の力添えあって、自分の努力あっての今とはわかっていても、私にはこの業界構造は肯定できない。
思い上がりだろうが、それは今後の結果で明らかになる。是非もない。
どうか同じ境遇で疲弊している方がいたら、迷わず道を変えて欲しい。
出来ないことなんてない、時間が人よりかかるかもしれないが、いずれ出来るようになるから。
私は年明けからは自営業となり、一切の後ろ盾を無くすが、晴れやかな気持ちでしかない。
失敗しても死ぬわけではないし、何より自分と向き合って選んだ道だ。悔いはない。
業界に入る前にインターンとかでこの辺を知ると、その後のキャリア選択に有用です。
プロジェクト全体を回す人として、スクラムマスターとか、プロジェクトマネージャー、が設置されているケースもあります。
求人資料を見るだけじゃなくて、可能な限り、直接面接で聞いたり、中の人に聞いたほうがよい。
Developer Experienceてきなところっすね。
バックエンド系なので、フロントエンドのことはよくわからない。
(給料とかは当然見ると思うので省略)
Windowsが悪いという話ではなく、WIndows以外の選択肢(Mac、Linux)を選べるというのが大事。
Windows縛りのところはだいたいろくでもない。
リモートワークが好きってわけではないんだけど、台風の日とか出社しなくてもいいのはありがたい。
あと、リモートワーク可な職場は、非同期コミュニケーションが発達していて、エンジニアとしての仕事がしやすい可能性が高い。
例えば、Github Enterpriseじゃなくて、github.comが使える、とか。ASP/SaaSがどの程度使えるか、ってのは、セキュリティがめんどくさいかそうでないかの試金石として有用。
Oracle RACを使っているところは経験上、結構がちがちな開発スタイルの可能性が高い。
古いRubyとか、古いMySQLを使い続けている職場は、そもそもあまり技術に関心がない可能性が高い。
エンジニアブログが無いのは論外(いい会社かもだけど、外からはわからん)、あと更新頻度、更新者のプロフィールをちゃんと出してるか、など。
更新者のプロフィールをちゃんと出している会社は、中の人間の対外発表をそれなりに推奨(黙認)していると想像できる。
プログラマーなら何でもできるでしょっていうことはなくて
採用する時に厳選しなきゃならないんだけど
そこらへん、専門にやってないとどこに切れ目があるかむずかしい
例えばABCDEというスキル名があって、全部できる人が存在するかどうかは、それぞれ習得にかかる経験値の量による
もちろん、ABCDEのスキルに対して今は「浅くていい」ってパターンもあれば、Aについては深くなければならないみたいなシーンもあるので
マップだけでは足りないんだけど
最近だとフロントエンドとバックエンドは別物みたいな風潮あるけど、その切れ目も難しくない?
例えば機械学習ができるエンジニアが一人いたとして、そのスキルは「機械学習」って言って良いのか
その中でも相当広くて、その人のスキルはそのどこかに偏ってるはず
地図がほしいんだよなー
__
そうそうこういうのだよ
https://oshamambe.jp/archives/542
よくできてるなぁ
現役のプログラマ、web制作・ソフトウェアに関連する産業に従事される方々のアドバイスを頂きたいです。また、ニートから社会復帰された方のアドバイスも頂きたいです。
注意: いわゆる特定を恐れてかなりぼかした表記をしているのですが、ぼかしすぎとの指摘をいただければ可能な限り追記いたします。ただし、GitHubプロフィール/WebアプリのURLについては、就職活動のための個人情報が含まれている可能性があること、宣伝すべきでないことから、ここで公開をすることはありません。
素人同然かもしれませんが、適切なアドバイスを頂くために必要だと思うので、書かせていただきます。
Webアプリの概要: 複数の外部APIを組み合わせて定期的にデータが更新される(現時点で数百万程度のレコード数)、ユーザの操作でリソースが更新されることはない(すべてのendpointが認証なし、GETのみ)
面接に間に合わせるように作ったのですが、残念ながら一度も面接官/採用担当者の方にご覧いただく機会がありませんでした。(そもそもGitHubについてご存知の面接官の方がいらっしゃらなかった…)
内容としては、モダンなWeb開発の基礎を一通り踏まえた構成になっていると考えています。
ソフトウェアエンジニアの取扱いが多い求人サイト(Find Job・Green・Wantedly)、一般的な大手求人サイト、派遣会社、ハロワ、横断検索サイト(Indeedなど)、Google検索
インターネット上で公開されている、通勤できる距離の求人情報は片っ端からクリックしました。(Google検索で site: ...
※実際には求人サイトのドメインが結構効果的でした)
良さそうな会社はたくさんあったものの、応募資格の時点でほとんど諦めることになりました。(実務経験以外なら必須でない条件を含めて満たす求人もありましたが、必須条件を満たさないために応募をすることはありませんでした。)
「社会人経験」「実務経験」を必要としない寛大な会社は、ほぼSESでしか存在しないようです。
「1年以上の実務経験」を必須とする、時給1000円のアルバイトはたくさん見つかりました。(ZOZOのアルバイトが1300円で話題になりましたが、1000円のアルバイトでもそこまで求められるのかと思ってしまいました…)
視野を広げてWebデザイナーやHTMLコーダーを見てみると、実務経験に加え、「Adobe製品の使用経験」(料金が払えない…)「Wordpressサイトの運用経験」「ポートフォリオサイトを持っていること」が必要な会社がほとんどでした。
VPSにWordPress+nginx+SSL(Let's encrypt)で構築したことはありますが、1人で更新する分には静的サイトジェネレータを使ったほうが簡単で、GitHub Pagesなどで無料で公開できるので、実際の運用には至りませんでした。
やはり、自分はデザイン系の会社が求める人材ではないと思います。
応募資格の時点でほぼ応募できる会社が存在しない中、応募資格を満たす会社に片っ端から応募して、数社面接までたどり着きました。SES以外面接落ち、SESの会社は一次面接通過後に辞退させていただきました。
面接で基礎的なコンピュータサイエンス/アルゴリズムの知識を問われる可能性を考えて、それらの基礎も学習をしましたが、これもまた面接で使用する機会がありませんでした。(それ自体は無駄ではなく、むしろ自分のためになるものでした)。
私の文章力が低く、読みにくい文章であったとすれば、申し訳ございませんでした。これでも下書きを一度破棄し、表現に気をつけながら、書きあげるのに数日を要しました。これが私にとって初めての増田での投稿で、「この内容を登録する」ボタンを押すのにも勇気が必要でした。
https://anond.hatelabo.jp/20190405004215
http://b.hatena.ne.jp/entry/s/anond.hatelabo.jp/20190405004215
NTTグループの増田やそのブコメを見て思うところあったので、自分のブログに書こうかとも思ったけど増田に書く。世の中には「普通の平凡なサラリーマン」にすらなれない人がいるんだよいう観点で。
構成はNTTグループ増田のそれに合わせて書く。分量は少なめで。
「安定してそこそこの給与が保障されている」という環境に対する憎悪の声がここ二十数年ほど高くなっているが、「安定してそこそこの給与が保障されている」環境が必須な人は一定の割合で存在するのでは?そういう進路を選択したほうが貧困に陥らずに済む人だっているのでは?そこから外れた瞬間に貧困に陥ってしまうのでは?(私自身も若いころはそういう視点を持てなかった。)
「普通」の人間にすらなれない人にとっての一つのセーフティーネットが存在することを私は実感したし、それを無くすのは自分のためだけでなく、社会のためにもよくないのでは?ということを捉えていただければ。(近い将来、その「一つのセーフティーネット」が無くなって私自身が惨めに野垂れ死ぬ可能性は高い確率であると思っている。)
修士新卒で就職。40代前半。いわゆる氷河期世代ってやつです。バックエンド業務に従事。
30くらいの時にブラック他部署との仕事でメンタルを病んで療養。復帰はしたが、不信感やらいじけ根性発揮やらで30代序盤にして「この先の人生はもう余生」と決め込む。今思うと、内心そう決め込んでいても「一生懸命仕事をやろうとしているポーズ」を取ることの重要性を理解していれば年功序列レールに数年の遅れで乗れたのになあと思うのですが、当時はとにかく辛くてそんなこと考える余裕すらなった。後の祭りだし後からならなんとでも言える。
過去は変えることはできないので、節約生活と可能な限り小銭を拾う生活をするしかない生活を強いられているんだッ!!(バカの自業自得)
経営は非常に安定している、、、とみなされた時代もあったようです。
労働組合は御用です。組合の側から「労使協調」という言葉が出たときにはのけぞりました。物事には建前というものがあるのでは?そりゃあ実態が御用組合で組合出向が人事部の出世コースなのはみんな知ってるけど、、、と思わないでもないです。
私自身の年収は650万ほど。残業しまくっていた就職3,4年目の頃と同じ水準ですね(さすがに今は残業時間は減っています。というかそんな残業生活もう無理)。40歳超えてこれですので、金銭感覚が比較的幼いままでよかったなあと思っています。この先歳をとるにつれどんどん周囲に差を付けられてきつくなるんでしょうけど。
(収入が順調に上がるにせよ上がらないにせよ、生活レベルは上げないほうがいいと思います。というか生活レベルって小金が入って油断すると勝手に上がっていくものです。心身の疾患で収入が上がらなくなったときに悲惨ですし、心身に問題がなければないで貯蓄が増えていきます)
年齢や学歴の近い人は最低でも係長、早い人はとっくに課長に上がっていて当然年収1000万超えです。
30代序盤までは、普通に過ごしていても優秀であってもメンタル疾患の欠陥品(私)であってもその時点での年収差はあまりないようです。後になって響いてきます。
ヒラ→主任→係長→課長、、、と昇格していきます。「普通」の人間でいられる限りは今でも係長までは多少の差はあれど基本的に年功序列です。もちろん私はそのレールにすら乗れていません。
学歴が高いほうが昇格が早い、という傾向はあるようです。自身の反省から言うと「普通」になれなくとも一生懸命頑張っているフリくらいはしましょう。社内ニートのキャリアパスを選択するのは最低でも、(表面的な体裁を保っていればなんとか年功序列で上がれる)係長に上がってからにしましょう(自戒)。係長にすら達していない若いころからいじけて余生モードになってもいいことはありません(体験者は語る)。いじけて社内ニートになるのはいつでもできます。実際課長以上のクラスでそういう人はいます。
なお、優秀な人は異常に昇格が早いですが、「あんな奴がどうして」「女性だから優遇されているのか?」というケースは少なくとも私の視界では見たことがないです。課長以上の世界は私からは見えないのでわかりませんが。
あと、昇格に関する(暗黙・非暗黙の)ルールはあるみたいですが、他人を人事評定する立場に立ったことのない私には正直わかりません。「普通の」コミュ力があればそのへんの情報を下っ端でも聞けるみたいなんですが。
社宅や寮はあります。以前は安価で長く居られたらしいですが、年々制度改悪されて今では基本的に35歳までしか使えないようです。値段については、改悪されたとはいえ普通に借りるよりは安いみたいです。
独身者は補助を受けたければ寮に入れ、という方針です。既婚者は条件をクリアすれば多少の賃貸補助を受けられます。こちらも年々改悪されて今に至るようです。40歳超えたら補助は一切ありません(だったはず。単身赴任に関しては別)。
そんなものはない(関羽)。家やマンションを買うための財形制度はあります。
私自身が持ち家を持っていないし検討すらしたことがないので正直よくわからないです。ただ、わりと多くの人が「年相応に」家なりマンションなりを購入しているようです。まあ、私はそういうルートにすら乗れなかったので、、、
旅行とかスポーツジムとかに使えるポイント制の制度があります。小銭を拾って生きていかないといけないので、これは、、、ありがたい、、、
勤務時間帯はコロコロ変わっていました。一日の労働時間が長くなる代わりに休みが増えるとかその逆とか。ただ、最近は世間の趨勢を無視できず世間並みになっている感触です。フレックスやリモート勤務や時短勤務などがあります。
残業規制は私が入った頃はいいかげんでした。最低でも終電帰宅がデフォなのに残業は毎日20時きっかりまでとか。(若いころはそれでもなんとかこなせるんですけど、それで心身のダメージが蓄積していくということに気づいたのはもう少し後の話)
社内外の関係者(犠牲者)が捨て身で騒いでマスコミ沙汰労基沙汰にしたことや世間の流れもあって、今では残業規制はNTTグループ増田の言っている程度には厳しくなりました。ただ、一部の部署では「退勤タイムカードを押した後残業」みたいなのが常態化しているという噂も聞きます。
人件費圧縮のため残業は減らせという職場全体の方針なのに、残業時間が少ない人は暇人認定されて評定上はよろしくないみたいです。じゃあどうすりゃあいいんだよ。
あと、フレックスが導入されたので残業時間の調整はしやすくなりました。今月残業多くて今日はやることないから早く帰りますとか。まあそんなこと言ってられない時はどうにもなりませんが。
有給休暇、夏季休暇、傷病休暇があります。繰り越せる休暇はいいんですが繰り越せない休暇はきっちり消化しないと上司が怒られます。
他は、最近急にコストに関して経営陣が意識高い系になっているけど、その内容が「とにかく目先の支出を減らすこと」という、民間大企業がかつて陥った罠に数周回遅れで嵌まっている感がムンムンします。「目先のコストカットが目的化してしまい本業に支障出まくり」という余所様の失敗はさんざん話題になっているのにそういう情報に触れていないんだろうか。
低いです。が最近は若い人の離職率が上がってきています。先日部長が「若い人が離れていくのは問題だ。もっと職場の一体感を」とズレたコメントをしていたのが印象に残っています。部長まで行くような人がその分析、、、?
個人的には、ここ数年人事が欲しがるような人材(安定のためとかそんな学生は要らねえ!)が増えた結果として若い人の離職率が上がっているんでしょ?人事がそういう人材を採用している方針的に当然の帰結では?と思っています。
・将来がどうかはともかく、貧困になりたくない人(「普通」になれなくても必死になんとかしがみつけばそこそこの生活費は確保できます。今のところは)
・社会的信用を求める人(エリートでもお荷物でも外から見れば所属組織名は同じ)
・馬鹿正直な人
・ルールや決まりよりも部署の声のデカさがすべて、という現実に適応できない人
・一攫千金を求める人
私はかつて「私は普通の人間(社会人)にくらい当然なれるさ」と思っていたし、もしかしたらそれ以上の…なんてことを思っていました。
最近話題なった45歳over首切り某民間大企業が、その昔「成果主義」とか言い出して世間的にも話題になってました、当時就職直後だった私もご多分に漏れず「自分は当然成果主義で給料の上がる側」と思っていました。
今は私の職場も(年功序列の面も残っているけど)「成果主義」が進んでいますね。イチローの引退会見じゃないけど、若いころの自分に「おまえメンタル疾患で普通の人間にすらなれずに成果主義どころか年功序列レールにすら乗れてないぞ」と言いたいですね。
そんな欠陥品でも当面は生きていけることに対しては、今のところは運がよかったな、と思っています。ということで退職しません。クビになった時に備えてチマチマ小銭を貯めます。まあ実際クビになったらそんなのすぐに吹っ飛ぶんだろうけど。
NTT退職だのGoogle入社だのいろいろと盛り上がってるがお前らそんなにお賃金欲しいなら狙うのはWebでもSIでもない。
外資ITベンダー。コレ。HWならIBM/HPE/Dell/Cisco/Juniper/F5/NetApp、SWならOracle/SAP/Salesforce/Redhatあたりな。
お前らはエンジニアだろうから営業職は除外するとして、Presales SE/PS/CS この順でお賃金が高くて、左から順に40歳ぐらいで評価が普通だとしてざっくり1200万/1000万/800万。
雇用の安定性は日本企業と比べたらそりゃ落ちるけど、外資コンサルみたいに up or out なんてかっこいいことも言わんで。数年に1回、下位5%が月給12ヶ月分とかのパッケージ込みで退職勧奨されるぐらいや。こんなんその辺のニッポン企業でも普通やろ?
必要なスキルもお前らが大好きなソフトウェアエンジニアリングとかWebのフロントエンド・バックエンドやってたなら十分や。インフラもちょっとかじってたりしたなら、下手したらこの辺のベンダーの人間なんかよりよっぽどスキル高いやろな。
Presalesなら出来上がってる仕様と客の要件が理解できればそれをうまくマッチングさせて動くように売ればええんや。PSなら動くように導入すればええんや。CSはなんかあったときにサンドバッグになっとけばええんよ。
あとは開発職な。これはニッポンにはほぼない職種やな。本国かインド・中国やね。本国の開発職はGoogle程ではないにしても待遇はええで。
で、一回入ってしまえば評価が普通なら毎年3%ぐらいは昇給するやろ。ここは個人の成果というよりかは会社の業績次第やね。またーり並みの評価でジリジリ年収が上がっていくのを待ってもいいし、ワイはもっと上にいくんや!思うなら業界内でぐるぐるしとけば転職のたびに10%アップ狙えるで。野心があってうまく生き残った奴は部長になれば平社員の1.5倍、本部長なら2倍やね。
どや?悪くないやろ?
やっぱり途中で切れたので続きから
違います。
そうです。
はい。Stadia Games and Entertainmentの組織を発表しました。これは我々の1stパーティのスタジオです。
はい。
Googleは開発者に対し全てのツールを支援しています。Stadia向けの開発は彼らにとって別のターゲットにしか過ぎません。Visual Studioを用いる既存のツールや彼らが用いるツールの全てと共に、彼らのワークフローに統合されます。従ってStadia向けの開発はPlayStationやXbox向けの開発と同じくらい簡単です。
我々はUnrealもサポートします。UnityがStadiaをサポートします。予想される多種多用な業界標準のツールとミドルウェアが準備されます。
とても良い質問です。我々はユーザに対し彼等のインフラの中で何が起こっているかをできる限り理解できるよう支援する必要があります。また我々はゲーマーに対し最適な体験を得られるようなチューニングを行うことが可能な情報に対し投資を行うだけでなく、我々自身の技術を用いて最良のパフォーマンスを実現するつもりです。Googleの技術の多くがインターネット網の基盤であることを思い出して下さい。我々はDCからの情報がどのようにユーザに届くかを良く理解しております。できる限りの最適化を行うつもりです。
その通りです。それこそが我々のプラットフォームの根本的な差別化ポイントです。既存のゲームカタログを持つデベロッパにとってStadiaは簡単で親しみ易いものです。我々はできる限り摩擦なくゲームの移植を行えるようにします。なぜならゲーマーは好きなゲームを遊びたいですし、彼らの愛するキャラクター、ストーリー、世界を楽しみたいのです。しかし我々はまた開発者に未来を描く新しいキャンバスをも提供します。ゲームを高速に配布し、プレーヤーと新しい手段で、特にYoutubeにて繋げます。そして開発者が持つアイデアを実現するための前例の無い技術を提供します。
解決されたと同時に緩和されています。まずデータセンターに対しより多くの人々がより良い経験を得られるようにするための投資が行われました。また圧縮アルゴリズムについては我々に抜本的な先進性が存在します。Googleは圧縮アルゴリズム標準仕様の先駆者でありこの点がストリーミングの将来をより確実にします。残念なことですがGoogleでも制御できない点が光の速さです。そのためこの点が常に要因となります。しかし常に理解しなければならないこととして、我々は常にエッジ(終端)にもインフラを構築していることが挙げられます。Googleの中心にある巨大なデータセンタだけではありません。我々はできる限りエンドユーザの側にインフラを構築しています。それによって歴史上の幾つかの問題は回避することが可能です。さらにまだ率直な、あまり洗練されていないProject Streamのストリーマーでも信じられない結果を出しています。さらに我々はサービスリリース時に1080p60を超える品質を実現できるだけの根本的な改善を行いました。我々は8Kに至るでしょう。
圧縮にネットワークです。我々はGoogleがインフラに投入した数々の改善点に依っています。BBR、QUIC、WebRTCを基盤としてその上に構築がなされました。だからIPパケットの低レイテンシでの配信だけでなく、送信元へのフィードバックも行うことが可能です。ですのであなたが仰るZenimaxが使用した技術なら、彼らはここでも利用することが可能です。彼らは彼らのゲームの最適化を行うことができるでしょう。我々はフレーム毎のレイテンシを予測が可能で彼らにそれに合わせて調整を行わせることができます。
我々は改善を続けます。Streamは最初のバージョンです。我々は性能向上のために調査を行っており、レイテンシに適応していきます。リリース時にはより良くなっているでしょう。
確かにそのとおりです。そしてそれこそがGoogleが何年もかけて開発してきたスキルであり、抜本的なスケールする能力です。我々がどうやって実現しているのか、何をしてきたかについては今日は詳細にはお話ししません。しかしGMailやMap、Youtubeが同時に利用可能であるためと同じ基本的な技術のいくつかが我々が依るものです。
我々は競合他社が何をしているかは存じておりません。
我々の第一世代システムに導入されるGPUは10Tflops以上の性能があり、さらにスケールアップします
AMDです。
情報を公開したくない訳ではないのですが、このプラットフォームが進化することのほうがより重要です。そしてこの進化がユーザと開発者の双方に対しシームレスに行われることを確認して頂きたいのです。そして進化は常に継続し、誰もが常に最新で最高の物を手に入れます。
開発者にもこのように考えて欲しいのです。もちろん完全には抽象化されていません。特にゲームの開発者にとっては。しかし我々はそれでもこのプラットフォームが常に進化していると考えて欲しいのです。速さや容量、リソースには制限されていないのだと。
シェーダコンパイラのツールをいくつか開発しました。これらは開発を楽にするでしょう。しかし現在のGPUはとても優れており開発者が既にVulkanに親しんでいれば、例えばid Softwareさんは既に全てVulkanに移行していますが、そのような開発者の方々には既存のゲームをStadiaに移植するのはとても簡単です。Doom Eternalが4K、60フレームで動いでいるのは既にご覧になったと思います。非常に素晴しい状態です。これこそが我々にとって重要な証明ポイントです。FPSはグラフィックとプレイアビリティの双方で要求が高いゲームです。 従ってこれは我々のプラットフォームの強力な証拠であり、idさんにも講演して頂きます。
x86で2.7GHzで動作しています。開発者にとり慣れのあるものです。開発全体を通して、CPUは制約となる要因ではありません。我々は全てのタイトルを動作するに十分なCPUを提供します。
沢山です。
しかしサーバ級のCPUです。Stadiaはこれまでのコンソールと違いパッケージングに制約を受けません。熱対策の問題も異なります。コンソールとはサイズやパッケージングの動機が異なります。データセンタの中でそれはとても汚なく見えるかもしれません。一方でとても帯域幅が高いメモリが使用可能で、とても高速なペタバイト級のローカルストレージも使用可能です。ご家庭のコンシューマデバイスよりも数百倍は速い物です。
パートナーには彼らが話せる時点で彼らの計画を教えてくれるよう伝えています。Stadiaをこの世界で最も偉大なゲームの開発者達に説明することにはとても興奮します。Stadiaは、開発コードではYetiと呼ばれていましたが、Stadiaのビジョンを説明すると、開発者のリアクションは「これは私が期待したものそのものだ。これはまさに我々の次のゲームのためのビジョンそのものだ。elastic computingの考え、次世代レベルのマルチプレーヤー環境、ゲームを観ることと遊ぶことの境をあやふやにし1つの体験にすること」と話されます。
イノベーションの1つの領域として、最初のほうで述べましたが、マルチプレーヤー環境において、単純にパケットを複数のプレーヤーにリダイレクすることから、原子時計レベルでのコンシステンシーを全ての状態遷移において定期的にクライアント間で更新する真のシミュレーションへの移行が挙げられます。これにより開発者はこれまでには不可能だった分散された物理シミュレーションを得ることができます。これだけでもゲーム設計のイノベーションに対し大きく寄与します。このため多くの開発者が、大袈裟でなしに、実際にとても感動的なリアクションを我々のプレゼンに対して返して下さっています。
これこそがゲーム業界の素晴しい点です。技術が常に創造性を刺激し、ゲームに対しより大きな聴衆を作り、そのことがプレーヤーと開発者に対しより大きな機会を作ってきました。エコシステムが進化し、正の方向に回り続けるなら、それはゲームを遊ぶことにとって良いことです。
3台のGPSが一緒に実行されるデモを行っています。私は上限が無いとは申しません。しかし我々は技術上の限界を上げています。そしてStadiaは静的なプラットフォームではありません。このプラットフォームは5年や6年の間、レベルが変わらない訳ではありません。開発者とプレーヤーの要求に従い、成長し、進化するプラットフォームです。なぜならStadiaはデータセンタの中に構築されています。進化させるのは我々にとって簡単なことです。
CPU/GPU/メモリ帯域幅の変更にはいくつかの自然な段階があります。これは家庭の物理な小売の端末よりももっとスムースでより継続的な進化です。しかし、より重要なことは基盤データセンタ網とそれに含まれるネットワーク技術への投資です。この2つが一致して行われることが重要でどちらか1つではダメなのです。
それは我々も既に行っています。Googleが既に20年以上、行っていることです。我々が依って立つまた別の巨人の肩です。
我々はStreamをさらに強化させています。従ってユーザはこの制約が全体のスタックに対する改善と最適化、また特に時間によって緩和されることを期待するでしょう。我々はその期待の上を行きます。
私は具体的な数値についてはコメントしません。しかし当然低くなります。
インターネットの接続環境はStadiaをリリースする市場では全体的に上昇機運が見られます。つまりこのパフォーマンス特性はますます多くのユーザが利用可能になります。
さらに繰り返しになりますが、BBRを初めとする我々の技術があります。さらに覚えておいて頂きたいのは我々のネットワークに対する理解はそのままではありません。それらもまた時と共に改善されていきます。Youtubeはマクロと
Eurogamerにより独占配信されたStadia開発者二人に対するインタビュー記事。
---
タイミングの問題です。20年間の蓄積によりGoogleにはデータセンタ内のパフォーマンスに優位性が存在します。Googleはデータセンタ内ではHWメーカーです。我々はデータセンタ内で何年もの間、高い性能で端末間を接続する基盤を構築してきました。Youtubeでの経験からプレーヤーサイドの観点からだけでなくデータセンタ内部からの技術的観点からの技術統合を行ってきました。他社でもその視点は存在していますがGoogleにはその点に固有のアドバンテージが存在します。
その通りです。我々にはレガシーがありません。全てが21世紀のために設計されています。開発者は制限の無い計算資源が利用でき、何よりもマルチプレーヤーをサポートできます。これまでのマルチプレーヤー環境は一番遅い通信に影響を受け開発者は最も遅い接続に対し最適化が必要でした。我々のプラットフォームではクライアントもサーバも同じアーキテクチャの下にあります。これまではクライアントとサーバの間のpingに支配されていましたが我々の環境なら最速でマイクロ秒で済みます。だからプレーヤーの数は単一のインスタンスにて動的にスケールアップが可能です。バトルロイヤルなら数百から数千、数万のプレーヤーが集まることも可能です。それが実際に楽しいかどうかは置いておくとしても、新聞のヘッドラインを飾ることが可能な技術です。
両方です。
ユーザが我々のプライベートLANからはみ出さないだけでもその効果は大きいものです。Googleは45万kmに及ぶ光ケーブルにより世界中のデータセンタ間を接続しています。米国の西海岸から東海岸まででも20ms、フランクフルトからマドリッドでも20ms。これにより開発者は最も極端な場合においてもレイテンシが予測可能でそれに従い設計を行うことができます。
StadiaはYoutubeの技術と深く結びついていますが、実際には一歩引いています。今日のゲーム業界を考えてみて下さい。2つの世界が共存しています。1つはゲームをプレイする人々で、もう1つはゲームを見る人達です。2億人の人々がYoutubeでゲームを毎日見ています。2018年には述べで500億時間がゲームを視聴するのに費されています。時間と人口の双方で信じられない程の視聴が存在します。我々のビジョンはこの2つの世界を1つにすることでゲームを見ることができ、かつ、プレイもできる、双方向に楽しめることです。
つまり重要なのはゲームシステムでもなくコンソールでもありません。噂とは異なり我々はコンソールビジネスには参入しません。我々のプラットフォームの要点はコンソールでは無いことで、皆が集まる場所を作ることです。我々は箱でなく場所を作る。今までと異なる体験を得られる場所です。ゲームを見るなり、遊ぶなり、参加する場所であり、かつユーザが楽しむ場所であり、ユーザが他人を楽しませる場所です。
だから我々のブランドはStadiaといいます。これはスタジアムの複数形です。スタジアムはスポーツを行う場所ですが同時に誰もがエンターテイメントを楽しむ場所でもあります。だから我々はそれをブランドにしたかったのです。皆が遊んで、観て、参加して、さらにはゲームをする場所。一歩下がって見ることもできる場所。常にどのボタンを押したかを意識しないでも良い場所。他のアーキテクチャでは実現できない場所です。
その通りです。そして単純に技術的に深い点を求めて、我々は第一世代でも4K60fps、HDRとサラウンドをサポートしました。さらに開発者が必要なインフラに従ってスケールします。それだけでなく、同時にYoutubeに常に4K60fpsHDRで画像を送信することが可能です。だからあなたのゲーム体験の思い出は常に最高の状態になります。
プレーヤー次第です。Googleは全てを記録はしません。もしプレーヤーが望むならGoogleは4Kでストリームします
共有が友達だけか、世界中に公開かも自由に選択可能です。Googleはユーザに制御を明け渡します。もしユーザがYoutubeで公開すれば誰でもリンクをクリックすることでそのゲームを遊ぶことができます。
そう。そしてこれはマルチプレーヤーゲームのロビーの新しい形となります。Youtubeのクリエイターなら誰でもがファンやチャンネルのsubscriberを自分のゲームへと誘うことができます。生主として、Youtubeのクリエイターとして私は視聴者を私のゲームに瞬間的に招待できます。それが私と10人の友達でも、(訳注: セレブの)Matpatと彼の数百万の購読者でも、技術は同じです。
Googleアカウントの一部です。従ってGMailアカウントがStadiaへのログインに利用できます。他の基盤についても説明させて下さい。最初のサービス立ち上げから全ての画面への対応を行います。TV、PC、ラップトップ、タブレットに携帯です。我々のプラットフォームの基本は画面に依存しないことです。これまで40年間、ゲーム開発は端末依存でした。開発者として私は制約の範囲内で、私の創造性を開発対象の端末に合わせてスケールダウンする必要がありました。
我々はStadiaでそれを逆にしたいのです。我々は開発者に対し彼らの考えをスケールさせ、どの端末の縛りからも解放したいのです。パフォーマンスに優れ、リンクをクリックすればゲームは5秒以内に開始されます。ダウンロードもなく、パッチもなく、インストールも必要なく、アップデートもありません。多くの場合、専用のHWも必要がありません。従って古いラップトップでChromeブラウザを使用する場合にでも皆さんが既に持っているだろうHID仕様に準ずるUSBコントローラが動作します。そして、もちろん、我々自身のコントローラも開発中です。
コントローラを自作する理由にはいくつかあります。1つはTVへの接続です。我々はChromecastをストリーミング技術に採用します。Stadiaコントローラの最も優れた機能の1つはそれがWiFi接続でDC内のゲームに直接接続することです。ローカルのデバイスとは接続しません。
その通りです。これこそが我々のブランドの実現であり、具現化です。そして独自コントローラにより最高のパフォーマンスが実現します。ゲームに直接接続するためにプレーヤーは画面を移動することが可能です。プレーヤーはどの画面でも自由に遊び、停止し、他の画面でゲームに復帰することが可能です。
そしてコントローラには2つの追加されたボタンがあります。1つはGoogle Assistantの技術とマイクを用います。ユーザの選択により、ユーザはプラットフォームとゲームの双方に対し、自然言語を用いて会話が可能です。例えば「Hey, Google。MadjとPatrickと一緒にGame Xをやりたいな」と言えばStadiaがマルチプレーヤーゲームを指定した友人と共に直ぐに開始します。
我々はゲーマーを可能な限り素早くゲームに辿り着かせるよう考えています。数多くの研究を行いましたが、多くのゲーマーがゲームを起動したら直ぐに友人とゲームを開始したいと考えています。ゲーマーはUIに時間を費したくは無いのです。
誰かが言ったことですが、現在のコンソールは起動した時にまるで仕事のように感じると言うのです。ゲーム機自体の更新や、ゲームの更新があります。我々はそれらを完全に取り除きたいと考えています。もう1つのボタンは、ちょっと趣が異なるのですが、Youtubeにシェアできます。
Youtubeが観られるならどこでもStadiaは動きます。
Chromecastはスマホからストリームを受取はしません。Chromecastはスマホから命令のみ受けます。画像はNetflixやYoutubeから直接受け取ります。Stadiaの場合、StadiaコントローラからChromecastへとこのゲームのインスタンスへと接続せよと命令がなされ、Chromecastはゲームインスタンスから動画のストリームを受け取ります。クライアントはとてもシンプルです。行うのはネットワーク接続、ビデオと音声のデコードのみです。Chromecastは入力を処理しません。全て入力はコントローラが扱います。ビデオと音声とネットワーク接続はChromecastの基本動作で全て既に組込まれています。
そうです。とても良く出来ています。WiFiに繋ぐだけです。コントローラにはWiFiのIDとPWを入れるだけです。それだけです。ホームボタンを押すと勝手にChromecastを探し直ぐにChromecast上でクライアントを起動します。UIが表示され直ぐにゲームを遊ぶことができます。デジタルパッドでUIを操作することも可能です。これが重い処理を全てクラウドへと移行する点の美しさです。Chromecastのような低消費電力の端末で説得力のある体験ができます。Chromecastは5W位下です。Micro-USBで給電可能です。典型的なコンソールは100から150Wもします。またこれまで説明しませんでしたが、例えスマホでも行うことは動画の再生だけです。従ってAssassin's CreedやDoomや他の重いゲームがあなたのスマホの上でモバイルゲームよりも低消費電力で動作します。だからスマホで10時間でも遊べます。
今の所、我々はChromecastのみに集中しています。でも技術的、機能的な観点からはYoutubeがある場所ならどこでも動きます。我々はまだStadiaをどのようにユーザに届けるかは検討中です。
サービス開始時から提供されるサードパーティによる解決手段をサポートしています。他にもアイデアがあります。しかし今は話せません。
良い質問です。私がこのプロジェクトに参加する前からチームは既に何社かと提携しここ何年かの間に技術を提供していました。StadiaはLinuxベースです。グラフィックAPIはVulkanです。開発企業はクラウドにインスタンスを作成しますので、開発キットも今ではクラウドにあります。しかしクラウドだけでなく、開発社のプライベートなDCでも、机上のPCでも可能です。
もしそうしたいなら。でも我々は今後のトレンドが開発でも配布でもますますクラウドへと移行していくと考えています。従って今後数年で開発者にとってクラウド中心、クラウドネイティブがゲーム開発での標準となるでしょう。
デベロッパーやパブリッシャーはとても賢くクラウドネイティブとなる新しいゲーム体験を達成するために必要なツールや技術について考えていると思います。しかしそれは世界中で何千ものアクセスポイントを持つデータセンターを運営することや、それらの運営に必要な莫大な投資資本とは異なるものです。Googleは今年単年でも$13Bの資本を投下しています。
米国では全ての必要な場所に展開が終わっています。Project Streamの試験に必要な環境は2018年末には整いました。我々はGoogle社内で、Google社員を対象に2017年の始めから2年間の間、プライベートなテストを行ってきました。2019年には米、加、西欧、英にて Permalink | 記事への反応(1) | 06:10