炎上プロジェクトとQCD崩壊の関連性について

公開日: : 最終更新日:2014/07/14 開発日誌 , , ,

炎上プロジェクトとQCDの崩壊には関連性があった

この業界にいると「プロジェクト炎上」に巻き込まれることがしばしば。
なんとか避けようとしても炎上プロジェクトの方からすり寄ってくる始末。

何度か炎上プロジェクトを経験していくにつれて、プロジェクト炎上具合の進行とQCDの崩壊に関連性があるのではないかと気がついた。
今日はそれについてちょっと書いてみる。

プロジェクトとは何か

「プロジェクト」という言葉をよく業界人は使うがまずはその定義をしてみます。

プロジェクトとは

「プロジェクト」とはPMBOKでは


プロジェクトとは、独自の製品、サービス、所産を創造するために実施される有期性の業務である。

書かれています。
ここで重要なのは「有期性」。
そう、プロジェクトには必ず「終わり」があります。いやあるはず。でも炎上プロジェクトではこの「終わり」がとてつもなく遠くにあります。
それは後ほど。

PMBOKとは

PMBOKとは「プロジェクトマネジメント知識体系ガイド(A Guide to the Project Management Body of Knowledge.)」の略で
プロジェクトマネジメントの知識体系をまとめたもの。

QCDとは

QCDも一応説明を書いておきます。


品質(Quality)、価格(Cost)、納期(Delivery/Time)の頭文字をつなげた略語。
ビジネスにおいて重視すべき3つの要素のこと。

プロジェクト炎上の初期・価格(Cost)の崩壊

プロジェクトが炎上し始めると当然ながらプロジェクトマネージャと呼ばれる人たちは懸命に対策を打ち始めます。
最初に始めるのが「遅れは残業で取り戻そう」という試み。
次第にメンバーが定時で帰れなくなり気が付くと全員が残業状態。
これでなんとかなれば良いですが、炎上の度合いが強くなると「休日出勤をして取り戻そう」と。
でも、これでも何ともならない状況になると「メンバー以外でも手の空いている人には手伝ってもらおう」と悪化します。

この状況になると上層部は「価格(Cost)をかけてでもなんとしてもプロジェクトを完成させてくれ」のようなことを言い出だします。
ここで見事に赤字プロジェクトへまっしぐら。
QCDのうち、価格(Cost)の崩壊を迎えます。

プロジェクト炎上の中期・品質(Quality)の崩壊

メンバーを投入してプロジェクト炎上が消化できればよいが、余程優秀なメンバーが投入されない限り
残念ながらたいていの場合は悪化します。
メンバー投入の準備や、仕様説明などなどに時間を取られ既存メンバーの負担になることもしばしば。
こうなるとプロジェクトマネージャーはやってはならない行動に出始めます。

まずは「ドキュメントを簡略化(ひどい時は後回しに)しよう」などと言いだします。
こうなってくるとメンバー間での意思疎通や仕様確認なども行われなくなり、不具合がいっぱい
出るようになり、ますます進捗が芳しくなくなります。
本来はここはじっくり品質を上げるためにドキュメントのチェックやきめ細かいテストが
求められるのですが、そんな余裕もなくプロジェクトマネージャーはついに禁じてを出します。
「よし、単体テストやっている時間がもったいないので、出来たものから結合テスト進めます。
なので、しょーもないバグは出さないようにコーディングして。」なんてこと言います。

冷静に考えればわかるのですが、単体テストしてないようなものを結合テストしても
上手く動くわけがない。ここでプロジェクトマネージャー逆切れ。
「メンバーのスキルが低すぎる!!!!」

かくして、品質(Quality)の崩壊となります。

プロジェクト炎上の末期・納期(Delivery/Time)の崩壊

この頃になると「とにかく納期だけは守ってくれ。お客様に迷惑をかけることはできない。」と上層部が騒ぎ出します。
しかしながら出来あがってくるプログラムは単体試験未完了レベルのとんでもないプログラムばかり。
当然、お客様に納品できるレベルではありません。
それでも頑張ります。ぎりぎりまで頑張ります。
最後には結合テストしてなくてもシステムテストなんか始めちゃいます。
でも出てくる不具合は「登録ボタン押したらプログラムが落ちた」とか「登録ボタンすら押せない」なんていう
レベルの不具合のオンパレード。

あ~あ、これじゃ納品できない・・・。

ここについに納期(Delivery/Time)の崩壊が訪れます。

まとめ

このようにプロジェクトの炎上するにつれ
価格(Cost)の崩壊→品質(Quality)の崩壊→納期(Delivery/Time)の崩壊
と進みます。
後に残るのは「燃え尽きた兵士たち」と「動かないプログラム」のみ・・・。


こうならないようにしましょう。自分も含めて・・・ね。

スポンサーリンク
  • このエントリーをはてなブックマークに追加
  • 14 follow us in feedly

関連記事

怒りの女性

IT業界が以外とIT化されてないのかも知れません

実はIT業界が以外とIT化されてないのかも知れません。 今の会社が中小の独立系ソフトウェアハウ

記事を読む

怒りの女性

IT業界のキャリアマップについて考えてみる

IT業界のキャリアマップ 今回はIT業界のキャリアマップについて考えてみます。 IT業界の標

記事を読む

no-img

システム開発工数見積りの10個のチェックポイント

工数見積りレビュー時のチェックポイント システム開発の工数見積りの結果をレビューする時に 気をつ

記事を読む

a0001_013635

要求定義の整理は「MosCow分析」を使って解決する

要求定義の段階でお客様の要望が膨らんだり曖昧になるのはよくあることで そんな時に役立つのがMosC

記事を読む

no-img

IT業界でのシステム開発見積りの謎

IT業界で仕事をしていると必ず「システム開発の見積り」を 行う事になります。 その中で「システム

記事を読む

no-img

資格があだになることも

この記事は削除しました。

記事を読む

no-img
IT業界でのシステム開発見積りの謎

IT業界で仕事をしていると必ず「システム開発の見積り」を 行う事にな

怒りの女性
IT業界のキャリアマップについて考えてみる

IT業界のキャリアマップ 今回はIT業界のキャリアマップについて考え

怒りの女性
IT業界が以外とIT化されてないのかも知れません

実はIT業界が以外とIT化されてないのかも知れません。 今の会社

a0001_013635
要求定義の整理は「MosCow分析」を使って解決する

要求定義の段階でお客様の要望が膨らんだり曖昧になるのはよくあることで

no-img
システム開発工数見積りの10個のチェックポイント

工数見積りレビュー時のチェックポイント システム開発の工数見積りの結

→もっと見る



PAGE TOP ↑