システム構築プロジェクトの成功率はわずか2～3割――。IT業界でこの「定説」が叫ばれ始めてから、もう何年も経つ。

その間、法人・個人を問わずさまざまな立場の人間が「失敗率7割」の要因や改善方法について議論や提言を行ってきたにもかかわらず、業界全体として大きく改善する見込みは立っていない。

「いろいろな調査結果（※）によると、ITプロジェクトの成否を図る指標となるQCD（クオリティー・コスト・デリバリー）それぞれの項目を調べても、等しく成功率は3割程度だそうです。このデータから考えると、特定の領域だけで改善策を打っても、プロジェクトを成功には導けないということです」

そう話すのは、ウルシステムズの植松隆氏。同社は「発注側」と「受注側≒開発会社」の間に立ってITプロジェクトの推進をサポートする独自のコンサルティング＆開発支援を展開しており、その経験則で築いた「ユーザー主導開発」の方法論で幾多の炎上プロジェクトを再生してきた。

直近でも、過去数年の間、数百人月も掛けながらうまく開発が進まず、難航していた某大手企業の大規模システム再構築プロジェクトにPMO（プロジェクトマネジメントオフィス）として参画。発注側である情報システム部門と、開発を担っていたSIerの両方に入り込むことで、数年越しのプロジェクトを完遂させるなどの実績を残している。

そこで今回、植松氏らウルシステムズの現役PM3人に、多くのITプロジェクトが失敗に終わる理由と、それらを未然に防ぎプロジェクトの成功率を高めるのに必要な手法を聞いた。

※出典は『日経コンピュータ』2008年12/1号「特集1-成功率は31.1% 第2回プロジェクト実態調査」や、米国スタンディッシュ・グループのリポート『CHAOS Summary 2009』など。いずれも30%程度の成功率しか報告されていない。

「プロジェクト炎上」にありがちな5つのステップ

まず聞いたのは、そもそもなぜ、ITプロジェクトの多くが失敗するのか？という理由だ。ウルシステムズのPM3人が挙げた、いわゆる大規模システム開発でありがちな「炎上メカニズム」は、以下のようになる。

この5つの流れを見ても分かるように、炎上の発端は【1】と【2】にある。発注側の意識・仕切りがつたなく、「どんな導入効果を狙うのかすらきちんと設定せずに開発を始めるから、間違いを間違いと気付かない」（植松氏）のが問題なのだ。

最近増えているユーザー企業の「開発内製化」も、「システム部門の考え方が変わらない限り、同じように失敗する」と横山芳成氏は明かす。

内製で作る分、コントロールが容易になりスピードアップにつながるというメリットはあるが、入り口を間違えたままでは品質は上がらず、内製化の効果もさほど見込めないからだ。

また、【3】の問題を解消する意味で注目されているアジャイル開発についても、3人は手法としての有効性を認めつつ、「ウォーターフォールでプロジェクトを回せないチームがアジャイルで開発しても成功率は上がらない」（植田氏）という。

「仕事柄、さまざまな種類のプロジェクトを見てきましたが、『開発側の技術力が足りない』という理由だけで失敗しているケースはほとんどありません。大規模なプロジェクトほど、最もクリティカルな失敗要因となっているのはコミュニケーションエラーなのです」（植田氏）

「『発注側は偉い』、『開発側は下請け』という主従関係でプロジェクトが進んでいるケースほど、失敗の確率が高いように感じます」（植松氏）

では、どうすれば従来のようなピラミッド構造ではなく「ユーザーと開発側が一つのチームとなった開発」（横山氏）を進めていけるのか。そのヒントを、発注側、受注側の2つの視点で解説してもらった。

多くの失敗の原因は「発注側の準備＆仕切り不足」にある

システム開発プロジェクトといっても規模や内容は千差万別なので、今回は「100人月以上の開発を協力会社に委託していて、すでに何かしらの問題が発生している」プロジェクトを前提に話してもらった。

