システム開発プロジェクトの炎上原因をMECEに分析してみる【SIerとクライアント】

      2018/08/31


「システム導入のプロジェクトがまた炎上した、えらいこっちゃ!」
「なぜシステム導入の仕事はいつもデスマーチになってしまうんだろう?」

この記事は、そんな方へ向けて書いています。

こんにちは、TEN(@02smwhere)です。

僕はコンサルタントとしてIT系のプロジェクトマネジメントの経験があるので、度々SIのプロジェクトが炎上するのを目の当たりにしてきました。

そこで本記事では、システム開発のプロジェクトがデスマーチと化してしまう原因を、コンサルタントらしくMECE(漏れなくダブりなく)に考えてみようと思います。

システム導入における炎上の原因は、大きく以下の3つに分けられます。

システム開発の炎上要因3点
  • ①システム開発の受託側の要因
  • ②プロジェクトメンバーの人的要因
  • ③依頼するクライアント側の要因

以下では、順番に原因をより掘り下げていくことにいたしましょう。

スポンサーリンク

プロジェクトを受託するSIer側の会社に要因がある場合

remi-walle-86579"

要件定義の段階からプロジェクトスケジュールが怪しい

システム導入は主に、初めは要件定義といって「何を仕事にするのか?」をクライアントとすり合わせることから始まります。

ウォーターフォール型の開発といい、詳しくは別記事をご参照ください。

要件定義ではクライアントのさまざまな部署の人たちと話をすることもあるので、結果としてスケジュールから遅延してしまうことも起こり得るでしょう。

しかしながら、プロジェクトの指針として何を行い、どれだけのフィーをいただいて、いつまでに納品するかを決定するのは、非常に大切なことです。

 
さて、このように仕事の全体像が決まる要件定義なのですが、まれにこういった要件定義が終わっていないのにも関わらず、設計から開発、テスト・リリースまでも合わせた最終デッドラインを決めてしまっていることがあります。

経験上、最終デッドラインを死守するためには、後述するように下流工程の時間を削らざるを得ません。

そもそも、初めから作業の遅延を考慮していないスケジュールを組んでいる時点で、プロジェクトに危険フラグが立っているに等しいです。

したがって、要件定義時点でのスケジュールを把握すれば、炎上するかどうかの判断材料とすることができます。

合わせて読みたい>>>> アジャイル型とウォーターフォール型の開発手法の違い
 

プロジェクト上流で発生した遅れを下流で巻き返そうとする

これまでで述べたように、スケジュールの遅延はどんなプロジェクトでも起こり得ることです。

しかし一方で、すでに要件定義などの上流工程が遅延しているにも関わらず、プロジェクト全体における最終デッドラインは死守しようとする場合。

この場合には、開発やテストなどの下流工程の期間を短縮することで、なんとか帳尻合わせをしようとするマネジメントが存在します。

 
いわずもがな、これは愚かなリカバリ方法でしかありません。

ただでさえ遅延しているので、現場の雰囲気も悪く、コミュニケーションも取れないので、手戻りも多く発生。

品質も悪いので結局やり直しをするはめになり、さらにスケジュールが遅延していって、デスマーチが繰り返される悲劇となります。

 

案件獲得のために最初から予算が削られている

現在は多くのSIerがシステム導入のプロジェクトを受注するために、しのぎを削ってる状態です。

したがって、何が何でも仕事を貰うために、初めから無茶なスケジュールを組んでいたり、さらには低予算で仕事を受けてしまったりします。

低予算で仕事を受けるということは、メンバーに残業代を払わなかったり、質の低い人材を使わざるを得ない状態を招いていまいます。

 

スケジュールや予算以外の揉め事を仕事に持ち込んでいる

システム導入のプロジェクトでは、SIerもクライアントもどちら側においても、いくつかの企業が共同で仕事をすることもあります。

SIのベンダーであっても、業務ごとに違う会社を使っていたり、さらにそれらをまとめるプロジェクトマネジメントは別のコンサルがいたり…

といったように、いわばキメラ状態のまま、プロジェクトが進んでいくことが多々あります。

 
こういった場合、他のベンダーから仕事を奪うために、あえて情報提供をしなかったり、進行を邪魔するような政治闘争がなされることもあります。

クライアント側についても、様々な部署の思惑が交差するプロジェクトである場合、あっちではこう言ってるけど、こっちでは別なことを…

みたいな、板挟みの状態になりかねません。

 

プロジェクトに関わる人たちに要因がある場合

pexels-photo-70292-1"

プロジェクトメンバーの問題

ほとんどの炎上プロジェクトの場合、マネジメントの力不足が原因となることが多いので、メンバーが直接因子となることは少ない場合が多いです。

