「SaaS」を含む日記 RSS

はてなキーワード: SaaSとは

2022-01-25

本のまとめ

--

この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。

1章

コンテナとは】

他のプロセスとは隔離された状態OS上にソフトウェアを実行する技術

コンテナ利用のメリット

環境依存から解放

コンテナにはアプリの稼働に必要となるランタイムライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリ依存関係をすべてコンテナ内で完結できる。

依存関係を含めたパッケージリリース単位となる

環境構築やテストに要する時間の削減

優れた再現性ポータビリティ

全ての依存関係コンテナ内で完結するため、オンプレでもクラウドでも起動する。

ステージング環境テスト済みのコンテナイメージプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテスト必要工数を削減できる。

リソース効率のアップ

サーバー仮想化では、仮想マシンレベルリソースを分離し、ゲストOS上でアプリが起動する。つまりアプリだけでなく、ゲストOSを動かすためのコンピューティングリソース必要

一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に1つのプロセスが稼働している扱いになる。

Dockerとは】

コンテナライフサイクル管理するプラットフォーム

アプリコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。

アプリソースコード + Dockerfile

↓ buildでイメージ作成

イメージ(アプリケーションと依存関係パッケージングされる。アプリライブラリOS)

shipイメージの保存

レジストリに保存

run コンテナの実行

オンプレクラウドなどで起動

Dockerfileとは】

イメージを構築するためのテキストファイル

このファイルコマンド記述することで、アプリ必要ライブラリインストールしたり、コンテナ上に環境変数を指定したりする。

1章まとめ、感想

コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンド設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。

2章

AWS提供するコンテナサービス

コントロールプレーン

コンテナ管理する機能

コントロールプレーンは2種類

ECSとEKSがある。

ECS

フルマネージドなコンテナオーケストレータ。

オーケストレーションサービスであり、コンテナの実行環境ではない。

ECSの月間稼働率99.99%であることがSLA として保証

タスク

コンテナ動作するコンポーネント

タスクは1つ以上のコンテナからなる

アプリを起動するためにはコンテナ必要

タスク定義

タスク作成するテンプレート定義JSON記述

デプロイするコンテナイメージタスクコンテナに割り当てるリソースやIAMロール、Cloud Watch Logsの出力先などを指定する。

サービス

指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサータスクを実行するネットワーク指定

クラスター

サービスタスクを実行する論理グループ

データプレーン

コンテナが実際に稼働するリソース環境

2種類ありECSとFargateがある。 Fargateに絞って書く

Fargateとは

サーバーレスコンピューティングエンジン

AWSのフルマネージドなデータプレーンとして定義されている

コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する

Fargate メリット

ホスト管理不要であること

サーバーのスケーリングパッチ適用保護管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる

Fargate デメリット

価格EC2より高い。

利用者コンテナの稼働するOSには介入できない

コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる

ECR

フルマネージドなコンテナレジストリ

コンテナイメージを保存、管理できる

コンテナが利用されているサービス

Lambda

・App Runner

Lambda

 利用者コードアップロードするだけでコードを実行できるサービス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の登場からしばらく経過し、有識者経験者は増え、確保しやすい。

システム要件確認

多数のユーザーに使ってもらう

可用性を高めるためにマルチAZ構成を取る

CI/CDパイプライン形成し、アプリリリースに対するアジティを高める

レイヤで適切なセキュリティ対策不正アクセス対策認証データの適切な管理ログ保存、踏み台経由の内部アクセス)を施したい

2章まとめ、感想

AWS提供するコンテナサービスはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理不要インフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である

3章

この章では運用設計ロギング設計セキュリティ設計信頼性設計パフォーマンス設計コスト最適化設計について述べている。

運用設計

Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計不具合修正デプロイリスク軽減のためのCI/CD設計必要である

モニタリングとは

システム内で定めた状態確認し続けることであり、その目的システムの可用性を維持するために問題発生に気づくこと

オブザーバビリティとは

システム全体を俯瞰しつつ、内部状態まで深掘できる状態

オブザーバビリティの獲得によって、原因特定対策検討が迅速に行えるようになる

ロギング設計

・cloud watch logs

他のAWSサービスとの連携も容易

サブスクリプションフィルター特定文字列の抽出も容易

・Firelens

AWS以外のサービスAWS外のSaaS連携することも可能

Firehoseを経由してS3やRed shiftOpenSearch Serviceにログ転送できる

Fluentdやfluent bit選択できる

fluent bitを利用する場合AWS公式提供しているコンテナイメージ使用できる

セキュリティ設計

イメージに対するセキュリティ対策

 - ソフトウェアライブラリ脆弱性は日々更新されており、作ってから時間が経ったイメージ脆弱性を含んでいる危険がある。

 - 方法

  脆弱性の有無はECRによる脆弱性スキャンOSSのtrivyによる脆弱性スキャン

継続的かつ自動的コンテナイメージスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリ場合CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャン必要になる。

cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる(スキャン自体は1日1回のみ可能

提供元が不明ベースイメージ使用は避ける

・IAMポリシーによるECRのパブリック化の禁止

 - オペレーションミスによる公開を防ぐことができる

信頼性設計

マルチAZ構成

Fargateの場合サービス内部のスケジューラが自動マルチAZ構成を取るため、こちらで何かする必要はない。

障害時切り離しと復旧

ECSはcloud watchと組み合わせることでタスク障害アプリエラーを検知できるうえに、用意されてるメトリクスをcloud watchアラームと結びつけて通知を自動化できる

ALBと結びつけることで、障害が発生したタスク自動で切り離す

リタイアという状態

AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合ECSは新しいタスクに置き換えようとするその状態のこと。

Fargateの場合アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ整合などが生じて危険

システムメンテナンス時におけるサービス停止

ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能

サービスクォータという制限

意図しない課金増加から保護するために設けられた制限

自動でクォータは引き上がらない

cloud watch メトリクスなどで監視する必要がある。

パフォーマンス設計

パフォーマンス設計で求められることは、ビジネスで求められるシステム需要を満たしつつも、技術領域進歩環境の変化に対応可能アーキテクチャを目指すこと

ビジネス上の性能要件を把握することが前提

利用者数やワークロードの特性を見極めつつ、性能目標から必要リソース量を仮決めする

FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める

既存のワークロードを模倣したベンチマークや負荷テスト実施してパフォーマンス要件を満たすかどうかを確認する

スケールアウト

サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存タスクを停止する必要原則ない。

スケールアウト時の注意

・Fargate上のECSタスク数の上限はデフォルトリージョンあたり1000までであること。

VPCIPアドレスの割当量に気をつける

ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能IPアドレスが消費されていく

スケールアウトによるIPアドレスの枯渇に注意

Application Autoscaling

Fargateで使用可能

Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う

ステップスケーリングポリシー

ステップを設けて制御する

CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意ステップに従ってタスク数を増減させる

ターゲット追跡スケーリングポリシーとは

指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針

ターゲット追跡スケーリングPermalink | 記事への反応(0) | 21:45

本のまとめ

--

この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。

1章

コンテナとは】

他のプロセスとは隔離された状態OS上にソフトウェアを実行する技術

コンテナ利用のメリット

環境依存から解放

コンテナにはアプリの稼働に必要となるランタイムライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリ依存関係をすべてコンテナ内で完結できる。

依存関係を含めたパッケージリリース単位となる

環境構築やテストに要する時間の削減

優れた再現性ポータビリティ

全ての依存関係コンテナ内で完結するため、オンプレでもクラウドでも起動する。

ステージング環境テスト済みのコンテナイメージプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテスト必要工数を削減できる。

リソース効率のアップ

サーバー仮想化では、仮想マシンレベルリソースを分離し、ゲストOS上でアプリが起動する。つまりアプリだけでなく、ゲストOSを動かすためのコンピューティングリソース必要

一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に1つのプロセスが稼働している扱いになる。

Dockerとは】

コンテナライフサイクル管理するプラットフォーム

アプリコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。

アプリソースコード + Dockerfile

↓ buildでイメージ作成

イメージ(アプリケーションと依存関係パッケージングされる。アプリライブラリOS)

shipイメージの保存

レジストリに保存

run コンテナの実行

オンプレクラウドなどで起動

Dockerfileとは】

イメージを構築するためのテキストファイル

このファイルコマンド記述することで、アプリ必要ライブラリインストールしたり、コンテナ上に環境変数を指定したりする。

1章まとめ、感想

コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンド設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。

2章

AWS提供するコンテナサービス

コントロールプレーン

コンテナ管理する機能

コントロールプレーンは2種類

ECSとEKSがある。

ECS

フルマネージドなコンテナオーケストレータ。

オーケストレーションサービスであり、コンテナの実行環境ではない。

ECSの月間稼働率99.99%であることがSLA として保証

タスク

コンテナ動作するコンポーネント

タスクは1つ以上のコンテナからなる

アプリを起動するためにはコンテナ必要

タスク定義

タスク作成するテンプレート定義JSON記述

デプロイするコンテナイメージタスクコンテナに割り当てるリソースやIAMロール、Cloud Watch Logsの出力先などを指定する。

サービス

指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサータスクを実行するネットワーク指定

クラスター

サービスタスクを実行する論理グループ

データプレーン

コンテナが実際に稼働するリソース環境

2種類ありECSとFargateがある。 Fargateに絞って書く

Fargateとは

サーバーレスコンピューティングエンジン

AWSのフルマネージドなデータプレーンとして定義されている

コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する

Fargate メリット

ホスト管理不要であること

サーバーのスケーリングパッチ適用保護管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる

Fargate デメリット

価格EC2より高い。

利用者コンテナの稼働するOSには介入できない

コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる

ECR

フルマネージドなコンテナレジストリ

コンテナイメージを保存、管理できる

コンテナが利用されているサービス

Lambda

・App Runner

Lambda

 利用者コードアップロードするだけでコードを実行できるサービス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の登場からしばらく経過し、有識者経験者は増え、確保しやすい。

システム要件確認

多数のユーザーに使ってもらう

可用性を高めるためにマルチAZ構成を取る

CI/CDパイプライン形成し、アプリリリースに対するアジティを高める

レイヤで適切なセキュリティ対策不正アクセス対策認証データの適切な管理ログ保存、踏み台経由の内部アクセス)を施したい

2章まとめ、感想

AWS提供するコンテナサービスはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理不要インフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である

3章

この章では運用設計ロギング設計セキュリティ設計信頼性設計パフォーマンス設計コスト最適化設計について述べている。

運用設計

Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計不具合修正デプロイリスク軽減のためのCI/CD設計必要である

モニタリングとは

システム内で定めた状態確認し続けることであり、その目的システムの可用性を維持するために問題発生に気づくこと

オブザーバビリティとは

システム全体を俯瞰しつつ、内部状態まで深掘できる状態

オブザーバビリティの獲得によって、原因特定対策検討が迅速に行えるようになる

ロギング設計

・cloud watch logs

他のAWSサービスとの連携も容易

サブスクリプションフィルター特定文字列の抽出も容易

・Firelens

AWS以外のサービスAWS外のSaaS連携することも可能

Firehoseを経由してS3やRed shiftOpenSearch Serviceにログ転送できる

Fluentdやfluent bit選択できる

fluent bitを利用する場合AWS公式提供しているコンテナイメージ使用できる

セキュリティ設計

イメージに対するセキュリティ対策

 - ソフトウェアライブラリ脆弱性は日々更新されており、作ってから時間が経ったイメージ脆弱性を含んでいる危険がある。

 - 方法

  脆弱性の有無はECRによる脆弱性スキャンOSSのtrivyによる脆弱性スキャン

継続的かつ自動的コンテナイメージスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリ場合CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャン必要になる。

cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる(スキャン自体は1日1回のみ可能

提供元が不明ベースイメージ使用は避ける

・IAMポリシーによるECRのパブリック化の禁止

 - オペレーションミスによる公開を防ぐことができる

信頼性設計

マルチAZ構成

Fargateの場合サービス内部のスケジューラが自動マルチAZ構成を取るため、こちらで何かする必要はない。

障害時切り離しと復旧

ECSはcloud watchと組み合わせることでタスク障害アプリエラーを検知できるうえに、用意されてるメトリクスをcloud watchアラームと結びつけて通知を自動化できる

ALBと結びつけることで、障害が発生したタスク自動で切り離す

リタイアという状態

AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合ECSは新しいタスクに置き換えようとするその状態のこと。

Fargateの場合アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ整合などが生じて危険

システムメンテナンス時におけるサービス停止

ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能

サービスクォータという制限

意図しない課金増加から保護するために設けられた制限

自動でクォータは引き上がらない

cloud watch メトリクスなどで監視する必要がある。

パフォーマンス設計

パフォーマンス設計で求められることは、ビジネスで求められるシステム需要を満たしつつも、技術領域進歩環境の変化に対応可能アーキテクチャを目指すこと

ビジネス上の性能要件を把握することが前提

利用者数やワークロードの特性を見極めつつ、性能目標から必要リソース量を仮決めする

FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める

既存のワークロードを模倣したベンチマークや負荷テスト実施してパフォーマンス要件を満たすかどうかを確認する

スケールアウト

サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存タスクを停止する必要原則ない。

スケールアウト時の注意

・Fargate上のECSタスク数の上限はデフォルトリージョンあたり1000までであること。

VPCIPアドレスの割当量に気をつける

ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能IPアドレスが消費されていく

スケールアウトによるIPアドレスの枯渇に注意

Application Autoscaling

Fargateで使用可能

Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う

ステップスケーリングポリシー

ステップを設けて制御する

CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意ステップに従ってタスク数を増減させる

ターゲット追跡スケーリングポリシーとは

指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針

ターゲット追跡スケーリングPermalink | 記事への反応(0) | 21:45

2022-01-15

奈良自動車整備工場デジタルプラットフォーマーへと舵を切る─ファーストグループの挑戦


2022年1月14日(金)奥平 等(ITジャーナリスト/コンセプト・プランナー

リスト

地方発中小企業からグローバルなデジタルプラットフォーマーへ──決して荒唐無稽な話ではない。すでにシリーズAによる資金調達を果たし、上場へ向けて確かな歩みを続ける企業がある。1960年奈良県天理市自動車整備工場として創業したファーストグループである現在天理市東京都渋谷区本社を置き、自らの事業を「グローバルカーライフテックサービス」と位置づけ、全国の自動車整備工場SaaSマーケティングサービス提供している。本稿では、地方自動車整備工場デジタルトランスフォーメーション(DX)に挑む同社のビジョンと打ち手に迫ってみたい。

オートアフターマーケット市場ポテンシャルを信じた

 自動車販売の「オートアフターマーケット」と聞くと、脇役的なイメージがあるかもしれない。だが実のところ、各種の市場調査データからファーストグループが算出した市場規模は下記のとおりで、自動車整備市場だけで実に5兆5000億円に達している(図1)。また、国内外300社以上が出展する国際展示会が開催されるなど、グローバルでも確固たる市場が築かれている。

図1:オートアフターマーケット市場規模(出典:ファーストグループ自動車年鑑2019、自販連、自軽協統計資料平成30年整備振興会整備白書を基に調査

 一方、矢野経済研究所2021年3月に発表した調査によると、2020年国内自動車アフターマーケット市場規模は19兆14億円。ここには「中古車(小売、輸出、買い取り、オークション)」「自動車賃貸リースレンタカーカーシェアリング)」「部品・用品(カー用品、補修部品リサイクル部品)」「整備(整備、整備機器)」「その他関連サービス自動車保険ロードサービス)」の5事業が含まれている。

 前年比1.8%減と2年連続で微減しているものの、2019年10月消費税増税2020年2月顕在化した新型コロナウイルス感染症(COVID-19)の感染拡大をもろに受けて新車販売台数が前年比11.5%減(日本自動車販売協会連合会の発表)と大幅に落ち込んだことと比較すると、マイナス幅は小さいと言える。

 ファーストグループ 代表取締役社長の藤堂高明氏(写真1)は、「実はオートアフターマーケット、とりわけ自動車整備市場リーマンショックギリシャショック、そして今回のコロナ禍においても大きな影響を受けなかった不況に強い産業なのです」として、その理由を次のように話す。

写真2:ファーストグループ 代表取締役社長の藤堂高明氏(出典:ファーストグループ

 「理由は大きく3つあります。最も大きいのが、道路運送車両法に定められた車検自動車継続検査)があること。自動車の所有者は半ば強制的に整備工場に足を運ぶこととなります。次に、定期点検オイル交換などに代表される定期接触必須ビジネスであること。そして、サービス供給側と利用側の情報格差が大きく、供給側主導のビジネスとなっていることです」

 こうして、オートアフターマーケット不況に強いビジネスではあるが、年々飛躍的な成長を遂げているかというと、残念ながらそうではない。その背景に、従業員が少ない小規模な工場地方分散しているというこの市場形態がある。ディーラー系を除いた小規模な自動車整備工場は全国に約5万7000も事業所があるが、メカニックエンジニア経営後継者の不足などに悩まされ、ここ数年は減少傾向に転じているという。

 また、ガソリンスタンド付加価値提供を目指したサービスステーションにシフトしていること、整備入庫を包含したビジネスモデルへの再編を狙うメーカーディーラーをはじめとする異業種の囲い込みなど、厳しい外的環境にもさらされている。

 それでも、藤堂氏はこの市場ポテンシャルに注目する。「全国に約5万7000事業所。この数って、実はコンビニエンスストアの出店数に匹敵します。さらに、ディーラー系を含めると9万事業所を超えるわけですからコンビニが出店のために費やしてきたコストや労力を考えれば、こんな魅力的な業界は他にないのではないでしょうか」(藤堂氏)

 「同時に、これは私の試算にすぎませんが、日本8000万台あると言われている自動車登録台数からの換算で、その資産価値総額は約200兆円に上ります。商圏を2~5kmに絞り、1事業所あたり1000人の顧客がいたとして、1台あたり100万円としても10億円規模の資産を預かるビジネスとなるわけです。自社の課題を克服して、ラストワンマイルの発想で、いわゆる自動車整備工場から脱却して、1人ひとりのカーライフを支えるビジネスパートナーとしての地位を担えれば、大きな飛躍があると確信しています」(同氏)

バリューチェーンの創出に注力し、年商を30倍に

 ファーストグループが掲げるミッションは「カーライフ革命で人々に喜びと感動を」、企業ビジョンは「GLOBAL No.1 CAR LIFE TECH COMPANY─世界の人々から最も必要とされるカーライフカンパニーへ─」である

 この壮大なミッションビジョンに辿り着くまでに、ファーストグループは実際にどのような手法プロセスで自社の変革を進めてきたのであろうか。藤堂氏は、同社が決して特別存在ではなかったことを物語エピソードとして、「父から引き継いだ段階で毎年7000万円の赤字を垂れ流していた企業だった」と振り返る。その歴史と変遷をたどってみよう。

 2007年、先代社長他界きっかけにMBO(Management Buyout)により事業を取得、2代目を継承した藤堂氏は先頭に立ってマーケティング指向経営管理手法企業再生に着手、翌年には黒字転換を達成する。成長への第1ステップは、自らが培ったその再生モデル武器に、「同様の課題に直面している全国の自動車整備工場を元気にする」(同氏)ことにあった。

 それは、いわゆる買収・再生モデルの横展開だが、実際にはそこにも紆余曲折があり、2つの段階を踏まえて、進化と深化を図っていった。①資産負債のすべてを原則譲り受けるM&Aモデル、②事業のみ譲渡を受け、土地建物賃貸借して継続させる賃貸モデル。この2段階のプロセス実践した14年間で、ファーストグループ年商1.5億円を約30倍の50億円に拡大したという。

 具体的な打ち手はバリューチェーンの創出だ。ファーストグループが特化しようとするカーライフにまつわるマーケットは、①車検をはじめとするメンテナンス領域、②更新が見込まれ保険領域、③カーライフのサイクルを最適化する車両販売領域、④万が一の事故に備えた各種サービス領域に大別される(図2)。

図2:カーライフマーケットにおけるバリューチェーン(出典:ファーストグループ

拡大画像表示

 しかしながら、これまでの自動車整備工場はその一端となるメンテナンス領域のみで、事業の維持に努めてきた。つまり顧客とのライフタイムバリューを最大化するチャンスを逃してきたのである。そこで、藤堂氏は、同社が買収・再生を手がけてきた自動車整備工場に対し、徹底的にバリューチェーンの創出に注力した。

 藤堂氏は、カーライフにまつわるサービスが多岐にわたることを、同氏のシミュレーションを示して力説する。「18歳で初めて免許を取得した若者が生涯にわたってクルマにかける費用は最低でも1600万円。高級車に乗られる方はその何倍ものコストを費やすことになるはずです」(同氏)

 藤堂氏によると、これまでの自動車整備工場車検や修理に依存した事業形態から抜け出すことができず、カーライフの起点とも言えるクルマ販売にはあまり積極的ではなく、むしろ苦手としていました。

 「ところが、その壁をクリアさえすれば、バリューチェーン簡単に創出できるのです。車両販売を手がけて成果を上げれば、自らのメンテナンス領域仕事も増えて安定します。さら販売時に必要となる保険やさまざまなサービス包含して提供する窓口にもなれば、さまざまな異業種の人たちとの接点が生まれエコシステム形成されます。つまりバリューチェーンによって、LTVの最大化と事業ポートフォリオ変革を同時に成し遂げられるというわけです」(藤堂氏)

 ファーストグループ自身が先陣を切って、このバリューチェーン創造エコシステム構築に取り組んだ。すると、瞬く間に車検の年間受注件数が急増し、奈良県内では断トツの年間1万件を超えるまでになったという。メーカーディーラーが何十年もかかって達成した件数を、ごく短期間で凌駕するまでになったのだ。年商は1.5億円から現在では実に30倍の50億円に達している。

2022-01-14

anond:20220114134743

俺、今地方の自社サービス開発企業に勤めててその中ではテックリード的な立場で、

Saasシステム設計フェーズから1から構築したこともあるし、

他にもレガシー目なサービスDDDクリーンアーキテクチャ思想を導入したりTDDの構築と運用へあたっての体制構築や教育を主導したりとか

メンバースキルに偏りがある状態でも品質維持するための体制をなんとか作ったりとかしてんすよ

面接官「うわ。こいつ、実績何もなさそう。面接官受けしそうな言葉ならべてるだけやな・・これ。この人は”面接が”上手い人なんだな。。」

Webエンジニアだけど転職活動うまく行かーん

28Webエンジニア。今の年収は400万くらい。

地方の自社サービス開発企業に勤めててその中ではテックリード的な立場

Saasシステム設計フェーズから1から構築したこともあるし、

他にもレガシー目なサービスDDDクリーンアーキテクチャ思想を導入したりTDDの構築と運用へあたっての体制構築や教育を主導したりとか

メンバースキルに偏りがある状態でも品質維持するための体制をなんとか作ったりとか

小さい企業ながら割と経験詰めたし今なら転職とか余裕だよなーって思ったがなかなかうまくいかない。

今のところ3社受けて全部1次面接落ち。受けたのは転職サイトのトップページに一番大きく載ってるような人気企業から倍率は結構高い気はする。

今のところフルリモートで初年度年収550万~600万くらいを目指してる。多分500万くらいまで水準下げれば求人めっちゃ増えるし余裕な気はする。



あっちからスカウトが来て、競合ではないけど似たようなサービスを俺も構築した経験があったか

御社製品の○○機能(リリースされたらプレスリリース打つくらいの機能)と似たようなもの営業にほしいと言われてから2日後にはテストカバレッジ100%状態リリースまで持っていきましたとか、

当時はリソース足りず自分一人でほぼ全部対応してたけど爆速リリースサイクル回して1年で機能数的にも競合製品に負けないくらいまで成長させましたとかこれ以上ないくらアピールしたよ。

それで受けたのに1次落ちなのはちょっと凹んだ。

なーにが行けなかったんだろう。やっぱコミュ障なのが影響してんのかなぁ。「えーっとまあ」とか「なんか」「えーーそうですね…」みたいなのが多いのは自覚してる。

フルリモート給与高水準だと倍率高いから、もしかしたら20人中の1人や2人採用で第3位だったとかかもしれない。

何をどう変えたらいかなぁ。

転職指南書に書いているようなHP企業理念読んで面接官が喜びそうなことを事前に作文して頭に叩き込んでおくみたいなことはやりたくないんだよね。

会社じゃ面接官する側だけどポートフォリオとか職務経歴しょぼいのに口だけ凄いこといってると

「ああ、この人面接官喜ばすための言葉を事前に作文してきたんだろうなーーー」「この人は”面接が”上手い人なんだな」とかやっぱ内心思っちゃう

まあ応募して落とされて凹んでまた応募してを繰り返すしかないのかな。

超人気の高望企業に3社落とされるだけでちょっと凹むのに就活生は凄いね。。

2022-01-04

疲れてるんご

sasssaasが逆に見えた。

aかsだけどぜんぜんちげーじゃん

2021-12-25

SaaS企業説明がよく分からない

どことは言わないけれど最近AWS障害が起きるとサービスが利用できません!みたいなことを書く企業多いよね

でもそれちがくない?AWSサービスを受けているのはSaaS企業であってSaaS企業提供するサービスを使うユーザじゃないよね?

ユーザに対してサービス提供出来ないのはSaaS企業責任なのだからサーバ障害等で利用できない、現在復旧方法などを検討中ならわかるんだ

だけど、AWS障害から何も出来ません!復旧をお待ちください!みたいなのを見ると違うでしょ?

課題解決をするんだ!みたいに意識高いことを言っているが、サービス継続出来ないのをクラウドのせいだからしょうがない!っていうのちがくない?

それでサービスがつけないなら課題解決出来てないよね?違う課題が発生してるよね?

意識高いこと言ってる割りにAWSのしょうがいが~っていうプレスリリースを出す会社よくわからん

2021-12-14

自営業はじめてから5年経つが辛い

資金調達とかSaaSとかベンチャーとかスタートアップとかベンチャーキャピタルとか、そういうキラキラとは別な零細自営業について語ります

特に戦略とか持たずに、のんべんだらりと会社をやってきたおっさん独り言です。同時期に会社を急速に伸ばした人を見ると、自分のだめさ加減が露呈して辛い。



2017年

転職直後に、家族うつ病に。辛い。

家族ケアをしながらできる働き方はないか模索したところ、「起業、、、ありかも」と思い立ち、友人知から仕事を集めたらなんとかなりそうなことが判明。

よっしゃ、辞めるぞ、ということで、転職から1年未満で退職退職時は、同じ会社の人に結構微妙対応をされる。まあ、そりゃ実績も出さずに1年未満で辞める人にかける言葉もないよな。辛い。

退職直後は、友人知から祝儀仕事が来て結構ハウハとなるが、その後、ご祝儀案件がすぐ蒸発。辛い。

あなたに任せるよりも、安いインターンに任せることにしました」という屈辱的なこともたくさん言われる。辛い。

友人と共同で受けた案件、お客さん会社社長パワハラ気味で、やった作業簡単にひっくりかえすx3を食らう。辛い。

この時点でサラリーマン仕事6ヶ月(給与)+自営業6ヶ月(売上)=800-900万円



2018年

友人から仕事で食いつなぎつつ、クラウドソーシング。辛い。1文字1円のライター業とかやる。格安SIMがどうとか、転職がどうとか、そんな記事を量産する。

格安SIM記事なんて、定められた構成に従い、機械的に書くだけ。書く機械。人ではない。そして、1円ライターでも「もっとちゃんと書け」と怒られる。辛い。

それ以外にもクラウドソーシングのよくわからない案件をこなす光通信系の会社の人からプロだと思って頼んだら全然だめですね」と言われる。辛い。

新卒入社した会社結構有名企業だったので、「あー、あんな有名な会社に勤めていたのに、そのまま勤めていれば年収もずいぶん高かっただろうに、いまは1円ライターやっているのかー」と自分客観視すると、辛い。

単価高いITエンジニアがうらやましくて仕方ない。ああ、どうしてプログラミングやらなかったのだろうと人生を後悔する。辛い。

元同僚の会社営業代行などしてしのぐ。営業なんて大嫌いなのに。辛い。

自営業12ヶ月(売上)=700-800万円



2019年

クラウドソーシングの受注案件から強引に営業したら、月額30万円くらいの安定収入になる。嬉しい!

営業代行仕事好調結構売上が伸びる。ただ、営業対応出張が多いのと、売上にならない案件フォローとかがかなり面倒。フォロー遅れると怒られる。辛い。

家族うつ病が再び悪化仕事したいのに、やる気もあるのに、張り付いていないといけなくて仕事できない日が増える。辛い。

Switch買ったら、昔のゲームやるのが面白すぎて仕事が進まない。でも止められない。作業遅れ多発。辛い。

また別な継続案件口コミで受注するも、親会社が推奨する会社リプレースされてしまい、一瞬で案件なくなる。辛い。

業界違いの案件を受けたら、「メールChatworkで連絡してください」としたにも関わらず、毎日電話くる。そのうえ、レスが悪いと怒られて案件終わる。辛い。

自営業12ヶ月(売上)=1000-1100万円



2020年

子供生まれる。しか双子!嬉しい!でも、お金なくて色々申し訳ない。旅行するときに、泊まりたいホテルでなくて、安いホテルから順に調べないといけない。辛い。

行きたいタイミング旅行に行けず、カードマイルを使って特典航空券が空いているタイミングを選ばないといけない。辛い。

元同僚の営業代行していた会社から、いいがかりをつけられて売上が減少。新卒入社したときは、楽しく酒を飲み交わしたことを思い出す。一緒に仕事しなければ友情は続いたのだろうに悲しい。紙の契約書がないって辛い。

売上どうしようと思い悩んでいたところ、交通事故あい、そのさなかにクラウドソーシング経由で営業した安定収入案件を失注。辛い。

別な友人経由で仕事をもらうが、「すみませんが、成果でないですね」と言われ、2ヶ月で切られる。辛い。

コロナで友人知人と会えず、精神的なバランスも崩れる。精神的なバランスが崩れても、息子たちのおむつ替えもミルクも待ってくれない。辛い。

自営業12ヶ月(売上)=700-800万円



2021年

知人からの紹介で再び別の案件を受注。月30万円くらい。嬉しい。

他の案件ほとんどなくなり、辛い。業績低迷を理由コロナ融資受ける。ある意味コロナ恩恵を受ける。うちみたいな会社お金貸してくれるなんて最高。大好き日本国

から、「稼ぎが悪い、お金がないか子供の服を1着買うのも悩む、友人は家を買っているのにうちは車すら買えない、ちゃんと考えずに会社経営しているだろ、融資返せるのか」と言われる。辛い。

さすがに食っていけないので、ほぼフルリモートサラリーマンも再開する。成功できずサラリーマン都落ちした気持ちになる。恥ずかしい。辛い。

ただ、普通に考えて自分会社仕事しながら、サラリーマンやるのは普通に考えて無理がある。溺れながら時々顔を出して仕事をしている感を装っているような感じ。情けないし辛い。

自営業12ヶ月(売上)+サラリーマン4ヶ月=700-800万円



2022年予定

来年は、サラリーマン年収が1000-1100万円+自営業が600万円。結局自営業金額はしょぼいので、ダメ社長だ。辛い。

金額全体が増えたのはうれしいが、仕事コントロールできず溺れている。自分会社サラリーマン仕事完璧にできていない。だましている感が強い。辛い。

大学時代の同期は、キラキラベンチャーでCxOして資産数十億円築いたり、コンサル上り詰めたり、起業して成功したり、外資系部長職で年収3000-4000万くらいのポジションについている。羨ましくて仕方ない。辛い。

2021-11-30

[]株式会社はてな2022年7月期1Q決算分析

さて、1Q決算が発表されたので見ていきましょう。

今回のソース

https://ssl4.eir-parts.net/doc/3930/tdnet/2054543/00.pdf

前年同期比で見ていきます

単位100万円です。


前年同期比比較

決算売上高営業経常益最終益
20年8-10570303019
21年8-10733697149
変化28.6%230%240%260%

めちゃくちゃ伸びてます!!!!!!!!!!!

はてな勝利!!!!!!!!!!!!!!!!!!!!!!!!!!!

とはなりません。

残念ながら。

当たり前ですが去年はコロナ直撃していますので異常値が出ています

比較としては使えません。ですのでその前と比較してみます


2年前同期比比較

決算売上高営業経常益最終益
19年8-10617727551
21年8-10733697149
変化15.9%-4%-5%-4%

おやおや。

売上は伸びています利益が減っていますね。

何故利益が圧迫されているのでしょうか。

決算短信の言い訳を見てみましょう。

中長期的な企業価値の向上への取り組みの結果、営業費用売上原価販売費及び一般管理費の合計)については

663,913千円(前年同期は539,799千円)となりました。主な増加要因は、広告レベニューシェアに伴う収益配分原価

が増加したこと、主要3サービス拡張事業創出のため、人材投資積極的に行ったことによります人材への経営

資源の配分は、当社が将来にわたり競争優位性を確保するために、収益基盤の確立に向けた成長戦略投資として位

置づけておりますサービスの高成長を中長期的に実現していくために、エンジニアを中心とした更なる人材投資

ついて、フレキシブル対応をしてまいります


要するに、広告原価とエンジニア雇用による人件費が上がったことによって、利益が圧迫されたようです。

では、次は雇ったエンジニアで何をしているのか、事業ごとの売上を見ていきましょう。

四半期ごとの事業別売上は今回はじめて登場したので、前年比較はできません。

コンテンツプラットフォームはてなブログ、はてなブックマーク等)

