プロジェクトを進めるうえで、僕の失敗経験をもとに
炎上に導く習慣を7つご紹介します。
これをやったら、高確率でプロジェクトを炎上させることができます。
もし同じような習慣がありそうだなと共感するところがあれば、
炎上リスクが高いかもしれません。
これは、システム構築プロジェクトの事例ですが、
他のプロジェクトでも当てはまると思います。
僕が体験したり目撃した「プロジェクトを炎上に導く7つの習慣」を目次にそってご紹介します。
体制、役割を明確にしない
まず、体制や役割が不明確なままプロジェクトを進めると、問題が勃発したときに責任の所在で揉めます。
多くの場合、ひとつの問題をきっかけに別の問題にも気づき責任の押し付け合いに発展するケースもあるのではないでしょうか。
僕もこういったケースを経験したことがあります。
体制を決めて満足
PM、PLなど、PMOなど、プロジェクト計画書に役割と名前を書いて満足。
それぞれが何をやるか、関係者の共通認識がないままプロジェクトが進すすんでいることがあります。
小規模なプロジェクトの場合に見かけた例ですが、
とある組織では、同じような小競り合いが毎回起きていました。
それ、PLの仕事なのになんでやってないの？
いやいや、それはPMの仕事でしょう。
押し付けないでくださいよ！！
体制自体を曖昧なまま
上記の例以前に、体制自体がそもそも曖昧な例もありました。
小さな組織で、ふんわりと関係者とやらないといけないことが決まっていて
- 気づいた人が、気を利かせて動く
- メールを受けた人が、自分の仕事だと思って動く
この連続で、事が進んでいる感覚です。
責任感の強いメンバーが居れば、問題に気づかないまま終わるケースもありました。
僕が見たある組織では、
外から入った新しい人にも、特に説明もなく同様のふるまいを求めていました。
「各メンバーの能力と自主性があればうまく行く」
ある意味理想かもしれませんね。
そういう状態が作られている素晴らしい組織であれば大丈夫かもしれません。
僕の見た組織では、まだその状態に届いていなかったためか後々修復が大変な問題に発展していました。
課題の期限を決めない。安易に伸ばす
プロジェクトを進めると、様々な課題が上がっていきます。
その際、「この課題をいつまでに解決しないと、何に影響があるのか」
考えたうえで適切な期限を設定するのが基本です。
期限設定のない課題一覧を見たときは、炎上の兆候かもしれません・・・
課題管理がまともにできていないことは論外として(たまにありますけど)
期限を決めなかったり、遅れに気づくととりあえず1週間延ばしてみたり、検討を後回しにしてしまいます。
これを続けていくと、
工程以降などの大きな節目で、慌てても間に合わない問題につながります。
成果物のイメージは担当まかせ
システム構築などの場合、一般的にWBSを使ってプロジェクトを進行していると思います。
WBSのタスクで作成する成果物は、次の作業のインプット情報になるのですが、次の作業の担当者が違う場合は特に要注意です。
成果物イメージを担当者まかせにして進めてしまうと、それでは情報が足りず、後続の作業者が動けないといった問題が起こります。
内容によっては大きな手戻りにつながる無視できない火種です。
今回は我ながらキレイな設計書ができました。
あとの開発はよろしくおねがいします。
え？？こんな設計書じゃぜんぜん情報足りないよ！！
開発に着手できるわけないでしょ！！
要件を曖昧なまま、その場しのぎ
そのプロジェクトでは、お客様(リクエスト部門)の要件をヒアリングして、
構築するシステム仕様を詰めていました。
パッケージの機能で実現できるかできないか、
要求されるカスタマイズが技術的にできるかできないか、
予定通り費用やスケジュールが収まるか収まらないか
要所要所で、確認しながらすすめていました。
この画面、〇〇△△のところを、XXXしたいから
〇〇じゃなくて◆◆で、ばばーって感じにできます？
たぶん大丈夫だと思うのでとりあえずこれで。
細かいことは後で考えましょう
(よく意味わかんなかったけど、とりあえず合わせておこう)
曖昧なまま、勝ってな解釈で実際に作ったあと・・・
あの画面、◆◆になってないじゃないか！！
◆◆だからこれがこうなってないとだめだよ
ばばーって感じだって言ったでしょ！
◆◆ってそういうことですか、、
これは今からでは期限内で対応できないです・・・
（そもそも「ばばー」ってなんだよ、わかんないよ・・・）
長文メールで仕様や課題を議論
「課題管理表」を使ってプロジェクト管理をするルールになっていましたが
一部の仕様調整をめぐって、チーム間で長文メールの応酬がはじまりました。
それも何度も・・・
その結果
最終的に設計書にも課題管理表にも記載のない仕様が漏れ、テスト終盤で火を噴きました。
Aチーム：「〇月〇日のメールで確かにこう書いていた！！」
Bチーム：「その後の会議でこう言ったはずだ！！」
どっちでも同じです。
ちゃんと設計書に落とし、お互い確認しましょう。
会議のアジェンダがないままだらだら
これも昔僕が経験したプロジェクトの状態でした。
そのプロジェクトでは、定例会議の時間は決まっており関係者は集まっていました。
時間になると、なんとなく話がはじまり、それぞれが「言いたいこ」とを言いあう場が定例会議でした。
アジェンダは決まっておらず、課題管理表を見たり見なかったり。
議事録もカオスです。
議論の効率も悪く、時間内に終わらず時間切れで散会。
十分な議論が進まないままプロジェクトが進行するので、曖昧にしていた部分が後半に大きな問題に発展する要因になります。
プロジェクトは「炎上するもの」という固定観念
プロジェクトに問題が発生すること、課題が上がることはあたりまえですが
「炎上するものだから」と開き直り、同じような過ちを繰り返している組織がありました。
いろいろな組織を見てきましたが、組織的にそういう風潮が根付いているところが確かにあります。
楽に仕事をしたい僕にとっては、「最大の敵」といっても過言ではないものでした。
こういうマインドの集団は、炎上に向かう習慣が根付いています。
上記にあげた要素がいくつか当てはまり、対策をとるための努力を惜しみます。
「炎上するまで頑張らない」
その理由は、「いま頑張っても、どうせ炎上するんだから・・・」
まとめ
僕の個人的な意見ですが、プロジェクトを炎上に導く7つの習慣をご紹介しました。
おさらいします。
- 体制、役割を明確にしない
- 課題の期限を決めない。安易に伸ばす
- 成果物のイメージは担当まかせ
- 要件を曖昧なまま、その場しのぎ
- 長文メールで仕様や課題を議論
- 会議のアジェンダがないままだらだら
- プロジェクトは「炎上するもの」という固定観念
意識しないと、に日常的にこうなっているプロジェクトは結構あります。
仮にこの習慣を変えると、炎上するリスクを下げられると思いませんか？
