「Ever felt like your code understands users better than you do?」
──最初にこの問いを読んだとき、僕は思わず笑ってしまいました。なぜなら、まさにそれが自分自身の姿だったからです。
C# WPFを使って海外でUI設計をしていた頃。画面上のボタン配置や入力チェックは、コードに落とし込めば正確に動きます。ユーザーが不正なデータを入れればエラーメッセージを出す。ログに記録して、再現性を検証する。ロジックは僕の指示どおり、誤りなく実行してくれる。まるで「ユーザーを理解している」のはプログラムの方で、僕自身はただそれを操作する技術者に過ぎない。そんな感覚でした。
でも実際のプロジェクトは、単純に「正しく動けばOK」では終わりません。たとえば、ある海外プロジェクトで現地のエンドユーザーとレビューをしたときのこと。僕は自信満々で画面をデモしました。バリデーションも完璧、動作も軽快。けれどユーザーから返ってきた言葉はこうでした。
「この画面だと、私たちの実際の業務フローに合わない。入力順序が逆で、現場ではとても使いづらい」
衝撃でした。
コードは完璧に動いているのに、使う人にとっては不便。つまり、「ユーザーを理解していなかった」のは僕の方だったんです。
ここで感じたのは、エンジニアとしての「論理的思考」と、ユーザー視点の「共感力」とのギャップです。僕たちは普段、要件定義や設計ドキュメントに書かれた仕様を忠実に守ることに集中します。テストケースを網羅して、例外処理を潰して、システムが壊れないようにする。それが僕たちの仕事だと信じて疑いません。
でも海外で働くようになってからは、その「信念」がよく揺さぶられる瞬間が増えました。文化の違いや業務プロセスの違いから、「正しいコード」より「使いやすさ」が優先される場面が本当に多いんです。
たとえば日本では、多少の不便さも「マニュアルを読めば理解できる」で済まされることがあります。でも海外では違う。ユーザーは「直感的じゃないならNG」とストレートに言ってきます。僕は最初、そのフィードバックにショックを受けました。だって、僕は「ちゃんと仕様どおりに作った」のに。
その経験をきっかけに、僕は次第に「コードの正しさ」だけでなく「ユーザーの気持ち」をどう理解するかを考えるようになりました。けれど、それは決して簡単なことではありません。なぜなら僕の頭の中には、常に「内なる批判者」がいたからです。
「ユーザーの立場に立つ？そんなの曖昧だろ」
「まずは仕様書を守れ。それが一番確実だ」
「余計なことを考えると、バグを生むぞ」
こんな声が頭の中で響くんです。エンジニアとしての訓練の中で、「論理こそが最優先」という価値観が染み付いていたんでしょう。でもその声に従ってばかりいると、結果的に「ユーザーに寄り添えないプロダクト」を生み出してしまう。これが僕の海外での痛い学びでした。
この「コードはユーザーを理解しているのに、自分は理解していない」矛盾をどう乗り越えるか──。ここから先が僕の挑戦であり、同時に海外で働くエンジニアとして避けて通れないテーマでした。
「論理は正しいのに、現場では使えない？」
海外で働き始めて数か月が経った頃、あるWPFアプリケーションの開発を担当しました。業務システムで、現場スタッフが毎日数百件の入力を行う画面。日本での経験を活かし、僕は「効率的で堅牢なUI」を目指しました。
たとえば入力欄には徹底したバリデーションを設け、必須項目は赤枠で警告。タブキーでスムーズに移動できるように設計し、フォーカスの制御も細かくチューニング。さらに、エラー時にはポップアップでユーザーに丁寧に説明する。
「これなら使いやすいはずだ」と自信満々でした。
しかしユーザーテストの日、現場スタッフの第一声はこうでした。
「エラーポップアップが出すぎて作業が止まる。入力しながら直せるようにしてほしい」
「タブ順序は仕様どおりだけど、実際の作業の流れと違う。逆に手間が増える」
僕は正直、ショックでした。仕様書に沿って作り、コードも最適化し、UIのベストプラクティスを意識したのに──「使えない」と言われる。
その瞬間、僕の頭の中では「論理的に正しい自分」と「現場の声」が真っ向から衝突しました。
エンジニア脳ではこう考えます。
- エラーを早く出すほど品質は高い
- 仕様通りに作るのが正義
- 操作フローは論理的に最短であるべき
でも現場スタッフの声は違います。
- 入力を止められると作業が途切れてストレス
- 仕様より実務フローの方が大事
- 論理的な最短経路より「手が覚えている順序」が重要
このギャップを目の前にしたとき、僕は初めて「共感力」という言葉の意味を実感しました。
「共感力なんてエンジニアに必要？」
正直に言うと、最初は共感力を軽視していました。だってエンジニアの評価は「バグの少なさ」や「パフォーマンスの高さ」で決まると思っていたから。ユーザーの感情や習慣なんて、主観的で測定できないし、設計書にも書かれていない。
でも海外チームで働いていると、それが通用しない。レビューの場では、現場スタッフだけでなくプロダクトマネージャーやUXデザイナーも加わります。そして彼らは口をそろえて言うんです。
「ユーザーはロジックの正しさじゃなく、使いやすさで判断する」
その言葉を聞いたとき、僕の中で一つの気づきがありました。
「コードは仕様を守るけど、ユーザーは仕様を守らない」 という事実です。
エンジニアとしては「仕様がすべて」だと思い込みがち。でも実際には、ユーザーは自分のやりやすいように使おうとする。だからこそ、仕様に縛られたロジックだけでは足りない。ユーザーが直感的に感じる「楽さ」や「自然さ」を理解する必要があるんです。
「文化の違いが突きつけたもの」
さらに海外ならではの壁もありました。たとえば僕が参加したプロジェクトでは、ユーザーは欧州のオフィススタッフ。彼らの作業スタイルは、日本の職場とまるで違います。
日本では「とにかく間違えないこと」が重視されます。だからエラーチェックを厳しくしても「まあ仕方ない」と受け入れられる。
一方で欧州のスタッフは「とにかくスピードが大事」。もし間違えても後で修正すればいいという文化でした。だからこそ、僕が作った「即エラーで止めるUI」は嫌われたんです。
このとき僕は、ただ技術的な正しさだけでなく、文化的背景や価値観まで理解しないと本当に使えるシステムは作れないと痛感しました。
「ユーザーインタビューの洗礼」
ある日、プロダクトマネージャーにこう言われました。
「hiro、明日のユーザーインタビューに出てくれない？」
正直、怖かったです。英語での会話に自信がなかったし、そもそもエンジニアが直接ユーザーと話す経験なんてほとんどなかった。
でも参加してみて、考え方が大きく変わりました。
ユーザーの声は予想以上に具体的でした。
- 「午前中は電話対応しながら入力するから、片手操作が多い」
- 「エラーポップアップは後でまとめて見たい」
- 「色分けは赤より黄色がいい。赤だと『自分がミスした』と責められてる気分になる」
僕はそこで初めて、「ああ、こういう細かいことが使いやすさにつながるんだ」と理解しました。コードには書かれていない、仕様書にもない。けれど確かに存在する「人間らしさ」。それを聞いたとき、自分の中の「論理優先主義」が少しずつ揺らぎ始めたのです。
「エンジニアの仕事は仕様を超える」
こうして僕は少しずつ、「コードの正しさ」だけでなく「人間の使いやすさ」に目を向けるようになりました。もちろん最初は戸惑いました。「そんな曖昧なこと、どう設計に落とし込むんだ？」と頭を抱えました。でも実際には、共感力をコードに翻訳する方法はいくつもあるんです。
たとえば：
- エラーを強制停止ではなく、入力後にまとめて提示する
- タブ順序を業務フローに合わせてカスタマイズする
- 色やメッセージ表現を文化的背景に合わせる
小さな工夫だけど、ユーザーからのフィードバックは劇的に変わりました。
この経験を通じて、僕は「論理だけでなく共感を設計に組み込むこと」の大切さを学びました。そして何より、海外で働くエンジニアには、その柔軟性が欠かせないと強く感じたのです。
「論理 vs 共感」のせめぎ合い
ユーザーインタビューを重ねる中で、「論理的な正しさ」と「ユーザーの感覚」の両立がどれほど難しいかを痛感しました。頭では「共感力が必要だ」と分かっていても、コードを書く段になると、どうしても「仕様通りに動かすこと」に引っ張られてしまうんです。
そのたびに内なる声が響きます。
「余計なことをすると、バグの温床になる」
「ユーザーの感覚なんて曖昧だ。コードは明確じゃないか」
「論理を犠牲にするなんて、エンジニア失格だ」
まるで心の中にもう一人の自分がいて、ひたすら冷徹にダメ出ししてくる。僕はこれを「内なる批判者」と呼んでいます。
でも不思議なことに、海外チームではこの声に真っ向から反論する人たちがいました。UXデザイナーやプロダクトマネージャーです。
彼らはよくこう言います。
「バグは直せる。でも不便な体験は、ユーザーが去ったらもう直せない」
その言葉にハッとしました。僕が恐れていたのは「論理を崩すこと」だったけれど、彼らが恐れているのは「ユーザーを失うこと」。つまり見ているリスクの種類がまったく違うんです。
チームで「共感」を育てる
あるとき、僕がUIの仕様を「仕様書どおりに」実装しようとしたら、デザイナーがこう言いました。
「hiro、ちょっと一緒に現場のフローを見に行こうよ」
彼に連れられてオフィスに行くと、ユーザーが実際にアプリを使っている場面を観察できました。電話を片手に受けながら、もう一方の手で入力をしている。メモを見ながら同僚に指示を出しつつ、画面に数字を打ち込む。
その光景を見て、僕は衝撃を受けました。
「机に座って両手で落ち着いて入力する」という僕の想定が、完全にズレていたんです。
そのとき初めて「共感」は一人で生み出すものじゃなく、チームで観察し、議論し、翻訳していくものだと理解しました。
小さな実験を重ねる
ただ、頭で分かっても「どうコードに落とすか」が難しい。そこで僕は、思い切って小さな実験を始めました。
- エラー表示をリアルタイムではなく、入力完了後にまとめて提示
- ポップアップをやめて、画面下部に非侵入型のメッセージを表示
- 文化に合わせて色やアイコンを変更
最初は「これでバグが増えるんじゃないか」と不安でいっぱいでした。でも勇気を出してユーザーに見せたら、予想以上に好評でした。
「これなら作業が止まらない」
「赤より黄色の方が安心する」
その反応を聞いた瞬間、僕の中の「内なる批判者」が少し黙りました。
「批判者」との付き合い方
ここで気づいたのは、内なる批判者を「消そう」とする必要はないということです。彼は常に「論理的な正しさ」を守ろうとしている。つまり敵ではなく、ただ極端に偏っているだけ。
そこで僕はこう考えるようになりました。
- 批判者の声をまず聞く（リスクや不安を洗い出す）
- その上でチームと議論し、ユーザー視点で調整する
- 実験して、結果で確かめる
こうすると、不思議と批判者の声は「安全装置」として機能するんです。盲目的にユーザー要望を取り込むのではなく、「リスクはここにあるけど、この形なら大丈夫だ」と冷静に判断できる。
「論理と共感の二刀流」
こうした試行錯誤を経て、僕は少しずつ「論理と共感の二刀流」で開発できるようになっていきました。
具体的には：
- コードを書く前に、ユーザーストーリーを自分の言葉で言い換える
- 実装中に「この仕様は誰にとって便利？」と自問する
- レビューでは「バグがないか」だけでなく「直感的か」をチームに確認する
結果として、以前よりもレビューがスムーズになり、ユーザーからのフィードバックもポジティブなものが増えました。何より僕自身が「仕様を守るために戦う」から「ユーザーに喜ばれるために工夫する」へと意識が変わっていきました。
振り返り
こうして振り返ると、「論理」と「共感」はどちらも大切で、片方だけでは成り立たないと分かります。論理がなければシステムは壊れるし、共感がなければ誰も使わない。
海外で働く中で、僕は「論理に偏ったエンジニア脳」を揺さぶられ、共感の重要性を体で覚えました。そして内なる批判者との対話を通じて、両方をバランスよく取り入れる方法を少しずつ掴んできたのです。
「正しさ」だけじゃ届かない世界
僕が海外で働いて最初に痛感したのは、エンジニアとしての「正しさ」だけではユーザーに届かないということでした。
論理的に正しく、仕様通りに動いていても、使う人が「不便だ」と感じれば、それは失敗作になる。
逆に言えば、多少コードが複雑になっても、ユーザーが「これなら楽だ」と感じてくれるなら、それは価値のあるシステムになる。日本にいた頃は気づかなかったこの事実を、海外でのプロジェクトが容赦なく突きつけてきました。
「共感力」は才能じゃなくスキル
最初の僕は、「共感力なんて自分にはない」と思っていました。だって僕はエンジニアで、論理や数値で物事を考えるのが得意なタイプだから。人の気持ちを察するなんて、どちらかといえば苦手分野。
でも実際には、共感力は「生まれつきの才能」ではなく「身につけられるスキル」だと気づきました。方法はシンプルで、ユーザーに会う・観察する・話を聞く。それだけで見える世界が変わるんです。
- ユーザーの机の上に置かれた大量のメモ用紙
- 入力フォームを操作するときのため息
- 色の使い方ひとつで変わる表情
そうした小さな観察が積み重なって、「この人たちにとって便利とは何か」が分かってくる。つまり共感力は、観察と対話を繰り返す中で磨かれていくスキルなんです。
「内なる批判者」との付き合い方
もちろん今でも、僕の中には「論理を最優先せよ」と叫ぶ内なる批判者がいます。でも海外での経験を経て、その声を「抑えるべき敵」ではなく「相談相手」として扱えるようになりました。
- 批判者はリスクを見つけるのが得意
- 自分はユーザー体験を大事にしたい
- 両者をぶつけて、バランスをとる
このプロセスを繰り返すことで、論理と共感を両立する設計ができるようになった気がします。
これから海外で働くエンジニアへ
ここまで僕の体験を話してきましたが、これを読んでいるあなたがもし「海外でエンジニアとして働きたい」と思っているなら、伝えたいことはひとつです。
👉 「論理の正しさ」と同じくらい、「人の気持ち」にも耳を傾けてほしい。
海外では特に、「正しいけど不便なシステム」は容赦なく拒否されます。逆に、「ちょっと仕様書から外れてても直感的に使えるシステム」は歓迎されます。
だからこそ、これから海外で働くエンジニアにおすすめしたい実践的なポイントをまとめます。
1. ユーザーに会う勇気を持つ
英語が不安でも大丈夫。たとえ片言でも、ユーザーに直接質問したり観察することで得られる学びは大きい。
2. チームメイトを頼る
UXデザイナーやプロダクトマネージャーは「共感の専門家」。彼らと一緒に動くことで、エンジニア脳の限界を補える。
3. 小さな実験をする
いきなり大改革しなくても、UIの色を変える、エラー表示のタイミングを調整する、といった小さな改善でも効果は大きい。
4. 内なる批判者を無視しない
不安や反論は貴重なチェックポイント。頭の中で対話しながら、ユーザー視点とバランスをとる。
僕自身の変化
こうして書きながら思い返すと、昔の僕は「コードは完璧に動くのに、ユーザーには響かない」という矛盾に苦しんでいました。
でも今は違います。コードが正しく動いたときの喜びももちろんあるけれど、ユーザーが笑顔で「これ、使いやすいよ」と言ってくれる瞬間の方がずっと大きなやりがいになっています。
そして気づいたんです。
「コードはユーザーを理解しているのに、自分は理解していなかった」過去の僕を、少しずつアップデートできていると。
まとめ
海外で働くエンジニアにとって、必要なのは「論理を突き詰める力」と「人に寄り添う力」。どちらか一方だけでは片手落ちです。
そしてそれを学ぶ一番の近道は、失敗すること、ユーザーに怒られること、文化の違いに戸惑うこと。僕はそれを何度も経験し、そのたびにエンジニアとしての幅を広げてきました。
これを読んでいるあなたも、もし「論理と共感のバランス」に悩む日が来たら思い出してほしい。
コードの正しさは大事。でも、それを使う人の気持ちを理解できたとき、あなたの作るプロダクトは本当に生きる。
それが、僕が海外で学んだ一番大きな教訓です。
コメント