【IT分野での2025年問題の本質:おわりに】基幹システム再構築プロジェクト成功への実践KSF

システム

2020年04月13日(月)掲載

(1)最後に、一番重要なことは?

これまで一連のコラムで解説してきました「事前準備の各ステップ」を着実にこなすだけでも非常に大変です。しかし、「準備フェーズ」を着実に実施することにより、いきなり基幹システムの再構築プロジェクトを実施するよりも、プロジェクトとの成功率が非常に高まります。
その理由は、プロジェクト開始後の重要なことの一つに「リスクの事前認識、排除」というものがあり、「準備フェーズ」を実施することにより、この「プロジェクトリスク」の低減がはかれるためです。
そして、この「準備フェーズ」をPM(もしくはPMを担う予定のメンバー)が自ら率先して実施することにより、プロジェクト開始後のリスクもかなり排除できるようになります。それは、PMがこれから任されるプロジェクト全体の「リスクマネージメント」の一部を、既にこれら一連の「準備フェーズ」から、事前に実施できるようになるからです。

しかし、プロジェクト開始後は、この「準備フェーズ」とはまた違った「基幹システム再構築プロジェクト」固有の難しさもあります。そして更に、PMとしての「プロジェクトマネージメント」のスキルも様々に問われる局面が多々出てきます。そこで、一連の「基幹システム再構築成功への重要な準備ステップ」コラムの締めくくりとして、今回のコラムのタイトルにも記載しました、「基幹システム再構築プロジェクトの成功への実践KSF」について簡単に触れておくこととしましょう。因みに、ここでKSFとは、Key Success Factorsの略であり、日本語ではIT以外の分野でも「重要成功要因」とも呼ばれて使用される用語の略称を意味します。

「準備フェーズ」のプロジェクトキックオフも無事終わり、さあこれからプロジェクトが開始するという段階において、PMとしての重責を担うことになる方もそうでない方も、下記を頭の片隅において、「基幹システム再構築プロジェクト」にあたってください。それでは、始めましょう。

(2)ITプロジェクト成功への実践KSFとは? 

貴社の肝いりで推進するITプロジェクトが成功するか失敗するかどうかは、貴社のプロジェクトマネージャー(PM)が、考えられる限りのリスクマネージメントを細分まで徹底分析し、かつITプロジェクトを成功させるための重要ポイント、つまりKSF(Key Success Factors)を押さえているかどうかにかかっています。
これは「基幹システムの再構築」のように、複雑で規模も大きくなるプロジェクトほど重要なポイントなります。

以下、私がこれまで経験しましたITプロジェクトを振り返り、プロジェクトが失敗する代表的な要因を次の(3)に思いつくまま列挙し、次にこれらを踏まえてのプロジェクトを失敗させないためのポイントを、その反面教師として(4)にKSFとして列挙します。

(3)ITプロジェクトが失敗する要因

①  自社作成のプロジェクトマネージメント計画書(PMP)が無い
自社作成のプロジェクトマネージメント計画書(PMP)が無いか、仮にあったとしてもベンダーに頼って作成したPMPであり、PMやプロジェクトメンバーがその内容を良く理解していないことが多々あります。

②  関連部署同士の関係や、コミュニケーションが良くない
プロジェクトで抱えている課題を解決するためではなく、自分の部門が有利な状況に立つために、業務部門などが関連部署と無意味な議論を繰り返しているケースも少なくありません。そして、このコミュニケーションの悪さが更に部署間での対立関係も産み、結果的にプロジェクトの遅延に至ります。

③  要件も定まっていないのにもかかわらず、納期のみが決まっている
プロジェクト全体としての要件が未だ明確に決まっていないにも拘わらず、納期だけが既に決まってしまっているケースがあります。要件が一向に定まっていない状態はプロジェクトとしては危険信号です。もし要件定義が大変で遅延が発生しても、これをないがしろにして納期の変更が認められないようなプロジェクトであれば、最後には失敗に至ります。

④  上流工程の遅延を、下流工程で取り戻そうとする
要件定義の遅延を含め、上流工程で発生した遅延を下流工程で取り戻そうとしても、余計に大変です。上流工程で遅れた工程を下流工程で取り戻すには、上流工程以上の負荷がかかります。それ故に、システムテストなどが疎かになって品質の悪い(脆弱性のある)システムが出来上がってしまうことになるのです。上流工程で発生した遅延は、下流工程で取り戻せないと思った方が良いでしょう。

⑤  メンバーの技術力が不足している
そもそも社内プロジェクトメンバーやサポートベンダーの技術力が不足していることで失敗するケースが多々あります。サポートベンダーからの要員の派遣契約では、能力のある技術者と一緒に経験不足のエンジニアが派遣されるケースもあるので参画メンバーの技術力の評価には注意が必要です。また、最近良くあるベンダーとの業務委託準委任契約では、ベンダーは成果物責任をもたないので、より注意が必要な場合もあります。プロジェクトの最初のフェーズのまだ要件がしっかり固まっていないフェーズであればやむを得ないですが、それ以降の開発フェーズでの導入サポートベンダーとの業務委託準委任契約は、発注会社側(顧客側)に余り経験やノウハウが無い場合には、特に注意が必要です。


