社内対談
システム調達におけるプロジェクトマネジメントとコンサルタントによる工程管理のあるべき姿【前編】

　システムインテグレータのシステムエンジニアとして10年ぐらい経験を積み、その後10年程度プロジェクトマネージャを務めていました。プロジェクトマネージャの経験の後半3年くらいは、トラブルプロジェクトのレスキューでしたので、自分で作るというよりは、炎上プロジェクトを立て直す方がメインでした。自分でゼロからプロジェクトを立ち上げて、ゴールを目指すという経験は7年くらいです。
　主には官公庁のシステムで、マルチベンダーのシステムの構築プロジェクトのプロジェクトマネージャが長かったですね。

　そうですね。ただ、技術的には僕が一番っていう立場も多かったので、実際に手を動かすところは任せるんですけど、エンジニアにあえて喧嘩を売ってですね、要件定義や設計に関してはかなり口を出していました。メンバーからすると面倒くさいプロジェクトマネージャだったんじゃないかなと思います。
　システムのプラットフォームについては、パソコンからメインフレームまで一通り関わりました。
　PMO業務を請け負う工程管理事業者と、システムインテグレータのプロジェクトマネージャの立ち位置の違いで一番大きいのは、自分でシステムを作る立場なのか、作らないのかっていうところだと思います。
　究極的な話をすると、システムインテグレータのプロジェクトマネジメントが完璧だったら、本来は工程管理事業者なんていらないと僕は思っています。今の立場的にはコンサルタントなので、ちょっと自己否定というか自己矛盾的なところがありますが。
　実際にシステムインテグレータのプロジェクトマネージャだったときは、工程管理事業者、要はコンサルタントに対しては、それを君が言うのか、みたいに思っていたことが多々あります。だからこそ、「工程管理事業者のバリューはなんだ」と言うことを、我々としてはすごく考えて仕事をしていかなきゃいけないと思います。

　大学を卒業して入った会社はシステムインテグレータですが、そこで財務系のパッケージシステムの開発や改修に2年程度携わった後、そのパッケージに絡んだプロジェクトマネジメントに2年携わりました。
　その後、グラビスに来まして、主に中央省庁様をメインに、LANシステムとか、中央省庁の職員の皆さんが使うシステム全般のシステム更改に向けた調達支援をやりつつ、調達支援の後続工程で、システム構築の工程管理を主にやってきました。

　山田さんがおっしゃっていた通り、システムを作る側と作らない側というのは一つ大きくあると思います。また、システム構築を実際にやるシステムインテグレータは、システムを作る当事者なので、僕のイメージだけで申し上げると、システムをどう作るかとか、自分の会社にとってどのようにやっていくかが、強く出てしまうケースがあるかなと思います。
　一方で、工程管理業者は、第三者の目線から見なきゃいけないのですが、お客様側の立場に立ってシステムを運用した後とか、そのシステムが実際にどう動いていくかっていうところをちゃんと見ながら、お客様側がシステムを実際に利用するときに、どういったシステムが本当に使いやすいのかとか、そういった部分を支援していくことが、最も重要かと考えています。そういったところでの立ち位置の違いはあるんじゃないかと考えています。

　プロジェクトは計画段階で、成否の7、8割が決まると思っています。プロジェクトってピンボック（PMBOK（Project Management Body of Knowledge））にも「スタートがあってエンドがある有機性の活動、アクティビティ」と定義されている。だからプロジェクトマネージャがスタートする前に最初にやらなきゃいけないことは、ゴールまでの見通しをどれだけきちっと見えるようにしておくかだと思ってやっていました。しかもこれはプロジェクトマネージャにしかできない仕事だと思う。

　プロジェクト計画書って公共機関の案件だと、どこでも成果物になっているので、なんとなくみんな定型的なフォームに定型的な内容で作っているけど、本当はそうじゃなくて、ものすごく重要な位置づけにある。プロジェクトが始まる前にプロジェクトマネージャが脳みそをフル回転でプロジェクト計画書を作ることが僕は一番大事だと思っていました。「気を付けていること」はそういうところでしたね。ありとあらゆる可能性を開始するまでにどれだけ考慮できるか。
　僕は人をたくさん使う大規模プロジェクトが多かったので、プロジェクトがスタートした後に「これってどうだったんだっけ」とかいうと、何十人、何百人の単位で足を止めちゃうことになる。一日止めるとコストはどれだけ無駄になるのか、というところがすごく大きくて。だからプロジェクト計画書はものすごく気合い入れて作っていました。

