失敗の本質

『失敗の本質』は日本で非常に有名な本だ。著者は第二次世界大戦中の日本陸海軍のさまざまな挫折を分析し、それを鏡として、ある組織が制度、文化、プロセスの面でどのように徐々に自壊していくのかを読者に見せている。日本陸海軍の問題を分析した本ではあるが、その要因分析は組織にも十分当てはまる。

失敗はしばしば一瞬の誤りではなく、長期的な制度的不均衡と文化的慣性の結果である

プロジェクトを進める中で、失敗は通常、単一の原因で起きるのではなく、小さな部分の積み重ねで生まれる。

ここでは、挙げられているいくつかの原因を列挙する。

• 権限と責任の分散
• 情報の遮断とフィルタリング：現場が実情を報告しない
• 物資より精神論を重視する
• 教条化
• 反省と改善の欠如

ある組織が悪い知らせを隠すことに慣れ、疑問を呈するより服従を尊び、あるいは成功指標を単一の定量目標に狭めてしまうと、外部からの圧力が来たときに非常に脆弱に見える。

著者は事例を用いてこれらの効果を分解し、構造的欠陥を修正しない限り、個人の勇敢さやその場しのぎの工夫だけでは全体の流れを逆転できず、ましてや武士道精神だけで戦局をひっくり返すことなどできないのだと説明しようとしている。

ソフトウェア開発

情報

たとえば、現場のエンジニアがリスクやユーザーの痛点を報告できないとき、上層部は歪んだ情報に基づいて意思決定をしてしまう。

第一線にいない開発者なら、何か問題が起きるたびに真っ先にこう思うかもしれない。「この機能（適当に当てはめる）なんてそんなに簡単なのに、なぜそんなに時間がかかるのか？」

しかし、ほとんどのソフトウェア仕様はもともと非常に曖昧で、いつでも変わりうるものだ。コーディングの途中にも、多くの探索が必要な部分がある。開発では単に機能を実装するだけではなく、歴史的な経緯を考慮し、既存コードにどう統合するか、そして今後の開発をどう円滑にするかまで考えなければならない。

過去の成功に囚われないこと

LLM、AI が進歩し続ける時代では、多くのやり方が徐々に変わっていく。この時代において知行合一は素晴らしいやり方だ。しかし、過去の成功を理由に疑わなくなったり、何の反省も変化も行わなくなったりしてはいけない。

失敗から学ぶこと

ソフトウェア開発では、必ず Bug / 事故などに遭遇する。規模の大きい会社では、通常 Incident 報告の仕組みがある。たとえば今日、システムが突然落ちて起動できなくなったとする。開発者や上層部の反応は何だろうか。怒るのか、責任を押し付けるのか、犯人捜しをするのか。それとも、事故による損害を最小限に抑えるための標準的な手順があるのか？

事故が起きたとき、最も役に立たない解決策は感情的になることだ。

失敗から経験を学び、今回犯したミスを二度と起こさないようにしなければならない。そのためには、管理層が誰も責めない環境を作り、その中で解決策を見つける必要がある。

• プロダクトは皆のものだ。ひとりに責任を押し付けるなら、会社の制度に問題があるということだ
• Codebase は RD 全体の歴史的な共同責任であり、エラーを特定の人に帰属させるなら、それもまた良い開発プロセスがないことを意味する

何年も前に Reddit で大きな反響を呼んだ記事がある——Accidentally destroyed production database on first day of a job, and was told to leave, on top of this i was told by the CTO that they need to get legal involved, how screwed am i?

内容は、この新入社員が初日にうっかり本番環境のデータベースを削除してしまったというものだ。ある手順で、ツールの出力値をコピーせず、代わりにドキュメントに記載されていた環境変数を使ってしまったのだが、その環境変数は本番環境を指していた。最終的に、この社員はその場で Fired された。

みんなはこの話を読んでどう思うだろうか。この社員はどうしてそんなに不注意で、値が正しいか確認しなかったのか、あるいは、開発者がこんなミスをするなんてあまりに信じがたい、と思うのか。もしこうした心構えで物事を見ているなら、むしろ事故の発生に大きな打撃を受けることになる。

ある会社が幸運に頼り、本番環境のデータベースのバックアップを用意していなかったのなら、それ自体がいずれ代償を払うことになる行為だ。データを失って初めてバックアップの重要性が分かるのである。新入社員ひとりが本番環境のデータベースを簡単に削除できたということは、いずれ他の社員も同じことができるということでもある。

数多くのコメントの中には、Netflix のやり方を共有している人もいた。

詳細は忘れたが、僕の記憶では、彼らは普段から災害発生時にどう迅速にバックアップするかを訓練している。それどころか、日常的に権限設定をきちんと行い、社員が本番環境のデータベースを壊せるなら報奨を出すことさえ奨励している。

同じ問題でも、ある会社はまず責める。別の会社は制度やプロセスから着手して、人為ミスを防ぐ。

スローガンに頼らないこと

スローガンは、制度と結びついて初めて実行される。それこそがスローガンへの敬意だ。たとえば「迅速な反復、小さく速く進める」を掲げる会社は、しばしば開発成果を搾り取るための言い訳にすぎず、エンジニアの専門性をまったく尊重していない。

本当に実践するのであれば、次のような点に表れるはずだ。

• CI/CD を非常に重視し、開発者が痛みなくデプロイできるようにする
• 開発速度には限界があることを理解している
• 開発者が開発に集中できるよう、あらゆる基盤整備を完璧に行う
• ドキュメントとプロセスの整備を重視する
• 迅速な反復では、必ず一部の品質が犠牲になることを理解している