PMO（プロジェクトマネジメントオフィス）を生かす_9

第81回 小規模プロジェクトだってPMOは生かせる

小規模なプロジェクトの予算を見積もるとき、PMOを参画させるためにコストを割いているだろうか。規模が小さいほど削られがちな“管理工数”だ が、小規模プロジェクトに合ったPMOの生かし方がある。PMOを必要とするのは規模の大きなプロジェクトという先入観を持たずに、プロジェクトの本当の成功のためにPMOの参画を検討してみてはいかがだろうか。

小林 慶志郎
マネジメントソリューションズ

 

　大規模プロジェクトならともかく、小規模なプロジェクトにPMOなんていらない――。そんな声が聞こえてきそうですが、本当にそうでしょうか。小規模プロジェクトには“小規模だからこそ”の難しさがあるはずです。

　イメージを合わせるために、ここでは小規模プロジェクトを50人月以内、プロジェクトメンバーは最大でも15人程度としましょう。

　これくらいの規模だと、予算の確保が難しいことも原因になりますが、「プロジェクトマネジャー（PM）が全体の状況を把握できる」とか、「PMOの役割はリーダーが兼任すれば十分」などと言われて、PMOの参画のためにコストを割かないケースが少なくないと思います。

PMやリーダーは実作業やレビューで結構忙しい

　ただ、そうしたプロジェクトの実態は、事前の見通しとかけ離れてしまいやすいものです。PMやリーダーがプレイングマネジャーとなっており、実作業やレビューなどに多くの時間を取られてしまうからです。業務やシステムに詳しい人がPM兼リーダーの役割を担うケースが多いためでしょう。結果的にマネジメントにかける時間はほとんどなくなり、WBSはメンテナンスされず、課題は期限を過ぎ、徐々にメンバーのコントロールが効かなくなっていきます。

　規模が小さいため、メンバーの踏ん張り（残業や休日出勤など）により、結果的にはスケジュールに間に合わせることができるかもしれません。しかし、メンバーのモチベーション低下や疲弊を招いたとしたら、プロジェクトとして本当に成功したとは言えません。

　そんな状況を変えるのに必要なのはPMOの役割です。プレイングマネジャーとなっているPMやリーダーに代わって、プロジェクト全体の状況把握をはじめ、スケジュールの管理や課題・リスクの把握、対応を推進していくことが必要です。

PMOに求められるオールラウンダー性

　とはいえ、こうした状況では、PMOにもある程度のスキルが求められます。PMO側の視点で考えると、プロジェクトに人数が少ない分、オールラウンダー として雑多な仕事の処理も求められますし、プロジェクト内で発生する課題や問題、悩み、相談事をいったんすべて受け止め、適切な負荷とスキルを見極めて PMやメンバーにタスクを振り分け、時には自分で解決していく必要があります。

　「第77回 新任PMOが悩むPMOの立ち位置（1）」の中で、『（PMOが課題・問題を）「拾うこと」と「自分でやること」はイコールでない』と述べましたが、小規模プロジェクトではある程度「自分でやること」も増やしていく必要があります。

　もちろん、PMOとしてやるべきことを見失い、メンバーの作業支援を始めてしまっては元も子もありません。自分のコントロールも含めて、適切なタスクの振り分けが必要になります。PMOが「メンバーの一人」になってしまったら意味がないのです。

　このように、PMOには「なんでもやる覚悟」と、その一方で「メンバーの忙しさに引きずられない強さ」が必要となります。

プロジェクトマネジャーとPMOの役割分担

　これらを考慮し、小規模プロジェクトで効率的にPMOを活用するためには、次の2点がポイントになります。

（1）PMOが得意とする分野（マネジメント面）をPMOに徹底的に任せること。
（2）PMやリーダーは、自分たちが得意とする分野（業務面など）に集中しながら、マネジメントの要点のみをPMOを通じて押さえ、意思決定をしていくこと。

　役割分担を明確にした適材適所の考えのもと、PMOをアサインすることで、プロジェクトを成功に導ける確率は上がるのではないでしょうか。規模に関わらず、PMOを生かす方法はあるのです。

第82回 「本当に必要な管理」を見極める

　プロジェクト管理における計画書を作成し、それに則ってプロジェクトを進める――。これがPMOの一つの役割である。しかし、プロジェクトの規模 を考えずに同じことをやって、本当にうまくいくだろうか。人数に対して管理工数が重くなれば、スピードが求められる小規模プロジェクトは潰れてしまう。小規模プロジェクトでは、個別のプロジェクトに合わせた管理方法の検討が特に重要になっている。

小林 慶志郎
マネジメントソリューションズ　中小企業診断士

 

　前回、 小規模プロジェクトでのPMOの活用について述べましたが、中～小規模プロジェクトに参画すると、プロジェクト管理がうまく適用されていないケースが多く見られます。「規模が小さいから」とか、「人数が少ないから把握できる」といった理由をこじ付けて、あらゆる管理をないがしろにしている場合が多いのでは ないでしょうか。

　こういったプロジェクトでは確かに目先の状況は把握できているのですが、先のフェーズのことまで考慮して本当にプロジェクト全体を把握できているケース はあまりありません。そのため、PMOとしてプロジェクトに参画すると、まずは状況を見える化して先のフェーズまで含めた情報収集を開始することになるで しょう。

　もちろん、その動き自体は間違っていません。ですが、その方法と、力の入れ具合には注意が必要となります。プロジェクトの特徴や事情、人数や文化に合わせた管理を導入していく必要があるのです。

ルールは存在に意味があるのではない

　ここで、私の経験を紹介します。40人月程度の小～中規模プロジェクトでの話です。テストフェーズでプロジェクトが混乱しており、その立て直しのために参画しました。まず、そのプロジェクトで作成していた資料を見てみると、前任者によってテスト計画書がしっかりと作成されていました。その内容も非常に充 実したものでした。

　しかし、現場ではこの計画書の内容がまったく守られていませんでした。なぜかというと、その理由は次のようなものでした。

（1）このチームでは実施したことがないほどの「必要以上に詳細な管理項目」が設定されている。
（2）テスト計画書が40ページにもわたる資料で、とてもメンバーが気軽に参照できない。
（3）ルールが詳細に規定されすぎていて、ルールから外れてしまった時（混乱状態）に対応できない。
（4）そもそもメンバーへのテスト計画書の説明が足りない。

　前任者の作成したテスト計画書に書いてあることは間違っていません。大規模プロジェクトだったら、そういう管理が必要になったでしょう。ですが、その時 のプロジェクトチームにはまったく適合していませんでした。私は参画してすぐに、「メンバーが一目で見て分かるレベル」まで情報をそぎ落とした資料を作成し、メンバーに配りました。それにより、プロジェクトは少しずつ混乱から抜け出し、ゴールに向けて動き始めました。

