デッドライン読書会第56回の課題図書は「DX失敗学 なぜ成果を生まないのか」でした。
ここ最近締め切りギリギリまで読んでいるのが多かったのですが、長距離出張の機会が重なり新幹線の中でさっくり読むことが出来ました。早めの感想文です。
本書の内容
失敗学といえば、畑村さん（失敗学会の理事長）の著書が有名です。最近「新」も出てます。
「DX失敗学」の著者も失敗学会の理事をされているとのことでした。
本書の内容としては、
- DXプロジェクトの大半は失敗している
- 失敗から学ぶための原因究明の方法
- DXを失敗させる「10の真因」 → ここが失敗事例分析の章
- 組織的な対応への一考察
といった内容です。「DX」と「失敗学」については解説書は多く出ているため「失敗事例分析」（ケース）が目玉です。なお、本書のタイトルにDXとついていますが、ITプロジェクトと読み替えたほうがしっくりくる内容です。（私の感想もこのあとDXは出てこない）
ITプロジェクト版失敗原因マンダラ図
本書で最も興味深かったのはITプロジェクト版失敗原因マンダラ図です。ITプロジェクトが失敗する原因を50以上に分割したもの。
失敗原因として抽出できる語彙は個人や組織のバイアスがかかりやすいです。そのため詳細化可能な箇所と、意識すら行かない箇所もでてきて、ばらばらになりがちです。こういったマンダラ図で網羅的に抽出されていることの意味は高く、プロジェクトを鳥の目で俯瞰できるメリットがあると思います。
またこのマンダラ図の活用方法も面白かったです。プロジェクトの振り返りで活用することを推奨していますが、その振り返りのステップがだいたい下記のイメージ。
- 個人ごとに「失敗（成功）」の原因が何だったかをマンダラ図に印をつける
- 関係者で集まり抽出した失敗原因を集約
- 失敗原因を整理
- 連関図を用いて真の失敗原因を特定
- 再発防止策を検討
Step2で関係者で失敗原因を集約する際に「選択しなかった原因」についても議論をするというのが良い。選択しなかった項目が成功の原因なのか、プロジェクト特性上影響がなかった原因なのか、議論の幅を広げることが出来そうです。
失敗原因マンダラ図をいつ使うか
「プロジェクトの失敗原因の追求」に失敗原因マンダラ図を使うというノリで本書は書かれている（つまりプロジェクト終了後に実施する）が、現代のプロジェクト管理においては、いかにプロジェクト中に頻回に使えるかが応用ポイントだと思います。（なんなら育成やプレモーテムなどのシミュレーションでの活用も考えられますね）
自分が担当したウォーターフォールのプロジェクト（２年間くらいの開発期間）だと、ライフワークとしてのふりかえりはこんな頻度で行っていた。
- 月次の振り返り
- 月次で前月の改善事項をグループワーク形式で議論する
- 四半期に一度のプロジェクト健康診断
- チェックリスト・アンケートを使って網羅的にプロジェクトの状況を計測する
- 工程終了ごとの大振り返り会
- ウォーターフォール工程の１工程が終わるごとに、タイムラインを利用し長期間を対象としふりかえりをする
- プロジェクトの終結としてのふりかえり
失敗原因マンダラは四半期に一度やっている「プロジェクト健康診断」の一部として取り込めそうです。
連関図は意外にかけるかもしれない？
本書では失敗の原因（真の原因）を見つけ出すために、マンダラ図で抽出した失敗項目を「連関図」を用いて整理するステップを紹介している。本書後半の事例でいくつも失敗原因の連関図がでてくるが、初見だと「え、、、これどうやってこういう構造になったの？」と読み手はなってしまうでしょう。マンダラ図を利用し関係者で抽出した失敗原因を、どのような過程で関連させるかが本書では見えないからです。
ただ、この連関図が自分（と関係者）が作成するシーンを改めてイメージしてみると、意外に作れそうだと思いました。たぶんこれまで行ってきた原因の分析の習慣に近しいからだと思います。実務的にはMiroやホワイトボード・付箋などをつかってワークショップ形式で、あーだこーだ議論をしていく形式になるんでしょう。
となると難しいのは「真因」部分です。連関図を描きながらたどり着いた先が真因なのか、まだ意味のある先があるのかが、感覚的な判断となるんだろうなぁ（真因かどうかの判断は関係者が「腹落ち」するかどうかによると思ってます）。こういった分析手法の勘所についてはもっと勉強したい。
さいごに
読む当初に期待していたケース分析については期待外れでした。きっと執筆の際に事前調査・分析に時間をかけられなかったんだろうな…と察しました。ですが本書では「ITプロジェクト版失敗原因マンダラ図」とその活用方法から、自分の仕事にも反映できる色々なヒントが得られたことが良かったです。
ネクスト！
次は第57回ですね。9月3日からスタッフエンジニアリングの予定です。
コメント