プロジェクト管理手法について | システム導入のエッセンス（２）

イントロダクション

システム導入にあたってプロジェクト計画書をベースにシステム導入の勘所とRFPに記載すべき要件をお話ししていく「システム導入のエッセンス」、今回が２回目です。

前回は中長期的なシステム導入計画のお話しをしましたが、今回はそもそもシステム導入プロジェクトとはどのような要素で成り立っているのかを、プロジェクト管理手法を紹介しながらお話ししていきたいと思います。

ベンダー側から見たプロジェクト管理手法がメインの話になりますが、体系化された手法があるのでまずはそれに沿ってお話していきたいと思います。

ベンダー側のプロジェクト管理手法について

確立されたプロジェクト管理手法がある

ベンダー側のプロジェクト管理には既に確立された手法が存在します。
恐らく最も有名なのはPMBOKでしょう。日本語訳は「プロジェクトマネジメント知識体系ガイド」です。
ITだけではなく、製造、建築も含めたプロジェクト単位で行われる様々な業務に適用できるプロジェクト管理のノウハウが体系化されています。

PMBOKをベースにした国際的なマネジメント資格がPMP（Project Management Professional）です。SIerではマネージャー昇格要件にPMP取得を求められる場合がありますが、色んな意味で難易度の高い資格です。
単純に試験勉強をすればいいだけではなく、実務経験、マネジメント経験の年数、35時間以上のPMI認定の研修受講、全て英文で行われる受験申請、高い受験料、4時間の試験時間、合格後の3年毎の更新と継続的な研修受講など、様々なハードルがあります。

ちなみに日本の国家資格にも「プロジェクトマネージャー試験」がありますが、こちらはIT関連のみの資格です。

PMBOKの構成

PMBOKはプロジェクトのフェーズによる5個のプロセス群と、管理すべき要素である10個の知識エリアで構成されています。
本気で勉強される予定ではない方でも、知識エリアの要素はプロジェクトが何を持って構成されているかを確認し、管理基準に抜け漏れが無いかのチェックリストとしてだけでも十分活用できます。

【5個のプロセス群】
１．立上げプロセス群
２．計画プロセス群
３．実行プロセス群
４．監視・コントロールプロセス群
５．終結プロセス群

【10個の知識エリア】
１．統合マネジメント
２．スコープ・マネジメント
３．スケジュール・マネジメント
４．コスト・マネジメント
５．品質マネジメント
６．人的資源マネジメント
７．コミュニケーション・マネジメント
８．リスク・マネジメント
９．調達マネジメント
10．ステークホルダー・マネジメント

IBMの「PM 7Keys」

PMBOKはやや敷居が高い、という方にお勧めなのがIBMがプロジェクトのリスク管理に用いていた「PM 7kes」というプロジェクト管理の７つの観点です。
これもベンダー側の観点で作成されたものですが、うまく纏まっているので１つずつ説明していこうと思います。

１．ステークホルダー

ステークホルダーとは「利害関係者」と訳されることもあります。要はプロジェクトに係わる関係者を指します。
PMBOKでいうコミュニケーション・マネージメントとステークホルダー・マネージメントを一緒にした観点と考えてよいと思います。実際PMBOKでも第5版で分離するまでは１つの知識エリアでした。

システム導入プロジェクトにおけるステークホルダーは、大きく分けるとベンダー側とユーザー側に分かれます。
ユーザー側のステークホルダーは、システムを実際に業務で利用する現場担当者、導入検討における決定権のある責任者、運用を担う情報システム部門、費用面でのスポンサーとなる経営層、のような分かれ方をしており、それぞれに対して必要なマネジメントを行うことがステークホルダーマネジメントです。

現場担当者と経営層に同じ頻度で同じ話をしても意味がありません。誰に対して、どれくらいの頻度で、どういう観点の報告を行うか、それを経験知としてだけではなく形式知として文書化されているかが問わるのがこの分野です。