身の丈に合わない管理は撤廃するべし

　上記は、管理の枠組みはしっかりできているにも関わらず、うまく運用できなかった事例です。このチームの中核メンバーには、冒頭で挙げた「人数が少ない から把握できる」という文化が根付いていました。メンバーを増やしてやや規模が大きくなっても、同様の管理レベルで対応しようとして、苦しんでいました。そこで、前任者はしっかりとした計画書を作成し、チームをコントロールしようとしたわけです。しかし、これは定着するどころか逆に混乱を招いてしまいまし た。

　この管理方法は、10人に満たないプロジェクトメンバーからすると、「なぜここまで必要なのか理解できない」ものだったと言えるでしょう。もちろん、説明が足りないことも大きな原因の一つです。加えて、取得したい情報、管理したい内容が、規模に対して過剰だったのです。

　どんなプロジェクトでも同じですが、過去の経験やPMBOKなどの知識にとらわれずに、本当に必要な情報だけを収集する仕組みを考える必要があります。

本当に必要な情報とは何か

　それでは、本当に必要な情報とは何でしょうか。システム開発プロジェクトのテストフェーズで実施される、障害の分析を通じた品質分析を例にして考えてみたいと思います。

　品質分析とは、テストフェーズにおける品質を保証したり、工程上の問題点を見つけて対策を打ったりするための活動です。テストフェーズの中で発生した障害の内容を分析することで、その傾向からシステムの品質を見極めていきます。

　この品質分析では、「開発規模に対する障害発生数」「日別の障害発生数」「発生から解決までの期間」「不具合を本来発見すべき工程」「不具合の原因となった工程」「原因箇所」などの情報を用いて、分析を行っていくケースが多いです。

　これらの情報を収集することで、以下のような分析ができます。

（1）開発規模に対して障害が多く出すぎていないか
（2）テストフェーズが進むにつれて、障害発生数は収束しているか
（3）対応者の速度が極端に低下していないか
（4）前工程に重大な問題はなかったか
（5）特定の機能に障害が集中していないか

　テストフェーズが始まる前に、品質分析を含めたテスト計画を検討していると、PMOとしてこれらの情報を「集めなければいけない」と思い込んでしまうことがあります。様々な角度から分析するためには、必ず情報を取得する必要があると考えてしまうのです。

　ですが、ここでプロジェクトの状況を考えてみる必要があります。これらの情報を集めるためには、プロジェクトメンバーに情報を入力してもらう必要があり ます。こういった情報の入力に慣れたメンバーの多いプロジェクトなら問題ないかもしれませんが、慣れていないメンバーが多ければ、「作業が増える」と反発も大きいでしょう。

　少しでも無駄を省いて効率的にプロジェクトを進めるためには、一つひとつの項目に対して、本当に必要か、なぜ必要なのかを、しっかりと検討していく必要があります。

「無くてもいい情報」に手間をかけない

　それぞれの情報の必要性を、小規模プロジェクトに当てはめて考えてみます。ここでは、テストを実施しているのが5人、テスト期間は4週間程度とします。

　例として、先に挙げた「原因箇所」や「発生から解決までの期間」について考えてみましょう。

　「原因箇所」の偏りは、日々進捗を確認するタイミングで当日に発生した不具合をチェックしていけば、傾向を把握できます。日々それを記録していけば、メンバーに入力させる必要もなく、入力させるための工数をPMOが割く必要もありません。

「発生から解決までの期間」も、不具合対応を行うメンバーの進捗状況を見ていれば、負荷状況は十分把握できるでしょう。そもそも4週間では、傾向が出始めてから対策を打つころにはフェーズ終了の目前になっています。

　これらの「小規模だったら、わざわざ収集しなくても何とかなる情報」を、メンバーの手を煩わせて入力してもらい、厳密な数値管理をすることが本当に必要か、一つひとつ見極めていく必要があるのです。

　品質分析の他の情報でも、まったく別の管理資料でも、一つひとつの項目について、あなたの参画するプロジェクトで「本当に必要なのか」「なぜ必要なのか」をしっかりと確認してみると、無駄のないプロジェクト運営を行っていけるでしょう。

必要なものは必要、削るのは不要なものだけ

　一方で、気をつけておきたいのが、必要な情報やプロセスまで削ってしまうことです。冒頭で述べたとおり、あらゆる管理がないがしろにされていることが多 いのですが、それは良くありません。たとえば、どんなに人数が少なくてもWBSは必要です。また、変更管理を削るとプロジェクトのゴールが不明確になって しまいます。規模が小さくても、変更のインパクトはしっかり管理する必要があります。

　こういった「必要な管理」と「無くてもいい管理」をしっかり見極めて、最小限の管理プロセスを導入していくことが、小規模プロジェクトにおけるPMOの 重要な役割になります。大規模プロジェクトも本質的には同じですが、スピードが重視される小規模プロジェクトではより重要なポイントとなっていきます。

第83回 ルールをかみ砕いて浸透させることの大切さ

　計画書が充実したプロジェクトは、管理が行き届いているような印象を与える。だが、その計画書をプロジェクトメンバーがどこまで読み込み、理解し ているだろうか。計画書に記載されたルールをかみ砕いてメンバーに浸透させ、計画書に命を吹き込むことでプロジェクトを円滑に推進していく必要がある。

小林 慶志郎
マネジメントソリューションズ　中小企業診断士

 

　プロジェクト管理の標準化は進んでいても、それが定着しない会社があります。この問題については『第76回 標準化が定着しない理由』で、PMOがテーラーメイドを行うべきと述べています。前回の『第82回 「本当に必要な管理」を見極める』 でも、しっかりとテスト計画書が作成されていたにも関わらず現場のメンバーに定着しなかった事例を紹介しました。この事例もテーラーメイドの失敗が大きな原因でした。ただし、私はもう一つ失敗の原因があると考えています。そもそも標準化された計画をメンバーが理解できていなかったのです。

　計画書を見慣れたPMOからすると、いつも通りの資料かもしれませんが、新しく参画したメンバーからすると、複雑な資料に見えるかもしれません。そこでPMOがこれらの資料をかみ砕いてメンバーに伝えていく必要があるのです。

ルールは詳細なだけでは伝わらない

　みなさんがイメージしやすいように一つ例を挙げます。

　あなたは仕事中に、自分の会社の社内規定や就業規則、業務規定をいちいち参照するでしょうか。実際には、自分の業務にかかわる部分だけを分かりやすくフ ロー化したものが作成されていて、それだけを見ていることが多いと思います。厳密なルールはもちろん必要ですが、もし閲覧できる資料が分厚い社内規定集しかなかったとしたら、現場のあなたは「もっと分かりやすく説明して！」と叫んでしまうことでしょう。

