「速さ」の正体とは何か？ 異国の地で痛感した、機能開発よりも大切な「勢い（Momentum）」の維持
こんにちは、海外でC#を書いてご飯を食べているエンジニアです。
普段はWPF（Windows Presentation Foundation）を使って、デスクトップアプリケーションの設計・開発をゴリゴリやっています。「え、今どきWPF？」って思ったそこのあなた、甘いですよ（笑）。海外のエンタープライズ領域、特に製造や金融、医療の現場では、堅牢なデスクトップアプリの需要は依然として底堅く、むしろWeb技術では代替できないパフォーマンスやハードウェア制御の部分で、C#のエキスパートたちがしのぎを削っています。
さて、今日はそんな私が、日本から海外へ飛び出し、現地の開発チームに混ざって働く中で受けた「最大の衝撃」について話したいと思います。それは技術レベルの高さでも、英語の壁でもありません。
それは、「開発スピード」に対する考え方の根本的な違いです。
日本にいた頃の私は、「速いエンジニア」＝「タイピングが速く、仕様を即座にコードに落とし込める人」だと思っていました。いかにバグを出さず、いかに早くチケットを消化するか。それが評価の全てでした。しかし、こっちに来て気づいたんです。それは単なる「瞬発力（Velocity）」に過ぎないと。
本当に強いチームが持っているのは、瞬発力ではなく**「勢い（Momentum）」**なんです。
開発現場で起きる「見えないブレーキ」
想像してみてください。
プロジェクトが始まったばかりの頃は、みんな意気揚々としていますよね。コードは綺麗だし、ビルドは一瞬で終わる。機能追加もサクサク進む。まさに飛ぶ鳥を落とす勢いです。
でも、半年、1年と経つにつれて、何かが変わり始めます。
「この機能を直すと、あっちが壊れるかもしれない」
「このライブラリ、バージョンアップしたいけど依存関係が複雑すぎて怖い」
「あの時とりあえず動くように書いたコード、誰が書いたんだっけ？ ……え、退職したあの人？」
こうして、チームの足取りは徐々に重くなります。まるで泥沼の中を歩いているかのように、同じ1行のコードを書くのにも、以前の何倍もの確認と精神力が必要になってくる。皆さんも経験ありませんか？ 私は日本にいた頃、これが「システム開発の宿命」だと思っていました。システムが巨大になればなるほど、動きが鈍くなるのは仕方がないことだと。
しかし、海外のトップティア（一流）のチームは違いました。
彼らのプロジェクトは、規模が大きくなっても、時間が経っても、開発スピードが落ちないのです。むしろ、ライブラリが整備され、ナレッジが共有されることで、後半になればなるほど加速していく。
「なんでだよ、魔法か？」
最初は本気でそう思いました。WPFのMVVMパターンが優れているから？ 違います。彼らが使っている言語やフレームワークは私と同じです。IDEだって同じVisual Studioです。
違いは、「技術的負債」と「失敗」、そして「共有」に対する文化的なアプローチにありました。
「Momentum（勢い）」を殺す犯人は誰だ
私が参加した当初、スプリントプランニング（アジャイル開発における計画会議）で衝撃的な光景を目にしました。
プロダクトオーナー（PO）が「この新機能を入れたい」と言ったとき、テックリードが平然とこう返したんです。
「OK。でも、このスプリントのキャパシティの20%は『負債の返済（Debt Budget）』に充てるよ。先週の実装でリファクタリングしきれなかった部分と、ライブラリのアップデートがあるからね」
POも嫌な顔ひとつせず、「了解。じゃあ機能の実装はこの範囲に絞ろう」と即答する。
日本での経験では、リファクタリングや技術的負債の解消は「機能開発の合間に、隠れてやるもの」か、あるいは「プロジェクトが炎上してどうしようもなくなってから、許可を乞うてやるもの」でした。それがここでは、最初から「予算」として組み込まれているのです。
彼らは知っていたんです。「勢い（Momentum）」を殺す最大の敵は、「あとでやる（Later）」という言葉だということを。
コードが汚いままでも「とりあえずリリース」を優先し続けると、そのツケは複利で膨れ上がります。これを彼らは「Momentumの摩擦係数が増える」と表現していました。摩擦がゼロなら、物体は加速し続けます。しかし、負債という摩擦・抵抗が増えれば、どんなに強力なエンジン（優秀なエンジニア）を積んでも、車体は前に進みません。
失敗を「個人の恥」ではなく「資産」にする
もう一つの衝撃は、障害が起きた時の対応でした。
ある日、私が担当したモジュールで、本番環境に影響するバグを出してしまったことがあります。日本の現場なら、始末書を書かされ、「なぜチェックできなかったのか」「再発防止策は（精神論で）どうするのか」と詰められる場面です。私は青ざめて、Slackで謝罪の言葉を並べ立てました。
しかし、チームの反応は真逆でした。
「Hey、落ち着けよ。これは素晴らしい『学習の機会』だ」
そう言って始まったのは、**Blameless Post-mortem（非難なき事後検証）**でした。
「誰がやったか」なんて誰も気にしません。「なぜシステムは、彼にそのミスをさせてしまったのか？」「テストのカバレッジが抜けていたのか？ アーキテクチャが複雑すぎたのか？」
彼らは、私のミスを責めるどころか、それをきっかけにシステム全体の堅牢性を上げるための議論を楽しみ始めたのです。
この時、私は気づきました。
彼らが維持している「勢い」は、単にコードを書く速さではなく、**「失敗を恐れずに挑戦し、その失敗すらも推進力に変えてしまう文化」**そのものなのだと。
車輪の再発明を許さない「社内OSS」
そして最後に、組織全体を貫く**Internal Open Source（社内オープンソース）**の考え方。
隣のチームが似たようなWPFのカスタムコントロールを作っているのに、互いにコードが見えず、コピペや再実装が横行する……なんてことはここにはありません。「良いものができたらライブラリ化して、全社に公開する。バグがあれば誰かが直してプルリクを送る」。
まるでGitHubの世界が、社内ネットワークの中で展開されているのです。これにより、共通基盤は常に磨き上げられ、私たちは「ビジネスロジック」という本質的な価値のみに集中できる。
なぜ、この話をするのか？
私がこのブログで伝えたいのは、C#の最新文法やWPFのXAMLテクニックではありません。もちろんそれも大事ですが、それ以上に、**「エンジニアが長期的に、健やかに、そして高速に価値を出し続けるための環境作り」**についてです。
これから海外を目指すエンジニアの方、あるいは日本で「もっと良い開発現場を作りたい」と足掻いているテックリードの方へ。
私が体験したこの「カルチャーショック」は、あなたのキャリアやチームを劇的に変えるヒントになるはずです。
「Debt Budget（負債の予算化）」
「Blameless Post-mortem（非難なき事後検証）」
「Internal Open Source（社内OSS）」
この3つのキーワードは、単なるバズワードではありません。これらは、開発の「勢い」を加速させるための、具体的かつ実践的な武器です。
次章からは、これらの具体的な中身と、実際にどうやって現場に導入し運用しているのか、生々しい実例を交えて解説していきます。これを知れば、あなたはもう「終わらないデスマ」や「触るのも怖いレガシーコード」に怯える必要はなくなります。
エンジニアとしての人生を、消耗戦から「知的生産の冒険」に変えるための方法論。
準備はいいですか？ ここからが本番です。
具体的手法を解剖する —— 「負債の予算化」「犯人探しの排除」「社内OSS」がもたらす化学反応
前の章では、海外の強いチームが持つ「Momentum（勢い）」について触れました。
「そんな夢みたいな話、実際にどうやって回してるの？」「納期に追われる中で、綺麗事なんて言ってられないでしょ？」
そう思ったあなた、正解です。私も最初はそう思っていました。
しかし、彼らは精神論ではなく、非常にドライで合理的な「システム（仕組み）」として、これを回していました。ここでは、私が実際に体験し、今では手放せなくなった3つの具体的なメソッドを解剖していきます。
1. The “Debt Budget” Approach（負債の予算化）
——「ごめんね」と言いながらリファクタリングするのは、もうやめよう。
日本にいた頃、リファクタリングやライブラリのアップデートは「隙間産業」でした。機能実装が早く終わった時にコッソリやるか、あるいは上司に「このままだとヤバいです」と土下座する勢いで説得して時間を貰うか。そこには常に「本来の業務（機能開発）ではないことをしている」という罪悪感がありました。
しかし、今のチームでは**「Debt Budget（負債予算）」**という概念が明確に存在します。
具体的な運用ルール：20%の聖域
私のチームでは、スプリント（2週間サイクル）のキャパシティのうち、20%を強制的に「Technical Debt（技術的負債）」の返済に割り当てます。
例えば、チーム全体の稼働時間が100ポイントあるとしたら、機能開発に使えるのは最大でも80ポイント。残りの20ポイントは、PO（プロダクトオーナー）が口出しできない「エンジニアの聖域」として確保されます。
この20%で何をするのか？
- WPFの古いバインディング記述の修正: レガシーな書き方を最新の構文に書き換える。
- ライブラリの更新: NuGetパッケージの依存関係を整理し、
.NETのバージョンを上げる。 - テストコードの拡充: カバレッジが低いモジュールの単体テストを追加する。
「後でやる」を構造的に排除する
ここで重要なのは、これを「タスク」としてチケット化し、バックログに入れることです。
プランニングの会議で、POが「この機能も入れたい」と言ってきても、スクラムマスターが冷静にこう言います。
「それを入れるとキャパシティの85%になる。Debt Budgetを侵食するので、どれか機能を削るか、次のスプリントに回してくれ」
最初は「厳しいな」と思いましたが、これを続けることで**「開発速度の予測可能性」**が劇的に向上しました。「急がば回れ」を制度化することで、突発的なバグ対応（これも一種の負債の利払い）が減り、結果として機能リリースのペースが安定するのです。
「負債は、借金と同じ。放置すれば利子がついて首が回らなくなる。だから毎月、元本を少しずつ返すんだ」
テックリードの口癖ですが、まさにこれが持続可能な開発の秘訣です。
2. Blameless Post-mortems（非難なき事後検証）
——「誰がやったか」を探す暇があったら、「仕組み」を疑え。
私がこちらに来て一番救われたのが、この文化です。
システム開発に障害はつきものです。特に、複雑なハードウェアと連携するC#アプリケーションでは、タイミング依存の厄介なバグ（Race Conditionなど）が発生しがちです。
ある時、私が担当した非同期処理のコードが原因で、顧客先でアプリがクラッシュする事態が起きました。
「終わった……」
冷や汗をかきながらオフィスに行くと、待っていたのは「懲罰委員会」ではなく、**「ポストモーテム（Post-mortem：検死）」**と呼ばれるミーティングでした。
犯人探し禁止の鉄の掟
ホワイトボードの前に集まったチームメンバーに対し、ファシリテーターが開口一番に言ったのはこの言葉です。
“Assume Good Intentions.”（善意を前提とせよ）
「彼はベストを尽くしてコードを書いた。それでもバグは起きた。つまり、我々のプロセスやツールに欠陥があるということだ。それを探そう」
そこからは、徹底的な**「なぜ（Why）」の深掘り**が始まります。
- Why? ->
NullReferenceExceptionで落ちた。 - Why? -> APIからのデータが予期せず欠損していた。
- Why? -> そのケースの単体テストが漏れていた。
- Why? -> モックデータの作成が手動で、エッジケースを網羅しきれていなかった。
- Solution: 自動化されたFuzzingテスト（ランダムデータによるテスト）を導入し、APIの契約テスト（Contract Testing）をパイプラインに組み込む。
心理的安全性が「隠蔽」を防ぐ
もしここで私が責められていたら、私は次から自分のミスを隠そうとしたり、防衛的になって挑戦的なコードを書かなくなったりしたでしょう。
しかし、チームは「バグを見つけてくれてありがとう、おかげでシステムが強くなる」という態度で接してくれました。
この**「心理的安全性（Psychological Safety）」**があるからこそ、障害報告が迅速になり、ボヤが火事になる前に消し止められる。
日本の現場でよくある「怒られないための報告書作成」がいかに無駄なコストだったか、痛感させられた瞬間です。
3. Championing “Internal Open Source”（社内OSSの推進）
——「車輪の再発明」は、エンジニアのプライドではなく恥だと思え。
3つ目は、組織全体でのコード共有の仕組みです。
大企業あるあるですが、「Aチームが作った便利なカレンダーUI」を、Bチームが知らずに「似たような（でもちょっと出来の悪い）カレンダーUI」を一から作っている……なんてこと、ありませんか？
私の会社では、これを防ぐために**Internal Open Source（InnerSource）**を強力に推進しています。
社内版NuGetの威力
具体的には、汎用的な機能（ロギング、認証、共通UIコントロールなど）は、個別のプロジェクトに書くのではなく、共有ライブラリとして切り出し、社内のプライベートNuGetフィードで公開します。
私がWPFで「リッチなデータグリッドの拡張機能」を作った時のことです。
「これ、他のプロジェクトでも使えそうだな」と思い、社内リポジトリに公開しました。すると数日後、全く面識のない他チームのエンジニアからPull Requestが届いたのです。
「君のコンポーネント、最高だね。ただ、パフォーマンスに少し難があったから、仮想化処理（Virtualization）を改善しておいたよ」
感動しました。
私が寝ている間に、私のコードが勝手に進化している。
これこそがオープンソースの醍醐味ですが、それが社内で起きているのです。
共通言語ができる強み
この文化が定着すると、組織全体で「技術的な共通言語」が生まれます。
どのチームに異動しても、基本的なライブラリやアーキテクチャ（PrismやMVVMの作法など）が統一されているため、オンボーディングのコストが極端に下がります。
「自分のコードを抱え込むな。外に出して、叩かれて、磨かれろ」
これが、こちらのシニアエンジニアたちの共通認識です。コードは個人の所有物ではなく、組織全体の資産。そう捉え直すだけで、開発効率は掛け算で伸びていきます。
承のまとめ：これらは個別の戦術ではなく「文化」である
ここまで紹介した3つの手法。
- Debt Budget: 定期的なメンテナンスを業務フローに組み込む。
- Blameless Post-mortem: 失敗を個人の責任にせず、システムの改善につなげる。
- Internal Open Source: 知見とコードを共有し、組織全体で品質を上げる。
これらは、どれか一つをやればいいというものではありません。
「失敗を恐れず（Blameless）」、「常にコードを綺麗に保ち（Debt Budget）」、「みんなで共有する（Internal Open Source）」。この3つが噛み合って初めて、アジャイルの本来の目的である「変化への対応力」と「持続可能なスピード」が手に入るのです。
日本にいた頃の私は、ツールやフレームワークの使い方ばかりを勉強していました。でも、本当に学ぶべきは、こうした**「エンジニアリングを支える社会学」**のような仕組み作りだったのかもしれません。
さて、ここまで読んで「良い話だけど、うちの会社じゃ無理だな……」と思ったあなた。
諦めるのは早いです。
次章では、この強烈な文化の違いに対して、我々日本人エンジニアがどう向き合い、どうやって自分の現場に取り入れていくか。その際に立ちはだかる「マインドセットの壁」についてお話しします。
実は、最大の敵は上司でも会社でもなく、私たち自身の心の中に巣食う「ある思考の癖」だったのです。
マインドセットの激震 —— 日本的「完璧主義」が邪魔をする？ 心理的安全性とオーナーシップの壁を越えて
ここまで、海外のエンジニアリング文化がいかに合理的で、スピード感に溢れているかを語ってきました。「すごい！ じゃあ明日から真似しよう！」そう思った方もいるかもしれません。
でも、正直に告白します。
私が渡航して最も苦しみ、そして最も時間をかけて乗り越えなければならなかった壁は、英語力でもC#の技術力でもありませんでした。
それは、私自身の中に深く根付いていた**「日本人としての職業倫理」そのもの**でした。
真面目で、責任感が強く、細部にこだわる。
これらは日本では「良いエンジニア」の条件です。しかし、皮肉なことに、この**「日本の美徳」こそが、アジャイルな文化（Momentum）を阻害する最大のボトルネック**になっていたのです。
この章では、私が直面した3つの「内なる敵」と、そこからの意識改革（パラダイムシフト）についてお話しします。
1. 「完璧主義」という名のブレーキ
—— 60点のコードを出す勇気を持てるか？
プロジェクトに慣れてきた頃、私はある機能実装を任されました。
「よし、日本のクオリティを見せつけてやる」と意気込み、私は完璧を目指しました。エッジケースを考え抜き、命名規則を徹底し、コメントを丁寧に書き、リファクタリングを繰り返す。
デイリースタンドアップ（朝会）で、私は数日間こう言い続けました。
「順調です。もう少しで完了します」
3日後、テックリードが私のデスクに来て、画面を覗き込みました。
そして、怪訝な顔でこう言ったのです。
「Hey、なんでPull Request（PR）を出さないんだ？ もう動く状態じゃないか」
私は答えました。
「いや、まだ例外処理の一部が甘いし、ここのクラス設計が美しくないから……」
彼は首を横に振り、強く言いました。
「君の『完璧』を待っている間に、他のメンバーは君のコードに依存する作業が進められない。それは『丁寧』なんじゃない。『独占』だ」
ガツンと殴られた気がしました。
日本では「中途半端なものを出すのは失礼」「プロとして恥ずかしい」という感覚がありました。しかし、こちらの文化では**「WIP（Work In Progress：作業中）」を共有しないことこそが罪**なのです。
アジャイルの本質は、フィードバックのループを早く回すこと。
私が一人で100点を目指して抱え込んでいる3日間で、チームなら60点のコードをベースに議論し、80点、100点、いや120点へと進化させることができたはずです。
**「Debt Budget（負債予算）」**があるからこそ、今は汚くてもいい。後で直す時間が確保されているのだから、まずは「動くもの」を出して、Momentum（勢い）を止めない。
私の「完璧主義」は、実は「他人からの評価を恐れるエゴ」でしかなかったことに気づかされた瞬間でした。
2. 「過剰な責任感」がシステムを弱くする
—— 「すみません」は、思考停止の言葉かもしれない。
次にぶつかった壁は、**「Blameless Post-mortem（非難なき事後検証）」**における振る舞いでした。
ある時、私のミスでビルドパイプラインを止めてしまいました。
ミーティングの場になった瞬間、私は日本にいた頃の条件反射で、こう切り出しました。
「本当に申し訳ありません。私の確認不足です。今後はダブルチェックを徹底し、週末を使って修正します……」
すると、部屋の空気が凍りつきました。
スクラムマスターが静かに口を開きました。
「謝るのはやめてくれ。君が謝ると、私たちが『真の原因』を探す目が曇ってしまう」
彼らが言いたかったのはこうです。
個人が「私が頑張ります」「私が悪かったです」と責任を背負い込むことは、一見潔いように見えます。しかし、それは**「システムの問題」を「個人の問題」にすり替えて隠蔽する行為**なのです。
「君が悪いんじゃない。君がミスを犯せる状態になっていたCI/CDパイプラインが悪いんだ。君が謝って、気合で再発防止を誓っても、半年後に新人が入ってきたら同じミスをするだろう？ それじゃ意味がないんだ」
私はハッとしました。
日本の現場でよく見る「詫びる文化」「属人的な頑張りでカバーする文化」。あれは、実は組織の学習能力を奪っていたのかもしれない。
「責任感」とは、一人で背負い込んで謝ることではなく、「二度と同じ悲劇が起きない仕組み」を淡々と構築すること。
感情を切り離し、ドライに事実と向き合う。
このマインドセットの切り替えは、情に厚い日本人にとって最初は冷たく感じるかもしれません。でも、これこそが本当の意味での「チームへの優しさ」なのだと理解するのに、私は半年かかりました。
3. 「恥の文化」とオープンソースマインド
—— クソコードを見せることは、信頼の証である。
最後に、**「Internal Open Source（社内OSS）」**への心理的障壁です。
自分のコードを全社公開する。
これは、「私の書いたコードが、見知らぬ凄腕エンジニアたちに品定めされる」という恐怖との戦いでした。
「こんな非効率なLINQの書き方して、ププッて笑われたらどうしよう」
「英語の変数名のスペルミスがあったら恥ずかしい」
日本的な**「恥（Shame）の文化」**です。
失敗を見られたくない。優秀だと思われたい。だから、完成するまで隠す。あるいは、自分だけのローカルフォルダに秘伝のタレとしてコードを隠し持つ。
しかし、こちらのエンジニアたちは、驚くほどオープンで、そして「無防備」です。
Slackのパブリックチャンネルに、平気で書きかけの汚いコードを貼り付けてこう言います。
「このクエリ、なんか重いんだけど、誰かいいアイデアない？ 笑」
すると、すぐに誰かが
「おっと、そこはIEnumerableじゃなくてIQueryableのまま扱わないと、全件メモリに展開しちゃうぜ」
とレスを返す。そこに嘲笑はありません。あるのは純粋な技術的関心と、貢献（Contribution）への意欲だけです。
私は気づきました。
彼らにとってコードは**「自分の分身（人格）」ではなく、単なる「成果物（アーティファクト）」**に過ぎないのです。
だから、コードが批判されても、自分が否定されたとは感じない。むしろ、自分のコードが直されることを「ラッキー、勉強になった！」と喜ぶ。
この「自意識の切り離し」ができないと、真のコラボレーションは生まれません。
私は恐怖を押し殺し、ある日、拙いWPFのビヘイビア（Behavior）のコードを社内リポジトリにPushしました。
心臓がバクバクしました。
しかし、返ってきたのは、
「Nice implementation!」というコメントと、いくつかの改善提案のPRでした。
その時、私の小さなプライドという殻が割れ、初めて本当の意味でチームの一員になれた気がしました。
転のまとめ：自分を変える勇気が、最強のスキル
こうして振り返ると、海外で働く上で最も必要なスキルは、語学力でもコーディング力でもなく、「Unlearn（学習棄却）」する力だったと確信しています。
日本で培った「常識」を一度捨てること。
- 完璧主義を捨て、スピードと共有を選ぶ。
- 過剰な自責を捨て、仕組みへの改善に昇華する。
- 恥を捨て、弱さをさらけ出して集合知を借りる。
これは、決して「日本人が劣っている」という話ではありません。日本の現場の緻密さや品質へのこだわりは、世界でもトップクラスです。
ただ、変化の激しい現代のソフトウェア開発、特に「Momentum」を重視するアジャイルな現場においては、その美徳が足かせになる瞬間があるという事実です。
「郷に入っては郷に従え」と言いますが、それは単に現地のランチタイムに合わせるとか、そういう表面的なことではありません。
仕事に対する哲学、プロフェッショナルとしての在り方を、環境に合わせてチューニングできる柔軟性。
それこそが、グローバルな環境で生き残るエンジニアの必須条件なのです。
さて、ここまで読んで、
「理屈はわかった。でも、明日からどう行動を変えればいいの？」
「日本にいながら、このマインドセットを取り入れるには？」
そう思った方へ。
最後の章では、これまでの話を総括し、あなたの明日からの行動を変えるための「具体的なアクションプラン」を提示します。
場所がどこであれ、エンジニアとしての人生をより豊かにするための、私のラストメッセージです。
明日からあなたのチームが変わる —— エンジニア個人の生存戦略として、この文化をどうハックするか
ここまで、海外の現場で私が体験した「Debt Budget（負債の予算化）」「Blameless Post-mortem（非難なき事後検証）」「Internal Open Source（社内OSS）」という3つの武器、そしてそれを受け入れるために必要なマインドセットの変革についてお話ししてきました。
きっと、これを読んでいる日本のエンジニアの皆さんは、少し複雑な気持ちかもしれません。
「言いたいことは痛いほどわかる。でも、うちの会社はドメスティックなSIerだし、上司はアジャイルなんて言葉も知らない。そんな環境でこれをやったら、ただの『面倒な奴』扱いされて終わりだよ」
その気持ち、本当によく分かります。
私も日本にいた頃、ガチガチのウォーターフォール開発の中で、一人でユニットテストを書いては「工数の無駄」と白眼視された経験がありますから。
しかし、だからこそ私は声を大にして言いたいのです。
環境が整うのを待っていたら、あなたのエンジニアとしての寿命が先に尽きてしまいます。
この「結」の章では、組織全体のルールを変える権限がない一介のエンジニアであっても、明日から自分の半径5メートル以内で始められる**「文化のハッキング方法」**を提案します。これは会社のためではありません。あなた自身が、消耗せずに長く楽しくコードを書き続けるための「生存戦略」です。
1. “Guerrilla” Debt Budget（ゲリラ的負債返済）
—— 許可を求めるな、見積もりに含めろ。
もしあなたのチームに「20%の負債返済ルール」がないなら、作ってしまえばいいのです。ただし、上司に直談判する必要はありません。
あなた自身の見積もりに、最初から含めてしまうのです。
「このWPF画面の実装、どれくらいかかる？」と聞かれたら。
以前のあなたなら「気合を入れて3日です（徹夜覚悟）」と答えていたかもしれません。それをこれからは、「5日です」と答えるのです。
その内訳はこうです。
- 3日：機能実装
- 1日：リファクタリングと単体テスト（Debt Budget）
- 1日：予備バッファ
これは嘘をついているわけでも、サボろうとしているわけでもありません。
プロフェッショナルとして、「後でバグを出して手戻りするリスク」を未然に防ぐための正当なコストです。
海外のシニアエンジニアはこう言います。
「外科医が『早く手術を終わらせるために、手洗いを省略しました』と言ったらどう思う？ エンジニアにとってテストとリファクタリングは、外科医の手洗いと同じだ。それは交渉の余地があるオプションじゃなくて、仕事の一部だ」
もし「5日は遅い」と言われたら？
「3日で出すこともできますが、その場合、将来的な修正コストが3倍になるリスクがあります。品質担保込みの5日か、借金を背負う3日か、どちらを選びますか？」と、ビジネスのリスクとして提示してみてください。
これを繰り返すことで、あなたは「仕事が速い人」から**「仕事が確実で、トラブルを起こさない人」**へと評価が変わっていきます。結果として、それが一番「速い」のです。
2. 一人から始める Post-mortem
—— 「なぜ」の問いかけを変えるファシリテーターになれ。
組織として「非難なき事後検証」のミーティングが開かれなくても、あなたの日々の会話を変えることはできます。
後輩や同僚がバグを出した時、あるいは自分自身がミスをした時。
「すみません」「気をつけて」という言葉が出そうになったら、それを飲み込んで、こう問いかけてみてください。
「『気をつける』以外で、ツールで防ぐ方法はないかな？」
- 「コンパイル時にエラーになるように、型を厳密にできないか？」
- 「CIでチェックするスクリプトを書けないか？」
- 「ドキュメントの場所が分かりにくかったのが原因じゃないか？」
犯人探しが始まりそうな空気を、あなたが率先して「仕組みの話」にすり替えるのです。
私が日本にいた頃、これを個人的に続けていたら、いつの間にかチーム内で「彼に相談すれば、怒られずに解決策が見つかる」という信頼が生まれました。やがて、障害が起きた時に私の席に自然と人が集まり、プチ・ポストモーテムが始まるようになりました。
文化は、会議室で作られるのではありません。日々のSlackや立ち話の中で作られるのです。
3. Gist から始める Internal Open Source
—— コードの断片をばら撒け。
全社的なライブラリ管理システムやNuGetサーバーがなくても、社内OSS的な動きは作れます。
社内のWikiや、Teams/Slackのメモ機能、あるいはGitのSnippet機能（Gistなど）を使って、「便利なコードの断片」を共有することから始めましょう。
「WPFのDataGridで、行番号を表示するBehavior作ったから置いとくね」
「SQL Serverへの接続リトライ処理、汎用的にしたからコピペで使っていいよ」
最初は誰も反応しないかもしれません。それでも続けるのです。
重要なのは、「自分のコードを他人に見せる」というハードルを自分自身で下げること。そして、「ギブ（Give）」の精神を行動で示すことです。
そのうち必ず、「あのコード助かりました」「ここ、もう少しこう書き直せますよ」という反応が返ってきます。
その瞬間、あなたの周りに小さな「コミュニティ」が生まれます。
会社という縦割りの組織の中に、技術という横串を通す。このネットワークを持っているエンジニアは、どの会社に行っても、あるいはフリーランスになっても、最強に強いです。
エンジニアとしての「Momentum」を維持するために
最後に、私がなぜこれほどまでに「アジャイルな文化」にこだわるのか、その個人的な理由をお話しして終わりにします。
それは、**「エンジニアとして、老け込みたくないから」**です。
技術的負債にまみれ、変更におびえ、誰かのミスを責め合い、自分の知識を隠し持つ。
そんな環境で働いていると、エンジニアの目は死んでいきます。新しい技術への好奇心は失われ、「どうせ動かない」「どうせ変えられない」という学習性無力感に支配されてしまう。それはエンジニアとしての「死」と同義です。
逆に、
常にコードが磨かれ、
失敗から学びを得て、
知見が共有され続ける環境。
ここに身を置くと、私たちは何歳になっても、どんな技術が出てきても、ワクワクしながら挑戦し続けることができます。
私が海外に来て一番良かったのは、50代、60代の現役エンジニアたちが、目を輝かせながら「おい、昨日の.NETのアップデート見たか？ アレすげーぞ！」と議論している姿を見られたことです。彼らは、Momentumを失っていないのです。
あなたが今日から始める小さな「文化のハッキング」は、あなたのチームを救うだけではありません。未来のあなた自身を救うのです。
C#とWPFという、ある種「枯れた」と言われる技術を使っている私たちが、最先端のWeb系企業にも負けないスピードと熱量で開発できている事実。
これが、場所や技術スタックに関わらず、「文化」さえあればどこでもMomentumは生み出せるという何よりの証明です。
さあ、次はあなたの番です。
完璧じゃなくていい。まずは次のプルリクエスト、次のチャットの一言から変えてみませんか？
世界は広いです。でも、あなたのデスクの前のモニターから繋がっている世界は、あなたが思っているよりもずっと自由で、可能性に満ちています。
いつか、どこかのGitHubのリポジトリ、あるいは技術カンファレンスの会場で、あなたとコードの話ができる日を楽しみにしています。
Happy Coding!
コメント