  |
はてなキーワード: AWSとは
https://note.com/syam_grit/n/n839693f4c194
noteに書くのも面倒なんでコッチで。
フリーランスって、基本的には「今ある技術と経験を売る」働き方で、育成してもらう場所ではない。足りない部分は仕事外で補う前提だと思う。
AWS資格を並べるのもいいけど、実際にAWSで何を作ったのか、どんな案件を一人で回せるのかの方が重要。もしDump系教材の暗記ではなく本当に理解して取った資格なら、まずAWS案件で実績を作ればいい。
基本情報にも苦戦している段階で「経験がある」「年収2000万を目指す」と言われても、かなり距離があるように見える。そもそもフリーランスの売上2000万と会社員の年収2000万は同じじゃない。
社員は100人ちょっといる。全員SEとかプログラマーとか、そういう肩書きになっている。
入社して最初に驚いたのは、技術の話がまったく通じないことだった。
Vim、Emacsを誰も知らない。使えないという意味ではなく、単語を知らない。
GitHubもほぼ誰も知らない。Linuxは何人か知っていたけど「Windowsじゃないやつ」くらいの認識だった。SSH、grep、cron、Docker、JSON、正規表現あたりもほぼ全滅。
昼休みに「家では何使ってるんですか」と聞いたら、「家でパソコン使うの？」と逆に聞かれた。
この前、雑談でRTX 5070の話をしたら、
「それ車？」
と聞かれた。
冗談だと思ったけど、本気だった。
最初は、仕事と趣味をきっちり分けている人たちなんだろうと思っていた。
でも仕事もひどかった。
「最新版」
「最新版2」
「最新版_最終」
「最新版_最終2」
デバッガを使っている人も見たことがない。エラーが出るとprintfを大量に入れて確認している。
C++を何年もやっていることになっている人に「コンパイル通りました？」と聞いたら、「コンパイルって何？」と言われた。
会社案内には「基本情報技術者96名」「応用情報技術者41名」「AWS認定32名」みたいなことが書かれている。
でも実際に聞いてみると、資格を持っている人が一人も見つからない。
AWS認定を持っていることになっている人にAWSのことを聞いたら、「それ何？」と言われた。
総務に資格証のコピーを見せてもらおうとしたら、そんなものは保管していないと言われた。
「これは本人申告ですか？」と聞いたら、
「いや、昔からこうなってる」
と言われた。
しかも自分も、入社した時点で持っていない資格を3つ持っていることになっていた。
訂正してほしいと言ったら、
と言われた。
スキルシートも同じだった。
Excelでデータ入力をしていた人がVBA経験5年になっている。
Windowsのセットアップをしていた人がWindows Server構築経験4年になっている。
ブラウザで社内システムを使っていただけの人がWebシステム運用経験7年になっている。
本人たちも普通に知っている。
「俺、今度は何ができることになってる？」
と営業に聞いて笑っていた。
毎日、Excelの数字を別のExcelに手入力している部署がある。
ミスがあると紙の修正票を作って、また別の人がExcelを直す。
聞いたら、この作業だけで30人くらいいる。
一番怖かったのは、その入力先のExcelが何に使われているのか誰も知らなかったこと。
調べたら、昔は別のシステムに取り込んでいたらしい。
実際には前月のExcelをコピーして数字を少し変えているだけ、という仕事もかなりある。
システム障害件数とか問い合わせ件数とか平均復旧時間とか、もっともらしい数字が並んだ月次報告書もある。
元データはない。
担当者に聞いたら、
「前月と同じだと怒られるから少し変えてる」
と言われた。
受領したPDFを共有フォルダに保存して、「確認済み」とExcelに入力する。
そのExcelをまた別の部署が集計してPowerPointにする。
髪を何か月も切っていないような人、靴が壊れている人、毎日ほぼ同じ服の人、シャツがずっと汚れている人がかなり多い。
でも比較的ちゃんとしている人に「いつも服きれいですね」と言ったら、
と言われた。
別の人は、朝着る服を親が出していると言っていた。
50歳で親に美容院に連れて行ってもらっているらしい。
そういう人が何人もいた。
家にPCがあって、趣味で少しプログラムを書いて、GitHubを使ったことがあって、VimとEmacsという単語を知っている程度。
それだけで社内では「パソコン博士」みたいな扱いになっている。
日本が落ちぶれた話になると悪い政治家の話だけが上がって、なんかみんな被害者面なんだな。
というか、天は二物与える人には与えるんだね…😟
家で3万円のPacificaでRime of the Ancient Marinerを弾いてストレス発散してる自分とは違う、
いわゆる、「黒い画面」でnode.js動かそうとか、普通やらないし、
みんなやろうとしない、悪意あるハッカーが使うとさえ思ってる人がいる…😟まあ、terminalでshell使ってるのはみんなそうなんだけどさ
泳げないじゃなくて、とりあえず、足がつくプールに入るのが大事、水を怖がらないためにも頭を水に浸けるのが大事なんだよ…😟
スポーツクラブで初心者講習を見て、👴👵おばちゃんが多いんだけど、泳ぎができない人はまず水を怖がってる、
これが根本的に駄目…😟
どんなに上手くなっても、水を恐れる、というのは大事、
人間にとって不利な環境なんだから、うっかり水泳とか海や川でなくてもプールで死ぬことはある、
だから大事なんだけど、怖さとトレードオフで泳げるようになってる、ということも考えて欲しい…😟
例えば、うっかり海か川に落ちて、基本的には何もしない、とにかく浮く、ことが大事だと俺は思ってるけど、
ちょっと泳げば岸に着ける、という状況なら、リスクを取って泳ぐ、という選択もありになる、
短期的に見れば危険でも、長期的に考えてリスクを取ることで、長期的な利益を得られることがある、
博打とか投資の考え方に似ているけど、普段プールで泳ぐことになれていれば、そのリスクはある程度なんとかなる、大丈夫だろうと思えるものになる、
そういえば、ウシジマくんのニート編で、ニート君はパチンカスで、俺は小出しに人生を賭けてる！とか言ってたけど、
賭ける方向が間違ってるだけで、パチンコじゃなきゃいいんじゃないの？と思った…😟
毎日、ちょっとでもいい、よく知らない曲とか、前々からこれを知りたかったんだ、みたいに思うものに数分でもいい、時間を割いてみる、
塀の中の囚人が、毎日少しずつ脱出の穴を掘るようなものだけど、そこまで緻密にキリキリ考えなくてもいい、
コーヒーを飲んで、気分が落ち着いたら、ちょっと穴を掘ってみるか、みたいに思ってるうちに、いつの間にか脱出口が完成してるかもしれない…😟
資格取得向けではない
賛否両論もあると思うが、IT系現場で働いていたり交流すると話に上がる本がメイン
勉強ももちろんだが、現場の話題についていくという点において読んでおいて損はなさそう
| 書籍 | 主なテーマ | 現在の位置づけ |
| ------------------------ | -------------------- | -------------- |
| 人月の神話 | ブルックスの法則、概念的完全性、銀の弾丸 | ソフトウェア工学の最重要古典 |
| ピープルウエア | 生産性、組織、作業環境、チーム形成 | 開発組織論の古典 |
| 達人プログラマー | 技術者の姿勢、抽象化、自動化、変更容易性 | 現代でも読みやすい準古典 |
| Code Complete | コーディング、設計、レビュー、品質 | 実装技術の百科事典 |
| ソフトウェア作法 | UNIX的なプログラム設計と思考法 | プログラミング文化の古典 |
| プログラミング作法 | 命名、デバッグ、テスト、性能、移植性 | C中心だが原則は普遍的 |
| 珠玉のプログラミング | アルゴリズム的問題解決 | 計算量・問題分解の古典 |
| 計算機プログラムの構造と解釈 SICP | 抽象化、評価、言語処理系 | コンピュータ科学寄りの古典 |
| 書籍 | 内容 |
| ------------------------------------------------------- | ------------------- |
| リファクタリング 第2版 | 振る舞いを変えずに内部設計を改善する |
| レガシーコード改善ガイド | テストのない既存コードを安全に変更する |
| Clean Code | 命名、関数、クラス、可読性 |
| テスト駆動開発 | TDDの基本的な進め方 |
| Growing Object-Oriented Software, Guided by Tests | テストからオブジェクト設計を成長させる |
| Working Effectively with Unit Tests | 単体テストの設計とテスト容易性 |
| A Philosophy of Software Design | 複雑性を減らす設計 |
| The Programmer’s Brain | コードを読むときの認知負荷 |
| 書籍 | 位置づけ |
| --------------------------------- | ------------------ |
| オブジェクト指向における再利用のためのデザインパターン | GoFデザインパターンの原典 |
| Head Firstデザインパターン | パターンの入門書 |
| アジャイルソフトウェア開発の奥義 | SOLID、パターン、アジャイル設計 |
| エンタープライズアプリケーションアーキテクチャパターン | 業務アプリの設計パターン |
| 実践UML | オブジェクト指向分析・設計 |
| オブジェクトデザイン | 責務駆動設計 |
| 書籍 | 内容 |
| ------------------------------------------- | ------------------- |
| ソフトウェアアーキテクチャの基礎 | アーキテクチャ特性、スタイル、意思決定 |
| ソフトウェアアーキテクチャ・ハードパーツ | 分割、粒度、データ、トレードオフ |
| Clean Architecture | 依存関係、境界、ユースケース |
| エンタープライズアプリケーションアーキテクチャパターン | 業務システムの設計パターン |
| Domain-Driven Design | 複雑な業務領域のモデル化 |
| 実践ドメイン駆動設計 | DDDの実践的な適用 |
| Building Evolutionary Architectures | 変更可能なアーキテクチャ |
| Fundamentals of Software Architecture | 現代アーキテクチャの概論 |
唯一の正解ではない
「依存関係を内側に向ける」「業務ルールをフレームワークから分離する」という考え方を学ぶ本であり、すべてのアプリを同じ円形の構造にする本ではない
| 書籍 | 内容 |
| ------------------------------------------- | -------------------- |
| データ指向アプリケーションデザインDDIA | DB、分散処理、一貫性、レプリケーション |
| 分散システムタネンバウム | 分散システム全般の教科書 |
| Designing Distributed Systems | 分散システムの設計パターン |
| Release It! | 本番障害、安定性、回復性 |
| Site Reliability Engineering | SRE、SLI、SLO、運用 |
| Building Secure and Reliable Systems | セキュリティと信頼性 |
| Web Scalability for Startup Engineers | Webシステムのスケーリング |
| System Design Interview | システム設計の考え方を広く学ぶ |
| 書籍 | 内容 |
| -------------------------------- | ----------------- |
| マスタリングTCP/IP 入門編 | 日本で最も定番のTCP/IP入門書 |
| コンピュータネットワークタネンバウム | ネットワーク全般の教科書 |
| コンピュータネットワーキング トップダウンアプローチ | アプリケーション層から学ぶ |
| ネットワークはなぜつながるのか | ブラウザからサーバーまでの流れ |
| 書籍 | 内容 |
| ----------------------------------------- | ------------------- |
| 詳解TCP/IP | TCP/IPの古典 |
| TCP/IP Illustrated | パケットレベルの詳細 |
| High Performance Browser Networking | TCP、TLS、HTTP、ブラウザ通信 |
| パケットキャプチャの教科書 | Wiresharkなどを使った解析 |
| 書籍 | 内容 |
| -------------------------------- | ---------------- |
| Real World HTTP | HTTPの歴史と現代的機能 |
| Webを支える技術 | HTTP、URI、REST |
| HTTP: The Definitive Guide | HTTP/1.1時代の体系的解説 |
| Web API: The Good Parts | Web API設計 |
| 書籍 | 内容 |
| -------------------------------- | --------------- |
| オペレーティングシステム 3つの簡単なピースOSTEP | 仮想化、並行性、永続性 |
| Operating System Concepts恐竜本 | OSの標準的教科書 |
| 詳解UNIXプログラミング | UNIXシステムコール |
| Linuxプログラミングインタフェース | Linux APIの詳細 |
| Linuxのしくみ | Linux内部の入門 |
| ふつうのLinuxプログラミング | Linux上でのプログラム実行 |
| 30日でできる！OS自作入門 | OSの動作を作りながら学ぶ |
| コンピュータシステムの理論と実装Nand2Tetris | 論理回路からOSまで |
| 書籍 | 内容 |
| ------------------------------ | --------------- |
| データベースシステム | DB理論の教科書 |
| Database System Concepts | DBの標準的教科書 |
| SQLアンチパターン | よくあるDB・SQL設計の失敗 |
| 達人に学ぶDB設計 徹底指南書 | 論理設計、正規化、性能 |
| 達人に学ぶSQL徹底指南書 | SQLの考え方 |
| SQLパフォーマンス詳解 | インデックスと実行計画 |
| High Performance MySQL | MySQLの性能設計 |
| PostgreSQL徹底入門 | PostgreSQL固有機能 |
| 書籍 | 内容 |
| ------------------------------------------- | -------------- |
| 体系的に学ぶ 安全なWebアプリケーションの作り方徳丸本 | Webセキュリティの国内定番 |
| Web Application Security | Webアプリの脆弱性と防御 |
| The Web Application Hacker’s Handbook | Web攻撃手法の古典 |
| Security Engineering | セキュリティ工学全般 |
| 暗号技術入門 | 暗号、ハッシュ、署名、証明書 |
| マスタリングTCP/IP 情報セキュリティ編 | ネットワークセキュリティ |
| Threat Modeling | 脅威モデリング |
| Building Secure and Reliable Systems | セキュアで信頼できる運用 |
| 書籍 | 内容 |
| ------------------------------------ | -------------- |
| アルゴリズムイントロダクションCLRS | アルゴリズム分野の標準教科書 |
| アルゴリズムとデータ構造 | 大学教科書的な基礎 |
| 珠玉のプログラミング | 問題解決の古典 |
| プログラミングコンテスト攻略のためのアルゴリズムとデータ構造 | 実装を伴う学習 |
| 問題解決力を鍛える！アルゴリズムとデータ構造 | 日本語での実践的入門 |
| The Algorithm Design Manual | 問題に適したアルゴリズム選択 |
| 書籍 | 内容 |
| --------------------------- | ------------- |
| テスト駆動開発 | TDDの原典 |
| ソフトウェアテスト技法ドリル | 同値分割、境界値など |
| はじめて学ぶソフトウェアのテスト技法 | テスト技法の定番 |
| 実践ソフトウェアエンジニアリング | 開発工程と品質全般 |
| Googleのソフトウェアエンジニアリング | 大規模開発、テスト、保守 |
| 単体テストの考え方／使い方 | 良い単体テストの設計 |
| xUnit Test Patterns | テストコードのパターン集 |
| Continuous Delivery | 自動テストからリリースまで |
| 書籍 | 内容 |
| ----------------------------------- | ------------------ |
| The DevOps ハンドブック | DevOpsの実践体系 |
| Accelerate | 開発組織とデリバリー性能の研究 |
| Continuous Delivery | 継続的デリバリーの原典的書籍 |
| Site Reliability Engineering | GoogleのSRE |
| The Site Reliability Workbook | SREの実践 |
| LeanとDevOpsの科学 | Accelerateの日本語版 |
| Infrastructure as Code | IaCの原則 |
| Kubernetes Patterns | Kubernetes上の設計パターン |
| Release It! | 本番耐性と障害対策 |
| 書籍 | 内容 |
| ---------------------------- | ----------------- |
| Kubernetes完全ガイド | Kubernetesの体系的な理解 |
| Kubernetes Patterns | Kubernetesの設計パターン |
| 入門 Kubernetes | Kubernetesの概念 |
| Docker系の入門書 | コンテナの操作 |
| Infrastructure as Code | インフラのコード化 |
| Cloud Native Patterns | クラウドネイティブ設計 |
| クラウドデザインパターン | クラウド上の設計パターン |
AWS、Azure、Google Cloudについては、以下を優先する
| 書籍 | 内容 |
| ------------------------------------- | -------------- |
| 要求工学系の教科書 | 要求の抽出・分析・管理 |
| ソフトウェア要求 | 要求定義の体系 |
| ユーザーストーリーマッピング | ユーザー行動と開発計画 |
| ユースケース実践ガイド | ユースケース記述 |
| RDRA2.0ハンドブック | 要求とシステム構造の整理 |
| 実践ドメイン駆動設計 | 業務モデリング |
| Domain Modeling Made Functional | 型を使ったドメインモデリング |
| イベントストーミング | 業務知識の探索 |
| 書籍 | 内容 |
| ------------------------- | ------------ |
| 誰のためのデザイン？ | 人間中心設計の古典 |
| インタフェースデザインの心理学 | 認知心理とUI |
| ノンデザイナーズ・デザインブック | レイアウト・配色・文字 |
| Don’t Make Me Think | Webユーザビリティ |
| About Face | インタラクションデザイン |
| デザインシステムの育て方 | デザインシステム |
| Lean UX | 仮説検証型のUX開発 |
| 書籍 | 内容 |
| ---------------------------- | ----------------- |
移民の質が違う。円安と日本語強要で高度人材から避けられる。言語(日本語)が高度にできなくてもいい仕事にそれなりの外国人が就く。
ーー
日本：「量」を補填しても「質」と「構造」が追いつかない脆弱性
一方で日本も、近年は事実上の移民（技能実習生、特定技能、外国人労働者）の受け入れ数を急速に増やしており、国内の外国人労働者数は過去最高を更新し続けています。しかし、スイスとは以下の3点で決定的な構造格差があります。
日本は毎年、数十万人規模（政令指定都市が1つ消えるレベル）で自然減が進んでいます。外国人労働者をいくら「点」で受け入れたところで、内需と労働力の激しい縮小スピードを補填する（マシンの摩耗を抑える）パッチにしかなっていません。
現在の日本円の購買力低下と硬直した言語環境は、世界のトップエンジニアや高度経営人材にとって「出稼ぎに行く国」としての魅力を完全に失わせています。結果として、労働集約型（人手不足の現場）の埋め合わせが主流となり、産業全体の生産性を爆発的に押し上げるイノベーションの起爆剤にはなり得ていません。
人口が減り、内需が縮むことが確定している市場では、企業は大規模な設備投資（資本集約的なアップデート）を躊躇します。その結果、業務を効率化するために海外のSaaSやAWSに頼らざるを得ず、少ない円の売上からさらに外貨でサブスク代を支払うという、典型的な「デジタル小作農」のサイクルから抜け出せなくなっています。
「超低金利でインフレ率も比較的低かった」という意味では、かつての日本円もスイスフランと同じカテゴリーに属していました。しかし、2020年代以降、両者の間には埋められない構造的バグ（脆弱性）の差が顕在化しました。
スイス：製薬、高級機械、プライベートバンクなど、**「他で代替できない高付加価値な商品・サービス」**を輸出しているため、物価高（インフレ）を他国に転嫁できる強靭なOSを持っています。
日本：エネルギー（原油・天然ガス）やデジタルインフラ（AWSなどのクラウド、半導体）を海外に完全に依存しているため、世界的なインフレや円安のコストを一方的に「支払う側（小作農）」になっています。
かつては「世界で危機が起きれば円高」でしたが、現在の日本は少子高齢化による国力の減退（供給力の崩壊）が見透かされているため、有事の際に「円」は買われず、むしろ売り逃げられる通貨に変わりました。一方でスイスは、永世中立国としての政治的安定性と、盤石な経常黒字に裏打ちされているため、**「金利がゼロだろうがマイナスだろうが、世界中の富裕層が資産を避難させたい国」**としての地位を独占しています。
スイスフランの面白さは、**「金利という目先のインカムゲイン（利息報酬）を一切提示しないにもかかわらず、通貨そのものの堅牢性（キャピタルゲイン）だけで世界中のマネーを引き寄せ、円を圧倒している」**という歪みにあります。
どれだけ名目金利が低くても、国の経済構造が強固で通貨価値が毀損しないスイスフラン。
一方で、金利を上げようにも巨額の国債（借金）と住宅ローン破綻リスク（冒頭のニュースの通り）を抱え、利上げのアクセルを踏めないまま減価していく日本円。
この金利と為替のねじれ現象は、表面的な数字の上下ではなく、**「国家の基礎体力（ファンダメンタルズ）の差が、そのまま通貨の格差として出力されている」**という冷徹なファクトを示しています。
「デジタル小作農」という構造は、現代のIT社会における残酷な真実を映し出しています。このシステムに搾取される側から抜け出すための具体的なアプローチを、マークダウン形式で分かりやすく整理します。
かつての封建社会における「地主と小作農」の関係は、現代のテック業界において以下のように完全に再現されています。
* AWS、Azure、Google、OpenAI、iOS/Android（App Store）などのインフラやOSを独占的に所有する。
* プラットフォームを借りてビジネスを行い、売上から重い「手数料（30%など）」や「サブスクリプション料金（地代・年貢）」を支払い続ける。
この構造に依存し続ける限り、以下のシステムエラーから逃れることはできません。
### 1. 為替（円安）連動による「自動的な年貢の値上げ」
プラットフォームの利用料やライセンス料の多くはドル建て、あるいはドルに連動しています。日本国内で**「円」しか稼いでいない企業や個人は、自社の売上やパフォーマンスが変わらなくても、円安が進むだけで自動的に固定費が跳ね上がり、利益を強制的に削り取られる**仕様になっています。
アルゴリズムの変更、APIの有料化、手数料率の改定など、地主側の胸先三寸で昨日までの黒字ビジネスが一瞬で赤字に転落するリスクを常に背負います。「拒否すればビジネスが崩壊する」ため、不条理なルールにも従うしかありません。
この永続的な搾取システムから抜け出す、あるいはリスクを最小化するための具体的なパッチ（修正策）は以下の2点に集約されます。
### 1. プラットフォームに依存しない「ポータビリティ（移行性）」の確保
特定のクラウドベンダー単体にロックイン（依存）されるのを防ぐため、Kubernetesのようなオープンな技術や、環境を選ばない汎用的なアーキテクチャ設計能力を身につけることです。土地（インフラ）の都合に合わせて、いつでも別の場所にシステムを移動できる実力を持てば、地主との交渉力（優位性）を確保できます。
支払うインフラコストがドルやユーロベースで上がっていくのであれば、**自分自身の労働力や成果物をグローバル市場（外貨建てOS）にデプロイし、ドルやユーロで直接報酬を受け取る側になる**のが最も合理的です。稼ぐ通貨を外貨にシフトした瞬間、インフラコストの上昇リスクは完全に相殺され、むしろ自らの資産を守る盾へと反転します。
> **核心のメッセージ**
> インフラをただ消費し、国内の「円」だけで完結しようとする立場に留まり続ける限り、デジタル地主への年貢の支払いが終わることはありません。自らの技術とアセットをグローバルな仕様へとリファクタリング（再構築）することこそが、唯一の生存戦略です。
>
2009年3月の特定の外れ値を基準にした「スイスフランの2.48倍への上昇」という名目の数字は、前述の指摘の通り、データの切り取り方によるマジックという側面を含んでいます。しかし、そこから展開されている「今後の日本円と国内インフラの構造的脆弱性」に関する分析は、現在の日本のマクロ経済が抱える致命的なバグを正確に突いています。
「名目レートの乱高下」というノイズを剥ぎ取った後に残る、日本が直面している冷徹なファクトと構造的リスクを整理します。
### 1. 「円以外の収入がない」場合の、デジタル小作農化の現実
> "AIやクラウド、AWSのサブスクしてると円以外の収入がない場合、年々支払い額が自動的に上がり続ける。"
>
この指摘は、現代の日本のIT業界、およびそれを基盤とする全産業が抱える最大の急所です。
現代のビジネスOSであるAWS、Azure、OpenAIのAPI、各種SaaSのライセンス料は、事実上のドル建て決済（またはドルに連動した円価格改定）です。日本国内の売上（円）がどれだけ一定であっても、実質実効為替レートを含めた円の購買力が下落し続ければ、**「システムを維持するための固定費（サブスク代）が自動的に膨張し、利益を圧迫し続ける」**という仕様エラーが確定します。
どれだけ国内で労働生産性を上げようとしても、インフラの根本を海外ベンダーに握られているため、円で稼いだ富がデジタル・サブスクというパイプラインを通じて無条件で海外へ流出し続ける構造になっています。
### 2. 「エネルギー」「人口減」「移民制限」のトリプル・デッドロック
> "エネルギーとでデジタルインフラの輸入依存度が高すぎるのと少子高齢化で人口減少し外国人移民も制限し経済成長のエンジンがかからなくなり衰退が確定するから。"
>
この分析も、感情論を排したマクロ経済のロードマップとしてきわめて妥当です。
日本はエネルギー自給率が著しく低いため、世界的な地政学リスクやインフレが発生した際、そのコストを円安という形でダイレクトに被らざるを得ません。
少子高齢化による急激な人口減少に加え、言語バグや低い賃金、硬直した移民政策によって外部からの労働力（コア人材）の補填も進みません。これにより、市場としての魅力（内需）が縮むだけでなく、社会システムを維持するための「供給力」そのものが維持できなくなります。
「銀行預金やタンス預金（円100%のポートフォリオ）」で資産を眠らせておく行為が、これら複合的なリスクに対して**「無防備に資産の購買力を削られ続ける設定」**になっているのは間違いありません。
### 結論：個人として「円だけの収入」という単一障害点を排除する
この予測が「ほぼ確実な未来」であるとするならば、取るべきデバッグ作業は、日本経済の行く末を嘆いたり過去のレートを惜しんだりすることではありません。
なんで広告に金を払うかと言えば、それで売上げが伸びるからだ。
広告を載せるためにGoogleやメタに金を払う。広告をみせるためにアプリやサービスを開発してAWSや Azureを通じてAmazonや Microsoftに金を払う。
無課金ユーザーは無料でサービスを享受してるつもりでも、たまに本当にモノを買う、有料サービスを契約
広告主にも、見せられる無課金ユーザーにも、Win-Winじゃないとビジネスは成り立たない。
問題だと思うのは、最近は"広告見たくなかったら金を払え"みたいなビジネスが増えてる。
このビジネスが広まると、広告はWin-Winではなくなり、見たくないウザい広告を見せられることになる。
広告は課金させる手段に成り下がり、ユーザーは広告をみても購買行動をしなくなる。
そうなると、webに広告費を払う企業が減り、業界が急激にしぼむのではなかろうか。
悪貨が良貨を駆逐し、誰も見向きしなくなる。
とにかく使えない。アスペの癖に低IQのコミュ障で、高校時代から個人開発をしつつココナラとかクラウドワークスでフリーランス活動に取り組んでたらしいのだが、それがどちらも7年も取り組んでおいて鳴かず飛ばずで法人すら立ってない事実を棚に上げてポートフォリオに書いてきやがった。
まずその時点で不安だったが、実際に使ってみれば一般的なサーバー管理、バックエンド、フロントエンド、ハードウェア、統計や計算機科学などどれもこれも一見できるように見えて理解が浅い。よく言えば広く浅い知識を持っていると言えるが、要は器用貧乏でまともに経験値がないということだ。AWSの資格すら取っちゃいない。
そんでもって学生時代にめぼしい経験がない。数学を幼少期から極めていたらしく(数IIIを小6でコンプしたというのは素直に驚いた)新しいアルゴリズムを論文に書いて某学会に通したことがあるらしいが、実績と呼べるのはそれくらいで数オリや競プロ、CTFの優勝歴などもない。本当に何の実績もない。大学生は大人なんだからIT目指すなら一つくらい社会に爪痕を残すようなとてつもない偉業をなして当然だろ、何のために大学行ったのか
自分の力と頭で修羅場を乗り越えて何かを為した経験もないのでとにかく子供じみていて扱いに困る。一見口調や語彙は大人びているように見えて忍耐力もコミュ力も何もないから始末に負えない。今どきZ世代は大人びてるんだからIT目指す新卒にもなれば普通少年ジャンプの主役くらいのスペックあって当然なのに。
そんでもって全能感にまみれていて、まるで相手が子供じみているかのように演出する能力だけは超一流。人様に物事を都合よく勘違いさせる能力は使い所を間違えなければ役に立つんだか立たないんだか。
マジで人様の前に立つカリスマ性も人様を率いる胆力も人様に率いられる根性も図太さもアイデア力も実績も実力も精神力も頭も心も体も顔も何もない無能中の無能中の無能なのでこんな奴を寄越した人事を末代まで呪うつもりだ。
結果の出ない努力は苦労や道楽ですらない。意味のある努力をした俺らがようやく意味のない辛酸も含めて舐めることができる権利を与えられているのに、無駄な努力しかせず時間を浪費した人間はエンジニアになる資格なんてない。それを解っちゃいない人事の奴らはバカしかいない。
Googleのアカウントが停止されて困らない人は居ないでしょ？
なのに、なぜ迂闊にその危険があるのにも関わらずGoogleドライブを使用するの？
とくにGoogleとは関連しないアプリで作成した過去ファイルをわざわざGoogleドライブにアップロードする意味がわからない。
自分でも、いったい何のファイルが入っているのかわからないような過去データが入ったフォルダとかあるでしょ？
ああいうのを何も考えずにGoogleドライブでバックアップしようとする人の気がしれない。
個人的には、過去ファイルのバックアップは、その容量が大きくないのであればAWSのS3で保存するのがベストだと思ってる。
一般的に考えられる個人利用の範囲であれば、料金も微々たる程度だし、安全だし、Amazonがファイルの内容に立ち入りすぎることもない。
専門的知識もほとんど必要ないし、わからなければAIに聞けば手取り足取り教えてくれる。
クラウドストレージを使うにしてもGoogleとかAppleとかアカウントの削除が死活問題になるようなものを手軽だからと利用するのは納得がいかない。
もちろん、スマホでアプリを使ってなにか作業をするのならそれらを使うのは仕方ないし当然だと思う。
よもやよもや！悩んで立ち止まるより、進め！心を燃やせ！結論から言う！営業が「向いてない」と感じてるなら、無理に続けるな！自分に合う土俵で戦え！俺は「数字と仕組みで評価される静かな職場」が大好きだ！逆に「声のデカさと飲み会で出世が決まる文化」は大嫌いだ！
おすすめ進路（年収450万以上を狙える“コミュ障フレンドリー”）
好き：定型・点検・改善で評価、資格手当豊富、夜勤手当ウマい！
目安年収：450–550。狙う資格：第二種電気工事士→乙4→ボイラー→ビル管。
好き：手順通り・安全第一・寮社宅あり、地方の工業地帯で稼げる！
目安年収：400–550。狙う資格：ITパス→CCNA or LPIC1→AWS SAA／JSTQB。
目安年収：350–500（簿記2級取って月次まで行けば上がる）。
目安年収：400–520。フォークリフト・VLOOKUP/ピボット。
今すぐの実行プラン（90日）
1) どれか一本に絞る
2) エージェントを3社並行
例：「新規/月30件架電→アポ率xx%→受注yy%」「Excelで見積自動化→作業時間-40%」→“黙々と改善できる人”として打ち出せ！
最後に