　プロジェクトでも同様です。統制をとるために詳細なルールは必要なのですが、その伝え方には工夫と相手に対する配慮が必要になります。ここに、PMOが価値を発揮できるポイントがあります。

ルールではなく手続きとして伝える

　たとえば、課題管理プロセスを変更する場合、各チームリーダーには「課題管理プロセスのエスカレーション先が、チームリーダーから統括リーダーに変わります」と説明すればいいでしょう。

　一方で、現場のメンバーに説明する際には、「課題を見つけたら○○さんではなく、××さんに知らせてください」と伝えたほうが、間違えもないですし、理解しやすいはずです。

　このように、現場のメンバーには「ルール」ではなく、「手続き」として伝えていく必要があります。プロジェクトが猛スピードで進んでいる中では、計画書などが網羅的かつ詳細に記載されているほど、メンバーがそれらをすべて読み込んで理解するのは難しいはずです。

　プロジェクトマネジメントの成熟度が高い企業ほど計画書をしっかりと作成しています。その半面、新しく参画したメンバーからすると、計画書はとっつきにくく、縁遠い存在になってしまう、という矛盾が生じやすくなるのです。

PMOがルールの伝道師となってメンバーを育てていく

　上述の例のように、PMOは「ルール」と「メンバー」の間に入り、ルールをかみ砕いて伝えていく役割を果たす必要があります。たとえば、計画書の一部を簡素化したプロセスフロー図を作成したり、具体的な人の名前を入れた説明資料を作成したり、時には個別に説明したりすることで、メンバーへのルールの浸透 を図っていきます。

　「PMOがそこまでやるのか」と疑問に思う方もいるかもしれませんが、必ずやるべきです。メンバーにしっかりとルールが浸透すれば、プロジェクト運営は圧倒的に円滑になります。それだけでなく、ルールの目的や内容をしっかりと伝えることにより、マネジメントの視点を持ったメンバーの育成にもつながってい きます。

　このようにPMOがメンバーに対して徹底的にルールを浸透させる役割を果たせば、「プロジェクトの成功」と「メンバーの育成」という二つの大きな成果に貢献するはずです。

第84回 「数字」の持つ説得力に惑わされるな

　プロジェクトの見える化については本コラムでもたびたび取り上げてきた。見える化により、進捗、課題の状況、リスクの影響度など、プロジェクトの様々な側面を客観的に把握することが可能になる。

　しかし、これらの数字を鵜呑みにしていないだろうか。数字を見せられると、人は思わず納得してしまうことがある。適切な判断を下していくためには、数字をそのまま受け止めるのではなく、一歩立ち止まり、その数字の本質を見極める必要がある。

小林 慶志郎
マネジメントソリューションズ　中小企業診断士

 

　プロジェクトの「見える化」の取り組みでは、進捗、課題の状況、リスクの影響度など、ややもすると定性的になりがちな情報を一定のルールで数値化し、プロジェクト関係者が客観的な情報をもとに共通認識を持てるようにしていきます。

　一方で、注意しておくべき点もあります。数値には「状況を明確に知ることができる」という利点がある半面、「いかにも正しそうに見える」という罠があるのです。

具体的な数字を示されると弱い

　どういうことか、例を挙げてみます。定性的に「スマートフォンユーザーは男性の方が多い」というよりも、数字を入れて「スマートフォンユーザーは男性が 約6割を占めており、女性よりも約335万人多い」と言われたほうが、説得力があるように感じるのではないでしょうか。この情報源や調査方法、発信者すら全く知らなくても、このように具体的な数字を示されると、思わず「正しいだろう」と思いこんでしまうことがあるのです。

　この「いかにも正しそうに見える」という事態は、プロジェクトの現場でも発生します。

　たとえば、進捗会議で「10日間かかる作業を、6日経過していて60％の進捗です」との報告がありました。これは「スケジュール通り」と考えていいでしょうか。

　まずは60％という数値が、何をもとに判断された数値なのか確認する必要があります。「100のタスクを終わらせるうち、6日経過していて60タスクが終わっています」という報告が加わると、さらに「正しそうに見える」度合いが増してきます。

　しかし、残りの40タスクは今までと同じ速度で対応できるのでしょうか。もしかしたら、難易度の高い作業ばかりが残っているかもしれません。あるいは、残りの期間は別の作業を並行して進める必要があり、これまでのように時間を割くことができないかもしれません。こういった点を含めて、「進捗60％」とい う数字の実態を確認する必要があります。

　数値化されていることに安心し、その数字を「正しそう」と思い込んでしまうことがないように、一つひとつの数字の「裏付けをとる」ことはとても大切です。

「数字」の本質を見抜け

　このように数字には、「正しそうに見え」、人を納得させてしまう力があります。ですので、自分が何かを伝えたいときには有効に利用すべきでしょう。

　その一方で、数字の力が強いからこそ、使う側も慎重になる必要があります。数字を見る側も、その内容をしっかりと見極めていく必要があるのです。

　プロジェクトにおいて重要な意思決定を求められるプロジェクトマネジャとその支援をするPMO（プロジェクトマネジメントオフィス）として、目の前に出てきた数字の本質を見抜き、適切な判断を下していくことが求められます。

第85回 見える化の目的は「評価」ではない

　様々な情報を見える化・数値化すると、予定と実績の対比が可能になり、客観的な状況の把握が容易になる。だが、進捗の予実を見て予定を下回っていたときに、頭ごなしに「ダメじゃないか！」と怒っていないだろうか。それでは、見える化の本来の目的を達成するのは難しい。

小林 慶志郎
マネジメントソリューションズ　中小企業診断士

 

　あなたのプロジェクトで、こんな会話を耳にしたことはないでしょうか。

プロジェクトマネジャ（PM）：「Aチームの進捗状況はどうなっていますか？」

チームリーダー：「予定では15タスク終わっているべきところですが、進捗が思わしくなく、現在13タスクしか終わっていません」

PM：「あれ、遅れているんですか？ 先週聞いたときは、今週までに終わると言っていたじゃないですか」

チームリーダー：「はい…、先週時点ではそうだったのですが…」（PMからの無言のプレッシャーに負けて）「でも、今週末までに必ずリカバリーします（出来るか分かりませんけどね）」

PM：「わかりました。それじゃあ来週また報告してください」

　この会話は極端な例に見えるかもしれません。ですが意外に身近なところでこんなやり取りがされているのではないでしょうか。