　僕のプロジェクトに対するイメージって、スタートがあってゴールがある一本道なんですけど、プロジェクトマネージャはその一本道を先頭に立ってメンバーを従えて進んでいく、先導する人だとイメージしていました。見通しが甘いままスタートした場合、例えばいきなり目の前に落とし穴が出現すると、全員でその落とし穴にドンと落ちちゃうわけじゃないですか。だからプロジェクトマネージャはそうならないように、どれだけ出発する前に道中、ゴールまでの落とし穴を見通して、あらかじめ対応策をどれだけ考えられるか。つまりは、PMBOKのリスクマネジメントで言っているとおり、まずはリスクをどれだけ事前に識別できるか、その上で、回避だとか転嫁だとか軽減だとか受容だとか、そういったリスクの対応策をスタートの前にどれだけ考えられるかっていったところだと思っています。

　要はプロジェクトの計画段階でどれだけできるかってところです。そこを僕はすごく考えてプロジェクトマネージャをやっていましたね。そうすると、スタートしていきなりカオスになるとかは少なくともないはず。残りの2割とか3割は、自分たちがどうしようもない外部依存的な要因だとか事故だとか。特にマルチベンダーのプロジェクトだと、相手方が起因して何か起きるのはどうしようもないので。そういうところの2、3割をどうやって対応していくかっていうところが、次のプロジェクトマネージャの腕の見せ処なのかなと思っていました。

　だけど、シングルベンダーで自分たちがどうにでもなるプロジェクトだったら、基本的には8割、9割まで計画時点で想定しないとダメだと思う。外部依存ってほとんどないので。例えば、プロジェクト進行中に要件が変わったとかね。そういったことを僕はトラブルだとは思ってなくて。なぜならば、契約変更を変更プロセスに乗って対応すればいい話なので、それは別にトラブルじゃない。
　費用の問題ももちろんあるけど、計画した予算から出せるのであれば対応すればいいし、出せないのであれば、後々にやるか、何かとバーターするか。それも交渉の範囲内だと思う。だからシングルベンダーのプロジェクトのトラブルっていうのは、プロジェクトマネジメントの問題以外には僕はないと思っているんですけどね。

　山田さんがおっしゃった通り、計画段階は非常に重要です。僕がプロジェクト始める段階にするのは、スケジュール感や全体のマイルストーンの設定は当然なんですけど、このプロジェクトに関与するステークホルダーとか、その人の意思決定とか権限がどこにあるかを気にして整理するようにしています。
　というのも官公庁で多いのは、最終的に課長とかトップの方に行った段階で、「いやそれダメだよね」って言われるケースが少なくはないかなと思っていて。どのタイミングで誰に承認を取っていかなきゃいけないとか、全体のスケジュール感のマイルストーンからこのタイミングで報告しなきゃいけないとか、そういったところは最初の段階で整理しておく必要があると思います。
　その上で、構築事業者にお願いするときには、さっき言ったプロジェクトマネージャがどれだけ作業をイメージできて、どうやっていくかをどこまで想像できるかが非常に重要だと思います。
　そこで、彼らが作ったスケジュールを見たときに、当然、お客様側関係者の確認のタイミングとか、承認や合意を取るタイミングとか、そういったものを全部加味した形で全体のスケジュールになっていないと、実現性が無くなってしまう。そのようなところを注視しています。
　あと私が工程管理をやる場合は、大体要件定義から続けて工程管理をやるケースが多いです。プロジェクトに入ったばかりの構築事業者に、いきなりこのプロジェクト上の課題やリスクを洗って、対策とかどこまで考えているのって言っても、正直出てこないと思っています。そういったところはあらかじめ我々のほうでも、プロジェクトに入ったタイミングで一覧化して、調達時に事業者の方にお渡し、検討・管理いただくということは心がけています。

　本当にトップの方から言われちゃうと、調整も難しいですが、担当者の方も振り回す人って結構多いんです。多分要件定義が、定まっていないのかもしれないのですが、そういったことを言う方は結構多くいます。
　単純にお客様が言うことが全て正しいわけでは絶対なくて。そういった場合にはまず、それが仕様に本当に書かれているのかっていうのはもちろん確認すべきことの一つではあるものの、その上で、それを本当にやるべきか、改めてお客様側とも調整が必要だと思っています。
　今やらなきゃいけないことなのか、それをやることでどんな影響があるのか。全てを受け入れるというよりもまずお客様と一回調整して、本当にやるべきかどうかを判断した上で事業者の方と調整に入るようにします。本当にトップの方から言われちゃうと、なかなか私たちから話せる相手でもなかったりするので、そういった場合は担当者の方がどう考えるかにもよりますが、資料などの説得材料を用いてご説明を支援したり、そういった対応をしますね。

