失敗の本質

『失敗の本質』は日本で非常に有名な本だ。著者は第二次世界大戦中の日本陸海軍のさまざまな挫折を鏡として分析し、組織が制度、文化、プロセスにおいていかにして徐々に自己を弱体化させていったかを読者に示している。日本陸海軍の問題を分析したものではあるが、その原因の分析は現代の組織論にも非常に当てはまる。

失敗は往々にして一瞬の過ちではなく、長期的な制度の不均衡と文化的な惰性の結果である

プロジェクトの進行において、失敗は通常、単一の原因で起きるのではなく、小さな問題の積み重ねによって生じる。

本書で挙げられている原因をいくつか紹介する：

• 権限と責任の分散
• 情報の隠蔽とフィルタリング：下層が実情を報告できない
• 物資よりも精神論の重視
• 教条主義化（ドグマ化）
• 反省と改善の欠如

組織が悪い知らせを隠蔽することに慣れ、疑問を持つことよりも服従を尊び、成功の指標を狭小な単一の定量的目標に落とし込んでしまうと、外部からの圧力がかかった際に極めて脆くなる。

著者は事例を通じてこれらの要因を分解し、構造的な欠陥を修正しなければ、個人の英雄的行動や一時的なその場しのぎで全体的な趨勢を逆転させることはできず、ましてや武士道精神だけで戦況を好転させることなど不可能であると説明しようとしている。

ソフトウェア開発

情報

例えば、現場のエンジニアがリスクやユーザーのペインポイントを報告できなくなると、上層部は歪んだ情報に基づいて意思決定を下すことになる。

第一線に立っていない開発関係者が、どんな問題に対してもまず口にする反応が「この機能（何でもいいが）はこんなにシンプルなはずなのに、なぜそんなに時間がかかるんだ？」というものだとしよう。

しかし、大半のソフトウェア仕様はもともと非常に曖昧で、常に変化するものであり、コーディングの中にも多くの探索が必要な部分が存在する。開発とは単に機能を実装するだけでなく、過去の経緯や既存コードへの統合方法、今後の開発をいかにスムーズに進めるかまで考慮しなければならないのだ。

過去の成功体験に囚われない

LLMやAIが絶えず進化する時代において、多くの仕事の進め方は徐々に変化していく。この時代において「知行合一」は素晴らしいアプローチだ。しかし、過去の成功にとらわれて疑うことをやめたり、何の反省や変化も行わなかったりしてはならない。

失敗から学ぶ

ソフトウェア開発において、バグや想定外のトラブルは必ず発生する。ある程度の規模の企業であれば、通常はインシデントレポートの仕組みが整っているだろう。仮に今日、システムが突然ダウンして起動しなくなったとしよう。開発者や上層部の反応はどうだろうか？ 怒り、責任の押し付け合い、戦犯探しをするのか、それとも事故による被害を最小限に抑えるための標準プロセスが存在しているだろうか？

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

失敗から経験を学び、今回犯した過ちを二度と繰り返さないようにする。これを実現するためには、マネジメント層は誰も責めない環境を作り、仕組みの中から解決策を見つけ出す必要がある。

• プロダクトはチーム全体のもの。一人の人間に責任を押し付けるのは、会社の制度に問題がある証拠だ
• コードベースはエンジニア全員の歴史的負債。もしエラーの原因を特定の人間に帰するなら、それもまた優れた開発プロセスが存在しないことを示している

何年も前に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を極めて重視し、開発者がストレスなくデプロイできるようにする
• 開発スピードには限界があることを理解している
• 開発者が開発に集中できるよう、インフラ基盤を完璧に整える
• ドキュメントやプロセスの構築を重視する
• 迅速にイテレーションを回す以上、一定の品質の犠牲は避けられないことを理解している