この場合、まず手を打つのは発注側の動き方を変えるところから、と3人は異口同音に話す。うまくいっていない時ほど、当該プロジェクトを開始するに至った原点＝目的とゴールに立ち返って、「何をすべきで、何をすべきでないか」を洗い直すという。

「プロジェクトの期間が長くなればなるほど、そもそも何をどう実現したくてシステムを導入するのか？ なぜこのシステムが必要なのか？ という素朴な問題提起が意外に見過ごされがちです。これは本来、プロジェクト発足時に十分話し合っておくべき部分ですが、それが抜けているケースが非常に多い。だから改めて振り返るのです」（植松氏）

「定例で行われる進ちょく会議も、ただ『先週やったこと』を確認し合う場にしかなっていないケースが多い。進ちょく会議だけでなく、『目的共有会議』も定例で行うように仕切り直します」（横山氏）

次に行う具体的な一手として、植田氏は「発注側がやるべきことの見える化」を一緒に行うと話す。

開発会社に依頼する事項のスケジューリングから、社内レポーティングのタイミング、人員調達計画、プロジェクト中に機能追加の有無を検討するとしたらいつで、その決定フローはどうなるのかetc…をひたすら書き出すのだ。

想定できる事柄をすべて事前に洗い出しておくため、例えば「障害の重要度ランキング」なども作成し、どのレベルの障害までなら許容（＝まずは納期優先で開発して追って解決）し、どんな項目で不具合が起きたら開発リソースを再配分するかなども見当を付けておく。

「重要なのは、スケジュールを管理すること以上に、後で起こり得るシチュエーションにどう対応するかを明確にしておくことなのです。このプロセスを事前に踏んでおくことで、再び何か問題が生じた際や、変更要求があった場合にどう動くかをクリアにできます」（植田氏）

こうした取り組みによって、「テストフェーズで初めて品質の悪さが判明、品質問題に対応するための人員が不足し、プロジェクトの進ちょくが一気に悪化した」といったような事象の発生を防ぎ、かつ長期プロジェクトでありがちな「突然の機能追加」などにもどう対処するか（対処できるリソースがあるか）などもはっきりする。

未来とヒトは先読みできないからプロジェクトが失敗するわけだが、「何かが起きた時にどう動くか？」のプロセスを決め直すことで、少なくとも変化に対処する柔軟性は高まる。その際に大事なのは、発注側の事前準備と動き方なのだ。

開発側にとって最大の課題は「無理だ」と声を挙げないこと

次に開発会社側で必要な動きは何かを尋ねたところ、「そもそも開発側が頑張り過ぎというシチュエーションが多い。無理なら無理と早く手を挙げるべき」（横山氏）という答えが返ってきた。

前述した「炎上メカニズム」の【4】でも取り上げたように、往々にしてSIerの「遅延報告」はギリギリにならないと出てこない。

「わたし自身がエンジニア出身なので気持ちは分かるのですが、お客さまを不安にさせないための美学としてリスクを開示しなかったり、開発側のPMが優れた人で『自分だったらできる』と思い込んでいるケースが多いように思います。でも、大きなプロジェクトになればなるほど、チームメンバーができなければ開発は進まないのです」（横山氏）

こういった失敗を立て直すためには、ヒト・モノ・カネといったプロジェクトリソースを冷静に分解した上で解決策を考えるのが大切になるという。

「開発現場に行ってみて、直面する問題を解決できる人が何人いて、逆にできない人はどのくらいいるのかを徹底的にヒアリングします。そうして“戦力分析”をしてみないと、次の打ち手を的確に提案することができないからです」（植松氏）

よくあるのが、発注側にスケジュール再調整の依頼をした上でより多くの人月を割く手はずを付け、合わせて増員分の予算も工面してもらうという手順だが、「問題を解決できる人員がいなければ人を増やしてもムダ」（植松氏）というのが開発の真理である。

