～コードの向こう側にいる「人間」を見失っていませんか？～
要件定義のその先へ：なぜ「完璧な仕様書」だけでは不十分なのか
「仕様通りに作ったのに、使われない」という悪夢
海外のオフィス、窓の外は少し曇り空。僕のデスクには、淹れたてのコーヒーと、3枚のモニターが並んでいます。画面にはVisual Studioが立ち上がり、C#のコードが整然と並んでいる。WPF（Windows Presentation Foundation）を使ったデスクトップアプリケーションの開発は、僕の得意分野であり、情熱を注いでいる仕事です。
でも、正直に告白します。僕にはかつて、**「完璧なゴミ」**を作ってしまった経験があります。
まだ日本にいた頃の話ですが、ある業務システムの刷新プロジェクトに参加しました。分厚い要件定義書、詳細な画面仕様書、完璧なUML図。僕はそれらを聖書のように信じ込み、ロジックの綻びひとつない、美しいコードを書きました。バグもゼロ、パフォーマンステストもクリア。WPFのBindingも完璧で、MVVMパターンに則った、まさに「エンジニアとして誇れる作品」でした。
しかし、リリース当日。
現場のユーザー（経理担当の方々）の反応は、冷ややかなものでした。
「……これ、どうやって前の画面に戻るんですか？」
「マウスをいちいち持ち替えないといけないの？ 前のシステムならEnterキーだけで進めたのに」
「なんか、画面が綺麗すぎて、どこが入力必須かわからないんですけど」
僕は反論したくなりました。「仕様書には戻るボタンなんて書いてなかった」「Enterキーでの遷移はWPFの標準挙動じゃない」「デザインは最新のFluent Designを取り入れたんだ」と。
でも、その時気づいたんです。僕は「仕様書」という「機械への命令書」を満たすことには成功したけれど、「ユーザー」という「人間」の課題を解決することには失敗していたのだ、と。
海外に出て痛感した「行間」のなさ
その後、海外のテック企業に転職して、この問題はさらに複雑になりました。
日本では「行間を読む」とか「阿吽の呼吸」という文化がありますが、海外、特に多国籍なエンジニアチームでは、言語化されていないことは存在しないものとして扱われがちです。英語でのコミュニケーションでは、YesはYes、NoはNo。仕様書に書かれていることが絶対の正義、というスタンスのエンジニアも少なくありません。
ある日、同僚のエンジニア（彼は技術的には非常に優秀です）が、ある入力フォームの実装をしていました。「電話番号の入力欄は数字のみを受け付ける」という仕様に対し、彼は正規表現でガチガチに入力を制限するバリデーションを実装しました。
結果、何が起きたか？
海外のユーザーからクレームの嵐です。「内線番号を入れるためにカッコを使いたい」「国番号のために＋を入れたい」「そもそも覚え書きとしてメモを残したい」……。
彼は言いました。「でも、仕様書には『電話番号（数値）』って書いてあったよ。DBのカラムも数値型だ。僕のコードは間違っていない」と。
確かに、コードは間違っていない。仕様書も（不親切だけど）間違ってはいない。
でも、ソフトウェアとしては大失敗なんです。
ここで必要だったのは、正規表現の知識ではなく、「ユーザーがその入力欄をどういう文脈で使うのか？」を想像する力、つまり**Empathy（共感力）**でした。
なぜ今、エンジニアに「Empathy」が必要なのか
「Empathy（エンパシー）」という言葉、最近テック業界でもよく聞くようになりましたよね。日本語だと「共感」と訳されますが、これは単に「相手の気持ちに寄り添う」とか「優しくする」という感情論ではありません。
エンジニアにおけるEmpathyとは、**「ユーザーのコンテキスト（背景・文脈）を技術的に翻訳する能力」**のことだと僕は定義しています。
特に僕たちが扱っているC#やWPFといった技術スタックは、Webフロントエンドに比べて、より業務に密着した、いわゆる「業務アプリ」や「基幹システム」、あるいは工場の制御端末などで使われることが多いです。ユーザーは、そのソフトを使って毎日8時間、仕事をします。
Webサイトなら、使いにくければ「戻る」ボタンを押して別のサイトに行けばいい。でも、業務アプリはそうはいきません。使いにくいソフトを強制的に使わされるユーザーのストレスは、僕たちが想像する以上です。
- 1クリックの多さが、1日100回の無駄を生むかもしれない。
- 0.5秒のロード時間の遅延が、ユーザーの思考を分断するかもしれない。
- 洗練されたアニメーションが、急いでいるユーザーにはただの邪魔かもしれない。
これらに気づくためには、Requirements Document（要件定義書）の「機能要件（Functional Requirements）」を眺めているだけでは不可能です。そのドキュメントの向こう側にいる、生身の人間の「痛み（Pain Points）」を想像しなければなりません。
「Code Monkey」から「Product Engineer」へ
海外では、ただ仕様書通りにコードを書くだけのエンジニアを揶揄して「Code Monkey（コードモンキー）」と呼ぶことがあります（あまり良い言葉ではありませんが）。
一方で、シリコンバレーや今の僕がいる現場で評価されるのは、**「Product Engineer（プロダクトエンジニア）」**と呼ばれる人々です。彼らは、コードを書く時間と同じくらい、ユーザーの行動観察や、なぜその機能が必要なのかという「Why」の解明に時間を使います。
これから海外を目指すエンジニアの皆さん、あるいは日本でキャリアアップを目指す皆さんに伝えたいのは、「技術力（Hard Skills）」はパスポート（入国許可証）に過ぎないということです。C#が書ける、WPFがわかっている、Azureが使える。それは海外で働くための最低条件です。
そこから一歩抜きん出て、チームに不可欠な存在となり、給与交渉でも強気に出られる（これ大事ですよね笑）エンジニアになるための鍵こそが、この「Empathy」なんです。
「英語がネイティブじゃないから、細かいニュアンスがわからない」と諦める必要はありません。むしろ、言葉の壁があるからこそ、「コード」と「動くソフトウェア」を通じて、ユーザーの意図を汲み取る姿勢が評価されるんです。
「要件定義書」はゴールではなく、スタート地点
では、具体的にどうすればいいのか？
まずマインドセットを変えることから始めましょう。
**「要件定義書は、絶対的な契約書ではなく、対話のための招待状である」**と考えてみてください。
例えば、「一覧画面に検索機能を実装する。検索対象は『氏名』とする」という要件があったとします。
ここで、「よし、LINQで Where(x => x.Name.Contains(keyword)) を書けば終わりだ！」と思考停止してはいけません。
ここでEmpathyを発動させると、次のような疑問が湧いてくるはずです。
- 「ユーザーは『氏名』を正確に覚えているだろうか？ もしかしたら読み仮名で検索したいのでは？」
- 「海外のユーザーなら、First NameとLast Nameの順序を気にするかも？」
- 「毎日何百回も検索するなら、検索ボタンを押させるより、インクリメンタルサーチ（入力と同時に絞り込み）の方が親切では？」
- 「そもそも、彼らが探しているのは『人』なのか、それとも『その人が担当している案件』なのか？」
これらをPM（プロジェクトマネージャー）やデザイナー、あるいは直接ユーザーにぶつけてみてください。「仕様書にないからやらない」ではなく、「ユーザーの成功のために、これが本当にベストか？」を問うのです。
これが、今回のタイトルのサブタイトルにもある “Beyond requirements documents”（要件定義書のその先へ） ということです。
User Stories 2.0：ステークホルダーとエンドユーザーから「真のインサイト」を引き出す技術
Sub: User stories 2.0: Techniques to extract deeper insights from stakeholders and end-users.
「テンプレ通りのユーザーストーリー」が思考停止を生む
アジャイルやスクラム開発の現場で、こんなフォーマットを見たことがありませんか？
As a [ユーザーの役割],
I want [機能],
So that [得られる利益/理由].
これがいわゆる「ユーザーストーリー」の基本形です。例えばこんな感じです。
As a 経理担当者,
I want 月次レポートをExcel出力する機能が欲しい,
So that 毎月の報告会議資料を作成できる.
一見、理にかなっています。開発者はこれを見て、「よし、ClosedXMLかEPPlusを使ってExcel出力機能を実装しよう。ボタンは『Export』でいいな」と作業に入ります。
でも、ちょっと待ってください。
これが**「思考停止の罠」**です。これをそのまま実装するのは、前回の話で言う「Code Monkey」の仕事です。
ここで発揮すべきEmpathy（共感力）は、このストーリーの**「So that（なぜなら）」のさらに奥**に向けられなければなりません。
User Stories 2.0 とは何か？
僕が提唱したい「User Stories 2.0」は、単なる機能要求（What）と表面的な理由（Why）に加えて、**「Context（文脈）」と「Emotion（感情）」、そして「Non-Functional Reality（非機能的な現実）」**をセットにしたものです。
さきほどのExcel出力の例で考えてみましょう。
ユーザーが本当にやりたいこと（ゴール）は「Excelを出力すること」ではありません。「報告会議資料を作ること」ですら、まだ浅い。
ここで、**「The 5 Whys（なぜなぜ分析）」**をカジュアルに行います。詰問調ではなく、興味を持って聞くのです。
- エンジニア: 「このExcel、出力した後は具体的にどう加工するんですか？」
- ユーザー: 「あー、実はこのC列とD列の数字を足して、部署ごとに集計し直して、それをグラフにしてパワポに貼ってるんだよ」
- エンジニア: 「なるほど。それは毎月同じ作業ですか？」
- ユーザー: 「そうなんだよ。手作業だからミスも怖くてね。毎月2時間くらいかかってて、月末の憂鬱の種だよ（Emotion）」
ここで初めて、真の課題が見えました。
彼らが必要なのは「Excelのエクスポート機能」ではなく、「集計済みのグラフが表示されるダッシュボード」、あるいは**「ワンクリックで生成されるPDFレポート」**だったのです。
これが User Stories 2.0 の考え方です。
ユーザーの口から出る「I want（～が欲しい）」は、しばしば**「XY Problem」**（Xという問題を解決したいのに、Yという解決策をねだってしてまう現象）に陥っています。
エンジニアの仕事は、Yを作るのではなく、Xを解決することです。
海外エンジニアの武器「Contextual Inquiry（文脈的調査）」
僕が海外の現場でよくやる（そして評価される）のが、「Contextual Inquiry（文脈的調査）」、もっと平たく言えば**「Shadowing（シャドーイング）」**です。
これは、ユーザーの隣に（物理的に、あるいは画面共有で）座り、彼らが仕事をしている様子をただ観察することです。質問攻めにするのではなく、あくまで「観察」します。
C# WPFで作った在庫管理システムを使っている倉庫スタッフを観察した時のことです。
彼らは画面上の「検索ボタン」を押す前に、必ず手元の紙のリストにペンでチェックを入れ、スキャナーを持ち替えていました。
システム上は「検索ボタンをクリック」というワンアクションですが、現実世界（Context）では「スキャナーを置く → マウスを握る → カーソルを合わせる → クリックする → マウスを離す → スキャナーを持つ」という、非常に高コストな動作を強いられていたのです。
僕はこれを見て、すぐにコードを修正しました。
検索ボックスにフォーカスが当たったら、バーコードリーダーからの入力を自動検知し、エンターキーもクリックも不要で即座に検索を実行、さらに結果が1件なら自動で詳細画面へ遷移するようにしました。
この変更は、要件定義書には載っていません。
でも、ユーザーからは「魔法みたいだ！ 作業が爆速になった！」と感謝されました。
「使われている現場（空気、音、焦り、物理的な制約）」を知ること。 これが最強の要件定義です。
C# WPFエンジニアとしての特権：Rapid Prototyping
ここで技術的な話をしましょう。僕たちWPFエンジニアには、Webエンジニアにはない強力な武器があります。
それは、XAMLによる強力なUI表現力と、Visual Studioのホットリロード機能です。
海外の現場では、議論するより「動くもの」を見せる方が圧倒的に話が早いです。英語が多少下手でも、コードで語ればいい。
僕は要件が曖昧なとき、バックエンドのロジック（ModelやViewModel）は一切作らず、View（XAML）だけで動く「ハリボテ」を猛スピードで作ります。
BlendやDesign Data機能を使って、あたかもデータが入っているかのような画面を30分で作るのです。
そして、ステークホルダーにこう言います。
“I made a rough sketch. Let’s play with it.”（ラフを作ったから、いじってみようぜ）
静止画のモックアップ（Figmaなど）では、「ふーん、いいんじゃない？」で終わってしまいます。
しかし、実際にボタンが押せて、画面遷移する（ように見える）アプリを触らせると、反応が変わります。
- 「あれ、このボタン、ここにあると誤クリックしそうだな」
- 「このリスト、スクロールするとヘッダーが見えなくなるのは困る」
- 「ここでエラーが出た時、どうやってリカバリーすればいいの？」
これらは、「User Stories 2.0」の種です。
開発の終盤で気づいたら「仕様変更」という悪夢になりますが、プロトタイピングの段階で気づけば、それは「価値ある発見」になります。
WPFのデータバインディングやTemplate機能を駆使すれば、この「試行錯誤のループ」を極めて高速に回せます。これはC#エンジニアの大きなアドバンテージです。
「No」と言う勇気、代案を出す誠実さ
最後に、マインドセットの話を。
日本人の美徳として「言われたことはきっちりやる」というものがありますが、海外の開発現場では、**「言われたことしかやらない」のは「怠慢」**と見なされることすらあります。
ステークホルダーがナンセンスな機能を求めてきた時、Empathyがあるからこそ、「No」と言う必要があります。
ただし、単に拒絶するのではなく、「Yes, but…」 あるいは 「How about…」 の精神で。
「その機能（User Story 1.0）を実装することは可能です。でも、あなたの本来の目的（User Story 2.0）を達成するためには、こちらの方法の方が開発コストも安く、ユーザー体験も良くなりますが、どうですか？」
こう提案できるエンジニアは、単なる「実装者」から「パートナー」へと昇格します。
英語に自信がなくても大丈夫。ロジックと「ユーザーを助けたい」という情熱は、必ず伝わります。
次回への架け橋：共感がブレイクスルーを生む瞬間
さて、今回はユーザーの深層心理や文脈を掘り下げるテクニックについてお話ししました。
「要件の裏を読む」「現場を見る」「プロトタイプで対話する」。これらは地道な作業ですが、これを積み重ねた先に、エンジニアとして震えるような瞬間が待っています。
それが、**「The “Aha!” moment（アハ・モーメント）」**です。
点と点がつながり、「これだ！ これこそが彼らが待ち望んでいたものだ！」と確信する瞬間。そして、そのソフトウェアがユーザーの働き方、あるいは人生そのものを劇的に変える瞬間。
次回、【転】のパートでは、僕が実際に体験した事例を交えながら、この「共感力が技術的ブレイクスルーを生んだ具体的なケーススタディ」をご紹介します。
泥臭い調査と対話の先に待っている、エンジニア最高の快感を共有できればと思います。
それでは、また次回の記事で。
Keep coding, keep listening.
アハ・モーメント：共感力がブレイクスルーを生んだ瞬間
Sub: The “Aha!” moment: Examples of how user empathy led to breakthrough software features.
ケーススタディ：ある物流管理システムの「高速化」案件
それは、北米にある中規模の物流会社のシステム改修プロジェクトでのことでした。
彼らが使っていたのは、10年以上前に作られた古いWindows Formsのアプリ。依頼内容は、これを最新の.NETとWPFで刷新し、**「とにかくDataGrid（一覧表）の表示を高速化してくれ」**というものでした。
要件は明確でした。
- 毎日数万件の配送データが発生する。
- 現在のアプリは表示に5秒かかる。これを1秒以内にする。
- 検索とソート、フィルタリングを爆速にする。
技術的には、WPFの「UI Virtualization（仮想化）」を効かせ、非同期処理（async/await）でDBアクセスを裏に回し、データ構造を最適化すれば達成できる数字です。
僕は最初、「楽勝だな」と思いました。C#エンジニアとしての腕の見せ所だと。
しかし、開発に着手する前、僕はマネージャーに頼んで、実際のオペレーションルーム（配車センター）を一日見学させてもらうことにしました。前回お話しした「Contextual Inquiry」の実践です。
現場で見た「カオス」と、違和感の正体
オペレーションルームは、まさに戦場でした。
電話が鳴り止まず、ディスパッチャー（配車担当者）たちは怒号に近い大声でドライバーに指示を出しています。
彼らのデスクには、3つのモニターがあり、そのひとつに例の「遅いアプリ」が表示されていました。
画面には、細かい文字でびっしりと埋め尽くされた巨大なグリッド（表）。
僕は彼らの動きを観察していて、ある奇妙な行動に気づきました。
彼らは、システムがデータをロードし終わると、画面をほとんど見ていなかったのです。
その代わり、手元のホワイトボードに「緊急：ルート4、遅延」などと赤ペンで殴り書きし、それを見て電話をかけていました。
そして時折、アプリの画面に戻っては、Ctrl+F で特定のIDを検索し、詳細を確認しては、またホワイトボードに戻る。
僕は休憩時間に、ベテランの担当者に尋ねました。
「システムが速くなれば、もっと楽になりますか？」
彼は疲れた顔で笑いながらこう言いました。
「速いに越したことはないけどね。結局、この画面は情報が多すぎて、どれが『今すぐ対応しなきゃいけないトラブル』なのか、パッと見てわからないんだよ。 だから自分でホワイトボードに書き出してるんだ」
その瞬間、僕の頭の中で雷が落ちました。**「Aha!（これだ！）」**と。
誤った解決策、真の課題
彼らの課題は「ロード時間が5秒かかること（Performance Issue）」ではありませんでした。
真の課題は、**「認知負荷が高すぎて、意思決定ができないこと（Cognitive Load Issue）」**だったのです。
数万行のグリッドを0.1秒で表示したところで、人間の脳はそれを瞬時に処理できません。
彼らが必要としていたのは、「全てのデータを見ること」ではなく、**「異常（Anomaly）に気づくこと」**でした。
クライアント（IT部門の責任者）は「高速なグリッド」を求めました。
でも、ユーザー（現場の人間）が本当に欲しかったのは、**「静寂と確信」**だったのです。
ブレイクスルー：DataGridを捨てる勇気
翌日、僕はプロトタイプを作り直しました。
こだわりの高速DataGridを、思い切ってメイン画面から削除しました。
その代わりに実装したのは、WPFの表現力を活かした**「ビジュアル・ダッシュボード」**です。
- カード形式のUI:ItemsControlを使い、配送トラックを1つの「カード」として表現。
- 信号機カラー（Traffic Light System）:順調なトラックは「緑」、少し遅れているものは「黄」、トラブル発生中は「赤」で背景色を変化。WPFの DataTrigger を使えば、ViewModelのステータスプロパティが変わるだけで、Viewの色がアニメーション付きで変わります。
- 優先順位付きソート:「赤」のカードが自動的に画面の左上に流れてくるように配置（CollectionViewSourceでソート）。
これを作るのに、高度なアルゴリズムは必要ありませんでした。標準的なMVVMパターンと、少しのXAMLだけです。
「これが欲しかったんだ！」という叫び
デモの日。
従来の「Excelのような表」を期待していたIT責任者は、最初は戸惑った顔をしていました。「グリッドはどこだ？」と。
しかし、同席していた現場のリーダーが、画面を見た瞬間に身を乗り出しました。
「待ってくれ……これ、今トラブルになってる配送が一番上に来てるのか？」
「はい。クリックすれば詳細が出ます。何もなければ、画面は全部緑色になります」と僕が答えると、彼は興奮して叫びました。
「これだ！ これだよ！ 俺たちはこれが欲しかったんだ！ これならホワイトボードはいらない！」
結果として、このシステムは導入され、彼らの業務効率は劇的に改善しました。電話の怒鳴り声は減り、オペレーションルームに「余裕」が生まれました。
ロード時間の短縮なんて、誰も気にしなくなりました（もちろんバックグラウンドで速くはしましたが）。
「Code（コード）」ではなく「Value（価値）」を書く
この経験で僕が得た教訓は強烈でした。
もし僕が、依頼通りに「世界一高速なDataGrid」を作っていたらどうなっていたでしょう？
仕様書通りの完璧な納品物にはなったでしょう。でも、現場の苦しみは消えなかったはずです。
Empathy（共感）とは、ユーザーと同じ景色を見ること。
そして、Engineering（技術）とは、その景色をより良いものに塗り替えること。
「DataGridを速くして」と言われたとき、C#エンジニアとしての僕は「どうやって（How）」を考え始めました。
でも、Empathyを持った僕は「なぜ（Why）」を問いかけ、現場を見ることで「何が（What）」本当に必要なのかを発見しました。
この「視点の転換」こそが、エンジニアとしての価値を何倍にも高めてくれます。
特に海外では、言われた通りに作る作業者は安く買い叩かれますが、**「問題の定義自体を変えてくれるエンジニア」**は、替えの利かないパートナーとしてリスペクトされます。
次回へ：そして「信頼」という資産へ
このプロジェクトの後、クライアントは僕の提案を全面的に信頼してくれるようになりました。
「君がそう言うなら、それが正解なんだろう」と。
技術力でねじ伏せるのではなく、共感力で「正解」を一緒に見つける。
そうやって積み上げた信頼は、フリーランスとしても、会社員としても、海外で生き抜くための最強の武器になります。
さて、長くなりましたが、次回はいよいよ最終回、【結】です。
これまで話してきた「Empathy」を、これから海外を目指す皆さんがどうやって身につけ、キャリア戦略に組み込んでいけばいいのか。
明日から実践できるアクションプランと、エンジニアとしての「生存戦略」についてお話しします。
あなたのコードが、誰かの人生を少しでも良くすることを願って。
See you in the next post!
エンジニアの生存戦略としての「Empathy」
Sub: Future-proofing your career with human-centric engineering.
AI時代における「エンジニアの価値」の再定義
最近、GitHub CopilotやChatGPTの進化には目を見張るものがありますよね。
僕も毎日使っていますが、正直、定型的なViewModelのボイラープレートコードや、単純なLINQクエリを書かせたら、僕より彼らの方が速くて正確です。
「コードを書くこと」自体の市場価値は、間違いなく下がっていきます。
「仕様書通りに動くプログラムを作る」だけなら、遠くない未来、AIがその大部分を担うことになるでしょう。
では、僕たち人間のエンジニアは不要になるのでしょうか？
答えは「No」です。ただし、「あり方」を変えなければ生き残れません。
AIは、過去のデータから最適解を出すことは得意ですが、「まだ言語化されていない人間の痛み」を感じ取ることはできません。
前回の事例で話した、「現場の担当者がホワイトボードに手書きしている理由」を、AIが勝手に察してくれることはないのです。
その「痛み」や「違和感」を現場で感じ取り、それを技術的な課題（Problem Definition）へと翻訳する力。
これこそが、AIに代替できない、人間だけの聖域（サンクチュアリ）です。
Empathyこそが、これからのエンジニアにとって最強の「生存戦略」なのです。
「英語力」以上に必要な「人間力」
海外で働きたいと思っている方から、よく「英語が不安です」という相談を受けます。
もちろん英語は大事です。でも、もっと大事なのは**「相手に関心を持つこと」**です。
僕の周りにも、英語はペラペラだけど、自分の技術自慢ばかりしてユーザーの話を聞かないエンジニアがいます。彼は残念ながら、チーム内での評価は高くありません。
一方で、文法はめちゃくちゃでも、「君の今の作業、ここが面倒くさそうだね。僕が直してあげようか？」と片言で話しかけ、泥臭く課題を解決するエンジニアは、ヒーローのように扱われます。
海外、特に多文化が入り混じる環境では、言葉の裏にある文脈（コンテキスト）が共有されていません。
だからこそ、「相手は何を考えているのか？」「どういう背景でこれを言っているのか？」を想像するEmpathyのスキルが、コミュニケーションの潤滑油として機能します。
技術力（C#やWPFのスキル）は、あなたをその場（海外の職場）に連れて行ってくれる**「パスポート」です。
しかし、そこで信頼を勝ち取り、長く活躍し続けるための「永住権（グリーンカード）」**となるのは、間違いなくEmpathyです。
明日からできる「Empathy Driven Development」
では、具体的に明日から何を始めればいいのか。
壮大なことをする必要はありません。日々の開発プロセスに、少しだけ「人間」を混ぜるだけです。
- 画面の向こうの「一人」を想像する不特定多数の「ユーザー」という記号で処理せず、「経理のサラさん」や「倉庫のボブさん」を思い浮かべてください。「サラさんは老眼気味だと言っていたから、フォントサイズはこのままでいいか？」「ボブさんは手袋をして操作するから、このボタン配置だと押し間違えるのでは？」その想像力が、UI/UXの質を劇的に変えます。
- エラーメッセージに愛を込める「予期せぬエラーが発生しました（Exception: NullReference）」これを見て、ユーザーはどう思うでしょうか？ 不安と苛立ちしかありませんよね。「データの読み込みに失敗しました。ネットワークを確認して、もう一度『更新』ボタンを押してみてください」これなら、ユーザーは次にすべき行動がわかります。例外処理（Try-Catch）は、プログラムを守るためだけでなく、ユーザーの心をパニックから守るために書くものです。
- 「未来の自分」と「チームメイト」へのEmpathyEmpathyはユーザーに対してだけのものではありません。3ヶ月後の自分、あるいはあなたのコードを引き継ぐチームメイトに対しても同じです。「この変な条件分岐、なんで書いたんだっけ？」とならないように、コメントに「Why（意図）」を残す。読みやすい変数名をつける。ドキュメントを整備する。これらは全て、**「次にこのコードを読む人間」への思いやり（Empathy）**です。「きれいなコード（Clean Code）」とは、すなわち「思いやりのあるコード」のことなのです。
日本のエンジニアが持つ「最強のポテンシャル」
最後に、日本のエンジニアの皆さんに伝えたいことがあります。
僕は海外に出て気づきましたが、日本人が持っている「おもてなし」や「気配り」の精神は、世界最強レベルのEmpathyスキルです。
「言われなくても察する」「相手が不快にならないように配慮する」。
これらは日本では当たり前すぎてスキルだと思われていませんが、海外では**「User Experience（UX）への驚異的な感度」**として称賛されます。
ただ、日本にいると、その能力が「社内政治」や「過剰な忖度」に使われてしまいがちです。
そのベクトルを、上司の顔色ではなく、**「エンドユーザーの幸せ」**に向けてみてください。
そして、その気配りを、C#というロジカルな武器を使って、動くソフトウェアとして具現化してください。
そうすれば、あなたは日本国内だけでなく、世界のどこに行っても必要とされるエンジニアになれるはずです。
結び：ソフトウェアは、人と人をつなぐ手紙である
全4回、「Empathy in Action」にお付き合いいただき、ありがとうございました。
僕たちは毎日、モニターに向かい、キーボードを叩いています。
扱っているのは0と1のデジタルな世界です。
でも、忘れないでください。その0と1の積み重ねの先には、必ず生身の人間がいます。
誰かが仕事を早く終わらせて、家族と夕食を食べる時間を増やすために。
誰かが煩雑な作業から解放されて、もっとクリエイティブな仕事に集中できるように。
僕たちが書くコードは、彼らへの**「手紙」**のようなものです。
技術力というペンを使って、Empathyというインクで、最高のラブレターを書きましょう。
僕もまだまだ修行中の身です。遠い空の下、WPFのXAMLと格闘しながら、今日もユーザーのために頭を悩ませています。
もし、世界のどこかの現場で、同じようにユーザーのために奮闘するあなたと出会えたら、その時はぜひ、美味しいコーヒーでも飲みながら語り合いましょう。
Keep coding, stay human.
あなたのエンジニアライフが、実り多きものになりますように。
コメント