　この会話の後、チームリーダーは期日に間に合わせるために頑張るでしょう。そして優秀なリーダーであれば、期日を守り、事なきを得るかもしれません。で すが、状況によっては「頑張ること」が解決策にならない場合もあります。もし終わらなかった場合にどう対応するのか、この会話の中では議論の余地がありません。

　少なくとも、こんなやり取りを繰り返せば、チームリーダーはPMに対して、悪い話は報告しなくなってしまうでしょう。

PMの話し方次第で、がらっと結論が変わる

　一方、同じ話でも、こんなやり取りをすると違った結果が出てきます。

PM：「Aチームの進捗状況はどうなっていますか？」

チームリーダー：「予定では15タスク終わっているべきところですが、進捗が思わしくなく、現在13タスクしか終わっていません」

PM：「そうですか。遅延の原因は明確になっていますか？」

チームリーダー：「はい、XX機能の開発が予想以上に難しくて、時間がかかっていまして…」

PM：「チーム内で対応の見込みは立っていますか？ 他チームの協力は必要ないですか？」

チームリーダー：「XX機能の問題はチーム内で有識者を集めて今週末には対応できますが、後続のYY機能の開発に影響が出てしまうかもしれません」

PM：「わかりました。遅延の可能性があることを、早めに関係チームに伝えておきましょう」

　PMの話し方次第で、チームリーダーもPMに状況を報告しやすくなるのではないでしょうか。

見える化の目的が誤解されたまま現場に定着…

　それでは、このPMと、先ほどのPMとの違いは何でしょうか。大きく違っているのは、「何のために進捗を数値で管理するのか」という点に関する認識です。

　前者のPMは、守るべき予定を数値化し、それを守らせることが管理だと考えています。そのため、進捗を守れていれば“良し”、守れていない場合は“ダメ”という判断を下そうとします。

　後者のPMは、予定と比べて遅れているという状況について、原因と対策、その先のリスクを早期にキャッチするための情報として、数値を活用しているのです。

　このように比較してみれば、後者のPMのように判断する必要があると理解していただけると思いますが、前者のPMのように、数値を組織や個人の評価に使 うという考え方は、実は多くの現場に根強く残っているように感じます。そして、PM、チームリーダー、メンバーのすべての層に、その誤解は定着していま す。

ブレのない態度で「見える化の本来の目的」を徹底的に示せ

　プロジェクトではEVM（Earned ValueManagement）の手法を取り入れたり、経営の見える化においてはKPI（主要業績指標）を取り入れたりするなど、様々な場面で様々な見える化・数値化に取り組み、改善につなげようとしています。

　しかし、表面化した数値だけを見て良し悪しを判断しようとすると、報告者が報告内容についてネガティブな印象を持ってしまい、悪い状況が顕在化するまで 報告されなくなるような弊害を引き起こします。また、現場の理解と協力が特に重要となるKPIの導入においては、運用そのものの定着が非常に困難になって しまいます。

　見える化が、組織や個人の評価を目的としているのではなく、対策の検討やリスクの抽出を目的としていることを、しっかりと理解してもらう必要があるのです。

　この点について理解を得るのは非常に難しいことです。組織に根付いている文化や意識を変えていく必要があるからです。そのためには、プロジェクトを通じ て本来の目的を伝え続けることはもちろんですが、言葉で伝えていくだけでなく、PMやPMOがブレのない態度で徹底的に示していくことが重要になっていき ます。

　数値化して客観的な情報を得ることの目的は、その数字を見て良し悪しを判断することではありません。数値の傾向を見て、早期に対策を検討し、潜在的なリ スクを抽出することが真の目的なのです。この目的をプロジェクトの共通認識にすることが、プロジェクトマネジメントを円滑に行うための大きな一手となるでしょう。

第86回 続・繰り返される「引き継ぎミス」

　以前、『繰り返される「引き継ぎミス」』にて、引き継ぎの難しさと勘所について書いた。今回は、実際に筆者が失敗した、もう一つの引き継ぎミスについて述べたい。皆さんの引き継ぎに少しでも役に立てればと思う。

後藤 年成
マネジメントソリューションズ 取締役 PMP

 

　第56回の『繰り返される「引き継ぎミス」』では、引き継ぎに伴う難しさの典型例として以下の7つの典型例を挙げました。

【典型例1】遅すぎる後任者の指名
【典型例2】引き継ぎ範囲の線引き
【典型例3】後任者の引き継ぎ余力の有無
【典型例4】引き継ぎ時期の代休消化がもたらす余波
【典型例5】引き継ぎ内容のクオリティ
【典型例6】重要な課題の引き継ぎ
【典型例7】引き継ぎ後のコミュニケーション問題

　筆者も日々のプロジェクトにおいて、引き継ぎが発生する場合は上記の点に注意を払ってきました。しかし、重要な注意点が一つ抜け落ちていることに気づきました。それは、筆者が引き継ぎで失敗を経験することによって明らかになりました。

　筆者はあるプロジェクトにて、前述した7つの点に注意しながら引き継ぎを行いました。業務内容をほぼ完璧に引き継ぎ、約1週間は後任者と並行して業務を進め、念には念を入れました。引き継ぎの品質には何も問題がないはずでした。

　ところが、引き継いだ後1～2週間ほどたって、後任者の立ち上がり状況を確認したところ、後任者のパフォーマンスがあまり上がっていないことに気が付きました。業務の内容は完全に引き継いだはずでしたが、何がまずかったのでしょうか。

最も引き継がなければならないのは「人のつながり」

　様々な人にヒアリングした結果、どうやら他のメンバーやキーパーソンとうまくコミュニケーションができていないことが分かりました。その担当者は、今ま でいくつもの難しいプロジェクトで実績を残しているので、元々コミュニケーションが苦手な担当者ではありません。どちらかというと周りからは「優秀な人」という風に見られていました。

　ここに落とし穴がありました。「後任者は優秀な人」という考えのもとに引き継ぎを進めていたため、私がそのプロジェクトで作り上げてきた「人のつなが り」の引き継ぎを怠っていたのです。心のどこかで、「プロジェクト内の人間関係なんて個人で個別に作り上げていくもの」という誤った考えがあったのです。

　PMOとしては、「業務のほぼ90％がコミュニケーションで成り立っている」と言っても過言ではありません。しかし、その肝心のコミュニケーションの基礎である「人のつながり」の引き継ぎを、後任者の紹介程度で済ませてしまったことが失敗の原因だったのです。

キーパーソンを交えての引き継ぎが重要

　皆さんも経験があるように、プロジェクトにおいて「人と人との信頼関係」を構築していくのは、一朝一夕でできるものではありません。ある程度の期間をかけて、徐々に「人と人とのつながり」ができてくるものだと思います。