広告SaaS
73.749.2
122.9

コンテンツマーケティングはてなブログmedia)

広告SaaS
62.6112.4
175.1

テクノロジーソリューションマカレル、GigaViewer等)

開発保守SaaS
246.5188.5
453

見てわかるように現在はてなテクノロジーソリューションが主力事業です。

はてブの売上なんてものコンテンツプラットフォーム広告の一部だと考えられますので、

せいぜい数千万円と言ったところです。

はてブ機能追加されない理由がよく分かることでしょう。

さて、主力事業テクノロジーソリューションをもうちょい見てみましょう。

通期決算資料

https://ssl4.eir-parts.net/doc/3930/ir_material_for_fiscal_ym/106320/00.pdf

テクノロジーソリューション

サーバー監視マカレル

ジャンプ+のマンガ投稿サービスマンガノ」

マンガビューワーのGigaViewer

くらげバンチにストア機能

カクヨム

魔法のiらんど企画開発運用支援

21年7月頃には人員が167人

開発がどのぐらいかわかりませんが、

ほとんどがテクノロジーソリューションに割り振られてるんじゃないかと思います

伸びしろのないコンテンツプラットフォームに割り振る意味はないのでこれは正しい選択だと思います

伸びしろのなさは前回のを見てください。

はてなの今後は、出版DXでどれだけ存在感を発揮できるかにかかっているんじゃないでしょうか。

