CTOに嘘をついて危機を切り抜けた事件
(GrumpyOldDev.com)- Fortune 500企業の大口顧客向けプロジェクトは、ベンダー製品への依存から始まったが、実際には大幅なカスタマイズが必要な半製品に近いソフトウェアだった
- ベンダー統合は、柔軟性のないパッケージとカスタム開発の欠点を同時に生み、8月の納品後、10月リリースに間に合わせようとする統合デスマーチにつながった
- すべての顧客取引を巨大なJSONドキュメント1つに保存する設計が性能問題を生み、当時のMongoDBのドキュメントあたり16MB制限が、実データ移行で致命的な限界として露呈した
- 会社は問題を顧客とベンダーに隠したまま1カ月遅れでリリースし、3人の社内チームでベンダー統合を置き換えるスカンクワークス的な書き直しを約2カ月で進めた
- クリスマス直前にCTOが休日勤務を命じると、チームリーダーはすでに終わっていた作業を毎日進行中であるかのように報告して開発者たちを休ませ、チームは1月のテスト日程とリリースに間に合わせた
ベンダー製品から始まった誤った設計
- Fortune 500企業で、CTOが個人的なつながりのある重要顧客のために大型プロジェクトの納品を約束した
- 中核部分は大手技術サービス企業にアウトソースされ、ベンダーは重い作業の大半を処理できる製品があると主張した
- 実際の製品は要件におおまかに合う程度で、必要な動作を実現するには大幅なカスタマイズが必要だった
- その結果、ベンダーソフトウェアとカスタムソフトウェアの欠点が同時に生じた
- 本来の設計目的とは異なることをさせるために無理やり合わせる、柔軟性のないパッケージになった
- ベンダーのメインコードベースからフォークされたため保守コストが大きくなり、いつかサポートが終了する可能性も生じた
- プロジェクト関係者はこのやり方が良くないと見ていたが、CTO直属の報告ラインが頻繁に変わる状況で、ステータス会議は「いい考えです、ボス」といった調子で進んでいった
スケジュール遅延と致命的なデータ構造
- 社内開発チームはプロジェクトの別部分を自社開発し、ベンダーは夏の間ずっと、製品はまもなく統合可能になると約束していた
- 8月にベンダー製品が納品されると、10月リリースを目指す統合デスマーチが始まった
- 9月には、リリースを阻むレベルのバグが明らかになった
- ベンダー製品は、すべての顧客取引を1つの巨大なJSONドキュメント内のJSONレコードとして保存していた
- テストデータが増えるほど性能がどんどん低下した
- 新しい取引を追加するたびに、データベースからJSONドキュメント全体を読み込み、末尾に新しいレコードを追加する方式だった
- ベンダーは取引フィールドにインデックスを追加すれば修正できると言い、この方法は一時的には役に立つように見えた
MongoDBの16MB制限と隠された書き直し
- さらに大きな問題は、ベンダーが選んだデータベースがMongoDBで、当時のMongoDBにはドキュメントあたり16MB制限があったことだった
- 10月に移行チームが実際の顧客データを投入し始めると、16MB制限に引っかかり始めた
- 会社はこの制限を顧客に隠したまま、1カ月遅れで運用を開始することにした
- 同時に、ベンダー統合を置き換えるスカンクワークスプロジェクトを開始した
- ベンダーにもこの事実を知らせなかった
- 顧客と技術パートナーの双方に中核的な状況を隠していたことになる
- 当初ベンダー側には約70人が投入されていたが、社内の代替作業には3人だけが割り当てられた
- 1人はデータベース設計
- 1人はデータベースとインターフェースするバックエンド構築
- 1人はビジネスロジックとWebサービス構築
休日デスマーチ直前の判断
- 顧客には、1月にテストする新バージョンが提供され、既存の運用開始時に受け入れた最も致命的な欠陥を修正すると案内された
- しかし、中核システム全体を約2カ月で書き直しているという事実は顧客に知らせなかった
- 元のプロジェクトはリリースまで1年以上かかったが、書き直しは3人が休日期間を含めて進めなければならなかった
- 12月中旬ごろ、プロジェクト参加者たちは依頼ではなく命令として休日勤務を通告された
- チームメンバーの大半は、すでに6カ月間、週60〜80時間働いており、燃え尽きた状態だった
- ソフトウェアのリリースは、舞台公演に似たプレッシャーと報酬をもたらす
- 数カ月または数年かけて準備した成果が、リリース日に実際のユーザーへ届く
- 開発者は「自分がやり遂げた」という感覚とユーザーの反応から強い達成感を得る
- ソフトウェアのリリースは、内向的な人のためのライブ公演のように感じられることがある
CTOに虚偽報告してチームを休ませた1週間
- クリスマスが近づくころ、3人のチームは1カ月で代替ソフトウェアをほぼ完成させていた
- まだ整理すべき機能は残っていたが、チームが燃え尽きなければ1月のテスト日程に間に合う状態だった
- CTOが休日の取り消しを命じると、チームリーダーは表向きは「OK」と答えた
- 実際には3人の開発者に「1週間休め。私が対処する」と伝えた
- チームリーダーは毎朝の必須ステータス会議に入り、CTOに対して、すでに前月に終えていた作業を進行中であるかのように報告した
- 「チームは懸命に作業しています。今日は統合マイルストーン#73に到達しました」
- 「昨日チームは良い進捗を出し、さらに別のWebサービスを完了しました」
- 開発者たちは1週間後、リフレッシュした状態で戻ってきた
- チームは1月の日程に間に合わせ、良いリリースを完了し、しばらくの間はロックスターのように感じた
- その感覚はThe BeatlesというよりHerman’s Hermitsに近かったが、それでも良かったと振り返っている
1件のコメント
Hacker Newsの意見
「納期重視」を理由に休暇を取り消して働き続けるような人には、実際に経験した立場から、もう愚かなことはやめろと言いたい
一生懸命働いたことを認められると、特に止まりにくいが、結局その時間すべてを後悔することになる
会社が製品を売るために従業員の休日や休暇を当然のように使い込む構造なら、今の問題だらけの世界を作る一因になっている
多くの人がそうすれば、さらに多くの人がそうせざるを得なくなる。一方で、誰もやらず、そうした要求自体がばかげていると行動で示せば、会社はCEOの懐が痛むとしても現実的な見積もりをするようになる
休暇の予定を伝え、代替要員を確保し、チームのカレンダーに入れ、引き継ぎをしたら、あとは普通に休めばよい
プロジェクトは来ては去り、スケジュールは自然にずれ込むこともある
プロジェクトの日程に合わせて休暇を動かし始めたら、一生休暇を取れない
例外があるとすれば、年末、四半期末、税務シーズンのように繁忙期が明確に知られている職務で、その時期にいなくなるのが不適切な場合くらいだ
いとこは2023年9月から2024年1月まで、ひどく管理されたプロジェクトを終わらせるためにほぼ毎日午前1時まで働き、休んだのはクリスマスだけだった。それも宗教上の祝日なので従業員に訴えられるのを恐れて取締役が認めたからだった
大事なことをいくつも逃し、ストレスで20ポンドほど体重が落ちた
会社には新システムへ移行しなければならない差し迫った期限があり、5年前から分かっていたのに前年まで着手しなかった
期限に間に合わなければ契約外コストとして数百万ドルがかかる状況で、最終的にチームは期限に間に合わせたが、報酬は数週間後に「職務がなくなった」という理由での解雇だった
今は50代を過ぎ、仕事探しに最悪の時期に職を探している
自分に価値があり重要だと感じることに依存していて、退勤してもほかにやることがない
中には、表彰された社員がその混乱に一部責任を負っていたケースもあった
4件目あたりになってようやく、部屋にいた上級管理職たちは会社に構造的な問題があることに気づいた
若い人たちがもし読んでいるなら、こういう話がこのように展開するかどうかは、会社と運に非常に大きく左右される
健全な会社なら、外注による実装方式そのものが始まらなかった可能性が高い
経験のある人なら始める前に結果を予想できる、あまりにも典型的な失敗パターンだからだ
もっと早い段階で、人々はCTOに「うまくいっている」と嘘をつかず、「うまくいっていない」と伝えていたはずだ
プロジェクトを救うために、より賢い、あるいは創造的な方法が必要だったなら、CTO、場合によっては顧客とも調整していたはずだ
チームがすでに燃え尽きかけているのに、休日に長時間追い込むこともなかったはずだ
マネージャーやリードは、プロジェクトの成功とチームの健康のために上層部に対抗し、必要ならチームは休日に休むべきだと主張したはずだ
「半分くらい健全な」組織では、マネージャーが意図的に曖昧にしたり情報を省いたりすることはあり、その良し悪しは状況次第だ
しかしこの話のように、マネージャーやリードが指揮系統の上に向かって繰り返し露骨な嘘をついたなら、健全な会社であれそうでなかれ、通常は非常に悪いことと見なされる
もちろん、こうした状況は後から腕組みして評価するほうがはるかに簡単だ
難しい立場や過労状態では誰でも間違うことがあるが、似たような厳しい状況に再び放り込まれたときによりよく対応できるよう、シナリオを見て学んでおくことには意味がある
こういう会社にいるなら、新しい仕事を探し始めたほうがいい
上層部の腐敗がこの程度なら修正は不可能だし、彼らがあなたをCTOにしてくれることもない
この25年間働いてきて、一度も見たことがない
修正には1年半かかり、その間は「下着」が配送済みになったという理由で販売を取り消すこともできなかった
実際には下着など売っておらずネットワークサービスだけを売っていたのに、システムが注文プロセスを閉じるのを待ってからでないと顧客を助けられなかった
その取締役会メンバーは1年後に去り、愚かなCEOをだましたことにかなり満足していたのだろうと思う
私は結局そこで解雇され、その右往左往する会社には何の同情もない
「解決策」を外注しようとして、全員に苦痛だけを増やした愚か者たちだった
実際に解決が必要な問題もあるが、半分は「社内で作らず金を節約している」という気分を味わうためだけのゴミにすぎない
結局、そもそも自分たちで作らなかったゴミを維持するために、契約費用を払い続けなければならない
問題を隠さず事実どおりに言うという意味だが、それは本当にまれなことだ
Microsoftのセキュリティメモを見るだけでもそうだ
休日にデスマーチがないというのは、銀行やFAANGで働いているならある程度当てはまる
「スタートアップ文化」のある会社なら、忘れたほうがいい
実際、自分の利害がかかると仕事に対する態度はかなり早く変わるが、そういう機会を得て観察できる会社は多くないと思う
誰にも知られず真夜中にルールを曲げながら必要なことをやり遂げたことは何度もあり、有能な人たちの中にもそういう道を通った人は多い
銀行でさえ、こうしたことを見た
会社やチームの価値を上回るような大きな金銭的賭けさえしなければ、多くのことは見逃される
やり遂げて昇進するか、昇進の可能性を自分で減らしたので新しい仕事を探すことになる、という具合だ
「ベンダー製品はすべての顧客取引を巨大な JSON ドキュメント内の JSON レコードとして保存しており、新しい取引を追加するにはデータベースから JSON ドキュメント全体を読み出して、末尾に新しいレコードを付け足していた」というくだりは、狂っているように聞こえるのが正常
似たような話で、あるファンドの投資候補について技術デューデリジェンスを手伝ったことがあるが、そのスタートアップのユーザーテーブルにはチケット／予約データも一緒に入っていた
チケット 1 件が 1 列だったので、最もアクティブなユーザーが全履歴でチケットを 5 件持っていれば 5 列が必要だった
調査した時点ですでに 500 を超える列があり、彼らは「スケール」のための投資を探していた
もちろん解決可能な問題ではあるが、想像どおり、あらゆるものが逆さまにねじれた形で設計されていて、それが最も明白な「何だこれは」瞬間だった
投資は受けられなかった
顧客と製品のデータベース全体が平文パスワードとともに、数メガバイトの公開
.js単一ファイルに保存されており、2000 年代初頭のインターネット速度で、アプリは何かをする前にそのファイルを全部読み込まなければならなかったそのうえアプリは単一の巨大ファイルで、ディレクトリには
index.1.js、index.final.js、index.newest.js、index.45.jsみたいな名前が山ほどあったベストプラクティスを知っている程度の経験はあったので、CEO のところへ行って CTO を解雇させ、
git、mysql、サーバー側ロジックと実際の構造を備えて作り直し始めたその後、このすべてが動いていた Windows サーバーがハッキングされてポルノサーバーになったのだが、私はそのサーバーを見たこともなく管理者権限もなかったのに、なぜか私の責任になった
最初の数社は本当に勉強になった
Stanford 出身だと自慢していたシニアエンジニアがそのシステムを設計した
リリースしたらスケールしないと、実際の本番データを根拠に長く議論したが、誰も聞かず、リリースから数週間で崩壊した
まもなく私はチームを移ったが、最悪なのは、そのシニアエンジニアが結局昇進し、そのシステムはまったく新しいチームに引き渡され、彼らが格闘することになった点
システム設計全体がひどく、なぜそうだったのかは想像がつくだろう
役員たちを豪華なディナーと旅行で丸め込み、めちゃくちゃな製品を渡して、今後も自分たちが必要とされ続けるようにした
話の中では CTO は何も知らない状態だった
彼の視点では、結局すべてがうまくいったように見える
週 80 時間働いた開発者たちを除けば、全員にとって勝利
この話のあらゆるものが壊れていて、主人公のやり方も含まれる
チームリーダーが人々に休暇を与え、それを嘘で隠すのは完全に受け入れがたく、会社が解雇できる領域にかなり入っている
実質的に正当な理由による解雇も可能に見える
ただ、上層部があまりにも軌道を外れているようなので、おそらく見逃され、称賛まで受けるかもしれない
彼が置かれた環境に合わせた行動のようには見える
新任のチームリードに助言するなら、ここで誇るべきことは何もなく、より良い選択は、メンバーが残業中だと大きく問題提起し、ベンダーにまともな基準を適用するか、プロジェクト範囲を通常の勤務週に合わせて見直すよう要求すること
こういう状況を何とか回るようにしてしまうと、何の得もなく人々が燃え尽きるか解雇されるだけになり得る
家族を養うために本当に切羽詰まっている状況でないなら、チームリードには狂った要求からチームの合理的な労働時間を守る責任がある
それは解雇される覚悟で立つべき丘であって、嘘をつくための丘ではない
したがって成果に影響しなかったなら、チームリーダーが人々に休暇を与え、さらには嘘をつくことも十分受け入れられる
共有していたら経営陣は何をしただろう？ プロジェクトをさらに前倒ししただろう
自分の栄光のために他人をもっと激しく働かせようとする人たちには、一発食らわせるべき
いったい誰の一日を救ったというのか？
ゴミを納品したひどいベンダー？
イエスマンで自分の周りを固め、会社で何が起きているのかまったく知らないのが明らかな CTO？
骨身を削るほど働いたのに「大丈夫、1 週間休ませてあげただろう」となった開発者たち？
従業員を気にかけない会社の恣意的な締め切りに合わせるため、全員に嘘をついた主人公？
この話はあらゆる瞬間で身震いした
私はよく働くほうだし、顧客向けのリリースを円滑にするために時々追加で働くこともあったが、この話は純粋な狂気
時々余分に時間を使えるのは、上司との信頼関係があり、いつでも真実を言えると分かっているから
実際、それこそが非難しない文化の中核概念であり、全員が真実を話すときにだけ可能になる
愚かな CTO の締め切りに合わせるために狂ったように嘘をつくのは、文字どおり正気ではない
こんな状況にいるなら、今すぐ抜け出してもっと良い職場を探すべき
「誇りと達成感」、そして燃え尽き？
「1 月のスケジュールにも間に合わせ、見事にリリースし、少しの間ロックスターになった」というくだりの「我々」は、明らかに私を意味している
運がよかっただけかもしれないが、真実を話して解雇されたことはないし、真実のほうが辻褄を合わせやすかった。
「クリティカルパス上にあるサードパーティライブラリにバグがある。バグを踏みにくくすることはできるが、ベンダーが直すまでは修正できない」とか、「ユーザー増加で思ったより早く性能問題が表面化した。修正に2か月かかる間、インフラに3倍の費用をかけて緩和するか、性能のせいで顧客を失う可能性がある」とか、「最大顧客は最初のイテレーションを受け取ってからようやく自分たちが何を望んでいるのか分かった。私たちが作ると思っていたものとはまったく違う。それを作って収益を上げるか、夢だけを追って死ぬかだ」といった具合に話す。
繰り返すが、運がよかっただけかもしれないものの、正直さは私にはうまく機能してきた。
だから他の人たちが言っているように、「検討します」と言ってからゆっくり押しのけるか、雑用に回す。
2つ目の選択肢は口を閉ざし、彼らが長い時間苦戦して失敗するのを見守ることだ。
たいてい1年ほどかかるが、2〜3か月で畳まれ、次の四半期にリーダー陣が事実上切られたのを見たこともある。
誰かに意見を求められれば懸念を外交的に説明できるが、求められなければ黙っていることもできる。
核心は、自分より上の人が手柄を取ろうとしている計画の問題点を、積極的に指摘するかどうかだ。
口にした瞬間、彼らは自分の判断を疑われたと感じ、個人攻撃として受け取る。
敵を作らずにやるのは極めて難しく、敵は長く残るし、敵1人がもたらす損害は友人が何人いても埋め合わせにくい。
だからゲームをしなければならない。
主人公が、すでに終わっていた仕事について嘘をついていたというのは本当に重要な細部だ。
毎朝CTOとの必須のデスマッチ状態会議に入り、「チームは懸命に働いている」「今日はマイルストーンの統合ポイント #73 に到達した」「昨日は良い進捗があり、Webサービスをもう1つ完了した」と言っていたが、実際には前月にすでに終えていた作業だった。
ある角度から見ると、これは低めに約束して高めに届けるようにも見える。
まだ終わっていない仕事を終わったと嘘をついていたなら、ずっと嫌な感じだっただろう。
間違いなくもっと危険だし、チームが戻ってきたときに「ここにチケットがあるが、CTOにはもう終わったと言ってあるから急いで」と言うのも、チームにとってよいことではなかったはずだ。
開発者と経営陣の相互作用は、情報の非対称性と信頼不足によって大きく苦しむ。
今、非常に古いコンパイラで動くコードベースを更新するプロジェクトをしている。
1年かけて作業し、システムの大きな塊は終わったが、かなり重要な部分がまだ1つ残っている。
経営陣はプロセスを理解しておらず、プロジェクトが最終的に成功するという確信もない。
ソフトウェアプロジェクト、とくに移行作業には失敗の歴史が長いので、彼らが不安になることを責めるつもりはない。
進捗会議は毎週だったのが、今では週2回に増えた。そうすれば速くなると思っているようだ。
たいてい直接は出席せず、中間管理職が伝達役をしている。
開発者の立場からすれば、当然これはうまくいく仕事であり、個人的に成功を疑ったことはない。
ただシステムが大きく古いため、期間が不確実なだけだ。
残っているのは数年ではなく数か月で、80/20の法則も分かっているが、すでにその20%の中に深く入り込んでいる。
経営陣にとっては完了/未完了の二値状態でしかないため進捗を測りにくく、私たちの言うことへの「信頼」がない。
それは理解できる。
私たちが1年間何もしていなくても、会議だけしていたなら彼らには分からなかっただろう。
固定価格契約なので、私たちが引き延ばす理由はないが、リスクはすべて彼らにある。
すでに多額の金を使っており、不安になっている。
外部の技術専門家の助言に基づいて良い技術判断をしたが、それでも確信が足りない。
結局プロジェクトが失敗すれば打撃を受けるのは彼らで、私たちは相対的にそれほどではない。
簡単な解決策はない。
管理職は技術的であるべきだ、とだけ言うこともできないし、その技術は彼らの中核事業でもない。
コンサルタントをさらに呼んでも、気持ちが温まることはないだろう。
私たちにできる最善は、押し進めて納品することだ。
1か月単位の塊でもよいので細分化し、すべてをサブタスクに分ければよい。
完璧でなくても、粗い部分があっても構わない。
各塊に親しみやすく面白い名前を付けることを勧める。
たとえばタンゴ、チャチャ、ワルツのような古典的なダンス名がよい。
管理職との会議を設定し、上級管理職も含め、中間管理職にはデイリースタンドアップへのオブザーバー参加を求めればよい。
全員を立たせて会議が短く終わるようにし、リスト上の作業に対する進捗を追跡する必要がある。
作業が1つ追加されたり少し遅れたりしても、全体として近づいてさえいれば人々を驚かせない。
私たちは2人とも実際のデプロイが大きな山場だと分かっているが、準備ができるまでは彼らに言わなければよい。
遅延は経営陣を不安にさせるし、それは理解できるが、会議を増やしても速くはならない。
PMが毎日30分チェックインして、「支援し、プロジェクトを正常軌道に戻すために必要なものを提供する」と言うのは役に立たない。
必要なのは会議を減らすことだけだ。
障害は時間だけであり、その時間が障害になっている理由も、そもそも上層部が非現実的なスケジュールに固執したからだ。
結局、開発者を信じていない姿を見せることで、適切な開発者を採用したという自分たちの管理能力も信じていないことになる。
彼らは自分たちの仕事の中核部分の1つを非常にまずくやっている。
1年がかりのプロジェクトが完了/未完了の二値状態であってはならない。
扱える進捗指標があるべきだ。
最高経営陣が技術的である必要はないが、階層のどこかには、進捗状況を理解可能な形式に翻訳できる人が必ずいなければならない。
ベンダーについて確実に分かっている2つのことは、許しがたいものだった
1つは、コアロジックが Mongo のレコードを際限なく大きくすることに依存するようにしていたこと、もう1つは、平均より少し上の3人が意図的に取り組めば、約3か月で置き換えられたという点だ
そのベンダーが Fortune 500 の顧客と取引する状態にまで到達していたという事実は、この顧客に似た組織が、それほど大きくないソフトウェア作業を前にしても、どれほど無力感を覚えるかを示している
実際、そのプロジェクトの範囲は、ここにいる何人かなら趣味プロジェクトとしてでもやり遂げられそうに見える
だから Retool が技術リーダーには人気だが、エンジニアには必ずしもそうではない理由も理解できる
同じギャップを埋める別のプロダクトアプローチにはどんなものがあるのか気になる
スプレッドシートのおかげで、低い職位の誰でも、組織内の他の人を相手にせずに、数日でほぼ動く粗いツールのプロトタイプを作れるようになった
スプレッドシート以前は、上の人を説得して IT 部門に依頼を引き受けさせる必要があり、その過程だけで少なくとも3か月はかかった
その後さらに数四半期待って、Cobol や C のようなもので書かれた、要件に合わない、ほぼ動く粗い実装を受け取ることになっただろう
開発者数人とサポート担当者数人でユーザーに会いに行き、開発者たちは大きな問題を解決する新しいツールを6か月かけて作っていた
ところが、その日がエンドユーザーたちがそれを初めて見る日だった
ほどなくして私たちは州境を越えて戻っており、開発者たちはしょんぼりしていた
私の知る限り、そのプロジェクトは二度と誰の口にも上らなかった
新人に全部やらせて、シニア開発者の時間単価で請求するやり方だ
人々には AI 生成のヘッダー画像を使うのをやめてほしい
冒頭から集中が途切れる
あれはコードがモニターの後ろにあるのか？
それに奥の椅子の背もたれにもコードがあるのか？ それとも座っているのは巨大な iPad なのか？
AI 画像を使うなら、少なくとも完全に変で狂っているように見えないよう努力はすべきだ
こういう画像は文字どおり数秒で生成できるのに、選んだ中で一番よかったのがこれだったのか？