コードと現実のギャップ：海外で気づいた「ITエンジニアの景色」
（ここから本文：約3000文字）
どうも、海外の片隅でC#を書いて暮らしているITエンジニアです。いつもはWPFアプリの設計だとか、.NETの新しい機能だとか、そういう技術的な話を中心にキャリアハック的なことを考えていますが、今日はちょっと違う角度から、僕が海外で働いて「うわ、これヤバいな」と肌で感じた話をシェアしたいと思います。
テーマは「コードの向こう側にいる、生身の人間」。
僕らエンジニアの仕事って、突き詰めれば「問題解決」ですよね。クライアントの「こんな機能が欲しい」を形にする。ユーザーの「ここが不便」を解消する。ロジックを組み立て、バグを潰し、パフォーマンスを改善する。そのプロセス自体がパズルみたいで楽しいし、自分の書いたコードが動いて、誰かの役に立つ（はず）っていうのは、何物にも代えがたいやりがいです。
僕も日本にいた頃は、まさにそんな感じでした。WPFでデスクトップアプリを作っていた時も、いかにリッチなUIを、いかに少ないリソースでサクサク動かすか、XAMLとC#のコードを行ったり来たりしながら、まさに「技術」に没頭していました。
でも、海外に出て、特に日本のような「インフラが整いすぎている国」とは違う、いわゆる「開発途上国」と呼ばれる地域や、経済的にまだまだ発展途上のコミュニティ向けのプロジェクトに関わるようになって、強烈な違和感というか、カルチャーショックを受けました。
それは、「技術的に完璧なコード」が、必ずしも「現地の人を幸せにするとは限らない」という、身も蓋もない現実です。
例えば、僕らが良かれと思って設計したシステム。日本では当たり前の「高速インターネット常時接続」を前提に作っていたとします。クラウドと連携し、リッチなデータをリアルタイムで同期する…技術的にはクールですよね。でも、それを導入する現地のインフラが、まだ不安定な3G回線がメインだったら？あるいは、1日のうち数時間しか電気が安定供給されない地域だったら？
僕らが「技術の粋」を集めて作ったアプリケーションは、現地では「重すぎて動かない」「すぐにオフラインになって使い物にならない」ただの“ガラクタ”になってしまうんです。
これ、笑い話じゃなくて、実際に僕が目の当たりにした光景です。日本でテストした時は完璧に動いた。スペックシート上も問題なかった。でも、現場では全く使われない。ユーザーは、結局もっとシンプルで、オフラインでも動く、なんなら古臭いExcelの管理表に戻っていきました。
その時、僕らが提供したのは「価値」だったんでしょうか？ もしかしたら、彼らの仕事を一時的に混乱させただけの「ノイズ」だったんじゃないか？
この経験が、僕に「The Human Impact（人間への影響）」という視点を強烈に植え付けました。
今回のフック（お題）にもあるように、僕らエンジニアは、特に新興国や開発途上国で技術を展開するとき、意図せず「デジタル・ディバイド（情報格差）」を助長してしまったり、「アルゴリズム・バイアス（アルゴリズムの偏見）」を生み出してしまったりする危険性と、常に隣り合わせなんです。
「アルゴリズム・バイアス」なんて言うと、AIとか機械学習の話だと思うじゃないですか。もちろんそれも大きい。例えば、欧米のデータセットだけで学習した顔認証AIが、アジア系やアフリカ系の人の顔をうまく認識できない、なんて話は有名ですよね。
でも、これ、僕らみたいなデスクトップアプリや業務システムのエンジニアにも無関係じゃないんです。
例えば、僕がWPFで作るような業務アプリで、何かの審査ロジックを組んだとします。「もし、この地域の平均所得より低い収入なら、このオプションは非表示にする」とか、「過去のデータに基づき、この属性のユーザーにはこの機能を制限する」とか。
一見、合理的な判断に見えても、その「過去のデータ」自体が、すでに存在する社会的な偏見や格差を反映していたら？ 僕らの書いたif文一つが、特定のグループの人々を、意図せずシステムから「排除」してしまうかもしれない。
さらに踏み込んで言えば、「デジタル・コロニアリズム（デジタル植民地主義）」なんていう、ちょっと強烈な言葉もあります。
これは、僕らのような技術的に進んだ国（とされる）エンジニアが、「こっちの方が効率的だから」「こっちのUI/UXがモダンだから」っていう「僕らの常識」を、現地の文化や習慣、価値観を無視して押し付けてしまうことを指します。良かれと思ってやったことが、結果的に現地のコミュニ Fティを分断したり、彼らが持っていた固有のやり方を破壊してしまったりする。
海外で働くエンジニアとして、僕らが向き合うべきなのは、C#の新しい構文やWPFのテクニックだけじゃない。僕らの作る「道具」が、文化や経済が違う場所で、どう使われ、人々の生活にどんな影響を与えてしまうのか。その「責任」について、本気で考える必要があるんです。
「そんなのエンジニアの仕事じゃない、企画やPMが考えることだ」
そう思うかもしれません。でも、本当にそうでしょうか？ 仕様書通りに作るだけがエンジニアの仕事なら、僕らはAIに取って代わられてしまうかもしれない。
現地で、自分のコードがもたらした「予想外の結果」を目の当たりにしたからこそ、僕は強く思うんです。技術を深く理解している僕らエンジニアだからこそ、その「影響」に気づけるし、声を上げられるはずだと。
このブログは、海外で働きたいエンジニアの皆さんに、「技術力」と同じくらい、あるいはそれ以上に大切な「視点」を提供したいと思って書いています。
次の「承」のセクションでは、僕らが具体的にどんな「格差」や「偏見」を無意識のうちに生み出してしまっているのか、もっと突っ込んだケーススタディを見ていきたいと思います。
見落とされるインパクト：僕らが無意識に広げる「格差」とは
（ここから本文：約3000文字）
「起」で投げかけた、僕らのコードがもたらす「責任」。これ、大げさな話じゃなくて、日々の設計やコーディングの「ちょっとした選択」に潜んでいるんです。
今回のテーマである「デジタル・ディバイド（情報格差）」や「アルゴリズム・バイアス（アルゴリズムの偏見）」。これ、AIやビッグデータ、GAFAみたいな巨大テック企業だけの問題だと思っていませんか？ 僕は、そう思っていました。C#とWPFでデスクトップアプリや社内システムを作っている自分には、あまり関係のない、遠い世界の議論だと。
でも、違ったんです。この「格差」や「偏見」は、僕ら業務システム開発者が書く、一行のif文や、一つのUIデザインの中に、驚くほど簡単に忍び込むんです。
ケース１：良かれと思って作った「高機能」が、現地を「置き去り」にする
これは、僕が海外のローカルオフィス向けに、ある業務管理ツールをWPFで開発した時の話です。日本側（僕）は、それはもう気合を入れて作りました。
「現地のスタッフも、モダンなUIの方が嬉しいだろう」
「データはリアルタイムでクラウド同期して、どこからでも見える方が便利だろう」
「このライブラリを使えば、リッチなグラフ表示も簡単だ」
C#の最新の非同期処理（async/await）を駆使し、リッチなサードパーティ製UIコンポーネントをふんだんに使い、MVVMパターンに則った美しい設計…。技術的には、なかなかの自信作でした。
ところが、現地に導入して数週間。フィードバックは最悪でした。
「起動に5分かかる」
「ボタンを押しても、次の画面が出るまで固まる」
「データが同期されるのを待っている間に、電話対応が終わってしまう」
慌てて現地の環境を調べたら、彼らが使っていたのは、僕の開発マシン（メモリ32GB、高速SSD）とは似ても似つかない、10年近く前の、メモリ4GB、OSもアップデートされていないようなロースペックPCだったんです。
しかも、ネットワーク環境も最悪。「高速インターネット」なんて名ばかりで、実際は頻繁にパケットロスする不安定な回線。
僕が「良かれ」と思って詰め込んだリッチなUIコンポーネントは、彼らの非力なPCでは描画するだけでCPUを食い尽くしていました。僕が「便利」だと信じたリアルタイム同期処理は、不安定な回線の上でタイムアウトを繰り返し、アプリ全体の動作を「フリーズ」させていました。
結果、どうなったか。現地のスタッフは、僕が作ったピカピカのWPFアプリを使うのをやめ、古くから使っていた、オフラインでも動くシンプルなExcelの管理表に戻ってしまいました。
これって、まさに「デジタル・ディバイド」じゃないですか？
僕ら技術者が、無意識のうちに「これくらいのスペックは普通だよね」「これくらいの回線速度はあるでしょ」という「先進国の常識」を押し付けてしまった。その結果、その「常識」から外れた人たちを、自分たちのシステムから「排除」してしまったんです。
彼らにとって、僕の作ったアプリは「エンパワーメント（力を与えるもの）」ではなく、自分たちの仕事のやり方を否定し、自分たちの環境の「遅れ」を突きつける、「フラストレーションの塊」でしかありませんでした。
ケース２：「当たり前」のバリデーションが、人を「存在しない」ことにする
もう一つ、背筋が寒くなった「アルゴリズム・バイアス」の実例です。
あるシステムで、ユーザー登録機能を作っていました。ごく普通の、名前、住所、電話番号、性別などを入力するフォームです。
ここでも僕は「エンジニアとしての常識」をフル稼働させました。
「名前フィールドには、変な記号が入らないようにしよう。アルファベットと空白だけを許可する正規表現（Regex）でバリデーションだ」
「電話番号は、国番号と市外局番、みたいな固定フォーマットで入力させよう」
「性別は、”Male” / “Female” のドロップダウンリストだな」
C#のコードで言えば、こんな感じのロジックです。
if (!Regex.IsMatch(input, @”^[a-zA-Z\s’-]+$”)) { // エラー処理 }
一見、何の問題もない、むしろ「堅牢な」設計に見えますよね？
でも、これが導入先の国では、大問題を引き起こしました。
まず、名前。その国では、公的な名前にアポストロフィ（’）以外の記号（例えばハイフン）や、アルファベット以外の文字（現地の言語固有のアクセント記号など）を含む人が、普通に存在したんです。僕の「完璧な」バリデーションは、そうした人たちを「不正な入力」として、ことごとく弾いてしまいました。
電話番号も同じです。国によっては、電話番号の桁数が地域によって違ったり、そもそも「固定のフォーマット」が存在しない場合もある。僕の決めつけたフォーマットは、多くの人の正しい電話番号を「エラー」にしました。
そして、性別。僕が「当たり前」だと思って設置した”Male” / “Female”の二択。これは、その国の文化で認識されている多様な性自認、あるいは「性別を公表したくない」という選択肢を、完全に無視するものでした。
僕が書いた数行のバリデーションロジックは、僕の「無知」と「偏見」に基づいた、立派な「アルゴリズム・バイアス」だったんです。
このシステムにとって、「僕の常識から外れた名前を持つ人」や「僕の常識から外れた性自認を持つ人」は、文字通り「存在しない」のと同じでした。なぜなら、彼らはシステムに登録することすらできないからです。
これは、AIの顔認証が特定の人種を認識できない、という話と根っこは全く同じです。僕らエンジニアが持つ「暗黙の前提（=バイアス）」がコードに反映され、それが特定の人々を不当に扱ったり、システムから排除したりする。僕らC#エンジニアの日常にも、この落とし穴はゴロゴロ転がっています。
僕らの「常識」が、誰かの「障壁」になる
「起」で触れた「デジタル・コロニアリズム（デジタル植民地主義）」という言葉が、ここで重く響いてきます。
結局のところ、僕がやったのは、「僕の国の、僕の環境の、僕の価値観の『常識』」を、現地のコンテクストを一切考慮せずに、コードという形で一方的に「輸出」しただけなんです。
「こっちのUIの方がモダンでしょ？」
「こっちのやり方の方が効率的でしょ？」
その傲慢さが、現地のPCスペックを見落とさせ、現地の文化（名前や性別）を無視させた。
僕らは、ただC#やWPFという「技術」を提供しているつもりかもしれません。でも、実際には、その技術に「僕らの文化」や「僕らの価値観」をベッタリと塗りたくって、一緒に送り込んでいる。それが、現地の文化や習慣と衝突したとき、僕らのコードは「武器」にも「障壁」にもなり得るんです。
ここまで、僕らの「無意識」がどうやって格差や偏見を生み出すか、という暗い話をしてきました。
じゃあ、技術って、結局のところ現地にとっては「害」にしかならないんでしょうか？ もちろん、そんなことはありません。
次の「転」では、この苦い失敗を乗り越えた先で出会った、テクノロジーが「本当に」現地の人々をエンパワーした事例と、そうでない事例を分けた「決定的な違い」について、掘り下げていきたいと思います。
「エンパワー」か「搾取」か：技術が持つ二つの顔
（ここから本文：約3000文字）
「承」で紹介した、僕の「自信作」だったWPFアプリが、現地で「重すぎて使えないガラクタ」認定された話。あれは、僕のエンジニアとしてのプライドを（良い意味で）ズタズタにしてくれました。
プロジェクトは当然、大炎上。僕らは「バージョン2」の開発を余儀なくされました。
その時、僕のチーム内でも意見が割れたんです。
「いや、アプリの問題じゃなくて、現地のPCスペックが低すぎるのが悪い。PCを新しくすりゃいいじゃん」
「回線が不安定なら、現地のインフラ業者に文句言うべきだろ」
これ、まさに「承」で話した「デジタル・コロニアリズム（デジタル植民地主義）」の思考停止ですよね。「自分たちの『当たり前』に、お前らが合わせろ」という傲慢さです。もし、このまま進んでいたら、僕らは「害」を上塗りするだけだったでしょう。
でも、幸いなことに、僕らは（痛い目を見たおかげで）違う道を選びました。
「違う。僕らの『当たり前』が、彼らの『当たり前』と違っただけだ。僕らが彼らの現実に合わせるべきだ」
この「転」換が、すべてのはじまりでした。
ケース３：失敗したWPFアプリの「再生」と「真の」エンパワーメント
僕らは、技術的な「小手先の最適化」をいったん全部捨てました。非同期処理のawaitをちょっとイジるとか、XAMLの描画を軽くするとか、そういうレベルの話じゃないと悟ったからです。
僕がやったこと。それは、コードを書くのをやめて、現地に飛んだことです。（もちろん、今はリモートでも可能ですが、当時は物理的に行きました）
そして、ひたすら彼らの「仕事」を観察した。Excelに戻ってしまった彼らが、一体「何」を「どう」やっているのか。
衝撃でした。彼らは、僕が「非効率だ」と切り捨てたExcelのシートを、とんでもない「職人技」で使いこなしていたんです。不安定なネットワークを前提に、まずローカルで全部入力し、ネットワークが安定する「特定の時間帯」（例えば早朝）にだけ、そのファイルを共有サーバーに「手動で」コピーしていた。
僕が作った「常時接続・リアルタイム同期」のアプリは、彼らのこの「知恵」を、ただ「邪魔」していただけだったんです。
この瞬間、僕のミッションはクリアになりました。
「彼らの『やり方』を否定するな。彼らの『知恵』を、テクノロジーで『補強』しろ」
僕らは日本に戻り、WPFアプリのアーキテクチャを根本から見直しました。
【技術的な「転」換】
- 「常時接続・リアルタイム同期」の全廃。これが最大のガンでした。僕の独りよがりな「モダン」の押し付けでした。代わりに導入したのが、「オフライン・ファースト」という考え方です。
- ローカルDB（SQLite）の徹底活用。C#（.NET）から簡単に使える、軽量なローカルデータベースSQLiteを導入しました。ユーザーの入力は、まず「すべて」ローカルPC上のSQLiteに保存される。クラウドには一切アクセスしません。これにより、アプリの応答速度は劇的に改善しました。もはや、ネットワーク速度もPCスペックも関係ない。サクサク動きます。
- 「手動同期ボタン」の実装。そして、アプリの目立つ場所に、デカデカと「今すぐ同期する」というボタンを一つだけ設置しました。ユーザーは、自分の好きなタイミング（＝ネットワークが安定していると彼らが判断した時）で、このボタンを押します。C#側では、ボタンが押されたら初めてasync処理が走り、ローカルのSQLiteに溜まった差分データだけを、まとめてクラウドに送信する。
- UIの徹底的な「軽量化」。「承」で失敗した、リッチなサードパーティ製UIコンポーネントも全部捨てました。WPF標準の、何の飾り気もないTextBoxやDataGridだけを使いました。見た目は正直、ダサい。でも、ロースペックPCでも瞬時に起動し、描画される。
さて、この「バージョン2」の結果どうなったか。
「最高だ！」
「これだよ、俺たちが欲しかったのは！」
現地スタッフから、初めて絶賛されました。
彼らにとって「価値」があったのは、僕が最初に見せつけた「リアルタイム同期」や「リッチなUI」という「技術」ではなく、「オフラインでもサクサク動き、自分たちのタイミングで安全にデータを預けられる」という「信頼感」だったんです。
彼らは、自分たちの「仕事のやり方」（＝ネットワークが安定した時に手動で同期する）を変える必要がなかった。僕のアプリは、彼らの「知恵」を邪魔するのではなく、「Excelの手作業コピー」という一番面倒でミスが起きやすい部分だけを、安全に自動化する「道具」として、初めて機能しました。
これこそが、「エンパワーメント」です。
「害」と「エンパワーメント」を分けたもの
「承」の失敗ケース（V1）と、「転」の成功ケース（V2）。
どちらも使った技術スタックは、C#とWPFです。技術そのものに善悪はありません。
「害」になったV1は、僕が「技術（モダン、リアルタイム）」を主語にして、それを現地に「押し付けた」結果です。
「エンパワーメント」になったV2は、僕が「現地の人間（彼らの知恵、彼らの環境）」を主語にして、彼らの「邪魔」にならないように」技術を使った結果です。
この違いは、天と地ほどあります。
僕らエンジニアは、新しい技術や「モダンな」アーキテクチャを試したい誘惑に常にかられます。WPFで言えば、もっとリッチな描画を、もっとリアクティブな設計を、と。
でも、海外で働く（特に日本とは全く違う環境で働く）時、その「技術的な欲望」が、そのまま「デジタル・コロニアリズム（植民地主義）」という「害」になり得る。
逆に、「承」のケース２で失敗した「名前のバリデーション」や「性別の選択肢」も、このV2のプロジェクトで学びました。
「僕らの『常識』でバリデーションを組むな。彼らが『自分はこうだ』と入力するものを、そのまま受け入れろ。システム側がそれに（後から）対応しろ」と。
僕らの仕事は、コードを書くことじゃありません。
コードという「道具」を使って、僕らの「常識」の外にいる人々の「現実」を、より良く（あるいは、少なくとも邪魔をしない）手伝いをすること。
この「転」換、つまり「技術」中心から「人間」中心への視点の切り替えこそが、海外で働くエンジニアに一番求められる「人生術」であり「スキル」なんだと、僕は今、本気で思っています。
さて、この大失敗と小さな成功を経て、僕らエンジニアが「害」を避け、「真のエンパワーメント」を生み出すために、明日から具体的に何をすべきなのか。
最後の「結」で、僕なりの「行動指針」をまとめてみたいと思います。
明日から僕らができること：コードの先に「人」を見るエンジニアへ
（ここから本文：約3000文字）
ここまで読んでくれて、本当にありがとうございます。僕の失敗談とちょっとした成功体験に、ここまで付き合ってくれたあなたは、きっと「ただコードが書けるエンジニア」で終わりたくない、と思っているはずです。
「転」で、僕が「技術（モダンなWPFアプリ）」を押し付けたV1の失敗と、「現地の人間（彼らの知恵）」に寄り添ったV2の成功について書きました。
C#やWPFの技術レベルで言えば、正直、V1の方が「モダン」で「クール」だったかもしれない。async/awaitを駆使したリアルタイム同期、リッチなUIコンポーネント…。エンジニアとしての「見せ場」は多かった。
でも、それは「マスターベーション」でした。ユーザーを完全に無視した、僕の自己満足。
V2は、技術的には「退化」しているように見えるかもしれません。オフライン・ファースト、手動同期、標準のダサいUI。でも、これこそが「プロの仕事」だったと、僕は胸を張って言えます。
僕らエンジニア、特に海外で働くエンジニアが目指すべきは、「クールな技術」を振り回すことじゃない。「現地の人々の、生身の現実を、1ミリでも良くする『動く道具』」を、泥臭く、確実に提供することです。
そのために、僕が「結」として皆さんに提案したい「明日からできること」は、4つあります。
1. 「スペックシート」の前に「人間」を読め
僕らエンジニアは、すぐ「技術仕様書」や「PCスペック」を見たがります。もちろん、それは大事です。でも、「承」で僕が失敗したように、それだけでは「現実」を見誤ります。
僕がV2で成功したのは、コードを書くのをやめて、「現地スタッフがExcelでどういう『知恵』を発揮しているか」を観察したからです。
これからあなたが関わるプロジェクトで、もしユーザーが海外の人々なら、お願いだから「人」を見てください。
- 彼らは、1日中安定したネットが使える？
- 彼らは、僕らと同じ高性能なPCを使ってる？
- 彼らの「名前」は、アルファベットと空白だけで構成されてる？
- 彼らの「性別」は、「男/女」の二択で収まる文化？
- 彼らが「非効率だ」と僕らが思うやり方をしているなら、それは「なぜ」？（もしかしたら、僕らが知らない「不安定なインフラ」から身を守るための、最高の「知恵」かもしれない）
仕様書にif文を書く前に、ifの条件分岐で「排除」されてしまう人はいないか、と想像力を働かせる。WPFでリッチなUIを作る前に、その描画負荷に耐えられないPCで泣く人はいないか、と立ち止まる。
コードの先にいる「人」の顔を、解像度高く想像すること。これが、僕らの最初の「責任」です。
2. 「完璧な技術」より「十分な道具」を目指せ
C#エンジニアとして、.NETの最新機能を追いかけたい。WPFで、もっとリッチでリアクティブなUIを実現したい。その探究心は素晴らしいし、僕も大好きです。
でも、それが「ユーザーのため」ではなく「自分のため」になっていないか、常に自問すべきです。
「転」で話したように、彼らが求めていたのは「リアルタイム同期」という「完璧な技術」ではなく、「オフラインでも動く」という「十分な道具」でした。
新興国や開発途上国での「十分」は、僕らの「完璧」より、ずっと価値が高い。
不安定なネットワーク、頻繁な停電、ロースペックなハードウェア。それが「前提」です。
その「前提」の上で、どうやって彼らの仕事を止めないか。どうやってデータを守るか。SQLiteに退化させるとか、あえて「手動同期」にするとか、そういう「技術的な引き算」ができること。
これこそ、海外で価値を生み出せるエンジニアの「本当の技術力」だと、僕は思います。ピカピカの技術を足すことより、泥臭い現実に対応するために「引く」ことの方が、よっぽど難しいんですから。
3. 自分の「常識」を、一番疑え
これが、一番難しいかもしれません。僕も「承」で、名前のバリデーションや性別のドロップダウンで、盛大にやらかしました。
日本で、恵まれたインフラと、単一民族的な文化の中で育った僕らの「常識」は、グローバルスタンダードでは、むしろ「特殊」です。
- 「ネットは常時繋がっていて当たり前」
- 「PCはサクサク動いて当たり前」
- 「名前は『姓』と『名』で構成される」
- 「性別は二択」
これらは全部、僕らのローカル・ルールに過ぎません。この「無意識のバイアス」に気づけないままコードを書くと、僕らの書いたif文や正規表現は、国境を越えた瞬間に「差別のツール」に変わってしまいます。
「アルゴリズム・バイアス」なんて、AI開発者だけの話じゃない。僕らC#エンジニアが書く、たった一行のバリデーションコードが、それなんです。
だから、自分の「常識」を常に疑ってください。「この仕様、うちの国の常識で決めつけてない？」と、常に問い続ける。その「謙虚さ」こそが、グローバルなエンジニアの最強の武器になります。
4. エンジニアは「壁」ではなく「橋」になれ
「そんなのエンジニアの仕事じゃない。PMや企画が考えることだ」
この言葉は、半分本当で、半分嘘です。
PMや企画者は、「技術が何をしでかすか」を知りません。
「このバリデーションが、現地の人を『存在しない』ことにしてしまう」なんて、Regexを書く僕らにしか分からない。
「このリッチなUIが、ロースペックPCでは『凶器』になる」なんて、WPFの描画負荷を知る僕らにしか分からない。
僕らエンジニアは、「仕様書通りに作る」だけの「壁」であってはいけない。
「その仕様、現地のPCじゃ動きませんよ」
「そのバリデーション、文化的にヤバいです。こういう『排除』を生みますよ」
と、技術的な知見から「人間への影響」を予測し、PMや企画者にフィードバックする。「技術」と「社会」の間に立つ「橋」になるべきなんです。
それが、フックにあった「エンジニアの責任」の正体です。僕らは、僕らの書いたコードが生み出す「ヒューマン・インパクト」から逃げられない。だったら、そのインパクトを「害」から「エンパワーメント」に変えるために、積極的に声を上げていくべきです。
最後に
これからの時代、C#が書けるとか、WPFが使えるとか、そういう「技術力」だけでエンジニアの価値が決まる時代は、もう終わりかけている気がします。
本当に市場価値が高く、世界中で必要とされるエンジニア。
それはきっと、技術力に加えて、「自分のコードが、文化の違う場所で、誰を幸せにし、誰を傷つける可能性があるか」を想像できる人。そして、その「傷つける可能性」を、自分の技術で「潰せる」人です。
このブログが、あなたが「コードの先」にいる「生身の人間」に想いを馳せる、何かのキッカケになれば、僕が「承」でやらかした数々の失敗も、少しは報われる気がします。
海外で、一緒に「本当に」価値のある仕事をしましょう。
僕もまだまだ道半ばです。お互い、頑張りましょう！
コメント