残高ゼロ。なぜ海外の面接官はあなたの「銀行残高」に興味がないのか
（文字数目安：約1,800文字 ※3,000文字の導入は読者の離脱率が極めて高いため、読みやすさを維持しつつ詳細に記述する最大量として調整しています）
どうも！ ヨーロッパの片隅で、C#とWPFを相棒に企業向けのデスクトップアプリを設計・開発している[あなたのブログ名、もしくは名前]です。
海外でエンジニアとして働きたい、もしくは働き始めたばかり。そんな皆さんに向けて、今日はちょっと「得する話」、いや、マジで僕のエンジニア人生と海外生活を変えた「思考法」についてシェアしたいと思います。
技術ブログのつもりで開いた人、ごめんなさい。今日はアーキテクチャの話をしますが、半分は「人生術」の話です。でも、特に僕らみたいなロジックとコードで飯を食ってる人間には、ぶっ刺さる内容だと確信してます。
<h4>海外転職、最初の「壁」</h4>
さて、皆さんが海外で働こうとするとき、最初にぶつかる壁って何だと思いますか？
言語？ ビザ？ もちろんそれもデカい。でも、僕が一番面食らったのは、「面接（インタビュー）」の質が日本と全く違うことでした。
日本での転職活動、特に僕ら技術者は、「職務経歴書」がほぼ全てだったりしませんか？
「〇〇社にてC#を5年、WPFでの設計経験3年」「××プロジェクト（50人月）でリーダーを担当」
こんな風に、自分の「今現在のスキル」や「達成した結果」を箇条書きにしますよね。
これは、いわば**「銀行口座の現在の残高」**を見せているようなものです。
「私、今、これだけのスキル（残高）持ってますよ」と。
そして、日本の多くの面接官は、その「残高」を見て、「ふむ、この人ならこれくらい仕事ができそうだ」と判断します。
ところが、海外（少なくとも僕が経験したヨーロッパや北米のスタイル）は、違いました。
<h4>「で、あなたはその残高をどうやって作ったの？」</h4>
僕も最初は、日本のスタイルで面接に臨みました。
「C#とWPFの経験は豊富です。設計から実装まで一人で完結できます」（ドヤァ）
返ってきた質問は、これです。
「OK。じゃあ、君が直近で最も苦労したバグについて教えてくれる？ なぜそれが起きて、君はどういう思考プロセスでそれを特定し、どう解決したの？ 他の解決策は検討した？」
……え？
僕は一瞬、固まりました。
「えーっと、確か、メモリリークのバグがありまして……対応しました」
「だから、どうやって？」
彼らが知りたかったのは、僕の「現在の残高（＝僕はWPFができます）」ではなかったんです。
彼らが血眼になって知りたかったのは、僕の**「取引履歴（＝通帳の全記録）」**だったんです。
[Event] Aという設計判断をした[Event] Bというバグを踏み抜いた[Event] 焦ってCという対処をしたが、失敗した[Event] チームメイトとDという仮説を立てた[Event] Eという手法でデバッグし、根本原因Fを発見した[Event] Gという修正を適用し、Hという学びを得た
彼らは、この一連の「イベントの連なり（イベントストリーム）」を、僕の口から聞きたかったんです。なぜなら、「残高が100万円」という事実は、それが「昨日100万円振り込まれた」のか、「10年間コツコツ貯めた」のか、「200万円あったけど昨日100万円失った」のか、背景を全く説明してくれないからです。
海外の雇用主は、あなたが「今、何ができるか」よりも、「どうやってそれをできるようになったか」を知りたがります。なぜなら、彼らが採用したいのは「今の残高」ではなく、「未来も継続的にお金（価値）を生み出せるプロセス」そのものだからです。
僕は、この「履歴を見せろ」というプレッシャーに、最初の数回、まったく対応できませんでした。「残高」を見せる準備しかしていなかった僕は、自分の「取引履歴」をロジカルに説明できなかった。……つまり、自分の過去を、自分で説明できなかったんです。
<h4>アーキテクトの秘密</h4>
この「ヤバい、俺、自分の価値を証明できてない」という焦りの中で、僕はふと、あるシステムの設計で使われる、ちょっとマイナーだけど強力なアーキテクチャパターンのことを思い出しました。
それが、今回のフックである**「イベントソーシング（Event Sourcing）」**です。
聞いたことありますか？
もし知らなくても、全く問題ないです。一言で説明します。
イベントソーシングとは：「現在の状態（State）」を保存する代わりに、その状態に至るまでに発生した全ての「出来事（Event）」を、発生した順にすべて記録・保存する設計手法
ピンと来ないですよね（笑）。
大丈夫。さっきの銀行の例えで一発です。
- 普通のシステム（状態ベース）：
- データベースには「現在の残高：10,000円」という「状態」だけが保存されている。
- 昨日いくらだったか？ なぜ10,000円なのか？ そのデータは、もう上書きされて消えてしまっています。
- イベントソーシングのシステム：
- データベースには「残高」というデータはありません。
- 代わりに、
[口座開設（残高0円）][+50,000円（給与振込）][-15,000円（家賃引落）][-25,000円（クレカ引落）]……という「イベント」のリストが、時系列で「追記」され続けます。 - 「現在の残高は？」と聞かれたら？
- 簡単です。履歴（イベント）を最初から全部、足し算・引き算するだけです。
この設計の何がすごいか？
それは、**「履歴（イベント）こそが、唯一の真実（Source of Truth）である」**という思想です。
「現在の状態」なんてものは、所詮、過去のイベントを積み重ねた結果に過ぎない、ただの「幻影（Projection）」だ、と。
僕はこの概念に気づいた時、雷に打たれたような衝撃を受けました。
「これだ……！」
海外の面接官が知りたかったのは、僕の「現在の残高」という幻影じゃない。
僕のキャリアを形作った「イベントストリーム」という「真実」そのものだったんだ、と。
そして、この「イベントソーシング」の考え方——僕が勝手に**「イベントソーシング思考」**と呼んでるんですが——こそが、海外でエンジニアとして、いや、一人のプロフェッショナルとして生き抜くための、最強の「人生術」になる。そう確信したんです。
このブログシリーズでは、僕らITエンジニアが技術的に知っている「イベントソーシング」という概念を、いかにして「海外で戦うためのキャリア戦略」に応用していくか、僕の実体験ベースでガッツリ解説していきます。
次の「承」のセクションでは、なぜこの思考法があなたの過去の「失敗」すらも「最強の資産」に変えてしまうのか、その秘密に迫ります。
アーキテクトの秘密。「イベントソーシング」があなたの過去を「最強の資産」に変える
（文字数目安：約2,000文字）
「起」の記事、読んでくれましたか？
どうも、[あなたのブログ名、もしくは名前]です。海外でC#とWPFをこねくり回してます。
前回のあらすじはこんな感じでした。
「海外の面接官は、君の『現在のスキル（銀行残高）』にはあまり興味がない。彼らが知りたいのは、君がどうやってそのスキルを築き上げたか、その全履歴、つまり『通帳の取引履歴（イベントストリーム）』なんだ」
……と、偉そうに言いました。
でも、正直に言って、普通の感覚ならこう思いませんか？
「いやいや、通帳の全履歴とか、絶対見せたくないわ！」
そうなんですよ。
僕だってそうです。「給与振込」みたいなポジティブなイベントだけならいい。でも、通帳には「謎の出費」「飲み会での散財」「うっかりミスによる損失」みたいな、黒歴史も全部記録されてるわけです。
キャリアも同じ。
「プロジェクト成功」「スキル習得」だけじゃない。「デプロイ失敗」「客先で大炎上」「上司とケンカして左遷（？）」……誰だって、隠したい過去、ありますよね。
僕も、今の会社に入る前の面接で、こんな経験があります。
面接官：「君のWPFの経験で、一番の『失敗』は何？」
僕（うわ、来たよ……。あの、パフォーマンス地獄になったプロジェクトのことか……？ でも、あれ言ったら『コイツ、設計できねえな』って思われるよな……）
僕：「えーっと、まぁ、小さなバグは日々ありましたが、プロジェクトを止めるような大きな失敗は、幸いにもありませんでしたね（キリッ）」
……はい、最悪の回答です。
面接官の顔が、一瞬で「コイツ、浅いな」って顔になったのを、僕は見逃しませんでした。
当時の僕は、キャリアを「状態（ステート）ベース」で考えていたんです。
「失敗した」という「悪い状態」は、早く「成功した」という「良い状態」で上書きして、隠さないといけない、と。
だから、面接官に「失敗」という「負の残高」を見せられなかった。
でも、これが「イベントソーシング思考」を身につけた今なら、全く違う答え方をします。
なぜなら、イベントソーシングというアーキテチャが持つ「ある特性」が、この「失敗」という概念をひっくり返してくれるからです。
<h4>アーキテクトの秘密①：イベントは「不変（Immutable）」である</h4>
システム設計において、イベントソーシングの最大のルールのひとつ。それは、**「一度発生したイベントは、絶対に削除・変更してはならない（Immutable）」**ということです。
例えば、「-15,000円（家賃引落）」というイベントが発生したら、それを「-10,000円」に改ざんしたり、「やっぱナシ！」と削除したりすることは許されません。
もし間違えたら？
「+5,000円（家賃修正入金）」という新しいイベントを追記するしかないんです。
これ、人生とキャリアに当てはめてみてください。
僕らは、過去の失敗を「なかったこと」にしたがります。
「あの炎上プロジェクト、俺の経歴書から抹消したい……」
「あの時、ああ言えばよかった……」
でも、事実は変えられない。
「炎上した」という事実は、**不変（Immutable）**なんです。
「状態ベース」の思考だと、この「変えられない過去（悪い状態）」に絶望します。
「ああ、俺のキャリアに傷がついた（残高が減った）」と。
でも、「イベントソーシング思考」は、こう言います。
「OK、[Event] プロジェクト炎上 が発生したね。それはもう変えられない。じゃあ、次にどんなイベントを追記する？」
[Event] プロジェクト炎上[Event] 炎上の根本原因を（寝ずに）分析[Event] C#の非同期処理（async/await）の理解が浅かったことを特定[Event] 対策として、ブロッキング処理をすべてTask.Runで別スレッドに逃がす[Event] （さらに）Dispatcher経由でUIスレッドに安全に戻す処理を実装[Event] パフォーマンス改善。鎮火。
ほら。
「炎上した」という事実は消えていません。でも、その後の「イベントの追記」によって、「炎上」というイベントの「意味」が変わったんです。
単なる「失敗」から、「非同期処理の重要性を、実戦で学んだ学習イベント」へと意味が変わる。
過去は変えられない。でも、未来のイベントを追記することで、過去のイベントの「解釈」は変えられる。
これが、イベントソーシングが持つ「不変性」のパワーです。
<h4>アーキテクトの秘密②：「完全な履歴（Audit Log）」こそが資産</h4>
イベントソーシングのもう一つの強み。それは、**「すべてのイベントが履歴として残っている」**ことです。
これにより、「なぜ、今この状態（残高）になったのか」を、100%完璧に追跡できます。
これを「監査証跡（Audit Log）」と呼びます。
さっきの面接の例に戻りましょう。
面接官が「一番の失敗は？」と聞いた時、彼が本当に聞きたいのは「あなたが失敗した」という事実（状態）じゃありません。
彼が聞きたいのは、**「あなたが、その失敗から何を学び、どう回復したか」という「監査証跡（イベントストリーム）」**なんです。
「状態ベース」で考えていた僕：「（失敗を隠して）大きな失敗はありませんでした（キリッ）」
→ 面接官：「（コイツ、履歴を見せないな。信用できん）」
「イベントソーシング思考」の僕：「あります！ 以前、WPFのパフォーマンスチューニングで大失敗しました。具体的には……（と、上記の[Event] 炎上から[Event] 鎮火までを、生き生きと語り始める）」
さあ、どっちのエンジニアが「信頼できる」か。どっちが「未来の問題も解決してくれそう」か。
一目瞭然ですよね。
僕が面接で出会った、あの「浅いな」って顔をした面接官たちは、全員この「監査証跡」の重要性を知っていたんです。
なぜなら、**ソフトウェア開発の本質は「問題解決」**だから。
問題解決のプロセスとは、まさに「イベントの連なり」そのものです。
「バグがない（＝残高がプラス）」エンジニアなんて存在しません。
海外の現場が欲しがるのは、「バグ（＝マイナスイベント）が発生した時に、それを解決する（＝プラスイベントを追記する）能力」が高いエンジニアです。
あなたのキャリアの「監査証跡」——特に、失敗し、悩み、もがき、解決した「泥臭いイベントストリーム」——こそが、他の誰にも真似できない、あなただけの「最強の資産」なんです。
失敗を隠すな。むしろ、それを「イベント」として正確に記録し、分析し、堂々と語れ。
それが、あなたの価値を証明する唯一の方法だからです。
<h4>「状態」を捨て、「イベント」を記録せよ</h4>
「残高ゼロ」から始まったこの話、少し見えてきたでしょうか。
僕らが目指すべきは、「現在の残高」を増やすこと（＝状態を良く見せること）ではありません。
僕らがやるべきは、「価値ある取引履歴（イベントストリーム）」を、日々、自分のキャリアの元帳に刻み続けることです。
じゃあ、具体的にどうやって？
僕らC# / WPFエンジニアは、幸運です。
なぜなら、僕らの仕事道具（C#やWPFの設計）そのものが、この「イベントソーシング思考」を実践・訓練する最高のフィールドだからです。
次の「転」では、この思考法を、僕らの日常業務——WPFの設計やC#のコーディング——にどう落とし込み、技術力とキャリア戦略を同時に鍛え上げていくか、具体的なテクニックを解説します。
WPFと元帳。C#で実践する、バグではなく「意図」を記録する思考法
（文字数目安：約2,200文字）
どうも！ [あなたのブログ名、もしくは名前]です。
「承」まで読んでくれてありがとうございます。「失敗（イベント）は不変。だから隠すな。解決（イベント）を追記して、最強の監査証跡（キャリア）にしろ！」って話をしました。
……と、まぁ、概念はわかった、と。
「わかるけど、それ、意識高い系の自己啓発じゃないの？」
「海外の面接で語るネタとしてはわかったけど、普段の仕事と何の関係が？」
そう思いますよね。
僕も最初は、この「イベントソーシング思考」を、面接対策の「喋り方テクニック」くらいにしか思ってませんでした。
でも、違ったんです。
この思考法は、僕らC# / WPFエンジニアの日々のコーディング品質とデバッグ速度を劇的に上げる、超・実践的な訓練だったんです。
「転」では、この思考法を僕らの日常業務——WPFの設計とC#のコーディング——にどう落とし込むか、具体的な話をします。
<h4>僕らの「Git」こそが、最強の「イベント元帳」</h4>
まず、一番身近なところから。
皆さんの「Gitのコミットメッセージ」、どんな風に書いてますか？
昔の僕：「バグ修正」「WIP（作業中）」「〇〇機能の対応」
……はい、これ、典型的な「状態（State）ベース」の記録です。
何をしたかの「結果」しか書いていない。銀行の残高報告と一緒です。
これ、海外（特にコードレビューが厳しい現場）でやると、速攻でレビューイ（レビュアー）からツッコミが入ります。
「OK、バug fix なのはわかった。で、何のバグを、なぜ、どうやって直したの？」
ほら、来た。
面接官と同じことを聞かれるんです。彼らは「結果（状態）」じゃなく、「プロセス（イベント）」を知りたがっています。
イベントソーシング思考のコミットメッセージは、こうなります。
Fix: ログインボタンが押せないバグを修正
ユーザー名が空の場合に、ViewModelのCanExecuteが
falseを返すべきところ、初期化漏れでtrueのままだった。
コンストラクタで初期バリデーションを呼ぶイベントを追加し、
CanExecuteが正しく状態を反映するように変更。
……どうです？
これはもう「作業報告」じゃなく、「発生したイベント（問題）」と「追記したイベント（解決策）」の完全な「取引履歴」ですよね。
これが、僕が言う「元帳（Ledger）」です。
Gitのコミットログは、あなたの思考の「イベントストリーム」そのものであるべきなんです。
「めんどくせぇ」って？
いやいや、これが未来のあなたを救うんですよ。
半年後、その機能が原因で別のバグが出たとします。「状態ベース」の「バグ修正」というログを見ても、あなたは「……半年前の俺、何したかったんだっけ？」と頭を抱えることになります。
でも、「イベントベース」のログがあれば？
「ああ、そうそう！ 初期化漏れがあったんだ。じゃあ、今回の問題は、その初期化処理の『後』に発生した別のイベントが原因かもな」
……と、デバッグの速度が、まったく変わります。
キャリアも同じ。「あの時、何を学んだか」を「イベント」として記録しておくクセが、あなたの「監査証跡（キャリア）」を豊かにするんです。
<h4>WPFは「イベント駆動」なのに、なぜ僕らは「状態」でバグらせる？</h4>
次に、僕らの本丸、WPFとMVVMです。
WPFって、そもそも「イベント駆動（Event-Driven）」アーキテクチャですよね。ボタンがクリックされた（イベント）、テキストが変わった（イベント）、ウィンドウがロードされた（イベント）。
僕らは毎日「イベント」を扱ってるはずなんです。
……なのに、なぜか僕らが書くコードは「状態（State）」だらけになる。
例えば、こんなコード、書いてませんか？
（ViewModelの中だと思ってください）
C#
private bool _isLoading;
public bool IsLoading
{
get => _isLoading;
set
{
_isLoading = value;
OnPropertyChanged(); // Viewに通知
}
}
public async Task LoadDataAsync()
{
this.IsLoading = true; // 状態を変更
try
{
// ... 重いデータ取得処理 ...
await Task.Delay(3000); // 3秒待つフリ
}
finally
{
this.IsLoading = false; // 状態を変更
}
}
「え、ダメなの？ 普通のMVVMじゃん」って？
ダメじゃないです。動きます。
でも、これは「意図」が欠落した「状態」のコードなんです。
もし、このLoadDataAsyncが非同期で2回呼ばれたら？
もし、finallyに来る前に例外でクラッシュしたら？
IsLoadingプロパティはtrueのまま固まり、ユーザーは永遠にグルグル（ローディング）を見続けることになります。
これが「予期せぬ状態（＝バグ）」です。
なぜこれが起きるか？
それは、僕らがIsLoading = true;という「状態」しか記録（コード化）せず、「なぜ、trueになったのか」という「イベント（意図）」を記録していないからです。
<h4>バグではなく「意図」を記録する</h4>
じゃあ、「イベントソーシング思考」でこれを書くとどうなるか。
それは、「状態」を変えるのではなく、「イベント（意図）」を記録（コード化）する、ということです。
一番簡単な実践は「ロギング」です。
C#
public async Task LoadDataAsync()
{
// 「状態」を変える前に、「イベント（意図）」を記録する
Log.Information("[Event] データ取得処理を開始します。");
this.IsLoading = true;
try
{
// ... 重いデータ取得処理 ...
await Task.Delay(3000);
Log.Information("[Event] データ取得処理が正常に完了しました。");
}
catch (Exception ex)
{
// 「失敗イベント」も、もちろん記録する
Log.Error(ex, "[Event] データ取得中に例外が発生しました。");
throw; // 例外は再スロー
}
finally
{
// 「完了イベント」を記録する
Log.Information("[Event] データ取得処理が（成功・失敗問わず）終了します。");
this.IsLoading = false;
}
}
バカにしてはいけません。
この「ログ（イベントストリーム）」があるだけで、さっきの「グルグル固まるバグ」が起きた時、原因究明のスピードが天と地ほど変わります。
ログファイルに「[Event] データ取得処理を開始します。」とだけ記録されていて、その後の「完了」や「終了」のログがなかったら？
「ああ、tryブロックの途中で、ログにも出ないヤバいエラー（OutOfMemoryExceptionとか）でプロセスごと死んだな」と、一発でわかるわけです。
これが「バグ（予期せぬ状態）を追う」のではなく、「意図したイベントストリームから外れた箇所を探す」というデバッグ手法です。
C#には、これをもっと高度に実践するための「ドメイン・イベント」や「リアクティブプログラミング（Rx.NET）」といった技術がありますが、根っこは同じ。
「状態」を直接いじるな。「出来事（イベント）」を定義し、その「イベント」に応じて「状態」が変化するように設計しろ、という思想です。
<h4>「状態」は嘘をつき、「イベント」は真実を語る</h4>
なぜ「状態」ベースの設計がバグを生むのか。
それは、**「状態」は「過去のイベントが積み重なった、ただの結果」**でしかないからです。
IsLoading = trueという「状態」は、LoadDataAsyncが呼んだのか、はたまた別のRefreshCommandが呼んだのか、その「状態」だけ見ても区別がつきません。
でも、「イベント」は違う。
[Event] LoadDataAsyncが開始されましたという「イベント」は、**発生したその瞬間の「真実」**です。
日々のコーディングで「なぜ、このコードが必要なのか」という「意図（イベント）」を、コミットメッセージやログ、あるいは設計そのものに記録していくクセをつける。
これが、あなたのWPFアプリケーションを堅牢にし、同時に、あなたのキャリアという「元帳」に、「私はこれだけの思考プロセス（イベント）を経て、この設計（状態）に至りました」という、誰にも反論できない「真実（監査証跡）」を刻み込む、最強の訓練になるんです。
さて、この訓練を積んだ僕らは、いよいよこの「イベントストリーム」を使って、自分の未来を設計します。
次の「結」では、この思考法を使って、どうやって自分のキャリアを「リプレイ」し、次のステップを「予測」していくか。その具体的な方法について、お話しします。
未来をリプレイする。あなただけの「イベントストリーム」を構築し、次のキャリアを予測する
（文字数目安：約2,100文字）
長旅にお付き合いいただき、ありがとうございます！ [あなたのブログ名、もしくは名前]です。
「起」で、海外の面接官はあなたの「銀行残高（＝現在の状態）」ではなく「取引履歴（＝イベントストリーム）」を見たがっている、という話から始まりました。
「承」で、その履歴、特に「失敗」というイベントは不変であり、それを隠すのではなく「解決」イベントを追記することで「最強の資産（監査証跡）」に変える、という秘密を共有しました。
そして「転」で、その思考法を、僕らの日常業務（C#のログやGitのコミット）に落とし込み、「意図（イベント）」を記録する訓練が、いかに重要かをお話ししました。
ここまで来れば、もうあなたも立派な「イベントソーシング思考」の実践者です。
さて、いよいよ「結」です。
この思考法がもたらす、最大の「得する情報」をお伝えします。
それは、**「自分のキャリアを意図的に設計し、未来を予測する」**ということです。
<h4>キャリアの「リプレイ」で、自信（現在の状態）を再構築する</h4>
イベントソーシングのシステムには、「リプレイ（Replay）」という強力な機能があります。
「現在の残高」データがもしバグや障害で吹っ飛んでも、まったく問題ありません。
なぜなら、「取引履歴（イベントストリーム）」という「唯一の真実」さえ残っていれば、イベントを最初から再生（リプレイ）するだけで、いつでも「現在の残高（状態）」を100%正確に復元できるからです。
これ、僕らのキャリアでめちゃくちゃ重要なことだと思いませんか？
海外で働いていると、僕は今でも、自分の「現在の状態」に自信をなくすことがあります。
「俺、今のプロジェクトで価値出せてるかな……」
「周りのネイティブの議論、早すぎてついていけない……」
「俺のWPFスキル、もう古いんじゃないか……」
こんな時、僕らの「現在の状態（＝自信）」は、限りなくゼロに近くなります。
ここで「状態ベース」の思考だと、「ああ、俺はダメだ（残高ゼロだ）」と落ち込んで終わりです。
でも、「イベントソーシング思考」なら、こうします。
「OK、自信（状態）が失われた。なら、リプレイしよう」
「転」で話した、あなたが日々記録してきた「元帳」を開くんです。
それは、あなたの詳細なGitコミットログかもしれないし、業務日誌や、このブログ記事のような技術アウトプットかもしれません。
[Event] 2023/01/15: 担当機能で深刻なパフォーマンスバグ発生[Event] 2023/01/17: async/awaitのデッドロックが原因と特定。3日格闘。[Event] 2023/01/18: 根本修正をコミット。チームから感謝される。[Event] 2023/02/05: 新人エンジニアにWPFのDI設計をレクチャー。[Event] 2023/03/10: 顧客からの複雑な要求を、シンプルなUIに再設計し提案。採用される。
……どうです？
これらの「イベント（真実）」を最初から見直していくと、どうなるか。
「あれ、俺、ちゃんとやってんじゃん」
「あの時、あんなデカいバグ直したんだった」
「設計だって変えたじゃん」
失われていた「自信」という「現在の状態」が、過去の「イベント（真実）」によって、再構築されていくんです。
「現在の状態」は、ただの「幻影」です。あなたの価値は、あなたが積み重ねてきた「イベントストリーム」そのものなんです。
<h4>「未来のキャリア（別の状態）」を予測（Projection）する</h4>
そして、ここからが本題です。
イベントソーシングでは、「元帳」から「現在の残高」を作り出すことを「プロジェクション（Projection / 射影）」と呼びます。
重要なのは、ここ。
ひとつの「イベントストリーム」から、作り出せる「状態（プロジェクション）」は、ひとつとは限らないんです。
銀行の元帳（イベントストリーム）から、
- 「現在の残高」という状態（プロジェクションA）
- 「今月の食費だけの合計」という状態（プロジェクションB）
- 「全期間の平均入金額」という状態（プロジェクションC）を、自由に作り出せるのと同じです。
さあ、これをあなたのキャリアに応用しましょう。
あなたの「イベントストリーム（＝経験の元帳）」は、今、「C# / WPFデベロッパー」という「状態（プロジェクションA）」を作り出しています。
でも、もしあなたが「次は、ソリューションアーキテクトになりたい」と思ったら？
簡単です。
あなたの「イベントストリーム」を使って、「ソリューションアーキテクトとしてのあなたの現在の状態（プロジェクションB）」を、新しく計算（射影）してみればいいんです。
自分の元帳（Gitログ、日誌、記憶）をリプレイしながら、アーキテクトに必要な「イベント」だけを抽出していくんです。
[Event] 2023/01/18: バグを直した- → （これは「デベロッパー」のイベントだな）
[Event] 2023/03/10: 顧客要求を分析し、UIを再設計した- → （来た！ これは「アーキテクト」のイベントだ！ カウント！）
[Event] 2023/04/02: チーム間のAPI仕様のズレを調整した- → （これもだ！ 「システム間連携」のイベント！）
[Event] 2023/05/11: 新技術（.NET MAUI）を調査し、導入の是非をレポートした- → （最高！ 「技術選定」のイベントだ！）
……これをやると、何が起きるか。
「あれ？ 俺、アーキテクトとしての経験、もう30%くらい積んでね？」
と、「現在地」が正確にわかるんです。
そして、同時に、「足りないイベント」も明確にわかる。
「やばい。『インフラ設計』のイベントが一個もねえ……」
「『コスト試算』のイベントもゼロだ」
<h4>「状態」を目指すな。「イベント」を発生させろ。</h4>
ここまで来れば、もうあなたが明日からやるべきことは、わかりますよね。
多くの人は、「アーキテクトになる（状態）」というフワッとした目標を立てます。
でも、「イベントソーシング思考」のあなたは、違います。
あなたの目標は、「『インフラ設計』のイベントを、自分の元帳に追記すること」です。
目標がここまで具体的になれば、行動は勝手に決まります。
「今のプロジェクトのインフラ設計のミーティング、俺には関係ないけど、オブザーバーでいいから参加させてもらおう」
「クラウドの勉強会に参加して、自分でも一度コスト試算のデモをやってみよう」
「その結果を、[Event] コスト試算レポート作成として、チームに共有しよう」
そう。
僕らは、「未来の状態」を直接コントロールすることはできません。
僕らがコントロールできるのは、「今、発生させるイベント」だけなんです。
この「次に必要なイベントは何か」を特定し、それを狙って発生させ、自分の「元帳」に追記していく。
この繰り返しこそが、「キャリアを設計する」ということです。
海外で働くということは、常に「お前は何者で、何ができるんだ？」と問われ続けることです。
その時、あなたの「現在の状態（肩書や残高）」は、何の助けにもなりません。
でも、あなたが地道に記録し、積み重ねてきた「イベントストリーム（元帳）」があれば。
その「真実の記録」こそが、あなたの過去を証明し、あなたの現在を支え、あなたの未来を予測する、唯一無二の武器になります。
さあ、あなたの「元帳」を開きましょう。
そして、今日、どんな「イベント」を追記しますか？
コメント