　しかし、プロジェクト途中の引き継ぎにおいて、そこから「人と人とのつながり」を個別に作り直していくとしたら時間の余裕がありません。特にPMOという立場であるならば、立ち上がりが遅れて、十分なパフォーマンスを出せない恐れがあります。

　それを回避する一つの方法として、「人と人とのつながり」もきちんと引き継ぐべきなのです。多少時間はかかるかもしれませんが、キーパーソンを交えて引 き継ぎを行うとより効果的です。プロジェクトの背景や経緯、今後の方針、キーパーソンの期待値など、引き継ぎ資料だけでは表現することができない情報に加え、そのキーパーソンとの「つながり」も引き継ぐことができるからです。

結局は「人」と「人」の問題

　ただし、「人と人とのつながり」の引き継ぎができたからといって、安心はできません。悲しいかな、どのプロジェクトでも必ず「人の好き嫌い」は付いて回ります。プロジェクトは仲の良い好きな人ばかりが集まってできた組織ではないため、仕方のないことだと思います。

　正直な話、どんなに前任者とキーパーソンの関係が良かったとしても、その良好な関係を後任者がそのままそっくり継承するかどうかは分かりません。引き継ぎ後に、しばらく様子を見てみないと分からないのです。

　こういう可能性を踏まえたうえで、引き継ぎを進めてみてください。繰り返しになりますが、PMOの業務のほぼ90％がコミュニケーションで成り立ってい ると言っても過言ではありません。その肝心のコミュニケーションの基礎である「人と人のつながり」を、後任者の紹介程度で引き継げると考えてはいけません。

第87回 うまい“関所”の使い方

　ある程度大きなプロジェクトの場合、プロジェクトの中間の状況を判断する“関所”のようなイベントを置く会社が多いのではないか。しかし、この関 所が「危ない所に手を打って何とか前進できるようにする場」というよりは、「何か粗探しをしてプロジェクトを止めようとしている場」ではないかと感じられることも少なくない。今回はこのような関所について考えてみたい。

後藤 年成
マネジメントソリューションズ 取締役 PMP

 

　フェーズの切れ目などの要所要所において、プロジェクト外の組織や機関から客観的な検査を受けなければならないプロジェクトを経験したことがある方は多 いと思います。プロジェクト外の組織とは、例えば「品質管理部」とか、「プロジェクト管理部」「プロジェクト監査室」のような名前で呼ばれていたりします。

　それらの組織は、プロジェクトの状況について次のような点を客観的に判断します。（1）該当フェーズの終了判断：予定通りのスケジュール、コストで、予定通りのアウトプットが出ているか。（2）次フェーズの開始判断あるいはサービスインの判断：次のフェーズの予定がしっかりと立てられていて、このまま次のフェーズ（サービスイン）に進んでも問題ないかどうか。

　しかし、その判断内容と言えば表面的・形式的でしかなく、役に立たないものになっていないでしょうか。例えば、普段は現場には全く顔を出さないような 方々がやってきて、チェックリストに従いながらヒヤリングを行うだけとか、あるいは現場から所定のチェックリストを出させて、それを見て当たり障りのないコメントを返してくるというような場合がとても多いと思います。

“吊るし上げ”で余計な苦労を強いられる

　会社によっては、同じようなプロジェクトの経験を積んできた有識者や他部門の有識者を交えて、会議形式で質疑応答をする場合もあると思います。こういう場では活発な発言がみられますが、別の意味で役に立たないものになりがちです。

　私が今まで経験してきた多くの場合、そこはプロジェクト担当者の“吊るし上げの場”になってしまいました。関所の番人として判断を下す方々は、自分の成 功（失敗）体験を現在のプロジェクトの状況に照らし合わせ、危険な状況を炙り出します。ただし、現場の状況をすべて把握できているわけではないため、具体的な対応策までは言及できません。たいていは問題点を指摘するだけで終わりです。

　ですから、「今の状況からして、私たち（レビューワー側）が検討したこの具体的な対策案を実施した方がいい。明日から一緒にやりましょう！」とか「それ では、私たち（レビューワー側）がお客様の品質部門と調整して道筋をつけてあげましょう！」といったレビューワ―主導の具体的な支援案は、これまでに片手 で数えられるほどしか聞いたことがありません。

　最悪の場合、自分（レビューワー）の経験の豊富さや権限を誇示しようと「あのリスク（起きそうにないリスク）は考えたのか。どうなってるんだ。3日以内 に対応策を考えろ！」などとあまり本質的ではない指摘をして、プロジェクトマネジャーの仕事を増やすだけの場合も少なくありません。こうした重箱の隅をつつくようなことに熱心になっている会議は、意外と多いものです。あるプロジェクトでは、そうした指摘が20個も出てきました。現場からすれば、「いまさら言われても困る。わかってるならもっと早く言ってくれよ」というのが本音でしょう。

「関所を利用する」という発想の転換

　では、このような不毛な関所の場合はどのように対応するべきなのでしょうか。考え方としては2つの方法があると思います。

　一つは、関所はそういうものだとして一度受け入れ、プロジェクト内の総点検の場として関所を活用してく方法。もう一つは、不毛な関所にならないように、関所のレビューワーをプロジェクトに引き込み、知見を有効に活用していく方法です。

　前者は、関所自体の役割を「自分たちがプロジェクトの総点検をする場」と位置づけ、有識者から「チェックを受ける」という考えから、有識者を「利用す る」という発想の転換をすることです。そして、コメントやチェックリストで見つかった問題に優先順位を付け、PMOが中心となって真摯に対応していくので す。

　この作業に対する工数やスケジュールを、プロジェクトとして事前に見込んでおくことがポイントとなります。また、前述したような、あまりにも現実とかけ 離れたり本質とかけ離れたりした指摘に対しては、プロジェクトマネジャーやPMOがうまく受け流し、現場への影響を最小限に抑えることも重要です。

　後者は、関所を通るときだけレビューワーに参加してもらうのではなく、常日頃から進捗会議などに参加してもらい、現場の状況を知ってもらうことがポイン トとなります。何かあるごとにレビューワーに相談し、レビューワーをプロジェクト側の味方にできれば、本来の関所の機能を果たせるでしょう。

　レビューワー全員がプロジェクトに常に関わるのは難しいかもしれませんが、一人でもプロジェクト側に引き込めればメリットがあります。プロジェクト側の 状況を伝えるスポークスマンとしての役割を果たしてもらうことができれば、関所の番人に対応するときの負荷を減らすことができます。

