第8章 ← 目次にもどる
同じことが起きても、結果が変わるのはどこか
ここまでの7章は、やり方の話でした。この章は、そのやり方が実際の現場でどう効いたかの話です。うまくいった案件と崩れた案件を並べてみると、意外なことが分かります。起きたトラブルの内容は、ほとんど同じなのです。
この記事の要点
- うまくいった案件も、崩れた案件も、起きたトラブルの種類はほぼ同じです。
- 差がついたのは気づいてから口に出すまでの時間でした。数日か、数か月か。
- この章は8.1「うまくいった案件がやっていたこと」と8.2「崩れた案件の内側」の2本です。
- どちらも実在の1社ではなく、日本国内でよく見る形をまとめた合成の事例です。
- 読むときは「何が起きたか」ではなく「いつ表に出たか」を見てください。
起きたことは、だいたい同じです
失敗事例を読むと、つい特別なトラブルを探してしまいます。前代未聞の障害、悪意のある取引先、無茶な要求をする役員。ところが実際に見比べると、そういう話はほとんど出てきません。
出てくるのは、こういうものです。移行元のデータが想定より汚かった。他部署の担当者がなかなかつかまらない。仕様の解釈が2通りあった。担当が1人辞めた。どれも、どの現場でも起きます。うまくいった案件でも、同じことが起きています。
この章の2本
8.1は、うまくいった案件が共通してやっていたことです。期待するようなうまい技は出てきません。出てくるのは、毎週かならず同じことをしていた、という話です。
8.2は、崩れた案件が内側からどう見えていたかです。外から見ると「なぜ早く言わなかったのか」で終わりますが、内側にいた人には、毎月それなりに筋の通った理由がありました。その理由を潰さないと、同じことが次も起きます。
事例の扱いについて、先にお断りします
この章の2本は、実在の特定企業の案件ではありません。国内のシステム開発・業務改善の現場でよく見る形を組み合わせた合成の事例です。規模は数人から十数人、期間は半年から1年、発注側にも受注側にも兼任の担当者がいる——という、多くの人が実際に置かれている条件に合わせてあります。
数字を盛った成功譚や、名前を伏せた告発は載せません。役に立たないからです。読んで意味があるのは、自分の案件で明日から見分けがつくようになる形だけだと考えています。
読むときに見てほしいところ
- 何が起きたか、ではなく、いつ表に出たか。トラブルの種類はどこでも同じです。差は時間に出ます。
- 個人の資質ではなく、仕組み。「担当が優秀だった」で終わる話は再現できません。誰がやっても同じ結果になる部分を探してください。
- 自分の案件のどこに当てはまるか。読み終えたときに1つだけ、来週やることが決まっていれば十分です。
ABではこう見えます
この章の話は、道具の話ではなく情報が動く速さの話です。とはいえ、速さは置き場所にかなり左右されます。AB Projectsのように、課題を書き込む場所と進捗を見る場所が同じであれば、「言う」ためにわざわざ会議を待つ必要がなくなります。
8.2で出てくる「報告は緑のまま、ある日いきなり赤になる」という現象は、悪い情報を出す道が月1回の会議しかないときに起きます。書き込めば全員に見える場所が1つあるだけで、この間隔は数か月から数日に縮みます。
このページで使った言葉
- エスカレーション
- 自分の手に負えないことを、決められる人へ上げることです。この章の主題は、実質これ1つと言ってもかまいません。くわしく →
- 報連相
- 報告・連絡・相談のことです。日本の現場では基本動作とされますが、悪い知らせほど滞ります。くわしく →
- 課題
- すでに起きていて、対応しないと困ることです。まだ起きていないものはリスクと呼び分けます。くわしく →
- リスク
- まだ起きていないが、起きると困ることです。「データが汚いかもしれない」は本来ここに入ります。くわしく →
- 兼任
- 本業を持ったまま別の役割も担うことです。この章の事例は、すべて兼任者がいる前提で書いています。くわしく →
- 炎上
- 遅れや不具合が重なり、通常の進め方では収まらなくなった状態です。多くの場合、原因は当日ではなく数か月前にあります。くわしく →