しかし、実際に作業を行ない、かつプロジェクト人数の大部分を占めるメンバー層ですから、炎上に加担してしまう場合も見受けられます。

 
例えば、単刀直入にメンバーの能力が不足している場合です。

経歴を詐称してプロジェクトに入ってきたり、社会常識がなっていなかったり、外注先のメンバーの入れ替えが多い場合など…

さらにコミュニケーション不足のため、進捗状況や発生した問題を報告しないなど、色々な人がいます。

こういった行動指針が原因となってしまい、結果としてプロジェクトそのものが遅延してしまうことも見受けられます。

 

プロジェクトマネージャーの問題

メンバー以上に炎上に深く関係してしまうのが、やはりマネジメント層の問題です。

ほとんどの炎上プロジェクトの場合、メンバーに問題があったとしても、リーダーがきちんと対応できていれば、失敗を避けることができます。

しかし、時には明らかに失敗を招いていると思えるようなマネージャーに出くわすことがあります。

例えば、クライアントの言いなりになってしまって、無茶な要求を引き受けてしまったり、予算や工数がない状態でスコープ外の作業をメンバーに振るなど…

メンバーからしてみると、クライアントの無茶な要求から守ってくれるのが、マネージャーの仕事であるはずです。

 
さらに、直接クライアントとミーティングした内容などについても、きちんとメンバーに報告することで、具体的なタスクに落とし込んでいくことが要求されます。

各メンバーのタスクの状況についても、きちんと把握してフォローしていくことで、うまくマネジメントしていくことが不可欠です。

これができないマネージャーは結果として、プロジェクトそのものを炎上させる原因となってしまいます。

結果として、遅れたスケジュールを取り戻すためにメンバーに残業させ、残業代によって会社の利益は悪くなる…

という、皮肉な結果を招いてしまいます。

合わせて読みたい>>>> 外資系コンサル経験者が「成長が早い」「優秀」と評価される理由とは
 

スポンサーリンク

システム導入をするクライアントそのものに要因がある場合

amritanshu-sikdar-253730"

パッケージ導入なのにシステムに合わせず、独自仕様にこだわる

システム開発のプロジェクトが炎上する理由は、SIerの問題ばかりではありません。

クライアント側に問題があるがために、結果としてプロジェクトが炎上してしまうこともあり得ます。

 
例えば、せっかく新たなシステムを導入するにも関わらず、クライアントがやたらと現行踏襲にこだわるパターンなどです。

クライアントの現行業務をヒアリングした上で、それらを整理して新しいシステムに落とし込んでいくのが、要件定義を行うコンサルタントの役割なのですが…

それでも、クライアントが首を縦に振らない限りは、その方針に従わざるを得ません。

 
欧州の企業が業務改善を行う場合、SAPなどのパッケージに従ってシステムありきの上、業務自身をトップダウンで再構築していく場合が多いです。

しかし、日本のシステム開発でありがちなのが、上層部がいくらパッケージを入れたがっていても、現場がそれを嫌がったり、現行業務の把握自体を疎かにする場合です。

結局パッケージの良さを活かすことができず、独自仕様のカスタム開発などで追加工数が発生してしまい、スケジュール遅延につながります。

 

要件や仕様を頻繁に変えるなど、システム開発プロジェクトへの理解に乏しい

これは仕方がない問題でもあるのですが、クライアント側がシステム開発がどのように進んでいくのか、理解をしていない場合です。

例えば、ウォーターフォール型の開発にも関わらず、下流工程に入っているのに当初の仕様を変更したがるなど…

 
どんなシステムにするか、何が標準で、何を追加開発するかなど、要件定義や基本設計の段階で確定したにも関わらず、後から出てきたえらい人がそれを拒むことすらあります。

これはまさに、自分で自分の首を締めているに等しい行為です。

さらに納期変更や追加予算も認めないとくれば、クライアントは明らかにシステム開発プロジェクトへの理解が足りないと考えていいでしょう。

合わせて読みたい>>>> Vモデルによるシステム開発のフェーズを自動車に例えて説明する
 

MECEに要因を把握してシステム開発のプロジェクト炎上を防止する

pexels-photo-541525"

本記事では、システム開発プロジェクトの炎上原因についてご紹介しました。

クライアントとして開発を外注する側の場合は、多少の予算がかかったとしても、信頼の置けるプロジェクトマネージャーやコンサルタントに頼むと良いでしょう。

値段を下げて受託しようとするSIerがいたとしても、本記事の内容から炎上プロジェクトとなり、結果納期も予算も想定外になりかねません。

また、炎上プロジェクトから抜け出したいSIerのエンジニアの方は、より上流工程から参画することを考えてみてください。

現在は売り手市場なので、経験があればきっとITのコンサルタントとしてのキャリアも歩むことができるでしょう。

合わせて読みたい>>>> コンサル志望者がSIerの仕事との違いを知るべき意味とは
 

 - データ分析