２．ビジネスベネフィット

「ビジネス利益」と訳される場合もあります。ユーザーがプロジェクトの成果としてどのようなビジネス上の利益を得ることができるのか明確になっていることが問われます。

システム導入に係る費用に対して価値が十分に得られるのかはユーザーの重大な関心事の一つです。「なんとなく便利になったね」くらいの感想で終わらせるのか、明確な指標を達成し、ビジネスに対する貢献度を定量化できるのかで、システム導入に対する顧客満足度は大きく変わります。

もちろん定性的な「便利になったね」も軽視はできません。顧客のニーズを正しく汲み取り、的確なソリューションを提案できることも重要な要素になります。
「パッケージなんで」「仕様ですから」と杓子定規で後ろ向きな言い方を望んでいるユーザーはどこにもいません。「そういう用途であれば、こういう使い方の事例がある」「この機能で実現しなかったとしても、別の運用方法が紹介できる」というように、事例や代替案の提示があってようやく「それならいいかな」となってもらえます。
提案されたやり方が現状よりも利便性の高いものであれば、そこでようやく「さすが！」となるのです。

私もパッケージシステムの適用SIを10年以上やっていましたが、ユーザーから「さすが！」なんて言われたことは片手で数える程しかありません。
そして「さすが！」と言われたら良いシステムだったかと言われると、必ずしもリンクしているとは限りません。システムトータルで十分な費用対効果が出て、且つ部分的な機能にも高い満足度が得られるシステムというのは規模が大きくなればなるほど難しくなります。

根底にあるのはユーザー側の「こんだけ高い金払っているのに」という感覚ではないかと思います。
例えば1万円くらいの市販パッケージソフトがあったとして、よほどに使い物にならない限りは機能や操作性は受け入れられていきます。
これが数千万円規模の導入プロジェクトだとそうはいきません。

システム導入費用は、二言目には「高い」と言われます。まして追加要件に対する見積なんか「高い」と言われないことのほうが稀です。
SEはモノづくりをほぼ全て単価で考えます。変更案件があれば変更規模に応じて工数を積み上げて見積を作ります。
しかしユーザーはプロジェクトの総額で考えます。車を買ったらカーナビが無料になったり、オプションが割引されたりする感覚です。「こんな追加くらい当初費用内でできないのか」となるわけです。

最終的に提供される「製品」は同じかもしれませんが、カーナビやオプションは販促費で計上されている「おまけ」であるのに対して、システムは「車本体」です。
既に購入している既製品の売価とこれから組み上げるために必要な材料費と手間賃は同じ扱いにはできません。
医者に向かって「高い診察料払ってるんだから、その診察料でついでに家族も診察してくれ」と言っているようなものなのです。

こうしたユーザー側の感覚は一朝一夕で変わるものではありません。
だからこそプロジェクトが目指すべきゴールを明確にしておかなければ、ビジネスベネフィットの達成は非常に難しいものになるのです。

３．ワーク＆スケジュール

ごく簡単に言えばWBSとスケジュールの管理です。

作業タスクは漏れなく洗い出されているか、マイルストーンに対する遅れは無いか、あるのであればどこまでにリカバリするのか、外部サプライヤーが入る場合その管理は文書化されているか、といった観点になります。

SEをはじめ、プロジェクト型の仕事が長時間残業の巣窟になる原因の一つがここにあります。タスクの洗い出しが不十分か、スケジュールの引き方がいい加減か、もしくはその両方か。これが長時間残業の理由の８割くらいの原因だと思います。
残りの２割はスコープが流動的だったりリスクが顕在化した場合などがありますが、スコープがぶれずに大したリスクが顕在化しなくても残業時間がさほど減らないと考えると、主たる要因はワーク＆スケジュールにあると思うのです。
スコープ増だって、増えたスコープに見合ったスケジュールを引けば問題無いところを、無理やり捻じ込もうとするから破綻しているだけです。

