組織に失敗学でPostmortem文化の定着を試みた話

こんにちは。電通国際情報サービス金融ソリューション事業部石沢です。

本記事は当部門で5年ほど前から継続している組織としてのPostmortem（ポストモーテム）活動「失敗学」をご紹介します。様々な用語で類似の活動をされている組織も多いと思いますが、良きシステム開発を実施するためのヒントとなれば幸いです。

Postmortem（トラブル事後分析）文化について

　Postmortemは直訳すると検死解剖ですが、システム開発の文脈では現在「トラブルの事後分析」という意味で使われています。有名なところでは

他多数の書籍で紹介されている概念です。

簡単にいうと、

システムやサービスにおいて発生したインシデント（障害等）の対応が完了した後に、
その内容や解消のために行われたアクション、
再発を防止するためのフォローアップについて、
文書化しレビュー、
共有すること

を、システム開発の現場ではPostmortemと呼んでいます。障害報告書と似ていますが、顧客や上司に対する説明文書ではなく組織やチームが学習するために作成するものです。日本語だとドリコムさんがポストモーテム例を公開しているので、こちらを見るとより理解が深まるかもしれません。

　特に近年、ITシステムそのものが複雑になったこと、およびITシステムを取り巻くビジネス環境も複雑になってきたことからPostmortemのような事後検証の重要性は高まっています。われわれは専門家として様々な技術・技法だけでなく、失敗からも学ばなければいけないというわけです。

　Postmortemについてより詳しく学びたい場合は、PagerDutyの公開しているガイドがオススメです。本文は英語ですが機械翻訳でもけっこう読めます。

SIer組織におけるPostmortemの難しさ

　「発生した問題から学ぶ」と言うと反対する人はほとんどいません。しかし、これを実行し定着させていくのはなかなか難しいものです。特に弊社のようなシステムインテグレーター色の強い組織・部門では開発チームを取り巻くコンテキストが千差万別であるという課題があります。

受託開発、製品開発、サービス開発、研究開発など
顧客、ドメインも異なる
短期プロジェクト、長期プロジェクト、無期限のプロダクト開発など期間もバラバラ
アジャイルからウォーターフォールまでバラエティに富んだ開発プロセス
利用技術、言語なども様々

SIer組織はバベルの塔　もちろんチーム別にPostmortemをやっていくのであれば問題はありません。ただそうすると、組織全体の学びの範囲がだいぶ狭まってしまいます。一方で当部門はお客様のミッション・クリティカルなシステム開発を担当することも多いため、特定のプロジェクトで発生した問題はできる限り広く横連携したいという想いもあります。事業会社の開発チームでPostmortemを行うのとは、ちょっと異なる悩みがありました。

勝手連事故調（ジコチョー）モデル

　様々なコンテキストが詰め込まれたシステムインテグレーター組織でPostmortemを行うことは難しいということを説明しました。この解決策として、当部門では「失敗学」で有名な畑村洋太郎先生の提唱する「勝手連事故調」モデルを（勝手に）取り込ませていただいています。「勝手連事故調」は書籍「失敗学実践講義」で紹介されている、事故災害が発生した際に公的機関や特定企業が主体となって設立される事故調査委員会（事故調）とは異なる、手弁当で何の誓約も受けずに好き勝手に行う調査委員会のことです。「勝手連事故調」は「責任追及のための調査」ではない「原因究明のための科学的調査」を行います。この活動をモデルとして、当部門では題材となるシステム障害や開発時の失敗などについて、当事者とは異なる第三者を中心としたチームでPostmortemを行うようにしています。

　勝手連事故調モデルのメリットは次のようなものがあります。

責任追及のための調査となりにくい。第三者が中心に調査を行うので、当事者や利害関係者が深く関与すると働きがちな「チームの論理」（責任問題や、問題原因を人に帰属させがち）を排除できる
第三者が検討するので、当事者が非難されることはない
第三者の検討によって、当事者が気づきにくい組織課題や真因に近づきやすくなる（場合によっては、当事者が導出した結論と異なる分析結果を出すこともできる）
第三者が抽象化・一般化することを通じて、当事者チーム以外のメンバーでも理解できる教訓が抽出、共有できる
勝手連事故調に情報が集約されることで、当事者に対して他のプロジェクトの対応事例などもアドバイスが可能

第三者を媒介にした解決　私の所属する部門では、この勝手連事故調モデルによるPostmortem活動（内部的には「失敗学分科会」）を運用しています。

現状の運用について

　現在シニアからジュニアまで多様なメンバーで構成されたチームにて、以下のような運用を実施しています。

部門で発生した題材事象（システム障害事例や開発トラブルなど）を定期的に収集する
第三者の分析チームにて、題材を見ながらどのような論点があるか議論する（通称：味見）
第三者チームの中で担当を決めて、担当がヒアリングと調査を行う
得られた情報を分析して、分析する。組織として学ぶべき教訓を抽出する
第三者チームで分析結果と教訓についてレビューする（通称：味わい）
得られた結果を取りまとめて、部門に広く共有する

　そこそこ安定して運用できていますが、活動当初はいろいろありました。畑村洋太郎先生が著書「失敗学のすすめ」等でも述べていますが、日本人は「失敗は恥」と考える文化があります。活動初期、発生トラブルのヒアリングに行こうとすると担当者の上司から「あれは失敗ではなかったので、ヒアリングはしないでほしい」とか「本人たちは十分に反省しているので、そっとしておいてほしい」などという意見を受けることもありました。これらはまさに「失敗は恥」という文化に起因するものでしょう。

　活動継続により、この問題については組織として乗り越えることができました。いまはプロジェクトでトラブルが発生すると「おっ、これは失敗学行きだね」「しっかりと教訓にしていこう」という前向き（？）な会話も増えています。地道な活動によっていくらかは「失敗は恥」から「失敗は学びのチャンス」に変えられたと思います。

　またプロジェクト横断の問題事例共有をしていく中で、トレンドの分析もできるようになりました。複数のプロジェクトで同じようなトラブルが発生していれば、それは組織としての教育施策やサポート体制の不足かもしれないと疑うことができます。必要に応じて臨時的に部署内で勉強会などを開催して補強するようになりました。

　加えて、当初は想定しなかった意外な効果として、勝手連事故調である第三者チームが「学習の場」としても有効であることがわかりました。第三者チームの年次的にもスキル的にも多様なメンバーで、フレッシュなトラブルを題材に「どうやって分析するか」といった議論に始まり、「そういえば昔はこういう事がよくあったなぁ」「過去にこういった対応を実施したことがあった」などという組織の暗黙知の交換まで行われるようになりました。経験値の継承という意味でも良い場になっていると考えています。