　以上のように、関所が機能していない場合の考えを述べてきましたが、会社やプロジェクトによっては「文句を言うだけではない関所」の役割をしっかり果た している場合もあります。その場合は、真摯にレビューワーの意見を聞いて、レビューワ―を巻き込み、対応を進めていくと、より良い効果が得られると思いま す。

第88回 PMOとして品質にどう向き合うか？（前編）

　PMOとしてプロジェクトマネジメントを実施していく場合、PMOとして期待される効果に「品質マネジメント」があります。筆者はPMOとして数 多くのプロジェクトに関わってきましたが、PMBOKに書いてあるような標準偏差を用いた管理など、やったことがありません。それでは、PMOとしてどの ように品質に関わって行けばよいのでしょうか。今回はシステム開発における品質管理について考えてみたいと思います。

後藤 年成
マネジメントソリューションズ 取締役 PMP

 

　PMBOK（第4版）の品質管理の章には、プロジェクト品質マネジメントは「品質計画」「品質保証」「品質管理」の3つのプロセスから構成されていると 記載されています。PMBOKはプロジェクトマネジメントを実施していく者にとって教科書的な存在ですが、果たしてどれだけのシステム開発プロジェクトで PMBOK通りの品質管理が行われているのでしょうか。「品質保証」と「品質管理」の違いが分かる人は、どれだけいるのでしょうか。また、その違いが分かったとして、果たして品質は向上するのでしょうか。

　恥ずかしながら筆者も「品質保証」と「品質管理」の違いを正確に暗記して言うことができませんし、誤解を恐れずに言えば、その違いを知ったからといって「品質管理（品質保証）」ができるようになるとも思えません。

「このプロジェクトの品質は目標値±3σの間に入ってますので…」

　また、PMBOKには品質管理のツールとして「特性要因図」「管理図」「ヒストグラム」「パレート図」「統計的サンプリング」などが挙げられています。しかし、「管理図」で標準偏差を利用して品質管理をした現場を私は経験したことがありませんし、あまり聞いたこともありません。

　そもそも「このプロジェクトの品質は目標値±3σ（σは標準偏差）の間に入っていますので…」などと言われても、ほとんどの人が「何のこっちゃ？」とい う感じになるでしょう。また、私の経験が少ないだけなのかもしれませんが、「特性要因図」や統計的にサンプリングを実施している現場もあまり聞いたことがありません。

　PMBOKはベストプラクティスであり、役に立つ場合が多いのは確かです。しかし、超大規模のプロジェクトを除けば、PMBOKの品質管理は実際のITプロジェクトには大げさすぎるというのが私の実感です。

　筆者がPMOとして品質管理を行う場合に注意する主なポイントは以下の通りです。
（1）品質指標の妥当性と目標値の意味づけ
（2）設計品質と開発品質
（3）プロセス品質とプロダクト品質
（4）非機能要件に関する品質の確保

　それぞれについて、一つひとつ見ていくことにしましょう。

品質指標とは何か？

　プロジェクトの、特にテスト工程において、皆さんは少なからず品質目標を立てたことがあると思います。よく使われる指標には「テスト密度（単位当たりの テストケースの数）」や「バグ密度（単位当たりのバグの数）」などがあります。ここで、ファンクションポイントやコード行数といった単位に、各社が独自に持っている係数を掛けて、基準値を計算するのが一般的です。ただし、この係数自体あまり説得力があるものではなかったりします。

　「ソフトウェア開発データ白書」（情報処理推進機構著・編集）などの白書にて公表されている平均値を係数として利用する場合も少なくありません。大手の システムインテグレータやITコンサルティングファームは独自の社内指標を持っています。しかし、これらもプロジェクトごとに異なる規模や特性、前提条件 を加味して考えると、設定した単一の指標を満たしていれば「品質OK」というものでもありません。

　それでは、品質指標とは一体何なのでしょうか。誤解を恐れずに言えば、「品質の指標とは単なる目安でしかない」と筆者は考えています。当然ですが、同じものを同じ品質で数多く製造していく製造業においては、品質目標は重要な指標です。

目安の品質指標でどのように品質を確保するのか？

　前項で品質指標は目安でしかないと書きましたが、具体的に言えば「その指標を満たしていないから品質が悪い」「指標を満たしたから品質が良い」と判断できるほど確かなものではない、ということです。システム開発においては、指標はあくまでも「目安」です。

　それでは、その指標を満たす場合、満たさない場合は、それぞれどのように考えればいいのでしょうか。前述の「テスト密度」や「バグ密度」の例で考えてみ ましょう。なお、一般的には、指標から±5％～20％のところに上限値/下限値を設定して管理しますが、便宜上、ここでは一つの指標（目標値）のみで管理していると仮定して進めます。

（1）テスト密度に関して
　　a）指標を満たす場合（テストケース数が目標値を超える場合）
　　b）指標を満たさない場合（テストケース数が目標値を下回る場合）

　aの場合は、目標のテストケースを上回ったので、何も問題がないと判断できるでしょうか。この場合に注意すべきポイントは、「テストケースの粒度が小さすぎて、テストケース数が多すぎるのではないか」という観点です。テストケースの数は、テストケースをどの単位で1ケースと数えるかにより、極端な話、1 ケースを10ケースに分割することもできます。ここでは、過去の類似プロジェクトや他チームのテストケースの粒度を見て、正しい粒度でテストケース数がカウントされているかどうかを見る必要があります。

　bの場合は、目標のテストケース数に達していないので、もっとテストケース数を増やさなければならないのでしょうか。この場合に注意すべきポイントは、「テストケース数というよりも、テストの観点に漏れがないか」という点です。テストの観点とは、例えば、正常ケースやエラーケース、業務上の特別運用に伴 うイレギュラーなデータの取り扱い、業務の最大ピーク時データ量に耐えられるか否か、システムが止まった場合に待機系にスムーズに移行できるかなど、業務、データ、運用などにおいて確認/テストすべき観点のことを指します。

　さすがにこの点はPMOでは分かりませんので、有識者を交えて観点の漏れを潰していく必要があります。その結果としてテストの観点に漏れがないのであれば、無理やりテストケースを増やす必要はありません。テストケースが少ない理由をきちんと説明できれば問題ないのです。

　もし、管理部門などから「目標値に達していないじゃないか？」と言われた場合は、観点の一覧を示して「すべての観点でケースを洗い出しました。先輩の今 までの経験から、漏れている観点を教えてください」と逆に尋ねてみてください。もし、新しい観点が出てきたら、それは品質向上のためになりますから良いことです。指標は絶対的なものではなく、あくまでも目安なのです。

（2）バグ密度に関して
　　c）指標を満たす場合（バグ数が目標値を超える場合）
　　d）指標を満たさない場合（バグ数が目標値を下回る場合）