ちなみに決算を受けて時間外取引価格

現在-9.52%下落です。ご愁傷さまです。

2021-11-24

死にたい

 死にたくて死にたくてしかたない。

 生きる希望をみつけたくて、ヒルティアランシューペンハウエル幸福論を読んだ。そこには理屈が書いてあった。しか自分死にたいのは理屈のせいではないと思う。もちろん病院にも言っている。メンタル系の病院で大量の薬を処方されている。リモートワークで仕事もしている。それなりの給料ももらっていた。けれど健康診断で異常な結果が出て、精密検査を受けた結果、高額な手術を受けて入院しなければならないことが明らかになってきた。

 手術して2週間入院すると、その間の日割分の月給の収入を失うことも踏まえると、恐ろしく高額だと思う。もちろんいままでちゃんと働いてきていてついこないだまではまとまった貯金があった。しかし老後2000万円必要になることを考えると、資産運用するしかないと思って投資をはじめた。そのとたんにコロナショックがやってきたり、急にSaaS銘柄があがらなくなって海運株と半導体株の時代がきたかと思うと、FRBパウエル議長再任で金利が爆上げしてまたすべてが飛んでいった。そう気がついたら、お金がぜんぜんなくなっていた。そして体調不良のためスキルを発揮できず、収入も約半分ぐらいに減らされてしまった。それぞれは小さなことだった。けれど、ひとつひとつと増えていく重しによって、もともと希死念慮が強かった俺のメンタルは、本当の限界をむかえつつあるような気がしている。

 友達もいない。彼女もいない。食欲もない。飯は一日一度の冷凍食品タバコは吸わないが、酒は500mlで170円の安酒を飲む。ストロングゼロではない。もっとアルコールの低いやつだ。オタクみたいな顏してるかもしれないがオタク知識さえなく、チー牛みたいな顏してるがチー牛を頼む金もない。趣味もない。何をやっても、虚しくなる。疲れてしまう。そして死にたくなる。こんな人生になることを、若いうちに気づいていればよかった。気づいていたのかもしれない。気づいたとしても、できることはなにもなかったのかもしれない。

