  |
はてなキーワード: ワークフローとは
Twitterとか見ているとエンジニアは一生勉強！とかっていってるやつ居るけど
エンジニアは大変なんだぞ！すごいんだぞ！って言いたいだけだよね？
実際問題、どんな職業でも大体一生涯なにがしかの新しいことは勉強している事は多々ある。
大企業の～とかいうけどそれらは一部の話であって本当に伸びている大企業の管理職とかはなにがしかの勉強をしていたりする。
コンビニの店員だって日々変わるワークフローに対応するために色々と勉強している。
エンジニアだけが一生勉強なわけではないし「エンジニアは一生勉強だ」みたいな発言は
ただの「それをやっている俺凄い！」っていう特権意識の表れにしか鳴らないので見ていてみっともないのでやめてくれ。
他の職業を馬鹿にするな、お前がやっていないことを他の人がやってくれるからお前は生活が出来るのだ。
それが社会だ。
税理士です。
東京都の感染拡大防止協力金、申請数に対してあまり審査が進んでいないらしいですね。
https://twitter.com/KeinoShinichi/status/1262188358073061377
twitterのリアルタイム検索でも実際支給された話がヒットせずやきもきしていたところ、
ついに自分の顧問先の飲食店に支給決定のメールがきたため、情報共有できればと思い増田にかきました。
----------
■支給決定日：2020/05/19
「東京都感染拡大防止協力金に係る支給決定通知」というメールが届く
なお、メール本文の通知の日付は「令和2年5月14日」とされていた
----------
いつ載るのか毎日店舗名検索しちゃったよ！どういうワークフローなんでしょう。
https://www.tokyo-kyugyo.com/list/index.html
今回実感したのがオンライン申請に抵抗あるご年配もLINEは割とやっているということ。
増田はブラックでもホワイトでも無い企業でシステム屋をして働いている。同僚が退職するので引継をしているのだが、とにかくヤバい。
https://www.jigowatt121.com/entry/2018/02/02/182918
なんで自分の仕事を他人に説明も出来ない、ワークフローも作れない、もしくは作るのを渋る、後任の疑問に答えられない、もしくは機嫌を損ねる人間が転職できるのかが分からない
そういえば、辞める同僚は某成人認証システムを作った大手からのドロップアウト組だったが、その時染み付いた『言われた事だけやる』体質は結局払拭出来なかった
もしかしたら学歴が良いのかもしれないが、資格や技術も含めて勝っているのは年齢だけなポンコツ人材でも転職出来ちゃうのが怖い
とは言え、もしステップアップ成功したのなら良いことだし、大手ならポンコツの10人20人居てもビクともしないだろうから頑張ってほしい
それでも、引継がマトモに出来ない奴が優秀なわけがない。それは曲げない
最近学会に参加するときなどに行う出張申請が、教授を通して一括から参加者が個別に行うようになった。
この出張申請のために動くシステムこそが、最近中高年を1000人単位でクビにした某Japanese Traditional Big Companyが開発・販売を担うワークフローシステムだ。
このシステムがすごい。
まずはじめに出張申請を行った10人が10人全員理解できない謎の画面が表示されるのである。一応所々に「こういうときはここに入力してね」というアナウンスが書かれているが、そこにもたまに嘘が混じっている。
教授どころか申請を処理する学校事務まで仕様を把握していない有様で、どうすれば申請できるのかよく分からない。
データベースから検索をかけていると思しき箇所がある。1データが6個の文字列・数値から構成され、それが推定1万件程度あるだけの小規模なデータベースだ。そこから1個データを取ってくる検索処理に10分近くかかる。さらに因果関係は不明だが、10人が同じタイミングで出張申請を行っていたらシステムがダウンした。まさかとは思うが、データベースの検索の負荷で死んだのか？
そして何より触った人間を例外なくイラつかせるクソUIである。本来ならばシステム化し学生にも個人で出張申請をさせることで関係者が楽になることを目指したはずなのに、関係者全員の生産性が低下する逆・働き方改革を成し遂げたクソUIがそこにはあった。
大学はこのマイナスしか産まないシステムに一体いくらかけたんだ？
疑問は尽きない。
ハードを重視するあまりソフトを軽視しまくったことが日本のIT産業を衰退させたという言説をどこかで聞いたことがある。
このソフトの出来を見る限り、それは本当かもしれないと思った。
はてブのホットエントリ(総合)で月内に数多く[あとで読む]タグを集めたエントリ
441あとで/2227users 未経験でも1カ月で即戦力クラスの知識が身に付く『webデザインドリル』公開 | knowledge / baigie
319あとで/2886users 賃貸住宅の退去費用として13万円請求された時の対応方法をまとめます｜犬笛｜note
305あとで/1662users 非デザイナーの僕がデザインぽいことをする時に使う便利なツール18選｜かずたか@プログラミング独学して起業した人｜note
260あとで/2214users 【朗報】Youtuber中田敦彦、うっかりまともな資産運用を数十万人に広めてしまう・・・これには金融マンも真っ青 | ライフハックちゃんねる弐式
228あとで/1529users 研修資料まとめ.md · GitHub
214あとで/1017users 技術ブログをバズらせたくて必死で身につけた情報収集術 - omuriceman's blog
191あとで/1517users 社会人の不幸の8割は合意のない期待から｜田中邦裕｜note
185あとで/1788users この法律が日本を｢生産性が低すぎる国｣にした | 国内経済 | 東洋経済オンライン | 経済ニュースの新基準
182あとで/1222users 科学的で現代的な「人を動かす」──『事実はなぜ人の意見を変えられないのか-説得力と影響力の科学』 - 基本読書
180あとで/970users 3年かけてたどり着いた英語記事を読むための方法 - Qiita
172あとで/796users 文系大学生が機械学習を０から始めて９か月でKaggle銀メダルを獲得するまで - Qiita
170あとで/669users いま知っておきたいLinux─WebアプリがOSのプロセスとしてどのように見えるか？ を運用に生かす - エンジニアHub｜若手Webエンジニアのキャリアを考える！
170あとで/1344users 機械の立体図をフリーハンドでとんでもなく上手に描く人が製図のテクニックを解説「恐ろしいレベル」「弊社に欲しい」 - Togetter
169あとで/2472users 食べログ3.8問題を検証 - クイックノート
168あとで/1146users 質問が出ないのは話し手の責任が8割。だから「質問が出る」ようにルールを決めたら、大成功した話。 | Books&Apps
166あとで/898users 貧困を減らす実験アプローチ｜安田 洋祐｜note
165あとで/679users 社内勉強会で作ったDocker/Kubernetes入門の資料を公開しました - inductor's blog
164あとで/695users データサイエンス・機械学習をやるためのエンジニアな本まとめ - 2019年版 - Lean Baseball
157あとで/1090users 20年の営業マン生活でわかってきた「仕事の本質」を全部話す。 - Everything you've ever Dreamed
154あとで/953users 【インスタ、エアビー、Slack等】人気サービスの初期ユーザー獲得方法
153あとで/1292users 【四川料理のスゴい人】家庭のキッチンの火力で「プロ並みのチャーハン」をつくる方法 - メシ通 | ホットペッパーグルメ
151あとで/1150users ０から100万円貯める、節約サバイバルガイド
149あとで/1972users 巨乳の炎上に見る進化と文化のミスマッチ - 本しゃぶり
148あとで/637users WebサービスのA/Bテストや機械学習でよく使う「確率分布」18種を解説 - paiza開発日誌
147あとで/1149users フライドポテト、チェーン店別徹底比較 :: デイリーポータルZ
143あとで/598users プログラミングの命名規則ガイドラインを規定するオープンソースプロジェクト「NamingC - エンジニア・プログラマのソーシャルITメディア
143あとで/661users ワークフロービルダーが新登場 : Slack で簡単にタスクを合理化 | The Official Slack Blog
142あとで/564users 「単体テスト」再入門！ 開発の現場でバグを確実に洗い出す最適な手法と、テストケースの作り方 - エンジニアHub｜若手Webエンジニアのキャリアを考える！
140あとで/1334users 13歳から43年間野宿していた「洞窟オジさん」はかつての住処でナニを食べていたのか？【極限メシ】 - メシ通 | ホットペッパーグルメ
138あとで/963users 自称IT企業があまりにITを使わずに嫌になって野に下った俺が紹介するWindowsの自動化の方法 - Qiita
意識高い系のいかにも仕事できなそうで職場や案件たらいまわしにされてるの丸わかりの増田とか、使えなさ過ぎて業界から追い出されてシコシコ技術ブログとか書いてるんだろうなっていう元ITエンジニアって肩書のブロガーとか自称業界人の皆様たちのおかげで、絶賛20代30代がいなくなり、40代50代の脳みそ壊れたオッサンオバサンばかりと少子高齢化のあおりを受けまくってるIT業界
そんな彼らが「IT業界がダメになったのは国や社会の責任だ！」と鼻息荒く早口でよく責任転嫁をしているが、彼らに「じゃあ昔のIT業界ってどんな風な仕事の仕方だったの？」っていっても口が裂けても答えてくれないことが多いのは周知の事実だと思う
だから、これから運悪く新卒でブラックにあたって職歴に傷がついているからIT業界に仕方がなく来るしかない、という第二新卒の方々や、IT業界に来たいんだ！という奇特な新卒やダ学生の増田向けに、まだ日本がITでは世界2位だったころは、どんな風な仕事の仕方だったのかを、知ってほしいからこれをかこうと思う。
増田が大好きで大好きで仕方がないweb系も、始まったのは実は92年くらいからで、その当時のweb系も合わせてどういう仕事なのかを知ったうえで、貴重な若い人生を無駄にしないように将来を考えてほしいと思う。
例えば業務用ツールの案件の場合、顧客はIT知識やましてやシステムのことなんて何も知らない
だからコンサルが「客の職場に常駐して」まず業務のヒアリングから始めていた
今でこそコンサルなんて半グレやヤクザみたいなのが業界の4割くらいしめていて詐欺師の代名詞みたいになっているが、当時はそんなことはなくちゃんとした技術者も多く、故に顧客がコンサルにまで正当にお金を払う文化が存在していた、この時点で信じられないとか発狂する増田もいるだろうが、真実なので落ち着いてほしい。
顧客は自分の会社ではあるけど現場でどんな業務が行われているかが見えてないケースさえ昔は多かった
まず業務手順の整理や確認をして行く、「SEとセールスエンジニアが常駐して」ヒアリングと現状の手作業の事務の工数をはじきだしていく。
今でこそセールスエンジニアとか茶飲みに来た営業の横にくっついている愛想悪そうなオッサンがやる気なさげに右上のタイムスタンプ数年前の資料かえただけのものをバサっと投げつけて技術わかってない客を見下しまくって喧嘩を売ってるような態度のエンジニア上がりとかが業界のセールスエンジニアの6割を占めているが、当時はそんなことなく、ちゃんとした一般常識や教養や礼儀や共感性が人並みにある健常者の技術者上がりも多く、故に顧客が常駐しているセールスエンジニアに正当にお金を払う文化が存在していた、この時点で嘘だ！主語がデカい！とか発狂する増田もいるだろうが、真実なので落ち着いてほしい。
現場の運用が把握して業務の棚卸しが始まる、無駄な業務を実施していることがここで判明してくる
だから、業務で発生している課題がハッキリして来る、システム移管時に何の業務が対象になるかが判って来る。
現状の客の業務ワークフローをドキュメント化して客に示して行き、詳細な機能要求仕様書も起こして行く。
今でこそIT業界のエンジニアたちが口をそろえて「それは客がすべきことだろ」と震え声でわなわなしながらブツクサ、ICT知らん奴は人にあらずみたいな商売と人様を舐め腐ったことを言うことも多いが、昔は顧客には本業の仕事だけに注力をして貰いたいのがベンダーとしての考えだったわけだ。これはwebサービスとか自社サでやるweb系の始祖であるところとかも一緒
課題が顕在化して来ると今後起こりうる可能性のある課題まで浮かび上がってくる、そして要求要件が固まると客にコストの提案が始まる
今までの業務コストとシステム化やシステム改修によるコストの差を示して行き、構築見積もりもここで概算を提示する。
概算見積もりの段階で高いと言う客にはここで終わりにはなってしまう。
OKなら、ここまでの見積もりコストを人権費と経費を基に計算して15%乗っけて完了、ドキュメント類は報告書として残して行く。
「なんでドキュメント類なんて残していくんだよ！ICTを知らん猿如きに！！！」って発狂するIT業界の現状の人間も甥が、理由はこれによって「顧客は競争入札が可能になるから」という至極まっとうなビジネスとしての理由がある。
こういうの今はBtoGでもめったにやらないだろうけど、大体すべてIT業界ではこれくらいが当たり前だった。増田が邪教の如く忌み嫌うウォーターフォールって奴だ(省庁は年度を跨ぐと手続き面倒だからデ通サが多いけどね)
さて、ここまで詰めてくれるわけだから、下流側は昔はコーディング設計書さえあった時代、マシンの性能以外を除けば、プログラマーとしてはこれほど助かることもない、綺麗なコーディングに注力できるから、だから昔の日本人プログラマーのコーディングは、芸術レベルで美しかったといわれる理由がこういう仕事の仕方が昔は当たり前だったからだ
昔のアメリカ以外で太刀打ちできる国は地球上に存在しないとまで言われていた時代の日本のIT業界を支えたSEやエンジニアたちは、ここまでやりがいのある仕事をする。
そりゃ年収一本当たり前だわな、これだけできれば。
今のIT業界の仕事の回し方なんて、アジャイル至上主義のweb系とかも見てもらえばわかるが、昔と比べればもはや学園祭の焼きそば屋レベル
上記のような仕事をされると困るから、そういうのが憎くて憎くて仕方がないみたいな奴らしかいないIT業界に、それでも来たいというのならどうぞご自由に。
え？海外いく？行けるわけないでしょコネもないのに。夢みたいなこといってないでパソコンの前に座るような不健全な仕事しないで汗をかいて働きなさい。
ディレクターサイドが大きいタスクを嫌がる工数が足りないと騒ぐ
リファクタしようにも軽微な改善を積まれまくって開発ができない
イベントを行うもイベントが終わるたびに燃え尽き症候群でエンジニアがやめていく
開発の経営陣は古いシステムをどうしようという話に一切口を出さず新しいシステム・機械学習に夢中
クローズするサービスを残し続ける、保守しなければ無料じゃねーんだよ
DBパンパン、使われていないテーブル多数あるけど怖いので消せない
CTO直下のチームは飽き性で色々なフレームワークを開発し運用チームに渡しまくるせいでもうぐっちゃぐちゃ
マイクロサービスを無理やりしたせいでバージョン違い、ミドルウェアの違いなどで更にカオス
DDDとか会社で誰も回せないし正常に導入できていないのに、推し続ける謎行為（俺たちは勘でDDDをやっている）
主要なサービスと新規事業サービスを乱立するのは良いが、損益点をはっきりさせて撤退する勇気を持つ
オンプレはもう限界だよ、オンプレでもいいけどサーバー構築を1h以内にやってくれ頼む
大規模なリファクタリングを行うために経営陣は今の現場の限界に気づいてくれ、株価見ろよ利益率悪いのが丸わかりだろ・・・
自分たちは弱いことを認めて改善をしていけばいい、全員やめろとは言わないけどもっと運用チームの一番下と経営陣がしゃべる時間を作って生の声を聞いてくれ
エンジニアをイベントごとに巻き込むな、全部任意イベントにしてくれ
エンジニアと営業を同じ制度・ワークフローで処理するのは限界ってことに気づいて
会社のお金の使い方見直しません？その社内イベント本当に必要ですか？
最近本当にそう思う。個々人はまともだとしても解決しない問題は残念ながらたくさんあることを痛感している。
そういう職場においてクソなのは仕事そのものではなくて大抵の場合ワークフローがクソなんだと思うようになった。
そんなもんを改善しても何も起きないんだろうけども、やっていくしかない。少しでもクソだって思う瞬間を殺すためには改善していくしかないのだ。
こんな感じ
http://blog.yuryu.jp/2012/05/blog-post.html
当時とは状況も違うしね。
といっても、〇芝や〇菱と違って学閥は感じられないのでほとんど影響はないんだと思う。
学部生は、主務昇進前の同期横並びになってる時期は、院卒の2年遅れ。
あとは様々。実力（いつ昇格研修に推薦されるか）次第
入社3年目くらいまでは夜10時くらいまで働くことも多かったけど、働き方改革の旗印のもと、8時以降の残業が禁止になり、定時日が週1設定され、
40時/月以上の残業についての手続きが煩雑になり上司もやりたがらなくなりました。
入退門システムと勤怠が連動してるので、サービス残業はありません。
GAFAとか行っちゃう強い人は↑で年収600万はあまり高くない・・と思うかもしれないけど、
結構な額の住宅補助と、ほぼ全額の通勤手当が出ます。自転車通勤でも出ます。（安いけど）
入社数年は寮か、寮扱いのレオパレスに月5000円で入居でき、
転勤すると自分で選んだマンションに住めて数年間家賃半額補助されます。
首都圏・大阪・名古屋だと補助倍率が変わり、もう少し安い。（東京勤務だったのでだいぶ助かった）
上司推薦の上研修に合格すると主務職という等級になり、お給料が一段踏みあがります。
平均給与ランキングみたいなので比較するとソニーとかと比べて安いのは、
工場の要員いっぱい抱えてるのと手当てを数字に反映してないせいもあると思う。 （借り上げ社宅だと所得税がかからないのでそこは有利）
あとは生命・傷害・自動車保険料がすごく安かったり、カフェテリアポイントがついたり、社割で家電とか買えたりします。
このあたりの福利厚生や人事制度は聞けば教えてくれると思うので、興味があったら就活生は人事に聞いてみて下さい。
とりあえず、この記事の内容について気になるところにコメントしていきます。
元記事の筆者の言う通り、パナソニックは事業部によりかなり風土が異なり、一部の全社共通の事項以外は結構異なります。
これは本当だと思う。
社員はエクセル方眼紙の仕様書を書くのが仕事で、バリバリコーディングすることはないという部署もある。
ただし、この点は事業部の中ですら風土が違い、僕のいる部署では協力会社にコーディングさせることもあるけど、
みんなプログラミングはするしできる。事業部と部署によるかな。
例えば、メモリ 1GB ぐらいの遅いマシンでビルドしている、ディスプレイが17インチ、
きちんとしたソース管理がない、などです。PCスペックやディスプレイなどは入社の時期によってはそこそこいいものになるんですが、
「壊れるまで使う」のが基本のためなかなか新しくなっていませんでした。
これは明確に違う。少なくとも、入社した2013年時点ではCAD用PCはメモリ16GBでQuadro積んだものが与えられてたし、デュアルモニタも使えた。
ラップトップはまともなスペックのレッツノートが与えられ、どちらも4年更新のリースなので、レッツノートのメモリが4GBだった次期はちょっと不満でしたがそれなりに使えるものでした。
ソース管理についてはメカ屋なのであんまり詳しくないのでノーコメ。なんらかの管理システム使ってたと思うけど・・・
具体的には書けませんが、改善提案をしたときには「新入社員(または入社2年目)なのに」というリアクションがついてまわりました。
中には「話を大きくすると、新入社員が思いつくようなこと何故今までやっていなかったのか」と問題になるのでと却下されたこともありました。
これはある。「物を作る前にひとをつくる」社風のため、若手は修行中とみなされる。
2年前くらいまではそうでした。
しかしここ2年くらいはセクハラに関する判定は厳しくなり、アファーマティブアクションとしてむしろ女性を優先して昇進させるという方針がトップから出されています。
逆にそれはどうなんだ・・？という気はしなくはないですが、「アファーマティブアクションである」と言い切られると納得できるところもある。
なんだかんだトラディショナルジャパニーズカンパニーなので言いたいことはいっぱいあります。
ほとんどの部署では毎朝・毎昼・毎夕のどれかで部署全員をあつめた会をやると思います。
そこで「綱領・信条・七精神」と呼ばれるチャントをみんなで唱え、小話をする儀式が発生します。
小話は持ち回りなので、人前で話しをすることが苦手な人はきっついと思います。
話が長い人も多いし・・
あなたがパナソニックで仕事を始めた場合、この3つに出会わない日はまずないと思います。
ワークフローシステムはあるんだけど、なぜかみんなエクセルの帳票を作りたがる。当然のように検印欄つき。
2001年にテンプレートの初版を作ったエクセル方眼紙でプロジェクト管理をするなボケ
研究所でもわりと「まとも」なことをしてる人ばかりです。
居室をドローンが飛んでるとか、そんな愉快なことはないです。夢のある話より事業貢献。当たり前といえば当たり前か。
新しいことに対してはまずリスクを考え、製造に根回しをし、品証、法務、営業エトセトラエトセトラに合議をとりつけないと何もできないので、
必然的に新しいことはしにくくなります。年初の計画にないことは予算付かないし。
でも偉い人がオッケーっていったらぜんぶオッケー！予算もつくし忖度してくれるぞ！
カイゼン活動やQC活動もやらせたがる。別にいいけど、本当に役立ってるかなぁ・・？
すっげえ時間と手間のかかる昇格研修（日立のケンロンみたいなやつ。5~10年目の中堅の昇格と、管理職候補のときにやる）とかね。
社内のシステムは全部クソです。20世紀のシステムが平気で動いてたりして驚く。
PLMシステムはほんとクソだし、
これにエクセル方眼紙を組み合わせた地獄の業務基盤が構成されてたりしてひっくりかえることがあります。
エクセル方眼紙をアップロードして印刷して・・・っていうのは構築時に誰かおかしいと言わなかったのか。
こいつのせいで設計資料どこだっけ（図面はあるけど設計書がない）などがおこりがち。
後述のe-チャレンジのセカンドチャンスがあるとはいえクソ度が高い。
入社時の話と配属の話が違うのは残念ながらあるっぽい。
というのは、どうも採用時点では部クラスまでは決まってるけど、
その中での課クラスの割り振りは後で決めるやりかたをとってるところがあるようだ。
例えば、xxxx事業部 開発部 までは決まっているけど、担当機種やシリーズは決まっていないとか。
これも事業部単位でやり方が違う。僕のときは研修時にヒヤリングがあった。
採用後、配属の決裁が下りてしまうと覆すのは結構たいへんなので、
やりたいことが明確な人は早めに人事部長と
明確にしておけば一応考慮はしてくれるはず。
僕のいるコネクテッドソリューションズ社（カンパニー）に限定されますが、
カンパニー社長が変わってからは上記の「ここがクソだぞ」を消していこうとしてくれてます。
問題を素直に言って改善しようとしたり実験的なことをやることを推奨しよう、というメッセージは発信されています。
ボロボロだったトイレや食堂も現代基準に合わせて改装されたし。
朝会の呪文詠唱はなくなっていないですが、鶴の一声で小話は、苦手な人は特にしなくてもよくなりましたね。
工場文化と研究開発のイノベーティブな文化を切り分けようとしてくれてるっぽい。
ただし、中間層まではまだ意識改革が行き届いてないっぽく、まだ保守的なことをいう人は多いです。
経営層の品位に関してははっきり言って経団連で迂闊なことを言って燃える他社よりはかなりましじゃないかなと思ってます。
事業部が変わるとほぼ他社な感じの会社なので、それまでの社内の実績を持ち込んだまま転職できるのはそれなりに普通に転職するより利点があります。
この制度の利用に関しては現職場にはすべて終わってからしか伝えられないので、どうしても無理になったらスッと転属するという、セカンドチャンスとなりえます。
長期所得補償保険に加入できますが、グループ社員は精神障害も対象になります（普通の保険は対象外）
鬱になってもなんとかなると思うと精神的に逆に鬱にならなくなるっぽい
少なくとも、僕の周りにいる人間は何かしら優秀なところがあり、人格的にもまともな人がほとんどです。
「ほとんど」としたのは、僕の知る限り数名頭のおかしいとしか思えない人もいるので・・・
ただ規模に比して無能・性格的に問題のある人は少ないと思います。
毎年25日付与されて、付与から2年超えても消化できない場合は毎年10日積み立てられます。
退職前にはちゃんと消化させてくれるし、普通に申請すれば休めるのでありがたい。
クソみたいだと思ってるところもありますが、案外、世間で言われるよりも変革に向かってる空気はあります。
車載部品や自動運転システム、電子部品組み立て装置やセキュリティシステム、工場ロボットやデジタルサイネージ、プロジェクターなど、
ぶっちゃけ家電以外の部門のほうが面白いと思ってます。地味なところでいろいろやってるよ。
家電も異常に軽い掃除機とか謎の球体扇風機、卓上燻製機など尖った製品は面白そうなんですけどね。
なんだかんだ家電もすげえまじめな作りしてるし。同期が調理家電の開発のベンチマークでコロッケ揚げてたら、見飽きすぎてプライベートでコロッケ食えなくなったとか言ってた
組織の慣性はあってクソなところもありますが、一つ一つつぶしていって、規模と革新性を両立させようと頑張っているところです。
改革が成った暁にはとても強い会社になりそうな気はするので、敬遠せずにぜひ話を聞きにきてみてください。
特に通過儀礼的な要素を含む新入社員研修、すごくリソースを取られる主務・主幹研修やエクセル方眼紙文化、根回し文化だのは、
IT基盤も現代の基準で構築してほしいし、提案活動や小集団活動はお手盛のパワポ発表会じゃなく、
データやノウハウも個人単位で溜め込まずにオープンに蓄積できるようなIT基盤にしてほしい。
社外の技術者や学生、そして僕とお客様にとって魅力的な企業であるために頑張って下さい。僕も頑張ります。
新卒でパナソニックに6年勤めましたがまだ退職しません。最先端の設計をしながらお給与も一定水準をクリアできる会社はなかなか多くはないと思うので、
もはや傾きまくりの日本の製造業にうっかり入社してしまったんだけれど、出張するにあたって必要な手続きがあまりにも多すぎる。どこもこんなものかしら？価値のない仕事に時間がかかり過ぎて早くも辞めたい。
いつどこに何の目的でどの程度の経費を使って出張に行くかを申請するワークフローがある。上長数名の承認に加え、経費を使うからか、何故か経理部門が承認のワークフローに入っている。
部門の中でグループ別の経費管理をしており、これを毎週メンテナンスしないといけない。出張前は、利用予定の経費を入力し、出張後は実績値を入れなければいけない。部門の中でのみ使われるシートであり、部門全体の経費は月毎に経理に提出。
グループの中で誰がどれだけ経費を使ったかを個人レベルで管理するためのもの。出張先も入力しなければいけない。(2)と違い、都度入力が必要でグループの中でのみ使われる。
(4)勤怠システム1
勤怠システムに出張予定を入力する。これも(1)と同じで上長数名にワークフローが回覧される。
(5)勤怠システム2
出張の際はタイムカードが打刻されないので、出張後、出張時の出勤時間と退勤時間を入力する必要がある。これも上長にワークフローが回る。
(6)カレンダー
出張の日はOffice365の自分のスケジュールに、「★出張」と記載する。★は日帰りを表すのが部門のルールらしい。
部門の電話当番が、一目で部員の勤怠状況を把握するために、専用のExcelに出張の日は、出張のため1日不在と記載する。
やっぱり途中で切れたので続きから
違います。
そうです。
はい。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