SIerのスケジュールは基本サービスインの期日から逆算で作成されます。
この時点で作業ボリュームによるスケジュールの積上げは一旦無視されます。
そして引かれたスケジュールに沿って要員が配置されていきます。
作業を実施するのに必要な要員を割り当てていくのですが、１人月の作業を20人でやったからといって１日では終わりません。
人が増えてもスケジュールは比例して短縮しないことはわかっているはずなのに、何故か都合よくそのことが忘れられます。
それどころか当て込むはずだった要員が他の案件に捕まってアサインできなくなってから別要員を探す間、予定された成果物を作る人数は減るのにスケジュールは変更されないことも普通にあります。
ようやく連れてきた要員のスキルが、当初見込んでいた人と比べて劣っていて生産性が想定通りに出なかったとしても工期は変わりません。
結局残業して作業時間を作り出すしか手が無くなるのです。

よく「スケジュールは余裕を持って」と聞きますが、そんなスケジュールを見た記憶はほとんどありません。タイトなうえにもタイトに詰め込まれ、生産性を無視した計画と「目標成果物が完成した時が退社時間」という一見当然そうな理屈が相まって毎日深夜まで作業が続くことになります。

４．チーム

ステークホルダーはどちらかといえばユーザーサイドや外部サプライヤーなど、ベンダーから見て「外側」の人の管理ですが、こちらは「内部」の体制についてです。

既にワーク＆スケジュールで記載したようなメンバーのアサインを含む体制の構築、作業環境や設備の調達などを問われます。
作業環境や設備には開発環境の整備や、必要に応じてプロジェクトルームの整備、現地作業端末の確保などが含まれます。

繰り返しになりますがメンバーのアサインについて、とりあえず必要工数を埋めるための頭数をかき集めてくるだけではプロジェクトはまともに機能しません。
しかし万全の体制でプロジェクトに臨めることは必ずしも多くはありません。
プロマネの手腕の一つとして、上手に人をアサインすることが求められます。そのために人脈や経験がものを言う部分が出てきます。
若いプロマネに任せるのであればこの部分を上位者がサポートしてあげる必要があるでしょう。

５．スコープ

プロジェクトを炎上させる最大の要因と言われるのがスコープです。簡単に言えば「作業範囲」「責任範疇」のことで、これがブレると他の計画が全て変更を余儀なくされる場合があります。

先ほどの車の話を引継ぐと、ユーザーが「この車種のこの年式のこの形式が欲しい。オプションはこれとこれで、今乗っている車を下取りしてもらった上で予算はこれくらい。」くらいまで明確に欲しいものが決まっていれば、調整や交渉はほとんど必要ありません。

しかしシステム導入となると、「車が欲しい」くらい漠然とした要望か、よくて「軽自動車がいい」「燃費のいい車がいい」「人がたくさん乗れる車がいい」「荷物がたくさん積める車がいい」くらいのイメージでディーラー（＝ベンダー）にやってくることがほとんどです。

ディーラー（＝ベンダー）は車の大きさ、色、排気量、積載量、インテリアやエクステリアに至るまで事細かに聞き取ります。その結果、「軽自動車がいい」といっていたユーザーが高級外車や２トントラックを要求しはじめるという現象が起こるのがシステム導入の世界です。

仕様凍結のタイミングや変更管理の手順についての合意であったり、追加要望の管理が求められます。また以前お話してきた非機能要件についても、スコープ管理から漏らさないようにしなければいけません。

６．リスク

リスク管理と聞いて課題管理表だけ思い浮かべた方は、リスクマネジメントの知識が不十分かもしれません。
リスクとは現在顕在化していないが今後起こる可能性があり、顕在化した場合に他の要素に影響を与える可能性があるものです。課題は既に顕在化していて解決しなければいけないものです。

