2012年10月17日
失敗は成功への近道?
「失敗は成功への近道」なんて言葉を耳にしたことがある。しかし、本当に正しいのか僕は疑問に思う。
僕の職業はシステムエンジニア。ビル・ゲイツやスティーブ・ジョブズも広い意味で同業者と言えるのだろうが、僕の現状は程遠いものだ。
僕の仕事内容を簡単に説明すると、ユーザーからこういうシステムがほしい、という要望を聞き、作る。というのが仕事。僕たちが売っているものは、原価で言えば数十円のCD一枚と人間である。つまりそのシステムを作る開発者の人件費を売っている。
僕の会社で言えば、単価は月80万円。一カ月3人で一年間の開発期間があれば、3人×80万×12カ月=2880万円の開発費用となる。これぐらいの計算を細かく説明すると馬鹿にしてるみたいなのでもうやめるとして、僕たちの売上は開発期間と開発人数で決まるため、できるだけ多くの期間と人数で契約を取りたいと考えている。そして、契約した期間よりも早く、より少ない人数で完成させることができれば、より多くの利益が発生する。
と、全てがそうなればいいのだが、仕事がほしいあまり、無理な契約人数で受けてしまうことも少なくない。そんな時は必ずと言っていいが、そのプロジェクトは破たんする。
結局人数を増員するか、頭を下げて期間を延ばしてもらうかのどちらかになってしまう。しかし、ここで言う、増員と期間延長は受注側の自己負担がほとんどである。つまりただ働き。
このように契約工数以上の実働が発生したプロジェクトは、失敗プロジェクト、赤字プロジェクトとして苦い記憶となる。
僕もそのような失敗プロジェクトを経験したことがある。その時は増員ができなかったため、その分自らが働くしかなかった。通常、1カ月の労働時間が160時間(1日8時間×20日)のところ、450時間働いた事があった。そのプロジェクトでは同じようなことを7人で半年続けた。
そして今、当時の反省を生かし、新しいプロジェクトが始動された。始動する前には前回の失敗の原因調査、分析、対策を検討し、今回の新規プロジェクトにどのように生かせるか話し合った。
しかし、僕はこのような反省を生かすやり方がどうも好きではない。というより、意味さえ感じない。
失敗から成功を導くためには、
@失敗した→A原因調査→B分析→C対策検討→D対策実行→結果(成功or失敗)
となるが、失敗から成功に辿り着くのであろうか?
失敗の反省を生かしたところで、その反省が成功する保証はどこにもない。
見たことのないきのこを食べ、食中毒になったとする。そのきのこを食べてはいけない、という経験を積むことができたとしても、どのきのこが食べれるかは分からない。それと同じように、失敗からは、こういうやり方はやってはいけない、という経験は積めても、こうすればいいね、という成功手段は分からない。
それに比べ、成功から成功を導くことはどうだろう。
@成功した→A原因調査→B分析→C応用策検討→D応用策実行→結果(成功or失敗)
となるが、一度成功したことを真似て次の成功に辿り着くことは、イメージしやすいのではないだろうか。確かに、成功例を真似ても結果的に失敗することはあるだろう。成功したことがあるということが逆に過信になることもあるだろう。しかし、根拠のない反省よりも、結果のある実績を信用した方がいいと僕は思う。気分的にも前向きになれるし。
ただ、今の新規プロジェクトは、成功例も取り入れなければ、反省したことも忘れている上司を中心に動いている。すでに失敗、が頭を埋めている。
僕の職業はシステムエンジニア。ビル・ゲイツやスティーブ・ジョブズも広い意味で同業者と言えるのだろうが、僕の現状は程遠いものだ。
僕の仕事内容を簡単に説明すると、ユーザーからこういうシステムがほしい、という要望を聞き、作る。というのが仕事。僕たちが売っているものは、原価で言えば数十円のCD一枚と人間である。つまりそのシステムを作る開発者の人件費を売っている。
僕の会社で言えば、単価は月80万円。一カ月3人で一年間の開発期間があれば、3人×80万×12カ月=2880万円の開発費用となる。これぐらいの計算を細かく説明すると馬鹿にしてるみたいなのでもうやめるとして、僕たちの売上は開発期間と開発人数で決まるため、できるだけ多くの期間と人数で契約を取りたいと考えている。そして、契約した期間よりも早く、より少ない人数で完成させることができれば、より多くの利益が発生する。
と、全てがそうなればいいのだが、仕事がほしいあまり、無理な契約人数で受けてしまうことも少なくない。そんな時は必ずと言っていいが、そのプロジェクトは破たんする。
結局人数を増員するか、頭を下げて期間を延ばしてもらうかのどちらかになってしまう。しかし、ここで言う、増員と期間延長は受注側の自己負担がほとんどである。つまりただ働き。
このように契約工数以上の実働が発生したプロジェクトは、失敗プロジェクト、赤字プロジェクトとして苦い記憶となる。
僕もそのような失敗プロジェクトを経験したことがある。その時は増員ができなかったため、その分自らが働くしかなかった。通常、1カ月の労働時間が160時間(1日8時間×20日)のところ、450時間働いた事があった。そのプロジェクトでは同じようなことを7人で半年続けた。
そして今、当時の反省を生かし、新しいプロジェクトが始動された。始動する前には前回の失敗の原因調査、分析、対策を検討し、今回の新規プロジェクトにどのように生かせるか話し合った。
しかし、僕はこのような反省を生かすやり方がどうも好きではない。というより、意味さえ感じない。
失敗から成功を導くためには、
@失敗した→A原因調査→B分析→C対策検討→D対策実行→結果(成功or失敗)
となるが、失敗から成功に辿り着くのであろうか?
失敗の反省を生かしたところで、その反省が成功する保証はどこにもない。
見たことのないきのこを食べ、食中毒になったとする。そのきのこを食べてはいけない、という経験を積むことができたとしても、どのきのこが食べれるかは分からない。それと同じように、失敗からは、こういうやり方はやってはいけない、という経験は積めても、こうすればいいね、という成功手段は分からない。
それに比べ、成功から成功を導くことはどうだろう。
@成功した→A原因調査→B分析→C応用策検討→D応用策実行→結果(成功or失敗)
となるが、一度成功したことを真似て次の成功に辿り着くことは、イメージしやすいのではないだろうか。確かに、成功例を真似ても結果的に失敗することはあるだろう。成功したことがあるということが逆に過信になることもあるだろう。しかし、根拠のない反省よりも、結果のある実績を信用した方がいいと僕は思う。気分的にも前向きになれるし。
ただ、今の新規プロジェクトは、成功例も取り入れなければ、反省したことも忘れている上司を中心に動いている。すでに失敗、が頭を埋めている。
【このカテゴリーの最新記事】
-
no image
-
no image
-
no image
-
no image
-
no image
この記事へのコメント