おかげで今でも社長やら部長からいろんなツッコミが来たり、失敗の原因分析をしたり、その結果の文書を上位マネジメントに報告したり、「結局何もマネジメントしてなかったってことね」とけちょんけちょんにされたり、周囲の人に迷惑をかけたりしています。。。
最悪です・・・。
上司からは「こいつは無能！」と烙印押されてるだろうし・・・。社長からは「全部勉強しなおせ」言われるし・・・。クビにしてもらった方がいくらか楽だ・・・とか思ってしまいます・・・。
こういう失敗を繰り返さない為に、自分へのログとして残しておこうかと。
＜マネジメント編＞
＜要件定義編＞
＜設計編＞
＜テスト編＞
＜実装編＞
に分けて書こうと思います。
ま、もうしばらくはマネジメントやるチャンスなんて無いんですけどね・・・。
あ、これ読んで実行して、本当にプロジェクトが失敗したぞ！！なんて人がいたとしても当方責任は取れませんので。やってみたい人は自己責任でお願いします。俺は絶対やりませんが・・・。悪しからず。
■プロジェクトを失敗させる方法＜マネジメント編＞
１．選任のPMなんて立てない。
この方法は非常に有効です。特に要員のスキルが低く生産性が期待に満たない場合は、早々に見限って上位者が手を下すべきでしょう。そうすれば、上位者はどんどん仕事を抱えることになり、プロジェクトを俯瞰して見る人がいなくなるので、問題解決する暇を無くすことが出来、プロジェクトは1ヶ月も待たずに破綻させることが出来ます。しかも、上位者は自分の作業に没頭していて問題に気付く間も無いので、問題はどんどん大きく多くなり、非常に効率よくプロジェクトを破綻させられます。
２．プロジェクト計画を立てない。
これは基本ですね。計画なんて立ててはなりません。スケジュールなんてのはどうせ変更されるしどうせ伸びるのです。計画を立ててしまうと、方針が明確になってしまい、みんなが同じ方向を向いて走ってしまいます。また、進捗や状況を測るものさしをプロジェクトに提供してしまいます。これでは、効率よくプロジェクトを破綻させられません。ガントチャートと、ゆるゆるなWBS、曖昧なプロジェクト計画書、というあたりで止めておいてくれれば、そのプロジェクトはうまく破綻させることができます。
３．見積もりは出来る限りKKD(経験・カン・度胸)で行い、絶対にFPなんて使わない。
見積もりはKKDで行うべきです。決して、過去の例から作成したFPなんて使ってはいけません。また、出来る限り見積もり基準も曖昧にして秘匿すべきでしょう。顧客とは、強気で交渉に臨み、「この機能は難しいんですよ」というのを技術用語を交えて難しく説明し、はぐらかしましょう。「かかるものはかかるんです！」などと怒りをあらわにするのも有効かも。
４．レビューは適当にやり、証拠なんて残さない。
最近は内部統制やらCMMやらがうるさくなってきて、あらゆるレビューの記録を残せ、レビュー時の指摘は追跡できるようにしろ、などとうるさいですが、もちろんそんなことをしてはいけません。そんなことをしたら、「○月○日のMtgで決まりましたよね」なんて後から指摘できてしまいます。出来るだけ、大事なことは頭の中に入れておき、文書化しないようにしておきましょう。
５．リスク管理はそのうちやる、と言ってやらない。
リスク管理票は、できるだけ空欄のままにしておくべきでしょう。どうせ始まってみないと何も分かりませんので、放置しましょう。事前に考えたリスクは、大体実現するものです。実現した場合には、阻止するつもりを見せつつ受け入れましょう。これでドンドン破綻に近くなります。
また、リスクの内容は、その対策内容は、出来るだけあいまいに書きましょう。対応策を明確に「どこそこの誰をアサインする」とかまで書いてしまうと、いざ実際にリスクが顕在化したときに、リスクを軽減できてしまいます。。。
６．進捗の確認は適当にパーセントで
数値的・定量的に進捗を把握してしまうと、問題点がすぐ明確になってしまい、非効率的です。手抜きや抜け漏れが発生しやすいよう、問題点の発覚は後であれば後であるほどいいので、出来るだけ秘匿し、後で報告しましょう。情報収集も、「今○○パーセント」という、抽象的な聞き方をしましょう。パーセントは作業者の主観であることが多く、事実とはかなりかけ離れていることが多いので、非常に無駄なく偽の情報が集められ、効率よくプロジェクトを混乱させることが出来ます。
・・・書いてて嫌になってきた・・・。
まだ続きます。今日はこれで終わり。。。