リスクマネジメントは顕在化していないリスクと顕在化した課題の両面を見ていく必要があります。

リスクは顕在化する可能性の高さと、顕在化した場合の影響を組み合わせて評価し、事前に対策を行うのか、継続して注視するのか、なにもせず放っておくのかといったレベル付けをしていきます。
このレベル付けを誤ると無駄な労力を使う羽目になったり、逆に何の対策もできていないリスクが突然顕在化してプロジェクトを奈落の底に引きずり落としたしります。

リスクの要因になりうるのはここまで紹介した５つの要素全てです。
ステークホルダーを説得できなかったら、ビジネスベネフィットをユーザーが十分に感じられず満足度が低下したら、スケジュールが遅延したら、メンバーがうまくアサインできなかったら、スコープが変動したら。
全て起こりうるリスクですが、起こっていないことに対して全て手を打つことはできません。起こってからでも対処できるものは放っておくこともできます。
またリスクが顕在化する確率が高くなってから手を打つことにして、発生の可能性だけをトレースしていくことも可能です。
明らかに顕在化の兆候が見られたら即座に手を打つことも必要でしょう。

リスク管理は現状の情報を正しく把握・認識してはじめて行うことができます。
そのため各担当者はプロジェクト進捗の報告資料作成に日々追われることになるということも発生していますが、それはワーク&スケジュールにプロジェクト管理のためのタスクを入れていないことが原因です。

また課題については、何時までに、誰が対応して、どのようにクローズさせたのかまでトレースしておく必要があります。予定していた期限までに課題が解決しない場合、なんだかの手を打つ必要があります。

以前の職場の上司から「課題管理表に残課題を残すな。解決した課題の結果しか書いてはいけないと思え」と言われたことがあります。かなり無茶な言い方に聞こえるかもしれませんが、それくらいの覚悟をもって望まないと課題は永遠に残り続ける、という意味です。
管理された状態に移行した課題には優先度が付けられ、重要性が低く程度が軽いものは後回しにされます。

いくら重みづけをしても、やはり残課題は件数ベースで認識されることが多いです。
１件でも多く減らせることで管理コストもそれだけ減ることになるので、「程度が軽いならとっとと終わらせてしまえ」ということも必要になる場合があります。

広義のリスクとして、品質マネジメントもここに属すると考えていいかもしれません。

７．デリバリー

QCDのDと同じく利益のことです。ビジネスベネフィットがユーザーの利益だとすると、デリバリーはベンダーの利益のことを指します。

プロジェクトは慈善事業ではありませんから、当然予算貢献・利益貢献が求められます。
コストマネジメントをきちんとして、売上を作り利益を確保できてこそのビジネスです。

コストだけ注視していてもプロジェクトは回らないので、全体の要素の中でのバランス感覚も重要です。

これらの要素をバランスよく、正確に把握することがプロマネに求められる役割であり、結果として数字と格闘する割合がどんどん増えていくことになるのです。

あとがき

だいぶ長くなりましたが、ベンダー側のプロジェクト管理の観点を一通り説明してきました。こうした観点でベンダーの動きを見るときちんと管理されたプロジェクトであるかどうかがわかります。
管理が不十分だと思った部分はこちらから指摘していかないと、最終的に提供されるサービスの品質という点で迷惑を被るのはユーザーです。なんでもかんでもベンダーにお任せで、ものができてから文句を言うだけでは本当に良いものはできません。

ユーザー側でも、今回のような観点でベンダーがきちん動いているのか確認したり、社内のメンバーの動きや情報を正しく把握し統制するなど、管理すべき事項はたくさんあります。しかしユーザー側はシステム導入プロジェクト自体そこまで頻度が少ないため、確立した管理手法のようなものがあまりありません。

そこで次回は今回の内容を踏まえてユーザー側に置き換えたプロジェクト管理の観点を考えていきたいと思います。

RFI・RFP／プロジェクト管理関連の記事を纏めています。