　cの場合において、意見が2つに分かれることがあります。一つは、「目標値を超えたので、意味のあるテストができ、バグを出すことができた」。もう一つは「目標値を超えたということは、開発したシステムの品質が悪いんじゃないのか」。

　もし、あなただったらどのように判断するでしょうか。答えは、どちらも正解です。

　バグに関していえば、大切なのは明らかに数よりもバグの内容です。PMOとしては、バグの表面的な数だけでなく、必ずバグの傾向やバグが作り込まれた原因を追究していく必要があります。定量的な数よりも、定性的に中身を精査し、根本原因や類似バグを潰していくことで品質を向上させることが求められます。

　dの場合も2つの意見に分かれるでしょう。一つは「バグ数が目標値を下回っているので、品質が良いのではないか」。もう一つは「目標のバグ数が出ていないということは、必要なテストができていないんじゃないか」。

　この場合も、両者が正解です。cの場合と同じように、中身を見て上記のどちらに当てはまるのかを判断しなければなりません。

第89回 PMOとして品質にどう向き合うか？（後編）

　前回は、品質管理の勘所として次の4点を挙げ、最初のポンインについて考察しました。（1）品質指標の妥当性と目標値の意味づけ、（2）設計品質と開発品質、 （3）プロセス品質とプロダクト品質、（4）非機能要件に関する品質の確保――。今回は残りの（2）～（4）のポイントを見ていくことにしましょう。

後藤 年成
マネジメントソリューションズ 取締役 PMP

 

　私はプロジェクトの現場で「良いシステムを開発するために、テスト期間を長めにとって、たくさんテストを実施しましょう」という言葉を何度か耳にしたことがあります。「品質を上げるには、テストでたくさんのバグを出せばよい」と信じている方もいらっしゃいます。

　確かに、アジャイル開発のように「設計～テスト」を繰り返し実施することで品質を実用レベルに高めていく開発手法もあります。しかし、ウォーターフォー ル型の一般的な開発手法においては、上流工程（要件定義や基本設計）の品質が重要です。ここでいかに品質を上げ、「設計品質」を確保しておくかが、プロジェクト全体の品質を決めていくと言っても過言ではないでしょう。

　なぜならば、開発工程は設計成果物をインプットにして進めるため、設計の品質が悪ければ必然的に開発の品質も悪化してしまいます。その分手戻りが発生すれば、後の工程になればなるほど「品質コスト（品質を確保するために必要なコスト）」が多く発生してしまいます。

　「設計品質」を確保する代表的な観点としては、次のようなものがあります。

• プロジェクトの目的を達成するために必要なニーズを把握し、そのために必要な要件や機能を満たせているか
• 開発を担当する人々にうまく伝えられる内容になっているか
• 機能だけでなく、運用や使い勝手（いわゆる非機能要件）まで設計されているか

　これらの観点を満たすために、どのような品質保証活動をしていくか。プロジェクトの特性を鑑みて、考えていかなければなりません。

　例えば、要件定義書に書かれていることがすべて機能として網羅されているかどうか、要件定義書と基本設計書の内容を突き合わせてみる。あるいは、担当者 ごとにレビューの指摘傾向を把握して、業務内容の理解不足による間違いがないか再検査してみる。また、機能ごとの整合性が設計書レベルでとれているかどうか、有識者が集まってシミュレーションを行う、といったことも考えられます。

プロセス品質とプロダクト品質を区別しているか？

　品質管理をしていく中での基本は、PMBOKでも記載されているように「顧客満足」と「検査よりも予防」の2点にあります。

　「顧客満足」とは、言い換えればお客様のニーズを満たしたり、お客様の問題を解決したりすることです。そいういう意味においては、お客さまの本当のニーズや問題を正確にとらえられているかが重要になります。

　また「検査よりも予防」は、「プロダクト品質よりもプロセス品質」という言葉に置き換えることができます。PMOとしては、成果物を作り込んでいく過程、つまり「プロセス」において、誤りが入り込む余地をなくすような環境や仕組みを作る必要があるのです。

　例えば、設計工程において一番効果があるのは、レビュープロセスを仕組みとして組み込み、レビュープロセスの品質（決められた通りにレビューが実施され ているか）をPMOとしてサンプリング（モニタリング）しながら改善していくことです。開発工程においては、バグの原因分析を行い、類似バグを徹底的に潰していくプロセスを組み込むなどして、開発プロセスの品質を高めていきます。

　「プロダクト品質」とは、実際に作られた成果物の品質です。ここは地道に、レビューの密度や精度、テストによるバグ潰しで品質を上げていくことが重要になります。

非機能要件の品質をどう作り込むか？

　最後に、非機能要件の品質についてです。システムの詳細が決まっていない要件定義フェーズなどでは、非機能要件を明確にするのが難しいプロジェクトもあ ります。つまり、上流工程で「設計品質」を十分に確保しづらいわけです。そこで筆者が非機能要件について注意しているポイントは、「プロジェクトの全フェーズを見渡し、どのフェーズで、何を、どうやって確認していくか」を最初に計画してしまうことです。

　あるWebシステム構築プロジェクトがあるとして、その性能要件をどう詳細化していくかを計画するのです。例えば、基本構想の段階では目標性能を仮設定し、要件定義では目標性能に必要なハードスペックを確定しよう。基本設計では、サンプルプログラムを利用してハードやミドルウエア、データベース、ネット ワークの要件を確定。詳細設計では…というように、プロジェクトの全期間を通じた計画的な設計を意識しています。

　近年では、情報処理推進機構（IPA）が出している「非機能要求グレード」を利用するプロジェクトが少なくありませんし、各社が持っている開発標準に非機能要件の検討項目が含まれている場合もあります。ただ、「何を検討すべきか」は書かれているのですが、「どうやって（品質を確保するか）」や「いつ（ど のタイミングで）」については、必ずしも明記されているわけではないようです。PMOとしては、「どうやって」は専門家に任せるとしても、「いつ」につい てはPMOが全体の計画の中に落とし込んでいく必要があると思います。

「顧客満足」の期待を調整

　品質に関しては、上を目指せばきりがありませんし、最初からバグがゼロというシステムも基本的に考えられません。近年はBRMS（ビジネスルール管理システム）などの導入によって、プログラミングでのバグをゼロにする（つまり、開発品質を保証する）ことが可能になってきていますが、設計品質については、 まだ途上にあります。

　そのような観点から、上流工程において「顧客満足」のために設計品質を確保することが最重要なのは言うまでもありません。「顧客満足」という品質を具体的にどう取りまとめていくのかは、姉妹コラムである「BABOKをプロジェクトに生かす」を、ぜひ参照してみてください。

第90回 プロジェクト管理ツールをもっと使い倒す（前編）