⑥  進捗情報を報告しない
これはITプロジェクトに限った話ではありませんが、進捗の遅れを故意に隠す、あるいは実際とは異なる進捗の報告をする人は少なからず存在します。
それ故に、プロジェクトオーナーとしては、順調な進捗報告を受けていた筈が、ある日突然進捗がまったく進んでおらず、問題の多いプロジェクトであることが判明するという状況になってしまうのです。

⑦  問題を隠蔽してしまう
得てして、ITプロジェクトに問題や課題はつきものです。しかし、一番行ってはいけないことは、事実とは異なる報告をすることです。ITプロジェクトで発生した問題はすぐにPMやプロジェクト関係者に報告し、迅速に適切な対処を取る必要があります。

⑧  メンバーが頻繁に入れ替わる
大きなITプロジェクトでは、メンバーが頻繁に入れ替わるケースが多々あります。メンバーが変更となるたびにコミュニケーションロス(オーバーヘッド)が発生するのが常ですので、それ故にプロジェクトが思うように進まないということも発生します。

⑨  業務部門からの無理難題を引き受けてしまう
ITプロジェクトの納期やコスト面を鑑みて、現場業務部門からの無理な要望は当然断らなければなりません。しかしながら、どうしてもこのような無理難題を断りきれずにやむを得ず承諾してしまうプロジェクトメンバーがいると、当然プロジェクト進捗に影響がでます。

⑩  見積り範疇ではない作業を受けてしまう
ITプロジェクトを見積る際には、常に全体の費用(コスト)とスケジュールによって行なう必要があります。よって、当初の見積範疇ではない作業を受けてしまうと、当然失敗する可能性が高くなり、メンバーにもそのしわ寄せがきます。

⑪  スケジュールバッファが無い
ITプロジェクトにおいて、スケジュールの遅れは日常茶飯事です。これまで述べました課題によりスケジュールが遅延することも多々発生します。しかし、ここでスケジュールに一切の余裕が無いと、些細な課題やトラブルが発生しただけで、本番稼働納期が変更になってしまいかねません。

⑫  納期に無理がある
プロジェクトによっては、無理な要望によって本来適切ではない納期が決められてしまうケースもあります。その場合、PMが無理をして納期に間に合わせようすると、プロジェクトメンバーの残業が多くなり、長期の長時間労働でメンバーが疲労しきってしまい、かえって逆効果となる可能性もあります。

⑬  メンバーに情報が共有されていない
各種打ち合わせの中で決定した内容がメンバーに共有されていなければ、ITプロジェクトはうまく進行しません。特にシステム仕様に関する情報は、決定した段階や変更が生じたタイミングでその都度共有しなければ、プロジェクトに手戻りが発生し、のちにトラブルが発生した場合の原因ともなりえます。

⑭  スケジュール遅延を残業でカバーしている
スケジュールが遅延した際のリカバリー方法として、残業を強いるケースが良くあります。しかし、既に述べましたように、残業は開発プロジェクトにかかるコストを上げるばかりか、メンバーの疲労蓄積やフラストレーションの増加にもなり、プロジェクトが失敗に陥りやすくなるでしょう。

⑮  初期段階でのテスト工程を短縮・簡略化する
スケジュールが遅延したことにより、一部のテストフェーズ期間を短縮する、或いは簡略化すると、後のテスト工程で大きな問題が発生する可能性があります。そのような場合、再度テストを実施する必要が生じ、余計に膨大な手間と時間がかかってしまうため、結果としてプロジェクトの失敗につながりかねません。

⑯  PMがメンバーの課題や進捗を把握していない
PMがメンバーの課題や進捗を把握できていないと、適切なタスク振り分けができません。その結果、特定のメンバーに負担が集中し、プロジェクト遅延の原因となります。

⑰  過剰なドキュメントが要求される
プロジェクトの課題や進捗状況の説明資料として、必要以上に過剰なドキュメントが要求される場合があります。PMはPMOの支援も得てこれらを適切に管理しないと、これらのドキュメント作成や管理だけで多くのリソースが割かれてしまいます。

⑱  必要なシステム要件、仕様が明確になっていない
ITプロジェクトをスタートする際に、対象システムの要件や仕様が明確になっていないままでプロジェクトを進めると、下流工程にそのしわ寄せが行ってプロジェクトに手戻りが発生し、結果的に遅延やコストの増加につながる可能性があります。

⑲  仕様が頻繁に変わる
プロジェクト途中で仕様が何度も変更になると、プロジェクトに過剰な負担がかかり、プロジェクト工程の大幅遅延や、失敗に至る原因となります。

