読むのがホネな技術書やビジネス書を取り上げて２週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第56回。同僚と読書期日を約束することによって消化が捗るという仕組み。過去記事はこちら。
さて、今回取り上げるのはちょっと気になっていた本「DX失敗学 なぜ成果を生まないのか」である。
失敗学といえば畑村洋太郎先生が提唱している歴史あるものだが、本書の著者は畑村先生ではなく佐伯徹さん。畑村先生も参加していたNPO法人 失敗学会の理事でもあり、本書は正統的な失敗学の文脈でソフトウェア開発プロジェクトについて書かれた本である。
なお本書のエッセンスは現時点では、幻冬舎のサイトで一部記事化されている。本書に興味がある方はこちらから見ると良さそう。
失敗まんだらと、ITプロジェクト版失敗マンダラ
本書の最大のポイントは「ITプロジェクト版失敗マンダラ」である。これを核にした分析手法と、実際の事例を使った分析事例の紹介が中心となっている。
xtech.nikkei.com
この「ITプロジェクト版失敗マンダラ」であるが、ITプロジェクト版とある通りで、オリジナル版失敗まんだらが存在する。畑村先生の「失敗学実践講義 文庫増補版 (講談社文庫)」や以下のサイトが詳しい。
本書では、各講義で取り上げる失敗事例に「失敗まんだら」を付けています。これは科学技術振興機構の「失敗知識データベース推進委員会」による失敗知識のデータベースづくりの中で生まれた、いわば失敗のシナリオが一目でわかる図のことです。 まんだら（曼荼羅）は、悟りの世界や仏の教えを示した仏教の図絵のことですが、失敗のシナリオを表現した図は、中心部分に全体を取りまとめている最上位の概念があり、そのまわりに次のレベルの概念を記すという表現方法がこれとよく似ているため、「失敗まんだら」という名前をつけることにしました。
失敗学実践講義 文庫増補版 (講談社文庫)、「失敗まんだら」について より
「失敗学実践講義 文庫増補版 (講談社文庫)」の中では、2002年のみずほ銀行システム障害や、2005年の東証売買システム障害も事例として取り上げられている。その内容はとても興味深いのだけれども、一方でオリジナルの失敗まんだらは対象が大規模事故などであることから「ソフトウェアの分野ではちょっと使いにくいなぁ」という感想を持っていたのだった。そしてついに、ソフトウェア開発向けにアップデートされた「ITプロジェクト版失敗マンダラ」が登場したのである。では、これはどうだろう。
ITプロジェクト版失敗マンダラについて
ITプロジェクト版失敗マンダラについては本書を読んでいただくか前掲のWebサイトを見ていただくとして、ひとことで言えば「使ってみたい」ものになっている。以下細かい感想である。
- シンプルに、原因マンダラのみとなった
- オリジナルの失敗まんだらは3種類ある。「原因まんだら」「行動まんだら」「結果まんだら」である。分析対象の事故（例えば航空機のエンジンの故障）が起こった場合には原因だけでなく、その後の関係者の行動も論点となりえる。また結果の影響が大きいため、しっかりと分類されるような構成となっていた。
- しかしソフトウェアシステムやサービスについては（場合によるが）人命に関わるような重大事故となる場合は少ない。その点で「原因」だけに着目しているのは使いやすいと感じる。
- プロジェクト原因の追加
- オリジナル版の失敗まんだらとITプロジェクト版失敗マンダラを対比させてみると、プロジェクト原因というカテゴリが追加されているのがわかる。これがオリジナル版には無いのが「使いにくそう」という印象の原因だったというのが改めてわかる。
ふりかえりツールとして「失敗マンダラ」は使えるのか
「使ってみたい」という感想を述べたが、どう使うかは悩ましいところである。
近年ではどのプロジェクトも（アジャイル開発かどうかに関わらず）ふりかえりを行うことが増えてきた。このマンダラはふりかえりに使えるだろうか。
わたしの意見は「ふりかえりツールにはふさわしくない」である。少なくともカジュアルに使うのは難しいのではないだろうか。
このマンダラは構造的に、根源的な組織や文化の問題に辿り着きやすく、その解決は少なくともチームで実施するようなものにはならないだろう。
よって、このマンダラはふりかえりツールというよりは、第三者評価であるとか組織課題検討など、プロジェクトとは距離を置いた形で取り扱うべきだと思う。
（あくまで印象なので、ちょっとどこかで実験をしてみたい。その結果はたぶん公開できないと思うが）
一方で、失敗に対する分析は必ずやるべきことである。
（引用註：工場や建設現場のケースでは）万一事故が発生した場合、できるだけ詳しい情報を素早くまとめて発表する必要がある。早く手を打たないと、影響が広がってしまう。
その後も事故がなぜ起こったのかを徹底的に検証する。事故につながった失敗の内容を後世に伝えるため、自社の敷地内に失敗に至った経緯を掲示している企業もある。
これに対し、DXをとりまくIT業界では失敗の原因を長い期間をかけて検証する習慣があまり根付いていない。新しい技術や製品、サービスが常に登場し続けているという事情もあり、それらを活用して企業の業績拡大などにつなげるほうを優先する傾向が強い。
DX失敗学 なぜ成果を生まないのか、第1章 失敗から学ぶための原因究明の方法、より
耳が痛い。この点はおおいに反省するべきではないだろうか。
というわけで、本書は完了。次は「スタッフエンジニア マネジメントを超えるリーダーシップ」を読む予定。
