IT系、特にソフトウェア開発が「3K職業」呼ばわりされて大分経ちます。
実際、当時まだ会社員だった私の身の回りでも、1999年から2003年位まで、ITプロジェクト＝デスマチ位の勢いだった気がします。
その後、自身で起業して最初も営業的に無理な案件もこなさなければならず、やはり当初2-3年はデスマチになるケースが多かった気がします。
しかし、この2年ほど弊社は「忙しいのは無論忙しい」ですが「徹夜だ休出だ」といういわゆるデスマチ状態には殆どならなくなっています。
現在4つのプロジェクトを回していますが、どのチームもそういった状況にはなっていません。
「「やりがいのある忙しさ」を会社全体で共有できているのかなー。」と思ってみたりしています。
そのことを取引先や応募者に説明すると「3K職場でなくなった理由」を聞かれます。
しかし、いままでは「弊社はそういうものです。というか仕事とは（長くやりがいをもって続けるために）本来そうあるべきです。」としか説明してこなかったので改めて理由を考えてみました。
ちょっと社内を見渡して思った理由は・・・
少人数で出来ていないことは大人数ではもっと出来ない
人を入れればプロジェクトは救われる？？
プロジェクトの人員増加の前に考えなければいけないこと
往々にして、プロジェクトの進捗が芳しくなかったり、スケジュールが厳しくなると、打たれる対策は「人員の追加」です。
しかし、人員の追加はプロジェクトを救う方法の1手段でかつ最後の手段にすぎません。人員の追加はコストが上がり、教育や管理で一時的に生産性が下がるという状況を生みます。
そんなリスクがあっても、人員を追加をする以上はその効果がリスクに見合う必要があります。
「そもそも問題の解決になっているか？」を検討せずに、そのリスクを背負い込むワケにはいきません。
にもかかわらず、「まずは人員増強」を最初に行うプロジェクトが多いのには違和感を覚えざるをえません。
なぜITプロジェクトとは失敗するのか？
おそらくこの命題は、ずっと多くのIT関連雑誌などで語られてきたことでしょう。
それは、簡単です。失敗したほうが開発ベンダーが儲かるからです。
以前にも「現在の人×月で計算するITプロジェクトの費用はSIベンダーにとって
効率よく早くプロジェクトを完遂させれば損をしてしまう。
逆になるべくダラダラと人を増やしながら対応するのが一番儲かる」と、お話しました。
この異常な価値観。「質が良いほど評価されない」問題点はそのまま「お客様」の不利益につながっていきます。