  |
はてなキーワード: プラットフォームとは
転売ヤー嫌いだから「ネットワーキングビジネスやってます！」って事業者からは絶対買わないようにしてるけどさ。
--
この本は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の主要なサービスをイチから書いていたりします。
つまり何が言いたいかというと、僕の上司で僕よりもプログラミングができない人なんて一人もいないんです。
そしてこういう人が僕の仕事のサポートをしてくれる、応援をしてくれるわけです。
だからこんな上司に何かを説得する必要なんてないんです。彼らがテッキーなミーティングに参加して、しかも僕らにすごい鋭いアドバイスをくれるんですよ。
皆さんがもしマネージャをやるときには、こういう人たちと世界で戦わないといけない、ということをちょっと意識していただきたいんです。
随分長々と書いてくれたが、前半に異議はない。というか、そんなのわかってて書いてる。
あのオープンレターは明らかに賛同者を募る「署名」行為として一見成立しているように見せかけているので、記名と署名の違いを書いた所で、オープンレター関連の話には本質的に無関係だろうからね。
そのことは貴殿が書いてる、
真正に成立した文書というのは、なにも直筆サイン入りの文書に限らない。
たとえば本人がスマホで送ったLINEや本人のtweetを印刷した物は、内容が本人=作成名義人の意思に基づく文書なので、真正に成立したといえる。
にもあるように、効力としては同等と扱われる。
そして、いわゆる署名運動つまり賛同者一覧を作るだけなら、電話やメールやSNSで本人に確認を取れば充分だ。
もしくはGoogleFormの仕組みを理解してないで書いてるだろ。
電話やメール、SNSで本人に確認を取れないのがGoogleFormなんだよ。
一部の肩書を含む署名にはなんとか推測して当人連絡取れるかも知れない。
xx x（無職）
xx xx（会社員）
なんてのにメールアドレス無かったらどうやって連絡を取れるというんだ？
そして、
とあるが、厳密にはその通り。
change.orgのFAQ「オンライン署名は国や自治体の請願に使えますか？」を読めば彼らも悩んでいるのがよく分かる。
ただ、貴殿が書いてる「記名（名前文字列が掲載）されている人々の意思に基づいている（真正である）ことを証明する」行為を唯一可能にしてるのがChange.orgなんだよね。
「正当な手続きでの署名ではない」という書き方も、そもそもアレは「署名」では無いので、なんかズレてる。
法律上の「署名」というのは自分の名前を手書きすること又は手書きした筆跡を言う。だから「ネット署名」は「署名」では無い。例のオープンレターにあるのは署名ではなく記名に過ぎない。
日常用語にいわゆる署名つまり賛同者名簿作成手続のような用法は、地方自治法上のリコール手続等で若干の例があるが、基本的には区別した方が良い。
あと、「署名として私文書の成立要件を満たしておらず」という表現もおかしい。署名は私文書の成立要件ではない。立証手段の一つに過ぎない。
署名、つまり文書に本人直筆の氏名記載があれば、文書の成立の真正、つまり文書の内容が文書作成名義人の意思に基づいていることが、民訴法の規定により推定される。（「推定」なので、反証されれば覆る。）
ちなみに本人がハンコを押した場合も同様。ハンコの場合はさらに、本人のハンコの印影があれば本人が押したと事実上推定され、その結果、文書の成立の真正が法律上推定される。
真正に成立した文書というのは、なにも直筆サイン入りの文書に限らない。
たとえば本人がスマホで送ったLINEや本人のtweetを印刷した物は、内容が本人=作成名義人の意思に基づく文書なので、真正に成立したといえる。
もっと言えば、本人が「これは私の意思で作った文書です」と言えば、それで成立の真正を証明できる。（ここでいう「証明」というのは、自然科学的な証明ではなく、裁判官に『十中八九間違いない』との心証を抱かせることを言う。）
だから、署名というのは文書の成立要件ではなく、その成立の真正を証明する手段の一つに過ぎない。
電子署名法上の電子署名は、手書きサインと同様に、成立の真正を法律上推定させるものだ。
電子署名があれば、文書の内容が名義人の意思に基づくと推定されるので、「こんな契約知らん」と言いにくくなる。（あくまでも推定なので、反証されれば覆る。）
けれども、電子署名が無くても、他の手段で文書の成立の真正を証明することはできる。同内容が掲載されたままのTwitterの画面を証拠化するとか、本人が「これは私の意思に基づきます」と表明するとか。
もし、あの文書について、そこに記名（名前文字列が掲載）されている人々の意思に基づいている（真正である）ことを証明する必要に迫られたときに、電子署名が有れば、それが裁判手続きであれば真正が推定される。また、世間一般からもそれなりに信用してもらえるだろう。
もっとも、他の手段で成立の真正を証明できるなら、裁判上も世論形成上も問題は無い。
たとえば賛同者に「確かに賛同しました」とteeetしてもらうとか、賛同する旨のメールを送っておいてもらうとか。
電子署名も、将来的にはスマホとマイナンバーカードで電子署名を行えるようなプラットフォームが出てくるかもしれないが（出てきてほしい）、現時点では簡単なプラットフォームは存在せず、世間一般にいわゆる署名運動すなわち賛同者一覧作成プロセスに用いるには全く不適だ。
そして、いわゆる署名運動つまり賛同者一覧を作るだけなら、電話やメールやSNSで本人に確認を取れば充分だ。
このことは、文書が仮に法律行為として作成される処分証書であっても原理的には同様であるが、まして何か世間にアピールしたいというプロパガンダに過ぎぬ代物であればなおさら当てはまる。
ネット署名運動に電子署名が必要だなんて、まるっきりデタラメだ。
毎日世界のどこかで起こっている問題は議論の対象となって、直接関係ない人達ばかりが議論している。
直接関係ないから好き放題に言えるし、深いことは知らないから感情論とか他人の感情を煽るとかばかりで、仕組みを組み替えたりもできない。
国内法も詳しくなく、国際法も詳しくないし、堅い長文も読めない。
YouTubeやアマゾンのようにお金渡して勝手に営業してくれる人を社外に増やすわけでもない。
暗号通貨やNFTで、分散型とか言っているが、開発なりプラットフォーム持っている特定の団体に振り回されるのには自ら積極的に関与していく。
勝手にコピーされて広まるものばかり。海外からすりゃ日本のネット見て持ってくるだけで売れる物が沢山あるってことになって都合がいいんだろうけどさ。
これ見て思った
https://togetter.com/li/1830266
おじさん構文はキモいが何故だろうか？
絵文字が多いとかそういうのもあるけどそもそも内容がキモいというか独特な気がする
「一方的に見える」「手紙っぽい」というのがよくないんじゃないだろうか？
LINEやSNSは即レスできるコミュニケーション手段なので口頭の会話に近い
そこで即レスができない手紙っぽい内容にすると、まるで手紙を口に出して読むかのようないたたまれなさが生じるのではないかと思った
もっと具体的に特徴を考える
これらは「より誤解されないように」という気持ちが入った結果だと思う
会話では少しくらい誤解されてもすぐ訂正ができるが、手紙やブログや一方通行な文章ではそうはいかない
なので一発で誤解されないようにあの手この手で正しく伝わるようにデコる
結果気持ち悪くなる
詠嘆っていうらしい
比較すると前者はレスを求めているのに対して後者はレスが無くても会話が成立する表現だ
おじさん構文を使う人はレスが返ってくると思っていないのかもしれなくて、そのおっかなびっくり感が透けて見えるあたりが気持ち悪い
例：今日は学校だったのかな？僕は今会社が終わったところだよ！今日は寒いね、増子ちゃんはちゃんと暖かくしてる？寒い時は首元を温めるといいらしいよ！
話題が多い結果、質問数も多くなり、質問数が多くなると圧が強くなるから結果的に「かな？」が増える
・話題が当たり障りなさすぎる
例1：今日は学校だったのかな？僕は今会社が終わったところだよ！今日は寒いね、増子ちゃんはちゃんと暖かくしてる？寒い時は首元を温めるといいらしいよ！
例2：数学のテストどうだった？僕のプレゼンは上手く行ったよ！雪が降ってるね、増子ちゃんいつも首元が寒そうだから心配だよ！
例2の方がマシに見えない？
例2の方が親密度高いんだろうな感がある（ストーカーかもしれないけど）
当たり障りないテキストは無理やり話題を作ってるように見えてより痛々しくみえる
例1：今日は重要なプレゼンがあったけど上手く行ったよ！早く帰ってパーッと飲みたい気分だなあ！雪が降ってるね、すっげー寒い！
例2：今日は数学のテストがあったんだってね？今日は帰って打ち上げかな？雪が降ってるね、寒くないか心配だよ
例2の方がキモく見えない？
ただし自分のことだけ話すのもコミュニケーションできないやつだから
バランス難しいけど
・謎報告
単に話題がないのが原因
せめてユーモがあればいいんだけど
テキストが多くなり、相手への言及が多くなると自ずとハラスメントが多くなる
まとめ
↓
謎報告
→かな？が増える、セクハラが増える
まあこんなところでしょ
アスタリスタ（3DモデルのVtuberと思ってもらえれば）というゲーム内キャラクターの
Vtuberと配信プラットフォームをセットにして内製すればガッポリやんけ
みたいなコンセプトでありながらAppleGoogleに上納するよくわからないヤツがあるんだが
やっぱりゲーマーにとってもVオタにとっても魅力がうすいのかプレイヤー人口は少なく
それでもアスタリスタ（初期3人＋追加1人）のライブはやめるわけにもいかず
演者が会社のスタジオ通って、投げ銭へのレスポンスするライブを毎日開催してると考えると
路上ライブとか営業どさ回り続けても芽が出ない感じがして気の毒になる
アダルトチャットのコメント返しを中のおっさんがやってるとファミ通記事にされた
「プラスリンクス」の方は同時性も声出しも無くていいし、体調不良で代わりの人がやっても
まずばれないだろうしええな
どれだけ業界に詳しくて想いが熱いかというその思いは黙ってスパチャなげとけばいいんだよ
独自の目線で関係ない話を語って自分がいかに正確で詳しくて深くてすごいかアピールしてくれてもね
子豚ちゃんたちにも子豚ちゃんの推しにも1円も入ってこないどころか、にわかの新参で恥知らずな素人が参入してくれて潤してくれるハードルをあげてどうするの
難解で特殊で専門的で知識がないと入れないプラットフォームには人があつまらないって事くらいわかるよね
子豚ちゃんがその困難さの権化になってくれるのは誰が喜んでくれるのかな
「俺が全額振り込んでやるから、おまえらはもうついてくんな」ってカッコつけるのならだれも口出しできないとおもうけど
君は一体いくらくらい振り込んだのだい？
https://gigazine.net/news/20220111-youtube-superchat-ranking-2021/
この手の話題になる度にブコメでも毎回補足されていていい加減学習しろって感じなんだが、海外でこの手のライブ配信といえばまずTwitchなの。
Twitchの投げ銭は中抜きありのCheerと中抜きなしのDonationってのがあって、トータルだとトップ配信者はTwitchの方が稼いでるんじゃないかな。（要出典）
一方日本ではライブ配信でもYouTubeが人気なのでこうなる。「日本のVTuberがすごい」というより「日本以外の配信者にYouTubeのライブ配信機能がそこまで使われていない」と言った方が正確。
確かシェア的にはTwitch : YouTube = 3 : 1くらいだった気がする。前にざっくり調べただけだから違ったらごめん。ちなみにYouTubeはGoogleのサービスだけど、TwitchはAmazonのサービス。
ホロライブは海外のファンが多い。1, 2年くらい前からRedditでミーム的に流行り始めて登録者数や再生回数が急増した。つまり、基本国内で完結してるバーチャルYouTuber業界の中でホロライブだけ飛びぬけてパイがでかくなってる。
それと、ランクインしてるカリオペとキアラは「ホロライブEN」所属でそもそも日本人じゃないし配信も英語圏向け。当然英語圏ファンが多い。
要するに今のホロライブ人気は国内市場だけで成り立ってるわけじゃないってこと。よく知らんのにいっちょ噛みして「馬鹿な日本人が外資に金を～」ってやってるのマジで恥ずかしいぞ。面の皮の厚さ5mくらいある？あるなら仕方ないが…
「ぼくは下世話なゴシップが大好きなお下劣人間です！」っていう自己紹介か？大多数はまともに真面目に活動やっとるぞ。お前がゴシップばかり見てるゴシップ大好き人間なだけ。
こないだのにじさんじ麻雀杯とか盛り上がってたのにはてブは誰もその話してねーしよぉ～
結局よく知らないものに部外者がいっちょ噛みしようとすると金とスキャンダルの話しかできないんだよね。
別にVTuberって投げ銭だけでやってるわけじゃなく、YouTubeなのでHIKAKIN的な人たちと同じように再生回数に応じた広告収入が入るし、月額いくらかでそのチャンネルの有料会員になれるメンバーシップってのもある。
事務所所属の場合、YouTubeの取り分引いた額をどう配分してるかは事務所による。ちなみにTwitchだとSubscribeっていうやつがYouTubeのメンバーシップにあたるぞ
じゃあお前もさっさとNetflixだのAmazonプライムだのやめてニコニコ動画とU-NEXTと楽天市場に金使え。俺とお前でニコニコを救うんだよ！頼むよ！
自分の興味が向かない分野で外資サービスに金を使う人を亡国の民みたいに言うのって戦時中の非国民呼ばわりと何が違うん？
まあそれはそれとして、ライブ配信ならTwitCastingあたりは国内企業だし、ゲーム配信ならOPENREC.tvっていうサイバーエージェントの子会社がやってるサービスがあって、過疎ってること以外は高画質低遅延の神プラットフォームだからよろしくな！
あとGoogle税はお前らに言われるまでもなく当然皆認識してるわけで、物販でBooth使ったり自サイト作ってやったりしてる。ただ結局のところ新規を取り込み続けるには人の多い場所（YouTube）でやるのが一番効率的なので、現状そこはプロモーション料と思って割り切ってやっていくしかないんだろう。
ちなみに、Streamlabsとかのドネーションツールを使えば中抜きなしで投げ銭できて、TwitchやYouTubeでの収益化がNGでも使用が容認されてる。じゃあなんで使ってる人が少ないかっていうと、わからん。
わからんが、事務所所属の場合は権利関係の管理がややこしくなるとかそんなところじゃなかろうか。識者求む
つかこの大YouTube時代に簡単そうに言うなあ…作ったところで既存を連れてこれても新規はYouTubeから引っ張ってこなきゃならんし、トータルで見たら現状そこまでする旨みって薄いんじゃないかな。（そして維持費をAWSに吸われる）
これも毎回馬鹿の一つ覚えのように言う奴が湧くけどさ、推しVだの何だのってどう見てもアイドル文化の延長線上にある界隈なのに、そこらへん全部無視していきなり水商売の話にしたがるのってただの馬鹿じゃん。浅すぎる。
ここ10年くらいVTuberに限らず色々な配信者を同時接続1桁の人から数万の人までたくさん見てきたけど、ライブ配信って常に一対多だから基本一対一の水商売とはそもそも毛色が違うんだよね。
それこそ路上ライブとかアイドルの握手会とかの方がずっと実態に近い。握手して二言三言喋って終わり、投げ銭して読まれて終わり。
視聴者側はまあ時々気合の入ったしょうもない奴もいるが、実際見てると結構ドライというかあっさりしてる配信者が多いよ。視聴者が増えれば尚更一人一人に構ってられんしな。まあでもこの辺の雰囲気は実際に見てないと分からん機微なのかなとは思う。仕方ないよね、見てないんだから。
ところでバーチャル水商売的なものだとユメノグラフィアってのがかつて存在してえ…（サ終）チケット制でキャストと一対一で話せるサービスなんだけど、こっちの方がずっとキャバクラなのに言及する人が殆どいないんだよね。
まあそういう人たちはそもそも知らないし知ろうともしないんだろうね。そのくせして自分は賢いですけど？みたいなツラをするのがはてブしぐさだから救いがない。
ただまあ、えにからがユメノグラフィアを畳んだってことはこの界隈でキャバクラ的な一対一サービスみたいなものがそもそもあまり求められていないという説もある。俺自身あまり求めてないし。キャストさんのYouTube配信は時々見てたけど。
単純に推しをひっそり応援したいだけ、みたいな人が多いのかなって感じ。一応言っとくけどROM専の方が遥かに多いからな？
あと俺は詳しくないが17LIVE（イチナナ）あたりはキャバ的雰囲気があるかもしれん。でもあそこはバーチャル界隈ほとんど関係ない場所だからVTuber全体に当てはめるのはさすがに乱暴すぎるだろう。識者求む
アイドル自体が水商売だと仰るのならもうこれ以上言うことはありませんのでお引き取りください。
最後にこれ気になってるんだけどさ、ここ1年くらいずーっと雑なVTuber増田を乱発してる奴おらん？
俺は単独かごく少数の仕業じゃないかと踏んでるんだけど、割とどっぷりめに浸かってる側からすると何じゃそりゃ？？ってなるような内容で似た文体の雑VTuber増田がいくつも書かれてて、はてブでそこそこブクマされるしこの間も何百とか付いててば～～～っかじゃねえの！？（ハルパゴス）って感じなんだよね。noteでやれ。あ、匿名風だからnoteじゃできないのか。失敬失敬。
→以下ループ
分かってるブクマカもちゃんといるんだけど、雑増田が乱発されすぎてていちいち補足や訂正するのも面倒なのよ。お前らいっちょ噛み勢はVTuberの知識を雑増田とスーパーチャットランキングの記事だけで得てるだろ？実際に動画や配信を見てる奴なんて殆どいないだろ？
「VTuber」というキャッチーなワードさえ付けば雑にいっちょ噛みしてくるの、誘蛾灯に寄ってくる虫と同レベルなんだわ。侍エンジニアの記事でプログラマを語るようなもんでさ、もう少し恥というものを知ってくれ。
はてブにいるくらいなんだからそこそこいい年なんだろ？知らないことを知ったかぶらないっていう当たり前の振る舞いをしていこうや。まあ面の皮の厚さが5mあるのなら仕方ないが…
