- 大規模な技術的負債を抱える企業では、コードの複製や古いフレームワークによる非効率が発生する
- プロジェクトの進行中には、マネジメントからの信頼喪失と組織内の変化への抵抗が大きな障害として作用する
- 技術的負債の根本原因は、要件の不明確さ、非現実的なスケジュール、古い技術への固執、経営陣の短期的対応、個人のプライドなど、人に起因する要素にある
- 技術的成果だけでなく、認識のマネジメントとコミュニケーションがプロジェクト成功に不可欠である
- エンジニアは技術力に加えて、組織内での協業や人間関係を調整する能力も備える必要がある
技術的負債と重複コードの問題
- 以前勤めていた会社では、数百万行のコード、単体テストの欠如、10年以上前のフレームワークの使用により、深刻な技術的負債が存在していた
- Windows専用モジュールをLinuxで動かすために、数十万行のコードをコピー＆ペーストして対応していた
- その結果、2つのコードベースが生まれ、機能追加やバグ修正をそれぞれ別々に行う必要が生じた
- このような状況は、保守不能な構造をもたらし、長期的にはコード間の乖離がさらに大きくなる
人の問題によって生まれる技術的負債
- 技術的負債の解消プロジェクトは経営陣を説得しにくく、その結果として機能の変化がほとんどないため、目に見える成果が乏しい
- 問題の本質は技術ではなく、人の態度と組織文化にある
- 多くの開発者が変化に抵抗し、過去のやり方に安住している
- コードの構造は、その作者の性格や変化受容度を反映する
- 技術的負債は、不明確な要件、非現実的な約束、古い技術の選択、経営陣による中断の判断、個人的なプライドなどから生まれる
- 変化を避ける傾向が強いチームほど、コードにも変化を拒む性質が表れやすい
- 複数の開発者は何年も同じやり方のまま作業しており、さらには「新しいことを学びたくない」という言葉まで出ていた
- このような環境では、整理の速度より負債の蓄積速度のほうが速いため、負債を減らす前に、これ以上負債が積み上がらないように防ぐことが優先されるべきである
- 救急外来の**triage（優先度分類）**の比喩のように、まずは「出血を止める」段階が必要だ
理想の世界と現実の隔たり
- エンジニアリング上の問題を政治や組織の文脈から切り離して解決できる理想的な環境は、ほとんど存在しない
- ほとんどのプロジェクトには非技術系の利害関係者が存在する
- 「自分たちで進めているので信じてほしい」という態度は通用しない
- 成果の見られ方のマネジメントは、実際の成果と同じくらい重要である
- 非技術者は技術的負債解消の必要性を直感的に理解できないため、定量的・事業的価値で説明する必要がある
- リーダーシップにエンジニアリングの背景がない場合、可視的な数値と効果の提示が必要になる
- 結局のところ、チームが生産的に見えること自体も、実際の生産性と同じくらい重要である
シニアエンジニアに必要な能力
- シニア以上の職位では、部門横断の協業と人間関係を調整する能力が不可欠である
- コンピュータサイエンス教育では、性格・プライド・関係性の管理といった「人を扱うこと」は教えない
- 優れた技術力を持つエンジニアでも、大規模で組織的な変化を必要とする問題には対処できないことがある
Heads up coder の役割は重要である
- 深い技術力を維持しつつ、プロジェクトリスクを早期に察知してチームを調整できる人物
- 単一コアのように一人で速く働くのではなく、チーム全体を効率的に導く役割
- 純粋な技術志向のエンジニアと異なり、組織の文脈とリスクをあわせて読み取りながら動ける
まとめ
- 技術的問題の根源には常に人がいる
- ほとんどの技術的問題は、人、文化、コミュニケーションの問題に帰着する
- 技術的負債はコードの問題ではなく、組織の行動パターンと文化が生み出した結果である
- 技術的負債の解決には、組織的な変化受容とリーダーシップの理解が先行しなければならない
- そして、技術的卓越性だけでは解決できない問題が、キャリア後半のより大きな舞台で待っている
- 真のシニアエンジニアとは、技術と人間理解の両方を扱えるバランス型のリーダーである
2件のコメント
これに関連してさらに詳しく知りたい方には、
Peoplewareを読んでみることをおすすめします！Hacker Newsの意見
ほとんどの問題はコミュニケーションの問題だと感じた
エンジニアはプロダクトビジョンや顧客から切り離されており、プロダクトチームはエンジニアを単なる社内の外注チームのように扱う
営業とCSは、自分たちの約束がプロダクトロードマップにどんな影響を与えるかを理解していない
結局、目標と成功指標が食い違い、みんながバラバラにオールを漕ぐ状況になる
解決策は「より良い人材」ではなく、全員が同じ目標にコミットし、それぞれの役割が全体にどう噛み合うかを理解できるようにすることだ
古い技術的負債も同じで、無視しても消えない。その負債が会社にもたらすコストとリスクを数値化し、他の目標とバランスを取りながら返済していく計画を立てる必要がある
ユーザーがすぐ隣にいるので、直接会って友人になり、彼らの日常や文脈を学ぶためのセッションだ
3週間ごとに自動でスケジュールされ、特別なアクションアイテムなしで進行する。毎回みんな驚き、小さなバグが解消され、つながりが生まれる
Slack APIと連携する自動スケジューラを作って運用しており、最も難しい部分は日程調整と参加を促すことだ
経営陣は下の立場の人の話を聞かず、下の立場の人は注目を集めるために競争する
最近うちの部署でも、コンサルタントが新しいプラットフォームへの移行を提案したが、誰も賛成していなかったのに止められなかった。結局、誰も話を聞いていない
「なぜこれをやるんですか？」という問いには、「信じてくれ、俺を」式の返答しか返ってこない
こうしたPMの振る舞いは変わらない気がする。だからエンジニアが自らプロダクトの役割を担い、コミュニケーションギャップをなくしている
多くの人が、実際には仕事に誇りを感じていないことに気づいた
ある人にとっては、ただの給料にすぎない
特に年配の同僚たちは、システムが崩壊するのを見た経験があるので、二度とそうならないようにしようとしている
新しい職場に行くたびに90日計画の中で明確なガイドラインを作ろうとするが、結局のところ核心はチームだ
変化に飢えているチームもあれば、変化を妨げるチームもある
リーダーが無知だったり、最も速くて安い選択肢だけを選んだりすると、さらに難しくなる
英国のPost Officeスキャンダルのように、内部で問題を知っていても止められなかった事例も思い出す
昔は半分以上が自営業者だったが、今では1割前後しかいない
今や私たちが作るものは「自分たちのもの」ではなく「雇用主のもの」だ
もっと頑張っても報われず、むしろさらに多くの仕事を背負わされる
結局、人はリソースとして扱われ、不要になれば捨てられる
危機の際に真っ先に解雇されるのは従業員で、CEOは数百万ドルを受け取る
こんな構造の中で、従業員が会社のために献身することを期待するのは不可能だ
あまり働かない人の方が多くの給料をもらい、あなたは自分の半分の給料の代替要員のために解雇され得る
面接はどんどん厳しくなり、功績は横取りされ、インフレは給料を蝕む
結局、「なぜ誇りが失われたのか」は謎のように見えるが、実際には答えは明らかだ
しかし企業は、ほとんどの人がやりたい仕事をできないと分かっているので、代わりにプロセスとワークフローに集中する
個人にとっては、自分の好きな仕事をしながら十分な報酬を得るのが最善だ
「新しいことを学びたくない」という開発者の言葉は、必ずしも悪いことではない
JavaScriptエコシステムのように毎日変わるフレームワーク疲れと、GoやLTSベースの技術的安定性は別物だ
安定性はプロダクトの俊敏性にも役立つ
古いC++コードベースを扱うシニアエンジニアと交渉しなければならないこともあるが、それを単純に技術的負債と呼ぶのは偏見だ
技術的負債かどうかは、コードベースに責任を持つリードICとその上司であるマネージャーだけが判断できる
面接で人間的な問題に言及するのは、不合格になりやすい方法だ
多くの面接官は技術的な答えだけを正解とみなし、人間的な洞察を無視する
私はむしろそうした観点を高く評価するが、同僚たちとは説得合戦をしなければならない
メッセージ処理量によってはバッチ処理で十分かもしれないと言ったところ、彼は「キューを知らない」と決めつけた
10年以上にわたってペタバイト級のデータプロダクトを扱ってきたと話したが、彼のシステム設計に合わないという理由で落とされた
結局いまそのチームはすべてのマイクロサービスを単一のAPIの背後にまとめる作業をしている
チームがそのバランスを理解できないなら、そのチームに加わる必要はない
Big Techのデータエンジニアとして、最も難しい問題は二つある
第一に、Conway’s Lawによって部門ごとに異なるツールチェーンとデータ哲学を持っていること
第二に、各サイロが自分たちのやり方だけが正しいと主張しながら、互いのデータは欲しがることだ
標準化が不可能な理由は、各部門のリーダーが自分たちのやり方だけが唯一の解だと信じているからだ
実際に見てみると、ほとんどのアプローチは正しくもあり間違ってもいる
見た目は技術的な問題でも、結局は人の問題だ
上流システムの変更通知がなく、下流でアラートが鳴って初めて気づく
スプリントが無意味になるほど場当たり的な依頼が多く、文書化されていない知識もあふれている
こうした経験のおかげで、より低レベルのコンピュータサイエンスを学ぶ動機が生まれた
変化を導くにはネットワークを作り、人々をまとめ、透明性をもって変化を広めていく必要がある
しかし本当の変化のためには、ディレクターやVPのような上位リーダーの支援が必要だ
AWSはこうした組織変革のためのガイドを出しており、AWS Prescriptive Guidance は優れた青写真だ
「全員を一つのソリューションにまとめよう」で始まるが、すぐに各部門ごとのプロジェクトに分裂する
これを防ぐには、強い権限を持つリーダーが必要だ
特に公共部門は互いを嫌っていることが多くてさらに難しく、民間は少なくとも雇用維持という共通目標くらいはある
Jerry Weinbergの『Secrets of Consulting』で言われているように、
「見た目は技術的な問題でも、常に人の問題だ」
技術的問題の根っこには、結局のところ人の選択、コミュニケーション、管理、能力がある
システム入れ替えプロジェクトでアナリストとして働いたことがある
既存システムは単純なラウンドロビン方式で業務を割り振っていたが、新システムは各人の業務量を考慮して公平に割り振っていた
ところが一部の従業員がシステムを操作して忙しそうに見せ、結果的に真面目な従業員がより多くの仕事を背負うことになった
私たちは問題の本質が技術ではなく監督不在にあると明確に説明したが、結局は技術的な解決策を押しつけられた
人間の本性として、仕事は与えられた時間いっぱいに膨らみがちで、こうした逆インセンティブは技術的に制御する必要がある
理想的な人間を前提にシステムを設計すれば失敗する
Jerry Weinbergは『The Psychology of Computer Programming』(1971)の頃から、
「見た目は技術的な問題でも、常に人の問題だ」という原則を強調していた
彼の著作は今読んでも十分に価値がある
私は、「仕事に誇りがない」と非難する態度が嫌いだ
ほとんどの従業員は仕事の持ち主ではなく、会社が持ち主だ
会社が特定の方向を強制し、反対すれば不利益を与えるなら、なぜ戦わなければならないのか
私たちはただの機械の歯車にすぎず、そう扱われるならそれに応じて行動するだけだ
書き手の自己中心的な態度が不快に感じられる
私は今かなりシニアな立場で、資金スポンサーや要件担当者と直接仕事をしている
彼らは「これをやってくれ、いくらだ？」と聞くが、私は30分の会議のうち18分ほどで概算見積もりを出さなければならない
彼らは技術は分からないが、金と政治の言語は完璧に分かっている
ある問題はメッセージを1通送るだけで解決したが、予算は600万ドルだった
また別のプロジェクトは他チームに取られ、3,500万ドルを燃やして失敗した
予算を握るスポンサーたちはたいてい政治が最優先で、目標は「次のポスト」だ
彼らのキャリアを見ると、「どうやってその地位に行けたんだろう」と思うことが多い