「機能を追加してほしい」と頼んだだけなのに、エンジニアが不機嫌になる。 「とりあえず動けばいいから、早くやって」と言ったら、猛反発された。
多くのビジネスリーダーが、こうした「エンジニアとの感情的な摩擦」に悩んでいます。 彼らは怠慢なのでしょうか？ いいえ、逆です。彼らはプロフェッショナルだからこそ怒っているのです。
彼らの怒りの正体。それは、目先のスピードと引き換えに、システムの中にゴミ（汚いコード）が溜まっていくことへの恐怖です。 今回は、DX組織を内側から崩壊させる**『技術的負債（Technical Debt）』**と、技術者の職人気質（クラフトマンシップ）との付き合い方について解説します。
1. 「借金」をして開発しているという自覚
ソフトウェア開発には、「技術的負債」という概念があります。 「汚くてもいいから早くリリースする」というのは、金融で言えば「借金」をする行為です。
借金（汚いコード）をすれば、一時的にキャッシュ（機能）は手に入ります。 しかし、その瞬間から「利子」が発生します。 コードが複雑になり、バグ修正に時間がかかり、新機能を追加するのが難しくなる。これが利子の正体です。
エンジニアが「これ以上は無理です。リファクタリング（コードの整理）をさせてください」と訴える時、彼らは「利子が膨らみすぎて、返済不能（破産）になりそうだ」と警告しているのです。 これを「サボりたい言い訳」と捉える経営者は、遠からずシステムごと破綻します。
2. 「品質」の定義がズレている
ビジネスサイドとエンジニアサイドでは、見ている「品質」が異なります。
- ビジネス側の品質（外部品質）： 画面が正しく動くか、バグがないか、使いやすいか。
- エンジニア側の品質（内部品質）： コードが読みやすいか、修正しやすいか、拡張性があるか。
ビジネス側は「動いているならいいじゃないか」と言いますが、エンジニアにとって「動くけれど汚いコード」は、腐った土台の上に高層ビルを建てるようなストレスを与えます。
彼らが怒るのは、**「将来、必ず起きるトラブルの責任を負わされるのは自分たちだ」**と知っているからです。 彼らの「こだわり」は、趣味ではなく、未来のリスクヘッジなのです。
3. 「20%ルール」でガス抜きをする
では、ビジネスのスピードと、エンジニアの品質へのこだわりをどう両立させるか。 Googleなどのテック企業が実践している**「20%ルール」**の応用を推奨します。
スプリント（開発サイクル）の中に、あらかじめ**「エンジニアが好きなように使える時間（リファクタリング枠）」を10〜20%確保しておく**のです。
「この20%の時間は、新機能を作らなくていい。君たちが気になっているコードの修正や、新しい技術の検証に使ってくれ」
こう宣言することで、エンジニアは「借金を返済できる」という安心感を得られます。 結果として、システムは健全に保たれ、長期的な開発スピードは向上します。 「急がば回れ」を制度化すること。これがエンジニアの信頼を勝ち取る最短ルートです。
まとめ：彼らの「プライド」を愛せ
エンジニアという生き物は、自分の書いたコードにアーティストのようなプライドを持っています。 「とりあえず動けばいい」という言葉は、彼らにとって「君の作品なんてどうでもいい」と言われているのと同じです。
技術的負債を理解し、「いつも綺麗なコードを保ってくれてありがとう」と伝えること。 そのリスペクトさえあれば、彼らはあなたのビジネスのために、喜んで徹夜をしてでも助けてくれる最強のパートナーになります。
次回は、組織内のスキル格差をどう埋めるか。 **『ベテランの「背中」を見て育つな。「ペアプログラミング」という超高速学習システム』**について解説します。
コメント