2021-11-23

Web業界中年エンジニアです。法人向けSaas開発の魅力を教えて。

転職先を探していたら法人向けSass開発の求人が多くて驚いた。

業界知識もないしそんなに興味が持てない。

例えばバックオフィスSassモダン機能提供して利用者は便利なのかな?。そういうところにやりがいを感じる?それともやりがいとか求めるエンジニアって少ないんだろうか。

実際に法人向けSaas開発をしてる人で

「こういうところが開発してて面白いぞ」とか

働いてみて良い意味で感じたギャップとかあったら教えてください。

2021-11-18

変化を認めない部下が多くて死にそう

20年も前に社員自力で開発した業務システムを今も使用し続けている我が部署

開発者退職済みで謎に包まれシステムは様々に不具合が生じているが誰も修正できない。

サーバクライアント型でさえなく、一人一人の業務PCエリアごとに保存されて、バックアップMOで月一手動とかいう、マジで何時の時代のやり方だよ。

業務の至るところにリスクありすぎる。どう考えても現システムから脱出しなければ。

なのに歴代マネージャーは「一応動いているから」と新システムの選定や移行を先送り続けてきた。

そして私がマネージャーとなった。

この業務顧客管理して適当な帳票を出力するだけで、自社専用のシステムなんざ必要ものじゃない。

