「コードとしては問題ないのに、なんか物足りないんだよね。」
これは、僕が海外に来て最初のプロジェクトでリーダーから言われた言葉です。
正直、そのときの僕は「？？？」という気持ちでいっぱいでした。
WPFでUIもちゃんと動いてる。バグも出ていない。要求仕様はすべて満たしている。日本でやってきたプロジェクトなら、胸を張って「完了です！」と報告できるレベル。
でも、リーダーの反応は全然違った。
「技術的には良い。でもユーザーの目線で考えたら、これだと“ただのソフト”なんだよ」
その瞬間、頭をガーンと殴られたような衝撃が走りました。
僕が日本でエンジニアをしていた頃、基本的には「設計通りに動くこと」がゴールでした。要件定義に沿ってコードを書き、テストをして、リリースする。もちろん、それが間違っているわけじゃない。むしろ日本の現場では“それが正義”でした。
でも、海外に来てから感じたのは「正義の基準が違う」ということです。
彼らは単に「動けばいい」では満足しない。動くのは当たり前。むしろそれはスタート地点に過ぎないんです。
大事なのは、その先。
「ユーザーがどう感じるか」
「どんな体験を提供できるか」
「人間らしい使いやすさがあるか」
まるでアプリケーションの中に“人の温度”があるかどうかを見ているような感覚でした。
最初は正直、かなり戸惑いました。
だって、C# WPFの設計ってけっこうロジカルだし、データバインディングやMVVMパターンをきっちりやれば、構造的にもきれいになる。それで十分だと思ってたから。
ところが現地の同僚たちはレビューでこう言うんです。
「この画面、ユーザーが最初に触ったときに迷わないかな？」
「このエラーメッセージ、ちょっと冷たくない？」
「ボタンの配置、もう少し直感的にできない？」
僕の頭の中には「そんなの仕様に書いてなかったよ！」って声がぐるぐる回っていました。
でも、彼らにとってはそれこそが“仕様より大事な部分”だったんです。
今振り返ると、この気づきが僕にとっての「エンジニアとしての第二のスタートライン」でした。
技術的に正しいコードを書くことから、ユーザーに共感できる体験を作ることへ。
最初に言われた「技術的には良い。でも人間味が足りない」という言葉は、まさにProblemの宣告だったわけです。
僕はそこで初めて「ただコードを書く」から「人に届くプロダクトを作る」という発想にシフトせざるを得なくなった。
その過程が僕の海外エンジニア生活を大きく変えるきっかけになりました。
最初の衝撃から数週間後、僕は新しいモジュールの開発を任されました。
C# WPFで作る管理ツールの画面。機能自体はシンプルで、一覧表示、詳細表示、そして編集できるフォーム。まさに「エンジニアが安心して取り組める」典型的な仕事でした。
僕は例によって、MVVMパターンを忠実に守り、ViewModelのプロパティを綺麗にバインド。コマンドもきちんと実装し、リレーショナルデータも効率的に取得。テストデータで動かしてみてもバグなし。
「よし、今度は文句ないはずだ」
そう思ってレビューに出したんです。
ところが、またもやチームリーダーの第一声はこうでした。
「技術的には問題ない。でもね――」
デジャヴのような感覚でした。
彼が指摘したのは、以下の3点でした。
- エラーメッセージが冷たい
例：「入力値が不正です」→「どこがどう不正なのか分からない」
「再試行してください」→「どう再試行すればいいか分からない」 - UIの流れが直感的でない
編集画面に入ると、ユーザーがまずどこを触ればいいのか迷う。必須入力欄の強調がない。 - “人間らしい声”がない
「処理が成功しました」だけでは、通知としては正しいけど冷たい。
「更新が完了しました。これで次のステップに進めますよ！」みたいに、少しだけでも人に語りかけるトーンがほしい。
僕は正直、頭の中でこう叫んでいました。
「いやいや、それはエンジニアの仕事なのか？」と。
日本で働いていたときなら、UIの文言やフローなんてSEやUX担当が決める部分だった。僕ら開発者は仕様に従ってコードを書く、それが当たり前。
でも海外の現場では違ったんです。
開発者もユーザー視点で考えることを期待される。むしろ「コードと人をつなぐ翻訳者」であることが求められる。
その事実に直面した僕は、内心パニックになりながらも、やらざるを得ない状況に追い込まれました。
そこで僕がとった行動は、シンプルに 「ユーザーを観察する」 ことでした。
幸い、そのプロジェクトではテストユーザーが社内にいて、実際に画面を触ってもらえる環境がありました。
最初のテストのとき、僕は画面の隅でじっとユーザーの操作を見ていました。
すると、すぐに気づいたんです。
- ユーザーがマウスカーソルをあちこち動かしながら「どこから始めればいいの？」と小声でつぶやく。
- 入力ミスをした瞬間、「なんでエラー出たんだろう？」と首をかしげる。
- 保存が完了しても「これで本当に反映されたのかな」と不安そうに待っている。
――僕はその様子を見て、心臓をぎゅっと掴まれたような感覚になりました。
「この不安や迷いを作っているのは、俺のコードだ」
それまでの僕は、コードを「動かす」ことしか考えていなかった。
でも目の前のユーザーにとっては、動くだけでは足りない。
安心感や信頼感、そして“分かりやすさ”がなければ、それは完成していないんだと気づかされました。
その体験から、僕は次の改善を試みました。
- エラーメッセージを具体的に
「入力値が不正です」→「日付は未来の日付を入力してください」
「再試行してください」→「ネットワークが一時的に切断されました。接続を確認して、再度［保存］をクリックしてください」 - UIに“導線”を作る
必須入力欄には背景色をうっすら変えて、最初に目が行くようにする。
タブオーダーも見直し、入力フローが自然になるように調整。 - メッセージに“人間味”を足す
「保存が完了しました」→「保存が完了しました。これで安心して次に進めます！」
「削除しました」→「削除しました。必要なら、すぐに取り消すこともできます」
これらを組み込んだ上で再度レビューに出したとき、リーダーの反応が変わりました。
「うん、これならユーザーが迷わずに使える。いいね」
正直、バグを潰したとき以上の達成感がありました。
なぜなら、それは「コードとして正しい」だけではなく、「人として自然に使える」ものになった証だったからです。
ここまでくると、僕の中で大きな変化が始まりました。
以前の僕：
- コードが動けばOK
- 仕様通りなら責任を果たした
- UIや文言は他部署の領域
今の僕：
- コードはスタート地点にすぎない
- ユーザーが迷わず安心して使えることがゴール
- 開発者も共感力を持って設計に参加する
つまり、 「ただのエンジニア」から「ユーザー体験をデザインするエンジニア」へとシフトし始めた のです。
この転換のきっかけは、最初に浴びせられた「技術的には良い。でも人間味が足りない」という一言。
その後のテスト観察と改善のプロセスを経て、僕の中に「コードと人間をつなぐ」意識が芽生えました。
それはまさに、ProblemからSolutionへの橋渡しとなる Transformation（変化の始まり） でした。
あの改善を経験したあと、僕のエンジニアとしての姿勢は少しずつ変わり始めていました。
でも、その変化を決定的なものにしたのは、ある「事件」でした。
プレゼンでの“沈黙”
プロジェクトの進捗報告会。チーム全体が集まる場で、僕も担当した画面のデモをすることになりました。
正直、前回の改善が評価されて少し自信がついていた僕は、「これならウケるはずだ」と心のどこかで思っていました。
デモを始めると、みんな真剣に画面を見ています。
僕は説明しながら操作を進め、「保存が完了しました。これで安心して次に進めます！」という新しいメッセージを表示させました。
……その瞬間、会議室に沈黙が走りました。
僕は「え？」と思いました。笑いでも、うなずきでも、何かしらの反応を期待していたのに、みんな顔を見合わせるばかり。
やっと口を開いたのはUXデザイナーの同僚でした。
「うーん、悪くないんだけど……このトーンだと、逆にユーザーが『押し付けられてる』って感じるかも」
僕は一気に冷や汗が出ました。
共感と押し付けの違い
その後のディスカッションで分かったのは、 「人間味を入れること」と「ユーザーに共感すること」は違う ということでした。
僕は“冷たいメッセージ”を改善しようとして、逆に“押し付けがましいメッセージ”を作っていたのです。
「これで安心できます！」という表現は、あたかも僕がユーザーの感情を決めつけているように聞こえる。
本当に大事なのは「ユーザーが自分で安心できる状態を支える」ことでした。
ここで初めて、僕は「共感の設計」という言葉の意味を理解しました。
- 押し付ける設計：開発者の都合や感情をユーザーに流し込むこと
- 共感する設計：ユーザーの立場に立ち、状況や感情に寄り添う表現や導線を作ること
これは僕にとって、まさに目から鱗の気づきでした。
エンジニア脳の“バグ”
日本で働いていた頃の僕は、効率性や正確さを最優先に考えていました。
「無駄を省く」「論理的に正しい」「パフォーマンスが高い」――それが最高のコードだと思っていた。
でも、その考え方をユーザー体験に持ち込むと、しばしば“バグ”になる。
なぜなら、人間は論理的に行動する生き物ではないからです。
例えば：
- 入力フォームのタブオーダーを最適化しても、ユーザーは必ずしもその順番通りに操作しない。
- エラーメッセージを短く正確にしても、ユーザーはそれだけでは安心できない。
- 操作手順を効率化しても、ユーザーは分かりやすさや「できている実感」を優先する。
つまり、人間の行動は「エンジニア的な正しさ」とは別の軸で動いている。
僕が気づいたのは、ここに橋をかける必要があるということでした。
マインドセットのリファクタリング
この体験をきっかけに、僕は自分のエンジニアとしての“マインド”をリファクタリングするようになりました。
以前のマインド：
- コードの正確さ > ユーザーの感覚
- 仕様通りであれば満足
- 人間の感情は自分の領域外
新しいマインド：
- ユーザーの感覚 = コードの正確さ
- 仕様を超えてでも使いやすさを考える
- 感情もまた設計要素の一部
この切り替えには時間がかかりました。
最初は「エンジニアが感情にまで関わる必要あるのか？」と抵抗もありました。
でも海外の現場では、それが“当たり前”として求められる。
むしろ、それをやらないと「ただのコーダー」と見なされてしまうんです。
文化の違いがくれた気づき
ここには文化的な背景も大きく関わっていました。
日本の現場では「役割分担」が非常に明確で、要件定義はSE、設計はアーキテクト、実装はエンジニア、と縦に分かれていました。
だから、ユーザー体験に関することは自分の範疇外だと自然に思っていた。
一方で、僕が働いている海外の現場では「役割の境界が曖昧」です。
開発者も仕様を考えるし、UXデザイナーもコードを読んだりする。
お互いの領域に足を踏み入れながら「より良いものを作ろう」と議論するのが普通。
この文化の中で働くことで、僕は「自分の役割の壁」を壊すことを余儀なくされました。
そして、その壁を壊した先に「共感を設計に組み込む」という新しいスタンスが待っていたのです。
“人間のコード”を書く
この経験を経て、僕は次第に「コードは人間と対話するものだ」と思うようになりました。
C#のシンタックスやWPFのXAMLは確かに機械に向けて書いている。
でも、その結果生まれるUIは人間に向けられるもの。
つまり、僕らは「機械語」と「人間語」を翻訳する役割を担っている。
それなら、論理的に正しいだけのコードでは足りない。
人間の感覚や感情を理解し、それをUIやメッセージに織り込む。
言うなれば、人間のコードを書く 必要があるのです。
あのプレゼンでの沈黙、そして「共感の設計」という概念に出会ったことは、僕のエンジニア人生を大きく変えました。
以前の僕は「コードを書けること」にアイデンティティを置いていました。
でも今は、「コードを通して人とつながれること」が、自分にとっての誇りになっています。
変化した日常の仕事スタイル
以前の僕は、開発タスクをもらうと、ひたすら「どう実装するか」だけを考えていました。
いかに綺麗にMVVMでまとめるか、非同期処理をどう効率化するか、コードレビューで指摘されないようにどう整えるか。
でも今は、最初にこう自分に問いかけるようになりました。
- この機能をユーザーはどんな状況で使うんだろう？
- 操作するとき、ユーザーは不安を感じないだろうか？
- このメッセージを見て「よかった」と思ってもらえるかな？
その問いかけをベースに、仕様を読み直し、場合によってはPMやUX担当に相談するようになりました。
「この仕様、ユーザーから見て分かりやすいですか？」と。
昔の僕なら絶対に言わなかったセリフです。
結果的に、コードを書く前の時間は増えました。
でもリリース後の「ユーザーからのフィードバック」は圧倒的に良くなった。
これは大きな自信につながりました。
チーム内での役割の変化
海外で働くエンジニアとしてもう一つ大きかったのは、チームから見られる自分の立ち位置が変わったことです。
以前は「C#とWPFが得意な日本人エンジニア」という認識でした。
でも今は「ユーザー目線でレビューしてくれる人」としても期待されるようになっています。
例えば、デザインレビューの場でUXデザイナーが案を出したとき、僕がこう口を挟むことがあります。
「この導線だと、初めて触る人はちょっと迷うかもしれません」
「エラーメッセージ、もう少し具体的に書いた方が安心感が出ると思います」
するとUXデザイナーから「それいいね、取り入れよう」と言ってもらえる。
昔の僕なら「UIはデザイナーの領域」と線を引いていましたが、今ではそこに自分も責任を持つ感覚があります。
“エンジニア × 共感”が生み出す強さ
この経験を通して分かったのは、エンジニアが共感力を持つことは大きな武器になるということです。
エンジニアリングの世界では、新しいフレームワークや技術は次々に出てきます。
C# WPFだって、かつての主流からは少し古い技術に見られることもある。
でも、「人に届く体験を設計できる力」は決して古くならない。
なぜなら技術は移り変わっても、人間の感情や行動の本質は変わらないからです。
「安心したい」「迷わず使いたい」「気持ちよく終わらせたい」――それはどの時代のユーザーにも共通している。
僕はC# WPFという少しニッチな分野でキャリアを積んできましたが、その中で「共感を設計に組み込む」力を得たことで、自分の武器は普遍的になったと感じています。
海外で得た最大の学び
もし日本にいたままだったら、僕はおそらく今も「仕様通りに動けばOK」という世界に閉じこもっていたと思います。
でも海外で働き、文化の違いに直面し、ユーザーに寄り添うことを求められたことで、僕は強制的に視野を広げられました。
最初はつらかったです。
「エンジニアがそこまで考える必要あるの？」と何度も思ったし、心のどこかで「それは俺の仕事じゃない」と抵抗していました。
でも、抵抗を超えた先に見えたのは、「人とつながるエンジニア」という新しい自分でした。
この学びは、技術スキルを超えて、働き方そのものを変えてくれました。
未来への展望
これからの自分にとっての課題は、「共感をどうチーム全体に広げるか」です。
自分一人が共感的に設計しても、プロダクト全体がそうでなければユーザーは違和感を覚えてしまう。
だから最近は、チームメンバーと一緒に「エラーメッセージの書き方ガイドライン」を作ったり、レビューのときに「ユーザーの気持ちチェック」を必ず入れるようにしています。
ちょっとした工夫ですが、これをやるだけでチーム全体のアウトプットが変わってきています。
また、将来的には日本のエンジニアにもこの考え方を共有したいと思っています。
日本ではまだ「役割分担の壁」が強い現場も多い。
でも、その壁を少し壊して「ユーザーの気持ちを一緒に考える」文化が広がれば、日本発のプロダクトももっと世界に通用するようになるんじゃないか。
そういう未来を、自分のキャリアを通して実現していきたいと思っています。
コメント