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

　私は、キックオフの場で構築事業者のPM（プロジェクトマネージャ）がプロジェクト計画書の抜粋を説明して、お客様も、工程管理事業者も、その場でそれをはじめて聞くようなプロジェクトは、最初から失敗していると思っているんですよね。
　キックオフの場はみんなが一緒に作って合意した内容を改めて確認、OKだね、にしていく必要がある。そうするとプロジェクト全体に一体感も生まれるし。それってすごく重要。何か起こっても一緒に解決していきましょうっていう環境が最初に作り込める。

　それは誰ができるのかっていうと、PMOなのかなって。

　そうそう。もうお客様と最初からいろいろ話をしていて、むしろキックオフなんかいらないぐらいの状態に持ってくるんだと思う。

　自分が工程管理で入った案件ではないのですが、一番雰囲気が良くなかったのは、チームっていう感覚はなくて、発注者は発注者で言いたいこと言うし、PMOはベンダー叩きだけみたいなことがありました。そういったのは避けるようにしたいですね。
　出てきたものをひたすら叩くだけなら誰でもできると思うんです。その指摘がプロジェクトにどう影響を与えるのか、結果として、本当にそれが必要なのか、さらにその課題が出たのであれば、その対応策って何なのっていうところまで一緒に考えることが工程管理のあるべきだと思います。
　当然レビューとかは、お客様側のスキルセットもまちまちでテクニカルな部分を全てお客様側が理解できるものではないと思うので、そういった部分を工程管理事業者が確認していくことが重要だと思っています。
　うまくいった時は、構築事業者が決まる前の調達支援の段階から、お客様との間で「このプロジェクトにはどんな課題があってどう進めていくべきなのか」などをあらかじめ洗っておくんです。プロジェクトが始まって、構築事業者が決定したタイミングで彼らへスケジュール感を伝えますが、これをやっておくと、こちらが考える課題感とか、早く決めなきゃいけないポイントの擦り合わせを最初にできる。お互いにちゃんと考えているよねっていう気持ちにもなるので、進める上で非常にいいと考えています。
　あとはお客様側も発注者側だと思うんですけど、自分たちもプロジェクトの一員だと考えてもらうのは、特に重要だと思っています。彼ら側で意思決定しなきゃいけないタイミングとか、向こうが求められたタイミングでアクションしなきゃいけないことがもちろんあります。そこにタイムリーに反応してもらわないと、プロジェクト全体のスケジュールにも影響します。そういったポイントを最初の段階でうまく調整できているとうまくいったな、と感じるかな。

　最後のいい話ですよね。業務を発注するってことは、別に丸投げするわけじゃなくて、ワーク自体の担当は任せた先に移動はするけど、責任は任せた側に残っているはずですよね。責任まで丸投げして、完成責任を構築事業者に問うのはお客様側の正しい立場ではないはず。そこを分かってもらう努力をしないといけないのかなと思う。

　それって、構築事業者側から言うものでもないし、言いにくいこともあると思うんですよね。そこはPMOが第三者として、発注者側も意識してやってもらうことがありますよっていうところを意識付けしていくことが、立ち上がりで一番大事かなと思う。

　そうそう。今のいい話だなと思う。そうだね。PMOはそういうところをきちっとやるんだろうなと思うね。
　あとは、お客様側の環境づくりも結構重要だと思う。どうしても悪いことって起きるから、それがちゃんと構築事業者から上がるような環境づくりを、お客様側でできるようにPMOの人たちはうまく動けたらいいと思う。悪いことは隠さない。いつでも正直に話ができる。そういう環境づくりは、PMOがやれる役割の大きなところの一つかなって思うね。

　そこってPMO側も一体になってプロジェクトやっているんだよっていうのを構築事業者にちゃんと伝えるというか。PMOが発注者側にいるんだぞ、みたいな立ち位置を見ると、構築事業者も言いにくい環境とかってあるし。そこはちゃんと中立というか、見るとこはちゃんと見るけど、構築事業者側のほうもちゃんと考えているよっていうのを、一緒に伝えていくのが重要かなとは思う。

　スケジュールや課題を管理するだけの工程管理事業者って多いじゃない。我々だって気を抜いたらそうなってしまう。そんな中をしっかりとうまく取り持って、一体感を醸成して、みんなで同じゴールを見て進めていける。そういう役割を担えたら、すごいPMOなんだろうなって思うよね。

　スケジュール管理だけだったらベンダーさんのPMOとかやってきていると思うんで。あとお客様側の要求要件を正しく、工程管理側が最初に理解していくのも非常に重要だと思います。
　お客様側が全て伝えられてなくて、最終的になんか違うな、とか、結構あります。前工程から一緒にやっているからこそだと思うんですけど、その要件が作り上げられた検討の経緯は必ずあるはずなので、そういったところって要件定義書に全てが載っているわけじゃないはずなんです。
　だからそういった部分も、工程管理側がプロジェクトの立ち上げ時点で伝えてあげると、彼らの業務も矢印が変な方向を向かないように進められるし、その検討の経緯は当然お客様側の担当者も一緒に決めてきたところだと思うので、そういった意味でもプロジェクトの推進には役立つかなと思う。

　そこはシステムインテグレータのプロジェクトマネージャの立場でいうと、調達時の要件定義、特にシステム要件定義は必ず見直さないといけないと思っていたけどね。

　あと、調達時点では製品まで指定しないですし。結局システムインテグレータが持ち込む製品に合わせてシステム要件定義って改めてやる必要があるから、しょうがないんだけどね。

　冒頭でPMOの工程管理はいらないって、極端に振ってみたけど、なんだかちょっといい感じの解が出てきたね。

　あと、開発現場をある程度経験した人はいいけど、本来PMOって、構築事業者側でプロジェクトマネージメントをきちっとやってきたキャリアの長い人がやる仕事だって僕はずっと思っていて。
　若手のコンサルタントの人たちって、そういう経験をすっ飛ばしてPMOをやるわけじゃない?だから、先輩たちが一緒にメンバーに入れたときは、自分たちもお客様側だけの立場じゃなくて、構築事業者側にもちゃんと入っていかないといけない。自分たちもシステムを作っているというのは疑似体験でしかないけれど、それでも、ないよりはずっとよくて。そういった経験をいかにやらせてあげられるかは考えたほうがいいと思います。

　PMOにも、構築事業者側の体験が大事だよね。

ありがとうございました。

ありがとうございました。