出来合いのシステムを買うか、SaaSでもした方がマシ。

というか、この界隈では他社もよく使う有名なサービスがあるので、それでよいのだ。

早速新システム移行へと踏み出したが、実際に業務システムを触る社員からは大反対にあっている。

この部署、実は、公務員のように前例を崇めすぎていたり、自ら発案や改善ができないとか、変化に耐えられないという奴で、尚且、声や態度だけはデカいという性質のやつを寄せ集めた部署なのだ

こんなに話し通じねーの初めてだわ。似たようなの寄せ集めてるのもないわ、相乗効果制御できん。とりあえず半分くらい辞めて濃度下げてくんねーかな。

2021-11-14

anond:20211114132021

Salesforceに限らずSaaSは導入後が肝心だよな。

Notionんあかも導入するだけ導入して何も書いてない会社だってあるし。

ビジネスサービス系のCMにおける上司無能演出

ビジネス系のサービス最近増えてきたSaas系のCMなんかの演出で、

部下らしき人物が何も知らない上司社長などのマネジメント層対して新しいサービスを紹介して目からウロコみたいな展開が半ばテンプレ化している感じなのだが、

これって今でもターゲットに刺さるメッセージとして通用しているのだろうか。

会社や自組織課題抽出して、その解決策を提示し実行させるのがマネジメントポジション重要仕事なのだとしたら、

上記CM目からウロコ落としてる人たちはいったい何の仕事毎日しているんだということになると思うのだが、

こんな演出が量産されているということは、まだまだ世の中にはこんなマネジメント層が蔓延っている会社が多いということなのだろうかね。

こんな上司ばっかりだったらとてもじゃないがこれからビジネス環境太刀打ちできるような企業力をつけることなんかできないと思うけど、実際どうなんだろう。

実際多数派だったら日本相当やばくないか。。

自分の周りのマネジメント層はわりとそのへんのキャッチアップが早くて自ら引っ張っていくような人たちが多いので、

そんな呑気な世界があるのかどうか知りたいと思ってここに書いてみました。

2021-10-26

anond:20211026190158

ExchangeサーバーSaaSみたいに提供するBlackberry Exchange Serverってのが10年前は「オサレ」だったんだよな

すべてがクラウド化された今じゃ考えられんけどなw

2021-09-24

anond:20210924180434

10年前なら重宝がられたかもしれないが、2021年ではVBA書いたら負けなとこある

社内にdocker演算サーバ立てるかSaaSでBIサービス契約すれば本気だと思われる

2021-09-22

山本拓高市氏の元旦那)の進次郎批判よろしくない

山本拓議員小泉進次郎への公開質問状話題になってる。

http://yamamototaku.jp/article/20210921/

山本議員の「元妻を守るために」という物言いが(「離別した夫にも擁護されるなんて、やっぱり高市さんは人格的に素晴らしいんですね!」みたいな感じで)高市支持者に大ウケ。さら自民支持者右派だけじゃなく、河野太郎小泉進次郞を叩きたいやつら、再エネを批判したいやつらにも大人気になっている。バズりまくりだ。よかったよかった。

しかし、肝心の公開質問の内容がまずいというか、やばい

IT関連消費電力は2050年には2016年の41TWh/年の約4,000倍の176,200 TWh/年になるとの予測が、国立研究開発法人科学技術振興機構低炭素社会戦略センターによって発表されています

現在よりも省エネルギーの進展があったとしても、IT 関連消費電力は莫大に膨れ上がることが予想されます。2050 年にそれらを再生可能エネルギーでまかなうための具体的計画を、環境大臣としてお示しください。

これ読んで、増田諸氏はどう感じるだろうか。少なから増田が「『176,200TWh/年』というのがどれぐらいかからないけど、ITの進展で電力需要がすごい増えるんだな、それは再エネだけじゃ到底まかなえないんだろうな、小泉進次郎はそういう現実的想定をしないで、夢みたいな再エネ推進を言ってやがるんだな」と思うんじゃなかろうか。でも、そうじゃない。

「176,200TWh/年」というのは、今の日本全体の年間発電電力量の180倍、世界全体の発電電力量の7倍だ。そんなもん再エネどころか原発だろうが火発だろうが絶対充当できるわけがない。もし小泉進次郎環境省から「なるほど、再生可能エネルギーでまかなうことが不可能だというなら、2050年にそれらを原子力化石燃料エネルギーでまかなうための具体的計画を、対案としてお示しください」と反論されたら一発で撃沈だ。なんなんだこの数字? というわけで引用元PDFを読む。vol.1からvol.3まである

情報化社会の進展がエネルギー消費に与える影響(Vol.1)

IT 機器の消費電力の現状と将来予測