　担当者が振り回すタイプだと、担当者と調整してもダメな場合が多い。その場合はエスカレーションして検討いただくように働きかける。なんだけど、山下さんが言った通り、一番トップだった場合はしょうがない。そういうときはきっちり議事録残して、あとでそれをエビデンスにするか要件と照らして、要件を曲げているんだったら、それは変更ですよねっていうところの、ネゴシエーションはやるべきですよね。

　僕はスケジュールを伸ばすっていうのが優先順位で最後なんですよね。時間はイコールコストなんで。だから必ずスケジュール内に収まるように、他のものとバーターにすることを最初にやるかな。

　QCDってあるけど、あれって全然MECEじゃない。全てはコスト(C)に集約される。品質(Q)もそう、デリバリー(D)もそう。最後はコストにいく。そこがすごく重要。

　横並びじゃないよね。

　コストは逆に発注者側からあんまり見えない。請負契約とかだから、その金額の中でうまくやってよ、って発注者側は思いがち。あんまりそこって意識に至らないケースが多いなと。

　でも受注者側はそこが一番気になるところだよね。

　「品質」ってバクっとした言葉だと思っていて、これって発注者側と受注者側のレベルが全然違う。だからそのレベル合わせを最初にやらなきゃいけない。
　例えば、水も漏らさぬ完璧なシステムを目指すのか、ある程度不具合は許容してでも、とにかく早く稼働させるのが重要なのかとか。システムの性質によって違う。
　前者はミッションクリティカルなシステムで、時間とかコストとかを多くかけてでも完璧を目指さなきゃいけない。品質が何よりも重要なところだと思う。
　ただ後者は多少の不具合は問題ではなくて、とにかくタイムリーな稼働を求められるシステムだよね。例えば災害時にとにかく緊急的に情報を集めなきゃいけないシステムは、じっくり時間とコストをかけて品質を高めるよりは、翌日に稼働させなきゃいけないとか。対象システムが何かによって要求品質は変わるから、そのレベル合わせというか、コンセンサスを取るのが、最初にやっておかなきゃいけないことだなって、品質に関しては思うよね。

　そうそう、そういうことだよね。

　そうだよね。ベンダー内でもその辺の違いってあるから、まずはお客様とよく話し合って、先に決めないと後で大変なことになっちゃうよね。

　品質で言うと、システムの特性に応じた対応やレベル感が重要だと思うんですけど、目に見えるバクがないことや一定レベルのテストをしていることは前提だと思っています。
　それを前提とした上で、成果物のレベルなどは、山田さんがおっしゃっていただいた通り、お客様側と「このプロジェクトではどういった成果物をどう作っていって、レベル感はこういったもの」ということを最初の段階から意識合わせしていくことが非常に重要だと思います。

　そうだね。でもそれはなんでもそう。無駄なことはやらずに、やらなきゃいけないことに注力する。その辺の交通整理というか、うまく配分を支配するのが工程管理業者の役割かもしれないね。

　開発側のプロジェクトマネージャの立場ですけど、これも計画段階で、工数増大の種を仕込んでいる可能性が結構あると思っていて、計画段階のスコープの定義とか、工数の見積もりとか、そういったところが結構重要だと思う。
　コストオーバーランになったプロジェクトの原因って、最初のスコープ定義が間違っていたり、あとはタスクごとの見積もりが過小だったり、そういったことが大きな原因になるケースが多い。
　なぜかというと、冒頭に言ったレスキュー案件は、コストオーバーランしていたわけ。最初に入ったときにいろいろ見ていくと、スコープの定義とお客様との合意がうまくいってなかったり、タスクの見積もりが過小だったりが大きかった。なので、計画段階でスコープ定義や見積もりを緻密にやれれば、ある程度は、工数増大を防ぐことはできるんじゃないかな。

　そうなんです。構築事業者が作ってくるプロジェクトの全体像に対して、PMOとして入る工程管理事業者もちゃんと納得感というか、きちっと理解しておく必要がある。
　そこから深く入っていれば、例えば計画段階で問題そのものは見つけられないかもしれないけど、問題がありがちな場所は指摘できて、「そこは大丈夫ですか」って確認ができる。大丈夫だって確認できればOKだし、何か見つかれば、事前に工数増大の原因を1つ潰せるわけだから。工程管理業者って、プロジェクト計画書を今まさに作っている段階からは、なんとなく入らないでしょ。

　提出された計画とかはちゃんと見るようにしています。一番はスケジュール周りとかでタスク漏れとか、検討すべき要素が漏れていないかとかっていうのは最初結構見ますかね。