　現在のプロジェクトマネジメントにおいては、ある程度規模が大きくなるとプロジェクト管理ツールは必要不可欠なものになる。しかし、プロジェクト 管理ツールを「入れただけ」のプロジェクトが少なくない。今回は、プロジェクト管理ツールを使い倒すために考慮したいポイントについて考えてみる。

後藤 年成
マネジメントソリューションズ 取締役 PMP

 

　皆さんもプロジェクトでプロジェクト管理のためのツールを利用したことがあると思います。現在はフリーのツールも数多く、様々な選択肢があると思いま す。また、簡単なマクロを使って作成したExcelシートを使いこなしているのであれば、立派なツールと言うことができます。

　それでは、プロジェクト管理ツールは何のために入れるのでしょうか。一番の目的はやはり、プロジェクトで発生する膨大な情報をシステムで管理することに よる「プロジェクト状況の見える化」です。ツールを使っての「プロジェクトを見える化」に関する記事はいたるところにありますので、今回は「プロジェクトの見える化」を超えてより現場の生産性を上げるためのプロジェクト管理ツールの使い倒し方を考えてみたいと思います。

「見える化」以外のプロジェクト管理ツール導入のメリット
（1）ツールはコミュニケーションの取引コストを下げる
（2）ツールはプロジェクト内の隙間を埋める
（3）ツールはプロジェクトの課題処理速度（意思決定）を高める
（4）ツールは運用ルールを定着化させる
（5）ツールはプロジェクトマネジメントの教育を肩代わりする

　上記にあるように、プロジェクト管理ツールには「現場の見える化」以外にも多くのメリットがあります。プロジェクト管理ツールの導入の際にはこれらのメ リットも最大限に享受できるように考慮すると現場の生産性も高めることが可能になると思います。それでは、上記（1）～（5）の考慮点を個別に見ていきま しょう。

コミュニケーションの取引コストを下げるための工夫

　プロジェクトを進める中で、当然のことながら、関係者はコミュニケーションを取りながら、プロジェクトを推進していきます。個人がそれぞれ1対1のコ ミュニケーションをとると仮定すると、メンバー数（n）に対するコミュニケーションパスの数は、「n(n-1)/2」で表すことができます。例えば、6人 のプロジェクトだと、コミュニケーションパスは15通りとなり、それだけコミュニケーションの取引コストがかかります（図1）。

図1●コミュニケーションの取引コストを減らす工夫

[画像のクリックで拡大表示]

　ここに、プロジェクト管理ツールを入れ、必要な情報をツールで管理すると、コミュニケーションパスはツールへのアクセスパスである6通りで済みます。プロジェクトの参加人数が多くなればなるほど、そのメリットは大きなものとなります。

また、管理ツールには、「登録はほぼリアルタイムで、参照は非同期」という大きなメリットがあります。関係者の時間を束縛せずに、自分が見たい時 （時間があるとき）に最新の状況を参照できるということは、関係者が自分の本来の作業を邪魔されずに実施できる、ということにつながります。

　その上で、こうしたメリットをきちんと享受するためには、「情報の責任者」を明確にしておくことが欠かせません。よく現場で起こる問題として、「知らな い間に勝手にある課題の主担当にされていたが、誰が責任をもって動いていたのかが分からない」というパターンがあります。皆さんも一度は経験があるのではないでしょうか。

　このように、「ツールに登録して割り振ったもの勝ち」という運用をしていると、ツールを利用して「単に仕事を押し付けているだけ」になってしまいます。 これではツールを入れた意味がありません。そうならないように、管理ツールに登録された内容について、「誰が責任者なのか」をきちんと割り振る仕組みやルールを確立する必要があります。

ツール間の連動が有効利用のコツ

　次に（2）ツールはプロジェクト内の隙間を埋める、というメリットについて考えてみたいと思います。『第78回 新任PMOが悩むPMOの立ち位置（2）』 にて、プロジェクトに潜む隙間について書きました。簡単におさらいすると、『プロジェクトの「人と人」「組織と組織」「プロセスとプロセス」「ツールとツール」のそれぞれの間には隙間ができやすい。そういう隙間を作らず、隙間に必要な情報がこぼれ落ちないようにすることが重要だ』という話をしました。そ の隙間を埋める仕組みとしてプロジェクト管理ツールをうまく使うとよいでしょう。隙間を埋めることはPMOの仕事ですが、それをツールで補うことができれ ば、膨大な情報量を効率よくさばくことができます。前述した「人と人」「組織と組織」の間については、ツールによって情報を埋めることができます。

　ここでのポイントは、「ツールとツール」「プロセスとプロセス」の間を、プロジェクト管理ツールでいかにつないでいくか、という観点です。例えば、「課 題管理プロセス」「変更管理プロセス」「コスト管理プロセス」「進捗管理プロセス」という4つのプロセスがあり、それぞれを「課題管理ツール」「変更管理 ツール」「コスト管理ツール」「進捗管理ツール」で管理していたとします。

感の良い方はお分かりかと思いますが、それぞれのツールとプロセスは当然ながらつながっているのです。良いプロジェクト管理ツールと言うのは、そのつながりをシームレスに実現しているツールだと言えます。

　例えば、次のようなケースを考え見ましょう（図2）。

1. ある大きな課題が発生した（課題管理プロセス/ツール）
   　　　　　↓
2. その課題に対応するため、要件が変更に
   　　　　　↓
3. 変更管理ツールで変更内容を管理する（変更管理プロセス/ツール）
   　　　　　↓
4. この変更の実施のために要員2人分（500万円）の追加コストが発生
   　　　　　↓
5. コスト管理ツールでコストを修正（コスト管理プロセス/ツール）
   　　　　　↓
6. 課題対応のため、2人の要員がアサインされスケジュールが変更に（リソース管理プロセス）
   　　　　　↓
7. 進捗管理ツールでタスクと要員を追加（進捗管理プロセス/ツール）

図2●単一のツールや単一のプロセスだけで作業は完結しない

[画像のクリックで拡大表示]

　このような活動の中で、もし各ツールやプロセスがバラバラであれば、1～7のそれぞれの間をプロジェクトマネジャーやPMOがつないでいかないと、全体 の整合性が取れなくなってしまいます。これでは各プロセスの情報を電子化しただけで、プロジェクトマネジメントの品質向上や効率化にはつながりません。

　その意味では、各管理ツール間、各プロセス間をシームレスにつなげられるツールを導入するか、各管理プロセスをうまくつなげるプロセスを運用ルールとしてカバーしていけば、より生産性を高めていくことができます。

　次回は、プロジェクト管理ツールについて、（3）～（5）の導入メリットを見ていきます。