以上の原因以外にも、ITプロジェクトが失敗する原因は無数にあります。では、これらの問題を起こさずにITプロジェクトを失敗させないためには、何に注意してプロジェクトを推進すれば良いのでしょうか。
当然、上記に述べたことの逆を行えば良いのですが、これが「言うは易く行うは難し 」の最たるものです。以下に、ITプロジェクトを失敗させないKSFの主なものを列挙しましょう。

(4)失敗しないためのポイント、KSF

以下は、(3)でのいくつかの原因を分析した上で、私が考えるKSFです。

①  プロジェクトマネマネージメント計画書(PMP)をしっかり作成する
プロジェクト開始前に、PMはPMOの支援も得て、しっかりしたプロジェクトマネージメント計画書を作成する必要があります。そして、その中には自社の体制だけで無く、ベンダーの体制も含めての推進体制を明確にすると共に、プロジェクトオーナーも含めての会議体(どのレベルの会議をどのメンバーでいつ開催するか)等も明確に決めておく必要があります。得てして、このPMPは形だけのものになりがちですので、PMPは事前に関係者含めてしっかりレビューした上で、プロジェクトを開始する必要があります。

②  プロジェクトメンバーのみでなく、関連部門とも情報共有を徹底する
プロジェクトメンバーや関連部門のメンバーともしっかりとコミュニケーションを取ることは、ITプロジェクトが成功するための絶対条件です。もし、そのためのコミュニケーション基盤がまだ整っていない場合は、すぐに整える必要があります。そして、PMPのプロジェクト推進体制や会議体にもこれらを意識して織り込むのが良いでしょう。

③  メンバーの技術力を把握して、適材適所を行う
ITプロジェクトを成功させるために各プロジェクトメンバーの技術力は欠かせません。仮にもし、技術力不足のメンバーがいたとしても、そのリソースをITプロジェクトから切り離すことができない場合、PMはこれらメンバーも含めた上での技術力を把握して、適材適所を実現することが大切です。

④  KPIを設定してリアルタイムに進捗を追う
ITプロジェクトを成功させたいのであれば、そのためのプロジェクトとしてのKPI設定することが必要です。通常、KPI(Key Performance Indicator)は、経営戦略用語で「重要業績評価指標」として用いられますが、他にも色々な局面での「評価指標」としての意味でも用いられます。例えば、ITプロジェクトにおいても、KPIとして課題発生件数やテスト項目件数、不良発生件数等々を事前に設定して、それらの定量的な指標管理も含めて、プロジェクトの進捗を管理することが大切です。

⑤  プロジェクト管理ツールを導入する
ITプロジェクトの成功に向けて大切なことは、いわゆる「プロジェクト管理ツール」の導入です。昨今、様々なプロジェクト管理ツールがありますが、貴社のプロジェクト管理に合った機能を有するプロジェクト管理ツールを導入することが必須です。もちろんそのための投資も必要ですが、その投資に見合った開発プロジェクト成功効果は十分でてくるでしょう。昨今ではインターネットで「プロジェクト管理ツール」と検索すると、無料で利用できるプロジェクト管理ツールも多々出てきますので、先ずはこれらを活用してプロジェクトの管理を実施してみることも可能です。更に、PMPの中でもプロジェクトの進捗管理や課題管理で使うツール等は、明確に記述しておく必要があります。 

最後に、ITプロジェクトを失敗させないために、列挙しましたITプロジェクトの失敗要因や失敗させないためのKSFを意識すると、何も行わないよりは貴社のプロジェクトの品質、納期、コスト面での成功率は、確実に高まります。

しかし、ITプロジェクトの成功に向けて重要なのは、オーケストラに例えればコンダクターとも言える、ITプロジェクトをコントロールするPMの素質、役割なのです。そして、その重要なPMとなるべき人にとって一番大切なのは、例えプロジェクトマネージメントが上手く行かなくても、その都度反省し、その失敗経験を次のプロジェクトに活かして数多くの経験を積むことなのです。そのような意味で、昨今はPMを補佐する(育てる)立場にもある、プロジェクト経験豊富なPMOの活用が重要視されてきているという背景もあります。

今後、貴社の「基幹システム再構築プロジェクト」のPMにあたる方は、「準備フェーズ」の重要性及びこのコラムに記載しましたようなKSFを念頭に置いて、貴社のプロジェクト成功に向けて是非、切磋琢磨してください。

そうすることにより、20年以上も前から、プロジェクトの成功率が3割程度(プロジェクトの管理不良、ひいてはPMのプロマネスキル不足)と言われて続けている「ITプロジェクト」の成功率も、恐らく高くなることでしょう。

ライターH.K氏

大阪大学工学部卒業後、電機業界の大手企業に入社し、情報システム事業部門勤務。米国への社費留学にて、コンピュータサイエンス修士号取得後、米国・東南アジア・欧州の関連会社に出向駐在を経験。日系企業の基幹システム導入支援等を多数実施。定年後はIT顧問として活動中。英語・海外関連著書30冊以上あり

関連コラム

ページTOPへ戻る