失敗から学ぶ人、学ばない人【その1】:ITエンジニア進化論
世の中に仕事で失敗しない人はまずいない。しかし、そうした失敗を糧とできるかどうかは個人差が見られる。失敗から学ぶ人と学ばない人の違い、そして、そもそも、失敗から学ぶとはどういう意味なのだろうか。
世の中に仕事で失敗しない人はまずいない。デスマーチといった言葉に代表されるように、世の中には目を覆いたくなるようなプロジェクトが幾つも存在しているのはご存じのとおりである。しかし一方で、そうしたプロジェクトを悲観するだけでなく、むしろ糧にしてしまうタイプの人も存在する。これは言い換えれば、「失敗から学ぶ」すべを知っている人と言うこともできる。失敗から学ぶ人と学ばない人の違い、そして、そもそも、失敗から学ぶとはどういう意味なのだろうか。
失敗には3つの視点がある
この命題に答えを出すには、まず失敗を定義しておく必要がある。筆者は、プロジェクトの失敗には、ユーザー、ベンダー、エンジニア個人の3つの視点があると考えている。
- ユーザーの視点:計画どおりにシステムを構築できずビジネスの効果を発揮できていない
- ベンダーの視点:プロジェクトの納期が遅れたり収益が赤字になったりする
- エンジニア個人の視点:プロジェクトの仕事を通じて、自ら何も学んでいない
ある調査によれば、実に70%のプロジェクトが品質・費用・納期を計画どおりに達成できず、失敗に終わっている。その失敗原因は、ユーザー側体制の不備や、仕様変更の多発、未成熟な技術の適用、要員スキルの不足などさまざまである。
多人数の組織で開発をする以上、一人のエンジニアがいくら優れたパフォーマンスを上げたとしても、顧客と会社の視点では失敗を避けられないことも多いだろう。しかし、エンジニア個人の視点は心がけ次第でどうにでもなる。学んだことを自己成長の肥やしにできるかどうかで、今後のキャリア形成や次の仕事への取り組み方が大きく変わってくるのだ。
小さな失敗でも見逃さず学ぶこと
「失敗の最たるものは、失敗したことを自覚しないことである」と英国の評論家であるトーマス・カーライルは述べている。
実際、システム開発のプロジェクトでは、問題が起きているにもかかわらず、組織上の政治的・文化的な側面から、お咎めなしに体制強化やスケジュール見直しが”なんとなく”行われることが珍しくない。
その結果、何を目標として仕事を進めていたのかが分からなくなり、成功でも失敗でもなくなってしまう。つまり、責任の所在があいまいになるとともに失敗も闇に葬られてしまうという玉虫色の結果となる。ユーザーやベンダーの視点ではそれも結構だろう。しかし、エンジニア個人としては、これに安穏とすることなく失敗を認識し、教訓として自分の成長に生かすべきだ。
そのためには、何をもって成功とするのか、計画時点での前提や目標に対して結果との違いを評価する。たとえ周りの人が「失敗」と見なさなくとも、自分としては「失敗」を認識し、前提の変化や判断ミスなどを分析して学ぶことが重要である。
次回は、組織として失敗の教訓を共有化するための、「失敗の知識化」について紹介したい。
著者プロフィール:克元亮
All About『ITプロフェッショナルのスキル』ガイド。SEのキャリア形成やスキルアップをテーマに、書籍やウェブ記事を企画・執筆。近著に『SEの文章術』(技術評論社)、『ITアーキテクト×コンサルタント 未来を築くキャリアパスの歩き方』(ソフトバンククリエイティブ)がある。日々の執筆や読書を、ブログ『克元亮の執筆日記』でつづっている。
関連記事
- トラブルをチャンスに変えるリカバリー法【その1】
エンジニアならば、システムトラブルの1つや2つは経験したことがあるだろう。何度経験しても、トラブル対応は嫌なものだ。しかし考え方1つで、リカバリーへの取り組み方を変えられるのだ。 - トラブルをチャンスに変えるリカバリー法【その2】
「最悪の場合、胴体着陸します」――先月発生した全日空ボンバルディア機の胴体着陸事故において、機長のリカバリー能力が試された。機長の落ち着いた姿勢と上手なリカバリーが惨事を防ぎ、結果として全日空の評価を上げることになった。トラブルの初動はどうあるべきなのだろうか。 - トラブルをチャンスに変えるリカバリー法【その3】
起きたトラブルを千載一遇のチャンスにするためにはどうすべきだろうか。今回は、顧客とこじれたときの対応方法の変更、対応方法のアピールについて紹介する
Copyright © ITmedia, Inc. All Rights Reserved.