https://www.jst.go.jp/lcs/pdf/fy2018-pp-15.pdf

情報化社会の進展に伴って、従来の予想を超える膨大なデータが取り扱われるようになり、この傾向は今後も拡大すると考えられる。これに伴い、エネルギー消費がどのような影響を受けるかを 2050 年までを視野に入れ、調査ヒアリングなどにより検討した。その結果、世界情報量IP トラフィック)は 2030 年には現在の 30 倍以上、2050 年には 4,000 倍に達すると予想され、現在技術のまま、まったく省エネルギー対策がなされないと仮定すると、情報関連だけで 2030年には年間 42PWh、2050 年には 5,000PWh と、現在世界の消費電力の約 24PWh を大きく上回る予測となった。すなわち、技術進歩がなければ情報関連だけで世界の全てのエネルギーを消費してもまだ不足するという事態になりうる。

現在日本の年間の電力消費量が約 980TWhであるから現在技術でまったく省エネルギー対策がなされないと仮定すると、2030年には年間使用電力量の倍近い電力を IT 関連機器だけで消費する予測となる。世界についても、現在世界の消費電力が約 24,000TWh であるから、やはり現在の2倍程度の電力を IT 関連機器が消費する予測となる。また、2050 年の電力消費量は、現在比較して日本世界ともに約200倍という極端な数字となり、情報関連だけで全てのエネルギーを消費してもまだ不足するという状況になりうる。この情報量の爆発に対しての対策必要なことは明らかである

まり「もし現時点から全く技術の進展がなければ、将来はIT関連機器だけで世界中のエネルギーを全部食い潰しちゃうぞ〜」という、極端なシナリオにもとづく極端な数字なのだ。そして、Vol.1(IT関連機器編)、Vol.2(データセンター編)、Vol.3(ネットワーク編)と分野別に分けて、こうした消費電力増大の問題技術進歩でどう抑えていくか、という議論がされている。IT中心に増大するエネルギー需要に対して、どういうエネルギーミックスで応需していくか、みたいな話は全くしていないし、それどころか低炭素エネルギーへの流れが世界的に進んでいるから「電力供給が大幅に増大することは期待しがたい」とはっきり言っている。電力供給の増大に期待できないということは話の前提で、その中でのやりくりについて書いているのだ。

情報化社会の進展がエネルギー消費に与える影響(Vol.2)

データセンター消費エネルギーの現状と将来予測および技術課題

https://www.jst.go.jp/lcs/pdf/fy2020-pp-03.pdf

 データセンターIaaSSaaS、MaaS などの新たなクラウドサービスの進展に伴い今後も膨大な計算負荷が発生すると考えられる。また全世界的な COVID-19 の蔓延にともなう仕事学習形態リモート化はそれに拍車をかけるものと思われる。さら医療画像診断やセキュリティの顔認識なども膨大な計算量の発生が予測される。

 これらの状況を考えると従来以上にデータセンターにおける計算負荷が上昇しそうである一方で、供給電力には限りがある。また、現在世界中で急速に低炭素エネルギーに向けてエネルギーポートフォリオ見直しが進められていて、供給電力の大幅な増大は期待しがたい

 低炭素社会へ歩を進めつつ、社会必要とされているサービス提供するためにはデータセンター省エネルギー化を進める必要がある。本提案書では 2030、2050 年も見据えて現状技術で固定された場合の電力需要計算した。 

(ちなみに具体的提案CPUGPUを中心とした要素部品類の集積度向上、液浸、ヒートポンプなどの冷却方法の工夫、必要とき以外は動作しない(スマート化)…などなどの提案で、それに対する研究支援をせよ、と言っている。割と普通だね)

この提案書の報告主体は「国立研究開発法人科学技術振興機構 低炭素社会戦略センター」なんだけど、ようするにこの提案書は、山本拓議員引用している文脈とは真逆の論旨のことを言ってるのだ。「これだけ電力が足りなくなるから、再エネを推進してはダメだ」ではなく、「技術進歩がなければこんな非現実的シナリオになってしまうから、それを避けるために、IT分野全体で電力消費を減らす努力研究支援をしよう」という内容なのである

山本議員公開質問ではこういう文脈無視して、一部の記述を都合よく切り取って、意図的に「再エネではこの電力需要を賄えない、再エネを推進しない現実的計画を立てるべきだ(立てることが可能だ)」みたいな誤解を招く表現をしてるように見えて、大変よろしくない。山本議員エネルギー通だそうだから、「176,200TWh/年」という数字が全く非現実的な想定であることは本人も理解しているはずだ。そもそも公開質問では、この数字引用した部分のすぐ上に

一般電気事業者 10 社の 2019 年度の火力発電量は約 4,814 億 kWh/年です。

という記述もあるのだ。約 4,814 億 kWh/年 = 481400000000 kWh/年 = 481 TWh/年 である東日本大震災以後、国内発電量の70%以上を担う火発を全部ひっくるめても480TWhでしかないことを山本議員承知していながら、その直後には「IT 関連消費電力は 2050 年には (略)176,200 TWh/年になるとの予測が、国立研究開発法人科学技術振興機構低炭素社会戦略センターによって発表されています」「現在よりも省エネルギーの進展があったとしても、IT 関連消費電力は莫大に膨れ上がることが予想されます。2050 年にそれらを再生可能エネルギーでまかなうための具体的計画を、環境大臣としてお示しください」という書き方をしている。こういうのは誠実な議論ではない。

anond:20210922091208

建てられるし、維持費も安い(ドメインが一番高そう)だし、いちばん大変なのはインフラの設定だと思う。

けど今そこまでして頑張っても得られるものが少ないんじゃね。

普通にSaaS使って、必要に応じて周辺知識付けていったほうがよい。

2021-09-21

anond:20210921091438

サーバーレスエンジニア用語なので混乱させてしまたか

帳票専門のSaaSといったほうがよかったな

2021-09-06

SaaS (Sex as a Service)のお店行ってもええか?

2021-08-14

anond:20210814113815

クラウドがあって

SaaSが充実してて

そしてプログラムが書ければ

ソフトウェアは何かしら作れる

2021-07-17

SaaS(Sex as a Service)のお店行ってもええか??

ログイン ユーザー登録
ようこそ ゲスト さん