技術
- コアシステムを6〜18か月かけて書き直すよう求める。前任のCTOを非難する。
- それぞれが異なる言語とフレームワークを使うよう奨励する。
- システムを恣意的な境界で分割し、多くのシステムが機能に関与するようにする。
- 複雑な開発環境を作る。少なくとも12個のサービスを含むサービスメッシュを動かすようにする。
- 本番環境と開発者環境をできるだけ異なるものにする。
- デプロイを可能な限りまれにする。デプロイについて極度に慎重であるよう勧める。
- コード変更や一般的なワークフローに非常に複雑なプロセスを導入する。それを「セキュリティ」または「コンプライアンス」のためだと言い訳する。
- すべての作業を作業トラッカーに記録させ、少なくとも5人のグループがレビュー、優先順位付け、承認を行うようにする。
- 当初の作業範囲外のあらゆることを禁じる。たとえばコード整理やその他の改善作業を禁じる。
- コアコンピタンスでないほぼすべてを内製する。「ベンダーロックインを避けるため」と正当化する。
- あらゆるものに抽象化レイヤーを追加するよう言い張る。抽象化されたベンダーを使い、さらに追加の抽象化レイヤーを加える。
- 非現実的に楽観的な規模を前提とした技術的意思決定を勧める。現在より少なくとも3倍以上の負荷を計画する。
- システムの共同所有を奨励する。保守に対する責任感を持たないようにする。
- ほぼあらゆるものを「プラットフォーム」として中央集権化するよう言い張る。プラットフォームチームを人手不足のままにし、他チームがプラットフォームの管轄になり得るものを構築できないようにする。
- プラットフォームチームにAPIを頻繁に作り直させ、他チームに最新版へコードをリファクタリングすることを強制する。
- 「アーキテクト」を雇い、小さな変更にも「アーキテクチャレビュー」を要求する。
- 小さな変更にも「セキュリティレビュー」を要求する。
製品
- 有用な指標を学術的な理由で無視する。たとえば「バイアス」や「遅行指標」だと言う。
- ビジネス価値と無関係な虚栄指標を選ぶ。ノイズの多い指標を選ぶ。
- すべてを「大きな賭け」と見なし、すべてが完全に完了するまでリリースしないよう言い張る。
- すべての機能を「必須」と見なし、「バージョンゼロ」の重要な一部とみなす。決して譲歩しない。
- 非常に詳細な「戦略的」計画を立てる。
- 頻繁に方針を変える。
- 明らかな改善を「局所最適化」として退ける。
- 最新トレンドを使ってリソースを縛り付ける。表面的にはもっともらしい「AI戦略」を始める。そのためにベンダーやコンサルタントへ多額の費用を払う。
- プロダクトマネージャーが時間の大半を「戦略」と「計画」に費やすよう奨励する。
- エンジニアとプロダクトマネージャーが社内で製品を使いにくい、あるいは使えないようにする。
- 社内でユーザーを「間抜け」と見なして軽視する。
リーダーシップ
- 報酬を肩書きとチーム規模に結び付け、肥大化を促す。
- 戦略、機能、または技術的複雑さについて大言壮語する。
- 新しい製品領域に参入するために高価な買収を行う。「シナジー」に言及する。買収した製品を廃棄する。
- 報告系統で点線を多用する。
- できるだけ多くの人が別チーム、別拠点、または別機能のマネージャーに報告するようにする。マネージャーがレポート対象を監督できないようにする。
- 低業績者を頻繁に別チームへ配置転換する。
- 高業績者を、成果が不確かな非常に投機的なR&Dプロジェクトに配置する。
- 些細な決定にも常に会議を要求する。
- すべての「ステークホルダー」が会議に出席しなければならないと言い張る。
採用
- 見かけ上は客観的だが、実際には主観的な採用プロセスを作る。
- 「カルチャーフィット不足」やその他の曖昧な基準で最高の人材を不採用にする。
- 「ポテンシャル」や「態度」やその他の曖昧な基準で最も弱い候補者を採用する。
- 大規模な人員拡大の約束を伴う、非常に高額な上級リーダーを採用する。
- 日和見主義者を引き寄せるために、水増しした肩書きや作られた役職を使う。
- 非常に専門化された「専門家」を雇った後、彼らが辞めないように人工的なプロジェクトを作る。
- 専門化を、別の補完的な人材を採用する正当化に使う。
プロジェクト管理
- すべてのプロジェクトについて非常に詳細な見積もりを要求する。
- できるだけ多くのチーム、理想的には別拠点のチームにまたがるプロジェクトを奨励する。
- 他チームが行った作業に依存する新しい要件を追加する。
- 高額なエージェンシーを頻繁に使う。スコープを曖昧にし、未完成のプロトタイプを社内チームに渡して仕上げさせる。
- 他チームのステークホルダー向けに複雑な「セルフサービス」システムを構築する。
結果
- 生産性を下げるのは難しい。だが、敵陣の後方にパラシュート降下してCTOとして就職すれば、それを実現できる。
- 破壊的でない人たちへ: これはチームの生産性を最大限に引き出す方法についての話である。生産性は小さなことの積み重ねで成り立つ。
- 小さなこと100個がそれぞれ5%の生産性税を課せば、すべては131倍遅くなる。エンジニアを幸せに保つには、もっともらしく見える100個の小さなことを拒まなければならない。
GN⁺の見解
- この記事は、ソフトウェア開発において生産性を阻害するさまざまな方法をユーモラスに説明している。これにより、実際に避けるべき行動が明確にわかる。
- 技術的負債を減らし、効率的な開発文化を維持することが重要である。不必要な複雑さと官僚主義を避けることが鍵である。
- チームの士気を高め、協業を促進する環境を整えることが重要である。これは生産性向上に直接的な影響を与える。
- この記事は、ソフトウェアエンジニアリングと管理の複雑さを理解する助けになる。特に初級エンジニアにとって有用な洞察を提供する。
- 類似のテーマを扱う他のプロジェクトとしては、『The Phoenix Project』のような書籍がある。これはITとDevOpsの効率を高める方法を扱っている。
11件のコメント
そんなことをしていない会社ってあるんですか？ うるうる
小さくて成功した会社でも、大きくなるとみんなああなってしまう気がします……
前の会社で指示された仕事の大半が含まれていますね。使い物にもならないプラットフォームの強制利用……標準的なパフォーマンス指標の無視……やったタスクをまたやらせる、などなど
え..?
これは完全に「保守しにくいコードの書き方：あなたも開発者として一生楽して暮らせる」って感じ……
私はドゥームエディタを使います。
ああっ..ああっ!..ああ!!.. あっ!... ああ......
いくつかは私たちの組織内でも見られるので、残念です。 ;_;
伝説の書籍「保守しにくくコーディングする方法」を思い出しますね。
私もこの本が！
「こんなに多いの？」と思うかもしれませんが、上に挙げられていることを一人または一つの組織が成し遂げることもあり得るのではないかと思います。^^
Hacker Newsの意見
CIAの提案が実際に効果的だったのか確信が持てない: そもそもCIAの提案が本当に有効だったと納得できる理由を見たことがなく、組織は自然とそういう人たちを無視する傾向がある。
会社を壊す方法: 望ましくない人材を管理職に昇進させ、採算の取れないことを最適化させるのは、会社に大きな打撃を与えうる。
破壊的なCTOになる方法: ほとんど何もせず、有能な人を排除し、責任を下に押し付ける文化を作るのは簡単だ。
公式チャネルを通した作業と書面指示の要求: 人によっては、公式チャネルを通して作業し、書面での指示を求めるほうが生産的な場合もある。
OSSとCIAの違い: OSS（戦略諜報局）は第二次世界大戦中に優れた本を作り、CIAは1947年に設立された。
ビジョンの重要性: 製品全体の動き方や、より良い未来について一貫したビジョンを持つ人々を排除することが、最も重要なステップだ。
採用セクションは更新が必要: Leetcodeの難しい問題を30分以内に解かせ、不確実性や疑いを許容しないことが必要だ。
本番環境と開発者環境の違い: 現代のアーキテクチャでは外部サービスが多いため、本番環境と開発者環境はどうしても異なり、これは開発者が常にインターネットに接続していなければならないことを意味する。
自己保身のための決定: 「サボタージュ」のための多くの意思決定は、自分のミスを隠そうとする試みを人に納得させることに関係している。
会社での「ベストプラクティス」: 記事の冒頭で示された8つのルールは、会社で「ベストプラクティス」として厳格に守られている。
コンサルタントたちの行動: 多くのコンサルタントは、こうした行動の大半、あるいはすべてを行っている。
技術業界の問題: 技術業界にはこうした行動をする人が多く、しかも彼らは自分が役に立っていると信じている。
大企業での経験: 大企業での限られた経験は、この文章の内容と非常によく一致している。