失敗する仕事を、人は「プロジェクト」と呼ぶ

プロジェクトは、定義からして失敗する

ＩＴを会社の武器に変える方法について講演することも多いのですが、
「ＩＴプロジェクトはなぜ、あんなにうまくいかないのか？」
「ケンブリッジは、どうやって成功させているのか？」
という質問をほぼ必ず受けます。

それに対して、わたしは身も蓋もない回答をします。
「そもそも、失敗する仕事を人はプロジェクトと呼ぶのです」と。

通常、プロジェクトと呼ばれる仕事は、
・初めての試みである。
・期限、予算、ゴールが決まっている。
・混成チームで取り組む
などの条件を満たしています。
要は、ルーティーンワークではない仕事のことです。

この定義を裏返しにすると、
・初めての試みだから、先が読めず、リスク満載
・期限や予算が決まっているから、いつもそれに追われる
・混成チームだから、コミュニケーションが難しい
となります。
そもそも、ルーティーンワークに比べて、はるかに難しいのです。

でも、ＩＴを作らなければ競争には勝てません。
プロジェクトを成功させなければ、会社を変革できません。

とても難しい。でもチャレンジしなければいけない仕事、それをプロジェクトと呼ぶのです。

このことを、ＩＴプロジェクトに関わるすべての人がまず、知っておく必要があるでしょう。

同じ会社なのに、協力できない悲劇

ＩＴプロジェクトへの期待値のズレは、さまざまな局面で軋轢を生んでいます。
いちばんやっかいなのは、エンジニアとそれ以外の人が、お互いを尊敬できないこと。
経営幹部や業務担当者はエンジニアのことを「グズで、仕事のできない奴ら」と思っています。一方のエンジニアは「プロジェクトの難しさを理解してくれずに、無理難題ばかりふっかけてくる人たち」と思っているのです。

これは悲劇です。
本来、ＩＴは業務をよくするために使うもの。経営に利益をもたらすもの。
なのに、業務担当者と経営幹部とＩＴ部門が一丸となってＩＴを育てられない。こういう状態で、競争に打ち勝つのはなかなか難しくなっています。

歩み寄るために、今日からできること

これまでこの連載で取り上げてきたように、ＩＴをうまく構築し、競争の武器にしている会社は多くはありません。
できている会社も、決して100点満点ではありません。

ですが、「ＩＴを武器にできないのは、エンジニアが悪い！」「ＩＴ部門が悪い！」「システムインテグレーターが悪い！」「経営者が悪い！」と、新橋の焼き鳥屋で愚痴を言っていても、何も変わりません。

一方で、特効薬がないことも、わかっています。
うまくやれている会社を参考に、少しずつＩＴに対する議論を積み上げ、実際の行動を変えていくしかありません。

そのためには、よい事例を知ることが有効です。

わたしの著書『会社のＩＴはエンジニアに任せるな！』では、多くの会社の
・プロジェクトを成功させている事例
・経営、業務、エンジニアがうまくコミュニケーションしている事例
・プロジェクトリーダーを育成する取り組み事例
・対話の中から、長期ビジョンを見出した事例
・ＩＴに経営者が主体的に関わっている事例
などを紹介しています。

少しでも、ＩＴを会社の武器にする手助けになればと心より願っています。