コードだけ書いていればいい時代の終わり 〜From Code to Concept〜
海外の現場で最初に浴びた洗礼
やあ、みんな。今日もVisual Studioとお友達かな？
日本を飛び出して、ここ海外のオフィスでC#やWPFと格闘する日々を送っている現役エンジニアだ。こっちのコーヒーは妙にサイズがでかいし、会議はエキサイティングすぎて喧嘩に見えることもあるけれど、まあなんとか生き残っているよ。
今日は、これから海外で働きたいと思っている君たち、あるいは今まさに技術の壁にぶつかって悩んでいる君たちに、どうしても伝えておきたい「ある思考法」についての話をしようと思う。
単刀直入に言うよ。「仕様書通りに完璧なコードを書く能力」だけじゃ、海外では通用しない。
いや、誤解しないでほしい。もちろん技術力は必須だ。MVVMパターンを理解していなきゃ話にならないし、非同期処理でUIをフリーズさせるようなエンジニアは即退場だ。でもね、それらはあくまで「入場チケット」に過ぎないんだよ。
僕がこっちに来て最初に浴びた洗礼は、技術不足への指摘じゃなかった。「Why（なぜ）？」の嵐だったんだ。
ある日、マネージャーから新機能の実装を頼まれた。僕は日本にいた時と同じように、要求された機能を完璧に、バグなく、WPFのBindingも美しく決めて実装した。自信満々でレビューに出したんだ。「どうだ、この疎結合な設計は美しいだろう？」ってね。
でも、返ってきた言葉は衝撃的だった。
「オーケー、コードは動くね。でも、これを使ってユーザーは具体的にどうやって幸せになるんだ？ このUIフローだと、ユーザーは3回もクリックしなきゃいけない。君はこれを『解決策』だと本気で思っているのか？」
頭をガツンと殴られたような気がしたよ。僕は「機能（Code）」を作っていたけれど、「概念（Concept）」や「解決策（Solution）」を作っていなかったんだ。
「言われた通り」が評価されない残酷な世界
日本での開発現場、特にSIerのような環境だと、詳細な設計書があって、その通りに実装することが「正義」とされることが多いよね。「行間を読む」文化もあるけれど、基本的にはスペックありきだ。
でも海外、特にイノベーションが求められる現場やプロダクト開発の現場では、エンジニアも「クリエイター」であることが求められる。
「仕様書に書いてあったから」なんて言い訳は、幼稚園児の「ママが言ったから」と同じレベルに聞こえるらしい（本当にそう言われたことがある）。
ここで働くエンジニアたちは、平気でデザイナーやプロダクトマネージャーに噛み付く。「この機能はユーザーにとって使いにくい」「この実装コストをかけるなら、別の方法で価値を提供すべきだ」ってね。彼らはコードを書く前に、徹底的に**「何を作るべきか」**を議論している。
僕は最初、それに戸惑った。「早く仕様を決めてくれよ、コードが書けないじゃないか」ってイライラしていた。
でも、ある時気づいたんだ。彼らが持っているのは、単なる自己主張の強さじゃない。問題を解決するための体系的なアプローチ、共通言語としての**「デザイン思考（Design Thinking）」**を持っているんだってことに。
「デザイン思考」はデザイナーのもの？ 大きな勘違い
「デザイン思考」って聞くと、どんなイメージを持つ？
おしゃれなUIを作ること？ 色彩理論？ センスのいいスライドを作ること？
もしそう思っているなら、君は過去の僕と同じ間違いをしている。そして、非常にもったいない損をしていると言わざるを得ない。
デザイン思考とは、**「デザイナーがデザインを行う際の思考プロセスを、ビジネスや技術の問題解決に活用するフレームワーク」のことだ。
もっと平たく言えば、「不確実で複雑な問題を、人間中心（ユーザー中心）のアプローチで解決するための思考の型」**だと言える。
これはデザイナーだけのものじゃない。むしろ、論理的思考（ロジカルシンキング）が得意なエンジニアこそ、この「デザイン思考」という武器を装備することで、最強のソルジャーになれるんだ。
僕たちエンジニアは、放っておくとすぐに「How（どうやって実装するか）」に意識が向いてしまう生き物だ。「WPFのDataTemplateをどう切り替えるか」「Prismを使ってどうモジュール化するか」。もちろんそれは大事だ。大好きだ。
でも、その前に「What（何を作るか）」そして「Why（なぜ作るか）」が間違っていたら？
どんなに美しいコードで実装された機能も、誰も使わないならただの「デジタルゴミ」だ。
海外の現場では、この「デジタルゴミ」を生産する罪は重い。だからこそ、僕たちはコードを書く手前の段階、つまり「Concept」を作る段階から参画する必要がある。そこで輝くのがデザイン思考なんだ。
イノベーションへの構造化されたアプローチ
僕がこのブログで伝えたいメインテーマ、「From Code to Concept: The Design Thinking Revolution（コードからコンセプトへ：デザイン思考革命）」の話に入ろう。
デザイン思考は、決して「ひらめき」や「センス」に頼るものではない。ここがエンジニアにとっての朗報だ。これは**「構造化されたアプローチ」**なんだ。僕たちがアルゴリズムを学ぶように、デザイン思考もステップ・バイ・ステップで学ぶことができる。
僕はこの思考法を学んでから、仕事のやり方が劇的に変わった。
以前は、「この画面にボタンを追加して」と言われたら、即座にXAMLを書き始めていた。
今は違う。「なぜそのボタンが必要なの？ ユーザーはその時どんな感情なの？ そのボタンを押した後、何が起きることを期待しているの？」と問いかけるようになった。
そして驚くことに、そうやって問いかけるエンジニアのほうが、海外では圧倒的に信頼されるし、評価されるんだ。
「あいつはただのコーダーじゃない。プロダクトのことを考えているパートナーだ」と認識されるからだ。
英語の壁？ もちろんある。でもね、ロジックとフレームワークがあれば、拙い英語でも議論はできる。「I think…」で詰まるんじゃなくて、「Based on the user’s pain point…（ユーザーの痛みに基づくと…）」と語り出せるようになる。デザイン思考は、言語の壁を超える共通プロトコルにもなり得るんだ。
魔法なんてない。「デザイン思考」という名の5段階の冒険の書
デザイン思考は「アルゴリズム」である
前回、僕は「仕様書通りのコードを書くだけでは、海外では生き残れない」という少し厳しい現実を話した。そして、その解決策として「デザイン思考」を提示したわけだけど、ここで多くのエンジニアがアレルギー反応を起こすんだ。
「おいおい、俺は左脳で生きるロジカルモンスターだぞ。デザイナーの『感性』とか『アート』みたいなふわっとした話は苦手なんだよ」
わかる。すごくわかるよ。僕もかつては、XAMLのグリッド定義に1ピクセルのズレがあるだけで発狂しそうになるタイプの人間だったからね。
でも、安心してほしい。デザイン思考は「アート（芸術）」ではない。これは「アルゴリズム」だ。
僕たちが普段、複雑な業務ロジックをクラスやメソッドに分割して処理するように、デザイン思考は「イノベーション」という巨大で掴みどころのない怪物を、処理可能な5つのサブルーチンに分割するフレームワークなんだ。
入力（ユーザーの課題）があり、処理（5つのフェーズ）があり、出力（解決策）がある。そう考えると、急に親近感が湧いてこないかい？
スタンフォード大学のd.schoolが提唱する、この有名な5つのフェーズ（Empathize, Define, Ideate, Prototype, Test）。これを僕らエンジニアの言葉に「超訳」しながら、その攻略法を見ていこう。
Phase 1: Empathize（共感）
〜ユーザーのデバッグログを脳内にダウンロードせよ〜
最初のステップは「共感」だ。
従来の開発フローだと、ここは「要件定義書の読み込み」に当たるかもしれない。でも、デザイン思考におけるEmpathizeはもっと泥臭く、もっと深い。
エンジニアは往々にして、ユーザーを「システムへの入力装置」として見がちだ。「ユーザーがボタンを押すと、イベントが発火する」。これだけの関係性だと思っている。
でも、海外の現場で求められるのは**「ユーザーという不安定なシステムの状態（State）を把握すること」**だ。
例えば、ある業務アプリの開発で、僕は現場のオペレーターの後ろに立って観察したことがある（これを「シャドーイング」と呼ぶ）。
彼らは僕が完璧に設計したWPFのデータグリッドを使っていたが、データを入力するたびに、なぜか手元の古いノートに同じ数字をメモしていたんだ。
「なんで二度手間なことを？」と聞くと、彼は「このシステム、たまにフリーズするでしょ？ その時にデータが消えるのが怖いから」と答えた。
ショックだったよ。僕のコードは例外処理（try-catch）を完璧に書いていたつもりだったけど、ユーザーの「恐怖（Fear）」という例外はキャッチできていなかったんだ。
ここですべきは、仕様を確認することじゃない。ユーザーが何を見て、何を感じ、どこで躓き、なぜため息をついたのか。その「感情のログ」を収集することだ。
エンジニア的に言えば、「クラッシュダンプの解析」ではなく、「ユーザーの感情プロファイリング」を行うフェーズだと思ってくれ。
Phase 2: Define（定義）
〜真に解くべき「バグ」を特定せよ〜
十分な「共感」を得たら、次は情報の洪水を整理して、問題を定義するフェーズだ。
ここで多くのエンジニアがやりがちなミスがある。それは**「手段（Solution）」を問題定義にしてしまうこと**だ。
× ダメな例：「検索機能が遅いから、インデックスを貼って高速化する必要がある」
○ 良い例：「ユーザーは顧客からの電話中に情報を探せず、3分間も客を待たせてストレスを感じている」
前者は「技術的な課題」だけど、後者は「人間中心の課題」だ。
前者の定義だと、解決策は「SQLチューニング」一択になる。でも後者の定義なら、「検索を速くする」以外にも、「直近の履歴を表示する」「よく使う項目をダッシュボードに出す」など、無数の解決策（メソッド）が考えられる。
このフェーズは、クラス設計における**「インターフェース（Interface）の定義」**に似ている。
IUserHappiness というインターフェースをどう定義するか。ここで定義を間違えると、その後の実装（Ideate以降）はすべて無駄になる。
海外のチームでは、この「Define」の文言一つを決めるのに、ホワイトボードの前で何時間も激論を交わす。「それは本当のペイン（痛み）なのか？」「ただの表面的な症状じゃないのか？」とね。
ここで「真因（Root Cause）」を特定できるかどうかが、エンジニアとしての洞察力を試される瞬間だ。
Phase 3: Ideate（概念化）
〜メモリリークを恐れず、アイデアをオーバーフローさせろ〜
問題を定義したら、解決策を出す。ブレインストーミングの時間だ。
ここで日本のエンジニア（僕を含め）が陥りやすい罠がある。それは、「実装可能性フィルター」を最初からオンにしてしまうことだ。
誰かが「AIで自動判別させよう」と言った瞬間、君の脳内でコンパイラが走り出す。
「いや、学習データがない」「Azureのコストがかかる」「レイテンシが許容できない」……そして口を開く。「それは技術的に難しいですね」。
今すぐそのコンパイラを切れ。
このフェーズでは、エラーチェックは不要だ。どんなに荒唐無稽でも、バカバカしくてもいい。質より量（Quantity over Quality）。
GC（ガベージコレクション）は後でやればいい。今はとにかくヒープ領域がパンクするまでアイデアを出し続けるんだ。
僕の同僚のシニアエンジニアなんて、「キーボードを使わずに念力で入力できたら最高じゃない？」なんて真顔で言い出す。
でも、そこから「じゃあ音声入力は？」「視線入力は？」「ショートカットの最適化は？」と、現実的な解が降りてくる。
「No（でも無理）」ではなく「Yes, and（いいね、さらに言えば）」で乗っかる。この即興演奏（ジャムセッション）のような感覚を楽しめるようになると、チーム内での君の立ち位置はガラリと変わるはずだ。
Phase 4: Prototype（試作）
〜コンパイル不要。ハリボテで未来を騙れ〜
さあ、ここがC#エンジニアにとって最大のパラダイムシフトだ。
「プロトタイプを作ろう」と言われたら、君は何をする？
Visual Studioを立ち上げ、MVVMのフォルダー構成を作り、NuGetパッケージを復元し始める？
ストップ。それじゃ遅すぎる。
デザイン思考におけるプロトタイプは、「動くソフトウェア」である必要すらない。
紙にペンで書いた画面遷移図（ペーパープロトタイプ）、PowerPointでボタンだけ動くようにした紙芝居、あるいはFigmaで作ったモックアップ。これで十分なんだ。
エンジニアは「動かないもの」を見せるのを恥ずかしがる。「バックエンドが繋がってないんで…」と言い訳したくなる。
でも、ここで検証したいのは「DB接続が正常か」ではなく「この解決策でユーザーが喜ぶか」だ。
僕はある時、複雑なWPFコントロールを作る前に、付箋紙を何枚も重ねて「こういう動きをするメニュー」を再現し、マネージャーに見せたことがある。
コードは1行も書いていない。制作時間10分。
でも、それで十分議論ができた。「あ、これだと指が届かないね」「ここは隠れちゃダメだね」。
もしこれをXAMLで実装していたら、修正に3日はかかっていただろう。
「Fail Fast（早く失敗せよ）」。
これがシリコンバレーの鉄則だ。時間をかけて完璧なゴミを作るより、10分で作ったゴミを捨てて、次の10分でマシなゴミを作るほうが、正解への到達は早い。
コードを書くのは、本当に最後の最後でいいんだ。
Phase 5: Test（テスト）
〜単体テストじゃない。エゴの破壊テストだ〜
最後はテスト。もちろん、NUnitやxUnitの話じゃない。ユーザーテストだ。
プロトタイプを実際のユーザー（あるいはターゲットに近い人）に触らせて、反応を見る。
ここで重要なのは、「説明しないこと」。
「ここはこうやって操作するんですよ」と言いたくなる気持ちをぐっと堪えて、ただ観察する。
ユーザーが迷子になり、変な場所をクリックし、眉をひそめる。その瞬間、君のエンジニアとしてのプライドはズタズタになるかもしれない。「そこは右クリックだってば！」と叫びたくなるだろう。
でも、それが現実だ。説明書がないと使えないUIは、UIが悪い。
ユーザーが間違えたなら、それはユーザーのバグではなく、設計のバグだ。
この「Test」の結果を元に、また「Empathize」や「Ideate」に戻る。
この5つのフェーズは一直線（ウォーターフォール）ではなく、ぐるぐると回るループ（アジャイル）なんだ。
while(!UserSatisfied) { DesignThinkingProcess(); }
この無限ループこそが、イノベーションを生むエンジンの正体だ。
現場で起きたパラダイムシフト。たった1つのフェーズが「動くゴミ」を「神アプリ」に変えた話
完璧な「要件通り」のゴミを作ってしまった日
僕のキャリアの中で、最も恥ずかしく、そして最も多くのことを学んだプロジェクトの話をしよう。
それは、ある大手物流会社の倉庫管理システム（WMS）のリプレース案件だった。
当時の僕は、渡航して2年目。英語にも慣れ、C#のスキルにも絶対の自信を持っていた。「Prism」を使ったモジュール分割も完璧、非同期処理によるUIのレスポンスも最高、単体テストのカバレッジは90%超え。
要件定義書には「既存のレガシーシステムの機能を踏襲しつつ、モダンなUIに刷新すること」とあった。僕はそれを忠実に守り、モダンで洗練されたMaterial Design風のWPFアプリケーションを作り上げたんだ。
リリースの数週間前、意気揚々と現地の倉庫マネージャーたちを集めてデモを行った。
「見てください、この検索スピード。旧システムでは10秒かかっていた検索が、Entity Frameworkの最適化で0.5秒です」
僕は称賛の拍手を期待していた。しかし、会議室を支配したのは**「凍りつくような沈黙」**だった。
やがて、一番年配の現場リーダーが、申し訳なさそうに手を挙げて言った。
「…素晴らしい技術だということはわかる。でも、これじゃ仕事にならないよ」
僕の頭の中で何かが崩れる音がした。「なぜ？ 要件通りですよ？ 前のシステムより遥かに速いし、画面だって綺麗でしょう？」
彼は首を横に振った。「現場に来ればわかる」
デスクを飛び出し、埃まみれの現場へ（Empathize）
プライドはずたずただったが、僕は「Why」を知るために、安全靴を履いて倉庫（Gemba）へ向かった。
デザイン思考でいう**「Empathize（共感）」**の実践だ。ただ、当時の僕はそんな高尚なつもりはなく、ただ自分の正しさを証明するための証拠探しのような気分だった。
現場は、想像を絶する環境だった。
フォークリフトが走り回り、巨大なファンが轟音を立てている。作業員たちは分厚い革手袋をし、片手にはバーコードスキャナー、もう片方には伝票の束を持っていた。
僕が作った「モダンなアプリ」が入ったタブレット端末が、作業台に置かれていた。
それを見て、僕は絶句した。
僕が設計した画面は、小さな「コンボボックス」や「スクロールバー」を多用していた。
だが、分厚い革手袋をした指では、その小さなプルダウンメニューがどうしても押せないのだ。
作業員は手袋を口でくわえて外し、イライラしながら画面をタップし、また手袋をはめる。その動作を繰り返していた。
0.5秒で検索できても、入力に10秒余計にかかっていたら何の意味もない。
さらに衝撃的な光景があった。
彼らはアプリの画面を見ながら、手元の薄汚れたホワイトボードにマジックで数字を書き込んでいた。
「なぜそんなことを？」と聞くと、リーダーは言った。
「このアプリ、画面遷移すると前の数字が見えなくなるだろう？ 俺たちは3つのエリアの数字を見比べながら配置を決めたいんだ。だから一度紙に書くしかない」
僕が「画面遷移をスムーズにするため」に採用した美しいページネーション機能が、彼らの業務フローを分断していたのだ。
僕が作ったのは「高機能なアプリ」だったが、彼らが求めていたのは「手袋をしたまま、一目で状況を把握できる道具」だった。
要件定義書の「機能を踏襲する」という言葉は嘘だった。
彼らは旧システムでも同じ不満を抱えており、それを「運用（紙とペン）」でカバーしていただけだったのだ。僕はその「隠れた運用」に気づかず、デジタルのゴミを再生産したに過ぎなかった。
たった一枚の紙切れからの逆転劇（Prototype & Test）
オフィスに戻った僕は、Visual Studioを開かなかった。
代わりに、A3のコピー用紙と太いマーカーペンを取り出した。
コードを書く前に、**「Prototype（試作）」**で検証しなければならない。
僕はUIの美しさをすべて捨てた。
コンボボックス？ 廃止だ。
ページネーション？ 廃止だ。
代わりに描いたのは、まるで幼児の落書きのような画面だ。
- 画面の8割を埋め尽くすほどの巨大なボタン（拳で叩けるサイズ）。
- 3つのエリアの情報を、スクロールなしで一度に見られる高密度なダッシュボード。
- 色は「白」と「黒」と、警告用の「赤」だけ。おしゃれなグラデーションは全廃。
翌日、その「紙芝居」を持って再び倉庫へ行った。
「まだコードは書いてない。でも、こういう画面ならどうだ？」
リーダーの目が輝いた。「これだよ！ これなら手袋のままでもいける！」
隣にいた若手も言った。「この一覧性があれば、ホワイトボードはいらないですね」
その瞬間、僕の中でパラダイムシフトが起きた。
エンジニアの仕事は「コードを書くこと」ではない。「問題を解決する最短のパスを見つけること」だ。
XAMLの記述量で言えば、修正後の画面は当初の半分以下だった。複雑なアニメーションも、凝ったデータバインディングも捨てた。技術的には「退化」したと言ってもいい。
しかし、その「技術的に枯れた」アプリがリリースされた時、現場からは歓声が上がった。
作業効率は20%向上し、手袋の着脱によるタイムロスはゼロになった。
何より嬉しかったのは、あのリーダーが「これは俺たちのために作られたアプリだ」と、同僚に自慢してくれていたことだ。
技術的負債ならぬ「概念的負債」
この経験から僕が得た教訓は強烈だった。
僕たちはよく「技術的負債（Technical Debt）」を恐れる。コードが汚い、テストがない、構造が古い。
しかし、それよりも恐ろしいものがある。それは**「概念的負債（Conceptual Debt）」**だ。
「誰のために、何のために作るのか」という根本の理解（Define）が間違っている状態で、どれだけ高品質なコード（Clean Code）を積み上げても、それは**「借金を効率よく増やしている」**のと同じことなのだ。
デザイン思考の「Empathize（共感）」フェーズをすっ飛ばし、「仕様書」というフィルター越しにしか世界を見ていなかったこと。それが僕の敗因だった。
そして、「Prototype（試作）」で紙切れ一枚の検証を行っていれば、数週間のコーディング時間をドブに捨てずに済んだはずだった。
この失敗と成功の体験を経て、僕はC#エンジニアとしてのスタンスを完全に変えた。
新しい機能の実装を頼まれた時、僕はもうすぐにキーボードを叩いたりはしない。
「ちょっと待って。その機能を使う人が、今どんな顔をして仕事をしているか、見に行ってもいいかな？」
そう言って席を立つようになったんだ。
そして驚くべきことに、そうやって「現場」に足繁く通うエンジニアは、海外では「Technical Architect」や「Product Owner」へとキャリアアップしていく道が開かれている。
なぜなら、ビジネス（Why）とテクノロジー（How）の両方の言語を話せる人材は、どこに行っても希少だからだ。
さあ、物語は結末へと向かう。
「コード」という手段と、「コンセプト」という目的を繋ぐ架け橋となった僕たちエンジニア。
最終回では、これからのAI時代、自動生成されるコードが溢れる世界で、僕たちが人間として、エンジニアとして勝ち残るための「最後のメッセージ」を送りたい。
デザイン思考は、ただのツールじゃない。それは、君のエンジニアとしての寿命を決定的に延ばす「生存本能」のアップデートなんだ。
君はプログラマーか、それともイノベーターか？
冒険の終わりに：IDE（統合開発環境）の外側に答えがある
ここまで付き合ってくれてありがとう。
「起」では、海外の現場で「仕様書通り」が通用しない衝撃を話した。
「承」では、デザイン思考という5つの武器（Empathize, Define, Ideate, Prototype, Test）を授けた。
「転」では、僕が倉庫の現場で「完璧なC#コード」を捨て、「紙切れのプロトタイプ」で勝利した話をシェアした。
この旅を通じて、僕が君に最も伝えたかったこと。それは**「エンジニアの戦場は、もはやエディタの中だけではない」**という事実だ。
僕たちは長年、Visual StudioやVS Codeという快適な城の中に引きこもっていた。
IntelliSenseがコードを補完してくれ、コンパイラが間違いを指摘してくれる。そこは論理的で、予測可能で、安心できる世界だ。
しかし、城の外には「ユーザー」という、非論理的で、予測不能で、感情を持ったカオスな世界が広がっている。
デザイン思考とは、このカオスな荒野を歩くための「コンパス」だ。
地図はない。正解もない。あるのは「ユーザーの感情」という北極星だけだ。
C#やWPFといった技術は、荒野を移動するための「ジープ」や「装備」に過ぎない。目的地（解決すべき課題）が間違っていたら、どんなに高性能なジープでも、間違った場所に猛スピードで到達するだけだ。
AI時代へのアンサー：コーディングはAIに、デザインは人間に
さて、ここで避けて通れない話をしよう。AIの話だ。
GitHub CopilotやChatGPTの進化は凄まじい。君もすでに使っているだろう？
僕も毎日使っている。「このWPFのBehaviorを書いて」と頼めば、数秒でそこそこのコードが出てくる。
これを「脅威」と感じるか、「チャンス」と感じるか。それが、君のエンジニアとしての寿命を決める。
もし君が「仕様書をコードに翻訳する作業員」であり続けたいなら、残念ながら未来は暗い。その仕事は、遠くない未来にAIがコストゼロでやってのけるだろう。正確さでもスピードでも、人間はAIに勝てない。
しかし、もし君が「デザイン思考を操るイノベーター」になるなら、AIは最強のパートナーになる。
なぜなら、AIは「共感（Empathize）」ができないからだ。
AIは現場の倉庫に行って、作業員のため息を聞くことはできない。手袋の厚みを感じることもできない。ユーザーが言葉にできない「潜在的なニーズ」を定義（Define）することもできない。
「何を作るべきか（Concept）」を決めるのは、痛みを感じ取れる生身の人間（君）だ。
「どう作るか（Code）」は、AIと協力して爆速で片付ければいい。
デザイン思考を手に入れたエンジニアにとって、AI時代は「面倒なコーディングから解放され、より創造的な問題解決に集中できる黄金時代」なんだ。
明日から使える「思考のOS」アップデート
では、具体的に明日からどう動けばいいのか？
いきなり海外へ行けとは言わない。日本の現場でも、今のプロジェクトでも、すぐに実践できるアクションプランを渡そう。
1. “Yes, but…” を “Yes, and…” に変える
ミーティングで誰かが無茶なアイデアを出した時、「いや、それは技術的に無理です（Yes, but…）」と即答していないか？
それを一度飲み込んで、「いいですね、それを実現するためにこんな技術が使えますよ（Yes, and…）」と言ってみよう。
否定から入るエンジニアは「ブロッカー（障害物）」と呼ばれるが、肯定から広げるエンジニアは「イネーブラー（実現者）」として信頼される。
2. 1日30分、モニターから離れる
コードに行き詰まったら、Google検索をする前に、その機能を使う人に会いに行こう。あるいは、自分がそのユーザーになりきって操作してみよう。
「ユーザーは何をしようとしていたんだっけ？」
この問いを立てる時間は、デバッグの時間を数時間節約する価値がある。
3. 「未完成」を愛する勇気を持つ
エンジニアには完璧主義者が多い。ビルドが通るまで人に見せたくない気持ちはわかる。
でも、そのプライドを捨ててほしい。
「まだ動かないけど、絵に描くとこんな感じ？」と、落書きレベルで共有しよう。
恥をかくことを恐れてはいけない。早期の恥は、後期の致命傷を防ぐワクチンだ。
海外で働くことを目指す君へ
最後に、海外就職を目指す同胞たちへ。
海外の現場は、厳しい。言葉の壁、文化の壁、そして「成果を出さなければ即レイオフ」というプレッシャー。
でも、だからこそ面白い。
ここでは、「私はC#が書けます」というだけでは評価されない。
「私はテクノロジーを使って、あなたのビジネスの課題をこうやって解決できます」と語れる人間が求められる。
デザイン思考は、そのための共通言語だ。
英語が多少下手でも、ロジカルにユーザーの課題を分析し、プロトタイプで解決策を可視化できれば、誰もが君をリスペクトする。
僕自身、まだまだ修行中の身だ。
新しいフレームワークが出るたびに勉強し直さなきゃいけないし、ユーザーの予期せぬ行動には毎回驚かされる。
でも、「コードを書く」という狭い世界から飛び出し、「価値を創る」という広い海に出たことで、エンジニアという仕事がもっと好きになった。
あなたは誰だ？
さあ、問いかけよう。
君は誰だ？
ただの「C#プログラマー」か？
仕様書の行間を埋める「コーダー」か？
違うはずだ。
君は、テクノロジーという魔法を使って、誰かの困りごとを解決し、世界を少しだけ良くする**「イノベーター」**だ。
デザイン思考という武器を装備した君は、もう最強だ。
もしどこかの国の現場で、WPFのXAMLと格闘しながら、ユーザーのために付箋紙を貼りまくっている日本人エンジニアを見かけたら、声をかけてくれ。
それが僕かもしれないし、未来の君かもしれない。
一緒に、世界をハックしよう。
Good luck, and happy coding (and designing)!
コメント