  |
はてなキーワード: リリースとは
素人のクオリティで良いのか、それとも彼女だからとプロにタダ働きさせてるのか
まぁ社内の資料とかで使う程度ならそれでも良いかも知れないけど、ユーザーがどうのこうのって言ってるってことはちゃんとリリースするものだろうし、それでいいのか
--
この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。
1章
【コンテナとは】
他のプロセスとは隔離された状態でOS上にソフトウェアを実行する技術
コンテナにはアプリの稼働に必要となるランタイムやライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリの依存関係をすべてコンテナ内で完結できる。
全ての依存関係がコンテナ内で完結するため、オンプレでもクラウドでも起動する。
ステージング環境でテスト済みのコンテナイメージをプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテストに必要な工数を削減できる。
サーバー仮想化では、仮想マシンレベルでリソースを分離し、ゲストOS上でアプリが起動する。つまり、アプリだけでなく、ゲストOSを動かすためのコンピューティングリソースが必要。
一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に１つのプロセスが稼働している扱いになる。
【Dockerとは】
アプリをコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。
イメージ(アプリケーションと依存関係がパッケージングされる。アプリ、ライブラリ、OS)
レジストリに保存
【Dockerfileとは】
このファイルにコマンドを記述することで、アプリに必要なライブラリをインストールしたり、コンテナ上に環境変数を指定したりする。
1章まとめ、感想
コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンドや設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。
2章
ECSとEKSがある。
オーケストレーションサービスであり、コンテナの実行環境ではない。
ECSの月間稼働率は99.99%であることがSLA として保証。
デプロイするコンテナイメージ、タスクとコンテナに割り当てるリソースやIAMロール、Cloud Watch Logsの出力先などを指定する。
指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサーやタスクを実行するネットワークを指定。
2種類ありECSとFargateがある。 Fargateに絞って書く
Fargateとは
コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する
サーバーのスケーリング、パッチ適用、保護、管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる
・コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる
ECR
・App Runner
利用者がコードをアップロードするだけでコードを実行できるサービス。AWS側で基盤となるコンピューティングリソースを構築してくれるフルマネージドサービス。
App Runner
2021年5月にGA(一般公開)となったサービス。プロダクションレベルでスケール可能なwebアプリを素早く展開するためのマネージドサービス。Githubと連携してソースコードをApp Runnerでビルドとデプロイができるだけでなく、ECRのビルド済みコンテナイメージも即座にデプロイできる。
ECSとFargateの場合、ネットワークやロードバランシング、CI/CDの設定などインフラレイヤに関わる必要があり、ある程度のインフラ知識は必要になる。App Runnerはそれらインフラ周りをすべてひっくるめてブラックボックス化し、マネージドにしていることが特徴である。
ECS Fargateを利用した場合のコスト、拡張性、信頼性、エンジニアリング観点
【コスト】
EC2より料金は割高。ただし、年々料金は下がってきている。
【拡張性】
デプロイの速度 遅め
理由1 コンテナごとにENIが割り当てられるため。ENIの生成に時間がかかる
理由2. イメージキャッシュができないため。コンテナ起動時にコンテナイメージを取得する必要がある。
タスクに割り当てられるエフェメラルストレージは200GB。容量は拡張不可。ただし永続ストレージの容量が必要な場合はEFSボリュームを使う手もある。
割り当て可能リソースは4vCPUと30GB。機械学習に用いるノードのような大容量メモリを要求するホストとしては不向き
【信頼性】
Fargateへのsshログインは不可。Fargate上で起動するコンテナにsshdを立ててsshログインする方法もあるが、セキュアなコンテナ環境にsshの口を開けるのはリスキーである。他にSSMのセッションマネージャーを用いてログインする方法もあるが、データプレーンがEC2の時に比べると手間がかかる。
しかし、2021年3月にAmazon ECS Execが発表され、コンテナに対して対話型のシェルや1つのコマンドが実行可能となった。
Fargateの登場からしばらく経過し、有識者や経験者は増え、確保しやすい。
多数のユーザーに使ってもらう
CI/CDパイプラインを形成し、アプリリリースに対するアジリティを高める
各レイヤで適切なセキュリティ対策（不正アクセス対策、認証データの適切な管理、ログ保存、踏み台経由の内部アクセス）を施したい
2章まとめ、感想
AWSが提供するコンテナサービスにはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理が不要でインフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である。
3章
この章では運用設計、ロギング設計、セキュリティ設計、信頼性設計、パフォーマンス設計、コスト最適化設計について述べている。
Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計、不具合修正やデプロイリスク軽減のためのCI/CD設計が必要である。
モニタリングとは
システム内で定めた状態を確認し続けることであり、その目的はシステムの可用性を維持するために問題発生に気づくこと
オブザーバビリティとは
オブザーバビリティの獲得によって、原因特定や対策の検討が迅速に行えるようになる
・cloud watch logs
・Firelens
AWS以外のサービスやAWS外のSaaSと連携することも可能
Firehoseを経由してS3やRed shift やOpenSearch Serviceにログを転送できる
fluent bitを利用する場合、AWSが公式に提供しているコンテナイメージを使用できる
- ソフトウェアやライブラリの脆弱性は日々更新されており、作ってから時間が経ったイメージは脆弱性を含んでいる危険がある。
- 方法
脆弱性の有無はECRによる脆弱性スキャン、OSSのtrivyによる脆弱性スキャン
継続的かつ自動的にコンテナイメージをスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリの場合、CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャンも必要になる。
cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる（スキャン自体は1日1回のみ可能）
Fargateの場合、サービス内部のスケジューラが自動でマルチAZ構成を取るため、こちらで何かする必要はない。
・障害時切り離しと復旧
ECSはcloud watchと組み合わせることでタスク障害やアプリのエラーを検知できるうえに、用意されてるメトリクスをcloud watchアラームと結びつけて通知を自動化できる
ALBと結びつけることで、障害が発生したタスクを自動で切り離す
AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合、ECSは新しいタスクに置き換えようとするその状態のこと。
Fargateの場合、アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ不整合などが生じて危険。
ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能
自動でクォータは引き上がらない
cloud watch メトリクスなどで監視する必要がある。
パフォーマンス設計で求められることは、ビジネスで求められるシステムの需要を満たしつつも、技術領域の進歩や環境の変化に対応可能なアーキテクチャを目指すこと
利用者数やワークロードの特性を見極めつつ、性能目標から必要なリソース量を仮決めする
FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーとターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める
既存のワークロードを模倣したベンチマークや負荷テストを実施してパフォーマンス要件を満たすかどうかを確認する
・スケールアウト
サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存のタスクを停止する必要は原則ない。
スケールアウト時の注意
・Fargate上のECSタスク数の上限はデフォルトでリージョンあたり1000までであること。
ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能なIPアドレスが消費されていく
Application Autoscaling
Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う
CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意のステップに従ってタスク数を増減させる
指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針
--
この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。
1章
【コンテナとは】
他のプロセスとは隔離された状態でOS上にソフトウェアを実行する技術
コンテナにはアプリの稼働に必要となるランタイムやライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリの依存関係をすべてコンテナ内で完結できる。
全ての依存関係がコンテナ内で完結するため、オンプレでもクラウドでも起動する。
ステージング環境でテスト済みのコンテナイメージをプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテストに必要な工数を削減できる。
サーバー仮想化では、仮想マシンレベルでリソースを分離し、ゲストOS上でアプリが起動する。つまり、アプリだけでなく、ゲストOSを動かすためのコンピューティングリソースが必要。
一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に１つのプロセスが稼働している扱いになる。
【Dockerとは】
アプリをコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。
イメージ(アプリケーションと依存関係がパッケージングされる。アプリ、ライブラリ、OS)
レジストリに保存
【Dockerfileとは】
このファイルにコマンドを記述することで、アプリに必要なライブラリをインストールしたり、コンテナ上に環境変数を指定したりする。
1章まとめ、感想
コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンドや設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。
2章
ECSとEKSがある。
オーケストレーションサービスであり、コンテナの実行環境ではない。
ECSの月間稼働率は99.99%であることがSLA として保証。
デプロイするコンテナイメージ、タスクとコンテナに割り当てるリソースやIAMロール、Cloud Watch Logsの出力先などを指定する。
指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサーやタスクを実行するネットワークを指定。
2種類ありECSとFargateがある。 Fargateに絞って書く
Fargateとは
コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する
サーバーのスケーリング、パッチ適用、保護、管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる
・コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる
ECR
・App Runner
利用者がコードをアップロードするだけでコードを実行できるサービス。AWS側で基盤となるコンピューティングリソースを構築してくれるフルマネージドサービス。
App Runner
2021年5月にGA(一般公開)となったサービス。プロダクションレベルでスケール可能なwebアプリを素早く展開するためのマネージドサービス。Githubと連携してソースコードをApp Runnerでビルドとデプロイができるだけでなく、ECRのビルド済みコンテナイメージも即座にデプロイできる。
ECSとFargateの場合、ネットワークやロードバランシング、CI/CDの設定などインフラレイヤに関わる必要があり、ある程度のインフラ知識は必要になる。App Runnerはそれらインフラ周りをすべてひっくるめてブラックボックス化し、マネージドにしていることが特徴である。
ECS Fargateを利用した場合のコスト、拡張性、信頼性、エンジニアリング観点
【コスト】
EC2より料金は割高。ただし、年々料金は下がってきている。
【拡張性】
デプロイの速度 遅め
理由1 コンテナごとにENIが割り当てられるため。ENIの生成に時間がかかる
理由2. イメージキャッシュができないため。コンテナ起動時にコンテナイメージを取得する必要がある。
タスクに割り当てられるエフェメラルストレージは200GB。容量は拡張不可。ただし永続ストレージの容量が必要な場合はEFSボリュームを使う手もある。
割り当て可能リソースは4vCPUと30GB。機械学習に用いるノードのような大容量メモリを要求するホストとしては不向き
【信頼性】
Fargateへのsshログインは不可。Fargate上で起動するコンテナにsshdを立ててsshログインする方法もあるが、セキュアなコンテナ環境にsshの口を開けるのはリスキーである。他にSSMのセッションマネージャーを用いてログインする方法もあるが、データプレーンがEC2の時に比べると手間がかかる。
しかし、2021年3月にAmazon ECS Execが発表され、コンテナに対して対話型のシェルや1つのコマンドが実行可能となった。
Fargateの登場からしばらく経過し、有識者や経験者は増え、確保しやすい。
多数のユーザーに使ってもらう
CI/CDパイプラインを形成し、アプリリリースに対するアジリティを高める
各レイヤで適切なセキュリティ対策（不正アクセス対策、認証データの適切な管理、ログ保存、踏み台経由の内部アクセス）を施したい
2章まとめ、感想
AWSが提供するコンテナサービスにはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理が不要でインフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である。
3章
この章では運用設計、ロギング設計、セキュリティ設計、信頼性設計、パフォーマンス設計、コスト最適化設計について述べている。
Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計、不具合修正やデプロイリスク軽減のためのCI/CD設計が必要である。
モニタリングとは
システム内で定めた状態を確認し続けることであり、その目的はシステムの可用性を維持するために問題発生に気づくこと
オブザーバビリティとは
オブザーバビリティの獲得によって、原因特定や対策の検討が迅速に行えるようになる
・cloud watch logs
・Firelens
AWS以外のサービスやAWS外のSaaSと連携することも可能
Firehoseを経由してS3やRed shift やOpenSearch Serviceにログを転送できる
fluent bitを利用する場合、AWSが公式に提供しているコンテナイメージを使用できる
- ソフトウェアやライブラリの脆弱性は日々更新されており、作ってから時間が経ったイメージは脆弱性を含んでいる危険がある。
- 方法
脆弱性の有無はECRによる脆弱性スキャン、OSSのtrivyによる脆弱性スキャン
継続的かつ自動的にコンテナイメージをスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリの場合、CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャンも必要になる。
cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる（スキャン自体は1日1回のみ可能）
Fargateの場合、サービス内部のスケジューラが自動でマルチAZ構成を取るため、こちらで何かする必要はない。
・障害時切り離しと復旧
ECSはcloud watchと組み合わせることでタスク障害やアプリのエラーを検知できるうえに、用意されてるメトリクスをcloud watchアラームと結びつけて通知を自動化できる
ALBと結びつけることで、障害が発生したタスクを自動で切り離す
AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合、ECSは新しいタスクに置き換えようとするその状態のこと。
Fargateの場合、アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ不整合などが生じて危険。
ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能
自動でクォータは引き上がらない
cloud watch メトリクスなどで監視する必要がある。
パフォーマンス設計で求められることは、ビジネスで求められるシステムの需要を満たしつつも、技術領域の進歩や環境の変化に対応可能なアーキテクチャを目指すこと
利用者数やワークロードの特性を見極めつつ、性能目標から必要なリソース量を仮決めする
FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーとターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める
既存のワークロードを模倣したベンチマークや負荷テストを実施してパフォーマンス要件を満たすかどうかを確認する
・スケールアウト
サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存のタスクを停止する必要は原則ない。
スケールアウト時の注意
・Fargate上のECSタスク数の上限はデフォルトでリージョンあたり1000までであること。
ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能なIPアドレスが消費されていく
Application Autoscaling
Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う
CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意のステップに従ってタスク数を増減させる
指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針
元アジャイルコーチとして、アメリカのガチの、ガチのシステム開発現場に、言うたらエスノグラフィ（行動観察調査）をしてるようなもんです。三流プログラマながら。
そういうリファレンスみたいなことをお伝えしたら、皆さん（Regional Scrum Gathering Tokyo 2022の参加者）が喜んでくれるかなとか思って、内容を構成しています。
ただ、僕が知っているのはマイクロソフトだけですし、自分の職場だけなので、主語が大きすぎるとか、そう言うのはやめてください。心が傷つくから（笑）
そういうのを踏まえて聞いてください（笑）。全部一次情報で、人から聞いたものではないです。ちょっとだけマネージャ関連のところはマネージャに聞いたところもありますが、基本的には自分が経験したことのみで構成します。
ウォーターフォールは使われていない
まず滝。ウォーターフォールがどれぐらい使われてるのかって話ですけど、これは簡単です。ゼロパーセント、本当に見たことないです。
だからといって本当に素晴らしいスクラムをみんなやってるかっていうと、そうでもない。どれぐらいプロセスに対してマチュア（成熟）かはチーム次第なんだけど、少なくともイテレーティブじゃないのはないし、アップフロントデザイン（開発前の仕様策定）を大量に時間をかけてやってるというのもない。
デザインドキュメントっていうのを書く人もいれば書かない人もいて、書く人が多いですけど、書いても5ページぐらい。
何年か前にサム・グッケンハイマーというDevOpsで有名な人が日本に来たときに日本のお客さんに「ウォーターフォールとアジャイルのメリットデメリットを教えてください」って聞かれて、彼が「ウォーターフォールは全くメリットがないのでやめておきなさい」って言い放って。
私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い - メソッド屋のブログ
分かります。誰も使ってないんだから。やっぱりもうやめといた方がいいですよね、正直話無理があります。
次は、僕のチームがどんな感じで運用されてるかっていうお話をします。
マイクロソフトには統一プロセスとかなくて、基本的にチームをどう回すかはチーム次第なんですよ。でもだいたいみんな似たような感じでやってると思います。
基本的にはスモールチームです。どんな大きなプロジェクトであっても、スモールチームの集まりって感じです。
自分のチームについては、これがよいやり方かは分からないですが、個人商店みたいなもので。「IC」というのはIndividual Contributorですね、開発者。
マネージャからアサインされるバックログが基本的にはふわっとしているので、ICがそれを明確にします。
ICが仕様を自分で明確化して、自分でデザインして、インプリメントする。だからそれぞれがレスポンシビリティを持っていて、それぞれが実装をする。
ただ、同じマイクロサービスをメンテする役割の人みたいなのがいて、それは「Buddy」（バディ）みたいになっていて、僕の場合は例えば「スケールコントローラー」っていうのを開発していますが、スケールコントローラーのチームでバディになってると、質問というかお互いに話が聞きやすい。すぐに答えてくれやすいですね。
他のチームとかになると、ちょっとバリアがあって。やっぱりみんなそれぞれの仕事をやっているので、プライオリティがそれぞれあるんですよ。だから違うチームの人になると意地悪じゃなくて彼らのレスポンスは1日に1回とかになったりするわけですよね。仕方がないことです。
多分このチームの単位はマネージャが管理できる最大以下の人数で構成されてるんじゃないかなと思います。だから本当に自分のチームはそれぞれが個人商店みたいな感じですね。自分でレスポンシビリティを持って自分でやる。それは新人であっても一緒です。
司会）ここでちょっと会場から質問が入りました。このチームというのはどういう単位なんでしょうか。プロダクトの単位なのか、どういう単位なのか。
（右下の点線で囲われたところ）このチームはスケールコントローラをやっていて、（右上の3つのICを指して）このあたりはプラットフォームと言って中の基盤みたいなことをやってたりします。
でも基盤もかなり巨大なので、内部でいくつか分かれているんですけど、同じマネージャが見て、みんなを助けている、という感じですね。
司会）隣のチームと、このチームを分けているのは、マネージャが違うだけ？
ええと、大きな機能で分かれているというのがあります。例えば隣のチームはランタイムっていうチームなんで、Azure Functionsのランタイムを担当してるんですよ。
さて、エンジニアの評価っていうのはどんな感じになってるかっていうと、この図にはマイクロソフトは入っていないのですが、僕の友達に「ゆうさん」っていう人がいて、彼がブログでGAFAの給与体系みたいなをまとめてくれて、マイクロソフトも似たような感じです。
参考：GAFA米国本社のエンジニアの年収をジョブレベル別に比較してみた【Google・Amazon・Facebook・Apple】
こういう情報って外部に公開されてるので別に隠すことはないし、マイクロソフトの給料の額とかも調べられるんですよ。
どういうふうになってるかっていうと、エンジニアとしてランクがあるんですよね、「SDE1」「SDE2」とか。マイクロソフトの場合は「シニアソフトウェアエンジニア」があって「プリンシパルエンジニア」がある、みたいな。
このランクの人はこういうことができる、っていうのが明確に定義されていて、それによって給料が決まるんですね。
だから自分が給料を上げたかったらどうするかっていうと、プロモート（ランク上げ）してもらえるように頑張るって感じです。他の人との戦いじゃないんです。
いまより一つ上のランクの仕事をしばらくしていれば、マネージャが「こいつは今はシニアだけどプリンシパルの仕事してるからプロモートしよう」とノミネートしてくれる。
そうやってノミネートされたら次のレベルに行けるし、行けなかったら転職をする。転職するとそこでネゴシエーションしやすいので、その時に例えばシニアとかプリンシパルになれればその給料がもらえる。
ただ、そういうふうに上に行くとレスポンシビリティも大きくなるので、自分でチョイスする感じですね。自分でチョイスするし、自分との戦いなので。だから他の人と比べて不公平とか全然思わない。
給料を上げたかったら次のレベルになればいい。そういうアクションをとればいいので、あくまで自分との戦いって感じになります。
マネージャの存在っていうのは僕的にはすごい（日本と）違ってるように感じています。
日本にいるときはマネージャって進捗管理や課題管理をしたりとかして、プログラマとか開発者を指揮するとかそんなイメージだったんですかね、僕のイメージとしては。
アメリカの場合は、彼らが重視してくれるのは僕のキャリアなんですよ。僕がハッピーかどうかとか、僕がキャリアで成功するかっていうのをすごい重視してくれるんです。
これまで何人かマネージャが変わりましたけど、みんなそうでした。マイクロソフトには明確にそう定義されているんです。だからマネージャはみんなそういう動きをしてくれます。
マネージャのすごく大事な仕事に「アンブロック」というのがあります。IC、つまり開発者の人がどこかで詰まっている状態になると、マネージャが助けてくれる。ブロックされているものをアンブロックしてくれるんです。
例えば、僕が技術的に詰まるとして、誰かに聞かなあかんけど、誰か聞かなあかん人がなかなか答えてくれへんとか、そういうこともあるかもしれないです。
そういうブロックをされる状況が一番生産性を阻害すると思うんですね。
そういうときにマネージャがアンブロックを手伝ってくれる。ある人に繋いでくれたり、マネージャ経由で他の人が僕に協力してくれたりとか。
マネージャが、このプルリクエストを見たら分かりやすいよと教えてくれるとか。
あと結構面白いのは、少なくとも今の僕の職場では、納期が基本的にない感じです。
あるときもあるんですよ。どんなときかっていうと、マイクロソフト最大のイベントの「Build」というのが5月ぐらいにあって、そのキーノートで発表される予定のプロダクトみたいなもの。それが決まったら納期があるのかもしれないですけど。
マネージャも僕に対して「早くしてください」って言ったことは1回もないですね。どっちかというと、僕が「何か遅くてごめんな」とか言ってたら、「いやそんな気にすんなよ」って、「よくあることだよ」とか言われたりする。
これは多分いろんな意味合いがあるんですよね。多分クラウドのプラットフォームって、難しいことがいろいろあって、例えば自分が1週間でできるって思ったのに2カ月かかったりとか、ほんまにあるんですよ。
例えば、JVMにあるJarをアタッチするだけに見えた仕事に、僕は半年かかりました。
僕の能力のなさもあるかもしれないですけど、そういういろんな予想外のことが起こる。
やっぱり世界中の人が使うプラットフォームなので、よく分かってない実装とかしたらむちゃくちゃになるんです。ちゃんと理解して、より良いアーキテクチャを作らないとひどい目にあう。
だから多分マネージャは絶対に急かさないんだと思います。ちゃんと理解して出来るようになれば、次からは開発が速くなる。だからマネージャとしてはそこで急かさないことによって未来への投資をしてる感じなんじゃないかなと、僕は思ってます。
バックログはあり予定もあるが、達成されないこともしょっちゅう
司会）すいません、マネージャの話しに行く前に。質問が集まっていて。納期がないという話に関して皆さんが大混乱に陥っていてですね（笑）。納期がないとすると逆に何があるのか。バックログみたいなのがあるのか、ロードマップがあるのか。どういうものを始点に駆動されていて、牛尾さんの仕事が始まるのか。
バックログですね。大きなトピックだけはある。今期はこれをやろう、というのはあるんですよ。
だいたい今期はこれとこれをやっていこうというのがあって、それを荒い粒度ですけどブレイクダウンしたストーリーにして、それをICにアサインするんです。
でも、それが今期に達成されないということはしょっちゅう起こります。
思ったよりもすごく難しかったとか、あるシステムで改変が入るのでそれまで作れないとか、そういうのがしょっちゅうある。でもそれでそのICが責められることはないです。
変化は見通せないので仕方ないですよね。オーガナイズはされているけど、できなかったときはできないと認める、ということです。
司会）お客様からバックログの元になるような要求がきて、それがリリースされるまでのタイムスパンはどのくらいなんでしょうか？
僕らの場合はプロダクトオーナーみたいなチームとしてプロダクトマネージャがあって、バックログの発生元はプロダクトマネージャが決めるのですが、そのインプットソースとしては、彼らの戦略（ストラテジ－）とカスタマフィードバックですね。
あとはハッカソンでエンジニアがなにかプロポーズするときもあります。
そういうもののなかからプロダクトマネージャが、今期これをやればインパクトがあるんじゃないかと考えるものがピックアップされます。
で、それが達成されてリリースされるまでの期間は本当にピンキリです。
僕の場合は、早いときは1週間で終わりましたけど、さっきの話みたいに1週間で終わると思ったやつが半年かかったこともあります。
僕の上にはプリンシパルマネージャがいるんですね、それが日本で言ったら課長みたいなもので、その上に部長みたいなのがいて、で、テクニカルフェロー、これは事業部長みたいな感じです。
彼らの技術力はどんな感じか。
僕の1つ上の上司は、Azure FunctionsのJavaランタイムをイチから書いた人です。
その上の人は、Azure Automationの開発をしている人で別チームなので細かいところまでは知らないのですが、技術力がハンパない、ということだけは分かります。
何でかと言うと、どんなテッキーな話題を振っても、ものすごく早く深く理解するんです。彼が経験したことのないことであっても、Kubernetesでも、彼がやったことのないPythonとかでも、完璧に理解してアーキテクチャの深い話をするんです。
で、テクニカルフェロー。これはAzureの主要なサービスをイチから書いていたりします。
つまり何が言いたいかというと、僕の上司で僕よりもプログラミングができない人なんて一人もいないんです。
そしてこういう人が僕の仕事のサポートをしてくれる、応援をしてくれるわけです。
だからこんな上司に何かを説得する必要なんてないんです。彼らがテッキーなミーティングに参加して、しかも僕らにすごい鋭いアドバイスをくれるんですよ。
皆さんがもしマネージャをやるときには、こういう人たちと世界で戦わないといけない、ということをちょっと意識していただきたいんです。
私は1992年生まれなので、「喝采」は生まれる20年前の曲である。
両親が世代なのもあり、日頃から昭和歌謡曲を何曲か耳にしていたが、「喝采」から受けた印象は他の曲とはまったく異なっていた。
激しい喪失感と、とんでもない説得力があり、聞いた後耳の後ろがじんわりと熱くなっていた。
「喝采」がなぜ、平成生まれにこんなにも刺さったのがが気になった。
曲がリリースされた当時を知る人からすれば、「何を今更」と言われるかもしれないが、とにかく私の「喝采」への思いを文章にしてみたいと思う。
まずは、順を追って、ストーリーについて思うところを書いてみたいと思う。
いつものように幕が開き
恋の歌うたうわたしに
届いた報らせは 黒いふちどりがありました
そして、いきなり人が死ぬ。とんでもない急展開。
いきなりすぎて聞き手が一気に臨戦態勢に入る。入らざるをえない。
あれは三年前 止めるアナタ駅に残し
動き始めた汽車に ひとり飛び乗った
しかも、何やら複雑な事情を連想させるような「アナタ」との別れである。
なぜ「アナタ」を駅に残すのか、なぜひとり飛び乗るのか。
その情報の少なさと、リアルな情景描写が、一気に聞き手を曲の世界へと引きずり込む。
ひなびた町の昼下がり
教会のまえにたたずみ
「黒い縁取り」という唐突でショッキングでそして曖昧な表現が、「教会」や「喪服」といったキーワードから、徐々に確かな死であったという確信へと変わる。
それはまるで、主人公が徐々に死を実感していったのを聞き手に追体験させる。
つたがからまる白い壁
細いかげ長く落として
ひとりのわたしは こぼす涙さえ忘れてた
曲が2番に入っても、なおも事態が好転しておらず、悲しみの中にあることがわかる。
このあたりで、「止めるアナタ駅に残し」という、奥歯に引っかかるようなストーリーが、じわじわと悲しみに追い打ちをかける。
暗い待合室 話すひともないわたしの
耳に私のうたが 通りすぎてゆく
「アナタ」とどういう関係だったのかは分からないが、「待合室」の中で話すひともなく孤独なわたし。
そんな「わたし」にトドメの一撃をカマすのは、なんと冒頭に出てきた「わたしの歌」という伏線の回収。
アナタをなくし、悲しみの底にありながら、そこに流れるのは自分の「恋の歌」という大変皮肉の効いた状況となる。悲しい。
いつものように幕が開く
降りそそぐライトのその中
そんなに辛い状況であっても、恋の歌を歌わないといけない。歌手だから。
時系列が飛び飛びになるので、私は正直1回聞いただけでは理解できなかったが、最終的に以下の時系列だと解釈した。
死んだ（ちょっと前）→別れた（3年前）→教会で喪服（ちょっと前）→待合室（ちょっと前）→歌ってる（今）
おそらくだが、順を追って説明されたらここまでの感動と共感は無かっただろう。
とんでもない急展開で、しかもショッキングな内容を、ゆったりとしたテンポで聞き手に伝えてきている。
そのため、「黒い縁取りがありました」や、「暗い待合室 話すひともないわたしの」といった、直接的な描写だけれども、婉曲的な表現の意味をじっくりと考える間が与えられる。
考える時間が与えられるほど、ストーリーや主人公に親近感が湧くし、衝撃的な落ちにも感動を受ける。
しかし、ストーリーに引き込まれ、主人公に同情した状態での、今日も恋の歌を歌わなければならない「わたし」へは、たしかに喝采を贈りたくなるなぁという気持ちになった。
まさか、歌詞の冒頭が「曲の終盤」と「曲の題名」への2つの伏線になっているとは思わなかった。
色々思ったことはあるが、まとめると、以下の4つの要素が盛り込まれているということに気づいた。
そして、それを短い歌詞でやってのけた表現力や構成力。加えて、曲調や歌手の歌唱力などからくる説得力に圧倒され、総合的に私に刺さったのではないかと思った。
後崩壊書第2部のオープンワールドギミックとQTEがブンブン回る戦闘楽しすぎる……
追加コンテンツとはいえ本当にこれ2016年リリースのゲームなのか……
ライルはこのゲームには珍しい男だけど非プレイアブルの補佐ポジだから許す……
というかオタク向け美少女SFゲーなのにこいつ女受け良さそうなキャラだな……
知己の主人公にはやたら馴れ馴れしいけど線の細い優男ビジュでやたら声がいいんだよな……
ググったらCV寺島拓篤か……俺が知ってるのはログホラのシロエくらいだった……
聞いた感じ櫻井孝宏を爽やかにしたような声だなあと思ったけどこの声のおかげで不快じゃないわ……
クソッ萌えオタなのにまた男性声優に詳しくなってしまったぜ……
ティミドちゃんは伊藤かな恵……俺の知ってるのだとSAOのユイとかか……
でも俺アニメはそんなに幅広く見てないものの、伊藤かな恵はゲームでものすごく印象的なキャラを覚えてるぞ……
サ終したゲームでマイナーだから知ってる人はいないかもしれんが……
ガールズ×マジック(ガルマジ)っていうポチソシャゲをやってた時に推しだった桃田実羽……
あの高身長だけど天真爛漫なキャラを伊藤氏の脱力系天然ヴォイスで演じられてたのが魅力的でなんか刺さったんだよ……やっほっほい……今思うとあれは着せ替えゲーだった……ああいうのも良い……
あれと演技は違うけどティミドの常時マスク系人見知りおどおどヴォイスでも力の抜けたような独特なレゾナンス感ある声質が本当に良い……デレマスで例えるとちえり系ってところか……
惜しむらくはなんか後崩壊書2部のボイス音量が全体的に小さくて聞こえにくいことある点くらいだな……
崩壊3rdでは他にもジト目ダウナー毒舌系妹キャラのリリアを演じてる芹澤優ヴォイスとかすごい好きだ……
うむ……なぜか声優の話しになってしまっている……ライルのせいだぞ……
とりあえずあれだ……宝箱があと2つ見つからんわ……
こんなにいいゲームなのにあれと比べたらプレイ人口1/10弱っていうね……
どっちも楽しんでくれてるマグロ氏みたいなYouTuberは自動的に好印象になるんだけどね……
っていうか崩壊3rdのPC版クライアントの話しあったはずだけどドコ行ったんだ……PCのSteam版は出たけどさ……
既存のmiHoYo垢持ってるプレイヤーとしては普通のPC版でやりたいのよ……大画面でさ……
まあ俺はSnapdragon 870のスマホ持ってるから普段のプレイ自体は快適なんだけどさ……
3年くらい前はスマホの性能追いついてなかったからNoxとかMumuとかのエミュでやってたわけよ……
でも最近、海外では既に出てる公式PC版クライアントにちょっと触れてみたらやっぱエミュとは全然軽さが違うのね……
あれを体験しちゃうともうエミュではやってられないよねっていう……
まあモバイル版も最新のiPhoneとか持ってる人なら十分動くからいいんだけど……
ちょっと古い機種使ってる人だとそれなりにストレス生じちゃいかねんくらいにはグリグリの3Dアクションだからね……
というかそもそもあれよ……日本人はスマホを横に持ってアクションって時点でもう敬遠するんだよな……
でもさ……もう世界のモバイルゲーム見てると……日本で流行ってるみたいな縦持ちスキマ時間ポチゲーは下火……
なんか話が脱線というかもうレールに沿って走ってたまるかって感じだけど……
とにかくオタク諸氏よ……ティミドちゃんのスケート移動で壁走りしたり必殺技の足パッカーンを刮目して見たりすべきなんだよ……
お分かりいただけただろうか……しらんけどな……
Webマーケティング・コンサルティングを行うUOCC（横浜市）は、30～49歳の男女を対象に、「20代を振り返って後悔していること」を調査した。後悔していること1位は「投資」（33.9％）だった。
30～49歳の男女を対象に、「20代を振り返って後悔していること」を調査した（画像はイメージ）
2位は「資格取得」（31.6％）、3位は「いろいろなところへ旅行する」（28.7％）だった。4位以下は「勉強」（27.6％）、「人生設計をする」（26.7％）、「貯金」（24.1％）、「語学力の向上」（20.4％）、「自己投資」（20.1％）、「お金を稼ぐ」（19.5％）、「副業」（19.3％）と続いた。
お金やスキルアップに関する後悔が多く、金銭面や仕事のことで30歳以降に悩む人が多いことがうかがえた。また「いろいろなところへ旅行する」も3位にランクインし、旅行は人生において重要な経験であると考えている人が多いことが分かった。
20代にやっておくべきだったと後悔していることは何ですか？（出所：リリース、以下同）
ジャンル別では？
ランキングをジャンルで分類したところ、「生活編」で最も多かったのは「いろいろなところへ旅行する」（100人）。次いで「人生設計をする」（93人）、「たくさんの異性と付き合う」（59人）だった。上位を見ると、体力に余裕がある20代のうちに幅広い経験をしなかったことや、その後の人生について真剣に考えなかったことを後悔している人が多いようだ。
「仕事編」で最も多かったのは「資格取得」（110人）、次いで「勉強」（96人）、「語学力の向上」（71人）だった。自分のスキルアップについて真剣に取り組まなかったことを後悔している人が多い結果となった。
「お金編」での1位は「投資」（118人）、2位は「貯金」（84人）、3位は「自己投資」（70人）だった。
「健康編」での1位は「健康的な生活」（35人）、2位は「筋トレ」（31人）、3位は「美容」（28人）だった。30～40代はまだ健康な人が多いからか、健康や美容に関する後悔は比較的少なかった。
30歳以降にその後悔したことには取り組んだ？
30歳以降にその後悔したことに取り組んだか尋ねた。「取り組んだ」と答えた割合は69.0％で、約7割は20代でできずに後悔したことについて行動を起こしていることが分かった。
「取り組んだ」と答えた人からは、「全て取り掛かかっている。理由はさらに後悔したくないから。恐らく40代、50代になっていくにつれてもっとやらなかったことに後悔してくると思った。言い訳した人生にしたくないから」（34歳男性）や、「このまま変化なく過ごしてはいけないと思い、これからどんな自分になりたいか、いつまでにどんなことがしたいかを定期的に考え紙に書いて思い出すようにしている」（38歳女性）という声が聞かれた。
「取り組んでいない」と答えた人は、「結婚をしたため家事や育児に追われ、なかなか自分の時間が取れなくなったので取り組むことができなかった。若いうちにいろんな経験はとても大事なことだと思った」（45歳女性）など、結婚や家庭を持つことで難しかったという声が多かった。
今回の調査は、30～49歳の男女を対象に、インターネットで行った。期間は2021年12月28日～22年1月3日、有効回答数は348人。
今地方の自社サービス開発企業に勤めててその中ではテックリード的な立場。
Saasのシステムを設計フェーズから1から構築したこともあるし、
他にもレガシー目なサービスにDDDやクリーンアーキテクチャ的思想を導入したりTDDの構築と運用へあたっての体制構築や教育を主導したりとか
メンバーのスキルに偏りがある状態でも品質維持するための体制をなんとか作ったりとか
小さい企業ながら割と経験詰めたし今なら転職とか余裕だよなーって思ったがなかなかうまくいかない。
今のところ3社受けて全部1次面接落ち。受けたのは転職サイトのトップページに一番大きく載ってるような人気企業だから倍率は結構高い気はする。
今のところフルリモートで初年度年収550万～600万くらいを目指してる。多分500万くらいまで水準下げれば求人めっちゃ増えるし余裕な気はする。
あっちからスカウトが来て、競合ではないけど似たようなサービスを俺も構築した経験があったから
御社の製品の○○機能(リリースされたらプレスリリース打つくらいの機能)と似たようなものを営業にほしいと言われてから2日後にはテストカバレッジ率100%の状態でリリースまで持っていきましたとか、
当時はリソース足りず自分一人でほぼ全部対応してたけど爆速でリリースサイクル回して1年で機能数的にも競合製品に負けないくらいまで成長させましたとかこれ以上ないくらいアピールしたよ。
なーにが行けなかったんだろう。やっぱコミュ障なのが影響してんのかなぁ。「えーっとまあ」とか「なんか」「えーーそうですね…」みたいなのが多いのは自覚してる。
フルリモートで給与も高水準だと倍率高いから、もしかしたら20人中の1人や2人採用で第3位だったとかかもしれない。
何をどう変えたらいかなぁ。
転職指南書に書いているようなHPの企業理念読んで面接官が喜びそうなことを事前に作文して頭に叩き込んでおくみたいなことはやりたくないんだよね。
俺会社じゃ面接官する側だけどポートフォリオとか職務経歴しょぼいのに口だけ凄いこといってると
「ああ、この人面接官喜ばすための言葉を事前に作文してきたんだろうなーーー」「この人は”面接が”上手い人なんだな」とかやっぱ内心思っちゃうし
まあ応募して落とされて凹んでまた応募してを繰り返すしかないのかな。
アスタリスタ（3DモデルのVtuberと思ってもらえれば）というゲーム内キャラクターの
Vtuberと配信プラットフォームをセットにして内製すればガッポリやんけ
みたいなコンセプトでありながらAppleGoogleに上納するよくわからないヤツがあるんだが
やっぱりゲーマーにとってもVオタにとっても魅力がうすいのかプレイヤー人口は少なく
それでもアスタリスタ（初期3人＋追加1人）のライブはやめるわけにもいかず
演者が会社のスタジオ通って、投げ銭へのレスポンスするライブを毎日開催してると考えると
路上ライブとか営業どさ回り続けても芽が出ない感じがして気の毒になる
アダルトチャットのコメント返しを中のおっさんがやってるとファミ通記事にされた
「プラスリンクス」の方は同時性も声出しも無くていいし、体調不良で代わりの人がやっても
まずばれないだろうしええな
https://news.ycombinator.com/item?id=29918052
https://bugzilla.mozilla.org/show_bug.cgi?id=1749908
about:config で network.http.http3.enabled を検索し値を false にする
不思議なのは、ycで報告されたのが96がリリースされて十数時間経過した39分前で
追記:
CloudflareでJST 17時に行われたデフォルト設定の変更が原因でFirefoxに以前から存在したHTTP3のバグが誘発されたらしい
なので、それまでは動いていたそうな
私は今朝の時点で無課金石が25000個ありました。
今度スマートファルコンがピックアップに来たらガチャ回そうと思ってました。
そして、今週ちょうどピックアップ対象だったんですよスマートファルコンが。
しかし、今は有償石１５００個でキャラまで指定できる引換券が販売されていたのです。
https://kamigame.jp/umamusume/page/146262155186931649.html
これであればたった２０８０円の課金で済んでいたし、私の２５０００個の石は無事でした。
課金したのは10000円だけですが、失った無課金石のことを考えると8000円+22500円の損失なんですよ今回のミスは。
これからなにをやってもこの時のミスを思い出してつらい気持ちになることは避けられず
https://heaven-burns-red.com/:embed:cite]
猶予期間として「ヘブンズバーンレッド」リリースまでは続けるつもりですが、
とにかく終わりやこんなゲーム！
もともとはマシュマロ運営がソナーズって感想がぶっちぎりにもらえる小説投稿サイトのベータ版をリリース。
でも、そのサイト、10件以上の感想が来たら古い感想がロックされて見られなくなる仕組みだった。
実はリリース直後だとどれくらい感想が得られるものなのかが不明でした。もし感想表示上限で困る人が続出するとしたら、それは少し見ないうちに感想が10件以上届いちゃう人が続出するということです。
さすがにリリース直後に改善もせずそんなことが確実に起こると想定していたら、頭がおかしいと思います。そんなサイト見たことありませんし。なので最初は制限を解放する機能を未実装にして、様子を見ることにしました。
小説投稿サイト、感想がたくさんもらえることを目的としたサイトを作りましたよ！
でも、そんな急に感想来ることないやろｗｗｗｗガハハｗｗｗｗｗそんな想定してる奴、頭おかＣ
だから感想数に制限はかけるけど解除する機能は未実装で放置したよ！
そしてさらに困ったことに、制限を解放するための機能が、まだすぐには実装できそうにありません。そのうえ感想数を増やすための機能がさらに追加されます。つまり、ここからさらに矛盾した状態が大きくなってしまうことが予想されます。
さすがにそれはまずいので、有料会員の機能を先に作り、制限をなくせる手段を最低でも1つは用意することを検討しています。
ちなみにいきなり「有料です」としてしまうのは酷なので、熱心なユーザーには無料体験期間を用意する予定です。おおっぴらには言えませんが、「熱心なユーザー」と判定する基準はあれを設定してあれのあれを希望しているかどうかになりそうなので、もし対象外になりそうなら今のうちに対象ユーザーになるよう調整しておくのをおすすめします。
しょうがないから後々作る予定だった有料会員機能作って制限解除できるようにするよ！
でも、急にそういうとかわいそうだから「熱心なユーザー」には無料体験期間を用意してあげるよ。
「熱心なユーザー」判定の基準はちょっと大っぴらにはできないけど、
頑張って「熱心なユーザー」になれるように調整しておいてね☆
いや、イカレとる。
明確に法律に引っかかることじゃないけどVtuberという仕事に関わる重要な情報を漏らしてさらに嘘をついた…
となると男関係かなあって思う。
似たような案件を要件定義時点から主導したとか大型機能を2日でリリースまで持っていったとかリソース足りなくて俺だけで対応してた間も競合他社よりもハイペースで機能リリースしてたとかマネジメント経験もあるよとかそんなことをアピールしたと思う
【衝撃の事実】日本軽視の転売商材PS5、謎の山積み イケブクログ
ソフト売上など気にしない普通のユーザーは知らないかもしれませんが、昨今日本のコンシューマー業界ではPSの市場が急激に減少しています。
https://s.famitsu.com/ranking/game-sales/
上記のファミ通ランキングはあくまで協力店舗の集計でありAmazonなどは含まれないとはいえ、集計外の大型量販店や通販のみで特定タイトルが売れまくるとも思えないので実際に売れてるタイトルと大差はないでしょう。
見ての通りSwitch一色で、この週が特別なわけではなくPSタイトルのランク入りは0から多くても2〜3本程度が常態化しています。なぜなのか？
ゲーム機には商売的な寿命があり、サイクルが長くなりつつあるとはいえ6〜7年もするとソフトが売れなくなりリリースタイトルも減っていきます。
2013年発売のPS4は長く現役でしたがとうに全盛期は過ぎており、本体の事実上の販売終了やソフト売上の低下は自然な流れといえます。今頃はPS5へと緩やかに移行していたはずなのです。本来なら。
PS5は数字だけでいえば国内100万台以上を出荷していますが、『売ってるの見たことねえ』という人も多いでしょう、事実発売から一年以上経っても店頭に並ぶことは少なく転売が横行しています。
中国で販売されている正規のPS5は定価が日本より高いうえに海外アカウント作成が不可（一応抜け道はある）のためDLCに制限があり、並行輸入品を買うのが半ば常識となっています。
誤解している人も多いですが日本のコンシューマー市場は国別では世界2位、EUをひとまとめで計算しても世界3位の大きさです。日本の購買力が低いというより北米が桁違いなのです。
しかしここ数年日本のSIEJAは権限が縮小され続け開発スタジオも解散しました。日本の数分の1しか市場規模のないイギリスでのPS5出荷が60万台もあり、意図的な日本軽視は明らかです。
性能的にライバルに当たるXbox Seriesとの競争を優先していて、Xbox Seriesが雑魚すぎる日本市場はほっといてもエエじゃろと判断されているという説もあります。
昨年末、PS5の週販が5千台を切ったと話題になりました。Switch発売直前のWiiUで2千〜5千台売れていたといえば少なさがわかるでしょうか？ しかし次の週に記録を更新、販売台数は1133台でした。同じ週にSwitchは20万台を販売しています。
この数字は事実上の出荷停止で、売れた数は店舗の取り置きや流通の余りでしかありません。北米のブラックフライデーを優先したといわれていますが、よりによってハードの売れる年末に出荷停止したことで日本軽視が鮮明になりました。
ソフト販売不振でよくいわれるのが「今どきディスクとか買わない」との声です。PS5はディスクドライブ無しDL専用のPS5デジタルエディションもあり、実数が不明なDL版の売上が議論の的でした。
しかし最近、PSストアのDL版販売数は相当少ないのでは？ と言われています。
PS5DE版本体を見たことのある人はいるでしょうか？ DE版は週販100台前後の超希少種で、そもそも売れ行きを考慮に入れる必要のないレア機体です。
期間内にストアカード購入2万件達成で500円分をプレゼントというキャンペーンが最終総応募数19573件でまさかの不成立。
キャンペーン事務局の想定外だったらしく、期間終了後のサイトには『2万件達成！』の文字が表示されてしまったが後日取り消されました。
DL版の具体的な販売数は伏されているが推測できる材料はあります、PSストアとSwitchのe-shopのDLランキングと制作者の販売報告です。
PS・Switch・Steamなどのマルチ展開ソフトの場合、作者がTwitterで「どの機種が一番売れた」と報告することが多々あり、たいていSwitchがトップです。
PSストアで1位、e-shopで5位くらいのソフトでも「Switch版が大きく売れた」との報告が相次ぎ、PSストア1位って実はそんなに売れてないのでは？ と疑問が持たれていました。
レトロアーケードゲームの移植シリーズであるアーケードアーカイブスで発売されたタイトーの功里金団（くりきんとん）がPSストアランキングで上位に入ってしまいました。
特にエポックメイキングでもないマイナーなレトロゲーですら発売日にはトップに躍り出るPSストアランキングはどんだけ過疎なんだと話題になりました。
CC2の松山洋氏が公演で、DL版の比率は「PSのタイトルだと70％を越えることもあります」と発言。ニュアンスとしては「DL版はこんなに売れるようになったよ！」と前向きな意味合いだが、この発言でパッケージの売上からDL版の最大値を予測できるようになる。
結果、パッケージ実売数が少なすぎるPS5ソフトはDLで数倍売れているというファンタジーが否定され、DL版を含めても微増でしかないという事実が確定しました。
PS5自体はスペックを考えれば大変コスパの良いゲーム機……になるはずでしたが、入手の困難を考えると微妙な立場になってしまいました。
そしてメーカーとしてもユーザーの少ないPS5に全ツッパするわけにもいかずPS4へのマルチが前提なのですが、そのせいで「PS5じゃなきゃ駄目」という空気がいつまでたっても形成されません。
「俺はPS5持ってるしめちゃくちゃDL版買ってんよ！」という貴方。自分では気がつかないでしょうが、貴方は日本のPSユーザーの上位数％に位置するエリートです。しかし、一部の精鋭の存在は大局になんら影響を与えないのも事実なのです。
現在の日本のPSはワンダースワンやドリームキャストレベルのプラットフォームです。なんとかするには本体を欲しい人がいつでも買える状況を作るしかありませんが、世界的な半導体不足の影響で見通しは良くありません。
どう考えても100万人のユーザーはいないPS5ですが、2月発売のエルデンリングの売上で現在の本体普及率が大体明らかになるかもしれませんね。