ウルシステムズのコンサルタントは、第三者としての客観性で冷静にリソースを洗い出し、場合によってはプロジェクトの中止を提案することもあると話す。

「例えばコスト削減や売上・利益向上で10億円の定量効果を狙いとした、予算5億円のシステム開発がスケジュールの延伸を繰り返していて、いまだトンネルの出口が見えない混乱状況だったとします。この場合、さらなる費用追加やスケジュール延伸をしても当初想定していた効果が望めない、あるいは投資と効果のバランスが明らかに崩れてしまうといった状況に陥ることがあります。そういう際は思い切って中止を提案することもあります」（植松氏）

逆に言えば、プロジェクトマネジメントの徹底によって、ほとんどの炎上プロジェクトは再生できるというわけだ。

開発側を悩ませる「突然の機能追加や仕様変更依頼」についても、客観的な立場と目線とで本当に必要なのかどうかを見極める。

「判断基準にしているのはQCDのバランスですね。その機能を追加することで品質アップになるのか？ 価格に見合った効果があるか？納期を延ばしてもやる価値があるか？」（横山氏）

「先に述べた『発注側が設定するゴールと目的がプロジェクトの成否を左右する』という観点で言えば、“あったら便利”、“使うかもしれない”といった機能は徹底的に排除すべきですね。『その機能がプロジェクトの目的とゴール、あるいは効果にどれだけ貢献できるのか』、『その機能を採用する際のトレードオフとして、どの機能をあきらめるのか』を発注側に徹底的に問いかけます」（植松氏）

大切なのは、「今自分がいる立場とは異なるモノの見方を磨くこと」

数々のITプロジェクト支援に携わってきた3人に言わせれば、こうした点を押さえて動けば「プロジェクト成功率は少なくとも70～80％まで高められる」と強調する。残り2割は戦略では解消できない部分（例えば人間関係や相性といったもの）だ。

「われわれは発注側の味方でも受注側の味方でもなく、プロジェクトの味方」と横山氏が語るとおり、ウルシステムズはプロジェクトを成功に導くことを最優先に日々ミッションをこなし、採用でもそこに共鳴する人たちが集まってきた。

では、若いSEやプロジェクトリーダーは、どうすれば彼らのような再生術を身に付けることができるのか。

植松氏は「PMBOKのようなプロジェクトマネジメントの定石はひとまず全部やってみること」と話し、横山氏は「まずは一エンジニアとして上司やお客さまに提案してみる経験を積んでみては？」と話す。

いずれの場合も、重要なレッスンは「一歩下がってプロジェクト全体を見てみる、一歩前に出てプロジェクトをミクロに見てみるなど、これまでのプロジェクトやシステム開発に対する視座を転換してみる」（植松氏）ことだ。

さらに植田氏は、自身がウルシステムズに入社する前、勤め先のSIerで体験した出来事を引き合いにこう話す。

「あるシステムの夜間自動バッチ処理ソフトを作っていた時、後輩に『何で僕がこれを作らなければならないのか？』と聞かれたことがあったんですね。彼からすると、誰が使うのかも分からないモノを、忙しいさなかで作る必要があるのかと。この時、わたしがとっさに返した答えは、『このバッチを作ったら誰が喜ぶか考えてみれば？』というものでした」（植田氏）

いわゆる「ユーザー体験」をしたことがないSIerのエンジニアほど、開発を“作業”としてこなしがちだ。だが植田氏は、忙殺されると忘れてしまう「使う人の立場」を今一度理解させることで、その後輩のモチベーションとモノの見方を改善した。

発注側、開発側、ユーザーなど、プロジェクトに関与するメンバーが分け隔てなく「For the Project」の御旗の下で愚直に必要な手を打っていく。ありていだが、それこそがプロジェクト再生の肝なのかもしれない。

取材・文／浦野孝嗣　撮影／小林 正

>> セミナー聴講の事前登録はコチラから